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.dema...@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.henri...@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.henri...@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 > > >
