October 2014 - Pharo-dev - lists.pharo.org

Nw Cog VMs available

by Eliot Miranda

...at http://www.mirandabanda.org/files/Cog/VM/VM.r3120/. These contain a few important bug fixes to Spur which will increase stability. CogVM binaries as per VMMaker.oscog-eem.916 Spur: Reimplement deriving the accessorDepth and retrying primitives on primitive failure machinery. Always take the primitive index from newMethod (setting newMethod to a SmallInteger for primitiveDoPrimitiveWithArgs. Have the Cogit always set primitiveFunctionPointer and newMethod for the retry. Add isNonInteger(Non)Immediate: and use it in several of the integer conversion routines that were missing code to exclude Character immediates, with fatal consequences. With these changes the Pharo 4 test suite runs without crashing on the latest Pharo Spur boot image. Fix processWeakSurvivor: so that it answers whether a weak object refers to a young object. The old version only scanned weak fields, ignoring refs to young objs from strong fields. Move check for valid classes from findClassOfMethod: forReceiver: into findClassContainingMethod:startingAt:, hence making findClassOfMethod:forReceiver: et al more robust. Implement safe access to contexts and methods when creating image segments (since internally married contexts and jitted methods have hidden state encoded in odd ways). As a result: Fix baaad bug in SpurMemoryManager>>lastPointerOf: for contexts, caused by transcription from (New)ObjectMemory where the method works on a wing and a prayer because BaseHeaderSize = BytesPerOop. And I can't be arsed to fix it. Fix baaad bug in accessibleObjectAfter: and add an assert to primitiveNextObject to catch similar bugs. Can now enumerate objects in new space, which will sort-of work, but code should really use allObjects. Will fix at the image level as time allows. Eliminate isInSurvivorSpace: in favour of the identical isInPastSpace:. All: Refactor decoding of context instruction pointers so there is only one copy of the code. -- best, Eliot

Oct. 31, 2014

Re: [Pharo-dev] Time Series in Smalltalk

by HernÃ¡n Morales Durand

2014-10-31 11:06 GMT-03:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > > > On 31 Oct 2014, at 14:42, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > > > > > > > > 2014-10-31 6:50 GMT-03:00 Blondeau Vincent < > vincent.blondeau(a)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=did… Cheers, HernÃ¡n

Oct. 31, 2014

Re: [Pharo-dev] Time Series in Smalltalk

by HernÃ¡n Morales Durand

Hi Serge, 2014-10-31 11:06 GMT-03:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > > > On 31 Oct 2014, at 14:42, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > > > > > > > > 2014-10-31 6:50 GMT-03:00 Blondeau Vincent < > vincent.blondeau(a)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/ > > >

Oct. 31, 2014

Re: [Pharo-dev] Super fast delay

by Ben Coman

Norbert Hartl wrote: >> Am 30.10.2014 um 12:52 schrieb Ben Coman <btc(a)openinworld.com>: >> >> Eliot Miranda wrote: >>> On Wed, Oct 29, 2014 at 12:14 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@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 >>> real 0m0.294s >>> user 0m0.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 >>> <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

Oct. 31, 2014

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

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 01610158cd63c7eba02bdb886ede5ae5df90b43c https://github.com/pharo-project/pharo-core/commit/01610158cd63c7eba02bdb88… Author: Jenkins Build Server <board(a)pharo-project.org> 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

Oct. 31, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 31, 2014

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

by Christophe Demarey

Le 31 oct. 2014 Ã 16:19, Sven Van Caekenberghe a Ã©crit : > Hi Christophe, > >> On 31 Oct 2014, at 14:21, Christophe Demarey <Christophe.Demarey(a)inria.fr> 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.

Oct. 31, 2014

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

by Sven Van Caekenberghe

Hi Christophe, > On 31 Oct 2014, at 14:21, Christophe Demarey <Christophe.Demarey(a)inria.fr> 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

Oct. 31, 2014

Re: [Pharo-dev] Time Series in Smalltalk

by 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-bounces@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 <vincent.blondeau(a)worldline.com<mailto:vincent.blondeau@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-bounces@lists.pharo.org<mailto:pharo-dev-bounces@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.blondeau(a)worldline.com<mailto:vincent.blondeau@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/07…) 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 resulting from any virus transmitted.

Oct. 31, 2014

Re: [Pharo-dev] Time Series in Smalltalk

by Blondeau Vincent

> -----Message d'origine----- > De : Pharo-dev [mailto:pharo-dev-bounces@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 > <vincent.blondeau(a)worldline.com> 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.

Oct. 31, 2014