- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Crazy Smalltalk code snippets

by Tudor Girba

+1 Doru On Wed, Mar 26, 2014 at 8:26 AM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Hi frank > > It would really great if you send an article on this to the ESUG workshop. > I can help reviewing the draft if you want. > Stef > > > Yes: http://ss3.gemstone.com/ss/Control.html > > > > Last time I checked I did need to add a shim (see the ControlPharo > > package), but it did load cleanly and pass all its own tests. > > > > Control not only provides a convenient way of making partial > > continuations (of the shift/reset sort, if you're familiar with the > > literature), but also _delimited_ dynamic variables. As soon as you > > start stack-slicing with partial continuations, you quickly find that > > standard implementations of dynamic variables fail in all sorts of > > nasty ways. Fundamentally, "normal" dynamic variables _cannot_ work > > cleanly with partial continuations because they either close over too > > much of the dynamic environment, or too little. > > > > Here's some reading on the topic: > > > > [1] http://okmij.org/ftp/Computation/dynamic-binding.html > > [2] http://www.cs.rutgers.edu/~ccshan/dynscope/DDBinding.pdf > > [3] > http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-expres… > > > > frank > > > >>>>> Cheers, > >>>>> -- Pavel > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> best, > >>> Eliot > >> > >> > > > > > -- www.tudorgirba.com "Every thing has its own flow"

March 26, 2014

Fixing inconsistent buttons look in PharoUI

by Philippe Back

I've made a pass at fixing the buttons look (border in some places, no border in others). Spec-generated buttons are using the ButtonModel and MorphicButtonAdapter but the defaultSpec fo the the ButtonModel is asking the borderWidth and borderColor from the model, which is all nice but should be looking like the standard PluggableButtonMorphs, which do have a border. So, aligned now. https://pharo.fogbugz.com/default.asp?13135 Slice in inbox: SLICE-Issue-13135-Inconsistent-look-of-buttons-across-tools-Border-no-border -PhilippeBack.1 Phil --- Ce courrier Ã©lectronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com

March 26, 2014

When change on class with trait freeze

by Hilaire Fernandes

https://pharo.fogbugz.com/f/cases/13133/When-change-on-class-with-trait-fre… -- Dr. Geo http://drgeo.eu

March 26, 2014

Re: [Pharo-dev] Use Spotlight to quickly evaluate and inspect short expressions

by Pharo4Stef

I like the idea now it is importznt that spotlight found class , method, package well :) Stef On 25 Mar 2014, at 14:30, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I had this idea: > > https://pharo.fogbugz.com/f/cases/13128/Use-Spotlight-to-quickly-evaluate-a… > > now you can do > > <shift-Enter>:42<Enter> > > to inspect the magic number 42 > > <shift-Enter>:1500*1.25<Enter> > > to quickly compute your 25% raise > > <shift-Enter>:Float pi<Enter> > > to see how many decimals you still remember > > <shift-Enter>:ZnClient new get: 'http://zn.stfx.eu/zn/small.html'<Enter> > > and so on. > > The interaction with the completion menu is not 100% perfect, but pressing <Space> at the end before <Enter> solves that. > > Feedback ? > > Sven > > PS: I know that many Smalltalk greybeards type everywhere to the same effect, and that is cool to, but it leaves around dirty windows. Opening a workspace for a single expression often is overkill. This feature is totally keyboard driven and very clean. > > PS2: Yes it resembles Emacs' M-: (evaluate-expression), but Pharo is much cooler, right ;-) > >

March 26, 2014

Flat button look in Pharo3

by Philippe Back

I grew really fed up of the blue -> gray gradients in the Pharo3Theme. Watching it all day long was too much, so I embarked on looking inside. Check https://pharo.fogbugz.com/default.asp?13132 and the SLICE-Issue-13132-Ugly-gradients-in-Pharo3Theme-Not-in-line-with-the-times-P hilippeBack.1 Phil --- Ce courrier Ã©lectronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com

March 26, 2014

Re: [Pharo-dev] Crazy Smalltalk code snippets

by Pharo4Stef

Hi frank It would really great if you send an article on this to the ESUG workshop. I can help reviewing the draft if you want. Stef > Yes: http://ss3.gemstone.com/ss/Control.html > > Last time I checked I did need to add a shim (see the ControlPharo > package), but it did load cleanly and pass all its own tests. > > Control not only provides a convenient way of making partial > continuations (of the shift/reset sort, if you're familiar with the > literature), but also _delimited_ dynamic variables. As soon as you > start stack-slicing with partial continuations, you quickly find that > standard implementations of dynamic variables fail in all sorts of > nasty ways. Fundamentally, "normal" dynamic variables _cannot_ work > cleanly with partial continuations because they either close over too > much of the dynamic environment, or too little. > > Here's some reading on the topic: > > [1] http://okmij.org/ftp/Computation/dynamic-binding.html > [2] http://www.cs.rutgers.edu/~ccshan/dynscope/DDBinding.pdf > [3] http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-expres… > > frank > >>>>> Cheers, >>>>> -- Pavel >>>> >>>> >>> >>> >>> >>> -- >>> best, >>> Eliot >> >> >

March 26, 2014

Re: [Pharo-dev] Location of Metacello package dependency

by Nicolas Cellier

2014-03-23 8:14 GMT+01:00 Johan Brichau <johan(a)inceptive.be>: > I reflected a bit more on your requirements. How about the following? > > Put a separate reference for the project in each platform-specific > section. I combine this with a #file: declaration because otherwise your > package cache will play dirty tricks on you if it has a newer version of > the ConfigurationOfB in it. This is really important. > > spec for: #common do:[ > > spec project: 'B' "empty def to allow dependency reference inside > the #common secion" > ] > > spec for: #pharo2.x do:[ > > spec > project: 'B' > with: [ > spec > className:'ConfigurationOfB'; > versionString: #stable; > file: 'ConfigurationOfB-johndoe.1.mcz'; > repository: '<meta repo for pharo 2.0>' > ] > ] > > spec for: #pharo3.x do:[ > > spec > project: 'B' > with: [ > spec > className:'ConfigurationOfB'; > versionString: #stable; > file: 'ConfigurationOfB-johndoe.2.mcz'; > repository: '<meta repo for pharo 3.0>' > ] > ] > > Thanks Johan, that makes sense. I understand that specifying a specific version of ConfigurationOfB is defensive, and in theory, yes that's the configuration I tested. Anything newer may fail - letting case of broken configuration apart, the #stable version could go thru a major revision and the API become uncompatible... What I'd like better would be semantic versionning style major.minor.revision rather than symbolic #stable. This way, when I would specify version 3.2+.x of project B, that would mean major=3, minor>=2, any revision. But right now, can we really trust such semantic numbering policy? The other thing I'd like is to somehow specify: - pick the configuration in official catalog for this dialect It makes perfect sense to somehow factor it out. Otherwise, imagine that this information will be repeated in a hundred packages or so... Thus a specific pharo.y.x requirement would be exceptionnal, if ever a configuration was not yet officially ready in the catalog. Last thing, I don't really want to protect myself from a broken ConfigurationOfB in the catalog for at least 2 reasons: 1) If I freeze a ConfigurationOfB version, then I can't profit by newer bug fixes, or worse, I'm subject to configuration rot due to package motion (like it was erased from squeaksource then ss3 then ...) 2) A transfer to official catalog implies that the ConfigurationOfB is at least maintained and cared upon and will be fixed within a few days. In between I can rely on copying older images rather than re-installing, but that's just me. As for the package-cache, I didn't face the problem so far because Pharo one click comes with its own package-cache and I renew the install rather often (note that often but the interval of time between two glimpses of Pharo is long enough such that the update stream rarely works for me). But it sounds to me like a package-cache problem, and if it is, we should better correct it than patching like mad our already complex enough Configuration as a workaround. On 22 Mar 2014, at 23:06, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > > We were discussing about that. > > My point is that the system should work if the catalog fall apart. > > Now others told me that in other community this is the inverse. People > only refer to the catalog. > > > > Since we did not get last year and this year the engineer I requested to > work on the validation of distirbution we did not make progress > > on that front because we are busy. > > > > For me I do not use SqueakSource not because it is written Squeak but > because I think that squeaksource is over and too old. > > > > Stef > > > >> I'm currently browsing the various ConfigurationOf in > MetaRepoForPharo30 catalog hoping to find a pattern to serve as guidelines, > but what I see is a messy variety of solutions: > >> > >> - direct reference to specific source repositories of package B as > Johan suggested (and the successive baselines are effectively tracking > motions of B) > >> IMO the worst thing, I don't manage B and don't want to update my > ConfigurationOfA each time B moves. > >> > >> - references to ConfigurationOfB thru squeaksource MetacelloRepository. > >> My preferred solution. I don't care if the catalog is centralized on > squeaksource, Smalltalkhub or whatever, but I want a centralized catalog > > > > Me too. > > Now the question is the following one. > > Ideally I would like to have one inbox and that configuration move to > the catalog for their version. > > (Because I do not see the point of having around old versions of > projects that do not load in the given version). > > I explained that in the Pharo vision document. > > Now may be other solutions are better. > > > > Stef > > > > > >> > >> - refrences thru MetaRepo catalog du jour (tracking motions of MetaRepo > across baselines) > >> My original question, using secondary catalogs is not a problem if they > are just a duplicata, but I prefer to ask, because it sounds strange to > have multiple catalogs just to implement a filter (the filter being select > those packages that are tested and approved in pharo x.y)... Certainly a > workaround for a missing feature of Metacello. > >> > >> - a mixture of the 3 solutions above for some packages! > >> That appears as randomness from my POV, or like of guidance > >> > >> So again, what are the best practices currently, and could we think of > it in a bit longer term? > >> > >> > >> 2014-03-22 21:51 GMT+01:00 Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com>: > >> > >> 2014-03-22 21:27 GMT+01:00 Johan Brichau <johan(a)inceptive.be>: > >> > >> I don't understand what squeaksource has to do with that. > >> With main repository, I mean the repository of the project itself. > >> > >> Almost all ConfigurationOfXXX are hosted together with the project > itself. They are also referenced in that repo. The MetacelloRepo or > MetaRepos are almost always secondary copies (if not, they should be) > >> > >> Johan > >> > >> > >> Arghh NOOOO, so that is really going to be a problem for me ! > >> With MetacelloRepository I absolutely don't care where to find a > specific package, I have some kind of centralized catalog. > >> > >> Now, if I must track each and every motion of package B from > squeaksource to ss3 to SmalltalkHub to github to (what's next ?), the idea > of catalog is completely broken then... > >> > >> Nicolas > >> > >> > >> On 22 Mar 2014, at 21:10, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> > >>> OK, if the MetacelloRepository on squeaksource can still serve as > reference, I'm perfectly OK with it, I don't know why I had this impression > that anything beginning with those 6 letters was going to be seen as a > problem ;) > >>> > >>> > >>> 2014-03-22 18:53 GMT+01:00 Johan Brichau <johan(a)inceptive.be>: > >>> Why can you not reference the main repository? The meta repository is > just a place where the configuration loader tool fetches them. > >>> > >>> Platform-specific elements go in the separate 'sections' of a baseline > or version method. > >>> > >>> Don't make separate branches of the same ConfigurationOf class. You > will not only make your life hard but also confuse all users! > >>> > >>> Maybe you can explain why you think you need those? > >>> > >>> Johan > >>> > >>> On 22 Mar 2014, at 18:20, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >>> > >>>> I have some packages A that depend on another package B. > >>>> In Metacello, I can easily declare the dependency > >>>> spec > >>>> className: 'ConfigurationOfB'; > >>>> versionString: #'stable'; > >>>> repository: ' > >>>> http://www.squeaksource.com/MetacelloRepository' ]. > >>>> But the repository is hardcoded here. > >>>> > >>>> My problem is that I'd like to edit a ConfigurationOfA valid for > pharo 1.x, 2.0.x and 3.0.x (so far so good) and put a copy in > MetaRepoForPharo20 and another copy in MetaRepoForPharo30. > >>>> > >>>> Since the repository is hardcoded, this is going to be a problem > because the MetaRepo will then cross-ref other repositories and weaken > robustness or miss uptodate ConfigurationOfB... > >>>> > >>>> I'd like to avoid maintaining many branches of ConfigurationOfA. > >>>> > >>>> How do others resolve this? > >>> > >> > >> > > > > >

March 25, 2014

Re: [Pharo-dev] [Pharo-fuel] FileSystemGit and Fuel final report

by Max Leske

On 25.03.2014, at 19:43, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > When I see all the interactions and people helping I think that this was really worth :) Yes, me too. > Thanks for ESUG for sponsoring your trip (like that we can reinvite with RMOD money). Cool! > > Stef > On 24 Mar 2014, at 10:06, Max Leske <maxleske(a)gmail.com> wrote: > >> For those whoâve been interested in what went on during the last two weeks, where I visited Lille, Iâve compiled a short report. Regarding my work on Git Iâll continue to report on the status from time to time. >> >> I want to thank everyone at RMoD once again for the warm welcome and the support I received. Special thanks to Ben and Camillo for providing a place to crash at. >> Thanks also go to all of you guys and girls on the list for pushing Pharo constantly and for showing interest in my work. Itâs very encouraging. >> >> Cheers, >> Max >> >> >> Git: >> - Esteban Lorenzano and me worked together on preparing the libgit2 and libssh2 libraries for integration into the VM >> - Igor Stasenko worked with me to solve a couple of problems I had with NativeBoost. Especially callbacks can be tricky >> - Learnt how to build the VM in debugging mode so that I could debug FFI calls in XCode >> - Stefan Marr worked with me on moving the tests from Phexample to SUnit >> - The implementation now enables writing of blobs, trees and commits, cloning of remote repositories (https), fetching from remote repositories (https), pushing to remote repositories (https) >> - Authentication with remote repositories via SSH is working but clone, fetch, push don't work yet (problems with the libssh2 interaction that I wasn't able to resolve yet) >> - I set up an initial build infrastructure on the INRIA CI server (https://ci.inria.fr/pharo-contribution/job/LibGit2/) >> - We defined a rough roadmap for what needs to be done in the near future: >> 1. finish the low level libgit2 abstraction (offer a minimal API that hides the bindings; we don't want users to use the bindings directly) >> 2. we already have a prototype of a FileSystem wrapper for Git. We want to use that on top of the libgit2 abstraction layer >> 3. we already have a Monticello FileSystem wrapper prototype. We want to use that to abstract from the actual storage method. Together with the Git-FileSystem wrapper this should make it very easy to continue (for now) using Monticello and the existing GUI tools while using Git as a backend for storage. >> - On Friday 21 I gave a short demo at RMoD on the work accomplished and what the plans are for the future >> >> Fuel: >> - MartÃn Dias and I worked together on: >> - debugging a problem with large object graphs >> - preparing a new baseline for Fuel 2 >> - moving the benchmark suite to SMark >> - setting up a benchmark build on the INRIA CI server which will help us track performance changes when introducing changes >> - defining a rough roadmap for Fuel >> - Had a discussion with Usman Bhatti about the uses and the future of Fuel in Moose >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >

March 25, 2014

Re: [Pharo-dev] [Pharo-fuel] FileSystemGit and Fuel final report

by Pharo4Stef

When I see all the interactions and people helping I think that this was really worth :) Thanks for ESUG for sponsoring your trip (like that we can reinvite with RMOD money). Stef On 24 Mar 2014, at 10:06, Max Leske <maxleske(a)gmail.com> wrote: > For those whoâve been interested in what went on during the last two weeks, where I visited Lille, Iâve compiled a short report. Regarding my work on Git Iâll continue to report on the status from time to time. > > I want to thank everyone at RMoD once again for the warm welcome and the support I received. Special thanks to Ben and Camillo for providing a place to crash at. > Thanks also go to all of you guys and girls on the list for pushing Pharo constantly and for showing interest in my work. Itâs very encouraging. > > Cheers, > Max > > > Git: > - Esteban Lorenzano and me worked together on preparing the libgit2 and libssh2 libraries for integration into the VM > - Igor Stasenko worked with me to solve a couple of problems I had with NativeBoost. Especially callbacks can be tricky > - Learnt how to build the VM in debugging mode so that I could debug FFI calls in XCode > - Stefan Marr worked with me on moving the tests from Phexample to SUnit > - The implementation now enables writing of blobs, trees and commits, cloning of remote repositories (https), fetching from remote repositories (https), pushing to remote repositories (https) > - Authentication with remote repositories via SSH is working but clone, fetch, push don't work yet (problems with the libssh2 interaction that I wasn't able to resolve yet) > - I set up an initial build infrastructure on the INRIA CI server (https://ci.inria.fr/pharo-contribution/job/LibGit2/) > - We defined a rough roadmap for what needs to be done in the near future: > 1. finish the low level libgit2 abstraction (offer a minimal API that hides the bindings; we don't want users to use the bindings directly) > 2. we already have a prototype of a FileSystem wrapper for Git. We want to use that on top of the libgit2 abstraction layer > 3. we already have a Monticello FileSystem wrapper prototype. We want to use that to abstract from the actual storage method. Together with the Git-FileSystem wrapper this should make it very easy to continue (for now) using Monticello and the existing GUI tools while using Git as a backend for storage. > - On Friday 21 I gave a short demo at RMoD on the work accomplished and what the plans are for the future > > Fuel: > - MartÃn Dias and I worked together on: > - debugging a problem with large object graphs > - preparing a new baseline for Fuel 2 > - moving the benchmark suite to SMark > - setting up a benchmark build on the INRIA CI server which will help us track performance changes when introducing changes > - defining a rough roadmap for Fuel > - Had a discussion with Usman Bhatti about the uses and the future of Fuel in Moose > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

March 25, 2014

Re: [Pharo-dev] threading in Pharo

by Igor Stasenko

On 25 March 2014 18:21, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Igor, > > > you have a point but I disagree. The scheduler is defined in the > implementation section of the blue book. It could be more explicit, but > the blue book scheduler is a known and simple system. In my threading work > I've made sure to preserve its semantics (cooperative within priorities, > preemptive across priorities, thread switch at activation of non-primitive > sends and backward branches). The only serious bug I know of (that > preempting sends a process to the back of its run-queue) was addressed in > Cog and the VW VM. We can and should write up the semantics, but they're > not undefined, they're simple and they do work. > > And you remember that i managed to move all scheduling logic out of VM to image. That gives you much more freedom in defining how scheduling shall work, without need of implementing complex, unsafe and errorneus sematic which involves mind-blowing exercises trying to fill the gap between VM and image without having right tools. I don't argue that current scheduling implementation is quite simple and more or less OK. What I am not pleased with, is that it is the only available semantic which we would ever have. And producing and using code based on it , only makes it carved in stone & live forever. > Eliot (phone) > > -- Best regards, Igor Stasenko.

March 25, 2014