July 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Nicolas Cellier

2009/7/8 Michael van der Gulik <mikevdg(a)gmail.com>: > > > 2009/7/8 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> >> >> I added this new issue that happens on the latest image. >> I'm posting it here because I think it is an important bug because it >> affects the number model. >> The problem is related with all fractions who's denominator is not power >> of two. (130/100 = 1.3 or 1/5 = 0.2, etc) >> (See >> >> Float>>adaptToFraction: rcvr andCompare: selector where it does >> .... >> "Try to avoid asTrueFraction because it can cost" >> selector == #= ifTrue: [ >> rcvr denominator isPowerOfTwo ifFalse: [^false]]. >> >> >> ...) >> > > A hypothetical question: would it be harmful if the compiler stored number > literals as Fractions rather than Floats? For example, the compiler could > store "1.3" as the literal "13/10" in the CompiledMethod. The denominator > would always be a multiple of 10 or whatever the base of the specified > number is. > > Gulik. > > Well this already exists and is named ScaledDecimal... > -- > http://gulik.pbwiki.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Igor Stasenko

2009/7/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/7/7 John M McIntosh <johnmci(a)smalltalkconsulting.com>: >> Let me step back and say, ok you are possibly breaking existing code, >> and causing all sorts of confusion for an >> optimization change? Â So where is the justification from the >> optimization viewpoint? Does it make browser >> windows open in 1/2 the time? >> >> If it takes more time milliseconds? to produce an answer that is what >> people expect, then t I think it's worth it. >> Yes I understand that floats are inexact but people think they know >> how they work thus expect to be able to say >> (13/10) = 1.3 Â without having to give clues with asFloat to indicate >> their intent. >> >> Let me see >> squeak 3.10.x Â (13/10) = 1.3 Â true >> Pharo 1037 Â (13/10) = 1.3 Â false >> VisualWorks (13/10) = 1.3 Â true >> >> I would classify this as a bug >> >> > > I repeat here my arguments: > Anyone depending on (13/10) = 1.3 is plain wrong... > +1. I dealt with 3D rendering/linear algebra using floats in the past , and i can say just one: - never write the code which compares the floats to be equal to some exact value. It makes no sense in practice, because of inexact nature of floats. For instance, i remember the code i wrote, to test whether two vectors perpendicular: float := n1 * n2 (where n1 , n2 - is line normals, and * - is dot product). As we know, if two vectors is perpendicular, then their dot product is zero. But it is almost always non-zero on hardware, especially when you transform vectors or compute them using data, which already contains a degree of precision error! So, i learned that comparing dot product with zero makes no sense, instead you'd better test it with something like: abs(float) < epsilon where epsilon is very small number. So, i don't understand, why its so important for such kind of equality tests to work right at all - because you hardly will use such tests in practice. > Either you want fast and inexact floating point operation and should > not rely on exact equality (use #closeTo:). > Or you want (13/10) = 1.3 EXACTLY, and then should better use ScaledDecimal. > That's the deal, and it's quite independant from the language. > > The false assertions that people are trying to push does not matter: > it's high time to educate. > My proposition has at least the merit to put a light on these > dangerous floating point strict equality tests > (I saw so many bugs like testing cos(pi/2) == 0). > > And I'm still waiting for the hypothetical application that would > break because of this change. > That's the main point of interest. > In this case, we'll see if patching is necessary and easy. > > Nicolas > > P.S. concerning behaviour of conversion binary<->decimal > representation, I'm rather the one trying to unify Smalltalk. > Dolphin, gst and Pharo adopted some of my changes to behave as exactly > as we can, and thus behave the same. > Try this in your prefered dialect, I guess you will have some surprise. > 123.4567890123d3 = (1234567890123/10000000). > 123.4567890123d3 = (1234567890123/10000000) asFloat. > > _______________________________________________ > 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.

July 7, 2009

Re: [Pharo-project] extended search -> senders of it (n) - defect?

by Mariano Martinez Peck

On Tue, Jul 7, 2009 at 6:32 PM, Cameron Sanders <camsanders01(a)roadrunner.com > wrote: > Having made some bozo statements lately, I am hesitant to even inquire > (because I am probably doing something dumb), but... > > I noted an error in my code that read xxx isNumber ifNil: [...] and > figured that when I imported in from VisualWorks, I must have "fixed" > things too hastily. Wondering where else I may have made this error I > did the following on an iMac using the 10371web image recently posted: > > In a workspace I typed and highlighted "ifNil:" --without the quotes > of course-- and selected "extended search...". > Then I selected "senders of it (n)", and to my surprise, not my > erroneous method was not displayed in the results. Ten (10) methods > turn up in the results, and some of them are not actually senders of > it; the non-senders may include the pattern in an array, or as a > substring of some symbol. can you give us a concrete example? In my opinion, if you have a symbol with that text, it must be found by "senders of it". In VAST it is like that. So, if you have #ifNil: for me it is correct to be found. best, Mariano > > > Is this a known defect? Previously (from images two months ago and > less) this searching worked as expected. > > A search of the defect db, using only the word "senders", gave me this > (semi-related) issue: > > http://code.google.com/p/pharo/issues/detail?id=261&q=sendeifNilrs&colspec=…<http://code.google.com/p/pharo/issues/detail?id=261&q=senders&colspec=ID%20…> > > Thanks in advance, > Cam > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Michael van der Gulik

2009/7/8 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > I added this new issue that happens on the latest image. > I'm posting it here because I think it is an important bug because it > affects the number model. > The problem is related with all fractions who's denominator is not power of > two. (130/100 = 1.3 or 1/5 = 0.2, etc) > (See > > Float>>adaptToFraction: rcvr andCompare: selector where it does > .... > "Try to avoid asTrueFraction because it can cost" > selector == #= ifTrue: [ > rcvr denominator isPowerOfTwo ifFalse: [^false]]. > > ...) > > A hypothetical question: would it be harmful if the compiler stored number literals as Fractions rather than Floats? For example, the compiler could store "1.3" as the literal "13/10" in the CompiledMethod. The denominator would always be a multiple of 10 or whatever the base of the specified number is. Gulik. -- http://gulik.pbwiki.com/

July 7, 2009

Re: [Pharo-project] Fwd: issue 348

by Igor Stasenko

2009/7/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Your cents are valuable! > Thanks. Then 1 more cent: No doubt , this will require deep refactoring/rethinking the Compiler & requestor roles. But it would help greatly in cleaning the Compiler/Parser code from things which related to handle uncertainties, like non-existing selector(s), undefined identifiers, unused temps and so on.. > 2009/7/8 Igor Stasenko <siguctua(a)gmail.com>: >> My 2 cents: >> >> compiler should always work together with requestor: >> >> Compiler compile: some thing requestor: aRequestor. >> >> Then it could always ask, aRequestor if its interactive, or not, >> but i think, Compiler could live just well without such knowledge at >> all - each time it needs some extra data - it can simply ask the >> requestor to handle such particular situation, in a fashion like >> following: >> >> Compiler>>compileError: error >> Â ^ requestor handleError: error ifUnhandled: [ error signal ] >> >> all we need is just carefully establish protocol between Compiler and >> requestor object, so then making interactive/non-interactive/partly >> interactive will be completely independant from Compiler. >> >> 2009/7/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> Hi Pavel >>> >>>> Hi, >>>> >>>> every UIManager may have its own preference about this behaviour >>>> (for example the dummy ui manager has no user input). It is cleaner >>>> solution than to set interactivity for every Compiler instance or >>>> for the Compiler class. >>> >>> In fact I have the impression that this is the same pattern than with >>> preference class. >>> We are now making sure that the Preference layer can be remove by >>> removing references from within the package to the Preference >>> class and we turn into a flow from the preference class to push value >>> to the tools default value. >>> >>> Similarly we prefer Â that the UIManager pushes information to the >>> compiler and not that the compiler rely on >>> UIManager. I would like to think about a Compiler been able to run >>> standalone without UI. >>> >>> Now we could have >>> >>> UIManager>> setUpForNonInteraction >>> >>> Â Â Â Â Â Â Â Â Compiler setInNonInteractiveMode >>> Â Â Â Â Â Â Â Â ,... >>> Â Â Â Â Â Â Â Â other class >>> >>> and Compiler code >>> referring to itself (its value for non interaction) >>> >>> This way we could even remove completely the UIManager. >>> >>> Else I think that UIManager will become another huge facade that we >>> cannot remove. >>> >>> >>> >>>> >>>> Cheers, >>>> -- Pavel >>>> >>>> >>>> On Tue, Jul 7, 2009 at 7:22 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >>>> > wrote: >>>> pavel I was wondering why you want to have interactiveParserFor: in >>>> UIManager and not in Compiler? >>>> >>>> May be I missed something but I'm ready to learn. >>>> >>>> Stef >>>> >>>> >>>> >>>> >>>> On Jul 7, 2009, at 7:18 PM, StÃ©phane Ducasse wrote: >>>> >>>> > >>>> > From: Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>> > Date: July 6, 2009 2:26:56 PM CEDT >>>> > To: stephane ducasse <stephane.ducasse(a)free.fr> >>>> > Subject: issue 348 >>>> > >>>> > Hi Stef, >>>> > >>>> > I updated the issue http://code.google.com/p/pharo/issues/detail? >>>> > id=348 >>>> > >>>> > Cheers, >>>> > -- Pavel >>>> > >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > 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 >>> >> >> >> >> -- >> 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.

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by John M McIntosh

On 7-Jul-09, at 2:46 PM, Nicolas Cellier wrote: > I repeat here my arguments: > Anyone depending on (13/10) = 1.3 is plain wrong... Historically and as far as I can tell in all other versions of smalltalk (13/10) = 1.3 why be different? If you *want* exact then I suggest you have (13/10) asAInexactFloatExactlyEquals: 1.3 and let who wants that type of compare live with it. As for real world examples. http://www.mobilewikiserver.com/Fraction.html has 104 test cases, unluckily the the math ones didn't trigger a failure but the calculator keyboard entry engine did " Test to enter .1 in memory storage, then confirm retrieval works" self tap: '.'. self tap: 1. self tap: 'S'. self should: [self enteredData = '.1']. self should: [self storedEntry = 0.1]. because (1/10) = 0.1 => false Sometimes what is false can be true because well people do think 1/10 = 0.1 -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Nicolas Cellier

2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > The answer is true on 7.6, and I don't think anything changed that for > 7.7. Â Historical background aside, I think it's wrong anyway... in the > hash book, exercise 7.20 asks to find two different fractions that are > equal to the same float. Â In other words, if f is a float, and r1 and r2 > are fractions, then r1 ~= r2 but r1 = f and r2 = f. Â And those do exist... > > Andres. > Il y a mÃªme une infinitÃ© de Fractions r telles que f-0.5*ulp < r < f+0.5ulp Anyway, Andres, tell me what how you can bear this VW behaviour I exposed to Michael L.S. 9.9999730e20 printString -> '1.0e21' 9.9999731e20 printString -> '9.99997e20' 9.9999731e20 >= 9.9999730e20. false To me, this is a clear violation of ISO/IEC 10967-2 http://www.cs.chalmers.se/~kent/ISOStandards/SC22/WG11/LIA-2/N424.ps I guess "we Smalltalk guys are smarter and did not change things for 30 years, so why bother now" is our best argument :) Nicolas > > StÃ©phane Ducasse wrote: >> so andres what will be the value of >> >>>> (13/10) = 1.3 >>>> >> in VW7.7 >> >> On Jul 7, 2009, at 11:18 PM, Andres Valloud wrote: >> >> >>> VisualWorks introduced LimitedPrecisionReal>>asFraction. Â That message >>> returns the actual floating point value represented by the >>> receiver. Â Of >>> course, I messed up and forgot * self sign... but that's the idea (and >>> it's fixed for 7.7). Â So, in reality, you should compare >>> >>> 13/10 = 1.3 asFraction >>> >>> which will answer false, like it should. >>> >>> Andres. >>> >>> >>> John M McIntosh wrote: >>> >>>> Let me step back and say, ok you are possibly breaking existing code, >>>> and causing all sorts of confusion for an >>>> optimization change? Â So where is the justification from the >>>> optimization viewpoint? Does it make browser >>>> windows open in 1/2 the time? >>>> >>>> If it takes more time milliseconds? to produce an answer that is what >>>> people expect, then t I think it's worth it. >>>> Yes I understand that floats are inexact but people think they know >>>> how they work thus expect to be able to say >>>> (13/10) = 1.3 Â without having to give clues with asFloat to indicate >>>> their intent. >>>> >>>> Let me see >>>> squeak 3.10.x Â (13/10) = 1.3 Â true >>>> Pharo 1037 Â (13/10) = 1.3 Â false >>>> VisualWorks (13/10) = 1.3 Â true >>>> >>>> I would classify this as a bug >>>> >>>> >>>> On 7-Jul-09, at 10:43 AM, Hernan Wilkinson wrote: >>>> >>>> >>>> >>>>> I added this new issue that happens on the latest image. >>>>> I'm posting it here because I think it is an important bug because >>>>> it affects the number model. >>>>> The problem is related with all fractions who's denominator is not >>>>> power of two. (130/100 = 1.3 or 1/5 = 0.2, etc) >>>>> (See >>>>> Float>>adaptToFraction: rcvr andCompare: selector where it does >>>>> Â .... >>>>> Â "Try to avoid asTrueFraction because it can cost" >>>>> Â Â selector == #= ifTrue: [ >>>>> Â Â Â rcvr denominator isPowerOfTwo ifFalse: [^false]]. >>>>> >>>>> Â ...) >>>>> >>>>> >>>>> Hernan. >>>>> >>>>> >>>> -- >>>> = >>>> = >>>> = >>>> = >>>> = >>>> = >>>> ===================================================================== >>>> 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 >>>> >>>> >>>> >>> _______________________________________________ >>> 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 >

July 7, 2009

Re: [Pharo-project] Fwd: issue 348

by Nicolas Cellier

Your cents are valuable! 2009/7/8 Igor Stasenko <siguctua(a)gmail.com>: > My 2 cents: > > compiler should always work together with requestor: > > Compiler compile: some thing requestor: aRequestor. > > Then it could always ask, aRequestor if its interactive, or not, > but i think, Compiler could live just well without such knowledge at > all - each time it needs some extra data - it can simply ask the > requestor to handle such particular situation, in a fashion like > following: > > Compiler>>compileError: error > Â ^ requestor handleError: error ifUnhandled: [ error signal ] > > all we need is just carefully establish protocol between Compiler and > requestor object, so then making interactive/non-interactive/partly > interactive will be completely independant from Compiler. > > 2009/7/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Hi Pavel >> >>> Hi, >>> >>> every UIManager may have its own preference about this behaviour >>> (for example the dummy ui manager has no user input). It is cleaner >>> solution than to set interactivity for every Compiler instance or >>> for the Compiler class. >> >> In fact I have the impression that this is the same pattern than with >> preference class. >> We are now making sure that the Preference layer can be remove by >> removing references from within the package to the Preference >> class and we turn into a flow from the preference class to push value >> to the tools default value. >> >> Similarly we prefer Â that the UIManager pushes information to the >> compiler and not that the compiler rely on >> UIManager. I would like to think about a Compiler been able to run >> standalone without UI. >> >> Now we could have >> >> UIManager>> setUpForNonInteraction >> >> Â Â Â Â Â Â Â Â Compiler setInNonInteractiveMode >> Â Â Â Â Â Â Â Â ,... >> Â Â Â Â Â Â Â Â other class >> >> and Compiler code >> referring to itself (its value for non interaction) >> >> This way we could even remove completely the UIManager. >> >> Else I think that UIManager will become another huge facade that we >> cannot remove. >> >> >> >>> >>> Cheers, >>> -- Pavel >>> >>> >>> On Tue, Jul 7, 2009 at 7:22 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >>> > wrote: >>> pavel I was wondering why you want to have interactiveParserFor: in >>> UIManager and not in Compiler? >>> >>> May be I missed something but I'm ready to learn. >>> >>> Stef >>> >>> >>> >>> >>> On Jul 7, 2009, at 7:18 PM, StÃ©phane Ducasse wrote: >>> >>> > >>> > From: Pavel Krivanek <pavel.krivanek(a)gmail.com> >>> > Date: July 6, 2009 2:26:56 PM CEDT >>> > To: stephane ducasse <stephane.ducasse(a)free.fr> >>> > Subject: issue 348 >>> > >>> > Hi Stef, >>> > >>> > I updated the issue http://code.google.com/p/pharo/issues/detail? >>> > id=348 >>> > >>> > Cheers, >>> > -- Pavel >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 >> > > > > -- > 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

July 7, 2009

Re: [Pharo-project] FFI problem

by Mariano Martinez Peck

Ok, now you can close http://code.google.com/p/pharo/issues/detail?id=908 in 10372 On Tue, Jul 7, 2009 at 6:26 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Jul 7, 2009, at 11:20 PM, Mariano Martinez Peck wrote: > > > Stef: Yes, it works. But, I have some questions: > > > > 1) Is it ok to have > > > > self new installer monticello http: > > 'source.squeakfoundation.org'; ??? > > > > or it is just temp ? In addition, why was #squeakfundation removed ? > > this is because now all is here: source.squeakfoundation.org??? If > > so, we can create a method for this new repository... > > It is temporary. > First I would say that FFI should have a loader doing the > initialization properly. > Second we will probably have a new loader in the near future. > > > > 2) I don't know what Smalltalk recreateSpecialObjectsArray. > > specialObjectsArray is an array known by the VM > > > But older version of FFI worked ok and also this version works ok in > > Linux...I don't understand why. > > I do not know :) > > > Is there a logic here I cannot see ? > > Is there a drawback in evaluating Smalltalk > > recreateSpecialObjectsArray. ? > > > > Cheers, > > > > Mariano > > > > On Tue, Jul 7, 2009 at 8:01 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr > > > wrote: > > Mariano > > > > I just published in Pharo a new ScriptLoader which I hope fix the > > problem. > > Could you check it? > > > > Stef > > > > On Jul 5, 2009, at 9:05 PM, Mariano Martinez Peck wrote: > > > > > Andreas: can you see new comments here: > http://code.google.com/p/pharo/issues/detail?id=908 > > > > > > What do you think? > > > > > > Thanks! > > > > > > Mariano > > > > > > On Tue, Jun 30, 2009 at 12:26 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com > > > > wrote: > > > I crated the issue so that no to forget about it: > > > > > > http://code.google.com/p/pharo/issues/detail?id=908 > > > > > > Best, > > > > > > Mariano > > > > > > > > > On Sun, Jun 28, 2009 at 3:56 AM, Andreas Raab <andreas.raab(a)gmx.de> > > > wrote: > > > Mariano Martinez Peck wrote: > > > Ok. Pharo people is in this mail. Let's wait if someone can help us. > > > > > > Please cc vm-dev on any responses. I'm not subscribed to the Pharo > > > list. > > > > > > > > > I don't know why in mi Windows machine the dump file is not > > > generated :( > > > > > > It looks like the crash has two different ways of showing. In the > > > first situation, it crashes with a recursive DNU. In the second, it > > > actually does generate a crash dump (attached). The latter seems to > > > happen when you try to step through the code. > > > > > > > > > Benoit St-Jean can you attach the complete dump file? > > > > > > I tried this in Linux and it doesn't crash my image. So, only > > > windows :( > > > > > > Difficult to say. There is a good possibility that the problem is > > > unrelated to the FFI since I have been completely unable to > > > reproduce the problem elsewhere. > > > > > > Cheers, > > > - Andreas > > > > > > > > > _______________________________________________ > > > 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 >

July 7, 2009

Re: [Pharo-project] Fwd: issue 348

by Igor Stasenko

My 2 cents: compiler should always work together with requestor: Compiler compile: some thing requestor: aRequestor. Then it could always ask, aRequestor if its interactive, or not, but i think, Compiler could live just well without such knowledge at all - each time it needs some extra data - it can simply ask the requestor to handle such particular situation, in a fashion like following: Compiler>>compileError: error ^ requestor handleError: error ifUnhandled: [ error signal ] all we need is just carefully establish protocol between Compiler and requestor object, so then making interactive/non-interactive/partly interactive will be completely independant from Compiler. 2009/7/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi Pavel > >> Hi, >> >> every UIManager may have its own preference about this behaviour >> (for example the dummy ui manager has no user input). It is cleaner >> solution than to set interactivity for every Compiler instance or >> for the Compiler class. > > In fact I have the impression that this is the same pattern than with > preference class. > We are now making sure that the Preference layer can be remove by > removing references from within the package to the Preference > class and we turn into a flow from the preference class to push value > to the tools default value. > > Similarly we prefer Â that the UIManager pushes information to the > compiler and not that the compiler rely on > UIManager. I would like to think about a Compiler been able to run > standalone without UI. > > Now we could have > > UIManager>> setUpForNonInteraction > > Â Â Â Â Â Â Â Â Compiler setInNonInteractiveMode > Â Â Â Â Â Â Â Â ,... > Â Â Â Â Â Â Â Â other class > > and Compiler code > referring to itself (its value for non interaction) > > This way we could even remove completely the UIManager. > > Else I think that UIManager will become another huge facade that we > cannot remove. > > > >> >> Cheers, >> -- Pavel >> >> >> On Tue, Jul 7, 2009 at 7:22 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >> > wrote: >> pavel I was wondering why you want to have interactiveParserFor: in >> UIManager and not in Compiler? >> >> May be I missed something but I'm ready to learn. >> >> Stef >> >> >> >> >> On Jul 7, 2009, at 7:18 PM, StÃ©phane Ducasse wrote: >> >> > >> > From: Pavel Krivanek <pavel.krivanek(a)gmail.com> >> > Date: July 6, 2009 2:26:56 PM CEDT >> > To: stephane ducasse <stephane.ducasse(a)free.fr> >> > Subject: issue 348 >> > >> > Hi Stef, >> > >> > I updated the issue http://code.google.com/p/pharo/issues/detail? >> > id=348 >> > >> > Cheers, >> > -- Pavel >> > >> > >> > >> > >> > _______________________________________________ >> > 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 > -- Best regards, Igor Stasenko AKA sig.

July 7, 2009