Vm-dev February 2010

vm-dev@lists.squeakfoundation.org

18 participants
32 discussions

[commit] r2149 - Add ExternalForm patches from Josh.
by commits＠squeakvm.org 11 Feb '10

11 Feb '10

Author: andreas Date: 2010-02-11 00:23:28 -0800 (Thu, 11 Feb 2010) New Revision: 2149 Added: trunk/platforms/Cross/plugins/SqueakFFIPrims/sqManualSurface.c Modified: trunk/platforms/Cross/plugins/SqueakFFIPrims/sqFFI.h Log: Add ExternalForm patches from Josh. Modified: trunk/platforms/Cross/plugins/SqueakFFIPrims/sqFFI.h =================================================================== --- trunk/platforms/Cross/plugins/SqueakFFIPrims/sqFFI.h 2010-01-12 06:28:45 UTC (rev 2148) +++ trunk/platforms/Cross/plugins/SqueakFFIPrims/sqFFI.h 2010-02-11 08:23:28 UTC (rev 2149) @@ -6,7 +6,7 @@ * AUTHOR: Andreas Raab (ar) * ADDRESS: Walt Disney Imagineering, Glendale, CA * EMAIL: andreasr(a)wdi.disney.com -* RCSID: $Id: sqFFI.h,v 1.1 2001/10/24 23:12:24 rowledge Exp $ +* RCSID: $Id$ * * NOTES: * @@ -128,5 +128,23 @@ /* return the float value from a previous call */ double ffiReturnFloatValue(void); +/* The following are for creating, manipulating, and detroying "manual surfaces". + These are surfaces that are managed by Squeak code, which has manual control + over the memory location where the image data is stored (the pointer used may + be obtained via FFI calls, or other means). + + Upon creation, no memory is allocated for the surface. Squeak code is + responsible for passing in a pointer to the memory to use. It is OK to set + the pointer to different values, or to NULL. If the pointer is NULL, then + BitBlt calls to ioLockSurface() will fail. + + createManualFunction() returns a non-negative surface ID if successful, and + -1 otherwise. The other return true for success, and false for failure. +*/ +#include "../SurfacePlugin/SurfacePlugin.h" +void initManualSurfaceFunctionPointers(fn_ioRegisterSurface reg, fn_ioUnregisterSurface unreg, fn_ioFindSurface find); +int createManualSurface(int width, int height, int rowPitch, int depth, int isMSB); +int destroyManualSurface(int surfaceID); +int setManualSurfacePointer(int surfaceID, void* ptr); #endif /* SQ_FFI_H */ Added: trunk/platforms/Cross/plugins/SqueakFFIPrims/sqManualSurface.c =================================================================== --- trunk/platforms/Cross/plugins/SqueakFFIPrims/sqManualSurface.c (rev 0) +++ trunk/platforms/Cross/plugins/SqueakFFIPrims/sqManualSurface.c 2010-02-11 08:23:28 UTC (rev 2149) @@ -0,0 +1,164 @@ +#include "sqFFI.h" +#include "sq.h" + +#include "sqVirtualMachine.h" +extern struct VirtualMachine* interpreterProxy; + +/* Need separate cases for GNU C and MSVC. */ +#ifdef DEBUG +#warning "DEBUG printing enabled" +#define DPRINTF(x) warnPrintf x +#elif defined(_DEBUG) +#pragma message ( "DEBUG printing enabled" ) +#define DPRINTF(x) warnPrintf x +#else +#define DPRINTF(x) +#endif + +#ifndef NULL +#define NULL 0 +#endif +#ifndef FALSE +#define FALSE 0 +#endif +#ifndef TRUE +#define TRUE 1 +#endif + +/* Don't want to mess with EXPORT status of functions in SurfacePlugin.c, + we use function-pointers here. */ +static fn_ioRegisterSurface registerSurface = NULL; +static fn_ioUnregisterSurface unregisterSurface = NULL; +static fn_ioFindSurface findSurface = NULL; +void initSurfacePluginFunctionPointers() +{ + registerSurface = (fn_ioRegisterSurface) interpreterProxy->ioLoadFunctionFrom("ioRegisterSurface","SurfacePlugin"); + unregisterSurface = (fn_ioUnregisterSurface) interpreterProxy->ioLoadFunctionFrom("ioUnregisterSurface","SurfacePlugin"); + findSurface = (fn_ioFindSurface) interpreterProxy->ioLoadFunctionFrom("ioFindSurface","SurfacePlugin"); +} + +/* This is the structure that represents a "manual surface". These are + created/destroyed by new primitives in this plugin. During it's life-time, + it may be touched directly from Squeak code to set/clear "ptr", and also + treated as a generic surface via BitBlt's use of the SurfacePlugin. */ +typedef struct { + int width; + int height; + int rowPitch; + int depth; + int isMSB; + void* ptr; + int isLocked; +} ManualSurface; + +/* Create the dispatch-table that SurfacePlugin will use to interact with + instances of "struct ManualSurface" */ +static int manualSurfaceGetFormat(ManualSurface* surface, int* width, int* height, int* depth, int* isMSB); +static void* manualSurfaceLock(ManualSurface* surface, int *pitch, int x, int y, int w, int h); +static int manualSurfaceUnlock(ManualSurface* surface, int x, int y, int w, int h); +static int manualSurfaceShow(ManualSurface* surface, int x, int y, int w, int h); +static sqSurfaceDispatch manualSurfaceDispatch = { + 1, + 0, + (fn_getSurfaceFormat) manualSurfaceGetFormat, + (fn_lockSurface) manualSurfaceLock, + (fn_unlockSurface) manualSurfaceUnlock, + (fn_showSurface) manualSurfaceShow +}; + +/* sqSurfaceDispatch functions *****************************************************************************/ + +int manualSurfaceGetFormat(ManualSurface* surface, int* width, int* height, int* depth, int* isMSB) { + *width = surface->width; + *height = surface->height; + *depth = surface->depth; + *isMSB = surface->isMSB; + DPRINTF(("Getting Surface Format: %lx %d %d %d %d\n", ((int) surface), *width, *height, *depth, *isMSB)); + return 1; +} + +void* manualSurfaceLock(ManualSurface* surface, int *pitch, int x, int y, int w, int h) { + /* Ideally, would be atomic. But it doens't matter for the forseeable future, + since it is only called via BitBlt primitives. */ + int wasLocked = surface->isLocked; + surface->isLocked = 1; + + /* Can't lock if it was already locked. */ + if (wasLocked) return NULL; + + /* If there is no pointer, the lock-attempt fails. */ + if (!surface->ptr) { + surface->isLocked = 0; + return NULL; + } + + /* Success! Return the pointer. */ + *pitch = surface->rowPitch; + DPRINTF(("Locked Surface: %lx Input Rect: %d %d %d %d Row Pitch: %d\n", ((int) surface), x, y, w, h, *pitch)); + return surface->ptr; +} + +int manualSurfaceUnlock(ManualSurface* surface, int x, int y, int w, int h) { + surface->isLocked = 0; + DPRINTF(("Unlocked Surface: %lx Rect: %d %d %d %d\n", ((int) surface), x, y, w, h)); + return 1; +} + +int manualSurfaceShow(ManualSurface* surface, int x, int y, int w, int h) { + /* Unsupported */ + return 0; +} + +/* primitive interface functions (i.e. called from Squeak) *********************************************/ + +/* Answer non-negative surfaceID if successful, and -1 for failure. */ +int createManualSurface(int width, int height, int rowPitch, int depth, int isMSB) { + ManualSurface* newSurface; + int surfaceID; + int result; + + if (width < 0) return -1; + if (height < 0) return -1; + if (rowPitch < (width*depth)/8) return -1; + if (depth < 1 || depth > 32) return -1; + if (!registerSurface) return -1; /* failure... couldn't init function-pointer */ + + newSurface = (ManualSurface*)malloc(sizeof(ManualSurface)); + if (!newSurface) return -1; + newSurface->width = width; + newSurface->height = height; + newSurface->rowPitch = rowPitch; + newSurface->depth = depth; + newSurface->isMSB = isMSB; + newSurface->ptr = NULL; + newSurface->isLocked = FALSE; + + result = registerSurface((int)newSurface, &manualSurfaceDispatch, &surfaceID); + if (!result) { + /* Failed to register surface. */ + free(newSurface); + return -1; + } + else { + return surfaceID; + } +} + +int destroyManualSurface(int surfaceID) { + if (!unregisterSurface) return 0; /* failure... couldn't init function-pointer */ + else return unregisterSurface(surfaceID); +} + +int setManualSurfacePointer(int surfaceID, void* ptr) { + int surfaceHandle; + ManualSurface *surface; + int result; + if (!findSurface) return FALSE; /* failure... couldn't init function-pointer */ + result = findSurface(surfaceID, NULL, &surfaceHandle); + if (!result) return FALSE; /* failed to find surface */ + surface = (ManualSurface*)surfaceHandle; + if (surface->isLocked) return FALSE; /* can't set pointer while surface is locked */ + surface->ptr = ptr; + DPRINTF(("Set Surface: %lx Pointer: %lx\n", surfaceID, ((int)ptr) )); + return TRUE; +}

1 0

a question about sqInt displayObject(void)
by John M McIntosh 10 Feb '10

10 Feb '10

Ok, I'm working on an iPhone project where I have to consider what is going on with the Squeak Drawing cycle. The original logic takes the ioShowDisplay(dispBitsIndex, w, h, d, left, right, top, bottom); and builds CGImageRefs from the dispBitsIndex data. This is an immutable object and actually uses Copy On Write Virtual Paging logic to ensure what the bits were when ioShowDisplay was called are what they will be when it's drawn. Usually ioShowDisplay is followed by a ForceDisplayUpdate which would then trigger the VM to take the queue of CGImageRefs (zero or more) and draw them to the screen. This entails invalidating the combined rectangle(s), and waiting for the video sync logic to catch up and render the CGImageRef(s) to the drawing surface. There is a case where if you use warpblt then showDisplayBitsLeftTopRightBottom is uses and doesn't do the ioForceDisplayUpdate. This is triggered by the primitive 231 code. However on both the Macintosh and iPhone I have a dead man's timer and fire the primitiveForceDisplayUpdate if a draw is pending and oh say about 20 millisecond passes. This ensure the queue doesn't go to infinity (I've a production example of that...) This works fine on os-x because we write to a window backing store but only flush the data to the window server for drawing based on the forceupdate. But on the iPhone it's different. We draw the CGImageRefs, BUT at some point the graphic layer can flush the content or part of the content and expect you to redraw eveything. However I don't have any of that information, or I didn't think I did, so I get black chunks of nothingness.... I've moved from something rather complex, tricky and broken on the iPhone to something more simple which makes a copy of all the drawing. But it's painfully slow. Last night I got to thinking, where *does* the data come from. So it appears and people can help confirm this, that Squeak *always* draws the data to the pointer in specialObjectsOops ->TheDisplay, found via sqInt displayObject(void). I recall that Tim had a hook for the ARM code to make the memory pointer not point to an area in Squeak OOps space, but to point it to video memory? Anyway I'm thinking here I should be able to at ForceDisplayUpdate time take the recorded rectangle data from ioShowDisplay and pull the bits directly from specialObjectsOops ->TheDisplay So anyone think this is not feasible? I'd also look at doing this on OS-X since it avoids building the intern CGImageRefs. ioShowDisplay displayBitsOfLeftTopRightBottom fullDisplayUpdate Platform usage, not used on mac. !ioForceDisplayUpdate! primitiveShowDisplayRect !ioForceDisplayUpdate! Primitive 127 Via DisplayScreen>>primShowRectLeft:right:top:bottom: Via DisplayScreen>>primRetryShowRectLeft:right:top:bottom: reverseDisplayFromto debugging code used by DoAssertionChecks !ioForceDisplayUpdate! showDisplayBitsLeftTopRightBottom **** only user of deferDisplayUpdates various places from BitBlt Plugin primitiveForceDisplayUpdate Primitive 231 sqInt displayObject(void) { return longAt((foo->specialObjectsOop + BaseHeaderSize) + (TheDisplay << ShiftForWord)); } -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

3 2

Question about primitives
by Mariano Martinez Peck 10 Feb '10

10 Feb '10

Hi folks. Disusing with a friend, he asked me if Squeak was completely written in itself (actually, SLANG). I think (I am not sure) that some parts of the VM as Interpreter, ObjectMemory, and most primitives are written in SLANG and then using VMMaker I can convert from that to C. Ok.....but...I think I heard that there are primitives that are directly written in C (not SLANG, no translation). Is this true ? If true, how can be that addressed ? where is the C code of that? because, I take VMMaker, I convert to C, then compile, install and I have a working VM. So...that C code must come somewhere...where is it ? how can I know if a primitive is written in SLANG or directly in C? I hope someone can help this newbie :) Thanks in advance, Mariano

7 21

Re: [squeak-dev] [ANN] VMMaker metacello config for Squeak and Pharo
by Torsten Bergmann 08 Feb '10

08 Feb '10

Andreas wrote: >I am not interesting in arguing. +1 >Things seem to have improved significantly from when I last looked at it, >which is good news. Yes. I will try to keep this separate metacello config for vmmaker maintained, but as I said I need a minimal support from vm-maintainers side to get notified when load order or packages change. Thanks in advance! David wrote: >I'm also happy to see the Metacello support, because it will make >VMMaker more accessible from images that do use Metacello. Thank you. Yes that was the goal. If a project is easy accessible more people are able to use it or learn or help. Thanks Torsten -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02

1 0

[ANN] VMMaker metacello config for Squeak and Pharo
by Torsten Bergmann 06 Feb '10

06 Feb '10

Hi, (crosspost vm-dev, squeak-dev, pharo-dev) with more and more Metacello configurations for various well known Squeak and Pharo packages appearing in the metacello repository [1] I thought it would be a good idea to have one for VMMaker. It is based on a description by David (see [2]) and maybe he is able to help me keeping it maintained. Since Metacello is Smalltalk independent and therefore able to handle differences between the deployment systems the new 'ConfigurationOfVMMaker' includes two platform spec's - one for #pharo and one #squeak. (Pharo has FreeType preinstalled, and Squeak not). Unfortunately the Balloon3D stuff needs a little bit more cleaning (underscores, assigns to block args). Maybe Andreas is able to fix this. Until then one has to switch a preference in Pharo. However: it should be easy now to load and use VMMaker in both: In Squeak 3.11 #9236 ==================== Installer ss project: 'MetacelloRepository'; install: 'ConfigurationOfVMMaker'. ((Smalltalk at: #ConfigurationOfVMMaker) project version: '1.0') load In Pharo (core or dev) evaluate: ================================ Preferences setPreference: #allowBlockArgumentAssignment toValue: true. Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfVMMaker'; load. ((Smalltalk at: #ConfigurationOfVMMaker) project version: '1.0') load Feel free to have a look or use it to build shiny new VM's for the next interesting devices. For more infos on Metacello see [3] and [4]. Bye T. ------------------------------------------------------------------------------------ [1] http://squeaksource.com/MetacelloRepository.html [2] http://n4.nabble.com/Package-name-SharedPool-Speech-SharedPool-FFI-etc-td12… [3] http://code.google.com/p/metacello/ [4] http://gemstonesoup.wordpress.com/2010/01/25/metacello-1-0-beta22-launches/ -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

3 3

Re: [squeak-dev] [ANN] VMMaker metacello config for Squeak and Pharo
by Torsten Bergmann 06 Feb '10

06 Feb '10

Hi Keith, >It's is not "just a package manager" it is huge and totally over >engineered for the purpose you have in mind. I dont care if you think it is over engineered in it's internal core. The specs are easy to write and I can maintain/load them with Monticello. I can continue to use both: Squeak and Pharo for projects. And I can load my projects code and throw Metacello's overengineered code out of the image easily afterwards. It's just a vehicle. Since the spec is parsable I can switch if someone provides something better in the future. Currently it is available, maintained and working. Is Bob/Sake project meanwhile with public access? Are you back in Bob/Sake business? >VMMaker is at a far lower level than Seaside or other things >Metacello is being used for. Yes, like FFI, ExternalWebBrowsers, SQLite3 or others which are available via configurations. You may say it is overkill for such small projects - but you can construct more complex configs (like Seaside) from that. >... You can put scripts into InstallerScripts to be loaded using ... I know all this - but a) I want something that works on Squeak, Pharo, Gemstone, maybe other ST's later (since I use Seaside) b) I want to maintain versions in one file (here in one class) not in separate scripts for each version. I can use Monticello diffs to see how the config has changed, ... c) I want a declarative description instead of code since I may use it for other purposes too (deployment and dependency tools, ...) >I could comment on the rest of your post, I basically disagree with >pretty much everything you say. No problem for me ... you dont have to use it. It doesnt change anything on VMMaker or prevents you from using other loaders/installers. >Can Metacello publish and use definitions on a web page or wiki, can >it load from squeakmap, or universes, can it access published bug >fixes, can you override with your own local definitions, can it >bootstrap from the source.st code inside a monticello package. Again: Metacello does not care about SqueakMap, Universe, Mantis since it is not bound to Squeak. You compare apples with oranges. Lets play a short game: You will find ConfigurationOfMetaSource in the MetaSource project on SqS, that is able to load a whole seaside app right from a core image and keep it maintained with new versions. Show me that Installer/Sake/Bob is doing better here and is aligned with the goals in a) b) and c) Bye T. -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02

2 2

Error after building.
by Andrey Larionov 06 Feb '10

06 Feb '10

I download source distribution of latest available VM (3.11.3). Run configure, which notifies my about disabling vm-sound-OSS, but after building ./squeak script, try to start vm with vm-sound-OSS plugin. And fail. Also i want to ask, is there any installation target in build files?

2 1

Re: [squeak-dev] [ANN] VMMaker metacello config for Squeak and Pharo
by Torsten Bergmann 06 Feb '10

06 Feb '10

Hi Andreas, a simple question: why do you warn others about "jumping heads-on" into a "frenzy" technology, when you never had a deeper look at Metacello or the simple config I provided for VMMaker? I havent changed a single package in VMMaker, the loading order, etc. you can continue to load and use VMMaker as before. Even in your own custom images. Nothing has changed!!! The only thing that is different now is that there is an easy way for Metacello users to load VMMaker into Squeak or Pharo. If you dont like Metacello - no problem - you dont have to use it. As I said - the config is just additionally available. One can use it or ignore it - but we need feedback from David or other VM maintainers (like you) about the VMMaker Monticello package dependencies and Monticello file versions to keep this config maintained. If they change it would be good to update the config. Nothing more! >Given the dependencies of Metacello itself I think there is an actual >risk of that happening Please enlighten me. Where do you see that risk? Did we introduce a dependency for VMMaker on Universe or SqueakMap code when we registered VMMaker there? No! Sample applies to Metacello. >BTW, it is unfair to spam your message to both Squeak-dev and the Pharo >list just to paint me as a nay-sayer in the community. Now you are the one who is interpreting! I wrote my original mail and the response to all three lists and since I use a web browser for reading (sqf.org/pipermail) and answering (GMX) I didnt notice that you responded only on vm-dev. This is also the reason why I constantly create new threads (sorry guys). I think you paint yourself as nay-sayer. Why do you warn about someting that help others to move forward. When you work with VMMaker day by day it is easy for you to follow all the package changes and stay on track. But if someone wants to build a VM he will not start with google and search for the right packages. He will just load it with all dependencies. Metacello provides an easy way to do that. Nothing more. >If there are none, that's great. However, the last time I loaded some >Metacello stuff (which is a couple of weeks ago) it pulled in all sorts >of things including OmniBrowser and left some modification in other >packages. Will you blame Metacello for loading something that was depending on OmniBrowser or that someone created a configuration with packages overriding others? Then help to clean the config. Metacello is a vehicle to describe package dependencies and versions that fit together. You can even unload it easily after it brought in the code. Again - please invest a few minutes in learning about metacello! Thanks T. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

2 1

Re: [squeak-dev] [ANN] VMMaker metacello config for Squeak and Pharo
by Torsten Bergmann 06 Feb '10

06 Feb '10

Andreas Raab wrote: >Let's be a bit careful before jumping heads-on into the Metacello >frenzy. Somehow I knew before that you will respond like this ... ;) >I don't mind if people choose to use Metacello to load VMMaker >but it shouldn't be the only option. Hey - Metacello is "just" a package management tool for Monticello using descriptions of the dependencies and the versions that fit together. Anything I did was to create such a configuration. Nobody forces you or other developers to use Metacello - having such an (additional) config does not change the way you are working right now. Use Monticello, SqueakSource, ... as you did before. You can continue to use build scripts, installers, SqueakMap, Universe, whatever ... to load VMMaker. But currently I dont see none of these "loaders" is well maintained (or only with private scripts), anything I've found was a decription from David (see last mail) on the web. And how often does one ask which packages in which version fit together to get VMMaker or other Squeak projects to work. Try to rebuild the SqueakSource server and you know what I'm talking about! Providing and maintaining a metacello spec is simple and works. And the interesting thing is that someone (Dale) is actively maintaining this tool on several Smalltalks - even for Squeak. And as Fernando responded on the pharo list: "And the ConfigurationOfXXX is allowing a new form of communication , unthinkable just a couple of months ago...." Metacello easily allows to have reproducable builds for projects, applications, images ... (see http://astares.blogspot.com/2010/01/pharo-10-release-candidate-2-and-image.…) Someone requires VMMaker in a specific version - just point him to "ConfigurationOfVMMaker" and you are done. >Myself for example, I use customarily a variety of images, none of which >support or are supported by Metacello. Two things - this has nothing to do with Metacello. Your images dont have to have Metacello. So it is just an additional configuration, so why will you bother - it will not affect the way you worked before - it is not the problem of the Squeak community if you use non-Squeak images to build VM's. As community we all have to assure that VMMaker and its loading (with or without Metacello) is well known and works on standard images and the loading and VM building is reproducable by ANYONE! Does the term "Truck Factor" ring a bell? At least your images seem to be able to use Monticello - so why lament. You can continue to work as before and if David could invest a minute to save others from annoying questions about VMMaker loading everything is in good shape and even free's some time in the long term. >It would not be good if we require Metacello to load VMMaker. Is the Linux project in trouble when one create's and publishes a CD with linux packages that fit together? No! Same applies here. You should really have a look first before commenting on Metacello... Bye T. -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02

4 6

[ANN] VMMaker metacello config for Squeak and Pharo (update 1.1.)
by Torsten Bergmann 05 Feb '10

05 Feb '10

Hi, the Balloon 3D stuff was already clean up - no preference change necessary in Pharo! I created a version 1.1 in the configuration with the latest package versions. So you just have to use 1.1 instead of 1.0: In Squeak 3.11 #9236 ==================== Installer ss project: 'MetacelloRepository'; install: 'ConfigurationOfVMMaker'. ((Smalltalk at: #ConfigurationOfVMMaker) project version: '1.1') load In Pharo (core or dev) evaluate: ================================ Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfVMMaker'; load. ((Smalltalk at: #ConfigurationOfVMMaker) project version: '1.1') load Now you should be able to open VMMaker from the world menu. Short Metacello tips: ==================== If you want to see your (platform) spec for 1.1 just print: ((Smalltalk at: #ConfigurationOfVMMaker) project version: '1.1') spec If you want to see the packages loaded in 1.1. print: ((Smalltalk at: #ConfigurationOfVMMaker) project version: '1.1') packages Have fun! Bye T. -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev February 2010