Vm-dev April 2010

vm-dev@lists.squeakfoundation.org

33 participants
95 discussions

Linux build errors
by Igor Stasenko 27 Apr '10

27 Apr '10

Guys, i got errors trying to build VM on Ubuntu linux, from svn sources. What i did is just followed instructions: $ svn co http://squeakvm.org/svn/squeak/trunk src $ cd src/platforms/unix $ make And got these errors when linking: Linking C executable squeakvm CMakeFiles/squeakvm.dir/home/sig/squeak/src/platforms/Cross/vm/sqVirtualMachine.c.o: In function `sqGetInterpreterProxy': /home/sig/squeak/src/platforms/Cross/vm/sqVirtualMachine.c:360: undefined reference to `internalIsImmutable' /home/sig/squeak/src/platforms/Cross/vm/sqVirtualMachine.c:361: undefined reference to `internalIsMutable' /home/sig/squeak/src/platforms/Cross/vm/sqVirtualMachine.c:362: undefined reference to `primitiveFailFor' /home/sig/squeak/src/platforms/Cross/vm/sqVirtualMachine.c:363: undefined reference to `classAlien' /home/sig/squeak/src/platforms/Cross/vm/sqVirtualMachine.c:364: undefined reference to `getStackPointer' /home/sig/squeak/src/platforms/Cross/vm/sqVirtualMachine.c:365: undefined reference to `sendInvokeCallbackStackRegistersJmpbuf' /home/sig/squeak/src/platforms/Cross/vm/sqVirtualMachine.c:366: undefined reference to `reestablishContextPriorToCallback' /home/sig/squeak/src/platforms/Cross/vm/sqVirtualMachine.c:367: undefined reference to `classUnsafeAlien' sure, i know how to fix it. I just wanted to let you know that current svn sources containing errors and can't be used to build VM. -- Best regards, Igor Stasenko AKA sig.

1 0

Re: [Vm-dev] AlienOpenGL [was: VM crashes on Alien tests on Linux.]
by laurent laffont 27 Apr '10

27 Apr '10

Hi, I've loaded AlienOpenGL to check that Alien works or not. AlienOpenGLLibraryExamples tests fails. ex: AlienOpenGLLibraryExamples new testDrawingVBOCubeWithoutNormals AlienOpenGLLibrary>>primLoadLibrary: primitive failed trying to load 'OpenGL.framework' Has it ever been tested on Linux ? Cheers, Laurent Laffont On Tue, Apr 27, 2010 at 2:43 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Mon, Apr 26, 2010 at 10:53:20PM +0200, laurent laffont wrote: > > > > Hi, > > > > I've created ConfigurationOfVMMaker version 1.4 to build Alien plugins. > > > > I use: > > - PharoCore-1.0-10517 > > - VMMaker-dtl.170 > > - Alien-VMMaker-Plugins-John M McIntosh.8 > > - Alien-VMMaker-Support-John M McIntosh.8 > > - squeak vm rev. 2203 > > Laurent, > > Thanks for doing the ConfigurationOfVMMaker update. > > > I've tried with NewsqueakIA32ABIPlugin and NewsqueakIA32ABIPluginAttic > > (which one should I use ?) as external. > > I had the same question. John, is NewsqueakIA32ABIPluginAttic just > there to hold on to some no-longer-used primitives? It compiles fine > so I am assuming that it is safe to use (a class comment would be > good BTW). > > > My build script is here > > http://github.com/lolgzs/easy_squeakvm/blob/alien/easy_squeakvm.sh > > > > The VM is successfully built. Then I load Alien tests using: > > ConfigurationOfAlien loadTests. > > FYI: I made the updates to VMMaker platforms/Cross/vm, and can verify > that the plugin compiles cleanly (building a 32-bit plugin/VM on a > 64-bit Linux platform). However, I did not load Alien and cannot verify > that the resulting plugin functions correctly. > > Dave > >

1 0

VM crashes on Alien tests on Linux.
by laurent laffont 27 Apr '10

27 Apr '10

