- Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20410

by Marcus Denker

20410 ----- Issue 7005: overlapping packages UI and UI-Basic http://code.google.com/p/pharo/issues/detail?id=7005 Issue 7004: remove ChangeSorter from privCleanUnloadMethods http://code.google.com/p/pharo/issues/detail?id=7004 Issue 6992: #cleanUpForRelease breaks image http://code.google.com/p/pharo/issues/detail?id=6992 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.986.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.742.diff -- Marcus Denker -- http://marcusdenker.de

Nov. 19, 2012

[Pharo-project] [Issues] Review needed

by Marcus Denker

This issue needs to be reviewed: Issue 6996: SoundSystem cleanup http://code.google.com/p/pharo/issues/detail?id=6996 -- Marcus Denker -- http://marcusdenker.de

Nov. 19, 2012

[Pharo-project] fOSSa 2012

by Marcus Denker

Pharo will participate to the fourth edition of the fOSSa Conference taking place from December 4 to 6, 2012 in Lille (France). The aim of the fOSSa (Free Open Source Academia Conference) is to reaffirm the underlying values of Open Source software: innovation & research in software development. While the first edition aimed at providing valuable information on the Open Source model at large, the second edition focused specific key-aspects of FOSS such as tech innovation,upcoming issues & challenges in the open development context and how open activities, collaboration and knowledge sharing is beneficial to academia, education & industry. The third edition look at the future of Open Source (Eco system, Trends, new territories, etc). The fourth edition will address in an open-minded style about: - Digital Geographic Strategies & the Native Generation, - FLOSS History with the movie: "Revolution OSâ followed by a debate, - Open Art, collaboration between art & science, - Licenses in the real life: no lawyers speeches, only facts & return experience, - Workshops to learn how to develop code for debian, gnome, apache, robotics ROS ... And, of course the usual fOSSa topics (Education & Community management). There will be a Pharo Workshop Dec 5th. "What marks the difference between fOSSa and other events is the air that you breath there. An event organized by passionate people, with passionate attendees as well â¦ and great speakers. Every year you can get some presentations of greater international events in advance (I remember the year of Arduino, to give you an example).â -- Gabriele Ruffatti -- SpagoWorld Blog 2012. fOSSa days are open to everyone and registration is free ! more information @ http://fossa.inria.fr -- Marcus Denker -- http://marcusdenker.de

Nov. 19, 2012

[Pharo-project] We crossed the 7000th issue!

by Marcus Denker

We crossed the 7000 mark yesterday! 6000 was reached In May 31. And of the 7000, just 381 are not yet solved. http://code.google.com/p/pharo/issues/list?can=2 Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 19, 2012

[Pharo-project] [update 2.0] #20409

by Marcus Denker

20409 ----- Issue 7000: Cleanup unused code in BitBlt class http://code.google.com/p/pharo/issues/detail?id=7000 Issue 7003: use ProvideAnswerNotification for DummyUIManager requests http://code.google.com/p/pharo/issues/detail?id=7003 Issue 6956: Some Ring tests are dependent on Monticello http://code.google.com/p/pharo/issues/detail?id=6956 Diff information: http://ss3.gemstone.com/ss/Pharo20/UIManager-MarcusDenker.88.diff http://ss3.gemstone.com/ss/Pharo20/Ring-Tests-Monticello-MarcusDenker.8.diff http://ss3.gemstone.com/ss/Pharo20/Ring-Tests-Kernel-MarcusDenker.44.diff http://ss3.gemstone.com/ss/Pharo20/Ring-Tests-Containers-MarcusDenker.9.diff http://ss3.gemstone.com/ss/Pharo20/Graphics-Primitives-MarcusDenker.96.diff http://ss3.gemstone.com/ss/Pharo20/Graphics-Display Objects-MarcusDenker.94.diff -- Marcus Denker -- http://marcusdenker.de

Nov. 19, 2012

[Pharo-project] [update 2.0] #20408

by Marcus Denker

20408 ----- Issue 7002: Remove old ChangeSorter implementation http://code.google.com/p/pharo/issues/detail?id=7002 Issue 7001: fix obsoleteReferences in Pharo Kernel http://code.google.com/p/pharo/issues/detail?id=7001 Issue 6999: cleaning a bit unused methods in DisplayObject hierarchy http://code.google.com/p/pharo/issues/detail?id=6999 Diff information: http://ss3.gemstone.com/ss/Pharo20/UI-Basic-MarcusDenker.20.diff http://ss3.gemstone.com/ss/Pharo20/UI-MarcusDenker.4.diff http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.984.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.741.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1289.diff http://ss3.gemstone.com/ss/Pharo20/Graphics-Files-MarcusDenker.35.diff http://ss3.gemstone.com/ss/Pharo20/Graphics-Display Objects-MarcusDenker.93.diff -- Marcus Denker -- http://marcusdenker.de

