January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] about imageSegments

by Eliot Miranda

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. 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. 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 >

Jan. 22, 2010

Re: [Pharo-project] Copy/paste not works

by StÃ©phane Ducasse

probably my mistake to remove SqueakClipBoard. Sorry. Could you file it out of a previous image and check if this is the problem? If I could reproduce your problem I would have fixed it already. Stef >>> >>> >>>> >>>> 11161" >>>> self withUpdateLog: 'Issue 765: Menu must not be zero size >>>> Issue 1793: Remove SqueakClipBoard >>>> Issue 1790: basicShallowCopy should be removed >>>> >>>> may be the SqueakClipBoard? >>>> >>> >>> Everything worked fine even in 11161, >>> until i saved image and restarted it. >>> So, the bug seems lurking inside a startup/shutdown code. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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 Schwab,Wilhelm K

We do not need new tools to take several lines and lots of irrelevant/redundant sugar down to one line with two relevant items. Please consider adding something like the attached to *anything* that is in the image; then load scripts will be far simpler than we are encouraging at present. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Friday, January 22, 2010 11:15 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2 2010/1/22 laurent laffont <laurent.laffont(a)gmail.com<mailto:laurent.laffont@gmail.com>> 2010/1/22 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> I'm very pressed for time right now, but I like the external projects workspace. I still think that there is way too much code, as all of the work can be done by one method that forms the name of the configuation class and takes (at most) a version string. The phrase "syntactic sugar" comes to mind - not quite the same thing, essentially so for our purposes. Why we don't use Loader ? Still in alpha state ? I like it and it's simple to use. Because we are not even stable with the current tools. We cannot do all toghether. Please guys, we need to go step by step. Loader is still in development. Laurent _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 22, 2010

[Pharo-project] about imageSegments

by StÃ©phane Ducasse

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? Stef

Jan. 22, 2010

[Pharo-project] Input different data types (integers or datetimes) in a textbox.

by nullPointer

I want know if exists some way or mechanism for input data in a widget of a specific type. For example a textbox with only numbers ( decimals or only integers ) or some mechanism of mask edit for fill a text in a textbox of "type" DateTime ?? IÂ´m developing a grid widget and I need in each column define a type of data. With strings is easy but for another values i donÂ´t know do it. As always excuse me for my poor english, and regards. -- View this message in context: http://n2.nabble.com/Input-different-data-types-integers-or-datetimes-in-a-… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 22, 2010

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

by laurent laffont

I've taken a look at TestIndenting>>testCR2 and TestIndenting and TestIndenting>>testNewLineLeaveSpacesOnOldLine which fails on my machine only I needs some hints :) I've attached a screenshot of a debugging session on testNewLineLeaveSpacesOnOldLine. It fails because Form object answered by (para asForm copy: (0@cb top extent: 24@cb height) has at least bit 240 not white. (depth: 32). What should I do/check now ? Laurent On Fri, Jan 22, 2010 at 5:18 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > On Linux, exupery VM > > Laurent > > 2010/1/22 Benoit St-Jean <bstjean(a)yahoo.com> > >> Here's the first test run, on a fresh image (see JPEG attached for >> results). >> >> >> I just unzipped the files, started Pharo and ran the Test Runner. >> >> No preferences changed, nothing even evaluated in a workspace! >> >> I'm on XP if that helps! >> >> >> _______________________________________________ >> 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] Dedicated image now available for Pharo by Example

by StÃ©phane Ducasse

Thanks a lot oscar. Stef On Jan 22, 2010, at 1:51 PM, Oscar Nierstrasz wrote: > > Hi Folks, > > Apparently people have been having problems following Pharo by Example with the latest Pharo images. > > To make their lives easier, I have now added a download link to http://PharoByExample.org for a dedicated image. It is essentially pharo1.0-10451-BETAweb09.09.3 with the OB Package Browser selected by default. It should be 99% consistent with the book. > > Please pass the word on to anyone you know who is experiencing problems following the book. > > - on > > > _______________________________________________ > 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] [ANN 1.0] Pre-cuilt CoreRC2 (#10508)

by StÃ©phane Ducasse

coooooool! We are getting there. On Jan 22, 2010, at 1:12 PM, Marcus Denker wrote: > > http://gforge.inria.fr/frs/download.php/25366/PharoCore-1.0-10508rc2.zip > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > 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] Copy/paste not works

by Igor Stasenko

2010/1/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Igor > > could you try to save the images so that we can spot which changes broke the behavior? > I suspect this is applying the 11161. The problem is that i applied each item in list without saving an image. And there was no bug until i saved & restarted an image. > Stef > On Jan 20, 2010, at 6:03 PM, Igor Stasenko wrote: > >> 2010/1/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> Ok excellent >>> >>>>>>>> Everything works perfectly on #11151 >>> >>> then can you look at the Utilities there is a method that let you update upto a given number. >>> >>> Â Â Â Â updateFromServerThroughUpdateNumber: aNumber >>> >>> so far: >>> >>> 11152 >>> Â Â Â Â - Issue 1773: Â MorphTreeMorph MNU when using keyboard >>> Â Â Â Â - Issue 1775: Â aClass getSource vs aCompiledMethod definition'. >>> >>> 11153 >>> Â Â Â Â "self new update11153" >>> Â Â Â Â self withUpdateLog: 'Issue 268: TODO: CurvierMorph should be merged with PolygonMorph >>> Â Â Â Â Issue 1141: Â Â Monticello directory selection window is non-resizable and very small >>> Â Â Â Â Issue 1770: Â Â Kernel-Tests-ClassBuilder category is not remove after ClassBuilderFormatTests tests are run >>> Â Â Â Â Issue 1774: Â Â Monticello repository edit works but doesnt update UI >>> Â Â Â Â Issue 1780: Â Â StrikeFont issues with derived fonts >>> Â Â Â Â Issue 1782: Â Â Save Dialog too small'. >>> >>> >>> 11154" >>> Â Â Â Â self withUpdateLog: '- Â Issue 1788: Â Â SMTPClient does not send HELO or EHLO, session is not initiated >>> Â Â Â Â - Â Issue 1793: Â Remove SqueakClipBoard >>> Â Â Â Â - Â Issue 1764: Â remove isPvtSelector'. >>> >>> 11155" >>> Â Â Â Â self withUpdateLog: '- Â Issue 1805: Â Â Bitmap fonts need reinitialization >>> Â Â Â Â Â Â Â Â StrikeFont installDejaVu >>> Â Â Â Â - Merged CompilerTests.lr.17.mcz >>> Â Â Â Â merged Compiler-cwp.73.mcz from Colin >>> Â Â Â Â "The compiler now uses notifications to signal that a Â correctable Â Â error has been found in the method source, Â Â Â rather than >>> Â Â Â Â interacting directly with the user." >>> Â Â Â Â - Issue 332: Â Â Arithmetic protocol should be removed from Collections and Strings Â Â Â Â Â Â Â '. >>> >>> >>> 11156" >>> Â Â Â Â self withUpdateLog: '- Issue 1811: Â Â Â FreeType fix for better integration of Rome >>> Â Â Â Â Tx Mike :) >>> - Issue 1151: Â RFC2047MimeConverter>>#readWord is broken, and this may be part of a larger issue >>> Â Â Â Â tx Peter :) (it was not marked as fixed nor 1.1 so skipped our radar) >>> - Issue 1751: Â allPairsDo: aBinaryBlock self do: [:first| self do: [:second| aBinaryBlock value: first value: second]] >>> - Â Issue 1769: Â TestRunner author while running tests >>> Â Â Â Â Â Â Â Â so we will have popup menu problems and in such case should >>> Â Â Â Â Â Â Â Â fix the tests'. >>> >>> update11157" >>> Â Â Â Â self withUpdateLog: 'Issue 1491: Â Â Â Â ImageSegment has special code for Player'. >>> >>> 11158" >>> Â Â Â Â self withUpdateLog: '- Issue 478: Â Â Â [Pending Etoy Cleaning] Object>>defaultNameStemForInstances >>> - Issue 479: Â Â [Etoy Pending Cleaning] Object>> externalName >>> - Issue 491: Â Â [Pending Etoy Cleaning] Morph>>defaultFloatPrecisionFor >>> - Issue 490: Â Â [Pending Etoy Cleaning] Morph >> decimalPlacesForGetter:'. >>> >>> >>> 11158" >>> Â Â Â Â self withUpdateLog: '- Issue 478: Â Â Â [Pending Etoy Cleaning] Object>>defaultNameStemForInstances >>> Â Â Â Â - Issue 479: Â Â [Etoy Pending Cleaning] Object>> externalName >>> Â Â Â Â - Issue 491: Â Â [Pending Etoy Cleaning] Morph>>defaultFloatPrecisionFor >>> Â Â Â Â - Issue 490: Â Â [Pending Etoy Cleaning] Morph >> decimalPlacesForGetter:'. >>> >>> >>> 11160" >>> Â Â Â Â self withUpdateLog: '- Issue 1821: Â Â Â Remove again service -base'. >>> Â Â Â Â self script716. >>> Â Â Â Â ServiceUnloader unloadServicesBasePackage. >>> >>> >>> 11161" >>> Â Â Â Â self withUpdateLog: 'Issue 765: Menu must not be zero size >>> Â Â Â Â Issue 1793: Â Â Remove SqueakClipBoard >>> Â Â Â Â Issue 1790: Â Â basicShallowCopy should be removed >>> >>> may be the SqueakClipBoard? >>> >> >> Everything worked fine even in 11161, >> until i saved image and restarted it. >> So, the bug seems lurking inside a startup/shutdown code. >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Jan. 22, 2010

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

by Eliot Miranda

Hi Ralph, On Thu, Jan 21, 2010 at 10:40 PM, Ralph Boland <rpboland(a)gmail.com> wrote: > Lest I confuse you let me state that I STRONGLY prefer using the > Smalltalk (Squeak in my case) development environment to using > Eclipse. It is also worth pointing out that Eclipse is a development > environment that works with multiple languages whereas in > Smalltalk the development tool and development language are > intimately connected so to compare the two is to compare apples > and oranges. > > 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. > > 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. > 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.) > > 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. > 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. > 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. > 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. There would also be a capability to copy entire > methods/classes/applications/other from the development image to the > application image. Note that in this model there would be need to search > the code base of either image (or both). For example, I may want to find > implementors/senders of method #doSomething in the development image, > the application image, or both. I think being able to search the > application > code base only is especially useful. > > An interesting example is if you were working on the development image > itself. In this case you would of course make as your application a copy > of the development image (and its changes file). Now, in principle you > need > not worry about many of the situations in which you get into an infinite > loop > because you have broken the development environment itself in some way > such as putting a halt message somewhere that get called every time the > debugger is called. > Yes, but what if your are modifying the debugger itself? Well you need > some > kind of command such as: > > #runAsDevelopmentEnvironmentOn: image changesFile: file "A > metacircular interpreter anybody?" > > I am not sure who this message is sent to. > > I am not actually sure if this is a good idea either. Perhaps if you > want to work on the development > environment you start your image with a special flag or simply no > application image. > The development image then becomes editable and there is no > application image; The > development image and application image become one as is the situation now. > > There are doubtless many problems I am not seeing here and even > many ways this may be a good idea that I have not considered. > > Either way I would like to hear what they are. > > How much of an effort would be involved in modifying some version > of Smalltalk (say Squeak) to work this way? (I have NO plans to do this!) > > How much of a benefit would such a version of Smalltalk really be? > > Has this been done before, perhaps in some other language, and what > were the results? > 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. 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? 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". 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. 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 <http://www.wiresong.ca/air/> pages on wiresong yesterday and what he wants is realised by this. 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. 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. Anyway, enough waffle. It's great to hear this idea again. Go for it! > > (Constructive) comments most welcome. > > Regards, > > Ralph Boland > >

Jan. 22, 2010