Vm-dev October 2010

vm-dev@lists.squeakfoundation.org

27 participants
60 discussions

positive32BitValueOf: fail with LargePositiveInteger
by Mariano Martinez Peck 11 Oct '10

11 Oct '10

Hi. I am trying to call #primitiveBitOr which inside calls #popPos32BitInteger which calls #positive32BitValueOf , with two LargePositiveInteger. Example: 9999999999 bitOr: 8888888888. Now, this seems to fail since the #bitOr: of LargePositiveInteger is failing, and thus, super (Integer) is being used. Now, I don't understand why it fails. If I read the comment of positive32BitValueOf it says "Convert the given object into an integer value. The object may be either a positive ST integer or a four-byte LargePositiveInteger." Its code is: positive32BitValueOf: oop "Convert the given object into an integer value. The object may be either a positive ST integer or a four-byte LargePositiveInteger." | sz value | (self isIntegerObject: oop) ifTrue: [ value := self integerValueOf: oop. value < 0 ifTrue: [^ self primitiveFail]. ^ value]. self assertClassOf: oop is: (self splObj: ClassLargePositiveInteger). successFlag ifTrue: [ sz := self lengthOf: oop. sz = 4 ifFalse: [^ self primitiveFail]]. successFlag ifTrue: [ ^ (self fetchByte: 0 ofObject: oop) + ((self fetchByte: 1 ofObject: oop) << 8) + ((self fetchByte: 2 ofObject: oop) << 16) + ((self fetchByte: 3 ofObject: oop) << 24) ]. as you can see, I am supposed to use ClassLargePositiveInteger. But, in addition, LargePositiveInteger >> #bitOr comment says: "Primitive. Answer an Integer whose bits are the logical OR of the receiver's bits and those of the argument. Fail if the receiver or argument is greater than 32 bits. See Object documentation whatIsAPrimitive." So....I don't understand...how can I have a LargePositiveInteger but that is less than 32 bits? Wouldn't that be a SmallInteger? I put some printf in the VM and seems that with my numbers (9999999999 and 8888888888.) when I sent positive32BitValueOf: I got : -65536 and 65535 Thanks in advance for any help. Mariano

7 16

CArray arithmetic methods...
by Eliot Miranda 11 Oct '10

11 Oct '10

Hi All, now I'm successfully simulating the LargeIntegers plugin I'm hitting what I consider a bug in CArray, used to model C pointers in the simulator. The first problem is that CArray>>#+ & #- return an integer value, not another CArray, (in C (char *)(exp) + n is still of type (char *), not int) and that the addition/subtraction doesn't scale by the unit size (in C (type *)p + n == (type *)((char *)p + n * sizeof(type))). The second problem is that << >> * & // are meaningless on C pointers. Anyone think of a good reason why I shouldn't a) rewrite CArray>>#+ & #- to read + n ^ self shallowCopy += (n * unitSize) - n ^ self shallowCopy -= (n * unitSize) (since e.g. += increment ptrOffset := ptrOffset + increment) and b) delete CArray>>#*, #//, #<<, #>>, #bitAnd:, #bitOr:, #bitShift: & #signedBitShift: ? best Eliot

2 4

JPEGReadWriter2Plugin
by Bert Freudenberg 11 Oct '10

11 Oct '10

Hi, have there been changes lately to the jpeg plugin? On a Mac 4.2.4 VM I see an off-by-one error, all pixels are moved to the right, the first pixel is transparent. On a Mac 5.8.1 Cog VM it works as expected though. Here's my little test: (JPEGReadWriter2 formFromStream: #[16rFF 16rD8 16rFF 16rE0 16r00 16r10 16r4A 16r46 16r49 16r46 16r00 16r01 16r01 16r01 16r00 16r48 16r00 16r48 16r00 16r00 16rFF 16rDB 16r00 16r43 16r00 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rC2 16r00 16r0B 16r08 16r00 16r01 16r00 16r01 16r01 16r01 16r11 16r00 16rFF 16rC4 16r00 16r14 16r10 16r01 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16rFF 16rDA 16r00 16r08 16r01 16r01 16r00 16r01 16r3F 16r10] readStream) bits first hex On 5.8.11 I get 16rFF808080 as expected, on 4.2.4 I get 0. - Bert -

3 7

VM Maker: VMMaker-dtl.192.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 09 Oct '10

09 Oct '10

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.192.mcz ==================== Summary ==================== Name: VMMaker-dtl.192 Author: dtl Time: 9 October 2010, 2:26:51 am UUID: e22782de-efc8-4029-b1ec-61588fb91d37 Ancestors: VMMaker-dtl.191 VMMaker 4.3.6 Merge John's 64-bit changes for JPEGReaderWriter2Plugin. Add unit tests based on Bert's test in original bug report. With these patches JPEGReaderWriter2Plugin works with the VM compiled in either 32-bit or 64-bit mode.

1 0

VM Maker: VMMaker-dtl.191.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 08 Oct '10

08 Oct '10

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.191.mcz ==================== Summary ==================== Name: VMMaker-dtl.191 Author: dtl Time: 8 October 2010, 3:52:12 am UUID: f82f1668-dd8b-417b-b546-320e2a713272 Ancestors: VMMaker-dtl.190 VMMaker 4.3.5 Adopt JPEGReaderWriter2Plugin from oscog. JPEGReaderWriter2Plugin is gives incorrect results as reported by Bert: http://lists.squeakfoundation.org/pipermail/vm-dev/2010-September/005481.ht… And on my system, the plugin crashes the VM outright. JPEGReaderWriter2Plugin from oscog branch works correctly. Merging the differences did not produce a happy result, therefore adopt the working oscog version. Follow up may be required to add intended changes from John's 64-bit updates as detailed below: #primJPEGReadHeader:fromByteArray:errorMgr: The oscog version contains parameter type declarations that are missing from the vmmaker trunk. The oscog version is stamped 4/4/2006, so this is just something that did not get included in trunk. Oscog version is correct, adopt in in trunk. #primJPEGReadImage:fromByteArray:onForm:doDithering:errorMgr: Oscog contains type declarations missing from trunk. Trunk contains John's type declaration fixes for 64-bit. Merging the two does not produce a working version, therefore adopt oscog version. This update removes the changes that were introduced in John's update of 1/4/2010. #primJPEGWriteImage:onByteArray:form:quality:progressiveJPEG:errorMgr: Oscog contains type declarations missing from trunk. Trunk contains John's type declaration fixes for 64-bit. Merging the two does not produce a working version, therefore adopt oscog version.This update removes the changes that were introduced in John's update of 1/4/2010.

2 1

positive32BitValueOf: fail with LargePositiveInteger
by Mariano Martinez Peck 08 Oct '10

08 Oct '10

1 0

Re: [Pharo-project] UUID and Cog?
by David T. Lewis 08 Oct '10

08 Oct '10

Moving to vm-dev list for follow up related to the UUIDPlugin. On Wed, Oct 06, 2010 at 04:37:00AM +0200, Levente Uzonyi wrote: > On Tue, 5 Oct 2010, David T. Lewis wrote: <unrelated discussion of Cog configurations snipped> > >As far as I know, there have been no reports of libuuid failures on > >the Unix VMs since Ian changed to using an internal UUIDPlugin, so > >this is an easy fix if it works for Cog also. > > If libuuid is not available, the internally built UUIDPlugin crashes the > VM. > > Levente Levente, thanks for identifying this. I was able to reproduce this on my system by removing the libuuid libraries, after which a VM with internal UUIDPlugin refuses to load: /usr/local/lib/squeak/4.3.4-2316/squeakvm: error while loading shared libraries: libuuid.so.1: cannot open shared object file: No such file or directory I reopened the issue on Mantis http://bugs.squeak.org/view.php?id=7358 with the following explanation: > Changing status from resolved back to acknowledged. Levente Uzonyi > reports that the plugin, if built internally, will crash the VM if > the target system does not have libuuid installed. > > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-October/033760.ht… [^] > > I reproduced this by removing the libuuid libraries from my Linux system. > The result is that the VM fails to load due to the missing library. It > never reaches main(), so this is not something that can be addressed in > the code. Presumably a static linked VM would work, but this would > probably lead to problems elsewhere. > > Summary: Building UUIDPlugin internally is a workaround for the libuuid > bug that is present on some systems, but it results in an unusable VM for > people who do not have the uuid library installed with their OS. Levente, can you say anything about what OS platforms would not have libuuid installed? I am guessing that it is a scenario involving a 64-bit OS for which some of the 32-bit runtime libraries were not installed, but if you can clarify this it would be helpful. Thanks! Dave

2 1

Cog on Mac OS X 10.5.8
by Yanni Chiu 07 Oct '10

07 Oct '10

On Mac OS X 10.5.8, using a fresh Squeak4.2-10548-alpha image... These VM's work: Cog.app r2316 Squeak 4.2.4beta1U.app Squeak 64-32 5.4b2.app This one does not: Squeak 5.8b10.app I get a stream of these, about 7 or 8 per second, in the system console: 06/10/10 5:16:39 PM Squeak[23499] invalid pixel format 06/10/10 5:16:39 PM Squeak[23499] invalid context 06/10/10 5:16:39 PM Squeak[23499] invalid pixel format 06/10/10 5:16:39 PM Squeak[23499] invalid context The behaviour with PhareCore-1.1.1 is similar, except the error messages are less frequent. Meanwhile, a window has popped up, but the Squeak/Pharo world is blank. I have to kill the process, since the close button and menu exit are probably waiting on a dialog I cannot see. I actually want to use SqueakSSL, which reportedly works on the "Squeak 5.8b10" VM. BTW, other VM results are: Squeak 5.8b3.app - WORKS Squeak 5.8b4.app - WORKS Squeak 5.8b7 - CRASH Squeak 5.8b9.app - same behaviour as 5.8b10 Is OSX 10.5.8 supposed to work, or do I need to upgrade ? -- Yanni

2 2

VM Maker: VMMaker-dtl.190.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 07 Oct '10

07 Oct '10

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.190.mcz ==================== Summary ==================== Name: VMMaker-dtl.190 Author: dtl Time: 6 October 2010, 8:39:07 am UUID: 4798e721-0a2b-4dea-b924-7492012a75f1 Ancestors: VMMaker-dtl.189 VMMaker 4.3.4 Fix #normalizeFloatOrderingInImage to work on 64-bit Squeak images. Float data storage in a 64-bit image is the same as for a 32 bit image, with the two 32-bit halves stored in the next two 32-bit words beginning at accessibleObjectAfter: floatOop (in the case of 64-bit memory, the two 32-bit halves occupy one object memory word, while a 32-bit object memory uses two). Therefore use the same logic in #normalizeFloatOrderingInImage for a 64-bit image.

1 0

VM Maker: VMMaker-dtl.189.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 07 Oct '10

07 Oct '10

Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.189.mcz ==================== Summary ==================== Name: VMMaker-dtl.189 Author: dtl Time: 6 October 2010, 12:17:37 pm UUID: 29192b6e-491d-4bc6-a209-5ba1c8625da0 Ancestors: VMMaker-dtl.188 VMMaker 4.3.3 Allow a standard interpreter VM to load and run an image that was saved from a Cog or StackInterpreter VM. On image load, the storage format of Float objects is returned to normalized word ordering (different from platform word order for little endian platforms) and unrecognized header flags are cleared. The image will be saved in standard interpreter format (image format 6504 for a 32-bit image), which may subsequently be loaded by a Cog or StackInterpreter VM. Works for 32-bit Cog images (image format 6505) on both 32-bit and 64-bit host (compile -m32 or -m64). Support for 64-bit image formats is not yet implemented, see comment in #normalizeFloatOrderingInImage.

6 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev October 2010