- Pharo-dev - lists.pharo.org

[Pharo-project] CFPaper: 4th Workshop on Dynamic Languages and Applications
by Alexandre Bergel Jan. 25, 2010

Jan. 25, 2010

4th Workshop on Dynamic Languages and Applications (DYLA 2010) (collocated with TOOLS) categories: programming languages, software engineering, computer science When: Jun 28, 2010 - Jun 28, 2010 Where: Malaga, Spain Submission Deadline: Mar 31, 2010 Notification Due: May 14, 2010 Final Version Due: May 31, 2010 link: http://scg.unibe.ch/wiki/events/dyla2010 Call For Papers The DYLA Workshop series focuses on the revival of dynamic languages. These days, dynamic languages (like Ruby, Python, JavaScript, Lua, etcâ¦) are getting ever more popular. This is a call to arms for academia! We need to explore the future of dynamic languages through its human aspects and technical issues. We also ought to look back and pick up solutions from existing dynamic languages (such as Scheme, Smalltalk, or Self) to be rediscovered and spread around. Goal and Topics The goal of this workshop is to act as a forum where we can discuss dynamic languages and their applications. Topics of interest include any topic relevant in applying and/or supporting dynamic languages: Ruby, Python, Groovy, JavaScript, Lua, Clojure, Lisp, Scheme, Smalltalk, Self, ABCL, Prolog, and many moreâ¦ Human aspects of dynamic languages, such as â empirical studies about the application of dynamic languages â best practices and patterns specific to dynamic languages â program correctness through unit testing (as opposed to types) â improved or novel IDE support for dynamic languages â use of dynamic features by library & framework developers â scripting of static application with dynamic languages â reverse engineering and analysis of dynamic applications Technical aspects of dynamic languages, such as â what features make a language a dynamic one? â agents, actors, active object, distribution, concurrency and mobility â delegation, prototypes, mix-ins, traits â first-class closures, continuations, environments â reflection and meta-programming â automated reasoning about programs written in dynamic languages â (concurrent/distributed/mobile/aspect) virtual machines â optimization of dynamic languages â multi-paradigm & static/dynamic-marriages â type systems for dynamic languages â (dynamic) aspects for dynamic languages â higher-order objects & messages â â¦other exotic dynamic features Submissions The workshop will have a demo-oriented style. The idea is to allow participants to demonstrate new and interesting features and discuss what they feel is relevant for the dynamic language community. Participants need to submit a 2â4 page position paper of their work in ACM, sig-alternate.cls format. At the workshop, participants will be asked to give 10-minute âlightning demosâ of their contributions. Submission page is https://www.easychair.org/login.cgi?conf=dyla10 Organizers â Alexandre Bergel, Univ of Chile, â Carl Friedrich Bolz, Heinrich-Heine-Univ, DÃ¼sseldorf, Germany â Simon Denier, INRIA Lille, France â Michael Haupt, HPI Potsdam, Germany â Adrian Kuhn, Univ of Bern, Switzerland Program Committee â Tom Dinkelaker, Technische Univ Darmstadt, Germany â Johan Fabry, Univ of Chile â Matthew Flatt, Univ of Utah, USA â Stephan Herrmann, TU Berlin, Germany â Abram Hindle, Univ of Waterloo, Canada â Kasper Lund, Google, Denmark. â Michael Perscheid, HPI Potsdam, Germany â Rodolfo Toledo, Univ of Chile â Niko Schwarz, Univ of Bern, Switzerland â Peter Sommerlad, HSR Rapperswil, Switzerland â Alessandro Warth, Viewpoints Research Institute, USA â Vadim Zaytsev, Univ of Koblenz, Germany For further information, please visit our website or follow us on twitter â http://bit.ly/dyla2010 â http://twitter.com/dyla2010 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

[Pharo-project] about imageSegments
by StÃ©phane Ducasse Jan. 25, 2010

Jan. 25, 2010

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

6 16

[Pharo-project] [update] #10507
by Adrian Lienhard Jan. 25, 2010

Jan. 25, 2010

10507 ----- Issue 945: Annoying bug: UndefinedObject(Object)>>doesNotUnderstand: #mimeTypes Issue 1769: TestRunner author while running tests Issue 1772: testSymbolTableM6812 is failing Issue 1815: Monticello prints class definitions to the transcript while loading Issue 1841: Make the System -> Software update a preference for 1.0 Issue 1861: Use old network (note: to take effect you need to restart the image) Issue 1771: testFinalizationOfEquals sometimes fails and sometimes doesn't With this update, all pending 1.0 issues have been resolved and tests are green. If no new issues pop up soon, we are going to declare this version as RC2. Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/

7 19

Re: [Pharo-project] Pharo dev image rc2 thoughts
by Dale Henrichs Jan. 25, 2010

Jan. 25, 2010

Mariano, The progress-bar problem is solvable. The progress bar problem appears because the dev image doits reinitalize the progress bar class. The first question is: "Must the progress bar code be initialized?" if no, then remove the initialization code and the problem should be solved:) If yes, then I will dig into the problem and see what I can come up with ... there are a couple of routes I can take, but I'd like to know that we can't bypass the initialization before getting my hands that dirty:) Dale ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: | 2010/1/24 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> | | > | > Now to the point. I understand that the separation of concerns is | good, | > because ImageForDevelopers is already a separated and tested | package | > that shouldn't be inside ConfigurationOfPharo. | > | | I will tell you a bit the background: First, when I took the | installScript | from Damien, there where some stuff done in the script (like settings | the | preferences and the fonts) done in the installScript. It didn't have | sense | for me (of course I asked Damien) and I put that in ImageForDevelopers | (and | this is cool because it is versiones with monticello). Actually in | DEVImageCreator >> install. I need also to clean that class as it has | a lot | of old stuff. But not time for the moment. | | When I create rc1, ImageForDevelopers was a dependency of | ConfigurationOfPharo as you said. There was a problem installing it | with the | progress bar and Metacello. The image just frezze because of a | sempahore and | a delay....see issue: | http://code.google.com/p/metacello/issues/detail?id=39 | But I can even reproduce the problem....So, that quick solution (as I | needed | to relase the Pharo image) was to put in the installScript. | | And after a while I discovered that I even like more that approach. | Someone | may want just the packages of a dev image, but not to set | preferences, | fonts, cleanups, etc. And I don't have the Metacello bug. | The problem I found also putting it as a dependency is that it has to | be the | LATEST (I think that you cannot even said that XX package has to be | the last | one to be loaded) package to be loaded. I can put it as postDoIt for | the | project, but this cannot be done because it is ONLY required for | certain | groups | | | > - Shouldn't be necessary to create a | ConfigurationOfImageForDevelopers | > and in this configuration reference ConfigurationOfPharo and then | the | > installScript for the dev image use *only* | > ConfigurationOfImageForDevelopers? | > | > | It can work, but actually for me we are having a problem (maybe we | need the | support the post/pre doit for groupos...but dale said it was | complicated). I | would like to just do (ConfigurationOfPharo project version: 'XXX') | load:'ImageForDeveloper' |

3 2

[Pharo-project] [update 1.1] #11180
by Marcus Denker Jan. 24, 2010

Jan. 24, 2010

11180 ----- Issue 1383: Behavior>>isAbstractClass Issue 1869: add MC package clean to ScriptLoader releaseclean script -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Fwd: [squeak-dev] Smalltalk vs Eclipse
by StÃ©phane Ducasse Jan. 24, 2010

Jan. 24, 2010

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 :)

3 3

[Pharo-project] Deadlock detection for testcases
by Stefan Marr Jan. 24, 2010

Jan. 24, 2010

Hi: Have currently a lot of trouble with tests which are just deadlocking. Here is quick hack which specifies a timeout for test cases. Maybe it is useful for others, too. Any suggestions for improvement are welcome. Best Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525

6 9

Re: [Pharo-project] [Pharo-users] Is there a tool to get the diff of two different classes?
by Mariano Martinez Peck Jan. 24, 2010

Jan. 24, 2010

On Sat, Jan 23, 2010 at 7:52 PM, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hi: > > I already found the DiffMorph which looks like it takes just two strings. > So, I wondered whether there might already be something where I can just > input the classnames and get a nice view of all differences? > I really don't know, but I would love to have that too. Many times I had the same problem. > > Thanks > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr <http://soft.vub.ac.be/%7Esmarr> > Phone: +32 2 629 3956 > Fax: +32 2 629 3525 > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

1 0

[Pharo-project] Pharo dev image rc2 thoughts
by Miguel Enrique CobÃ¡ Martinez Jan. 24, 2010

Jan. 24, 2010

First that anything, thanks to Mariano for all the effort put in order to release a 1.0 version of Pharo. And to all the contributors also. As part of incorporating Metacello to my projects, I have gain a little more insight in the working of it. For that I have been studying the existing configurations. I even contributed a pair to the repository. Tonight I was building a Pharo image using the ConfigurationOfPharo. The announce said nothing but the inner workings of the dev image creations changed, although the result is exactly (with a lot of fixes included) the same that the rc1 image created with Metacello. The changes are this: - in rc1, it was only necessary ConfigurationOfPharo to build a complete Pharo dev image. That is ConfigurationOfPharo included ImageForDevelopers. - in rc2, ConfigurationOfPharo isn't enough to build a dev image (I noticed this tonight because I used ConfigurationOfPharo alone to build an image but in the end I didn't get autocompetition), it is also necessary to run a second script to load ImageForDevelopers and install it. This is all done in the installScript.st script included in the pharo rc2 dev image. As I said before, the results are the same, but before all was done in the ConfigurationOfPharo and now requires two steps. Now to the point. I understand that the separation of concerns is good, because ImageForDevelopers is already a separated and tested package that shouldn't be inside ConfigurationOfPharo. - Shouldn't be necessary to create a ConfigurationOfImageForDevelopers and in this configuration reference ConfigurationOfPharo and then the installScript for the dev image use *only* ConfigurationOfImageForDevelopers? - It appears that Dale will announce project preload/postload doIts next monday. If that happens, shouldn't be better to incorporate the code from DEVImageCreator as preload/postload do its to the ConfigurationOfPharo? It appears to me that DEVImageCreator is a mixture of different things, both preference tuning (setDefaultPreferences, setFonts) image fixing (addPreferenceCategories, cleanOpenMenu) and image building stuff (writeListOfPackages, showWelcomeWorkspaces). Maybe the image fixing stuff should be a change incorporated to the PharoCore image, and the preference tuning should be a postload do it for the ConfigurationOfImageForDevelopers, and the image building stuff should be in the install script. This way, if someone wants to build a image for developers (but without the list of packages, or welcome workspaces) it only has to use ConfigurationOfImageForDevelopers. Also, maybe after all this refactoring, the ConfigurationOfImageForDevelopers isn't necessary because all can be incorporated to the ConfigurationOfPharo as preload/postload do its. That is fine. Also, the image for developers has stuff for squeak. This refactoring would permit to separate them in preload/postload for each platform, in a cleaner way. As I said at beginning, this is only thoughts, and the current result image is the same as the one produced by the previous configuration, but maybe, with more time and less pressure, this refactoring and cleaning could be made. Of course, I will try to do this and contribute the code as my time permits, but if someone can do it sooner, the better for all of us. Thanks again for the hard work -- Miguel CobÃ¡ http://miguel.leugim.com.mx

3 4

[Pharo-project] Update!! Packages and Projects working on Pharo [WAS] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2
by Mariano Martinez Peck Jan. 24, 2010

Jan. 24, 2010

Thanks Adrian. I will point to that link also in next image. Now....can we update that wiki ? I know there are severaaaal more projects and packages that run in Pharo. We can even update that table and put some information about metacello...as most of those packages are loaded now with Metacello. Someone volunteer to do update this ? On Sat, Jan 23, 2010 at 9:06 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Maybe it would be better to add these definitions to a wiki page or to the > website. Like this we can add new ones and update existing ones independent > of releases. In the welcome workspace you could then just point to the URL > that contains the current list. There is already a related wiki page: > http://code.google.com/p/pharo/wiki/PackagesTestedInPharo > > Cheers, > Adrian > > On Jan 22, 2010, at 17:58 , 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 >

1 0