Vm-dev October 2007

vm-dev@lists.squeakfoundation.org

23 participants
17 discussions

Profiling and delay accuracy
by Andreas Raab 06 Aug '11

06 Aug '11

Hi Folks - For a long time now I had this feeling that MessageTally reports pretty bogus results in many situations without being able to precisely track down why this would be the case. Today I was looking at primitiveResponse() and, much to my surprise, noticed that the checkForInterrupts() that used to be there for years is gone (see Squeak3.6 for example which still has it). The sole reason for this check was to get both high delay accuracy and good profiling behavior. Consider this example: fc := FormCanvas on: Display. MessageTally spyOn:[ 1 to: 100 do:[:i| fc fillColor: Color white. fc printString. ]. ]. Using 3.6 this will be measured correctly as: **Tree** 87.5% {243ms} FormCanvas>>fillColor: |87.5% {243ms} GrafPort>>fillRect:offset: | 87.5% {243ms} GrafPort>>copyBits 12.5% {35ms} FormCanvas(Object)>>printString 12.5% {35ms} FormCanvas(Object)>>printStringLimitedTo: whereas the 3.10 reports it as **Tree** 99.6% {670ms} FormCanvas(Object)>>printString 94.9% {639ms} primitives 4.6% {31ms} FormCanvas(Object)>>printStringLimitedTo: I think you can see the problem and just imagine what this does to any cumulative results. I also wonder what that change does to platforms that don't have high-resolution asynchronous timers. This used to be the one place where we would catch timer changes at high resolution and unless the platform forces high resolution timer interrupts asynchronously (by resetting the interrupt counter) we must be loosing a lot in terms of delay accuracy. (it just so happens that the Windows VM *does* do asynchronous timer interrupts so I never noticed this but I'm very curious about the difference on Linux which typically still has pretty bad timer granularity). Any opinions? My feeling is that the timer check should go back in for all of the above reasons. At the very least a quickCheckForInterrupt() is required but I actually think putting the full check back in is worth it. Cheers, - Andreas

3 3

Joys of Squeak-dev image, VM Compiling on MacIntel and Spoon remote OtherBrowsing
by Ken G. Brown 16 Nov '10

16 Nov '10

MacPro OS X 10.4.9 Xcode 2.4.1 Squeak-dev-114-2, VMMaker 2.8b6.1, Squeak 3.8.15beta6U.app, and version 1657 of svn MacOS VM sources, and Spoon v2a12. Downloaded http://www.squeakvm.org/cgi-bin/viewcvs.cgi/ trunk version 1657 for MacOS Ran squeak-dev-beta-114-2.image on Squeak 3.8.15beta6U.app Loaded VMMaker 3.8b6.1 from dev image Universes. Generated vm sources by following instructions in <http://www.squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/Mac%20OS/vm/Doc…> Fought with Xcode wanting to use MacOSX10.3.9.sdk for ppc which was giving an error which was known and documented in the Readme. Finally figured out what Xcode wanted so built universal app just using 10.4.9 sdk. Couple issues: Exupery references remain in sqnamedPrims.h and sqPlatformSpecific.h from svn version 1657, I just commented them out. Notes said: Info-NPSqueak__Upgraded_.plist was to be found in the Developer directory. I could not find it so scammed a info.plist out of John's Squeak 3.8.15beta6U.app vm. Not sure what impact this has. And much, much diddling about figuring out various things... Finally got a build. It's a lot smaller (3.9MB) than John McIntosh's Squeak 3.8.15beta6U.app (8.1MB), and it looks like it is a PowerPC one but at least it runs. I'll look into the Xcode build process some more. Then: Replaced interp.c with Craig's interp.c for Spoon, rebuilt and got a VM with Spoon client stuff. Downloaded Spoon release 2a12. Moved a copy of Flow plugin from within Craig's naiad.app package into a plugins subdirectory where the new spoon client compatible MacIntel universal VM was run from. Followed Craig's Spoon instructions for loading niaid.st and niaid.pr into the 3.10 image (Squeak-dev-114-2) running on the new VM. Did the run spoon.app thing from Spoon.dmg (version 2a12), needs to be done twice if Safari is not running. Got Spoon processor running. Followed instructions again in the Spoon client and lo! Got OtherBrowser browsing the Spoon memory running on processor. Yay Craig! Who do i get to sign my certificate? :) Ken

4 7

patch: new sound driver for Solaris
by Andrew Gaylard 29 Nov '07

29 Nov '07

> > The new driver files are attached. Since the changes are > widespread, I have not made patches (but will on request). > Can someone please check the sqUnixSoundSun.c file > into SVN (assuming it's OK)? I have included the other file, > sqUnixSoundSun-select.c, for comparison only. > Sorry, I forgot to turn on compiler warnings and fix them. (I also forgot to update the subject line. It's late...) This is a cleaned-up version of the new driver. Andrew

2 2

64bit: "This interpreter (vers. 68000) cannot read image file (vers. 274877913446)."
by John Thornborrow 05 Nov '07

05 Nov '07

Hello all, This is my first message to this list. I have compiled a 64bit VM for my Gentoo 64bit Intel Core2Duo machine, and I receive the message "This interpreter (vers. 68000) cannot read image file (vers. 274877913446)." for any image I try to run. I'm unable to identify a cause/solution; can anyone help? Apologies if this is a question asked very frequently. John www.pinesoft.co.uk Pinesoft Computers are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

9 22

Sound driver "plays" silence
by Andrew Gaylard 01 Nov '07

01 Nov '07

In my message, archived here http://lists.squeakfoundation.org/pipermail/vm-dev/2007-October/001595.html I mentioned that it seems that once a sound has played, the image keeps sending silence to the sound device. This keeps the CPU quite busy, as seen both by the OS (load average) and the interpreter (slower benchmarks). I've had a little more time to dig into this, and it seems this is expected behaviour: it is toggled by the "soundStopWhenDone" preference, and read in SoundPlayer>>playLoop. It seems that this is off by default (i.e. sound never really stops, once started). Switching it to "on" solved my problem. So now I'm curious. Why was it built this way? And why do released images have this preference off? For most modern hardware, this isn't an issue, but for slower hardware (e.g. mine), or for power-lean systems (e.g. the OLPC) I think it could be. Andrew

3 2

64-bit FAQ
by Andrew Gaylard 29 Oct '07

29 Oct '07

Hello VM developers, I've taken the detailed input on this subject that's been posted to the list so far, and turned it into a FAQ for posting either to squeakvm.org or the swiki. Please check my facts (and grammar, and wording, ...) one last time. Thanks, Andrew Squeak 64-bit VM and image FAQ 1. What is a 32-bit image? 2. What is a 64-bit image? 3. Can I run a 32-bit image on my 64-bit computer? 4. Can I run a 64-bit image on my 32-bit computer? 5. Can a single VM run both 32-bit and 64-bit images? 6. What is a 64-bit VM? 7. Can I run a 32- or 64-bit VM on my computer? 8. For which hardware/OS combinations is there a 64-bit VM? 9. Does this VM run both 32-bit and 64-bit images? 10. I have a 64-bit computer; should I use a 64-bit VM to run my 32-bit Squeak images? 11. What are the advantages of using 64-bits? 12. What are the disadvantages of using 64-bits? 13. My OS allows a single process to grow to 3.75GB; if I need a lot of objects can I use a 32-bit image / VM, or must I use a 64-bit one? 14. Where can I find a 64-bit image? 15. Why isn't there an officially-released 64-bit image? 16. How can I make a 64-bit image from a 32-bit image? 17. How does a 32-bit VM manage to run a 64-bit image if pointers are only 32-bits wide? 18. What sizes and alignment does the new 64-bit image format use for pointers and integers? 19. How do I tell if a given image file is 32-bit or 64-bit? 1/ What is a 32-bit image? - A 32-bit image is an image in which the object memory uses a 32-bit word size for object pointers, limiting its total size to a maximum amount of 4GB of memory. The formats of object memory and object pointers are defined in class ObjectMemory (see the class comment for a basic explanation). As of this writing, all Squeak images of practical interest are 32-bit images. 2/ What is a 64-bit image? - A 64-bit image is an image in which the object memory uses a 64-bit word size for object pointers, allowing the size of the image to grow beyond 4GB of memory. Squeak now supports a 64-bit image format that is sufficient to produce a working system, but which is intentionally simple. It is expected to be modified and extended to take advantage of additional 64-bit capabilities in the future. 3/ Can I run a 32-bit image on my 64-bit computer? - Yes. A 32-bit image can be run on either a 32-bit VM or a 64-bit VM. Some computer platforms (e.g. 64-bit Linux) can run both the 32-bit VM and 64-bit VM on the same system. 4/ Can I run a 64-bit image on my 32-bit computer? - Yes. If you build a VM with the "64-bit VM?" check box selected, you will create a VM that runs 64-bit images. This will work on 32-bit host systems as well as on 64-bit host systems. 5/ Can a single VM run both 32-bit and 64-bit images? - No. For any given computer platform, two different VMs are required to run 32-bit and 64-bit images. The type of VM that you build is governed by the "64-bit VM?" check box in VMMaker, and is independent of the word size of your computer. While it would be possible to create a VM that is "smart" enough to run both 32-bit and 64-bit images, this is currently of little practical value due to Squeak's reliance on plugins that are linked to 32-bit or 64 external library code. Any combination of 32/64 bit VM and 32/64-bit image is possible, but note that all currently available Squeak images are still in 32-bit format, and most (perhaps all) pre-built VMs are 32-bit applications. 6/ What is a 64-bit VM? - A 64-bit VM is one which is compiled with the LP64 or ILP64 data model. This means, in C terms, that pointers and longs are 64-bits wide. 7/ Can I run a 32- or 64-bit VM on my computer? - It depends. Some current architectures, such as the x86-64 and the UltraSPARC, can run 32-bit as well as 64-bit applications; these are known as "bi-arch" systems. However, some systems, such as the Alpha, can only run 64-bit applications. For bi-arch systems, you can choose whether to run a 32-bit or 64-bit VM. For 64-bit-only systems, you don't have that choice; you can only run a 64-bit VM, since there's no way of compiling a 32-bit application. 8/ For which hardware/OS combinations is there a 64-bit VM? - Linux on 64-bit architectures: x86-64, SPARC64, Alpha, Power64, etc. - Solaris on x86-64 and SPARC64 - MacOS on Power64 - Windows on x86-64 9/ Does my 64-bit VM run both 32-bit and 64-bit images? - All VMs can run both 32-bit and 64-bit images, but this selection needs to be made at compile time. See question 5. 10/ I have a 64-bit computer; should I use a 64-bit VM to run my 32-bit Squeak images? - It depends. Either one will work, but if your image depends on plugins that are only available for 32-bit systems, use the 32-bit VM. Otherwise, if you are building your own VM, go ahead and use the 64-bit version. 11/ What are the advantages of using 64-bits? - The first advantage is that your image size can be enormous. If you need the size of your VM code plus in-memory image to exceed 4 GB, then a 64-bit image running on a 64-bit VM is for you. Note that it will take ages to write out an image that's this big to disk. The sort of applications that need this are those which load a small(ish) image, and run code that creates millions of objects, but don't save them back to disk in the image. Keep in mind that the garbage collector is probably not up to the task of collecting multiple gigabytes. - Another advantage is that certain architectures (e.g. the Alpha) don't offer a 32-bit mode; they are 64-bit only. For such machines, a 64-bit VM is required; the image may be 32- or 64-bit. - Another advantage is that when the 64-bit-VM is built, the C compiler knows the ABI is different from the 32-bit ABI. The x86-64 case is an interesting example: the old i386 ABI offered few registers, used i387 floating-point, and passed parameters on the stack (remember, memory writes are slower than register moves). The x86-64 ABI and architecture, on the other hand, has many more registers, has SSE, SSE2, etc. for FP, and passes parameters in registers where possible. It also has additional instructions (MMX et al). All of these CPU and ABI features may make for a VM that runs faster, but only if (a) the compiler is able to make use of them and (b) is told to do so at compile-time. However, the gains are unlikely to be much, and will also be offset by the cost of large pointers (see below). If you're looking for performance, it's important to measure a 32-bit VM with a 32-bit image versus a 64-bit VM with a 64-bit image before assuming anything. 12/ What are the disadvantages to using 64-bits? - A disadvantage to 64-bit code is that pointers are 8 bytes instead of 4; they are also aligned on 8-byte boundaries, meaning that some space around them, known as `padding', is wasted. This means that (a) pointers take more space in RAM, (b) take more memory bandwidth when the CPU loads and stores them, (c) take up valuable space in on-chip caches, and (d) will have greater wastage due to padding compared to 32-bit pointers aligned on 4-byte boundaries. For most users, the upper 32-bits of each pointer will always be zero, so it makes little sense to load, process and store pointers that are double the size but only half-used. So for these users, a 32-bit VM and image is a good choice. - Another disadvantage is that most users use the 32-bit VM and a 32-bit image. This combination is therefore the most tested, and therefore most stable, combination. - A third disadvantage is that code for many of the plugins is not yet ported to a 64-bit VM. 13/ My OS allows a single process to grow to 3.75GB; if I need a lot of objects can I use a 32-bit image / VM, or must I use a 64-bit one? - There have in the past been problems related to the so-called "2-GB limit". This is due to conversion to and from signed 32-bit integers to 32-bit pointers in the VM code. These problems appeared when the operating system loaded the image into memory at addresses above the 2GB mark, and could occur with normal-sized images, not only images larger than 2GB. These issues should be a thing of the past. Use the most recently-released VM for your platform, and report any problems that you see. You should only *need* a 64-bit VM and 64-bit image if your image size will exceed 4GB. 14/ Where can I find a 64-bit image? - These are scarce. The original 64-bit port project (from Ian and Dan) includes a 64-bit image that worked with the VM distributed at that time. A current VM cannot execute the original 64-bit image due to changes in the interpreter since that time. It is possible to update that original image using a modified VM, and the resulting image is executable using a current unmodified VM. However, there are no official or supported releases of 64-bit images at this time. 15/ Why isn't there an officially-released 64-bit image? - Lack of interest: most people don't need a 64-bit image. - There may yet be some changes to the 64-bit image format to take advantage of features of 64-bit CPUs. For instance, 63-bit tagged integers might be possible. 16/ How can I make a 64-bit image from a 32-bit image? - Use the SystemTracer (SystemTracerV2 on SqueakMap). The original 64-bit Squeak image was created using this tool, and a sufficiently motivated person should be able to reproduce the job. However, the SystemTracer does not currently work on little-endian computers (including Intel), so some work should be expected in order to enhance SystemTracer before a successful conversion will be possible. 17/ How does a 32-bit VM manage to run a 64-bit image if pointers are 32-bits? - The short answer: It relies on the image size being smaller than 4GB. - The long answer: Object pointers within the object memory are not pointers in the C sense of the word. The VM needs to be able to convert the object pointers into C pointers, and this can be done on either a 32-bit host or a 64 bit host. The only caveat would be that if a 64-bit image grew to a size large enough to use object pointers larger than the 32-bit limit (i.e. an image approaching 4GB in size), then a 64-bit VM would be required. 18/ What sizes and alignment does the new 64-bit image format use for pointers and integers? - Object pointers are 64-bits wide, allowing for memory up to 2^64 bytes to be directly addressable. They are aligned on 8-byte boundaries. Integers are still implemented as tagged 31-bit values. They are aligned to 4-byte boundaries. These alignments were chosen as most 64-bit CPUs require them. - The object header and pointer formats for both 32-bit and 64-bit images are documented in the class comment of ObjectMemory (in the VMMaker package). The conversions to and from host data types are done in platforms/Cross/vm/sqMemoryAccess.h using either macros or inline functions. The actual conversions vary from host to host, and are controlled by macros such as SQ_HOST64 and SQ_IMAGE32 which must be set for that host. In the case of a Unix VM, the configure utility is used to specify the characteristics of the host platform. - The word size to be used in the object memory is specified by the SQ_VI_BYTES_PER_WORD macro on src/vm/interp.h. This file is created in the VMMaker code generation process, and the value of SQ_VI_BYTES_PER_WORD is determined by the "64-bit VM?" check box in the VMMaker tool. - In summary, the object word format is described in class ObjectMemory, the host data type conversions are specified in sqMemoryAccess.h, and the image word size is specified in interp.h. 19/ How do I tell if a given image file is 32-bit or 64-bit? - The first four bytes in the image file are a "magic" value that indicates the image word size. This is specified in Interpreter>>imageFormatVersion. For most images, this will be the first four bytes of the image file, although in some cases the image data may be offset by 512 bytes in order to permit an image file to be treated as an executable program on Unix platforms (see http://en.wikipedia.org/wiki/Shebang_(Unix)). For instance, if I load VMMaker-3.8b6 into a stock Squeak3.9a-7024.image file, I see this: imageFormatVersion "Return a magic constant that changes when the image format changes. Since the image reading code uses this to detect byte ordering, one must avoid version numbers that are invariant under byte reversal." BytesPerWord == 4 ifTrue: [^6502] ifFalse: [^68000] Examining the file itself gives this: apg@breakfast: ~/squeak xxd Squeak3.9a-7024.image | head -1 0000000: 0000 1966 0000 0040 011c 7ee0 0427 b000 ...f...@..~..'.. Looking at the first four bytes gives this: apg@breakfast: ~/squeak perl -e 'print 0x1966' 6502 (or do "16r1966 <Alt-P>" in a workspace; it also returns 6502.) So Squeak3.9a-7024.image is a 32-bit image file (since BytesPerWord == 4).

7 9

Pypy-Squeak VM generation news
by Adrian Kuhn 26 Oct '07

26 Oct '07

Dear all, today started the PyPy-Squeak sprint in Bern, with the bold goal of using PyPy the generate a Squeak VM. A sprint is one week of full- time hacking. If you are interested in daily progress reports, please refer to http://pypysqueak.blogspot.com/ cheers, AA

6 15

Any patch for InterpreterSimulator
by Rob Withers 25 Oct '07

25 Oct '07

My first post on this list, and it may not be my last. I am trying to run the InterpreterSimulator adn am having issues. Mathieu Suen mentioned this list and that there may be a patch for it. Does anyone know of a patch? My current issue is: In postGCAction, the gcSemaphoreIndex is nil, which blows up in signalSemaphoreWithIndex:. Trying to be a bit more self sufficient, I put a halt in primitiveSetGCSemaphore and reran it, but it never breaks, so it never seems to get set. Full stop. thank you, Rob

3 5

Re: [Vm-dev] Any patch for InterpreterSimulator
by Rob Withers 25 Oct '07

25 Oct '07

Here's the top of the stack when this file plugin problem happens. It really looks like some changes have occurred in the image and the Simulator hasn't cought up yet. For instance using ByteSymbol instead of Symbol. I'll do what I can to bring this current. 12814BC StandardFileStream>>#basicNext args: temps: 04 stack: 1281394 UTF8TextConverter>>#nextFromStream: args: 1280688 temps: 04 04 04 04 04 04 04 04 04 stack: 12811EC MultiByteFileStream>>#next args: temps: 04 04 04 stack: 1281190 MultiByteFileStream>>#next: args: 191 temps: 12813F0 03 04 stack: 1268024 FileDirectory class>>#openSources:andChanges:forImage: args: 12687A8 1268BF4 10FB194 temps: 127B3B0 1280688 CA19FC CA1A78 stack: ----- Original Message ----- From: "Rob Withers" <reefedjib(a)yahoo.com> To: <johnmci(a)smalltalkconsulting.com>; "Squeak Virtual Machine Development Discussion" <vm-dev(a)lists.squeakfoundation.org> Sent: Wednesday, October 24, 2007 10:17 PM Subject: Re: [Vm-dev] Any patch for InterpreterSimulator > Thanks, John. I fixed this in ObjectMemory>>#initializeObjectMemory:, > since I figured it belonged there more than in the Interpreter. On > running further, I also had to add fixes to the following, all switching > from Smalltalk to SmalltalkImage current: > InterpreterSimulator>>#primitiveGetAttribute > InterpreterSimulator>>#vmPathGet:Length: > InterpreterSimulator>>#vmPathSize > > Then I hit FilePluginSimulator>>#primitiveFileRead. This gets its file > from: > file := self fileValueOf: (interpreterProxy stackValue: 3). > where the stackValue is 20, which is not an integer object and the file is > nil. It's beyond me. > > How can I report these to Mantis. Is there a website for it? > > Cheers, > Rob > > ----- Original Message ----- > From: "John M McIntosh" <johnmci(a)smalltalkconsulting.com> > To: "Squeak Virtual Machine Development Discussion" > <vm-dev(a)lists.squeakfoundation.org> > Sent: Wednesday, October 24, 2007 7:20 PM > Subject: Re: [Vm-dev] Any patch for InterpreterSimulator > > >> >> >* primitiveSetGCSemaphore: Indicates a semaphore (index) to be >> signaled whenever a garbage collection occurs. >> >> it should have a value of zero if it's not used. Obviously in C that's >> zero by the magic of auto-initialization of that C variable, and so the >> code runs without care, but in Smalltalk it's nil and you die. >> >> I'd make a mantis report and supply a patch to initialize the value >> explicitly in the interpreter startup code initializeInterpreter: so >> that the simulator will run. >> >> >> On Oct 24, 2007, at 7:09 PM, Rob Withers wrote: >> >>> My first post on this list, and it may not be my last. I am trying to >>> run the InterpreterSimulator adn am having issues. Mathieu Suen >>> mentioned this list and that there may be a patch for it. Does anyone >>> know of a patch? >>> >>> My current issue is: In postGCAction, the gcSemaphoreIndex is nil, >>> which blows up in signalSemaphoreWithIndex:. Trying to be a bit more >>> self >>> sufficient, I put a halt in primitiveSetGCSemaphore and reran it, but >>> it >>> never breaks, so it never seems to get set. Full stop. >>> >>> thank you, >>> Rob >> >> -- >> ======================================================================== >> === >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> ======================================================================== >> === >> >> >> >

1 0

patch: fix build problems on Solaris [resend]
by Andrew Gaylard 13 Oct '07

13 Oct '07

[Note: I'm resending this message because it seems the server filtered it. My apologies if you have already seen it.] On 9/27/07, Andrew Gaylard <ag(a)computer.org> wrote: > > > When I send a sound, it plays fine, but when I signal the semaphore > that output has completed, the VM keeps writing more and more stuff to > the sound device. I assume that it's writing "silence", since I hear > nothing after the initial sound. But it does keep the CPU quite busy > as you might imagine. > > I have instrumented the C code where the VM checks for I/O (aioPoll), > and under ordinary usage (keyboard, mouse, etc.) I get under 20 > polls/second. As soon as a sound has started playing, this jumps > to 2300+ polls/second, and stays there, even when the sound is > played and silence reigns. > > I can't figure out why it would do this. > > Clearly, since the buffer is large enough to contain only a fraction > of a second of audio data, the semaphore is needed to tell the VM > to send some more data. And clearly the select() call in aioPoll will > notice the file-descriptor for /dev/audio is writable as soon as the > first sample is played, and continuously thereafter, so I can > understand that during playback the poll-rate should be high. This > problem should be fix-able by using the STREAMS SIGPOLL to > trigger the auHandle() function, rather than using select(). > > However, once the whole sound is played, why would the VM > continue playing nothing at full speed? Even with the SIGPOLL > handler in place -- I'm about to try it now -- the VM is still issuing > write() calls to /dev/audio several time per second, indefinitely. > > I'm sure I'm missing something here... > OK, I've done some more digging into this problem, and have implemented the SIGPOLL-based scheme. This works as well as the select()-based scheme of Wolfgang Helbig; i.e. there's no discernible difference in the sound quality. The problem with the VM playing silence at full speed once the first sound has played, remains. I'm not sure what to do about this, as I am fairly sure it is not a driver issue. Here are some figures showing the performance: (a) Newly-started VM, idle for 60s 1-minute load-average: 0.22 '23633677 bytecodes/sec; 990806 sends/sec' (b) select driver, 60s after playing a 1-second-long sound 1-minute load-average: 1.14 '21932830 bytecodes/sec; 899000 sends/sec' (c) sigpoll driver, 60s after playing a 1-second-long sound 1-minute load-average: 0.62 '21592442 bytecodes/sec; 911752 sends/sec' Clearly, the writes to /dev/audio keep the squeak process busy in both cases (b) and (c). Case (b) has the added disadvantage of spending a great deal of time in select calls. For reference, my system details are: - Sun SPARC Ultra-60, 2x400MHz CPUs - Squeak SVN tree r1749 - unchanged etoys image, files dated September 7, 2005 - gcc-3.4.3 The new driver files are not attached. Since the changes are widespread, I have not made patches (but will on request). The file can be found in the mailing list archives from the first time I tried to send this message, at http://lists.squeakfoundation.org/pipermail/vm-dev/2007-October/001577.html Can someone please check the sqUnixSoundSun.c file into SVN (assuming it's OK)? I have included the other file, sqUnixSoundSun-select.c, for comparison only. Thanks, Andrew

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev October 2007