Squeakfoundation May 2003

squeakfoundation@lists.squeakfoundation.org

18 participants
26 discussions

SM1.1
by goran.krampe＠bluefish.se 28 May '03

28 May '03

By the way, forgot to mention that Brian Rice has stepped up to the plate and is going to help me out with SM1.1. He will probably take on the "package cache" part first. regards, Göran

2 1

Re: [Squeakfoundation]Monthly report...
by Daniel Vainsencher 27 May '03

27 May '03

You did it well previously... Daniel goran.krampe(a)bluefish.se wrote: > Hi fellow Guides! > > Anyone else interested in writing the monthly report for april-may? > The last one was on 7th of april. Pressure is mounting. :-) > > regards, Göran > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

Monthly report...
by goran.krampe＠bluefish.se 27 May '03

27 May '03

Hi fellow Guides! Anyone else interested in writing the monthly report for april-may? The last one was on 7th of april. Pressure is mounting. :-) regards, Göran

1 0

Re: [Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff)
by Daniel Vainsencher 25 May '03

25 May '03

[Alternative browser] Yes, that sounds cool. I think one good long term goal for such a browser would be that it is possible to plug into it all of the functionality of the RB, without having to subclass it. This forces you to make quite a lot of the hooks that are needed to plug in other stuff that should be in the browser, like package management, analysis tools, and so forth. Please let us know your plans. Daniel Stephane Ducasse <ducasse(a)iam.unibe.ch> wrote: > Hi all, > > Just a simple point about packages. I discussed a lot with Avi and > I think that while DVS is a simple start the future is to have real > package and not only > hack around the categories. Avi agrees on that. I discussed recently > also with joseph > and he said that Ginsu is free (I should send him a license). > What would be good is to have a group of people discussing/cooperating > to create this asset. > May be this is already in place (sorry for not knowing it). > > So there is still a gap between having definitions in the image (like > in Ginsu) and only > definitions in the exchange files but having definitions is important. > We should have a way > to see in the file that we declare a new Class, Pool what ever. We > could have then multiple > run-times if people want and we could load code without installing it. > So imagine what we could > do. > > Having support for real package in the image is not really difficult > but the browser is > so much a pain that it will hamper any move. Nathanael and alex for the > traits and the > classboxes had to fix, patch, this gory browser, Markus also for his > ideas. What we are > planning to do here is to build our own browser where they could plug > what they need for > their research. > I will check what is the plan but it should be still in our current > plans. First we want > to fix the core (compiler, changes notification, classOrganization). > However, this means > that we could take into account that other entities such as packages > could be used there too. > > Stef > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Re: [Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff)
by Daniel Vainsencher 25 May '03

25 May '03

goran.krampe(a)bluefish.se wrote: > Or putting it another way - making a competitor to SM or DVS would be in > many ways counterproductive since these tools in some ways work their > magic by turning into de facto standards for the community. Much better > to cooperate on them. :-) I disagree in general - alternative solutions to the problem DVS solves, for example, don't hurt the community, because their functionality is more important than the synergy of sharing the same format. This is because the different formats do not add significant issues, because SM makes hides them by abstracting the install option. So a "better DVS" (just an example) is a good thing. SM specifically, OTOH, derives most of it's benefits from the network effect (everyone is putting his package in one place, and everyone looks for code in one place), and thus two incompatible catalogs would probably be worth less than just one, functionality almost not-withstanding. So SM competitors would be hard pressed to provide real value. > And that is btw one of the reasons I really want opinions on SM. Since a > few important issues were reaised on the list recently I am in the > process of writing down how SM1.1 will work on: It's been a couple of months since the last time I said this, so I consider it borderline-polite-nagging ;-). IMO, nothing matters as much as that you release something as soon as possible that supports package releases. - Details of distribution of the DB is unimportant. - UUIDs vs. names is unimportant. - Caching is unimportant. Why? because releases in SM allow dependencies to be handled in various intelligent ways, which would save people like Stephan from inventing their own schemes that are non-scalable simply because versions are not supported. Such a release would let loose the next "avalanche" of progress in the package handling aspects of Squeak. Also, while 3.6 release is pretty far away, we do need to start seeing how we actually handle releases in and after it, and to do that we need SM 1.1. So please do whatever you can to release asap, we need SM1.1 now! :-) Daniel

4 3

Re: [Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff)
by Daniel Vainsencher 23 May '03

23 May '03

goran.krampe(a)bluefish.se wrote: > And SMPackage again - is a "public" package used by others. > > So my conclusion is that both concepts are valid and disjoint but we > should try to NOT introduce any *more* of these "kinda-module-thingies" > into the Squeak world. :-) On the contrary - it isn't that we have too many "kinda module thingies", it is that we (ab)use the word "module" to describe an imaginary construct that's supposed to solve too many different problems. Here's one way to cut it - * Unit of code reuse (which brings with it issues of understanding changemanagement) * Unit of program deployment (including issues of mixing different versions of modules) * As used by some people, may also include Namespaces, distributed transactions, partitioning of non-code objects... To the extent that we're clear about which design is meant to solve what problems, constructing the overall solution from a few more pieces won't hurt too much, and will give us flexibility (DVS today, Monticello tommorrow). Daniel

2 1

SqueakMap in the image (was Re: Incorporating removals & KCP stuff)
by Daniel Vainsencher 23 May '03

23 May '03

[Add SM into 3.6 using update stream to do package installation] Sounds good to me. BTW, you mentioned the current update stream seems to be leading to Minimal. I think that at least for 3.6 it should be leading us towards Basic. [packages for Basic, like DVS, SAR] IMO Basic should include PackageInfo, because it is a useful unit of filing stuff in and out that (a very lightweight replacement for one function changesets get abused for). DVS and SAR I am less sure about. In particular, DVS seems like it might be temporary, in the sense that the Monticello stuff will replace it as infrastructure. OTOH, maybe I'm just faliing to realize the benefits of how easy it is to issue an update that installs/uninstalls well-packaged stuff. Which, BTW, we need to define and start paying attention to - stuff that doesn't uninstall cleanly is badly packaged, and should not be included in Basic. Daniel goran.krampe(a)bluefish.se wrote: > Ok, back to the issue at hand: SM. And IMHO DVS, SAR and Package Loader. > And perhaps one or two more I am forgetting right now. My reasoning > above may sound like I don't want to introduce SM into the image - but > in fact I do. :-) But not as "just another changeset". I want them > *installed as packages*. > > What this means in practice is the following: > > We should issue updates through the update stream that installs these > puppies using SM! The SM bootstrap changeset (the one that you get if > you do the "Open packag loader") makes it look like SM itself was > installed through SM (though of course it wasn't). > > I know that Scott Wallace earlier argumented to put SM into the image - > and I strongly objected. I still object to simply "filing it in" just > like *any changeset*. > > In short - we can issue an update that simply runs the bootstrap. We can > keep the bootstrap code in place for a while. > > > (Then there's Andreas' new stuff which supports update streams on > > individual packages, which I haven't looked at closely yet... I'm not > > sure if that would make a big difference for this particular case.) > > I don't think so. I may try it out but I can't see how they have > anything to do with us just yet. That package could OTOH be a candidate > for Basic of course - just like DVS, SAR etc. > > Phew - so what do you all say? Does my analysis above sound reasonable? > I find it strange that it seems so hard to define what things are - we > really are creatures of habit. Hard to let go! :-) > > > - Doug Way > > regards, Göran > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

6 9

Re: [Squeakfoundation]Incorporating removals & KCP stuff
by Daniel Vainsencher 21 May '03

21 May '03

Once and only once - code that affects packages should be distributed in no other way than by being in the package. This important for two reasons - 1. The package owner really should be the only one that decides about code that goes in his package. 2. If packages depend on active Harvesting of all their stuff, that slows down the maintainance of base itself, and the evolution of all packages. The opposite of what we want. Part of this is removing concerns from the Harvesters. The maximum they should worry about packages is that when packages are updated that affect a certain image brand (base, full), the maintainer of the image should have the option of making the package update itself. Of course, this can be done easily if SM in the image, which is not a problem for Base and Full. Daniel John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > > On Thursday, May 8, 2003, at 04:22 AM, goran.hultgren(a)bluefish.se > wrote: > > > > > > But the update stream is only used for code not in packages. It can > > only > > "expect" an image that doesn't have SM. Aargh. My head spins. > > > > Need to think more... > > Well any way to change the update stream logic to consider packages. > Then the update stream > could update packages if they are installed, otherwise they get > skipped. Later if you load said package > and rerun the update, it might go back and re-apply updates as needed > based on which packages > are now loaded? > > -- > ======================================================================== > === > John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > ======================================================================== > === > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

3 2

Testing Coordinator volunteer
by Doug Way 19 May '03

19 May '03

Since Marcus Denker is doing a fair amount of work with maintaining the test-related packages for Squeak (SUnit, BaseImage Tests, and some other package tests), I went ahead and added him on the Volunteer Roles page as the "Testing Coordinator". (I checked with Marcus beforehand.) In the future, he could help coordinate automated testing, whenever we get to that stage... http://swiki.squeakfoundation.org/squeakfoundation/88 - Doug Way

2 1

Call for more harvesters!
by Doug Way 16 May '03

16 May '03

(thought this was worth cross-posting to the SqF list too) In order to make the harvesting process more lively, we'd like to have about 5 more Harvesting Volunteers. Responders should be quite experienced with Squeak, should be familiar with and willing to apply the rules as published on the Swiki, and have an intention to harvest roughly 5 change sets a month (no sworn oaths needed - but we are trying to keep up with the harvesting load). Candidates should reply with evaluations of their first 5 intended changesets (can be [FIX]es or [ENH]ancements), just to get started, and to make sure we're in sync, since some aspects of the process are new. Changeset evaluations don't need to be meticulously detailed... just good enough for an external review [er]. Please reply to me directly, and I'll discuss with the other harvesters. Basically, if your 5 changeset reviews look reasonable, you'll probably be accepted... unless we get way too many volunteers, which is unlikely. :-) http://swiki.squeakfoundation.org/squeakfoundation/45 http://minnow.cc.gatech.edu/squeak/3152 - Doug Way dway(a)riskmetrics.com

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Squeakfoundation May 2003