Squeak-dev April 2000

squeak-dev@lists.squeakfoundation.org

141 participants
506 discussions

Re: [FIX][ENH] SortedCollection robustness & speedup
by Florin X Mateoc 28 Apr '00

28 Apr '00

Hi Andres, At first I did not realize what was failing. The example with 3@3 works just fine (although the index is 13 not 26 (there are only 25 elements) like you said). The part that is still failing is s includes: #garbage. You are right, #includes is a generic message and it should probably work even for a SortedCollection and an incompatible object. I would contend that #indexOf: should be allowed to fail for an incompatible object. A SortedCollection is conceptually different from an OrderedCollection. It has no external notion of index independent of the sort criteria. I think your suggestion to use exceptions here for #includes: is the right way to do it. So, what do you think of: includes: anObject ^[(self indexOf: anObject) ~~ 0] on: Error do: [:ex | ex returnWith: false] Florin (See attached file: sortedCollection.1.cs) avalloud(a)entrypoint.com on 04/27/2000 06:53:09 PM Please respond to squeak(a)cs.uiuc.edu To: squeak(a)cs.uiuc.edu cc: (bcc: Florin X Mateoc) Subject: Re: [FIX][ENH] SortedCollection robustness & speedup Hi Florin. > I am afraid your implementation of the #includes: method only works for the > particular cases where the object is arithmetically compared directly. Or when the object provided is compatible with the operations in the sort block. > I took a stab at (re)implementing #includes: and #indexOf: for the > SequenceableCollection classes. > > !SortedCollection methodsFor: 'accessing' stamp: 'fm 4/26/2000 15:08'! > > indexOf: newObject > | index low | > low := self indexForInserting: newObject. > sortBlock isNil Hmmm... how about ifNil:ifNotNil:... > ifTrue: [ > index := low -1. > ^[index >= firstIndex and: [(array at: index) = newObject] ] > ifTrue: [low - firstIndex] > ifFalse: [0]] > ifFalse: [ > index := low -1. > [index >= firstIndex and: > [(sortBlock value: (array at: index) value: newObject) and: > [sortBlock value: newObject value: (array at: index)]]] > whileTrue: > [(array at: index) = newObject > ifTrue: [^index + 1 - firstIndex]. > index := index - 1]. > index := low. > [index <= lastIndex and: > [(sortBlock value: (array at: index) value: newObject) not and: > [(sortBlock value: newObject value: (array at: index)) not]]] > whileTrue: > [(array at: index) = newObject > ifTrue: [^index + 1 - firstIndex]. > index := index + 1]. > ^0]! ! Unfortunately, the example I provided in my previous message will fail with this method too, because it relies on #indexForInserting: and also because it assumes anObject will be compatible with sortBlock. There is no way to predict that what will be provided through #indexOf: will respond to messages probably sent in the sortBlock (remember that the sortBlock is used in #indexForInserting:). It is not possible to predict the protocol of this object beyond things like #=. Andres.

1 0

Re: (NEWBIE) FileStream help??
by Tim Olson 28 Apr '00

28 Apr '00

James wrote: >I'm trying to read from a file and output it to the Transcript window. The >method I'm using works with Smalltalk Express but fails in Squeak can anyone >look at this for me and tell me the problem please. > >Food class instance method: > >initializeFrom: aFile > | inputStream | > inputStream := File FileNamed: aFile. > self name: inputStream nextWord. > self fatCalories: inputStream nextWord asNumber. > self carbohydrateCalories: inputStream nextWord asNumber. > self proteinCalories: inputStream nextWord asNumber. > inputStream close. > ^self. In Squeak, the term "word" in methods is mainly used to signify operating on a low-level memory word (2 bytes). So "nextWord" is returning the next two bytes of the input stream treated as raw binary values, instead of what you are expecting (the next textual word). There are a number of ways to do what you want. One is to read each input line as a string, then use String's "findTokens" method: inputStream := File fileNamed: aFile. tokens := inputStream nextLine findTokens: Character separators. self name: tokens at: 1. self fatCalories: (tokens at: 2) asNumber. self carbohydrateCalories: (tokens at: 3) asNumber . . Another way is to use Squeak's Smalltalk scanner to do the scanning and processing of the input stream for you. This works well if your input token types match Smalltalk's (e.g. strings, numbers, etc.): inputStream := File fileNamed: aFile. scanner := Scanner new. scanner scan: inputStream. self name: scanner advance. self fatCalories: scanner advance. self carbohydrateCalories: scanner advance. Note that the scanner does all of the work of converting the numeric tokens to numbers. -- tim

