- Pharo-dev - lists.pharo.org

[Pharo-project] detect if image was saved with Cog

by Max Leske

Hi guys Is there a way to find out (from outside of the image), if an image has been saved with Cog? What I would like to do is something like this: $ head -20 myImage.image | grep <some expression> The use case for this is seaside hosting, where we only have squeak VMs to run images, so when an image is uploaded that was saved with Cog that image cause trouble. Any ideas? Cheers, Max

Oct. 1, 2012

Re: [Pharo-project] Metacello bleedingEdge question

by phil＠highoctane.be

Hey, don't. I found it very helpful. I read it thrice actually. Still do find Configurations confusing though. 2012/10/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > OK > so we should not talk about it anymore and ban it from all the > configurations. > It would be good to have specific rules for configurations. > > BTW: what do we do with the chapter I'm working on the new book and now > I'm puzzled > because I have invested a large amount of time and I get a chapter that > you never gave feedback on and > that is probably not correct or up to date. So may be the only thing I can > do is to drop it. > And after people will tell that pharo does not have documentation but I > often fell alone. > > Stef > > > #latestVersion actually has a very good reason for existing, just not > for use by end users in loading code ... > > > > It _has_ been dropped from the _convention_, and it shouldn't be dropped > from the code base... > > > > Dale > > > > ----- Original Message ----- > > | From: "Sven Van Caekenberghe" <sven(a)stfx.eu> > > | To: Pharo-project(a)lists.gforge.inria.fr > > | Sent: Saturday, September 29, 2012 1:02:17 PM > > | Subject: Re: [Pharo-project] Metacello bleedingEdge question > > | > > | > > | 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 > > | > > | > > | > > | > > | > > > > >

Oct. 1, 2012

Re: [Pharo-project] Metacello bleedingEdge question

by StÃ©phane Ducasse

OK so we should not talk about it anymore and ban it from all the configurations. It would be good to have specific rules for configurations. BTW: what do we do with the chapter I'm working on the new book and now I'm puzzled because I have invested a large amount of time and I get a chapter that you never gave feedback on and that is probably not correct or up to date. So may be the only thing I can do is to drop it. And after people will tell that pharo does not have documentation but I often fell alone. Stef > #latestVersion actually has a very good reason for existing, just not for use by end users in loading code ... > > It _has_ been dropped from the _convention_, and it shouldn't be dropped from the code base... > > Dale > > ----- Original Message ----- > | From: "Sven Van Caekenberghe" <sven(a)stfx.eu> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Saturday, September 29, 2012 1:02:17 PM > | Subject: Re: [Pharo-project] Metacello bleedingEdge question > | > | > | 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 > | > | > | > | > | >

Oct. 1, 2012

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

by StÃ©phane Ducasse

>> I was going to suggest you that. It is also accesible from the Settings UI. >> BTW, maybe we should do this in #cleanUpForProduction? >> > Maybe also there should be a different setting for when tests are run, and/or adding deprecations to the TestRunner result > eg. 15 deprecations, 0 run, 0 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes Indeed it would be good. Stef

Oct. 1, 2012

[Pharo-project] [update 2.0] #20317

by Marcus Denker

20317 ----- Issue 6167: ClassFactoryForTestCase has silent extensions from fuel http://code.google.com/p/pharo/issues/detail?id=6167 Issue 6392: DNU for Text initialize http://code.google.com/p/pharo/issues/detail?id=6392 Issue 6277: PharoV10.sources files should be loaded on demand http://code.google.com/p/pharo/issues/detail?id=6277 -- Marcus Denker -- http://marcusdenker.de

Oct. 1, 2012

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

by Sven Van Caekenberghe

On 30 Sep 2012, at 14:56, Ben Coman <btc(a)openInWorld.com> wrote: > Maybe also there should be a different setting for when tests are run, and/or adding deprecations to the TestRunner result > eg. 15 deprecations, 0 run, 0 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes That sounds like a good idea ! -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Sept. 30, 2012

Re: [Pharo-project] Metacello bleedingEdge question

by Dale Henrichs

Sept. 30, 2012

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

by Igor Stasenko

On 30 September 2012 10:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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 ? > You show it if it not already open, and if you hit deprecated method. In headless mode, warnings is simply written to debug log/console. (but for speed reasons, we should also write them only once per deprecation, i think). > 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. >> > > -- Best regards, Igor Stasenko.

Sept. 30, 2012

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

by Ben Coman

Mariano Martinez Peck wrote: > On Sun, Sep 30, 2012 at 10:15 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > > >> 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. >> >> > > I was going to suggest you that. It is also accesible from the Settings UI. > BTW, maybe we should do this in #cleanUpForProduction? > Maybe also there should be a different setting for when tests are run, and/or adding deprecations to the TestRunner result eg. 15 deprecations, 0 run, 0 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes > > >> 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

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

by Mariano Martinez Peck

On Sun, Sep 30, 2012 at 10:15 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > 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. > I was going to suggest you that. It is also accesible from the Settings UI. BTW, maybe we should do this in #cleanUpForProduction? > > 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. > > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 30, 2012