January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Finalization quirk

by John M McIntosh

Bill, I always tell people (a) finalization will occur later, not when you think it should (b) finalization will occur slower/faster than you think. (c) both (a) & (b) will vary You're violating (a) There is mention of doing a full GC will force the finalization, but I can't recall if that finalizes (all) objects in old oops space in one pass with squeak. Various Smalltalk flavours and versions do things differently, some at different times & versions perhaps would only finalize one oops per pass (visualage). On 2010-01-06, at 10:12 AM, Schwab,Wilhelm K wrote: > I am trying to add finalization to something and appear to be at a point that finalization does not happen until I open the process browser. Any ideas? > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 6, 2010

Re: [Pharo-project] akuhn/SUnit: run faster tests first & step through tests

by StÃ©phane Ducasse

in 11138 I got ifUnknownAuthorUse: DNU run | result | result := TestResult new. self on: TestFinished send: #add: to: result. Author ifUnknownAuthorUse: 'TestRunner' during: [TestResource tearDownAll: self resources while: [ self run: self ]]. self unsubscribe: result. ^ result As soon as you fix it I try to run all the test of 11138

Jan. 6, 2010

Re: [Pharo-project] akuhn/SUnit: run faster tests first & step through tests

by StÃ©phane Ducasse

Adrian this sounds really great! I have to check it :) I like the idea that we builder can do a better job at building tools to empower ourselves. Now it is compatible with SUnit ifTrue: [ dear community can you test it and we integrate it :)] > Hi Pharo list, > > The lastest akuhn/SUnit runs fasters tests first. When running your test suite > for the second time, faster tests are run first. For the whole 9000 tests in > the dev image, this means that the first 8000 tests are run in like 10 > milliseconds. cool! I will test it. My problem is that I run tests always in core > Also I fixed the menues in the test runner, you can now mark either all or > single tests are expected defect. If you mark expected defects through the UI > they are stored on the class side. The #expectedFailures method on the > instance side is still taken into account for compatibility, but storing > expected defects on the class side is the preferred way to do it now. > > I also cleared up the vocabulary. There are no more history on the class side, > rather there are two histories one called "last run" and one called "expected > defects" that both serve different purposes. The "last run" history is used to > mark test results in the browser. The "expected defects" history is used to > keep track of expected / unexpected defects. (As far I know, the icons in O2 > show this as well.) > > Plus I added the ability to step through a failed tests. This stops right > before the actual test method, rather than at the failed assertion. To step > through a failed test, run your tests with the test runner and use the menu > of test failures or errors. (OB and O2 might consider adding this option as > well. In particular in combination with running fasters tests first a "run > and debug/step-through first failure" might be interesting.) > > To load akuhn/SUnit gofer > > SystemChangeNotifier uniqueInstance > noMoreNotificationsFor: TestCase. > Gofer it > disablePackageCache; > squeaksource: 'akuhn'; > package: 'SUnit'; > package: 'SUnitGUI'; > load. > > Thank you all for the awesome feedback last time! > More is welcome :) > > --AA > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 6, 2010

Re: [Pharo-project] Fwd: traits :)

by StÃ©phane Ducasse

Knowing nathanael it should be quite cool. Too bad google got him.... This is why I would love to have a traits based collection library :) > Very nice post! > > Alexandre > > > On 5 Jan 2010, at 15:23, StÃ©phane Ducasse wrote: > >> >> >> >> Some emails about traits from their father @ google :) >> >>> Hi Stef >>> >>> Sorry for the late reply. I'm just going through my email after the >>> Christmas break... >>> >>>> Could someone please come up with ONE example where MI (traits in >>> particular) solve an *actual* problem and not just some academic BS? >>> >>> I have encountered a bunch of cases in my every-day work at Google >>> where single inheritance was not good enough to write the >>> functionality that we needed without (a) code duplication and/or >>> (b) boilerplate for object delegation (plus the associated >>> complexity/slow-down/etc.). This was getting so annoying that I >>> went through the hassle of implementing a template-based traits >>> mechanism in C++ that we have been using quite regularly. >>> >>> For example, we have been designing and implementing a very complex >>> framework for efficient handling of massive entity/relation graphs >>> (billions of nodes). Since we needed this framework to be general >>> across multiple aspects, we simply couldn't come up with a good way >>> of doing this without some sort of MI, and traits proved to be >>> extremely useful. So, based on my experience, I certainly have seen >>> plenty of real-world applications where traits can make a >>> tremendous difference!! >>> >>> That said, I can absolutely see that an overuse of traits can also >>> add a lot of additional complexity. But in my opinion, this is not >>> specific to traits and much more applies to almost any concept when >>> it is overused. Consider for example single inheritance. If someone >>> needs a class with 50 methods and decide to split this into a 10- >>> level deep class hierarchy (just in case that somebody might want >>> to reuse a part of it later), this will annoy a lot of other people >>> and make things unnecessary complex. Similarly, if somebody splits >>> a method with a 20 line algorithm into 10 helper methods with hard- >>> to-understand names and consisting of only 2 lines each, this will >>> probably make things much harder to understand (although having >>> small methods is generally a good thing). >>> So, despite the fact that the concepts of single inheritance and >>> (helper-)methods can be overused, I'm sure that neither of us would >>> argue that they are bad/useless in the first place. And this is the >>> same for any of the other nice programming concepts that come to >>> mind, like meta-programming and closures (as much as I love >>> closures for parametrization, overuse of functional elements can >>> make code really hard to understand as well...) >>> >>> From my point of view, the same applies to traits: If traits are >>> used in cases where they actually bring a benefit, i.e., they >>> factor together a set of methods that conceptually and logically >>> belong together and actually facilitate code reuse, they have been >>> very useful to me. >>> >>> >>> Happy New Year and all the best, >>> Nathanael >>> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 6, 2010

[Pharo-project] About my recursive blues :)

by StÃ©phane Ducasse

Hi guys Sometimes I'm not in good mood. Today I was in a bad bad mood. Quite bad even badder. I was wondering why I was doing all that and the rest. What was the use to do Pharo if we get Squeak doing exactly the same - Ok we were right long time ago but still seeing all the removal of crappy code we begged to be removed and got bashed for and also doing all that effort and seeing it redone was not helping. Being right sometimes is not even cool :) So a plain bad day.... cold and rainy. I was frustrated that I cannot be somebody else, doing stuff full time and no other duties and going faster. In short nothing was working and I was a frustation ball like I'm good at being. But my kids were there and we had to go swimming! After going swimming and not thinking then thinking and discussing with some remote friends and emails. (Thanks guys you know who you are) also thinking about other people's attention and remarks in other contexts, my good mood came back even stronger than before because I came up to the conclusion that my remote friends were right (BTW thanks pharoers some of you inspire me today during my bad mood - alain, henrik, danny, lukas...) So what is the conclusion of all that? - I have a cool job (one of the best research positions in europe - not easy everyday but cool and with people supporting me with my crazy idea....imagine coding in smalltalk building an international team doing smalltalkish stuff). - we can invest for 5 years or even 10. Close your eyes and imagine we can decide now what we want to do now for the next 10 years and do it because we decided that this is fun. Amazing. No clients, no venture guys telling us the truth of life. - To a friend to which I was saying that I'm not that smart, that guy told me that smart is not the only measure: you can measure your impact, the books you wrote, the energy that other people took and got inspired and all kind of other measures.... :) So I can tell you I was down but this is good because I could think about what I really want to do. And I want to have an innovative Smalltalk system that can be used to develop business and innovative. (for example I would like to see if the new event system can be used to save Genie - one of the coolest handwriting recognition system I see). So I will not be extra-smart but I will learn and I will do it bit by bit. And I want to make it fun and beautiful. May be we will be able to go faster (it depends mainly on you guys :)) but I want 10 years or 15 or even 20 years of fun with a cool system and it is there in my hand (at three keystrokes from my keuboard). We will build it. Stef (sorry for the one of you that have to listen my bad mood I'm curing myself).

Jan. 6, 2010

Re: [Pharo-project] Beginner question :) search and replace in String

by Levente Uzonyi

On Wed, 6 Jan 2010, csrabak(a)bol.com.br wrote: > Em 06/01/2010 11:18, Adrian Kuhn < akuhn(a)iam.unibe.ch > escreveu: > >> Douglas Brebner writes: >> >>> Please bear in mind that natural languages have much more >>> redundancy and less precision than programming languages. >> You are right! >> Personally I believe programming languages should strive to be as >> close to the >> the more stringent English of specification documents, and not to >> natural language with *all* its facets. The main line of >> argumentation in my previous mail was thus that the very argument >> of natural languages can be used in favor of my point as well :) >> >>> In addition, programming languages have handy tools like >>> autocompletion that natural languages don't, making abbreviations >>> less useful :) >> That argument keeps popping up (eg from Ramon just in parallel to >> this >> answer, and also before) but I am not sure if auto completion is >> the whole story. For example in Object-C you have to write >> >> @"hello " stringByAppendingString: @"worlds!" >> >> to concatenate strings. Whereas in Smalltalk we just write >> >> 'hello ', 'worlds!' >> >> clearly both are as writable when you got auto completion, but >> isn't the second just more readable? > > Two points on "more readable". _Right now_ to Smalltalkers that know > by heart that #, is a concatenation operator, it seems *less cluttered* > and thus it appears more readable. > > Put forward some twenty to fifty years (or to do it right now ask a > girlfriend that doesn't know nor Objective C nor Smalltalk) to see > what of two expressions convene more meaning. > > As everybody else knows :-P the string concatenation operator is '+', > right!? So #, needs to be explained anyway. . . You're wrong, it's '.'. :) > > >> In his "Elements of Style" >> William Strunk recommends to omit unnecessary word. With regard to >> source code, I'd say the lesson should be that more verbose is >> typically more readable but *not* always. >> So given this observation that sometimes operators (or single >> letters, which >> for that sake the same) are *sometimes* more readable than natural >> language, we can go an revisit the set of operators in Smalltalk >> and check if there might be more candidates. And I'd be more than >> surprised if are were not some more candidates for abbreviation. >> For example Pharo already got #<< for appending to a stream, so the >> same would >> make sense to append elements to a collecton, such that we can >> write >> >> list := List new << 'lorem' << 'ipsum' << 'dolor'. >> et cetera. > > This may lead to the same problem we already have with #, namely it is > slow and not recommended for repeated operations. > No, it's fast, because it doesn't create copies. Of course to know that you also have to know that List is an alias for OrderedCollection... It's just a C++ism that makes your code slower. :) Levente > We have to strike a balance between the easiness for writing the code > with the implementation that will run it. > > my 0.019999.... > > -- > Cesar Rabak > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 6, 2010

Re: [Pharo-project] Polymorph

by StÃ©phane Ducasse

Gary I feel honored by your trust (which is a ***really*** important value for me - mainly my own value). Now slices are only good when dealing with crosscutting changes. They help us finding the packages in the kind of random order of the inbox :) > Given the integration of Polymorph with Pharo and the distinct direction that Squeak is going I am going to have to mark an end to Polymorph as an ongoing project, as such. > > Further changes/additions/refactorings will now be limited to Pharo and must be therefore done using the Slice system (will take a while to get to grips with as time allows). What I would like is to have a deeper merge (not turning around morphic idiosyncrasies). For fun I wanted to check CUIS Morph since juan removed a lot of unnecessary code. > A final release of Polymorph will be made on SqueakSource, as time allows soon. This will be the last (allegedly compatible) version with Squeak, though I expect in its current state it is effectively not loadable into recent Squeak images. > > I'll try to get the time to make any changes via Pharo slices though I still like the modularity of packaging systems. Can't have both it seems. Polymorph is mature enough that, moving forward, most else can be done as additions rather that overrides. Cool. > Perhaps an "extras" package? > Thanks to all who have been involved with Pharo and helping us to move forward. Here's to the new baseline! > > Shame the StrikeFonts don't do all that they should... always a compromise of speed vs. functionality (c.f. translucent text). > > On a personal note, it would be nice to start to leverage the possiblility of an open approach to visuals, host windows etc. Valuable lessons have been learned and I think Pharo can provide a baseline for moving forward to a more flexible and performant ui substrate. Happy to work with you all to achieve that goal! Excellent! We really want to learn from your experience. I have rome also in my scanner. > Regards, Gary > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 6, 2010

Re: [Pharo-project] Polymorph

by Alexandre Bergel

> On a personal note, it would be nice to start to leverage the > possiblility of an open approach to visuals, host windows etc. > Valuable lessons have been learned and I think Pharo can provide a > baseline for moving forward to a more flexible and performant ui > substrate. Happy to work with you all to achieve that goal! Nice to hear this! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 6, 2010

Re: [Pharo-project] Dev images with or without tests?

by csrabak＠bol.com.br

Alexandre, Once upon a time I thought like you, but I changed my mind when I realized that more and more the tests are being engineered in such a fashion that using them for the sake of an example is becoming convoluted. As we create all the machinery (setup and tear down) to do Unit Tests the test itself conveys less information unless you start to navigate the SUnit land, and I feel it will become even more inexpugnable for newcomers as soon PhExample enters the scene (you might have chained tests). Notwithstanding the accepted notion that tests are a form of documentation, I would say more and more they're falling into the same slot of the argument "you have access to the code": true but not practical for the day to day chores. -- Cesar Rabak Em 06/01/2010 14:58, Alexandre Bergel < alexandre(a)bergel.eu > escreveu: It is more for having examples under hands. Cheers, Alexandre

Jan. 6, 2010

Re: [Pharo-project] cutting dependencies

by Marcus Denker

On Jan 6, 2010, at 5:44 PM, Alain Plantec wrote: > StÃ©phane Ducasse a Ã©crit : >> Now the fact that Setting is cool will also >> reduce some problems we saw before. This will raise the question of the usage of services too. >> Because Services are a registration mechanism. >> > I thought that Services was to be removed and I've started to do so (It > would allow to fully remove Preferences). > Have I missed something ? No, services (the artefact that is there now, unused) should be removed. But we might need to introduce something similar (but simpler) later again. Marcus

Jan. 6, 2010