Menu
▾
▴
squeak-vmdev — CVS-related Virtual Machine Development Issues
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(54) |
Jun
(3) |
Jul
|
Aug
(23) |
Sep
(33) |
Oct
(14) |
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
(15) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
(1) |
Feb
|
Mar
(26) |
Apr
(130) |
May
(5) |
Jun
|
Jul
(21) |
Aug
(3) |
Sep
(24) |
Oct
(10) |
Nov
(37) |
Dec
(2) |
| 2005 |
Jan
(30) |
Feb
(15) |
Mar
(4) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(10) |
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Tim R. <ti...@su...> - 2004-09-09 20:05:19
|
(Mostly to Andreas but it affects several people and probably interests more) John passed on to me (briefly, on a bad cellphone link, so excuse any misunderstandings) the comment about hooking into the forceDamageToScreen/forceDisplayUpdate instead of into the displayBitsOfLeftTopRightBottom end of copyBits (et al.). Excellent suggestion; it avoids the unpleasantness of how to check to see if this is a Display or host window within a rather common operation. (For other people, my first and actually functional hack, was to extend displayBitsOfLeftTopRightBottom such that any bitblt to a host window would trigger the ioShowDisplay mechanism just as Display does now. It works great but meant adding a hopefully-fast way to check for 'destination is some kind of host window'. Ugly, limits you to one class etc but it does make it really simple to display stuff on the extra windows since any bitblt at all with the window as a dest will cause an update immediately) Moving the window updating to a plugin call attached to forceDamageToScreen means it can work with the Canvas mechanism. However, I have queries about some details her since I have no prior experience with doing anything to canvases. a) WTF are canvasss used? So far as I can work out the WorldState has a canvas which is a FormCanvas on the Display. So far so good but they also seem to be used in a few other places and that confuses me because ther is a good bit of code that looks like it very explicitly wants Display to be the target form. See for example WorldState>forceDamageToScreen which explicitly does Dispaly forceDamageToScreen rather than form.... and FormCanvas>flushDisplay which again talks to Display rather than the target form. It's understandable that this might be done with only a single window, though it seems a waste of time when the target form is not the Display. b) Which canvas to use? It looks like FormCanvas is the best candidate already in the system. We could subclass to make the assorted force... messages go to our host window DisplayScreen analogues but then BalloonCanvas and other subclasses of FormCanvas would need sometinhg done. If I've understood it, we could consider changing FormCanvas to send all those force... messages to 'form' instead and then the 'form' could be an instance of HostWindow and we pass them on to the HostWindowPlugin. I looked at some ofthe PluggableCanvas classes but they all seem a bit ugly to me. c) Once we have a canvas talking to the HostWindowPlugin, we open a host window, display something on it, force the damage to screen (well, window) and it's supposed to appear on the glass. Many of us need to process pixels and we have that code in the VM so we can leverage that with (probably) a few mods to factor it not to assume getting the Display oop from specialObjectsArray. Pretty soon the OS is going to send in a paint/expose type event for that window and current code will fail. All the copies of platform code I have (a bit old but probably not horribly out of date) handle a paint by calling fullDisplayUpdate (Ian has a nice little optimisation to use any paint event clipping rectangle) which explcitly gets the bitmap from the Display oop. Clearly this isn't going to do any updating of other windows. As it happens, RISC OS is ok with this due to a side effect of how I have to keep a backing bitmap for each window. All I have to do is map from the incoming window handle to the actual host bitmap and display some of that. No problem except for the 'waste' of memory. If you want to get the latest bits from inside ObjectMemory we will need a map from host window handle to squeak bitmap oop. Easy way is to have an array held by specialObjects that has the oops of the bitmaps used by all open host windows. How else might one handle paint type OS events? d) my knuckles hurt. enough tim -- Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim Useful random insult:- Afraid she'll void her warranty if she thinks too much. |
|
From: Bert F. <be...@im...> - 2004-09-03 10:05:13
|
Am 03.09.2004 um 05:18 schrieb John M McIntosh: > Ok, under os-x running the Squeak VM standalone I find that > > button1 is red squeak mouse bit set to (4) > button2 is blue cmd key squeak mouse bit set to (1) > button3 is yellow option key squeak mouse bit set to (2) > > yes? This is what I see, too. The button numbers from left to right are 1 - 3 - 2. Button3 is when you press the scroll wheel down. > The squeak mouse bits are set by looking at which mouse button was > pressed from the Carbon mouse event. > > Now the fun thing here is that when you use Safari it has to map > button-3 to a cmd/option/cntrl key and mouse-down when it converts the > os-x event to > a historical mac os mouse down event since that is what the Netscape > plugin interface is supplying. Therefore the issue is that button-3 is > turning into a ctrl-click versus option key-click. Ah, so the problem is actually that in Squeak we define option-click to bring up the menu, whereas in the Finder and elsewhere it's ctrl-click. > Does the mouse supplier have an os-x driver they supply that lets you > control what the magic keyboard modifiers are? Logitech does have one, but it is not application sensitive so I can only change the mapping globally. I removed all that nonsense functions and mapped each button to its native value. AFAICT the generic mouse driver just generates button events (buttons 1 to 8 in my case). And the translation to modifiers happens in the browser itself? Apparently, Safari translates button3 and button2 to cmd-click and ctrl-click, while Firefox ignores button3, right button (button2) generates ctrl-click. > What you might want to do is try running the Mac OS Classic vm by > opening up the Squeak VM application by showing the contents and > digging down to the classic VM and executing the "Squeak 3.7.5b1 > Classic" application. Then observe the behavior and let me know. Right button2 does ctrl-click. Middle button3 does nothing. So we cannot actually do much about this. Except maybe for a preference to treat ctrl-click as yellow? I'm wondering if this should be in the VM or in the image ... - Bert - |
|
From: Bert F. <be...@im...> - 2004-09-03 07:18:47
|
Am 03.09.2004 um 02:34 schrieb John M McIntosh: > Actually I don't think we ever offered the B3DAcceleratorPLugin and > the OpenGL support in the os-x carbon plugin code. When I looked at > that a few > years back I found that IE and the openGL stuff did NOT play nice! In > fact I spent many many days trying to get it to work and gave up. > > Of course now that we have safari I should look again I'd guess, but I > doubt I can get it into 3.7.5x unless it just works out of the box Thanks! It's not all that important for the Squeakland VM indeed. Although it might be useful in the not-too-distant future to run Croquet from the browser plugin ;-) - Bert - |
|
From: John M M. <jo...@sm...> - 2004-09-03 00:34:55
|
Actually I don't think we ever offered the B3DAcceleratorPLugin and the OpenGL support in the os-x carbon plugin code. When I looked at that a few years back I found that IE and the openGL stuff did NOT play nice! In fact I spent many many days trying to get it to work and gave up. Of course now that we have safari I should look again I'd guess, but I doubt I can get it into 3.7.5x unless it just works out of the box On Sep 2, 2004, at 3:18 PM, Bert Freudenberg wrote: > Am 02.09.2004 um 22:20 schrieb John M McIntosh OLD: > >> I've posted a SqueakLand.3.7.5b1.dmg in the >> http://homepage.mac.com/johnmci/ location > > Hi John, > > I tried your SqueakLand.3.7.5b1.dmg. The NPSqueak version works great > with the latest beta image (http://impara.de/drop/m17n/). However, the > B3DAcceleratorPlugin is missing? > > Also, please note that I checked in a fix for the B3DAcceleratorPlugin > this week, so you may want to update the Cross platform tree. > > - Bert - > > > -- ======================================================================== === John M. McIntosh <jo...@sm...> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
From: Bert F. <be...@im...> - 2004-09-02 22:20:14
|
Am 02.09.2004 um 22:20 schrieb John M McIntosh OLD: > I've posted a SqueakLand.3.7.5b1.dmg in the > http://homepage.mac.com/johnmci/ location Hi John, I tried your SqueakLand.3.7.5b1.dmg. The NPSqueak version works great with the latest beta image (http://impara.de/drop/m17n/). However, the B3DAcceleratorPlugin is missing? Also, please note that I checked in a fix for the B3DAcceleratorPlugin this week, so you may want to update the Cross platform tree. - Bert - |
|
From: John M M. O. <jo...@sm...> - 2004-09-02 20:20:43
|
I've posted a SqueakLand.3.7.5b1.dmg in the http://homepage.mac.com/johnmci/ location A note was sent to the squeak list about the changes. I'll look further at your issue with mouse buttons. On Aug 31, 2004, at 2:07 PM, Bert Freudenberg wrote: > This looks *much* better! Thanks! > > The next Squeakland release is only a few days away, since some > schools start next week. Michael actually wants to create release > candidate installers today, with the actual release following later > this week. Perhaps you could do the backport even sooner?-- ======================================================================== === John M. McIntosh <jo...@sm...> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
From: Bert F. <be...@im...> - 2004-09-01 13:18:38
|
Great! One more thing I noticed in the NPSqueak VM vs. the regular VM is when you use a 3-button mouse: In the regular VM, the middle and right button bring up the context menu and halo, respectively, so we have a nice red-yellow-blue mapping. There is no difference in fullscreen mode. Running in the browser window, however, the middle button brings up the halo, vs the right button seems to be mapped to ctrl-click. No button brings up the context menu (except for pressing the option key). So we have red-blue-ctrl. When escaping the browser (going fullscreen), the middle button stops functioning at all (no halo anymore). Which means red-nada-ctrl. It would be nice if the behaviour would be the same independent of how the image is started. Also, while you're at it ;-) IMHO a red-blue-yellow mapping would be more consistent with the Finder and other apps, which bring up the context menu on a right click. - Bert - Am 01.09.2004 um 09:40 schrieb John M McIntosh: > I compiled a version Tuesday night. I'll see if I can push it out Wed > evening. > > On Aug 31, 2004, at 2:07 PM, Bert Freudenberg wrote: > >> This looks *much* better! Thanks! >> >> The next Squeakland release is only a few days away, since some >> schools start next week. Michael actually wants to create release >> candidate installers today, with the actual release following later >> this week. Perhaps you could do the backport even sooner? >> >> Btw, I did build a VM myself, but when the latest SF sources only >> have your 3.7.1b3 version? Or is it just the info.plist files and >> resource icons which are not up to date? >> >> - Bert - >> >> Am 31.08.2004 um 20:17 schrieb John M McIntosh: >> >>> This is fixed, I've released an early VM for testing of application >>> background click behavior and the color mapping change, we now use a >>> lookup table >>> to smoothly map from '00000'b<->'11111'b to 0x00 0xFF >>> >>> I most likely will backport this change to a 3.7.5 version in the >>> next week. >>> >>> You can find a beta on >>> >>> see http://homepage.mac.com/johnmci/ >>> >>> Squeak 3.8.1Beta2.app.sit >>> >>> It has >>> >>> a) Native Menubar support, still being written is the Smalltalk >>> EventSensor code (my task for today). >>> b) The color mapping from 16 color space to 32 bit color space >>> follows a smooth transition curve, versus a logrithmic like pattern. >>> This makes >>> color shading look correct when going from 16 to 32bit displays and >>> having squeak in 16bit appearance mode. >>> c) Multiple window support, (a work in progress by Tim and myself). >>> d) Minor changes to mac support files to eliminate compiler warning >>> messages about improper casting, and returning void from routines >>> returning int. >>> e) toss the mouse click activation event when you click on the >>> Squeak window and it's a background window. >>> >>> On Aug 31, 2004, at 2:39 AM, Bert Freudenberg wrote: >>> >>>> Hi John, >>>> >>>> when testing the new Squeakland image >>>> (http://impara.de/drop/m17n/DSqueak3.8a-5976-60004-267r- >>>> plugin.zip), I noticed the menus look odd. They now have a >>>> horizontal gradient, which before was a solid color. Apparently, a >>>> gamma correction is performed when displaying the 16 bit Squeak >>>> Display on the OS's 32 bit screen. Things look fine when both the >>>> OS and Squeak are set to 16 bits. Is it possible to suppress this >>>> color correction? We cannot easily change the default depth of >>>> Squeak to 32 bits, because certain existing Etoys rely on exact >>>> color matches. >>>> >>>> - Bert - |
|
From: John M M. <jo...@sm...> - 2004-09-01 07:41:34
|
Mmm I think the info.plist is stale. I'll check that and ensure everything goes out wed evening. On Aug 31, 2004, at 2:07 PM, Bert Freudenberg wrote: > Btw, I did build a VM myself, but when the latest SF sources only have > your 3.7.1b3 version? Or is it just the info.plist files and resource > icons which are not up to date? > > - Bert - -- ======================================================================== === John M. McIntosh <jo...@sm...> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
From: John M M. <jo...@sm...> - 2004-09-01 07:40:38
|
I compiled a version Tuesday night. I'll see if I can push it out Wed evening. On Aug 31, 2004, at 2:07 PM, Bert Freudenberg wrote: > This looks *much* better! Thanks! > > The next Squeakland release is only a few days away, since some > schools start next week. Michael actually wants to create release > candidate installers today, with the actual release following later > this week. Perhaps you could do the backport even sooner? > > Btw, I did build a VM myself, but when the latest SF sources only have > your 3.7.1b3 version? Or is it just the info.plist files and resource > icons which are not up to date? > > - Bert - > > Am 31.08.2004 um 20:17 schrieb John M McIntosh: > >> This is fixed, I've released an early VM for testing of application >> background click behavior and the color mapping change, we now use a >> lookup table >> to smoothly map from '00000'b<->'11111'b to 0x00 0xFF >> >> I most likely will backport this change to a 3.7.5 version in the >> next week. >> >> You can find a beta on >> >> see http://homepage.mac.com/johnmci/ >> >> Squeak 3.8.1Beta2.app.sit >> >> It has >> >> a) Native Menubar support, still being written is the Smalltalk >> EventSensor code (my task for today). >> b) The color mapping from 16 color space to 32 bit color space >> follows a smooth transition curve, versus a logrithmic like pattern. >> This makes >> color shading look correct when going from 16 to 32bit displays and >> having squeak in 16bit appearance mode. >> c) Multiple window support, (a work in progress by Tim and myself). >> d) Minor changes to mac support files to eliminate compiler warning >> messages about improper casting, and returning void from routines >> returning int. >> e) toss the mouse click activation event when you click on the Squeak >> window and it's a background window. >> >> On Aug 31, 2004, at 2:39 AM, Bert Freudenberg wrote: >> >>> Hi John, >>> >>> when testing the new Squeakland image >>> (http://impara.de/drop/m17n/DSqueak3.8a-5976-60004-267r-plugin.zip), >>> I noticed the menus look odd. They now have a horizontal gradient, >>> which before was a solid color. Apparently, a gamma correction is >>> performed when displaying the 16 bit Squeak Display on the OS's 32 >>> bit screen. Things look fine when both the OS and Squeak are set to >>> 16 bits. Is it possible to suppress this color correction? We cannot >>> easily change the default depth of Squeak to 32 bits, because >>> certain existing Etoys rely on exact color matches. >>> >>> - Bert - > > > -- ======================================================================== === John M. McIntosh <jo...@sm...> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
From: Bert F. <be...@im...> - 2004-08-31 21:07:58
|
This looks *much* better! Thanks! The next Squeakland release is only a few days away, since some schools start next week. Michael actually wants to create release candidate installers today, with the actual release following later this week. Perhaps you could do the backport even sooner? Btw, I did build a VM myself, but when the latest SF sources only have your 3.7.1b3 version? Or is it just the info.plist files and resource icons which are not up to date? - Bert - Am 31.08.2004 um 20:17 schrieb John M McIntosh: > This is fixed, I've released an early VM for testing of application > background click behavior and the color mapping change, we now use a > lookup table > to smoothly map from '00000'b<->'11111'b to 0x00 0xFF > > I most likely will backport this change to a 3.7.5 version in the next > week. > > You can find a beta on > > see http://homepage.mac.com/johnmci/ > > Squeak 3.8.1Beta2.app.sit > > It has > > a) Native Menubar support, still being written is the Smalltalk > EventSensor code (my task for today). > b) The color mapping from 16 color space to 32 bit color space follows > a smooth transition curve, versus a logrithmic like pattern. This > makes > color shading look correct when going from 16 to 32bit displays and > having squeak in 16bit appearance mode. > c) Multiple window support, (a work in progress by Tim and myself). > d) Minor changes to mac support files to eliminate compiler warning > messages about improper casting, and returning void from routines > returning int. > e) toss the mouse click activation event when you click on the Squeak > window and it's a background window. > > On Aug 31, 2004, at 2:39 AM, Bert Freudenberg wrote: > >> Hi John, >> >> when testing the new Squeakland image >> (http://impara.de/drop/m17n/DSqueak3.8a-5976-60004-267r-plugin.zip), >> I noticed the menus look odd. They now have a horizontal gradient, >> which before was a solid color. Apparently, a gamma correction is >> performed when displaying the 16 bit Squeak Display on the OS's 32 >> bit screen. Things look fine when both the OS and Squeak are set to >> 16 bits. Is it possible to suppress this color correction? We cannot >> easily change the default depth of Squeak to 32 bits, because certain >> existing Etoys rely on exact color matches. >> >> - Bert - |
|
From: John M M. <jo...@sm...> - 2004-08-31 18:17:34
|
This is fixed, I've released an early VM for testing of application background click behavior and the color mapping change, we now use a lookup table to smoothly map from '00000'b<->'11111'b to 0x00 0xFF I most likely will backport this change to a 3.7.5 version in the next week. You can find a beta on see http://homepage.mac.com/johnmci/ Squeak 3.8.1Beta2.app.sit It has a) Native Menubar support, still being written is the Smalltalk EventSensor code (my task for today). b) The color mapping from 16 color space to 32 bit color space follows a smooth transition curve, versus a logrithmic like pattern. This makes color shading look correct when going from 16 to 32bit displays and having squeak in 16bit appearance mode. c) Multiple window support, (a work in progress by Tim and myself). d) Minor changes to mac support files to eliminate compiler warning messages about improper casting, and returning void from routines returning int. e) toss the mouse click activation event when you click on the Squeak window and it's a background window. On Aug 31, 2004, at 2:39 AM, Bert Freudenberg wrote: > Hi John, > > when testing the new Squeakland image > (http://impara.de/drop/m17n/DSqueak3.8a-5976-60004-267r-plugin.zip), I > noticed the menus look odd. They now have a horizontal gradient, which > before was a solid color. Apparently, a gamma correction is performed > when displaying the 16 bit Squeak Display on the OS's 32 bit screen. > Things look fine when both the OS and Squeak are set to 16 bits. Is it > possible to suppress this color correction? We cannot easily change > the default depth of Squeak to 32 bits, because certain existing Etoys > rely on exact color matches. > > - Bert - > > > -- ======================================================================== === John M. McIntosh <jo...@sm...> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
From: Bert F. <be...@im...> - 2004-08-31 09:39:47
|
Hi John, when testing the new Squeakland image (http://impara.de/drop/m17n/DSqueak3.8a-5976-60004-267r-plugin.zip), I noticed the menus look odd. They now have a horizontal gradient, which before was a solid color. Apparently, a gamma correction is performed when displaying the 16 bit Squeak Display on the OS's 32 bit screen. Things look fine when both the OS and Squeak are set to 16 bits. Is it possible to suppress this color correction? We cannot easily change the default depth of Squeak to 32 bits, because certain existing Etoys rely on exact color matches. - Bert - |
|
From: David A. S. <dav...@be...> - 2004-07-29 14:07:49
|
We are using this for Croquet, but we are happy to have it simply emit up-arrow and down-arrow keys for now, which I believe is the behavior on the Mac and Win. Regards, David On Jul 29, 2004, at 2:50 AM, John M McIntosh wrote: > In making changes to sq.h I discovered that I had made a change for > the scroll mouse logic which impacts some changes we want to > make for multiple windows, but I not sure anyone is using this feature. > > On os-x if you are using a wheel mouse I generate a mouse move event > and pass up > the axis direction and number of movements in the reserved fields, > followed by the key-down/key char/key-up events > for each simulated arrow key. > > I believe other platforms just provide the key stroke data and do not > pass up the raw wheel mouse data. As mentioned earlier this > data is provided in the two reserved (undocumented) fields of the > mouse event from EventSensor. > > In looking at what is happening in the image, I can't see anyone > actually using this data at this time. > > Because of changes we're making I'm going to be dropping this > information, since it's not duplicated on other platforms, this is > an easier choice than adding another field to the event logic to > support the windowIndex information. > > If anyone has issues please let me know. > > > -- > ======================================================================= > ==== > John M. McIntosh <jo...@sm...> 1-800-477-2659 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > ======================================================================= > ==== > > |
|
From: John M M. <jo...@sm...> - 2004-07-29 06:50:09
|
In making changes to sq.h I discovered that I had made a change for the scroll mouse logic which impacts some changes we want to make for multiple windows, but I not sure anyone is using this feature. On os-x if you are using a wheel mouse I generate a mouse move event and pass up the axis direction and number of movements in the reserved fields, followed by the key-down/key char/key-up events for each simulated arrow key. I believe other platforms just provide the key stroke data and do not pass up the raw wheel mouse data. As mentioned earlier this data is provided in the two reserved (undocumented) fields of the mouse event from EventSensor. In looking at what is happening in the image, I can't see anyone actually using this data at this time. Because of changes we're making I'm going to be dropping this information, since it's not duplicated on other platforms, this is an easier choice than adding another field to the event logic to support the windowIndex information. If anyone has issues please let me know. -- ======================================================================== === John M. McIntosh <jo...@sm...> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
From: Craig L. <cr...@ne...> - 2004-07-16 01:20:38
|
YAY -C -- Craig Latta improvisational musical informaticist cr...@ne... www.netjam.org [|] Proceed for Truth! |
|
From: Dan I. <Da...@Sq...> - 2004-07-16 00:31:23
|
Folks - Just wanted to share my experiences from the last 48 hours. The bad news is that Andreas was right about the fundamental problem of simulating C Arrays that get floats, signed ints and 32-bit masks stored into them, when the Smalltalk code that reads out of them can't tell how to load them. Heh heh. I was actually in a bad mood for part of that evening. Ah, sleep that knits up the ravelled sleeve of care. Next morning I had the solution. Had to go outside the box. Spent a day hacking it into place and... The good news is that (again with the latest 3.7 image and VMMaker sources) I can now bring up a morphic display (gradient fills, TrueType titles and all) type '3+4' in a workspace, and print the result. Note that since Cmd bits don't come through the keyboard, I had to bring up a menu (inboard graphics and all) to do this. The same system also brings up an MVC project just fine, and it too compiles/prints 3+4. Happy happy. I now plan to make up a careful bundle of the sources, rebuild the 64-bit stuff on top of that, and then see if I can get the 64-bit simulator to go this far too. At that point I'd like a couple of testers and then, if Tim has some time perhaps we can get it all out in as a new VMM release. Ciao - Dan |
|
From: <gor...@bl...> - 2004-07-14 08:33:45
|
Dan Ingalls <Da...@Sq...> wrote: > Folks - > > I'm taking time out from 64-bit hacking to restore the regular > (32-bit) simulator to full operation. > > Today I present exhibit A -- more than I believe has been visible in > the Simulator for a long time (if ever). Note the browser buttons > and scroll buttons with successful gradient fills... Wohoo! Impressive! Yeah, we just talked on IRC about the simulator - we really need to make sure it doesn't "rot" again. Would be nice to have some tests for it. And some little server sitting and running the tests like a mad dog - I believe Daniel Vainsencher and someone else experimented with such a beast. regards, Göran PS. Noone has yet reacted with a "full solution" to the signed int endOfMemory: http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-July/079503. html |
|
From: Andreas R. <and...@gm...> - 2004-07-13 02:03:39
|
Dan, > That's exactly the kind of boost I was after. I'll take it > from here and, with the caveat that I may have to ask you a > couple more specific questions, I should be able to get things > right. I will report to all as things progress. Great. If you want to, we could meet wednesday to work out any remaining issues. Let me know (or rather: Kim, since that'll be eating into eToys time) if we want to set up a meeting for an hour or so. Cheers, - Andreas ----- Original Message ----- From: "Dan Ingalls" <Da...@Sq...> To: "Andreas Raab" <and...@gm...> Cc: <squ...@li...> Sent: Monday, July 12, 2004 11:30 AM Subject: Re: [Squeak-VMdev] Request for help with simulation in 3.7 > >All of it should and does run in the simulation > > Thanks, Andreas - > > This gives me great hope. > > >- it's just that there are a > >few gotchas that I didn't think about for getting this stuff running from > >the interpsim (which, unfortunately insists on managing an array of bytes > >instead of objects...) > > > >AFAICT, the problem is really in the use of the workBuffer iVar in the B2D > >simulation which expects some sort of array (it's accessed via #at: and > >#at:put:) and typically holding a CArrayAccessor of some kind but being > >handed a SmallInt from the interpsim. Which in itself wouldn't be that big > >of a problem if the simulation would consistently use #longAt: and friends > >but it doesn't and so there it goes... > > > >I've attached a few changes which (I think) are the simplest workaround to > >the problem. Let me know if this works. > > That's exactly the kind of boost I was after. I'll take it from here and, with the caveat that I may have to ask you a couple more specific questions, I should be able to get things right. I will report to all as things progress. > > - Dan > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Squeak-VMdev mailing list > Squ...@li... > https://lists.sourceforge.net/lists/listinfo/squeak-vmdev > |
|
From: Dan I. <Da...@Sq...> - 2004-07-12 18:30:38
|
>All of it should and does run in the simulation Thanks, Andreas - This gives me great hope. >- it's just that there are a >few gotchas that I didn't think about for getting this stuff running from >the interpsim (which, unfortunately insists on managing an array of bytes >instead of objects...) > >AFAICT, the problem is really in the use of the workBuffer iVar in the B2D >simulation which expects some sort of array (it's accessed via #at: and >#at:put:) and typically holding a CArrayAccessor of some kind but being >handed a SmallInt from the interpsim. Which in itself wouldn't be that big >of a problem if the simulation would consistently use #longAt: and friends >but it doesn't and so there it goes... > >I've attached a few changes which (I think) are the simplest workaround to >the problem. Let me know if this works. That's exactly the kind of boost I was after. I'll take it from here and, with the caveat that I may have to ask you a couple more specific questions, I should be able to get things right. I will report to all as things progress. - Dan |
|
From: Dan I. <Da...@Sq...> - 2004-07-10 16:49:15
|
tim Rowledge <ti...@su...> wrote.. >With the two fixes I sent you in between packing boxes and disconnecting computers it should simulate about as well as can be expected right now. >As you've discovered, there are parts of some plugins which were not written with support for the simulator in mind. For example, 6 methods send strlen: and 7 strcmp: - neither of which are simulated. Well, my expectations are higher, but you're right that some recent additions seem never to have been simulated. >BalloonEngine>>#primInitializeBuffer: looks suspicious to me from a quick scan mainly because resetGraphicsEngineStats fills up 'workBuffer' which most likely needs to be wrapped in a CArrayAccessor in the BalloonEngineSimulation code. See BalloonEngineSimulation>smallSqrtTable for an example involving a small array. If Andreas is listening, it would be *extremely* useful to me to know how this is supposed to work. In other words if everything should fail in simulation, or if some or all of it will have to run in slang code. And whether that slang ever ran in simulation, or only in translation to C. >Interpreter>primitiveTruncated fails for utterly obvious reasons - the line self cCode:'pushInteger((int) trunc)' inSmalltalk:[self pushInteger: rcvr truncated]] quite obviously doesn't do a range test on the truncated number and since a very large float can easily exceed an acceptable 32bit int, kaboom. Yes, I fixed this way back. >All of the improvements Ned (&I) proposed in april when you started looking at 64bitness are in the VMMaker3-7b5 package. The extra two fixes compensate for the latest work on dispatching direct function addresses in the message sending. > >Aside from some places where the perpetrator of code can remember doing something unsimulable, the only real answer is to run till it breaks and find a fix each time. Ny experience is that this is tedious, time consuming and utterly unappreciated work that nobody cares about until they have a problem. Much like most VM work in fact :-) Having just bashed most of the kernel into execution of a true 64-bit image with a true 64-bit ObjectMemory, I'm pretty much into the tedium. I do appreciate what everyone has done before, and the best form of that appreciation in my mind would be for me to get things working right again, and to leave some basic tests in place that will make it easy for the guides or whoever to check that most everything is right before any major release. - Dan |
|
From: tim R. <ti...@su...> - 2004-07-10 00:15:10
|
> 1. If everything worked right, is it the case that a current system > should be able to simulate itself? What this means is that, provided > that the plugin interface all works (and fails) properly, does all > the necessary failure code exist such that the system will run > completely and with integrity? If this is not so, then a further > question is, apart from whatever fixes may be needed, how much new > code would need to be written? > With the two fixes I sent you in between packing boxes and disconnecting computers it should simulate about as well as can be expected right now. As you've discovered, there are parts of some plugins which were not written with support for the simulator in mind. For example, 6 methods send strlen: and 7 strcmp: - neither of which are simulated. BalloonEngine>>#primInitializeBuffer: looks suspicious to me from a quick scan mainly because resetGraphicsEngineStats fills up 'workBuffer' which most likely needs to be wrapped in a CArrayAccessor in the BalloonEngineSimulation code. See BalloonEngineSimulation>smallSqrtTable for an example involving a small array. Interpreter>primitiveTruncated fails for utterly obvious reasons - the line self cCode:'pushInteger((int) trunc)' inSmalltalk:[self pushInteger: rcvr truncated]] quite obviously doesn't do a range test on the truncated number and since a very large float can easily exceed an acceptable 32bit int, kaboom. All of the improvements Ned (&I) proposed in april when you started looking at 64bitness are in the VMMaker3-7b5 package. The extra two fixes compensate for the latest work on dispatching direct function addresses in the message sending. Aside from some places where the perpetrator of code can remember doing something unsimulable, the only real answer is to run till it breaks and find a fix each time. Ny experience is that this is tedious, time consuming and utterly unappreciated work that nobody cares about until they have a problem. Much like most VM work in fact :-) I'm not in a position to do anything much with this for now; I'm still unpacking, setting up and trying to find everything. tim |
|
From: Craig L. <cr...@ne...> - 2004-07-10 00:05:05
|
> Maybe there was some... conflict with my other stuff. Yeah, it sounds like it. So, I have a 3.2 snapshot that can simulate itself. This same snapshot can simulate the 3.6 snapshot that OpenAugment has been using (probably due to some changes I made that I haven't isolated for release, sorry). I guess a pragmatic question is, are you interested in either of those combinations, or are they too old? :) (The oldest is the 3.2 snapshot, from 2002.) There may be the small issue of *my* VM changes for Squat getting in the way, but I could take those out pretty easily. I can't help mentioning that this is all great motivation for the Squat module system, which is what I'm trying to build with these things. :) -C p.s. Now *I'm* off for the evening, take care... -- Craig Latta improvisational musical informaticist cr...@ne... www.netjam.org [|] Proceed for Truth! |
|
From: Craig L. <cr...@ne...> - 2004-07-09 23:34:55
|
Oh, I also tried with a 3.6 "final" snapshot, also (3.6.5429). Apparently the VM stuff is already in there, so you don't have to load a separate VMMaker package. InterpreterSimulator>>primitiveGetAttribute, InterpreterSimulatorLSB>>halfWordAt: and SequenceableCollection>>copyGrownBy: are all missing, as with VMMaker 3.6g2 and 3.7a2. After patching those, simulating the 3.6.5429 snapshot in MVC yields the "primitiveBrowserPluginReady" problem I mentioned in my previous message. In Morphic, Interpreter>>primitiveTruncated barfs on a very large number. The display is painted under MVC, however, as with 3.7.5969. Normally these days I simulate 3.2 and 2.2 snapshots from a 3.2 snapshot, for the Squat project. -C -- Craig Latta improvisational musical informaticist cr...@ne... www.netjam.org [|] Proceed for Truth! |
|
From: Craig L. <cr...@ne...> - 2004-07-09 22:45:11
|
Oh, I hadn't noticed there was a thread here, too. Just for completeness, here's what I sent a little while ago to Dan, Tim, and the Squeak list. -------- Original Message -------- Subject: [FIX] simulator regression-testing, 2004-07-09 Date: Fri, 09 Jul 2004 15:16:44 -0700 From: Craig Latta <cr...@ne...> Organization: the NetJam project To: Dan Ingalls <Da...@Sq...>,tim Rowledge <ti...@su...> Newsgroups: gmane.comp.lang.smalltalk.squeak.general References: <B85...@ia...> <40E...@ne...> <601...@ia...> <40E...@ne...> <p05210605bd128cd87a05@[10.0.1.3]><40E...@ne...> <p05210608bd148420a934@[10.0.1.3]> Hi all-- I tried simulating a current snapshot (3.7b.5969) with several versions of the VMMaker package, in both MVC and Morphic. VMMaker 3.7b5 and 3.7b4 don't work because of bugs with the primitive function-pointer stuff that Tim added in April (apparently these changes were never tested under simulation?). VMMaker 3.7b2 yields a bizarre situation with Interpreter>>positive32BitValueOf: getting run when the top of the stack is a ReadStream instead of a number. VMMaker 3.6g2 and 3.7a2 are missing InterpreterSimulator>>primitiveGetAttribute, InterpreterSimulatorLSB>>halfWordAt: (but not InterpreterSimulatorMSB>>halfWordAt:, which is weird), and SequenceableCollection>>copyGrownBy:. VMMaker 3.7b1 has InterpreterSimulator>>primitiveGetAttribute, but is missing the other two things that VMMaker 3.6g2 and 3.7a2 are missing. After patching it (patch attached), it seems to start. The open issues first encountered are: - When simulating MVC, there's no simulation for FloatArrayPlugin, and hilarity ensues when the simulator tries to store an actual Float in the object memory bitmap. - When simulating Morphic, when trying to dispatch for "primitiveBrowserPluginReady", control goes to Interpreter>>findObsoleteNamedPrimitive:length: (instead of an override in InterpreterSimulator, as I would expect). The Slang code there attempts one of its famous "at: 0" expressions, then bang. I guess the simulation for that stuff has never been written. I've mostly been simulating 3.2 and 2.2 snapshots myself, with very pedestrian plugins or no plugins at all, so I hadn't encountered those issues. And I could have sworn the items in the attached patch had been in VMMaker for some time, sorry for assuming incorrectly in my previous message. Anyway, we seem to be in decent shape; the things that don't work seem to be things that have never worked. :) Happy hacking... I probably wouldn't get to the open issues myself for some time. I'm currently occupied with much weirder Squat stuff. But as usual, I would reprioritize if someone paid me. :) thanks, -C -- Craig Latta improvisational musical informaticist cr...@ne... www.netjam.org [|] Proceed for Truth! |
|
From: Dan I. <Da...@Sq...> - 2004-07-09 22:35:54
|
Hi, Craig - > Anyway, we seem to be in decent shape; the things that don't work seem >to be things that have never worked. :) Happy hacking... I probably >wouldn't get to the open issues myself for some time. I'm currently >occupied with much weirder Squat stuff. But as usual, I would >reprioritize if someone paid me. :) I've done these changes myself. I'll look deeper as soon as I get a chance (out for a few hours). Maybe there was some stupid conflict with my other stuff. Thanks for your time and checking into all of this. - Dan |
13 messages has been excluded from this view by a project administrator.
