- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 4013 in pharo: DNU ObjectExlorer with taskbar enabled

by pharo＠googlecode.com

Updates: Status: Closed Labels: Milestone-1.3 Comment #1 on issue 4013 by marcus.d...(a)gmail.com: DNU ObjectExlorer with taskbar enabled http://code.google.com/p/pharo/issues/detail?id=4013 in 13149

April 14, 2011

Re: [Pharo-project] Issue 4007 in pharo: Taskbar disappeared

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 4007 by marcus.d...(a)gmail.com: Taskbar disappeared http://code.google.com/p/pharo/issues/detail?id=4007 in 13149

April 14, 2011

Re: [Pharo-project] Issue 4006 in pharo: Some UI improvement

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 4006 by marcus.d...(a)gmail.com: Some UI improvement http://code.google.com/p/pharo/issues/detail?id=4006 in 13149

April 14, 2011

[Pharo-project] [update 1.3] #13149

by Marcus Denker

13149 ----- Issue 3986: Bug with Delay during clock rollover Issue 4012: Explore It crashes when selected using mouse Issue 4010: References to it nor working in Inspector Issue 4008: DNU on opening inspector with enabled taskbar Issue 4006: Some UI improvement Issue 4007: Taskbar disappeared Issue 4013: DNU ObjectExlorer with taskbar enabled -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 14, 2011

Re: [Pharo-project] Issue 4008 in pharo: DNU on opening inspector with enabled taskbar

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 4008 by marcus.d...(a)gmail.com: DNU on opening inspector with enabled taskbar http://code.google.com/p/pharo/issues/detail?id=4008 in 13149

April 14, 2011

Re: [Pharo-project] Issue 4010 in pharo: References to it nor working in Inspector

by pharo＠googlecode.com

Comment #3 on issue 4010 by marcus.d...(a)gmail.com: References to it nor working in Inspector http://code.google.com/p/pharo/issues/detail?id=4010 in 13149

April 14, 2011

Re: [Pharo-project] Issue 4010 in pharo: References to it nor working in Inspector

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 4010 by marcus.d...(a)gmail.com: References to it nor working in Inspector http://code.google.com/p/pharo/issues/detail?id=4010 in 13149

April 14, 2011

Re: [Pharo-project] About float: new chapter looking for reader and contributors

by Nicolas Cellier

