I just discovered AutoHotKey and it seems like a dream come true. I have two .ahk scripts, A.ahk and B.ahk. I want to call script B from within script A.
The AHK forums are strangely silent on the subject but I am sure this is possible.
It's the #Include directive you are looking for. You include ScriptB.ahk, then call its functions like you normally would.
#include SomeFile.ahk
http://www.autohotkey.com/docs/commands/_Include.htm
Using an #include directive is more common, but occasionally you will need to call an external AHK script. This is easily accomplished using the Run or RunWait commands. While you can pass arguments to the called script through the command line you cannot call functions within it directly. Also, this approach will create a separate thread for the called script, but that may be the point.
What really helped was a combination of the previous answers and a little bit of outside knowledge. I needed a script that would call more than 1 script, and since my files were in different folders, I found that I needed to specify the entire path of the files (I am sure this could be shortened but this was good enough for me at this point). I also didn't want all the different scripts that were being called to appear in the tray of the taskbar so I added an ExitApp statement at the end.
So my 'generalized' code was follows. Hopefully it can help another person.
#SingleInstance, Force
; HotKeys
#Include C:\Users\username\path1\Arrows.ahk
#Include C:\Users\username\path1\HomeEndModifiers.ahk
; SoundKeys
#Include C:\Users\username\path2\VolumeAdjustment.ahk
; Opening Programs
#Include C:\Users\username\path3\OpeningPrograms.ahk
ExitApp
```
Related
I am trying to make a custom block for my x310 and use it.
So far, I'm stuck at the example FPGA image compilation because I can't use the custom block gain.
I've followed step by step the "Building an FPGA Image with OOT Blocks" tutorial and successfully compiled and uploaded the image to my x310. A uhd_usrp_probe returned the expected "0/Block#0" linked back and forth to the SEP4 Block. But a warning from RFNOC:BLOCK_FACTORY states "could not find block with Noc-ID 0xb16, 0xffff"
I proceeded anyway after compiling a custom C++ program based on the rfnoc_radio_loopback example in order to make use of the gain block,
I added this line in the includes:
#include <rfnoc::gain::gain_block_control.hpp>
And these two lines after the radio_block_control instancing:
uhd::rfnoc::block_id_t gain_id(0, "Block", 0);
rfnoc::example::gain_block_control::sptr gain_ctrl = graph->get_block<rfnoc::example::gain_block_control>(gain_id);
The program compiles fine but running it returns a LookupError stating "This device doesn't have a block of type rfnoc::example::gain_block_control with ID: 0/Block#0"
I tend to believe the lookup error is clear but I don't know what to do instead.
I first tried to use the block with gnuradio-companion but was not able to generate the block at all. I am sure I am missing something but I have no idea what (apart from actual brain cells).
What is wrong with my C++?
Is it possible to generate a gain block in gnuradio-companion and if yes how?
Do you know of some tutorial that explains the different procedures on how to use a custom block?
There is an example application (rfnoc-example/apps/init_gain_block.cpp) that will test the functionality of the block for you. You can compile/run that to see if your block is working.
If you are seeing uhd_usrp_probe return 0/Block#0 instead of 0/Gain#0, then the .so file is not being picked up properly. The easiest way to test this is to LD_PRELOAD the DLL like this:
LD_PRELOAD=/path/to/librfnoc-example.so uhd_usrp_probe
What this will do is force a preload of the DLL containing the block controller (which will make sure it is registered). You should be seing 0/Gain#0 as the block ID now.
When using the magic function %edit from QtConsole with IPython, the call does not block, and does not execute the saved code. It does however save a temporary file...
I think this is intended behavior due to GUI editors and uncertainty, and whatever that reason is for not being able to communicate with subprocess (pyZMQ?).
What do you suggest as the best way to mix %edit/%run magics?
I would not mind calling two different commands (one to edit, and one after I have saved and execution is safe). But those commands need a way to synchronize this target file location, or someone to persist storage, and probably need some crude form of predicatably generating filenames such that you can edit more than one file at a time, and execute in arbitrarily. Session persistence is not a must.
Would writing my own magic do any good? Hope we can %edit macros soon, that would do well enough to make it work.
you shoudl be able to do %edit filename.py and %run filename.py. The non blocking behavior is expected, and IIRC due to technical reason. Not unsurmountable but difficult.
You could define your own magic if you wish, improvement are welcomed.
Hope we can %edit macros soon, that would do well enough to make it work.
For that too, PR are welcomed. I guess as a workaround/option you can %load macro which would put macro on input n+1 , edit it and redefine it, that might be a good extension for a cell magic %%macro macroname
If you have some executable code on your input (from QtConsole), you can type
%edit 1-5
This fires the editor, creates a temporarily file (automatically managed), and loads your input lines. This is nearly enough, now how to retrieve the name of that temp file pragmatically?
I see the print statement on Stdout, but its not visible to QtConsole AFAIK. Could maybe redirect stdout to catch that line, but that may not be an option anyway if your doing something else with stdout.
If I could retrieve the full pathname that was just created, this would be cake. Store it where some magics will know how to find it. Then issue a followup command when ready,pops the name off the stack, loads it into a macro, and run. All this with 2 input commands and no names to remember (unless you want to find and use that macro again, but for 1 shot stuff...)
How do I catch or retrieve the path of that temporary file?
I know how to write some 100 lines C, but I do not know how to read/organize larger source like Rebol. Somewhere was a tutorial with hostkit and dll, but it seems R3 is now statically linked. So I do not know where to look.
How would I write a native which gets a value and returns another? Where to put it in the source? What to obey, like telling the GC I created something in C?
Also, how can I embed R3 in other programms, to call it from Python or Node? I ask for Python/Node part comes later. But my learning-main should access R3 in a similar way. Means dll. And are there some typical hooks for startup/shutdown etc in such ffi's?
[Edit: forgot to mention: it is for Rebol 3.]
That's two questions. :-)
Regarding the first (about adding a native)... it's probably best elaborated as developer documentation on a Wiki. Questions in the rebol tag should generally be more about the language from a user's point of view. The answers regarding source code itself typically will be long, and there's really only a few people who can answer it, or care about the answer (what StackOverflow calls "too localized"). And it will wind up being more of a c question at that point, if anything.
So telling the developers to get their act together and write that documentation and put it in a centrally organized place is probably the best idea! :-P But I actually did try this myself. I added a set-env native to set environment variables from the interpreter, and you can look at the diffs it took to do that in GitHub for a bit of an idea.
add SET-ENV, tweaks to host api for environment string handling
An important thing to remember is that when you touch certain files, you have to run make prep which does a lot of scanning and code generation automatically. Adding a native is one of those things where you're definitely going to have to do that, each time you change to an interface that fundamental.
As for your second question, which is more of a user-facing question about interpreter embedding, one of the first places to look is just in how the simple REPL is implemented. There are two versions in the main repository right now, one for Posix and one for Windows.
https://github.com/rebol/r3/blob/master/src/os/host-main.c
So a string goes in and a string comes out. But there are more complicated forms of interaction, and you can get to them from reb-host.h, which includes these files from src/include
#include "reb-config.h"
#include "reb-c.h"
#include "reb-ext.h" // includes reb-defs.h
#include "reb-args.h"
#include "reb-device.h"
#include "reb-file.h"
#include "reb-event.h"
#include "reb-evtypes.h"
#include "reb-net.h"
#include "reb-filereq.h"
#include "reb-gob.h"
#include "reb-lib.h"
So you can look through those files for the API as it existed at the moment of the December-12th open-sourcing. Things will be evolving, and hopefully much better documented. But for now that's what seems to be available. You could link the host kit as a shared/DLL or static library, it depends on your build settings and what compiler you use.
In code, I'd use
#include <sys/types.h>
#include <sys/ptrace.h>
ptrace(PT_DENY_ATTACH, 0, 0, 0);
to deny attaching to the process. I was wondering if there was a way to rename "ptrace()" to something less obvious. I tried copying ptrace.h into my own header file and changing int ptrace to something else, but that just failed with an undefined symbol error. And I can't find any other references to the function :\
Thank you in advance for anything on this.
ptrace is a system call. Even if you renamed that function in your C code, the actual ptrace call would still have to be made, so it would be visible in for example strace output (with all the parameters).
Using a macro trick will only make it very slightly less obvious (you'd need two greps instead of one to find it in your codebase). So I don't really see the point. (A macro trick would not change anything to the compiled code.)
You could try running the actual syscall yourself with syscall, but that's a lot of work and still wouldn't hide anything to strace up to that point. It would make it just a tiny bit harder to break there in gdb.
So IMO: what you're trying to do is not worth the effort.
Use #define in your header to create a new macro:
#define MyTrace(a,b,c,d) ptrace(a,b,c,d)
I'm working in an embedded system (RTXC) where I need to disable the debugger functionality which is enabled through a #define command. However, when I change the #define to undefine, compilation goes off fine, but when the linker runs, it encounters an error about a symbol not existing that belongs to the debug code (which should have been taken care of by the debugger variable not being defined). Is there any way for Make to ensure that a preprocessor variable does not get defined or stays undefined ?
The answer to your question is no, Make can't absolutely prevent a variable from being defined by, say, a #define expression in the code.
You seem to have an elusive problem. It could be a bug in your Makefiles, a misspelled directive, a bad macro (if you'll pardon the tautology) or something trivial. I'd suggest burning the forest: cut out everything until the problem stops, then see where it was hiding. If you get down to HelloWorld and the problem persists, let us know.
No. You will need to fix the bug in your code.
More specifically, there is something that is referencing the debug side of things outside of an #ifdef. Make won't be able to help you there.
Another possibility is that you have a .o or something left over from a previous build; you might want to try cleaning the build tree.