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

Re: [Pharo-project] Exception handling and cull: [ Xtreams port to Squeak - second wave ]
by Nicolas Cellier Oct. 11, 2010

Oct. 11, 2010

2010/10/11 <mkobetic(a)gmail.com>: > "Sven Van Caekenberghe"<sven(a)beta9.be> wrote: >> I tried to follow your different releases in Pharo 1.1.1, right now I have 433 tests, 3 failures (#testReadWriteLargeAmount), 11 errors (#..base64 and #..multipleBufferSize). If will send you the report. >> >> I have been trying some of the examples from the doc pages (google code project), this simple one still fails: >> >> ((1 to: 10) reading collecting: [:x | x * x]) rest > > Ah, that's because of the use of #cull: like semantics with exception handlers in some places, mostly > > Â Â Â Â ... on: Incomplete do: #count. > > We can certainly replace all those with regular block style. > I see, #handleSignal: just calls valueWithPossibleArgument: instead of #cull... I don't well see the interest of adding arguments to #on:do: handler, since they would all be filled with nils... IMO, this is because we didn't have #cull: previously, so we used an existsing more powerfull version. To me, it should be self to just send #cull: Nicolas

2 1

[Pharo-project] [CfPart] BoF: Non-deterministic Programming for Manycore Systems at SPLASH'10
by Stefan Marr Oct. 11, 2010

Oct. 11, 2010

============================================================================ Call for Participation Non-deterministic Programming for Manycore Systems Birds of a Feather Tuesday, October 19, starting 5:30pm Reno/Tahoe, Nevada, 2010. Co-located with SPLASH 2010 http://soft.vub.ac.be/~smarr/bof_non-determenistic_programming.html ============================================================================ Non-deterministic Programming: A Solution for the Manycore Challenge? Informal Workshop on the Opportunities of Embracing Non-determinism in a Highly Parallel World Goal ---- This BoF is meant to bring together people who are interested in solving the challenges that the fine-grained parallelism of manycore and exascale systems present. Today, non-determinism is usually considered a problem researchers have to solve when they confronted with parallel programming. However, non-deterministic programming and its potential has been the subject of research for decades past. With the increasing and unavoidable degree of parallelism, it may be the time to discuss it from a new perspective. Thus, the main question of the workshop is, what if the downsides of non-determinism are outweighed by its benefits? We like to discuss the question of how a programming model for non-deterministic parallel programming could be designed. Thus, we want to think about what challenges need to be overcome and what research questions need to be formulated. Of interest are also which classic problems, for instance sorting, could be solved in a non-deterministic manner, and what kind of computational problems could benefit from speedups provided by additional parallelism even when trading off precision for speed. Attendance ---------- This Birds of a Feather is supposed to propose and discus new ideas, without any restriction of the creativity of its attendees. Every attendee is welcome to give a brief presentation, show a demo, or just engage into a discussion with the audience. Renaissance Project ------------------- This BoF will also be used as a venue to present the Renaissance Virtual Machine (RVM) of IBM Research[3]. On this occasion, the RVM will be opensourced and attendees will have the opportunity to get introduced to the technical details of it. The RVM is meant to provide a common foundation for research regarding non-deterministic parallel programming for manycore systems. It is a Squeak/Pharo compatible Smalltalk VM supporting a classic shared-memory programming model. Thus, the programmer has the illusion of a single object heap on which Smalltalk Processes can work in parallel. On top of the RVM, Ly was developed to embrace non-determinism and to harness emergence. The first results will be reported in an Onward! presentation on Thursday afternoon [1]: Harnessing Emergence for Manycore Programming: Early Experience Integrating Ensembles, Adverbs, and Object-based Inheritance by David Ungar, Sam S. Adams Confirmed Participants ---------------------- David Ungar, Doug Kimelman, IBM Research Brief introduction into the Renaissance project and demo of the current status of their Ly/Sly language and manycore virtual machine. Max OrHai, Andrew Black, Portland State University Giving an overview of an example application to test the Renaissance ensemble code as well as an outlook to a scalable non-deterministic parallel sorting algorithm. Theo D'Hondt, Vrije Universiteit Brussel Lessons from the past: Recapitulating the relations of non-deterministic programming, AI, and highly parallel systems like Connection Machine. Organizers ---------- Theo D'Hondt, Software Languages Lab, Vrije Universiteit Brussel Stefan Marr, Software Languages Lab, Vrije Universiteit Brussel [1] http://splashcon.org/program/onward-short-papers/154-onward-short-papers-b [2] http://splashcon.org/schedule/tuesday-oct-19-/235 [3] https://researcher.ibm.com/researcher/view_project.php?id=245 -- 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

1 0

[Pharo-project] Xtreams hook to the holly Squeak TextEncoder
by Nicolas Cellier Oct. 11, 2010

Oct. 11, 2010

So, I updated Xtreams-Transforms to fit Cincom public store version 52. Then I added Xtreams-SqueakTextConverter to provide a DialectConverter. I didn't name it Xtreams-SqueakEncoder because I'd like to let room for cleaner classes. I didn't make any effort to support backup/restore State My version can now execute: (((ByteArray new writing encoding: 'utf8') nextPutAll: 'Ã Ã©'; conclusion) reading encoding: 'utf8') rest Cheers Nicolas

1 0

Re: [Pharo-project] Xtreams port to Squeak - second wave
by mkobetic＠gmail.com Oct. 11, 2010

Oct. 11, 2010

"Sven Van Caekenberghe"<sven(a)beta9.be> wrote: > I tried to follow your different releases in Pharo 1.1.1, right now I have 433 tests, 3 failures (#testReadWriteLargeAmount), 11 errors (#..base64 and #..multipleBufferSize). If will send you the report. > > I have been trying some of the examples from the doc pages (google code project), this simple one still fails: > > ((1 to: 10) reading collecting: [:x | x * x]) rest Ah, that's because of the use of #cull: like semantics with exception handlers in some places, mostly ... on: Incomplete do: #count. We can certainly replace all those with regular block style. > The readline example is using the non-existing #slicer: method, this simpler version seems to work: > > |text| > text := 'line1\line2\line3\line4' withCRs reading. > text := text ender: [ :char | char = Character cr ]. > text collect: [ :line | line rest ]. > > That is a documentation bug though. Hm, odd, this is fixed in the package comments, but looks like I failed to regenerate the project pages properly. I'll review the comments again and update the site. Thanks!

3 2

[Pharo-project] Xtreams was Re: Unit Tests on Pharo 1.1.1
by Sven Van Caekenberghe Oct. 11, 2010

Oct. 11, 2010

Nicolas, On 11 Oct 2010, at 22:35, Nicolas Cellier wrote: > Yes, that was expected. > > With latest versions, the Base64 encoding/decoding now pass. > Beware, I moved everything to http://www.squeaksource.com/Xtreams.html > > Cheers > > Nicolas > > 2010/10/11 Sven Van Caekenberghe <sven(a)beta9.be>: >> Nicolas, >> >> Here is the unit test report I promised: OK, thanks, I moved to the new SS project. I commited some changes: replacing on: XTIncomplete do: #count with on: XTIncomplete do: [:exception | exception count] as suggested by Martin Kobetic Now, this works: ((1 to: 10) reading collecting: [:x | x * x]) rest and I think more tests succeed, but I am not sure since I forgot how many failed before. Sven

1 0

Re: [Pharo-project] MicroSqueak Was: Re: [update 1.2] #12188
by StÃ©phane Ducasse Oct. 11, 2010

Oct. 11, 2010

>> > > Ah, good to know. I will be very happy to someday take a 50k input, and > a script.st file containing a ConfigurationOfXXX load sentence and get a > fully featured custom image. > Keep the good job. I hope :) and ideally I would like to have binary loading instead of having the compiler loaded first :) but it takes time.

