I have fixed the crash for the next beta. It was a recent blunder that
marked a block as inplaceable when it was still in use. It took some
improvements to our memory auditor to find the cause.
Thanks for the report. After the fix, I still get domain error in qstr.
Henry Rich
On 10/29/2020 1:02 AM, Raul Miller wrote:
Well.. technically, I do not want to generate a linear rep. I want to
generate a direct definition rep.
Or, at least, that is my current thinking.
But, also, the linear rep code does not do much of anything special
for explicit definitions. It just rearranges the atomic representation
of the code into a linear format. (Though it does seem to munge a
literal matrix into a literal vector, so maybe I will be able to take
advantage of that...)
Anyways...
I'm still working through the issues, and I expect I will have to
change the details, but I have run into another problem, which is that
the lrep model crashes J.
Actually, it throws a domain error, because it seems to expect that
the verb 'type' is defined as 3!:0 and that's not what the current
definition is,
But, replacing 'type' with 3!:0 in the definition of value at
https://www.jsoftware.com/ioj/iojRep.htm crashes J for me when I try
to use lrep.
If that doesn't give you an easy test case, let me know and I can try
narrowing down the cause of the crash. Though if you have any hunches,
I would also like to hear them because that will likely help me
isolate the offending code.
For example:
ex=: {{+/y}}
lrep <'ex'
0 libj.dylib 0x0000000119f644a0 jtio14 + 14400
1 libj.dylib 0x0000000119edadaf jtindexofprehashed + 1247
2 libj.dylib 0x0000000119d9b45f on1cell + 159
3 libj.dylib 0x0000000119dad975 jtfolk1 + 181
4 libj.dylib 0x0000000119e03862 jtunquote + 514
5 libj.dylib 0x0000000119dad9b8 jtfolk1 + 248
6 libj.dylib 0x0000000119dad975 jtfolk1 + 181
7 libj.dylib 0x0000000119dad975 jtfolk1 + 181
8 libj.dylib 0x0000000119dad975 jtfolk1 + 181
9 libj.dylib 0x0000000119e03862 jtunquote + 514
10 libj.dylib 0x0000000119db0820 jtcasei12 + 208
11 libj.dylib 0x0000000119e03862 jtunquote + 514
12 libj.dylib 0x0000000119d9b498 on1cell + 216
13 libj.dylib 0x0000000119d9b498 on1cell + 216
14 libj.dylib 0x0000000119db09c3 jtcasei12 + 627
15 libj.dylib 0x0000000119e03862 jtunquote + 514
16 libj.dylib 0x0000000119db09c3 jtcasei12 + 627
17 libj.dylib 0x0000000119e03862 jtunquote + 514
18 libj.dylib 0x0000000119dcc949 jtevery + 569
19 libj.dylib 0x0000000119d9b498 on1cell + 216
20 libj.dylib 0x0000000119dad975 jtfolk1 + 181
21 libj.dylib 0x0000000119e03862 jtunquote + 514
22 libj.dylib 0x0000000119db09c3 jtcasei12 + 627
23 libj.dylib 0x0000000119e03862 jtunquote + 514
24 libj.dylib 0x0000000119db09c3 jtcasei12 + 627
25 libj.dylib 0x0000000119e03862 jtunquote + 514
26 libj.dylib 0x0000000119d9b498 on1cell + 216
27 libj.dylib 0x0000000119d9b498 on1cell + 216
28 libj.dylib 0x0000000119e03862 jtunquote + 514
29 libj.dylib 0x0000000119df63c6 jtparsea + 1846
30 libj.dylib 0x0000000119df5c72 jtparse + 66
31 libj.dylib 0x0000000119df93c5 jtimmex + 85
32 libj.dylib 0x0000000119de8e49 jdo + 265
33 libj.dylib 0x0000000119de9351 JDo + 97
Engine: j902/j64avx2/darwin
Beta-i: commercial/2020-10-20T10:35:52
Library: 9.02.06
Qt IDE: 1.8.7/5.12.7(5.12.7)
Platform: Darwin 64
Installer: J902 install
InstallPath: /users/rauldmiller/applications/j902
Contact: www.jsoftware.com
Thanks,
--
Raul
On Wed, Oct 28, 2020 at 9:35 PM Henry Rich <[email protected]> wrote:
I feel that you are off in the weeds. But you are so seldom there,
maybe I just don't understand.
AR is not a native JE rep. It's there for portability. Converting an AR
to LR is nothing you would ever see in the JE. Thus I think your work on
a J model is misdirected.
Moreover, you will never feed it an AR of ((,'0');'{{'). {{ is a
spelling error. It will never get into the parser and will never be
part of a verb.
Furthermore, {{ is not a noun. It is a control word. Its AR would be
(<'{{').
Nested DDs are represented as (9 : 'string'). [This is internal and
subject to change.] The LR for this is already converted to a DD:
a =. 3 : 0
b =. {{ x + y }}
b y
)
5!:5 <'a'
3 : 0
b =. {{ x + y }}
b y
)
Where the new LR class is needed is in the display of the outermost
definition. You want the LR of A to be
{{
b =. {{ x + y }}
b y
}}
I think this is a fairly small change to the LR code. A deeper question
is whether the resulting string, when executed, will reproduce the
desired value. That is an issue to be resolved during the beta.
Henry Rich
On 10/28/2020 6:54 PM, Raul Miller wrote:
Right -- I was talking about the mechanism that would be used to do that.
The linear representation code at
https://www.jsoftware.com/ioj/iojRep.htm works by taking an atomic
representation and converting it into a linear representation.
In other words, the linear representation of {{+/y}} is 3 : '+/y'
More specifically, to generate
3 : '+/y'
that linear representation code starts from this data structure
{{+/y}} arep
+---------------------+
|+-+-----------------+|
||:|+-----+---------+||
|| ||+-+-+|+-+-----+|||
|| |||0|3|||0|+ / y||||
|| ||+-+-+|+-+-----+|||
|| |+-----+---------+||
|+-+-----------------+|
+---------------------+
What I was saying is that I could use that same code, with relatively
minor modifications, if I were to feed it something that looked like
this:
+-----------------------------+
|+-+-------------------------+|
||:|+------+---------+------+||
|| ||+-+--+|+-+-----+|+-+--+|||
|| |||0|{{|||0|+ / y|||0|}}||||
|| ||+-+--+|+-+-----+|+-+--+|||
|| |+------+---------+------+||
|+-+-------------------------+|
+-----------------------------+
But this doesn't deal with the occasional need for decorators like )a
-- that gets into deeper waters.
That said, maybe as proof of concept I should start with an
implementation which includes those decorators on multi-line
definitions and leaves them off of single line definitions? (Since the
decorators themselves currently require a newline to separate them
from the first line of code).
Note also that what I am saying means that this implementation would
NOT deal with the improper use of bare reserved argument names in the
resulting code, for single line definitions. But since that's a
relatively minor problem, maybe it's the right approach?
Thanks,
--
Raul
On Wed, Oct 28, 2020 at 8:46 AM Henry Rich <[email protected]> wrote:
You don't want to touch the internal representation (which is different
from AR). What is produced by {{ }} is just an explicit definition.
What you want is a switch to display an explicit definition using {{ }}
rather than n : 0. That could be as simple as using {{)x }} .
A different decision is whether you want to remember how a verb was
created, and display it in that form.
Henry Rich
On 10/27/2020 11:02 PM, Raul Miller wrote:
Hmm... actually, this might mean something new -- this approach
suggests delving into the atomic rep, finding the explicit definitions
and converting them to dd.
But that implies a less explicit ar which can directly represent a
direct definition. So, for example, making a '{{' token which has a
modifier indicating type (for example )a or )v or whatever), followed
by the direct definition text. Probably followed by an inert '}}'
token to make the ddrep implementation simpler...
I would definitely want Eric to weigh in on a design change that hits
the system this deeply.
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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
