Squeak-dev July 2000

squeak-dev@lists.squeakfoundation.org

121 participants
566 discussions

Re: Block closures
by Stephan Rudlof 01 Aug '00

01 Aug '00

Dear Squeakers, Meta: I have some understanding and some practical problems. I haven't worked for years at ParcPlace/Disney/Cincom and I haven't written an ST interpreter. Possibly some of these things would be a good foundation to go deeper here... ;-) I don't think, I'm stupid in principle, but sometimes I get this feeling *here*... Possibly I shouldn't go too deep into this stuff, because it is quiet special and needs deep insights to become productive here; but currently I'm interested in it and motivated to go a little deeper... And I think some of mine problems are resulting from a lack of existing or found documentation. BTW: It is natural, that in this special area there isn't so much doc as in more common areas: Not everybody is interested in looking into the mechanisms of compiling and VMs; and more less in improving this stuff... Concrete: Squeaks ST80 implementation of BlockContexts without any BlockClosures is far away from Eliot's paper. I think I need an understanding of BlockClosures first and have just searched for papers about BlockClosures, without success. With platform dependent I've meaned the 'hybrid context' together with 'native frame' stuff, introduced to support just in time compilers. To use this we need a Jitter. Am I correct here? I'm thinking (not working! (would be interesting, though)) about a less ambitious solution with the current 'normal' VM. I have a non commercial VW: sr@Klaus:~ > vw5i -version Copyright © 1999 Cincom Systems, Inc. All Rights Reserved. Release identification ... OE version: 51 platform: 168 release: 51.4 flags: 0 VI version: 0 minor: 0 release: 0 variant: 0 From version: 0 platform: 0 release: 0.1 flags: 0 ; there is some documentation, but to get an understanding of 'classical' BlockClosures some kind of paper related to an earlier version of VW without so much optimizations would be better. Moreover I don't fully understand the VW-VM definition: E.g. when which temporary variables are pushed why onto the stack before calling a BC and how they are pop'ed thereafter. In short: the logic of compiling by the Compiler and interpreting the compiled result by the VM; especially in regard to BCs. Just looking with an inspector onto CompiledMethods and CompiledBlocks and jumping around from method to method isn't sufficient to get deeper insights. Vassili Bykov wrote: > > Stephan, > > The only thing I can add to what Tim already said is you can read "Lisp in > Small Pieces" or SICP. Thanks for the hint; is this somewhere in the net? Greetings, Stephan > They explain in detail some things Eliot's paper > assumes the reader knows. (Though I still can't see how it is not "platform > independent"--unless you want a Smalltalk VM on a Turing machine or > something). > > --Vassili > > -- > Vassili Bykov > VisualWorks development > vassili(a)parcplace.com > > > -----Original Message----- > > From: Stephan Rudlof [mailto:sr@evolgo.de] > > Sent: Saturday, July 29, 2000 8:43 AM > > To: squeak(a)cs.uiuc.edu > > Subject: Re: Block closures > > > > > > Vassili Bykov wrote: > > > > > > Eliot's OOPSLA paper describes that improvement, as well as > > gives a good > > > intro to closure implementation in VW in general: > > > > > > http://www.squeak.org/oopsla99_vmworkshop/oopsla99-contexts.pdf > > > > I have to put some water into the wine here... ;-( > > > > The paper is interesting and stands in the tradition of and > > is related to > > earlier VW implementations, which have extended the ST80 > > specification. > > It addresses the realization of very fast block closures, so > > far so good. > > > > But to reach this goal, native stack layout is used and > > different kind of > > mappings of ST contexts to native stack frames. I think this > > fits good into > > JIT-Compiler work, but > > > > *** this isn't a platform independent approach ***. > > > > Moreover I don't see a realization just by changing the > > interpreter and ST > > contexts, methods and related things. > > > > To reach platform independence, we should use a slower, but compatible > > realization of block closures. More sophisticated techniques should be > > applied after a working common variant. > > > > BTW: Are there any papers describing BlockClosures without > > referring to > > native stack layout? > > > > > > Greetings, > > > > Stephan > > > > > > > -- > > > Vassili Bykov > > > VisualWorks development > > > vassili(a)parcplace.com > > > > > > > -----Original Message----- > > > > From: Tim Rowledge [mailto:tim@sumeru.stanford.edu] > > > > Sent: Thursday, July 27, 2000 2:29 PM > > > > To: squeak(a)cs.uiuc.edu > > > > Subject: Re: Block closures > > > > > > > > > > > > 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. > > > > > -- > 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 -- 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

1 0

[ENH] Delete key under Windows
by Thomas Kuehne 31 Jul '00

31 Jul '00

Hi, the (unshifted) delete key (usually labelled 'Del') does not seem to have a function assigned to it (I am using version 2.7 under Windows). I did not like pressing shift + the delete key each time I wanted to delete a character right to the cursor. Adding the delete key to the command key map solved the problem for me. For those interested, please perform ParagraphEditor initializeCmdKeyShortcuts after you filed in the attachment. P.S.: I also made the system browser show all methods after a class has been selected, i.e., selecting message category '-- all --' as a default. One simply has to replace all occurrences of assigning 0 to messageCategoryListIndex with assigning 1 to the same variable. Cheers, Thomas -- Dr. Thomas Kuehne +49 631 205 4654, http://www-agce.informatik.uni-kl.de/~kuehne The difficulty in doing research is to find the right questions so that all the answers come easily. -- TK 'From Squeak2.7 of 5 January 2000 [latest update: #1782] on 30 July 2000 at 12:45:45 pm'! !ParagraphEditor class methodsFor: 'keyboard shortcut tables' stamp: 'TK 7/30/2000 12:43'! initializeCmdKeyShortcuts "Initialize the (unshifted) command-key shortcut table." "NOTE: if you don't know what your keyboard generates, use Sensor kbdTest " "ParagraphEditor initialize" | cmdMap cmds | cmdMap _ Array new: 256. "use temp in case of a crash" cmdMap atAllPut: #noop:. cmdMap at: 1 + 1 put: #cursorHome:. "home key" cmdMap at: 4 + 1 put: #cursorEnd:. "end key" cmdMap at: 8 + 1 put: #backspace:. "ctrl-H or delete key" cmdMap at: 11 + 1 put: #cursorPageUp:. "page up key" cmdMap at: 12 + 1 put: #cursorPageDown:. "page down key" cmdMap at: 13 + 1 put: #crWithIndent:. "cmd-Return" cmdMap at: 27 + 1 put: #selectCurrentTypeIn:. "escape key" cmdMap at: 28 + 1 put: #cursorLeft:. "left arrow key" cmdMap at: 29 + 1 put: #cursorRight:. "right arrow key" cmdMap at: 30 + 1 put: #cursorUp:. "up arrow key" cmdMap at: 31 + 1 put: #cursorDown:. "down arrow key" cmdMap at: 127 + 1 put: #forwardDelete:. "del key" '0123456789-=' do: [:char | cmdMap at: char asciiValue + 1 put: #changeEmphasis:]. '([{''"<' do: [:char | cmdMap at: char asciiValue + 1 put: #enclose:]. cmdMap at: $, asciiValue + 1 put: #shiftEnclose:. cmds _ #($a selectAll: $b browseIt: $c copySelection: $d doIt: $e exchange: $f find: $g findAgain: $h setSearchString: $i inspectIt: $j doAgainOnce: $k offerFontMenu: $l cancel: $m implementorsOfIt: $n sendersOfIt: $o spawnIt: $p printIt: $q querySymbol: $r recognizer: $s save: $t tempCommand: $u align: $v paste: $w backWord: $x cut: $y swapChars: $z undo: ). 1 to: cmds size by: 2 do: [:i | cmdMap at: (cmds at: i) asciiValue + 1 put: (cmds at: i + 1)]. CmdActions _ cmdMap! !

3 3

Re: final(?) version of Object Engine Tour chapter online
by Bijan Parsia 31 Jul '00

31 Jul '00

On Sun, 30 Jul 2000, Tim Rowledge wrote: [snip] > for anyone that would like to try to make sense of it. If you find major > problem, please don't tell me.... I don't have any energy left for a > major rewrite! Er...but *Tim*! Weren't you supposed to be doing the networking bit? noCheers, Bijan "There's no 'cheers' when there's a deadline" Parsia. P.S., I did glance at the penultimate version and it seemed quite intellegible to me. Take that data as you will...

2 1

Re: [FIX] Mac VM doesn't find Plugins folder
by Tim Rowledge 31 Jul '00

31 Jul '00

In message <B5A9FF8A.4363%Henrik.Gedenryd(a)lucs.lu.se> you wrote: > By chance I found a bug that prevents the Mac VM from loading plugins from a > Plugins folder--a colon was appended to the path before 'Plugins', but the > path already ends with one. Ergo two colons were there. Ouch! > > Believe it or not, the function ioLoadModule is defined in sqMacWindow.c: That's no so awful really, the sq{plat}Window.c file has become a repository for most of the platform dependent stuff. It has the virtue of simplicity, though I'll happily agree that it would be possible to factor things a bit more cleanly. The real problem is that the more files there are, the easier it is for someone to 'lose' one either really or just mentally. -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim An elephant is a mouse with an operating system.

1 0

[bug][fix] small celeste bug fixes
by mdr＠scn.org 31 Jul '00

31 Jul '00

This fixes three bugs in Celeste. (1) Restores help text to the category menu (which was overwritten by a recent change set) (2) Custom F. Move button no longer fails to the debugger when (always the initial case) no filters are defined (3) It is now possible to alter an incorrectly typed POP3 password without using the inspector I have tested this with my mail and am satisfied with it. I would suggest including it in the soon-to-be-released 2.8 since the second bug will catch most new users of Celeste. (NB: Each of the changes are localized to one method.) Mike Content-Type: application/octet-stream; name="CelesteFixes.2.cs" Content-Disposition: attachment; filename="CelesteFixes.2.cs" Content-Transfer-Encoding: base64 J0Zyb20gU3F1ZWFrMi44IG9mIDMxIEp1bHkgMjAwMCBbbGF0ZXN0IHVwZGF0ZTogIzIzNDhd IG9uIDMxIEp1bHkgMjAwMCBhdCA3OjE2OjM2IHBtJyENIkNoYW5nZSBTZXQ6CQlDZWxlc3Rl Rml4ZXMNRGF0ZToJCQkzMSBKdWx5IDIwMDANQXV0aG9yOgkJCU1pa2UgUnV0ZW5iZXJnICht ZHJAc2NuLm9yZykNDUZpeGVzIHRocmVlIGJ1Z3MvcHJvYmxlbXMgaW4gQ2VsZXN0ZS4gIEVh Y2ggbWFrZSBpdCBlYXNpZXIgZm9yIG5vbi1leHBlcnRzIHRvIHVzZSBDZWxlc3RlLg0NKDEp IFJlc3RvcmVzIGhlbHAgdGV4dCB0byB0aGUgY2F0ZWdvcnkgbWVudSAoaGVscCB3YXMgb3Zl cndyaXR0ZW4gYnkgYSByZWNlbnQgY2hhbmdlIHNldCkNKDIpIEN1c3RvbSBGLiBNb3ZlIGJ1 dHRvbiBubyBsb25nZXIgZmFpbHMgdG8gZGVidWdnZXIgd2hlbiAoYWx3YXlzIHRoZSBpbml0 aWFsIGNhc2UpIG5vIGZpbHRlcnMgYXJlIGRlZmluZWQNKDMpIENsZWFyIHRoZSBwYXNzd29y ZCB3aGVuIHRoZSBQT1AgdXNlcm5hbWUgaXMgY2hhbmdlZCAocHJvdmlkaW5nIGEgbWV0aG9k IHRvIGNvcnJlY3QgYW4gaW5jb3JyZWN0IHBhc3N3b3JkKQ0iIQ0NDSFDZWxlc3RlIG1ldGhv ZHNGb3I6ICdjYXRlZ29yaWVzIHBhbmUnIHN0YW1wOiAnbWRyIDcvMzEvMjAwMCAxOToxNCch DWNhdGVnb3J5TWVudTogYU1lbnUNCSJBbnN3ZXIgdGhlIG1lbnUgZm9yIHRoZSBjYXRlZ29y aWVzIHBhbmUuIg0NCXwgdmlld2luZ1JlYWxDYXRlZ29yeSB8DQl2aWV3aW5nUmVhbENhdGVn b3J5IF8gKChjdXJyZW50Q2F0ZWdvcnkgbm90TmlsKSBhbmQ6DQkJCQkJCQlbKGN1cnJlbnRD YXRlZ29yeSB+PSAnLmFsbC4nKSAmIChjdXJyZW50Q2F0ZWdvcnkgfj0gJy51bmNsYXNzaWZp ZWQuJyldKS4NDQlhTWVudSBhZGQ6ICdzYXZlJyAgYWN0aW9uOiAjc2F2ZS4NCWFNZW51IGJh bGxvb25UZXh0Rm9yTGFzdEl0ZW06ICdTYXZlIHRoZSBkYXRhYmFzZScuDQlhTWVudSBhZGRM aW5lLg0NCWFNZW51IGFkZDogJ2ZldGNoIG1haWwnICBhY3Rpb246ICNmZXRjaE1haWwuDQlh TWVudSBiYWxsb29uVGV4dEZvckxhc3RJdGVtOiAnRmV0Y2ggbmV3IG1haWwgZnJvbSB0aGUg c2VydmVyJy4NCWFNZW51IGFkZDogJ3NlbmQgcXVldWVkIG1haWwnICBhY3Rpb246ICNzZW5k UXVldWVkTWFpbC4NCWFNZW51IGJhbGxvb25UZXh0Rm9yTGFzdEl0ZW06ICdTZW5kIG5ld2x5 IHdyaXR0ZW4gbWFpbCcuDQlhTWVudSBhZGRMaW5lLg0NCWN1cnJlbnRDYXRlZ29yeSBub3RO aWwgaWZUcnVlOiBbDQkJCWFNZW51IGFkZDogJ3ZpZXcgYWxsIG1lc3NhZ2VzJyAgYWN0aW9u OiAjdmlld0FsbE1lc3NhZ2VzLg0JCQlhTWVudSBiYWxsb29uVGV4dEZvckxhc3RJdGVtOiAn VmlldyBhbGwgbWVzc2FnZXMgaW4gdGhpcyBjYXRlZ29yeScuDQkJCWFNZW51IGFkZExpbmUu DQkJCV0uDQ0Jdmlld2luZ1JlYWxDYXRlZ29yeSBpZlRydWU6IFsNCQkJYU1lbnUgYWRkOiAn ZWRpdCBjYXRlZ29yeSBmaWx0ZXInICBhY3Rpb246ICNlZGl0Q2F0ZWdvcnlGaWx0ZXIuDQkJ CWFNZW51IGJhbGxvb25UZXh0Rm9yTGFzdEl0ZW06ICdEZWZpbmUgYSBmaWx0ZXIgdG8gc3Vw cG9ydCBzZW1pLWF1dG9tYXRpY2FsbHkgbW92aW5nIG1lc3NhZ2VzIHRvIHRoaXMgY2F0ZWdv cnknLg0JCQlhTWVudSBhZGRMaW5lLg0JCQldLg0NCWFNZW51IGFkZDogJ2FkZCBjYXRlZ29y eScgIGFjdGlvbjogI2FkZENhdGVnb3J5Lg0JYU1lbnUgYmFsbG9vblRleHRGb3JMYXN0SXRl bTogJ0FkZCBhIG5ldyBvcmdhbml6YXRpb25hbCBjYXRlZ29yeScuDQl2aWV3aW5nUmVhbENh dGVnb3J5IGlmVHJ1ZTogWw0JCQlhTWVudSBhZGQ6ICdyZW5hbWUgY2F0ZWdvcnknICBhY3Rp b246ICNyZW5hbWVDYXRlZ29yeS4NCQkJYU1lbnUgYmFsbG9vblRleHRGb3JMYXN0SXRlbTog J1JlbmFtZSB0aGlzIG9yZ2FuaXphdGlvbmFsIGNhdGVnb3J5Jy4NCQkJYU1lbnUgYWRkOiAn cmVtb3ZlIGNhdGVnb3J5JyAgYWN0aW9uOiAjcmVtb3ZlQ2F0ZWdvcnkuDQkJCWFNZW51IGJh bGxvb25UZXh0Rm9yTGFzdEl0ZW06ICdSZW1vdmUgdGhpcyBvcmdhbml6YXRpb25hbCBjYXRl Z29yeQ0oTkI6IGFsbCBtZXNzYWdlcyB3aWxsIGJlIHNhZmVseSBhdmFpbGFibGUgaW4gb3Ro ZXIgY2F0ZWdvcmllcyknLg0JCQldLg0JYU1lbnUgYWRkTGluZS4NDQl2aWV3aW5nUmVhbENh dGVnb3J5IGlmVHJ1ZTogWw0JCQlhTWVudSBhZGQ6ICdpbXBvcnQgaW50byBjYXRlZ29yeScg IGFjdGlvbjogI2ltcG9ydEludG9DYXRlZ29yeS4NCQkJYU1lbnUgYmFsbG9vblRleHRGb3JM YXN0SXRlbTogJ0ltcG9ydCBtZXNzYWdlcyBmcm9tIGEgVW5peC9FdWRvcmEgZmlsZSBpbnRv IHRoaXMgY2F0ZWdvcnknLg0JCQldLg0JYU1lbnUgYWRkOiAnZXhwb3J0IGNhdGVnb3J5IChD ZWxlc3RlKScgIGFjdGlvbjogI2V4cG9ydENhdGVnb3J5Lg0JYU1lbnUgYmFsbG9vblRleHRG b3JMYXN0SXRlbTogJ0NvcHkgYWxsIG1lc3NhZ2VzIGZyb20gdGhpcyBjYXRlZ29yeSB0byBh bm90aGVyIGV4aXN0aW5nIENlbGVzdGUgZGF0YWJhc2UnLg0JYU1lbnUgYWRkOiAnZXhwb3J0 IGNhdGVnb3J5IChVbml4L0V1ZG9yYSknICBhY3Rpb246ICNleHBvcnRDYXRlZ29yeVVuaXgu DQlhTWVudSBiYWxsb29uVGV4dEZvckxhc3RJdGVtOiAnV3JpdGUgYSBjb3B5IG9mIGFsbCBt ZXNzYWdlcyBmcm9tIHRoaXMgY2F0ZWdvcnkgdG8gYSBVbml4L0V1ZG9yYSBmb3JtYXQgZmls ZScuDQlhTWVudSBhZGRMaW5lLg0NCWFNZW51IGFkZDogJ2VtcHR5IHRyYXNoJyAgYWN0aW9u OiAjZW1wdHlUcmFzaC4NCWFNZW51IGJhbGxvb25UZXh0Rm9yTGFzdEl0ZW06ICdDb21wbGV0 ZWx5IHJlbW92ZSBhbGwgbWVzc2FnZXMgaW4gdGhlIGNhdGVnb3J5IC50cmFzaC4gZnJvbSBD ZWxlc3RlJy4NCWFNZW51IGFkZDogJ3NhbHZhZ2UgJiBjb21wYWN0JyAgYWN0aW9uOiAjY29t cGFjdC4NCWFNZW51IGJhbGxvb25UZXh0Rm9yTGFzdEl0ZW06ICdTYWx2YWdlIGFueSB3b3Jr IGRvbmUgc2luY2UgdGhlIGxhc3QgZGF0YWJhc2Ugc2F2ZSAmIHJlY292ZXIgc3BhY2UgdXNl ZCBieSBvbGQgZGVsZXRlZCBtZXNzYWdlcy4NKFRoaXMgbWF5IGJlIGEgcXVpdGUgc2xvdykn Lg0JYU1lbnUgYWRkOiAnZmluZCBkdXBsaWNhdGVzJyAgYWN0aW9uOiAjZmluZER1cGxpY2F0 ZXMuDQlhTWVudSBiYWxsb29uVGV4dEZvckxhc3RJdGVtOiAnRmluZCBtZXNzYWdlcyB3aGlj aCBhcmUgZXhhY3QgZHVwbGljYXRlcycuDQlhTWVudSBhZGRMaW5lLg0NCWFNZW51IGFkZDog J3RvZ2dsZSBoZWFkZXJzJyAgYWN0aW9uOiAjdG9nZ2xlU3VwcHJlc3NIZWFkZXJzLg0JYU1l bnUgYmFsbG9vblRleHRGb3JMYXN0SXRlbTogJ1Nob3cgZWl0aGVyIHRoZSBjb21wbGV0ZSB1 bnRvdWNoZWQgbWVzc2FnZSBvciBhbiBlYXN5LXRvLXJlYWQgbWVzc2FnZScuDQlhTWVudSBh ZGRMaW5lLg0NCWFNZW51IGFkZDogJ3NldCB1c2VyIG5hbWUnICBhY3Rpb246ICNzZXRVc2Vy TmFtZS4NCWFNZW51IGJhbGxvb25UZXh0Rm9yTGFzdEl0ZW06ICdTcGVjaWZ5IHRoZSAnJ0Zy b206JycgdXNlciBuYW1lIGZvciBuZXcgbWVzc2FnZXMnLg0JYU1lbnUgYWRkOiAnc2V0IGNj OiBsaXN0JyAgYWN0aW9uOiAjc2V0Q0NMaXN0Lg0JYU1lbnUgYmFsbG9vblRleHRGb3JMYXN0 SXRlbTogJ1NwZWNpZnkgYSBjYzogbGlzdCB0aGF0IGlzIGFkZGVkIHRvIGVhY2ggbmV3IG1l c3NhZ2UnLg0JYU1lbnUgYWRkOiAnc2V0IFBPUCBzZXJ2ZXInICBhY3Rpb246ICNzZXRQb3BT ZXJ2ZXIuDQlhTWVudSBiYWxsb29uVGV4dEZvckxhc3RJdGVtOiAnU3BlY2lmeSB3aGljaCAo UE9QMykgc2VydmVyIHRvIGNoZWNrIGZvciBuZXcgbWVzc2FnZXMnLg0JYU1lbnUgYWRkOiAn c2V0IFBPUCB1c2VybmFtZScgIGFjdGlvbjogI3NldFBvcFVzZXJOYW1lLg0JYU1lbnUgYmFs bG9vblRleHRGb3JMYXN0SXRlbTogJ1NwZWNpZnkgdGhlIHVzZXJuYW1lIHRvIHVzZSB3aGVu IGNoZWNraW5nIGZvciBuZXcgbWVzc2FnZXMnLg0JYU1lbnUgYWRkOiAnc2V0IFNNVFAgc2Vy dmVyJyAgYWN0aW9uOiAjc2V0U210cFNlcnZlci4NCWFNZW51IGJhbGxvb25UZXh0Rm9yTGFz dEl0ZW06ICdTcGVjaWZ5IHdoaWNoIChTTVRQKSBzZXJ2ZXIgdG8gdXNlIHdoZW4gc2VuZGlu ZyBtZXNzYWdlcycuDQlhTWVudSBhZGRMaW5lLg0NCSJhZGQgdG9nZ2xlIGZvciB3aGV0aGVy IHRvIGRlbGV0ZSBtZXNzYWdlcyBvbiBkb3dubG9hZCINCURlbGV0ZUluYm94QWZ0ZXJGZXRj aGluZw0JCWlmVHJ1ZTogWw0JCQlhTWVudSBhZGQ6ICdsZWF2ZSBtZXNzYWdlcyBvbiBzZXJ2 ZXInICBhY3Rpb246ICNrZWVwTWVzc2FnZXNPblNlcnZlci4NCQkJYU1lbnUgYmFsbG9vblRl eHRGb3JMYXN0SXRlbTogJ0RvbicndCBkZWxldGUgbWVzc2FnZXMgZnJvbSB0aGUgc2VydmVy IHdoZW4geW91IHJldHJlaXZlIHRoZW0gKHR5cGljYWxseSB1c2VkIGZvciB0ZXN0aW5nIG9u bHkpJy4NCQkJXQ0JCWlmRmFsc2U6IFsNCQkJYU1lbnUgYWRkOiAnZG9uJyd0IGxlYXZlIG1l c3NhZ2VzIG9uIHNlcnZlcicgIGFjdGlvbjogI2RlbGV0ZU1lc3NhZ2VzQWZ0ZXJGZXRjaGlu Zy4NCQkJYU1lbnUgYmFsbG9vblRleHRGb3JMYXN0SXRlbTogJ0F1dG9tYXRpY2FsbHkgcmVt b3ZlIG1lc3NhZ2VzIGZyb20gdGhlIHNlcnZlciBhZnRlciB5b3UgcmV0cmVpdmUgdGhlbScu DQkJCV0uDQ0JXiBhTWVudQ0hICENDSFDZWxlc3RlIG1ldGhvZHNGb3I6ICdjYXRlZ29yaWVz IHBhbmUnIHN0YW1wOiAnbWRyIDcvMzEvMjAwMCAxOTowMychDXNldFBvcFVzZXJOYW1lDQl1 c2VyUGFzc3dvcmQgXyBuaWwuICAgIkNsZWFyIHRoZSBwYXNzd29yZCB3aGVuIGEgbmV3IHVz ZXJuYW1lIGlzIHNldCINCV5zZWxmIGNsYXNzIHNldFBvcFVzZXJOYW1lISAhDQ0hQ2VsZXN0 ZSBtZXRob2RzRm9yOiAnZmlsdGVyaW5nJyBzdGFtcDogJ21kciA3LzMxLzIwMDAgMTA6NTQn IQ1jdXN0b21GaWx0ZXJNb3ZlDQkiU2VsZWN0IG9yIGRlZmluZSBhbmQgYWN0aXZhdGUgYSBj dXN0b20gZmlsdGVyLiINCXwgZmlsdGVyTGlzdCBmaWx0ZXJOYW1lIGZpbHRlckV4cHIgbXNn TGlzdCB8DQlmaWx0ZXJMaXN0IF8gQ3VzdG9tRmlsdGVycyBrZXlzIGFzU29ydGVkQ29sbGVj dGlvbiBhc09yZGVyZWRDb2xsZWN0aW9uIHNlbGVjdDogWzplIHwgc2VsZiBjYXRlZ29yeUxp c3QgaW5jbHVkZXM6IGVdLg0JZmlsdGVyTGlzdCBzaXplID0gMCBpZlRydWU6IFtec2VsZl0u ICAgICJTdG9wIHF1aWV0bHkgaWYgdGhlcmUgYXJlIG5vIGZpbHRlcnMuLi4iDQ0JZmlsdGVy TmFtZSBfIChDdXN0b21NZW51IHNlbGVjdGlvbnM6IGZpbHRlckxpc3QpDQkJCQlzdGFydFVw V2l0aENhcHRpb246ICdTZWxlY3QgYSBtb3ZlIGZpbHRlcjonLg0JZmlsdGVyTmFtZSBpZk5p bDogW14gc2VsZl0uDQlmaWx0ZXJFeHByIF8gQ3VzdG9tRmlsdGVycyBhdDogZmlsdGVyTmFt ZS4NCWZpbHRlckV4cHIgaXNFbXB0eSBpZlRydWU6IFteIHNlbGZdLg0JY3VzdG9tRmlsdGVy QmxvY2sgXyBDb21waWxlciBldmFsdWF0ZTogJ1sgOm0gfCAnICwgZmlsdGVyRXhwciAsICdd Jy4NCW1zZ0xpc3QgXyBzZWxmIGZpbHRlcmVkTWVzc2FnZXNJbjogY3VycmVudENhdGVnb3J5 Lg0JbWFpbERCIHJlbW92ZUFsbDogbXNnTGlzdCBmcm9tQ2F0ZWdvcnk6IGN1cnJlbnRDYXRl Z29yeS4NCW1haWxEQiBmaWxlQWxsOiBtc2dMaXN0IGluQ2F0ZWdvcnk6IGZpbHRlck5hbWUu DQljdXN0b21GaWx0ZXJCbG9jayBfIG5pbC4NCXNlbGYgdXBkYXRlVE9DISAhDQ0=

1 0

Re: [Questions]Events
by Lex Spoon 31 Jul '00

31 Jul '00

Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > > Is this work still useful? > I think so - I'd love to see a simpler mechanism than the two ugly > special cases currently in use. If you can think of a way to unify them, > go for it. > I think a pretty good proposal has gone around the list. Graned, this is one big list. Have the following methods in the core Unix VM: registerPollFunction(function) unregisterPol/Function(function) watchFD(fd, flags, handler) stopWatchingFD(fd) Then, the core Unix ioWait call (whatever its name is) should call all the polling functions followed by select-ing on the registered FD's. For any fd's where something interesting happens, call the relevant handler. -Lex

1 0

Re: [ENH] Alternative EventSensor
by Lex Spoon 31 Jul '00

31 Jul '00

"Raab, Andreas" <Andreas.Raab(a)disney.com> wrote: > 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. > Alternatively, this could be solved the same way it is for sockets. On platforms where it can't be done asynchronously, do it from HandleEvents(). Image code will have the impression that the events are asynchronous, it's just that they will be delayed by a few milliseconds. -Lex

1 0

Re: [ENH] Alternative EventSensor
by Lex Spoon 31 Jul '00

31 Jul '00

Ned Konz <ned(a)bike-nomad.com> wrote: > [1] That is: the big key above the Return key (which on my (but not every) > keyboard > is labeled "Delete")) emits an 8, and the Del key emits a 127. > Amen. On my computer, and most of the ones I've seen, that key is labelled "Backspace". Perhaps sun keyboards do it differently? -Lex

1 0

Re: AF_UNIX sockets?
by Lex Spoon 31 Jul '00

31 Jul '00

The SocketPlugin is for platform independent sockets. IMHO, Unixisms should go in a separate addon. -Lex Ned Konz <ned(a)bike-nomad.com> wrote: > Is there no support in Socket for AF_UNIX (Unix domain, a/k/a FIFO) sockets? > It seems that there is an assumption that sockets are always AF_INET. > I see constructors for UDP and TCP sockets, but none for Unix domain ones. > > I realize that existing stream protocols should work with these, but it > would be nice to have a unified interface (perhaps if host is nil, port > could be the name of the socket?). > > What brings this up is that I'm looking at the MySQL stuff in Comanche, > and felt that the Unix domain socket connection might be faster than the > existing TCP socket connection. > > -- > Ned Konz > currently: Stanwood, WA > email: ned(a)bike-nomad.com > homepage: http://bike-nomad.com

1 0

Re: Window Frames for system windows
by Lex Spoon 31 Jul '00

31 Jul '00

Henrik Gedenryd <Henrik.Gedenryd(a)lucs.lu.se> wrote: > Lex Spoon wrote: > > > Man, after all this talk I'm really wishing I had such a UI available > > right now, even though I've got a plain ~100dpi monitor! I think I > > could live with 50% larger font sizes in return for such a convenient > > and scalable UI framework. > > I think the reason why no one is doing this yet is that you need to get up > to resolutions above 300 dpi or so before it won't look really ugly, today's > pixels are far too discernible one by one. As an example, imagine what an > every-other-pixel pattern at 72dpi will look like at 96 dpi. This is not the > way you would specify things, of course, but the same effects would occurr > often, where some distances yielding 1 pixel spaces at 72 would yield 2 at > 96, etc., and that would look really bad. Going from 300 to 400 would not > yield the same problem (4 vs. 5 pixels in the two cases). > I'm not sure where you'd have these pixel patterns. Most video cards can handle 16-bit color at least, and so it's not needed for dithering. And anti-aliasing usually only effects neighboring pixels, not large swaths. To get an idea what such a system would be like on *your* monitor ("you" being anyone on the list), just look at a PDF file with anti-aliasing turned on. I find that things look fuzzy, but they are quite usable if you increase the font size by 50%. > I just realized that the dominating dpi size hasn't changed significantly > since the bitmapped displays were invented. But it'll have to once > everything is 32 bit color, or how else would you improve your product? > Maybe you're right. Still, I wonder if it's more a problem that there's no market as long as GUI's aren't resolution-scalable. It looks like a catch 22: nobody wants high-res video cards and monitors because they are useless for most GUI's. And yet, if the high-res video cards and monitors were available, the GUI's would surely improve within a few years (perhaps Microsoft would catch on in five or ten :)). Interestingly, video cards for polygon-based games are out of this loop, because such games use scalable graphics already.... -Lex

1 0

Jump to page: