Squeak-dev July 2000

squeak-dev@lists.squeakfoundation.org

121 participants
566 discussions

Re: Small fix (was Re: [ENH][Unix][VM][2.8][2.9alpha?] stream-based translation)
by Rob Withers 28 Jul '00

28 Jul '00

Stephan, Sorry it has taken me so long to post. I've been hacking! Stephan Rudlof wrote: > Rob Withers wrote: > > > > Hi. There was a problem with the automatic overwriting of a file when > > using FileDirectory>>#fileNamed:. It turns out that when you have an > > *existing* file, you will write from the beginning, but it doesn't > > eliminate the other contents. The result is that when you write less > > than the previous contents then close it, the file hasn't been > > truncated. > > What about using #newFileNamed? This puts up a question dialog, asking if you want to overwrite the file. Since there are many files being written, I wanted to ask once, then write all of the files. Rob

2 2

Re: [GOODIE] iScream - Audio Chat
by Lex Spoon 28 Jul '00

28 Jul '00

Bob Arning has the most recent version right now. I'd recommend *against* using any other version, because it will either be slow for large packets or it won't file in because it's missing a bunch of methods (oops). -Lex Mark Guzdial <guzdial(a)cc.gatech.edu> wrote: > > > lab. They've added buddy lists this summer (maintained on a server, > > > >When will the buddy list and the server be available? I'm willing to try > >an early version :-) > > The server and buddy lists are part of the same changeset. > > > > > > though the audio connection is peer-to-peer). Their code (and > > > updating docs) can be found at: http://coweb.cc.gatech.edu/csl/25 > > > >At least the class ObjectSocket is missing. Where do I get it from? > > Bummer! I've sent mail to them for fixing. Meanwhile, ObjectSocket > is part of Lex's MuSwiki which can be found at > http://coweb.cc.gatech.edu/csl/6 . The latest version I can find > I've now uploaded to > http://guzdial.cc.gatech.edu/squeakers/Network-ObjectSocket.st (This > looks like it includes extensions by Dean Mao used in his IWIN > instant messenging system.) Lex, can you confirm that this is the > latest version? > > >Thanks for all the cool ideas you and your students are coming up with! > > Thanks for the nice feedback! :-) > > Mark > > -------------------------- > Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 > Associate Professor - Learning Sciences & Technologies. > Collaborative Software Lab - http://coweb.cc.gatech.edu/csl/ > (404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu > http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html

1 0

Re: Compiler, was Re: Block closures
by Roel Wuyts 28 Jul '00

28 Jul '00

> My plan is to rewrite the #emitFor<X>:on: -family with one (or a few) > Visitor(s). In this way being able to encapsulate information only > belonging there. And at the same time gain the possibility of making > related compilers by inheritance. Probably I'll do the same with > #sizeFor<X>:. It is possible to go further than that but this seems about > right. Yes, that and the printing-stuff. It was for exact that reason that I wrote the simple enumerator I posted a while back. Just being able to walk the parse tree will prove very flexible (especially for the tool builders and language players amongst us :) ). In my (VisualWorks) experience), I did not measure much performance difference between a visitor-style approach and a 'direct' implementation. > The Parser will not inherit from Scanner but will refer to a Scanner. > This adds flexibility which is sometimes good to have. And it is in > accordance with my general view of how to handle syntax. I don't think > it will run slower but I havn't measured it. I don;t think it should. Anyway, from an experimentation standpoint, it would be much better... > If you have comments at this eary stage, welcome. My hope is that it will > make it a bit "simplified and clarified" and more flexible. I am quite sure it will. And about comments: I am willing to participate actively in the development of this (since we directly benefit from this). So, if you need a hand whan yoy start playing around :) PS: you might want to know that this year's ESUG Summer School has invited Eliot Miranda to give a talk (see www.esug.org). Maybe this is of interest of you... -- Roel Wuyts Programming Technology Lab rwuyts(a)vub.ac.be Vrije Universiteit Brussel http://prog.vub.ac.be/~rwuyts Webmaster of European Smalltalk User Group: www.esug.org

1 0

[GOODIE] LindaTalk update: they now support an event model Challenge: make it fast!
by Rob Withers 28 Jul '00

28 Jul '00

Hi all, Attached you will find an updated LindaTalk. Try the Dining Philosopher example that Bolot did once upon a time. Very neat! I removed the naming of tuple fields for performance and complexity reasons, so the Core framework is practically unchanged from 6 months ago. You will find the EventTupleSpace subclass, which allows you to register for callback events if certain operations occur. You can dynamically change the number of Processes which dispatch events by sending #threadPoolSize: aNum to the EventTupleSpace. I would like to issue a challenge to see if we can't get the performance up. It is currently averaging about 70 reads and writes of tuples a second. There are performance tests in the Workspace that pops up when you install. I have a few ideas about using a binary search tree with these tuples, so that each node will have one of the fields from the tuple, and a tuple would describe a path in the tree. Another idea is to have a restricted TupleSpace which would use hashes and IdentityDictionaries to match Tuples. You could label some of the fields as being Symbols so that the comparison is faster. Finally, writting a Plugin may make some sense. How to use regular LindaTalk: For reading and writing: | ts | ts := TupleSpace new. "stores this tuple" ts add: ('Psst' | 'Squeak Rulez!'). "only unlocks synchronous reads and takes" ts transientAdd: ('Psst' | 'Squeak Rulez!'). "read but leave it there - non-blocking" ts detect: ('Psst' | String). "take the tuple - non-blocking" ts remove: ('Psst' | String). ts detect: ('Psst' | String) ifNone: [nil]. ts remove: ('Psst' | String) ifNone: [nil]. "blocking read" ts syncDetect: ('Psst' | String). "blocking take" ts syncRemove: ('Psst' | String). How to register for events. Normally you send #when:send:to:. You can register for normal events the same way, of course. To register for Tuple activity, we need to register for an event with a matching tuple and then an action. So we have #when:match:send:to: logic. The match argument is a tuple. | ts | ts := EventTupleSpace new. "register for events" ts when: #write match: ('Psst' | String) send: #beep to: Smalltalk. "This will beep us" ts add: ('Psst' | 'Squeak Rulez!'). enjoy! Rob -- -------------------------------------------------- Smalltalking by choice. Isn't it nice to have one!

1 0

Re: [UNIX][ALPHA][NET] When to tap the r/w sems?
by Lex Spoon 28 Jul '00

28 Jul '00

It seems reasonable to me to tap when there is a *change* in the read or write flag. In fact, if the image sockets code is modified to drain semaphores instead of just reading one signal at a time, then we could completely stop checking whether we think the image is watching or not, and just signal any events that someone in the image might be interested in. In Unix, this would suggest that dataHandler and friends be given seven arguments: the fd the current read, write, and exceptions flags the previous read, write, and exceptions flags The data handlers can then signal the relevant semaphore whenever read or write goes from 0 to 1. This approach *does* require some slight trickery in order to make the select() wait properly: do one select to wait for stuff to happen, and then do another select() to update all three flags for all open sockets. (Note you can't ask select() to watch for a flag changing from 1 to 0). -Lex Rob Withers <slosher2(a)home.com> wrote: > Below are the code chunks. The only time we are going to be waiting on > the semaphore is if we call one of the 'checking' methods > (SendDone/DataAvailable). I am checking the readFlag in the async > handler, that was installed for data ops, and SETting the flag for > semaphore tap. This means that I'm always tapping, but I thought I was > only to do it during an intent call. Should I remove the SET_.. calls > in the async handler? > > thanks, > Rob > > The SET_... sets a flag that the tapSemaphores(pss) method checks for, > taps is set, then clears the flag. > Here are two chunks of code from the unix network code: > > /* async handler for data operation */ > static void dataHandler(privateSocketStruct *pss, int errFlag, int > readFlag) > { > aioSuspend(pss); > > FPRINTF((stderr, "dataHandler(%d,%d,%d)\n", pss->s, errFlag, > readFlag)); > if (errFlag) > pss->sockState = OtherEndClosed; /* error: almost > certainly "connection closed by peer" */ > if (readFlag) { > SET_TAPREADSEM(pss); > } else { > SET_TAPWRITESEM(pss); > } > tapSemaphores(pss); > } > > > And the two primitives for checking for readAvailable and sendDone: > > /* answer whether the socket has data available for reading */ > int sqSocketReceiveDataAvailable(SocketPtr s) > { > if (!socketValid(s)) return -1; > if (SOCKETSTATE(s) == Connected) { > if (socketReadable(SOCKET(s))) return true; > SET_TAPREADSEM(PSP(s)); > aioHandle(PSP(s), dataHandler, AIO_RW); > } > return false; > } > > /* answer whether the socket has space to receive more data */ > int sqSocketSendDone(SocketPtr s) > { > if (!socketValid(s)) return -1; > if (SOCKETSTATE(s) == Connected) { > if (socketWritable(SOCKET(s))) return true; > SET_TAPWRITESEM(PSP(s)); > aioHandle(PSP(s), dataHandler, AIO_RW); > } > return false; > } > > > -- > -------------------------------------------------- > Smalltalking by choice. Isn't it nice to have one!

2 1

Re: [ENH][Unix][VM][2.8][2.9alpha?] stream-based translation
by Lex Spoon 28 Jul '00

28 Jul '00

Rob Withers <slosher2(a)home.com> wrote: > Stephan Rudlof wrote: > > > > Please take a look onto the supportFile logic, which also could be a > > supportStream logic of course. It is an easy to use mechanism to define > > files, which behave to a plugin; not necessarily platform specific ones. > > There would also arise an error, if a - platform specific or not - file > > is missing, what is needed by a plugin. > > > > An alternative would be to install a similar logic into a VMBuilder > > class hierarchy. Probably this would be better, since it would be more > > transparent and more flexible (say you have a different number of > > platform specific files for different platforms). > > > Keeping the names of dependent modules in the Plugin sounds right to > me. The current locations and storage details should be resolved by the > VMBuilder I think. For now we could have a VMBuilder classVariable > which would hold the current builder and a VMBuildConfiguration > classVariable which would hold a, ..., configuration. This > configuration would provide the location details of the various modules > (local, ftp, cvs, http, Minnestore, ...) and be able to hold a build > environment config (gcc, cc, bcc32.exe, ...) and make utility config > (jam, make, autoconf, ...). Then we could generate all support files > from the builder. This would encapsulate the stream management to the > builder. Does this sound like a good partitioning of logic for the > support files? > > OSProcess would allow us to launch the builds and connect to stdin, > stdout, and stderr. If there is a Window to display the shell then we > can display output and so on. Once we've built a c, c++ development > environment, we can use the configurable parser that someone was posting > to allow for alternate syntaxes. We could create a Python development > environment! Well, I'm not really interested in that. I would rather > build concurrent ObjectMemories in the VM. > It seems really easy to me to just establish a standard directory structure, and then load platform specific files on top of that and type "make". Whatever more sophisticated system everyone comes up with, please try and keep it as easy as the simple scheme! -Lex

2 1

Re: [ENH][Unix][VM][2.8][2.9alpha?] stream-based translation
by Rob Withers 28 Jul '00

28 Jul '00

Stephan, Stephan Rudlof wrote: > > Dear Rob, > > Rob Withers wrote: > > > > Stephan Rudlof wrote: > > > > > > Please take a look onto the supportFile logic, which also could be a > > > supportStream logic of course. It is an easy to use mechanism to define > > > files, which behave to a plugin; not necessarily platform specific ones. > > > There would also arise an error, if a - platform specific or not - file > > > is missing, what is needed by a plugin. > > > > > > An alternative would be to install a similar logic into a VMBuilder > > > class hierarchy. Probably this would be better, since it would be more > > > transparent and more flexible (say you have a different number of > > > platform specific files for different platforms). > > > > Keeping the names of dependent modules in the Plugin sounds right to > > me. > > I agree for platform independent files. > > For platform dependent ones I don't know, probably both ways are similar > good. But think of the possibility of different numbers of files for > different platforms (for one platform it may be very complicated to > implement mouse control with a special driver for it), for the other may > be just one file... And the naming for the standard specific files > needed from each platform has to be unique to switch automatically > between them (and not in the plugin code!). Mmmm.. It sounded like we were going to switch to a standard directory structure, where the platform specific files are kept separate from the plugin files. When this happens then hopefully the special cases will disappear. We probably need an external project file to specify all of the platform and helper files needed for each plugin, especially if there are different numbers of files for different platforms. The VMBuilder can generate files from methods *in the VMBuilder/VMConfiguration* or verify them in the correct dir location. I am going to leave my code as it stands unless there is a directory structure change. > > The current locations and storage details should be resolved by the > > VMBuilder I think. For now we could have a VMBuilder classVariable > > which would hold the current builder and a VMBuildConfiguration > > classVariable which would hold a, ..., configuration. This > > configuration would provide the location details of the various modules > > (local, ftp, cvs, http, Minnestore, ...) and be able to hold a build > > environment config (gcc, cc, bcc32.exe, ...) and make utility config > > (jam, make, autoconf, ...). Then we could generate all support files > > from the builder. This would encapsulate the stream management to the > > builder. Does this sound like a good partitioning of logic for the > > support files? > > Agreed. > > > OSProcess would allow us to launch the builds and connect to stdin, > > stdout, and stderr. If there is a Window to display the shell then we > > can display output and so on. Once we've built a c, c++ development > > environment, we can use the configurable parser that someone was posting > > to allow for alternate syntaxes. We could create a Python development > > environment! Well, I'm not really interested in that. I would rather > > build concurrent ObjectMemories in the VM. > > Sounds difficult... yes, but I'm certain that I am underestimating by a little too! ;) cheers, Rob

1 0

Re: Block closures
by Mats Nygren 28 Jul '00

28 Jul '00

Stephan Rudlof <sr(a)evolgo.de> wrote: > Mats, > > Mats Nygren wrote: > > > > Hi, > > > > I've had a look at the compiler and the VM. > > > > I can do the block closures. > > Very good! It's one of the things at my wish list and I've thought about > to put it onto my toDo list... Why didnt you ;-> > > But don't expect to see anything before the > > middle of October as I have other things that has to be done. I have the > > straighforard way of doing it in mind, > > I'v just read the purple book chapter about interpreter stuff, so for me > it wouldn't be straightforward with my current knowledge... > > > allocating block contexts. > > Do you really mean BlockContexts or rather BlockClosures? I don't understand the question. (Perhaps my reply to Lex is what your thinking about) > > No fancy > > optimizations. > > But blocks shouldn't be much slower than before then. They will use more memory. I'm not into the minute details yet. See reply to Lex. > > The semantics I have in mind is as in ANSI Smalltalk, is that what is > > wanted? > > To be compatible to the standard seems to be reasonable for me. > > > In particular it will be possible to shadow variables in > > enclosing scopes. > > BlockClosures? Dont understand. > > > While at it I will restructure the compiler a little. > > Seems as if you're really experienced in compiler construction... Unfortunately not, but this isn't that big a thing. A working compiler is already there. The handling of variable names need to be changed and the details of how to manage blocks need to be changed a little, that's all. And see my reply to Dwight Hughes. > Greetings, > > Stephan > > > > > /Mats > > -- > Stephan Rudlof (sr(a)evolgo.de) > "Genius doesn't work on an assembly line basis. > You can't simply say, 'Today I will be brilliant.'" > -- Kirk, "The Ultimate Computer", stardate 4731.3

2 1

Re: Block closures
by Stephan Rudlof 27 Jul '00

27 Jul '00

Mats Nygren wrote: <snipped> > My general attitude is that if there are three (or more) different > solutions, make it easy to change, at best while the system is running > but that's beyond my present ambitions. I will be satisfied at first > with one of them probably a single parent pointer or as you said > (did you?) two pointers, home and (enclosing) parent. BlockClosures! > When we > are that far probably people will help with benchmarking and > thinking about the details. > > /Mats Stephan

1 0

Re: Block closures
by Tim Rowledge 27 Jul '00

27 Jul '00

Mats, if you're serious about this, do yourself a big favour and talk to Eliot Miranda about his recent (as in a year or so ago) improvements to block handling in VW; he's explained it to me but I couldn't for the life of me explain it to you and get it right. Basically I think it ... oh hell, get him to explain it. And don't forget to talk with Ian Piumarta to make sure he isn't duplicating the work (he said at ECOOP he'd tackle it soon) and that you don't do anything that will break the jitter. Craig Latta did some pretty serious planning with Ian some time ago on this subject so he might some useful input for you as well. And don't forget the VM changes you'll need. And don't forget to work out howto get there from here; the bit that has always put me off trying anything. I'd suggest using the SystemTracer to clone a new image with BlockClosures rather than trying to manage with both styles. At least with Squeak you can simulate the new system and have a decent debugger. tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim To err is human; to forgive, beyond the scope of the Operating System.

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
57
Older →

Jump to page: