[release 24.5.10]

[Daniel Kochmański]

Dear All,

We've made a bugfix release that addresses some OSX issues (among other 
things). You may find the announcement here:

https://ecl.common-lisp.dev/posts/ECL-24510-release.html

Best regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: MSVC and C++

[Daniel Kochmański]

Hey Dave,

technically there shouldn't be any issue with the compilation. That
said *I think* that cl.exe picks the compiler mode based on the file
extension, and as you will see in msvc/c/Makefile, dpp compiles .d files to .c.

ECL (as the source code) can run with C++ core and C++ compilers but for 
Windows appropriate Makefile *doesn't seem* to cater to that.

Best regards,
Daniel



--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi



On Friday, April 5th, 2024 at 8:59 PM, d...@synergy.org  
wrote:

> Is it possible to perform C++ builds of ECL on Windows/MSVC?
> Thanks,
> Dave

Re: ASDF: could use some help with ECL issue

[Daniel Kochmański]

Hey Robert,

I've looked into this issue and it seems that it is a bug in ECL. Even on 
idempotent defpackage definitions it first removes use-list and then re-adds 
it, while the different part of the code enforces the lock. I've added the 
ticket to our tracker:

https://gitlab.com/embeddable-common-lisp/ecl/-/issues/730

Best regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

On Tuesday, January 9th, 2024 at 16:48, Robert Goldman  
wrote:

