Squeak-dev March 2003

squeak-dev@lists.squeakfoundation.org

202 participants
818 discussions

[DOCS] 3 german Tutorials
by Chris Burkert 01 Apr '03

01 Apr '03

Hi I've written three Tutorials. They are at the Swiki of the Squeak e.V. http://swiki.squeakfoundation.org/squeak-ev/52 and in german language. Events ... this is about the triggering technics in Object. SUnit ... a very short introduction in Testing Buttons ... building a Morphic Button (based on Events) I will translate them to english next. enjoy Chris Burkert -- ------------------------------------------------------------------------ Student of applied Computer Science at Chemnitz University of Technology http://www.chrisburkert.de/ chris(a)chrisburkert.de ------------------------------------------------------------------------ "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." - Alan Kay --> http://www.whysmalltalk.com/

1 2

Ideas, Experiences required for changes managements
by Stephane Ducasse 01 Apr '03

01 Apr '03

Hi In the context of the Kernel Cleaning Project we are facing problems related to change management. While the idea and the tool provided by diego are cool they do not scale up well. Publishing one change one by one is not fast enough. Then when you have multiple versions of the change changeset, SWiki only shows the last one so this is nearly impossible to roll-back to a previous version (I mean I do not want to be forced to browse the upload directory and guess, I want a real way of managing a version). So before hacking yet another solution we wanted to know how others are doing. ideally we would like to have a place where all the changes can be versioned at once so we thought of using cvs, but we want that other can contribute so is source forge easy to use, adequate for this project? For supporting external reviewing process we could generate a web page from the files in the cvs. I think that we should have real tools if we want to move fast. Avi I understood that you used sourceforge for storing SeaSide code. Could you tell us more? Stef Prof. Dr. Stéphane DUCASSE 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 "The best way to predict the future is to invent it..." Alan Kay. Open Source Smalltalks: http://www.squeak.org, http://www.gnu.org/software/smalltalk/smalltalk.html Free books for Universities at http://www.esug.org/sponsoring/promotionProgram.html Free Online Book at http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html

10 25

RE: [Q] a couple of questions related to look enhancements
by Brent Vukmer 01 Apr '03

01 Apr '03

Maybe I'm in the minority -- but I like the "over-sized" icons. -----Original Message----- From: Ragnar Hojland Espinosa [mailto:ragnar@linalco.com] Sent: Mon 3/31/2003 3:19 AM To: The general-purpose Squeak developers list Cc: Subject: Re: [Q] a couple of questions related to look enhancements On Sun, Mar 30, 2003 at 01:10:09PM -0800, Avi Bryant wrote: > On Sun, 30 Mar 2003 diegogomezdeck(a)consultar.com wrote: > > > - Which is the feeling of the community about the new set of changes? > > My two cents: some of them I very much like, some of them are not to my My 4 cents (post-euro inflation;): Real nice. > scrollbar "thumb". More or less the same goes for the window icons - the > general direction is good, but they take up too much space for the amount > of detail the icons provide, and to my eye they stand out too much from I'd like to see smaller icons icons too. -- Ragnar Hojland - Project Manager Linalco "Especialistas Linux y en Software Libre" http://www.linalco.com Tel: +34-91-5970074 Fax: +34-91-5970083

4 3

What is supposed to be the effect of DisplayScreen class>depth:width:height:fullscreen: ?
by Tim Rowledge 01 Apr '03

01 Apr '03

This is a very curious primitive. First, there are no senders so I have to wonder if it is actually of any value. Secondly, just what is it supposed to do? Setting the fullscreen flag to true and the width or height to some number not equal to the full screen size does what exactly? Should the prim ignore w & if fullscreen = true? Setting the depth should do what? It can't set the depth of the Display object - that has to be done via methods like DisplayScreen>setExtent:depth:. I suppose it could possibly set the bitdepth of the OS window buffer (where one is used) but that seems like it is private to the VM. I can see a value in having a prim that programmatically sets the window size (which is why I ended up looking at this) but I don't think this prim is entirely suitable nor even properly defined nor even widely implemented. Any thoughts anyone? tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Lightbulb over his head is burned out

2 5

Concatenating binary files?
by Jimmie Houchin 01 Apr '03

01 Apr '03

Hello, I am ripping a bunch of MP3s from some CDs. Some of the segments were split into separate tracks on subsequent CDs. I am creating wave files of the split tracks and would like to concatenate the 2 wave files so that I could do an MP3 from the single wave file. I tried using StandardFileStream and #nextPutAll: to write the 2 wave files into a single then I got an error because #nextPutAll: accepts only strings. (I forgot) :) From looking at the File and Stream classes I didn't find how to write binary data to a file. I am sure this is simple and I'm just not seeing/understanding how to proceed. Any help or pointers on how to accomplish this is greatly appreciated. Thanks. Jimmie Houchin

4 10

[UNIX][VM][Mac] Can't run Squeak-3.5-1devel VM under Mac OS/X
by Ned Konz 01 Apr '03

01 Apr '03

A couple of problems with Ian's latest Squeak-3.5-1devel sources and the Mac (using MacOS/X 10.2.4, Apple's December 2002 Developer tools): * I get a "bus error" when compiling the ObjectiveC plugin. So I commented it out. (hope I don't need it). * I can't run the resultant Squeak. I get a complaint (after installing it; the library path is compiled in): $ ./squeak ../../Squeak.image arg: ./squeak arg: ../../Squeak.image looking for module vm-display-null ioFindExternalFunctionIn(display_null, -1): symbol not found: _display_null squeak: loaded plugin `/usr/local/lib/squeak/3.5-1devel/vm-display-null.so' displayModule 0x4e50b0 vm-display-null vmName: ./squeak -> /Users/wordy/Desktop/Squeak-3.5-1devel/build/squeak viName: ../../Squeak.image documentName: (null) fstat(4) => 0 image size 0 + heap size 20971520 (useMmap = 1073741824) This interpreter (vers. 6502 cannot read image file (vers. 0 Hit CR to quit Here's the "architecture" part of config.h: #define OS_TYPE "unix" #define VM_HOST "powerpc-apple-darwin6.4" #define VM_HOST_CPU "powerpc" /* #undef VM_HOST_VENDOR */ #define VM_HOST_OS "darwin6.4" #define WORDS_BIGENDIAN 1 /* #undef DOUBLE_WORD_ALIGNMENT */ /* #undef DOUBLE_WORD_ORDER */ /* damage containment */ #define DARWIN 1 Anyone have any ideas about this? Thanks, -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE

2 6

RE: [GOODIE] BinaryRelation
by Richard A. O'Keefe 01 Apr '03

01 Apr '03

"Jason Rogers" <jacaetevha(a)fast-mail.org> asked: Pardon my ignorance, since most of this is out of my league. Doesn't this make garbage collection essentially ineffective? In fact this is one of the reasons why a BinaryRelation object as a separate object *not* "owned" by the things it relates is a good idea. Suppose you have a binary relation R and two objects (x,y) related by R. Suppose this is implemented by data structures inside x and y, so that x owns a set which has y as an element, and y owns a set which has x as an element. Then you have a cycle linking x and y, which is bad news for a reference counting garbage collector. For other kinds of garbage collector, it need not be a problem. However, it does mean that as long as x remains interesting, y will be retained, even if the relationship itself ceases to be of interest. To work around that, Squeak has WeakSet, but we don't for some reason have WeakIdentitySet and WeakPluggableSet. Note that BinaryRelation is a class. *A* binary relation is just an object, and there isn't the slightest necessity for it to be held in a global variable or class variable. When the relation R is held in a BinaryRelation object, there are no cycles: R points to x and y, but x does not point to R or to y, and y does not point to R or to x. This means that using BinaryRelation objects is *better* from a garbage collection point of view. x and y remain interesting as long as either they would have been interesting anyway, plus as long as the relation R remains interesting, just like they would hang around if they were in a Set or Array. There's also some flag about coupling being raised in the back of my mind, but I am not yet able to articulate it. Here again, the point is that a BinaryRelation *reduces* coupling. Suppose we are interested in the relationship (dog is-registered-in city) Without a binary relation object, the Dog class is coupled to the City class and vice versa. With a binary relation object, we can relate objects of any two classes *without* coupling them. Obviously *some* object has to accept the resposibility of registering and unregistering dogs, but it doesn't have to be a Dog object or a City object; it can be an AnimalRegistry object which either has or isa BinaryRelation. (Probably 'has'; it would also need to keep track of (dog has-registration-number n), and we certainly don't want numbers to have to know about dogs.) Everything I have said about the merits of binary relations applies to n-ary relations as well. However, Smalltalk already has one kind of set-of-pairs (Dictionary) so adding another kind of set-of-pairs (BinaryRelation) which loosens the restrictions of Dictionary is the smallest extension which lets you do relations at all.

2 1

Re: [GOODIE] BinaryRelation
by Richard A. O'Keefe 01 Apr '03

01 Apr '03

Avi wrote: Come on, I'm not "bemoaning" anything, nor do I think the "only" is necessary. As I said, an algebra of binary relations is a natural approach for what you're doing, but it's rather awkward to model a set of Oracle tables that way (or at least, it seems so in my ignorance - feel free to enlighten me). I want to point out that the purpose of my BinaryRelation class is *NOT* to model a set of Oracle tables but simply to plug a gap in the data structures available to *programmers* for in-memory programming. Over many years I have learned to think of relations as a valuable tool for my own programming and design *without* any reference to relational databases as such. (BinaryRelation now includes #converse, #reachableFromSource[s]:, #reachableFromTarget[s]:, and #* .) E. F. Codd has published a list of 12 criteria for what makes something a relational database. (At the time, SQL did _not_ qualify...) Amongst other things, persistence, audit/recovery, and authorisation control are important. These things must be dealt with in any Smalltalk modelling of Oracle tables. They are completely irrelevant to a set of pairs data structure for internal programming use.

2 1

Re: Harvesting was: [Q] a couple of questions related to look enhancements
by Daniel Vainsencher 01 Apr '03

01 Apr '03

You might notice you're actually agreeing with my first point, and it sounds like we're only partly disagreeing on the second. You say three things (IIUC - please correct me if I don't) A. Packages should not be as small as a fix, but should be bigger, say, application size or library size. B. Fixes should go into the image. C. Integration is a lot of work. As to the first, this is not a problem of policy, it's a problem of mechanism. Right now, in SM, all package are equal. Since small things get made more often than bigger things, big stuff becomes harder to find. Most Debian UIs hide libraries. The libraries are loaded as needed by the applications, users don't choose specific libraries. In the same way, if I understand you correctly, Squeak users should not have to choose their applications from among a huge list of fixes and enhancements. Fine, I agree. The solution includes using load scripts to aggregate packages, so that people can load one load script, and get Jacaranda working, with Connectors automatically included, and also all the appropriate fixes. Another part of the solution is that some packages that are "libraries" should be hidden most of the time, and possibly also fixes and the like. That way, most users, most of the time, will not need to pick from a huge list. Note that when I thought about what SMLoader should look like, I thought explicitly that the important thing is to make it easy to start working with at the beginning, when there we 14 packages. I consiously made tradeoffs to that effect, at the expense of scalability. If people say that there's a better GUI they prefer to use, that scales higher, I would be delighted to see it replaced. I think a hierarchial view would work pretty well, if combined with keyboard control of the hierarchy (which is available), and a very available search function. About fixes going into the image, I agree. But these are not *obviously* fixes, and unless/until everybody likes them, they can live just fine in packages. The most important functions SM fill is to make the Harvesters free to not include in the image things that add function, and to make makers of such things free to publish them anyway. About integration (and testing) being alot of work, I didn't disagree before either. Which is a good reason to spread it as much as possible through the community, and not confine it to merely the Harvesters. As I've said before, it also has the benefits that you can test packages far more lazily than the image itself - it's easier to update them, and if you have a bug, it affects less people. So when packages have bugs or conflict, their users discover this, and their maintainers fix it, and it's no big deal. Daniel Martin Wirblat <sql.mawi(a)t-link.de> wrote: > Hi Daniel, > > I knew you would enthusiastically disagree with 'murmuring of > loadscripts' :) > > > A. Writing a load script is trivial. > > The script itself is trivial, but as I said you need to test it, > meaning you have to run it AND test the resulting image. This is > testing a release! If you have more than one loadscript it is > something which is MORE work than testing a monolithic image release > today. Have in mind here how many bugs, problems or not quite > beautiful things are in the single image of today. > > There are not only packages depending on other packages, there are > packages excluding each other, and this not only in a syntactically > detectable way ( name clashes, class and method redefinitions ) but as > I fear in many more subtle ways. E.g. programs produce data with > data structures on disk, communicate with protocols, have semantics of > their inst and class vars or have implications regarding the UI. You > will not find such incompatibilities in an automated way. Something on > top of assembled image A may not work on top of assembled image B or > may hamper something in B, even if the dependency system gives green > lights. > > These two points led me to the conclusion that it is best to keep the > number of packages for the official releases as small as possible and > the packages as big as possible. Of course it is a question of > sensitiveness to find the optimal balance, but I really think that > something like Diego's font-enhancement for the pref-panel is more a > fix of something ugly - it should not be a package for loadscripts. > This leads to Debian: Most modules of Debian are full blown > applications or at least tools or libraries, they don't have minor > tweaks and fixes which you can combine together to your personal > system. > > The finer the granulation of modules, the more interface vs function > there is, the bigger is the chance of problems. Debians module > granulation is huge compared to the small SM-packages which I think > about. > > > Just to make this factually crystal clear - the harvesters don't > > harvest from SM. > > Exactly because not everyone puts his code on the right avenue this is > a problem. > > regards > Martin

1 0

[FIX] MessageTallyBalloonFix-nk
by ned＠bike-nomad.com 31 Mar '03

31 Mar '03

from preamble: "Change Set: MessageTallyBalloonFix-nk Date: 31 March 2003 Author: Ned Konz If you have balloonHelpInMessageLists preference on, and you open a TimeProfileBrowser, and you move your mouse over the first blank line, you get a walkback. This CS fixes that problem. "!

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
82
Older →

Jump to page: