Squeak-dev January 2008

squeak-dev@lists.squeakfoundation.org

147 participants
192 discussions

Second CfP: Workshop on Self-sustaining Systems (S3) 2008
by Michael Haupt 21 Jan '08

21 Jan '08

Apologies for multiple copies! [Call for Papers] *** Workshop on Self-sustaining Systems (S3) 2008 *** May 15-16, 2008 Potsdam, Germany http://www.swa.hpi.uni-potsdam.de/s3/ -- Call for papers: The Workshop on Self-sustaining Systems (S3) is a forum for discussion of topics relating to computer systems and languages that are able to bootstrap, implement, modify, and maintain themselves. One property of these systems is that their implementation is based on small but powerful abstractions; examples include (amongst others) Squeak/Smalltalk, COLA, Klein/Self, PyPy/Python, Rubinius/Ruby, and Lisp. Such systems are the engines of their own replacement, giving researchers and developers great power to experiment with, and explore future directions from within, their own small language kernels. S3 will be take place May 15-16, 2008 at the Hasso-Plattner-Institute in Potsdam, Germany. It is an exciting opportunity for researchers and practitioners interested in self-sustaining systems to meet and share their knowledge, experience, and ideas for future research and development. -- Invited talk: Ian Piumarta: Late-bound Object Lambda Architectures (Viewpoints Research Institute, USA) -- Submissions and proceedings: S3 invites submissions of high-quality papers reporting original research, or describing innovative contributions to, or experience with, self-sustaining systems, their implementation, and their application. Papers that depart significantly from established ideas and practices are particularly welcome. Submissions must not have been published previously and must not be under review for any another refereed event or publication. The program committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality. Revised papers will be published as post-proceedings in the Springer LNCS series. Papers should be submitted electronically via EasyChair at http://www.easychair.org/conferences/?conf=s3 in PDF format. Submissions must be written in English (the official language of the workshop) and must not exceed 20 pages. They should use the LNCS format, templates for which are available at http://www.springer.de/comp/lncs/authors.html. -- Venue: Hasso-Plattner-Institut (Potsdam, Germany) -- Important dates: Submission of papers: February 15, 2008 Author notification: April 11, 2008 Revised papers due: April 25, 2008 S3 workshop: May 15-16, 2008 Final papers for LNCS post-proceedings due: June 6, 2008 -- Chairs: * Robert Hirschfeld (Hasso-Plattner-Institut Potsdam, Germany) * Kim Rose (Viewpoints Research Institute, USA) -- Program committee: * Johan Brichau, Universite Catholique de Louvain, Belgium * Pascal Costanza, Vrije Universiteit Brussel, Belgium * Wolfgang De Meuter, Vrije Universiteit Brussel, Belgium * Stephane Ducasse, INRIA Lille, France * Michael Haupt, Hasso-Plattner-Institut, Germany * Robert Hirschfeld, Hasso-Plattner-Institut, Germany * Dan Ingalls, Sun Microsystems Laboratories, USA * Martin von Lwis, Hasso-Plattner-Institut, Germany * Hidehiko Masuhara, University of Tokyo, Japan * Ian Piumarta, Viewpoints Research Institute, USA * David Ungar, IBM, USA -- Registration fees: Early (until April 18, 2008) * Regular participants: EUR 160 * Students: EUR 80 Late (after April 18, 2008) * Regular participants: EUR 170 * Students: EUR 90

1 0

Squeak on iPodTouch?
by astares＠gmx.de 21 Jan '08

21 Jan '08

Meanwhile you can port Squeak to Googles Android and win the $10 million award ;) The SDK is already available, it's based on a Linux 2.6 kernel http://code.google.com/android/ The SDK includes an emulator. The VM is called Dalvik-VM. It is possible to convert Java bytecode to it. Therefore they have an Eclipse plugin to develop Android apps in Java. But Squeak would be more fun. As this video proves you can also run OpenGL (-> Croquet) http://www.activityshot.com/2007/11/video-android-opengl-model-viewer.html Have fun Torsten -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

1 0

squeak-dev friendly for newcomer
by Jerome Peace 21 Jan '08

21 Jan '08

squeak-dev friendly for newcomer *** >Damien Cassou damien.cassou at gmail.com >Sat Jan 19 11:01:58 UTC 2008 > >On Jan 19, 2008 11:51 AM, Hilaire Fernandes <hilaire at ofset.org> wrote: >> Squeak-dev is very friendly for newcomer to Squeak. I use it to invite >> people to join on DrGeoII development. >> >> One think could make it even more user friendly: turning on the "_ >> conversion to :=" preference by default. >> >> Of course for Squeak experts who prefer using _ , changing back the >> preference will be easy, far more easier than it will be for newbie. > >This preference does not change the way the method is saved, only the >way it is displayed. I think it can be interesting to turn this on. >What do other think? *** +10 Absolutely necessary. Squeak needs to transition to := in all ways possible. Printing out := means the next time a method is modified and saved it has phased out its use of underscore for assignment. Currently the existence of the preference for printing underscore undermines all the work attempted in 3.9 to transition to :=. You can not use underscore as within a squeak name because: this_is_actually_five_variables := 0 . Even if you used one of Keith Hodge's schemes to intern a variable with an interenal underscore, a round trip fileout and filein would get you the wrong result. So please. Set this preference. (Or, and I highly recommend this, SET the choice and remove the option of a preference). As Hercules found out you can't clean the stables until you are willing to kill all the horses. (And the king tends to get mad at you. ;-) Yours in service and curiosity, --Jerome Peace ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

1 0

Re: Squeak on iPodTouch?
by stephan＠stack.nl 20 Jan '08

20 Jan '08

To get a feeling for what would be needed: http://www.cocoadev.com/index.pl?IPhoneRuntime http://adactio.com/journal.php/1396 http://code.google.com/p/iphoneebooks/ In a month we will know more Stephan

1 0

Fwd: Part II
by Marcus Denker 20 Jan '08

20 Jan '08

> > "Thanks for the information. I have the impression that you stressed > too much the speed of the new compiler. Yes, sorry abou that. > > I know that you use it a lot and that reflectivity is completely > based on it and working great. Indeed, one way to formulate it is that everything that I needed works great. There are some things not yet perfect, but these are fixable. I will send a list of bugs / plan for next steps soon. > > "Is SmaCC the major bottleneck, or is it tree traversal? If > scanning/parsing is the slowest part, perhaps it is worth evaluating > Alex Warth's OMeta as a potential replacement (http://www.cs.ucla.edu/~awarth/ometa/ > ). My intuition would be that OMeta should be *slower* then SmaCC. I did not read the paper and did not benchmark it, but I thought that OMeta would come from the idea that with today's machines it makes sense to revisit the abandoned paths of the 60ties and 70ties wrt. parsing. (Like the work on Generalized LR Parsing and Scannerless parsers done elsewhere). The idea here is that as the machines are so fast and we have so much memory, we can completely rething the algorithms used for parsing, e.g. the only usefull property of LALR parsing is that it is fast and uses not that much memory. Everything else sucks. e.g. the need to carefully massage a simple undestandable LR Grammar into LALR form... and the impossibility to compose grammars. (This is *really* cool with Scannerless Generalizes LR Parsing... very cool for DSLs). > > "Very interesting Markus, thank you very much. Do you think there is > still space for optimizations while keeping the Visitor pattern? > Most of the performance loss is the IR buildup, the other should be SmaCC. The question is if it's really that much of a problem to need a fix now... Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

1 0

Converting blocks to methods
by Martin Beck 19 Jan '08

19 Jan '08

Hi there, has anyone tried to accomplish something like MyNewClass addMethod:#doSomethingWith: with: [ :arg | Transcript show: arg]. MyNewClass new doSomethingWith: 'Hello World'. in Squeak? This would mean, to convert a block into a method, thus changing the hole semantics. Outer temporaries or other variables are of course forbidden. Literals have to be fetched out of the defining method and brought into a new compiled method and so on. Or perhaps there are other possibilities? Any ideas? Regards, Martin

3 2

Converting blocks to methods
by Marcus Denker 19 Jan '08

19 Jan '08

Hi, > > has anyone tried to accomplish something like > > MyNewClass addMethod:#doSomethingWith: with: [ :arg | > Transcript show: arg]. > > MyNewClass new doSomethingWith: 'Hello World'. > > in Squeak? This would mean, to convert a block into a method, thus > changing the hole semantics. Outer temporaries or other variables > are of > course forbidden. Literals have to be fetched out of the defining > method > and brought into a new compiled method and so on. Or perhaps there are > other possibilities? Any ideas? > one idea could be to just build a tiny compiledmethod that calls the Block. e.g., you can store the block in the literalframe of the that method and then call value:... on it with the correct arguments. As it's just a "pushLiteral, send value", with #value being a primitive method, this should be not too slow. Especially it preserves the semantics of the block, converting blocks into non-blocks is normally no good idea as you need to explain people that they are not allowed to use outer references... So I would keep the block. Blocks are cool. This would be fairly easy to do with IRBuilder, as you can just push the block as a literal, generate a method that calls this then with the correct value:... this would look like this: addMethod: selector with: aBlock | irBuilder args | args := (aBlock tempNames collect: #asSymbol) asArray. irBuilder := IRBuilder new numRargs: 1 + aBlock numArgs; addTemps: #(self); addTemps: args; pushLiteral: aBlock. "push the block as a literal" args do: [:each | "maybe this needs to be done in reverse?" irBuilder pushTemp: each ]. irBuilder send: aBlock valueSelector. irBuilder returnTop. self basicAddSelector: selector withMethod: irBuilder ir compiledMethod (this needs the latest NewCompiler and the attached changeset). Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

1 0

Using a Form and Canvas in Seaside.
by stephan＠stack.nl 19 Jan '08

19 Jan '08

Sophie wrote >> Are either of these two either available or shareable? > > I meant your BalloonCanvas-usage or Mondrian-usage examples :-) not > Mondrian and dotty, which I know. Dotty is used by gjallar. Here is a simple app using a Canvas. It needs Magritte and Seaside. Developed on 3.10 Stephan (cross-posted to seaside and squeak-dev)

1 0

Use FFI to dynamically load shared library on Mac OS 10.5
by James Foster 19 Jan '08

19 Jan '08

I'm trying to dynamically load a shared library (.so) and consistently get "Unable to find function address." I have tried putting the library in a variety of locations (next to the executable, next to the image, next to the FFI package, etc.) and I have set the environment variable DYLD_LIBRARY_PATH to the location of the library. Nothing seems to work (although the FFI tests all pass). Any advice? James Foster

5 9

About the new compiler, Part II
by Marcus Denker 19 Jan '08

19 Jan '08

Part II: Examples ----------------------- I was made aware that the first part put far to much emphasis on performance of compilation. I think it's true that it's fairly unimportant, I did that because in an ealier thread we got a comment that suggested that the compiler has to be bad just because of that. This is of course completely not the case, performance of compilation is not at all that important... especially considering today's machines. And both SmaCC nor the rest of the Compiler were ever optimized for speed of compilation... What counts is flexibility and good design, so that the code is maintainable, reusable and enables experiments. So I hope this part emphasis the right points better. Having a framework with the right abstractions simplifies everything... "Modeling is cheating". So the question was if the modular design with all these visitors, the use of SmaCC instead of a hand-written parser and the IR at the end really are that interesting to have... I think they are, but the only way to prove it is to explain a bit what we used the framework for in the past. For all these, the architecture proved to be quite useful. All the things mentioned in the following are *not* part of the NewCompiler. They have been build using it, and while building them, we fixed bugs and generalized the framework a little. So what did we do with the NewCompiler Framework? 1) Language experiments. Some time ago, I did a small experiment for Impara with different syntax for Squeak. The stated goal was to see how little is needed for having python or JS like syntax in Squeak. (Of course, the result was that just having the syntax is not enough: It's completely unclear where the similarity to the other language brakes down, and thus it's unusable.. people want to pick a book and just type in the code without even undestanding it completely... the semantics are where it starts to get interesting and *a lot* of work). But it's a cool demo... and easy to do: Grammar of JS in SmaCC, AST Nodes for all constructs, then a visitor that calls the IRBuilder to generate code. No dealing with bytecode, but nevertheless the complete freedom of bytecode abstraction level code generation. Slides (Squeak image with all code): http://www.iam.unibe.ch/~denker/talks/BabelTalk.zip 2) Bytecode Transformation. I got interested in Behavioral Reflection some time ago, and wanted to implement the Reflex model of partial behavioral Reflection [1] with a student (David Roethlisberger). For that, we needed bytecode transformation (at least at that time we thought so...). So we looked at Javassist [2] and inspired from that build ByteSurgeon. The idea here is that we want to insert (or replace) code at any bytecode instruction. Of course, we don't want to write the to-be-inlined code as bytecode itself, and we do not want to deal with the very low level view of bytecode where there a many different send-bytecodes, for example. When you look now at the NewCompiler framwork, then there are two things directly trivially visible: 1) The IR is exactly on the right level of abstraction. 2) Implementing a small compiler to generate us the to-be-inlined code as IR is trivial with the the modular design. So this is what we did... added transformation (adding/deleting nodes) to the IR, wrote a Compiler as a simple subclass of the standard SmaCC based compiler that generates IR (extended with special syntax to be able to access e.g. the receiver and arguments of a send). Then the bytecode inling framework is a simple thing. As an example, here is a the code that would annotate the class Example to log the receiver objecrs of all message sends: Example instrumentSend: [ :sendInstr | sendInstr insertBefore: ’Logger logSendTo: <meta: #receiver> ’ ]. More information: Slides: http://www.iam.unibe.ch/~denker/talks/ByteSurgeon-slides.pdf Paper: http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Denk06a ByteSurgeon was then used as the basis for some things: -> first Geppetto (Unanticipated Partial Behavioral Reflection) Slides: http://www.iam.unibe.ch/~denker/misc/GeppettoESUG2006.pdf Paper: http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Roet08a -> a proof-of concept implementation of an Omniscient Debugger similar to Bill Lewis' work for Java: Slides: http://www.iam.unibe.ch/~denker/talks/06NODE/UnstuckNode06.pdf Paper: http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Hofe06a -> It's one of the backends in the Test Coverage tool Christo done by Stefan Reichart http://smallwiki.unibe.ch/stefanreichhart/codecoverage/ 3) Compiler hack: Global variables as message sends. For ChangeBoxes, Pascal Zumkehr needed globals not the be hard- coded, but to be accessed via message sends. For this, he changed the NewCompiler. It's easy to do, and he did it after a short introduction over the NewCompiler. The old compiler is quie arcane for all these things. (But for sure as soon as you get used to the patterns it's not impossible... but I think it's odd way of coding) Paper: http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Denk07c 5) Sub-Method Reflection Joined work with Phillippe Marschall. This uses the SmaCC/RB-AST part of the NewCompiler to generate "Reflective" Methods that use and extendend AST instead of bytecodes, and it provides a small in-image "JIT" that generate bytecode on-demand, which is based on the standard NewCompiler backend. Slides: http://www.iam.unibe.ch/~denker/talks/07TOOLS/07PersephoneTOOLS.pdf Paper: http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Denk07b This was used e.g. for Adrian Lienhard's work on first class aliases and Object-Flow Analysis http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Lien07a http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Lien07c 6) Textual Annotations on every language constructs. Phillippe provided textual annotations for all language constructs in the Persephone system. This was realized as it's own extended smalltlak compiler (based on the SMacc grammar) Nik Haldiman used this to build a pluggable type system for Squeak. Slides: http://www.iam.unibe.ch/~denker/talks/07ESUG/07TypePlugESUG.pdf Paper: http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Hald07b 6) Reflectivity. This merges sub-method reflection with partial behavioral reflection. Homepage: http://www.iam.unibe.ch/~scg/Research/Reflectivity/index.html Slides: http://www.iam.unibe.ch/~denker/talks/07DYLA/07ReflectivityDylan.pdf This was used e.g. -> for Dynamic Analysis http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi?query=Denk07d&abstract=yes -> for Transactional Memory (Lukas Renggli): http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Reng07b -> HistOOry, by Frederic Pluquet: http://decomp.ulb.ac.be/frdricpluquet/researchactivities/histoory/ So, all in all I am quite convinced that an open, reusable compiler infrastructure provides *huge* benefits for building experiments and tools and thus exploring the future. Next part: -> Closures and Performance of Closure code. (this may take some days... busy) In addition, I will try to answer the questions that came up and give a status report soon. Marcus (I am not subscribed to Squeak-dev anymore, so please CC: me) References ========== [1] Reflex: http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Tant03a [2] Javassist: http://www.csg.is.titech.ac.jp/paper/chiba-gpce03.pdf -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
20
Older →

Jump to page: