Is the following a sensible use of define-runtime-path so that when the code is in an executable, the user-path will be appropriate when run on a machine where the user-path is different:
(require racket/runtime-path)
;(define-runtime-path runtime-path ".") ;I am replacing "." with expr below:
(define-runtime-path runtime-path (path->string (build-path (expand-user-path) (string->path ".plt-scheme/4.2.1/collects"))))
(file->string (build-path runtime-path "email-rules.csv"))
No, I don't think that's a sensible use. Apologies if I'm misunderstanding the example.
The runtime-path mechanism is designed for situations where the given file is in a known location relative to the source (code) file.
Is your source file in a known location relative to the source (code) file? If not, maybe it could be?
The more I read, I get the feeling that maybe don has a big folder of custom files and maybe code, within this collects folder. To me it seems as if maybe the concepts of collections and packages is missing here.
Maybe you want to create a new local package copy the email rules file into it and use (define-runtime-path email-rules "email-rules.csv") to refer to it. If these rules need to be bundled with other code, create a local package there and bundle it with that code.
As said before don't throw fragments of code at us, describe your goal first.
Hi John,
Thanks for your feedback! I appreciate the clarity by saying my attempt at using define-runtime-path was not sensible.
Is the following correct?
The define-runtime-path function requires that Racket/DrRacket be run from a constant location so that the constructed path is relative to the current directory which should be a constant.
No, if you use define-runtime-path with a relative path, that path is relative to the racket module in which define-runtime-path is used, independent of the current working directory.
Right! As Simon implies, the current-directory is irrelevant when using runtime-path. Perhaps the confusion arises from the name; the word "runtime" suggests that it might be relative to the current directory, and that's not the case at all.
Also, I'd like to echo Simon's proposal: can you tell us what it is you're trying to accomplish, and how the files are laid out?
Hi Simonis,
I have not been creating collections and packages, although I certainly make use of them.
I believe my current line of enquiry is more fundamental - the use of relative paths instead of absolute paths.
I think it is a bit premature for me to be creating a package of my code although I do believe it is appropriate after I have
put relative paths into effect.
I am now working on developing an understanding of how to use relative paths.
Thanks for your feedback.
Regarding the request for me to state my goal:
Stating my goal is less the issue than giving you some context - I think.
And although it may be frustrating to be on the receiving end of questions with little context and maybe no apparent goal, I find that when I make questions as specific as I can, I get the replies that I am looking for.
I consider the replies to have been excellent and of great help to me!
To give some context and state a goal that I am working toward...
I have been using absolute references to data files.
Relative paths need to be in effect for the executable app to function on machines with different user paths.
General description of my file sets:
a) I have a set of language functions (created from Racket fns) in one collects path.
b) and an app created by those functions in another path.
Regarding my language file set:
This set of files should probably be moved. One respondent pointed out that I have effectively placed
my code in a collects path that should be thought of as reserved for racket code only.
I don't disagree because anytime I update the version of Racket that I am using, the new version comes with a new default collects directory and I must take steps to ensure the original collects path can still be found.
To summarize:
Step 1: Learn to use relative paths.
Step 2: Move my language files to a new path.
(I suspect the best method is move my language files then create a pkg and have my app refer to the new pkg.)
Personally I prefer to have questions connected to the goal, because it makes it easier for the reader to follow along and also provide answers or tips, that may not be obvious. Sometimes there are things that can be approached from many different directions, some of those might be connected to the goal, but not immediately to a particular function or feature.
Also some features can be used in many ways and it can be hard to imagine, without that context, thank you for providing it.
I am not sure I understand everything about your setup, so I will leave that up to you, unless you have particular questions. Also with discourse I don't mind having a topic that is connected to a goal, with multiple questions in it, because that shows to other readers a sort of "natural evolution" of the problem,
rather than lots of disconnected queries for information that are hard to "stitch together".
Especially with discourse it is possible to link to posts in a topic, or quote parts of answers, so I think it is easier to take a part things into small knowledge bits after the fact, then go the other way around.
But this may be my personal style of using discourse.
I definitively encourage you to use locally defined packages, I remember that packages seemed to much work (but that was more an expectation I had from other languages) when I started with racket. Overall I find using your own local packages is one of the things that is way easier than I have encounter in other languages and from my experience it just makes everything easier.
1 Getting Started with Packages
For example I have my projects in a folder that is separate from the collects paths and if I want to use one of those projects with a new racket installation, I just execute raco pkg install in my project folder, it then asks me whether I want to install missing dependencies (that I have defined in it's "info.rkt").
Handling application specific data, is probably to varied to say something about it in general.
I'm curious, why did you decide to put your code in a collects path? (I'm asking sincerely, not sarcastically.)
Hi Jack,
Thanks for your interest.
And may I say that I that I am most honoured to hear from you. You are famous - as far as I am concerned as I am well aware and very appreciative of software you have created and made available.
A couple of short answers to your question "why did you decide to put your code in a collects path" are:
a) I knew of no other method at the time I started with pltscheme, later Racket.
b) I believe the use of 'packages' came later.
I could say a lot more on the subject but I don't want to write a book in response. I invite you to a telephone conversation on this topic and any other topics of interest to you.
Call me anytime by telephone (voice only) at 403-239-5270 Canada.)
Thanks
Don
Oops.
Mistakenly thought that responding through my email program meant I was sending a one-to-one email.
At any rate...
I am actually a fan, not only of Jack Firth but everyone who is programming with Racket and the like.
I am happy to receive telephone calls from anyone working with Racket however there is one guideline: that the intent is for a mutually enjoyable conversation between 2 people with the common interest of working with program languages - probably mostly Racket.
Call anytime by telephone (voice only) at 403-239-5270.
It's good that you think that, but I (and, I think, most of the other people on the list) disagree. Stating the goal is the best way to give context. If you state the goal then we can ask questions to clarify points that we need. If you instead hide the goal and only provide the context that you think is relevant then you will almost certainly give irrelevant details and not give relevant ones. Being blunt: If you knew enough to give only the relevant context then you wouldn't be asking the question.
If you realize that you are frustrating the people that you want to help you, and that not frustrating them would be zero extra effort on your part, why are you choosing to be frustrating?
Simon spoke to this already, but let me say it in a more blunt fashion: If you continue doing things the way you have been, you may get the replies you are looking for, but you will not get the replies you need. I cannot count the times when I've had this conversation:
Me: Hey, I'm writing a function to do XYZ, here's my code, and I need a <foo>. Any ideas?
The list: <pointer to a builtin function that does XYZ>
Please. When you have a question, simply tell us what you're trying to do. We'll ask if we need more context.
EDIT: Forgot to use \< instead of only <, since things in angle brackets don't render because HTML.