Squeakfoundation February 2003

squeakfoundation@lists.squeakfoundation.org

22 participants
36 discussions

Re: [Squeakfoundation]A bit about SM1.1 and dependencies
by Daniel Vainsencher 12 Feb '03

12 Feb '03

[I claim resources/links not needed for depedencies] =?ISO-8859-1?Q?G=F6ran_Hultgren?= <goran.hultgren(a)bluefish.se> wrote: > Well, I am having a hard time seeing where we should record our dependencies if > we don't have Resources. They *are* needed. At least given my plan. :-) Ok, just to show what I mean. Suppose I make a package type that holds a single method that goes something like ^#((RBModel 1.09) (RBGUI 1.06) (RBTests 1.05)) Then I write a service that loads this kind of package, and does packagesList collect: [:packagePair | SMSqueakMap loadPackage: packagePair first version: packagePair second]. Or maybe something a little more complicated, but you can see where I'm going... I don't need much more support. > Sure. The cache thing is just something that annoys me - it is simply put > incredibly stupid right now. Hey, I'm just one voice here.. and not even offering any cash, so... ;-) > Yes, but the modifying API is coupled with managing distributed change. At least > as I have planned it. Otherwise the API would need to "call" the master server > using some for of RPC yadda, yadda... Ah, I see what you mean. I'd thought you were going to implement that RPC anyway, since the image do need to communicate anyhow. > > I have interest, and would be glad to help flesh out the services along > > the lines above. Whether that'd be as a part of SM for you to integrate > > or as a separate package - as you wish. It'll be very easy to specify > > that the UIs require both SM and SM Services after we get dependencies, > > so I don't see a problem... :-) > > I will try to get it out this weekend and perhaps you could take over the > services part. Cool. Daniel

2 1

Re: [Squeakfoundation]A bit about SM1.1 and dependencies
by Daniel Vainsencher 11 Feb '03

11 Feb '03

goran.hultgren(a)bluefish.se wrote: > Well, given my plan of us being able to register "package > configurations" associated with a package release *as* a Resource - it > is needed. And Links too of course - Resources of course need to be > linked to something > > But don't get scared by this - these two mechanisms are very simple and > I have that stuff more or less implemented including package releases. Not scared, and I don't doubt it's simple, just said it's not necessary. You know, Simplest thing that could possibly work, You ain't gonna need it, and all that crap... ;-) > Things I *am* waiting with: > - The ability to make modifications to the map in a distributed fashion. > - And thus also: The API for modifying the map. > > And two more things I *do* want to include: > - A sensible cache instead of the braindead scheme right now. But this > is also simple. > - The new service architecture instead of the current "install or > download" choice. Distributed modification and cache are, IMO, easily delayed. We don't, AFAICT, have a real performance/reliability problem that would make these essential (though there might be other reasons for them I'm not aware of...). OTOH, services and API for modifying would be really nice. Services are important for making use of the dependencies, by letting the category of the package indicate that it's a multiple, and modifing would allow much convinience to developers. On the gripping hand, the services architechture could actually also not be part of the SM catalog - one might say it's an extension that can be either used or ignored by the UIs, and that the only modification needed to SM is to break off the existing install and such into such services. > Note that the package configurations and corresponding dependency engine > I have been blabbering about is *not* included here - that is meant to > come as an addon later. And anyone could start coding that up right now > I think. I wouldn't know how because I don't know what the API for downloading a specific package version will look like... but I might as soon as I do. > Well, I am not sure what is the best way forward - I have SM1.1 on my > drive and it does have package releases, quite a lot of refactoring > done, links and resources in the model and the new service architecture > halfbaked. I have a sketch in my head for a better cache model, need to > whip through the web UIs so that we can register releases, resource etc > - but that is pretty easy coding. > > Anyway, I will try to throw in a bunch of hours in this the coming week > - at least enough to post a developer snapshot so that anyone could help > me - if there is interest. My current fixed price job is pressing me > pretty hard. It will get easier in late feb, early march. I have interest, and would be glad to help flesh out the services along the lines above. Whether that'd be as a part of SM for you to integrate or as a separate package - as you wish. It'll be very easy to specify that the UIs require both SM and SM Services after we get dependencies, so I don't see a problem... :-) Daniel Vainsencher

2 1

Re: [Squeakfoundation]A bit about SM1.1 and dependencies
by Daniel Vainsencher 09 Feb '03

09 Feb '03

Hi Goran, everyone. Since you mentioned it... I know you have a paying job, which takes understandable precedence, and delays the SM1.1 release. I would ask that you please consider doing a work-split, that is, reprioritize the features, decide which ones have to be in then next release, formally delay the others, such that the next release is a as soon as possible. Obviously, what I'm really getting at, is that we really need very little to be able to build functional depedencies mechanisms. An SM release that does nothing else but that would be VERY valuable to the Squeak community. Just to remind those of us that aren't thinking about this all the time why: 1. It would enable publishers of complex packages to split them, making the package more modular, and yet keep the ease of installation single packages enjoy. 2. It would enable a process to begin where people make up their favorite configurations, and share them. This would be a big step towards making distribution of images easier to democratize, and less a bottleneck. AFAICT, the only additional mechanism required to support dependencies is package/card versioning. Links and resources would be nice to have, but they aren't stopping us from implementing dependencies. I know any changes in a release plan requires shifting some things around, but I think in this case it is quite worthwhile... I understand that your time is still limited, I'd just like to "get" dependencies as soon as possible. It might help if we have some sort of initial release and can help test/debug. In this view, the incremental addition of prototypical services to SM 1.0 might be easier to handle than work on a non-production SM1.1. Daniel Vainsencher

2 1

One more Welcome window addition
by Doug Way 09 Feb '03

09 Feb '03

While waiting for the interim VMs to be built for 3.4, I thought I would suggest one more small addition to the 3.4 Welcome window. (btw, are there any remaining issues with the content of the 3.4 VMs?) Anyway, it seems like the Welcome window really ought to mention the minnow swiki somewhere specifically as a resource. So something like this could be tacked on near the end. (maybe before The Squeak License section) ---------------------------- Further Documentation The Squeak Swiki at Georgia Tech is currently the primary source of online documentation and community information regarding Squeak. It contains a FAQ, tutorials, and much more. Visit it at http://minnow.cc.gatech.edu/squeak.

4 3

The update stream, 3.4, 3.5, harvesting
by Doug Way 05 Feb '03

05 Feb '03

Hello all. Several items... Just to keep everyone posted, Scott has given me instructions on how to add updates to the Squeak update stream. So, SqC has "handed over the keys" so to speak, and I am now the official maintainer of the update stream, more or less. Of course, my manual handling of the update stream is somewhat temporary... the idea being that with the upcoming harvesting tool, the addition of items to the update stream will become more automated, with a process known to the community. (Although it will probably always require some manual tweaking on occasion.) I'm about to start working on this harvesting tool (based on SqueakMap 1.05), but it's hard to say when it would be ready to use. I'll shoot for having something ready within a month or so. (with input from this list, of course) But in the meantime, we probably shouldn't let 3.5alpha stagnate, so I'm going to add some harvesting tables of recent submissions to the ol' superswiki pages one more time. The harvesters/guides/SqC can then review items for inclusion in 3.5alpha, as was the process several months ago. I'll post again as soon as I've added these tables. Which brings up a question: Who in general should be able to review/approve items to be harvested? I would say the current harvesters + the guides + the SqC folks would be a good starting point. But there are other qualified Squeakers out there, too. For now, if someone else really wants to volunteer to help with harvesting, I could add them to the list of harvesters, and they can help with the swiki tables. However, once the better harvesting tool is in place, harvesting should be somewhat easier (editing the swiki tables is a bit of a pain), so that might be a better time to get more volunteers. (And yes, eventually, once the image is split up into packages, we want to have different people in charge of approving what goes into each package, and maybe have an update stream for each package, if desired. But the first version of the harvesting tool probably won't be package-specific yet.) Aside from harvesting, there are more general plans which need to be discussed for 3.5. Such as how much of the image should we try to break off into packages, which larger enhancements should be considered, what would be an approximate release date, etc. Someone other than me should lead this discussion, I have enough to do myself. ;-) Daniel led some discussion on this in the past, so perhaps he could continue. In other news, the 3.4gammaOne image has been out there now for over a week. There haven't been any major bugs reported with it, so I'm thinking that we could probably make this the 3.4 final image in a few days, and then release it on squeak.org. (Of course, a lack of feedback may also mean that not many folks have tested it. I would encourage everyone to at least give it a quick test. The differences in the image itself are relatively minor compared with an image updated from 3.4beta, though... e.g. the contents of the welcome windows have changed a bit. See ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/3.4gamma/ ) As we approach the 3.4 final release, we'll want to make sure a few things are in order: * Make sure that the VM's for various platforms (Mac & Windows at least) are decided upon as the 3.4 VM's to be included in the bundles on squeak.org. Bruce O'Neel would then put the bundles together and update the squeak.org download page accordingly, when we are ready to release. * Make sure the 3.4 release is announced in all the right places, as described on the "External Relations" SqF swiki page. Cees de Groot is in charge of this. * Anything else? Ok, I think that's it for now. - Doug

3 5

A bit about SM1.1 and dependencies
by goran.hultgren＠bluefish.se 05 Feb '03

05 Feb '03

Hi! I sent this email to Avi, Ned and Chris Muller as a response to Chris wonderings but then I thought I could post it here too. If you are interested in dependencies this might be interesting to read. It is about my plans for SM1.1 and beyond. regards, Göran ----- Hi Chris and all! Chris Muller <afunkyobject(a)yahoo.com> wrote: > --- Ned Konz <ned(a)bike-nomad.com> wrote: > > Note that the prerequisite handling in SARs is only > > temporary, until SqueakMap gets dependency handling. > > Hmm.. I'm a bit confused by this. It seems to me that dependency definitions > would be something more at the Package level. Thinking out loud - Packages It typically is in for example RPM or deb. But that is not my current plan. :-) Well, "not really" anyway. As you will see below default information could redundantly be included in the SAR, but it should still be available separately. > have additional resources, readme's, change histories and dependencies. Yes. > SqueakMap, on the other hand, is a cataloging system. It knows *where* > packages are, *who* maintains them and, for my convenience, obtains the stream, > local or network, necessary for SarInstaller to do the installation work. Right. > So if prerequisite handling is removed from PackageInfo's and SAR utilities, > then does that mean the only packages that'll be able to have prerequisites are > ones cataloged in SqueakMap? Eh, no. It could be included inside. But in order to have an engine be able to reason about dependencies without having to download the packages themselves this information should *also* be available separately. An URL will be sufficient. > Please educate me.. Ok. :-) Unfortunately I haven't written down my plan for the upcoming SM in a detailed manner - so it is not "your fault" not knowing about this. :-) I really should do this. Perhaps I will find some time for that later this week. Anyway, here goes: In regard to dependencies (there are other things coming in SM1.1 too, but that is of less importance here) I am in SM1.1 adding these mechanisms: 1. Package releases. In SM1.1 you will first register a package much like you do today, but much of the information will instead be entered for a PackageRelease that the Package owns. So the url, the version info, the version name etc etc will be attributes of PackageRelease instead of Package. This is just simply necessary for us to be able to handle dependencies since they must be between specific releases of packages and not just the packages. 2. Links. All things that can be registered on SM1.1 will have a "link list" to other things registered at SM. This way a Package can link to another Package typically just to give guidance or whatever. But it is also a crucial capability for handling dependencies - see below. 2. Resource. This is a new beast in SM1.1. It is simply a digital resource given by a URL that is not a Package or a PackageRelease. So Resource will be the "kitchen sink" type that we can use for whatever we like. This way we can create new kinds of "additional info" and attach them (by using Links) to Packages or PackageReleases. Ok. This is actually the only ground work I aim for in SM1.1. But hey, you say. Where are the dependencies? Aha! SM doesn't really know about them! BUT... we will be able to create dependency information and "attach" that information to the PackageReleases using the Link/Resource mechanism described above. Given this here is my plan for dependencies that I discussed at length at OOPSLA with Roel Wuyts, Ned Konz, Doug Way and many more - especially Daniel Vainsencher on email: On SM anyone can register a "Package Configuration" as a Resource. This is simply a list of specific PackageReleases of other prereq packages that a given PackageRelease of package X works with. This resource is then associated with the PackageRelease in question. Typically the maintainer of package X would register at least one such "working configuration". Note that the dependency information is NOT inside the package. There is nothing stopping the package maintainer of having the same "default" configuration inside the SAR of course in order to make the SAR file a bit more "self sufficient". But the main point here is that the maintainer of package X is not the ONLY one that can register package configurations for package X. If I find out that, hey - Magma works just as well together with package Y version 1.13 as a replacement for package Z 3.4 then I can register that configuration as a viable alternative. Note that the registrant is visible so perhaps nobody trusts me in regards to Magma, in that case they would pick Chris suggested configuration instead. Anyway - now the field is open. We can now construct a simple textual format (I would simply use Smalltalk) for these "Package Configurations" and then someone can build a really cool dependency resolution engine to answer the question - "Ok, I want the newest Seaside, Magm, YAXO and SIXX that work nicely together." It would then build a dependency graph and do all sorts of smart reasoning and hopefully come up with a nice list of Package Releases including all non conflicting prerequisite packages. The cool part of this plan is that we have maximum flexibility, SM doesn't really know anything about dependencies (as it should not), different models for describing dependencies and different resolution engines could be tested and of course - the change in known dependencies does NOT force a new package release! By the way - the SM1.1 servers should be able to "mirror" the resources registered simply by downloading the URLs given to the server. I hope this helped a bit. regards, Göran PS. Perhaps I should post this somewhere...

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