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

ConfigurationOfIDE working again

by Pavel Krivanek

Hi, the job for ConfigurationOfIDE that loads GUI and tools (not all for now) to minimal Pharo is now producing usable image again.: https://ci.inria.fr/pharo/view/5.0-SysConf/job/Pharo-5.0-ConfigurationOfIDE/ We definitely need to find a way how to keep it green and improve and clean it instead of spending one forenoon once in a while by fixing it ;-) Cheers, -- Pavel

Nov. 19, 2015

Re: [Pharo-dev] EyeInspector with subclasses of ProtoObject

by Guillermo Polito

I know we can :) and I did some prototypes already as part of my thesis. The question is if that is a design we *want* or not. > On 18 nov 2015, at 5:29 p.m., ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > 2015-11-18 8:43 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: > Iâd like to discuss also the possibility to add those low level operations on mirrors objects, that could be packaged separately from the kernel of the language. Adding them on a first step is easy, then making all tools use them is the hard/timeconsuming part, yes. > > All the needed operations already exist. You can put them on your mirror objects without any problem. > > > >> On 18 nov 2015, at 12:35 p.m., ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>> wrote: >> >> Hello, >> >> This is known and was discussed on the bug tracker. >> >> The problem is that currently Pharo has many tools and classes: EyeInspector in the debugger, GTInspector outside, the debugger itself, the in-image interpreter in the Context class ... that need to be changed to support debugging objects that basically cannot receive any message. >> >> We are aware of the solution but fixing it for all the toolkits and classes is quite some work. In addition, if not tested, someone will break it because he won't understand that an inspected object can't receive any message because the expected behavior of an object with no DNU behavior and no methods inherited from Object is to freeze the system. >> >> It's a lot of fun doing that though. >> >> Clement >> >> 2015-11-17 21:39 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: >> Hi Esteban, >> >> On Tue, Nov 17, 2015 at 1:37 PM, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: >> 2015-11-17 14:37 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: >> > Hi Esteban, >> > >> > I think EyeInspector needs to handle classes that don't inherit from >> > Object specially. Instead of asking the instance it should ask the class. >> > You should be able to use the Context methods for mirror primitives to >> > extract state without sending messages to the instance. Then the special >> > version of EyeInspector for ProtoObject subclasses can ask this like >> >> Yes, an special inspector for ProtoObject subclasses would be required, but I couldn't find one already suited for this purpose. >> >> > (thisContext objectClass: object) isIndexable ifTrue: >> > [size := thisContext objectSize: object] >> >> I don't know if your code was meant to be accurate or just a guideline of how this could be implemented, but Context doesn't implement #objectClass: nor #objectSize: >> >> >> Find attached. I think you'll find they are in the Spur version. You might think of back-porting their use in Context form Spur; that'll make the debugger able to handle proxies. >> >> > Basically both the Inspector and the Debugger's execution simulation >> > machinery need to treat encapsulators such as MessageArchiver with kid >> > gloves. One *must not* cause inspecting or debugging to send messages >> > through the encapsulator. Instead, all access to the object should be >> > through primitives that don't send messages to the objects. >> >> I know that dealing with Proxies and similar objects is tricky, I had to deal with my own subclasses of ProtoObject in Dolphin, but there the class implemented all that was needed to interact with the environment tools. >> >> Hiwever, to me all this is a kind of black magic, I read the blue book years ago and can understand it, but I do understand it as I understand the mechanics of my car, however when it breaks down I take it to the specialist :) >> >> Well, the thing to think of is that inside the VM objects are just a sequence of words, and the VM, while it sends messages, doesn't send messages to objects to update their state; it just accesses the state directly. So in an execution simulation method such as >> >> Context methods for instruction decoding >> pushReceiverVariable: offset >> self push: (receiver instVarAt: offset + 1) >> >> that will send the message instVarAt: to the receiver, and if the receiver is a proxy, that will go through the proixie's doesNotUnderstand: method and send instVarAt: the the object the proxy wraps, which won't do the right thing at all. Instead it needs to be written >> >> Context methods for instruction decoding >> pushReceiverVariable: offset >> self push: (self object: receiver instVarAt: offset + 1) >> >> which reaches into the object without sending any messages to it. I understand that this will appear in Spur, because I made it part of the bootstrap, but if I were you I would integrate these changes into the current version asap. The debugger won't work properly with proxies, encapsulators etc otherwise. >> >> _,,,^..^,,,_ >> best, Eliot >> > >

Nov. 19, 2015

Re: [Pharo-dev] Preparing for the (already here) future world of multi-core PCs

by EuanM

I agree that parallelism and concurrency are different things. For easy parallelism : - a multi-VM version of something like PharoLauncher. - tools for tailor each VM + Image - tools to manage and track each running VM + Image. - tolls to try to mak sure that different running VMs and images have their own core, and that VMs can be closed down so that VMs never are sharing (unless you want them to) All we need to do is make sure that the VM and image don't have baked-in assumptions about being the only VM on the physical machine baked in to each VM and the Smalltalk above it.) The task for the end-user app developers then becomes seeing what bundles of functionality are sufficiently decoupled from the others that they can be set adrift in their own VM. (I'm even starting to think of reinventing the multi-user server. A single 16 core PC, with 16 4-core Raspberry Pis connected, and each RPi's user taking control of a single app on a single VM single core on the PC). (Then you could have a quite a decent network for $140 per workstation (PiCEED + keyboard + mouse) , and one fast laptop as the central server Cheap, and easy to transport to remote locations. (But I digress) Concurrency is a deeper and harder problem for a Smalltalk, I agree. On 18 November 2015 at 23:36, Michael J. Forster <mike(a)sharedlogic.ca> wrote: > This is no small issue, nor a single one. > > Be careful to distinguish concurrency from parallelism. See Rob Pike's > talk/slides on this. > > Note that many systems can benefit from a concurrent design--even on a > single core, where no parallel execution is possible--because the problem is > inherently concurrent; note how effectively shared-nothing approaches with > Erlang, Go, or Scala/Akka have been used in such domains. > > In other domains, parallelism--especially nested data parallelism--is more > important than concurrency (see > http://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html) > The Haskell and other communities have been exploring this with shared > memory approaches like STM. > > So, to better use the slowing but increasing number of cores in today's > hardware, we need to understand the many very different use cases and > approaches. The lowest-hanging fruit in the Pharo/Squeak world might be to > rework the vm and process scheduler to support massive numbers of lighter > weight processes similar to Erlang. Check out Andrew Blacks "Erlang in > Pharo", http://www.squeaksource.com/Erlang.html. > > Best, > > Mike > > > > > -- > View this message in context: http://forum.world.st/Preparing-for-the-already-here-future-world-of-multi-… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Nov. 19, 2015

Hapao2>>addMethodEdges:scope:view MNU

by sheridan＠sheridan-mahoney.com

Hi, I'm trying to run Hapao2 on the String class and its subclasses, and encountered an error. I downloaded the latest image (50452) for Windows, loaded Roassal2 and S2py, and tried to run the following code: (Hapao2 runTestsForClasses: String withAllSubclasses , StringTest withAllSubclasses) visualize. This worked in previous versions. This time I got an MNU error in Hapao2 >> addMethodEdges:scope:view: It looks like RTEdgeBuilder isn't loaded. Can someone tell me if I am missing a step? Many thanks, Sheridan

Nov. 19, 2015

Re: [Pharo-dev] Preparing for the (already here) future world of multi-core PCs

by Michael J. Forster

This is no small issue, nor a single one. Be careful to distinguish concurrency from parallelism. See Rob Pike's talk/slides on this. Note that many systems can benefit from a concurrent design--even on a single core, where no parallel execution is possible--because the problem is inherently concurrent; note how effectively shared-nothing approaches with Erlang, Go, or Scala/Akka have been used in such domains. In other domains, parallelism--especially nested data parallelism--is more important than concurrency (see http://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html) The Haskell and other communities have been exploring this with shared memory approaches like STM. So, to better use the slowing but increasing number of cores in today's hardware, we need to understand the many very different use cases and approaches. The lowest-hanging fruit in the Pharo/Squeak world might be to rework the vm and process scheduler to support massive numbers of lighter weight processes similar to Erlang. Check out Andrew Blacks "Erlang in Pharo", http://www.squeaksource.com/Erlang.html. Best, Mike -- View this message in context: http://forum.world.st/Preparing-for-the-already-here-future-world-of-multi-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 18, 2015

Re: [Pharo-dev] Preparing for the (already here) future world of multi-core PCs

by Chris Muller

If you are on Linux, there is a add-on package for OSProcess called CommandShell which includes a class called RemoteTask. It lets you fork a block of code to a separate OS thread and return the result to the calling image via serialization (Fuel or other). IIUC, it takes advantage of Linux memory copy-on-write sharing, so the forking overhead should be proportional to the amount of work done (e.g., memory changes). On Wed, Nov 18, 2015 at 3:56 PM, EuanM <euanmee(a)gmail.com> wrote: > (And yes, I know it's actually here already). > > Now that clock-speed rises have stalled, basically forever, desktop > and laptop PCs are growing ever-increasing numbers of cores in their > CPU chips, > > Is there design and conceptualisations work going on to see how Pharo > will deal with providing increased access to the additional processing > power? > > > One thing I have been thinking about is a set of co-operating Pharo VMs. > > But given memory and storage are shared, this may not provide as large > a benefit as we'd like. > > Or moving Pharo into being having multiple native-threads, and taking > Pharo into a concurrency route. > > Or - whatever it is I am too ignorant to see. > > This all strikes me (like the way Smalltalk is extending its system > boundary out onto the web with Monticello, Pharo is extending that > via the Configuration Browser and Versionner) as a way Pharo could > build on Smalltalk, while becoming its own thing. (as opposed to > being a Smalltalk with a very big set of classes). > > Is there thought work going on in this area yet? > > DabbleDB had a system of running multiple VMs on a server, and > hot-swapping them in and out depending on their CPU loading. > > Did that ever get developed intop a more generally-useful facility? >

Nov. 18, 2015

Re: [Pharo-dev] Preparing for the (already here) future world of multi-core PCs

by Levente Uzonyi

Searching with the right keywords should have directed you to HydraVM[1] and RoarVM[2][3], which are two different approaches to this problem. Both projects are stalled, and would require significant effort to merge them with the current VM sources. RoarVM also requires images changes, because it brings the concurrency problems up to the Smalltalk level. There are plans for Spur to have some kind of support for multi-core machines, though that'll be different than what you described, because Smalltalk code will still be executed by one core at a time. Levente [1] http://forum.world.st/ANN-Hydra-VM-A-multi-core-capable-Croquet-VM-td106298… [2] http://stefan-marr.de/2010/11/roarvm-the-manycore-squeakvm/ [3] https://github.com/smarr/RoarVM On Wed, 18 Nov 2015, EuanM wrote: > (And yes, I know it's actually here already). > > Now that clock-speed rises have stalled, basically forever, desktop > and laptop PCs are growing ever-increasing numbers of cores in their > CPU chips, > > Is there design and conceptualisations work going on to see how Pharo > will deal with providing increased access to the additional processing > power? > > > One thing I have been thinking about is a set of co-operating Pharo VMs. > > But given memory and storage are shared, this may not provide as large > a benefit as we'd like. > > Or moving Pharo into being having multiple native-threads, and taking > Pharo into a concurrency route. > > Or - whatever it is I am too ignorant to see. > > This all strikes me (like the way Smalltalk is extending its system > boundary out onto the web with Monticello, Pharo is extending that > via the Configuration Browser and Versionner) as a way Pharo could > build on Smalltalk, while becoming its own thing. (as opposed to > being a Smalltalk with a very big set of classes). > > Is there thought work going on in this area yet? > > DabbleDB had a system of running multiple VMs on a server, and > hot-swapping them in and out depending on their CPU loading. > > Did that ever get developed intop a more generally-useful facility? > >

Nov. 18, 2015

Preparing for the (already here) future world of multi-core PCs

by EuanM

(And yes, I know it's actually here already). Now that clock-speed rises have stalled, basically forever, desktop and laptop PCs are growing ever-increasing numbers of cores in their CPU chips, Is there design and conceptualisations work going on to see how Pharo will deal with providing increased access to the additional processing power? One thing I have been thinking about is a set of co-operating Pharo VMs. But given memory and storage are shared, this may not provide as large a benefit as we'd like. Or moving Pharo into being having multiple native-threads, and taking Pharo into a concurrency route. Or - whatever it is I am too ignorant to see. This all strikes me (like the way Smalltalk is extending its system boundary out onto the web with Monticello, Pharo is extending that via the Configuration Browser and Versionner) as a way Pharo could build on Smalltalk, while becoming its own thing. (as opposed to being a Smalltalk with a very big set of classes). Is there thought work going on in this area yet? DabbleDB had a system of running multiple VMs on a server, and hot-swapping them in and out depending on their CPU loading. Did that ever get developed intop a more generally-useful facility?

Nov. 18, 2015

Re: [Pharo-dev] News about FastTable

by Thierry Goubier

Hi Cyril, Le 18/11/2015 10:53, Ferlicot D. Cyril a Ã©crit : > Hi everyone! > > I just wanted to say that I added a first version of Tree in FastTable > and I corrected some bugs. > > If someone want to try it and give some feedback you can see some > examples on the latest Pharo 5 in FTExamples class. Some feedback: On exampleTree1, * expand AJBaseReg, * select AJx87Register, * then collapse AJBaseReg... selection becomes AJCallInfo. * expand AJBaseReg selection becomes AJx87Register Listening to the FTSelectionChanged announcement when doing the sequence above shows that no events are sent during collapse/expand showing the selection change in the tree (i.e. switching from AJx87Register to AJCallInfo and back). Normal GUI behavior is that selection switch to collapsed item if selection was previously among that item children. Regards, Thierry > With Usman we also worked on the glamour version of FastTable begun by > Esteban. > You can see some examples of FastList, FastTable, FastOutlineList and > FastTree in the GLMExamplesBrowser after executing this: > > (ConfigurationOfFastTable project version: #stable) load: #glamour > > Every feedback is welcome :) >

Nov. 18, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 18, 2015