Squeak-dev January 2008

squeak-dev@lists.squeakfoundation.org

147 participants
192 discussions

Any current package for Aspect-like functionality
by itsme213 27 Jan '08

27 Jan '08

I would like to investigate using some aspect-like functionality in my app (the behavior & state of many of my objects should (appear to) be different depending on the context in which they are used). I found AspectS and PerspectiveS on SqueakMap, but they seem to be dated and inactive. Anyone know of any current & reasonably stable package for Aspect-like functionality? Thanks - Sophie

3 9

(no subject)
by bryce＠kampjes.demon.co.uk 26 Jan '08

26 Jan '08

Subject: Smalltalk UK meeting on Saturday 8th March X-Mailer: VM 7.17 under 21.4 (patch 20) "Double Solitaire" XEmacs Lucid Bcc: bryce(a)kampjes.demon.co.uk --text follows this line-- We're organising a Smalltalk event in London. This is going to be on a Saturday afternoon, we'll probably head to a pub afterwards. We'll aim to get a room with a projector. Details are here: http://www.xpdeveloper.net/xpdwiki/Wiki.jsp?page=SmalltalkUK20080308 RSPV required as it's being hosted in corporate offices. Please add your name if you're interested in either attending or presenting. Bryce

1 0

Focus on a stringMorph embedded in a PastupMorph
by Hilaire Fernandes 26 Jan '08

26 Jan '08

I have a pasteupmorph with a StringMorph into it. When I request (through an external command) edit with the launchMiniEditor, I immediately lose the the focus of the string morph. To get it working I first need to click in the background of the PasteUpMorph. I have tried various message for keyboard/mouse focus without success. Kazuhiro Abe suggested to us a MouseButtonEvent as follow: anEvent := MouseButtonEvent new setType: #mouseDown position: aStringMorph bounds center which: 4 buttons: 12 hand: aStringMorph currentHand stamp: nil. anEvent handler: aStringMorph owner. aStringMorph launchMiniEditor: anEvent. But it does not help. Any clue? Hilaire

1 1

About the new compiler, Part I
by Marcus Denker 26 Jan '08

26 Jan '08

Part I: Compiling is slower, so it's bad ========================================= This part will not talk about closures at all, just about the overall system archicture of the compiler. I will write with Math something about Closures, their design and performance later. Before I go into the details, I think I need to clearify one thing: from the start, I always saw Squeak in terms of it's possibilities, never as "what it is now". I think all what follows comes from that point of view. If you see Squeak an artifact that should never be changed, then you won't like any of the arguments that follow. But I am truly convinced that the greatness of Squeak never was the artifact, it was always the possibility it promised. So.The Compiler is slower to compile code (factor ca. 4). But then, this is not that of a problem. Most people will now think about the slowness of loading code with MC, but that has multiple causes, the compiler is not the slowest thing here... (in 3.9, we managed to speed up code loading with MC by a factor of two just by caching the class category in the "category" variable of the class objec). Another "problem" of the NewCompiler is that it has far more classes then the old one. Horrible for some people, but interestingly, this makes it far easier to understand than the old one... So, Slower and More Classes. What do we get for that? Of course we need some payout. One is that the NewCompiler is *far* easier to understand. I can explain it to a student in half an hour, and the student can hack it. Slower. The Slowness is caused by two things: 1) Use of SmaCC for parsing 2) multi-pass visitor based architecture. Before explaining (with examples) why both are indeed very nice to have, I will in this Part I just do a short overview of the architecture. 1) Scanning/Parsing. This is wher the text is analyzed and a tree- structure (AST) is build up. The NewCompiler does not implement the Scanner/Parser "by hand", but instead it uses a Parser-Generator. This is an application that takes a description of the Grammar of the language in a fairly standardized form (BNF). Then this is compiled using the Parser Generator to build the Scanner/Parser classes. The nice thing about this are three things: 1) easier to understand and modify (grammar is formulated as a grammer) 2) less bugs, as the grammar is transformed automatically. This is not that important for a simple language is Smalltalk. 3) Easy to modify, Easy to add a slightly changed / extended Smalltalk-like language. (We see examples for that later) 2) The AST (Abstract Syntax Tree). This encodes the syntax as a tree. For a compiler, a very simple AST is mostly enough. For the NewCompiler, the AST of the Refactoring Browser was used instead. This is an overkill for a compiler, but it has some cool aspects: 1) One AST for the sytem. No duplicated code between the RB and the Compiler. Less bugs. 2) the RB can use the Parser of the Compiler. No problem with differences, less duplicated code. The nice thing about the RB AST are two things: Visitors and Transformations. Visitors are used a lot in the NewCompiler. 3) Now we have the AST. The AST does not encode any semantics yet, e.g. meaning of variables. We know that there is Variable "a", but is it a definition or use? Are variables shadowing each other? This we need to check and add information to all variables. For this, we have a Visitor that walks over the AST, grows a scope-chain for each block entered, records variable definitions, annotated variable uses with the definition that it referes to. 4) The annotated AST now can be used to generate Code. The NewCompiler uses a very nice small "Squeak Assembler" to emit the code. The class for Code Generation is ASTTranslator. Again a visitor, walks over the tree and calls IRBuilder to emit code. Here in ASTTranslator the magic happens for the inlining of if/and/ while and so on: acceptMessageNode: aMessageNode aMessageNode isInlineIf ifTrue: [^ self emitIfNode: aMessageNode]. aMessageNode isInlineIfNil ifTrue: [^ self emitIfNilNode: aMessageNode]. aMessageNode isInlineAndOr ifTrue: [^ self emitAndOrNode: aMessageNode]. aMessageNode isInlineWhile ifTrue: [^ self emitWhileNode: aMessageNode]. aMessageNode isInlineToDo ifTrue: [^ self emitToDoNode: aMessageNode]. aMessageNode isInlineCase ifTrue: [^ self emitCaseNode: aMessageNode]. ^ self emitMessageNode: aMessageNode Uncomment the line with "isInlineIfNil" --> no compiler generates normal message send for ifNil:. Easy. 5) The IRBuilder. A symblic assembler for Squeak Bytecode. Here is an example of a method that compared the first iVar with the argument and returns yes or no ir := RBuilder new numRargs: 2; addTemps: #(self a); "rcvr, arg" pushTemp: #self; pushInstVar: 1; pushTemp: #a; send: #=; jumpAheadTo: #else if: false; pushLiteral: 'yes'; returnTop; jumpAheadTarget: #else; pushLiteral: 'no'; returnTop; ir. we can run this method likes this: ir compiledMethod valueWithReceiver: (5@4) arguments: #(5) As the "ir" suggests, this bytecode assembler does not directly generate bytecode, but it builds up an Intermediate Representation instead. This is nice, as it allows the backend to be changed quite easily, so changeing the bytecode encoding is easy with this kind of architecture. The other thing is that on the IR, we can do transformation, too. (example later). The IRBuilder can be used to implement compiler for other languages, it's actually very simple to do: walk the AST of your language, call method on the IRBuilder. (Example later). 6) ByteCodeBuilder now is called by the IRBuilder to emit bytecode and build a compiledMethod object. This is the only class that encodes the actual bytecode set used. So, comparing that to the old compiler, it's actually amazing that this is just slower by a factor of 4. It's not a black box compiler, it's a "Compiler Framework" that can be used to experiment. Building yout own compiler is simplified a lot with this framwork. Part II will show some examples for how we used this compiler framework in the past. I will try to write that later today. There are some slides that explain all this in some more detail: http://www.iam.unibe.ch/~denker/talks/07SCGSmalltalk/11Bytecode.pdf Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

12 17

Simple lock up with delay + semaphore - not fixed with 0006576
by Georg Köster 26 Jan '08

26 Jan '08

Hi all, I'm trying around with Croquet since a short while and stumbled over a bug in TPromise, but after a first fix there I also found that I could lock up my squeak (3.8.18beta1U on os x 10.5) as simply as this: |s b c| s := Semaphore new. b := false. [b := true. "forgotten/crashed therefore no: s signal." ] fork. Delay timeoutSemaphore: s afterMSecs: 1. s wait. c := b. Transcript show: c; cr. This shows the use case. Shorter even: |s| s := Semaphore new. Delay timeoutSemaphore: s afterMSecs: 1. s wait. Transcript show: 'doesnt get here - not printed'; cr. I hope I'm doing something wrong here! I pasted the fixes from 6576 and 6588 to no avail. I have this fix for my use-case: Avoid Delay>>timeoutSempaphore:afterMSecs: |s| s := Semaphore new. [(Delay forSeconds:1) wait. s signal.] fork. s wait. Transcript show: 'Now gets here - line will be printed'; cr. Resource intense, I know. I would love to use your Delay mechanism! Cheers, Georg

5 15

3 positions for french speaking Smalltalkers at Paris
by Noury Bouraqadi 25 Jan '08

25 Jan '08

More on my web site http://vst.ensm-douai.fr/noury/SmalltalkJobAndInternshipOffers#2008-01-25 Regards, Noury Bouraqadi ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------

1 0

Musings about modularity and programming in the large
by Jason Johnson 25 Jan '08

25 Jan '08

Hi all, Recently working in other high level languages I was thinking about how modularity is accomplished in these systems and how we might do it in Squeak. Now we could of course simply add something trivial that formalizes the prefixes we are using now and hide them for us (sometimes), but this doesn't really help our position much or make us much better at "programming in the large". Looking at other systems, Haskell, Ocaml and Lisp, it is interesting how they tackle this problem. What these systems all have in common is a pretty simple idea: a module declaration defines what is "exported" or visible from outside the module (or at least can be made so) and everything else is only visible to code inside the module. So combining this simple concept with Smalltalk's unique "objects all the way down" philosophy it occurred to me that a module could appear as simply a class like any other. The typical "import" mechanisms could be ignored, and export is handled as it is now. That is, today all classes and objects "export" methods; they simply respond to the ones they implement and DNU the ones they don't. Today, in Squeak all classes are inserted into a global namespace and are therefor visible from anywhere. With this module system I'm talking about, it would still work this way, but when one creates a new module, only the "module class" would be inserted. Any classes inside the module would not be inserted into the global namespace and would therefor not be visible globally. The "module class" could chose to behave completely as a normal class, i.e. the messages it exports/answers do their work by using the module's internal classes and objects, as well as global classes and other modules. An example of this might be a Seaside application which simply/responds to #renderOn: but internally has a complex series of class/objects determine the behavior. From the point of view of Seaside there is just one class that receives the render request. This is actually what we have right now, but the difference is that today every class even remotely involved in the application is visible everywhere, despite being essentially "private" to the application. The "module class" could also chose to behave as a "namespace", simply restricting access to its internal classes. But the most common behavior would likely be a hybrid between these two possibilities. That is, often you would send a message to this visible "module class" and it would behave as though it were a normal class. Other times you might send a message and the return value would be an instance of one of the modules internal classes (think, a regular instance creation method like Point>>x:y: that just happens to return an initialized instance from a class inside the module). Now, the question of course comes up of how such a system would look, be implemented, etc., etc. and I haven't really thought about that part yet. I'm sure I'm not the first person to think of such a system, so my question is: what systems do you all know about that sound like what I have described? Thanks, Jason

14 40

Dynamic Languages Symposium (DLS) 2008 -- Call for Papers
by Robert Hirschfeld 25 Jan '08

25 Jan '08

CALL FOR PAPERS *** Dynamic Languages Symposium (DLS) 2008 *** July 8, 2008 (Tuesday) Co-located with ECOOP 2008, Paphos, Cyprus Sponsored by ACM SIGPLAN http://www.swa.hpi.uni-potsdam.de/dls/dls08/ ------------------------------- IMPORTANT DATES ------------------------------- Submission deadline: April 25, 2008 (hard deadline) Author notification: May 23, 2008 Camera-ready copy due: June 6, 2008 DLS 2008: July 8, 2008 ------------------------------- ABOUT DLS ------------------------------- The Dynamic Languages Symposium (DLS) at ECOOP 2008 in Paphos, Cyprus, is a forum for discussion of dynamic languages, their implementation and application. While mature dynamic languages including Smalltalk, Lisp, Scheme, Self, Prolog, and APL continue to grow and inspire new converts, a new generation of dynamic scripting languages such as Python, Ruby, PHP, Tcl, and JavaScript are successful in a wide range of applications. DLS provides a place for researchers and practitioners to come together and share their knowledge, experience, and ideas for future research and development. DLS 2008 invites high quality papers reporting original research, innovative contributions or experience related to dynamic languages, their implementation and application. Accepted Papers will be published in the ACM Digital Library. ------------------------------- TOPICS OF INTEREST ------------------------------- Areas of interest include but are not limited to: - Innovative language features and implementation techniques - Development and platform support, tools - Interesting applications - Domain-oriented programming - Very late binding, dynamic composition, and runtime adaptation - Reflection and meta-programming - Software evolution - Language symbiosis and multi-paradigm languages - Dynamic optimization - Hardware support - Experience reports and case studies - Educational approaches and perspectives - Object-oriented, aspect-oriented, and context-oriented programming ------------------------------- SUBMISSION GUIDELINES ------------------------------- We invite original contributions that neither have been published previously nor are under review by other refereed events or publications. Research papers should describe work that advances the current state of the art. Experience papers should be of broad interest and should describe insights gained from substantive practical applications. The program committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality. Papers are to be submitted electronically at http://www.swa.hpi.uni-potsdam.de/dls/dls08/ in PDF format. Submissions must not exceed 12 pages and need to use the ACM format, templates for which can be found at http://www.acm.org/sigs/pubs/proceed/template.html. ------------------------------- PROCEEDINGS ------------------------------- Accepted Papers will be published in the ACM Digital Library. ------------------------------- PROGRAM COMMITTEE ------------------------------- Chair: Johan Brichau (Université catholique de Louvain, Belgium) Joe Armstrong (Ericsson AB, Sweden) Pierre Cointe (École des Mines de Nantes, France) William R. Cook (University of Texas at Austin, USA) Pascal Costanza (Vrije Universiteit Brussel, Belgium) Wolfgang De Meuter (Vrije Universiteit Brussel, Belgium) Maja D'Hondt (IMEC, Belgium) Robert Hirschfeld (Hasso-Plattner Institüt, Germany) Roberto Ierusalimschy (PUC-Rio, Brazil) Andy Kellens (Vrije Universiteit Brussel, Belgium) Michele Lanza (University of Lugano, Switzerland) Michael Leuschel (University of Düsseldorf, Germany) Oscar Nierstrasz (University of Berne, Switzerland) Kent Pitman (PTC, USA) Lynne Shaw (CheckFree Investment Services, USA) David Ungar (Sun Microsystems, USA) Peter Van Roy (Université catholique de Louvain, Belgium) Martin von Löwis (Hasso-Plattner Institüt, Germany) Daniel Weinreb (ITA Software, USA) -- Robert Hirschfeld hirschfeld(a)acm.org www.hirschfeld.org

1 0

Common enough to include it?
by Sebastian Sastre 24 Jan '08

24 Jan '08

Hi there, I've found a couple of simple but nice conveniences in collections: A) To be able to do things like: persons collectAspect: #surname collectAspect: aSymbol "Collects the element's answer to aSymbol" ^ self collect:[:each| each perform: aSymbol] B) To be able to do things like: 1 to: 12 collect:[:i| (Month nameOfMonth: i) asString ] to: stop collect: aBlock "Evaluate aBlock and adds it's answer to results for each element of the interval (self to: stop by: 1)." | nextValue results | nextValue _ self. results := OrderedCollection new. [nextValue <= stop] whileTrue: [results add: (aBlock value: nextValue). nextValue _ nextValue + 1]. ^ results Maybe they are universal enough to include in base? cheers, Sebastian Sastre PS: I'm proposing to use this #collectAspect: in the very same way of #pluck as you can found it in Prototype enumerable, a kind of collection abstraction for javascript.

5 6

squeak-dev friendly for newcomer
by Hilaire Fernandes 24 Jan '08

24 Jan '08

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

4 3

← Newer
1
...
4
5
6
7
8
9
10
...
20
Older →

Jump to page: