July 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Image overwrite warning

by StÃ©phane Ducasse

In fact I have the same MouseHandler over problem in the previous image so I will probably recheck the changes of lukas. On Jul 7, 2009, at 12:00 PM, StÃ©phane Ducasse wrote: > > On Jul 7, 2009, at 10:47 AM, Torsten Bergmann wrote: > >> Is it just me or does the latest pharo(-dev) not warn anymore >> if you save the image to an image file that >> already exist (when using "save as")? > > no lukas change that and we should rollback but the fixes he sent me > look strange. > Can you check in the inbox the hostmenus package? > >> >> >> Also why are the arrows in folded menus >> now white? Black was better visible on the light >> background. > > :) > This is a side effect of Cursor initialize when we recompiled the > method due to the > _ to := refactoring. > > You know this may be 15 years that this initialize was not > executed.... > Now we would like to get back the black arrows but I do not know. > Probably a color depth went wrong :) > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 7, 2009

Re: [Pharo-project] Image overwrite warning

by StÃ©phane Ducasse

On Jul 7, 2009, at 10:47 AM, Torsten Bergmann wrote: > Is it just me or does the latest pharo(-dev) not warn anymore > if you save the image to an image file that > already exist (when using "save as")? no lukas change that and we should rollback but the fixes he sent me look strange. Can you check in the inbox the hostmenus package? > > > Also why are the arrows in folded menus > now white? Black was better visible on the light > background. :) This is a side effect of Cursor initialize when we recompiled the method due to the _ to := refactoring. You know this may be 15 years that this initialize was not executed.... Now we would like to get back the black arrows but I do not know. Probably a color depth went wrong :) Stef

July 7, 2009

Re: [Pharo-project] Loads of Pharo development process questions

by StÃ©phane Ducasse

would be interesting to give a try. Now I'm concerned by our resources. Stef On Jul 7, 2009, at 10:50 AM, Damien Cassou wrote: > On Mon, Jul 6, 2009 at 12:18 AM, Reinout Heeck<reinz(a)desk.org> wrote: >> Load (more precisely: use -- we might not be able to load it) a / >> specific/ version of the Squeak tool, and then apply a separate >> (Pharo- >> maintained) set of patches to make it Pharo compliant. >> Define a process to specify how bug fixes are to be pushed upstream, >> and how enhancements are pulled downstream -- reassessing the Pharo >> patches each time a new version is pulled downstream. > > This is something that works very well in Linux and I think we could > use it. What we need to make this happen: > > 1) a repository of patched packages that can be easily loaded inside > user images > 2) a repository of patches that can be applied to tools in order to > make them compatible with Pharo > 3) a database which associates a package with a list of ordered > patches to apply on it > 4) a tool to populate the first repository with automatically created > packages containing the patches. That tool should be able to apply > patches without even load the package in the image (because there > might be undefined references or overrides in non-existing classes...) > > > What we have: > > 1) any Monticello repository would do (e.g., SqueakSource) > 2) any ftp/http directory would do (like we do with the current update > stream 'pharo.gforge.inria.fr') > 3) it could be a directory per package (named with the name of the > package) containing all patches for that package (named with a number > indicating the order of patches) > 4) that one should be written. Possible steps: unzipping the mcz, > applying the patch to the source, creating a new mcz, pushing that mcz > to the repository 1). > > What do you think? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 7, 2009

Re: [Pharo-project] Image overwrite warning

by Cameron Sanders

Just grabbed an image last night, and I was surprised by the Quit behavior: option to save on Quit. There was recently some talk about this menu, but I didn't follow the discussion closely. -Cam On Jul 7, 2009, at 4:47 AM, Torsten Bergmann wrote: > Is it just me or does the latest pharo(-dev) not warn anymore > if you save the image to an image file that > already exist (when using "save as")? > > > Also why are the arrows in folded menus > now white? Black was better visible on the light > background. > > Thanks > Torsten > -- > Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate > fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 7, 2009

Re: [Pharo-project] Loads of Pharo development process questions

by Damien Cassou

On Mon, Jul 6, 2009 at 12:18 AM, Reinout Heeck<reinz(a)desk.org> wrote: > Load (more precisely: use -- we might not be able to load it) a / > specific/ version of the Squeak tool, and then apply a separate (Pharo- > maintained) set of patches to make it Pharo compliant. > Define a process to specify how bug fixes are to be pushed upstream, > and how enhancements are pulled downstream -- reassessing the Pharo > patches each time a new version is pulled downstream. This is something that works very well in Linux and I think we could use it. What we need to make this happen: 1) a repository of patched packages that can be easily loaded inside user images 2) a repository of patches that can be applied to tools in order to make them compatible with Pharo 3) a database which associates a package with a list of ordered patches to apply on it 4) a tool to populate the first repository with automatically created packages containing the patches. That tool should be able to apply patches without even load the package in the image (because there might be undefined references or overrides in non-existing classes...) What we have: 1) any Monticello repository would do (e.g., SqueakSource) 2) any ftp/http directory would do (like we do with the current update stream 'pharo.gforge.inria.fr') 3) it could be a directory per package (named with the name of the package) containing all patches for that package (named with a number indicating the order of patches) 4) that one should be written. Possible steps: unzipping the mcz, applying the patch to the source, creating a new mcz, pushing that mcz to the repository 1). What do you think? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 7, 2009

[Pharo-project] Image overwrite warning

by Torsten Bergmann

Is it just me or does the latest pharo(-dev) not warn anymore if you save the image to an image file that already exist (when using "save as")? Also why are the arrows in folded menus now white? Black was better visible on the light background. Thanks Torsten -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

July 7, 2009

[Pharo-project] VM & Exupery

by Cameron Sanders

What are the best places (documentation sources) to get started exploring and learning the VM code (the generated C) and Exupery? I am running on an iMac and would be willing to try to get Exupery working on it. Thanks, Cam PS: I will not be able to invest a block of time until November or December -- in the event there was something I could help with, but I imagine there is a learning curve

July 6, 2009

Re: [Pharo-project] [ANN][Dev-Images] July 2009 versions

by Adrian Lienhard

For "Pharo" I would focus on developer tools. So what is listed as accepted on the wiki page [1] seems reasonable to me. Adrian [1] http://code.google.com/p/pharo/wiki/Packages On Jul 6, 2009, at 22:27 , StÃ©phane Ducasse wrote: > probably now I was talking about pharo. > what do we want in pharo (old pharo-dev) > Stef > > On Jul 6, 2009, at 7:49 PM, Adrian Lienhard wrote: > >> just a thought: instead of a Pharo-full image, wouldn't it be more >> useful if we had a package manager (Metacello?) that lets the user >> install what he likes (and not more)? >> >> Cheers, >> Adrian >> >> On Jul 6, 2009, at 18:27 , StÃ©phane Ducasse wrote: >> >>> Damien >>> >>> may be we will have to think about what should be available in pharo >>> (old pharo-dev) >>> vs pharo-full >>> >>> >>> my first cut at pharo is >>> >>>> eCompletion version 0.102 >>>> eCompletion-Traits version 0.1 >>>> eCompletionOmniBrowser version 0.5 >>> >>>> OB-Enhancements version 0.328 >>>> OmniBrowser version 0.447 >>>> OmniBrowser-Algernon version 0.5 >>>> OmniBrowser-Full version 0.27 >>>> OmniBrowser-Morphic version 0.88 >>>> OmniBrowser-Refactory version 145 >>>> OmniBrowser-Regex version 0.18 >>>> OmniBrowser-Standard version 0.406 >>> >>>> Polymorph EventEnhancements version 1.1 >>>> Polymorph Geometry version 1.1 >>>> Polymorph TaskbarIcons version 1.0 >>>> Polymorph ToolBuilder version 1.3 >>>> Polymorph Tools Diff version 1.3 >>>> Polymorph Widgets version 1.4 >>>> Refactoring Core version 48 >>>> Refactoring Spelling version 5 >>>> RoelTyper version 0.60 >>> >>>> Universes version 52 >>>> Universes OmniBrowser version 0.38 >>>> YAXO version 14 >>>> Shout version 3.15-tween.72 >>>> ShoutWorkspace version 1-tween.4 >>> >>> >>> >>> >>>> VBRegex version 1.9 >>> is already in Pharo >>> >>> >>> all the rest may go in pharo -full >>> >>>> Aida version 5.6 >>>> Algernon version 1.2 >>>> AST version 164 >>>> AutomaticMethodCategorizer version 0.25 >>>> AutomaticMethodCategorizerOB version 0.2 >>>> DynamicBindings version 2.7 >>>> Installer version 4.3 >>>> Installer-Core version 4.3.313 >>>> Installer-Formats version 4.3.3 >>>> Installer-Scripts version 4.3.8 >>>> KomHttpServer version 7.0.45 >>>> KomServices version 1.19 >>>> Magritte-Model version 1.1.1.349 >>>> Magritte-Seaside version 1.1.1.302 >>>> Magritte-Tests version 1.1.1.153 >>>> >>>> Pier version current >>>> Pier-Blog version 1.1.1.117 >>>> Pier-Documents version 1.1.1.15 >>>> Pier-EditorEnh version 1.1.1.48 >>>> Pier-Model version 1.1.1.328 >>>> Pier-Seaside version 1.1.1.419 >>>> Pier-Security version 1.1.1.141 >>>> Pier-Tests version 1.1.1.137 >>>> >>>> RSRSS2 version 2.8.4.12 >>>> Scriptaculous version 2.8.4.250 >>>> ScriptManager version 0.6 >>>> Seaside version 2.8.4.591 >>>> Seaside-Adapters-Core version pmm.2.mcz >>>> Seaside-Adapters-Swazoo version 9 >>>> Seaside-Squeak-Adapters version pmm.3.mcz >>>> SeasideAdaptersCompatibility version pmm.1.mcz >>>> >>>> SmaCC runtime version 13 >>>> Sport version 2.31 >>>> Squeak dev packages version 0.28 >>>> Squeak web packages version 0.2 >>> >>> >>>> SUnit-improved version 4.0.118 >>>> SUnitGUI-improved version 4.0.50 >>> what is this? >>> >>> >>> >>>> Swazoo version 2.1 >>>> >>>> >>>> >>>> -- >>>> Damien Cassou >>>> http://damiencassou.seasidehosting.st >>>> >>>> "Lambdas are relegated to relative obscurity until Java makes them >>>> popular by not having them." James Iry >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 6, 2009

Re: [Pharo-project] Loads of Pharo development process questions

by StÃ©phane Ducasse

>> > > No, quite the opposite: > > The Pharo maintainers maintain the Pharo compliance patches for every > tool we import, the tool developer should not be bothered with these > -- should not even see them. I agree but it means that other pharoers should stand up and sign for that because I'm full and will probably continue to be. > Only a subset of these patches -- the bugfixes created in the Pharo > community -- should be pushed up to the tool developer. > > > > This way both worlds could get the best of both worlds: > > The tool developers still get bugfixes posted despite their original > implementation possibly being/becoming incompatible with Pharo. > > The Pharo community gets the freedom to become incompatible with > Squeak without loosing the benefits of ongoing tool development on > Squeak. > > > I am not saying this is the only solution, just describing what is a > 'field proven' model in the Linux community which seems to perfectly > implement the stated goals of Pharo. > > > >> >>> [...for version management] >>>> The vision is bytecode loader >>> >>> Pleas don't go there. Byte-code loading is a very nice-to-have in >>> deployment scenarios (lazy plugin loading, live update delivery to >>> deployed apps etc) but if there is one thing that using VW's Store >>> has >>> taught me it is that it definitely should not be part of a code >>> repository that is used for development code version management. >> >> This is in VW store is bad. I do not see why a package MCZ could not >> ship with >> a byte-code synchronized version of the source. Then we could have a >> stripper >> or a synchronizer that recompile the source code and produce new >> bytecode. > > > In my experience it 'poisons' the repository with packages that load > fine as bytecode but fail to load as source. > Mostly in 'auto brain surgery' scenarios where the /source/ should > contain more load ordering hints (but never attains that level because > the binary version hides these bugs). > > I reiterate that VW shows that source loading is fast enough -- even > for rather large updates. Ok so this is a good news. > So in my opinion 'fast enough' source loading should be attained > first, and bin-loading should be added later as an option (and > probably not in the code repository but perhaps in a cache in front of > such a repository, or maybe sideways as part of a build process). yes this is also an alternative. >> we will start by fixing packageInfo > > :-) right! > > > > R > - > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 6, 2009

Re: [Pharo-project] Squeak Forks Popularity & Trends Estimate

by StÃ©phane Ducasse

On Jul 6, 2009, at 9:33 PM, Hernan Wilkinson wrote: > Hi Stef, > have you thought about have not only first class instance variables > but first class variables? (no matter the scope). yes this was included. Now we want to really experiment and provide a real and working solution. I just mentioned that because Smalltalk deserves a better instantiation. :) > I think that would be interesting... observers on variables would > be pretty easy to implement, type inference (or type > recollection)... not sure about the trade-off cost/convenience, We did a simple implementation with marcus and the implementation we came up with did not have **any** runtime penalties. Now the classBuilder is so brittle that to make sure that we would have a robust implementation we would have to rewrite it and this is a real nightmare... look at the comment. for now we just created an extra instance variable that serves to allocate our instances :) > but looks interesting... accessing local variables could be made > sending messages to thisContext... anyway, just an idea. so far having plain well working first class instance/class variable would be a really good achiemenet with a good mop. Would be great. Imagine people could implement tweak like field without requiring copying the compiler and adding XML syntax :) > > On Mon, Jul 6, 2009 at 6:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > Hi nevin > > our goal is not predominancy :) It was never. I would be happy that > squeak offers a really good multimedia > platform. Our goal is to deliver good open source smalltalk. > Our goal is to get agile, rethink the system, use good software > engineering practices (systematic smallLnt rules), > tests.... > We want to propose/accept/evaluate new solutions: > first class package, > first class instance variables, better refactoring support, > may be modules, security, new compiler.... > > Smalltalk deserves a clean and powerful implementation and > we will work on that hard. > > Stef > > PS: you can forward this answer to squeak-dev if you feel the need. > > On Jul 6, 2009, at 3:17 AM, Nevin Pratt wrote: > > > There's no right or wrong answer to the following three questions. > > And, > > every response is meaningful, because it helps reveal the general > > sense > > of direction that the community is feeling. > > > > *********************** > > Question #1: Of the various Squeak forks (such as Croquet, Pharo, > > etc.), > > what is your feeling of their relative popularities at this point in > > time, and how does that compare with the current popularity of the > > base > > Squeak distribution? > > > > Question #2: This is related to the above-- what is your feeling of > > the > > relative popularity *trend* of each of the forks, and how does that > > compare with your feeling of the *trend* of the future popularity of > > the > > base Squeak distribution? > > > > Question #3: What is your justification for your answers to the > above > > two questions? > > ************************ > > > > I'll begin with my own answers... > > > > ...I'm beginning to feel like the Pharo fork currently now has maybe > > 50% > > or more of the popularity of the base Squeak distro, and I'm > beginning > > to feel like Pharo is headed to become the dominant distribution in > > the > > future, surpassing the original Squeak distro. And I base that > > feeling > > on several observations: > > > > 1. The email traffic comparison on the "Pharo-project" email list > > compared to the email traffic on "The general-purpose Squeak > > developers > > list", and the observed trend in such traffic. > > > > 2. The number of developers posting on the Pharo-project email list. > > > > 3. The specific developers posting on the Pharo-project email list > > (known Squeakers who have contributed heavily to Squeak in the > past). > > > > 4. The fact that Seaside development has moved to Pharo. > > > > At one time I wondered if Croquet would become the dominant Squeak > > fork, > > for the simple reason that it had a business organization > "officially" > > supporting it, similar to what Squeak had in the Disney days. But > > now I > > think I would bet my money on Pharo. > > > > What do you think? And why? > > > > Also, remember, there's certainly nothing wrong with several > > "dominant" > > forks existing. But of those, one of them will still be the most > > popular overall. And I'm curious about thoughts of which one that > is, > > and which one that will become, and why you think so. > > > > Nevin > > > > > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 6, 2009