September 2016 - Pharo-users

Re: [Pharo-users] Lint Rule for Class-Side Method

by Sean P. DeNigris

Sean P. DeNigris wrote > I'm probably missing something obvious, but it seems like #checksMethod > Lint Rules only get checked against instance-side methods. How does one > check class-side methods? I converted it to a #checksClass rule, but then > hits showed the class definition instead of the offending method source. Bump. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Lint-Rule-for-Class-Side-Method-tp4914121p4914409.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Sept. 6, 2016

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

by Ben Coman

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). > > In you case, you will have something like: > > FFIExternalObject subclass: #CXString Thanks Esteban for the detailed description. However I've come to the conclusion that the C-library dynamically allocating memory for a field inside the struct of CXString doesn't exactly fit any of the pre-existing FFI types. When CXString subclasses FFIExternalObject the call to clang_getClangVersion () crashes the VM since its handle ==> ExternalAddress of 4 bytes but 8 bytes are required for a pointer + uint, https://github.com/llvm-mirror/clang/blob/google/stable/include/clang-c/CXS… /* The CXString type is used to return strings from the interface when * the ownership of that string might differ from one call to the next. * Use clang_getCString() to retrieve the string data and, once finished * with the string data, call clang_disposeString() to free the string. */ typedef struct { const void *data; unsigned private_flags; } CXString; In my limited experience so far it seems FFIExternalStructure is most appropriate So what I've got working is... FFIExternalStructure subclass: #CXString instanceVariableNames: '' classVariableNames: '' poolDictionaries: 'CXStringFlag' package: 'Libclang' CXString class>>fieldsDesc ^ #( void *data; uint private_flags; ) Thus handle of CXString new ==> ByteArray of 8 bytes. However ByteArray and FFIExternalStructure doesn't have any of the smarts of ExternalAddress and FFIExternalReference. So... CXString>>autoRelease self class finalizationRegistry add: self CXString>>finalize self dispose. Transcript crShow: 'debug CXString disposed'. CXString>>dispose self private_flags = CXS_Malloc value "as set by C library" ifTrue: [ self private_flags: CXS_Disposed value. self unguardedDispose. ] ifFalse: [ Error signal: 'Guard prevents double-dispose' ]. CXString>>unguardedDispose self ffiCall: #( void clang_disposeString ( CXString self ) ) module: Libclang > > CXString class>>#finalizeResourceData: version > self ffiCall: #(void clang_disposeString(void *version)) This only seems applicable to FFIExternalReference subclasses. I guess I could copy FFIExternalReference>>autoRelease to CXString. Do you think there would be much advantage to doing this? I see FFIExternalResourceExecutor>>finalize has some session tracking, presumably to avoid freeing dangling references. but I'm not sure about the semantics of #addResource:'s call to #resourceData, and what CXString>>resourceData would return. cheers -ben

Sept. 6, 2016

Re: [Pharo-users] [ann] pillar support in gtinspector

by Nicolai Hess

2016-08-29 21:41 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > I updated the Pillar support in GTInspector. Some of the extensions > already exist in the default Pillar #development version. If you want to > play with the full support, you can load it like this: > > Gofer new > smalltalkhubUser: 'Moose' project: 'PetitParser'; > package: 'PetitAnalyzer'; > package: 'PetitIndent'; > package: 'PetitIslands'; > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'GT-InspectorExtensions-Pillar'; > load > > Then you can just inspect a book folder and you get this: > > > I did not integrate this in the main Pillar yet because this is an older > implementation based on a limited island parser. As now Pillar has a full > parser based on PetitParser, the next step is to move the highlighting > logic to use this parser instead of the island parser. From my > measurements, the speed of the two parsers is about the same, so from a > user perspective there will be not much changes. > > It pains me that we are editing Pillar in outside tools, and now we should > no longer have to do that. Of course, this is not the most ideal tool > support for Pillar but I think it is a reasonable start. > > Cheers, > Doru > nice! I just played a bit with the code to apply larger different font sizes for the headings and use the code styler for inlined code ("=="). Maybe we should use a different code styler or add a way to instruct the styler to ignore unknown classes or uknown selectors :) > > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > > > >

Sept. 6, 2016

Re: [Pharo-users] [ANN] Territorial

by Tudor Girba

Hi Hernan, I read quickly through the doc. Nice work! I noticed that you used the GTInspector (even with multiple panes at a time). That was a nice surprise :). On this occasion I noticed that you could probably extend the inspector with a couple of dedicated views. For example, on page 35, the AmbiguousCity could present the Cities in a dedicated presentation in the same pane. For example, something like: gtInspectorCitiesIn: composite <gtInspectorPresentationOrder: 40> composite list title: âCitiesâ; display: [ cities ]; when: [ cities notEmpty ] Thanks for the clarification about the license. I did not see it either in the manual but that must have been because I schemed fast through it. A note for others: AGPL is different than MIT (the typical license for Pharo projects) in that it requires a user to open source any software that uses the AGPL package in some form. There is nothing wrong with it, but you should be aware of the implications. Cheers, Doru > On Sep 6, 2016, at 11:40 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > > Hi Stephan, > > 2016-09-06 2:52 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > On 06/09/16 06:24, HernÃ¡n Morales Durand wrote: > > I am happy to announce the release of Territorial, a new Smalltalk > library for Geographical Information Retrieval in geopolitical objects. > > Nice. Please tell us about your license choice > > > License of the library is AGPL v3 (it is in the Notes and disclaimers of the manual) > License of the documentation is CC BY-SA 3.0 > > Cheers, > > HernÃ¡n > > Stephan > > > > -- www.tudorgirba.com www.feenk.com âLive like you mean it."

Sept. 6, 2016

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

by Esteban Lorenzano

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). 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 > On 06 Sep 2016, at 13:29, Ben Coman <btc(a)openinworld.com> wrote: > > Hi Pierce, > > I can't determine from DemoFFI how the autorelease works. > > I see memory is allocated by the C library here.... > DemoFFIAutoThing>>allocByReturnedPointer > super allocByReturnedPointer. > handle autoRelease > > where super is... > DemoFFIThing>>allocByReturnedPointer > ((handle := DemoFFILibrary uniqueInstance apiAllocByReturnedPointer) isNull) > ifTrue: [ DemoFFIError signal: 'bummer' ] > > and... > DemoFFILibrary>>apiAllocByReturnedPointer > "demo_thing* alloc_by_returned_pointer(void)" > ^ self ffiCall: #(DemoFFIExternalObject alloc_by_returned_pointer ()) > > > which I guess is to be released by... > DemoFFILibrary>>apiFree: handle > "int free_thing(demo_thing*)" > ^ self ffiCall: #(int free_thing (DemoFFIExternalObject handle)) > > but this has only one sender... > DemoFFIThing>>letGo > handle isNull ifFalse: [ > DemoFFILibrary uniqueInstance apiFree: handle ] > > and the only sender of #letGo is... > DEMOFFIThingTest >> tearDown > > From this I can't follow how #apiFree: ultimately gets automatically > invoked by the object finalization. Are you able to fill me in on the > details? > > cheers -ben > > > On Sun, Sep 4, 2016 at 10:40 PM, Ben Coman <btc(a)openinworld.com> wrote: >> On Fri, Sep 2, 2016 at 10:04 PM, Pierce Ng <pierce(a)samadhiweb.com> wrote: >>> On Fri, Sep 02, 2016 at 12:40:06PM +0800, Ben Coman wrote: >>>> Referring to the example show_clang_version() below, cleanup is done >>>> with clang_disposeString(). How does UFFI hook into the object >>>> finalisation mechanism to call this when the object is garage >>>> collected. >>> >>> Ben, see if this addresses your query: >>> >>> http://www.samadhiweb.com/blog/2016.03.12.demoffi.html >>> >>> Pierce >>> >> >> Thanks Pierce. I've loaded DemoFFI and browsing it now. >> autorelease looks like part of what I need. >> I guess it is #finalize where I should call the libraryAPI_free() function? >> >> cheers -ben >

Sept. 6, 2016

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

by Ben Coman

Hi Pierce, I can't determine from DemoFFI how the autorelease works. I see memory is allocated by the C library here.... DemoFFIAutoThing>>allocByReturnedPointer super allocByReturnedPointer. handle autoRelease where super is... DemoFFIThing>>allocByReturnedPointer ((handle := DemoFFILibrary uniqueInstance apiAllocByReturnedPointer) isNull) ifTrue: [ DemoFFIError signal: 'bummer' ] and... DemoFFILibrary>>apiAllocByReturnedPointer "demo_thing* alloc_by_returned_pointer(void)" ^ self ffiCall: #(DemoFFIExternalObject alloc_by_returned_pointer ()) which I guess is to be released by... DemoFFILibrary>>apiFree: handle "int free_thing(demo_thing*)" ^ self ffiCall: #(int free_thing (DemoFFIExternalObject handle)) but this has only one sender... DemoFFIThing>>letGo handle isNull ifFalse: [ DemoFFILibrary uniqueInstance apiFree: handle ] and the only sender of #letGo is... DEMOFFIThingTest >> tearDown >From this I can't follow how #apiFree: ultimately gets automatically invoked by the object finalization. Are you able to fill me in on the details? cheers -ben On Sun, Sep 4, 2016 at 10:40 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Fri, Sep 2, 2016 at 10:04 PM, Pierce Ng <pierce(a)samadhiweb.com> wrote: >> On Fri, Sep 02, 2016 at 12:40:06PM +0800, Ben Coman wrote: >>> Referring to the example show_clang_version() below, cleanup is done >>> with clang_disposeString(). How does UFFI hook into the object >>> finalisation mechanism to call this when the object is garage >>> collected. >> >> Ben, see if this addresses your query: >> >> http://www.samadhiweb.com/blog/2016.03.12.demoffi.html >> >> Pierce >> > > Thanks Pierce. I've loaded DemoFFI and browsing it now. > autorelease looks like part of what I need. > I guess it is #finalize where I should call the libraryAPI_free() function? > > cheers -ben

Sept. 6, 2016

Re: [Pharo-users] PunQlite problems

by Esteban Lorenzano

Hi, Voyage-UnQLite uses PunQLite driver. I will check what happens, because it should be working. Esteban ps: numbering is a mess, it doesnât necessarily means anything. > On 06 Sep 2016, at 12:42, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > Hi Esteban > > Well, I tried re-installing from your repo, but now I cannot even run the tests in the mumez repo. Whatever I try, I get an error message > in trying to open the database, saying I cannot get a pointer to a byte array. > > Previously, my Monticello browser said I was using PunQLite-Core(TorstenBergmann.28); now it shows the version as Estebanlorenzano.17. I donât understand the naming and numbering, but surely the version number shouldnât go backwards? > > Should I give upon PunQLite, and maybe try Voyage-UnqLite instead? Basically all I need is a database that looks like a large dictionary, with rather lengthy entries (mainly in XML). > > Thanks. > > Peter Kenny > > > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Esteban Lorenzano > Sent: 06 September 2016 10:21 > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] PunQlite problems > > Hi, > > most probably not related to the problem, but the currently maintained (for us) PunQLite is now here: https://github.com/pharo-nosql/PunQLite <https://github.com/pharo-nosql/PunQLite> > > and correct way to install it is: > > Metacello new > repository: 'github://pharo-nosql/PunQLite/repository' <github://pharo-nosql/PunQLite/repository'>; > baseline: 'PunQLite'; > load. > > â¦ even if it is basically the same (and we submit changes to mumez repository too), this is the correct place for us :) > > cheers, > Esteban > >> On 06 Sep 2016, at 00:37, PBKResearch <peter(a)pbkresearch.co.uk <mailto:peter@pbkresearch.co.uk>> wrote: >> >> Hi â just tried a further experiment, with more mysterious results. I created a database in memory with a subset of my data. This time the program will retrieve the values as well as the keys. However, the value presented is just the first 1024 bytes, i.e. the first buffer full. In addition, in the majority of cases the correct bytes are each followed by three zero bytes, e.g. the data begins: >> 3C 00 00 00 68 00 00 00 >> 74 00 00 00 6D 00 00 00 >> 6C 00 00 00 20 00 00 00 >> 63 00 00 00 6C 00 00 00 >> Rather than the expected: >> 3C 68 74 6D 6C 20 63 6C. >> This affects 75 of the 88 cases in my trial database. >> >> I presume the insertion of the zero bytes took place in the writing stage, but I have no idea what is going on. Are there any known problems with PunQLite on pharo 5? >> >> >> >> Hello >> >> I am using Moose 6.0 (Pharo 5.0 Latest update: #50761) on Windows 10. I have installed PunQLite following the instructions in https://github.com/mumez/PunQLite <https://github.com/mumez/PunQLite>. I have run all the examples that involve using files, and everything seems OK. I have tried creating a database using my own data, which seemed to run OK. The database will display its keys successfully, but whenever I try to retrieve a value I get PqFetchError. The debug information shows that an ffi fetch operation has given a return value of -10. I have searched for any information on unQLite return codes, but so far I have nothing. >> >> I tried the PqDatabaseBrowser in the Tools section. This recognised the database, opened it and displayed all the keys correctly. However, clicking on any key gave the same PqFetchError. >> >> Does anyone have any idea of what I have done wrong? >> >> Thanks for any help. >> >> Peter Kenny

Sept. 6, 2016

Re: [Pharo-users] PunQlite problems

by PBKResearch

Hi Esteban Well, I tried re-installing from your repo, but now I cannot even run the tests in the mumez repo. Whatever I try, I get an error message in trying to open the database, saying I cannot get a pointer to a byte array. Previously, my Monticello browser said I was using PunQLite-Core(TorstenBergmann.28); now it shows the version as Estebanlorenzano.17. I donât understand the naming and numbering, but surely the version number shouldnât go backwards? Should I give upon PunQLite, and maybe try Voyage-UnqLite instead? Basically all I need is a database that looks like a large dictionary, with rather lengthy entries (mainly in XML). Thanks. Peter Kenny From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Esteban Lorenzano Sent: 06 September 2016 10:21 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] PunQlite problems Hi, most probably not related to the problem, but the currently maintained (for us) PunQLite is now here: https://github.com/pharo-nosql/PunQLite and correct way to install it is: Metacello new repository: 'github://pharo-nosql/PunQLite/repository'; baseline: 'PunQLite'; load. â¦ even if it is basically the same (and we submit changes to mumez repository too), this is the correct place for us :) cheers, Esteban On 06 Sep 2016, at 00:37, PBKResearch <peter(a)pbkresearch.co.uk <mailto:peter@pbkresearch.co.uk> > wrote: Hi â just tried a further experiment, with more mysterious results. I created a database in memory with a subset of my data. This time the program will retrieve the values as well as the keys. However, the value presented is just the first 1024 bytes, i.e. the first buffer full. In addition, in the majority of cases the correct bytes are each followed by three zero bytes, e.g. the data begins: 3C 00 00 00 68 00 00 00 74 00 00 00 6D 00 00 00 6C 00 00 00 20 00 00 00 63 00 00 00 6C 00 00 00 Rather than the expected: 3C 68 74 6D 6C 20 63 6C. This affects 75 of the 88 cases in my trial database. I presume the insertion of the zero bytes took place in the writing stage, but I have no idea what is going on. Are there any known problems with PunQLite on pharo 5? Hello I am using Moose 6.0 (Pharo 5.0 Latest update: #50761) on Windows 10. I have installed PunQLite following the instructions in <https://github.com/mumez/PunQLite> https://github.com/mumez/PunQLite. I have run all the examples that involve using files, and everything seems OK. I have tried creating a database using my own data, which seemed to run OK. The database will display its keys successfully, but whenever I try to retrieve a value I get PqFetchError. The debug information shows that an ffi fetch operation has given a return value of -10. I have searched for any information on unQLite return codes, but so far I have nothing. I tried the PqDatabaseBrowser in the Tools section. This recognised the database, opened it and displayed all the keys correctly. However, clicking on any key gave the same PqFetchError. Does anyone have any idea of what I have done wrong? Thanks for any help. Peter Kenny

Sept. 6, 2016

Re: [Pharo-users] [ANN] Territorial

by HernÃ¡n Morales Durand

2016-09-06 2:53 GMT-03:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > On Tue, Sep 6, 2016 at 6:24 AM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: > > > > I am happy to announce the release of Territorial, a new Smalltalk > library > > for Geographical Information Retrieval in geopolitical objects. > > Great ! At the moment, I don't have immediate needs of this but this > might change in the future. > > > Blog post with details: > > http://80738163270632.blogspot.com/2016/08/territorial.html > > The link does not work, apparently the correct link is : > http://80738163270632.blogspot.fr/2016/09/territorial.html > > Thanks! I forgot to update, yes the correct link is http://80738163270632.blogspot.fr/2016/09/territorial.html > > User Manual: http://bit.ly/2c4RrCJ > > Nice documentation ! > > I see you are using github. Try to setup a CI job and maybe put your > code also on github. > Ask me if you need help. > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

Sept. 6, 2016

Re: [Pharo-users] [ANN] Territorial

by HernÃ¡n Morales Durand

Hi Stephan, 2016-09-06 2:52 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > On 06/09/16 06:24, HernÃ¡n Morales Durand wrote: > >> >> I am happy to announce the release of Territorial, a new Smalltalk >> library for Geographical Information Retrieval in geopolitical objects. >> > > Nice. Please tell us about your license choice > > License of the library is AGPL v3 (it is in the Notes and disclaimers of the manual) License of the documentation is CC BY-SA 3.0 Cheers, HernÃ¡n > Stephan > > > >

Sept. 6, 2016