Hi Dale, I would not call it a bug but an omission ;) It is hard to guess that a tool is scraping an html page to get data.
Nevertheless, I will take a look today to find a solution for Glass to work again with smalltalkhub. Could you tell me what is the expected output? What is the html structure that is expected? I think I can find a solution to produce an html page through apache index listing and rewrite rules to catch URLs like http://smalltalkhub.com/mc/Seaside/Seaside30LGPL/main. Thanks, Christophe. > Le 27 août 2020 à 23:50, Dale Henrichs <dale.henri...@gemtalksystems.com> a > écrit : > > That makes sense and confirms that the static site has a bug ... portions of > my work are on hold until the SmalltalkHub issue is resolved and at least one > other GemStone user is impacted, so far... > > Dale > > On 8/27/20 2:41 PM, Sven Van Caekenberghe wrote: >> The static version of StHub seems to always assume the client is Pharo, >> while the dynamic version used format=raw (which non-Pharo implementation >> did not include in their request for the listing) to send the Pharo specific >> response only then. >> >>> On 27 Aug 2020, at 23:34, Dale Henrichs <dale.henri...@gemtalksystems.com> >>> wrote: >>> >>> Depends upon how old that optimized code is ... as little as a 15 days ago, >>> the last time my travis cron job ran successfully[1], the pharo code >>> presumably was handling html page returns ... I'm pretty certain I haven't >>> touched the Monticello HTTP handling code for nearly a decade:) >>> >>> Dale >>> >>> [1] https://travis-ci.org/github/GsDevKit/GsDevKit_home/builds/717364651 >>> >>> On 8/27/20 1:44 PM, Sven Van Caekenberghe wrote: >>>> Hmm, this is going to be a hard one. >>>> >>>> SmalltalkHub got optimised in Pharo, consider >>>> >>>> MCHttpRepository>>#parseFileNamesFromStream: aStream >>>> | names fullName | >>>> names := OrderedCollection new. >>>> [aStream atEnd] whileFalse: >>>> [[aStream upTo: $<. {$a. $A. nil} includes: aStream next] >>>> whileFalse. >>>> aStream upTo: $". >>>> aStream atEnd ifFalse: [ >>>> fullName := aStream upTo: $". >>>> names add: fullName urlDecoded ]]. >>>> ^ names >>>> >>>> vs. >>>> >>>> MCSmalltalkHubRepository>>#parseFileNamesFromStream: >>>> aNewLineDelimitedString >>>> ^ aNewLineDelimitedString >>>> ifNil: [ ^ OrderedCollection new ] >>>> ifNotNil: [ aNewLineDelimitedString substrings: String crlf ] >>>> >>>> In the old server code there was probably a way to detect what kind of >>>> client was making the request to determine how to respond. I am not sure a >>>> static server can do that (it is the format=raw query parameter, see >>>> MCSmalltalkHubRepository>>#loadAllFileNames). I also believe GZIP >>>> compressed files were returned in the optimised case. >>>> >>>> BTW, there exists code to generate the listing in >>>> >>>> ZnMonticelloRepository>>#repositoryListing >>>> ^ ZnHtmlOutputStream streamContents: [ :html | >>>> html page: 'Monticello Repository' do: [ >>>> html tag: #ul do: [ >>>> self mczEntries do: [ :each | >>>> html tag: #li do: [ >>>> html >>>> tag: #a >>>> attributes: { #href. >>>> each } >>>> with: each ] ] ] ] ] >>>> >>>> Sven >>>> >>>>> On 27 Aug 2020, at 22:29, Dale Henrichs >>>>> <dale.henri...@gemtalksystems.com> wrote: >>>>> >>>>> My guess is lies in the difference in the payload returned. >>>>> >>>>> http://www.squeaksource.com/MooseSQL/ produces a html page: >>>>> >>>>> <pnioijaecacnfagp.png> >>>>> >>>>> and the static smalltalkhub site does not: >>>>> >>>>> <lepkhlgeiolajoki.png> >>>>> >>>>> I think that all of the monticello web sites return an html web page >>>>> listing of packages and presumably the static site should produce html >>>>> ... I'm sure that the dynamic version of smalltalkhub produced html pages >>>>> as well and for now we are caught between a rock and a hard place ... the >>>>> dynamic site is flakey and the static site breaks existing Monticello >>>>> package list reading code:) >>>>> >>>>> Dale >>>>> >>>>> On 8/27/20 1:04 PM, Dale Henrichs wrote: >>>>>> As I've started digging around, I have found that this url[1] does >>>>>> produce the correct list of mcz files in the browser, but is currently >>>>>> failing to produce any list at all in GLASS ... so there is a different >>>>>> mystery ... other than the fact that this url[1] was working prior(?) to >>>>>> the switchover (if in fact the DNS has propagated to all the right >>>>>> spots) and has been working for all of the other http Monticello >>>>>> repositories for over a decade:) >>>>>> >>>>>> I will continue digging ... >>>>>> >>>>>> Dale >>>>>> >>>>>> [1] http://smalltalkhub.com/mc/Seaside/Seaside30LGPL/main >>>>>> >>>>>> On 8/27/20 12:48 PM, Dale Henrichs wrote: >>>>>>> Christophe, >>>>>>> >>>>>>> There is a new(?) problem that we are having that has been reported in >>>>>>> this thread on the GLASS list[1] where I am able to successfully >>>>>>> download an mcz file [2], but get a `Not Found` error when I try to >>>>>>> list the mcz files in a project[3]. The missing mcz list is consistent >>>>>>> with the failed builds that I am now seeing on travis [4] and that are >>>>>>> being reported by Brodbeck[1]. I have yet to get to a point where I can >>>>>>> debug the problems directly and determine what is actually going on and >>>>>>> of course I can't tell if these are the results of slow DNS propagation. >>>>>>> >>>>>>> In this case [2][3], the list of file shows up on the dynamic(?) site: >>>>>>> >>>>>>> <popmbnhcnehhanno.png> >>>>>>> >>>>>>> and can be downloaded by pressing the download for the selected mcz >>>>>>> file, but the missing list of packages[3] is likely to be the root >>>>>>> cause of the problem. >>>>>>> >>>>>>> Dale >>>>>>> >>>>>>> [1] >>>>>>> http://forum.world.st/SmalltalkHub-packages-not-accessible-tt5120932.html >>>>>>> [2] >>>>>>> http://smalltalkhub.com/mc/Seaside/Seaside30LGPL/main/Seaside-Swazoo-jf.19.mcz >>>>>>> [3] http://smalltalkhub.com/mc/Seaside/Seaside30LGPL >>>>>>> [4] >>>>>>> https://travis-ci.org/github/GsDevKit/GsDevKit_home/jobs/721523221#L2411 >>>>>>> >>>>>>> On 8/27/20 5:36 AM, Christophe Demarey wrote: >>>>>>>> Hi Dale, >>>>>>>> >>>>>>>> Sorry, I did not see your message before. >>>>>>>> Yesterday, I switched smalltalkhub to the static version (a bit >>>>>>>> earlier than announced) to avoid frequent downtimes we had with >>>>>>>> smalltalkhub. >>>>>>>> I did not measure but downloads should now be faster and reliable. >>>>>>>> >>>>>>>> Do not hesitate to ping if you have any problem. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Christophe >>>>>>>> >>>>>>>>> Le 26 août 2020 à 18:12, Dale Henrichs >>>>>>>>> <dale.henri...@gemtalksystems.com> a écrit : >>>>>>>>> >>>>>>>>> Well, I haven't see any email response, but today (after two days of >>>>>>>>> brokenness), >>>>>>>>> http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz >>>>>>>>> is now downloading successfully, so THANK YOU, to whoever fixed the >>>>>>>>> problem! >>>>>>>>> >>>>>>>>> Dale >>>>>>>>> >>>>>>>>> On 8/25/20 9:02 AM, Dale Henrichs wrote: >>>>>>>>>> SmalltalkHub mcz downloads are broken ... looks like a mongo server >>>>>>>>>> has gone down? .... I ran into this problem running production tests >>>>>>>>>> yesterday and today I find that while the smalltalkhub site is up, I >>>>>>>>>> cannot download an mcz file, using this url: >>>>>>>>>> http://smalltalkhub.com/mc/dkh/metacello/main/Metacello-Base-dkh.109.mcz. >>>>>>>>>> >>>>>>>>>> If you are not going to keep the current smalltalkhub site >>>>>>>>>> functional, why don't you switch to the static site and give those >>>>>>>>>> of us who DEPEND upon static access to mcz files a reliable site to >>>>>>>>>> connect to ... I have plans to move completely away from mcz files, >>>>>>>>>> but I didn't plan on doing that this week ... and frankly I don't >>>>>>>>>> have the cycles to do that ... right now ... >>>>>>>>>> >>>>>>>>>> Here's a screenshot of a manual login and navigation to the mcz file >>>>>>>>>> that is failing to download: >>>>>>>>>> >>>>>>>>>> <jchancldefkbdajd.png> >>>>>>>>>> >>>>>>>>>> And when I press the `Download .mcz` button, I get the following >>>>>>>>>> "response" after a delay: >>>>>>>>>> >>>>>>>>>> <lnonccpgaamnnobg.png> >>>>>>>>>> >> >
