Squeak-dev June 2008

squeak-dev@lists.squeakfoundation.org

130 participants
143 discussions

Perl is to CPAN as Squeak is to (what)?
by merlyn＠stonehenge.com 28 Jun '08

28 Jun '08

Since I promised the folks in #squeak I would start this thread... It's been my observation for quite a while that Squeak is missing the equivalent of what Perl has in the CPAN. First, let me describe the CPAN: Anyone can get a CPAN ID for free. Once they have a CPAN ID, they upload packages to a central server, which are then indexed and replicated to 500+ places worldwide, usually within an hour. A package has a name and a version number. Version numbers are floating point numbers, with "larger = better". If the version number contains an underscore, it's considered "better, but only beta" and not automatically offered as an upgrade (see below). In general, package names are *not* registered, meaning that if I upload Foo-3.4, and you upload Foo-3.5, users around the world will be asked if they want to upgrade my package with yours. By default, this allows cooperating team members to upgrade new releases of a cooperative project, as long as they work together on the version numbers. This also allows the long-gone-developer's code to be updated in-absentia. Although this has the possibility for abuse, in the 15 years of the CPAN it has only been abused a few times, and the CPAN gods can quickly remedy the situation. For more managed care, a package name or prefix can be *registered*, which means only a small group of individuals can upload things in that prefix. Again, this is rare, but solves the wildcard issue. If a package is abandoned, the CPAN gods can transfer the registration or deregister it. Any CPAN package can declare that it is dependent on another CPAN package, or even particular versions of core-installed packages. The CPAN installer can be told to automatically or manually install all dependencies (or even ignore them, but that's rarely wise). Speaking of which, the core Perl distro has had a CPAN installer for many years (CPAN.pm), and even a newer one (CPANPLUS.pm) has been included in recent releases. As long as the CPAN index can be read, and the packages downloaded, anyone can write additional CPAN installers too, but they probably won't go into the core. As a result of the above rules: * CPAN installation is easy * CPAN publishing is easy * The CPAN is vital and thriving - see search.cpan.org/recent Notice about 50 uploads a *day*. And everything *works* in an automated way, except for the "CPAN gods" exceptions listed above. Now. Squeak has been around only half as long as Perl. But that's about how long Perl was around before we came up with the CPAN, so it's about time Squeak had the same thing, I think. Here's what I know (and I could be wrong): Squeakmap - *everything* is "registered", so cooperation is hard Squeaksource - no index is made, so you have to find things yourself Universes - like Squeakmap Sake/Packages - single point of update, making publishing hard And except for Squeakmap, there's none of these that have been in all of the recent Squeak releases for installation, so we have a bootstrapping problem. Even installing Universes is hard from Squeakmap. :) And all of these systems are missing dependency and automatic upgrade management. Can we discuss something like the CPAN for Squeak? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

15 24

Squeak Package Management
by Matthew Fulmer 28 Jun '08

28 Jun '08

Hi all. A discussion started on IRC about how difficult it can be to install packages in Squeak, and about how confusing the current situation can look to a newcomer. All of our solutions seem to have problems: SqueakMap: Packages are out-of-date, because the security model does not allow anyone to maintain the package; also, there are no dependencies Universes addressed the dependency issue, but still does not allow widely distributed maintenance of the packages. So far, it is kept mostly up-to-date, due to a few motivated individuals. Sake/Packages is an attempt to address both of the above concerns. It as yet has no UI. Unlike in SM or Universes, the entire distribution is versioned as a whole, rather than the individual packages, so editing one package means making a new distribution version. This makes it easy to specify exactly what version of the database your image is up-to-date with, but does not scale if there are many contributions. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

9 10

Monticello Version Numbers (minor update)
by Keith Hodges 28 Jun '08

28 Jun '08

Many moons ago, it was requested that Monticello allow GUIDs as version numbers... this support was added together with support for conventional 1.0.12b style version numbering in MC1.5 (in theory). However the theory turned out to be not good enough for some folks (they know who they are) Matthew and I spent a couple of hours reworking the version number support in MC1.5 and this has resulted in cleaner, better code... so we are all happy now. (in theory) The net result is that the following is now supported... In addition to the standard.... PackageName-kph.1.mcz we can now have PackageName-kph.1.2.13beta.mcz or PackageName-kph.1.2beta.14.mcz and also.... PackageName-my.very.silly.author.initials.which.stupidly.include.the.delimiter.1.0.3.4beta.mcz But what of GUID support.... well this turned out to be fairly impractical, due to the fact that GUIDs contain a lot of redundant information and dont sort nicely. i.e. you get you packages appearing in a random order in the repo. So instead I defined a timestamp based UID which should do the job. The UID is assembled as - date.time.count So if you happen to save a version named like so... MC will see the timestamp and will save subsequent versions with a new timestamp and updated count. The basic UID package name is like so... PackageName-kph.20080628.054558001.2.mcz However this can be combined with a proper version number (of any length) PackageName-kph.10.5.3beta.20080628.054558001.2.mcz Ok so its not going to be perfect, but I think it should be good enough, since there is a proper GUID in the version info anyway if there ever was a UID clash. best regards Keith

2 2

Does anyone use Monticello Configurations in 3.9 or 3.10?
by Danie Roux 28 Jun '08

28 Jun '08

Dear list, I've been trying to get Monticello Configurations to work, ideally in a 3.9 based image. I would be very interested to hear from anyone using it successfully in a 3.9 or 3.10 image. I take these steps: - Start with a new Squeak3.9.1-final-7075 image. - Open up a Monticello Configurations from the menu - Add Balloon-ar.13 - Add repository http://source.squeakfoundation.org/Balloon from the list I can now hit update (from repositories), and get Balloon-ar.14. Cool, as expected. - I click Store, and save it as test.mcm in my local package-cache repository. - I now close everything and open a Monticello Browser again. - I open my package-cache repository - Select "test" project - Select test.mcm on the right pane and I get a walkback: "My subclass should have overridden #loadVersionInfo" -- Danie Roux *shuffle* Adore Unix - http://danieroux.com

6 9

Monticello Version Numbers
by Keith Hodges 28 Jun '08

28 Jun '08

Many moons ago, it was requested that Monticello allow GUIDs as version numbers... this support was added together with support for conventional 1.0.12b style version numbering in MC1.5 (in theory). However the theory turned out to be not good enough for some folks (they know who they are) Matthew and I spent a couple of hours reworking the version number support in MC1.5 and this has resulted in cleaner, better code... so we are all happy now. (in theory) The net result is that the following is now supported... In addition to the standard.... PackageName-kph.1.mcz we can now have PackageName-kph.1.2.13beta.mcz or PackageName-kph.1.2beta.14.mcz and also.... PackageName-my.very.silly.author.initials.which.stupidly.include.the.delimiter.1.0.3.4beta.mcz But what of GUID support.... well this turned out to be fairly impractical, due to the fact that GUIDs contain a lot of redundant information and dont sort nicely. i.e. you get you packages appearing in a random order in the repo. So instead I defined a timestamp based UID which should do the job. The UID is assembled as - date.time.count So if you happen to save a version named like so... MC will see the timestamp and will save subsequent versions with a new timestamp and updated count. The basic UID package name is like so... PackageName-kph.20080628.054558.2.mcz However this can be combined with a proper version number (of any length) PackageName-kph.10.5.3beta.20080628.054558.2.mcz Ok so its not going to be perfect, but I think it should be good enough, since there is a proper GUID in the version info anyway if there ever was a UID clash. best regards Keith

1 0

Help Installing Installer
by Derrell Piper 28 Jun '08

28 Jun '08

Newbie alert. Using a fresh 3.10.2 image (Squeak3.10.2-7179-basic) and instructions from here: http://wiki.squeak.org/squeak/5897 Workspace: (HTTPSocket httpGet: 'installer.pbwiki.com/f/Installer.st') fileIn. ...after "Reading Stream" results in a Transcript of: (user is Undeclared) (password is Undeclared) (user is Undeclared) (password is Undeclared) Installer (Bindings is Undeclared) (ReleaseBuilderFor3dot10 is Undeclared) (ReleaseBuilderFor3dot10 is Undeclared) (ReleaseBuilderFor3dot10 is Undeclared) (MCCsReader is Undeclared) (user is Undeclared) (user is Undeclared) Next I tried downloading Installer.st by hand and just doing a fileIn with: (FileStream readOnlyFileNamed: 'Installer.st') fileIn. ...and that wins me about the same failure, more or less. Can someone clue me in how to get this in a fresh image (or else point me towards a better starting point). Thanks!

2 1

Monticello version numbers
by Keith Hodges 27 Jun '08

27 Jun '08

Many do not know that Monticello 1.5 supports more complicated/natural version numbering schemes. Versions can be... 100 1.0.20 b523057e.606b.464b (abbreviated UUID with: $- replaced by $.) so.... this means... PLEASE DONT USE $. in your author initials when saving MC packages!!!!!! this has been a public service announcement Keith

2 1

Re: [squeak-dev] Re: Perl is to CPAN as Squeak is to (what)?
by Benoit St-Jean 27 Jun '08

27 Jun '08

If I might add to the discussion, we should ask ourselves what is missing to the Cincom repository to become as useful/friendly/whatever as CPAN? What are the pros and cons of the Cincom repository and Squeakmap as compared to CPAN ? I don't think we're that far from a "Smalltalkish" CPAN. I also think we definitely need such a mechanism. ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blog: lamneth.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein)

1 0

[JSqueak] Unofficial git repository available
by Victor Rodriguez 27 Jun '08

27 Jun '08

Hello all, I changed the indenting style of the source code to follow a more traditional Java style. This seemed like a good excuse for myself to learn to use git, so I have created a repository at github to share these changes. The repository is at http://github.com/victorr/jsqueak/tree. github has many nice features, you can browse source code, download a tar file with the latest sources, view commit history, etc. To clone the repository, use the command git clone git://github.com/victorr/jsqueak.git I'm new to git myself, but google turns out plenty of tutorials (and I'm sure Randal Schwartz can recommend a good one). There's even a gitcasts.com site (thanks melriffe!), here is a link to the introductory screencast: http://gitcasts.com/posts/setup-initialization-and-cloning I'll continue "cleaning up" the code. Feel free to let me know of your own improvements. I have not yet included my patches (submitted to jsqueakinterest) that make the return, alt and control keys work. Best Regards, Victor Rodriguez.

3 3

[JOB] Permanent position @ Douai
by Noury Bouraqadi 27 Jun '08

27 Jun '08

Dear Smalltalkers, My lab is looking for a french speaking PhD http://vst.ensm-douai.fr/noury/18#2008-06-24 Regards, Noury ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------

3 4

← Newer
1
2
3
4
5
6
7
8
...
15
Older →

Jump to page: