I am using some of the subVIs that other people wrote so this is some historical issue.
The problem I have is that if two different subVIs are different, stored in different locations, but happens to have the same name.
It seems sometimes LabVIEW confuses the two of them and the link jump from one to the other, since the two subVIs are different, this makes errors.
So my question is: is this something real? That LabVIEW call subVIs by their filename rather than absolute filepath. Or am I describing something unreal and may be caused by other issues.
Thanks!
There are two separate things here. The first is that LV remembers where each file that something uses is placed, and there are three ways it can store that path (assuming I'm not forgetting any):
Logical. These are folders like vi.lib, where the base folder is represent by a name (so the path is stored as "|vilib|\...\myVI.vi"). This allows you to call the correct file when you go to a different LV version.
Relative. This is how LV normally saves paths, so if VI A calls VI B and they're in the same folder, the path to B inside A will be stored as "..\B.vi".
Absolute. I believe this is only reserved for VIs which are stored in a different volume, but do not match the first rule.
If for whatever reason LV doesn't find the file where it's supposed to be, it will take the one already in memory or try to search for it in other places, at which point you get a searching dialog.
The second thing is that there can only be one VI with a specific name in memory at any one time. If you load two VIs with the same name, you will get a conflict and have to resolve it, as you've seen. This isn't LV getting confused, just a matter of each calling VI referencing another VI with the same name and the order in which you load them. Technically, I suppose that LV could have used the full paths to allow duplicate names, but I believe that this decision goes back at least 20 years, so it won't be changed now, and it certainly would be a problem when you consider that now you can reference VIs in memory by name. It also has some other technical merits.
If you do have VIs which need to have the same name, what you will most likely want to do is namespace them. In the past, this was often done by actually changing the name using a prefix or a suffix. These days, you would usually do this by placing the VI in a library (such as .lvlib or .lvclass). This doesn't modify the file name, but it does become part of its fully qualified name, which is what determines collision, so it allows you to have multiple VIs with the same name. In the case of classes, this is actually a requirement, as that's the mechanism used to determine which VIs will override.
Related
I am adding some 2000 new objects to a DOORS module, I do this by importing a spread sheet with blank IDs, DOORS is supposed to create IDs for those blank rows.
Now the problem is, while i import spreadsheet, DOORS hangs, then when i Kill DOORS process, it anyhow creates IDs, next time when i add a new object, ID number starts from those which are already created but no exist. For some reason i need to continue from my last saved ID. Is there any way I can do this?
several remarks here:
works as designed. As soon as an object is created in any DOORS session, the new absolute number is centrally marked as "used". I think the main reason for this feature is the possibility to work in shared mode. If there were a different design, you would get into trouble as soon as two developers work on the module at the same time.
are you sure that DOORS really hangs? Perhaps it is just not yet finished, at least you can see that the objects are really created. Note that depending on how the script is written that you use for import, the number of imports per second might decrease significantly for bigger files
You should NEVER give any meaning to the absolute number other than uniqueness (perhaps QSS should have used timestamps or UUIDS instead of integers for their absolute numbers when they designed DOORS, this would make the situation clearer). You will have to rework “some reasons” . Perhaps you use a different mechanism to assign your own ID mechanism or you have to evaluate whether the requirement “generate consecutive numbers without gaps” is really necessary.
Does the name of a directory title 'the container' or the 'contents'? This question nags at me because if the name of a directory semantically titles 'the container' then the name should be singular. (By analogy: When referring to an actual physical bag that contains your groceries - one would probably refer to it as a 'grocery' bag and not the 'groceries' bag.) Conversely if one were to assert that the name of the directory titles the contents of the directory then it would make more sense to use a plural form.
I understand that there are common-sense and even usability concerns associated with this question; however, although I would like to hear the practical results of these two options I am more concerned with semantics.
So in summary: does the name of a directory serve as a title for the container or the contents?
Thanks.
A directory on its own needs no name as a directory without any content is useless. Directories exist to group a set of files together. Even if a directory is currently empty, it represents such a group, just that there are currently no files in this group and that's why it is empty. So the name of a directory should always describe what you can find within that directory.
Assume you have a drawer with boxes and you use these boxes to group physical objects together. To know what is inside each box without having to first open it and look inside, you label the boxes. How would you label these boxes?
If a box contains pencils, you'd label it Pencils and not Pencil, correct? If a box contains paper clips, you'd label it Paper Clips and not Paper Clip, wouldn't you? That's because in these cases the label only describes the kind of item to be found within the box. Same goes for directories. A directories containing pictures should most likely be named Pictures, so you know that the files you can find inside it are of type picture.
But sometimes you group items together, not because they are of the same kind but because they belong to the same "entity". E.g. if you have a large box that contains all items related to your trip to Japan in 2012, you would label it "Trip to Japan, 2012" or maybe just "Japan, 2012". Actually you could label it "Trip to Japan in 2012 Items" but "Items" is redundant, as it is obvious you will find items inside. The same way it is redundant to add "Files" to a directory name. So if you are not grouping files because the files itself have something in common but because they belong to a common "entity", you usually name the directory after that entity and since is only one such entity, it would be singular.
A directory with the pictures of Peter's Birthday would most likely be named Pictures/Peter's Birthday. On the other hand, if you keep pictures of every birthday of Peter, year after year, you would rather use a structure like Pictures/Peter's Birthdays/2016. Note how it suddenly became "Birthdays" as now the directory name again describes the kind of items found inside and not an individual event/purpose.
As a general rule of the thumb: Always name directories in such a way that the reader of the directory name has a very good idea of what kind of files and other directories they can expect to find inside that directory, so they can decide whether it's interesting to "go there" or not by just having read the directory name.
If you name a directory Recipe, what will the reader expect to find inside? I would expect to find one or more files, all belonging to a single recipe, e.g. a short ingredient list, a longer instruction text and maybe some supporting photos. Contrary, if you name the directory Recipes, what will the reader expect to find there? I would expect several recipes, either multiple files and every file contains one recipe or multiple sub-directories and each one contains the files that belong to one recipe. As you can clearly see by this simple example, whether you choose plural or not has an effect on the expectation of the reader.
My first impulse is to say that you name a generic container based on its contents. But I'll dig a little deeper just for the fun of it. (Scroll to the end if you just want the summarised conclusion.)
Firstly, I don't think Tum's car and cake examples help us very much. Sure, they are made from simpler components, but only for the purpose of creating new and self-contained objects. The grocery bag is a collection of molecules—so what. The more meaningful thing to ask is: is the object's fundamental purpose to hold other objects? In other words, is it a generic container, like the folder in a file system? You would definitely answer no to the cake. You would probably answer no to the car (even though it does, admittedly, hold people). You would certainly answer yes to the grocery bag.
In your grocery bag example, you said we would refer to it as a grocery bag and not the groceries bag. Sure. The following sentences are all grammatically correct and natural sounding:
Would you help me bring the bags in?
Would you help me bring the grocery bags in?
Would you help me bring the groceries in?
Would you help me bring the shopping in?’
The first sentence is only meaningful if the listener knows we just went shopping and can infer the contents of said bags without us telling them. Without that information, the bags might, for all we know, contain venomous snakes. The second sentence is the most descriptive, but includes redundant information. Anyone familiar with groceries and the process of buying them can reasonably infer that they will be contained in bags. The third sentence tells us all we need to know in the most succinct manner.
The forth sentence takes a different approach entirely, labelling the singular activity that produced the groceries. But it doesn't tell us what kind of product we shopped for, so it’s not as descriptive. (Sometimes this approach is the best option as will be seen in other examples.)
If you look at the user's home folder on any new Windows PC or Mac, you'll find it pre-populated with folders like Documents, Downloads, and Pictures. A folder labelled 'Pictures' tells us all we need to know. You could choose to suffix all your directory names with 'dir', 'folder' or something similarly redundant, but it adds nothing meaningful. (I'm old enough to remember seeing Mac users of yesteryear add the 'ƒ' character—generated by pressing Option-F—to the end of folder names. Crazy times.)
Ah, but there are exceptions! On my Mac, Apple (in its infinite wisdom, of course) chose singular names for three subfolders: Desktop, Library and Public. The rationale, one suspects, is that no one knows what the Desktop contains—not even the user oftentimes! Similarly, the Public folder might contain anything. To get all scholarly, we would call it a heterogeneous collection. It’s like that big box of stuff you pull out at Christmas time, which contains a hotchpotch of stuff like tinsel, baubles, stockings, wrapping paper and fake snow—easier to just label it ‘Christmas’, according to its purpose and theme.
The Library folder is an interesting one—not so much because Apple didn't name it according to its contents, but because it gives us an interesting real-world example. Is the purpose of a library to hold other objects, or is it a functional object in its own right? I'd say it's somewhere in the middle. Let’s say we decide to label a real-world library based on contents. We could call it ‘Books’. (Most libraries contain more than books, but to keep it simple we'll imagine that our library only contains books.) A library could hang a big sign out front that just said 'Books'—but then you might assume the books were for sale, rather than free to borrow. You'd probably assume this because you live in a capitalist society where most big signs are trying to peddle something. So the question of semantics is also one of context.
There's one more question of context that you didn't supply in your question. Where are these directories stored? Are they on your personal computer, or are they on a web server? Why does it matter? Well, on your PC, you're probably viewing each folder in a GUI, where the label is attached to an individual icon. But if the directories are part of a website structure, it's more likely that users will only ever see the names as part of a file path (if they notice them at all). The question here is, do you care, and if so, do you want the file path to read like a sentence? This is best illustrated by an example:
http://acme.com/order/explosive/detonator/dx3000
While each category could be plural, the path reads more like an English sentence by using singular directory names. While this seems a bit forced perhaps, you do see this approach on some websites.
TL;DR: When the function or theme of a container is more descriptive than its contents, a singular label (e.g. Library, Desktop, Christmas) can work best. The more heterogeneous a collection, the more likely this approach will make sense. But in most cases, labelling the plural contents (e.g. Documents, Downloads, Pictures) of the collection is easier and more descriptive.
Interesting question.
If you look at a class as a substitute for a tag name (something you would do when using a <div> or a <span>, which have no semantic meaning), your class would have to describe the contents of the element.
But at the same time, the element it self is the content. If you look at a car you say 'this is a car', you don't say 'these are car parts'. Or, if you eat a cake you call it 'cake' and not 'ingredients'.
So I guess a semantic class name would be singular and not plural, because it is always only one element. This might result in using a lot of 'wrapper' in your class names, because finding a fitting name for your element is not always that easy.
I hope this answers your question, if not you might want to read this: http://css-tricks.com/semantic-class-names/
The convention proposed by user Mecki is coherent, but I wonder whether it is really useful in the context of file organization.
In my experience, a very useful convention is to see file path components as a collection of searchable tags. This aids in classifying and finding files, which, for me is the main purpose of establishing a convention for directory and file names.
For example, one file could be named camera-MODEL-manual.pdf (where MODEL is the concrete model). There could be also a directory that contains various manuals. Or perhaps there are multiple manuals for a particular device. In that case, they could be kept in manual/DEVICE/.... Naming directories that contain manuals with the tag "manual" in singular helps searches for manuals.
Within this convention, one can search for file paths containing "birthday" and "peter" without having to remember whether the directory is "2022-birthday-peter" or "birthday/peter/2022". Or one can search for all PDF files whose path contains "car" to find some car-related document.
While in English most plural forms are simply created by adding an "s" suffix, so that a search for "birthday" may bring up "birthdays", this is not true in many other languages. And even in English, it may be preferable to search for whole words, such that a search for "birth" does not bring up "brithday".
In the sample installation and configuration instructions, it is seemingly suggested that OpenGrok requires two staging areas, with the rationale being, that one area is an index-regeneration-work-area, and the other is a production area, and they are rotated with every index regen.
Is that really necessary? Can I only have one area instead of two?
I'm looking for an answer that is specific to opengrok, and not a general list of race conditions one might encounter.
Strictly said, this is not necessary. In fact, I am pretty sure overwhelming majority of the deployments are without staging area.
That said, you need to decide if you are comfortable with a window of inconsistency that could result in some failed/imprecise searches. Let's assume that the source was updated (e.g. via git pull in case of Git) and the indexer has not finished processing the new changes yet. Thus, the index still contains the data reflecting the old state of the source. Let's say the changes applied to the source removed a file. Now if someone initiates a search that matches the contents of the removed file, the search result will probably end with an error. This is probably the better alternative - consider the case when more subtle change is done to a file such as removal/addition of couple of lines of code. In that case the symbol definitions will be off so the search results will bring you to the wrong line of code. Or, not so subtle change, when e.g. a function definition is removed from a file, the search results for references of this function will contain invalid places.
The length of the inconsistency window stems from the indexing time that is largely dependent on 2 things, at least currently:
size of the changes applied to the source
size of the source directory tree
The first is relevant because of history processing. The more incoming history changes (e.g. changesets in Git), the more work the indexer will have to do to generate history cache and/or history fields for the index (assuming history handling is on).
The second is relevant because the indexer traverses the whole source directory tree to find out which files have changed which might incur lots syscalls and potentially lots of I/O. At least until https://github.com/oracle/opengrok/issues/3077 is implemented and that will help only Source Code Management systems based on changesets.
What is the purpose of GUIDs in COM?
Is it only to avoid name conflicts?
It serves the exact same purpose as a name. A COM client can ask the system to create a COM object using a simple identifier (CoCreateInstance). That identifier has the scope of the full machine. Different chunks of code written by programmers that don't know each other and work for different companies live at that scope.
The problem with names is that people suck at picking good names. The odds that one programmer picks the exact same name as another programmer, 3000 miles away and 5 years ago are high. Names like "Record", "Database" etc would be popular choices. Evident at this website too, lot's of users named "Jason" or "Mike". They don't mind, they know their own name when they review their profile. Context. Impossible for me to find them back though when they send me an email with just their user name, following up on a question with a generic subject string.
Getting a name collision and COM creating the wrong object is disastrous. The program stops working because it is getting a completely wrong object. Finding out why is difficult, the error message sucks. Actually fixing the problem is impossible. Calling programmer B and ask him in the friendliest possible way to "pick a different name, somebody already picked yours" doesn't work. Automatic response is "call programmer A instead".
This is not a problem when you use a GUID instead of a name. They are Globally Unique IDs. The odds of getting a collision are astronomically small.
Probably, as it would guarantee a globally unique identifier for each object.
As the name suggests, it's an identifier and serves the same purpose as any other identifier. As you mentioned, avoiding name conflicts is one use. Another advantage is that it is only 128 bits long (as compared to a name which could be arbitrarily long) so comparing two GUIDs is much faster than comparing their corresponding names.
As it name suggests, GUID is a globally unique identifier. Which means that if one developer generates two GUIDs he gets two different GUIDs and if two developers who don't even know about each other generate one GUID each - either at the same moment or at different moments - they again get two different GUIDs.
Now consider a problem - any developer needs an ability to introduce new interfaces and classes and make them uniquely identifiable. That's because if you get an interface pointer and your program treats it as some InterfaceA* but it really is not an InterfaceA* you've got a major problem - your program runs into undefined behavior - crashes or produces unexpected results.
The above problem is easily solved with GUIDs. Every developer creates a new (and thus unique) GUID value for every new interface or class he introduces. This is reliable and convenient (except that GUIDs are not that human-readable).
Files and directories could have different namespaces, and still be used to identify specific files, because a file and directory with the same name can be distinguished by being different kinds of things.
Primitive field and reference fields could also have different namespaces (in Java), because if a primitive and a reference field had the same name, they could be identified by being different kinds of things.
Separate namespaces are used elsewhere like this. For example, in Java, you can have a method exampleName() and a field exampleName, and though they have the same name, they are distinguished by being different kinds of things.
First, this question is language specific. In pure OOP languages there's no distinction between atomic and compound elements. Everything is an object. By a similar reason in a pure functional language you can't have function and variable named the same.
Second, if you have polymorphic operations, there's no way to tell which variable did you refer to. For example, you can't have different namespaces for files and directories, because of the polymorphic operations, like
cp foo bar
The cp works on files and dirs, and if you have different namespaces, there's no way to tell what did you mean.
I do not believe that this would be a good idea. I imagine that the reasons involve things like performance and simplicity of the filesystem code. If a directory listing had to go down 2 or 3 or more different paths depending on how many different namespaces you think you should have, this would probably complicate the code.
Additionally, consider the end user confusion that might arise. Currently we have a kind of namespacing available in filesystems by using file extensions. You can have file.txt and file.dll and file.exe all existant in the same directory. What happens when these files are present simultaneously is a matter of concern - this has been one method for virus writers to use a form of social engineering to get you to click on the wrong file. Imagine if you could confuse a directory with a file of the same name as well?
Directories and files aren't necessarily so different. They are both entries in their parent directory, just with a flag to indicate if an entry is a directory or not. You can open a directory and read it just as if it was a file, just that certain other operations are possible on it- symbolic links work the same way. (This description is biased towards the Unix filesystem view, but I think the DOS/Windows view works much the same way). Within any directory, there is a set of names of members, and the filesystem enforces the uniqueness constraint that a directory can only have one member with a given name.
Thinking about Java method names compared to field names--- back in C, you couldn't have a global function and global variable with the same name, because all the symbols in the object file are in a single namespace. But you could with C++, because a function "void foo()" was mapped to mangled symbol name ("foo__vv" or something). So it's not so much that they have a separate namespace, as that the key into the namespace is different for a field "foo" vs a method "foo()". Given that you can't get key clashes, they look like separate namespaces, but is that really how it's implemented?