Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

[Dale Henrichs]

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  
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  
wrote:

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://

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

[Sven Van Caekenberghe]

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  
> 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  
>>> wrote:
>>> 
>>> 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/Sma

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

[Dale Henrichs]

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  
wrote:

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  a 
écrit :

We

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

[Sven Van Caekenberghe]

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  
> wrote:
> 
> 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  
> a écrit :
> 
> Well, I haven't see any email response, but today (after two days of 
> brokenness), 
> http://smalltalkhub.com/mc/dkh/

Re: [Pharo-dev] Why copy and pasting class definition invokes the class parser?

[Martin McClure]

This is not definite knowledge, but some code I was digging through 
yesterday suggests that it *might* be for syntax highlighting of the 
class definition.


Regards,
-Martin

On 8/27/20 11:16 AM, Stéphane Ducasse wrote:

Hi

I’m working on a nice class definition and I’m exploring….
And I wonder why copy and pasting class definition invokes the class 
parser?


S

Stéphane Ducasse
http://stephane.ducasse.free.fr / http://www.pharo.org
03 59 35 87 52
Assistant: Aurore Dalle
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France

[Pharo-dev] Why copy and pasting class definition invokes the class parser?

[Stéphane Ducasse]

Hi 

I’m working on a nice class definition and I’m exploring….
And I wonder why copy and pasting class definition invokes the class parser?

S

Stéphane Ducasse
http://stephane.ducasse.free.fr / http://www.pharo.org 
03 59 35 87 52
Assistant: Aurore Dalle 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

[Esteban Maringolo]

Hi Cristophe,

I was referring to exactly what you mention you did to preserve the
load of dependencies.
But since it failed me, and also to Dale and others I know, I thought
it was not the case that such consideration was in place.

Thanks!

Esteban A. Maringolo

On Thu, Aug 27, 2020 at 11:02 AM Christophe Demarey
 wrote:
>
> Hi  Esteban,
>
> > Le 27 août 2020 à 15:14, Esteban Maringolo  a écrit :
> >
> > Again, I don't know what software is serving SmalltalkHub HTTP
> > requests, but can't we make a redirect or rewrite rule in the HTTP
> > request to transparently answer the proper resource when requested?
> >
> > It would be simply removing the `/mc` and changing the hostname.
> >
> > This way Baselines and other dependencies don't have to be rewritten
> > to continue working.
>
> I do not get what you mean.
> The static version rewrites old / used urls so that all URLs that are used in 
> baselines or whatever are still served transparently.
> We took care of this to do not break the load of old piece of software.
>
> Regards,
> Christophe.

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

[Christophe Demarey]

Hi  Esteban,

> Le 27 août 2020 à 15:14, Esteban Maringolo  a écrit :
> 
> Again, I don't know what software is serving SmalltalkHub HTTP
> requests, but can't we make a redirect or rewrite rule in the HTTP
> request to transparently answer the proper resource when requested?
> 
> It would be simply removing the `/mc` and changing the hostname.
> 
> This way Baselines and other dependencies don't have to be rewritten
> to continue working.

I do not get what you mean.
The static version rewrites old / used urls so that all URLs that are used in 
baselines or whatever are still served transparently.
We took care of this to do not break the load of old piece of software.

Regards,
Christophe.

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

[Christophe Demarey]

Hi Sven,

> Le 27 août 2020 à 14:47, Sven Van Caekenberghe  a écrit :
> 
> 
> 
>> On 27 Aug 2020, at 14:36, 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.
> 
> Are you sure ?
> 
> For me, http://smalltalkhub.com is different from 
> http://static.smalltalkhub.com

Yes, there are DNS caches probably stil referring to the non-static version.
Maybe you can try this: 
https://coolestguidesontheplanet.com/clear-the-local-dns-cache-in-osx/

Regards,
Christophe.

[Pharo-dev] Smalltalkhub is now in archive mode (static version)

[Christophe Demarey]

Hi all,

Since May, Smalltalk is in read-only mode, allowing people to get back their 
data and move it to another forge if needed.
We had several unexpected downtimes with the deprecated version of Smalltalkub 
(different software stack due to server migration).
To enhance the user experience, we put the static version of Smalltalkhub «  
SmalltalkHub archive » on-line as the official http://smalltalkhub.com service.

It was already announced that it will be done in November but we decided to do 
it earlier because it improves the current state:
- faster and reliable downloads from smalltalkhub.com (mcz files are no longer 
stored in a Mongo DB but served as static files)
- Smalltalkhub archive still allows to list projects, search for a project, see 
packages, contributors, commits
- deprecated version of smalltalkhub is still on-line until November at 
http://deprecated.smalltalkhub.com/.

So you have the best of the 2 versions.

Regards,
The Pharo consortium team.

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

[Esteban Maringolo]

Again, I don't know what software is serving SmalltalkHub HTTP
requests, but can't we make a redirect or rewrite rule in the HTTP
request to transparently answer the proper resource when requested?

It would be simply removing the `/mc` and changing the hostname.

This way Baselines and other dependencies don't have to be rewritten
to continue working.

Regards!

Esteban A. Maringolo

On Thu, Aug 27, 2020 at 9:47 AM Sven Van Caekenberghe  wrote:
>
>
>
> > On 27 Aug 2020, at 14:36, 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.
>
> Are you sure ?
>
> For me, http://smalltalkhub.com is different from 
> http://static.smalltalkhub.com
>
> And the download links
>
> http://www.smalltalkhub.com/mc/SvenVanCaekenberghe/ZincHTTPComponents/main/ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.120.mcz
>
> and
>
> http://static.smalltalkhub.com/SvenVanCaekenberghe/ZincHTTPComponents/mc/ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.120.mcz
>
> are coming from a different server.
>
> > 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  
> >> 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:
> >>>
> >>> 
> >>>
> >>> And when I press the `Download .mcz` button, I get the following 
> >>> "response" after a delay:
> >>>
> >>> 
> >>>
> >
>
>

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

[Sven Van Caekenberghe]

> On 27 Aug 2020, at 14:36, 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.

Are you sure ?

For me, http://smalltalkhub.com is different from http://static.smalltalkhub.com

And the download links

http://www.smalltalkhub.com/mc/SvenVanCaekenberghe/ZincHTTPComponents/main/ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.120.mcz

and 

http://static.smalltalkhub.com/SvenVanCaekenberghe/ZincHTTPComponents/mc/ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.120.mcz

are coming from a different server.

> 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  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:
>>> 
>>> 
>>> 
>>> And when I press the `Download .mcz` button, I get the following "response" 
>>> after a delay:
>>> 
>>> 
>>> 
> 

Re: [Pharo-dev] 'VOMongoConnectionError' when dowloading mcz from smalltalkhub.com

[Christophe Demarey]

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  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:
>> 
>> 
>> 
>> And when I press the `Download .mcz` button, I get the following "response" 
>> after a delay:
>> 
>> 
>> 

[Pharo-dev] [Pharo 9.0] Build #623: Prevent the inspector to fail on double click on an item in a collection

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #623 was: FAILURE.

The Pull Request #7188 was integrated: "Prevent the inspector to fail on double 
click on an item in a collection"
Pull request url: https://github.com/pharo-project/pharo/pull/7188

Issue Url: 
https://github.com/pharo-project/pharo/issues/inspectorDoubleClickFail
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo9.0/623/