Hi, I've created ConfigurationOfVMMaker version 1.4 to build Alien plugins. I use: - PharoCore-1.0-10517 - VMMaker-dtl.170 - Alien-VMMaker-Plugins-John M McIntosh.8 - Alien-VMMaker-Support-John M McIntosh.8 - squeak vm rev. 2203 I've tried with NewsqueakIA32ABIPlugin and NewsqueakIA32ABIPluginAttic (which one should I use ?) as external. My build script is here http://github.com/lolgzs/easy_squeakvm/blob/alien/easy_squeakvm.sh The VM is successfully built. Then I load Alien tests using: ConfigurationOfAlien loadTests. When I run the tests in SUnit, the VM crashes. What should I check ? Here's the output: $ ./squeak ../PharoCore-1.0-10517/PharoCore-1.0-10517.image SQUEAK_ENCODING=UTF-8 SQUEAK_PATHENC=UTF-8 SQUEAK_PLUGINS=/home/lol/sandbox/squeakvm/easysqueak/out/build/%n + exec /home/lol/sandbox/squeakvm/easysqueak/out/build/squeakvm ../PharoCore-1.0-10517/PharoCore-1.0-10517.image 4 characters came in as c1 = (5) c2 = ` (60) c3 = (1) c4 = q (71) The 14 double are 0.000000 37731012097013058067317437078204362971852032595528259107423762531097905265514261096396025173302750110612706358114292371797115438181248956805323712176147123864545071420926082396075239300957542084816252981938270394157639412729055222913295109423106709185098753526806347776000.000000 1.000000 20.000000 30.000000 40.000000 50.000000 60.000000 70.000000 80.000000 90.000000 100.000000 110.000000 120.000000 The two floats are 0.000000 and inf The 13 floats are 0.000000 0.000000 0.000000 0.000000 1.000000 20.000000 30.000000 40.000000 50.000000 60.000000 70.000000 80.000000 90.000000 The 14 floats are 0.000000 0.000000 0.000000 0.000000 1.000000 20.000000 30.000000 40.000000 50.000000 60.000000 70.000000 80.000000 90.000000 100.000000 The two floats are 0.000000 and 0.000000 The float 0.000000 and integer 159532624 The integer 4 and float 0.000000 The 7 floats are 0.000000 0.000000 0.000000 27965084.000000 1.000000 20.000000 30.000000 4 ints came in as i1 = 5 (5) i2 = 159532832 (9824720) i3 = 4 (4) i4 = 1 (1) 8 ints came in as i1 = 9 (9) i2 = 159532960 (98247a0) i3 = 4 (4) i4 = -1074779508 (bff02a8c) i5 = 1 (1) i6 = 20 (14) i7 = 30 (1e) i8 = 40 (28) 4 ints came in as i1 = 3 (3) i2 = 159533024 (98247e0) i3 = 4 (4) i4 = -1217854351 (b7690471) 4 shorts came in as s1 = 5 (5) s2 = 18496 (4840) s3 = 2 (2) s4 = 1 (1) Segmentation fault 2019482440 AlienLibrary>ffiPrintString: 2019481780 AlienSunit>testCallingSquenceString 2019481688 TestCase>performTest 2019481596 TestCase>runCase 2019481504 BlockClosure>ensure: 2019481380 TestCase>runCase 2019481288 TestResult>runCase: 2019481172 BlockClosure>on:do: 2019481036 TestResult>runCase: 2019480944 BlockClosure>on:do: 2019480736 TestResult>runCase: 2019480644 TestCase>run: 2019480552 TestRunner>runTest: 2019480460 TestRunner>runSuite: 2019480276 SequenceableCollection>do:displayingProgress: 2019276848 SequenceableCollection>withIndexDo: 2019276732 SequenceableCollection>do:displayingProgress: 2019276640 ProgressInitiationException>defaultAction 2019276476 BlockClosure>ensure: 2019275852 ProgressInitiationException>defaultAction 2019275760 UndefinedObject>handleSignal: 2019275668 ContextPart>handleSignal: 2019275576 Exception>signal 2019275436 ProgressInitiationException>display:at:from:to:during: 2019275344 >display:at:from:to:during: 2019275232 String>displayProgressAt:from:to:during: 2019275140 SequenceableCollection>do:displayingProgress: 2019275004 TestRunner>basicRunSuite:do: 2019274912 BlockClosure>ensure: 2019274744 TestRunner>basicRunSuite:do: 2019274652 TestRunner>runSuite: 2019272372 TestRunner>runAll 2019272280 PluggableButtonMorph>performAction 2019272188 PluggableButtonMorphPlus>performAction 2019272096 PluggableButtonMorph>mouseUp: 2019272004 SequenceableCollection>do: 2019271212 PluggableButtonMorph>mouseUp: 2019271076 PluggableButtonMorphPlus>mouseUp: 2019270984 Morph>handleMouseUp: 2019270892 MouseButtonEvent>sentTo: 2019270800 Morph>handleEvent: 2019270708 Morph>handleFocusEvent: 2019270540 HandMorph>sendFocusEvent:to:clear: 2019270448 PasteUpMorph>becomeActiveDuring: 2019270356 BlockClosure>on:do: 2019270264 PasteUpMorph>becomeActiveDuring: 2019270148 HandMorph>sendFocusEvent:to:clear: 2019269988 HandMorph>sendEvent:focus:clear: 2019269896 HandMorph>sendMouseEvent: 2019269804 HandMorph>handleEvent: 2019269540 HandMorph>processEvents 2019269432 WorldState>doOneCycleNowFor: 2019269340 SequenceableCollection>do: 2019269248 WorldState>handsDo: 2019269156 WorldState>doOneCycleNowFor: 2019269028 WorldState>doOneCycleFor: 2019268936 PasteUpMorph>doOneCycle 1996578680 >? 1996578552 BlockClosure>? Aborted Cheers, Laurent Laffont

2 1

FFI crashing the VM while running a Win32Window example
by Igor Stasenko 26 Apr '10

26 Apr '10

Try this: Win32Window getFocus messageBox:'Are you ready???' title:'News from Squeak:' flags: 3 Is following correct & expected? Win32Window getFocus getHandle size ==> 0 Win32Window byteSize ==> 0 seems like it doesn't parsing the fields correctly, resulting a handle size = 0. fields "Win32Handle defineFields" "The following really means typedef void* Win32Handle; " ^#(nil 'ulong') "an opaque 32bit handle" -- Best regards, Igor Stasenko AKA sig.

1 0

Running Alien on Windows
by Torsten Bergmann 25 Apr '10

25 Apr '10

Bouraqadi Noury wrote on pharo-dev >We have trouble running alien on Windows. Starting from a clean pharo >1.0 image and the latest VM, Would not work out of the box with the VM since it requires VM changes. Marco ported them from Newspeak and made them available [1]. Tests went green and he is sucessfully using Alien on Windows. But it is not yet in the official Squeak VM (which is 4.0.2.). There is also an issue for pharo [2] and an issue for VM developers [3] to follow progress. So the code is there and is ready for integration. Andreas asked for the license [4], Marco answered that code was from Newspeak [5]. After that we got a good response from John McIntosh on the license issue [6] which should be OK now. (Dont know, I'm not a lawyer) After I asked Andreas again he answered that it is not highest priority for him which I understood since Squeak 4.1 was in preparation. See last response regarding this [7] Dont know what should be the next steps to get Alien into the Win32-VM code base. Maybe Andreas could tell you more. As a workaround you could use the source provided by Marco to build your own unofficial VM - however you would have to reintegrate anytime Andreas makes a new release... Bye T. [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/003983.html [2] http://code.google.com/p/pharo/issues/detail?id=1360 [3] http://bugs.squeak.org/view.php?id=7475 [4] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004034.html [5] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004037.html [6] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004054.html [7] http://lists.squeakfoundation.org/pipermail/vm-dev/2010- March/004103.html -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

4 4

Re: [squeak-dev] Re: MessageTally problems
by David T. Lewis 24 Apr '10

24 Apr '10

(CC to vm-dev list) I added Mantis 7515 to track this issue. http://bugs.squeak.org/view.php?id=7515 "Need way to add timer checks to #dispathFunctionPointer: without performance hit" Dave On Fri, Apr 23, 2010 at 11:11:29PM +0200, Brent Pinkney wrote: > Hi Andreas, > > > Look at primitiveResponse. You need to make sure that > > > > ioMSecs() > nextWakeupTick ifTrue:[self checkForInterrupts]. > > Ok, I have compared the 3.6-0 interp.c against the 3.10-4 interp.c (both from www.squeakvm.org). > > I have made a patch to Squeak-3.10-4/platforms/unix/src/vm/interp.c to (hopefully) restore the 3.6 profiling behaviour. > My changes are... > > > #define DoProfilerTimerCheck 1 > > sqInt dispatchFunctionPointer(void * aFunctionPointer) { > > int timerPending; > int startTime; > > /* this is required if the MessageTally is to function correctly */ > if (DoProfilerTimerCheck) { > timerPending = foo->nextWakeupTick != 0; > if (timerPending) { > startTime = ioLowResMSecs(); > } > } > ((void (*)(void))aFunctionPointer)(); > if (DoProfilerTimerCheck) { > if (timerPending) { > if ((ioLowResMSecs()) != startTime) { > if (((ioMSecs()) & MillisecondClockMask) >= foo->nextWakeupTick) { > if (foo->successFlag) { > checkForInterrupts(); > } else { > foo->interruptCheckCounter = 0; > } > } > } > } > } > } > > > I would be grateful for any insight as to whether this is the correct change - it seems to profile correctly on my Kubuntu 8.04 > box. > > I am willing to pursue this change back into VMMaker once blessed. > > Brent > >

1 0

VM for this Touch book
by Hilaire Fernandes 24 Apr '10

24 Apr '10

I saw this cool tablette device when browsing the ARM Ltd web site. http://www.alwaysinnovating.com/touchbook/ Any one with experience running the VM on this architecture? Hilaire

1 0

Conflicting type on readImageFromFileHeapSizeStartingAt
by Jean Baptiste Arnaud 23 Apr '10

23 Apr '10

hi, i take the source from svn. I Install Clean VMMaker, generate source (on Mac OS) then : src / interp.c >> sqInt readImageFromFileHeapSizeStartingAt(sqImageFile f, sqInt desiredHeapSize, squeakFileOffsetType imageOffset); Cross / sq.h>> sqInt readImageFromFileHeapSizeStartingAt(sqImageFile f, usqInt desiredHeapSize, squeakFileOffsetType imageOffset); If i correct manually that compile and work . I missing something ? Regard Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

3 2

Re: [Pharo-project] Hints and clues for a Pharo newb
by Eliot Miranda 22 Apr '10

22 Apr '10

On Wed, Apr 21, 2010 at 4:34 PM, Hernán Morales Durand < hernan.morales(a)gmail.com> wrote: > 2010/4/21 Lukas Renggli <renggli(a)gmail.com>: > >> thisContext is a special object for representing an activation in a > >> stack frame in a stack-based VM. > > > > Actually "thisContext" represents *the current* activation/stack-frame. > > > > foo: anObject > > ^ thisContext at: 1 > > > > is the same as > > > > foo: anObject > > ^ anObject > > > > Of course, "this" refers to "the current" in common language usage. > > >> There are two kinds of contexts: > >> Method Contexts and Block Contexts. > > > > Actually in Pharo images there are only instances of MethodContext. > > Though you can ask the context if it comes from a block by sending the > > message #isExecutingBlock. > > > > Actually in Pharo there is a BlockContext class, which is not > instantiated anymore after the introduction of the closure compiler? > Right. > In other Smalltalks aBlockContext is the resulting context of a block > activation during its evaluation and is activated by sending > #value,.this fills thisContext with the execution information inside > the block. > and it is now with the closure compiler. Or rather a new context is created when a BlockClosure is sent the value message. The context is an instance of methodContext though. > In Squeak (or the old compiler) block contexts were created using > #blockCopy:, now I see #closureNumCopied:numArgs:. Does this means > BlockContext could be completely removed and replaced with > MethodContext semantics? I've removed the BlockContext class and used > Pharo a little bit with no problems, maybe some Decompiler issues in > the Debugger... > Yes. But MethodContext behaves differently depending on whether its closureOrNil inst var is nil (a normal method) or a BlockClosure (an activation of a block). If nil, ^-returns return to the context's sender. If not nil ^-returns return from the home context, found by following the outerContext chain through the closureOrNil inst var. So we no longer need BlockContext. This also means we only need one context class, and some time I'd like to merge the two ContextPart and MethodContext classes into a single Context class. Possibly the name should be ExecutionContext or MethodOrBlockContext or? Suggestions? > Now, test yourself before evaluating :) what should be the result of > this expression? > > [: arg | arg perform: #isExecutingBlock ] value: thisContext > It depends on whether the expression is executed at method level or at block level. As a test this should be: testIsExecutingBlock self assert: ([: arg | arg perform: #isExecutingBlock ] value: thisContext) == false. [self assert: ([: arg | arg perform: #isExecutingBlock ] value: thisContext) == true] value Can somebody justify the result? > isExecutingBlock answers if the receiver is executing a block or not. It does not answer whether the context in which isExecutingBlock is sent is executing a block or not. Remember that [:arg| arg == thisContext] value: thisContext is false. thisContext is rebound within every actual method or block scope. HTH Eliot > >> Context creation is optimized in the VM in most Smalltalks, so it's > >> only really created as an object in the environment (reified) when > >> it's specifically needed through "thisContext". > > > > In Pharo contexts are not reified like that. Stack-frames are actual > > objects at all times. However, for speed reasons, their creation and > > garbage-collection is optimized by the VM. Stack frames get > > automatically recycled if nobody refers to them. > > > > I think is what I said :) > But its not a property of Pharo. It is a property of the VM. In Cog contexts are not actual objects all the time, only when needed. And Cog runs Pharo images just as it runs Squeak images. So it would be incorrect to say "in Pharo" and better to say "in the standard Squeak VM". > >> There are several applications related with computational reflection > >> (Reflective Programming, Meta-Programming, MOP, etc) which makes use > >> of the current context. > > > > Also: exception handling, generators, continuations, co-routines, ... > > > > For another fun use of "thisContext" check this Stack-Overflow question: > > > > > http://stackoverflow.com/questions/2500483/is-there-a-way-in-a-message-only… > > > > Lukas > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

3 5

Re: [Pharo-project] FFI in 1.1
by Eliot Miranda 22 Apr '10

22 Apr '10

Hi All, 2010/4/20 John M McIntosh <johnmci(a)smalltalkconsulting.com> > Well I asked for it... > > (a) you can get graphic cut/copy/paste of complex data on the macintosh and > windows. > > (b) I'd rather have people learn FFI & Alien so they can build their own > api to Rome, Pango, & Curl instead of waiting on about 4 people in the world > to get around to building and distributing *official* plugins . > I agree with this, but I also understand the security and modularity concerns of those who want to deploy without FFI and with plugins only. I think it might be worth-while, and would certainly be feasible and fun, to write an automatic plugin generator, e.g. above David's SmartSyntaxPlugin, that would take a set of FFI methods and shrink-wrap them into a plugin. So the natural development cycle for plugins could become prototype and extend using the FFI and deploy via the generator and a plugin compilation step. That would be analogous to the approach taken to produce the VM itself. I hope this approach would make it easier for people to produce plugins, since more of the gubbins <http://www.thefreedictionary.com/gubbins> would be hidden. That might be naive given complications with mapping object and memory references across the boundary, but it might also be an easier way to integrate things like Andreas' proposed handle framework<http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004106.html> . > (c) When your curl, rome, etc FFI call freaks and toasts your image why you > can do debugging, versus relying on a handful of people in the world to > grind thru some compiler, gnu debug session to figure out why that register > move results in a fatal Virtual memory page fault. > Certainly we got some good mileage out of catching external errors in FFI calls and returning these as primitive error codes. Basically it helps you find which FFI calls cause crashes, because the system will typically stay up long enough for you to open the debugger and identify which FFI call failed and what its arguments were. Why the call failed isn't so easy. The errr codes are an address and some OS-specific exception identifier. One then either has to think hard (infer from the args why the call might fail) or decamp to a low-level debugger, rerun the call and use any additional info it provides to debug the call. This is easy to add to the current VM which already has fatal signal handlers and primitive error codes. The FFI must set a flag "in FFI call" (clearing on callback, resetting on return from callback) which is tested in the fatal signal handlers and cause the exception info to be squirrelled away and the FFI call to fail. If the VM has enough state to take a callback it typically has enough state to cause the current FFI callout to fail and from the fatal signal handler longjmp to somewhere that can continue execution through the primitive failure. (and if it doesn't now, it can be made to, and not on every FFI call either, e.g. the interpreter can call setjmp prior to entering the interpreter loop, Cog does this to be able to switch between native code and interpreted code) 2¢ Eliot > > > On 2010-04-19, at 11:41 PM, Torsten Bergmann wrote: > > >> I wouldn't include neither FFI or Alien FFI in neither PharoCore or > PharoDev > >> image. > > > > +1 > > > >> That's only my opinion. > > > > Maybe Stef should tell us more about why he thinks it should be included. > > > > Bye > > T. > > > > -- > > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! > > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

5 4

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev April 2010