(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
