- GBC_BOEHM_OWN_ALLOCATOR is dead for a long time
- undef alloc_object was used the function rename to ecl_alloc_object
- remove mark phase ignored by the preprocessor
ecl_assqlp is sufficient and does not require argument parsing at runtime. host
is always checked to be a string, so the ecl_assoc test EQUAL will have the same
effect as the previously checked STRING-EQUAL.
We've used void_reader as an implementation for sharp_{plus,minus}_reader -
sharp readers accept three arguments while void_reader accepted two.
- introduce void_reader3
- change sharp_{plus,minus}_reader to use void_reader3
- remove unused defines (leftovers from the past)
- remove unused void_reader (with two arguments)
Due to rounding issues the exponent can be different than what we
guessed. For example in the following only one digit should appear
before the decimal point such that
(format nil "~,1e" 9.9) => 9.9e+0
is correct but
(format nil "~,1e" 9.9) => 10.0e+0
is incorrect, has to be 1.0e+1.
Split up the options into additional flags for the linker and
additional libraries.
Quoting from issue #636:
> Here's an example, attempting to link one object file named
example.o into an executable named example. Libcrypto here is
superfluous and should be removed by --as-needed:
```
LDFLAGS="-Wl,--as-needed"
LIBS="-lcrypto"
gcc ${LDFLAGS} ${LIBS} example.o -o example # doesn't link libcrypto!
gcc example.o ${LDFLAGS} ${LIBS} -o example # doesn't honor --as-needed!
gcc ${LDFLAGS} example.o ${LIBS} -o example # works great!
```
> In short, the placement of your -l<foo> flags differs from that of
all the other linker flags. Since ECL is only providing one big
variable ld-flags for all of the linker flags, there's no correct
way to pass in options like --as-needed and -l<foo> at the same
time.
Fixes#636.
Due to the typo, all floating point exceptions were enabled after the
test had run. This leads to failures in other tests for instance due
to floating-point-inexact errors. Now, the exception flags are
correctly restored again after the test is finished.
We've allowed any symbol to be supplied as a condition, when it was not
recognized then we've not changed bits (they remained 0). From now on we signal
an error if the condition can't be signaled.
Since user reported the error with keywords used instead of cl symbols, we also
make the manual more clear regarding the package of condition symbols.
Appropriate smoke tests are added too.
Fixes#681.
Unfortunately, execvpe is not standard. However, we can replicate its behavior
by pointing **environ to a new array of environment variable assignments before
execvp.
On Darwin, shared libraries do not have direct access to **environ. Instead, we
use the return value of _NSGetEnviron().
Rename all existing uses of environ (as a variable name) to my_environ as
environ now names a macro on both Darwin and Mingw.
If the target does not HAVE_ENVIRON, fall back to execve as before.
(ext:run-program "env" nil :environ '("foo=bar")) actually exits with non-zero
status because 1) PATH is not specified in the child process and even if it
were 2) the use of :ENVIRON prevents ECL from searching the PATH for child
programs.
Rewrite the tests to actually highlight the failure.
The test ensures that there's no error when HASH-TABLE-TEST is called on a hash
table with a custom equality function. The tests pass, with some caveats:
- I'm only about 70% sure that FINISHES is the right test-predicate to use for
something like this
- The test suite would consistently fail with non-deterministic segfaults while
testing the MULTIPROCESSING subtest. This could easily be due to the fact that
I'm using a FreeBSD machine, and don't have access to a Linux machine at the
moment -- though I'd be happy to re-run the tests when I do. The test suite
completed when I commented out the MULTIPROCESSING subtest from the ASD
file. I don't believe this would have any bearing on whether or not the hash
table tests should pass
Previously, we used the "tombstones" approach for removing entries
from a hash-table, that is buckets were marked as previously occupied
but currently empty. If the hash-table did not grow in size these
tombstones were never cleaned up, only reused for new entries.
For a general purpose hash-table this is a problematic strategy
because there are workloads where this significantly slows down any
attempted lookup or deletion for elements that are not contained in
the hash-table. This happens when new elements are added and deleted
regularly for a long time without the size of the hash-table changing.
Even if the hash-table is never filled above a small fraction of its
size, tombstones will eventually accumulate which an unsuccessfull
search for an element will have to skip over.
In the new implementation, we don't use any tombstones at all but
instead shift elements into more optimal buckets.
In the case where the hash-table in the old approach was free of
tombstones, the new approach is a little slower for the process of
deleting from highly occupied hash-tables itself but inserting into a
hash-table is a little bit faster on the other hand.
The function SORT-APPLICABLE-METHODS accepts as the third argument called
ARGS-SPECIALIZERS however this function assumed that the argument was a list
of argument's classes (i.e not EQL specializers) - see COMPARE-SPECIALIZERS.
This commit doesn't change the function signature but conses a new list that
is ensured to be a list of classes and passes them to COMPARE-METHODS.
(Local) functions COMPARE-METHODS, COMPARE-SPECIALIZERS-LISTS and
COMPARE-SPECIALIZERS have the argument name changed to reflect their true
expectations.
The function COMPARE-SPECIALIZERS takes the CLASS-PRECEDENCE-LIST of the class
of the argument to break ties when there is no direct relationship between
method specializers.
Previously a local function APPLICABLE-METHOD-P returned (values nil nil) when
it found an EQL-specializer where the object was of a matching class. This is
premature because some later specializer may make the method not applicable
based on one of the argument classes, so there is no need to resort to
COMPUTE-APPLICABLE-METHODS in such case.
Previously this function stored a list of elements
(cons list-or-random-atom argument-position)
ARGUMENT-POSITION was preasumbly stored because authors anticipated denoting
unspecialized arguments, however all positions were always filled because
unspecializer argument had non-nil specializer #<BUILTIN-CLASS T>.
LIST-OR-RANDOM-ATOM contained either a list of EQL specializers or a random
specializer from all method specializers. The second value was not clear.
This change simplifies the code and the interface, we additionally maintain
additional information. From now on the list stores elements:
(cons class-specializer-p eql-specializers)
CLASS-SPECIALIZER-P is either NIL or T denoting whether the generic function
has a method specialized on this argument on a class other than T.
EQL-SPECIALIZERS without change, is a list of all EQL specializers.
