Squeak-dev July 2006

squeak-dev@lists.squeakfoundation.org

132 participants
241 discussions

Icons in Unix
by Keith Hodges 30 Jul '06

30 Jul '06

I know that when developing a server one should not be interested in such trivialities, but, does squeak have any icons in the KDE/Linux world? At the moment on my installation squeak is a X11 logo which just feels so wrong. Keith ___________________________________________________________ All New Yahoo! Mail Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html

1 0

[BUG]UndefinedObject(Object)>>error:
by thiagarajan.varadharaju＠students.unisa.edu.au 29 Jul '06

29 Jul '06

What should I do with this error: RBNamespace new-> MessageNotUnderstood #new 29 July 2006 10:47:30 pm VM: Win32 - a SmalltalkImage Image: Squeak3.8 [latest update: #6665] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir D:\Studies\Project\Squeak3.8-For Learn Trusted Dir D:\Studies\Project\Squeak3.8-For Learn\Thiyagarajan Untrusted Dir C:\My Squeak\Thiyagarajan UndefinedObject(Object)>>error: Receiver: nil Arguments and temporary variables: aString: 'This message should be implemented' Receiver's instance variables: city: nil UndefinedObject(Object)>>shouldBeImplemented Receiver: nil Arguments and temporary variables: Receiver's instance variables: city: nil UndefinedObject>>new Receiver: nil Arguments and temporary variables: Receiver's instance variables: city: nil SmaCCGrammarCompiler>>initialize Receiver: a SmaCCGrammarCompiler Arguments and temporary variables: Receiver's instance variables: shiftTable: nil itemSets: nil startingStateMap: nil actions: nil parserClass: nil parserDefinitionString: nil scannerCompiler: a SmaCCScannerCompiler grammar: nil model: nil --- The full stack --- UndefinedObject(Object)>>error: UndefinedObject(Object)>>shouldBeImplemented UndefinedObject>>new SmaCCGrammarCompiler>>initialize - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - SmaCCGrammarCompiler class>>new [] in SmaCCParserGenerator>>acceptParserCode:notifying: {[SmaCCGrammarCompiler new buildScanner: scannerText andParser: aStringOrATex...]} BlockContext>>on:do: SmaCCParserGenerator>>acceptParserCode:notifying: SmaCCParserGenerator>>verifyParser SmaCCParserGenerator>>verifySyntax [] in SmaCCParserGenerator>>compile: {[self verifySyntax ifFalse: [^ self]]} BlockContext>>ensure: CursorWithMask(Cursor)>>showWhile: SmaCCParserGenerator>>compile: SmaCCParserGenerator>>compileLALR1 PluggableButtonMorph>>performAction [] in PluggableButtonMorph>>mouseUp: {[:m | (m containsPoint: evt cursorPoint) ifTrue: [m performAction]]} Array(SequenceableCollection)>>do: PluggableButtonMorph>>mouseUp: PluggableButtonMorph(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableButtonMorph(Morph)>>handleEvent: PluggableButtonMorph(Morph)>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. ActiveEvent := anEvent. result := focusHolder han...]} [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} BlockContext>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: {[:h | ActiveHand := h. h processEvents. capturingGesture := capturingGest...]} Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess {[[World doOneCycle. Processor yield. false] whileFalse. nil]} [] in BlockContext>>newProcess {[self value. Processor terminateActive]}

2 1

Re: [Webteam] Re: Re: Squeak web site down
by Jason Rogers 29 Jul '06

29 Jul '06

As some of you noticed the www.squeak.org was not responding. We have restarted the server and everything seems to be functional. If you notice any issues please email the webteam list at webteam at lists dot squeakfoundation dot org. Thanks and regrets, Jason Rogers

1 0

[Patch] Both source files now with 512MB capacity
by Klaus D. Witzel 29 Jul '06

29 Jul '06

List, attached are two .cs files which together push the limit from 32MB to 512MB for the .sources file and the .changes file, no problem so far on #7048. Use: FileIn LargeSourceFilePointers-kwl.0.cs; if you filed it into an empty changeset then select the doIt in the preabmble, otherwise select the doIt from the fileList text view, then doIt. This doIt is essential. Note that this fileIn will change the MethodProperties class definition, you must accept. Do the very same with LargeSourceFilePointers-kwl.1.cs, fileIn then doIt. You don't need to inspect the result from the two doIts (these 204 methods have been discussed before). In both steps a small amount of methods is compiled and a part of the migration is executed, doesn't take much time. Don't forget to save the image (before; after)! The #7048 image grew 300KB here. There is no break in compatibility with the existing .sources and .changes files, except that *after* you passed the old 32MB limit for one of the files, it can no longer be used by an uncoditioned image. I'd like to receive some feedback that this works for you, all platforms, thank you in advance. The FilePlugin was checked for the file pointer length, it accepts up to eight byte pointers (SmallInteger and LargeInteger). Will do more tests (and perhaps more patches) during the next couple of days. /Klaus

3 4

Problem with simple Dice/DiceView program
by Manas Dadarkar 29 Jul '06

29 Jul '06

Hi, I am facing a strange problem with a simple Dice/DiceView code. I have a simple dice and a diceview that should show the new image of the dice depending on what the new value of the dice is. For some reason, the image of the dice does not get refreshed in the system window. Can someone help me here? Thanks, -Manas

4 5

Web site www.squeak.org appears to be down
by Ron Teitelbaum 29 Jul '06

29 Jul '06

I just noticed that the web site for squeak appears to be down. - Ron

3 2

Spoon progress 27 July 2006: shared variables (including "globals")
by Craig Latta 29 Jul '06

29 Jul '06

Hi-- contents: introduction shared variables and compilation/execution classes other shared variables the root class the special objects array method references to "Smalltalk" another reminder about live behavior transfer why do this now introduction Previously I mentioned that I wanted to rid Spoon of the system dictionary. Here's how I'm currently doing it, and, more generally, how I'm supporting shared variables in Spoon. Thanks in advance for any feedback! First, a recap of the system dictionary concept and why I don't like it. :) shared variables and compilation/execution Shared variables in Smalltalk are stored as associations; the key is a shared variable name, and the value is an object associated with that name. When the compiler compiles source for a method that refers to a shared variable's name, it attempts to find an appropriate shared-variable association for that name. It stores that association in the "literal frame" of the resulting compiled method (currently, a span of the method's bytes after the header and before the instructions). There are instructions for pushing the value of a particular shared-variable association from a method's literal frame onto the stack (or "temporary frame") of a context running that method (see Interpreter>>pushLiteralVariableBytecode, the implementation of interpreter operations 16r40 to 16r5F). Traditionally, all of these shared-variables associations are stored in dictionaries that the compiler knows about. As far as the compiler is concerned, the outermost shared-variable scope is represented by the "system dictionary", a singleton instance of the SystemDictionary class called "Smalltalk". (Just to review, note that the system dictionary has an association whose key is the symbol #Smalltalk and whose value is the system dictionary itself. This association is used in the compiler methods that make use of the system dictionary.) classes Most of the associations in the system dictionary refer to classes. The key of each such association indicates the name of the corresponding class as far as the compiler is concerned. Additionally, each class has a "name" instance variable. That is, the name of each class is stored in two distinct places: in the system dictionary, and in the class itself. In effect, the compiler's notion of a class' name and the class' own notion of its name are distinct (and possibly conflicting). I propose to make the compiler use the classes' notion of names directly, so that there is only one naming scheme, and that the classes themselves are responsible for it. To do this, instead of storing a class' name symbol in its "name" instance variable, we can just store the shared-variable association that the compiled methods use (and which used to be in the system dictionary). When the compiler wants to find a class with some name in some source a human just wrote, it can search the class hierarchy from the root (class Object). As I discussed earlier here with Ralph Johnson, it's typically not as fast as a dictionary lookup, but it's acceptable (the compiler tends not to be a part of the system that needs every cycle squeezed out of it). If the compiler finds multiple classes with some name in source submitted for compilation, it can present other information about these classes (e.g., class category or module) to the human, and ask for a choice. When already-compiled methods are transferred between systems, there is no ambiguity, since class names aren't used at all (see "another reminder about live behavior transfer" below). the root class As you might guess, this means that Spoon will not have multiple root classes. So far, all the non-primary root classes in Squeak were motivated by a desire to use method lookup failure for various "proxyish" features. I support such features in Spoon directly with the interpreter (see for example, class "Other"), so it's not necessary to have more than one root class (it's also not necessary to have the "ProtoObject" class). As for how to access the root class, there are a couple of options. We could store the root class' shared-variable association directly in methods, or we could store the root class in the "special objects array" (it could take the system dictionary's place there, in fact). the special objects array This brings me to the special objects array. :) I've always found it odd that it's chock-full of well-known and relatively unchanging things, but it doesn't have its own class and protocol. I've never liked the name "special objects array" either; it seems too vague. Metaphorically, I think the special objects array represents the grip that the interpreter has (and needs to have) on the object memory. So for Spoon I've created a class called "InterpreterGrip" whose sole instance is a collection of the objects that the interpreter knows about. I call each of these objects a "grip point". There is protocol for accessing them (for example, a "rootClass" message). I find this more pleasant than the current scheme. other shared variables Anyway, back to the system dictionary. I addressed the associations there that refer to classes, but there are others. These are the other so-called "global" variables (like Display, the primary display) as well as all the "shared pools" (like TextConstants and, strictly speaking, Undeclared). I think each global variable should be the responsibility of some class. So the primary display could be something you get by sending "primary" to DisplayScreen. Shared pools are dictionaries of shared-variable associations, similar to the system dictionary (in fact, I'd call the system dictionary just another shared pool). I know some think we should simply banish all shared pools, but I'll assume for the moment that we're keeping them. I find them useful, I just think some class should take responsibility for each one. I've added a "publishedPools" instance variable to Class, which stores all the shared pool dictionaries for which a class has responsibility (i.e., the class that introduced the pool into the system). I renamed the traditional "sharedPools" instance variable in Class to "receivedPools"; these are the pools that a class merely uses. Finally, I renamed the "classPool" instance variable to "classVariablesPool", just to be clearer. When you want to use a shared pool, you access the pool by sending a message to the responsible class, rather than relying on its name being a global variable. method references to "Smalltalk" So now we've got new homes for all the shared-variable associations which used to be reachable through the system dictionary. The other thing to do is refactor the methods which use the shared-variable association for the system dictionary itself (the methods which refer to "Smalltalk"). I'm working on this now. There are about a thousand of them in a "full" object memory, but for most of them it's clear which class should actually take responsibility. For example, there are several methods which (in my opinion) are rightly the responsibility of the Interpreter class (like the garbage collection messages). I've also written some refactoring tools that automate a lot of this (e.g., a tool which replaces the push of one literal variable with another when followed by the sending of a particular message). another reminder about live behavior transfer Some of these decisions would be problematic if we were limited to using source code ("fileouts") to transfer behavior between systems. Since Spoon can transfer methods directly, without recompilation (or even source code) and without referring to shared-variable names at all, it works (see the MethodLiteralTransmissionMarker hierarchy for details). why do this now This work was always lurking in the future, but now the issue is forced by my work on Naiad (Spoon's module system). I'm making a module which reattaches the primary display (the system is initially headless), and that meant deciding how to access it. Since access is traditionally through a global variable (Display), the can of worms was opened. :) *** Again, thanks in advance for any feedback or questions. I'm usually around on the Squeak IRC channel from 1700 to 0500 GMT, and I read the squeak-dev and Spoon lists. thanks again, -C -- Craig Latta http://netjam.org/resume

3 4

ScaledDecimal scale coercion
by nicolas cellier 29 Jul '06

29 Jul '06

Hello I noticed that in Squeak, the scale is inherited from receiver: (0.5s1*0.5s2) -> 0.2s1 (0.5s2*0.5s1) -> 0.25s2 in VW, it is coerced to the larger scale (also do gst and stx): (0.5s1*0.5s2) -> 0.25s (0.5s2*0.5s1) -> 0.25s Also, the storeString is not retrieving original object but truncate as printString would do: (Number readFrom: (0.5s1*0.5s1) storeString) = (0.5s1*0.5s1). (Compiler evaluate: (0.5s1*0.5s1) storeString) = (0.5s1*0.5s1). VW has the same bug with: (0.5s1 squared storeOn: Transcript). Transcript flush except it rounds instead of truncating. Is this expected / ANSI / standard / bugged ? Nicolas

1 0

New source code subsystem
by Klaus D. Witzel 28 Jul '06

28 Jul '06

List, I put together what I think is relevant for a new source code subsystem and, if I'm mistaken or have overlooked one of your recent suggestions and/or requirements, please do not hesitate and say so. What follows is not intended as a replacement for MC or SM, rather the new subsystem should be as independent as possible. If you load something with MC, the new subsystem can treat it like any other contribution (more about contributions later). Trying to keep preliminaries as short as possible, we have as organizational elements (for the sake of discussion): system categories, classes, message categories and methods. The unit of source code "entity" we consider to be a unit of change belongs to one of these elements. We can add, replace, rename and delete. We have not only methods, but also DoIt's (definitions, organizational, etc) to take into account. And let's say that the browser is our tool, just to keep it simple here. ------------------------------- At the time an image is distributed, it is supposed to be in sync (not necessarily *full* sync) with its respective source code subsystem. So when you open a browser, all entities are colored black on white, and my story begins. When you want to *observe* a certain area of the source code subsytem, you put the respective entity (item from here on) onto your watchlist (cmd+ if you like) from where the item gets the color blue. After putting a class onto your watchlist you get all its message categories and methods blue; un-watch those (sub)items which are of no interest to you; etc for other organizational levels. When you do a *change* to a blue colored item, its new source is contributed to the source code subsystem (from here on scs for short) and the item is colored green in your browser. If later somebody else contributes a change to the same blue item, it gets the color yellow in both browsers. And if an entity you have in your image cannot be *matched* with the scs, it is colored red. As is tradition, if you don't save your image before the next crash, all this coloring information is lost, and you are back to black and white. The scs does NOT know the state of your image. ------------------------------- A contribution to the scs either has a predecessor or else it is new (to the scs). Let's say three developers make contributions to the same blue item, then we arrive at three branches (and the three browsers color the respective item yellow). It is up to you to accept one of these branches, but you are no forced to do so. An accepted branch is colored green (it will turn yellow when the next contribution relative to it arrives). ------------------------------- By chasing the predecessor it is always possible to roll-back an item (or a group of items), this is independent of the coloring I used for illustration. The same "backwards" information is readily available for analyzing the complete history of an item, including all unaccepted branches. ------------------------------- Doing this into the other direction (roll-forward) depends on which branches where accepted. At any point in time, accepted branches represent a "cut" in the scs. ------------------------------- If you work alone on a project, you'll never see any yellow colored item, unless you revert a change (because the dismissed becomes an unaccepted branch). For people who are used to make small incremental changes, a preference tells whether or not every change is treated as a branch or else is to be consolidated until you do a "big save" to the scs. The latter requires, I think, a local buffering scs on your harddisk (or on your local area server). ------------------------------- The amount of conversation between browser and scs is small, the browser only has to ask for colors (one byte answer per item) for those items it shows *and* which are on your watch list. But if you want to see more (like, for example, all branches of an item), more data will have to travel. ------------------------------- It's now time for me to sit back and relax :-) /Klaus

3 5

Re: New source code subsystem
by ncellier＠ifrance.com 28 Jul '06

28 Jul '06

Klaus, i would say this is another source version control system. This bottom up approach is interesting but will not work. Squeakers will continue to use their preferred tools, not your specific browser. Let's be more pragmatic and have a small incremental bottom up approach. I see two solutions: - store source code and history in image... I do not believe we should go in this direction even in compressed forms. We are rather making efforts to make images shorter... But you can have other opinion of course. - continue storing source in external repositories (files, URL, NET servers...) In the later case, we could have many files instead of two (sources changes) and we should be able to have large files: conclusion: let's just change source code pointer encoding. Using SmallIntegers (30 bits?) we can address 1GByte of space. More if bits are not encoded as file offset but as Oop on a server... Using two SmallInteger, we have at least 60 bits, 1 ExaByte of data! Let's go for it (count how many compiledMethod are in your image... and you'll see this is not a drama). Maybe we can have an encoding supporting 1 single SmallInteger for certain patterns (for example it can be sufficient for code stored in 'sources' file, 'sources' file could also be organised with an indirection table instead of using byte offsets...Given average source code length, that can save a factor between 10 and 100 i presume). We should be able to extend source code being in several places in the future... (several files or URL or ...). So let use change encoding by splitting bits : 20 bits for sourceRegistry offset, 40 bits for file offset, or 30bits/30bits, or both (pattern starting with bits 0001 will be 20/40, all other 30/30 for example). Then we have to create the SourceRegistry with objects able to handle source code stored in files, in compressed files, on the Net, with all necessary caching to reduce number of connections and design of the source code servers... However, i would keep the principle of copying changes in the 'changes' file to recover easily in case of image crash, and commiting to another source would still be the responsibility of user, as is now. Small details: make sure the FileSystem primitives can deal with huge offsets (and also underlying OS of course). You see, nothing really new, nothing really difficult. With just a little bit more reflexion we can go in this direction and that should be enough for a few years of development and future enhancements... Nicolas Klaus D. Witzel: > List, > > I put together what I think is relevant for a new source code subsystem > and, if I'm mistaken or have overlooked one of your recent suggestions > and/or requirements, please do not hesitate and say so. > > What follows is not intended as a replacement for MC or SM, rather the new > subsystem should be as independent as possible. If you load something with > MC, the new subsystem can treat it like any other contribution (more about > contributions later). > > Trying to keep preliminaries as short as possible, we have as > organizational elements (for the sake of discussion): system categories, > classes, message categories and methods. The unit of source code "entity" > we consider to be a unit of change belongs to one of these elements. We > can add, replace, rename and delete. We have not only methods, but also > DoIt's (definitions, organizational, etc) to take into account. And let's > say that the browser is our tool, just to keep it simple here. > > ------------------------------- > > At the time an image is distributed, it is supposed to be in sync (not > necessarily *full* sync) with its respective source code subsystem. So > when you open a browser, all entities are colored black on white, and my > story begins. > > When you want to *observe* a certain area of the source code subsytem, you > put the respective entity (item from here on) onto your watchlist (cmd+ if > you like) from where the item gets the color blue. After putting a class > onto your watchlist you get all its message categories and methods blue; > un-watch those (sub)items which are of no interest to you; etc for other > organizational levels. > > When you do a *change* to a blue colored item, its new source is > contributed to the source code subsystem (from here on scs for short) and > the item is colored green in your browser. If later somebody else > contributes a change to the same blue item, it gets the color yellow in > both browsers. > > And if an entity you have in your image cannot be *matched* with the scs, > it is colored red. > > As is tradition, if you don't save your image before the next crash, all > this coloring information is lost, and you are back to black and white. > The scs does NOT know the state of your image. > > ------------------------------- > > A contribution to the scs either has a predecessor or else it is new (to > the scs). Let's say three developers make contributions to the same blue > item, then we arrive at three branches (and the three browsers color the > respective item yellow). It is up to you to accept one of these branches, > but you are no forced to do so. An accepted branch is colored green (it > will turn yellow when the next contribution relative to it arrives). > > ------------------------------- > > By chasing the predecessor it is always possible to roll-back an item (or > a group of items), this is independent of the coloring I used for > illustration. The same "backwards" information is readily available for > analyzing the complete history of an item, including all unaccepted > branches. > > ------------------------------- > > Doing this into the other direction (roll-forward) depends on which > branches where accepted. At any point in time, accepted branches represent > a "cut" in the scs. > > ------------------------------- > > If you work alone on a project, you'll never see any yellow colored item, > unless you revert a change (because the dismissed becomes an unaccepted > branch). For people who are used to make small incremental changes, a > preference tells whether or not every change is treated as a branch or > else is to be consolidated until you do a "big save" to the scs. The > latter requires, I think, a local buffering scs on your harddisk (or on > your local area server). > > ------------------------------- > > The amount of conversation between browser and scs is small, the browser > only has to ask for colors (one byte answer per item) for those items it > shows *and* which are on your watch list. But if you want to see more > (like, for example, all branches of an item), more data will have to > travel. > > ------------------------------- > > It's now time for me to sit back and relax :-) > > /Klaus > > > ________________________________________________________________________ iFRANCE, exprimez-vous ! http://web.ifrance.com

8 22

← Newer
1
2
3
4
5
6
7
...
25
Older →

Jump to page: