March 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] A Unifying Mechanism for the Implementation of Concurrency Abstractions

by Stefan Marr

Added missing links below, thanks Nick for pointing it out. On 09 Mar 2012, at 15:38, Stefan Marr wrote: > Hi, beware the shameless plug: > > Our paper > > Identifying A Unifying Mechanism for the > Implementation of Concurrency Abstractions on > Multi-Language Virtual Machines [1] > > introduces an ownership-based Meta-object Protocol (MOP) to enable the > enforcement of the various concurrency semantics required by the different > programming models discussed in literature. > > The prototypical implementation is done on top of Pharo 1.3 and available at > SqueakSource3 [2] under the MIT license. > > You might be interested in it to experiment with new concurrent programming > models. Typically, green threads are enough to be exposed to race conditions > and other correctness problems. Thus, a CogVM is sufficient for experiments. > RoarVM support is coming later, enabling experiments with the parallel aspects > of these programming models as well. > > For the evaluation, we implemented a couple of concurrency models on top of > it. Most notably, you can use Clojure-like agents, AmbientTalk-like actors, > a basic CSP, Active Objects, and an STM that is a port of Lukas Renggli's > work. These concurrency models work out of the box with the Metacello > configuration given below (to the degree they were tested and benchmarked). > > You might also be interested in the AmbientTalkST implementation that was done > as comparison as well as the direct port of Lukas' STM to Pharo 1.3 [3]. > > Please see the paper [1] for an introduction to the MOP and an example how to > use it to make objects immutable and implement Clojure's agents guaranteeing > all required semantics. > > The paper's abstract: > > Supporting all known abstractions for concurrent and parallel programming > in a virtual machines (VM) is a futile undertaking, but it is required to > give programmers appropriate tools and performance. Instead of supporting > all abstractions directly, VMs need a unifying mechanism similar to > INVOKEDYNAMIC for JVMs. > > Our survey of parallel and concurrent programming concepts identifies > concurrency abstractions as the ones benefiting most from support in a VM. > Currently, their semantics is often weakened, reducing their engineering > benefits. They require a mechanism to define flexible language guarantees. > > Based on this survey, we define an ownership-based meta-object protocol as > candidate for VM support. We demonstrate its expressiveness by > implementing actor semantics, software transactional memory, agents, CSP, > and active objects. While the performance of our prototype confirms the > need for VM support, it also shows that the chosen mechanism is > appropriate to express a wide range of concurrency abstractions in a > unified way. > > The code can be loaded into a fresh Pharo 1.3 image [4] with the following > Gofer expression. However, be aware this is experimental software. > Furthermore, note that you will need to acknowledge changes to the Process > class: > > > Gofer new > url: 'http://ss3.gemstone.com/ss/Omni'; > package: 'ConfigurationOfOmni'; > load. > (Smalltalk at: #ConfigurationOfOmni) loadTOOLS2012. > > As mentioned before, the paper gives some examples. The definition of > different concurrency semantics can be found in subclasses of OstDomain. > Examples of how to use any of the existing concurrency models are either the > unit tests, or the included benchmarks. > > Note that the MOP based implementation of AmbientTalkST does use the same > class names. Thus, to use the ad-hoc implementation, you will need to load it > into a different image: > > Gofer new > url: 'http://ss3.gemstone.com/ss/Omni'; > package: 'ConfigurationOfAmbientTalkST'; > load. > (Smalltalk at: #ConfigurationOfAmbientTalkST) loadTOOLS2012. > > Similarly, the port of Lukas Renggli's STM to Pharo needs to be loaded > into a separate image, too. This version is not using our MOP: > > Gofer new > url: 'http://ss3.gemstone.com/ss/LRSTM'; > package: 'ConfigurationOfLRSTM'; > load. > (Smalltalk at: #ConfigurationOfLRSTM) loadTOOLS2012. > > > Acknowledgements: > > Thanks to Lukas for his STM implementation I used here. It was also a strong > inspiration for my bytecode transformation approach. > > Best regards > Stefan [1] http://soft.vub.ac.be/~smarr/2012/03/identifying-a-unifying-mechanism-for-t… [2] http://ss3.gemstone.com/ss/Omni.html [3] http://ss3.gemstone.com/ss/LRSTM.html [4] http://gforge.inria.fr/frs/download.php/29273/Pharo-1.3-13315.zip -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

March 9, 2012

Re: [Pharo-project] Socket listenOn: 0 & accept

by Philippe Marschall

On 03/09/2012 04:44 PM, Sven Van Caekenberghe wrote: > Most socket API's allow for the creation of a server socket on the next available port, often by specifying 0 instead of a port. When the socket is bound, one can retrieve the local port and let the client(s) know. I tried to do that in Pharo today, and these steps seem to work, by accepting an incoming connection gives a primitive failed. Stupid n00b question, isn't 0 a valid port number? Cheers Philippe

March 9, 2012

Re: [Pharo-project] [ANN] A Unifying Mechanism for the Implementation of Concurrency Abstractions

by Nick Ager

BTW I think you missed the link to you paper. Google found it at: http://soft.vub.ac.be/~smarr/downloads/tools12-smarr-dhondt-identifying-a-u… On 9 March 2012 15:26, Nick Ager <nick.ager(a)gmail.com> wrote: > Hi Stefan, > > =Our paper >> >> >> Identifying A Unifying Mechanism for the >> Implementation of Concurrency Abstractions on >> Multi-Language Virtual Machines [1] >> > > I'm really looking forward to digesting this. I'm been flirting with > Clojure and have been enviously looking at their STM, so this sounds really > interesting and potentially very timely for Pharo and Smalltalk. > > Thanks > > Nick >

March 9, 2012

[Pharo-project] Socket listenOn: 0 & accept

by Sven Van Caekenberghe

Most socket API's allow for the creation of a server socket on the next available port, often by specifying 0 instead of a port. When the socket is bound, one can retrieve the local port and let the client(s) know. I tried to do that in Pharo today, and these steps seem to work, by accepting an incoming connection gives a primitive failed. Anyone tried this ? | socket | socket := Socket newTCP. socket listenOn: 0. [ [ Transcript crShow: 'Port is ', socket localPort printString. (socket waitForAcceptFor: 60) ifNotNil: [ :client | | data | data := client receiveDataTimeout: 30. Transcript crShow: 'Received ', data asString. data ifNotNil: [ client sendData: data reverse; close ] ]. ] ensure: [ socket close ] ] fork. I am running the Pharo Cog VM on Mac OS X using Pharo 1.4. Thx, Sven

March 9, 2012

Re: [Pharo-project] [ANN] A Unifying Mechanism for the Implementation of Concurrency Abstractions

by Nick Ager

Hi Stefan, =Our paper > > Identifying A Unifying Mechanism for the > Implementation of Concurrency Abstractions on > Multi-Language Virtual Machines [1] > I'm really looking forward to digesting this. I'm been flirting with Clojure and have been enviously looking at their STM, so this sounds really interesting and potentially very timely for Pharo and Smalltalk. Thanks Nick

March 9, 2012

Re: [Pharo-project] ClassBuilder depending -in some way- on text

by Guillermo Polito

I tagged it as 1.5 ;) http://code.google.com/p/pharo/issues/detail?id=5456&thanks=5456&ts=1331306… On Fri, Mar 9, 2012 at 7:09 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 9 March 2012 04:28, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > > On Thu, Mar 8, 2012 at 5:17 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> On 9 March 2012 01:22, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >>> ClassBuilder>>validateClassName: aString > > ... > >>> self notify: aString asText allBold, > >>> ' already exists!\Proceed will store over it.' > >>> > >>> Is it right to do that asText allBold there? :S > >>> Shouldn't an exception be raised instead? > >>> > >>> Do I open a ticket? > >>> > >> Yes. > >> We should kill dependency by removing asText asBold. > >> Notifications should not accept rich-formatted text anyways, > >> because not all ui managers can handle it (now we having command-line > >> ui manager > >> which prints message on console). > >> > > Maybe have the command-line ui manager dumb down the representation - > > I'm sure this isn't the only place. > > > > Guille, > > this likely pre-dates Exceptions (or at least wide-spread use of > > them). A much better direction is to use exceptions (or > > Announcements?) here, and have a process capture them and display > > appropriately for what they can display. The mechanism should probably > > include Class name and exception text, which could be rich-formatted > > as above, or plain formatted for command-line UI, or interrogated for > > other observers. > > > if you replace it with exception, it doesn't means that exception should > use text and bold.. > so... > > > Just suggestions. > > > > -Chris > > > > > > -- > Best regards, > Igor Stasenko. > >

March 9, 2012

Re: [Pharo-project] Increase populatity of Pharo by doing some Killer-OpenSource-Tools

by Stefan Krecher

Am 9. MÃ¤rz 2012 15:01 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> A simple and good looking Ticketing-System for use in an agile team >> would be a good thing - it's a CRUD-Application with some Reporting >> and maybe some eye candy. > > Why don't you start based on experience to build a tool and share with us. i guess, that's what i'm going to do - my problem is, that i'm quite new too seaside and have no experience with building "eyecandy". I work at the server-side ... or deal with projectmanagement-stuff >> Is anyone interested in creating some OpenSource-Projects for use in a >> wider range? Those Tools should look "sexy" and should be easy to try >> (OneClick) or to install as a Service. > > Yes we are lot of people interested in that. Just quite busy. that's a problem. But let me dream: If pharo was organized as a scrum-project and if i was the product owner, i would suspend the current pharo development and instruct the team to work the complete next sprint (e.g. 4 weeks) on an OpenSource-Project for some general use. Imagine what a bunch of pharo developers could create in 4 weeks ... And if companies start to evaluate and use the new software, this would be a big boost for pharo/ smalltalk. It would be a complete new way of pushing an Open Source Project. regards, Stefan

March 9, 2012

Re: [Pharo-project] new CI Job: Project Pharo Kernel Reload Tests-Unix

by Marcus Denker

On Mar 9, 2012, at 1:31 PM, Pavel Krivanek wrote: > Hi, > > I created a new Jenkins job named "Project Pharo Kernel Reload > Tests-Unix". It is the same job as Pharo 1.4 Tests-Unix but with Pharo > Kernel Reload as the base. > > In ideal case it should have the same set of failing tests as Pharo > 1.4 Tests-Unix (zero would be nice ;-)). Currently it has one more > failing job: Tests.Release.ReleaseTest.testUndeclared. But I think it > is a big achievement in itself :-) > Very nice! -- Marcus Denker -- http://marcusdenker.de

March 9, 2012

[Pharo-project] [ANN] A Unifying Mechanism for the Implementation of Concurrency Abstractions

by Stefan Marr

Hi, beware the shameless plug: Our paper Identifying A Unifying Mechanism for the Implementation of Concurrency Abstractions on Multi-Language Virtual Machines [1] introduces an ownership-based Meta-object Protocol (MOP) to enable the enforcement of the various concurrency semantics required by the different programming models discussed in literature. The prototypical implementation is done on top of Pharo 1.3 and available at SqueakSource3 [2] under the MIT license. You might be interested in it to experiment with new concurrent programming models. Typically, green threads are enough to be exposed to race conditions and other correctness problems. Thus, a CogVM is sufficient for experiments. RoarVM support is coming later, enabling experiments with the parallel aspects of these programming models as well. For the evaluation, we implemented a couple of concurrency models on top of it. Most notably, you can use Clojure-like agents, AmbientTalk-like actors, a basic CSP, Active Objects, and an STM that is a port of Lukas Renggli's work. These concurrency models work out of the box with the Metacello configuration given below (to the degree they were tested and benchmarked). You might also be interested in the AmbientTalkST implementation that was done as comparison as well as the direct port of Lukas' STM to Pharo 1.3 [3]. Please see the paper [1] for an introduction to the MOP and an example how to use it to make objects immutable and implement Clojure's agents guaranteeing all required semantics. The paper's abstract: Supporting all known abstractions for concurrent and parallel programming in a virtual machines (VM) is a futile undertaking, but it is required to give programmers appropriate tools and performance. Instead of supporting all abstractions directly, VMs need a unifying mechanism similar to INVOKEDYNAMIC for JVMs. Our survey of parallel and concurrent programming concepts identifies concurrency abstractions as the ones benefiting most from support in a VM. Currently, their semantics is often weakened, reducing their engineering benefits. They require a mechanism to define flexible language guarantees. Based on this survey, we define an ownership-based meta-object protocol as candidate for VM support. We demonstrate its expressiveness by implementing actor semantics, software transactional memory, agents, CSP, and active objects. While the performance of our prototype confirms the need for VM support, it also shows that the chosen mechanism is appropriate to express a wide range of concurrency abstractions in a unified way. The code can be loaded into a fresh Pharo 1.3 image [4] with the following Gofer expression. However, be aware this is experimental software. Furthermore, note that you will need to acknowledge changes to the Process class: Gofer new url: 'http://ss3.gemstone.com/ss/Omni'; package: 'ConfigurationOfOmni'; load. (Smalltalk at: #ConfigurationOfOmni) loadTOOLS2012. As mentioned before, the paper gives some examples. The definition of different concurrency semantics can be found in subclasses of OstDomain. Examples of how to use any of the existing concurrency models are either the unit tests, or the included benchmarks. Note that the MOP based implementation of AmbientTalkST does use the same class names. Thus, to use the ad-hoc implementation, you will need to load it into a different image: Gofer new url: 'http://ss3.gemstone.com/ss/Omni'; package: 'ConfigurationOfAmbientTalkST'; load. (Smalltalk at: #ConfigurationOfAmbientTalkST) loadTOOLS2012. Similarly, the port of Lukas Renggli's STM to Pharo needs to be loaded into a separate image, too. This version is not using our MOP: Gofer new url: 'http://ss3.gemstone.com/ss/LRSTM'; package: 'ConfigurationOfLRSTM'; load. (Smalltalk at: #ConfigurationOfLRSTM) loadTOOLS2012. Acknowledgements: Thanks to Lukas for his STM implementation I used here. It was also a strong inspiration for my bytecode transformation approach. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

March 9, 2012

Re: [Pharo-project] more Nautilus feed back

by Fabrizio Perin

Hi, I just started to play with nautilus so this is just a quick feedback: - Are the icons on the packages really useful? I think they just overload the list with redundant information which is not really useful. Can they be simply removed? - When I tried to run a test class (ZnClientTests just to try it out) with several tests inside a big stack of bluish transparent boxes started to flood the left side of the image. Moreover for every failing assertion I get a debugger open. Which is the idea behind this? First I cannot do TDD. Can we have just one debugger window open at the time (for instance with the first failing assertion)? Second the image is polluted with elements which confuse me. Can we have just one bluish box with the whole results report? Third, the rendering of all this elements is very slow. I will play a bit more with it and I will give you more feedback. Regards, Fabrizio 2012/3/9 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > Interesting proposition, I will keep that on my desktop :) > > Thanks > Ben > > On Mar 9, 2012, at 12:27 PM, Helene Bilbo wrote: > > > > > Igor Stasenko wrote > >> > >> so then go finish arts and design schools (min 5 years each). and only > >> then you may get back and continue working on nautilus! Hurry up. :) > >> > >> I can also easily tell what i don't like in Nautilus. Much harder is > >> to propose alternative. > >> > > So after finishing art school i propose a better UI in the attached > drawing. > > It gets rid of all Toggle-Buttons except one for the comments: > > > > http://forum.world.st/file/n4459175/nautilusui.jpg > > > > Good Luck with the exams, Helene. > > > > > > -- > > View this message in context: > http://forum.world.st/more-Nautilus-feed-back-tp4457416p4459175.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > >

March 9, 2012