I am trying to run a simple IDL program from this website: https://www.colorado.edu/physics/phys4810/phys4810_sp08/tutorial.htm
here is the code:
PRO example
a=5 ;sets a to 5
b=13.5 ;and b to 13.5
c=a+b ;adds a and b and puts the result in c
d=a*sin(b) ;sets d to the product of a and Sine(b)
e=b*exp(a) ;sets e to the product of b and Exp(a)
print,a,b,c,d,e ;prints the results
END
the output should be:
5 13.5000 18.5000 4.01892 2003.58
however I am getting this:
IDL> .run example.pro
% Compiled module: EXAMPLE.
IDL>
I have copied the code exactly from the website I linked above and ran it exactly as shown above. I'd like to know where I've gone wrong. Also I am using mac OS 10.13.3 in case that is relevant. Thanks for the help.
.run is for main-level programs, you are trying to call a procedure. You should be able to do just:
IDL> example
Related
In REPL mode, Julia lets you type a semicolon and run shell commands, i.e.
;
cd ~
And then to return to Julian REPL
Is there a way to do something similar in a .jl file? The closest I found was run(…) and that has many caveats. This is a Linux environment, so I'm not concerned about the caveats of shell mode on Windows machines.
The broader topic of interest is in doing this for other REPL modes, like the R one provided by using RCall
As you mentioned, the default way to do is via the run command. If you have not already, check out the docs on this https://docs.julialang.org/en/v1/manual/running-external-programs/#Running-External-Programs which go into some of the caveats.
I am not sure I follow what you are getting at with RCall but it may perhaps be worth opening a separate question for that.
You can find the code for this at https://github.com/JuliaLang/julia/tree/master/stdlib/REPL/test.
Seems there is no API, just lots of typing.
Here is a minimal working example (the codes are mostly copied from different places from the folder above):
using REPL
mutable struct FakeTerminal <: REPL.Terminals.UnixTerminal
in_stream::Base.IO
out_stream::Base.IO
err_stream::Base.IO
hascolor::Bool
raw::Bool
FakeTerminal(stdin,stdout,stderr,hascolor=true) =
new(stdin,stdout,stderr,hascolor,false)
end
REPL.Terminals.hascolor(t::FakeTerminal) = t.hascolor
REPL.Terminals.raw!(t::FakeTerminal, raw::Bool) = t.raw = raw
REPL.Terminals.size(t::FakeTerminal) = (24, 80)
input = Pipe()
output = Pipe()
err = Pipe()
Base.link_pipe!(input, reader_supports_async=true, writer_supports_async=true)
Base.link_pipe!(output, reader_supports_async=true, writer_supports_async=true)
Base.link_pipe!(err, reader_supports_async=true, writer_supports_async=true)
repl = REPL.LineEditREPL(FakeTerminal(input.out, output.in, err.in, false), false)
repltask = #async REPL.run_repl(repl)
Now you can do:
julia> println(input,";ls -la *.jld2")
-rw-r--r-- 1 pszufe 197121 5506 Jul 5 2020 file.jld2
-rw-r--r-- 1 pszufe 197121 5506 Jul 5 2020 myfile.jld2
If yes, would I be able to check the values of the variables then? I am using Juno in atom.
Yes, there are a number of different debugging options available for Julia that allow you to set breakpoints, step into code, and inspect values of variables. If you're using Juno, you can check the Juno Debugging documentation here: http://docs.junolab.org/stable/man/debugging/
Regardless of IDE you can also debug using Debugger.jl.
Consider this code (from Debugger.jl README):
using Debugger
function foo(n)
x = n+1
((BigInt[1 1; 1 0])^x)[2,1]
end
Now you can debug this code using #enter macro in the following way:
julia> #enter foo(20)
In foo(n) at REPL[9]:1
1 function foo(n)
>2 x = n+1
3 ((BigInt[1 1; 1 0])^x)[2,1]
4 end
About to run: (+)(20, 1)
1|debug>
Pressing n key will move the execution to the next line and all other standard debugging options are available - for the details see https://github.com/JuliaDebug/Debugger.jl
function foo(x)
n = 0
t = time()
while n < x
n += 1
end
sec = time() - t
println("done in $sec seconds $(x / sec) operations/sec")
end
foo(1e7)
I'm on Windows using Atom latest version of everything. I run the above code and it prints fine for 1e1,..., 1e7
But for foo(1e8) and above, it prints the line, and then the line DISAPPEARS. I'm completely baffled by that.
It only happens in Atom (VS Code works fine). I use control-enter on the foo(1e8) line to evaluate it and I can see it printing the line and then the line erases by itself. For foo(1e7) and below, it prints fine.
Here's the video of this with 1e8 then 1e7 and it happens on Linux too. As you can see from one of the attempts the video was able to capture the printing and erasing (see at 5 second mark in the video). When I changed to 1e7, it prints fine every single time.
everything is up-to-date: Julia 1.4.1, Atom 1.46, Juno 0.8.1 and I did a complete Julia package update as well.
github.com/JunoLab/Juno.jl/issues/560.
(credit to pfitzseb )
Just starting out with Python, so this is probably my mistake, but...
I'm trying out Python. I like to use it as a calculator, and I'm slowly working through some tutorials.
I ran into something weird today. I wanted to find out -1%4, and got this:
>>> -1%4
3
I checked it on c and c++ compiles as well, and 3 is the wrong answer! -1 % 4 is supposed to be 3.
Why is Python giving me a wrong answer?
In standard Pascal (ISO7185), there was no procedure Assign that would've let a programmer to assign some kind of file name to a file variable. It only appeared in Turbo Pascal and other derivates.
So... how am I supposed to open a handle to a specific file if I comply with the standard?
Closest I've found is this Irie Pascal example:
program vowels(f, output);
var
f : file of char;
tot, vow : integer;
c : char;
begin
reset(f);
tot := 0;
vow := 0;
while not eof(f) do
begin
read(f, c);
case c of
'a', 'e', 'i', 'o', 'u',
'A', 'E', 'I', 'O', 'U'
: vow := vow + 1;
otherwise
end;
tot := tot + 1;
end;
writeln('Total characters read = ', tot);
writeln('Vowels read = ', vow)
end.
which suggests I might be able to give the file name as a startup parameter. This works using Irie Pascal. However, if I try to use that with P5, which should be closest to standard-compiliant Pascal compiler for modern computers I've found, I get (after replacing 'otherwise') **** Error: external file unknown 'f '. So, what'd be the standard way? Or is this actually the standard way and P5 is doing something wrong?
Edit: standard also gives a sample
program copy (f, g);
var f,g : file of real;
begin
reset(f) ; rewrite(g);
while not eof(f) do
begin
g^ := f^ ; get(f) ; put(g)
end
end.
but I haven't been able to get that to work with any compiler.
Edit2:
Doing it like this:
program copy (f, g);
var f,g : file of char;
begin
reset(f) ; rewrite(g);
while not eof(f) do
begin
g^ := f^ ; get(f) ; put(g)
end
end.
works just fine in Irie and is compliant with the standard. Using that, file name can be given as a startup parameter.
However, as explained by Marco van de Voort,
ISO 7185 does not have any standard way for a program to specify
file names at all, so any such way is already beyond 7185 (Bind
is ISO 10206, Assign is UCSD/BP, the 2nd parameter to Reset is
an extension of GPC and I think some other compilers).
(source)
IIRC this was for VMS support where the OS bound files before starting the program.
Unbound files were automatically tempfile iirc. Search the GNU Pascal maillists (old archives, say 2005 or so), they had quite some discussions about ISO file implementation.
It was Scope on the CDC 6000 series machines. However, the rest is correct. You basically assigned external files to logical header file names in the Scope command language.
Of course this seems very tedious now, but these were the days of the batch mode computer, where everything was submitted as a "deck" of cards to be run as input, then collected as a series of output "cards". Tape reels got rid of the actual cards, but tapes were treated as a collection of cards on a tape.
In normal use, Wirth's original compilers were actually limited to just an input and an output file. If you wanted more than one input file, you concatenated them. This was easier than it sounds, since most input and output files were text, and every file had distinct end tolkens in it.
This paradigm fit well with the idea that you mounted an input tape and an output tape for a job on a batch system. The job of the batch computer was to linearly process the input tape and produce the output tape. A large and fast machine would have several jobs concatenated onto a single tape and run sequentially.
The option of a high speed printer typically rounded out the system. Thus, a college kid in the 1960s learning computer science would punch a deck on what looked like a typewriter (or get it typed by a keypunch operator), then that deck would be collected and transcribed to a tape deck and scheduled to run. An hour or more later, you were handed a section of greenbar from the printer that represented the output from your program.
Anyways, its always a good debate question as to why Wirth put that limitation in the language. Probabaly it was for the simple reason that the CDC 6000 machines could not have dealt with a feature that randomly opened a file by name. Also remember that the predecessor to Pascal, Algol, had no I/O statements whatever! They considered I/O to be inherently machine specific.
Scott Moore