Whilst looking into ways to script loading packages I noticed a few items we could probably clean up to benefit the next release
a) the class doc is currently at http://installer.pbwiki.com/Installer and it is quite old. That doesn't mean it is bad per se but it does mean it likely needs some updates and corrections. There are some 'interesting' related scripts etc that might be useful to look into and either update or remove. I think a lot are completely out of date now. Note that there is/was a complaint about not using a swiki page (which I'd prefer for less-obscure) because of 'lack of real urls". No idea. Is that actually a problem now?
b) quite a few of the class side methods providing short cuts to repositories are now invalid- cobalt (no server) goran (seems not to be a repo any more, lets me into what looks like some fairly private directories) impara (no server) keith (no apparent server, also see this rather cool - https://en.wikipedia.org/wiki/Warrosquyoake_Shire page) lukas (seems to be very out of date?) saltypickle (no domain - but it is for sale!) sophie (no domain - also for sale - whee!) ssMirror (no server) swasource (seems to have a squeaksource3 service but nothing in it?) wiresong (just set as a webdav server?)
I propose copying most of the pbwiki description of the use of Installer to the class method and removing the above list of locations. Can anyone provide further info on the locations and their status?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: FSRA: Forms Skip and Run-Away
I think it was http://warwick.st no idea how it got to that wikipedia destination.
Keith
On 2019-08-22, at 1:19 PM, Keith keithy@consultant.com wrote:
I think it was http://warwick.st no idea how it got to that wikipedia destination.
Oh the wikipedia page was just a cute thing that came up when searching. But I don't get anything helpful for warwick.st - just "can't find the server warwick.st". Should there be something there?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Error 13: Illegal brain function. Process terminated.
http://warwick.st/udents was from long past era.
Keith
On 2019-08-22, at 7:35 PM, Keith keithy@consultant.com wrote:
http://warwick.st/udents was from long past era.
OK, so not useful any longer.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- His shared libraries aren't installed.
Hi, all.
#swasource is up and running: http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/MetacelloRepository/ :-)
Best, Marcel Am 22.08.2019 22:12:06 schrieb tim Rowledge tim@rowledge.org: Whilst looking into ways to script loading packages I noticed a few items we could probably clean up to benefit the next release
a) the class doc is currently at http://installer.pbwiki.com/Installer and it is quite old. That doesn't mean it is bad per se but it does mean it likely needs some updates and corrections. There are some 'interesting' related scripts etc that might be useful to look into and either update or remove. I think a lot are completely out of date now. Note that there is/was a complaint about not using a swiki page (which I'd prefer for less-obscure) because of 'lack of real urls". No idea. Is that actually a problem now?
b) quite a few of the class side methods providing short cuts to repositories are now invalid- cobalt (no server) goran (seems not to be a repo any more, lets me into what looks like some fairly private directories) impara (no server) keith (no apparent server, also see this rather cool - https://en.wikipedia.org/wiki/Warrosquyoake_Shire page) lukas (seems to be very out of date?) saltypickle (no domain - but it is for sale!) sophie (no domain - also for sale - whee!) ssMirror (no server) swasource (seems to have a squeaksource3 service but nothing in it?) wiresong (just set as a webdav server?)
I propose copying most of the pbwiki description of the use of Installer to the class method and removing the above list of locations. Can anyone provide further info on the locations and their status?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: FSRA: Forms Skip and Run-Away
On 2019-08-22, at 11:15 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi, all.
#swasource is up and running: http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/MetacelloRepository/ :-)
Ok, BUT we seem to have a problem accessing it. In a web browser the link you give works to provide a simple directory listing. In a web browser "http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/MetacelloRepository.ht..." gives an actual useful page. http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource gives plain ss3 homepage `Installer swasource basicView` opens an empty repository browser, which isn't terribly useful.
So, which path is the best one to have in Installer class>>#swasource ?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim egret - apology by email
On 23.08.2019, at 20:32, tim Rowledge tim@rowledge.org wrote:
On 2019-08-22, at 11:15 PM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi, all.
#swasource is up and running: http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/MetacelloRepository/ :-)
Ok, BUT we seem to have a problem accessing it. In a web browser the link you give works to provide a simple directory listing.
That's how Monticello accesses its stuff, directory listings.
In a web browser "http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/MetacelloRepository.ht..." gives an actual useful page.
That's how humans access stuff.
http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource gives plain ss3 homepage
If you want, we can make an account for you and you can start exploring stuff there :)
`Installer swasource basicView` opens an empty repository browser, which isn't terribly useful.
Because it is not a repository, but a SqueakSource, ie, a collection of repositories.
you might want to do
`(Installer swasource project: 'MetacelloRepository') basicView`
So, which path is the best one to have in Installer class>>#swasource ?
The one already there.
Please leave it be, I put it there on purpose.
We had a full list of stuff on the http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/ page but I have no time to ensure everything is up to legal requirements when I display stuff publicly.
The shortcut is there to install MCZ-files, IMHO not for exploration. For Example: The "Metacello Quick Install" project entry features the following code for installation:
Installer swasource project: 'SwaUtilities'; addPackage: 'ConfigurationOfMetacello'; install.
"Bootstrap Metacello Preview, using mcz files (#'previewBootstrap' symbolic version" ((Smalltalk at: #ConfigurationOfMetacello) project version: #'previewBootstrap') load.
Thanks and best regards -Tobias :)
Hi tim
On 22.08.2019, at 22:11, tim Rowledge tim@rowledge.org wrote:
Whilst looking into ways to script loading packages I noticed a few items we could probably clean up to benefit the next release
a) the class doc is currently at http://installer.pbwiki.com/Installer and it is quite old. That doesn't mean it is bad per se but it does mean it likely needs some updates and corrections. There are some 'interesting' related scripts etc that might be useful to look into and either update or remove. I think a lot are completely out of date now. Note that there is/was a complaint about not using a swiki page (which I'd prefer for less-obscure) because of 'lack of real urls". No idea. Is that actually a problem now?
b) quite a few of the class side methods providing short cuts to repositories are now invalid- cobalt (no server) goran (seems not to be a repo any more, lets me into what looks like some fairly private directories) impara (no server) keith (no apparent server, also see this rather cool - https://en.wikipedia.org/wiki/Warrosquyoake_Shire page) lukas (seems to be very out of date?)
essentially frozen, but why would that be invalid? If you want to try Lukas Renggli's stuff, that would be the go-to-location.
saltypickle (no domain - but it is for sale!) sophie (no domain - also for sale - whee!) ssMirror (no server) swasource (seems to have a squeaksource3 service but nothing in it?)
It works if you know what to install. I have removed the ss3 project listing and especially the authors listings, as I am unsure what is admissible under the European Privacy regulations. We use it at HPI primarily for our students' projects, so these must stay private.
However, all the public stuff is still public, just not on the front page.
Currently, that squeaksource hosts over 400 projects.
wiresong (just set as a webdav server?)
This is valid. It's Colin's repository.
I propose copying most of the pbwiki description of the use of Installer to the class method and removing the above list of locations. Can anyone provide further info on the locations and their status?
tim
Best regards -Tobias
On 2019-08-23, at 10:20 AM, Tobias Pape Das.Linux@gmx.de wrote:
Hi tim
lukas (seems to be very out of date?)
essentially frozen, but why would that be invalid? If you want to try Lukas Renggli's stuff, that would be the go-to-location.
True, but is it still interesting enough to warrant a utility link in a system class? And it returns an empty list for Installer lukas basicAvailablePackages I'm not suggesting any of the repositories are junk (aside from the ones simply no longer there) but is they no longer respond to the utilities in the Installer classes then they probably shouldn't be listed therein.
saltypickle (no domain - but it is for sale!) sophie (no domain - also for sale - whee!) ssMirror (no server) swasource (seems to have a squeaksource3 service but nothing in it?)
It works if you know what to install. I have removed the ss3 project listing and especially the authors listings, as I am unsure what is admissible under the European Privacy regulations. We use it at HPI primarily for our students' projects, so these must stay private.
That's fine, though unfortunate since there is likely intersting stuff.
However, all the public stuff is still public, just not on the front page.
Finding a way to get it listed in response to a #basicAvailablePackages etc would be a bit help. How else are we supposed to find them?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Diarrhea of the mouth; constipation of the ideas.
Relating to this, does anyone know if there is any point in keeping the InstallerSake and InstallerUniverse classes around? They're sort-of deprecated but were sort-of deprecated in 2008, which is quite a while ago...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Time to start the War on Errorism before stupidity finally gets us.
On 23.08.2019, at 20:47, tim Rowledge tim@rowledge.org wrote:
Relating to this, does anyone know if there is any point in keeping the InstallerSake and InstallerUniverse classes around? They're sort-of deprecated but were sort-of deprecated in 2008, which is quite a while ago...
I'd say purge it :)
Hi tim
On 23.08.2019, at 20:40, tim Rowledge tim@rowledge.org wrote:
On 2019-08-23, at 10:20 AM, Tobias Pape Das.Linux@gmx.de wrote:
Hi tim
lukas (seems to be very out of date?)
essentially frozen, but why would that be invalid? If you want to try Lukas Renggli's stuff, that would be the go-to-location.
True, but is it still interesting enough to warrant a utility link in a system class? And it returns an empty list for Installer lukas basicAvailablePackages
That's because it isn t a single repository but a collection thereof, just like squeaksource.
If you want to look at his Functional Pattern Matching stuff, do
`(Installer lukas project: 'fpm') basicAvailablePackages`
I'm not suggesting any of the repositories are junk (aside from the ones simply no longer there) but is they no longer respond to the utilities in the Installer classes then they probably shouldn't be listed therein.
saltypickle (no domain - but it is for sale!) sophie (no domain - also for sale - whee!) ssMirror (no server) swasource (seems to have a squeaksource3 service but nothing in it?)
It works if you know what to install. I have removed the ss3 project listing and especially the authors listings, as I am unsure what is admissible under the European Privacy regulations. We use it at HPI primarily for our students' projects, so these must stay private.
That's fine, though unfortunate since there is likely intersting stuff.
yeah, but https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/ is a better staring point.
For most of the software you can't just take the monticello browser and start loading some packages, as there's typically more steps involved to get going.
However, all the public stuff is still public, just not on the front page.
Finding a way to get it listed in response to a #basicAvailablePackages etc would be a bit help. How else are we supposed to find them?
Note that #basicAvailablePackages doesn't work for `Installer squeaksource` either. It seems to be repository specific, not repository-collection-aware. And how could it? We have no canonical way of denoting "this is a collection of Monticello repositories" to a Squeak image.
Yes, HPI's SqueakSource repos are documented out-of-band (see the Squeak Community Project link above). I have no intention to re-list stuff at the moment, because I have no time to think through the legal implications (we're in the EU, after all…)
That said, please keep the shortcut :)
Best regards -Tobias
PS: you'll notice that some packages on the page, eg, https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/... do not even use the shortcut. That's because they were worked on before I put the shortcut into trunk. We're making heavy use of the shortcut when preparing our biannual Squeak Images for students. :)
On 2019-08-26, at 1:33 AM, Tobias Pape Das.Linux@gmx.de wrote:
[snip]
And it returns an empty list for
Installer lukas basicAvailablePackages
That's because it isn t a single repository but a collection thereof, just like squeaksource.
Ah, a quick pass in the degubber suggests that something is not working as expected by the package listing code. The repository pointed to by #lukas is MCHttpRepository(http://source.lukas-renggli.ch), which when sent the usual #allfileNamesOrCache returns a reasonable looking list of stuff like 'magritte3addons/' 'pier/' '/built/oneclick/Pier-1.0-OneClick.zip' 'pieraddons/' 'pier2/' '/built/oneclick/Pier-2.0-OneClick.zip' (just grabbing a few entries from the middle of the list).
However, when the code checks for those results being valid they all fail the test in #isValid., which is why we get an apparently empty list of available packages.
Now the interesting thing is that it looks like this is a general issue for squeaksource and ss3 websites, at least. But my local package-cache MC returns a perfectly good list of packages. It looks like we have a minor design bug getting in the way here; for the `Installer cache availablePackages` case we end up running MCFileBasedRepository>>#validNames: and since the items in the package-cache directory are very 'ordinary' filenames it works. When trying `Installer ss availablePackages` we still run MCFileBasedRepository>>#validNames: but all the items returned are not at all the same format as package names. They are more like '/@kUVwlQhgbjCHrPSQ/8sV_cJ_-?18' - which I'm going to ascribe for the moment to Seaside. Clearly these sort of 'filenames' aren't going to return true when sent #isValid.
We're well out in the weeds from where I was intending to work on this but maybe someone with interest and experience in details of MC/squeaksource can work out a way to derive more appropriate names. Perhaps a more squeaksource specific repository class could over-ride #allFileNames or #parseFileNamesFromString: (like the file tree specific class does) to solve the problem. At least maybe we could over-ride to deliberately do nothing and not waste time fetching info we know isn't useful.
Generically, surely it would be helpful to have all the repository types able to list what projects/packages they can provide? Nice simple discovery always seems to be useful.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Doesn't just know nothing; doesn't even suspect much.
On Mon, Aug 26, 2019 at 02:03:30PM -0700, tim Rowledge wrote:
Generically, surely it would be helpful to have all the repository types able to list what projects/packages they can provide? Nice simple discovery always seems to be useful.
There are 3382 packages on squeaksource.com. Most are probably student workspaces or otherwise things of little general interest. Making this discoverable would be quite a project in itself ;-)
Dave
On 2019-08-26, at 2:36 PM, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Aug 26, 2019 at 02:03:30PM -0700, tim Rowledge wrote:
Generically, surely it would be helpful to have all the repository types able to list what projects/packages they can provide? Nice simple discovery always seems to be useful.
There are 3382 packages on squeaksource.com. Most are probably student workspaces or otherwise things of little general interest. Making this discoverable would be quite a project in itself ;-)
Well the benefit might be that we discover the useful stuff and delete everything else...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Never forget: 2 + 2 = 5 for extremely large values of 2.
Does anyone remember much about InstallerWeb and what it is intended to do? Right now it seems fairly broken and certainly a bit ... weird.
Unlike most of the repository accessor methods in Installer #web returns the class InstallerWeb instead of an instance of the relevant class. We can 'fix' that fairly easily but it's really hard to see what is meant to happen.
For example the old doc on http://installer.pbworks.com/w/page/19997682/Installer refers to Installer web url: 'http://minnow.cc.gatech.edu/squeak/uploads/5889/MakeTestsGreen39.cs'; install. ... which simply can't work because Installer web returns InstallerWeb InstallerWeb url: ... returns an instance of InstallerUrl and the `; install` would send the message to InstallerWeb. Oh well.
Installer installUrl: ... works rather better.
A bit more convoluted is the webSearchPath stuff that looks like it is meant to be a list of urls to look at; it isn't set by default (apparently it used to point to pbwiki?) and in fact the suggested Installer web url: 'http://wiki.squeak.org/squeak/742'; install. can't work any more because we end up at Installer>>install: where we try to send #scripts - which is not implemented.
So, is InstallerWeb still of value? Anyone care to suggest how to make it work if so?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Propaganda: a good look
Hi Tim,
I wrote it and I don't remember sufficient detail.
The idea was part of a suite of capabilities for the Squeak4.1 "new development model".
The capability was that each version of squeak would be created by applying a crafted script to the previous version, rather than hacking away at a trunk repo.
The scripts for various targets could be tested out and edited by contributors as it was embedded in a wiki page. Bug fixes were supplied by mantis, and called up by fix numbers, and the code was found embedded in mantis pages.
These scripts would also unload as many palaces from the main image as possible, moving them into a curated list of packages (Sake/Packages).
Bob the Builder, a continuous integration and testing tool also built on Sake, would run the scripts, build and test the images, periodically or whenever anything changed.
Keith
That's pretty clever, and it's kind of sad that it can't work right now.
I found a few more bugs that could be fixed quite simply and might result in something that would enable much the same capability. I guess it can't be in regular use though or we'd hear complaints about the missing methods.
So aside from the wierdness about Installer web returning the InstallerWeb class etc, and the missing #scripts method, I see that the methods that help with parsing a web page to fid the embedded script(s) got changed such that the pbwiki doc recipes are unusable - the tag is described as <code st=""></code> whereas the code specifies <code st></code st>. Unless anyone has a good technical reason to change the code here I'll leave it and just describe it that way in the comments.
Given that it doesn't work, doesn't seem to have any current use and we don't know what #scripts should do, I propose to remove the Installer class>>install: method. An equivalent capability ought to be in InstallerWeb anyway, if someone wants to reinvigorate it.
On 2019-08-27, at 2:38 AM, Keith keithy@consultant.com wrote:
Hi Tim,
I wrote it and I don't remember sufficient detail.
The idea was part of a suite of capabilities for the Squeak4.1 "new development model".
The capability was that each version of squeak would be created by applying a crafted script to the previous version, rather than hacking away at a trunk repo.
The scripts for various targets could be tested out and edited by contributors as it was embedded in a wiki page. Bug fixes were supplied by mantis, and called up by fix numbers, and the code was found embedded in mantis pages.
These scripts would also unload as many palaces from the main image as possible, moving them into a curated list of packages (Sake/Packages).
Bob the Builder, a continuous integration and testing tool also built on Sake, would run the scripts, build and test the images, periodically or whenever anything changed.
Keith
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, when Piglet stubbed his fag out on the semtex.
impara (no server)
impara is no more, but that isn't exactly news...
sophie (no domain - also for sale - whee!)
so the Bulgarians dropped it too, ey?
I still have copies of the above servers "somewhere". In case Tim's exercise comes up with a squeaksource server that is actually functional/installable and miraculously there is some spare time found between the sofa cushions I could try to make the packages available again. No idea if those would even load in any of the newer images though...
Cheers
Michael
Hi Mike!
On 2019-08-26, at 6:27 PM, Michael Rueger lists@andience.co.nz wrote:
impara (no server)
impara is no more, but that isn't exactly news...
Sadly true.
sophie (no domain - also for sale - whee!)
so the Bulgarians dropped it too, ey?
Like a hot ... something Bulgarian and hot.
I still have copies of the above servers "somewhere". In case Tim's exercise comes up with a squeaksource server that is actually functional/installable and miraculously there is some spare time found between the sofa cushions I could try to make the packages available again. No idea if those would even load in any of the newer images though...
Any chance the packages could just be uploaded to squeaksource.com? Likely not much would still load but there may be parts rescuable.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One sandwich short of a picnic.
Any chance the packages could just be uploaded to squeaksource.com? Likely not much would still load but there may be parts rescuable.
Yes, I think there could be some useful stuff there. But then I'm not exactly objective ;-)
I'll see when I find some time, hopefully soon. First need to dig through my archives
Cheers
Michael
had a brief look at the Sophie stuff, had forgotten that it is BSD license, not MIT. So will probably take a bit more effort to sort things into Sophie and contributed buckets...
On 27/08/19 10:37 PM, Michael Rueger wrote:
Any chance the packages could just be uploaded to squeaksource.com? Likely not much would still load but there may be parts rescuable.
Yes, I think there could be some useful stuff there. But then I'm not exactly objective ;-)
I'll see when I find some time, hopefully soon. First need to dig through my archives
Cheers
Michael
squeak-dev@lists.squeakfoundation.org
-
David T. Lewis -
Keith -
Marcel Taeumel -
Michael Rueger -
tim Rowledge -
Tobias Pape