November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] method wrappers package name problem

by Noury Bouraqadi

Hi, I tried MethodWrappers42 under Pharo 2.0-20370. I've got many tests turn green by simply adding CompiledMetod>>#isMwMethodWrapper that return true. Attached the mcz file. BTW, what is the license of this project? Noury Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print On 16 nov. 2012, at 10:43, Tudor Girba wrote: > Hi, > > Thanks a lot. I now created another package named MethodWrappers42 (instead of MethodWrappers4.2). > > Cheers, > Doru > > > On 15 Nov 2012, at 19:03, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On Nov 15, 2012, at 2:34 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi, >>> >>> We have a little problem with MethodWrappers. Currently, the package is called MethodWrappers4.2 which completely messes up Monticello in Pharo 1.4. >>> >>> So, we (me and Stef) would like to rename it to MethodWrappers42, but for that we need access to the repository. Marcus, could you provide this access? >>> >> >> I actually don't know what state MW is in... there are multiple ports using multiple strategies. The 42 one is for Squeak, I think. >> >> I added you, after fighting with SqueakSource (Stef I could not find in the list) >> >> Marcus >> >> >> >> >> >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> > > -- > www.tudorgirba.com > > "Don't give to get. Just give." > > > > > > Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --

Nov. 19, 2012

[Pharo-project] MongoTalk update

by Nicolas Petton

Hi guys, Lately I worked a bit on the Pharo Mongo driver for SmalltalkHub. I made several changes (in the new version 1.4): The query API changed: - MongoCollection>>query: now takes a 1 arg block, improving the API quite a bit. Queries like: aCollection query: (aCollection query query: { 'foo' -> 'bar'} asDictionary; yourself) Is now written: aCollection query: [ :query | query where: { 'foo' -> 'bar'} ] Sending #asDictionary has also been made optional, the query builder will send #asMongoQuery to the query collection. The MongoQueries package: Version 1.4 comes with a new package MongoQueries, a small DSL allowing us to use traditional blocks instead of dictionaries to perform queries. This is optional and backward compatible. Queries like: aCollection select: { '$or' -> { 'name' -> 'foo'. 'age' -> { '$gt' -> 23 } asDictionary } asDictionary } asDictionary can be expressed: aCollection select: [ :each | (each name = 'foo') | (each age > 23) ] The MongoQueries package should support the entire mongo query language (including nested queries), and comes with unit tests. Nico

Nov. 19, 2012

Re: [Pharo-project] [update 2.0] #20409

by Pavel Krivanek

On Mon, Nov 19, 2012 at 1:49 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 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 Grrr, the extension methods are still not moved to Ring-Tests-Monticello. Maybe we will need to remove this tests in one update and in the next one to add them to the new package. -- Pavel > > > 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] #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