format and gray streams

[Stas Boukarev]

(require :gray-streams) (format t "~:<~{~A~^ ~}~:>" '((1 2)))

Gives me:

Debugger invoked on condition of type SIMPLE-ERROR:
  There is no applicable method for the generic function
  #<STANDARD-GENERIC-FUNCTION GRAY-STREAMS:STREAM-WRITE-STRING
  {31CC903C}> when called with arguments (#<XP::XP-STRUCTURE {38A22EA7}>
  " " 0 NIL).


Works fine without gray strems.

Armed Bear Common Lisp 0.16.0-dev
Java 1.6.0_0 Sun Microsystems Inc.
OpenJDK 64-Bit Server VM

--
With best regards, Stas.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel

[Erik Huelsmann]

Stas, Mark,

I committed a change today. I know you both have been trying to get
Gray streams working. There was some terrible interaction between the
pretty printer and gray streams though.

I resolved the interaction - not in the way that I wanted to -
although the fix is as good as any. As a bonus, I changed the
signatures of the STREAM-READ-SEQUENCE and STREAM-WRITE-SEQUENCE
functions to be the same as those in Allegro CL: with the START and
END parameters being optional.

I hope this  helps!

Please report back your experiences.


Bye,


Erik.

On Tue, Jun 9, 2009 at 11:04 PM, Stas Boukarev<[hidden email]> wrote:

> (require :gray-streams) (format t "~:<~{~A~^ ~}~:>" '((1 2)))
>
> Gives me:
>
> Debugger invoked on condition of type SIMPLE-ERROR:
>  There is no applicable method for the generic function
>  #<STANDARD-GENERIC-FUNCTION GRAY-STREAMS:STREAM-WRITE-STRING
>  {31CC903C}> when called with arguments (#<XP::XP-STRUCTURE {38A22EA7}>
>  " " 0 NIL).
>
>
> Works fine without gray strems.
>
> Armed Bear Common Lisp 0.16.0-dev
> Java 1.6.0_0 Sun Microsystems Inc.
> OpenJDK 64-Bit Server VM
>
> --
> With best regards, Stas.
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> armedbear-j-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
>

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel

[Erik Huelsmann]

On Wed, Jun 10, 2009 at 9:17 PM, Erik Huelsmann<[hidden email]> wrote:

> Stas, Mark,
>
> I committed a change today. I know you both have been trying to get
> Gray streams working. There was some terrible interaction between the
> pretty printer and gray streams though.
>
> I resolved the interaction - not in the way that I wanted to -
> although the fix is as good as any. As a bonus, I changed the
> signatures of the STREAM-READ-SEQUENCE and STREAM-WRITE-SEQUENCE
> functions to be the same as those in Allegro CL: with the START and
> END parameters being optional.

Some further research to eliminate our incompatibility with the
"standard" regarding:

* STREAM-ELEMENT-TYPE
* CLOSE
* INPUT-STREAM-P
* OUTPUT-STREAM-P

which are all prefixed with STREAM- in our gray streams
implementation, turns out to be pretty hard: they are used by our
compiler, while replacing them means on-demand compilation.

This puts us in a catch-22 situation: we need to call CLOSE in order
to be able to compile it...

The solution however, seems to be available: eliminate the use of
temp-files for COMPILE. That way, the use of CLOSE should not be
required: we'll store the content of the temp file in-memory and load
the class from there. Alessio has already done some prep work for it.
I / we just need to hook that up.

So, the next priority would be to eliminate temp files in the
compiler. Who wants to take a stab at it?

Bye,

Erik.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel

[Alessio Stalla]

On Wed, Jun 10, 2009 at 10:46 PM, Erik Huelsmann<[hidden email]> wrote:
> The solution however, seems to be available: eliminate the use of
> temp-files for COMPILE. That way, the use of CLOSE should not be
> required: we'll store the content of the temp file in-memory and load
> the class from there. Alessio has already done some prep work for it.
> I / we just need to hook that up.
>
> So, the next priority would be to eliminate temp files in the
> compiler. Who wants to take a stab at it?

I'm still interested in eliminating the use of temp-files in the
compiler; I've just been busy with other things lately. I have a
couple of ideas which I'd like to try soon.
However, is eliminating temp files sufficient for not using close
anymore? What about compile-file?

Bye,
Alessio

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel

[Erik Huelsmann]

On Thu, Jun 11, 2009 at 8:58 AM, Alessio Stalla<[hidden email]> wrote:

> On Wed, Jun 10, 2009 at 10:46 PM, Erik Huelsmann<[hidden email]> wrote:
>> The solution however, seems to be available: eliminate the use of
>> temp-files for COMPILE. That way, the use of CLOSE should not be
>> required: we'll store the content of the temp file in-memory and load
>> the class from there. Alessio has already done some prep work for it.
>> I / we just need to hook that up.
>>
>> So, the next priority would be to eliminate temp files in the
>> compiler. Who wants to take a stab at it?
>
> I'm still interested in eliminating the use of temp-files in the
> compiler; I've just been busy with other things lately.

No problem! I have been too: when you make a toolkit, you need 'to eat
your own dogfood' to understand the strength and limitations of what
you're doing. IOW: I was creating a program *using* abcl.

> I have a couple of ideas which I'd like to try soon.
> However, is eliminating temp files sufficient for not using close
> anymore?

Well, ofcourse does elimination of temp files in COMPILE not eliminate
the use of CLOSE at all, but it eliminates the circular dependency
where compilation of CLOSE requires a call to CLOSE: upon compilation
to memory no CLOSE is required: the bytes will be moved into the
target buffer.

> What about compile-file?

It still uses CLOSE, but the point is not to eliminate the use of
CLOSE entirely: the point is to eliminate the circular dependency.
When using CLOSE the first time, an effective method is compiled. This
compilation uses temp files, currently. Hence the circular dependency.
Now, if we were to compile this CLOSE method to memory, no further
issues would occur there.


> Bye,
> Alessio


Bye,


Erik - who hopes to make sense today.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel