gmane.lisp.ecl.general

Re: SIMPLE-ERROR: In interpreted code, attempted to call a foreign function but ECL was build without support for that.

Juan Jose Garcia-Ripoll — 2013-05-24T12:54:30

On Wed, May 22, 2013 at 3:54 PM, Dietrich Bollmann
<dietrich-55Sq3ERg400gsBAKwltoeQ< at >public.gmane.org>wrote:


I need some time to investigate why this happens -- at least the compiled
FFI should be available on every port :-/

Re: Filenames encoding

Juan Jose Garcia-Ripoll — 2013-05-23T19:09:18


ECL does not do locales: it only does Unicode or Latin-1, depending on how
you build it. You may use other codepages for data and external
representations for streams, but you have to tell ECL which representation
to use explicitly (except for the terminal on Windows)

However, filenames are not just about locales. The problem with filenames
is that there is not a unique representation for filenames with extended
characters, given that all filesystems define names based on bytes. If you
read the link Matthew pass you, there I commented a very precise problem:
on Windows, OS X and on Linux, programs encode filenames using utf-8, but
there is not a unique representation for this, because such encodings
include (or not) reordering of characters (normalization). Thus you may
create a file with a Unicode name and retrieve that name from the operating
system and it would be a non-equalp string (equal under Unicode's
normalized string comparisons, though)

I have not yet solved this problem and you may complain,

Re: Filenames encoding

Stanislav Frolov — 2013-05-23T13:43:15

Thank you for solution Matt.

I understand OS and locale specifics, but this solution seems an ugly low-level 
hack for cross-platform high-level language. Am I wrong? Information about OS 
is available in compilation phase, about locale - in runtime.

Now I have installed ecl and clozurecl. And both have problems with non-ASCII 
filenames. ECL throws error while coerce string to base-string, Clozurecl 
writes data to file with name in wrong encoding. I never use cyrilic filenames 
before, but my clients use it. And this problem is a surprise for us :)

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
________________________________________

Re: Filenames encoding

Matthew Mondor — 2013-05-23T12:10:54

On Thu, 23 May 2013 08:01:51 -0400
Matthew Mondor <mm_lists-xHKImXiT534xnpGSZB1jBA< at >public.gmane.org> wrote:


Correction: UCS-4, not 32 :)

Re: Filenames encoding

Matthew Mondor — 2013-05-23T12:06:45

On Thu, 23 May 2013 08:01:51 -0400
Matthew Mondor <mm_lists-xHKImXiT534xnpGSZB1jBA< at >public.gmane.org> wrote:


I found the reference I was looking for only after posting the previous
message; also see:

http://www.mail-archive.com/ecls-list-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org/msg02409.html
http://sourceforge.net/p/ecls/bugs/237/

Re: Filenames encoding

Matthew Mondor — 2013-05-23T12:01:51

On Thu, 23 May 2013 14:02:58 +0400
Stanislav Frolov <frolosofsky< at >gmail.com> wrote:


Unfortunately, path/file names encoding are OS-specific, file-system
specific and may be locale specific...

POSIX filenames may contain bytes which are often used to hold UTF-8
characters on filesystems which allow this, but that too is only one of
the available encoding options, and unfortunately filenames cannot be
tagged with the encoding type, except if using an uncommon convention
like is used in RFC 2047 for message headers, or non-portable
attributes/subfiles, so files named by others on their systems may not
display correctly locally on the same OS and FS).  However, because
POSIX syscalls expect C strings, UTF-8 is popular when the various
single-byte encodings are not used.

My Windows experience is limited, but I think that it usually uses
UTF-16 where unicode strings are possible.

ECL internally stores unicode strings using UCS-32, and the base-string
only accepts character codes 0-255.


This might not be the

Filenames encoding

Stanislav Frolov — 2013-05-23T10:02:58

Hello all.

I have trouble with filename encoding on Linux (utf-8) and windows (cp866?).

Examples

There is one file in directory: "тест" (mean "test" in russian).
(directory "*") => (#P"/path/to/ÑÐµÑÑ")

Let's try create pathname from cyrilic utf-8 filename:
(pathname "тест")
Error: Cannot coerce string тест to a base-string

How to set filenames encoding properly?


locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=POSIX
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Ecl 13.4.1. With new ecl I have infinite recursion with multithreads again. 
I'll report it later.

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring

Re: SIMPLE-ERROR: In interpreted code, attempted to call a foreign function but ECL was build without support for that.

Dietrich Bollmann — 2013-05-22T13:54:14

Hi Juan,

On Tue, May 21, 2013 at 6:13 PM, Juan Jose Garcia-Ripoll <
juanjose.garciaripoll-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


Here what I get when trying this on windows:

===
 $ /cygdrive/c/Users/dietrich/home/cs/lang/lisp/ecl/64/git/install/ecl.exe
;;; Loading
"E:/Users/dietrich/home/cs/lang/lisp/ecl/ecl/64/git/library/quicklisp/install/setup.lisp"
;;; Loading
#P"C:/Users/dietrich/home/cs/lang/lisp/ecl/64/git/install/asdf.fas"
ECL (Embeddable Common-Lisp) 13.4.1
(git:0e93edfc7aefe16bb5b0fc20d4735ae69ac346ce)
Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
Copyright (C) 1993 Giuseppe Attardi
Copyright (C) 2000 Juan J. Garcia-Ripoll
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: #<process TOP-LEVEL>.
To load "cffi":
  Load 1 ASDF system:
    cffi
; Loading "cffi"

(:CFFI)

;;; Compiling foo.lsp
;;; Compiling #<input stream foo.lsp>
;;; Loading
"E:/Users/dietrich/home/cs/lang/lisp/ecl/ec

Re: SIMPLE-ERROR: In interpreted code, attempted to call a foreign function but ECL was build without support for that.

Juan Jose Garcia-Ripoll — 2013-05-21T09:13:50

On Mon, May 20, 2013 at 4:15 AM, Dietrich Bollmann
<dietrich-55Sq3ERg400gsBAKwltoeQ< at >public.gmane.org>wrote:


The CFFI model is simply too rigid: they assume that libraries can be
loaded at run time, always. Instead ECL supports also a model in which
libraries are linked with the compiled code, being available that way. I
fear there is no way to work around this but using ECL's own FFI mingled
with CFFI

To load "cffi":
  Load 1 ASDF system:
    cffi
; Loading "cffi"

(:CFFI)

;;;
;;; Compiling foo.lsp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; Compiling (DEFCFUN (MYCOS "cos") ...).
;;; End of Pass 1.
;;; Emitting code for MYCOS.
;;; Finished compiling foo.lsp.
;;;
;;; Loading "/Users/jjgarcia/foo.fas"
C:    cos(3.2000000000000001777d+0) = -0.9982947757947531
Lisp: cos(3.2000000000000001777d+0) = -0.9982947757947531
#P"/Users/jjgarcia/foo.fas"
NIL
NIL


----

;;; Nothing special about the "CFFI-USER" package.  We're just
;;; using it as a substitute for your own CL package.
(defpackage

Re: generated shared library does not contain thedefined function

Ala'a Mohammad — 2013-05-20T13:36:23

I mistakenly assumed that 'defined protocol' was for when linking with
libecl. and thought that the c:build-shared-library was similar to
LispWorks delivered shared libraries (see the attached example that I was
trying to port from LW).

So now I need to execute that defined protocol, and then:
- load my library (my CL library)
- define a result object with cl_object.
- create a CL array object via 'si_make_array'
- fill the created array with the data.
- call the the function sum_array and store the result in the result object.

Thanks to all for the help,

Ala'a


LW shared library example:

---- example.lisp
(in-package "CL-USER")

(fli:define-foreign-callable ("say_hello" :result-type :void)
    ()
  (write-line "Hello From Shared Library.")
  (force-output)
  (values))

(fli:define-foreign-callable ("square" :result-type :int)
    ((num :int))
  (* num num))

(fli:define-foreign-callable ("sum_array" :result-type :int)
    ((nums (:c-array :int 10))
     (size :int))
  (loop for i from 0 below size

Re: SIMPLE-ERROR: In interpreted code, attempted to call a foreign function but ECL was build without support for that.

Dietrich Bollmann — 2013-05-20T02:15:20

Hi Juanjo,

faster) would be to compile your code before loading it: it will just work
even without dffi. The FFI is only needed to create the wrappers, but once
they have been compiled they work regardless of the underlying
implementation.

I tried to do so - but for some reason I never get it work...

A very simple HOWTO explaining step by step how to compile and load a
simple example file ( for instance the sin / cos example in
examples/ffi/cffi.lsp ) would be most helpful!

I tried all kind of permutations of (compile-file ...) with different
parameters, together and without (require :cmp), etc. but I seem to be
unable to make sense out of the documentation and error messages and always
fail to get a working example...

I am currently trying to understand the msvc build files of ECL - but would
be very grateful about a faster solution...

Anyway, thank you very much for your fast and detailed answer!  Your
one-man support is quite impressive - actually much more than the
"professional" (and commercial) s

Re: generated shared library does not contain thedefined function

Juan Jose Garcia-Ripoll — 2013-05-19T21:08:20


There are many examples out there how to call Common Lisp functions. Indeed
many in this very same mailing list explain how to call cl_boot(),
ecl_read_from_cstring(), cl_funcall() and friends. Directly calling a
Common Lisp function compiled by you by name is not recommended.



In order to have compile-time side effects you need to fix the name and use
(eval-when (:compile-toplevel)
 (proclaim '(si::c-export-fname sum-array)))

  // summ-array

Broken, broken, broken. ECL has to be bootstrapped before calling any
function. This involves a well defined protocol that starts by calling
cl_boot() with two arguments and, optionally, registering any additional
threads from which code may be invoked. Then you can start using Common
Lisp functions and objects.

Juanjo

Re: SIMPLE-ERROR: In interpreted code, attempted to call a foreign function but ECL was build without support for that.

Juan Jose Garcia-Ripoll — 2013-05-19T20:47:51

On Sun, May 19, 2013 at 12:40 PM, Dietrich Bollmann
<dietrich-55Sq3ERg400gsBAKwltoeQ< at >public.gmane.org>wrote:


Currently ECL does not support this in the original sources because FFI has
evolved into a very complicated set of sources that cannot be built with
Microsoft's compilers: it demands mingw and other tools.

This may have changed recently, I do not follow libffi so closely, but, as
I said, the problem is not that ECL cannot be linked against libffi using
Visual Studio, it is just that I do not know how to do this integration
smoothly without further dependencies.

A more reasonable alternative that works on all ports (and is much faster)
would be to compile your code before loading it: it will just work even
without dffi. The FFI is only needed to create the wrappers, but once they
have been compiled they work regardless of the underlying implementation.

Juanjo

SIMPLE-ERROR: In interpreted code, attempted to call a foreign function but ECL was build without support for that.

Dietrich Bollmann — 2013-05-19T10:40:17

Hi,

I am trying to use ECL as scripting language for the 3D modelling software
Rhino3D.  The idea is to call a lisp script with something like

  lisp /path/to/the/script.lisp

from the rhino command shell.  In the lisp script I would make use of the
foreign function interface to call Rhino C++ commands for creating and
manipulating Rhino 3D geometry.

Looking at the sources I had the impression that CFFI is the best way to
make the Rhino C++ API accessible from lisp. (Please tell me if this is not
the case and some other method should be used.)  With CFFI it might be even
possible to generate the lisp wrappers automatically using SWIG.

In order to understand CFFI better I decided to start with the FFI examples
in the ecl/examples/ffi/ directory of the ECL source tree.  But when trying
to compile and load the cffi.lsp example using my 64 bit windows compile of
ECL with

  (compile-file "cffi.lsp" :load t)

I get the following error message:

  In interpreted code, attempted to call a foreign function
   #<

Re: Function type proclaimations not working?

Jason Sewall — 2013-05-16T22:51:39

On Thu, May 16, 2013 at 3:42 PM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Sorry, it wasn't clear to me that it was "old" - I got it from a doc
tree I recently built from the ecl-doc repo. Should such parts be at
least marked with *obsolete* somehow if there is no time for updating?


This seems sensible to me, but it doesn't really explain the warning I
got, does it? Shouldn't the compiler just ignore the proclamation in
that case instead of apparently failing to understand it?

Cheers,
Jason

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Function type proclaimations not working?

Juan Jose Garcia-Ripoll — 2013-05-16T22:42:52



You are looking at the _old_ manual. That section is obsolete, but I did
not have time to go through the whole manual again.

That said, ECL no longer implements unboxed functions. It was very hard to
maintained and lead to code bloat: we had to provide two functions for
every signature, one with Common Lisp objects, another one with unboxed
values. It could be reimplemented using appropriate proclamations, but the
default action was to remove it.

Outside from function arguments, the rest can be fully unboxed, as you see
in the new code body, which is also more readable.

Juanjo

Re: Function type proclaimations not working?

Jason Sewall — 2013-05-16T22:33:38

On Thu, May 16, 2013 at 3:22 PM, Matthew Mondor
<mm_lists-xHKImXiT534xnpGSZB1jBA< at >public.gmane.org> wrote:

Sorry for the missing context; the doc page I got the 'tak' example
from indicates that this is the sort of output you should expect:

   /*      local entry for function TAK                                  */
   static int LI1(register int V1,register int V2,register int V3)
   { VT3 VLEX3 CLSR3
   TTL:
   if (V2 < V1) {
   goto L2;}
   return(V3);
   L2:
   { int V5;
   V5 = LI1((V1)-1,V2,V3);
   { int V6;
   V6 = LI1((V2)-1,V3,V1);
   V3 = LI1((V3)-1,V1,V2);
   V2 = V6;
   V1 = V5;}}
   goto TTL;
   ;;; Note: Tail-recursive call of TAK was replaced by iteration.
   }

Note the signature of Ll1 and the lack of conversion functions. I am
simply interested to see how good the ECL compiler is compared to
hand-coding C, and type information is obviously a large part of that.

Cheers,
Jason

------------------------------------------------------------------------------
AlienVault Unified Security Manageme

Re: Function type proclaimations not working?

Matthew Mondor — 2013-05-16T22:22:56

On Thu, 16 May 2013 15:09:59 -0700
Jason Sewall <jasonsewall-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


Would it be possible to indicate what you expect different below?


Above I can see inline use of < rather than a generic comparison
function call, as well as inline use of -1 instead of a generic
substraction function call, along with the required conversions to
fixnum...

Thanks,

Function type proclaimations not working?

Jason Sewall — 2013-05-16T22:09:59

The docs (III 4.4) give an example for optimizing code based on type
info (which seems to be missing a close paren, by the way):

(eval-when (compile)
  (proclaim '(function tak (fixnum fixnum fixnum) fixnum)))

(defun tak (x y z)
  (declare (fixnum x y z))
  (if (not (< y x))
      z
      (tak (tak (1- x) y z)
       (tak (1- y) z x)
       (tak (1- z) x y))))


ECL 13.4.1 (from HEAD built a few weeks ago) complains "Warning: The
variable name (FIXNUM FIXNUM FIXNUM) is not a symbol."

The resulting c file does not look anything like the example. Did some
behavior change/go away? Even if I add (proclaim '(optimize (speed 3)
(safety 0))), lots of type info doesn't get propagated.

If this is my fault for running things off of HEAD, please tell me to
shut up and I'll do so. Let me know if I can help, too.

Cheers,
Jason

P.S. Here's the C file (or the first part of it, anyway) if I add the
optimize directive to the above:
/*    Compiler: ECL 13.4.1                                          */
/*    Date: 2013/

Re: generated shared library does not contain the defined function

Matthew Mondor — 2013-05-13T23:29:03

On Mon, 13 May 2013 14:33:00 +0400
"Ala'a Mohammad" <amalawi-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


It's possible that you need to use the ECL library to resolve the
function's symbol to the actual C function, or possibly using
ecl_funcall().  I assume that your main application is linked against
libecl, such that you can dlopen() ECL-built libraries.  Normally when
ECL FASL are loaded by ECL, an initialization function is called which
updates the environment such as symbols.  Perhaps that loading a FASL
using the ECL library would also be easier because of this.

But I admit I have no experience with using such ECL-built shared
libraries and custom-loading them.

Re: generated shared library does not contain thedefined function

Ala'a Mohammad — 2013-05-13T17:19:32

Hi,

I've taken it from here:
http://comments.gmane.org/gmane.lisp.ecl.general/2995

and from here:
http://comments.gmane.org/gmane.lisp.ecl.general/2341

and assumed from the messages context that they worked for their posters.

I've also check the following github mirror of ecl (it is a little bit
outdated - January was the last time)
https://github.com/ageneau/ecl-mirror/blob/8ac2ec408cda4334baba1f0f03e8d1fa288ae504/src/cmp/cmpenv-proclaim.lsp#L78

What is the correct one? any documentation link?

Ala'a


On Mon, May 13, 2013 at 8:08 PM, Peter Keller <psilord-hcNo3dDEHLuVc3sceRu5cw< at >public.gmane.org> wrote:

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial._____________________________________