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

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

by David T. Lewis

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

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

by Stefan Marr

Hi: I don't really understand how NativeBoostFFI handles pointers. 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 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

Jan. 25, 2013

[Pharo-project] Fwd: Smalltalk Industry Conference

by Casimiro de Almeida Barreto

Just received this today -------- Original Message -------- Subject: Smalltalk Industry Conference Date: 24 Jan 2013 11:10:50 -0500 From: Cincom Systems <events(a)info.cincom.com> Reply-To: Cincom Systems <events(a)cincom.com> To: cbarreto(a)lsi.usp.br If you are having trouble viewing this email message, launch your browser here <http://app.info.cincom.com/e/es.aspx?s=836&e=75170&elq=c2237f702a6d4353a3d1…>. Cincom logo hot air balloons *The Smalltalk Industry Conference (STIC) 2013: Celebrating the History (and Future) of Smalltalk* The conference will take place at the Wigwam Resort in Phoenix, Arizona on June 9-12, 2013. <http://app.info.cincom.com/e/er?s=836&lid=4558&elq=c2237f702a6d4353a3d18302…> STIC is a forum where Smalltalk professionals, researchers and enthusiasts can meet and share ideas and experiences. We're looking forward to an excellent conference and need your participation to maintain the conference's high technical level! STIC is currently accepting proposals for talks involving Smalltalk technology, Smalltalk user experiences and other areas of innovation in the software industry. We are also seeking academic papers for "Smalltalk Directions"âthe academic sessions of the conference. Such papers should address possible future directions for Smalltalk and/or Smalltalk-inspired dynamic languages. To submit conference session proposals and academic papers, click here <http://app.info.cincom.com/e/er?s=836&lid=4558&elq=c2237f702a6d4353a3d18302…>. For updates and announcements about the conference, please visit us on the web at http://www.stic.st <http://app.info.cincom.com/e/er?s=836&lid=460&elq=c2237f702a6d4353a3d183021…>. Join us for the conference and celebration and share your experiences with other Smalltalk enthusiasts. Try Cincom Smalltalk Now! Free <http://app.info.cincom.com/e/er?s=836&lid=3122&elq=c2237f702a6d4353a3d18302…> Wigwam Resort conference attendees conference attendees Share this: <mailto:?subject=Here%20is%20the%20Smalltalk%20information%20I%20would%20lik…> <http://app.info.cincom.com/e/er?s=836&lid=4121&elq=c2237f702a6d4353a3d18302…> <http://app.info.cincom.com/e/er?s=836&lid=4122&elq=c2237f702a6d4353a3d18302…> <http://app.info.cincom.com/e/er?s=836&lid=4189&elq=c2237f702a6d4353a3d18302…> <http://app.info.cincom.com/e/er?s=836&lid=4124&elq=c2237f702a6d4353a3d18302…> smalltalk footer <http://www.cincomsmalltalk.com/main/developer-community/trying-cincom-small…> 55 Merchant St. â¢ Cincinnati, OH 45246 â¢ phone: 800-2CINCOM â¢ fax: 513-612-2000 view in browser <http://app.info.cincom.com/e/es.aspx?s=836&e=75170&elq=c2237f702a6d4353a3d1…> â¢ legal notice <http://www.cincom.com/legal-notice/?elq=c2237f702a6d4353a3d1830213a332e4&el…> â¢ privacy policy <http://www.cincom.com/privacy-policy/?elq=c2237f702a6d4353a3d1830213a332e4&…> â¢ subscription preferences <http://events.cincom.com/forms/subscription?elq=c2237f702a6d4353a3d1830213a…> Cincom, the Quadrant Logo, Cincom Smalltalk, ObjectStudio, VisualWorks and Simplification Through Innovation are trademarks or registered trademarks of Cincom Systems, Inc. All other trademarks belong to their respective companies. Â©2013 Cincom Systems, Inc. All Rights Reserved

Jan. 24, 2013

Re: [Pharo-project] TalkFFI: automatic FFI generation for Pharo

by Jan Vrany

Hi Stefan, just a comment. I spent quite some time on libgit2 bindings before giving up (at the stage where I could browse repo + do a commit) Better to avoid callbacks at all costs - fortunately there is usually an "iterative" API. Also, you must be very careful when passing in parameters, sometimes the libgit2 remembers pointers and when GC moves them, you know... I had to dig into libgit2 sources/attach GDB to find out. Have fun! Jan On 24/01/13 21:24, Stefan Marr wrote: > > branches := OrderedCollection new. > > cb := LG2BranchHCb161 on: [:name :type :payload | branches add: name ]. > LG2BranchH uniqueInstance branch_foreach: repo list_flags: 1 branch_cb: cb payload: NBExternalAddress null. > > ^ { repo. branches } > > > So, now I am down to the question of how to use TalkFFI and NativeBoostFFI. > > Any idea what that could be? And how to diagnose these things? > > Thanks a lot > Stefan > > >

Jan. 24, 2013

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

by Sven Van Caekenberghe

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. 24, 2013

Re: [Pharo-project] TalkFFI: automatic FFI generation for Pharo

by Stefan Marr

Hi: On 24 Jan 2013, at 20:29, Ciprian Teodorov wrote: > Hi Stefan, > > I've just tried libgit2 mapping generation on my machine, at it seems to work without any problems... (well besides the hack on the ChangesBrowser)... > Now the thing is that I have the latest packages of TalkFFI, and LibClang. So I recommend that you retry after updating the packages from the repository... Aaaah... Well, I update one of the things yesterday manually, and was not aware that there is a second repository. My TalkFFI packages were outdated. Well, and I needed to work the ordering issue, so I added CLForeignLibInterfaceGenerator>>#implement mappingModel model changes execute. Now the generation indeed succeeds :) However, trying to do something simple fails with a NBCog VM crash. I am not entirely sure whether I am doing it correct, and whether this is all GC save etc... So here we go with two examples: "try to get the repo head and its name" | repo repoPath cb branches headHandle | repo := NBExternalHandle new. repoPath := NBExternalAddress fromString: '/Users/smarr/tmp/filetree'. LG2RepositoryH uniqueInstance repository_open: repo path: repoPath. headHandle := NBExternalHandle new. LG2RepositoryH uniqueInstance repository_head: headHandle repo: repo. ^ LG2RefsH uniqueInstance reference_name: headHandle. The second one is a bit more complex, it has to use a callback: "try to read all the names of branches" | repo repoPath cb branches | LibGit2Map initialize. repo := NBExternalHandle new. repoPath := NBExternalAddress fromString: '/Users/smarr/tmp/filetree'. LG2RepositoryH uniqueInstance repository_open: repo path: repoPath. branches := OrderedCollection new. cb := LG2BranchHCb161 on: [:name :type :payload | branches add: name ]. LG2BranchH uniqueInstance branch_foreach: repo list_flags: 1 branch_cb: cb payload: NBExternalAddress null. ^ { repo. branches } So, now I am down to the question of how to use TalkFFI and NativeBoostFFI. Any idea what that could be? And how to diagnose these things? 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. 24, 2013

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

by Camillo Bruni

On 2013-01-24, at 21:03, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > On Thu, Jan 24, 2013 at 4:16 PM, 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. > > > what do you mean by this? > FLUserGuidesTest contains the examples used in the website (although there > may not be everything and still it could be outdated). > Maybe we can move this test into a Fuel-Examples package? > > >> 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) >> >> > Hi Sean. One problem I found is that then we have too many places with the > same doc. Hence, a simple update means changing a lot of places: > > - Doc in image > - Examples in image / tests > - Website > - Help system > - PBE chapter > > so...that does not scale. > > I don't know yet the best way to solve this. Markdown and then output all > the different pieces is not an option I think. > thoughts? For me the first place to put information is in the Image, hence I would only create a HelpDoc (using a common Markdown et. al scheme). The secondary thing is to output that to proper website to get a nice global index on google. This is specially useful if you do not have the code installed yet and you are looking for some piece of code doing a certain thing. Note that it happens way to often on this mailing list that people ask for something and reimplement it due to missing answers ;), google should answer you the right thing!

Jan. 24, 2013

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

by Sean P. DeNigris

Mariano Martinez Peck wrote > FLUserGuidesTest contains the examples used in the website Oops, didn't see that one! I went to the serialization tests and got lost. I guess what I'm suggesting is to have pointers to the prefered docs (in this case FLUserGuidesTest) where a user might look e.g. HelpSystem -- View this message in context: http://forum.world.st/In-Image-Fuel-Documentation-tp4665190p4665210.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 24, 2013

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

by Mariano Martinez Peck

On Thu, Jan 24, 2013 at 4:16 PM, 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. what do you mean by this? FLUserGuidesTest contains the examples used in the website (although there may not be everything and still it could be outdated). Maybe we can move this test into a Fuel-Examples package? > 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) > > Hi Sean. One problem I found is that then we have too many places with the same doc. Hence, a simple update means changing a lot of places: - Doc in image - Examples in image / tests - Website - Help system - PBE chapter so...that does not scale. I don't know yet the best way to solve this. Markdown and then output all the different pieces is not an option I think. thoughts? > Thanks, > Sean > > [1] > > http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8.1/Documentation > > > > -- > View this message in context: > http://forum.world.st/In-Image-Fuel-Documentation-tp4665190.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

Jan. 24, 2013

Re: [Pharo-project] Image size of 2.0...

by Sven Van Caekenberghe

On 24 Jan 2013, at 18:57, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Marcus Denker-4 wrote >> The download of 2.0 now has ca. 30MB, which is large. >> >> But... 15.4MB > > I am in awe that I can download the closest thing the world has ever come to > dynabook software in 20 seconds on my home internet. This is truly an > exciting time to be alive!! > > Cheers, > Sean > > p.s. 10 seconds for 15MB is even nicer... what will I do with the time ;) Fix Pharo bugs ? ;-) Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Jan. 24, 2013