- Pharo-dev - lists.pharo.org

[Pharo-project] Hacking afternoon starts

by StÃ©phane Ducasse

Hi guys we are starting and we will log on irc but you can also reach me with aol/ichat: sducasse(a)mac.com ICQ: 234273866 the idea is to - fix some bugs in 1.1 - tristan found the problem in the weakDictionary so we will need other people to have a look at it. - integrate/check validate some easy items for you - fix some important bugs. I suggest that we send around mails in this thread when we start to work on an item and we integrate something. In the future we will see if we cannot use the inria infrastcuture to have webcam + videos fun. Stef

April 30, 2010

Re: [Pharo-project] Pharocasts on www.world.st

by StÃ©phane Ducasse

Excellent! Good idea torsten On Apr 30, 2010, at 9:36 AM, Geert Claes wrote: > > Thanks, just added those as well! > -- > View this message in context: http://forum.world.st/Pharocasts-on-www-world-st-tp2076555p2076574.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 30, 2010

Re: [Pharo-project] Pharocasts on www.world.st

by Geert Claes

Thanks, just added those as well! -- View this message in context: http://forum.world.st/Pharocasts-on-www-world-st-tp2076555p2076574.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 30, 2010

[Pharo-project] Pharocasts on www.world.st

by Torsten Bergmann

Hi Geert, there are also videos on Pharo done regulary by Laurent (see htt://pharocasts.blogspot.com) Maybe you can add them to the new video section of http://www.world.st too. Thanks Torsten -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

April 30, 2010

Re: [Pharo-project] ConfigurationOfPharo

by Torsten Bergmann

The best solution would be to bring back Damiens version that was deleted so the repos is like it was before without any compatibility problem (maybe someone has it in it's package cache). We should also remind people not to delete mcz's. Bye T. -------- Original-Nachricht -------- > Datum: Fri, 30 Apr 2010 00:44:01 +0200 > Von: Mariano Martinez Peck <marianopeck_gmail.com> > An: Torsten Bergmann <astares_gmx.de> > Betreff: Re: [Pharo-project] ConfigurationOfPharo > On Fri, Apr 30, 2010 at 12:38 AM, Torsten Bergmann <astares_gmx.de> wrote: > > > > Done. Check the repo. Can you change MetaSource to use 1.0.1 instead > and > > > let > > > me know if it works? > > > > > > > If you look at ConfigurationOfMetaSource in squeaksource/MetaSource > > you will see that I dont use it directly. It come in through transitive > > dependencies: > > > > - I use ConfigurationOfPharo (1.0-10517) which uses > > - ConfigurationOfAutomaticMethodCategorizer (version 1.1) which uses > > - 'OB-Standard' with: '1.1'. > > > > If I want to make it work again we have to do new version for all > > of them!? > > > > Maybe you now know why I used the workaround ... > > > > > Uffff yes. Now I see. :( > I don't see a clear solution here. Yours is easy and work, but I don't > like > the idea of changing a released version. Anyway, maybe we should rollback > to > your solution? > I hate we don't have an easy and clear solution :( > sorry for all the noise. I guess we are all trying to understand how to > manage software with metacello agains different situations. > > cheers > > mariano > > > > > Bye > > T. > > -- > > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

April 30, 2010

Re: [Pharo-project] Legitimate syntax for # ... foo

by StÃ©phane Ducasse

THANKS!!! I'm sure that lukas is occupy to clean his house/repaint the wall/read all the papers he forgot instead of writing his phd that he will help :D with great enthusiasm. >>>>> That's fair enough, but that's a different issue to there being allowable >> whitespace between the literal hash and the literal. In any case, comparing >> against VW is probably a sensible thing to do. >> best >> Eliot > > Here we go: fix at http://code.google.com/p/pharo/issues/detail?id=2371 > > Some tests from Lukas would be appreciated :)

April 30, 2010

Re: [Pharo-project] gettext change set

by StÃ©phane Ducasse

thanks hilaire I will open a ticket. Stef On Apr 29, 2010, at 10:05 PM, Hilaire Fernandes wrote: > So far, > > In the archive the change set of classes (may be there are more) extracted from Etoys for Gettext support. > > They should install fine in Pharo 1.1, however there are incompatibility issues, look like related to MethodReference protocole (in TranslatedReceiverFind>>findWordsWith:in: ) > Probably more to discover after this one. > > To use the gettext protocol doc http://community.ofset.org/index.php/OLPC#How_can_I_export_the_.pot_file_fo… > > I use to install DrGeoII package then, try the gettext into it: > > TextDomainManager registerCategoryPrefix: 'DrGeoII' domain: 'DrGeoII'. > > ok > > GetTextExporter2 exportTemplate. > > fail > > > If someone is interested by a pair hacking session in IRC, drop me a line. > > Hilaire > <gettext-support.zip>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 30, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by Andreas Raab

On 4/29/2010 3:21 AM, Alain Plantec wrote: > Andreas Raab a Ã©crit : >> On 4/28/2010 11:32 PM, StÃ©phane Ducasse wrote: >>> Good but what is your point? >> >> Compatibility and simplicity. > Come on Andreas, "simple" is not so much more precise than "cool" That comment deserves a more detailed exploration than I want to put into this message. You can find my response here: http://squeakingalong.wordpress.com/2010/04/30/measuring-simplicity/ > and I don't think that having: > > ------------------ > Editor class>>blinkingCursor > ^ BlinkingCursor ifNil: [ true ] > > EditorSetting class>>editorSettingsOn: aBuilder > <systemsettings> > (aBuilder setting: #blinkingCursor) > label:'Blinking Text Cursor') > parent: #Morphic; > target: Editor; description: 'When true, the text cursor will blink.' > ------------------- > > is so much more "complicated" than > > ------------------- > Editor class>>blinkingCursor > <preference: 'Blinking Text Cursor' > category: 'Morphic' > description: 'When true, the text cursor will blink.' > type: #Boolean> > ^ BlinkingCursor ifNil: [ true ] > ------------------- You're right, by itself it may not be "so much more complicated". But isn't this forgetting a few things? Like for example, that not only are you adding the extra method, but also an extra class and an extra package? This gets you from a single entity (the domain code) to four entities (the domain code, the builder method, class and package). In terms of both conceptual and interface simplicity that seems significant (and a dozen of messages in the builder all add to interface complexity). BTW, I want to point out something important here. I'm not saying your approach is "bad". Good and bad, black and white, are not categories that I use for evaluating software design. I leave that to the people with overly simplified views on software development ;-) There are only different trade-offs for different goals. Your approach is perfectly reasonable for a given set of goals and trade-offs. If there is a need to have specific fine-grained control over the UI to particular preferences, I would choose precisely the same approach - make a package with views for the values that I want to modify. It's a perfectly fine approach for such a set of goals. Moreover, "simplicity" isn't an absolute attribute of software. Simplicity is a tradeoff. It is often worthwhile to trade off simplicity, for example when adding valuable new features. So my claim here is not about "good" and "bad". My claim is this: 1. The approach in Squeak is measurably simpler than yours. It may not fit your goals, you may need a different approach, that's quite possible. But there are numbers we can put on things to compare them and if we put the numbers on then Squeak's approach is simpler. 2. Because of the difference in interface complexity, I expect Squeak's approach will be easier to support in the long term. There's no proof for that, but I think the claim is valid, and I will watch the future developments in both Pharo and Squeak with interest. 3. Your initial design choice of using a builder framework for preferences implied the later complexity. Because the approach requires adding non-domain code to core classes it creates pressure to put this code elsewhere and to package that code separately. It's a valuable lesson about the impact of early design choices. > You prefer UI+domain mixing, we prefer UI separated from domain. I'm missing something. What UI+domain mixing? There is no UI code in Squeak's preference tags. There is only domain code and a method tag for discovery of the preference. Only Pharo has UI (builder) code; there is no equivalent in Squeak's preference tags. > And yes, the SettingBrowser implementation could be improved. > I know, but I'm happy because it can be removed or remade > without any other consequence. > And compare it to the PreferenceBrowser ... I'm not certain what your point here is. I'm only talking about preference declaration, not about how the preference browser functions. PreferenceBrowser itself is reloadable in Squeak 4.1 and one of the packages that I customarily unload for creating smaller images, because I'm quite happy to set my preferences by sending message to objects directly :-) Cheers, - Andreas

April 30, 2010

Re: [Pharo-project] [NativeBoost] new win32 build available

by Igor Stasenko

On 30 April 2010 02:16, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Interesting. Â Scary<g> but interesting. Â At the risk of seeming obsessed with numerical analysis, is there a way to use this for callbacks? > Not yet. But i plan to add the callbacks support. > 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.

April 30, 2010

Re: [Pharo-project] [NativeBoost] new win32 build available

by Igor Stasenko

On 30 April 2010 01:54, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Â On 29.04.2010 17:13, Igor Stasenko wrote: >> >> Core packages were broken, and were unable to load w/o errors. >> But now seems everything loads well. >> Use NBInstaller install. >> >> Thanks to Henrik for help! > > Here's a small example, as well as profile: > > SmallInteger >> nbFib > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > Â Â ^ NBNativeCodeGen methodAssembly: [:gen | > Â Â Â Â | loopStart proxy asm Â EAX EBX ECX | > Â Â Â Â asm := gen asm. > Â Â Â Â proxy := NBInterpreterProxy new asm: asm. > Â Â Â Â loopStart := asm uniqueLabelName: 'loopStart'. > > Â Â Â Â EAX := asm assembler reg0. > Â Â Â Â EBX := asm assembler reg3. > Â Â Â Â ECX := asm assembler reg1. > Â Â Â Â proxy receiver. > Â Â Â Â proxy integerValueOf: EAX. > > Â Â Â Â asm mov: EAX to: ECX; > Â Â Â Â Â Â Â Â mov: 0 to: EAX; > Â Â Â Â Â Â Â Â mov: 1 to: EBX; > Â Â Â Â Â Â Â Â label: loopStart; > Â Â Â Â Â Â Â Â add: EAX with: EBX; > Â Â Â Â Â Â Â Â xchg: EAX with: EBX; > Â Â Â Â Â Â Â Â "next three could be replaced by loopnz and a dec ECX before > loop, but loopnz isn't there yet" > Â Â Â Â Â Â Â Â dec: ECX; > Â Â Â Â Â Â Â Â cmp: ECX with: 1; > Â Â Â Â Â Â Â Â jg: loopStart. > > Â Â Â Â proxy positive32BitIntegerFor: EBX. > Â Â Â Â gen epilogue] > > SmallInteger >>fib > Â Â |tmp res| > Â Â tmp := 1. > Â Â res := 0. > Â Â 0 to: self -1 do: [:ix | |oldRes| > Â Â Â Â Â Â oldRes := res. > Â Â Â Â Â Â res := tmp + res. > Â Â Â Â Â Â tmp := oldRes.]. > Â Â ^res > > Neither work for negative integers, and nbFib overflows for 48, haven't > added largeInt creation logic :) > ohh.. you will be need more than just create large int. Since at 48 you will get past the size of register, you'll have to switch to different loop. And it will end up with quite complex assembler :) But if we leave the complexity aside, the thing is, that you can greatly optimize it comparing to smalltalk implementation. You can use stack, for keeping a variable-length big int during calculation. So, you will need to create a single final BigInt oop only when loop ends. > [1 to: 100000 do: [:ix | 47 fib]] timeToRun 361 > [1 to: 100000 do: [:ix | 47 nbFib]] timeToRun 21 > [1 to: 100000 do: [:ix | ]] timeToRun 2 > > Cheers, > Henry > > > > > _______________________________________________ > 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.

April 30, 2010