I have written a Perl XS wrapper for a C library consisting of about ~80
functions. Right now my general strategy is to substitute the error from a C
function with PL_sv_undef and the calling Perl code has to check explicitly
whether the return is not undef. (For some C functions it is more complicated
as I convert their output into a HV/AV and use empty list to report the error.)
Now as I moved to writing bigger Perl scripts using that library, I want to
simplify the error handling and use e.g. the usual eval {}/die exception-like
mechanism to handle errors.
At the moment a simple XSUB in my XS look like that:
SV *
simple_function( param1, param2 = 0, param3 = 0)
int param1
int param2
int param3
CODE:
int rc;
rc = simple_function( param1, param2, param3 );
RETVAL = (rc == 0) ? &PL_sv_yes : &PL_sv_undef;
OUTPUT:
RETVAL
I have seen that some modules have global flag like "RaiseError" to die on
errors but failed to find any example I can borrow from. The few modules I have
found handle the "RaiseError" flag inside the .pm, not inside the .xs, and
thus allowed to use the Perl's die. In my case that is rather hard to
implement inside the .pm as many functions require special error checks. That
would also lead to code duplication as the checks are already present inside the XS.
I found nothing relevant in the perlxs/perlguts documentation. In particular, I have seen calls to Perl_croak() in the .c generated from my .xs, but failed to locate any documentation for the function.
What is the XS' analog of the Perl's die? Or how else can the XSUB report to Perl
run-time that the function has failed and there is no RETVAL to return? How to properly set the $#?
Perl_croak() is documented here on the perlapi man page. As the example on that page shows, you can either pass it a message string, or you can manually set $# to an exception object and pass NULL.
Related
I think the question sums it up pretty well as to what I want: passing the value of a variable to a macro in SystemVerilog.
For example, what I want:
Say, there are 4 signals by the name of abc_X_def and I want to initialize all of them to 0.
So, without macros:
abc_0_def = 4'b0000;
abc_1_def = 4'b0000;
abc_2_def = 4'b0000;
abc_3_def = 4'b0000;
Now, the code that I have written is having a problem:
`define set_value(bit) abc_``bit``_def = 4'b0000
for (int i = 0; i < 4; i++) begin
`set_value(i);
end
The error is that it's trying to find the signal abc_i_def which is obviously wrong. Just wondering if it's possible to pass the actual value of the variable 'i' to the macro.
The preprocessor directives are evaluated by the preprocessor and modify the code that is presented to the compiler.
The for loop is a verilog construct that is evaluated by the compiler.
So your preprocessor is not evaluating the for loop. It sees:
`define `set_value(bit) abc_``bit``_def = 4'b0000
[some verilog]
`set_value(i);
[some verilog]
So 'i' is just i. It doesn't become a number until compilation.
Why don't you use local params with generate, so the local params are created in a loop at elaboration as the for loop is unrolled?
This is one of the many places that macros are a problem. Generate is a problem in other places (like when you want to control port lists).
I dug into this a bit more. Parameters and local parameters inside a generate are created a localparams in the scope of the generate. See here: System Verilog parameters in generate block. I had to get back to work before I could test it.
I would just use code and populate an array. This compiles in VCS:
module veritest
#(
parameter MAX_X = 5,
MAX_Y = 3,
MAX_Z = 2
)
(); // empty port list
logic [4:0] abc_def[1:MAX_X][1:MAX_Y][1:MAX_Z];
always #*
begin
for (integer z=1; z<(MAX_X+1);z=z+1)
for (integer y=1; y<(MAX_Y+1);y=y+1)
for (integer x=1; x<(MAX_X+1);x=x+1)
begin
abc_def[x][y][z] = 4'b0000;
end
end
endmodule
Since you said the naming conventions is out of your control, you should consider using another tool to generate the verilog for you.
You can have the code generated by your preferred programming then use an `include statement in your verilog file. Or you can go with an embedded route.
Perl had EP3 : http://search.cpan.org/~gspivey/Text-EP3-Verilog-1.00/Verilog.pm
Ruby has eRuby : http://www.tutorialspoint.com/ruby/eruby.htm
I'm sure something like it exists for other languages to. Such as Python, Tcl, JavaScript, etc.
Concept is the same, just a difference in embedded language and tool used for conversion.
I am adding to Exim an embedded python interpreter. I have copied the embedded perl interface and expect python to work the same as the long-since-coded embedded perl interpreter. The goal is to allow the sysadmin to do complex functions in a powerful scripting language (i.e. python) instead of trying to use exim's standard ACL commands because it can get quite complex to do relatively simple things using the exim ACL language.
My current code as of the time of this writing is located at http://git.exim.org/users/tlyons/exim.git/blob/9b2c5e1427d3861a2154bba04ac9b1f2420908f7:/src/src/python.c . It is working properly in that it can import the sysadmin's custom python code, call functions in it, and handle the returned values (simple return types only: int, float, or string). However, it does not yet handle values that are passed to a python function, which is where my question begins.
Python seems to require that any args I pass to the embedded python function be explicitly cast to one of int,long,double,float or string using the c api. The problem is the sysadmin can put anything in that embedded python code and in the c side of things in exim, I won't know what those variable types are. I know that python is dynamically typed so I was hoping to maintain that compliance when passing values to the embedded code. But it's not working that way in my testing.
Using the following basic super-simple python code:
def dumb_add(a,b):
return a+b
...and the calling code from my exim ACL language is:
${python {dumb_add}{800}{100}}
In my c code below, reference counting is omitted for brevity. count is the number of args I'm passing:
pArgs = PyTuple_New(count);
for (i=0; i<count; ++i)
{
pValue = PyString_FromString((const char *)arg[i]);
PyTuple_SetItem(pArgs, i, pValue);
}
pReturn = PyObject_CallObject(pFunc, pArgs);
Yes, **arg is a pointer to an array of strings (two strings in this simple case). The problem is that the two values are treated as strings in the python code, so the result of that c code executing the embedded python is:
${python {dumb_add}{800}{100}}
800100
If I change the python to be:
def dumb_add(a,b):
return int(a)+int(b)
Then the result of that c code executing the python code is as expected:
${python {dumb_add}{800}{100}}
900
My goal is that I don't want to force a python user to manually cast all of the numeric parameters they pass to an embedded python function. Instead of PyString_FromString(), if there was a PyDynamicType_FromString(), I would be ecstatic. Exim's embedded perl parses the args and does the casting automatically, I was hoping for the same from the embedded python. Can anybody suggest if python can do this arg parsing to provide the dynamic typing I was expecting?
Or if I want to maintain that dynamic typing, is my only option going to be for me to parse each arg and guess at the type to cast it to? I was really really REALLY hoping to avoid that approach. If it comes to that, I may just document "All parameters passed are strings, so if you are actually trying to pass numbers, you must cast all parameters with int(), float(), double(), or long()". However, and there is always a comma after however, I feel that approach will sour strong python coders on my implementation. I want to avoid that too.
Any and all suggestions are appreciated, aside from "make your app into a python module".
The way I ended up solving this was by finding out how many args the function expected, and exit with an error if the number of args passed to the function didn't match. Rather than try and synthesize missing args or to simply omit extra args, for my use case I felt it was best to enforce matching arg counts.
The args are passed to this function as an unsigned char ** arg:
int count = 0;
/* Identify and call appropriate function */
pFunc = PyObject_GetAttrString(pModule, (const char *) name);
if (pFunc && PyCallable_Check(pFunc))
{
PyCodeObject *pFuncCode = (PyCodeObject *)PyFunction_GET_CODE(pFunc);
/* Should not fail if pFunc succeeded, but check to be thorough */
if (!pFuncCode)
{
*errstrp = string_sprintf("Can't check function arg count for %s",
name);
return NULL;
}
while(arg[count])
count++;
/* Sanity checking: Calling a python object requires to state number of
vars being passed, bail if it doesn't match function declaration. */
if (count != pFuncCode->co_argcount)
{
*errstrp = string_sprintf("Expected %d args to %s, was passed %d",
pFuncCode->co_argcount, name, count);
return NULL;
}
The string_sprintf is a function within the Exim source code which also handles memory allocation, making life easy for me.
Greetings,
I'm using mktemp() (iPhone SDK) and this function returns a char * to the new file name where all "X" are replaced by random letters.
What confuses me is the fact that the returned string is automatically free()d. How (and when) does that happen? I doubt it has something to do with the Cocoa event loop. Is it automatically freed by the kernel?
Thanks in advance!
mktemp just modifies the buffer you pass in, and returns the same poiinter you pass in, there's no extra buffer to be free'd.
That's at least how the OSX manpage describes it(I couldn't find documentation for IPhone) , and the posix manpage (although the example in the posix manpage looks to be wrong, as it pass in a pointer to a string literal - possibly an old remnant, the function is also marked as legacy - use mkstemp instead. The OSX manpage specifically mention that as being an error).
So, this is what will happen:
char template[] = "/tmp/fooXXXXXX";
char *ptr;
if((ptr = mktemp(template)) == NULL) {
assert(ptr == template); //will be true,
// mktemp just return the same pointer you pass in
}
If it's like the cygwin function of the same name, then it's returning a pointer to an internal static character buffer that will be overwritten by the next call to mktemp(). On cygwin, the mktemp man page specifically mentions _mktemp_r() and similar functions that are guaranteed reentrant and use a caller-provided buffer.
Can anyone give an example of how a string can be returned from a call using Win32::API() function? I need to return a string and print using $val. Please give an example if the same can be handled using pointer as return type.
use Win32::API;
my $res = new Win32::API('abc.dll','MyFun','_argument type list_','_Return type list_')or die $^E;
my $val= $res->Call();
print ($val);
The documentation for Win32::API's Call() method suggests that you must pass Call() a scalar which will be used as a buffer to store the returned value; Call() itself will return whether the call succeeded or not.
Example:
my $return_buffer = " " x 80;
if ($res->Call(80, $return_buffer)) {
print "OK, the API call returned '$return_buffer'\n";
} else {
print "The API call failed for some reason.\n";
}
EDIT: quoting from the docs for completeness:
The two parameters needed here are the length of the buffer that will hold the returned temporary path, and a pointer to the buffer itself. For numerical parameters, you can use either a constant expression or a variable, while for pointers you must use a variable name (no Perl references, just a plain variable name). Also note that memory must be allocated before calling the function, just like in C. For example, to pass a buffer of 80 characters to GetTempPath(), it must be initialized before with:
$lpBuffer = " " x 80;
This allocates a string of 80 characters. If you don't do so, you'll probably get Runtime exception errors, and generally nothing will work. The call should therefore include:
$lpBuffer = " " x 80;
$GetTempPath->Call(80, $lpBuffer);
And the result will be stored in the $lpBuffer variable. Note that you don't need to pass a reference to the variable (eg. you don't need \$lpBuffer), even if its value will be set by the function.
I don't see any obvious problem with the way you are doing this. The Win32::API module is capable of receiving a char * from a DLL function and transforming it into a Perl scalar. This code, for example, does what I expect:
use Win32::API;
$GetCommandLine = Win32::API->new('kernel32',
'LPTSTR GetCommandLine()');
$val = $GetCommandLine->Call();
print "The command line of this program is: $val\n";
which is to print
The command line of this program is: C:\strawberry\perl\bin\perl.exe win32-api-string.pl
The obvious things are to check the return values as well as $! and $^E from every step of your code and that abc.dll is in your program's $PATH. You might want to drop the .dll from the function call (just say Win32::API->new('abc', ...) ) -- none of the examples ever explicitly include the .dll extension, and perhaps the module assumes that you won't use it (and will try to load a library from abc.dll.dll instead).
You also might want to try using the Win32::API constructor from a prototype, as I have done in my example. I find that this gives me fewer headaches setting the right argument and return types properly (but occasionally more headaches trying to shoe horn some object type into the list of types that Win32::API supports out of the box). (The parameter list style constructor is now deprecated anyway, according to the v0.59 docs).
I'd rather do this:
say $shop->ShopperDueDate->andand->day_name();
vs. this:
say $shop->ShopperDueDate->day_name() if $shop->ShopperDueDate;
Any ideas?
(This idea is inspired by the Ruby andand extension.)
(Actually it is inspired by the Groovy language, but most people don't know that ;-)
update: I think that both maybe() and eval {} are good solutions. This isn't ruby so I can't expect to read all of the methods/functions from left to right anyway, so maybe could certainly be a help. And then of course eval really is the perl way to do it.
You can use Perl's eval statement to catch exceptions, including those from trying to call methods on an undefined argument:
eval {
say $shop->ShopperDueDate->day_name();
};
Since eval returns the last statement evaluated, or undef on failure, you can record the day name in a variable like so:
my $day_name = eval { $shop->ShopperDueDate->day_name(); };
If you actually wish to inspect the exception, you can look in the special variable $#. This will usually be a simple string for Perl's built-in exceptions, but may be a full exception object if the exception originates from autodie or other code that uses object exceptions.
eval {
say $shop->ShopperDueDate->day_name();
};
if ($#) {
say "The error was: $#";
}
It's also possible to string together a sequence of commands using an eval block. The following will only check to see if it's a weekend provided that we haven't had any exceptions thrown when looking up $day_name.
eval {
my $day_name = $shop->ShopperDueDate->day_name();
if ($day_name ~~ [ 'Saturday', 'Sunday' ] ) {
say "I like weekends";
}
};
You can think of eval as being the same as try from other languages; indeed, if you're using the Error module from the CPAN then you can even spell it try. It's also worth noting that the block form of eval (which I've been demonstrating above) doesn't come with performance penalties, and is compiled along with the rest of your code. The string form of eval (which I have not shown) is a different beast entirely, and should be used sparingly, if at all.
eval is technically considered to be a statement in Perl, and hence is one of the few places where you'll see a semi-colon at the end of a block. It's easy to forget these if you don't use eval regularly.
Paul
I assume your second example should better be:
say $shop->ShopperDueDate ? $shop->ShopperDueDate->day_name() : undef;
instead of what it actually says.
Anyway, you can't do it with exactly that syntax without a source filter because undef isn't an object, but an unary operator, so it can't have any methods.
Instead, consider this:
package noop;
our $maybe = bless [], 'noop';
sub AUTOLOAD { undef };
This $noop::maybe is an object; all of its methods return undef though. Elsewhere, you'll have a regular function like this:
sub maybe { $_[0] || $noop::maybe; }
Then you can write this:
say maybe($shop->ShopperDueDate)->day_name()
This works because "maybe" returns returns its argument if true, otherwise it returns our $noop::maybe object which has methods which always return undef.
EDIT: Correction! the ->andand-> syntax can be had without a source filter, by using an XS that mucks about with Perl's internals. Leon Timmermans made an implementation that takes this route. It replaces the undef() function globally, so it's likely to be a lot slower than my method.
I think I've just written it. I've just uploaded it to CPAN, you can find it here.
Something like (untested):
use Object::Generic::False;
sub UNIVERSAL::andand { $_[0] || Object::Generic::False->false }
UNIVERSAL is automatically a subclass of all other classes, so this provides andand for all objects.
(Obviously creating methods in UNIVERSAL has the potential for conflicts or surprising action at a distance,
so it shouldn't be used carelessly.) If the object upon which the andand method is called is true, return it;
otherwise return a generic false object which returns itself for any method call used upon it.