Mike,
I think there is a typo in:
· “path: A sequence of elements that identify the location of a file
within a filesystem. The elements are the root-nameopt, root-directoryopt, and
an optional sequence of filenames.”
The last word should probably be “directory names”.
Regarding absolute/relative and ambiguous/unambiguous, I think these definitions
are lacking some important detail. Drive letter/name and machine name. I could
have an identical directory tree on two different drives, C:\ and D:\ with two
identical file names in the same directory on the two drives, yet the two files
may have different content. Providing an “absolute path” will only be
unambiguous
if we include the drive letter. This can be further extended to two different
computers either in the same room, or half way around the world, in which case
we might need to consider a URL (network) notation in addition to the drive
letter.
So, how much of that is included in the “absolute path”? I don’t see that in
the
definitions you provided/suggested. How far do we want or need to go along
these
lines?
This discussion reminds me to the ground cleanup effort and voltage reference
discussion we had. The only difference here is that instead of voltage, we are
talking about file names. Location with respect to what (directory, drive,
computer, WWW network URL, etc…)? Fun stuff, huh?
Thanks,
Arpad
=====================================================================================
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Mike LaBonte
Sent: Thursday, April 27, 2017 11:01 AM
To: bob@xxxxxxxxxxxxxxxxx; michael.mirmak@xxxxxxxxx; Muranyi, Arpad
<Arpad_Muranyi@xxxxxxxxxx>
Cc: ibis-editorial@xxxxxxxxxxxxx; IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-editorial] Re: File name concepts as used in IBIS 6.1
Revisiting this, I think Michael pursues a good <pun>path</pun> in seeking
other standards to follow. The boost.org naming system has indeed been adopted
by C++<http://en.cppreference.com/w/cpp/filesystem/path>, which defines a “file
name” as having no directory path. I find 42 instances of “file name” and 2 of
“File name” in IBIS 6.1, and most of these are used in reference to a file name
with no directory path components. Maybe we should keep it that way; they are
already consistent with the standard definition.
If we are to add definitions, a reduced and simplified set of the boost.org
definitions might be a good basis. Here is a slight reduction of their own
definitions:
· file: An object that can be written to, or read from, or both.
· filename: The name of a file.
· file system: A collection of files and certain of their attributes.
· path: A sequence of elements that identify the location of a file
within a filesystem. The elements are the root-nameopt, root-directoryopt, and
an optional sequence of filenames.
· absolute path: A path that unambiguously identifies the location of a
file without reference to an additional starting location.
· relative path: A path that is not absolute, and so only unambiguously
identifies the location of a file when resolved relative to an implied starting
location.
· pathname: A character string that represents the name of a path.
Some notes:
1. They use “filename” and “pathname” with no spaces. Not sure how much that
matters.
2. They use the term “absolute path”, which is what DLL_Path uses.
3. We might not need to define “file system”.
4. These definitions are for programming, which is why they define
“filename” and “pathname” independently of “file” and “path”. We could reduce
this.
5. Their definitions did not include “stem” and “extension”, although these
are described in the methods.
Considering all of the above we might have something like these simplified
definitions:
* file name: The name of a file without its location.
* stem: The portion of a file name before the last dot, or the full file
name if no dot.
* extension: The portion of a file name after the last dot, if any.
* path: A sequence of directory elements and file name that identify the
location of a file.
* absolute path: A path that unambiguously identifies the location of a
file without reference to an additional starting location.
* relative path: A path that is not absolute, and so only unambiguously
identifies the location of a file when resolved relative to an implied starting
location.
Those definitions should be sufficient to handle all of the places where we
state character rules about file names. In most places, the term “file name”
would not need to change. They should also be sufficient for the places where
we describe what types of file references are allowed.
Mike
From:
ibis-editorial-bounce@xxxxxxxxxxxxx<mailto:ibis-editorial-bounce@xxxxxxxxxxxxx>
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Monday, April 24, 2017 12:57 PM
To: michael.mirmak@xxxxxxxxx<mailto:michael.mirmak@xxxxxxxxx>; 'Muranyi, Arpad'
<Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>;
mlabonte@xxxxxxxxxx<mailto:mlabonte@xxxxxxxxxx>
Cc: ibis-editorial@xxxxxxxxxxxxx<mailto:ibis-editorial@xxxxxxxxxxxxx>;
'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-editorial] Re: File name concepts as used in IBIS 6.1
All,
Good information.
Do other specifications or languages have these definitions or similar
definitions?
Also, we allow a Filename to have a Stem only. Eg., S4p by itself is legal.
Also we define extension as the text following the last “.”, and not including
the “.”. However, we have been inconsistent here from IBIS V2.0 or below.
Bob
From:
ibis-editorial-bounce@xxxxxxxxxxxxx<mailto:ibis-editorial-bounce@xxxxxxxxxxxxx>
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Monday, April 24, 2017 9:37 AM
To: Muranyi, Arpad; mlabonte@xxxxxxxxxx<mailto:mlabonte@xxxxxxxxxx>
Cc: ibis-editorial@xxxxxxxxxxxxx<mailto:ibis-editorial@xxxxxxxxxxxxx>; IBIS-ATM
(ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>)
Subject: [ibis-editorial] Re: File name concepts as used in IBIS 6.1
Mike, thanks for the Python analysis; Arpad, thanks for the links!
The online discussion mentioned the “boost.org” system, which is being applied
specifically to C++. While we should also consider VHDL and Verilog (and
variants), as IBIS supports them, IBIS-AMI with C++ is used fairly often, so
using a C++-friendly approach makes sense.
From the Boost naming convention
(http://www.boost.org/doc/libs/1_64_0/libs/filesystem/doc/reference.html#path-decomposition)
and the stackoverflow discussion:
Part Windows Posix
------------------------------------------------
Root name c: <empty>
Root directory \ /
Root path c:\ /
Relative path foo\bar\baa.txt foo/bar/baa.txt
Parent path c:\foo\bar /foo/bar
Filename baa.txt baa.txt
Stem baa baa
Extension .txt .txt
Path c:\foo\bar\baa.txt /foo/bar/baa/txt
In this nomenclature, our “basename” becomes “stem”, “file extension” becomes
“extension”, and “file name” and variants become “filename”. Relatively few
changes would be required in the existing IBIS text, but an introductory
paragraph would be needed to explain the notation above and provide suitable
references. We could also easily note that other languages and systems (making
explicit note of Python as an example) may assign the same terms to different
concepts.
Will this work?
- MM
From: Muranyi, Arpad [mailto:Arpad_Muranyi@xxxxxxxxxx]
Sent: Monday, April 24, 2017 9:16 AM
To: mlabonte@xxxxxxxxxx<mailto:mlabonte@xxxxxxxxxx>; Mirmak, Michael
<michael.mirmak@xxxxxxxxx<mailto:michael.mirmak@xxxxxxxxx>>
Cc: ibis-editorial@xxxxxxxxxxxxx<mailto:ibis-editorial@xxxxxxxxxxxxx>; IBIS-ATM
(ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>)
<ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: RE: File name concepts as used in IBIS 6.1
Just to add another twist to this conversation, in the HTML world, they
call this a URL. A URL can practically be anything, but in the end, it
is a reference to a file, whether it is local or somewhere in the big
wide world. Look at what they call the various components of a URL here:
https://www.w3schools.com/html/html_urlencode.asp
Can we learn something from this?
By the way, we don’t seem to be the only ones wrestling with this:
http://stackoverflow.com/questions/2235173/file-name-path-name-base-name-naming-standard-for-pieces-of-a-path
Thanks,
Arpad
==========================================================================
From:
ibis-editorial-bounce@xxxxxxxxxxxxx<mailto:ibis-editorial-bounce@xxxxxxxxxxxxx>
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Mike LaBonte
Sent: Friday, April 21, 2017 8:33 PM
To: Michael Mirmak <michael.mirmak@xxxxxxxxx<mailto:michael.mirmak@xxxxxxxxx>>
Cc: ibis-editorial@xxxxxxxxxxxxx<mailto:ibis-editorial@xxxxxxxxxxxxx>; IBIS-ATM
(ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>)
<ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Subject: [ibis-editorial] Re: File name concepts as used in IBIS 6.1
Looking outside of IBIS for a moment, the Perl
File::Basename<http://perldoc.perl.org/File/Basename.html> functions are:
($name,$path,$suffix) = fileparse($fullname,@suffixlist);
$basename = basename($fullname,@suffixlist);
$dirname = dirname($fullname);
In their terminology, if $fullname = 'a/b/c.d' and @suffixlist = ('.d') then:
$name = c
$path = a/b/
$suffix = .d
$basename = c.d
$dirname = a/b
So their idea of basename is what we in some places call file name. Note that
the use of DLL_ID as a basename is a slightly different concept. If DLL_ID is
serdes_16544 then a DLL might write files serdes_16544_cdrout.csv and
serdes_16544_dfeout.csv. I wonder if the term "file name fragment" might work
better there?
I think we need to decide what we will call each entity:
a/b/c.d file path? (not distinguishing between full and relative paths)
a/b directory path?
c.d file name?
c file base name?
d file extension?
Michael's effort to find the dominant current practice to determine a minimal
change that results in a consistent policy is worthwhile. My suggestions above
would not necessarily minimize the change. But Michael seems to have found that
"file name" is currently used for both "c.d" and "c", so it seems to me some
changes are warranted somewhere in the spec, no matter what we choose.
Mike
________________________________
From: "Michael Mirmak"
<michael.mirmak@xxxxxxxxx<mailto:michael.mirmak@xxxxxxxxx>>
To: "ibis-editorial@xxxxxxxxxxxxx<mailto:ibis-editorial@xxxxxxxxxxxxx>"
<ibis-editorial@xxxxxxxxxxxxx<mailto:ibis-editorial@xxxxxxxxxxxxx>>, "IBIS-ATM
(ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>)"
<ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Sent: Friday, April 21, 2017 7:19:15 PM
Subject: [ibis-editorial] File name concepts as used in IBIS 6.1
Today’s discussion of BIRD189.2 focused on the concept of “file name” (and
variants on the term), and whether it refers to a string that includes an
extension, whether it is simply the pre-extension string, or whether it
includes path information. As noted by Bob Ross, the BIRD189.2 language is
closely modeled on .pkg and .ebd language in the IBIS document.
I conducted a brief set of searches through the IBIS 6.1 specification,
including on the phrases or words “base name”, “basename”, “file name” and
“filename”. My general findings are shown below, with quotations where
appropriate. All page numbers refer to the Adobe PDF* version of the file.
In brief, I believe Bob and Arpad were correct in their statements during the
meeting, and that there is a long-standing inconsistency in how we refer to
files in even pre-3.2 IBIS. In particular, the usage on pages 9 conflict with
the usage on 140 and 154. The latter two use “filename”, when “basename” would
be more consistent with usage elsewhere.
Fortunately, I believe we can very quickly make the document completely
consistent by using the phrase “base name” for the non-extension portion of the
string, and “file name” for the full string, appropriately and distinctly
defined, without forcing model or tool changes. Current BIRDs could be made
consistent with these definitions very easily.
Comments are welcome.
- MM
basename
--------
p. 9 – In the “GENERAL SYNTAX RULES AND GUIDELINES” section, “basename” may be
up to 40 characters in length, followed by a period and an
up-to-three-character extension
base name
--------
p. 213 - "The algorithmic model is responsible for using DLL_ID as the base
name for any data files that the model creates..."
filename
--------
p. 140 - regarding .pkg, “filename” refers to base file name without extension
p. 154 - regarding .ebd, “filename” refers to base file name without extension
file name
--------
p. 9 – “basename” is 40 characters, followed by a period and an
up-to-three-character "file name extension" (so here, file name is equivalent
to basename)
p. 18 - for [File Name], "the file name must use the extension '.ibs', '.pkg'
or '.ebd'. The file name must be the actual name of the file."
p. 100ff - for [External Model], “file name” implies extension is included, but
the phrase "file name extension" is used several times
p. 120ff - for [External Circuit], “file name” implies extension is included,
but the phrase "file name extension" is used several times
p. 221 - for Supporting_Files, "file name" is explicitly described in contrast
to directory names and paths
