Vm-dev March 2009

vm-dev@lists.squeakfoundation.org

21 participants
29 discussions

How to compile a debugging VM?
by Michael van der Gulik 24 Mar '09

24 Mar '09

On Linux, how do you tell the build scripts to make GCC compile with the -g flag rather than -O2 (i.e. don't optimise and leave debugging symbols in the VM)? So far I've been manually editing relevant Makefiles, but surely there's a better way. Gulik. -- http://gulik.pbwiki.com/

3 2

Crash on start-up.
by Michael van der Gulik 23 Mar '09

23 Mar '09

Hi VM guys. Does anybody have any insights into the following?: I get the following crash. I've tried this on a Windows VM of unknown version and a 3.9-alpha Linux VM with the same result: Segmentation fault -1528952856 [] in Semaphore>critical: -1528953680 BlockContext>ensure: -1528953772 Semaphore>critical: -1528953864 >clearExternalObjects -1528953956 SystemDictionary>clearExternalObjects -1529116848 SmalltalkImage>snapshot:andQuit:embedded: -1529116940 SmalltalkImage>snapshot:andQuit: -1529117032 TheWorldMenu>saveAndQuit -1529117216 TheWorldMenu>doMenuItem:with: -1529117308 [] in MenuItemMorph>invokeWithEvent: -1529117400 BlockContext>ensure: -1529117492 Cursor>showWhile: -1529117712 MenuItemMorph>invokeWithEvent: -1529117804 MenuItemMorph>mouseUp: -1529117896 MenuItemMorph>handleMouseUp: -1529118028 MouseButtonEvent>sentTo: -1529118120 Morph>handleEvent: -1529118212 MorphicEventDispatcher>dispatchDefault:with: -1529118304 MorphicEventDispatcher>dispatchEvent:with: -1529118396 Morph>processEvent:using: -1529118488 MorphicEventDispatcher>dispatchDefault:with: -1529118596 MorphicEventDispatcher>dispatchEvent:with: -1529118728 Morph>processEvent:using: -1529118820 Morph>processEvent: -1529118912 MenuMorph>handleFocusEvent: -1529119188 [] in HandMorph>sendFocusEvent:to:clear: -1529119096 [] in PasteUpMorph>becomeActiveDuring: -1529119280 BlockContext>on:do: -1529119372 PasteUpMorph>becomeActiveDuring: -1529119556 HandMorph>sendFocusEvent:to:clear: -1529119648 HandMorph>sendEvent:focus:clear: -1529119740 HandMorph>sendMouseEvent: -1529119884 HandMorph>handleEvent: -1529120168 HandMorph>processEvents -1529120076 [] in WorldState>doOneCycleNowFor: -1529120260 SequenceableCollection>do: -1529120352 WorldState>handsDo: -1529120444 WorldState>doOneCycleNowFor: -1529120536 WorldState>doOneCycleFor: -1529120628 PasteUpMorph>doOneCycle -1529214452 [] in >spawnNewProcess -1529214268 [] in BlockContext>newProcess Segmentation fault (core dumped) This happens on start-up. None of the VM flags I tried make a difference. I suspect this may have caused it: !EventSensor methodsFor: 'as yet unclassified' stamp: 'mvdg 3/17/2009 21:54' prior: 36505616! startUp [ panicButtonPressed := false. Smalltalk.Sensor shutDown. inputSemaphore := Semaphore new. Smalltalk.ExternalSemaphoreTable registerExternalObject: inputSemaphore. self primSetInputSemaphore: inputSemaphore. self enterEventLoop. ] ensure: [ Smalltalk.Sensor startUp. Smalltalk.Display restore. ].! ! This code worked fine until I saved, quit and tried to reopen the image. Note that this class is actually defined in my namespaces implementation - it does not exist in the SystemDictionary and has it's environment set to an instance of Namespace. It is my own implementation of EventSensor and I've added the primitive methods to it. I'm not sure if any of this matters. I'm going to put this image aside rather than try to fix the above and make a new image so I can continue my work. This problem will continue to exist, however, so if I have any breakthroughs as to what is happening, I'll post a reply. Gulik. -- http://gulik.pbwiki.com/

3 9

Compiling squeak-vm for Linux 64bit
by whaevr 17 Mar '09

17 Mar '09

Been trying to compile the latest squeak-vm (version 3.10-4) for x86_64 Linux, heres my configure line: ./Squeak-$_realver/platforms/unix/config/configure --prefix=/usr --without-quartz --with-x --enable-mpg-mmx Ignore the $_realver its a variable used in the pkgbuild. It gets through configure but on running make it stops with the following error: vm/vm.a(sqUnixMain.o): In function `vm_parseEnvironment': sqUnixMain.c:(.text+0x15ad): undefined reference to `setLocaleEncoding' vm/vm.a(sqNamedPrims.o):(.data+0x68): undefined reference to `FileCopyPlugin_exports' vm/vm.a(sqNamedPrims.o):(.data+0xc0): undefined reference to `MIDIPlugin_exports' vm/vm.a(sqNamedPrims.o):(.data+0xd0): undefined reference to `Mpeg3Plugin_exports' collect2: ld returned 1 exit status make: *** [squeak] Error 1 I've attached a full log of the compiler's output. I can successfully compile version 3.9.8 with the same configure line.

7 24

Integer fixes for Mantis 6987
by David T. Lewis 13 Mar '09

13 Mar '09

I have updated the SqueakSource VMMaker project (VMMaker-dtl.117) with fixes from Mantis 6987. http://bugs.squeak.org/view.php?id=6987 http://www.squeaksource.com/VMMaker/VMMaker-dtl.117.mcz I believe these fixes are correct for the 32 and 64-bit integer methods, and I verified them on both 32 and 64-bit images. However, I have not run the Alien tests, and I did not run the FFITestCase.st test on Mantis (I don't have a 32-bit machine handy at the moment). If anyone has a chance to validate these changes with the Alien tests, please let me know (or just close the issue on Mantis if it is complete). Dave

1 0

Re: [squeak-dev] Re: New Window VM (Closures, FT2Plugin, Large Cursors)
by Eliot Miranda 10 Mar '09

10 Mar '09

On Tue, Mar 10, 2009 at 12:48 AM, Klaus D. Witzel <klaus.witzel(a)cobss.com>wrote: > Hi Eliot, > > On Tue, 10 Mar 2009 01:04:29 +0100, Eliot Miranda wrote: > > Hi Klaus, >> >> On Mon, Mar 9, 2009 at 11:04 AM, Klaus D. Witzel wrote: >> > ... > >> I've seen that one of the differences between the Encoder*XYZ's is >>> #supportsClosureOpcodes being true/false but also #generateAsClosure >>> plays a >>> role. So the *Closures suffix is short for *EmitClosuresBytecode? Also, >>> blocks are never emitted the old (non-closure) way? >>> >> >> >> The scheme is that by choosing the encoder one can choose the type of code >> generated. So that e.g. if you say >> >> (Parser new >> encoderClass: EncoderForV3PlusClosures; >> parse: someString readStream class: MyClass) >> generate: #(0 0 0 0) >> >> you'll get closure code and if you say >> >> (Parser new >> encoderClass: EncoderForV3; >> parse: someString readStream class: MyClass) >> generate: #(0 0 0 0) >> >> you'll get pre-closure old-block code. >> > > Okay thanks, perfectly clear now. > > ... > > And on the wrong VM it'll crash. Only the CLosure VM that people are >> providing right now can run both new and old code. The StackVM we have in >> Qwaq (that I hope will be released sometime) will only run Closure code >> and die horribly if given old block code. >> > > This implies that any test*ABC method which compiles source code and passes > the wrong Encoder*XYZ to Parser can crash its VM. So one has to check, in > such tests, what VM type is running. How can the VM be queried for that? Good point. There isn't a straight-forward way in the normal VMs. In the Qwaq internal VMs I added the imageFormatVersion of the current VM as vm parameter #41. BTW, here is the complete list of things I've added 41 imageFormatVersion for the VM 42 nil (number of stack pages in use in Stack VM) 43 nil (desired number of stack pages in Stack VM) 44 nil (size of eden, in bytes in Stack VM) 45 nil (desired size of eden in Stack VM) 46-55 nil; reserved for VM parameters that persist in the image (such as eden above) 56 number of process switches since startup (read-only) 57 number of ioProcessEvents calls since startup (read-only) 58 number of ForceInterruptCheck calls since startup (read-only) 59 number of check event calls since startup (read-only) There might be a way of constructing an empty closure on a null method and testing if a version of the closure primitive fails, but I prefer the image format parameter. In older VMs the vm parameter primitive should fail if given parameter 41. What say the VM devs? Can we add #41 as answering the imageFormatVersion of the VM? > > > /Klaus > > -- > "If at first, the idea is not absurd, then there is no hope for it". Albert > Einstein > > >

2 1

Various Mantis VM issues closed
by David T. Lewis 08 Mar '09

08 Mar '09

I have closed a number of Mantis issues in the "VM" and "Squeak 64 bit" categories. These are issues that have been addressed in the VMMaker project on SqueakSource as of VMMaker-dtl.116. They include various changes that have not been reviewed by people other than the author (e.g changes to slang inlining), but in the interest of housekeeping I thought it best to mark them closed at this point. I've tried (not always successfully) to keep change sets on Mantis corresponding to the Monticello updates on SqueakSource, as well as version comments in the SqueakSource update to point to the Mantis issues. Doing a Monticello history on VMMaker-dtl.116 will identify most of the corresponding Mantis issues and change sets. Searching for closed Mantis VM issues may find a couple that I failed to identify in the Monticello comments. There are still plenty of open Mantis issues in the VM category, but with respect to VMMaker I consider the following two open Mantis issues to be most significant: 6987: signed32BitValueOf:, signed64BitValueOf: etc. broken 5238: Integer bug on 64bit image/32bit VM, DateAndTime now ==> -4391-12-26T16:18:33+00:00 Dave

1 0

New Window VM (Closures, FT2Plugin, Large Cursors)
by Andreas Raab 07 Mar '09

07 Mar '09

Folks - Since I was in VM building mode today I figured I might as well make a new Squeak VM. There is some interesting new stuff in it: * Closure support. This VM is based on VMMaker-dtl.116 meaning it includes support for the closure bytecodes. I have verified it by both running a Qwaq image on this VM and and a converted closure image on our Stack VM (this is useful since the Stack VM will die a horrible death something goes wrong in the process). It worked fine both ways which means that I no longer need to switch VMs (yay! ;-) * Experimental large cursor support. Try the following for fun (but don't do it in an image you care about): cursor := Cursor extent: 128@128 depth: 32. cursor offset: -64@-64. cursor getCanvas fillOval: cursor boundingBox color: (Color white alpha: 0.1); frameOval: cursor boundingBox width: 4 color: Color red; line: 62@64 to: 66@64 width: 1 color: Color blue; line: 64@62 to: 64@66 width: 1 color: Color blue. Cursor classPool at: #NormalCursor put: cursor. This changes your normal cursor to be a 128x128 pixels large, translucent cursor. * FT2Plugin. The build includes an external FT2Plugin that has no dependencies on extra DLLs. The downloads are in the usual places: http://squeakvm.org/win32/release/SqueakVM-Win32-3.11.1-bin.zip http://squeakvm.org/win32/release/SqueakVM-Win32-3.11.1-src.zip A closure image (for those interested): http://squeakvm.org/win32/release/Squeak-3.10.2-Closures.zip Note that I consider this an "alpha" version since there is a goodly bit of new and untested stuff in it. I'm in particular interested in finding people to test large cursor support and the FT2Plugin. Feedback is highly welcome. Cheers, - Andreas

8 11

Closure conversion in 3.10
by Andreas Raab 07 Mar '09

07 Mar '09

Hi Eliot - I've just successfully converted a 3.10.2 image to closures (see follow-on message to Squeak-dev). In the process, the following three problems occurred: 1) DecompilerTests is not present in 3.10 and PreRecompilationPatches.st doesn't load unless you remove the modification to DecompilerTests. 2) #isMessageNode is not understood by ParseNode or MessageNode but sent in the recompilation process. I'm not sure where this is coming from (or where it should be); it could be a bug in 3.10. 3) Recompilation of Preferences results in spurious ERROR listings in the transcript during recompilation. Again, no idea where this comes from. Other than that the conversion went entirely flawless. Cheers, - Andreas

2 3

Interpreter>>isContextHeader: optimization
by Igor Stasenko 05 Mar '09

05 Mar '09

Here the method: isContextHeader: aHeader self inline: true. ^ ((aHeader >> 12) bitAnd: 16r1F) = 13 "MethodContext" or: [((aHeader >> 12) bitAnd: 16r1F) = 14 "BlockContext" or: [((aHeader >> 12) bitAnd: 16r1F) = 4]] "PseudoContext" i think it wouldn't hurt to rewrite it as: isContextHeader: aHeader self inline: true. | hdr | hdr := aHeader bitAnd: (16r1F << 12). ^ hdr = (13 << 12) "MethodContext" or: [ hdr = (14 << 12) "BlockContext" or: [ hdr = (4 << 12)]] "PseudoContext" which will allow GCC to optimize it more easily. I'm not sure if it can optimize it in its current state. This may impact a small speedup of copy operations and any other operations which need to determine a number of pointer fields in object (users of #lastPointerOf:) -- Best regards, Igor Stasenko AKA sig.

5 34

Re: [Etoys] BUG: Squeak-3.10 VM and ubuntu
by Bert Freudenberg 05 Mar '09

05 Mar '09

On 05.03.2009, at 19:40, Markus Schlager wrote: > Hi Jan, > > I do know, this is the wrong mailing-list for this issue. Indeed. Why don't you bring this up on a Scratch forum? > Maybe someone > could do me the favour and forward this mail to the VM mailing list. > > Problem description: > > When running squeak with a Squeak-3.10-VM (tested with 3.10-1 and > 3.10-4) an ubuntu hardy, it is not possible to close squeak by > closing the > squeak-window with Alt+F4 nor with the x-icon. It doesn't happen > anything. The VM was changed to not kill the image but send it a close event. John said he would handle that event in the next Scratch release. I pointed him to the relevant changeset from the Etoys image: http://tinlizzie.org/updates/etoys/updates/1574WindowEvents-JMM-bf.cs The other platforms' VMs were changed, too, although there the new behavior is optional. The problem on X11 always was that it was too simple to accidentally quit Squeak. There was no confirmation dialog as on Windows, or a specific menu item as on the Mac. So I find the new behavior much safer. > This is a real Problem when running Scratch on Linux, since this is > the > only way to close a Scratch. Some Scratch versions do have a quit button ... - Bert -

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev March 2009