After further thought (though perhaps still not enough time studying
the code and thinking about its use), a better approach (than
coinsert'base', which would allow name collisions) would be to use
do_base_
instead of
".
where that is used (getDEoptim and packargs).
Sadly, there's no equiv
I agree with you on locales causing troubles. Especially since some things
just seem to go against the grain of J, i.e. don't work as expected.
For instance today, I tried writing an explicit adverb that would need to
execute in an object's locale. It didn't work, because once a verb is
derived, i
On Thu, May 12, 2022 at 3:27 PM Jan-Pieter Jacobs
wrote:
> This works, but honestly, it's ugly.
If it works right, it's beautiful. ;)
--
Raul
--
For information about J forums see http://www.jsoftware.com/forums.htm
I think I agree with you, but I have been reluctant to suggest the
change. I am not sure what the ramifications of the change would be.
Henry Rich
On 5/12/2022 3:27 PM, Jan-Pieter Jacobs wrote:
I agree with you on locales causing troubles. Especially since some things
just seem to go against
The problem here is transitive (thinking about the call stack and the
relationship between the represented partial execution contexts).
We want things to operate correctly but, when multiple locales are
involved, correctness at the interface is different from internal
correctness.
This winds up b
Hi, I have some questions on error reporting.
I wrote this verb, I thought could be handy alongside the assert verb in
the standard library:
assertno =: 0 0$([ 13!:8~ ],~(LF,'| '),~ (9!:8'') {::~ <:@[)&>/@[^:(0 e. ])
it takes as x: error_number;'message', and as y the same as for assert (i.
e.
Hmm...
Usually when I throw errors I try to make my tests somewhat
readable and either
a) form a simple (fast) sentence which throws the desired error, or
b) use an assert.
--
Raul
On Thu, May 12, 2022 at 6:10 PM Jan-Pieter Jacobs
wrote:
>
> Hi, I have some questions on error reporting.
>
> I