- Pharo-dev - lists.pharo.org

[Pharo-project] Need your help filling a FAQ

by Igor Stasenko

Hello guys, i'm currently writing a documentation for my project - NativeBoost. The work is based on a simple plugin which i wrote, which allows to run a native code from Squeak. The native code is attached to a compiled method itself (into its trailer), and so lives within an image. The plugin can run this code through a single primitive, which knows how to do it right. Actually VM requires very small changes to support that. The bulk of the work lies at the language side. I'm currently working on making FFI callout support interface which will support many cool things, comparing to usual FFIPlugin. :) I'd like to know, what details you want to know about it (tautology ;) , so i will compose the FAQ along with other details about project. P.S. Google became too smart :) Once i clicked 'send' button, its shows a message box: Did you mean to attach files? You wrote "is attached" in your message, but there are no files attached. Send anyway? -- Best regards, Igor Stasenko AKA sig.

April 25, 2010

Re: [Pharo-project] Expectation for readFrom:... getting bored to fix bugs.

by Nicolas Cellier

2010/4/25 Igor Stasenko <siguctua(a)gmail.com>: > imo, it should look like: > > readFrom: stream > Â ^ readFrom: stream pattern: ISO8601 > > and > readFrom:pattern: > Yes, and next step will be to optimize with a pre-compiled pattern (may use a cache). Otherwise, when you have a bunch of String to convert in DateAndTime, you're spending time in parsing the same pattern repeatedly. Nicolas > should parse date by taking an arbitrary pattern into account. > We could invent own syntax for a pattern, or use other invented ones > (from C, Perl etc), > and implement a separate DateTimeParser class. > > The messy code like this > Â aStream peek = $- ifTrue: [ aStream next. bc := -1] ifFalse: [bc := 1]. > Â Â Â year := (aStream upTo: $-) asInteger * bc. > Â Â Â month := (aStream upTo: $-) asInteger ifNil: [1]. > Â Â Â day := (aStream upTo: $T) asInteger ifNil: [1]. > Â Â Â hour := (aStream upTo: $:) asInteger ifNil: [0]. > > should be put in trash! :) > > On 24 April 2010 23:05, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> What I did was to stick with the ISO parsing and added a fuzzy readfrom (the previous one in pharo) >> so that readFrom: read only iso but well and fuzzy tries to find its way with strange input. >> >> Stef >> >> On Apr 24, 2010, at 9:48 PM, Nicolas Cellier wrote: >> >>> 2010/4/24 Julian Fitzell <jfitzell(a)gmail.com>: >>>> On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse >>>> <stephane.ducasse(a)free.fr> wrote: >>>>> >>>>> What are the expectation for DateAndTime>>readFrom? >>>> >>>> Personally, my expectation is that it doesn't exist. :) >>>> >>>> To believe that there is a single way of parsing strings into dates (or >>>> numbers, or anything else) that will be appropriate in all cases is pretty >>>> silly. It would seem much better to me to have configurable parsing classes. >>>> >>>> Julian >>>> >>> >>> Sure, that might be usefull, however current implementation intention >>> clearly seems related to >>> http://en.wikipedia.org/wiki/ISO_8601 >>> >>> Nicolas >>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 25, 2010

Re: [Pharo-project] Expectation for readFrom:... getting bored to fix bugs.

by Igor Stasenko

On 25 April 2010 10:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes!!!! > Right now I will keep readFrom: (reading only ISO8601) and if one day we get > what you propose I would be happy. > Send code :) > Add it to issue tracker and CC to me :) I can't do it right now, since i'm currently busy with my NativeBoost project. >> imo, it should look like: >> >> readFrom: stream >> Â ^ readFrom: stream pattern: ISO8601 >> >> and >> readFrom:pattern: >> >> should parse date by taking an arbitrary pattern into account. >> We could invent own syntax for a pattern, or use other invented ones >> (from C, Perl etc), >> and implement a separate DateTimeParser class. >> >> The messy code like this >> Â aStream peek = $- ifTrue: [ aStream next. bc := -1] ifFalse: [bc := 1]. >> Â Â Â year := (aStream upTo: $-) asInteger * bc. >> Â Â Â month := (aStream upTo: $-) asInteger ifNil: [1]. >> Â Â Â day := (aStream upTo: $T) asInteger ifNil: [1]. >> Â Â Â hour := (aStream upTo: $:) asInteger ifNil: [0]. >> >> should be put in trash! :) >> >> On 24 April 2010 23:05, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> What I did was to stick with the ISO parsing and added a fuzzy readfrom (the previous one in pharo) >>> so that readFrom: read only iso but well and fuzzy tries to find its way with strange input. >>> >>> Stef >>> >>> On Apr 24, 2010, at 9:48 PM, Nicolas Cellier wrote: >>> >>>> 2010/4/24 Julian Fitzell <jfitzell(a)gmail.com>: >>>>> On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse >>>>> <stephane.ducasse(a)free.fr> wrote: >>>>>> >>>>>> What are the expectation for DateAndTime>>readFrom? >>>>> >>>>> Personally, my expectation is that it doesn't exist. :) >>>>> >>>>> To believe that there is a single way of parsing strings into dates (or >>>>> numbers, or anything else) that will be appropriate in all cases is pretty >>>>> silly. It would seem much better to me to have configurable parsing classes. >>>>> >>>>> Julian >>>>> >>>> >>>> Sure, that might be usefull, however current implementation intention >>>> clearly seems related to >>>> http://en.wikipedia.org/wiki/ISO_8601 >>>> >>>> Nicolas >>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 25, 2010

Re: [Pharo-project] Expectation for readFrom:... getting bored to fix bugs.

by StÃ©phane Ducasse

Yes!!!! Right now I will keep readFrom: (reading only ISO8601) and if one day we get what you propose I would be happy. Send code :) > imo, it should look like: > > readFrom: stream > ^ readFrom: stream pattern: ISO8601 > > and > readFrom:pattern: > > should parse date by taking an arbitrary pattern into account. > We could invent own syntax for a pattern, or use other invented ones > (from C, Perl etc), > and implement a separate DateTimeParser class. > > The messy code like this > aStream peek = $- ifTrue: [ aStream next. bc := -1] ifFalse: [bc := 1]. > year := (aStream upTo: $-) asInteger * bc. > month := (aStream upTo: $-) asInteger ifNil: [1]. > day := (aStream upTo: $T) asInteger ifNil: [1]. > hour := (aStream upTo: $:) asInteger ifNil: [0]. > > should be put in trash! :) > > On 24 April 2010 23:05, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> What I did was to stick with the ISO parsing and added a fuzzy readfrom (the previous one in pharo) >> so that readFrom: read only iso but well and fuzzy tries to find its way with strange input. >> >> Stef >> >> On Apr 24, 2010, at 9:48 PM, Nicolas Cellier wrote: >> >>> 2010/4/24 Julian Fitzell <jfitzell(a)gmail.com>: >>>> On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse >>>> <stephane.ducasse(a)free.fr> wrote: >>>>> >>>>> What are the expectation for DateAndTime>>readFrom? >>>> >>>> Personally, my expectation is that it doesn't exist. :) >>>> >>>> To believe that there is a single way of parsing strings into dates (or >>>> numbers, or anything else) that will be appropriate in all cases is pretty >>>> silly. It would seem much better to me to have configurable parsing classes. >>>> >>>> Julian >>>> >>> >>> Sure, that might be usefull, however current implementation intention >>> clearly seems related to >>> http://en.wikipedia.org/wiki/ISO_8601 >>> >>> Nicolas >>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 25, 2010

Re: [Pharo-project] starting to think about 1.1 freeze

by StÃ©phane Ducasse

ok may be we should rollback We should also include the network changes made in 1.0 to roll back IVP6 > WeakKeyDictionary, to be specific. > To be frank, to me the new implementation in 1.1 seems simply broken. > > Cheers, > Henry > > Den 24. apr. 2010 kl. 22.58 skrev "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu>: > >> Stef, >> >> What do you mean by "weak structures?" Weak collections? >> >> Bill >> >> >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse >> Sent: Saturday, April 24, 2010 3:58 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] starting to think about 1.1 freeze >> >> ok but this is still good to know what we could wrap up. >> Now I'm fixing some tests if somebody wants to help there are some problems on weak structures. >> >> Stef >> On Apr 24, 2010, at 10:31 AM, Marcus Denker wrote: >> >>> >>> On Apr 23, 2010, at 8:30 PM, Schwab,Wilhelm K wrote: >>> >>>> Stef, >>>> >>>> I will soon reach a point of missing a way to do callbacks. Alien/FFI is listed among the goals, and I would very much like to see that happen, especially if callbacks are well supported as a result. >>>> >>> >>> But what we should *not* do is to delay the release for that. Releases >>> should be a snapshot of what is already done. 1.1 *as it is now* (minus bugs) is already a huge step forward. If we delay that to make it even better, we will again delay the release for a looong time. >>> >>> I vote for just defininf 1.1 as what 1.1 is *now* and stabilize it. There will be a 1.2 anyway. >>> >>> Marcus >>> >>> >>> >>> -- >>> Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord >>> Europe. Team RMoD. >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 25, 2010

Re: [Pharo-project] saving headless image on Mac

by Yanni Chiu

Tudor Girba wrote: > Hi, > > I am trying to integrate a Pharo image into a continuous integration > system through the command line. For that I need to spawn the image, do > something, save and quit. > > The problem is that on Mac (using 4.2.2beta1U), when I open the > resulting image I get a very tiny window instead of the original size. This has been bothering me for a long time, and Lukas' recent thread on "Change Window Size" pushed me to take a look at it. I found out, just like you, that just the save-and-quit would result in the tiny window. > The command below reveals the problem (save-and-quite-image.st is > attached): > > /Applications/Squeak4.2.2beta1U/Squeak\ > 4.2.2beta1U.app/Contents/MacOS/Squeak\ VM\ Opt -headless Pharo-1.0.image > THE_PATH/save-and-quit-image.st > > Could anyone advise me how to proceed to get around this problem? Since you're on a Mac, could you add a final fix-up step that runs the vm without the "-headless" option, sets the window size, then runs save-and-quit. I added: HostWindowProxy basicNew primitiveWindowSize: 1 x: 1024 y: 786. before the save and quit code. I used another build.sh script that skipped the "-headless" option, and ran the script. As expected, the Pharo window popped up briefly. In the end, I finally have an image that opens up with a reasonable size. -- Yanni

April 25, 2010

Re: [Pharo-project] Expectation for readFrom:... getting bored to fix bugs.

by Igor Stasenko

imo, it should look like: readFrom: stream ^ readFrom: stream pattern: ISO8601 and readFrom:pattern: should parse date by taking an arbitrary pattern into account. We could invent own syntax for a pattern, or use other invented ones (from C, Perl etc), and implement a separate DateTimeParser class. The messy code like this aStream peek = $- ifTrue: [ aStream next. bc := -1] ifFalse: [bc := 1]. year := (aStream upTo: $-) asInteger * bc. month := (aStream upTo: $-) asInteger ifNil: [1]. day := (aStream upTo: $T) asInteger ifNil: [1]. hour := (aStream upTo: $:) asInteger ifNil: [0]. should be put in trash! :) On 24 April 2010 23:05, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > What I did was to stick with the ISO parsing and added a fuzzy readfrom (the previous one in pharo) > so that readFrom: read only iso but well and fuzzy tries to find its way with strange input. > > Stef > > On Apr 24, 2010, at 9:48 PM, Nicolas Cellier wrote: > >> 2010/4/24 Julian Fitzell <jfitzell(a)gmail.com>: >>> On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse >>> <stephane.ducasse(a)free.fr> wrote: >>>> >>>> What are the expectation for DateAndTime>>readFrom? >>> >>> Personally, my expectation is that it doesn't exist. :) >>> >>> To believe that there is a single way of parsing strings into dates (or >>> numbers, or anything else) that will be appropriate in all cases is pretty >>> silly. It would seem much better to me to have configurable parsing classes. >>> >>> Julian >>> >> >> Sure, that might be usefull, however current implementation intention >> clearly seems related to >> http://en.wikipedia.org/wiki/ISO_8601 >> >> Nicolas >> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 25, 2010

Re: [Pharo-project] Expectation for readFrom:... getting bored to fix bugs.

by csrabak＠bol.com.br

Then a more appropriate class would be ISO8601DateAndTime for this method to remain in Pharo? -- Cesar Rabak Em 24/04/2010 16:48, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com > escreveu: 2010/4/24 Julian Fitzell : > On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse > wrote: >> >> What are the expectation for DateAndTime>>readFrom? > > Personally, my expectation is that it doesn't exist. :) > > To believe that there is a single way of parsing strings into dates (or > numbers, or anything else) that will be appropriate in all cases is pretty > silly. It would seem much better to me to have configurable parsing classes. > > Julian > Sure, that might be usefull, however current implementation intention clearly seems related to http://en.wikipedia.org/wiki/ISO_8601 Nicolas > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 25, 2010

[Pharo-project] saving headless image on Mac

by Tudor Girba

Hi, I am trying to integrate a Pharo image into a continuous integration system through the command line. For that I need to spawn the image, do something, save and quit. The problem is that on Mac (using 4.2.2beta1U), when I open the resulting image I get a very tiny window instead of the original size. The command below reveals the problem (save-and-quite-image.st is attached): /Applications/Squeak4.2.2beta1U/Squeak\ 4.2.2beta1U.app/Contents/MacOS/ Squeak\ VM\ Opt -headless Pharo-1.0.image THE_PATH/save-and-quit- image.st Could anyone advise me how to proceed to get around this problem? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow."

April 24, 2010

Re: [Pharo-project] starting to think about 1.1 freeze

by Schwab,Wilhelm K

Not to be inflammatory, the weak collections have been broken all along. They are not thread safe, and so cannot hope to be adequately cleaned as objects are finalized. My efforts to compensate have been aimed at clearing away nils that are left behind. If the weak collection itself is busted (holds too strongly??), then my additions are not going to help. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Johansen Sent: Saturday, April 24, 2010 5:07 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] starting to think about 1.1 freeze WeakKeyDictionary, to be specific. To be frank, to me the new implementation in 1.1 seems simply broken. Cheers, Henry Den 24. apr. 2010 kl. 22.58 skrev "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu >: > Stef, > > What do you mean by "weak structures?" Weak collections? > > Bill > > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- > project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Saturday, April 24, 2010 3:58 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] starting to think about 1.1 freeze > > ok but this is still good to know what we could wrap up. > Now I'm fixing some tests if somebody wants to help there are some > problems on weak structures. > > Stef > On Apr 24, 2010, at 10:31 AM, Marcus Denker wrote: > >> >> On Apr 23, 2010, at 8:30 PM, Schwab,Wilhelm K wrote: >> >>> Stef, >>> >>> I will soon reach a point of missing a way to do callbacks. Alien/ >>> FFI is listed among the goals, and I would very much like to see >>> that happen, especially if callbacks are well supported as a result. >>> >> >> But what we should *not* do is to delay the release for that. >> Releases >> should be a snapshot of what is already done. 1.1 *as it is now* >> (minus bugs) is already a huge step forward. If we delay that to make >> it even better, we will again delay the release for a looong time. >> >> I vote for just defininf 1.1 as what 1.1 is *now* and stabilize it. >> There will be a 1.2 anyway. >> >> Marcus >> >> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord >> Europe. Team RMoD. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 24, 2010