- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] OSProcess updated for Pharo 2.0 (was: The monkey is back in town)

by Bruni camillo

Perfect that is really great news! I will try it immediately. On 25 Jan 2013 15:08, "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > Thanks a lot david!!! > > Stef > > On Jan 24, 2013, at 10:38 PM, David T. Lewis wrote: > > > On Fri, Jan 18, 2013 at 03:28:10PM +0100, Damien Cassou wrote: > >> > >> you don't need FileSystem-Legacy if you use OSProcess from Coral: > >> > >> Gofer new > >> squeaksource3: 'coral'; > >> package: 'OSProcess'; > >> load. > >> > > > > OSProcess and CommandShell-Piping should now load cleanly in Pharo 2.0. > > > > The latest versions are OSProcess-dtl.75 and CommandShell-Piping-dtl.13 > > in the SqueakSource repositories for OSProcess and CommandShell. > > > > Thanks to Damien Cassou for doing the original work for OSProcess support > > in Coral. I adapted his work so it will now load in both Squeak and > Pharo. > > > > Unit test notes: > > > > The AioEventHandlerTestCase failures are due to AioPlugin not included in > > the VM. I expect the tests will pass if AioPlugin is added to VM builds. > > > > Many test rely on #forkSqueak to create cooperating OS processes for the > > tests. These tests fail on Cog, although this does not affect basic > > functionality of OSProcess itself. > > > > UnixProcessAccessorTestCase>>testRedirectStdOutTo fails due to a problem > > introduced in the oscog branch of the OSProcessPlugin. This should be > fixed > > in the plugin but is a minor concern and does not affect normal usage > > of OSProcess. > > > > Dave > > > > > > >

Jan. 25, 2013

Re: [Pharo-project] OrderedCollections and File I/O

by J. P. L. MartÃn

Thank you all for your help, I've used Fuel to save my data and it was really easy to do. Thanks! On Wed, Jan 23, 2013 at 9:43 AM, Edgar J. De Cleene <edgardec2005(a)gmail.com>wrote: > > > > On 1/23/13 8:47 AM, "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: > > > On Wed, Jan 23, 2013 at 6:39 AM, Edgar J. De Cleene <* > edgardec2005@gmail.com*> wrote: > > > > > On 1/23/13 6:25 AM, "Marcus Denker" <*marcus.denker@inria.fr*> wrote: > > > Keep in mind that ReferenceStream is deprecated in 2.0 > > > > The nice thing about Fuel is: > > > > -> Very much faster > > -> output more compact > > -> you can store *any* kind of objects. > > (even the one you are sure you can't, like the Context (stack > > frame)) > > > > Marcus > > Yes , I know Fuel is a great advance, but he ask about simple thing. > And also I said Pharo 1.4 and not Pharo 2.0. > > Thanks to Mariano and others , wish Fuel become Squeak citizen soon, for > Cuis guess should wait longer. > > > Edgar see new release: * > http://forum.world.st/ANN-Fuel-1-8-1-td4661609.html > *Supported and tested images: > Pharo 1.1.1, 1.1.2, 1.2, 1.3, 1.4, 2.0 > Squeak 4.1, 4.2, 4.3, 4.4 > > > Edgar > > > Mariano, yo se eso. > Pareciera que por tratar de ayudar a un nuevo con dos lineas de codigo > estoy desconociendo tu trabajo y el de todos los demas que estan trabajando > con Fuel. > No hay una unica receta, mis amigos de Pharo. > > Edgar >

Jan. 25, 2013

Re: [Pharo-project] OSProcess updated for Pharo 2.0 (was: The monkey is back in town)

by StÃ©phane Ducasse

Thanks a lot david!!! Stef On Jan 24, 2013, at 10:38 PM, David T. Lewis wrote: > On Fri, Jan 18, 2013 at 03:28:10PM +0100, Damien Cassou wrote: >> >> you don't need FileSystem-Legacy if you use OSProcess from Coral: >> >> Gofer new >> squeaksource3: 'coral'; >> package: 'OSProcess'; >> load. >> > > OSProcess and CommandShell-Piping should now load cleanly in Pharo 2.0. > > The latest versions are OSProcess-dtl.75 and CommandShell-Piping-dtl.13 > in the SqueakSource repositories for OSProcess and CommandShell. > > Thanks to Damien Cassou for doing the original work for OSProcess support > in Coral. I adapted his work so it will now load in both Squeak and Pharo. > > Unit test notes: > > The AioEventHandlerTestCase failures are due to AioPlugin not included in > the VM. I expect the tests will pass if AioPlugin is added to VM builds. > > Many test rely on #forkSqueak to create cooperating OS processes for the > tests. These tests fail on Cog, although this does not affect basic > functionality of OSProcess itself. > > UnixProcessAccessorTestCase>>testRedirectStdOutTo fails due to a problem > introduced in the oscog branch of the OSProcessPlugin. This should be fixed > in the plugin but is a minor concern and does not affect normal usage > of OSProcess. > > Dave > >

Jan. 25, 2013

Re: [Pharo-project] destructive / regression tests

by Sean P. DeNigris

Camillo Bruni-3 wrote > I think I got it! last night's hacking session was fruitful! > For now I have > ... Nice work, cami! Thanks :) -- View this message in context: http://forum.world.st/destructive-regression-tests-tp4665153p4665352.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 25, 2013