Re: [Jsource] [Jprogramming] Bug in sorting?

[bill lam]

On linux or Mac, it should be as simple as typing make2/build_all.sh
What are the errors that you got?

On Thu, Dec 28, 2023 at 10:23 PM Raul Miller  wrote:

> I decided I should try taking a look at this... but I'm running into
> numerous errors trying to compile j9.4.3 (or, for that matter, j902).
>
> So... I guess I won't try to look into this. But I figure I should
> give people a heads up that at least one machine has issues with
> compiling J.
>
> --
> Raul
>
> On Thu, Dec 28, 2023 at 5:40 AM bill lam  wrote:
> >
> > I got a similar result. I believe this bug is related to the boolean
> > argument.
> > coercing the array to integer can work correctly.
> >
> > p =. 00 + 8 2 $ 0 0 1 1 1 0 0 0 0 1 1 0 1 0 0 0
> >
> > On Thu, Dec 28, 2023 at 6:02 PM Marcin Żołek <
> > marcin.zo...@students.mimuw.edu.pl> wrote:
> >
> > > Hello,
> > > I was trying to run my code on j9.4 Linux, j9.4 MacOS, j9.5 MacOS and
> it
> > > crashes.
> > >
> > > In terminal
> > > /Applications/j9.5/bin/jconsole bug.ijs < input.txt
> > > JE has crashed, likely due to an internal bug.  Please report the code
> > > which caused the crash, as well as the following printout, to the J
> > > programming forum.
> > > Could not generate stack trace: no debug info in Mach-O executable (-1)
> > > ...
> > >
> > >
> -
> > > 5 3 1 1[1]6692 abort  /Applications/j9.5/bin/jconsole bug.ijs <
> > > input.txt
> > >
> > > bug.ijs:
> > > ":@((#/.~ +/@, ~.)@/:~)@(".;._2)&.stdin''
> > >
> > > input.txt:
> > > 0 0
> > > 1 1
> > > 1 0
> > > 0 0
> > > 0 1
> > > 1 0
> > > 1 0
> > > 0 0
> > > I figured out that the problem is with sorting:
> > > p =. 8 2 $ 0 0 1 1 1 0 0 0 0 1 1 0 1 0 0 0
> > > p
> > > 0 0
> > > 1 1
> > > 1 0
> > > 0 0
> > > 0 1
> > > 1 0
> > > 1 0
> > > 0 0
> > > /:~ p NB. returns various and wrong results
> > > 0 0
> > > 0 0
> > > 0 0
> > > 1 0
> > > 1 0
> > > 1 0
> > > 1 1
> > > 1 1
> > >
> > > or
> > >
> > > 0 0
> > > 0 0
> > > 0 0
> > > 1 0
> > > 1 0
> > > 1 0
> > > 0 0
> > > 0 0
> > > ~.@:/:~ p NB. crashes jqt
> > >
> > > Best regards,
> > > Marcin
> > > --
> > > 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

Re: [Jsource] thoughts about rewriting extended integer support

[bill lam]

After the patch
  q:509247139646491621x
270869761 1880044261

This is taken from the gmp source
+void jmpn_com (mp_ptr rp, mp_srcptr up, mp_size_t n)

+{

+  mp_limb_t ul;

+  do {

+  ul = *up++;

+  *rp++ = ~ul & GMP_NUMB_MASK;

+  } while (--n != 0);

+}

@Henry The j32 still failed in gj but probably unrelated to XNUM. Please
check.



On Mon, Dec 4, 2023 at 11:13 PM Raul Miller  wrote:

> No, not only a private branch. I took your message
> https://www.jsoftware.com/pipermail/source/2023-December/001628.html
> as an indication that I should push what I had working to the main branch.
>
> That said, I see what happened. Though I'm baffled how it did not fail
> on my machine.
>
> mpn_com is supposed to implement a bitwise negation of a span of gmp
> limbs. It's mpn_neg which is supposed to implement the two's
> complement of that span.
>
> I misremembered these details and implemented in my jmpn_com the logic
> of mpn_neg. That should never have worked in any examples of negating
> an extended integer I can think of.
>
> And yet it repeatedly passed tests on my machine.  I don't understand
> how that was possible. I guess I'm going to spend some time looking at
> intermediate results before I go any further with this project.
>
> Thanks,
>
> --
> Raul
>
> On Mon, Dec 4, 2023 at 9:54 AM Henry Rich  wrote:
> >
> > I can't get this to fail.  Even
> >
> >   q: 1000 $ 509247139646491621x
> >
> > works.  The problem is that q: is nondeterministic for large numbers.
> > It usually works, but sometimes not.  I will replace the q: with q: ::
> > q: and hope that doesn't fail.
> >
> > @Raul: you have pushed your changes only to your private branch, right?
> >
> > hhr
> >
> > On 12/3/2023 8:02 PM, Bill Heagy wrote:
> > > JVERSION
> > > Engine: j9.5.0-beta8/j64avx2/linux
> > > Build: GPL3/2023-12-03T19:45:50/clang-16-0-6/SLEEF=1
> > > Library: 9.5.5
> > > Platform: Linux 64
> > > Installer: unknown
> > > InstallPath: /home/wheagy/git/jsource/jlibrary
> > > Contact: unknown
> > >
> > >
> > >
> > > .
> > >'domain error' -: 2 ?. etx 2 3;4 5
> > > 1
> > >'domain error' -: 2 ?.~etx 2 3;4 5
> > > 1
> > >
> > >'domain error' -: ?.~@(*/) etx 'abc'
> > > 1
> > >
> > >'length error' -: 2 3 ?. etx 4 5 6
> > > 1
> > >
> > >270869761 1880044261 -: q: 509247139646491621x
> > > |nonce error in ex02, executing monad q:
> > > |this computation is not yet supported
> > > |   270869761 1880044261-:q:509247139646491621x
> > > |[-66] /home/wheagy/git/jsource/test/g641.ijs
> > >
> > > On 12/3/23 19:11, Raul Miller wrote:
> > >> Ok, changes pushed. I believe I've a working update for jtxplus, and I
> > >> believe it's portable to all supported architectures.
> > >>
> > >> I'll keep an eye out for issues. If all goes well, I intend to start
> > >> working through some of the other X primitives (and, eventually, the
> > >> RAT primitives). If I have to hold off at some point for release
> > >> management purposes, I think that that should be fine - this effort
> > >> can be completed in J9.6 or whenever.
> > >>
> > >> Thanks,
> > >>
> > > --
> > > 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

Re: [Jsource] thoughts about rewriting extended integer support

[bill lam]

Your version of gmpn_com does not work in some cases. I have pushed a patch
to resurrect gmpn_com in non-window os.
A version of gmp_com for windows is also defined and to be tested in github
action. Let us see if that will work.


On Mon, Dec 4, 2023 at 10:11 PM Raul Miller  wrote:

> Nope, I am still unable to reproduce this issue.
>
> I don't know what's going on here.
>
> --
> Raul
>
> On Mon, Dec 4, 2023 at 8:51 AM Raul Miller  wrote:
> >
> > I do not have any uncommitted changes.
> >
> > That said, I ran script/install-lnx.sh a few minutes ago, and it had
> > some new packages to install, along with some other changes. I'm
> > running a fresh build and test right now to see if the changes it
> > introduced will let me reproduce this issue.
> >
> > Thanks,
> >
> > --
> > Raul
> >
> > On Mon, Dec 4, 2023 at 8:43 AM bill lam  wrote:
> > >
> > > Do you have any uncommitted changes in your computer?
> > >
> > > On Mon, Dec 4, 2023 at 21:41 Raul Miller 
> wrote:
> > >
> > > > Yes: 8e379fd90153baae7624401ddb1aaa16f3179cd4
> > > >
> > > > Very odd.
> > > >
> > > > --
> > > > Raul
> > > >
> > > > --
> > > > Raul
> > > >
> > > > On Mon, Dec 4, 2023 at 7:51 AM bill lam  wrote:
> > > > >
> > > > > I tested on apple m1 and the following 3 tests failed.
> > > > > g641
> > > > > gqco
> > > > > gxco1
> > > > >
> > > > > The sha1 for the latest commit in the master branch is
> 8e379fd90153 , is
> > > > > this the same on your machine?
> > > > >
> > > > > On Mon, Dec 4, 2023 at 3:54 PM bill lam 
> wrote:
> > > > >
> > > > > > Nearly all platforms failed on GitHub action.
> > > > > >
> > > > > > On Mon, Dec 4, 2023 at 14:13 Raul Miller 
> > > > wrote:
> > > > > >
> > > > > >> No errors, still, on my machine, for script/buildga.sh linux &&
> > > > > >> script/testga.sh linux
> > > > > >>
> > > > > >> I don't know if this means that my machine is defective or
> deficient
> > > > > >> in some way, of course.
> > > > > >>
> > > > > >> FYI,
> > > > > >>
> > > > > >> --
> > > > > >> Raul
> > > > > >>
> > > > > >> On Mon, Dec 4, 2023 at 12:33 AM Raul Miller <
> rauldmil...@gmail.com>
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > I tested on the master branch. I'll do a fresh compile and
> test
> > > > again,
> > > > > >> > though, since I've nothing better to do on this issue.
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> >
> > > > > >> > --
> > > > > >> > Raul
> > > > > >> >
> > > > > >> > On Sun, Dec 3, 2023 at 11:28 PM bill lam  >
> > > > wrote:
> > > > > >> > >
> > > > > >> > > Are you two both testing on the master branch?
> > > > > >> > >
> > > > > >> > > On Mon, Dec 4, 2023 at 12:02 Raul Miller <
> rauldmil...@gmail.com>
> > > > > >> wrote:
> > > > > >> > >
> > > > > >> > > > I have been unable to reproduce this issue.
> > > > > >> > > >
> > > > > >> > > > $ time j64/jconsole -lib libjavx2.so -js "exit i.0[RECHO
> > > > > >> > > > testfiles'g641'[load'test/tsu.ijs'"
> > > > > >> > > > see: tsu_notes, tsu_usage, tsu_pacman, and tsu_jd
> > > > > >> > > >
> > > > > >> > > >RUN  ddall  NB. report scripts that fail
> > > > > >> > > >RECHO ddall NB. echo script names as run and final
> count of
> > > > > >> failures
> > > > > >> > > >
> > > > > >> > > > j9.5.0-beta8/j64avx2/linux/commercial/
> > > > > >> > > >
> www.jsoftware.com/2023-12-03T17:50:19/clang-14-0-6/SLEEF=1
> > > > > >

Re: [Jsource] thoughts about rewriting extended integer support

[bill lam]

Do you have any uncommitted changes in your computer?

On Mon, Dec 4, 2023 at 21:41 Raul Miller  wrote:

> Yes: 8e379fd90153baae7624401ddb1aaa16f3179cd4
>
> Very odd.
>
> --
> Raul
>
> --
> Raul
>
> On Mon, Dec 4, 2023 at 7:51 AM bill lam  wrote:
> >
> > I tested on apple m1 and the following 3 tests failed.
> > g641
> > gqco
> > gxco1
> >
> > The sha1 for the latest commit in the master branch is 8e379fd90153 , is
> > this the same on your machine?
> >
> > On Mon, Dec 4, 2023 at 3:54 PM bill lam  wrote:
> >
> > > Nearly all platforms failed on GitHub action.
> > >
> > > On Mon, Dec 4, 2023 at 14:13 Raul Miller 
> wrote:
> > >
> > >> No errors, still, on my machine, for script/buildga.sh linux &&
> > >> script/testga.sh linux
> > >>
> > >> I don't know if this means that my machine is defective or deficient
> > >> in some way, of course.
> > >>
> > >> FYI,
> > >>
> > >> --
> > >> Raul
> > >>
> > >> On Mon, Dec 4, 2023 at 12:33 AM Raul Miller 
> > >> wrote:
> > >> >
> > >> > I tested on the master branch. I'll do a fresh compile and test
> again,
> > >> > though, since I've nothing better to do on this issue.
> > >> >
> > >> > Thanks,
> > >> >
> > >> > --
> > >> > Raul
> > >> >
> > >> > On Sun, Dec 3, 2023 at 11:28 PM bill lam 
> wrote:
> > >> > >
> > >> > > Are you two both testing on the master branch?
> > >> > >
> > >> > > On Mon, Dec 4, 2023 at 12:02 Raul Miller 
> > >> wrote:
> > >> > >
> > >> > > > I have been unable to reproduce this issue.
> > >> > > >
> > >> > > > $ time j64/jconsole -lib libjavx2.so -js "exit i.0[RECHO
> > >> > > > testfiles'g641'[load'test/tsu.ijs'"
> > >> > > > see: tsu_notes, tsu_usage, tsu_pacman, and tsu_jd
> > >> > > >
> > >> > > >RUN  ddall  NB. report scripts that fail
> > >> > > >RECHO ddall NB. echo script names as run and final count of
> > >> failures
> > >> > > >
> > >> > > > j9.5.0-beta8/j64avx2/linux/commercial/
> > >> > > > www.jsoftware.com/2023-12-03T17:50:19/clang-14-0-6/SLEEF=1
> > >> > > > cpu x86_64 cores 4
> > >> > > > /mnt/c/Other/jsoftware/jsource/test/g641.ijs
> > >> > > >
> > >> > > > real0m7.961s
> > >> > > > user0m0.201s
> > >> > > > sys 0m1.803s
> > >> > > >
> > >> > > > FYI,
> > >> > > >
> > >> > > > --
> > >> > > > Raul
> > >> > > >
> > >> > > >
> > >> > > > On Sun, Dec 3, 2023 at 8:02 PM Bill Heagy 
> wrote:
> > >> > > > >
> > >> > > > > JVERSION
> > >> > > > > Engine: j9.5.0-beta8/j64avx2/linux
> > >> > > > > Build: GPL3/2023-12-03T19:45:50/clang-16-0-6/SLEEF=1
> > >> > > > > Library: 9.5.5
> > >> > > > > Platform: Linux 64
> > >> > > > > Installer: unknown
> > >> > > > > InstallPath: /home/wheagy/git/jsource/jlibrary
> > >> > > > > Contact: unknown
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > .
> > >> > > > > 'domain error' -: 2 ?. etx 2 3;4 5
> > >> > > > > 1
> > >> > > > > 'domain error' -: 2 ?.~etx 2 3;4 5
> > >> > > > > 1
> > >> > > > >
> > >> > > > > 'domain error' -: ?.~@(*/) etx 'abc'
> > >> > > > > 1
> > >> > > > >
> > >> > > > > 'length error' -: 2 3 ?. etx 4 5 6
> > >> > > > > 1
> > >> > > > >
> > >> > > > > 270869761 1880044261 -: q: 509247139646491621x
> > >> > > > > |nonce error in ex02, executing monad q:
> > >> > > > > |this compu

Re: [Jsource] thoughts about rewriting extended integer support

[bill lam]

I tested on apple m1 and the following 3 tests failed.
g641
gqco
gxco1

The sha1 for the latest commit in the master branch is 8e379fd90153 , is
this the same on your machine?

On Mon, Dec 4, 2023 at 3:54 PM bill lam  wrote:

> Nearly all platforms failed on GitHub action.
>
> On Mon, Dec 4, 2023 at 14:13 Raul Miller  wrote:
>
>> No errors, still, on my machine, for script/buildga.sh linux &&
>> script/testga.sh linux
>>
>> I don't know if this means that my machine is defective or deficient
>> in some way, of course.
>>
>> FYI,
>>
>> --
>> Raul
>>
>> On Mon, Dec 4, 2023 at 12:33 AM Raul Miller 
>> wrote:
>> >
>> > I tested on the master branch. I'll do a fresh compile and test again,
>> > though, since I've nothing better to do on this issue.
>> >
>> > Thanks,
>> >
>> > --
>> > Raul
>> >
>> > On Sun, Dec 3, 2023 at 11:28 PM bill lam  wrote:
>> > >
>> > > Are you two both testing on the master branch?
>> > >
>> > > On Mon, Dec 4, 2023 at 12:02 Raul Miller 
>> wrote:
>> > >
>> > > > I have been unable to reproduce this issue.
>> > > >
>> > > > $ time j64/jconsole -lib libjavx2.so -js "exit i.0[RECHO
>> > > > testfiles'g641'[load'test/tsu.ijs'"
>> > > > see: tsu_notes, tsu_usage, tsu_pacman, and tsu_jd
>> > > >
>> > > >RUN  ddall  NB. report scripts that fail
>> > > >RECHO ddall NB. echo script names as run and final count of
>> failures
>> > > >
>> > > > j9.5.0-beta8/j64avx2/linux/commercial/
>> > > > www.jsoftware.com/2023-12-03T17:50:19/clang-14-0-6/SLEEF=1
>> > > > cpu x86_64 cores 4
>> > > > /mnt/c/Other/jsoftware/jsource/test/g641.ijs
>> > > >
>> > > > real0m7.961s
>> > > > user0m0.201s
>> > > > sys 0m1.803s
>> > > >
>> > > > FYI,
>> > > >
>> > > > --
>> > > > Raul
>> > > >
>> > > >
>> > > > On Sun, Dec 3, 2023 at 8:02 PM Bill Heagy  wrote:
>> > > > >
>> > > > > JVERSION
>> > > > > Engine: j9.5.0-beta8/j64avx2/linux
>> > > > > Build: GPL3/2023-12-03T19:45:50/clang-16-0-6/SLEEF=1
>> > > > > Library: 9.5.5
>> > > > > Platform: Linux 64
>> > > > > Installer: unknown
>> > > > > InstallPath: /home/wheagy/git/jsource/jlibrary
>> > > > > Contact: unknown
>> > > > >
>> > > > >
>> > > > >
>> > > > > .
>> > > > > 'domain error' -: 2 ?. etx 2 3;4 5
>> > > > > 1
>> > > > > 'domain error' -: 2 ?.~etx 2 3;4 5
>> > > > > 1
>> > > > >
>> > > > > 'domain error' -: ?.~@(*/) etx 'abc'
>> > > > > 1
>> > > > >
>> > > > > 'length error' -: 2 3 ?. etx 4 5 6
>> > > > > 1
>> > > > >
>> > > > > 270869761 1880044261 -: q: 509247139646491621x
>> > > > > |nonce error in ex02, executing monad q:
>> > > > > |this computation is not yet supported
>> > > > > |   270869761 1880044261-:q:509247139646491621x
>> > > > > |[-66] /home/wheagy/git/jsource/test/g641.ijs
>> > > > >
>> > > > > On 12/3/23 19:11, Raul Miller wrote:
>> > > > > > Ok, changes pushed. I believe I've a working update for
>> jtxplus, and I
>> > > > > > believe it's portable to all supported architectures.
>> > > > > >
>> > > > > > I'll keep an eye out for issues. If all goes well, I intend to
>> start
>> > > > > > working through some of the other X primitives (and,
>> eventually, the
>> > > > > > RAT primitives). If I have to hold off at some point for release
>> > > > > > management purposes, I think that that should be fine - this
>> effort
>> > > > > > can be completed in J9.6 or whenever.
>> > > > > >
>> > > > > > Thanks,
>> > > > > >
>> > > > >
>> --
>> > > > > 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

Re: [Jsource] thoughts about rewriting extended integer support

[bill lam]

Nearly all platforms failed on GitHub action.

On Mon, Dec 4, 2023 at 14:13 Raul Miller  wrote:

> No errors, still, on my machine, for script/buildga.sh linux &&
> script/testga.sh linux
>
> I don't know if this means that my machine is defective or deficient
> in some way, of course.
>
> FYI,
>
> --
> Raul
>
> On Mon, Dec 4, 2023 at 12:33 AM Raul Miller  wrote:
> >
> > I tested on the master branch. I'll do a fresh compile and test again,
> > though, since I've nothing better to do on this issue.
> >
> > Thanks,
> >
> > --
> > Raul
> >
> > On Sun, Dec 3, 2023 at 11:28 PM bill lam  wrote:
> > >
> > > Are you two both testing on the master branch?
> > >
> > > On Mon, Dec 4, 2023 at 12:02 Raul Miller 
> wrote:
> > >
> > > > I have been unable to reproduce this issue.
> > > >
> > > > $ time j64/jconsole -lib libjavx2.so -js "exit i.0[RECHO
> > > > testfiles'g641'[load'test/tsu.ijs'"
> > > > see: tsu_notes, tsu_usage, tsu_pacman, and tsu_jd
> > > >
> > > >RUN  ddall  NB. report scripts that fail
> > > >RECHO ddall NB. echo script names as run and final count of
> failures
> > > >
> > > > j9.5.0-beta8/j64avx2/linux/commercial/
> > > > www.jsoftware.com/2023-12-03T17:50:19/clang-14-0-6/SLEEF=1
> > > > cpu x86_64 cores 4
> > > > /mnt/c/Other/jsoftware/jsource/test/g641.ijs
> > > >
> > > > real0m7.961s
> > > > user0m0.201s
> > > > sys 0m1.803s
> > > >
> > > > FYI,
> > > >
> > > > --
> > > > Raul
> > > >
> > > >
> > > > On Sun, Dec 3, 2023 at 8:02 PM Bill Heagy  wrote:
> > > > >
> > > > > JVERSION
> > > > > Engine: j9.5.0-beta8/j64avx2/linux
> > > > > Build: GPL3/2023-12-03T19:45:50/clang-16-0-6/SLEEF=1
> > > > > Library: 9.5.5
> > > > > Platform: Linux 64
> > > > > Installer: unknown
> > > > > InstallPath: /home/wheagy/git/jsource/jlibrary
> > > > > Contact: unknown
> > > > >
> > > > >
> > > > >
> > > > > .
> > > > > 'domain error' -: 2 ?. etx 2 3;4 5
> > > > > 1
> > > > > 'domain error' -: 2 ?.~etx 2 3;4 5
> > > > > 1
> > > > >
> > > > > 'domain error' -: ?.~@(*/) etx 'abc'
> > > > > 1
> > > > >
> > > > > 'length error' -: 2 3 ?. etx 4 5 6
> > > > > 1
> > > > >
> > > > > 270869761 1880044261 -: q: 509247139646491621x
> > > > > |nonce error in ex02, executing monad q:
> > > > > |this computation is not yet supported
> > > > > |   270869761 1880044261-:q:509247139646491621x
> > > > > |[-66] /home/wheagy/git/jsource/test/g641.ijs
> > > > >
> > > > > On 12/3/23 19:11, Raul Miller wrote:
> > > > > > Ok, changes pushed. I believe I've a working update for jtxplus,
> and I
> > > > > > believe it's portable to all supported architectures.
> > > > > >
> > > > > > I'll keep an eye out for issues. If all goes well, I intend to
> start
> > > > > > working through some of the other X primitives (and, eventually,
> the
> > > > > > RAT primitives). If I have to hold off at some point for release
> > > > > > management purposes, I think that that should be fine - this
> effort
> > > > > > can be completed in J9.6 or whenever.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > >
> --
> > > > > 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

Re: [Jsource] thoughts about rewriting extended integer support

[bill lam]

Are you two both testing on the master branch?

On Mon, Dec 4, 2023 at 12:02 Raul Miller  wrote:

> I have been unable to reproduce this issue.
>
> $ time j64/jconsole -lib libjavx2.so -js "exit i.0[RECHO
> testfiles'g641'[load'test/tsu.ijs'"
> see: tsu_notes, tsu_usage, tsu_pacman, and tsu_jd
>
>RUN  ddall  NB. report scripts that fail
>RECHO ddall NB. echo script names as run and final count of failures
>
> j9.5.0-beta8/j64avx2/linux/commercial/
> www.jsoftware.com/2023-12-03T17:50:19/clang-14-0-6/SLEEF=1
> cpu x86_64 cores 4
> /mnt/c/Other/jsoftware/jsource/test/g641.ijs
>
> real0m7.961s
> user0m0.201s
> sys 0m1.803s
>
> FYI,
>
> --
> Raul
>
>
> On Sun, Dec 3, 2023 at 8:02 PM Bill Heagy  wrote:
> >
> > JVERSION
> > Engine: j9.5.0-beta8/j64avx2/linux
> > Build: GPL3/2023-12-03T19:45:50/clang-16-0-6/SLEEF=1
> > Library: 9.5.5
> > Platform: Linux 64
> > Installer: unknown
> > InstallPath: /home/wheagy/git/jsource/jlibrary
> > Contact: unknown
> >
> >
> >
> > .
> > 'domain error' -: 2 ?. etx 2 3;4 5
> > 1
> > 'domain error' -: 2 ?.~etx 2 3;4 5
> > 1
> >
> > 'domain error' -: ?.~@(*/) etx 'abc'
> > 1
> >
> > 'length error' -: 2 3 ?. etx 4 5 6
> > 1
> >
> > 270869761 1880044261 -: q: 509247139646491621x
> > |nonce error in ex02, executing monad q:
> > |this computation is not yet supported
> > |   270869761 1880044261-:q:509247139646491621x
> > |[-66] /home/wheagy/git/jsource/test/g641.ijs
> >
> > On 12/3/23 19:11, Raul Miller wrote:
> > > Ok, changes pushed. I believe I've a working update for jtxplus, and I
> > > believe it's portable to all supported architectures.
> > >
> > > I'll keep an eye out for issues. If all goes well, I intend to start
> > > working through some of the other X primitives (and, eventually, the
> > > RAT primitives). If I have to hold off at some point for release
> > > management purposes, I think that that should be fine - this effort
> > > can be completed in J9.6 or whenever.
> > >
> > > Thanks,
> > >
> > --
> > 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

Re: [Jsource] thoughts about rewriting extended integer support

[bill lam]

I traced and got this simple sentence to crash.
_1x + 1x
123x

I suspect when result in plusXX is 0, it frees memory but forgets some
housekeeping flags. So the block is doubly freed in the next gc.

On Fri, Dec 1, 2023 at 10:07 Raul Miller  wrote:

> This seems to be the "source" of the audittstack "too many deletes" error:
>
> (gdb) p ttop
> $5 = (A *) 0x555a1660
> (gdb) p *ttop
> $6 = (A) 0x5586e240
> (gdb) p ttop[1]
> $7 = (A) 0x5586e240
> (gdb) p ttop[0]
> $8 = (A) 0x5586e240
>
> The same entry is on the stack twice (though AC(w) is 1).
>
> But this doesn't come after a direct update of "ttop" - it seems like
> a failure to properly clean up after the previous audittstack.
>
> So... how do I audit audittstack?
>
> Thanks,
>
> --
> Raul
>
> On Wed, Nov 29, 2023 at 7:50 PM Raul Miller  wrote:
> >
> > It looks like something in audittstack is changing AFLAG(w) for one of
> > my X values which was created in my updated jtxplus(). (These look
> > like rank 1 LIT values, usually with a shape significantly smaller
> > than AN(w) -- sometimes negative, though not in this example.)
> >
> > $1 = {kchain = {k = 64, chain = 0x40, globalst = 0x40, locpath =
> > 0x40}, flag = 8589934592, mback = {m = 93824992548456,
> > back = 0x555a1668, jobpyx = 0x555a1668, zaploc =
> > 0x555a1668, aarg = 0x555a1668}, tproxy = {t = 2,
> > proxychain = 0x2}, c = 1, n = 16, r = 1 '\001', filler = 0 '\000',
> > h = 354, origin = 0, lock = 0, s = {1}}
> >
> > Specifically, it changes from 0 to 2^33 (on intel 64 bit) between two
> > successive calls to audittstack with no memory allocations nor frees
> > between them (one in plusXX immediately before the call to jtxplus and
> > the other on the first line of jtxplus). Apparently 2^33 represents
> > two deletes and 0 represents 0 deletes, while AC(x) is 1, in both
> > cases.
> >
> > This suggests, in turn, that I have violated some assumption required
> > by the memory management system, though I'm not sure what that would
> > be. I'm using more-or-less stock GA to allocate the memory, and I
> > don't know where to look to isolate this kind of problem.
> >
> > I guess I do have tactics to eventually isolate this kind of thing.
> > But, it's slow going. So, I'm leaving this note here in case it
> > reminds anyone of a plausibly relevant issue.
> >
> > Thanks,
> >
> > --
> > Raul
> >
> > On Mon, Nov 27, 2023 at 11:06 PM Raul Miller 
> wrote:
> > >
> > > Here's what my stack looks like at the point of failure:
> > >
> > > #0  0x7293a2ae in auditsimdelete (jt=0x71438200,
> > > w=0x5586e240) at ../../../../jsrc/m.c:553
> > > #1  0x72939b14 in audittstack (jt=0x71438200) at
> > > ../../../../jsrc/m.c:648
> > > #2  0x72e753e3 in jtxplus (jt=0x71438200,
> > > a=0x55651240, w=0x55651060) at ../../../../jsrc/vx.c:60
> > > #3  0x72e7c2b6 in plusXX (n=-50, m=1, x=0x55768940,
> > > y=0x556d17a8, z=0x556cfda0, jt=0x71438200)
> > > at ../../../../jsrc/vx.c:368
> > > #4  0x72a0538a in jtva2 (jt=0x71438200, a=0x55768900,
> > > w=0x556d1600, self=0x73a28580 ,
> > > allranks=131072) at ../../../../jsrc/va2.c:749
> > > #5  0x72a01ffa in jtatomic2 (jt=0x71438200,
> > > a=0x55769080, w=0x556d1600, self=0x73a28580
> > > )
> > > at ../../../../jsrc/va2.c:1276
> > > #6  0x72944b6c in jtparsea (jt=0x71438200,
> > > queue=0x5571eda8, nwds=21) at ../../../../jsrc/p.c:785
> > > #7  0x72943314 in jtparse (jt=0x71438200,
> > > w=0x5571ed00) at ../../../../jsrc/p.c:290
> > > #8  0x72951c95 in jtimmex (jt=0x71438200,
> > > w=0x5571ed00) at ../../../../jsrc/px.c:54
> > >
> > > The line number for plusXX in vx.c will be one greater than the line
> > > number in the gmp-redo-messy branch, because I have added a line
> > > immediately before it:
> > >
> > > 366 {if(MEMAUDIT&2)audittstack(jt);}
> > > 367   void *previous= *z;
> > > 368   *z++= jtxplus(jt,(u),(v));
> > > 369 {if(MEMAUDIT&2)audittstack(jt);}
> > >
> > > The value of previous (and of *z) is 0. So, my thought in adding that
> > > line was useless, because the error happens before *z gets updated and
> > > before z gets updated.
> > >
> > > As best as I  understand it, the only difference between line 366 here
> > > and the first line of jtxplus is the creation of a new stack frame for
> > > the jtxplus invocation.
> > >
> > > (And, I'm having difficulty reasoning about how that could cause
> > > audittstack to fail...)
> > >
> > > --
> > > Raul
> > >
> > > On Mon, Nov 27, 2023 at 9:44 PM Henry Rich 
> wrote:
> > > >
> > > > I think you're telling me to check out the gmp-redo-messy branch.
> Then
> > > > what do I look at?  What is the failing line?
> > > >
> > > > hhr
> > > >
> > > > On 11/27/2023 8:17 PM, Raul Miller wrote:
> > > > > Ok.
> > > > >
> > > > > I've eliminated jmpn_com as a 

Re: [Jsource] thoughts about rewriting extended integer support

[bill lam]

Have you fixed segfault on 1x when adding the line
if(unlikely(ISGMP(w)) SEGFAULT; // do not free libgmp managed memory here


On Mon, Nov 6, 2023 at 21:36 Raul Miller  wrote:

> So...
>
> It turns out that it's fairly easy to find a simple example of this
> problem.
>
> In m.c, add:
> if(unlikely(ISGMP(w)) SEGFAULT; // do not free libgmp managed memory here
>
> as the first line of jtmf. This will crash on i.10x
>
> That said, replacing the SEGFAULT with {gmpfree(w);R;} or (since ja.h
> isn't available here) its definition, changing x for w), still results
> in a crash, it just takes longer.
>
> This behavior roughly matches an earlier suspicion (that the decision
> to use the gmp deallocator vs the j deallocator was being bypassed -
> that there was an assumption that all members of an XNUM (or a RAT)
> were constructed using the same allocator), but I don't know my way
> around the memory management code to see where I should be looking to
> find this decision.
>
> That said, also, I was expecting a segfault in the gmp deallocator,
> not in m.c, but that corresponding SEGFAULT doesn't seem to trigger.
>
> So... do you have any suggestions on how I should approach looking in
> m.c to find the assumptions about homogeneous XNUMs that I'm breaking?
>
> (My current level of ignorance on this subject feels like the kind of
> architectural detail ignorance that routinely trips people up in many,
> many "enterprise" contexts. I can presumably work through it by
> performing inspection and experiments, but it seems more fruitful to
> just ask.)
>
> Thanks,
>
> --
> Raul
>
>
> On Fri, Nov 3, 2023 at 6:22 PM Raul Miller  wrote:
> >
> > This sounds like a good plan.
> >
> > Unfortunately, my machine is crashing (and sometimes failing to
> > reboot) just doing step 1.
> >
> > So I'm not even sure that the problem I'm encountering is a problem in
> > my changes - it might be a problem in my machine. (That said, my code
> > is still the prime suspect.)
> >
> > So... I've pushed a copy of my changes to a new branch (gmp-redo0).
> > This is partially to guard against a complete loss of my machine, and
> > partially to give someone else a chance of looking at the problem.
> >
> > I've not given up, but I have expanded the scope of my concerns, which
> > is going to slow me down.
> >
> > FYI,
> >
> > --
> > Raul
> >
> > On Fri, Nov 3, 2023 at 1:41 PM Henry Rich  wrote:
> > >
> > > You have an unknown memory corruption running the test suite. This is
> how I
> > > debug those:
> > >
> > > 1. RECHO ddall to see where it crashes.
> > > 2. Run the scripts before the crash to see if you can crash with a
> shorter
> > > run
> > > 3. When you have the crash as small as you can, set MEMAUDIT to 1d and
> see
> > > if you get an audit failure.
> > > 4. Once you get an audit failure you want to increase the frequency of
> > > audits. This is where 6!:5 (1) comes in. Once you execute that, it
> audits
> > > the free pool very frequently. That slows things down so you want to
> set it
> > > as close to the actual error as possible.
> > > 5. When you have found the first failure, it will be soon after the
> errant
> > > code. Add calls to auditmemchains liberally until you have isolated the
> > > error line.
> > > 6. If at any point you need to know what J sentence is executing, set
> > > TRACKINFO to 1 and look at the name track* in any routine that defines
> > > them.
> > >
> > > hhr
> > >
> > > On Fri, Nov 3, 2023, 5:15 PM Raul Miller 
> wrote:
> > >
> > > > Can you give me some hints on using 6!:5?
> > > >
> > > > I don't see any comments on jtpeekdata, and I haven't visualized what
> > > > I'd be looking for, nor when, for that matter.
> > > >
> > > > I got the 0xdeadbeef stuff running MEMAUDIT=0xd.
> > > >
> > > > I was running MEMAUDIT=0xff overnight, to see if I could catch the
> > > > problem earlier, but my machine rebooted. I don't know if that was
> > > > windows update or if that was some other issue. I'll give it another
> > > > shot.
> > > >
> > > > Basically, though, this isn't a problem which I've figured out a good
> > > > way of triggering, so it's slow going.
> > > >
> > > > --
> > > > Raul
> > > >
> > > >
> > > > On Fri, Nov 3, 2023 at 6:18 AM Henry Rich 
> wrote:
> > > > >
> > > > > Set MEMAUDIT and 6!:5 to see where the free chain is corrupted.
> > > > >
> > > > > hhr
> > > > >
> > > > > On Thu, Nov 2, 2023, 3:32 PM Raul Miller 
> wrote:
> > > > >
> > > > > > This is turning out to be more difficult than I had anticipated.
> > > > > >
> > > > > > I've modified jtxplus to use mpn_add (and mpn_sub and a macro
> > > > > > workalike for the inlined mpn_neg, which in turn uses mpn_com -
> > > > > > necessary because the mpn_ family of routines works on unsigned
> limb
> > > > > > sequences). And, it *mostly* works.
> > > > > >
> > > > > > However, when running script/testga.sh, I encounter a double free
> > > > problem.
> > > > > >
> > > > > > My current best guess is that somewhere I'm relying on a
> container
> > 

Re: [Jsource] testing issues

[bill lam]

@Raul Thank you for your suggestion. I have pushed a patch to fix force
macro emulation for some avx emulation. Please test again.

On Sat, Oct 28, 2023 at 8:35 PM Raul Miller  wrote:

> Another workaround occurs to me:
>
> When compiling with -O0, only build the avx2 instance of jconsole.
>
> The /bin/sh test for -O0:
>
> case "$CFLAGS" in *-O0*) true;; *) false;; esac
>
> This could be used as is, as the control statement for a shell if
> statement. Though I'd like to restructure the script/buildga.sh script
> for conciseness and readability if I do this, if that would be ok.
>
> That said, I don't know where your efforts to fix the emulation issue are.
>
> Thanks,
>
> --
> Raul
>
> On Thu, Oct 26, 2023 at 10:53 AM bill lam  wrote:
> >
> > I can reproduce the asm error. I suspect the problem is that the
> particular
> > intel asm instruction only supports immediate addressing for i (value
> known
> > during compilation time), but the argument was passed in as an inline
> > function parameter. The workaround is to replace the inline function with
> > macro call. I will work on it over the weekend.
> >
> > All files under the script are meant for the github action yaml. They are
> > intended for github runners, Developers should run test/tsu.ijs directly
> > after building binaries (using shell scripts under make2 on *nix or
> makevs
> > etc on windows) on their local machine.
> >
> > On Thu, Oct 26, 2023 at 10:16 PM Raul Miller 
> wrote:
> >
> > > Well.. I think a part of the answer is  .github/workflows/jsource.yml
> > >
> > > There's lots of things going on, and some of them are difficult to
> > > understand.
> > >
> > > For my purposes, I don't mind supplying linux on the command line. If
> > > I had enough machines, and wanted to automate based on uname, I guess
> > > I'd update the script with tr '[A-Z]' '[a-z]' or create a wrapper
> > > script which did that. (Probably a wrapper script, patterned after the
> > > github workflow yaml.)
> > >
> > > I guess the fundamental problems here are:
> > >
> > > (1) different platforms require entirely different build chains, and
> > >
> > > (2) our developer community is relatively isolated, and
> > >
> > > (3) it takes energy and time to implement working changes
> > >
> > > I guess maybe I should submit a patch for testga.sh to fix what seem
> > > to be obvious problems (the unquoted $1 and the local context for
> > > tests). I was hoping that bill could say a few words about the state
> > > of and/or plan for the script, though.
> > >
> > > Thanks,
> > >
> > > --
> > > Raul
> > >
> > > On Thu, Oct 26, 2023 at 9:36 AM 'Viktor Grigorov' via Source
> > >  wrote:
> > > >
> > > > On "9.5.0-beta6" the script has some issues. There are common to most
> > > the dash script I've seen in the zip and the main repo. Likely not
> what you
> > > are discussing, but worth mentioning, since you are trying to have a
> glibc
> > > unix release.
> > > >
> > > > I get
> > > >
> > > > script/testga.sh: line 16: [: =: unary operator expected
> > > > script/testga.sh: line 18: [: =: unary operator expected
> > > > script/testga.sh: line 22: [: =: unary operator expected
> > > > script/testga.sh: line 24: [: =: unary operator expected
> > > > script/testga.sh: line 26: [: =: unary operator expected
> > > > argument is linux|darwin|raspberry|openbsd|freebsd|wasm
> > > >
> > > > when running sans argument. $1 isn't doubly quoted on those lines.
> > > >
> > > > Running with an argument of linux---why lowercase when uname returns
> it
> > > capitalized..?---I get that j64 cannot be accessed. This is because it
> is
> > > suffixed with avx or avx2 or avx512. Symlinking my version to j64/ and
> > > running again, it cannot stat 'mpir/linux/x86_64/libgmpd.so'. I have
> only
> > > one such named file in mpir/linux/i386/. I don't know whether I can
> test
> > > whether I have extended integers, since I haven't got the library
> working
> > > yet, but any x prepended to an integer doesn't cause an issue. Whatever
> > > libgmpd.so does in addition to libgmp.so is beyond me currently.
> > > >
> > > > Could provide more info, if desired.
> > > >
> > > > Oct 26, 2023, 15:46 by rauldmil...@gmail.com:
> > 

Re: [Jsource] testing issues

[bill lam]

Please feel free to commit the fix. Thanks.

On Fri, 27 Oct 2023 at 7:09 AM Raul Miller  wrote:

> I think I could do a fix, if that would be desirable.
>
> --
> Raul
>
> On Thu, Oct 26, 2023 at 7:07 PM bill lam  wrote:
> >
> > Linux failed to compile on github at least since last month but I haven't
> > gotten the chance to fix it yet. So that I don't know any workaround are
> > needed for test scripts on gitglhub. Making testga working outside github
> > runners is low priority for me right now.
> >
> > On Fri, 27 Oct 2023 at 7:01 AM Raul Miller 
> wrote:
> >
> > > This is sufficient to trigger the error:
> > >
> > > j64/jconsole script/testga.ijs
> > >
> > > And, script/testga.ijs uses RUN4 ddall at the top level.
> > >
> > > I imagine a workaround would use a latent sentence, so that RUN4
> > > doesn't execute till after testga.ijs finishes.
> > >
> > > --
> > > Raul
> > >
> > >
> > > On Thu, Oct 26, 2023 at 6:18 PM Henry Rich 
> wrote:
> > > >
> > > > I'm totally guessing, but if you have a script that has
> > > >
> > > > t =. 2
> > > > t =: 3
> > > >
> > > > it will fail if loaded with load but not with 0!:1 .
> > > >
> > > > hhr
> > > >
> > > > On 10/26/2023 5:51 PM, Raul Miller wrote:
> > > > > How does github yaml avoid the local context which triggered that
> > > > > "public assignment to a name with a private value" error?
> > > > >
> > > > > Thanks,
> > > > >
> > > >
> > > >
> --
> > > > 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

Re: [Jsource] testing issues

[bill lam]

Linux failed to compile on github at least since last month but I haven't
gotten the chance to fix it yet. So that I don't know any workaround are
needed for test scripts on gitglhub. Making testga working outside github
runners is low priority for me right now.

On Fri, 27 Oct 2023 at 7:01 AM Raul Miller  wrote:

> This is sufficient to trigger the error:
>
> j64/jconsole script/testga.ijs
>
> And, script/testga.ijs uses RUN4 ddall at the top level.
>
> I imagine a workaround would use a latent sentence, so that RUN4
> doesn't execute till after testga.ijs finishes.
>
> --
> Raul
>
>
> On Thu, Oct 26, 2023 at 6:18 PM Henry Rich  wrote:
> >
> > I'm totally guessing, but if you have a script that has
> >
> > t =. 2
> > t =: 3
> >
> > it will fail if loaded with load but not with 0!:1 .
> >
> > hhr
> >
> > On 10/26/2023 5:51 PM, Raul Miller wrote:
> > > How does github yaml avoid the local context which triggered that
> > > "public assignment to a name with a private value" error?
> > >
> > > Thanks,
> > >
> >
> > --
> > 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

Re: [Jsource] testing issues

[bill lam]

I don't know. IIRC This had never happened in github action.

On Fri, 27 Oct 2023 at 5:52 AM Raul Miller  wrote:

> How does github yaml avoid the local context which triggered that
> "public assignment to a name with a private value" error?
>
> Thanks,
>
> --
> Raul
>
> On Thu, Oct 26, 2023 at 10:53 AM bill lam  wrote:
> >
> > I can reproduce the asm error. I suspect the problem is that the
> particular
> > intel asm instruction only supports immediate addressing for i (value
> known
> > during compilation time), but the argument was passed in as an inline
> > function parameter. The workaround is to replace the inline function with
> > macro call. I will work on it over the weekend.
> >
> > All files under the script are meant for the github action yaml. They are
> > intended for github runners, Developers should run test/tsu.ijs directly
> > after building binaries (using shell scripts under make2 on *nix or
> makevs
> > etc on windows) on their local machine.
> >
> > On Thu, Oct 26, 2023 at 10:16 PM Raul Miller 
> wrote:
> >
> > > Well.. I think a part of the answer is  .github/workflows/jsource.yml
> > >
> > > There's lots of things going on, and some of them are difficult to
> > > understand.
> > >
> > > For my purposes, I don't mind supplying linux on the command line. If
> > > I had enough machines, and wanted to automate based on uname, I guess
> > > I'd update the script with tr '[A-Z]' '[a-z]' or create a wrapper
> > > script which did that. (Probably a wrapper script, patterned after the
> > > github workflow yaml.)
> > >
> > > I guess the fundamental problems here are:
> > >
> > > (1) different platforms require entirely different build chains, and
> > >
> > > (2) our developer community is relatively isolated, and
> > >
> > > (3) it takes energy and time to implement working changes
> > >
> > > I guess maybe I should submit a patch for testga.sh to fix what seem
> > > to be obvious problems (the unquoted $1 and the local context for
> > > tests). I was hoping that bill could say a few words about the state
> > > of and/or plan for the script, though.
> > >
> > > Thanks,
> > >
> > > --
> > > Raul
> > >
> > > On Thu, Oct 26, 2023 at 9:36 AM 'Viktor Grigorov' via Source
> > >  wrote:
> > > >
> > > > On "9.5.0-beta6" the script has some issues. There are common to most
> > > the dash script I've seen in the zip and the main repo. Likely not
> what you
> > > are discussing, but worth mentioning, since you are trying to have a
> glibc
> > > unix release.
> > > >
> > > > I get
> > > >
> > > > script/testga.sh: line 16: [: =: unary operator expected
> > > > script/testga.sh: line 18: [: =: unary operator expected
> > > > script/testga.sh: line 22: [: =: unary operator expected
> > > > script/testga.sh: line 24: [: =: unary operator expected
> > > > script/testga.sh: line 26: [: =: unary operator expected
> > > > argument is linux|darwin|raspberry|openbsd|freebsd|wasm
> > > >
> > > > when running sans argument. $1 isn't doubly quoted on those lines.
> > > >
> > > > Running with an argument of linux---why lowercase when uname returns
> it
> > > capitalized..?---I get that j64 cannot be accessed. This is because it
> is
> > > suffixed with avx or avx2 or avx512. Symlinking my version to j64/ and
> > > running again, it cannot stat 'mpir/linux/x86_64/libgmpd.so'. I have
> only
> > > one such named file in mpir/linux/i386/. I don't know whether I can
> test
> > > whether I have extended integers, since I haven't got the library
> working
> > > yet, but any x prepended to an integer doesn't cause an issue. Whatever
> > > libgmpd.so does in addition to libgmp.so is beyond me currently.
> > > >
> > > > Could provide more info, if desired.
> > > >
> > > > Oct 26, 2023, 15:46 by rauldmil...@gmail.com:
> > > >
> > > > > I understand the error message in g13x.ijs
> > > > >
> > > > > I guess the question is: is script/testga.sh used anywhere (it sure
> > > > > looks like it's intended to be used broadly)? If so, why don't
> other
> > > > > people get this error?
> > > > >
> > > > > I haven't changed anything about the testing process.
> > &g

Re: [Jsource] testing issues

[bill lam]

I can reproduce the asm error. I suspect the problem is that the particular
intel asm instruction only supports immediate addressing for i (value known
during compilation time), but the argument was passed in as an inline
function parameter. The workaround is to replace the inline function with
macro call. I will work on it over the weekend.

All files under the script are meant for the github action yaml. They are
intended for github runners, Developers should run test/tsu.ijs directly
after building binaries (using shell scripts under make2 on *nix or makevs
etc on windows) on their local machine.

On Thu, Oct 26, 2023 at 10:16 PM Raul Miller  wrote:

> Well.. I think a part of the answer is  .github/workflows/jsource.yml
>
> There's lots of things going on, and some of them are difficult to
> understand.
>
> For my purposes, I don't mind supplying linux on the command line. If
> I had enough machines, and wanted to automate based on uname, I guess
> I'd update the script with tr '[A-Z]' '[a-z]' or create a wrapper
> script which did that. (Probably a wrapper script, patterned after the
> github workflow yaml.)
>
> I guess the fundamental problems here are:
>
> (1) different platforms require entirely different build chains, and
>
> (2) our developer community is relatively isolated, and
>
> (3) it takes energy and time to implement working changes
>
> I guess maybe I should submit a patch for testga.sh to fix what seem
> to be obvious problems (the unquoted $1 and the local context for
> tests). I was hoping that bill could say a few words about the state
> of and/or plan for the script, though.
>
> Thanks,
>
> --
> Raul
>
> On Thu, Oct 26, 2023 at 9:36 AM 'Viktor Grigorov' via Source
>  wrote:
> >
> > On "9.5.0-beta6" the script has some issues. There are common to most
> the dash script I've seen in the zip and the main repo. Likely not what you
> are discussing, but worth mentioning, since you are trying to have a glibc
> unix release.
> >
> > I get
> >
> > script/testga.sh: line 16: [: =: unary operator expected
> > script/testga.sh: line 18: [: =: unary operator expected
> > script/testga.sh: line 22: [: =: unary operator expected
> > script/testga.sh: line 24: [: =: unary operator expected
> > script/testga.sh: line 26: [: =: unary operator expected
> > argument is linux|darwin|raspberry|openbsd|freebsd|wasm
> >
> > when running sans argument. $1 isn't doubly quoted on those lines.
> >
> > Running with an argument of linux---why lowercase when uname returns it
> capitalized..?---I get that j64 cannot be accessed. This is because it is
> suffixed with avx or avx2 or avx512. Symlinking my version to j64/ and
> running again, it cannot stat 'mpir/linux/x86_64/libgmpd.so'. I have only
> one such named file in mpir/linux/i386/. I don't know whether I can test
> whether I have extended integers, since I haven't got the library working
> yet, but any x prepended to an integer doesn't cause an issue. Whatever
> libgmpd.so does in addition to libgmp.so is beyond me currently.
> >
> > Could provide more info, if desired.
> >
> > Oct 26, 2023, 15:46 by rauldmil...@gmail.com:
> >
> > > I understand the error message in g13x.ijs
> > >
> > > I guess the question is: is script/testga.sh used anywhere (it sure
> > > looks like it's intended to be used broadly)? If so, why don't other
> > > people get this error?
> > >
> > > I haven't changed anything about the testing process.
> > >
> > > (Meanwhile - if anyone else stumbles over this - it looks like there's
> > > a comment in avx-intremu.h explaining the error and what to do about
> > > it.)
> > >
> > > Thanks,
> > >
> > > --
> > > Raul
> > >
> > >
> > > On Thu, Oct 26, 2023 at 5:29 AM Henry Rich 
> wrote:
> > >
> > >>
> > >> I have nothing on the asm problem.
> > >>
> > >> On the other, the error is just what it looks like: you are publicly
> > >> assigning a name that was previously assigned privately. The scripts
> are
> > >> sometimes loaded under an explicit definition, sometimes not, so =. is
> > >> unpredictable.
> > >>
> > >> hhr
> > >>
> > >> On Thu, Oct 26, 2023, 1:34 AM Raul Miller 
> wrote:
> > >>
> > >> > I'm testing out a change to the support for extended integers, and
> > >> > I've run across what seems like an unrelated issue in g13x.ijs, when
> > >> > running script/testga.sh linux:
> > >> >
> > >> >NB. 13!:13
> > >> > -
> > >> >
> > >> >mean=: sum % #
> > >> >sum =: [: +/ ".@('t=:13!:13 $0'&[) ] ]
> > >> >
> > >> >13!:0 ]1
> > >> >1: mean x=: ?4 5$100
> > >> > |domain error: sum
> > >> > |public assignment to a name with a private value
> > >> > |   t=:13!:13$0
> > >> >
> > >> > Not sure what to do about this...
> > >> >
> > >> > Meanwhile, running test/tsu.ijs manually shows me an error with my
> > >> > changes. I'd like to use a debugger to inspect what's happening to
> > >> > cause that error. However, when I attempt to build for debugging, I
> > >> > get a 

Re: [Jsource] [Jbeta] Error in ? verb OR in NuVoc

[bill lam]

Just curious, if the underlying algorithm for random assume 32 or 64 bits,
how does it extend to xnum?

On Fri, Jun 16, 2023, 12:14 AM Raul Miller  wrote:

> I've pushed a fix for j32.
>
> I should also note that collisions between random numbers seem rare
> when the count of the numbers is significantly less than the square
> root of the magnitude of the range of the numbers.
>
>cols=: {{ x-#~.?x#y }}
>{{y cols 0 0 10 p. y}}"0(10^i.6)
> 0 0 0 0 0 0
>
> Both the j64 and the j32 estimators (the value of h in jtdeal) could
> be better. For j64, the estimator is too high for XNUMs in particular.
> For j32, the estimator is probably too low when using deal to generate
> extremely long sequences of XNUMS.
>
> --
> Raul
>
> On Thu, Jun 15, 2023 at 11:11 AM Raul Miller 
> wrote:
> >
> > Oh, right... thanks!
> >
> > (./clean.sh instead of make clean -- there's no Makefile in make2. I'm
> > rusty on this build system.)
> >
> > Thanks again,
> >
> > --
> > Raul
> >
> > On Thu, Jun 15, 2023 at 11:08 AM bill lam  wrote:
> > >
> > > There are artifacts of 64 bit objects. I suspect you use your own shell
> > > script instead of the make2/clean.sh to clean up.
> > >
> > >
> > > On Thu, 15 Jun 2023 at 10:58 PM Raul Miller 
> wrote:
> > >
> > > > Or... I would like to think I'm working on it.
> > > >
> > > > Unfortunately, building and testing a j32 instance on linux 64 bit os
> > > > is currently failing for me.
> > > >
> > > > I *think* that using the (make2) make clean, followed by setting
> > > > j64x=j32 and CFLAGS=-m32 (as exported environmental variables in my
> > > > shell) should be sufficient to build a 32 bit instance of J. However,
> > > > currently when I try this, my build fails to link because of 64 bit
> > > > artifacts in the build:
> > > >
> > > > https://gist.github.com/rdm/b48b4be3a6e57aeb1f071d079aec6745
> > > >
> > > > Any ideas on how I should fix this?
> > > >
> > > > Thanks,
> > > >
> > > > --
> > > > Raul
> > > >
> > > >
> > > > On Thu, Jun 15, 2023 at 10:44 AM Raul Miller 
> > > > wrote:
> > > > >
> > > > > The test works on j32, the patch fails.
> > > > >
> > > > > Working on it now,
> > > > >
> > > > > Thanks,
> > > > >
> > > > > --
> > > > > Raul
> > > > >
> > > > > On Thu, Jun 15, 2023 at 10:30 AM bill lam 
> wrote:
> > > > > >
> > > > > > github windows32 failed g600
> > > > > > 2023-06-15T14:17:26.0886637Z63 < >./ 2 ^. 5 ?
> > > > > > 2980293480239480239480239480239480239482039x
> > > > > > 2023-06-15T14:17:26.0886679Z 0
> > > > > >
> > > > > > Does the patch or test work on J32?
> > > > > >
> > > > > >
> > > > > > On Thu, Jun 15, 2023 at 10:14 PM Raul Miller <
> rauldmil...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > I've pushed a fix. The essence is
> > > > > > >
> https://github.com/jsoftware/jsource/blob/master/jsrc/vrand.c#L625
> > > > > > >
> > > > > > > It's been a while since I've concerned myself with the details
> of
> > > > > > > array allocation, so I'd like to verify that AT(z)= XNUM is
> valid
> > > > when
> > > > > > > z is a freshly allocated (and unpopulated) INT array. (The
> > > > alternative
> > > > > > > would be to free z and allocate a fresh array for z.)
> > > > > > >
> > > > > > > Note also that J's estimate of the number of values which need
> to be
> > > > > > > rolled here is a bit high. The value of h as calculated at
> > > > > > >
> https://github.com/jsoftware/jsource/blob/master/jsrc/vrand.c#L803
> > > > is
> > > > > > > 20 for the example where I need to deal 5 XNUMs. This is not
> > > > > > > incorrect, but it is an opportunity for an efficiency gain.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > --
> > > > > > >

Re: [Jsource] [Jbeta] Error in ? verb OR in NuVoc

[bill lam]

There are artifacts of 64 bit objects. I suspect you use your own shell
script instead of the make2/clean.sh to clean up.


On Thu, 15 Jun 2023 at 10:58 PM Raul Miller  wrote:

> Or... I would like to think I'm working on it.
>
> Unfortunately, building and testing a j32 instance on linux 64 bit os
> is currently failing for me.
>
> I *think* that using the (make2) make clean, followed by setting
> j64x=j32 and CFLAGS=-m32 (as exported environmental variables in my
> shell) should be sufficient to build a 32 bit instance of J. However,
> currently when I try this, my build fails to link because of 64 bit
> artifacts in the build:
>
> https://gist.github.com/rdm/b48b4be3a6e57aeb1f071d079aec6745
>
> Any ideas on how I should fix this?
>
> Thanks,
>
> --
> Raul
>
>
> On Thu, Jun 15, 2023 at 10:44 AM Raul Miller 
> wrote:
> >
> > The test works on j32, the patch fails.
> >
> > Working on it now,
> >
> > Thanks,
> >
> > --
> > Raul
> >
> > On Thu, Jun 15, 2023 at 10:30 AM bill lam  wrote:
> > >
> > > github windows32 failed g600
> > > 2023-06-15T14:17:26.0886637Z63 < >./ 2 ^. 5 ?
> > > 2980293480239480239480239480239480239482039x
> > > 2023-06-15T14:17:26.0886679Z 0
> > >
> > > Does the patch or test work on J32?
> > >
> > >
> > > On Thu, Jun 15, 2023 at 10:14 PM Raul Miller 
> wrote:
> > >
> > > > I've pushed a fix. The essence is
> > > > https://github.com/jsoftware/jsource/blob/master/jsrc/vrand.c#L625
> > > >
> > > > It's been a while since I've concerned myself with the details of
> > > > array allocation, so I'd like to verify that AT(z)= XNUM is valid
> when
> > > > z is a freshly allocated (and unpopulated) INT array. (The
> alternative
> > > > would be to free z and allocate a fresh array for z.)
> > > >
> > > > Note also that J's estimate of the number of values which need to be
> > > > rolled here is a bit high. The value of h as calculated at
> > > > https://github.com/jsoftware/jsource/blob/master/jsrc/vrand.c#L803
> is
> > > > 20 for the example where I need to deal 5 XNUMs. This is not
> > > > incorrect, but it is an opportunity for an efficiency gain.
> > > >
> > > > Thanks,
> > > >
> > > > --
> > > > Raul
> > > >
> > > >
> > > > On Thu, Jun 15, 2023 at 9:21 AM Raul Miller 
> wrote:
> > > > >
> > > > > Good eye, I had overlooked that problem.
> > > > >
> > > > > That said, it's worth noting that 5 ? 1e99 runs into the same
> issue.
> > > > > I'm not going to attempt a fix for that today. (But it's tempting
> to
> > > > > think about implementing that in a fashion which would provide a
> > > > > distribution which is equivalent to that which would be provided by
> > > > > (5 ?&.x: 1e99), once I have fixed this problem.)
> > > > >
> > > > > Anyways, I should have a fix up within a few hours.
> > > > >
> > > > > Thanks,
> > > > >
> > > > >
> > > > > --
> > > > > Raul
> > > > >
> > > > > On Thu, Jun 15, 2023 at 3:19 AM Henry Rich 
> wrote:
> > > > > >
> > > > > > That isn't sufficient, is it?  The random numbers will be drawn
> from i.
> > > > > > IMAX, won't they?  If not, it's OK.
> > > > > >
> > > > > > hhr
> > > > > >
> > > > > > On Wed, Jun 14, 2023, 11:28 PM Raul Miller <
> rauldmil...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > But that's not what i0() does:
> > > > > > >
> > > > > > > i0(1e99) returns IMAX
> > > > > > >
> > > > > > > Why should i0(x: 1e99) produce a domain error?
> > > > > > >
> > > > > > > Anyways, I've pushed a fix to jti0 for this issue.
> > > > > > >
> > > > > > > Please help me understand, if it's not acceptable.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > --
> > > > > > > Raul
> > > > > > >
> > > > > > > On Wed, Jun 14, 2023 at 4:46 PM Henry Rich <
&g

Re: [Jsource] [Jbeta] Error in ? verb OR in NuVoc

[bill lam]

github windows32 failed g600
2023-06-15T14:17:26.0886637Z63 < >./ 2 ^. 5 ?
2980293480239480239480239480239480239482039x
2023-06-15T14:17:26.0886679Z 0

Does the patch or test work on J32?


On Thu, Jun 15, 2023 at 10:14 PM Raul Miller  wrote:

> I've pushed a fix. The essence is
> https://github.com/jsoftware/jsource/blob/master/jsrc/vrand.c#L625
>
> It's been a while since I've concerned myself with the details of
> array allocation, so I'd like to verify that AT(z)= XNUM is valid when
> z is a freshly allocated (and unpopulated) INT array. (The alternative
> would be to free z and allocate a fresh array for z.)
>
> Note also that J's estimate of the number of values which need to be
> rolled here is a bit high. The value of h as calculated at
> https://github.com/jsoftware/jsource/blob/master/jsrc/vrand.c#L803 is
> 20 for the example where I need to deal 5 XNUMs. This is not
> incorrect, but it is an opportunity for an efficiency gain.
>
> Thanks,
>
> --
> Raul
>
>
> On Thu, Jun 15, 2023 at 9:21 AM Raul Miller  wrote:
> >
> > Good eye, I had overlooked that problem.
> >
> > That said, it's worth noting that 5 ? 1e99 runs into the same issue.
> > I'm not going to attempt a fix for that today. (But it's tempting to
> > think about implementing that in a fashion which would provide a
> > distribution which is equivalent to that which would be provided by
> > (5 ?&.x: 1e99), once I have fixed this problem.)
> >
> > Anyways, I should have a fix up within a few hours.
> >
> > Thanks,
> >
> >
> > --
> > Raul
> >
> > On Thu, Jun 15, 2023 at 3:19 AM Henry Rich  wrote:
> > >
> > > That isn't sufficient, is it?  The random numbers will be drawn from i.
> > > IMAX, won't they?  If not, it's OK.
> > >
> > > hhr
> > >
> > > On Wed, Jun 14, 2023, 11:28 PM Raul Miller 
> wrote:
> > >
> > > > But that's not what i0() does:
> > > >
> > > > i0(1e99) returns IMAX
> > > >
> > > > Why should i0(x: 1e99) produce a domain error?
> > > >
> > > > Anyways, I've pushed a fix to jti0 for this issue.
> > > >
> > > > Please help me understand, if it's not acceptable.
> > > >
> > > > Thanks,
> > > >
> > > > --
> > > > Raul
> > > >
> > > > On Wed, Jun 14, 2023 at 4:46 PM Henry Rich 
> wrote:
> > > > >
> > > > > The i0 gives domain error if the argument exceeds IMAX, which is
> what you
> > > > > are seeing.   This looks like a bug to me.  I think the algorithm
> for
> > > > deal
> > > > > would work if you just called roll with the extended arguments.
> Raul,
> > > > would
> > > > > you like to take that on?
> > > > >
> > > > > Henry Rich
> > > > >
> > > > > On Wed, Jun 14, 2023, 6:53 PM Raul Miller 
> wrote:
> > > > >
> > > > > > This error is coming from
> > > > > >
> > > > > > #0  jtjsignal (jt=0x77fc0200, e=3) at
> ../../../../jsrc/d.c:361
> > > > > > #1  0x734b131a in jtcvt () from
> > > > > >
> /mnt/c/cygwin64/home/15712/jsoftware/jsource/bin/linux/j64avx2/libj.so
> > > > > > #2  0x7350173e in jtvi (jt=0x77fc0200, w=0x4b4000) at
> > > > > > ../../../../jsrc/u.c:570
> > > > > > #3  0x73501562 in jti0 (jt=0x77fc0200, w=0x4b4000) at
> > > > > > ../../../../jsrc/u.c:238
> > > > > > #4  0x736fa6a1 in jtdeal (jt=0x77fc0200,
> a=0x73a3a680
> > > > > > , w=0x4b4000,
> > > > > > self=0x73a3b8c0 ) at
> ../../../../jsrc/vrand.c:794
> > > > > >
> > > > > > The issue seems to be the second i0 here
> > > > > >
> > > > > >  RE(m=i0(a)); RE(c=n=i0(w));  // c starts as max#+1
> > > > > >
> > > > > > In u.c, the comment on i0 is:
> > > > > >
> > > > > > // Extract the integer value from w, return it.  Set error if
> > > > > > non-integral or non-atomic.  Values whose abs > IMAX are
> converted to
> > > > > > IMAX/-IMAX
> > > > > >
> > > > > > I haven't yet figured out what's wrong with jti0 in this
> instance.
> > > > > >
> > > > > > FYI,
> > > > > >
> > > > > > --
> > > > > > Raul
> > > > > >
> > > > > > On Wed, Jun 14, 2023 at 11:54 AM 'Veter Kamenev' via Beta
> > > > > >  wrote:
> > > > > > >
> > > > > > > Hi!
> > > > > > >
> > > > > > > 5 ? 2980293480239480239480239480239480239482039x
> > > > > > >
> > > > > > > |domain error, executing dyad ?
> > > > > > > |y must be a positive integer
> > > > > > >
> > > > > > > I read in NuVoc:
> > > > > > >
> > > > > > > y   range of random number
> > > > > > > 0   floating-point value in interval (0,1)
> > > > > > > 1   0 (always)
> > > > > > > 2   Boolean
> > > > > > >  >1 integer or extended integer from list i.y
> > > > > > >
> > > > > > > https://code.jsoftware.com/wiki/Vocabulary/query#dyadic
> > > > > > >
> > > > > > > Best wishes,
> > > > > > > Veter
> > > > > > >
> > > >
> --
> > > > > > > For information about J forums see
> > > > http://www.jsoftware.com/forums.htm
> > > > > >
> --
> > > > > > For information about J forums see
> http://www.jsoftware.com/forums.htm
> > > > > >
> 

Re: [Jsource] Proposal: git short hash in JVERSION

[bill lam]

I think msys of windows git provides a friendlier environment than the dos
prompt but msys is mot mandatory for the working of windows git. A cmd file
can execute the git command if full path to git is supplied.

However what if users just download the zipped source code but didn't clone
the j source repository? Can they still build binaries?

On Wed, 12 Apr 2023 at 10:04 PM Raul Miller  wrote:

> git tags would be useful for rebuilding historic versions of J.
>
> However, in our current process, we do not necessarily create a tag as
> a part of a J release.
>
> So it would be nice if we retained enough information to retroactively
> tag a release.
>
> I think the best way of achieving this goal would be to include the
> git short hash (as provided by git rev-parse --short HEAD) in
> JVERSION.
>
> For example:
>
> echo "#define GITHASH $(git rev-parse --short HEAD)" >jsrc/githash.h
>
> And then #GITHASH would be a quoted string which could be exposed in
> the result of a !: verb.
>
> Accomplishing this in a .cmd file would be similar but I don't know
> enough about that environment. (Possibly, the implementation of git
> includes a mingw shell, which would support this exact same syntax?)
>
> Thanks,
>
> --
> Raul
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] control-C not trappable

[bill lam]

Which platform(s)?
Jconsole calls JInterrupt whenever ctrl-c/sigint is received. That's all I
knew.

On Tue, Mar 7, 2023 at 9:11 AM Raul Miller  wrote:

> In j903, attention interrupt in j console was trappable (using try. catch.)
>
> In j9.4, it was changed to deal with threading, and it also became
> untrappable.
>
> But there's no mention of the try.catch. behavior change in the
> release notes. So perhaps this change was unintentional?
>
> Thanks,
>
> --
> Raul
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] wd pshow vs wd qhwndc

[bill lam]

pshow post a message to event queue and returns. The window will be
realized and visible after cascaded events so pshow itself has no control
on it.

IMO in the spirit of event driven programming, it would better to have a
form_loaded event that you can query properties of the form or whatever you
want to do inside the event.


On Sat, 21 Jan 2023 at 6:17 PM Raul Miller  wrote:

> Doesn't asynchronous mean that pshow would show the window after the
> wd command exited?
>
> If so, would it make sense to have some sort of "continue" or
> "deferred" option on pshow, which would indicate that the developer is
> comfortable with pshow having a delayed effect rather than cancelling
> pending commands?
>
> Thanks,
>
> --
> Raul
>
>
> On Fri, Jan 20, 2023 at 11:51 AM bill lam  wrote:
> >
> > I think pshow is asynchronous because the underlying Qt function it calls
> > is also asynchronous.
> >
> > On Sat, Jan 21, 2023 at 12:14 AM Raul Miller 
> wrote:
> >
> > > https://github.com/jsoftware/qtide/blob/master/lib/wd/wd.cpp
> > >
> > > I'm looking at the implementation of wd, and I'm trying to figure out
> > > why I can't use both pshow and qhwndc in the same sequence of wd
> > > commands.
> > >
> > > Can anyone here help me understand this issue?
> > >
> > > Here's a demonstration:
> > >
> > > win_close=: {{ wd'pclose'}}
> > > echo wd {{)n
> > >   pc win;
> > >   minwh 300 300;
> > >   cc gl opengl flush;
> > >   pshow;
> > >   qhwndc gl;
> > > }}
> > >
> > > Here, there's no result from qhwndc.
> > >
> > > If the pshow line is moved below the qhwndc line, the child handle
> > > appears but the window no longer pops up.
> > >
> > > Of course, I can work around this issue using two invocations of wd --
> > > but I would like to understand why this is necessary. And, currently,
> > > I don't really know what I'm looking for. (Nor is this a documented
> > > issue, inthe command reference --
> > > https://code.jsoftware.com/wiki/Guides/Window_Driver/Command_Reference
> > > -- nor anywhere else that I've noticed.)
> > >
> > > Any insights would be appreciated.
> > >
> > > Thanks,
> > >
> > > --
> > > Raul
> > > --
> > > 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

Re: [Jsource] wd pshow vs wd qhwndc

[bill lam]

I think pshow is asynchronous because the underlying Qt function it calls
is also asynchronous.

On Sat, Jan 21, 2023 at 12:14 AM Raul Miller  wrote:

> https://github.com/jsoftware/qtide/blob/master/lib/wd/wd.cpp
>
> I'm looking at the implementation of wd, and I'm trying to figure out
> why I can't use both pshow and qhwndc in the same sequence of wd
> commands.
>
> Can anyone here help me understand this issue?
>
> Here's a demonstration:
>
> win_close=: {{ wd'pclose'}}
> echo wd {{)n
>   pc win;
>   minwh 300 300;
>   cc gl opengl flush;
>   pshow;
>   qhwndc gl;
> }}
>
> Here, there's no result from qhwndc.
>
> If the pshow line is moved below the qhwndc line, the child handle
> appears but the window no longer pops up.
>
> Of course, I can work around this issue using two invocations of wd --
> but I would like to understand why this is necessary. And, currently,
> I don't really know what I'm looking for. (Nor is this a documented
> issue, inthe command reference --
> https://code.jsoftware.com/wiki/Guides/Window_Driver/Command_Reference
> -- nor anywhere else that I've noticed.)
>
> Any insights would be appreciated.
>
> Thanks,
>
> --
> Raul
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] beta-i crash

[bill lam]

We already use github action to build binaries and run the test suite.

On Fri, Dec 16, 2022 at 12:12 AM Leonardo Sandoval 
wrote:

> as a side question: Is there a CI (Continuous Integration) system for J?
> Having a solid CI would detect regressions per commit, without finding
> surprises post release.
>
> In my job, I work in this area (CI); doing CI is basically 'free' for low
> volume testing at gitlab.com for example, for this implies having the J
> repo located there. I am also familiar with Jenkins, but this would require
> dedicated server(s) for the testing piece, which implies $$.
>
> On Thu, Dec 15, 2022 at 2:36 AM Raul Miller  wrote:
>
> > This crashes J for me (windows, jqt, beta-i):
> >
> >{{ {{ }} }} ''
> >
> > --
> > Raul
> > --
> > 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

Re: [Jsource] possibility for special code

[bill lam]

I agree with Raul, monad = is a primitive that represents a thinking model
inside human brain. It is just too resources consuming and should be used
where special code is supported. +/@= #@= etc are candidates.



On Wed, Dec 7, 2022, 3:02 AM Raul Miller  wrote:

> I disagree with your implicit suggestion that #@= would lead to smelly
> replacements for i.~
>
> --
> Raul
>
> On Tue, Dec 6, 2022 at 1:54 PM Henry Rich  wrote:
> >
> > = is unfortunately with us for keeps.  It's used a lot to create
> > identity matrices.
> >
> > I object to encouraging its use by having special code for #@= . I don't
> > want people to think about (= y), ever.  It raises a stench in the
> > nostrils of the Almighty.  I disown it.  It's shunned.
> >
> > Henry Rich
> >
> > On 12/6/2022 1:40 PM, Raul Miller wrote:
> > > Right -- my suggestion here would be that #@= would not produce the
> > > result of = but would instead generate the counts directly without
> > > generating the intermediate results.
> > >
> > > And yes i.~ and u/. give the same information more compactly, (but the
> > > equivalent expression involving i.~ would be >./@i.~ which is harder
> > > to read, so #@~. would be preferable).  and u/. assumes that we are
> > > using the bit vectors to compress an argument.
> > >
> > > Meanwhile, if you were to get rid of the monadic definition of = it
> > > would make sense to give it the nub operation in its place, leaving ~.
> > > in place (mapping it to CEQ instead of CNUB) for backwards
> > > compatibility. I would be hesitant to take that step (at the very
> > > least, I'd want to read through every published book on J to make sure
> > > I hadn't overlooked something important. For example, are there
> > > approaches to fractals where the current = monadic result is useful?)
> > >
> > > A general issue, in the context of the usefulness of primitives, is
> > > that any single application domain is going to tend to emphasize a
> > > handful of primitives, but an unrelated application domain would tend
> > > to emphasize a different handful.
> > >
> > > Anyways, this doesn't have to go out immediately or anything, but the
> > > argument that jtsclass() might be tossed is not necessarily an
> > > argument against my suggestion.
> > >
> > > Thanks,
> > >
> >
> > --
> > 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

Re: [Jsource] stress test for J

[bill lam]

I can get the crash under wine.
on linux debug

Program received signal SIGSEGV, Segmentation fault.
[84/4987]
jtgaf (jt=0x77f80200, blockx=6) at ../../../../jsrc/m.c:1301

1301   jt->mfree[-PMINL+1+blockx].pool = AFCHAIN(z);  // remove & use
the head of the free chain
Missing separate debuginfos, use: yum debuginfo-install
glibc-2.28-211.el8.x86_64 libedit-3.1-23.20170329cvs.el8.x86_64 libomp-1
4.0.6-2.module_el8.7.0+1198+0c3eb6e2.x86_64
ncurses-libs-6.1-9.20180224.el8.x86_64

(gdb) bt

#0  jtgaf (jt=0x77f80200, blockx=6) at ../../../../jsrc/m.c:1301

#1  0x76cd7b1a in jtgafv (jt=jt@entry=0x77f80200,
bytes=) at ../../../../jsrc/m.c:1351
#2  0x76e103ae in jtwordil (jt=jt@entry=0x77f80200, w=0x65b3c0)
at ../../../../jsrc/w.c:61
#3  0x76cb89a5 in jtddtokens (jt=jt@entry=0x77f80200,
w=0x65b3c0, env=2) at ../../../../jsrc/cx.c:1245
#4  0x76e98a78 in jtline (jt=0x77f80200, w=,
si=, ce=0 '\000', tso=)
at ../../../../jsrc/xs.c:79
#5  0x76cdcc1c in jtparsea (jt=0x0, jt@entry=0x77f80200,
queue=0x65ca78, nwds=)
at ../../../../jsrc/p.c:714
#6  0x76cb50e4 in jtxdefn (jt=0x77f80200, a=,
w=, w@entry=0x65a840, self=0x65a840)
at ../../../../jsrc/cx.c:426

#7  0x76cee288 in jtunquote (jt=0x77f80200, a=,
w=0x65a840, self=)
at ../../../../jsrc/sc.c:166

#8  0x76cdcc1c in jtparsea (jt=0x0, jt@entry=0x77f80200,
queue=0x648fe0, nwds=)
at ../../../../jsrc/p.c:714

#9  0x76cb50e4 in jtxdefn (jt=0x77f80200, a=,
w=, w@entry=0x69bec0, self=0x65e9c0)
at ../../../../jsrc/cx.c:426

#10 0x76cee288 in jtunquote (jt=0x77f80200, a=,
w=0x69bec0, self=)
at ../../../../jsrc/sc.c:166
#11 0x76cdcc1c in jtparsea (jt=0x0, jt@entry=0x77f80200,
queue=0x65af78, queue@entry=0x65af80, nwds=nwds@entry=7)
at ../../../../jsrc/p.c:714
#12 0x76cdc4cd in jtparse (jt=jt@entry=0x77f80200,
w=w@entry=0x65af40)
at ../../../../jsrc/p.c:254
#13 0x76ce15fa in jtimmex (jt=0x77f80200, jt@entry=0x77f80208,
w=) at ../../../../jsrc/px.c:54
#14 0x76e98a86 in jtline (jt=jt@entry=0x77f80200, w=, w@entry=0x668940, si=,
ce=0 '\000', tso=, tso@entry=0 '\000') at
../../../../jsrc/xs.c:79

On Sun, Oct 30, 2022 at 5:52 AM Henry Rich  wrote:

> I cannot reproduce this error on Windows.
>
> Henry Rich
>
> On 10/28/2022 10:31 PM, Raul Miller wrote:
> > I hit the same issue from 3 1e5 trys 32}.126{.a.
> >
> > This was in
> >
> > JVERSION
> > Engine: j904/j64avx2/windows
> > Beta-f: commercial/2022-10-02T17:45:07
> > Library: 9.04.03
> > Qt IDE: 2.0.3/6.2.4(6.2.4)
> > Platform: Win 64
> > Installer: J904 install
> > InstallPath: c:/other/j904
> > Contact: www.jsoftware.com
> >
> > J903 was fine.
> >
> > FYI,
> >
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] libgmp support -- initial draft

[bill lam]

The first step would be building gmp.dll because I googled and can't find
anything dll available/suitable

On Sat, 22 Oct 2022 at 8:45 PM Raul Miller  wrote:

> On Sat, Oct 22, 2022 at 8:13 AM bill lam  wrote:
> > It works for macos too. what is your plan for windows support?
>
> I guess I'm going to need to get visual studio working.
>
> --
> Raul
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] libgmp support -- initial draft

[bill lam]

It works for macos too. what is your plan for windows support?

On Sat, Oct 22, 2022 at 7:27 PM Raul Miller  wrote:

> I have pushed a fresh branch: j+gmp-clean which incorporates recent
> changes to the master branch,
>
> Assuming it tests out ok (the tests are looking good, so far), I will
> be deleting the j+gmp branch soon.
>
> Thanks,
>
> --
> Raul
>
> On Sat, Oct 22, 2022 at 6:35 AM bill lam  wrote:
> >
> > I notice changes of commits from Elijah were reverted/lost in your
> initial
> > commit. From which specific commit was you code based on? I think you
> > should checkout a branch from that particular commit and import your
> code.
> > and then merge or rebase with the master branch.
> >
> >
> > On Sat, Oct 22, 2022 at 6:19 PM bill lam  wrote:
> >
> > > I pushed some minor changes to enable compilation under apple m1.
> > >
> > > On Sat, Oct 22, 2022 at 5:41 PM Raul Miller 
> wrote:
> > >
> > >> Yes.
> > >>
> > >> Fixed, now.
> > >>
> > >> Thanks,
> > >>
> > >> --
> > >> Raul
> > >>
> > >> On Sat, Oct 22, 2022 at 5:37 AM bill lam  wrote:
> > >> >
> > >> > Did you forget to include the file jplatform64.sh ?
> > >> >
> > >> > On Sat, Oct 22, 2022 at 4:59 PM Raul Miller 
> > >> wrote:
> > >> >
> > >> > > On Sat, Oct 22, 2022 at 12:25 AM bill lam 
> > >> wrote:
> > >> > > > You should clone repos from jsoftware server for development
> that
> > >> are
> > >> > > > intended to commit to J repos. Please contact Chris Burke if
> you do
> > >> not
> > >> > > has
> > >> > > > the access.
> > >> > >
> > >> > > That's a good point.
> > >> > >
> > >> > > He had granted me access, though for some reason I had thought I
> only
> > >> > > had read-only access.
> > >> > >
> > >> > > I've pushed a j+gmp branch (implemented as a change from the
> jsoftware
> > >> > > master branch) to the J repo.
> > >> > >
> > >> > > Thanks,
> > >> > >
> > >> > > --
> > >> > > Raul
> > >> > >
> --
> > >> > > 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

Re: [Jsource] libgmp support -- initial draft

[bill lam]

I notice changes of commits from Elijah were reverted/lost in your initial
commit. From which specific commit was you code based on? I think you
should checkout a branch from that particular commit and import your code.
and then merge or rebase with the master branch.


On Sat, Oct 22, 2022 at 6:19 PM bill lam  wrote:

> I pushed some minor changes to enable compilation under apple m1.
>
> On Sat, Oct 22, 2022 at 5:41 PM Raul Miller  wrote:
>
>> Yes.
>>
>> Fixed, now.
>>
>> Thanks,
>>
>> --
>> Raul
>>
>> On Sat, Oct 22, 2022 at 5:37 AM bill lam  wrote:
>> >
>> > Did you forget to include the file jplatform64.sh ?
>> >
>> > On Sat, Oct 22, 2022 at 4:59 PM Raul Miller 
>> wrote:
>> >
>> > > On Sat, Oct 22, 2022 at 12:25 AM bill lam 
>> wrote:
>> > > > You should clone repos from jsoftware server for development that
>> are
>> > > > intended to commit to J repos. Please contact Chris Burke if you do
>> not
>> > > has
>> > > > the access.
>> > >
>> > > That's a good point.
>> > >
>> > > He had granted me access, though for some reason I had thought I only
>> > > had read-only access.
>> > >
>> > > I've pushed a j+gmp branch (implemented as a change from the jsoftware
>> > > master branch) to the J repo.
>> > >
>> > > Thanks,
>> > >
>> > > --
>> > > Raul
>> > > --
>> > > 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

Re: [Jsource] libgmp support -- initial draft

[bill lam]

I pushed some minor changes to enable compilation under apple m1.

On Sat, Oct 22, 2022 at 5:41 PM Raul Miller  wrote:

> Yes.
>
> Fixed, now.
>
> Thanks,
>
> --
> Raul
>
> On Sat, Oct 22, 2022 at 5:37 AM bill lam  wrote:
> >
> > Did you forget to include the file jplatform64.sh ?
> >
> > On Sat, Oct 22, 2022 at 4:59 PM Raul Miller 
> wrote:
> >
> > > On Sat, Oct 22, 2022 at 12:25 AM bill lam  wrote:
> > > > You should clone repos from jsoftware server for development that are
> > > > intended to commit to J repos. Please contact Chris Burke if you do
> not
> > > has
> > > > the access.
> > >
> > > That's a good point.
> > >
> > > He had granted me access, though for some reason I had thought I only
> > > had read-only access.
> > >
> > > I've pushed a j+gmp branch (implemented as a change from the jsoftware
> > > master branch) to the J repo.
> > >
> > > Thanks,
> > >
> > > --
> > > Raul
> > > --
> > > 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

Re: [Jsource] libgmp support -- initial draft

[bill lam]

Did you forget to include the file jplatform64.sh ?

On Sat, Oct 22, 2022 at 4:59 PM Raul Miller  wrote:

> On Sat, Oct 22, 2022 at 12:25 AM bill lam  wrote:
> > You should clone repos from jsoftware server for development that are
> > intended to commit to J repos. Please contact Chris Burke if you do not
> has
> > the access.
>
> That's a good point.
>
> He had granted me access, though for some reason I had thought I only
> had read-only access.
>
> I've pushed a j+gmp branch (implemented as a change from the jsoftware
> master branch) to the J repo.
>
> Thanks,
>
> --
> Raul
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] libgmp support -- initial draft

[bill lam]

J source in GitHub is a mirror of repos hosted in jsoftware so that J
source repos in GitHub is readonly.

You should clone repos from jsoftware server for development that are
intended to commit to J repos. Please contact Chris Burke if you do not has
the access.


On Sat, Oct 22, 2022, 7:01 AM Raul Miller  wrote:

> https://github.com/rdm/jsource/tree/j+gmp
>
> I've an implementation of the J engine with libgmp support for the
> XNUM and RAT types which passes a slightly modified test suite (RUN
> ddall under test/tsu.ijs). Note that there's a few issues in the test
> suite which need attention which I believe are not related to this
> porting effort.
>
> I'm going to continue to work on it, but it's in good enough shape
> that I think I am prepared to accept bug reports, if anyone wants to
> try building with these changes.
>
> (That said, in its current state it would be wise to keep these
> changes on a secondary branch or in a secondary copy of the jsource
> repository.)
>
> Oddly, I don't see my commit notice when I view the commit on github.
> So I'm copying it here as the remainder of this message:
>
> --
>
> libgmp integration -- initial draft
>
> This has been tested ONLY on a single 64 bit linux system. Also,
> libgmp must be installed in either a standard library location or in
> the same directory as jconsole.
>
> There are going to be issues.
>
> Also, beware that this patch includes changes to the make2/ build
> system and changes to the test/ directory.
>
> Do not incorporate these changes blindly.
>
> Changes in jsrc/ are the focus here.  It might be best to first
> test the libgmp changes against an untouched copy of the test
> directory, to review issues which prompted changes:
>
> (1) Previously, x: _ was an extended integer (type 64), this is no
> longer the case. Now x: _ is a rational (type 128).
>
> (2) I have "de-optimized" hexdump for simplicity. This means it
> takes a bit more space to execute than it used to.
>
> Also note that although this build is "complete" in the sense that
> it passes the (modified) test suite, there are other issues which need
> to be addressed.
>
> Planned, but not yet implemented is 3!:2 support for XNUM/RAT
> values exported via 3!:1 or 3!:3 under older versions of J.
>
> Planned, but not yet implemented is some sort of WS FULL support
> under low memory circumstances. (Here, malloc() would fail and memory
> would be allocated from a reserved chunk of memory and all subsequent
> libgmp calls would fail with WS FULL until the reserved memory has
> been restored.)
>
> And, of course, this is an EARLY RELEASE and may be unstable.
>
> --
>
> FYI,
>
> --
> Raul
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] errors in build scripts

[bill lam]

fixes pushed. please check. thanks.

On Tue, Sep 20, 2022 at 5:10 AM Raul Miller  wrote:

> Er.. oops... forgot the !
>
> So the test in portable form would be
>
> if [ "" = "$MAKEFLAGS" ]; then
>
> or
>
> if ! set|grep >/dev/null ^MAKEFLAGS=; then
>
> Thanks,
>
> --
> Raul
>
> On Mon, Sep 19, 2022 at 5:07 PM Raul Miller  wrote:
> >
> > As it happens, set -e wouldn't catch the problem on line 604 of
> build_all.sh
> >
> > The line is
> > if [ ! -v MAKEFLAGS ] ; then
> >
> > And, -v is a bash extension, not supported by /bin/sh
> >
> > To be portable, this should instead test for a non-empty "$MAKEFLAGS".
> > Or, if empty MAKEFLAGS has significance, the test in portable form
> > would be
> >if set|grep >/dev/null ^MAKEFLAGS=; then
> >
> > ...optionally with a space to the left of the semicolon.
> >
> > Thanks,
> >
> > --
> > Raul
> >
> > On Mon, Sep 19, 2022 at 4:58 PM Raul Miller 
> wrote:
> > >
> > > I would like to recommend that all shell scripts used for building J
> use set -e
> > >
> > > So they would start out like this:
> > >
> > > #!/bin/sh
> > > set -e
> > > ...
> > >
> > > This will exit the build script when an error is encountered, which
> > > helps isolate problems in build scripts.
> > >
> > > (A few moments ago, I saw an error fly by referencing line 604 of
> > > build_all.sh in make2.)
> > >
> > > Thanks,
> > >
> > > --
> > > Raul
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] __emu_maskload_impl / __emu_maskload_pd

[bill lam]

What is the version of your clang? It seems it doesn't support __float128.
JE itself doesn't use long double, so you may try adding
#define Sleef_quad_DEFINED
or add -DSleef_quad_DEFINED into the CFLAGS


