July 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] pharo-2.0-tests Â» 32,mac - Build # 199 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

July 9, 2012

[Pharo-project] pharo-2.0-tests Â» 32,linux - Build # 199 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

July 9, 2012

Re: [Pharo-project] Cairo, VM?

by Hilaire Fernandes

I need to adjust the path to the Cairo lib. Some cleaning seems to be needed as nbLibraryNameOrHandle is redefined several time. Or do I misunderstand something with the Trait ? Hilaire On 07/07/2012 21:53, Igor Stasenko wrote: > On 7 July 2012 21:44, Hilaire Fernandes <hilaire.fernandes(a)edu.ge.ch> wrote: >> And for the Linux VM? >> All are good? >> > linux NBCog should work just fine. > >> >> Thanks >> >> Hilaire >> >> On 07/07/2012 06:26, Igor Stasenko wrote: >>> RIght now for macs only.. >>> https://ci.lille.inria.fr/pharo/view/NativeBoost/job/NB-Cog-Mac-Cocoa/29/ >>> >>> (well, actually linux one is *ready* too , you just need to install >>> cairo library by yourself, >>> and even, AFAIK, it is there by default in many linux distros >>> >>> on linux we don't need to care about bundling. >>> >> >> >> -- >> Dr. Geo -- http://www.drgeo.eu >> >> >> >> > > > -- Dr. Geo -- http://www.drgeo.eu

July 9, 2012

[Pharo-project] Job Pharo-2.0-Numbered

by Pavel Krivanek

Hi, if you often download latest development Pharo versions from Jenkins, you may have a mess in the downloaded files because for all builds the archives and images have the same name. I created a Jenkins job that creates an archive named by the latest update number. So you will get something like this: Pharo-2.0-20196.zip - Pharo-2.0-20196.image - Pharo-2.0-20196.changes - PharoV10.sources link: https://ci.lille.inria.fr/pharo/view/Pharo%202.0/job/Pharo-2.0-Numbered/ -- Pavel

July 9, 2012

[Pharo-project] [update 2.0] #20197

by Marcus Denker

20197 ----- Issue 6312: Failing test on windows: MCDataStreamTest http://code.google.com/p/pharo/issues/detail?id=6312 Issue 6310: Failing test on Windows: ZipArchiveTest>>testCreateWithRelativeNames http://code.google.com/p/pharo/issues/detail?id=6310 -- Marcus Denker -- http://marcusdenker.de

July 9, 2012

Re: [Pharo-project] [ANN]: Vim Shortcuts for Nautilus (Proof-of-concept)

by Guillermo Polito

On Sun, Jul 8, 2012 at 2:52 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > Benjamin Van Ryseghem-2 wrote > > > > If I were you, I would have put all the VIM shortcut in one class, > instead > > of putting them around but :) > > > I'll keep that in mind once I get it working ;-) > > > Benjamin Van Ryseghem-2 wrote > > > > Like that, you could add yours in a specific context, and remove them. > > > Any luck finding those detach* methods? Googling/Nabbling > "detachKeymapCategory" turned up nothing. > > Also, I think of my use case here for the "enter command mode" shortcut as > "Change the default shortcuts for a Morph class". It seems that what's > required for this type of use is a registration mechanism more like the > world menu. For the world menu, I can insert an entry at any level, not > just > an existing one, without overriding anything. In KM currently, in order to > do this, it seems we're forced to hitch a ride on an existing category. > Maybe a special pragma indicating that certain categories should be > attached > for the class by default. > > In summary, I'm still unclear on the relationship between the class-side > <keymap> defaults methods and changing shortcuts on the fly, but what seems > to be missing are: > * a way to register shortcuts/categories to be attached to a Morph class by > default > Nope :). Look at http://www.smalltalkhub.com/mc/Guille/Keymappings/main, in Keymapping-Morphic, KMWindowsKeymaps class>>buildGlobalKeymappingsOn:. The last line: aBuilder attachShortcutCategory: #Window to: SystemWindow. Those are static keybindings, and they were the first ones. I think I have to spend some hours in providing examples... > * a way to detach categories > I'll integrate them again. Ben, somehow the dettach* methods dissapeared from KMDispatcher in latest 2.0 :/. I'll have a look and integrate all of them in latest Keymapping version. > * a way to detach individual shortcuts > You mean removing a shortcut from a category? Or to ban a shortcut from a morph? Because here, I will be a bit strict with the nomenclature so we understand each other :) : - Static category keymappings: you attach a category to a class. ( The one in the example above ) - Dynamic category keymappings: you attach dinamically a category to an object. (the one you've used so far) - Dynamic object keymappings: you attach a single shortcut to an object, sending the #on:do: message So, were you using the third one? Removing a keymap from a category, which removes it from all the objects who use it, is easy but removing just for one object is not there, because the keymaps are looked up in the configuration, not flattened on the object. > Thanks, this is very exciting. We're *so* close to having this work... > Sean > > -- > View this message in context: > http://forum.world.st/ANN-Vim-Shortcuts-for-Nautilus-Proof-of-concept-tp463… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

July 9, 2012

Re: [Pharo-project] Solving the fact that http://source.lukas.renggli.ch/ is down

by Damien Cassou

On Sat, Jul 7, 2012 at 1:48 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Any idea why Lukas stops his servers? remember we have a dropbox folder with all mcz. Please ask if you are interested -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 9, 2012

[Pharo-project] View from an outsider [was Re: Pharo and Namespaces]

by Patrik Sundberg

On Jun 27, 2012; 4:27pm, Stephane Ducasse wrote: > On Jun 27, 2012, at 4:44 PM, James Foster wrote: > >> Stef, >> >> I'm sorry to hear about your burnout and I understand that you are not >> prepared to seriously discuss the issues that others have raised. I hope >> when the issue is raised again (it does seem to come up every year or >> so!) we can correct some of the misunderstandings that exist. > >yes we are discussing regularly that topic and Camille is writing a master where all the points are discussed and summarized with pros and cons. >Now for 20 we should finish all the open tracks we have. > >Stef Hi, A comment from a complete outsider: I've been following pharo on the side for the last year or so and am very impressed by both smalltalk as a language and pharo as an implementation. I am not trying to even voice an opinion of what's right to focus on for pharo project since that's not my place having nothing invested in it (so far, gearing up to add some pharo parts to my world). It did strike me that it could be interesting to hear the view from an outsider on what would draw interest and more users/developers to the project. Be it inspiration for pharo 2.1 or 3.0 or 4.0 :) I'll first state a belief: I believe that the explosive growth of ruby and python communities to some extent depended on good package management systems making it very easy for people to publish/share/collaborate on packages. A killer app to kick it off, but one needs easy collaboration to grow. On the back of that I'm very excited to see the following pharo efforts being close to coming together into something great: 1. Stripped down core kernel and bootstrap project 2. Fuel for fast serialization and deserialization (can be used for binary packages) 3. FileTree 4. Metacello scripting API 5. Metacella Git/Github integration 6. Tools such as Versionner on top of Metacello for ease of use 7. Namespaces/Environments In terms of getting a lot of people much more comfortable diving into the image world I think that list have great promise. If one can easily start with a minimal kernel, have some simple tooling such that one from e.g. the commandline can bootstrap it via Metacello configurations that pulls in both the parts of the base system one needs and project/application dependencies to get a working image for both development and deployment (via metacello groups for example) it has 2 benefits: 1. Reproducible process which means automation and testing a lot easier for projects (jenkins etc for applications), as well as deployment 2. It's a workflow that's quite similar to how one would for example work with ruby, rubygems and bundler (on a high level). Familiarity draws in more people - it shouldn't be at the cost of a good system, but if one can get both it's a definite positive. Once project/appliation bootstrapped like that and one is working in the image tools like Versionner and Metacello with git/github intregration will provide an excellent workflow for collaboration (push/pull/merge/branch/etc). Again I see 2 benefits: 1. Functionally solid (see e.g. the Practical Git for Smalltalk presentation by Dale) 2. It's familiar to outsiders and has a good chance of attracting new people. Even if one has great in image tooling it's very good to be able to be a "lazy" follower of a package/project via e.g. github (RSS feeds for changes, nice diffs accessible from any web browser, pull requests, graphical representation of branches etc etc). I for example would be much more likely to have learnt more on pharo implementation if I could have followed it on github for the last year. When collaboration increases and people share a lot of packages via e.g. git & github one tend to see exponential reuse and number of new packages created (on the back of what exists), and at least the ruby experience is the average number of package dependencies for a project increases. It's in that point of view I'm seeing namespaces/environments as an important addition. Prefixing names is doable and at a non-human level you can accomplish most of the same things, but on a human level I see it as important - and it gets more important the more collaboration and reuse of existing packages one accomplishes. A non-technical consideration is that developers these days kind of expects some form of namespacing to exist and not seeing it available is something to deter some possible adopters (rightly or wrongly, many times they wouldn't need namespaces/environments, but many may not reflect too deeply on that). I know I twigged at first seeing prefixing being used instead of some form of namespaces. >From that this perspective (namespaces/environments more important as more people are, reuse and collaboration happens) it seems quite sensible to put it after the other things on the todo list (as long as it doesn't goes away completely). Hopefully that's of some interest :) I'll continue my journey towards using pharo more - we shall see how it works out for me! Regards, Patrik -- View this message in context: http://forum.world.st/Pharo-and-Namespaces-tp4636635p4639158.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 8, 2012

[Pharo-project] [update 2.0] #20196

by Marcus Denker

20196 ----- Issue 6316: Restore display when launching transcripter via menu http://code.google.com/p/pharo/issues/detail?id=6316 Issue 6307: UI inform dialog should use our "growl" stuff http://code.google.com/p/pharo/issues/detail?id=6307 Issue 6293: Fix FIleSystemTest >> #testReferenceTo http://code.google.com/p/pharo/issues/detail?id=6293 -- Marcus Denker -- http://marcusdenker.de

July 8, 2012

Re: [Pharo-project] [ANN]: Vim Shortcuts for Nautilus (Proof-of-concept)

by Benjamin

Here is the detach methods filed out. They are still extensions here, but they should be moved directly into KM We will succeed :P Ben On Jul 8, 2012, at 2:52 PM, Sean P. DeNigris wrote: > > Benjamin Van Ryseghem-2 wrote >> >> If I were you, I would have put all the VIM shortcut in one class, instead >> of putting them around but :) >> > I'll keep that in mind once I get it working ;-) > > > Benjamin Van Ryseghem-2 wrote >> >> Like that, you could add yours in a specific context, and remove them. >> > Any luck finding those detach* methods? Googling/Nabbling > "detachKeymapCategory" turned up nothing. > > Also, I think of my use case here for the "enter command mode" shortcut as > "Change the default shortcuts for a Morph class". It seems that what's > required for this type of use is a registration mechanism more like the > world menu. For the world menu, I can insert an entry at any level, not just > an existing one, without overriding anything. In KM currently, in order to > do this, it seems we're forced to hitch a ride on an existing category. > Maybe a special pragma indicating that certain categories should be attached > for the class by default. > > In summary, I'm still unclear on the relationship between the class-side > <keymap> defaults methods and changing shortcuts on the fly, but what seems > to be missing are: > * a way to register shortcuts/categories to be attached to a Morph class by > default > * a way to detach categories > * a way to detach individual shortcuts > > Thanks, this is very exciting. We're *so* close to having this work... > Sean > > -- > View this message in context: http://forum.world.st/ANN-Vim-Shortcuts-for-Nautilus-Proof-of-concept-tp463… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

July 8, 2012