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:
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.henrichs@gemtalksystems.com
mailto:dale.henrichs@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>
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:
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.henrichs@gemtalksystems.com
mailto:dale.henrichs@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>
My guess is lies in the difference in the payload returned.
http://www.squeaksource.com/MooseSQL/ produces a html page:
and the static smalltalkhub site does not:
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:
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.henrichs@gemtalksystems.com
mailto:dale.henrichs@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>
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.henrichs@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.henrichs@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>
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.henrichs@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.henrichs@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>
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.henrichs@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.henrichs@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.henrichs@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>
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.henrichs@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.henrichs@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.henrichs@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>
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.henrichs@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.henrichs@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.henrichs@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.henrichs@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>
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?
Regards,
Christophe
Le 28 août 2020 à 09:37, Christophe Demarey christophe.demarey@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.henrichs@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.henrichs@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.henrichs@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.henrichs@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>
On 28 Aug 2020, at 10:13, Christophe Demarey christophe.demarey@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.demarey@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.henrichs@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.henrichs@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.henrichs@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.henrichs@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>