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 |
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). > http://code.google.com/p/pharo/issues/detail?id=193 http://bugs.squeak.org/view.php?id=7201 ? Norbert |
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 |
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 |
> 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 > > > > |
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 |
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. |
--- 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/ |
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 |
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 Keith |
Free forum by Nabble | Edit this page |