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

EQL5: QML/Lisp bridge (for desktop)
by PR 19 Jan '17

19 Jan '17

For those interested in the progress of EQL5: Two new modules have been added lately: "multimedia" and "quick". The most interesting part is the QML / Lisp bridge, which allows creating applications using only QML (declarative UI) and Lisp (instead of JavaScript). For examples of calling Lisp from QML, see: https://gitlab.com/eql/EQL5/blob/master/examples/M-modules/quick/qml-lisp/q… For a working example (port of the QtQuick1 "Tic-Tac-Toe" example), see: QML: https://gitlab.com/eql/EQL5/blob/master/examples/M-modules/quick/Tic-Tac-To… Lisp: https://gitlab.com/eql/EQL5/blob/master/examples/M-modules/quick/Tic-Tac-To… This is meant for desktop applications only (I don't have any experience with mobile apps, and don't know the current state of the android port). Paul

1 0

Continuous integration
by Roger Sen Montero 05 Jan '17

05 Jan '17

Hi, Any plan to deploy Gitlab continuous integration? If yes, happy to contribute with a mac for testing. -- Roger Sen Montero roger.sen(a)gmail.com +34 649 975 570

2 3

[CfP] ELS'17, 10th European Lisp Symposium, April 3-4 2017, Brussels
by Didier Verna 03 Jan '17

03 Jan '17

ELS'17 - 10th European Lisp Symposium VUB - Vrije Universiteit Brussel Belgium April 3-4, 2017 In co-location with <Programming> 2017 Sponsored by Brunner Software GmbH http://www.european-lisp-symposium.org/ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 10th 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 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. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. The conference proceedings will be published in the ACM Digital Library. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els17 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. Important dates: - 30 Jan 2017 Submission deadline - 27 Feb 2017 Notification of acceptance - 20 Mar 2017 Final papers due - 03-04 Apr 2017 Symposium Programme chair: Alberto Riva, University of Florida, USA Programme committee: Marco Antoniotti, Università Milano Bicocca, Italy Marc Battyani, FractalConcept Theo D'Hondt, Vrije Universiteit Brussel, Belgium Marc Feeley, Université de Montreal, Canada Stelian Ionescu, Google Rainer Joswig, Independent Consultant, Germany António Menezes Leitão, Technical University of Lisbon, Portugal Nick Levine, RavenPack Henry Lieberman, MIT, USA Mark Tarver, Shen Programming Group Jay McCarthy, University of Massachusetts Lowell, USA Christian Queinnec, Université Pierre et Marie Curie, France François-René Rideau, Bridgewater Associates, USA Nikodemus Siivola, ZenRobotics Ltd Alessio Stalla, Università degli Studi di Genova, Italy Search Keywords: #els2017, ELS 2017, ELS '17, European Lisp Symposium 2017, European Lisp Symposium '17, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2017, European Lisp Conference '17 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Feature request: dlopen(NULL, ...
by Michael Fox 03 Jan '17

03 Jan '17

I was wondering if I could get some feeback on an ECL feature request that I posted here: https://gitlab.com/embeddable-common-lisp/ecl/issues/336 <https://gitlab.com/embeddable-common-lisp/ecl/issues/336> Here is the text: I would like to be able to call functions using dynamic FFI in the program into which ECL has been embedded. In Linux, you can do this by calling `dlopen` with `NULL` for the filename. > If filename is NULL, then the returned handle is for the main program. http://man7.org/linux/man-pages/man3/dlopen.3.html Looking at ECL source code, it does not seem to be supported. `dlopen` is called in `c/ffi/libraries.d` like this: char *filename_string = (char*)filename->base_string.self; #ifdef HAVE_DLFCN_H block->cblock.handle = dlopen(filename_string, RTLD_NOW|RTLD_GLOBAL); So, I guess there's no way to set `filename_string = NULL`. One way to do it would be to say if you call (ffi:load-foreign-library "") Then it will skip the checks to see if the file exists and just call `dlopen(NULL, ...` Another way would be to make a new function `ffi:load-main-program`. I don't have any suggestions as to which would be better as I am very new to Lisp. Thank you for your attention.

2 1

ECL does not support docstrings for functions created with flet, labels or lambda. Why?
by Alexander Artemenko 03 Jan '17

03 Jan '17

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. -- Alexander Artemenko (a.k.a. Svetlyak 40wt) Blog: http://dev.svetlyak.ru

2 1

Bad slot inheritance in ECL
by Faré 28 Dec '16

28 Dec '16

I'm facing an "interesting" bug in ECL: in my branch of cffi at https://github.com/fare/cffi I try to define a static-image-op that has gather-operation 'compile-op and gather-type :object because I want to force all objects to be linked, and using the same 'lib-op and :static-library as image-op cause objects unreferenced by ECL to be dropped. However, though I override these slots in my defclass, they don't seem effective. (require "asdf") (asdf:load-system :cffi-toolchain) (in-package :cffi-toolchain) (uiop-debug) (defclass foo-op (image-op) ((gather-type :initform :object :allocation :class))) (defun g (o) (asdf/bundle::gather-type (make-operation o))) (DBG :foo (g 'image-op) ;==> :static-library, as expected (g 'static-image-op) ;==> :static-library, but expected :object (g 'static-program-op) ;==> :static-library, but expected :object (g 'foo-op)) ;==> :static-library, but expected :object I tried to extract a smaller test case by recreating in a file the hierarchy of static-image-op, keeping only the definitions and overrides for slot gather-type, but then it worked. Maybe the combination of eval-when's and/or the compilation and loading play a role in making the bug happen. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The only way for a reporter to look at a politician is down. — H.L. Mencken

2 4

Re: Statically linking C code into ECL
by Daniel Kochmański 27 Dec '16

27 Dec '16

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&Cybernethics• 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

3 7

maxima-5.39.0/ecl-16.1.3 new testsuite failure
by Andrey G. Grozin 20 Dec '16

20 Dec '16

Hello *, There is a new testsuite failure in maxima-5.39.0 compiled with ecl-16.1.3: Running tests in rtest16: ********************** Problem 561 (line 2153) *************** Input: 2 - %pi ev(closeto(li (1.0 %i) - (------ + %i 0.915965594177219), 1.3878e-16), numer) 2 48 Result: error-catch This differed from the expected result: true 612/613 tests passed With ecl-16.1.2 there were no unexpected failures in the maxima testsuite. Andrey

3 5

[ECL 16.1.3]
by Daniel Kochmański 19 Dec '16

19 Dec '16

Dear All, ECL 16.1.3 has been released today. For more information please see the announcement: https://common-lisp.net/project/ecl/posts/ECL-1613-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

3 4

What is the proper way to pass a void* to a C++ instance?
by Ryan 14 Dec '16

14 Dec '16

Hello all, I'm working on a C++ project. For example let's say I have a class called MyClass In C++ I might have void* ptr = new MyClass(); // Assume default constructor What is the proper way to turn ptr into a cl_object? What is the proper way to decode the encoded cl_object back to C++'s void pointer so I can recast it? I've read the documentation and tried a bunch of things. Finally giving in and asking for a bit of direction since it's not working as I'd expect. I was using ecl_make_pointer(ptr) to try and make a cl_object I was using ecl_to_pointer([formerly created cl_object here]) to try and convert the cl_object pointer to a C++ void* Maybe the bug is elsewhere or I'm not understanding... Sincerely, Ryan

2 3