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