January 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 2.0] #20489

by Benjamin

Has been done, and probably lost in the versions Ben On Jan 25, 2013, at 11:19 PM, Sven Van Caekenberghe wrote: > > On 25 Jan 2013, at 22:27, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > >> EstebanLM wrote >>> Issue 7296: visual feedback from 'class side button' when a class has >>> class side methods >> >> Great idea! > > Indeed. > > But like in the sentence above I would prefer 'class side' as label instead of 'show class'. > > Just an idea...

Jan. 25, 2013

Re: [Pharo-project] [update 2.0] #20489

by Sven Van Caekenberghe

On 25 Jan 2013, at 22:27, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > EstebanLM wrote >> Issue 7296: visual feedback from 'class side button' when a class has >> class side methods > > Great idea! Indeed. But like in the sentence above I would prefer 'class side' as label instead of 'show class'. Just an idea...

Jan. 25, 2013

Re: [Pharo-project] [update 2.0] #20489

by Francois Stephany

<3 On 25/01/13 18:41, Esteban Lorenzano wrote: > Issue 7296: visual feedback from 'class side button' when a class has class side methods > http://code.google.com/p/pharo/issues/detail?id=7296

Jan. 25, 2013

Re: [Pharo-project] [update 2.0] #20489

by Sean P. DeNigris

EstebanLM wrote > Issue 7296: visual feedback from 'class side button' when a class has > class side methods Great idea! -- View this message in context: http://forum.world.st/update-2-0-20489-tp4665408p4665438.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 25, 2013

Re: [Pharo-project] NativeBoostFFI out parameters passing pointers back and forth is confusing...

by Stefan Marr

Hi Ciprian: On 25 Jan 2013, at 20:58, Ciprian Teodorov wrote: > repo := NBExternalObject new. [...] > repository_open: out path: path > ^self call: #(NBInt32 git_repository_open(NBExternalObject * out, NBCharacterType * path)) options: #( ) > Notice that when using NBExternalObject one level of indirection is gone so git_repository ** becomes NBExternalObject * Indeed, much nicer. I am now using type aliases such as: #(git_repository_ptr NBExternalObject git_reference_ptr NBExternalObject) With a signature such as: ^self call: #(int git_repository_open(git_repository_ptr * handle, char * path)) That stays close to the C, and tells me what the pointer are. And with the NBExternalObject it works nicely. Thanks a lot! Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 25, 2013

[Pharo-project] NativeBoost and NULL

by Ciprian Teodorov

Hi Igor, I have a question about NativeBoost and the usage of NULL. Many C functions that have output arguments passing NULL means that the argument is not needed, however I am under the impression that this is not supported in NativeBoost yet. For example I have this function signature, which returns the `disable` option if called with not null argument. getDiagnosticOption: diag Disable: disable <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> ^self call: #(CXString clang_getDiagnosticOption(CXDiagnostic diag, CXString * disable)) options: #( ) For now in NB it seems that I can only call it as follows: bogus := CXStringStruct new. <- cxstr := self clang getDiagnosticOption: handle Disable: bogus. bogus disposeString. <- The idea is that I want to get rid of the bogus, on one hand because it pollutes the method, and in the other hand I do not need to do the allocation if I won't use the result so the call will become cxstr := self clang getDiagnosticOption: handle Disable: nil. how can we do this? Cheers -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Jan. 25, 2013

Re: [Pharo-project] NativeBoostFFI out parameters passing pointers back and forth is confusing...

by Ciprian Teodorov

