Vm-dev

vm-dev@lists.squeakfoundation.org

2 participants
17052 discussions

Sound on 3.7-7 for solaris 8 on intel
by Wolfgang Helbig 14 Jan '06

14 Jan '06

Hi, after installing successfully the 3.7-7 stuff from squeakvm.org on my sol8-i386 system, playing music using the vm-sound-Sun plugin is kind of disappointing: If I hit the play button to play the example midi file it plays less then a second. If I hit the play button again, nothing happens. So what can be done? I tried to apply NAS, but I didn't find a vm-sound-NAS plugin for solaris 8 on intel. thanks for any help! Wolfgang

1 0

Smartphone port of squeak
by Sam Liddicott 13 Jan '06

13 Jan '06

I'm trying my hand at porting squeak to MS Smartphone 2003, which is based on WINCE4. I'm adapting the win32 squeak build, which makes the most sense; Smartphone, however, DOES have a joystick but does NOT have a mouse or mouse pointer. It does have a concept of tab-order and focus. Is this going to be a dead loss? while faking a mouse pointer might be worthwhile for some things, if smalltalk is useless without it, then it is probably a waste of time; does smalltalk or the GUI used, have a concept of focus? Or would these be a feature of something like wxSqueak, which probably could be ported? Comments? The other problem is, that although Smartphone supports sizeof(char)=1, 2 byte wchar_t is used for most API calls. Comments? Sam

2 1

Obscure hang
by Bert Freudenberg 09 Jan '06

09 Jan '06

