[Pharo-project] Smalltalkhub news
Nicolas and I improved on last Friday the interaction with Smalltalkhub - new repository type for Pharo2.0 - cached allFileNames on server side - response time reduction: 500ms => 12ms - added new raw filenames format: - see: http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw - cuts the transferred data size in half - reduces parsing overhead on image-side - fixed a bug in the HTTPRepository where the download would take took long - testing if a mcz file exists is now a 10ms action instead of >1s with the last three fixes applied we have cropped down the response time from the server to ~15ms. All in all this will make Smalltalkhub a super-fast Monticello experience! enjoy! camillo
Cool cool cool :) Now the website need a "Import from" part to mmigrate from ss3/squeaksource to SmalltalkHub :) Ben On Sep 16, 2012, at 1:18 PM, Camillo Bruni wrote:
Nicolas and I improved on last Friday the interaction with Smalltalkhub - new repository type for Pharo2.0 - cached allFileNames on server side - response time reduction: 500ms => 12ms - added new raw filenames format: - see: http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw - cuts the transferred data size in half - reduces parsing overhead on image-side - fixed a bug in the HTTPRepository where the download would take took long - testing if a mcz file exists is now a 10ms action instead of >1s
with the last three fixes applied we have cropped down the response time from the server to ~15ms. All in all this will make Smalltalkhub a super-fast Monticello experience!
enjoy! camillo
Very cool. I'll give it a shot. 2012/9/16 Benjamin <benjamin.vanryseghem.pharo@gmail.com>:
Cool cool cool :)
Now the website need a "Import from" part to mmigrate from ss3/squeaksource to SmalltalkHub :)
Ben
On Sep 16, 2012, at 1:18 PM, Camillo Bruni wrote:
Nicolas and I improved on last Friday the interaction with Smalltalkhub - new repository type for Pharo2.0 - cached allFileNames on server side - response time reduction: 500ms => 12ms - added new raw filenames format: - see: http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw - cuts the transferred data size in half - reduces parsing overhead on image-side - fixed a bug in the HTTPRepository where the download would take took long - testing if a mcz file exists is now a 10ms action instead of >1s
with the last three fixes applied we have cropped down the response time from the server to ~15ms. All in all this will make Smalltalkhub a super-fast Monticello experience!
enjoy! camillo
Nice work guys. Just, one question, I read that Smalltalkhub is using MongoDB. Is that right? How do you do that? There is a Smalltalk port or something for MongoDB. Cheers. On Sep 16, 2012, at 8:18 , Camillo Bruni <camillobruni@gmail.com> wrote:
Nicolas and I improved on last Friday the interaction with Smalltalkhub - new repository type for Pharo2.0 - cached allFileNames on server side - response time reduction: 500ms => 12ms - added new raw filenames format: - see: http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw - cuts the transferred data size in half - reduces parsing overhead on image-side - fixed a bug in the HTTPRepository where the download would take took long - testing if a mcz file exists is now a 10ms action instead of >1s
with the last three fixes applied we have cropped down the response time from the server to ~15ms. All in all this will make Smalltalkhub a super-fast Monticello experience!
enjoy! camillo
driver: http://squeaksource.com/MongoTalk/ mapper: http://smalltalkhub.com/#!/~estebanlm/Voyage cheers, Esteban On Sep 16, 2012, at 3:15 PM, Oscar E A Callaú <oalvarez@dcc.uchile.cl> wrote:
Nice work guys.
Just, one question, I read that Smalltalkhub is using MongoDB. Is that right? How do you do that? There is a Smalltalk port or something for MongoDB.
Cheers.
On Sep 16, 2012, at 8:18 , Camillo Bruni <camillobruni@gmail.com> wrote:
Nicolas and I improved on last Friday the interaction with Smalltalkhub - new repository type for Pharo2.0 - cached allFileNames on server side - response time reduction: 500ms => 12ms - added new raw filenames format: - see: http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw - cuts the transferred data size in half - reduces parsing overhead on image-side - fixed a bug in the HTTPRepository where the download would take took long - testing if a mcz file exists is now a 10ms action instead of >1s
with the last three fixes applied we have cropped down the response time from the server to ~15ms. All in all this will make Smalltalkhub a super-fast Monticello experience!
enjoy! camillo
Excellent! Stef On Sep 16, 2012, at 1:18 PM, Camillo Bruni wrote:
Nicolas and I improved on last Friday the interaction with Smalltalkhub - new repository type for Pharo2.0 - cached allFileNames on server side - response time reduction: 500ms => 12ms - added new raw filenames format: - see: http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw - cuts the transferred data size in half - reduces parsing overhead on image-side - fixed a bug in the HTTPRepository where the download would take took long - testing if a mcz file exists is now a 10ms action instead of >1s
with the last three fixes applied we have cropped down the response time from the server to ~15ms. All in all this will make Smalltalkhub a super-fast Monticello experience!
enjoy! camillo
Good work ! Where can the code be found/seen ? I am especially interested in the last point. Has it something to do with (using) Zn ? -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill On 16 Sep 2012, at 13:18, Camillo Bruni <camillobruni@gmail.com> wrote:
Nicolas and I improved on last Friday the interaction with Smalltalkhub - new repository type for Pharo2.0 - cached allFileNames on server side - response time reduction: 500ms => 12ms - added new raw filenames format: - see: http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw - cuts the transferred data size in half - reduces parsing overhead on image-side - fixed a bug in the HTTPRepository where the download would take took long - testing if a mcz file exists is now a 10ms action instead of >1s
with the last three fixes applied we have cropped down the response time from the server to ~15ms. All in all this will make Smalltalkhub a super-fast Monticello experience!
enjoy! camillo
On 2012-09-16, at 21:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Good work !
Where can the code be found/seen ?
all in the latest pharo SmalltalkHubRepository browse.
I am especially interested in the last point. Has it something to do with (using) Zn ?
yes, we basically did a HEAD request and returned false on 404, however Zn does 3 or so retries, and thus makes everything slow :). I don't know what the side-effects are, but we reduce the retryCount to 0, to get low response times. I thought that upon a valid 404 response there is no retry needed? (but I guess I miss something here :P)
On 16 Sep 2012, at 21:56, Camillo Bruni <camillobruni@gmail.com> wrote:
I am especially interested in the last point. Has it something to do with (using) Zn ?
yes, we basically did a HEAD request and returned false on 404, however Zn does 3 or so retries, and thus makes everything slow :). I don't know what the side-effects are, but we reduce the retryCount to 0, to get low response times.
I thought that upon a valid 404 response there is no retry needed? (but I guess I miss something here :P)
The reason ZnClient keeps on retrying on 404 is because you probably had #enforceHttpSuccess true as part of #systemPolicy and only 2xx response are considered a success. But this is an interesting use case: basically 404 is a valid response here. I'll have to think about that so more. Thanks for pushing this and letting me know. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 2012-09-16, at 22:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 16 Sep 2012, at 21:56, Camillo Bruni <camillobruni@gmail.com> wrote:
I am especially interested in the last point. Has it something to do with (using) Zn ?
yes, we basically did a HEAD request and returned false on 404, however Zn does 3 or so retries, and thus makes everything slow :). I don't know what the side-effects are, but we reduce the retryCount to 0, to get low response times.
I thought that upon a valid 404 response there is no retry needed? (but I guess I miss something here :P)
The reason ZnClient keeps on retrying on 404 is because you probably had #enforceHttpSuccess true as part of #systemPolicy and only 2xx response are considered a success.
ah right, that will do it!
But this is an interesting use case: basically 404 is a valid response here. I'll have to think about that so more.
well now I know, so I'm fine by manually changing it :P
yeah, i think it is pointless to retry if you get 404 "not found" response. Usually (of course if web server conforms to HTTP RFC), this means that requested resource is really not there and will not be there anytime soon :) On 16 September 2012 23:10, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2012-09-16, at 22:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 16 Sep 2012, at 21:56, Camillo Bruni <camillobruni@gmail.com> wrote:
I am especially interested in the last point. Has it something to do with (using) Zn ?
yes, we basically did a HEAD request and returned false on 404, however Zn does 3 or so retries, and thus makes everything slow :). I don't know what the side-effects are, but we reduce the retryCount to 0, to get low response times.
I thought that upon a valid 404 response there is no retry needed? (but I guess I miss something here :P)
The reason ZnClient keeps on retrying on 404 is because you probably had #enforceHttpSuccess true as part of #systemPolicy and only 2xx response are considered a success.
ah right, that will do it!
But this is an interesting use case: basically 404 is a valid response here. I'll have to think about that so more.
well now I know, so I'm fine by manually changing it :P
-- Best regards, Igor Stasenko.
On 17 Sep 2012, at 11:05, Igor Stasenko <siguctua@gmail.com> wrote:
yeah, i think it is pointless to retry if you get 404 "not found" response. Usually (of course if web server conforms to HTTP RFC), this means that requested resource is really not there and will not be there anytime soon :)
I decided to only do retries on NetworkError, ZnParseError for now, we'll see how it goes. The ifFail block will be triggered on any Error.
On 16 September 2012 23:10, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2012-09-16, at 22:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 16 Sep 2012, at 21:56, Camillo Bruni <camillobruni@gmail.com> wrote:
I am especially interested in the last point. Has it something to do with (using) Zn ?
yes, we basically did a HEAD request and returned false on 404, however Zn does 3 or so retries, and thus makes everything slow :). I don't know what the side-effects are, but we reduce the retryCount to 0, to get low response times.
I thought that upon a valid 404 response there is no retry needed? (but I guess I miss something here :P)
The reason ZnClient keeps on retrying on 404 is because you probably had #enforceHttpSuccess true as part of #systemPolicy and only 2xx response are considered a success.
ah right, that will do it!
But this is an interesting use case: basically 404 is a valid response here. I'll have to think about that so more.
well now I know, so I'm fine by manually changing it :P
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 2012-09-17, at 11:18, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 17 Sep 2012, at 11:05, Igor Stasenko <siguctua@gmail.com> wrote:
yeah, i think it is pointless to retry if you get 404 "not found" response. Usually (of course if web server conforms to HTTP RFC), this means that requested resource is really not there and will not be there anytime soon :)
I decided to only do retries on NetworkError, ZnParseError for now, we'll see how it goes. The ifFail block will be triggered on any Error.
sounds reasonable :)
Is there a Metacello configuration for it? I'm trying to load it by hand but guessing the dependencies is tricky for me. On 16/09/12 12:56, Camillo Bruni wrote:
On 2012-09-16, at 21:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Good work !
Where can the code be found/seen ?
all in the latest pharo SmalltalkHubRepository browse.
I am especially interested in the last point. Has it something to do with (using) Zn ?
yes, we basically did a HEAD request and returned false on 404, however Zn does 3 or so retries, and thus makes everything slow :). I don't know what the side-effects are, but we reduce the retryCount to 0, to get low response times.
I thought that upon a valid 404 response there is no retry needed? (but I guess I miss something here :P)
-- http://tulipemoutarde.be CA: +1 778 558 3225 BE: +32 65 709 131
No, there's no configuration yet. Nico On Wed, 19 Sep 2012 15:05:10 -0700, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
Is there a Metacello configuration for it? I'm trying to load it by hand but guessing the dependencies is tricky for me.
On 16/09/12 12:56, Camillo Bruni wrote:
On 2012-09-16, at 21:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Good work !
Where can the code be found/seen ?
all in the latest pharo SmalltalkHubRepository browse.
I am especially interested in the last point. Has it something to do with (using) Zn ?
yes, we basically did a HEAD request and returned false on 404, however Zn does 3 or so retries, and thus makes everything slow :). I don't know what the side-effects are, but we reduce the retryCount to 0, to get low response times.
I thought that upon a valid 404 response there is no retry needed? (but I guess I miss something here :P)
-- http://tulipemoutarde.be CA: +1 778 558 3225 BE: +32 65 709 131
-- Nicolas Petton http://nicolas-petton.fr
Ok! I've managed to load it but haven't tried to run it (yet). I almost gave up before realising that KO is the prefix used by Kalingrad :) It's cool to browse a real project using Seaside and Mongo. The way Smalltalkhub maps Mongo and Smalltalk objects is interesting. It seems to be more explicit than the Voyage approach. Have you considered to use Voyage or to extract the smalltalkhub mapper to a indenpendent package (a bit like mongoid, moped and origin in ruby[1])? Anyway, thanks for open sourcing it! Fa [1]http://mongoid.org/en/mongoid/index.html On 20/09/12 03:32, Nicolas Petton wrote:
No, there's no configuration yet.
Nico
On Wed, 19 Sep 2012 15:05:10 -0700, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
Is there a Metacello configuration for it? I'm trying to load it by hand but guessing the dependencies is tricky for me.
On 16/09/12 12:56, Camillo Bruni wrote:
On 2012-09-16, at 21:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Good work !
Where can the code be found/seen ?
all in the latest pharo SmalltalkHubRepository browse.
I am especially interested in the last point. Has it something to do with (using) Zn ?
yes, we basically did a HEAD request and returned false on 404, however Zn does 3 or so retries, and thus makes everything slow :). I don't know what the side-effects are, but we reduce the retryCount to 0, to get low response times.
I thought that upon a valid 404 response there is no retry needed? (but I guess I miss something here :P)
Yes, in fact with Esteban we thought about merging our work or maybe I will drop my layer and use Voyage. Nico On Thu, 20 Sep 2012 10:30:30 -0700, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
Ok!
I've managed to load it but haven't tried to run it (yet). I almost gave up before realising that KO is the prefix used by Kalingrad :)
It's cool to browse a real project using Seaside and Mongo. The way Smalltalkhub maps Mongo and Smalltalk objects is interesting. It seems to be more explicit than the Voyage approach. Have you considered to use Voyage or to extract the smalltalkhub mapper to a indenpendent package (a bit like mongoid, moped and origin in ruby[1])?
Anyway, thanks for open sourcing it!
Fa
[1]http://mongoid.org/en/mongoid/index.html
On 20/09/12 03:32, Nicolas Petton wrote:
No, there's no configuration yet.
Nico
On Wed, 19 Sep 2012 15:05:10 -0700, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
Is there a Metacello configuration for it? I'm trying to load it by hand but guessing the dependencies is tricky for me.
On 16/09/12 12:56, Camillo Bruni wrote:
On 2012-09-16, at 21:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Good work !
Where can the code be found/seen ?
all in the latest pharo SmalltalkHubRepository browse.
I am especially interested in the last point. Has it something to do with (using) Zn ?
yes, we basically did a HEAD request and returned false on 404, however Zn does 3 or so retries, and thus makes everything slow :). I don't know what the side-effects are, but we reduce the retryCount to 0, to get low response times.
I thought that upon a valid 404 response there is no retry needed? (but I guess I miss something here :P)
-- Nicolas Petton http://nicolas-petton.fr
in fact, I already dropped old Voyage session cache for the one in SmalltalkHub, which was cooler than mine :) now is turn to Nico to check what can he use from Voyage, and if that makes sense ;) Esteban On Sep 21, 2012, at 11:05 AM, Nicolas Petton <petton.nicolas@gmail.com> wrote:
Yes, in fact with Esteban we thought about merging our work or maybe I will drop my layer and use Voyage.
Nico
On Thu, 20 Sep 2012 10:30:30 -0700, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
Ok!
I've managed to load it but haven't tried to run it (yet). I almost gave up before realising that KO is the prefix used by Kalingrad :)
It's cool to browse a real project using Seaside and Mongo. The way Smalltalkhub maps Mongo and Smalltalk objects is interesting. It seems to be more explicit than the Voyage approach. Have you considered to use Voyage or to extract the smalltalkhub mapper to a indenpendent package (a bit like mongoid, moped and origin in ruby[1])?
Anyway, thanks for open sourcing it!
Fa
[1]http://mongoid.org/en/mongoid/index.html
On 20/09/12 03:32, Nicolas Petton wrote:
No, there's no configuration yet.
Nico
On Wed, 19 Sep 2012 15:05:10 -0700, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
Is there a Metacello configuration for it? I'm trying to load it by hand but guessing the dependencies is tricky for me.
On 16/09/12 12:56, Camillo Bruni wrote:
On 2012-09-16, at 21:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Good work !
Where can the code be found/seen ?
all in the latest pharo SmalltalkHubRepository browse.
I am especially interested in the last point. Has it something to do with (using) Zn ?
yes, we basically did a HEAD request and returned false on 404, however Zn does 3 or so retries, and thus makes everything slow :). I don't know what the side-effects are, but we reduce the retryCount to 0, to get low response times.
I thought that upon a valid 404 response there is no retry needed? (but I guess I miss something here :P)
-- Nicolas Petton http://nicolas-petton.fr
I really like the abstraction that Voyage provides. We could check if it would make sense to use it for SmalltalkHub. I really hate duplicated efforts. Nico On Fri, 21 Sep 2012 11:11:33 +0200, Esteban Lorenzano <estebanlm@gmail.com> wrote:
in fact, I already dropped old Voyage session cache for the one in SmalltalkHub, which was cooler than mine :) now is turn to Nico to check what can he use from Voyage, and if that makes sense ;)
Esteban
On Sep 21, 2012, at 11:05 AM, Nicolas Petton <petton.nicolas@gmail.com> wrote:
Yes, in fact with Esteban we thought about merging our work or maybe I will drop my layer and use Voyage.
Nico
On Thu, 20 Sep 2012 10:30:30 -0700, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
Ok!
I've managed to load it but haven't tried to run it (yet). I almost gave up before realising that KO is the prefix used by Kalingrad :)
It's cool to browse a real project using Seaside and Mongo. The way Smalltalkhub maps Mongo and Smalltalk objects is interesting. It seems to be more explicit than the Voyage approach. Have you considered to use Voyage or to extract the smalltalkhub mapper to a indenpendent package (a bit like mongoid, moped and origin in ruby[1])?
Anyway, thanks for open sourcing it!
Fa
[1]http://mongoid.org/en/mongoid/index.html
On 20/09/12 03:32, Nicolas Petton wrote:
No, there's no configuration yet.
Nico
On Wed, 19 Sep 2012 15:05:10 -0700, Francois Stephany <tulipe.moutarde@gmail.com> wrote:
Is there a Metacello configuration for it? I'm trying to load it by hand but guessing the dependencies is tricky for me.
On 16/09/12 12:56, Camillo Bruni wrote:
On 2012-09-16, at 21:29, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Good work !
Where can the code be found/seen ?
all in the latest pharo SmalltalkHubRepository browse.
I am especially interested in the last point. Has it something to do with (using) Zn ?
yes, we basically did a HEAD request and returned false on 404, however Zn does 3 or so retries, and thus makes everything slow :). I don't know what the side-effects are, but we reduce the retryCount to 0, to get low response times.
I thought that upon a valid 404 response there is no retry needed? (but I guess I miss something here :P)
-- Nicolas Petton http://nicolas-petton.fr
-- Nicolas Petton http://nicolas-petton.fr
participants (10)
-
Benjamin -
Camillo Bruni -
Esteban Lorenzano -
Francois Stephany -
Igor Stasenko -
Nicolas Petton -
Oscar E A Callaú -
phil＠highoctane.be -
Stéphane Ducasse -
Sven Van Caekenberghe