Re: [Pharo-project] Smalltalk vs Eclipse

>> > Nevertheless there are advantages to both and I wonder to what
>> > extent I can have my cake and eat it too  (that would be an orapple
>> > cake I suppose).  I should also point out that my discussion is abstract;
>> > I am asking if it would have been better if Smalltalk had
>> > been designed the way I propose and not should some Smalltalk,
>> > say Squeak, now be modified to be so.
>>
>> Yes I think that we can the best of both world. A minimal (but not smaller)
>> runtime with a good separation between the infrastructure for the runtime
>> and the loadeble ide and others.
>>
>> > The thing, particular to this discussion, about Eclipse that I like
>> > is that the Eclipse (image I will call it) is separate from the
>> > application (image I will call it).  In Smalltalk the two images are
>> > combined.  This means that a lot of code is encorporated
>> > into your application image that you may not want.
>>
>> I imagine that in Pharo in a couple of versions this will be different.
>> At least this is where we want to go.
>>
>> > Of course, before you release your application you can run a
>> > stripping program or process that strips out code that is not
>> > used in your application. (I have never done this but my
>> > understanding is that this is possible.)
>>
>> Stripping should not be the process.
>>
>> > Never having done this I assume that stripping is not that
>> > satisfactory because there is much code that cannot be
>> > stripped out; certainly unused methods and likely unused
>> > classes as well; the dynamic nature of Smalltalk means that
>> > much necessary information to determine that a method or
>> > class is not used is not available so such methods and classes
>> > must be included in the application release.
>>
>> Stripping in VW was not satisfactory not really easy.
>>
>
> It was not easy precisely because it had to strip out its own tools.  If the
> tools are remote then stripping is much easier.  I'm not proposing stripping
> as a standard step in deploying applications.  I;m proposing stripping via
> remote tools as a way to get down to a small kernel image.  Part of the
> difficulty in producing the small kernel image is needing to keep tools
> around so that the development system keeps working.  This is all much
> easier if that development system is remote.
>
>
>
>> > Some may argue, that with all the memory processing power
>> > available today, who cares; but I care.  For example, I would
>> > like to be able to put a Smalltalk application into a linux pipe
>> > as in:
>> >
>> > a | b > c
>> >
>> > where a or b or both are applications written in Smalltalk.
>>
>> me too :)
>>
>> > Similarly I would like to use Smalltalk applications in bash (Linux)
>> > shells scripts or use it in other scripting languages. So it
>> > may be important that my image not be unnecessarily
>> > large as getting it started may take longer than what it
>> > does once it is started.
>>
>> Yes we want that too. So any help in that direction is welcomed.
>>
>> > Of course I could use GNU Smalltalk for this but is it really
>> > necessary that I know/use two smalltalks?
>> >
>> > I think the Eclipse model suggests an improvement to Smalltalk.
>> > It seems to me that when you run Smalltalk ideally you would
>> > run two images.  One would be the development environment image
>> > and the other would be the application image.  When you started
>> > a new project you would choose from a selection of start images
>> > each including some subset of the development classes you
>> > expect to need.
>>
>> for minimal image to work, we need a way to manage parts
>> this is why metacello is important. Because you want to have ways to build
>> coherent images out of components with dependencies.
>> This is just because of that that we did not started to heavily remove
>> packages from the image.
>>
>> > I can't speak in detail to the Firewall work done at Digitalk by people
>> like Steve Messick, but they did get stuff done in the late 90's, although I
>> don't think anything was productised.  I think they made the mistake of
>> focussing on being able to produce very small executables rather than just
>> separating the development and deployment images.  I think Steve was able to
>> produce a tiny executable that only contained SmallInteger and hence was
>> able to eliminate tagged pointers and method lookup.  But the focus on
>> optimization was I think a step too far.
>>
>> + 1.
>>
>> > One thing I remember was that the communications stub in the deployment
>> image was in the VM, not in Smalltalk code, again I think a mistake. Can
>> anyone from Digitalk put flesh on these bones?
>> ?
>>
>> eliot what is the communications stub
>>
>
> Is is some code that sits on a socket in the target image and receives
> remote message send requests from the UI image, evaluates them and returns
> the results.  So it is a minimal communications port through which the UI
> can send messages to objects in the target image.  It should be written
> entirely in Smalltalk for flexibility and simplicity.  We don't need to get
> to 100's of bytes of image (e.g. being able to implement the unix mv
> command) we need to get down below 1Mb.
>
> I think Craig has such a remote messaging scheme in Spoon.
>
>
>
>> > We spent a lot of time discussing doing this in the VisualWorks team
>> about 10 years ago but as far as I'm aware none of it was realised.
>>  Splitting tools UIs from the image under development (the target image) was
>> a major design goal behind OpenTalk, the distributed messaging framework
>> that Xu Wang did.  We had the idea of the Model in an MVC triad being the
>> interface between the UI and target images, the natural point at which one
>> would define an API narrow enough to be efficiently distributed.  If the API
>> is designed appropriately one would be exchanging symbols (class names,
>> selectors etc) not complex objects (classes, compiled methods) and that
>> because symbols and numbers are immutable they can be passed by value.
>> >
>> > We had the idea of the model being split in two, one half being specific
>> to a tool and the same whether one was in a single image or in the ui/target
>> pair, and the other half being an adaptor to either the local image or the
>> remote target.  This adaptor would have sat between a model and some complex
>> object graph (like the class hierarchy) and defined the entire API through
>> which the object graph was accessed, narrowing the interface to make it
>> suitable for distribution, and doumenting the interface to make it easier to
>> understand.  Vassili named these things between the model and an object
>> graph TTIBs for "The Things In Between".
>>
>> Was using distribution just one way to make sure that your two systems were
>> decoupled?
>> Because we could achieve the same using seaside? or
>>
>
> Exactly.  The TTIB serves as a specification and a filter.  But it is
> independent of the transport.  Seaside is a valid transport.  If things are
> done right one can have many different kinds of UI.  But one is making the
> choice that the transport is Smalltalk messages over some non-Smalltalk
> stream.  No one is contemplating using SOAP or CORBA or... (I hope).
>
>
>> > We very much wanted to produce a set of tools in a tools UI image that
>> could be targetted either at itself or at a remote target, and wanted to be
>> able to attach the tools image to a remote target dynamically (which we
>> called "dynamic capitation", for dynamically gaining a head) so that one
>> could have full debuggability on a remote image deployed in the field.
>>
>> :)
>> I would really like to know what are the issue at the level of the
>> Display.... VM code. What are the existing hypotheses
>> that have to be broken. Like global access to sensor or
>>
>
> Yes, lots of things break potentally.  Transcript, self confirm: etc.  Part
> of the challenge is in coming up with "pluggable" replacements.  So that for
> example Transcript in the target image is something that sends its output to
> stdout until one attaches a tools UI, at which it becomes something that
> sends its output to the Transcript in the UI image.  This takes some thought
> :)
>
>
>> Alas we never managed to get the priority of the project high enough to
>> actually commit major resources to it.  There were always more pressing more
>> mundane things to do.  Frustration at not doing things like this was in part
>> behind my leaving Cincom.  Xu got quite far with a prototype, demonstrating
>> things like a distributed inspector that allowed one to walk though an
>> object graph spanning more than one image.  The inspector would change
>> colour to indicate which machine the current object was one.
>> >
>> >
>> > Personally I think that Smalltalk is the ideal vehicle for this kind of
>> approach.  We have lightweight remote messaging which is relatively easy to
>> implement.  We have UI architectures which are relatively well-decomposed
>> and amenable to distribution.  We have a reified exception system which is
>> not pushed down into hidden execution machinery and which has resume
>> semantics.  We now have a much faster much more reliable internet.  We could
>> relatively easily add things like delegation which can enable interesting
>> interleaving of tools and target images (see below).  I think we could have
>> something truly revolutionary, the ability to interact with a remote
>> headless image that contains no development tools or UI frameworks and only
>> a relatively small communications module (remote messaging interface).  This
>> would enable us to get to images of a few 10s or 100s of kilobytes.  I
>> fervently hope you work on this.  Lots of people want this.  I was reading
>> Colin's Thin Air pages on wiresong yesterday and what he wants is realised
>> by this.
>>
>> Yes this would be good to have that.
>> I think that cleaning the left over of years of experimentations (which we
>> started with 3.6 Kernel Cleaning project
>> and continue in 3.9 and now is taking a large part in current pharo) is the
>> first phase so that we can
>> make sure kind of system happening.
>>
>> > If you do work on this remember your goals.  The most important thing is
>> incremental deliverables and useful progress.  Don't focus on whizzy
>> optimisations or cool demos (such as the inspector changing colour).  Dn't
>> focus on arbitrarily complex topologies of remote images.  Instead focus on
>> building a robust, well-engineered remote tools framework that just allows
>> one to do what one can do today in a browser and debugger, but remotely
>> between two images.
>>
>> We were thinking just about that with marcus and noury for mariano PhD.
>> this could be used to debug remote image running on robots.
>>
>> > I would start with browser, debugger and stripper, where stripper would
>> be something that allowed you to eliminate code from the target image using
>> the UI image to discover what was there and what was needed or not, i.e.
>> remote stripping, not the much trickier auto-stripping.
>> >
>> > On delegation I think one really cool thing is to wrap remote objects
>> with local development-only code.  In a deployed image I would expect there
>> to be no inspectorClass methods or debugPrintOn: messages etc.  The target
>> is lean and mean.  Anything not needed for deployment except that which
>> supports adequate remote messaging is absent.  So one wants to be able to
>> add methods that add debugging features to remote objects, and delegation is
>> the way.  If the local handle on a remote object is wrapped by a delegate,
>> the delegate can implement the debugging methods.  Catching
>> doesNotUnderstand: in the target mage can allow one to intercept
>> computations in the target and resume them in the development image.  So
>> when connecting a tools image to a target one would layer tools and UI code
>> upon objects in the target but that code would reside only in the tools
>> image.
>> >
>> > Naming conventions in packaging, like splitting a Foo package into
>> Foo-Deployment & Foo-Development could help in making this kind of split
>> easy to navigate and conceptualise.  So after producing the tools/target
>> split I would next focus on packaging tools, including analysis of call
>> graphs etc to help automating the deployment/development split.
>>
>> You forget deliver often :)
>>
>
> Right!
>
> best
> Eliot
>
>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20100122/a7ec7d11/attachment.htm
>
> ------------------------------
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> End of Pharo-project Digest, Vol 21, Issue 375
> **********************************************
>

>> On Fri, Jan 22, 2010 at 1:32 PM, St?phane Ducasse <[hidden email]
>>> wrote:
>>
>>>
>>> Hi ralph and eliot
>>>
>
> Wow, for once one of my Ideas seems to be popular,
> even if, apparently, it is not new.
>
> Some points:
>
> 1)  I had not thought of the advantages of using Smalltalk to debug/develop
> an application remotely.  Commenters have made clear that the remote
> aspect is very useful.  I was just thinking of development in general where
> my application and development images are on the same machine.
> Does it make sense to first create a system having both a development
> image and application image and once that is complete add the capability
> to work remotely?  Or is it best that both be implemented in parallel?
> If the two tasks can be separated then I suggest we worry about achieving
> the first while keeping the second in mind during development.
>
> 2)  While this seems like an exciting project to me I do not have the necessary
> skills/knowledge.  The best I could offer would be as a serf in some
> corner implementing
> some component that I could handle.  Actually I cannot really offer that because
> I have my own open source project that I am working on for the next several
> man years.  Worse still I am going broke (Hi Keith) and desperately need to find
> a job.  Unfortunately Smalltalk jobs in Canada are extremely rare so I can going
> to have to program in C or Java or learn Python or  Php or Ruby (any
> recommendations
> as to which of those languages is the best) just so I can be employed.
> I would really like to see this project go forward though.
> I also much prefer some current version of Smalltalk make this
> modification rather
> than forking a new Smalltalk (call it  Orapple?).  Can this project go
> forward in
> stages,  say in 4 stages, with a stage completed with each major release?
> Could the project be a loadable package or are things too intimate for that?
>
> 3)  I don't know much about stripping but I don't believe this idea removes it.
> Even if the application and IDE are separated the application image is likely
> to have many things not meant for the client such as application specific
> debugging tools (tools separate from the IDE),  testing software such
> as SUnit tests,
> features meant for one client but not another,  etc.  As pointed out, however,
> stripping becomes much easier and effective if the IDE is separated
> from the image.
>    An alternative to stripping is to have three images,  The IDE
> image, the application
> development version image and the application release image.  Then the
> application release image never has anything in it that needs to be stripped
> (ignoring the multiple client issue).
> Admittedly, having three imaging running at the same time seems a bit wild.
> To be honest, I really don't know if having a third image is a good idea.
> I wouldn't worry too much about this though until we actually have a
> much progressed
> real project on our hands.
>
> Regards,
>
> Ralph Boland  (Available Smalltalker,  will travel anywhere)
>
>
>>> > Nevertheless there are advantages to both and I wonder to what
>>> > extent I can have my cake and eat it too  (that would be an orapple
>>> > cake I suppose).  I should also point out that my discussion is abstract;
>>> > I am asking if it would have been better if Smalltalk had
>>> > been designed the way I propose and not should some Smalltalk,
>>> > say Squeak, now be modified to be so.
>>>
>>> Yes I think that we can the best of both world. A minimal (but not smaller)
>>> runtime with a good separation between the infrastructure for the runtime
>>> and the loadeble ide and others.
>>>
>>> > The thing, particular to this discussion, about Eclipse that I like
>>> > is that the Eclipse (image I will call it) is separate from the
>>> > application (image I will call it).  In Smalltalk the two images are
>>> > combined.  This means that a lot of code is encorporated
>>> > into your application image that you may not want.
>>>
>>> I imagine that in Pharo in a couple of versions this will be different.
>>> At least this is where we want to go.
>>>
>>> > Of course, before you release your application you can run a
>>> > stripping program or process that strips out code that is not
>>> > used in your application. (I have never done this but my
>>> > understanding is that this is possible.)
>>>
>>> Stripping should not be the process.
>>>
>>> > Never having done this I assume that stripping is not that
>>> > satisfactory because there is much code that cannot be
>>> > stripped out; certainly unused methods and likely unused
>>> > classes as well; the dynamic nature of Smalltalk means that
>>> > much necessary information to determine that a method or
>>> > class is not used is not available so such methods and classes
>>> > must be included in the application release.
>>>
>>> Stripping in VW was not satisfactory not really easy.
>>>
>>
>> It was not easy precisely because it had to strip out its own tools.  If the
>> tools are remote then stripping is much easier.  I'm not proposing stripping
>> as a standard step in deploying applications.  I;m proposing stripping via
>> remote tools as a way to get down to a small kernel image.  Part of the
>> difficulty in producing the small kernel image is needing to keep tools
>> around so that the development system keeps working.  This is all much
>> easier if that development system is remote.
>>
>>
>>
>>> > Some may argue, that with all the memory processing power
>>> > available today, who cares; but I care.  For example, I would
>>> > like to be able to put a Smalltalk application into a linux pipe
>>> > as in:
>>> >
>>> > a | b > c
>>> >
>>> > where a or b or both are applications written in Smalltalk.
>>>
>>> me too :)
>>>
>>> > Similarly I would like to use Smalltalk applications in bash (Linux)
>>> > shells scripts or use it in other scripting languages. So it
>>> > may be important that my image not be unnecessarily
>>> > large as getting it started may take longer than what it
>>> > does once it is started.
>>>
>>> Yes we want that too. So any help in that direction is welcomed.
>>>
>>> > Of course I could use GNU Smalltalk for this but is it really
>>> > necessary that I know/use two smalltalks?
>>> >
>>> > I think the Eclipse model suggests an improvement to Smalltalk.
>>> > It seems to me that when you run Smalltalk ideally you would
>>> > run two images.  One would be the development environment image
>>> > and the other would be the application image.  When you started
>>> > a new project you would choose from a selection of start images
>>> > each including some subset of the development classes you
>>> > expect to need.
>>>
>>> for minimal image to work, we need a way to manage parts
>>> this is why metacello is important. Because you want to have ways to build
>>> coherent images out of components with dependencies.
>>> This is just because of that that we did not started to heavily remove
>>> packages from the image.
>>>
>>> > I can't speak in detail to the Firewall work done at Digitalk by people
>>> like Steve Messick, but they did get stuff done in the late 90's, although I
>>> don't think anything was productised.  I think they made the mistake of
>>> focussing on being able to produce very small executables rather than just
>>> separating the development and deployment images.  I think Steve was able to
>>> produce a tiny executable that only contained SmallInteger and hence was
>>> able to eliminate tagged pointers and method lookup.  But the focus on
>>> optimization was I think a step too far.
>>>
>>> + 1.
>>>
>>> > One thing I remember was that the communications stub in the deployment
>>> image was in the VM, not in Smalltalk code, again I think a mistake. Can
>>> anyone from Digitalk put flesh on these bones?
>>> ?
>>>
>>> eliot what is the communications stub
>>>
>>
>> Is is some code that sits on a socket in the target image and receives
>> remote message send requests from the UI image, evaluates them and returns
>> the results.  So it is a minimal communications port through which the UI
>> can send messages to objects in the target image.  It should be written
>> entirely in Smalltalk for flexibility and simplicity.  We don't need to get
>> to 100's of bytes of image (e.g. being able to implement the unix mv
>> command) we need to get down below 1Mb.
>>
>> I think Craig has such a remote messaging scheme in Spoon.
>>
>>
>>
>>> > We spent a lot of time discussing doing this in the VisualWorks team
>>> about 10 years ago but as far as I'm aware none of it was realised.
>>>  Splitting tools UIs from the image under development (the target image) was
>>> a major design goal behind OpenTalk, the distributed messaging framework
>>> that Xu Wang did.  We had the idea of the Model in an MVC triad being the
>>> interface between the UI and target images, the natural point at which one
>>> would define an API narrow enough to be efficiently distributed.  If the API
>>> is designed appropriately one would be exchanging symbols (class names,
>>> selectors etc) not complex objects (classes, compiled methods) and that
>>> because symbols and numbers are immutable they can be passed by value.
>>> >
>>> > We had the idea of the model being split in two, one half being specific
>>> to a tool and the same whether one was in a single image or in the ui/target
>>> pair, and the other half being an adaptor to either the local image or the
>>> remote target.  This adaptor would have sat between a model and some complex
>>> object graph (like the class hierarchy) and defined the entire API through
>>> which the object graph was accessed, narrowing the interface to make it
>>> suitable for distribution, and doumenting the interface to make it easier to
>>> understand.  Vassili named these things between the model and an object
>>> graph TTIBs for "The Things In Between".
>>>
>>> Was using distribution just one way to make sure that your two systems were
>>> decoupled?
>>> Because we could achieve the same using seaside? or
>>>
>>
>> Exactly.  The TTIB serves as a specification and a filter.  But it is
>> independent of the transport.  Seaside is a valid transport.  If things are
>> done right one can have many different kinds of UI.  But one is making the
>> choice that the transport is Smalltalk messages over some non-Smalltalk
>> stream.  No one is contemplating using SOAP or CORBA or... (I hope).
>>
>>
>>> > We very much wanted to produce a set of tools in a tools UI image that
>>> could be targetted either at itself or at a remote target, and wanted to be
>>> able to attach the tools image to a remote target dynamically (which we
>>> called "dynamic capitation", for dynamically gaining a head) so that one
>>> could have full debuggability on a remote image deployed in the field.
>>>
>>> :)
>>> I would really like to know what are the issue at the level of the
>>> Display.... VM code. What are the existing hypotheses
>>> that have to be broken. Like global access to sensor or
>>>
>>
>> Yes, lots of things break potentally.  Transcript, self confirm: etc.  Part
>> of the challenge is in coming up with "pluggable" replacements.  So that for
>> example Transcript in the target image is something that sends its output to
>> stdout until one attaches a tools UI, at which it becomes something that
>> sends its output to the Transcript in the UI image.  This takes some thought
>> :)
>>
>>
>>> Alas we never managed to get the priority of the project high enough to
>>> actually commit major resources to it.  There were always more pressing more
>>> mundane things to do.  Frustration at not doing things like this was in part
>>> behind my leaving Cincom.  Xu got quite far with a prototype, demonstrating
>>> things like a distributed inspector that allowed one to walk though an
>>> object graph spanning more than one image.  The inspector would change
>>> colour to indicate which machine the current object was one.
>>> >
>>> >
>>> > Personally I think that Smalltalk is the ideal vehicle for this kind of
>>> approach.  We have lightweight remote messaging which is relatively easy to
>>> implement.  We have UI architectures which are relatively well-decomposed
>>> and amenable to distribution.  We have a reified exception system which is
>>> not pushed down into hidden execution machinery and which has resume
>>> semantics.  We now have a much faster much more reliable internet.  We could
>>> relatively easily add things like delegation which can enable interesting
>>> interleaving of tools and target images (see below).  I think we could have
>>> something truly revolutionary, the ability to interact with a remote
>>> headless image that contains no development tools or UI frameworks and only
>>> a relatively small communications module (remote messaging interface).  This
>>> would enable us to get to images of a few 10s or 100s of kilobytes.  I
>>> fervently hope you work on this.  Lots of people want this.  I was reading
>>> Colin's Thin Air pages on wiresong yesterday and what he wants is realised
>>> by this.
>>>
>>> Yes this would be good to have that.
>>> I think that cleaning the left over of years of experimentations (which we
>>> started with 3.6 Kernel Cleaning project
>>> and continue in 3.9 and now is taking a large part in current pharo) is the
>>> first phase so that we can
>>> make sure kind of system happening.
>>>
>>> > If you do work on this remember your goals.  The most important thing is
>>> incremental deliverables and useful progress.  Don't focus on whizzy
>>> optimisations or cool demos (such as the inspector changing colour).  Dn't
>>> focus on arbitrarily complex topologies of remote images.  Instead focus on
>>> building a robust, well-engineered remote tools framework that just allows
>>> one to do what one can do today in a browser and debugger, but remotely
>>> between two images.
>>>
>>> We were thinking just about that with marcus and noury for mariano PhD.
>>> this could be used to debug remote image running on robots.
>>>
>>> > I would start with browser, debugger and stripper, where stripper would
>>> be something that allowed you to eliminate code from the target image using
>>> the UI image to discover what was there and what was needed or not, i.e.
>>> remote stripping, not the much trickier auto-stripping.
>>> >
>>> > On delegation I think one really cool thing is to wrap remote objects
>>> with local development-only code.  In a deployed image I would expect there
>>> to be no inspectorClass methods or debugPrintOn: messages etc.  The target
>>> is lean and mean.  Anything not needed for deployment except that which
>>> supports adequate remote messaging is absent.  So one wants to be able to
>>> add methods that add debugging features to remote objects, and delegation is
>>> the way.  If the local handle on a remote object is wrapped by a delegate,
>>> the delegate can implement the debugging methods.  Catching
>>> doesNotUnderstand: in the target mage can allow one to intercept
>>> computations in the target and resume them in the development image.  So
>>> when connecting a tools image to a target one would layer tools and UI code
>>> upon objects in the target but that code would reside only in the tools
>>> image.
>>> >
>>> > Naming conventions in packaging, like splitting a Foo package into
>>> Foo-Deployment & Foo-Development could help in making this kind of split
>>> easy to navigate and conceptualise.  So after producing the tools/target
>>> split I would next focus on packaging tools, including analysis of call
>>> graphs etc to help automating the deployment/development split.
>>>
>>> You forget deliver often :)
>>>
>>
>> Right!
>>
>> best
>> Eliot
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20100122/a7ec7d11/attachment.htm
>>
>> ------------------------------
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> End of Pharo-project Digest, Vol 21, Issue 375
>> **********************************************
>>
>
>
>
> --
> I've been middle class and I've been poor.
> Middle class is better.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Some points:
>
> 1)  I had not thought of the advantages of using Smalltalk to debug/develop
> an application remotely.  Commenters have made clear that the remote
> aspect is very useful.  I was just thinking of development in general where
> my application and development images are on the same machine.
> Does it make sense to first create a system having both a development
> image and application image and once that is complete add the capability
> to work remotely?  Or is it best that both be implemented in parallel?
> If the two tasks can be separated then I suggest we worry about achieving
> the first while keeping the second in mind during development.
>
> 2)  While this seems like an exciting project to me I do not have the necessary
> skills/knowledge.  The best I could offer would be as a serf in some
> corner implementing some component that I could handle.  

