> On 28 Aug 2020, at 10:13, Christophe Demarey <christophe.dema...@inria.fr> 
> wrote:
> 
> Smalltalkhub is now to able to distinguish between raw and not raw mcz 
> listing requests.
> Ex: 
>       http://smalltalkhub.com/mc/Seaside/Seaside30LGPL/main?format=raw
>       http://smalltalkhub.com/mc/Seaside/Seaside30LGPL/main/
> 
> I already use the apache directory index for another page so I will not be 
> able to modify this one. I guess the current index will «  not work » because 
> glass expect some HTML structure.
> Could you confirm and tell me what is the expected structure?

See my earlier mail with code.

> Regards,
> Christophe
> 
>> Le 28 août 2020 à 09:37, Christophe Demarey <christophe.dema...@inria.fr> a 
>> écrit :
>> 
>> 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>
>>>>>>>>>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 


Reply via email to