- Pharo-dev - lists.pharo.org

[Pharo-project] for Rpackage status, questions, path

by StÃ©phane Ducasse

Hi guys here is the status: - I have all tests green but but but - I have plenty of code to review about the integration with MC and understand since cyrille's goal was to make sure that RPackage can be used in place of PackageInfo and using the same subpackage semantics. Now having that put a lot of ugly code in RPackage and we have to do really strange things to make it work. If you want to have a look you can load the latest configurationOfRPackage and load version 30 and check a bit Gofer new squeaksource: 'PharoTaskForces'; package: 'ConfigurationOfRPackage'; load. ConfigurationOfRPackage project load: '3.0' run the tests look for self flag: #stef self flag: #cyrille - I would like to review all this code and see if we can improve it to the point where this is ok to keep it or just do what we decided: one category = one package: no submatching. Now I have also a problem and metacello can help me. RB is one of the heavy/sometimes even single user of some packageInfo API and I would like to migrate RB alltogether with RPackage. So mariano may be I could work on a configurationOfRB for me. What do you think: I could load OB version for 1.3 RB version (we mark a stable version for 1.3) and I work with another one for 11.4 for example? Mariano could you give me hand on that? Stef

April 29, 2011

[Pharo-project] [update 1.3] #13176

by Marcus Denker

13176 ----- Issue 4123: ifNotNilDo: --> ifNotNil: Issue 4122: Fix #isDeprecated Issue 4121: move more deprecated methods to package Deprecated13 Issue 4072: Deprecate or fix PCXReadWriter Issue 4119: MorphTreeMorph rows height and color problem Issue 3860: Overzealous arithmetic collection removal -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 29, 2011

Re: [Pharo-project] Explicit control of Parallel execution in Smalltalk ? (was Counting Messages as a Proxy for Average Execution Time in Pharo)

by Michael Haupt

Hi, On 29 April 2011 02:18, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > But of course choosing manually an optimal multi-Process > implementation is far from easy... there is this talk by Guy Steele where he discusses the idea of language concepts that leave the language implementation some "wiggle room" for optimisation through parallelisation. Maybe that's inspiring. Let me see if I can find it ... yup: http://www.infoq.com/presentations/Thinking-Parallel-Programming The first few minutes are a bit off-topic but still amusing, but then he gets to the details, and those are really interesting. Best, Michael

April 29, 2011

Re: [Pharo-project] Zinc problems found

by Sven Van Caekenberghe

Hello Esteban, On 29 Apr 2011, at 00:26, Esteban Lorenzano wrote: Thanks for reporting these issues, I'll have a look at them, but during the day I am out of the office and have meetings, so it won't be until the evening that I have some time, maybe only tomorrow. I remember having thought about the first issue, I just don't remember why I did it that way, I'll have to check a bit. The second issue them, can you send a print string of the headers in that response ? Maybe there just is no body ? Is there a way for me to try that request ? Sven > Hi, > I found some problems on Zinc implementation. > > Take this example: > > HTTPSocket > httpGetDocument: 'http://127.0.0.1:333/analytics/feeds/accounts/default' > args: (Dictionary new > at: 'prettyprint' put: #('true'); > yourself) > accept: '*/*' > request: ('Authorization: GoogleLogin Auth={1}{2}' format: {self authenticationKey. String crlf} > > this, if I have the correct authentication key, gives me the correct answer (an atom-xml response). > > Now, if I try: > > ZnHTTPSocketFacade > httpGetDocument: 'http://127.0.0.1:333/analytics/feeds/accounts/default' > args: (Dictionary new > at: 'prettyprint' put: #('true'); > yourself) > accept: '*/*' > request: ('Authorization: GoogleLogin Auth={1}{2}' format: {self authenticationKey. String crlf} > > (this should work, as the facade is for compatibility, I think) > > I have two errors, one of them easily solvable, and the other... well... I couldn't solve it in the 15' I spent on it :) > > 1) arguments are not in the correct way. While HTTPSocket functions expect something like this: > > Dictionary new > at: 'prettyprint' put: #('true'); "<-- Parameter is an array" > yourself. > > ZnHTTPSocketFacade expects something like this: > > Dictionary new > at: 'prettyprint' put: 'true'; "<-- Parameter is a string" > yourself. > > 2) This is the hard one. If you do the get request with parameter fixed, you should get the atom feed. > But you don't. > You get a ZnResponse who is OK (status 200), but entity is empty. I followed the error until this method: > > canReadContent > ^ self hasContentLength or: [ self isChunked or: [ self allowsReadingUpToEnd ] ] > > who return false, because none of the questions is true. Then, no entity is filled, and I have no answer :( > > Hope this help :) > > Cheers, > Esteban > > > > > > > > >

April 29, 2011

[Pharo-project] Explicit control of Parallel execution in Smalltalk ? (was Counting Messages as a Proxy for Average Execution Time in Pharo)

by Nicolas Cellier

2011/4/29 Stefan Marr <pharo(a)stefan-marr.de>: > > On 29 Apr 2011, at 01:07, Nicolas Cellier wrote: >>>> However, as I understand it, it's entirely up to user to write code >>>> exploiting parallel Process explicitly right ? >>> Sure, you have to do: n times: [ [ 1 expensiveComputation. ] fork ]. >>> >>> I don't belief in holy grails or silver bullets. >>> Automatic parallelization is something nice for the kids, like Santa Clause or the Easter Bunny... >> >> Unless your hobby is oriented toward functional languages maybe... >> But I just know enough of it to now shut up ;) > Would be nice, but that is also a fairy tale. > > The best we have today, in terms of being 'easily' automatically scheduleable are data-flow/stream languages. Things like StreamIT or Lucid have interesting properties, but well, its still a search for the holly grail. > > Best regards > Stefan > Interestingly, I was thinking of Xtreams as an obvious Smalltalk test case for parallelism. But of course choosing manually an optimal multi-Process implementation is far from easy... Reading http://cag.lcs.mit.edu/commit/papers/06/gordon-asplos06-slides.pdf reinforce my feeling that it shall not be optimized manually, and that user shall not design/assign Process directly. I don't know what the right abstraction would be in Smalltalk though such that a VM could do it, and neither do I understand how StreamIT solves the optimization, but thanks for these interesting clues. Nicolas > > -- > 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 > > >

April 29, 2011

Re: [Pharo-project] [TODO] 1.2.2

by Marcus Denker

On Apr 29, 2011, at 12:44 AM, Mariano Martinez Peck wrote: > BTW...do we need a Pharo 1.2.2 ? can't we directly release Pharo 1.3 ? > The idea was to release 1.2.2 very very soon... while 1.3, who knows when? Not many people are actually pushing to close the 1.3 open issues... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 29, 2011

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Stefan Marr

On 29 Apr 2011, at 01:07, Nicolas Cellier wrote: >>> However, as I understand it, it's entirely up to user to write code >>> exploiting parallel Process explicitly right ? >> Sure, you have to do: n times: [ [ 1 expensiveComputation. ] fork ]. >> >> I don't belief in holy grails or silver bullets. >> Automatic parallelization is something nice for the kids, like Santa Clause or the Easter Bunny... > > Unless your hobby is oriented toward functional languages maybe... > But I just know enough of it to now shut up ;) Would be nice, but that is also a fairy tale. The best we have today, in terms of being 'easily' automatically scheduleable are data-flow/stream languages. Things like StreamIT or Lucid have interesting properties, but well, its still a search for the holly grail. 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

April 29, 2011

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Nicolas Cellier

2011/4/29 Stefan Marr <pharo(a)stefan-marr.de>: > > On 29 Apr 2011, at 00:32, Nicolas Cellier wrote: > >> >> However, as I understand it, it's entirely up to user to write code >> exploiting parallel Process explicitly right ? > Sure, you have to do: n times: [ [ 1 expensiveComputation. ] fork ]. > > I don't belief in holy grails or silver bullets. > Automatic parallelization is something nice for the kids, like Santa Clause or the Easter Bunny... > > > Best regards > Stefan > Unless your hobby is oriented toward functional languages maybe... But I just know enough of it to now shut up ;) Nicolas > -- > 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 > > >

April 29, 2011

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Stefan Marr

On 29 Apr 2011, at 00:32, Nicolas Cellier wrote: > > However, as I understand it, it's entirely up to user to write code > exploiting parallel Process explicitly right ? Sure, you have to do: n times: [ [ 1 expensiveComputation. ] fork ]. I don't belief in holy grails or silver bullets. Automatic parallelization is something nice for the kids, like Santa Clause or the Easter Bunny... 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

April 29, 2011

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Alexandre Bergel

> One silly idea while reading this thread (not the paper): > For single core, the idea makes sense. > It may even extend easily to multicore VM (just forget about Smalltalk > for a while) by counting message sent per core and taking the max. But you are here assuming that all the CPU have the same speed (#messages/sec) right? Alexandre > > Nicolas > > 2011/4/29 Alexandre Bergel <alexandre.bergel(a)me.com>: >> +1 >> >> Alexandre >> >> >> On 28 Apr 2011, at 17:35, Michael Haupt wrote: >> >>> Hi Alex, >>> >>> On 29 April 2011 00:08, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>>> I think you're being a bit harsh on stack sampling there. It is exact >>>>> enough to drive optimisation in some really high-performance VMs. It >>>>> is also deterministic enough to yield data leading to very good >>>>> performance results in those VMs. Whether focusing on counting >>>>> messages instead of taking samples is more beneficial would have to be >>>>> determined by experiment ... >>>> >>>> Yes, 25 pages of experiment :-) >>> >>> oh, I was not referring to your paper. I was referring to the general >>> applicability of message counting as opposed to sampling. The latter >>> is true-and-tried in many high performance VMs. For the former, an >>> experiment has yielded good results (from what I take from this thread >>> - I still haven't read your paper, sorry, it's on top of the pile) in >>> a constrained setting. All I was saying is that it is not possible to >>> conclude anything for the broader area from the experiments you >>> conducted. But we're probably of the same opinion here. >>> >>>>> What you mean with "non-portable" I do not understand. >>>> >>>> The information about the execution time contained in your profile cannot be compared with a new profile realized on a different machine, with a different CPU. >>> >>> That is correct, but the approach itself is portable - may I quote >>> you: "Most profilers, including MessageTally, count stack frames at a >>> regular interval. This is doomed to be inexact, non-deterministic and >>> non-portable". You weren't talking about the results. Those are >>> obviously specific to the platform, clock frequency, L1/L2/L3 cache >>> and memory sizes, application input (!) and other factors. >>> >>> Best, >>> >>> Michael >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 29, 2011