Adam Ginsburg writes: > >> * Edited the perldl script to change the number of >> lines saved in history from 50 to 250 > > Is that the line "@a= @a[($#a-50)..($#a)] if $#a>50 ? > (line 239 of unedited perldl) > > If that's it, I think it would make sense to set a variable > that you can edit in .perldlrc for the number 50 there. > Is there any reason it's not that way already?
Short answer: yes, no one did it. Long answer: welcome to open source development. :-) The way things improve is that someone steps up and takes on the problem, makes the fix, tests it, and then propagates the fix into the code (cvs) for the next release. Since the source code is available to all, that someone could even be you... Actually, I have been working on some improvements to the perldl shell I would like to see in the next release: * better history control * session logs * completion Right now, they're accumulating in my working version (like the history flush described here) waiting until I have the time to integrate, test, and push to cvs. I hope to get to some of them this Summer which was why I was so interested in having a real bug report by Kare (a lot easier to fix things if you have bug reports to start from). >> ... >> where the flhist() command is just a cut and paste of the >> existing function in the perldl program which I've attached >> below. > > Did you paste the contents of flhist into the perldl script, > or put flhist.pdl in your PDL path? Does it matter? I used the PDL::AutoLoader and the attached file is in my PDLLIB search path. That is the way I can add to my current PDL/perldl and keep track of things for later integration into the cvs tree or for sharing... > Will it cause problems if I have 2 PDL terminals open > simultaneously? Will both record to the history file, > or will they overwrite each other? Yes, the flush to file just dumps the last 250 lines of history over the current file and there is no locking. My bash shells have the same problem. In practice, the flushing is every 10 user commands so it is unlikely that you would type the 10th command in at the same time in two perldl instances so the file locking would not be the issue. The history overwrite would be a problem. I would suggest two possible work arounds: (1) modify the flhist() to use a different file name for each perldl instance, or (2) use the same HIST file name but change the overwrite to append instead. This kind of thing is what falls under the "better history control" enhancements above. (Do you have any interest in contributing to PDL development? Many hands makes light work...) Good luck and happy pdl-ing, Chris
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
