date:20141031

Re: [Pharo-dev] Time Series in Smalltalk

2014-10-31 Thread Blondeau Vincent

Dear Serge,

That's nice but I will need more statistical functions to calculate 
autocorrelations.
These functions are already implemented in R (http://www.r-project.org/).
So, there is two solutions:
- As the sources are open, implement them in Pharo (but it is some thousands of 
lines...)
- With nativeboost, use the R libs (written in C)

As I prefer the second solution, I began to write some code with native boost 
and it seems to work well.
I can add them in SciSmalltalk package if I have the rights. But I don't know 
how to package the R libraries for the different OS...

Regards,

Vincent Blondeau

-Message d'origine-
De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de Serge 
Stinckwich
Envoyé : vendredi 24 octobre 2014 09:56
À : Pharo Development List
Objet : Re: [Pharo-dev] Time Series in Smalltalk

> On 23 Oct 2014, at 14:52, Blondeau Vincent  
> wrote:
>
> Hi !
>

Dear Vincent,

>
>
> I am looking for a time series library available for Pharo.
>
> Serge Stinckwich asked the same thing a year ago 
> (http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-February/074796.html),
>  and I would know whether any improvement has been made since?
>
>

We started a really simple implementation of time series. Look at the class : 
KETimeSeries and KETimeSeriesTest in this repository: 
http://smalltalkhub.com/#!/~UMMISCO/Kendrick

Please feel free to extract these classes and extend them. Maybe we can move 
them in the SciSmalltalk repository.

Regards,
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/

Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité de Worldline ne pourra être 
recherchée quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.

Re: [Pharo-dev] Time Series in Smalltalk

2014-10-31 Thread Serge Stinckwich

> On 31 Oct 2014, at 10:50, Blondeau Vincent  
> wrote:
> 
> Dear Serge,
> 

Bonjour Vincent,

> That's nice but I will need more statistical functions to calculate 
> autocorrelations.
Yes having some statistical functions and tests is definitively something we 
are looking for SciSmalltalk.

> These functions are already implemented in R (http://www.r-project.org/).
> So, there is two solutions:
> - As the sources are open, implement them in Pharo (but it is some thousands 
> of lines…)

This is R code ? Do you have a link to this source ?
I’m also interested to have a native solution in Pharo. Maybe we can join our 
forces ;-)

> - With nativeboost, use the R libs (written in C)
> 
> As I prefer the second solution, I began to write some code with native boost 
> and it seems to work well.

I’m a little bit worried with performance issue for the second solution ;-)
or R libs are not written in R ?

> I can add them in SciSmalltalk package if I have the rights. But I don't know 
> how to package the R libraries for the different OS…
> 

Yes, this is a nice idea. We can give you access to the SciSmalltalk repo.
Please join the ml: https://groups.google.com/forum/#!forum/scismalltalk 
What could be nice is write tests so we can use this tests latter if we want to 
have a native solution.

Thank you.
Regards,
-- 
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/

Re: [Pharo-dev] VersionnerRepositoriesManager - Why clear okAction?

2014-10-31 Thread Christophe Demarey

Hi Sean,

Le 23 oct. 2014 à 23:16, Sean P. DeNigris a écrit :

> No class is safe from my wrath he he...
> 
> VersionnerRepositoriesManager class>>#open
>   | dialog |
>   dialog := remotesUI openDialogWithSpec.
>   dialog okAction: [  ]
> 
> - why were we wiping the okAction? "dialog okAction: [  ]" does not reveal
> any intention. At minimum, a comment would be good

I fully agree. I wrote the code some months ago and I forgot the reason ...
I think the setting of the okAction is useless.
I often put a comment but i miss this one. Thanks for the feedback.

> - it would be good to return something here so users can customize more
> easily. Even though this is tightly integrated with Versionner, a tiny bit
> of care makes the system more easily extensible. We should record some
> patterns here...

Maybe what you need is RemotesManager. I extracted this component from Komitter.



smime.p7s
Description: S/MIME cryptographic signature

[Pharo-dev] [pharo-project/pharo-core] 500663: 40341

2014-10-31 Thread GitHub

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 500663af6f157acf73edc166a46f5be4e8868ac6
  
https://github.com/pharo-project/pharo-core/commit/500663af6f157acf73edc166a46f5be4e8868ac6
  Author: Jenkins Build Server 
  Date:   2014-10-31 (Fri, 31 Oct 2014)

  Changed paths:
