Sourceforge has discontinued temporarily or definitively the use of CVS.
Seems their goal is to enforce use of SCM for security reasons. In any case,
while they make up their minds, they have switched off all access for now 5
days. We can not afford to remain off-line, specially in view of the numb
2011/2/2 crox
> 02.02.2011, 19:13, "Juan Jose Garcia-Ripoll" <
> juanjose.garciarip...@googlemail.com>:
> > ECL does have weak pointers and that could be used to implement weak hash
> tables, but it has not been done.
> Sounds solvable... As far as I can see weak pointers are not documented
> yet
02.02.2011, 19:13, "Juan Jose Garcia-Ripoll"
:
> ECL does have weak pointers and that could be used to implement weak hash
> tables, but it has not been done.
Sounds solvable... As far as I can see weak pointers are not documented yet?
> However, in many cases those dependencies can be worked ar
ECL does have weak pointers and that could be used to implement weak hash
tables, but it has not been done.
And regarding what I said, note the difference between libraries that work
on other implementations and libraries that do not support ECL because they
demand nonstandard implementations -- t
My code always use a
(eval-when
(proclaim '(...)))
should have posted this :-)
Anyhow could serve as a workaround for the declaim
On Wed, Feb 2, 2011 at 9:34 AM, Juan Jose Garcia-Ripoll
wrote:
> On Tue, Feb 1, 2011 at 9:21 PM, Karsten Poeck
> wrote:
>>
>> I think you need a:
>> (eval-when
>>
On Wed, Feb 2, 2011 at 10:37 AM, crox wrote:
> Thanks, I'll try it. But what about the second problem (weak hash tables), is
> it solvable?
>
I don't know.
If ECL have support for it, it shouldn't be too hard to port
trivial-garbage to use it.
--
02.02.2011, 12:11, "Marko Kocić" :
> I forgot to add that you need to put either :x86 or :x86-64 to
> *features* and rebuild CFFI, since cl-gtk2 is trying to infer
> architectyre by using cffi-feature-p function which expects one of
> these features to be preseent.
>
> Regards,
> Marko
Thanks, I'l
I forgot to add that you need to put either :x86 or :x86-64 to
*features* and rebuild CFFI, since cl-gtk2 is trying to infer
architectyre by using cffi-feature-p function which expects one of
these features to be preseent.
Regards,
Marko
On Wed, Feb 2, 2011 at 9:48 AM, Marko Kocić wrote:
> I was
You have to compile ECL with threads enabled. Just pass
--enable-threads to ./configure script when bulding ECL.
On Wed, Feb 2, 2011 at 9:55 AM, crox wrote:
> Thanks, Marko!
>
>> Second problem is that trivial-garbage, which is cl-gtk2 dependency at
>> some point reports that ECL does not report
Thanks, Marko!
> Second problem is that trivial-garbage, which is cl-gtk2 dependency at
> some point reports that ECL does not report weak hash tables.
Is it a very difficlut task to port weak hash tables?
And what about Threading (via Bordeaux-Threads) that is an another requirement
for cl-gtk2
> All libraries that work with other lisps *should* work with ECL. Any
> deviation from that behavior should be reported as a bug.
Well, cl-gtk2, for example, requires `bordeaux-threads' that, as I can see,
doesn't work in ecl. Am I right?
---
I was looking at cl-gtk2 yesterday, and it doesn't work with ECL (yet).
First problem was non-conformant loop macro used in one place. That is
an easy fix,
Second problem is that trivial-garbage, which is cl-gtk2 dependency at
some point reports that ECL does not report weak hash tables.
Regards
On Tue, Feb 1, 2011 at 9:21 PM, Karsten Poeck wrote:
> I think you need a:
> (eval-when
>(:compile-toplevel :execute :load-toplevel)
> ..)
>
> around the declaim
>
I would say DECLAIM must have compile time side effects. I take note and
investigate this possible bug.
Juanjo
--
Instituto de
On Tue, Feb 1, 2011 at 9:15 PM, crox wrote:
> Hello list!
> Please tell me, what gui libraries are known to be compatible with ecl
> (except EQL, obviously).
> In particular I'm interested in cl-gtk2.
All libraries that work with other lisps *should* work with ECL. Any
deviation from that behav
14 matches
Mail list logo
