September 2020 - Pharo-dev - lists.pharo.org

Unity Happens One Step at a Time (was Re: [squeak-dev] Porting my programs from Squeak 3.10.2 to 3.5)

by Sean DeNigris

I've been pontificating about unity between dialects, convinced more than ever that we need each other and have more of a simple (not easy) communication problem than anything else, and pestering the principals of various communities, so I decided to put some concrete action behind it - some "skin in the game" as we say in the U.S. After reading Trygve's frustration with Squeak image/VM management, and Eliot's mention of Pharo's solution, I've extended PharoLauncher to manage and run Squeak (and GToolkit) VMs/images. The current limitation vs. launching standard Pharo images is that you have to download the VMs and images and manually install them due to differences in URL and other conventions. However once the files are in place, you can create templates allowing images to be created at will from different Squeak versions and automatically run with the correct VM. Auto-installation could probably be done if someone cares enough but it scratched my itch for the moment to manage GT images. Iâm sure Cuis support could be added, but the hooks are now available and someone more familiar with its VM/image installation might have an easier time. Until my latest PR [1] is merged, brave souls can play with it and give feedback by loading my issue branch [2] into the latest Launcher release [3]. NB only tested on Mac. It seemed Trygve was at his wits' end, but maybe this and other small gestures will let him know how important he is to our community if not motivate him to resume his important work. I challenge you, as a member of our wider Squeak/Pharo/Cuis family: what small action can you take today that unites us rather than divides us? We can be each others' supporters even if technical, vision and other differences keep our codebases somewhat distinct. I believe the seeds of wars are planted when I lack the grace to give those around me the benefit of the doubt that they mean well and are trying their best. There is more than enough of that already in the world. Letâs invent a *better* futureâ¦ Your brother, Sean 1. https://github.com/pharo-project/pharo-launcher/pull/503 2. https://github.com/seandenigris/pharo-launcher/tree/enh_vm-image-custom-hoo… 3. https://pharo.org/download

Sept. 2, 2020

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

by Christophe Demarey

> Le 1 sept. 2020 Ã 18:44, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> a Ã©crit : > > > On 9/1/20 1:51 AM, Christophe Demarey wrote: >> Hi Dale, >> >> Thanks for the very detailed explanation. >> I updated the href link to only include the mcz file name. I also took the opportunity to display a nicer URL and set up a permanent redirection to the current mc repository folder (else links would be broken : we must keep only file names, paths prohibited). >> Tell me if it is ok. > > Christophe, > > Everything looks fine. The travis jobs that were failing because of the packageName issue are now failing because of test issues (you win some, you lose some:), so I think we are finally out of woods. >> Also, I will not reinvent the past but I think It was a mistake to use an html listing as input for tools. A raw list of files contained in the Monticello repository would have been better.It is also strange to use an href link value as the name of the mcz file. If the displayed text of the link was used, it would have allow to store mcz files at any place on the web server. > The decision to use html for list packages was a decision made almost 20 years ago, when Avi and Colin first invented Monticello and once code gets written and people start relying on that code, it gets REAL hard to change without creating pain for all of the users. This gets even more complicated when there are multiple, independent sites implemented using the old scheme. Yes, it is easy to say a decision was not so good afterwards. And, yes, when people use code in many places, it becomes harder to change this code. >> But anyway, if things work fine now, we are done! >> > I agree that it looks like we are done and I appreciate your patience and effort to resolve the issues. Sorry for the time GemStone tools were broken but I was not aware of te use of this HTML package listing this way. The goal of Smalltalk archive was / is to be a Â« smooth Â» substitution of Smalltalkhub, keeping existing URLs alive, even if redirected. This avoids a lot of changes in existing code. Regards, Christophe

Sept. 1, 2020

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

by Dale Henrichs

On 9/1/20 1:51 AM, Christophe Demarey wrote: > Hi Dale, > > Thanks for the very detailed explanation. > I updated the href link to only include the mcz file name. I also took > the opportunity to display a nicer URL and set up a permanent > redirection to the current mc repository folder (else links would be > broken : we must keep only file names, paths prohibited). > Tell me if it is ok. Christophe, Everything looks fine. The travis jobs that were failing because of the packageName issue are now failing because of test issues (you win some, you lose some:), so I think we are finally out of woods. > Also, I will not reinvent the past but I think It was a mistake to use > an html listing as input for tools. A raw list of files contained in > the Monticello repository would have been better.It is also strange to > use an href link value as the name of the mcz file. If the displayed > text of the link was used, it would have allow to store mcz files at > any place on the web server. The decision to use html for list packages was a decision made almost 20 years ago, when Avi and Colin first invented Monticello and once code gets written and people start relying on that code, it gets REAL hard to change without creating pain for all of the users. This gets even more complicated when there are multiple, independent sites implemented using the old scheme. > But anyway, if things work fine now, we are done! > I agree that it looks like we are done and I appreciate your patience and effort to resolve the issues. Dale

Sept. 1, 2020

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

by Tom Beckmann

Works perfectly, thank you for the rapid fix! Best, Tom On Tue, Sep 1, 2020 at 12:27 PM Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > > > Le 1 sept. 2020 Ã 12:21, Christophe Demarey <christophe.demarey(a)inria.fr> > a Ã©crit : > > Hi Tom, > > Le 1 sept. 2020 Ã 12:14, Tom Beckmann <tomjonabc(a)gmail.com> a Ã©crit : > > Hi everyone, > > not quite sure what's happening yet, but bootstrapping Metacello in Squeak > will attempt to download > http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz > which currently returns a 302 to > http://smalltalkhub.com/dkh/metacello/mc?format=raw-html > which just returns the index page's HTML instead of the mcz file. > > Is this possibly a slip in the matching rules you added recently?- > > > I think so. I did not see it while testing in my browser (probably because > of its cache) but I can see it with curl. > I will fix that ASAP. > > > Should be ok now. > Let me know. > > > >

Sept. 1, 2020

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

by Christophe Demarey

> Le 1 sept. 2020 Ã 12:21, Christophe Demarey <christophe.demarey(a)inria.fr> a Ã©crit : > > Hi Tom, > >> Le 1 sept. 2020 Ã 12:14, Tom Beckmann <tomjonabc(a)gmail.com <mailto:tomjonabc@gmail.com>> a Ã©crit : >> >> Hi everyone, >> >> not quite sure what's happening yet, but bootstrapping Metacello in Squeak will attempt to download >> http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz <http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz> >> which currently returns a 302 to >> http://smalltalkhub.com/dkh/metacello/mc?format=raw-html <http://smalltalkhub.com/dkh/metacello/mc?format=raw-html> >> which just returns the index page's HTML instead of the mcz file. >> >> Is this possibly a slip in the matching rules you added recently?- > > I think so. I did not see it while testing in my browser (probably because of its cache) but I can see it with curl. > I will fix that ASAP. Should be ok now. Let me know.

Sept. 1, 2020

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

by Christophe Demarey

Hi Tom, > Le 1 sept. 2020 Ã 12:14, Tom Beckmann <tomjonabc(a)gmail.com> a Ã©crit : > > Hi everyone, > > not quite sure what's happening yet, but bootstrapping Metacello in Squeak will attempt to download > http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz <http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz> > which currently returns a 302 to > http://smalltalkhub.com/dkh/metacello/mc?format=raw-html <http://smalltalkhub.com/dkh/metacello/mc?format=raw-html> > which just returns the index page's HTML instead of the mcz file. > > Is this possibly a slip in the matching rules you added recently?- I think so. I did not see it while testing in my browser (probably because of its cache) but I can see it with curl. I will fix that ASAP. Thanks for reporting. Christophe

Sept. 1, 2020

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

by Tom Beckmann

Hi everyone, not quite sure what's happening yet, but bootstrapping Metacello in Squeak will attempt to download http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz which currently returns a 302 to http://smalltalkhub.com/dkh/metacello/mc?format=raw-html which just returns the index page's HTML instead of the mcz file. Is this possibly a slip in the matching rules you added recently? Best, Tom On Tue, Sep 1, 2020 at 10:52 AM Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > Hi Dale, > > Thanks for the very detailed explanation. > I updated the href link to only include the mcz file name. I also took the > opportunity to display a nicer URL and set up a permanent redirection to > the current mc repository folder (else links would be broken : we must keep > only file names, paths prohibited). > Tell me if it is ok. > > Also, I will not reinvent the past but I think It was a mistake to use an > html listing as input for tools. A raw list of files contained in the > Monticello repository would have been better.It is also strange to use an > href link value as the name of the mcz file. If the displayed text of the > link was used, it would have allow to store mcz files at any place on the > web server. > But anyway, if things work fine now, we are done! > > Cheers, > Christophe > > Le 31 aoÃ»t 2020 Ã 21:02, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> > a Ã©crit : > > Okay, I've finally sorted things out ... and it gets down to the > difference between MCHttpRepository>>parseFileNamesFromStream: returning an > empty list (the original problem) and returning a list of the wrong thing > the current problem). When I reported that the "manual test" was passing, > that was true, but instead of listing the names of the packages, the > "manual test" was returning a list of urls, and not a list of packageNames > and I didn't recognize the difference --- but the code that is executing in > the travis test does recognize the difference. > > The GemStone code does not special case SmalltalkHub, while Pharo does > handle SmalltalkHub as a special case and to actually see the difference > between the two, you have to use the following expression (the > MCHttpRepository class>>location:user:password: is intercepted and creates > an MCSqueaksourceRepository instance, which has different implementation of > parseFileNamesFromStream:): > > (MCHttpRepository new > location: 'http://smalltalkhub.com/mc/Swazoo/Swazoo/main'; > user: ''; > password: ''; > yourself) allFileNames > > Both Pharo and GemStone, use the pretty much same code for > MCHttpRepository>>parseFileNamesFromStream: (this is the GemStone version): > > parseFileNamesFromStream: aStream > | names fullName | > names := OrderedCollection new. > [ aStream atEnd ] > whileFalse: [ > [ > aStream upTo: $<. > aStream atEnd > ifTrue: [ true ] > ifFalse: [ > {$a. > $A. > nil} includes: aStream next ] ] > whileFalse. > aStream upTo: $". > aStream atEnd > ifFalse: [ > fullName := aStream upTo: $". > names add: fullName unescapePercents ] ]. > ^ names > > and both return the same result when pointed at > http://www.squeaksource.com/MooseSQL (you should recognize the > EyeCollectionInspector from Pharo3.0:) and the other inspector is from tODE > ... Note that both are producing a list of .mcz file names: > > <lgkbcdpahkmomino.png> > And when the expression: > > (MCHttpRepository new > location: 'http://smalltalkhub.com/mc/Swazoo/Swazoo/main'; > user: ''; > password: ''; > yourself) allFileNames > > > is used, both Pharo and GemStone produce the same (wrong) list of package > names from SmalltalkHub: > > <elmgecjolgkmfkgb.png>The travis test is trying to scan for > ConfigurationOfSwazoo2 package names in the list and that algorithm is > failing because it expects only a list of .mcz file names as produced like > that produced for http://www.squeaksource.com/MooseSQL ... > > The difference boils down to how the `href` statements are formed. The > Here is the relevant statement from SqueakSource: > > <a > href="Moose-SQL-Importer-FabrizioPerin.22.mcz">Moose-SQL-Importer-FabrizioPerin.22.mcz</a> > > and here is the statement from SmalltalkHub with the full url included in > the href field): > > <a href="http://smalltalkhub.com/Swazoo/Swazoo/mc/Swazoo-HTTP-avi.4.mcz" > <http://smalltalkhub.com/Swazoo/Swazoo/mc/Swazoo-HTTP-avi.4.mcz> > >Swazoo-HTTP-avi.4.mcz</a> > > So only the .mcz filename should be included in the href field as the code > in MCHttpRepository>>parseFileNamesFromStream: _is parsing the package name > from the href field_. > > Dale > On 8/30/20 7:31 PM, Dale Henrichs wrote: > > > On 8/30/20 3:07 AM, Christophe Demarey wrote: > > Hi Dale, > > Le 29 aoÃ»t 2020 Ã 19:40, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> > a Ã©crit : > > Sooooo close, the interactive tests are passing, but there is a use case > that is popping up in a travis job[1] where this url > http://smalltalkhub.com/mc/Swazoo/Swazoo/main is being used (no trailing > slash) and this form of the url still produces the `raw` listing, > > > Are you sure? For me, http://smalltalkhub.com/mc/Swazoo/Swazoo/main produces > the html listing > > I am sure that the travis build is still failing[1] after having passed 2 > weeks ago, before the dynamic site was switched out. > > I am sure the a manual test (different code path than the travis site) > that was failing with the new site is now passing. > > I did discovered that that the reason I _thought_, that the html page > wasn't being displayed was because the old page for that url was cached in > my web browser:( Sorry for the red herring. > > Tomorrow I will dig a little deeper and let you know what is causing the > travis test to fail ... I've seen this particular error with the Swazoo > repository show up in production tests that I run locally, so I should be > able to identify the cause of the failures. > > Dale > > [1] > https://travis-ci.org/github/GsDevKit/GsDevKit_home/jobs/721523220#L2354 > > >

Sept. 1, 2020

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

by Christophe Demarey

Hi Dale, Thanks for the very detailed explanation. I updated the href link to only include the mcz file name. I also took the opportunity to display a nicer URL and set up a permanent redirection to the current mc repository folder (else links would be broken : we must keep only file names, paths prohibited). Tell me if it is ok. Also, I will not reinvent the past but I think It was a mistake to use an html listing as input for tools. A raw list of files contained in the Monticello repository would have been better.It is also strange to use an href link value as the name of the mcz file. If the displayed text of the link was used, it would have allow to store mcz files at any place on the web server. But anyway, if things work fine now, we are done! Cheers, Christophe > Le 31 aoÃ»t 2020 Ã 21:02, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> a Ã©crit : > > Okay, I've finally sorted things out ... and it gets down to the difference between MCHttpRepository>>parseFileNamesFromStream: returning an empty list (the original problem) and returning a list of the wrong thing the current problem). When I reported that the "manual test" was passing, that was true, but instead of listing the names of the packages, the "manual test" was returning a list of urls, and not a list of packageNames and I didn't recognize the difference --- but the code that is executing in the travis test does recognize the difference. > > The GemStone code does not special case SmalltalkHub, while Pharo does handle SmalltalkHub as a special case and to actually see the difference between the two, you have to use the following expression (the MCHttpRepository class>>location:user:password: is intercepted and creates an MCSqueaksourceRepository instance, which has different implementation of parseFileNamesFromStream:): > > (MCHttpRepository new > location: 'http://smalltalkhub.com/mc/Swazoo/Swazoo/main <http://smalltalkhub.com/mc/Swazoo/Swazoo/main>'; > user: ''; > password: ''; > yourself) allFileNames > Both Pharo and GemStone, use the pretty much same code for MCHttpRepository>>parseFileNamesFromStream: (this is the GemStone version): > > parseFileNamesFromStream: aStream > | names fullName | > names := OrderedCollection new. > [ aStream atEnd ] > whileFalse: [ > [ > aStream upTo: $<. > aStream atEnd > ifTrue: [ true ] > ifFalse: [ > {$a. > $A. > nil} includes: aStream next ] ] > whileFalse. > aStream upTo: $". > aStream atEnd > ifFalse: [ > fullName := aStream upTo: $". > names add: fullName unescapePercents ] ]. > ^ names > and both return the same result when pointed at http://www.squeaksource.com/MooseSQL <http://www.squeaksource.com/MooseSQL> (you should recognize the EyeCollectionInspector from Pharo3.0:) and the other inspector is from tODE ... Note that both are producing a list of .mcz file names: > > <lgkbcdpahkmomino.png> > > And when the expression: > (MCHttpRepository new > location: 'http://smalltalkhub.com/mc/Swazoo/Swazoo/main <http://smalltalkhub.com/mc/Swazoo/Swazoo/main>'; > user: ''; > password: ''; > yourself) allFileNames > > is used, both Pharo and GemStone produce the same (wrong) list of package names from SmalltalkHub: > > <elmgecjolgkmfkgb.png>The travis test is trying to scan for ConfigurationOfSwazoo2 package names in the list and that algorithm is failing because it expects only a list of .mcz file names as produced like that produced for http://www.squeaksource.com/MooseSQL <http://www.squeaksource.com/MooseSQL> ... > > The difference boils down to how the `href` statements are formed. The Here is the relevant statement from SqueakSource: > > <a href="Moose-SQL-Importer-FabrizioPerin.22.mcz">Moose-SQL-Importer-FabrizioPerin.22.mcz</a> > > and here is the statement from SmalltalkHub with the full url included in the href field): > > <a href="http://smalltalkhub.com/Swazoo/Swazoo/mc/Swazoo-HTTP-avi.4.mcz" <http://smalltalkhub.com/Swazoo/Swazoo/mc/Swazoo-HTTP-avi.4.mcz>>Swazoo-HTTP-avi.4.mcz</a> > > So only the .mcz filename should be included in the href field as the code in MCHttpRepository>>parseFileNamesFromStream: _is parsing the package name from the href field_. > > Dale > > On 8/30/20 7:31 PM, Dale Henrichs wrote: >> >> On 8/30/20 3:07 AM, Christophe Demarey wrote: >>> Hi Dale, >>> >>>> Le 29 aoÃ»t 2020 Ã 19:40, Dale Henrichs <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> a Ã©crit : >>>> >>>> Sooooo close, the interactive tests are passing, but there is a use case that is popping up in a travis job[1] where this url http://smalltalkhub.com/mc/Swazoo/Swazoo/main <http://smalltalkhub.com/mc/Swazoo/Swazoo/main> is being used (no trailing slash) and this form of the url still produces the `raw` listing, >>>> >>> >>> Are you sure? For me, http://smalltalkhub.com/mc/Swazoo/Swazoo/main <http://smalltalkhub.com/mc/Swazoo/Swazoo/main> produces the html listing >> I am sure that the travis build is still failing[1] after having passed 2 weeks ago, before the dynamic site was switched out. >> >> I am sure the a manual test (different code path than the travis site) that was failing with the new site is now passing. >> >> I did discovered that that the reason I _thought_, that the html page wasn't being displayed was because the old page for that url was cached in my web browser:( Sorry for the red herring. >> >> Tomorrow I will dig a little deeper and let you know what is causing the travis test to fail ... I've seen this particular error with the Swazoo repository show up in production tests that I run locally, so I should be able to identify the cause of the failures. >> >> Dale >> >> [1] https://travis-ci.org/github/GsDevKit/GsDevKit_home/jobs/721523220#L2354 <https://travis-ci.org/github/GsDevKit/GsDevKit_home/jobs/721523220#L2354>

Sept. 1, 2020

Re: [Pharo-dev] OSProcess and CommandShell updated on GitHub for Pharo

by Sean P. DeNigris

Thanks, Dave!! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 1, 2020