April 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] Magma 1.1

by Chris Muller

In conjunction with the outstanding releases of Pharo 1.0 and Squeak 4.1, I am pleased to announce the immediate availability of Magma 1.1 release 1. Don't be fooled by the grand version number; it's just an increment of "1.0 release 44" (details below). This "1.1" is about compatibility with what I feel are these new beginnings in Smalltalk. - Chris Changes in 1.1r1 (since 1.0r44): - Compatible with Squeak 4.1 and Pharo 1.0 (also compatible with Squeak 3.10 and 3.9). Loads into all images cleanly, with no more warnings in Pharo. - No longer necessary to disable WriteBarrier to run the tests; if it can't be used, just don't rather than intrude on the user. - Added MagmaSession>>#fullBackup, for making a quick, convenient backup on the server in the same directory as the existing repository, but named with its commitNumber as an extension. This is useful insurance for when you're about to run, say, a domain migration script.. - Fix for case using relative-path local locations. - Moved MagmaSessionRequest to Ma base additions so that applications can be written to to signal MagmaSessionRequests without having to load all of the packages associated with Magma. - Added MaHashIndex>>#keyCounts to help developers determine distribution of keys and number of duplicates, for optimizing indexes. - Some other minor fixes and optimizations.

April 21, 2010

Re: [Pharo-project] FEATURE: User chooses preferred location for MC directory repositories

by Sean P. DeNigris

> Don't know if this has already mentioned, but you can > programmatically add Directory repositories as follows: > Yes, thanks. I already fixed my image, and it made my life easier, so I wanted to contribute! Sean -- View this message in context: http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directo… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 21, 2010

Re: [Pharo-project] FEATURE: User chooses preferred location for MC directory repositories

by Dale Henrichs

Sean, Don't know if this has already mentioned, but you can programmatically add Directory repositories as follows: | repo | {'/path/to/repositories/project-1/'. '/path/to/repositories/project-2/'. '/path/to/repositories/project-3/'. } do: [:path | repo := MCDirectoryRepository new directory: (FileDirectory on: path). MCRepositoryGroup default addRepository: repo ]. ----- "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: | I'll give you my use case: | I share my projects among a few images, and I like to keep them in | sub- | directories like: | /path/to/repositories/project-1/ | /path/to/repositories/project-2/ | /path/to/repositories/project-3/ | So each one of these is a separate, unrelated repository in a common | | parent directory for ease of finding. | | So when I +Repository to each image, I have to navigate from the | default directory to my repository for each new repository. If I can | | pick a start directory once as a setting, I can add new project's sub- | | directory or open them without any navigation. | | Does that make sense? | | Sean | | On Apr 20, 2010, at 1:33 PM, "Chris Muller-3 [via Smalltalk]" | <ml-node+2017760-613088063-217701(a)n4.nabble.com | > wrote: | | > Whether the user is required to specify a "default directory" or a | > directory to a repository, it's the same task isn't it? | > | > Once you add it once to MC, it can be "added" to any other package. | > So this defaultDirectory would seem to be a feature not worth its | > weight.. | > | > | > On Mon, Apr 19, 2010 at 6:00 PM, Sean P. DeNigris <[hidden email]> | | > wrote: | > | > > | > > http://code.google.com/p/pharo/issues/detail?id=2329 | > > | > > Pharo image: Pharo 1.0 | > > | > > In Monticello Browser, when I click "+Repository" and select | > "directory," | > > I'd love to be taken right to the directory where I keep my local | > > repositories, instead of having to click to the same place over | > and over. | > > | > > I changed the following method: | > > MCDirectoryRepository class>>morphicConfigure | > > ^ (UIManager default chooseDirectoryFrom: (FileDirectory | on: | > > '/path/to/my/Repositories')) ifNotNil: | > > [:directory | | > > self new directory: directory] | > > | > > How should I store the default repository directory? Would anyone | | > else find | > > this helpful? | > > | > > Sean DeNigris | > > -- | > > View this message in context: | http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directo… | > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. | > > | > > _______________________________________________ | > > Pharo-project mailing list | > > [hidden email] | > > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > > | > | > _______________________________________________ | > Pharo-project mailing list | > [hidden email] | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > View message @ | http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directo… | > To unsubscribe from FEATURE: User chooses preferred location for MC | | > directory repositories, click here. | > | | -- | View this message in context: | http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directo… | Sent from the Pharo Smalltalk mailing list archive at Nabble.com. | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 21, 2010

Re: [Pharo-project] Error when 'Loading 11313-Pha-CleaningCompilerTests...'

by Henrik Sperre Johansen

On 19.04.2010 22:56, Sean P. DeNigris wrote: > > StÃ©phane Ducasse wrote: >> on which system are you? >> Do you use a one click image >> > Pharo image: core > Pharo core version: PharoCore1.1ALPHA #11312 > Virtual machine used: Squeak 4.2.4beta1U (Mac) > > - Sean Same error message just popped up for me when I was downloading 11311. I hit debug, inspected the stream, lo and behold, in the collection I have: *snip* "SqueakSource is currently down. We are sorry for the inconvenience and working on the problem. In the meantime you can still commit to a directory repository on your disk and later copy the versions to SqueakSource." *snip* So my guess is this is the message you get when it tries to parse the html error document as a mcz zip archive ;) Cheers, Henry

April 21, 2010

Re: [Pharo-project] FEATURE: User chooses preferred location for MC directory repositories

by Sean P. DeNigris

I'll give you my use case: I share my projects among a few images, and I like to keep them in sub- directories like: /path/to/repositories/project-1/ /path/to/repositories/project-2/ /path/to/repositories/project-3/ So each one of these is a separate, unrelated repository in a common parent directory for ease of finding. So when I +Repository to each image, I have to navigate from the default directory to my repository for each new repository. If I can pick a start directory once as a setting, I can add new project's sub- directory or open them without any navigation. Does that make sense? Sean On Apr 20, 2010, at 1:33 PM, "Chris Muller-3 [via Smalltalk]" <ml-node+2017760-613088063-217701(a)n4.nabble.com > wrote: > Whether the user is required to specify a "default directory" or a > directory to a repository, it's the same task isn't it? > > Once you add it once to MC, it can be "added" to any other package. > So this defaultDirectory would seem to be a feature not worth its > weight.. > > > On Mon, Apr 19, 2010 at 6:00 PM, Sean P. DeNigris <[hidden email]> > wrote: > > > > > http://code.google.com/p/pharo/issues/detail?id=2329 > > > > Pharo image: Pharo 1.0 > > > > In Monticello Browser, when I click "+Repository" and select > "directory," > > I'd love to be taken right to the directory where I keep my local > > repositories, instead of having to click to the same place over > and over. > > > > I changed the following method: > > MCDirectoryRepository class>>morphicConfigure > > ^ (UIManager default chooseDirectoryFrom: (FileDirectory on: > > '/path/to/my/Repositories')) ifNotNil: > > [:directory | > > self new directory: directory] > > > > How should I store the default repository directory? Would anyone > else find > > this helpful? > > > > Sean DeNigris > > -- > > View this message in context: http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directo… > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > View message @ http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directo… > To unsubscribe from FEATURE: User chooses preferred location for MC > directory repositories, click here. > -- View this message in context: http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directo… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 20, 2010

Re: [Pharo-project] [Vm-dev] Re: FFI in 1.1

by Bert Freudenberg

On 21.04.2010, at 00:09, Eliot Miranda wrote: > Hi All, > > 2010/4/20 John M McIntosh <johnmci(a)smalltalkconsulting.com> >> Well I asked for it... >> >> (a) you can get graphic cut/copy/paste of complex data on the macintosh and windows. Linux too. Etoys on the OLPC does images and rich text copy/pasting just fine. Not sure what that has to do with FFI though? ExtendedClipboard is a plugin. Seems I missed some earlier discussion ... - Bert -

April 20, 2010

Re: [Pharo-project] FFI in 1.1

by Eliot Miranda

Hi All, 2010/4/20 John M McIntosh <johnmci(a)smalltalkconsulting.com> > Well I asked for it... > > (a) you can get graphic cut/copy/paste of complex data on the macintosh and > windows. > > (b) I'd rather have people learn FFI & Alien so they can build their own > api to Rome, Pango, & Curl instead of waiting on about 4 people in the world > to get around to building and distributing *official* plugins . > I agree with this, but I also understand the security and modularity concerns of those who want to deploy without FFI and with plugins only. I think it might be worth-while, and would certainly be feasible and fun, to write an automatic plugin generator, e.g. above David's SmartSyntaxPlugin, that would take a set of FFI methods and shrink-wrap them into a plugin. So the natural development cycle for plugins could become prototype and extend using the FFI and deploy via the generator and a plugin compilation step. That would be analogous to the approach taken to produce the VM itself. I hope this approach would make it easier for people to produce plugins, since more of the gubbins <http://www.thefreedictionary.com/gubbins> would be hidden. That might be naive given complications with mapping object and memory references across the boundary, but it might also be an easier way to integrate things like Andreas' proposed handle framework<http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004106.html> . > (c) When your curl, rome, etc FFI call freaks and toasts your image why you > can do debugging, versus relying on a handful of people in the world to > grind thru some compiler, gnu debug session to figure out why that register > move results in a fatal Virtual memory page fault. > Certainly we got some good mileage out of catching external errors in FFI calls and returning these as primitive error codes. Basically it helps you find which FFI calls cause crashes, because the system will typically stay up long enough for you to open the debugger and identify which FFI call failed and what its arguments were. Why the call failed isn't so easy. The errr codes are an address and some OS-specific exception identifier. One then either has to think hard (infer from the args why the call might fail) or decamp to a low-level debugger, rerun the call and use any additional info it provides to debug the call. This is easy to add to the current VM which already has fatal signal handlers and primitive error codes. The FFI must set a flag "in FFI call" (clearing on callback, resetting on return from callback) which is tested in the fatal signal handlers and cause the exception info to be squirrelled away and the FFI call to fail. If the VM has enough state to take a callback it typically has enough state to cause the current FFI callout to fail and from the fatal signal handler longjmp to somewhere that can continue execution through the primitive failure. (and if it doesn't now, it can be made to, and not on every FFI call either, e.g. the interpreter can call setjmp prior to entering the interpreter loop, Cog does this to be able to switch between native code and interpreted code) 2Â¢ Eliot > > > On 2010-04-19, at 11:41 PM, Torsten Bergmann wrote: > > >> I wouldn't include neither FFI or Alien FFI in neither PharoCore or > PharoDev > >> image. > > > > +1 > > > >> That's only my opinion. > > > > Maybe Stef should tell us more about why he thinks it should be included. > > > > Bye > > T. > > > > -- > > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 20, 2010

Re: [Pharo-project] FEATURE: User chooses preferred location for MC directory repositories

by Michael Roberts

i'm not sure what either of you mean. I want there to be no UI choice and the system just looks higher up in the file system hierarchy. certainly environment variables or a .pharorc style file would solve this. thanks, Mike On Tue, Apr 20, 2010 at 6:33 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > Whether the user is required to specify a "default directory" or a > directory to a repository, it's the same task isn't it? > > Once you add it once to MC, it can be "added" to any other package. > So this defaultDirectory would seem to be a feature not worth its > weight.. > > > On Mon, Apr 19, 2010 at 6:00 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> http://code.google.com/p/pharo/issues/detail?id=2329 >> >> Pharo image: Pharo 1.0 >> >> In Monticello Browser, when I click "+Repository" and select "directory," >> I'd love to be taken right to the directory where I keep my local >> repositories, instead of having to click to the same place over and over. >> >> I changed the following method: >> MCDirectoryRepository class>>morphicConfigure >> Â Â Â Â ^ (UIManager default chooseDirectoryFrom: (FileDirectory on: >> '/path/to/my/Repositories')) ifNotNil: >> Â Â Â Â Â Â Â Â [:directory | >> Â Â Â Â Â Â Â Â self new directory: directory] >> >> How should I store the default repository directory? Â Would anyone else find >> this helpful? >> >> Sean DeNigris >> -- >> View this message in context: http://n4.nabble.com/FEATURE-User-chooses-preferred-location-for-MC-directo… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 20, 2010

Re: [Pharo-project] what expectedfailures expected to do?

by Adrian Lienhard

Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. Adrian On Apr 20, 2010, at 21:57 , StÃ©phane Ducasse wrote: > Hi > > I tagged some tests as expected failures and I got a strange behavior. > On the the tests which was passing was listed under the failures. > When I renamed the method without updating the expected failures my bar was green. > So expected failures really expect that the tests failed? We cannto have green tests in there? > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 20, 2010

Re: [Pharo-project] Addition to the Success story page

by Adrian Lienhard

I added the link. Cheers, Adrian On Apr 20, 2010, at 18:46 , Mariano Martinez Peck wrote: > On Tue, Apr 20, 2010 at 9:56 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > >> I added the link. >> >> Re UTN, I wait for a URL. >> >> > It is still under construction: > http://sites.google.com/site/paradigmasdeprogramacion/ > > And here you can read about Pharo: > > http://sites.google.com/site/paradigmasdeprogramacion/Home/software/softwar… > > Cheers > > Mariano > > > >> Cheers, >> Adrian >> >> On Apr 20, 2010, at 05:45 , Mariano Martinez Peck wrote: >> >>> On Thu, Apr 15, 2010 at 10:04 PM, StÃ©phane Ducasse < >>> stephane.ducasse(a)inria.fr> wrote: >>> >>>> excellent idea. >>>> I know that there are other university or engineering schools in >> argentina. >>>> I will check that with mariano when he is back >>>> >>>> >>> University of Buenos Aires (UBA) >>> Signature: Algoritmos y programaciÃ³n 3 >>> >>> This is the link: (go to where it says "recursos" if you want) >>> http://materias.fi.uba.ar/7507/ >>> >>> Tomorrow I will give a talk there ;) >>> >>> Please, also add UTN as Carla said. >>> >>> Cheers >>> >>> Mariano >>> >>> >>>> On Apr 15, 2010, at 9:58 PM, Alexandre Bergel wrote: >>>> >>>>> Hi! >>>>> >>>>> Would it be possible to add on the page >>>> http://www.pharo-project.org/about/success-stories : >>>>> "University of Chile" in the Universities teaching in Pharo ( >>>> http://www.uchile.cl/) and >>>>> "PLEIAD / DCC" in the Research groups using Pharo ( >> http://www.pleiad.cl >>>> ) >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 20, 2010