Squeak-dev June 1999

squeak-dev@lists.squeakfoundation.org

139 participants
408 discussions

Re: On Reuse
by Lex Spoon 01 Jul '99

01 Jul '99

Edward P Luwish <eluwish(a)uswest.com> wrote: > Would namespaces make reuse easier by permitting the "reusable" code to access private versions of otherwise well-known objects? It certainly isn't the only problem, but a big enough one. It may be valuable to approach code reuse the way one approaches porting. Porting to a foreign environment is a pretty well understood activity with lots of grist for the pattern mill, unlike reuse which is more of a holy grail as you eloquently point out. > > Ed I believe so, but at a different level. I don't think anything can stop the fundamental problem that computer systems are complex, and thus that a component of one system can't just be plopped somewhere else even if they do basically the same thing. The way namespaces help reuse, AFAICT, is that when you *do* decide to try and make a reusable component, you can give it a name that is unique across the world. Thus, it is easier to grab a reusable component and plop it in another program program, because there are definately no name conflicts. Without namespaces, any component you write has a chance of conflicting with someone else's component--and such problems are a real nuisance to work around. Putting prefixes on your names does help, but it doesn't completely eliminate the risk. Lex

1 0

Re: On Reuse
by Lex Spoon 01 Jul '99

01 Jul '99

Rik Fischer Smoody <riks(a)smOO.com> wrote: > Reuse requires a state of mind AND a lot of work. > It does not happen automatically. > On that, we agree. [...] > Now all of the rest of us see two substantially incomparable things... > noise, bulk. > It's REALLY hard to remove those forks. Please don't speak for "all of the rest of us". You seem to be arguing that reuse is a good thing. I completely agree. I'm saying you don't always have the luxury of trying to reuse every bit of existing code you can find. To give a concrete example, I once spent 2-3 days looking for a POP implementation, and when I found one, spent another 1-2 days trying to figure out how to fold it into my application with the least amount of change. In the end, I gave up and wrote my own from scratch--in about 15 minutes. Granted, it was helpful to look at the other person's code, but straight reuse just didn't work in the short term--the other code simply made a lot of assumptions that were awkward in my particular system. Furthermore, that was for *POP*, which is relatively simple as far as computer modules go! Just because I needed a "POP component", and someone had written a "POP component", didn't at all mean I could just pick theirs up and use it. (And likewise, just because I write "a linux sound module" and someone else writes "a linux sound module", they aren't necessarily duplicates! There've been at least four such modules to go across this list, all with important differences). Lex

1 0

Re: [ENH] OS-level events
by Peter William Lount 30 Jun '99

30 Jun '99

Hi, I like this idea. The low level OS Event collection system that is being implemented and discussed would still be needed to feed this "generic event queue" which could be built in Smalltalk code. A sorted collection would not be needed IF the events were put into the collection as soon as they occured. But this can't be garranteed from the OS Events. So you would need to use the sorted collection as you indicated. Peter William Lount peter(a)smalltalk.org http://www.smalltalk.org ---------- From: Reinier van Loon <R.L.J.M.W.van.Loon(a)inter.nl.net> To: squeak(a)cs.uiuc.edu Subject: Re: [ENH] OS-level events Date: June 30, 1999 1:39 PM I keep getting the impression that the event systems designed so far are only concerned with keyboard or mouse events. These events are then put in an event queue with some information regarding the event. Why not define an event as <time, object> and event queue as a collection sorted by time? The global event (interrupt) handler detects an event on the queue (tim's work) and gets the rest of the event of the object mentioned in the event. In this way, each object (keyboard, mouse, network, etc.) can have it's own buffer. And composite events are detected easily by comparing the time stamps. You could even start new processes to deal with events or have different event handlers wait on the queues of the objects. No 'centralized' event queue anymore. Just an idea. Reinier.

1 0

On Reuse
by Lex Spoon 30 Jun '99

30 Jun '99

A comment to the list. I find it quite frustrating when I post something to the list, and get replies back saying I should have used this or that bit of code someone else had already posted. It's especially frustrating when it's just a few thousand lines of code or less, which can be regenerated in a few hours or maybe one day. The fact is, trying to reuse code, even moderately small amounts of code, is not all that easy. You can't always just drop in someone's foo and expect it to work. There are hidden costs in reusing code: 1. The new project will probably need to be modified to fit assumptions in the reusable code. 2. If the code hasn't been reused much before, it's probably going to need modifications for the new project. So the new author will likely make changes to the original code, and end up having to negotiate those changes with the original author. If the new author ends up making a new fork of the "reusable" code, then the value from reuse has largely been lost. 3. People have to become aware of appropriate code to reuse. That's tough, and it takes time. The UIUC repository could help us if more people used it, but even there, you have to figure out what keywords to put in. Point is, even if you have somehting perfectly reusable, don't be surprised that a particlar person hasn't heard of it or didn't think of it. To say it again: just because you have an X, doesn't mean that someone else can just pick it up and start using it. It takes significant effort, and oftentimes it is easier to code another X from scratch. So, whenever you are tempted to make a post implying insta-reuse of something, please consider making one of the other kinds of posts described below. First, if you have some code that you think will help someone else's project, tell them about it and be sure to explain how you think it will help. Don't just say "you should have used my foo", period. Second, if you are trying to build a sort of library that can be easily reused, don't fool yourself that it is going to be trivial. It takes significant work to build easily-reusable libraries, and it's unfair to just expect others to do a lot of that work for you. Even once you have identified a system that someone posted about could make use of your library (or whatever it is), there is work remaining to look at the library and the system and to figure out how to make reuse happen. Don't just assume they could just trivially drop your library; either really look closely, or be appropriately tentative in your proposal--less tentative according to how closely you have looked. Finally, if you have some code for a project which is very similar to something that just got posted, you could post about your project and explain how your version differs. There will probably be interesting differences between them, if only you take the time to look for them. That's all. Thoughts are welcome. Lex

3 2

Re: [ENH] OS-level events
by Reinier van Loon 30 Jun '99

30 Jun '99

I keep getting the impression that the event systems designed so far are only concerned with keyboard or mouse events. These events are then put in an event queue with some information regarding the event. Why not define an event as <time, object> and event queue as a collection sorted by time? The global event (interrupt) handler detects an event on the queue (tim's work) and gets the rest of the event of the object mentioned in the event. In this way, each object (keyboard, mouse, network, etc.) can have it's own buffer. And composite events are detected easily by comparing the time stamps. You could even start new processes to deal with events or have different event handlers wait on the queues of the objects. No 'centralized' event queue anymore. Just an idea. Reinier.

1 0

Re: FMP, the game
by Bob Arning 30 Jun '99

30 Jun '99

On Mon, 28 Jun 1999 23:10:42 -0500 Tim Olson <tim(a)jumpnet.com> wrote: >Is the game something you came up with, >or is it based upon some other strategy game? Hi Tim, It's based on an older game. I wonder if it was so obscure that no one will recognize it. Cheers, Bob

2 1

Re: [ENH] OS-level events
by Peter William Lount 30 Jun '99

30 Jun '99

Hi, Thanks... Alt-backspace sounds cool. Peter William Lount peter(a)smalltalk.org http://www.smalltalk.org ---------- From: Jarvis, Robert P. <Jarvisb(a)timken.com> To: 'peter(a)smalltalk.org' Subject: RE: [ENH] OS-level events Date: June 30, 1999 12:13 PM Both Ctrl-ESC and Alt-ESC are used by Windows. Ctrl-ESC brings up the Start menu, and Alt-ESC switches between active windows on the screen. Also for purposes of information Ctrl-Shift-ESC brings up Task Manager. Ctrl-TAB is *supposed* to switch between MDI child windows in an MDI application, but this may be deprecated behavior as it seems that some of MS's latest and greatest don't seem to use this anymore. You might consider using Alt-Backspace for the purpose of clearing the event buffer instead. I don't know of any app which uses this combination, and it seems easy enough to remember. Bob Jarvis The Timken Company

1 0

Re: [ENH] OS-level events
by Peter William Lount 30 Jun '99

30 Jun '99

Hi, It would be a pain if the buffer size is fixed. NeXTSTep/OpenStep had a limit of 50 events. Sometimes 50 events was not enough - it is really annoying to have your keystorkes dropped - very confusing. Other times there were too many event queued up (when the system was slow or not responding well) and you wish you had a way to cancel them all (when you make a mistake) - how about a special command key that erases the event buffer? "Cmd-ESC" or "Alt-ESC" if it's not used already by any operating systems or applications? Could you make the "circular buffer" resizable by deallocating it and reallocating a new one if someone wanted it larger? The linked list approach is still the best for unpredictable event list size. The size of the list shouldn't get too large, in normal usage, as the events would get "consumed" pretty quickly. If the old unlinked cells are kept on a free list then they can be reused over and over and a new one is only needed when the free list is empty. A number (128) of the them could be preallocated if needed. If you do go with a circular buffer of a fixed size please make the size large - say 128 or 256 entries? Peter William Lount peter(a)smalltalk.org http://www.smalltalk.org ---------- From: Tim Rowledge <rowledge(a)interval.com> On Wed 30 Jun, Lex Spoon wrote: > I believe we are working on different things. You did up a general event system, righ > t? All I wanted was to tunnel up a handful of specific kinds of events. I _think_ they're the same, but I have been wrong on several occasions this century :-) I did a quick example that handled the 'screnn size has changed' event, just to show how it wokred and to illustrate the possibility of events other than key/mouse being useful. > Since I don' > t know how general event systems work, and since I *do* understand > how semaphores and linked lists worked, I went with what I know. Nothing wrong with that at all; the stuff I wrote uses a simple circular buffer for exactly the same reasons. The one advantage I can see with a fixed circualr buffer is no need to allocate new chunks; the obvious disadvantage is the chance of overflowing.

1 0

Re: [ENH] OS-level events
by Lex Spoon 30 Jun '99

30 Jun '99

Tim Rowledge <rowledge(a)interval.com> wrote: > On Tue 29 Jun, Lex Spoon wrote: > [SNIP] > > You could have saved one of your weekends by grabbing the event stuff I did > months ago! I think it's better to get as much as possible into the generated > code, so I put the event queue handling in Interpreter. It also reduces the > load on the platform code files. > See http://sumeru.stanford.EDU/tim/pooters/SqFiles/deltas/sq23Events.zip > > tim > I believe we are working on different things. You did up a general event system, right? All I wanted was to tunnel up a handful of specific kinds of events. Since I don't know how general event systems work, and since I *do* understand how semaphores and linked lists worked, I went with what I know. This is not to say rolling input events up into a more general system would be a bad idea--I really have no idea. Can you elaborate on how a general event mechanism would be useful here? What other kinds of events might we want to use, where raw semaphores don't cut it? Also, I didn't talk about it, but the requirements on the platform-specific part of the VMs are about as low as I can imagine them being. Individual platforms must implement code to record input events into a queue, and code to do various queries on that queue. Preferably they also rewrite the keyboard queries to use the new event queue, so that MVC and Morphic can coexist. How much less than this can you get away with? I guess you could try to put the queue in the platform-generic section, but it's not a huge win. It might even be a loss, on systems where the OS already has a nice queue to use. (I didn't use the OS-level queue in XWindows, because that same queue has other kinds of events like window redraw requests, but it might be more convenient on other platforms). Lex

2 1

RE: [ALL] Lobbying - Smalltalk KILLER APP!
by Jarvis, Robert P. 30 Jun '99

30 Jun '99

Truly compiled lightweight threads would indeed be faster than interpreted threads, but perhaps interpreted threads would be "fast enough". Given that you're slowed to network speeds anyway (consider that a T1 is relatively slow compared to bus speeds, which are relatively slow compared to internal processor speeds) I think that the issue becomes one of responding to multiple requests "fast enough". Bob Jarvis The Timken Company > -----Original Message----- > From: Dick Karpinski [SMTP:dick@cfcl.com] > Sent: Wednesday, June 30, 1999 1:05 AM > To: squeak(a)cs.uiuc.edu > Subject: Re: [ALL] Lobbying - Smalltalk KILLER APP! > > What a lovely vision! > > But I don't understand how an interpreted server can have processes > as lightweight as compiled lightweight processes. Is this after some > hypothetical compiler has sped up frequently used code paths or > something? I think I understand parts of that direction, but it does > not seem to get much discussion here. > > Dick

2 1

Jump to page: