Dyalog Forums

I wish to turn a debugging feature used within Dyalog APL on and off from the Raspberry Pi command line before I start running APL.

I thought I could on the command line:

which appears to work because


So I thought from within the APL session I could read $DEBUGANT thus

unfortunately "a" did not contain what I expected:


Can someone tell me where I am going wrong, and how to correctly set up an environment variable and then read in in Dyalog APL..

Thanks

Hi Ray

You should find that

export DEBUGANT=1
/opt/mdyalog/17.1/32/unicode/mapl
⎕sh'echo $DEBUGANT'
should work, as should

⊣2⎕nq'.' 'GetEnvironment' 'DEBUGANT'
this last one is rather quicker than calling ⎕SH.

You can also use
DEBUGANT=1 /opt/mdyalog/17.1/32/unicode/mapl

For setting DEBUGANT on a more permanent basis, you can always add
export DEBUGANT=1
to $HOME/.dyalog/dyalog.config

Thanks Andy

I have now found the reason that I am having problems with my $DEBUGANT exported variable from within my APL session, it is because I export it as "pi" but am running APL as "root".

I know it is not recommend running Dyalog on the RPI as "root" but (so far) I have not found any way around this. I need ROOT privileges to access certain aspects of the GPIO pins used by C programs accessed via ⎕NA calls. Hence, I have to start APL from "root" and not "pi".

Then when I try from within APL to access $DEBUGANT, it is not found in the "root" environment!

As Andy suggests, (when I run APL as "pi") I have no problem accessing $DEBUGANT.

As an aside Andy, is Dyalog version 17.1 (and for that matter RIDE 4.2) available to us "mere mortals" yet? You have mentioned both in recent replies to my queries!

Hi Ray

I suspect that you're calling something like
in which case you have to work a bit (lot) harder to get your environment variable into your APL process.

If you and addand then call that should get you what you want. I only know this as I needed it for running part of the QAs as root; you may be able to tighten it down further if you want/need to.

What you may like to try is to then initialise the ⎕NA calls and then call

      4007⌶'ray'

so that your process continues to run with ray's privileges. Note that 4007⌶ can only be called once in a process, and only works on non-Windows platforms. We implemented this for several reasons, the most important being that when you start a web server and you want to bind to port 80 (or indeed any port less than 1024) then you must do so with a process with root privileges, but once you've bound to the port, you want to run as a normal user. Not entirely sure whether this will work for you but it might be worth a try. FWIW you can compare ⊃⎕ai and ⎕an to see what your effective and real userids are.

17.1 is still just around the corner; we're making some changes to new extensions to the HTMLRenderer. 17.1 will come bundled with RIDE 4.2, but we also encourage people to download RIDE from Github; there is no difference in functionality between what's on GitHub and what appears in an installation image. I would recommend however always taking the release marked as "Latest Release" rather than marked as "Draft".

Hi Andy

Thank you for a most useful and informative reply. I was also totally unaware of visudo and have been investigating it further via google.

I have a script to start up Dyalog APL on the pi which includes the extra command to allow remote access to the session via Ride.

I will have fun playing with my new knowledge.

Thanks again