> On 6 Mar 2022, at 3:49 AM, Raul Miller  wrote:
> 
> Building with clang fails like this:
> 
> cc -c -o a.o ../../../../jsrc/a.c  -fPIC -O2 -fvisibility=hidden
> -fno-strict-aliasing   -Werror -Wextra -Wno-unknown-warning-option
> -Wsign-compare  -Wtautological-constant-out-of-range-compare
> -Wuninitialized  -Wno-char-subscripts  -Wno-consumed
> -Wno-delete-non-abstract-non-virtual-dtor  -Wno-empty-body
> -Wno-implicit-float-conversion  -Wno-implicit-int-float-conversion
> -Wno-int-in-bool-context  -Wno-missing-braces  -Wno-parentheses
> -Wno-pass-failed  -Wno-pointer-sign  -Wno-pointer-to-int-cast
> -Wno-sometimes-uninitialized  -Wno-string-plus-int
> -Wno-unknown-pragmas  -Wno-unsequenced  -Wno-unused-but-set-variable
> -Wno-unused-function  -Wno-unused-parameter  -Wno-unused-value
> -Wno-unused-variable  -DSLEEF=1 -DEMU_AVX=1 -DC_AVX=1   -mavx
> In file included from ../../../../jsrc/a.c:6:
> In file included from ../../../../jsrc/j.h:164:
> ../../../../jsrc/../sleef/include/sleef.h:140:9: error: unknown type
> name '__float128'
> typedef __float128 Sleef_quad;
>^
> 1 error generated.
> 
> (This is on a different system from the one that was failing earlier.
> I'm going to take some time to look into this, and maybe there's a
> simple solution.)
> 
> ((I should also mention, since I keep thinking this, but never seem to
> talk about it: that I Really Wish that compiler context feature tests
> were implemented modularly. Like: a feature test directory with a
> makefile (to represent dependencies between feature tests) which
> generates environmental variable declarations (one env var per file,
> one file per feature, and then at the end of the makefile hierarchy a
> cat command to build a shell include script with env var settings for
> all features. Except, of course, the c preprocessor SYS mechanism
> doesn't adequately support this kind of approach.))
> 
> FYI,
> 
> -- 
> Raul
> 
> On Fri, Feb 25, 2022 at 11:55 PM bill lam  wrote:
>> 
>> Can you also try compile with clang?
>> 
>> On Sat, 26 Feb 2022 at 12:47 PM Raul Miller  wrote:
>> 
>>> I am trying to compile J (on a nonavx linux system -- celeron
>>> processor), and I'm running into a memory alignment issue.
>>> 
>>> Specifically, test/g022.ijs triggers a segmentation fault, and when
>>> compiling, I'm getting a variety of warnings that the ABI for passing
>>> parameters with 32-byte alignment has changed in GCC 4.6
>>> 
>>> So, before I go digging into the details of what's going on here, I
>>> was wondering if anyone else had run into this issue, and (if so) how
>>> they dealt with it.
>>> 
>>> (I should also confess that I might not have properly handled the
>>> non-avx architecture:  I altered make2/build-all.sh so that it, by
>>> default, always sets j64x=j64 for linux, for my builds. Hopefully
>>> that's not an issue, but when debugging I have found that it often
>>> pays to be a bit skeptical that I've done the right thing.)
>>> 
>>> Thanks,
>>> 
>>> --
>>> Raul
>>> --
>>> 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

Re: [Jsource] __emu_maskload_impl / __emu_maskload_pd

[bill lam]

Can you also try compile with clang?

On Sat, 26 Feb 2022 at 12:47 PM Raul Miller  wrote:

> I am trying to compile J (on a nonavx linux system -- celeron
> processor), and I'm running into a memory alignment issue.
>
> Specifically, test/g022.ijs triggers a segmentation fault, and when
> compiling, I'm getting a variety of warnings that the ABI for passing
> parameters with 32-byte alignment has changed in GCC 4.6
>
> So, before I go digging into the details of what's going on here, I
> was wondering if anyone else had run into this issue, and (if so) how
> they dealt with it.
>
> (I should also confess that I might not have properly handled the
> non-avx architecture:  I altered make2/build-all.sh so that it, by
> default, always sets j64x=j64 for linux, for my builds. Hopefully
> that's not an issue, but when debugging I have found that it often
> pays to be a bit skeptical that I've done the right thing.)
>
> Thanks,
>
> --
> Raul
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] Proposing NPY reader and writer as foreign 128!:9

[bill lam]

I agree with Raul. It is possible to implement it using pure J scripts
without any shared library call. This approach is good in that it is
simpler to write and validate, efficiency is also good for data under
100MB.

If you have a really serious project that expecting several hundred
megabytes or even giga bytes, then you need to make a more serious
investment.

On Tue, Oct 6, 2020, 4:20 AM Raul Miller  wrote:

> And a part of the issue there is that the format specifies that some
> of that metadata is executable python.
>
> (I took a look at implementing this myself, in a library, ran into
> that issue, and decided to spend my time elsewhere.)
>
> That said, I wouldn't worry about efficiency of memory allocation for
> something that's parsing a file. J routinely makes copies of data
> while operating on it, and that has proved to be significantly faster
> than naive optimization approaches would suggest. It turns out that
> cache coherency matters a lot more than micro-optimizations.
>
> For something like this, it's much more important that it works
> correctly than that it be "fast". Otherwise you just get something
> that does the wrong thing, really fast.
>
> Put differently: you should first parse the file into a representation
> that has all the information you need to send a serialized form of the
> file to J. The overhead of reading the file will be orders of
> magnitude greater than the cost of a serialize/deserialize step. And,
> maintaining clean interfaces is critical to the long term survival of
> a system like this.
>
> Good luck,
>
> --
> Raul
>
> On Mon, Oct 5, 2020 at 12:48 AM 'Zhihao Yuan' via Source
>  wrote:
> >
> > On Fri, Oct 2, 2020 at 12:45 PM Alex Shroyer  wrote:
> >
> > > My 2 cents, this should not be part of the J engine, but implemented
> as a
> > > library.
> > > It appears that NumPy itself implements .npy conversion as a library:
> > > https://github.com/numpy/numpy/blob/master/numpy/lib/format.py
> > >
> > >
> > A part of the reason is that since the code is
> > written in Python, they don't need to write a
> > parser or serializer to handle .npy metadata,
> > but we do.
> >
> > --
> > Zhihao
> > --
> > 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

Re: [Jsource] Proposing NPY reader and writer as foreign 128!:9

[bill lam]

An easier approach would be writing a thin wrapper for an existing c shared
library and then use 15!:0 to call the wrapper.

Unless the npy has at least become as widely used as json, I don't think it
should be included inside J engine.



On Fri, Sep 25, 2020, 4:51 AM 'Zhihao Yuan' via Source 
wrote:

> On Thu, Sep 24, 2020 at 12:44 PM Eric Iverson 
> wrote:
>
> >
> > It should be possible to package it as an addon. The addon would include
> > shared libraries for the platforms of interest (windows/linux/macos) and
> > simple cover functions that did the cd calls to the libraries. This is
> how
> > Jd/lapack/etc provide extensions like this.
>
>
> You are essentially asking me to write a
> new library in C, since there is no such
> library from the beginning -- which may
> be fine.  But here are the problems I
> encountered:
>
> 1. How do I allocate a J array before
> knowing its type and shape?  Because
> DLL (15!:) interface wants J side to pass
> such a thing into cd.  The short answer is
> I can't.  I must use separated calls to
> negotiate the type and shape, which
> leads to the next question...
>
> 2. How to pass FILE* to DLL from J?
> All I can access from J code is file number;
> DLL doesn't know what that is.  This implies
> that I may have to pass only filenames and
> open a file twice -- first to parse its header,
> then to load its data. But there is no
> guarantee that the file is not renamed
> between the two calls, or corresponds to
> the same file.  From a C library's point of
> view, such an API will be poorly designed.
>
> I'm leaning towards adding this
> functionality as 3!:12 and 3!:13, converting
> a J array to bytes in NPYand retrieving a
> J array from bytes.
>
> --
> Zhihao
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] Compiling J source on Cygwin

[bill lam]

base64 in github. the LICENSE file already included the names of authors.

On Thu, Jul 30, 2020, 3:12 AM Akakima  wrote:

> Good news. Finally i succesfully compiled J on Cygwin.
>
> The following tests failed:
>
> gdll.ijs
> g7x5.ijs
> g420.ijs
>
> g420 failed because foldr.ijs is not present in the right directory.
> not found:
>
> /cygdrive/e/gitdev/Jsource-J902.original/jsource/jlibrary/addons/dev/fold/foldr.ijs
>
> After copied in the right directory, the test succeded.
>
> gdll failed because, under Cygwin, when you copy a file (in this case a
> dll) with fread/fwrite, the permissions of the resulting file is not ok.
> Ie, it is not executable. I tested to copy with a C program, same result.
>
> Solution: set the permission manually.
> Add the line: if. IFUNIX do. (1!:7 <'libtsdll.so') 1!:7  in gdll.ijs. So the expression 2 0-:f'' returns 1.
>
> g7x5 failed with a strange error message.
> Fix: delete ~temp/*.jmf at the beginning of g7x5.ijs.
> g =: 3 : 0
>   if. IFUNIX do.
>2!:0 'rm -f ',jpath '~temp/*.jmf'
>   end.
>   1
> )
>
> g ''
>
> There is another modification in js.h :
> //#ifdef __linux__
> #if defined(__linux__) || defined(__CYGWIN__)
> #define SYS SYS_LINUX
> #undef SY_LINUX
> #define SY_LINUX 1
> #endif
>
> All other modifications are in the directory make4.cygwin.
> make4.cygwin is a new directory made from make2.
> The sh scripts where modified.
>
> The results are the same for gcc and clang.
>
> SLEEF is not available for Cygwin.
> I downloaded it and was not able to compile it.
>
> Under Cygwin, YASM (a NASM clone) is available.
> So we can compile J with NO_SHA_ASM=0.
>
> Question: What is the source (where does it come from) of BASE64 ?
> There are many version on Github (and may be elsewhere)
>
> Thanks
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] git pull

[bill lam]

Thank you for providing the context. I have set pull.rebase=true in
.gitconfig for years, so should not be affected by it.
But the warning message is really bad enough. It blamed users, but it
should admit git had made a mistake for the default in the past and ask
users to explicitly set the option and recommend rebase=true.

On Sun, Jun 7, 2020 at 9:22 AM ethiejiesa via Source 
wrote:

> FWIW, this is a new warning in git as of 2.27.0, released about a week ago:
> https://github.com/git/git/commit/d18c950a69f3a24e1e3add3d9fc427641f53e12b
> which likely explains why you are suddenly seeing this.
>
> The issue is that, when pulling, you might have local commits not on the
> upstream branch:
>
> - A -- B -- C   
> - A -- B -- C'  
>
> so git needs to know what to do with your commit C'. The default is to
> merge:
>
>  C
>/   \
> - A -- B -- D
>\   /
>  C'
>
> creating a new commit D with the combined changes of C and C'. However, a
> common workflow is simply work *on top of upstream* in which case we simply
> want C' to be applied on top of C:
>
> - A -- B -- C -- C'
>
> This latter case is called "rebasing" in the sense that the "base" of C'
> gets
> switched from B to C. Rebasing is a generic operation you can perform on
> commits, and the `pull.rebase' git option lets you tell git to use it in
> case
> of conflicts when pulling. The default is to merge, and the new warning is
> essentially just to let users know about the covnience of `pull.rebase'.
>
> Similarly, the `pull.ff' option tells git to use a "fast-forward" strategy
> when
> pulling, which is git's terminology for "simply update the branch to look
> like
> upstream." By default git fast-forwards when there are no local conflicts
> with
> the upstream branch and merges otherwise; however, if you don't want to
> manually take care of pull conflicts, without git trying to merge or rebase
> automatically, setting the `pull.ff' option to `only' has your back.
>
> Hope that helps,
>
>
> Akakima  wrote:
> > Tried this in the fresh jsource cloned, and it worked. No more message.
> >
> > Then tried it in my previous jsource (after some renaming to restore
> > it). And it worked too. No more message ...
> >
> > Many thanks to all for the help.
> >
> > Now, guess i should study Git ...
> > But seems to me, it is a bit complex.
> >
> > On 2020-06-06 19:56, bill lam wrote:
> > > looks like the tree is clean, not sure what's wrong with your git
> global
> > > setting. perhaps you follow anyone of the suggestion, eg
> > >
> > > git config pull.rebase false
> > >
> > > and then git pull
> > >
> > >
> > > On Sun, Jun 7, 2020, 7:48 AM Akakima  wrote:
> > >
> > >> E:\gitdev\Jsource-J902\jsource>git status
> > >> On branch master
> > >> Your branch is up to date with 'origin/master'.
> > >>
> > >> nothing to commit, working tree clean
> > >>
> > >> E:\gitdev\Jsource-J902\jsource>
> > >>
> > >> On 2020-06-06 19:30, bill lam wrote:
> > >>> what's the output of git status ?
> > >>>
> > >> --
> > >> 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

Re: [Jsource] git pull

[bill lam]

looks like the tree is clean, not sure what's wrong with your git global
setting. perhaps you follow anyone of the suggestion, eg

git config pull.rebase false

and then git pull


On Sun, Jun 7, 2020, 7:48 AM Akakima  wrote:

> E:\gitdev\Jsource-J902\jsource>git status
> On branch master
> Your branch is up to date with 'origin/master'.
>
> nothing to commit, working tree clean
>
> E:\gitdev\Jsource-J902\jsource>
>
> On 2020-06-06 19:30, bill lam wrote:
> > what's the output of git status ?
> >
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] git pull

[bill lam]

what's the output of git status ?

On Sun, Jun 7, 2020, 7:23 AM Akakima  wrote:

> E:\gitdev\Jsource-J902\jsource>git --version
> git version 2.27.0
>
> To Bill, Michael and Bill :
>
> Thanks for the help.
> As you know, my knowledge of GIt  is very limited.
> The only commands i know are: clone and pull.
>
> Before trying your suggestions, I had to try this :
>
> I renamed current jsource dir jsource-n.
> So the next clone will be a new clean jsource directory.
>
> Cloned a fresh copy of jsource.
>
> Immediately made a pull (jsource virgin. Not one modification)
> Got the same message:
>
> I dont know how interpret this.
>
> warning: Pulling without specifying how to reconcile divergent branches is
> discouraged. You can squelch this message by running one of the following
> commands sometime before your next pull:
>
>git config pull.rebase false  # merge (the default strategy)
>git config pull.rebase true   # rebase
>git config pull.ff only   # fast-forward only
>
> You can replace "git config" with "git config --global" to set a default
> preference for all repositories. You can also pass --rebase, --no-rebase,
> or --ff-only on the command line to override the configured default per
> invocation.
>
> Already up to date.
>
>
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] git pull

[bill lam]

For not too old versions of git, can do it with rebase option

git commit -a -m 'lahlahlah'
git pull --rebase


On Sun, Jun 7, 2020, 12:49 AM Michael Dykman  wrote:

> Try
>
> #stash your changes
> $ git stash -u
> # pull a clean copy
> $ git pull
>
> # if you want to reapply your patches
> $ git stash pop
>
>
>
> On Sat, Jun 6, 2020, 12:20 Akakima  wrote:
>
> >  > Have you made any changes to your local copy?
> >
> > Yes. Some.
> >
> > To take in account the fact that i have a 32 bits OS with only 3 gig of
> > memory.
> > To allow J to compile under Cygwin.
> > May be 6 Files.
> > Plus i added some directories (but no conflicts with existing names).
> >
> >
> >  > $ git status
> > On branch master
> > Your branch is up to date with 'origin/master'.
> >
> > Changes not staged for commit:
> >(use "git add/rm ..." to update what will be committed)
> >(use "git restore ..." to discard changes in working directory)
> > modified:   jsrc/js.h
> > modified:   jsrc/xf.c
> > modified:   makemsvc/install.bat
> > modified:   makemsvc/release.bat
> > deleted:test/g128x3.ijs
> > modified:   test/g320ipt.ijs
> > modified:   test/gdll.ijs
> > modified:   test/gmbx.ijs
> > deleted:test/test.htm
> >
> > Untracked files:
> >(use "git add ..." to include in what will be committed)
> > jlibrary/addons/dev/
> > jsrc/Trace.out
> > jsrc/a.out
> > jsrc/a.tds
> > jsrc/bcc32c.help
> > jsrc/jcon
> > jsrc/jconsole.cygwin.c
> > jsrc/jconsole.cygwin.c.orig
> > jsrc/jj.exe
> > jsrc/xf.cygwin.c
> > jsrc/xt.s
> > linux-mint-fail.txt
> > make.msvc/
> > make2linux/
> > makemsvc/jbld/
> > makemsvc/jconsole/jconsole.res
> > makemsvc/jconsole/jconsole32.exe
> > makemsvc/jdll/j32.dll
> > makemsvc/jdll/j32.exp
> > makemsvc/jdll/j32.lib
> > makemsvc/jdll/jdll.res
> > makemsvc/run.bat
> > makemsvc/tsdll/tsdll32.dll
> > makemsvc/tsdll/tsdll32.exp
> > makemsvc/tsdll/tsdll32.lib
> > makemsvc2/
> > test-20200512-13h09/
> > test/crash/
> > test/test.html
> >
> > no changes added to commit (use "git add" and/or "git commit -a")
> >
> >
> > On 2020-06-06 11:27, Michael Dykman wrote:
> > > Have you made any changes to your local copy?
> > >
> > > What does this give you?
> > >
> > > $ git status
> > >
> > --
> > 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

Re: [Jsource] cc.c(487) : error C2065: 'jt' : undeclared identifier

[bill lam]

I also saw this error.

If you use makemsvc, you also need to set macro on the command line, eg

nmake -f makefile.win x64=1 JAVX2=1

see the first 20 lines in the makefile

On Fri, May 1, 2020, 6:12 AM Akakima  wrote:

> Hi,
>
> --- preparation
> Make a fresh clone of the J repository.
> setup version.h
> cd makemvsc
> cd jdll
> nmake -f makefile.win clean
> nmake -f makefile.win
>
> --- error
>  cl  /D_JDLL  /WX /W3 /Ot /Ob1 /Oy- /GS /Zc:strictStrings
> /D_USING_V110_SDK71_ /D_CRT_SECURE_NO_WARNINGS /MT  /Fo../../jsrc/cc.o
> /c ../../jsrc/cc.c
> Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x86
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> cc.c
> ../../jsrc/cc.c(487) : error C2065: 'jt' : undeclared identifier
> ../../jsrc/cc.c(487) : error C2223: left of '->typesizes' must point to
> struct/union
> ../../jsrc/cc.c(487) : error C2168: '_tzcnt_u32' : too few actual
> parameters for intrinsic function
> NMAKE : fatal error U1077: 'E:\Vs2013\VC\BIN\cl.EXE' : return code '0x2'
> Stop.
>
> On 2020-04-30 13:40, Raul Miller wrote:
> > It's been ages since I've messed with VS2013 or windows, but... some
> > observation based questions which might help you shed some light on
> > this problem:
> >
> > Does VS2013 not identify the file where the error occurred? Or is this
> > a linking error?
> >
> > If it's a linking issue, I'm going to guess that you're building a dll
> > and haven't completed one of the prerequisite steps.
> >
> > But I am just guessing -- you haven't provided a lot of information
> > here about what you are doing nor about where the error occurred, That
> > sort of information is critical to understanding what's going on here.
> >
> > Thanks,
> >
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] make/build_*.sh are unfriendly to cross-compilation

[bill lam]

Sorry I don't quite understand your question, nevertheless it is 
up to you inside your own fork because this is open-source, 
please feel free to improve it.

Eric or Chris should be the best person to anwser because they
build official binaries using the make folder.

Fri, 24 Jan 2020, JSource написал(а):
> Okay, so make2 exists as a simple conveniece. And this presumably at the cost
> of (cross-platform) build flexibility?
> 
> Instead of continuing a barrage of micro-questions, permit me to directly 
> share
> my intent. I would like to improve the build scripts in make; however, this
> seems like a Chesterton's fence [0] problem. Is there a way for users to test
> changes to the build system?
> 
> [0]:https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
> 
> bill lam  wrote:
> 
> > make folder is the original and used for building official release. It
> > requires users to READ instructions in order to set up and go. But too many
> > users don't like to read and follow instructions, they just expect to type
> > configure then make to do everything. To life easier, there comes make2,
> > users need only to build_all.sh right after cloning the repos.
> >
> >
> > On Fri, Jan 24, 2020, 12:04 PM ethiejiesa via Source 
> > wrote:
> >
> > > Okay, thank you.
> > >
> > > When first going about packaging J, I do recall reading overview.txt. At
> > > least
> > > at that time, it was entirely unclear to me how to judge the differences
> > > between the two, as it just menions that make it is "somewhat simpler." Is
> > > there a particular objective behind maintaining the two build pipelines,
> > > or is
> > > it mainly due to legacy reasons?
> > >
> > > If it would be of any use, I would not mind writing up my experience
> > > trying to
> > > package J as a complete newcomer. There were several surprises that I 
> > > never
> > > found documented in the repo nor the wiki, and the J repository looks 
> > > quite
> > > idiosyncratic compared to "typical" software one tries to package for a
> > > linux
> > > distro.
> > >
> > > bill lam  wrote:
> > >
> > > > users can choose the one that they prefer as mentioned inside
> > > overview.txt
> > > >
> > > > cc --ver does not work in some platforms or gcc/clang version in that
> > > they
> > > > print something else that identifying them as gcc/clang.
> > > >
> > > > On Wed, Jan 22, 2020, 2:48 PM ethiejiesa via Source <
> > > sou...@jsoftware.com>
> > > > wrote:
> > > >
> > > > > That worked beautifully. Thank you for the pointer.
> > > > > Did I miss some obvious documentation about building jsource? I am
> > > curious
> > > > > about the need for both make and make2.
> > > > >
> > > > > bill lam  wrote:
> > > > >
> > > > > > I suggest you to use make file under make2, see the readme there. It
> > > uses
> > > > > > readlink to get the real filename of cc.
> > > > > >
> > > > > > On Tue, Jan 21, 2020, 1:05 PM ethiejiesa via Source <
> > > > > sou...@jsoftware.com>
> > > > > > wrote:
> > > > > >
> > > > > > > > If you use either gcc or clang, you can export $CC before make.
> > > > > > >
> > > > > > > Taking `build_libj.sh` for example, the problem is that it only
> > > detects
> > > > > > > gcc in
> > > > > > > cases where CC contains "gcc" as a substring. This breaks when, 
> > > > > > > for
> > > > > > > example,
> > > > > > > CC=cc and cc is a symlink to some gcc. For example, when building
> > > for a
> > > > > > > non-native target, one usually sets up cc to point to the
> > > appropriate
> > > > > build
> > > > > > > toolchain, e.g. /usr/bin/arm-linux-gnueabihf-gcc.
> > > > > > >
> > > > > > > Interestingly, `build_jconsole.sh` adopts a diffrent, stronger
> > > > > assumption
> > > > > > > that
> > > > > > > CC=gcc when gcc is the compiler. Note that clang compilation 
> > > > > > > mostly
> > > > > Just
> > > > > > > Works
> > > > > > > TM, sinc

Re: [Jsource] make/build_*.sh are unfriendly to cross-compilation

[bill lam]

make folder is the original and used for building official release. It
requires users to READ instructions in order to set up and go. But too many
users don't like to read and follow instructions, they just expect to type
configure then make to do everything. To life easier, there comes make2,
users need only to build_all.sh right after cloning the repos.


On Fri, Jan 24, 2020, 12:04 PM ethiejiesa via Source 
wrote:

> Okay, thank you.
>
> When first going about packaging J, I do recall reading overview.txt. At
> least
> at that time, it was entirely unclear to me how to judge the differences
> between the two, as it just menions that make it is "somewhat simpler." Is
> there a particular objective behind maintaining the two build pipelines,
> or is
> it mainly due to legacy reasons?
>
> If it would be of any use, I would not mind writing up my experience
> trying to
> package J as a complete newcomer. There were several surprises that I never
> found documented in the repo nor the wiki, and the J repository looks quite
> idiosyncratic compared to "typical" software one tries to package for a
> linux
> distro.
>
> bill lam  wrote:
>
> > users can choose the one that they prefer as mentioned inside
> overview.txt
> >
> > cc --ver does not work in some platforms or gcc/clang version in that
> they
> > print something else that identifying them as gcc/clang.
> >
> > On Wed, Jan 22, 2020, 2:48 PM ethiejiesa via Source <
> sou...@jsoftware.com>
> > wrote:
> >
> > > That worked beautifully. Thank you for the pointer.
> > > Did I miss some obvious documentation about building jsource? I am
> curious
> > > about the need for both make and make2.
> > >
> > > bill lam  wrote:
> > >
> > > > I suggest you to use make file under make2, see the readme there. It
> uses
> > > > readlink to get the real filename of cc.
> > > >
> > > > On Tue, Jan 21, 2020, 1:05 PM ethiejiesa via Source <
> > > sou...@jsoftware.com>
> > > > wrote:
> > > >
> > > > > > If you use either gcc or clang, you can export $CC before make.
> > > > >
> > > > > Taking `build_libj.sh` for example, the problem is that it only
> detects
> > > > > gcc in
> > > > > cases where CC contains "gcc" as a substring. This breaks when, for
> > > > > example,
> > > > > CC=cc and cc is a symlink to some gcc. For example, when building
> for a
> > > > > non-native target, one usually sets up cc to point to the
> appropriate
> > > build
> > > > > toolchain, e.g. /usr/bin/arm-linux-gnueabihf-gcc.
> > > > >
> > > > > Interestingly, `build_jconsole.sh` adopts a diffrent, stronger
> > > assumption
> > > > > that
> > > > > CC=gcc when gcc is the compiler. Note that clang compilation mostly
> > > Just
> > > > > Works
> > > > > TM, since the scripts assume clang by default.
> > > > >
> > > > > > j forum discards attachment so we can't see your patch.
> > > > >
> > > > > Oops. Thank you for pointing this out. Including both patches in
> the
> > > body
> > > > > is
> > > > > probably too much clutter, so for illustrative purposes, I will
> simply
> > > > > post the
> > > > > smaller one below:
> > > > >
> > > > >
> > > > > --- make/build_jconsole.sh  2019-12-17 18:25:11.713700768 +0900
> > > > > +++ make/build_jconsole.sh  2019-12-17 18:26:45.090341029 +0900
> > > > > @@ -5,6 +5,7 @@
> > > > >  cd ~
> > > > >
> > > > >  macmin="-mmacosx-version-min=10.6"
> > > > > +ccver=$(${CC} --version)
> > > > >  USE_LINENOISE="${USE_LINENOISE:=1}"
> > > > >
> > > > >  if [ "x$CC" = x'' ] ; then
> > > > > @@ -20,7 +21,7 @@
> > > > >  export CC
> > > > >  fi
> > > > >
> > > > > -if [ $CC = "gcc" ] ; then
> > > > > +if [ -z "${ccver##*(GCC)*}" ]; then
> > > > >  # gcc
> > > > >  common=" -fPIC -O1 -fwrapv -fno-strict-aliasing -Wextra
> > > > > -Wno-maybe-uninitialized -Wno-unused-parameter -Wno-sign-compare
> > > > > -Wno-clobbered -Wno-empty-body -Wno-unused-value -Wno-pointer-sign
> > > > > -Wno-par

Re: [Jsource] WIP Port of J901beta-d to OpenBSD

[bill lam]

There are some linux-ism in base library, while openbsd is not officially
supported, I think it is nice to let base library run correctly on linux
and fail safe, on other unknown platforms, like this.

cpu=. 2!:0 ::(''"_) 'cat /proc/cpuinfo'

On Tue, Apr 23, 2019, 3:32 AM Raul Miller  wrote:

> (Do you have a github fork of https://github.com/jsoftware/jsource
> that we can look at?)
>
> Probably, since you're doing this quick and dirty, I imagine the thing
> to do is edit your copy of stdlib.ijs with a quick fix that gets you
> running.
>
> From your error message, it looks like your copy dies at the line
> corresponding to:
>
>
> https://github.com/jsoftware/jsource/blob/master/jlibrary/system/main/stdlib.ijs#L49
>
> Which is, basically:
>
> if. notdef 'IFRASPI' do.
>   if. UNAME -: 'Linux' do.
> cpu=. 2!:0 'cat /proc/cpuinfo'
> IFRASPI=: (1 e. 'BCM2708' E. cpu) +. (1 e. 'BCM2709' E. cpu) +. 1
> e. 'BCM2710' E. cpu
>   else.
> IFRASPI=: 0
>   end.
> end.
>
> Since you're probably not using a raspberry pi here, I'd just change that
> to:
>
> if. notdef 'IFRASPI' do.
>   IFRASPI=: 0
> end.
>
> (At some point, though, I imagine it would be nice to do an official
> openbsd port of J source.)
>
> Thanks,
>
> --
> Raul
>
> On Mon, Apr 22, 2019 at 3:19 PM Alexander Shendi
>  wrote:
> >
> > Hello J community,
> >
> > I am currently trying to learn J using the 'J for C Programmers'
> > book. As there is no binary distribution for OpenBSD, I have decided
> > to attempt to compile the J901-beta-d source under OpenBSD.
> >
> > I have so far succeded in adapting and compiling the C source files and
> have
> > working jconsole and libj.so binaries.
> >
> > However it seems that I also need to port the J library files
> > (e.g. `stdlib.ijs'), but that seems to be harder, because I am still a
> > J newbie.
> >
> > Here is a sample jconsole session:
> >
> > 
> >
> > Script started on Mon Apr 22 21:00:38 2019
> > alex-x200t$ ./jconsole
> > cat: /proc/cpuinfo: No such file or directory
> > |interface error
> > |   cpu=.2!:0'cat /proc/cpuinfo'
> > |[-75]
> /home/alexshendi/sources/packages/jsource-j901-beta-d.p1/jlibrary/system/main/stdlib.ijs
> >UNAME
> > Linux
> >1 2 3 + 4 5 6
> > 5 7 9
> >i.10
> > 0 1 2 3 4 5 6 7 8 9
> >+/i.11+1
> > 66
> >
> > Script done on Mon Apr 22 21:05:41 2019
> >
> > ===
> >
> > J seems to think it is still running under Linux and tries to
> > open /proc/cpuinfo, which doesn't exist under BSD systems.
> > But basic stuff seems to work :)
> >
> > I would be grateful for some advice on how to proceed.
> > I will be glad to provide more information, if needed.
> >
> > Many thanks in advance,
> >
> > Alexander
> > --
> > 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

Re: [Jsource] Building J for Android

[bill lam]

I used only ant to build apk, never tried android studio, eclipse or other
gui tool.

I had no problem in using ant last time I tired, I'll check again.

On Sat, Aug 11, 2018, 2:27 AM David Mitchell  wrote:

> I tried the jandroid process.   It initially failed with
> tools/ant/build.xml not
> found.  This seems to be expected:
>
>
> https://stackoverflow.com/questions/42912824/the-ant-folder-is-suddenly-missing-from-android-sdk-did-google-remove-it
>
> Android team has decided to remove all old and obsolete scripts from SDK
> in
> march release of 25.3.0 SDK Tools
>
> Changes:
>
>  Obsolete/deprecated tools have been removed:
>  android
>  ddms (instead see Using DDMS)
>  draw9patch (instead see Draw 9-patch)
>  hierarchyviewer (instead see Profile Your Layout with Hierarchy
> Viewer)
>  traceview (instead see Profiling with Traceview and dmtracedump)
>  ant scripts
>  Project and activity template
>
> I tried he work-around (install tools/ant/build.xml from an older tools
> release), which failed:
>
> ant release && ./deploy.sh
> Buildfile: /home/me/Downloads/Android/jandroid-master/build.xml
>[taskdef] Could not load definitions from resource anttasks.properties.
> It
> could not be found.
>[taskdef] Could not load definitions from resource emma_ant.properties.
> It
> could not be found.
>
> Poking on the web, it looks as if ant is not well supported any more and
> folks
> are migrating to gradle (or Android Studio).
>
> Does this look like the best approach?
>
> Thanks,
> David Mitchell
>
>
> On 8/10/2018 10:14, David Mitchell wrote:
> > Bill,
> >
> > Thanks for the nudge.  My old eyes missed the separate git repository
> for jandroid.
> >
> > All the best,
> > David Mitchell
> >
> > On 8/10/2018 09:56, bill lam wrote:
> >> build.xml should already been there, just
> >> ant release
> >> should build the unsigned apk
> >>
> >> On Fri, Aug 10, 2018, 9:49 PM David Mitchell 
> wrote:
> >>
> >>> It looks like the only place libjpcre.so is used is in jd.  But, jd
> looks
> >>> like
> >>> it won't run on the 32 bit default Android distribution.
> >>>
> >>> So, for now, I'll ignore pcre and move on to creating an apk.  Does
> anyone
> >>> have
> >>> any suggestions for creating a J Android apk from the binaries created
> by
> >>> ndk-build?  It looks like the choices are to use Android Studio, using
> >>> gradlew
> >>> or using ant with some sort of build.xml.
> >>>
> >>> Unless there is a build.xml hiding somewhere, all of these look like
> they
> >>> would
> >>> require reverse-engineering the current distribution J Android APK.
> >>>
> >>> Thanks,
> >>> David Mitchell
> >>>
> >>> On 8/9/2018 09:48, David Mitchell wrote:
> >>>> I used that Android.mk for pcre2.  The Android build references both
> >>> pcre and
> >>>> pcre2:
> >>>>
> >>>> 1. make a symlink in jni folder
> >>>>
> >>>> $ cd jni
> >>>> $ ln -sf ../../jsrc .
> >>>> $ ln -sf ../../hostdefs.
> >>>> $ ln -sf ../../netdefs .
> >>>> $ ln -sf ../../../../src/pcre .
> >>>> $ ln -sf ../../../../src/pcre2 .
> >>>> $ cd ..
> >>>>
> >>>> 2. build using ndk in the current folder
> >>>>
> >>>> $ ndk-build
> >>>>
> >>>> I tried using the same Android.mk with pcre, but it did not work well.
> >>>>
> >>>> Thanks,
> >>>> David Mitchell
> >>>>
> >>>> On 8/9/2018 08:51, chris burke wrote:
> >>>>> https://github.com/jsoftware/base8/blob/master/regex/make/Android.mk
> >>>>>
> >>>>> On Thu, Aug 9, 2018 at 2:17 AM David Mitchell  >
> >>> wrote:
> >>>>>
> >>>>>> I have almost gotten this to build.  The last step I have is finding
> >>>>>> Android.mk
> >>>>>> for pcre.
> >>>>>>
> >>>>>> Any help would be appreciated.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> David Mitchell
> >>>>>>
> --
> >>>>>> 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

Re: [Jsource] Building J for Android

[bill lam]

build.xml should already been there, just
ant release
should build the unsigned apk

On Fri, Aug 10, 2018, 9:49 PM David Mitchell  wrote:

> It looks like the only place libjpcre.so is used is in jd.  But, jd looks
> like
> it won't run on the 32 bit default Android distribution.
>
> So, for now, I'll ignore pcre and move on to creating an apk.  Does anyone
> have
> any suggestions for creating a J Android apk from the binaries created by
> ndk-build?  It looks like the choices are to use Android Studio, using
> gradlew
> or using ant with some sort of build.xml.
>
> Unless there is a build.xml hiding somewhere, all of these look like they
> would
> require reverse-engineering the current distribution J Android APK.
>
> Thanks,
> David Mitchell
>
> On 8/9/2018 09:48, David Mitchell wrote:
> > I used that Android.mk for pcre2.  The Android build references both
> pcre and
> > pcre2:
> >
> > 1. make a symlink in jni folder
> >
> > $ cd jni
> > $ ln -sf ../../jsrc .
> > $ ln -sf ../../hostdefs.
> > $ ln -sf ../../netdefs .
> > $ ln -sf ../../../../src/pcre .
> > $ ln -sf ../../../../src/pcre2 .
> > $ cd ..
> >
> > 2. build using ndk in the current folder
> >
> > $ ndk-build
> >
> > I tried using the same Android.mk with pcre, but it did not work well.
> >
> > Thanks,
> > David Mitchell
> >
> > On 8/9/2018 08:51, chris burke wrote:
> >> https://github.com/jsoftware/base8/blob/master/regex/make/Android.mk
> >>
> >> On Thu, Aug 9, 2018 at 2:17 AM David Mitchell 
> wrote:
> >>
> >>> I have almost gotten this to build.  The last step I have is finding
> >>> Android.mk
> >>> for pcre.
> >>>
> >>> Any help would be appreciated.
> >>>
> >>> Thanks,
> >>> David Mitchell
> >>> --
> >>> 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

Re: [Jsource] compilation from sources on OpenBSD, amd64, noavx

[bill lam]

  if. UNAME -: 'Linux' do.
 cpu=. 2!:0 'cat /proc/cpuinfo'

Apparently, the base library guarded non-Linux system
from execution these sentences. I think you
need to add a line
UNAME_z_=: 'OpenBSD' 
to the begining of your profile.ijs as a kludge.
Of course there will be other issues since base
library has no support for OpenBSD. 

I think this can not be half done, you need to 
spend some time to modify base library to
support OpenBSD. As a rough estimate, you can
grep all occurrence of the word 'Android' in
base library, those are places that you needed
to work. May be a few more but not many.

Чт, 07 июн 2018, Rudolf Sykora написал(а):
> Hello,
> 
> On 6 June 2018 at 15:15, bill lam  wrote:
> > try comment out this line
> >
> >  'libc.so.6 setlocale > x i *c'&(15!:0)^:(UNAME-:'Linux')1;,'C'
> >
> >> odin$ cd soft/jsource/jbld/j64/bin
> >> odin$ ./jconsole
> >> |domain error: boot
> >> |   'libc.so.6 setlocale > x i *c'&(15!:0)^:(UNAME-:'Linux')1;,'C'
> >>install'all'
> >> |value error: install
> >> |   install'all'
> >>
> 
> 
> odin$ find . -exec grep 'libc.so.6 setlocale' {} /dev/null \;
> ./jlibrary/system/main/stdlib.ijs:'libc.so.6 setlocale > x i
> *c'&(15!:0)^:(UNAME-:'Linux') 1;,'C'
> ./jbld/j32/system/main/stdlib.ijs:'libc.so.6 setlocale > x i
> *c'&(15!:0)^:(UNAME-:'Linux') 1;,'C'
> ./jbld/j64/system/main/stdlib.ijs:'libc.so.6 setlocale > x i
> *c'&(15!:0)^:(UNAME-:'Linux') 1;,'C'
> 
> So I commented out the line in the jlibrary and j64 directories.
> (Why are there two?! Which one is really relevant?)
> But that gives:
> 
> odin$ ./jconsole
> cat: /proc/cpuinfo: No such file or directory
> |interface error: boot
> |   cpu=.2!:0'cat /proc/cpuinfo'
> 
> 
> after which I can issue commands to j
> .
> OpenBSD does not use /proc/cpuinfo.
> 
> Anyway. These errors / warnings (?) probably just mean that my path
> of compiling /setting up j on OpenBSD is suboptimal (so far it has
> been just a hack).
> 
> Thanks
> Ruda
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] compilation from sources on OpenBSD, amd64, noavx

[bill lam]

openbsd is not linux. whenever something in J that are specific for Linux,
eg UNAME or hostdef , you need to be alert. It is better for testing by
adding a new platform OpenBSD to discover more places that need fixing.
That said I'm afraid that will not be supported officially.

did cmd uname report Linux? or uname unavailable in OpenBSD?

On Fri, Apr 13, 2018, 8:54 PM Rudolf Sykora  wrote:

> Hello,
>
> I tried to compile jconsole + libj + libtsdll under OpenBSD.
> I managed (although I had to be hard; I seem to dislike the
> build system a lot).
>
> When I run jconsole now, I get the message
>
> |domain error: boot
> |   'libc.so.6 setlocale > x i *c'&(15!:0)^:(UNAME-:'Linux')1;,'C'
>
> (it originates from system/main/stdlib.ijs)
>
> Thus probably I still had to change something.
> Can anybody comment on this?
>
> For me there are too many #define in the sources at too many
> places... (j.h js.h x15.c)
>
> Thanks
> Ruda
>
> --
> PS.:
> So far I (probably not comprehensive, just for reference; not polished at
> all):
>
> 1) change #!/bin/bash to #!/bin/sh in the building scripts
>
> 2) keep jvars.sh inside the building tree, source it once to
> the shell that will be used for the building
> (and do not source it again anywhere)
>
> 2.5) put to jvars.sh:
> jplatform=openbsd
> and export it at the end
>
> 2.6) add to jsrc/js.h info about OPENBSD (what is really needed apart from
> finally having SY_64 1??)
> #define SYS_OPENBSD  8388608L
>
> #define SYS_UNIX(SYS_ATT3B1 + SYS_DEC5500 + SYS_IBMRS6000 + \
>  SYS_MIPS + SYS_NEXT + SYS_SGI + SYS_SUN3 + \
>  SYS_SUN4 + SYS_VAX + SYS_LINUX + SYS_MACOSX +
> \
>  SYS_FREEBSD + SYS_NETBSD + SYS_SUNSOL2 +
> SYS_HPUX+ \
> SYS_OPENBSD)
>
> #define SYS SYS_OPENBSD  ...just before testing if SYS is defined
> (towards the end)
>
> 3) run gmake instead of make (domake.sh)
>
> 4) change the line in build_libj.sh to:
> if [ $($CC -v 2>&1 | grep -E -c "clang\ version|Apple\ LLVM\ version")
> -eq 1 ] ; then
> or just say it'll be clang for us
> or sth like (?)
> if [ $CC -v 2>&1 | grep -E  "clang version|Apple LLVM version"  ] ; then
>
> and add to this file
>
> openbsd_j64) # nonavx here
> TARGET=libj.so
> COMPILE="$common"
> LINK=" -shared -Wl,-soname,libj.so -lm  $LDOPENMP -o libj.so "
>
> 5) add to build_tsdll.sh
> openbsd_j64)
> TARGET=libtsdll.so
> COMPILE="$common "
> LINK=" -shared -Wl,-soname,libtsdll.so -o libtsdll.so "
>
> 6) add to build_jconsole.sh
> openbsd_j64)
> COMPILE="$common"
> LINK=" -o jconsole "
>
> 7) ?should we also change this (have not done for now) in x15.c?
> #define SY_UNIX64 (SY_64 && (SY_LINUX || SY_MAC || SY_FREEBSD))
> to something like
> #define SY_UNIX64 (SY_64 && (SY_LINUX || SY_MAC || SY_FREEBSD ||
> SY_OPENBSD))
> and define SY_OPENBSD somewhere?
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] compilation from sources on OpenBSD, amd64, noavx

[bill lam]

unless you are using European locales, you can ignore that line.



On Fri, Apr 13, 2018, 8:54 PM Rudolf Sykora  wrote:

> Hello,
>
> I tried to compile jconsole + libj + libtsdll under OpenBSD.
> I managed (although I had to be hard; I seem to dislike the
> build system a lot).
>
> When I run jconsole now, I get the message
>
> |domain error: boot
> |   'libc.so.6 setlocale > x i *c'&(15!:0)^:(UNAME-:'Linux')1;,'C'
>
> (it originates from system/main/stdlib.ijs)
>
> Thus probably I still had to change something.
> Can anybody comment on this?
>
> For me there are too many #define in the sources at too many
> places... (j.h js.h x15.c)
>
> Thanks
> Ruda
>
> --
> PS.:
> So far I (probably not comprehensive, just for reference; not polished at
> all):
>
> 1) change #!/bin/bash to #!/bin/sh in the building scripts
>
> 2) keep jvars.sh inside the building tree, source it once to
> the shell that will be used for the building
> (and do not source it again anywhere)
>
> 2.5) put to jvars.sh:
> jplatform=openbsd
> and export it at the end
>
> 2.6) add to jsrc/js.h info about OPENBSD (what is really needed apart from
> finally having SY_64 1??)
> #define SYS_OPENBSD  8388608L
>
> #define SYS_UNIX(SYS_ATT3B1 + SYS_DEC5500 + SYS_IBMRS6000 + \
>  SYS_MIPS + SYS_NEXT + SYS_SGI + SYS_SUN3 + \
>  SYS_SUN4 + SYS_VAX + SYS_LINUX + SYS_MACOSX +
> \
>  SYS_FREEBSD + SYS_NETBSD + SYS_SUNSOL2 +
> SYS_HPUX+ \
> SYS_OPENBSD)
>
> #define SYS SYS_OPENBSD  ...just before testing if SYS is defined
> (towards the end)
>
> 3) run gmake instead of make (domake.sh)
>
> 4) change the line in build_libj.sh to:
> if [ $($CC -v 2>&1 | grep -E -c "clang\ version|Apple\ LLVM\ version")
> -eq 1 ] ; then
> or just say it'll be clang for us
> or sth like (?)
> if [ $CC -v 2>&1 | grep -E  "clang version|Apple LLVM version"  ] ; then
>
> and add to this file
>
> openbsd_j64) # nonavx here
> TARGET=libj.so
> COMPILE="$common"
> LINK=" -shared -Wl,-soname,libj.so -lm  $LDOPENMP -o libj.so "
>
> 5) add to build_tsdll.sh
> openbsd_j64)
> TARGET=libtsdll.so
> COMPILE="$common "
> LINK=" -shared -Wl,-soname,libtsdll.so -o libtsdll.so "
>
> 6) add to build_jconsole.sh
> openbsd_j64)
> COMPILE="$common"
> LINK=" -o jconsole "
>
> 7) ?should we also change this (have not done for now) in x15.c?
> #define SY_UNIX64 (SY_64 && (SY_LINUX || SY_MAC || SY_FREEBSD))
> to something like
> #define SY_UNIX64 (SY_64 && (SY_LINUX || SY_MAC || SY_FREEBSD ||
> SY_OPENBSD))
> and define SY_OPENBSD somewhere?
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] conditional check in jtjprx depends on uninitialized value

[bill lam]

Thank you for tracking this down.
The gcc compiler should be capable of detecting most of this kind of bugs,
but since it would produce lots of warnings and we got on one to audit
those one by one, so those warnings are suppressed by the
flag -Wno-maybe-uninitialized
If you remove this flag, perhaps you can get all those potential bugs and
check one by one. IIRC, The gcc idiom to suppress the warning if a variable
is known to be initialized before use is declared by something like
int nbx=nbx

On Fri, Mar 9, 2018, 4:55 AM Chris Double  wrote:

> Running jconsole through valgrind picked up a conditional check in
> jtjprx in f.c depending on an uninitialized value.
>
> The check occurs here:
>
>
> https://github.com/jsoftware/jsource/blob/332c18ced323d33ae50d9551ab4d52d18e158375/jsrc/f.c#L804
>
> The relevant code block being:
>
> case 1:
> // LIT characters. Copy them. If there were boxing characters about,
> copy one by one and translate if boxing chars
> // No need to suppress NULs - if the result is LIT, all boxes must
> have converted to LIT, and would have had NUL converted to space
> if(nbx){DO(c1, x=*v++; BDC(zv,x);); if(c1 // Otherwise just move fast
>
> Here, nbx can be uninitialized (ie. set to a random memory value)
> unless certain conditions are met with parsing.
>
> It is declared here:
>
>
> https://github.com/jsoftware/jsource/blob/332c18ced323d33ae50d9551ab4d52d18e158375/jsrc/f.c#L706
>
> static A jtjprx(J jt,I ieol,I maxlen,I lb,I la,A w){A y,z;B ch;C
> e,eov[2],*v,x,*zu,*zv;D lba; I c,c1,h,i,j,k,lc,m,nbx,nq,p,q,r,*s,t,zn;
>
> and is initialized in the following line:
>
>
> https://github.com/jsoftware/jsource/blob/332c18ced323d33ae50d9551ab4d52d18e158375/jsrc/f.c#L733
>
> if(ch||AT(w)+SPARSE)zn+=nbx=countonlines(scanbdc,t,v,h,nq,c,lb,la);
>
> It can be demonstrated outside of valgrind by adding a print statement
> just before the check in line 804 to print the value of nbx. With this
> print statement in affect, here's a console session:
>
> $ ./bin/jconsole
>1
> nbx: -1692375296
> 1
> <1
> nbx: 24
> 1
>
> $ ./bin/jconsole -lib libj-nonavx.so
>1
> nbx: 977359104
> 1
> <1
> nbx: 24
> 1
>
> Note that an unboxed expression shows random uninitialized values for
> nbx on each run. An expression containing the box character triggers
> the initialization in line 733 and shows a reasonable value.
>
> The net affect of this is that the "otherwise move fast" else block in
> the if loop probably never gets hit unless nbx happens to randomly
> initialize to zero.
>
> --
> http://bluishcoder.co.nz
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] Pull request for simplified build under Linux

[bill lam]

Just had a culsory look only, the patch uses uname to detect
platform. However this detects host platform rather than
target platform which is something else during
cross-compilation, eg building binaries for mingw or raspberry
on linux.  Better to provide more detail manual control with 
fallback to sensible defaults, but this might make build
scripts even more complex.

Сб, 03 фев 2018, Blake McBride написал(а):
> Greetings,
> 
> I have created a new patch request on github that simplifies the build
> process under Linux.  It eliminates the need for:
> 
> 1.  The sources to be in a particular directory
> 
> 2.  The need for environment variables
> 
> 3.  The need to edit or copy files
> 
> 4.  The need for more than one directory tree or files outside the source
> tree
> 
> If there is interest in it, I can adapt it to OSX and possibly other
> environments too.
> 
> Thanks.
> 
> Blake McBride
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] Linux AVX build

[bill lam]

I think your compiler does not support fma intrinsic so that function is
undefined and assumed returning int type. Please try removing the file from
source or replacing with an empty file. Using the file gemm_int-avx.c
should be sufficient.

What is the version of compiler you are using?



On Oct 10, 2017 4:01 AM, "Thomas Costigliola"  wrote:

I am trying to compile the AVX version of libj.so on Linux and I am getting
a
bunch of these errors in gemm_int-fma.c

jsrc/blis/gemm_int-fma.c:277:11: error: incompatible types when assigning to
type '__m256d' from type 'int'
 t0_00 = MM256_FMADD_PD(b_0, a_re, t0_00);
   ^
jsrc/blis/gemm_int-fma.c:278:11: error: incompatible types when assigning to
type '__m256d' from type 'int'
 t0_01 = MM256_FMADD_PD(b_1, a_re, t0_01);

Any idea what is causing this?


--
For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] Contribution bug fix

[bill lam]

Thank you for your contribution, but I am incapable of signing off commits
related to calculus.


On Sep 16, 2017 1:33 AM, "Joe Bogner"  wrote:

Hey Jon - I don't have the answer but wanted to say thank you. I don't use
d. however it's great to see more contributors to J source.

On Wed, Sep 13, 2017 at 8:15 PM, 'Jon Hough' via Source <
sou...@jsoftware.com> wrote:

> I have fixed a bug in the J source code. Namely, I have fixed d. handling
> of integrating reciprocal powers.
> e.g. (^&_3) d. _1
> I have also tested the fix with gddot.ijs (the relevant test script) and
> all tests pass (I think more tests need to be added though).
>
> How should I get this fix into J source?
>
> Regards,
> Jon
> --
> 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

Re: [Jsource] Porting qtide 1.5.3 to ArmV8-a Cortex-a53 aarch64, Pine64

[bill lam]

Good to hear all demos works. Those quickview demos will not
run under both slim and full version. Instead you need a 
fat version.  To build a fat jqt, export JQTFAT before make.
Prebuilt fat versions of jqt are not provided in order to
cut down Qt lib size and ease deployment packaging.

Чт, 03 авг 2017, Edward Clinton Harold Deveaux написал(а):
> Compiled qtide 1.5.3 to Pinebook under Ubuntu Mate 16.04
> 
> Using 2GB Ram and aarch64 64 bit OS.
> 
> 1. Using qt5 5.5.1,  Using j805 Engine I ported see earlier post.
> 
> 2. All Qt demos appear to work except: quickview1, quickview2 and
> quichwidget.
> 
> 3. Webgl runs with a Framerate:24fps
> 
> 4. Opengl shader runs, GL_VERSION: 3.0 Mesa 17.0.7
> 
> When installing.
> 
> Setup by:
> 
> 1. install j805 engine.
> 
> 2. configure.
> 
> 3. start jconsole
> 
> 4. install 'all'
> 
> 5. Copy jconsole, libj.so and libtsdll.so.
> 
> 6. Copy libjqt.so.1.5.3 and set soft links.
> 
> NB. Install 'all', downloads and overwrites ARM aarch64 binaries.
> 
> Added clean.pine64, and makepine64.sh. Changed default to qt5.
> 
>  ./makepine64.sh to build qtide library, compiles 38,000 lines C++ in 22
> minutes.
> 
> I will make changes to use j806 engine source and post results.
> 
> Thanks to Bill for his suggestions.
> 
> qtide patch is attached:
> 
> 
> Ed Deveaux
> 
> e...@rawbw.com
> 
> 470-330-0665
> 

> diff -crBN qtide-1.5.3/clean.pine64 qtide-1.5.3Pinebook/clean.pine64
> *** qtide-1.5.3/clean.pine64  1969-12-31 19:00:00.0 -0500
> --- qtide-1.5.3Pinebook/clean.pine64  2017-08-02 23:00:13.0 -0400
> ***
> *** 0 
> --- 1,7 
> + #!/bin/bash
> + 
> + S=$(dirname "$0")
> + 
> + rm -rf $S/bin/linux-aarch64
> + rm -rf $S/lib/build/linux-aarch64
> + rm -rf $S/main/build/linux-aarch64
> diff -crBN qtide-1.5.3/lib/lib.pro qtide-1.5.3Pinebook/lib/lib.pro
> *** qtide-1.5.3/lib/lib.pro   2016-12-11 12:32:40.0 -0500
> --- qtide-1.5.3Pinebook/lib/lib.pro   2017-08-02 23:00:13.0 -0400
> ***
> *** 75,80 
> --- 75,83 
>   linux-raspi: QMAKE_TARGET.arch = armv6l
>   linux-armv6l: QMAKE_TARGET.arch = armv6l
>   
> + # echd Sun 30 July 2017 added,  This builds in 22 minutes on my Pinebook   
> + equals(QMAKE_TARGET.arch , aarch64): QMAKE_CXXFLAGS += -march=armv8-a+crc 
> -mtune=cortex-a53
> +   
>   equals(QMAKE_TARGET.arch , i686): QMAKE_TARGET.arch = x86
>   ABI=$$(ABI)
>   
> diff -crBN qtide-1.5.3/makepine64.sh qtide-1.5.3Pinebook/makepine64.sh
> *** qtide-1.5.3/makepine64.sh 1969-12-31 19:00:00.0 -0500
> --- qtide-1.5.3Pinebook/makepine64.sh 2017-08-02 23:00:13.0 -0400
> ***
> *** 0 
> --- 1,15 
> + #!/bin/bash
> + #
> + # run in jqt directory
> + 
> + S=$(dirname "$0")
> + 
> + ./clean.sh
> + ./clean.pine64
> + 
> + cd lib
> + qmake  && make 
> + cd ..
> + 
> + cd main
> + qmake  && make 

> --
> For information about J forums see http://www.jsoftware.com/forums.htm


-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] Porting J805 Engine to ArmV8-a Cortex-a53 aarch64, Pine64

[bill lam]

J805 provides no optimization for armv64. If you build from
J806 and define C_CRC32C=1 then it will make similar improvement
with that of avx. see Android.mk.

Ср, 02 авг 2017, Edward Clinton Harold Deveaux написал(а):
> The pinebook is a $100.00 laptop from China, 2GB Ram and a quad core Arm64
> cortex-a53 processor.
> 
> I upgraded my pinebook with a 64GB eMMC chip, $31, to make room for software
> development files.
> 
> The environment is Ubuntu Mate 16.04 Linux, running in ArmV8-a, aarch64.
> 
> See: http:www.pine64.org/pinebook/ for more about this laptop.
> 
> 1. Downloaded, jsource-j805-release-final from the gpl repositories.
> 
> 2. Compiled 47k lines of code on the pinebook in 6 minutes.
> 
> 3. Ran all the jconsole engine test scripts successfully.
> 
> 4. Successfully ran my own j programs from my x86-64, iMac and Linux
> machines.
> 
> 5. To update run, install all in jconsole, then copy jconsole, libj.so and
> libtsdll.so to bin.
> 
> 6. Also copy jqtide binary files.
> 
> NB. install 'all' downloads x86-64 binaries.
> 
> NB. -j5 added to make options.
> 
> NB. -march=armv8-a+crc -mtune=cortex-a53 and -DC_NA=1  added to COMPILE
> 
> A patch for the j805-source-final is attached.
> 
> 
> Note: Information on porting the jqtide appears in another e-mail.
> 
> Ed Deveaux
> 
> e...@rawbw.com
> 
> 470-330-0655
> 

> diff -crBN jsource-j805-release-final/jsrc/jversion.h 
> jsource-j805-release-finalPinebook/jsrc/jversion.h
> *** jsource-j805-release-final/jsrc/jversion.h1969-12-31 
> 19:00:00.0 -0500
> --- jsource-j805-release-finalPinebook/jsrc/jversion.h2017-08-02 
> 19:17:34.0 -0400
> ***
> *** 0 
> --- 1,5 
> + #define jversion   "805" 
> + #define jplatform "linuxA64"  // AArch64-Arm64 
> windows/linux/darwin/raspberry/android/...
> + #define jtype   "release-final" // release,beta,... may include 
> bug level such as beta-3
> + #define jlicense   "GPL3"
> + #define jbuilder   "e...@rawbw.com"  // website or email
> diff -crBN jsource-j805-release-final/make/build_all.sh 
> jsource-j805-release-finalPinebook/make/build_all.sh
> *** jsource-j805-release-final/make/build_all.sh  2016-12-10 
> 22:06:13.0 -0500
> --- jsource-j805-release-finalPinebook/make/build_all.sh  2017-08-02 
> 19:17:34.0 -0400
> ***
> *** 1,13 
>   #!/bin/bash
> ! # build all binaries
>   cd ~
> ! . jvars.sh
>   
>   $jmake/install.sh
>   
> ! $jmake/build_jconsole.sh j32
> ! $jmake/build_libj.sh j32
> ! $jmake/build_tsdll.shj32
>   
>   if [ $jplatform = "raspberry" ]; then
> exit 0
> --- 1,13 
>   #!/bin/bash
> ! # build all binaries bypass j32 binaries
>   cd ~
> ! . ./jvars.sh
>   
>   $jmake/install.sh
>   
> ! #$jmake/build_jconsole.sh j32
> ! #$jmake/build_libj.sh j32
> ! #$jmake/build_tsdll.shj32
>   
>   if [ $jplatform = "raspberry" ]; then
> exit 0
> diff -crBN jsource-j805-release-final/make/build_jconsole.sh 
> jsource-j805-release-finalPinebook/make/build_jconsole.sh
> *** jsource-j805-release-final/make/build_jconsole.sh 2016-12-10 
> 22:06:13.0 -0500
> --- jsource-j805-release-finalPinebook/make/build_jconsole.sh 2017-08-02 
> 19:17:34.0 -0400
> ***
> *** 1,12 
>   #!/bin/bash
>   # $1 is j32 or j64
>   cd ~
> ! . jvars.sh
>   
>   common=" -fPIC -O1 -Wextra "
>   
>   case $jplatform\_$1 in
>   
>   linux_j32)
>   COMPILE="$common -m32 -DREADLINE"
>   LINK=" $jgit/unix/libedit.a -m32 -ldl -l:libncursesw.so.5.9 
> -l:libtinfo.so.5.9 -o jconsole "
> --- 1,17 
>   #!/bin/bash
>   # $1 is j32 or j64
>   cd ~
> ! . ./jvars.sh
>   
>   common=" -fPIC -O1 -Wextra "
>   
>   case $jplatform\_$1 in
>   
> + linuxA64_j64)
> + COMPILE="-fpic -march=armv8-a+crc -mtune=cortex-a53  -O2 -pipe -DC_NA=1 
> -DREADLINE"
> + LINK=" -ledit -ldl -lncursesw -o jconsole "
> + ;;
> + 
>   linux_j32)
>   COMPILE="$common -m32 -DREADLINE"
>   LINK=" $jgit/unix/libedit.a -m32 -ldl -l:libncursesw.so.5.9 
> -l:libtinfo.so.5.9 -o jconsole "
> diff -crBN jsource-j805-release-final/make/build_libj.sh 
> jsource-j805-release-finalPinebook/make/build_libj.sh
> *** jsource-j805-release-final/make/build_libj.sh 2016-12-10 
> 22:06:13.0 -0500
> --- jsource-j805-release-finalPinebook/make/build_libj.sh 2017-08-02 
> 19:17:34.0 -0400
> ***
> *** 1,7 
>   #!/bin/bash
>   # $1 is j32 or j64
>   cd ~
> ! . jvars.sh
>   
>   # gcc 5 vs 4 - killing off linux asm routines (overflow detection)
>   # new fast code uses builtins not available in gcc 4
> --- 1,7 
>   #!/bin/bash
>   # $1 is j32 or j64
>   cd ~
> ! . ./jvars.sh
>   
>   # gcc 5 vs 4 - killing off linux asm routines (overflow detection)
>   # new fast code uses builtins not available in gcc 4
> ***
> *** 18,23 
> --- 18,28 
>   
>   case $jplatform\_$1 in
>   
> + linuxA64_j64) # linux Arm64 aarch64 Little Endian
> + TARGET=libj.so
> + COMPILE="-fpic 

Re: [Jsource] GCC compile failure - BLIS

[bill lam]

in the file blis.h, change the line
#elif defined(__GNUC__)
to
#elif 0

vector extension is useful for those cpu such as powerpc that have simd
unit but lack blis microkernel. For arm family, only arm64 neon is a decent
simd unit. armv7 neon does not support double precision float. vpf is not
even a simd unit.

On Jul 14, 2017 1:54 AM, "Thomas Costigliola"  wrote:

Undefining __GNUC__ seemed to work.


On 07/13/2017 01:51 PM, Thomas Costigliola wrote:

> Thanks Bill, but how do I disable it in blis.h?
>
> On 07/12/2017 06:05 PM, Bill wrote:
>
>> gcc vector extension seems available for some years
>>   https://gcc.gnu.org/onlinedocs/gcc-3.3.4/gcc/Vector-Extensions.html
>>
>> It also complied successfully for raspberry using linaro gcc toolchain.
>> Perhaps kindle toolchain is special. If you cannot fix it then you may
>> disable it in blis.h and let it fall through to c ref version. Performance
>> will be more or less the same (no improvement) if there is no decent
>> hardware simd support.
>>
>> Sent from my iPhone
>>
>> On 13 Jul, 2017, at 3:29 AM, Thomas Costigliola  wrote:
>>
>> I am using an old version of GCC built to target the kindle (arm
>>> architecture).
>>>
>>> gcc version 4.5.4 20110505 (prerelease) (Linaro GCC 4.5-2011.05-0)
>>>
>>> The new BLIS routines are causing compilation failures as follows:
>>>
>>> jsrc/blis/gemm_vec-ref.c: In function 'bli_zgemm_128_3x2':
>>> jsrc/blis/gemm_vec-ref.c:582:11: error: subscripted value is neither
>>> array nor pointer
>>> jsrc/blis/gemm_vec-ref.c:582:11: error: subscripted value is neither
>>> array nor pointer
>>> jsrc/blis/gemm_vec-ref.c:583:11: error: subscripted value is neither
>>> array nor pointer
>>>
>>>
>>> It seems like a GCC version, behavior issue. Is there either 1) a quick
>>> syntax fix that will get it to compile or 2) a way to disable the BLIS
>>> routines? Or are they required in the latest J engine?
>>>
>>> Thanks,
>>> -Thomas
>>>
>>> --
>>> 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

Re: [Jsource] This code worked in J805

[bill lam]

I tested a little bit more. It seems more work is required.

   ,~ < $. 1 0 0 2
┌─┬─┐
│0 │ 1│0 │ 1│
│3 │ 2│3 │ 2│
└─┴─┘
(<2 3 4 5),< $. 1 0 0 2
┌───┬─┐
│2 3 4 5│0 │ 1│
│   │3 │ 2│
└───┴─┘
   /: (<2 3 4 5),< $. 1 0 0 2
(segfault)

Вс, 11 июн 2017, bill lam написал(а):
> I applied your patch to the latest git repos, and it ran without
> any crash.
>< $. 1 0 0 2
> ┌─┐
> │0 │ 1│
> │3 │ 2│
> └─┘
> 
> 
> Пт, 02 июн 2017, Thomas Costigliola написал(а):
> > I have this patch that implements sparse boxing that worked in the J805
> > engine. Sometime between 805 and 806 it stopped working and now crashes the
> > interpreter during or after the result gets freed.
> > 
> > < $. 1 0 0 2
> > 
> > Can someone (Henry) explain what changed?
> > 
> > Here is the patch:
> > 
> > diff --git a/jsrc/cu.c b/jsrc/cu.c
> > index ea70060..db2166c 100644
> > --- a/jsrc/cu.c
> > +++ b/jsrc/cu.c
> > @@ -9,7 +9,7 @@
> > 
> >  static A jteverysp(J jt,A w,A fs,AF f1){A*wv,x,z,*zv;P*wp,*zp;
> >   RZ(w);
> > - ASSERT(SBOX(w),EVNONCE);
> > + //ASSERT(SBOX(w),EVNONCE);
> >   RZ(z=ca(w));
> >   wp=PAV(w); x=SPA(wp,x); wv=AAV(x);
> >   zp=PAV(z); x=SPA(zp,x); zv=AAV(x);
> > @@ -17,7 +17,7 @@ static A jteverysp(J jt,A w,A fs,AF
> > f1){A*wv,x,z,*zv;P*wp,*zp;
> >   R z;
> >  }
> > 
> > -#define EVERYI(exp)  {RZ(*zv++=x=exp); ASSERT(!(SPARSE(x)),EVNONCE);}
> > +#define EVERYI(exp)  {RZ(*zv++=x=exp);
> > /*ASSERT(!(SPARSE(x)),EVNONCE);*/}
> >   /* note: x can be non-noun */
> > 
> >  A jtevery(J jt,A w,A fs,AF f1){A*wv,x,z,*zv;I wd;
> > diff --git a/jsrc/vo.c b/jsrc/vo.c
> > index 29d118c..a8b20ac 100644
> > --- a/jsrc/vo.c
> > +++ b/jsrc/vo.c
> > @@ -17,8 +17,22 @@ F1(jtlevel1){RZ(w); R sc(level(w));}
> > 
> >  F1(jtbox0){R irs1(w,0L,0L,jtbox);}
> > 
> > +F1(jtboxsp){A z, *zv;I r, n;
> > + if(jt->rank){
> > +  r=jt->rank[1]; jt->rank=0;
> > +  z=denseit(w);
> > +  z=df1(z,qq(ds(CLT),sc(r)));
> > +  z=every(z,0,jtsparse1);
> > + }else{
> > +  GATV(z,BOX,1,0,0); zv=AAV(z);
> > +  rat1(w); *zv=w;
> > + }
> > + R z;
> > +}
> > +
> >  F1(jtbox){A y,z,*zv;C*wv,*yv;I f,k,m,n,r,wr,*ws;
> >   RZ(w);
> > + if(SPARSE(w)) R jtboxsp(jt,w);
> >   ASSERT(!(SPARSE(w)),EVNONCE);
> >   ws=AS(w); wr=AR(w); r=jt->rank?jt->rank[1]:wr; f=wr-r;
> >   RE(n=prod(f,ws)); if(n)m=AN(w)/n; else RE(m=prod(r,f+ws));
> > 
> > --
> > For information about J forums see http://www.jsoftware.com/forums.htm
> 
> -- 
> regards,
> 
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3

-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] This code worked in J805

[bill lam]

I applied your patch to the latest git repos, and it ran without
any crash.
   < $. 1 0 0 2
┌─┐
│0 │ 1│
│3 │ 2│
└─┘


Пт, 02 июн 2017, Thomas Costigliola написал(а):
> I have this patch that implements sparse boxing that worked in the J805
> engine. Sometime between 805 and 806 it stopped working and now crashes the
> interpreter during or after the result gets freed.
> 
> < $. 1 0 0 2
> 
> Can someone (Henry) explain what changed?
> 
> Here is the patch:
> 
> diff --git a/jsrc/cu.c b/jsrc/cu.c
> index ea70060..db2166c 100644
> --- a/jsrc/cu.c
> +++ b/jsrc/cu.c
> @@ -9,7 +9,7 @@
> 
>  static A jteverysp(J jt,A w,A fs,AF f1){A*wv,x,z,*zv;P*wp,*zp;
>   RZ(w);
> - ASSERT(SBOX(w),EVNONCE);
> + //ASSERT(SBOX(w),EVNONCE);
>   RZ(z=ca(w));
>   wp=PAV(w); x=SPA(wp,x); wv=AAV(x);
>   zp=PAV(z); x=SPA(zp,x); zv=AAV(x);
> @@ -17,7 +17,7 @@ static A jteverysp(J jt,A w,A fs,AF
> f1){A*wv,x,z,*zv;P*wp,*zp;
>   R z;
>  }
> 
> -#define EVERYI(exp)  {RZ(*zv++=x=exp); ASSERT(!(SPARSE(x)),EVNONCE);}
> +#define EVERYI(exp)  {RZ(*zv++=x=exp);
> /*ASSERT(!(SPARSE(x)),EVNONCE);*/}
>   /* note: x can be non-noun */
> 
>  A jtevery(J jt,A w,A fs,AF f1){A*wv,x,z,*zv;I wd;
> diff --git a/jsrc/vo.c b/jsrc/vo.c
> index 29d118c..a8b20ac 100644
> --- a/jsrc/vo.c
> +++ b/jsrc/vo.c
> @@ -17,8 +17,22 @@ F1(jtlevel1){RZ(w); R sc(level(w));}
> 
>  F1(jtbox0){R irs1(w,0L,0L,jtbox);}
> 
> +F1(jtboxsp){A z, *zv;I r, n;
> + if(jt->rank){
> +  r=jt->rank[1]; jt->rank=0;
> +  z=denseit(w);
> +  z=df1(z,qq(ds(CLT),sc(r)));
> +  z=every(z,0,jtsparse1);
> + }else{
> +  GATV(z,BOX,1,0,0); zv=AAV(z);
> +  rat1(w); *zv=w;
> + }
> + R z;
> +}
> +
>  F1(jtbox){A y,z,*zv;C*wv,*yv;I f,k,m,n,r,wr,*ws;
>   RZ(w);
> + if(SPARSE(w)) R jtboxsp(jt,w);
>   ASSERT(!(SPARSE(w)),EVNONCE);
>   ws=AS(w); wr=AR(w); r=jt->rank?jt->rank[1]:wr; f=wr-r;
>   RE(n=prod(f,ws)); if(n)m=AN(w)/n; else RE(m=prod(r,f+ws));
> 
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] Help compiling jsource?

[bill lam]

Glad that it now works for you. jsouce will be patched to
decommit TMPDIR or let it to be applicable to android only.

Сб, 10 июн 2017, Ric Tikkanz написал(а):
> thanks Bill,
> I'd tried unsetting $TMPDIR and it worked, but was a bit of a pain.
> I can confirm that your suggested change to xh.c fixed my problem.
> 
> Thanks again!
> 
> On Fri, Jun 9, 2017 at 3:04 AM, bill lam <bbill@gmail.com> wrote:
> 
> > inside xh.c, look for the lines
> >
> > > const char*ftmp=getenv("TMPDIR");  /* android always define TMPDIR in
> > jeload */
> > > strcpy(fn,ftmp?ftmp:(char*)"/tmp");
> >
> > $TMPDIR was only intended for android, since it has no /tmp
> > directory. On the other hand, $TMPDIR is not a posix standard,
> > /tmp is always present in linux. You may try, either unset
> > $TMPDIR before running jconsole or change the line into
> >
> > > strcpy(fn,(char*)"/tmp");
> >
> > Чт, 08 июн 2017, Ric Tikkanz написал(а):
> > > The mystery appears to have been solved. It seems jengine segfaults when
> > > $TMPDIR is longer than 27 characters. Inside a Slurm job it is getting
> > set
> > > to something like "/tmp/jobs/$USERNAME/63964409" (so that the Slurm
> > > "epilog" can remove any leftover temporary files at the end of the job),
> > > and my user name is longer than the support guy's user name.
> > >
> > > Does the 27 character limit make sense? Is there any reason not to
> > increase
> > > this?
> > >
> > > On Wed, Jun 7, 2017 at 11:10 PM, Ric Sherlock <tikk...@gmail.com> wrote:
> > >
> > > > I meant that I got the same result when I ran the commands above. I
> > didn't
> > > > check the file itself.
> > > >
> > > > When I do:
> > > > gdb ./jconsole core.
> > > > > run
> > > > then J seems to work OK.
> > > >
> > > > I've attached the libj.so
> > > >
> > > > On Wed, Jun 7, 2017 at 10:43 PM, bill lam <bbill@gmail.com> wrote:
> > > >
> > > >> What is no difference? Can you email me your libj.so to try?
> > > >>
> > > >> Ср, 07 июн 2017, Ric Tikkanz написал(а):
> > > >> > Tried again with -ggdb with no difference
> > > >> >
> > > >> > On Wed, Jun 7, 2017 at 10:22 PM, Ric Sherlock <tikk...@gmail.com>
> > > >> wrote:
> > > >> >
> > > >> > > Can try again with that. I used it the first time in build_libj
> > but
> > > >> gdb
> > > >> > > was reporting no symbols, googling around for using gdb I found a
> > > >> bunch of
> > > >> > > pages suggesting -g. Used that with no change, until I realised I
> > > >> needed to
> > > >> > > change build_jconsole.sh too.
> > > >> > >
> > > >> > > On Wed, Jun 7, 2017 at 10:17 PM, bill lam <bbill@gmail.com>
> > > >> wrote:
> > > >> > >
> > > >> > >> Not sure what had gone wrong.  I usually build debug version
> > > >> > >> with -ggdb since this work better with gdb.
> > > >> > >>
> > > >> > >> What was the problem with -ggdb ?
> > > >> > >>
> > > >> > >> Ср, 07 июн 2017, Ric Tikkanz написал(а):
> > > >> > >> > Thanks Bill,
> > > >> > >> > I made the change you suggested (but used -g rather than
> > -ggdb) as
> > > >> well
> > > >> > >> as
> > > >> > >> > a similar change in build_jconsole.sh and then ran through the
> > make
> > > >> > >> process
> > > >> > >> > including install.sh and clean.sh
> > > >> > >> >
> > > >> > >> > I started a SLURM environment, set $ ulimit -c unlimited
> > > >> > >> > I then ran $ gdb ./jconsole
> > > >> > >> > which generated a core dump file.
> > > >> > >> >
> > > >> > >> > I then exited the SLURM environment and ran gdb on the core
> > dump,
> > > >> with
> > > >> > >> the
> > > >> > >> > result below.
> > > >> > >> > Looks less than illuminating? Am I missing s

Re: [Jsource] Help compiling jsource?

[bill lam]

inside xh.c, look for the lines

> const char*ftmp=getenv("TMPDIR");  /* android always define TMPDIR in jeload 
> */
> strcpy(fn,ftmp?ftmp:(char*)"/tmp");

$TMPDIR was only intended for android, since it has no /tmp
directory. On the other hand, $TMPDIR is not a posix standard,
/tmp is always present in linux. You may try, either unset
$TMPDIR before running jconsole or change the line into
 
> strcpy(fn,(char*)"/tmp");

Чт, 08 июн 2017, Ric Tikkanz написал(а):
> The mystery appears to have been solved. It seems jengine segfaults when
> $TMPDIR is longer than 27 characters. Inside a Slurm job it is getting set
> to something like "/tmp/jobs/$USERNAME/63964409" (so that the Slurm
> "epilog" can remove any leftover temporary files at the end of the job),
> and my user name is longer than the support guy's user name.
> 
> Does the 27 character limit make sense? Is there any reason not to increase
> this?
> 
> On Wed, Jun 7, 2017 at 11:10 PM, Ric Sherlock <tikk...@gmail.com> wrote:
> 
> > I meant that I got the same result when I ran the commands above. I didn't
> > check the file itself.
> >
> > When I do:
> > gdb ./jconsole core.
> > > run
> > then J seems to work OK.
> >
> > I've attached the libj.so
> >
> > On Wed, Jun 7, 2017 at 10:43 PM, bill lam <bbill@gmail.com> wrote:
> >
> >> What is no difference? Can you email me your libj.so to try?
> >>
> >> Ср, 07 июн 2017, Ric Tikkanz написал(а):
> >> > Tried again with -ggdb with no difference
> >> >
> >> > On Wed, Jun 7, 2017 at 10:22 PM, Ric Sherlock <tikk...@gmail.com>
> >> wrote:
> >> >
> >> > > Can try again with that. I used it the first time in build_libj but
> >> gdb
> >> > > was reporting no symbols, googling around for using gdb I found a
> >> bunch of
> >> > > pages suggesting -g. Used that with no change, until I realised I
> >> needed to
> >> > > change build_jconsole.sh too.
> >> > >
> >> > > On Wed, Jun 7, 2017 at 10:17 PM, bill lam <bbill@gmail.com>
> >> wrote:
> >> > >
> >> > >> Not sure what had gone wrong.  I usually build debug version
> >> > >> with -ggdb since this work better with gdb.
> >> > >>
> >> > >> What was the problem with -ggdb ?
> >> > >>
> >> > >> Ср, 07 июн 2017, Ric Tikkanz написал(а):
> >> > >> > Thanks Bill,
> >> > >> > I made the change you suggested (but used -g rather than -ggdb) as
> >> well
> >> > >> as
> >> > >> > a similar change in build_jconsole.sh and then ran through the make
> >> > >> process
> >> > >> > including install.sh and clean.sh
> >> > >> >
> >> > >> > I started a SLURM environment, set $ ulimit -c unlimited
> >> > >> > I then ran $ gdb ./jconsole
> >> > >> > which generated a core dump file.
> >> > >> >
> >> > >> > I then exited the SLURM environment and ran gdb on the core dump,
> >> with
> >> > >> the
> >> > >> > result below.
> >> > >> > Looks less than illuminating? Am I missing something?
> >> > >> >
> >> > >> > $ gdb ./jconsole core.10302
> >> > >> > GNU gdb (GDB) 7.12
> >> > >> > Copyright (C) 2016 Free Software Foundation, Inc.
> >> > >> > License GPLv3+: GNU GPL version 3 or later <
> >> > >> http://gnu.org/licenses/gpl.html
> >> > >> > >
> >> > >> > This is free software: you are free to change and redistribute it.
> >> > >> > There is NO WARRANTY, to the extent permitted by law.  Type "show
> >> > >> copying"
> >> > >> > and "show warranty" for details.
> >> > >> > This GDB was configured as "x86_64-pc-linux-gnu".
> >> > >> > Type "show configuration" for configuration details.
> >> > >> > For bug reporting instructions, please see:
> >> > >> > <http://www.gnu.org/software/gdb/bugs/>.
> >> > >> > Find the GDB manual and other documentation resources online at:
> >> > >> > <http://www.gnu.org/software/gdb/documentation/>.
> >> >

Re: [Jsource] Help compiling jsource?

[bill lam]

What is no difference? Can you email me your libj.so to try?

Ср, 07 июн 2017, Ric Tikkanz написал(а):
> Tried again with -ggdb with no difference
> 
> On Wed, Jun 7, 2017 at 10:22 PM, Ric Sherlock <tikk...@gmail.com> wrote:
> 
> > Can try again with that. I used it the first time in build_libj but gdb
> > was reporting no symbols, googling around for using gdb I found a bunch of
> > pages suggesting -g. Used that with no change, until I realised I needed to
> > change build_jconsole.sh too.
> >
> > On Wed, Jun 7, 2017 at 10:17 PM, bill lam <bbill@gmail.com> wrote:
> >
> >> Not sure what had gone wrong.  I usually build debug version
> >> with -ggdb since this work better with gdb.
> >>
> >> What was the problem with -ggdb ?
> >>
> >> Ср, 07 июн 2017, Ric Tikkanz написал(а):
> >> > Thanks Bill,
> >> > I made the change you suggested (but used -g rather than -ggdb) as well
> >> as
> >> > a similar change in build_jconsole.sh and then ran through the make
> >> process
> >> > including install.sh and clean.sh
> >> >
> >> > I started a SLURM environment, set $ ulimit -c unlimited
> >> > I then ran $ gdb ./jconsole
> >> > which generated a core dump file.
> >> >
> >> > I then exited the SLURM environment and ran gdb on the core dump, with
> >> the
> >> > result below.
> >> > Looks less than illuminating? Am I missing something?
> >> >
> >> > $ gdb ./jconsole core.10302
> >> > GNU gdb (GDB) 7.12
> >> > Copyright (C) 2016 Free Software Foundation, Inc.
> >> > License GPLv3+: GNU GPL version 3 or later <
> >> http://gnu.org/licenses/gpl.html
> >> > >
> >> > This is free software: you are free to change and redistribute it.
> >> > There is NO WARRANTY, to the extent permitted by law.  Type "show
> >> copying"
> >> > and "show warranty" for details.
> >> > This GDB was configured as "x86_64-pc-linux-gnu".
> >> > Type "show configuration" for configuration details.
> >> > For bug reporting instructions, please see:
> >> > <http://www.gnu.org/software/gdb/bugs/>.
> >> > Find the GDB manual and other documentation resources online at:
> >> > <http://www.gnu.org/software/gdb/documentation/>.
> >> > For help, type "help".
> >> > Type "apropos word" to search for commands related to "word"...
> >> > Reading symbols from ./jconsole...done.
> >> >
> >> > warning: core file may not match specified executable file.
> >> > [New LWP 10302]
> >> > Core was generated by `gdb ./jconsole'.
> >> > Program terminated with signal SIGSEGV, Segmentation fault.
> >> > #0  0x006e2e9b in ?? ()
> >> > (gdb) bt
> >> > #0  0x006e2e9b in ?? ()
> >> > #1  0x0001 in ?? ()
> >> > #2  0x2b0af52248c8 in ?? ()
> >> > #3  0x54552e53555f6e65 in ?? ()
> >> > #4  0x0040 in ?? ()
> >> > #5  0x00e69520 in ?? ()
> >> > #6  0x7fff8820d0e0 in ?? ()
> >> > #7  0x7fff8820d1e0 in ?? ()
> >> > #8  0x in ?? ()
> >> >
> >> >
> >> > On Wed, Jun 7, 2017 at 6:01 PM, bill lam <bbill@gmail.com> wrote:
> >> >
> >> > > Assuming you are using gcc,
> >> > > change a line in build_libj.sh
> >> > >
> >> > > common="$OPENMP -fPIC -O1 -fwrapv ...
> >> > >
> >> > > to
> >> > >
> >> > > common="$OPENMP -fPIC -ggdb -O0 -fwrapv ...
> >> > >
> >> > > and invoke ./jconsole as gdb ./jconsole
> >> > > run and wait for segfault.
> >> > >
> >> > > I got no idea what had happened.
> >> > >
> >> > > Ср, 07 июн 2017, Ric Tikkanz написал(а):
> >> > > > Ok so while I can successfully run jconsole and scripts on a build
> >> node
> >> > > on
> >> > > > the cluster (all tests pass), whenever I try to run J via SLURM
> >> workload
> >> > > > manager <https://slurm.schedmd.com/> using srun or sbatch I get a
> >> > > Segfault
> >> > > > and a core dump.
> >> > > >
> >> > > > I'm w

Re: [Jsource] Help compiling jsource?

[bill lam]

You need not built jconsole with debug, the no symbols reported
is normal because libj.so is not yet loaded when running 
gdb ./jconsole

only after you type run, it will actually start.

Ср, 07 июн 2017, Ric Tikkanz написал(а):
> Can try again with that. I used it the first time in build_libj but gdb was
> reporting no symbols, googling around for using gdb I found a bunch of
> pages suggesting -g. Used that with no change, until I realised I needed to
> change build_jconsole.sh too.
> 
> On Wed, Jun 7, 2017 at 10:17 PM, bill lam <bbill@gmail.com> wrote:
> 
> > Not sure what had gone wrong.  I usually build debug version
> > with -ggdb since this work better with gdb.
> >
> > What was the problem with -ggdb ?
> >
> > Ср, 07 июн 2017, Ric Tikkanz написал(а):
> > > Thanks Bill,
> > > I made the change you suggested (but used -g rather than -ggdb) as well
> > as
> > > a similar change in build_jconsole.sh and then ran through the make
> > process
> > > including install.sh and clean.sh
> > >
> > > I started a SLURM environment, set $ ulimit -c unlimited
> > > I then ran $ gdb ./jconsole
> > > which generated a core dump file.
> > >
> > > I then exited the SLURM environment and ran gdb on the core dump, with
> > the
> > > result below.
> > > Looks less than illuminating? Am I missing something?
> > >
> > > $ gdb ./jconsole core.10302
> > > GNU gdb (GDB) 7.12
> > > Copyright (C) 2016 Free Software Foundation, Inc.
> > > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.
> > html
> > > >
> > > This is free software: you are free to change and redistribute it.
> > > There is NO WARRANTY, to the extent permitted by law.  Type "show
> > copying"
> > > and "show warranty" for details.
> > > This GDB was configured as "x86_64-pc-linux-gnu".
> > > Type "show configuration" for configuration details.
> > > For bug reporting instructions, please see:
> > > <http://www.gnu.org/software/gdb/bugs/>.
> > > Find the GDB manual and other documentation resources online at:
> > > <http://www.gnu.org/software/gdb/documentation/>.
> > > For help, type "help".
> > > Type "apropos word" to search for commands related to "word"...
> > > Reading symbols from ./jconsole...done.
> > >
> > > warning: core file may not match specified executable file.
> > > [New LWP 10302]
> > > Core was generated by `gdb ./jconsole'.
> > > Program terminated with signal SIGSEGV, Segmentation fault.
> > > #0  0x006e2e9b in ?? ()
> > > (gdb) bt
> > > #0  0x006e2e9b in ?? ()
> > > #1  0x0001 in ?? ()
> > > #2  0x2b0af52248c8 in ?? ()
> > > #3  0x54552e53555f6e65 in ?? ()
> > > #4  0x0040 in ?? ()
> > > #5  0x00e69520 in ?? ()
> > > #6  0x7fff8820d0e0 in ?? ()
> > > #7  0x7fff8820d1e0 in ?? ()
> > > #8  0x in ?? ()
> > >
> > >
> > > On Wed, Jun 7, 2017 at 6:01 PM, bill lam <bbill@gmail.com> wrote:
> > >
> > > > Assuming you are using gcc,
> > > > change a line in build_libj.sh
> > > >
> > > > common="$OPENMP -fPIC -O1 -fwrapv ...
> > > >
> > > > to
> > > >
> > > > common="$OPENMP -fPIC -ggdb -O0 -fwrapv ...
> > > >
> > > > and invoke ./jconsole as gdb ./jconsole
> > > > run and wait for segfault.
> > > >
> > > > I got no idea what had happened.
> > > >
> > > > Ср, 07 июн 2017, Ric Tikkanz написал(а):
> > > > > Ok so while I can successfully run jconsole and scripts on a build
> > node
> > > > on
> > > > > the cluster (all tests pass), whenever I try to run J via SLURM
> > workload
> > > > > manager <https://slurm.schedmd.com/> using srun or sbatch I get a
> > > > Segfault
> > > > > and a core dump.
> > > > >
> > > > > I'm working with a Cluster support guy who is able to run fine, but
> > can
> > > > > confirm that if he logs in as me he gets the same error. I've copied
> > his
> > > > > last message below in case it is helpful to those of you who know
> > more
> > > > > about the internals of the system.
> > > > >
&

Re: [Jsource] Help compiling jsource?

[bill lam]

Not sure what had gone wrong.  I usually build debug version
with -ggdb since this work better with gdb.

What was the problem with -ggdb ?

Ср, 07 июн 2017, Ric Tikkanz написал(а):
> Thanks Bill,
> I made the change you suggested (but used -g rather than -ggdb) as well as
> a similar change in build_jconsole.sh and then ran through the make process
> including install.sh and clean.sh
> 
> I started a SLURM environment, set $ ulimit -c unlimited
> I then ran $ gdb ./jconsole
> which generated a core dump file.
> 
> I then exited the SLURM environment and ran gdb on the core dump, with the
> result below.
> Looks less than illuminating? Am I missing something?
> 
> $ gdb ./jconsole core.10302
> GNU gdb (GDB) 7.12
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
> >
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-pc-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./jconsole...done.
> 
> warning: core file may not match specified executable file.
> [New LWP 10302]
> Core was generated by `gdb ./jconsole'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x006e2e9b in ?? ()
> (gdb) bt
> #0  0x006e2e9b in ?? ()
> #1  0x0001 in ?? ()
> #2  0x2b0af52248c8 in ?? ()
> #3  0x54552e53555f6e65 in ?? ()
> #4  0x0040 in ?? ()
> #5  0x00e69520 in ?? ()
> #6  0x7fff8820d0e0 in ?? ()
> #7  0x7fff8820d1e0 in ?? ()
> #8  0x in ?? ()
> 
> 
> On Wed, Jun 7, 2017 at 6:01 PM, bill lam <bbill@gmail.com> wrote:
> 
> > Assuming you are using gcc,
> > change a line in build_libj.sh
> >
> > common="$OPENMP -fPIC -O1 -fwrapv ...
> >
> > to
> >
> > common="$OPENMP -fPIC -ggdb -O0 -fwrapv ...
> >
> > and invoke ./jconsole as gdb ./jconsole
> > run and wait for segfault.
> >
> > I got no idea what had happened.
> >
> > Ср, 07 июн 2017, Ric Tikkanz написал(а):
> > > Ok so while I can successfully run jconsole and scripts on a build node
> > on
> > > the cluster (all tests pass), whenever I try to run J via SLURM workload
> > > manager <https://slurm.schedmd.com/> using srun or sbatch I get a
> > Segfault
> > > and a core dump.
> > >
> > > I'm working with a Cluster support guy who is able to run fine, but can
> > > confirm that if he logs in as me he gets the same error. I've copied his
> > > last message below in case it is helpful to those of you who know more
> > > about the internals of the system.
> > >
> > > My questions are:
> > >   1. Is compiling J with debugger support relatively easy and if so are
> > > there any instructions?
> > >   2. Does the stack listing below suggest any potential problems
> > >
> > > Note I'm compiling the up-to-date master branch ( 05073eb 2017-06-05 ) of
> > > the github repository.
> > >
> > > == message from support guy ==
> > > OK now I can reproduce it when running as you, but I still don't know
> > what
> > > the difference is. It might help to compile it with debugging support -
> > > currently I can get a listing of the stack at the point it dies (below)
> > but
> > > not any line numbers or values of variables. From the source code it
> > seems
> > > the deepest part of this (*jtgaf*) is part of jengine's memory management
> > > code, which I guess isn't a surprise given that the symprom is a
> > segfault.
> > > As you can see, the function names are not very self-explanatory.
> > >
> > > #0  0x2b2de75608d6 in jtgaf () from
> > > /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> > > #1  0x2b2de7560ad1 in jtgafv () from
> > > /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> > > #2  0x2b2de7560bdd in jtga () from
> > > /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> > > #3  0x2b2de7655be

Re: [Jsource] Help compiling jsource?

[bill lam]

j64_806/bin/libj.so
> #31 0x2b2de754cf69 in jtparseas () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #32 0x2b2de754d592 in jtparsex () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #33 0x2b2de7548152 in jtxdefn () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #34 0x2b2de754923b in xn1 () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #35 0x2b2de751b286 in jtdfs1 () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #36 0x2b2de756466d in jtparsea () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #37 0x2b2de75650e1 in jtparse () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #38 0x2b2de75674dd in jtimmex () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #39 0x2b2de771f96e in jtline () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #40 0x2b2de771fe52 in jtlinf () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #41 0x2b2de77204db in jtscm00 () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #42 0x2b2de751b286 in jtdfs1 () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #43 0x2b2de756466d in jtparsea () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #44 0x2b2de75650e1 in jtparse () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #45 0x2b2de75674dd in jtimmex () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #46 0x2b2de771f96e in jtline () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #47 0x2b2de771fe52 in jtlinf () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #48 0x2b2de77204db in jtscm00 () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #49 0x2b2de751b286 in jtdfs1 () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #50 0x2b2de756466d in jtparsea () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #51 0x2b2de754cf69 in jtparseas () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #52 0x2b2de754d592 in jtparsex () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #53 0x2b2de7548152 in jtxdefn () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #54 0x2b2de754923b in xn1 () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #55 0x2b2de751b286 in jtdfs1 () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #56 0x2b2de756466d in jtparsea () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #57 0x2b2de75650e1 in jtparse () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #58 0x2b2de75674dd in jtimmex () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #59 0x2b2de755b6f2 in jdo () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #60 0x2b2de755b840 in JDo () from
> /gpfs1m/projects/nesi00187/tools/j64_806/bin/libj.so
> #61 0x004013c0 in jedo ()
> #62 0x00401770 in jefirst ()
> #63 0x00401307 in main ()
> 
> 
> On Sun, Jun 4, 2017 at 3:00 AM, Ric Sherlock <tikk...@gmail.com> wrote:
> 
> > Yes it will be more resilient to upgrades too I imagine!
> >
> > On Sun, Jun 4, 2017 at 2:45 AM, bill lam <bbill@gmail.com> wrote:
> >
> >> I think link to the major version is sufficient,
> >>
> >> +LINK=" -l:libedit.so.0 -ldl -o jconsole "
> >>
> >> Вс, 04 июн 2017, Ric Tikkanz написал(а):
> >> > Thanks Bill,
> >> > I ended up just editing the make/build_jconsole.sh as follows. This
> >> seems
> >> > to have done the trick for now so I can make some progress!
> >> >
> >> >  ...
> >> >  linux_j64)
> >> >  COMPILE="$common -DREADLINE"
> >> > -LINK=" -ledit -ldl -o jconsole "
> >> > +LINK=" -l:libedit.so.0.0.27 -ldl -o jconsole "
> >> >  ;;
> >> >  ...
> >> >
> >> > On Sun, Jun 4, 2017 at 12:13 AM, bill lam <bbill@gmail.com> wrote:
> >> >
> >> > > An easy way is not define READLINE in build but then you will miss
> >> readline
> >> > > facility.
> >> > >
> >> > > or symlink the file under your home folder and use LB_LIBRARY_PATH
> >> > > environment variable.
> >> > >
> >> > > On 3 Jun, 2017 8:04 pm, "Ric Sherlock" <tikk...@gmail.com> wrote:
> >> > >
> >> > > > That is why I was thinking I should build the system on 

Re: [Jsource] Help compiling jsource?

[bill lam]

I think link to the major version is sufficient,

+LINK=" -l:libedit.so.0 -ldl -o jconsole "

Вс, 04 июн 2017, Ric Tikkanz написал(а):
> Thanks Bill,
> I ended up just editing the make/build_jconsole.sh as follows. This seems
> to have done the trick for now so I can make some progress!
> 
>  ...
>  linux_j64)
>  COMPILE="$common -DREADLINE"
> -LINK=" -ledit -ldl -o jconsole "
> +LINK=" -l:libedit.so.0.0.27 -ldl -o jconsole "
>  ;;
>  ...
> 
> On Sun, Jun 4, 2017 at 12:13 AM, bill lam <bbill@gmail.com> wrote:
> 
> > An easy way is not define READLINE in build but then you will miss readline
> > facility.
> >
> > or symlink the file under your home folder and use LB_LIBRARY_PATH
> > environment variable.
> >
> > On 3 Jun, 2017 8:04 pm, "Ric Sherlock" <tikk...@gmail.com> wrote:
> >
> > > That is why I was thinking I should build the system on the rhel system?
> > > i.e. to make sure it has the versions that I'm linking to?
> > >
> > > I've had a go at this and am having an issue finding libedit.so
> > > $ $jmake/build_jconsole.sh j64
> > > jconsole
> > > -fPIC -O1 -Wextra -Wno-unused-parameter -DREADLINE
> > > -ledit -ldl -o jconsole
> > > cc  jconsole.o jeload.o-ledit -ldl -o jconsole
> > > /usr/bin/ld: cannot find -ledit
> > > collect2: ld returned 1 exit status
> > > make: *** [jconsole] Error 1
> > > cp: cannot stat `jconsole': No such file or directory
> > >
> > > I've found a copy on the system at /usr/lib64/libedit.so.0 or
> > > /usr/lib64/libedit.so.0.0.27 . If I had sudo access I'd create symlink to
> > > /usr/lib64/libedit.so but I don't. What other options do I have?
> > >
> > >
> > > On Sat, Jun 3, 2017 at 11:45 PM, bill lam <bbill@gmail.com> wrote:
> > >
> > > > Since you built on ubuntu 16.04, I suspect its glibc is still newer
> > than
> > > > that on rhel.
> > > >
> > > > On 3 Jun, 2017 7:29 pm, "Ric Sherlock" <tikk...@gmail.com> wrote:
> > > >
> > > > > Hi Bill,
> > > > > Thanks based on that suggestion I checked out master which
> > successfully
> > > > > built. Tests running now.
> > > > >
> > > > > So am I right in thinking that my next move is to build the system on
> > > the
> > > > > Red Hat server?
> > > > >
> > > > > On Sat, Jun 3, 2017 at 11:19 PM, bill lam <bbill@gmail.com>
> > wrote:
> > > > >
> > > > > > copy the file build_jconsole.sh from j806 head, there the
> > > > > > dependency on ncursesw has been killed off.
> > > > > >
> > > > > > Сб, 03 июн 2017, Ric Tikkanz написал(а):
> > > > > > > Hi guys,
> > > > > > > I'm trying to build J from source - the main incentive being to
> > try
> > > > and
> > > > > > get
> > > > > > > it running on a research compute cluster. (see post in beta
> > forum)
> > > > > > >
> > > > > > > I thought I'd start simple by cloning the source from github and
> > > > > building
> > > > > > > the j64-805 release branch on my local Ubuntu 16.04 machine, but
> > > came
> > > > > > > across a problem.
> > > > > > >
> > > > > > > ~$ $jmake/build_jconsole.sh j64
> > > > > > > jconsole
> > > > > > > -fPIC -O1 -Wextra -DREADLINE
> > > > > > > /home/rishe0/gitdev/jsource/unix/libedit64.a -ldl -lncursesw -o
> > > > > jconsole
> > > > > > > cc  -fPIC -O1 -Wextra  -DREADLINE   -c -o jconsole.o
> > > > > > > /home/rishe0/gitdev/jsource/jsrc/jconsole.c
> > > > > > > cc  -fPIC -O1 -Wextra  -DREADLINE   -c -o jeload.o
> > > > > > > /home/rishe0/gitdev/jsource/jsrc/jeload.c
> > > > > > > /home/rishe0/gitdev/jsource/jsrc/jeload.c: In function ‘jepath’:
> > > > > > > /home/rishe0/gitdev/jsource/jsrc/jeload.c:139:3: warning:
> > ignoring
> > > > > > return
> > > > > > > value of ‘getcwd’, declared with attribute warn_unused_result
> > > > > > > [-Wunused-result]
> > > > > > >getcwd(path,sizeof(path));
> > > > > > >^
> > 

Re: [Jsource] Help compiling jsource?

[bill lam]

An easy way is not define READLINE in build but then you will miss readline
facility.

or symlink the file under your home folder and use LB_LIBRARY_PATH
environment variable.

On 3 Jun, 2017 8:04 pm, "Ric Sherlock" <tikk...@gmail.com> wrote:

> That is why I was thinking I should build the system on the rhel system?
> i.e. to make sure it has the versions that I'm linking to?
>
> I've had a go at this and am having an issue finding libedit.so
> $ $jmake/build_jconsole.sh j64
> jconsole
> -fPIC -O1 -Wextra -Wno-unused-parameter -DREADLINE
> -ledit -ldl -o jconsole
> cc  jconsole.o jeload.o-ledit -ldl -o jconsole
> /usr/bin/ld: cannot find -ledit
> collect2: ld returned 1 exit status
> make: *** [jconsole] Error 1
> cp: cannot stat `jconsole': No such file or directory
>
> I've found a copy on the system at /usr/lib64/libedit.so.0 or
> /usr/lib64/libedit.so.0.0.27 . If I had sudo access I'd create symlink to
> /usr/lib64/libedit.so but I don't. What other options do I have?
>
>
> On Sat, Jun 3, 2017 at 11:45 PM, bill lam <bbill@gmail.com> wrote:
>
> > Since you built on ubuntu 16.04, I suspect its glibc is still newer than
> > that on rhel.
> >
> > On 3 Jun, 2017 7:29 pm, "Ric Sherlock" <tikk...@gmail.com> wrote:
> >
> > > Hi Bill,
> > > Thanks based on that suggestion I checked out master which successfully
> > > built. Tests running now.
> > >
> > > So am I right in thinking that my next move is to build the system on
> the
> > > Red Hat server?
> > >
> > > On Sat, Jun 3, 2017 at 11:19 PM, bill lam <bbill@gmail.com> wrote:
> > >
> > > > copy the file build_jconsole.sh from j806 head, there the
> > > > dependency on ncursesw has been killed off.
> > > >
> > > > Сб, 03 июн 2017, Ric Tikkanz написал(а):
> > > > > Hi guys,
> > > > > I'm trying to build J from source - the main incentive being to try
> > and
> > > > get
> > > > > it running on a research compute cluster. (see post in beta forum)
> > > > >
> > > > > I thought I'd start simple by cloning the source from github and
> > > building
> > > > > the j64-805 release branch on my local Ubuntu 16.04 machine, but
> came
> > > > > across a problem.
> > > > >
> > > > > ~$ $jmake/build_jconsole.sh j64
> > > > > jconsole
> > > > > -fPIC -O1 -Wextra -DREADLINE
> > > > > /home/rishe0/gitdev/jsource/unix/libedit64.a -ldl -lncursesw -o
> > > jconsole
> > > > > cc  -fPIC -O1 -Wextra  -DREADLINE   -c -o jconsole.o
> > > > > /home/rishe0/gitdev/jsource/jsrc/jconsole.c
> > > > > cc  -fPIC -O1 -Wextra  -DREADLINE   -c -o jeload.o
> > > > > /home/rishe0/gitdev/jsource/jsrc/jeload.c
> > > > > /home/rishe0/gitdev/jsource/jsrc/jeload.c: In function ‘jepath’:
> > > > > /home/rishe0/gitdev/jsource/jsrc/jeload.c:139:3: warning: ignoring
> > > > return
> > > > > value of ‘getcwd’, declared with attribute warn_unused_result
> > > > > [-Wunused-result]
> > > > >getcwd(path,sizeof(path));
> > > > >^
> > > > > cc  jconsole.o jeload.o   /home/rishe0/gitdev/jsource/
> > unix/libedit64.a
> > > > -ldl
> > > > > -lncursesw -o jconsole
> > > > > /usr/bin/ld: cannot find -lncursesw
> > > > > collect2: error: ld returned 1 exit status
> > > > > /home/rishe0/gitdev/jsource/make/makefile:5: recipe for target
> > > > 'jconsole'
> > > > > failed
> > > > > make: *** [jconsole] Error 1
> > > > > cp: cannot stat 'jconsole': No such file or directory
> > > > >
> > > > > From the above it appears that ncursesw is not found. This seems to
> > be
> > > > > confirmed by:
> > > > > ~$ ld -lncursesw --verbose
> > > > > ...
> > > > > ==
> > > > > attempt to open //usr/local/lib/x86_64-linux-gnu/libncursesw.so
> > failed
> > > > > attempt to open //usr/local/lib/x86_64-linux-gnu/libncursesw.a
> > failed
> > > > > attempt to open //lib/x86_64-linux-gnu/libncursesw.so failed
> > > > > attempt to open //lib/x86_64-linux-gnu/libncursesw.a failed
> > > > > attempt to open //usr/lib/x86_64-linux-gnu/libncursesw.so failed
> > > > > attempt to open //usr/lib/x86

Re: [Jsource] Help compiling jsource?

[bill lam]

Since you built on ubuntu 16.04, I suspect its glibc is still newer than
that on rhel.

On 3 Jun, 2017 7:29 pm, "Ric Sherlock" <tikk...@gmail.com> wrote:

> Hi Bill,
> Thanks based on that suggestion I checked out master which successfully
> built. Tests running now.
>
> So am I right in thinking that my next move is to build the system on the
> Red Hat server?
>
> On Sat, Jun 3, 2017 at 11:19 PM, bill lam <bbill@gmail.com> wrote:
>
> > copy the file build_jconsole.sh from j806 head, there the
> > dependency on ncursesw has been killed off.
> >
> > Сб, 03 июн 2017, Ric Tikkanz написал(а):
> > > Hi guys,
> > > I'm trying to build J from source - the main incentive being to try and
> > get
> > > it running on a research compute cluster. (see post in beta forum)
> > >
> > > I thought I'd start simple by cloning the source from github and
> building
> > > the j64-805 release branch on my local Ubuntu 16.04 machine, but came
> > > across a problem.
> > >
> > > ~$ $jmake/build_jconsole.sh j64
> > > jconsole
> > > -fPIC -O1 -Wextra -DREADLINE
> > > /home/rishe0/gitdev/jsource/unix/libedit64.a -ldl -lncursesw -o
> jconsole
> > > cc  -fPIC -O1 -Wextra  -DREADLINE   -c -o jconsole.o
> > > /home/rishe0/gitdev/jsource/jsrc/jconsole.c
> > > cc  -fPIC -O1 -Wextra  -DREADLINE   -c -o jeload.o
> > > /home/rishe0/gitdev/jsource/jsrc/jeload.c
> > > /home/rishe0/gitdev/jsource/jsrc/jeload.c: In function ‘jepath’:
> > > /home/rishe0/gitdev/jsource/jsrc/jeload.c:139:3: warning: ignoring
> > return
> > > value of ‘getcwd’, declared with attribute warn_unused_result
> > > [-Wunused-result]
> > >getcwd(path,sizeof(path));
> > >^
> > > cc  jconsole.o jeload.o   /home/rishe0/gitdev/jsource/unix/libedit64.a
> > -ldl
> > > -lncursesw -o jconsole
> > > /usr/bin/ld: cannot find -lncursesw
> > > collect2: error: ld returned 1 exit status
> > > /home/rishe0/gitdev/jsource/make/makefile:5: recipe for target
> > 'jconsole'
> > > failed
> > > make: *** [jconsole] Error 1
> > > cp: cannot stat 'jconsole': No such file or directory
> > >
> > > From the above it appears that ncursesw is not found. This seems to be
> > > confirmed by:
> > > ~$ ld -lncursesw --verbose
> > > ...
> > > ==
> > > attempt to open //usr/local/lib/x86_64-linux-gnu/libncursesw.so failed
> > > attempt to open //usr/local/lib/x86_64-linux-gnu/libncursesw.a failed
> > > attempt to open //lib/x86_64-linux-gnu/libncursesw.so failed
> > > attempt to open //lib/x86_64-linux-gnu/libncursesw.a failed
> > > attempt to open //usr/lib/x86_64-linux-gnu/libncursesw.so failed
> > > attempt to open //usr/lib/x86_64-linux-gnu/libncursesw.a failed
> > > attempt to open //usr/local/lib64/libncursesw.so failed
> > > attempt to open //usr/local/lib64/libncursesw.a failed
> > > attempt to open //lib64/libncursesw.so failed
> > > attempt to open //lib64/libncursesw.a failed
> > > attempt to open //usr/lib64/libncursesw.so failed
> > > attempt to open //usr/lib64/libncursesw.a failed
> > > attempt to open //usr/local/lib/libncursesw.so failed
> > > attempt to open //usr/local/lib/libncursesw.a failed
> > > attempt to open //lib/libncursesw.so failed
> > > attempt to open //lib/libncursesw.a failed
> > > attempt to open //usr/lib/libncursesw.so failed
> > > attempt to open //usr/lib/libncursesw.a failed
> > > attempt to open //usr/x86_64-linux-gnu/lib64/libncursesw.so failed
> > > attempt to open //usr/x86_64-linux-gnu/lib64/libncursesw.a failed
> > > attempt to open //usr/x86_64-linux-gnu/lib/libncursesw.so failed
> > > attempt to open //usr/x86_64-linux-gnu/lib/libncursesw.a failed
> > >
> > > ~$ ls /lib/x86_64-linux-gnu/libncursesw*
> > > /lib/x86_64-linux-gnu/libncursesw.so.5
> > > /lib/x86_64-linux-gnu/libncursesw.so.5.9
> > >
> > > It seems that there is no link to libncursesw.so on my system. I then
> > tried
> > > creating a symlink from libncursesw.so to libncursesw.so.5.9 in
> > > /lib/x86_64-linux-gnu/ but this didn't fully resolve things as shown
> > below.
> > > I'm not sure what the output below is telling me and what my next move
> > is.
> > > Any suggestions?
> > >
> > > ~$ $jmake/build_jconsole.sh j64
> > > jconsole
> > > -fPIC -O1 -Wextra -DREADLINE
> &

Re: [Jsource] va.h constants

[bill lam]

I think nouns type should not be touched at all but other types such as
verb adverb can be grouped as a miscellaneous type with a new subtype since
it is quite rare that those types will be used in user codes.

type promotion is another issue since current J implementation assumes max
type.

On Jul 30, 2016 3:06 AM, "Henry Rich"  wrote:

> It wouldn't be necessary to change VRESX to 29; we would put in bit-by-bit
> tests as needed.  I wanted to eliminate as much bit-testing as possible for
> the usual cases.
>
> I don't think reordering the type bits is possible, since user code
> depends on the assignment.
>
> Henry Rich
>
> On 7/29/2016 3:00 PM, Thomas Costigliola wrote:
>
>> Are the changes to the bit patterns at the top of va.h supposed to
>> eliminate an extra lookup later?
>>
>> #define VBB B01 /* convert arguments to B
>>   */
>> #define VII INT /* convert arguments to I
>>   */
>> #define VDD FL  /* convert arguments to D
>>   */
>> #define VZZ CMPX/* convert arguments to Z
>>   */
>> #define Vxx XNUM/* convert arguments to XNUM
>>  */
>> #define VQQ RAT /* convert arguments to RAT
>>   */
>> #define VARGMSK (VBB|VII|VDD|VZZ|Vxx|VQQ)  // mask for argument
>> requested type
>> #define VRESX   8   // bit position for result flags
>>
>> But what happens if the extended floating point type (XD) gets
>> implemented? That would push VRESX to 29 and leave no room for VXCVTTYPEX
>> on 32 bit machines. I do have custom types beyond bit 29 and I would like
>> to conform to the official source, what is the recommendation? Reorder the
>> type bit patterns?
>>
>> --
>> 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

Re: [Jsource] Unicode <-> utf-8 encoding in J805 beta 10

[bill lam]

I think this might already happened in the last beta. a null is added
following cjk so that it becomes 2 unicode character and therefore occupies
2 display width to make proper box alignment.

Nulls can be removed but it will cause another bug that real original nulls
will also be removed.

On Aug 2, 2016 6:16 AM, "robert therriault"  wrote:

>  I noticed some strange behaviour when unicode is converted to utf-8. It
> seems an extra zero is being added in j805 beta 10. Any reason for this?
>
> Cheers, bob
>
> JVERSION
> Engine: j804/j64/darwin
> Release: commercial/2015-12-21 18:06:25
> Library: 8.04.15
> Qt IDE: 1.4.10/5.4.2
> Platform: Darwin 64
> Installer: J804 install
> InstallPath: /applications/j64-804
> Contact: www.jsoftware.com
>u: 3
> 田
>3 u: '田'
> 231 148 176
>3 u: 7 u: ": u: 3
> 3
>3 u: ": u: 3
> 231 148 176
>
> JVERSION
> Engine: j805/j64/darwin
> Beta-10: commercial/2016-08-01T13:22:59
> Library: 8.05.02
> Qt IDE: 1.4.10/5.4.2
> Platform: Darwin 64
> Installer: J805 install
> InstallPath: /applications/j64-805
> Contact: www.jsoftware.com
>u: 3
> 田
>3 u: '田'
> 231 148 176
>3 u: 7 u: ": u: 3
> 3 0
>3 u: ": u: 3
> 231 148 176 0
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] Problems dealing with UTF-8

[bill lam]

What you had asked is not just for append but promotion in
general. For promotion I think it should meet some requirements,

1 preserve semantic
2 same shape
3 round trip conversion

for promotion from integer to double,
1 still a number, the same number
2 same shape
3 demote to the same number

promotion from literal to wide using u: can satisfy these
requirements, whereas using 7: would break them.

Users should have the best knowledge about the domain/meaning/encoding
of literals being used and therefore should be reponsible to do 
conversion by themselves.

Пн, 11 июл 2016, Don Guinn написал(а):
> Thank you, Raul, ​I appreciate your questions on my reasoning. That said, I
> am quite pleased with J when working with Unicode.​ The tools provided make
> it easy.
> 
> 
> > Can you give me an example where this would give a different result from:
> >
> > append=: dyad define
> >   if. 131074 = x +&(3!:0) y do. x ,&(7:) y else. x, y end.
> > )
> >
> > For that matter, is there some reason you would not want to use
> > ,&(7:) if you are mixing utf-16 and utf-8 characters?
> >
> 
> Sorry for the delay in responding. This is how I was asking for the default
> to work. ​That is what I do when there is a possibility for UTF-8 to be in
> data. 7: is a pretty powerful verb.​
> 
> 
> >
> > > However, I feel that the current standard of converting
> > > with u: monadic should not be allowed at all. It should be an error
> > period.
> >
> > Why is that?
> >
> > Is this because that is the only use you have? Is this because you
> > believe this would break no existing code? Or is this because you
> > believe that no one should ever use a 16 bit literal for non-unicode
> > data in J? (For example, when dealing with binary files representing
> > music, or for representing pixels?)
> >
> 
> ​I feel that the default action for combining char with wide is that <7f
> data is not UTF-8 is no longer a good choice. Most of the time it is UTF-8.
> And I suspect that Unicode in the form of UTF-8 will grow. For that reason
> I felt that it should be the default action. However, if one should make a
> conscious decision​ as to how char maps to wide then there should be no
> default. Although browser data is really strange in how it supports
> Unicode. Fortunately most of that disappears before we see it in J
> 
> 
> 
> >
> > > In the current world one never really can predict when some data may
> > appear
> > > with UTF-8 characters unexpectedly. This would force manual conversion
> > > insuring that the proper conversion from char to wide as required by the
> > > application is done. Otherwise testing with only ASCII char would not
> > catch
> > > the possible error.
> >
> > I feel that you have not encountered enough problems with "almost
> > utf-8 data", or "utf-8 data mixed in with other binary data in a file)
> > if you are saying stuff like this.
> >
> 
> ​True. Char and wide
> can be used for all sorts of things. Right now, wide being relatively new I
> thought that it would not be used for other things. But 16 bit audio files
> do fit nicely in wide to save space.
> ​
>  ​
> 
> >
> > For that matter, if by "manual conversion" you mean using 7: then I
> > do not see that why this should be a problem.
> >
> > > It seems to me that automatic conversion from char to wide assume UTF-8
> > is
> > > a proper choice now. It is possible that one could run into a need to
> > leave
> > > the conversion as it is now, but where would that data come from?
> >
> > A file, most likely. Or a network stream.
> >
> > > And it would really be a pain do view given that J is so insistent to
> > treat char
> > > as UTF-8 when displaying.
> >
> > Usually you convert such data to numbers (possibly hexadecimal) when
> > you want to inspect it. But you expect J to function in a transparent
> > and predictable fashion, to get there.
> >
> > > J automatically converts integer (64 bit) into float when it can cause a
> > > loss of accuracy and we accept that. How is this different?
> >
> > This conversion changes the shape of the data.
> >
> > ​Yes it does. One of the major problems with dealing with UTF-8. Alignment
> problems, working with char with UTF-8 where the number of bytes do not
> agree with the number of characters is difficult. Converting to wide avoids
> these problems. When through simply convert back.
> ​
> 
> 
> > Thanks,
> >
> > --
> > Raul
> > --
> > For information about J forums see http://www.jsoftware.com/forums.htm
> >
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
--
For information about J 

Re: [Jsource] Problems dealing with UTF-8

[bill lam]

I consider myself a frequent user of wide/utf8 unicode user and yet I
prefer doing the proper conversion by myself instead of automatic
conversion by J.

There are confusions when using utf8 but the best way I suggested is to
gain more experience, but not by relying on J to do automatic conversion of
literal to wide.

J will convert literal to wide for external interface such as 1!:x family
and 15!:0 under windows.

Recent beta for unicode display had made a similar assumption as yours to
convert all one byte literal to wide in regardless whether they are utf8 or
not.  This leads to a change in behavior that Bob has demonstrated that
illegal symbol becoming another character. I would like to have this fixed
if possible.
On Jul 11, 2016 6:14 AM, "Don Guinn"  wrote:

> Thanks for your response Bill. I certainly have no problem any more
> controlling the way literal converts to unicode; however, I would like you
> to consider the following.
>
> literal is a problem as it has many inconsistent uses. The ASCII part is
> not a problem as it is the same whether literal (char) is interpreted as
> extended ASCII or UTF-8. Char is also used as numeric in many places, like
> image files.
>
> I was not thinking that the errors were in J, but in my failure to assure
> that UTF-8 codes have been converted to unicode (wide) before catenating or
> whatever with wide. When support was added to J for Unicode the proper
> decision to maintain compatibility with extended ASCII was correct. But
> things have changed. Now I doubt that anyone uses extended ASCII. Any
> programs using extended ASCII are probably obsolete or converted to use
> UTF-8.
>
> Like dropping the dot after x and y, it makes more sense now to assume that
> char may contain UTF-8 when treated as text.
>
> I am not suggesting any change in the way char is handled except when
> combining with wide. So programs not using wide would not be affected. Wide
> is different from char as it is only Unicode. It has no other use. So any
> time wide and char are mixed the char bytes are must be Unicode points. So
> I looked at what U+80 through U+FF are. Some control codes of which I don't
> understand and Latin-1 Supplement. There are many useful symbols in
> this range. But how would they be entered?
>
> The only way to enter them as extended ASCII is by indexing into a. . Say I
> want to assign some name a value with the  symbol.
>
>(163{a.),":1234
> �1234
>(2 u: 163{a.),":1234
> £1234
>(4 u: 163),":1234
> £1234
>]Value=:'£',":1234
> £1234
>a.i.Value
> 194 163 49 50 51 52
>3 u: 7 u: Value
> 163 49 50 51 52
>
> OK. I cheated. I can't directly enter  on my keyboard, but the
> British can on theirs. But notice that J did not treat the 163{a. as
>  It entered the UTF-8 representation. And the same thing would
> happen for any of the Latin-1 Supplement characters. They would be in UTF-8
> multi-byte.
>
> Anything retrieved from the web assumes that characters coming in can
> include UTF-8 or be wide. J assumes that char is UTF-8 for both entry and
> display. It actually treats extended ASCII as invalid UTF-8.
>
> Things get messy in J when trying to manipulate UTF-8 in J, particularly in
> arrays. People seem to avoid using wide because of the care that must be
> taken when using it then end out struggling trying to make UTF-8 cooperate.
> All the more reason to make wide easy to use.
>
> Question: Does anybody have a need for or have any program that has a need
> for char bytes >127 to be expanded to wide by adding a zero byte?
>
> On Sat, Jul 9, 2016 at 6:15 PM, Don Guinn  wrote:
>
> > Thanks. I'll look them up.
> >
> > I think most of the too wide characters take 3 UTF-8 bytes so aren't
> > supported any way.
> > On Jul 9, 2016 5:21 PM, "robert therriault" 
> wrote:
> >
> > Thanks Don, both for this encapsulation and the writing that you done in
> > the past on unicode in J. I am learning a lot.
> >
> > Two things which are worth mentioning.
> >
> > utf8
> > 8:
> >ucp
> > 7:
> >uucp
> > u:@(7:)
> >
> > are already defined in the standard library and may lead to some
> confusion
> > with your definitions
> > UCP
> > 3:
> >UD NB. I like your use of rank as that was an issue in my early
> > explorations of unicode
> > 8:"1
> >UC
> > 7:
> >
> > and second,the issue remains with uneven boxing with some of the unicode
> > characters (which I think is one of the prime motivators in this
> adventure.)
> >
> > ]s=: ucp 'ΔaΔ'
> > ΔaΔ
> > > ┌───┐
> > │ΔaΔ│
> > └───┘
> >]t=: ucp 'Δaఝ' NB. last character wider
> > Δaఝ
> > > ┌───┐
> > │Δaఝ│
> > └───┘
> >uwid=: ({.@:glqextent_jgl2_ @: u: @:  ":) "0 NB.glqextent_jgl2_
> > available in jqt ide
> >uwid s
> > 9 7 9
> >uwid t
> > 9 7 16
> > JVERSION
> > Engine: j805/j64/darwin
> > Beta-9: commercial/2016-07-05T17:11:06
> > Library: 8.04.15
> > Qt IDE: 1.4.9/5.4.2
> > Platform: Darwin 64
> > 

Re: [Jsource] j805-beta-9 release candidates

[bill lam]

This is unrelated to cjk. but the behavior change in beta that
it assumes one byte literals are always utf8 encoded which I think
is wrong.

Чт, 07 июл 2016, robert therriault написал(а):
> Howdy Bill :-)
> 
> I agree that there will be cases that will not be handled by the approach 
> that I am recommending. When the display width is larger than 3 (my proposal 
> would have a max width of 3 because I believe that was what you had said was 
> the maximum UTF-8 code point for J in an earlier post) or the display height 
> is larger than 1 we will be back in the same situation that we were before 
> with boxing being erratic, but this will happen far less than it does 
> currently. If we vary the width of the characters for any other reason, such 
> as treating CJK characters differently from other UTF-8 characters with code 
> point of 3, we run the risk of really complicating the rules of how the 
> display is created. Since the mail clients will probably mangle the results, 
> try the following examples with 805 beta-9.
> 
> 3 5 $ ": (u: 30005 30006 30007 30008 30009)
> 
>   < 3 5 $ ": (u: 30005 30006 30007 30008 30009)
> 
>3 5 $ ": (u: 30005 30006 3101 30008 30009)
> 
>< 3 5 $ ": (u: 30005 30006 3101 30008 30009)
> 
> Cheers, bob
> 
> > On Jul 7, 2016, at 3:54 PM, bill lam <bbill@gmail.com> wrote:
> > 
> > As you and Eric had said, unicode is a bit of the wild west.  The length of
> > utf8 is 1 to 4, but the display width can be larger than 4, also display
> > height larger than 1.  I think there are always some cases which cannot be
> > handled by a simplistic approach.
> > On Jul 7, 2016 11:31 PM, "robert therriault" <bobtherria...@mac.com> wrote:
> > 
> >> Thinking about this a little more I wonder if spacing should be done on
> >> the basis of UTF-8 encoding because this is really the source of the issue
> >> with boxes not lining up with contents.
> >> 
> >>'电甶男甸甹'
> >> 电甶男甸甹
> >>   $  '电甶男甸甹' NB. 5 characters represented by 15 integers
> >> 15
> >>   < '电甶男甸甹'
> >> ┌───┐
> >> │电甶男甸甹│
> >> └───┘
> >>   ": < '电甶男甸甹'
> >> ┌───┐
> >> │电甶男甸甹│   NB. This line is narrower because the characters do not
> >> require the space allotted by the width of the UTF-8 encoding array
> >> └───┘
> >>   $ ": < '电甶男甸甹'
> >> 3 17
> >> 
> >>   JVERSION
> >> Engine: j804/j64/darwin
> >> Release: commercial/2015-12-21 18:06:25
> >> Library: 8.04.15
> >> Qt IDE: 1.4.10/5.4.2
> >> Platform: Darwin 64
> >> Installer: J804 install
> >> InstallPath: /applications/j64-804
> >> Contact: www.jsoftware.com
> >> 
> >> The width of the box is being determined by the number of integers in the
> >> UTF-8 encoding, but the actual width of the characters results in the
> >> narrowing of the box on the lines where characters are actually displayed.
> >> If UTF-8 spacing were used then there would be enough room for wider
> >> characters and the boxes would line up not only for unicode characters, but
> >> also for literals expressed in UTF-8. Having the CJK characters only taking
> >> up two spaces instead of the expected three reduces the meaningfulness of
> >> the display of UTF-8 literals. Using UTF-8 spacing would mean that there
> >> would be extra space within the box, but the boxes would still line up with
> >> each other based on the fact that they are all using the spacing created by
> >> UTF-8.
> >> 
> >> 
> >> My 2 bits.
> >> 
> >> Cheers, bob
> >> 
> >>> On Jul 7, 2016, at 7:57 AM, robert therriault <bobtherria...@mac.com>
> >> wrote:
> >>> 
> >>> Yes, unicode is a bit of the wild west, isn't it?
> >>> 
> >>> The thing I am a bit concerned about is whether having some wide
> >> characters line up and others that don't creates even more wildness. In
> >> terms of the things that I have been doing with svg and html, this spacing
> >> does throw my viewer out of whack compared to 804, but I think that I can
> >> compensate as long as I know which characters will be affected and which
> >> ones won't.I am guessing that the CJK characters are being identified
> >> through their range of encoding values?
> >>> 
> >>> Cheers, bob
> >>> 
> >>>

Re: [Jsource] j805-beta-9 release candidates

[bill lam]

As you and Eric had said, unicode is a bit of the wild west.  The length of
utf8 is 1 to 4, but the display width can be larger than 4, also display
height larger than 1.  I think there are always some cases which cannot be
handled by a simplistic approach.
On Jul 7, 2016 11:31 PM, "robert therriault"  wrote:

> Thinking about this a little more I wonder if spacing should be done on
> the basis of UTF-8 encoding because this is really the source of the issue
> with boxes not lining up with contents.
>
> '电甶男甸甹'
> 电甶男甸甹
>$  '电甶男甸甹' NB. 5 characters represented by 15 integers
> 15
>< '电甶男甸甹'
> ┌───┐
> │电甶男甸甹│
> └───┘
>": < '电甶男甸甹'
> ┌───┐
> │电甶男甸甹│   NB. This line is narrower because the characters do not
> require the space allotted by the width of the UTF-8 encoding array
> └───┘
>$ ": < '电甶男甸甹'
> 3 17
>
>JVERSION
> Engine: j804/j64/darwin
> Release: commercial/2015-12-21 18:06:25
> Library: 8.04.15
> Qt IDE: 1.4.10/5.4.2
> Platform: Darwin 64
> Installer: J804 install
> InstallPath: /applications/j64-804
> Contact: www.jsoftware.com
>
> The width of the box is being determined by the number of integers in the
> UTF-8 encoding, but the actual width of the characters results in the
> narrowing of the box on the lines where characters are actually displayed.
> If UTF-8 spacing were used then there would be enough room for wider
> characters and the boxes would line up not only for unicode characters, but
> also for literals expressed in UTF-8. Having the CJK characters only taking
> up two spaces instead of the expected three reduces the meaningfulness of
> the display of UTF-8 literals. Using UTF-8 spacing would mean that there
> would be extra space within the box, but the boxes would still line up with
> each other based on the fact that they are all using the spacing created by
> UTF-8.
>
>
> My 2 bits.
>
> Cheers, bob
>
> > On Jul 7, 2016, at 7:57 AM, robert therriault 
> wrote:
> >
> > Yes, unicode is a bit of the wild west, isn't it?
> >
> > The thing I am a bit concerned about is whether having some wide
> characters line up and others that don't creates even more wildness. In
> terms of the things that I have been doing with svg and html, this spacing
> does throw my viewer out of whack compared to 804, but I think that I can
> compensate as long as I know which characters will be affected and which
> ones won't.I am guessing that the CJK characters are being identified
> through their range of encoding values?
> >
> > Cheers, bob
> >
> >
> >> On Jul 7, 2016, at 7:11 AM, Eric Iverson 
> wrote:
> >>
> >> Unicode is a wonderful beast, but it is a wild one.
> >
> > --
> > 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

Re: [Jsource] j805-beta-9 release candidates

[bill lam]

Did you mean <"1 [ 8 32 

the current beta can only handle display width of 1 and 2.  zero
or negative display width cannot be handled. 

capability of character composition also depends on font engine being used.

Вт, 05 июл 2016, JSource написал(а):
> unicode looks better, but every one of these pages has misalignments
> 
> 
> ,. <"1 8 32 $ 4 u: 0 + i.256   NB. quarterwidth row 5
> 
> ,. <"1 8 32 $ 4 u: 256 + i.256
> ,. <"1 8 32 $ 4 u: 512 + i.256
> ,. <"1 8 32 $ 4 u: 768 + i.256  NB. first pages are digraph 0 (back) space 
> chars.
> 
> ,. <"1 8 32 $ 4 u: 1024 + i.256
> 
> 
> < (4 u: ,@:(3: ,. 758 + ?@(95"0))) 'Digraph char cheating'
> ┌──┐
> │D˿i̅g̢r˶a̭p̠h̡ ̗c̳h˻a̢r͒ ̒c̋h̭e̐a͒ṫi̵n̍g͒│
> └──┘
> 
> 
> alternate "real" diacritics, don't quite line up either
> 
> 
> dict =: ,&.>/"1 ((0 (0 ". '16b' , tolower@(4 5 6 7 &{)@{::) each ]) ,. (1 (0 
> ". '16b' , tolower@(4 5 6 7 &{)@{::) every each ('';'')&(] <;._1~  
> E.)  each)) (<'')&(] <;._1~  +./@:E.every) dltb 
> each cutLF a  NB. a is html source for 
> http://pinyin.info/unicode/diacritics.html
> 
> twist =:  4 u: ({. every dict)  (]  ({~  ?@#)@:(dict {::~ ])`[@.((# dict) = 
> ]) i.)("_ 0) 3 u: ]
> 
> ,. cut twist someasciitext
> 
> - Original Message -
> From: Eric Iverson 
> To: Source forum 
> Sent: Tuesday, July 5, 2016 5:22 PM
> Subject: [Jsource] j805-beta-9 release candidates
> 
> New tested builds for windows/linux/mac 32/64
> 
> This beta release has some significant performance improvements courtesy
> Henry Rich.
> 
> See http://www.jsoftware.com/download/jengine for more details,
> 
> If interested please install and play with these builds. Problems are much
> better found now than later.
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] j805-beta-9 release candidates

[bill lam]

I don't know the detail of how it work, but I have been told that the new
beta first convert literal to wchar unicode (131072) to make alignment.  I
suspect it attempts to convert illegal utf8 sequence to valid codepoint.  I
think this behavior is incorrect.

the new beta should work reasonably well for valid utf8/unicode.  Correct
display of brahmic scripts is very difficult in J and I think J needs not
attempt to do it either.
On Jul 6, 2016 8:19 AM, "robert therriault"  wrote:

> Eric, I thought you said it would be up in a couple of days/weeks! Nice
> work (and Beta 9 works fine on Darwin).
>
> For Henry, it's different, although I am not sure it is an improvement for
> boxing. I wish I had some useful suggestions, but with fixed width and the
> inability to move characters within space, I am not sure how you resolve
> this. Maybe box size could be based on the shape of the UTF-8 encoding,
> although that ends up padding out to the right with the higher value for
> the row index. Tricky.
>
> Cheers, bob
>
>JVERSION
> Engine: j804/j64/darwin
> Release: commercial/2015-12-21 18:06:25
> Library: 8.04.15
> Qt IDE: 1.4.10/5.4.2
> Platform: Darwin 64
> Installer: J804 install
> InstallPath: /applications/j64-804
> Contact: www.jsoftware.com
>
>< 3 4 $ 'a', (u: 30101), 'b'
> ┌┐
> │a疕ba  │
> │疕ba疕│
> │ba疕b  │
> └┘
>< 3 4 $ 'a','疕', 'b'
> ┌┐
> │a疕│
> │ba��│
> │�ba�│
> └┘
>
>JVERSION
> Engine: j805/j64/darwin
> Beta-9: commercial/2016-07-05T17:11:06
> Library: 8.04.15
> Qt IDE: 1.4.9/5.4.2
> Platform: Darwin 64
> Installer: J804 install
> InstallPath: /users/bobtherriault/j64-804
> Contact: www.jsoftware.com
>  < 3 4 $ 'a', (u: 30101), 'b'
> ┌──┐
> │a疕ba │
> │疕ba疕│
> │ba疕b │
> └──┘
> < 3 4 $ 'a', '疕', 'b'
> ┌┐
> │a疕 │
> │baç–│
> │•baç│
> └┘
>  $ ": 3 4 $ 'a', (u: 30101), 'b' NB. create UTF-8 encoding shape
> 3 8
> < 3 8 $ 'x'  NB. this box would accommodate the size of the unicode,
> but the box would need to be generated independently of the contents.
> ┌┐
> ││
> ││
> ││
> └┘
>
> > On Jul 5, 2016, at 3:29 PM, 'Pascal Jasmin' via Source <
> sou...@jsoftware.com> wrote:
> >
> > unicode looks better, but every one of these pages has misalignments
> >
> >
> > ,. <"1 8 32 $ 4 u: 0 + i.256   NB. quarterwidth row 5
> >
> > ,. <"1 8 32 $ 4 u: 256 + i.256
> > ,. <"1 8 32 $ 4 u: 512 + i.256
> > ,. <"1 8 32 $ 4 u: 768 + i.256  NB. first pages are digraph 0 (back)
> space chars.
> >
> > ,. <"1 8 32 $ 4 u: 1024 + i.256
> >
> >
> > < (4 u: ,@:(3: ,. 758 + ?@(95"0))) 'Digraph char cheating'
> > ┌──┐
> > │D˿i̅g̢r˶a̭p̠h̡ ̗c̳h˻a̢r͒ ̒c̋h̭e̐a͒ṫi̵n̍g͒│
> > └──┘
> >
> >
> > alternate "real" diacritics, don't quite line up either
> >
> >
> > dict =: ,&.>/"1 ((0 (0 ". '16b' , tolower@(4 5 6 7 &{)@{::) each ]) ,.
> (1 (0 ". '16b' , tolower@(4 5 6 7 &{)@{::) every each ('';'')&(]
> <;._1~  E.)  each)) (<'')&(] <;._1~
> +./@:E.every) dltb each cutLF a  NB. a is html source for
> http://pinyin.info/unicode/diacritics.html
> >
> > twist =:  4 u: ({. every dict)  (]  ({~  ?@#)@:(dict {::~ ])`[@.((#
> dict) = ]) i.)("_ 0) 3 u: ]
> >
> > ,. cut twist someasciitext
> >
> > - Original Message -
> > From: Eric Iverson 
> > To: Source forum 
> > Sent: Tuesday, July 5, 2016 5:22 PM
> > Subject: [Jsource] j805-beta-9 release candidates
> >
> > New tested builds for windows/linux/mac 32/64
> >
> > This beta release has some significant performance improvements courtesy
> > Henry Rich.
> >
> > See http://www.jsoftware.com/download/jengine for more details,
> >
> > If interested please install and play with these builds. Problems are
> much
> > better found now than later.
> > --
> > 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

Re: [Jsource] Non displayable characters display changed in penultimate beta

[bill lam]

Bob, I tried your utf verb
   a.&.> utf a.{~126+i.6
+---+---+---+---+---+---++
|126|127|128|129|130|131||
+---+---+---+---+---+---++

It seems to be to have an extra empty box, is it intended?

Вт, 05 июл 2016, robert therriault написал(а):
> Yep, I hear you Henry,
> 
> I wanted to be sure you were aware of the differences. The concern that I 
> have is that when the UTF-8 is broken up that the display be something that 
> is a bit more understandable for the user.  I was playing around with it 
> recently in trying to develop a web based solution, which is a lot easier 
> because there is no constraint of a fixed font size. Here is a video of what 
> I ended up with https://youtu.be/eN9H-rMk1No and the key verb in the process 
> was this one that breaks a list of point numbers into appropriate chunks to 
> generate characters.
> 
>utf_vts_
> 3 : 0"1
> if. y-:'' do. return. end.
> try.  ((utf@:((1<.#)}.]));~((3 u: ":)@: (7 u: a.{~ (1<.#) {. ]))) y
>   catch. try. ((utf@:((2<.#)}.]));~((3 u: ":)@: (7 u: a.{~ (2<.#) {. ]))) y
> catch. try. ((utf@:((3<.#)}.]));~((3 u: ":)@: (7 u: a.{~ (3<.#) {. ]))) y
>   catch. ({. ; utf@}.) y
>   end.
> end.
>   end.
> )
> 
> Thanks for all of your work on this, handling the variable widths and uneven 
> box boundaries within your constraints seems quite a challenge. By the way, 
> the most recent version of the beta that I could download was 7 on the Darwin 
> platform, so I have not had a chance to try out the solution to the CJK 
> character widths.
> 
> Cheers, bob
> 
> > On Jul 5, 2016, at 2:52 AM, Henry Rich  wrote:
> > 
> > This 3 4 $ 'a', 'ఝ', 'b'
> > is a strange beast: The string requires 5 bytes, so you have chopped 3 
> > copies of it into 3 4-byte sections.  ": formats each line separately; the 
> > second and third lines contain partial UTF-8 sequences which are displayed 
> > as unknown.  I think it's right; at least it's reasonable (formatting of 
> > invalid UTF-8 is undefined).
> > 
> > Playing with UTF-8 is hard; easier to convert to unicodes first, using u: .
> > 
> > Henry Rich
> > 
> > 
> > 
> > 
> > On 7/5/2016 12:21 AM, robert therriault wrote:
> >>   JVERSION
> >> Engine: j804/j64/darwin
> >> Release: commercial/2015-12-21 18:06:25
> >> Library: 8.04.15
> >> Qt IDE: 1.4.10/5.4.2
> >> Platform: Darwin 64
> >> Installer: J804 install
> >> InstallPath: /applications/j64-804
> >> Contact: www.jsoftware.com
> >> 
> >>  3 4 $  'a', 'ఝ', 'b'
> >> aఝ
> >> ba��
> >> �ba�
> >> 
> >>JVERSION
> >> Engine: j805/j64/darwin
> >> Beta-7: commercial/2016-06-22T14:29:03
> >> Library: 8.04.15
> >> Qt IDE: 1.4.9/5.4.2
> >> Platform: Darwin 64
> >> Installer: J804 install
> >> InstallPath: /users/bobtherriault/j64-804
> >> Contact: www.jsoftware.com
> >> 
> >>3 4 $  'a', 'ఝ', 'b'
> >> aఝ
> >> baà°
> >> baà
> >> 
> >> I can't seem to download the newest beta, but this behaviour in the 
> >> previous one does not seem correct and may be the same in the newest 
> >> version (I don't expect that the CJK changes would affect this behaviour). 
> >> Introducing new characters instead of the � to show non-displayable 
> >> characters would be confusing to the user, and the third line containing 3 
> >> characters instead of the expected 4 seems incorrect.
> >> 
> >> 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

-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] jqt crash

[bill lam]

jqt crashed again with libj.so built from the head of UnicodeCJK
branch when typing  
(32#1)&(128!:3)

libj.so built from the current master head does not have this
problem.

Чт, 23 июн 2016, bill lam написал(а):
> now run fine.
> 
> Ср, 22 июн 2016, Eric Iverson написал(а):
> > Please try again with the new release candidates now available at
> > download/jengine.
> > 
> > On Mon, Jun 20, 2016 at 8:27 PM, bill lam <bbill@gmail.com> wrote:
> > 
> > > It only happened in the version Beta: commercial/2016-05-10T12:23:26
> > > downloaded from jsoftware.  It seemed had gone away when I built from the
> > > current git source.
> > > On Jun 21, 2016 2:39 AM, "Henry Rich" <henryhr...@gmail.com> wrote:
> > >
> > > > I have been away.  Is this something I need to look at?  I tried the
> > > > sentence
> > > >
> > > > (32#1)&(128!:3)
> > > >
> > > > on my local version  & it was OK.
> > > >
> > > > Henry
> > > >
> > > > On 6/12/2016 4:32 AM, bill lam wrote:
> > > >
> > > >> A simple sentence to crash jqt with jengine beta
> > > >>   (32#1)&(128!:3)
> > > >>
> > > >> there are no visible changes in xcrc.c
> > > >>
> > > >> Вс, 12 июн 2016, bill lam написал(а):
> > > >>
> > > >>> I'm not sure if the problem is actually related to recent
> > > >>> jengine changes, but it is quite strange to me.
> > > >>>
> > > >>> JVERSION
> > > >>> Engine: j805/j64/linux
> > > >>> Beta: commercial/2016-05-10T12:23:26
> > > >>> Library: 8.04.15
> > > >>> Platform: Linux 64
> > > >>> Installer: unknown
> > > >>> InstallPath: /usr/share/j/8.0.4
> > > >>> Contact: www.jsoftware.com
> > > >>>
> > > >>>
> > > >>> I have a script which can be simplified to this line to
> > > >>> reproduce the crash,
> > > >>>   crc32=: (((i.32) e. 32 26 23 22 16 12 11 10 8 7 5 4 2 1 0)&(128!:3))
> > > >>>
> > > >>> which crashed jqt (Qt 5.6.1) on loading it but occasionally it
> > > >>> didn't crash.  However it didn't crash when running on jconsole.
> > > >>>
> > > >>> ***
> > > >>>
> > > >>> It tested with the original jengine, and it didn't crash on both
> > > >>> jqt and jconsole.
> > > >>>
> > > >>> Engine: j804/j64/linux
> > > >>> Release: commercial/2015-12-28 10:47:03
> > > >>> Library: 8.04.15
> > > >>> Platform: Linux 64
> > > >>> Installer: unknown
> > > >>> InstallPath: /usr/share/j/8.0.4
> > > >>> Contact: www.jsoftware.com
> > > >>>
> > > >>> --
> > > >>> regards,
> > > >>> 
> > > >>> GPG key 1024D/4434BAB3 2008-08-24
> > > >>> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> > > >>> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
> > > >>>
> > > >>
> > > > --
> > > > 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
> 
> -- 
> regards,
> 
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3

-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] Language committee: in-place assignment rules

[bill lam]

I opt for ignore it.

To stack a deep copy is inefficient, but it is possible a clever
way to do it will be discovered someday.

Just my 2 cents

Пн, 20 июн 2016, Henry Rich написал(а):
> The issue:
> 
> ipm =: 3 : 0
> 
> ip =: 2 (0}) ip
> 
> )
> 
>ip =: i. 3
> 
>(ipm '') ] ip
> 
> 2 1 2
> 
> 
> As you see, ip was modified by call to ipm, which did an in-place
> assignment.  This violates the rules, which say that the value of ip should
> have been stacked.  In fact, a pointer to the value is stacked.
> 
> 
> This requires a decision.  I think we need a committee of J Language Experts
> to decide how to resolve issues like this, and future enhancements.
> 
> 
> The choices as I see them are:
> 
> 1 - Fix to conform to the Dictionary.  Possible; would slow things down a
> little; would make some assignments currently done in-place perform a copy.
> 
> 
> 2 - Ignore it.  Leave as is.
> 
> 
> 3 - Embrace it - declare that in-place assignments to global variables may
> affect previously-stacked references to the same name.  [With local
> variables the problem does not arise]
> 
> Now we need a Language Committee, and a decision.
> 
> 
> Henry
> 
> 
> 
> 
> 
> 
> 
> --
> For information about J forums see http://www.jsoftware.com/forums.htm

-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jsource] strtol

[bill lam]

I agree the testcase is contrived and 64-bit overflow should not
happen in real world unless the same application has running
continuously for many years (or millennium?). 


Чт, 09 июн 2016, Eric Iverson написал(а):
> Bill,
> 
> Thanks for pointing out the last remaining use of strtol (last letter is a
> lowercase el). This caused the problem seen in win64 vs linux64.
> 
> I have pushed a change so that strtoI (last letter is a capitol eye) is
> used instead and this fixes the immediate problem (overflow before it is
> necessary in win64).
> 
> The larger and older problem of overflow remains, but does not warrant the
> effort to fix now. This is not a practical problem and there are better
> areas to spend our efforts.
> 
> On Thu, Jun 9, 2016 at 11:28 AM, 'Pascal Jasmin' via Source <
> sou...@jsoftware.com> wrote:
> 
> > Even if this is "MS's fault", could windows get the same behaviour as
> > linux on this?
> >
> >
> >
> >
> > - Original Message -
> > From: bill lam <bbill@gmail.com>
> > To: Source forum <sou...@jsoftware.com>
> > Sent: Thursday, June 9, 2016 9:20 AM
> > Subject: Re: [Jsource] strtol
> >
> > No problem on linux64
> >
> >a_12345678901234_ =: 3
> >cocreate ''
> > +--+
> > |12345678901235|
> > +--+
> >JVERSION
> > Engine: j805/j64/linux
> > Beta: commercial/2016-05-10T12:23:26
> > Library: 8.04.15
> > Platform: Linux 64
> > Installer: unknown
> > InstallPath: /usr/share/j/8.0.4
> > Contact: www.jsoftware.com
> >
> > I suspect it only breaks on windows64 where strtol is 32-bit.
> >
> >a_12345678901234_ =: 3
> >cocreate''
> > +--+
> > |2147483648|
> > +--+
> >JVERSION
> > Engine: j804/j64/windows
> > Release: commercial/2015-12-21 16:18:48
> > Library: 8.04.15
> > Platform: Win 64
> > Installer: j801 beta install
> > InstallPath: z:/usr/share/j/8.0.4
> > Contact: www.jsoftware.com
> >
> >
> >
> > Чт, 09 июн 2016, bill lam написал(а):
> > > Did you test on windows?  Does it also failed on linux or mac?
> > > On Jun 9, 2016 8:11 PM, "'Pascal Jasmin' via Source" <
> > sou...@jsoftware.com>
> > > wrote:
> > >
> > > > On a (afaiu) related note, could the numbered locale limit be raised
> > on 64
> > > > bit systems?
> > > >
> > > >
> > > > a_12345678901234_ =: 3
> > > >
> > > > cocreate ''
> > > > ┌───┐
> > > > │-2147483646│
> > > > └───┘
> > > >
> > > >
> > > > using unlimited extended integers (to track next object number) on all
> > > > systems (or just on 32bit) would seem viable as well.
> > > >
> > > > The constraint becomes an issue with systems that hope to have high
> > uptime.
> > > >
> > > >
> > > >
> > > >
> > > > - Original Message -
> > > > From: Henry Rich <henryhr...@gmail.com>
> > > > To: sou...@jsoftware.com
> > > > Sent: Wednesday, June 8, 2016 12:25 PM
> > > > Subject: Re: [Jsource] strtol
> > > >
> > > > The way to create a testcase is to create a locale with a very large
> > > > number, by
> > > >
> > > > a_2147483648_ =: 5
> > > >
> > > > locale numbering will start after the largest number that has been
> > used.
> > > >
> > > > Henry
> > > >
> > > > On 6/8/2016 8:54 AM, bill lam wrote:
> > > > > I think using strtoI should be harmless, but I am not sure if u will
> > > > exceed
> > > > > range of 32-bit integer. And how to design a test script to show
> > strtol
> > > > > will fail while strtoI will pass.
> > > > >
> > > > > PS. I realized it is nearly impossible to distinguish strtol (last
> > > > > character is el) and strtoI (last is capital i) on android gmail app.
> > > > > On Jun 8, 2016 8:36 PM, "Raul Miller" <rauldmil...@gmail.com> wrote:
> > > > >
> > > > >> Oh!
> > > > >>
> > > > >> There is also a microsoft supplied definition for strtoI, I was
> > > > >> similarly lazy and forgot to look in the source code to see if it
> > > > >> redefined the name 

Re: [Jsource] strtol

[bill lam]

Did you test on windows?  Does it also failed on linux or mac?
On Jun 9, 2016 8:11 PM, "'Pascal Jasmin' via Source" <sou...@jsoftware.com>
wrote:

> On a (afaiu) related note, could the numbered locale limit be raised on 64
> bit systems?
>
>
> a_12345678901234_ =: 3
>
> cocreate ''
> ┌───┐
> │-2147483646│
> └───┘
>
>
> using unlimited extended integers (to track next object number) on all
> systems (or just on 32bit) would seem viable as well.
>
> The constraint becomes an issue with systems that hope to have high uptime.
>
>
>
>
> - Original Message -
> From: Henry Rich <henryhr...@gmail.com>
> To: sou...@jsoftware.com
> Sent: Wednesday, June 8, 2016 12:25 PM
> Subject: Re: [Jsource] strtol
>
> The way to create a testcase is to create a locale with a very large
> number, by
>
> a_2147483648_ =: 5
>
> locale numbering will start after the largest number that has been used.
>
> Henry
>
> On 6/8/2016 8:54 AM, bill lam wrote:
> > I think using strtoI should be harmless, but I am not sure if u will
> exceed
> > range of 32-bit integer. And how to design a test script to show strtol
> > will fail while strtoI will pass.
> >
> > PS. I realized it is nearly impossible to distinguish strtol (last
> > character is el) and strtoI (last is capital i) on android gmail app.
> > On Jun 8, 2016 8:36 PM, "Raul Miller" <rauldmil...@gmail.com> wrote:
> >
> >> Oh!
> >>
> >> There is also a microsoft supplied definition for strtoI, I was
> >> similarly lazy and forgot to look in the source code to see if it
> >> redefined the name (which it looks like it does).
> >>
> >> So one part of my objection (that strtoI would cause problems which
> >> currently do not happen) should not be the case.
> >>
> >> But the other issue - that it does not seem like strtoI would fix
> >> anything (would not make J perform in a fashion which is closer to
> >> what was prescribed by the dictionary), either - might still be an
> >> issue.
> >>
> >> Do you disagree?
> >>
> >> Thanks,
> >>
> >> --
> >> Raul
> >>
> >>
> >> On Wed, Jun 8, 2016 at 1:12 AM, bill lam <bbill@gmail.com> wrote:
> >>> I am sorry that I was too lazy to include the definition of
> >>> strtoI for discussion
> >>>
> >>> #if SY_64
> >>> #define IMAX9223372036854775807L
> >>> #define FMTI"%lli"
> >>> #define FMTI02  "%02lli"
> >>> #define FMTI04  "%04lli"
> >>> #define FMTI05  "%05lli"
> >>>
> >>> #if SY_WIN32
> >>> #define strtoI _strtoi64
> >>> #else
> >>> #define strtoI  strtoll
> >>> #endif
> >>>
> >>> #else
> >>> #define IMAX2147483647L
> >>> #define FMTI"%li"
> >>> #define FMTI02  "%02li"
> >>> #define FMTI04  "%04li"
> >>> #define FMTI05  "%05li"
> >>> #define strtoI  strtol
> >>> #endif
> >>>
> >>> For *nix, strtol and strtoll are almost equivalent.
> >>>
> >>> Вт, 07 июн 2016, Raul Miller написал(а):
> >>>> I think strtol (long result) should be better than strtoI (int
> result).
> >>>>
> >>>> The distinction should only matter when a numeric local name exceeds
> >>>> the value which can be stored in a 32 bit integer. That's a rare
> >>>> problem and it's probably more important that the behavior be correct
> >>>> for that case on 64 bit systems than on 32 bit systems. Worse,
> >>>> changing to strtoI would not actually fix any failure case, but it
> >>>> would introduce additional failure cases.
> >>>>
> >>>> That said, it might be worthwhile investigating a solution for the
> >>>> resulting problem. I guess you would first want to cocreate/coerase
> >>>> about 5 billion times to see if that works. And, if it fails, work
> >>>> from there.
> >>>>
> >>>> One possible failure mode would be overlapping locales. For example,
> >>>> locale 4294967296 on a 32 bit system might be the same as locale 0.
> >>&g

Re: [Jsource] git and c usage suggestions?

[bill lam]

Certainly all suggestions are appreciated.  Please also take a look (if
case not yet) the j git repo section at
http://www.jsoftware.com/source.htm

in particular JPD and JCD.

Also the jsource git repo in github is a read-only mirror.
On May 18, 2016 7:41 AM,  wrote:

> Do folks want me to make suggestions how to make better commits to the
> J source repository?
>
> Doing proper write-ups what's sub-optimal and what to do instead would
> take a lot of my time, so please let me know if you'd be interested in
> constructive criticism at all.  Eric?  Bill?  Henry?
>
> Simple changes how commits are done would go a long way.  My suggestions
> would refer to better git usage or coding style.
>
>
> Job credentails:
>
> I have three decades of open source coding under my belt,
> (Whenever you are using any of gcc, gdb, emacs, vim, or cvs,
> you are actually running my code, too :-)
>
> I am also inherited enough Original German Bluntness genes
> to do this job.
>
> Martin
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm