Squeak-dev October 2002

squeak-dev@lists.squeakfoundation.org

183 participants
406 discussions

Object Format
by PhiHo Hoang 29 Oct '02

29 Oct '02

Hi, <NuBlueBookQuote> ... Since we still need to have the class oop, size and some flags available for each object, Squeak generally uses a larger header. The canonical header is three words:- flags/hash/size encoded in one word, class oop, size. However as a high proportion of objects are instances of a small set of common classes, and since few objects are large, it was decided to use three header formats as follows:- - One word - all objects have this header. - 3 bits reserved for GC state machine (mark, old, dirty) - 12 bits object hash (for hashed Set usage) - 5 bits compact class index, non-zero if the class is in a group of classes known as 'Compact Classes' - 4 bits object format - 6 bits object size, in 32-bit words - 2 bits header type (0: 3-word, 1: 2-word, 2: free chunk of memory, not an object at all, 3: 1-word) ... </NuBlueBookQuote> What is this 4-bit 'object format' field. Where can I find further detailed information about this 'object format'. Any pointer is very much appreciated. Cheers, PhiHo. P.S: Plugins are really boring now. It's about time to learn _real_ object ;-)

5 11

[Q] Creating printed document from ComSwiki
by Drautzburg Martin 29 Oct '02

29 Oct '02

I have just "installed" a ComSwiki on Solaris and it was a real pleasure. Still some questions remain. (1) Large *.old files The *.old files have apx. 10 times the size of the *.xml files. This is after one day of usage. Is there a way I can purge the history or limit the number of history entries or any other way to keep the *.old files from growing endlessly. (2) Creating a printed version I wanted to use the swiki for collaboratively creating a design spec. One fellow asked how we can enventually produce a printed version (preferably MS Word format)? Also I have not yet figured out how to "render" the swiki. Any popinters ? Martin Drautzburg, SIEMENS dematic Konstanz, +49-7531-86-3618

1 0

RE: Persistent VM (was Re: [ANN] New Version of VI4 (block closures))
by Frank Sergeant 29 Oct '02

29 Oct '02

"Stephen Pair" <spair(a)acm.org> wrote: > What I'd really like to find is something that is comparable to > BerkeleyDB but with a more open license. Have you considered MetaKit (http://www.equi4.com/metakit) ? Part of the blurb is > MetaKit is an efficient embedded database library with a small footprint. > It fills the gap between flat-file, relational, object-oriented, and > tree-structured databases, supporting relational joins, serialization, nested > structures, and instant schema evolution ... > MetaKit is open source software, using a liberal X/MIT-style license. I have been using it (not from Squeak) in another project and have been very happy with it and with the superb support from its creator and maintainer Jean-Claude Wippler. -- Frank

2 1

The Taste of Smalltalk Scanned, OCRed... ready to enjoy
by Stephane Ducasse 29 Oct '02

29 Oct '02

Hi all I finally get all the pieces and reassemble them. All the chapters (except the 2 where one page is still missing) are available at: http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks/Taste/ Spread the word. Thanks alex, lukas, gabi for their help. I felt better with helping to scan and convert some resistant images. Thanks for the experiences various people did. We used FineReader and turn around the C++ bugs of the program :) Stef Dr. Stéphane DUCASSE (ducasse(a)iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes

3 3

Re: Envy or Store or what?
by Colin Putney 29 Oct '02

29 Oct '02

On Monday, October 28, 2002, at 12:48 PM, Cees de Groot wrote: > Cees de Groot <cg(a)cdegroot.com> said: >> Smalltalk, and Squeak in particular, is about doing The Right Thing. >> CVS is, >> IMNSHO, a crutch that is absolutely necessary at the moment to have >> something, >> but definitely not The Right Thing. I agree here, up to a point. DVS makes using CVS Squeak fairly painless, but it's far from ideal. > If DVS can use multiple backends, wouldn't Subversion be a better > choice? I'm a big fan of Subversion, but I think integrating it with Squeak nicely would quite difficult. Subversion is designed as a set of libraries that a Subversion client can link against. But the API they present uses a lot of callbacks, so calling into it via FFI would be tricky at best. Another option would be to just use the svn client. This is easy, but not much of an improvement over using cvs. Svn is "a better CVS," so you still have hassle of synching code back and forth between a working copy and your image. Avi mentions the possibility of implementing a WebDAV client. That would be a start, but you'd still have to implement an SVN client on top of that, since Subversion's use of WebDAV is fairly specialized. So this is a fair amount of work. I think implementing our own respository similar to ENVY or StORE would be a pretty attractive option. It's probably not that much more work than implementing DAV, for example, or the CVS pserver protocol... Cheers, Colin Colin Putney Whistler.com Colin Putney Whistler.com

1 0

Re: Diff between two change sets
by Bob Arning 28 Oct '02

28 Oct '02

On Mon, 28 Oct 2002 14:02:13 -0700 Nevin Pratt <nevin(a)smalltalkpro.com> wrote: >Is there any way to get Squeak to show the diffs between two change sets? You might try http://www.charm.net/~arning/Comparison.18Aug114pm.cs Source Comparison Browser (Squeak 2.5 - requires change set 1358) is a tool for comparing two squeak source files side-by-side. Hierarchical lists, color coding, etc. Updated for unpleasant side-effect of changeset 1375. Cheers, Bob

1 0

About SqueakMap for 3.2 and the future!
by Göran Hultgren 28 Oct '02

28 Oct '02

Hi all! Now that RC2 is out and it seems to work (knock, knock) I would like to start a period of "thinking" about what to do next. In fact, OOPSLA is coming up and I think we should let the package "SqueakMap" be as it is right now. SMLoader and Browser can of course evolve furiously, they are "just UIs". :-) So, let's only correct bugs in package "SqueakMap" and not add features - feature freeze in other words. This can hopefully let Scott Wallace (with our help of course) get it into 3.2. And when I am talking about that, some small issues: 1. Category name. Currently it is called "SM-domain" but that doesn't say much. Perhaps "SqueakMap-Kernel" would be better or something? 2. The postscript for the RC2 changeset marks "SqueakMap" as installed (in SqueakMap itself) and installs "SM Package Loader" (through itself) which means that it will get the newest release *at the time when the image gets updated*. That is probably not want we want in the update. In fact, if we now put RC2 into the update stream and in a year SM has evolved away from RC2 making it incompatible with the master then when someone updates an old 3.2 it will... Oops. Perhaps the update changeset should just include a little snippet similar to the one that I have been posting for trying out SM? I could even add a little feature in SM that can deliver the download url for a package using a simple http request. I could make it look something like this: ChangeSorter newChangesFromStream: (('http://map2.squeakfoundation.org/sm/packagebyname/squeakmap3.2/downloadurl' asUrl retrieveContents content) asUrl retrieveContents content unzipped readStream) named: 'SqueakMap 3.2' And then we register a package called "SqueakMap 3.2" which will "always" work with 3.2. And then the postscript can still install "SM Package Loader" like it does today since it will be compatible. Neat. So Scott and Doug - if you could just review RC2 (especially the changes to classes without the SM prefix) and give it a "green light" then I can produce a changeset described above that could go into the stream. --------- Ok, what about the "thinking" part? Currently there is an interesting situation in the Squeak community and Andrew Greenbergs post called "An uncomfortable question" brought it up, even though it has been discussed quite a lot in the different modules related threads actually. In short we have a 3.3a with the "Modules" code in it that noone seems to work on currently and then we have the "lightweight modules" route which has materialized itself the last months consisting of primarily DVS (http://map2.squeakfoundation.org/sm/packagebyname/dvs) and SqueakMap (http://map2.squeakfoundation.org/sm/package/4f0b9db6-8add-43aa-8d6b-53e6a0e…) but also other tools like Spaghetti tracer (http://map2.squeakfoundation.org/sm/packagebyname/spaghetti) etc. Currently SqueakMap doesn't overlap the "Modules" code. Yet. The intention was all along that SqueakMap should fit nicely on top of Modules but still being backwards compatible in regards of being able to handle packages not in "Modules form". But now we have reached a point where we want to add features/functions that clearly will solve problems that Modules was meant to solve (think dependencies between packages etc). *Personally* I have come to the conclusion that Modules in 3.3a is dead. I tried to fool myself into thinking that it could get picked up by the rest of us but after having seen Andreas and Daniel struggle and more or less "give up" (I may be wrong in this but that is my perception) then... ;-) I have a hard time seeing anyone else succeeding. Again *personally* I think we should just face this truth, declare 3.3a as a dead branch, start harvesting as much as possible over to 3.2 from 3.3a (forming 3.4a?) and then try to look over the stuff in Modules and see what we can easily copy or learn from it. During this we should start ripping out pieces of 3.2 (in 3.4a that is) into packages of their own in SqueakMap. Using DVS and SqueakMap this is clearly possible today. So, I would like to come up with some answers to these questions: 1. Should we dump Modules? If not then how do we make Modules work? 2. If we dump Modules, what do we do with 3.3a? Is it even possible to reconstruct it easily? Is it better to simply freeze and salvage stuff from it? 3. If we dump Modules, how do we proceed with the lightweight route? I know that we haven't reached any answers to 1 and 2 yet, but just for the argument - what about question 3? Well, here are some top priority items in that case: - Add support for programmatically registering packages and updating packages Currently these two activities can only be performed using the web UI on the master server. But the design of SM allows us to improve this and this would really make life easier on the package maintainers (but users wouldn't notice any difference of course). - Add support for versions of registrations (SMCard). We need this for several reasons. Especially if we want to be able to handle dependencies between packages. Currently SM only knows about the latest version of a package. - Add support for registering optional "incoming" and "update streams". Or something similar. This is to support users sending FIXes and ENHs etc "to a package". If a package does not define an incoming ftp/http upload area etc then it can fall back on email if the maintainer expressly allows that. Packages using DVS could of course do their own thing with a CVS backend. But developers that want to work with changesets need this to keep track of contributions etc. - Add support for configurations/dependencies Now we are really stomping into the "Modules" arena. Daniel wants to think in terms of publishable "configurations" instead of registering dependencies directly "on the packages". I am also leaning in this direction. Either way, this is a very interesting area to discuss further. We need this in order to be able to let users install packages that depend on other packages. Just try installing Spaghetti tracer and you will realize it depends on DVS, and so on. - Separate all UI from model (the code is a bit dirty right now) The SqueakMap model should of course be totally clean of UI code. It isn't today, but we will fix that. Then we have other nice things (and tons more floating around): - Free text search (Scott's engine) A nice free text search mechanism in SMLoader/SMBrowser and the web UI is of course a perfect addition that will make it much easier to find packages. And we have a nice engine for this in harvesting land somewhere... ;-) - Annotations This is my catch-all mechanism for bugreports, comments etc on packages. I am not sure if SM should handle this or if we are in fact talking about a separate system. - Swikification of texts in registrations I have actually a reimplementation of the Swiki-syntax that is completely "separate" that we can plug into SM!. This would make it possible to link to other packages using just their name, embed urls in text, bullet lists and much more. We just need a Swiki-syntax->TextMorph-thingy but that couldn't be too hard to hack into my Swiki-code. - Integrated upload capability for package storage or attachments to packages. Well, SM is a catalog of course... so... should it offer storage? Anyway, a long post. Sorry. regards, Göran Göran Hultgren, goran.hultgren(a)bluefish.se GSM: +46 70 3933950, http://www.bluefish.se \"Department of Redundancy department.\" -- ThinkGeek

5 6

2 little buglets in SMLoader 0.96
by goran.hultgren＠bluefish.se 28 Oct '02

28 Oct '02

In version 0.96 of "SM Package Loader" there are two buglets: 1. The "upgrade all installed packages" does not work, probably my fault because I changed the API in SqueakMap so change this method as this: upgradeInstalledPackages squeakMap upgradeOldPackagesDirectory: downloadDirectory ...and then it should work. 2. The filter for current version sometimes doesn't work. I think it depends on if you run a downloaded 3.2 or an updated 3.2gamme into 3.2 (just guessing). Anyway Smalltalk version returns "Squeak 3.2" in some of my images. And the code in filterVersion doesn't take that into account. regards, Göran PS. No need to harvest this post that is why I chose SMBUGS as prefix. Not to be used permanently. DS

2 1

RE: [ANN] New Version of VI4 (block closures)
by Stephen Pair 28 Oct '02

28 Oct '02

Hi Anthony, Will you be at OOPSLA? VI4 sounds great...have you compared the performance of generating the interpreter of the two VMs? Here's the code: Smalltalk garbageCollect. [((CCodeGenerator new initialize addClass: Interpreter; prepareMethods; doInlining: true) cCodeForMethod: #interpret)] timeToRun In working on the "Chango" persistence VM, I've found that #tinyBenchmarks doesn't really give an accurate picture of real performance. Anyway...I'm planning to demo my persistence VM at OOPSLA and would like to re-implement it on top of VI4 (I may gain back some of the performance I lost ;) ). It would be nice to sit down with you to get an idea how much work that would entail. Cheers, Stephen > -----Original Message----- > From: squeak-dev-admin(a)lists.squeakfoundation.org > [mailto:squeak-dev-admin@lists.squeakfoundation.org] On > Behalf Of Anthony Hannan > Sent: Wednesday, October 23, 2002 1:42 AM > To: squeak-dev(a)lists.squeakfoundation.org > Subject: [ANN] New Version of VI4 (block closures) > > > Hello Squeakers, > > I'm pleased to announce that I'm finally finished with the > latest version of VI4. You can get it from its usual place > at http://minnow.cc.gatech.edu/squeak/VI4. It has been > rewritten and cleaned up and should be very stable. Once > other image format changes are incorporated (if any) and once > it is approved for a future Jitter, it should be ready for prime time. > > The Interpreter still operates directly on the process stack > object, but hooks have been provided so the process stack can > be internalized by the VM if desired. See the aboutVI4 > method comment for more details. > > 0 tinyBenchmarks reports a 30% increase in bytecode speed and > a 75% increase in send speed. > > Enjoy! > Anthony > >

3 4

RE: [ANN] SqueakMap Package Loader (0.95)
by Magistrello Alejandro (SFA) 28 Oct '02

28 Oct '02

Hi > >[SNIP] >> There was allegedly a situtation where things misbehaved when SM >> couldn't find any servers. Goran, you blamed me. Bad, bad goran ;-) > >:-) Well, I am not sure I blaed you - not finding the servers was probably a >proxy/firewall problem in itself (I hope, haven't heard anymore from Alejandro) it was not, i answered to a mail where you say this: >And you could also try with commenting out the first 2 lines in >#pingServer: if you are having trouble with the DNS or something: > > "serverAddr _ NetNameResolver addressForName: (aServerName upTo: $:) >timeout: 5. > serverAddr = nil ifTrue: [^false]." and this made it work. don´t know how to reproduce the dnu, so attached is the debuglog from a fresh image, whitout SM and filein RC1. Best regards Alejandro Magistrello PS. i read the list from work, so that´s the main reason why i don´t answer any email during weekends ;-) <<SqueakDebug.log>>

2 1

← Newer
1
...
5
6
7
8
9
10
11
...
41
Older →

Jump to page: