Setting ⎕RL does not appear to work under MiServer

[ray]

Hi,

Im using "?" under MiServer (for my ANT visualisation).

To "debug" the ants, I need to be able to reproduce the same run repeatedly to see the effect of a change in my code, so Im setting ⎕RL to try to ensure the same random numbers from "?".

However, when I try the identical code twice under MiServer, I am getting different results.

I assume that MiServer is resetting ⎕RL, or using "?" which is causing the problems Im having.

If it is (and it is not poor coding at my end, which I cant rule out), can a isolate my code from MiServer use of "?" or ⎕RL ?

Ray

[Brian|Dyalog]

Hi Ray,

MiServer does use ⎕RL and ? in the HtmlElement class in order to generate random HTML element ids when needed. The MiPage class is derived from the HtmlPage class which is in turn derived from the HtmlElement class. Your page is based on the MiPage class. ⎕RL has namespace scope so I can think of a couple possible ways to create repeatable scenarios, but it would be helpful to see how you've organized your code. If you have your code in a public repository somewhere, let me know, otherwise, email me and we'll work out how I can take a look at what you're doing.

Best regards,
/Brian

[ray]

Hi Brian,
Thank you for your quick response.

I do have a (2 month out of date) version on Git-Hub at https://github.com/RayCannon/Ambiants

The class called by MiServer is "Hex", and is to be found in "RayCannon-patch-1" under "hex.dyalog".

Because of my personal dislike of namespace SCRIPTS (functions in scripts loose their original workspace timestamp) the hex class functions are all copied in via a ":Include #.Combat_fns" statement in hex.dyalog .

I have tried adding a "⌷RL ← 16807" line in the hex namespace, but without apparent success.

The workspace "hexserver32.dws" sets up and then starts up the "hex" class under MiServer.

When NOT "debugging" Ant code I set "⎕RL←1 1" as I do require random behaviour under normal usage.

Thanks for any suggestions,

Ray

[Morten|Dyalog]

Hi Ray! Have you tried creating a separate namespace and using it to "source" random numbers?

⎕RL has namespace scope, as "proved" by the following sequence:

Code: Select all

      #.(Random←⎕NS '').⎕RL←22
      #.Random.? 6 6 6
5 2 3
      #.Random.⎕RL←22
      #.Random.? 6 ⍝ Expect sequence to restart from 5
5
      ?6 ⍝ Generate random number outside the namespace
3
      #.Random.? 6 6 ⍝ Continue the sequence
2 3

[ray]

Thank you Morten.

So simple, I already had a namespace "G" for global variables, so I simple replaced "⎕RL←1602" by "G.⎕RL←1602" and "?" by "G.?" and with just those 4 extra character it works fine.

I don't really understand why setting ⎕RL in the class (which is also a Namespace) did not achieve the same effect, but I'm very happy with the result.

(I have in the past played with namespaces to localise the effect of ⎕IO, eg with "⎕IO←1" set then creating a namespace called "IO" setting "IO.⎕IO←0", so "IO.⍳6" gives 0 1 2 3 4 5 when required without knock on effects on other ⎕IO settings.)

Thanking both Brian and Morten for your help

Ray

[Morten|Dyalog]

I don't really understand why setting ⎕RL in the class (which is also a Namespace) did not achieve the same effect

The reason for this is that the class inherits some MiServer base classes, and those classes also use random numbers - and that is happening in the same namespace. Arguably, one should log an issue against MiServer and ask that *it* start using a different namespace, so that it does not mutate the environment that application code is running in.

[kai]

I don't really understand why setting ⎕RL in the class (which is also a Namespace) did not achieve the same effect, but I'm very happy with the result.

Ray, since you said that a class is also a namespace I guess that with a class "Foo" you did

Foo.⎕RL←<integer>

A class is NOT a namespace. The two exist in parallel, sharing the same name. (Yes, really!)

So setting Foo.⎕RL has no bearing on the value of ⎕RL inside the class. It sets the value of ⎕RL in the namespace that accompanies the class.

When you think about public and private stuff it becomes apparent: ⎕RL in the class is of course private, and there is no way to make it public, meaning that referencing it cannot by definition reveal the value of ⎕RL inside the class. For the same reason assigning a value is impossible.

When you do something like this it will work:

:Class Foo

⎕RL←<integer>

...

:EndClass

This would also work (in the session):

Foo.⎕rl←<integer>
      Foo.? 100

That's because both statements are executed inside the namespace, not inside the class.