December 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Monkey restored: Spur migration "mostly" finished!

by Tudor Girba

Great job! Doru > On Dec 17, 2015, at 12:19 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > Soâ¦ monkey is running again! > Which means you can restart send your bug reports (and bug fixes)â¦ we are back to business! > > Now, time to fix the remaining problemsâ¦ but you all can help! > > cheers, > Esteban > > > > -- www.tudorgirba.com www.feenk.com "Every successful trip needs a suitable vehicle."

Dec. 19, 2015

CryptoCeps: Encrypted Mushrooms

by Robert Withers

Here is a diagram as it evolves. There are lots of support units with MissionControl and the Meta. Security, Resources, Hospital, Library... Let's anthropomorphize it! Feedback sought ... regards, robert CryptoCeps -- . .. .. ^,^ robert

Dec. 19, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort

by Dimitris Chloupis

I am very excited for such a project. I hope you manage to fix the stdout problem on macos. One thing I would like to see is an expansion of the ability of OSProcess to launch multiple instances of pharo and make them communicate with each other. Thats a way to have pharo running on multiple cores. Maybe establish a framework of communication of images that will be based on the existing design of the fork mechanism in Pharo. Python is doing something similar with multiprocessing module which launches multiple processes of cpython executable and makes them communication with each other through a similar api to its threading module. This way python takes advantage of multiple cores. Python threads like pharo are green threads and pharo like python has a GIL like mechanism. Taking into account that current computers have at least 4 cores, its not a bad idea to speed up pharo like this at least 400% ;) On Sat, Dec 19, 2015 at 3:24 PM Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Dear all, > > I am tremendously happy to announce you that Pharo Consortium will sponsor > yet another development effort. In this particular case, it's my honor to > carry on such an effort and I will be developing and improving a few things > and ideas. All the contract and paperwork has already been done so it's > time to start working. > > Regarding the developments itself, we discussed about these topics: > > 1) Experiment with a simpler yet more limited OSProcess alternative to > execute OS commands. > 2) Improving FileSystem in order to better deal with some POSIX stuff like > symbolic links, unix file permissions, etc etc. > > I have already started with 1). OSProcess is super complete and it > involves some packages (OSProcess / CommandShell) as well as some VM > plugins (OSProcessPlugin, AIOPlugin). OSProcess provides lots of features > (like forking the running image) but we would like to focus only in > executing OS commands. In addition, OSProcess dates from quite some years > ago when many of the current infrastructure features did not exist yet. > > So the idea is to think a simpler alternative to execute OS commands, > using new features such as threaded FFI (for example, for reading async > from pipes), pinned objects, etc. We want to use FFI as much as possible > rather than VM plugins. > > From the image side, we are thinking about an API which would look like a > builder-like API (FileSystem, XStream, etc). > > We have been discussing with David Lewis (OSProcess author) as well as > with Eliot Miranda, Esteban Lorenzano, Damien Pollet, Stephane Ducasse, etc > in order to agree in a project that would be worth doing (otherwise we > would continue using existing tools). And they have all been very kind with > me providing positive discussions. > > I will soon do a survey to measure the most common use cases of OSProcess > and related tools. > > If you have any thought, question, feedback, or whatever, please let us > know. > > Finally, note that I will be doing this project together with another > client's project (Quuve) and my life does not have much free time these > days...so please be patient!!! > > Best, > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 19, 2015

[ANN] Pharo Consortium Sponsored Development Effort

by Mariano Martinez Peck

