April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] XML and DTD

by Olivier Auverlot

Le 28/04/11 14:38, StÃ©phane Ducasse a Ã©crit : > On Apr 28, 2011, at 11:58 AM, Olivier Auverlot wrote: > >> Hi, >> >> Now, I'm playing with XML-Parser. It's a funny game but I have a little question. How to validate a XML file with a DTD ? > I do not know. I need this to validate XML data received by my application. XML-Parser seems to contain the tools required. There is a category named XML-Parser-DTD. In the category XML-Parser, there is a method named XMLConfiguration>>#isValidating. But how use them ? Someone has a link to a documentation, an exemple, an information, an bottle that contains a message, something ? What are the alternative ways to parsing XM, generating XML and validating XML data ? Olivier ;-) www.auverlot.fr > In VisualWorks there was a kind of validator now in XMLwriter....package I do not know. > >> Thank for your help. >> >> Best regards >> Olivier ;-) >> >> www.auverlot.fr >> >

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 Stefan Marr

Hi: On 29 Apr 2011, at 02:18, Nicolas Cellier wrote: > 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. Hm, you refer to http://code.google.com/p/xtreams/ ? Maybe its just my missing imagination, but Xtreams alone do not look like they help here a lot. > But of course choosing manually an optimal multi-Process > implementation is far from easy... Right, and that is also not what I meant with 'automatic parallelization does not work'. I just think, that you will need to formulate your problems in a way that the opportunity for parallelism is obvious. There is no smart compiler that will parallelize something _in the spirit of_ a recursively defined factorial. I think, we will be forced to formulate our problems in some way that is not inherently sequential. (That is basically also what Michael referred to with Guy Steele's work, Fortress is all about trees, and I also assume that this is the best bet for the moment.) Data-flow/stream languages force you to do that, Fork/Join and map reduce are also about forcing your problem into a structure that is manageable. And then, we can apply something like a work-stealing scheduler and we do not need to specify how the computation is to be distributed over the available computational resources. However, there is always a big constant factor in all this on todays machines, and we are still forced to think about a sequential cut-off. Hopefully we can apply some of that automatic fusing of fine-grained parallelism to get a good-enough solution to avoid having to think about sequential cut-offs. (Which still will remain interesting since certain sequential strategies will always outperform naive divide-and-conquer strategies.) > 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. Fine-grained parallelism and a good scheduling approach help already a lot. Work-stealing seems to be the state-of-the-art solution for that. And hopefully, we will get to replace the stupid scheduler in the RoarVM with a work-stealing one soon. (But a CogJIT RoarVM would help real-world performance more ;)) 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 StÃ©phane Ducasse

alex did you read the OOPSLA paper stefan or michael sent around about profiling and the default flaw in research approach? Stef On Apr 29, 2011, at 12:40 AM, Alexandre Bergel wrote: > +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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

April 29, 2011

[Pharo-project] Best strategy for ConfigurationOfPharo using #stable

by Mariano Martinez Peck

Hi Dale. For Pharo 1.3 I want to (try) to use all #stable, i.e, I want that ConfigurationOfPharo doesn't explicitly load a specific version of every project but instead, the #stable. First step I need to do (I will try to do it during the weekend) is to update #stable in each of the ConfigurationOf used by ConfuigurationOfPharo. That's an easy part. Now, my question is...I don't really understand how the confs would look like after. I mean, 99% of the cases (in fact, at the beginning it will be 100% until I find a problem), the version I use will be #stable. So,the version of ConfgiruationOfPharo AND all the Configurations used by ConfgiruationOfPharo would look something like this: spec project: 'Autotest' with: #stable; project: 'Autotest Help Tests' with: #stable; project: 'MemoryMonitor' with: #stable; project: 'XMLSupport' with: #stable; I mean...every single project reference will have #stable instead of a specific version. So...is this expected? is this the way I should do it ? Finally...is there a query I can do to Metacello saying "which are the ConfigurationsOf needed for this version for this group of this Conf" ? Thanks -- Mariano http://marianopeck.wordpress.com

April 29, 2011

[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 28, 2011