Skip to content

Releases: Co-dfns/Co-dfns

Co-dfns v5.6.0

05 Apr 06:10
Compare
Choose a tag to compare
  • Add support for strand assignment
  • Fix parser error related to stranding and strand assignment
  • Fix a bug in handling of variable binding detection related to stranding

Co-dfns v5.5.0

29 Mar 12:57
Compare
Choose a tag to compare

What's New:

  • Fix an issue with device allocated complex arrays not squeezing properly
  • Partially support the function; this still has a lot of issues
  • Partial support for ⎕← and ⍞←; this is preliminary, and it only works with the executable interface, not the DWA interface
  • The Compile and Exec API calls now allow you to create standalone executables that will execute a namespace
  • Fix a bug in returning too soon from functions that end with only guard statements
  • Improve tracing and error handling
  • Improve text output and handling by defaulting to UTF-8 output
  • Improve error reporting message formatting in the DWA interface
  • Fix a bug in which indexing could result in attempting to migrate nested arrays to the device storage
  • Fix a bug in handling of ⌶
  • Improve parsing error handling for numbers, guards, etc.
  • Add support for passing an environment to TK
  • Add preliminary parsing for Keyword statements
  • Add preliminary parsing for Trad-fns
  • Add preliminary parsing support for :: error guards
  • Fix a bug that caused the parser to be very slow for large amounts of code during symbol table generation
  • Fix issues in which some of the primitives were using ⎕CT≠0 algorithms; everything now assumes the use of ⎕CT=0
  • Fix issues in error reporting
  • Preliminary label parsing

Co-dfns v5.4.0

11 Dec 11:29
Compare
Choose a tag to compare

What's New:

  • Updated documentation reflecting runtime changes and the side effects of the runtime changes of v5
  • Implement Key over simple vector keys
  • Fix a bug in generating code when assignments appeared within guards
  • Implement interval index over numeric vector right arguments
  • Update the user command so that it no longer presents the -af option (which is no a no-op)

Co-dfns v5.3.1

07 Dec 08:43
Compare
Choose a tag to compare

What's New:

  • Fix an issue with nested inputs to scalar primitives

Co-dfns v5.3.0

06 Dec 03:50
Compare
Choose a tag to compare

What's New:

  • Making the runtime will give more feedback about the stage it is in
  • Implement partition (⊆)
  • Fix an issue with parsing F[]V←... constructs
  • Implement high rank where (⍸)
  • Implement partitioned enclose

Co-dfns v5.2.0

03 Dec 02:54
Compare
Choose a tag to compare

What's New:

  • Complete implementation of pick
  • Floor over complex values
  • Quadratic index of implementation for nested or high-ranked values
  • Implement without
  • Fix an issue with nested vectors and replicate
  • Implement split (with axis) on non-scalar ranks
  • Implement first occurrence

Co-dfns v5.1.0

01 Dec 02:14
Compare
Choose a tag to compare

What's New:

  • Indexing over high-rank arrays on device storage

Co-dfns v5.0.2

01 Dec 00:10
Compare
Choose a tag to compare

What's New:

  • Fix issues with the user-command interface
  • Expand the basic functions for building and testing the compiler runtime
  • Don't link against ArrayFire for normal objects, since we only need to link against the Co-dfns runtime

Co-dfns v5.0.1

20 Nov 16:38
Compare
Choose a tag to compare

What's New:

  • Fix a syntax error in the clang compilation step

Co-dfns v5.0.0

08 Nov 17:03
Compare
Choose a tag to compare

After much work and labor pains, the newest version of Co-dfns is here! This is a huge release with a massive number of changes, so it's worth laying them out.

What's New

New runtime architecture

The biggest thing to come to Co-dfns in this release is that the entire runtime has been rewritten to follow a new architecture and to allow almost all of it to be written in APL. This means that now the runtime is a separately compiled and distributed object that you'll need to build and ship with your product. See the installation guide for more details on how to build the runtime.

Almost complete language support

With the exception of Key (), Format (), and Inverse (⍣¯1), we expect that all normal primitives are now fully supported. This includes fixing and removing a number of the limitations in the previous implementations of some primitives.

Removal of most system limitations

We have removed all known limitations on things like depth, rank, data type, and so forth. The only known remaining limitation is that indexing into device arrays that have a rank greater than 4 is not yet supported. We have complex and nested array support for all primitives for which it makes sense. We have added support for character arrays (8, 16, and 32-bit) as well as allowing for mixed arrays.

This also includes limitations on the use of user-defined operators within the source code, which can now take any type of operands.

See the Limitations section of the manual for more information on the limitations that are still present in the system.

Improved error handling and stack tracing

When an error occurs in a compiled module, the system will generate a complete stack trace together with line information both for the original source input as well as the corresponding compiled target language source line. This tracking occurs at the "token by token" level, meaning that you get a trace of the execution of an expression down to the individual application level, and not just the line level.

Furthermore, we have a much richer set of parsing errors that provides richer errors when parse-time errors are discovered.

Data type squeezing and handling of overflow

The system will now squeeze and promote arrays as appropriate. In order to maintain performance, we will automatically promote arrays to the largest safest type for a given computation. We will also only squeeze arrays down when it seems convenient to do so. This is meant to improve performance on GPU kernels while still giving the advantages of squeezing and promotion.

CPU and GPU execution

The C runtime will now execute small array computations on the CPU, and only migrate computations to the GPU when a given threshold is crossed. GPU migration is meant to be mostly "sticky," so computations should stay on the GPU after they have migrated unless they collapse back down into very small arrays (scalars).

Some added features

There are some new features which even Dyalog APL does not have:

  • We support any arbitrary rank, even greater than 15
  • Any arbitrary function can be modified with the axis operator. See rtm/prim.apln for some examples of how this is used and accessed.
  • There is a platform agnostic foreign function interface using the primitive, also demonstrated in the rtm/prim.apln code.
  • We have full support for real closures, which enables future dfns behaviors to be richer than those presently possible in the interpreter
     

What's changed

We have removed the old runtime API, since it is being redesigned and currently doesn't operate under the new runtime model. This includes the caching API.

The C calling conventions and behaviors are now different.

Unfortunately, the new runtime is not yet optimized for all workloads, and it is likely that you will see a slow down in some of your code in this version as we work to improve the performance of the system over subsequent releases.

Our implementation of stencil follows the "stencil function" format instead of the stencil operator that is included in Dyalog APL. Please take note of this difference.

We currently generate excessive amounts of code, which can make large namespaces somewhat heavy and long to compile. We are working to improve this.