Hmm... The domain error looks like it's from an error in the text on the page.
qstr and vchar both use the phrase "e but e is an undefined name. Replacing "e with "1 turns the error into a length error in J807 and leaves it as a domain error in j901. Looking closer... I guess I'm going to have to rebuild some parts of the model to account for language drift. I wish there were more text describing its principles. FYI, -- Raul On Thu, Oct 29, 2020 at 2:15 PM Henry Rich <[email protected]> wrote: > > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
