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

Re: [Pharo-project] New Pharo based on core 10413

by StÃ©phane Ducasse

sure this is a beta and if you update this is fixed. Stef On Aug 15, 2009, at 8:27 AM, Eagle Offshore wrote: > I just downloaded the 1.0beta on the site and it immediately throws up > a deprecation warning bout initialsPerSe - please use fullNamePerSe > > That makes a poor first impression. > > On Aug 9, 2009, at 10:48 AM, Damien Cassou wrote: > >> Please download and report problems: >> >> http://pharo-project.org/pharo-download >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> >> _______________________________________________ >> 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

Aug. 16, 2009

Re: [Pharo-project] Class browser with changing title.

by StÃ©phane Ducasse

Hi javier did you sign the license agreement? and send it to me :)? Then open an entry in the bug tracker and add you changes there. Stef On Aug 15, 2009, at 2:28 AM, Javier PimÃ¡s wrote: > Thanks everybody for the answers of last post. Finally I used the > technique Mariano recommended because it was just what I wanted. > > Here I'm proposing a really small change to the class browser so > that whenever a class or method is selected it's title is changed > accordingly. The title produced is such that you can distinguish the > browsers when looking at the taskbar (very usefull when you have > many browsers opened). In case you like it, it would be nice to have > it included in main pharo. > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > <ClassBrowserchange. > 1.cs>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 16, 2009

Re: [Pharo-project] Mouse does not find matching when closing paren is immediately following single quotes

by StÃ©phane Ducasse

probably related to shout Stef On Aug 14, 2009, at 9:50 PM, csrabak(a)bol.com.br wrote: > Be it in the Workspace or a System Browser pane if you have: > > #('something'1 2 3 'nothing') "exactly this way" > > if you (red) click the left paren all the parenthesis contents get > highlited, however, if you click the right paren, then no highlit > happens. You've to put a space between the quote, so the example > above has to change to: > > #('something'1 2 3 'nothing' ) > > In order to get the higliting back. As this obviously is not a > feature :-) I think we should see if it can be put in investigation > to be fixed in next releases... > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 16, 2009

Re: [Pharo-project] Newbie new initialize [WAS: Incompatibilities was: #< if at first you dont succeed..]

by StÃ©phane Ducasse

Yes we did :) Stef On Aug 14, 2009, at 9:40 PM, Ken.Dickey wrote: > I highly recommend _Squeak by Example_. My recollection (highly > suspect) is > that they refer to the base change which added #initialize. > > http://squeakbyexample.org/ > > Good on you, > -KenD > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 16, 2009

Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?

by Schwab,Wilhelm K

Sig, all, I have been preparing MC packages with classes and method designed to soften the blow of moving much of my domain code to Pharo. In this case, I have some sends of ProcessorSchedler>>forkMainIfMain, so I created that method. Initially, I made it emtpy, and then based on what you helpe me find, I tried ProcessorScheduler>>forkMainIfMain Project spawnProcessIfThisIsUI:self activeProcess. The above gets called from something that then immediately waits on a semaphore that is signalled by one of two threads. One of the threads waits on a timer, the other tries to evaluate a block; creating a background worker thread that will run for a limited time. There is a test case that tries various combinations, some of which should succeed and some should time out. I have used these things in production in Dolphin for some time. In Dolphin, #forkMainIfMain allows the UI to be responsive during these tests, but trying the above in Pharo turns ugly. There are problems that appear to related to two UI processes - running short of events or something like that. The tests run for only a few seconds, though I suppose I could try to allow enough time to look around, but then I'm probably not the right person to do the looking anyway. DUMB question: the argument to #spawnProcessIfThisIsUI: is named suspendedProcess. Do I need to ensure the process in question is indeed suspended before entering the method? If so, then I start wondering how to get there from #forkMainIfMain, but it's a little late for my brain to take on that question. One thing is certain: what I tried did not work. There were errors from the event loop and even some screen scarring. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Saturday, August 15, 2009 3:29 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? 2009/8/15 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Is there anything in Pharo that starts a new main thread to carry on for one that is about to get blocked? Â It might be that Pharo does not need it, since sockets are serviced by the VM, where Dolphin (at least prior to overlapped calls) did the I/O through the event loop; if the main thread stopped, so did Windows event dispatching, and hence no socket I/O. > There is such thing. Try to explore the way how debugger handling this (when process you want to debug is current UI process), or when you pressing interrupt key. See Debugger>>openOn: process context: context label: title contents: contentsStringOrNil fullView: bool at 'Project spawnNewProcessIfThisIsUI: process' > Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create modal loops in Smalltalk code. Â I see a few references to such things in Pharo, but I'm fairly lost. Â Where should I start reading and/or browsing? > > Bill > > > > > _______________________________________________ > 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

Aug. 16, 2009

Re: [Pharo-project] Complex number support discussion

by Schwab,Wilhelm K

Cesar, Storing integers and fractions for the real and imaginary parts of a complex number will be of benefit in a very small number of cases. Most uses of complex numbers involve transcendental functions that will not produce "nice" results in the general case. Your closing paragraphs below, well, let's just say I disagree. If you and Ken, separately or together, put proposal(s) on the wiki, I will gladly respond with comments on the pages and/or counter proposal(s), and would be glad to work with Sig on same. As for this seemingly endless chain of email rehashing the same points, I'm done. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br Sent: Saturday, August 15, 2009 9:04 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion Em 15/08/2009 19:21, Igor Stasenko < siguctua(a)gmail.com > escreveu: > 2009/8/16 <csrabak(a)bol.com.br>: > > Your first example is interesting. It boils down to two design aspects: > > > > If you need Complex numbers in the same application, you need to > > refactor the code to: > > > > > length := (something positive) ifTrue:[something sqrt ] > > IfFalse: Error do: [ 5 ]. > > i'm sure you meant > length := (something positive) ifTrue:[something sqrt ] IfFalse: [ 5 ] I'm not so sure ;-) I thought your block with a five inside some kind of error message, but this is not that important. It seems you get the spirit and considering my mistake on interpreting your example your correction is OK. > > but then > #positive is a test which defined as > > positive > ^ self > 0 > > and we getting back to discussion , what is the meaning of #> or #< > operator for complex values. > NO!! Because all this discussion is being on the possibility of having an operation on a _non_ Complex number return a Complex result, so the test is kosher and you can go. _If_ you return an argument that something already was a complex number then all this argument is moot... [snipped] > > Once you put Complex in the Smalltalk paradigm, I think we should > > preserve as much as possible this design decision made at the start of the language. > > From a programming POV -4 sqrt mapping from Real to Imaginary > > (Complex) is homologous to 13 / 3 giving a Fraction. Overall is a modeling of the world. > > > > BTW, this is why I think having Complex to only have Float members > > is not a nice design decision... > > > ageed. Its can hold any values representing the value from a Real set. > But as soon as one of its member start holding someting different > (Complex) - you are in trouble. It depends. My reasoning was that if we maintain the members as two numbers in Smalltalk sense and let the mechanisms choose the representation (actually the classes), a lot of possible problems with Complex numbers not coalescing back to real due non canceling of imaginary parts (due rounding errors) could be minimized. This could make Pharo Smalltalk more interesting than using other languages where all the problems with numerical accuracy have to be taken in account. > > I simply wanted to illustrate you that passing values to code which > not expecting the Complex values having same side effect as passing a > Complex values to members of Complex value (real/imaginary) part, and > state that its ok. I'm sorry to inform you that until now you have not achieved your intent in showing me a robust case. . . > > That's why its is good to have separation from functions which > operating with reals only and can NEVER return anything else than real > values from functions which can return complex values. I maintain my opinion that this is not helpful to make Pharo (having an implementation like this) compelling for doing work with this kind of programming. For doing this way you rather do it in a spreadsheet application that has for any function a separate one for complex numbers: it works, but is cumbersome and makes code become bulkier. A strength of OO languages is polymorphism and Smalltalk adds to it dynamic typing. The separation you advocate make these advantages be lost. -- Cesar Rabak _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 16, 2009

Re: [Pharo-project] [update] 10414

by Marcus Denker

On 13.08.2009, at 16:26, Adrian Lienhard wrote: > update #10414 > ----------------- > 310+311: Reorganize unit tests in a more modular way such that they > can be unloaded > > Now all unit tests are in the packages "Tests", "CollectionsTests", > "KernelTests", "MorphicTests", etc. The key point of this > reorganization is to make these packages really modular, i.e., they > can be unloaded without leaving obsolete classes behind. I also made > sure that SUnit with its GUI is unloadable. > > If you execute in a Pharo-core image: > > ScriptLoader new cleanUpForProduction; cleanUpForRelease > > you get an image without tests and SUnit that is 8.0 MB on disk. > And after deleting the ScriptLoader class, it's only 6.9 MB. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Aug. 16, 2009

Re: [Pharo-project] Complex number support discussion

by csrabak＠bol.com.br

Em 15/08/2009 19:21, Igor Stasenko < siguctua(a)gmail.com > escreveu: > 2009/8/16 <csrabak(a)bol.com.br>: > > Your first example is interesting. It boils down to two design aspects: > > > > If you need Complex numbers in the same application, you need to refactor > > the code to: > > > > > length := (something positive) ifTrue:[something sqrt ] > > IfFalse: Error do: [ 5 ]. > > i'm sure you meant > length := (something positive) ifTrue:[something sqrt ] IfFalse: [ 5 ] I'm not so sure ;-) I thought your block with a five inside some kind of error message, but this is not that important. It seems you get the spirit and considering my mistake on interpreting your example your correction is OK. > > but then > #positive is a test which defined as > > positive > ^ self > 0 > > and we getting back to discussion , what is the meaning of #> or #< > operator for complex values. > NO!! Because all this discussion is being on the possibility of having an operation on a _non_ Complex number return a Complex result, so the test is kosher and you can go. _If_ you return an argument that something already was a complex number then all this argument is moot... [snipped] > > Once you put Complex in the Smalltalk paradigm, I think we should preserve > > as much as possible this design decision made at the start of the language. > > From a programming POV -4 sqrt mapping from Real to Imaginary (Complex) is > > homologous to 13 / 3 giving a Fraction. Overall is a modeling of the world. > > > > BTW, this is why I think having Complex to only have Float members is not a > > nice design decision... > > > ageed. Its can hold any values representing the value from a Real set. > But as soon as one of its member start holding someting different > (Complex) - you are in trouble. It depends. My reasoning was that if we maintain the members as two numbers in Smalltalk sense and let the mechanisms choose the representation (actually the classes), a lot of possible problems with Complex numbers not coalescing back to real due non canceling of imaginary parts (due rounding errors) could be minimized. This could make Pharo Smalltalk more interesting than using other languages where all the problems with numerical accuracy have to be taken in account. > > I simply wanted to illustrate you that passing values to code which > not expecting the Complex values > having same side effect as passing a Complex values to members of > Complex value (real/imaginary) part, and state that its ok. I'm sorry to inform you that until now you have not achieved your intent in showing me a robust case. . . > > That's why its is good to have separation from functions which > operating with reals only and can NEVER return anything else than real > values from functions which can return complex values. I maintain my opinion that this is not helpful to make Pharo (having an implementation like this) compelling for doing work with this kind of programming. For doing this way you rather do it in a spreadsheet application that has for any function a separate one for complex numbers: it works, but is cumbersome and makes code become bulkier. A strength of OO languages is polymorphism and Smalltalk adds to it dynamic typing. The separation you advocate make these advantages be lost. -- Cesar Rabak

Aug. 16, 2009

Re: [Pharo-project] Monitoring Transcript progress from UI Process

by Miguel Enrique CobÃ¡ Martinez

El sÃ¡b, 15-08-2009 a las 17:05 -0500, Chris Muller escribiÃ³: > Greetings, I am a Pharo newbie. What a nice image! > > One of the things I'd like to do is monitor the Magma test-suite while > it runs; Magma intercepts Notifications from its test suite code to > simply Transcript show: them by default. > > But the Transcript doesn't render them while the UI process is busy, > as the following demonstrates: > > "Screen doesn't update until entire script is complete.." > World findATranscript: nil. > 1 to: 100 do: [ : n | Transcript cr; show: n; endEntry ] > > I also tried a World doOneCycleNow but it blows up.. Doesn't seem > right anyway.. Check this: http://code.google.com/p/pharo/issues/detail?id=1053 > > Thanks, > Chris > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 15, 2009

Re: [Pharo-project] Complex number support discussion

by Igor Stasenko

2009/8/16 <csrabak(a)bol.com.br>: > Your first example is interesting.Â It boils down to two design aspects: > > If you need Complex numbers in the same application, you need to refactor > the code to: > > length := (something positive) ifTrue:[something sqrt ] IfFalse: Error do: [ > 5 ]. i'm sure you meant length := (something positive) ifTrue:[something sqrt ] IfFalse: [ 5 ] but then #positive is a test which defined as positive ^ self > 0 and we getting back to discussion , what is the meaning of #> or #< operator for complex values. > array := Array new: length. > > The application does not complex results at all and through the mechanism > Pharo team will decide upon this kind of support will be disabled. > > About the remaining of discussion, we need to remember all the time Pharo > [Smalltalk] is a programming environment that has come concrete in bits at > some time in order to become operative (from this onset I think the > abusedComplex should trow errors as adequate). > > The need for Fraction, Float and Integer in most programming languages > (Smalltalk included) is more often than not for the sake of efficiency or > simplification of the underlying code than for mathematical rigour. > > So as right as you are that 13/3 returning asFraction does not change the > "mathematical meaning of the value" in Smalltalk this is a correct > assertion, but in a lot of other environments it is not! They are different > representations of numbers that have to be treated as such. > > In a lot languages I'm versed on, writing 5e100 can only mean an 80 bit > float (in most HW) because it is the only way of storing such a beast.Â In > Smalltalk you ask for the class of this and getÂ LargePositiveInteger > (Pharo).Â In Smalltalk 5e100 is syntatic sugar for not having to write one > hundred zeros. > > So, when we decide in certain things in programming language you're making > decisions on how to model certain aspects of the problem domain. > > Smalltalk in the arithmetical part decide to postpone as much as possible > the loss of precision of the result. It is an expected behaviour in this > language. > > Once you put Complex in the Smalltalk paradigm, I think we should preserve > as much as possible this design decision made at the start of the language. > From a programming POV -4 sqrt mapping from Real to Imaginary (Complex) is > homologous to 13 / 3 giving a Fraction.Â Overall is a modeling of the world. > > BTW, this is why I think having Complex to only have Float members is not a > nice design decision... > ageed. Its can hold any values representing the value from a Real set. But as soon as one of its member start holding someting different (Complex) - you are in trouble. I simply wanted to illustrate you that passing values to code which not expecting the Complex values having same side effect as passing a Complex values to members of Complex value (real/imaginary) part, and state that its ok. That's why its is good to have separation from functions which operating with reals only and can NEVER return anything else than real values from functions which can return complex values. > > > > > Em 15/08/2009 18:27, Igor Stasenko < siguctua(a)gmail.com > escreveu: > > 2009/8/15 : >> I agree with your first paragraph! However I don't see logical fitting to >> example you gave on an Array of 0.2i. . . >> > because of that: > > length := [ something sqrt ] on: Error do: [ 5 ]. > array := Array new: length. > > which makes the code which worked before to be badly broken if you > change the sqrt behavior to not produce error, when you supply > negative value as receiver. > Even how ridiculous it may look, some people could deliberately > provide the 'wrong' values to functions, expecting them to fail and > then to be catched later & handled appropriately. It could serve as a > way to simplify the code or workaround. > >> Again Physics versus Banking, there is lot of physics that is done without >> need of complex numbers, and certainly in financial application I cannot >> foresee any need to have Complex loaded in an image (except if you need >> 'imaginary dollars' in some Ponzi scheme :-D ) >> > never heard about Ponzi scheme.. :) > >> About the principle of least surprise (a.k.a. principle of least >> astonishment) I thinking about the Smalltalk environment. >> >> In several programming languages 13 / 3 would return 4. In these languages >> this operation is on two integers and integer division gives you four. >> >> In [Pharo] Smalltalk the result is Fraction.Â We are used to this. >> >> So once we have Fraction in the image (OK, just as think experiment. . .), >> we can have this automatic promotion of the result.Â Same happens to the >> classic (aNumber factorial) example. >> > > I see where you want to draw a parallel, but this is not the case with > Complex. > Simply because Fraction is a different represe ntation of values from > the same set - Real (or rational) numbers, but its not adds new > dimensions and you are not jumping into a complex plane when using > fractions. > > You can potentially pass the Fraction into any function(method) which > expects a Real value. But you can't simply pass a Complex value to a > function with expects and designed to operate with a Real values, > because it would be theoretically/conceptually wrong. > > Just an example, where you can go conceptually wrong is to write something > like: > > abusedComplex := Complex real: (2i) imaginary: (5i). > > and then use given value in operations which expecting the complex > values and assuming that real & imaginary parts should not be complex > in own turn. > For the same reason i'm against implicit conversion to complex values > as a result of functions which is also defined for real values. > >> Now. Again in other languages sho uld a programmer want to be sure the >> result >> are less than a truncation she/he coud do: >> >> 13 / 3.0 or use some of the 'casting' mechanisms available to them. I see >> the asComplex need for operations where Complex has been alredy put in >> operation as similar to those casts. >> > You don't need casting with fractions because you don't change the > mathematical meaning of the value. But complex values changing it. > >> Hope it is explicit now. >> > > I hope i clarified my position too :) > >> Em 15/08/2009 17:36, Igor Stasenko < siguctua(a)gmail.com > escreveu: >> >> 2009/8/15 : >>> Igor, >>> >>> I think I don't undersand your point. What is the mathematical >>> significance >>> of an Array of size 0.2i? >>> >> the significance is not mathematical, it is practical: how many hours >> one should s pend fixing all 'surprises' which >> you can introduce if not carefully add Complex support. >> >> Let me remind you that Physics is not the only area where is >> mathematcal apparatus is used. >> In banking, people using a completely different mathematical >> apparatus, and i doubt that they using complex values to calculate >> sums on client's accounts. But i don't have any doubts that such >> applications require very stable and predictable math functions which >> operating mainly over real numbers. >> >>> Em 15/08/2009 14:35, Igor Stasenko < siguctua(a)gmail.com > escreveu: >> & gt; >>> 2009/8/15 : >>>> It helps to undestand your suggestion. >>>> >>>> It does not help to make it Smalltalk friendly, my meaning of that being >>>> the >>>> "principle of least surprise". >>>> >>> least suprise for who? >>> For you it could be the least surprise. >>> For me, and for other people it would be a big surprise. >>> So, please give a better/different reasoning, why in a presence of >>> Complex numbers, a functions >>> which operating with Real numbers should change their behavior. >>> >>> Integers are subset of Real set and Real is a subset of Complex, then >>> one could happily write: >>> >>> Array new: 0.2i >>> >>> and following your reasoning, the above is good way to write a code >>> and it should work well. >>> >>>> If complex math is to be allowed a natural consequence is that a lot of >>>> ; functions would retur n complex answers for real arguments. >>>> >>>> How would then have Pharo Smalltalk behave in a case of computing a >>>> reactance: X = jÏL? >>>> >>>> anInductance being Number and complexFrequency obviously being Complex: >>>> >>>> aReactance := anInductance * complexFrequency >>>> >>>> Em 15/08/2009 13:55, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > >>>> escreveu: >>>> >>>> Nothing tricky: just that methods answering complex results should be >>>> defined only by things tha are already complex.Â -1 sqrt blows up; -1 >>>> asComplex answers i.Â There would be no imlicit conversion between real >>>> and >>>> complex, allowing the base system to perform as it does now and still >>>> allowing all the complex number crunching anyone wants to do. Does that >>>> help? >>>> Bill >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Phar o-pr oject(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. >> >> _______________________________________________ >> Pharo-project mailing list >> P har o-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.

Aug. 15, 2009