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

Re: [Pharo-dev] handling method/classes updartes

by stepharo

What you should realize is that when we introduce the SystemAnnouncer ancestor with Roel Wuyts, there way no such a thing: a system that to whim you register and notify about changes. So in VW you had to go and find all the places and patch them to get you notified. So to me this is a huge enhancements to support the creation of great tool. Now working with a real system is complex because a class can recategorized, a method rename, recatogorized, removed.... and there is magical solution - at least that I know Stef On 10/7/14 19:38, Yuriy Tymchuk wrote: > Hi, > > is there a way to subscribe directly to a method/class, so I san know when it updates/is removed and so on? Because it looks like a pain to subscribe to system announcer and check if the method changed is the one I need. > > Uko > >

July 13, 2014

Nautilus - Recover Lost Changes - Class Comments

by Ben Coman

I had SomeClassA that did not have a class comment, and so an alert icon showed for it in Nautilus. Then I used Recover-Lost-Changes which added a class comment for SomeClassA, but the icon did not update. I understood that Pharo 4 will be modifying how the ".changes" file works. Will this include modifying the mechanism of Recover-Lost-Changes mechanism? Hence, should create a Case for this for Pharo 4, or just for Pharo 3 ? cheers -ben

July 13, 2014

Re: [Pharo-dev] Doc of mustache

by stepharo

Thanks Thanks Thanks. I want to check Marina too. >> And I'm reading pillar code because I would like to see how I can use a API >> to generate XHTML and take into account mustache > > pillarString := '! Some text > > -item1 > -item2'. > > pillarDocument := PRDocumentParser parse: pillarString. > > htmlString := PRHTMLWriter write: pillarDocument . > > > 'main.template.html' asFileReference mustacheTemplateDuring: [ :template| > > 'result.html' asFileReference writeStreamDo: [ :outStream | > > outStream nextPutAll: (template value: { 'contents' -> htmlString > } asDictionary) > > ] > > ] >

July 13, 2014

Design trends in UI for Mobiles

by GOUBIER Thierry

Food for thought for those working on theming for Pharo: http://arstechnica.com/gadgets/2014/07/the-software-design-trends-that-we-l… Flat buttons for a new kind of game... Finding out what is clickable in a GUI :) Thierry

July 13, 2014

Re: [Pharo-dev] Doc of mustache

by Damien Cassou

On Fri, Jul 11, 2014 at 10:55 AM, stepharo <stepharo(a)free.fr> wrote: > And I'm reading pillar code because I would like to see how I can use a API > to generate XHTML and take into account mustache pillarString := '! Some text -item1 -item2'. pillarDocument := PRDocumentParser parse: pillarString. htmlString := PRHTMLWriter write: pillarDocument . 'main.template.html' asFileReference mustacheTemplateDuring: [ :template| 'result.html' asFileReference writeStreamDo: [ :outStream | outStream nextPutAll: (template value: { 'contents' -> htmlString } asDictionary) ] ] -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 13, 2014

Re: [Pharo-dev] [Article] Elegant Pharo Code

by Sergi Reyner

It may have been mentioned already, but number 7 is wrong, is states: "7. Sum of the first 64 primes" when it actually is: "7. Sum of the primes not larger than 64" Cheers, Sergi 2014-07-12 17:02 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 08 Jul 2014, at 21:53, kilon alios <kilon.alios(a)gmail.com> wrote: > > > Ruby and Pearl look very ugly to me. > > > > Programming languages are primarily personal preference. > > > > Pharo advantages to me at least are far more than live image, its live > coding which by the way is different from live image, the IDE tools, the > factor that is all Pharo objects even when you do assembly coding inside > Pharo , the libraries of course and last but not least the community. > > > > I could name also thousands more advantages that I have found in the > implementation that I really like as well others I don't. Devil , as they > say, is in the details. Details are everything , generalisations have > little meaning. > > > > Lovely article Sven , keep them coming. I think Pharo would definitely > benefit from a cookbook working as a database where pharo coders can use to > find example code the easy way. > > Thanks, Kilon. > > > But even articles like this can help a lot, I just wish that there was a > Pharo wiki to keep these links and see them buried in Pharo news. > > Yes, I think we need more/better places to link everything together. A > curated reading list maybe. > > > PS: Sven I am making my own Pharo book called Pharo Universe where I > want to put things that are not part of PBE or PFTE which can be find here > https://github.com/kilon/Pharo-Universe and here > https://ci.inria.fr/pharo-contribution/job/PharoUniverse/ . May I have > permission to use your articles as chapters for my book ? I will fully > credit you and link back to your blog posts of course :) > > I know you are doing a lot of effort with respect to documentation and > that is really great and important. I am not sure that copying articles > that were not meant to be part of a book or larger whole is a good > solution, for either party, it will give too much repetition and not a lot > of coherence. > > > On Tue, Jul 8, 2014 at 10:33 PM, Paul Davidowitz <pdavidow(a)fastmail.fm> > wrote: > > Very nice, except all this could be done in Ruby, also elegantly. > > The Smalltalk advantage is the live image, and that's where the focus > > should be. > > > > > > >

July 13, 2014

Re: [Pharo-dev] Handling side-scrolls

by Yuriy Tymchuk

Thank you Stef. Iâll take a look. Uko On 10 Jul 2014, at 21:21, stepharo <stepharo(a)free.fr> wrote: > This is not that we do not care. This is that we are busy. If you want to make some step in that direction > try to OSWindow bug tracker issue and see if it is working for you. > Because probably that the solution will be using OSWindow > > Stef > >> Dear Pharo developers, >> >> can we deal somehow with this issue: https://pharo.fogbugz.com/f/cases/5296/Fast-Scroll-Down-produces-weird-even… ? >> >> Or at least please tell me if someone needs this functionality. Maybe we can just ignore that? >> >> Uko >> >> > >

July 13, 2014

Re: [Pharo-dev] Division isn't correct

by Nicolas Cellier

2014-07-12 17:00 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > > 2014-07-12 13:42 GMT+02:00 Andres Valloud < > avalloud(a)smalltalk.comcastbiz.net>: > > Being consistent then means either abandonning 1/2 = 0.5 but we saw this >>> has nasty side effects. >>> >> >> Well ok, so letting 1 / 2 = 0.5 answer false has nasty side effects. Why >> is that? Isn't the code that breaks trying to tell us something? That's >> what I've been trying to point out. Why rush to defend numerically >> unstable code? What are we going to preserve, and what will be the example >> given to others? >> >> Andres. >> >> > What apparently breaks Pharo graphics is letting (1 comparisonOp: 1.0) = > false in Float>>adaptToInteger:andCompare: > (maybe my mistake, I should ^ operator = #~= rather than ^false) > At this point, we can't tell that the code is numerically unstable. > Maybe the Float are very well formed and sufficiently away from int, or > exactly equal to int... > Only if we see off-by-one errors can we conclude that there are design > mistakes. > Or if we perform a deeper analysis, but it ain't going to be easy. > To know where it happens, we would have to instrument code (no static > typing). > > It's not un-interesting. > But it's going to waste a lot of time for a problem we don't yet have... > > So I gave a try to instrumentation with one of my dirtiest hack: 1) define a new Notification subclass: #IntegerFloatComparison 2) raise this signal in Float>>adaptToInteger:andCompare: IntegerFloatComparison signal ...snip... 3) catch the senders using the message tally: tally := MessageTally new. tally spyEvery: 100 on: ['em ezilaitini ot si siht' reverse]. tally class: World class method: World class>>#doOneCycle. tallyEnd := false. [(Delay forSeconds: 300) wait. tallyEnd := true] fork. [[World doOneCycle. Processor yield.tallyEnd] whileFalse] on: IntegerFloatComparison do: [:exc | tally tally: exc signalerContext by: 1. exc resume]. (StringHolder new contents: (String streamContents: [:s | tally report: s])) openLabel: 'EndOfStream Spy Results'. 4) do your favourite activity... After 5 minutes of typical browsing/workspace activity, > 100 000 sends in Morph, TableLayout, bounds etc... But are the Float possibly ill-formed? I modified the signaller: (self fractionPart = 0) ifFalse: [IntegerFloatComparison signal]. Hmm 0 tallies this time. So I don't know where exactly Float are required (some primitive do not accept Fraction I think this is the main reason why some asFloat have been spreaded...). But these are innocuous Float. No numerical unstable code detected by this cheap exercize.

July 12, 2014

Re: [Pharo-dev] [Article] Elegant Pharo Code

by Sven Van Caekenberghe

On 08 Jul 2014, at 21:53, kilon alios <kilon.alios(a)gmail.com> wrote: > Ruby and Pearl look very ugly to me. > > Programming languages are primarily personal preference. > > Pharo advantages to me at least are far more than live image, its live coding which by the way is different from live image, the IDE tools, the factor that is all Pharo objects even when you do assembly coding inside Pharo , the libraries of course and last but not least the community. > > I could name also thousands more advantages that I have found in the implementation that I really like as well others I don't. Devil , as they say, is in the details. Details are everything , generalisations have little meaning. > > Lovely article Sven , keep them coming. I think Pharo would definitely benefit from a cookbook working as a database where pharo coders can use to find example code the easy way. Thanks, Kilon. > But even articles like this can help a lot, I just wish that there was a Pharo wiki to keep these links and see them buried in Pharo news. Yes, I think we need more/better places to link everything together. A curated reading list maybe. > PS: Sven I am making my own Pharo book called Pharo Universe where I want to put things that are not part of PBE or PFTE which can be find here https://github.com/kilon/Pharo-Universe and here https://ci.inria.fr/pharo-contribution/job/PharoUniverse/ . May I have permission to use your articles as chapters for my book ? I will fully credit you and link back to your blog posts of course :) I know you are doing a lot of effort with respect to documentation and that is really great and important. I am not sure that copying articles that were not meant to be part of a book or larger whole is a good solution, for either party, it will give too much repetition and not a lot of coherence. > On Tue, Jul 8, 2014 at 10:33 PM, Paul Davidowitz <pdavidow(a)fastmail.fm> wrote: > Very nice, except all this could be done in Ruby, also elegantly. > The Smalltalk advantage is the live image, and that's where the focus > should be. > >

July 12, 2014

Re: [Pharo-dev] Division isn't correct

by Nicolas Cellier

2014-07-12 13:42 GMT+02:00 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net >: > Being consistent then means either abandonning 1/2 = 0.5 but we saw this >> has nasty side effects. >> > > Well ok, so letting 1 / 2 = 0.5 answer false has nasty side effects. Why > is that? Isn't the code that breaks trying to tell us something? That's > what I've been trying to point out. Why rush to defend numerically > unstable code? What are we going to preserve, and what will be the example > given to others? > > Andres. > > What apparently breaks Pharo graphics is letting (1 comparisonOp: 1.0) = false in Float>>adaptToInteger:andCompare: (maybe my mistake, I should ^ operator = #~= rather than ^false) At this point, we can't tell that the code is numerically unstable. Maybe the Float are very well formed and sufficiently away from int, or exactly equal to int... Only if we see off-by-one errors can we conclude that there are design mistakes. Or if we perform a deeper analysis, but it ain't going to be easy. To know where it happens, we would have to instrument code (no static typing). It's not un-interesting. But it's going to waste a lot of time for a problem we don't yet have... > Or denying the generality of Dictionary: not all objects can be used as >> key... >> That's a possible choice, but IMO, this will generate bad feedback from >> customers. >> Speaking of consistency, I strongly believe that Squeak/Pharo are on the >> right track. >> >> OK, we can not magically erase inexactness of floating point operations. >> They are on purpose for the sake of speed/memory footprint optimization. >> Exceptional values like NaN and Inf are a great deal of >> complexification, and I'd allways preferred exceptions to exceptional >> values... >> But when we can preserve some invariants, we'd better preserve them. >> Once again, I did not invent anything, that's the approach of lispers, >> and it seems wise. >> >> And last thing, I like your argumentation, it's very logical, so if you >> have more, you're welcome >> but I pretty much exhausted mine ;) >> >> Nicolas >> >> >> If we can maintain the invariant with a pair of double dispatching >> methods and coordinated hash, why shouldn't we? >> Why lispers did it? (Scheme too) >> >> For me it's like saying: "since float are inexact, we have a >> license to >> waste ulp". >> We have not. IEEE 754 model insists on operations to be exactly >> rounded. >> These are painful contortions too, but most useful! >> Extending the contortion to exact comparison sounds a natural >> extension >> to me, the main difference is that we do not round true or false >> to the >> nearest float, so it's even nicer! >> >> >> On 7/11/14 17:19 , Nicolas Cellier wrote: >> >> >> >> >> 2014-07-12 1:29 GMT+02:00 Andres Valloud >> <avalloud(a)smalltalk.__comcastb__iz.net >> <http://comcastbiz.net> >> <mailto:avalloud@smalltalk.__comcastbiz.net >> <mailto:avalloud@smalltalk.comcastbiz.net>> >> <mailto:avalloud@smalltalk. >> <mailto:avalloud@smalltalk.>__c__omcastbiz.net >> <http://comcastbiz.net> >> >> >> <mailto:avalloud@smalltalk.__comcastbiz.net >> <mailto:avalloud@smalltalk.comcastbiz.net>>>>: >> >> >> I don't think it makes sense to compare >> floating point >> numbers to >> other types of numbers with #=... there's >> a world of >> approximations >> and other factors hiding behind #=, and the >> occasional true >> answer >> confuses more than it helps. On top of >> that, then >> you get >> x = y => >> x hash = y hash, and so the hash of >> floating point >> values >> "has" to >> be synchronized with integers, fractions, >> scaled >> decimals, >> etc... >> _what a mess_... >> >> >> Yes, that's true, hash gets more complex. >> But then, this has been discussed before: >> >> {1/2 < 0.5. 1/2 = 0.5. 1/2 > 0.5} - > #(false >> false false). >> >> IOW, they are unordered. >> Are we ready to lose ordering of numbers? >> Practically, this would have big impacts on >> code base. >> >> >> IME, that's because loose code appears to work. >> What >> enables that >> loose code to work is the loose mixed mode >> arithmetic. I could >> understand integers and fractions. Adding >> floating point >> to the mix >> stops making as much sense to me. >> >> Equality between floating point numbers does make >> sense. >> Equality >> between floating point numbers and scaled decimals >> or >> fractions... >> in general, I don't see how they could make sense. >> I'd >> rather see >> the scaled decimals and fractions explicitly >> converted to >> floating >> point numbers, following a well defined procedure, >> and then >> compared... >> >> Andres. >> >> >> Why do such mixed arithmetic comparisons make sense? >> Maybe we used floating points in some low level >> Graphics for >> optimization reasons. >> After these optimized operations we get a Float result by >> contagion, but >> our intention is still to handle Numbers. >> It would be possible to riddle the code with explicit >> asFloat/asFraction >> conversions, but that does not feel like a superior >> solution... >> >> OK, we can as well convert to inexact first before >> comparing for >> this >> purpose. >> That's what C does, because C is too low level to ever >> care of >> transitivity and equivalence relationship. >> It's not even safe in C because the compiler can decide >> to >> promote to a >> larger precision behind your back... >> But let's ignore this "feature" and see what lispers >> recommend >> instead: >> >> http://www.lispworks.com/____documentation/lcl50/aug/aug-__ >> __170.html >> <http://www.lispworks.com/__documentation/lcl50/aug/aug-__ >> 170.html> >> >> <http://www.lispworks.com/__documentation/lcl50/aug/aug-__ >> 170.html >> <http://www.lispworks.com/documentation/lcl50/aug/aug-170.html>> >> >> >> It says: >> >> In general, when an operation involves both a rational >> and a >> floating-point argument, the rational number is first >> converted to >> floating-point format, and then the operation is >> performed. This >> conversion process is called /floating-point contagion/ >> >> <http://www.lispworks.com/____reference/lcl50/aug/aug-193.__ >> __html#MARKER-9-47 >> <http://www.lispworks.com/__reference/lcl50/aug/aug-193.__ >> html#MARKER-9-47> >> >> >> >> <http://www.lispworks.com/__reference/lcl50/aug/aug-193.__ >> html#MARKER-9-47 >> <http://www.lispworks.com/reference/lcl50/aug/aug-193. >> html#MARKER-9-47>>>. >> >> However, for numerical equality comparisons, the >> arguments are >> compared >> using rational arithmetic to ensure transitivity of the >> equality (or >> inequality) relation. >> >> So my POV is not very new, it's an old thing. >> It's also a well defined procedure, and somehow better >> to my taste >> because it preserve more mathematical properties. >> If Smalltalk wants to be a better Lisp, maybe it should >> not >> constantly >> ignore Lisp wisdom ;) >> >> We can of course argue about the utility of >> transitivity... >> As a general library we provide tools like Dictionary >> that rely on >> transitivity. >> You can't tell how those Dictionary will be used in real >> applications, >> so my rule of thumb is the principle of least >> astonishment. >> I've got bitten once by such transitivity while >> memoizing... I >> switched >> to a better strategy with double indirection as >> workaround: class -> >> value -> result, but it was surprising. >> >> >> I'm pretty sure a Squeak/Pharo image wouldn't >> survive >> that long >> to such >> a change >> (well I tried it, the Pharo3.0 image survives, >> but >> Graphics are >> badly >> broken as I expected). >> >> That's allways what made me favour casual >> equality to >> universal >> inequality. >> >> Also should 0.1 = 0.1 ? In case those two >> floats have been >> produced by >> different path, different approximations they >> might not >> be equal... >> (| a b | a := 0.1. b := 1.0e-20. a+b=a.) >> I also prefer casual equality there too. >> Those two mathematical expressions a+b and a are >> different but both >> floating point expressions share same floating >> point >> approximation, >> that's all what really counts because in the >> end, we cannot >> distinguish >> an exact from an inexact Float, nor two >> inexact Float. >> We lost the history... >> >> Also, the inexact flag is not attached to a >> Float, it's >> only the >> result >> of an operation. >> Statistically, it would waste one bit for >> nothing, most >> floats >> are the >> result of an inexact operation. >> But who knows, both might be the result of exact >> operations too ;) >> >> >> >> On 7/11/14 10:46 , stepharo wrote: >> >> I suggest you to read the Small >> number chapter >> of the >> Deep into >> Pharo. >> >> Stef >> >> On 11/7/14 15:53, Natalia Tymchuk >> wrote: >> >> Hello. >> I found interesting thing: >> Why it is like this? >> >> Best regards, >> Natalia >> >> >> >> >> >> >> >> >> >> >> >

July 12, 2014