I have problem with setting start module and function in "Run configuration"
I'm doing it that way:
"Run -> Run Configuration" and in "start" section I'm setting
Module: mod,
Function: hello
my code:
-module(mod).
-export([hello/0]).
hello()-> io:format("42").
Now, when I hit "Run" I would like mod:hello() to be execute automatically, but it doesn't work.
What am I doing wrong?
The code does get executed...
When you hit "Run", mod:hello() does get executed. The thing is, the execution of mod:hello() is meant for system initialization, like loading library code and initializing looping states. The side effect of mod:hello(), which is the string "42" as stdout will not be reflected in your Eclipse console. To prove my point, we can create some more explicit and more persistent side effects, like creating a file in the file system called output_file.txt. Change mod.erl to something like this:
-module(mod).
-export([hello/0]).
hello() ->
os:cmd("touch output_file.txt").
Hit "Run", and you will find a output_file.txt file being created under your workspace directory. This is an evidence for the execution of mod:hello().
To achieve what you want...
In an Unix shell:
$ erlc mod.erl
$ erl -noshell -s mod hello -s init stop
42
Depending on what you want to execute, there is an alternative to the answer above: the "live expressions". There is a view with this name in the same place as the console, where you can enter an expression and enable it for evaluation every time a module is recompiled.
This works nicely for expression that aren't heavy to evaluate and that are without side effects, can be used as a form of alternative to having a test suite.
Related
I've recently started using fish, and I needed to use a jar file for google's bundletool.
As such, I needed to set up an alias/function for bundletool, and I chose a function since it seems more "fishy".
My function is simple:
function bundletool
java -jar bundletool-all-1.12.1.jar $argv
end
The bundletool jar itself lives at ~/.local/bin, which is on my fish user path:
lase#laser-razer /m/c/U/matth [1]> echo $fish_user_paths
/home/lase/.local/bin /usr/local/go/bin /home/lase/.nvm /home/lase/.cargo/bin /home/lase/.cargo
In a regular shell, I can execute java -jar bundletool-all-1.12.1.jar, and the command runs as expected. However, in the function, fish doesn't seem to know about my fish_user_paths, and reports it cannot find the jar file.
To remedy this, I had to update my function to specify the full path:
function bundletool
java -jar ~/.local/bin/bundletool-all-1.12.1.jar $argv
end
This works, but I feel like I'm doing something incorrectly. Should I be setting up my paths or functions in a different fashion?
Your function will run in the ordinary environment.
It will run with the current $PATH [0] and, more importantly to you, the current working directory.
What happens is this:
java -jar bundletool-all-1.12.1.jar
Will tell java to run the jar found at bundletool-all-1.12.1.jar.
Notably, fish just hands java the string "bundletool-all-1.12.1.jar", and java will then not look at $PATH. It does not care about $PATH. It simply looks at "bundletool-all-1.12.1.jar", and tries to open a file by that name.
And it will find that file, if it is in the current directory.
And that's the reason this worked for you when you executed it interactively - because you happened to be in that directory
And then you tried it with the function, but you tried it from a different directory, and so it didn't work.
This works, but I feel like I'm doing something incorrectly. Should I be setting up my paths or functions in a different fashion?
No, giving the full path to the file instead of relying on the working directory is the right thing to do.
[0]: $fish_user_paths is just a variable you set, that fish will then take care to add to $PATH. $PATH is the actual variable that fish and other tools (including any command fish starts, if it wants to) will use to find commands.
NOTE
I've had to remove like two chunks of this post because stack overflow kept interpreting it as code when it isn't and it wouldn't let me post, I'll just make a screenshot of what the post is supposed to look like and post it here. Read this instead.
Summary
I was finally trying to learn how to use VSCode tasks and so I copied the first task example from here and created a shell script at scripts/test.sh which contains simply "echo foo". I also commented out the windows alternative script because I exclusively use WSL/Bash. Whenever I run the task I receive a "The terminal process terminated with exit code: 1" error message, which is no help whatsoever.
Testing
I ran various tests and I have no idea why this isn't working.
Proving The Task Is In The Correct Directory & In WSL
First I thought maybe the task isn't running in WSL or that the directories are out of sync, so I changed the commands to see what happens.
First, I changed it to:
"command": "pwd",
and the output was "/mnt/f/.../.../tmp/tmp.1BitOIA78E" (... are for some arbitrary path) so clearly I concluded I was running on WSL and in the right path.
Proving the Script is Executeable
Next I thought, maybe the script I'm trying to run isn't executable or something to that affect, so I changed the command to:
"command": "stat ./scripts/test.sh",
and I got the following output which shows, the file exists, it's executeable & can be accessed through "./scripts/test.sh" from whatever directory the Task is set to on construction
I run the task by typing ctrl-shift-P to open the menu, select "run tasks" and then select 'My First Task'.
Note: I don't think this is a settings problem. There're no workspace settings setup (because this is just me testing) & just in case, you can find my current user settings here which I updated immediately before posting this.
Expectations
What I'd like is either:
Someone to tell me how I can access the stderr and stdout log of the shell upon startup so I can get some actually helpful information as to why this is happening.
Someone to tell me why I can run a script perfectly fine outside of a task, but within a task it completely fails.
Whats also of note is that the script isn't the problem here. Leaving it completely blank, doesn't stop the terminal from straight up crashing.
Not sure if I am explaining this well, but here goes...
I have a perl script/flow that runs various steps. Each step is basically dependent on the output of its previous step in order to run.
For example:
myflow -step1...input is file0, produces file1
myflow -step2...input is file1, produces file2
myflow -stepN...input is fileN-1, produces fileN
Right now users can run myflow -step1 -step2...-stepN to go from start to finish. I would like to somehow have the ability for the user to run myflow -stepN, have myflow check to see which steps need to be run prior to it, and then run stepN. Maybe no steps were run, so myflow -stepN would start from step1 and continue until it finishes stepN or an error occurs. Maybe step1 through step3 ran fine previously, so running -stepN would start from step4. Maybe all steps ran fine, but the user modified/deleted/touched an intermediate file, so running -stepN would detect this and rerun from that previous step.
Is there a cpan module that essentially mimics this make behavior, i.e. given steps, inputs they require, and outputs they produce, create a dependency graph and determine which steps need to be run?
I'm thinking you could use make itself instead of trying to simulate it.
The makefile rules for "building" each fileX "target" from the fileX-1 "source file" would be invoking your script for the respective step.
I'm running into problems testing a new addition to a module. (Specifically - the ~ operator seems to be not working in Math::Complex for this new feature only.) It's too bizarre to be what it appears but the ideal scheme would be to add the -d option on the top line of the .t program.
Well, I was quickly disabused of that idea! It does not invoke the debugger.
If I wanted to use the debugger, I'd need to create an edit of the .t program that:
Uses (the use command) the module directly. not in the form of
BEGIN { use_ok('My::Module') };
Does not "use Test::More;"
A few other edits that cause gluteal pains
The problem with doing that is that any changes I make in the edited test program I still need to transfer back to the true test program use in "make test". Error prone as best.
I am already using "make test TEST_VERBOSE=1" so that my stdio output shows up. But there's GOT to be a simpler way to invoke the debugger on the .t
Thanks for ideas here.
-- JS
use_ok tests are great, but you should have them in test files of their own, not test files that also test other things.
I'm not sure why you would need to avoid Test::More or use_ok to run the debugger, though. What does happen when you try your test directly:
perl -d -Mblib t/yourtestfile.t?
If all else fails, you can try using Enbugger in your test script.
I'm trying to set an environment variable in a build script with phing.
This is normally done command line like this:
export MY_VAR=value
In Phing I did the following but it isn't working.
<exec command="export MY_VAR=value" />
I see that this is quite an old question, but I don't think it has been answered in the best way. If you wish to export a shell variable, for example say you are running phpunit from phing and want to do an export before invoking phpunit, try:
<exec command="export MY_VAR=value ; /path/to/phpunit" />
Simply do the export and invoke your command inside the same exec tag. Separate the export statement and the shell executable with a semicolon as shown. Your script will be able to access the value using the standard php function:
$myVar = getenv('MY_VAR');
Bold claim: There is no way to set/export a (Unix) shell variable in PHP so that it is visible inside the scope that started the php script.
php myfile.php (does putenv or shell_exec('export foo=bar');)
echo $foo
Will return nothing.
As PHP can not do it so neither can phing.
Accessing shell environment variables accross multiple script runs (if its that what you want) seems also like an unideal design decision, pretty stateful.
Apart from that I'd urge you to stick to phing and learn its lean lesson. Phing helps stateless thinking to some degree.
I'd never heard of phing before, but this looks very promising as a build tool. Thanks for posting! I looked through the doc on phing.info, I found the following possibility:
#0 I would like to clarify one point. Are you saying that
prompt$ > export MY_VAR=value
prompt$ > phing build.xml
doesn't set MY_VAR to value so it is visible inside the running phing processes? I'd be surprised, but I would understand if this is not how you want to run your build script.
#1 I think in the context of a build tool, a feature like exec is meant to run a stand-alone program, so, while the exec may run and set MY_VAR, this is all happening in a subprocess that disappears immediately as the exec finishes and continues processing the next task in the build.xml.
If you're just trying to ensure that your phing script runs with specific values for env_vars, you could try
Command-line arguments:
....
-D<property>=<value>
// Set the property to the specified value to be used in the buildfile
So presumably, you can do
phing -DMY_VAR=value build.xml
#2 did you consider using a properites file?
See http://www.phing.info/docs/guide/stable/chapters/appendixes/AppendixF-FileFormats.html
and scroll down for info on build.properties
#3 also ...
Phing Built-In Properties
Property Contents
env.* Environment variables, extracted from $_SERVER.
you would access them with something like
${env.MY_VAR}
#4 This looks closer to what you really want
<replacetokens>
<token key="BC_PATH" value="${top.builddir}/"/>
<token key="BC_PATH_USER" value="${top.builddir}/testsite/user/${lang}/"/>
</replacetokens>
I hope this helps.