March 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Just found, i can compile this:

by Eliot Miranda

On Mon, Mar 24, 2014 at 10:00 AM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > Hi Eliot, > > Le 20 mars 2014 Ã 17:04, Eliot Miranda a Ã©crit : > > On Thu, Mar 20, 2014 at 2:03 AM, Christophe Demarey < > Christophe.Demarey(a)inria.fr> wrote: > >> Hi Eliot, >> >> Le 19 mars 2014 Ã 16:25, Eliot Miranda a Ã©crit : >> >> Hi Christophe, >> >> On Mar 19, 2014, at 1:45 AM, Christophe Demarey < >> Christophe.Demarey(a)inria.fr> wrote: >> >> >> Le 18 mars 2014 Ã 19:50, Eliot Miranda a Ã©crit : >> >> On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey < >> Christophe.Demarey(a)inria.fr> wrote: >> >>> Why arguments should be read only? >>> They are just temporary variables with an initial value. >>> >> >> Read the blue book. It was a decision of the language designers to >> forbid assignment to arguments to allow debugging. The assignment to block >> arguments is a side-effect of the old BlockContext implementation of blocks >> where block arguments were mapped onto temporary variables of the home >> context. It is an anachronism and should be forbidden also. >> >> >> Thank you for the explanation. >> I'm just curious why it is so difficult to implement a debugger if >> arguments are assignable? >> If you need to restart the execution of a method, and so you need to get >> the initial value of the argument, I understand you cannot find the value >> anymore in the method context but it is available in the caller context, no? >> As I never implemented a debugger, I cannot figure out the difficulties. >> >> >> the args are no longer available; they get moved from the caller context >> to the callee. If you think about stack frames then what happens is that >> the slots containing the outgoing arguments are used as the slots for the incoming >> arguments. So if arguments are assigned to they are indeed lost. >> >> >> ok, I understand. Thank you for the explanation. >> >> >> But look at how many methods in the system (or in any system). The >> proportion of methods/functions/procedures that could be written to assign >> their arguments is very small so the Smalltalk trade off is a good one. >> >> >> I agree we don't really loose something. You can always assign arguments >> to temporary variables and update temporary variables. My point was just: >> if possible, why don't do it? >> > > It's that tricky trade-off between value and cost. Is it worth it? Does > doing it provide as much value as doing what it displaces (opportunity > cost). IMO it simply doesn't provide enough value, and there are different > priorities in the compiler. But if you disagree implement it your self and > then it'll be done. > > > It looks like "My point was just: if possible, why don't do it?" was > misunderstood. > I wanted to say: if available for free (no work needed, why forbid it?). > You gave a very good reason and I also think that the cost does not worth > the value. :) > Agreed. Good discussion. -- best, Eliot

March 24, 2014

Re: [Pharo-dev] threading in Pharo

by Jan Vrany

Hi, On 24/03/14 17:56, Alexandre Bergel wrote: > Hi! > > Threads in Pharo have always been mysterious for me. > If I doit the following: [ true ] whileTrue > Can other thread interrupt this? > > Say in other words, can the following piece of code may suffer from a concurrent problem in Pharo > anOrderedCollection add: 42 > > My current understanding about thread is that there is a scheduling that may occurs each time we enter the VM (e.g., primitive call, instantiating an object, throwing an exception). So, the code "anOrderedCollection add: 42â will _never_ suffer from concurrent call because adding 42 to a collection does not enter the VM. Does this make sense? I don't think so. AFAIK interrupts are checked on message sends and on backward jumps (because of inlined loops just like in your example). So context switch may happen on each send... Jan > > What is the current status of this? > > Thanks to you all > Alexandre >

March 24, 2014

threading in Pharo

by Alexandre Bergel

Hi! Threads in Pharo have always been mysterious for me. If I doit the following: [ true ] whileTrue Can other thread interrupt this? Say in other words, can the following piece of code may suffer from a concurrent problem in Pharo anOrderedCollection add: 42 My current understanding about thread is that there is a scheduling that may occurs each time we enter the VM (e.g., primitive call, instantiating an object, throwing an exception). So, the code "anOrderedCollection add: 42â will _never_ suffer from concurrent call because adding 42 to a collection does not enter the VM. Does this make sense? What is the current status of this? Thanks to you all Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 24, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Christophe Demarey

Hi Eliot, Le 20 mars 2014 Ã 17:04, Eliot Miranda a Ã©crit : > On Thu, Mar 20, 2014 at 2:03 AM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > Hi Eliot, > > Le 19 mars 2014 Ã 16:25, Eliot Miranda a Ã©crit : > >> Hi Christophe, >> >> On Mar 19, 2014, at 1:45 AM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >> >>> >>> Le 18 mars 2014 Ã 19:50, Eliot Miranda a Ã©crit : >>> >>>> On Tue, Mar 18, 2014 at 10:10 AM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >>>> Why arguments should be read only? >>>> They are just temporary variables with an initial value. >>>> >>>> Read the blue book. It was a decision of the language designers to forbid assignment to arguments to allow debugging. The assignment to block arguments is a side-effect of the old BlockContext implementation of blocks where block arguments were mapped onto temporary variables of the home context. It is an anachronism and should be forbidden also. >>> >>> Thank you for the explanation. >>> I'm just curious why it is so difficult to implement a debugger if arguments are assignable? >>> If you need to restart the execution of a method, and so you need to get the initial value of the argument, I understand you cannot find the value anymore in the method context but it is available in the caller context, no? >>> As I never implemented a debugger, I cannot figure out the difficulties. >> >> the args are no longer available; they get moved from the caller context to the callee. If you think about stack frames then what happens is that the slots containing the outgoing arguments are used as the slots for the incoming arguments. So if arguments are assigned to they are indeed lost. > > ok, I understand. Thank you for the explanation. > > >> But look at how many methods in the system (or in any system). The proportion of methods/functions/procedures that could be written to assign their arguments is very small so the Smalltalk trade off is a good one. > > I agree we don't really loose something. You can always assign arguments to temporary variables and update temporary variables. My point was just: if possible, why don't do it? > > It's that tricky trade-off between value and cost. Is it worth it? Does doing it provide as much value as doing what it displaces (opportunity cost). IMO it simply doesn't provide enough value, and there are different priorities in the compiler. But if you disagree implement it your self and then it'll be done. It looks like "My point was just: if possible, why don't do it?" was misunderstood. I wanted to say: if available for free (no work needed, why forbid it?). You gave a very good reason and I also think that the cost does not worth the value. :) Cheers, Christophe.

March 24, 2014

Re: [Pharo-dev] new website about Artefact

by phil＠highoctane.be

+3 On Mon, Mar 24, 2014 at 3:53 PM, Sergi Reyner <sergi.reyner(a)gmail.com>wrote: > 2014-03-24 14:40 GMT+00:00 olivier <olivier.auverlot(a)gmail.com>: > >> Hi, >> >> A website is now available about Artefact. Documentation and useful >> informations are grouped to help you to produce many and beautiful PDF >> documents with Pharo. >> >> https://sites.google.com/site/artefactpdf/ > > > I am of the opinion that any documentation that includes unicorns is an > automatic +1. > So, +2! > > Cheers, > Sergi >

March 24, 2014

Re: [Pharo-dev] new website about Artefact

by camille teruel

Congrats it's very funny :D 2014-03-24 15:40 GMT+01:00 olivier <olivier.auverlot(a)gmail.com>: > Hi, > > A website is now available about Artefact. Documentation and useful > informations are grouped to help you to produce many and beautiful PDF > documents with Pharo. > > https://sites.google.com/site/artefactpdf/ > > The pasta team >

March 24, 2014

Re: [Pharo-dev] new website about Artefact

by Sergi Reyner

2014-03-24 14:40 GMT+00:00 olivier <olivier.auverlot(a)gmail.com>: > Hi, > > A website is now available about Artefact. Documentation and useful > informations are grouped to help you to produce many and beautiful PDF > documents with Pharo. > > https://sites.google.com/site/artefactpdf/ I am of the opinion that any documentation that includes unicorns is an automatic +1. So, +2! Cheers, Sergi

March 24, 2014

new website about Artefact

by olivier

Hi, A website is now available about Artefact. Documentation and useful informations are grouped to help you to produce many and beautiful PDF documents with Pharo. https://sites.google.com/site/artefactpdf/ The pasta team

March 24, 2014

Created PetitParserExtension project

by Guillaume Larcheveque

Hi everybody, I am using PetitParser a lot and had implemented some little tools that help me for writing or generating grammars. I put two of the most useful in the project PetitParserExtension ( http://smalltalkhub.com/#!/~Moose/PetitParserExtensions) the first one is useful when you generate grammars with lots of rules: A PPExtendedCompositeParser offers you a new way to create rules. Just define your rule as a method in the #rules protocol and it will be managed exactly like rules in PPCompositeParser. You will not have the limitation of 256 rules due to the instance variables limit but you will need to refer to your rule with the method #rule: in any other rule using it. You can mix PPCompositeParser and PPExtendedCompositeParser way to define rules. the second one is cool for token identification because it creates a parser that will parse in a time depending on token length and not the number of different tokens. A PPMultiStringParser is a tool able to create a really effective parser on a huge collection of Strings. This parser will match any string in this collection, and the longest one if two are matchable (( PPMultiStringParser on: #('tin' 'tintin')) parse: 'tintin' will match 'tintin' and not just 'tin') If someone else has implemented some tools around PetitParser, it will be great to put those all together so feel free to commit your tools in this project and to improve mines. -- *Guillaume Larcheveque*

March 24, 2014

Re: [Pharo-dev] Debugger acting up

by Gary Chambers

Hi, maybe related to something I found when using our locked-down images (no Tools in ToolRegistry). In SmalltalkImage>>openLog FileStream fileNamed: Smalltalk tools debugger logFileName was causing a loop since the default error handling ends up sending #logDuring:, which sends #openLog, causing an attempt to log an error (no debugger)... For a quick workaround I changed to openLog "This is a _private_ method, Because it really belongs to logging facility, we should delegate to it at some point " ^ ( FileStream fileNamed: Debugger logFileName ) wantsLineEndConversion: true; setToEnd; yourself though obviously not ideal having the direct reference to Debugger there. Regards, Gary ----- Original Message ----- From: "Diego Lont" <diego.lont(a)delware.nl> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> Sent: Friday, March 21, 2014 2:32 PM Subject: [Pharo-dev] Debugger acting up Hi all, I do not have a proper test case yet, but as I have seen it twice now I want to ask you guys if you have any problems with it. In a recent moose 5.0 image with seaside and some other suff loaded, the page would not load. Interrupting the image showed that the debugger was lost in the following loop: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: Originally it was a halt that caused the signal, and that should pop up the debugger, but instead of that it went into an infinite loop. Now I see that building Pier3 development on a pharo2 image also seems to causes this loop. The root cause is also in the mail, so maybe this is just the size of the stack ...: Startup Error: An attempt to use interactive tools detected, while in non-interactive mode Interactive Request: You are about to load new versions of the following packages that have unsaved changes in the image: Grease-Tests-Pharo20-Core If you continue, you will lose these changes: [0mNonInteractiveUIManager>>nonInteractiveWarning: NonInteractiveUIManager>>nonInteractiveRequest:title: NonInteractiveUIManager>>nonInteractiveRequest: NonInteractiveUIManager>>confirm:trueChoice:falseChoice:cancelChoice:default: MCMergeOrLoadWarning>>defaultAction UndefinedObject>>handleSignal: If anyone knows where this problem might come from, please put a mail on the mailing list. Cheers, Diego

March 24, 2014