- Pharo-dev - lists.pharo.org

Re: [Pharo-project] RoarVM - Pharo and Squeak on Multicore

by Stefan Marr

Hi Igor: On 03 Nov 2010, at 22:36, Igor Stasenko wrote: > "so, placing: " > > eventBuffer at: 1 put: EventTypeNone. > > "should solve the promblem?" Ok, I found the difference. Probably our VM is behaving slightly different from what the SqueakVM. (Not sure what the 'right' thing to do is thought) >From my understanding, the idea is that if there is no event, the primitive will fail. And all other images have that case covered. They set the first array index to EventTypeNone. Thus, "InputEventFetcher>>primGetNextEvent: array" should look like: primGetNextEvent: array "Store the next OS event available into the provided array. Essential." <primitive: 94> array at: 1 put: EventTypeNone. "STEFAN: Added this line" ^nil However, since Pharo works on the other VM, I guess the primitive there is filling in the first slot of the array anyway. So, what is the specification? I think the primitives have changed since 'the bluebook'. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Nov. 3, 2010

[Pharo-project] a question about reef naming conventions

by Esteban Lorenzano

Hi, I'm having some doubts about how to call some methods for Reef. To be precise, I'm not sure about the naming og the method extensions I'm adding. For instance, I have an extension for Object, the method #asView, and some others in BlockClosure, #asCallback, asCallbackOn:, etc. So... I want to ask which naming convention is better. 1) Just let the methods like now? 2) adding a prefix, like reView, reCallback, etc.? 3) adding a full name prefix, asReefView, asReefCallback, etc.? What do you think? Cheers, Esteban

Nov. 3, 2010

Re: [Pharo-project] RoarVM - Pharo and Squeak on Multicore

by Igor Stasenko

On 3 November 2010 23:28, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hi Igor: > > Lets look at the current code, and let me explain what currently happens on the RoarVM. > > "Code as in Pharo 1.0" > eventLoop > Â Â Â Â "Fetch pending raw events from the VM. > Â Â Â Â This method is run at high priority." > Â Â Â Â | eventBuffer | > > Â Â Â Â "STEFAN: this is fine, it is an optimization but should not be a problem (Squeak has that also outside of the inner loop)" > Â Â Â Â eventBuffer := Array new: 8. > > Â Â Â Â [true] whileTrue: [ > Â Â Â Â Â Â Â Â | type window | > Â Â Â Â Â Â Â Â self waitForInput. > "so, placing: " eventBuffer at: 1 put: EventTypeNone. "should solve the promblem?" > Â Â Â Â Â Â Â Â [ > Â Â Â Â Â Â Â Â "STEFAN: here things break on RoarVM > Â Â Â Â Â Â Â Â Â Â Â Â the problem is, that eventBuffer is not filled with anything useful if there is no new event. > Â Â Â Â Â Â Â Â Â Â Â Â In case there is non new event, the content of eventBuffer seems to be the same content as it was before. > Â Â Â Â Â Â Â Â Â Â Â Â However, on all other forks, RoarVM seems to supply the right 'there is no event (EventTypeNone = 0)' value to eventBuffer" > Â Â Â Â Â Â Â Â self primGetNextEvent: eventBuffer. > Â Â Â Â Â Â Â Â type := eventBuffer at: 1. > Â Â Â Â Â Â Â Â type = EventTypeNone] > Â Â Â Â Â Â Â Â Â Â Â Â whileFalse: [ > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "Patch up the window index in case we don't get one" > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â window := eventBuffer at: 8. > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (window isNil > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â or: [window isZero]) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [eventBuffer at: 8 put: 1]. > > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self signalEvent: eventBuffer]] > > > I will have a look at what happen inside the VM later. > > Best regards > Stefan > > > On 03 Nov 2010, at 22:07, Igor Stasenko wrote: > >> On 3 November 2010 21:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> can you open a bug entry? >>> >> it was my idea putting >> >> eventBuffer := Array new: 8. >> >> outside of loop, since InputEventSensor anyways copying it before >> placing in queue: >> >> handleEvent: evt >> Â Â Â self queueEvent: evt shallowCopy. >> >> >> i have no idea, what can go wrong with it when running under RoarVM. >> >>> Stef >>> >>>>> Hi >>>>> Yes, is on a x86_64-linux, Debian squeeze. >>>> I use that setup on one of the machines, too. >>>> Should not be problem with the 32bit libraries. >>>> >>>>> The problem was some libraries... but with a good symbolic links compile >>>>> fine, but, Pharo 1.2 doesn't works, it freezes. >>>> Pharo works currently only with a single core, I think. >>>> And there might be one of my latest fixes missing in the current change set for Pharo. >>>> The event processing is broken somehow. I have a work-around (below) but still need to figure out why the eventBuffer is not filled in correctly by the primitive. >>>> >>>> Wouldn't be surprised if it is again Pharo's compiler *grml*. The other forks work, so I doubt that it is the primitive/VM. >>>> >>>> >>>> !InputEventFetcher methodsFor: 'events' stamp: 'StefanMarr 10/31/2010 21:45' prior: 47875547! >>>> eventLoop >>>> Â Â Â "Fetch pending raw events from the VM. >>>> Â Â Â Â This method is run at high priority." >>>> >>>> >>>> Â Â Â [true] whileTrue: [ >>>> Â Â Â Â Â Â Â | window eventBuffer type | >>>> Â Â Â Â Â Â Â self waitForInput. >>>> Â Â Â Â Â Â Â [eventBuffer := Array new: 8. >>>> Â Â Â Â Â Â Â self primGetNextEvent: eventBuffer. >>>> Â Â Â Â Â Â Â type := eventBuffer at: 1. >>>> Â Â Â Â Â Â Â ((type = EventTypeNone) or: [type isNil])] >>>> Â Â Â Â Â Â Â Â Â Â Â whileFalse: [ >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "Patch up the window index in case we don't get one" >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â window := eventBuffer at: 8. >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (window isNil >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â or: [window isZero]) >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [eventBuffer at: 8 put: 1]. >>>> >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self signalEvent: eventBuffer]]. >>>> Â Â Â Â Â Â Â RVMPrimitives printOnConsole: 'ended event loop'.! ! >>>> >>>> >>>>> >>>>> Someone could it on a x86_64-linux ? >>>>> >>>>> Thanks! >>>>> El miÃ©, 03-11-2010 a las 18:18 +0100, Stefan Marr escribiÃ³: >>>>>> Hello Felipe: >>>>>> >>>>>> On 03 Nov 2010, at 17:45, Felipe Ignacio Valverde Campos wrote: >>>>>>> Hi, how can i compile this on a x86_64 environment ? >>>>>>> until now i hace some problems with lstdc++ >>>>>> >>>>>> RoarVM does not support compilation as 64bit. >>>>>> So you will need the 32bit compatibility libraries. >>>>>> >>>>>> I don't remember doing something out of the ordinary but in the worst case some paths are guessed badly in src/makefiles/configure or src/makefiles/Makefile.common >>>>>> >>>>>> What is the exact system you are running on, some Linux is suppose? >>>>>> >>>>>> Best regards >>>>>> Stefan >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Estudiante de IngenierÃa Civil en ComputaciÃ³n >>>>> Departamento de Ciencias de la ComputaciÃ³n >>>>> Universidad de Chile >>>>> >>>>> http://www.dcc.uchile.cl/~fvalverd/public_key.asc >>>> >>>> -- >>>> Stefan Marr >>>> Software Languages Lab >>>> Vrije Universiteit Brussel >>>> Pleinlaan 2 / B-1050 Brussels / Belgium >>>> http://soft.vub.ac.be/~smarr >>>> Phone: +32 2 629 2974 >>>> Fax: Â +32 2 629 3525 >>>> >>>> >>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: Â +32 2 629 3525 > > > -- Best regards, Igor Stasenko AKA sig.

Nov. 3, 2010

Re: [Pharo-project] RoarVM - Pharo and Squeak on Multicore

by Stefan Marr

Hi Igor: Lets look at the current code, and let me explain what currently happens on the RoarVM. "Code as in Pharo 1.0" eventLoop "Fetch pending raw events from the VM. This method is run at high priority." | eventBuffer | "STEFAN: this is fine, it is an optimization but should not be a problem (Squeak has that also outside of the inner loop)" eventBuffer := Array new: 8. [true] whileTrue: [ | type window | self waitForInput. [ "STEFAN: here things break on RoarVM the problem is, that eventBuffer is not filled with anything useful if there is no new event. In case there is non new event, the content of eventBuffer seems to be the same content as it was before. However, on all other forks, RoarVM seems to supply the right 'there is no event (EventTypeNone = 0)' value to eventBuffer" self primGetNextEvent: eventBuffer. type := eventBuffer at: 1. type = EventTypeNone] whileFalse: [ "Patch up the window index in case we don't get one" window := eventBuffer at: 8. (window isNil or: [window isZero]) ifTrue: [eventBuffer at: 8 put: 1]. self signalEvent: eventBuffer]] I will have a look at what happen inside the VM later. Best regards Stefan On 03 Nov 2010, at 22:07, Igor Stasenko wrote: > On 3 November 2010 21:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> can you open a bug entry? >> > it was my idea putting > > eventBuffer := Array new: 8. > > outside of loop, since InputEventSensor anyways copying it before > placing in queue: > > handleEvent: evt > self queueEvent: evt shallowCopy. > > > i have no idea, what can go wrong with it when running under RoarVM. > >> Stef >> >>>> Hi >>>> Yes, is on a x86_64-linux, Debian squeeze. >>> I use that setup on one of the machines, too. >>> Should not be problem with the 32bit libraries. >>> >>>> The problem was some libraries... but with a good symbolic links compile >>>> fine, but, Pharo 1.2 doesn't works, it freezes. >>> Pharo works currently only with a single core, I think. >>> And there might be one of my latest fixes missing in the current change set for Pharo. >>> The event processing is broken somehow. I have a work-around (below) but still need to figure out why the eventBuffer is not filled in correctly by the primitive. >>> >>> Wouldn't be surprised if it is again Pharo's compiler *grml*. The other forks work, so I doubt that it is the primitive/VM. >>> >>> >>> !InputEventFetcher methodsFor: 'events' stamp: 'StefanMarr 10/31/2010 21:45' prior: 47875547! >>> eventLoop >>> "Fetch pending raw events from the VM. >>> This method is run at high priority." >>> >>> >>> [true] whileTrue: [ >>> | window eventBuffer type | >>> self waitForInput. >>> [eventBuffer := Array new: 8. >>> self primGetNextEvent: eventBuffer. >>> type := eventBuffer at: 1. >>> ((type = EventTypeNone) or: [type isNil])] >>> whileFalse: [ >>> "Patch up the window index in case we don't get one" >>> window := eventBuffer at: 8. >>> (window isNil >>> or: [window isZero]) >>> ifTrue: [eventBuffer at: 8 put: 1]. >>> >>> self signalEvent: eventBuffer]]. >>> RVMPrimitives printOnConsole: 'ended event loop'.! ! >>> >>> >>>> >>>> Someone could it on a x86_64-linux ? >>>> >>>> Thanks! >>>> El miÃ©, 03-11-2010 a las 18:18 +0100, Stefan Marr escribiÃ³: >>>>> Hello Felipe: >>>>> >>>>> On 03 Nov 2010, at 17:45, Felipe Ignacio Valverde Campos wrote: >>>>>> Hi, how can i compile this on a x86_64 environment ? >>>>>> until now i hace some problems with lstdc++ >>>>> >>>>> RoarVM does not support compilation as 64bit. >>>>> So you will need the 32bit compatibility libraries. >>>>> >>>>> I don't remember doing something out of the ordinary but in the worst case some paths are guessed badly in src/makefiles/configure or src/makefiles/Makefile.common >>>>> >>>>> What is the exact system you are running on, some Linux is suppose? >>>>> >>>>> Best regards >>>>> Stefan >>>>> >>>>> >>>> >>>> -- >>>> Estudiante de IngenierÃa Civil en ComputaciÃ³n >>>> Departamento de Ciencias de la ComputaciÃ³n >>>> Universidad de Chile >>>> >>>> http://www.dcc.uchile.cl/~fvalverd/public_key.asc >>> >>> -- >>> Stefan Marr >>> Software Languages Lab >>> Vrije Universiteit Brussel >>> Pleinlaan 2 / B-1050 Brussels / Belgium >>> http://soft.vub.ac.be/~smarr >>> Phone: +32 2 629 2974 >>> Fax: +32 2 629 3525 >>> >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Nov. 3, 2010

