Vm-dev April 2005

vm-dev@lists.squeakfoundation.org

18 participants
16 discussions

Latest VM to develop to
by Giovanni Giorgi 13 Apr '05

13 Apr '05

Hi, I am looking forward the Squeak 3.8 I have found a "undocumented" directory ftp://st.cs.uiuc.edu/Smalltalk/Squeak/3.8/ for the not yet relased 3.8 Is it safe to take the Squeak 3.8g-6548.zip to develop with (I need to upgrade the packages I am working on)? Or there are big changes on the way? Thank you! -- Giovanni Giorgi http://www.squeak.org http://www.siforge.org ............................................................. -- La presente comunicazione potrebbe contenere informazioni riservate e/o protette da segreto professionale ed e' indirizzata esclusivamente ai destinatari della medesima qui indicati. Se avete ricevuto per errore la presente comunicazione, siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo di e-mail, e a cancellare il presente messaggio dal Vostro sistema. E' strettamente proibito e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione, copia o diffusione dei contenuti di questa comunicazione da parte di chi la abbia ricevuta per errore o in violazione degli scopi della presente. Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi ed e' risultato NON infetto.

1 0

Re: Jamming
by Giovanni Giorgi 12 Apr '05

12 Apr '05

--- Lex Spoon <lex(a)cc.gatech.edu> wrote: > 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. Where can I find more information on Jam? it looks very very interesting // Giovanni Giorgi http://www.siforge.org

2 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev April 2005