Eliot Miranda wrote:
On Mon, Oct 26, 2009 at 1:04 PM, Juan Vuletich <juan@jvuletich.org mailto:juan@jvuletich.org> wrote:
Hi Eliot, Eliot Miranda wrote: Hi Juan, On Mon, Oct 26, 2009 at 11:07 AM, Juan Vuletich <juan@jvuletich.org <mailto:juan@jvuletich.org> <mailto:juan@jvuletich.org <mailto:juan@jvuletich.org>>> wrote: Eliot Miranda wrote: On Mon, Oct 26, 2009 at 6:01 AM, Juan Vuletich <juan@jvuletich.org <mailto:juan@jvuletich.org> <mailto:juan@jvuletich.org <mailto:juan@jvuletich.org>> <mailto:juan@jvuletich.org <mailto:juan@jvuletich.org> <mailto:juan@jvuletich.org <mailto:juan@jvuletich.org>>>> wrote: Hi Folks, I've just opened http://bugs.squeak.org/view.php?id=7407 , with a description of the problem, several tests (based on Henrik's scripts) and the fix I propose. David T. Lewis wrote: On Sat, Oct 24, 2009 at 10:40:17AM -0300, Juan Vuletich wrote: What worries me a bit is the other changes I needed to do to be able to run the Smalltalk BitBlt simulation and to do the translation. These are: BitBltSimulator >> #oopForPointer: "May be harmless" CArrayAccessor >> #long32At: "Why is this needed?" CArrayAccessor >> #long32At:put: "Why is this needed?" I am just guessing here, but I think that BitBltSimulator expects to be used with an interpreter simulator, so perhaps if you initialize it with a simulator there will be no need to add these methods. sim := BitBltSimulator new setInterpreter: InterpreterSimulator new Dave Given that BitBltSimulation calls #isIntegerObject: it looks like the ivar interpreterProxy should hold an InterpreterProxy (as it already does) and not an InterpreterSimulator. I did not add my patch to make simulation work to Mantis, as I'm not sure about them. When simulating the interpreterProxy inst var should hold the InterpreterSimulator, not the proxy. Maybe it should be an InterpreterSimulator when simulating the whole interpreter. When calling #copyBitsSimulated, it is set to an InterpreterProxy in #copyBitsFrom: . Anyway, I'm asking for help on making #copyBitsSimulated work again, like it should do when called from BitBltTest. If nobody can help with that, I guess I'll open a Mantis issue for this problem, in the hope that some day it gets fixed. Well with my current VM I see no problems; all 10 tests are green. What is the bug that you see? How can I reproduce it? tia Eliot Thank you for caring about this issue! I apologize for not being clear. Check #testAlphaCompositingSimulated and #testAlphaCompositing2Simulated. Both do nothing if BitBltSimulation is not there. If you load VMMaker, both tests give errors. The VM in use should be irrelevant, this is pure Smalltalk.
I understand that. I have an image containing BitBltSimulation and 5 different VMs :) I'm developing Cog, a faster Squeak VM. In my image with BitBltSimulation present all 10 BitBltTest tests pass. But I have done some work on the simulator.
I am asking you to help me reproduce the bug and then I can export the fixes from my VM to fix VMMaker. What version of VMMaker are you using?
Ok. I see. I downloaded latest trunk from http://ftp.squeak.org/trunk/Squeak3.10.2-Trunk-091024.zip. Opened the image, open MC Browser. Add repository: MCHttpRepository location: 'http://www.squeaksource.com/VMMaker' user: '' password: '' Opened the repository Loaded VMMaker-dtl.145.mcz Proceeded on the warning about Klatt and FFI. Run the tests. Both give errors.
Thanks, Juan Vuletich
Ps. I can't wait for Cog!
It is a very bad idea to have a test do nothing under default conditions! (i.e. no special packages such as VMMaker loaded) That's why I moved both to a new class, that should be part of VMMaker, and removed that silly check for BitBltSimulation. This is included in the stuff I attached to http://bugs.squeak.org/view.php?id=7407 . Cheers, Juan Vuletich