headers
Andrew Topp | 1 Jul 2003 01:37
Picon

Re: Cute screenshot of a ECL prompt


Erik Winkels wrote:
|
| I'm not using the ECL top-level, at least I think so, but I could just
| be confusing terminology here.  I just get the input from the Quake2
| console which is always a string, do a c_string_to_object() on that
| and feed the result to si_safe_eval().  Then I print the result of the
| eval back to the console.
|

Ahh :). This is what I was doing initially, but to get debugging
working, I used CLOS streams masquerading as standard input and output
to the default top level, so the debugging prompt was accessable.
throw/catch was used to break out of the toplevel loop. There were some
issues that seemed to leave ECL in invalid states after an error
occurred. The debugger was never properly accessible.

I was going to try some other things, but got sidetracked with other
issues, and eventually UC was put on ice. I think I had been planning to
save the traceback and other information, and write a postmortem debugger.

|
| It's all still very basic and was mainly a quick hack to see how easy
| it would be to communicate with ECL.
|
| So I don't have debugging going either :) (I had Quake2 crashing on me
| whenever I entered an invalid Lisp form until Juanjo pointed me to
| si_safe_eval() instead of cl_eval() which I was using uptil that
| point.)
|
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juan Jose Garcia-Ripoll | 1 Jul 2003 11:17
Picon

Re: unnecessary (?) glibc dependencies

On Monday 30 June 2003 22:49, Edi Weitz wrote:
> Hi!
>
> I'm writing a Lisp application for a customer of mine and he wants
> "binaries". As he needs them for Linux and Solaris and I only have a
> LW license for Linux I decided to give ECL a try for this project. It
> looks like ECL's ANSI support is good enough for my program, [...]

I still have to finish the port for Solaris: static linking works on my 
private source tree and I will commit the changes this week; loading of 
shared libraries still has to wait, because of some problems with the BW 
garbage collector.

> Is there an easy way to develop and build binaries on my laptop that I
> can execute with older glibc versions? It seems to be the case (at
> least for this simple program) that the dependency on the glibc
> version isn't really necessary.

I don't know where this dependency comes from :-/ I suppose that glibc 2.2.* 
and 2.1.* are binary incompatible and the system therefore complains. Lacking 
a better solution, I would recommend building a statically linked image:

LDFLAGS="-static" ../src/configure --prefix=$HOME --disable-shared 
--enable-local-gmp

The flags "-static" and "--disable-shared" are like virus and will propagate 
to the programs you build with this image. Notice also, that the image 
created by this process is far too large, as it contains the compiler: you 
should use BUILD-PROGRAM to build your own customized application. But you 
already know this, probably.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Edi Weitz | 1 Jul 2003 11:29
Picon
Favicon

Re: unnecessary (?) glibc dependencies

Juan Jose Garcia-Ripoll <worm@...> writes:

> I still have to finish the port for Solaris: static linking works on
> my private source tree and I will commit the changes this week;
> loading of shared libraries still has to wait, because of some
> problems with the BW garbage collector.

Ooops! That does mean 0.9 doesn't work for Solaris? Good to know. But
I take it that I should grab the nightly CVS tarball next week and try
this one, right?

> I don't know where this dependency comes from :-/ I suppose that
> glibc 2.2.* and 2.1.* are binary incompatible and the system
> therefore complains. Lacking a better solution, I would recommend
> building a statically linked image:
> 
> LDFLAGS="-static" ../src/configure --prefix=$HOME --disable-shared 
> --enable-local-gmp
> 
> The flags "-static" and "--disable-shared" are like virus and will
> propagate to the programs you build with this image. Notice also,
> that the image created by this process is far too large, as it
> contains the compiler: you should use BUILD-PROGRAM to build your
> own customized application. But you already know this, probably.

Does that mean I should already build ECL itself with these flags?
I'll try that.

I don't mind if the image I work with is large as long as the binaries
built with BUILD-PROGRAM aren't dozens of megabytes big.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Pearson | 1 Jul 2003 11:57

Doing a :pop instead of an :exit when EOF given in "sub-prompts"

Is it possible to configure ecl's repl so that, when you hit EOF, while
you're in a "sub-prompt" (sorry, I don't know the correct term, I'm talking
of the type of prompt you get when you've encountered an error), it does a
:pop instead of an :exit?

Talking of prompts, I also note from top.lsp that there doesn't seem to be
an easy method of providing your own prompt function. I note that there is a
si::*prompt-hook* but you still get the normal prompt output after that has
been called and, on top of this, I found that if I set si:*prompt-hook* from
within my ~/.eclrc the value seems to have disappeared once the top level
starts up.

--

-- 
Dave Pearson
http://www.davep.org/lisp/

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
Permalink | Reply | 1 comment |
headers
Dave Pearson | 1 Jul 2003 13:39

Re: Doing a :pop instead of an :exit when EOF given in "sub-prompts"

* Dave Pearson <davep@...> [2003-07-01 10:57:44 +0100]:

> Talking of prompts, I also note from top.lsp that there doesn't seem to be
> an easy method of providing your own prompt function. I note that there is
> a si::*prompt-hook* but you still get the normal prompt output after that
> has been called and, on top of this, I found that if I set
> si:*prompt-hook* from within my ~/.eclrc the value seems to have
> disappeared once the top level starts up.

Sorry, typo in the above: s/prompt-hook/tpl-prompt-hook/.

--

-- 
Dave Pearson
http://www.davep.org/

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
Permalink | Reply | 0 comments |
headers
Juan Jose Garcia-Ripoll | 1 Jul 2003 13:50
Picon

Re: unnecessary (?) glibc dependencies

On Tuesday 01 July 2003 11:29, Edi Weitz wrote:
> Ooops! That does mean 0.9 doesn't work for Solaris? Good to know. But
> I take it that I should grab the nightly CVS tarball next week and try
> this one, right?

No, 0.9 did not work for Solaris; 0.9b will. I had to solve several problems: 
missing functions (setenv), different integer type names (u_int8_t -> 
uint8_t), and some other tweaks. However, this port revealed one memory leak 
in "dpp", and I am glad to see that the source code of ECL slowly converges 
to something really portable. You will have to wait, though, until I announce 
the port, because I still have to make sure that I did not break anything in 
the other supported platforms.

> > I don't know where this dependency comes from :-/ I suppose that
> > glibc 2.2.* and 2.1.* are binary incompatible and the system
> > therefore complains. Lacking a better solution, I would recommend
> > building a statically linked image:
> >
> > LDFLAGS="-static" ../src/configure --prefix=$HOME --disable-shared
> > --enable-local-gmp
>
> Does that mean I should already build ECL itself with these flags?
> I'll try that.

Yes. --disable-shared tells ECL that it should not produce dynamically linked 
libraries for lisp code; the LDFLAG="-static" ensures that all other 
libraries (i.e. non-lisp) are statically linked in the program.

> I don't mind if the image I work with is large as long as the binaries
> built with BUILD-PROGRAM aren't dozens of megabytes big.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juan Jose Garcia-Ripoll | 1 Jul 2003 15:14
Picon

Solaris/SPARC port

Hi,

I am proud to announce that ECL now compiles and runs under Solaris/SPARC. 
Finally the environment works not only in statically linked mode, but also 
allows compiling and loading lisp code in the form of dynamically linked 
libraries.

The changes have been uploaded to CVS. People with anonymous CVS access will 
get access to the latest sources about tomorrow --- you know, SourceForge has 
a strange policy regarding CVS these days ---. However, I remind you that my 
computer creates regularly a patch file that can be applied to the latest 
release (i.e. 0.9) and contains all of the latest changes

	http://ecls.sf.net/patch-0.9-current.gz

I am looking for volunteers that take the task of maintaining other ports: 
FreeBSD, NetBSD, Cygwin, etc. The amount of work is now minimal, as it will 
be porting to other 32-bit environments (Solaris/Intel???, Linux/ARM, ...).

Best regards

	Juanjo

bash-2.03$ hostname
usf-cf-sparc-solaris-2
bash-2.03$ ecl
ECL (Embeddable Common-Lisp) 0.9
Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
Copyright (C) 1993 Giuseppe Attardi
Copyright (C) 2000 Juan J. Garcia-Ripoll
(Continue reading)

Permalink | Reply | 501 comments |
headers
Julian St. | 1 Jul 2003 18:07
Picon

Re: Solaris/SPARC port

On Tue, 1 Jul 2003 15:14:50 +0200
Juan Jose Garcia-Ripoll <worm@...> wrote:

> Hi,
> 
> I am looking for volunteers that take the task of maintaining other ports: 
> FreeBSD, NetBSD, Cygwin, etc. The amount of work is now minimal, as it will 
> be porting to other 32-bit environments (Solaris/Intel???, Linux/ARM, ...).

I am currently running ECL on FreeBSD without problems, I will cry if it breaks *g*, but I do not think that I am
able to properly maintain it due to the lack of familarity with the ECL code base. I am willing to take some
responsibility, though.

Regards,
Julian
--

-- 
	       Member of the Guild of Tagline Thieves.

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
Permalink | Reply | 501 comments |
headers
Juan Jose Garcia-Ripoll | 2 Jul 2003 10:47
Picon

Re: Solaris/SPARC port

On Wednesday 02 July 2003 02:00, Edi Weitz wrote:
> Juan Jose Garcia-Ripoll <worm@...> writes:
> > 	http://ecls.sf.net/patch-0.9-current.gz
>
> This doesn't seem to be a patch against the released 0.9 sources which
> can be downloaded from SF. My sources don't have src/CHANGELOG,
> src/ansi-tests/format.lisp, src/tests/format.tst, and
> src/tests/tests.lsp.

My fault. I made the patch against a directory with the 0.9 release and _all_ 
files (tests included). I have made a new patch file and tested it against 
the official tarball of the 0.9 release.

Juanjo

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
Permalink | Reply | 0 comments |
headers
Juan Jose Garcia-Ripoll | 2 Jul 2003 15:57
Picon

Re: Solaris/SPARC port

On Tuesday 01 July 2003 18:07, Julian St. wrote:
> I am currently running ECL on FreeBSD without problems, I will cry if it
> breaks *g*, but I do not think that I am able to properly maintain it due
> to the lack of familarity with the ECL code base. I am willing to take some
> responsibility, though.

Thanks. That should be enough. Normally the changes that will break other 
platforms are very easy to spot (for instance, if I decide to use a header 
<inttypes.h> instead of <sys/types.h>, etc). The problem is that SourceForge 
has dropped many platforms from their Compiler Farm -- and FreeBSD is among 
them.

Best regards,

Juanjo

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
Permalink | Reply | 0 comments |

Gmane