> In the regression test results for a bug fix to ASDF 
> (https://gitlab.common-lisp.net/asdf/asdf/-/jobs/63801), I see this error 
> which I don't understand at all:
>
> Cannot unuse package #<"COMMON-LISP" package> from locked package 
> #<"PACKAGE-INFERRED-SYSTEM-TEST/SBCL-EXT-LOCK" package>.
>
> The line that seems to be causing this is the following (in a test system):
>
> (defpackage package-inferred-system-test/sbcl-ext-lock
>   (:use :cl)
>   #+(or sbcl ecl) (:lock t)
>   (:export #:implemented-by-other-package))
>
> More discussion about this is in ASDF Merge Request 226: 
> https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/226
>
> The underlying issue is to try to make sure that implementation specific 
> defpackage extensions (like :lock) don't cause ASDF's defpackage groveler to 
> fail when working with package-defined systems.
>
> Thanks for any advice!

Re: WASM / Web Assembly ecl in a browser

[Daniel Kochmański]

Hey,

I've only made a puny javascript thing, but it is possible to have a "normal" 
repl. I've been approached by the author of "eclweb" - this person used xterm 
magic to make it more compelling:

https://opensource.chee.party/chee/eclweb

There's also an online repl:

https://repl.chee.party/

I'm not offiliated with them, so I don't know how long the online version will 
persist.

Best regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

On Saturday, December 30th, 2023 at 14:39, Jón Hallur Haraldsson 
 wrote:

> Hi,
>
> I've been toying around with the idea to run ecl in the browser since it is 
> now easy to build it using emscripten.
>
> I have successfully interacted with the runtime using the extremely awkward 
> "window.prompt" native javascript pop up.
>
> My experience in using ECL is in embedding it in C/C++
>
> Has someone successfully used it to run in the browser without using the 
> "wasm-draw-to-canvas" and "windows.prompt" REPL
>
> I'm assuming that this has nothing to do with ECL and is purely how 
> emscripten works.
>
> Can I write a more embedded version which does not require me to interact 
> through the REPL in the browser.
>
> If anyone has done any similar things I'd really like to hear about them.
>
> Kindest regards.
>
> Jon Hallur

[ecl 23.9.9][release]

[Daniel Kochmański]

Dear All,

we are happy to announce the new release: ECL 23.9.9.
You may find details here:
https://ecl.common-lisp.dev/posts/ECL-2399-release.html

Cheers!
Daniel


--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: speeding ECL up

[Daniel Kochmański]

As a side note, and I have not attempted that and that would require further 
investigation, be we could incorporate the concept of sealed domains as 
presented by Marco Heisig in the library fast-generic-functions. We already 
have the concept of sealing classes, but FGF allows to partially seal a generic 
function. That could do wonders for inlining of effective methods specialized 
on system classes.

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi



--- Original Message ---
On Friday, July 14th, 2023 at 2:37 PM, Daniel Kochmański  
wrote:


> Hello Dima,
> 
> some bottlenecks are known and I'm working on these. The worst offenders:
> 
> - the generic function dispatch is slow
> 
> I have implemented the computation part of the fast generic function dispatch 
> as proposed by Robert Strandh, but it needs to be integrated with the C 
> compiler
> 
> - there is no type inference (only the type propagation)
> 
> ECL can go really fast when it knows about its types. I have plans for that, 
> but some extra work needs to be done first
> 
> Both things hang on refactoring the compiler (that task is pending, you may 
> see cmpc-separation branch), so it will be easier to work with the 
> intermediate representation and experiment with backends. There are also 
> other motivations for this refactor.
> 
> There is also the fact that ECL /compilation/ time is very slow. Currently 
> there is not much we can do about this, because most of the time is spend in 
> GCC (so nothing to optimize for us).
> 
> Another problem is FASL loading - when ECL loads a fasl then it replays 
> necessary side-effects and that is time consuming (you may notice this for 
> example when you REQUIRE ASDF). This is not much of the problem in itself, 
> but said side-effects need to be replayed even when we build an executable, 
> so the startup suffers. Other implementations hide that startup time by 
> dumping images, where all side effects are already present.
> 
> Also, if you are not using the C compiler (i.e only the bytecode), then the 
> result is not optimized at all - the bytecodes compiler performs only the 
> minimal compilation.
> 
> All that said, when both fast gf and type inference are implemented, I will 
> try to identify further bottlenecks if things still doesn't look good.
> 
> None of these possible improvements will be part of the upcoming release. We 
> are currently in the testing phase (not thanks to me, I'm disappointingly not 
> very active on this front at the moment - sorry Marius!).
> 
> Here are a few hints that will help you to produce better optimized code:
> - avoid generic functions
> - declare types wherever feasible
> - lower safety to 1, raise speed to 3 (don't use safety 0, there are known 
> bugs)
> 
> There are also more mundane ways to improve the performance:
> - inline partial dispatch tables for arithmetic operators
> - work harder on IR to optimize it (using SSA and adding more passes is 
> pending™)
> 
> Best regards,
> Daniel
> 
> p.s we should also introduce more immediate types on 64bit platforms - we are 
> currently using only two available bits for tagging while we could use three, 
> but I'm not working on that at the moment - single-float could be unboxed in 
> that case
> 
> --
> Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
> TurtleWare - Daniel Kochmański | www.turtleware.eu
> 
> "Be the change that you wish to see in the world." - Mahatma Gandhi
> 
> 
> 
> --- Original Message ---
> On Friday, July 14th, 2023 at 2:19 PM, Dima Pasechnik dimpase+...@gmail.com 
> wrote:
> 
> 
> 
> > It's well-known that ECL-compiled CL projects are considerably slower
> > than ones where SBCL is used. Examples are e.g. Maxima, FriCAS - there
> > speed might be few times (sic!) slower.
> > 
> > Is there an effort to find out bottlenecks, or is it known where these
> > bottlenecks are?
> > 
> > Best,
> > Dima

Re: speeding ECL up

[Daniel Kochmański]

Hello Dima,

some bottlenecks are known and I'm working on these. The worst offenders:

- the generic function dispatch is slow

  I have implemented the computation part of the fast generic function dispatch 
as proposed by Robert Strandh, but it needs to be integrated with the C compiler

- there is no type inference (only the type propagation)

  ECL can go really fast when it knows about its types. I have plans for that, 
but some extra work needs to be done first

Both things hang on refactoring the compiler (that task is pending, you may see 
cmpc-separation branch), so it will be easier to work with the intermediate 
representation and experiment with backends. There are also other motivations 
for this refactor.

There is also the fact that ECL /compilation/ time is very slow. Currently 
there is not much we can do about this, because most of the time is spend in 
GCC (so nothing to optimize for us).

Another problem is FASL loading - when ECL loads a fasl then it replays 
necessary side-effects and that is time consuming (you may notice this for 
example when you REQUIRE ASDF). This is not much of the problem in itself, but 
said side-effects need to be replayed even when we build an executable, so the 
startup suffers. Other implementations hide that startup time by dumping 
images, where all side effects are already present.

Also, if you are not using the C compiler (i.e only the bytecode), then the 
result is not optimized at all - the bytecodes compiler performs only the 
minimal compilation.

All that said, when both fast gf and type inference are implemented, I will try 
to identify further bottlenecks if things still doesn't look good.

None of these possible improvements will be part of the upcoming release. We 
are currently in the testing phase (not thanks to me, I'm disappointingly not 
very active on this front at the moment - sorry Marius!).

Here are a few hints that will help you to produce better optimized code:
- avoid generic functions
- declare types wherever feasible
- lower safety to 1, raise speed to 3 (don't use safety 0, there are known bugs)

There are also more mundane ways to improve the performance:
- inline partial dispatch tables for arithmetic operators
- work harder on IR to optimize it (using SSA and adding more passes is 
pending™)

Best regards,
Daniel

p.s we should also introduce more immediate types on 64bit platforms - we are 
currently using only two available bits for tagging while we could use three, 
but I'm not working on that at the moment - single-float could be unboxed in 
that case

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi



--- Original Message ---
On Friday, July 14th, 2023 at 2:19 PM, Dima Pasechnik  
wrote:


> It's well-known that ECL-compiled CL projects are considerably slower
> than ones where SBCL is used. Examples are e.g. Maxima, FriCAS - there
> speed might be few times (sic!) slower.
> 
> Is there an effort to find out bottlenecks, or is it known where these
> bottlenecks are?
> 
> Best,
> Dima

Re: Example in ECL repository for static link

[Daniel Kochmański]

Hey Thomas,



--- Original Message ---
On Monday, June 19th, 2023 at 5:34 PM, Thomas Teixeira 
 wrote:


> Hi !
> Thanks for ECL, I've been learning CL for the past weeks and it's my favorite
> implementation so far ! Would love to contribute one I've the required skills
> :))

That sounds great :)

> 
> I'm trying to create a small script that'll allow users to recreate a mail
> thread inside a virtual maildir box. I would like to use ECL for that script 
> but
> the project which this script will belong to ([fruitslegumes][1]) is focused 
> on
> using no dependencies.

Does libc count as a dependency? Currently ECL links dynamically against libc 
even
for static builds. There are no technical reasons why it couldn't link 
statically
against libc (and we want to allow that), but currently flags in multiple places
simply assume a dynamic link.

> 
> Because of this constraint, I only ever used POSIX-shell/C99 to build those
> scripts
> I would love to use ECL as programs can be compiled down to machine code, 
> which
> can be `upx`-ed, but users would have to install their ecl package.
> 
> I managed to statically link libecl with a simple script, but it gets harder 
> for
> me when trying with the example-with-dep program.
> I saw in a previous thread of this mailing list that statically linking ECL
> makes asdf unusable. Is that still the case ?

It is not that ASDF is unusable when we link statically. There are a few 
ramifications
though. I'll elaborate a little here about FASL files in ECL:

> Would it be possible to either provide an example (if what i'm asking is even
> possible) or talk in more depth about ecl being statically linked ?

The fasl file created by ECL is a shared object that is linked dynamically 
against
libecl.so. If it were a static object, then each and every fasl would need to 
carry
whole ECL runtime statically linked. That's not a sound solution.

Now, regarding using ASDF in static builds. When the C compiler is not installed
(either not build with ECL, or (ext:install-bytecodes-compiler) was called), 
then
files compiled by ECL are in FASC format, that is the bytecode. Such bytecode 
may
be loaded with statically linked ECL. ASDF should work fine with FASC files, 
although
some libraries may assume the C compiler, so not all software will work with it.

If you want to have ASDF statically linked in the resulting binary, you need to 
specify
that when building ECL. For example ./configure --disable-shared 
--with-asdf=builtin .

There's also that you may compile your lisp source code along with ECL and 
statically
link it (that would be somewhat similar to the example with deps), although 
there is
no explicit support for ASDF. To specify files that should be compiled and 
linked with
ECL you may specify the flag --with-extra-files.

As you can see, static linking is somewhere in the ballpark of what ECL can do, 
but
it is not well supported. I'm working on some compiler improvements to allow 
easier
cross compilation and other similar things and hope that during that work I'll 
also
improve the support for static builds (although that is not the main focus).

I hope that this explanation is at least partly satisfactory.

> 
> Regards,
> Thomas.

Best regards,
Daniel


--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Building ECL as a static library

[Daniel Kochmański]

Hello,

Thanks for raising this question. It is a feature that was requested a few 
times already. ECL works when cross-compiled, but you need to compile it 
against the target's libc.

Currently ECL always (even when statically linked) links dynamically against 
the target libc (if you've ever seen an error for executables that glibc is not 
compatible - that's this sort of issue).

In the future (but not in the imminent release) I want to add the possibility 
to link with libc statically (i.e musl), so the executable may be moved between 
machines with incompatible libc libraries.

Best regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

[release candidate][23.x.x]

[Daniel Kochmański]

Dear All,

we've decided that it is a good time to go for the new release. The current 
release candidate is in the develop branch, testing is tracked in this issue:

https://gitlab.com/embeddable-common-lisp/ecl/-/issues/706

All help with testing is greatly appreciated.

Best regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Differences Between ECL Executable and Embedded ECL

[Daniel Kochmański]

It seems that for mingw we do some unholy mashup between posix and window 
-specific options, that is we do a flat structure instead of a tree 
(/usr/loca/bin etc). In that case you are expected to ship all your modules in 
the same directory as the application (quite like with dll files when they are 
shipped with a program).

Regarding shipping particular modules with ECL
./configure --with-asdf=builtin --with-tcp-sockets=builtin
should do the trick.

Best regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

--- Original Message ---
On Thursday, March 23rd, 2023 at 12:11 PM, Binh Nguyen  
wrote:

> Hi Daniel,
>
> ＿|￣|○
>
> Thank you for your reply!
>
> Yep, I passed "--prefix=/usr/local/" to configure and then performed make 
> install afterwards, as per the notes on Autoconf based configurations.
> (https://ecl.common-lisp.dev/static/manual/Building-ECL.html#Building-ECL)
>
> I agree, I think there is something funny going on with my pathnames.
>
> I compared the features variable and the list of packages in the ECL 
> executable and my program and they were the same. So I had a hunch there 
> something external was different. So I copied my executable to "/usr/local" 
> to be with "ecl.exe", and I was able to call (require 'asdf).
>
>> $ /usr/local/a.exe
>
>> ...
>
>>> (require 'asdf)
>
>>
>
>> ;;; Loading #P"C:/msys64/usr/local/asdf.fas"
>
>> ("ASDF" "asdf" "UIOP" "uiop")
>
> When I my executable from my home directory, I was not able to call (require 
> 'asdf).
>
>>> (require 'asdf)
>
>>
>
>> Debugger received error of type: SIMPLE-ERROR
>
>> Module error: Don't know how to REQUIRE ASDF.
>
>> Error flushed.
>
> I tried loading ASDF with the directory but I got the following error.
>
>>> (load #P"C:/msys64/usr/local/asdf.fas")
>
>>
>
>> ;;; Loading "C:/msys64/usr/local/asdf.fas"Debugger received error of type: 
>> FILE-ERRORFilesystem error with pathname "SYS:help.doc".Either 1) the file 
>> does not exist, or 2) we are not allowed to access the file, or 3) the 
>> pathname points to a broken symbolic link.Error flushed.
>
> So I copied "/usr/local/help.doc" to my home directory and then I was able to 
> load ASDF.
>
>>> (load #P"C:/msys64/usr/local/asdf.fas")
>
>>
>
>> #P"C:/msys64/usr/local/asdf.fas"
>
> After that, I was able to load SOCKETS ad Quicklisp.
>
> I don't know how to specify that ASDF and SOCKETS are builtin but I'll look 
> into it.
>
> Thank you for your help and thank you for all your work on ECL.
>
> Best regards,
>
> Binh Nguyen
>
> On Thu, 23 Mar 2023 at 20:20, Daniel Kochmański  wrote:
>
>> Hey Binh,
>>
>> it is not that the function REQUIRE is not available, it is that it doesn't 
>> know /where/ to look for sockets.fas. I see that you have unix pathnames, so 
>> ecl should not expect the flat structure. Did you pass 
>> "--prefix=/usr/local/" to configure (or something in this spirit)? If so, 
>> did you perform make install afterwards? If so, then require should be able 
>> to find sockets.fas in /usr/local/lib/ecl/... , and if not - it can't find 
>> it. The same applies to the module "ASDF", so I think that having 
>> installation with known pathnames should fix all your issues on that front.
>>
>> Alternatively you may specify that ASDF and SOCKETS are builtin (see 
>> ./configure --help for details).
>>
>> As the last resort, if you want to push in the same direction you've already 
>> started - load ASDF.fas the same way you've loaded SOCKETS.fas (it should be 
>> in the same directory) - that will ensure ASDF 3.1.8.
>>
>> Best regards,
>> Daniel
>>
>> --
>> Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
>> TurtleWare - Daniel Kochmański | www.turtleware.eu
>>
>> "Be the change that you wish to see in the world." - Mahatma Gandhi
>>
>> --- Original Message ---
>> On Wednesday, March 22nd, 2023 at 1:55 PM, Binh Nguyen 
>>  wrote:
>>
>>> Dear ECL Community,
>>>
>>> Could you let me know how to do the following, please?
>>>
>>> - How to load file "quicklisp.lisp" in an embedded instance of ECL
>>> - How to make the function REQUIRE available in an embedded instance of ECL
>>>

Re: Differences Between ECL Executable and Embedded ECL

[Daniel Kochmański]

Hey Binh,

it is not that the function REQUIRE is not available, it is that it doesn't 
know /where/ to look for sockets.fas. I see that you have unix pathnames, so 
ecl should not expect the flat structure. Did you pass "--prefix=/usr/local/" 
to configure (or something in this spirit)? If so, did you perform make install 
afterwards? If so, then require should be able to find sockets.fas in 
/usr/local/lib/ecl/... , and if not - it can't find it. The same applies to the 
module "ASDF", so I think that having installation with known pathnames should 
fix all your issues on that front.

Alternatively you may specify that ASDF and SOCKETS are builtin (see 
./configure --help for details).

As the last resort, if you want to push in the same direction you've already 
started - load ASDF.fas the same way you've loaded SOCKETS.fas (it should be in 
the same directory) - that will ensure ASDF 3.1.8.

Best regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

--- Original Message ---
On Wednesday, March 22nd, 2023 at 1:55 PM, Binh Nguyen  
wrote:

> Dear ECL Community,
>
> Could you let me know how to do the following, please?
>
> - How to load file "quicklisp.lisp" in an embedded instance of ECL
> - How to make the function REQUIRE available in an embedded instance of ECL
> - How to load ASDF 3 or newer in an embedded instance of ECL
>
> I am able to load file "quicklisp.lisp" when I run "/usr/local/ecl.exe".
>
> I saw that there is an "ecl-quicklisp.lisp" but I'd like to learn how to load 
> non-ECL Quicklisp.
>
> I am running ECL 21.2.1. that I compiled with MSYS MinGW x86.
>
> The first error that comes up is that the function REQUIRE is not available.
>
>>> (load "quicklisp.lisp")
>
>>
>
>> ;;; Loading "C:/msys64/home/Admin/quicklisp.lisp"
>
>> Debugger received error of type: SIMPLE-ERROR
>
>> Module error: Don't know how to REQUIRE SOCKETS.
>
>> Error flushed.
>
> So I manually loaded SOCKETS.
>
>>> (load #P"C:/msys64/usr/local/sockets.fas")
>
>>
>
>> ;;; Loading "C:/msys64/usr/local/sockets.fas"
>
>> #P"C:/msys64/usr/local/sockets.fas"
>
> Then I tried again and I was able to progress further.
>
>>> (load "quicklisp.lisp")
>
>>
>
>> ;;; Loading "C:/msys64/home/Admin/quicklisp.lisp"
>
>>
>
>>  quicklisp quickstart 2015-01-28 loaded 
>
>>
>
>> To continue with installation, evaluate: (quicklisp-quickstart:install)
>
>>
>
>> For installation options, evaluate: (quicklisp-quickstart:help)
>
>>
>
>> #P"C:/msys64/home/Admin/quicklisp.lisp"
>
>>> (quicklisp-quickstart:install)
>
>>
>
>> Debugger received error of type: SIMPLE-ERROR
>
>> Quicklisp has already been installed. Load 
>> #P"C:/msys64/home/Admin/quicklisp/setup.lisp" instead.
>
>> Error flushed.
>
> Bu the following error appeared that I don't know how to solve.
>
>>> (load #P"C:/msys64/home/Admin/quicklisp/setup.lisp")
>
>>
>
>> ;;; Loading "C:/msys64/home/Admin/quicklisp/setup.lisp"
>
>> Debugger received error of type: SIMPLE-ERROR
>
>> Could not load ASDF "3.0" or newer
>
>> Error flushed.
>
> I tried loading the other ".fas" files in "/usr/local" such as "asdf.fas" but 
> that did not help.
>
> I checked the *features* variable in both versions but they were the same.
>
>> $ ./a.exe
>
>> ...
>
>> Condition of type: INTERACTIVE-INTERRUPT
>
>> Console interrupt.
>
>> Available restarts:
>
>>
>
>> 1. (CONTINUE) CONTINUE
>
>> ...
>
>>> (print-list *features*)
>> (WALKER ECL-BYTECMP CDR-1 CDR-5 FORMATTER CDR-7 WSOCK ECL-WEAK-HASH 
>> LITTLE-ENDIAN LONG-LONG UINT64-T UINT32-T UINT16-T COMPLEX-FLOAT LONG-FLOAT 
>> UNICODE DFFI CLOS-STREAMS CMU-FORMAT WINDOWS WIN32 MINGW32 ECL-PDE DLOPEN 
>> CLOS THREADS BOEHM-GC ANSI-CL COMMON-LISP IEEE-FLOATING-POINT 
>> PACKAGE-LOCAL-NICKNAMES CDR-14 PREFIXED-API FFI I686 COMMON ECL)
>
>> $ /usr/local/ecl.exe
>> ...> (print-list *features*)
>> (WALKER ECL-BYTECMP CDR-1 CDR-5 FORMATTER CDR-7 WSOCK ECL-WEAK-HASH 
>> LITTLE-ENDIAN LONG-LONG UINT64-T UINT32-T UINT16-T COMPLEX-FLOAT LONG-FLOAT 
>> UNICODE DFFI CLOS-STREAMS CMU-FORMAT WINDOWS WIN32 MINGW32 ECL-PDE DLOPEN 
>> CLOS THREADS BOEHM-GC ANSI-CL COMMON-LISP IEEE-FLOATING-POINT 
>> PACKAGE-LOCAL-NICKNAMES CDR-14 PREFIXED-API FFI I686 COMMON ECL)
>
> Best regards,
>
> Binh Nguyen

Re: Compiling a binary that uses quicklisp

[Daniel Kochmański]

I think that you should not call quickload in the package file. ASDF should 
solve depenencies based on a sole (ql:quickload 'cl-i3).

I've tried to reproduce your issue and I've succeeded. After quick 
investigation it seems that the system cl-str expects that its
source code will be available to asdf at any time (even after the compilation). 
The offensive line is this:

cl-str-20221106-git/str.lisp:144:(defvar +version+ (asdf:component-version 
(asdf:find-system "str")))

Basically it is as if you were expecting that both make and linux source code 
are both available at startup.

If you replace this line to maintain some reasonable sanity it will look like 
this:
(defvar +version+ #.(asdf:component-version (asdf:find-system "str")))

Another issue with this system is that it does not declare dependencies on 
"uiop" and "asdf" despite using both. str.asd
should have

:depends-on (:cl-ppcre
:cl-ppcre-unicode
:cl-change-case
"asdf" "uiop")

note the last two lines. With that the following builds and runs without a 
hitch:

brandon.asd:
(in-package #:asdf-user)
(asdf:defsystem "brandon"
:name "brandon"
:depends-on ("str") :components ((:file "main")))

main.lisp:
(defpackage #:brandon
(:use #:cl))
(in-package #:brandon)

(defun main (str)
(format t "Hello ~a!~%" str))

build.lisp (not part of the system):
(in-package #:cl-user)

;;; Make the system recognizable by ASDF
(asdf:load-asd "brandon.asd")

;;; Pull dependencies and load macros
(asdf:load-system "brandon")

;;; Build the program (shared object)
(asdf:make-build "brandon" :type :program
:move-here "./brandon.out")

(asdf:make-build "brandon" :type :program
:monolithic t
:move-here ".")



note that if you don't want repl then probably you want to add (progn (main 
"HI") (ext:quit)) in the epilogue code.

Best regards,
Daniel

p.s if you feel like it you may make issues in cl-str repository bugtracker.

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

--- Original Message ---
On Friday, February 10th, 2023 at 20:02, Brandon Hale 
 wrote:

> Maybe I should get my project up in a repo, but it looks like I have the 
> dependency listed. Here is my package's .asd named cl-i3.asd:
>
> (asdf:defsystem #:cl-i3
>
> :name "cl-i3"
>
> :description "A replacement for i3status written in Common Lisp."
>
> :author "Brandon Hale
> [](mailto:bthaleproducti...@gmail.com)
> "
>
> :license "GPLv3"
>
> :version "1.0"
>
> :depends-on (#:cl-ansi-text #:trivial-battery #:str)
>
> :components ((:file "main")))
>
> And the top portion of my main.lisp:
>
> (ql:quickload :trivial-battery)
>
> (ql:quickload :str)
>
> ;; allows for colors to be printed
>
> (ql:quickload :cl-ansi-text)
>
> (defpackage :cl-i3
>
> (:use #:common-lisp))
>
> I am definitely not an expert on Common Lisp packages, but this does load up 
> in slime on my machine when I do a
>
> (ql:quickload :cl-i3)
>
> with ecl 21.2.1-3 from Arch Linux.
>
> I need to look at the well-commented example again to see what I'm doing 
> wrong methinks.
>
> Brandon Hale
>
> On 2/10/23 01:07, Daniel Kochmański wrote:
>
>> Hello Brandon,
>>
>> --- Original Message ---
>> On Friday, February 10th, 2023 at 00:20, Brandon Hale
>> [](mailto:bthaleproducti...@gmail.com)
>> wrote:
>>
>>> Hello all,
>>>
>>> I apologize if this is either the wrong place to get help with ecl, or if 
>>> this is asked all of the time.
>>
>> this is the right place, don't worry :)
>>
>>> I've written a small replacement for i3status with common lisp and want to 
>>> use ecl to make a binary so when i3wm loads, it just loads the cl-i3status 
>>> binary. I've looked at the ecl documentation online and it suggests doing 
>>> something like this:
>>>
>>> (ql:quickload :cl-i3)
>>>
>>> (asdf:make-build :cl-i3
>>>
>>>  :type :program
>>>
>>>  :move-here #P"/home/brandon/Programming/lisp/cl-i3/"
>>>
>>>  :prologue-code '(require 'asdf))
>>>
>>> So, I run this and the binary appears. However, when I try to run it, I get 
>>> this output:
>>>
>>> ;;; Loading #P"/usr/lib/ecl-21.2.1/asdf.fas"
>>> ;;; Computing Hangul syllable names
>>> Condition of type: MISSING-COMPONENT
>>

Re: Compiling a binary that uses quicklisp

[Daniel Kochmański]

Hello Brandon,


--- Original Message ---
On Friday, February 10th, 2023 at 00:20, Brandon Hale 
 wrote:


> Hello all,
> 
> I apologize if this is either the wrong place to get help with ecl, or if 
> this is asked all of the time. 

this is the right place, don't worry :)


> I've written a small replacement for i3status with common lisp and want to 
> use ecl to make a binary so when i3wm loads, it just loads the cl-i3status 
> binary. I've looked at the ecl documentation online and it suggests doing 
> something like this:
> 
> (ql:quickload :cl-i3)
> 
> (asdf:make-build :cl-i3
> 
>  :type :program
> 
>  :move-here #P"/home/brandon/Programming/lisp/cl-i3/"
> 
>  :prologue-code '(require 'asdf))
> 
> So, I run this and the binary appears. However, when I try to run it, I get 
> this output:
> 
> ;;; Loading #P"/usr/lib/ecl-21.2.1/asdf.fas"
> ;;; Computing Hangul syllable names
> Condition of type: MISSING-COMPONENT
> Component "str" not found
> 
> Available restarts:
> 
> 1. (RETRY) Retry ASDF operation.
> 2. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the 
> configuration.
> 
> Top level in: #.
> >
> 
> I imagine it is just because of my use of quicklisp packages, but how do I 
> compile the packages into the binary?

this error message seems to suggest that you use a system "str" without 
declaring it in dependencies. In your
project file my-project.asd add

(defsystem "my-project"
  ...
  :depends-on (... "str")
  ...)

depending on what you want from your project you may not need (require 'asdf) 
in the prologue code. Also you
may consider passing :monolithic t flag to make-build.

Make sure that you study well-commented example in ecl source repository under 
examples/asdf_with_dependence/.

Last but not least make sure that you use the latest release (currently it is 
21.2.1) or a build from the branch
"develop" if you are not afraid of cutting your self on the bleeding edge ;).

If none of these advises helps then please try to minimize the test case to the 
minimum (basically an asd system
with a singly stub file and all dependencies you need) and make an issue ticket 
on gitlab

https://gitlab.com/embeddable-common-lisp/ecl/-/issues

mind that such action requires registration on the gitlab platform.

> 
> Thank you very much for any help you can offer,
> 
> Brandon Hale

Best regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: bug in (log)

[Daniel Kochmański]

Hey,

sorry for taking my time with the response. While indeed conforming, I've added 
a separate code path for ratios. I'm conditioning on the integer length (like 
SBCL does).

static cl_object
ecl_log1_ratio(cl_object x)
{
  cl_object num = x->ratio.num;
  cl_object den = x->ratio.den;
  if (ecl_integer_length(num) != ecl_integer_length(den)) {
return ecl_minus(ecl_log1(num), ecl_log1(den));
  } else {
return ecl_log1_fixnum(x);
  }
}

Thanks all for the input. The change is now submitted as a merge request 
against develop (and will be part of the next release).

Best regards,
Daniel



--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi



--- Original Message ---
On Sunday, July 10th, 2022 at 5:39 PM, James Cloos  wrote:


> i should have realized this even before noticing ecl's limitation for
> logs of ratios, but at least i finally did
> 
> since i'monly using log to find the exponent for an arbitrary precision
> replacement for format's ~e, it works to truncate first.
> 
> so i ended up with this:
> 
> (defun ilog (n  (base nil base-p))
> "return floor of base b log of n"
> (let ((s (if (< n 1) -1 1))
> (trunc-n (truncate (if (< n 1) (/ n) n
> (floor (* s (if base-p
> (log trunc-n base)
> (log trunc-n))
> 
> 
> One could use let* and then test s when choosing between n and (/ n), but
> i choose instead to let the compiler optimize the two calls to (< n 1).
> 
> that makes my ~e replacement work exactly as desired on all lisps i've tried.
> 
> (I have a ~// function which chooses output baed on the arg's type, with
> ratios done via that print-e-significant-digits function and everything
> else using write.)
> 
> -JimC
> --
> James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
> 
>

Re: manual typo

[Daniel Kochmański]

Hey James,

thank you, you are right. I've corrected this in the repository
- the change will be propagated to the manual after the release.

Best regards (and Merry Christmas),
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

‐‐‐ Original Message ‐‐‐

On Monday, December 20th, 2021 at 9:37 PM, James Cloos  
wrote:

> James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6

Re: Dependency issue with program-op

[Daniel Kochmański]

Ecl does not dump the image - in other words the compilation environment is not 
part of the final executable. If the setup system is not a dependency of a 
"dumped" system, still its package is referenced from the latter, then this 
will happen. If the setup is indirect dependency of a dumped system, then it is 
most likely asdf bug, otherwise it is an expected behavior.

If you do not reference setup system package from a dumped system, then 
something fishy is going on, i.e system definition files are included in 
program op for some reason.

Regards, Daniel

Wysłano z aplikacji ProtonMail

 Oryginalna wiadomość 
‎ 21 mar 2021, 18:33, Didier Verna napisał(a):

> Hello,
>
> I'm cross-posting because I don't know if the issue is related to ASDF
> or ECL. I'm using the most recent repos of both.
>
> When dumping a very simple system defined like this:
>
> (asdf:defsystem :simple
> :depends-on (:net.didierverna.clon)
> :components ((:file "simple"))
> :entry-point "simple:main")
>
> with (asdf:operate 'asdf:program-op :simple),
>
> I'm getting a runtime error with the executable:
> Condition of type: SIMPLE-PACKAGE-ERROR
> There exists no package with name "NET.DIDIERVERNA.CLON.SETUP"
> No restarts available.
>
> Top level in: #.
>
> So it seems that the net.didierverna.clon.setup system is not dumped in
> the executable.
>
> In Clon, the dependency on setup is indirect:
> net.didierverna.clon <- net.didierverna.clon.core
> net.didierverna.clon.core <- net.didierverna.clon.setup
>
> If I add an explicit dependency on setup in the :simple ASDF system
> above like this:
>
> :depends-on (:net.didierverna.clon.setup :net.didierverna.clon))
>
> the problem goes away. This doesn't happen with the 5 other Lisp
> implementations that I've tested.
>
> Also, it may be worth mentioning that Clon's setup system gets a special
> treatment. It's loaded explicitly at the top of several .asd files like
> this (with the utmost disrespect for the Almighty ASDF Gods
> recommendations):
>
> (asdf:load-system :net.didierverna.clon.setup)
>
> I'm wondering if this may have something to do with the problem.
>
> Thanks!
>
> --
> ¡En Seguida! -- New album: https://www.didierverna.com/records/en-seguida.php
> Available on all digital platforms now!
>
> Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: Where to go with EQL5 and QT specific questions?

[Daniel Kochmański]

Hey,

‐‐‐ Original Message ‐‐‐
On Monday, March 1, 2021 1:54 PM, Renaud Casenave-Péré 
 wrote:

> I am also a bit concerned about asking end-users to add an
> unrelated repository to be able to install your applications and
> I was wondering if there is a possibility to statically link
> against libecl and libeql5. That way applications could be truly
> standalone and maybe even acceptable for the jolla shop.

when you specify --disable-shared during configuration, then ecl will be 
compiled statically
(one of the artifacts will be named libecl.a). This solution has a drawback, 
because you won't
be able to load .fas files at runtime (but .fasc are fine). In the future, it 
would be nice to
separate these two things with different flags.

Best regards,
Daniel

[release][21.2.21]

[Daniel Kochmański]

Dear Community,

we are happy to announce a new release of ECL.

https://common-lisp.net/project/ecl/posts/ECL-2121-release.html

Best regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: [EQL5] Slow startup

[Daniel Kochmański]

Make sure you have uiop (a library) in your local projects or another registry 
- otherwise asdf won't add it to the bundle because it is 'preloaded' - and ql 
won't download it - ditto.

Daniel

Wysłano z aplikacji ProtonMail

 Oryginalna wiadomość 
‎ 13 sty 2021, 08:39, pls.153 napisał(a):

> ‐‐‐ Original Message ‐‐‐
> On Tuesday, January 12, 2021 1:30 PM, Erik Winkels  wrote:
>> I've alleviated my slow startup somewhat by
>>
>> diff --git a/make.lisp b/make.lisp
>> index 41d4e3d..52b05b6 100644
>> --- a/make.lisp
>> +++ b/make.lisp
>> @@ -13,7 +13,8 @@
>> (asdf:make-build "app"
>> :monolithic t
>> :type :static-library
>> - :prologue-code '(require :ecl-quicklisp)
>> + :prologue-code '(progn (require :sb-bsd-sockets)
>> + (require :asdf))
>> :move-here "./"
>> :init-name "init_lib_APP__ALL_SYSTEMS")
>
> ok, so I just tried to build a dummy app on the desktop (problem is the same 
> there) with the dependencies listed in your ASDF definitions.
> I added :uiop as an additional dependency (both in *.asd and 
> 'dependencies.lisp'), but this still didn't work without adding :asdf.
>
> But after the following hack (in 'make.lisp') I was able to run the app 
> without startup errors:
>
> :prologue-code '(progn
> (require :sb-bsd-sockets)
> (defpackage uiop/os)
> (defpackage uiop/pathname)
> (defpackage uiop/filesystem)
> (defpackage asdf/operate)
> (defpackage asdf/lisp-action)
> ;;(require :asdf)
> )
>
> As you can see, creating some dummy packages and excluding ASDF worked (of 
> course you need to test if your app still works this way).
>
> Paul

[release candidate][testing]

[Daniel Kochmański]

Hey,

we've started tests before the next release if you have time and
resources to help, then the issue is here:

https://gitlab.com/embeddable-common-lisp/ecl/-/issues/621

Best regards,
Daniel


--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Where to go with EQL5 and QT specific questions?

[Daniel Kochmański]

This list is also fine.

Best regards,
DK

 Oryginalna wiadomość 
‎ 9 gru 2020, 09:17, PR napisał(a):

> On 12/6/20, Erik Winkels  wrote:
>> I know little of QT however and looking at the EQL5 examples only gets
>> me so far. What would be a good venue to ask my (initially really
>> basic) questions on the combination of ECL, EQL and QT? I mean, I want
>> to ask questions to people who also like to program in Common Lisp so I
>> don't have to have a discussion thread first on why I am not using C++
>> or Python.
>
> There is now a web logged #eql5 IRC channel, that would be the perfect place.
> The (searchable) logs can be found here:
>
> https://irclog.tymoon.eu/freenode/%23eql5
>
> For now it's empty, you're welcome to fill it with some content :)
> And for people not running an IRC client all day long, there are also
> web clients, like this one:
>
> https://webchat.freenode.net/
>
> Paul

Re: Monolithic build of static library

[Daniel Kochmański]

Do you have the source code of uiop available in the central registry? 
Quicklisp won't
download it, because asdf considers it being preloaded. Also, if so, do you 
have uiop
listed as a dependency?

Alternatively you may add asdf as a dependency to your system.

Regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

‐‐‐ Original Message ‐‐‐
On Tuesday, 1 December 2020 22:01, Иван Трусков  wrote:

> Thank you very much. After rebuilding with newer version of ecl and with 
> :init-name supplied compilation was a success.
>
> However, when i try to run the resulting executable, i get this error:
>
> Condition of type: SIMPLE-ERROR
> Package ((UIOP/STREAM . #)) referenced in compiled file
> NIL
> but has not been created
>
> Available restarts:
>
> 1. (IGNORE) Ignore the error, and try the operation again
>
> What should be done in this situation and how can i avoid it? Searching 
> internet with this message did not yield any meaningful results (except for 
> one Stackoverflow post that tells about having the same mistake).
>
> вт, 1 дек. 2020 г. в 22:15, Marius Gerbershagen 
> :
>
>> 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.html#Build-it-as-shared-library-and-use-in-C
>> for more details).
>>
>> Since you didn't specify an explicit init name yourself, init functions
>> are automatically generated for each system contained in the final
>> library. When compiling a monolithic library, it is preferable to
>> specify an explicit init name yourself, for example as
>>
>> (asdf:make-build :embedded-console :type :static-library :move-here
>> #P"/my/output/dir" :monolithic t :init-name "init_lib_embedded_console")
>>
>> and then invoke it using
>>
>> extern void init_lib_embedded_console(cl_object);
>> /* ... */
>> cl_boot(argc, argv);
>> ecl_init_module(NULL, init_lib_embedded_console);
>>
>> Am 29.11.20 um 13:17 schrieb Иван Трусков:
>>> Hello. I am trying to make a library that makes use of 'STR' package and
>>> link it into my C program.
>>> I presumed that using :monolithic t flag would result in the static
>>> library that contained all systems my library depends on. However it
>>> seems that is not the case.
>>>
>>> Here is my .asd file:
>>>
>>> (defsystem "embedded-console"
>>> :description "embedded console - ECL functions for smart snake game"
>>> :author "Ivan Truskov mailto:tru...@gmail.com>>"
>>> :components ((:file "embedded-console"))
>>> :depends-on ("str"))
>>>
>>> I am compiling the library with command:
>>>
>>> ecl -norc -eval '(require :ecl-quicklisp)'
>>> -eval '(push \"/my/src/dir/\" asdf:*central-registry*)'
>>> -eval '(asdf:make-build :embedded-console :type
>>> :static-library :move-here \#P\"/my/output/dir}\" :monolithic t )'
>>> -eval '(quit)'
>>>
>>> However, when i try to link with resulting library, this is what i get:
>>>
>>> ... undefined reference to `init_lib_CL_PPCRE'
>>> ... undefined reference to `init_lib_BASE'
>>> ... undefined reference to `init_lib_CL_UNICODE'
>>> ... undefined reference to `init_lib_CL_PPCRE_UNICODE'
>>> ... undefined reference to `init_lib_CL_CHANGE_CASE'
>>> ... undefined reference to `init_lib_STR'
>>> ... undefined reference to `init_lib_EMBEDDED_CONSOLE'
>>>
>>> And indeed, when i run nm over the built file
>>> embedded-console--all-systems.a, this is output:
>>>
>>> eclinitVtJU9J.o:
>>>  b Cblock.10857
>>> U cl_boot
>>> U cl_symbols
>>> U _ecl_frs_push
>>> U ecl_init_module
>>> U ecl_make_codeblock
>>> U ecl_process_env
>>> U _GLOBAL_OFFSET_TABLE_
>>> U init_lib_BASE
>>> U init_lib_CL_CHANGE_CASE
>>> U init_lib_CL_PPCRE
>>> U init_lib_CL_PPCRE_UNICODE
>>> U init_lib_CL_UNICODE
>>> U init_lib_EMBEDDED_CONSOLE
>>>  T init_lib_EMBEDDED_CONSOLE__ALL_SYSTEMS
>>> U init_lib_STR
>>> 0110 T main_lib_EMBEDDED_CONSOLE__ALL_SYSTEMS
>>> U _setjmp
>>> nm: cl-ppcre.a: File format not recognized
>>> nm: base.a: File format not recognized
>>> nm: cl-unicode.a: File format not recognized
>>> nm: cl-ppcre-unicode.a: File format not recognized
>>> nm: cl-change-case.a: File format not recognized
>>> nm: str.a: File format not recognized
>>> nm: embedded-console.a: File format not recognized
>>>
>>> What am i doing wrong? What should i change to get static library
>>> containing all systems i am intending to use (and maybe only them, if
>>> possible)?

Re: Fw: Windows 10

[Daniel Kochmański]

Hey,

I'm glad that it worked for you. Regarding compiling to a file, you may specify 
c-file, h-file and data-file
as keyword arguments to compile-file, if definitions are kept then these files 
won't be removed.

Best regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

‐‐‐ Original Message ‐‐‐
On Saturday, 28 November 2020 19:18, Garrett Dangerfield 
 wrote:

> First off, I very much appreciate your patience and help as I got this going. 
> But I HAVE got it going.
>
> I used the MS Visual Studio nmake to get it working and it's the 32-bit not 
> the 64-bit. I may poke at trying 64-bit along the way but it's lower priority.
>
> I do have to run "(ext:install-c-compiler)" each time I start the ECL REPL, 
> just FYI.
>
> The biggest issue I faced was that my Lisp code wouldn't compile. First it 
> complained about missing .h files and then it complained about missing .lib 
> files. Basically, it needed system level additional pathing for both the .h 
> files and the .lib files passed to "cl".
>
> This may or may not be the best solution, but what I did was change 
> cmpmain.lsp to include two new variables (c::*ecl-include-directory-extra* 
> and c::*ecl-library-directory-extra*). They are both lists and they are 
> "extra" directories needed during the compile and linking phases.
>
> The values I had to set mine to were:
> (setf c::*ecl-include-directory-extra*
> '("c:/Program Files (x86)/Windows Kits/10/Include/10.0.18362.0/ucrt/"
> "c:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/include/"
> "c:/Program Files (x86)/Windows Kits/10/Include/10.0.18362.0/um/"
> "c:/Program Files (x86)/Windows Kits/10/Include/10.0.18362.0/shared/"
> ))
> (setf c::*ecl-library-directory-extra*
> '("c:/Program Files (x86)/Windows Kits/10/Lib/10.0.18362.0/um/x86/"
> "c:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/lib/"
> "c:/Program Files (x86)/Windows Kits/10/Lib/10.0.18362.0/ucrt/x86/"
> ))
>
> I've attached my modified cmpmain.lsp. Please feel free to use/not use, etc. 
> however you desire (legal release granted blah blah blah).
>
> A minor issue I'm currently facing is that I'd like to look at the C code 
> generated but when I set "(setq si::*keep-definitions* t)" it doesn't seem to 
> have any effect. If there's another way to keep the C code, please let me 
> know.
>
> Also, the exe that's generated only seems to want to work right if the 
> ecl.dll is in the same directory, but that's fairly minor right now.
>
> The next goal I have is to try and connect my Lisp up to C/C++ code and 
> generate an actual working Windows GUI program (meaning actually create a 
> window but having the drawing portion of the window and the Windows messaging 
> be handled by Lisp code, ideally allowing real-time modification of the LIsp 
> while the window still up and running). I'll send updates as appropriate. I 
> may create a blog post somewhere with my ongoing adventures.
>
> Thanks again for your help,
> Garrett Dangerfield.
>
> On Thu, Nov 26, 2020 at 1:13 PM Daniel Kochmański  
> wrote:
>
>> Garrett: please put ecl-devel as the address (that may be my fault that I've 
>> hit reply earlier).
>>
>> Re your problem, please ensure, that c compiler is in the path.
>>
>>  Oryginalna wiadomość 
>> ‎ 26 lis 2020, 20:45, Garrett Dangerfield napisał(a):
>> I got a compile to work with Visual Studio. I set:
>> ECL_CMP = 1
>> and it's at least trying to generate a .o file instead of an .fasc file. I'm 
>> running this:
>>> (ext:install-c-compiler)
>>
>> ;;; Loading #P"C:/Users/danger/Downloads/ecl-20.4.24/msvc/cmp.fas"
>> NIL
>>> (compile-file "t2.lsp" :system-p t)
>>
>> ;;;
>> ;;; Compiling t2.lsp.
>> ;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
>> ;;;
>> ;;; End of Pass 1.The system cannot find the file specified.
>>
>> ;;; Internal error:
>> ;;; ** Could not spawn subprocess to run "cl".
>> NIL
>> T
>> T
>>> And its' creating these files:
>> -rwxr-xr-x+ 1 danger None 1930 Nov 26 11:40 t2.c
>> -rwxr-xr-x+ 1 danger None 395 Nov 26 11:40 t2.data
>> -rwxr-xr-x+ 1 danger None 599 Nov 26 11:40 t2.eclh
>>
>> Thoughts? Were there other settings I needed to tweak during the ECL compile?
>>
>> Thanks,
>> Garrett.
>>
>> On Thu, Nov 26, 2020 at 9:54 AM Garrett Dangerfield  
>> wrote:
&

Fw: Windows 10

[Daniel Kochmański]

Garrett: please put ecl-devel as the address (that may be my fault that I've 
hit reply earlier).

Re your problem, please ensure, that c compiler is in the path.

 Oryginalna wiadomość 
‎ 26 lis 2020, 20:45, Garrett Dangerfield napisał(a):
I got a compile to work with Visual Studio. I set:
ECL_CMP = 1
and it's at least trying to generate a .o file instead of an .fasc file. I'm 
running this:
> (ext:install-c-compiler)

;;; Loading #P"C:/Users/danger/Downloads/ecl-20.4.24/msvc/cmp.fas"
NIL
> (compile-file "t2.lsp" :system-p t)

;;;
;;; Compiling t2.lsp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; End of Pass 1.The system cannot find the file specified.

;;; Internal error:
;;; ** Could not spawn subprocess to run "cl".
NIL
T
T
> And its' creating these files:
-rwxr-xr-x+ 1 danger None 1930 Nov 26 11:40 t2.c
-rwxr-xr-x+ 1 danger None 395 Nov 26 11:40 t2.data
-rwxr-xr-x+ 1 danger None 599 Nov 26 11:40 t2.eclh

Thoughts? Were there other settings I needed to tweak during the ECL compile?

Thanks,
Garrett.

On Thu, Nov 26, 2020 at 9:54 AM Garrett Dangerfield  
wrote:
Thanks, I found the section of the manual right after I clicked send, of course.

Thanks.

On Thu, Nov 26, 2020 at 9:50 AM Daniel Kochmański  wrote:
You don't call configure on msvc build, check out install file and the manual

Wysłano z aplikacji ProtonMail

 Oryginalna wiadomość 
‎ 26 lis 2020, 17:58, Garrett Dangerfield napisał(a):

So if I use Visual Studio, will I still use cygwin to do the ./configure?

On Thu, Nov 26, 2020 at 8:55 AM Daniel Kochmański  wrote:

‐‐‐ Original Message ‐‐‐
On Thursday, 26 November 2020 17:51, Garrett Dangerfield 
 wrote:

I tried your suggestions and I tried the cygwin patch as well, no luck, that's 
why I tried to pull cygwin out of the equation. Neither seem to be producing an 
EXE that could understand an external compiler.

With the non-cygwin configuration, I'm baffled on why configure says things are 
kosher but the compile fails for missing file, though.

Thoughts?

No, sorry. All I can think of is using msvc. Generally ECL expects that he C 
compiler used will be the same compiler
ECL was built with itself.

Thanks,
Garrett.

On Thu, Nov 26, 2020 at 3:05 AM Daniel Kochmański  wrote:
ECL may be build with cygwin/mingw, then it works with cygwin/mingw runtime. 
You may also use
MSVC, then you need to enter the msvc directory and issue nmake (see 
documentation for more
precise instructions).

That said, did you try my previous suggestion with passing appropriate flags to 
cygwin?

Regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

‐‐‐ Original Message ‐‐‐
On Wednesday, 25 November 2020 23:11, Garrett Dangerfield 
 wrote:

So I zapped the gcc/g++, etc. from cygwin and did an install of mingw 64 bit 
outside of cygwin. I added the big directory from that to my path.

I did the "./configure --with-cmp=yes" and it finished:
config.status: creating ecl/config.h
config.status: creating ecl/config-internal.h
Configuration complete. To build ECL, issue make in this directory.

But make is failing:
$ make
cd build; make
make[1]: Entering directory 
'/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build'
c doc gc atomic
make[2]: Entering directory 
'/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic'
Making all in src
make[3]: Entering directory 
'/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
make all-am
make[4]: Entering directory 
'/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I../src 
-I/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src 
-Wall -Wextra -Wpedantic -Wno-long-long -g -O2 -D_THREAD_SAFE -MT atomic_ops.lo 
-MD -MP -MF .deps/atomic_ops.Tpo -c -o atomic_ops.lo 
/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src/atomic_ops.c
libtool: compile: gcc -DHAVE_CONFIG_H -I../src 
-I/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src 
-Wall -Wextra -Wpedantic -Wno-long-long -g -O2 -D_THREAD_SAFE -MT atomic_ops.lo 
-MD -MP -MF .deps/atomic_ops.Tpo -c 
/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src/atomic_ops.c
 -o atomic_ops.o
gcc.exe: error: 
/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src/atomic_ops.c:
 No such file or directory
gcc.exe: fatal error: no input files
compilation terminated.
make[4]: *** [Makefile:610: atomic_ops.lo] Error 1
make[4]: Leaving directory 
'/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
make[3]: *** [Makefile:473: all] Error 2
make[3]: Leaving directory 
'/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
make[2]: *** [Makefile:475: all-recursive] Er

Re: Windows 10

[Daniel Kochmański]

You don't call configure on msvc build, check out install file and the manual

Wysłano z aplikacji ProtonMail

 Oryginalna wiadomość 
‎ 26 lis 2020, 17:58, Garrett Dangerfield napisał(a):

> So if I use Visual Studio, will I still use cygwin to do the ./configure?
>
> On Thu, Nov 26, 2020 at 8:55 AM Daniel Kochmański  
> wrote:
>
>> ‐‐‐ Original Message ‐‐‐
>> On Thursday, 26 November 2020 17:51, Garrett Dangerfield 
>>  wrote:
>>
>>> I tried your suggestions and I tried the cygwin patch as well, no luck, 
>>> that's why I tried to pull cygwin out of the equation. Neither seem to be 
>>> producing an EXE that could understand an external compiler.
>>>
>>> With the non-cygwin configuration, I'm baffled on why configure says things 
>>> are kosher but the compile fails for missing file, though.
>>>
>>> Thoughts?
>>
>> No, sorry. All I can think of is using msvc. Generally ECL expects that he C 
>> compiler used will be the same compiler
>> ECL was built with itself.
>>
>>> Thanks,
>>> Garrett.
>>>
>>> On Thu, Nov 26, 2020 at 3:05 AM Daniel Kochmański  
>>> wrote:
>>>
>>>> ECL may be build with cygwin/mingw, then it works with cygwin/mingw 
>>>> runtime. You may also use
>>>> MSVC, then you need to enter the msvc directory and issue nmake (see 
>>>> documentation for more
>>>> precise instructions).
>>>>
>>>> That said, did you try my previous suggestion with passing appropriate 
>>>> flags to cygwin?
>>>>
>>>> Regards,
>>>> Daniel
>>>>
>>>> --
>>>> Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
>>>> TurtleWare - Daniel Kochmański | www.turtleware.eu
>>>>
>>>> "Be the change that you wish to see in the world." - Mahatma Gandhi
>>>>
>>>> ‐‐‐ Original Message ‐‐‐
>>>> On Wednesday, 25 November 2020 23:11, Garrett Dangerfield 
>>>>  wrote:
>>>>
>>>>> So I zapped the gcc/g++, etc. from cygwin and did an install of mingw 64 
>>>>> bit outside of cygwin. I added the big directory from that to my path.
>>>>>
>>>>> I did the "./configure --with-cmp=yes" and it finished:
>>>>> config.status: creating ecl/config.h
>>>>> config.status: creating ecl/config-internal.h
>>>>> Configuration complete. To build ECL, issue make in this directory.
>>>>>
>>>>> But make is failing:
>>>>> $ make
>>>>> cd build; make
>>>>> make[1]: Entering directory 
>>>>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build'
>>>>> c doc gc atomic
>>>>> make[2]: Entering directory 
>>>>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic'
>>>>> Making all in src
>>>>> make[3]: Entering directory 
>>>>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
>>>>> make all-am
>>>>> make[4]: Entering directory 
>>>>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
>>>>> /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I../src 
>>>>> -I/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src
>>>>>  -Wall -Wextra -Wpedantic -Wno-long-long -g -O2 -D_THREAD_SAFE -MT 
>>>>> atomic_ops.lo -MD -MP -MF .deps/atomic_ops.Tpo -c -o atomic_ops.lo 
>>>>> /cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src/atomic_ops.c
>>>>> libtool: compile: gcc -DHAVE_CONFIG_H -I../src 
>>>>> -I/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src
>>>>>  -Wall -Wextra -Wpedantic -Wno-long-long -g -O2 -D_THREAD_SAFE -MT 
>>>>> atomic_ops.lo -MD -MP -MF .deps/atomic_ops.Tpo -c 
>>>>> /cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src/atomic_ops.c
>>>>>  -o atomic_ops.o
>>>>> gcc.exe: error: 
>>>>> /cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src/atomic_ops.c:
>>>>>  No such file or directory
>>>>> gcc.exe: fatal error: no input files
>>>>> compilation terminated.
>>>>> make[4]: *** [Makefile:610: atomic_ops.lo] Error 1
>>>>> make[4]: Leaving directory 
>>>>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.2

Re: Windows 10

[Daniel Kochmański]

‐‐‐ Original Message ‐‐‐
On Thursday, 26 November 2020 17:51, Garrett Dangerfield 
 wrote:

> I tried your suggestions and I tried the cygwin patch as well, no luck, 
> that's why I tried to pull cygwin out of the equation. Neither seem to be 
> producing an EXE that could understand an external compiler.
>
> With the non-cygwin configuration, I'm baffled on why configure says things 
> are kosher but the compile fails for missing file, though.
>
> Thoughts?

No, sorry. All I can think of is using msvc. Generally ECL expects that he C 
compiler used will be the same compiler
ECL was built with itself.

> Thanks,
> Garrett.
>
> On Thu, Nov 26, 2020 at 3:05 AM Daniel Kochmański  
> wrote:
>
>> ECL may be build with cygwin/mingw, then it works with cygwin/mingw runtime. 
>> You may also use
>> MSVC, then you need to enter the msvc directory and issue nmake (see 
>> documentation for more
>> precise instructions).
>>
>> That said, did you try my previous suggestion with passing appropriate flags 
>> to cygwin?
>>
>> Regards,
>> Daniel
>>
>> --
>> Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
>> TurtleWare - Daniel Kochmański | www.turtleware.eu
>>
>> "Be the change that you wish to see in the world." - Mahatma Gandhi
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Wednesday, 25 November 2020 23:11, Garrett Dangerfield 
>>  wrote:
>>
>>> So I zapped the gcc/g++, etc. from cygwin and did an install of mingw 64 
>>> bit outside of cygwin. I added the big directory from that to my path.
>>>
>>> I did the "./configure --with-cmp=yes" and it finished:
>>> config.status: creating ecl/config.h
>>> config.status: creating ecl/config-internal.h
>>> Configuration complete. To build ECL, issue make in this directory.
>>>
>>> But make is failing:
>>> $ make
>>> cd build; make
>>> make[1]: Entering directory 
>>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build'
>>> c doc gc atomic
>>> make[2]: Entering directory 
>>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic'
>>> Making all in src
>>> make[3]: Entering directory 
>>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
>>> make all-am
>>> make[4]: Entering directory 
>>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
>>> /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I../src 
>>> -I/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src
>>>  -Wall -Wextra -Wpedantic -Wno-long-long -g -O2 -D_THREAD_SAFE -MT 
>>> atomic_ops.lo -MD -MP -MF .deps/atomic_ops.Tpo -c -o atomic_ops.lo 
>>> /cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src/atomic_ops.c
>>> libtool: compile: gcc -DHAVE_CONFIG_H -I../src 
>>> -I/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src
>>>  -Wall -Wextra -Wpedantic -Wno-long-long -g -O2 -D_THREAD_SAFE -MT 
>>> atomic_ops.lo -MD -MP -MF .deps/atomic_ops.Tpo -c 
>>> /cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src/atomic_ops.c
>>>  -o atomic_ops.o
>>> gcc.exe: error: 
>>> /cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src/atomic_ops.c:
>>>  No such file or directory
>>> gcc.exe: fatal error: no input files
>>> compilation terminated.
>>> make[4]: *** [Makefile:610: atomic_ops.lo] Error 1
>>> make[4]: Leaving directory 
>>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
>>> make[3]: *** [Makefile:473: all] Error 2
>>> make[3]: Leaving directory 
>>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
>>> make[2]: *** [Makefile:475: all-recursive] Error 1
>>> make[2]: Leaving directory 
>>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic'
>>> make[1]: *** [Makefile:129: libeclatomic.a] Error 2
>>> make[1]: Leaving directory 
>>> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build'
>>> make: *** [Makefile:65: all] Error 2
>>>
>>> Obviously, on windows I still have to use cygwin as my shell because that's 
>>> what configure expects.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Garrett.
>>>
>>> On Wed, Nov 25, 2020 at 10:03 AM Daniel Kochmański  
>>> wrote:
>>>
>>>> So the problem seems to be quite clear: your ecl build doesn't have the C 
>>>> compiler enabled.
>>>> When you configure the build, include --with-cmp=yes (or builtin).
>>>>
>>>> ./configure --prefix=/my/cygwin/prefix --with-cmp=yes
>>>> make && make install
>>>>
>>>> Then C compiler should be available (you may still need to call 
>>>> (ext:install-c-compiler), you need
>>>> to check it yourself because I don't remember whether bytecodes compiler 
>>>> is installed by default
>>>> on cygwin, it is for msvc).
>>>>
>>>> If it still doesn't work, please include a result of calling this code 
>>>> snippet:
>>>>
>>>> (format t "~&~@{~12@A ~S~%~}"
>>>> :version (lisp-implementation-version)
>>>> :vcs-id (ext:lisp-implementation-vcs-id)
>>>> :os (software-type)
>>>> :os-version (software-version)
>>>> :machine-type (machine-type)
>>>> :features *features*)

Re: Static Compilation Issues

[Daniel Kochmański]

Hey Ava,

are all dependencies specified in drakma? i.e sb-bsd-sockets, uiop and asdf?
If not, please try add them as dependencies of your project. If that doesn't
work then please file an issue with a source code you've used and dump from
the console of what is happening (including commands you issue).

Best regards,
Daniel


--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

‐‐‐ Original Message ‐‐‐
On Thursday, 26 November 2020 00:46, Ava Fox  wrote:

> I've been learning how to create static executables with ECL and was
> looking at the provided example that uses an ASDF system that has
> defined dependencies
> (https://gitlab.com/embeddable-common-lisp/ecl/-/tree/develop/examples/asdf_with_dependence).
> When following the readme, and building it as-is with Quicklisp fetching
> alexandria (the only dependency specified) it works fine.
>
> However, when I change that dependency to include a project such as
> drakma it compiles fine but then throws SIMPLE-ERROR when I run the
> resulting static executable, saying that various uiop/asdf packages and
> sb-bsd-sockets cannot be found.
>
> Exact error:
>
> Condition of type: SIMPLE-ERROR
> Package ((SB-BSD-SOCKETS . #)) referenced in
> compiled file
>   NIL
> but has not been created
>
> Exact packages being listed as not being found: :sb-bsd-sockets,
> :uiop/filesystem, :uiop/os, :uiop/pathname, :asdf/operate, :asdf/lisp-action
>
> Any help or ideas would be appreciated, I am just unsure of where to go
> from here.
>
> ECL version: 20.4.24
>
> Operating System: Linux Kernel 5.8.18

Re: Windows 10

[Daniel Kochmański]

ECL may be build with cygwin/mingw, then it works with cygwin/mingw runtime. 
You may also use
MSVC, then you need to enter the msvc directory and issue nmake (see 
documentation for more
precise instructions).

That said, did you try my previous suggestion with passing appropriate flags to 
cygwin?

Regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

‐‐‐ Original Message ‐‐‐
On Wednesday, 25 November 2020 23:11, Garrett Dangerfield 
 wrote:

> So I zapped the gcc/g++, etc. from cygwin and did an install of mingw 64 bit 
> outside of cygwin. I added the big directory from that to my path.
>
> I did the "./configure --with-cmp=yes" and it finished:
> config.status: creating ecl/config.h
> config.status: creating ecl/config-internal.h
> Configuration complete. To build ECL, issue make in this directory.
>
> But make is failing:
> $ make
> cd build; make
> make[1]: Entering directory 
> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build'
> c doc gc atomic
> make[2]: Entering directory 
> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic'
> Making all in src
> make[3]: Entering directory 
> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
> make all-am
> make[4]: Entering directory 
> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
> /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I../src 
> -I/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src 
> -Wall -Wextra -Wpedantic -Wno-long-long -g -O2 -D_THREAD_SAFE -MT 
> atomic_ops.lo -MD -MP -MF .deps/atomic_ops.Tpo -c -o atomic_ops.lo 
> /cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src/atomic_ops.c
> libtool: compile: gcc -DHAVE_CONFIG_H -I../src 
> -I/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src 
> -Wall -Wextra -Wpedantic -Wno-long-long -g -O2 -D_THREAD_SAFE -MT 
> atomic_ops.lo -MD -MP -MF .deps/atomic_ops.Tpo -c 
> /cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src/atomic_ops.c
>  -o atomic_ops.o
> gcc.exe: error: 
> /cygdrive/c/Users/danger/Downloads/ecl-20.4.24/src/bdwgc/libatomic_ops/src/atomic_ops.c:
>  No such file or directory
> gcc.exe: fatal error: no input files
> compilation terminated.
> make[4]: *** [Makefile:610: atomic_ops.lo] Error 1
> make[4]: Leaving directory 
> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
> make[3]: *** [Makefile:473: all] Error 2
> make[3]: Leaving directory 
> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic/src'
> make[2]: *** [Makefile:475: all-recursive] Error 1
> make[2]: Leaving directory 
> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build/atomic'
> make[1]: *** [Makefile:129: libeclatomic.a] Error 2
> make[1]: Leaving directory 
> '/cygdrive/c/Users/danger/Downloads/ecl-20.4.24/build'
> make: *** [Makefile:65: all] Error 2
>
> Obviously, on windows I still have to use cygwin as my shell because that's 
> what configure expects.
>
> Thoughts?
>
> Thanks,
> Garrett.
>
> On Wed, Nov 25, 2020 at 10:03 AM Daniel Kochmański  
> wrote:
>
>> So the problem seems to be quite clear: your ecl build doesn't have the C 
>> compiler enabled.
>> When you configure the build, include --with-cmp=yes (or builtin).
>>
>> ./configure --prefix=/my/cygwin/prefix --with-cmp=yes
>> make && make install
>>
>> Then C compiler should be available (you may still need to call 
>> (ext:install-c-compiler), you need
>> to check it yourself because I don't remember whether bytecodes compiler is 
>> installed by default
>> on cygwin, it is for msvc).
>>
>> If it still doesn't work, please include a result of calling this code 
>> snippet:
>>
>> (format t "~&~@{~12@A ~S~%~}"
>> :version (lisp-implementation-version)
>> :vcs-id (ext:lisp-implementation-vcs-id)
>> :os (software-type)
>> :os-version (software-version)
>> :machine-type (machine-type)
>> :features *features*)

Re: Question on multiple contributions to common-lisp.net...

[Daniel Kochmański]

Ops, accidently accepted a spam email (they have mentioned common-lisp.net 
though! :) sorry about that.

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

[release][ecl 20.4.24]

[Daniel Kochmański]

Dear All,

we've released today a new version of ECL. For details please see the
announcement on our blog:
https://common-lisp.net/project/ecl/posts/ECL-20424-release.html

Best regards,
Daniel

P.S. I've modified a blog a little so the index shows only headers
(instead of whole bodies). It is easier to navigate old entries that
way.

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: ASDF problem on second load of ECL

[Daniel Kochmański]

Hey querent,

could it be, that you have two ASDF versions loaded on top of each
other? i.e asdf.lisp in your ~/common-lisp/ directory or something in
this spirit.

Best regards,
Daniel

-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: About the source of The ECL Manual

[Daniel Kochmański]

Hey NOEU,

NOEU writes:

> Hello.
>
> I want to translate "The ECL
> Manual(https://common-lisp.net/project/ecl/static/manual/)" into my
> native language (Japanese). Because I couldn't find the translated
> version.
Manual sources are in the source tree of ECL under a subtree
src/doc/manual. The most recent version is in branch develop.

>
> Is "The ECL Manual" generated by DocBook?
> Please let me know if I have a way to get the XML source for The ECL
> Manual.

Old version was written in XML. We have rewritten it to texinfo. If you
are interested in the old version please see src/doc/old-manual/.
>
> Thanks

Best regards,
Daniel


--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Combining ~T and ~<~:;~>

[Daniel Kochmański]

Hello Eric,

Eric Timmons writes:

> I've been using ECL to compile SBCL on aarch64, but I can't do it
> without patching the sources. There is a warning triggered during the
> build (only on aarch64) with a format string that contains:
>
> ~<~%~9T~:;~/sb-impl:print-type/:~>
>
> ECL chokes on this due to the ~T in the ~:; clause. Why is that not
> allowed? It seems like a reasonable thing to do at first glance.
>
> -Eric

We've fixed issues with bootstrapping sbcl from ecl /after/ the 16.1.3
release (a new version will be released soon); for details please see:

https://gitlab.com/embeddable-common-lisp/ecl/issues/540 (~T problem)
https://gitlab.com/embeddable-common-lisp/ecl/issues/468 (other issues)

Please try building ECL from a develop branch and then bootstrap SBCL
from this build.

Best regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Error while running a simple GTK program with ECL

[Daniel Kochmański]

If number of so files is the problem then try to build a bundle (ot even a 
monolithic bundle), then each library/all libraries will be in a single fas 
instead of a fasl-per-file.

On January 4, 2020 9:57:36 PM GMT+01:00, Marius Gerbershagen 
 wrote:
>Hi,
>
>> Hi list,
>> I am sorry I didn't find an ECL-User mailing list, so I post this
>question here. If here is not the right place to ask this kind of
>question, please let me know.
>> I wrote a simple GTK program using cl-gtk2-gtk, please see it
>here:http://depot.kdr2.com/scrappy/202001/ecl-gtk.lisp
>> 
>> After I installed the dependent packages using quicklisp,  I ran it
>with `ecl --load ecl-gtk.lisp`, then, ECL started to compile files. It
>compiled for about 5 hours, and emitted an error, here is the
>log:http://depot.kdr2.com/scrappy/202001/ecl-gtk.log
>
>The important parts of the log are the errors such as
>
>(Error: "/tmp/ecl3258uX7y8Y.fas: failed to map segment from shared
>object")
>
>I can't tell you exactly how to fix this, but it is clear that the
>cl-gtk2-gtk system is compiling A HUGE NUMBER of files and also single
>functions. This number might be simply too big for ECL to handle and
>the
>above error a result of some limit on the number of shared libraries
>that one can load imposed by the glibc or the kernel, I don't know.
>
>> Then I run it again, it gave a different error:
>> ```$ ecl --load ecl-gtk.lisp;;; Loading
>"/home/kdr2/Work/mine/DS-III/explore/common-lisp/ecl-gtk.lisp";;;
>Loading "/home/kdr2/quicklisp/setup.lisp";;; Loading
>#P"/usr/lib/x86_64-linux-gnu/ecl-16.1.3/asdf.fas"An error occurred
>during initialization:The slot ASDF/PLAN::STAMP in the object
>#> Condition of type: STACK-OVERFLOWBINDING-STACK overflow at size
>10240. Stack can probably be resized.Proceed with caution.Available
>restarts:
>> 1. (CONTINUE) Extend stack size2. (RETRY) Retry ASDF operation.3.
>(CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting
>the configuration.4. (RETRY) Retry completing compilation for
>#.5. (ACCEPT) Continue, treating
>completing compilation for # as having
>been successful.6. (RETRY) Retry ASDF operation.7.
>(CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting
>the configuration.8. (CONTINUE) Ignore initialization errors and
>continue.9. (ABORT) Quit ECL unsafely, ignoring all existing threads.
>> Top level in: #.>
>> ```
>
>I have seen errors like this before when asdf was trying (and failing)
>to replace itself with a newer version. You can 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

-- Wysłane za pomocą K-9 Mail.

Re: Raspberry Pi test results

[Daniel Kochmański]

Hey Dave,

thank you for this,

Dave Richards writes:


> Add the file src/c/arch/fpe_fenv.c:
>
> /* -*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*- */
> /* vim: set filetype=c tabstop=8 shiftwidth=4 expandtab: */
>
> /*
> fpe_fenv.c -- ISO C99 version of the floating point code
> */
> /*
> Copyright (c) 2005, Juan Jose Garcia Ripoll.

Did you bring back an old file? If not please adjust the copyright note
accordingly.
>
> The cl-bench results are:

could you also run cl-bench against the last release build? they make
sense only in scenario when we compare results with previous versions.

Best regards,
Daniel

PS Happy new year!

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: FP exceptions on Raspberry Pi

[Daniel Kochmański]

Hey Dave,

Dave Richards writes:

> It appears that the VFP unit on the Raspberry Pi does not generate FPU
> exceptions.  Therefore, no SIGFPE is generated and cannot be handled by ECL.
> This causes numerous 'make check' test failures.  I am working on a patch.
> I am not very familiar with the ECL C environment so I am sure the patch
> will need some help.  The approach is as follows:
>
> 1. There is no value in registering a SIGFPE handler.  For the ARM I will
> just not register the handler at all.

If you are interested in how handler works please take a look at file
src/c/unixint.d (most notably install_fpe_handler). That said the option
you look for is ECL_OPT_TRAP_SIGFPE (src/c/main.d). That said there is
no harm with leaving it at its default value, if sigfpe is not signaled
then the handler will simply not be called.

> 2. I will created an arch/fpe_arm.c file.  I will re-define the macro to
> read the FPSCR register and check for exception bits being set.  If any are
> I will call a C function that will disambiguate which exception to map to a
> condition and signal the condition.

please see files:
- c/arch/fpe_*.c for software ecl_detect_fpe() definitions
- c/number.d for a definition of DO_DETECT_FPE()

calls to floating point operations are always detected in the float
number constructors (if software fpe handling is used). They are
signalled with ecl_deliver_fpe.

> 3. I was planning on creating a static inline function for this purpose
> right inside fpe_arm.c but if it should go somewhere else I'd be happy to
> put it there.  The inline thing is just an excuse for sticking in the
> fpe_arm.c file.  In reality it's probably better to make a C function call
> to do the heavy lifting rather than making each FPE check pay for it.

If you need a file then fpe_/arch/.c is the right place to put
it. Preferably this file is self-contained (static function definition).
>
>   Dave

Best regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

[ecl 20.1.x][rc testing]

[Daniel Kochmański]

Dear All,

After three years of development we are closing to a new release. During
this time many important features and fixes has been made. We also have
a new co-maintainer of the project – Marius Gerbershagen, what is a
fantastic news (especially from a bus-factor perspective :-).

If you have spare machines (especially on uncommon architectures/
operating systems), it would be very helpful if you could help with
testing. I'm tracking testing progress here:

https://gitlab.com/embeddable-common-lisp/ecl/issues/333

there is no need to limit yourself to the mentioned platforms and it is
possible that we will omit some listed there, so please treat it more
like a wishlist than an actual roadmap. We are especially interested in
regressions (that is issues which are not present in 16.1.3 but occur in
the current develop branch) - of course if you encounter other problems
please report them too, but they will be most likely addressed after the
release. Thank you for your help; I hope that we will be able to release
the new version on January 2020.

As a side note, I've been invited to give a talk at the European Lisp
Symposium this year about ECL. Currently I'm working on the compiler
documentation and refactoring as well as the IR visualizer, but these
changes will be proposed after there release.

Best regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Error when building ironclad

[Daniel Kochmański]

Hello Dave,

Dave Richards writes:

> This occurs on my Raspberry Pi 3B+ running Raspbian Buster on current ECL:

> ;;; Internal error:
> ;;;   ** Error code 1 when executing
> ;;; (SI:RUN-PROGRAM-INNER "gcc" ("-I." "-I/home/pi/ecl/include/"note
> "-D_GNU_SOURCE" "-D_FILE_OFFSET_BITS=64" "-g" "-O2" "-fPIC" "-D_THREAD_SAFE"
> "-Dlinux" "-O2" "-c"
> ".cache/common-lisp/ecl-16.1.3-87a1c5fa-linux-armv7l/home/pi/quicklisp/dists
> /quicklisp/software/ironclad-v0.47/src/ciphers/kalyna.c" "-o"
> ".cache/common-lisp/ecl-16.1.3-87a1c5fa-linux-armv7l/home/pi/quicklisp/dists
> /quicklisp/software/ironclad-v0.47/src/ciphers/kalyna.o") NIL):
> ;;;
> .cache/common-lisp/ecl-16.1.3-87a1c5fa-linux-armv7l/home/pi/quicklisp/dists/
> quicklisp/software/ironclad-v0.47/src/ciphers/kalyna.c: In function
> 'L49kalyna512_decrypt_block':
> ;;;
> .cache/common-lisp/ecl-16.1.3-87a1c5fa-linux-armv7l/home/pi/quicklisp/dists/
> quicklisp/software/ironclad-v0.47/src/ciphers/kalyna.c:231231:18: note:
> variable tracking size limit exceeded with -fvar-tracking-assignments,
> retrying without
> ;;;  static cl_object L49kalyna512_decrypt_block(cl_object v1context,
> cl_object v2ciphertext, cl_object v3ciphertext_start, cl_object v4plaintext,
> cl_object v5plaintext_start)
> ;;;   ^~

These notes may be ignored. It just means that function is too big to
store debug information in appropriate tables (C compiler thing).

> ;;; gcc: fatal error: Killed signal terminated program cc1
> ;;; compilation terminated.

This seems to be the real issue. If I had to guess it was OOM kicking in
and killing the compiler because GCC reached available memory limit on
your system. Do you have particular process quotas for memory? or maybe
your system is full of other processes atm? You may try to add swap to
your system, remove the quota or free some memory beforehand.

Best regards,
Daniel

-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: [PATCH] Improved error detection and reporting in RESTART-BIND

[Daniel Kochmański]

I see, in that case please make a merge request on
gitlab.common-lisp.net, we'll go through peer review there and I'll
merge it locally when all is fine and push to the repository we use.

Here is a link to ecl repository mirror:
https://gitlab.common-lisp.net/ecl/ecl

>hosted at gitlab.com (however it would be nice to move to
>gitlab.common-lisp.net, just /not now/),

I've found writing ecl quarterly too time consuming given I work also on
other projects, I wouldn't take everything I wrote then at face
value. At some point I've decided that gitlab repository is good enough
for time being and moving it will introduce another big confusion among
contributors (and I want to avoid that unless there is a practical
reason to move it again). In any case we have the mirror set up so if
gitlab.com stops to be a viable solution we'll move there.

Regarding formating patches (for the future), a good solution to do it
(so it is applicable) is calling git format-patch after doing commits,
that preserves commit messages and ensures that it is possible to apply
it to the branch it was made on.

Regards,
Daniel


--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: [PATCH] Improved error detection and reporting in RESTART-BIND

[Daniel Kochmański]

Hello Spiros,

thank you for your contribution. We do not accept patches over mailing
list. Instead we prefer merge requests on our repository. This makes
possible peer review, requeesting changes and continous integration.

Repository is located here:
https://gitlab.com/embeddable-common-lisp/ecl

Please create a git commit with detailed commit message and make a merge
request there. Branch used for development is called "develop" (it will
be cloned as default unless you specify it otherwise).

If you are not familiar with gitlab workflow here's how it goes:
- [on gitlab] create an account on the platform
- [on gitlab] fork the repository into your personal userspace
- [locally] clone the repository from your fork
- [locally] do appriate changes on your computer and make git commit
- [locally] push to your local repository
- [on gitlab] go to merge requests tab and select "new merge request"

While this patch is small and I could manage merging it (although it is
made against ecl 16.1.3 version, so patch may fail against develop
branch), I'm anxious about setting a precedence - working with patches
manually is more time-consuming on my part. I hope that this explanation
is sufficient to you. Once again thank you for sharing your improvements
to ECL.

Best regards,
Daniel

--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Compilation failure on cygwin

[Daniel Kochmański]

Hey,

please report a ticket on gitlab. Information which would be useful:

- ecl version (commit, where did you get it from)
- configuration flags and build log
- console log where things fail
- what fails and backtrace for that
- cygwin version (where did you get it from)
- windows version

Thanks,
Daniel

Иван Трусков writes:

> Hello
> I am trying to build and use ECL on windows machine under cygwin environment
> However, evter it is built, there arises a problem when i try to compile
> any lisp files, for example when running examples/build/readme.lisp
> Inspecting with gsb gives the picture of stack overflow on handling some
> exception across threads, overflow occuring in the bad case of circular
> calls to acquiring thread-local data (pthreads_getspecific) and processing
> error message from failure of it.
>
> is there recommended configuration for cygwin that would allow to overcome
> that kind of problem? Alternatively, what data exactly are needed for a
> full bug report? I would gladly provide everything relevant


-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Evaluating with a lexical environment

[Daniel Kochmański]

Hello Spiros,

> I was wondering if ECL has something analogous or could be added easily.
no such interfaces are present currently in ECL. Even with bytecompiler 
code is not interpreted but always minimally compiled.


> Looking in the ECL source I saw a  si::eval-with-env  function in file
> ecl-16.1.3/src/c/compiler.d .If you do
>
>> (find-symbol "EVAL-WITH-ENV" "SYSTEM")
> SI:EVAL-WITH-ENV
> :EXTERNAL
>
> which suggests that the function is not just for internal use. But 
scanning

> the documentation , I didn't see it mentioned.
symbols in package system are part of ecl internals (this is 
documented), they are not part of the api. Only symbols reexported to 
ext are somewhat stable.


> I tried
>
> (defmacro env-eval (form  env)
>  `(ext:eval-with-env ,form (quote ,env)))
> ENV-EVAL
>> (let ((v 12)) (env-eval '(print v)))
> The variable V is unbound.
> Broken at EVAL.No restarts available.
> Broken at EVAL.
>
>
> So is there a way to achieve this ?
>
eval-with-evn accepts the lexical environment while environment put 
there by defmacro is something else. You may use a hack, but I do not 
guarantee it will work in all scenarios:


CL-USER> (defmacro eval-with-lexenv-ala-clisp (form)
   `(let ((lexenv (nth-value 1 (function-lambda-expression 
(lambda ())

  (si:eval-with-env ,form lexenv)))
EVAL-WITH-LEXENV-ALA-CLISP
CL-USER> (let ((v 42))
   (eval-with-lexenv-ala-clisp '(print v)))

42
42

Most notably this *won't* work in normally compiled code.

Best regards,
Daniel

Re: Infinite loop or blocking operation in main ECL thread - what to do?

[Daniel Kochmański]

Hey,

given scarce amount of details this may be inaccurate, but if I had such
issue I'd do what follows:

start main ECL thread and spawn a thread with the user script in
it. Function running in this process would look something in this
spirit:

(loop
  while (null *exit*)
  do (handler-case (si:toplevel)
   (serious-condition (c)
 (format *debug-io* "something is wrong:~%~a~%~@
  Yes, starting over." c

Since it will be in a separate thread, you may safely interrupt it or
even destroy to start over. You may put your own repl in the
handler-case body and i.e wrap each REP iteration in with-timeout.

Regarding problems with cl_boot, cl_shutdown, cl_boot please report an
issue on our bugtracker.

N.b at some point of time I'd love to see a functionality in ECL where
whole runtime is stored in a single variable, so we could have N
different ECL instances running in the same process, but I don't think
it will happen anytime soon.

  ecl_call_with_runtime(ecl_ptr, "(si::toplevel)");

Best regards,
Daniel

Не Скажу writes:

> Some portion of program is scriptable with ECL, which runs in its own 
> separate thread. What I fear, however, is that users might do something 
> stupid and enter an infinite loop or break into debugger wondering why does 
> the scriptable part no longer responds. For the latter breaking into debugger 
> is disabled by default with an option to reenable it, but nevertheless 
> knowing Murphy's law I expect the worst to happen. I would like to keep the 
> program responsive no matter what.
>
> I was hoping I could restart ECL in such cases, so I tried terminating ECL 
> thread first but it results in a crash. And apparently after calling 
> cl_shutdown ECL shuts down for good and a second call to cl_boot does not 
> work so restarting does not appear as an option anyway.
>
> Is there anything I can do to keep the program running or just trust the user 
> to do the right thing?


--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: What is the best version of ECL to use right now?

[Daniel Kochmański]

> [...] there are multiple more calls to Lxxstore_object() methods below this
> 
> I am having problems debugging this because I highly doubt that the generic 
> function dispatch mechanism is broken (otherwise *nothing ever* would work, 
> right?) So I think something else is causing this confusion in 
> fill_spec_vector.

It is hard to tell anything without a reproducible test case I could use. 
Please replace the if/else in fill_spec_vector with:

<< I've compiled it with only the --disable-threads flag now and I still get the 
> same crash in the call to GC_init() in cl_boot(). However, staring the ECL 
> interpreter works fine and embedding ECL into a single-threaded, small 
> example program also works.

Regarding working with threads enabled: ECL enviroment must b e imported on 
each "C++ world" thread (see examples for how to do that). That is not 
necessary on ECL with single thread build.

Regarding GC_init – are you certain you do not call it twice for some reason? 
Or that cl_boot is not called twice? I mildly remember someone had a similar 
problem and it was due to calling GC_init separately before cl_boot (or 
immedietely after).
> 
> Could it be that I am missing something when trying to embed ECL in a large 
> C++ codebase? Do I have to worry about the Boehm GC not functioning when most 
> of the program is not designed to use GC_MALLOC? I am also statically linking 
> my lisp code, would that make a difference here?

No, bdwgc should work fine with code which is not libgc aware. You may want to 
try using libgc shipped with your system. I don't know what your OS is, but 
OpenBSD has some heavy restrictions for what you can do with memory.
> 


Regards,
Daniel

Re: What is the best version of ECL to use right now?

[Daniel Kochmański]

On Tue, 04 Jun 2019 20:22:48 -0400
Dennis Ogbe  wrote:

> Hello Daniel,
> 
> thanks for your reply, that's about what I expected. It's not a secret at 
> all---My team and I (a bunch of graduate students) are building an 
> "intelligent" radio network using software-defined radios. The source is not 
> opened--yet--since we are competing as part of a DARPA Grand Challenge [1].
> 
> While I have you here: I am currently fighting a strange bug that crashes my 
> process. I am still in the phase where its occurrences seem random to me, so 
> I can't tell you how to reproduce it, but the crashes seem localized to the 
> if statement in fill_spec_vector in src/c/gfun.d--the call to cl_class_of() 
> crashes with an unrecoverable error "not a lisp object".

what is the object you call cl_class_of on? are you sure it is initialized 
cl_object? you may try attaching gdb to the process (see src/utils/gdbinit for 
useful configuration).
> 
> Since I've seen merge requests like [2] I wanted to try to disable threading, 
> since I won't be using it. But when I compile ecl with
> 
> ./configure --enable-shared --enable-threads=no --enable-boehm=included 
> --with-dffi --enable-debug=yes
> 
> I now crash in cl_boot in a GC function (GC_push_all_eager)! Is building 
> without threads supposed to work or am I trying the wrong thing here? My 
> original problem (the crash in fill_spec_vector) only happens about 1/500 
> times I call the offending function (it's the store function from cl-store), 
> and I am still investigating what the culprit could be. If you have any 
> thoughts--I'd appreciate it!

I've used recently ECL with threads disabled and all seemed to work. I would 
try playing with flags (i.e first allow use autodetected boehm, then skip the 
with-dffi flag if it still doesn't work, then remove enable-shared and at last 
enabl-edebug). If ./configure --disable-threads without any additions still 
crashes then it is indeed problem with this exactly flag.
> 
> Thanks,
> Dennis

Regards,
Daniel
> 
> [1] https://www.spectrumcollaborationchallenge.com/
> [2] https://gitlab.com/embeddable-common-lisp/ecl/merge_requests/100
> 
> Daniel Kochmański  writes:
> 
> > Hello Dennis,
> >
> > On Mon, 2019-06-03 at 20:02 -0400, Dennis Ogbe wrote:
> >> Hello,
> >>
> >> I am working on embedding ECL in a reasonably-sized C++ program and I
> >> have been using v16.1.3 until now, since it seems like this is the
> >> latest official release.
> >
> > Yes, 16.1.3 is the latest official release.
> >>
> >> However, it seems like there is a lot of activity and bug fixes in
> >> the develop branch and I already ran into a few bugs (for example
> >> [1]) that are fixed in develop, but are not in any release. The
> >> documentation also seems to overlap more with the develop branch than
> >> the latest release.
> >
> > That is also true, we work on the next release and we expect to make
> > the new one soon™ (only a few tasks has been left over to implement).
> >>
> >> In your opinion, what is the best and most stable ECL version to use
> >> as of June 2019? I have some reservations about simply picking a
> >> random commit from a dev branch, so I wanted to reach out and ask
> >> y'all directly.
> >
> > There is no good answer for that. While develop branch indeed has many
> > improvements in form of bug fixes and new (dare I say – exciting)
> > features it is only loosely tested. Before each release we work hard to
> > test the release candidate against a big variety of operating systems,
> > architectures and libraries (cl-test-grid is an invaluable help with
> > that) and try to fix regressions. If you feel adventurous just pick
> > develop branch, we do not commit there half-baked things (only stuff
> > which we are certain about or which was a subject of a peer review /
> > testing around the thing being changed) - it is fairly stable. But
> > there is no guarantee that you won't hit some ugly regression we are
> > not aware of yet. Otherwise you may try to live with 16.1.3 until we
> > release the new 16.2.0 version – hopefully withing a few months from
> > now.
> >>
> >> Thanks for all the hard work, this project is great!
> >
> > That's very kind of you to say that. If it is not a secret what are you
> > working on?
> >>
> >> [1] https://gitlab.com/embeddable-common-lisp/ecl/issues/418
> >>
> >
> > Best regards,
> > Daniel


-- 
Daniel Kochmański 

Re: What is the best version of ECL to use right now?

[Daniel Kochmański]

Hello Dennis,

On Mon, 2019-06-03 at 20:02 -0400, Dennis Ogbe wrote:
> Hello,
> 
> I am working on embedding ECL in a reasonably-sized C++ program and I
> have been using v16.1.3 until now, since it seems like this is the
> latest official release.

Yes, 16.1.3 is the latest official release.
> 
> However, it seems like there is a lot of activity and bug fixes in
> the develop branch and I already ran into a few bugs (for example
> [1]) that are fixed in develop, but are not in any release. The
> documentation also seems to overlap more with the develop branch than
> the latest release.

That is also true, we work on the next release and we expect to make
the new one soon™ (only a few tasks has been left over to implement).
> 
> In your opinion, what is the best and most stable ECL version to use
> as of June 2019? I have some reservations about simply picking a
> random commit from a dev branch, so I wanted to reach out and ask
> y'all directly.

There is no good answer for that. While develop branch indeed has many
improvements in form of bug fixes and new (dare I say – exciting)
features it is only loosely tested. Before each release we work hard to
test the release candidate against a big variety of operating systems,
architectures and libraries (cl-test-grid is an invaluable help with
that) and try to fix regressions. If you feel adventurous just pick
develop branch, we do not commit there half-baked things (only stuff
which we are certain about or which was a subject of a peer review /
testing around the thing being changed) - it is fairly stable. But
there is no guarantee that you won't hit some ugly regression we are
not aware of yet. Otherwise you may try to live with 16.1.3 until we
release the new 16.2.0 version – hopefully withing a few months from
now.
> 
> Thanks for all the hard work, this project is great!

That's very kind of you to say that. If it is not a secret what are you
working on?
> 
> [1] https://gitlab.com/embeddable-common-lisp/ecl/issues/418
> 

Best regards,
Daniel

Re: ECL cross-compiled for 'aarch64' considered stable?

[Daniel Kochmański]

Hay Paul,

it is worth noting that there are some unresolved issues on aarch64 due
to calling convention for variadic functions is differnt. Please see this 
summary: 

https://gitlab.com/embeddable-common-lisp/ecl/issues/224

apparently aarch64 android calling convention is more permissive given it works
for you.

Best regards,
Daniel

On Mon, 11 Mar 2019 10:06:18 +0100
PR  wrote:

> 2019-03-10 23:59 GMT+01:00, PR :
> > Did anybody here run ECL on aarch64, and is it considered to be stable?
> >
> > I'm asking because of my EQL5-Android project: I successfully compiled
> > the REPL example to aarch64, but I encountered a severe memory
> > corruption at startup [...]
> 
> ...answering myself: it seems that I got confused by all the different
> 32bit/64bit cross compiled versions of ECL sitting on my computer, so
> I just mixed it up in one place.
> After rebuilding everything from scratch, the memory corruption
> doesn't happen anymore.
> 
> Sorry for the noise.
> 
> Paul
> 
> P.S. ...and yes, ECL seems to run just fine on aarch64. I will add the
> scripts to cross-compile it to my EQL5-Android project, if you are
> interested in building it yourself.
> 


-- 
Daniel Kochmański 

Re: specifying custom location for ecl-quicklisp packages

[Daniel Kochmański]

Hey Dima,

ecl-quicklisp contrib is more a conveniance hack than a mechanism I
would advertise for getting quicklisp. The correct way to do that is to
download quicklisp from its homepage and follow instructions from its
website (and verifying signatures etc) and add loading setup.lisp from
the location you look out for.

That said ecl-quicklisp installs Quicklisp at the location reflected in
a logical pathname translation for "HOME:QUICKLISP;". To customize
install directory for ecl-quicklisp contrib target set it to the
desired directory:

   CL-USER> (push '("HOME:QUICKLISP;**;*.*" "/tmp/quicklisp/**/*.*") 
(logical-pathname-translations "HOME"))
   ((#P"HOME:QUICKLISP;**;*.*" #P"/tmp/quicklisp/**/*.*")
(#P"HOME:**;*.*" #P"/home/jack/**/*.*"))
   CL-USER> (translate-logical-pathname "HOME:QUICKLISP;directory;setup.lisp")
   #P"/tmp/quicklisp/directory/setup.lisp"
   CL-USER> (translate-logical-pathname "HOME:QUICKLISP;setup.lisp")
   #P"/tmp/quicklisp/setup.lisp"
   CL-USER> (translate-logical-pathname "HOME:QUICKLISP;")
   #P"/tmp/quicklisp/"

That should be enough to make (require 'ecl-quicklisp) to install QL in
"/tmp/quicklisp/" directory. I would advertise doing

  (require 'ecl-quicklisp)

instead of (asdf:load-system :ecl-quicklisp). While the latter will
probably work it is a contrib module, not a library (and asdf's inner
workings are not under ECL custody).

Best regards,
Daniel

Re: least-positive vs least-positive-normalized

[Daniel Kochmański]

Hey,

> With ecl 16.1.3, I noticed that least-positive-double-float and
> least-positive-normalized-double-float are exactly equal.  This is
> allowed, but ecl can work with denormals since (/
> least-positive-normalized-double-float 10) is printed correctly.

The reason they are the same is because portable C gives us DBL_MIN at
our disposal (and its counterparts for other floats).
> 
> Maybe these two values should be different?

 Maybe we could hardcode other value when ieee-floating-point is in
featuers (fwiw it is an optional build flag). I'm not sure what would
be the right thing here.
> 
> Or maybe ecl really meant to turn on flush-to-zero so that no
> denormals can
> occur?
> 

ECL signals a floating-point-overflow/underflow conditions unless
disabled by an internal function si:trap-fpe.

Regards,
Daniel

Re: Is this thing on? Cross-compiling for ARM

[Daniel Kochmański]

Congrats! Please send me photos of the phone running ECL, I'll brag
about it on social media ;-)


> So, to follow up on this I've gotten ECL running on the SailfishOS 
> emulator.  In the end (after finding the right web page) it was
> pretty 
> easy to get shell access to the emulator and run `./configure`,
> `make` 
> and `make install` there.  Although it's a cross-compilation
> environment 
> it worked without an issue.
> 
> Now on the EQL!  (SailfishOS runs QT (but with their own layer on top
> of 
> it :-( ).)
> 
> And then try to get it running on the actual phone...
> 
> Thanks again,
> Erik
> 

Re: Is this thing on? Cross-compiling for ARM

[Daniel Kochmański]

> First of all, sorry for the horrible formatting of my initial e-
> mail.  I'm using a proper mail program now.
> 
> Secondly, thanks for the reply and apologies for the late reply: the
> year turnaround got in the way.

No worries, I figured that much :-).
> 
> "Daniel Kochmański" wrote on Sunday, 2018-12-30 20:56:
> > 
> > Alright, so the quick follow up:
> > 
> > The problem is that you try to cross-compile ECL with an older
> > version
> 
> […]
> > and all should work fine. If your toolchain doesn't have atomic_ops
> > library then build may have some problems if you need them. In that
> > case either use different flags or install said library.
> 
> Hm, I did compile the same ECL for the host before making this report
> since that was mentioned in the README (or INSTALL) but it didn't
> seem to make a difference.  So I will try your above
> suggestion.  Never thought of this since I'm not very familiar with
> with the atomic_ops stuff.

but did you "make install" the host ECL, remove build/ directory,
configure for cross compilation (once), customize ECL_TO_RUN in
build/cross_config directory and run configure and make after that?
Your error really looks like your build has picked some older ECL
version (i.e from /usr/bin/ecl if you have ECL installed from the
repositories).
> 
> As you wrote in your earlier reply about compiling on the machine
> itself: I wanted to avoid this since the Sailfish SDK offers both an
> emulator (x86) and a way to deply directly on the machine (ARM), but
> on further thought I might just go for this option.  It might
> actually make things easier instead of more difficult (which I
> initially thought).

Native compilation is always the most certain way get things working.
In any case when you succeed (or fail!) please let us know what you
did.

Best regards (and a Happy New Year!),
Daniel

Re: defsystem+ecl question

[Daniel Kochmański]

> I think I have the answer: :private-file only loads, but not compiles
> the file even if :file would, correct?
> 

As I said, I don't know defsystem well. This hypothesis makes sense
though.

Regards,
Daniel

Re: defsystem+ecl question

[Daniel Kochmański]

Hey Gunter,

I don't know mk-defsystem, but I have an idea what is wrong.

> Since 2 of the lisp files containing (defparameter) commands are
> generated by the build scripts

the short answer is that these files need to be part of the build. See
longer answer below.
> 
>  - the build process is started in the directory the output will end
> up in
>  - an (mk:add-registry-location "$(top_srcdir)/src/") informs
> defsystem
> where to find the source tree and
>  - in maxima.system all files that are in the build tree instead are
> marked as private-file:
> 
>(:module final :source-pathname ""
> ;; These are not compiled, for whatever reason
> #-ecl :load-only #-ecl t
> :components ((:file "autol")
>  (:file "max_ext")
>  :private-file "share-subdirs")
>  (:file "init-cl")
> 
> 
> This seems to work fine in sbcl, clisp, ecl, openmcl, gcl and cmucl.
> And
> with ECL maxima seems to build fine, as well. But when I start a
> maxima
> that was compiled with ECL it generates a runtime error that the
> variables share-subdirs defines are not bound.

ECL (and I'd suspect GCL has a similar problem) does not have image
save utility. That means there is no such thing as save-lisp-and-die,
so all alterations to the system (i.e from repl) at runtime are not
part of the final executable.

When building executables ECL compiles all files in a system definition
and (optionally) produces a single executable composed of these
objects. Your compilation may depend on some parameters and if you
define them from REPL, they will be available during build time, but if
you start the executable you start with bare Common Lisp and then you
add all things which are part of compiled files. If your files are only
loaded during compilation, then they are not in the "bare" image when
you start the executable. So if your application depends on some
parameters, they must be defined in one of your compiled components (or
their dependencies).

Best regards,
Daniel

Re: Loading "lparallel" hangs

[Daniel Kochmański]

Hey Robert,

I've found the issue and it is related to unwind-protect changes.
Symbol is exported from both packages, but it is the same symbol.
Problem doesn't manifest itself in this merge request[1]. Hopefully
running ECL from this unmerged branch solves your problem too. Thank
you for your persistance and investigation.

Best regards,
Daniel

[1] https://gitlab.com/embeddable-common-lisp/ecl/merge_requests/119

W dniu wto, 04.09.2018 o godzinie 20∶08 +0200, użytkownik Robert Larice
napisał:
> Hello Daniel,
> 
>   if I grep for interrupts-enabled I see both
> si::*interrupts-enabled*
>   and
> ext::*interrupts-enabled*
>   and there is at least one or two commits which did
> rename such things. perhaps there is some confusion.
> 
>   with my debian dished SLIME I've both NIL,
> si::*interrupts-enabled*
> NIL
> ext::*interrupts-enabled*
> NIL
> 
> Best Regards,
>   Robert
>   
> Daniel Kochmański  writes:
> 
> > Hey Robert,
> > 
> > nice analysis. While I have the newest ECL and the newest bordeaux-
> > threads I've tried the snippet in SLIME REPL.
> > 
> > CL-USER> si:*interrupts-enabled*
> > T
> > 
> > But when I run this snippet from console I have:
> > 
> > > si:*interrupts-enabled*
> > 
> > NIL
> > 
> > Moreover:
> > 
> > > (bt:make-thread (lambda () (print `(jd ,si:*interrupts-
> > > enabled*
> > 
> > (JD T)
> > 
> > So it is a bug in ECL - interrupts are disabled indeed in the main
> > thread by default. I'm looking into it at this very moment. Thank
> > you
> > for investigating. When fix is merged into develop branch I'll
> > notify
> > you.
> > 
> > Best regards,
> > Daniel
> > 
> > 
> > W dniu pon, 03.09.2018 o godzinie 22∶31 +0200, użytkownik Robert
> > Larice
> > napisał:
> > > Hello Daniel,
> > > 
> > >   I continued to search for the culprit.
> > >   First I tried a second machine,
> > > which showed exactly the same problem.
> > >   Thus I think you might not have used the
> > > same bordeaux thread version, I have
> > >   bordeaux-threads-v0.8.6
> > > 
> > >   The minimised snippet can be further minimised to this:
> > > (ql:quickload :bordeaux-threads)
> > > (let ((lock (bordeaux-threads:make-lock))
> > >   (cvar (bordeaux-threads:make-condition-variable)))
> > >   (bordeaux-threads:with-lock-held (lock)
> > > (handler-case (bordeaux-threads:with-timeout (0.001)
> > > (mp:condition-variable-wait cvar lock))
> > >   (bordeaux-threads:timeout () nil
> > >   and still showes the same "hang"
> > > 
> > >   Then I started to macroexpand the stuff, and saw the
> > > with-timeout depends on interrupting a thread
> > > to terminate it after timeout.
> > >   Merely guessing, I tried to wrap the whole code into a
> > > (mp:with-interrupts
> > >... )
> > >   and voila, the piece starts to work properly.
> > >   But actually, if I've glimpsed the doc correctly,
> > > the interrupts should have been enabled by default.
> > > 
> > >   Thus it seems either the bordeaux threads library is missing  
> > > a with-interrupts, or there is a bug in ecl
> > > which doesn't enable these interrupts per default.
> > > 
> > > Best Regards,
> > >   Robert
> > >   
> > > 
> > > Daniel Kochmański  writes:
> > > 
> > > > Hey Robert,
> > > > 
> > > > I can't reproduce the problem with the newest ECL code (from
> > > > git
> > > > develop branch) on my host. lparallel works fine and this
> > > > snippet
> > > > does 
> > > > terminate after timeout.
> > > > 
> > > > CL-USER> (ext:lisp-implementation-vcs-id)
> > > > "ba6e6ddde780c097918673f16c7aba05f354d022"
> > > > 
> > > > Best regards,
> > > > Daniel
> > > > 
> > > > W dniu nie, 02.09.2018 o godzinie 12∶27 +0200, użytkownik
> > > > Robert
> > > > Larice
> > > > napisał:
> > > > > I tried to understand where the issue is located.
> > > > > 
> > > > > In :lparallel file lparallel-20160825-git/src/thread-
> > > > > util.lisp
> > > > > there is a stanza which tries to check for th

Re: Loading "lparallel" hangs

[Daniel Kochmański]

Hey Robert,

nice analysis. While I have the newest ECL and the newest bordeaux-
threads I've tried the snippet in SLIME REPL.

CL-USER> si:*interrupts-enabled*
T

But when I run this snippet from console I have:

> si:*interrupts-enabled*
NIL

Moreover:

> (bt:make-thread (lambda () (print `(jd ,si:*interrupts-enabled*
(JD T)

So it is a bug in ECL - interrupts are disabled indeed in the main
thread by default. I'm looking into it at this very moment. Thank you
for investigating. When fix is merged into develop branch I'll notify
you.

Best regards,
Daniel


W dniu pon, 03.09.2018 o godzinie 22∶31 +0200, użytkownik Robert Larice
napisał:
> Hello Daniel,
> 
>   I continued to search for the culprit.
>   First I tried a second machine,
> which showed exactly the same problem.
>   Thus I think you might not have used the
> same bordeaux thread version, I have
>   bordeaux-threads-v0.8.6
> 
>   The minimised snippet can be further minimised to this:
> (ql:quickload :bordeaux-threads)
> (let ((lock (bordeaux-threads:make-lock))
>   (cvar (bordeaux-threads:make-condition-variable)))
>   (bordeaux-threads:with-lock-held (lock)
> (handler-case (bordeaux-threads:with-timeout (0.001)
> (mp:condition-variable-wait cvar lock))
>   (bordeaux-threads:timeout () nil
>   and still showes the same "hang"
> 
>   Then I started to macroexpand the stuff, and saw the
> with-timeout depends on interrupting a thread
> to terminate it after timeout.
>   Merely guessing, I tried to wrap the whole code into a
> (mp:with-interrupts
>... )
>   and voila, the piece starts to work properly.
>   But actually, if I've glimpsed the doc correctly,
> the interrupts should have been enabled by default.
> 
>   Thus it seems either the bordeaux threads library is missing  
> a with-interrupts, or there is a bug in ecl
>     which doesn't enable these interrupts per default.
> 
> Best Regards,
>   Robert
>   
> 
> Daniel Kochmański  writes:
> 
> > Hey Robert,
> > 
> > I can't reproduce the problem with the newest ECL code (from git
> > develop branch) on my host. lparallel works fine and this snippet
> > does 
> > terminate after timeout.
> > 
> > CL-USER> (ext:lisp-implementation-vcs-id)
> > "ba6e6ddde780c097918673f16c7aba05f354d022"
> > 
> > Best regards,
> > Daniel
> > 
> > W dniu nie, 02.09.2018 o godzinie 12∶27 +0200, użytkownik Robert
> > Larice
> > napisał:
> > > I tried to understand where the issue is located.
> > > 
> > > In :lparallel file lparallel-20160825-git/src/thread-util.lisp
> > > there is a stanza which tries to check for the implementation
> > >   of the :timeout capability
> > > 
> > > > ;;; Check for timeout parameter in bordeaux-threads:condition-
> > > > wait.
> > > > (eval-when (:compile-toplevel :execute)
> > > >   ;; use special to defeat compiler analysis
> > > >   (defparameter *condition-wait* #'bordeaux-threads:condition-
> > > > wait)
> > > > 
> > > >   (flet ((has-condition-wait-timeout-p ()
> > > >   ...
> > > 
> > > I tried to minimise this to a small standalone piece
> > > which can be used to examine the issue:
> > > 
> > > (ql:quickload :bordeaux-threads)
> > > 
> > > (let ((lock (bordeaux-threads:make-lock))
> > >   (cvar (bordeaux-threads:make-condition-variable)))
> > >   (bordeaux-threads:with-lock-held (lock)
> > > (bordeaux-threads:condition-wait cvar lock :timeout 0.001)))
> > > 
> > > I think the :timeout doesn't seem to work properly and thus the
> > >   condition-wait waits forever.
> > > 
> > > Can you help me to understand this better and to work around it ?
> > > 
> > > Regards
> > >   Robert Larice
> > > 
> > > 
> > > Robert Larice  writes:
> > > 
> > > > Hello,
> > > > 
> > > >   can you provide me some hints for the following problem ?
> > > > 
> > > >   I've compiled ecl from git on a debian stretch machine.
> > > >   Then I've tried to compile the "qt" example,
> > > > which did hang when loading "lparallel"
> > > >   So I started "ecl" from a shell,
> > > >   and did execute
> > > > (ql:quickload :lparallel)
> > > >   which presents me:
> > > >   > To load "lparallel":
> > > >   > Load 1 ASDF system:
> > > >   >   lparallel
> > > >   > ; Loading "lparallel"
> > > >   then the process fell silent.
> > > >   "top" doesn't show "ecl" to consume cpu cycles.
> > > >   Its waiting for something and doesn't proceed.
> > > > 
> > > > Regards,
> > > >   Robert Larice

Re: Loading "lparallel" hangs

[Daniel Kochmański]

Hey Robert,

I can't reproduce the problem with the newest ECL code (from git
develop branch) on my host. lparallel works fine and this snippet does 
terminate after timeout.

CL-USER> (ext:lisp-implementation-vcs-id)
"ba6e6ddde780c097918673f16c7aba05f354d022"

Best regards,
Daniel

W dniu nie, 02.09.2018 o godzinie 12∶27 +0200, użytkownik Robert Larice
napisał:
> I tried to understand where the issue is located.
> 
> In :lparallel file lparallel-20160825-git/src/thread-util.lisp
> there is a stanza which tries to check for the implementation
>   of the :timeout capability
> 
> > ;;; Check for timeout parameter in bordeaux-threads:condition-wait.
> > (eval-when (:compile-toplevel :execute)
> >   ;; use special to defeat compiler analysis
> >   (defparameter *condition-wait* #'bordeaux-threads:condition-wait)
> > 
> >   (flet ((has-condition-wait-timeout-p ()
> >   ...
> 
> I tried to minimise this to a small standalone piece
> which can be used to examine the issue:
> 
> (ql:quickload :bordeaux-threads)
> 
> (let ((lock (bordeaux-threads:make-lock))
>   (cvar (bordeaux-threads:make-condition-variable)))
>   (bordeaux-threads:with-lock-held (lock)
> (bordeaux-threads:condition-wait cvar lock :timeout 0.001)))
> 
> I think the :timeout doesn't seem to work properly and thus the
>   condition-wait waits forever.
> 
> Can you help me to understand this better and to work around it ?
> 
> Regards
>   Robert Larice
> 
> 
> Robert Larice  writes:
> 
> > Hello,
> > 
> >   can you provide me some hints for the following problem ?
> > 
> >   I've compiled ecl from git on a debian stretch machine.
> >   Then I've tried to compile the "qt" example,
> > which did hang when loading "lparallel"
> >   So I started "ecl" from a shell,
> >   and did execute
> > (ql:quickload :lparallel)
> >   which presents me:
> >   > To load "lparallel":
> >   > Load 1 ASDF system:
> >   >   lparallel
> >   > ; Loading "lparallel"
> >   then the process fell silent.
> >   "top" doesn't show "ecl" to consume cpu cycles.
> >   Its waiting for something and doesn't proceed.
> > 
> > Regards,
> >   Robert Larice
> 
> 

Re: defstruct :predicate failure

[Daniel Kochmański]

In both cases (ECL built from the tag and your install from the HEAD) 
make sure you remove previous ECL and its cache with FASLs. It might be 
that you use wrong library in your system (i.e two libecl libraries are 
installed, or FASL from incompatible version is loaded).


Regards,
Daniel


On 09.05.2018 07:09, Peter Keller wrote:

On 05/08/2018 11:03 PM, Andrew Kirkpatrick wrote:

Interestingly I cannot reproduce it. I'm running Linux Mint 18.2 and
built ECL from a git checkout of the tag ECL-16.1.3:

$ /opt/ecl/bin/ecl
;;; Loading "/home/spacebat/quicklisp/setup.lisp"
;;; Loading #P"/opt/ecl/lib/ecl-16.1.3/asdf.fas"
ECL (Embeddable Common-Lisp) 16.1.3
(git:17645d703eb95b9452186015f5f3a1a9c0bc6b6a)
Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
Copyright (C) 1993 Giuseppe Attardi
Copyright (C) 2000 Juan J. Garcia-Ripoll
Copyright (C) 2016 Daniel Kochmanski
ECL is free software, and you are welcome to redistribute it
under certain conditions; see file 'Copyright' for details.
Type :h for Help.
Top level in: #.

(defstruct (foo (:type vector) (:predicate nil)) qux bar)

FOO


(make-foo :qux "q" :bar "b")

#("q" "b")


However if I install ECL via apt, I get an older version with this banner:

ECL (Embeddable Common-Lisp) 15.3.7 (git:UNKNOWN)

The error you describe is then evident.

I suspect the tagged version and the actual release are different, but
it seems it is moot.

I was not the only person to discover this bug:

https://gitlab.com/embeddable-common-lisp/ecl/issues/385

It turns out it is fixed on the head of ecl (and maybe by the time that
tag was actually made, too).

When I switched to the head of ECL, the described problem went away.

Sadly, another problem showed up, this time trying to load fare-utils
from the most recent edition of Quicklisp.


Linux violet > ecl
;;; Loading "/home/psilord/quicklisp/setup.lisp"
;;; Loading #P"/usr/local/lib/ecl-16.1.3/asdf.fas"
ECL (Embeddable Common-Lisp) 16.1.3 
(git:e3b9919ffaddbeb8d5f16c394fb70b813c5f0d94)
Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
Copyright (C) 1993 Giuseppe Attardi
Copyright (C) 2000 Juan J. Garcia-Ripoll
Copyright (C) 2016 Daniel Kochmanski
ECL is free software, and you are welcome to redistribute it
under certain conditions; see file 'Copyright' for details.
Type :h for Help.
Top level in: #.

(ql:quickload :fare-utils)

To load "fare-utils":
   Load 1 ASDF system:
 fare-utils
; Loading "fare-utils"
;;;
;;; Compiling
/home/psilord/quicklisp/dists/quicklisp/software/fare-utils-20170124-git/base/utils.lisp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
.
;;; Error:
;;;   in file utils.lisp, position 4443
;;;   at (EXPORTING-DEFINITIONS (DEFMACRO DEFINE-EXPORTER ...) ...)
;;;   * The macro form (EXPORTING-DEFINITIONS (DEFMACRO DEFINE-EXPORTER
(EXPORTER DEFINER) `(DEFMACRO ,EXPORTER (SYMBOL  ARGS) `(PROGN (,',DEFINER
,SYMBOL ,@ARGS) (ENSURE-SYMBOL-EXPORTED ,SYMBOL (DEFINE-EXPORTER
DEFINE*-EXPORTER DEFINE-EXPORTER) (DEFINE-EXPORTER DEF*CLASS DEFCLASS)
(DEFINE-EXPORTER DEF*CONSTANT DEFCONSTANT) (DEFINE-EXPORTER DEF*GENERIC
DEFGENERIC) (DEFINE-EXPORTER DEFINE*-COMPILER-MACRO DEFINE-COMPILER-MACRO)
(DEFINE-EXPORTER DEFINE*-CONDITION DEFINE-CONDITION) (DEFINE-EXPORTER
DEFINE*-METHOD-COMBINATION DEFINE-METHOD-COMBINATION) (DEFINE-EXPORTER
DEFINE*-MODIFY-MACRO DEFINE-MODIFY-MACRO) (DEFINE-EXPORTER
DEFINE*-SETF-EXPANDER DEFINE-SETF-EXPANDER) (DEFINE-EXPORTER
DEFINE*-SYMBOL-MACRO DEFINE-SYMBOL-MACRO) (DEFINE-EXPORTER DEF*MACRO DEFMACRO)
(DEFINE-EXPORTER DEF*METHOD DEFMETHOD) (DEFINE-EXPORTER DEF*PACKAGE DEFPACKAGE)
(DEFINE-EXPORTER DEF*PARAMETER DEFPARAMETER) (DEFINE-EXPORTER DEF*SETF DEFSETF)
(DEFINE-EXPORTER DEF*STRUCT DEFSTRUCT) (DEFINE-EXPORTER DEF*TYPE DEFTYPE)
(DEFINE-EXPORTER DEF*FUN DEFUN) (DEFINE-EXPORTER DEF*VAR DEFVAR)) was not
expanded successfully.
;;; Error detected:
;;; GO: The tagbody 2875 is missing.
Condition of type: COMPILE-FILE-ERROR
COMPILE-FILE-ERROR while compiling #

Available restarts:

1. (RETRY) Retry compiling #.
2. (ACCEPT) Continue, treating compiling # as having been successful.
3. (RETRY) Retry ASDF operation.
4. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the
configuration.
5. (ABORT) Give up on "fare-utils"
6. (RESTART-TOPLEVEL) Go back to Top-Level REPL.

Broken at SI:BYTECODES. [Evaluation of: (QUICKLISP-CLIENT:QUICKLOAD
:FARE-UTILS)] In: #.




I appreciate you had spent some time looking into the :predicate bug.

Thank you!

-pete

Re: defstruct :predicate failure

[Daniel Kochmański]

Hey,

thank you for the report. This issue has been fixed around a year ago: 
b6a4d4a85148dfc0561981e7e65fcf2224ddb2a2
(reported here: 
https://gitlab.com/embeddable-common-lisp/ecl/issues/385). This change 
is not
part of the release yet (fix was applied in 2017-05-30 while 16.1.3 was 
released in 2016-12-19).


If you are interested what we want to solve before we release 16.2.0 you 
may check out the
milestone in here: 
https://gitlab.com/embeddable-common-lisp/ecl/issues?milestone_title=ECL+16.2.0


Best regards,
Daniel


(defstruct (foo (:type vector) (:predicate nil)) qux bar)

Re: A few basic Lisp commands while in debugger (gdb)?

[Daniel Kochmański]

Hey Paul,

check out src/util/gdbinit, I think that this is the file you are 
referring to.


Regards,

Daniel


On 01.02.2018 11:16, PR wrote:

Hi,

I remember vaguely that there have been added a few useful, simple
functions for Lisp, which can be used during a gdb session, but I
can't currently find them...

Could anybody please point me to them?

Thanks,

Paul


P.S. This would probably help debugging an android thread issue,
happening only on a few recent devices; at least I already figured how
to run gdbserver on android, and debug from the PC.

Re: ASDF 3.1.1 is released

[Daniel Kochmański]

Happily we are safe, because we didn't update to 3.3.0 in a first place. 
Thank you for head-ups though. Congrats on a new release.



On 15.11.2017 15:27, Robert Goldman wrote:


Here is the announcement. Because this fixes a backwards-compatibility 
bug, we strongly encourage you to replace 3.3.0 with 3.3.1 in your 
implementations.


Best regards,
Robert

Today we release ASDF 3.3.1, the first bugfix release for the 3.3.0 
release series. Of primary interest in this release are


1.

a fix for an incompatibility in the UIOP stamp-comparison
functions. The handling of infinity as a bound in these functions
changed between 3.2 and 3.3, potentially causing problems in
backward compatibility. In order to maintain compatibility, the
old behavior was restored to the stamp-comparison functions, and
new functions -- TIMEstamp comparison functions -- were added to
carry the new behaviors.

2.

a fix for upgrade from version 3.2.1

3.

fixes for bugs that can occur when the default readtable is
manipulated inside a dependency loaded by DEFSYSTEM-DEPENDS-ON.

We urge implementations that are currently bundling previous versions 
of ASDF -- and especially those bundling 3.3.0 -- to upgrade to 3.3.1 
at their earliest convenience.


Here is the changelog entry for 3.3.1:

cl-asdf (2:3.3.167-1) unstable; urgency=low

New milestone:
* UIOP compatibility fix: Introduced new replacement "timestamp"
comparison functions, because of inadvertent change in the
API. Functions that are compatible with the old semantics are retained
as "stamp" comparison functions, but will eventually be deprecated.
* Upgrade fix: Upgrade from 3.2.1 needed repair.
* Syntax manipulation: Fix for bugs that could be introduced when the
default readtable was manipulated during the loading of a
defsystem-depends-on system.
* Tests: tests for new capabilities and bugs
* Documentation: a number of improvements and clarifications.

Re: 16.1.3 mingw-w64-x86_64 build error

[Daniel Kochmański]

Hey Dave,

thanks for taking your time to let us know. We have some read-time 
conditionals for mingw32 (and no for mingw64), so this is something to 
expect.


This issue doesn't look like a hard thing to fix, though I'm not using 
Windows machine frequently (only before the release, to test and fix 
regressions) - so I won't fix it immedietely. If nobody takes this task, 
I will fix it myself before the 16.2.0 release. I've created issue for 
it here:


https://gitlab.com/embeddable-common-lisp/ecl/issues/411

Best regards,

Daniel


On 22.10.2017 18:25, Dave Richards wrote:

I ran configure and only provided the --prefix argument.  The 32-bit build
worked fine, but the 64-bit build failed, see below.

Dave

cd build; make
make[1]: Entering directory '/c/Dave/ecl-16.1.3/build'
Building libeclmin.a...
Building ecl_min.exe...
;*** Lisp core booted 
ECL (Embeddable Common Lisp)

;;;
;;; Welcome to bare.lsp. Let's bring this instance up!
;;;
;;;
;;; About to load lsp/load.lsp
;;;
;;; Loading src:lsp;export.lsp
;;; Unhandled lisp initialization error
;;; Message:
FILE-ERROR
;;; Arguments:
(:PATHNAME #P"SRC:LSP;EXPORT.LSP.NEWEST")
Internal or unrecoverable error in:

Lisp initialization error.


This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
make[1]: *** [Makefile:241: bin/ecl.exe] Error 3
make[1]: Leaving directory '/c/Dave/ecl-16.1.3/build'
make: *** [Makefile:72: all] Error 2

Re: ECL and musl

[Daniel Kochmański]

Hey,

I'll update bundled GC before next release. One of the valid scenarios 
where bundling GC with ECL makes sense is static linking (and ECL 
supports that – when GC is bundled it is statically linked and none of 
its symbols are exported). I've also found it handy, when I was buidling 
ECL on NetBSD, which shipped only non-threaded build of bdwgc.


Note, that ECL first looks for system GC and if it can be used – it is.

Regards,

Daniel


On 20.10.2017 19:44, Dima Pasechnik wrote:
The bundled GC is too old; it's not working in the embedded ECL 
situation on FreeBSD (see https://github.com/ivmai/bdwgc/issues/180 
for a very fresh fix to this), or in at least one dynamic C library 
case on OSX I know about (see https://github.com/miguelmarco/libhomfly).


In general, I don't see the value of bundling with ECL an old snapshot 
of a relatively popular and actively maintained library.
(removing it is trivial - there is one script from bdwgc/ that is 
used, and should be copied, the rest can go...)


Just my 0.02c.
Dima




On Thu, Oct 12, 2017 at 5:12 PM, Daniel Kochmański 
<dan...@turtleware.eu <mailto:dan...@turtleware.eu>> wrote:


Hey,

your problem is related to bundled libgc. We have some
conditionalization for musl, so I'm sure it worked in the past.
I'd suggest trying to install libgc from alpine repositories and
build ECL against that libgc. If Alpine doesn't have libgc in the
repositories, I'd try building upstream bdwgc and linking ECL with
it. If it doesn't build, report a bug on bdwgc project, if it does
– please let us know here so we'll update bundled libgc to the
working version.

Best regards,

Daniel


On 12.10.2017 18:03, Lucas Ramage wrote:

Hello,

I am attempting to package ecl for alpine linux and I am having
troubles compiling against musl.

Building ecl_min...

.//libeclgc.a(mach_dep.o): In function `GC_with_callee_saves_pushed':

/root/ecl-16.1.3/src/bdwgc/mach_dep.c:245: undefined reference to
`getcontext'

collect2: error: ld returned 1 exit status

make[1]: *** [Makefile:224: ecl_min] Error 1

make[1]: Leaving directory '/root/ecl-16.1.3/build'

make: *** [Makefile:72: all] Error 2

​
I tried `make CFLAGS='-DNO_GETCONTEXT'`​ but that did not work
either.

Has anyone successfully built ecl using musl?


-- 
Regards,


Visit online journal <https://lramage94.github.io/>



*Lucas Ramage* / Software Engineer
ramage.lu...@openmailbox.org
<mailto:ramage.lu...@openmailbox.org> / (941) 404-6794
<tel:%28941%29%20404-6794>

*PGP Fingerprint* / Learn More <https://emailselfdefense.fsf.org/en/>
EAE7 45DF 818D 4948 DDA7 0F44 F52A 5A96 7B9B 6FB7
<https://pgp.mit.edu/pks/lookup?op=get=0xF52A5A967B9B6FB7>

*Visit online journal*
http://lramage94.github.io <https://lramage94.github.io/>

Github <https://github.com/lramage94>Linkedin
<https://www.linkedin.com/in/lramage94>

Re: ECL and musl

[Daniel Kochmański]

Hey,

your problem is related to bundled libgc. We have some 
conditionalization for musl, so I'm sure it worked in the past. I'd 
suggest trying to install libgc from alpine repositories and build ECL 
against that libgc. If Alpine doesn't have libgc in the repositories, 
I'd try building upstream bdwgc and linking ECL with it. If it doesn't 
build, report a bug on bdwgc project, if it does – please let us know 
here so we'll update bundled libgc to the working version.


Best regards,

Daniel


On 12.10.2017 18:03, Lucas Ramage wrote:

Hello,

I am attempting to package ecl for alpine linux and I am having 
troubles compiling against musl.


Building ecl_min...

.//libeclgc.a(mach_dep.o): In function `GC_with_callee_saves_pushed':

/root/ecl-16.1.3/src/bdwgc/mach_dep.c:245: undefined reference to 
`getcontext'


collect2: error: ld returned 1 exit status

make[1]: *** [Makefile:224: ecl_min] Error 1

make[1]: Leaving directory '/root/ecl-16.1.3/build'

make: *** [Makefile:72: all] Error 2

​
I tried `make CFLAGS='-DNO_GETCONTEXT'`​ but that did not work either.

Has anyone successfully built ecl using musl?


--
Regards,

Visit online journal 



*Lucas Ramage* / Software Engineer
ramage.lu...@openmailbox.org  / 
(941) 404-6794 


*PGP Fingerprint* / Learn More 
EAE7 45DF 818D 4948 DDA7 0F44 F52A 5A96 7B9B 6FB7 



*Visit online journal*
http://lramage94.github.io 

Github Linkedin 

Re: Help.doc loading in Binary

[Daniel Kochmański]

Hey,


here is a patch which will probably work for you (not tested):

-- cut here--

diff --git a/src/lsp/helpfile.lsp b/src/lsp/helpfile.lsp
index 09c7cb32..62e6985a 100644
--- a/src/lsp/helpfile.lsp
+++ b/src/lsp/helpfile.lsp
@@ -18,18 +18,18 @@
  Documentation system
 

-#+ecl-min
+;#+ecl-min
 (progn
   (*make-special '*documentation-pool*)
   (setq *documentation-pool* nil)
   (*make-special '*keep-documentation*)
   (setq *keep-documentation* t))
-#-ecl-min
-(progn
-  (setq *documentation-pool*
-    (list (make-hash-table :test #'equal :size 128)
-  "SYS:help.doc"))
-  (defparameter *keep-documentation* t))
+;; #-ecl-min
+;; (progn
+;;   (setq *documentation-pool*
+;; (list (make-hash-table :test #'equal :size 128)
+;;   "SYS:help.doc"))
+;;   (defparameter *keep-documentation* t))

 (defun new-documentation-pool ( (size 1024))
   "Args: ( hash-size)

--cut here--

regards,

Daniel


On 05.10.2017 05:29, John Mercouris wrote:

Hello everyone, I’m running ECL + EQL 16.1.3, Mac OS High Sierra

I can produce a binary with ECL, but I have an issue, when I try to run it on 
anybody’s computer: I get the following:

--

Condition of type: FILE-ERROR
Filesystem error with pathname “SYS:help.doc”.
Either
   1) the file does not exist, or
   2) we are not allowed to access the file, or
   3) the pathname points to a broken symbolic link.
No restarts available.

Top level in: #.
--

I’ve determined that the cause of this error is a file missing at: 
/usr/local/lib/ecl-16.1.3/help.doc

I’ve been able to get binary files to work on other people’s machines by 
copying the help.doc file to the appropriate
dir. Unfortunately this is not a practical solution for distribution.

Is there any way to tell ECL to not attempt to load this file? Any patch I can 
apply to the source? Thanks,

-John

Re: Android question: how to connect to swank, running on android?

[Daniel Kochmański]

Hm, I was able to reproduce it after all. It seems, that condition wait 
on ECL is prone to race conditions.


I've written alternative implementation using mailboxes, could you check 
with slime taken from https://github.com/dkochmanski/slime ? It seems to 
work for me, but before I make another pull request I want to double check.


Regards,

Daniel


On 29.09.2017 12:07, Daniel Kochmański wrote:

Hello,

Thanks for the report. Regarding bad news, can your confirm that this 
still happening with ecl from development branch?


Best regards,
Daniel

On 24.09.2017 16:04, PR wrote:

2017-09-03 1:22 GMT+02:00, PR <polos.ru...@gmail.com>:

...

Hi again,

so let's disentangle some confusion (partially created by me, sorry 
for that):


I have good news (for android) and bad news (for current Slime v2.20):


* First the good one:

I found out that old Slime v2.19 is stable on android (even though it
needs a tiny patch, as mentioned in an earlier mail).
(So, what I'm currently doing in EQL5-Android is to include a patched
Slime v2.19, just to be safe)


* Now the bad news, _not_ related to android (and I can't be the only
one experimenting this...):

With current Slime v2.20, the Slime REPL will freeze occasionally,
especially if the response from Swank takes some time to compute, e.g.
with TAB completion. What causes the "freezing" is a segfault in ECL:

I ran ECL through gdb, and the segfault seems related to GC (see
attachment for the full backtrace). I was provoking the freezing with
TAB completion (and it took me a few minutes to have it occur).

If my subjective observations match reality, then this is caused when
a GC is triggered during a Slime REPL command, waiting for a response
from Swank (since these pauses are mostly very short, that coincidence
doesn't happen very often).

This problem definitely doesn't happen in Slime version v2.19, and
it's not related to the new :SPAWN mode, because it happens even with
:style NIL (the fallback communication style).

Paul

Re: Android question: how to connect to swank, running on android?

[Daniel Kochmański]

Hello,

Thanks for the report. Regarding bad news, can your confirm that this 
still happening with ecl from development branch?


Best regards,
Daniel

On 24.09.2017 16:04, PR wrote:

2017-09-03 1:22 GMT+02:00, PR :

...

Hi again,

so let's disentangle some confusion (partially created by me, sorry for that):

I have good news (for android) and bad news (for current Slime v2.20):


* First the good one:

I found out that old Slime v2.19 is stable on android (even though it
needs a tiny patch, as mentioned in an earlier mail).
(So, what I'm currently doing in EQL5-Android is to include a patched
Slime v2.19, just to be safe)


* Now the bad news, _not_ related to android (and I can't be the only
one experimenting this...):

With current Slime v2.20, the Slime REPL will freeze occasionally,
especially if the response from Swank takes some time to compute, e.g.
with TAB completion. What causes the "freezing" is a segfault in ECL:

I ran ECL through gdb, and the segfault seems related to GC (see
attachment for the full backtrace). I was provoking the freezing with
TAB completion (and it took me a few minutes to have it occur).

If my subjective observations match reality, then this is caused when
a GC is triggered during a Slime REPL command, waiting for a response
from Swank (since these pauses are mostly very short, that coincidence
doesn't happen very often).

This problem definitely doesn't happen in Slime version v2.19, and
it's not related to the new :SPAWN mode, because it happens even with
:style NIL (the fallback communication style).

Paul

Re: "Got signal before environment was installed on our thread"

[Daniel Kochmański]

On 22.09.2017 13:31, Dima Pasechnik wrote:

No, we have not done that before, and everything worked on Linux and
OSX, and even on Cygwin (that is to say, we were lucky with threads
implementations on these platforms, depending on some sort of
undefined behaviour). Now I am trying
ecl_import_current_thread/ecl_release_current_thread on FreeBSD, and
it certainly appears to be the right direction, but I have a couple of
questions, at least one of them related to signal handling.

0) any advice on signal flags to be set to certain values?
Namely, ECL_OPT_SIGNAL_HANDLING_THREAD and
ECL_OPT_THREAD_INTERRUPT_SIGNAL? They seem to affect
the setup quite a bit; I had to do some trial and error, setting the
former to 1 and the latter to 67 (probably OS-specific value) seemed
to have done the trick...

1) as ECL must be built with --enable-threads, does it mean
that it will also try to spawn threads on its own?
(so far we always used to --disable-threads; for debugging purposes
I'd rather not let ECL run its own threads)

[I'd say this is a documentation issue, too, as it's not clear what
exactly --enable-threads is doing: enabling own ECL's threads, or
enabling ECL embedding in a multithreaded program, or both?]
--enable-threads gives ECL ability to use threads (i.e programmer may 
create his own
thread in Lisp program). ECL may be embedded in any scenario (having 
both threads enabled
and disabled), but if threads for ECL are disabled, than it is calling 
program responsibility to
assure that ECL is accessed synchronously (i.e no two functions in ECL 
at the same time are called).


ECL_OPT_SIGNAL_HANDLING_THREAD is a flag, which when set to 1 makes ECL 
create
a separate thread meant for handling signals (so ECL in that case runs 
two threads). If

ECL has threads disabled, then this flag does nothing.


2) for some reason calling ecl_release_current_thread()
leads to a nasty  crash, with lines like

 frame #299974: 0x000883a52463
libecl.so.16.1`FElibc_error(msg="", narg=0) at error.d:490
 frame #299975: 0x000883ab3e2c libecl.so.16.1`ecl_process_env
at process.d:70
 frame #299976: 0x000883aba9d4
libecl.so.16.1`ecl_alloc_compact_object(t=t_base_string,
extra_space=12) at alloc_2.d:622
 frame #299977: 0x000883a8c782
libecl.so.16.1`ecl_alloc_simple_vector(l=11, aet=ecl_aet_bc) at
array.d:585
 frame #299978: 0x000883a5331d
libecl.so.16.1`make_base_string_copy(s="No error: 0") at string.d:136
 frame #299979: 0x000883a52320
libecl.so.16.1`_ecl_strerror(code=0) at error.d:475
 frame #299980: 0x000883a52463

repeating endlessly in the backtrace.
Must it be called at all?
(The test program in examples you pointed at does work for me, with
few makefile changes...)



3) How does one call cl_boot() in such a multithreaded setting? I
tried merely putting the call to

ecl_import_current_thread()

before the call to

cl_boot()

but I get an error from GC:

"Threads explicit registering is not previously enabled"
and the program aborts.
Without doing ecl_import_current_thread(), cl_boot() succeeds in "main" thread,
but coredumps if invoked from another thread---this is the behaviour
you mistook for another instance of GC kicking in)

While we probably can live with cl_boot() always being called in the
main thread, this would be an extra burden to implement...

ecl_import_current_thread and ecl_release_current_thread needs to be called
in threads, which call ECL and are different than thread where cl_boot 
is called.
For the thread where cl_boot was called you don't call import/release, 
they are
implicit for cl_boot / cl_shutdown. You may run cl_boot in thread not 
being main

one, that's not the issue.


4) GC_THREADS is #define'd both in ECL and in GC headers.
This seems wrong to me.

No idea why it is that way. I'll keep in mind investigating that.

Regards,
Daniel

Re: "Got signal before environment was installed on our thread"

[Daniel Kochmański]

From the backtrace it is sure that fail is caused inside the call to 
GC_init. Such errors are known to have happened when another GC was 
initialized already on the system (I've linked the issue). It might be 
caused by something else in bdwgc, I don't know. Either way I'd focus on 
GC_init part.


To make sure, that I'm right with my assertion you may put printf before 
and after call to GC_init. I'm not quite familiar with bdwgc internals 
to say, what is wrong though. Maybe updating bundled sources of GC will 
help? Or linking with libgc on the system? It might be that it was a bug 
in bdwgc which got already fixed.


Regards,

Daniel


On 04.09.2017 12:04, Dima Pasechnik wrote:

On Fri, Sep 1, 2017 at 1:57 PM, Daniel Kochmański <dan...@turtleware.eu> wrote:

I dont think its related to shared vs static - rather two gc running
concurrently. Try commenting out GC_init call in ecl and see what happens.

I don't understand how two GCs can run concurrently on a memory region
controlled by ECL which is statically linked to GC...
In fact I am pretty sure no other instances of GC are running anywhere
within our process tree.

By the way, I don't know whether it's obvious from the backtrace that
cl_boot() has been completed, or not.

If it actually was completed, could it be a bug that invalidates the
bit indicating that cl_boot() has been done?

We have seen similar troubles with clang recently, related to FPE.
There an FPE bit was flipped by assignment of a double to an
integer type (sic!).
It took us a lot of head banging on various hard surfaces to debug this:
https://trac.sagemath.org/ticket/22799
it turned out we did hit a known bug:
https://bugs.llvm.org//show_bug.cgi?id=17686


Do you need sigchld for anything? Run-program was rewritten and sigchld
handling wasnt viable option anymore for it.


We do set ECL_OPT_TRAP_SIGCHLD to 0, thus I presume we
now can simply skip it all together.

Thanks,
Dima


Im on phone, will be avail after the weekend.

Regards, D.


Dnia 1 września 2017 14:47:57 CEST, Dima Pasechnik <dimpase+...@gmail.com>
napisał(a):

Hi Daniel,
Thanks for the message. The scenario you talk about only happens if GC
is a shared library, right?

I've rebuilt GC disabling shared libs, and ECL doing static linking to GC.
And I still get very similar segfaults:

;;; ECL C Backtrace
;;;0 ecl_internal_error (0x87d79b375)
;;;1 init_unixint (0x87d7c17e0)
;;;2 init_unixint (0x87d7c1582)
;;;3 pthread_sigmask (0x80103779d)
;;;4 pthread_getspecific (0x801036d6f)
;;;5 unknown (0x7193)
;;;6 GC_push_current_stack (0x87d7ef7c3)
;;;7 GC_with_callee_saves_pushed (0x87d7f7360)
;;;8 GC_push_roots (0x87d7ef9c2)
;;;9 GC_mark_some (0x87d7ec97c)
;;;   10 GC_stopped_mark (0x87d7e6b7a)
;;;   11 GC_try_to_collect_inner (0x87d7e6a75)
;;;   12 GC_init (0x87d7f08ea)
;;;   13 init_alloc (0x87d7d5669)
;;;   14 cl_boot (0x87d69f66b)
...

And a very similar picture on the develop branch of ECL - although
I had to change our code, as  in particular
ECL_OPT_TRAP_SIGCHLD is gone...

So, what can it be? Some signals issue?

Thanks,
Dima

On Fri, Sep 1, 2017 at 7:38 AM, Daniel Kochmański <dan...@turtleware.eu>
wrote:

  Hey Dima,

  this looks like the issue with having GC initialized before ECL kicks
in.
  See https://gitlab.com/embeddable-common-lisp/ecl/issues/371 for a
  discussion about this problem. Basically some other component already
called
  GC_init and ECL calls it once more. It's arguably not a bug.

  Best regards,

  Daniel


  On 31.08.2017 15:29, Dima Pasechnik wrote:


  Dear all,

  I'm struggling to understand strange segfaults coming from
  ECL(+Maxima) on FreeBSD embedded into Python; they typically look as
  follows:

  Got signal before environment was installed on our thread
 [2: No such file or directory]

  ;;; ECL C Backtrace
  ;;;0 ecl_internal_error (0x87d790765)
  ;;;1 init_unixint (0x87d7b6bd0)
  ;;;2 init_unixint (0x87d7b6972)
  ;;;3 pthread_sigmask (0x80103779d)
  ;;;4 pthread_getspecific (0x801036d6f)
  ;;;5 unknown (0x7193)
  ;;;6 GC_push_all_stacks (0x87db1ea2c)
  ;;;7 GC_mark_some (0x87db12eec)
  ;;;8 GC_stopped_mark (0x87db09baa)
  ;;;9 GC_try_to_collect_inner (0x87db09a75)
  ;;;   10 GC_init (0x87db16f4f)
  ;;;   11 init_alloc (0x87d7caa59)
  ;;;   12 cl_boot (0x87d694a5b)
  ;;;   13 initecl (0x87d218340)
  ;;;   14 initecl (0x87d20a43f)
  ;;;   15 initecl (0x87d207e28)
  ;;;   16 _PyImport_LoadDynamicModule (0x800b3ed1c)
  ;;;   17 PyImport_AppendInittab (0x800b3d71f)
  ;;;   18 PyImport_AppendInittab (0x800b3d1a8)
  ;;;   19 PyImport_ImportModuleLevel (0x800b3c2ce)
  ;;;   20 _PyBuiltin_Init (0x800b162d7)
  ;;;   21 PyObject_Call (0x800a7d3e3)
  ;;;   22 PyEval_EvalFrameEx (0x800b2121c)
  ;;;   23 PyEval_EvalCodeEx (0x800b1b5d4)
  ;;;   24 PyEval_EvalCode (0x800b1ad96)
  ;;;   25 PyImport_ExecCodeModuleEx (0x800b3ad11)
  ;;;   26 PyImport_AppendInittab (0x800

Re: "Got signal before environment was installed on our thread"

[Daniel Kochmański]

I dont think its related to shared vs static - rather two gc running 
concurrently. Try commenting out GC_init call in ecl and see what happens.

Do you need sigchld for anything? Run-program was rewritten and sigchld 
handling wasnt viable option anymore for it.

Im on phone, will be avail after the weekend.

Regards, D.

Dnia 1 września 2017 14:47:57 CEST, Dima Pasechnik <dimpase+...@gmail.com> 
napisał(a):
>Hi Daniel,
>Thanks for the message. The scenario you talk about only happens if GC
>is a shared library, right?
>
>I've rebuilt GC disabling shared libs, and ECL doing static linking to
>GC.
>And I still get very similar segfaults:
>
> ECL C Backtrace
>0 ecl_internal_error (0x87d79b375)
>1 init_unixint (0x87d7c17e0)
>2 init_unixint (0x87d7c1582)
>3 pthread_sigmask (0x80103779d)
>4 pthread_getspecific (0x801036d6f)
>5 unknown (0x7193)
>6 GC_push_current_stack (0x87d7ef7c3)
>7 GC_with_callee_saves_pushed (0x87d7f7360)
>8 GC_push_roots (0x87d7ef9c2)
>9 GC_mark_some (0x87d7ec97c)
>   10 GC_stopped_mark (0x87d7e6b7a)
>   11 GC_try_to_collect_inner (0x87d7e6a75)
>   12 GC_init (0x87d7f08ea)
>   13 init_alloc (0x87d7d5669)
>   14 cl_boot (0x87d69f66b)
>...
>
>And a very similar picture on the develop branch of ECL - although
>I had to change our code, as  in particular
>ECL_OPT_TRAP_SIGCHLD is gone...
>
>So, what can it be? Some signals issue?
>
>Thanks,
>Dima
>
>On Fri, Sep 1, 2017 at 7:38 AM, Daniel Kochmański
><dan...@turtleware.eu> wrote:
>> Hey Dima,
>>
>> this looks like the issue with having GC initialized before ECL kicks
>in.
>> See https://gitlab.com/embeddable-common-lisp/ecl/issues/371 for a
>> discussion about this problem. Basically some other component already
>called
>> GC_init and ECL calls it once more. It's arguably not a bug.
>>
>> Best regards,
>>
>> Daniel
>>
>>
>> On 31.08.2017 15:29, Dima Pasechnik wrote:
>>>
>>> Dear all,
>>>
>>> I'm struggling to understand strange segfaults coming from
>>> ECL(+Maxima) on FreeBSD embedded into Python; they typically look as
>>> follows:
>>>
>>> Got signal before environment was installed on our thread
>>>[2: No such file or directory]
>>>
>>> ;;; ECL C Backtrace
>>> ;;;0 ecl_internal_error (0x87d790765)
>>> ;;;1 init_unixint (0x87d7b6bd0)
>>> ;;;2 init_unixint (0x87d7b6972)
>>> ;;;3 pthread_sigmask (0x80103779d)
>>> ;;;4 pthread_getspecific (0x801036d6f)
>>> ;;;5 unknown (0x7193)
>>> ;;;6 GC_push_all_stacks (0x87db1ea2c)
>>> ;;;7 GC_mark_some (0x87db12eec)
>>> ;;;8 GC_stopped_mark (0x87db09baa)
>>> ;;;9 GC_try_to_collect_inner (0x87db09a75)
>>> ;;;   10 GC_init (0x87db16f4f)
>>> ;;;   11 init_alloc (0x87d7caa59)
>>> ;;;   12 cl_boot (0x87d694a5b)
>>> ;;;   13 initecl (0x87d218340)
>>> ;;;   14 initecl (0x87d20a43f)
>>> ;;;   15 initecl (0x87d207e28)
>>> ;;;   16 _PyImport_LoadDynamicModule (0x800b3ed1c)
>>> ;;;   17 PyImport_AppendInittab (0x800b3d71f)
>>> ;;;   18 PyImport_AppendInittab (0x800b3d1a8)
>>> ;;;   19 PyImport_ImportModuleLevel (0x800b3c2ce)
>>> ;;;   20 _PyBuiltin_Init (0x800b162d7)
>>> ;;;   21 PyObject_Call (0x800a7d3e3)
>>> ;;;   22 PyEval_EvalFrameEx (0x800b2121c)
>>> ;;;   23 PyEval_EvalCodeEx (0x800b1b5d4)
>>> ;;;   24 PyEval_EvalCode (0x800b1ad96)
>>> ;;;   25 PyImport_ExecCodeModuleEx (0x800b3ad11)
>>> ;;;   26 PyImport_AppendInittab (0x800b3ddb8)
>>> ;;;   27 PyImport_AppendInittab (0x800b3d71f)
>>> ;;;   28 PyImport_AppendInittab (0x800b3d1a8)
>>> ;;;   29 PyImport_ImportModuleLevel (0x800b3c2ce)
>>> ;;;   30 _PyBuiltin_Init (0x800b162d7)
>>> ;;;   31 PyEval_EvalFrameEx (0x800b22dd1)
>>> Segmentation fault (core dumped)
>>>
>>> It looks as if ECL (version 16.1.2) is being called before an
>>> initialisation is complete, but it it possible to say more without a
>>> debugger?
>>>
>>> More details: is is on FreeBSD 11.0, clang 3.8.0, GC version 7.6.0
>>> with libatomic_ops version 7.4.6.
>>> And only reproducible on FreeBSD.
>>>
>>> ECL is built with --disable-threads; GC is built with or without
>>> threads---result is still the same.
>>> (so it's unclear to me where pthread_* calls in the trace
>>> come from).
>>>
>>> Thanks,
>>> Dima
>>>
>>> PS. the segfault is at the bottom of
>>> https://trac.sagemath.org/ticket/22679#comment:87
>>>
>>

-- Wysłane za pomocą K-9 Mail.

Re: "Got signal before environment was installed on our thread"

[Daniel Kochmański]

Hey Dima,

this looks like the issue with having GC initialized before ECL kicks 
in. See https://gitlab.com/embeddable-common-lisp/ecl/issues/371 for a 
discussion about this problem. Basically some other component already 
called GC_init and ECL calls it once more. It's arguably not a bug.


Best regards,

Daniel

On 31.08.2017 15:29, Dima Pasechnik wrote:

Dear all,

I'm struggling to understand strange segfaults coming from
ECL(+Maxima) on FreeBSD embedded into Python; they typically look as
follows:

Got signal before environment was installed on our thread
   [2: No such file or directory]

;;; ECL C Backtrace
;;;0 ecl_internal_error (0x87d790765)
;;;1 init_unixint (0x87d7b6bd0)
;;;2 init_unixint (0x87d7b6972)
;;;3 pthread_sigmask (0x80103779d)
;;;4 pthread_getspecific (0x801036d6f)
;;;5 unknown (0x7193)
;;;6 GC_push_all_stacks (0x87db1ea2c)
;;;7 GC_mark_some (0x87db12eec)
;;;8 GC_stopped_mark (0x87db09baa)
;;;9 GC_try_to_collect_inner (0x87db09a75)
;;;   10 GC_init (0x87db16f4f)
;;;   11 init_alloc (0x87d7caa59)
;;;   12 cl_boot (0x87d694a5b)
;;;   13 initecl (0x87d218340)
;;;   14 initecl (0x87d20a43f)
;;;   15 initecl (0x87d207e28)
;;;   16 _PyImport_LoadDynamicModule (0x800b3ed1c)
;;;   17 PyImport_AppendInittab (0x800b3d71f)
;;;   18 PyImport_AppendInittab (0x800b3d1a8)
;;;   19 PyImport_ImportModuleLevel (0x800b3c2ce)
;;;   20 _PyBuiltin_Init (0x800b162d7)
;;;   21 PyObject_Call (0x800a7d3e3)
;;;   22 PyEval_EvalFrameEx (0x800b2121c)
;;;   23 PyEval_EvalCodeEx (0x800b1b5d4)
;;;   24 PyEval_EvalCode (0x800b1ad96)
;;;   25 PyImport_ExecCodeModuleEx (0x800b3ad11)
;;;   26 PyImport_AppendInittab (0x800b3ddb8)
;;;   27 PyImport_AppendInittab (0x800b3d71f)
;;;   28 PyImport_AppendInittab (0x800b3d1a8)
;;;   29 PyImport_ImportModuleLevel (0x800b3c2ce)
;;;   30 _PyBuiltin_Init (0x800b162d7)
;;;   31 PyEval_EvalFrameEx (0x800b22dd1)
Segmentation fault (core dumped)

It looks as if ECL (version 16.1.2) is being called before an
initialisation is complete, but it it possible to say more without a
debugger?

More details: is is on FreeBSD 11.0, clang 3.8.0, GC version 7.6.0
with libatomic_ops version 7.4.6.
And only reproducible on FreeBSD.

ECL is built with --disable-threads; GC is built with or without
threads---result is still the same.
(so it's unclear to me where pthread_* calls in the trace
come from).

Thanks,
Dima

PS. the segfault is at the bottom of
https://trac.sagemath.org/ticket/22679#comment:87

Re: Android question: how to connect to swank, running on android?

[Daniel Kochmański]

Hey,

that probably means you still have slime without my recent improvements. 
Removal of timedwait was done in 
898aac6348a307130fb1c3906db86bd1cb565e92 slime. It's present in 2.20 
version.


Regards,

Daniel

On 26.08.2017 10:02, PR wrote:

Since Daniel suggested the new :spawn style as
swank:*communiication-style*, which works on the PC, I tried it on
android, but there it gives this error:

   Condition of type: SIMPLE-ERROR
   Timed condition variables are not supported.

Paul

Re: Android question: how to connect to swank, running on android?

[Daniel Kochmański]

Hah, that would explain why it has worked for me. In jni driver on 
ecl-android I've dup'ed stdin. See file 
jni/org_lisp_ecl_EmbeddedCommonLisp.c:63


LOGI("Redirecting I/O\n");

snprintf(tmp, 2048, "%s/ecl_output", lisp_dir);
mkfifo(tmp, 0664);
/* mode is O_RDWR to prevent blocking. Linux-specific. */
fd = open(tmp, O_RDWR | O_NONBLOCK);
dup2(fd, 1);
dup2(fd, 2);
close(fd);

snprintf(tmp, 2048, "%s/ecl_input", lisp_dir);
mkfifo(tmp, 0664);
fd = open(tmp, O_RDONLY | O_NONBLOCK);
dup2(fd, 0);
close(fd);

So stdin had a valid value.

Best regards,

Daniel


On 25.08.2017 22:01, PR wrote:

...and finally the OK: problem solved (thanks to Luís Oliveira / Slime
mailing list):

This would be a possible patch to 'swank.lisp':

  (defun repl-input-stream-read (connection stdin)
(loop
 (let* ((socket (connection.socket-io connection))
+  (inputs (list socket #-android stdin))
-  (inputs (list socket stdin))
(ready (wait-for-input inputs)))
   (cond ((eq ready :interrupt)
  (check-slime-interrupts))

(quickly tested by me on both Android and PC.)

Paul

Re: Tail self-call optimization in generated C code?

[Daniel Kochmański]

Hey,

from compiler sources (see src/cmp/cmpexit.lsp for functions which 
determine if TSC is possible):


;;; Tail-recursion optimization for a function F is possible only if
;;; 1. F receives only required parameters, and
;;; 2. no required parameter of F is enclosed in a closure.
;;;
;;; A recursive call (F e1 ... en) may be replaced by a loop only if
;;; 1. F is not declared as NOTINLINE,
;;; 2. n is equal to the number of required parameters of F,
;;; 3. the form is a normal function call (i.e. args are not 
ARGS-PUSHED),

;;; 4. (F e1 ... en) is not surrounded by a form that causes dynamic
;;;binding (such as LET, LET*, PROGV),
;;; 5. (F e1 ... en) is not surrounded by a form that that pushes a 
frame

;;;onto the frame-stack (such as BLOCK and TAGBODY whose tags are
;;;enclosed in a closure, and CATCH),

Best regards,

Daniel


On 22.08.2017 10:41, Eric Brunel wrote:
I thought it would work, but I still have a problem: I reorganized the 
code so that there aren't any  parameters in any of my 
functions and it worked quite well: the generated C code for almost 
all of them do optimize the tail self-call... except one, which is of 
course the biggest and most complicated one. I double-checked it 
thoroughly, and I can't find any reason why it wouldn't work: it is 
properly tail-recursive, and actually, every recursive call in the 
generated C code is immediately followed by a 'return'.


Now I noticed that for every function, the generated C code starts 
with something like:


{
 /* Some declarations... */
 const cl_env_ptr cl_env_copy = ecl_process_env();
 cl_object value0;
 ecl_cs_check(cl_env_copy,value0);
 {
TTL:

the TTL label being used for the tail-call optimization. This happens 
even if the function is not recursive at all, in which case the TTL 
label is never used.


But for the function that doesn't work, the 'TTL:' line is not even 
there. So there must be something in the Lisp function that prevents 
the TCO from happening. Is there a document somewhere that describes 
how the TCO is done, and in which cases it cannot be done? That would 
help me a lot to figure out what's happening here and how to fix it...




Le 2017-08-21 15:14, Eric Brunel a écrit :

Le 2017-08-21 14:55, PR a écrit :

2017-08-21 14:11 GMT+02:00, Eric Brunel :

Hello all,

I'm trying to get ECL to optimize tail self-calls in the C code
generated from the Lisp files and it looks like I'm missing something,
because I can't find a way to do that.


Here is an example that works (not written by me, it's from cliki.net):

(defun fib (n)
  "Tail-recursive computation of the nth element."
  (check-type n (integer 0 *))
  (labels ((fib-aux (n f1 f2)
 (if (zerop n)
 f1
 (fib-aux (1- n) f2 (+ f1 f2)
(fib-aux n 0 1)))

The generated C code uses goto, as you can see:

static cl_object LC1fib_aux(cl_object v1n, cl_object v2f1, cl_object 
v3f2)

{
 cl_object env0;
 const cl_env_ptr cl_env_copy = ecl_process_env();
 cl_object value0;
 ecl_cs_check(cl_env_copy,value0);
 {
TTL:
  if (!(ecl_zerop(v1n))) { goto L1; }
  value0 = v2f1;
  cl_env_copy->nvalues = 1;
  return value0;
L1:;
  v1n = ecl_one_minus(v1n);
  {
   cl_object v4;
   v4 = v3f2;
   v3f2 = ecl_plus(v2f1,v3f2);
   v2f1 = v4;
  }
  goto TTL;
 }
}



It does indeed, and I think I got it: the optional parameters to my
function seem to prevent the optimization from happening. If I rewrite
my function as:

(defun enumerate-aux (l index result)
  (cond
((null l) (reverse result))
(t (enumerate-aux (cdr l) (+ index 1) (cons (list index (car l)) 
result)))

  )
)
(defun enumerate (l) (enumerate-aux l 0 nil))

the generated code for the enumerate-aux function is as expected:

static cl_object L1enumerate_aux(cl_object v1l, cl_object v2index,
cl_object v3result)
{
 cl_object T0, T1;
 cl_object env0;
 const cl_env_ptr cl_env_copy = ecl_process_env();
 cl_object value0;
 ecl_cs_check(cl_env_copy,value0);
 {
TTL:
  if (!(v1l==ECL_NIL)) { goto L1; }
  value0 = cl_reverse(v3result);
  return value0;
L1:;
  {
   cl_object v4;
   v4 = ecl_cdr(v1l);
   {
cl_object v5;
v5 = ecl_plus(v2index,ecl_make_fixnum(1));
T0 = ecl_car(v1l);
T1 = cl_list(2, v2index, T0);
v3result = CONS(T1,v3result);
v2index = v5;
v1l = v4;
   }
  }
  goto TTL;
 }
}

Not sure I understand why, but I have a solution.

Thank you very much!
 - Eric -




Paul




Here is the behavior I'm getting for this simple Lisp function:

(defun enumerate (l  (index 0) (result nil))
   (cond
 ((null l) (reverse result))
 (t (enumerate (cdr l) (+ index 1) (cons (list index (car l))
result)))
   )
)

As far as I can see, this function is properly tail-recursive, so I
expected the generated C code to take the into account and generate a
goto instead of a recursive call. But what I'm getting is this:

static cl_object L1enumerate(cl_narg narg, cl_object v1l, ...)

Re: Android question: how to connect to swank, running on android?

[Daniel Kochmański]

Did you try again (without restarting ECL on Android) to slime-connect 
to Android host? I don't remember, but I think I had such problem, but 
connecting again worked (but it may be just my imagination).


Other ideas: are you sure your slime and swank versions match?

Did you try to update slime and swank to the newest (i.e taken from 
github) versions?



On 20.08.2017 21:39, PR wrote:

2017-08-19 23:25 GMT+02:00, Daniel Kochmański <dan...@turtleware.eu>:

AFAIR I was connecting over wifi to the REPL on my Android device.

If the port forwarding works fine - do you have some logs either from
emacs or running ECL process which show what's going on?

ok, just to report the current state:

  - if I run '(start-swank)' from the desktop (same sources as on
android), it works locally
  - PC and tablet are connected via USB
  - both PC and tablet are in the same wlan, and can ping each other
  - port forwarding is enabled: 'adb forward tcp:4005 tcp:4005'
  - if I try to connect from the PC to Swank running on the tablet,
Emacs logs these messages:




   Connecting to Swank on port 4005..
   Lisp connection closed unexpectedly: connection broken by remote peer

   error in process filter: if: Lisp connection closed unexpectedly
   error in process filter: Lisp connection closed unexpectedly
   Error running timer `slime-process-available-input': (error
"Selecting deleted buffer")




So, still no luck...

Paul







Daniel


On 19.08.2017 22:24, PR wrote:

thanks to both of you, but it still doesn't work.

  From the PC, I did:

$ adb forward tcp:4005 tcp:4005

so, this part works.

Daniel, I already "stole" the functions from the "ecl-android" project
(prior to post my question); without them I would have been lost...

So, I'll have to play around a little... Of course I will post the
solution here, if I get it to work.

Paul


2017-08-19 17:27 GMT+02:00, Daniel Kochmański <dan...@turtleware.eu>:

Hello,

swank listens by default only for localhost connections (for a good
reason!). To force it to listen for connections from specific host other
than 127.0.0.1 you have to bind swank::*loopback-interface* to it. For
instance to listen for connections from everywhere on port 4005 you
could use functions from
https://gitlab.common-lisp.net/ecl/ecl-android/blob/master/assets/lisp/etc/user.lisp

(defun start-swank ()
 (format t "Starting swank server~%")
 (mp:process-run-function
  "SLIME-listener"
  (lambda ()
(let ((swank::*loopback-interface* "0.0.0.0"))
  (swank:create-server :port 4005
   :dont-close t
   ;; :style nil #|:spawn|#
   )

(defun stop-swank ()
 (format t "Stopping swank server~%")
 (swank:stop-server 4005)
 (format t ";; Swank off-line~%"))

Note, that newest slime/swank should support :spawn communication style
just fine with ECL (my PR was merged lately). In that case it should be
enough to call create-server which won't block (note that in the example
above we create separate thread for that).

Since ECL isn't run from CLI but as shared library, it is useful to
define implementation for implementation program (don't remeber for
sure, but I think lack of this caused some problems later)

(defimplementation lisp-implementation-program ()
 "Return the argv[0] of the running Lisp process, or NIL."
 "org.lisp.ecl")

Hope this helps.

Best regards,

Daniel


On 19.08.2017 16:32, PR wrote:

Hi again,

so, the progress of the new android REPL is going well, it already
runs Quicklisp and can start swank, and right there I'm stuck now:
How does one connect from the local computer to the android device,
which is running the SLIME-listener?

They are connected via USB, and the device is /not/ rooted.

Since this is certainly of public interest, I ask here, thanks for any
help!
Below the link to the current APK of the REPL (you'll need android
version >= 4.1, API >= 16):

http://lights-of-holiness.eu/tmp/repl.apk

After launching the app, do (there is currently no feedback of the
progress, sorry):

 (quicklisp)   ; should take less than a minute, with a fast
internet
connection
 (start-swank) ; same as above (needs to byte-compile all
'contribs')

If I run:

 (mp:all-processes)

it lists the running "SLIME-listener" process, so it seems to work...

Thanks for any help!

Paul

Re: Android question: how to connect to swank, running on android?

[Daniel Kochmański]

Hello,

swank listens by default only for localhost connections (for a good 
reason!). To force it to listen for connections from specific host other 
than 127.0.0.1 you have to bind swank::*loopback-interface* to it. For 
instance to listen for connections from everywhere on port 4005 you 
could use functions from 
https://gitlab.common-lisp.net/ecl/ecl-android/blob/master/assets/lisp/etc/user.lisp


(defun start-swank ()
  (format t "Starting swank server~%")
  (mp:process-run-function
   "SLIME-listener"
   (lambda ()
 (let ((swank::*loopback-interface* "0.0.0.0"))
   (swank:create-server :port 4005
:dont-close t
;; :style nil #|:spawn|#
)

(defun stop-swank ()
  (format t "Stopping swank server~%")
  (swank:stop-server 4005)
  (format t ";; Swank off-line~%"))

Note, that newest slime/swank should support :spawn communication style 
just fine with ECL (my PR was merged lately). In that case it should be 
enough to call create-server which won't block (note that in the example 
above we create separate thread for that).


Since ECL isn't run from CLI but as shared library, it is useful to 
define implementation for implementation program (don't remeber for 
sure, but I think lack of this caused some problems later)


(defimplementation lisp-implementation-program ()
  "Return the argv[0] of the running Lisp process, or NIL."
  "org.lisp.ecl")

Hope this helps.

Best regards,

Daniel


On 19.08.2017 16:32, PR wrote:

Hi again,

so, the progress of the new android REPL is going well, it already
runs Quicklisp and can start swank, and right there I'm stuck now:
How does one connect from the local computer to the android device,
which is running the SLIME-listener?

They are connected via USB, and the device is /not/ rooted.

Since this is certainly of public interest, I ask here, thanks for any help!
Below the link to the current APK of the REPL (you'll need android
version >= 4.1, API >= 16):

http://lights-of-holiness.eu/tmp/repl.apk

After launching the app, do (there is currently no feedback of the
progress, sorry):

   (quicklisp)   ; should take less than a minute, with a fast internet
connection
   (start-swank) ; same as above (needs to byte-compile all 'contribs')

If I run:

   (mp:all-processes)

it lists the running "SLIME-listener" process, so it seems to work...

Thanks for any help!

Paul

Re: Android question: does cross-compiling require a 32 bit host ECL?

[Daniel Kochmański]

Yes, this is true. The problem is that ECL compiler doesn't have 
distinction between host architecture and target architecture (it just 
transpiles code) - so if host implementation has long-double, it will 
produce C code using long-double, if 64 bit integers are present, then 
transpiled code is used for that.


I'm aware of that problem and I plan to separate compilation and target 
features. That said, it's probably not something what will be fixed in 
the upcoming release. Definetely doable though (and useful).



On 01.07.2017 20:37, PR wrote:

Hi again,

In the process of porting EQL5 to Android, I stumbled upon this problem:
The app crashes on Android during read_VV(), if the lisp library has
been cross-compiled using a 64 bit ECL.

To solve this problem, I need to use a 32 bit ECL for cross-compiling:
but this would mean that for cross-compiling EQL5 apps we are required
to stay with 32 bit ECL for EQL5.

Probably not a big deal, but could the Android gurus confirm this?

Thanks,

Paul

Re: Recipe for wrapping C++ files

[Daniel Kochmański]

Here: https://common-lisp.net/project/ecl/static/manual/ch28.html
And here:
https://common-lisp.net/project/ecl/static/ecldoc/Extensions.html#Foreign-Function-Interface

Иван Трусков writes:

> Thanks!
> However, it contains only examples of calling lisp from C.
> Are there examples of calls going both ways? After some search I have found
> about CFFI which may be just what I need. Are there examples for using CFFI
> alongside ECL?
>
> среда, 24 мая 2017 г. пользователь Daniel Kochmański написал:
>
>> Hey,
>>
>> this tutorial may be useful to you:
>>
>> https://common-lisp.net/project/ecl/index.html#orgheadline10
>>
>> Best regards,
>> Daniel
>>
>>
>> Иван Трусков writes:
>>
>> > Hello
>> > How can one bridge between C++ objects and CL? For example, given a class
>> > to the lines of
>> >
>> > class A
>> > {
>> > public:
>> > A(int q, int w);
>> > ~A();
>> > void foo(int q);
>> > int bar();
>> > };
>> >
>> > that has its instances wrapped in smart pointers, how can that
>> > functionality be made available from embedded Common Lisp?
>> > Sorry if that's too general of a question. I am somewhat ignorant at the
>> > moment, and would appreciate any tips as to where to dig to solve that
>>
>> --
>> Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
>> TurtleWare - Daniel Kochmański  | www.turtleware.eu
>>
>> "Be the change that you wish to see in the world." - Mahatma Gandhi
>>

-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: ECL does not support docstrings for functions created with flet, labels or lambda. Why?

[Daniel Kochmański]

Hello,

the problem origins from the fact, that documentation isn't stored in
the same structure as the function definition (we have PDE machanism and
expand-set-documentation for that). Lambda macro doesn't use them,
because it doesn't have associated global symbol (same goes for flet and
labels as well as for macrolet and such).

This is a quirk I would want to fix at some point of time. The way to go
will be adding documentation slot to the appropriate structures. Another
problem originating from the current behavior is that our documentation
is usually lost when the image is restarted (unless we dump the
documentation and load it again at start) – fas files doesn't contain
documentation entries whatsoever.

I'm adding #337 issue to the tracker so you can track a progress when I
get to it: https://gitlab.com/embeddable-common-lisp/ecl/issues/337 . I
don't know about the other implementations.

Best regards,
Daniel

Alexander Artemenko writes:

> Hi!
>
> I found that:
>
> CL-USER> (let ((foo (lambda () "With docstring" 100500)))
>>(princ (funcall foo))
>>(terpri)
>>(princ (documentation foo t)))
>> 100500
>> NIL
>> NIL
>
>
> in ECL, but:
>
> CL-USER> (let ((foo (lambda () "With docstring" 100500)))
>>(princ (funcall foo))
>>(terpri)
>>(princ (documentation foo t)))
>> 100500
>> With docstring
>> "With docstring"
>
>
> Why?
>
> BTW, similar behaviour have ABCL, Allegro and CCL. But SBCL and CLISP work
> as expected.


-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Continuous integration

[Daniel Kochmański]

Hey,

Roger Sen Montero writes:

> Hi,
>
>  Any plan to deploy Gitlab continuous integration? If yes, happy to
> contribute with a mac for testing.

Thanks for the offer. I would love to see CI with ECL, though I haven't
made any plans for that so far. Maybe someone is interested in doing
that? If not, I'll get back to you when I'll deploy it.

Best regards,
Daniel

-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Statically linking C code into ECL

[Daniel Kochmański]

Faré writes:

> Unhappily, neither *user-cc-flags* nor *ld-flags* allows me to get the
> desired result:
> the former is not used by build-program, and the latter is only used
> *after* passing the list of .a, too late for a -Wl,--whole-archive.
> Moreover, on Darwin and/or with lld, I need to use -Wl,-force_load
> before each individual .a instead, and the current interface won't
> allow that.

What about the proposed usage of :ld-flags passed to the builder?
>
> I tried to link .o files directly, instead of .a files, but ran into a
> different ECL issue regarding slot inheritance; see my other email
> about that.

Thanks for the report.
>
> PS: Regarding using c:build-program instead of c::builder :program,
> when was the change made? Do I need to care about supporting older
> versions of ECL?

It's in place since 2001 (or earlier) according to git blame.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org
> What is mind? No matter! What is matter? Never mind!
>— Bertrand Russell's Grand Mother, In Karl Popper, The Unended Quest
>
>

Daniel

-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Statically linking C code into ECL

[Daniel Kochmański]

Faré writes:

> Is there an official or encouraged way?

No.

>> builder (and all interfaces built on top of it) support ld-flags key
>> argument. Additionally if you want to influence how ECL compiles files
>> dynamically you may shadow *user-cc-flags* and *user-ld-flags*.
>>
> This won't work. *user-cc-flags* isn't used by build-program, AFAICT,
> and user-ld-flags is only used at the end of the linking command,
> which is too late for a --whole-archive (and a --no-whole-archive is
> actually needed before the -ldl -lm etc. calls, whereas on Darwin, the
> -force_load is needed in front of each individual .a).

*user-cc-flags* and *user-ld-flags* are used in all operations involving
C/C++ compiler. If it's too late, then what about (mentioned in the
previous mail) :ld-flags ?

(let ((c::*compile-verbose* t)
   (*compile-print* t))
   (c::builder :program "sdbam" :lisp-files '("/home/jack/test.c")
   :ld-flags '("ld-flag-bam=3")))

(RUN-PROGRAM "gcc" ("-o" "sdbam" "-L/usr/local/lib/"
"/tmp/eclinitPjB9n2.o" "test.c"
"ld-flag-bam=3"
"-Wl,--rpath,/usr/local/lib/" "-lecl"
"-lgmp" "-lgc" "-lgc" "-lgc" "-lpthread"
    "-ldl" "-lm"))

ld-flag-bam=3 is passed before -ldl -lm etc (that, of course, won't
work, because ld-flag=bam=3 doesn't make much sense), so if that's what
you want, just pass :ld-flags to c:build-*.

-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Statically linking C code into ECL

[Daniel Kochmański]

Faré writes:

> What's the official way to link a C file into ECL?

What do you mean by 'linking C file'? If you want to compile independent
C file with ECL, then you are out of luck, because there is no official
support for that in ECL's builder. It may work by passing file as one of
lisp-files to builder, because ECL uses C files *internally*, but it's
far from encouraged or official.

As a side note, I see you use there c::builder, which is also
internal. Exported interfaces are build-fasl, build-program,
build-static-library and build-shared-library (it doesn't make a
difference right now, but in the future builder interface may change,
while the mentioned functions wont).
>
> I'm adding a :c-file type to cffi-toolchain, and it works great on
> sbcl and clisp,
> or on ECL when loading the file as a .so, but when I try to link the
> file into an executable,
> the .o failed to be included in the executable: the .o was
> successfully grouped with
> other .o's from the same system in a .a, but ecl fails to use
> -Wl,--whole-archive,
> so the .o is not preserved.
> Is there a way to tell ECL to use -Wl,--whole-archive and/or (on
> Darwin) -force_load before every .a?

builder (and all interfaces built on top of it) support ld-flags key
argument. Additionally if you want to influence how ECL compiles files
dynamically you may shadow *user-cc-flags* and *user-ld-flags*.
>
> The question is in the context of my cffi branch (that I'm hoping to
> upstream asap, pending merge of the sbcl patch it depends on):
> https://github.com/fare/cffi
>
> —♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org
> A president worth voting for wouldn't run for office.

If this remarks aren't helpful, please tell me exactly what do you want
to achieve with some minimal example (i.e I'm doing that and that,
expecting this and this, but it doesn't work failing in this way),
because I don't quite understand your problem.

I'm adding ecl-devel to CC, because someone may be more competent to
answer your question.

Regards,
Daniel

-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: [Maxima-discuss] maxima-5.39.0/ecl-16.1.3 new testsuite failure

[Daniel Kochmański]

This wasn't a regression, just reinforcing fpe shown already existing
problem in atan function. The problem is fixed in the develop branch.

-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: [Maxima-discuss] maxima-5.39.0/ecl-16.1.3 new testsuite failure

[Daniel Kochmański]

Hey,

Thank you for narrowing this down! I've added an issue to gitlab:

https://gitlab.com/embeddable-common-lisp/ecl/issues/329

Best regards,
Daniel

-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: What is the proper way to pass a void* to a C++ instance?

[Daniel Kochmański]

Also check out this tutorial:

https://common-lisp.net/project/ecl/posts/ECL-Quarterly-Volume-V.html#orgheadline10
by Lexicall.

Daniel

-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Crosscompiling ECL for Windows

[Daniel Kochmański]

Your patch added to the develop branch.

Best regards,
Daniel

-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

[quarterly volume 5]

[Daniel Kochmański]

Dear All,

New ECL Quarterly issue has been published today. I hope to make it more
regular, sorry for the delay.

https://common-lisp.net/project/ecl/posts/ECL-Quarterly-Volume-V.html

I have also some latency with the next release, but I hope to finish it
before a new year.

Best regards,
Daniel

-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: probe-file cuts symlink filename to 128 chars

[Daniel Kochmański]

Hello,

could you verify, if the fix works for you?
https://gitlab.com/embeddable-common-lisp/ecl/issues/295 (commit
44178bd0, develop branch).

Best regards,
Daniel

-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: probe-file cuts symlink filename to 128 chars

[Daniel Kochmański]

Hello Tomas,

Thank you for the report (and sorry for delayed response). I've added
this issue to the tracker, you may monitor it here:

https://gitlab.com/embeddable-common-lisp/ecl/issues/295

Best regards,
Daniel

-- 
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Crosscompiling ECL for Windows

[Daniel Kochmański]

OK, fixed in the `develop' branch, if you could try the lastest changes
and report back if it work for you I would be grateful.

Thanks,
Daniel

-- 
Daniel Kochmański ;; aka jackdaniel | Poznań, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: segfault while testing lil

[Daniel Kochmański]

In fact I did, but it didn't work, so I've tried the testcase you
provided with the same result, so I've wrote an e-mail.

I had to manually quickload the reader-interception, because it's not
listed in the lil/test dependencies. I think it's a lil's test system
definition bug.

Either way, testing the system gives the segmentation-violation just as
you said, so the bug is confirmed. I think that it's triggered by
something in hu.dwim.stefil (hu.dwim.* already proven a few ECL bugs).

Could you add it to the issue tracker on
https://gitlab.com/embeddable-common-lisp/ecl/issues ?

Thanks,
Daniel

Faré writes:

> On Thu, Apr 14, 2016 at 1:28 AM, Daniel Kochmański <dan...@turtleware.eu> 
> wrote:
>> Hey,
>>
>> I have on this testcase:
>>
>> jack@pandora ~ % rlwrap ecl -eval "'(#.(require \"asdf\")#.(asdf:test-system 
>> :lil))"
>> ;;; Loading "/home/jack/quicklisp/setup.lisp"
>> ;;; Loading #P"/usr/local/lib/ecl-16.1.2/asdf.fas"
>> An error occurred during initialization:
>> Component "reader-interception" not found, required by
>> #.
>>
> That's just you missing a dependency.  Install all dependencies, or
> try loading quicklisp instead of requiring asdf.
>
> —♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org
> Thinking is the hardest work there is, which is probably the reason why
> so few engage in it. — Henry Ford


-- 
Daniel Kochmański ;; aka jackdaniel | Poznań, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Some thread/GC questions

[Daniel Kochmański]

Juraj Variny writes:

> On Wednesday 09 March 2016 09:07:38 you wrote:
>> Hello,
>> 
>> Juraj Variny writes:
>> > Hello,
>> > 
>> > can you please tell me how to:
>> > 
>> > 1. Initialize lisp environment in a thread that was already created by
>> > C/C++ app? Is it possible for it to share existing lisp environment?
>> 
>> There is an example in examples/embed directory (file hello.c). What do
>> you mean by sharing an existing lisp environment? cl_boot creates an
>> environment for this instance.
>
> Say I have main thread, where cl_boot was called, with some lisp environment. 
> Then I call cl_boot in some other pre-existing thread, would it be able to 
> access lisp environment of the main thread, evaluate symbols defined there, 
> call functions etc? This is what I meant with shared environment.

It is enought to call cl_boot once. Calling it a second time won't do
any harm, but the cl_boot isn't thread-safe, so don't call it twice at
the same time from different threads.

After calling cl_boot once you should be able to work with lisp from any
thread.

Please also keep in mind this section of the manual (signal handling):
https://common-lisp.net/project/ecl/manual/ch32s04.html
>
>> > 2. Is accessing and modification of the shared lisp environment from a new
>> > thread made by (mp:process-run-function) threadsafe? For example I am
>> > running swank this way, is this a safe practice?
>> 
>> It is meant to be. Any reproducible bug should be reported here:
>> https://gitlab.com/embeddable-common-lisp/ecl/issues/ . I'm using swank
>> from the separate thread in ecl-android and I didn't encounter problems
>> with that.
>> 
>> ECL's swank backend contains in comment some hint regarding the thread
>> safety (not sure though, how up-to-date it is):
>> 
>>   ;; While ECL does provide threads, some parts of it are not
>>   ;; thread-safe (2010-02-23), including the compiler and CLOS.
>> 
>> it is something I want to investigate. I'm currently working on
>> something else in the compiler though.
>
> I do see corruption in this scenario. But it is so far anectotal or may be my 
> own error (failed to prevent 3. and 4.), will make an issue if I reliably 
> reproduce it.

Thanks.
>
>> > 3. In the environment where only ECL is garbage collected: Calling
>> > ecl_base_string_pointer_safe(si_copy_to_simple_base_string(obj)) means
>> > that
>> > resulting C string will be eventually garbage collected?
>> 
>> Yes.
>> 
>> > 4. Likewise (ffi:c-inline () () :cstring "...") returns the value via
>> > ecl_cstring_to_base_string_or_nil() which causes trouble when C side
>> > deallocates it, I presume?
>> 
>> Yes.
>> 
>> > Regards,
>> > 
>> > Juraj
>> 
>> Best reagrds,
>> Daniel


-- 
Daniel Kochmański ;; aka jackdaniel | Poznań, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: [Maxima-discuss] ecl-16.1.2: new maxima testsuite failure

[Daniel Kochmański]

I can't reproduce it on my 64-bit ArchLinux box. What flags did you
built ECL with?

Could you check, if the bug is present on:
4548ed7c4cd9a428d95695b6528e55d6d80cb11c and
bff9aced440c47893d283d48cc251391828836a9 ?

(this is before and after the new RNG implementation).

Regards,
Daniel

Andrey G. Grozin writes:

> An additional bit of information: this failure happens in 64-bit Gentoo 
> linux. In 32-bit Gentoo linux there are no unexpected errors in the 
> testsuite.
>
> How can one debug this problem?
>
> Andrey


-- 
Daniel Kochmański ;; aka jackdaniel | Poznań, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

ECL 16.1.2

[Daniel Kochmański]

Dear all,

ECL 16.1.2 has been released just a few minutes ago :-) Link to the
announcement and downloads available in the news section on the website:
https://common-lisp.net/project/ecl/

Best regards,
Daniel

-- 
Daniel Kochmański ;; aka jackdaniel | Poznań, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: [rc2]

[Daniel Kochmański]

OK, thanks. I think I have something wrong with my setup because I can't
load the crashed packages even from SBCL or CCL (problems with
hu.dwim.*). I'll create a fresh user account, download testgrid and run
it (with a new rc tag), I hope it will work OK...

Regards,
Daniel

Anton Vodonosov writes:

> 16.02.2016, 18:30, "Daniel Kochmański" <dan...@turtleware.eu>:
>> Is there a way to pick the results if the commit and version name were
>> the same? I've re-run the tests on my localhost machine, but the
>> generated report uses results from the previous run. If not, I'll re-run
>> the tests with the dummy -rc4 tag..
>
> I've just filtered out old results by their test-run-time:
> https://github.com/cl-test-grid/cl-test-grid-work/blob/e44d78215d6e90297cd9cf8defa21e3100d12fe7/ecl-reports4.lisp#L206
>
> I took the value of timestamp in the notification email:
> https://groups.google.com/d/msg/cl-test-grid-notifications/qlDB70TaSQo/L7sDGkwVAwAJ
>
> The resulting report:
> https://common-lisp.net/project/cl-test-grid/ecl/ecl-diff-16.1.2-rc3-lin-x64-lisp-to-c.html
>
> BTW, new results were only submitted for lisp-to-c compiler.
>
> I did one change in the report: new ECL version - RC3 - is on the right hand 
> side.
> This is the usual way, but in the previous report I mistakenly did it other 
> way around.
>
> Let me know how can I help.
>
>
> Best regards,
> - Anton

-- 
Daniel Kochmański ;; aka jackdaniel | Poznań, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: [release candidate][16.1.2]

[Daniel Kochmański]

Anton Vodonosov writes:

> 05.02.2016, 11:15, "Daniel Kochmański" <dan...@turtleware.eu>:
>> Anton Vodonosov writes:
>>
>>> Daniel, your 16.1.2 linux results are submitted.
>>> If you run the previous release on the same machine, I will be able
>>> to produce a diff report.
>>
>> OK, I'll do that. 32 bit machine will finish soon also (I've suspended
>> it for a night). Then I'll run with 16.0.0 this one as well.
>>> Your windows results are usually CRASH results, like this:
>>> http://cl-test-grid.appspot.com/blob?key=m76e0039li
>>>
>>> Alos, you seem to forgot to change :user-email
>>> from avodono...@yandex.ru to your email.
>>
>> Hrm, a few first tries were against cygwin build which had such
>> problems, but I think that the last two runs (which were against MSVC
>> version) did OK. All windows results are trash?
>
> I only see results from ecl-16.1.2-093ba0ab-win-x86-bytecode submitted twice
> (for example see here
> https://common-lisp.net/project/cl-test-grid/library/drakma.html )
>
> Both times the log mentions C:/cygwin64/ directory.

cl-test-grid was installed in cygwin64 directory (I'm using it's bash as
a console). I'm sure I did run it with bytecmp compiler on 16.1.2 *and*
16.0.0 (last two runs), but probably windows is too _alient_ to me and I
did something weird. I've started 16.0.0 run on my machine and will
start also 16.0.0 on 32bit Ubuntu VM. I'll pass with windows this time
:-)

-- 
Daniel Kochmański ;; aka jackdaniel | Poznań, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: Displaying lisp errors while running with save_eval

[Daniel Kochmański]

Hello,

do you mean si_safe_eval? I can't find save_eval function, but
si_safe_eval prints the error if desired.

I've added corresponding documentation issue:
https://gitlab.com/embeddable-common-lisp/ecl/issues/197

Generally, if you provice si_safe_eval with four arguments (incliding
the nargs), then on error the fourth one will be returned. If you
provide only three arguments, then standard debugger will be invoked and
error printed (note, that you may unwind protect it, and then only the
error should be printed).

It's a feature, because often we don't want these things in the
production code, we just want to be able to verify, if an error
occurs. So if you want "normal" handling of the errors, invoke it like
this:

si_safe_eval(2, c_string_to_object("(hi-jack)"), ECL_NIL);

(or if you want some other environment, use it instead of ECL_NIL,
i.e. ecl_process_env()).

Best regards,
Daniel

Diogo Franco writes:

> Hi all,
>
> Uncaught error conditions in lisp code don't display in *standard-output*
> for me, when ecl is running embedded in c (i presume the reason is that i'm
> calling the lisp functions using save_eval()).
>
> My workflow on the shell while developing is then to do ctrl-c which drops
> me to the REPL, and to manually execute the functions, which will print the
> error.
>
> I'm no expert on the inner workings of ecl, so forgive me if this is a dumb
> question, but is there some way to get the errors in *standard-output* even
> when using save_eval()?
>
> Thanks in advance,
> Diogo Franco

-- 
Daniel Kochmański ;; aka jackdaniel | Poznań, Poland
TurtleWare - Daniel Kochmański  | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: [ecl-android v0.0.1]

[Daniel Kochmański]

Pascal J. Bourguignon writes:

> I compiled and installed successfully ecl-android on a cyanogen cm-12.1
> android on Sansung Galaxy S4.
>
> After getting quicklisp:
>
> - I tried (ql:add-to-init-file) but I'm not sure it was successful,
>   since it waits for a newline input.

Init file isn't loaded at start. You may add loading it in user.lisp
under

assets/lisp/etc/user.lisp

in ecl-android sources. I'd advise you though to use (get-quicklisp)
instead, because it replaces QL minitar and gunzip with precompiled
versions (much faster then the bytecompiled ones).

>
> - I tried to start swank, either from the menu, or by evaluating
>   (start-swank), but in both case, I got an error (ERROR in eval).

You should put slime-2.14/ in assets/lisp/home/ . I'll add it to the
readme later.
>
> I guess next step will be to integrate with my application, or to
> improve the user interface for the "ECL Android" app. 

I wouldn't recommend integrating ecl-android yet. As mentioned a few
times it's an alpha quality and as you have noticed it has many
shortcomings. I hope to improve this state soon (after assembling the
next ECL Quarterly).

Some notes regarding working with ecl-android:
- all lisp files are in assets/lisp/ directory
- they are extracted on the first boot of the application, so if you
modify for instance user.lisp and install application over the previous
installation it won't get updated unless you'll clear the application
data
- first loaded file is etc/init.lisp, then it's etc/user.lisp, please
customize the latter (not the former file)
- environment variables:
  $ROOT points to the toplevel lisp directory (assets/lisp)
  $ECLDIR never change this ($ROOT/lib)
  $ETC contains init.lisp, user.lisp ($ROOT/etc)
  $HOME contains user files ($ROOT/home)

working lisp library maintains two fifos: $ROOT/ecl_output and
$ROOT/ecl_input . Input isn't used yet (had some problems with the slime
and working stdin) and output is slurped and shown in the APP.

Application has special service (android-specific) which enables two
intents: "ENSURE_LISP" and "EVAL" - the latter takes data argument which
contains sexp to exec. This part *is* prone to change. You may export
this service to the other applications by modifying AndroidManifest.xml
(that means that you will be able to call lisp from application which
isn't derivered from ecl-android).

Best regards,
Daniel

-- 
Daniel Kochmański | Poznań, Poland ;; aka jackdaniel
www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi

Re: [ecl-android v0.0.1]

[Daniel Kochmański]

Pascal J. Bourguignon writes:

> Daniel Kochmański <dan...@turtleware.eu>
> writes:
>
>> Hey,
>>
>> I've noticed in your scripts that you build without the dffi - please
>> try removing this option. It seems unrelated but who knows.
>
> Didn't help.
>
>> I can't reproduce your error unfortunately. I have however a suspicion
>> why libtool can't "see" the toolchain in the path.
>>
>> src/bdwgc/libatomic_ops/configure:7972:LIBTOOL='$(SHELL) 
>> $(top_builddir)/libtool'
>>
>> Probably the PATH variable gets "cleaned" when invoking the shell
>> command and libtool from libatomic_ops can't see the libtool.
>>
>> Please try remove the invocation of libtool via /bin/sh
>>
>> src/bdwgc/libatomic_ops/configure:7972:LIBTOOL='$(top_builddir)/libtool'
>>
>> If it works for you please let me know so I'll fix it in the sourcecode.
>
> Doesn't help.
>
> But I notice an inconsistency in the libtool scripts generated. For
> example, ecl/build/libffi/libtool contains:
>
> NM="/home/pjb/opt/toolchains/android-arm-ndk-android-18/bin/arm-linux-androideabi-nm
>  -B"
> OBJDUMP="arm-linux-androideabi-objdump"
> AR="arm-linux-androideabi-ar"
> STRIP="arm-linux-androideabi-strip"
> RANLIB="arm-linux-androideabi-ranlib"
> LTCC="arm-linux-androideabi-gcc -fPIC"
> striplib="arm-linux-androideabi-strip --strip-unneeded"
> LD="/home/pjb/opt/toolchains/android-arm-ndk-android-18/arm-linux-androideabi/bin/ld"
> CC="arm-linux-androideabi-gcc -fPIC"
> LD="/home/pjb/opt/toolchains/android-arm-ndk-android-18/arm-linux-androideabi/bin/ld"
> CC="arm-linux-androideabi-g++"
>
> So, sometimes, there's a full path to the cross compiler tools, and
> sometimes, there's just the file name.
>
> As bash scripts, they will load /etc/profile and ~/.bash_profile (or
> else ~/.bash_login or else ~/.profile) and $BASH_ENV; the later will
> usually set the PATH, overriding the environment.
>
> Since we configure the PATH when compiling (either in a script like my
> compile-toolchain.sh, or in an interactive shell), this environment
> variable will usually be overriden when bash scripts such as libtool are
> started.
>
> If I source my android.sh where the PATH is updated in my $BASH_ENV,
> then the compilation with the cross compiler proceeds successfully.
>
> [pjb@kuiper :0.0 android]$ file ~/opt/toolchains/android-arm-ecl/bin/ecl
> /home/pjb/opt/toolchains/android-arm-ecl/bin/ecl: ELF 32-bit LSB executable, 
> ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter 
> /system/bin/linker, not stripped
>
>
> I would therefore advice to either copy the environment PATH in those
> scripts, or only use absolute path for the cross compiler commands.

Thanks. I'll take a look on that when find some time. Grats :)

Daniel

-- 
Daniel Kochmański | Poznań, Poland ;; aka jackdaniel
www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi