Language Change Specification for Current File

Voting Results: Cast your votes here

Yes:

1. Jim Lewis - 21-Mar-2017 ver 6
2. Steve Grout - 2017-03-06 Ver 3
3. Rob Gaddi - 2017-03-21 ver 6
4. Patrick Lehmann - 2017-03-21 ver 6
5. Lars Asplund - 2017-03-23 ver 6

No:

Abstain:

Revision Notes

Revision 6 21-Mar-2017

• Per Patrick comment changed LINE to STRING in text for FILE_LINE.

Revision 5 18-Mar-2017

• Per meeting 16-Mar. Path does not end with a directory separator

Revision 4 10-Mar-2017

• Changed path to fully resolved absolute path

Revision 3 6-Mar-2017

• Changed function names so they are all of the format FILE_*
• FILE_NAME returns only the file name - no path
• FILE_PATH returns only the absolute file path
• FILE_LINE returns the current line number of the file.

Revision 2 21-Feb-2017

• impure
• Added overloading for string and positive
• Added simple name and absolute path variations of file name

Revision 1 Initial 19-Feb-2017

Style Notes

Changes are shown in red font. Deletions are crossed out. Editing notes in green font.

Comments

I think attributes are a better way. They can be optimised to static strings line SIMPLE_NANE.

-- Patrick Lehmann - 2017-02-20

TBP #1: Shouldn't CURRENT_LINE rather return POSITIVE or NATURAL? The choice of one of these types would also document whether line counting is zero- or one-based.

TBP #2: As the proposed functions return values dependent on the context rather than just the immediate function parameters, I would suggest to declare them impure.

-- Thomas Preusser - 2017-02-20

Agree on both TBP comments. I definitely think CURRENT_LINE should be POSITIVE; every text editor I've ever used and ever error report I've ever read considers the first line of the file to be 1.

Also, CURRENT_FILE should be more specific about paths. Is it absolute or relative, and if the latter relative to what? If I can suggest an answer to that, I'd point out that FILE_OPEN is currently equally ambiguous about such things, to the serious detriment of usability (see discussions of "file logical name" in 6.4.2.5) Ideally we'd pin all that down, but at least for this revision we could just add to std.env:

impure function CURRENT_DIR return LINE

And have relative file paths always be relative to whatever directory name would be returned if the function was called.

-- Rob Gaddi - 2017-02-21

LCS 006c adds DIR_WORKINGDIR which returns the current working directory as a STRING. But this doesn't help with source file names which are mostly not relative to whatever. I suggest fully resolved absolute paths.

-- Patrick Lehmann - 2017-02-21

@TBP #1: What do you intend to do with line number? I intend to print it. It would be easiest if it were string. @TBP #2: Yep. Thanks.

@RG Which CURRENT_DIR do you want, the one where there CURRENT_FILE is located or the one the simulator is currently running out of?

?Do we want these to be LINE or STRING? If I were to assign it to something or were going to process it, I think LINE would be best, but here I suspect we are going to print it, so maybe STRING is best. OTOH, we should be able to overload it.

If we return string, then it would be as static as an attribute

-- Jim Lewis - 2017-02-21

Ideally, if CURRENT_DIR were "/home/rgaddi/ftl_travel", my source file /home/rgaddi/ftl_travel/src/warp_drive.vhd would report CURRENT_FILE of "src/warp_drive.vhd". And if I were to call FILE_OPEN("sim/data/vectors.csv") we would be discussing the "/home/rgaddi/ftl_travel/sim/data/vectors.csv"

Whereas if it thought my CURRENT_DIR was "/home/rgaddi/ftl_travel/sim", then CURRENT_FILE should be "../src/warp_drive.vhd".

It would be fantastic to say "If I zip up this entire project and move it to a different location (or even different machine) and run the simulator again from the same relative path in the project tree, I'll get the same results for calls to CURRENT_FILE" Not sure if it's a feasible thing to say, but it'd be a nice one.

-- Rob Gaddi - 2017-02-21

I do no think this separation into FILE_NAME_SIMPLE and FILE_NAME_ABSOLUTE is desirable. This operation of turning a path into a canonical representation is appearing in several LCSs, which all add it onto their actual key functionality. To name another LCS, also DIR_OPEN of LCS 006c canonizes the directory path kind of as a side effect in addition to returning a directory listing. I think it would be wiser to provide one function PATH_CANONIZE(path : STRING) returns LINE, e.g. as part of LCS 006c, that takes care of this operation once and for all.

With LCS 018, transforming an INTEGER into a STRING only takes an expression like i'image. I think with so little bother, the version of LINE_NUMBER returning a STRING directly is not really needed.

-- Thomas Preusser - 2017-02-21

Version 3

Simplified and refactored the funcitons. FILE_NAME now only returns the file name without any path information. Added FILE_PATH which returns the absolute path of the file. Changed LINE_NUMBER to FILE_LINE so we have one consistent naming style for these.

We need FILE_PATH as tools do not always stay in the directory in which you start them. I need FILE_PATH in testbenches so I can locate the results files in a directory relative to where the source files are - if this existed today, I would be using it in the OSVVM regression suite.

@RG and @TP Per your comments, I have removed the extra FILE_NAME and added FILE_PATH (as I need that one). It is assumed that some other LCS (such as the directory one) can deal with converting an absolute file path to a relative file path if that is desirable.

@TP: My only use model for the line number is to print it. For that, I need it as a string. What is your use model for needing positive? I suspect that printing is the primary use model. Hence if we need to remove one, we should remove the one that returns positive and use integer'value(s) to convert the string to a value. I left them both in as I suspect you do not want to do that and there is no reason not to provide the overloading.

For some applications, it seems like we may want to provide these same functions for the parent of the current file: FILE_PARENT_NAME, FILE_PARENT_PATH, FILE_PARENT_LINE. Thoughts?

-- Jim Lewis - 2017-03-06

Please specify the "absolute path" as "fully resolved absolute path". This excludes ambiguities if paths contain symlinks or other nice file system features.

Please describe each sub program in one paragraph per function and overload.

Why don't we remove the function returning a string? integer'image(l) is as good as integer'value(s), except for one reason: The tool internally saves the line number as an integer and not as a string. But I'm fine having two overloads here!

What is a parent?

-- Patrick Lehmann - 2017-03-07

Version 4

@PL1: done @PL2: done - nasty twiki thought. I now really dislike "%RED%" @PL3: The use model needs string to simplify printing (report and open source packages). Do you have a use case for integer? Are you going to do math on the FILE_LINE value? I think the minimum overloading needs to support the predominant use case. I am fine with both, but require string.

-- Jim Lewis - 2017-03-11

I don't want to do math on line number, but I dislike that an integer is converted to a string by VHDL and a user converts it back to an integer, so he can store the value e.g. in a record. Please note your string has variable size (line "10" vs. "1648") whereas an integer is fixed in space.

There is a mismatch in the return type for function FILE_LINE in the text. String vs. Line.

-- Patrick Lehmann - 2017-03-14