Towards clean unloading Morphic (an idea)
Locked
Towards clean unloading Morphic (an idea)
 
|
Hello,
i just thought, that in order to get down to a minimal kernel image, it would be nice to move all Morphic globals into a shared pool. Things like, World, ActiveWorld could be placed into a MorphicPool class. Then we can make an easy transition 1. add this pool to classes which using that global & recompile them 2. for classes, which should have no dependency from Morphic, use a messages like Object >> currentWorld ^ (Smalltalk at: #MorphicPool ifAbsent: [ self error: 'bummer' ]) currentWorld . Then, i hope, you can unload the Morphic using MC and it will leave no trace in an image (or at least less trace than usual ;). Same could be applied to Graphics package (to get rid a Display global) -- Best regards, Igor Stasenko AKA sig. |
Re: Towards clean unloading Morphic (an idea)
|
|
Hi Igor,
On Thu, May 20, 2010 at 2:47 AM, Igor Stasenko <[hidden email]> wrote: Hello, Good idea. This is a little like a poor man's namespaces. It suggests the following cheap hack namespaces:
Inside Smalltalk all the Morphic class names are #'Morphic.Morph' #'Morphic.TheWorldMenu' etc. Inside the MorphicNamespace shared pool they are #Morph #TheWorldMenu etc. The bindings for these would have to be shared between Smalltalk and the MorphicNamespace shared pool. I guess something like a smart subclass of VariableBinding that when decompiling printed itself differently depending on whether its home pool was in scope or not might make the sleight-of-hand invisible. You'd also need to hack the browsers to prune the Morphic. prefix when the selected category began with Morphic. Is this a primrose path, a slippery slope or a worth-while experiment?
best Eliot
|
Re: Towards clean unloading Morphic (an idea)
|
|
On Thu, May 20, 2010 at 9:43 AM, Eliot Miranda <[hidden email]> wrote: Hi Igor, Provided that one can parse e.g. Object subclass: #'MorphicNamespace.Morph' instanceVariableNames: 'bounds owner submorphs fullBounds color extension'
classVariableNames: 'EmptyArray' poolDictionaries: '' category: 'Morphic-Kernel'
then creating a namespace's shared pool and adding a class/global to the right namespace shared pool might be able to be done entirely in SystemDictionary>>at:put:
at: aKey put: anObject "Override from Dictionary to check Undeclared and fix up references to undeclared variables."
| index element | (self includesKey: aKey) ifFalse: [self declare: aKey from: Undeclared.
self flushClassNameCache]. super at: aKey put: anObject. >> self checkForAdditionOfNamespaceKey: aKey.
^ anObject checkForAdditionOfNamespaceKey: aKey | namespaceName |
(aKey includes: $.) ifFalse: [^self]. (namespaceName := aKey copyUpTo: $.) isEmpty ifTrue: [self error: 'invalid namespace name']. namespaceName := namespaceName asSymbol.
namespace := (self at: namespaceName ifAbsent: []) ifNil: [self at: namespaceName put: SharedPool new]
ifNotNil: [:maybeSharedPool| maybeSharedPool isSharedPool ifFalse:
[self error: 'namespace name refers to non-namespace']. maybeSharedPool].
namespace adoptBinding: (self bindingFor: aKey) or some such. Removal in removeKey:ifAbsent:.
|
Re: Towards clean unloading Morphic (an idea)
|
|
In reply to this post by Igor Stasenko
On 5/20/2010 2:47 AM, Igor Stasenko wrote:
> Then we can make an easy transition > 1. add this pool to classes which using that global& recompile them > > 2. for classes, which should have no dependency from Morphic, > use a messages like > > Object>> currentWorld > ^ (Smalltalk at: #MorphicPool ifAbsent: [ self error: 'bummer' ]) > currentWorld . I think that's the wrong way to deal with the problem. A polymorphic implementation via Project works much better, i.e., Object>>currentWorld ^Project current world and then Project>>world "No worlds here" ^nil MorphicProject>>world ^world etc. Then you don't need any globals at all. > Then, i hope, you can unload the Morphic using MC and it will leave no > trace in an image (or at least less trace than usual ;). > > Same could be applied to Graphics package (to get rid a Display global) And the same applies. The pattern should be "Project current display". Cheers, - Andreas |
Re: Towards clean unloading Morphic (an idea)
|
|
In reply to this post by Eliot Miranda-2
On Thu, May 20, 2010 at 9:43 AM, Eliot Miranda <[hidden email]> wrote: Hi Igor, Or of course a derivative reinvention. I'm ignorant of other namespace attempts in Squeak. Has something close to the above scheme been tried before?
|
Re: Towards clean unloading Morphic (an idea)
|
|
On 5/20/2010 10:08 AM, Eliot Miranda wrote:
> Or of course a derivative reinvention. I'm ignorant of other namespace > attempts in Squeak. Has something close to the above scheme been tried > before? Clearly you are ;-) Entire wars have been waged about whether it should be period or colon. - A. |
Re: Towards clean unloading Morphic (an idea)
|
|
On 05/20/2010 07:11 PM, Andreas Raab wrote:
> On 5/20/2010 10:08 AM, Eliot Miranda wrote: >> Or of course a derivative reinvention. I'm ignorant of other namespace >> attempts in Squeak. Has something close to the above scheme been tried >> before? > > Clearly you are ;-) Entire wars have been waged about whether it should > be period or colon. Ehm... Eliot, what you describe sound very close to my Namespace implementation available on SqueakMap and also written up: http://swiki.krampe.se/gohu/27 ...see especally: http://swiki.krampe.se/gohu/32 And I think period is bad, it blends too much with sequencing, I personally think double colon looks the best and stands out. And is used in both C++ and Perl AFAIK. Also, one of the GSoC projects is "cross platform namespaces", but I am not yet sure which direction that will take. regards, Göran PS. I am not "pushing" for my Namespaces solution/implementation because I don't generally feel "the pain", but I do tend to remind people about it when the subject comes up. Perhaps in a few more years people will start warming up :) |
Re: Towards clean unloading Morphic (an idea)
|
|
Hi Göran,
2010/5/20 Göran Krampe <[hidden email]>
Cool. I'll take a look. It seems to me that this approach is very light-weight w.r.t. system changes. Monticello works unaffected, etc. There are minor tweaks to SystemDictionary and whatever subclass of SharedPool a NamespaceSharedPool is, but that's it. It appears one doesn't even have to modify the compiler. e.g. imports can be handled in NamespaceSharedPool. So I like the minimality.
best Eliot PS. I am not "pushing" for my Namespaces solution/implementation because I don't generally feel "the pain", but I do tend to remind people about it when the subject comes up. Perhaps in a few more years people will start warming up :) |
Re: Towards clean unloading Morphic (an idea)
|
|
In reply to this post by Andreas.Raab
On 20 May 2010 20:08, Andreas Raab <[hidden email]> wrote:
> On 5/20/2010 2:47 AM, Igor Stasenko wrote: >> >> Then we can make an easy transition >> 1. add this pool to classes which using that global& recompile them >> >> 2. for classes, which should have no dependency from Morphic, >> use a messages like >> >> Object>> currentWorld >> ^ (Smalltalk at: #MorphicPool ifAbsent: [ self error: 'bummer' ]) >> currentWorld . > > I think that's the wrong way to deal with the problem. A polymorphic > implementation via Project works much better, i.e., > > Object>>currentWorld > ^Project current world > (Smalltalk at: #Project ) blahblahblah because Smalltalk, is the only global, which i am sure will stay with us forever :) > and then > > Project>>world > "No worlds here" > ^nil > > MorphicProject>>world > ^world > > etc. Then you don't need any globals at all. > >> Then, i hope, you can unload the Morphic using MC and it will leave no >> trace in an image (or at least less trace than usual ;). >> >> Same could be applied to Graphics package (to get rid a Display global) > > And the same applies. The pattern should be "Project current display". > Using a Project as a name is a bit counterintuitive. Why it has to be responsible for answering an instance of Display or morphic world? I know, it is historically been so, but i wonder if there other (more appropriate) dispathes. Smalltalk graphics display Smalltalk ui morphicWorld > Cheers, > - Andreas > > -- Best regards, Igor Stasenko AKA sig. |
Re: Towards clean unloading Morphic (an idea)
|
|
In reply to this post by Andreas.Raab
On 20 May 2010 20:11, Andreas Raab <[hidden email]> wrote:
> On 5/20/2010 10:08 AM, Eliot Miranda wrote: >> >> Or of course a derivative reinvention. I'm ignorant of other namespace >> attempts in Squeak. Has something close to the above scheme been tried >> before? > > Clearly you are ;-) Entire wars have been waged about whether it should be > period or colon. > Yeah, that's why i staying away from namespace topic, and why my idea maybe not-so elegant (comparing to namespaces), but completely compatible solution with current status-quo. > - A. > > -- Best regards, Igor Stasenko AKA sig. |
Re: Towards clean unloading Morphic (an idea)
|
|
In reply to this post by Igor Stasenko
On 5/20/2010 5:05 PM, Igor Stasenko wrote:
> On 20 May 2010 20:08, Andreas Raab<[hidden email]> wrote: >> I think that's the wrong way to deal with the problem. A polymorphic >> implementation via Project works much better, i.e., >> >> Object>>currentWorld >> ^Project current world >> > unless you wanna get rid of Project as well.. then you still have to write > (Smalltalk at: #Project ) blahblahblah > > because Smalltalk, is the only global, which i am sure will stay with > us forever :) What about removing #currentWorld instead? It seems to me that there's a boundary somewhere - if you're assuming "some" UI but not necessarily Morphic, it seems that vectoring it through Project current is the right approach. If you're assuming "no UI" and consequently, no class Project, it seems that at this point #currentWorld might have to go too. So I'd say, make Object>>currentWorld vector through Project current, based on the assumption that some UI will be there, and bundle Object>>currentWorld with Project so that if you unload one, you unload the other as well. That seems like a nice clean separation of concerns. >> And the same applies. The pattern should be "Project current display". >> > Indeed. Except that i'm not really happy with naming. > Using a Project as a name is a bit counterintuitive. I quite like the name. A "Project" generally context of some sorts; having it be the working context of your environment with windows, display, sensor, etc. makes sense to me. > Why it has to be responsible for answering an instance of Display > or morphic world? Err ... because we defined it to be that way? ;-) > I know, it is historically been so, but i wonder if there other (more > appropriate) dispathes. > > Smalltalk graphics display > Smalltalk ui morphicWorld I'll object to those two because they don't imply the presence of multiple displays or worlds. "Graphics" and "UI" sound like singletons to me; "projects" on the other hand can be many. Cheers, - Andreas |
Re: Towards clean unloading Morphic (an idea)
|
|
In reply to this post by Igor Stasenko
>And I think period is bad, it blends too much with sequencing, I
>personally think double colon looks the best and stands out. And is used >in both C++ and Perl AFAIK Double colon is also used in Smalltalk MT for Namespaces. Bye T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 |
Re: Towards clean unloading Morphic (an idea)
|
|
Am 2010-05-21 um 08:44 schrieb Torsten Bergmann: >> And I think period is bad, it blends too much with sequencing, I >> personally think double colon looks the best and stands out. And is used >> in both C++ and Perl AFAIK > > Double colon is also used in Smalltalk MT for Namespaces. … what about a slash? + makes for a good binary message NameSpaceA / SubspaceB / ClassC + Looks like a Path - May interfere with division Or, to be even more heretic, why not using » (Mac: Opt-Shift-\)? (Ok, I know, hard to input…) But, personally, I really would like NamespaceA»SuspaceB»ClassC So Long, -Tobias |
Re: Towards clean unloading Morphic (an idea)
|
|
On 05/21/2010 09:23 AM, Tobias Pape wrote:
> > Am 2010-05-21 um 08:44 schrieb Torsten Bergmann: > >>> And I think period is bad, it blends too much with sequencing, I >>> personally think double colon looks the best and stands out. And is used >>> in both C++ and Perl AFAIK >> >> Double colon is also used in Smalltalk MT for Namespaces. > > > … what about a slash? > + makes for a good binary message > NameSpaceA / SubspaceB / ClassC > + Looks like a Path > - May interfere with division If you start using syntax that includes "space" then you will get into syntactic problems. It clashes with message sending, but on the other hand, if you are indeed looking for *dynamic* namespaces then that is what you want. But then, as Dan Ingalls suggested, you wouldn't need any slash at all, it would just be: NameSpaceA SubspaceB ClassC ...now, my Namespace solution is *not* dynamic, so it is not message sending. It simply allows having the character $: in a Symbol and thus also in a global reference. And oh, my proposal was *not* hierarchical but a flat list - but it could be made hierarchical if needed, I just didn't feel the need. So: NameSpaceA::ClassC ...in my solution is just a global reference. regards, Göran |
Re: Towards clean unloading Morphic (an idea)
|
|
I think It's very good if Squeak namespaces will be compatiple with VisualWorks (it use dot).
2010/5/21 Göran Krampe <[hidden email]>
|
Re: Towards clean unloading Morphic (an idea)
|
|
On 21 May 2010 12:17, Denis Kudriashov <[hidden email]> wrote:
> I think It's very good if Squeak namespaces will be compatiple with > VisualWorks (it use dot). dot is ambiguous. { A.B.C.D. } P.S. guys can be get back to topic? i am almost 99% sure that just yet another namespaces discussion won't brings us any closer to practical solution > > 2010/5/21 Göran Krampe <[hidden email]> >> >> On 05/21/2010 09:23 AM, Tobias Pape wrote: >>> >>> Am 2010-05-21 um 08:44 schrieb Torsten Bergmann: >>> >>>>> And I think period is bad, it blends too much with sequencing, I >>>>> personally think double colon looks the best and stands out. And is >>>>> used >>>>> in both C++ and Perl AFAIK >>>> >>>> Double colon is also used in Smalltalk MT for Namespaces. >>> >>> >>> … what about a slash? >>> + makes for a good binary message >>> NameSpaceA / SubspaceB / ClassC >>> + Looks like a Path >>> - May interfere with division >> >> If you start using syntax that includes "space" then you will get into >> syntactic problems. It clashes with message sending, but on the other hand, >> if you are indeed looking for *dynamic* namespaces then that is what you >> want. But then, as Dan Ingalls suggested, you wouldn't need any slash at >> all, it would just be: >> >> NameSpaceA SubspaceB ClassC >> >> ...now, my Namespace solution is *not* dynamic, so it is not message >> sending. It simply allows having the character $: in a Symbol and thus also >> in a global reference. And oh, my proposal was *not* hierarchical but a flat >> list - but it could be made hierarchical if needed, I just didn't feel the >> need. So: >> >> NameSpaceA::ClassC >> >> ...in my solution is just a global reference. >> >> regards, Göran >> > > > > > -- Best regards, Igor Stasenko AKA sig. |
Re: Towards clean unloading Morphic (an idea)
|
|
The question is what you want Namespace for?
For having private classes vs public classes? For reducing global name clashes? For compiling/evaluating code in different environments (security?) This latest subject also is related to dynamically looked up globals. It also is related to the discussion from Gilad about files considered evil : if we are forced to give a full path for each class, then it's a little like we reintroduced something like a file system (thank you very much Tobias for making this obvious thru the / notation). Nicolas 2010/5/21 Igor Stasenko <[hidden email]>: > On 21 May 2010 12:17, Denis Kudriashov <[hidden email]> wrote: >> I think It's very good if Squeak namespaces will be compatiple with >> VisualWorks (it use dot). > > dot is ambiguous. > { A.B.C.D. } > > P.S. guys can be get back to topic? > i am almost 99% sure that just yet another namespaces discussion won't > brings us any closer to practical solution > >> >> 2010/5/21 Göran Krampe <[hidden email]> >>> >>> On 05/21/2010 09:23 AM, Tobias Pape wrote: >>>> >>>> Am 2010-05-21 um 08:44 schrieb Torsten Bergmann: >>>> >>>>>> And I think period is bad, it blends too much with sequencing, I >>>>>> personally think double colon looks the best and stands out. And is >>>>>> used >>>>>> in both C++ and Perl AFAIK >>>>> >>>>> Double colon is also used in Smalltalk MT for Namespaces. >>>> >>>> >>>> … what about a slash? >>>> + makes for a good binary message >>>> NameSpaceA / SubspaceB / ClassC >>>> + Looks like a Path >>>> - May interfere with division >>> >>> If you start using syntax that includes "space" then you will get into >>> syntactic problems. It clashes with message sending, but on the other hand, >>> if you are indeed looking for *dynamic* namespaces then that is what you >>> want. But then, as Dan Ingalls suggested, you wouldn't need any slash at >>> all, it would just be: >>> >>> NameSpaceA SubspaceB ClassC >>> >>> ...now, my Namespace solution is *not* dynamic, so it is not message >>> sending. It simply allows having the character $: in a Symbol and thus also >>> in a global reference. And oh, my proposal was *not* hierarchical but a flat >>> list - but it could be made hierarchical if needed, I just didn't feel the >>> need. So: >>> >>> NameSpaceA::ClassC >>> >>> ...in my solution is just a global reference. >>> >>> regards, Göran >>> >> >> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
Re: Towards clean unloading Morphic (an idea)
|
|
In reply to this post by Andreas.Raab
On Thu, May 20, 2010 at 08:08:34PM -0700, Andreas Raab wrote:
> On 5/20/2010 5:05 PM, Igor Stasenko wrote: > > >I know, it is historically been so, but i wonder if there other (more > >appropriate) dispathes. > > > >Smalltalk graphics display > >Smalltalk ui morphicWorld > > I'll object to those two because they don't imply the presence of > multiple displays or worlds. "Graphics" and "UI" sound like singletons > to me; "projects" on the other hand can be many. I like Igor's suggestion here. To me, the phrases "Smalltalk graphics" and "Smalltalk ui" do imply multiple displays or worlds. And the expressions are easily evaluated to figure out what objects they actually point to. Vectoring things through Project is an excellent mechanism, but I also like the phrases that Igor proposes as a way to express the meaning, and as a way to permit the mechanism to be evolved in the future. As an example, the expression "Smalltalk os windowSystemName" is a phrase that is easy to understand, answering the name of the window system for the host operating system. The mechanism is totally bogus ("Smalltalk os" answers a SmalltalkImage rather than some object that represents the host operating system), but it suggests how the implementation might look in the future (a class that represents the host OS). Thus the phrase expresses intent rather than mechanism, and I think this is a good thing. Dave |
Re: Towards clean unloading Morphic (an idea)
|
|
On 27 May 2010 06:13, David T. Lewis <[hidden email]> wrote:
> On Thu, May 20, 2010 at 08:08:34PM -0700, Andreas Raab wrote: >> On 5/20/2010 5:05 PM, Igor Stasenko wrote: >> >> >I know, it is historically been so, but i wonder if there other (more >> >appropriate) dispathes. >> > >> >Smalltalk graphics display >> >Smalltalk ui morphicWorld >> >> I'll object to those two because they don't imply the presence of >> multiple displays or worlds. "Graphics" and "UI" sound like singletons >> to me; "projects" on the other hand can be many. > > I like Igor's suggestion here. To me, the phrases "Smalltalk graphics" > and "Smalltalk ui" do imply multiple displays or worlds. And the > expressions are easily evaluated to figure out what objects they > actually point to. > > Vectoring things through Project is an excellent mechanism, but I also > like the phrases that Igor proposes as a way to express the meaning, > and as a way to permit the mechanism to be evolved in the future. > > As an example, the expression "Smalltalk os windowSystemName" is > a phrase that is easy to understand, answering the name of the window > system for the host operating system. The mechanism is totally bogus > ("Smalltalk os" answers a SmalltalkImage rather than some object > that represents the host operating system), but it suggests how > the implementation might look in the future (a class that represents > the host OS). Thus the phrase expresses intent rather than mechanism, > and I think this is a good thing. > The difference between: Smalltalk ui browser fullOnClass: #MyClass and: SystemBrowser default fullOnClass: #MyClass is in following: The #ui message defines a UI module as a whole, which you want to speak with. While various concrete classes, actually just defining a various subsets of UI. And so, when your system having no any ui, you could just throw an error at #ui message, without proceeding further. So, we could have only a single stub for all ui operations. Now, think how many stubs you will need to implement to make the whole UI [un]loadable at user's will, when your code is allowed to speak with concrete classes directly. In same way, 'Smalltalk graphics' defines an intent to talk with 'graphics' module. Sure thing, it doesn't implies that there are only one display or world (this is maybe unclear from an example which i shown). So, my vision is, that Smalltalk should serve as _the only_ hub to reach various modules, installed in system. So, then we could implement: Smalltalk ui unload. and from that point, sending any messages to (Smalltalk ui), except from #isLoaded (and maybe some other userful ones - like #load) will lead to error. > Dave > -- Best regards, Igor Stasenko AKA sig. |
Re: Towards clean unloading Morphic (an idea)
|
|
In reply to this post by Igor Stasenko
On 5/20/10, Igor Stasenko <[hidden email]> wrote:
> Hello, > > i just thought, that in order to get down to a minimal kernel image, > it would be nice to move all Morphic globals into a shared pool. > > Things like, World, ActiveWorld > could be placed into a MorphicPool class. > > Then we can make an easy transition > 1. add this pool to classes which using that global & recompile them > > 2. for classes, which should have no dependency from Morphic, > use a messages like > > Object >> currentWorld > ^ (Smalltalk at: #MorphicPool ifAbsent: [ self error: 'bummer' ]) > currentWorld . > > Then, i hope, you can unload the Morphic using MC and it will leave no > trace in an image (or at least less trace than usual ;). > > Same could be applied to Graphics package (to get rid a Display global) > > -- > Best regards, > Igor Stasenko AKA sig. Hello If have read all the other mails in this thread. The proposal by Igo may be implemented with the means available. Is there any strong reason not to move ahead with this? Kind regards Hannes |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |