headers
Gabriel Dos Reis | 4 Sep 2010 19:54
Picon
Favicon

Re: [open-axiom-devel] FFI change 1.3 -> 1.4?

Arthur Ralfs <arthur@...> writes:

| Hi Gaby,
| 
| Your FFI Example for scalar product compiles in 1.3 but not 1.4.  Can 
| you tell me what the difference is?  I copied the C file to 
| dot-product.c and the spad file to dot-product.spad.  In 1.4 I get an 
| error: invalid signature.

Hi Arthur,

Alfredo recently raised the issue with me, while he was looking at the
panserver.  The problem was that I changed the Boot abstrat syntax
tree, but I failed to propagate the changes to the Spad compiler (which
is reusing the FFI in the Boot code.) 

The problem is fixed in any recent version from trunk.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
Permalink | Reply | 1 comment |
headers
Arthur Ralfs | 4 Sep 2010 20:52
Picon

Re: [open-axiom-devel] FFI change 1.3 -> 1.4?

On 09/04/2010 10:54 AM, Gabriel Dos Reis wrote:
> Arthur Ralfs<arthur@...>  writes:
>
> | Hi Gaby,
> |
> | Your FFI Example for scalar product compiles in 1.3 but not 1.4.  Can
> | you tell me what the difference is?  I copied the C file to
> | dot-product.c and the spad file to dot-product.spad.  In 1.4 I get an
> | error: invalid signature.
>
> Hi Arthur,
>
> Alfredo recently raised the issue with me, while he was looking at the
> panserver.  The problem was that I changed the Boot abstrat syntax
> tree, but I failed to propagate the changes to the Spad compiler (which
> is reusing the FFI in the Boot code.)
>
> The problem is fixed in any recent version from trunk.
>

Thanks Gaby, I'll give that a try as soon as I have time.

Arthur

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arthur Ralfs | 5 Sep 2010 18:29
Picon

[open-axiom-devel] still not right

Hi Gaby,

The panserver.spad file seems to compile with latest trunk but now I get:

; /mnt/sdb3/arthur-home1/openaxiom/panserver/SOCKLIB.NRLIB/code.fasl written
; compilation finished in 0:00:00.105

    >> System error:
    Compilation of generated Lisp failed

whereas with 1.3 I get:

; /mnt/sdb3/arthur-home1/openaxiom/panserver/SOCKLIB.NRLIB/code.fasl written
; compilation finished in 0:00:00.143
------------------------------------------------------------------------
    SockLib is now explicitly exposed in frame frame803
    SockLib will be automatically loaded when needed from
       /mnt/sdb3/arthur-home1/openaxiom/panserver/SOCKLIB.NRLIB/code.fasl

Arthur

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
Permalink | Reply | 3 comments |
headers
Gabriel Dos Reis | 5 Sep 2010 18:56
Picon
Favicon

Re: [open-axiom-devel] still not right

Arthur Ralfs <arthur@...> writes:

| Hi Gaby,
| 
| The panserver.spad file seems to compile with latest trunk but now I get:
| 
| ; /mnt/sdb3/arthur-home1/openaxiom/panserver/SOCKLIB.NRLIB/code.fasl written
| ; compilation finished in 0:00:00.105
| 
|     >> System error:
|     Compilation of generated Lisp failed

Hi Arthur,

This problem is separate from the FFI interface code per se.  

The errors are caused by mixing Lisp variables/instructions with Spad
variables/instructions in way that the Spad compiler does not
understand.  This is a problem common to all AXIOM compilers; older
versions may let it pass by, but only to lead to random `memory may be
damaged' errors.

For example, in sendCommand(), we have

            SETQ(tmpmathml$Lisp, MAKE_-STRING_-OUTPUT_-STREAM()$Lisp)$Lisp
            SETQ(tmpalgebra$Lisp, MAKE_-STRING_-OUTPUT_-STREAM()$Lisp)$Lisp
            SETQ(savemathml$Lisp, _$texOutputStream$Lisp)$Lisp
            SETQ(savealgebra$Lisp, _$algebraOutputStream$Lisp)$Lisp

As currently written, the variables `tmpmathml', `tmpalgebra', etc.,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Arthur Ralfs | 6 Sep 2010 19:37
Picon

Re: [open-axiom-devel] still not right

On 09/05/2010 09:56 AM, Gabriel Dos Reis wrote:
>
> The errors are caused by mixing Lisp variables/instructions with Spad
> variables/instructions in way that the Spad compiler does not
> understand.  This is a problem common to all AXIOM compilers; older
> versions may let it pass by, but only to lead to random `memory may be
> damaged' errors.
>
> For example, in sendCommand(), we have
>
>              SETQ(tmpmathml$Lisp, MAKE_-STRING_-OUTPUT_-STREAM()$Lisp)$Lisp
>              SETQ(tmpalgebra$Lisp, MAKE_-STRING_-OUTPUT_-STREAM()$Lisp)$Lisp
>              SETQ(savemathml$Lisp, _$texOutputStream$Lisp)$Lisp
>              SETQ(savealgebra$Lisp, _$algebraOutputStream$Lisp)$Lisp
>
>
> As currently written, the variables `tmpmathml', `tmpalgebra', etc.,
> appear to be intended to Lisp-level special variables, not Spad
> variables.  However the Spad compiler does not know that.  So it
> generates code that does not  tell the Lisp compiler that they are
> special variables.  The way we  tell the Spad compiler that a Lisp
> variable is special, is that its name starts with a dollar --
> e.g. _$algebraOutputStream.
>
> On the other hand, I am not too sure you wanted `tmpmathml' or `tmpalgebra'
> to be Lisp-level special variables.  So, my question is: are they
> reasons why you don't say
>
>     tmpmathml :=  MAKE_-STRING_-OUTPUT_-STREAM()$Lisp
>     tmpalgebra := MAKE_-STRING_-OUTPUT_-STREAM()$Lisp
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gabriel Dos Reis | 7 Sep 2010 04:29
Picon
Favicon

Re: [open-axiom-devel] still not right

Arthur Ralfs <arthur@...> writes:

[...]

| Hi Gaby,
| 
| I tried out your suggestions both ways, with Lisp variables and with
| Spad variables, but still didn't get it to compile properly.

Hi Arthur,

Many thanks for your patience in isolating simple testcases we can work
on.  This is very much appreciated.  See explanations below.  Your input
is very much appreciated.

| 
| I have no idea what the problem is so I started stripping things out
| to try and isolate the problem.  I discovered that the first version
| below compiles but the second doesn't:
| 
| )abbrev package SOCKLIB SockLib
| 
| SockLib(): Public == Private where
| 
|     Public == Type with
| 
|         handleInsert: () -> Integer
|         sendInsertFile: () -> String
| 
|
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arthur Ralfs | 21 Sep 2010 18:27
Picon

[open-axiom-devel] run time error

Hi Gaby,

I've got panserver.spad to compile now under 1.4 but now I get a run 
time error when I run

ans:String := string parseAndEvalToStringEqNum$Lisp command

If I compile this test spad

)abbrev package SOCKLIB SockLib

SockLib(): Public == Private where

     Public == Type with

         sendCommand: String -> String

     Private == add

         sendCommand(command) ==
	    ans:String := string parseAndEvalToStringEqNum$Lisp command
	    "test"

I get this

(2) -> sendCommand("x")

    >> System error:
    The value
   ("   (2)  x"
(Continue reading)

Permalink | Reply | 6 comments |

Gmane