About the #logChange error in SqueakMap

Hi Stephane!

=?ISO-8859-1?Q?st=E9phane_ducasse?= <[hidden email]> 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.

I posted at least to the Network list (probably can be found in the I/O
team archives today).

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 [hidden email]:

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 -

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

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

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

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

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

I wrote:

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

One solution to the problem of cosmetic changes showing as differences:

  Don't do it

especially on others' code.

If someone is changing functionality, they are welcome to reformat
entire methods they change to their taste.  Otherwise, I would (almost)
never make cosmetic-only changes to other peoples code..

Hi!

karl <[hidden email]> wrote:
:)

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

sounds like that indeed.

Hi chris,

I'm not sure I understood what you meant exactly but here are some  
points to explain
what drived us:

        - the code in the image should be homogenous so having := consistently
        would be better than having one methods with _ and one with :=

        - we tried to ease the transition between Squeak and the other  
Smalltalks which
        (as far as I know but I can be wrong use :=).

        - people can use the characters they want for their code
       
        - I would loved to get a consistently formatting and I believe in  
your increase in productivity ;)
        I hope that the pretty printer a guy here is doing will be cool  
enough so that everybody can use it

Stef

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

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

could be that since I always get a parsing error kind of...:)

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:

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!

(missed this one before)

=?ISO-8859-1?Q?st=E9phane_ducasse?= <[hidden email]> 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.

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, [hidden email] wrote:

> And here are the mcz's with detailed version notes:
>
> http://source.squeakfoundation.org/network/

=?ISO-8859-1?Q?st=E9phane_ducasse?= <[hidden email]> 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, [hidden email] wrote:
>
> > And here are the mcz's with detailed version notes:
> >
> > http://source.squeakfoundation.org/network/