Coder Social home page Coder Social logo

comunica / sparqlee Goto Github PK

View Code? Open in Web Editor NEW
14.0 7.0 8.0 1.61 MB

⚙️ SPARQL expression evaluator library - Moved to @comunica/expression-evaluator

Home Page: https://www.npmjs.com/package/sparqlee

TypeScript 99.25% Shell 0.34% JavaScript 0.40%
sparql sparql-query expression-evaluator expression-engine rdf linked-data

sparqlee's Introduction

Sparqlee - Moved to Comunica

Build status Coverage Status npm version Gitter chat

A simple spec-compliant SPARQL 1.1 expression evaluator library.

This package is available on npm, type definitions are provided.

Using Sparqlee

import { translate } from "sparqlalgebrajs";
import { stringToTerm } from "rdf-string";

// An example SPARQL query with an expression in a FILTER statement.
// We translate it to SPARQL Algebra format ...
const query = translate(`
  SELECT * WHERE {
     ?s ?p ?o
     FILTER langMatches(lang(?o), "FR")
    }
`);

// ... and get the part corresponding to "langMatches(...)".
const expression = query.input.expression;

// We create an evaluator for this expression.
// A sync version exists as well.
const evaluator = new AsyncEvaluator(expression);

// We can now evaluate some bindings as a term, ...
const result: RDF.Term = await evaluator.evaluate(
  Bindings({
    ...
    '?o': stringToTerm("Ceci n'est pas une pipe"@fr),
    ...
  })
);

// ... or as an Effective Boolean Value (e.g. for use in FILTER)
const result: boolean = await evaluator.evaluateAsEBV(bindings);

Note: If you want to use aggregates, or exists you should check out the stream section.

Config

Sparqlee accepts an optional config argument, that is not required for simple use cases, but for feature completeness and spec compliance it should receive now, baseIRI, exists, aggregate and bnode.

For the extended date functionality (see later), an additional context item has been added: implicitTimezone. The choice was made to default to the timezone now has. It can be desired to set it explicitly so implicitTimezone does not change over time (i.e., it is not dependent on daylight saving time).

interface AsyncEvaluatorContext {
  now?: Date;
  baseIRI?: string;

  exists?: (expression: Alg.ExistenceExpression, mapping: Bindings) => Promise<boolean>;
  aggregate?: (expression: Alg.AggregateExpression) => Promise<RDF.Term>;
  bnode?: (input?: string) => Promise<RDF.BlankNode>;
  extensionFunctionCreator?: (functionNamedNode: RDF.NamedNode) => (args: RDF.Term[]) => Promise<RDF.Term> | undefined;
  overloadCache?: LRUCache<string, SomeInternalType>;
  typeCache?: LRUCache<string, SomeInternalType>;
  getSuperType?: (unknownType: string) => string;
  implicitTimezone?: { zoneHours: number; zoneMinutes: number;}; 
}

See the stream and context dependant function sections for more info.

Errors

Sparqlee exports an Error class called ExpressionError from which all SPARQL related errors inherit. These might include unbound variables, wrong types, invalid lexical forms, and much more. More info on errors here. These errors can be caught, and may impact program execution in an expected way. All other errors are unexpected, and are thus programmer mistakes or mistakes in this library.

There is also the utility function isExpressionError for detecting these cases.

// Make sure to catch errors if you don't control binding input
try {
  const result = await evaluator.evaluate(bindings);
  consumeResult(result;)
} catch (error) {
  if (isExpressionError(error)) {
    console.log(error); // SPARQL related errors
    ...                 // Move on, ignore result, ...
  } else {
    throw error;        // Programming errors or missing features.
  }
}

Exists

'Exists' operations are an annoying problem to tackle in the context of an expression evaluator, since they make the operation statefull and context dependant. They might span entire streams and, depending on the use case, have very different requirements for speed and memory consumption. Sparqlee has therefore decided to delegate this responsibility back to you.

You can, if you want, pass hooks to the evaluators of the shape:

exists?: (expression: Alg.ExistenceExpression, mapping: Bindings) => Promise<boolean>;

