For adverbs and conjunctions producing non-verbs: Option 1: You could provide an option to assume that user-written modifiers are repeatable. That would let you test partial phrases to see how they behave.
Option 2: You could use the jtrace approach - emulate the parser yourself so that at each stage of parsing you know which rule will be used next. Thanks, -- Raul On Sun, Dec 14, 2014 at 4:56 PM, Henry Rich <[email protected]> wrote: > Jan-Pieter, > > Forward and back buttons are a good idea; I will work on them soon. > > I have put out version 3.4.3 which addresses the other issues you brought > up. > > 1. Lev was being executed in the wrong locale. This is now fixed, but Lev > as shown will not get through dissect because dissect assumes that a > user-written modifier produces a verb. I don't see any way to fix that. > > 2. pow (or any other cover name that is defined tacitly) is now supported as > if you had written ^: . > > 3. The selection error in dissect '+: ^: 4 [6' is fixed. > > 4. Generally, you can click on any result to get an expansion or to > highlight the inputs that produced it. The exception is when the result is > a single cell and there is no further detail available. When this happens, > the program displays a tooltip telling you that. Unfortunately, it removed > the tooltip when you released the mouse, so if you were a fast clicker you > never saw it. I have forced the message to linger on the screen for at > least half a second; see if that makes things clearer. > > 5. Now you can remove an expansion by clicking on the result that caused the > expansion to be created in the first place. This doesn't work for $:, but > it does for the rest: / ^: etc. > > Thanks much for the suggestions. I expect that it will take quite a bit of > feedback to produce the best user interface. > > Henry Rich > > > On 12/14/2014 11:42 AM, Jan-Pieter Jacobs wrote: >> >> Henry, >> congratulations with this tool it's really an excellent help for debugging >> complex things, and explaining J phrases to beginners. >> >> I ran into some errors though, when playing around with conjunctions: >> >> Lev =: 2 : 'u' >> 1 Lev 2 Lev 3' >> 1 >> dissect '1 Lev 2 Lev 3' >> value error >> >> |value error: Lev >> >> | exeobj=.1 (Lev)2 >> >> >> and >> >> >> pow =: ^: >> >> dissect '+: ^: 4 [6' NB. works as expected >> dissect '+: pow 4 [ 6' >> dissect error: internal result does not match the result from the J >> session! Aborting. >> >> y= >> >> ┌────┬┐ >> >> │┌──┐││ >> >> ││96│││ >> >> │└──┘││ >> >> └────┴┘ >> >> >> With the first one (+: ^: 4 [6) it shows the window as expected, and also >> the recursions when clicked on the final result, but clicking on any >> intermediate result gives an error message. >> >> >> For the Quicksort example you gave it does work though. >> >> Just to let you know. >> >> >> As I said, I really like dissect, but I'm having a bit of a hard time >> navigating around. To me, it's not really clear what is clickable and why. >> It would also be nice to have a way to undo expansions, or go to a >> previous >> view (like a back button), especially when tracing around in something >> like >> the Quicksort example. >> >> Kind regards, >> >> Jan-Pieter >> >> 2014-12-13 22:31 GMT+01:00 Henry Rich <[email protected]>: >>> >>> >>> Dissect, the 2-D sentence debugger, now supports all J primitives, in >>> most >>> of their forms (it doesn't handle gerunds on partitioning modifiers or >>> }). >>> It is an addon and is described at >>> >>> http://www.jsoftware.com/jwiki/Vocabulary/Dissect >>> >>> Dissect is especially useful if you are teaching J. Suppose a student >>> reads that +//.@(*/) does polynomial multiplication. How much fun is it >>> going to be to explain THAT? Just let em run >>> >>> dissect '4 1 2 3 +//.@(*/) _1 4 0 2 6' >>> >>> and they can happily click on individual numbers and see where they came >>> from. >>> >>> Even if you're an expert you will want to use dissect if you have a >>> complicated sentence that is failing. For example: >>> >>> ]a =. (<0 1);<(<2 3 4);(1);<<5 6;7 8 >>> +-----+-----------------------+ >>> |+---+|+-------+-+-----------+| >>> ||0 1|||+-----+|1|+---------+|| >>> |+---+|||2 3 4|| ||+---+---+||| >>> | ||+-----+| |||5 6|7 8|||| >>> | || | ||+---+---+||| >>> | || | |+---------+|| >>> | |+-------+-+-----------+| >>> +-----+-----------------------+ >>> a: ,L:1 a >>> |domain error >>> | a: ,L:1 a >>> >>> You might not be one of the very few people, if indeed there are any, who >>> can see right off why this sentence failed. But if you run >>> >>> dissect 'a: ,L:1 a' >>> >>> or just use a PFkey set up to dissect the last line that failed, you will >>> immediately see the source of the problem. (The Wiki shows how to set up >>> a >>> PFkey). >>> >>> How about debugging recursions? Bring back some painful memories? >>> Looking >>> at an error message like >>> >>> 'b c' =. 'a';5 >>> >:`($:&.>)@.(0<L.) 1 2 3;<4 5;<<b;c >>> |domain error >>> | >:`($:&.>)@.(0<L.)1 2 3;<4 5;<<b;c >>> >>> ? >>> >>> Run >>> >>> dissect '>:`($:&.>)@.(0<L.) 1 2 3;<4 5;<<b;c' >>> >>> and you'll see the results of all the recursions, with the failing one >>> exposed in detail; you can look through them one at a time if you like. >>> >>> For fun, you can see quicksort (as described in the J Wiki) all at once >>> with >>> >>> a =. 20 ? 50 >>> dissect '(($:@(<#[) , (=#[) , $:@(>#[)) ({~ ?@#)) ^: (1<#) a' >>> >>> Henry Rich >>> ---------------------------------------------------------------------- >>> 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
