- Pharo-dev - lists.pharo.org

[Pharo-project] Re: [build broken] 10083/10084

by Marcus Denker

On 01.10.2008, at 21:04, Marcus Denker wrote: > Please dont' update, it's broken right now. > (And I don't have time to fix it, I have to admit) > Fixed. Make sure to update to 10084, this has the compiler bug fixed. -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 1, 2008

[Pharo-project] [build broken] 10083/10084

by Marcus Denker

Please dont' update, it's broken right now. (And I don't have time to fix it, I have to admit) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 1, 2008

Re: [Pharo-project] strange problem with 10083

by Marcus Denker

On 01.10.2008, at 20:57, Marcus Denker wrote: > > On 01.10.2008, at 20:18, StÃ©phane Ducasse wrote: > >> >> 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. > > > Update 10084 fixes the problem. It recompiled the image to make > sure that no wrong method is left over. > Uhhh... and it seems to have problems recompiling the image. So that was not a fix. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 1, 2008

Re: [Pharo-project] strange problem with 10083

by Marcus Denker

On 01.10.2008, at 20:18, StÃ©phane Ducasse wrote: > > 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. Update 10084 fixes the problem. It recompiled the image to make sure that no wrong method is left over. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 1, 2008

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