- Pharo-dev - lists.pharo.org

Re: [Pharo-project] String>>includesSub[S|s]tring: - do we need another kind of deprecation ?

by StÃ©phane Ducasse

I'm in favor of anything smoothing migration. Ideally I would love to have refactorings recorded. Stef > Guys, > > So yesterday I deployed a new server based on an #20309 image, with a single Metacello config for my code, and a separate manual load for Seaside 3.1 (which I use as an interface to work with the headless image) - and all went well ! > > But I had to apply one manual hack: remove the deprecation from #includesSubString: (for Seaside). > > I feel like we need another, more silent kind of deprecation for situations like this. Library/framework/application writers targetting multiple Pharo versions are being hit way too hard by this, for - in this case certainly -, no good reason. Creating two versions (I introduced a special package Pharo-Forward-Compatibility just for this), is not worth it (unless you absolutely want the best Pharo 2.x code like I do). > > I would imagine something similar to Deprecation which maybe prints on the Transcript, but is otherwise silent, except when some switch is turned on. > > It would give us the power to deprecate much more things even 'silly renames'. And less external stuff would break. > > What do you think ? > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

Sept. 30, 2012

Re: [Pharo-project] String>>includesSub[S|s]tring: - do we need another kind of deprecation ?

by Sven Van Caekenberghe

Yes, Transcript will be too slow. Actually, I didn't look carefully at the Deprecation class. It has show/raise warning options and a simple way to collect deprecations with #deprecationsWhile: Maybe I should run production code with Deprecation raiseWarning: false. This is of course a global setting. Your idea with the window sounds cool but how/when are you going to show it ? And what about headless ? On 30 Sep 2012, at 01:24, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 29 September 2012 23:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Guys, >> >> So yesterday I deployed a new server based on an #20309 image, with a single Metacello config for my code, and a separate manual load for Seaside 3.1 (which I use as an interface to work with the headless image) - and all went well ! >> >> But I had to apply one manual hack: remove the deprecation from #includesSubString: (for Seaside). >> >> I feel like we need another, more silent kind of deprecation for situations like this. Library/framework/application writers targetting multiple Pharo versions are being hit way too hard by this, for - in this case certainly -, no good reason. Creating two versions (I introduced a special package Pharo-Forward-Compatibility just for this), is not worth it (unless you absolutely want the best Pharo 2.x code like I do). >> >> I would imagine something similar to Deprecation which maybe prints on the Transcript, but is otherwise silent, except when some switch is turned on. >> > > Putting transcript is possible only for non-performance critical methods. > Put it in wrong place, and it will crawl like slug .. > So, we need a kind-of non-interfering deprecation. > > I am all for having less intrusive deprecation system. > IMO, to fix deprecation (if developer really cares), one needs only > the method which sends the deprecated message, bringing a full > Debugger is overkill in 99% of cases. > > What can we do is to make a nice wrapping around this, so if running > code hits deprecated method, > it should bring a special popup window titled 'deprecated methods > used' or something, > and if user will click on the button there, he can see the list of > methods which having send sites which hit deprecated methods, i.e. a > list populated from pairs: > > MyClass>>foo using deprecated SystemClass>>deprecatedBar > > clicking on that entry will open a browser in #foo method, where you can fix it. > > (sure thing, if method #foo runs millions of times, it should not > produce millions of very same entries > in that list. we only interested in unique sender->receiver pairs. > And run-time check for that is far less expensive comparing printing > that stuff on transcript every time). > > To speed things up even more, we can even just do this on a first hit, > and then recompile deprecated method to not do any checks but perform > only what they exist for. But this will require some dark magic, > either with compiler, or using method wrappers of some sort. > > At the end, what we have is a system simply runs as usual, except from > small window, which (if users care to click on) will bring the list of > deprecations hit so far. > >> It would give us the power to deprecate much more things even 'silly renames'. And less external stuff would break. >> >> What do you think ? >> >> Sven >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> > > -- > Best regards, > Igor Stasenko. >

Sept. 30, 2012

[Pharo-project] [update 2.0] #20316

