- Pharo-dev - lists.pharo.org

pattern for configuration definition

by StÃ©phane Ducasse

Hi camillo I like the pattern damien told me you are applying for your configuration. Could you explain them? I understood: baseline48: spec <version: '4.8-baseline'> spec repository: 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. â¦ spec project: 'Metanool' with: [ spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. â¦ => baseline48: spec <version: '4.8-baseline'> spec repository: self repositoryUrlString â¦ spec project: 'Metanool' with: [ spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. â¦ repositoryUrlString ^ 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. specMetanoolConfiguration: spec spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' I like the idea to avoid duplication at the configuration level. Now damien mention a dev and stable baseline Stef

Aug. 10, 2013

Re: [Pharo-dev] Keyboard events is broken.

by StÃ©phane Ducasse

I will retry and be careful about which vm I use because I had around 3/4 images open to tests snapshotcello. So I may have open it with the old one. Stef > yes, this latest vm should have the problem solved > > On Aug 9, 2013, at 6:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Aug 7, 2013, at 7:06 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: >> >>> >>> On Aug 7, 2013, at 5:59 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>> >>>> now can we get a working keyboard? >>> Yes here >>> >>> Hi, >>> >>> Guille built a new vm with an attept of fixing the key combinations problem. >>> Can you test it? >>> >>> http://files.pharo.org/vm/pharo/ >>> >>> (and pick the latest for your platform) >>> >>> Thanks, >>> Esteban >>> >> Esteban did this vm get the fix for SmallInteger? >> Because in the latest moose image >> >> (ConfigurationOfMoose project version: #development) record >> led to problem >> >> Stef >> >

Aug. 9, 2013

Re: [Pharo-dev] Consequence of NBExternalStructure refactorings

by StÃ©phane Ducasse

>> >>> well if the bug entry is not tag as ready to include the chance to get it loaded is really low. >>> If people do not pay attention to basics like thatâ¦.We will not make progress. >>> >> it is not ready yet because it is not ready. i will tag it when it will. >> > i meant not *tagged* ready on purpose. ok :)

Aug. 9, 2013

Re: [Pharo-dev] Keyboard events is broken.

by Esteban Lorenzano

yes, this latest vm should have the problem solved On Aug 9, 2013, at 6:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 7, 2013, at 7:06 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > >> >> On Aug 7, 2013, at 5:59 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> now can we get a working keyboard? >> Yes here >> >> Hi, >> >> Guille built a new vm with an attept of fixing the key combinations problem. >> Can you test it? >> >> http://files.pharo.org/vm/pharo/ >> >> (and pick the latest for your platform) >> >> Thanks, >> Esteban >> > Esteban did this vm get the fix for SmallInteger? > Because in the latest moose image > > (ConfigurationOfMoose project version: #development) record > led to problem > > Stef >

Aug. 9, 2013

Re: [Pharo-dev] Consequence of NBExternalStructure refactorings

by Igor Stasenko

On 9 August 2013 18:04, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 9 August 2013 17:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> well if the bug entry is not tag as ready to include the chance to get it loaded is really low. >> If people do not pay attention to basics like thatâ¦.We will not make progress. >> > it is not ready yet because it is not ready. i will tag it when it will. > i meant not *tagged* ready on purpose. >> Stef >> >> On Aug 9, 2013, at 5:18 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> Hello, >>> >>> lately we changed the object format of subject class from variableByte >>> to normal one. >>> >>> All projects which using NBExternalStructure can meet certain problems with it, >>> and first which comes is that it may load code cleanly but in fact >>> result in bogus >>> variable subclasses of NBExternalStructure , while it can't because >>> superclass has instance variable. >>> (i suspecting classbuilder bug, but need to verify first). >>> >>> To address that, you need to manually go over all subclasses and double-check. >>> >>> Another thing: since now instances NBExternalStructure can also point >>> to external memory, >>> special care should be taken for #copying. >>> Sending #copy to instance which uses external memory, will create a >>> copy on object memory >>> (and copy all data from external memory into it). This is same >>> behavior as in NBExternalArray. >>> >>> - there is a bugs in #initialize and #postCopy (fixed but not intergated yet) >>> https://pharo.fogbugz.com/default.asp?11395#83020 >>> will do that in nearest time. >>> >>> also note, that in callouts, you cannot pass an instance of >>> NBExternalStructure anymore >>> to function, which uses raw pointer (like void*) anymore. >>> >>> For passing a pointer to structure data for callouts, use >>> myStructure address >>> idiom (or use right struct type, which is preferable). >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

Aug. 9, 2013

Re: [Pharo-dev] Consequence of NBExternalStructure refactorings

by Igor Stasenko

On 9 August 2013 17:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > well if the bug entry is not tag as ready to include the chance to get it loaded is really low. > If people do not pay attention to basics like thatâ¦.We will not make progress. > it is not ready yet because it is not ready. i will tag it when it will. > Stef > > On Aug 9, 2013, at 5:18 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Hello, >> >> lately we changed the object format of subject class from variableByte >> to normal one. >> >> All projects which using NBExternalStructure can meet certain problems with it, >> and first which comes is that it may load code cleanly but in fact >> result in bogus >> variable subclasses of NBExternalStructure , while it can't because >> superclass has instance variable. >> (i suspecting classbuilder bug, but need to verify first). >> >> To address that, you need to manually go over all subclasses and double-check. >> >> Another thing: since now instances NBExternalStructure can also point >> to external memory, >> special care should be taken for #copying. >> Sending #copy to instance which uses external memory, will create a >> copy on object memory >> (and copy all data from external memory into it). This is same >> behavior as in NBExternalArray. >> >> - there is a bugs in #initialize and #postCopy (fixed but not intergated yet) >> https://pharo.fogbugz.com/default.asp?11395#83020 >> will do that in nearest time. >> >> also note, that in callouts, you cannot pass an instance of >> NBExternalStructure anymore >> to function, which uses raw pointer (like void*) anymore. >> >> For passing a pointer to structure data for callouts, use >> myStructure address >> idiom (or use right struct type, which is preferable). >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Aug. 9, 2013

Re: [Pharo-dev] Keyboard events is broken.

by StÃ©phane Ducasse

On Aug 7, 2013, at 7:06 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > > On Aug 7, 2013, at 5:59 PM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> now can we get a working keyboard? > Yes here > > Hi, > > Guille built a new vm with an attept of fixing the key combinations problem. > Can you test it? > > http://files.pharo.org/vm/pharo/ > > (and pick the latest for your platform) > > Thanks, > Esteban > Esteban did this vm get the fix for SmallInteger? Because in the latest moose image (ConfigurationOfMoose project version: #development) record led to problem Stef

Aug. 9, 2013

Re: [Pharo-dev] Consequence of NBExternalStructure refactorings

by StÃ©phane Ducasse

well if the bug entry is not tag as ready to include the chance to get it loaded is really low. If people do not pay attention to basics like thatâ¦.We will not make progress. Stef On Aug 9, 2013, at 5:18 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hello, > > lately we changed the object format of subject class from variableByte > to normal one. > > All projects which using NBExternalStructure can meet certain problems with it, > and first which comes is that it may load code cleanly but in fact > result in bogus > variable subclasses of NBExternalStructure , while it can't because > superclass has instance variable. > (i suspecting classbuilder bug, but need to verify first). > > To address that, you need to manually go over all subclasses and double-check. > > Another thing: since now instances NBExternalStructure can also point > to external memory, > special care should be taken for #copying. > Sending #copy to instance which uses external memory, will create a > copy on object memory > (and copy all data from external memory into it). This is same > behavior as in NBExternalArray. > > - there is a bugs in #initialize and #postCopy (fixed but not intergated yet) > https://pharo.fogbugz.com/default.asp?11395#83020 > will do that in nearest time. > > also note, that in callouts, you cannot pass an instance of > NBExternalStructure anymore > to function, which uses raw pointer (like void*) anymore. > > For passing a pointer to structure data for callouts, use > myStructure address > idiom (or use right struct type, which is preferable). > > -- > Best regards, > Igor Stasenko. >

Aug. 9, 2013

Re: [Pharo-dev] Fwd: Consequence of NBExternalStructure refactorings

by Martin Dias

On Fri, Aug 9, 2013 at 5:18 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hello, > > lately we changed the object format of subject class from variableByte > to normal one. > > All projects which using NBExternalStructure can meet certain problems > with it, > and first which comes is that it may load code cleanly but in fact > result in bogus > variable subclasses of NBExternalStructure , while it can't because > superclass has instance variable. > > (i suspecting classbuilder bug, but need to verify first). > I can help with classbuilder if you confirm the bug cheers, MartÃn

Aug. 9, 2013

Fwd: Consequence of NBExternalStructure refactorings

by Igor Stasenko

Hello, lately we changed the object format of subject class from variableByte to normal one. All projects which using NBExternalStructure can meet certain problems with it, and first which comes is that it may load code cleanly but in fact result in bogus variable subclasses of NBExternalStructure , while it can't because superclass has instance variable. (i suspecting classbuilder bug, but need to verify first). To address that, you need to manually go over all subclasses and double-check. Another thing: since now instances NBExternalStructure can also point to external memory, special care should be taken for #copying. Sending #copy to instance which uses external memory, will create a copy on object memory (and copy all data from external memory into it). This is same behavior as in NBExternalArray. - there is a bugs in #initialize and #postCopy (fixed but not intergated yet) https://pharo.fogbugz.com/default.asp?11395#83020 will do that in nearest time. also note, that in callouts, you cannot pass an instance of NBExternalStructure anymore to function, which uses raw pointer (like void*) anymore. For passing a pointer to structure data for callouts, use myStructure address idiom (or use right struct type, which is preferable). -- Best regards, Igor Stasenko.

Aug. 9, 2013