Is there a way that I can single step through part (or all) of a Perl 6 program? I expected that there would be a -d, but of course there is not:
% perl6 -d test.p6
I thought perhaps eval-ing the file, but that does the whole thing at once:
% perl 6
> EVALFILE 'test.p6'
As I expected, that just runs the entire file.
I suspect someone hasn't implemented this sort of thing. Is there some way I can hook into the runtime to insert actions between statements and so on? In Perl 5 land, that would be the DB class.
Aside from that, does Perl 6 work with any general debuggers? If I were using the JVM backend, would it even make sense to use a Java tool (or is it gibberish by that point)?
I started working on this problem as one of the features of LREP. I haven't worked on it for a while, so not sure how well it still works. Since the last time I worked on LREP, we've done a lot of cleanup on the internal REPL–I hope to modify LREP to work more cleanly and add in debugger features.
Related
The following code works flawlessly in Linux, but when I put it on a Windows machine, all hell breaks loose:
$pid = open2($my_reader, $my_writer, "$JAVACALL $PARSER_CP $PARSER_CMD -");
$my_reader->autoflush(1);
$my_writer->autoflush(1);
print $my_writer "$line\n";
close($my_writer);
my $tree = <$my_reader>;
chomp($tree);
push #parse_trees, $tree;
close($my_reader);
waitpid($pid, 0);
In Windows, it just hangs waiting on waitpid($pid, 0). If we comment that line out, everything finishes properly, but then we're left with numerous orphaned processes. What confuses me is that ActiveState (who's Perl we are using) actually says to do things exactly how we're doing them.
Does anyone know a Windows-happy way to do this? Even if I have to maintain two separate versions of the code, I could care less at this point. :)
(For those curious, this code opens the Stanford Parser, which takes a file as input (hence the use of "-" (similar to/same as /dev/stdin in Linux)), throws a sentence at it, and gets back a parse tree. Not important but I know someone is going to ask. :) )
Well, for those who are curious, I got things working the way they should, but I'm not too crazy about part of the fix. I added
use POSIX ":sys_wait_h";
and changed that waitpid() call to
waitpid($pid, &WNOHANG);
This alone didn't do it, so immediately after this I added
kill(-9, ($pid));
to kill the process. Not really liking the call to kill() but it works, and oddly enough I still had zombie processes if I didn't also call waitpid(). Again, it'd be great if anyone knows a more elegant solution, but this will have to do for now. :)
Background
I am writing an R package to support reproducible research. At this point, the workflow is mostly held together by bash scripts, and I can run an analysis by sending a single command like ./runscript.sh. I use bash for the following:
file manipulation tar, rsync, 'rename'
running bash files locally and via ssh
running R scripts using R --vanilla that in turn call R functions
find and replace text within files using sed
submitting jobs via qsub
It seems to me that it would be much more efficient (cleaner and easier) to execute the entire workflow from an R function or R script. I am partial to R since I am more familiar with it and mostly work within emacs ESS.
Questions
Would it be worthwhile to encapsulate all of these uses of bash within R using the system and files functions?
Are there other R packages that I have not yet found that would be helpful for doing this?
Notes
Following Al3xa's answer, I realize that it is important to note that the speed penalty of using eg. R vs bash versions of tar and gsub on 1000-2000 files would likely be less than the current rate limiting steps in the workflow: computations by JAGS (~10-20min) and FORTRAN (>4hrs)
I'm a big fan of using R as your "integrated" environment vs. bash scripts. I'm in the process of moving all of my bash and ruby scripts to Rscript as I need to make changes to them.
There are only a couple of reasons not to move everything into R that come to mind. I'm referring mainly to using Rscript to accomplish this
1) Speed, which from my testing is a moderate impact in any situation I've come across, and would be trivial relative to the times you mentioned.
2) Portability, in that paths to Rscript, etc. may be different across systems. I've had no problems writing things on OS X and moving them to a Linux server, but might break on Windows.
The advantages in my book are:
1) Much easier for me to write. I don't have to switch back and forth between the slight idiosyncrasies with things like conditional statements and for loops.
2) More forgiving. I can't describe how much time I've spent trying to get bash scripts to work because I accidentally had a space where I shouldn't have. R is much nicer in that regard (yes, of course, we should all follow conventions in R perfectly, but I'd rather that it not stall me up for hours if I don't).
3) I do better work. For tar a file it doesn't matter, but I find I do better text manipulation in R vs. awk/sed for example.
Re: packages that are helpful -- This doesn't exist, to my knowledge, but I'd love a version of make that's based on R. make's syntax is one of the most inflexible out there (tabs vs spaces? really?) - I'd love to write an R-based alternative. Some day, I will...
Well, there are functions like tar, gsub etc. Anyway, I guess you're willing to create a crossplatform solution. You should prefer bash for the sake of speed, and use R only for R-specific functions. I don't find it useful to wrap all system-based commands within system and/or file.*... it would be much slower... If you're using Linux, I suggest littler over Rscript interface.
I'm developing a ruby app with Vim in one screen, and in another I'm using irb to test the code I'm writing in Vim.
For the sake of this example, we'll say there are only 2 irb commands to test the code that I've written, a load and a method call.
Generally, it's more than 2 commands - if its just 2 I would tap the up arrow twice and hit enter, but generally its around 5 or 6 and that's up to 36 key presses just to run the last 6 commands. There must be an easier way.
Is there an easy way to execute the last X commands from the irb readline history buffer in the order they were executed, where X is the number of commands you want to run? Something like;
run_last_x_commands(i)
I'm pretty sure it would be a custom written piece of code, I'm just wondering if anyone already solved this problem or if this is something I'll need to write myself.
You may be interested in running Vim in IRB.
Gem.
Source.
I would really store your test script in a file. It is less convenient than just typing it out, but at the same time, it's easier to edit and work with. Plus, if you're trying to define classes, you often get issues with IRB not able to redefine a class without doing things like Object.remove_const('MyClass'). I've had the same problem you're having, and I decided against using IRB for this task.
There may be some readline magic to do what you want though. Readline has all kinds of tricks and shortcuts I don't know about.
I have a Perl script that runs via a system() command from C. On a specific site (SunOS 5.10), when that script is run, it nearly always takes 6 seconds or more. On other sites, it runs pretty much instantly (0.1s). If I run the script manually, i.e. not from the C code, it also runs instantly. I eventually tracked the slowness down (by spitting out the time a whole bunch in a lot of different places), to a single require line. The file that it is requiring is another Perl script we wrote. The script consists of a single require (this file here), 3 scalars that are assigned integer values, and a handful of time/date conversion routines. The file ends with a 1;. That single require appears to take as much as 6 seconds on occasion, but as I said, not always even on the same machine. I'm absolutely stumped here. My only last thought is to turn on profiling, but the site doesn't have Devel::Profiler and my only other option (that I know of) would be to add it to the Perl command which would require me altering and recompiling the C code (doable but non-trivial).
Anybody have ANY idea what could be going on here? I don't think I can/want to put the entire date.pl that is being required, but it's pretty much exactly as I described; I could answer any questions about it that you have.
Thanks in advance.
You might be interested in A Timely Start by Jean-Louis Leroy. He had a similar problem and tracked it down to a long and deep module search path where perl usually found the modules in the last entries in #INC.
Six seconds is a long time. Have you checked what your network is doing during this?
My first thought was that spawning the new process when using the system() command could be the problem, but six seconds is too long.
I don't know much about perl, but I could imagine that for any reason, the access of the time module could invoke a call to a network time server. Just to get synchronized. Maybe this takes so long or maybe it is getting a time out.
It could be that this only happens for a newly spawned process -- hence only when you use the system() command.
just wild guessing...
So, this does nothing to answer your question directly, but please tell me that you're not actually running on perl 4? Assuming you're on perl 5, you could remove the entire file and replace the require with use POSIX qw(ctime) to get the version that comes with Perl.
If you do have to support perl4, I'll merely grumble something about version 5 being fifteen years old now and go away. :)
I sweated over the question above. The answer I'm going to supply took me a while to piece together, but it still seems hopelessly primitive and hacky compared to what one could do were completion to be redesigned to be less staticky. I'm almost afraid to ask if there's some good reason that completion logic seems to be completely divorced from the program it's completing for.
I wrote a command line library (can be seen in scala trunk) which lets you flip a switch to have a "--bash" option. If you run
./program --bash
It calculates the completion file, writes it out to a tempfile, and echoes
. /path/to/temp/file
to the console. The result is that you can use backticks like so:
`./program --bash`
and you will have completion for "program" in the current shell since it will source the tempfile.
For a concrete example: check out scala trunk and run test/partest.