Squeak-dev January 2002

squeak-dev@lists.squeakfoundation.org

176 participants
612 discussions

[modules] Important: class re/definitions in change sets and updates
by Henrik Gedenryd 03 Feb '02

03 Feb '02

Dan Ingalls wrote: > Apparently some of the new updates after modules have had their classes > strangely classified. I say this because if you do a 'find...' in the left > pane of a browser, they do not seem to be findable, even though they appear at > the bottom of the leftmost pane. > Ok, the updates got out so fast I didn't have the time to say this in public: There are now multiple name spaces, one per module. So an important thing to keep in mind is that in subsequent change sets and especially updates, system categories in class definitions *have to* agree with that of the existing class, or a second class will be added in the module specified by the category. (Harvesters, in particular, keep this in mind.) Since system categories are simulated from module path names, classes will be placed in *exactly* the module specified in the category of a class definition--even if the module doesn't exist. This is for reasonable backward compatibility. So, new classes will be placed there obviously. But, for an existing class in a certain module, a *new class* will be created from the new class (re-) definition if it specifies a different module. This is not a bug, it is because every module has its own name space. One could circumvent this by ignoring the category for any class already present under #(Squeak), but I don't think this would be a good thing, all things considered. > Do you know how to > fix this so they can be found? attached. > and/or warn so it doesn't happen in the future? Umm, there is a warning for reusing class names, but they are suppressed during fileIn... suggestions? > write an update with code that will repair existing cases? attached. Finally, a warning: There are now (and have been) coming out updates that refactor the image. This should always be done on a non-modified, standard image. If there are classes in improper places (ie. badly placed modules), they are in danger during refactoring. There is code to prevent this, but there are no guarantess that this will always work (although I don't see why it should happen). Henrik

6 9

[BUG] 3.2-4652 scoller sausage can obscure top scroll arrow
by Tim Rowledge 03 Feb '02

03 Feb '02

Using the 'normal' scoller look (no offense intended but the new one with rounded ends looks really awful) it is possible to get the scroller sausage to overlay the top scroll arrow, but not the bottom one. tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: WK: Write to Keyboard

3 4

Command/control key mapping
by Harry Chesley 03 Feb '02

03 Feb '02

I recall a discussion on the list a while ago about allowing Windows users to use control- rather than alt-. I don't recall whether there was any final resolution (i.e., code) posted. I looked in the Squeak Fixes archives, but didn't see it. At the time, I thought I'd wait and hope it makes it into the official image, but as my Squeak usage approaches 50% of my time on the computer, I find my muscle memory is approaching a state of maximal confusion... I'd be quite happy with something that swapped control- and alt-, or with something allowed the core commands (x, c, v, z, s, l) to be used with either control- or alt-. To avoid unnecessary traffic on the list, perhaps it would be best to reply directly to me on this. I'll post a summary answer to the list. Thanks.

4 4

[Modules][Vote][ShamelessPlug] Big chunks?
by goran.hultgren＠bluefish.se 01 Feb '02

01 Feb '02

Answer the poll about the Modules question below at: http://marvin.bluefish.se:8080/squeakdot :-) :-) :-) Fun and useful! regards, Göran PS. Please propose useful features for the voting mechanism. DS Henrik Gedenryd <h.gedenryd(a)open.ac.uk> wrote: > Moving this to the main list... > > Dan Ingalls wrote: > > ducasse <ducasse(a)iam.unibe.ch> wrote... > >> I think that Celeste is "well" separated from the core so this could be > >> interesting to try. > > > > Hi Stef - > > > > I've been reflecting more on this since responding to your message. I > > completely defer to you and Henrik on which way to go, but I see a choice > > here: > > > > Either we... > > Find various small things that are pretty modular and do them first > > > > Or we... > > Take various big chunks that are pretty modular and do them first.

3 2

[FIX] via source forge updates
by John M McIntosh 01 Feb '02

01 Feb '02

Tim fled to his cabin in the mountains and asked me to update source forge with some changes after I verified they worked ok on the mac. Beyond posting the changes for 3.2.2 Mac mach-o VM, excluding the FFI plugin which I'll do later today, the changes are: cross/sq.h A typedef for long long int to make acorn users happy, actually acorn users get long int (32bit) since the compiler doesn't support long long (64bits). cross/sqFilePluginBasicPrims.c Revert back to pure ansi, overrides are now done in platform specific header for 64 bit file io, and for ftruncate support (#define sqFTruncate to something). For 64bit file io: a) Your platform compiler must support long long int, pointless otherwise. b) you must typedef squeakFileOffsetType to the 64bit file offset type (possibly off_t, but you need to verify the number of bits, some u**x environments are broken) fseek to the 64bit fseeko? ftell to the 64bit ftello? unix/sqPlatformSpecific.h include <unistd.h> for ftruncate enable 64bit io per notes above However you need to comfirm the 64bit file io stuff really works even if it compiles. -- -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

3 4

Re: ModuleStorageTests all error out
by Henrik Gedenryd 01 Feb '02

01 Feb '02

Ned Konz wrote: > Image version 4689. > > I tried running the ModuleStorageTests, and all of them error out: > 47 run, 0 passed, 0 failed, 47 errors > > Is there some initialization that is required but not being done? > I explicitly tried this after updating and it all went fine for me. Does anyone else see this? A Mac/Win issue perhaps? Henrik

4 3

Re: Persistence & DTSTTCPW: ZODB clone?
by John Hinsley 01 Feb '02

01 Feb '02

Cees de Groot wrote: //big snip// > Would that sound like something useful for Squeak? It has its limitations, for > sure, but it seems like the simplest way to get a solid persistence engine > into Squeak, which is a Good Thing I think. It's also a project I'd like to > tackle... Oh _please!_ Put that together with something like Comanche or Seaside and (maybe) a WYSIWYG front end (I heard that the zopistas were playing with using the Mozilla engine which is probably GLPLed, but might be loadable as a module to get rid of GPL objections) and I think we'd have a _killer_ application. I can't help with the coding (far too stupid) but I'd be happy to help on the documentation and crash test dummy side. Cheers John -- They're afraid, very afraid...... According to CRN magazine, Microsoft staff discovering Linux in use will have now access to a special 'escalation' team. Now, where did I put that stake and mallet? http://www.newsforge.com/article.pl?sid=02/01/16/0310222&mode=nocomment

3 2

[updates] 4 more; mostly whiplash
by Dan Ingalls 01 Feb '02

01 Feb '02

Folks - I've just posted 4 more updates, but they are mostly repairs for my having missed some important input from the harvesters. - Dan ----------------------- 4727initLeftMargin-ls -- Lex Spoon -- 14 January 2002 Make sure leftMargin gets initialized in CharacterScanner; this bug was brought out recently when Scamper is showing a page with indentation, and the mouse is waved over an indented line." 4728includesIdentity-sw -- Scott Wallace -- 30 January 2002 Fixes up one missed reference to References in the module work." 4729existenceOfPath-cmm -- Chris Muller, Scott Wallace -- 25 January 2002 The crux of this update is Chris's fix to FileDirectory>>assureExistanceOfPath:, which did not previously account for platform-specific differences in case-sensitivity, causing it to take a path of logic that quickly leads to a primitive failure on Win32 machine (attempting to create a directory that already exists). The 'existance' misspelling is corrected to 'existence' and the other method name with the same misspelling is also fixed, as of course are all senders." 4730FixUpdateGlitches-di -- Dan Ingalls -- 30 January 2002 In merging the various submissions from harvesters, I omitted several useful tweaks and reviewed decisions. This update attempts to set them straight, with apologies to Scott Wallace for my oversights. In particular, Restored the solution of 4728includesIdentity 4272InitLeftMargin supplants CharacterBlockScannerFix (simpler, more general) ShrinkWrapObjectsTool withdrawn until we can find a way to avoid jerkiness. Retracted 4705 and 4707. Improved wording of Brace explanation in 4714.

2 1

iteration - don't optimize it
by Mark Mullin 01 Feb '02

01 Feb '02

Ahh - that got your attention. No, I'm not really opposed to improving iteration speeds, by all means have at it. Terrific idea. My own vote is cast for a hashing class based on SHA5. I think you could get interesting results from using a perfect hash,even if the thing is 120 bits. On the other hand, maybe I didn't make my original point too well. My thread started over "can one language do everything" and my response was "no, languages are tools and you shouln't pound in a nail with a power saw". >From my own perspective, I live in a world where we drop down to native platform machine code in a few places, and C++ code may often be written to deal with little issues like "Pentiums usually predict you'll take a reverse branch over a forward branch." When performance gets to be that much of an issue (we have clients that require many billions of high level linear algebra calcs per second) you tend to survey your language tools very carefully. For the record, C++ iteration is what we use to deal with problems that really vex the computer but that the user could care less about. Smalltalk has a richer and more powerful set of iterators and collections than STL, but the costs of such a dynamic flexible solution are more than we can bear. Nothing I've said should be construed to mean I'm talking about collections the user interacts with directly. In my first post I observed that C/C++ was prefered over Smalltalk when the computers oddest peripheral wasn't directly involved :-) I really only keep responding to this because I do feel it's counterproductive to go "I don't care what you got, Squeak can do it better". I'm just arguing for a slight modification - If you don't care enough to profile it to death, then Squeak will do perfectly. Recognizing this means we can say, we don't care what your problem is, what Smalltalk can't do well directly it can do by being extended. Legacy systems, databases, whatever. But I rather violently disagree with those that claim you should just use Smalltalk cause it's iterators aren't as fast as C/C++. Bull. A C/C++ iterator/loop construct is a lot more expensive to write, a lot more expensive to maintain, and a lot less accessable. It's also a hell of a lot faster cause it's compiled, and cause if performance is the central thread, it's using static storage. For example, in such a world one has a tendancy to use a vector to aquire data of unknown length, and then immediately reconstruct it as a fixed size array as soon as the length is known. On reflection, if there are those who think I'm arguing for recoding the collection classes or using plugins to do collection -- neat idea, but no. I like Smalltalk collections just fine, I was only using collections/iteration as an example of why languages were tools. What is particularly interesting these days is that Smalltalk and it's close relatives seem to be the only ones that truly recognize that the class hierarchy is in fact a derivative language, and implicitly, a tool in its own right. In the real world of C++ it's hard to keep two class libraries from either stepping on each other or being incapable of efficient interoperation, depending on namespace:. In Smalltalk land, we regularly seem to throw 30 peoples work into one unified whole with a lot less sweat. I wrote a book in 89 under duress about how to use C++, and my primary focus was on 'if you do these things this way, you too can have the ability to create and share class libraries like we do every day in Smalltalk'. Funny, things haven't worked out that way. Yes we have more libraries, but nowhere near what I have expected. Now that's what I think is most unique of all about the Smalltalk tool. Why is it so damn good at collecting, merging, and sharing the work of many participants and everything else just sucks soooo bad. Mark

3 2

[BUG] VirtualRootModule<<cachedClassNames not updated
by Craig Latta 01 Feb '02

01 Feb '02

Hi Henrik-- It seems that VirtualRootModule<<cachedClassNames doesn't get updated (it doesn't get nilled when classes are added or removed), so, e.g., new classes aren't found with "find class..." in the system browser. -C -- Craig Latta composer and computer scientist craig.latta(a)netjam.org www.netjam.org crl(a)watson.ibm.com Smalltalkers do: [:it | All with: Class, (And love: it)]

2 1

Jump to page: