Squeak-dev December 2008

squeak-dev@lists.squeakfoundation.org

91 participants
114 discussions

re: Feedback on Naiad documentation
by Craig Latta 30 Dec '08

30 Dec '08

Hi Jerome-- > > By separating class name from identity, Naiad makes Smalltalk more > > approachable for newcomers, and more productive for developer and > > user communities. > > Expand on this. Well, that's what I attempt to do in the rest of the document. :) The first four paragraphs are an abstract, not a conclusion. I don't expect anyone to simply believe what I've said by that point; I'm summarizing what I intend to describe. But, expanding... By separating class name from identity, we remove a critical source of ambiguity, and we can transfer methods more accurately, with less manual labor. We can do this transfer both between an author's system and other people's systems, and from an author's system to itself at another point in time. This makes every person's work more amenable to study by anyone else in the community. It also makes it easier for each person in the community to express their ideas clearly through their work. I think this combination of transparency and expressiveness would make Smalltalk more approachable for newcomers, and more productive for developer and user communities. > What has identity? In this paper I'm referring to the identity of classes. > On what does the identity depend. I'm taking advantage of the fact that every class, simply by being a Smalltalk object, has its own identity by definition. > How does the Class name get detached from identity. I detach the name of a class from the identity of that class by offering an alternative to source code as the medium of code transfer. > What does the class name represent? The name of a class represents a class, but exactly which one is ambiguous in source code. One needs additional context to identify the class to which a name refers at some point in time. The mechanisms described in the rest of the paper provide that context, and go so far as to make source code optional when transferring code. > > An Edit represents the activation of some edition at a point in > > time. > > Describe activation. When an edition is activated, the compiled method to which it corresponds becomes active in the object memory whose history we are tracking. > > The history memory replaces the current changes and sources > > files > > I need diagrams. Okay, I'll make diagrams. (I'm not against them, but my time is limited and I think the text is a higher priority. Or, put another way, I think diagrams without text would be harder to understand than text with no diagrams, and getting one out before both are done is better than waiting for both.) > What does subject memory id represent? When in time do subject memory > id's change? A subject memory's system ID identifies the subject memory. A subject memory's ID is set when the memory is considered distinct from other memories. I set the system ID of the minimal memory before releasing it, and I imagine that memory will change its ID when next saved by someone receiving it. Traditionally, the identity of an object memory remains the same after a snapshot via "save", and it changes after a snapshot via "save as...". I expect the system ID to reflect that; generally, the system ID for a memory doesn't change. > I.e. The subject memory with two subject ids, how do they differ? There's no such thing as a subject memory with two system IDs (please let me know if I slipped up and wrote otherwise somewhere). > > The subject memory keeps a remote reference to the history > > memory's instance of EditHistory as a class variable of the local > > EditHistory class, and interacts with it using utility messages sent > > to the local EditHistory class. The history memory also keeps that > > EditHistory instance as a class variable of its local EditHistory > > class, but as a local reference. > > Explain Remote messaging as it applies here. I'm using the term in the usual sense: an object in one memory is sending messages to an object in another memory, by interacting with a special proxy object that represents the remote object. Since everything in Smalltalk happens by sending messages to objects, the proxy object is indistinguishable from the remote object under normal circumstances. > Who or what receives the messages? An instance of EditHistory in the history memory receives the messages. > Why are [the messages] Remote? By design, all the historical information for the subject memory is kept in a separate history memory. This is both to enable crash recovery, and to ease separation of a deployed system from its historical information when the time comes. > What is a History memory snapshot? The history memory is a bunch of objects describing all the editions of a subject memory's classes, methods, authors, modules, checkpoints, comments, and tags. > Where is the History memory located? The history memory is usually located alongside the subject memory, but it can be on any net-accessible machine. > Where is the snapshot located? The subject memory is located wherever the developer wants to put it, as now. > > An edition typically elides some of its references when it is > > transferred out of a history memory. For example, a transferred > > edition will usually omit the references to its next and previous > > editions. > > > > The requesting subject memory can calculate the ID of those > > editions and obtain them with a separate request, if necessary. > > How? In general, a next or previous edition's ID differs only in version number, and version numbers form a simple linear sequence over time. > Also if it can do that then you haven't really elided the > references only made them implicit? I'm referring to how the system leaves the reconstructed edition's nextEdition and previousEdition fields set to nil, rather than going to the trouble of serializing further editions. This is because they're often not relevant to the original edition request. Following the nextEdition and previousEdition references exhaustively during serialization would take a significant amount of time and net traffic, for no good reason in most cases. > > A subject memory may elect to keep its EditHistory instance as a > > local object, such as in a situation where one wants some limited > > immutable history for debugging purposes, and no crash recovery > > support. Whether in this scenario or in normal development the same > > EditHistory utility messages suffice, since no special code need be > > written to support remote objects. > > How do histories know about each other? Someone using a history memory can decide to connect it to another history memory, if the person using the latter memory approves. Typically, someone who has discovered a module (using mechanisms described in the "checkpoints and modules" section) requests a connection with a history memory that has the module. (Once connected, the history memories synchronize so that the receiving system has the module, with a minimum of traffic.) > Can histories move about in space and time? You can put them in any net-accessible place. I'm not sure what you mean about time here... > Clone themselves? Yes (you might want to do this when discarding rarely-used editions, for example). > How is the mesh kept track of? Each system keeps track of the other systems to which it is connected, and can report this information if permitted by the person using the system. Typically, one can ask any system in a connected set for the IDs of the whole set. > What is [the] minimal subject memory? The minimal subject memory contains the objects needed to start and extend the system (and nothing else). > How (and who) releases it? initially? I'm preparing it for release, to be available from websites and other download locations. I expect this work to be easier, doable by more people, and less frequent as the module distribution mechanism matures. Over time, I envision nearly all activity taking place in modules which are added to and removed from the minimal memory, not in the minimal memory itself. At some point, I expect analysis to prove it minimal, and that further work on it will be rare. > How easily (frequently) do versions get created? One may create them as easily as before, and faster than one is ever likely to create them from interactive use. Human activity will be the rate-determining step. I don't expect developers' traditional artifact-creation rates to change radically with the introduction of this system (it's the quality of the artifacts that I expect to change, for the better :). The traditional maximum UUID allocation rate (as cited by the Leach/Salz UUID specification, for example) is ten million per second per machine. Since UUIDs are used to identify classes and authors, I don't think we'll have a problem distinguishing one class from another, or one author from another[1]. Each author may create 65,535 versions of each class in the system, as fast as remote messages can be sent between the subject and history memories on a single machine. That rate varies by hardware; for the sake of argument, let's say it's something very slow, yielding 100 classes created per second. I think that's far more than was ever likely to occur from interactive use in the past, and even acceptable as part of the automated installation of an application. For each version of each class that each author has created, the author may create 65,535 versions of each method. This means that, for example, if you add an instance variable to class Foo, you can now create 65,535 more versions of every single method that existed for Foo before (because you've made a new version of class Foo). So for each class/selector pair, you can create 4,294,836,225 distinct method versions (four billion versions of Array>>new, for example). And each other developer could create their own four billion total versions of that one method. I think it's very unlikely that anyone has created even ten thousand versions of any particular method across *all* versions of the class that holds it, much less for only one version of that class. It also seems unlikely that any class in Smalltalk has gone through even a thousand versions from the same author in the entire history of the system so far. I understand it's tempting to draw a comparison between these claims and previous predictions which turned out to be wrong. (I suppose the most infamous example is Gates' apocryphal[2] exclamation that 640K of memory should be enough for anyone.) But I think there's an important difference here: we're estimating the capacity of people to produce, not to consume. Also, the medium is relatively obscure; we're talking about development artifact indices here, not the size of the artifacts themselves (although we have some practical limits imposed on us there, too). All that said, one could easily make variable-length versions. I just think it's space overhead on every ID (and therefore time overhead, during transmission) that's not worth paying. > How big is a MethodEdition? a ClassEdition? The size of a MethodEdition varies depending on whether the method's instructions or source are included, and, if so, how big they are. The size of a ClassEdition depends on how many methods are associated with the class it describes. I assume you're asking for aggregate sizes, following all references. Otherwise, they're on the order of 32 bytes each. > When in time and space do they reside? They occupy long-term space in the history memory, and briefly occupy space in the subject memory (in response to queries by development tools). > How does one construct the compiled method directly? You can create a compiled method given a desired header value and number of instructions. Then you set the literal values appropriately (in this case, from a method edition's literal markers), and set the instructions. After that you can install it in a class and run it. It's the literal markers which make this all work. Just as one can create compiled methods directly, one can also create each kind of method literal directly. Literal markers contain the information needed for that construction, and can carry it out. > What is missing is the basic "How do I start from a seed and build a > sunflower". <How do things start and grow the metephor refers to a > current squeak project of mine> Well, I don't think that's missing. You start with a system that has enough methods in it to start and accept more methods, then add methods written by yourself or others. The essence of it is not complicated. > > Method literal markers are used to transmit a compiled method's > > literal frame values between object memories. There are method > > literal marker classes to support references to classes, class > > variables, other pool variables, and literal objects, and to support > > methods which perform class-side super-sends. Each method literal > > marker instance knows how to serialize itself as part of Spoon's > > remote messaging system. In particular, when a method literal that > > refers to a class transmits itself, it transmits the ClassID of that > > class, not the name of the class. > > I still at this point don't understand why this is a good thing. Why > would I, as a human, not want to know the difference between, say, > True and False? I'm not trying to obscure the identity of anything. On the contrary, I want to introduce identifiers which are less ambiguous than the textual ones we've used before. When a person says "class Foo", it's not clear to another person, much less a machine, which version of class Foo they mean, and by which author. Also, I don't intend for developers to ever see things like ClassIDs unless they want to. At any given moment, the browsers we've been using before can display an appropriate textual equivalent for an ID. > > This gets at the namesake concept of Naiad, "Name And Identity > > Are Distinct". When referring to a class, we never need to use its > > name. Each version of each class is an object with a distinct > > identity. By using ClassIDs to refer to each of them, we can avoid > > using class names at all when storing history or distributing > > code. This means that name of each class can be anything, as far as > > the system is concerned. > > Ok then. For human understanding how do I get back to names? You will never use or see ClassIDs in method sources (the browsers see to that, aided by the information in class editions). ClassIDs are what machines use to refer to classes when transferring compiled methods. > > ...every shared variable pool is the responsibility of > > some class in the system. > > If I wanted to refer to a pool variable how would I do so? When composing method source, the same rules as before would apply. The benefit I propose is always being able to select a shared variable that you see in method source, then having the browsers tell you which class is responsible for it (and, in turn, which *authors* are responsible for it). > Where in time and space do Checkpoints live? Checkpoints are the same as other editions in that regard. They occupy long-term space in the history memory, and briefly occupy space in the subject memory (in response to queries by development tools). > What are postrequisite [modules]? A postrequisite module is a module that must be loaded as a consequence of loading some other module. Conceptually, it's the complement of a prerequisite. > How does a module know them? Each module has an instance variable which is a collection of postrequisite modules (see the object model summary in the Naiad design document). There's another instance variable for prerequisites, too. > Who transfers a module out of a history memory? <What dialogue is > taking place at this point and among which parties?> A module is transferred from a providing history memory to a consuming history memory, when the consuming history memory requests it. The transfer is done via remote message-sending. > > ...each module edition has a URI by which someone at a remote site > > may install the module. That URI represents a command to a Spoon > > system running on a requestor's local machine; it refers to a > > standard port on localhost. Its path is a text-encoded action, > > containing an instruction ([for example] "install a module"), the > > hostname and port of a Spoon system providing the module, and the > > module's ID. > > > > ... > > > > The encoded URIs can serve other functions as well, such as > > listing a system's installed modules, removing an installed module, > > making a snapshot, and quitting the system. > > How? The instruction part of command URI can indicate one of several commands, such as the ones mentioned above. For example, an instruction value of one could mean "install a module", two could mean "list the local system's installed modules", and so on. For each instruction, there are parameters one needs to carry out the instruction (for installing a module, those parameters are the hostname and port of a Spoon system providing the module, and the module's ID). The instruction and all the parameters are concatenated and encoded as text to form the path of the command URI. Any system that implements the specification can interpret the command URI and carry out its instruction. thanks for the comments! -C *** [1] Consider, for example, the number of humans who have ever lived. Two hundred billion seems to be a generous guess currently; see, e.g., http://tinyurl.com/9f7s5x (wikipedia). [2] www.itbusiness.ca/it/client/en/CDN/News.asp?id=48924 -- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)] -- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]

1 0

SlangBrowser updates
by David T. Lewis 28 Dec '08

28 Dec '08

I have updated SlangBrowser to maintain it as a package (mostly) separate from VMMaker. The intent is that it can now be loaded into any of the various VMMaker projects, hopefully including Cog, Hydra, and Exupery. SlangBrowser enables viewing of generated C source for the interpreter and plugins directly from system browsers. The change sets are at http://wiki.squeak.org/squeak/5916 and also attached here for reference. If you are using VMMaker from the SqueakSource project, the supporting changes are in VMMaker-dtl.111.mcz, and SlangBrowser is saved as a separate package in the VMMaker project. The CodeHolderMenuRegistration changes (also attached) are separate from VMMaker, and are on Mantis http://bugs.squeak.org/view.php?id=5932. Dave

1 0

[ANN] Introducing Mars 0.1
by Esteban Lorenzano 25 Dec '08

25 Dec '08

Hi, I'm introducing Mars (just another world) Mars is a world for Squeak (and all it's forks) builded as an MVC on top of Cocoa (OSX framework) and OmniBrowser. For that reason, Mars just runs on OSX environments. While this project has some similariries with SqueakGTK and wxSqueak, it has big differences: 1) Mars is not a port of Cocoa for squeak, is just an MVC implementation who uses Cocoa. Why that "subtle" distinction? well, SqueakGTK is a full port of GTK+ library and for that reason, a little big a and a little too complex. I'm following simplicity as one of the project goals. 2) Mars is a plugin, and will run in any fork of squeak, and OB-Mars (Mars world) will run in any fork of squeak who can load OmniBrowser. This is a big difference with wxSqueak, wich is a fork it self (and requires an special VM) And of course, while both efforts (SqueakGTK and wxWidgets) are cool, none of them can be executed (and won't ever be) in small environments, like the iphone, which is one of my main objectives (using John's new VM and Edgar's work on minimal image building) Mars is MIT and can be downloaded following instructions from here: http://www.smallworks.com.ar/productos/Mars/Download For more details (history, blog, etc.), you can go to: http://www.smallworks.com.ar/productos/Mars DISCLAIMER: Right now, Mars is vere-very alpha stage (though it runs and can be used) and I would love any contribution in the form of: bug reports (there will be a lot now), feature requests, comments, and of course, code :) Cheers, Esteban -- "Querer es suscitar las paradojas" Camus. El míto de Sísifo.

4 3

ConflictFinder update
by Andreas Raab 25 Dec '08

25 Dec '08

Folks - I spent a bit of time on the weekend to add various improvements to ConflictFinder and try them out. Most importantly, CF now has the ability to run all the tests and detect any newly found failures (i.e., it's running all tests that are in the image and blames newly failing tests on the latest loaded package). Interestingly, I found that at this point in time this isn't as helpful as I had assumed - I think that's mostly because test coverage isn't great at this point and maybe because most blatant failures can be easily detected by the basic conflict tests. So while I think this will be helpful in the long term it's turned off for the moment which dramatically increases the speed of the process. That said, thanks to the people running ConflictFinder we have some early feedback about general issues with the current 3.10 universe: * Missing Dependencies: There seem to be a *lot* of packages that miss either some or all dependencies. Not sure what to do about them but I've seen lots of packages with warnings reported from MC about missing dependencies. * Package renames: It seems that some packages (Polymorph in particular) were renamed halfways along the way but the obsolete versions are still available. This often results in bogus conflicts (different category names) and also clutters the user-visible space (for Polymorph for example there seem to be three different names under which it goes: Polymorph, UI Theme, and Look Enhancements). * Platform dependencies: Some packages (TimeZoneDB, ExternalWebBrowser) will only load and work on a particular platform. TimeZoneDB for example fails to load on Windows boxes since it tries to access some Unix path directly. * Overrides: We all know that overrides are evil but occasionally necessary. I am wondering how we should treat them integration testing. Any ideas? Also, there is the question of how we want to go forward from here. For example, should we try to fix these issues in the current 3.10 universe, or should we work forward from here and start fresh with a 3.11 universe at which point we could start running these tests for example weekly and have feedback about many of the above issues much earlier in the process. We could then also make a much more well-informed decision about what the "stable 3.11 universe" really means (i.e., for example only provide packages that pass the integration tests). Comments, advice, offers for help are all welcome. Cheers, - Andreas

4 3

[Fwd: [Newbies] Changes file - has reached its size limit.]
by Keith Hodges 25 Dec '08

25 Dec '08

What should Richard do?

1 0

Re: Smallfaces examples
by stephan＠stack.nl 24 Dec '08

24 Dec '08

I've installed SmallFaces into an updated Seaside one-click image (latest Seaside and Scriptaculous) and see some character encoding problems in the examples. Stephan

2 1

Resume Problems
by Zulq Alam 24 Dec '08

24 Dec '08

Hi All, Perhaps I am misunderstanding the behaviour of I have a class SoupTag which holds a dictionary of attributes and a collection of children which are also soup tags. As a shorthand for attribute access, SoupTag implements: SoupTag>>doesNotUnderstand: aMessage (aMessage arguments size = 0) ifFalse: [^ super doesNotUnderstand: aMessage]. ^ attributes at: aMessage selector ifAbsent: [super doesNotUnderstand: aMessage] So that a SoupTag with attribute id=100 would answer 100 to #id and DNU to any other selector. This seems to work fine but I'm having trouble implementing a flexible find: method. The test case is tag := SoupTag new tag attributeAt: 'id' put: 'abc'. tag find: [:each | (each missing = 'xyz') or: [each id = 'abc']] And so far I have simplemented this as: SoupTag>>find: aBlock [(aBlock value: self) ifTrue: [^ self]] on: MessageNotUnderstood do: [:e | e resume: false]. children do: [:anElement | | found | found := anElement find: aBlock. found ifNotNil: [^ found]]. ^ nil I expected this to effectively end up evaluating: tag find: [:each | false or: [each id = 'abc']] But all I get is infinite recursion from the doesNotUnderstand. I think this should work as this little test demonstrates: [('abc' + 1) + 1] on: MessageNotUnderstood do: [:e | e resume: 1] " prints 2 " Any help is greatly appreciated. Thanks, Zulq.

5 10

[ANN]iStoa.net 8.12-alpha1
by Hilaire Fernandes 24 Dec '08

24 Dec '08

Dear all, I am working on a learning system written in Smalltalk. The contents is only in French for now, and only cover multiplication learning, but I am planing for more in various subjects. Underneath the curriculum is modelised in a graph to help situating the learning progression of the learner. It is an alpha state, website http://www.istoa.net -- http://blog.ofset.org/hilaire

2 2

FFI + ODBC problems
by riccardo.sangalli＠edor.it 23 Dec '08

23 Dec '08

Hello, sorry for my english and for annoying you, but I have a question about FFI... I am a newbie in smalltalk and I tried to use Seaside to make an ODBC connection. So we tryied to make a simple connection + query: | con | con := ODBCConnection dsn:'testsqueak' user:'sa' password:''. (con query: 'SELECT count(*) FROM Clienti') results do:[:row | Transcript show: row; cr]. con close. ...but we obtained the error explained in the attachment image file. We use Squeak 3.9 (Seaside OneClickExperience version) + FFI loaded by Squeak Map + ODBC for Squeak loaded with Squeak Map. Running that code in an old version of Squeak (3.7) everithing works... Do you know why? Maybe that are different versions of FFI? Maybe the call at odbc32.dll OLD deprecated function "SQLAllocEnv" instead of new "SQLAllocHandle"? Thank you a lot in advance and best wishes for holidays.

4 3

losing mouse clicks
by Julian Fitzell 23 Dec '08

23 Dec '08

On 08.05.2008, at 11:14, Adrian Lienhard wrote: > Hi, > > From time to time it happens that the image gets into a weird state where click > events are only honored after moving the mouse. For example, in the code > browser you click on a method but nothing happens until you start moving the > cursor. The problem does not seem to go away again. > > Has anybody else seen this problem? If yes, does a Mantis report exist that I > have not found? Gah, this has been biting me constantly in one image after another over the past 6 weeks (never seen it until then). First It thought it was a particular image, then it happened in another. So I thought it was the Windows VM but then it happened with the Mac VM. So then I figured it must be something MC2 was doing but now it just happened in a Seaside image. And that was a Pharo image so it's not even specific to the base image I'm using. Did anybody ever figure out what the heck is causing this? It's driving me nuts!! I did spend a bit of time in one image trying to track it down and it seemed like lots of mouse events were getting put into the EventSensor's eventQueue but not being pulled out before #flushNonKbdEvents was called (it's called often). Changing that method to leave mouse clicks as well helped for a bit but mouse ups weren't getting generated. I again hacked around that a bit but it never worked very well and then it seemed to start getting worse again. Help! Julian

6 10