Vm-dev

vm-dev@lists.squeakfoundation.org

10 participants
17027 discussions

Re: contemplating a VM fork.
by Lex Spoon 08 Apr '05

08 Apr '05

Ned Konz <ned(a)bike-nomad.com> wrote: > On Monday 28 March 2005 1:50 am, Alan Grimes wrote: > > Hello, I am contemplating forking the VM due to my frustration over > > having to live at Ian's mercy with regards to enhancements to the VM. ÊI > > don't mean to fault Ian, he has clearly done some excellant work with > > Squeak and is superbly talented. My issue is that I am unable to work > > with his build environment to the point that I can successfully > > implement my own extensions such as the SDL driver that I've been > > working on. -- I can't figure out how to make the build script work. > > I find this a bit odd. I know of many people who have downloaded the sources, > VMMaker, etc. and have had no problems building a VM. > > Assuming your system has a properly matched set of tools, installed properly, > the configure script should work properly. I think he was talking about modifying the build scripts, not running them as is. Even so, you must admit that this is a lot of if's. If you have the wrong awk, you don't get gnuification. If you have the wrong version of autoconf, then the configure script may not be rebuildable. Wrong version of gcc? Your compile can fail. etc. FWIW, the scripts are still not perfect even with all the if's satisfied. My current system builds without complaint, but the resulting VM cannot open an X window. (This is why I haven't yet posted a deb of Ian's latest VM release.) vm-display-X11 is created, and I can compile other X programs just fine, so I don't know what the problem is. I intend to eventually dig to the bottom of this; in fact, I've seen it before, but cannot remember what the problem was! I'm not complaining-- bugs happen! Let's not get so overconfident that we are surprised that it does not go perfectly for someone. Regarding the complexity of the script, I have several ideas. In fact, I have actually coded several of them up in the past, for whatever credibility that gives me. Since those changes have been rejected-- many times--I won't work further on them myself, but maybe some people have thicker skin and would like to take a try at it. Here are a few from the top of my head: 1. Dump make. We already depend on GNU make. It is no more onerous to depend on Jam, which would make it easy to encode more rules in the Jamfiles. Jam is easier to understand, and further, it removes a major temptation to violate #2: 2. Use autoconf only for its purpose: *guessing* about configuration. Always let the user override the guess. And don't overload it with other functions, just because make doesn't have if statements or subroutine calls. A quick test for whether you are overloading it is: if you change part of the build scripts unrelated to configuration settings, you should not have to re-run the configure script. 3. Reconsider libtool. It's a nice idea, but it is really confusing, and I'm not sure it is truly helping out. It sucks having to read an extra manual just because we are too afraid to hard code "gcc -shared". It would not be terrible, if the standard build scripts can only build external plugins if you are using gcc. 4. Heck, while at it, reconsider the default of external plugins. There are clear advantages to external plugins, but they cause an installation hassle. Especially it is annoying, if you want to compile an experimental VM and test it out without installing it on your system. Make internal the default, if VMMaker allows this. Don't take me wrong -- the build scripts generally work fine. Let's just not overestimate them. They are complicated, few people understand them (maybe just 1?), they sometimes fail, they often require people to install extra dependencies, and when the the build fails, the error messages (or lack thereof) are frequently impenetrable. Most of this is not necessary, and so we should welcome discussion (and code!) about how to improve them. -Lex PS -- Alan, there are no Squeak Police that will come after you if you just do something like gcc *.c */*.c. :) Please don't dump great VM work just because you can't use the official build scripts. Build script crud can always be fixed up later.

4 5

Jamming
by Lex Spoon 08 Apr '05

08 Apr '05

I've worked with Jam a good deal at this point, and it is my favored build tool when I start new projects. If anyone tries to use it with Squeak, here are a few thoughts from my experience. First, a good autoconf strategy is for autoconf to create a single file "Jamsettings" which holds most of the build options. This file is simple and easily hand-hackable; this is nice, because then I can manually maintain make a Jamsettings.win32 and Jamsettings.osx for platforms which are different from normal Unix boxes and which autoconf doesn't work well. Also, if autoconf ever guesses wrong (and come on, it sometimes does), users are not up the creek -- they can hack a single file and then move on. With this approach, conditional build options show up as conditional statements in the Jamfile. Remember that you can write things in Jam such as: if $x11_libraries_present { include plugins/vm-display-X11/Jamfile ; } and: if $awk_present { interpc = "gnu-interp.c" ; Gnuify gnu-interp.c : interp.c ; } else { interpc = "interp.c" ; } This is extremely useful, and means that you should not need to have complicated scripts in your autoconf setup--instead, the conditional stuff is in the Jamfile, which is a nicer language that Bourne shell. It also means autoconf goes back to its main job of checking for what is on the system; it does not get involved with patching together makefile fragments or anything like that. A second thing to think about, is to divide your jam code into a library part and a users part. As with any library, it is worth spending significant time up front to design a nice interface. For example, maybe you want plugin Jamfiles to look like this: PluginFile "FooPlugin" ; PluginCFile foo.c ; PluginCFile bar.c ; EndPluginFile ; Or maybe you want this: Plugin FooPlugin : foo.c bar.c ; Think carefully about it, and skim through the individual plugins to see what is possible. As one tip here, don't get carried away and try to make too many things automatic. I find it a good a general rule of thumb to name each source file exactly one time. More than this is okay, but less than this is often a false economy. The Jamfiles may get shorter, but they become so much more complicated that it isn't worth the savings. Once you have your interface worked out, you can then make a Jambase which defines subroutines like "Plugin" and "PluginCFile". These will expand to smaller rules, and eventually to "actions" which set up the low-level dependencies and give the specific build rules. Finally, you might want to ignore Jam's much-vaunted "grist", and instead use full pathnames. Grist, IMHO, makes the Jamfiles shorter, but it's another false economy. Grist is a significant time investment to learn from the existing documentation, and it's fiddly (some rules use it, some don't) even once you understand what is going on. Maybe a very clever guy can overcome these hurdles; I just want to toss out that some people have gone there and have not found it worth the hype. Good luck, anyone who goes for it. I expect, as with Squeak, you will get addicted... and then want even more. Lex

1 0

TEST
by Alan Grimes 03 Apr '05

03 Apr '05

TEST.

2 2

problem with LINUX installation
by D. Hugh Redelmeier 02 Apr '05

02 Apr '05

This is my first Squeak installation. System: Fedora Core 3 LINUX running on an i386 (Athlon). I fetched .rpm files from http://squeak.hpl.hp.com/unix/: -rw-rw-r-- 1 hugh hugh 12797972 Mar 22 04:17 Squeak-image-3.7-5989.noarch.rpm -rw-rw-r-- 1 hugh hugh 3428037 Mar 22 17:11 Squeak-sources-3-1.noarch.rpm -rw-rw-r-- 1 hugh hugh 753846 Mar 22 04:28 Squeak-vm-3.7-7.i386.rpm -rw-rw-r-- 1 hugh hugh 2383423 Mar 22 04:28 Squeak-vm-3.7-7.src.rpm I installed all but the last of these (rpm -iv). I didn't know how to start it, so I typed "squeak" at the shell. squeak complained about not being able to find the image. Then I tried: squeak /usr/lib/squeak/squeak.image.gz This interpreter (vers. 6502 cannot read image file (vers. 134777631 Hit CR to quit [Notice the unmatched parentheses in the diagnostic message. BUG, I think.] I realized at this point that I should be using inisqueak to make a personal writeable copy of the image and changes files. Then I tried inisqueak and got this message: No default image, looking for alternatives... I could not find an image to install. Please check your Squeak installation. I'd have expected that inisqueak, which is in Squeak-image-3.7-5989.noarch.rpm, would know where to look for /usr/lib/squeak/Squeak3.7-5989.image.gz which is packaged in the same .rpm. In fact, the inisqueak shell script thinks that things are installed in /usr/local/bin and /usr/local/lib/squeak. BUG: inisqueak in Squeak-vm-3.7-7.i386.rpm should know where the same .rpm places the initial image and changes files. The man page for inisqueak says: inisqueak has no options or arguments. This turns out not to be the case. inisqueak accepts flags (give it -h to see a list). It also accepts a pathname that it will prefix to the wired in paths for: - bindir - imgdir - plgdir I am guessing that this facility is for the benefit of packaging tools. I could not get it to solve my problem since I needed to change these paths, not just prefix them. The paths are set up as the first few executable lines in inisqueak: MAJOR=3 VERSION=3.7-5989 prefix=/usr/local exec_prefix=${prefix} bindir=${exec_prefix}/bin imgdir=${prefix}/lib/squeak plgdir=/usr/local/lib/squeak/3.7-7 Why is plgdir not based on prefix like the other path variables? If plgdir were based on prefix then prefix could be defined: prefix=$(prefix:-/usr/local) allowing the prefix to be overridden from the command line: prefix=/usr inisqueak The existing mechanism for relocating all paths (when a path is supplied as an argument) relocates bindir, imgdir, and plgdir, even though plgdir is not initialized in terms of prefix. At this point, I make a copy of inisqueak, fix the definition of prefix, and run that copy. Don't bother me for a while -- I'm playing. PS: My plugin stuff is probably broken since I only changed prefix. But perhaps not -- how can I tell? The filenames in the directory suggest that the display would not work without plugins, and the display is working. PPS: top says that squeak is taking about 14% of the user mode CPU before I even touch it. Is it (the vm?) still busy waiting / polling? I know that used to be the case years ago.

1 0

changes to platforms/Cross
by Ian Piumarta 01 Apr '05

01 Apr '05

Folks, I'm just about to release the 'mainstream' 64-bit VM support. Part of this requires changes to the plugin-related files in platforms/Cross. I have tried to ensure that the changes remain backward compatible with pre-64-bit source code, but a few things might need tweaking (minimally) in platform-specific files to make old generated sources compile with the new headers. (I can compile a 3.7 Unix VM using my 64-bit support code, with all plugins built correctly, but I cannot guarantee anything about the other platforms which may or may not require intervention from their maintainers to ensure they build old-world generated code correctly after the new-world 64-bit changes are committed.) Unless someone complains before 15:00 PST, I will commit the 64-bit changes to the trunk. I consider the danger of committing these changes to be minimal. The danger of not committing these changes today (including leaving them to linger in the branch they currently occupy) is that they start rotting once more -- and it's not clear when I'll next have another week to waste on fixing them again. Cheers, Ian

3 2

changes to platforms/Cross [addendum]
by Ian Piumarta 31 Mar '05

31 Mar '05

Sorry -- I forgot to include a list of the affected files: Files 3.7-7/platforms/Cross/plugins/FilePlugin/FilePlugin.h and merge64/platforms/Cross/plugins/FilePlugin/FilePlugin.h differ Files 3.7-7/platforms/Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c and merge64/platforms/Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c differ Files 3.7-7/platforms/Cross/vm/sq.h and merge64/platforms/Cross/vm/sq.h differ Files 3.7-7/platforms/Cross/vm/sqNamedPrims.c and merge64/platforms/Cross/vm/sqNamedPrims.c differ Files 3.7-7/platforms/Cross/vm/sqVirtualMachine.c and merge64/platforms/Cross/vm/sqVirtualMachine.c differ Files 3.7-7/platforms/Cross/vm/sqVirtualMachine.h and merge64/platforms/Cross/vm/sqVirtualMachine.h differ (SocketPlugin.h will likely follow, as I 64-bit clean the Unix support code this afternoon.) Cheers, Ian

1 0

This week's VM build problem...
by Alan Grimes 29 Mar '05

29 Mar '05

Looking to update my workhorse VM with the current one, I sync'd my SVN sources and did my usual routine. (with the SVN-provided configure script), Here's the result. bash-2.05b$ make gawk -f /home/atg/source/trunk/platforms/unix/config/gnuify /home/atg/source/trunk/src/vm/interp.c > gnu-interp.c.out mv gnu-interp.c.out gnu-interp.c gcc -g -O2 -fomit-frame-pointer -DLSB_FIRST=1 -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN -I/home/atg/source/trunk/bld -I/home/atg/source/trunk/platforms/unix/vm -I/home/atg/source/trunk/platforms/Cross/vm -I/home/ atg/source/trunk/platforms/Cross/vm -I/home/atg/source/trunk/platforms/unix/vm -I/home/atg/source/trunk/src/vm -I/home/atg/source/trunk/platforms/Cross/plugins/FilePlugin -I/home/atg/source/trunk/platforms/unix/p lugins/B3DAcceleratorPlugin -I/home/atg/source/trunk/bld -I/home/atg/source/trunk/platforms/unix/vm -I/home/atg/source/trunk/platforms/Cross/vm -c -o gnu-interp.o gnu-interp.c In file included from /home/atg/source/trunk/platforms/Cross/vm/sq.h:198, from /home/atg/source/trunk/platforms/unix/vm/sqGnu.h:45, from gnu-interp.c:8: /home/atg/source/trunk/platforms/unix/vm/sqPlatformSpecific.h:52:28: sqMemoryAccess.h: No such file or directory In file included from /home/atg/source/trunk/platforms/Cross/vm/sq.h:198, from /home/atg/source/trunk/platforms/unix/vm/sqGnu.h:45, from gnu-interp.c:8: /home/atg/source/trunk/platforms/unix/vm/sqPlatformSpecific.h:54: error: parse error before "minHeapSize" /home/atg/source/trunk/platforms/unix/vm/sqPlatformSpecific.h:55: error: parse error before "sqGrowMemoryBy" /home/atg/source/trunk/platforms/unix/vm/sqPlatformSpecific.h:55: error: parse error before "oldLimit" /home/atg/source/trunk/platforms/unix/vm/sqPlatformSpecific.h:55: warning: data definition has no type or storage class /home/atg/source/trunk/platforms/unix/vm/sqPlatformSpecific.h:56: error: parse error before "sqShrinkMemoryBy" /home/atg/source/trunk/platforms/unix/vm/sqPlatformSpecific.h:56: error: parse error before "oldLimit" /home/atg/source/trunk/platforms/unix/vm/sqPlatformSpecific.h:56: warning: data definition has no type or storage class /home/atg/source/trunk/platforms/unix/vm/sqPlatformSpecific.h:57: error: parse error before "sqMemoryExtraBytesLeft" /home/atg/source/trunk/platforms/unix/vm/sqPlatformSpecific.h:57: error: parse error before "includingSwap" /home/atg/source/trunk/platforms/unix/vm/sqPlatformSpecific.h:57: warning: data definition has no type or storage class /home/atg/source/trunk/platforms/unix/vm/sqPlatformSpecific.h:67: error: parse error before "sqInt" make[1]: *** [gnu-interp.o] Error 1 make: *** [vm/vm.a] Error 2 bash-2.05b$ -- Someone forgot to check in sqMemoryAccess.h?

2 1

3.7-7 "final" VM for Unix
by Ian Piumarta 25 Mar '05

25 Mar '05

Unix Hackers, I am pleased (and relieved) to announce the "final" 3.7-7 VM for Unix. This VM is very close to 3.7b-5 (which has been working well for many people for some time) with the addition of several critical fixes. Archives are in the usual place (http://squeak.hpl.hp.com/unix) for sources and a few pre-compiled binaries: Darwin 7.8 PowerPC Mac OS X PowerPC FreeBSD 4.10 i386 NetBSD 1.6.1 i386 OpenBSD 3.4 i386 Solaris 2.9 i386 Solaris 2.9 Sparc GNU/Linux PowerPC GNU/Linux i686 (.rpms and .debs will follow shortly. Due to limited physical access to machines I have only been able to test this release on Darwin-PPC, MacOSX-PPC, and GNU/Linux-i686.) If you prefer to fetch the sources from our Subversion repository: svn export http://squeak.hpl.hp.com/svn/squeak/tags/unix-3.7-7 (The repository source now includes everything needed to build the Unix VM. No more guessing which magical combination of image-side stuff is needed to generate a working Interpreter and plugins. FWIW, the generated sources used in this release are those found in the released "final" 3.7-5898-full image [following my usual rule] plus [exceptionally] Ned's "2GB oop" patches, which are included in the 'unix/misc' directory of both the source archive and repository.) Enjoy! Ian PS: A small reminder. Please send VM-related problems/bugs/fixes to the VM-Dev list (see discuss.squeakfoundation.org). VM-related posts to the general-purpose squeak-dev list are not guaranteed to be seen, let alone acted upon, by the relevant people. If you're sending me Unix-specific VM fixes, please send *entire* modified files (not 'diffs', of any flavour) since I read and manually apply all patches, one line at a time, using ediff in Emacs. Fixes should usually be sent to me directly (ian [point] piumarta [chez] squeakland [point] org) and not copied to any mailing list, *please*. (Partly traffic, but mostly to keep my remaining 'uncompromised' email addresses out of publicly-archived lists.) Thanks! PPS: Here are the release notes (relative to the 3.6 stable release) for anyone interested... VM: Netscape plugin understands "imageName" and "failureURL" attributes in <embed ...> tags. Less noise from dlopen() and friends when probing for plugins. Problems preventing more than one external plugin from loading in Mac OS X fixed. Obscure bug fixed that prevented socket options being set on some platforms. NPSqueak improvements and bug fixes from Bert Freudenberg and Jens Lincke. New environment variable SQUEAK_USERDIR used to find plugin image; defaults to 'My Squeak'. (NPS may not work for users of shells other than bash. Contact Bert if you have problems.) Interpreter changes from Ned Konz that avoid image segment loading errors caused by oops >= 2GB. VM drivers: Drag-and-drop support added to the X11 display driver. vm-sound-NAS driver explicitly depends on libaudio. New option '-glxdebug <n>' sets OpenGL debug message level for X11 display. Plugins: Additional checks for external data in SocketPlugin. New OSProcessPlugin (including XDpyPlg and AioPlg). Build: Optimisation flags default to '-O' if compiler not recognised. sqGnu.h asm() statements fixed for gcc-3.1 compatibility. Use of alloca() made more portable. SVN repository now includes contents of 'src' directory used to build Unix binaries. No more endless searching for the right combination of obscure VMM version and image updates. Build instructions updated for SVN and recent organisational changes. 'gnuify' inserts a #error into gnu-interp.c if it detects a problem (causing cpp to barf cleanly with a comprehensible error message, rather than leaving the compiler to spew hundreds of obscure error messages). Documentation: URIs updated to reflect recent organisational changes.

3 2

VMMaker 3.8b3 released
by Tim Rowledge 25 Mar '05

25 Mar '05

This is a temporary version of VMMaker mostly to provide a workaround for that irritating >2Gb issue. It is also an experiment in releasing as an MC file. It should build a useful VM for people keeping up to date. It is possible that there will be SVN tree related issues as the 64bit enhancements work their way in but everyone is working to prevent problems and begs your indulgence whilst the patient's chest cavity is open. tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful Latin Phrases:- Sentio aliquos togatos contra me conspirare = I think some people in togas are plotting against me.

1 0

3.8a-1 (Unix) and 32-bit compatibility for 64-bit support code (all platforms)
by Ian Piumarta 23 Mar '05

23 Mar '05

[apologies for multiple reception. if it's possible to subscribe to this list with several posting email addresses for just a single reception address, someone please point me at the relevant stuff] VM Hackers, The trunk of the unix tree is now at (an unstable, monotonically advancing) 3.8a-1. I'm telling you this because there are significant widespread changes since 3.7-7. In particular, the core Unix VM support is the result of merging 3.7-7 with my previous 64-bit support code released a while ago. This 64-bit compatible code is now the official support code for Unix versions 3.8 and onwards. While waiting for Tim to pull the changes Dan and I sent him into the Interpreter and CCodeGenerator, I've pre-emptively checked in Cross/vm/sqMemoryAccess.h, which is a slightly modified copy of the one I released with the original 64-bit code. It allows the support code to use the new type names, but still compile with a 'src' tree generated from a 32-bit Interpreter/CCodeGenerator. There may be a few unexpected warnings about mixing integers and pointers for the moment, but these are harmless. Needless to say, if your support code is still of the old 32-bit flavour, it won't ever include this header file. Note that this does not mean you can compile a 64-bit VM for 32/64-bit hardware, nor does it mean you can run a 32-bit VM on 64-bit hardware. The only thing it kludges into working order is compiling 32-bit 'src' to run on 32-bit hardware, mixing 'int's in the generated stuff with 'sq{Int,Long,Whatever}'s in the support code. For all four combinations of 32/64 VM + 32/64 h/w to work, we have to wait for our 64-bit image changes to percolate into the released image-side stuff. Backwardly-compatible cheers, Ian

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev