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 > <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.henri...@gemtalksystems.com >>>> <mailto: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 >>>> <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>