If Sparqlee encounters any or existence expression, it will call this hook with the relevant information so you can resolve it yourself. If these hooks are not present, but an existence expression is encountered, then an error is thrown.

An example consumer/hook can be found in Comunica.;

Aggregates

We provide an AggregateEvaluator to which you can pass the individual bindings in the stream, and ask the aggregated result back. It uses Sparqlee's internal type system for operations such as sum and avg.

const stream = [bindings1, bindings2, bindings3];

if (stream.length === 0) {
  return AggregateEvaluator.emptyValue(aggregateExpression);
} else {
  const evaluator = new AggregateEvaluator(aggregateExpression, bindings[0]);
  stream.slice(1).forEach((bindings) => evaluator.put(bindings));
  return evaluator.result();
}

We have not found any SPARQL Algebra for which this occurs, but we happen to find any aggregate expressions nested in the expression (or even at the top level), we will call (similarly to EXISTS) an aggregate hook you might have provided.

aggregate?: (expression: Alg.AggregateExpression) => Promise<RDF.Term>;

You can probably ignore this.

We also provide an AsyncAggregateEvaluator to that works the same way AggregateEvaluator does. The signature of only the put method changes to be async. It is up to you to handle this correctly. You are for example expected to await all puts before you ask for result. You should also note the order of calling and awaiting put while using the GroupConcat aggregator.

Extension functions

Extension functions can be added by providing the extensionFunctionCreator in the config. Example

config.extensionFunctionCreator = (functionName: RDF.NamedNode) => {
   if (functionNamedNode.value === 'https://example.org/functions#equal') {
      return async (args: RDF.Term[]) => {
         return literal(String(args[0].equals(args[1])), 'http://www.w3.org/2001/XMLSchema#boolean');       
      }
   }
}

Extended Xsd Types

Using this flag we can use Overload function caching and Super type discovery. This flag makes the type system more powerful and reliable. In most cases however the old system works perfectly. Using this experimental system makes sparqlee a bit slower but more reliable using type promotion for example.

Overload function caching

An overloadcache allows Sparqlee to cache the implementation of a function provided the argument types. The cache is only used when setting the enableExtendedXsdTypes flag to true. When not providing a cache in the context, sparqlee will create one. The cache speeds up execution time significantly especially when evaluating a lot of bindings that mostly have the same types. This statement is backed up by the integer addition benchmark.

This cache can be reused across multiple evaluators. We don't recommend manual modification.

Super type discovery

This is a feature only available using when enableExtendedXsdTypes is active.

The getSuperType allow a user to use custom types and define their super relationship to other types. Example:

const superTypeDiscoverCallback = (unknownType: string) => {
  if (unknownType === "http://example.org/label") {
    return 'http://www.w3.org/2001/XMLSchema#string';
  }
  return 'term';
}

This is helpful when performing queries over data that uses data-types that are a restriction on the known xsd data types. For example a datasource could define ex:label = "good" | "bad". These are both strings, and we could for example call the substr function on these values. When we want to allow this in a type safe way, we need to check if ex:label is a restriction on string.

The typeCache allows us to cache these super type relationships. This cache can be reused across multiple evaluators. We don't recommend manual modification.

Binary

Sparqlee also provides a binary for evaluating simple expressions from the command line. Example

# (npm binary)
$ sparqlee 'concat("foo", "bar")'
Literal {
  value: 'foobar',
  datatype: NamedNode { value: 'http://www.w3.org/2001/XMLSchema#string' },
  language: '' }

# (in development)
$ node ./dist/bin/Sparqlee.js '7 + 3'
Literal {
  value: '10',
  datatype: NamedNode { value: 'http://www.w3.org/2001/XMLSchema#integer' },
  language: '' }

Context dependant functions

Some functions (BNODE, NOW, IRI) need a (statefull) context from the caller to function correctly according to the spec. This context can be passed as an argument to Sparqlee (see the config section for exact types). If they are not passed, Sparqlee will use a naive implementation that might do the trick for simple use cases.

BNODE

spec

Blank nodes are very dependant on the rest of the SPARQL query, therefore, we provide the option of delegating the entire responsibility back to you by accepting a blank node constructor callback. If this is not found, we create a blank node with the given label, or we use uuid (v4) for argument-less calls to generate definitely unique blank nodes of the shape blank_uuid.

bnode(input?: string) => RDF.BlankNode

Now

spec

All calls to now in a query must return the same value, since we aren't aware of the rest of the query, you can provide a timestamp (now: Date). If it's not present, Sparqlee will use the timestamp of evaluator creation, this at least allows evaluation with multiple bindings to have the same now value.

IRI

spec

To be fully spec compliant, the IRI/URI functions should take into account base IRI of the query, which you can provide as baseIRI: string to the config.

Spec compliance

TODO Add section about differences from the spec and which functions are affected (and which are implemented). See also extensible value testing and error handling.

Note about string literals: See issue #2 (simple literals are masked)

  • Implemented: The function is at least partially implemented.
  • Tested: There are tests for this function in this repo.
  • Passes spec: Passes the spec tests (see rdf-test-suite). We test this with Comunica and in ./test/spec. A ? signifies a dedicated spec test is missing, and it does not occur in any other test, an I indicates it has no dedicated spec test, but occurs indirectly in others.
  • Spec compliant: Passes the spec tests, has local tests, and there is high confidence the function is fully spec compliant.
Function Implemented Tested Passes Spec Spec compliant Note
Operator Mapping
! (not) ?
+ (unary plus) ?
- (unary minus) ?
|| I Occurs in bnode01
&& I Occurs in rand01, struuid01, and uuid01
= I Occurs almost everywhere
!= I Occurs almost everywhere
< ?
> ?
<= ?
>= ?
* ?
/ I Occurs in coalesce
+
- ?
Notes Spec compliance depends on #13 and #14
Functional Forms
BOUND X ?
IF X
COALESCE X
NOT EXISTS X X Needs full SPARQL engine to really test
EXISTS X X Needs full SPARQL engine to really test
logical-or I See operators
logical-and I See operators
RDFTerm-equal I See operators
sameTerm X ?
IN X
NOT IN X
Notes
On RDF Terms
isIRI X I Occurs in uuid01
isBlank X ?
isLiteral X I Occurs in struuid01
isNumeric X
str I Occurs in many tests
lang I Occurs in many tests
datatype I Occurs in now01, rand01
IRI X
BNODE X X X X
STRDT X
STRLANG X
UUID X
STRUID X
Notes
On Strings
STRLEN
SUBSTR X
UCASE X
LCASE X
STRSTARTS X
STRENDS X
CONTAINS X
STRBEFORE X
STRAFTER X
ENCODE_FOR_URI X
CONCAT X
langMatches ?
REGEX ? X Missing flag support
REPLACE X X Missing flag support, replace03 should be updated in tests
Notes
On Numerics
abs X
round X
ceil X
floor X
RAND X
_Notes
On Dates and Times Only xsd:dateTime is specified, but we also support xsd:date
now X Whether this is spec compliant depends on whether you pass a spec compliant 'now' config argument
year X
month X
day X
hours X
minutes X
seconds X
timezone X
tz X
Notes
Hash Functions
MD5 X
SHA1 X
SHA256 X
SHA384 X ?
SHA512 X
Notes
XPath Constructor Functions
str (see 'On Terms') I
flt ?
dbl ?
dec ?
int ?
dT ?
bool ?

SPARQL 1.2

Sparqlee looks forward and already implements some SPARQL 1.2 specification functions.

Currently, this is restricted to the extended date functionality. Please note that the new built-in ADJUST function has not been implemented due to package dependencies.

Development

Setup locally

  1. Install yarn (or npm) and node.
  2. Run yarn install.
  3. Use these evident commands (or check package.json):
    • building once: yarn run build
    • build and watch: yarn run watch
    • testing: yarn run test
    • benchmarking: yarn run bench

Adding or fixing functions

Functions are defined in the functions directory, and you can add or fix them there. All definitions are defined using a builder model defined in Helpers.ts.

Three kinds exists:

  • Regular functions: Functions with a uniform interface, that only need their arguments to calculate their result.
  • Special functions: whose behaviour deviates enough from the norm to warrant the implementations taking full control over type checking and evaluation (these are mostly the functional forms).
  • Named functions: which correspond to the SPARQLAlgebra Named Expressions.

TODO: Explain this hot mess some more.

Layout and control flow

The only important external facing API is creating an Evaluator. When you create one, the SPARQL Algebra expression that is passed will be transformed to an internal representation (see Transformation.ts). This will build objects (see expressions module) that contain all the logic and data for evaluation, for example the implementations for SPARQL functions (see functions module). After transformation, the evaluator will recursively evaluate all the expressions.

Type System

See functions/Core.ts, funcions/OverloadTree.ts and util/TypeHandling.ts.

The type system is tailored for doing (supposedly) quick evaluation of overloaded functions.

A function definition object consists of a tree-like structure with a type (e.g. xsd:float) at each internal node. Each level of the tree represents an argument of the function (e.g. function with arity two also has a tree of depth two). The leaves contain a function implementation matching the concrete types defined by the path of the tree.

When a function is called with some arguments, a depth first search, to find an implementation among all overloads matching the types of the arguments, is performed in the tree. If we can not find one, we consider the argument of invalid types.

We also handle subtype substitution for literal terms. What this means is that for every argument of the function and it's associated accepted type, we also accept all subtypes of that type for that argument. These sub/super-type relations define the following type tree: type tree So, when expecting an argument of type xsd:integer we could provide xsd:long instead and the function call would still succeed. The type of the term does not change in this operation.

We also handle type promotion, it defines some rules where a types can be promoted to another, even if there is no super-type relation. Examples include xsd:float and xsd:decimal to xsd:doubleand xsd:anyURI to xsd:string. In this case, the datatype of the term will change to the type it is promoted to.

Testing

Running tests will generate a test-report.html in the root dir.

The testing environment is set up to do a lot of tests with little code. The files responsible for fluent behaviour reside in test/util.
Most tests can be run by running the runTestTable method in test/util/utils.ts. This method expects a TestTable. Multiple test are run over a TestTable (one for every line). A TestTable may contain aliases if the aliases are also provided (Some handy aliases reside in test/util/Aliases.ts). This means that when testing something like "3"^^xsd:integer equals "3"^^xsd:integer is "true"^^xsd:boolean. We would write a small table (for this example some more tests are added) and test it like this:

import { bool, merge, numeric } from './util/Aliases';
import { Notation } from './util/TruthTable';
import { runTestTable } from './util/utils';
runTestTable({
   testTable: `
       3i 3i = true
       3i -5i = false
       -0f 0f = true
       NaN  NaN = false
   `,
   arity: 2,
   operation: '=',
   aliases: merge(numeric, bool),
   notation: Notation.Infix,
});

More options can be provided and are explained with the type definition of the argument of runTestTable.

We can also provide an errorTable to the runTestTable method. This is used when we want to test if calling certain functions on certain arguments throws the error we want. An example is testing whether Unknown named operator error is thrown when we don't provide the implementation for an extension function.

import { bool, merge, numeric } from './util/Aliases';
import { Notation } from './util/TruthTable';
import { runTestTable } from './util/utils';
runTestTable({
   errorTable: `
       3i 3i = 'Unknown named operator'
       3i -5i = 'Unknown named operator'
       -0f 0f = 'Unknown named operator'
       NaN  NaN = 'Unknown named operator'
   `,
   arity: 2,
   operation: '<https://example.org/functions#equal>',
   aliases: merge(numeric, bool),
   notation: Notation.Infix,
});

When you don't care what the error is, you can just test for ''.

In case the tables are too restrictive for your test, and you need an evaluation. You should still use the generalEvaluate function from test/util/generalEvaluation.ts. This function will automatically run both async and sync when possible. This increases your tests' coverage.

sparqlee's People

Contributors

danielbeeke avatar florianfv avatar greenkeeper[bot] avatar jacoscaz avatar jitsedesmet avatar joachimvh avatar renovate-bot avatar renovate[bot] avatar rubensworks avatar rubenverborgh avatar stephaniech97 avatar tpt avatar wschella avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

sparqlee's Issues

Handle invalid lexical form better

@wschella I was wondering whether we can handle the invalidLexical form error from with the overloadTree?
Right now, the Builder enables this behavior from within its functions. This creates some tedious code, since every function added should provide all implementations of InvalidLexicalForm? This behavior makes some functions not function correctly, I think. For example, "apple"^^xsd:integer + "0"^^xsd:integer doesn't throw the right error. It throws implementation not found.

An in-range update of sparqlalgebrajs is breaking the build 🚨

The dependency sparqlalgebrajs was updated from 2.0.1 to 2.1.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

sparqlalgebrajs is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Commits

The new version differs by 3 commits.

  • 1f2142c Update to version 2.1.0
  • 5b112ce Create exception for wildcard typings
  • 8cc2ffb Create separate types for Wildcard and GroupConcat

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @types/jest is breaking the build 🚨

The devDependency @types/jest was updated from 24.0.9 to 24.0.10.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build failed (Details).
  • coverage/coveralls: First build on greenkeeper/@types/jest-24.0.10 at 64.942% (Details).

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Async super type discovery and getting full context in regular functions.

In #112 we closed #109 . We did this in a sync way. It would however be beneficial if the superTypeCallback had type (unknownType: string) => Promise<string> in the AsyncEvaluator. This way a user could for example perform a web call to discover the super type.

We might also want regular functions to get the whole context instead of just the SharedConfig. This way we can make BNODE a regular function. This is also important for the above feature since it is pretty likely we want to do some type checking in regular function in the future.

I made a first implementation of this. I had a few problems.

  1. Making regular functions also have an async implementation makes it that a lot of code gets 'almost' duplicated. It also creates some problems in the aggregators. The Average aggregator for example calls a regular function in its result function. This creates problems for backwards compatibility because we can't make the result function be async.
  2. Having an async superTypeCallback results in a lot of code duplication, mainly in the transformers.

We should find a way to reduce code duplication and we should find a way to keep the result function of aggregators sync.

One way would be copying the function implementation used but I don't really like this idea because it is again, duplication.
We could also split regular function in context dependent and non context dependent regular functions. This would be a solution because the functions used don't require the (complete) context. I don't like this either because we already separate in regular and special functions and I feel like this would again complicate things.
We could also wait for a major release to provide this feature?

AgragateEvaluator uses SyncEvaluator

@wschella I was wondering why AgragateEvaluator uses SyncEvaluatorConfig.
I was trying to make sure the custom-function implementation for #16 was usable in a bigger project like comunica. Within this project almost everything is async, so it wouldn't make any sense to ask a developer for sync extension functions. However, the project uses sparqlee's AggragateEvaloator which is build apon the SyncEvaluator. Maybe we should make an AsyncAggragateEvaloator for completeness?

An in-range update of @types/rdf-js is breaking the build 🚨

The dependency @types/rdf-js was updated from 2.0.2 to 2.0.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/rdf-js is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of jest-html-reporter is breaking the build 🚨

The devDependency jest-html-reporter was updated from 2.4.4 to 2.4.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

jest-html-reporter is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Release Notes for v2.4.5