Hi folks, I've had some rather obscure hangs on my squeak-source server lately. The funny thing is, as soon as I connect to the Xvnc server and move the mouse, things start rolling again. Otherwise, it takes a couple of minutes until serving continues. I have no idea why. Here are the file descriptors for reference. #3 is the X server (Xvnc) connection: squeaksou 30574 source 0r CHR 1,3 31583 /dev/ null squeaksou 30574 source 1w REG 3,5 32895 16482319 .../ some.log squeaksou 30574 source 2w REG 3,5 32895 16482319 .../ some.log squeaksou 30574 source 3u unix 0xf2119ac0 3367464 socket squeaksou 30574 source 4r REG 3,5 23206828 12402706 .../ some.image squeaksou 30574 source 5r DIR 3,5 4096 12402698 .../ somedir squeaksou 30574 source 6r REG 3,5 14542313 17317896 .../ SqueakV3.sources squeaksou 30574 source 7u REG 3,5 20230368 12402705 .../ some.changes squeaksou 30574 source 8u IPv4 4290750 TCP *:someport (LISTEN) Unfortunately I took this only after the hang. Socket #9 must be a file that was interrupted while writing, 10 and 11 is an HTTP connection pair. There were already 3581255 bytes of 4457385 bytes written to file #9 at this point. === According to strace the VM was chugging along just fine: gettimeofday({1136823729, 265939}, NULL) = 0 gettimeofday({1136823729, 265985}, NULL) = 0 gettimeofday({1136823729, 266050}, NULL) = 0 gettimeofday({1136823729, 266092}, NULL) = 0 --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) gettimeofday({1136823729, 277789}, NULL) = 0 gettimeofday({1136823729, 277819}, NULL) = 0 gettimeofday({1136823729, 277856}, NULL) = 0 gettimeofday({1136823729, 277877}, NULL) = 0 gettimeofday({1136823729, 277910}, NULL) = 0 gettimeofday({1136823729, 277939}, NULL) = 0 ioctl(3, FIONREAD, [0]) = 0 gettimeofday({1136823729, 278015}, NULL) = 0 select(9, [3], [], [3 8], {0, 0}) = 0 (Timeout) gettimeofday({1136823729, 278212}, NULL) = 0 gettimeofday({1136823729, 289711}, NULL) = 0 gettimeofday({1136823729, 289751}, NULL) = 0 gettimeofday({1136823729, 289813}, NULL) = 0 gettimeofday({1136823729, 289854}, NULL) = 0 ... === but nothing was served to sockets 10/11 nor written to file #9. Now some X data arrives on socket #3 ... gettimeofday({1136823748, 170924}, NULL) = 0 gettimeofday({1136823748, 170956}, NULL) = 0 gettimeofday({1136823748, 170984}, NULL) = 0 ioctl(3, FIONREAD, [32]) = 0 read(3, "\7\1W\204A\306\371\257%\0\0\0\1\0\200\0\2\0\200\0\217 \003"..., 32) = 32 ioctl(3, FIONREAD, [32]) = 0 read(3, "\6\0W\204B\306\371\257%\0\0\0\2\0\200\0\0\0\0\0\211\003"..., 32) = 32 gettimeofday({1136823748, 171177}, NULL) = 0 ioctl(3, FIONREAD, [0]) = 0 gettimeofday({1136823748, 171221}, NULL) = 0 select(9, [3], [], [3 8], {0, 0}) = 0 (Timeout) ... ==== and 5 seconds later it answers the (pending?) request on sockets 10/11 ioctl(3, FIONREAD, [0]) = 0 gettimeofday({1136823753, 233667}, NULL) = 0 select(9, [3], [], [3 8], {0, 0}) = 0 (Timeout) gettimeofday({1136823753, 234002}, NULL) = 0 gettimeofday({1136823753, 234042}, NULL) = 0 gettimeofday({1136823753, 234070}, NULL) = 0 gettimeofday({1136823753, 234110}, NULL) = 0 ioctl(10, FIONBIO, [1]) = 0 gettimeofday({1136823753, 234306}, NULL) = 0 gettimeofday({1136823753, 234330}, NULL) = 0 gettimeofday({1136823753, 234352}, NULL) = 0 gettimeofday({1136823753, 234377}, NULL) = 0 gettimeofday({1136823753, 234410}, NULL) = 0 gettimeofday({1136823753, 234431}, NULL) = 0 gettimeofday({1136823753, 234456}, NULL) = 0 getpeername(10, {sa_family=AF_INET, sin_port=htons(44431), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 time(NULL) = 1136823753 gettimeofday({1136823753, 234716}, NULL) = 0 gettimeofday({1136823753, 234738}, NULL) = 0 recv(10, "G", 1, MSG_PEEK) = 1 read(10, "GET /3d/?C=M;O=D HTTP/1.1\r\nHost:"..., 2000) = 266 time(NULL) = 1136823753 --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) gettimeofday({1136823753, 239059}, NULL) = 0 gettimeofday({1136823753, 239600}, NULL) = 0 gettimeofday({1136823753, 239624}, NULL) = 0 time(NULL) = 1136823753 gettimeofday({1136823753, 243498}, NULL) = 0 select(11, NULL, [10], NULL, {0, 0}) = 1 (out [10], left {0, 0}) write(10, "HTTP/1.1 200 OK\r\nKeep-Alive: tim"..., 190) = 190 gettimeofday({1136823753, 243785}, NULL) = 0 select(11, NULL, [10], NULL, {0, 0}) = 1 (out [10], left {0, 0}) write(10, "<?xml version=\"1.0\" encoding=\"is"..., 3811) = -1 EPIPE (Broken pipe) --- SIGPIPE (Broken pipe) @ 0 (0) --- === immediately followed by writing to file #9 gettimeofday({1136823753, 244020}, NULL) = 0 getpeername(10, 0xbffff9d0, [16]) = -1 ENOTCONN (Transport endpoint is not connected) time(NULL) = 1136823753 setsockopt(10, SOL_SOCKET, SO_LINGER, {onoff=0, linger=0}, 8) = 0 close(10) = 0 write(9, "\10", 1) = 1 write(9, "\0", 1) = 1 write(9, "\0", 1) = 1 write(9, "\0", 1) = 1 write(9, "\1", 1) = 1 write(9, "\t", 1) = 1 _llseek(9, 3579904, [3579904], SEEK_SET) = 0 read(9, "ubclasses.\20\3\37\312\20\5\37\325\4\0\0\0\0\n\0\34\315"..., 1356) = 1356 read(9, "\t", 4096) = 1 _llseek(9, 3581261, [3581261], SEEK_SET) = 0 _llseek(9, 3581261, [3581261], SEEK_SET) = 0 _llseek(9, -1, [3581260], SEEK_CUR) = 0 write(9, "\20", 1) = 1 write(9, "\t", 1) = 1 write(9, "\37", 1) = 1 write(9, "\3", 1) = 1 === 11 seconds later the saving was done (yes storing is that slow): close(9) = 0 munmap(0x40188000, 4096) = 0 gettimeofday({1136823764, 800773}, NULL) = 0 === ... and everything is back to normal ... All this is on Linux, 2.4 kernel, Ian's 3.7.7 VM. Did anybody see something similar? Any ideas? - Bert -

2 2

How to add new immediate types (was: Re: Adding a new imediate type)
by Andreas Raab 04 Jan '06

04 Jan '06

Hi Folks - [Cross-posted to VM-dev where this topic really belongs] As others have noted, it's Really Hard (tm) to add a new immediate type. However, having said that, I would like to outline an approach that I've contemplated in the past (up to the point of actually implementing a major part of it). The main issue with tag bits is that they are for obvious reasons few and far inbetween so it's hard to get the maximum value out of changing the VM for a single new immediate type. In addition there is a major issue with the range of bits for SmallIntegers - each tag bit takes away from the number of bits available for small integers and that's not good since many algorithms are designed to fit into 32 bits and the more often you have to fall back to general large int arithmethic, the worse it gets. Today, we use a single tag bit which differentiates small integers from "regular" pointer objects. (Not so) incidentally, this is bit zero so that pointer objects (which are always aligned to 32bits) have a "natural" LSB of zero for addressing. However, since pointer objects are 32bit aligned, there is an UNUSED(!) bit pattern even if we leave small integers alone: xxxxxxxx00 -> object pointer (tag bit not set; divisible by four) xxxxxxxx10 -> Unused (tag bit not set; but not a valid pointer) xxxxxxxx01 -> SmallInteger (tag bit set) xxxxxxxx11 -> SmallInteger (tag bit set) So what one could do is to use that formerly unused bit pattern for "something different". But wait! Unfortunately, the bit pattern is not-so-unused after all; the garbage collector makes use of it (see the definition of HeaderTypeGC in ObjectMemory) to flag objects that are currently being marked. This needs to be fixed before the bit pattern can be used and I'll leave that as an exercise for the interested reader because it's a strict prerequisite for anything that follows below and can be done independently (HINT: A cheap way out -and yes, there are others- is to relocate that bit; most people are likely just as happy with half of the addressable memory). Once the GC usage of that flag is fixed we can decide what to do with the pattern. But given that we only have a single bit it's probably worthwhile to get a little bit more out of it than just one type. So instead of declaring "yet another immediate", I say let's use another 6bit to index into an array(!) of immediate classes (very much like compact classes) and use the 24 remaining bits to represent the actual value (and note that you can obviously adjust that number for different trade offs of number of immediate class vs. bits of accuracy). Then you need primitives that convert back and forth between a small integer and one of those immediates but that's about it. IIRC (it's been a while since I looked at it) those are the issues that you'd have to deal with. There are some more nice things about this particular scheme beside preserving small int bit range btw; for example, class lookup can test the low order two bits and if non-zero index into a 256 element array (with the odd slots filled with SmallInteger) so that there is no additional overhead for fetching the class of an object. Whether 24 bits are useful is another good question though; there are certainly some places that could use them since you can also split 24 bits into 2x12 (immediate points) and 3x8 (immediate colors) or 4x6 (dunno what you'd use that for though ;-) So the bottom line is that, yes, while it is hard to add new immediate types, it is far from impossible - it's a goodly amount of work and (the way I look at it) not worth doing it for just a *single* new immediate type; but being able to have up to 64 immediate types just *may* be worth it. In any case, I think that if anyone is interested in this issue the best way to go about it is to fix the usage of that xx10 bit pattern in the garbage collector and take it from there. Good Luck! Cheers, - Andreas Joerg Beekmann wrote: > Can anyone comment on how much work would be involved in > 1) Adding a new 32bit field to the object header > 2) Adding a new immediate type like integer, presumable by adding > another tag bit. > > I'm just looking for a very rough estimate. Do these tasks involve > tracking down a bunch of constants and then rebuilding everything, > tedious but a with a known path to follow. Or will this involve much more. > > regards Joerg >

1 0

[ANN] Gentoo and Squeak
by Brent Pinkney 21 Dec '05

21 Dec '05

Hi, The following Gentoo ebuilds exist dev-lang/squeak dev-lang/squeak-basicimage dev-lang/squeak-fullimage Unfortunately, they are for 3.6 and do not seem to be maintained. I have updated these to the latested 3.7.7 VM and the final 3.8 images from uiuc. The currently exist in my portage overllat only. Does anyone else a) care b) know how to get these updated in Gentoo. Cheers Brent

1 0

Slang - self primitive: parameters:
by Brad Fuller 14 Dec '05

14 Dec '05

Hello all, I'm trying to generate a 'ulong' in Slang using the "self primitive: parameters:" method. self primitive: 'primitivePutOutputParms' parameters: #(#SmallInteger #SmallInteger #Unsigned #Float #String). But, I don't know how. #Float generates a double and SmallInteger generates "int". What are the other ones? Is this a dictionary? When I use #Unsigned it generates: int parm2; interpreterProxy->success(interpreterProxy->isKindOf(interpreterProxy->stackValue(2), "Unsigned")); parm2 = interpreterProxy->stackValue(2); which I don't think I want, do I? Also, does anyone know how to generate void pointer?: (void *)? brad

3 5

State of support code vs. VMMaker version
by Andreas Raab 11 Dec '05

11 Dec '05

Hi Guys, I was just trying to catch up with various of the later VMMaker and support code versions only to find that there seem to be some serious mismatches between what's in VMMaker and the support code. I'm not sure if I'm missing something here (quite possible) but I'm curious if anyone has been using the latest versions at all. Here are some of the issues I encountered: * Use of "squeakInt64": The (now obsolete) type "squeakInt64" is still being used by some primitives in Interpreter (mostly the 64bit accessors). Shouldn't these be changed to sqLong? * fptr/dispatchOn:in: etc: Apparently, these definitions have been removed from sq.h and are nowhere in the platform tree. What happened here? Did the fptr definition go away (in which case where do I get an appropriate VMMaker version?) or should it live in another file (which one?) * sqVirtualMachine undefined references: When linking, the linker complains about undefined references to "getThisSessionID", "obsoleteDontUseThisFetchWordofObject", and "fetchLong32ofObject". Why are these methods *neither* defined in ObjectMemory/Interpreter *nor* in InterpreterProxy? (I checked this both with VMMaker 3.8b3 and 3.8b4) How is this supposed to work at all? * Redefinitions of byteAt/longAt/longAtput: It seems like these are now all defined in sqMemAccess.h and should be removed from the boiler-plate definitions of the plugins. * Redefinition of "self flag:" in LargeIntPlugin: It seems that this is now defined both in an include file as well as specifically in LargeIntegers plugin. One needs to go away. In any case, it does appear as if there's a significant mismatch between the support code and the available VMMaker version (3.8b3/3.8b4). I'd greatly appreciate if somebody could tell me what I'm missing here. Cheers, - Andreas

1 0

Plugins and Platforms
by Bert Freudenberg 25 Nov '05

25 Nov '05

Hi folks, when writing a plugin in Slang I encountered two problems wrt platform specifics: 1) convert a squeak pathname to a platform pathname: * my plugin links to a library that expects a platform file path * must convert from Squeak path (char encoding etc.) * sqFilenameFromString() should do this * PROBLEM: this does not work in an external plugin * because it is just a macro pointing to some platform-code function that would have to be linked to the external plugin * PROPOSAL: provide an ioFilenameFromString() function exported from the VM * looked up by plugin via interpreterProxy->ioLoadFunctionFrom ("ioFilenameFromString", "") * could trivially be implemented by using sqFilenameFromString macro? 2) endianness: * I need to know the current platform's endianness * because the linked library provides 8 bit bitmap data in platform order * and I want to adjust the Squeak form from the plugin (set depth to -8 on little-endian machine) * PROBLEM: which function/macro to use? * there seem to be several: - LSB_FIRST used in B3DAcceleratorPlugin.c - MSB_FIRST used in sqWin32Window.c - WORDS_BIGENDIAN defined on Mac OS and Unix - is this the one? thanks, - Bert -

3 2

Cross-platform floating point behavior
by Andreas Raab 22 Nov '05

22 Nov '05

Hi Folks, I had quite a bit of fun with trying to achieve bit-identical floating point behavior across platforms for Croquet. Turns out our claim about "bit identical" behavior is not so bit-identical when it comes to floating point after all. Reading up on IEEE754 and some of the more interesting fpu options like extended internal fpu accuracy or fused multiply-add (all of which are "consistent" with IEEE754 although delivering different results) I have found a wonderful little library (http://www.netlib.org/fdlibm/) which deals very well with these issues. Using it, I have been able to get truly bit-identical results between x87 and PPC and I think it likely that other architectures (Sparc, Arm, Mips) can be made to work with this library as well. Which raises an interesting question: Should we change the VM so that by default we *always* use that library? It would mean replacing our boiler-plate #include<math.h> by an #include<fdlibm.h> and having to link everything (both the VM as well as external plugins if needed) with the library, the cost of which is somewhere in the 60kbytes range. Together with a few platform specific tweaks (like setting the default accuracy on x87 to 53 bits mantissa, or disabling fused-madd on PPC) it *should* make floating point behave perfectly bit-identically across platforms. A word about the runtime efficiency: The overhead seems to be fairly acceptable for the most common uses. Using the primitives, I have been unable to measure noticable differences between the current primitives and the fdlibm primitives *except* for the implementation of sqrt(x) which appears to be significantly faster in hardware. However, both on x87 and PPC it turns out that the results are bit-identical both across the architectures as well as in comparison to fdlibm. And that in turn means we can use the hardware sqrt directly. Note that none of the other implementations give identical results; in particular when it comes to boundary or extreme cases (like huge exponents) the results can *vastly* differ - up to the point that x87 will tell you that sin(1.0e100) is NaN which obviously ridiculous. fdlibm computes this to -0.38 and I have no idea if that's to be considered "correct" but at least we get consistent results across the various platforms. What do you think? It is worth using fdlibm generally instead of -lm? Cheers, - Andreas PS. If somebody has access to Sparc/Mips/Arm I would be interested to see how they behave.

3 2

External Plugin returning too quickly
by Brad Fuller 21 Nov '05

21 Nov '05

The plugin that I'm creating seems to return too quickly. I have a simple test that plays a sine wave and waits 5 seconds (using usleep). The problem is that it stops the sine wave and returns in about a half a second (I hear the sine wave but just a blip. And no errors from the external code.) The code works fine outside of Squeak, but not called from Squeak. The plugin does 2 simple things: * Starts a stream that calls a callback routine (below) * The callback fills a buffer for the sine wave data and then returns After waiting 5secs, the main line cleans up and exits. Are there any particular issues with callbacks in Squeak? Do I need to compile/link with anything special? It doesn't seem like this should be a problem since Squeak is single-threaded. If anything, I would think that the return would be slower not quicker. BTW, usleep returns w/o error. Any ideas or pointers much appreciated! brad -- Brad Fuller (408) 799-6124 ** Sonaural Audio Studios ** (408) 799-6123 West San Jose (408) 799-6124 Cambrian ________________________________ Hear us online: www.Sonaural.com See me on O'Reilly: http://www.oreillynet.com/pub/au/2184

3 5

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev