-
Notifications
You must be signed in to change notification settings - Fork 732
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Process.schelp: fix outdated incorrect explanation for thisProcess.nowExecutingPath
with examples
#6291
base: develop
Are you sure you want to change the base?
Process.schelp: fix outdated incorrect explanation for thisProcess.nowExecutingPath
with examples
#6291
Conversation
thisProcess.nowExecutingPath
correct the explanation
The PDF of Process help document in this PR |
HelpSource/Classes/Process.schelp
Outdated
@@ -24,7 +24,9 @@ Returns the full path to the file containing the code that is currently executin | |||
|
|||
teletype::nowExecutingPath:: is valid only for interactive code, i.e., code files with a teletype::.scd:: extension. It does not apply to class definitions (teletype::.sc::). For that, use code::thisMethod.filenameSymbol:: or code::this.class.filenameSymbol::. | |||
|
|||
This method is supported in the SuperCollider IDE, the macOS-only SuperCollider.app, and the scel (SuperCollider-Emacs-Lisp) environment. In other editor environments, it will return code::nil::. | |||
This method is supported in the SuperCollider IDE, the scel (SuperCollider-Emacs-Lisp) environment and the command-line interface (CLI). In other editor environments, it will return code::nil::. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In other editor environments, it will return code::nil::.
I have only tested it with
- SC-IDE on MacOS, Windows and Ubuntu
- Terminal on MacOS and Ubuntu
- Command Prompt on Windows
So I do not know if it is true or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one edition is already an enhancement since the "macOS-only SuperCollider.app" doesn't exist anymore.
Nothing changed in scel, but I can double check later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nowExecutingPath does work on SCNvim on Mac!
...how about if we write: "This method is supported in the SuperCollider IDE, SCNvim, scel, and the command-line interface (CLI). In unsupported editor environments, it will return code::nil::."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cdbzb Thanks for the suggestion!
After the following thread,
The following IDE's support this feature: Visual Studio Code, VSCodium and Neovim.
I am not sure, but Neovim seems to be the same as SCNvim.... Am I right?
Combining these with your idea results in:
"This method is supported in the SuperCollider IDE, SCNvim, scel, Neovim, Visual Studio Code, VSCodium, and the command line interface (CLI). In unsupported editor environments it will return code::nil::".
How about that? It is just a suggestion to reflect my little poll on the scsynth forum.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion:
The method is supported in various environments, including the SuperCollider IDE, Neovim (SCNvim), Emacs (scel), VSCode/VSCodium, and the command line interface (CLI). In unsupported editors, it will return code::nil::.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@smoge
Thanks, I will use your suggestion!
The method is supported in various environments, including the SuperCollider IDE, Neovim (SCNvim), Emacs (scel), VSCode/VSCodium, and the command line interface (CLI). In unsupported editors, it will return code::nil::.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you switched the filenames at the end maybe? I will write a test code, just a minute.
HelpSource/Classes/Process.schelp
Outdated
table:: | ||
## | ||
|
||
If a code block ("fileMain.scd" in the example code below) executes another file on disk ("fileForLoad.scd" in the example code below), using link::Classes/String#-load:: or link::Classes/String#-loadPaths::, teletype::thisProcess.nowExecutingPath:: will be the location of the executed file ("fileForLoad.scd" in the example code below). However, if the function is called in the executed file ("fileForLoad.scd" in the example code below), teletype::thisProcess.nowExecutingPath:: will be the document of the code block ("fileMain.scd" in the example code below). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused - if a function containing thisProcess.nowExecutingPath
is called, thisProcess.nowExecutingPath
will return the path of the document containing the function call, right? You are defining the function in fileForLoad but calling it in fileMain... or am I musinderstanding?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe deserves a less confusing rewrite. Writing like @cdbzb comment "path of the document containing the function call" is already more clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cdbzb @smoge
Thanks and sorry! You both are correct. My writing is wrong.
What I wanted to write was:
However, if the function stored in the executed file ("fileForLoad.scd" in the example code below) is called in another file ("fileMain.scd" in the example code below),
thisProcess.nowExecutingPath
will be the document of the code block ("fileMain.scd" in the example code below).
(I seem to have left some words out while writing)
@smoge. Yes, @cdbzb's sentence is very clear! Thanks!
How about the following?
If a code ("fileMain.scd" in the example code below) executes another file on disk ("fileForLoad.scd" in the example code below) using
String: -load
orString: -loadPaths
,thisProcess.nowExecutingPath
will be the location of the executed file ("fileForLoad.scd" in the example code below). If a function containingthisProcess.nowExecutingPath
is called (the function defined in "fileForLoad.scd" in the example code below),thisProcess.nowExecutingPath
will return the path of the document containing the function call ("fileMain.scd" in the example code below).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what you are describing?
// Main.scd
thisProcess.nowExecutingPath.postln ;
~func = {thisProcess.nowExecutingPath.postln};
"~/test/secondary.scd".standardizePath.load;
~func2.value;
// secondary.scd
thisProcess.nowExecutingPath.postln;
{~func}.value.value.postln;
~func2 = {thisProcess.nowExecutingPath.postln};
// OUTPUT
/Users/smoge/test/main.scd
/Users/smoge/test/secondary.scd
/Users/smoge/test/secondary.scd
/Users/smoge/test/secondary.scd
/Users/smoge/test/main.scd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's always the path containing the function call, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it necessary to create other files in the help file to demonstrate this? I'm not sure it will just take the focus away from the main point. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// Main.scd
thisProcess.nowExecutingPath.postln ;
~ func = {thisProcess.nowExecutingPath.postln};
"~/test/secondary.scd".standardizePath.load;
~func2.value;// secondary.scd
thisProcess.nowExecutingPath.postln;
{~func}.value.value.postln;
~func2 = {thisProcess.nowExecutingPath.postln};// OUTPUT
/Users/smoge/test/main.scd
/Users/smoge/test/secondary.scd
/Users/smoge/test/secondary.scd
/Users/smoge/test/secondary.scd
/Users/smoge/test/main.scd
Yes!
By evaluating the example in this PR:
- fileMain.scd:
( ("thisProcess.nowExecutingPath:").postln; (" in fileMain.scd: " + thisProcess.nowExecutingPath).postln; ~test = (thisProcess.nowExecutingPath.dirname +/+ "fileForLoad.scd"); ~test.load.testFunction; ~test.openOS; // n.b.: .openDocument only works in SC-IDE 'fileMain.scd tasks finished'.postln; )
- fileForLoad.scd:
(" in fileForLoad.scd: " + thisProcess.nowExecutingPath).postln; ( testFunction: { (" in the testFunction in fileForLoad.scd:" + thisProcess.nowExecutingPath).postln } )
- Post window:
-> a File -> /Users/prko/fileMain.scd thisProcess.nowExecutingPath: in fileMain.scd: /Users/prko/fileMain.scd in fileForLoad.scd: /Users/prko/fileForLoad.scd in the testFunction in fileForLoad.scd: /Users/prko/fileMain.scd fileMain.scd tasks finished -> fileMain.scd tasks finished
Is it necessary to create other files in the help file to demonstrate this? I'm not sure it will just take the focus away from the main point. What do you think?
Evaluating a path in HelpBrowser returns a wrong path. To make it easy for readers to understand how it works, users should learn it by doing or by watching a video. I think including this example helps. For me, http://doc.sccode.org/Classes/File.html is a well-written example in this respect.
HelpSource/Classes/Process.schelp
Outdated
"(" ++ ("\tin fileMain.scd: ").quote + "+" + test ++ ").postln;\n" ++ | ||
"~test = (" ++ test ++ ".dirname +/+" + "fileForLoad.scd".quote ++");\n" ++ | ||
"~test.load.testFunction;\n" ++ | ||
"~test.openOS; // n.b.: .openDocument only works in SC-IDE\n" ++ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe just avoid code like .openOS that only works in scide?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
openOS
works in the terminal and the SC-IDE. Does it not work on Emacs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
openOS
works in the terminal and the SC-IDE. Does it not work on Emacs?
It does something strange. If I evaluate this in Emacs, it opens SCIDE ... But it will vary from system to system. It uses xdg-open
on Linux.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would use this method for files like PDF, but it can result in strange behaviors with scd files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is because SC-IDE is the default application for scd document on your OS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I usually have emacs running first and open files from it. So I don't change xdg-open default. Emacs users don't usually open and close emacs all the time. (Also, you can open with a emacsclient or a new emacs process, two ways)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know, openDocument
works only inside SC-IDE. However. openOS
works generally.
I also do not close SC-IDE. Anyway I changed that part as follows:
code::
~fileMainPath.openOS;
// Note:
// - .openDocument only works in SC-IDE.
// - .openOS will work in other editors and
// the system default application will open the SCD file. ::
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I revised PR reflecting what you pointed out: Sorry and thank you for your efforts to work with a person without sufficient English skills... |
I'm not sure about this part. Do we want to generate the source files like this? It can be confusing. I think just writing the files in different code blocks would be more clear. |
@smoge
I can only imagine these two alternatives. If you want, I can choose one of these examples. |
I thought just writing the actual files. Not generating them. What do you think? |
Example updated for ease of understanding
I also feel that the last update, which reflects @smoge's suggestion, is now easier to understand. |
Sorry! |
there's an interesting subtlety (at least on Mac): if fileOne.scd contains |
I still feel this could be clearer! if we're just documenting the (suboptimal) current behavior how about something like: Save a file on disk called
in the same directory save a file called
now save a third file
in the case of functions |
OK I think we should change this behavior - I'm going to make a PR to set |
Ok, then this PR is reserved until your PR is reviewed, I believe. However, I would like to ask one question and to mention one thing:
@cdbzb |
Purpose and Motivation
It fixes an outdated incorrect explanation for
thisProcess.nowExecutingPath
:thisProcess.nowExecutingPath
also works correctly on Windows (tested with Windows 11) and Linux (tested with Ubuntu 22.04).Also added some examples with other classes.
Some examples are based on https://scsynth.org/t/serverboot-add-and-thisprocess-nowexecutingpath/8662/7?u=prko
Thanks @jamshark70, @cdbzb and @smoge
Types of changes
To-do list