Hi Stefan, First of all I want to thank you for this mail, which showed me a bug that I had in TalkFFI (the git_repository 'NBVoid *') which introduces one more indirection level, which is wrong. On Fri, Jan 25, 2013 at 2:13 AM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > Hi: > > I don't really understand how NativeBoostFFI handles pointers. > > probably Igor is the best to answer this question... in details > > I have two functions like this: > > > self call: #(int git_repository_open(git_repository * * handle, char * > path)) > > and > > self call: #(int git_repository_head(git_reference * * refHandle, > git_repository * repo)) > > > > They use a type mapping like this: > #('git_repository' 'NBVoid' > 'git_reference' 'NBVoid' ) > > So, nothing special going on here, just pointers to pointers, > and pointers to opaque data structures. > > Now, the call to the _open function is done with a `repoHandle := > NBExternalHandle new`. > This works, and I get the result value of the c lib inside my repoHandle. > > However, if I want to use it in the _head call, I first have to convert it > into a NBExternalAddress (`NBExternalAddress value: repoHandle value`). > > Took me a while to figure out that passing in the repoHandle to _head does > actually do the wrong thing. > The _head function then gets the address of repoHandle instead of its > value, which is wrong for my usecase. > > However, just passing in `repoHandle value` results in some strange _nil_ > error. > > So, the main question is, why do I need to convert between Handle and > Address? > > For the library I am trying to use, that becomes a somehow recurring > pattern: > > > | repo repoPath cb branches headHandle | > repo := NBExternalHandle new. > repoPath := NBExternalAddress fromString: '/Users/smarr/tmp/filetree'. > > LG2RepositoryH uniqueInstance repository_open: repo path: repoPath. > repo := NBExternalAddress value: repo value. "<-- Why is this necessary?" > > headHandle := NBExternalHandle new. > LG2RepositoryH uniqueInstance repository_head: headHandle repo: repo. > > ^ (LG2RefsH uniqueInstance > reference_name: (NBExternalAddress value: headHandle value)) "<-- Why > is this necessary?" > readString > > Another solution which removes this recurring pattern is to use the NBExternalObject, either directly, or by subclassing it. Here is a snippet showing how: |headHandle path repo name| repo := NBExternalObject new. path := NBExternalAddress fromString: '/Users/ciprian/github/local/enso'. LG2RepositoryH uniqueInstance repository_open: repo path: path. headHandle := NBExternalObject new. LG2RepositoryH uniqueInstance repository_head: headHandle repo: repo. name := LG2RefsH uniqueInstance reference_name: headHandle. name readString. but now FFI methods need to be changed to: repository_open: out path: path ^self call: #(NBInt32 git_repository_open(NBExternalObject * out, NBCharacterType * path)) options: #( ) repository_head: out repo: repo ^self call: #(NBInt32 git_repository_head(NBExternalObject * out, NBExternalObject repo)) options: #( ) reference_name: ref ^self call: #(NBCharacterType * git_reference_name(NBExternalObject ref)) options: #( ) Notice that when using NBExternalObject one level of indirection is gone so git_repository ** becomes NBExternalObject * Even nicer, if you subclass the NBExternalObject to have LG2Repository and LG2Reference, the signatures become clearer... I will look this weekend at TalkFFI to see how can I make use of this NBExternalObject, at least in the simple cases... to prevent the need for (NBExternalAddress value: repo value) all over the place. Cheers, Ciprian > > Thanks > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Jan. 25, 2013

[Pharo-project] [update 2.0] #20489

by Esteban Lorenzano

20489 ----- Issue 7296: visual feedback from 'class side button' when a class has class side methods http://code.google.com/p/pharo/issues/detail?id=7296 Issue 6100: Too many 'This group already exists' http://code.google.com/p/pharo/issues/detail?id=6100 Issue 5896: [ENH]: Nautilus icon for method breakpoints http://code.google.com/p/pharo/issues/detail?id=5896 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-EstebanLorenzano.1018.diff http://ss3.gemstone.com/ss/Pharo20/NautilusCommon-EstebanLorenzano.109.diff http://ss3.gemstone.com/ss/Pharo20/Nautilus-EstebanLorenzano.400.diff http://ss3.gemstone.com/ss/Pharo20/GroupManager-EstebanLorenzano.39.diff

Jan. 25, 2013

Re: [Pharo-project] In-Image Fuel Documentation

by Martin Dias

Thanks. In latest releases we added several guides, and we also refactored the website to keep the guides for the previous versions (http://rmod.lille.inria.fr/web/pier/software/Fuel in the "Versions" section). How can you access the readme in a particular old version, in github? I don't have experience with it so I don't know. I like the idea of avoiding redundant documentation. I don't know if for every Monticello package, but at least can be interesting for each ConfigurationOf* package... Martin On Thu, Jan 24, 2013 at 10:32 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 24 Jan 2013, at 20:16, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > >> I eventually found this awesome website [1]. It would be great if there were >> some basic examples in the image. I found the tests too well factored to be >> used for this purpose. Even a HelpSystem entry simply pointing to [1] would >> be really helpful for beginners like me ;) (although a full Help entry would >> have the nice benefit of executable examples) >> >> Thanks, >> Sean >> >> [1] >> http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8.1/Documentation > > This is very nice documentation ! > > Thanks for the pointer, and thanks Mariano for writing it - this is really great. > > Sven > > PS: IMHO the only thing we need is a way or a convention to document a Monticello package as a whole. That can then be the starting or entry point. Like README.md in github. This should then be in the code and browseable externally. > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

Jan. 25, 2013

[Pharo-project] Finalization in Pharo 2.0 vs Pharo 1.4

by Noury Bouraqadi

Hi, I'm currently working with 1.4 and having some issues with finalization. I wonder if there were some changes at this level in 2.0? Noury -- http://twitter.com/#!/NouryBouraqadi http://car.mines-douai.fr/noury

Jan. 25, 2013