s* "-lsome_shared_library")
Note that if you are running an ECL release older than 23.9.9, both
types of linker flags belong in c:*user-ld-flags*, although that
variable is now deprecated because it can lead to linker flags being put
in the wrong position in the linker command line.
Bes
ich contains a very rough early-stage port of the maxima computer
algebra system to a browser environment (in particular the wasm
subdirectory and the src/ecl-port.lisp file are relevant).
Best regards,
Marius Gerbershagen
Am 30.12.23 um 14:39 schrieb Jón Hallur Haraldsson:
Hi,
I've been
Dear Dima,
it is also worth noting that the next release will already bring some
improvements. Maxima's test suite runs about 10% faster on the release
candidate than on the last release.
But I also have to add that in my experience of using sagemath (in
particular the manifolds package) the
Dear James,
This has been fixed now in the develop branch of the git repository.
Thanks for the report!
Best regards,
Marius Gerbershagen
Am 22.03.23 um 16:54 schrieb James Cloos:
making either of the coponents of the first #c() float avoids that bug
but gets a different one:
===
(log #c
m 23:00 schrieb Joshua Armenta:
Thanks, Marius.
So for Intel to M1, we’d need the binaries for M1 and use the byte compiler?
Sent from my iPhone
On Jun 27, 2021, at 11:32, Marius Gerbershagen
wrote:
Dear Joshua,
it is possible to cross-compile lisp code using ECL. Basically, one
needs to set up
https://gitlab.com/eql/EQL5-Android/. You could also look at
https://gitlab.com/spaghettisalat/jffi_repl_example/blob/master/app/src/main/lisp/asdf_libs/compile.lisp
for an example with a basic asdf integration.
Best regards,
Marius Gerbershagen
Am 26.06.21 um 19:43 schrieb Joshua Armenta:
Is there
runtime. I recommend not using ASDF in the final executable/shared
library if avoidable. ASDF is really a built system mostly meant for
development.
Best regards,
Marius Gerbershagen
PS: the API ECL has for converting strings between lisp and C is
definitely lacking. Feel free to open merge requ
For the release candidate testing it is also ok to report the results on
this mailing list.
Best,
Marius
Am 01.01.21 um 12:38 schrieb Juan Jose Garcia-Ripoll:
> Though I do not use ECL so intensively now, I have a couple of VPS and a
> big Windows CPU I could contribute to testing.
>
> I also ha
The generated library does indeed contain all systems that your library
contains on. The undefined references are init functions, which need to
be called via ecl_init_module after cl_boot to initialize the compiled
libraries (see
https://common-lisp.net/project/ecl/static/manual/System-building
Dear Garrett,
the error you get is due to ECL not finding its compiler binary (the
compiler is build as a separate fasl which is loaded on demand). Can you
check whether the file obtained from (translate-logical-pathname
#P"SYS:CMP.NEWEST") exists? What value is the variable
c::*ecl-library-direct
is worth it there.
Am 11.05.20 um 01:06 schrieb Vladimir Sedach:
Marius Gerbershagen writes:
thank you very much for the bug reports and patches. I have
incorporated your changes in the develop branch of the git
repository. If you have any more bug fixes in the future, it would be
preferable
/ecl/
instead of sending patches to the mailing list, since it makes things
easier for us.
Best regards,
Marius Gerbershagen
Am 05.05.20 um 04:46 schrieb Vladimir Sedach:
Ok, I figured out a fix (attached).
write_symbol_string was attempting to use some kind of buffering
similar to
doesn't generate floating point
exceptions. Could you test whether these changes solve the problems you
reported?
Best regards,
Marius Gerbershagen
Am 31.12.19 um 23:10 schrieb Dave Richards:
> The FPU on the Raspberry Pi does not generate CPUexceptions, which
> prevents Linux from genera
check whether you have a
copy of a newer asdf in a place where asdf will search for its systems
and remove that copy. If you really need the new asdf, you need to
generate the asdf.lisp file containing all of asdf from the sources (see
the asdf documentation for how to do that), drop that in place of the
"contrib/asdf/asdf.lisp" file in the ECL sources and recompile ECL.
Best regards,
Marius Gerbershagen
Dear Paul,
unfortunately, I don't have time at the moment to look at this in
detail, however already from the second backtrace of yours I see that
something is missing. Between
frame #4: 0x000100437940 repl`cl_M(narg=1,
num=0x0001) at minus.d:26:23
and
frame #5: 0x00
on active, replacing /MD by /MDd should work).
Best regards,
Marius Gerbershagen
musl/ecl-16.1.3/build/atomic/src'
make[6]: *** [Makefile:460: all] Error 2
This is an error in the libatomic_ops package. Since this package is
widely used, I suggest looking whether OpenWRT already has it available
and whether they have patches. You should also open an issue with the
people de
RAP_SIGPIPE option is meant for programs embedding ECL. If
it is enabled, ECL will install the default SIGPIPE handler, which
currently does nothing.
Best regards,
Marius Gerbershagen
Am 15.02.19 um 18:30 schrieb Gunter Königsmann:
Dear all,
Maxima (which is written in lisp) connects to it
ivision
by zero and invalid operations.
Best regards,
Marius Gerbershagen
Yes, simply call (si::gc).
Am 02.01.19 um 16:20 schrieb Gunter Königsmann:
> Dear all,
>
> Is there any way to manually trigger ECL's garbage collector if I know
> that I have just created many temporary objects that I don't need any more?.
>
> Thanks a lot,
>
> and kind regards,
>
> Gunter
Dear Gunter,
Looking into your problem, I found that this is most certainly an ECL
bug, probably triggered by the definition of the MAXIMA package, which
shadows the array symbol from the COMMON-LISP package.
If you add an
(in-package #:common-lisp)
statement before the
(mk:oos "lapack-inte
Am 01.09.2018 um 04:36 schrieb Faré:
> On Thu, Aug 30, 2018 at 1:46 PM Marius Gerbershagen
> wrote:
>> The test-require.script test fails because it tries to require
>> the :rt module which is deprecated on the develop branch and no longer
>> build by default. A
Harmless in the sense that ECL doesn't crash or throw me in the
interactive debugger. Besides, the test failures seem to be easily
fixed. The test-require.script test fails because it tries to require
the :rt module which is deprecated on the develop branch and no longer
build by default. A simple
compile
anything unless you run `(ext:install-bytecodes-compiler)`. However,
asdf already contains a test target for the bytecodes compiler with
`make test l=ecl_bytecodes` (which will unfortunately fail at the moment
unless you apply the fix at
https://gitlab.com/embeddable-common-lisp/ecl/merge_requests/118).
> Suggestions for debugging would be welcome.
Best regards,
Marius Gerbershagen
ar as i know.
Hope that helps,
Marius Gerbershagen
Am 29.07.2018 um 00:40 schrieb Stewart M.:
To clarify, the issue is not with C++, which I am successfully wrapping
with C.
The actual issue is using the c_object type in Lisp--if it comes back as
a CFFI pointer, how can I use it in Lisp as a Lis
25 matches
Mail list logo
