Vm-dev January 2010

vm-dev@lists.squeakfoundation.org

28 participants
47 discussions

ffi-test-main.c fails on FreeBSD
by Gary Dunn 12 Aug '16

12 Aug '16

In conjunction with getting Open Cobalt running on FreeBSD I have been looking into the problems with SqueakFFIPrims on FreeBSD and have reached a point that is beyond my understanding. I am not sure if the fix should come from the VM side or the FreeBSD port maintainer. I needed to get source code back into the ports tree so I did a make in /usr/ports/lang/squeak. I already had the 3.9 tarball, so that just repopulated the source and did the initial build. In the "files" folder I found patch files typical for a FreeBSD port. These patch source files from a generic tarball to work with FreeBSD. The one of interest was patch-platforms__unix__plugins__SqueakFFIPrims__ffi-config which contains ----x-----x----- --- platforms/unix/plugins/SqueakFFIPrims/ffi-config.org Wed Apr 26 20:27:53 2006 +++ platforms/unix/plugins/SqueakFFIPrims/ffi-config Wed Apr 26 20:29:00 2006 @@ -39,6 +39,7 @@ case ${abi} in linux) abi=sysv;; + freebsd*) abi=sysv;; darwin*) abi=darwin;; *) abi=libffi; lib="-lffi";; esac -----x-----x----- I then had the folder work/Squeak-3.9-7/platforms/unix/plugins/SqueakFFIPrims In it is a file 00README which explains how to test FFI. It says to run ffi-test-config but I have no such file. It says to type "make" to build a test suite but the build failed. It says to try with make CPU=any ABI=libffi LIB=-lffi which also failed. I traced the problem to the gcc search paths for includes and libraries -- turns out FreeBSD only searches /usr/include and /usr/lib when the required files are in /usr/local/include and /usr/local/lib. After some fiddling I finally had a "main" to test. It failed: ffi-test-main.c failed at line 361. Here is a bit from that file, ending with line 361: ffiInitialize(); for (ul= 0; ul < 15; ++ul) ffiPushSingleFloat(fa[ul]); GO(FFITypeSingleFloat, many); f= ffiReturnFloatValue(); ffiCleanup(); CHECK(f - ff < FLT_EPSILON); I worked out the CHECK macro but could not find what FLT_EPSILON is. At that point I decided to stop and come to you for help. Where do I go from here? -- Gary Dunn, Honolulu osp(a)aloha.com http://openslate.net/ http://e9erust.blogspot.com/ Sent from Slate001

5 8

Profiling and delay accuracy
by Andreas Raab 06 Aug '11

06 Aug '11

Hi Folks - For a long time now I had this feeling that MessageTally reports pretty bogus results in many situations without being able to precisely track down why this would be the case. Today I was looking at primitiveResponse() and, much to my surprise, noticed that the checkForInterrupts() that used to be there for years is gone (see Squeak3.6 for example which still has it). The sole reason for this check was to get both high delay accuracy and good profiling behavior. Consider this example: fc := FormCanvas on: Display. MessageTally spyOn:[ 1 to: 100 do:[:i| fc fillColor: Color white. fc printString. ]. ]. Using 3.6 this will be measured correctly as: **Tree** 87.5% {243ms} FormCanvas>>fillColor: |87.5% {243ms} GrafPort>>fillRect:offset: | 87.5% {243ms} GrafPort>>copyBits 12.5% {35ms} FormCanvas(Object)>>printString 12.5% {35ms} FormCanvas(Object)>>printStringLimitedTo: whereas the 3.10 reports it as **Tree** 99.6% {670ms} FormCanvas(Object)>>printString 94.9% {639ms} primitives 4.6% {31ms} FormCanvas(Object)>>printStringLimitedTo: I think you can see the problem and just imagine what this does to any cumulative results. I also wonder what that change does to platforms that don't have high-resolution asynchronous timers. This used to be the one place where we would catch timer changes at high resolution and unless the platform forces high resolution timer interrupts asynchronously (by resetting the interrupt counter) we must be loosing a lot in terms of delay accuracy. (it just so happens that the Windows VM *does* do asynchronous timer interrupts so I never noticed this but I'm very curious about the difference on Linux which typically still has pretty bad timer granularity). Any opinions? My feeling is that the timer check should go back in for all of the above reasons. At the very least a quickCheckForInterrupt() is required but I actually think putting the full check back in is worth it. Cheers, - Andreas

3 3

Joys of Squeak-dev image, VM Compiling on MacIntel and Spoon remote OtherBrowsing
by Ken G. Brown 16 Nov '10

16 Nov '10

MacPro OS X 10.4.9 Xcode 2.4.1 Squeak-dev-114-2, VMMaker 2.8b6.1, Squeak 3.8.15beta6U.app, and version 1657 of svn MacOS VM sources, and Spoon v2a12. Downloaded http://www.squeakvm.org/cgi-bin/viewcvs.cgi/ trunk version 1657 for MacOS Ran squeak-dev-beta-114-2.image on Squeak 3.8.15beta6U.app Loaded VMMaker 3.8b6.1 from dev image Universes. Generated vm sources by following instructions in <http://www.squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/Mac%20OS/vm/Doc…> Fought with Xcode wanting to use MacOSX10.3.9.sdk for ppc which was giving an error which was known and documented in the Readme. Finally figured out what Xcode wanted so built universal app just using 10.4.9 sdk. Couple issues: Exupery references remain in sqnamedPrims.h and sqPlatformSpecific.h from svn version 1657, I just commented them out. Notes said: Info-NPSqueak__Upgraded_.plist was to be found in the Developer directory. I could not find it so scammed a info.plist out of John's Squeak 3.8.15beta6U.app vm. Not sure what impact this has. And much, much diddling about figuring out various things... Finally got a build. It's a lot smaller (3.9MB) than John McIntosh's Squeak 3.8.15beta6U.app (8.1MB), and it looks like it is a PowerPC one but at least it runs. I'll look into the Xcode build process some more. Then: Replaced interp.c with Craig's interp.c for Spoon, rebuilt and got a VM with Spoon client stuff. Downloaded Spoon release 2a12. Moved a copy of Flow plugin from within Craig's naiad.app package into a plugins subdirectory where the new spoon client compatible MacIntel universal VM was run from. Followed Craig's Spoon instructions for loading niaid.st and niaid.pr into the 3.10 image (Squeak-dev-114-2) running on the new VM. Did the run spoon.app thing from Spoon.dmg (version 2a12), needs to be done twice if Safari is not running. Got Spoon processor running. Followed instructions again in the Spoon client and lo! Got OtherBrowser browsing the Spoon memory running on processor. Yay Craig! Who do i get to sign my certificate? :) Ken

4 7

Gnuification fails when compiling unix VM with latest VMMaker source
by Adrian Lienhard 09 Mar '10

09 Mar '10

Hi all, I'm trying to build a unix VM (on OSX) with the latest trunk (r2148) and the latest VMMaker version (VMMaker-dtl.156) but apparently the gnuification fails: [ 80%] Building C object CMakeFiles/squeakvm.dir/gnu-interp.c.o /Users/adrian/Desktop/vmbuilding/platforms/build/gnu-interp.c:6:2: error: #error GNUIFICATION FAILED ( 0 ) make[2]: *** [CMakeFiles/squeakvm.dir/gnu-interp.c.o] Error 1 make[1]: *** [CMakeFiles/squeakvm.dir/all] Error 2 make: *** [all] Error 2 When compiling with r2135, in which no gnuification is done, it works. From the above error output I have no clue as to what went wrong. To narrow down the problem I went to http://www.squeakvm.org/unix/ and downloaded the VMMaker image that Ian uses for the unix builds. I can compile with the cmake configuration of r2148 and the source that this VMM produces. So I assume there is a source change in VMMaker-dtl.156 that is not compatible with gnuification. The only question is, which one? The VMM version found in this image is VMMaker-tpr.58 (this version is many years old!) with lots of uncommitted changes. Diffing against VMMaker-dtl.156 I get tons of changed methods so I'm kind of lost here too. Why is the maintained VMMaker package not used for unix VMs? The following benchmarks show that gnuification makes a significant difference (MacBook Pro with 2.4Ghz, i686-apple-darwin10-gcc-4.2.1): 1 pre-compiled 3.11.3.2135 VM [1]: '248543689 bytecodes/sec; 8117987 sends/sec' 2 compiled from source r2135 '411244979 bytecodes/sec; 10560900 sends/sec' 3 VMMaker-dtl.156 compiled with cmake r2135: '313533374 bytecodes/sec; 11534330 sends/sec' 4 compiled from source r2148 '487619047 bytecodes/sec; 13257851 sends/sec' 5 provided VMMaker image [2] with r2148 '493256262 bytecodes/sec; 13200950 sends/sec' 6 VMMaker-dtl.156 compiled with r2148 ??? cannot compile... [1] http://www.squeakvm.org/unix/release/Squeak-3.11.3.2135-src.tar.gz [2] http://www.squeakvm.org/unix/release/unix-3.11.3.2135-vmm.tar.gz 1, 2, and 3 are compiled with the configuration of cmake from trunk revision 2135, hence without gnuification. 4 and 5 probably are from identical source: 4 from the svn trunk, the other, 5, generated through the VMM image provided by Ian. Any help to make 6 work is very welcome! Cheers, Adrian

4 8

Patches to SqueakFFIPrims and FFI-Kernel to support "manual surfaces"
by Josh Gargus 11 Feb '10

11 Feb '10

Hi, Here's a zip file that contains patches to SqueakFFIPrims (both Slang and C support files) and FFI-Kernels in order to support "manual surfaces", as embodied in the new class ExternalForm. There's a README in the zip file that describes how the changes fit together, so here I'll just describe the goal. The intent is to have a subclass of Form, ExternalForm, that uses an arbitrary pointer as the location of its pixel-data. It achieves this by acting as a client of SurfacePlugin much like any other, with the added twist of a primitive that enables Squeak code to set/clear the pointer. This is useful when working with such APIs as OpenGL and OpenCL, which provide a "map-image" API for interacting with images which reside in GPU memory. For example, if you want to access the updated contents of an OpenCL image, you would call clEnqueueMapImage(). This returns a pointer to CPU-accessible memory; by using this as the pointer for an ExternalForm, we can seamlessly use the OpenCL image just like any other Squeak Form. Cheers, Josh

4 6

Re: [Vm-dev] Multiprocessing with Squeak
by Levente Uzonyi 31 Jan '10

31 Jan '10

On Fri, 29 Jan 2010, Jecel Assumpcao Jr wrote: > > Levente Uzonyi wrote on Date: Wed, 27 Jan 2010 23:04:05 +0100 (CET) > >> Opinions? Ideas? > > If you haven't seen it already, you should really check out David > Ungar's work: > > http://portal.acm.org/citation.cfm?id=1640149 Thanks for the pointer to the paper, I saw a video about it but I can't find it atm. My idea is much simpler than this and (ideally it) would work with current images. What I'm interrested in is if it's doable or not? If it's doable, how much work would it be to do it? > My plan is to work on this from late March to the end of June. You mean you are about to reimplement that vm? Levente > > -- Jecel > >

2 1

fullscreen patch for Maemo 5 in N900
by K. K. Subramaniam 31 Jan '10

31 Jan '10

Hi, I had to apply the attached patch to vm-driver-x11/sqUnixX11.c to get squeakvm to work correctly in fullscreen mode Maemo 5. Without this patch, the window manager scales the screen to squeeze in a input panel/status bar along the bottom at random. While tracing the problem, I noticed that the driver code does not set properties like _NET_WM_WINDOW_TYPE or _NET_WM_STATE used by modern window managers and recommended by specs (http://standards.freedesktop.org/wm- spec/1.4/ar01s05.html). Has anyone else faced issues with fullscreen mode when porting to smaller devices like N900 or Android? Subbu

1 0

Re: Developer access to VMMaker, FFI, and SVN?
by David T. Lewis 31 Jan '10

31 Jan '10

On Sat, Jan 30, 2010 at 10:29:49AM -0800, Josh Gargus wrote: > Hi David, > > Could I be added as a developer to these projects? I believe that Andreas will vouch for me. > > If this is acceptable, my SqueakSource login is "jcg". Josh Gargus has been added as developer on SqueakSource/VMMaker. A few tips: - Each time you commit something with functional impact (as opposed to say adding some comments), edit VMaker>>versionString and bump the minor version by one. - If you add something that requires platform support, make sure that Ian, John and Andreas have all agreed in advance. - Posting change sets on Mantis (category "VM") is helpful but not required. Thanks, Dave

2 1

One-Click as VM
by keith 30 Jan '10

30 Jan '10

Hi All, I am trying to use the One-Click image as a one stop vm shop. I took the pier1.2 one click image, and removed the image. My first use-case is launching the vm with the image in the same directory as the .app. This works brilliantly, but I don't seem to be able to provide the sources file inside the .app, the one in ./Contents/Resources is ignored. I think that the same is true if I launch via drag and drop on the mac. My second use case is to be able to put the image, in the top level directory of the .app packages. any thoughts on how to achieve either of these. Keith

2 6

Re: Uploaded squeak-vm 3.11.3
by Bert Freudenberg 29 Jan '10

29 Jan '10

On 26.01.2010, at 05:31, José L. Redrejo wrote: > > I've just uploaded the latest version of the vm. > I've removed RomePlugin for all the archs, except i386. It's the only > one where I've tested it works. > I've also tempted of doing the same with ogg and gstreamer plugins, but > finally I've let them there. They segfaults often in amd64 too, but > don't do it unless the user tries to use those features. With Romeplugin > it was different: some squeak images (as etoys) have it activated by > default, so squeak segfaults when the image is loaded. Ah, right. I seem to remember there was a similar problem with Rome on the Mac. I'm cc'ing vm-dev ... > There are still some important bugs in Debian, and some very ugly > lintian messages. I don't have too much spare time, so I need some help > to deal with them: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497583 I have not ideas > to argue with this man. In fact, I think he might be totally right. Well, there is a source for this of course (in the VMMaker Squeak package). Generating the C code is a manual, interactive process and requires a running Squeak installation. Making that scriptable is possible, but so far nobody has done it AFAIK. > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528774 : let's way how > the new package behaves in the autobuilders, but I'm not very > optimistic. My only idea is removing hppa arch from the package. Any > help in doing it is welcome too. Let's see how the new package builds, maybe it works better? - Bert -

7 22

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev January 2010