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

Re: [Pharo-project] bad bracket autocompletion in Pharo Core 1.2

by StÃ©phane Ducasse

thanks! On Oct 11, 2010, at 9:37 AM, Fernando olivero wrote: > Hi , it was a enhancement i did starting from a Chris Muller enhancement for Squeak. > > ISSUE 2653. > http://code.google.com/p/pharo/issues/detail?id=2653&can=1&q=auto&colspec=I… > > I did a test, maybe a good start would be to see if its failing now. > > Fernando > > On Oct 9, 2010, at 2:18 PM, Juan Vuletich wrote: > >> Hi Folks, >> >> Cuis doesn't include #autoEnclose, so I don't know how it should behave. >> >> Cheers, >> Juan Vuletich >> >> Mariano Martinez Peck wrote: >>> Guille, if I remember correctly (not sure), these new classes like >>> TextEditor and Smalltalk editor came from Cuis. Juan (Cuis author) i >>> think he is in the mailing list but not read it so frequently. So, for >>> this issues maybe you can cc'ed him. >>> >>> Cheers >>> >>> Mariano >>> >>> 2010/10/9 Guillermo Polito <guillermopolito(a)gmail.com >>> <mailto:guillermopolito@gmail.com>> >>> >>> Here is the piece of code that's behaving weird >>> >>> TextEditor>>dispatchOn: >>> >>> ... >>> ... >>> char := aKeyboardEvent keyCharacter. >>> openers := '([{'. >>> closers := ')]}'. >>> ( closers includes: char) ifTrue: [ self blinkPrevParen: >>> char ]. >>> result := self normalCharacter: aKeyboardEvent. >>> (self class autoEnclose and: [ openers includes: char ]) >>> not ifTrue: [ ^ result ]. >>> suffix := closers at: (openers indexOf: char). >>> paragraph text append: suffix asString. >>> self moveCursor: [ : position | position ] forward: true >>> specialBlock: [ : pos | "no special behavior" ] event: >>> aKeyboardEvent . >>> self userHasEdited. >>> >>> ------------------------------------- >>> >>> So, if I evaluate "TextEditor autoEnclose: false", it is stops >>> behaving like that :) >>> >>> What should be the desired behavior? Having it configurable as it >>> is today but fix the strange bracket adding? remove this behavior? >>> I can't find now how ParagraphEditor did this. >>> >>> Guille >>> >>> >>> On Wed, Oct 6, 2010 at 10:34 PM, Guillermo Polito >>> <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>> >>> Yes, the issue can be reduced to: >>> >>> open parenthesis (or brackets), then something else (anywhere >>> in the editor). >>> >>> 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com >>> <mailto:marianopeck@gmail.com>> >>> >>> I detected a similar problem: >>> >>> once you type an opening parenthesis, and then something >>> else, it adds a new one at the END of the code >>> >>> check http://code.google.com/p/pharo/issues/detail?id=2939 >>> >>> 2010/10/6 Guillermo Polito <guillermopolito(a)gmail.com >>> <mailto:guillermopolito@gmail.com>> >>> >>> http://code.google.com/p/pharo/issues/detail?id=3069 >>> >>> if you type: >>> >>> [] -> []] >>> >>> () -> ()) >>> >>> {} -> {}} >>> >>> >>> >>> >>> Bye! >>> >>> _______________________________________________ >>> 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 >>> <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 >>> <mailto:Pharo-project@lists.gforge.inria.fr> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com >>> Version: 9.0.862 / Virus Database: 271.1.1/3184 - Release Date: 10/08/10 03:34:00 >>> >>> >> >> >> _______________________________________________ >> 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

Oct. 12, 2010

[Pharo-project] R: R: R: R: R: Problem with inspector

by morod

Hello FrÃ©d All right, huge thank you and sorry again for my shallowness Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: lunedÃ¬ 11 ottobre 2010 21.58 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: R: R: R: Problem with inspector Did you expand the category NewInspector and check the two first options ? See my attached screenshot. Once done, close the inspector and reopen it. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/11 morod <morod(a)tiscali.it> IÂm sorry but something may be wrong. My Pharo.image NewInspector installed System settings I tried again and the result has not changed Thanks again for your patience Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: lunedÃ¬ 11 ottobre 2010 00:23 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: R: R: Problem with inspector It's really strange. It works perfectly here. Step by step: - Download the last image of Pharo - Go to Monticello and load the last package of NewInspector - Go to System > Settings > Debugging > NewInspector - Check the options - Open a new inspector on an object The new children must appear. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/10 morod <morod(a)tiscali.it> Thanks for your interest, I have done what was suggested, but nothing has changed. Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: domenica 10 ottobre 2010 17:00 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: R: Problem with inspector If you load the last version of NewInspector (posted this morning), you go to the Settings Browser (System > Settings in the World menu), expand "Debugging" > "NewInspector" and check the options you want. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/10 morod <morod(a)tiscali.it> Hello, How can I switch from the two different versions of tool ÂInspectorÂ Best regards Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: sabato 9 ottobre 2010 14:08 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: Problem with inspector Hello, It's the NewInspector on both pictures but two different versions of this tool. In the old version, the class and the methods were displayed for each inspected object. In the current version, there are not displayed (because the community prefers less children for each object). FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/8 morod <morod(a)tiscali.it> Hi Mariano I tried it with multiple images and the behavior is the same with all the images. Sent the sample is made with: Pharo-1.1-11411 Latest update: #11411 The first one is my image and the second is taken from the book ÂPharo by ExampleÂ Thanks again Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Mariano Martinez Peck Inviato: venerdÃ¬ 8 ottobre 2010 21:43 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] Problem with inspector Hi morod, and welcome to Pharo! Which Pharo image are you exactly using? (the name of the zip, the image file or go to System -> About) The first one is your image, right ? and the second one? where is it from ? The difference is that the first image is using the "old" traditional inspector, while the second picture is using another inspector, which is called "NewInspector", which provides more information. Cheers Mariano 2010/10/8 morod <morod(a)tiscali.it> Hi iÂm new to smalltalk and Pharo and my inspector show Errore. Il nome file non Ã¨ specificato. instead of Errore. Il nome file non Ã¨ specificato. Why? Thanks _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 12, 2010

Re: [Pharo-project] [squeak-dev] Re: Xtreams port to Squeak - second wave

by Levente Uzonyi

On Tue, 12 Oct 2010, Levente Uzonyi wrote: > On Tue, 12 Oct 2010, Nicolas Cellier wrote: > >>> >>> I just realized that sometimes the 100 ms timeout is not enough even on >>> Cog >>> and the test fails, 200 ms works well. It typically happens when running >>> #testReadWriteLargeAmount. I'd suggest increasing it to 1000 ms or more, >>> to >>> make sure it doesn't fail with SqueakVM or on slower machines. >>> >>> >>> Levente >>> >> >> Hmm, I increased to 1000ms, but still get some random failures... > > Yes, it's a bit strange. If I change it to 200ms, every test passes, no > random failures. If I increase it to 1000ms, I get random failures. Okay, I really tracked down the cause of the problem. The tests perform simple producer-consumer scenarios, but the consumers won't wait at all. If there's nothing to consume, the test fails. The randomness come from the scheduler. The server process is started first, the client is the second. If the server process can produce enough input to the client process the test will pass. If you decrease the priority of the client process by one in #timeout:server:client:, the randomness will be gone and the tests will reliably pass, because the client won't be able to starve the server. To avoid false timeouts I had to increase the timeout value to 2000 milliseconds using SqueakVM. I also found an issue: the process in XTTransformWriteStream doesn't terminate. If you run the tests, you'll get 12 lingering processes. Levente > > > Levente > >> >> Nicolas >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Oct. 12, 2010

Re: [Pharo-project] how to get the diff on commit on the pharo source?

by Schwab,Wilhelm K

I've played similar games for a long time. Originally, I had to run on a Novell network, and it was a BSOD waiting to happen. So, I added a machine with the Novell client that did nothing but use a mapped drive to read from a source and push data over TCP/IP to my server, which happily no longer ran the Novell client, and hence did not throw a BSOD twice or more each week. Some time after that, I realized that the second machine could do more to help the server, and it ended up doing a fair amount of crunching, sending only summary data to the server. Works great. It's more boxes to maintain, but otherwise it's a nice arrangement. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Monday, October 11, 2010 7:38 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] how to get the diff on commit on the pharo source? On 11 October 2010 20:03, Lukas Renggli <renggli(a)gmail.com> wrote: > 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. > Its not necessary to do diff processing on squeaksource.com host. Another host could simply watch repositor(ies), and then download new versions and do diff & email it to mailing list. > Lukas > > On 11 October 2010 18:01, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> Maybe on a separate mailing list. >> >> Cheers, >> Alexandre >> >> >> On 11 Oct 2010, at 12:49, StÃ©phane Ducasse 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. >>> >>> Stef >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > 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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Schwab,Wilhelm K

Sig, You seem to be doing a good job of this, so if you think I'm off, feel free to prove it. The executors (in Dolphin, the objects themselves) probably know more than the registry about how to handle errors, and (it seems to me) either generated them or could have readily caught them if there were something different to do based on the information. Maybe the crux of the matter is as follows: are you thinking of an executor class with subclasses that implement #handleFinalizationError: (a hook), or is it more "this happened, thought you might like to know." I think I read it more as the latter, probably assuming that #finalize would retry if that could reasonably be expected to help. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Monday, October 11, 2010 6:35 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On 12 October 2010 00:32, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > How hard it is or isn't is not nearly as important as your tackling it and doing so with the right tools. So again I say, carry on :) > > On self vs. executor as the receiver of #handleFinalizationError:, I might lean toward "self" as it will be closer to the system. There is probably little the executor can do, and it either missed or raised the error in the first place, right? I *think* the most you are going to to do is log that something went wrong, but I could be missing something. > I'm not sure about that . >From other size, a finalizer could better know why error can occur and how to handle it graciously, if its possible, and not just showing 'you suck' at the center of screen ;) Because weak registry can tell even less about nature of error, because it propably knows nothing about its finalizers, except that they understand #finalize message. > #ensure: attempts to evaluate the argument block whenever the receiver of it is completed (modulo some ominous sounding questions raised in the past months to a year??). #ifCurtailed: should be similar, but evaluating the argument/block only on abnormal (including, I think, ^) exit of the block. > > Does that help at all? > Yes. Thanks. I now remember semantics of it. Been there when dealt with Process>>terminate voodo. > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Monday, October 11, 2010 4:17 PM > To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On 11 October 2010 22:49, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> The most important words in there are "critical section." Carry on :) >> > > Oh, please. This is not too hard to code. > > My mind rolling around following choice(s) (there may be others i don't see). > What would be a proper way to handle error during #finalize. > > [ executor finalize ] on: Error do: [:ex | > self handleFinalizationError: ex "where self is registry" > ]. > > or: > > [ executor finalize ] on: Error do: [:ex | > executor handleFinalizationError: ex > ]. > > > of course, i should catch this error in test, so i can verify that: > > a) test is get notified upon synthetically made error > b) no matter what i do inside error handler (up to 'Processor > activeProcess terminate'), a finalization process continues working > (or restarts without losing remainder of executors). > > > Also, i used #ensure: and #ifCurtailed: but i tend to forget where > they are applicable and how. > So, little help in this regard will be wellcome. > >> Bill >> > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] how to get the diff on commit on the pharo source?

by Igor Stasenko

On 11 October 2010 20:03, Lukas Renggli <renggli(a)gmail.com> wrote: > 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. > Its not necessary to do diff processing on squeaksource.com host. Another host could simply watch repositor(ies), and then download new versions and do diff & email it to mailing list. > Lukas > > On 11 October 2010 18:01, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> Maybe on a separate mailing list. >> >> Cheers, >> Alexandre >> >> >> On 11 Oct 2010, at 12:49, StÃ©phane Ducasse 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. >>> >>> Stef >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel Â http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

Re: [Pharo-project] [squeak-dev] Re: Xtreams port to Squeak - second wave

by Levente Uzonyi

On Tue, 12 Oct 2010, Nicolas Cellier wrote: >> >> I just realized that sometimes the 100 ms timeout is not enough even on Cog >> and the test fails, 200 ms works well. It typically happens when running >> #testReadWriteLargeAmount. I'd suggest increasing it to 1000 ms or more, to >> make sure it doesn't fail with SqueakVM or on slower machines. >> >> >> Levente >> > > Hmm, I increased to 1000ms, but still get some random failures... Yes, it's a bit strange. If I change it to 200ms, every test passes, no random failures. If I increase it to 1000ms, I get random failures. Levente > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 11, 2010

Re: [Pharo-project] Exception handling and cull: [ Xtreams port to Squeak - second wave ]

by Levente Uzonyi

On Mon, 11 Oct 2010, Nicolas Cellier wrote: > 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. Originally the method sent #valueWithPossibleArgs:. I changed it to #valueWithPossibleArgument:, because it's 100% backwards compatible. But I agree that #cull: is suitable here too. Levente > > To me, it should be self to just send #cull: > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 11, 2010

[Pharo-project] [CfPart] BoF: Non-deterministic Programming for Manycore Systems at SPLASH'10

by Stefan Marr

============================================================================ 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

Oct. 11, 2010

[Pharo-project] Xtreams hook to the holly Squeak TextEncoder

by Nicolas Cellier

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

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Igor Stasenko

On 12 October 2010 00:32, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > How hard it is or isn't is not nearly as important as your tackling it and doing so with the right tools. Â So again I say, carry on :) > > On self vs. executor as the receiver of #handleFinalizationError:, I might lean toward "self" as it will be closer to the system. Â There is probably little the executor can do, and it either missed or raised the error in the first place, right? Â I *think* the most you are going to to do is log that something went wrong, but I could be missing something. > I'm not sure about that . >From other size, a finalizer could better know why error can occur and how to handle it graciously, if its possible, and not just showing 'you suck' at the center of screen ;) Because weak registry can tell even less about nature of error, because it propably knows nothing about its finalizers, except that they understand #finalize message. > #ensure: attempts to evaluate the argument block whenever the receiver of it is completed (modulo some ominous sounding questions raised in the past months to a year??). Â #ifCurtailed: should be similar, but evaluating the argument/block only on abnormal (including, I think, ^) exit of the block. > > Does that help at all? > Yes. Thanks. I now remember semantics of it. Been there when dealt with Process>>terminate voodo. > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Monday, October 11, 2010 4:17 PM > To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On 11 October 2010 22:49, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> The most important words in there are "critical section." Â Carry on :) >> > > Oh, please. This is not too hard to code. > > My mind rolling around following choice(s) Â (there may be others i don't see). > What would be a proper way to handle error during #finalize. > > [ executor finalize ] on: Error do: [:ex | > Â self handleFinalizationError: ex Â "where self is registry" > Â ]. > > or: > > [ executor finalize ] on: Error do: [:ex | > Â executor handleFinalizationError: ex > Â ]. > > > of course, i should catch this error in test, so i can verify that: > > a) test is get notified upon synthetically made error > b) no matter what i do inside error handler (up to 'Processor > activeProcess terminate'), a finalization process continues working > (or restarts without losing remainder of executors). > > > Also, i used #ensure: and #ifCurtailed: but i tend to forget where > they are applicable and how. > So, little help in this regard will be wellcome. > >> Bill >> > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

Re: [Pharo-project] [squeak-dev] Re: Xtreams port to Squeak - second wave

by Nicolas Cellier

> > I just realized that sometimes the 100 ms timeout is not enough even on Cog > and the test fails, 200 ms works well. It typically happens when running > #testReadWriteLargeAmount. I'd suggest increasing it to 1000 ms or more, to > make sure it doesn't fail with SqueakVM or on slower machines. > > > Levente > Hmm, I increased to 1000ms, but still get some random failures... Nicolas

Oct. 11, 2010

Re: [Pharo-project] [squeak-dev] Re: Xtreams port to Squeak - second wave

by Nicolas Cellier

2010/10/11 Sven Van Caekenberghe <sven(a)beta9.be>: > Martin, > > On 11 Oct 2010, at 20:35, mkobetic(a)gmail.com wrote: > >> 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 committed the necessary changes in the (new) repository. > > Thx, > > Sven > > > Thanks. In the meantime, I used #cull: in #handleSignal: in Squeak trunk, previous behaviour was not meaningfull anyway. But we can keep the long version for larger compatibility. Nicolas PS: shall we feed vwnc list with Squeak/Pharo porting problems ? I removed it from the CC

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Schwab,Wilhelm K

Sig, How hard it is or isn't is not nearly as important as your tackling it and doing so with the right tools. So again I say, carry on :) On self vs. executor as the receiver of #handleFinalizationError:, I might lean toward "self" as it will be closer to the system. There is probably little the executor can do, and it either missed or raised the error in the first place, right? I *think* the most you are going to to do is log that something went wrong, but I could be missing something. #ensure: attempts to evaluate the argument block whenever the receiver of it is completed (modulo some ominous sounding questions raised in the past months to a year??). #ifCurtailed: should be similar, but evaluating the argument/block only on abnormal (including, I think, ^) exit of the block. Does that help at all? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Monday, October 11, 2010 4:17 PM To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list Subject: Re: [Pharo-project] Another finalization concern: error handling On 11 October 2010 22:49, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > The most important words in there are "critical section." Carry on :) > Oh, please. This is not too hard to code. My mind rolling around following choice(s) (there may be others i don't see). What would be a proper way to handle error during #finalize. [ executor finalize ] on: Error do: [:ex | self handleFinalizationError: ex "where self is registry" ]. or: [ executor finalize ] on: Error do: [:ex | executor handleFinalizationError: ex ]. of course, i should catch this error in test, so i can verify that: a) test is get notified upon synthetically made error b) no matter what i do inside error handler (up to 'Processor activeProcess terminate'), a finalization process continues working (or restarts without losing remainder of executors). Also, i used #ensure: and #ifCurtailed: but i tend to forget where they are applicable and how. So, little help in this regard will be wellcome. > Bill > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] Xtreams port to Squeak - second wave

by Sven Van Caekenberghe

Martin, On 11 Oct 2010, at 20:35, mkobetic(a)gmail.com wrote: > 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 committed the necessary changes in the (new) repository. Thx, Sven

Oct. 11, 2010

[Pharo-project] Xtreams was Re: Unit Tests on Pharo 1.1.1

by Sven Van Caekenberghe

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

Oct. 11, 2010

Re: [Pharo-project] MicroSqueak Was: Re: [update 1.2] #12188

by StÃ©phane Ducasse

>> > > 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.

Oct. 11, 2010

Re: [Pharo-project] Exception handling and cull: [ Xtreams port to Squeak - second wave ]

by Nicolas Cellier

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

Oct. 11, 2010

Re: [Pharo-project] MicroSqueak Was: Re: [update 1.2] #12188

by Miguel CobÃ¡

El lun, 11-10-2010 a las 22:56 +0200, StÃ©phane Ducasse escribiÃ³: > > Now that John Maloney has released MicroSqueak as MIT > > (http://web.media.mit.edu/~jmaloney/microsqueak/) shouldn't be worth to > > analize it and see if that can be used as an alternative to build the > > Pharo Kernel. > > Yes we already started. Now I think that producing microsqueak for pharo should just be the easy part. > Because after you want to be able to load package and not a large mess. > > So this is why we did the two in parallel since august > - trying to recompile a kernel (for example as specified by pharo kernel) and fixing all the packages > problems we could find. So we build > - tools to analyse the system > - read a GNU ST based bootstrap > - read chacharas (we did not read spoon because we could not find it) > > - We were thinking that in parallel we would use an approach like chacharas (dynamic creation of a kernel based on an expression definitively cool). gabriel started to have a look at to build a micro kernel. So now that we have one we will check it. > > > I know that Pavel (and now also Nicolas) have done a lot of work in > > getting PharoCore stripped to a minimal kernel. > > But as I understand, PharoKernel idea is to part from a core image, > > reorganize packages, _unload_ what isn't needed and then shrink the > > image to get a kernel image. > > Not necessarily. It was just starting somewhere. > > > The approach of John Maloney's MicroSqueak is the inverse, parting from > > a source code representation and from there to aggregate code until have > > a full image. > > I think that this is the way to go. But there is a middle man missing. > > > Of course the image from John hasn't all the improvements that Squeak > > and Pharo have made to the core classes and that will mean a lot of > > effort to reapply in order to get a modern image. > > It should not be that difficult. > The core image does not have to have everything. It can be simple and part of it can be overload/overridden. > Now the process to go from seed (microsqueak pharo name) to pharo kernel is really important because > we will find all kinds of dead skeleton in the drawers :) > > > But I wonder, and not meaning to discourage any possibility, if isn't > > worth to discuss the technical effort required and the pros/cons of each > > approach and if isn't possible a reutilization of knowledge for this > > very wanted goal of Pharo. > > We already did that :) > And we will continue to learn and build. 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. Cheers > > Stef > > > > Cheers > > > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 11, 2010

Re: [Pharo-project] how to get the diff on commit on the pharo source?

by StÃ©phane Ducasse

> 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

Oct. 11, 2010

Re: [Pharo-project] how to get the diff on commit on the pharo source?

by StÃ©phane Ducasse

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

Oct. 11, 2010

Re: [Pharo-project] [SPAM] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b12

by Sven Van Caekenberghe

Thanks, John, (a) now works again for me. I commented on the Pharo issue (I don't think I can close it myself). On my Mac, all Smalltalk related icons are now gone, maybe they'll come back after logout or reboot (which I almost never do). Sven On 11 Oct 2010, at 07:01, John M McIntosh wrote: > I've stuck a version (5.8b12) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. > > http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b12.app.zip > > This is based on the latest Cog VM source (oct 10/10/10). > > Changes to the support logic: > > (a) Supply file create/mod times & size based on target of symbolic link versus the link file node. > (b) Untrusted directory was set wrong, use same default value as 4.2.x VM ~/Library/Preferences/Squeak/Internet/My Squeak/ > (c) There is no -pathenc option > (d) Attempt to integrate changes into Cog branch to allow you to compile VM from the Cog branch. > *** This does not work yet, 90% there, Eliot and I still have some pencil sharping to do... *** > > Now the big news is that I pushed a version of the Squeak Cog stack VM to the Apple App Store! > > It's rough, but it's a candidate for review by Apple's special App review committee. It does not have socket support and we are seeing if they > allow us to move image/change files in and out of the Documents folder via a desktop machine. I should know more by next weekend. > > If accepted then I am looking to the Smalltalk community to help in building a viable image to allow people to edit source code on an iPad. > > > Lastly, yes something broken in open/gl on os-x 10.4 I hope to look at the issue this week. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] MicroSqueak Was: Re: [update 1.2] #12188

by StÃ©phane Ducasse

> Now that John Maloney has released MicroSqueak as MIT > (http://web.media.mit.edu/~jmaloney/microsqueak/) shouldn't be worth to > analize it and see if that can be used as an alternative to build the > Pharo Kernel. Yes we already started. Now I think that producing microsqueak for pharo should just be the easy part. Because after you want to be able to load package and not a large mess. So this is why we did the two in parallel since august - trying to recompile a kernel (for example as specified by pharo kernel) and fixing all the packages problems we could find. So we build - tools to analyse the system - read a GNU ST based bootstrap - read chacharas (we did not read spoon because we could not find it) - We were thinking that in parallel we would use an approach like chacharas (dynamic creation of a kernel based on an expression definitively cool). gabriel started to have a look at to build a micro kernel. So now that we have one we will check it. > I know that Pavel (and now also Nicolas) have done a lot of work in > getting PharoCore stripped to a minimal kernel. > But as I understand, PharoKernel idea is to part from a core image, > reorganize packages, _unload_ what isn't needed and then shrink the > image to get a kernel image. Not necessarily. It was just starting somewhere. > The approach of John Maloney's MicroSqueak is the inverse, parting from > a source code representation and from there to aggregate code until have > a full image. I think that this is the way to go. But there is a middle man missing. > Of course the image from John hasn't all the improvements that Squeak > and Pharo have made to the core classes and that will mean a lot of > effort to reapply in order to get a modern image. It should not be that difficult. The core image does not have to have everything. It can be simple and part of it can be overload/overridden. Now the process to go from seed (microsqueak pharo name) to pharo kernel is really important because we will find all kinds of dead skeleton in the drawers :) > But I wonder, and not meaning to discourage any possibility, if isn't > worth to discuss the technical effort required and the pros/cons of each > approach and if isn't possible a reutilization of knowledge for this > very wanted goal of Pharo. We already did that :) And we will continue to learn and build. Stef > > Cheers > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

by StÃ©phane Ducasse

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

Oct. 11, 2010

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

by StÃ©phane Ducasse

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

Oct. 11, 2010