Re: [Pharo-project] RoarVM - Pharo and Squeak on Multicore

by Igor Stasenko

On 3 November 2010 21:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > can you open a bug entry? > it was my idea putting eventBuffer := Array new: 8. outside of loop, since InputEventSensor anyways copying it before placing in queue: handleEvent: evt self queueEvent: evt shallowCopy. i have no idea, what can go wrong with it when running under RoarVM. > Stef > >>> Hi >>> Yes, is on a x86_64-linux, Debian squeeze. >> I use that setup on one of the machines, too. >> Should not be problem with the 32bit libraries. >> >>> The problem was some libraries... but with a good symbolic links compile >>> fine, but, Pharo 1.2 doesn't works, it freezes. >> Pharo works currently only with a single core, I think. >> And there might be one of my latest fixes missing in the current change set for Pharo. >> The event processing is broken somehow. I have a work-around (below) but still need to figure out why the eventBuffer is not filled in correctly by the primitive. >> >> Wouldn't be surprised if it is again Pharo's compiler *grml*. The other forks work, so I doubt that it is the primitive/VM. >> >> >> !InputEventFetcher methodsFor: 'events' stamp: 'StefanMarr 10/31/2010 21:45' prior: 47875547! >> eventLoop >> Â Â Â "Fetch pending raw events from the VM. >> Â Â Â Â This method is run at high priority." >> >> >> Â Â Â [true] whileTrue: [ >> Â Â Â Â Â Â Â | window eventBuffer type | >> Â Â Â Â Â Â Â self waitForInput. >> Â Â Â Â Â Â Â [eventBuffer := Array new: 8. >> Â Â Â Â Â Â Â self primGetNextEvent: eventBuffer. >> Â Â Â Â Â Â Â type := eventBuffer at: 1. >> Â Â Â Â Â Â Â ((type = EventTypeNone) or: [type isNil])] >> Â Â Â Â Â Â Â Â Â Â Â whileFalse: [ >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "Patch up the window index in case we don't get one" >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â window := eventBuffer at: 8. >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (window isNil >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â or: [window isZero]) >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [eventBuffer at: 8 put: 1]. >> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self signalEvent: eventBuffer]]. >> Â Â Â Â Â Â Â RVMPrimitives printOnConsole: 'ended event loop'.! ! >> >> >>> >>> Someone could it on a x86_64-linux ? >>> >>> Thanks! >>> El miÃ©, 03-11-2010 a las 18:18 +0100, Stefan Marr escribiÃ³: >>>> Hello Felipe: >>>> >>>> On 03 Nov 2010, at 17:45, Felipe Ignacio Valverde Campos wrote: >>>>> Hi, how can i compile this on a x86_64 environment ? >>>>> until now i hace some problems with lstdc++ >>>> >>>> RoarVM does not support compilation as 64bit. >>>> So you will need the 32bit compatibility libraries. >>>> >>>> I don't remember doing something out of the ordinary but in the worst case some paths are guessed badly in src/makefiles/configure or src/makefiles/Makefile.common >>>> >>>> What is the exact system you are running on, some Linux is suppose? >>>> >>>> Best regards >>>> Stefan >>>> >>>> >>> >>> -- >>> Estudiante de IngenierÃa Civil en ComputaciÃ³n >>> Departamento de Ciencias de la ComputaciÃ³n >>> Universidad de Chile >>> >>> http://www.dcc.uchile.cl/~fvalverd/public_key.asc >> >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 2974 >> Fax: Â +32 2 629 3525 >> >> > > > -- Best regards, Igor Stasenko AKA sig.

Nov. 3, 2010

Re: [Pharo-project] RoarVM - Pharo and Squeak on Multicore

by StÃ©phane Ducasse

can you open a bug entry? Stef >> Hi >> Yes, is on a x86_64-linux, Debian squeeze. > I use that setup on one of the machines, too. > Should not be problem with the 32bit libraries. > >> The problem was some libraries... but with a good symbolic links compile >> fine, but, Pharo 1.2 doesn't works, it freezes. > Pharo works currently only with a single core, I think. > And there might be one of my latest fixes missing in the current change set for Pharo. > The event processing is broken somehow. I have a work-around (below) but still need to figure out why the eventBuffer is not filled in correctly by the primitive. > > Wouldn't be surprised if it is again Pharo's compiler *grml*. The other forks work, so I doubt that it is the primitive/VM. > > > !InputEventFetcher methodsFor: 'events' stamp: 'StefanMarr 10/31/2010 21:45' prior: 47875547! > eventLoop > "Fetch pending raw events from the VM. > This method is run at high priority." > > > [true] whileTrue: [ > | window eventBuffer type | > self waitForInput. > [eventBuffer := Array new: 8. > self primGetNextEvent: eventBuffer. > type := eventBuffer at: 1. > ((type = EventTypeNone) or: [type isNil])] > whileFalse: [ > "Patch up the window index in case we don't get one" > window := eventBuffer at: 8. > (window isNil > or: [window isZero]) > ifTrue: [eventBuffer at: 8 put: 1]. > > self signalEvent: eventBuffer]]. > RVMPrimitives printOnConsole: 'ended event loop'.! ! > > >> >> Someone could it on a x86_64-linux ? >> >> Thanks! >> El miÃ©, 03-11-2010 a las 18:18 +0100, Stefan Marr escribiÃ³: >>> Hello Felipe: >>> >>> On 03 Nov 2010, at 17:45, Felipe Ignacio Valverde Campos wrote: >>>> Hi, how can i compile this on a x86_64 environment ? >>>> until now i hace some problems with lstdc++ >>> >>> RoarVM does not support compilation as 64bit. >>> So you will need the 32bit compatibility libraries. >>> >>> I don't remember doing something out of the ordinary but in the worst case some paths are guessed badly in src/makefiles/configure or src/makefiles/Makefile.common >>> >>> What is the exact system you are running on, some Linux is suppose? >>> >>> Best regards >>> Stefan >>> >>> >> >> -- >> Estudiante de IngenierÃa Civil en ComputaciÃ³n >> Departamento de Ciencias de la ComputaciÃ³n >> Universidad de Chile >> >> http://www.dcc.uchile.cl/~fvalverd/public_key.asc > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >

Nov. 3, 2010

Re: [Pharo-project] Writing API for XML (WAX) - Bibliography example

by StÃ©phane Ducasse

No we consider it as an external package. Now we will have specific dedicated repositories for each version where configuration and all their packages will be published so that people can have distribution of working code. Stef On Nov 3, 2010, at 7:28 PM, Hannes Hirzel wrote: > Is XMLWriter in the upcoming 1.2 image? It is not in the 1.1 image. > > --Hannes > > On 11/3/10, Hannes Hirzel <hannes.hirzel(a)gmail.com> wrote: >> Thank you Stef, for pointing this out. >> >> I had a look at Torsten's email of July 6th about XMLWriter and the >> subsequent discussion. >> >> Yes, an alternative approach would be to model an XML generation API >> along the lines of Seaside html rendering -- with blocks instead of >> start/end messages. >> >> Has there some work going on elsewhere besides what Torsten did? >> http://squeaksource.com/PharoGoodies/XMLWriter-tbn.5.mcz >> >> --Hannes >> >> N.B. This is only about 'XML writing' NOT about XML parsing. The idea >> is to have an API which allows to have readable XML generation code >> with an implementation which does not consume much memory. And with >> enough examples and tests. >> >> >> On 11/2/10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Thanks hannes >>> I think that the XMLWriter offers a bit something similar influenced by >>> seaside DSL. >>> >>> Stef >>> >>> On Nov 1, 2010, at 10:58 PM, Hannes Hirzel wrote: >>> >>>> Hello >>>> >>>> I read the post by Stephane Ducasse about writing XML (see below) with >>>> a bibliography example. >>>> >>>> Recently I (re)-discovered the port to Squeak/Pharo of the Writing API >>>> for XML (WAX) (http://java.ociweb.com/mark/programming/WAX.html) and >>>> could put it to good use for writing an XML file a bit more complex >>>> than the bibliography example. >>>> >>>> From the web site >>>> WAX has the following characteristics: >>>> >>>> * focuses on writing XML, not reading it >>>> * requires less code than other approaches >>>> * uses less memory than other approaches >>>> (because it outputs XML as each method is called rather than >>>> storing it in a DOM-like structure and outputting it later) >>>> * writes all XML node types >>>> * always outputs well-formed XML or throws an exception unless >>>> running in "trust me" mode >>>> * knows how to associate DTDs, XML Schemas and XSLT stylesheets >>>> with the XML it outputs >>>> * is well-suited for writing XML request and response messages for >>>> REST-based and SOAP-based services >>>> >>>> However I do not know how far these points apply to the Squeak/Pharo >>>> port. >>>> http://www.squeaksource.com/WAX >>>> It needs the VB Regex package (http://www.squeaksource.com/Regex) >>>> >>>> As an exercise I did the code to produce the example Stephane gave. It >>>> worked fine; see below. >>>> >>>> Regards >>>> Hannes >>>> >>>> >>>> >>>> >>>> >>>> ========================================================== >>>> >>>> WAX new >>>> stream: (FileStream newFileNamed: 'myBibliography.xml'); >>>> writeXMLDeclaration: #1.0; >>>> start: 'BDBase'; >>>> attr: 'date' value: '25 May 2010'; >>>> attr: 'note' value: 'nil'; >>>> >>>> start: 'bd'; >>>> attr: 'authors' value: 'Larcenet'; >>>> attr: 'editor' value: 'Dargaud'; >>>> attr: 'entryCreationDate' value: '25 March 2006'; >>>> attr: 'entryNumber' value: '1'; >>>> attr: 'number' value: '1'; >>>> attr: 'original' value: 'true'; >>>> attr: 'serie' value: 'Nic oumouk'; >>>> attr: 'serieComplete' value: 'false'; >>>> attr: 'title' value: 'Total souk pour nic oumouk'; >>>> attr: 'year' value: '2005'; >>>> end; >>>> >>>> start: 'bd'; >>>> attr: 'authors' value: 'Greg'; >>>> attr: 'editor' value: 'Dargaud'; >>>> attr: 'entryCreationDate' value: '5 May 2006'; >>>> attr: 'entryNumber' value: '2'; >>>> attr: 'notes' value: 'sur le 4eme de couv aventure a manhattan'; >>>> attr: 'number' value: '9'; >>>> attr: 'original' value: 'true'; >>>> attr: 'serie' value: 'Achille Talon'; >>>> attr: 'title' value: 'Les petits desseins d''Achille Talon'; >>>> attr: 'year' value: '1974'; >>>> end; >>>> >>>> start: 'bd'; >>>> attr: 'authors' value: 'Greg'; >>>> attr: 'editor' value: 'Dargaud'; >>>> attr: 'entryCreationDate' value: '5 May 2006'; >>>> attr: 'entryNumber' value: '3'; >>>> attr: 'notes' value: 'sur la couverture une histoire du journal >>>> tintin'; >>>> attr: 'number' value: '13'; >>>> attr: 'original' value: 'true'; >>>> attr: 'serie' value: 'Achille Talon'; >>>> attr: 'title' value: 'Pas de pitiÃ© pour Achille Talon'; >>>> attr: 'year' value: '1976'; >>>> end; >>>> end; >>>> close. >>>> >>>> ========================================================== >>>> Output >>>> <?xml version="1.0" encoding="UTF-8"?> >>>> <BDBase date="25 May 2010" note="nil"> >>>> <bd authors="Larcenet" editor="Dargaud" entryCreationDate="25 March >>>> 2006" entryNumber="1" number="1" original="true" serie="Nic oumouk" >>>> serieComplete="false" title="Total souk pour nic oumouk" year="2005"/> >>>> <bd authors="Greg" editor="Dargaud" entryCreationDate="5 May 2006" >>>> entryNumber="2" notes="sur le 4eme de couv aventure a manhattan" >>>> number="9" original="true" serie="Achille Talon" title="Les petits >>>> desseins d'Achille Talon" year="1974"/> >>>> <bd authors="Greg" editor="Dargaud" entryCreationDate="5 May 2006" >>>> entryNumber="3" notes="sur la couverture une histoire du journal >>>> tintin" number="13" original="true" serie="Achille Talon" title="Pas >>>> de pitiÃ© pour Achille Talon" year="1976"/> >>>> </BDBase> >>>> >>>> >>>> >>>> ========================================================== >>>> >>>> On 10/31/10, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>>>> How can I control that each of the node of my document get printed a cr >>>>> at >>>>> its end? >>>>> >>>>> In the past I got that >>>>> >>>>> <?xml version="1.0" encoding="UTF-8" ?> >>>>> <BDBase date="25 May 2010" entriesNumber="2440" note="nil"> >>>>> <bd authors="Larcenet" editor="Dargaud" entryCreationDate="25 March >>>>> 2006" >>>>> entryNumber="1" number="1" original="true" serie="Nic oumouk" >>>>> serieComplete="false" title="Total souk pour nic oumouk" year="2005"/> >>>>> <bd authors="Greg" editor="Dargaud" entryCreationDate="5 May 2006" >>>>> entryNumber="2" notes="sur le 4eme de couv aventure a manhattan" >>>>> number="9" >>>>> original="true" serie="Achille Talon" title="Les petits desseins >>>>> d'Achille >>>>> Talon" year="1974"/> >>>>> <bd authors="Greg" editor="Dargaud" entryCreationDate="5 May 2006" >>>>> entryNumber="3" notes="sur la couverture une histoire du journal >>>>> tintin" >>>>> number="13" original="true" serie="Achille Talon" title="Pas de pitiÃ© >>>>> pour >>>>> Achille Talon" year="1976"/> >>>>> <bd aut >>>>> >>>>> Now I get >>>>> >>>>> <?xml version="1.0" encoding="UTF-8"?><Base date="31 October 2010" >>>>> entriesNumber="2448" note="nil"><bd serieComplete="false" >>>>> editor="Dargaud" >>>>> entryCreationDate="25 March 2006" entryNumber="1" authors="Larcenet" >>>>> title="Total souk pour nic oumouk" serie="Nic oumouk" original="true" >>>>> number="1" year="2005" /><bd serieComplete="false" editor="Dargaud" >>>>> entryCreationDate="5 May 2006" entryNumber="2" authors="Greg" >>>>> title="Les >>>>> petits desseins d'Achille Talon" serie="Achille Talon" original="true" >>>>> notes="sur le 4eme de couv aventure a manhattan" number="9" year="1974" >>>>> /><bd serieComplete="false" editor="Dargaud" entryCreationDate="5 May >>>>> 2006" >>>>> entryNumber="3" authors="Greg" title="Pas de pitiÃ© pour Achille Talon" >>>>> serie="Achille Talon" original="true" notes="sur la couverture une >>>>> histoire >>>>> du journal tintin" number="13" year="1976" /><bd serieComplete="false" >>>>> editor="Dargaud" entryCreationDate="5 May 2006" entryNumber="4" >>>>> authors="Greg" title >>>>> >>>>> Thanks >>>>> >>>>> Stef >>>>> >>>> >>> >>> >>> >> >

Nov. 3, 2010

Re: [Pharo-project] RoarVM - Pharo and Squeak on Multicore

by Stefan Marr

On 03 Nov 2010, at 18:40, Felipe Ignacio Valverde Campos wrote: > Hi > Yes, is on a x86_64-linux, Debian squeeze. I use that setup on one of the machines, too. Should not be problem with the 32bit libraries. > The problem was some libraries... but with a good symbolic links compile > fine, but, Pharo 1.2 doesn't works, it freezes. Pharo works currently only with a single core, I think. And there might be one of my latest fixes missing in the current change set for Pharo. The event processing is broken somehow. I have a work-around (below) but still need to figure out why the eventBuffer is not filled in correctly by the primitive. Wouldn't be surprised if it is again Pharo's compiler *grml*. The other forks work, so I doubt that it is the primitive/VM. !InputEventFetcher methodsFor: 'events' stamp: 'StefanMarr 10/31/2010 21:45' prior: 47875547! eventLoop "Fetch pending raw events from the VM. This method is run at high priority." [true] whileTrue: [ | window eventBuffer type | self waitForInput. [eventBuffer := Array new: 8. self primGetNextEvent: eventBuffer. type := eventBuffer at: 1. ((type = EventTypeNone) or: [type isNil])] whileFalse: [ "Patch up the window index in case we don't get one" window := eventBuffer at: 8. (window isNil or: [window isZero]) ifTrue: [eventBuffer at: 8 put: 1]. self signalEvent: eventBuffer]]. RVMPrimitives printOnConsole: 'ended event loop'.! ! > > Someone could it on a x86_64-linux ? > > Thanks! > El miÃ©, 03-11-2010 a las 18:18 +0100, Stefan Marr escribiÃ³: >> Hello Felipe: >> >> On 03 Nov 2010, at 17:45, Felipe Ignacio Valverde Campos wrote: >>> Hi, how can i compile this on a x86_64 environment ? >>> until now i hace some problems with lstdc++ >> >> RoarVM does not support compilation as 64bit. >> So you will need the 32bit compatibility libraries. >> >> I don't remember doing something out of the ordinary but in the worst case some paths are guessed badly in src/makefiles/configure or src/makefiles/Makefile.common >> >> What is the exact system you are running on, some Linux is suppose? >> >> Best regards >> Stefan >> >> > > -- > Estudiante de IngenierÃa Civil en ComputaciÃ³n > Departamento de Ciencias de la ComputaciÃ³n > Universidad de Chile > > http://www.dcc.uchile.cl/~fvalverd/public_key.asc -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Nov. 3, 2010

Re: [Pharo-project] Writing API for XML (WAX) - Bibliography example

by Hannes Hirzel

Is XMLWriter in the upcoming 1.2 image? It is not in the 1.1 image. --Hannes On 11/3/10, Hannes Hirzel <hannes.hirzel(a)gmail.com> wrote: > Thank you Stef, for pointing this out. > > I had a look at Torsten's email of July 6th about XMLWriter and the > subsequent discussion. > > Yes, an alternative approach would be to model an XML generation API > along the lines of Seaside html rendering -- with blocks instead of > start/end messages. > > Has there some work going on elsewhere besides what Torsten did? > http://squeaksource.com/PharoGoodies/XMLWriter-tbn.5.mcz > > --Hannes > > N.B. This is only about 'XML writing' NOT about XML parsing. The idea > is to have an API which allows to have readable XML generation code > with an implementation which does not consume much memory. And with > enough examples and tests. > > > On 11/2/10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Thanks hannes >> I think that the XMLWriter offers a bit something similar influenced by >> seaside DSL. >> >> Stef >> >> On Nov 1, 2010, at 10:58 PM, Hannes Hirzel wrote: >> >>> Hello >>> >>> I read the post by Stephane Ducasse about writing XML (see below) with >>> a bibliography example. >>> >>> Recently I (re)-discovered the port to Squeak/Pharo of the Writing API >>> for XML (WAX) (http://java.ociweb.com/mark/programming/WAX.html) and >>> could put it to good use for writing an XML file a bit more complex >>> than the bibliography example. >>> >>> From the web site >>> WAX has the following characteristics: >>> >>> * focuses on writing XML, not reading it >>> * requires less code than other approaches >>> * uses less memory than other approaches >>> (because it outputs XML as each method is called rather than >>> storing it in a DOM-like structure and outputting it later) >>> * writes all XML node types >>> * always outputs well-formed XML or throws an exception unless >>> running in "trust me" mode >>> * knows how to associate DTDs, XML Schemas and XSLT stylesheets >>> with the XML it outputs >>> * is well-suited for writing XML request and response messages for >>> REST-based and SOAP-based services >>> >>> However I do not know how far these points apply to the Squeak/Pharo >>> port. >>> http://www.squeaksource.com/WAX >>> It needs the VB Regex package (http://www.squeaksource.com/Regex) >>> >>> As an exercise I did the code to produce the example Stephane gave. It >>> worked fine; see below. >>> >>> Regards >>> Hannes >>> >>> >>> >>> >>> >>> ========================================================== >>> >>> WAX new >>> stream: (FileStream newFileNamed: 'myBibliography.xml'); >>> writeXMLDeclaration: #1.0; >>> start: 'BDBase'; >>> attr: 'date' value: '25 May 2010'; >>> attr: 'note' value: 'nil'; >>> >>> start: 'bd'; >>> attr: 'authors' value: 'Larcenet'; >>> attr: 'editor' value: 'Dargaud'; >>> attr: 'entryCreationDate' value: '25 March 2006'; >>> attr: 'entryNumber' value: '1'; >>> attr: 'number' value: '1'; >>> attr: 'original' value: 'true'; >>> attr: 'serie' value: 'Nic oumouk'; >>> attr: 'serieComplete' value: 'false'; >>> attr: 'title' value: 'Total souk pour nic oumouk'; >>> attr: 'year' value: '2005'; >>> end; >>> >>> start: 'bd'; >>> attr: 'authors' value: 'Greg'; >>> attr: 'editor' value: 'Dargaud'; >>> attr: 'entryCreationDate' value: '5 May 2006'; >>> attr: 'entryNumber' value: '2'; >>> attr: 'notes' value: 'sur le 4eme de couv aventure a manhattan'; >>> attr: 'number' value: '9'; >>> attr: 'original' value: 'true'; >>> attr: 'serie' value: 'Achille Talon'; >>> attr: 'title' value: 'Les petits desseins d''Achille Talon'; >>> attr: 'year' value: '1974'; >>> end; >>> >>> start: 'bd'; >>> attr: 'authors' value: 'Greg'; >>> attr: 'editor' value: 'Dargaud'; >>> attr: 'entryCreationDate' value: '5 May 2006'; >>> attr: 'entryNumber' value: '3'; >>> attr: 'notes' value: 'sur la couverture une histoire du journal >>> tintin'; >>> attr: 'number' value: '13'; >>> attr: 'original' value: 'true'; >>> attr: 'serie' value: 'Achille Talon'; >>> attr: 'title' value: 'Pas de pitiÃ© pour Achille Talon'; >>> attr: 'year' value: '1976'; >>> end; >>> end; >>> close. >>> >>> ========================================================== >>> Output >>> <?xml version="1.0" encoding="UTF-8"?> >>> <BDBase date="25 May 2010" note="nil"> >>> <bd authors="Larcenet" editor="Dargaud" entryCreationDate="25 March >>> 2006" entryNumber="1" number="1" original="true" serie="Nic oumouk" >>> serieComplete="false" title="Total souk pour nic oumouk" year="2005"/> >>> <bd authors="Greg" editor="Dargaud" entryCreationDate="5 May 2006" >>> entryNumber="2" notes="sur le 4eme de couv aventure a manhattan" >>> number="9" original="true" serie="Achille Talon" title="Les petits >>> desseins d'Achille Talon" year="1974"/> >>> <bd authors="Greg" editor="Dargaud" entryCreationDate="5 May 2006" >>> entryNumber="3" notes="sur la couverture une histoire du journal >>> tintin" number="13" original="true" serie="Achille Talon" title="Pas >>> de pitiÃ© pour Achille Talon" year="1976"/> >>> </BDBase> >>> >>> >>> >>> ========================================================== >>> >>> On 10/31/10, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>>> How can I control that each of the node of my document get printed a cr >>>> at >>>> its end? >>>> >>>> In the past I got that >>>> >>>> <?xml version="1.0" encoding="UTF-8" ?> >>>> <BDBase date="25 May 2010" entriesNumber="2440" note="nil"> >>>> <bd authors="Larcenet" editor="Dargaud" entryCreationDate="25 March >>>> 2006" >>>> entryNumber="1" number="1" original="true" serie="Nic oumouk" >>>> serieComplete="false" title="Total souk pour nic oumouk" year="2005"/> >>>> <bd authors="Greg" editor="Dargaud" entryCreationDate="5 May 2006" >>>> entryNumber="2" notes="sur le 4eme de couv aventure a manhattan" >>>> number="9" >>>> original="true" serie="Achille Talon" title="Les petits desseins >>>> d'Achille >>>> Talon" year="1974"/> >>>> <bd authors="Greg" editor="Dargaud" entryCreationDate="5 May 2006" >>>> entryNumber="3" notes="sur la couverture une histoire du journal >>>> tintin" >>>> number="13" original="true" serie="Achille Talon" title="Pas de pitiÃ© >>>> pour >>>> Achille Talon" year="1976"/> >>>> <bd aut >>>> >>>> Now I get >>>> >>>> <?xml version="1.0" encoding="UTF-8"?><Base date="31 October 2010" >>>> entriesNumber="2448" note="nil"><bd serieComplete="false" >>>> editor="Dargaud" >>>> entryCreationDate="25 March 2006" entryNumber="1" authors="Larcenet" >>>> title="Total souk pour nic oumouk" serie="Nic oumouk" original="true" >>>> number="1" year="2005" /><bd serieComplete="false" editor="Dargaud" >>>> entryCreationDate="5 May 2006" entryNumber="2" authors="Greg" >>>> title="Les >>>> petits desseins d'Achille Talon" serie="Achille Talon" original="true" >>>> notes="sur le 4eme de couv aventure a manhattan" number="9" year="1974" >>>> /><bd serieComplete="false" editor="Dargaud" entryCreationDate="5 May >>>> 2006" >>>> entryNumber="3" authors="Greg" title="Pas de pitiÃ© pour Achille Talon" >>>> serie="Achille Talon" original="true" notes="sur la couverture une >>>> histoire >>>> du journal tintin" number="13" year="1976" /><bd serieComplete="false" >>>> editor="Dargaud" entryCreationDate="5 May 2006" entryNumber="4" >>>> authors="Greg" title >>>> >>>> Thanks >>>> >>>> Stef >>>> >>> >> >> >> >

Nov. 3, 2010

Re: [Pharo-project] RoarVM - Pharo and Squeak on Multicore

by Felipe Ignacio Valverde Campos

Hi Yes, is on a x86_64-linux, Debian squeeze. The problem was some libraries... but with a good symbolic links compile fine, but, Pharo 1.2 doesn't works, it freezes. Someone could it on a x86_64-linux ? Thanks! El miÃ©, 03-11-2010 a las 18:18 +0100, Stefan Marr escribiÃ³: > Hello Felipe: > > On 03 Nov 2010, at 17:45, Felipe Ignacio Valverde Campos wrote: > > Hi, how can i compile this on a x86_64 environment ? > > until now i hace some problems with lstdc++ > > RoarVM does not support compilation as 64bit. > So you will need the 32bit compatibility libraries. > > I don't remember doing something out of the ordinary but in the worst case some paths are guessed badly in src/makefiles/configure or src/makefiles/Makefile.common > > What is the exact system you are running on, some Linux is suppose? > > Best regards > Stefan > > -- Estudiante de IngenierÃa Civil en ComputaciÃ³n Departamento de Ciencias de la ComputaciÃ³n Universidad de Chile http://www.dcc.uchile.cl/~fvalverd/public_key.asc

Nov. 3, 2010