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

[Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by David T. Lewis

I have updated CommandShell for Pharo 2.0, and made a few additional updates to OSProcess also. In addition to CommandShell-Piping, the rest of the CommandShell package (except for CommandShell-MVC) can now be loaded into Pharo 2.0. CommandShellPharo provides the menu registration to make "Command shell" available under "Tools" in the world menu. The repository is at http://www.squeaksource.com/CommandShell, and the latest versions are: CommandShell-Base-dtl.29 CommandShell-Piping-dtl.13 CommandShell-Commands-dtl.13 CommandShell-UI-dtl.10 CommandShell-Morphic-dtl.2 CommandShellPharo-dtl.2 Yes I know, it needs a ConfigurationOfCommandShell. There are test failures related to VM issues but the basic functionality is now working, and both OSProcess and CommandShell should now be working for Pharo on Unix/Linux (and hopefully Mac) VMs. Dave On Thu, Jan 24, 2013 at 08:38:03PM -0500, David T. Lewis wrote: > > 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. 29, 2013

Re: [Pharo-project] How to force Metacello to use the package cache?

by StÃ©phane Ducasse

On Jan 28, 2013, at 9:29 PM, Dale Henrichs wrote: > Metacello does use the package cache, but there _are_ certain specifications that can force a load from the repository: > > 1) If a configuration is blessed as #development, the configuration will be downloaded from the repository when referenced (to ensure that you are picking up the latest configuration > > 2) If you have a "naked" package in a specification (i.e/, no file: specified), then Metacello will _ALWAYS_ access the repository to load the LATEST mcz file...most often this is triggered when you load a baseline version (where no file: are specified). > > Moose tends to reference baselines in this manner to ensure that the latest packages are loaded. This is the most likely cause of your "problem". > > If you've specified a file: and Metacello finds the file in the package-cache it does not hit the repository to download the file. Thanks for the explanation. I'm happy because I found my bug (in fact you found my bug :). And there is a lesson. Do not code when you are too tired. Dale. > Dale > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > | Sent: Monday, January 28, 2013 7:05:16 AM > | Subject: [Pharo-project] How to force Metacello to use the package cache? > | > | Hi guys > | > | I'm trying to work on Moose and I get 200 package to download during > | my experiments ~ 30 min at minimum > | Does anybody have an idea how to make sure metacello use the package > | cache? > | > | I started to comment > | > | cacheGofer > | > | cacheGofer == nil > | ifTrue: [ > | "don't use a caching Gofer here, since we expect the contents to > | change during a fetch operation" > | cacheGofer := Gofer new. > | >>>> cacheGofer disablePackageCache. > | cacheGofer repository: self cacheRepository. ]. > | ^ cacheGofer > | > | But no success so far. > | > | Still looking around > | Stef > | >

Jan. 29, 2013

Re: [Pharo-project] How to force Metacello to use the package cache?

by Dale Henrichs

Metacello does use the package cache, but there _are_ certain specifications that can force a load from the repository: 1) If a configuration is blessed as #development, the configuration will be downloaded from the repository when referenced (to ensure that you are picking up the latest configuration 2) If you have a "naked" package in a specification (i.e/, no file: specified), then Metacello will _ALWAYS_ access the repository to load the LATEST mcz file...most often this is triggered when you load a baseline version (where no file: are specified). Moose tends to reference baselines in this manner to ensure that the latest packages are loaded. This is the most likely cause of your "problem". If you've specified a file: and Metacello finds the file in the package-cache it does not hit the repository to download the file. Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> | Sent: Monday, January 28, 2013 7:05:16 AM | Subject: [Pharo-project] How to force Metacello to use the package cache? | | Hi guys | | I'm trying to work on Moose and I get 200 package to download during | my experiments ~ 30 min at minimum | Does anybody have an idea how to make sure metacello use the package | cache? | | I started to comment | | cacheGofer | | cacheGofer == nil | ifTrue: [ | "don't use a caching Gofer here, since we expect the contents to | change during a fetch operation" | cacheGofer := Gofer new. | >>>> cacheGofer disablePackageCache. | cacheGofer repository: self cacheRepository. ]. | ^ cacheGofer | | But no success so far. | | Still looking around | Stef |

Jan. 29, 2013

[Pharo-project] how can we create project in SmalltalkHub

by StÃ©phane Ducasse

Hi guys I mean projects that are not under StephaneDucasse. Should I create a Moose team to create the Moose Project? Stef

Jan. 29, 2013

Re: [Pharo-project] nativeboost google groups

by StÃ©phane Ducasse

but this is always good to know the limit of key infrastructure of pharo. So now we will not know it, only if we register to the google group. Stef > it's mostly offtopic low-level stuff which has nothing to do with Pharo per se. > > hence separate mailing list, plus it's much easier to separate discussions ;). > > > On 2013-01-28, at 23:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> why? >> because this is cool to see that there is activity around NB >> >> Stef >> >>> I thought it might be a good idea to outsource the nativeboost discussions from the main mailinglist. >>> So I started a new google groups: >>> >>> https://groups.google.com/forum/?fromgroups#!forum/nativeboost >>> nativeboost(a)googlegroups.com >>> >>> cami >> >> > >

Jan. 28, 2013

[Pharo-project] TxText configuration

by Camillo Bruni

Who's in charge of the development of TxText right now? It would like the maintainers on the ci-job description: https://ci.inria.fr/rmod/job/TxText/ thanks :)

Jan. 28, 2013

Re: [Pharo-project] nativeboost google groups

by Camillo Bruni

it's mostly offtopic low-level stuff which has nothing to do with Pharo per se. hence separate mailing list, plus it's much easier to separate discussions ;). On 2013-01-28, at 23:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > why? > because this is cool to see that there is activity around NB > > Stef > >> I thought it might be a good idea to outsource the nativeboost discussions from the main mailinglist. >> So I started a new google groups: >> >> https://groups.google.com/forum/?fromgroups#!forum/nativeboost >> nativeboost(a)googlegroups.com >> >> cami > >

Jan. 28, 2013

Re: [Pharo-project] NativeBoost linux 8 byte structures

by Ciprian Teodorov

Thank you guys, you got me started... I've submitted a quick fix... however we'll need to write some linux tests... Cheers, On Mon, Jan 28, 2013 at 11:20 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > See also this thread > http://lists.gforge.inria.fr/pipermail/pharo-project/2012-May/064140.html, > and this link http://www.shell-storm.org/papers/files/657.pdf to give > you an idea of how messy every-one-else-but-your-own low level code > can be... > > Nicolas > > 2013/1/28 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Sun, Jan 27, 2013 at 2:26 PM, Ciprian Teodorov > > <ciprian.teodorov(a)gmail.com> wrote: > >> > >> Hi Guys, > >> > >> Today I wanted to test my TalkFFI project on linux, and I run into some > NB > >> issue. > >> It seems that the VM crashes when trying to invoke a function returning > a > >> 8 byte structure. > >> I have tried with 4 bytes structure and I get some bogus data but no > crash > >> with 12 bytes structure it seems to work... > > > > > > I suspect this is a win32/linux difference that NB doesn't handle yet. > On > > win32 power-of-two structures <= 8 bytes in length are returned in > > registers. On linux they're always returned through memory. Here are > the > > relevant defs from the ThreadedIA32FFIPlugin > > > > > > #if defined(_X86_) || defined(i386) || defined(__i386) || > defined(__i386__) > > /* Both Mac OS X x86 and Win32 x86 return structs of a power of two in > size > > * less than or equal to eight bytes in length in registers. Linux never > > does so. > > */ > > # if __linux__ > > # define WIN32_X86_STRUCT_RETURN 0 > > # else > > # define WIN32_X86_STRUCT_RETURN 1 > > # endif > > > > #define returnStructInRegisters(sz) (WIN32_X86_STRUCT_RETURN && (sz) <= > 8 && > > !((sz)&((sz)-1))) > > > > > > HTH > > > >> Attached to this mail you will find a simple test case. > >> > >> the c file I have compiled with: > >> > >> gcc -g -fPIC -Wall -c -m32 strreturn.c > >> gcc -shared -g -Wl,-soname,libret.so.1 -o libret.so -m32 strreturn.o -lc > >> > >> 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 > > > > > > > > > > -- > > best, > > Eliot > > -- 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. 28, 2013

Re: [Pharo-project] nativeboost google groups

by StÃ©phane Ducasse

why? because this is cool to see that there is activity around NB Stef > I thought it might be a good idea to outsource the nativeboost discussions from the main mailinglist. > So I started a new google groups: > > https://groups.google.com/forum/?fromgroups#!forum/nativeboost > nativeboost(a)googlegroups.com > > cami

Jan. 28, 2013

[Pharo-project] nativeboost google groups

by Camillo Bruni

I thought it might be a good idea to outsource the nativeboost discussions from the main mailinglist. So I started a new google groups: https://groups.google.com/forum/?fromgroups#!forum/nativeboost nativeboost(a)googlegroups.com cami

Jan. 28, 2013