Vm-dev March 2010

vm-dev@lists.squeakfoundation.org

33 participants
62 discussions

Re: Some notes about SqueakMap dead in trunk images...
by Andreas Raab 24 Mar '10

24 Mar '10

On 3/15/2010 1:26 PM, Göran Krampe wrote: > But so far I am unclear as to why this is so. I have now tested LOTS of > trunk images backwards and it seems to be broken all the way down to > 7179! Funny thing is - my 3.10.1-7175 image works fine. > > And there may be a hint here: The 7175 image can be opened by an old > 3-9-8 VM. But the later 7179 images can NOT be opened due to some kind > of image format change. Bingo. The issue is that the image format changed for closures and there's been a bug in the image segment loading code that makes the primitive fail in cases where the image format is older, but compatible. I've posted a fix for that in VMMaker but I really think SM should stop using image segments for data exchange. Image segments are not a reliable long-term interchange format in an evolving system. Obviously, this fix requires new VMs. Cheers, - Andreas

5 7

VM handle management
by Andreas Raab 24 Mar '10

24 Mar '10

Folks - [Warning: Long post. Please try to stay on topic and don't get into any SmartSyntaxInterpreterPlugin / FFI syntax digressions that always come up with these issues. This is a practical proposal that I'd like to implement]. For the third time this month I ran into the situation that I was writing a plugin that would create an internal data structure (containing pointers etc) and where I wanted to return a handle to this structure and pass that back to the VM. Since I'm a lazy bastard, what I usually do is something like this in the support code: int sqNewFooBar(void) { /* creates a new foobar and returns a handle */ FooBar *newFoo = malloc(1, sizeof(FooBar)); /* return a handle, sort of */ return (int) newFoo; } void sqDeleteFooBar(int handle) { FooBar *theFoo = (FooBar*) handle; free(handle); } I don't have to tell you how horrible this is and what all the problems with the approach are - I'm sure you're all well aware of it. The question is, how do we fix this? Here's my proposal. I say let's extend the VM with 4 new proxy functions, namely: /* Registers a pointer and returns a handle. The type argument ensures that the handle cannot be forged. */ OOP registerHandleType(void *ptr, char *type); /* Unregister a handle */ void unregisterHandle(void *ptr); /* Look up the pointer for a given handle/pair type */ void* lookupHandleType(OOP handle, char *type); /* Ditto, just based on a stack index */ void* stackHandleValueType(int stackIndex, char *type); With these functions the support code can *always* deal with pointers, never with OOPs. The glue code does the translation between OOP and pointer. As a consequence the above support code becomes: FooBar *sqNewFooBar(void) { /* creates a new foobar and returns it */ FooBar *newFoo = malloc(1, sizeof(FooBar)); return newFoo; } void sqDeleteFooBar(FooBar *theFoo) { /* deletes the FooBar */ free(theFoo); } and the glue code in the plugin becomes: primitiveNewFooBar "Creates a new foobar" | foobar | <var: #foobar type: 'FooBar*'> foobar := self sqNewFooBar. handle := interpreterProxy registerHandle: foobar type: 'FooBar'; interpreterProxy pop: interpreterProxy methodArgumentCount+1 thenPush: handle. primitiveDestroyFooBar "Destroys a foobar" | foobar | <var: #foobar type: 'FooBar*'> foobar := interpreterProxy lookupHandle: (interpreterProxy stackValue: 0) type: 'FooBar'. "or simply: foobar = interpreterProxy stackHandleValue: 0 type: 'FooBar' " foobar ifNotNil:[ interpreterProxy unregisterHandle: foobar. self sqDestroy: foobar. ]. interpreterProxy pop: interpreterProxy methodArgumentCount. What is interesting is that handles are completely opaque structures. They could be integers, byte arrays, whatever representation we choose, the only requirement is that the VM has a handleTable that can look up these pointers. The obvious advantages of such a scheme are: * It's safe. We don't expose a pointer but rather a handle that the VM knows about and that does not expose any dangerous internals. * It's secure. By passing the additional "type" argument you can ensure that only handles registered as that type are used. I.e., no passing a SocketPtr into the FilePlugin. * It's simple. I've written at least three handle management implementations and I'm getting sick and tired of it. * It allows sharing. For example, OSProcessPlugin likes to do manipulate and register / deregister file handles, and can now safely look up the internal structure from the handle. (there are some issues here but they are no worse than what OSProcess already does) If you agree, I'd like to implement this scheme and rewrite SocketPlugin and FilePlugin as examples for how to use such handles. They are already places that expose a ton of pretty risky information and it'd be a good example for how to utilize handles. Cheers, - Andreas

5 7

primitiveVMPath
by Ang BeePeng 23 Mar '10

23 Mar '10

int primitiveVMPath(void) { int sz; int s; sz = vmPathSize(); s = instantiateClassindexableSize(splObj(6), sz); vmPathGetLength(s + 4, sz); pop(1); push(s); } int vmPathSize(void) { return strlen(vmPath); } int vmPathGetLength(int sqVMPathIndex, int length) { char *stVMPath = (char *) sqVMPathIndex; int count, i; count = strlen(vmPath); count = (length < count) ? length : count; /* copy the file name into the Squeak string */ for (i = 0; i < count; i++) { stVMPath[i] = vmPath[i]; } return count; } Hi, I'm looking at win32 SqueakVM code. The above confuse me. In function vmPathGetLength(), count is strlen of vmPath, while length(or sz) is also strlen of vmPath. vmPathGetLength() is only used in function primitiveVMPath(). Why do we need the checking? Thanks. Ang Beepeng -- View this message in context: http://n4.nabble.com/primitiveVMPath-tp1679365p1679365.html Sent from the Squeak - VM mailing list archive at Nabble.com.

1 0

Alien for Win32 too
by Torsten Bergmann 23 Mar '10

23 Mar '10

Andreas wrote on squeak-dev: >The main reason for using Alien today is callbacks. There is still no >support for callbacks in the FFI so if you need callbacks Alien is your >choice. Any chance we can get Alien support included into the official Win32 VM and therefore provide callback support on Windows too? So one at least is able to have that choice you are talking about? Alien is AFAIK easily usable on all major platforms, except Windows. There were various mails on pushing all that forward, also the code was provided by Marco and it seems like we have to take two final steps to get it included (clearify your license question and if OK the final code integration into the official VM source) So again: Would you please respond on [1]/[2] so we can hopefully move forward here! I would really like to see callback support on Windows too (however it is done Alien or FFI) to move other projects (like a general COM/Java interface, ... ) forward. It's still a shame that Squeak is light years behind other programming environments on interfacing with the outside world... Bye T. [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004054.html [2] http://bugs.squeak.org/view.php?id=7475 -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

2 1

PrimitiveFailFor:
by Jean Baptiste Arnaud 19 Mar '10

19 Mar '10

#PrimitiveFailFor: disappear ? Why ? How can we handle specific exception, now ? Regard Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

2 1

VMMaker small problem for pharo developper
by Jean Baptiste Arnaud 19 Mar '10

19 Mar '10

hi, I have see the immutability bit implementation and i think, it can be easily integrate in the actual VM, the main problem is VMMaker, especially the difference existing between Pharo and Squeak, using VMMaker on Pharo imply to patch it (only small difference, deprecated method, changing method name ), then the main problem is i can change the VM on pharo without creating a incompatible VM for squeak(cause of the patching). Then i just want to find a solution to have exactly the same version of VMMaker on squeak and pharo. then if someone want to contribute, he can, regardless of this environment . Then i want to contribute, but i can't. any solution ? Regard Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

7 14

[Vm-team] New VM builds to support Squeak 4.1 release (was: [squeak-dev] 4.1 release tasks)
by David T. Lewis 19 Mar '10

19 Mar '10

Ian, John, Andreas: To support the upcoming Squeak 4.1 release (relicensed Squeak plus subsequent trunk development), we would like to provide updated VMs for all platforms over the next two weeks (target April 4 for completion). The purpose of this message is to start a thread on vm-dev to drive completion of the "Ensure current VMs" task from Andreas' task list, see below. I'm not sure that I'm entirely up to speed on our open issues (sorry), but I think that the following needs to be done: - Merge and adopt John's 64-bit and iPhone changes (John, need guidance as to specific things we need to include for 4.1). - Complete the SoundPlugin patches for 64-bit (or I will roll back the VMMaker patches until a later date if this cannot be easily completed). - Updates to support John's microsecond timer changes for profiling. - Review open Mantis issues for critical open concerns (my responsibility). - If possible, include FT2Plugin in builds (important for Pharo folks, not essential for Squeak 4.1 support). - Do the builds. On Wed, Mar 17, 2010 at 11:11:24PM -0700, John M McIntosh wrote: > > On 2010-03-17, at 8:28 PM, Andreas Raab wrote: > > > [ ] Ensure current VMs > > What: Ensure that all platforms have current VMs available, with all required fixes applied. > > Who: VM maintainers > > When: April 4th > > To do this I'll need some help folding the 64bit changes from macintosh squeak 5.x and the iphone port back into the tree John, let me know how and if I can help. Given the short timeline, we should focus on essential changes that should be supported also by win32 and unix. I'm not clear on which things are needed in the near term. For reference, the Squeak 4.1 release tasks thread is here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147166.ht… And Andreas' original posting is repeated below: On Wed, Mar 17, 2010 at 08:28:56PM -0700, Andreas Raab wrote: > Folks - > > As stated in the previous message, here is a thread to gather release > tasks and the time frame in which they should be addressed. I'm taking > the "4 weeks to release" rather literally below because I want to avoid > excessive discussions about what we should do with feature x or y. > Rather, I'm saying let's ship it as it is, get it out quickly, and spend > our time moving forward from there. With that said, here we go: > > [ ] Build a 4.1alpha trunk image > What: We need to re-apply all the changes that went into trunk on top of > 4.0 to create a proper 4.1 alpha. I'm planning to do this by the weekend > and remove the previous trunk images since they're now obsolete. > Who: Andreas > When: March 20th > > [ ] Feature Freeze trunk > What: Feature freeze the trunk. Only fixes for identified issues go in. > Who: All core-devs. > When: March 28th > > (this gives us one more week if you have anything that you feel strongly > about) > > [ ] Make tests green > What: Review all the tests on all platform; identify failing tests, make > them pass or document known failures. > Who: ??? > When: April 4th (this is a bit of wishful thinking...) > > [ ] Ensure current VMs > What: Ensure that all platforms have current VMs available, with all > required fixes applied. > Who: VM maintainers > When: April 4th > > [ ] Create a 4.1 release repository on source.squeak.org > What: Create a release repository that we can point the release image to > for subsequent 4.1 maintenance updates. > Who: Any source.squeak.org admin > When: ASAP. > > [ ] Identify Mantis bugs that should be in 4.1 > What: Categorize bugs that need to be looked at for the 4.1 release > (does NOT imply fixing the bugs) > Who: Everyone. > When: April 4th. > > [ ] Build release candidates > What: Start building release candidates to ensure we have a process. > Casey probably still has a few make files around. > Who: ??? > When: Ongoing. > > [ ] Write welcome message, press release > What: Write a welcome message, overview of changes, press release etc. > Who: ??? > When: April 4th. > > As a time line we get: > > ASAP: > - Create 4.1 release repository > > March 20th: > - Build a 4.1alpha trunk image > > March 28th: > - Feature Freeze > - RC1 build > > April 4th: > - Green tests > - Updated VMs > - Mantis bugs organized > - Welcome message, press release > - RC2 build > > April 11th: > - All bugs fixed (yeah, right :-) > - RC3 build > > April 17th: > - Ship date > > This is obviously a tight schedule but if we want to get the puppy out > in four weeks we need to get schtuff done. I don't think it's > unreasonable though; all the tasks are doable on their own, we just need > a few people to step up and pick one they can help with. > > Cheers, > - Andreas

2 3

Build VM with FT2Plugin on Linux
by laurent laffont 19 Mar '10

19 Mar '10

Hi, to compile the VM with FT2Plugin on Linux I have to: 1. FT2Plugin class >> declareCVarsIn: change cg addHeaderFile: '<tttables.h>'. to cg addHeaderFile: '<freetype/tttables.h>'. 2. Patch unix/cmake/Plugins.cmake with this patch http://lolgzs.free.fr/pharo/Plugins.cmake.patch 3. Create unix/plugins/FT2Plugin/config.cmake with: PLUGIN_REQUIRE_PACKAGE(FT2 freetype2) Are these issues Linux specific ? Is it possible to integrate these changes ? Cheers, Laurent Laffont

1 0

what's happening when the vm is a shared library
by Stefan Krecher 18 Mar '10

18 Mar '10

Hi, i'm working on the "squeak on android" Project (but i'm absolutely new to squeak-vm-hacking): http://code.google.com/p/squeak-android-vm/ currently i try to get the socket-stuff working - with limited success :-( The squeak vm is a shared library compiled with the android-ndk and wrapped by an android-java app, making jni-calls. Though the SocketPlugin does compile with the ndk, any call to the Plugin produces a primitiveFailed-Exception. Even when i replace the code of a primitive with dummy-code that returns static values and does not execute any plattform-specific code. Do i need to redirect the primitive-calls somehow through the java-app and make calls to the shared-library, or should the primitives just work on android? would be greateful for any tips/ hints/ discussions ... regards, Stefan -- Dipl.-Wirtsch.-Inf. Stefan Krecher Neulander Str. 17, 27374 Visselhövede Tel +49(0)4262 958848 mobil +49(0)172 3608616 http://krecher.com

3 5

Is Smalltalk>>#vmVersion correct?
by Chris Muller 16 Mar '10

16 Mar '10

I thought I was running the new VM, but I'm getting 'Squeak3.10.2 of ''5 June 2008'' [latest update: #7179]'. Has this been updated in the VM or do I have a problem?

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev March 2010