- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Image overwrite warning

by StÃ©phane Ducasse

thanksssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss On Jul 7, 2009, at 12:17 PM, Gary Chambers wrote: > Yes, the MenuItemMorph submenu marker was reinitialized to be properly > transparent/black whereas, oddly, it was transparent/nearly-black. > > This highlighted an error in the Polymorph code (need to copy the form > before mapping the black to the string colour, which depends on > selection > state for a menu item). > > I'll release a new version on SqueakSource now... > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, July 07, 2009 11:00 AM > Subject: Re: [Pharo-project] Image overwrite warning > > >> >> 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 > > > _______________________________________________ > 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 Gary Chambers

Yes, the MenuItemMorph submenu marker was reinitialized to be properly transparent/black whereas, oddly, it was transparent/nearly-black. This highlighted an error in the Polymorph code (need to copy the form before mapping the black to the string colour, which depends on selection state for a menu item). I'll release a new version on SqueakSource now... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, July 07, 2009 11:00 AM Subject: Re: [Pharo-project] Image overwrite warning > > 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

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