Nov. 19, 2012

Re: [Pharo-project] about sharing class binding and others

by Frank Shearar

On 18 November 2012 21:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Nov 18, 2012, at 10:40 PM, James Foster wrote: > >> I don't see the benefit of the added complexity. As it is now, at compile time the reference is not bound to a global but to an Association holding the global. If you want to change the value of the global you can do so and the method will reference the new value. Also, if you want to do name-lookup at runtime you can explicitly code it to do that. >> >> My objection to always doing run-time name lookup is that I would like to be able to create a module that is self-contained and binds to the the classes I provide without risking that someone else will replace my classes. I would like you to be able to load my module, containing my classes and methods, and we both can be confident that your later changes (including different classes with the same name) will not impact my classes and methods. >> >> If you want a parameterized module, then the module should be explicitly coded to take a parameter and use it explicitly. > > yes > > Module name: 'FOO' > binds: #A to: #Core.Z > > Module name: 'FOO2' > binds: #A to: #My.Z > > My original mail was to measure how much it costs to avoid to have the sharing of the system dictionary class binding in the method literal. > Because the design above requires to not share binding. > > I'm going over the master of camille and I would like to make such points clearer. > So with my little investigation it shows that we can support life programming without sharing bindings. Once Squeak 4.4 has been released, we'll be re-importing Colin Putney's Environments work, which seeks to do this. It might be worthwhile talking to him about modularisation. (Environments right now only handles class-level issues; it doesn't do anything like selector namespacing or classboxes or anything like that.) frank > Stef > >> I think it is not as clear to let the module think it is referencing a Point but in fact play a trick on it to have it reference a different class. >> >> - James >> >> On Nov 16, 2012, at 6:17 PM, StÃ©phane Ducasse wrote: >> >>> While I love the idea of sharing the systemDictionary class binding in the method to gain immediate update in case of >>> change I was questioning myself if we could not gain from not having (for example to get parametrized modules). >>> >>> The point is that we are not constantly changing classes especially when not programming but running program. >>> >>> So let us do some experiments: >>> >>> CompiledMethod allInstances size >>> 58891 >>> >>> (CompiledMethod allInstances select: [:each | each classBinding value name = #Point]) size >>> 100 >>> >>> [CompiledMethod allInstances select: [:each | each classBinding value name = #Point]] timeToRun >>> 23 >>> >>> this is the best case since classBinding is at a fixed size >>> >>> now looking for any reference to Point >>> >>> (CompiledMethod allInstances select: [:cm | >>> cm literals anySatisfy: [:each | each class = Association >>> and: [each key = #Point ]]]) size >>> 134 methods. >>> >>> [CompiledMethod allInstances select: [:cm | >>> cm literals anySatisfy: [:each | each class = Association >>> and: [each key = #Point ]]]] timeToRun >>> 91 ms >>> >>> so it looks to me that this sharing is not something that we should not changed if needed. >>> >>> What do you think? >>> >>> Stef >>> >> >> > >

Nov. 19, 2012

[Pharo-project] traits file-in problem

by Pavel Krivanek

Hi, if I file-out the category Tests-Traits-MOP to own *.st file and then try to load it into the Pharo Kernel, this test will fail because of this expression: self assert: (MOPTestClassA>>#c2) origin = Trait2. in this case it shows that the origin of MOPTestClassA>>#c2 is Trait3. The solution of this issue was to recompile the loaded classes. But it shows that the we miss some mechanism for preservation of system consistency when changing classes with traits. Cheers, -- Pavel

Nov. 19, 2012

[Pharo-project] Support: Redline Smalltalk ...

by James Ladd

Hey All, As you know I really love Smalltalk. So much so I have created a version of it that runs on the Java Virtual Machine. Please can you look at this campaign (http://www.indiegogo.com/smalltalk?a=1366536) and possibly support me raising some money to further develop Redline Smalltalk into a Version 1.0 product. If you hate this sort of post than apologies but you can't blame a developer for trying. Keep well, Rgs, James. http://redline.st

Nov. 19, 2012

Re: [Pharo-project] CachedBlockClosure was gone on purpose?

by Eliot Miranda

I replaced the implementation with one based on properties. It's in Squeak trunk and works fine. The VisualWorks style clean-block implementation is more complex but arguably not better, and being based on become: is less well suited to Squeak. On Sat, Nov 17, 2012 at 4:07 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Nov 17, 2012, at 9:05 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > On Nov 17, 2012, at 8:20 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > > > >> Because it is not present in 2.0 but I couldn't find any issue about > that. > >> > > Issue was http://code.google.com/p/pharo/issues/detail?id=6708 > > -- > Marcus Denker -- http://marcusdenker.de > > > -- best, Eliot

Nov. 19, 2012