Re: [Ecls-list] RC 14.4.1 almost ready
On Fri, Apr 26, 2013 at 11:36 AM, Matthew Mondor wrote: > Then everything works fine. Unless I'm mistaken, this is a standard > interface, which is not likely to change unexpectedly? > Yes. The problem with setenv is that the value of the TMP translation is set up during boot time, before your code is evaluated. You may rely on the current interface, though. -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- 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_apr___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Tue, 16 Apr 2013 09:18:21 -0400
Matthew Mondor wrote:
> On Sat, 13 Apr 2013 22:22:21 -0400
> Matthew Mondor wrote:
>
> > If that's not already possible, do you think that it would be a good
> > idea to also configure the temporary path via a variable, such that it
> > can be set in ~/.eclrc ?
>
> Shortly after posting this, I realized that EXT:SETENV was already
> enough for this purpose :)
I noticed that if I use:
$ TMPDIR=/var/tmp /usr/local/ecl/bin/ecl
> (load "httpd")
Everything works fine, however, with in ~/.eclrc:
(ext:setenv "TMPDIR" "/var/tmp/")
$ ktrace /usr/local/ecl/bin/ecl
> (ext:getenv "TMPDIR")
"/var/tmp"
> (load "httpd")
Then the mmap(2) EPERM error is issued, with ktrace showing that
"/tmp/" is still used. I then noticed that the translation is assigned
from the environment variable before ~/.eclrc is evaluated in
config.lsp.in.
However, if using instead in ~/.eclrc:
(setf (logical-pathname-translations "TMP")
`(("**;*.*" ,(format nil "~A/**/*.*" "/var/tmp"
Then everything works fine. Unless I'm mistaken, this is a standard
interface, which is not likely to change unexpectedly?
Thanks again,
--
Matt
--
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_apr
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Sat, 13 Apr 2013 22:22:21 -0400 Matthew Mondor wrote: > If that's not already possible, do you think that it would be a good > idea to also configure the temporary path via a variable, such that it > can be set in ~/.eclrc ? Shortly after posting this, I realized that EXT:SETENV was already enough for this purpose :) -- Matt -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Sun, 14 Apr 2013 12:20:08 +0200 Juan Jose Garcia-Ripoll wrote: > On Sun, Apr 14, 2013 at 4:22 AM, Matthew Mondor > wrote: > > > Immediately I remembered that /tmp/ is a memory filesystem mounted with > > a no-exec option, > > > > Is this a general strategy in NetBSD? The only reason we unfortunately must > rely on a temporary directory for loading FASL files is that the dynamic > linker only works on a filename based hash, without noticing time stamps. > This means that if a user loads a FASL and this FASL is recompiled, relying > just on the dynamic linker would result on this last fasl not being loaded, > as the original one was already in memory. Yes I understand about that limitation, and you probably don't have to worry as it's not a NetBSD default, but a custom configuration. The important is that ECL can be configured consequently, which is currently possible using the TMPDIR environment variable, fortunately. Thanks, -- Matt -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Sun, Apr 14, 2013 at 4:22 AM, Matthew Mondor wrote: > Immediately I remembered that /tmp/ is a memory filesystem mounted with > a no-exec option, > Is this a general strategy in NetBSD? The only reason we unfortunately must rely on a temporary directory for loading FASL files is that the dynamic linker only works on a filename based hash, without noticing time stamps. This means that if a user loads a FASL and this FASL is recompiled, relying just on the dynamic linker would result on this last fasl not being loaded, as the original one was already in memory. -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Sun, 14 Apr 2013 01:26:23 +0200 Juan Jose Garcia-Ripoll wrote: > On Sat, Apr 13, 2013 at 9:07 PM, Matthew Mondor > wrote: > > > Hmm I'll have to do some more tests I guess. It's possible that my git > > tree isn't properly in sync with yours, although "git pull" reports > > that it's up to date. > > > > There were some tiny bugs left out in the new code, which can now compile > files in Windows with data that exceeds 65kb. Testing it on OS X and > Windows seems to work, but I still have to go through the whole release > process. ASDF now loads fine and SLIME also builds fine and works, thanks for the quick fixes! A strange thing was that even after these fixes, at first ASDF loaded fine, but somehow the SLIME build still failed the same way as before. It succeeded several times afterwards. Then I noticed that the crow-httpd build also failed with mmap errors (the httpd I had written for ECL). So I noticed after a few tests that often loading more than one fasl, or even a single one twice in a row failed: $ cat hello.lisp (defun hello () (format t "Hello, world!~%")) $ /usr/local/ecl/bin/ecl [...] > (compile-file "hello") ;;; ;;; Compiling hello. ;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0 ;;; ;;; Compiling (DEFUN HELLO ...). ;;; End of Pass 1. ;;; Emitting code for HELLO. ;;; Finished compiling hello. ;;; #P"/home/mmondor/work/mmsoftware/cl/server/hello.fas" NIL NIL > (load "hello") #P"/home/mmondor/work/mmsoftware/cl/server/hello.fas" > (hello) Hello, world! NIL > (load "hello") Condition of type: SIMPLE-ERROR LOAD: Could not load file #P"/home/mmondor/work/mmsoftware/cl/server/hello.fas" (Error: "mmap of entire address space failed: Permission denied") Available restarts: 1. (RESTART-TOPLEVEL) Go back to Top-Level REPL. Broken at SI:BYTECODES. [Evaluation of: (LOAD "hello")] In: #. >> With the last official release, built with the same gmp and boehm-gc: $ ecl ;;; Loading #P"/usr/pkg/lib/ecl-12.12.1/asdf.fas" ;;; Loading #P"/usr/pkg/lib/ecl-12.12.1/cmp.fas" ECL (Embeddable Common-Lisp) 12.12.1 (git:UNKNOWN) 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: #. > (compile-file "hello") ;;; ;;; Compiling hello. ;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0 ;;; ;;; Compiling (DEFUN HELLO ...). ;;; End of Pass 1. ;;; Emitting code for HELLO. ;;; Finished compiling hello. ;;; #P"/home/mmondor/work/mmsoftware/cl/server/hello.fas" NIL NIL > (load "hello") ;;; Loading #P"/home/mmondor/work/mmsoftware/cl/server/hello.fas" #P"/home/mmondor/work/mmsoftware/cl/server/hello.fas" > (load "hello") ;;; Loading #P"/home/mmondor/work/mmsoftware/cl/server/hello.fas" #P"/home/mmondor/work/mmsoftware/cl/server/hello.fas" > (hello) Hello, world! NIL > ^D I then assumed that there must be something odd going on with the loader, so used ktrace(1) on the process to get a clue: First load: 8032 1 ecl CALL open(0x26014a8,0,0x2f2f2f2f2f2f2f2f) 8032 1 ecl NAMI "/home/mmondor/work/mmsoftware/cl/server/hello.fas" 8032 1 ecl RET open 5 8032 1 ecl CALL __fstat50(5,0x7f7fc7b0) 8032 1 ecl RET __fstat50 0 8032 1 ecl CALL mmap(0,0x1000,1,1,5,0,0) 8032 1 ecl RET mmap 140187598168064/0x7f7ff7fda000 8032 1 ecl CALL munmap(0x7f7ff7fda000,0x1000) 8032 1 ecl RET munmap 0 8032 1 ecl CALL mmap(0,0x201000,5,0x1502,5,0,0) 8032 1 ecl RET mmap 140187535409152/0x7f7ff440 8032 1 ecl CALL mmap(0x7f7ff460,0x1000,3,0x12,5,0,0) 8032 1 ecl RET mmap 140187537506304/0x7f7ff460 8032 1 ecl CALL mmap(0x7f7ff4601000,0,3,0x1012,0x,0,0) 8032 1 ecl RET mmap 140187537510400/0x7f7ff4601000 8032 1 ecl CALL mprotect(0x7f7ff4401000,0x1ff000,0) 8032 1 ecl RET mprotect 0 8032 1 ecl CALL close(5) 8032 1 ecl RET close 0 Second load: 8032 1 ecl CALL open(0x2934ce8,0,0x2f2f2f2f2f2f2f2f) 8032 1 ecl NAMI "/tmp/ecl08032a" 8032 1 ecl RET open 5 8032 1 ecl CALL __fstat50(5,0x7f7fc7b0) 8032 1 ecl RET __fstat50 0 8032 1 ecl CALL mmap(0,0x1000,1,1,5,0,0) 8032 1 ecl RET mmap 140187598168064/0x7f7ff7fda000 8032 1 ecl CALL munmap(0x7f7ff7fda000,0x1000) 8032 1 ecl RET munmap 0 8032 1 ecl CALL mmap(0,0x201000,5,0x1502,5,0,0) 8032 1 ecl RET mmap -1 errno 13 Permission denied 8032 1 ecl CALL close(5) 8032 1 ecl RET close 0 Immediately I remembered that /tmp/ is a memory filesystem mounted with a no-exec option, which was probably the issue, as th
Re: [Ecls-list] RC 14.4.1 almost ready
On Sat, Apr 13, 2013 at 9:07 PM, Matthew Mondor wrote: > Hmm I'll have to do some more tests I guess. It's possible that my git > tree isn't properly in sync with yours, although "git pull" reports > that it's up to date. > There were some tiny bugs left out in the new code, which can now compile files in Windows with data that exceeds 65kb. Testing it on OS X and Windows seems to work, but I still have to go through the whole release process. -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Sat, 13 Apr 2013 20:06:45 +0200 Juan Jose Garcia-Ripoll wrote: > On Sat, Apr 13, 2013 at 7:44 PM, Matthew Mondor > wrote: > > > ;;; Loading #P"/usr/local/ecl/lib/ecl-13.4.1/profile.fas" > > ;; > > ;; Error while loading > > /home/mmondor/.slime/fasl/2012-11-08/ecl-13.4.1-173fb92e-unix-x86_64/swank-ecl.fas: > > ;; LOAD: Could not load file > > #P"/usr/local/ecl/lib/ecl-13.4.1/profile.fas" (Error: "mmap of entire > > address space failed: Permission denied") > > ;; Aborting. > > > > Did you clean old files? ECL should not be using mmap any more. Interestingly, /home/mmondor/.slime/fasl/2012-11-08/ecl-13.4.1-173fb92e-unix-x86_64/swank-ecl.fas doesn't exist at that point, so the reported error is probably bogus. It seems that there's an error linking the fasl from the generated files. I'll try to manually invoke the commands and see where and why it fails, but I must leave so will resume later. $ ls -1 ~/.slime/fasl/2012-11-08/ecl-13.4.1-173fb92e-unix-x86_64/ swank-backend.c swank-backend.data swank-backend.eclh swank-backend.fas swank-backend.o swank-ecl.c swank-ecl.data swank-ecl.eclh swank-ecl.o swank-source-file-cache.c swank-source-file-cache.data swank-source-file-cache.eclh swank-source-file-cache.fas swank-source-file-cache.o swank-source-path-parser.c swank-source-path-parser.data swank-source-path-parser.eclh swank-source-path-parser.fas swank-source-path-parser.o -- Matt -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Sat, 13 Apr 2013 20:06:45 +0200
Juan Jose Garcia-Ripoll wrote:
> On Sat, Apr 13, 2013 at 7:44 PM, Matthew Mondor
> wrote:
>
> > ;;; Loading #P"/usr/local/ecl/lib/ecl-13.4.1/profile.fas"
> > ;;
> > ;; Error while loading
> > /home/mmondor/.slime/fasl/2012-11-08/ecl-13.4.1-173fb92e-unix-x86_64/swank-ecl.fas:
> > ;; LOAD: Could not load file
> > #P"/usr/local/ecl/lib/ecl-13.4.1/profile.fas" (Error: "mmap of entire
> > address space failed: Permission denied")
> > ;; Aborting.
> >
>
> Did you clean old files? ECL should not be using mmap any more.
Yes I deleted completely both /usr/local/ecl/ and ~/.slime/fasl/
Hmm I'll have to do some more tests I guess. It's possible that my git
tree isn't properly in sync with yours, although "git pull" reports
that it's up to date.
In the c/ directory, there are very few existing references to mmap,
and these do not appear to be related to the loading code:
c/Makefile.in: ffi/libraries.o ffi/backtrace.o ffi/mmap.o ffi/cdata.o \
c/alloc.d:#define USE_MMAP
c/alloc.d:#if defined(USE_MMAP)
c/alloc.d:#if defined(USE_MMAP)
c/alloc.d: result = mmap(0x2E00, bytes, PROT_READ | PROT_WRITE,
c/alloc.d: result = mmap(data_end, bytes, PROT_READ | PROT_WRITE,
c/alloc.d:#ifdef USE_MMAP
c/alloc.d:#endif /* USE_MMAP, MSDOS, or HAVE_ULIMIT */
c/alloc.d:#ifdef USE_MMAP
c/alloc_2.d:/* When not using threads, "env" is mmaped or statically
allocated. */
c/ffi/cdata.d:map = si_mmap(3, filename, @':direction', @':input');
c/ffi/cdata.d:array = si_mmap_array(map);
c/ffi/mmap.d:mmap.d -- Mapping of binary files.
c/ffi/mmap.d:@(defun ext::mmap (filename
c/ffi/mmap.d:pa = mmap(0, len, c_prot, c_flags, fd,
c/ffi/mmap.d:FElibc_error("EXT::MMAP failed.", 0);
c/ffi/mmap.d:si_mmap_array(cl_object map)
c/main.d:* allocated using mmap or some other method. We could do more,
cleaning
c/main.d:* the environment using mmap or the garbage collector.
c/main.d: output = mmap(0, sizeof(*output), PROT_READ | PROT_WRITE,
c/symbols_list.h:{EXT_ "MMAP", EXT_ORDINARY, si_mmap, -1, OBJNULL},
c/symbols_list.h:{EXT_ "MMAP-ARRAY", EXT_ORDINARY, si_mmap_array, 1, OBJNULL},
c/symbols_list2.h:{EXT_ "MMAP","si_mmap"},
c/symbols_list2.h:{EXT_ "MMAP-ARRAY","si_mmap_array"},
c/unixint.d:# error "We cannot use the mmap code without siginfo"
And there are no more references to mmap in lsp/
I'll report again after I have the opportunity to test using a newly
freshly synchronized repository. It's also possible that it's the OS
that fails to mmap a potentially malformed ELF object that it attempts
to dynamically load, but it's less likely, especially if ECL no longer
tempers with the final objects.
--
Matt
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Sat, Apr 13, 2013 at 7:44 PM, Matthew Mondor wrote: > ;;; Loading #P"/usr/local/ecl/lib/ecl-13.4.1/profile.fas" > ;; > ;; Error while loading > /home/mmondor/.slime/fasl/2012-11-08/ecl-13.4.1-173fb92e-unix-x86_64/swank-ecl.fas: > ;; LOAD: Could not load file > #P"/usr/local/ecl/lib/ecl-13.4.1/profile.fas" (Error: "mmap of entire > address space failed: Permission denied") > ;; Aborting. > Did you clean old files? ECL should not be using mmap any more. -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Sat, 13 Apr 2013 12:03:47 -0400 Matthew Mondor wrote: > On Sat, 13 Apr 2013 00:16:19 +0200 > Juan Jose Garcia-Ripoll wrote: > > > I have change this, though, and #+unix is now reported for all what is now > > considered unix. > > The build now succeeds, however: > > ninja$ /usr/local/ecl/bin/ecl > ;;; Loading #P"/usr/local/ecl/lib/ecl-13.4.1/asdf.fas" > An error occurred during initialization: > Package ((TION . #)) referenced in compiled file > NIL > but has not been created. > ninja$ Also if attempting to build and load slime: ;;; Loading #P"/usr/local/ecl/lib/ecl-13.4.1/profile.fas" ;; ;; Error while loading /home/mmondor/.slime/fasl/2012-11-08/ecl-13.4.1-173fb92e-unix-x86_64/swank-ecl.fas: ;; LOAD: Could not load file #P"/usr/local/ecl/lib/ecl-13.4.1/profile.fas" (Error: "mmap of entire address space failed: Permission denied") ;; Aborting. There might be some problem with the new way data is written and/or loaded. But interestingly on a virgin REPL, I can (require :profile) and it loads without error. -- Matt -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Sat, 13 Apr 2013 00:16:19 +0200
Juan Jose Garcia-Ripoll wrote:
> I have change this, though, and #+unix is now reported for all what is now
> considered unix.
The build now succeeds, however:
ninja$ /usr/local/ecl/bin/ecl
;;; Loading #P"/usr/local/ecl/lib/ecl-13.4.1/asdf.fas"
An error occurred during initialization:
Package ((TION . #)) referenced in compiled file
NIL
but has not been created.
ninja$
I'm not sure if the problem really is in asdf though, the last
modification seems to be from April 2nd, and I've seen a recent
confirmation of a working system on this list recently.
ECL starts fine if I remove (require :asdf) from ~/.eclrc, and if I
manually do this at the REPL the same error occurs. Other systems can
be loaded fine, (require :sockets) works for instance.
I'm not sure if this is related, but I found that build/ext/asdf.data
has a split which corresponds to a place with a "tion":
[...]
"patfmt \"~@<~? (will be skipped)~@:>\") (asdf/configuration::condition-format
asdf"
"/configura " };
static const struct ecl_base_string compiler_data_text2[] = {
(int8_t)t_base_string, 0, ecl_aet_bc, 0,
ECL_NIL, (cl_index)65531, (cl_index)65531,
(ecl_base_char*)
"tion::c) (list* (asdf/configuration::condition-form asdf/configuration::c)
(asdf"
"/configuration::condition-location asdf/configuration::c)
(asdf/configuration::c"
"ondition-arguments asdf/configuration::c :name si::report-function)
(:initar"
[...]
strings asdf.o:
register-clear-configuration-hook #:resolve-location #:location-designator-p
#:location-function-p #:*here-directory* #:resolve-relative-location
#:resolve-absolut
e-location #:upgrade-configuration) :intern nil :recycle (:asdf/configuration
:asdf) :mix nil :reexport nil :unintern nil) (:initform (lambda
(asdf/configuration::
c asdf/configuration::s) (format asdf/configuration::s
(asdf/common-lisp::compatfmt "~@<~? (will be skipped)~@:>")
(asdf/configuration::condition-format asdf/confi
gura
tion::c) (list* (asdf/configuration::condition-form asdf/configuration::c)
(asdf/configuration::condition-location asdf/configuration::c)
(asdf/configuration::cond
ition-arguments asdf/configuration::c :name si::report-function) (:initargs
(:form) :readers (asdf/configuration::condition-form) :name
asdf/configuration::for
m) (:initargs (:location) :readers (asdf/configuration::condition-location)
:name asdf/configuration::location) (:initargs (:format) :readers
(asdf/configuration::
Thanks,
--
Matt
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Sat, 13 Apr 2013 00:16:19 +0200 Juan Jose Garcia-Ripoll wrote: > There is a bit of confusion here. ECL simply exports several C macros as > features. :unix is exported because the compiler reports unix, not because > it detects a unix-compatible system. Actually this is a very old definition > and it probably meant sco unix back then, as we also have an opposing BSD > definition in the same file. > > I have change this, though, and #+unix is now reported for all what is now > considered unix. It's then strange that ASDF appears to rely on it... I'll try to report soon about if it now builds. Thank you very much, -- Matt -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Wed, Apr 3, 2013 at 5:49 AM, Matthew Mondor wrote: > After now rereading my message, I want to mention that I don't think > that :UNIX should be reported instead of :NETBSD > There is a bit of confusion here. ECL simply exports several C macros as features. :unix is exported because the compiler reports unix, not because it detects a unix-compatible system. Actually this is a very old definition and it probably meant sco unix back then, as we also have an opposing BSD definition in the same file. I have change this, though, and #+unix is now reported for all what is now considered unix. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Tue, 2 Apr 2013 19:29:50 -0400 Matthew Mondor wrote: > On Tue, 2 Apr 2013 17:46:43 -0400 > Matthew Mondor wrote: > > > I cannot have a deeper look immediately, but should try to investigate > > it soon... > > If I understand, ASDF expects *FEATURE* :UNIX, but ECL exports :NETBSD > not :UNIX > > (defun os-unix-p () > (or #+abcl (featurep :unix) > #+(and (not abcl) (or unix cygwin darwin)) t)) After now rereading my message, I want to mention that I don't think that :UNIX should be reported instead of :NETBSD however, I think that having a more descriptive name like :NETBSD is useful. Perhaps that :UNIX or :POSIX should also be exported in the case of unix/linux/bsd systems, though, and ASDF could keep relying on :POSIX or :UNIX ... It's not a very recent SBCL that I have, but it appears on NetBSD to provide: :UNIX :BSD :NETBSD :ELF, other than a bunch of OS-PROVIDES-. As for x86-64, SBCL provides :X86-64 while ECL provides :X86_64. CLISP provides very little system-specific *features*, but also provides :UNIX (:WORD-SIZE=64 :PC386 :UNIX). Thanks, -- Matt -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Tue, 2 Apr 2013 17:46:43 -0400 Matthew Mondor wrote: > I cannot have a deeper look immediately, but should try to investigate > it soon... If I understand, ASDF expects *FEATURE* :UNIX, but ECL exports :NETBSD not :UNIX (defun os-unix-p () (or #+abcl (featurep :unix) #+(and (not abcl) (or unix cygwin darwin)) t)) -- Matt -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Tue, 2 Apr 2013 23:17:10 +0200 Juan Jose Garcia-Ripoll wrote: > On Tue, Apr 2, 2013 at 9:35 PM, Juan Jose Garcia-Ripoll < > juanjose.garciarip...@gmail.com> wrote: > > > If you have a critical bug (two about FORMAT have been reported, but I may > > as well leave them for later), please report. I am trying to prepare a > > release for this week. > > > Sorry, a few patches had not been synchronized and that prevented building > the Windows ports. The RC should be ready now. Although what I just tried to build was ECL from git HEAD, there seems to be a problem, perhaps with ASDF, on NetBSD-6/amd64: [...] ;;; Note: ;;; in file ASDF.LISP, position 64300 ;;; at (WITH-UPGRADABILITY NIL ...) ;;; Checking type of (SI:CONS-CDR #:LOOP-LIST1303) to be LIST ;;; Compiling (WITH-UPGRADABILITY NIL ...). ;;; Compiling (WITH-UPGRADABILITY NIL ...). ;;; Compiling (WITH-UPGRADABILITY NIL ...). ;;; Compiling (WITH-UPGRADABILITY NIL ...). ;;; Compiling (WITH-UPGRADABILITY NIL ...). ;;; Compiling (WITH-UPGRADABILITY NIL ...). ;;; Compiling (WITH-UPGRADABILITY NIL ...). Condition of type: SIMPLE-ERROR Congratulations for trying XCVB on an operating system that is neither Unix, nor Windows, nor even Genera. Now you port it. Available restarts: 1. (ABORT) ABORT Top level in: #. > I cannot have a deeper look immediately, but should try to investigate it soon... Thanks, -- Matt -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RC 14.4.1 almost ready
On Tue, Apr 2, 2013 at 9:35 PM, Juan Jose Garcia-Ripoll < juanjose.garciarip...@gmail.com> wrote: > If you have a critical bug (two about FORMAT have been reported, but I may > as well leave them for later), please report. I am trying to prepare a > release for this week. Sorry, a few patches had not been synchronized and that prevented building the Windows ports. The RC should be ready now. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
