Re: [Ecls-list] Some latest changes
On Mon, Jun 28, 2010 at 2:46 PM, Juan Jose Garcia-Ripoll wrote: > * MAKE-PATHNAME reimplemented to ensure that :CASE is only applied to the > user arguments. > > * NAMESTRING will refuse to produce a string when :NAME is nil and :TYPE is > not. The reason is ".txt" = (make-pathname :name ".txt" :type nil) > > * The implementation of "compiler optimization flags" had to be redone, > because switching on and off flags did not work as expected. > > * Proclamations are also used to deduce the type of a function's arguments > and create argument type checks. > > * Feature :C++ is exported when using a C++ compiler > > * A lot of fixes in ECL's declarations and proclamations, all of them > trivial, but which caused the compiler to complain or generated safety > checks that were not satisfied. For instance > (defun pprint-tabular (... &optional ... tab-size) > (declare (unsigned-byte tab-size)) > ...) > caused PPRINT-TABULAR to fail. This sounds fantastic! Kudos. -- Gaby -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] Regular toplevel functions vs. labels
Hi Juanjo, Is the ECL compilation scheme of functions defined by labels likely to yield better codes than those functions defined at toplevel? -- Gaby -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Some latest changes
On Mon, Jun 28, 2010 at 2:46 PM, Juan Jose Garcia-Ripoll wrote: > * Proclamations are also used to deduce the type of a function's arguments > and create argument type checks. Now that ECL is getting good at using function proclamations for arguments types, is there away to report functions names in diagnostics when a check fail? (SBCL does that, and it is quite helpful for debugging.) -- Gaby -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] Bug in argument checking based on function proclamation
On Mon, Jun 28, 2010 at 2:46 PM, Juan Jose Garcia-Ripoll wrote: > * Proclamations are also used to deduce the type of a function's arguments > and create argument type checks. > Hi Juanjo, The function arguments checking seems to have a bug. The attached testcase (distilled from OpenAxiom) produces the following warnings: > (compile-file "pbug.lisp") ;;; Loading #P"/usr/local/lib/ecl-10.4.2/cmp.fas" ;;; ;;; Compiling pbug.lisp. ;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0 ;;; ;;; Compiling (DEFUN BEGIN-DOLLAR-P ...). ;;; Note: ;;; in file pbug.lisp, position 55 ;;; at (DEFUN BEGIN-DOLLAR-P ...) ;;; In function BEGIN-DOLLAR-P, checking types of arguments X. ;;; Note: ;;; in file pbug.lisp, position 55 ;;; at (DEFUN BEGIN-DOLLAR-P ...) ;;; Unknown type (T). Assuming it is T. ;;; Compiling (DEFUN COMP-FLUIDIZE ...). ;;; Warning: ;;; in file pbug.lisp, position 123 ;;; at (DEFUN COMP-FLUIDIZE ...) ;;; ! Too few arguments for proclaimed function BEGIN-DOLLAR-P ;;; End of Pass 1. ;;; Note: ;;; Refusing to propagate FUNCALL ;;; Note: ;;; Refusing to propagate C-INLINE ;;; Warning: ;;; ! Too few arguments for proclaimed function BEGIN-DOLLAR-P 1. The argument-type in the function proclamation is simple enough that ECL should not be confused. 2. ECL pretends that there are too few arguments for proclaimed BEGIN-DOLLAR-P. Yet, the function was proclaimed to be of arity 1, and there is exactly one argument supplied in the call. What are the notes about propagating FUNCALL and C-INLINE about? -- Gaby pbug.lisp Description: Binary data -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Bug in argument checking based on function proclamation
On Mon, Jun 28, 2010 at 9:13 PM, Matthew Mondor wrote: > I rebuilt an ECL from ECL HEAD to test these new changes. > While building some code which uses function proclamations, there also > was a new problem: I forgot to mention that I could not build OpenAxiom. I do not know whether Maxima uses function type proclamations, and therefore suffers from the same problem. -- Gaby -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Bug in argument checking based on function proclamation
On Thu, Jul 1, 2010 at 4:39 PM, Juan Jose Garcia-Ripoll wrote: > On Tue, Jun 29, 2010 at 2:12 AM, Gabriel Dos Reis > wrote: >> >> On Mon, Jun 28, 2010 at 2:46 PM, Juan Jose Garcia-Ripoll >> wrote: >> > * Proclamations are also used to deduce the type of a function's >> > arguments >> > and create argument type checks. >> > >> The function arguments checking seems to have a bug. > > Thanks a lot for the test case. I identified a problem with how FTYPE > declarations are parsed. I did not detect the problem because I was focusing > on PROCLAIM, not DECLAIM. It should be fixed now, but just started an > OpenAxiom build to make sure -- Maxima works, though. I just updated my local copy of ECL CVS. That problem is indeed solved. Thanks! However, I cannot build OpenAxiom. The build fails during ECL'c C code generation for the lisp translation of src/interp/c-util.boot, in the function |expandableDefinition?|: ;;; Emitting code for |expandableDefinition?|. -1 is not of type FUNCTION. Available restarts: 1. (ABORT) ABORT Backtrace did not give me much to work on. to isolate the bug. I do not know how ECL got to '-1'. >> >> 1. The argument-type in the function proclamation is simple enough >> that ECL should not be confused. >> >> 2. ECL pretends that there are too few arguments for proclaimed >> BEGIN-DOLLAR-P. Yet, the function was proclaimed to be >> of arity 1, and there is exactly one argument supplied in the call. > > These two were caused by the error I just fixed. OK. >> >> What are the notes about propagating FUNCALL and C-INLINE about? > > The type propagator is complaining about forms for which there is no type > propagation code. I just disabled some of them, but seems I forgot FUNCALL. OK, thanks! -- Gaby -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] [PATCH,BUG] Some fixes for ECL & a bug
On Mon, Jul 12, 2010 at 5:09 PM, Juan Jose Garcia-Ripoll wrote: > On Mon, Jul 12, 2010 at 5:45 PM, Alexander Gavrilov > wrote: >> >> (defmethod foo ((bar t)) (declaim (optimize (speed 1 > > I did not change anything since yesterday and this works for me. > Maybe Alexander did not rebuild from a clean local build tree? -- Gaby -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] [PATCH,BUG] Some fixes for ECL & a bug
On Tue, Jul 13, 2010 at 4:20 PM, Juan Jose Garcia-Ripoll wrote: > On Tue, Jul 13, 2010 at 9:43 AM, Alexander Gavrilov > wrote: >> >> > On Mon, Jul 12, 2010 at 5:45 PM, Alexander Gavrilov >> > wrote: >> > >> > > (defmethod foo ((bar t)) (declaim (optimize (speed 1 >> > > >> > >> > I did not change anything since yesterday and this works for me. >> > >> >> This requires cmp.fas to be loaded. In my case it happens >> automatically because I load ASDF from .eclrc > > I verified the problem and found a quick solution for it -- apparently there > are some extensions to the bytecodes compiler that do not work so nicely as > expected, I just avoided their use. > > There are now two compiler problems left, the one reported by Pascal and > another one by Dan Corkill, as well as a pending fix for increased accuracy > in EXP. I hope that kind of closes the list of things to solve. well there is still the pending issue that ECL now leaves lots of tempory files ecl* or ECL* in the /tmp directory... -- Gaby -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] [PATCH,BUG] Some fixes for ECL & a bug
On Tue, Jul 13, 2010 at 5:12 PM, Juan Jose Garcia-Ripoll wrote: > On Wed, Jul 14, 2010 at 12:04 AM, Gabriel Dos Reis > wrote: >> >> well there is still the pending issue that ECL now leaves lots of tempory >> files ecl* or ECL* in the /tmp directory... > > I am not sure about this. I was reported a problem with mkstemp causing > conflicts because POSIX allows dots in the resulting names. That was fixed. > But when and how are these extra files being created? Was it in a previous > email? Yes, I reported that in a previous email. I do not know how they are created. But, I observed that every time I build a new ECL, I get a bunch of them in the /tmp directory. Here is a sample: dromion[17:17]% ls ecl* eclinit04Trez.ceclinitegxURz.ceclinitJOk7Zo.ceclinitRwL7De.c eclinit04Trez.oeclinitegxURz.oeclinitJOk7Zo.oeclinitRwL7De.o eclinit04Trez.tmp eclinitegxURz.tmp eclinitJOk7Zo.tmp eclinitRwL7De.tmp eclinit1aAaaI.ceclinitFJgzb1.ceclinitK1iIu4.ceclinitT0DSm4.c eclinit1aAaaI.oeclinitFJgzb1.oeclinitK1iIu4.oeclinitT0DSm4.o eclinit1aAaaI.tmp eclinitFJgzb1.tmp eclinitK1iIu4.tmp eclinitT0DSm4.tmp eclinit2uSySQ.ceclinitFnqOln.ceclinitkcRIsC.ceclinittbr2OF.c eclinit2uSySQ.oeclinitFnqOln.oeclinitkcRIsC.oeclinittbr2OF.o eclinit2uSySQ.tmp eclinitFnqOln.tmp eclinitkcRIsC.tmp eclinittbr2OF.tmp eclinit4UkB6o.ceclinitGjdnwb.ceclinitkO7RsU.ceclinitufRjhl.c eclinit4UkB6o.oeclinitGjdnwb.oeclinitkO7RsU.oeclinitufRjhl.o eclinit4UkB6o.tmp eclinitGjdnwb.tmp eclinitkO7RsU.tmp eclinitufRjhl.tmp eclinit7qsQKc.ceclinitGKcMbq.ceclinitM6wejY.ceclinituhxQcu.c eclinit7qsQKc.oeclinitGKcMbq.oeclinitM6wejY.oeclinituhxQcu.o eclinit7qsQKc.tmp eclinitGKcMbq.tmp eclinitM6wejY.tmp eclinituhxQcu.tmp eclinit7un2XA.ceclinitgukKgJ.ceclinitmVGcCR.ceclinitUNc9XO.c eclinit7un2XA.oeclinitgukKgJ.oeclinitmVGcCR.oeclinitUNc9XO.o eclinit7un2XA.tmp eclinitgukKgJ.tmp eclinitmVGcCR.tmp eclinitUNc9XO.tmp eclinit9sUxBL.ceclinitHLahgx.ceclinitNPU0xk.ceclinitvPG9PO.c eclinit9sUxBL.oeclinitHLahgx.oeclinitNPU0xk.oeclinitvPG9PO.o eclinit9sUxBL.tmp eclinitHLahgx.tmp eclinitNPU0xk.tmp eclinitvPG9PO.tmp eclinitA1jHQi.ceclinithzAuqO.ceclinitNvBuRv.ceclinitw4kWpI.c eclinitA1jHQi.oeclinithzAuqO.oeclinitNvBuRv.oeclinitw4kWpI.o eclinitA1jHQi.tmp eclinithzAuqO.tmp eclinitNvBuRv.tmp eclinitw4kWpI.tmp eclinitaMUNEN.ceclinitiD1OGz.ceclinitojOmOW.ceclinitWvXDDp.c eclinitaMUNEN.oeclinitiD1OGz.oeclinitojOmOW.oeclinitWvXDDp.o eclinitaMUNEN.tmp eclinitiD1OGz.tmp eclinitojOmOW.tmp eclinitWvXDDp.tmp eclinitaxaTeO.ceclinitIDPWbH.ceclinitOS7k1s.ceclinitXrSEJx.c eclinitaxaTeO.oeclinitIDPWbH.oeclinitOS7k1s.oeclinitXrSEJx.o eclinitaxaTeO.tmp eclinitIDPWbH.tmp eclinitOS7k1s.tmp eclinitXrSEJx.tmp eclinitbZkAMm.ceclinitjbHJBx.ceclinitp1X2Ab.ceclinitYspvKg.c eclinitbZkAMm.oeclinitjbHJBx.oeclinitp1X2Ab.oeclinitYspvKg.o eclinitbZkAMm.tmp eclinitjbHJBx.tmp eclinitp1X2Ab.tmp eclinitYspvKg.tmp eclinitCp4VHk.ceclinitJc5mYT.ceclinitpUWTSJ.ceclinitYyG7qz.c eclinitCp4VHk.oeclinitJc5mYT.oeclinitpUWTSJ.oeclinitYyG7qz.o eclinitCp4VHk.tmp eclinitJc5mYT.tmp eclinitpUWTSJ.tmp eclinitYyG7qz.tmp eclinitCtnzr1.ceclinitjckBEN.ceclinitqJmwUM.ceclinitz4Hjvr.c eclinitCtnzr1.oeclinitjckBEN.oeclinitqJmwUM.oeclinitz4Hjvr.o eclinitCtnzr1.tmp eclinitjckBEN.tmp eclinitqJmwUM.tmp eclinitz4Hjvr.tmp eclinitcYRYrE.ceclinitJLhHSS.ceclinitQNtkUN.ceclinitzgLGz4.c eclinitcYRYrE.oeclinitJLhHSS.oeclinitQNtkUN.oeclinitzgLGz4.o eclinitcYRYrE.tmp eclinitJLhHSS.tmp eclinitQNtkUN.tmp eclinitzgLGz4.tmp eclinitEdRSCS.ceclinitjMpsq5.ceclinitr5OFDw.ceclinitzh7A9m.c eclinitEdRSCS.oeclinitjMpsq5.oeclinitr5OFDw.oeclinitzh7A9m.o eclinitEdRSCS.tmp eclinitjMpsq5.tmp eclinitr5OFDw.tmp eclinitzh7A9m.tmp -- Gaby -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] ECL fasl format
Hi Juanjo, Do you have a documentation for ECL's FASL format (and data structures)? -- Gaby -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] A bug was found in the compiler
On Thu, May 20, 2010 at 1:11 AM, Gabriel Dos Reis wrote: > On Fri, May 14, 2010 at 5:44 PM, Gabriel Dos Reis wrote: >> Hi Juanjo, >> >> As I cannot build OpenAxiom with ECL HEAD, despite commits from today, >> I tried to see the effect of the improvement on building SBCL with ECL. >> I was almost pleasantly surprised: the build went much further than it >> used to; but it still fails: >> >> ;;; Note: >> ;;; in file late-type.lisp, position 21076 >> ;;; at (DEFUN VALUES-TYPE-OUT ...) >> ;;; Replacing variable TYPE by its value >> ;;; Emitting code for PROCESS-TYPES. >> ;;; Emitting code for VALUES-TYPE-IN. >> >> Internal error: >> in file late-type.lisp, position 21832 >> at (DEFUN VALUES-TYPE-IN ...) >> ** A bug was found in the compiler >> Available restarts: >> >> 1. (ABORT) ABORT >> 2. (RESTART-TOPLEVEL) Go back to Top-Level REPL. >> >> >> Here is how you can reproduce the bug: >> >> (1) check out SBCL CVS HEAD >> (2) apply the patch below >> (3) issue ./make.sh ecl >> > > Hi Juanjo, > > Your recent commits (yesterday or today depending on where you are) > have made some improvements. The build no longer dies in the > compilation of VALUES-TYPE-IN. It goes further (yay!), and now I am > getting > > ;;; Loading > "/home/gdr/src/sbcl.cvs/obj/from-host/src/code/deftypes-for-target.fas" > > The function (SETF CLASSOID-CELL-PCL-CLASS) is undefined. > Available restarts: > > 1. (RESTART-TOPLEVEL) Go back to Top-Level REPL. > > I was hoping that the recent SETF expander fixes may also fix this; but not :-/ -- Gaby -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL fasl format
On Sat, Jul 17, 2010 at 4:41 PM, Juan Jose Garcia-Ripoll wrote: > On Thu, Jul 15, 2010 at 3:08 AM, Gabriel Dos Reis > wrote: >> >> Do you have a documentation for ECL's FASL format (and data structures)? > > Not really: read.d and more precisely read_VV document the process of > initializing a FASL file, while load.d shows how it is loaded. > > FASL files are just shared libraries. We do not use "formats" as such, but > just link together object files. > > Each object file contains a single initialization routine, which is just a C > function with the statements in the lisp file, compiled. > > This routine is called twice by read_VV. The first time it just returns a > structure (ecl_codeblock) with some fields filled in, such as the text > representation of all constants, the text representation of those constants > that are only used during initialization (and can be eliminated afterwards), > and some debug information. > > The second time, the init function executes the compiled statements I > mentioned before. Now all constants and packages have been set up and thus > the lisp code works just fine. Functions will be installed by the statements > that implement DEFUN, and macros, classes, and other things will be defined. > > But again, this is _how_ it works. There is no format as such. ECL just uses > whatever the operating system provides in terms of binary file formats, > system calls to load them, etc. Many thanks. -- Gaby -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] ECL on LLP64 machines
Hi Juanjo, By way of necessity I ended up with only a Windows 7 64-bit machine on travel. I managed to have mingw-w64 up and running flawlessly (so far.) I tried to compile ECL, but only to realize that it supports only ILP or LP data model. The windows box I am running is LLP-64. Was that restriction intended, or is it just an accident of how ECL's src/aclocal.m4 is currently written? Speaking of which, I was curious as to why ECL does not first try to probe for and and use predefined sized integer types from there, and only fall back to the current detection scheme only if those headers are unavailable? -- Gaby -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] refactor src/aclocal.m4
Hi Juanjo,
While I was looking at the configure issue of ECL on Windows 64-bit, I
noticed that the tests for sized integer types were
(1) duplicating what Autoconf already does for free (and more)
(2) copy-n-pasted duplicates
The patch below refactors the boilerplate into a single macro:
ECL_CHECK_SIZED_INTEGER_TYPE. And it reuses standard Autoconf tests.
A patch dealing with CL_FIXNUM_TYPE will follow later, after this one is
discussed/refined and integrated.
-- Gaby
Index: aclocal.m4
===
RCS file: /cvsroot/ecls/ecl/src/aclocal.m4,v
retrieving revision 1.118
diff -p -r1.118 aclocal.m4
*** aclocal.m4 4 Jul 2010 20:54:51 - 1.118
--- aclocal.m4 11 Aug 2010 07:36:33 -
*** int main() {
*** 445,450
--- 445,465
}]])],[ECL_FILE_CNT=3],[])
fi
])
+
+ dnl -
+ dnl Check availability of standard sized integer types of a given width.
+ dnl On success, define the global variables ECL_INTx_T and ECL_UNITx_T to
+ dnl hold the names of the corresponding standard C integer types.
+ AC_DEFUN(ECL_CHECK_SIZED_INTEGER_TYPE,[
+ AC_TYPE_INT$1_T
+ AC_TYPE_UINT$1_T
+ if test "x$ac_cv_c_int$1_t" = xyes; then
+ eval ECL_INT$1_T="int$1_t"
+ eval ECL_UINT$1_T="uint$1_t"
+ AC_DEFINE_UNQUOTED([ecl_int$1_t],[int$1_t])
+ AC_DEFINE_UNQUOTED([ecl_uint$1_t],[uint$1_t])
+ fi])
+
dnl
dnl --
dnl Check the existence of different integer types and that they
*** if test -z "${ECL_STDINT_HEADER}"; then
*** 458,548
AC_CHECK_HEADER([inttypes.h],[AC_DEFINE(HAVE_INTTYPES_H)
ECL_STDINT_HEADER="#include "],[])
fi
! if test -n "${ECL_STDINT_HEADER}" -a -z "${ECL_UINT8_T}"; then
! AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#ifdef HAVE_INTTYPES_H
! #include
! #else
! #ifdef HAVE_STDINT_H
! #include
! #endif
! #endif]], [[
! {
! uint8_t i = 0x80;
! if (i == 0)
! return 0;
! if ((i << 1))
! return 0;
! if ((i - 1) != 0x7F)
! return 0;
! return 1;
! }]])],[ECL_UINT8_T=uint8_t;ECL_INT8_T=int8_t],[])
! fi
! if test -z "${ECL_UINT8_T}"; then
! AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [[
! {
! unsigned char c = 0x80;
! if (i == 0)
! return 0;
! if ((i << 1))
! return 0;
! if ((i - 1) != 0x7F)
! return 0;
! return 1;
! }]])],[ECL_UINT8_T="unsigned char";ECL_INT8_T="signed char"],[])
! fi
! if test -n "${ECL_STDINT_HEADER}" -a -z "${ECL_UINT16_T}"; then
! AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#ifdef HAVE_INTTYPES_H
! #include
! #else
! #ifdef HAVE_STDINT_H
! #include
! #endif
! #endif]], [[
! {
! uint16_t i = 0x8000UL;
! if (i == 0)
! return 0;
! if ((i << 1))
! return 0;
! if ((i - 1) != 0x7FFFUL)
! return 0;
! return 1;
! }]])],[ECL_UINT16_T=uint16_t;ECL_INT16_T=int16_t],[])
! fi
! if test -n "${ECL_STDINT_HEADER}" -a -z "${ECL_UINT32_T}"; then
! AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#ifdef HAVE_INTTYPES_H
! #include
! #else
! #ifdef HAVE_STDINT_H
! #include
! #endif
! #endif]], [[
! {
! uint32_t i = 0x8000UL;
! if (i == 0)
! return 0;
! if ((i << 1))
! return 0;
! if ((i - 1) != 0x7FFFUL)
! return 0;
! return 1;
! }]])],[ECL_UINT32_T=uint32_t;ECL_INT32_T=int32_t],[])
! fi
! if test -n "${ECL_STDINT_HEADER}" -a -z "${ECL_UINT64_T}"; then
! AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#ifdef HAVE_INTTYPES_H
! #include
! #else
! #ifdef HAVE_STDINT_H
! #include
! #endif
! #endif]], [[
! {
! uint64_t i = 1;
! i <<= 63; if (i == 0) return 0;
! i <<= 1; if (i) return 0;
! return 1;
! }]])],[ECL_UINT64_T=uint64_t;ECL_INT64_T=int64_t],[])
! fi
if test "${ECL_UINT16_T}${CL_FIXNUM_BITS}" = "16"; then
ECL_UINT16_T="cl_index"
ECL_INT16_T="cl_fixnum"
--- 473,484
AC_CHECK_HEADER([inttypes.h],[AC_DEFINE(HAVE_INTTYPES_H)
ECL_STDINT_HEADER="#include "],[])
fi
!
! ECL_CHECK_SIZED_INTEGER_TYPE(8)
! ECL_CHECK_SIZED_INTEGER_TYPE(16)
! ECL_CHECK_SIZED_INTEGER_TYPE(32)
! ECL_CHECK_SIZED_INTEGER_TYPE(64)
!
if test "${ECL_UINT16_T}${CL_FIXNUM_BITS}" = "16"; then
ECL_UINT16_T="cl_index"
ECL_INT16_T="cl_fixnum"
*** if test "${ECL_UINT64_T}${CL_FIXNUM_BITS
*** 555,592
ECL_UINT64_T="cl_index"
ECL_INT64_T="cl_fixnum"
fi
! AC_MSG_CHECKING(uint8_t type)
if test "x${ECL_UINT8_T}" = "x" -o "x${ECL_UINT8_T}" = xno; then
- AC_MSG_RESULT(none)
AC_MSG_ERROR(Can not build ECL without byte types)
- else
- AC_DEFINE_UNQUOTED([ecl_uint8_t],[$ECL_UINT8_T])
- AC_DEFINE_UNQUOTED([ecl_int8_t],[$ECL_INT8_T])
- AC_MSG_RESULT(${ECL_UINT8_T})
- fi
- AC_MSG_CHECKING(uint16_t type)
- if test "x${ECL_UINT16_T}" = "x" -o "x${ECL_UINT16_T}" = xno; then
- AC_MSG_RESULT(none)
- else
- AC_DEFINE_UNQUOTED([ecl_uint16_t],[$ECL_UINT16_T])
- AC_DEFINE_UNQUOTED([ecl_int16_t],[$ECL_INT16_T])
- AC_MSG_RESULT(${ECL_UINT16_T})
- fi
- AC_MSG_CHECKING(uint32_t type)
- if te
Re: [Ecls-list] refactor src/aclocal.m4
Juan Jose Garcia-Ripoll writes: | Hi Gabriel, | | thanks a lot for the refactoring. I wrote those tests at a time when I | was not sure that they existed and did the proper job. BTW, regarding | your previous question about stdint.h, some platforms define that | header but they do not provide any or all useful integer types. Thus | checking for its existence is not enough (old Solaris, for instance). yes, I remembered the solaris case. The standard Autoconf tests for the sized integer types do actually this: 1. they test for the existence of the headers. 2. next, they test that the typedefs are actually there. 3. If 2 fails, then they try to guess the types by running a program similar to yours, except that they avoid possible (mis)-optimization by compilers that assume that signed integer overflow is undefined-behaviour. I did not include the diff for 'configure' because I assumed that you would recreate it yourself. The other thing I was unsure about was whetehr you wanted to bump the required (developer) Autotools to version 2.62. -- Gaby -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL on LLP64 machines
On Wed, Aug 11, 2010 at 3:41 AM, Juan Jose Garcia-Ripoll wrote: > Hi Gabriel, > > ECL just needs an integer type that fits a pointer. That type is used > for defining cl_fixnum / cl_index, and in various places you will find > conversions to and from cl_object. In the LLP model, which I did not > know of until now (*), both "int" and "long" are 32-bit and pointers > are 64-bits, Yes. > which means they can not be used to implement cl_fixnum / > cl_integer. Thanks. I knew for cl_fixnum by going through src/aclocal.m4 and src/h/config.h.in, but I failed to notice that cl_integer has the same issue. Thanks! > If you find time, ECL's autoconf may be fixed to add that > additional type to the list of candidates for cl_fixnum / cl_integer. I did try last night to get ECL use intptr_t, when available, for cl_fixnum. That discovered some overflow arithmetics in the C code. I was too tired to investigate it. I'm on vacation with my family and I am supposed to be away from computing devices, so I will do that when everybody is sleeping. > > Juanjo > > (*) From a lot of code out there I gave for granted that "long" must > be long enough to fit a pointer, which is why ECL's autoconf just uses > "int" and "long" as candidates for cl_fixnum. This is probably a too > old assumption, but I fail to see the utility of the LLP model given > that :-/ I wondered the same. My speculative conclusion was that maybe that is needed for having LP32 binaries run on LLP64 without change. -- Gaby -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL on LLP64 machines
On Wed, Aug 11, 2010 at 5:16 PM, Juan Jose Garcia-Ripoll wrote: > On Wed, Aug 11, 2010 at 4:39 PM, Gabriel Dos Reis > wrote: >> >> I did try last night to get ECL use intptr_t, when available, for >> cl_fixnum. >> That discovered some overflow arithmetics in the C code. > > I attach a patch that uses "long long" when neither of "long" nor "int" fit. > Unfortunately I have no way to test it. > Juanjo Hi Juanjo, Thanks for the patch! The build failed earlier in the GC component: In file included from c:/Docume~1/gdr/Desktop/ecl.cvs/src/gc/include/private/gc_priv.h:68:0, from c:/Docume~1/gdr/Desktop/ecl.cvs/src/gc/allchblk.c:19: c:/Docume~1/gdr/Desktop/ecl.cvs/src/gc/include/private/gcconfig.h:997:7: error: #error This should be handled as X86_64 c:/Docume~1/gdr/Desktop/ecl.cvs/src/gc/include/private/gcconfig.h:1843:0: warning: "MACH_TYPE" redefined c:/Docume~1/gdr/Desktop/ecl.cvs/src/gc/include/private/gcconfig.h:995:0: note: this is the location of the previous definition c:/Docume~1/gdr/Desktop/ecl.cvs/src/gc/allchblk.c:21:9: warning: 'GC_use_entire_heap' redeclared without dllimport attribute: previous dllimport ignored Is the GC library known to work on Windows 64-bit? -- Gaby -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL on LLP64 machines
On Thu, Aug 12, 2010 at 12:35 PM, Juan Jose Garcia-Ripoll wrote: > For Mingw you should use a more recent (alpha) release of the garbage > collector, install it and then build ECL. Sorry for the inconvenience, but > the GC people do not yet dare to produce a stable release. > Juanjo That is what I figured out, but I got mired in other issues. Yes, the GC from CVS compiles and installs fine. And ECL's configure was able to pick it up. The only issue I had been distracted with is that, apparently, ECL's configure could not use the multi-threading library that comes with mingw-w64. I was trying to resolve that issue but unsuccessfully so far. -- Gaby -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Request to mailing list Ecls-list rejected
ecls-list-boun...@lists.sourceforge.net writes:
| "Gabriel, your message was too large for the mailing list, but it was
| automatically forwarded to me this morning. I will commut the changes
| to number.h and have a look at the rest. Thanks a lot for your help.
|
| Juanjo"
Hi Juanjo,
After having restructured src/c/load.d as I indicted in my earlier
message [1], I needed to apply the patch below (which fixes an obvious
thinko). Then I could successfully build ecl_min. However, it crashed
when used to bootstrap ECL. The codes that are guarded by
ECL_LONG_BITS < FIXNUM_BITS
do not seem to have been tested in recent years (for they do not compile).
The reason for that is simple: ECL seems to have been tested only on ILP
or LP platforms.
So, I am wondering why ECL is making that distinction? That is, why does
ECL need to distinguish 'long' from ECL_FIXNUM_TYPE? Should not
the distinction between GMP_LIMB_BITS vs. FIXNUM_BITS be sufficient?
[1] I introduced the following CPP macro
#if defined(__MINGW32__) || defined(__MINGW64__) || defined(_MSC_VER)
# define ECL_MS_WINDOWS_TARGET 1
#endif
in src/h/ecl.h. to abstract over the various targets that run native
windows.
For Windows 7 64-bit I recommend testing also for __MINGW64__. The
difference between __MINGW32__ and __MINGW64__ matters only for
selecting 32-bit v 64-bit specific code.
I'm not sending the patch against src/c/load.d yet since I did not
manage to resolve all issues.
-- Gaby
Index: big.d
===
RCS file: /cvsroot/ecls/ecl/src/c/big.d,v
retrieving revision 1.43
diff -p -r1.43 big.d
*** big.d 1 Feb 2010 13:55:16 - 1.43
--- big.d 13 Aug 2010 09:17:09 -
*** _ecl_fix_times_fix(cl_fixnum x, cl_fixnu
*** 160,166
ECL_WITH_TEMP_BIGNUM(w,4);
mpz_set_si(z->big.big_num, x);
mpz_set_si(w->big.big_num, y);
! mpz_mu(z->big.big_num, z->big.big_num, w->big.big_num);
#endif
{
cl_object y = big_normalize(z);
--- 160,166
ECL_WITH_TEMP_BIGNUM(w,4);
mpz_set_si(z->big.big_num, x);
mpz_set_si(w->big.big_num, y);
! mpz_mul(z->big.big_num, z->big.big_num, w->big.big_num);
#endif
{
cl_object y = big_normalize(z);
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Request to mailing list Ecls-list rejected
Juan Jose Garcia-Ripoll writes: | On Fri, Aug 13, 2010 at 11:35 AM, Gabriel Dos Reis wrote: | | So, I am wondering why ECL is making that distinction? That is, why does | ECL need to distinguish 'long' from ECL_FIXNUM_TYPE? Should not | the distinction between GMP_LIMB_BITS vs. FIXNUM_BITS be sufficient? | | | Gabriel, I think you have found a major problem. GMP only exports routines to | convert from gmp to long and int, not to long long. Since I did not want to | tinker with GMP's internals, I almost never manipulated limbs myself. I have | not the faintest idea of what choices GMP takes when facing an LLP platform. I | believe the Sage group switched from GMP to MPIR for this precise reason, but | it also poses a significant problem for ECL because we will have to have a look | at the cl_fixnum -> gmp conversions scattered throughout the code, which | currently rely on GMP's mpz_set_si function and this is taking LONG not LONG | LONG!!! Aha! Thanks for the explanation. I would not think that it would be good for ECL to swicth from GMP to MPIR (not that I think bad of MPIR, but only because GMP remains quite popular on almost all platforms and is still actively maintained.) As for the conversion problem. 1. GMP does use 'long long' for mp_limb_t where it is available. So, ECL could check at configure time whether ECL_FIXNUM_TYPE matches mp_limb_t in size. 2. GMP offers low-level mpn_xxx functions that could be used to initialize mpz objects from fixnum values. That would avoid the unstructured code you are alluding to. Is that something you would contemplate? -- Gaby -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Request to mailing list Ecls-list rejected
Gabriel Dos Reis writes:
[...]
| Index: big.d
| ===
| RCS file: /cvsroot/ecls/ecl/src/c/big.d,v
| retrieving revision 1.43
| diff -p -r1.43 big.d
| *** big.d 1 Feb 2010 13:55:16 - 1.43
| --- big.d 13 Aug 2010 09:17:09 -
| *** _ecl_fix_times_fix(cl_fixnum x, cl_fixnu
| *** 160,166
| ECL_WITH_TEMP_BIGNUM(w,4);
| mpz_set_si(z->big.big_num, x);
| mpz_set_si(w->big.big_num, y);
| ! mpz_mu(z->big.big_num, z->big.big_num, w->big.big_num);
| #endif
| {
| cl_object y = big_normalize(z);
| --- 160,166
| ECL_WITH_TEMP_BIGNUM(w,4);
| mpz_set_si(z->big.big_num, x);
| mpz_set_si(w->big.big_num, y);
| ! mpz_mul(z->big.big_num, z->big.big_num, w->big.big_num);
| #endif
| {
| cl_object y = big_normalize(z);
Hi Juanjo,
I believe the above patch did not make it to the official CVS trunk.
[and this leaves me convinced that ECL_LONG_BITS should go :-)]
-- Gaby
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] ECL on Windows 32-bit with msys/mingw
hi,
Has anybody been successful building ECL from CVS trunk on Windows
32-bit using msys/mingw? For me it fails with:
In file included from
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/
unistd.h:13,
from c:/Docume~1/gdr/Desktop/ecl.cvs/src/c/file.d:29:
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/process.h:95: error:
expected identifier or '(' before '{' token
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/process.h:95: error:
expected identifier or '(' before 'void'
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/process.h:100: error:
conflicting types for 'GC_beginthreadex'
c:/Docume~1/gdr/Desktop/ecl.cvs/build/ecl/gc/gc.h:1049: note: previous
declaration of 'GC_beginthreadex' was here
I started the week with an abundance of patience and hope for ECL on
Windows boxes, but it seems to be drying up very quickly.
-- Gaby
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL on Windows 32-bit with msys/mingw
Juan Jose Garcia-Ripoll writes: [...] | I started the week with an abundance of patience and hope for ECL on | Windows boxes, but it seems to be drying up very quickly. | | | Some ideas | | - the windows 32 bit port worked. if something broke in the mean time and | nobody reported it can be easily fixed | - mingw is a PITA and a patience drainer. just guessing what to do to have 64 | bits is a waste of time. Looking into MinGW system file process.h, the error looks very puzzling. For it is only declaring _beginthread. All this sounds like a catch-22 macro game between ECL, MinGW, and the garbage collector. [...] | - no difficulty is insurmountable except death. but time can run out :-) -- Gaby -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL on Windows 32-bit with msys/mingw
Juan Jose Garcia-Ripoll writes:
| On Wed, Aug 18, 2010 at 5:03 PM, Gabriel Dos Reis wrote:
|
| Has anybody been successful building ECL from CVS trunk on Windows
| 32-bit using msys/mingw? For me it fails with:
|
| In file included from
| c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/
| unistd.h:13,
| from c:/Docume~1/gdr/Desktop/ecl.cvs/src/c/file.d:29:
| c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/process.h:95:
| error: expected identifier or '(' before '{' token
| c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/process.h:95:
| error: expected identifier or '(' before 'void'
| c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/process.h:100:
| error: conflicting types for 'GC_beginthreadex'
|
|
| I just got the same error because ECL was unable to find version 7.2a4 of the
| garbage collector, which I had installed somewhere else. Ensure that the right
| library is used by passing --enable-boehm=system This will make ECL complain
| when it cannot find the library you downloaded and installed yourself.
Indeed, that gets me past that error. I'm now getting
libeclmin.a(ffi.o): In function `si_make_dynamic_callback':
c:/Docume~1/gdr/Desktop/ecl.cvs/src/c/ffi.d:976: undefined reference to
`ffi_pre
p_closure'
libeclmin.a(ffi.o): In function `si_call_cfun':
c:/Docume~1/gdr/Desktop/ecl.cvs/src/c/ffi.d:925: undefined reference to
`ffi_call'
libeclmin.a(ffi.o):tmp.c:(.rdata+0x320): undefined reference to `ffi_type_sint8'
libeclmin.a(ffi.o):tmp.c:(.rdata+0x324): undefined reference to `ffi_type_uint8'
libeclmin.a(ffi.o):tmp.c:(.rdata+0x328): undefined reference to `ffi_type_sint8'
libeclmin.a(ffi.o):tmp.c:(.rdata+0x32c): undefined reference to `ffi_type_uint8'
libeclmin.a(ffi.o):tmp.c:(.rdata+0x330): undefined reference to
`ffi_type_sint16
[...]
My configure command line was:
$ ./configure --enable-threads --prefix="C:/msys/1.0/local/ecl"
--with-gmp-prefix="C:/msys/1.0/local" --enable-boehm=system
-- Gaby
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Ecls-list Digest, Vol 52, Issue 7
"aeri...@xs4all.nl" writes:
| Hi,
|
|
| Date: Wed, 18 Aug 2010 10:03:44 -0500
| From: Gabriel Dos Reis
| Subject: [Ecls-list] ECL on Windows 32-bit with msys/mingw
| To: ecls-l...@lists.sf.net
| Message-ID: <87eidwarov@gauss.cs.tamu.edu>
| Content-Type: text/plain; charset=us-ascii
|
| Has anybody been successful building ECL from CVS trunk on Windows 32-bit
| using msys/mingw?
|
|
| Do you have a specific need for CVS trunk? I've recently compiled 10.4.1 on
| 32-bit Windows.
Yes, I'm planning some changes to ECL to compile on Window 64-bit, and I
am desperately trying to get a reference base line before I make further
"damages".
| For me it fails with:
|
| In file included from
| c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/
| unistd.h:13,
| from c:/Docume~1/gdr/Desktop/ecl.cvs/src/c/file.d:29:
| c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/process.h:95:
| error: expected identifier or '(' before '{' token
| c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/process.h:95:
| error: expected identifier or '(' before 'void'
| c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/process.h:100:
| error: conflicting types for 'GC_beginthreadex'
| c:/Docume~1/gdr/Desktop/ecl.cvs/build/ecl/gc/gc.h:1049: note: previous
| declaration of 'GC_beginthreadex' was here
|
|
| I'm writing this on a phone so excuse the vague description, but I think I
| fixed this by replacing the Boehm GC source tree that comes with ECL with an
| updated one.
|
| I recall Juanjo mentioning this in one of the ECL changelogs.
I think ECL CVS trunk still uses an older version of the collector.
It appears that Juanjo and I can work around that specific problem by
using a more recent GC (e.g. from CVS trunk.)
However, I am still seeing other link failures from ffi.d.
-- Gaby
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL on Windows 32-bit with msys/mingw
Juan Jose Garcia-Ripoll writes: | On Wed, Aug 18, 2010 at 11:15 PM, Juan Jose Garcia-Ripoll < | juanjose.garciarip...@googlemail.com> wrote: | | On Wed, Aug 18, 2010 at 6:37 PM, Gabriel Dos Reis wrote: | | libeclmin.a(ffi.o): In function `si_make_dynamic_callback': | c:/Docume~1/gdr/Desktop/ecl.cvs/src/c/ffi.d:976: undefined reference to | `ffi_prep_closure' | | libeclmin.a(ffi.o): In function `si_call_cfun': | c:/Docume~1/gdr/Desktop/ecl.cvs/src/c/ffi.d:925: undefined reference to | `ffi_call' | | | This code should not be compiled and I can guarantee I do not see this in | my copy of mingw. Is there a library called libffi in your system, or did | ECL detect it at configuration time? It should appear in the log or by a | definition HAVE_LIBFFI in ecl/config.h If so you could you try using | --without-dffi | | | I have seen this precise error when building with a recent version of cygwin | (see http://ecls.sourceforge.net/logs/cygwin32) which comes with a -lffi | library. ECL detects it and tries to use it, but it fails because it seems it | is not the actual libffi or it has some other API. I just wonder why you saw | the same error in pure Mingw (while I don't http://ecls.sourceforge.net/logs/ | mingw32) Hi Juanjo, Indeed there is a libffi.a installed with my copy of MinGW. It comes with the precompiled GNU's Java front-end gcj (which uses it). If I understand correctly, there might be two libffi floating around: one that ECL wants, and one that comes with GNU Compiler suite. Yet, they may not be the same. In that case, I think it ought to be the case that ECL has a definite idea about which libffi it wants and test for it at configuration time. Until your message, I was completely puzzled by these link failures. Indeed, configuring with --without-dffi, the build is OK. What is the relation between --enable-shared and --with-dffi? -- Gaby -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL on Windows 32-bit with msys/mingw
Juan Jose Garcia-Ripoll writes: [...] | --with-dffi is only useful when combined with --enable-shared, because the | later allows finding out shared libraries, loading them and retrieving pointers | to their C functions, which DFFI may then use as described before. | | --with-dffi is only needed when you want to do FFI operations from the command | line or interpreted code. OK, thanks! | As for the coexistence of both libraries, my feeling is that libffi is a very | quickly evolving library. Now, I only have libffi as shipped with Debian and | with OS X and they more or less look the same, and indeed ECL builds just fine | in both platforms with --with-dffi enabled. Cygwin and mingw may be either | shipping a much older or much newer version, or a version with some | functionality removed due to security reasons (arbitrary function calls? | callbacks?), I really can not tell. The ffi.h (located in GCC internal directories) with my copy of MinGW says version 2.1 in comment. I don't see any CPP macro version or something of the sort in the header file, so it would be more involved to prevent this kind of puzzling link failure. It sucks to have a library without a mean to report version. -- Gaby -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL on Windows 32-bit with msys/mingw
Juan Jose Garcia-Ripoll writes: | BTW, I just finished configuring the Windows64 virtual image and right now all | tests are run through it: | http://ecls.sourceforge.net/logs.html Great! | However, I still have not managed installing mingw64, nor setting up the MSVC | port to use LLP. I will try to free up time this afternoon to polish my patch and send it for discussion. Many thanks, -- Gaby -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL on Windows 32-bit with msys/mingw
In fact I have a question I should ask now. I am introducing a CPP macro, say ECL_MS_WINDOWS_HOST, that tells where ECL is being built as a native Windows program (this includes using MS compiler, GNU MinGW/MSYS or mingw-w64, but excludes Cygwin). This is easily done by configure. And all is well. However for a build with MS compiler, the macro needs to be defined somewhere since configure is not used there. Where is the right place to put that CPP macro definition? -- Gaby -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] features.h is harmful
Hi Juanjo, The new header file src/c/features.h appears to break builds on Linux. Indeed, on many linux distributions there already exists a header file named feature.h. In the ECL case, it looks like is picking the new (ECL) file as opposed of the (linux) system supplied header. This is on openSUSE-11.2. The exact error is: In file included from /usr/include/stdlib.h:25, from /home/gdr/src/ecl.cvs/src/c/dpp.c:71: /home/gdr/src/ecl.cvs/src/c/features.h:18: error: expected ‘)’ before ‘static’ In file included from /home/gdr/src/ecl.cvs/src/c/dpp.c:71: /usr/include/stdlib.h:96: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__BEGIN_NAMESPACE_STD’ /usr/include/stdlib.h:140: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘extern’ /usr/include/stdlib.h:145: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘extern’ I would suggest to rename features.h as ecl-features.h. -- Gaby -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] features.h is harmful
Juan Jose Garcia-Ripoll writes: | On Sat, Aug 21, 2010 at 10:02 PM, Gabriel Dos Reis wrote: | | The new header file src/c/features.h appears to break builds on Linux. | Indeed, on many linux distributions there already exists a header file | named feature.h. In the ECL case, it looks like is picking | the new (ECL) file as opposed of the (linux) system supplied header. | | | Thanks for pointing out both the problem and the solution -- they were both | quite unexpected to me, since I develop on OS X and saw no problem building | ECL. Thanks for the quick fix, ECL is in Buildville again. -- Gaby -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] ecl_make_stream_from_fd
Hi Juanjo, I am looking at this snippet from ecl_make_stream_from_fd in src/c/file.d: #if defined(ECL_WSOCK) if (smm == smm_input_wsock || smm == smm_output_wsock || smm == smm_io_wsock) fp = (FILE*)fd; else fp = fdopen(fd, mode); #else fp = fdopen(fd, mode); #endif the parameter `fd' is of type `int'. I cannot see how the cast to `FILE*' can possibly yield a valid pointer value on a 64-bit architecture. -- Gaby -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] Compiling ECL under Wine
Hi Juanjo, Yesterday, I tried to cross build a native Windows ECL compiler but it looks as if the current configure/build infrastructure puts far more burdens than it ought to be -- and this goes back to some discussions we had last month. More on that later. I then decided to use Wine to compile ECL. I needed to apply the patchlet attached to this email. The first hunk is needed because even though a true windows system won't mind that the '.exe' is left out ecl_min is invoked, the build environment still cares. The second hunk is needed for a similar reason. Although NTFS is case-insensitive and case-preserving, the build filesystem may still care. The build did not complete because of some issues related to how wine maps drives to actual build pathnames, but my suspicion is that it is close. -- Gaby Index: src/Makefile.in === RCS file: /cvsroot/ecls/ecl/src/Makefile.in,v retrieving revision 1.104 diff -p -r1.104 Makefile.in *** src/Makefile.in 4 Jul 2010 20:55:04 - 1.104 --- src/Makefile.in 12 Sep 2010 11:45:19 - *** bin/ecl$(EXE): ecl_min$(EXE) compile.lsp *** 72,78 if [ -f CROSS-COMPILER ]; then \ ./CROSS-COMPILER compile; \ else \ ! ECLDIR=`pwd`/ ./ecl_min compile; \ fi ecl_min$(EXE): $(LIBRARIES) .gdbinit @libpre...@eclmin.@LIBEXT@ --- 72,78 if [ -f CROSS-COMPILER ]; then \ ./CROSS-COMPILER compile; \ else \ ! ECLDIR=`pwd`/ ./ecl_min$(EXE) compile; \ fi ecl_min$(EXE): $(LIBRARIES) .gdbinit @libpre...@eclmin.@LIBEXT@ Index: src/c/time.d === RCS file: /cvsroot/ecls/ecl/src/c/time.d,v retrieving revision 1.44 diff -p -r1.44 time.d *** src/c/time.d 22 Aug 2010 21:03:27 - 1.44 --- src/c/time.d 12 Sep 2010 11:45:20 - *** *** 34,40 #include #if defined(ECL_MS_WINDOWS_HOST) # include ! # include #endif #if !defined(HAVE_GETTIMEOFDAY) && !defined(HAVE_GETRUSAGE) && !defined(ECL_MS_WINDOWS_HOST) --- 34,40 #include #if defined(ECL_MS_WINDOWS_HOST) # include ! # include #endif #if !defined(HAVE_GETTIMEOFDAY) && !defined(HAVE_GETRUSAGE) && !defined(ECL_MS_WINDOWS_HOST) -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] problems in src/c/dpp.c - too many & too few arguments.
On Thu, Sep 16, 2010 at 5:30 AM, Dr. David Kirkby wrote: > I thought I'd reported this before, but can't see to find the email. So I'll > have another go. > > When I'm building ecl-10.2.1 as part of Sage I get too warning messages from > gcc. I fear nothing can be done about ECL-10.2.1. It has already been released into the wilderness long ago. Try newer version, e.g. from CVS. -- Gaby -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ecl is linking unnecessarily to libintl.so (at least on OpenSolaris)
On Sat, Sep 18, 2010 at 3:51 PM, Dr. David Kirkby wrote: > I'm sure you wont consider this a high priority, but ECL appears to be linking > unnecessarily to libintl.so at least on OpenSolaris. > > An intersting blog post here > > http://blogs.sun.com/rie/entry/tt_dependencies_tt_define_what > > shows how to find out any unused libraries. The current version of ECL in Sage > has 3 such unneeded libraries, but the latest git version has only one. > > See > > http://trac.sagemath.org/sage_trac/ticket/9943 I have always empirically found that use of sockets on *Solaris needed that library to be linked in. Are you claiming that changed in recent version of OpenSolaris? Which version? -- Gaby -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ecl is linking unnecessarily to libintl.so (at least on OpenSolaris)
On Mon, Sep 20, 2010 at 1:27 AM, Daniel Herring wrote: > On Sun, 19 Sep 2010, Juan Jose Garcia-Ripoll wrote: > If the test passes without -lintl, then that library is not used. If it > only passes with -lintl, then you don't care what OS you're on until > somebody else finds a case where this breaks things. In this specific case, which concrete test will cut it? -- Gaby -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] minor fixes for cross compilation
On Wed, Sep 22, 2010 at 4:27 PM, Anton Vodonosov wrote: > 2.a) Add CL_INT_BITS and CL_LONG_BITS declaration (similar to CL_FIXNUM_BITS) > 2.b) The declaration ECL_LONG_LONG_BITS=no geneted by default doesn't work > (the > relevant build error log is attached). Probably it was meant to have _T > instead of _BITS > (by analogy with other settings in this section). I defined both > ECL_LONG_LONG_T and > ECL_LONG_LONG_BITS (my environment has the long long type, therefore I > specified concrete values here). > 2.c) It looks like the default declarations for ECL_INT16_T, ECL_INT32_T must > use int16_1, int32_t, but not uint16_t, uint32_t. when we are cross-compiling ECL, most of this information is available in most cases in the target standard C headers. ECL should not require manual supply of those quantities. I understand that not all platforms have them, but they are the minority and ECL should not optimize for them and it is only for them that ECL should require manual edition. The cross compile process will be smoother. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] libdir: *nix vs. Windows
On Thu, Sep 30, 2010 at 11:03 AM, Samium Gromoff <_deepf...@feelingofgreen.ru> wrote: > On Thu, 30 Sep 2010 19:08:48 +0400, Samium Gromoff > <_deepf...@feelingofgreen.ru> wrote: >> However, @libdir@ is @prefix@/lib, which somehow works on Linux, and >> breaks on MinGW. > > Ok, so "*mingw" have INSTALL_TARGET=flatinstall, which mashes bindir, > libdir, includedir and ecldir together into $(prefix), > /but this fact only surfaces during installation/! > > Which obviously breaks for code built with default *dir's. > > The preconditions for flatinstallation are set into motion within > aclocal.m4. Now, there is no way to enforce the above equality > constraint between these variables in aclocal.m4, and so /it seems/ we > should enforce it somewhere down below the substitution chain, upon > detection of the impending flatinstall... Or compute the right value of libdir (called ecl_libdir?) at configuration time, so that everybody sees the same value. -- Gaby -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Help needed: autoconf with spaces in names
On Sun, Oct 3, 2010 at 3:16 PM, Juan Jose Garcia-Ripoll wrote: > It seems that "configure" does not work when one of the directories contains > a space in the name. Is this a known limitation? > Juanjo Hmm, I don't understand what you mean... But, I usually invoke the configure script with a relative path to avoid troubles. By the way, ECL's configure would refuse to configure outside the source directory, so it was already "not working" :-) -- Gaby -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] RANLIB, AR, build paths when cross-compiling
Hi Juanjo,
Attached is a patch I had needed (and that has been sitting on my hard-drive
for a while now.) It addresses some pesky issues related to
cross-compiling ECL.
1. ECL hard-codes the name of the program `ranlib'. That should not be.
Rather, like the compiler,the name should be detected at
configuration time. The patch adds a special variable *RANLIB* for
just that. Note that the detection at configuration time is
important because during cross compilation, the name of the program
may be prefixed by the host triplet, e.g. i686-pc-mingw32-ranlib.
This is what the Autoconf AC_PROG_RANLIB macro is for.
2. Similarly, ECL hard-codes the name of the `ar' program. That is no good.
The patch introduces a special variable *AR* for that purpose.
`ar' is looked for at configuration time as a tool, hence AC_CHECK_TOOL.
3. Build path.
When ECL generates C codes, it uses SI::COERCE-TO-FILENAME to
construct an absolute path to the variously generated external files.
That function generates host native paths. That is OK for a native
build. But, it is not OK for a cross build. For example, if you are
using Wine on Unix/Linux to cross compile ECL and use the default
drive mapping, the build system's filesystem / is mapped to the Z:/
drive; so, you will get absolute paths starting with Z:, that is no
good for tools working on the build system. Rather, ECL needs to
generate paths that are grok-able by the build system and its tool.
The proposed patch introduces BRIEF-NAMESTRING which is
ENOUGH-NAMESTRING around SI::COERCE-TO-FILENAME to get rid of the
thr drive letter where unnecessary.
There are other issues related to cross-compiling ECL, but they are
orthogonal to this.
-- Gaby
Index: src/configure.in
===
RCS file: /cvsroot/ecls/ecl/src/configure.in,v
retrieving revision 1.241
diff -p -r1.241 configure.in
*** src/configure.in 3 Oct 2010 20:35:02 - 1.241
--- src/configure.in 4 Oct 2010 19:19:07 -
*** AC_PROG_RANLIB# sets variable RA
*** 321,326
--- 321,328
AC_PROG_INSTALL # sets variables INSTALL, INSTALL_DATA, INSTALL_PROGRAM
AC_PROG_LN_S # sets variable LN_S
AC_PROG_MAKE_SET # set $(MAKE) if needed
+ AC_PROG_RANLIB# set variable RANLIB
+ AC_CHECK_TOOL([AR],[ar]) # set variable AR to appropriate `ar' program
dnl ---
dnl Checks which do not come with autoconf (must be after AC_PROG_CC)
Index: src/cmp/cmpdefs.lsp
===
RCS file: /cvsroot/ecls/ecl/src/cmp/cmpdefs.lsp,v
retrieving revision 1.97
diff -p -r1.97 cmpdefs.lsp
*** src/cmp/cmpdefs.lsp 3 Jun 2010 18:42:47 - 1.97
--- src/cmp/cmpdefs.lsp 4 Oct 2010 19:19:07 -
*** coprocessor).")
*** 29,34
--- 29,40
(defvar *ld* "@ECL_CC@"
"This variable controls the linker which is used by ECL.")
+ (defvar *ranlib* "@RANLIB@"
+ "Name of the `ranlib' program on the hosting platform.")
+
+ (defvar *ar* "@AR@"
+ "Name of the `AR' program on the hosting platform.")
+
(defvar *cc-flags* "@CPPFLAGS@ @CFLAGS@ @ECL_CFLAGS@")
(defvar *cc-optimize* #-msvc "-O2"
Index: src/cmp/cmpmain.lsp
===
RCS file: /cvsroot/ecls/ecl/src/cmp/cmpmain.lsp,v
retrieving revision 1.186
diff -p -r1.186 cmpmain.lsp
*** src/cmp/cmpmain.lsp 23 Jul 2010 22:01:09 - 1.186
--- src/cmp/cmpmain.lsp 4 Oct 2010 19:19:07 -
*** the environment variable TMPDIR to a dif
*** 123,129
(format nil
*ld-format*
*ld*
! (si::coerce-to-filename o-pathname)
(fix-for-mingw (ecl-library-directory))
options
*ld-rpath*
--- 123,129
(format nil
*ld-format*
*ld*
! (brief-namestring o-pathname)
(fix-for-mingw (ecl-library-directory))
options
*ld-rpath*
*** the environment variable TMPDIR to a dif
*** 154,160
(format nil
*ld-format*
*ld*
! (si::coerce-to-filename o-pathname)
(fix-for-mingw (ecl-library-directory))
options
*ld-rpath*
--- 154,160
(format nil
*ld-format*
*ld*
! (brief-namestring o-pathname)
(fix-for-mingw (ecl-library-directory))
options
*ld-rpath*
*** the environment variable TMPDIR to a dif
*** 168,175
(let ((lib-file (compile-file-pathname o-pathname :type :lib)))
(safe-system
(format nil
! "gcc -shared -o ~S -L~S ~{~S ~} ~...@[~s~]~{ '~A'~} ~...@?"
! (si::coerce-to-filename o-pathname)
(fix-for-mingw (ecl-library-directory))
options
*ld-rpath*
--- 168,176
(let ((lib-file (compile-file-pathname o-pathname :type :lib)))
(safe-system
(forma
[Ecls-list] Typo in src/Makefile.in breaks installation
Juanjo,
this patchlet fixes a typo in src/Makefile.in that breaks "make install".
-- Gaby
Index: src/configure.in
===
RCS file: /cvsroot/ecls/ecl/src/configure.in,v
retrieving revision 1.241
diff -p -r1.241 configure.in
*** src/configure.in 3 Oct 2010 20:35:02 - 1.241
--- src/configure.in 4 Oct 2010 19:19:07 -
*** AC_PROG_RANLIB# sets variable RA
*** 321,326
--- 321,328
AC_PROG_INSTALL # sets variables INSTALL, INSTALL_DATA, INSTALL_PROGRAM
AC_PROG_LN_S # sets variable LN_S
AC_PROG_MAKE_SET # set $(MAKE) if needed
+ AC_PROG_RANLIB# set variable RANLIB
+ AC_CHECK_TOOL([AR],[ar]) # set variable AR to appropriate `ar' program
dnl ---
dnl Checks which do not come with autoconf (must be after AC_PROG_CC)
Index: src/cmp/cmpdefs.lsp
===
RCS file: /cvsroot/ecls/ecl/src/cmp/cmpdefs.lsp,v
retrieving revision 1.97
diff -p -r1.97 cmpdefs.lsp
*** src/cmp/cmpdefs.lsp 3 Jun 2010 18:42:47 - 1.97
--- src/cmp/cmpdefs.lsp 4 Oct 2010 19:19:07 -
*** coprocessor).")
*** 29,34
--- 29,40
(defvar *ld* "@ECL_CC@"
"This variable controls the linker which is used by ECL.")
+ (defvar *ranlib* "@RANLIB@"
+ "Name of the `ranlib' program on the hosting platform.")
+
+ (defvar *ar* "@AR@"
+ "Name of the `AR' program on the hosting platform.")
+
(defvar *cc-flags* "@CPPFLAGS@ @CFLAGS@ @ECL_CFLAGS@")
(defvar *cc-optimize* #-msvc "-O2"
Index: src/cmp/cmpmain.lsp
===
RCS file: /cvsroot/ecls/ecl/src/cmp/cmpmain.lsp,v
retrieving revision 1.186
diff -p -r1.186 cmpmain.lsp
*** src/cmp/cmpmain.lsp 23 Jul 2010 22:01:09 - 1.186
--- src/cmp/cmpmain.lsp 4 Oct 2010 19:19:07 -
*** the environment variable TMPDIR to a dif
*** 123,129
(format nil
*ld-format*
*ld*
! (si::coerce-to-filename o-pathname)
(fix-for-mingw (ecl-library-directory))
options
*ld-rpath*
--- 123,129
(format nil
*ld-format*
*ld*
! (brief-namestring o-pathname)
(fix-for-mingw (ecl-library-directory))
options
*ld-rpath*
*** the environment variable TMPDIR to a dif
*** 154,160
(format nil
*ld-format*
*ld*
! (si::coerce-to-filename o-pathname)
(fix-for-mingw (ecl-library-directory))
options
*ld-rpath*
--- 154,160
(format nil
*ld-format*
*ld*
! (brief-namestring o-pathname)
(fix-for-mingw (ecl-library-directory))
options
*ld-rpath*
*** the environment variable TMPDIR to a dif
*** 168,175
(let ((lib-file (compile-file-pathname o-pathname :type :lib)))
(safe-system
(format nil
! "gcc -shared -o ~S -L~S ~{~S ~} ~...@[~s~]~{ '~A'~} ~...@?"
! (si::coerce-to-filename o-pathname)
(fix-for-mingw (ecl-library-directory))
options
*ld-rpath*
--- 168,176
(let ((lib-file (compile-file-pathname o-pathname :type :lib)))
(safe-system
(format nil
! "~S -shared -o ~S -L~S ~{~S ~} ~...@[~s~]~{ '~A'~} ~...@?"
! *cc*
! (brief-namestring o-pathname)
(fix-for-mingw (ecl-library-directory))
options
*ld-rpath*
*** the environment variable TMPDIR to a dif
*** 198,204
(format nil
*ld-format*
*ld*
! (si::coerce-to-filename o-pathname)
(fix-for-mingw (ecl-library-directory))
options
*ld-rpath*
--- 199,205
(format nil
*ld-format*
*ld*
! (brief-namestring o-pathname)
(fix-for-mingw (ecl-library-directory))
options
*ld-rpath*
*** the environment variable TMPDIR to a dif
*** 212,218
(safe-system
(format nil
"gcc -shared -o ~S -Wl,--export-all-symbols -L~S ~{~S ~} ~...@[~s~]~{ '~A'~} ~A"
! (si::coerce-to-filename o-pathname)
(fix-for-mingw (ecl-library-directory))
options
*ld-rpath*
--- 213,219
(safe-system
(format nil
"gcc -shared -o ~S -Wl,--export-all-symbols -L~S ~{~S ~} ~...@[~s~]~{ '~A'~} ~A"
! (brief-namestring o-pathname)
(fix-for-mingw (ecl-library-directory))
options
*ld-rpath*
*** or a loadable module."
*** 326,338
"Given a file name, return the compiler command line argument to link this file in."
(case kind
((:object :c)
! (si::coerce-to-filename pathname))
((:fasl :fas)
nil)
((:static-library :lib)
! (si::coerce-to-filename pathname))
((:shared-library :dll)
! (si::coerce-to-filename pathname))
((:program)
nil)
(otherwise
--- 327,339
Re: [Ecls-list] Typo in src/Makefile.in breaks installation
Gabriel Dos Reis writes: | Juanjo, | | this patchlet fixes a typo in src/Makefile.in that breaks "make install". Wrong patch :-( Here is the right patch. -- Gaby Index: src/Makefile.in === RCS file: /cvsroot/ecls/ecl/src/Makefile.in,v retrieving revision 1.107 diff -p -r1.107 Makefile.in *** src/Makefile.in 3 Oct 2010 21:37:14 - 1.107 --- src/Makefile.in 4 Oct 2010 21:25:20 - *** install: *** 172,178 $(LN_S) @SONAME3@ @SONAME@ ) \ fi $(INSTALL_PROGRAM) c/dpp$(EXE) $(DESTDIR)$(ecldir) ! $(INSTALL_PROGRAM) c/ecl_min(EXE) $(DESTDIR)$(ecldir) for i in `cat modules`; do \ case $$i in \ *.fas) $(INSTALL_PROGRAM) $$i $(DESTDIR)$(ecldir);; \ --- 172,178 $(LN_S) @SONAME3@ @SONAME@ ) \ fi $(INSTALL_PROGRAM) c/dpp$(EXE) $(DESTDIR)$(ecldir) ! $(INSTALL_PROGRAM) ecl_min$(EXE) $(DESTDIR)$(ecldir) for i in `cat modules`; do \ case $$i in \ *.fas) $(INSTALL_PROGRAM) $$i $(DESTDIR)$(ecldir);; \ -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] RANLIB, AR, build paths when cross-compiling
Juan Jose Garcia-Ripoll writes:
| On Mon, Oct 4, 2010 at 9:39 PM, Gabriel Dos Reis wrote:
|
| Attached is a patch I had needed (and that has been sitting on my
| hard-drive
| for a while now.) It addresses some pesky issues related to
| cross-compiling ECL.
|
|
| Hi Gabriel, thanks a lot for the patch. It looks good and I like the idea of
| "brief-namestring". Hopefully this will help making cross-compilation easier.
Hi Juanjo,
I figured the patch needed a tightening. The C compiler needs to be told
to consider the current directory as part of the include search paths --
because we are now resolving the path starting from the current directory.
Fixed with the attached patch.
(Tested with an OpenAxiom/ECL build.)
-- Gaby
Index: src/cmp/cmpdefs.lsp
===
RCS file: /cvsroot/ecls/ecl/src/cmp/cmpdefs.lsp,v
retrieving revision 1.98
diff -p -r1.98 cmpdefs.lsp
*** src/cmp/cmpdefs.lsp 4 Oct 2010 19:50:17 - 1.98
--- src/cmp/cmpdefs.lsp 6 Oct 2010 03:45:26 -
*** coprocessor).")
*** 43,50
(defvar *ld-format* #-msvc "~A -o ~S -L~S ~{~S ~} ~...@[~s~]~{ '~A'~} ~A"
#+msvc "~A -Fe~S~* ~{~S ~} ~...@[~s~]~{ '~A'~} ~A")
! (defvar *cc-format* #-msvc "~A \"-I~A\" ~A ~:[~*~;~A~] -w -c \"~A\" -o \"~A\"~{ '~A'~}"
! #+msvc "~A -I\"~A\" ~A ~:[~*~;~A~] -w -c \"~A\" -Fo\"~A\"~{ '~A'~}")
#-dlopen
(defvar *ld-flags* "@LDFLAGS@ -lecl @CORE_LIBS@ @FASL_LIBS@ @LIBS@")
--- 43,50
(defvar *ld-format* #-msvc "~A -o ~S -L~S ~{~S ~} ~...@[~s~]~{ '~A'~} ~A"
#+msvc "~A -Fe~S~* ~{~S ~} ~...@[~s~]~{ '~A'~} ~A")
! (defvar *cc-format* #-msvc "~A -I. \"-I~A\" ~A ~:[~*~;~A~] -w -c \"~A\" -o \"~A\"~{ '~A'~}"
! #+msvc "~A -I. -I\"~A\" ~A ~:[~*~;~A~] -w -c \"~A\" -Fo\"~A\"~{ '~A'~}")
#-dlopen
(defvar *ld-flags* "@LDFLAGS@ -lecl @CORE_LIBS@ @FASL_LIBS@ @LIBS@")
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys
On Fri, Oct 29, 2010 at 8:48 AM, Paul Goins wrote: > Hi, > > New to the list, so please forgive me if I've missed a thread that > covers this. > > I'm trying to compile ECL 10.4.1 under Windows 7 64-bit. > Unfortunately, I'm having problems, and the "Windows with > Mingw/Cygwin" section of the reference guide is totally blank, so I > thought I should ask here. > > (Note: already read some previous comments about 64-bit support. I'm > just trying to build a 32-bit ECL via 32-bit MinGW, so don't worry, > I'm not barking up *that* tree. However, the OS *is* 64-bit.) > > 1. I grabbed the CVS version of the Boehm GC. Built it successfully > using "./configure && make && make install". (7.1 failed to compile > via MSys in this way.) > > 2. I tried to ./configure and make ECL. This did not pan out... > > ./configure --enable-threads=yes > # no problem, but did give some warnings: > # configure: Configuring included GMP library: > # configure: WARNING: you should use --build, --host, --target Add --enable-boehm=system so that ECL picks up the GC library you just installed. PS: I have not been able to build ECL on windows 7, so let me know how it went. -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys
On Fri, Oct 29, 2010 at 12:48 PM, Paul Goins wrote: > Hello, > > On 10/29/2010 11:43 PM, Gabriel Dos Reis wrote: >> Add --enable-boehm=system so that ECL picks up the GC library >> you just installed. >> >> PS: I have not been able to build ECL on windows 7, so let me know >> how it went. > > Thanks Gabriel. Okay, this was rather encouraging. I can't quite > compile completely, but I got much further. > > This time, the configure line was: > > LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include \ > ./configure --enable-threads=yes --enable-boehm=system > > The LDFLAGS and CPPFLAGS specs were necessary to pick up the GC lib; > configure failed without them. yeah. > Info: resolving _GC_dont_gc by linking to __imp__GC_dont_gc (auto-import) > Info: resolving _GC_oom_fn by linking to __imp__GC_oom_fn (auto-import) > Info: resolving _GC_no_dls by linking to __imp__GC_no_dls (auto-import) > Info: resolving _GC_all_interior_pointers by linking to > __imp__GC_all_interior_pointers (auto-import) > Info: resolving _GC_time_limit by linking to __imp__GC_time_limit > (auto-import) > Info: resolving _GC_push_other_roots by linking to > __imp__GC_push_other_roots (auto-import) > Info: resolving _GC_start_call_back by linking to __imp__GC_start_call_back > (auto-import) > Info: resolving _GC_java_finalization by linking to > __imp__GC_java_finalization (auto-import) > Info: resolving _GC_print_stats by linking to __imp__GC_print_stats > (auto-importc:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: > warning: auto-importing has been activated without --enable-auto-import > specified on the command line. > This should work unless it involves constant data structures referencing > symbols from auto-imported DLLs. > libeclmin.a(threads.o): In function `ecl_import_current_thread': > c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/threads.d:248: > undefined reference to `GC_register_my_thread' > libeclmin.a(threads.o): In function `mp_process_enable': > c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/threads.d:408: > undefined reference to `gc_createthr...@24' > libeclmin.a(threads.o): In function `ecl_release_current_thread': > c:/Users/Vultaire/Desktop/pauls_stuff/ecl-10.4.1/src/c/threads.d:280: > undefined reference to `GC_unregister_my_thread) It sounds as if tECL is able to pick up the GC library but only a few symbols are missing. When you configured, did ECL really report that it was building a 32-bit program? -- Gaby -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys
On Fri, Oct 29, 2010 at 2:40 PM, Marko Kocić wrote: > Just wanted to ask the same question, but you beat me to it :) > I'm using mingw64, Win7 64, similar to you. I have been using mingw64, windows 7 64-bit, and I have not been able build full ECL. However, I can build ecl_min.exe, but it crashes when executed. > > I can build gc-7.2-alpha-4 as both 32 and 64 bit, by setting CFLAGS="-mXX" > flag. > The problem is that gmp on windows could be compiled only as -m32. I > tried gmp-4.3.2 and gmp-5.0.1 and latest mipr and I was able to > compile them only with -m32. > (Does anyone knows gmp compatible lib that can be used instead of gmp on > win64?) That is weird. I am able to build both GC and GMP as 64-bit libraries. Make sure that you're using the mingw64/GCC version that defaults to 64-bit. (they distribute two sets of compilers with different default.) -- Gaby -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys
On Fri, Oct 29, 2010 at 3:20 PM, Juan Jose Garcia-Ripoll wrote: > Regarding more generally Win64 support, I have built ECL with Windos64 > support using Microsoft's compilers. Indeed this is the regular build in > ECL's test farm whenever it is not off the grid (ecls.sf.net/logs.html). I > was never able to install mingw64 on that box (Windows Server 2008) so I > really do not know whether the compiler builds 64 bits executables or not. > In any case, it is been one month since I looked at the Windows port and as > I said our test > Juanjo I'm reading this as suggesting that the build problem I am having would be confined to mingw64 port only. What was your issue with the mingw64 installation? (Did you use the auto installer?) -- Gaby -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys
On Fri, Oct 29, 2010 at 3:32 PM, Marko Kocić wrote: > On Fri, Oct 29, 2010 at 10:28 PM, Gabriel Dos Reis > wrote: >> On Fri, Oct 29, 2010 at 2:40 PM, Marko Kocić wrote: >>> Just wanted to ask the same question, but you beat me to it :) >>> I'm using mingw64, Win7 64, similar to you. >> >> I have been using mingw64, windows 7 64-bit, and I have not been able >> build full ECL. However, I can build ecl_min.exe, but it crashes when >> executed. >> >>> >>> I can build gc-7.2-alpha-4 as both 32 and 64 bit, by setting CFLAGS="-mXX" >>> flag. >>> The problem is that gmp on windows could be compiled only as -m32. I >>> tried gmp-4.3.2 and gmp-5.0.1 and latest mipr and I was able to >>> compile them only with -m32. >>> (Does anyone knows gmp compatible lib that can be used instead of gmp on >>> win64?) >> >> That is weird. I am able to build both GC and GMP as 64-bit libraries. >> Make sure that you're using the mingw64/GCC version that defaults to 64-bit. >> (they distribute two sets of compilers with different default.) > > Which version of GMP you compiled as 64bit, and which MingW > distribuition you use? I installed GMP=5.0.1 on August 9, 2010. Mingw64, I'm using TDM64-1 (May 2010), which defaults to 64-bit. > Mine defaults to 64, but when building gmp it > builds only 32 bit version, and fail when I try to set ABI=64 or -m64. > I cnn't check which mingw64 distribution I was using right now, but > think it was the one fro tdragon (or something). Hmm, send me the config.log (privately.) -- Gaby -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys
On Fri, Oct 29, 2010 at 3:34 PM, Juan Jose Garcia-Ripoll wrote: > I did not find such a thing. All I found were several mingw64 packages and > various naming conventions for them, no msys and thus no apparent support > for Unix-like builds and an overall lack of instructions. It was pretty > frustrating and I gave up at some point, installing mingw32+msys, which I > knew how to find. 1. Install msys as usual (yes 32-bit, there is no 64-bit at the moment, and that won't happen anytime soon.) It works perfectly for both 32-bit and 64-bit. 2. Download and install mingw64 -- use the automated installation (anything else is a nightmare, at least from my perspective.) http://tdm-gcc.tdragon.net/download There are two versions: (a) one that defaults to 32-bit, but can also generate code on demand; (b) one that defaults to 64-bit, but can generate 32-bit on demand. I use the latter. 3. You should be good to go. -- Gaby -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Need help compiling ECL 10.4.1 (32-bit) on Win7 64-bit via mingw32/msys
On Sat, Oct 30, 2010 at 10:51 PM, Paul Goins wrote: > I've looked into things a bit further here. Perhaps now it's not > problems with ECL per se, but with compiling the Boehm GC. Is this GC from CVS as of today? -- Gaby -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] ECL trunk fails to compile
Hi Juanjo, ECL trunk (CVS) fails to compile on x86_64 running openSUSE-11.3 (GCC 4.5.0) ;;; Note: ;;; Invoking external command: ;;; gcc -I. "-I/home/gdr/src/ecl.cvs/build/" -DECL_API -I"/home/gdr/src/ecl.cvs/build/c" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -fPIC -Dlinux -I"/home/gdr/src/ecl.cvs/src/c" -w -c "lsp/numlib.c" -o "lsp/numlib.o" In file included from lsp/numlib.c:4:0: ./lsp/numlib.h:189:1: error: ‘_ecl_static_7_realdata’ undeclared here (not in a function) ./lsp/numlib.h:189:1: error: ‘_ecl_static_7_imagdata’ undeclared here (not in a function) ;;; (SYSTEM "gcc -I. \"-I/home/gdr/src/ecl.cvs/build/\" -DECL_API -I\"/home/gdr/src/ecl.cvs/build/c\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -fPIC -Dlinux -I\"/home/gdr/src/ecl.cvs/src/c\" -w -c \"lsp/numlib.c\" -o \"lsp/numlib.o\"") returned non-zero value 1 Available restarts: 1. (CONTINUE) Continues anyway. 2. (ABORT) ABORT Top level. -- Gaby -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL trunk fails to compile
On Sat, Nov 6, 2010 at 1:19 PM, Juan Jose Garcia-Ripoll wrote: > On Sat, Nov 6, 2010 at 10:31 AM, Gabriel Dos Reis > wrote: >> >> Hi Juanjo, >> >> ECL trunk (CVS) fails to compile on x86_64 running openSUSE-11.3 (GCC >> 4.5.0) > > This has been fixed in CVS today. Sorry for the inconvenience. > Juanjo I concur that it is working again. Thanks! -- Gaby -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] fatal: relocation errors on Solaris x86 and OpenSolaris 64-bit.
On Sun, Nov 7, 2010 at 2:54 PM, Dr. David Kirkby wrote: > It's a shame it can't be configured, but I understand your reasons. Not every tiny bit of unportable code should be candidate for configure. Some are best just avoided. > >> Juanjo >> > > Unless I am mistaken, this problem is only seen with gcc. In other forums, you have lamented that C programmers don't write codes according to the C standard. Well, computed gotos are not standard C. I'm surprised that you are advocating to keep them regardless. They do impose some constraints on generation of position-independent codes. Even though one might argue that GCC has a regression/bug compared to previous versions, you should know that the construct itself is non-standard. -- Gaby -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] fatal: relocation errors on Solaris x86 and OpenSolaris 64-bit.
On Mon, Nov 8, 2010 at 2:45 AM, Dr. David Kirkby wrote: > I assumed the fact the Sun compiler was compiling this without problems, > that the code was standard C, but I take your word for the fact the bit of > code is not. I don't actually know precisely the bit of affected code, so I > was unaware it was not C. The technique is simple: store `addresses' of labels in a table, and jump to the entries as appropriate. The only snag is that `address of label' is inexistent in standard C. For more information about the extension in GCC, see: http://gcc.gnu.org/onlinedocs/gcc-4.5.1/gcc/Labels-as-Values.html#Labels-as-Values -- Gaby -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] temporar files left behding by ECL
Hi Juanjo, I reported this issue a couple of months ago, but I don't think anything has happened. ECL builds leave behind lot of temporary files in the temporary directory (this happens both on linux and windows, I've not built ECL on macs for a while.) For example, I have gauss[14:46]% ls /tmp/ecl* /tmp/eclinit0ErHFR.c/tmp/eclinitiPIvZv.tmp /tmp/eclinitpHBZJP.o /tmp/eclinit0ErHFR.o/tmp/eclinitjJjDLM.c/tmp/eclinitpHBZJP.tmp /tmp/eclinit0ErHFR.tmp /tmp/eclinitjJjDLM.o/tmp/eclinitr834Sq.c /tmp/eclinit2oPxW6.c/tmp/eclinitjJjDLM.tmp /tmp/eclinitr834Sq.o /tmp/eclinit2oPxW6.o/tmp/eclinitN6gaEo.c/tmp/eclinitr834Sq.tmp /tmp/eclinit2oPxW6.tmp /tmp/eclinitN6gaEo.o/tmp/eclinitRK5S8v.c /tmp/eclinit6L8yrj.c/tmp/eclinitN6gaEo.tmp /tmp/eclinitRK5S8v.o /tmp/eclinit6L8yrj.o/tmp/eclinitN7xdrO.c/tmp/eclinitRK5S8v.tmp /tmp/eclinit6L8yrj.tmp /tmp/eclinitN7xdrO.o/tmp/eclinitsounff.c /tmp/eclinitBOw6Xe.c/tmp/eclinitN7xdrO.tmp /tmp/eclinitsounff.o /tmp/eclinitBOw6Xe.o/tmp/eclinitNHFpsi.c/tmp/eclinitsounff.tmp /tmp/eclinitBOw6Xe.tmp /tmp/eclinitNHFpsi.o/tmp/eclinitswZsCw.c /tmp/eclinitDx3EHX.c/tmp/eclinitNHFpsi.tmp /tmp/eclinitswZsCw.o /tmp/eclinitDx3EHX.o/tmp/eclinitOARSQ4.c/tmp/eclinitswZsCw.tmp /tmp/eclinitDx3EHX.tmp /tmp/eclinitOARSQ4.o/tmp/eclinitwCso3q.c /tmp/eclinitfBzVhN.c/tmp/eclinitOARSQ4.tmp /tmp/eclinitwCso3q.o /tmp/eclinitfBzVhN.o/tmp/eclinitofpQGU.c/tmp/eclinitwCso3q.tmp /tmp/eclinitfBzVhN.tmp /tmp/eclinitofpQGU.o/tmp/eclinitx2YLME.c /tmp/eclinitiPIvZv.c/tmp/eclinitofpQGU.tmp /tmp/eclinitx2YLME.o /tmp/eclinitiPIvZv.o/tmp/eclinitpHBZJP.c/tmp/eclinitx2YLME.tmp -- Gaby -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] fatal: relocation errors on Solaris x86 and OpenSolaris 64-bit.
On Wed, Dec 22, 2010 at 5:50 AM, Juan Jose Garcia-Ripoll wrote: > On Wed, Dec 22, 2010 at 2:48 AM, David Kirkby > wrote: >> >> Removing the compiler options >> -G -Bdynamic >> and replacing with >> -shared -Wl,-soname,libcliquer.so >> solved another text relocation issue in Sage >> http://trac.sagemath.org/sage_trac/ticket/9871 > > Well, it is the same problem here. I simply assumed that gcc was properly > interpreting the Solaris flags for shared library building, but it dit not: > it passed those flags to the linker, but did not realize that a shared > library was being built I think -Wl,xxx is documented as passing flags to the linker. That really means that. If in addition one wants the front-end and middle end to understand something, one has to give appropriate flags to them. -- Forrester recently released a report on the Return on Investment (ROI) of Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even within 7 months. Over 3 million businesses have gone Google with Google Apps: an online email calendar, and document program that's accessible from your browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] *default-pathname-defaults* and compilation
On Fri, Dec 24, 2010 at 6:35 AM, Juan Jose Garcia-Ripoll wrote: > I have fixed this by wrapping c:safe-run-program in a form that changes the > process current directory to the one dictated by *default-pathname-defaults* > I am not yet sure that this is the right solution. > > The problems you were experiencing were due to a contributed patch that > shortens filenames: instead of using the full name, just relative to > *default-pathname-defaults*. This was done to reduce the size of the command > line. I do not know whether that patch was submitted because the user faced > a system error with very large programs, but I suspect so. That is correct. And also because, when cross-compiling, we want to emit pathnames short enough for the build environment to recognize. I had assumed (and at the time, that seemed to be correct) that EL started the compiler relative to the current working directory. Was that assumption incorrect? -- Gaby -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Project status
On Mon, Dec 27, 2010 at 5:07 PM, Juan Jose Garcia-Ripoll wrote: > Testing and bug fixing proceeds. While I would love to make the release > before the 31st, I find it is more important getting it right. I say this > because it is 27th and I still have not managed to reactivate testing of > Axiom and Maxima. I can build OpenAxiom with ECL HEAD on a x86_64 running openSUSE-11.3. The testsuite reveals some type checking problems -- I don't know yet whether it is an OpenAxiom bug or an issue with ECL. I'll report on that later. > * Right now all Unix platforms build except for one Solaris box which I am > unable to debug (heisenbug, disappears when I use the debugger) > * Mingw32 also builds on my virtualbox (XP SP3). I don't have my Windows box handy, but I expect to do so by the end of the day. I don't promise to test ECL with OpenAxiom on given the time it takes to build OpenAxiom with ECL (but it would be a good thing to do). Thanks! -- Gaby -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] small typo fix
Hi Juanjo, Attached is the patch for the typo I was talking about earlier. The way I discovered it was a bit unusual: I forgot that my existing ECL build tree was 32-bit, but when I reconfigured and relaunched the build with 64-bit compiler, it took a different path and GCC chocked. After this correction, ECL builds fine and I reproduce the OpenAxiom issue you originally raised on the macintel. -- Gaby Index: src/c/big.d === RCS file: /cvsroot/ecls/ecl/src/c/big.d,v retrieving revision 1.48 diff -p -r1.48 big.d *** src/c/big.d 21 Nov 2010 21:05:51 - 1.48 --- src/c/big.d 29 Dec 2010 15:27:02 - *** _ecl_big_register_normalize(cl_object x) *** 107,113 #if GMP_LIMB_BITS >= FIXNUM_BITS static const limbs_per_fixnum = 1; #else ! static conts limbs_per_fixnum = (FIXNUM_BITS + GMP_LIMB_BITS - 1) / GMP_LIMB_BITS; #endif --- 107,113 #if GMP_LIMB_BITS >= FIXNUM_BITS static const limbs_per_fixnum = 1; #else ! static const limbs_per_fixnum = (FIXNUM_BITS + GMP_LIMB_BITS - 1) / GMP_LIMB_BITS; #endif -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] Help needed, really
Hi, Happy New Year everybody! The message below is an ackward way of starting the new year, but it seems there is no way around it. So, I'll try to be brief. I have a hectic schedule ahead of me but I'll try to follow the discussion, to the extent I can and also depending on whether it leads to anything that would be useful for building OpenAxiom with ECL. Matthew Mondor wrote: | On Thu, 30 Dec 2010 10:42:43 +0100 | Juan Jose Garcia-Ripoll wrote: | | Sorry that I didn't read the previous discussions, which most probably | happened on another list (and it's unclear to me why OpenAxiom requires | that implementation-dependent low-level information; why it cannot use | an FFI library or standard means such as CL min/max constants such as | MOST-POSITIVE-FIXNUM, MOST-NEGATIVE-FIXNUM to obtain the information it | needs); I'll simply suggest ideas about what I know, hoping they | weren't discussed or dismissed already. You may cross-post or quote | from this message as wanted. Most of the discussion happened in private between Juanjo and me, starting with his reporting that OpenAxiom could not build with ECL on macintel 64-bit. I was able to reproduce the problem and explained to him what was happening. I'm going to summarize the explanation, and also give a brief explanation of how and why *FEATURES* came into the picture. Yes, Juanjo suggested that I look at integer sizes. I'll also address that point, as I did in private when he made the suggestion. Then, I'll conclude. There is a potential for fruitful technical discussion and an opportunity for ECL to make itself more useful, but after having tried several times and having been called many things, I don't see that happening soon, so I'll just put the issue to rest on the platforms that are affected. This is a fresh new year and I'm not planning on starting it the way I ended the last one :-) Juanjo made a good effort at summarizing the discussion. But, I do not feel that his summary adequately captures the problem and what I have been suggesting. * Background OpenAxiom needs a Lisp system that it can extend with its own native libraries (e.g. C++ libraries.) Because of this extension requirement, OpenAxiom has to get some `binary compatibility' information from the Lisp system in order to construct adequate compiler and linker flags for its own (e.g. OpenAxiom's) libraries that it uses to extend the base Lisp. You may think of it as the ABI, but it is not the full ABI. Usually, this not much of a problem for systems that support only on kind of ABI interface. However, it is an issue on platforms that provide "compatibility" modes, e.g. Windows 64-bit making it possible to compile a program as a 32-bit binary or a 64-bit binary, or macintel offering 32-bit binary or 64-binary or universal binary formats. Of course, those of us who had tried SPARC v8 in 90s are familiar with the issue -- sometimes called "multilib". Please note that the `binary information' I'm talking about here is about a program binary flavor or a library flavor, NOT whether a C integer type has size 32-bit or 64-bit. For example, the C `long' integer type is 32-bit wide on many ilp32 systems and llp64 systems, but 64-bit on lp64 unix systems. Similarly the C `long long' integer type is 64-bit wide on almost all systems. So the suggestion of looking C integer types is a non-solution, despite being frequently suggested. The closest that could give some information is the width of `void*', but, again, that does not give the `binary information' in question for a value 32-bit or 64-bit does say whether libecl is only 32-bit or 64-bit or universal on macintels for example (where, I as said earlier Juanjo first experienced the problem with OpenAxiom.) * The problem As stated above, OpenAxiom needs an indication about the binary flavor of the Lisp system. From experiments, I noticed that the five systems supported by OpenAxiom (SBCL, ECL, CLISP, GCL, Clozure CL) give some hints on their *FEATURES* -- yes, including ECL (but more on this below)! As DS also pointed out, x86-64, etc., are common tokens to refer to a class of binary flavor. So, OpenAxiom was looking for that and decides (albeit imperfectly at times) whether to build 32-bit library or 64-bit library. What happens on macintel 64-bit with ECL is that ECL puts out I686 instead there -- even when it is clearly a 64-bit binary program. OpenAxiom then proceeded to build a 32bit library and tried to link it with ECL, and patatra! I explained that to Juanjo and suggested that ECL puts a more correct token on *FEATURES*. After that, we had had very long discussions. * Summary OpenAxiom is not insisting on the token appearing on ECL's *FEATURES* -- it just happens that it seems to be a common place where many free Lisp systems put that kind of information. As long as ECL provides a simple and reliable way to retrieve that information, I'm perfectly willing to put up with one more of its eccentri
Re: [Ecls-list] Help needed, really
On Sat, Jan 1, 2011 at 2:23 PM, DS wrote: > > On 1 Jan 2011, at 20:13, Gabriel Dos Reis wrote: > >> Anyway, I do no believe that the suggestion for ECL to make available > >> its binary flavor is equivalent to building and maintaining a database > >> of all imaginable ABIs and all combinations of processors. > > > > I believe Juanjo was referring to the second obvious way to figure out > system info from C: conditional compilation. In that case the C code > would be sort of like There usually are many ways to implement a specification. That does not necessarily mean we have to reject the specification just because, among the many possible implementations, we have found one that we don't like :-) > and you have to know the exact symbol used by every supported platform: > some are lowercase, some are uppercase and have underscores, etc. Same > for system version and architecture. This would be the database Juanjo > does not want to build and maintain, and I find that understandable. yes, but is a completely different issue and I don't see how that would implement the binary information in question. The issue is to tell the binary flavour of the ecl program or libecl library. This is the same kind of binary information that a dumb linker would use to reject a binary file for not being compatible. Lest this analogy be misconstrued, I am emphasizing that I am not suggesting that ECL writes its own linker. I'm just saying that the binary information is one that comes from the RESULTING program or library, not the size of the C integer types used. > > BTW this is the only way to tell one C compiler from another from > 'inside' C that I know of. yes, but it is not reliable information and I'm not sure how that is necessary and why it implements the binary flavour of a program. > The first obvious way (for me at least) would be the uname() libc call, > but it is more limited and as far as I know is not present on some > platforms, so it would require an autoconf test. It is true that uname while being a POSIX function may not be present on all system, and even it is it may not give what we are looking for. Another way of thinking about this is that you are given binary objects to link together to construct a program. You do not have access to the original program. But, you can tell the binary flavour by just looking at the header of each binary object file -- that is in essence what `file' utility does, and that is a preliminary step of linkers. DISCLAIMER: I am not suggesting that ECL reimplements `file' or a linker. On POSIX systems, ECL can just issue `file test-program-linked-against-required-c-lib' and use the output to determine the binary flavour. On non-posix systems (not many, among the platforms where this actually matters.), it can have its own custom program to look at the header of the test program. Certainly using Autoconf's triplet in an improved way may remove the need to have to write custom header reading program. > Figuring out the ILP32/LP64/whatever bit is a matter of comparing > sizeof()'s. It is also easy to figure out endianness. This is very > simple and portable C code. Autoconf now has standard macros to test endianness at configuration time. At this point, I'm not asking for ILP32/LP64/LLP64 -- though I recognize that other ECL users want find it useful to have. > OTOH configure scripts usually do some or all of these tests. GMP is > extremely platform-dependant and surely knows about all this. Yes, definitely. > Extracting the information from there might be easier and more portable. Yes, that is what I suggested in private conversion. In fact, all it takes is just link a dummy C file against the GMP library and look at the binary flavour of the program as indicated above. I suspect that the `file' utility will handle most cases. Taking the Ruby interpreter I gave earlier, I have ring:~ gdr$ file `which ruby` /usr/bin/ruby: Mach-O universal binary with 3 architectures /usr/bin/ruby (for architecture x86_64):Mach-O 64-bit executable x86_64 /usr/bin/ruby (for architecture i386): Mach-O executable i386 /usr/bin/ruby (for architecture ppc7400): Mach-O executable ppc The glaring case where `file' won't work is if compling on Windows using MS toolchain. In which case, we know we are dealing with PE/COFF binary file and we know how to get the information. For the rest, old UNIX `file' utility does the work. -- Gaby -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Help needed, really
On Sat, Jan 1, 2011 at 2:41 PM, DS wrote: > > On 1 Jan 2011, at 20:13, Gabriel Dos Reis wrote: > >> What happens on macintel 64-bit with ECL is that ECL > >> puts out I686 instead there -- even when it is clearly a 64-bit binary > >> program. > >> ... > >> I explained that to Juanjo and suggested that ECL puts a more correct > >> token on *FEATURES*. > >> ... > >> and after reading indication > >> that ECL intentionally put misleading information regarding platforms on > >> *FEATURES* > > > > On Mac OS X 10.6.5 (64-bit kernel and everything): > > $ uname -m > > i386 > > > > Looks like this is actually Mac OS X's fault. On my system, ECL has the following as *FEATURES* (:DARWIN :FORMATTER :LONG-LONG :UINT64-T :UINT32-T :UINT16-T :RELATIVE-PACKAGE-NAMES :LONG-FLOAT :DFFI :CLOS-STREAMS :CMU-FORMAT :ECL-PDE :DLOPEN :CLOS :BOEHM-GC :ANSI-CL :COMMON-LISP :IEEE-FLOATING-POINT :PREFIXED-API :FFI :I686 :COMMON :ECL) even when uname -m reports the same value you indicated. At any rate, I think `file' is far for reliable than `uname' because file looks at the specific object file reflecting the binary personaity, whereas `uname' gives something far for vague -- any string would still be conforming. > BTW, > > why > > is > > this > > mailing > > list > > software > > inserting > > new > > lines > > all > > over > > my > > messages? I really do not know :-) -- Gaby -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Help needed, really
On Sat, Jan 1, 2011 at 3:51 PM, David Brown wrote: > On Sat, Jan 01 2011, Gabriel Dos Reis wrote: > >> On POSIX systems, ECL can just issue `file >> test-program-linked-against-required-c-lib' and use the output to >> determine the binary flavour. On non-posix systems (not many, among >> the platforms where this actually matters.), it can have its own >> custom program to look at the header of the test program. Certainly >> using Autoconf's triplet in an improved way may remove the need to >> have to write custom header reading program. > > I might be missing something, but why is this something at ECL needs to > do, or even should be doing? If you need to know the format of the > executables, why not issue these tests as part of the build system? I > don't see why some knowledge needed by one specific application should > be included in ECL itself. There is absolutely no need for ECL to be a useful Lisp system for ECL-based programs that target multilib platforms. So, I believe you are missing nothing. And as I said, I spent more time arguing this than I expected. Consequently, I disabled OpenAxiom build with ECL where this is a known problem. Therefore, there is no more "need" for ECL to do anything on this. For non-multilib platforms, ECL-based OpenAxiom build should continue to work (as it does for other Lisp systems that find it appropriate to offer better support for multilib platforms.) -- Gaby -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Help needed, really
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll wrote: > On Sat, Jan 1, 2011 at 10:01 PM, Gabriel Dos Reis > wrote: >> >> > Extracting the information from there might be easier and more portable. >> >> Yes, that is what I suggested in private conversion. In fact, all it >> takes is >> just link a dummy C file against the GMP library and look at the binary >> flavour of the program as indicated above. I suspect that the `file' >> utility will handle most cases. > > The hardest point of the conversation, and one that people do not seem to > get, is that I have no idea how to do this which is written in the paragraph > and in the discussion before. Really, it makes the discussion very hard that > people do not realize that I have no idea how to get binary information from > an executable, or gather the binary mode from GMP just by linking a custom > program -- to begin with, it would be utterly impossible to link against > this library before having guessed the appropriate linker/compiler flags! I have no idea what you mean by "linking against this library before having guessed the appropriate linker/compiler flags!". I don't recall I ever suggest that, and I really don't understand what you mean by that. -- Gaby -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Help needed, really
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll wrote: > Now let's put this in context. Should OpenAxiom or any other ECL user want > to link against a preinstalled GMP, or gnome library, would they demand that > the library supplies this information? How would they obtain that > information? Is ECL just s random library or at the minimum a Lisp system? I must confess that until now, I thought it as primarily a Lisp system that provided a library. I had been using it that way, and was expecting to find similar usefulness as from other free Lisp system. I may very well have been wrong; in which case, I offer my apologies from having brought this issue based on wrong expectation of usefulness. -- Gaby -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Help needed, really
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll wrote: > * Autoconf triplets. ECL currently exports them as *features* and as the > output of other functions but they do not work. They are unreliable and OS > X, where OpenAxiom failed to build because of this, is an example. Autoconf reports the same triplet to ECL that it reports to OpenAxiom Yet, OpenAxiom builds successfuly with SBCL and GCL on that same machine with the same machine. -- Gaby -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Help needed, really
On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll wrote: > This seems to be the current attitude in the Autoconf'ed world, where > uniform build environments are assumed and deviations from them are a > responsibility of the packager or builder. I don't know what you mean by that. I don't recall that the GMP library is supposed to be linked against only in a uniform build environments, nor do I understand why that has to be assumed (in this specific case.) -- Gaby -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Help needed, really
On Sun, Jan 2, 2011 at 10:58 AM, Juan Jose Garcia-Ripoll wrote: > On Sun, Jan 2, 2011 at 10:39 AM, Gabriel Dos Reis > wrote: >> >> On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll >> wrote: >> > On Sat, Jan 1, 2011 at 10:01 PM, Gabriel Dos Reis >> > wrote: >> >> >> >> > Extracting the information from there might be easier and more >> >> > portable. >> >> >> >> Yes, that is what I suggested in private conversion. In fact, all it >> >> takes is >> >> just link a dummy C file against the GMP library and look at the binary >> >> flavour of the program as indicated above. I suspect that the `file' >> >> utility will handle most cases. >> > >> > The hardest point of the conversation, and one that people do not seem >> > to >> > get, is that I have no idea how to do this which is written in the >> > paragraph >> > and in the discussion before. Really, it makes the discussion very hard >> > that >> > people do not realize that I have no idea how to get binary information >> > from >> > an executable, or gather the binary mode from GMP just by linking a >> > custom >> > program -- to begin with, it would be utterly impossible to link against >> > this library before having guessed the appropriate linker/compiler >> > flags! >> >> I have no idea what you mean by "linking against this library before >> having guessed the appropriate linker/compiler flags!". I don't recall >> I ever suggest that, and I really don't understand what you mean by that. >> >> -- Gaby > > The sentence "In fact, all it takes is just link a dummy C file against the > GMP library and look at the binary flavour of the program as indicated > above" implies that the dummy file has to be linked against GMP. That in > turn requires knowing what type of library it is, whether it was built with > long integers, small pointers, whatever. No, that was not the suggestion. Let me explain one more time. You link this dummy C file against the GMP library just the same way you currently build and link ECL against the GMP. The configuration/build requirements remains exactly the same. If GMP is system-wide installed, you just proceed to link the dummy file against the library, using exactly the same flags as you currently do. If you have to build GMP, you build that library first (as you currently do), then you link the dummy C file against that with exactly the same flags as you do today. Nothing changes there. You do not need to infer the binary personality before you link against GMP. The purpose of that dummy program is solely to give the same binary personality that the ECL program and library would have. The only reason you would do that before proceeding with the remaining ECL build is so that you can cache that information in the ECL image (e.g. *FEATURES*) if you so chose to. You can very well just build the usual ecl program, then determine the binary personally, and put that in some file that gets installed with the the ECL system and make it available to users later. The possibilities are numerous, but we do not need to pick the worse possible realization or non-realization of the idea and shut the whole thing down on that basis. -- Gaby -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Help needed, really
On Sun, Jan 2, 2011 at 12:42 PM, Juan Jose Garcia-Ripoll wrote: > On Sun, Jan 2, 2011 at 10:54 AM, Gabriel Dos Reis > wrote: >> >> On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll >> wrote: >> >> > This seems to be the current attitude in the Autoconf'ed world, where >> > uniform build environments are assumed and deviations from them are a >> > responsibility of the packager or builder. >> >> I don't know what you mean by that. I don't recall that the GMP library >> is supposed to be linked against only in a uniform build environments, nor >> do I understand why that has to be assumed (in this specific case.) > > What I mean is that right now I am using prepackaged software built with > standard compiler flags. None of what I suggest should change that. > Developers provide the basic software and port > maintainers keep track of how the build/compile/link flags of their platform > evolve and pass those to their libraries, compilers, editors, etc, using > standard Autoconf techniques. That provides a "uniform" environment in which > the developer of a piece of software is isolated from the complexities of > the platforms in which it is delivered, as far as standard features (POSIX, > C, math, etc) are concerned, of course. Of course, that is one of the reasons why I believe it is ECL's job to isolate the binary personally complexity from its users -- like other Lisp systems do -- so that N users don't have to invent N buggy ways of getting information already contained in ECL and that ECL should provide. > It also may safely expect that all > software is properly installed and binary compatible. A further complexity here is that ECL is a Lisp compiler that targets the C language -- variously implememted by various C compilers with several ABI and whatnots. The implication is that if ECL finds it great to profit from the isolation provided by the various packages it is using, it should also isolate its users from the low-level complexities brought up by its design choices. > That is how I expected ECL to be used and so far I have not received any > feedback that this mode of use makes it totally useless and impossible to > integrate in reasonable software. You can take what I've reported so far as a feedback, or you can also dismiss it and maintain the invariant that you have not received any feedback. > Where particular needs had to be met, the > configuration mechanism is flexible enough that developers may provide > nonstandard build and link options *in their private copies*, and be > consistent then with their own software. So, is it your official recommendation to maintain private own copy of ECL? I'm not claiming it is a wrong suggestion, I just wanted to make sure that I am not reading too much into your suggestion and I'm not putting words in your mouth. Please confirm. > We should put also things in perspective. What do other lisps really > provide? Lisps around are not that smart and might fool you. That may very well be the case. But, they have not done that yet, and if I concretely ran into that issue and can reproduce it, be sure I would report it, just like I reported to ECL. > If I take my > copy of SBCL the *features* it supplies are just names of assembler > backends. From base-target-features.lisp-expr > ;; machine architecture features: > ;; :x86 any Intel 386 or better, or compatibles like the AMD K6 or > K7 > ;; :x86-64 any x86-64 CPU running in 64-bit mode > ;; :alpha; DEC/Compaq Alpha CPU > ;; :sparc any Sun UltraSPARC (possibly also non-Ultras -- currently > untested) > ;; :ppc any PowerPC CPU > ;; :hppa any PA-RISC CPU > ;; :mips any MIPS CPU (in little-endian mode with :little-endian) > Note how this is incomplete. It may be incomplete, but so far it suffices for what the kind of information I have been asking from ECL. > You can not deduce from here how C software has > to be built and linked to be properly loaded and used by SBCL. Please note that I have never asked ECL to give me an information so that I "can deduce how C software has to be built and linked to be properly loaded and used by SBCL". > This is > ultimately confirmed by looking at the features of the Solaris/Sparc copy > that is installed in Sage's buildnet (v 1.0.17). It does not offer really > useful hints about what ABI it uses > (:ANSI-CL :COMMON-LISP :SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS > :SB-UNICODE :SB-EVAL :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :SPARC :UNIX > :ELF :SUNOS :LINKAGE-TABLE :STACK-ALLOCATABLE-CLOSURES :OS-PROVIDES-DLOPEN > :OS-PROVIDES-DLADDR :OS-PROVIDES-PUTWC :OS-PROVIDES-BLKSIZE-T > :OS-PROVIDES-SU
Re: [Ecls-list] Help needed, really
On Sun, Jan 2, 2011 at 3:27 PM, David Brown wrote: > On Sun, Jan 02 2011, Gabriel Dos Reis wrote: > >> On Sun, Jan 2, 2011 at 12:42 PM, Juan Jose Garcia-Ripoll > >> Of course, the number of combinations will be always limited, in practice. >> I never asked for an unlimited combinations. > > It seems to me that you have. That is a mistaken impression. -- Gaby -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Help needed, really
On Sun, Jan 2, 2011 at 3:27 PM, David Brown wrote: > Most Lisp compilers take significant amounts of work to make them build > on a different configuration. ECL often just works. Asking it to try > and deduce a bunch of information about that configuration would make it > much less portable than it is. Bunch of information already contained in the "just working ECL" That is the part that is being consistently missed in this discussion. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Help needed, really
On Sun, Jan 2, 2011 at 4:04 PM, David Brown wrote: > On Sun, Jan 02 2011, Gabriel Dos Reis wrote: > >> On Sun, Jan 2, 2011 at 3:27 PM, David Brown wrote: >> >>> Most Lisp compilers take significant amounts of work to make them build >>> on a different configuration. ECL often just works. Asking it to try >>> and deduce a bunch of information about that configuration would make it >>> much less portable than it is. >> >> Bunch of information already contained in the "just working ECL" >> That is the part that is being consistently missed in this discussion. > > $ ./configure > $ make > $ make install > > That's what I mean by "just works". Oh, I did not realize that your definition of "just works" is the successful completion of "make install". In that case, I have nothing else to add since we obviously have so differing notions of "works" that there is no possible reconciliation in this discussion. -- Gaby -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Help needed, really
On Sun, Jan 2, 2011 at 4:06 PM, David Brown wrote: > Then, what exactly, are you asking for? There are an unbounded number > of combinations that ECL can support, "can support" is very different from "actually support". For example, using your criteria, there is an unbounded set of standard C conforming compilers on which ECL cannot possibly work -- because the the ECL's C source code contains lots of undefined behaviour. However, we are all happy because for the limited set of platforms that ECL *actually* runs, we can expect most C compilers to be blindsighted and generate codes that *appear* to work -- even if the source code is buggy. > since it can easily support new > platforms without even changing the source code. What information may > be necessary for a complex C/C++ based application to successfully link > against it can't really be determined ahead of time. Only because you are insisting on maligning the topic of the discussion. -- Gaby -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Help needed, really
On Sun, Jan 2, 2011 at 4:55 PM, Juan Jose Garcia-Ripoll wrote: > On Sun, Jan 2, 2011 at 11:25 PM, Gabriel Dos Reis > wrote: >> >> However, we are all happy because for the limited set of platforms that >> ECL *actually* runs, we can expect most C compilers to be blindsighted >> and generate codes that *appear* to work -- even if the source code >> is buggy. > > Should we start a flame war now on a different topic? Only if you believe that pointing that ECL is reling on undefned behaviour at various places, is starting a flame war. For example, do you believe that the way ECL detects in which direction the C stack grows is actual C code with defined behaviour? It certainly isn't. I was making a point to someone claiming that "ECL just works." You don't have to feel bad about it or feel that it is a flame war. It was meant to. It was simply pointing out a basic fact to someone making arguments in the abstract. > Ah, great. for what? -- Gaby -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Help needed, really
On Sun, Jan 2, 2011 at 4:53 PM, Juan Jose Garcia-Ripoll
wrote:
> On Sun, Jan 2, 2011 at 9:41 PM, Gabriel Dos Reis
> wrote:
>>
>> Because of ECL's design decision to target the C programming language,
>> and the C programming language has lots ot parameters left to the
>> implementation, it is certainly ECL's responsability to document choices
>> that affect inter-operation with other C library -- at least if ECL claims
>> to be embeddable. It has to document enough of the characteristics
>> so that a knowledgeable person can construct a compatible library.
>
> First this paragraph, because it summarizes the spirit of this discussion. I
> have marked in bold what is relevant.
> 1) Parameters left to the implementation. ECL does not take any choice
> itself. The person who configures ECL does, by choosing to pass any
> CFLAGS/LDFLAGS, or by using the default configuration parameters.
> 2) Documentation. ECL does not have a way to name the choices done by the
> user right now, because those choices are in the CFLAGS/LDFLAGS.
> 3) Offer enough information to build compatible libraries. Your sentece
> seems to imply that we hide information, and all your emails have had this
> implication. Nothing is hidden, it is provided in the exported CFLAGS,
> either in ECL itself (through dedicated variables, through functions to
> compile and link), or in scripts. We simply do not provide names for those
> choices because, as I have insisted thousands of times, I do not have them.
I certainly do believe ECL is hiding the information. And we can agree to
disagree on that. That is OK.
> Now, (and this goes to Samium) I did not reopen this discussion in the
> public to open a flame war. I expected it to be constructive and the
> knowledgeable lot help me understand what I am missing and the things I
> could do to solve this problem. But overall I see the same patterns repeated
> that lead the private discussion to a stall and uneasy feelings, at least on
> my side.
You are complaining about flame war (called me things when it was
no warranted), yet you are doing exactly what you complaining about -- and
what is irritating. See below.
> * You, Gabriel, insist on the need to provide information to users, but give
> no precise names nor do you explain how I should offer this information.
I first try to convey an idea to you. I noticed that when I tried to give a
name, the discussion went instantaneously in the wrong direction because
you were focused on the name I gave. So, I refrain from giving a specific
name so that you don't get sidetracked. Instead, I have been trying to
convey the general idea to you. Do you seriously believe we would have gotten
anywhere if I insisted on a particular name and you were consistently
nitpicking on it?
> * Current isolation techniques, such as scripts providing valid
> CFLAGS/LDFLAGS, which are standard for known and supported software (KDE,
> gnome, apache, etc), are disregarded as useless. We have to provide "names"
> that the user can turn back into compiler flags (what level of isolation is
> this for a user?)
The problem as I explained in the private conversation was that the
CFLAGS/LDFLAGS
that ECL provides are useless.
> * Back to the topic of gathering information from binary files. I answer
> back that I do not know how to process that information. I do not even have
> the faintest idea of what is useful for you out of this
> jua...@sage:~$ file bin/ecl
> bin/ecl: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), dynamically
> linked (uses shared libs), not stripped
> How and what should I isolate? Hardcoded names? Grepping strings? Should I
> grep the output of "file" for a set of known keywords ("ELF", "COFF",
> "SPARC", X86-64, the list of processor names, etc) and turn them into
> *features*?
>From that information, I see key things:
* 64-bit
* SPARC V9
* optionally ELF
That is not all that can be inferred, but it is far better than nothing.
> * I add a couple of sentences about choices that appear in different
> compilers and turn executables incompatible, even if they have the same
> "binary" format. Those choices change the sizes of floating points,
> activate/deactivate the use of __thread local storage, ... the number is
> very large and I would not even know how to keep track of those. But they
> will definitely make your software incompatible with ECL's binary. Again I
> am just misdirecting the conversation, and this remark is disregarded.
I suspect this paragraph illustrates a key difference in our approach. I am
of the opinion that something is better than nothing and I'm a believer in
refinement based on actual practice. Your messages seem to indicate that
if you
Re: [Ecls-list] Help needed, really
On Mon, Jan 3, 2011 at 10:13 AM, Samium Gromoff <_deepf...@feelingofgreen.ru> wrote: > I am replying to several mails, by different authors here, sorry for > that. > > On Sat, 01 Jan 2011 13:13:36 -0600, Gabriel Dos Reis wrote: >> At the moment, since the discussion is stall and it does not appear that >> ECL is willing to make itself more useful (at least as far as OpenAxiom >> is concerned) on these multilib-platforms, and after reading indication >> that ECL intentionally put misleading information regarding platforms on >> *FEATURES*, I've disabled attempts to build OpenAxiom with ECL on know >> problematic platforms. > > My impression was that ECL doesn't /add/ information anywhere -- it merely > /forwards/ whatever is fed to it by autoconf. It's not intent, merely a > lack of sophistication. Yeah, there was an earlier assertion by Juanjo: # I already mentioned the problem with exporting Autoconf's detection of processor, # which on some platforms is flawed (intentionally, btw). It has been a long day and a short night, and I'm a bit jet lagged. I don't see this discussion getting anywhere, and I don't see any chances of progress now when I'm jet lagged than when I was not. I already said I was dropping the issue. My naivete has been to think from the outset, when I reported what was causing the build failure and made suggestion (that was shut down based on completely different interpretation of what I meant) that it was just a question of explaining and if I tried hard enough it should be resolved. However, what ensued proved me wrong. and the discussion over the week has significantly cut into any appetite I had developed over the last couple of years in contributing to make ECL a better alternative to other Lisp systems out there. I certainly was disposed to help implement missing features if the proposal was deemed of interest (and of course subject to improvements.) We never got to that point, I doubt we ever will. Reading past messages suggests that most ECL users who expressed themselves are either against, or don't care, or seem to understand but believe it is not an ECL problem. The choice I am left with to deal with it in a way that would not unproductively consume more time, and that would not put me in this burlesque situation. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Help needed, really
On Tue, Jan 4, 2011 at 8:17 AM, Samium Gromoff <_deepf...@feelingofgreen.ru> wrote: > On Tue, 4 Jan 2011 05:10:55 -0600, Gabriel Dos Reis > wrote: >> On Mon, Jan 3, 2011 at 10:13 AM, Samium Gromoff >> <_deepf...@feelingofgreen.ru> wrote: >> > My impression was that ECL doesn't /add/ information anywhere -- it merely >> > /forwards/ whatever is fed to it by autoconf. It's not intent, merely a >> > lack of sophistication. >> >> Yeah, there was an earlier assertion by Juanjo: >> # I already mentioned the problem with exporting Autoconf's detection >> of processor, >> # which on some platforms is flawed (intentionally, btw). > > Now, I hope, you don't read this as Juan's intentional reduction of the > autoconf's output, don't you? > > What Juan says, in your quote, is that /Autoconf/ intentionally produces > flawed processor identification information. > >> It has been a long day and a short night, and I'm a bit jet lagged. >> I don't see this discussion getting anywhere, and I don't see any chances >> of progress now when I'm jet lagged than when I was not. I already >> said I was dropping the issue. > > Now, wait, Juan pulled out some code to solve your problem, you cannot > just disappear, the onus is upon you to evaluate his proposal! : -) In private, I did notify Juanjo of my schedule (and I'm mindful that he has a tight schedule too) a few days ago when he informed me of his own tight schedule. But, we spent more time making no progress than actually doing anything. My stating that I was dropping this issue predated the email I sent today. I just landed in Paris and see that a preliminary patch has been proposed when a lot of heat has already spilled into hard feelings on both sides. Given what it took to get here, and considering that I had no intention to waste anybody's time, I hope you understand my hesitation in believing (again) that something really useful might get out of this in reasonable time with nobody feeling unduly maligned >> My naivete has been to think from the outset, when I reported what was >> causing the build failure and made suggestion (that was shut down based on >> completely different interpretation of what I meant) that it was just a >> question >> of explaining and if I tried hard enough it should be resolved. However, >> what >> ensued proved me wrong. and the discussion over the week has significantly >> cut into any appetite I had developed over the last couple of years >> in contributing to make ECL a better alternative to other Lisp systems >> out there. > > Now, it's a hard problem, and you've had phylosophical differences (Juan > appears to value high portability, whereas you seem to need a high > degree of completeness). I think that statement underestimates my appreciation of high portability, and I am not sure I am advocating a high degree of completeness -- I had stated several times that I'm not asking for complete ABI specification and that having tokens like :x86_64 or sparc and 64-bit,etc., was already a progress. > I understand that this might not be the best > moment to discuss this further, in your position, but there is no need > for hard feelings either, really. > >> I certainly was disposed to help implement missing features if the proposal >> was >> deemed of interest (and of course subject to improvements.) We never got to >> that point, I doubt we ever will. > > Juan has just posted code, so it's not that bad. : -) I'll look at it tomorrow after I have some rest. > >> Reading past messages suggests that most ECL users who expressed themselves >> are either against, or don't care, or seem to understand but believe >> it is not an ECL >> problem. > > Thankfully, you don't have to convince the users to implement a > feature. : -) -- Gaby -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] FFI_SYSV and FFI_UNIX64
ECL fails to build on Windows 7 64-bit using msys and MinGW64. The symbols FFI_SYSV and SYS_UNIX64 appear not be defined when they are referenced in src/c/ffi.d:145 src/c/ffi.d:147 Configure command line was ./configure --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 I'm using separately installed GMP (5.0.2) and Boehm GC (from cvs.) -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] building open axiom with ECL on Mac OS X
Nick Walters writes: | Hello, | | I am trying to get a working build of Open Axiom on Mac OS X. My requirements | are such this must be built with ECL as opposed to one of the other Lisp | compilers. I am building Open Axiom 1.4.1 with the latest ECL (11.1.1). I am | able to build but when I try to run the open-axiom command, everything but the | simplest functions are broken: Hi Nick, Thanks for doing this. I am currently on travel attending CICM 2011 so I do not have direct access to a mac. There were some issues with the released ECL-11.1.1 that were resolved only in the cvs version (which regrettably also identifies itself as ECL-11.1.1). I do not know whether this is one of them. From your tests and the messages [...] | (2) -> integrate(x^2, x) | | * | >> System error: | * is not a valid type specifier. | | (2) -> x^2 | | * | >> System error: | * is not a valid type specifier. it sounds as if ECL is having some difficulties with type specifiers (OpenAxiom uses function type proclaimations to aid ECL's compiler with better code generation.) My experience with ECL is that it tends to lead to frustrating debugging sessions. Could you report the backtrace when this error occurs? Here is how you would do it: 1. start OpenAxiom 2. Instruct OpenAxiom to BREAK into the ECL debugger by issueing )set break break 3. try to evaluate any of the expressions that are causing troubles That should drop you into the ECL debugger in case an error occurs. 4. enter :backtrace 5. send the stack trace. | Has anyone successfully built and run Open Axiom with ECL on the Mac? I am | using Mac OS X 10.6.8 with the latest Xcode tools. Any help is greatly | appreciated. Thanks! Last time I tried was on 04/11/2011 and I did not have any problem. Thanks, -- Gaby -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] infinite loops in make clean
I synced my local copy of ECL to match trunk.
Then I issued 'make clean'. The result is an
infinite loop:
(cd tests; make clean)
/bin/sh: line 0: cd: tests: No such file or directory
make[4426]: Entering directory `/home/gdr/src/ecl.cvs/build'
for i in lsp cmp clos clx tk ext; do rm -f lib$i.a
$i/?*.{o,eclh,data,c,sdat,h,fas}; done
rm -f help.doc
(cd tests; make clean)
/bin/sh: line 0: cd: tests: No such file or directory
make[4427]: Entering directory `/home/gdr/src/ecl.cvs/build'
for i in lsp cmp clos clx tk ext; do rm -f lib$i.a
$i/?*.{o,eclh,data,c,sdat,h,fas}; done
rm -f help.doc
(cd tests; make clean)
/bin/sh: line 0: cd: tests: No such file or directory
make[4428]: Entering directory `/home/gdr/src/ecl.cvs/build'
for i in lsp cmp clos clx tk ext; do rm -f lib$i.a
$i/?*.{o,eclh,data,c,sdat,h,fas}; done
rm -f help.doc
(cd tests; make clean)
/bin/sh: line 0: cd: tests: No such file or directory
make[4429]: Entering directory `/home/gdr/src/ecl.cvs/build'
for i in lsp cmp clos clx tk ext; do rm -f lib$i.a
$i/?*.{o,eclh,data,c,sdat,h,fas}; done
rm -f help.doc
(cd tests; make clean)
/bin/sh: line 0: cd: tests: No such file or directory
make[4430]: Entering directory `/home/gdr/src/ecl.cvs/build'
for i in lsp cmp clos clx tk ext; do rm -f lib$i.a
$i/?*.{o,eclh,data,c,sdat,h,fas}; done
rm -f help.doc
(cd tests; make clean)
/bin/sh: line 0: cd: tests: No such file or directory
make[4431]: Entering directory `/home/gdr/src/ecl.cvs/build'
which reacted very violently with another infinite loop
when I pressed Ctrl-C:
^Cmake[4431]: *** [clean_lisp] Interrupt
make[4430]: *** [mostlyclean] Interrupt
make[4429]: *** [mostlyclean] Interrupt
make[4428]: *** [mostlyclean] Interrupt
make[4427]: *** [mostlyclean] Interrupt
make[4426]: *** [mostlyclean] Interrupt
make[4425]: *** [mostlyclean] Interrupt
make[4424]: *** [mostlyclean] Interrupt
make[4423]: *** [mostlyclean] Interrupt
make[4422]: *** [mostlyclean] Interrupt
make[4421]: *** [mostlyclean] Interrupt
make[4420]: *** [mostlyclean] Interrupt
make[4419]: *** [mostlyclean] Interrupt
make[4418]: *** [mostlyclean] Interrupt
make[4417]: *** [mostlyclean] Interrupt
make[4416]: *** [mostlyclean] Interrupt
make[4415]: *** [mostlyclean] Interrupt
make[4414]: *** [mostlyclean] Interrupt
make[4413]: *** [mostlyclean] Interrupt
make[4412]: *** [mostlyclean] Interrupt
make[4411]: *** [mostlyclean] Interrupt
make[4410]: *** [mostlyclean] Interrupt
make[4409]: *** [mostlyclean] Interrupt
make[4408]: *** [mostlyclean] Interrupt
make[4407]: *** [mostlyclean] Interrupt
make[4406]: *** [mostlyclean] Interrupt
make[4405]: *** [mostlyclean] Interrupt
make[4404]: *** [mostlyclean] Interrupt
make[4403]: *** [mostlyclean] Interrupt
make[4402]: *** [mostlyclean] Interrupt
make[4401]: *** [mostlyclean] Interrupt
make[4400]: *** [mostlyclean] Interrupt
make[4399]: *** [mostlyclean] Interrupt
make[4398]: *** [mostlyclean] Interrupt
make[4397]: *** [mostlyclean] Interrupt
make[4396]: *** [mostlyclean] Interrupt
make[4395]: *** [mostlyclean] Interrupt
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] regression involving macro expansion, GETHASH, SETF, and HASH-SET
Hi, A fresh update of my local copy of ECL CVS version shows a regression involving macro expansion, GETHASH, SETF and HASH-SET. In short, after expansion, the arguments to HASH-SET seems to be switched. To reproduce this, issue the following in a fresh ECL session (compile-file "ht-test.lisp") (load "ht-test") The file ht-test.lisp is in attachment to this message. It is distilled from attempt to build OpenAxiom with ECL. I get: ;;; Loading #P"/home/gdr/build/ecl-x-oa/ht-test.fas" Condition of type: SIMPLE-TYPE-ERROR In function HASH-SET, the value of the second argument is "and" which is not of the expected type HASH-TABLE Available restarts: 1. (RESTART-TOPLEVEL) Go back to Top-Level REPL. Broken at SI:BYTECODES. [Evaluation of: (LOAD "ht-test")] >> -- Gaby (defparameter |KeyTable| (make-hash-table :test #'equal)) (defmacro |tableValue| (ht k) `(gethash ,k ,ht)) (setf (|tableValue| |KeyTable| "and") 'and) -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] regression involving macro expansion, GETHASH, SETF, and HASH-SET
Juan Jose Garcia-Ripoll writes: | On Sun, Jan 1, 2012 at 7:34 PM, Gabriel Dos Reis wrote: | | A fresh update of my local copy of ECL CVS version shows a regression | involving macro expansion, GETHASH, SETF and HASH-SET. In short, after | expansion, the arguments to HASH-SET seems to be switched. | | | Thanks for reporting. The problem is not actually related to the hash | functions. ECL now includes a tiny SETF form optimizer that simplifies some | expressions, trying to reduce the number of LET bindings that are generated. | Your macro reordered the list of arguments w.r.t the list produced by the | get-setf-expansion and this confused the optimizer. I will upload a patch | tonight. Thanks for the detective work. -- Gaby -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] regression involving macro expansion, GETHASH, SETF, and HASH-SET
On Sun, Jan 1, 2012 at 1:14 PM, Juan Jose Garcia-Ripoll wrote: > On Sun, Jan 1, 2012 at 7:34 PM, Gabriel Dos Reis wrote: >> >> A fresh update of my local copy of ECL CVS version shows a regression >> involving macro expansion, GETHASH, SETF and HASH-SET. In short, after >> expansion, the arguments to HASH-SET seems to be switched. > > > Thanks for reporting. The problem is not actually related to the hash > functions. ECL now includes a tiny SETF form optimizer that simplifies some > expressions, trying to reduce the number of LET bindings that are generated. > Your macro reordered the list of arguments w.r.t the list produced by the > get-setf-expansion and this confused the optimizer. I will upload a patch > tonight. > > Juanjo > Hi Juanjo, did you get a chance to commit the patch? It appears I may have missed it. -- Gaby -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] regression involving macro expansion, GETHASH, SETF, and HASH-SET
On Sun, Jan 15, 2012 at 2:29 PM, Juan Jose Garcia-Ripoll wrote: > On Sun, Jan 15, 2012 at 8:46 PM, Gabriel Dos Reis > wrote: >> >> Hi Juanjo, >> did you get a chance to commit the patch? It appears I may have missed it. > > > Yes, indeed, it is in git/CVS HEAD. I just checked with tonight's build and > I also verified that the sources in my laptop match those in Sourceforge. > Indeed, it works now. My local copy of ECL CVS was stale and I failed to spot the fix. -- Gaby -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Bug in code detecting stack growth direction
On Fri, Feb 3, 2012 at 8:23 AM, Juan Jose Garcia-Ripoll wrote: > I just noticed that some cleverly optimizing compilers broke the code I used > to detect whether the stack grows upwards or downwards. I will upload a > patch tonight. Hmm. The code in question invoked an undefined behaviour. So, it was just a disaster waiting to happen. The compilers can't be blamed. -- Gaby -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Bug in code detecting stack growth direction
On Fri, Feb 3, 2012 at 10:13 AM, Juan Jose Garcia-Ripoll wrote: > ECL is assuming that local variables are kept in the stack. Is this wrong? What is undefined behaviour isn't assuming the notion of "stack" -- which the C standard effectively does not know about. The crucial point is that it is undefined to compare the address of two distinct objects for relative position (e.g. before or after) unless they are part of an array (or one last the end address.) > Perhaps, but this is an implicit assumption in all C garbage collectors I > know and so far no compiler has broken this assumption. It is an undefined > behavior as per the ANSI C specification, but that is not what broke the > code ECL used. That wasn't it (thought it could have.) > What broke the test is the fact that the functions from the test were > inlined and thus the local variables ended up in a different order in the > stack, not the original assumption. Exactly. Because the local variables were distinct objects. > I have made the code non-deterministic > so most compilers will not inline the calls and hopefully the growth test > works. I hope you realize that it is just delaying the breakage point in time. > > Finally, though the test is fragile, it is not critical. Stack growth > direction is only used in two places > > 1* In ECL's code for detecting stack overflows. We might do without it, but > graceful handling of stack overflows based on alternative stacks proved to > be useless due to the signal-async problem. > > 2* In the Boehm-Weiser garbage collector to detect the extent of the stack > on different threads. As I said, this is a common assumption across C > implementations of garbage collectors and so far never broken. This confusese two things: (1) the existence of a stack; (2) the direction of growth. The test for (2) is invoking an undefined behaviour. Therefore, the outcome of that test does not say anything about the collector's assumption that there is a stack (1) and a defined direction of growth. > > So all in all, the broken test only affected "1" and now it seems to work. > > Best, > > Juanjo > > -- > Instituto de Física Fundamental, CSIC > c/ Serrano, 113b, Madrid 28006 (Spain) > http://juanjose.garciaripoll.googlepages.com -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Bug in code detecting stack growth direction
On Thu, Feb 9, 2012 at 8:24 PM, Daniel Herring wrote:
> On Fri, 3 Feb 2012, Juan Jose Garcia-Ripoll wrote:
>
>> I just noticed that some cleverly optimizing compilers broke the code I used
>> to detect whether the stack grows upwards or downwards. I will upload a
>> patch tonight.
>
> Wouldn't two calls to alloca() in a single function give a reliable answer
> on pretty much all platforms?
>
> #include
> #include
> int main()
> {
> void *x;
> void *y;
> x=alloca(100);
> y=alloca(100);
> printf("delta: %d\n", (int)(y-x));
You probably want to cast x and y to intptr_t and compare instead of the
substraction: you can't subtract two pointers that are not related to the same
object. You also probably want to check for availability of alloca.
> return 0;
> }
>
>
> The following was another idea; but it looks no better than what you have
> now.
>
> #include
> #include
> void * start;
> void * end;
> void recurse(int n, void *y)
> {
> int x;
> if(n==0)
> end=&x;
> else
> recurse(n-1, &x);
> }
> int main(int argc, char **argv)
> {
> int x;
> int times;
> start=&x;
> times=(random()%10)+1;
> recurse(times, start);
> printf("delta: %d\n", (int)(end-start));
> return 0;
> }
>
>
> This link indicates Sparc could violate some common assumptions about
> stack behavior (though it looks to me like he was confusing the register
> window with the stack).
> http://stackoverflow.com/questions/664744/what-is-the-direction-of-stack-growth-in-most-modern-systems
>
> - Daniel
>
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Ecls-list mailing list
> Ecls-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ecls-list
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] ECL build failure on 64-bit windows 7 using mingw-w64 toolchain
* fresh check out of CVS trunk * configure option: --build=x86_64-w64-mingw64 First failure appeared while compiling c/ffi.d. Reason: the symbol :WIN64 appears not to be defined anywhere so that the '@' translation could do something meaningful. Instead it replaced it with unknown, which of course gives a compile-time error. After modifying c/symbols_list.h and c/symbols_list2.h to include a definition for :WIN64, the build failed again because the function ecl_make_ulong_long was mistyped as ecl_make_ulong_Long (note the capital L for the second Long.) The same typo appears in c/number.d 3 times. After correcting those, I got an ecl_min.exe. Unfortunately, it failed to execute properly, apparently for the same reasons as 2 years ago. -- Gaby -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL build failure on 64-bit windows 7 using mingw-w64 toolchain
On Sun, Aug 19, 2012 at 8:37 AM, Juan Jose Garcia-Ripoll wrote: > I am a bit lost with the mingw64 toolchain, with so may different tarballs > and options. I must admit I have never managed to get it up and running. > What do I have to do to use it? Indeed, there are probably too many options around. Here is what I use: * Install traditional msys toolchains, conveniently packaged by the mingw-w64 people; one download, one click as explained here: http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS Note: When you unzip the package into a directory c:/foo, you get the msys.bat in the directory c:/foo/msys/bin. One directory deeper than what the wiki says. You can afterward arrange to have the structure c:/msys/bin (which I have) or leave it like that. Do not attempt to unpack directly into c: -- Windows won't let you do that anyway. The rest of the wiki is good. * GCC from TDM http://tdm-gcc.tdragon.net/ I chose the configuration that generates 64-bit binaries by default. It conveniently packages several things that are needed for development. Choose a directory of installation, for example c:/mingw64 Once you have installed GCC-TDM, you are good to go. If you are build your own packages and you want the compiler to automatically find its headers (e.g. for gmp.h or gc.h), use the option --prefix=c:/mingw64. The compiler considers c:/mingw64/include as a standard include path. If you use your own directory you will have to specify it every time to the package which wants it. /usr/local (which would reside under the msys directory, unless you make a special arrangement) is not considered a standard path. Before building ECL from trunk, I installed: -- GMP 5.0.5 in c:/mingw64 -- Boehm-Wieser GC from CVS trunk (the one that comes with ECL will refuse to build) also in c:/mingw64 Please don't forget to specify --build=x86_64-w64-mingw32 as configure option if you install the compiler that generates 64-bit by default. > > On Sun, Aug 19, 2012 at 11:56 AM, Gabriel Dos Reis > wrote: >> >> * fresh check out of CVS trunk >> * configure option: --build=x86_64-w64-mingw64 > > > Is this really enough? Or do I have to also change the value of CC? that should be enough. That is all I had to do. See my development configuration as detailed above. -- Gaby -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL build failure on 64-bit windows 7 using mingw-w64 toolchain
On Sun, Aug 19, 2012 at 1:44 PM, Juan Jose Garcia-Ripoll wrote: > On Sun, Aug 19, 2012 at 11:56 AM, Gabriel Dos Reis > wrote: >> >> After modifying c/symbols_list.h and c/symbols_list2.h to include >> a definition for :WIN64, > > > I uploaded a fix for this OK. >> the build failed again because >> the function ecl_make_ulong_long was mistyped as >> ecl_make_ulong_Long (note the capital L for the second Long.) >> The same typo appears in c/number.d 3 times. > > > This was corrected in git/CVS some weeks ago. No, it wasn't. Browse to the source code for number.d http://ecls.cvs.sourceforge.net/viewvc/ecls/ecl/src/c/number.d?revision=1.102&view=markup Have a look at lines 308, 326, and 394. > Please make sure you do not > suffer from the same repository problems other reported here. > > In addition to this, I had to fix the aclocal.m4 code that reports the > integer sizes: it printed out a long long number without the %lld macro and > the LL suffix. Once this is done, ecl_min.exe builds, but GMP breaks at some > point while it is loading the bootstrap code. I will investigate this. OK. -- Gaby > > Juanjo > > -- > Instituto de Física Fundamental, CSIC > c/ Serrano, 113b, Madrid 28006 (Spain) > http://juanjose.garciaripoll.googlepages.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL build failure on 64-bit windows 7 using mingw-w64 toolchain
On Sun, Aug 19, 2012 at 2:27 PM, Juan Jose Garcia-Ripoll wrote: > On Sun, Aug 19, 2012 at 9:14 PM, Gabriel Dos Reis > wrote: >> >> No, it wasn't. Browse to the source code for number.d >> >> >> http://ecls.cvs.sourceforge.net/viewvc/ecls/ecl/src/c/number.d?revision=1.102&view=markup >> >> Have a look at lines 308, 326, and 394. > > > Ok, it seems my emacs script did not find those ones. I uploaded a fix. Thanks, -- Gaby -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] ECL build failure on 64-bit windows 7 using mingw-w64 toolchain
On Sun, Aug 19, 2012 at 3:46 PM, Juan Jose Garcia-Ripoll wrote: > On Sun, Aug 19, 2012 at 11:56 AM, Gabriel Dos Reis > wrote: >> >> Unfortunately, it failed to execute properly, apparently for the >> same reasons as 2 years ago. > > > There were not so many things to fix after all: > > * the typo you found > * missing :win64 keyword > * typo in _ecl_big_set_fixnum() > * wrong printf() statements in aclocal.m4 I guessed the crash had to do with the LLP ABI flavour on the 64-bit Windows. However, I was away from imagining the root cause of the last two items on the list. > > With all these, ECL seems to build fine on mingw32. The configuration step > is not the one you showed, but > > ./src/configure --prefix=... --build=x86_86-w64-mingw32 > > One needs to download and build separately the following components: > libatomic_ops (https://github.com/ivmai/libatomic_ops) , boehm-weiser > garbage collector (https://github.com/ivmai/bdwgc), and gmp 5.0.5 (stable > release). > > None of those libraries, as shipped with ECL, build on 64-bits/mingw. > Unfortunately I cannot upgrade them because then other ports would be > broken, and also because the required versions are unstable. libatomic_ops that ships with ECL builds fine for me. I am stuck with CVS on windows machine. [ I do not want msysgit to mess with my gcc setup on my machine. ] Otherwise, ECL seems now to build. I have not tested yet with OpenAxiom. -- Gaby -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
[Ecls-list] ECL performance with respect to OpenAxiom
Hi Juanjo, I've reported, on several occasions, in the past that an ECL-based build of OpenAxiom takes a very long time (usually over 2 or 4 hours.) Well, with current CVS mainline, ECL builds OpenAxiom about 20min on my machine. It could be argued that it is just a better machine, but on the same machine SBCL takes approximately the same time. So, whatever you've done lately, that was great! (Is it because of better IO or GC implementation?) I thought I should report that impressive improvement :-) Now, if only debugging with ECL could be just as pleasant as with SBCL... ;-) -- Gaby -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Meaningful C variable names
is there a prettier name than "gazonk"? :-) -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Meaningful C variable names
On Sat, Dec 8, 2012 at 4:01 AM, Juan Jose Garcia-Ripoll wrote: > On Sat, Dec 8, 2012 at 2:05 AM, Gabriel Dos Reis > wrote: >> >> is there a prettier name than "gazonk"? :-) > > > And it is so old that I bet it dates back to KCL days :-) yes, I suspected so -- GCL also uses gazonk especially for temporary file names too. -- Gaby -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Announce: A new C++ based implementation of Common Lisp based on the ECL CL code
> I have given it a try https://github.com/juanjosegarciaripoll/cl-cxx > > It is indeed not that hard to define wrappers for C++ functions using > templates as they seem to properly dispatch among functions with different > arities. Implicit or explicit conversions are also easy to implement, given > the proper Common Lisp back-end. I just quickly glanced over the code. I noticed that some of the constructs https://github.com/juanjosegarciaripoll/cl-cxx/blob/master/include/cl-cxx/defun.hpp are C++03 ways of emulating lambda-expressions. C++11 has better support for those. -- Gaby -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
Re: [Ecls-list] Mingw users here?
On Wed, Aug 7, 2013 at 1:42 AM, Juan Jose Garcia-Ripoll wrote: > I am _very_ slowly transitioning all my data and processes to the new > Windows computer. Due to the changes in the Windows interface it is much > slower tan I anticipated and found a few surprises. > > One surprise is that GMP does not seem to build at all with the versión of > mingw32 I installed. Is there anybody else here with the same problem? Are you referring to Windows 8? -- Gaby -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
