Propeller Tool - Why is \ an invalid character when specifying an OBJ name

Chuck Rice

Every time Parallax updates the Propeller tool, my compiles start failing. The problem is that I have added objects to the propeller library and they do not get copied forward. I do this because it is the only way to have common objects that I can share between all my projects. I just installed 1.2 and I am scurrying around rebuilding all my project just so I can find all missing objects.

Based on the principle of least astonishment, I thought that I could put a folder in my propeller library called MYLIB and another one called OBEX, and I would put all my non-parallax objects in these libs. Then I could specify the object as:

OBJ
    terminal      : "OBEX\PC_Text"
    globals        : "MYLIB\globals"

but alas, it astonished me again. it tells me that "\" is an invalid character. Couldn't you make the "\" work?

Just a suggestion.

Fred Hawkins

2cents from the Cheap Seats said...

OBJ
    [b]using        : "C:\filepath\OBEX"[/b]
    terminal      : "PC_Text"
 
    [b]using        : "C:\filepath\MYLIB"[/b]
    globals        : "globals"
    morestuff      : "another_file_in_Mylib"

I suggest this syntax. And filepath is just a placeholder·for the entire path specification.

BradC

I suffer from this also. My "solution" is a it different though. I've got all my stuff on a Samba server, so I just symlink the files where they are needed using the underlying *nix filesystem. When the compiler is updated a simple...

cd $compiler_dir
for i in /home/brad/spinlibs/*.spin ; do ln -s $i . ; done

and I'm away again.

It would be *really* nice to have an additional configurable directory or better still, a search path.. but alas..

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!

allanlane5

The propeller IDE doesn't support a "search path"? That's a pretty basic feature for organizing code into "libraries".

hippy

Lack of being able to specify drive and path in the object filename has been raised before. At present object files have to be placed in the working directory or the default PropTool library directory.

Just adding another path to search would be a good start but I cannot see any reason the full path could not be specified in the object filename descriptor string.

Jeff Martin

This issue is one we plan on solving in the next release.· We will be adding a library search path feature that allows you to specify multiple paths for the "logical" library, searched in order.· That's a registry setting, so it will be carried over from version to version as new versions are installed on the system.

It is very intentional to not support file paths in file strings (like OBJ block and FILE directive) because it would ultimately result in many broken projects when moved to another machine, especially when the Archive feature is used for distributing objects (like on the object exchange).· Keeping the path out of the "hard-coded" source code, and adding a multi-path library feature would best solve this in both cases; normal compiling would still work, the paths would be carried over from version to version on the same machine, and archived projects would continue to function properly, regardless of the myriad of paths that the original files could have been pulled from.

I'm sorry we have not implemented this already, but it should be included soon.



Take care,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin

· Sr. Software Engineer
· Parallax, Inc.

Phil Pilgrim (PhiPi)

Jeff,

I agree wholeheartedly that absolute path specifications must be kept out of the OBJ strings. User-defined paths will be a most welcome addition, alleviating the necessity for specifying them in the source code.

But what this still doesn't fix is not having libraries organized by topics, subtopics, etc. My development library is a mess: one directory with a bunch of Spin files. What we need is what Chuck asked for at the head of this thread: relative paths in the OBJ strings. This would allow libraries to be organized hierarchically into topics like "Math", "Sensors", "Signals", etc. — rather like the ObEx is organized. This is not a non-portable feature, either, since the location of each main library would still be given by the path. And when an archive is unpacked, this hierarchy can still be maintained by creating and populating the requisite subdirectories.

It may be tempting to think that this could be accomplished with the path specs alone, i.e. "c:\spin\mylib", "c:\spin\mylib\math", "c:\spin\mylib\math\trig", "c:\spin\mylib\sensors". But it should be obvious how awkward this would quickly become.

As to notation, please just say "no" to the backslash. A forward slash or double colon "::" (a la Perl) would be preferable and more OS-agnostic. At least we could pretend we weren't using Windows.

Thanks,
Phil

Paul Sr.

Phil Pilgrim (PhiPi) said...


As to notation, please just say "no" to the backslash. A forward slash or double colon "::" (a la Perl) would be preferable and more OS-agnostic. At least we could pretend we weren't using Windows.

But we ARE using Windows and that is the convention. To switch to a non-Windows convention would be counter intuitive.

Phil Pilgrim (PhiPi)

Paul Sr. said...
But we ARE using Windows and that is the convention. To switch to a non-Windows convention would be counter intuitive.

The point is to divorce the language notation from anything OS-specific. This makes the notation portable from an OS standpoint. In the source code, you want to think "libraries" and "sub-libraries", not "directories" and "subdirectories", even though that might be the way they're organized in the OS. Using an OS-neutral notation like the double colon reinforces this necessary distinction. Besides, even though the Propeller IDE is Windows-only now doesn't mean it always will be, so it's best to keep OS-specific notation out of the language syntax.

-Phil

Paul Sr.

Phil Pilgrim (PhiPi) said...

Paul Sr. said...
But we ARE using Windows and that is the convention. To switch to a non-Windows convention would be counter intuitive.

The point is to divorce the language notation from anything OS-specific. This makes the notation portable from an OS standpoint. In the source code, you want to think "libraries" and "sub-libraries", not "directories" and "subdirectories", even though that might be the way they're organized in the OS. Using an OS-neutral notation like the double colon reinforces this necessary distinction. Besides, even though the Propeller IDE is Windows-only now doesn't mean it always will be, so it's best to keep OS-specific notation out of the language syntax.

-Phil

Well, Phil, for the first time EVER, I just can't get on board with you on this one!

However, every one IS entitled and the truth is, we'll all do whatever the thing needs us to do!

hippy

One could always use back-slash and forward-slash to mean one and the same ( most browsers I've used will accept either ) so that covers Windows and Linux relative paths and if users of other OS's can live with that convention in a browser they'll cope in the PropTool.

Double-colon and similar is just non-intuitive, but if anyone wants to support double-colon as another synonym for filename separator then that's fine by me - My principle is don't force any single standard, accept as many standards as is possible, then everyone's happy no matter what direction they're coming from.

Phil Pilgrim (PhiPi)

Well, in any event, the actual notation used is much less important than just being able to denote sublibraries in the OBJ strings. At this point, I would be happy with any notation that enabled hierarchical library organization.

-Phil

Paul Sr.

I agree.