- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Classes referenced in code string

by Sean P. DeNigris

Lukas Renggli wrote > > This is the rest of the code: > Thanks Lukas! "#annotateInClass: nil" doesn't work... what's the class of nil? Seems so obvious now! -- View this message in context: http://forum.world.st/Classes-referenced-in-code-string-tp4244214p4246073.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 30, 2011

[Pharo-project] string hash collisions?

by Philippe Marschall

Hi As you probably noted string hash collisions are all the rage these days [1]. Has anybody looked into whether this applies to Pharo as well? [1] http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html Cheers Philippe

Dec. 30, 2011

[Pharo-project] Pharo surpasses 1 Million downloads ;-)

by Sean P. DeNigris

I just happened to notice this on Squeaksource. Pretty cool. Project Downloads Pharo 1365087 -- View this message in context: http://forum.world.st/Pharo-surpasses-1-Million-downloads-tp4246065p4246065… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 30, 2011

Re: [Pharo-project] TWM bug when deleting a snapshot

by Sean P. DeNigris

Most of it feels very natural to me. laurent laffont wrote > > - go to S3. Then move some windows and delete. If automatically TWM > restore > last snapshot, we loose current state..... > If I delete a snapshot, I'm saying that the state is no longer interesting, so that's what I would expect. laurent laffont wrote > > Another idea is to have TWMWorldRecorder plugged to announcements so each > time a window move / appear / disappear it creates automatically a > snapshot.... > This could be interesting, but I think it would be another feature - "world history" vs. "particular points I find interesting"; like browser history vs. bookmarks -- View this message in context: http://forum.world.st/TWM-bug-when-deleting-a-snapshot-tp4243197p4245948.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 30, 2011

[Pharo-project] [COTDC] 99 - ZipEncoder

by sean＠clipperadams.com

98 classes done 798 classes remaining Continuing in Compression... Today: ZipEncoder Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest p.s. this message was sent from a pharo image. Did you know you could easily do that?!

Dec. 30, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by StÃ©phane Ducasse

It is Stef On Dec 30, 2011, at 2:58 PM, Igor Stasenko wrote: > how about putting it into default pharo image? > > > -- > Best regards, > Igor Stasenko. >

Dec. 30, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by Igor Stasenko

how about putting it into default pharo image? -- Best regards, Igor Stasenko.

Dec. 30, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by StÃ©phane Ducasse

On Dec 29, 2011, at 11:38 PM, Torsten Bergmann wrote: >>> So we should care for 1.3 and not yet for 1.4. since >>> this is what people use. >> >> Yes but I use 1.4 for my private projects and this is good to know >> what works. > > Yes - but dont use the squeaksource.com/MetaRepoForPharo14 > for that. Otherwise we have to clean it up again and again > depending on Pharos progress in 1.4. But if I fixed the configurationOfSoup and citizen to work on 1.4 then they will work. There is not that much changes that break everything. > > > The "official" squeaksource.com/MetaRepoForPharo14 should be filled > when Pharo 1.4 is out with all the configs that are > known to work (and tested) for 1.4 > > But you can use the browser for your pet projects also. > Just point him to another repo (maybe a local one): > > (MetacelloConfigurationBrowser new) > repository: 'http://www.squeaksource.com/MyPetConfigs'; > open > > thats all you have to do. > > And remember: the browser itself is just a start - it could > be improved to mark configs already loaded, ... later > > Bye > T. > -- > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! > Jetzt informieren: http://www.gmx.net/de/go/freephone >

Dec. 30, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by laurent laffont

We can yet know which packages load in Pharo 1.2 / 1.3, .... it's written in the ConfigurationOf......>>stable: spec <symbolicVersion: #stable> spec for: #'pharo1.2.x' version: '1.0'. spec for: #'pharo1.3.x' version: '1.1'. Would be nice / necessary to script upcoming SmalltalkHub and render automatically the compatibility list. Automatic dashboard and good indicators are the first step. Second nice step would be automatic testing that each ConfigurationOf loads according according to what is declared. Jenkins to the rescue. It seems stable API is always subject to controversy and will slow down the release process. Pharo already has a deprecation policy. I do not see the point of taking a 5 years old package and expect to load it correctly in current Pharo (especially in an open source platform). Custom solutions mixing old, new and legacy stuff will always be a pains and lot of work, stable API or not - except (maybe) when high test coverage is present (at least it's far easier). Now I believe in fixed length iteration that provide some answers to moving packages from one version to another. Example: - 4 months development of Pharo (new features) - 1 / 2 months feature freeze and fix - now guys upgrade your packages we won't break things anymore. - write announcements and release. Good process, automation and visibility is one key for me. Laurent On Thu, Dec 29, 2011 at 3:44 PM, Benoit St-Jean <bstjean(a)yahoo.com> wrote: > I was wondering what is planned regarding packages available on > SqueakSource and Pharo. More and more packages can't load in Pharo and it > gets more and more frustrating not being able to load anything without > having to add/modify methods/classes all over the place so those packages > can load properly in Pharo. Are we looking at a Pharo-only kind of > SqueakSource in the future ? > > Besides, having to handle platform specific (i.e. Pharo vs Squeak) for > every package is adding more complexity than what is needed. I know > backward compatibility was thrown away from the start to avoid compromises > in Pharo but how do we take care of the fact that as each day passes, less > and less stuff from SqueakSource is usable in Pharo ? > > tia > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > >

Dec. 30, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by Igor Stasenko

On 30 December 2011 10:54, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 30 December 2011 09:49, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 29 December 2011 18:26, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> >>> >>> On Thu, Dec 29, 2011 at 5:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>> On 29 December 2011 15:44, Benoit St-Jean <bstjean(a)yahoo.com> wrote: >>>> > I was wondering what is planned regarding packages available on >>>> > SqueakSource >>>> > and Pharo.Â More and more packages can't load in Pharo and it gets more >>>> > and >>>> > more frustrating not being able to load anything without having to >>>> > add/modify methods/classes all over the place so those packages can load >>>> > properly in Pharo.Â Are we looking at a Pharo-only kind of SqueakSource >>>> > in >>>> > the future ? >>>> > >>>> > Besides, having to handle platform specific (i.e. Pharo vs Squeak) for >>>> > every >>>> > package is adding more complexity than what is needed.Â I know backward >>>> > compatibility was thrown away from the start to avoid compromises in >>>> > Pharo >>>> > but how do we take care of the fact that as each day passes, less and >>>> > less >>>> > stuff from SqueakSource is usable in Pharo ? >>>> > >>>> The recipe is simple: maintenance. >>>> >>>> If you really care, spend time maintaining packages you using. >>>> If nobody cares to maintain the software, it is dead. >>>> It is only a matter of time for it to get broken. >>>> We cannot give any guarantee that something which worked fine 10 years >>>> ago will keep working today, >>>> without keeping everything unchanged. >>>> >>>> If you have a garden and planted a rose there, do you expect that 5 >>>> years later it will still grow there, without you taking care of it? >>> >>> >>> >>> Igor, I think he is not criticizing that. What he points out is not the lack >>> of maintenance but a clear way of knowing which project/packages are >>> expected to work or not in Pharo. If you take a random package/project from >>> SS there is no way to know that. Having a Pharo catalog/certified >>> packages/projects would help here. >>> >> >> Well, it is just another side of same problem. >> If package maintainer wants its package to work without problems with Pharo, >> usually, he takes care of everything, from checking if it works with >> latest pharo up to >> mentioning where and how it can be loaded/used. >> And if people don't care about their stuff, it is just rots and dies. >> >> Any attempts to do that externally (by people who don't maintain own >> projects directly) are futile and counterproductive. >> Because it is fine, you can spend couple of hours verifying that some >> software works ok today, >> "certify" it and list it in some "catalogue". But then tomorrow >> something will be changed and again package will be broken/stop >> working >> properly. >> So unless you maintaining your software continuously, there's no other >> way to guarantee that it works and will keep working in future. >> Remember the SqueakMap and Universe? They meant to solve same problem. >> But you cannot solve it automatically, >> because putting a package into list of certified packages does not >> guarantees that if today it works, it will keep working tomorrow. > > Well, that's _half_ true. If Foo 1.0 loads in Pharo 1.3 today, then it > should load in Pharo 1.3 tomorrow, because both "Foo 1.0" and "Pharo > 1.3" point to immutable chunks of code. And of course they must be > immutable, because otherwise your versioning's useless. > > Otherwise, sure, to keep Foo 1.1-dev working against Pharo's HEAD > requires maintenance, right up until 1.4 enters code freeze. > > Once 1.4 is released, Foo 1.2 can be released, and you can safely know > - because your catalogue (i.e., SqueakMap) tells you so - that Foo 1.2 > can load cleanly and work correctly in Pharo 1.4. And so on. > What you described here is a normal _maintenance_ process. Now if there's no people who doing it, how it can magically keep working? There's no any guarantees for that. Because Pharo does not standing still, it moves and evolves. My main point is that questions like "why it cannot be loaded?" should be addressed to right person(s) who is responsible for maintaining particular project. And if there's none, then you can make it work by yourself but again, ask right questions like "class is missing, what can i do" instead of "my beloved package stops working what can you do". > frank > -- Best regards, Igor Stasenko.

Dec. 30, 2011