June 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] squeaksource down

by StÃ©phane Ducasse

They are working on it.... Stef On Jun 5, 2011, at 11:16 AM, laurent laffont wrote: > please SmalltalkHub, please, save our souls !! > > Laurent.

June 5, 2011

[Pharo-project] squeaksource down

by laurent laffont

please SmalltalkHub, please, save our souls !! Laurent.

June 5, 2011

Re: [Pharo-project] Cuis 3.3

by StÃ©phane Ducasse

> Maybe we can list the interesting things to add and open tickets? That we we'll not forget ;) Yes here is the list > > On Sat, Jun 4, 2011 at 6:09 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Hi guys > > Some items would be good to have in pharo like the event cleaning... to bad that we cannot collaborate more > but this is like that. > May be have a look > * New hierarchy of Morphic Windows for tools, builds and handles UI > and menus; handles keystrokes > - View / Model separation is now complete > - Models are now GUI agnostic: they have 25% less methods and no references to Morphs we are rewriting all StringHolder with the same purpose so comparing is interesting at the design level. certainly: > * Object level events cleanup > - Gone is Model and the DependentsFields classVar in Object > - Only object event system mechanism is #when:send:to: > * Deep Models cleanup > * Big cleanup of copy and friends. > - #deepCopy eliminated > - #veryDeepCopy, DeepCopier, #veryDeepInner:, > #veryDeepFixupWith: eliminated. > * Editor tweaks and enhancements. Code simplification, removed > several ivars > > * FileList refactor

June 5, 2011

Re: [Pharo-project] Cuis 3.3

by Guillermo Polito

Maybe we can list the interesting things to add and open tickets? That we we'll not forget ;) On Sat, Jun 4, 2011 at 6:09 PM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > Hi guys > > Some items would be good to have in pharo like the event cleaning... to bad > that we cannot collaborate more > but this is like that. > > Stef > > New in Cuis 3.3 > ------------------- > * New nice Icon set from Tango (Casey) > - Most menu options have now a nice icon > * ContentPack - A clean solution for a problem Squeak had for over a > decade! (Casey) > - Manages internal/external resources > - Allows import / export to enable use of use existing stuff and > external tools > - Does not depend on external files for image update > - Updates done with code (enabling change sets of Monticello > packages) > - Avoids cruft accumulation, code for resources is removed after > update > * Taskbar for better access to minimized windows (Casey) > * Multiple selection on text morphs (Thanks Bernhard Pieber and > Software Generation!) > - Use ctrl + mouse for multiple selection > - Do 'Preferences disable: #commandClickOpensHalo' to enable the > standard Mac gesture for multi-selection (command + mouse) > - Enhanced senders view: all occurrences of sent message are > highlighted > * Cosmetic tweaks in menus and Themes > * NewTranscript fixes and enhancements (right click menu) > * New hierarchy of Morphic Windows for tools, builds and handles UI > and menus; handles keystrokes > - View / Model separation is now complete > - Models are now GUI agnostic: they have 25% less methods and no > references to Morphs > - Eases having alternate GUI frameworks such as Morphic 3, or > adapted versions of MVC, Tweak or EToys > * Object level events cleanup > - Gone is Model and the DependentsFields classVar in Object > - Only object event system mechanism is #when:send:to: > * Deep Models cleanup > * Big cleanup of copy and friends. > - #deepCopy eliminated > - #veryDeepCopy, DeepCopier, #veryDeepInner:, > #veryDeepFixupWith: eliminated. > - Use of ReferenceStream for copying object graphs such as Morphs > - Clients don't need to know object internals to get a good copy > - copying details in most classes greatly simplified > * Editor tweaks and enhancements. Code simplification, removed > several ivars > * New image shrinking tools: #reduceCuis for building reduced images > * Support for gigabyte changes and sources files > - not activated by default, as it needs new Sources file, i.e. > major version number change > - Easy to activate if you need it > * BlockClosure>>#isClean, BlockClosure serialization (for clean > blocks), enabling use of ReferenceStream for copying objects > * Many minor Morphic fixes > * Morphic cleanup. Morph selectors size reduced by 17%, several > ivars removed, code simplified. > * Cleanup in Object and other basic classes. Object selectos size > reduced by 10% > * FileList refactor > > As usual, comments, discussion, bug reports, kudos and donations are all > welcome! > > Cheers, >

June 5, 2011

[Pharo-project] Cuis 3.3

by stephane ducasse

Hi guys Some items would be good to have in pharo like the event cleaning... to bad that we cannot collaborate more but this is like that. Stef New in Cuis 3.3 ------------------- * New nice Icon set from Tango (Casey) - Most menu options have now a nice icon * ContentPack - A clean solution for a problem Squeak had for over a decade! (Casey) - Manages internal/external resources - Allows import / export to enable use of use existing stuff and external tools - Does not depend on external files for image update - Updates done with code (enabling change sets of Monticello packages) - Avoids cruft accumulation, code for resources is removed after update * Taskbar for better access to minimized windows (Casey) * Multiple selection on text morphs (Thanks Bernhard Pieber and Software Generation!) - Use ctrl + mouse for multiple selection - Do 'Preferences disable: #commandClickOpensHalo' to enable the standard Mac gesture for multi-selection (command + mouse) - Enhanced senders view: all occurrences of sent message are highlighted * Cosmetic tweaks in menus and Themes * NewTranscript fixes and enhancements (right click menu) * New hierarchy of Morphic Windows for tools, builds and handles UI and menus; handles keystrokes - View / Model separation is now complete - Models are now GUI agnostic: they have 25% less methods and no references to Morphs - Eases having alternate GUI frameworks such as Morphic 3, or adapted versions of MVC, Tweak or EToys * Object level events cleanup - Gone is Model and the DependentsFields classVar in Object - Only object event system mechanism is #when:send:to: * Deep Models cleanup * Big cleanup of copy and friends. - #deepCopy eliminated - #veryDeepCopy, DeepCopier, #veryDeepInner:, #veryDeepFixupWith: eliminated. - Use of ReferenceStream for copying object graphs such as Morphs - Clients don't need to know object internals to get a good copy - copying details in most classes greatly simplified * Editor tweaks and enhancements. Code simplification, removed several ivars * New image shrinking tools: #reduceCuis for building reduced images * Support for gigabyte changes and sources files - not activated by default, as it needs new Sources file, i.e. major version number change - Easy to activate if you need it * BlockClosure>>#isClean, BlockClosure serialization (for clean blocks), enabling use of ReferenceStream for copying objects * Many minor Morphic fixes * Morphic cleanup. Morph selectors size reduced by 17%, several ivars removed, code simplified. * Cleanup in Object and other basic classes. Object selectos size reduced by 10% * FileList refactor As usual, comments, discussion, bug reports, kudos and donations are all welcome! Cheers,

June 4, 2011

[Pharo-project] [update 1.3] #13245

by stephane ducasse

13245 ----- - Issue 4331: Lists Fusion. Now deprecate PluggableIconListMorphOfMany, PluggableListMorphOfMany, PluggableMorphListMorphOfMany since PluggableListMorph can do the same. Thanks Benjamin this is cool :). - Issue 4348: CompilerEvaluationTest>>#testEvaluationOfSelfSend dependent on Morphic. Thanks Pavel Krivanek. http://code.google.com/p/pharo/issues/detail?id=4348 Stef

June 4, 2011

[Pharo-project] [update 1.3] #13244

by StÃ©phane Ducasse

13244 ----- - Issue 4349: Base64MimeConverterTest in CollectionsTests. Thanks Pavel Krivanek. http://code.google.com/p/pharo/issues/detail?id=4349 - Issue 4331: Lists Fusion part two. Tx B. van ryseghem.

June 4, 2011

Re: [Pharo-project] Toward MVP: SimpleGridExample vs. ClassListExample, etc.

by StÃ©phane Ducasse

On Jun 4, 2011, at 6:55 PM, Schwab,Wilhelm K wrote: > Stef, > > Thanks for the homework assignments :) > > I have not specifically looked at simple grid in 1.3, but I will do so - gotta go for a run first. > > My MVP code is not yet available, but I intend to release it once it is remotely worth having. I was pleasantly surprised to find more than I thought I had working. Maybe I should soon put a "first draft" where people can see it. yes please do :) > The design (if that word applies<g>) is a compromise between Dolphin's approach to GUIs where it makes sense to follow them, realizing that the Dolphin view composer isn't here, some "going along with the flow" where Polymorph makes things too easy to ignore, and finally some Seaside influence. > > Dolphin uses a GUI to assemble views. I am planning to do that with code, but ultimately that should not be forced. It will take some time to balance all of that. > >>> did you check HPI library or void nullpointer widgets? > > I am not familiar with them, but I will look. I suspect I am finding smoke screens on HPI, I think that they have some nice widgets to get inspired from. > but the null pointer widgets look like I found what you have in mind. It looks like you are "thinking big," which is great. I am not a big believer that native widgets equate to speed, but, there are times when some native code goes a LONG way in that direction. I would like to see us able to use one native window per tool shell, if not be able to go completely native. I think it would be painful, but ultimately good for us. I'm not talking about native. just getting some good foundation. > > Short term, I am not so much thinking of replacing the GUI (though my stuff would hopefully run on top of any widgets - with some work) as I am with reducing the redundant work that goes in to a GUI, and moving us toward MVP. The latter is for two reasons: (1) it is a nice framework; (2) I have a lot of old code that I would like to see have a home on Linux. yes work on it and let us see it. > > Bill > > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Saturday, June 04, 2011 12:23 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Toward MVP: SimpleGridExample vs. ClassListExample, etc. > > On Jun 4, 2011, at 6:08 PM, Schwab,Wilhelm K wrote: > >> I have a couple of GUIs to create, and took another look at my (very) slowly evolving MVP package. A small update appears below, but the question of the day is one of performance of MorphTreeMorph in its various incarnations. >> >> ClassListExample is very impressive and reasonably quick. SimpleGridExample is very nice, but quite slow. Profiling its opening reveals that it spends a lot of time making morphs, but that's not super surprising. It's the total time that is of concern. Any takers on why? > > > did you check on 1.3 because igor and ben spent some time optimizing it a bit. > >> I ask, because I am trying to create basic presenter classes for lists, trees, (more or less working), text (will be easy - I *think*), and another big item is multi-column lists. My objective is to be able to easily construct things that (unless told to do otherwise) automatically deal with the selected index, updates, etc. None of this stuff is terribly difficult to do when following the Polymorph examples, PharoCasts, etc., but hopefully we can have MVP and stop repeating ourselves at the same time. > > > I'm interested in that MVP framework. > Do you have some code somewhere? > > With igor we discussed about killing pluggable.... but for now one step at the time. > > >> The next thing I am missing is a grid. Any strong thoughts on examples to follow/reuse, or things that should NOT be used for any reason? > > did you check HPI library or void nullpointer widgets? > > I would love to have a gorup of people pushing that. >> >> Bill >> >> >> >> >> > > >

June 4, 2011

Re: [Pharo-project] OSProcess on 1.2

by Sean P. DeNigris

David T. Lewis wrote: > > If I remember correctly, there are no plans for further updates > to that VM (Esteban could say better than me of course). > From http://forum.world.st/looking-for-feedback-on-Cocoa-Cog-MT-VM-td3534230.html : Esteban Lorenzano wrote: > > What is definitively true, is the fact that there are a lot of machines > who needs to use a 4.x series (in mac versions), and a lot of legacy code > who will be using this "old" vm too... and because of this, 4.x series > will be around a long time. > With Cog 5.8b12, I got warnings like "process accessor module not available". And I mentioned the hanging tests with the Cocoa 5.7.4.1 in my last post. So there seems to be issues with all the Mac VMs. David T. Lewis wrote: > If it I can raise the question on the vm-dev list. Done. -- View this message in context: http://forum.world.st/OSProcess-on-1-2-tp3569458p3573880.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 4, 2011

Re: [Pharo-project] Compiling and using the FT2Plugin

by Mariano Martinez Peck

Hi Alain. I am a bit late, sorry. I just wanted to let you know that you made me happy :) Not only because you could build the vm by yourself but in addition you could help us, comment a problem and even helping with the solution. That kind of thing is exactly what I expect and hope when I write my posts or colaborate with the VM world. Cheers Mariano On Sat, Jun 4, 2011 at 2:55 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 4 June 2011 11:34, Alain Plantec <alain.plantec(a)yahoo.com> wrote: > > Hi Igor, > > > > #configureFT2Plugin: is the place for #addExternalLibraries: but it only > > works for FT2Plugin compiled as internal plugin. > > To compile the FT2Plugin as external, you also have to use > > #addExternalLibraries: #('freetype') but not sent from > #configureFT2Plugin:. > > It is because of cmake and where #configurePlugin:with: is sent from the > > #generate method. > > in the #generate method, #configurePlugin:with: is sent **BEFORE** the > > 'add_library' cmd production for cmake. > > it is ok for internal plugin. but, if the plugin is external, then, > > #addExternalLibraries: #('freetype') > > has to be invoked **AFTER** the 'add_library' cmd production for cmake. > > > > I've implemented a #postConfigurePlugin:with:. same logic as > > #configurePlugin:with: but sent from > > the generate method after the 'add_library' cmd production. > > > > generate > > ... > > vmGen config configurePlugin: plugin with: self. > > ... > > internal > > ifTrue: [self cmd: 'add_library' params: name , ' STATIC > > ${sources}'.] > > ifFalse: [self cmd: 'add_library' params: name , ' SHARED > > ${sources}']. > > > > vmGen config postConfigurePlugin: plugin with: self. "added post > > configuration here" > > ... > > > > Yeah. I am also stumbled with this couple of times. > The workaround would be to use variables, so > in #addExternalLibrary , it should set (or better append ) library to the > list, > and then generator will simply use this list in a single command for > linking with target. > > > I will open an issue and put all my stuffs there. > > > > good. thanks. > > > Cheers > > Alain > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Mariano http://marianopeck.wordpress.com

June 4, 2011