I created a git account last night but must install latex on my mac. I don't have your rythm :) Nicolas 2011/4/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Nicolas > > why don't you grab the latex file and edit it? > because I do not know anything about float. > > Stef > > > > > > On Apr 13, 2011, at 10:37 PM, Nicolas Cellier wrote: > >> Here is a small variation. It's not perfect, and most elements are >> already in Stephane's text. >> But maybe we can jump deeper in the first example that claims some explanations. >> >> We can first explain that 0.1 will answer the Float nearest to (1/10). >> Thanks to this important property, if we enter 0.1, it will be printed >> 0.1 and reinterpreted the same. A nice property to have! >> >> However, what is fundamental is that this Float won't be equal to (1/10). >> How is this so ? Hey we didn't learn that in school ! >> Well, Float have an internal representation in base 2, of the form >> mantissa * (2 raisedTo: exponent). >> There is no way to represent (1/10) in base 2 with a finite number of >> bits... Â (like illustrated with 1.3 example, #significandAsInteger, >> #exponent, #ulp and such kind of messages...). >> A rounding operation has to occur to make this number fit in Float >> internal representation ( it might be good to tell that Pharo Float >> follow the IEEE 754 double precision standard with a link to >> http://en.wikipedia.org/wiki/IEEE_754-1985 . This standard governs the >> way most FPU work on this planet). >> This rounding operation introduce a rounding error, and thus we don't >> get exactly (1/10). >> >> To know the exact internal representation of 0.1 the Smalltalk way is >> as usual to send a message: 0.1 asTrueFraction. >> The same goes with 0.2, it's not equal to (2/10), check it with 0.2 >> asTrueFraction. >> >> So what goes on with this operation 0.1+0.2 ? >> In fact you asked the system to perform following operation (0.1 >> asTrueFraction+0.2 asTrueFraction) asFloat. >> (0.1 asTrueFraction+0.2 asTrueFraction) is an exact operation, but the >> result again does not fit in Float internal representation: >> (0.1 asTrueFraction+0.2 asTrueFraction) numerator highBit -> 54 >> (0.1 asTrueFraction+0.2 asTrueFraction) numerator lowBit -> 1 >> This means that 54 bits of mantissa are required to represent this >> number. Float only have 53 >> Float precision -> 53 >> So converting it to aFloat requires another rounding operation, and >> due to this rounding error, >> (0.1 asTrueFraction+0.2 asTrueFraction) ~= (0.1 asTrueFraction+0.2 >> asTrueFraction) asFloat. >> That's exactly how your IEEE-754 compliant FPU will work. >> >> In the whole process, 3 rounding errors have been cumulated: >> (1/10) asFloat -> 0.1 (the error is not yet visible, but it's here already) >> (2/10) asFloat -> 0.2 (same) >> (0.1 asTrueFraction+0.2 asTrueFraction) asFloat -> 0.30000000000000004 >> >> This is to be compared to 0.3, which has a single rounding error: >> (3/10) asFloat -> 0.3 >> >> Due to these rounding errors, and the way they cumulate or annihilate, >> both result might differ. And in this case, they differ. >> This is a very important property of Float. Float are fast thanks to >> hardware acceleration, and thanks to these rounding errors that keep >> the number of significant bits from growing. But the counterpart is >> that operations on Float are inexact. Due to this inexactness, it is >> most often inadequate to rely on strict equality of Float, as this >> very simple example illustrates. Instead, Float comparisons shall >> better be tested with fuzzy tolerance. >> >> Note that the nice thing with Pharo is that you immediately see that >> (0.1+0.2) ~= 0.3 thanks to extraneous digits printed. >> Pharo does not hide the horrible truth by shortening the printed >> representation to 0.3 like some system do. >> However, the decimal printed form does not show you the truth about >> 0.1 ~= (1/10). Inexactness is hidden. This is an implicit knowledge to >> remember about Float, that you now learned with this lesson. >> >> Remember, this is not a deficiency of Pharo. This is the way Float are >> expected to work whatever the language. >> >> Nicolas >> >> 2011/4/13 laurent laffont <laurent.laffont(a)gmail.com>: >>> >>> >>> >>> On Tue, Apr 12, 2011 at 6:07 PM, stephane ducasse <stephane.ducasse(a)free.fr> >>> wrote: >>>> >>>> Hi guys >>>> >>>> I started to put in shape a chapter on floats based on the numerous >>>> discussions we got over the years. >>>> You can find it on github under the pharo by example book/Floats >>> >>> >>> For me it's a good candidate for a ProfStef tutorial (text, evaluations, >>> text, ...) >>> Laurent >>> >>>> >>>> Stef >>>> >>> >>> >> > > >

April 14, 2011

Re: [Pharo-project] Issue 4012 in pharo: Explore It crashes when selected using mouse

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 4012 by marcus.d...(a)gmail.com: Explore It crashes when selected using mouse http://code.google.com/p/pharo/issues/detail?id=4012 in 12149

April 14, 2011

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

by Nicolas Cellier

We didn't say that creating classes is bad by nature, we spoke only about compromise... If you have a hierarchy of 1000+ class, then it makes the hierarchy browser useless because we are flooded by unclassified information flow. It's fine grained mud, but from this POV it's still mud. It just means we can't use it for finding information. You might translate this saying "cherchez une aiguille dans une botte de foin". The IDE still follows this late 70s classification : category/class/protocol/method. This was tailored for a much smaller namespace. The only enhancement we made was to add another level like this: category-subcategory/class/protocol/method We managed a x10 inflation in the namespace with such extension... If we are to increase again our Dictionary, then we can't avoid a reflexion on classification. What you are proposing is to concentrate all Exception classification in two levels: category/class Dale proposed a three level category/class/method Nicolas 2011/4/14 Toon Verwaest <toon.verwaest(a)gmail.com>: > Somehow I feel like I offended someone :) > > I personally don't have experience with 10'000+ classes in a system. I do > understand that's where you are coming from and do appreciate the insight. > > My personal experience has rather been the opposite until now. For example > the Pharo/Squeak classbuilder is 1 single class doing everything. This is > horrible; not just horrible because the code is completely horrid but it's > non-extensible, non-configurable, non-reusable, contains tons of duplication > _just because_ it is all put into one big ball of mud. By decomposing the > classbuilder into 4 to 10 different classes I ended up having very little > methods with very little code, and a very high level of configurability and > understandability. I now actually use this classbuilder to build anonymous > classes too, avoiding the whole problem with forgetting to copy in the > format that everyone seems to have. > > And this experience was showing me that having classes for all _relevant_ > concepts actually pays off in the long run. Since you (and others) are > saying that it doesn't for exceptions; and since I don't have enough > experience there I'll take your advice into account when writing code ;) > > Toon > > On 04/14/2011 01:00 AM, Dale Henrichs wrote: >> >> On 04/13/2011 02:58 PM, Toon Verwaest wrote: >>> >>> Is it such a problem if you duplicate a certain exception class? At the >>> moment you'll do the same anyway by not completely writing the exact >>> same symbol. >> >> It's a simple matter of namespaces and volume of names ... with a large >> open ended namespace you are more likely to have a number of redundant names >> with slight differences in spelling showing up in different spots in the >> hierarchy...with a logically segmented namespace each segment will have a >> manageable number of names and the risk of duplication is reduced ... end of >> discussion ... >> >> 10,000 names vs 30 names ... I can easily recognize duplicates in a list >> of 30 names ... not so easy in 10,000 ... that is all ... >> >> to attempt to map every possible error condition onto a class will lead >> you to 10,000 much quicker than using reasonCodes ... that is all ... >> >> I don't hate classes, it is a _practical_ matter ... if _you_ would rather >> manage 10,000 names then I will say that it isn't practical ... I'm _not_ >> saying it is _wrong_, just not _practical_. >> >>> >>> And if the problem is not finding classes anymore, maybe we need a >>> better way of organizing the exception classes away from the standard >>> classes so that they are as non-intrusive as symbols, but convey more >>> information? >> >> And now you've hit the nail on the head ... in order to handle the extra >> complexity you need additional tools ... before creating more tools, ask >> your self the simple question: "Do I _need_ the additional complexity?" ... >> if the answer is yes, then create the tool, if the answer is no, then you >> don't need to create a new tool .. >> >> Again, this is a _practical_ matter... >> >>> >>> self error: #keyNotFound >>> does not really give much information; and isn't much more difficult to >>> write than: >>> KeyNotFoundException new in: self; key: key; signal >> >> From a practical perspective how many exception handlers will be written >> to handle KeyNotFoundException ... I use at:ifAbsent: when I'm doing a look >> up that I think might fail ... better than writing an exception handler ... >> >> If there is a real need to write a handler for KeyNotFoundException, then >> by all means create the class, but until you actually NEED >> KeyNotFoundException, `self error: #keyNotFound` or `NotFoundException >> signal: #keyNotFound` will work just fine... >>> >>> although the second one gives you all the contextual information that >>> the first one misses. >> >> _If_ you NEED the additional contextual information. It's just like >> writing a framework that no uses ... there's nothing wrong with the idea or >> the implementation, it's just that the framework didn't solve a problem that >> anyone had... >> >> If you are going to create a class, I think the least it should do is >> address an real problem, not an imaginary one. >> >> To say that "if one were to handle the KeyNotFoundException, they will >> need the complete context", I prefer to say "Until one needs the complete >> context of the KeyNotFoundException, don't bother creating class" >> >>> >>> What I mean mostly: what about trying to figure out why you want to >>> avoid decent exception classes and tackling that problem? >> >> Depends upon what your definition of a decent exception classes is? My >> argument is simply that it is not _necessary_ to create a unique class for >> every unique error condition ... I think that folks should answer the >> question: "Will anyone every write an exception handler for this exception" >> before creating the class ... if the answer is yes (or better yet, I am >> writing code right now and need that exception) then by all means create the >> class. >> >>> Maybe we don't want classes but exception objects that can pool data >>> together? Maybe a very silly idea: what about just exception "classes" >>> that have dictionaries to store enough information? >> >> That would be another way of doing things ... although using exception >> classes and reasonCodes is pretty close to all that is needed... >> >> I agree with the notion that it isn't that useful to have a single Error >> class and have all errors mapped to it ... on the other hand I don't think >> it is particularly useful to have an exception class for every possible >> error condition ... the compromise is to provide a smallish hierarchy of >> excpetion classes with fairly general structure, provide a means for >> uniquely identifying every possible error condition (I think that is >> important) and then add new classes to the hierarchy when a demand for the >> class is found ... >> >> > > >

April 14, 2011