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 <[hidden email]> Date: 15-mar-2006 11:31 Subject: About the #logChange error in SqueakMap To: The general-purpose Squeak developers list <[hidden email]> 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 SMInstallationRegistry-gsa.1.cs (1K) Download Attachment |
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 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 <[hidden email]>: > 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. > 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. Bye |
2006/3/29, Damien Cassou <[hidden email]>:
> Hi, > > thank you very much for your help, it works now. > > > 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. > > > 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 <[hidden email]>: >> Hi, >> >> thank you very much for your help, it works now. >> >>> 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. >> >> >> 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 |
On 30.03.2006, at 13:48, Marcus Denker wrote: > > > Nothing happens with Network for 3 Months, we have not seen a Unix > vm build since > three years It's not that bad, it's one year, build using the 3.7 vm-maker... Marcus |
In reply to this post by Marcus Denker
Hi people!
Marcus Denker <[hidden email]> 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 |
In reply to this post by Marcus Denker
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 <[hidden email]>: > > 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"
<[hidden email]> 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. |
In reply to this post by Göran Krampe
On 30.03.2006, at 14:53, [hidden email] 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 <[hidden email]> wrote: > On 30.03.2006, at 14:53, [hidden email] 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. |
In reply to this post by Göran Krampe
>
> 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. |
In reply to this post by Marcus Denker
> 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 > |
In reply to this post by Marcus Denker
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. a year. Depending on whose floating point library you had used of course... tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim "#define QUESTION ((bb) || !(bb)) - Shakespeare." |
In reply to this post by Andreas.Raab
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 <[hidden email]> * vm/sqUnixMain.c (getImageName): Added, under extreme duress, to deal with tpr laziness/sloppiness. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Why do we want intelligent terminals when there are so many stupid users? |
tim Rowledge <[hidden email]> wrote:
> Oh, and I don't find myself amused at crap like this in the ChangeLog > file, either- > > 2005-03-15 Ian Piumarta <[hidden email]> > > * 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 |
Free forum by Nabble | Edit this page |