M NautilusCommon.package/AbstractKeyPressedPlugin.class/README.md
M NautilusCommon.package/AbstractNautilusPlugin.class/README.md
M 
NautilusCommon.package/AbstractNautilusPlugin.class/class/information/description.st
M 
NautilusCommon.package/AbstractNautilusPlugin.class/class/information/possiblePositions.st
M 
NautilusCommon.package/AbstractNautilusPlugin.class/class/position/defaultPosition.st
M 
NautilusCommon.package/AbstractNautilusPlugin.class/instance/display/display.st
M 
NautilusCommon.package/AnnotationPanePlugin.class/instance/private/buildString.st
A NautilusCommon.package/CountingKeyPressedPlugin.class/README.md
A 
NautilusCommon.package/CountingKeyPressedPlugin.class/class/information/description.st
A 
NautilusCommon.package/CountingKeyPressedPlugin.class/class/position/defaultPosition.st
A NautilusCommon.package/CountingKeyPressedPlugin.class/definition.st
A 
NautilusCommon.package/CountingKeyPressedPlugin.class/instance/accessing/stringMorph.st
A 
NautilusCommon.package/CountingKeyPressedPlugin.class/instance/accessing/stringMorph_.st
A 
NautilusCommon.package/CountingKeyPressedPlugin.class/instance/announcement/keyPressed_.st
A 
NautilusCommon.package/CountingKeyPressedPlugin.class/instance/display/display.st
A 
NautilusCommon.package/CountingKeyPressedPlugin.class/instance/initialization/initialize.st
R NautilusCommon.package/DummyKeyPressedPlugin.class/README.md
R 
NautilusCommon.package/DummyKeyPressedPlugin.class/class/information/description.st
R 
NautilusCommon.package/DummyKeyPressedPlugin.class/class/position/defaultPosition.st
R NautilusCommon.package/DummyKeyPressedPlugin.class/definition.st
R 
NautilusCommon.package/DummyKeyPressedPlugin.class/instance/accessing/stringMorph.st
R 
NautilusCommon.package/DummyKeyPressedPlugin.class/instance/accessing/stringMorph_.st
R 
NautilusCommon.package/DummyKeyPressedPlugin.class/instance/announcement/keyPressed_.st
R 
NautilusCommon.package/DummyKeyPressedPlugin.class/instance/display/display.st
R 
NautilusCommon.package/DummyKeyPressedPlugin.class/instance/initialization/initialize.st
M NautilusCommon.package/DummyPackageSelectedPlugin.class/README.md
M NautilusCommon.package/DummyPackageSelectedPlugin.class/definition.st
R NautilusCommon.package/IgorsPlugin.class/README.md
R NautilusCommon.package/IgorsPlugin.class/class/as yet 
unclassified/description.st
R NautilusCommon.package/IgorsPlugin.class/definition.st
R NautilusCommon.package/IgorsPlugin.class/instance/as yet 
unclassified/buildString.st
M NautilusCommon.package/KonamiCodePlugin.class/README.md
M NautilusCommon.package/KonamiCodePlugin.class/definition.st
M NautilusCommon.package/MondrianPlugin.class/README.md
M NautilusCommon.package/MondrianPlugin.class/definition.st
M 
NautilusCommon.package/NautilusBreadcrumbsPlugin.class/class/information/description.st
M 
NautilusCommon.package/PackageTasksPlugin.class/instance/announcement/packageSelected_.st
M 
NautilusCommon.package/PackageTasksPlugin.class/instance/display/buildTaskList.st
M 
NautilusCommon.package/PackageTasksPlugin.class/instance/display/updateMethodSelection_.st
M NautilusCommon.package/URLPlugin.class/instance/private/buildString.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script341.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40341.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M 
SlotTests.package/SlotAnnouncementsTest.class/instance/helpers/subscribeOn_.st
M System-Announcements.package/AnnouncementLogger.class/instance/as yet 
unclassified/subscribeTo_.st

  Log Message:
  ---
  40341
14356 Replace Announcer>>#on:send:to:s senders in System-Announcements
https://pharo.fogbugz.com/f/cases/14356

14355 Replace Announcer>>#on:send:to:s senders in SlotTests
https://pharo.fogbugz.com/f/cases/14355

14352 Cleaning, fixing and documenting NautilusPugin
https://pharo.fogbugz.com/f/cases/14352

http://files.pharo.org/image/40/40341.zip

[Pharo-dev] [pharo-project/pharo-core]

2014-10-31 Thread GitHub

  Branch: refs/tags/40341
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] c6c309: 40342

2014-10-31 Thread GitHub

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: c6c309f9fa7f1093c0e6171ee00eec329230156a
  
https://github.com/pharo-project/pharo-core/commit/c6c309f9fa7f1093c0e6171ee00eec329230156a
  Author: Jenkins Build Server 
  Date:   2014-10-31 (Fri, 31 Oct 2014)

  Changed paths:
M Polymorph-Widgets.package/ThemeIcons.class/definition.st
M 
Polymorph-Widgets.package/ThemeIcons.class/instance/initialization/initializeIcons.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script342.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40342.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  40342
14326 ThemeIcons should use LRUCache
https://pharo.fogbugz.com/f/cases/14326

14357 add Current class var to ThemeIcons
https://pharo.fogbugz.com/f/cases/14357

http://files.pharo.org/image/40/40342.zip

[Pharo-dev] [pharo-project/pharo-core]

2014-10-31 Thread GitHub

  Branch: refs/tags/40342
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] LRUCache for high latency stuff

2014-10-31 Thread Thierry Goubier

Hi all,

I tried to use LRUCache for some application of mine with a two stages,
over-the-internet data requests, and I couldn't find a way of using it.

My use case was:
- retrieve some data with high latency (over 10 seconds)
- in a interactive application, where I need to be able to continue while
the data is being loaded.

So I designed it in two stages:
- Have a cache
- if the data isn't in the cache
-- trigger a load with a fork
-- put some temporary data in the cache (something which says loading)
-- continue
- When the data load is terminated
-- replace the cached temporary data with the final version.

The thing is that I couldn't do the last one with the LRUCache (there is
not at:put:, only a at:ifAbsentPut: []). Did I miss something?

Thierry

[Pharo-dev] [pharo-project/pharo-core] 787596: 40343

2014-10-31 Thread GitHub

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 787596aa8a0f20acb55a923f9afa63ec22417f9d
  
https://github.com/pharo-project/pharo-core/commit/787596aa8a0f20acb55a923f9afa63ec22417f9d
  Author: Jenkins Build Server 
  Date:   2014-10-31 (Fri, 31 Oct 2014)

  Changed paths:
M Polymorph-Widgets.package/ThemeIcons.class/class/instance 
creation/current.st
M Polymorph-Widgets.package/ThemeIcons.class/class/instance 
creation/current_.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script343.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40343.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  40343
Current

http://files.pharo.org/image/40/40343.zip

[Pharo-dev] [pharo-project/pharo-core]

2014-10-31 Thread GitHub

  Branch: refs/tags/40343
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] Zinc running on privileged ports

2014-10-31 Thread Christophe Demarey

Hello,

I just tried to get a simple Zinc server running on the standard HTTP port (80) 
and it is not working.
ZnServer startDefaultOn: 80
My image was run with a standard user. As the standard HTTP port is a 
privileged port (each port number < 1024 is a privileged port), I tried to run 
it through sudo.
It is not working with PharoLauncher (loss of permissions with the process 
fork?) but works by running the image directly.

The thing that is strange to me is that if I try to run Zinc on a port with not 
enough permissions, I do not get an error. I saw a test of the socket validity 
in ZnNetworkingUtils>>serverSocketOn: but I think it is not catching the 
permissions problem. Is it difficult to detect? If not, it would be good to 
have an exception if the specified port cannot be used.

Christophe.

smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] Time Series in Smalltalk

2014-10-31 Thread Hernán Morales Durand

2014-10-31 6:50 GMT-03:00 Blondeau Vincent :

> Dear Serge,
>
> That's nice but I will need more statistical functions to calculate
> autocorrelations.
>

Have you checked NumericalMethods package? (is available from the
Configuration Browser)


> These functions are already implemented in R (http://www.r-project.org/).
> So, there is two solutions:
> - As the sources are open, implement them in Pharo (but it is some
> thousands of lines...)
> - With nativeboost, use the R libs (written in C)
>
> As I prefer the second solution, I began to write some code with native
> boost and it seems to work well.
> I can add them in SciSmalltalk package if I have the rights. But I don't
> know how to package the R libraries for the different OS...
>
>
I would ask you if you can put this code into its own repository, so we can
use the R binding without need to load the whole SciSmalltalk, and
SciSmalltalk could import your Configuration.

Cheers,

Hernán


> Regards,
>
> Vincent Blondeau
>
> -Message d'origine-
> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
> Serge Stinckwich
> Envoyé : vendredi 24 octobre 2014 09:56
> À : Pharo Development List
> Objet : Re: [Pharo-dev] Time Series in Smalltalk
>
>
> > On 23 Oct 2014, at 14:52, Blondeau Vincent <
> vincent.blond...@worldline.com> wrote:
> >
> > Hi !
> >
>
> Dear Vincent,
>
> >
> >
> > I am looking for a time series library available for Pharo.
> >
> > Serge Stinckwich asked the same thing a year ago (
> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-February/074796.html),
> and I would know whether any improvement has been made since?
> >
> >
>
> We started a really simple implementation of time series. Look at the
> class : KETimeSeries and KETimeSeriesTest in this repository:
> http://smalltalkhub.com/#!/~UMMISCO/Kendrick
>
> Please feel free to extract these classes and extend them. Maybe we can
> move them in the SciSmalltalk repository.
>
> Regards,
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://doesnotunderstand.org/
>
>
> Ce message et les pièces jointes sont confidentiels et réservés à l'usage
> exclusif de ses destinataires. Il peut également être protégé par le secret
> professionnel. Si vous recevez ce message par erreur, merci d'en avertir
> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
> pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra
> être recherchée quant au contenu de ce message. Bien que les meilleurs
> efforts soient faits pour maintenir cette transmission exempte de tout
> virus, l'expéditeur ne donne aucune garantie à cet égard et sa
> responsabilité ne saurait être recherchée pour tout dommage résultant d'un
> virus transmis.
>
> This e-mail and the documents attached are confidential and intended
> solely for the addressee; it may also be privileged. If you receive this
> e-mail in error, please notify the sender immediately and destroy it. As
> its integrity cannot be secured on the Internet, the Worldline liability
> cannot be triggered for the message content. Although the sender endeavours
> to maintain a computer virus-free network, the sender does not warrant that
> this transmission is virus-free and will not be liable for any damages
> resulting from any virus transmitted.
>
>

Re: [Pharo-dev] Time Series in Smalltalk

2014-10-31 Thread Serge Stinckwich

> On 31 Oct 2014, at 14:42, Hernán Morales Durand  
> wrote:
> 
> 
> 
> 2014-10-31 6:50 GMT-03:00 Blondeau Vincent :
> Dear Serge,

Hi Hernán,

> That's nice but I will need more statistical functions to calculate 
> autocorrelations.
> 
> Have you checked NumericalMethods package? (is available from the 
> Configuration Browser)
>  

Apparently this is a derivative of DHB classes already included in SciSmalltalk.
Did you make some modifications ?
We already modify/add some code to these classes.
What do you think about working on the same codebase instead of duplicating 
efforts ?

Regards,
-- 
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/

Re: [Pharo-dev] Time Series in Smalltalk

2014-10-31 Thread Blondeau Vincent

> -Message d'origine-
> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de
> Serge Stinckwich
> Envoyé : vendredi 31 octobre 2014 11:39
> À : Pharo Development List
> Objet : Re: [Pharo-dev] Time Series in Smalltalk
>
>
> > On 31 Oct 2014, at 10:50, Blondeau Vincent
>  wrote:
> >
> > Dear Serge,
> >
>
> Bonjour Vincent,
>
> > That's nice but I will need more statistical functions to calculate
> autocorrelations.
> Yes having some statistical functions and tests is definitively something we
> are looking for SciSmalltalk.
>
> > These functions are already implemented in R (http://www.r-project.org/).
> > So, there is two solutions:
> > - As the sources are open, implement them in Pharo (but it is some
> > thousands of lines...)
>
> This is R code ? Do you have a link to this source ?
This is C code: you can download it here: http://cran.r-project.org/sources.html
> I'm also interested to have a native solution in Pharo. Maybe we can join our
> forces ;-)

I look at the sources a little and it seems costly to translate them. Maybe we 
can select a few. Statistical Tests looks simpler.

>
> > - With nativeboost, use the R libs (written in C)
> >
> > As I prefer the second solution, I began to write some code with native
> boost and it seems to work well.
>
> I'm a little bit worried with performance issue for the second solution ;-) 
> or R
> libs are not written in R ?

R libs are in C. So I think that the performances are not the problem.
>
> > I can add them in SciSmalltalk package if I have the rights. But I
> > don't know how to package the R libraries for the different OS...
> >
>
> Yes, this is a nice idea. We can give you access to the SciSmalltalk repo.
> Please join the ml: https://groups.google.com/forum/#!forum/scismalltalk
> What could be nice is write tests so we can use this tests latter if we want 
> to
> have a native solution.

That's what I planned to do ;)

Thanks,

Regards,
Vincent
>
> Thank you.
> Regards,
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://doesnotunderstand.org/

Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité de Worldline ne pourra être 
recherchée quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.

Re: [Pharo-dev] Time Series in Smalltalk

2014-10-31 Thread Blondeau Vincent

Dear Hernán,

I will put the code in my own repo with a configuration that you can import.
NumericalMethods package seems to contains the same things that Scismalltalk. 
So there is no timeseries methods.

Cheers,
Vincent

De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de Hernán 
Morales Durand
Envoyé : vendredi 31 octobre 2014 14:42
À : Pharo Development List
Objet : Re: [Pharo-dev] Time Series in Smalltalk

2014-10-31 6:50 GMT-03:00 Blondeau Vincent 
mailto:vincent.blond...@worldline.com>>:
Dear Serge,

That's nice but I will need more statistical functions to calculate 
autocorrelations.

Have you checked NumericalMethods package? (is available from the Configuration 
Browser)

These functions are already implemented in R (http://www.r-project.org/).
So, there is two solutions:
- As the sources are open, implement them in Pharo (but it is some thousands of 
lines...)
- With nativeboost, use the R libs (written in C)

As I prefer the second solution, I began to write some code with native boost 
and it seems to work well.
I can add them in SciSmalltalk package if I have the rights. But I don't know 
how to package the R libraries for the different OS...

I would ask you if you can put this code into its own repository, so we can use 
the R binding without need to load the whole SciSmalltalk, and SciSmalltalk 
could import your Configuration.
Cheers,
Hernán

Regards,

Vincent Blondeau

-Message d'origine-
De : Pharo-dev 
[mailto:pharo-dev-boun...@lists.pharo.org]
 De la part de Serge Stinckwich
Envoyé : vendredi 24 octobre 2014 09:56
À : Pharo Development List
Objet : Re: [Pharo-dev] Time Series in Smalltalk

> On 23 Oct 2014, at 14:52, Blondeau Vincent 
> mailto:vincent.blond...@worldline.com>> wrote:
>
> Hi !
>

Dear Vincent,

>
>
> I am looking for a time series library available for Pharo.
>
> Serge Stinckwich asked the same thing a year ago 
> (http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2013-February/074796.html),
>  and I would know whether any improvement has been made since?
>
>

We started a really simple implementation of time series. Look at the class : 
KETimeSeries and KETimeSeriesTest in this repository: 
http://smalltalkhub.com/#!/~UMMISCO/Kendrick

Please feel free to extract these classes and extend them. Maybe we can move 
them in the SciSmalltalk repository.

Regards,
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/

Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité de Worldline ne pourra être 
recherchée quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.

Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité de Worldline ne pourra être 
recherchée quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages

Re: [Pharo-dev] Zinc running on privileged ports

2014-10-31 Thread Sven Van Caekenberghe

Hi Christophe,

> On 31 Oct 2014, at 14:21, Christophe Demarey  
> wrote:
> 
> Hello,
> 
> I just tried to get a simple Zinc server running on the standard HTTP port 
> (80) and it is not working.
>   ZnServer startDefaultOn: 80
> My image was run with a standard user. As the standard HTTP port is a 
> privileged port (each port number < 1024 is a privileged port), I tried to 
> run it through sudo.
> It is not working with PharoLauncher (loss of permissions with the process 
> fork?) but works by running the image directly.

So basically, it works. Good. I never tried that. I/we always put a proxy in 
front for production deploys.

> The thing that is strange to me is that if I try to run Zinc on a port with 
> not enough permissions, I do not get an error. I saw a test of the socket 
> validity in ZnNetworkingUtils>>serverSocketOn: but I think it is not catching 
> the permissions problem. Is it difficult to detect? If not, it would be good 
> to have an exception if the specified port cannot be used.

There is ZnServer>>#isListening that tries to do that. In the end it comes down 
to what is available to the Socket API and how it behave across different 
platforms. You can access the server socket with #serverSocket.

> Christophe.

Sven

Re: [Pharo-dev] Zinc running on privileged ports

2014-10-31 Thread Christophe Demarey


Le 31 oct. 2014 à 16:19, Sven Van Caekenberghe a écrit :

> Hi Christophe,
> 
>> On 31 Oct 2014, at 14:21, Christophe Demarey  
>> wrote:
>> 
>> Hello,
>> 
>> I just tried to get a simple Zinc server running on the standard HTTP port 
>> (80) and it is not working.
>>  ZnServer startDefaultOn: 80
>> My image was run with a standard user. As the standard HTTP port is a 
>> privileged port (each port number < 1024 is a privileged port), I tried to 
>> run it through sudo.
>> It is not working with PharoLauncher (loss of permissions with the process 
>> fork?) but works by running the image directly.
> 
> So basically, it works. Good. I never tried that. I/we always put a proxy in 
> front for production deploys.
> 
>> The thing that is strange to me is that if I try to run Zinc on a port with 
>> not enough permissions, I do not get an error. I saw a test of the socket 
>> validity in ZnNetworkingUtils>>serverSocketOn: but I think it is not 
>> catching the permissions problem. Is it difficult to detect? If not, it 
>> would be good to have an exception if the specified port cannot be used.
> 
> There is ZnServer>>#isListening that tries to do that. In the end it comes 
> down to what is available to the Socket API and how it behave across 
> different platforms. You can access the server socket with #serverSocket.

Yes, I think it is a limitation of the Socket API.

smime.p7s
Description: S/MIME cryptographic signature

[Pharo-dev] [pharo-project/pharo-core] 016101: 40344

2014-10-31 Thread GitHub

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 01610158cd63c7eba02bdb886ede5ae5df90b43c
  
https://github.com/pharo-project/pharo-core/commit/01610158cd63c7eba02bdb886ede5ae5df90b43c
  Author: Jenkins Build Server 
  Date:   2014-10-31 (Fri, 31 Oct 2014)

  Changed paths:
R KeyChainTest.package/ManifestKeyChainTest.class/README.md
R KeyChainTest.package/ManifestKeyChainTest.class/class/meta 
data/rejectClasses.st
R KeyChainTest.package/ManifestKeyChainTest.class/class/meta 
data/rejectRules.st
R KeyChainTest.package/ManifestKeyChainTest.class/class/meta 
data/ruleLongMethodsRuleV1FalsePositive.st
R KeyChainTest.package/ManifestKeyChainTest.class/definition.st
R KeyChainTest.package/PharoUserPermissionsTest.class/README.md
R KeyChainTest.package/PharoUserPermissionsTest.class/definition.st
R 
KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanBrowse.st
R 
KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanDebug.st
R 
KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanDropOSFile.st
R 
KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanEditCode.st
R 
KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanEditUser.st
R 
KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanEvaluateCode.st
R 
KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanInspect.st
R 
KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanRunStartupScript.st
R 
KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanSaveImage.st
R 
KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testCanShowMorphHalo.st
R 
KeyChainTest.package/PharoUserPermissionsTest.class/instance/tests/testIsRoot.st
R KeyChainTest.package/PharoUserTest.class/README.md
R KeyChainTest.package/PharoUserTest.class/definition.st
R KeyChainTest.package/PharoUserTest.class/instance/tests/testUsername.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script344.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40344.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A UserManager-Tests.package/ManifestKeyChainTest.class/README.md
A UserManager-Tests.package/ManifestKeyChainTest.class/class/meta 
data/rejectClasses.st
A UserManager-Tests.package/ManifestKeyChainTest.class/class/meta 
data/rejectRules.st
A UserManager-Tests.package/ManifestKeyChainTest.class/class/meta 
data/ruleLongMethodsRuleV1FalsePositive.st
A UserManager-Tests.package/ManifestKeyChainTest.class/definition.st
A UserManager-Tests.package/PharoUserPermissionsTest.class/README.md
A UserManager-Tests.package/PharoUserPermissionsTest.class/definition.st
A 
UserManager-Tests.package/PharoUserPermissionsTest.class/instance/tests/testCanBrowse.st
A 
UserManager-Tests.package/PharoUserPermissionsTest.class/instance/tests/testCanDebug.st
A 
UserManager-Tests.package/PharoUserPermissionsTest.class/instance/tests/testCanDropOSFile.st
A 
UserManager-Tests.package/PharoUserPermissionsTest.class/instance/tests/testCanEditCode.st
A 
UserManager-Tests.package/PharoUserPermissionsTest.class/instance/tests/testCanEditUser.st
A 
UserManager-Tests.package/PharoUserPermissionsTest.class/instance/tests/testCanEvaluateCode.st
A 
UserManager-Tests.package/PharoUserPermissionsTest.class/instance/tests/testCanInspect.st
A 
UserManager-Tests.package/PharoUserPermissionsTest.class/instance/tests/testCanRunStartupScript.st
A 
UserManager-Tests.package/PharoUserPermissionsTest.class/instance/tests/testCanSaveImage.st
A 
UserManager-Tests.package/PharoUserPermissionsTest.class/instance/tests/testCanShowMorphHalo.st
A 
UserManager-Tests.package/PharoUserPermissionsTest.class/instance/tests/testIsRoot.st
A UserManager-Tests.package/PharoUserTest.class/README.md
A UserManager-Tests.package/PharoUserTest.class/definition.st
A 
UserManager-Tests.package/PharoUserTest.class/instance/tests/testUsername.st

  Log Message:
  ---
  40344
14330 rename KeyChainTest --> KeyChainTests so it gets unloaded by 
#cleanUpForProduction
https://pharo.fogbugz.com/f/cases/14330

14362 Iconset is wrong
https://pharo.fogbugz.com/f/cases/14362

http://files.pharo.org/image/40/40344.zip

[Pharo-dev] [pharo-project/pharo-core]

2014-10-31 Thread GitHub

  Branch: refs/tags/40344
  Home:   https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] Super fast delay

2014-10-31 Thread Ben Coman


Norbert Hartl wrote:

Am 30.10.2014 um 12:52 schrieb Ben Coman :

Eliot Miranda wrote:

On Wed, Oct 29, 2014 at 12:14 PM, Ben Coman mailto:b...@openinworld.com>> wrote:
   Holger Hans Peter Freyther wrote:
   On Wed, Oct 29, 2014 at 06:54:57PM +0100, Holger Hans Peter
   Freyther wrote:
   On Wed, Oct 29, 2014 at 10:03:03AM +0100, Norbert Hartl wrote:
   Good Evening,
   Hi again,
   I don't know how you debug startUp issues. I just added an
   OrderedCollection
   into the systemdictionary and use it as a log..
   time ./bin/pharo --nodisplay ./TimerTest3.image eval "(Delay
   forSeconds: 3) wait. (Smalltalk at: #Foo) do: [:each |
   FileStream stderr nextPutAll: each printString; cr].1"
   ... old events from saving the image...
   {#handleTimerEvent->7147}
   {#handleTimerEvent->7167}
   {#resumptionTime->7187}
   {#handleTimerEvent->7167}
   {#handleTimerEvent->7187}
   {#start->true}
   {#start->393102159}
   {#start->393102159}
   {#resumptionTime->3279}
   {#handleTimerEvent->279}
   {#adjustResum->-393098880}
   {#restoreWithActiveDelay->266}
   {#adjustResum->-393098601}
   1
   real0m0.294s
   user0m0.244s
   sys 0m0.048s
   So what happens is Delay class>>#startU is called. and
   ActiveDelayStartTime is being set to 393102159. Then the
   delay is being created and resumptionTime is set to 3279.
   At the first time handleTimerEvent runs the milliSecondClock
   jumped backwards from 393102159 to 3279 which leads to
   an adjustment of the time.
   a.) Why does the time jump backwards like this during the
   resumption of the image? "3279" is not the old time nor
   the new starting time.
   b.) So even if that is a "wrap" around. Why does it go
   wrong? Are there unit tests for the clock wraps around?
   There are no unit tests, I guess since its all done using class
   variables its too hard test without disturbing the system.
   Now I have spent the last week refactoring this out to the
   instance-side of a new class "DelayScheduler" which should help with
   getting unit tests.  Its ready for review [1], maybe you could take
   a look.
   [1] https://pharo.fogbugz.com/__default.asp?14261
   
   Maybe it is the same reason delays just don't work after
   image resumption?
   The "first" issue appears that when start is being executed
   that the clock is still wrong. At the same the clock is
   being considered wrapped the resumption time was actually
   already "correct' (3279 instead of 393102159+3279).
   Does this ring a bell?
   holger
   btw, its too late in the night for me to try something, but I have
   been wondering, should the check for clock roll-over occur
   immediately after
   TimingSemaphore wait
   wakes up. That is, before the Schedule and Finish requests are
   handled ???
The check for rollover should be thrown away and the system implemented over 
the VM's support for 64-bit microseconds since 1901.  It's in the VM, it isn't 
susceptible to rollover for ~ 50,000 years, and doesn't require the millisecond 
clock to be synced to the second clock, because all times can be derived from 
the one 64-bit microsecond clock.
--
best,
Eliot

I'll give it a go.
cheers -ben


Super, thanks in advance,

Norbert






This is ready for review as "Delay refactoring (part 2) - change from 
milliseconds to microseconds"

https://pharo.fogbugz.com/default.asp?14353

Note that this continues on from "Delay refactoring (part 1) - move 
scheduler from class-side to instance-side of its own class"

https://pharo.fogbugz.com/default.asp?14261

So load part 1 first if you only want to see the from milliseconds to 
microseconds changes.  Now if you don't like part 1, I'll do the work to 
break out part 2 on its own - but it was simpler for me to work on part 
2 since:
* with instances I could define, run and debug tests without 
interference from the live system-delay-scheduler.

* the code swapping (newCodeEnabled) pattern I'd used for part 1 helped.
* eliminating the clock rollover conditional simplifies what I am 
planning for part 3


I don't have the virtual machine environment to replicate the problem, 
so please report if it this has any effect.


cheers -ben

Re: [Pharo-dev] Time Series in Smalltalk

2014-10-31 Thread Hernán Morales Durand

Hi Serge,

2014-10-31 11:06 GMT-03:00 Serge Stinckwich :

>
> > On 31 Oct 2014, at 14:42, Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
> >
> >
> >
> > 2014-10-31 6:50 GMT-03:00 Blondeau Vincent <
> vincent.blond...@worldline.com>:
> > Dear Serge,
>
> Hi Hernán,
>
> > That's nice but I will need more statistical functions to calculate
> autocorrelations.
> >
> > Have you checked NumericalMethods package? (is available from the
> Configuration Browser)
> >
>
> Apparently this is a derivative of DHB classes already included in
> SciSmalltalk.
> Did you make some modifications ?
> We already modify/add some code to these classes.
> What do you think about working on the same codebase instead of
> duplicating efforts ?
>
>
The code in NumericalMethods is frozen, in part to preserve the same class
names as in the book.

I have added a couple of methods, specially to build big matrices in an
easier way. I could integrate them, let me check next week because I am
very busy these days.

Hernán


Regards,
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://doesnotunderstand.org/
>
>
>

Re: [Pharo-dev] Time Series in Smalltalk

2014-10-31 Thread Hernán Morales Durand

2014-10-31 11:06 GMT-03:00 Serge Stinckwich :

>
> > On 31 Oct 2014, at 14:42, Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
> >
> >
> >
> > 2014-10-31 6:50 GMT-03:00 Blondeau Vincent <
> vincent.blond...@worldline.com>:
> > Dear Serge,
>
> Hi Hernán,
>
> > That's nice but I will need more statistical functions to calculate
> autocorrelations.
> >
> > Have you checked NumericalMethods package? (is available from the
> Configuration Browser)
> >
>
> Apparently this is a derivative of DHB classes already included in
> SciSmalltalk.
>

Just for the record, my SThub repository is a copy from the first
Squeak/Pharo port at http://www.squeaksource.com/DHBNumerical.html in 2011
(I don't know if SciSmalltalk existed then). For those wondering about the
book, there is a Google Books copy here:

http://books.google.com/books?id=QPX7_MP8w5UC&lpg=PP1&ots=bIsemiaRUC&dq=didier%20besset%20smalltalk&pg=PP1#v=onepage&q=&f=false

Cheers,

Hernán

Re: [Pharo-dev] Super fast delay

2014-10-31 Thread Ben Coman


Ben Coman wrote:

Norbert Hartl wrote:

Am 30.10.2014 um 12:52 schrieb Ben Coman :

Eliot Miranda wrote:
On Wed, Oct 29, 2014 at 12:14 PM, Ben Coman > wrote:

   Holger Hans Peter Freyther wrote:
   On Wed, Oct 29, 2014 at 06:54:57PM +0100, Holger Hans Peter
   Freyther wrote:
   On Wed, Oct 29, 2014 at 10:03:03AM +0100, Norbert Hartl 
wrote:

   Good Evening,
   Hi again,
   I don't know how you debug startUp issues. I just added an
   OrderedCollection
   into the systemdictionary and use it as a log..
   time ./bin/pharo --nodisplay ./TimerTest3.image eval "(Delay
   forSeconds: 3) wait. (Smalltalk at: #Foo) do: [:each |
   FileStream stderr nextPutAll: each printString; cr].1"
   ... old events from saving the image...
   {#handleTimerEvent->7147}
   {#handleTimerEvent->7167}
   {#resumptionTime->7187}
   {#handleTimerEvent->7167}
   {#handleTimerEvent->7187}
   {#start->true}
   {#start->393102159}
   {#start->393102159}
   {#resumptionTime->3279}
   {#handleTimerEvent->279}
   {#adjustResum->-393098880}
   {#restoreWithActiveDelay->266}
   {#adjustResum->-393098601}
   1
   real0m0.294s
   user0m0.244s
   sys 0m0.048s
   So what happens is Delay class>>#startU is called. and
   ActiveDelayStartTime is being set to 393102159. Then the
   delay is being created and resumptionTime is set to 3279.
   At the first time handleTimerEvent runs the milliSecondClock
   jumped backwards from 393102159 to 3279 which leads to
   an adjustment of the time.
   a.) Why does the time jump backwards like this during the
   resumption of the image? "3279" is not the old time nor
   the new starting time.
   b.) So even if that is a "wrap" around. Why does it go
   wrong? Are there unit tests for the clock wraps around?
   There are no unit tests, I guess since its all done using class
   variables its too hard test without disturbing the system.
   Now I have spent the last week refactoring this out to the
   instance-side of a new class "DelayScheduler" which should help with
   getting unit tests.  Its ready for review [1], maybe you could take
   a look.
   [1] https://pharo.fogbugz.com/__default.asp?14261
   
   Maybe it is the same reason delays just don't work after
   image resumption?
   The "first" issue appears that when start is being executed
   that the clock is still wrong. At the same the clock is
   being considered wrapped the resumption time was actually
   already "correct' (3279 instead of 393102159+3279).
   Does this ring a bell?
   holger
   btw, its too late in the night for me to try something, but I have
   been wondering, should the check for clock roll-over occur
   immediately after
   TimingSemaphore wait
   wakes up. That is, before the Schedule and Finish requests are
   handled ???
The check for rollover should be thrown away and the system 
implemented over the VM's support for 64-bit microseconds since 
1901.  It's in the VM, it isn't susceptible to rollover for ~ 50,000 
years, and doesn't require the millisecond clock to be synced to the 
second clock, because all times can be derived from the one 64-bit 
microsecond clock.

--
best,
Eliot

I'll give it a go.
cheers -ben


Super, thanks in advance,

Norbert






This is ready for review as "Delay refactoring (part 2) - change from 
milliseconds to microseconds"

https://pharo.fogbugz.com/default.asp?14353

Note that this continues on from "Delay refactoring (part 1) - move 
scheduler from class-side to instance-side of its own class"

https://pharo.fogbugz.com/default.asp?14261

So load part 1 first if you only want to see the from milliseconds to 
microseconds changes.  Now if you don't like part 1, I'll do the work to 
break out part 2 on its own - but it was simpler for me to work on part 
2 since:
* with instances I could define, run and debug tests without 
interference from the live system-delay-scheduler.

* the code swapping (newCodeEnabled) pattern I'd used for part 1 helped.
* eliminating the clock rollover conditional simplifies what I am 
planning for part 3


I don't have the virtual machine environment to replicate the problem, 
so please report if it this has any effect.


cheers -ben




I've confirmed this works with build 40346
on LinuxMint17 on Virtualbox on OSX.

With the following script test.sh...

#!/bin/bash
for i in `seq 1 20` ;
do
(time pharo-vm-nox ./test.image \
  eval "(Delay forSeconds: 2) wait") 2>&1 > /dev/null | grep real
done


I get...
# bash ./test.sh
real0m0.160s
real0m2.159s
real0m0.161s
real0m0.176s
real0m2.158s
real0m0.160s
real0m0.157s
real0m0.170s
real0m0.154s
real0m0.156s
real0m0.159s
real0m2.161s
real0m0.156s
real0m0.149s
real0m

Re: [Pharo-dev] Time Series in Smalltalk

Re: [Pharo-dev] Time Series in Smalltalk

Re: [Pharo-dev] VersionnerRepositoriesManager - Why clear okAction?

[Pharo-dev] [pharo-project/pharo-core] 500663: 40341

[Pharo-dev] [pharo-project/pharo-core]

[Pharo-dev] [pharo-project/pharo-core] c6c309: 40342

[Pharo-dev] [pharo-project/pharo-core]

[Pharo-dev] LRUCache for high latency stuff

[Pharo-dev] [pharo-project/pharo-core] 787596: 40343

[Pharo-dev] [pharo-project/pharo-core]

[Pharo-dev] Zinc running on privileged ports

Re: [Pharo-dev] Time Series in Smalltalk

Re: [Pharo-dev] Time Series in Smalltalk

Re: [Pharo-dev] Time Series in Smalltalk

Re: [Pharo-dev] Time Series in Smalltalk

Re: [Pharo-dev] Zinc running on privileged ports

Re: [Pharo-dev] Zinc running on privileged ports

[Pharo-dev] [pharo-project/pharo-core] 016101: 40344

[Pharo-dev] [pharo-project/pharo-core]

Re: [Pharo-dev] Super fast delay

Re: [Pharo-dev] Time Series in Smalltalk

Re: [Pharo-dev] Time Series in Smalltalk

Re: [Pharo-dev] Super fast delay

23 matches

Site Navigation

Mail list logo

Footer information