Bug Fixes:

  • Updated incorrectly documented parameter useCssFile (#62)
Commits

The new version differs by 2 commits.

  • 8dab5aa Merge pull request #64 from Hargne/feature/2.4.5
  • a963351 Updated incorrectly documented settings parameter

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Enable `no-redeclare` rule

While trying to fix #93 it became clear I needed to disable the no-redeclare rule because an implementation of Set is used in the file lib/util/Consts.ts I couldn't just use the default implementation of Set because a union function is used. This issue, tho probably small aims to enable the no-redeclare rule.

Make new type system default

The new type system has been put behind a flag in #117. We should try to make this new type system the default.
This means that we should optimize the new system some more. Even seemingly small optimization mean a lot here. The functions that require special attention are:

  • experimentalTransformLiteral in lib/transformers/TermTransformer
  • isSubTypeOf in lib/util/TypeHandling
  • getSubTreeWithArg in lib/functions/OverloadTree

Of course we could also look at the few functions that are called within these functions.

I don't have any suggestions on how to start optimizing these functions. If there are any more questions regarding this issue you should be able to contact me on them.

strstarts filter bug

Wrong implementation of substr

As explained in #112 (comment), the implementation of substr is wrong. We should update this and write some tests on this new implementation.
This shouldn't be much harder then adding + beginIndex on the endIndex argument of the slice function.

Support blank nodes

This W3C explanation on blank nodes in RDF vs blank nodes in SPARQL is a good reference for expected behaviour semantics.

We should be able to just compare the blank node value.

Migrate to eslint

Since tslint is deprecated, we should migrate to eslint, so we are aligned with the coding conventions in other comunica projects.

In some cases, it may be needed to reconfigure/disable rules.

OverloadTree caching and open world types

These are 2 problems in 1 issue because they need to be implemented with much consideration with eachother.
There has already been a lot of talking surrounding the cache part of this issue in #102 . To make sparqlee truly open world I think we still need to add the functionality of a user providing his own datatypes and making them have the known datatypes as a super type. This way those types can still be provided to functions expecting xsd datatypes due to subtype substitution.

Plain literal behaviour

Context

In the SPARQL spec, more spefically operand data types and [operator mapping] there exist the concepts of:

  • plain literals: one of
    • simple literals
    • language tagged literals
  • typed literals with xsd:string type

Problem

The distinction is important, as the string operators only apply to apply to typed literals, and not the plain ones. For example, following expressions are NOT equivalent:
"foo"^^xsd:string != "bar"^^xsd:string and "foo" != "bar".
The first one will evaluate true, the second one should error, since the operator is not defined. A solution to this is to allow simple literals in problematic operators.

A bigger problem however is that the return type the some functions (mainly functions on strings) is dependent on the original type, e.g. a simple literal should be returned when the (first) argument was a simple literal. This is however impossible.

However: the RDF.js spec hides the difference between simple and typed literals, as it automatically adds the xsd:string data type.

Proposal

Concluded from the discussion on the RDF.js repo, we want to consider simple literals as being typed with xsd:string. By extension, the same goes for language tagged literals and rdf:langString.

Any untyped literals we get as input we could type ourselves.

This will give issues with spec tests.

Spec compliant number representation & precision

The [SPARQL-spec] uses multiple numeric datatypes from the xsd-spec.
These types have a fixed representation, minimal value, maximum value, precision, ...

Currently none of this is checked by us, and everything is the JS number datatype, which is a "a double-precision 64-bit binary format IEEE 754 value", i.e. a double in C, f64 in Rust.

  • Parse (and mostly validate) incoming values correctly
  • Store internally at the correct precision through libraries such as decimal.js
  • Handle correctly during operations such as addition (i.e. should we overflow, widen the type?)
  • Handle correctly during Type Promotion (#12 )
  • Export and print in the correct lexical form (although I think this is already the case)

Ideally the strictness is all quite configurable.

Test function aliases

Things like IRI and URI both refer to the same function, let's make sure both work.

Test both async and sync implementations

Currently the test script always uses the async implementation. This way however we have no clue whether the sync one works as well. And although it has the same logic largely, there are some differences, certainly for the special functions.

Auto casting arguments using `OverloadTree`

With the newly added (#101 ) OverloadTree we can enable auto casting like talked about in #94. I create this new issue because #94 is getting a little big and would get much bigger. I'll link some of the, in my opinion, most relevant comments for this issue from #94 here.

  • Auto casting idea: #94 (comment) and #94 (comment)
  • Needing depth first search: #94 (comment)
  • There's some talk about what types should be handled by auto casting. A clear scheme should be created for this. Once the scheme is ready I will link it in here.
  • Rewriting builder: #101 (comment)

When using auto cast, it could happen that searching an overload operation is pretty expensive. The chosen overload for a given array of arguments will never change however. Each node could have some kind of cache to keep the already calculated searchStack in. This cache would make sparqlee have a global state. We want to take control over that state so when implementing the cache, we should provide functions to reset and maybe set the cache status. A package that could be used for this is: https://www.npmjs.com/package/lru-cache

If I forgot something, please add it in the comments. The issue became kinda big to keep track of 😅

Suport overriding functions

Just like we recently added support for extension functions #16 we should also add support for overriding existing/ default named functions.

An in-range update of @types/node is breaking the build 🚨

The devDependency @types/node was updated from 10.11.2 to 10.11.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).
  • coverage/coveralls: First build on greenkeeper/@types/node-10.11.3 at 78.348% (Details).

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @types/create-hash is breaking the build 🚨

The devDependency @types/create-hash was updated from 1.2.0 to 1.2.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/create-hash is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of rdf-string is breaking the build 🚨

The dependency rdf-string was updated from 1.2.0 to 1.3.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

rdf-string is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Commits

The new version differs by 5 commits.

  • 31093c2 1.3.0
  • 42b0a1b Start tracking changelog
  • d216ed2 Update to generic RDFJS typings
  • a7a3667 Update to ts-jest 23.10.x, Closes #5
  • 58d2a83 Rename RdfTerm to RdfString in README

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Clean up tests

  • Testing between operators is inconsistent
  • Util folder needs documentation and cleanup
  • Util.test needs to be renamed

Breaking changes

@jitsedesmet It looks like something went wrong while checking whether or not changes in sparqlee caused breakages in Comunica. Everything from the master HEAD until this commit causes unit, spec and integration test failures.

I have no bandwidth to look into fixing all of the problems. So my current idea is to revert master back to the state before the OverloadTree was added, as everything still worked there, and there were no performance regressions yet. Unless you see any other solutions @jitsedesmet?

An in-range update of @types/lodash is breaking the build 🚨

The dependency @types/lodash was updated from 4.14.120 to 4.14.121.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/lodash is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Test general concepts

There are a lot of general concepts (error handling, type promotion, EBV), that are implemented, but at the best loosely tested trough some unrelated tests.

Things we should definitely still test:

  • Error handeling
  • Subtype subsitution
  • Type promotion
  • Handling of nonlexicals
  • Coercing to EBV
  • Exists / aggregate hook

Enable `no-implicit-globals` rule

Trying to fix issue #93 I stumbled upon the fact that we use a lot of globally declared functions and maybe some variables (didn't check). This issue aims to remove all those global functions an variables. This issue does not cover global variables within the test folder.

AggregateEvaluators is a mess

AggregateEvaluators is a mess, the single file is 400 lines long and contains 11 classes. If you ask me, we should clean this up by making a new folder aggregators or something like that. And give these classes their own file. I know this will result in a lot of small files but it's cleaner in my opinion.

Test all functions

The spec tests are very insufficient for testing all logic (certainly in regards to types) of all functions. For every function we should add a test ourselves.

An in-range update of sparqlalgebrajs is breaking the build 🚨

The dependency sparqlalgebrajs was updated from 1.1.0 to 1.2.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

sparqlalgebrajs is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Commits

The new version differs by 2 commits.

  • 53fc959 Update to version 1.2.0
  • 687fbbd Update to generic RDFJS typings, Closes #31

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Document spec link explaining `arithmeticWidening`

We should make sure we understand why we use arithmeticWidening and where this behaviour is mentioned in the specs.
This issue has 2 tasks.

  1. Find the specs surounding arithmeticWidening.
  2. Implement arithmeticWidening like the specs sugest.

arithmeticWidening answers a simple question: what type is the return type of an arithmetic operation.
things to consider: it could be that short + short \ne short. Example: is 240 + 100 still a short? It can not be represented as a short. Should we check this? Or do we need to return a short with value 340 which is not a valid short value.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.