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

• [x] Code is tested
• [x] All tests are passing
• [x] Updated documentation
• [x] 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]

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

[prko]

I think the part this PR touches should be improved, but there seems to be little interest. Should this PR stay open or should I close it?

@cdbzb Is there any update from your side?

[telephon]

2. Why does loadRelative return an array?

Because it may interpret several files, when the path is a wildcard. loadRelative calls loadPaths which returns an array. This is more reliable, and it is hard to check, since your code may return anything, including arrays ...

[telephon]

In my memory, there is indeed a bug in loadRelative, and resolveRelative (If I understand, you also found it?) This should be done in a separate issue, and probably fixed before we merge this explanation.