Updates to the platforms code and VMMaker are needed to make SoundPlugin work on 64-bit platforms. This is a coordinated change affecting all platforms.
I'm not sure of folks' schedules right now, so Ian, John, Andreas - are you available to do the updates over say the next two weeks or so?
The following steps are required:
Dave: - Update SoundPlugin in VMMaker with patches from Mantis 7103.
Ian: - Update platforms/Cross and platforms/unix. The diffs on Mantis 7103 are slightly out of date, so I am attaching a fresh copy of the affected files (M7103-platforms.tgz). These are: platforms/Cross/plugins/SoundPlugin/SoundPlugin.h platforms/unix/plugins/SoundPlugin/sqUnixSound.c platforms/unix/vm/SqSound.h platforms/unix/vm-sound-ALSA/sqUnixSoundALSA.c platforms/unix/vm-sound-NAS/sqUnixSoundNAS.c platforms/unix/vm-sound-Sun/sqUnixSoundSun.c platforms/unix/vm-sound-MacOSX/sqUnixSoundMacOSX.c platforms/unix/vm-sound-null/sqUnixSoundNull.c platforms/unix/vm-sound-OSS/sqUnixSoundOSS.c
Andreas: - Update platforms/win32/plugins/SoundPlugin/sqWin32Sound.c to match the new declarations in SoundPlugin.h. I believe this will involve only changing various int declarations to the appropriate sqInt or (void *) declarations, then testing to make sure sound still works. However, I have not tried a windows build to verify this.
John: - Update the files in platforms/Mac OS/plugins/SoundPlugin/ with declarations to match SoundPlugin.h in Cross. I'm not sure what needs to be done here, although I think that current OS X support is based on the unix SoundPlugin, so you may be able to use the update in platforms/unix. - I'm not sure of the implications (if any) for your new VM work or for iPhone.
Dave
--- background ---
For reference this was the suggested "to-do" list that I posted a while back. These updates will complete step #2 on the list. Note, with John's recent 64-bit work and new VM development, we will no doubt have a few new items to add to the list :)
1) Closure support (COMPLETE) - Priority: High, should be done as soon as possible - All major VM distributions should support images with closure bytecodes.
2) Changes to support Etoys and teaching for kids. - Priority: High, supports large educational programs. - Mantis 7266: SerialPlugin doesn't handle arbitrary nodes names (COMPLETE) - Mantis 7103: Playing sounds in linux 64 bits causes a vm segmentation fault (subject of this note - NEXT UP on the list)
3) Some simple updates for 23/64 bit platforms. - Priority: Low - Mantis 7236: Make AsynchFilePlugin work on 32/64 bit images and 32/64 bit unix VMs - Mantis 6828: make FileCopyPlugin work on 32/64 bit images and 32/64 bit unix VMs - Current status: These are minor updates, low priority but easy to do. Patches are available but must be coordinated for all platforms.
4) 64-bit FFI (Interpreter updates as well as FFI) - Priority: Medium - Mantis 7237: Make FFI work on 64 bit platforms - Current status: Patches are available, but additional work and testing may be required on some platforms. I consider this update important because it effects the interpreter as well as FFI itself, e.g. these changes are a prerequisite to closing out the issues in Mantis 6987: "signed32BitValueOf:, signed64BitValueOf: etc. broken".
Ok, next week I'm somewhat on vacation but was planning to review the 64bit changes I have. Some of which are sound related.
I would also like to push the iphone/64 bit work into the squeakvm svn. I'll need to restructure the isqueak svn a bit first to take it back to the original vmmaker tree structure and to "obsolete" the older macintosh VM files into a subdirectory.
On 2009-12-29, at 11:09 AM, David T. Lewis wrote:
Updates to the platforms code and VMMaker are needed to make SoundPlugin work on 64-bit platforms. This is a coordinated change affecting all platforms.
I'm not sure of folks' schedules right now, so Ian, John, Andreas - are you available to do the updates over say the next two weeks or so?
The following steps are required:
Dave:
- Update SoundPlugin in VMMaker with patches from Mantis 7103.
Ian:
- Update platforms/Cross and platforms/unix. The diffs on Mantis 7103 are slightly out of date, so I am attaching a fresh copy of the affected files (M7103-platforms.tgz). These are: platforms/Cross/plugins/SoundPlugin/SoundPlugin.h platforms/unix/plugins/SoundPlugin/sqUnixSound.c platforms/unix/vm/SqSound.h platforms/unix/vm-sound-ALSA/sqUnixSoundALSA.c platforms/unix/vm-sound-NAS/sqUnixSoundNAS.c platforms/unix/vm-sound-Sun/sqUnixSoundSun.c platforms/unix/vm-sound-MacOSX/sqUnixSoundMacOSX.c platforms/unix/vm-sound-null/sqUnixSoundNull.c platforms/unix/vm-sound-OSS/sqUnixSoundOSS.c
Andreas:
- Update platforms/win32/plugins/SoundPlugin/sqWin32Sound.c to match the new declarations in SoundPlugin.h. I believe this will involve only changing various int declarations to the appropriate sqInt or (void *) declarations, then testing to make sure sound still works. However, I have not tried a windows build to verify this.
John:
- Update the files in platforms/Mac OS/plugins/SoundPlugin/ with declarations to match SoundPlugin.h in Cross. I'm not sure what needs to be done here, although I think that current OS X support is based on the unix SoundPlugin, so you may be able to use the update in platforms/unix.
- I'm not sure of the implications (if any) for your new VM work or for iPhone.
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
I have committed the 64-bit SoundPlugin updates to SqS/VMMaker.
Ian, John, Andreas: please proceed with platforms updates at your convenience (see below for details).
As a point of reference:
- Platforms sources in Subversion are currently at revision 2147.
- VMMaker version 3.11.11 (VMMaker-dtl.155) works with SVN 2147.
- The updated VMMaker is 3.11.12 (VMMaker-dtl.156). This will be out of sync with the SVN sources until the sound plugin platforms patches are applied.
Note to other VM builders: If you have compile errors building SoundPlugin, use VMMaker-dtl.155 or earlier until the necessary patches have been applied. See Mantis 7103 for background.
Thanks, Dave
On Tue, Dec 29, 2009 at 02:09:11PM -0500, David T. Lewis wrote:
Updates to the platforms code and VMMaker are needed to make SoundPlugin work on 64-bit platforms. This is a coordinated change affecting all platforms.
I'm not sure of folks' schedules right now, so Ian, John, Andreas - are you available to do the updates over say the next two weeks or so?
The following steps are required:
Dave:
- Update SoundPlugin in VMMaker with patches from Mantis 7103.
Ian:
- Update platforms/Cross and platforms/unix. The diffs on Mantis 7103 are slightly out of date, so I am attaching a fresh copy of the affected files (M7103-platforms.tgz). These are: platforms/Cross/plugins/SoundPlugin/SoundPlugin.h platforms/unix/plugins/SoundPlugin/sqUnixSound.c platforms/unix/vm/SqSound.h platforms/unix/vm-sound-ALSA/sqUnixSoundALSA.c platforms/unix/vm-sound-NAS/sqUnixSoundNAS.c platforms/unix/vm-sound-Sun/sqUnixSoundSun.c platforms/unix/vm-sound-MacOSX/sqUnixSoundMacOSX.c platforms/unix/vm-sound-null/sqUnixSoundNull.c platforms/unix/vm-sound-OSS/sqUnixSoundOSS.c
Andreas:
- Update platforms/win32/plugins/SoundPlugin/sqWin32Sound.c to match the new declarations in SoundPlugin.h. I believe this will involve only changing various int declarations to the appropriate sqInt or (void *) declarations, then testing to make sure sound still works. However, I have not tried a windows build to verify this.
John:
- Update the files in platforms/Mac OS/plugins/SoundPlugin/ with declarations to match SoundPlugin.h in Cross. I'm not sure what needs to be done here, although I think that current OS X support is based on the unix SoundPlugin, so you may be able to use the update in platforms/unix.
- I'm not sure of the implications (if any) for your new VM work or for iPhone.
Dave
--- background ---
For reference this was the suggested "to-do" list that I posted a while back. These updates will complete step #2 on the list. Note, with John's recent 64-bit work and new VM development, we will no doubt have a few new items to add to the list :)
- Closure support (COMPLETE)
- Priority: High, should be done as soon as possible
- All major VM distributions should support images with closure bytecodes.
- Changes to support Etoys and teaching for kids.
- Priority: High, supports large educational programs.
- Mantis 7266: SerialPlugin doesn't handle arbitrary nodes names (COMPLETE)
- Mantis 7103: Playing sounds in linux 64 bits causes a vm segmentation fault (subject of this note - NEXT UP on the list)
- Some simple updates for 23/64 bit platforms.
- Priority: Low
- Mantis 7236: Make AsynchFilePlugin work on 32/64 bit images and 32/64 bit unix VMs
- Mantis 6828: make FileCopyPlugin work on 32/64 bit images and 32/64 bit unix VMs
- Current status: These are minor updates, low priority but easy to do. Patches are available but must be coordinated for all platforms.
- 64-bit FFI (Interpreter updates as well as FFI)
- Priority: Medium
- Mantis 7237: Make FFI work on 64 bit platforms
- Current status: Patches are available, but additional work and testing may be required on some platforms. I consider this update important because it effects the interpreter as well as FFI itself, e.g. these changes are a prerequisite to closing out the issues in Mantis 6987: "signed32BitValueOf:, signed64BitValueOf: etc. broken".
Attached is a zip file of the header changes to common I've made in the last three months, plus some fixes for VMMaker.
If people could poke at them and discuss, that would be helpful.
My other notes say: REPlugin is broken Squeak3D is broken RePlugin is broken
sqInt readImageFromFileHeapSizeStartingAt(sqImageFile f, sqInt desiredHeapSize, squeakFileOffsetType imageOffset); should be sqInt readImageFromFileHeapSizeStartingAt(sqImageFile f, usqInt desiredHeapSize, squeakFileOffsetType imageOffset);
EXPORT(sqInt) dumpImage(sqInt fileName); should be EXPORT(sqInt) dumpImage(char * fileName);
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
2010/1/12 John M McIntosh johnmci@smalltalkconsulting.com:
Attached is a zip file of the header changes to common I've made in the last three months, plus some fixes for VMMaker.
If people could poke at them and discuss, that would be helpful.
My other notes say: REPlugin is broken Squeak3D is broken RePlugin is broken
sqInt readImageFromFileHeapSizeStartingAt(sqImageFile f, sqInt desiredHeapSize, squeakFileOffsetType imageOffset); should be sqInt readImageFromFileHeapSizeStartingAt(sqImageFile f, usqInt desiredHeapSize, squeakFileOffsetType imageOffset);
Btw, about that function. Its using a squeakFileOffsetType, which is platform specific, and i had hard times trying to deal with right header inclusion order imposing dependency of interpreter from platform code, which, IMO should be avoided. I propose to change it to typedef unsigned long long vmFileOffsetType; and use this type instead. While platform specific code could always coerce this type to own
squeakFileOffsetType offset = (squeakFileOffsetType) vmOffset;
EXPORT(sqInt) dumpImage(sqInt fileName); should be EXPORT(sqInt) dumpImage(char * fileName);
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Igor Stasenko wrote:
Btw, about that function. Its using a squeakFileOffsetType, which is platform specific, and i had hard times trying to deal with right header inclusion order imposing dependency of interpreter from platform code, which, IMO should be avoided. I propose to change it to typedef unsigned long long vmFileOffsetType; and use this type instead.
I'm not sure if MSVC supports long long nowadays. It didn't used to - it used to require __int64 which is why the definition of squeakFileOffsetType is external.
Cheers, - Andreas
2010/1/12 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
Btw, about that function. Its using a squeakFileOffsetType, which is platform specific, and i had hard times trying to deal with right header inclusion order imposing dependency of interpreter from platform code, which, IMO should be avoided. I propose to change it to typedef unsigned long long vmFileOffsetType; and use this type instead.
I'm not sure if MSVC supports long long nowadays. It didn't used to - it used to require __int64 which is why the definition of squeakFileOffsetType is external.
There should be an ANSI long long integer type. Afaik __int64 is platform/compiler specific.
Cheers, - Andreas
Igor Stasenko wrote:
2010/1/12 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
Btw, about that function. Its using a squeakFileOffsetType, which is platform specific, and i had hard times trying to deal with right header inclusion order imposing dependency of interpreter from platform code, which, IMO should be avoided. I propose to change it to typedef unsigned long long vmFileOffsetType; and use this type instead.
I'm not sure if MSVC supports long long nowadays. It didn't used to - it used to require __int64 which is why the definition of squeakFileOffsetType is external.
There should be an ANSI long long integer type.
There's a C99 long long type (does MSVC implement C99?) but for example no C++ long long type. See also:
http://bytes.com/topic/c/answers/63790-__int64-vs-long-long
I'd strongly suggest leaving this in a way that allows for external redefinition. You could have something that says:
#ifndef LONGLONG_NOT_SUPPORTED typedef long long squeakFileOffsetType #endif
Cheers, - Andreas
2010/1/12 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
2010/1/12 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
Btw, about that function. Its using a squeakFileOffsetType, which is platform specific, and i had hard times trying to deal with right header inclusion order imposing dependency of interpreter from platform code, which, IMO should be avoided. I propose to change it to typedef unsigned long long vmFileOffsetType; and use this type instead.
I'm not sure if MSVC supports long long nowadays. It didn't used to - it used to require __int64 which is why the definition of squeakFileOffsetType is external.
There should be an ANSI long long integer type.
There's a C99 long long type (does MSVC implement C99?) but for example no C++ long long type. See also:
http://bytes.com/topic/c/answers/63790-__int64-vs-long-long
I'd strongly suggest leaving this in a way that allows for external redefinition. You could have something that says:
#ifndef LONGLONG_NOT_SUPPORTED typedef long long squeakFileOffsetType #endif
Oh, well, then how about
typedef struct { long hi; long lo; } squeakFileOffsetType;
let me restate what i intend to achieve: i just want to make interp.c to be independent from compiler-specific idiosyncrasies , and from platform-specific types.
Cheers, - Andreas
Igor Stasenko wrote:
I'd strongly suggest leaving this in a way that allows for external redefinition. You could have something that says:
#ifndef LONGLONG_NOT_SUPPORTED typedef long long squeakFileOffsetType #endif
Oh, well, then how about
typedef struct { long hi; long lo; } squeakFileOffsetType;
Could do, but that's not the same as a native 64 bit int on little endian machines so all code using squeakFileOffsetType needs to be rewritten to use struct accessors. Not sure if that's worth it.
let me restate what i intend to achieve: i just want to make interp.c to be independent from compiler-specific idiosyncrasies , and from platform-specific types.
I'm not sure what purpose this serves. The compiler will fail instantly for an absent definition of squeakFileOffsetType so it's not that there's any doubt about what you need to do if you port to a new platform. Let's be pragmatic here - as much as I agree that having compiler specific stuff in there isn't the best choice, there are some situations where the alternative is needlessly complex. This seems to be one of those.
Cheers, - Andreas
On Tue, Jan 12, 2010 at 7:54 AM, Andreas Raab andreas.raab@gmx.de wrote:
Igor Stasenko wrote:
Btw, about that function. Its using a squeakFileOffsetType, which is platform specific, and i had hard times trying to deal with right header inclusion order imposing dependency of interpreter from platform code, which, IMO should be avoided. I propose to change it to typedef unsigned long long vmFileOffsetType; and use this type instead.
I'm not sure if MSVC supports long long nowadays. It didn't used to - it used to require __int64 which is why the definition of squeakFileOffsetType is external.
We should just use usqLong. The platform-specific definition in platforms/Cross/vm/sqVirtualMachine.h can be moved to sqMemoryAccess.h so that usqLong & sqLong are also available once sqInt & usqInt are.
Cheers,
- Andreas
Mmm no, the history of the squeakFileOffsetType was originally for the use of file system 64bit points back when 64bit support Windows was a footnote in some Microsoft engineers diary. It was first introduced on the mac version of the VM with other variations following years? later.
Technically it is a platform specific entity since not all file systems support 64bit values, so it's improper to consider for other usages outside the file system support plugins.
On 2010-01-12, at 11:42 AM, Eliot Miranda wrote:
On Tue, Jan 12, 2010 at 7:54 AM, Andreas Raab andreas.raab@gmx.de wrote:
Igor Stasenko wrote: Btw, about that function. Its using a squeakFileOffsetType, which is platform specific, and i had hard times trying to deal with right header inclusion order imposing dependency of interpreter from platform code, which, IMO should be avoided. I propose to change it to typedef unsigned long long vmFileOffsetType; and use this type instead.
I'm not sure if MSVC supports long long nowadays. It didn't used to - it used to require __int64 which is why the definition of squeakFileOffsetType is external.
We should just use usqLong. The platform-specific definition in platforms/Cross/vm/sqVirtualMachine.h can be moved to sqMemoryAccess.h so that usqLong & sqLong are also available once sqInt & usqInt are.
Cheers,
- Andreas
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Tue, Jan 12, 2010 at 11:52 AM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:
Mmm no, the history of the squeakFileOffsetType was originally for the use of file system 64bit points back when 64bit support Windows was a footnote in some Microsoft engineers diary. It was first introduced on the mac version of the VM with other variations following years? later.
Technically it is a platform specific entity since not all file systems support 64bit values, so it's improper to consider for other usages outside the file system support plugins.
OK, but in any case IMO the usqLong/sqLong defines belong alongside the sqInt/usqInt ones.
On 2010-01-12, at 11:42 AM, Eliot Miranda wrote:
On Tue, Jan 12, 2010 at 7:54 AM, Andreas Raab andreas.raab@gmx.de wrote:
Igor Stasenko wrote:
Btw, about that function. Its using a squeakFileOffsetType, which is platform specific, and i had hard times trying to deal with right header inclusion order imposing dependency of interpreter from platform code, which, IMO should be avoided. I propose to change it to typedef unsigned long long vmFileOffsetType; and use this type instead.
I'm not sure if MSVC supports long long nowadays. It didn't used to - it used to require __int64 which is why the definition of squeakFileOffsetType is external.
We should just use usqLong. The platform-specific definition in platforms/Cross/vm/sqVirtualMachine.h can be moved to sqMemoryAccess.h so that usqLong & sqLong are also available once sqInt & usqInt are.
Cheers,
- Andreas
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
2010/1/12 John M McIntosh johnmci@smalltalkconsulting.com:
Mmm no, the history of the squeakFileOffsetType was originally for the use of file system 64bit points back when 64bit support Windows was a footnote in some Microsoft engineers diary. It was first introduced on the mac version of the VM with other variations following years? later. Technically it is a platform specific entity since not all file systems support 64bit values, so it's improper to consider for other usages outside the file system support plugins.
Right , and that's why i feel this type usage in readImageFromFileHeapSizeStartingAt() awfully wrong.
On 2010-01-12, at 11:42 AM, Eliot Miranda wrote:
On Tue, Jan 12, 2010 at 7:54 AM, Andreas Raab andreas.raab@gmx.de wrote:
Igor Stasenko wrote:
Btw, about that function. Its using a squeakFileOffsetType, which is platform specific, and i had hard times trying to deal with right header inclusion order imposing dependency of interpreter from platform code, which, IMO should be avoided. I propose to change it to typedef unsigned long long vmFileOffsetType; and use this type instead.
I'm not sure if MSVC supports long long nowadays. It didn't used to - it used to require __int64 which is why the definition of squeakFileOffsetType is external.
We should just use usqLong. The platform-specific definition in platforms/Cross/vm/sqVirtualMachine.h can be moved to sqMemoryAccess.h so that usqLong & sqLong are also available once sqInt & usqInt are.
Cheers, - Andreas
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
John M McIntosh wrote:
Mmm no, the history of the squeakFileOffsetType was originally for the use of file system 64bit points back when 64bit support Windows was a footnote in some Microsoft engineers diary. It was first introduced on the mac version of the VM with other variations following years? later.
Technically it is a platform specific entity since not all file systems support 64bit values, so it's improper to consider for other usages outside the file system support plugins.
That may be true but these platforms can still return 64 bit values (and fail if the request is larger than 32 bit). I think Eliot's suggestion is a good one: Make all file operations take 64 bit, leave it to the vm implementors to deal with the consequences, and alias squeakFileOffsetType to usqLong (or get rid of it).
Cheers, - Andreas
On 2010-01-12, at 11:42 AM, Eliot Miranda wrote:
On Tue, Jan 12, 2010 at 7:54 AM, Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> wrote:
Igor Stasenko wrote: Btw, about that function. Its using a squeakFileOffsetType, which is platform specific, and i had hard times trying to deal with right header inclusion order imposing dependency of interpreter from platform code, which, IMO should be avoided. I propose to change it to typedef unsigned long long vmFileOffsetType; and use this type instead. I'm not sure if MSVC supports long long nowadays. It didn't used to - it used to require __int64 which is why the definition of squeakFileOffsetType is external.We should just use usqLong. The platform-specific definition in platforms/Cross/vm/sqVirtualMachine.h can be moved to sqMemoryAccess.h so that usqLong & sqLong are also available once sqInt & usqInt are.
Cheers, - Andreas--
John M. McIntosh <johnmci@smalltalkconsulting.com mailto:johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
2010/1/12 Andreas Raab andreas.raab@gmx.de:
John M McIntosh wrote:
Mmm no, the history of the squeakFileOffsetType was originally for the use of file system 64bit points back when 64bit support Windows was a footnote in some Microsoft engineers diary. It was first introduced on the mac version of the VM with other variations following years? later. Technically it is a platform specific entity since not all file systems support 64bit values, so it's improper to consider for other usages outside the file system support plugins.
That may be true but these platforms can still return 64 bit values (and fail if the request is larger than 32 bit). I think Eliot's suggestion is a good one: Make all file operations take 64 bit, leave it to the vm implementors to deal with the consequences, and alias squeakFileOffsetType to usqLong (or get rid of it).
Exactly what i want :)
Cheers, - Andreas
On 2010-01-12, at 11:42 AM, Eliot Miranda wrote:
On Tue, Jan 12, 2010 at 7:54 AM, Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> wrote:
Igor Stasenko wrote:
Btw, about that function. Its using a squeakFileOffsetType, which is platform specific, and i had hard times trying to deal with right header inclusion order imposing dependency of interpreter from platform code, which, IMO should be avoided. I propose to change it to typedef unsigned long long vmFileOffsetType; and use this type instead.
I'm not sure if MSVC supports long long nowadays. It didn't used to - it used to require __int64 which is why the definition of squeakFileOffsetType is external.
We should just use usqLong. The platform-specific definition in platforms/Cross/vm/sqVirtualMachine.h can be moved to sqMemoryAccess.h so that usqLong & sqLong are also available once sqInt & usqInt are.
Cheers, - Andreas
--
=========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com mailto:johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
On Tue, Jan 12, 2010 at 10:41:30PM +0200, Igor Stasenko wrote:
2010/1/12 Andreas Raab andreas.raab@gmx.de:
That may be true but these platforms can still return 64 bit values (and fail if the request is larger than 32 bit). I think Eliot's suggestion is a good one: Make all file operations take 64 bit, leave it to the vm implementors to deal with the consequences, and alias squeakFileOffsetType to usqLong (or get rid of it).
Exactly what i want :)
Sounds right to me as well.
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
David T. Lewis -
Eliot Miranda -
Igor Stasenko -
John M McIntosh