- ecl-devel - mailman3.common-lisp.net

MSVC and C++
by dave＠synergy.org 07 Apr '24

07 Apr '24

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

3 3

Adding include and library directories
by dave＠synergy.org 04 Apr '24

04 Apr '24

I am trying to add directories for #include directives and for linking libraries. The below text is my make.lisp file for building my code: (require 'cmp) (setf c:*user-cc-flags* "-DWXUSINGDLL") (setf c::*ecl-include-directory* "C:/Dave/wx/include,C:/Dave/wx/include/msvc") (setf c::*ecl-library-directory* "C:/Dave/wx/lib/vc_x64_dll") (compile-file "wx.lisp" :system-p t) (c:build-fasl "wx" :lisp-files '("wx.obj")) Although (setf c:*user-cc-flags* "-DWXUSINGDLL") Is working as evidenced by the argument list to run-program, there is no evidence that the include or library directories are being used at all. Moreover, the #include directive in the wx.lisp code cannot find the specified header file. How are c::*ecl-include-directory* and c::*ecl-library-directory* intended to be used? Dave

2 2

[Last CfP] 17th European Lisp Symposium, May 6-7 2024, Vienna
by Didier Verna 18 Feb '24

18 Feb '24

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 17th European Lisp Symposium Call for Papers May 6-7 2024 Federal Computing Center, Vienna, Austria https://www.european-lisp-symposium.org/2024 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: Feb. 25 2024 ** EXTENDED ** - Author notification: Mar. 24 2024 - Final papers due: Apr. 14 2024 - Symposium: May 6-7 2024 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation, and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - context-, aspect-, domain-oriented and generative programming - macro-, reflective-, meta- and/or rule-based development approaches - language design and implementation - language integration, inter-operation, and deployment - development methodologies, support, and environments - educational approaches and perspectives - experience reports and case studies This year, we suggest an emphasis on best practices, approaches, and technologies for building highly recursive and self-adapting architectures, in particular for AI, ML, tool integration and instruction generation, using dynamic programming languages. Technical Program ~~~~~~~~~~~~~~~~~ We invite submissions in the following forms. * Papers: technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. * Experience reports: papers of up to 6 pages describing a successful use of a Lisp dialect and/or analyzing obstacles that have kept it from working in practice. * Tutorials: abstracts of up to 4 pages for in-depth presentations about topics of special interest. * Demonstrations: abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following link http://www.easychair.org/conferences/?conf=els2024. Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Giuseppe Attardi, University of Pisa, Italy Organizing Chair ~~~~~~~~~~~~~~~~ Didier Verna, EPITA, France Programme Committee ~~~~~~~~~~~~~~~~~~~ Ambrose Bonnaire-Sergeant, Untypable LLC Frederic Peschanski, UPMC/LIP6 Jay McCarthy, UMass Lowell Jim Newton, EPITA Research Lab Kai Selgrad, OTH Regensburg Mark Evenson, not.org Michael Raskin, LaBRI/CNRS UMR 5800, University of Bordeaux Robert Smith, HRL Laboratories LLC Robert P. Goldman, SIFT LLC Stefan Monnier, Université de Montréal Local Chair ~~~~~~~~~~~ Philipp Marek, BRZ, Vienna, Austria Virtualization Team ~~~~~~~~~~~~~~~~~~~ Georgiy Tugai, Configura, Sweden Michal Herda, Poland Yukari Hafner, Shirakumo.org, Switzerland -- Resistance is futile. You will be jazzimilated. Jazz site: http://www.didierverna.com Other sites: http://www.didierverna.info

1 0

Command Prompt end-of-line issues
by dave＠synergy.org 24 Jan '24

24 Jan '24

Hello, I am having end-of-line issues on Windows 11 64-bit (compiled with Visual Studio 2022 v17.6.2). ECL acts like it is gobbling up end-of-line characters. For example, when I type (cons 1 2)<ENTER> at the REPL nothing happens. If I then type <ENTER>, then REPL executes the function and returns (1 . 2) as expected. If I type (quit)<ENTER> at the REPL, nothing happens. If I type <ENTER>, ECL exits and returns to the Command Prompt. This is new behavior to me, but I do not know when it began. I have never had this difficulty on Windows before. Has anyone else observed this behavior? It does not happen on Debian. David

1 0

[CfP] 17th European Lisp Symposium, May 6-7 2024, Vienna, Austria
by Didier Verna 19 Jan '24

19 Jan '24

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 17th European Lisp Symposium Call for Papers May 6-7 2024 Federal Computing Center, Vienna, Austria https://www.european-lisp-symposium.org/2024 Sponsored by EPITA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: Feb. 18 2024 - Author notification: Mar. 24 2024 - Final papers due: Apr. 14 2024 - Symposium: May 6-7 2024 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation, and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - context-, aspect-, domain-oriented and generative programming - macro-, reflective-, meta- and/or rule-based development approaches - language design and implementation - language integration, inter-operation, and deployment - development methodologies, support, and environments - educational approaches and perspectives - experience reports and case studies This year, we suggest an emphasis on best practices, approaches, and technologies for building highly recursive and self-adapting architectures, in particular for AI, ML, tool integration and instruction generation, using dynamic programming languages. Technical Program ~~~~~~~~~~~~~~~~~ We invite submissions in the following forms. * Papers: technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. * Experience reports: papers of up to 6 pages describing a successful use of a Lisp dialect and/or analyzing obstacles that have kept it from working in practice. * Tutorials: abstracts of up to 4 pages for in-depth presentations about topics of special interest. * Demonstrations: abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following link http://www.easychair.org/conferences/?conf=els2024. Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Giuseppe Attardi, University of Pisa, Italy Programme Committee ~~~~~~~~~~~~~~~~~~~ Ambrose Bonnaire-Sergeant, Untypable LLC Frederic Peschanski, UPMC/LIP6 Jay McCarthy, UMass Lowell Jim Newton, EPITA Research Lab Kai Selgrad, OTH Regensburg Mark Evenson, not.org Michael Raskin, LaBRI/CNRS UMR 5800, University of Bordeaux Robert Smith, HRL Laboratories LLC Robert P. Goldman, SIFT LLC Stefan Monnier, Université de Montréal Local Chair ~~~~~~~~~~~ Philipp Marek, BRZ, Vienna, Austria Virtualization Team ~~~~~~~~~~~~~~~~~~~ Georgiy Tugai, Configura, Sweden Michał Herda, Poland Yukari Hafner, Shirakumo.org, Switzerland -- Resistance is futile. You will be jazzimilated. Jazz site: http://www.didierverna.com Other sites: http://www.didierverna.info

1 0

ASDF: could use some help with ECL issue
by Robert Goldman 10 Jan '24

10 Jan '24

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!

2 2

WASM / Web Assembly ecl in a browser
by Jón Hallur Haraldsson 05 Jan '24

05 Jan '24

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

4 4

[ecl 23.9.9][release]
by Daniel Kochmański 09 Sep '23

09 Sep '23

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

1 0

ecl-devel@common-lisp.net
by Gerard ROBIN 18 Aug '23

18 Aug '23

Hello, I am using ecl on my smartphone (android) it works fine but the -q option does not work. How can we make it not verbose? Thanks -- Gerard ____________________________ **************************** Created with Mutt 2.2.9 under Debian Linux BOOKWORM ****************************

1 0

Re: speeding ECL up
by Daniel Kochmański 14 Jul '23

14 Jul '23

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+ecl(a)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

3 3