Your idea for checksumming entities might have merit. The AC() field of
a block - the usecount - is subject to change, but the rest of a block
should be immutable after assignment.
Moving on to the immediate problem you cite, I point out that there is
no such thing as a 'locale-specific verb'. A verb is defined by its
text. What locale it executes in is given entirely by the rules for
changing the implied locale given at
https://code.jsoftware.com/wiki/Vocabulary/Locales#Changing_the_implied_locale
. Usually you get the effect of a locale-specific verb by executing
verbname_specificlocale_ . The JE code implementing this follows the
spec closely and I would be surprised if it got confused.
If you were executing a modifier referring to x or y, remember that no
matter what locale the modifier was executed in, the derived verb is not
a locative and does not change the current locale. This is a 'feature'
of J that many (including me) have considered a bug. If enough argument
can be marshaled to carry that point, it could be changed.
hhr
On 2/18/2022 7:54 PM, Raul Miller wrote:
I ran into an issue today, where locale specific verbs were running in
base rather than in the locale where they were defined (j903).
Exiting and restarting J fixed the problem. At least for now.
But I am now wondering about the viability of some kind of "integrity
dump" where J somehow exposes something about supposed internal
constants -- perhaps a checksum of the "constants" defined at startup?
Being able to detect when things have gone awry should help. (I do not
know if the problem was caused by a flaw in J, in the operating system
or in the hardware, or in whatever else. But having test mechanisms
might shed clues...)
Thanks,
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
