t-round does, so we're starting from square
> one.)
Note that if I recall correctly, m68k isn't a release critical
architecture for lenny, so although I think it would be good to fix
this, it may not affect guile's inclusion in lenny.
Thanks for the help.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Rob Browning <[EMAIL PROTECTED]> writes:
> "Neil Jerram" <[EMAIL PROTECTED]> writes:
>
>> ia64: is getting illegal instruction in test-unwind
>> i386, m68k, sparc: are unclickable, so I can't tell
>>
>> The ia64 one is fully understood; y
Rob Browning <[EMAIL PROTECTED]> writes:
> This will be in the packages I should be uploading later today.
I've uploaded guile-1.8 1.8.5+1-3. Let me know if there are remaining
issues.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as
u.org/gitweb/?p=guile.git;a=commit;h=78aa4a8850396801f2e5515565d051b45b4f15b5
This will be in the packages I should be uploading later today.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
new upload with both this and the ia64 fix,
> hopefully we'll then have all architectures building.
OK, I'll try to have a new upload within the next few days.
Thanks for the help
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
difference between Building and Built
> statuses?
Hmm, I didn't know either, but here's a description:
http://www.debian.org/devel/buildd/wanna-build-states
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Rob Browning <[EMAIL PROTECTED]> writes:
> This was on my list, but time got away from me. I'll see what I can
> do.
OK, I should be uploading packages that include Neil's two patches
this weekend, if not sooner.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @
gs are still
> allowed, and I believe that all the fixes you need are available in
> Guile's git repository - so please apply and NMU if you can so that
> Guile stays in lenny!
This was on my list, but time got away from me. I'll see what I can
do.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
iscussion about
modularization.
If anyone wants to attempt the modularization, I can look back and try
to summarize my conclusions there as well.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 7
and continue to work with
the SLIB upstream to alter guile.init there as appropriate.
Ideally the 1.8 slib.scm should look like this:
(define-module (ice-9 slib))
(load-from-path "slib/guile.init")
Hope this helps
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @c
uilds from the development branch
of CVS will have version number 1.9.0.
Guile versions with an odd middle number, i.e. 1.5.* are unstable
development versions. Even middle numbers indicate stable versions.
This has been the case since the 1.3.* series.
Please send bug reports to
27;ll be a problem. I'll just coordinate the issue with
the Debian SLIB maintainer and guile-1.8 won't support SLIB until
Guile does upstream.
However, first I'm trying to resolve the popen.test issue being
discussed on guile-devel.
--
Rob Browning
rlb @defaultvalue.org and @debia
icular is there some specific bit of the C code
that you're concerned about?
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
___
Guile-
SLIB is handled within Guile.
If I don't come up with a solution soon, I can just upload 1.8
packages without SLIB support.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
__
ber, i.e. 1.5.* are unstable
development versions. Even middle numbers indicate stable versions.
This has been the case since the 1.3.* series.
Please send bug reports to [EMAIL PROTECTED]
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 43
oposing that we use a symlink, just observing that it seemed to work
(after minor patches to guile.init).
Also, for anyone interested, we're discussing the SLIB issue further
in a thread on guile-devel.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG st
the
> load insidde the module definition of (ice-9 slib) seems fine.
In fact, if you adjust guile.init to not suppress the define-module
statement under guile 1.6, even symlinking ice-9/slib.scm to the
current guile.init seems to work fine, as does a simple
load-from-path.
--
Rob Browning
rlb @
vial test, ignoring ice-9/slib.scm
and using the slib guile.init directly seems to work.
So do we have any known arguments against just using slib's guile.init
and submitting fixes upstream?
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11
interested in changes that might make our
integration/maintenance easier, presuming we can figure out what that
might entail?
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432
Neil Jerram <[EMAIL PROTECTED]> writes:
> The two developers who have thought most on this subject in the past
> are Marius (Vollmer) and Rob (Browning), and they've both been out of
> circulation for the last week or so. No doubt one of them will
> respond when they cat
then pass it to an
implementation of `free' that doesn't know what book keeping the
allocator used.
You must not modify any of their values after calling any libltdl
function other than `lt_dlpreopen_default' or the macro
`LTDL_SET_PRELOADED_SYMBOLS&
(low-level))
(load-extension "libguile-foo-v-1" "scm_init_foo_low_level")
(export baz)
...
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
__
er libraries, or anything else that has been set up by code
executed from guile.
I was concerned that there may be trouble unless there's some way of
enumerating all of these things and undoing them, and that seems like
it might be difficult in the general case.
--
Rob Browning
rlb @defau
re-dlopen the lib that depends on libguile and start using it?
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
___
Guile-user mailing list
ent what we need and can change it at will, of course.
Unless there's a strong case, I don't think we should export it. We
can always be convinced to export it later, but it's much more
difficult to "unexport" something.
--
Rob Browning
rlb @defaultvalue.org and @debian
doing this just yet.
I haven't considered it carefully yet, but if fold's only supposed to
take a procedure for kons, then why not just add a check-arg-type
procedure? call for kons?
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03
26 matches
Mail list logo
