- Pharo-dev - lists.pharo.org

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

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

by Dale Henrichs

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: 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: 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">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 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 >

Aug. 31, 2020

[Pharo 9.0] Build #634: 7208-sharePools-is-defined-in-Class-but-called-from-superclass

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #634 was: FAILURE. The Pull Request #7220 was integrated: "7208-sharePools-is-defined-in-Class-but-called-from-superclass" Pull request url: https://github.com/pharo-project/pharo/pull/7220 Issue Url: https://github.com/pharo-project/pharo/issues/7208 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 31, 2020

[Pharo 9.0] Build #633: TextAction-do-not-share-block

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #633 was: FAILURE. The Pull Request #7221 was integrated: "TextAction-do-not-share-block" Pull request url: https://github.com/pharo-project/pharo/pull/7221 Issue Url: https://github.com/pharo-project/pharo/issues/TextAction Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 31, 2020

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

by Dale Henrichs

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

Aug. 31, 2020

OSProcess and CommandShell updated on GitHub for Pharo

by David T. Lewis

These updates bring OSProcess/CommandShell up to date with the latest development versions, and include earlier fixes for Pharo by Max Leske. The repositories are at https://github.com/dtlewis290/OSProcess-Tonel https://github.com/dtlewis290/CommandShell-Tonel A new feature of possible interest is: OSProcess outputOf: 'ls -lR | wc -l' This is a convenience method that handles parsing, piping, and error handling for a unix-style command pipeline. Both OSProcess and CommandShell must be loaded. Any errors detected in the external commands will be displayed in a Pharo debugger, proceed through the debugger to obtain the final stdout result. Dave

Aug. 30, 2020