September 2016 - Pharo-users

Re: [Pharo-users] [Pharo-dev] Planning: Pharo Sprints Lille for the rest 2016

by Dimitris Chloupis

I feel experienced enough to join you this time, hope you do slack channel communication because I wont be able to physical attend but I will be available online. I am mostly interested in working on GUI things. On Wed, Sep 7, 2016 at 6:01 PM Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 07 Sep 2016, at 13:05, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > Hi > > > > Here locally we try to organise one âSprintâ per month were we meet to > work on > > boring issue tracker entries together. (external visitors are welcome!) > > > > In the past people organised local sprints at other places at the sane > time (e.g. Santiago/Chile). > > > > The next dates are: > > > > 30 September > > 28 October > This has been moved to 4th November due to holidays > > > 25 November > > 16 December. Pharo Christmas Party! > > > > > > Marcus > > > > >

Sept. 7, 2016

Re: [Pharo-users] UFFI documentation state

by Ben Coman

On Wed, Sep 7, 2016 at 9:12 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Kilon, > > documentation is âongoingâ, but I think the only way I will actually finish > it is by answering questions from people (Iâve been pasting there the > answers I give also in the list). So I would ask you to take a look into the > doc and make all the questions that you wantâ¦ so I answer, and I will be > closer to finish :) > > https://github.com/SquareBracketAssociates/PharoInProgress/blob/master/Unif… That doc is certainly off to a good start. Its what I was using ... enough to get me far enough along to start asking questions :P cheers -ben > > cheers, > Esteban > > On 07 Sep 2016, at 15:01, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Hey Esteban hows the documentation for UFFI going ? I will most likely go > down the Memory Mapped File (Shared Memory) for uniting Pharo with Unreal > instead of making a Pharo to C++ compiler since it will be much simpler for > me but I will need the FFI. Is it stable enough both FFI and its > documentation or should I wait more ? > >

Sept. 7, 2016

Re: [Pharo-users] UFFI cleanup of externally allocated memory (was Re: UFFI const, unsigned, opaque-ish types)

by Ben Coman

On Wed, Sep 7, 2016 at 10:42 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Wed, Sep 7, 2016 at 9:09 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> On 07 Sep 2016, at 14:56, Ben Coman <btc(a)openInWorld.com> wrote: >> >> On Tue, Sep 6, 2016 at 8:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> Hi, >> >> sorry for arriving so late to this, but I was on holidays :) >> this is how autoRelease works: >> >> 1) #autoRelease of an object registers object for finalisation with a >> particular executor. Then behaviour is divided: >> >> 2.1.1) for ExternalAddresses, it just registers in regular way, who will >> call #finalize on GC >> 2.1.2) finalize will just call a free assuming ExternalAddress was allocated >> (which is a malloc) >> >> 2.2.1) for all FFIExternalReference, it will register for finalisation what >> #resourceData answers (normally, the handle of the object) >> 2.2.2) finalisation process will call the object >> class>>#finalizeResourceData: method, with the #resourceData result as >> parameter >> 2.2.3) each kind of external reference can decide how to free that data (by >> default is also just freeing). >> >> An example of this is how CairoFontFace works (or AthensCairoSurface). >> >> >> >> At the bottom of FFIExternalResourceExecutor class comment I read... >> "Note that in #finalizeResourceData: you cannot >> access any other properties of your instance, >> since it is already garbage collected." >> >> But in my experiments it seems okay to access instance variables in >> #finalize. >> For example... >> >> CXString >> autoRelease >> self class finalizationRegistry add: self >> >> CXString >> finalize >> Transcript crShow: 'Finalizing CXString ' ; show: self private_flags. >> self dispose. >> Transcript show: ', done!'. >> >> CXString >>private_flags >> "This method was automatically generated" >> ^handle unsignedLongAt: 5 >> >> Libclang getClangVersion autoRelease. >> Smalltalk garbageCollect. >> "==> Finalizing CXString 1, done! " >> >> >> Is this an unlucky coincidence? Or maybe something changed from NB >> to UFFI? (There is a reference to NB there) >> >> >> yes, is a coincidence. >> the idea of using #finalizeResourceData: is that you keep minimal >> information (in general, just the handle)â¦ this way we ensure instances will >> be collected because we will not have circular references (preventing the >> weakregistry to work). >> >> In general, you can always implement as you did it, but I would prefer the >> #finalizeResourceData: approach, even for structures. >> The only reason it is not implemented is because I didnât reach the >> necessity, then I just skipped it (not in purpose, it was not in my head >> :P), but now is a good moment to implement itâ¦ if you want it :) > > Thanks for the offer, but hold off for the moment. I think I actually > need more than just finalization session management. To get a real > displayable string requires calling the clang_getCString() library > function. I imagine I'd like to call this from CXString>>printOn: -- > but this of course this would break after restarting the image. > > extern "C" { > const char *clang_getCString(CXString string) { > .... > return static_cast<const char *>(string.data); > }} > > typedef struct { > const void *data; > unsigned private_flags; > } CXString; > > So I think I need to register CXString with SessionManager to set *data <-- 0 > on startup. > > An alternative might be adding a session variable to CXString, > FFIExternalStructure subclass: #CXString > instanceVariableNames: 'session' > classVariableNames: '' > poolDictionaries: 'CXStringFlag' > package: 'Libclang' > > except doing so crashes when calling.... > getClangVersion > ^ self ffiCall: #( CXString clang_getClangVersion () ) module: Libclang So this worked... CXString >> resetData handle unsignedLongAt: 1 put: 0. CXString class >> startUp: resuming resuming ifTrue: [ self allInstances do: [ :cxs | cxs resetData ] ]. CXString class >> initialize "self initialize" SessionManager default registerSystemClassNamed: self name Now immediate after a save/restart, doing... CXString allInstances first getString "==> UndefinedObject(nil)" instead of crashing the VM. Can you see/guess any traps hidden from me? Now I wonder early it is practical to prioritise such a reset. My first thought is at least before #printString starts getting called ?? cheers -ben

Sept. 7, 2016

Re: [Pharo-users] Spec: InputWidget question

by Johan Fabry

Hi Brad, the magic of the OK and Cancel buttons is due to the opening of the UI with openDialogWithSpec (instead of openWithSpec). There is info on that in the Spec documentation, in the âManaging Windowsâ chapter (which I finished last week :-) ). You can find a pdf of that chapter here: https://ci.inria.fr/pharo-contribution/view/Books/job/BuildingUIWithSpec/la… HTH -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On Sep 6, 2016, at 18:14, Brad Selfridge <bsselfridge(a)gmail.com> wrote: > > I've been trying for several days to get the Spec InputWidget to work as > expected. I've been running the "example2" example. If you enter text in > the input field and press the "enter" key, then the input text is returned. > But, if you click the "Ok" button rather than "enter" key, then the input > text field is empty. I've tried to dig into why, but I stymied. > > Can someone please help me with this? > > > > ----- > Brad Selfridge > -- > View this message in context: http://forum.world.st/Spec-InputWidget-question-tp4914439.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Sept. 7, 2016

Re: [Pharo-users] Planning: Pharo Sprints Lille for the rest 2016

by Marcus Denker

> On 07 Sep 2016, at 13:05, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi > > Here locally we try to organise one âSprintâ per month were we meet to work on > boring issue tracker entries together. (external visitors are welcome!) > > In the past people organised local sprints at other places at the sane time (e.g. Santiago/Chile). > > The next dates are: > > 30 September > 28 October This has been moved to 4th November due to holidays > 25 November > 16 December. Pharo Christmas Party! > > > Marcus >

Sept. 7, 2016

Spur problem?

by Usman Bhatti

Hi, While working on a Pharo 5 image for 3-4 hours, I got an image crash and I was no more able to start the image from the UI interface. When starting the image from the command line I got the following error: Pharo(50871,0xa02c91a8) malloc: *** error for object 0x1af7a04: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug fish: '/Users/ubhatti/temp/vm-spur/Phaâ¦' terminated by signal SIGBUS (Misaligned address error). The image is about 973 Mb (Moose + seaside + a model for a big industrial software). This message might not go beyond reporting an error that I do not know how to produce neither can I share the image (it contains client proprietary software model and hence we are restricted). Just to let you know that there was a problem and n ask if someone has encountered it before? regards. Usman

Sept. 7, 2016

Re: [Pharo-users] UFFI cleanup of externally allocated memory (was Re: UFFI const, unsigned, opaque-ish types)

by Ben Coman

On Wed, Sep 7, 2016 at 9:09 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 07 Sep 2016, at 14:56, Ben Coman <btc(a)openInWorld.com> wrote: > > On Tue, Sep 6, 2016 at 8:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > Hi, > > sorry for arriving so late to this, but I was on holidays :) > this is how autoRelease works: > > 1) #autoRelease of an object registers object for finalisation with a > particular executor. Then behaviour is divided: > > 2.1.1) for ExternalAddresses, it just registers in regular way, who will > call #finalize on GC > 2.1.2) finalize will just call a free assuming ExternalAddress was allocated > (which is a malloc) > > 2.2.1) for all FFIExternalReference, it will register for finalisation what > #resourceData answers (normally, the handle of the object) > 2.2.2) finalisation process will call the object > class>>#finalizeResourceData: method, with the #resourceData result as > parameter > 2.2.3) each kind of external reference can decide how to free that data (by > default is also just freeing). > > An example of this is how CairoFontFace works (or AthensCairoSurface). > > > > At the bottom of FFIExternalResourceExecutor class comment I read... > "Note that in #finalizeResourceData: you cannot > access any other properties of your instance, > since it is already garbage collected." > > But in my experiments it seems okay to access instance variables in > #finalize. > For example... > > CXString >> autoRelease > self class finalizationRegistry add: self > > CXString >> finalize > Transcript crShow: 'Finalizing CXString ' ; show: self private_flags. > self dispose. > Transcript show: ', done!'. > > CXString >>private_flags > "This method was automatically generated" > ^handle unsignedLongAt: 5 > > Libclang getClangVersion autoRelease. > Smalltalk garbageCollect. > "==> Finalizing CXString 1, done! " > > > Is this an unlucky coincidence? Or maybe something changed from NB > to UFFI? (There is a reference to NB there) > > > yes, is a coincidence. > the idea of using #finalizeResourceData: is that you keep minimal > information (in general, just the handle)â¦ this way we ensure instances will > be collected because we will not have circular references (preventing the > weakregistry to work). > > In general, you can always implement as you did it, but I would prefer the > #finalizeResourceData: approach, even for structures. > The only reason it is not implemented is because I didnât reach the > necessity, then I just skipped it (not in purpose, it was not in my head > :P), but now is a good moment to implement itâ¦ if you want it :) Thanks for the offer, but hold off for the moment. I think I actually need more than just finalization session management. To get a real displayable string requires calling the clang_getCString() library function. I imagine I'd like to call this from CXString>>printOn: -- but this of course this would break after restarting the image. extern "C" { const char *clang_getCString(CXString string) { .... return static_cast<const char *>(string.data); }} typedef struct { const void *data; unsigned private_flags; } CXString; So I think I need to register CXString with SessionManager to set *data <-- 0 on startup. An alternative might be adding a session variable to CXString, FFIExternalStructure subclass: #CXString instanceVariableNames: 'session' classVariableNames: '' poolDictionaries: 'CXStringFlag' package: 'Libclang' except doing so crashes when calling.... getClangVersion ^ self ffiCall: #( CXString clang_getClangVersion () ) module: Libclang cheers -ben

Sept. 7, 2016

Re: [Pharo-users] UFFI documentation state

by Dimitris Chloupis

perfect I will take look and ask all the questions I need answered and I can also document my answers since I am familiar with Pillar as a UPBE contributor. Thanks :) On Wed, Sep 7, 2016 at 4:13 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Kilon, > > documentation is âongoingâ, but I think the only way I will actually > finish it is by answering questions from people (Iâve been pasting there > the answers I give also in the list). So I would ask you to take a look > into the doc and make all the questions that you wantâ¦ so I answer, and I > will be closer to finish :) > > > https://github.com/SquareBracketAssociates/PharoInProgress/blob/master/Unif… > > cheers, > Esteban > > On 07 Sep 2016, at 15:01, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Hey Esteban hows the documentation for UFFI going ? I will most likely go > down the Memory Mapped File (Shared Memory) for uniting Pharo with Unreal > instead of making a Pharo to C++ compiler since it will be much simpler for > me but I will need the FFI. Is it stable enough both FFI and its > documentation or should I wait more ? > > >

Sept. 7, 2016

Re: [Pharo-users] UFFI documentation state

by Esteban Lorenzano

Hi Kilon, documentation is âongoingâ, but I think the only way I will actually finish it is by answering questions from people (Iâve been pasting there the answers I give also in the list). So I would ask you to take a look into the doc and make all the questions that you wantâ¦ so I answer, and I will be closer to finish :) https://github.com/SquareBracketAssociates/PharoInProgress/blob/master/Unif… <https://github.com/SquareBracketAssociates/PharoInProgress/blob/master/Unif…> cheers, Esteban > On 07 Sep 2016, at 15:01, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Hey Esteban hows the documentation for UFFI going ? I will most likely go down the Memory Mapped File (Shared Memory) for uniting Pharo with Unreal instead of making a Pharo to C++ compiler since it will be much simpler for me but I will need the FFI. Is it stable enough both FFI and its documentation or should I wait more ?

Sept. 7, 2016

Re: [Pharo-users] UFFI cleanup of externally allocated memory (was Re: UFFI const, unsigned, opaque-ish types)

by Esteban Lorenzano

> On 07 Sep 2016, at 14:56, Ben Coman <btc(a)openInWorld.com> wrote: > > On Tue, Sep 6, 2016 at 8:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> Hi, >> >> sorry for arriving so late to this, but I was on holidays :) >> this is how autoRelease works: >> >> 1) #autoRelease of an object registers object for finalisation with a particular executor. Then behaviour is divided: >> >> 2.1.1) for ExternalAddresses, it just registers in regular way, who will call #finalize on GC >> 2.1.2) finalize will just call a free assuming ExternalAddress was allocated (which is a malloc) >> >> 2.2.1) for all FFIExternalReference, it will register for finalisation what #resourceData answers (normally, the handle of the object) >> 2.2.2) finalisation process will call the object class>>#finalizeResourceData: method, with the #resourceData result as parameter >> 2.2.3) each kind of external reference can decide how to free that data (by default is also just freeing). >> >> An example of this is how CairoFontFace works (or AthensCairoSurface). > > > At the bottom of FFIExternalResourceExecutor class comment I read... > "Note that in #finalizeResourceData: you cannot > access any other properties of your instance, > since it is already garbage collected." > > But in my experiments it seems okay to access instance variables in #finalize. > For example... > > CXString >> autoRelease > self class finalizationRegistry add: self > > CXString >> finalize > Transcript crShow: 'Finalizing CXString ' ; show: self private_flags. > self dispose. > Transcript show: ', done!'. > > CXString >>private_flags > "This method was automatically generated" > ^handle unsignedLongAt: 5 > > Libclang getClangVersion autoRelease. > Smalltalk garbageCollect. > "==> Finalizing CXString 1, done! " > > > Is this an unlucky coincidence? Or maybe something changed from NB > to UFFI? (There is a reference to NB there) yes, is a coincidence. the idea of using #finalizeResourceData: is that you keep minimal information (in general, just the handle)â¦ this way we ensure instances will be collected because we will not have circular references (preventing the weakregistry to work). In general, you can always implement as you did it, but I would prefer the #finalizeResourceData: approach, even for structures. The only reason it is not implemented is because I didnât reach the necessity, then I just skipped it (not in purpose, it was not in my head :P), but now is a good moment to implement itâ¦ if you want it :) Esteban > I am wary of believing my results contrary to the comment. That old > engineering principle "When things work, it may be only reinforcing > your misconceptions." :) > > cheers -ben > >> In you case, you will have something like: >> >> FFIExternalObject subclass: #CXString >> >> CXString class>>#finalizeResourceData: version >> self ffiCall: #(void clang_disposeString(void *version)) >> >> notice that here I casted to void*â¦ this is because actually resourceData answers a pointer, not the object. >> >> cheers, >> Esteban

Sept. 7, 2016