On Thu, 2013-02-14 at 18:21 +1100, William ML Leslie wrote:
> On 13 February 2013 05:24, Mark H Weaver wrote:
> > Okay, but here I'm using "Static FFI" to mean something very different
> > than the C API: I'm talking about a pure scheme-based API that would be
> > quite similar to the API our curr
On 13 February 2013 05:24, Mark H Weaver wrote:
> Okay, but here I'm using "Static FFI" to mean something very different
> than the C API: I'm talking about a pure scheme-based API that would be
> quite similar to the API our current dynamic FFI, except that a lot of
> the work would be done at co
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver skribis:
>>
>>> At some point, it might make sense to create a more static FFI that
>>> works more like a C compiler does, splitting the job into compile-time
>>> and run-time phases. This static FFI would be str
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> At some point, it might make sense to create a more static FFI that
>> works more like a C compiler does, splitting the job into compile-time
>> and run-time phases. This static FFI would be strictly less powerful
>> than the d
Mark H Weaver skribis:
> It seems to me that the dynamic FFI performs, at run time, the same jobs
> that a C compiler performs at compile time. If at some point we add
> support for accessing preprocessor macros and type definitions (which
> seems important), then we'll need the header files as
Greg Troxel writes:
> This .so=>devel does not make sense to me. I thought the point was
> that -devel split things that people who wanted to compile against the
> package needed, but not things needed to run.
It seems to me that the dynamic FFI performs, at run time, the same jobs
that a C com
On 12 February 2013 12:20, Nala Ginrut wrote:
> Put that link .so in guile rather than guile-devel is the exception I
> mentioned. The regular packaging policy not allow it.
>
[Again, referring only to Debian.]
Right. This applies only to libguilereadline-v-18.so, not
libguile-2.0.so. I had ov
在 2013-2-12 AM10:10，"Daniel Hartwig" 写道：
>
> On 11 February 2013 23:23, Greg Troxel wrote:
> > (First, "all mainstream distros" is only talking about Linux.)
> >
> > This .so=>devel does not make sense to me. I thought the point was
> > that -devel split things that people who wanted to compile
On 11 February 2013 23:23, Greg Troxel wrote:
> (First, "all mainstream distros" is only talking about Linux.)
>
> This .so=>devel does not make sense to me. I thought the point was
> that -devel split things that people who wanted to compile against the
> package needed, but not things needed t
Nala Ginrut writes:
> On Sat, 2013-02-09 at 16:12 +0100, Ludovic Courtès wrote:
>>
>> Daniel Hartwig skribis:
>> An issue with the FFI is distros where .la and .so files are only
>> available in the -dev package, because then ‘dynamic-link’ won’t work
>> unless that -dev package is installed (
Mike Gran skribis:
> Right now, the Guile project does a poor job of testing Guile on
> multiple platforms. Hydra does check that i686-linux, x86_64-linux
> and x86_64-darwin compile, but, that's about the extent of multi-platform
> testing. (There are Hydra jobs for Cygwin and Solaris, but, th
> I have the feeling that we should implement our own dynamic-link
> function without libltdl. It would eliminate a dependency and allow us
> to use other search path rules, like ones that could deal with this
> case. I think the situation would actually be better on other
> architectures because
On Sat, 2013-02-09 at 16:12 +0100, Ludovic Courtès wrote:
> Hi,
>
> Daniel Hartwig skribis:
>
> > By the way, I very much like the conventions used in the GnuTLS
> > bindings. The enums in particular make a lot of sense for a security
> > library, with the extreme type safety they provide. I w
() Andy Wingo
() Mon, 11 Feb 2013 09:20:55 +0100
- Coordination cost (working with upstream on bugs/features)
For ltdl, my instinct is "no".
Just MHO :)
I imagine no one likes to hear the curmudgeon spew, but i feel it is my
duty (to GNU, Guile, and my fellow programmers) to trot ou
Howdy,
On Sat 09 Feb 2013 18:50, Mark H Weaver writes:
> Andy Wingo writes:
>
>> I have the feeling that we should implement our own FOO function
>> without libBAR.
>
> Wouldn't it be better to fix these problems in libBAR, to the benefit
> of all its users, than for each of its users to duplic
Mark H Weaver skribis:
> Andy Wingo writes:
>
>> On Sat 09 Feb 2013 16:12, l...@gnu.org (Ludovic Courtès) writes:
>>
>>> An issue with the FFI is distros where .la and .so files are only
>>> available in the -dev package, because then ‘dynamic-link’ won’t work
>>> unless that -dev package is ins
Mark,
I agree with everything you said about dependencies. I think the real
solution is something like what you said - sharing code, but bundling.
One way to push that farther would be to distribute tarballs that include
the complete source of some libraries, and somehow making a combined build
s
Hi Andy,
Andy Wingo writes:
> On Sat 09 Feb 2013 16:12, l...@gnu.org (Ludovic Courtès) writes:
>
>> An issue with the FFI is distros where .la and .so files are only
>> available in the -dev package, because then ‘dynamic-link’ won’t work
>> unless that -dev package is installed (as recently dis
On Sat 09 Feb 2013 16:12, l...@gnu.org (Ludovic Courtès) writes:
> An issue with the FFI is distros where .la and .so files are only
> available in the -dev package, because then ‘dynamic-link’ won’t work
> unless that -dev package is installed (as recently discussed on
> guile-user.)
I have the
Hi,
Daniel Hartwig skribis:
> By the way, I very much like the conventions used in the GnuTLS
> bindings. The enums in particular make a lot of sense for a security
> library, with the extreme type safety they provide. I will pursue a
> similar approach.
Yeah, I think it’s helpful.
> One que
On 9 February 2013 00:21, Ludovic Courtès wrote:
>
> Yeah, apparently there are several half-baked bindings around. Let’s
> just polish one of them, and submit it for inclusion in libgcrypt.
I have already submitted some additions to one, but I may just continue
in a new repository.
By the way,
Daniel Hartwig skribis:
> On 5 February 2013 23:48, Ludovic Courtès wrote:
>>> The gcrypt-guile project is doing so, I'll help it if I can.
>>> But my original thought is orthogonal with gcrypt-guile, just put some
>>> common digest algorithm in libguile rather than a full-stack crypto-lib.
>>
>
hi Noah!
On Mon, 2013-02-04 at 21:57 -0500, Noah Lavine wrote:
> Hello,
>
>
> I was just thinking about this, and I was wondering, can you hash an
> arbitrary Guile object? And if so, what do you hash? (I mean,
> algorithms like SHA-1 are defined on sequences of bits, as I
> understand it. So wh
On 6 February 2013 12:18, Daniel Hartwig wrote:
> Avoiding duplication and feature creep /in the core/ is highly
> desirable. Guildhall makes it convenient enough to pull in additional
> features; guile-lib has md5 and industria provides also sha and
> others.
During yesterday's IRC discussion t
On 5 February 2013 23:48, Ludovic Courtès wrote:
>> The gcrypt-guile project is doing so, I'll help it if I can.
>> But my original thought is orthogonal with gcrypt-guile, just put some
>> common digest algorithm in libguile rather than a full-stack crypto-lib.
>
> We could actually use the Gnuli
Nala Ginrut skribis:
> On Tue, 2013-02-05 at 00:03 +0100, Ludovic Courtès wrote:
[...]
>> We probably don’t want Guile to depend on libgcrypt.
>>
>
> No, I didn't mean to use libgcrypt directly, I just suggested reuse part
> of libgcrypt code(only the common digest algorithm) and make wrapper,
Hello,
I was just thinking about this, and I was wondering, can you hash an
arbitrary Guile object? And if so, what do you hash? (I mean, algorithms
like SHA-1 are defined on sequences of bits, as I understand it. So what
collection of bits do you hash?) And is the hash recursive? (I.e. is it an
e
On Tue, 2013-02-05 at 00:03 +0100, Ludovic Courtès wrote:
> Nala Ginrut skribis:
>
> > As mentioned in another thread about digest algorithm support in Guile,
> > my plan is use part of implementation of libgcrypt and make a wrapper,
> > then put into libguile.
>
> We probably don’t want Guile t
Nala Ginrut skribis:
> As mentioned in another thread about digest algorithm support in Guile,
> my plan is use part of implementation of libgcrypt and make a wrapper,
> then put into libguile.
We probably don’t want Guile to depend on libgcrypt.
So, instead, I’d suggest choosing the best of th
On Mon, 2013-02-04 at 11:35 +0800, Daniel Hartwig wrote:
> On 4 February 2013 11:12, Nala Ginrut wrote:
> >> If your goal is only to provide crypto. support to Guile programs,
> >> then time is better spent providing a wrapper to the existing library.
> >> Concerns about adding an external depend
On 4 February 2013 11:12, Nala Ginrut wrote:
>> If your goal is only to provide crypto. support to Guile programs,
>> then time is better spent providing a wrapper to the existing library.
>> Concerns about adding an external dependency do not hold much weight
>> next to the advantages of directl
On Mon, 2013-02-04 at 09:14 +0800, Daniel Hartwig wrote:
> Hello
>
> On 3 February 2013 20:55, Nala Ginrut wrote:
> > As mentioned in another thread about digest algorithm support in Guile,
> > my plan is use part of implementation of libgcrypt and make a wrapper,
> > then put into libguile.
> >
Hello
On 3 February 2013 20:55, Nala Ginrut wrote:
> As mentioned in another thread about digest algorithm support in Guile,
> my plan is use part of implementation of libgcrypt and make a wrapper,
> then put into libguile.
> But now I found weinholt's Scheme industria lib, which contains all
> m
() Nala Ginrut
() Sun, 03 Feb 2013 20:55:46 +0800
Would you prefer C implementation or Scheme way?
The less C the better, generally, IMHO.
--
Thien-Thi Nguyen . GPG key: 4C807502
. NB: ttn at glug dot org is not me .
.
As mentioned in another thread about digest algorithm support in Guile,
my plan is use part of implementation of libgcrypt and make a wrapper,
then put into libguile.
But now I found weinholt's Scheme industria lib, which contains all
mainstream crypto(not only digest) algorithm.
http://weinholt.se
35 matches
Mail list logo