1 0

Re: [Pharo-project] how to get the diff on commit on the pharo source?
by StÃ©phane Ducasse Oct. 11, 2010

Oct. 11, 2010

> It is not the mailing list that is the problem, it is the >> squeaksource.com server that is. It takes several minutes to calculate >> a simple diff of a single version and that just kills responsiveness >> at the current rate of commits. > > That seems to be a really high number. I just compared a version of the > CollectionTests package in Squeak 4.2 with a Pharo version. The two are totally different, there are 2002 changes. Parsing both packages and creating the diffs takes less than a second with Cog. So it's probably less than 3 seconds with the standard VM. And this is an edge case. > this is true that squeaksource is central and we should get it faster not slower. :-/ Stef

1 0

Oct. 11, 2010

Ok I see INRIA told us that they will allocate some time of their busy engineer for the web-dav server. Once we have that we could host any pharo/squeak projects. Now we will not have squeaksource.... :( But for pharo we need a scriptable interface because we are losing time moving package around. Stef > On 11 October 2010 17:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> I would really like to have the same behavior than the squeak system ie having the source modification >> send to the list. I could not see how to set it up on squeaksource. >> May be this is not the same version running. > > It is disabled because of the excessive processing power that this > requires. And the server is already at the limit. Ok this is sad because I would like that people can see published code. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Oct. 11, 2010

On Oct 11, 2010, at 6:02 PM, James Foster wrote: > > On Oct 11, 2010, at 8:07 AM, StÃ©phane Ducasse wrote: > >> Hi guys >> >> there is a HUGE HUGE HUGE difference between >> (1) namespace at the language level and we do not want that the way german did it. > > StÃ©phane, > > Are you suggesting that the approach GermÃ¡n Leiva demonstrated at ESUG last month is "at the language level"? Could you elaborate? no time to elaborate sorry I have boring documents to write. Now this is at the language level because as a programmer I have to write it when I write my class. Look at point 2 items: you as a nice programmer do not care that your class is defined in bootstrap or normal. Stef > > James > >> Give us some times and we will try different solutions and see what come out >> (2) systemDictionary at the infrastructure level. >> We are working on that since Squeak Kernel Cleaning Project >> here we want the tools to be able to use another environment so that we can >> - bootstrap the compiler with itself >> - load different version of code (for Moose) to build report on Pharo 1.2 from pharo 1.1 >> - bootstrap the kernel >> - build atomic loading. >> We are working on 2 and this is what nick needs. >> I will not talk about namespace at the lnaguage level. No time for that. >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Oct. 11, 2010

On Oct 11, 2010, at 5:53 PM, Schwab,Wilhelm K wrote: > Nick, > > I'm certainly no expert on DST, but I will gladly help where I can. You're starting a PhD program? Is Stef your advisor? That would put you in good hands. noury luc and me :) Indeed nick you should ahve a look at VisualWorks Distributed Smalltalk. I remember now that in 3 min I could browse your browser from my machine wayback in 2002. Stef > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nick Papoylias [npapoylias(a)gmail.com] > Sent: Monday, October 11, 2010 11:43 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ? > > I am currently concerned with remote programming (debugger, browser, compiler e.t.c) in Pharo from one image (or environment) to another, so that this infrastructure can be used in the field of autonomous robotics to ease the development cycle. > > So we should definitely exchange ideas ! Cause there surely is more than one way to go (plain sockets and API, rST, remote SystemDictionary and environment, to name a few..) > > We should keep in touch ! > > Nick > > On Mon, Oct 11, 2010 at 5:16 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com<mailto:serge.stinckwich@gmail.com>> wrote: > 2010/10/11 Nick Papoylias <npapoylias(a)gmail.com<mailto:npapoylias@gmail.com>>: >> Hallo to all, >> >> I am starting my Ph.D on 'languages and environments for autonomous >> robotics' -- and pharo will be a huge part of it. > > Hi Nick, > > Great to see that another guy will work in the domain of embedded > systems&autonomous robots with Smalltalk ! > > I already talked with Noury or Luc about that. This is really > important to share code as we are a small community, especially code > to interface with existing robotics systems like ROS, OROCOS or > Player/Stage. I will start soon to work on how to integrate Smalltalk > with ROS: http://www.ros.org/wiki/ > > Regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0