I have a SWIG generated R wrapper which contains the following setClass operations:
setClass('_p_f_p_struct_parameters_p_struct_chromosome_p_struct_dataSet__double',
prototype = list(parameterTypes = c('_p_parameters', '_p_chromosome', '_p_dataSet'),
returnType = '_p_f_p_struct_parameters_p_struct_chromosome_p_struct_dataSet__double'),
contains = 'CRoutinePointer')
setClass('_p_f_p_struct_parameters_p_p_struct_chromosome_p_p_struct_chromosome_int_int__void',
prototype = list(parameterTypes = c('_p_parameters', '_p_p_chromosome', '_p_p_chromosome', '_int', '_int'),
returnType = '_p_f_p_struct_parameters_p_p_struct_chromosome_p_p_struct_chromosome_int_int__void'),
contains = 'CRoutinePointer')
These operation do not appear to be behaving as expected. When I call a function with the output being the creation of a _p_parameters object (defined above), I get the following error:
Error in getClass(Class, where = topenv(parent.frame())) :
“_p_parameters” is not a defined class
The setClass therefore seems to be not doing it's thing.
I tried to manually set the _p_parameters class via:
p_parameters<-setClass(Class="_p_parameters", representation = representation(ref = "externalptr"))
But this does not seem to work as when I try and modify other parameters (or even print parameters via an inbuilt function) the terminal crashes and hangs.
For reference, the final lines in initialiseParameters (the function which initially own _p_parameters) are calling the native C function via .Call then assigning the external pointer to a new object of class _p_paramters as follows:
;ans = .Call('R_swig_initialiseParameters', numInputs, numNodes, numOutputs, arity, as.logical(.copy), PACKAGE='cgp');
ans <- new("_p_parameters", ref=ans) ;
I've read various R doc on new(), setClass, S3/S4 classes but nothing seems to clarify what I'm meant to be doing here.
Any suggestions on where to start or tutorials that would give a good heads up would be most welcome.
Please keep in mind the C code is not mine (but is freely available under GNU), I am not a C programmer and am only weakly-moderately proficient in R. So please be gentle :)
Cheers.
PS: If I call the function in R terminal via .Call it works as expected (so it doesn't seem to e a C function error)
I thought I should post the solution I have to this. The least I could do for a 'tumbleweed' medal haha.
The only solution I could find to this is to comment out the following line:
ans <- new("_p_parameters", ref=ans) ;
in all function that try to create an R object.
The resulting memory pointer is then assigned to an R object at function call.
It's dirty, but I couldn't work out how to create an object from a memory pointer (at least from within the functions themselves).
It seems to work so I guess it will do.
Related
Reading through https://docs.perl6.org/language/packages#Package-qualified_names it outlines qualifying package variables with this syntax:
Foo::Bar::<$quux>; #..as an alternative to Foo::Bar::quux;
For reference the package structure used as the example in the document is:
class Foo {
sub zape () { say "zipi" }
class Bar {
method baz () { return 'Þor is mighty' }
our &zape = { "zipi" }; #this is the variable I want to resolve
our $quux = 42;
}
}
The same page states this style of qualification doesn't work to access &zape in the Foo::Bar package listed above:
(This does not work with the &zape variable)
Yet, if I try:
Foo::Bar::<&zape>; # instead of &Foo::Bar::zape;
it is resolves just fine.
Have I misinterpreted the document or completely missed the point being made? What would be the logic behind it 'not working' with code reference variables vs a scalar for example?
I'm not aware of differences, but Foo::Bar::<&zape> can also be modified to use {} instead of <>, which then can be used with something other than literals, like this:
my $name = '&zape';
Foo::Bar::{$name}()
or
my $name = 'zape';
&Foo::Bar::{$name}()
JJ and Moritz have provided useful answers.
This nanswer is a whole nother ball of wax. I've written and discarded several nanswers to your question over the last few days. None have been very useful. I'm not sure this is either but I've decided I've finally got a first version of something worth publishing, regardless of its current usefulness.
In this first installment my nanswer is just a series of observations and questions. I also hope to add an explanation of my observations based on what I glean from spelunking the compiler's code to understand what we see. (For now I've just written up the start of that process as the second half of this nanswer.)
Differences (if any) between Package::<&var> vs &Package::var?
They're fundamentally different syntax. They're not fully interchangeable in where you can write them. They result in different evaluations. Their result can be different things.
Let's step thru lots of variations drawing out the differences.
say Package::<&var>; # compile-time error: Undeclared name: Package
So, forget the ::<...> bit for a moment. P6 is looking at that Package bit and demanding that it be an already declared name. That seems simple enough.
say &Package::var; # (Any)
Quite a difference! For some reason, for this second syntax, P6 has no problem with those two arbitrary names (Package and var) not having been declared. Who knows what it's doing with the &. And why is it (Any) and not (Callable) or Nil?
Let's try declaring these things. First:
my Package::<&var> = { 42 } # compile-time error: Type 'Package' is not declared
OK. But if we declare Package things don't really improve:
package Package {}
my Package::<&var> = { 42 } # compile-time error: Malformed my
OK, start with a clean slate again, without the package declaration. What about the other syntax?:
my &Package::var = { 42 }
Yay. P6 accepts this code. Now, for the next few lines we'll assume the declaration above. What about:
say &Package::var(); # 42
\o/ So can we use the other syntax?:
say Package::<&var>(); # compile-time error: Undeclared name: Package
Nope. It seems like the my didn't declare a Package with a &var in it. Maybe it declared a &Package::var, where the :: just happens to be part of the name but isn't about packages? P6 supports a bunch of "pseudo" packages. One of them is LEXICAL:
say LEXICAL::; # PseudoStash.new(... &Package::var => (Callable) ...
Bingo. Or is it?
say LEXICAL::<&Package::var>(); # Cannot invoke this object
# (REPR: Uninstantiable; Callable)
What happened to our { 42 }?
Hmm. Let's start from a clean slate and create &Package::var in a completely different way:
package Package { our sub var { 99 } }
say &Package::var(); # 99
say Package::<&var>(); # 99
Wow. Now, assuming those lines above and trying to add more:
my Package::<&var> = { 42 } # Compile-time error: Malformed my
That was to be expected given our previous attempt above. What about:
my &Package::var = { 42 } # Cannot modify an immutable Sub (&var)
Is it all making sense now? ;)
Spelunking the compiler code, checking the grammar
1 I spent a long time trying to work out what the deal really is before looking at the source code of the Rakudo compiler. This is a footnote covering my initial compiler spelunking. I hope to continue it tomorrow and turn this nanswer into an answer this weekend.
The good news is it's just P6 code -- most of Rakudo is written in P6.
The bad news is knowing where to look. You might see the doc directory and then the compiler overview. But then you'll notice the overview doc has barely been touched since 2010! Don't bother. Perhaps Andrew Shitov's "internals" posts will help orient you? Moving on...
In this case what I am interested in is understanding the precise nature of the Package::<&var> and &Package::var forms of syntax. When I type "syntax" into GH's repo search field the second file listed is the Perl 6 Grammar. Bingo.
Now comes the ugly news. The Perl 6 Grammar file is 6K LOC and looks super intimidating. But I find it all makes sense when I keep my cool.
Next, I'm wondering what to search for on the page. :: nets 600+ matches. Hmm. ::< is just 1, but it is in an error message. But in what? In token morename. Looking at that I can see it's likely not relevant. But the '::' near the start of the token is just the ticket. Searching the page for '::' yields 10 matches. The first 4 (from the start of the file) are more error messages. The next two are in the above morename token. 4 matches left.
The next one appears a quarter way thru token term:sym<name>. A "name". .oO ( Undeclared name: Package So maybe this is relevant? )
Next, token typename. A "typename". .oO ( Type 'Package' is not declared So maybe this is relevant too? )
token methodop. Definitely not relevant.
Finally token infix:sym<?? !!>. Nope.
There are no differences between Package::<&var> and &Package::var.
package Foo { our $var = "Bar" };
say $Foo::var === Foo::<$var>; # OUTPUT: «True»
Ditto for subs (of course):
package Foo { our &zape = { "Bar" } };
say &Foo::zape === Foo::<&zape>;# OUTPUT: «True»
What the documentation (somewhat confusingly) is trying to say is that package-scope variables can only be accessed if declared using our. There are two zapes, one of them has got lexical scope (subs get lexical scope by default), so you can't access that one. I have raised this issue in the doc repo and will try to fix it as soon as possible.
I know the subject has already been treated, but I've failed to find anything that works for me, so I guess my problem is slightly different from the others.
What I do, basically, is that I use a C function wrapped into a python code using ctypes.
My goal is to compute some quantities in the C function, store them into a single structure, and return the structure in Python where I could read all the different data in the structure.
So :
To define my structure in python, I use :
class BITE(ctypes.Structure):
_fields_ = [
("lum", ctypes.c_int),
("suce", ctypes.c_int)
]
I compile like that :
sub.call(["gcc","-shared","-Wl,-install_name,ex.so","-o","ex.so","-fPIC","ex.c"])
lum = ctypes.CDLL('ex.so')
lum = lum.lum
I declare the arguments and result types like this :
lum.restype = ctypes.POINTER(BITE)
lum.argtypes = [ctypes.POINTER(ctypes.c_float),ctypes.c_int,ctypes.POINTER(ctypes.c_float),ctypes.c_int,ctypes.POINTER(ctypes.c_float),ctypes.POINTER(ctypes.c_float),ctypes.c_int,ctypes.POINTER(ctypes.c_float),ctypes.c_int,ctypes.POINTER(ctypes.c_float),ctypes.POINTER(ctypes.c_float),ctypes.POINTER(ctypes.c_float),ctypes.POINTER(ctypes.c_float),ctypes.c_float,ctypes.c_float,ctypes.c_float,ctypes.c_float,ctypes.c_float]
Then, I call the C function "lum" in the python code
out = lum(all the different variables needed)
The problem begins here. I have my structure, but impossible to read the data stored in each fields.
A partial solution I found is to do :
out = out[0]
But then, when doing
print(out.suce)
I have a segmentation fault 11. DOn't know why. I tried to understand how to used create_string_buffer, but I didn't really understand how it works and what it supposed to do. Moreover, I tried to using as a black box, and still, nothing works.
I also tried some other solutions mentionned in other threads such as using out.contents or something like that, but it has no .contents attributes. Nor out.suce.value, which is also something I saw somewhere during my desperate research.
Of course, I checked in the C code that the structure exists and that each field of the structure exists, and has the right data in it.
Thanks.
Suppose you have a C-structure like this :
typedef struct _servParams
{
unsigned short m_uServPort;
char m_pInetAddr[MAX_LENGTH_OF_IP_ADDRESS];
} ServerParams_t;
To use it within ctypes you should create a wrapper like this :
class ServerParams_t(Structure):
_fields_ = [ ("m_uServPort", c_ushort),
("m_pInetAddr", (c_char * 16)) ]
Later on inside your python you can use the following snippet :
servParams = ServerParams_t()
servParams.m_uServPort = c_ushort(int(port))
servParams.m_pInetAddr = ip.encode()
If you need to pass it by value, simply pass servParams variable to you api. If you need to pass a pointer use byref(servParams).
So, I'm trying to program an AI for the game Screeps, whose docs are found here.
I'm trying to write my AI in OCaml, which I'm then compiling to Javascript via Bucklescript, whose docs are found here.
Anywho, within Screeps' API is the method Game.spawns.SPAWN_NAME.createCreep, in which SPAWN_NAME corresponds to the name of the 'spawn' object in question. It takes in a string array corresponding to the various body parts of the 'Creep' it is helping to spawn, and given a correct function call (with enough energy reserves), your Creep will spawn in game.
An example call (in JS) would be Game.spawns['Spawn1'].createCreep(["body","move"]);
I already have code which gives me a string array of all the spawns in OCaml. That code is:
let spawns : string array = [%bs.raw{|Object.keys(Game.spawns)|}]
let spawnsArray : string array = spawns
Lets say that I have one spawn called Spawn1, and that I also have a string array for the body composition in OCaml:
let spawnName : string = "Spawn1"
let body : string array = [|"body","move|]
I then iterate over each string within that array, using a for loop like the one below:
for i=0 to Array.length spawns - 1 do
// I WANT TO CALL SOMETHING ANALOGOUS TO MY FUNCTION HERE
done
I just can't, for the life of me, figure out how to format the Bucklescript bindings so that I can dynamically call the createCreep function with body : string array and spawnName : string. Any help would be amazing. I know there are the bs.get and bs.set methods described briefly within the Bucklescript docs, but I don't know how to use them.
Thanks in advance for the help.
EDIT:
I managed to 'work around' the issue by writing my own 'interfacing' functions in a Javascript module which I can then call via the bs.module Bucklescript binding.
IE I wrote a function
function spawnCreepHelper(spawnName, body) {
Game.spawns[spawnName].createCreep(body);
}
which I'm then able to call via
external spawnCreepHelper : string -> string array -> unit = ""
[##bs.module "./supplemental", "Supplement"]
Seems kind of hacked together to me, so if anyone has another way of approaching it that doesn't involve rewriting their API myself, please let me know.
You probably want the bs.get_index attribute:
type spawn
type spawns
external spawns : spawns = "" [##bs.val] [##bs.scope "Game"]
external getSpawn : spawns -> string -> spawn = "" [##bs.get_index]
external createCreep : spawn -> string array -> unit = "" [##bs.send]
let _ =
let spawn = getSpawn spawns "spawn1" in
createCreep spawn [|"body"; "move"|]
compiles to
var spawn = Game.spawns["spawn1"];
spawn.createCreep(/* array */[
"body",
"move"
]);
You can then get the keys by providing your own typed external to Object.keys:
external keys : spawns -> string array = "" [##bs.val] [##bs.scope "Object"]
let _ =
spawns |> keys
|> Js.Array.forEach Js.log
which will compile to
Object.keys(Game.spawns).forEach((function (prim) {
console.log(prim);
return /* () */0;
}));
Alternatively, you could type spawns as a spawn Js.Dict and use the functions already provided by BuckleScript to access and manipulate it: https://bucklescript.github.io/bucklescript/api/Js.Dict.html
Say that you pass an environment R object to an internal C routine through the .Call interface. Said enviromnent has (by design) a someObject object which I want to extract and manipulate from the C side. How to do it?
To simplify my question, I just want to write a C function that returns someObject. Like this:
en <- new.env()
en$someObject <- someValue
.Call("extractObject",en)
#the above should return en$someObject
Guess the C code should then look something like
SEXP extractObject(SEXP env) {
return SOMEMACROORFUNCTION(env, "someObject");
}
Unfortunately, I was not able to find the real SOMEMACROORFUNCTION.
After a little bit of googling and searching, I've found the solution:
findVar(install("someObject"),env)
in the C code is basically the equivalent of get("someObject",env) in R.
I have created an array of objects and I would like assign a property value in a vector operation without using a for loop. Unfortunately I get an error.
A simplified example of the problem.
classdef clsMyClass < handle
properties
dblMyProperty1
end
methods
function obj = clsMyClass()
end
end
end
And when running
vecMyArray = clsMyClass.empty(100,0);
vecMyArray(100) = clsMyClass;
vecMyArray.dblMyProperty1 = 1:100;
We get the following error:
??? Incorrect number of right hand side elements in dot name
assignment. Missing [] around left hand side is a likely cause.
Any help would be appreciated.
I see what you're trying to do now. Use disperse from the MATLAB File Exchange:
>> [vecMyArray.dblMyProperty1] = disperse(1:100);
>> vecMyArray(1).dblMyProperty1
ans =
1
>> vecMyArray(10).dblMyProperty1
ans =
10
You can use the deal function for exactly this purpose:
[vecMyArray.dblMyProperty1] = deal(1:100);
See: http://www.mathworks.com/company/newsletters/articles/whats-the-big-deal.html
Edit: No you can't, actually; that'll set them to all be the vector 1:100.
I think you'll find your answer here in "Struct array errors." Even though this is a class, similar rules apply.
Unfortunately missing [] is not the cause, since adding them causes more errors. The cause is that you cannot assign the same value to all fields of the same name at once, you must do it one at a time, as in the following code:
So you'll need:
for ii=1:100
vecMyArray(ii).dblMyProperty1 = ii;
end
I know it's not satisfying, but I think it at least helps us to definitively understand this error.