Dear all, I am tremendously happy to announce you that Pharo Consortium will sponsor yet another development effort. In this particular case, it's my honor to carry on such an effort and I will be developing and improving a few things and ideas. All the contract and paperwork has already been done so it's time to start working. Regarding the developments itself, we discussed about these topics: 1) Experiment with a simpler yet more limited OSProcess alternative to execute OS commands. 2) Improving FileSystem in order to better deal with some POSIX stuff like symbolic links, unix file permissions, etc etc. I have already started with 1). OSProcess is super complete and it involves some packages (OSProcess / CommandShell) as well as some VM plugins (OSProcessPlugin, AIOPlugin). OSProcess provides lots of features (like forking the running image) but we would like to focus only in executing OS commands. In addition, OSProcess dates from quite some years ago when many of the current infrastructure features did not exist yet. So the idea is to think a simpler alternative to execute OS commands, using new features such as threaded FFI (for example, for reading async from pipes), pinned objects, etc. We want to use FFI as much as possible rather than VM plugins. >From the image side, we are thinking about an API which would look like a builder-like API (FileSystem, XStream, etc). We have been discussing with David Lewis (OSProcess author) as well as with Eliot Miranda, Esteban Lorenzano, Damien Pollet, Stephane Ducasse, etc in order to agree in a project that would be worth doing (otherwise we would continue using existing tools). And they have all been very kind with me providing positive discussions. I will soon do a survey to measure the most common use cases of OSProcess and related tools. If you have any thought, question, feedback, or whatever, please let us know. Finally, note that I will be doing this project together with another client's project (Quuve) and my life does not have much free time these days...so please be patient!!! Best, -- Mariano http://marianopeck.wordpress.com

Dec. 19, 2015

Re: [Pharo-dev] pharo vm + plugins

by Robert Withers

I'm sorry for the confusion, Pierce. You can find these plugins in the CryptographyPlugins package in http://www.squeaksource.com/Cryptography. The confusion arose because the vm team just included them so the latest VMMaker pulls them in for us. I am on an Ubuntu 32-bit OS. Thanks so much for looking into this!- robert On 12/19/2015 04:51 AM, Pierce Ng wrote: > On Sat, Dec 19, 2015 at 12:30:19AM -0500, Robert Withers wrote: >> I am looking for DESPlugin, DSAPrims, MD5Plugin and SHA256Plugin. >> they are now in the squeak vmmaker. Evidently not in pharo just yet. > I didn't ask which OS which version you want :-) but looking through my > collection of source and binaries for OSX, Linux and FreeBSD, I have none of > those files, alas. > > From a Pharo 4 image with an Apr 2015 VM, DSAPrims is builtin, and used by > SHA1: > > SmalltalkImage current vm listBuiltinModules > select: [ :x | x beginsWithEmpty: 'DSA' caseSensitive: false ]. > #('DSAPrims VMMaker.oscog-jeanbaptistearnaud.828 (i)') > > SHA1 new primHasSecureHashPrimitive. > true > > SHA1 should give you better performance on Pharo at this time. > > Pierce > -- . .. .. ^,^ robert

Dec. 19, 2015

Re: [Pharo-dev] Some test where Spur more slow than Cog

by Denis Kudriashov

Hi 2015-12-19 4:18 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > and used in some copying code to access indexable fields. Chris Muller > found this in some of his Magma code and so we added a pair of new > primitives, primitiveSlotAt and primitiveSlotAtPut that access any slot > within the sequence of named followed by indexable inst vars, avoiding the > primitive failure. So in Squeak Spur instVarAt: now reads: > > instVarAt: index > "Primitive. Answer a fixed variable in an object. The numbering of the > variables > corresponds to the named instance variables, followed by the indexed > instance > variables. Fail if the index is not an Integer or is not the index of a > fixed variable. > Essential. See Object documentation whatIsAPrimitive." > > <primitive: 173 error: ec> > self primitiveFailed > Same code used in Pharo too. I try same test on latest squeak images: Cog: '10,100 per second. 98.8 microseconds per run.' Spur: '7,610 per second. 131 microseconds per run.'

Dec. 19, 2015

Re: [Pharo-dev] pharo vm + plugins

by Pierce Ng

On Sat, Dec 19, 2015 at 12:30:19AM -0500, Robert Withers wrote: > I am looking for DESPlugin, DSAPrims, MD5Plugin and SHA256Plugin. > they are now in the squeak vmmaker. Evidently not in pharo just yet. I didn't ask which OS which version you want :-) but looking through my collection of source and binaries for OSX, Linux and FreeBSD, I have none of those files, alas. >From a Pharo 4 image with an Apr 2015 VM, DSAPrims is builtin, and used by SHA1: SmalltalkImage current vm listBuiltinModules select: [ :x | x beginsWithEmpty: 'DSA' caseSensitive: false ]. #('DSAPrims VMMaker.oscog-jeanbaptistearnaud.828 (i)') SHA1 new primHasSecureHashPrimitive. true SHA1 should give you better performance on Pharo at this time. Pierce

Dec. 19, 2015

Re: [Pharo-dev] Some test where Spur more slow than Cog

by ClÃ©ment Bera

Hello, In the Smalltalk profiler it shows more time spent in primitive. It could be also, as it is an older version of the spur vm currently used in Pharo, that this problem is already fixed. I can't know the problem for sure as I can't run the VM profiler in Pharo. 2015-12-19 4:18 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Denis, > > On Fri, Dec 18, 2015 at 9:36 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> Hi. >> >> I found case where Spur more slow than Cog. Not much but. >> > > Well, it might be indicative of a soluble problem. One thing that Spur is > slower at is primitive failure; it catches primitive failure in the VM as > potentially caused by primitives encountering forwarders. So many > primitive failure involves a slow scan of the primitives arguments to some > depth to find out if there are any forwarders which should be followed, and > if so the primitive retried. So that means some idioms that use primitive > failure normally will go slower. One of these is instVarAt: which used to > be written > > instVarAt: index > "Primitive. Answer a fixed variable in an object. The numbering of the > variables corresponds to the named instance variables. Fail if the index > is not an Integer or is not the index of a fixed variable. Essential. See > Object documentation whatIsAPrimitive." > > <primitive: 73> > "Access beyond fixed variables." > ^self basicAt: index - self class instSize > > and used in some copying code to access indexable fields. Chris Muller > found this in some of his Magma code and so we added a pair of new > primitives, primitiveSlotAt and primitiveSlotAtPut that access any slot > within the sequence of named followed by indexable inst vars, avoiding the > primitive failure. So in Squeak Spur instVarAt: now reads: > > instVarAt: index > "Primitive. Answer a fixed variable in an object. The numbering of the > variables > corresponds to the named instance variables, followed by the indexed > instance > variables. Fail if the index is not an Integer or is not the index of a > fixed variable. > Essential. See Object documentation whatIsAPrimitive." > > <primitive: 173 error: ec> > self primitiveFailed > > I suspect something like this is happening with the veryDeepCopy code. > You might want to use the profiler on both versions and compare. You might > find an issue. > > HTH > > > >> prototype := BorderedMorph new. >> >> result := [prototype veryDeepCopy ] benchFor: 2 seconds. >> >> In my computer I got: >> >> Cog: a BenchmarkResult(16,982 iterations in 2 seconds 1 millisecond. >> 8,487 per second) >> Spur: a BenchmarkResult(12,507 iterations in 2 seconds 33 milliseconds. >> 6,152 per second). >> >> Is it expected behavior for such case? >> > > > > -- > _,,,^..^,,,_ > best, Eliot >

Dec. 19, 2015

Re: [Pharo-dev] pharo vm + plugins

by Robert Withers

On 12/19/2015 12:22 AM, Pierce Ng wrote: > On Fri, Dec 18, 2015 at 07:48:00PM +0100, Sven Van Caekenberghe wrote: >> Maybe a silly question, but aren't VM plugins interchangeable between the >> Pharo and Squeak VM ? I know for a fact that the SSL plugin used to be like >> that, maybe it still is. > Pharo's is named libSqueakSSL.so while Squeak's is named SqueakSSL. I don't > know whether renaming one plugin file will allow it to be used with the other > VM. I tried the rename and it didn't work. That would have been great! thank you, robert > Pierce > -- . .. .. ^,^ robert

Dec. 19, 2015

Re: [Pharo-dev] pharo vm + plugins

by Robert Withers

I am looking for DESPlugin, DSAPrims, MD5Plugin and SHA256Plugin. they are now in the squeak vmmaker. Evidently not in pharo just yet. On 12/19/2015 12:23 AM, Pierce Ng wrote: > On Fri, Dec 18, 2015 at 01:55:14PM -0500, Robert Withers wrote: >> I tried this but it no longer seems to work. Do you have the lib* >> plugins, by chance? > What files are you looking for? > > Pierce > -- . .. .. ^,^ robert

Dec. 19, 2015