About the #logChange error in SqueakMap

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

About the #logChange error in SqueakMap

garduino
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.

Reply | Threaded
Open this post in threaded view
|

Fwd: About the #logChange error in SqueakMap

garduino
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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: About the #logChange error in SqueakMap

Damien Cassou-3
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


Reply | Threaded
Open this post in threaded view
|

Re: Fwd: About the #logChange error in SqueakMap

garduino
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
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Fwd: About the #logChange error in SqueakMap

Damien Cassou-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Fwd: About the #logChange error in SqueakMap

garduino
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.

Reply | Threaded
Open this post in threaded view
|

Re: About the #logChange error in SqueakMap

Marcus Denker

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
Reply | Threaded
Open this post in threaded view
|

Re: About the #logChange error in SqueakMap

Marcus Denker

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



Reply | Threaded
Open this post in threaded view
|

Re: About the #logChange error in SqueakMap

Göran Krampe
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

Reply | Threaded
Open this post in threaded view
|

Re: About the #logChange error in SqueakMap

stéphane ducasse-2
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

Reply | Threaded
Open this post in threaded view
|

Re: About the #logChange error in SqueakMap

garduino
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: About the #logChange error in SqueakMap

Cees de Groot-2
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.


Reply | Threaded
Open this post in threaded view
|

Re: About the #logChange error in SqueakMap

Marcus Denker
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

Reply | Threaded
Open this post in threaded view
|

Re: About the #logChange error in SqueakMap

Göran Krampe
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.

Reply | Threaded
Open this post in threaded view
|

Re: About the #logChange error in SqueakMap

stéphane ducasse-2
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.


Reply | Threaded
Open this post in threaded view
|

Re: About the #logChange error in SqueakMap

stéphane ducasse-2
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
>


Reply | Threaded
Open this post in threaded view
|

Re: About the #logChange error in SqueakMap

Andreas.Raab
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.

Reply | Threaded
Open this post in threaded view
|

Re: About the #logChange error in SqueakMap

timrowledge

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; [hidden email]; http://www.rowledge.org/tim
"#define QUESTION ((bb) || !(bb))  - Shakespeare."



Reply | Threaded
Open this post in threaded view
|

Re: About the #logChange error in SqueakMap

timrowledge
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?



Reply | Threaded
Open this post in threaded view
|

Re: About the #logChange error in SqueakMap

Göran Krampe
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

123