[squeak-dev] Re: SqueakMap Status?

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

[squeak-dev] Re: SqueakMap Status?

Göran Krampe
Hi again!

Ok, now I made a fix to "SqueakMap2 Base" (SMBase) - available on SM,
version 1.24. Use that and in your release procedure you can do:

        SMSqueakMap default purge

...and it still will work when freshly installed.

That should get you to around 13.79 Mb (well, with 3.10.2-7179 at least).

cheers, Göran


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: SqueakMap Status?

NorbertHartl
On Fri, 2009-02-13 at 10:02 +0100, Göran Krampe wrote:

> Hi again!
>
> Ok, now I made a fix to "SqueakMap2 Base" (SMBase) - available on SM,
> version 1.24. Use that and in your release procedure you can do:
>
> SMSqueakMap default purge
>
> ...and it still will work when freshly installed.
>
> That should get you to around 13.79 Mb (well, with 3.10.2-7179 at least).
>
Was it something different than

http://code.google.com/p/pharo/issues/detail?id=193

http://bugs.squeak.org/view.php?id=7201

?

Norbert



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: SqueakMap Status?

Göran Krampe
Norbert Hartl wrote:

> On Fri, 2009-02-13 at 10:02 +0100, Göran Krampe wrote:
>> Hi again!
>>
>> Ok, now I made a fix to "SqueakMap2 Base" (SMBase) - available on SM,
>> version 1.24. Use that and in your release procedure you can do:
>>
>> SMSqueakMap default purge
>>
>> ...and it still will work when freshly installed.
>>
>> That should get you to around 13.79 Mb (well, with 3.10.2-7179 at least).
>>
> Was it something different than
>
> http://code.google.com/p/pharo/issues/detail?id=193
>
> http://bugs.squeak.org/view.php?id=7201
> slightly
> ?

Bloody hell :).

I didn't check on Mantis because I thought Keith had already checked (me
emailed me). BUT... I think my fix is better - I made sure that when you
try to open the UI for SM it will note that the map is indeed purged AND
that you don't have a map on disk - and it will tell you that and offer
to load a map from the net.

Ah... but if you *decline* doing that my fix is probably not complete.
Right, then you will end up in the debugger anyway of course. Ok, I will
integrate this fix too and even though running a UI on top of a purged
map might be "error prone" - it is probably better than refusing to open
the UI. :)

Thanks Norbert for the heads up.

regards, Göran


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: SqueakMap Status?

NorbertHartl
On Fri, 2009-02-13 at 12:44 +0100, Göran Krampe wrote:

> Norbert Hartl wrote:
> > On Fri, 2009-02-13 at 10:02 +0100, Göran Krampe wrote:
> >> Hi again!
> >>
> >> Ok, now I made a fix to "SqueakMap2 Base" (SMBase) - available on SM,
> >> version 1.24. Use that and in your release procedure you can do:
> >>
> >> SMSqueakMap default purge
> >>
> >> ...and it still will work when freshly installed.
> >>
> >> That should get you to around 13.79 Mb (well, with 3.10.2-7179 at least).
> >>
> > Was it something different than
> >
> > http://code.google.com/p/pharo/issues/detail?id=193
> >
> > http://bugs.squeak.org/view.php?id=7201
> > slightly
> > ?
>
> Bloody hell :).
>
> I didn't check on Mantis because I thought Keith had already checked (me
> emailed me). BUT... I think my fix is better - I made sure that when you
> try to open the UI for SM it will note that the map is indeed purged AND
> that you don't have a map on disk - and it will tell you that and offer
> to load a map from the net.
>
> Ah... but if you *decline* doing that my fix is probably not complete.
> Right, then you will end up in the debugger anyway of course. Ok, I will
> integrate this fix too and even though running a UI on top of a purged
> map might be "error prone" - it is probably better than refusing to open
> the UI. :)
>
> Thanks Norbert for the heads up.

Somehow I got amiable through Keiths Mail to the pharo list. He was
blaming the pharo crew for not caring about squeak and things/fixes
others do. That was exactly the reason back then for me to fix it in
pharo and then open a bug on mantis as well. So it turns out that the
integrational aspect doesn't work in either direction.

And now I'm really concerned, too. Would be good to have at least a
minimal exchange base between all squeak forks.

Norbert


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: SqueakMap Status?

keith1y

> Somehow I got amiable through Keiths Mail to the pharo list. He was
> blaming the pharo crew for not caring about squeak and things/fixes
> others do. That was exactly the reason back then for me to fix it in
> pharo and then open a bug on mantis as well. So it turns out that the
> integrational aspect doesn't work in either direction.
>  
It would work fine if....

SqueakMap was treated as an external package to both squeak and pharo,
and the repo, or at least a repo is available to any contributors that
want to improve things.

In squeak 3.11, 4.1 or what ever it will be called we will simply build
every build with the latest (credited to be working) version of the
external tools*, or if the tool is not present in the image, the
Sake/Packages definition will enable the package to be loadable. We make
no claim on the quality of the package, if it works or not that is up to
the package developers. The package is in any case an optional extra,
either unloadable if it is loaded, or loadable if it is not. As long as
full images are available for testing, the continuous testing and the
feedback loop should keep everyone on their toes and everything working.

*I never did understand why 3.10 shipped with a version of Installer
that was 40 (?) versions behind.

If in the case of SqueakMap situation mentioned you "fixed it in pharo"
then that means there is likely to be a new SMBase with your initials on
it, where is it? If it is languishing in a pharo repository, then that
simply illustrates my point. Namely, that pharo should conceptually
treat external packages as external packages, and contributors should be
encouraged to improve such external packages for everyone. e.g. tell the
maintainer what is going on, and check your changes back in to the main
development stream... isn't it rude not to?

My complaint against pharo is that while the rest of the squeak
community has been trying to modularize the image and treat more and
more modules as external loadable packages. The pharo team goes back 3
(?) years and ignores anything done in said external projects in the
meantime, thus wasting a lot of effort and emotional energy. The team
does this as a matter of principle, and it is this principle that I was
attempting to challenge (while far too tired and irritable).

btw thanks for you feedback

Keith

-
p.s. Göran, sorry I didnt think to scan Mantis, it was 5.30am, and I was
running on far too little sleep. I saw two new versions in the repo so I
assumed they would have some goodies in them already.
> And now I'm really concerned, too. Would be good to have at least a
> minimal exchange base between all squeak forks.
>
> Norbert
>
>
>
>  


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: SqueakMap Status?

Adrian Lienhard

On Feb 13, 2009, at 18:06 , Keith Hodges wrote:

>
>> Somehow I got amiable through Keiths Mail to the pharo list. He was
>> blaming the pharo crew for not caring about squeak and things/fixes
>> others do. That was exactly the reason back then for me to fix it in
>> pharo and then open a bug on mantis as well. So it turns out that the
>> integrational aspect doesn't work in either direction.
>>
> It would work fine if....
>
> SqueakMap was treated as an external package to both squeak and pharo,
> and the repo, or at least a repo is available to any contributors that
> want to improve things.

[...]

> If in the case of SqueakMap situation mentioned you "fixed it in  
> pharo"
> then that means there is likely to be a new SMBase with your  
> initials on
> it, where is it? If it is languishing in a pharo repository, then that
> simply illustrates my point. Namely, that pharo should conceptually
> treat external packages as external packages, and contributors  
> should be
> encouraged to improve such external packages for everyone. e.g. tell  
> the
> maintainer what is going on, and check your changes back in to the  
> main
> development stream... isn't it rude not to?

For version 1.0 we've planned to remove SqueakMap from the Pharo core  
and treat it as an external package.

> My complaint against pharo is that while the rest of the squeak
> community has been trying to modularize the image and treat more and
> more modules as external loadable packages. The pharo team goes back 3
> (?) years and ignores anything done in said external projects in the

As a side note, Keith, I'm slightly getting annoyed being criticized  
over again for what we do wrong in your opinion. To do it our own way  
without conflicting with the Squeak way of doing (or not doing)  
things, is why we left. I believe that we can profit from the common  
effort, but it should happen in a constructive way.

Adrian

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: SqueakMap Status?

Igor Stasenko
2009/2/13 Adrian Lienhard <[hidden email]>:

>
> On Feb 13, 2009, at 18:06 , Keith Hodges wrote:
>
>>
>>> Somehow I got amiable through Keiths Mail to the pharo list. He was
>>> blaming the pharo crew for not caring about squeak and things/fixes
>>> others do. That was exactly the reason back then for me to fix it in
>>> pharo and then open a bug on mantis as well. So it turns out that the
>>> integrational aspect doesn't work in either direction.
>>>
>> It would work fine if....
>>
>> SqueakMap was treated as an external package to both squeak and pharo,
>> and the repo, or at least a repo is available to any contributors that
>> want to improve things.
>
> [...]
>
>> If in the case of SqueakMap situation mentioned you "fixed it in pharo"
>> then that means there is likely to be a new SMBase with your initials on
>> it, where is it? If it is languishing in a pharo repository, then that
>> simply illustrates my point. Namely, that pharo should conceptually
>> treat external packages as external packages, and contributors should be
>> encouraged to improve such external packages for everyone. e.g. tell the
>> maintainer what is going on, and check your changes back in to the main
>> development stream... isn't it rude not to?
>
> For version 1.0 we've planned to remove SqueakMap from the Pharo core and
> treat it as an external package.
>
>> My complaint against pharo is that while the rest of the squeak
>> community has been trying to modularize the image and treat more and
>> more modules as external loadable packages. The pharo team goes back 3
>> (?) years and ignores anything done in said external projects in the
>
> As a side note, Keith, I'm slightly getting annoyed being criticized over
> again for what we do wrong in your opinion. To do it our own way without
> conflicting with the Squeak way of doing (or not doing) things, is why we
> left. I believe that we can profit from the common effort, but it should
> happen in a constructive way.
>
> Adrian
>
>

Keith, i understand your rightfull indignation.
But i personally feel, that people who making fixes to external
packages having no intent on keeping them private.
It comes simply from different development process they involved in,
and our common laziness to do something in addition (like ANN the fix)
to what possibly be done to fix some annoying issue.

I seen multiple 'twas already fixed in XYZ' in this mailing list. And
XYZ is not always =='Pharo' :)
I think that such message could serve as a signal for
backporting/reintegration but not as a signal to bash people :)


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: SqueakMap Status?

Edgar J. De Cleene




--- El vie 13-feb-09, Igor Stasenko <[hidden email]> escribió:

> De: Igor Stasenko <[hidden email]>
> Asunto: Re: [squeak-dev] Re: SqueakMap Status?
> Para: "The general-purpose Squeak developers list" <[hidden email]>
> Fecha: viernes, 13 de febrero de 2009, 3:53 pm
> 2009/2/13 Adrian Lienhard <[hidden email]>:
> >
> > On Feb 13, 2009, at 18:06 , Keith Hodges wrote:
> >
> >>
> >>> Somehow I got amiable through Keiths Mail to
> the pharo list. He was
> >>> blaming the pharo crew for not caring about
> squeak and things/fixes
> >>> others do. That was exactly the reason back
> then for me to fix it in
> >>> pharo and then open a bug on mantis as well.
> So it turns out that the
> >>> integrational aspect doesn't work in
> either direction.
> >>>
> >> It would work fine if....
> >>
> >> SqueakMap was treated as an external package to
> both squeak and pharo,
> >> and the repo, or at least a repo is available to
> any contributors that
> >> want to improve things.
> >
> > [...]
> >
> >> If in the case of SqueakMap situation mentioned
> you "fixed it in pharo"
> >> then that means there is likely to be a new SMBase
> with your initials on
> >> it, where is it? If it is languishing in a pharo
> repository, then that
> >> simply illustrates my point. Namely, that pharo
> should conceptually
> >> treat external packages as external packages, and
> contributors should be
> >> encouraged to improve such external packages for
> everyone. e.g. tell the
> >> maintainer what is going on, and check your
> changes back in to the main
> >> development stream... isn't it rude not to?
> >
> > For version 1.0 we've planned to remove SqueakMap
> from the Pharo core and
> > treat it as an external package.
> >
> >> My complaint against pharo is that while the rest
> of the squeak
> >> community has been trying to modularize the image
> and treat more and
> >> more modules as external loadable packages. The
> pharo team goes back 3
> >> (?) years and ignores anything done in said
> external projects in the
> >
> > As a side note, Keith, I'm slightly getting
> annoyed being criticized over
> > again for what we do wrong in your opinion. To do it
> our own way without
> > conflicting with the Squeak way of doing (or not
> doing) things, is why we
> > left. I believe that we can profit from the common
> effort, but it should
> > happen in a constructive way.
> >
> > Adrian
> >
> >
>
> Keith, i understand your rightfull indignation.
> But i personally feel, that people who making fixes to
> external
> packages having no intent on keeping them private.
> It comes simply from different development process they
> involved in,
> and our common laziness to do something in addition (like
> ANN the fix)
> to what possibly be done to fix some annoying issue.
>
> I seen multiple 'twas already fixed in XYZ' in this
> mailing list. And
> XYZ is not always =='Pharo' :)
> I think that such message could serve as a signal for
> backporting/reintegration but not as a signal to bash
> people :)
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.

Adding to my views about current release, is not time to think we doing the wrong thing ?

We don't have a 3.11 image.
We don't have a process as we have earlier.
1 a bug or fix is summit to Mantis
2 some add his review , saying the particular fix or enh is good and should included in the image
3 the people running the release try the fix, run the relevant test
4 a nnnnImprovingFoo.cs go to updates folder
5 user press a button and have his 3.11Squeak.nnnn.image

For packages, we don't should reinvent the fire.
Exist some called Monticello 2 and all should help to being the only accepted way .

Universes and SqueakMap should integrate, Installer should be put to a deserved rest.

CodeLoader exist in the image from 1999 and with a few changes do the load of external things.

A new SqueakSource should be run by Aida , if Aida people is ready for the challenge.

This time, not only .mcz could be put for each package.

The acepted formats should be .pr, .morph, .mcz , .obj, etc

Mientras esto no se entienda ...
As long this don't be understand...

Edgar



      Yahoo! Cocina
Recetas prácticas y comida saludable
http://ar.mujer.yahoo.com/cocina/


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: SqueakMap Status?

stephane ducasse
In reply to this post by Adrian Lienhard
+1

>
>> My complaint against pharo is that while the rest of the squeak
>> community has been trying to modularize the image and treat more and
>> more modules as external loadable packages. The pharo team goes  
>> back 3
>> (?) years and ignores anything done in said external projects in the
>
> As a side note, Keith, I'm slightly getting annoyed being criticized  
> over again for what we do wrong in your opinion. To do it our own  
> way without conflicting with the Squeak way of doing (or not doing)  
> things, is why we left. I believe that we can profit from the common  
> effort, but it should happen in a constructive way.

It would be nice that you stop to systematically bashing us.
Why don't you the same with Etoys40, scratch, Croquet, opensophie?

Stef

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: SqueakMap Status?

keith1y
stephane ducasse wrote:

> +1
>>
>>> My complaint against pharo is that while the rest of the squeak
>>> community has been trying to modularize the image and treat more and
>>> more modules as external loadable packages. The pharo team goes back 3
>>> (?) years and ignores anything done in said external projects in the
>>
>> As a side note, Keith, I'm slightly getting annoyed being criticized
>> over again for what we do wrong in your opinion. To do it our own way
>> without conflicting with the Squeak way of doing (or not doing)
>> things, is why we left. I believe that we can profit from the common
>> effort, but it should happen in a constructive way.
>
> It would be nice that you stop to systematically bashing us.
> Why don't you the same with Etoys40, scratch, Croquet, opensophie?
>
> Stef
Because as far as I know these projects haven't started forking MC again.

Keith