A while back I was asking about internal use monticello repositories and one suggestion I didn't have time to do much with was to install squeaksource; three options were pointed out
squeaksource squeaksource3 personalsqueaksource. I thought I'd give it a quick try to see what happens. All in all it wasn't a particularly successful attempt. A) squeaksource3 I know Tobias officially abandoned this at the beginning of the year but since there is an entry in squeakmap for it I thought "let's try it". Nothing happened. There was clearly an attempt to find a suitable version for the image I am using (a 5.2-18229 release, and an updated version) but nothing further. I noticed Tobias had pointed out using `Metacello new configuration: 'SqueakSource3'; load: #('All').` ... so I tried that; it failed because of not finding a suitable version. I dug a little but didn't see anything obvious. I also looked in the MetacelloRepository for a ConfigurationOf... but it appears to have been removed. B) squeaksource There's also a SqueakMap entry for the old system. It didn't load either. Complaints about no #stable version etc I did see the ConfigurationOfSqueakSource and tried that but again, no stable version, no way I spotted to use any other named version that looked plausible. I suppose one shouldn't be too surprised since it is pretty old but it *is* the system we have as a main repository... C) personalsqueaksource This does seem to load from SqueakMap *but* not trivially. There is a syntax error in the Seaside2 method WAWikiRenderer>>#swikifyPiece: where the original was writing into a block arg (aLine, replaced with thisLine etc to make it complete). There is also an alarmingly large number of Undeclareds left over at the end of the load. So, not a terribly happy test. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: SDR: Shift Disk Right |
On Fri, Aug 23, 2019 at 02:35:40PM -0700, tim Rowledge wrote:
> A while back I was asking about internal use monticello repositories and one suggestion I didn't have time to do much with was to install squeaksource; three options were pointed out > squeaksource > squeaksource3 > personalsqueaksource. > > I thought I'd give it a quick try to see what happens. All in all it wasn't a particularly successful attempt. > <snip> > > B) squeaksource > There's also a SqueakMap entry for the old system. It didn't load either. > Complaints about no #stable version etc > I did see the ConfigurationOfSqueakSource and tried that but again, no > stable version, no way I spotted to use any other named version that looked >plausible. I suppose one shouldn't be too surprised since it is pretty old > but it *is* the system we have as a main repository... > Assuming that the "old system" refers to what we now know as squeaksource.com, then there is no real repository for the sources. It basically exists as a long running image that has survived into the modern era, with some workspaces that explain how the image originally came into existance, and how it has subsequently been maintained in the intervening decades. The source.squeak.org image is of newer vintage, and it is closely related to (same as?) the personalsqueaksource version. Dave |
> On 2019-08-23, at 6:57 PM, David T. Lewis <[hidden email]> wrote: >> >> B) squeaksource >> There's also a SqueakMap entry for the old system. It didn't load either. >> Complaints about no #stable version etc >> I did see the ConfigurationOfSqueakSource and tried that but again, no >> stable version, no way I spotted to use any other named version that looked >> plausible. I suppose one shouldn't be too surprised since it is pretty old >> but it *is* the system we have as a main repository... >> > > Assuming that the "old system" refers to what we now know as squeaksource.com, > then there is no real repository for the sources. It basically exists as a > long running image that has survived into the modern era, with some workspaces > that explain how the image originally came into existance, and how it has > subsequently been maintained in the intervening decades. Yah; well, that's perhaps even worse than I remembered. I see someone balancing on a highwire over a raging river of lava, with lava-proof giant Piranha swimming hungrily below. And the wire is razor thin and the walkers feet are unprotected. > > The source.squeak.org image is of newer vintage, and it is closely related > to (same as?) the personalsqueaksource version. Ah, interesting. That one completely escaped my attention. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: HBT: Harvest Binary Tree |
In reply to this post by timrowledge
Hi
> On 23.08.2019, at 23:35, tim Rowledge <[hidden email]> wrote: > > A while back I was asking about internal use monticello repositories and one suggestion I didn't have time to do much with was to install squeaksource; three options were pointed out > squeaksource > squeaksource3 > personalsqueaksource. > > I thought I'd give it a quick try to see what happens. All in all it wasn't a particularly successful attempt. > > A) squeaksource3 > I know Tobias officially abandoned this at the beginning of the year but since there is an entry in squeakmap for it I thought "let's try it". Nothing happened. There was clearly an attempt to find a suitable version for the image I am using (a 5.2-18229 release, and an updated version) but nothing further. > I noticed Tobias had pointed out using > `Metacello new configuration: 'SqueakSource3'; > load: #('All').` Yeah, sorry for that. This should be Metacello new configuration: 'SqueakSource'; version: #bleedingEdge; load: #('All'). But it is probably advisable to have a Seaside with WebServer adaptor installed already. You can use the following to install Seaside version 3.2, this worked very well for me last year: Metacello new baseline: 'Grease'; githubUser: 'SeasideSt' project: 'Grease' commitish: 'master' path: 'repository'; load. "=-=-=-" Metacello new configuration: 'Seaside3'; smalltalkhubUser: 'Seaside' project: 'MetacelloConfigurations'; onConflictUseLoaded; version: #'release3.2'; load: #('OneClick' 'Security' 'Filesystem'). Metacello new configuration: 'Magritte3'; smalltalkhubUser: 'Magritte' project: 'Magritte3'; onConflictUseLoaded; version: #'release3.5'; load: #('Core' 'Tests' 'Seaside'). (I still have https://github.com/krono/squeaksource3.. somebody to transfer that to? > ... so I tried that; it failed because of not finding a suitable version. I dug a little but didn't see anything obvious. I also looked in the MetacelloRepository for a ConfigurationOf... but it appears to have been removed. it lives in http://squeaksource.com/MetacelloRepository/, not in https://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/MetacelloRepository/. The former is still the 'canonical' where-to-find-ConfigurationOf-Packages for Metacello. > > B) squeaksource > There's also a SqueakMap entry for the old system. It didn't load either. Complaints about no #stable version etc > I did see the ConfigurationOfSqueakSource and tried that but again, no stable version, no way I spotted to use any other named version that looked plausible. I suppose one shouldn't be too surprised since it is pretty old but it *is* the system we have as a main repository... > > C) personalsqueaksource > This does seem to load from SqueakMap *but* not trivially. There is a syntax error in the Seaside2 method WAWikiRenderer>>#swikifyPiece: where the original was writing into a block arg (aLine, replaced with thisLine etc to make it complete). There is also an alarmingly large number of Undeclareds left over at the end of the load. > > So, not a terribly happy test. > > tim Best regards -Tobias PS: all in one script: "=-=-=- Seaside, Magritte, and Prerequisites " Metacello new baseline: 'Grease'; githubUser: 'SeasideSt' project: 'Grease' commitish: 'master' path: 'repository'; load. Metacello new configuration: 'Seaside3'; smalltalkhubUser: 'Seaside' project: 'MetacelloConfigurations'; onConflictUseLoaded; version: #'release3.2'; load: #('OneClick' 'Security' 'Filesystem'). Metacello new configuration: 'Magritte3'; smalltalkhubUser: 'Magritte' project: 'Magritte3'; onConflictUseLoaded; version: #'release3.5'; load: #('Core' 'Tests' 'Seaside'). "=-=-=- SqueakSource3" Metacello new configuration: 'SqueakSource'; squeaksource: 'squeaksource3'; version: #bleedingEdge; load: #('All'). "=-=-=- " |
> On 2019-08-26, at 1:52 AM, Tobias Pape <[hidden email]> wrote: >> >> A) squeaksource3 >> I know Tobias officially abandoned this at the beginning of the year but since there is an entry in squeakmap for it I thought "let's try it". Nothing happened. There was clearly an attempt to find a suitable version for the image I am using (a 5.2-18229 release, and an updated version) but nothing further. >> I noticed Tobias had pointed out using >> `Metacello new configuration: 'SqueakSource3'; >> load: #('All').` > > Yeah, sorry for that. > This should be > > Metacello new > configuration: 'SqueakSource'; > version: #bleedingEdge; > load: #('All'). > > But it is probably advisable to have a Seaside with WebServer adaptor installed already. That very nearly worked, but not quite. I tried in an image with seaside installed and it actually complained that it was there... so I tried again in a fresh image and things very nearly went smoothly. A great deal of code was loaded but with one complaint notifier- This package depends on the following classes: WARestfulFilter WAEmailErrorHandler You must resolve these dependencies before you will be able to load these definitions: SSEmailErrorHandler SSEmailErrorHandler>>bodyFor: [snip] SSUrlFilter SSUrlFilter>>authResponseFor: [snip] Of course, I forgot to note which package was making the complaint. Poking around it looks as if the code for SSEmailErrorHandler & SSUrlFilter are in squeaksource.com/squeaksource3/SqueakSource-pmm.1121 - is that where we would expect them to load from? I found WARestfulFilter in http://www.smalltalkhub.com/mc/Seaside/Seaside30Addons/main and it looks (from the ConfgurationOfSeasdide class) as if http://smalltalkhub.com/mc/Seaside/Seaside31/main/Seaside-Email-pmm.26 is supposed to have loaded too. Running the load process again, the above problem occurs in MCPackageLoader>loadWithNameLike: 'SqueakSource-Core-topa.104' - hope that helps! Just on a whim I tried manually loading SqueakSource-pmm.1121 but it depends on some other REST related stuff and so probably that isn't the right solution. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: IA: Illogical And |
Assuming for a moment that the loading process previously mentioned worked well enough, just how does one actually start squeaksource serving? I can't see any obvious seaside-like control panel, haven't found any class with a comment describing this... what do I do?
tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim loggerheads - lumberjack sniffing addicts |
In reply to this post by David T. Lewis
>
Yes, source.squeak.org is a Personal SqueakSource instance. They're one and the same. It is based on the code from the "old system", but simply brought up to modern image with dozens fixes and improvements. |
In reply to this post by timrowledge
Hi Tim,
Since you didn't say, I don't know what you tried to install, or what image level you tried to install it in, but I just verified that "Personal SqueakSource", after all these years, _still_ loads cleanly without a single hiccup into the image level designated by the SqueakMap entry -- 5.2. So, not a terribly happy test. A lot of work went into designing it to be easy to install and deploy on a Debian/Ubuntu Linux. I wish I knew what you tried to do to know where it went wrong.. - Chris
|
> On 2019-08-28, at 7:29 PM, Chris Muller <[hidden email]> wrote: > > Hi Tim, > > [snip] > A lot of work went into designing it to be easy to install and deploy on a Debian/Ubuntu Linux. I wish I knew what you tried to do to know where it went wrong.. Well as I said, it went fine except for that one Seaside method trying to write into a block arg. My notes say I tried the install on a plain 5.2 and an updated one with the same results, but since it is always possible I screwed up, let's do it again to try to be sure. OK, interesting; a dead plain straight out of the zip 5.2-18299 does indeed load cleanly (though the asking for the user/password near the end jars a tiny bit). So what was the difference... well it *was* an 18299 image in the previous test but I did load my preferences file. Ahhh. OK, my preferences disables 'Allow block argument assignment' because, obviously, nobody would ever do that ;-) I must have set that and saved it quite some time ago. Confusion resolved! I wouldn't say it was even worth 'fixing' the WAWikiRenderer>>swikifyPiece: method since it is from Seaside2 and hopefully there is some chance of a personalsqueaksource based on Seaside3 some time. Perhaps making the install script enable the block-arg-writing during the load might be worthwhile. Thanks for doing that check-install; now to see if Raspbian will run the system... tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: RP: Read Printer |
> A lot of work went into designing it to be easy to install and deploy on a Debian/Ubuntu Linux. I wish I knew what you tried to do to know where it went wrong.. I missed that, sorry. and an updated one with the same results, but since it is always possible I screwed up, let's do it again to try to be sure. Agree, but that's Seaside initialization, what solution would you propose? So what was the difference... well it *was* an 18299 image in the previous test but I did load my preferences file. Ahhh. OK, my preferences disables 'Allow block argument assignment' because, obviously, nobody would ever do that ;-) I must have set that and saved it quite some time ago. Baaaad Seaside code... should fix.
Why? So many important things to do before that... Perhaps making the install script enable the block-arg-writing during the load might be worthwhile. That's probably quickest and easiest solution, yes...
Just want to set your expectations -- the Linux scripts were written for Ubuntu and may have issues on Raspbian. But please let me know how it goes, I'll be very curious! - Chris
|
> On 2019-08-29, at 3:00 PM, Chris Muller <[hidden email]> wrote: > > Just want to set your expectations -- the Linux scripts were written for Ubuntu and may have issues on Raspbian. But please let me know how it goes, I'll be very curious! First weirdness; in the SSRepository>deploy method we get an Error because there is no configsys.st file to add to the zip. I can't find any place that looks like it will create such a file, not any other mention. I just did `echo nil > configsys.st` to see if it would go any further. Next problem is that #deploy explicitly refers to sqcogspur64linuxht, which is obviously not appropriate for Raspbian. It's also not the format (or indeed the same structure) as the release VMs, which could be problematic. If I use a similarly non-release Pi vm bundle and change the search to compensate ... lots of *.out files get blasted for a moment and then it sits busy. The zipping worked, the unzipping worked, the system is actually up and provides the front page. Excellent! Adding an account seems fine too. The `sudo svstat /service/squeaksource` test fails though; apparently the file does not exist. I'm not familiar with 'daemontools` - is it systemd related stuff? I'll send the changed #deploy method offline. Cool stuff! tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Starbucks are, of course, run by the Caffeinatti. |
In reply to this post by timrowledge
Dear tim
> On 29.08.2019, at 01:37, tim Rowledge <[hidden email]> wrote: > > > >> On 2019-08-26, at 1:52 AM, Tobias Pape <[hidden email]> wrote: >>> >>> A) squeaksource3 >>> I know Tobias officially abandoned this at the beginning of the year but since there is an entry in squeakmap for it I thought "let's try it". Nothing happened. There was clearly an attempt to find a suitable version for the image I am using (a 5.2-18229 release, and an updated version) but nothing further. >>> I noticed Tobias had pointed out using >>> `Metacello new configuration: 'SqueakSource3'; >>> load: #('All').` >> >> Yeah, sorry for that. >> This should be >> >> Metacello new >> configuration: 'SqueakSource'; >> version: #bleedingEdge; >> load: #('All'). >> >> But it is probably advisable to have a Seaside with WebServer adaptor installed already. > > That very nearly worked, but not quite. mea culpa. I did dot re-test and got distracted… If you look at the SqueakSource-Cofiguration, in the baseline (latest is baseline30rc4: i think), you see the deps: … project: 'Seaside' with: [ spec className: 'ConfigurationOfSeaside3'; loads: #('Base' 'Email' 'RSS' 'REST'); … > So, for the record, the whole ordeal: "=-=-=- Seaside, Magritte, and Prerequisites " Metacello new baseline: 'Grease'; githubUser: 'SeasideSt' project: 'Grease' commitish: 'master' path: 'repository'; load. Metacello new configuration: 'Seaside3'; smalltalkhubUser: 'Seaside' project: 'MetacelloConfigurations'; onConflictUseLoaded; version: #'release3.2'; load: #('OneClick' 'Security' 'Filesystem' 'Email' 'RSS' 'REST'). Metacello new configuration: 'Magritte3'; smalltalkhubUser: 'Magritte' project: 'Magritte3'; onConflictUseLoaded; version: #'release3.5'; load: #('Core' 'Seaside'). "=-=-=- SqueakSource3" Metacello new configuration: 'SqueakSource'; squeaksource: 'squeaksource3'; version: #bleedingEdge; load: #('All'). "=-=-=- " Best regards -Tobias > I tried in an image with seaside installed and it actually complained that it was there... so I tried again in a fresh image and things very nearly went smoothly. A great deal of code was loaded but with one complaint notifier- > This package depends on the following classes: > WARestfulFilter > WAEmailErrorHandler > You must resolve these dependencies before you will be able to load these definitions: > SSEmailErrorHandler > SSEmailErrorHandler>>bodyFor: > [snip] > SSUrlFilter > SSUrlFilter>>authResponseFor: > [snip] > > Of course, I forgot to note which package was making the complaint. Poking around it looks as if the code for SSEmailErrorHandler & SSUrlFilter are in squeaksource.com/squeaksource3/SqueakSource-pmm.1121 - is that where we would expect them to load from? I found WARestfulFilter in http://www.smalltalkhub.com/mc/Seaside/Seaside30Addons/main and it looks (from the ConfgurationOfSeasdide class) as if http://smalltalkhub.com/mc/Seaside/Seaside31/main/Seaside-Email-pmm.26 is supposed to have loaded too. > > Running the load process again, the above problem occurs in MCPackageLoader>loadWithNameLike: 'SqueakSource-Core-topa.104' - hope that helps! Just on a whim I tried manually loading SqueakSource-pmm.1121 but it depends on some other REST related stuff and so probably that isn't the right solution. > > > tim |
In reply to this post by timrowledge
> On 29.08.2019, at 03:06, tim Rowledge <[hidden email]> wrote: > > Assuming for a moment that the loading process previously mentioned worked well enough, just how does one actually start squeaksource serving? I can't see any obvious seaside-like control panel, haven't found any class with a comment describing this... what do I do? Hmm, there should be a Seaside Control Panel in Apps after loading.. you can start it with WAControlPanel openDefault you can work with the server(s)/adaptor(s) via WAAdmin defaultServerManager (for example WAAdmin defaultServerManager startAll WAAdmin defaultServerManager adaptors WAAdmin serverAdaptors ) or start the WebClient/WebServer-based adaptor directly: WAWebServerAdaptor start "if there's a default already" WAWebServerAdaptor startOn: aPort. =-=-=-=-= For SqueakSource, the class SSInstallWizzard registers itself on load as a Seaside application (see class-side #register) and (assuming defaults) can be started at http://localhost:8080/installSS which guides you thoug the SqueakSource-setup. Here some sane choices: well known name: leave empty storage class: Filesystem for larger installs on squeak, Dictionary for quick, small assesments, Nested dictionary for GemStone or slightly larger Squeak stuff, slow disks and so on. =-=-=-=-= hth Best regards -Tobias |
Free forum by Nabble | Edit this page |