Vm-dev May 2006

vm-dev@lists.squeakfoundation.org

17 participants
25 discussions

Re: I've ported Squeak 2.3 to Amiga, more or less
by Bert Freudenberg 05 Jun '06

05 Jun '06

Am 30.05.2006 um 08:02 schrieb Tim Johnson: > Hello all, > > What a lovely weekend! I have spent the majority of it indoors, > porting Squeak 2.3 to the Amiga! One weekend? Nice :) > : \ > > I have put up a screenshot at: > > http://metaphorse.com/amiga/squeak/ > > I am obviously having some trouble with graphics (specifically, > ioShowDisplay), but the screenshot is recognizably showing Squeak > asking for its .changes file. To an outsider, though, it may look > as if something is *broken*... ;) Oh I guess every VM hacker has seen this :) You might just copy the bit depth conversion routines from another VM. > You may wonder why I used 2.3 ... It seemed to be the best choice > for a simple, well-documented, starting-from-scratch VM-building > scheme, with little-to-no dependence on plug-ins. I am scared of > VMMaker (it seems to be designed to create/tweak a VM for an > already-existing platform, versus a new one?), plus there is > already much documentation on Interpreter>>translate. Of course, I > am ignorant. I think you're the first one porting Squeak to a new platform after VMMaker. So there might be indeed some overly helpful features in there. Or is it not VMMaker, but rather that the VM got more complicated because we rely a lot on modules nowadays? I'm not quite sure what we actually need for a minimal functioning Squeak port. > Overall, this has been a pretty fun pastime. I can continue > posting progress reports to the list if anyone is interested. I > have to figure out this PixMap -> BitMap thing, but I also have to > get to work in the morning... ;) Sure, please, keep us posted! And, to get the attention of most people interested in the VM (even those who do not follow squeak-dev closely) you should post to the vm- dev list, too: http://discuss.squeakfoundation.org/cgi-bin/ezmlm-browse?list=vm-dev - Bert -

4 5

Re: sigsev in 64/32 bit VM
by Martin Kuball 31 May '06

31 May '06

Am Sunday, 28. May 2006 20:54 schrieb David T. Lewis: > Hi Martin, > > It's been a couple of months since I've tried compiling a VM on > amd64, but if noone else replies to this I'll give it a try > sometime in the next couple of days and let you know if it works > for me. Right now I'm too busy drinking beer and enjoying a long > Memorial Day weekend ;) (that's the US holiday to honor war > veterans, but also the semi-official first day of summer). > > In the past I have seen symptoms like this due to problems in the > memory access macros/functions in sqMemoryAccess.h, but it really > could be caused by most anything. You should definitely build only > the absolutely necessary plugins until you get the VM to run, as > many of the plugins are not 64 bit clean. > > Dave What exactly are the absoulutely necessary plugins? Martin > On Sun, May 28, 2006 at 07:26:11PM +0200, Martin Kuball wrote: > > Am Sunday, 28. May 2006 15:24 schrieb Martin Kuball: > > > Hi! > > > > > > I compiled a 64/32 bit VM from svn. Immediately after start I > > > get a SIGSEV at: interp.c line 7865: > > > > > > longAtput(where + ((ReceiverIndex + i) << ShiftForWord), > > > longAtPointer(localSP - ((argCount2 - i) * BytesPerWord))); > > > > > > I examined the arguments to longAtput and they seem OK. But > > > there is no Memory mapped at sqMemoryBase. How could that > > > happen? > > > > > > Martin > > > > Forgot to give you some more details. I'm running a amd64 system > > with linux 2.6.14. Compiler ist gcc 4.0.3. > > > > Martin

3 4

sigsev in 64/32 bit VM
by Martin Kuball 28 May '06

28 May '06

Hi! I compiled a 64/32 bit VM from svn. Immediately after start I get a SIGSEV at: interp.c line 7865: longAtput(where + ((ReceiverIndex + i) << ShiftForWord), longAtPointer(localSP - ((argCount2 - i) * BytesPerWord))); I examined the arguments to longAtput and they seem OK. But there is no Memory mapped at sqMemoryBase. How could that happen? Martin

1 1

Re: Patch for FilePlugin - bug 3649
by John M McIntosh 18 May '06

18 May '06

try looking in sqMacUnixFileInterface.c On 18-May-06, at 12:42 PM, Tony Garnock-Jones wrote: > John M McIntosh wrote: >> I think I only do this in dir_Delete, but is that enough? >>>>> lastPath[0] = '\0'; > > Perhaps set lastPathValid = false? I'm seeing that happen in the > carbon > version of dir_Delete, but no mention of lastPath or lastPathValid at > all in the non-carbon version of dir_Delete. > > This is the SVN head, of course, since I haven't looked hard enough to > find a more appropriate source for the Mac OS plugin code :-) > > Tony -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

1 0

Re: Patch for FilePlugin - bug 3649
by John M McIntosh 18 May '06

18 May '06

I think I only do this in dir_Delete, but is that enough? On 18-May-06, at 12:35 PM, Tony Garnock-Jones wrote: >>> lastPath[0] = '\0'; -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

1 0

Patch for FilePlugin - bug 3649
by Tony Garnock-Jones 18 May '06

18 May '06

Hi Ian. I've found and fixed a problem in the Unix FilePlugin regarding directory deletion. The problem is already covered by a test case in the 3.8 and 3.9 images. A description of the fault is here: http://bugs.impara.de/view.php?id=3649 and I've attached the patch against SVN trunk. Regards, Tony Index: platforms/unix/plugins/FilePlugin/sqUnixFile.c =================================================================== --- platforms/unix/plugins/FilePlugin/sqUnixFile.c (revision 1509) +++ platforms/unix/plugins/FilePlugin/sqUnixFile.c (working copy) @@ -122,6 +122,12 @@ return false; if (!sq2uxPath(pathString, pathStringLength, name, MAXPATHLEN, 1)) return false; + if (lastPathValid && !strcmp(lastPath, name)) { + closedir(openDir); + lastPathValid = false; + lastIndex = -1; + lastPath[0] = '\0'; + } return rmdir(name) == 0; }

2 1

64 bit cleanup completion?
by tim Rowledge 18 May '06

18 May '06

It's been a while since the 64 bit cleanup work was started and almost as long since anything much was done with it. There are a number of plugins that need some work to get rid of things like cCoerce:to: in favour of oopForPointer: etc. There are places with #flag: Dan lying around and Dan has expressed a lack of time to do anything with them but a willingness to sit with someone and a beer to explain what he was thinking of. I'm not going to be heading down to silicon valley anytime soon so I certainly can't do that but anyone that can take notes could do it and report back. Volunteers? tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, as he flunked the the sobriety test.

3 7

Re: Poor TTF font performance on Linux with newer VM
by Tony Garnock-Jones 18 May '06

18 May '06

I've just checked against 3.9-4 (built from source tarball from squeakvm.org), and it's still hideously slow. So it's down to something that changed between 3.7-7 and 3.9-4. Or perhaps CroquetPlugin or FloatMathPlugin. Or AioPlugin or UnixOSProcess :-) Tony. goran(a)krampe.se wrote: > Hi! > > Tony Garnock-Jones <tonyg(a)lshift.net> wrote: >> Thanks for that - I had suspected it might be a plugin. I've followed >> your suggestion, and the plugin list is almost identical except for >> OSProcess and FFI plugins. >> >> I've just run "MessageTally spyOn: [3 timesRepeat: [self nextPage]]" on >> my BookMorph. The two results are dramatically different: on the 3.7 VM, >> 477ms for the whole thing; on the 3.9 VM, 50354ms for the whole thing! A >> factor of 100x slower. > > Just wanted to mention that this might indeed be the issue I have been > experiencing with the new VM in my IRCe image - I thought it had to do > with Socket communication, but hey, it might as well be this in fact. > > regards, Göran > >

3 4

Re: 3.9-4 VM on cygwin: check that /usr/local/lib/squeak/3.9-4/vm-display-X11.so exists
by Wolfgang Helbig 17 May '06

17 May '06

Hi Klaus, you checked >> And then check the file bld/libtool which is a shell script generated by >> config which is supposed to generate the shared objects. > >Runs nicely, results are (also for vm-display-null): >/bin/sh /home/kWitzel/platforms/unix/config/mkinstalldirs >/usr/local/lib/squeak/3.9-4 >/bin/sh /home/kWitzel/platforms/libtool --mode=install /usr/bin/install >-c vm-display-X11.la /usr/local/lib/squeak/3.9-4/vm-display-X11.la >/usr/bin/install -c vm-display-X11/.libs/vm-display-X11.lai >/usr/local/lib/squeak/3.9-4/vm-display-X11.la >/usr/bin/install -c vm-display-X11/.libs/vm-display-X11.a >/usr/local/lib/squeak/3.9-4/vm-display-X11.a >ranlib /usr/local/lib/squeak/3.9-4/vm-display-X11.a >chmod 644 /usr/local/lib/squeak/3.9-4/vm-display-X11.a >---------------------------------------------------------------------- >Libraries have been installed in: > /usr/local/lib/squeak/3.9-4 > >> Hope, that helps. > >:-( Well, it helps me. :-) Looks like your libtool is configured to build static libraries. Which is perfectly ok. The VM should run with static libraries as well. Here are the relevant lines in my libtool: # Whether or not to build shared libraries. build_libtool_libs=yes # Whether or not to build static libraries. build_old_libs=no # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=yes # Whether or not to disallow shared libs when runtime libs are static allow_libtool_libs_with_static_runtimes=no They should differ from your libtool if configure figured out that it is better to build static libraries. But if you know better, feel free to override it by configure --enabled-shared Greetings Wolfgang -- Weniger, aber besser.

2 3

method dictionary lookups and walking up the inheritance tree
by Michael Haupt 16 May '06

16 May '06

Hi, once more, apologies for cross-posting. >From ClassBuilder, I could see that, when a new class is created, the superclass's method dictionary contents are copied to the method dictionary of the new class. Still, the interpreter climbs, in Interpreter>>lookupMethodInClass:, up the inheritance tree to resolve a method. Why is that? Have I missed a spot where subclass creation does not entail method dictionary copying? Thanks, Michael

5 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2006