Squeak-dev December 1999

squeak-dev@lists.squeakfoundation.org

146 participants
451 discussions

RE: caching of screen display...
by Raab, Andreas 02 Dec '99

02 Dec '99

> > For example, setting "PasteUpMorph MinCycleLapse: 1000" should reduce > > network traffic pretty far, too.... Yes, but it has currently bad side effects (such as that Morphs won't step for this period of time). > Ok, well I'm still understanding how/where the > primitiveDeferDisplayUpdates method is called. (primitive 126) Look at the senders of Display>>deferUpdates: It's called from PasteUpMorp>>doDeferredUpdating and can be traced back into PasteUpMorph>>displayWorld. That's where the magic happens - notice in particular the #forceToScreen: operations at the end. > I then tried my deferred updates and got 1754 cached screen updates, and 64 > actual screen updates, which is what I expect, the number is probably very > close to 60 but I need to drop a stop watch, halt the program read counter > from debugger, This of course impacts the time reported, but good enough for > now. (320 is not close to 64) The traffic is not only (mainly?!) depending from the number of updates. If you would count the number of *pixels* that are actually drawn you should end up with very much the same number. See above, #forceToScreen: is used to update the display partially so there is no need to make a roundtrip to the server with the full display bitmap (if that's the case it's a bug). A small portion does just fine - in fact one could think about forcing the update immediately after drawing completed which should make drawing and transmission parallel and thus faster. > I did note that deferDisplayUpdates if true doesn't invoke the VMs screen > update, but it also doesn't remember the 'damaged' area. It also doesn't > trap updates via primitive 127 or the fullDisplayUpdate method. It also begs > the question who turns it on, who turns it off, and who refreshes the > damaged area. I assume this rest with the programmer? He turns it on, does > lots of screen manipulation, then turns it off and refreshes the screen? > This is helpful for specific cases but I doubt any programmer will do this > as a general way of programming. Again, see PasteUpMorph>>displayWorld. Display updating is deferred for an entire redraw cycle so there is no need for the average programmer to ever worry about this. You just go on and draw - Morphic does the rest for you. Andreas

1 0

Smalltalk in a Sandbox
by Torsten.Bergmann＠phaidros.com 02 Dec '99

02 Dec '99

There was a discussion on the GSUG-Mailinglist (German Smalltalk User Group) about Smalltalk in a Sandbox. Maybe you are interested on the following paper: http://www.heeg.de/~georg/guendel.htm -Torsten

1 0

RE: Hierarchical Tree View [KINDA LONG...] ;)
by Ali Chamas 02 Dec '99

02 Dec '99

Howdy Stewart, --- Stewart MacLean <stewart.maclean(a)nzhis.govt.nz> wrote: > I hear what you're saying about time! mix in a young > family, a day job, and > a long commute and getting to grips with Morphic > feels like a far off dream > :) Hang in there buddy! This is why i think a built in help tree system for Squeak would be so useful. This way, all of the questions and answers that are bouncing back and forth from this list server could find a really useful, central home. Actually, speaking of new learning curves, i'm kind of working on my own GUI system within Squeak. It's not Morphic, nor MVC, but will be much easier to use than Morphic, and will come with documentation. I'm designing it with an accomanying set of widgets and elements suitable for high grade interface work, both business and other, with other programmers usage in mind. Amoung other projects :), it should be ready soon (it's my first priority, if it performs as good as i hope, i might even do the tree view based in it!). For example, the family of Window class will be able to render as Mac or Windows standard windows (palettes, tabbed, alerts), similar to QKS Smalltalk Agents window bin feature. Good luck! Ali. __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com

1 0

Re: debugging broken in 2.6?
by Paul McDonough 02 Dec '99

02 Dec '99

Um, yeah. I'm not at all surprised to hear that the debugger acts a bit funny around exceptions. Step and send are (I believe) running through simulations of code execution most of the time, rather than sending actual messages via the vm; that means that the debugger has to manage a 'virtual vm' and keep its code path in sync with where the actual vm would have gone. Because exceptions cause code execution to move about the call stack in (to the debugger) unexpected ways, the debugger can get pretty confused in a hurry the moment an exception is handled (although an unhandled exception should leave a more or less normal stack, I think). As for the fear that Halt can get 'eaten' by handlers set up to handle other exceptions ... humm. Halt moved around in the class hierarchy a few times, eventually winding up as an Error subclass. In retrospect, perhaps either a direct Exception subclass, or part of an Interrupt hierarchy which subclasses from Exception (or possibly Notification), would be a better place for it to live. The exception code in the current Squeak release is a framework; filling out the core Exception class hierarchy and integrating its into the base classes, and making the debugger exception-aware, are two tasks that would need done before it would really be properly integrated. None of that work is particularly trivial, unfortunately ... . Paul McDonough, writing far worse than I should, and speaking off-the-cuff and not-at-all-officially rather than for my employer (The Fourth Estate)

1 0

Re: Goodie for Change Set Browser hides automatic updates
by Jason McVay 02 Dec '99

02 Dec '99

in morphic in 2.6 you can start typing in the changeset's name and the list will go to the item... --jason > Yes, both approaches sounds great. It's really annoying having to hunt > through numbered changesets to find the ones that are mine. > > However, I would vote for a third approach than the two mentioned: sort > the changesets by *name*, in reverse order. This gives you an intuitive > ordering, fast lookups if you know the name, and separation of numbered > and non-numbered changesets. It remains easy to figure out which > numbered changesets were added most recently, because after all, > numbered changesets are numbered in order, anyway. Finally, it avoids > adding a menu item to an already large menu. > > > Lex

1 0

RE: Hierarchical Tree View [KINDA LONG...]
by Stewart MacLean 02 Dec '99

02 Dec '99

Hi Ali, Thanks for your informative reply. It sounds like we've approached it in a similar way although I'll have to take a closer look - I did this at the beginning of the year when I was "resting". I hear what you're saying about time! mix in a young family, a day job, and a long commute and getting to grips with Morphic feels like a far off dream :) Cheers, Stewart > -----Original Message----- > From: Ali Chamas [mailto:alichamas@yahoo.com] > Sent: Thursday, December 02, 1999 1:13 PM > To: squeak(a)cs.uiuc.edu > Cc: recipient.list.not.shown; @cs.uiuc.edu > Subject: Re: Hierarchical Tree View [KINDA LONG...] > > > Hi Stewart, > > --- Stewart MacLean <stewart.maclean(a)nzhis.govt.nz> > wrote: > > Hi Ali, > > > > I have found this view very useful in VisualWorks in > > the > > form of the WorkspaceOrganizer. I have ported it to > > VisualAge and was intending to port it to Squeak as > > soon > > as I got up to speed with Morphic. > > > > However there is no point in reinventing the wheel > > so I was > > wondering how your TreeView was comming on and > > whether it was > > close to release? > > Here's a breakdown of my TreeGold project, it's kind > of long, but i hope it might be some help for your > project, or just to know what i'm working on (plus a > GIF screen snap): > > [MODEL] The tree started with a simple <TreeNode> > class whose instances linked together forming a > hierarchical data tree. Each node had a tag, type, and > data attribute which meant you could do deep recursive > searches of individual tags, or node family types. > Each node could also hold any object within it's data > collection (so you could create your structure, and > then "clip" objects to nodes of your tree). > > This data tree was supported by a <TreeParser> class > which could break the tree down into text format > (although now in Smalltalk, it would be binary to > support the objects held in the data attribute), and > then create a new tree from a read source. > > [VIEW] Then came the <TreeView> class which would > compute the view in a virtual canvas (only in a > geometric sense of spacial and graphical association), > which meant that it could be drawn to screen, or > printed. When drawing to screen, an view origin, and > clipping rect were used. > > [CONTROLLER] In the grand MVC tradition, there was > also a <TreeController> to handle interactivity, and > user feedback to the view. > > Some general features were: > * Each node held a "show children" boolean which > related to the TreeView computing the view, and for > shallow node recursive searches. > * The TreeView would hold bitmap association with > particular node tags or types so that a family of > nodes would be drawn with "this" graphic, and another > family would be drawn with "that" graphic, plus "this" > particular node would draw with "that" graphic. > * The tree computes the stems of the tree as well, > which is also configurable graphically. > * The view is spaced dynamically, so that if you were > using large icons for one node type, and small for > another, the view would be spaced neatly (same for the > collapse/expand icons size). > * The tag of the node was drawn next to the node in > the view. > * The view supported row padding so that you create > space between node rows (the stems still reached). > > I myself have been getting up to speed with Morphic, > and plan to do this project using true Morphic > components so that you could bring up a halo on any > visual component. It shouldn't be too long now (...), > there are so many things i want to do with Squeak, so > little hours, especially when your day job is > programming...:\ > > Sorry for the lengthy mail, but your interest was > welcomed! > > I'll post it here as soon as it's ready. > > Cheers, > Ali. > __________________________________________________ > Do You Yahoo!? > Thousands of Stores. Millions of Products. All in one place. > Yahoo! Shopping: http://shopping.yahoo.com >

1 0

Re: caching of screen display...
by John M McIntosh 02 Dec '99

02 Dec '99

>> A week back I asked about the poor performance of X-Windows updates. >> >> I was told lots of bits flow across the wire. >> >> So I looked >> >> On the mac in my test case of doing 100 Display restore I get 55,320 calls >> to ioShowDisplay and of course to the Mac's CopyBits. Nice but expensive. My >> mac does this in 52 seconds, so I'm getting at least 1000 screen updates a >> second. >> >> I changed the code to cache updates which I then trigger each 1/60 of a >> second if required. This reduces the CopyBits calls to 2417. >> >> Now Before I hack the X-Window's implementation I'm wondering if some other >> squeaker has taken this path before? >> >From: lex(a)cc.gatech.edu (Lex Spoon) .... > I think the best solution to remote display is to forget about X-Windows > and write a solution in Squeak! Write a Squeak display server, and > write a Squeak display client that displays things by talking to a > server. That is, use the basic X-Windows model, but don't bother trying > to force your stuff into the specific X-Windows protocol. That > way, you get a cross-platform remote display, and you get to > do it well. > ..... > Lex > (Lex also had some thoughts on a more complicated solution) But I took a simple way out and change the VM to cache screen updates. At my site you can find a change set which you need to file in, then build your own VM. All the changes required lurk in the VM. I've tested it on a Mac, with Linux i686, and with Linux m68k and it seems to compile, and work ok. http://www.smalltalkconsulting.com/papers/tipsAndThoughts/codeFragments.html Could a few people could try it and let me know if there are any problems? Enjoy. I'd be happy to get some performance (feel?) numbers out of people using X across networks since my test case currently has a fast x-server, but a slow x-client, and I can't judge the speedup correctly. PS if you set a 16 millisecond delay then morphic animations flow just fine, setting the delay to zero causes a fallback to the original VM behavior. Setting the delay to 1000 causes some interesting human feedback issues, but certainly reduces network traffic. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== Custom Macintosh programming & various Smalltalk dialects PGP Key: DSS/Diff/46FC3BE6 Fingerprint=B22F 7D67 92B7 5D52 72D7 E94A EE69 2D21 46FC 3BE6 ===========================================================================

1 0

Re: Shouldn't 2 hash = 2.0 hash? [LONG]
by Jan Theodore Galkowski 02 Dec '99

02 Dec '99

On Mon, 29 Nov 1999 16:26:34 David N. Smith (IBM) wrote: >At 17:33 -0600 11/28/99, R. A. Harmon wrote: >>I found the following: >> >> 2 = 2.0 -> true >> 2 hash = 2.0 hash ->false >> >>I think this is a bug. Is it? > >Good question. The blue book says: > >"... Any two objects that are equal must return the same value for >#hash. Unequal values may or may not return equal values for hash. >Typically, this integer is used as an index to locate the object in >an indexed collection..." >[Pg 96]. > [snip] > >I'd argue that having (2.0 = 2) answer false is better than forcing >the hashes to be equal. Besides, comparing floats is a sin one should >not encourage. I'd rather see #= answer false and that some other >method be used for 'has equivalent value'. [snip] I'm not sure this is a better answer than David's, but from a numerical standpoint there is a lot of justification in defining 2.0 = 2.0 --> false or any two flonums. This is because the only way that flonums can be considered "equal" is by specifying a context dependent tolerance, as ((a - b) abs) < tol where tol is some multiple of machine epsilon. I would say, however, that the comparison of an integer to a flonum is an on-the-fence situation, but I'm inclined to insist, like David, that it be false, too. If the integer is converted to a flonum, then it's apparent why this must be so. And to convert the flonum to an integer in this kind of situation is just wrong, unless one is trying to imitate FORTRAN's mixed mode. So, like Dave, I see the hash behavior of really not being pertinent. > > >But you did ask a good question, and I didn't really answer it. >Anyone have a better answer? > [snip] --- ___________________________________________ demiourgos(a)smalltalk.org squeak.org/ home.stny.rr.com/algebraist/ www.smalltalk.org/ jtgalkowski(a)alum.mit.edu Get your FREE, private e-mail account at http://www.salonmember.com.

2 2

Re: Hierarchical Tree View [KINDA LONG...]
by Ali Chamas 02 Dec '99

02 Dec '99

--0-1649760492-944093568=:378 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Stewart, --- Stewart MacLean <stewart.maclean(a)nzhis.govt.nz> wrote: > Hi Ali, > > I have found this view very useful in VisualWorks in > the > form of the WorkspaceOrganizer. I have ported it to > VisualAge and was intending to port it to Squeak as > soon > as I got up to speed with Morphic. > > However there is no point in reinventing the wheel > so I was > wondering how your TreeView was comming on and > whether it was > close to release? Here's a breakdown of my TreeGold project, it's kind of long, but i hope it might be some help for your project, or just to know what i'm working on (plus a GIF screen snap): [MODEL] The tree started with a simple <TreeNode> class whose instances linked together forming a hierarchical data tree. Each node had a tag, type, and data attribute which meant you could do deep recursive searches of individual tags, or node family types. Each node could also hold any object within it's data collection (so you could create your structure, and then "clip" objects to nodes of your tree). This data tree was supported by a <TreeParser> class which could break the tree down into text format (although now in Smalltalk, it would be binary to support the objects held in the data attribute), and then create a new tree from a read source. [VIEW] Then came the <TreeView> class which would compute the view in a virtual canvas (only in a geometric sense of spacial and graphical association), which meant that it could be drawn to screen, or printed. When drawing to screen, an view origin, and clipping rect were used. [CONTROLLER] In the grand MVC tradition, there was also a <TreeController> to handle interactivity, and user feedback to the view. Some general features were: * Each node held a "show children" boolean which related to the TreeView computing the view, and for shallow node recursive searches. * The TreeView would hold bitmap association with particular node tags or types so that a family of nodes would be drawn with "this" graphic, and another family would be drawn with "that" graphic, plus "this" particular node would draw with "that" graphic. * The tree computes the stems of the tree as well, which is also configurable graphically. * The view is spaced dynamically, so that if you were using large icons for one node type, and small for another, the view would be spaced neatly (same for the collapse/expand icons size). * The tag of the node was drawn next to the node in the view. * The view supported row padding so that you create space between node rows (the stems still reached). I myself have been getting up to speed with Morphic, and plan to do this project using true Morphic components so that you could bring up a halo on any visual component. It shouldn't be too long now (...), there are so many things i want to do with Squeak, so little hours, especially when your day job is programming...:\ Sorry for the lengthy mail, but your interest was welcomed! I'll post it here as soon as it's ready. Cheers, Ali. __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com --0-1649760492-944093568=:378 Content-Type: text/plain; name="treeSnap.zip" ; x-mac-type="705A4950" ; x-mac-creator="705A4950" Content-Disposition: attachment; filename="treeSnap.zip" Content-Transfer-Encoding: imap_stub 0,1912,2,82696,0, --0-1649760492-944093568=:378--

1 0

Re: Shouldn't 2 hash = 2.0 hash? [LONG]
by merlyn＠stonehenge.com 02 Dec '99

02 Dec '99

>>>>> "Jan" == Jan Theodore Galkowski <algebraist(a)salonmember.com> writes: Jan> I'm not sure this is a better answer than Jan> David's, but from a numerical standpoint Jan> there is a lot of justification in Jan> defining Jan> 2.0 = 2.0 --> false That'd make stuff like this freak out: aSet _ Set new. aSet add: 2.0. aSet add: 2.0. aSet size ==> 2 :) No, just say no. = should be OK if they really *are* equal. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

1 0

← Newer
1
...
39
40
41
42
43
44
45
46
Older →

Jump to page: