[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave type argument error calling mxGetField

From: Julien Bect
Subject: Re: Octave type argument error calling mxGetField
Date: Sun, 14 Dec 2014 14:34:35 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

Le 14/12/2014 14:29, Julien Bect a écrit :
Le 14/12/2014 13:08, Hans Peschke a écrit :
Am 14. Dezember 2014 09:08:44 MEZ, schrieb Julien Bect <address@hidden>:
Le 13/12/2014 20:39, Hans Peschke a écrit :
Hello everybody out there using and developping octave!
I would love to port some matlab code to run with octave.  Beside some
unproblematic m-files, there is a C struct type coming along with
delete.c, subasgn.c and subsref.c in its @Type directory, each
implementing a mexFunction(..), handling syntax and basic access for
the types instances.

As I'm new to such sophisticated matlab and octave programming, I
don't know wether the approach taken here is the right way or whether
it's compatible with octave.

The problem is, that as soon as a call to the function mxGetField
occurs (triggered for example by an acces to a field of an instance of
the type, resulting calling the @Type/subsref.c:mexFunction(..) )
octave stumbles over it, called in the following manner

void mexFunction(
  int nlhs,       mxArray *plhs[],
  int nrhs, const mxArray *prhs[]
  mxArray *ptr;
  ptr = mxGetField(prhs[0], 0, "handle");

which results in the following octave (version 3.8.1 shipped in
lubuntu 14.10) error:

error: octave_class::as_mxArray (): wrong type argument 'class'
panic: impossible state reached in file 'corefcn/' at line 556

Hello Hans,

I use MEX-files regularly but I've never come accross such a problem.

It would help if you could post some minimal code to reproduce the error.

Hello Julien,

Alright, I'm working on it ;)

But i doubt it would be very useful to post the code directly in an email, because there will be at least 5 files involved. Thus I'll upload it to a git repo, which should be more convenient to work with.

Of course a git repo will do, but a zip would have been good enough :)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]