User Command and Namespace

[Morten|Dyalog]

Could I ask what is the technical reason for a Class not being able to store a variable (characters, matrix of number, etc.).

There are two reasons: In addition to the issue of finding a representation for "any data", there is the problem of WHEN you update the script. Does the script get updated every time you add 1 to a global variable? Or when you explicitly reference the source? When do you write the script back to the external source file?

Script files are designed to contain the "source code" of an application, and not the data. Perhaps one could have a rule that said that variables which are initialized in the script should be updated - but it isn't clear how data should be handled in scripts.

[MBaas]

Hmmm, I'm also struggling with UCMDs and Namespaces atm, trying to reuse some utilities from a scripted namespace

      :Namespace dlstools

      ∇Z←A OVER B;S
      :Access Shared Public
.
.
.
:EndNamespace

which is stored in a file dlstools.dyalog in my UCMDs-folder (the same as the actual UCMD trying to use this ns with ":include dlstools").

However, when trying to launch my ucmd ]ucmd or call help for it, the status-window comes up with this msg:

line(3,9) : error AC0556: include target can only be a namespace ":include dlstools"
^
Complete: 1 error.

I was hoping it would be namespace! (I also tried storing that namespace's .dyalog-file in SALT, SALT/SALT)

[DanB|Dyalog]

Spaces' scripts (nss, classes) are like fn scripts (what we get with []NR): when you update a local variable the fn's []NR is not updated,
If line 3 of the fn sets variable A to 1, whenever A is modified (by of the code of the fn or because we manually updated it) the script is not modified.

[DanB|Dyalog]

Hmmm, I'm also struggling with UCMDs and Namespaces atm, trying to reuse some utilities from a scripted namespace

      :Namespace dlstools

      ∇Z←A OVER B;S
      :Access Shared Public
.
.
.
:EndNamespace

which is stored in a file dlstools.dyalog in my UCMDs-folder (the same as the actual UCMD trying to use this ns with ":include dlstools").

However, when trying to launch my ucmd ]ucmd or call help for it, the status-window comes up with this msg:

line(3,9) : error AC0556: include target can only be a namespace ":include dlstools"
^
Complete: 1 error.

I was hoping it would be namespace! (I also tried storing that namespace's .dyalog-file in SALT, SALT/SALT)

Michael: :Include assumes the namespace you want to include in the class resides in the same location as the class.
When you run a UCMD it runs INSIDE the Spice (aka UCMD) framework.
In order to include a ns in a class used for a ucmd you need to bring it in BEFORE the class is defined.
There is no way for you to do that by yourself. However, from the start, SALT has had the ability to bring in namespaces if they are required by recognizing a special comment that you include in the class. This comment is ⍝∇:require and can be used this way:

⍝∇:require path/incl

Usually you would use

⍝∇:require =/incl

instead where '=' means "from the same location as this class". Thus if you were to write a UCMD needing a ns to be included you should do something like

:Namespace in
∇ z←subTest
z←'works!'
∇
:EndNamespace
Save this in spice/MBincl.dyalog

:class myCmdGrp
:include in ⍝∇:require =/MBincl
∇ r←List
:Access public shared
r←⎕NS¨1⍴⊂⍬
r.Name←⊂'MBt1'
...
∇
∇ r←Run(Cmd Line)
:Access public shared
...
r←subTest
∇
:Endclass

Now if you call ]MBt1 it should call <subTest> without any problem.

That being said I don't recommend you do that in general as it is untidy. You need to keep track of both the UCMD file AND its included namespaces.
You could also separate them but you would have to hardcode the path into the class and any change in location would render the ucmd useless.
I try to keep my UCMDs smalll.
I have a couple of cases where a LOT of code has to be brought in. In that case I COPY (using []CY) the whole workspace I need or I bring in (using SALT) another space. This is similar to the :include case and the day my script moves my UCMD will stop to work.
But it's a tradeoff.
You decide.
/Dan

[MBaas]

Thanks Dan for the info on require, very useful :-)
Unfortunately it's not working as intended - I have created these 2 sample-files, but ]? now returns:

Error loading Spice Commands from C:\Program Files\Dyalog\Dyalog APL-64 12.1 Classic\SALT\Spice\MBcmd: VALUE ERROR
Error loading Spice Commands from C:\Program Files\Dyalog\Dyalog APL-64 12.1 Classic\SALT\Spice\MBincl: VALUE ERROR

I have attached both files so that you can easily replicate the issue.

[DanB|Dyalog]

The example I posted above cannot work.
I deliberately replaced working code by '...' to save space. You would have to fill in the ...s

The complete code would look something like

:class myCmdGrp
⎕IO←1 ⋄ ⎕ML←1

:include in ⍝∇:require =/MBincl

∇ r←List
:Access public shared
r←⎕NS¨1⍴⊂⍬
r.Name←⊂'MBt1'
r.Group←⊂'MyCmds'
r[1].Desc←'help for MB'
r.Parse←⊂''
∇

∇ r←Run(Cmd Line)
:Access public shared
r←subTest
∇

∇ r←level Help Cmd;⎕ML
:Access public shared
r←'Better help...'
∇

:Endclass

[MBaas]

Thanks Dan, adding .Parse and .Help-props to the class fixed the problem. I guess I was confused because there was a VALUE ERRROR even for MBincl, but that has also disappeared now :-)