headers
David_Creelman | 3 Jan 2007 23:12
Picon

Small fix for cygwin

Hi,
I don't know if this is a final solution (and I don't know if cygwin is
being supported anymore), but on Cygwin, when

#if defined(cygwin)

is removed from ecl.h, everything compiles and runs (with limited user
testing) correctly.
The earlier problems may have been to do with earlier versions of gcc/libs
on cygwin.

Regards
David

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 1 comment |
headers
Dennis Heuer | 4 Jan 2007 15:19

creating standalone executables?

Hello, am new here. I already tried the -compile option and starting
the binary object with 'ecl -shell' worked fine. However, I remember
reading something about standalone executables. How can I create one?

Regards,
Dennis Heuer

P.s.: What about following the common style for parameters and putting
'--' before named parameters?

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 2 comments |
headers
Juan Jose Garcia-Ripoll | 4 Jan 2007 15:50
Picon

Fwd: Re: creating standalone executables?

2007/1/4, Dennis Heuer <dh@...>:
> Hello, am new here. I already tried the -compile option and starting
> the binary object with 'ecl -shell' worked fine. However, I remember
> reading something about standalone executables. How can I create one?

This one I can answer quickly:
http://ecls.sourceforge.net/new-manual/ch18.html
Back to the mine!

Juanjo

--
Dpto. de Fisica Teorica I, Fac. de CC Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 2804 (Spain)
http://teorica.fis.ucm.es/~jjgarcia/

--

-- 
Dpto. de Fisica Teorica I, Fac. de CC Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 2804 (Spain)
http://teorica.fis.ucm.es/~jjgarcia/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 1 comment |
headers
Erik Huelsmann | 4 Jan 2007 22:14
Picon
Gravatar

Fwd: [ANNOUNCE] usocket 0.2.2

I tried to send the announcement below, but got refused as a non-subscriber.

I also want to take the opportunity to report a problem I have with
ECL: when running the RT tests which come with usocket, a number of
tests return a list with all values returned by the forms in the progn
of the test, while other lisp implementations only return the last
value in the progn.

The problem can be found by checking out the usocket code from its
Subversion repository. The only tests failing are the ones which
exhibit this problem. Looking at the content of the list, the tests
would normally (without this bug) have succeeded though.

The RT version I used is the one I got with SBCL, I think. Anyway it
is unpatched and *not* the one in the ecl repository.

I hope you can help, so we can fix the test failures and give users
the right confidence level in both ECL and usocket.

bye,

Erik.

---------- Forwarded message ----------
From: Erik Huelsmann <ehuels@...>
Date: Jan 3, 2007 11:31 PM
Subject: [ANNOUNCE] usocket 0.2.2
To: usocket-devel@...
Cc: ecls-list@...
(Continue reading)

Permalink | Reply | 8 comments |
headers
Juan Jose Garcia-Ripoll | 5 Jan 2007 19:46
Picon

Re: A few pathname bugs

2006/12/31, Richard M Kreuter <kreuter@...>:
> Hi,

Hi, and first of all sorry for the delay (I do not have much free time
in my new job) and hope that my answer below satisfies you.

> (1) common case translation doesn't seem to get applied to strings in
>     directory components:

First bug. The directory list was actually translated, but due to a
typo, it got discarded.

> (2) Pathnames with a directory starting with :relative :back don't
>     seem to be constructable: (these are occasionally useful for
>     merging):
> (3) Pathnames with a directory containing a :back component anywhere
>     else get constructed strangely

There was a missing "else" in the C code. :BACK now works as expected.
I added several tests in the test suite for that (bugs/cl-001.lsp)

> (4) enough-namestring doesn't seem to do anything:
> > (enough-namestring #P"/abc/def" #P"/abc/")
> "/abc/def"

There was a bug when interpreting the output of the lisp function
MISMATCH. When the directories were completely equal, no
simplification occurred, which is wrong. I fixed this and added more
tests.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Juan Jose Garcia-Ripoll | 5 Jan 2007 19:48
Picon

Re: Small fix for cygwin

2007/1/3, David_Creelman@... <David_Creelman@...>:
> Hi,
> I don't know if this is a final solution (and I don't know if cygwin is
> being supported anymore), but on Cygwin, when
>
> #if defined(cygwin)

Do you mean line 20 of current ECL? It says
#if !defined(cygwin) && !defined(_MSVC_VER)
Does it mean I can delete it? If you say so, I will trust you and do
it. As I said in previous messages, I have not succeeded in installing
cygwin on my windows box.

Juanjo
--

-- 
Dpto. de Fisica Teorica I, Fac. de CC Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 2804 (Spain)
http://teorica.fis.ucm.es/~jjgarcia/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 0 comments |
headers
Juan Jose Garcia-Ripoll | 5 Jan 2007 20:00
Picon

Re: C-INLINE and LET bindings

2006/12/30, Marco Gidde <marco.gidde@...>:
> while playing around with ECL and CFFI I got a strange compiler error
> that did not occur with e.g. SBCL. I was able to strip it down to the
> following code: [...]
> Both functions are the same except for the superfluous LET in
> C-MALLOC-2. The problem is that the first form compiles while the
> second doesn't. The error message is
>
> > ;;; Compiling ecl.lsp.
> > ;;; Compiling (DEFUN C-MALLOC-2 ...).
> > Not a condition type: C::FOREIGN-DATA
> > No restarts available.
> > Broken at MAKE-CONDITION.

This was an typo in the type-inference code from the compiler. Instead
of the lisp type SI::FOREIGN-DATA, there appeared just FOREIGN-DATA.
Type inference was only activated by the LET form because it had to
analize whether the let-variable could be replaced by just the inline
form.

Fixed in CVS.

Regards,

Juanjo

--

-- 
Dpto. de Fisica Teorica I, Fac. de CC Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 2804 (Spain)
http://teorica.fis.ucm.es/~jjgarcia/
(Continue reading)

Permalink | Reply | 501 comments |
headers
Juan Jose Garcia-Ripoll | 5 Jan 2007 20:23
Picon

Re: Fwd: [ANNOUNCE] usocket 0.2.2

2007/1/4, Erik Huelsmann <ehuels@...>:
> I tried to send the announcement below, but got refused as a non-subscriber.

Yes, the list is set so as to prevent spam.

> I also want to take the opportunity to report a problem I have with
> ECL: when running the RT tests which come with usocket, a number of
> tests return a list with all values returned by the forms in the progn
> of the test, while other lisp implementations only return the last
> value in the progn. [...]
> The problem can be found by checking out the usocket code from its
> Subversion repository. The only tests failing are the ones which
> exhibit this problem. Looking at the content of the list, the tests
> would normally (without this bug) have succeeded though.
> The RT version I used is the one I got with SBCL, I think. Anyway it
> is unpatched and *not* the one in the ecl repository.

First of all let me tell you that, within my limited time and
possibilities, I am open to helping people port any kind of libraries
to ECL and I am happy to fix any problem.

Now, as for usocket, I checked it out and, apart from the fact that
you were not using the rt from SBCL but the one from b9, your library
does not work for me. Tests do not even run because of this in
test-usocket.lisp

(defparameter *soc1* (usocket::make-socket :socket :my-socket
                                           :stream :my-stream))

where make-socket is defined in usocket.lisp as a function taking only
(Continue reading)

Permalink | Reply | 7 comments |
headers
Erik Huelsmann | 5 Jan 2007 23:21
Picon
Gravatar

Re: Fwd: [ANNOUNCE] usocket 0.2.2

On 1/5/07, Juan Jose Garcia-Ripoll <jjgarcia@...> wrote:
>
> > I also want to take the opportunity to report a problem I have with
> > ECL: when running the RT tests which come with usocket, a number of
> > tests return a list with all values returned by the forms in the progn
> > of the test, while other lisp implementations only return the last
> > value in the progn. [...]
> > The problem can be found by checking out the usocket code from its
> > Subversion repository. The only tests failing are the ones which
> > exhibit this problem. Looking at the content of the list, the tests
> > would normally (without this bug) have succeeded though.
> > The RT version I used is the one I got with SBCL, I think. Anyway it
> > is unpatched and *not* the one in the ecl repository.
>
> First of all let me tell you that, within my limited time and
> possibilities, I am open to helping people port any kind of libraries
> to ECL and I am happy to fix any problem.

Thanks. I want to do all the work myself when possible, but I don't
think *if* the problem is on the ECL side, I won't be able to.

> Now, as for usocket, I checked it out and, apart from the fact that
> you were not using the rt from SBCL but the one from b9, your library
> does not work for me. Tests do not even run because of this in
> test-usocket.lisp
>
> (defparameter *soc1* (usocket::make-socket :socket :my-socket
>                                            :stream :my-stream))
>
> where make-socket is defined in usocket.lisp as a function taking only
(Continue reading)

Permalink | Reply | 6 comments |
headers
Juan Jose Garcia-Ripoll | 5 Jan 2007 23:37
Picon

Re: Fwd: [ANNOUNCE] usocket 0.2.2

2007/1/5, Erik Huelsmann <ehuels@...>:
> On 1/5/07, Juan Jose Garcia-Ripoll
<jjgarcia@...> wrote:
> > Now, as for usocket, I checked it out and, apart from the fact that
> > you were not using the rt from SBCL but the one from b9, your library
> > does not work for me. Tests do not even run because of this in
> > test-usocket.lisp
> >
> > (defparameter *soc1* (usocket::make-socket :socket :my-socket
> >                                            :stream :my-stream))
> >
> > where make-socket is defined in usocket.lisp as a function taking only
> > one keword argument, :socket
>
> Ok. Did you try 0.2.2 or trunk? I ran tests with trunk and - possibly
> falsely - assumed you would try trunk too. From what you tell me, I
> start to think you may have tried the 0.2.x branch, 0.2.2 tag or the
> asdf installable tar.gz.

I prefer to use cvs trees rather than tarballs because otherwise I
cannot easily revert the sources or make patches. However, I did not
apply any tags -- I do not know how to use subversion, just applied
the line you wrote on the usocket page
http://common-lisp.net/project/usocket/ I will investigate other
possibilites as time permits.

Juanjo

--

-- 
Dpto. de Fisica Teorica I, Fac. de CC Fisicas, Universidad Complutense,
(Continue reading)

Permalink | Reply | 5 comments |

Gmane