I was wondering if there is a way to extract a procedure from another script without sourcing all of it.
The goal in this case is to not create a new file with the methods separated from the main script file, but to use the procs that are into that script.
I have use open, read and source and eval.
The implementation of source is almost exactly like open+read+eval (except with the C API). It isn't smart.
In general, getting the contents of a procedure can only be done by using info body after it has been created (plus info args and info default). But often people write code such that the word proc is in the first column of a line and the body is all indented, with first following non-indented line being the closing }. That won't work in all cases (the main trickiness is when namespace eval is in use) but will in many. Even then, the word proc is probably the first on its line (with indenting) and the close-brace is aligned with it.
I'm one of the few people that really writes code that doesn't always follow this convention. You don't need to worry about me.
Related
I have a huge VCD file that I use in combination with gtkwave to observe certain signal behaviors. I have a list of signals stored into a .txt file which are the ones that I wish to probe. The thing is that by doing the insertion of the signals manually by hand is a painstakingly long process. So my question here is,
Is there a way, given the .txt file to compose a .tcl script that filters and adds the designated signals from the list to the waveform editor?
Well, after scouting on manuals and some gists I found here and there seems that there is a load of gtkwave instructions one can use that are listed (most of them) on the gtkwave manual (Appendix E) here. So in a nutshell all one has to do is to write a .tcl script in the following format:
# add_waves.tcl
set sig_list [list sig_name_a, register_name\[32:0\], ... ] # note the escaping of the [,] brackets
gtkwave::addSignalsFromList $sig_list
and then invoke the gktwave as:
gtkwave VCD_file.vcd --script=add_waves.tcl
Furthermore, access to the GUI menu options are viable as well via the following syntax in tcl:
gtkwave::/Edit/<Option> <value>
In short: I am trying to load a csv file but the program always overwrites the existing file as an empty new file.
Longer: I am pretty new to Fortran, so bear with me. I am trying to read data from a csv file into a fortran program. Now I didn't write the program and it is pretty big, so I can't post the whole thing here. The program consists of a whole bunch of .f90 files and everything is compiled using a makefile. Now since I am loading the gcc module before compiling, I am assuming that it is compiled using GNU Fortran, because it is part of gcc. (idk how to find out if that is correct)
The compiler returns an executable in a different directory. When I execute the program in that directory it apparently overwrites the existing .csv file with a new blank one, so the program only reads "End of File". I don't know why it always creates a new file, how do I stop it from doing so?
As a side note, the csv file I am trying to read simply consists of a single column of floats, e.g.
"0.01, 0.13, 0.041,..." etc.
The code that I inserted into a subroutine of one of the .f90 files is the following:
real*8, dimension(nz) :: Nsq
integer :: i
open(10, file='Nsq.csv')
do i=1,20
read(10, *) Nsq(i)
enddo
close(10)
I have also tried to write a small test program, essentially running the same code as above. That one works just fine and outputs the contents of the csv file without any issues. For that one I use gfortran to compile it.
I have no experience in Fortran at all, so I am completely stumped, why this happens. I know the chances are slim that you guys can help me with this, since I can't provide the whole source code. But maybe someone has an idea why this occurs. Maybe you know an alternate way of reading csv files?
Thanks for your time.
The open-statement in Fortran OPEN(connect-spec-list), has a lot of connection specifications which define how an external file should be managed (see. Fortran 2018 Standard sec 12.5.6).
When you open a file using the simplest form of the open-statement:
OPEN(unit=unitid,file="filename")
A lot of default assumptions are made such as: ACCESS="SEQUENTIAL", ASYNCHRONOUS="NO", BLANK="NULL", .... The most important ones, however, are ACTION and STATUS which define the purpose of the file. The action specification states if you want to use the file for reading, writing or both, while the status essentially defines if we work on an existing file or not, and what we should do with it (replace it, keep it, ...)
Both these specifications have a default compiler dependent state.
In the Intel compiler suit, the default is action="readwrite", status="unknown" (see here and here)
Intel defines the status="unknown" as :Indicates the file may or may not exist. If the file does not exist, a new file is created and its status changes to 'OLD'.
The Gnu compiler suit has a different take on this. The default action is defined by a set of rules which depend on its accessibility if the file exists (+rw,+r-w,-r+w) (see here). The behaviour for the default action="unknown" is not documented but seems to be REWRITE (see Default Status of "Unknown" in Open)
It is advised to use a proper method if you know what you want to do with the file:
OPEN(newunit=unitid, file="filename", action="read", status="old")
When I create a class or a function file in octave. Is there a possibility to give the file a name that is different from the classes/functions name? (Class test is in the file test.m, but i would prefer to name the file for example test.class.m)
# test.m
classdef test
% ...
endclassdef
No. The way Octave is designed, classes and functions must be defined in files whose file names exactly match the class or function name. This is so that, given a function or class name, Octave knows where to locate its definition on disk, so it can lazily load in their definitions as they are needed by other source code, instead of having to load the entire source tree up front.
The exception is "command-line" functions, where you can define global functions inside a script, and their definition appears when the script is executed. This isn't a good way to organize code for larger projects, though, because you'd need to arrange for execution of all the scripts at the appropriate time, before those function definitions are needed.
If you want to distinguish classes from functions, you have the option of sticking them in subdirectories named #<class>, for example, #test/test.m.
I have a workflow Knime, in the middle I must execute an external program to create an Excel file.
Exists some node that allows me to achieve this? I don't need to put any input or output, only execute the program and wait to generate the Excel file (I require to use this Excel for the next nodes).
There are (at least) two “External Tool” nodes which allow running executables on the command line:
External Tool
External Tool (Labs)
In case that should not be enough, you can always go for a Java Snippet node. The java.lang.Runtime class should be your entry point.
It's could be used the External tool node. The node requires inputs and outputs... but, you can use a table creator node for input:
This create an empty table.
In the external tool node, you must include an Input file and Output file, depending on your request, this config could be meaningless but require to the Node works.
In this case, the external app creates a text with the result of the execution, so, in the initial table (Table creator node), will be read the file and get the information into Knime.
I'm, writing a Puppet (3.6.2) module that reads data fields from a CSV file via the extlookup function and I cannot figure out how to tell extlookup that the first line is the header field. Does extlookup support this? If not, can anyone recommend an external function I could import and use?
thanks,
PS - Yes I know about hiera, and having the data in YAML or JSON files but my requirement is CSV files only.
Brandon
The behavior of extlookup() is pretty well documented. It makes no special provision for column headers, which are by no means an inherent feature of CSV format. Indeed, if your header line is not readable as a data line, then your file is not CSV at all.
Supposing that your file is indeed valid CSV, the absolute simplest solution would be to ignore the issue. It presents a problem only if the first column heading duplicates an actual or potential data name. If it does not, then you will never look up or use the psuedo-value represented by the first row.
If your file in fact is not CSV on account of its first line, or if the first column name conflicts with a real data name, then it seems the next best alternative would be to just remove that line, or to avoid creating it in the first place. I don't see any reason why one of these should not be possible.
I know about heira, and having the data in YAML or JSON files but my requirement is CSV files only.
How sad. Do be aware that extlookup() has long been deprecated, and it was removed from Puppet 4.
I'm inclined to suggest you implement a translator from CSV to Hiera-friendly YAML, and use Hiera in your module. Alternatively, Hiera supports custom backends, and it's not too hard to write one. I am unaware of an existing CSV backend for Hiera, but you could write one. Ignoring a header line would then be under your control, and you would simultaneously achieve a measure of future-proofing.