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

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