1 0

RE: (NEWBIE) FileStream help??
by Eric Arseneau 28 Apr '00

28 Apr '00

> When I -> Do it the transcript displays several rows of 5 digit > numbers and > I do not know what they are. This works fine in st express. What > does Squeak > do different? You problem here is that nextWord on Squeak Stream's returns the next binary word, ie it takes the next byte, shits it by 8 bits, then adds the next bye, or the other way around. The point here is that nextWord is not giving you the next bunch of characters up to the next space. I couldn't find a method that would give you what you want, but then I have a really old image. I would recommend you take a look at the one in ST Express and copy it, or write your own. Something like nextWordString | start | [self next isSeparator] whileTrue. self atEnd ifTrue: [^'']. start := self position - 1. [self next isSeperator] whileFalse. ^self copyFrom: start to: self position - 1 Something like that, I haven't run this code but I think you get the idea.

1 0

Re: Packaging into the sole Squeak window
by Bert Freudenberg 28 Apr '00

28 Apr '00

On Thu, 27 Apr 2000, John M McIntosh wrote: > Ok well a 2.6 Unix/Linux version has > ioSetDisplay coded as > fprintf(stderr,"useless output if you are hoping to resize the window") > > Well it doesn't quite say that, but it certainly doesn't have the code to > support resizing the window. Unless of course that feature has creeped into > 2.7 or 2.8 > > (Sorry I cann't fix it this month (way too much on the go), takers?) > Should just be a little X-window magic eh? To fully support it, there's more needed than a "little" magic. That primitive is for switching to a different video mode with the given resolution and depth. I guess to switch back to windowed mode the fullscreen flag would be false, and width/height/depth ignored. Could SqC confirm this? It's a DirectX game thing I suppose. Andreas? A trivial implementation with X is this: /* ioSetDisplayMode: switch to specified videomode * Note: we ignore depth and fullscreenFlag for now because to * change it we would have to do use the XF86VidMode extension * or something similar not cross-platform ... */ int ioSetDisplayMode(int width, int height, int depth, int fullscreenFlag) { XResizeWindow(stDisplay, stWindow, width, height); return 1; } It just resizes the window. It does not touch savedWindowSize. It ignores the other fullscreen logic (prim 233). The third fullscreen logic (the global fullScreen) is only in effect at startup anyway. ~8-} -Bert-

1 0

Re: InputSensor still polling?
by Lex Spoon 28 Apr '00

28 Apr '00

Dan Ingalls <Dan.Ingalls(a)disney.com> wrote: > I believe that once we had that state of affairs, then peer pressure would bring about the necessary implementation on the remaining platforms, with no single one constituting a greatly onerous burden. > By any chance does anyone have a copy of the Unix version of this I sent around last summer? I put it on the Swiki, and since then the Swiki has lost its files, my computer has crashed, and I've returned the laptop I developped the code on. If anyone has either of the two files, I'd love to have a copy. :( Here's the message I sent around: http://www.egroups.com/message/squeak/4491?&start=4478 Figuring out how to make the new system compatible actually took a little bit of thought. The message also has some suggestions for updating the VM's. Now why didn't inertia and peer pressure take over after I posted this? If I recall, the problem at the time was to define what exactly the VM interface should look like. Somehow it ended up on Squeak Central's laden plate, and since then they've had much more exciting things to work on. The version I sent around was specifically for mouse and keyboard events, but there was talk that we should have some sort of general event mechanism. Personally, I'm not sold on the idea of waiting for a general event mechanism. First, what exactly would the other events would be? Furthermore, what is it about an event system that is complicated enough to make it worth generalizing? An event system has a queue, and a primitive or two to query the queue--this doesn't sound like a terrible burden even if it has to be implemented from scratch a few times. Finally, regarding window resizes, let's not forget someone has posted a very simple in-image way to deal with window resizes. No VM mods are required.... -Lex

1 0

Re: UI Opinions
by Marcel Weiher 28 Apr '00

28 Apr '00

> From: Russell Allen <russell.allen(a)firebirdmedia.com> > This is interesting. Was the Next dock aligned along one of the sides of > the screen to take advantage of Fitt's Law when dragging/selecting > minimized windows? The dock actually was not a place where minimized icons went automatically, this is something that's new in OS-X. The dock was a repository for your ~10 most frequently used applications and the recycler, located on the right side of the screen. It could be used both for launching these applications and for switching to them. Dragging documents on top of the app-icon for opening was added later. Applications not in the dock, as well as minimized document windows automatically went to the bottom of the screen, left to right and bottom to top. No scaling, all the tiles were a constant, fairly large size. Applicaion tiles sometimes animated to show application status. For example, the "clock" application was nothing but an animated application tile. It was all highly effective in creating a transparent interface for working with multiple collaborating applications, where you directly to what you want to do instead of working the computer/interface. I've never seen anything like it, especially for working with many applications simultaneously. Marcel

1 0

Re: [ENH] Celeste receives attachments
by Lex Spoon 28 Apr '00

28 Apr '00

Bob Arning <arning(a)charm.net> wrote: > On Thu, 27 Apr 2000 02:19:08 +0300 Daniel Vainsencher <danielv(a)netvision.net.il> wrote: > >Guys, anybody feel like doing the encoding side of QuotedPrintable? (base64 is basically enough, but QuotedPrintable is, well, printable...) > > I have included below what I use. You will need to change the class to one you have. Excellent news, Daniel, and Bob--my was that fast. String might be a good choice for the class to put the encoder in -- String>>toQuotedPrintable. It's a general purpose utility, and might well be usable in contexts other than reading mail. As for the UI, I've been thinking that instead of a menu, a good way to handle attachments would be to make a link within the text which is hyperlinked to the attachment. Clicking on the link would give you a small menu with things like "open in window" or "save to file". Really, it should be a very similar menu to the one that FileList has. To make such a link, one first makes a new subclass of TextAttribute with the relevant instance variables (probably data, content-type, and default file name). Adding the attribute to your text is a small challenge, but AttributedTextStream should be useful here. If no one goes after this, I'll try and do it, but it will be at least a week. Again, this is great news. Attachments are the most important facility that Celeste has been missing. -Lex

1 0

InputSensor still polling?
by C. Gable Watts 28 Apr '00

28 Apr '00

Dan, I was going to make a comment about 'polling' to find out when the Display is resized. I was going to recommend instead a new input event from the VM come into InputSensor instead. So much more tidy... I just assumed that InputSensor had been converted by now to get events from the VM (as we had done at Interval in our Squeak-based project there). But when I looked at class InputSensor, I found to my amazement its still polling based (with all the problems of missed events and wasted cycles that implies). Admitedly I don't follow the discussion on this squeak list as often as I'd like. Is there some reason why InputState has never been converted to reaping 'events' from the VM rather than polling? Or is it just that no-one doing Squeak development has gotten around to it yet? Perhaps it remains polling in an attempt to avoid requiring the VM to poll on some platforms? No, that couldn't be it, the VM already polls for the interrupt key on some platforms. Would it help to post the version of class InputSensor I wrote for Interval's event-driven version of Squeak? It might help some though much of the difficult work was in the two new primitives it used. Implementing those new primitives on all of Squeak's different platforms would be a chore & a half. Perhaps the platform spread has gotten too wide to expect the new primitives it requires to be implemented on all platforms? Carl Watts >It's so easy (was it Lex who suggested this?). Define... > >... and insert the line > DisplayScreen checkForNewScreenSize. >right before the delays in > PasteUpMorph>>interCyclePause: (for Morphic) >and > Controller>>interActivityPause (for MVC)

2 1

Re: UML Visual Modeling in Squeak?
by Francois Le Coguiec 28 Apr '00

28 Apr '00

Conrad, If you are interested in Smalltalk and UML modelling (or modelling in general) you might want to take a look at: http://www.htc.honeywell.com/dome/ It is the ultimate (meta)modelling tool. I wish someone would port this to Squeak or build something equivalent. -Francois- >From: Conrad Taylor <conradwt(a)yahoo.com> >Reply-To: squeak(a)cs.uiuc.edu >To: squeak(a)cs.uiuc.edu >Subject: UML Visual Modeling in Squeak? >Date: Wed, 26 Apr 2000 16:28:00 -0700 (PDT) > >Are there any plans for UML visual modeling within the >Squeak environment or will this be part of the >refactoring browser? I'm thinking about something >that would integrate nicely with the system browser. >For >example, something similar to Together/J (i.e. provide >a source as well as a modeling view that can be >altered by the user). In addition to the general UML >support, I would like to be able drag-n-drop GOF and >other patterns onto the modeling view, edit these >classes as necessary in either view (i.e. modeling or >source view), and save this information. Thus, one >can create categories or packages, and classes in >either the system browser view or the modeling browser >view. If anyone has any information about this or >similar projects, please let me know because I would >be very interested in assisting with this effort as a >new person to Squeak Smalltalk. > >Thanks, > >-Conrad > > > >__________________________________________________ >Do You Yahoo!? >Send online invitations with Yahoo! Invites. >http://invites.yahoo.com > ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

1 0

RE: Aha! How to get rid of Blocks in Smalltalk.
by Richard A. O'Keefe 28 Apr '00

28 Apr '00

I wrote >David Farber <dfarber(a)numenor.com> >describes a restriction on blocks (one message send per block) >and the reason for it (making a callback-based GUI work). David Farber replied The *reason* i proposed the change to blocks really has nothing to do with the callback-based GUI example i described. the reason i proposed allowing only one message send per block is because you can always group message sends together by putting them into a method. blocks, as they currently stand, break the principle of monotony. I am not familiar with the "principle of monotony". If it's the old "each language should have ONE way to do each thing", then I was impressed when I read it 20+ years ago, but then realised it's not possible in any non-trivial language. Given that we can write x+y in some language (where "x" alphabetically precedes "y"), does it make sense to ban y+x? In Smalltalk, since we have #ifTrue:ifFalse, should we eliminate #ifFalse:ifTrue:? Let's take another stab at language trimming. Smalltalk-sans-blocks doesn't need temporary variables either. Let's take my DomNode>>select: example, which starts out like select: aBlock |result| result := self clone privateZap. ... We can eliminate the temporary by writing select: aBlock ^self select: aBlock into: self clone privateZap. select: aBlock into: result ... See? We had two mechanisms for introducing local names, and we can get rid of one of them. That does introduce some awkwardness. Because we can store into temporaries, but not arguments. But hey, that's ok, we don't need assignment to temporaries either! (Assignment to instance variables, global variables, and so on, yes. To temporaries, no.) Prolog manages fine without that. Basically, you can handle any flow chart by associating with each node the set of temporaries and arguments live at that point, give the node a name, and make those variables its arguments. For this to be reasonably efficient, we'd have to make method calls tail recursive, which would be nice anyway. In fact, if we eliminate all but one-message-send blocks, we pretty much have to learn how to do without assignment to method temporaries anyway, because if we move stuff into other methods, it doesn't have access to the method temporaries. i have heard this several times in regard to my proposal and i am convinced that exactly the opposite is the case. methods make code *clearer* and *easier* to understand. But I provided an example where they *DIDN'T*. All i am saying is, let's use more methods. That's not what I understood from earlier messages. Blocks (when they group message sends) are exactly the opposite; they are totally anonymous. Of course. Some things *shouldn't* be named. Breaking code out of a block and turning it into a method makes it something that is accessible from outside, and something that subclass designers have to worry about. Having to figure out how to re-implement a method (because it _might_ be called from outside) which makes no real sense in a subclass (because it uses a different algorithm) is not my idea of fun or clarity. Of course, when you _want_ subclasses to override parts of an algorithm without having to copy the rest, then it actually buys you something to split those parts out as named methods. You have to actually *read* the code to figure out what is going on. A well named method quickly lets you know what its group of messages is all about. This seems backwards. If you want to understand what a method is for, you read its interface line and its comment. Only if you want to understand how it works do you want to read any of the code, and then you *need* the code to be visible. I have already made that point. If there is anything about a block that isn't obvious, well, that's what we've got comments for. Smalltalk provides some fairly heavy hints about style. In particular, the size of the bottom pane in a browser quitely suggests "it would be a really good idea for the entire method body to fit here". As long as method bodies are small, I don't think it matters how many blocks or message sends in blocks there are. If anything_ about a method is complicated, whether it is in a block or not, then is time to do some refactoring.

1 0

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

Jump to page: