Re: [Pharo-users] Postmark email library

[vmusulainen]

Sure!

I use pharo 2.0 (21.0)

Attempt 1.

Use http://ss3.gemstone.com/ss/postmark.html at "Getting the code/Gofer"

Gofer new
repository: 'http://ss3.gemstone.com/ss/postmark';
package: 'ConfigurationOfPostMark';
package: 'PostMark-Core';
package: 'PostMark-Tests';
load

DoIt at workspace

Result: Expection "ByteString  doesNotUnderstand: #goferReferences"

Attempt 2.

Use http://ss3.gemstone.com/ss/postmark.html at "Getting the code/Monticello
Registration"
Add repository => select package "PostMark-Core-FrancoisStephany.11", press
"Load"

Result:
"This package depends on the following classes:
  JsonObject
You must resolve these dependencies before you will be able to load these
definitions: 
  PMEmail
  addAttachment:content:contentType:
  addAttachmentAndCompress:archiveName:
  attachAndCompressFile:
  attachFile:

Select Proceed to continue, or close this window to cancel the operation."

Attempt 3.
see http://ss3.gemstone.com/ss/postmark.html/Wiki

Gofer it
  url: 'http://ss3.gemstone.com/ss/postmark';
  package: 'ConfigurationOfPostMark';
  load.
(Smalltalk at: #ConfigurationOfPostMark) project stableVersion load.

DoIt at workspace

Result: "The symbolic version #stable is not defined in
ConfigurationOfPostMark for the current platform."



--
View this message in context: 
http://forum.world.st/Postmark-email-library-tp4254680p4705729.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Postmark email library

[Stéphane Ducasse]

On Aug 30, 2013, at 9:45 AM, vmusulainen  wrote:

> Sure!
> 
> I use pharo 2.0 (21.0)
> 
> Attempt 1.
> 
> Use http://ss3.gemstone.com/ss/postmark.html at "Getting the code/Gofer"
> 
> Gofer new
>repository: 'http://ss3.gemstone.com/ss/postmark';
>package: 'ConfigurationOfPostMark';
>package: 'PostMark-Core';
>package: 'PostMark-Tests';
>load

this is the configurationOfPostmark that have the responsibility of loading the 
other packages and projects it needs.
I will try to have a look but on Smalltalkhub

Stef

> 
> DoIt at workspace
> 
> Result: Expection "ByteString  doesNotUnderstand: #goferReferences"
> 
> Attempt 2.
> 
> Use http://ss3.gemstone.com/ss/postmark.html at "Getting the code/Monticello
> Registration"
> Add repository => select package "PostMark-Core-FrancoisStephany.11", press
> "Load"
> 
> Result:
> "This package depends on the following classes:
>  JsonObject
> You must resolve these dependencies before you will be able to load these
> definitions: 
>  PMEmail
>  addAttachment:content:contentType:
>  addAttachmentAndCompress:archiveName:
>  attachAndCompressFile:
>  attachFile:
> 
> Select Proceed to continue, or close this window to cancel the operation."
> 
> Attempt 3.
> see http://ss3.gemstone.com/ss/postmark.html/Wiki
> 
> Gofer it
>  url: 'http://ss3.gemstone.com/ss/postmark';
>  package: 'ConfigurationOfPostMark';
>  load.
> (Smalltalk at: #ConfigurationOfPostMark) project stableVersion load.
> 
> DoIt at workspace
> 
> Result: "The symbolic version #stable is not defined in
> ConfigurationOfPostMark for the current platform."
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Postmark-email-library-tp4254680p4705729.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 

[Pharo-users] Benchmark

[Natalia Moskovchuk]

Hello.
I want to use the benchmarks in my GSoC project. Can somebody write or 
suggest me some resources about how could I run written benchmarks on CI 
server and get there information?


Best regards,
Natalia

Re: [Pharo-users] Benchmark

[Sebastian Tleye]

Hi Natalia,

Here you have an interesting video
http://vimeo.com/68494202

and a repository

http://smalltalkhub.com/#!/~StefanMarr/SMark


2013/8/30 Natalia Moskovchuk 

> Hello.
> I want to use the benchmarks in my GSoC project. Can somebody write or
> suggest me some resources about how could I run written benchmarks on CI
> server and get there information?
>
> Best regards,
> Natalia
>
>

[Pharo-users] [ANN] Aida 6.6 Web Framework Released

[Janko Mivšek]

Dear Pharoers,

New version of Aida/Web framework and application server
(http://www.aidaweb.si) is here with:

  - optimization on HTTP level to send first byte to the client as soon
as possible
  - streaming of HTML, specially header to get first byte out
immediately,
  - gzip compression of all text stuff like CSS, JS etc
  - CSS Sprites support added
  - internal vs. extarnal IP detection, to control access rights
accordingly
  - Geolocation support improved
  - all JS and CSS libraries updated to latest versions, Twitter
Bootstrap v3 added in parallel to v2.x

More in Release notes: http://www.aidaweb.si/release-notes-6.6

On latest Pharo 2.0 open Configuration browser, right click and Switch
repository to SqueakSource. Select Aida and Install it.

Or load Aida with this script:

  Gofer new
 squeaksource: 'MetacelloRepository';
 package: 'ConfigurationOfAida';
 load.

  (Smalltalk at: #ConfigurationOfAida) load.

Then simply open http://localhost: .

Best regards
Janko

-- 
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si

[Pharo-users] get.pharo.org and sources files

[Norbert Hartl]

Is there a url for get.pharo.org to obtain sources files? I struggle to find it!

thanks,

Norbert

Re: [Pharo-users] get.pharo.org and sources files

[Yuriy Tymchuk]

http://files.pharo.org/sources//PharoV20.sources.zip

Cheers!
Uko

On 30 серп. 2013, at 16:54, Norbert Hartl  wrote:

> Is there a url for get.pharo.org to obtain sources files? I struggle to find 
> it!
> 
> thanks,
> 
> Norbert

Re: [Pharo-users] get.pharo.org and sources files

[Marcus Denker]

On Aug 30, 2013, at 3:54 PM, Norbert Hartl  wrote:

> Is there a url for get.pharo.org to obtain sources files? I struggle to find 
> it!
> 

http://files.pharo.org/sources/

on get.pharo.org the sources file is in the vm bundle…

Marcus



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-users] [ANN] Aida 6.6 Web Framework Released

[Sven Van Caekenberghe]

On 30 Aug 2013, at 15:47, Janko Mivšek  wrote:

> Dear Pharoers,
> 
> New version of Aida/Web framework and application server
> (http://www.aidaweb.si) is here with:
> 
>  - optimization on HTTP level to send first byte to the client as soon
>as possible
>  - streaming of HTML, specially header to get first byte out
>immediately,
>  - gzip compression of all text stuff like CSS, JS etc
>  - CSS Sprites support added
>  - internal vs. extarnal IP detection, to control access rights
>accordingly
>  - Geolocation support improved
>  - all JS and CSS libraries updated to latest versions, Twitter
>Bootstrap v3 added in parallel to v2.x

Great work, thanks, Janko.

Sven

> More in Release notes: http://www.aidaweb.si/release-notes-6.6
> 
> On latest Pharo 2.0 open Configuration browser, right click and Switch
> repository to SqueakSource. Select Aida and Install it.
> 
> Or load Aida with this script:
> 
>  Gofer new
> squeaksource: 'MetacelloRepository';
> package: 'ConfigurationOfAida';
> load.
> 
>  (Smalltalk at: #ConfigurationOfAida) load.   
> 
> Then simply open http://localhost: .
> 
> Best regards
> Janko
> 
> -- 
> Janko Mivšek
> Aida/Web
> Smalltalk Web Application Server
> http://www.aidaweb.si
> 
> 

Re: [Pharo-users] get.pharo.org and sources files

[Norbert Hartl]

Am 30.08.2013 um 16:04 schrieb Sven Van Caekenberghe :

> They are included in each vm download,
> but maybe it would be good to offer them separately too.
> 
Indeed. If not I would like to know what people do after they downloaded only 
the image. 

Norbert

> On 30 Aug 2013, at 15:54, Norbert Hartl  wrote:
> 
>> Is there a url for get.pharo.org to obtain sources files? I struggle to find 
>> it!
>> 
>> thanks,
>> 
>> Norbert
> 
> 

Re: [Pharo-users] get.pharo.org and sources files

[Sven Van Caekenberghe]

They are included in each vm download,
but maybe it would be good to offer them separately too.

On 30 Aug 2013, at 15:54, Norbert Hartl  wrote:

> Is there a url for get.pharo.org to obtain sources files? I struggle to find 
> it!
> 
> thanks,
> 
> Norbert

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

[Esteban Lorenzano]

On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe  wrote:

> 
> On 29 Aug 2013, at 16:51, Esteban Lorenzano  wrote:
> 
>> hi
>> 
>> well... I've never been happy on using the UUID generator for my keys, but 
>> is the fastest option I found. 
>> There are, of course, alternatives: 
>> 
>> 1) Using your own number generator (sequential, or whatever). Problem with 
>> that is that is image based, then you need a persistence strategy... then 
>> you are slow. 
>> 2) then you can use your own procedure in mongo... with same problem than (1)
>> 3) you could use timestamp. but TimeStamps are slow :(
>> 
>> anyway... I open to ideas :)
>> 
>> in the mean time, you can check if your UUID generator is using the 
>> primitive or not. In you are not, you have more possibilities of having a 
>> collision. 
> 
> Yes, the Smalltalk code (type 4 UUID) is just a random number that is 
> computed in a complex way.
> 
> What does the primitive actually do ? Is it different ?

the primitive uses the clock ticks to produce an UUID... you shouldn't have 
repeated numbers that way... but well, it depends on the platform 
implementation also. 

> 
>> Esteban
>> 
>> On Aug 29, 2013, at 11:27 AM, Sabine Knöfel  wrote:
>> 
>>> Hi Esteban, All,
>>> 
>>> I was proceeding to seach for the reason of the problem I described
>>> yesterday.
>>> 
>>> I added some debugging code into VOMongoSerializer>>ensurePersisted: and the
>>> problem I described, did NOT occur.
>>> 
>>> That made the whole process slower...and I had an idea
>>> 
>>> I was looking into >>UUIDGenerator default makeSeed.
>>> Then I tried the following code:
>>> 
>>> |theOld theNew|
>>> 
>>> 1 timesRepeat: [ 
>>> theNew :=  UUIDGenerator default makeSeed.
>>> theNew = theOld ifTrue: [self halt].
>>> theOld := theNew]
>>> 
>>> The debugger came up! Doesn't that mean that, if the code is run very fast,
>>> there are double OIDs generated?!
>>> 
>>> In my case, the objects for country and currency are very lightweight and
>>> so, they are created very fast. Also, the error occured much more often
>>> within my fast production EC2 instance as at my (old and slow) development
>>> pc. 
>>> 
>>> Important: I work with windows and so >>makeUnixSeed returns nil... :-)
>>> 
>>> What is your opinion about that?
>>> 
>>> Sabine
>>> 
>>> 
>>> 
>>> --
>>> View this message in context: 
>>> http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705603.html
>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>> 
>> 
>> 
> 
> 

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

[Sven Van Caekenberghe]

On 30 Aug 2013, at 16:54, Esteban Lorenzano  wrote:

> 
> On Aug 30, 2013, at 4:49 PM, Sven Van Caekenberghe  wrote:
> 
>> 
>> On 30 Aug 2013, at 16:35, Esteban Lorenzano  wrote:
>> 
>>> 
>>> On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe  wrote:
>>> 
 
 On 29 Aug 2013, at 16:51, Esteban Lorenzano  wrote:
 
> hi
> 
> well... I've never been happy on using the UUID generator for my keys, 
> but is the fastest option I found. 
> There are, of course, alternatives: 
> 
> 1) Using your own number generator (sequential, or whatever). Problem 
> with that is that is image based, then you need a persistence strategy... 
> then you are slow. 
> 2) then you can use your own procedure in mongo... with same problem than 
> (1)
> 3) you could use timestamp. but TimeStamps are slow :(
> 
> anyway... I open to ideas :)
> 
> in the mean time, you can check if your UUID generator is using the 
> primitive or not. In you are not, you have more possibilities of having a 
> collision. 
 
 Yes, the Smalltalk code (type 4 UUID) is just a random number that is 
 computed in a complex way.
 
 What does the primitive actually do ? Is it different ?
>>> 
>>> the primitive uses the clock ticks to produce an UUID... you shouldn't have 
>>> repeated numbers that way... but well, it depends on the platform 
>>> implementation also. 
>> 
>> I don't like plugins because it is some much harder for everyone to look at 
>> the implementation, while everybody thinks some magic happens there, and 
>> often the truth is quite disappointing.
>> 
>> Maybe the resolution of #primUTCMicrosecondsClock is not high enough ?
> 
> I tried... not enough :(

I understand: the clock is not fast enough for the request rate. But then what 
is there against some counter as part of a UUID ?

Sorry for the discussion, I find it an interesting subject. I'll have to read a 
bit about UUIDs. Can anyone point to the plugin implementation code ?

> Esteban
> 
> On Aug 29, 2013, at 11:27 AM, Sabine Knöfel  
> wrote:
> 
>> Hi Esteban, All,
>> 
>> I was proceeding to seach for the reason of the problem I described
>> yesterday.
>> 
>> I added some debugging code into VOMongoSerializer>>ensurePersisted: and 
>> the
>> problem I described, did NOT occur.
>> 
>> That made the whole process slower...and I had an idea
>> 
>> I was looking into >>UUIDGenerator default makeSeed.
>> Then I tried the following code:
>> 
>> |theOld theNew|
>> 
>> 1 timesRepeat: [ 
>>  theNew :=  UUIDGenerator default makeSeed.
>>  theNew = theOld ifTrue: [self halt].
>>  theOld := theNew]
>> 
>> The debugger came up! Doesn't that mean that, if the code is run very 
>> fast,
>> there are double OIDs generated?!
>> 
>> In my case, the objects for country and currency are very lightweight and
>> so, they are created very fast. Also, the error occured much more often
>> within my fast production EC2 instance as at my (old and slow) 
>> development
>> pc. 
>> 
>> Important: I work with windows and so >>makeUnixSeed returns nil... :-)
>> 
>> What is your opinion about that?
>> 
>> Sabine
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705603.html
>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>> 
> 
> 
 
 
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

[Esteban Lorenzano]

On Aug 30, 2013, at 4:49 PM, Sven Van Caekenberghe  wrote:

> 
> On 30 Aug 2013, at 16:35, Esteban Lorenzano  wrote:
> 
>> 
>> On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe  wrote:
>> 
>>> 
>>> On 29 Aug 2013, at 16:51, Esteban Lorenzano  wrote:
>>> 
 hi
 
 well... I've never been happy on using the UUID generator for my keys, but 
 is the fastest option I found. 
 There are, of course, alternatives: 
 
 1) Using your own number generator (sequential, or whatever). Problem with 
 that is that is image based, then you need a persistence strategy... then 
 you are slow. 
 2) then you can use your own procedure in mongo... with same problem than 
 (1)
 3) you could use timestamp. but TimeStamps are slow :(
 
 anyway... I open to ideas :)
 
 in the mean time, you can check if your UUID generator is using the 
 primitive or not. In you are not, you have more possibilities of having a 
 collision. 
>>> 
>>> Yes, the Smalltalk code (type 4 UUID) is just a random number that is 
>>> computed in a complex way.
>>> 
>>> What does the primitive actually do ? Is it different ?
>> 
>> the primitive uses the clock ticks to produce an UUID... you shouldn't have 
>> repeated numbers that way... but well, it depends on the platform 
>> implementation also. 
> 
> I don't like plugins because it is some much harder for everyone to look at 
> the implementation, while everybody thinks some magic happens there, and 
> often the truth is quite disappointing.
> 
> Maybe the resolution of #primUTCMicrosecondsClock is not high enough ?

I tried... not enough :(

> 
 Esteban
 
 On Aug 29, 2013, at 11:27 AM, Sabine Knöfel  
 wrote:
 
> Hi Esteban, All,
> 
> I was proceeding to seach for the reason of the problem I described
> yesterday.
> 
> I added some debugging code into VOMongoSerializer>>ensurePersisted: and 
> the
> problem I described, did NOT occur.
> 
> That made the whole process slower...and I had an idea
> 
> I was looking into >>UUIDGenerator default makeSeed.
> Then I tried the following code:
> 
> |theOld theNew|
> 
> 1 timesRepeat: [ 
>   theNew :=  UUIDGenerator default makeSeed.
>   theNew = theOld ifTrue: [self halt].
>   theOld := theNew]
> 
> The debugger came up! Doesn't that mean that, if the code is run very 
> fast,
> there are double OIDs generated?!
> 
> In my case, the objects for country and currency are very lightweight and
> so, they are created very fast. Also, the error occured much more often
> within my fast production EC2 instance as at my (old and slow) development
> pc. 
> 
> Important: I work with windows and so >>makeUnixSeed returns nil... :-)
> 
> What is your opinion about that?
> 
> Sabine
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705603.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 
 
 
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

[Esteban Lorenzano]

yes, is a conversation geeky enough to be fun :)

unix:

https://github.com/pharo-project/pharovm/blob/master/platforms/unix/plugins/UUIDPlugin/sqUnixUUID.c

mac: 

https://github.com/pharo-project/pharovm/blob/master/platforms/iOS/plugins/UUIDPlugin/sqMacUUID.c

win:

https://github.com/pharo-project/pharovm/blob/master/platforms/win32/plugins/UUIDPlugin/sqWin32UUID.c

as you can see... it much depends on the platform. I would like to unify that 
(I'm doing it slowly, with certain plugins... but just when I have time, 
which is not very frequent :), and also it is not always possible)

Esteban


On Aug 30, 2013, at 5:15 PM, Sven Van Caekenberghe  wrote:

> 
> On 30 Aug 2013, at 16:54, Esteban Lorenzano  wrote:
> 
>> 
>> On Aug 30, 2013, at 4:49 PM, Sven Van Caekenberghe  wrote:
>> 
>>> 
>>> On 30 Aug 2013, at 16:35, Esteban Lorenzano  wrote:
>>> 
 
 On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe  wrote:
 
> 
> On 29 Aug 2013, at 16:51, Esteban Lorenzano  wrote:
> 
>> hi
>> 
>> well... I've never been happy on using the UUID generator for my keys, 
>> but is the fastest option I found. 
>> There are, of course, alternatives: 
>> 
>> 1) Using your own number generator (sequential, or whatever). Problem 
>> with that is that is image based, then you need a persistence 
>> strategy... then you are slow. 
>> 2) then you can use your own procedure in mongo... with same problem 
>> than (1)
>> 3) you could use timestamp. but TimeStamps are slow :(
>> 
>> anyway... I open to ideas :)
>> 
>> in the mean time, you can check if your UUID generator is using the 
>> primitive or not. In you are not, you have more possibilities of having 
>> a collision. 
> 
> Yes, the Smalltalk code (type 4 UUID) is just a random number that is 
> computed in a complex way.
> 
> What does the primitive actually do ? Is it different ?
 
 the primitive uses the clock ticks to produce an UUID... you shouldn't 
 have repeated numbers that way... but well, it depends on the platform 
 implementation also. 
>>> 
>>> I don't like plugins because it is some much harder for everyone to look at 
>>> the implementation, while everybody thinks some magic happens there, and 
>>> often the truth is quite disappointing.
>>> 
>>> Maybe the resolution of #primUTCMicrosecondsClock is not high enough ?
>> 
>> I tried... not enough :(
> 
> I understand: the clock is not fast enough for the request rate. But then 
> what is there against some counter as part of a UUID ?
> 
> Sorry for the discussion, I find it an interesting subject. I'll have to read 
> a bit about UUIDs. Can anyone point to the plugin implementation code ?
> 
>> Esteban
>> 
>> On Aug 29, 2013, at 11:27 AM, Sabine Knöfel  
>> wrote:
>> 
>>> Hi Esteban, All,
>>> 
>>> I was proceeding to seach for the reason of the problem I described
>>> yesterday.
>>> 
>>> I added some debugging code into VOMongoSerializer>>ensurePersisted: 
>>> and the
>>> problem I described, did NOT occur.
>>> 
>>> That made the whole process slower...and I had an idea
>>> 
>>> I was looking into >>UUIDGenerator default makeSeed.
>>> Then I tried the following code:
>>> 
>>> |theOld theNew|
>>> 
>>> 1 timesRepeat: [ 
>>> theNew :=  UUIDGenerator default makeSeed.
>>> theNew = theOld ifTrue: [self halt].
>>> theOld := theNew]
>>> 
>>> The debugger came up! Doesn't that mean that, if the code is run very 
>>> fast,
>>> there are double OIDs generated?!
>>> 
>>> In my case, the objects for country and currency are very lightweight 
>>> and
>>> so, they are created very fast. Also, the error occured much more often
>>> within my fast production EC2 instance as at my (old and slow) 
>>> development
>>> pc. 
>>> 
>>> Important: I work with windows and so >>makeUnixSeed returns nil... :-)
>>> 
>>> What is your opinion about that?
>>> 
>>> Sabine
>>> 
>>> 
>>> 
>>> --
>>> View this message in context: 
>>> http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705603.html
>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>> 
>> 
>> 
> 
> 
 
 
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-users] Benchmark

[Camillo Bruni]

That you just need to run it from the command line which is not related to the 
benchmark project.
Currently it seems like the ci has some troubles, so I cannot get to the 
configuration either.


On 2013-08-30, at 17:25, Natalia Moskovchuk  
wrote:

> Thanks. I already saw this video. I cann't see configuration on
> https://ci.inria.fr/rmod/job/FullTextSearch/configure . Can you share it?



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-users] Benchmark

[Natalia Moskovchuk]

Thanks. I already saw this video. I cann't see configuration on
https://ci.inria.fr/rmod/job/FullTextSearch/configure . Can you share it?




--
View this message in context: 
http://forum.world.st/Benchmark-tp4705781p4705818.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

[Sabine Knöfel]

"Sorry for the discussion"

for me, this discussion is interesting and important because I need a
solution. :-)
Thank you for the discussion!

I tried following ideas but they have been up to 4 times slower than the
original:
1) I tried to remember the last seed in an inst var of UUIDGenerator and
create it new if it was the same as the last one.
2) wait for 1 millisecond before create new seed.

As third, I tried adding a (random nextInt: 10). This did not work,
there have been also doouble numbers.

So, perhaps the counter is a good idea but is it fast?

Again, I work on windows and so I get nil as answer to makeUnixSeed.

makeSeed

| seed |
 seed := self makeUnixSeed.
seed ifNotNil: [^seed].

[seed := (Time millisecondClockValue bitAnd: 16r3FFF) bitXor: self hash.
 seed := seed bitXor: (Time totalSeconds bitAnd: 16r3FFF).
seed = 0] whileTrue: ["Try again if ever get a seed = 0"].

^seed


On Fri, Aug 30, 2013 at 5:15 PM, Sven Van Caekenberghe-2 [via Smalltalk] <
ml-node+s1294792n4705817...@n4.nabble.com> wrote:

>
> On 30 Aug 2013, at 16:54, Esteban Lorenzano <[hidden 
> email]>
> wrote:
>
> >
> > On Aug 30, 2013, at 4:49 PM, Sven Van Caekenberghe <[hidden 
> > email]>
> wrote:
> >
> >>
> >> On 30 Aug 2013, at 16:35, Esteban Lorenzano <[hidden 
> >> email]>
> wrote:
> >>
> >>>
> >>> On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe <[hidden 
> >>> email]>
> wrote:
> >>>
> 
>  On 29 Aug 2013, at 16:51, Esteban Lorenzano <[hidden 
>  email]>
> wrote:
> 
> > hi
> >
> > well... I've never been happy on using the UUID generator for my
> keys, but is the fastest option I found.
> > There are, of course, alternatives:
> >
> > 1) Using your own number generator (sequential, or whatever).
> Problem with that is that is image based, then you need a persistence
> strategy... then you are slow.
> > 2) then you can use your own procedure in mongo... with same problem
> than (1)
> > 3) you could use timestamp. but TimeStamps are slow :(
> >
> > anyway... I open to ideas :)
> >
> > in the mean time, you can check if your UUID generator is using the
> primitive or not. In you are not, you have more possibilities of having a
> collision.
> 
>  Yes, the Smalltalk code (type 4 UUID) is just a random number that is
> computed in a complex way.
> 
>  What does the primitive actually do ? Is it different ?
> >>>
> >>> the primitive uses the clock ticks to produce an UUID... you shouldn't
> have repeated numbers that way... but well, it depends on the platform
> implementation also.
> >>
> >> I don't like plugins because it is some much harder for everyone to
> look at the implementation, while everybody thinks some magic happens
> there, and often the truth is quite disappointing.
> >>
> >> Maybe the resolution of #primUTCMicrosecondsClock is not high enough ?
> >
> > I tried... not enough :(
>
> I understand: the clock is not fast enough for the request rate. But then
> what is there against some counter as part of a UUID ?
>
> Sorry for the discussion, I find it an interesting subject. I'll have to
> read a bit about UUIDs. Can anyone point to the plugin implementation code
> ?
>
> > Esteban
> >
> > On Aug 29, 2013, at 11:27 AM, Sabine Knöfel <[hidden 
> > email]>
> wrote:
> >
> >> Hi Esteban, All,
> >>
> >> I was proceeding to seach for the reason of the problem I described
> >> yesterday.
> >>
> >> I added some debugging code into
> VOMongoSerializer>>ensurePersisted: and the
> >> problem I described, did NOT occur.
> >>
> >> That made the whole process slower...and I had an idea
> >>
> >> I was looking into >>UUIDGenerator default makeSeed.
> >> Then I tried the following code:
> >>
> >> |theOld theNew|
> >>
> >> 1 timesRepeat: [
> >> theNew :=  UUIDGenerator default makeSeed.
> >> theNew = theOld ifTrue: [self halt].
> >> theOld := theNew]
> >>
> >> The debugger came up! Doesn't that mean that, if the code is run
> very fast,
> >> there are double OIDs generated?!
> >>
> >> In my case, the objects for country and currency are very
> lightweight and
> >> so, they are created very fast. Also, the error occured much more
> often
> >> within my fast production EC2 instance as at my (old and slow)
> development
> >> pc.
> >>
> >> Important: I work with windows and so >>makeUnixSeed returns nil...
> :-)
> >>
> >> What is your opinion about that?
> >>
> >> Sabine
> >>
> >>
> >>
> >> --
> >> View this message in context:
> http://forum.w

Re: [Pharo-users] Benchmark

[Clément Bera]

However benchmark on the CI are not on a dedicated machine so it is not
very reliable 


2013/8/30 Camillo Bruni 

> That you just need to run it from the command line which is not related to
> the benchmark project.
> Currently it seems like the ci has some troubles, so I cannot get to the
> configuration either.
>
>
> On 2013-08-30, at 17:25, Natalia Moskovchuk <
> natalia.moskovc...@unikernel.net> wrote:
>
> > Thanks. I already saw this video. I cann't see configuration on
> > https://ci.inria.fr/rmod/job/FullTextSearch/configure . Can you share
> it?
>
>

Re: [Pharo-users] Benchmark

[Esteban Lorenzano]

yes, it was just a proof of concept, waiting for their own dedicated machine(s)

On Aug 30, 2013, at 7:03 PM, Clément Bera  wrote:

> However benchmark on the CI are not on a dedicated machine so it is not very 
> reliable 
> 
> 
> 2013/8/30 Camillo Bruni 
> That you just need to run it from the command line which is not related to 
> the benchmark project.
> Currently it seems like the ci has some troubles, so I cannot get to the 
> configuration either.
> 
> 
> On 2013-08-30, at 17:25, Natalia Moskovchuk 
>  wrote:
> 
> > Thanks. I already saw this video. I cann't see configuration on
> > https://ci.inria.fr/rmod/job/FullTextSearch/configure . Can you share it?
> 
> 

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

[Esteban Lorenzano]

Hi, 

One idea (not sure if it will work) 

You can take 

Time primUTCMicrosecondsClock

when system start, then increase it sequentially. 
most probably that will ensure uniqueness while providing fast ids. 

but of course, that depends, you need to check in your system. 

I'm thinking on provide different ID generators for Voyage, and let people plug 
what is more convenient for them. 

(all of this happens because, unlike other db drivers, mongo does not answer 
the inserted id :( )

Esteban

On Aug 30, 2013, at 5:41 PM, Sabine Knöfel  wrote:

> So, I will wait and till then, use the solution of Jan. 
> Thank you, Jan for the file in.
> Sabine
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705821.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

[Sven Van Caekenberghe]

On 30 Aug 2013, at 16:35, Esteban Lorenzano  wrote:

> 
> On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe  wrote:
> 
>> 
>> On 29 Aug 2013, at 16:51, Esteban Lorenzano  wrote:
>> 
>>> hi
>>> 
>>> well... I've never been happy on using the UUID generator for my keys, but 
>>> is the fastest option I found. 
>>> There are, of course, alternatives: 
>>> 
>>> 1) Using your own number generator (sequential, or whatever). Problem with 
>>> that is that is image based, then you need a persistence strategy... then 
>>> you are slow. 
>>> 2) then you can use your own procedure in mongo... with same problem than 
>>> (1)
>>> 3) you could use timestamp. but TimeStamps are slow :(
>>> 
>>> anyway... I open to ideas :)
>>> 
>>> in the mean time, you can check if your UUID generator is using the 
>>> primitive or not. In you are not, you have more possibilities of having a 
>>> collision. 
>> 
>> Yes, the Smalltalk code (type 4 UUID) is just a random number that is 
>> computed in a complex way.
>> 
>> What does the primitive actually do ? Is it different ?
> 
> the primitive uses the clock ticks to produce an UUID... you shouldn't have 
> repeated numbers that way... but well, it depends on the platform 
> implementation also. 

I don't like plugins because it is some much harder for everyone to look at the 
implementation, while everybody thinks some magic happens there, and often the 
truth is quite disappointing.

Maybe the resolution of #primUTCMicrosecondsClock is not high enough ?

>>> Esteban
>>> 
>>> On Aug 29, 2013, at 11:27 AM, Sabine Knöfel  
>>> wrote:
>>> 
 Hi Esteban, All,
 
 I was proceeding to seach for the reason of the problem I described
 yesterday.
 
 I added some debugging code into VOMongoSerializer>>ensurePersisted: and 
 the
 problem I described, did NOT occur.
 
 That made the whole process slower...and I had an idea
 
 I was looking into >>UUIDGenerator default makeSeed.
 Then I tried the following code:
 
 |theOld theNew|
 
 1 timesRepeat: [ 
theNew :=  UUIDGenerator default makeSeed.
theNew = theOld ifTrue: [self halt].
theOld := theNew]
 
 The debugger came up! Doesn't that mean that, if the code is run very fast,
 there are double OIDs generated?!
 
 In my case, the objects for country and currency are very lightweight and
 so, they are created very fast. Also, the error occured much more often
 within my fast production EC2 instance as at my (old and slow) development
 pc. 
 
 Important: I work with windows and so >>makeUnixSeed returns nil... :-)
 
 What is your opinion about that?
 
 Sabine
 
 
 
 --
 View this message in context: 
 http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705603.html
 Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
 
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

[Sabine Knöfel]

So, I will wait and till then, use the solution of Jan. 
Thank you, Jan for the file in.
Sabine



--
View this message in context: 
http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705821.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Group and member with Voyage

[Esteban A. Maringolo]

Hi James,

Thanks for your response. You are right, the Pattern is quite common,
if not ubiquous in all systems.

My particular question is related with Voyage+MongoDB, and also could
apply to Magritte (given the fact Voyage "inherits" its descriptions
model).

I sucessfully implemented this pattern with ORMs using an intermediary
table for the relation, or even reifying the relation as a first class
object.
I also used the #select: technique to avoid duplication of
"responsibility" and caching at one side of the relation.
But I always did it "in memory" with no mapping et all, just plain old
smalltalk objects (POSO?) and using ORM solutions.

What I need to know now is:
1) How to do this with voyage+MongoDB
2) I want to have a two way relation, it is both members and groups
have a collection (members know their groups and viceversa). This
requires additional maintenance, but with a higher performance, and
doesn't require me to load all groups if I'm just materializing one
member.


Regards!

Esteban A. Maringolo


2013/8/30 James Foster :
> Hi Esteban,
>
> What you have described is quite common and there are a variety of ways of 
> designing this sort of object model. If you were dealing with a relational 
> database, then you would have a Group table, a Member table, and a Membership 
> table. The Membership table would have one row for each member/group pair and 
> the member ID and group ID would be the primary columns (perhaps with other 
> things like date joined, date expired, etc.). With an index on the member ID 
> and group ID, one could quickly find all the groups for a member and all the 
> members for a group, and each piece of data would exist in only one place 
> ("normalized"). One could take a similar approach with objects, having three 
> collections containing Groups, Members, and Memberships respectively. You 
> could have an accessor in Group that returned members based on a select from 
> the Memberships collection and an accessor in Member that returned groups 
> based on a select from the Memberships collection.
>
> Alternatively, if you wanted to avoid the #'select:' call in one or both 
> lookups, you can cache the respective subcollections in Group and/or Member 
> and drop the Memberships collection. If you cache in only one place (e.g., 
> each Group has a collection of Members), then you can add a method in Member 
> that does a #'select:' of Groups where a Group has the Member. If you cache 
> in both places then your getters/setters in each can update the other (with 
> the understanding that you are duplicating data to get performance 
> efficiency).
>
> Again, this problem is very common. Consider students in classes, persons 
> with addresses, persons with hobbies, etc. Your choices are basically (1) 
> three collections, no duplicates, select for both queries; (2) two 
> collections, no duplicates, cache for one query, select for the other query; 
> and (3) two collections, caches for each query. Which is preferable depends 
> on your typical sizes and lookup patterns. If performance is not an issue, 
> then start with whatever is simplest for you to code. I lean toward the three 
> collections with the lookup penalty (GemStone's ability to index collections 
> makes this approach very efficient), but if most of your lookups are from one 
> side or the other and scanning the full collection is slow, then cache in one 
> or both places.
>
> If you have a composite, the analysis is similar since Smalltalk does not 
> require static typing of variables. You just need to take care that your 
> accessors can give back the expected objects.
>
> James
>
> On Aug 29, 2013, at 6:12 PM, Esteban A. Maringolo  
> wrote:
>
>> Hi all,
>>
>> Let's say I have a class Group and a class Member.
>>
>> aGroup has many members.
>> and aMember can belong to many groups.
>>
>> What is the "proper" voyageDescription for those one to many relations?
>>
>> Should I do something extra?
>>
>> Everytime I add a member to the group, both the member and the group
>> get their references updated.
>> Now when I add a member to a group and save it, I also save the
>> member. Is there another way to avoid this?
>>
>> Any recommended practice for this?
>>
>> Next level question: What if it gets composite? it is... a Group has
>> other Groups as members :)
>>
>>
>> Regards!
>>
>> Esteban A. Maringolo
>>
>>
>
>

Re: [Pharo-users] Group and member with Voyage

[James Foster]

Hi Esteban,

What you have described is quite common and there are a variety of ways of 
designing this sort of object model. If you were dealing with a relational 
database, then you would have a Group table, a Member table, and a Membership 
table. The Membership table would have one row for each member/group pair and 
the member ID and group ID would be the primary columns (perhaps with other 
things like date joined, date expired, etc.). With an index on the member ID 
and group ID, one could quickly find all the groups for a member and all the 
members for a group, and each piece of data would exist in only one place 
("normalized"). One could take a similar approach with objects, having three 
collections containing Groups, Members, and Memberships respectively. You could 
have an accessor in Group that returned members based on a select from the 
Memberships collection and an accessor in Member that returned groups based on 
a select from the Memberships collection. 

Alternatively, if you wanted to avoid the #'select:' call in one or both 
lookups, you can cache the respective subcollections in Group and/or Member and 
drop the Memberships collection. If you cache in only one place (e.g., each 
Group has a collection of Members), then you can add a method in Member that 
does a #'select:' of Groups where a Group has the Member. If you cache in both 
places then your getters/setters in each can update the other (with the 
understanding that you are duplicating data to get performance efficiency). 

Again, this problem is very common. Consider students in classes, persons with 
addresses, persons with hobbies, etc. Your choices are basically (1) three 
collections, no duplicates, select for both queries; (2) two collections, no 
duplicates, cache for one query, select for the other query; and (3) two 
collections, caches for each query. Which is preferable depends on your typical 
sizes and lookup patterns. If performance is not an issue, then start with 
whatever is simplest for you to code. I lean toward the three collections with 
the lookup penalty (GemStone's ability to index collections makes this approach 
very efficient), but if most of your lookups are from one side or the other and 
scanning the full collection is slow, then cache in one or both places.

If you have a composite, the analysis is similar since Smalltalk does not 
require static typing of variables. You just need to take care that your 
accessors can give back the expected objects.

James

On Aug 29, 2013, at 6:12 PM, Esteban A. Maringolo  wrote:

> Hi all,
> 
> Let's say I have a class Group and a class Member.
> 
> aGroup has many members.
> and aMember can belong to many groups.
> 
> What is the "proper" voyageDescription for those one to many relations?
> 
> Should I do something extra?
> 
> Everytime I add a member to the group, both the member and the group
> get their references updated.
> Now when I add a member to a group and save it, I also save the
> member. Is there another way to avoid this?
> 
> Any recommended practice for this?
> 
> Next level question: What if it gets composite? it is... a Group has
> other Groups as members :)
> 
> 
> Regards!
> 
> Esteban A. Maringolo
> 
> 

Re: [Pharo-users] [ANN] Aida 6.6 Web Framework Released

[Stéphane Ducasse]

>> 
>> 
>> New version of Aida/Web framework and application server
>> (http://www.aidaweb.si) is here with:
>> 
>> - optimization on HTTP level to send first byte to the client as soon
>>   as possible
>> - streaming of HTML, specially header to get first byte out
>>   immediately,
>> - gzip compression of all text stuff like CSS, JS etc
>> - CSS Sprites support added
>> - internal vs. extarnal IP detection, to control access rights
>>   accordingly
>> - Geolocation support improved
>> - all JS and CSS libraries updated to latest versions, Twitter
>>   Bootstrap v3 added in parallel to v2.x
> 
> Great work, thanks, Janko.

+ 1

Janko if you need scripts to migrate to SmalltalkHub let me know.

Re: [Pharo-users] Group and member with Voyage

[James Foster]

Hi Esteban,

It seems that I mistook the question for something easy enough for me to 
answer! Unfortunately, I don't have any knowledge of Voyage+MongoDB so can't 
really give the proper answer.

James

On Aug 30, 2013, at 11:13 AM, Esteban A. Maringolo  wrote:

> Hi James,
> 
> Thanks for your response. You are right, the Pattern is quite common,
> if not ubiquous in all systems.
> 
> My particular question is related with Voyage+MongoDB, and also could
> apply to Magritte (given the fact Voyage "inherits" its descriptions
> model).
> 
> I sucessfully implemented this pattern with ORMs using an intermediary
> table for the relation, or even reifying the relation as a first class
> object.
> I also used the #select: technique to avoid duplication of
> "responsibility" and caching at one side of the relation.
> But I always did it "in memory" with no mapping et all, just plain old
> smalltalk objects (POSO?) and using ORM solutions.
> 
> What I need to know now is:
> 1) How to do this with voyage+MongoDB
> 2) I want to have a two way relation, it is both members and groups
> have a collection (members know their groups and viceversa). This
> requires additional maintenance, but with a higher performance, and
> doesn't require me to load all groups if I'm just materializing one
> member.
> 
> 
> Regards!
> 
> Esteban A. Maringolo
> 
> 
> 2013/8/30 James Foster :
>> Hi Esteban,
>> 
>> What you have described is quite common and there are a variety of ways of 
>> designing this sort of object model. If you were dealing with a relational 
>> database, then you would have a Group table, a Member table, and a 
>> Membership table. The Membership table would have one row for each 
>> member/group pair and the member ID and group ID would be the primary 
>> columns (perhaps with other things like date joined, date expired, etc.). 
>> With an index on the member ID and group ID, one could quickly find all the 
>> groups for a member and all the members for a group, and each piece of data 
>> would exist in only one place ("normalized"). One could take a similar 
>> approach with objects, having three collections containing Groups, Members, 
>> and Memberships respectively. You could have an accessor in Group that 
>> returned members based on a select from the Memberships collection and an 
>> accessor in Member that returned groups based on a select from the 
>> Memberships collection.
>> 
>> Alternatively, if you wanted to avoid the #'select:' call in one or both 
>> lookups, you can cache the respective subcollections in Group and/or Member 
>> and drop the Memberships collection. If you cache in only one place (e.g., 
>> each Group has a collection of Members), then you can add a method in Member 
>> that does a #'select:' of Groups where a Group has the Member. If you cache 
>> in both places then your getters/setters in each can update the other (with 
>> the understanding that you are duplicating data to get performance 
>> efficiency).
>> 
>> Again, this problem is very common. Consider students in classes, persons 
>> with addresses, persons with hobbies, etc. Your choices are basically (1) 
>> three collections, no duplicates, select for both queries; (2) two 
>> collections, no duplicates, cache for one query, select for the other query; 
>> and (3) two collections, caches for each query. Which is preferable depends 
>> on your typical sizes and lookup patterns. If performance is not an issue, 
>> then start with whatever is simplest for you to code. I lean toward the 
>> three collections with the lookup penalty (GemStone's ability to index 
>> collections makes this approach very efficient), but if most of your lookups 
>> are from one side or the other and scanning the full collection is slow, 
>> then cache in one or both places.
>> 
>> If you have a composite, the analysis is similar since Smalltalk does not 
>> require static typing of variables. You just need to take care that your 
>> accessors can give back the expected objects.
>> 
>> James
>> 
>> On Aug 29, 2013, at 6:12 PM, Esteban A. Maringolo  
>> wrote:
>> 
>>> Hi all,
>>> 
>>> Let's say I have a class Group and a class Member.
>>> 
>>> aGroup has many members.
>>> and aMember can belong to many groups.
>>> 
>>> What is the "proper" voyageDescription for those one to many relations?
>>> 
>>> Should I do something extra?
>>> 
>>> Everytime I add a member to the group, both the member and the group
>>> get their references updated.
>>> Now when I add a member to a group and save it, I also save the
>>> member. Is there another way to avoid this?
>>> 
>>> Any recommended practice for this?
>>> 
>>> Next level question: What if it gets composite? it is... a Group has
>>> other Groups as members :)
>>> 
>>> 
>>> Regards!
>>> 
>>> Esteban A. Maringolo
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-users] Group and member with Voyage

[Esteban A. Maringolo]

2013/8/30 James Foster :
> It seems that I mistook the question for something easy enough for me to 
> answer! Unfortunately, I don't have any knowledge of Voyage+MongoDB so can't 
> really give the proper answer.

Thanks anyway, it is a problem you'll never find in GemStone/S ;-)

Re: [Pharo-users] Group and member with Voyage

[Esteban A. Maringolo]

More or less, I have this working.

In the Group class I have a description named:
descriptionMembers

^VOMongoToManyDescription new
attributeName: 'members';
accessor: #members;
kind: Member;
beLazy;
yourself


And in the Member class I have
descriptionGroups

^VOMongoToManyDescription new
  attributeName: 'groups';
  accessor: #groups;
  kind: Group;
  beLazy;
  yourself



But what if Member is an abstract class and the elements can be any of
SingleMember or ComplexMember?, each one is stored in a separate
collection in Mongo.

If I do specify #kind: Member in my #descriptionMembers it won't work.

Any ideas?

Regards,


Esteban A. Maringolo


2013/8/30 Esteban A. Maringolo :
> 2013/8/30 James Foster :
>> It seems that I mistook the question for something easy enough for me to 
>> answer! Unfortunately, I don't have any knowledge of Voyage+MongoDB so can't 
>> really give the proper answer.
>
> Thanks anyway, it is a problem you'll never find in GemStone/S ;-)

Re: [Pharo-users] Group and member with Voyage

[Esteban A. Maringolo]

I think that the question could be rephrased as:

How to map a collection with elements of different classes?

Am I asking for too much?


Esteban A. Maringolo


2013/8/30 Esteban A. Maringolo :
> More or less, I have this working.
>
> In the Group class I have a description named:
> descriptionMembers
> 
> ^VOMongoToManyDescription new
> attributeName: 'members';
> accessor: #members;
> kind: Member;
> beLazy;
> yourself
>
>
> And in the Member class I have
> descriptionGroups
> 
> ^VOMongoToManyDescription new
>   attributeName: 'groups';
>   accessor: #groups;
>   kind: Group;
>   beLazy;
>   yourself
>
>
>
> But what if Member is an abstract class and the elements can be any of
> SingleMember or ComplexMember?, each one is stored in a separate
> collection in Mongo.
>
> If I do specify #kind: Member in my #descriptionMembers it won't work.
>
> Any ideas?
>
> Regards,
>
>
> Esteban A. Maringolo
>
>
> 2013/8/30 Esteban A. Maringolo :
>> 2013/8/30 James Foster :
>>> It seems that I mistook the question for something easy enough for me to 
>>> answer! Unfortunately, I don't have any knowledge of Voyage+MongoDB so 
>>> can't really give the proper answer.
>>
>> Thanks anyway, it is a problem you'll never find in GemStone/S ;-)