July 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Why does CompiledMethod>>hasLiteral: use ==

by StÃ©phane Ducasse

tx for this good reflex! Stef > > Eliot Miranda-2 wrote: >> >> I've run all the tests in a trunk 4.2 before and after and making the >> above >> change makes no difference. So I think I'll go ahead and commit the >> change >> to Squeak trunk. I'll leave the Pharo folks to apply it there-in. Files >> attached. >> > > I created Pharo issue #4538 and attached the file. > > SD > > -- > View this message in context: http://forum.world.st/Why-does-CompiledMethod-hasLiteral-use-tp3676573p3679… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

July 20, 2011

Re: [Pharo-project] [update 1.4] #14050

by StÃ©phane Ducasse

On Jul 19, 2011, at 7:09 PM, Torsten Bergmann wrote: > Pavel wrote: >> is there some paper about Ring? > > see http://goo.gl/7Er5O > > Stef: would it be possible to add the URL's to the > update notes as we discussed in May in thread > "Linking Update Mails to issue tracker" yes and this is what we are trying to do. Now ring fixes where not entered in bug entries because we were hot fixing. Stef > > Thx and Bye > T. > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >

July 20, 2011

Re: [Pharo-project] why isEmptyOrNil is not defined in Object?

by StÃ©phane Ducasse

On Jul 19, 2011, at 2:57 PM, Nicolas Cellier wrote: > "deprecate it" was a bit provocative, and would be hard to achieve now. > But you agree that we gratuitously complexified a legacy simple interface, while there were smoother, and IMO more elegant solutions, don't you? probably. Now we can deprecate it. I think that this is important to have a process and state of mind that ack that errors are not a problem but a way to learn (even if this is a slower way than doing right the first time). > Nicolas > > 2011/7/19 Esteban Lorenzano <estebanlm(a)gmail.com> > well... I use it a lot... yes, mainly for "FillInTheBlank". > In fact, I usually add it to my programs... > however, I'm not sure if we have to deprecate it (and replace for a larger code), or adopt it :) > > cheers, > Esteban > > El 19/07/2011, a las 7:14a.m., Nicolas Cellier escribiÃ³: > >> I don't like isEmptyOrNil. >> It has been introduced mainly because we can now distinguish these two operations in a "FillInTheBlank" >> - cancel returns nil >> - accept returns a String eventually empty >> The original implementation did always return an empty String even if cancel was pressed. >> >> But no application is really prepared to deal with nil, and most did interpret an empty String as a cancel. >> So we replaced the isEmpty checks by isEmptyOrNil... >> >> I would have done it differently: >> 1) let the default return an empty String even if cancelled >> 2) provide a ifCancelled: addtional key for the rare apps which really need to distinguish. >> >> UIManager default request: 'OK ?' initialAnswer: '' ifCancelled: [^nil]. >> >> Default behaviour would be equivalent to >> UIManager default request: 'OK ?' initialAnswer: '' ifCancelled: ['']. >> >> So my take would be to deprecate it. >> >> Nicolas >> >> 2011/7/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> Hi guys >> >> I'm puzzled and probably need food. but why isEmptyOrNil is not defined in Object? >> because right now if a variable is '' or nil or something else I cannot use it. >> >> Stef >> > >

July 20, 2011

Re: [Pharo-project] fun bug: fileouting method with a $!, produces $!!

by StÃ©phane Ducasse

My requirements: no scanner to access metadata explicit first class definition to build better tools - need class definition (so that we can remove do it on reply) like in VW. - package definition - declarative syntax of action I would prefer to have an object instead of a message for recategorization so that tool can manipulate objects and not their implementation copy and pasteable close to coding in emacs (in the sense that it would be nice to have a scripting syntax also used in chunk) cf coral http://rmod.lille.inria.fr/coral

July 20, 2011

[Pharo-project] UUIDs not so unique

by Igor Stasenko

On 20 July 2011 18:58, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Igor, (Hi Phillipe) > Â Â Â yes, I see the bug in the linux Cog VMs. Â I went to > http://code.google.com/p/pharo/issues/detail?id=4541Â but I don't see any > fix. Â Can you point me to the fix and I'll integrate and roll out new VMs > ASAP. > TIA > Here: https://gitorious.org/cogvm/blessed/commit/4a3f8bf9f560c19b167ee1b3d5ab6c52… > On Wed, Jul 20, 2011 at 8:51 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 20 July 2011 16:27, Torsten Bergmann <astares(a)gmx.de> wrote: >> > Igor wrote: >> >>Feel free to submit an additional test for UUID to prevent this >> >>regression in a future. >> > >> > I already provided such a test in my previous post: >> > >> > >> > http://lists.gforge.inria.fr/pipermail/pharo-project/2011-July/051481.html >> > >> > and now there is a fixed issue ready for integration >> > >> > http://code.google.com/p/pharo/issues/detail?id=4541 >> > >> Thanks, Torsten. >> >> > Nothing more to do on Pharo side than integration this test case >> > into one of the next updates. >> > >> > >> > But the VM maintainers should fix the issue for the VM >> > Phillipe used. >> > >> i will check the unix configs for Cog VMs. >> But since Philippe using Eliot's builds, then he should wait till >> Eliot integrate it (hoping that Eliot reads this mailing list and >> corresponding topic). >> >> > Bye >> > T. >> > -- >> > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! >> > Jetzt informieren: http://www.gmx.net/de/go/freephone >> > >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > best, > Eliot > -- Best regards, Igor Stasenko AKA sig.

July 20, 2011

Re: [Pharo-project] [update 1.4] #14050

by StÃ©phane Ducasse

July 20, 2011

Re: [Pharo-project] UUIDs not so unique

by Eliot Miranda

Hi Igor, (Hi Phillipe) yes, I see the bug in the linux Cog VMs. I went to http://code.google.com/p/pharo/issues/detail?id=4541 but I don't see any fix. Can you point me to the fix and I'll integrate and roll out new VMs ASAP. TIA On Wed, Jul 20, 2011 at 8:51 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 20 July 2011 16:27, Torsten Bergmann <astares(a)gmx.de> wrote: > > Igor wrote: > >>Feel free to submit an additional test for UUID to prevent this > >>regression in a future. > > > > I already provided such a test in my previous post: > > > > > http://lists.gforge.inria.fr/pipermail/pharo-project/2011-July/051481.html > > > > and now there is a fixed issue ready for integration > > > > http://code.google.com/p/pharo/issues/detail?id=4541 > > > Thanks, Torsten. > > > Nothing more to do on Pharo side than integration this test case > > into one of the next updates. > > > > > > But the VM maintainers should fix the issue for the VM > > Phillipe used. > > > i will check the unix configs for Cog VMs. > But since Philippe using Eliot's builds, then he should wait till > Eliot integrate it (hoping that Eliot reads this mailing list and > corresponding topic). > > > Bye > > T. > > -- > > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! > > Jetzt informieren: http://www.gmx.net/de/go/freephone > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- best, Eliot

July 20, 2011

Re: [Pharo-project] why isEmptyOrNil is not defined in Object?

by StÃ©phane Ducasse

July 20, 2011

Re: [Pharo-project] UUIDs not so unique

by Igor Stasenko

On 20 July 2011 17:31, Levente Uzonyi <leves(a)elte.hu> wrote: > On Wed, 20 Jul 2011, Igor Stasenko wrote: > >> I changed the MakeUUID in sqUnixUUID.c to look like following: > > This change is useless IMHO. Instead of stopping the compilation, either > return 0 from the function, so the primitive will fail, or fix the included > header files for Darwin, which has uuid_generate > (http://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPa… > ). But the best solution is using the Mac OS platform files instead of the > Unix ones for Mac OS. > Right, that's why i pointed Esteban to use mac-specific functions. Well, the problem was initially reported for unix builds. And why stopping compilation useless? It indicating the configuration error, while if we do as you proposing, then prim will always fail and UUID will work.. but then its a question, why we need uuid plugin at all, if it's not using any function for generating uuids? I prefer to have compilation error, than useless and malfunctioning plugin which does nothing. > > Levente > >> >> >> >> int MakeUUID(char *location) >> { >> Â uuid_t uuid; >> >> #if defined(HAVE_UUIDGEN) >> Â uuidgen(&uuid, 1); >> #elif defined(HAVE_UUID_GENERATE) >> Â uuid_generate(uuid); >> #else >> #error "No uuid function provided" >> #endif >> >> Â memcpy((void *)location, (void *)&uuid, sizeof(uuid)); >> Â return 1; >> } >> >> >> and during compiling cocoa vms it fails with error. >> And before change the code was looking like following: >> >> int MakeUUID(char *location) >> { >> Â uuid_t uuid; >> >> #if defined(HAVE_UUIDGEN) >> Â uuidgen(&uuid, 1); >> #elif defined(HAVE_UUID_GENERATE) >> Â uuid_generate(uuid); >> #endif >> >> Â memcpy((void *)location, (void *)&uuid, sizeof(uuid)); >> Â return 1; >> } >> >> which means that if none HAVE_UUIDGEN or HAVE_UUID_GENERATE is >> defined, then there is nothing got called >> and memcpy then returns a random values on stack, copied from uuid to >> locaiton. >> >> And first version of that file just contains : >> >> >> int MakeUUID(char *location) >> { >> Â uuid_t uuid; >> Â uuid_generate(uuid); >> Â memcpy((void *)location, (void *)&uuid, sizeof(uuid)); >> Â return 1; >> } >> >> and then changed to: >> >> #if defined(__NetBSD__) >> Â uuidgen(&uuid, 1); >> #else >> Â uuid_generate(uuid); >> #endif >> >> and then changed to: >> >> #if defined(HAVE_UUIDGEN) >> Â uuidgen(&uuid, 1); >> #elif defined(HAVE_UUID_GENERATE) >> Â uuid_generate(uuid); >> #endif >> >> Blame: >> Merge Levente's linux UUIDPlugin fix. Fix tickerSleepCycle decl in >> heartbeat. Restore -O2 optimization for the interpreter. >> >> Author: eliot >> Date: Â 5 months ago >> Commit: 757297f62c32eaf2af7f26ce66aa6499df776749 >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > -- Best regards, Igor Stasenko AKA sig.

July 20, 2011

Re: [Pharo-project] UUIDs not so unique

by Igor Stasenko

On 20 July 2011 16:27, Torsten Bergmann <astares(a)gmx.de> wrote: > Igor wrote: >>Feel free to submit an additional test for UUID to prevent this >>regression in a future. > > I already provided such a test in my previous post: > > http://lists.gforge.inria.fr/pipermail/pharo-project/2011-July/051481.html > > and now there is a fixed issue ready for integration > > http://code.google.com/p/pharo/issues/detail?id=4541 > Thanks, Torsten. > Nothing more to do on Pharo side than integration this test case > into one of the next updates. > > > But the VM maintainers should fix the issue for the VM > Phillipe used. > i will check the unix configs for Cog VMs. But since Philippe using Eliot's builds, then he should wait till Eliot integrate it (hoping that Eliot reads this mailing list and corresponding topic). > Bye > T. > -- > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! > Jetzt informieren: http://www.gmx.net/de/go/freephone > > -- Best regards, Igor Stasenko AKA sig.

July 20, 2011