Hi:
About the problem http://bugs.impara.de/view.php?id=2912, that I've documented a workaround at http://bugs.impara.de/view.php?id=3283 I want to ask how many time may take to be fixed.
Sorry If I don't know deeper the fix related process, but this case is really widely spread (arise in any opprtunity when a user want to update SqueakMap) and really easy to solve (only patching the method not using the deprecated one).
Can I help? Only say me how/were.
Best Regards. gsa.
As neither responded, I'm attaching a .cs that solves the problem.
I hope someone can put it in the correct place to be downloaded by the "all time failing" SM upgrade process.
Cheers. gsa.
---------- Forwarded message ---------- From: Germán Arduino garduino@gmail.com Date: 15-mar-2006 11:31 Subject: About the #logChange error in SqueakMap To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org
Hi:
About the problem http://bugs.impara.de/view.php?id=2912, that I've documented a workaround at http://bugs.impara.de/view.php?id=3283 I want to ask how many time may take to be fixed.
Sorry If I don't know deeper the fix related process, but this case is really widely spread (arise in any opprtunity when a user want to update SqueakMap) and really easy to solve (only patching the method not using the deprecated one).
Can I help? Only say me how/were.
Best Regards. gsa.
-- Germán S. Arduino http://www.arsol.biz http://www.arsol.net
Germán Arduino a écrit :
As neither responded, I'm attaching a .cs that solves the problem.
I can't file-in your .cs. I'm running a 3.9a-7015, opened the 'file list' tool and try to filein the file. I get the following :
UndefinedObject(Object)>>doesNotUnderstand: #methodsFor:stamp: Receiver: nil Arguments and temporary variables: aMessage: methodsFor: 'installation' stamp: 'gsa 3/15/2006 11:20' Receiver's instance variables: nil
UndefinedObject>>DoIt Receiver: nil Arguments and temporary variables:
Receiver's instance variables: nil
Compiler>>evaluate:in:to:notifying:ifFail:logged: Receiver: a Compiler Arguments and temporary variables: textOrStream: 'SMInstallationRegistry methodsFor: ''installation'' stamp: ''gsa...etc... aContext: nil receiver: nil aRequestor: nil failBlock: [] in Compiler class>>evaluate:for:notifying:logged: {[^ nil]} logFlag: false methodNode: DoIt ^ SMInstallationRegistry methodsFor: 'installation' stamp: 'g...etc... method: a CompiledMethod (2342) value: nil Receiver's instance variables: sourceStream: a ReadStream 'SMInstallationRegistry methodsFor: ''installation''...etc... requestor: nil class: UndefinedObject category: nil context: nil parserClass: Parser
Compiler class>>evaluate:for:notifying:logged: Receiver: Compiler Arguments and temporary variables: textOrString: 'SMInstallationRegistry methodsFor: ''installation'' stamp: ''gsa...etc... anObject: nil aController: nil logFlag: false Receiver's instance variables: superclass: Object methodDict: a MethodDictionary(#compileNoPattern:in:context:notifying:ifFail:->...etc... format: 142 traitComposition: {} localSelectors: nil instanceVariables: #('sourceStream' 'requestor' 'class' 'category' 'context' 'p...etc... organization: ('error handling' notify: notify:at:) ('public access' compile:in...etc... subclasses: nil name: #Compiler classPool: a Dictionary() sharedPools: nil environment: a SystemDictionary(lots of globals) category: nil
--- The full stack --- UndefinedObject(Object)>>doesNotUnderstand: #methodsFor:stamp: UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: Compiler class>>evaluate:for:notifying:logged: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Compiler class>>evaluate:for:logged: Compiler class>>evaluate:logged: [] in MultiByteFileStream(PositionableStream)>>fileInAnnouncing: {[val := (self peekFor: $!) ifTrue: [(Compiler evaluate: self nextChunk l...]} BlockContext>>on:do: [] in MultiByteFileStream(PositionableStream)>>fileInAnnouncing: {[:bar | [self atEnd] whileFalse: [bar value: self position. self skipS...]} [] in ProgressInitiationException>>defaultMorphicAction {[result := workBlock value: progress]} BlockContext>>ensure: ProgressInitiationException>>defaultMorphicAction ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: ByteString(String)>>displayProgressAt:from:to:during: MultiByteFileStream(PositionableStream)>>fileInAnnouncing: MultiByteFileStream(FileStream)>>fileIn MultiByteFileStream>>fileIn FileStream class>>fileIn: SimpleServiceEntry>>performServiceFor: PluggableButtonMorph>>performAction [] in PluggableButtonMorph>>mouseUp: {[:m | (m containsPoint: evt cursorPoint) ifTrue: [m performAction]]} Array(SequenceableCollection)>>do: PluggableButtonMorph>>mouseUp: PluggableButtonMorph(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableButtonMorph(Morph)>>handleEvent: PluggableButtonMorph(Morph)>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. ActiveEvent := anEvent. result := focusHolder han...]} [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} BlockContext>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: {[:h | ActiveHand := h. h processEvents. capturingGesture := capturingGest...]} ...etc...
Hi Damien:
This is because the class to patch, SMInstallationRegistry isn't in the image.
Seems that SMInstallationRegistry is downloaded by the SM update process (from 2.0 to 2.1) but I don't know very well this process of update (I meant I don't know were is SMInstallationRegistry and from were is downloaded).
Then, the easy way to patch is:
1) Start the SM upgrading. 2) When you get the DNU error, start the debugger and go to the wrong method and replace Smalltalk logChange by SmalltalkImage current logChange. 3) Hit Proceed and is done.
HTH gsa.
2006/3/23, Damien Cassou damien.cassou@laposte.net:
Germán Arduino a écrit :
As neither responded, I'm attaching a .cs that solves the problem.
I can't file-in your .cs. I'm running a 3.9a-7015, opened the 'file list' tool and try to filein the file. I get the following :
UndefinedObject(Object)>>doesNotUnderstand: #methodsFor:stamp: Receiver: nil Arguments and temporary variables: aMessage: methodsFor: 'installation' stamp: 'gsa 3/15/2006 11:20' Receiver's instance variables: nil
UndefinedObject>>DoIt Receiver: nil Arguments and temporary variables:
Receiver's instance variables:nil
Compiler>>evaluate:in:to:notifying:ifFail:logged: Receiver: a Compiler Arguments and temporary variables: textOrStream: 'SMInstallationRegistry methodsFor: ''installation'' stamp: ''gsa...etc... aContext: nil receiver: nil aRequestor: nil failBlock: [] in Compiler class>>evaluate:for:notifying:logged: {[^ nil]} logFlag: false methodNode: DoIt ^ SMInstallationRegistry methodsFor: 'installation' stamp: 'g...etc... method: a CompiledMethod (2342) value: nil Receiver's instance variables: sourceStream: a ReadStream 'SMInstallationRegistry methodsFor: ''installation''...etc... requestor: nil class: UndefinedObject category: nil context: nil parserClass: Parser
Compiler class>>evaluate:for:notifying:logged: Receiver: Compiler Arguments and temporary variables: textOrString: 'SMInstallationRegistry methodsFor: ''installation'' stamp: ''gsa...etc... anObject: nil aController: nil logFlag: false Receiver's instance variables: superclass: Object methodDict: a MethodDictionary(#compileNoPattern:in:context:notifying:ifFail:->...etc... format: 142 traitComposition: {} localSelectors: nil instanceVariables: #('sourceStream' 'requestor' 'class' 'category' 'context' 'p...etc... organization: ('error handling' notify: notify:at:) ('public access' compile:in...etc... subclasses: nil name: #Compiler classPool: a Dictionary() sharedPools: nil environment: a SystemDictionary(lots of globals) category: nil
--- The full stack --- UndefinedObject(Object)>>doesNotUnderstand: #methodsFor:stamp: UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: Compiler class>>evaluate:for:notifying:logged:
Compiler class>>evaluate:for:logged: Compiler class>>evaluate:logged: [] in MultiByteFileStream(PositionableStream)>>fileInAnnouncing: {[val := (self peekFor: $!) ifTrue: [(Compiler evaluate: self nextChunk l...]} BlockContext>>on:do: [] in MultiByteFileStream(PositionableStream)>>fileInAnnouncing: {[:bar | [self atEnd] whileFalse: [bar value: self position. self skipS...]} [] in ProgressInitiationException>>defaultMorphicAction {[result := workBlock value: progress]} BlockContext>>ensure: ProgressInitiationException>>defaultMorphicAction ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: ByteString(String)>>displayProgressAt:from:to:during: MultiByteFileStream(PositionableStream)>>fileInAnnouncing: MultiByteFileStream(FileStream)>>fileIn MultiByteFileStream>>fileIn FileStream class>>fileIn: SimpleServiceEntry>>performServiceFor: PluggableButtonMorph>>performAction [] in PluggableButtonMorph>>mouseUp: {[:m | (m containsPoint: evt cursorPoint) ifTrue: [m performAction]]} Array(SequenceableCollection)>>do: PluggableButtonMorph>>mouseUp: PluggableButtonMorph(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableButtonMorph(Morph)>>handleEvent: PluggableButtonMorph(Morph)>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. ActiveEvent := anEvent. result := focusHolder han...]} [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} BlockContext>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: {[:h | ActiveHand := h. h processEvents. capturingGesture := capturingGest...]} ...etc...
-- Damien Cassou
Hi,
thank you very much for your help, it works now.
- Start the SM upgrading.
- When you get the DNU error, start the debugger and go to the wrong
method and replace Smalltalk logChange by SmalltalkImage current logChange. 3) Hit Proceed and is done.
Bye
2006/3/29, Damien Cassou damien.cassou@laposte.net:
Hi,
thank you very much for your help, it works now.
- Start the SM upgrading.
- When you get the DNU error, start the debugger and go to the wrong
method and replace Smalltalk logChange by SmalltalkImage current logChange. 3) Hit Proceed and is done.
Bye
Not problem.
I regrett really that this is a long time reported (and assigned) bug in Mantis. from February 18, very simple to solve, but seems that the maintainer of the package has no time :(
Cheers.
On 30.03.2006, at 12:41, Germán Arduino wrote:
2006/3/29, Damien Cassou damien.cassou@laposte.net:
Hi,
thank you very much for your help, it works now.
- Start the SM upgrading.
- When you get the DNU error, start the debugger and go to the
wrong method and replace Smalltalk logChange by SmalltalkImage current logChange. 3) Hit Proceed and is done.
Bye
Not problem.
I regrett really that this is a long time reported (and assigned) bug in Mantis. from February 18, very simple to solve, but seems that the maintainer of the package has no time :(
The problem is known even longer (December or Jan), and actually the cause is a deprecated method that has been deprecated over 1.5 years (!) ago.
It's a one line fix, but that has to be done in a repository where I have no access to, so I can not fix it myself.... sorry. There is a downside of "maintained" packages: Nothing happens with Network for 3 Months, we have not seen a Unix vm build since three years, and SqueakMap is broken for 3 Months. Maybe we need to define more clearly what it really means to be a Maintainer. Right now I have the feeling that making something "maintained" is the best way to ensure that nothing happns at all.
Marcus
Hi people!
Marcus Denker denker@iam.unibe.ch wrote:
On 30.03.2006, at 12:41, Germán Arduino wrote:
I regrett really that this is a long time reported (and assigned) bug in Mantis. from February 18, very simple to solve, but seems that the maintainer of the package has no time :(
The problem is known even longer (December or Jan), and actually the cause is a deprecated method that has been deprecated over 1.5 years (!) ago.
But which AFAIK didn't "show up" until lately, right? At least I can't recall getting a "warning" in my face.
It's a one line fix, but that has to be done in a repository where I have no access to, so I can not fix it myself.... sorry.
You ask and ye shall receive. I have asked numerous times for help in maintaining SM but have gotten ZERO replies earlier. Now apparently you want to help me and great, I am adding you as a co-maintainer and will send you write access to the server.
There is a downside of "maintained" packages: Nothing happens with Network for 3 Months,
Things did happen a bit (at least *I* did a few fixes) but I didn't get around to "zipping it all up". I think I explained it in detail if someone wanted to do the picking - but if noone does then I will eventually get around to it.
we have not seen a Unix vm build since three years,
That is true and a bit worrying. Do we have any suggestions on who to pick that up? I can picture a few names in my head - but have no idea about interest.
and SqueakMap is broken for 3 Months.
"broken" is a bit harsh - yes, it flunks in the current 3.9alpha or beta, but not in 3.8 AFAIK.
Now, if/when you fix it btw - make sure that the "SqueakMap" package (the script) picks the correct release of base and also - check that your fix works back in 3.6, 3.7 and 3.8 too.
Otherwise I will give it a shot (as I think I said the other day) tonight.
Maybe we need to define more clearly what it really means to be a Maintainer. Right now I have the feeling that making something "maintained" is the best way to ensure that nothing happns at all.
Hardly think so - but our free time comes and goes. Mine has turned pretty slim.
regards, Göran
On 30.03.2006, at 14:53, goran@krampe.se wrote:
and SqueakMap is broken for 3 Months.
"broken" is a bit harsh - yes, it flunks in the current 3.9alpha or beta, but not in 3.8 AFAIK.
Now, if/when you fix it btw - make sure that the "SqueakMap" package (the script) picks the correct release of base and also - check that your fix works back in 3.6, 3.7 and 3.8 too.
Is this reasonable? One codebase for all Squeak versions? I mean, this would imply to add code that tests if the deprecated method has been removed or not, or it would not to test for the version (if version X, call method Y, else method Z). This is bound to become very messy over time...
Wouldn't it make more sense to freeze the external packages with the release (to be developed much more cautiously) while forking a new unstable branch for the new unstabe Squeak release?
To be backward compatible in the sense that all new versions of packages in 3.9 need to work even on old Squeak versions seems to be not really practical...
Marcus
Hi Marcus!
Marcus Denker denker@iam.unibe.ch wrote:
On 30.03.2006, at 14:53, goran@krampe.se wrote:
and SqueakMap is broken for 3 Months.
"broken" is a bit harsh - yes, it flunks in the current 3.9alpha or beta, but not in 3.8 AFAIK.
Now, if/when you fix it btw - make sure that the "SqueakMap" package (the script) picks the correct release of base and also - check that your fix works back in 3.6, 3.7 and 3.8 too.
Is this reasonable? One codebase for all Squeak versions? I mean, this
It has worked so far - and no, not for *all* versions, but from 3.5 I think. :)
would imply to add code that tests if the deprecated method has been removed or not, or it would not to test for the version (if version X, call method Y, else method Z). This is bound to become very messy over time...
Well, it seems that *in practice* it doesn't get *that* hairy - SM mostly uses "vanilla code" in the image.
Wouldn't it make more sense to freeze the external packages with the release (to be developed much more cautiously) while forking a new unstable branch for the new unstabe Squeak release?
I am not sure I parsed what you wrote - but I am guessing that, yes, when it gets too hairy the principal idea is of course to "branch" like you describe BUT... there is one "small" catch. SM is a client server system where we synhronize the model by transferring it in an ImageSegment to the clients and smacking it in. In short - having different client side code running against a server with... the latest code? Well, as you can imaging *that* gets hairy much faster I think :).
Also just trying to maintain different forks for different Squeak versions (automatically upgrading etc when people try to connect to the server with old code blabla) is not easy either.
To be backward compatible in the sense that all new versions of packages in 3.9 need to work even on old Squeak versions seems to be not really practical...
No, of course not - but as I said - SM is different in the sense that it has to support older versions of Squeak (right? :)) and it is based on the ImageSegment approach and also - it seems appropriate that the same domain code runs on the server as on the clients.
Anyway - the "one line 5 minute fix" doesn't include branching SM for 3.9. :)
Marcus
regards, Göran
PS. If you don't get around fixing the issue before say in ... 5 hours then I will fix it - Maya should be asleep then. :) ANd also - there may be other small things I should fix at the same time, we will see.
Is this reasonable? One codebase for all Squeak versions? I mean, this would imply to add code that tests if the deprecated method has been removed or not, or it would not to test for the version (if version X, call method Y, else method Z). This is bound to become very messy over time...
Wouldn't it make more sense to freeze the external packages with the release (to be developed much more cautiously) while forking a new unstable branch for the new unstabe Squeak release?
We should do that. Freeze. freeze
To be backward compatible in the sense that all new versions of packages in 3.9 need to work even on old Squeak versions seems to be not really practical...
:)
Marcus
You ask and ye shall receive. I have asked numerous times for help in maintaining SM but have gotten ZERO replies earlier.
Certainly a miscommunication problem :)
Now apparently you want to help me and great, I am adding you as a co-maintainer and will send you write access to the server.
There is a downside of "maintained" packages: Nothing happens with Network for 3 Months,
Things did happen a bit (at least *I* did a few fixes) but I didn't get around to "zipping it all up". I think I explained it in detail if someone wanted to do the picking - but if noone does then I will eventually get around to it.
Goran this would be good to have a list of fixes and also beasts to beat to death and ask for help.
we have not seen a Unix vm build since three years,
That is true and a bit worrying. Do we have any suggestions on who to pick that up? I can picture a few names in my head - but have no idea about interest.
and SqueakMap is broken for 3 Months.
"broken" is a bit harsh - yes, it flunks in the current 3.9alpha or beta, but not in 3.8 AFAIK.
I got a lot a problem with the students (may be because they are behind firewall) But they get this wlkaback on error .... or should throw away the squeakmap file. I would really like (if possible) to get it fixed in 3.9.
Now, if/when you fix it btw - make sure that the "SqueakMap" package (the script) picks the correct release of base and also - check that your fix works back in 3.6, 3.7 and 3.8 too.
Otherwise I will give it a shot (as I think I said the other day) tonight.
Please.... this would be great to have it in 3.9a.
Hi Stephane!
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:
You ask and ye shall receive. I have asked numerous times for help in maintaining SM but have gotten ZERO replies earlier.
Certainly a miscommunication problem :)
Ehmmmm... no. I have communicated quite clearly but noone has ever stepped up. Simle as that. So in short - until someone actually *does* step up - stop complaining about maintenance.
Now apparently you want to help me and great, I am adding you as a co-maintainer and will send you write access to the server.
There is a downside of "maintained" packages: Nothing happens with Network for 3 Months,
Things did happen a bit (at least *I* did a few fixes) but I didn't get around to "zipping it all up". I think I explained it in detail if someone wanted to do the picking - but if noone does then I will eventually get around to it.
Goran this would be good to have a list of fixes and also beasts to beat to death and ask for help.
I posted at least to the Network list (probably can be found in the I/O team archives today).
we have not seen a Unix vm build since three years,
That is true and a bit worrying. Do we have any suggestions on who to pick that up? I can picture a few names in my head - but have no idea about interest.
and SqueakMap is broken for 3 Months.
"broken" is a bit harsh - yes, it flunks in the current 3.9alpha or beta, but not in 3.8 AFAIK.
I got a lot a problem with the students (may be because they are behind firewall) But they get this wlkaback on error .... or should throw away the squeakmap file. I would really like (if possible) to get it fixed in 3.9.
Sorry but I need more specifics than that. :)
Now, if/when you fix it btw - make sure that the "SqueakMap" package (the script) picks the correct release of base and also - check that your fix works back in 3.6, 3.7 and 3.8 too.
Otherwise I will give it a shot (as I think I said the other day) tonight.
Please.... this would be great to have it in 3.9a.
Ok, I sat down last night and spent a few hours (!) on getting SM into shape for 3.9. It turned out to be more work if doing it properly. SM has been modified quite a bit inside the 3.9 image and that code is based on a pretty old SM version and unfortunately it contained lots of "old removed code" and tons of modifications caused by automatic conversion of underscore to :=.
Now - one question regarding that last part: Why did you replace *all* underscores in the source with ":=" ?!? I saw at least one method in which underscores *inside my String literals* had been replaced. Ouch.
Anyway, now you know I am working on this and hopefully I will get it out today or this weekend. I want to update the server to use the same code as the clients do, I don't want to be out of synch and I definitely don't want clients running different Squeak versions to use different code.
regards, Göran
Am 31.03.2006 um 08:25 schrieb goran@krampe.se:
Ok, I sat down last night and spent a few hours (!) on getting SM into shape for 3.9. It turned out to be more work if doing it properly. [...] unfortunately it contained [...] tons of modifications caused by automatic conversion of underscore to :=.
Now - one question regarding that last part: Why did you replace *all* underscores in the source with ":=" ?!? I saw at least one method in which underscores *inside my String literals* had been replaced. Ouch.
That shouldn't have happened, at least not with my automatic conversion procedure, which carefully does not touch methods that contain underscore in literals. I hope. Of course, when going over the remaining methods manually these might have slipped in.
What would be helpful in this case is if we had a "pretty printed diff" in Monticello so one could see the actual changes undisturbed by cosmetic modifications. I found it so cumbersome to merge 3.9 packages with my own versions that I gave up on it.
Any takers? :)
- Bert -
That shouldn't have happened, at least not with my automatic conversion procedure, which carefully does not touch methods that contain underscore in literals. I hope. Of course, when going over the remaining methods manually these might have slipped in.
bert this is may be my fault.
What would be helpful in this case is if we had a "pretty printed diff" in Monticello so one could see the actual changes undisturbed by cosmetic modifications. I found it so cumbersome to merge 3.9 packages with my own versions that I gave up on it.
Me too and the diff makes often really difficult for me to read the changes.
Any takers? :)
I hope that soon we will have a nice pretty printer so it may help us there.
- Bert -
Me too and the diff makes often really difficult for me to read the changes.
Any takers? :)
I hope that soon we will have a nice pretty printer so it may help us there.
I don't know how compare non-cosmetic changes only, nor the best way to show differences *within* a line instead of only entire-line differences. Both of these would be very nice.
However, I worked on RB's pretty print to suit my own formatting tastes (I was raised with Beck's "Rectangular Block") a couple of weeks ago. I now, *finally*, have hot-key auto-formatting of my code that I can tolerate.
I realize what a great productivity booster auto-formatting is. YOu can just place the cursor within a method, type like crazy whatever you need, then hit command+shift+s followed by command+s.
Made me wonder how much cumululative time I've spent over the years manually formatting code.. :-\
PS - I'm disappointed to hear we're converting a bunch of legacy code to use := instead of left-arrow.. Why mark the original authors of the code with your own personal preference?
Am 31.03.2006 um 13:30 schrieb Bert Freudenberg:
Am 31.03.2006 um 08:25 schrieb goran@krampe.se:
Ok, I sat down last night and spent a few hours (!) on getting SM into shape for 3.9. It turned out to be more work if doing it properly. [...] unfortunately it contained [...] tons of modifications caused by automatic conversion of underscore to :=.
Now - one question regarding that last part: Why did you replace *all* underscores in the source with ":=" ?!? I saw at least one method in which underscores *inside my String literals* had been replaced. Ouch.
That shouldn't have happened, at least not with my automatic conversion procedure, which carefully does not touch methods that contain underscore in literals. I hope. Of course, when going over the remaining methods manually these might have slipped in.
Oh well, turns out there actually *is* a bug in the conversion. It does not recognize literal underscores inside arrays :(
This snippet will find potentially broken methods (those that have a ':=' inside a literal array):
SystemNavigation default browseAllSelect: [:meth | meth literals anySatisfy: [:lit | lit class == Array and: [ | todo found | todo := OrderedCollection withAll: lit. found := false. [found or: [todo isEmpty]] whileFalse: [ | next | next := todo removeFirst. next class == Array ifTrue: [todo addAll: next]. found := next isString and: [next includesSubString: ':=']]. found]]]
I have no fix yet, one would have to change MethodReference>>fixUnderscores to also look inside arrays. Or even better, use the Parser to recognize assignments and only replace those instead of all underscores in the source.
- Bert -
Ehmmmm... no. I have communicated quite clearly but noone has ever stepped up. Simle as that. So in short - until someone actually *does* step up - stop complaining about maintenance.
I'm confused. Are you saying that you do not want to maintain squeakmap. May be I do not understand what you imply?
Things did happen a bit (at least *I* did a few fixes) but I didn't get around to "zipping it all up". I think I explained it in detail if someone wanted to do the picking - but if noone does then I will eventually get around to it.
Goran this would be good to have a list of fixes and also beasts to beat to death and ask for help.
I posted at least to the Network list (probably can be found in the I/O team archives today).
where can we find that? If I want to include that in the release I should know where it is and its status.
I got a lot a problem with the students (may be because they are behind firewall) But they get this wlkaback on error .... or should throw away the squeakmap file. I would really like (if possible) to get it fixed in 3.9.
Sorry but I need more specifics than that. :)
I know but the problems happen always in labs with students and stress :) I get this walkback that says parsing error. most of the time I trash the sm folder and relaunch. I will try to be more precise but I'm travelling right now.
Ok, I sat down last night and spent a few hours (!) on getting SM into shape for 3.9.
Cooooooooooooooooooooooooooooooooooooooooooooooooooooooool
It turned out to be more work if doing it properly. SM has been modified quite a bit inside the 3.9 image and that code is based on a pretty old SM version and unfortunately it contained lots of "old removed code" and tons of modifications caused by automatic conversion of underscore to :=.
Now - one question regarding that last part: Why did you replace *all* underscores in the source with ":=" ?!?
Because we got a lot of problems with code comparisons (when you integrate code you do not want to have problems because people used Shout or not).
I saw at least one method in which underscores *inside my String literals* had been replaced. Ouch.
Ok an error, sorry about that.
Anyway, now you know I am working on this and hopefully I will get it out today or this weekend.
Excellent because now we feel a bit orphan :)
I want to update the server to use the same code as the clients do, I don't want to be out of synch and I definitely don't want clients running different Squeak versions to use different code.
I understand. There is no rush but squeakmap is an important assets of Squeak now and we got used to it :) Diego is harvesting his fixes and we are thinking about the integration of ned connectors (but this will not be for now too much overrides).
Stef
stéphane ducasse skrev:
I got a lot a problem with the students (may be because they are behind firewall) But they get this wlkaback on error .... or should throw away the squeakmap file. I would really like (if possible) to get it fixed in 3.9.
Sorry but I need more specifics than that. :)
I know but the problems happen always in labs with students and stress :) I get this walkback that says parsing error. most of the time I trash the sm folder and relaunch. I will try to be more precise but I'm travelling right now.
Sounds like the problem that happen if you open SM and it updates, but you don't save the image. Next time you try to open SM you get a error. Maybe a warning that you should save the image after SM is updated would fix that. Karl
Hi!
karl karl.ramberg@chello.se wrote:
stéphane ducasse skrev:
I got a lot a problem with the students (may be because they are behind firewall) But they get this wlkaback on error .... or should throw away the squeakmap file. I would really like (if possible) to get it fixed in 3.9.
Sorry but I need more specifics than that. :)
I know but the problems happen always in labs with students and stress :)
:)
I get this walkback that says parsing error. most of the time I trash the sm folder and relaunch. I will try to be more precise but I'm travelling right now.
Sounds like the problem that happen if you open SM and it updates, but you don't save the image. Next time you try to open SM you get a error. Maybe a warning that you should save the image after SM is updated would fix that. Karl
I actually now think I know what it is/was. I suspect (haven't looked in total detail) that the current code ends up making some kind of m17n related conversion (not StandardFileStream) when saving the map so that the .gz file actually isn't recognized as a gz file (wrong magic bytes in the header) and thus isn't decompressed - so the actual imagesegment loading then of course fails badly.
Anyway, I just converted that code back to using StandardFileStream explicitly both on save and load and I now think the code does the exact same "good ole" thing in all versions 3.5-3.9. We will see.
I intend to very soon (this weekend hopefully) deploy this code to both the server and to update the map entry for SqueakMap and bumping the protocol version forcing all clients to upgrade.
regards, Göran
I actually now think I know what it is/was. I suspect (haven't looked in total detail) that the current code ends up making some kind of m17n related conversion (not StandardFileStream) when saving the map so that the .gz file actually isn't recognized as a gz file (wrong magic bytes in the header) and thus isn't decompressed - so the actual imagesegment loading then of course fails badly.
could be that since I always get a parsing error kind of...:)
Anyway, I just converted that code back to using StandardFileStream explicitly both on save and load and I now think the code does the exact same "good ole" thing in all versions 3.5-3.9. We will see.
I intend to very soon (this weekend hopefully) deploy this code to both the server and to update the map entry for SqueakMap and bumping the protocol version forcing all clients to upgrade.
regards, Göran
sounds like that indeed.
I know but the problems happen always in labs with students and stress :) I get this walkback that says parsing error. most of the time I trash the sm folder and relaunch. I will try to be more precise but I'm travelling right now.
Sounds like the problem that happen if you open SM and it updates, but you don't save the image. Next time you try to open SM you get a error. Maybe a warning that you should save the image after SM is updated would fix that. Karl
Folks -
I have my Squeak VM in Java working so that the entire Mini2.1 image runs quite nicely. I'd like help from anyone who would have fun playing with this. The main things I'd like help with are...
Support for changing color depth (at least to 8, 16, and 32 bits; ideally all). I currently have it working with 1-bit B/W only. I believe BitBlt works in color; I just need to be able to change the color model in the AWT window. Support for changing the window size, both from inside Squeak and by window resize. Getting various command characters to work right on various platforms, especially cmd-period. Also, booting from a .jnlp web link would be nice. I've tried the JavaWebStart stuff and couldn't get it to work
It may sound crazy for me to be asking here, since I work at Sun now, but folks here are busy doing other things, and I'm hoping for someone who would already know what they are looking at if they see Squeak VM code.
The minute it does color and can boot from a web page, I'll put it out.
Please reply directly to me so we don't clutter this list with extra traffic
Thanks - Dan
Hi Dan
what is the speed of your VM on a normally fast :) Java VM?
Stef
On 1 avr. 06, at 01:51, Dan Ingalls wrote:
Folks -
I have my Squeak VM in Java working so that the entire Mini2.1 image runs quite nicely. I'd like help from anyone who would have fun playing with this. The main things I'd like help with are...
Support for changing color depth (at least to 8, 16, and 32 bits; ideally all). I currently have it working with 1-bit B/W only. I believe BitBlt works in color; I just need to be able to change the color model in the AWT window. Support for changing the window size, both from inside Squeak and by window resize. Getting various command characters to work right on various platforms, especially cmd-period. Also, booting from a .jnlp web link would be nice. I've tried the JavaWebStart stuff and couldn't get it to work
It may sound crazy for me to be asking here, since I work at Sun now, but folks here are busy doing other things, and I'm hoping for someone who would already know what they are looking at if they see Squeak VM code.
The minute it does color and can boot from a web page, I'll put it out.
Please reply directly to me so we don't clutter this list with extra traffic
Thanks
- Dan
Hi, Stef -
what is the speed of your VM on a normally fast :) Java VM?
I don't know what a normally fast JVM is. However I can say that on my Mac it runs about 1/10 the speed of the native Squeak VM, in both tinyBenchmark figures. The BitBlt is much faster -- almost the same speed -- and the end result is that the Mini image is entirely usable, even without text or line drawing primitives, nor any of the stream primitives. I can think of various hacks to make it faster, but that's not my focus right now.
It's nice and small. I've never printed it, so I can't say how many pages, but it's 160k of source code. The entire .jar file is 433k, which includes the VM and the mini image (you know, the one that can decompile 800k of source code with temp names).
- Dan
Nifty!
Cheers,
Alan
------------
At 08:41 AM 4/1/2006, Dan Ingalls wrote:
Hi, Stef -
what is the speed of your VM on a normally fast :) Java VM?
I don't know what a normally fast JVM is. However I can say that on my Mac it runs about 1/10 the speed of the native Squeak VM, in both tinyBenchmark figures. The BitBlt is much faster -- almost the same speed -- and the end result is that the Mini image is entirely usable, even without text or line drawing primitives, nor any of the stream primitives. I can think of various hacks to make it faster, but that's not my focus right now.
It's nice and small. I've never printed it, so I can't say how many pages, but it's 160k of source code. The entire .jar file is 433k, which includes the VM and the mini image (you know, the one that can decompile 800k of source code with temp names).
- Dan
Now - one question regarding that last part: Why did you replace
*all*
underscores in the source with ":=" ?!?
Because we got a lot of problems with code comparisons (when you integrate code you do not want to have problems because people used Shout or not).
So because Shout is rude and intrusive in this respect (it is great in its other respects and I enjoy using it), the solution is to intrude on the "the rest of the worlds" code and make it conform to Shouts default setting?
Personally, I set mine to left-arrow since that's my preference. But why is the syntax highlighter in the business of dictating a particular assignment operator anyway? Why not just leave it alone and whatever the developer types is what he gets?
Hi!
(missed this one before)
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:
Ehmmmm... no. I have communicated quite clearly but noone has ever stepped up. Simle as that. So in short - until someone actually *does* step up - stop complaining about maintenance.
I'm confused. Are you saying that you do not want to maintain squeakmap. May be I do not understand what you imply?
No, I intend to maintain SqueakMap for many more years. But it will be ups and downs. Lately there has been a down period. I am just saying that I am not *stopping* people from helping me - on the contrary - I have asked numerous times for people to join me in the maintenance/development of it. But as I said, so far noone has actually showed any real interest.
And given that situation I humbly ask people to not groan too much about maintenance.
Things did happen a bit (at least *I* did a few fixes) but I didn't get around to "zipping it all up". I think I explained it in detail if someone wanted to do the picking - but if noone does then I will eventually get around to it.
Goran this would be good to have a list of fixes and also beasts to beat to death and ask for help.
I posted at least to the Network list (probably can be found in the I/O team archives today).
where can we find that? If I want to include that in the release I should know where it is and its status.
Well, I am dealing with SM now - feel free to bug the others on the I/O team :) but here are my two most important postings:
http://lists.squeakfoundation.org/pipermail/io/2005-October/000040.html http://lists.squeakfoundation.org/pipermail/io/2005-December/000046.htm l
And here are the mcz's with detailed version notes:
http://source.squeakfoundation.org/network/
I am pretty confident that my mcz's are pretty ok to include but don't remember about the KLC mcz's (Ken Causey).
[SNIP]
Now - one question regarding that last part: Why did you replace *all* underscores in the source with ":=" ?!?
Because we got a lot of problems with code comparisons (when you integrate code you do not want to have problems because people used Shout or not).
I agree with the idea of having one representation of assignment in the stored source - I just thought that getting new method versions (IIRC) for this and also replacing inside comments (!) and inside literals (!) seemed pretty buggy to me.
I saw at least one method in which underscores *inside my String literals* had been replaced. Ouch.
Ok an error, sorry about that.
Ok. Just note that we might want to find what methods were "banged up" like this. My particular method stopped working (as you might have guessed) because of this.
Anyway, now you know I am working on this and hopefully I will get it out today or this weekend.
Excellent because now we feel a bit orphan :)
Well, as I said - the offer to help me is wiiiiide open. Just step up to the plate! :) But yes, I intend to focus more on SM from now on.
regards, Göran
So we could include that in the next build then.
Stef
On 3 avr. 06, at 12:58, goran@krampe.se wrote:
And here are the mcz's with detailed version notes:
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:
So we could include that in the next build then.
Stef
I think so, yes. But to be *absolutely* stringent - Cees is the team leader of I/O. And of course, a bit of peer review on my mcz's would be nice. :)
regards, Göran
On 3 avr. 06, at 12:58, goran@krampe.se wrote:
And here are the mcz's with detailed version notes:
Since I do not really understand what you imply we will wait that someone sends an email to v3dot9@discuss.squeakfoundation.org
Stef
On 3 avr. 06, at 14:23, goran@krampe.se wrote:
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:
So we could include that in the next build then.
Stef
I think so, yes. But to be *absolutely* stringent - Cees is the team leader of I/O. And of course, a bit of peer review on my mcz's would be nice. :)
regards, Göran
On 3 avr. 06, at 12:58, goran@krampe.se wrote:
And here are the mcz's with detailed version notes:
Hi!
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:
Since I do not really understand what you imply we will wait that someone sends an email to v3dot9@discuss.squeakfoundation.org
Stef
I just meant that yes - I think my mcz's are ready to go in (at least if someone peer reviews them, please...) but since I am not the I/O team leader I am not taking the "decision". Cees is the one to do that IMHO. Or you could by just "grabbing" the stuff. :)
regards, Göran
On 30 mars 06, at 13:48, Marcus Denker wrote:
It's a one line fix, but that has to be done in a repository where I have no access to, so I can not fix it myself.... sorry. There is a downside of "maintained" packages: Nothing happens with Network for 3 Months, we have not seen a Unix vm build since three years, and SqueakMap is broken for 3 Months. Maybe we need to define more clearly what it really means to be a Maintainer. Right now I have the feeling that making something "maintained" is the best way to ensure that nothing happns at all.
Yes we should fix that.
Stef
I don't know the complete process and chain of responsabilities, as I've said before.
But I think that could exist some way of help with fast patches as this, were several people (even a not very experienced as me) could help.
Abot Göran words: I understand (I suffer the same) that the free time is ever little, but in this case is only a line to patch, and having the responsability of the package, I think that the maintainer must patch. (About how many time we are talking, 5 minutes, 10 muinutes?).
Well, is only my opinion.
Cheers.
2006/3/30, stéphane ducasse ducasse@iam.unibe.ch:
On 30 mars 06, at 13:48, Marcus Denker wrote:
It's a one line fix, but that has to be done in a repository where I have no access to, so I can not fix it myself.... sorry. There is a downside of "maintained" packages: Nothing happens with Network for 3 Months, we have not seen a Unix vm build since three years, and SqueakMap is broken for 3 Months. Maybe we need to define more clearly what it really means to be a Maintainer. Right now I have the feeling that making something "maintained" is the best way to ensure that nothing happns at all.
Yes we should fix that.
Stef
On Thu, 30 Mar 2006 10:24:55 -0300, "Germán Arduino" garduino@gmail.com wrote:
Abot Göran words: I understand (I suffer the same) that the free time is ever little, but in this case is only a line to patch, and having the responsability of the package, I think that the maintainer must patch. (About how many time we are talking, 5 minutes, 10 muinutes?).
15 minutes, at least, I'd figure. At least if you want some quality: - Investigate the bug; - Investigate the patch, whether it is valid, whether it shouldn't break stuff; - Run the tests (are there tests with the one-line patch? If not, the previous two steps take longer); - Integrate and publish to the MC repository; - Close the bug on Mantis.
Marcus Denker wrote:
we have not seen a Unix vm build since three years,
http://squeakvm.org/unix/release/
Squeak-3.8a-1.noarch.rpm 22-Mar-2005 14:11 1.5K Squeak-3.8a-1.src.tar.gz 22-Mar-2005 14:11 2.4M Squeak-3.8g-6548.image.tar.gz 22-Mar-2005 14:11 11M
That's about ten months old, and it's built for 3.8.
- A.
On 30-Mar-06, at 2:06 PM, Andreas Raab wrote:
Marcus Denker wrote:
we have not seen a Unix vm build since three years,
http://squeakvm.org/unix/release/
Squeak-3.8a-1.noarch.rpm 22-Mar-2005 14:11 1.5K Squeak-3.8a-1.src.tar.gz 22-Mar-2005 14:11 2.4M Squeak-3.8g-6548.image.tar.gz 22-Mar-2005 14:11 11M
That's about ten months old, and it's built for 3.8.
Actually since it's March 29th today that would pretty much precisely a year. Depending on whose floating point library you had used of course...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "#define QUESTION ((bb) || !(bb)) - Shakespeare."
tim Rowledge wrote:
http://squeakvm.org/unix/release/
Squeak-3.8a-1.noarch.rpm 22-Mar-2005 14:11 1.5K Squeak-3.8a-1.src.tar.gz 22-Mar-2005 14:11 2.4M Squeak-3.8g-6548.image.tar.gz 22-Mar-2005 14:11 11M
That's about ten months old, and it's built for 3.8.
Actually since it's March 29th today that would pretty much precisely a year. Depending on whose floating point library you had used of course...
Nah, it's just that my precognition abilities are greatly improving - I actually wrote this message two months ago and just forgot to send it ;-) (seriously, I read "May" instead of "Mar"; maybe I should stop using these sub-pixel rendered fonts, they are so hard to read at 3pt ;-)
Cheers, - Andreas
On 30-Mar-06, at 2:06 PM, Andreas Raab wrote:
Marcus Denker wrote:
we have not seen a Unix vm build since three years,
http://squeakvm.org/unix/release/
Squeak-3.8a-1.noarch.rpm 22-Mar-2005 14:11 1.5K Squeak-3.8a-1.src.tar.gz 22-Mar-2005 14:11 2.4M Squeak-3.8g-6548.image.tar.gz 22-Mar-2005 14:11 11M
That's about ten months old, and it's built for 3.8.
Oh, and I don't find myself amused at crap like this in the ChangeLog file, either-
2005-03-15 Ian Piumarta ian.piumarta@hp.com
* vm/sqUnixMain.c (getImageName): Added, under extreme duress, to deal with tpr laziness/sloppiness.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Why do we want intelligent terminals when there are so many stupid users?
tim Rowledge tim@rowledge.org wrote:
Oh, and I don't find myself amused at crap like this in the ChangeLog file, either-
2005-03-15 Ian Piumarta ian.piumarta@hp.com
- vm/sqUnixMain.c (getImageName): Added, under extreme duress, to
deal with tpr laziness/sloppiness.
I agree with you Tim, that is not the way to act in this community IMHO (regardless of the issue at hand which I know nothing about).
regards, Göran
Germán Arduino wrote:
Hi:
About the problem http://bugs.impara.de/view.php?id=2912, that I've documented a workaround at http://bugs.impara.de/view.php?id=3283 I want to ask how many time may take to be fixed.
Hi, I see the discussion has slipped away from the main subject. I also spent some time debugging this and I have 2 questions:
1. does SM support preamble/postscripts? The SM browser from a 3.9a image has a button for this. If it does then maybe the place of the update script should be in one of the mcz packages of SMLoader, SMBAse etc.
2. fixing this bug means changing the SqueakMap script, that is downloaded from server, to use SmalltalkImage current logChange. The question is: will this not break the update for older squeak images? Is there a way to choose the update script based on the SM version we upgrade to and the image version we are working on?
Best regards, cdan.
Hi!
Dan Corneanu cdan@savatech.ro wrote:
Germán Arduino wrote:
Hi:
About the problem http://bugs.impara.de/view.php?id=2912, that I've documented a workaround at http://bugs.impara.de/view.php?id=3283 I want to ask how many time may take to be fixed.
Hi, I see the discussion has slipped away from the main subject. I also spent some time debugging this and I have 2 questions:
- does SM support preamble/postscripts? The SM browser from a 3.9a
image has a button for this. If it does then maybe the place of the update script should be in one of the mcz packages of SMLoader, SMBAse etc.
Eh... not sure what you mean. If you are talking about how SM upgrades itself - then that is a "custom" solution since it must be able to do so even though it can't download a new map (since it is old, moment 22).
- fixing this bug means changing the SqueakMap script, that is
downloaded from server, to use SmalltalkImage current logChange. The question is: will this not break the update for older squeak images? Is there a way to choose the update script based on the SM version we upgrade to and the image version we are working on?
Well, there are always "ways" but I really want to keep SM in one piece as long as possible due to reasons I have already explained. And as a sidenote I can mention that Avi does exactly the same with Monticello - he also checks what to use - just see senders of #logChange:.
Best regards, cdan.
regards, Göran
goran@krampe.se wrote:
- does SM support preamble/postscripts? The SM browser from a 3.9a
image has a button for this. If it does then maybe the place of the update script should be in one of the mcz packages of SMLoader, SMBAse etc.
Eh... not sure what you mean. If you are talking about how SM upgrades itself - then that is a "custom" solution since it must be able to do so even though it can't download a new map (since it is old, moment 22).
Yes right, I forgot that the process of *upgrading SM* is not able to use SM until it has finished with the upgrade :) My mistake! I have also been misled, by mcz packages found in the SM repository, into confusing Monticello with SqueakMap.
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Andreas Raab -
Bert Freudenberg -
Cees de Groot -
Chris Muller -
Damien Cassou -
Dan Corneanu -
Dan Ingalls -
Germán Arduino -
goran＠krampe.se -
karl -
Marcus Denker -
stéphane ducasse -
tim Rowledge