- Pharo-dev - lists.pharo.org

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

by laurent laffont

On Tue, Apr 20, 2010 at 11:21 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > 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. > On my machine I've written these files: ~/.pharorc.st Author fullName: 'LaurentLaffont'. MCRepositoryGroup default addRepository: (MCDirectoryRepository new directory: (FileDirectory on: '/home/laurent/pharo/repository')). Then ~/bin/pharo: #!/bin/sh squeak $1 ~/.pharorc.st Then I launch my image with: pharo /path/to/my.image Author and repository always set for every image. Very emacs-like :) Cheers, Laurent Laffont 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 > > _______________________________________________ > 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] what expectedfailures expected to do?

by StÃ©phane Ducasse

On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: > Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. > > 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 > > > _______________________________________________ > 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] FEATURE: User chooses preferred location for MC directory repositories

by StÃ©phane Ducasse

we should add that to the pharo book :) On Apr 21, 2010, at 2:42 AM, Dale Henrichs wrote: > 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 > > _______________________________________________ > 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] [Vm-dev] Re: FFI in 1.1

by Andreas Raab

On 4/20/2010 3:37 PM, Bert Freudenberg wrote: > > 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 ... Where is ExtendedClipboardPlugin? I've never seen it. Cheers, - Andreas

April 21, 2010

Re: [Pharo-project] [Vm-dev] Running Alien on Windows

by Andreas Raab

Hi Torsten - Thanks for cc-ing vm-dev; I wouldn't have seen this post otherwise. I've actually looked at the code since and there's some good news here: It appears that there's no actual modification of the Windows support code necessary to use Alien. The only difference is a flag in sqWin32Window.c which for all intents and purposes appears to be completely unused. That leaves the question of how to deal with the patches to the VMMaker code base. As you know, my "official" VMs are always built from the "official" sources (i.e., the latest VMMaker package on http://www.squeaksource.com/VMMaker.html) and if you'd like to help getting Alien support into the standard builds we should figure out how to integrate these patches. Perhaps David and/or Eliot can help? From my perspective this issue doesn't really belong with the Windows VM but rather with the VMMaker package. I just build whatever is in there, so if Alien support is in, then I'll build it together with everything else. Cheers, - Andreas On 4/20/2010 10:24 AM, Torsten Bergmann wrote: > > Bouraqadi Noury wrote on pharo-dev >> We have trouble running alien on Windows. Starting from a clean pharo >> 1.0 image and the latest VM, > > Would not work out of the box with the VM since it requires > VM changes. Marco ported them from Newspeak > and made them available [1]. Tests went green and > he is sucessfully using Alien on Windows. But it is not yet > in the official Squeak VM (which is 4.0.2.). > > There is also an issue for pharo [2] and an issue for > VM developers [3] to follow progress. > > So the code is there and is ready for integration. > Andreas asked for the license [4], Marco answered > that code was from Newspeak [5]. > > After that we got a good response from John McIntosh > on the license issue [6] which should be OK now. > (Dont know, I'm not a lawyer) > > After I asked Andreas again he answered that it is not > highest priority for him which I understood since > Squeak 4.1 was in preparation. See last response > regarding this [7] > > Dont know what should be the next steps to get Alien > into the Win32-VM code base. Maybe Andreas could tell > you more. > > As a workaround you could use the source provided > by Marco to build your own unofficial VM - however > you would have to reintegrate anytime Andreas makes > a new release... > > Bye > T. > > [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/003983.html > [2] http://code.google.com/p/pharo/issues/detail?id=1360 > [3] http://bugs.squeak.org/view.php?id=7475 > [4] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004034.html > [5] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004037.html > [6] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004054.html > [7] http://lists.squeakfoundation.org/pipermail/vm-dev/2010- > March/004103.html >

April 21, 2010

Re: [Pharo-project] FFI in 1.1

by Igor Stasenko

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 . > > (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. > +++100 > > 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 > -- Best regards, Igor Stasenko AKA sig.

April 21, 2010

Re: [Pharo-project] FFI in 1.1

by Igor Stasenko

2010/4/20 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Thu, Apr 15, 2010 at 9:31 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> Hi all >> >> Do we add FFI by default in 1.1? > > Noooooooooo!!! > > I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev > image. > > FFI is an EXTERNAL package, NOT core, neither a dev tool. > Frankly, its a dev tool. What else it is if not a dev tool? You have to be extremely careful, as with anything which using C or binary interfaces, but apart from it, i see nothing wrong with it. How else you can easily bind an external API to image? Writing a plugin? You could, but what the point in spending a lot of hours writing a primitives for each API function, when in the end, you still will be doing pretty same thing: using external api? > That's only my opinion. > > Cheers > > Mariano > >> >> This was the plan so. >> >> Stef >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

April 21, 2010

[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