> I would really like to see this project go forward though.
> I also much prefer some current version of Smalltalk make this
> modification rather
> than forking a new Smalltalk (call it  Orapple?).  Can this project go
> forward in
> stages,  say in 4 stages, with a stage completed with each major release?
> Could the project be a loadable package or are things too intimate for that?
>
> 3)  I don't know much about stripping but I don't believe this idea removes it.
> Even if the application and IDE are separated the application image is likely
> to have many things not meant for the client such as application specific
> debugging tools (tools separate from the IDE),  testing software such
> as SUnit tests,
> features meant for one client but not another,  etc.  As pointed out, however,
> stripping becomes much easier and effective if the IDE is separated
> from the image.
>    An alternative to stripping is to have three images,  The IDE
> image, the application
> development version image and the application release image.  Then the
> application release image never has anything in it that needs to be stripped
> (ignoring the multiple client issue).
> Admittedly, having three imaging running at the same time seems a bit wild.
> To be honest, I really don't know if having a third image is a good idea.
> I wouldn't worry too much about this though until we actually have a
> much progressed
> real project on our hands.
>
> Regards,
>
> Ralph Boland  (Available Smalltalker,  will travel anywhere)
>
>
>>>> Nevertheless there are advantages to both and I wonder to what
>>>> extent I can have my cake and eat it too  (that would be an orapple
>>>> cake I suppose).  I should also point out that my discussion is abstract;
>>>> I am asking if it would have been better if Smalltalk had
>>>> been designed the way I propose and not should some Smalltalk,
>>>> say Squeak, now be modified to be so.
>>>
>>> Yes I think that we can the best of both world. A minimal (but not smaller)
>>> runtime with a good separation between the infrastructure for the runtime
>>> and the loadeble ide and others.
>>>
>>>> The thing, particular to this discussion, about Eclipse that I like
>>>> is that the Eclipse (image I will call it) is separate from the
>>>> application (image I will call it).  In Smalltalk the two images are
>>>> combined.  This means that a lot of code is encorporated
>>>> into your application image that you may not want.
>>>
>>> I imagine that in Pharo in a couple of versions this will be different.
>>> At least this is where we want to go.
>>>
>>>> Of course, before you release your application you can run a
>>>> stripping program or process that strips out code that is not
>>>> used in your application. (I have never done this but my
>>>> understanding is that this is possible.)
>>>
>>> Stripping should not be the process.
>>>
>>>> Never having done this I assume that stripping is not that
>>>> satisfactory because there is much code that cannot be
>>>> stripped out; certainly unused methods and likely unused
>>>> classes as well; the dynamic nature of Smalltalk means that
>>>> much necessary information to determine that a method or
>>>> class is not used is not available so such methods and classes
>>>> must be included in the application release.
>>>
>>> Stripping in VW was not satisfactory not really easy.
>>>
>>
>> It was not easy precisely because it had to strip out its own tools.  If the
>> tools are remote then stripping is much easier.  I'm not proposing stripping
>> as a standard step in deploying applications.  I;m proposing stripping via
>> remote tools as a way to get down to a small kernel image.  Part of the
>> difficulty in producing the small kernel image is needing to keep tools
>> around so that the development system keeps working.  This is all much
>> easier if that development system is remote.
>>
>>
>>
>>>> Some may argue, that with all the memory processing power
>>>> available today, who cares; but I care.  For example, I would
>>>> like to be able to put a Smalltalk application into a linux pipe
>>>> as in:
>>>>
>>>> a | b > c
>>>>
>>>> where a or b or both are applications written in Smalltalk.
>>>
>>> me too :)
>>>
>>>> Similarly I would like to use Smalltalk applications in bash (Linux)
>>>> shells scripts or use it in other scripting languages. So it
>>>> may be important that my image not be unnecessarily
>>>> large as getting it started may take longer than what it
>>>> does once it is started.
>>>
>>> Yes we want that too. So any help in that direction is welcomed.
>>>
>>>> Of course I could use GNU Smalltalk for this but is it really
>>>> necessary that I know/use two smalltalks?
>>>>
>>>> I think the Eclipse model suggests an improvement to Smalltalk.
>>>> It seems to me that when you run Smalltalk ideally you would
>>>> run two images.  One would be the development environment image
>>>> and the other would be the application image.  When you started
>>>> a new project you would choose from a selection of start images
>>>> each including some subset of the development classes you
>>>> expect to need.
>>>
>>> for minimal image to work, we need a way to manage parts
>>> this is why metacello is important. Because you want to have ways to build
>>> coherent images out of components with dependencies.
>>> This is just because of that that we did not started to heavily remove
>>> packages from the image.
>>>
>>>> I can't speak in detail to the Firewall work done at Digitalk by people
>>> like Steve Messick, but they did get stuff done in the late 90's, although I
>>> don't think anything was productised.  I think they made the mistake of
>>> focussing on being able to produce very small executables rather than just
>>> separating the development and deployment images.  I think Steve was able to
>>> produce a tiny executable that only contained SmallInteger and hence was
>>> able to eliminate tagged pointers and method lookup.  But the focus on
>>> optimization was I think a step too far.
>>>
>>> + 1.
>>>
>>>> One thing I remember was that the communications stub in the deployment
>>> image was in the VM, not in Smalltalk code, again I think a mistake. Can
>>> anyone from Digitalk put flesh on these bones?
>>> ?
>>>
>>> eliot what is the communications stub
>>>
>>
>> Is is some code that sits on a socket in the target image and receives
>> remote message send requests from the UI image, evaluates them and returns
>> the results.  So it is a minimal communications port through which the UI
>> can send messages to objects in the target image.  It should be written
>> entirely in Smalltalk for flexibility and simplicity.  We don't need to get
>> to 100's of bytes of image (e.g. being able to implement the unix mv
>> command) we need to get down below 1Mb.
>>
>> I think Craig has such a remote messaging scheme in Spoon.
>>
>>
>>
>>>> We spent a lot of time discussing doing this in the VisualWorks team
>>> about 10 years ago but as far as I'm aware none of it was realised.
>>>  Splitting tools UIs from the image under development (the target image) was
>>> a major design goal behind OpenTalk, the distributed messaging framework
>>> that Xu Wang did.  We had the idea of the Model in an MVC triad being the
>>> interface between the UI and target images, the natural point at which one
>>> would define an API narrow enough to be efficiently distributed.  If the API
>>> is designed appropriately one would be exchanging symbols (class names,
>>> selectors etc) not complex objects (classes, compiled methods) and that
>>> because symbols and numbers are immutable they can be passed by value.
>>>>
>>>> We had the idea of the model being split in two, one half being specific
>>> to a tool and the same whether one was in a single image or in the ui/target
>>> pair, and the other half being an adaptor to either the local image or the
>>> remote target.  This adaptor would have sat between a model and some complex
>>> object graph (like the class hierarchy) and defined the entire API through
>>> which the object graph was accessed, narrowing the interface to make it
>>> suitable for distribution, and doumenting the interface to make it easier to
>>> understand.  Vassili named these things between the model and an object
>>> graph TTIBs for "The Things In Between".
>>>
>>> Was using distribution just one way to make sure that your two systems were
>>> decoupled?
>>> Because we could achieve the same using seaside? or
>>>
>>
>> Exactly.  The TTIB serves as a specification and a filter.  But it is
>> independent of the transport.  Seaside is a valid transport.  If things are
>> done right one can have many different kinds of UI.  But one is making the
>> choice that the transport is Smalltalk messages over some non-Smalltalk
>> stream.  No one is contemplating using SOAP or CORBA or... (I hope).
>>
>>
>>>> We very much wanted to produce a set of tools in a tools UI image that
>>> could be targetted either at itself or at a remote target, and wanted to be
>>> able to attach the tools image to a remote target dynamically (which we
>>> called "dynamic capitation", for dynamically gaining a head) so that one
>>> could have full debuggability on a remote image deployed in the field.
>>>
>>> :)
>>> I would really like to know what are the issue at the level of the
>>> Display.... VM code. What are the existing hypotheses
>>> that have to be broken. Like global access to sensor or
>>>
>>
>> Yes, lots of things break potentally.  Transcript, self confirm: etc.  Part
>> of the challenge is in coming up with "pluggable" replacements.  So that for
>> example Transcript in the target image is something that sends its output to
>> stdout until one attaches a tools UI, at which it becomes something that
>> sends its output to the Transcript in the UI image.  This takes some thought
>> :)
>>
>>
>>> Alas we never managed to get the priority of the project high enough to
>>> actually commit major resources to it.  There were always more pressing more
>>> mundane things to do.  Frustration at not doing things like this was in part
>>> behind my leaving Cincom.  Xu got quite far with a prototype, demonstrating
>>> things like a distributed inspector that allowed one to walk though an
>>> object graph spanning more than one image.  The inspector would change
>>> colour to indicate which machine the current object was one.
>>>>
>>>>
>>>> Personally I think that Smalltalk is the ideal vehicle for this kind of
>>> approach.  We have lightweight remote messaging which is relatively easy to
>>> implement.  We have UI architectures which are relatively well-decomposed
>>> and amenable to distribution.  We have a reified exception system which is
>>> not pushed down into hidden execution machinery and which has resume
>>> semantics.  We now have a much faster much more reliable internet.  We could
>>> relatively easily add things like delegation which can enable interesting
>>> interleaving of tools and target images (see below).  I think we could have
>>> something truly revolutionary, the ability to interact with a remote
>>> headless image that contains no development tools or UI frameworks and only
>>> a relatively small communications module (remote messaging interface).  This
>>> would enable us to get to images of a few 10s or 100s of kilobytes.  I
>>> fervently hope you work on this.  Lots of people want this.  I was reading
>>> Colin's Thin Air pages on wiresong yesterday and what he wants is realised
>>> by this.
>>>
>>> Yes this would be good to have that.
>>> I think that cleaning the left over of years of experimentations (which we
>>> started with 3.6 Kernel Cleaning project
>>> and continue in 3.9 and now is taking a large part in current pharo) is the
>>> first phase so that we can
>>> make sure kind of system happening.
>>>
>>>> If you do work on this remember your goals.  The most important thing is
>>> incremental deliverables and useful progress.  Don't focus on whizzy
>>> optimisations or cool demos (such as the inspector changing colour).  Dn't
>>> focus on arbitrarily complex topologies of remote images.  Instead focus on
>>> building a robust, well-engineered remote tools framework that just allows
>>> one to do what one can do today in a browser and debugger, but remotely
>>> between two images.
>>>
>>> We were thinking just about that with marcus and noury for mariano PhD.
>>> this could be used to debug remote image running on robots.
>>>
>>>> I would start with browser, debugger and stripper, where stripper would
>>> be something that allowed you to eliminate code from the target image using
>>> the UI image to discover what was there and what was needed or not, i.e.
>>> remote stripping, not the much trickier auto-stripping.
>>>>
>>>> On delegation I think one really cool thing is to wrap remote objects
>>> with local development-only code.  In a deployed image I would expect there
>>> to be no inspectorClass methods or debugPrintOn: messages etc.  The target
>>> is lean and mean.  Anything not needed for deployment except that which
>>> supports adequate remote messaging is absent.  So one wants to be able to
>>> add methods that add debugging features to remote objects, and delegation is
>>> the way.  If the local handle on a remote object is wrapped by a delegate,
>>> the delegate can implement the debugging methods.  Catching
>>> doesNotUnderstand: in the target mage can allow one to intercept
>>> computations in the target and resume them in the development image.  So
>>> when connecting a tools image to a target one would layer tools and UI code
>>> upon objects in the target but that code would reside only in the tools
>>> image.
>>>>
>>>> Naming conventions in packaging, like splitting a Foo package into
>>> Foo-Deployment & Foo-Development could help in making this kind of split
>>> easy to navigate and conceptualise.  So after producing the tools/target
>>> split I would next focus on packaging tools, including analysis of call
>>> graphs etc to help automating the deployment/development split.
>>>
>>> You forget deliver often :)
>>>
>>
>> Right!
>>
>> best
>> Eliot
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20100122/a7ec7d11/attachment.htm
>>
>> ------------------------------
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> End of Pharo-project Digest, Vol 21, Issue 375
>> **********************************************
>>
>
>
>
> --
> I've been middle class and I've been poor.
> Middle class is better.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project