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
