I was using lldb, because I built using clang instead of gcc. But in either case, an important command is: b jtgr2
You might also want b jtsortb and/or b jtsortc This will not initially do anything, because libj will not have been loaded yet. But the debugger should pick it up right when libj loads. If not, I guess you'll have to step through main until you get to the point where libj is loaded. You might also be able to regain control without a breakpoint using control-C (at which point you could install the breakpoint and then continue execution). Note also that jtgr2 got executed three times before I reached the initial prompt. Those are not relevant to this problem, but are something you should expect to see. Thanks, -- Raul On Sun, Apr 12, 2015 at 11:38 AM, Vijay Lulla <vijaylu...@gmail.com> wrote: > Raul, > Are you using gdb? If so, how do I break at execution of "1/:1"? I > tried "break main" but that didn't help at all...got all entangled in > the initialization of the interpreter. > Thanks, > Vijay. > > On Sun, Apr 12, 2015 at 10:56 AM, Raul Miller <rauldmil...@gmail.com> wrote: >> (This is a stream of thought semi-narrative about looking into this 1/:1 >> bug.) >> >> A trick, though, for using a debugger, is figuring out how to get >> debugging information into the build. >> >> In my case, I needed to add the -g command line option. (It turns out >> that clang uses a lot of the same command line options as gcc, along >> with a lot of the same underlying file formats - DWARF in this case. >> Which, as near as I can tell, is a pun on the earlier ELF file format >> as much as anything else.) >> >> Anyways, once I managed to get the stuff compiled with -g (I think >> adding it to the CFLAGS definition in makefile was the important >> step), I had a debugging build where I couldn't inspect any of the >> variables. Because optimizations confuse the debugger. >> >> So the next thing to do was to change the definition of COMP (on line >> 43 of bin/jconfig) to use -O0 instead of -O3. And, since COMP is >> really just CFLAGS (or was before I changed the makefile), I probably >> should have put the -g on this line also. >> >> So that was fun... >> >> Anyways, with that out of the way, I could build and run a working >> jconsole and run it under the debugger and have the debugger be >> somewhat intelligible. >> >> And after a bit of poking around, I found that jtgr2 in vgsort.c is >> the top level implementation for dyadic /: and that in the 1/:1 case >> it's calling jtsortb (defined further down in the file). >> >> So apparently we're talking about a bug in jtsortb(). >> >> But looking at how the system behaves, jtsortb() only seems to be >> called when sorting rank 0 boolean scalars. But jtsortb seems to be >> way more complicated than it would need to be, for that purpose. >> >> Still, if jtsortb() is special case code, I should be able to just disable >> it and have the j interpreter use the more general jtsortc() >> implementation for this case. (Yeah, I need to better understand what >> I'm doing before I propose any changes, but for now, I'm just trying >> to get myself oriented). >> >> Anyways, avoiding the call to jsortb() turns out to be an easy change. >> But it also turns out that the interpreter behaves exactly the same >> way (same bug even) when 1/:1 gets handled by jtsortc. >> >> So I guess I really ought to study the code enough to understand >> the underlying assumptions of the code so I can fix this without >> breaking something else. >> >> (Oh well, at least this is a distraction from trying to figure out how to >> do a meaningful opengl lab that somehow is relevant across a variety >> of somewhat semi-incompatible opengl versions. ...) >> >> Anyways... at the moment, in jtsortc, it's looking like the problem is >> that n is 0 at this line: >> >> https://github.com/openj/core/blob/master/vgsort.c#L63 >> >> DO(n, ++yv[*wv++];); >> >> Here, wv is a pointer to the list of values being sorted, and yv is >> the tallies of how many we have seen of each of them, and n is the >> number of values we need to scan through. So n *should* be 1. But it's >> not - it's zero. >> >> Meanwhile, n is defined as a part of the SF macro which is used to >> provide the common elements of jtsortc and jtsortb. So that's probably >> why we're seeing the same bug in both cases. >> >> Fortunately, the definition of SF is simple (and it's only relevant in >> this file): >> >> https://github.com/openj/core/blob/master/vgsort.c#L10 >> >> #define SF(f) A f(J jt,I m,I c,I n,A w) >> >> The value of n is just being passed in literally from jtgr2() where it >> is defined as n=s[f]; >> >> https://github.com/openj/core/blob/master/vgsort.c#L166 >> >> Here, s is the shape of the right argument and f is the frame of the >> right argument (0 in this case). So the problem is that the shape is >> empty for this case, and we're using a binsort. We should expect to >> see the same problem if we try to sort a single character: >> >> a.i./:~'a' >> 0 >> >> Perhaps in older versions of J, we always had a 1 in the shape for >> rank 0 nouns? >> >> So... anyways... to fix this, the definition of n needs to change. And >> figuring out the right change for that would mean thinking through >> what sort needs to do with various integrated rank support cases. >> >> Or, jtsortb/jtsortc need to ignore n and get the number of elements to >> sort using some other approach. If we went this way, we could probably >> assume that the rank we are dealing with is no greater than 1 and that >> we are only dealing with "booleans" (I dislike that name because I am >> of the opinion that non-negative integers are the proper "boolean" >> type - this two valued type should perhaps be called "truthiness" or >> "logicality" ... but that's not a change I am going to make.) This >> would be a minor inefficiency but it would not be the first. >> >> But... anyways... that's the problem. >> >> Thanks, >> >> -- >> Raul >> >> >> >> >> >> >> >> Thanks, >> >> -- >> Raul >> >> On Sat, Apr 11, 2015 at 10:12 PM, Vijay Lulla <vijaylu...@gmail.com> wrote: >>> The readme.txt in the jgplsrc folder (which is what the tar zipped >>> archive unzips to) contains instructions for how to build and test the >>> source code. It is slightly different than most of the open source >>> projects but it shouldn't be much difficult if you're familiar with >>> configure/make/install routine used in linux land. Also, each c file >>> has one line (4th line in most cases) describing what is in that c >>> file. I've extracted those and put them in a file named 00FILEMAPPING >>> (strangely named to always keep it at the top!) and I just consult it >>> to see which file I should be looking at for implementation of >>> vocabulary items. >>> >>> I'm not entirely sure but I think this strange issue of >>> grading/sorting literals might be connected to list/atom dichotomy for >>> a single item list. This dichotomy is fine for numbers but unsuitable >>> for literals. I just cannot think of a situation where a single item >>> literal can be anything but a list. Am I missing something obvious? >>> >>> On Sat, Apr 11, 2015 at 2:59 PM, Henry Rich <henryhr...@nc.rr.com> wrote: >>>> Interesting. There seems to be a retrogression in J8.03, which included a >>>> new interpreter build. >>>> >>>> It gets even weirder: >>>> >>>> In J8.03 32-bit, >>>> >>>> /:~'p' >>>> >>>> p =. 'p' >>>> >>>> /:~'p' >>>> >>>> /:~p >>>> p >>>> /:~'p' >>>> p >>>> >>>> Initialization error? >>>> >>>> If Jsoftware would organize a way to modify, build, & test the official J >>>> version, many of us would work on fixing problems like this. >>>> >>>> Henry Rich >>>> >>>> >>>> On 4/11/2015 2:12 PM, EelVex wrote: >>>>> >>>>> What is more alarming, imo, is that: >>>>> >>>>> (in both j701 and j801) >>>>> /:~2 >>>>> 2 >>>>> /:~'p' >>>>> p >>>>> /:~'pa' >>>>> ap >>>>> /:~'p' >>>>> NB. empty result! >>>>> >>>>> >>>>> >>>>> On Sat, Apr 11, 2015 at 9:00 PM, Henry Rich <henryhr...@nc.rr.com> wrote: >>>>> >>>>>> Don't expect this to be fixed in J804. There are many small interpreter >>>>>> bugs and no organized effort to repair them AFAIK. >>>>>> >>>>>> This bug is similar to the previously-noted bug #86 which was that the >>>>>> result was atomic rather than a list for equal Boolean values. >>>>>> >>>>>> On my system, which is J32, /:~1 is 0. >>>>>> >>>>>> Henry Rich >>>>>> >>>>>> >>>>>> On 4/11/2015 1:54 PM, robert therriault wrote: >>>>>> >>>>>>> So the fix may already be in process. >>>>>>> >>>>>>> The versions that I have found with the issue are: >>>>>>> >>>>>>> j602/2008-03-03/16:45 which is not surprising since it is not a current >>>>>>> version and >>>>>>> >>>>>>> j803/2014-10-19-11:11:11 in the jhs environment on my mac, which is >>>>>>> certainly more current, although the whisperings suggest j804 may not be >>>>>>> far off. >>>>>>> >>>>>>> Cheers, bob >>>>>>> >>>>>>> On Apr 11, 2015, at 10:29 AM, 'Pascal Jasmin' via Programming < >>>>>>> programm...@jsoftware.com> wrote: >>>>>>> >>>>>>> actually, in Jqt 8.03 >>>>>>>> >>>>>>>> >>>>>>>> 1 /: 1 >>>>>>>> 1 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: robert therriault <bobtherria...@mac.com> >>>>>>>> To: Programming forum <programm...@jsoftware.com> >>>>>>>> Cc: >>>>>>>> Sent: Saturday, April 11, 2015 1:16 PM >>>>>>>> Subject: [Jprogramming] Results of 1/:1 >>>>>>>> >>>>>>>> Just spotted a question on stack overflow from Zhe Hu about the >>>>>>>> behaviour of 1/:1 >>>>>>>> http://stackoverflow.com/questions/29580291/j-sort- >>>>>>>> function-1-1-returns-0 >>>>>>>> >>>>>>>> 2/:2 NB. expected result >>>>>>>> 2 >>>>>>>> 1/:1 NB. expected 1 as the result >>>>>>>> 0 >>>>>>>> >>>>>>>> Also, >>>>>>>> >>>>>>>> #$ 2 /: 2 NB. result is list as expected >>>>>>>> 1 >>>>>>>> #$ 1 /: 1 NB. result is atom, not a list as expected >>>>>>>> 0 >>>>>>>> >>>>>>>> I don't see the reasons that 1/:1 would return the atom 0 as a result, >>>>>>>> but that does not mean there one does not exist. :) >>>>>>>> >>>>>>>> Cheers, bob >>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> 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 >>> ---------------------------------------------------------------------- >>> 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
