I've been trying to write a script-fu script for GIMP 2.6+ that uses one of the built-in script-fu methods, namely the script-fu-add-bevel method. My problem is that whenever I call it, either in the console or in my script, I get:
Error: Procedure execution of gimp-drawable-type-with-alpha failed on invalid input
arguments: Procedure 'gimp-drawable-type-with-alpha' has been called with an
invalid ID for argument 'drawable'. Most likely a plug-in is trying to work on a layer that
doesn't exist any longer.
This is really strange because I can clearly see by calling gimp-image-get-active-drawable with my image ID as the parameter that the layer ID that I'm passing to the script-fu method exists. The script is erroring while calling gimp-drawable-type-with-alpha, but I can call this method with the same ID in the console with no error. How can I fix this problem?
From this forum post, I learned that when calling a script-fu method, you shouldn't pass in the run-mode argument. This is done behind the scenes, and if you pass anything for that value, it will be interpreted as the second argument! This means that every argument you send in will be one parameter off, and it's only a matter of time before the script crashes.
So calling script-fu-add-bevel from another script-fu would look something like this:
(script-fu-add-bevel img layer bevel-width FALSE FALSE)
Related
I have encountered an issue recently while processing a CICS transaction. My CICS transaction is calling a chain of dynamically linked COBOL modules. The transaction runs fine for the first time after the PGM-A load is new copied into the region. When I try to process the transaction for the second time, I keep getting CEE3DD abend saying the module not found for PGM-B which is being called from PGM-A. IF I do a new copy for PGM-A in CICS, the transaction again runs fine.
Something is wrong with the CICS setup or memory but I am not able to figure it out. PGM-A is working fine in batch processing. PGM-B has no issues when it is called from any other PGMs except PGM-A.
Can someone share some thoughts on what may be wrong with this?
To invoke your program via CICS, it must be compiled with the NODYNAM option.
It admittedly seems counter-intuitive, but using the DYNAM option will cause CICS stubs to be loaded, instead of your intended programs, and result in the CEE3501S condition.
So, compile your programs with the NODYNAM option to avoid this error condition.
See the following links for additional info:
https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.3.0/com.ibm.cics.ts.applicationprogramming.doc/topics/dfhp3_cobol_subprog_rules.html
http://www-01.ibm.com/support/docview.wss?uid=swg21054079
Does PGM-A use "CALL VARIABLE" to invoke PGM-B? If so check the contents of VARIABLE on the second run (the contents of that variable will probably be reported in the error message. The contents of the variable may be overwritten by a bug in PGM-A. That might explain why the program always fails after the (seemingly) succesful run and after a newcopy.
Converting this from dynamic to static worked. But the question remains why it was not working with dynamic linking.
I'm using the closure compiler to minify and speed up my code but I'm running into some issues with JSLint when I try to export my functions.
Basically, I have an object, foo{} with a function, foo.bar() that gets called via an external file as. In order for this function to be called externally I need to add some declarations to my script before it gets compiled:
window['foo'] = foo;
window['foo']['bar'] = foo.bar;
This works great, but—as ever—JSLint thinks I'm mental for even attempting this. I've managed to suppress the dot notation error by declaring, /*jslint sub: true */ just before these two lines but I still get the following error:
"window['foo']['bar'] = foo.bar;" - Weird assignment
It's not wrong, it is a weird assignment out of context, but I need it in there in order for my code to work.
The way I see it, I have three possible options:
Tell JSLint not to bother even looking at them two lines.
Suppress the Weird assignment error.
Find another way to make my code work with closure compiler.
The problem is, I have no idea how to go about doing any of them.
You can export names using goog.exportSymbol instead of bracket notation: https://github.com/google/closure-library/blob/master/closure/goog/base.js#L1532
The Closure Compiler understands what goog.exportSymbol is so it'll remove the explicit exportSymbol call and add foo and bar directly to the window for you.
When I look at Java method AST declaration in Rascal, I see under Expression \super() node.
However in Java, you can also call super() with parameters. So, I expected to see something like : \super(list[Expression] arguments), but I do not see it.
Is it traced via \methodCall() or in some other way?
I could not try it myself because I get an error when I try to build an AST from a constructor with getMethodASTEclipse() method. I already opened an issue about this getMethodASTEclipse() error in the GitHub.
If luaL_load function fails, then, according to the documentation (Lua5.1), the error message is pushed on the stack and can be retrieved with lua_tostring(L, -1), but if I want to print a customized error message, I don't think I can use lua_Debug (because that is for active function). Is there any other way (other than parsing the string) to get the file, line number and what error occured ?
--
Thanks.
The error code returned by luaL_loadfile tells you what kind of error happened. You're mostly likely only interested in LUA_ERRSYNTAX, in which case there is a detailed error message left on the stack. This is the only record of the error. If you need to reformat it, you need to parse it.
During a luaL_load(), there is nothing techinally on the stack that is relavant to the loading of the script. No functions are performed or executed in the script. Its just a compilation step, returning a function that encapsulates the whole file or the error found during compilation.
If you get a function back, you execute this to actually run the script, which sounds like what you are really interested in. In which case you can use a lua_pcall() and provide an error handler. In your handler you would then have your expected stack trace available via lua_Debug.
I have an application that periodically will run a Lua script. Within the script, on occasion, I have created a custom registered Lua function to check some parameters and decide if the Lua script should continue or exit. The logic ideally should not be part of the script and I can think of using a Lua script to work around this, but I'm wondering if it is possible to stop the execution of a Lua script without ending the application.
I have a custom function written in Delphi and exposed to Lua scripts using Lua 5.1. The Lua script looks something like that shown below and the script in Lua is started using luaL_loadbuffer.
io.write("Script starting\n");
--Custom Function
ExitIfFound();
io.write("Script continuing\n");
My custom function looks something like this, below I have provided one of my attempts where I tried to use lua_error to stop the script...
function ExitIfFound(LuaState: TLuaState): Integer;
var
s: AnsiString;
begin
s := 'ExitIfFound ending script, next Lua script line not called';
lua_pushstring(LuaState, PAnsiString(s));
lua_error(LuaState);
end;
When my custom function is called, I'm unsure as to how to exit the Lua script without any further evaluation. I have seen posts referring to Lua and using setjmp and longjmp in C, but I'm curious how these may translate Delphi.
In the example above, when I use lua_error, the entire program crashes with Windows doing its typical, [luarun.exe has stopped working] ...
With all of this, I'm am still pretty new to integrating Lua to Delphi and hoping that I can find some cleaner options to explore.
There is no clean way to entirely abort a Lua script. The lua_error function is the correct way to signal an error. It is the caller's responsibility to catch the error and propagate it to the next caller.
If you cannot rely on the caller to cooperate, then you can try to exert more control by installing debug hooks. Then the host program will be consulted before continuing to run the script. However, the script can still avoid exiting by using pcall to catch any errors.
The crash in your program is probably not simply from setting an error. Rather, it's likely from using the wrong calling convention on your ExitIfFound function. It needs to be cdecl, but Delphi's default, if you don't specify anything else, is register. Using the wrong calling convention will give you unpredictable parameter values and can lead to a corrupted stack. If you type-casted the function or used the # operator when you called lua_register, then you might have hidden the calling-convention mismatch from the compiler's type checker, which would have otherwise alerted you to the problem at compile time.
When compiled as C++, lua_error will use a exception instead of longjmp, but either way, the caller always catches the error. Exceptions are important, though, when your Delphi code uses compiler-managed types like string, or exception-sensitive constructs like try-finally blocks. In C mode, lua_error calls longjmp to jump directly to the waypoint set by a previous call to setjmp. That jump will skip over any exception handlers like the ones the Delphi compiler sets up to ensure the finally block runs and the string gets cleaned up.
A further headache is that since the compiler cleans up the string while exiting the function, the pointer you put on the Lua stack might not be valid by the time it's used; that depends on whether lua_pushstring makes a copy of its argument.