- Pharo-dev - lists.pharo.org

Re: [Pharo-project] about imageSegments

by Martin McClure

StÃ©phane Ducasse wrote: > hi guys > > the more I read about imageSegments the more I would like to remove them (or to package them > carefully - not sure that this is possible) and may be add a new class to > just have one simple way of invoking the save (but not swapping back in) > > I think that mariano diving into them is a great phd exercise but on the long run > I see it as a brittle mechanism. ImageSegments currently have some problems, but are useful. Rather than remove them, I'd like to see them evolve to be better-implemented as people have energy to work on them. If necessary, put a "not for the faint of heart" sign on them in the meantime. Regards, -Martin

Jan. 23, 2010

Re: [Pharo-project] Deadlock detection for testcases

by Adrian Kuhn

Lukas Renggli <renggli@...> writes: Please don't add this to TestCase. Sometimes I want to keep my > debuggers open. Also this slows running lots of tests considerably > down. > > I suggest that you create your own subclass of TestCase and override > runCase as such: > > runCase > [ super runCase ] > valueWithin: self expectedMaxRuntime > onTimeout: [ self failWithTimeout ] +1, being able to debug your tests is a must have. Please note that is also TAssertable >> #should:notTakeMoreThan: TAssertable >> #should:notTakeMoreThanMilliseconds: TestMatcher >> #runWithin: If you dont use akuhn/SUnit the first two methods are in TestCase and the third requires Phexample. cheers, AA

Jan. 23, 2010

Re: [Pharo-project] Smalltalk vs Eclipse

by Ralph Boland

> On Fri, Jan 22, 2010 at 1:32 PM, St?phane Ducasse <stephane.ducasse(a)inria.fr >> 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 >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Jan. 22, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Miguel Enrique CobÃ¡ Martinez

El vie, 22-01-2010 a las 22:14 +0100, StÃ©phane Ducasse escribiÃ³: > don't put magma > there was a list of tools that we wanted in the dev image. Not loaded in the image, but only the snippet to load it in the welcome workspace. As an example of the packages available to load. :) Cheers > > The dev image should be convenient for coding after people should load what they want. > > > > On Jan 22, 2010, at 5:58 PM, Mariano Martinez Peck wrote: > > > > > > > Don't forget Magma. There is a ConfigurationOfMagma already in > > MetacelloRepository. > > > > > > Yes...there are a lot of projects..I even didn't put SqueakDBX/GlorpDBX. I guess that in a future we will have Loader to do this... > > > > I don't know. Do you think we should also include Magma? I put the projects I though were most used. > > > > > > > Do you think that with this we are able to close issue1479 ? > > > - Background with Pharo picture. This was a joke. It looked nice :) > > > I promise I don't put it again if you don't like. To remove it > > > evaluate: > > > World color: Color white. > > > - Enable the preference fastDragWindowForMorphic. Sorry, but it most > > > computers this works REALLY slow. If you want them back, just disable > > > it. > > > > +1 > > > > I generally use: > > Preferences enable: #fastDragWindowForMorphic. > > Preferences disable: #windowAnimation. > > Preferences enable: #updateSavesFile. > > Preferences disable: #windowAnimation. > > > > > > Well....that's why they are called Preferences :) > > I will check them and see if they make sense. > > Thanks!! > > > > > > > - When installing Seaside now doesn't ask for user and password > > > ( admin/seaside ). In addition, the Seaside Control Panel is only > > > isntalled if OB is installed. This means that yu can install it in > > > core or dev. Thanks Dale! > > > - Disable of System Update for Dev images as it is not working > > > properly. > > > > Isn't working? In the image from your link, the preference is working > > correctly. > > > > > > > > > > > The link is: > > > https://gforge.inria.fr/frs/download.php/25397/Pharo1.0-10508-rc2dev10.01.2… > > > > > > Cheers > > > > > > Mariano > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 22, 2010

Re: [Pharo-project] Fwd: [squeak-dev] Smalltalk vs Eclipse

by Eliot Miranda

On Fri, Jan 22, 2010 at 1:32 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > Hi ralph and eliot > > > 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 > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 22, 2010

[Pharo-project] Fwd: [squeak-dev] Smalltalk vs Eclipse

by StÃ©phane Ducasse

Hi ralph and eliot > 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. > 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 > 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 > 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 > 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 :)

Jan. 22, 2010

Re: [Pharo-project] smart MorphTreeWidget

by StÃ©phane Ducasse

this kind of widgets is really important! Tx a lot alain! Stef On Jan 22, 2010, at 10:23 PM, Tudor Girba wrote: > Hi, > > I would just want to praise publicly the work of Alain Plantec on the > MorphTreeWidget. In Pharo 1.0 you can get it at: > Gofer new squeaksource: 'Momo10'; package: 'MorphTreeWidget'; load. > > It's a list, a tree and a table (with single and multiple selection) > in one easily customizable widget. > > Recently, a new feature was added: you can limit the amount of items > visible in the list and you can expand it either incrementally or > altogether once you get to the bottom of the existing items. The idea > is that when you have very long lists, you most of the time do not > want to see all details but just want some visual support for what is > in the list. This is very important for tools like Moose which deal > with large amounts of items. > > This type of work typically goes unnoticed, and that is why I felt the > need to call it to your attention :). > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 22, 2010

Re: [Pharo-project] about imageSegments

by StÃ©phane Ducasse

On Jan 22, 2010, at 9:59 PM, Eliot Miranda wrote: > > > On Fri, Jan 22, 2010 at 12:35 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > hi guys > > the more I read about imageSegments the more I would like to remove them (or to package them > carefully - not sure that this is possible) and may be add a new class to > just have one simple way of invoking the save (but not swapping back in) > > I think that mariano diving into them is a great phd exercise but on the long run > I see it as a brittle mechanism. > > what do you think? > > David Leibs' work on parcels in VW demonstrated that high-performance packaging can be done with no VM support. When you implement a binary format, carefully designed for unpacking performance, at the image level you get the freedom to add flexibility. I added shape change support to parcels (and some higher level features that aren't relevant here) after David had left. So I think the right approach is to reimplement image segments entirely in the image without special VM support and add metadata to the format (class shape information) and you'll probably end up with something that is nearly as performant but much more flexible and evolvable. Thanks I read a lot the parcel paper roel wrote about the pickle format. I reviewed it several times. I'm found of the idea that you can spend time saving if you get really fast loading :) But the paper was never crystal clear to me and I was always sad about that. I remember the first time I loaded RB with the parcels (20 min vs a couple of seconds). > > The two keys to the performance of David's design are the separation of objects from their references and the btching of object allocations. A parcel file starts with a number of allocations of well-known classes (e.g. this parcel contains 17 large integers of the following sizes, and 3 floats, and 17 symbols of the following sizes etc) followed by an arbitrary number of "N instances of class X". So the unpacker populates an object table with indices from 1 to N where N is the number of objects in the parcel, but it does so in batch, spinning in a loop creating N instances of each class in turn, instead of determining which object to create as it walks a (flattened) input graph. After the instance data comes the reference data, which slots refer to which objects. Again the unpacker can spin filling in slots from the reference data instead of determining whether to instantiate an object or dereference an object id as it walks the input graph. So loading is much faster than e.g. ReferenceStream-style approaches. Ok I see the idea. > > 2Â¢ > > best > Eliot > > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 22, 2010

[Pharo-project] smart MorphTreeWidget

by Tudor Girba

Hi, I would just want to praise publicly the work of Alain Plantec on the MorphTreeWidget. In Pharo 1.0 you can get it at: Gofer new squeaksource: 'Momo10'; package: 'MorphTreeWidget'; load. It's a list, a tree and a table (with single and multiple selection) in one easily customizable widget. Recently, a new feature was added: you can limit the amount of items visible in the list and you can expand it either incrementally or altogether once you get to the bottom of the existing items. The idea is that when you have very long lists, you most of the time do not want to see all details but just want some visual support for what is in the list. This is very important for tools like Moose which deal with large amounts of items. This type of work typically goes unnoticed, and that is why I felt the need to call it to your attention :). Cheers, Doru -- www.tudorgirba.com "Beauty is where we see it."

Jan. 22, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by StÃ©phane Ducasse

don't put magma there was a list of tools that we wanted in the dev image. The dev image should be convenient for coding after people should load what they want. On Jan 22, 2010, at 5:58 PM, Mariano Martinez Peck wrote: > > > Don't forget Magma. There is a ConfigurationOfMagma already in > MetacelloRepository. > > > Yes...there are a lot of projects..I even didn't put SqueakDBX/GlorpDBX. I guess that in a future we will have Loader to do this... > > I don't know. Do you think we should also include Magma? I put the projects I though were most used. > > > > Do you think that with this we are able to close issue1479 ? > > - Background with Pharo picture. This was a joke. It looked nice :) > > I promise I don't put it again if you don't like. To remove it > > evaluate: > > World color: Color white. > > - Enable the preference fastDragWindowForMorphic. Sorry, but it most > > computers this works REALLY slow. If you want them back, just disable > > it. > > +1 > > I generally use: > Preferences enable: #fastDragWindowForMorphic. > Preferences disable: #windowAnimation. > Preferences enable: #updateSavesFile. > Preferences disable: #windowAnimation. > > > Well....that's why they are called Preferences :) > I will check them and see if they make sense. > Thanks!! > > > > - When installing Seaside now doesn't ask for user and password > > ( admin/seaside ). In addition, the Seaside Control Panel is only > > isntalled if OB is installed. This means that yu can install it in > > core or dev. Thanks Dale! > > - Disable of System Update for Dev images as it is not working > > properly. > > Isn't working? In the image from your link, the preference is working > correctly. > > > > > > > The link is: > > https://gforge.inria.fr/frs/download.php/25397/Pharo1.0-10508-rc2dev10.01.2… > > > > Cheers > > > > Mariano > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > 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

Jan. 22, 2010