Process.schelp: fix outdated incorrect explanation for thisProcess.nowExecutingPath with examples

[prko]

Purpose and Motivation

It fixes an outdated incorrect explanation for thisProcess.nowExecutingPath:

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::.

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

• Documentation

To-do list

• Code is tested
• All tests are passing
• Updated documentation
• This PR is ready for review

[prko]

The PDF of Process help document in this PR

• Process _ SuperCollider 3.14.0-dev Help - default css.pdf

• Process _ SuperCollider 3.14.0-dev Help _ custom.css.pdf

[prko]

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.

[smoge]

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.

[cdbzb]

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::."

[prko]

@cdbzb Thanks for the suggestion!
After the following thread,

https://scsynth.org/t/what-does-thisprocess-nowexecutingpath-return-in-editor-environments-other-than-sc-ide-scel-and-terminal-command-prompt/9474/4

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.

[smoge]

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::.

[prko]

@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::.

[smoge]

Have you switched the filenames at the end maybe? I will write a test code, just a minute.

[cdbzb]

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?

[smoge]

Maybe deserves a less confusing rewrite. Writing like @cdbzb comment "path of the document containing the function call" is already more clear.

[prko]

@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 or String: -loadPaths, thisProcess.nowExecutingPath will be the location of the executed file ("fileForLoad.scd" in the example code below). If a function containing thisProcess.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).

[smoge]

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

[smoge]

It's always the path containing the function call, right?

[smoge]

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?

[prko]

@smoge

// 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.

[smoge]

Maybe just avoid code like .openOS that only works in scide?

[prko]

openOS works in the terminal and the SC-IDE. Does it not work on Emacs?

[smoge]

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.

[smoge]

I would use this method for files like PDF, but it can result in strange behaviors with scd files.

[prko]

This is because SC-IDE is the default application for scd document on your OS.

[smoge]

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)

[prko]

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. ::

[prko]

Can I mark it as solved?

[prko]

@cdbzb @smoge

I revised PR reflecting what you pointed out:
Process _ SuperCollider 3.14.0-dev Help.pdf

Sorry and thank you for your efforts to work with a person without sufficient English skills...

[smoge]

@cdbzb @smoge

I revised PR reflecting what you pointed out: Process _ SuperCollider 3.14.0-dev Help.pdf

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.

[prko]

@smoge
Thanks for your opinion. Yes, it is indeed confusing. There are three reasons:

1. The use of the variable test:
   If I do not use test = "thisProcess.nowExecutingPath, the code block is as follows:
   

2. The use of \n with ":
   If I do not use \n with ", the code block is as follows:
   

3. The use of quote:
   There is no way to remove quote as there is no ''' and """ in sclang.

I can only imagine these two alternatives. If you want, I can choose one of these examples.
If not, could you suggest another example? I can also use your example.

[smoge]

I can only imagine these two alternatives. If you want, I can choose one of these examples.
If not, could you suggest another example? I can also use your example.

I thought just writing the actual files. Not generating them. What do you think?

[prko]

@smoge @cdbzb
I saw @cdbzb's like emoticon, so I updated the help file!

• Process _ SuperCollider 3.14.0-dev Help with custom css.pdf
• Process _ SuperCollider 3.14.0-dev Help with default css.pdf

[prko]

I also feel that the last update, which reflects @smoge's suggestion, is now easier to understand.
I was obsessed with automation...

[prko]

Sorry!
Closed due to incorrect touch.

[cdbzb]

there's an interesting subtlety (at least on Mac):

if fileOne.scd contains thisProcess.nowExecutingPath.postln and if we create a fileTwo.scd in the same directory and execute "fileOne.scd".load we get fileOne.scd in the Post window... If we execute "./fileOne.scd" we get ./fileOne.scd. In other word we get the string we called load on! This seems like a bug, no?

[cdbzb]

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 fileOne.scd with the following content:

thisProcess.nowExecutingPath

in the same directory save a file called fileTwo.scd with the following contents and evaluate each line

thisProcess.nowExecutingPath // full path of fileTwo.scd
"./fileOne.scd".load // ./fileOne.scd - the string we called load on
"fileOne.scd".load // fileOne.scd 
~test = { thisProcess.nowExecutingPath } // a Function
~test.() // full path of fileTwo.scd

now save a third file fileThree.scd and evaluate the following:

~test.() // full path of fileThree.scd 

in the case of functions thisProcess.nowExecutingPath is set when the function is evaluated, not when it is defined.

[cdbzb]

OK I think we should change this behavior - I'm going to make a PR to set .thisProcess.nowExecutingPath to pathname.absolutePath instead of pathname in Interpreter: executeFile

[prko]

@cdbzb

OK I think we should change this behavior - I'm going to make a PR to set .thisProcess.nowExecutingPath to PathName(pathname).fullPath instead of pathname in Interpreter: executeFile

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:

1. I still feel this could be clearer! if we're just documenting the (suboptimal) current behavior how about something like:

   This is a very good idea! Should the example added or should the example replace the old one with FileMain and FileForLoad?

2. if fileOne.scd contains thisProcess.nowExecutingPath.postln and if we create a fileTwo.scd in the same directory and execute "fileOne.scd".load we get fileOne.scd in the Post window... If we execute "./fileOne.scd" we get ./fileOne.scd. In other word we get the string we called load on! This seems like a bug, no?

   Thanks for this case!
   On my machine:

   1. The following code

      "fileOne.scd".load
      

      returns:

      file "fileOne.scd" does not exist.
      -> nil

   2. The following code

      "./fileOne.scd".load
      

      returns

      file "./fileOne.scd" does not exist.
      -> nil

   3. The following code

      "fileOne.scd".loadRelative
      

      returns:

      /Users/prko/fileOne.scd
      -> [/Users/prko/fileOne.scd]

   4. The following code

      "./fileOne.scd".loadRelative.class
      

      returns:

      /Users/prko/./fileOne.scd
      -> Array

   5. The following code

      "fileOne.scd".resolveRelative.load
      

      returns:

      /Users/prko/fileOne.scd
      -> /Users/prko/fileOne.scd

   6. The following code

      "./fileOne.scd".resolveRelative.load
      

      returns:

      /Users/prko/./fileOne.scd
      -> /Users/prko/./fileOne.scd

   The fourth and sixth cases are weird! As @cdbzb mentioned, this seems to be a bug in my opinion.
   The third and fourth cases are also odd. Why does loadRelative return an array?

   Based on the test result of my laptop, the 2nd and 4th lines in fileTwo.scd:

   thisProcess.nowExecutingPath // full path of fileTwo.scd
   "./fileOne.scd".load // ./fileOne.scd - the string we called load on
   "fileOne.scd".load // fileOne.scd
   ~test = { thisProcess.nowExecutingPath } // a Function
   ~test.() // full path of fileTwo.scd
   should be changed. Also .postln should be added to each line as follows:

   thisProcess.nowExecutingPath.postln; // full path of fileTwo.scd
   "./fileOne.scd".loadRelative.postln; // ./fileOne.scd - the string we called load on
   "fileOne.scd". loadRelative.postln; // fileOne.scd 
   ~test = { thisProcess.nowExecutingPath.postln; } // a Function
   ~test.() // full path of fileTwo.scd
   

   Also, the fileOne.scd should be

   thisProcess.nowExecutingPath.postln
   

@cdbzb
According to your response, I will update the relevant part of this PR, although we should wait for the review of your PR related to the behaviour change of thisProcess.nowExecutingPath.