Squeak-dev July 2000

squeak-dev@lists.squeakfoundation.org

121 participants
566 discussions

Re: Compiler, was Re: Block closures
by Lex Spoon 31 Jul '00

31 Jul '00

I also would like to see a standard Squeak parser that is clearer and easier to work with. Another starting point might be the refactoring- browser's parser. Why not?! It is under scrutiny by a large number of people, and it's been proven useful for refactoring, rule-based code rewriting, and for "lint" checking. I haven't looked real closely at the RB's parser, but from the outside it sounds promising. But anyway, what would people really like out of a parser? Here are some possibilities: 1. A clear parse-tree structure and symbol table. This was my primary motivation behind finally writing a custom parser for Lucid: Squeak's parser appears to be highly geared towards compilation, and it loves to use encoded integers that end up embedded in byte codes. Also, for analyzing code in the abstract, it is nice to have explicit nested symbol tables that can be inspected after the parser has finished. 2. Ability to generate parse trees from code, not just Smalltalk code. This is useful for parsing alternative languages like Prolog. 3. Ability to execute statements straight out of a parse tree. Or at the least, the ability to generate a block from a parse tree which can later be evaluated. (blocks and methods are very similar in the abstract, but they aren't in Squeak). It just seems like this should be possible, due to the nature of what a parse tree is. 4. Ability to make simple pattern-based modifications to a parse tree. This is useful for partial evaluation, as well as anywhere that the refactoring browser's rewrite tool would be useful. 5. Ability to clone a parse tree into a different format, so that, eg, the CCodeGenerator can continue to work. -Lex Dwight Hughes <dwighth(a)ipa.net> wrote: > Hal's Squeak compiler stuff is at > http://www.hellblazer.com/personal/squeak/ > > Hal approached the design of the new compiler in a very "engineered" > fashion -- the result is somewhat larger and structurally more complex > than the current design. While it might be more easily extended in some > ways, I found it to be rather unsatisfying since it added overall > complexity in an area I would most like to see simplified and clarified > instead. > > -- Dwight > > Les Tyrrell wrote: > > > > About the compiler: Once upon a time, Hal Hildebrand wrote a parser/compiler > > for Squeak which he called "Loki". I meant to give you a nice tidy web reference > > to this earlier, but I have not been able to find it. I could give you a link > > to the source files, but the laptop I have them on is dead right now. > > > > So, perhaps someone out there might have a link or more information? > > > > - les

4 3

4th Estate server (roarr.com) - gone
by Paul McDonough 30 Jul '00

30 Jul '00

Fellow Squeakers: As a few of you have noted offline, the 4th Estate ftp server where we stored our Squeak contributions for download is no longer there. That is because, quite literally, it is no longer there, and we don't expect it to come back. The projects will be reappearing shortly, although exactly when/where is still unclear. Please feel free to contact me offline and I will be happy to discuss the status of each. All of them require some clean-up before any but the most cussed and determined Squeakers will want to try to install them (see previous discussions on this list). That clean-up is in progress. The projects are: - port of T-Gen to Squeak - a project related to platform events (as yet nameless) - a versioning doo-dah, which you may have heard referred to as "Roarr" - a platform level messaging channel (nameless? - I forget) I will post updates as these projects become available for download. Please note that while the code is open source under the Squeak license, the name "Roarr" is a trademark of 4th Estate, and that project when it reappears will be known as "Tefkar". Well, why not "Tefkar"? On behalf of the ex-4th Estate Squeakers, Paul wnchips(a)home.com __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/

2 1

[Q] Does anyone have a radix search trie Smalltalk implementation?
by Rob Withers 30 Jul '00

30 Jul '00

Or any abstract tree implementation. There's no sense in reinventing the wheel. Even better would be a Slang implementation. 8-) (drool) thanks, Rob -- -------------------------------------------------- Smalltalking by choice. Isn't it nice to have one!

1 0

Re: [ENH] Alternative EventSensor
by Rob Withers 30 Jul '00

30 Jul '00

Hi Andreas, I would have to say that your implementation presented me with a very nice hook. Thanks! All I had to do is install an eventQueue that responds to #nextPut: and we were off and running. I am attaching the most recent LindaTalk. I have created a LindaEventProcessor, that supplies a pumped queuing mechanism and spits the events out based on linda style event registrations and the matching of a tupleTemplate with the event that was stuffed into the queue by the EventSensor. This seems to run at ~ 130,000 events/sec on the enqueue side. I don't know how the event handling side is performing, but it seems to be pretty fast. After unzipping this tarball, please filein the following: EventSensor-ar.cs Linda-Base.X.cs Linda-Queues.X.cs Linda-VM-Events.X.cs This will open a workspace with commands that installs the LindaEventProcessor for 30 seconds only, or perminently. It *does* register a KeyboardEventHandler since your code redirects all keyboard traffic to the queue if one exists. There is also a command, in the workspace, to install a TestMouseEventHandler. Your EventSensor handles current mouse events and also queues them. This MouseHandler evals 'Smalltalk beep' whenever a mouse event comes in. You can also uninstall it. Does you think this performs well enough for the potential volume of event traffic? Do you like the registration semantics? I think we can give Object the Tuple interface and override the #match: method where we need to. This means that the target events and the registered tuple templates can be different classes and so we could have Registrations (like MouseEventRegistration) as the template, and it will #match: the incoming events. I think I can see my way clear to writing an event based socket plugin and have a LindaSocket that registers to this queue based on EventType and the SocketHandleId and the read/write/exception flags. The data can be buffered separately and the callback would cause the socket to go get data, or write data. Doing this so that the vm is backward compatible is the real trick I think. I also refactored the EventTupleSpace to use the LindaEventProcessor for it's event engine. It solved a deadlock/starvation problem and cleaned up the code considerably. I am now getting around 700 tuples/sec into the EventTupleSpace (this is with 3 eventThreads and a producer and a consumer thread). Rob "Raab, Andreas" wrote: > > Folks, > > After looking at Tim's EventSensor stuff I figured that there are a couple > of things that I don't like (no pun intended). So I took a little time and > rewrote it the way I think it should be done. Attached is the corresponding > change set which you can file in into any Squeak version (I tested it only > with 2.9a but I strongly believe it'll work with any Squeak). Here are the > major differences: > > * InputSensor compatibility > The provided EventSensor gives you full compatibility with InputSensor. It > allows to implement either the (old) state based API (that is #primMousePt, > #primMouseButtons, #primKbdPeek, #primKbdNext, #primInterruptSemaphore etc.) > or a new event based API, consisting of only two new primitives (one of > those optional). > > * Decoupling Morphic and Events > Events are not automatically converted into MorphicEvents but stored as > "raw" data. I figured that some people might be interested in packaging > event in different ways so that there's no point in converting the events > before knowing in which context they're used. > > * A somewhat different event format > I've added support for time stamps (which we will need for determining > double-click times etc) for all events, as well as a number of currently > "reserved" slots for the defined events. I think that we may want to use > these reserved slots for stuff like a window handle, Unicode characters, or > meta-keys (such as function keys or similar). > > How does it work?! First of all, the provided EventSensor basically shadows > the "old" primitives with instance state. Since these primitives have been > state based anyways, the EventSensor simply replicates this particular part > of the C support code, (pre-)processing events as they come in and updating > the state as required. Thus, whenever you ask for "Sensor mousePoint" you > will get the latest mouse position regardless of the events still in the > queue. This is useful since most users of Sensor use want to see a quick > snapshot of the current state rather than an outdated state from possibly > several hundred milliseconds before. > > Events itself are read in by a process running at #lowIOPriority. This > process waits either waits for a specified amount of milliseconds between > looking for more events or can be triggered by an event semaphore. You may > ask why I'm using two mechanisms here but the answer is simple. Most VMs > will not support true asynchronous notifications about events so we do have > to poll at some point. If, however, the VM does support async event > notification, the semaphore can be used to signal incoming events. The > design of the EventSensor allows for both mechanisms. > > Whenever an event comes in, it is processed by the EventSensor. Processing > means to update the current state so that it reflects the state that would > be reported by InputSensor. Also - given that an event queue is present - > the event gets queued up there, allowing clients to retrieve the events in > order. Therefore, you can use both approaches either the state based > protocol of InputSensor or an event based protocol (such as for morphic). > The only difference is that you have to install an event queue if you wish > to process the events yourself. > > User interrupts. These are handled by the ioProcess running in EventSensor. > Again, this is basically a replication of the functionality that was > formerly carried out by the VM support code. If EventSensor receives a > keyboard event which represents the interrupt key, then it signals the user > interrupt semaphore. A small but important side note here is that because > the interrupt watcher runs at #userInterruptPriority and the ioProcess of > the EventSensor runs at #lowIOPriority, the interrupt watcher process will > *not* interrupt the low-level event process but only processes running at > regular user priority. Again, this is the same behavior as before so it's > completely compatible with the internals of the InputSensor primitive set we > have today. > > I'm sending this CS as a base for discussions. If you wish to try it out, > all you have to do is to file it in and execute "EventSensor install" and > everything should keep going just as before. As of now, the primitive > support for the two new primitives is not provided since I'm still trying to > figure out how to prevent the C support code from creating raw oops (another > thing I don't like is that with Tims implementation you have to create oops > yourself). > > Comments are, of course, very welcome. > > - Andreas > > ------------------------------------------------------------------------ > Name: EventSensor-ar.cs > EventSensor-ar.cs Type: unspecified type (application/octet-stream) > Encoding: quoted-printable -- -------------------------------------------------- Smalltalking by choice. Isn't it nice to have one!

1 0

RE: [ENH] Alternative EventSensor
by Raab, Andreas 30 Jul '00

30 Jul '00

Tim, > I don't care much how the details are done so long as they work Well, I do if it's such a critical piece of the system :-) That's basically why I put this out for discussion first. [Re: ST oops] > Huh? It makes SmallIntegers (or potentially LPIs I guess). What's > the problem with that? Two problems basically. #1 I simply don't like hacks like "#define INT_OBJ(val) (((val) <<1) | 1)" if there might be a cleaner solution. #2 is that for time stamping an accurate mask is required and forgetting it may cause trouble. Yes, all of this can be debugged but why even bother?! There is only one situation where one might argue that exposing the internals is actually a good idea - which is when you want to return something different than an Integer (such as a string). But as I understand it, for the time being we won't have a use for anything but a number of integers so I'd rather not expose the details too much. [Re: Latest state] > One possible problem with your 'latest state' details - I can't > prove it, but I have a feeling from my ponderings that it is > quite important to flush the event queue down to the event > responsible for the state you are returning. Something about > getting an event later that has in some sense already been > handled worries me. I had originally thought about removing the events from the queue before returning state information but the thing that bothered me about it was that a quick (even accidental) state check removes valuable information from the queue which is lost for those clients who actually rely on it. E.g., if you write a drawing program and really want to use all the mouse events coming in, some completely unrelated sender of "Sensor mousePoint" could remove all sorts of valuable information. Even worse, it could remove critical information such as a mouse up event. Therefore, a tiny little piece of bad code could affect all the good code you have. In the end, this lead me to returning some current state and obviously (e.g., if you use "[Sensor leftShiftDown] whileTrue") this state must be updated according to the latest known information. - Andreas

3 2

RE: [ENH] Alternative EventSensor
by Raab, Andreas 30 Jul '00

30 Jul '00

Tim, > > [Re: ST oops] > > > Huh? It makes SmallIntegers (or potentially LPIs I guess). What's > > > the problem with that? > > > > Two problems basically. #1 I simply don't like hacks like "#define > > INT_OBJ(val) (((val) <<1) | 1)" if there might be a cleaner solution. > So call integerObjectOf: or positive32BitIntegerFor: ; for a freely > declared hack to demonstrate that events can be done it's no > great crime to use a macro. It's not a great crime but it's not a clean solution either. Calling #positive32BitIntegerFor: or any such function can cause a GC in which case the OOP provided may move and you have to keep in mind to remap it. As I said this can all be debugged, but then again, why bother?! That's the first part of why I don't want to expose the raw Smalltalk oop. > > #2 is that for time stamping an accurate mask is required and > > forgetting it may cause trouble. Yes, all of this can be debugged > > but why even bother?! There is only one situation where one might > > argue that exposing the internals is actually a good idea - which > > is when you want to return something different than an Integer > > (such as a string). But as I understand it, for the time > > being we won't have a use for anything but a number of > > integers so I'd rather not expose the details too much. > ?? you've lost me. What details are being exposed that you > don't like to expose? What has time stamping masks got to do with it? For one thing see above. For the time stamp - the value returned by #millisecondClockValue is masked to fit into a positive SmallInteger value. Which means if you forget to mask it or (because of overflow of the VM msec representation) return a negative value, you will sometimes compute accurate double click times and sometimes you won't. Again, it can be debugged. And then again, why should there be any need for debugging it?! > > [Re: Latest state] > I almost agree but not quite. I think the proper answer lies in fixing > the bad code as soon as possible. The problem ought not arise and we > shouldn't spend all that much time trying to work around it. I would > prefer that there were no need for any compatability with > InputSensor at all. Yes and no. I agree that such code should be fixed but there are two uses where I can see that the state based representations will be used for some time. One is backward compatibility with MVC - I think there are still enough pieces of code that will be used under both regimes so I think it's important to keep these pieces going until we've got time to fix them. The other possible use is for debug code - e.g., something like "Sensor leftShiftDown ifTrue:[self halt]" is very convenient. And from my point of view Smalltalk is all about convenience. > PPS You gotta admit I proved that event driven need not have > anything to do with interrupt driven. If I ever said anything like that I must have said it while being drunk ;-) It was always clear to me that we will need some support for polling since current OS' generally don't give you event notification at the interrupt level. At least not for the common input events which are always almost handled in the main thread by some polling mechanism itself (call it GetMessage or XNextEvent or whatever). - Andreas

1 0

Re: Launching a DOS executable from Squeak?
by Jon Hylands 30 Jul '00

30 Jul '00

On Sat, 29 Jul 2000 22:44:59 -0500, Jon Hylands <Jon(a)huv.com> wrote: > on a > mouse click, I get some error and a walkback scrolls by at the bottom of > the screen. BTW, the error that I can see as it flashes by usually has something to do with SetDIBits, so I assume its a windows/graphics problem... Later, Jon -------------------------------------------------------------- Jon Hylands Jon(a)huv.com http://www.huv.com/jon Project: Micro Seeker (Micro Autonomous Underwater Vehicle) http://www.huv.com

1 0

RE: Comments on BTF epilogue
by Raab, Andreas 30 Jul '00

30 Jul '00

> d) I don't think you explained the external prim lookup right. It's > named-module first, followed by name-in-builtin-list, then fail. I > think. Andreas? You're right. And so is Dan ;-) The BTF epilogue doesn't distinguish between external and builtin plugins (which I think would be an unnecessary complication) so saying that the VM "looks for the module first and then for the prim and then fails" is basically correct. A more detailed explanation could say "looks for external module + prim first and if not present for internal module + prim and then fails" but as I said this might be more confusing than helpful. - Andreas

1 0

Launching a DOS executable from Squeak?
by Jon Hylands 30 Jul '00

30 Jul '00

Hi everyone, I'm trying to get PIC/Smalltalk to launch my PIC programmer application which is a DOS application. Torsten sent me a solution a while ago: Win32Shell new shellOpen: aFileString But that class doesn't seem to exist... I've looked high & low through the image, and can't find anything to do this kind of thing... Does anyone have any idea of how to do this? Later, Jon -------------------------------------------------------------- Jon Hylands Jon(a)huv.com http://www.huv.com/jon Project: Micro Seeker (Micro Autonomous Underwater Vehicle) http://www.huv.com

1 0

Comments on BTF epilogue
by Dan Ingalls 30 Jul '00

30 Jul '00

Folks - I have written a chapter for The Squeak Book the purpose of which is to bring the topics of the original Back to the Future paper up to date. It's at http://coweb.cc.gatech.edu/squeakbook/32 If you are in a mood to read, I would greatly appreciate any comments and suggestions whether broad philosophy or minor typhos, especially if they come by Monday. Thanks - Dan

2 1

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

Jump to page: