From: Stas B. <sta...@gm...> - 2009-06-09 21:04:18
|
(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. |
From: Erik H. <eh...@gm...> - 2009-06-10 19:17:41
|
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<sta...@gm...> 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 > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel > |
From: Erik H. <eh...@gm...> - 2009-06-10 20:46:42
|
On Wed, Jun 10, 2009 at 9:17 PM, Erik Huelsmann<eh...@gm...> 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. |
From: Alessio S. <ale...@gm...> - 2009-06-11 06:58:38
|
On Wed, Jun 10, 2009 at 10:46 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 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 |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2009-06-11 14:40:58
|
On Thu, Jun 11, 2009 at 8:58 AM, Alessio Stalla<ale...@gm...> wrote: > On Wed, Jun 10, 2009 at 10:46 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 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. |