September 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Igor Stasenko

2008/9/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > sounds cool > I have the eyes blinking of excitment :) > But I'm on mac :) You should try it. There are much more support for Macs than for windoze in these changesets. I had to add own Win32 specific subclass to make it working on windoze. My wish behind all of this is to provide clean separation between core VM and UI. Then, in Hydra each image could create and manage own windows. I just installed an Ubuntu, lets see how far i can get with building squeak VM + freetype on it. I never tried to build squeak on linux, but i expect it will be much easier than on windows. > Stef > On Sep 14, 2008, at 9:13 AM, Igor Stasenko wrote: > >> Thing was even easier than i first thought. >> >> I installed the changesets from here: >> ftp://ftp.smalltalkconsulting.com/experimental/Ffenestri/ >> >> Ffenestri-b-2-WindowProxies.3.cs >> Ffenestri-b-3-MultiHostWindows-Sunits.1.cs >> Ffenestri-b-3-MultiHostWindows.1.cs >> Ffenestri-b-4-Events-Morphic.1.cs >> >> And did few own changes (see attachment). >> >> It can render morphic in a window created by hostwindow plugin. >> The fix was, to remove a code which ignoring the events from non-main >> window :) >> >> Now, the goal is to create some kind of Display manager, refactor some >> code to associate an instance of PasteUpMorph with Display instance. >> Get rid of all direct references to Display - replace it by self >> defaultDisplay. (or self currentDisplay). >> >> and dispatch event handling & drawing based on targeted window/display. >> I hope someone could help me with that refactoring.. I tried to make a >> batch for replacing Display refs to message send, but failed. I'm not >> very good in refactoring tools.. >> I tried to replace text in all methods with Display: >> (CompiledMethod allInstances select: [:each | each literals >> anySatisfy: [:lit | lit isVariableBinding and: [lit key == #Display] >> ]]) >> But refactoring based on text source is error prone, it would be good >> to use RB refactoring to make it precisely. >> >> >> On windoze almost everything is functional - of course there is some >> visual glitches, but code is stable and not crashing image even when >> you'll save the image with replaced Display! >> >> Try the code yourself. Just file in the changes, and then do: >> >> DisplayHostWindow installAsDisplay >> >> and when you done: >> >> Display uninstall >> >> to revert to usual Display >> >> 2008/9/13 Igor Stasenko <siguctua(a)gmail.com>: >>> >>> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>>> On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote: >>>> >>>>> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>> >>>>>> this sounds interesting. >>>>>> But I think that this is important to still be able to not rely on >>>>>> external >>>>>> libraries when you want. >>>>>> so what is the exact difference between having it for free or optional >>>>>> - ? that you need to implement the primitive on platform where you >>>>>> do >>>>>> not need? >>>>>> - ? that the system is not layered in consequence? >>>>> >>>>> I think both. Having it 'for free' leads developers to think that they >>>>> can use it anytime, anywhere, like in String>>showProgressBar. Which >>>>> from my POV is complete stupidity. And now just check different >>>>> mailing lists and count complains about unable to getting rid of such >>>>> 'free' uses, like asking for user input or showing warnings in >>>>> headless image :) >>>> >>>> sure this is something that we should fix from an infrastructural point >>>> of >>>> view using a notification system. >>>> At the end we should not that PopUpMenu everywhere but only in one place >>>> in >>>> the Plafform >>>> code. >>>> >>>>> I don't want it 'for free', but instead, i want that language should >>>>> ask for it, and then, if VM could provide it - start using it. >>>>> Instead of having 'position & size & fullscreen flag' hanging around >>>>> in VM -obviously, with good design, this should be completely at >>>>> language side. >>>>> >>>>>> Did you check the work made around "ffnestraria" ? >>>>> >>>>> Surely, this could be taken as a initial base for new plugin. >>>>> But, as it reads on http://wiki.squeak.org/squeak/3862 : >>>>> >>>>> This architecture is for the lowest levels of the system, the virtual >>>>> machine and dungeon levels of the image. NO support yet exists for >>>>> Morphic since there is a vast amount of code and class cleanup needed. >>>> >>>> Yes I think that we should go slowly but removing a lot of morphic cruft >>>> will >>>> help. >>>> >>>>> >>>>> Tweak has been our sole higher level target thus far since it is >>>>> somewhat less broken, not to mention the target of our main project >>>>> remit. >>>>> >>>>> Since Pharo now actively adressing different Morphic issues, it would >>>>> be good for those who doing it (hello Gary) to keep this idea in mind. >>>> >>>> Yes >>>> >>>>> On embedded systems you don't have a 'window', you just have a >>>>> display. But on PCs, operating system can provide you many windows , >>>>> which can play role as displays. What is bad, that at language side >>>>> you don't have a notion about this, as well as it don't have notion >>>>> whether keys/mouse are present or not. >>>>> I think this should be represented by concrete classes, which can >>>>> answer things like: >>>>> - hasKeyboard(s) >>>>> - hasMouse(s) >>>>> - hasDisplay >>>>> - hasWindowing >>>>> >>>>> for instance, on windoze, you can use a real display using two >>>>> approached: >>>>> - one can prefer using a display (which covers a whole area of >>>>> screen), and should be allowed to control its resolution (if >>>>> possible). >>>>> - another one can rather use windowing and treat separate native >>>>> windows as separate displays. >>>>> >>>>>> Then what is important is to have good more then proof of concepts. >>>>>> This is sometimes that we would be interested in. >>>>>> >>>>>> Stef >>>>>> >>>>> >>>>> >>> >>> Concerning Display & Forms & BitBlt with connection with host window: >>> We already have everything we need in VM!! >>> The only thing which is required to wire things up. >>> >>> Here is components which need to be merged (to work together): >>> - SurfacePlugin & HostWindowPlugin on VM side >>> - DisplayScreen class need to be refactored to create new host window >>> and ask for its surface (which in own turn should be registered by >>> HostWindowPlugin using SurfacePlugin interface). >>> >>> There are also an example in >>> platforms/Cross/plugins/ExampleSurfacePlugin , how to create & >>> register own surface >>> and how to use it at language side. >>> >>> So, we really can throw out almost all windowing stuff from core VM, >>> leaving HostWindowPlugin to handle things. >>> >>> Initially, i guess, that most changes will affect the Display var and >>> DisplayScreen class. >>> For headless mode , a Display could be replaced by >>> NoDisplayScreen - which simply ignoring all calls >>> LazyDisplayScreen - which sits in Display global var until first >>> drawing attempt, and then creates a window and replacing itself by >>> working DisplayScreen. >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> <HostWindowsDisplay.1.cs>_______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Sept. 14, 2008

[Pharo-project] Re: Re: how to load sophie

by Andrew Tween

I am running Sophie on Windows. Perhaps the menus are different on a Mac? "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote in message news:96099EE9-95A6-46C7-B954-ACA5EE36C751@inria.fr... I do not have an exit menu under file :( I took the latest version and I get Stef On Sep 12, 2008, at 9:14 PM, Andrew Tween wrote: > > "StÃ©phane Ducasse" <Stephane.Ducasse(a)inria.fr> wrote > in message > news:7916FF5C-0CA0-4562-A69F-65B4B54C8067@inria.fr ... >> Hi mike >> >> I would like to browse the code but not only from MC but in a real >> image. >> How do I get sophie loaded (even in 3.8 or others). >> In particular I would like to see how URI are used in the code. > > If you don't want to install it all from scratch then... > > If you download Sophie from www.sophieproject.org > (http://www.sophieproject.org/download ) > and run it, then the File>>Exit menu item will close the Sophie > application but leave the Squeak image running so you can open browsers > etc. > > Cheers, > Andy > >> >> Setf > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 14, 2008

[Pharo-project] Re: Re: Re: Building VM Freetype

by Andrew Tween

"Igor Stasenko" <siguctua(a)gmail.com> wrote in message news:4a5f5f320809130714u60fe4d6at851dddf92cea4ffd@mail.gmail.com... >I rebuilt VM with changeset & uploaded it replacing old .zip. > > FreeTypeSettings current > clearBitBltSubPixelAvailable; > bitBltSubPixelAvailable > > prints: true Thanks. Everything is working now Andy > > 2008/9/13 Igor Stasenko > <siguctua(a)gmail.com>: >> 2008/9/13 Andrew Tween <amtween(a)hotmail.com>: >>> Hi, >>> "Igor Stasenko" <siguctua(a)gmail.com> wrote >>> in message >>> news:4a5f5f320809130455h6403bc01ne6f8c7638c02cbde@mail.gmail.com... >>>> >>>> I uploaded the binaries + freetype plugin platform sources under >>>> "squeak VM + freetype" cat: >>>> https://gforge.inria.fr/frs/?group_id=1299 >>> >>> Cool. >>> The FreeType plugin seems to work great. >>> I notice that you have used FreeType 2.3.7 - that's good, the previous >>> plugin used 2.2.1 which is quite old now. >>> >>> However, the sub-pixel anti-aliasing isn't working. >>> This can be tested by evaluating ... >>> >>> FreeTypeSettings current >>> clearBitBltSubPixelAvailable; >>> bitBltSubPixelAvailable >>> >>> It answers true if the new BitBlt combination rule 41 is present and >>> working; false otherwise. >>> >> >>> Did you install FreeTypeBitBltSimulation.1.cs >>> (http://www.zen61439.zen.co.uk/bak/bitBlt_plugin_enhancements/FreeTypeBitBlt…) >>> into your VMMaker image? >>> If you did, then it is possible that the changeset isn't compatible with >>> the >>> latest VMMaker, and I'll look into it. >>> >> oh..sorry, i forgot to load the changeset for BitBlt. >> >>> Cheers, >>> Andy >>> >>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig.

Sept. 14, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by StÃ©phane Ducasse

sounds cool I have the eyes blinking of excitment :) But I'm on mac :) Stef On Sep 14, 2008, at 9:13 AM, Igor Stasenko wrote: > Thing was even easier than i first thought. > > I installed the changesets from here: > ftp://ftp.smalltalkconsulting.com/experimental/Ffenestri/ > > Ffenestri-b-2-WindowProxies.3.cs > Ffenestri-b-3-MultiHostWindows-Sunits.1.cs > Ffenestri-b-3-MultiHostWindows.1.cs > Ffenestri-b-4-Events-Morphic.1.cs > > And did few own changes (see attachment). > > It can render morphic in a window created by hostwindow plugin. > The fix was, to remove a code which ignoring the events from non- > main window :) > > Now, the goal is to create some kind of Display manager, refactor some > code to associate an instance of PasteUpMorph with Display instance. > Get rid of all direct references to Display - replace it by self > defaultDisplay. (or self currentDisplay). > > and dispatch event handling & drawing based on targeted window/ > display. > I hope someone could help me with that refactoring.. I tried to make a > batch for replacing Display refs to message send, but failed. I'm not > very good in refactoring tools.. > I tried to replace text in all methods with Display: > (CompiledMethod allInstances select: [:each | each literals > anySatisfy: [:lit | lit isVariableBinding and: [lit key == #Display] > ]]) > But refactoring based on text source is error prone, it would be good > to use RB refactoring to make it precisely. > > > On windoze almost everything is functional - of course there is some > visual glitches, but code is stable and not crashing image even when > you'll save the image with replaced Display! > > Try the code yourself. Just file in the changes, and then do: > > DisplayHostWindow installAsDisplay > > and when you done: > > Display uninstall > > to revert to usual Display > > 2008/9/13 Igor Stasenko <siguctua(a)gmail.com>: >> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote: >>> >>>> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> >>>>> this sounds interesting. >>>>> But I think that this is important to still be able to not rely on >>>>> external >>>>> libraries when you want. >>>>> so what is the exact difference between having it for free or >>>>> optional >>>>> - ? that you need to implement the primitive on platform >>>>> where you >>>>> do >>>>> not need? >>>>> - ? that the system is not layered in consequence? >>>> >>>> I think both. Having it 'for free' leads developers to think that >>>> they >>>> can use it anytime, anywhere, like in String>>showProgressBar. >>>> Which >>>> from my POV is complete stupidity. And now just check different >>>> mailing lists and count complains about unable to getting rid of >>>> such >>>> 'free' uses, like asking for user input or showing warnings in >>>> headless image :) >>> >>> sure this is something that we should fix from an infrastructural >>> point of >>> view using a notification system. >>> At the end we should not that PopUpMenu everywhere but only in one >>> place in >>> the Plafform >>> code. >>> >>>> I don't want it 'for free', but instead, i want that language >>>> should >>>> ask for it, and then, if VM could provide it - start using it. >>>> Instead of having 'position & size & fullscreen flag' hanging >>>> around >>>> in VM -obviously, with good design, this should be completely at >>>> language side. >>>> >>>>> Did you check the work made around "ffnestraria" ? >>>> >>>> Surely, this could be taken as a initial base for new plugin. >>>> But, as it reads on http://wiki.squeak.org/squeak/3862 : >>>> >>>> This architecture is for the lowest levels of the system, the >>>> virtual >>>> machine and dungeon levels of the image. NO support yet exists for >>>> Morphic since there is a vast amount of code and class cleanup >>>> needed. >>> >>> Yes I think that we should go slowly but removing a lot of morphic >>> cruft >>> will >>> help. >>> >>>> >>>> Tweak has been our sole higher level target thus far since it is >>>> somewhat less broken, not to mention the target of our main project >>>> remit. >>>> >>>> Since Pharo now actively adressing different Morphic issues, it >>>> would >>>> be good for those who doing it (hello Gary) to keep this idea in >>>> mind. >>> >>> Yes >>> >>>> On embedded systems you don't have a 'window', you just have a >>>> display. But on PCs, operating system can provide you many >>>> windows , >>>> which can play role as displays. What is bad, that at language side >>>> you don't have a notion about this, as well as it don't have notion >>>> whether keys/mouse are present or not. >>>> I think this should be represented by concrete classes, which can >>>> answer things like: >>>> - hasKeyboard(s) >>>> - hasMouse(s) >>>> - hasDisplay >>>> - hasWindowing >>>> >>>> for instance, on windoze, you can use a real display using two >>>> approached: >>>> - one can prefer using a display (which covers a whole area of >>>> screen), and should be allowed to control its resolution (if >>>> possible). >>>> - another one can rather use windowing and treat separate native >>>> windows as separate displays. >>>> >>>>> Then what is important is to have good more then proof of >>>>> concepts. >>>>> This is sometimes that we would be interested in. >>>>> >>>>> Stef >>>>> >>>> >>>> >> >> Concerning Display & Forms & BitBlt with connection with host window: >> We already have everything we need in VM!! >> The only thing which is required to wire things up. >> >> Here is components which need to be merged (to work together): >> - SurfacePlugin & HostWindowPlugin on VM side >> - DisplayScreen class need to be refactored to create new host window >> and ask for its surface (which in own turn should be registered by >> HostWindowPlugin using SurfacePlugin interface). >> >> There are also an example in >> platforms/Cross/plugins/ExampleSurfacePlugin , how to create & >> register own surface >> and how to use it at language side. >> >> So, we really can throw out almost all windowing stuff from core VM, >> leaving HostWindowPlugin to handle things. >> >> Initially, i guess, that most changes will affect the Display var and >> DisplayScreen class. >> For headless mode , a Display could be replaced by >> NoDisplayScreen - which simply ignoring all calls >> LazyDisplayScreen - which sits in Display global var until first >> drawing attempt, and then creates a window and replacing itself by >> working DisplayScreen. >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > <HostWindowsDisplay. > 1.cs>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 14, 2008

Re: [Pharo-project] show bytecode menu -> DNU

by StÃ©phane Ducasse

excellent I will harvest after my nap (I'm dead and it is only 12 :( Stef On Sep 14, 2008, at 10:56 AM, Marcus Denker wrote: > > On 12.09.2008, at 20:22, StÃ©phane Ducasse wrote: > >> Hi >> >> if one of you could have a look at the menu item show bytecode. >> > > this one fixes it: > > > > <PluggableTextMorph-showBytecodes.st> > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 14, 2008

Re: [Pharo-project] show bytecode menu -> DNU

by Marcus Denker

On 12.09.2008, at 20:22, StÃ©phane Ducasse wrote: > Hi > > if one of you could have a look at the menu item show bytecode. > this one fixes it: -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 14, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Igor Stasenko

Thing was even easier than i first thought. I installed the changesets from here: ftp://ftp.smalltalkconsulting.com/experimental/Ffenestri/ Ffenestri-b-2-WindowProxies.3.cs Ffenestri-b-3-MultiHostWindows-Sunits.1.cs Ffenestri-b-3-MultiHostWindows.1.cs Ffenestri-b-4-Events-Morphic.1.cs And did few own changes (see attachment). It can render morphic in a window created by hostwindow plugin. The fix was, to remove a code which ignoring the events from non-main window :) Now, the goal is to create some kind of Display manager, refactor some code to associate an instance of PasteUpMorph with Display instance. Get rid of all direct references to Display - replace it by self defaultDisplay. (or self currentDisplay). and dispatch event handling & drawing based on targeted window/display. I hope someone could help me with that refactoring.. I tried to make a batch for replacing Display refs to message send, but failed. I'm not very good in refactoring tools.. I tried to replace text in all methods with Display: (CompiledMethod allInstances select: [:each | each literals anySatisfy: [:lit | lit isVariableBinding and: [lit key == #Display] ]]) But refactoring based on text source is error prone, it would be good to use RB refactoring to make it precisely. On windoze almost everything is functional - of course there is some visual glitches, but code is stable and not crashing image even when you'll save the image with replaced Display! Try the code yourself. Just file in the changes, and then do: DisplayHostWindow installAsDisplay and when you done: Display uninstall to revert to usual Display 2008/9/13 Igor Stasenko <siguctua(a)gmail.com>: > 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote: >> >>> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>>> this sounds interesting. >>>> But I think that this is important to still be able to not rely on >>>> external >>>> libraries when you want. >>>> so what is the exact difference between having it for free or optional >>>> - ? that you need to implement the primitive on platform where you >>>> do >>>> not need? >>>> - ? that the system is not layered in consequence? >>> >>> I think both. Having it 'for free' leads developers to think that they >>> can use it anytime, anywhere, like in String>>showProgressBar. Which >>> from my POV is complete stupidity. And now just check different >>> mailing lists and count complains about unable to getting rid of such >>> 'free' uses, like asking for user input or showing warnings in >>> headless image :) >> >> sure this is something that we should fix from an infrastructural point of >> view using a notification system. >> At the end we should not that PopUpMenu everywhere but only in one place in >> the Plafform >> code. >> >>> I don't want it 'for free', but instead, i want that language should >>> ask for it, and then, if VM could provide it - start using it. >>> Instead of having 'position & size & fullscreen flag' hanging around >>> in VM -obviously, with good design, this should be completely at >>> language side. >>> >>>> Did you check the work made around "ffnestraria" ? >>> >>> Surely, this could be taken as a initial base for new plugin. >>> But, as it reads on http://wiki.squeak.org/squeak/3862 : >>> >>> This architecture is for the lowest levels of the system, the virtual >>> machine and dungeon levels of the image. NO support yet exists for >>> Morphic since there is a vast amount of code and class cleanup needed. >> >> Yes I think that we should go slowly but removing a lot of morphic cruft >> will >> help. >> >>> >>> Tweak has been our sole higher level target thus far since it is >>> somewhat less broken, not to mention the target of our main project >>> remit. >>> >>> Since Pharo now actively adressing different Morphic issues, it would >>> be good for those who doing it (hello Gary) to keep this idea in mind. >> >> Yes >> >>> On embedded systems you don't have a 'window', you just have a >>> display. But on PCs, operating system can provide you many windows , >>> which can play role as displays. What is bad, that at language side >>> you don't have a notion about this, as well as it don't have notion >>> whether keys/mouse are present or not. >>> I think this should be represented by concrete classes, which can >>> answer things like: >>> - hasKeyboard(s) >>> - hasMouse(s) >>> - hasDisplay >>> - hasWindowing >>> >>> for instance, on windoze, you can use a real display using two approached: >>> - one can prefer using a display (which covers a whole area of >>> screen), and should be allowed to control its resolution (if >>> possible). >>> - another one can rather use windowing and treat separate native >>> windows as separate displays. >>> >>>> Then what is important is to have good more then proof of concepts. >>>> This is sometimes that we would be interested in. >>>> >>>> Stef >>>> >>> >>> > > Concerning Display & Forms & BitBlt with connection with host window: > We already have everything we need in VM!! > The only thing which is required to wire things up. > > Here is components which need to be merged (to work together): > - SurfacePlugin & HostWindowPlugin on VM side > - DisplayScreen class need to be refactored to create new host window > and ask for its surface (which in own turn should be registered by > HostWindowPlugin using SurfacePlugin interface). > > There are also an example in > platforms/Cross/plugins/ExampleSurfacePlugin , how to create & > register own surface > and how to use it at language side. > > So, we really can throw out almost all windowing stuff from core VM, > leaving HostWindowPlugin to handle things. > > Initially, i guess, that most changes will affect the Display var and > DisplayScreen class. > For headless mode , a Display could be replaced by > NoDisplayScreen - which simply ignoring all calls > LazyDisplayScreen - which sits in Display global var until first > drawing attempt, and then creates a window and replacing itself by > working DisplayScreen. > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Sept. 14, 2008

Re: [Pharo-project] Re: how to load sophie

by StÃ©phane Ducasse

I do not have an exit menu under file :( I took the latest version and I get Stef On Sep 12, 2008, at 9:14 PM, Andrew Tween wrote: > > "StÃ©phane Ducasse" <Stephane.Ducasse(a)inria.fr> wrote in message news:7916FF5C-0CA0-4562-A69F-65B4B54C8067@inria.fr > ... >> Hi mike >> >> I would like to browse the code but not only from MC but in a real >> image. >> How do I get sophie loaded (even in 3.8 or others). >> In particular I would like to see how URI are used in the code. > > If you don't want to install it all from scratch then... > > If you download Sophie from www.sophieproject.org (http://www.sophieproject.org/download > ) > and run it, then the File>>Exit menu item will close the Sophie > application but leave the Squeak image running so you can open > browsers etc. > > Cheers, > Andy > >> >> Setf > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 13, 2008

[Pharo-project] [ANN] some updates 10062 -> 10070

by StÃ©phane Ducasse

------------------------------------------------------ update10063 - add #numberOfMethods - fix Behavior>>linesOfCode to be traits-aware - create all morphic events with basicNew to save the send of #initialize - optimized path for Morph>>#fillStyle for emoty morph-extension. (Called a lot) - optimized path for Morph>>#shadowOffset for empy morphExtension (called a lot) - remove call to "self flag #arNote" in Morph>>#transformedFrom: (called on mouse-move) - remove MorphEvent>>#convertFromObsolete - remove turtle trails check from Morph>>#drawOn: - remove more calls to #flag: - some simple code simplification (e.g. call #methods, not #methodDict values, more isEmpty) - remove AbstractEvent>>#saveChangeNotificationAsSARFileWithNumber: ------------------------------------------------------ update10064 -0007136: [BUG] LinkedList add:after: fails to update lastLink -0007156: Behavior>>#initialize sends #superclass: which can cause VM crash - delete #isValidWonderlandTexture - fix TClassAndTraitDescription>>#methods to return the methods of a class or trait - add #localMethods to return methods defined in a class, not included by a trait. -7147 Parser-removeUnusedTemps -0006503: RunArray cant be created through #new: ------------------------------------------------------ update10065 Fixing Transcript and Smalltalk to return themselves when printed :) ------------------------------------------------------ update10066 tally it integration http://bugs.squeak.org/view.php?id=1014 ------------------------------------------------------ update10067 Cleaning html fileout removal http://code.google.com/p/pharo/issues/detail?id=115 ------------------------------------------------------ update10068 - ClassBuilder fixes and tests from Noury Bouraqadi Now instance variable names cannot be uppercased and classVariables lowered. - Refactoring engine tests commented by alexandre bergel to let the test builder work - PackageInfo better printOn: + mostSpecificPackageOf: - Tools package loaded (was forgotten before) with tally enh of alexandre Bergel ------------------------------------------------------ update10070 Remove TextSqkLink TextProjectSqkLink

Sept. 13, 2008

Re: [Pharo-project] About removing TextSqkLink and TextSqkProjectLink

by StÃ©phane Ducasse

I got nervous :) so 10070 removes them :) Stef On Sep 13, 2008, at 4:39 PM, StÃ©phane Ducasse wrote: > Hi guys > > I wanted to know you point of view. > I fall on TextSqkLink and TextSqkProjectLink > that it would be good to remove them. > > What your point of view on that? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 13, 2008