iocane / unbox Goto Github PK

GPL licensed J interpreter

License: Other

C 49.84% C++ 4.75% J 45.11% Logos 0.28% Batchfile 0.02% Shell 0.01%

unbox's Introduction

Unbox

Introduction

Unbox is a GPLv3 licensed version of the J programming language interpreter derived from the initial J Software source release. The goals of this project are to provide bug fixes in the short term and language enhancements and new features in the long term. Although this is intended to be used as a drop in replacement for the J shared library the behavior of the interpreter and the definition of the language itself will likely diverge from the official J Software version over time.

Building

Prerequisites

Unbox uses the tup build system. Install tup for your platform.
Clone the repository
Edit tup.config
- CONFIG_RELEASE: toggle the optimizations / debugging information
- CONFIG_TEST: toggle whether or not to run the test script suite after a successful build
- CONFIG_CLANG: y to use clang instead of gcc on Linux
- CONFIG_X86_64: toggle 64/32 bit build
- CONFIG_READLINE: toggle readline support for jconsole on Linux

Linux

The build scripts assume you are using a 64 bit compiler even if targeting a 32 bit architecture. Using a 32 bit version of gcc, e.g., will require some changes to the build scripts.

Make sure tup is in your PATH
Type tup in the working directory

Windows (Visual Studio 2013 Community)

The build scripts only target 64 bit Windows builds at the moment.

Make sure tup is in your PATH
Open Visual Studio Tools (from the start menu, not Visual Studio)
From the Visual Studio Tools folder, run the "64 bit native" command prompt
Change to the Unbox source directory and type tup

Mac

I do not have access to a Mac and have not tried building this yet. If you are a Mac user, please test and report your results and I will update this section.

Tests

To run the test suite set the CONFIG_TEST=y in tup.config and rerun tup.

If a test fails run bin/jconsole -debug test/<path-to-test> to see where the failure is occuring.

Contributing

The preferred ways to contribute code are:

Send me a patch and I will review it and apply it to the develop branch
Make a new branch off of develop, e.g., myfeature, and make your changes in that branch. When you are done with your changes create a pull request on Github and I will pull, test/edit and then merge into develop.

unbox's People

Contributors

Stargazers

Watchers

Forkers

henryhrich neitzel jonghough gsstark nunb joebo

unbox's Issues

Segmentation fault on some gerund arguments to ^:

Executing the following yields a segfault with any string in place of 'string':

]^:(1:`(<,'0';'string')) 0

Bug in linear representation parenthesis parsing

The following verb is represented incorrectly by linear representation (5!:5).

]@((,'(')&])

The output of 5!:5 is

]@(,'(')&]

whereas replacing '(' with '[' yields (correctly)

]@((,'[')&])

No tup entry for config/macosx

System is: Mac OSX 10.11.2

Note that I installed tup via Homebrew, which required two steps due to some kext permission thing:

$ brew install Caskroom/cask/osxfuse
$ brew install homebrew/fuse/tup

Here is the full output:

$ tup
[ tup ] [0.000s] Scanning filesystem...
[ tup ] [0.003s] Reading in new environment variables...
[ tup ] [0.003s] Parsing Tupfiles...
* 1) [0.002s] .
tup error: Unable to find tup entry for file 'config/macosx'
tup error: Failed to parse included file 'config/macosx'
tup error: Error parsing Tupfile line 16
  Line was: 'include config/@(TUP_PLATFORM)'
 [     ETA~=<1s      ]   5%
 *** tup: 1 job failed.

Tried on the develop branch to be thorough; same error:

$ git checkout develop
Branch develop set up to track remote branch develop from origin.
Switched to a new branch 'develop'
$ tup
[ tup ] [0.000s] Scanning filesystem...
[ tup ] [0.024s] Reading in new configuration/environment variables...
 1) updated variant: tup.config
 [ ] 100%
[ tup ] [0.027s] Parsing Tupfiles...                                                                                   
* 1) [0.002s] .
tup error: Unable to find tup entry for file 'config/macosx'
tup error: Failed to parse included file 'config/macosx'
tup error: Error parsing Tupfile line 16
  Line was: 'include config/@(TUP_PLATFORM)'
 [     ETA~=<1s      ]   5%
 *** tup: 1 job failed.
$

Failing test on OSX

Here's what I get:

$ tup
[ tup ] [0.000s] Scanning filesystem...
[ tup ] [0.039s] Reading in new environment variables...
[ tup ] [0.039s] No Tupfiles to parse.
[ tup ] [0.039s] No files to delete.
[ tup ] [0.049s] Executing Commands...
* 1) TEST test/core/g110.ijs                                                                                           
test/core/g110.ijs: failed
|NaN error: sgn
|       test x=:o._10+?5 10$20
|[-8] test/core/g110.ijs

 *** tup errors ***
 *** Command ID=1401 failed with return value 1
tup error: Expected to write to file 'build/test/g110.ijs.pass' from cmd 1401 but didn't
 *** Additionally, command 1401 failed to process input dependencies. These should probably be fixed before addressing the command failure.
 2) [0.042s] TEST test/core/g111a.ijs                                                                                  
 3) [0.051s] TEST test/core/g110s.ijs                                                                                  
 4) [0.052s] TEST test/core/g111.ijs                                                                                   
 [                                        ETA~=5s  Remaining=312 Active=0                                        ]   1%
 *** tup: 1 job failed.

I examined the test more closely with unbox/bin/jconsole, and it appears to fail when there are zeros present in the x table, but it succeeds when there are no zeros.

Build fails on ARM

What I did:

$ git clone https://github.com/iocane/unbox.git
$ cd unbox
$ tup

Many errors of the same type happen when tup gets to the file src/libj/x15.c, right before an #if SY_WIN32 section.

Here's an example of the error:

src/libj/x15.c:845:1: error: initializer element is not constant
 I static cbv[]={(I)&cb0,(I)&cb1,(I)&cb2,(I)&cb3,(I)&cb4,(I)&cb5,(I)&cb6,(I)&cb7,(I)&cb8,(I)&cb9};
 ^
src/libj/x15.c:845:1: error: (near initialization for 'cbv[0]')
src/libj/x15.c:845:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 I static cbv[]={(I)&cb0,(I)&cb1,(I)&cb2,(I)&cb3,(I)&cb4,(I)&cb5,(I)&cb6,(I)&cb7,(I)&cb8,(I)&cb9};
                         ^
src/libj/x15.c:845:1: error: initializer element is not constant
 I static cbv[]={(I)&cb0,(I)&cb1,(I)&cb2,(I)&cb3,(I)&cb4,(I)&cb5,(I)&cb6,(I)&cb7,(I)&cb8,(I)&cb9};
 ^
src/libj/x15.c:845:1: error: (near initialization for 'cbv[1]')
src/libj/x15.c:845:33: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 I static cbv[]={(I)&cb0,(I)&cb1,(I)&cb2,(I)&cb3,(I)&cb4,(I)&cb5,(I)&cb6,(I)&cb7,(I)&cb8,(I)&

Errors for cbv[2] through cbv[8] elided for brevity here. Last few lines of output:

src/libj/x15.c:857:1: error: initializer element is not constant
 I static cbvx[]={(I)&cbx0,(I)&cbx1,(I)&cbx2,(I)&cbx3,(I)&cbx4,(I)&cbx5,(I)&cbx6,(I)&cbx7,(I)&cbx8,(I)&cbx9};
 ^
src/libj/x15.c:857:1: error: (near initialization for 'cbvx[9]')
 *** tup errors ***
 *** Command ID=858 failed with return value 1
tup error: Expected to write to file 'build/x15.o' from cmd 858 but didn't
 *** Additionally, command 858 failed to process input dependencies. These should probably be fixed before addressing the command failure.
 [ETA~=7s  ]  11%
 *** tup: 1 job failed.

Here's some info about my system. For what it's worth, I use the "raspi" version of the official J804 release.

$ uname -a
Linux localhost 3.8.11 #1 SMP Wed Jan 6 19:59:47 PST 2016 armv7l armv7l armv7l GNU/Linux
$ cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 48.00
Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc0f
CPU revision    : 4

processor       : 1
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 48.00
Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc0f
CPU revision    : 4

Hardware        : SAMSUNG EXYNOS5 (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000

Segfault under complicated conditions

The following code causes a segfault. If NOUN is assigned to a string not ending in LF, there is no segfault, and likewise if NOUN is assigned a value before assigning it a string ending in LF.

verb=: 0:`NOUN@.(0=#)
NOUN =: 'string',LF
verb ''

Better integration

I was wondering if it's possible to get better integration with the rest of the system, particularly Linux.

That is I would like to install J to a structure which resembles the following:

# /usr is optional here, it's just a PREFIX.
/usr/bin/j # jconsole conflicts with java packages.
/usr/lib/libj.so
/usr/share/j/profile.ijs
/usr/share/doc/j/...

But as it stands this will result in libj.so failing to load because you appear to hardwire some path into dlopen, I'm not sure.

A somewhat less nice solution I could use is to dump everything into /opt so jconsole has the same directory as libj.so and then symlinking jconsole to /usr/bin/j.

The other feature I'd like to consider is moving .jhistory out of the users HOME and following something more in-line with XDG_DATA_DIR/j/history which would typically expand to HOME/.local/share/j/history. (See https://wiki.archlinux.org/index.php/XDG_Base_Directory_support)

Antiderivative fails

This gives a strange result:
(^&_2) d. _1

which returns
[

The correct result should be something like
_1&*@:(^&_1)

Presumably the bug is in the file cd.c.

Build fails on windows 7 64-bit, building for 64-bit

Running tup on windows7 64-bit.
All compiles complete OK.
First LINK (for libj) fails with message
src\libj\win\winasm64.obj : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'

Inconsistent behavior of ~. and special code failure

See this J forum post for full details. Inconsistencies in how ~. and /. handle arguments with tolerantly equal elements. In particular, the following results are dangerously incorrect.

   tb =: 1+2e_14*i:3
   #tb
7
   #/.~ 1+2e_14*i:3  NB. sum of group lengths should be total length
3
   (#,{.)/.~ tb  NB. Should not fail
|length error
|       (#,{.)/.~tb

Segfault on infinite recursion

The following code (containing a verb which, with the given argument, executes itself on that argument) segfaults rather than failing with a stack error.

3 :'y`:6 y' 3 :'y`:6 y'`''

E. fails on integer input containing _1

The following line returns all zeros even though the left argument is contained in the right:

_2 1  E.  1 2 _1 _2 1

This is the case whenever a _1 appears in the right argument to E. before the left argument does.