Re: Having trouble with 4.2 on Linux

David said:
Thanks Dave, I will try rebuilding the stock VM tomorrow with the
suggested flag and see what happens.

However I will take this opportunity to update everyone on why I finally
got fed up with it today.  I thought to myself if the test functions
were not being included in the plugin(and my cursory inspection suggests
the cmake configuration does not include ffi-test.*) then perhaps the
simplest thing I could do would be to create a simple interface to rand.
 So I created a new subclass of ExternalLibrary and tried to add a
testRand instance method.  However as soon as I finished typing
'<cdecl:' I started getting debuggers popping up for every keypress
related to parsing, I suspect having to do with Shout.  Yet I check the
preferences and under Browsing Shout and syntaxHighlightingAsYouType
(going from memory) are not enabled.  But in fact the syntax is being
colored as I type.  I can't figure out how to stop it.  So I just type
away and ignore the debuggers resulting in

testRand
   "Test rand"
   <cdecl: int 'rand' ()>
   ^self externalCallFailed

and I try to accept that but it will not accept it insisting that there
should be a return call type in the cdecl line even though I think I've
typed one in there.  I also tried <cdecl: int 'rand' (void)> as I'm not
sure which if either of these is correct, but the same result happens in
both cases.

Ken

 
On Tue, May 24, 2011 at 03:47:40PM -0700, Ken Causey wrote: Most likely both declarations are incorrect, and that's probably what
the parser is trying to tell you.

<OT>
Of course everyone knows that writing plugins is "hard". But just in case
you run out of patience with doing it the "easy" way, consider writing a
small plugin. Commented example attached.  Compile the plugin with your VM,
then evaluate "RandPlugin next" to exercise the primitive.

  primitiveRand
    "Call the rand() clib function to obtain a positive int in the range 0 through
    16r7FFFFFFF. This will be the value of the Integer that we want to return from
    this primitive. Use #positive32BitIntegerFor: to convert this value into an object
    reference, which will be either a SmallInteger or a LargePositiveInteger. Pop
    a value from the stack (representing self), then push the integer value to be
    returned. Sender of this primitive will receive the integer object as the result
    of calling the primitive. Note, #code:inSmalltalk: provides a means of implementing
    the equivalent of rand() in Smalltalk. When running this primitive in Smalltalk
    (i.e. the interpreter simulator), the Smalltalk block will be executed rather
    than the rand() clib function."
    <export: true>
    | nextRand |
    nextRand := self
        cCode: 'rand()'
        inSmalltalk: [(Random new next * 16r7FFFFFFF) asInteger].
    self pop: 1 thenPush: (self positive32BitIntegerFor: nextRand)

</OT>

Dave

 
On Tue, 24 May 2011, Ken Causey wrote:

snip

> testRand instance method.  However as soon as I finished typing
> '<cdecl:' I started getting debuggers popping up for every keypress
> related to parsing, I suspect having to do with Shout.  Yet I check the
> preferences and under Browsing Shout and syntaxHighlightingAsYouType
> (going from memory) are not enabled.  But in fact the syntax is being
> colored as I type.  I can't figure out how to stop it.  So I just type

I fixed this bug in the Trunk a few weeks ago. It was present in Shout
since 2004 or so, but probably the error was simply ignored by some other
part of the system.

The error message is correct, you should specify the return type as long.
There's no int type in FFI, probably because it's ambiguous (even in C)
and unnecessary.


Levente

>
> Ken
>
>

Levente said:

>The error message is correct, you should specify the return type as long.
>There's no int type in FFI, probably because it's ambiguous (even in C)
>and unnecessary.

Thank you Levente.  This was enough to get me farther and have the
method compile.  If I were planning to do anything serious with this I
would certainly use trunk and take advantage of your fix, thanks for
that also.

I've fiddled with it a bit and the best result I have gotten so far is
if I implement my AnFFITest class as a subclass of ExternalObject and
put my method on the class side:

testRand
        "simplest test I could think of"
        <cdecl: long 'rand' ()>
        ^self externalCallFailed

This fails with 'unable to find function address'.  Perhaps rand isn't a
function or I need to do something more to indicate that the function is
a libc function, or I've made some other mistake.

Separately David has suggested that for my self-built VM I specify -m32
but if I do that with cmake/configure -CFLAGS=-m32 configure fails with
'no suitable type found' with the top of the stack 'vm/config.cmake:71
(TEST_BIG_ENDIAN).  In all likelihood I'm not doing this right and I
will continue to look around.  However even with the normal build cmake
gives a stern warning that we are using an accidental and deprecated
feature (The source directory .../unix/npsqueak does not contain a
CMakeLists.txt file).  I'm using cmake 2.8.4 and I wonder if cmake has
moved beyond our currently cmake configuration.

I'll continue to mess with it and I welcome any suggestions anyone has.

Ken

 
On Wed, May 25, 2011 at 09:00:45AM -0700, Ken Causey wrote:
I think you can ignore the stern warning regarding npsqueak. I see that
all the time, and since I'm not building npsqueak anyway, I ignore the
fact that no CMake configuration has been written for it.

I recently switched PCs and for some reason have not gotten the 32 bit
libraries (especially sound) installed properly, so I have not been building
32-bit VMs lately (64-bit works fine for everything I do anyway). But
if you have enough of the 32-bit libraries installed, building with -m32
*should* work. Sorry I'm being a bit unhelpful here as a result.

Dave