October 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] strange problem with 10083

by StÃ©phane Ducasse

On Oct 1, 2008, at 8:00 PM, Bill Schwab wrote: > Stef, > > To reproduce, one would start with 10083 and invoke > > Installer loadOB. > > Is that correct? We found the problem :) some magic in bytecode generation that was broken. > It will be a couple of hours before I would have time > to try it, and my hunch is probably wrong anyway, but here goes: could > it be a nil stream (file or URL that is incorrect or otherwise > non-openable) or a read off the end of a stream that defaults to nil? No :) > > Among other things, I have been working on File and FileStream classes > (mostly facades around Pharo's streams, with lots of error checking > and > signalling) to avoid silent failures that merely postpone the > inevitable > until down stream with a nil receiver and NO clue as to what really > happened. > > My primary goal with File and FileStream is to get a large amount of > my > Dolphin code loaded into Pharo and working without a huge fight. A > close second is to provide the alternate selectors (#nextOne, etc.) I > described to avoid silent failures in stream I/O. Whether or not it > is > at the root of your current problem (my guess is that something else > changed, and a failure to raise an error is masking it), I strongly > recommend deprecating (but keeping) the offending selectors. > > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > >>>> stephane.ducasse(a)inria.fr 10/01/08 1:34 PM >>> > Hi > > I tried to load the following code into 10082 and 10083 > in 10082 it works like a charm, in 10083 > > > > > loadOB > "self loadOB" > > | instClass | > instClass := self environment at: #Installer ifAbsent: [self new > > installingInstaller]. > > instClass ss > project: 'AST'; > install: 'AST-lr.158'. > > instClass ss > project: 'RefactoringEngine'; > install: 'RefactoringEngine-ab.51'. > > instClass wiresong > project: 'ob'; > install: 'OmniBrowser-dr.418'; > install: 'OB-Standard-dr.353'; > install: 'OB-Morphic-dr.56'; > install: 'OB-Enhancements-dr.216'; > install: 'OB-Refactory-lr.100'; > install: 'OB-SUnitIntegration-dc.9'. > > > I get a extremely strange bug > UndefinedObject DNU value: !!!!! > > when Instance := nil is selected and > > RefactoryChangeManager class>>nuke > Instance notNil ifTrue: [Instance release]. > Instance := nil > > RefactoryChangeManager class >>initialize > self nuke. > UndoSize := 5 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 1, 2008

Re: [Pharo-project] strange problem with 10083

by Bill Schwab

Stef, To reproduce, one would start with 10083 and invoke Installer loadOB. Is that correct? It will be a couple of hours before I would have time to try it, and my hunch is probably wrong anyway, but here goes: could it be a nil stream (file or URL that is incorrect or otherwise non-openable) or a read off the end of a stream that defaults to nil? Among other things, I have been working on File and FileStream classes (mostly facades around Pharo's streams, with lots of error checking and signalling) to avoid silent failures that merely postpone the inevitable until down stream with a nil receiver and NO clue as to what really happened. My primary goal with File and FileStream is to get a large amount of my Dolphin code loaded into Pharo and working without a huge fight. A close second is to provide the alternate selectors (#nextOne, etc.) I described to avoid silent failures in stream I/O. Whether or not it is at the root of your current problem (my guess is that something else changed, and a failure to raise an error is masking it), I strongly recommend deprecating (but keeping) the offending selectors. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 10/01/08 1:34 PM >>> Hi I tried to load the following code into 10082 and 10083 in 10082 it works like a charm, in 10083 loadOB "self loadOB" | instClass | instClass := self environment at: #Installer ifAbsent: [self new installingInstaller]. instClass ss project: 'AST'; install: 'AST-lr.158'. instClass ss project: 'RefactoringEngine'; install: 'RefactoringEngine-ab.51'. instClass wiresong project: 'ob'; install: 'OmniBrowser-dr.418'; install: 'OB-Standard-dr.353'; install: 'OB-Morphic-dr.56'; install: 'OB-Enhancements-dr.216'; install: 'OB-Refactory-lr.100'; install: 'OB-SUnitIntegration-dc.9'. I get a extremely strange bug UndefinedObject DNU value: !!!!! when Instance := nil is selected and RefactoryChangeManager class>>nuke Instance notNil ifTrue: [Instance release]. Instance := nil RefactoryChangeManager class >>initialize self nuke. UndoSize := 5 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 1, 2008

Re: [Pharo-project] strange problem with 10083

by StÃ©phane Ducasse

Because we do not want to have a dandling reference if the package is not loaded. :) We want to be clean :) Stef On Oct 1, 2008, at 7:53 PM, Keith Hodges wrote: > Why do your scripts use a temporary variable, this means that you > cannot > select part of the script and Doit. This is one of the design goals of > Installer, that you be able to execute scripts either wholly or in > parts. > > You would be far better off referring to Installer directly or to > 'self > installer'. > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 1, 2008

Re: [Pharo-project] strange problem with 10083

by StÃ©phane Ducasse

Marcus we found the source of the problem: your readOnly clean up :) apparently we reintroduced the old version of sizeForStorePop: + isSpecialWriteBinding ^ false and it worked. Now mathieu could not understand why :) Stef On Oct 1, 2008, at 7:34 PM, StÃ©phane Ducasse wrote: > Hi > > I tried to load the following code into 10082 and 10083 > in 10082 it works like a charm, in 10083 > > > > > loadOB > "self loadOB" > > | instClass | > instClass := self environment at: #Installer ifAbsent: [self new > installingInstaller]. > > instClass ss > project: 'AST'; > install: 'AST-lr.158'. > > instClass ss > project: 'RefactoringEngine'; > install: 'RefactoringEngine-ab.51'. > > instClass wiresong > project: 'ob'; > install: 'OmniBrowser-dr.418'; > install: 'OB-Standard-dr.353'; > install: 'OB-Morphic-dr.56'; > install: 'OB-Enhancements-dr.216'; > install: 'OB-Refactory-lr.100'; > install: 'OB-SUnitIntegration-dc.9'. > > > I get a extremely strange bug > UndefinedObject DNU value: !!!!! > > when Instance := nil is selected and > > RefactoryChangeManager class>>nuke > Instance notNil ifTrue: [Instance release]. > Instance := nil > > RefactoryChangeManager class >>initialize > self nuke. > UndoSize := 5 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 1, 2008

Re: [Pharo-project] strange problem with 10083

by Keith Hodges

Why do your scripts use a temporary variable, this means that you cannot select part of the script and Doit. This is one of the design goals of Installer, that you be able to execute scripts either wholly or in parts. You would be far better off referring to Installer directly or to 'self installer'. Keith

Oct. 1, 2008

[Pharo-project] strange problem with 10083

by StÃ©phane Ducasse

Hi I tried to load the following code into 10082 and 10083 in 10082 it works like a charm, in 10083 loadOB "self loadOB" | instClass | instClass := self environment at: #Installer ifAbsent: [self new installingInstaller]. instClass ss project: 'AST'; install: 'AST-lr.158'. instClass ss project: 'RefactoringEngine'; install: 'RefactoringEngine-ab.51'. instClass wiresong project: 'ob'; install: 'OmniBrowser-dr.418'; install: 'OB-Standard-dr.353'; install: 'OB-Morphic-dr.56'; install: 'OB-Enhancements-dr.216'; install: 'OB-Refactory-lr.100'; install: 'OB-SUnitIntegration-dc.9'. I get a extremely strange bug UndefinedObject DNU value: !!!!! when Instance := nil is selected and RefactoryChangeManager class>>nuke Instance notNil ifTrue: [Instance release]. Instance := nil RefactoryChangeManager class >>initialize self nuke. UndoSize := 5

Oct. 1, 2008

Re: [Pharo-project] [updates] 10083

by Marcus Denker

On 01.10.2008, at 11:15, Adrian Lienhard wrote: > > On Oct 1, 2008, at 11:03 , Damien Cassou wrote: > >> On Wed, Oct 1, 2008 at 11:01 AM, Marcus Denker >> <denker(a)iam.unibe.ch> wrote: >>>> May be time to release? How do we proceed for the dev packages? >>>> >>> >>> not yet. in the changesets I added there of course was a >>> conflict.. and some >>> more cleanup is needed (remove preferences not needed, and so on) >> >> I may not have been clear enough. I meant a downloadable 10083 core >> image. > > Actually, this would be a good task to automate (i.e., a script that > checks once a day for new updates, loads them and then saves the > image). Shouldn't be hard... Concerning terminology, I'd rather talk > about "nightly builds" than releases (I think the latter is a bit > misleading). > Yes! I added an entry in the tracker: http://code.google.com/p/pharo/issues/detail?id=208 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 1, 2008

Re: [Pharo-project] Image tidyup convention

by StÃ©phane Ducasse

Ok I saw it is below :) I like the idea now it would be good to specify it a bit better. Stef > I would really like if Pharo will introduce a convention for tidying > up the image, proposed by Keith. > It could save a lot of time and nerves for developers/maintainers :) > > http://www.nabble.com/Squeak-low-on-space...-td13243777.html#a13244357 > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 1, 2008

Re: [Pharo-project] Image tidyup convention

by StÃ©phane Ducasse

hi igor > I would really like if Pharo will introduce a convention for tidying > up the image, proposed by Keith. Which is because I'm confused? > It could save a lot of time and nerves for developers/maintainers :) > > http://www.nabble.com/Squeak-low-on-space...-td13243777.html#a13244357 Is it related to tidying up image? Stef > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 1, 2008

[Pharo-project] Image tidyup convention

by Igor Stasenko

I would really like if Pharo will introduce a convention for tidying up the image, proposed by Keith. It could save a lot of time and nerves for developers/maintainers :) http://www.nabble.com/Squeak-low-on-space...-td13243777.html#a13244357 -- Best regards, Igor Stasenko AKA sig.

Oct. 1, 2008