Vm-dev August 2006

vm-dev@lists.squeakfoundation.org

8 participants
7 discussions

Passing parameters to a Squeaklet in Firefox on Solaris 10 - Solved Thanks!
by Graham McLeod 31 Aug '06

31 Aug '06

Following earlier message below: Thanks anyway, our own efforts have yielded fruit and we solved he problem today, so our application is up on Firefox/Solaris. Regards, Graham Hi all, and especially Bert Freudenberg and Andreas Wacknitz(Thanks for prior help) We have managed with help of Bert and others in the community to get as far as luanching our application as a Squeaklet in Firefox on Solaris 10. Thanks so far. We are now having difficulty passing parameters from the web page to the Squeaklet. We have put them in the EMBED tag in the form: parameterName=ParameterValue or parameterName="ParameterValue" where the value contains anything like special characters or spaces. Our application retrieves parameters fine when they are listed in the OBJECT tag and the squeaklet is launched in IE on Windows. These are read from the Smalltalk dictionary. I would be very greatful is anyone has a code example of: a. A Firefox web page calling a Squeaklet with parameters b. The Smalltalk code inside the applet which retrieves these That is known to work on Firefox 1.5 and Solaris 10. Many Thanks in Advance. Best Graham

3 2

VM stability issue on unix
by Adrian Lienhard 31 Aug '06

31 Aug '06

Hi VM maintainers, We have run into the following problem with 3.7/3.9 unix VMs (but not with version 3.6). The VM hoggs the CPU and does not respond anymore after consuming more than about 120MB of memory. The problem is reproducible independently of the image version (simply by instantiating enough objects). This is the VM version we are using: 3.7-7 #1 Don Okt 20 11:25:27 CEST 2005 gcc-Version (Debian Squeak3.7 of '4 September 2004' [latest update: #5989] Linux 2.6.10 #1 Tue Dec 28 21:16:21 CET 2004 i686 GNU/Linux Inspecting the Squeak process stacks with gdb does not show anything unusual, however, one process does not seem to get back from calling t he new: primitive. The call stack of the VM looks like this: #0 updatePointersInRangeFromto (memStart=231866373, memEnd=2138759076) at gnu-interp.c:21562 #1 0x0805d500 in incCompBody () at gnu-interp.c:4650 #2 0x0805d2ed in fullGC () at gnu-interp.c:4500 #3 0x0806d576 in sufficientSpaceAfterGC (minFree=202536) at gnu- interp.c:21275 #4 0x08067d5e in primitiveNewWithArg () at gnu-interp.c:16045 #5 0x080614fa in interpret () at gnu-interp.c:7249 #6 0x0805a5fb in main (argc=0, argv=0xbfeff8a4, envp=0x0) at /usr/src/Squeak-3.7-7/platforms/unix/vm/sqUnixMain.c:1367 It looks like the same issue has been discussed in the following thread already: http://lists.squeakfoundation.org/pipermail/seaside/ 2005-October/005897.html. The proposed workaround of explicitly setting -memory with a high enough value works, i.e., the vm does not stop working when the memory consumption exceeds 120MB. Since in Seaside applications images often grow up to 200MB or even more, this is a real show stopper... Cheers, Adrian

1 0

Subscribed again
by Andreas Raab 29 Aug '06

29 Aug '06

Hi Folks - Just FYI, it looks like something went wrong with the transfer from the previous mailing list and I got unsubscribed somehow. If there are any issues that are relevant for me since the transfer please send me a gentle reminder ;-) Cheers, - Andreas

1 0

discuss: [Squeak 0001144]: [ENH] SmartSyntaxInterpreterPlugin
by Martin Kuball 20 Aug '06

20 Aug '06

Hi! I know this is more than a year in the past. But some things take their time and I'v just now resumed my work on the Xvid plugin. When evaluating my sugested changes, Andreas made the following comment: > The main reason for concern is that this creates a dangerous > precedent for plugins. Thus far, all plugins have been "safe" in > such that they were used with unforgeable object references. > Allowing arbitrary pointers in *plugin* interfaces means that the > whole idea of "plugins are secure, FFI is not" becomes moot. > > Suddenly we need to be aware which plugins abuse what pointers and I > think we should really avoid this. I have not looked at the specific > reason for wanting to pass a pointer instead of an object reference > but the only reason I can imagine is that the pointer was > originally obtained by some FFI call. In which case I'd say "stick > with FFI" instead of plugins (after all it's no harder to export a C > function from a plugin than to write the named primitive). > > There are no good reasons that I can think of to suddenly start > using C pointers in plugins (lazyness on behalf of the plugin writer > does not count) and there are many good reasons against it. Unfortunately I do not realy understand his arguments. From the code of the plugins that come with VMMaker I can see that there are plugins that use c-pointers and do pass them to smalltalk. E.g. the Mpeg3 Plugin does it and the OsProecess plugin is another example. I would be very glad if someone could explain to me what is allowed and what is forbidden regarding this matter. Thanks. Martin

2 5

preferred version to get 1st indexable field
by Martin Kuball 19 Aug '06

19 Aug '06

Hi! What is the preferred version to get the pointer to the first indexable field of an indexable object: dstStrPointer := interpreterProxy firstIndexableField: string. or dstStrPointer := interpreterProxy arrayValueOf: string. Thanks. Martin

2 3

SocketPlugin and 64 bit
by Martin Kuball 10 Aug '06

10 Aug '06

Hi! After having a working vm for linux-amd64 again, I tried to get the network stuff up and running which has never worked for met on amd64. Some debugging in gdb showed that the code for optaining the bytesize of an array is broken in SocketPlugin. Some comparisions with the Fileplugin showed that code like this from SocketPlugin: sz = interpreterProxy->byteSizeOf(((sqInt)(long)(name) - 4)); (where name is the adress of the first indexable field of an ByteArray) does not work while pathNameSize = interpreterProxy->byteSizeOf(pathName); (pathName beeing an oop from the stack) does work. I changed the generated code and it works now. But of course something has to be done at VMMaker level to realy solve the problem. Martin

2 3

building a unix 32bit vm for amd64 (yet again)
by Martin Kuball 05 Aug '06

05 Aug '06

Hi! Today I started new attempt to compile a working 32bit vm. Determined to not give up before success I eventually found the culprit. Among other things I compared the file sqMemoryAccess.h from an old version (that did work on amd64) with the new one. I should have done this right away because two things imediately stroke me: * the old version only has inline functions while the new one has macros in addition * the macro version of oopForPointer is different from the inline function version: # define oopForPointer(ptr) ((sqInt)(ptr)) vs static inline sqInt oopForPointer(char *ptr) { return (sqInt)(ptr - sqMemoryBase); } From here on it was easy to verify that the macro USE_INLINE_MEMORY_ACCESSORS is not defined anywhere and that forcing the use of the inline version results in a working vm. Now the big question is: should I use the inline versions or the macros (after fixing them). I'm using gcc 4.1.2 by the way. Martin

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev August 2006