by Marcus Denker

20316 ----- Issue 6746: Failing Test: TestCaseTest.testAssertEqualsActualAndExpectedOrder http://code.google.com/p/pharo/issues/detail?id=6746 -- Marcus Denker -- http://marcusdenker.de

Sept. 30, 2012

Re: [Pharo-project] String>>includesSub[S|s]tring: - do we need another kind of deprecation ?

by Igor Stasenko

On 29 September 2012 23:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Guys, > > So yesterday I deployed a new server based on an #20309 image, with a single Metacello config for my code, and a separate manual load for Seaside 3.1 (which I use as an interface to work with the headless image) - and all went well ! > > But I had to apply one manual hack: remove the deprecation from #includesSubString: (for Seaside). > > I feel like we need another, more silent kind of deprecation for situations like this. Library/framework/application writers targetting multiple Pharo versions are being hit way too hard by this, for - in this case certainly -, no good reason. Creating two versions (I introduced a special package Pharo-Forward-Compatibility just for this), is not worth it (unless you absolutely want the best Pharo 2.x code like I do). > > I would imagine something similar to Deprecation which maybe prints on the Transcript, but is otherwise silent, except when some switch is turned on. > Putting transcript is possible only for non-performance critical methods. Put it in wrong place, and it will crawl like slug .. So, we need a kind-of non-interfering deprecation. I am all for having less intrusive deprecation system. IMO, to fix deprecation (if developer really cares), one needs only the method which sends the deprecated message, bringing a full Debugger is overkill in 99% of cases. What can we do is to make a nice wrapping around this, so if running code hits deprecated method, it should bring a special popup window titled 'deprecated methods used' or something, and if user will click on the button there, he can see the list of methods which having send sites which hit deprecated methods, i.e. a list populated from pairs: MyClass>>foo using deprecated SystemClass>>deprecatedBar clicking on that entry will open a browser in #foo method, where you can fix it. (sure thing, if method #foo runs millions of times, it should not produce millions of very same entries in that list. we only interested in unique sender->receiver pairs. And run-time check for that is far less expensive comparing printing that stuff on transcript every time). To speed things up even more, we can even just do this on a first hit, and then recompile deprecated method to not do any checks but perform only what they exist for. But this will require some dark magic, either with compiler, or using method wrappers of some sort. At the end, what we have is a system simply runs as usual, except from small window, which (if users care to click on) will bring the list of deprecations hit so far. > It would give us the power to deprecate much more things even 'silly renames'. And less external stuff would break. > > What do you think ? > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > -- Best regards, Igor Stasenko.

Sept. 29, 2012

[Pharo-project] String>>includesSub[S|s]tring: - do we need another kind of deprecation ?

by Sven Van Caekenberghe

Guys, So yesterday I deployed a new server based on an #20309 image, with a single Metacello config for my code, and a separate manual load for Seaside 3.1 (which I use as an interface to work with the headless image) - and all went well ! But I had to apply one manual hack: remove the deprecation from #includesSubString: (for Seaside). I feel like we need another, more silent kind of deprecation for situations like this. Library/framework/application writers targetting multiple Pharo versions are being hit way too hard by this, for - in this case certainly -, no good reason. Creating two versions (I introduced a special package Pharo-Forward-Compatibility just for this), is not worth it (unless you absolutely want the best Pharo 2.x code like I do). I would imagine something similar to Deprecation which maybe prints on the Transcript, but is otherwise silent, except when some switch is turned on. It would give us the power to deprecate much more things even 'silly renames'. And less external stuff would break. What do you think ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Sept. 29, 2012

Re: [Pharo-project] Bad behaviour at startup

by StÃ©phane Ducasse

Thanks Sven. I created an issue. BTW esteban was making progress on a simpler integration process and it will easier for non core people to commit :). Stef On Sep 29, 2012, at 9:02 PM, Sven Van Caekenberghe wrote: > Name: Zinc-HTTP-SvenVanCaekenberghe.307 > Author: SvenVanCaekenberghe > Time: 29 September 2012, 9:00:49.72 pm > UUID: 9387492b-daa2-4ebf-a49d-44950586bda3 > Ancestors: Zinc-HTTP-SvenVanCaekenberghe.306 > > Modified ZnServer class>>#startUp: to use a deferred startup action to start all registered servers; this should allow for normal error handling when something goes wrong initializing server sockets (thanks Igor Stasenko for the fix; thanks Denis Kudriashov for the error report)

Sept. 29, 2012

Re: [Pharo-project] Metacello bleedingEdge question

by Sven Van Caekenberghe

On 29 Sep 2012, at 21:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > On Sep 29, 2012, at 5:39 PM, Dale Henrichs wrote: > >> Stef, >> >> #latestVersion is there for backward compatibility. > > Ok > I would simply remove it. > > Stef I was about to say: what's that 'backward compatibility' ? ;-) No seriously, unless there is a very good, important reason to keep it, confusing stuff should be removed going forward. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Sept. 29, 2012

Re: [Pharo-project] Fuel and Tanker in older Pharo images [WAS] Re: How to try Shapes and Gaucho?

by StÃ©phane Ducasse

> On 29 September 2012 14:57, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> Cool! Thanks Mariano for the summary, and all the others for this >> much needed features! Looking forward to adopt such a process, to have >> a minimal Pharo image, customized to my needs. >> > > indeed, sometimes even i forgetting why we doing things we do.. don't worry I'm the compass :) > and then people who are poorly informed about our end goals, making > wrong assumptions > about where Pharo moves, bashing us for killing compatibility, > breaking what was not broken, etc etc :) Because they did not read the vision document :) Stef

Sept. 29, 2012

Re: [Pharo-project] Fuel and Tanker in older Pharo images [WAS] Re: How to try Shapes and Gaucho?

by StÃ©phane Ducasse

Thanks mariano for the history :) This is the vision we have and that is presented in the vision file available in the consortium web page on the pharo-project.org :) > Hi Denis. I want to say a couple of things about this. First, you are not the only one wanting this. In fact, that scenario is one of the reasons we are investing a lot of time in the infrastructure: > > 1) Pavel Krivanek has been working a lot in making the image more modular, being able to cleanly unload and reload packages. This was the first step. > 2) Jannik Laval continue that effort trying to remove lots of cyclic dependencies between packages. > 3) Guillermo Polito started to work in the bootstrap. He is now able to bootstrap images from scratch (contrary to Pavel's PharoKernel where he was unloading packages). > 4) Esteban Lorenzano is working on a new ConfigurationOfPharo that will let you take a kernel/bootstraped/minimal image and load just the packages you want. > 5) Camilo Bruni, Martin Dias, Guillermo Polito, and Toon Verwaest have been working in a new class builder based on layouts. The "old ClassBuilder" is really difficult to maintain, understand, fix, etc. When you load packages, the class builder takes an important role. Therefore, they were working in a new class builder, which, from my point of view, is way better, object-oriented, tested, etc. > 6) Martin Dias and Me were working in Tanker, a tool to export/import packages of code using Fuel without Compiler. > > So.....as you can see there is/was a lot of work going on related to what you need :) It is not 100% ready, but we are getting there. > > Cheers,

Sept. 29, 2012

Re: [Pharo-project] Metacello bleedingEdge question

by StÃ©phane Ducasse

On Sep 29, 2012, at 5:39 PM, Dale Henrichs wrote: > Stef, > > #latestVersion is there for backward compatibility. Ok I would simply remove it. Stef > > The #stable symbolic version is the preferred mechanism for declaring the "latest version". > > Dale > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Friday, September 28, 2012 11:37:30 AM > | Subject: Re: [Pharo-project] Metacello bleedingEdge question > | > | dale > | > | at the end do we really need latestVersion because I'm still confused > | by it. > | > | On Sep 28, 2012, at 3:42 PM, Dale Henrichs wrote: > | > | > #latestVersion is defined as the latest version whose blessing is > | > neither #baseline nor #development. > | > | > | >

Sept. 29, 2012