Access to Library SubDirectories
pjv
Posts: 1,903
in Propeller 1
Hello;
I would like to keep library object files in a number of different Library Subdirectories. But I can't figure a way to get my spin programs to access any subdirectory. Only the root library directory seems to work. Is that "the way it is", or am I missing some technique. I'd be OK with somehow altering the library access link.
Also I note that I can't access the object even if I have opened it in the edit pane. I get a message stating something like "cannot find xyz in the edit bar, or work directory". Yet I believe there have been times that I COULD do that. What gives ?
Cheers,
Peter (pjv)
I would like to keep library object files in a number of different Library Subdirectories. But I can't figure a way to get my spin programs to access any subdirectory. Only the root library directory seems to work. Is that "the way it is", or am I missing some technique. I'd be OK with somehow altering the library access link.
Also I note that I can't access the object even if I have opened it in the edit pane. I get a message stating something like "cannot find xyz in the edit bar, or work directory". Yet I believe there have been times that I COULD do that. What gives ?
Cheers,
Peter (pjv)
Comments
No.
Sadly spin just allows one library folder and your actual working folder, both without sub directory support.
Mike
This path to object thing was discussed a lot of times here and as usual no agreement was found. Basically if a path in the OBJ reference is allowed it should be able to contain drive specification also and the Mac and Linux world rebelled. Relative path was rejected also. (not sure why).
I also think that having at least relative path support would help to organize the library folder a lot. But then all objects and demos have to be rewritten to adjust the OBJ name with his actual path in the new sub directory. So no example from the net works anymore and - hmm - the brilliant decision was made to basically leave it as it is.
I am not sure here but I sort of remember that you can supply multiple library path's to OpenSpin on the command line.
I personally think that even providing full path/filenames could be supported without messing things up. If you put something into GitHub or Obex you can fall back to a flat directory, but while developing I really miss having support for directories in OBJ names.
Enjoy!
Mike
It's not there yet, but if you want, you can start following the new subdirectory scheme, which will eventually be supported in OpenSpin and PropellerIDE. That doesn't help you right now, but at least you'll have less code to change to take advantage of this feature when it's introduced.
https://github.com/parallaxinc/spin-standard-library/wiki/Subdirectories
@Brett Weir, you are one of a kind, somehow.
I really like the way your dot notation works. Well done and platform independent.
In my opinion you are doing a very nice work with PropellerIDE. And I am sure the integration problems with OpenSpin mentioned in another thread will be solved. I really would like you to get PropBasic support in there too, PropBasic is in need for a IDE for a long time now. There where a lot of try's, @Hanno supported it in his product, there is (was?) a tweak for SimpleIDE. But Basically it is in need for some IDE.
And PropBasic is quite cool compiling to PASM and/or LMM. I really hope for a P2 version.
What I want to do today is to send you some encouragement, you are absolutely on the right way. The PropelllerIDE is looking and performing better every time I check it.
I really thank you for the work you have done and the work you will do in the future (I hope)...
Enjoy!
Mike
Regarding your subdirectory scheme: I would avoid using . as a separator, since it's also allowed in directory and file names, leading to possible ambiguities:
A colon : or double colon :: would be a better choice, since it's typically not permitted in file and directory names.
-Phil
I love the idea of pushing double colon on Spin. Then namespaces won't be foreign when folks discover C++
Thank you, @msrobots. Sometimes it feels as though I am building this platform in isolation, so it makes me very happy to hear that people are paying attention and want to see it go further.
PropBASIC support is actually not that far off. A great deal of work I've put into PropellerIDE has been towards making it language-neutral. There's actually already a language definition for PropBASIC, but it's not exposed to the user yet.
Here's the short list of things blocking PropBASIC support:
And that's all. It's really only a matter of time now.
Don't worry about me. I'll be sticking around for awhile. =P
Hi Phil. The details of how this ambiguity is avoided are provided in the document above. For added clarity, I just checked in a sample implementation showing how this approach behaves in action.
This is explained in the document I provided.
Oh, you evil man, haha. >.>
And I don't agree with your explanation. You shouldn't go out of your way to make bad practices impossible with restrictive and confusing features.
EDIT: I now see why . is a good idea - just by rearranging the files, you can feed a Spin file with . separators through Spin Tool. But I still don't see why you should disallow slashes. You could allow for both, and only consider dots if no slashes are found in the path.
No. The use of slashes implies a regular filesystem path, which this is not, and should not be.
Dot notation prevents escape from the library root path, making Spin projects inherently self-contained. This allows projects that use subdirectories to be archived in the classic, OBEX-friendly way, without modification.
I saw your explanation of "Directory Order." I'm sorry, but that's just wrong. Disambiguation should be made explicit in the syntax, not implicit in some obscure search-order scheme.
-Phil
There is nothing wrong with this approach.
Path order is a problem inherent in any language, regardless of how "explicit" the syntax is. Just look at our lord and savior, C, and all the problems it has. Who among us hasn't endured the nightmare of trying to set up include paths for all but the most trivial projects? In any case, this new directory scheme results in syntax that is nearly identical to Python, another language that has enjoyed great success for the past few decades despite its apparent "shortcomings". So what, again, is the big deal?
I also have to question the author of code that willfully introduces the ambiguity you are so concerned about:
Why would someone do this? As the saying goes, you can write FORTRAN in any language. If you were writing code that didn't take a sensible approach to resolving this fairly trivial issue, you probably wouldn't be experienced enough that you'd be worrying about how to build a structured Spin library where this would even become a problem. You'd really have to work hard to make this happen.
Every avenue has its own trade-offs, but this one plays to Spin's strengths and the current state of the Spin language. This strategy is the best possible solution; it prioritizes current project layouts over new ones so that the feature can be rolled out without impacting any existing projects.
So what is really the problem here?
You should be able to tell what a reference means just by looking at it, and you should not be able to change that meaning by doing something external to the program.
By contrast fee::fie::foe::fum and fee::fie::foe.fum are entirely unambiguous just by looking at them.
You and I might not do it, but we can't presume that someone else would not and even have a good reason for it. So I don't think it's right to punish them for it, as your notation would.
-Phil