7; refer to and rely on it being bound to the
> RTD.
Ahh, right.
So I suppose if you want as the goops name, then you really do
just have to choose something other than foo for the constructor within
the module.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-
broken on 32-bit architectures:
https://buildd.debian.org/guile-3.0
So if that's what you have, you may need to stick with 3.0.9 for now. I
plan to downgrade debian/unstable to 3.0.9 this weekend.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1F
so you
wouldn't want to include the Debian revision unless the format of
PACKAGE_VERSION isn't very rigid.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7)
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Neil Jerram writes:
> I'm afraid I can't help in detail with those other ones, as I don't have
> those systems.
I should note that if anyone does come up with ideas or patches that
they'd like to try, I can test them.
Thanks
--
Rob Browning
rlb @defaultvalue.org and
x27;ll first
need an updated libgc in Debian unstable?
If so, I'll probably hold off on the guile patch for now.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
org/status/fetch.php?pkg=guile-2.0&arch=s390&ver=2.0.3%2B1-2&stamp=1322025002
Anything else I might try?
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Neil Jerram writes:
> Rob Browning writes:
>> So do I understand correctly that in order for this to work, we'll first
>> need an updated libgc in Debian unstable?
>
> Yes.
Great. If we can get this and the s390 problem fixed, I'll be able to
see about removing
too?
Given your next message, I think I might just wait for a fixed Debian
libgc. We can't really proceed without that anyway.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
onable patch, we could ask
the Debian libgc maintainer to apply it to the older version.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
sts are in test-suite/standalone/test-require-extension.
I also just realized that I forgot to add appropriate info
documentation. I'll try to make some time to do that, but if anyone
else is motivated, go right ahead.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs
l.
For the record, now that we don't need customizations, I don't have
any problem with dropping our copy of libltdl. Alhough I agree that
it would be good to have a clear configure error message when libltdl
is not detected.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; p
ropriate. Although you'd probably also need a mutex
which might obviate any potential resource savings achieved by
dropping the thread.
--
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 73A
tructs the user to install libltdl,
> maybe by using the included sources.
Hmm. I wonder what the chance is that a user will be able to get hold
of the Guile source, but not the libltdl source. Is it high enough to
justify keeping a normally unused copy of libltdl in our tree?
Marius Vollmer <[EMAIL PROTECTED]> writes:
> So futures are clearly faster than threads (as expected). Nice!
Indeed, and as I think someone may have mentioned, we definitely need
some clarification in the docs, since they don't make it clear how
futures differ from threads.
--
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
tion is, and
that those with sufficient experience with the platform (i.e. probably
not me) have adequately considered any corner cases.
--
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
and is a bit on
> the painful side to figure out. Have you-all a "pkg-config" file
> that can be installed? That would make life easier
> Thanks! Regards, Bruce
We don't at the moment, but I've wanted to take some time to
investigate and see how/if we might
...
flex --version || ...
But I'd guess that the normal
-bash: flex: command not found
might be informative enough.
What would the configure check actually get us?
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432
7;d like to see #| |# work
in-line, in accordance with SRFI-30 and Common Lisp, and perhaps #! !#
should just be a synonym.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B
issue has a chance to review the
changes and comment (i.e. probably Marius).
--
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
ught your previous message said that
this was too big a change for the 1.6 series. Or did you mean that
you want to gear up for a 1.8 release now?
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F
Rob Browning <[EMAIL PROTECTED]> writes:
> Hmm. Did I misunderstand. I thought your previous message said that
> this was too big a change for the 1.6 series. Or did you mean that
> you want to gear up for a 1.8 release now?
Nevermind. I see I hadn't read far enough in
If so, then I think that
would probably be OK. I'd be surprised if anyone knew about and
depended on the current in-line behavior.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25
info", some
of it seems a bit questionable. For example, it mentions build tree
directories which often won't be relevant after an install, and
although it mentions $(pkgincludedir), most of our headers don't
actually go there. They go to $(includedir)/libguile/.
--
Rob Browning
rlb @de
mostly
theoretical argument.
For example, if you want to know the version, you can always just ask
guile:
guile -c '(display (version))'
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D
p?email=&packages=guile-1.6&arches=
--
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-devel mailing list
Guile-devel@gnu.o
I've just committed some changes that fix build problems with gcc 4.0,
at least under a Debian unstable. Please test, especially anyone with
a non-Linux machine.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F
I'd like to release 1.6.8 quite soon.
Given that, if there are issues that need to be resolved that you
think I might overlook, please speak up.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0
If you have time, could those of you who have committed changes to 1.6
(since 1.6.7) check out a current 1.6 tree, look over the output of
cvs -qz5 diff -u -r release_1-6-7
and make sure that all of your changes have appropriate NEWS entries?
Thanks
--
Rob Browning
rlb @defaultvalue.org
Greg Troxel <[EMAIL PROTECTED]> writes:
> Can you put up the output of 'make dist'.
Certainly -- see my next message.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0
For now it's available here:
http://people.debian.org/~rlb/tmp/guile-1.6.8-rc0.tar.gz
Please test. This file isn't likely to become the actual release, but
it's probably close.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG star
es
regarding NEWS, so I'd be more than happy to hear relevant comments
and opinions.
--
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
_
Rob Browning <[EMAIL PROTECTED]> writes:
> If you have time, could those of you who have committed changes to 1.6
> (since 1.6.7) check out a current 1.6 tree, look over the output of
>
> cvs -qz5 diff -u -r release_1-6-7
>
> and make sure that all of your changes have
I can't remember the arguments for and against adding numerator and
denominator to the public API in 1.6.8. Can someone remind me?
Thanks
--
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
one before has it?
>
> (The soname doesn't change, just the sub-minor version on the library
> filename. Probably affects just about nothing.)
Right, and thanks. That's on my to-do.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Rob Browning <[EMAIL PROTECTED]> writes:
>>
>> I can't remember the arguments for and against adding numerator and
>> denominator to the public API in 1.6.8. Can someone remind me?
>
> They're specified
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Rob Browning <[EMAIL PROTECTED]> writes:
>>
>> cvs -qz5 diff -u -r release_1-6-7
>
> I added the bits I did, mostly fixes from bug reports. I've tried to
> keep it brief, none are too terrible, unless you ac
or the release, but I'm not sure that's helpful.
--
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-devel mailing list
Guile-de
i.e. perhaps something like
** make-stack can now correctly construct a stack from a continuation.
if that's correct.
--
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
_
uld you re-try with
the 1.6.8-rc0 archive (or current 1.6 CVS)?
> I don't know if this is a known issue or IA64 specific or what since I
> am not that familiar with guile (I mostly just want to build autogen).
We had a similar problem on ia64/Linux, but with rc0 it seems to h
to work or if I
> should just look at the top-of-tree sources.
Well if your needs aren't short-to-medium term, or if your intended
purpose can handle a potentially very unstable guile, then you might
want to focus on CVS HEAD (i.e. 1.7). However, if you need something
stable, then 1.6 is i
. IA64 Linux GCC defines __ia64 and __ia64__ but not any of the
> hpux macros.
So what code should be used on HP-UX? Should the code in gc_os_dep.c
that's currently guarded by IA64 be enabled or not, and should gc.c
and continuations.c be doing something different for HP-UX, or
7;s no reason this can't wait for 1.6.9,
which I can release as soon as we figure it out.
Thanks
--
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
pproach this would be to do something like
this in ice-9/slib.scm:
(if (detect-older-slib?)
(load-from-path "old-slib.scm")
(load-from-slib "guile.init"))
or similar. Though I don't know if there's an official way to
discover the version of slib that's
Andy Wingo <[EMAIL PROTECTED]> writes:
> I thought about this in the past. It is however a maintainance
> nightmare. If you don't believe me you are free to try it and see ;)
I don't think I'd want to try this unless the upstream was interested
in facilitatin
this weekend at the earliest.
[1] Though actually, the current SLIB release still has the unix/UNIX
symbol case issue (which has been fixed in CVS). I believe it also
doesn't define the (ice-9 slib) module if it detects guile 1.6, so
we'd still need at least a small wrapper.
--
Ro
on it, rather than the code in
slib.scm.
Greg Troxel's suggestion may also be worth considering -- that we
might also provide an easy way to request execution of the older
slib.scm code.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD
Rob Browning <[EMAIL PROTECTED]> writes:
> My current intention is to sit down when I have time and see if I can
> figure out what changes, if any, we would have to make to the current
> guile.init in order to be able to rely on it, rather than the code in
> slib.scm.
So here&#
upstream, but should?
For example, aside from the "eval in interaction-environment vs slib"
issue, see also the comments in slib.scm regarding *features* and
slib:load. Do we need or want to preserve any of those changes?
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previousl
Rob Browning <[EMAIL PROTECTED]> writes:
> For example, aside from the "eval in interaction-environment vs
> slib" issue, see also the comments in slib.scm regarding *features*
> and slib:load. Do we need or want to preserve any of those changes?
With respect to some of
slib docs, and as implemented in
guile.init.
I suppose that leaves just the vicinity related definitions in
question.
--
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
_
(call-with-input-string str
(lambda (port)
(set-port-filename! port filename)
(set-port-line! port line)
(set-port-column! port column)
(eval-port port
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 =
scm_call_4.
> I'll give this a spin and let you know if it works shortly
> (a day or two). Thank you. (I still think adding it to libguile
> would not hurt.)
It could be worth adding something like this to Guile, but I'd need to
think a bit more about what might be mos
implementation.
SRFI-45: Primitives for Expressing Iterative Lazy Algorithms
SRFI-40: A Library of Streams
If these were added to Guile, then we might want the SRFI-40 delay and
force to just replace our existing implementations.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Is there a way to return an exit code with pthread_exit()?
Doesn't pthread allow that directly?
Function: void pthread_exit (void *RETVAL)
Of course you have to pthread_join() to get the value.
--
Rob Browning
rlb @defaul
/ (do last to avoid race at [1])
result = SCM_PROMISE_DATA(p);
}
scm_unlock_mutex(mutex);
}
Note that this wouldn't be safe if the initial mutex assignment might
copy a value that has been half filled by some other thread.
Of course, if we're interested in srfi-45, then it
ly back on-topic, I'm imagining that if
> streams or lazy stuff throw off quite a few forced promises then it's
> a good thing for them to be small and fast.)
Quite possibly.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03
rotect things in real code, so it's not an issue...)
> Actually, I think some memory models will allow some accesses to be
> moved into the region where the lock is held from outside it.
Interesting.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG sta
Rob Browning <[EMAIL PROTECTED]> writes:
> I suppose that leaves just the vicinity related definitions in
> question.
As far as I can tell, the vicinity related definitions aren't exported
or documented, so I think we can just drop those too.
For those still following thi
ticed this, but I think the semantics of
SRFI-45 force/delay are supposed to be a strict superset of R5RS
force/delay, so in theory we might be able to have just one type of
promise.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas
an SLIB release yet. They will,
but I'm not sure they have yet.
With respect to 1.7, I believe I essentially agree with you. My
current plan for 1.7 is to change slib.scm to more or less just read:
(load-from-path "slib/guile.init")
--
Rob Browning
rlb @defaultvalue.org and
ers to update.
Absolutely. I was ready to attempt the release quite a bit back, but
have held it up for this issue.
I should be adding this code to 1.6 CVS in the next few days, and then
I'll fire the release process back up.
Thanks
--
Rob Browning
rlb @defaultvalu
.7. I need to add the slib changes. I hope to get to that
later today or sometime tomorrow.)
--
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
_
t now, and maybe I will regret it
> later, but what the heck!
Also if we don't want to have people hold off on 1.9 only bits in the
trunk, then I'd say that now qualifies as "as late as possible" ;>
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.
nd I was told that they
don't. i.e. this is fine:
Copyright (C) 1997, 1998, 2000, 2001, 2002, 2003,
2004, 2005 Free Software Foundation, Inc.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B5
interested in any significant regressions with
respect to 1.6.7. If none are found, we should be ready to release
1.6.8.
Note that rc1 includes the new SLIB related code; see NEWS. (SLIB
fixes for 1.8 are still pending.)
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously
no matter what the compiler. What
> gives?
I think this may have been fixed in 1.6 CVS. If so, the 1.6.8-rc1
test archive that I recently announced should contain the changes.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39
in SLIB behavior for 1.8 may be substantial,
but I'll know more later. We may end up just requiring a new enough
(perhaps even pending) version of SLIB.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Now that libguile-ltdl is unused, I think I might cvs remove it from
> 1.8 and the head, in the interests of less extraneous stuff. (The old
> contents are still in the cvs of course, just not checked out.)
Sounds good to me.
--
R
est in SCM_TESTS (or
at least EXTRA_DIST) so it'll show up in the distribution.
--
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
___
Guil
ng library if, for example,
the author of the library is willing to allow the inclusion of the
code in Guile.
Hope this helps.
--
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
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Rob Browning <[EMAIL PROTECTED]> writes:
>>
>> I would really like to see Guile provide a fixed regular expression
>> format, one that doesn't vary depending on what the build platform has
>> available. Wit
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Rob Browning <[EMAIL PROTECTED]> writes:
>> My impression was that Guile just uses whatever library it finds on
>> the system (if any), and that the library found might or might not be
>> POSIX compliant. If that's
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
tinuation, and at least with Guile, that
should make them notably more efficient.
Thanks
--
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
__
uations.c, and that does fix the
illegal instruction when executing (call/cc (lambda (c) (c #t))).
However, without having a better understanding about what's actually
happening, I'm not inclined to treat this as a correct solution yet.
Can anyone else comment more conclusively?
Rob Browning <[EMAIL PROTECTED]> writes:
> I also came across this, which suggests that adding a dummy setjmp
> before the getcontext call might help:
>
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/144939
Here's a more recent comment which appears to sa
ag=branch_release-1-6&view=markup
Versions:
Debian libc6.1 2.3.6-15
Debian gcc (GCC) 4.1.2 20060708 (prerelease) (Debian 4.1.1-8)
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE3
that
because Guile calls getcontext via asm, gcc doesn't know that the call
needs to be handled specially?
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592
I've committed the fix suggested in the following thread to 1.6, 1.8,
and CVS head:
http://lists.gnu.org/archive/html/guile-devel/2006-07/msg6.html
I'll try to release updated Debian packages soon.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.
es in a their own test module, and that raised two
questions:
1) Should they (to limit the chance that one test might affect
another inadvertently)?
2) Is there any reason I shouldn't consider just reworking the
scheme level tests to run each foo.test in a separate Guile
way.
I wonder if those test counts are actually all that useful. I would
guess that most of the time you only care whether there was an error
or not.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F
tently break (or
just improperly skew) the current test, i.e. it makes it harder to
isolate your variables. Such a problem seems like the kind of thing
that might take a long time to track down, without providing any
useful diagnostics.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
icular, do gnucash and lilypond work with 1.8.0?
I think lilypond probably does.
Thanks
--
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
___
Rob Browning <[EMAIL PROTECTED]> writes:
> Right now 1.8's make check fails here in popen.test:
I have some further information, and it's quite surprising.
At this point with a fresh guile-1.8.0 tree, popen.test no longer
fails during make check, it hangs, but only in *some*
n-input-pipe: no duplicate
PASS: popen.test: open-output-pipe: no args
PASS: popen.test: open-output-pipe: port?
PASS: popen.test: open-output-pipe: stdin==stderr
PASS: popen.test: open-output-pipe: stdout==stderr
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexa
handler=0x400b6080 , handler_data=0x400d867e)
at throw.c:218
#7 0x400b55ad in really_spawn (d=0xbfa860c8) at threads.c:777
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE
, it looks like the child is probably one of
these zombies. There are several zombie sh children:
\_ [sh]
\_ [sh]
\_ [sh]
\_ [lt-guile]
\_ [lt-guile]
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14
g number of arguments to ~A" (#) #f))
ERROR: In procedure fport_flush:
ERROR: Bad file descriptor
ERROR: In procedure fport_flush:
ERROR: Bad file descriptor
Running ports.test
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14
Rob Browning <[EMAIL PROTECTED]> writes:
> OK, here's what I see with that test code:
>
> Running popen.test
> FAIL: popen.test: open-output-pipe: no duplicate
> FAIL: popen.test: close-pipe: exit 0
> ERROR: popen.test: close-pipe: exit 1 - arguments: ((wrong-number-o
Rob Browning <[EMAIL PROTECTED]> writes:
> Hmm. Just to be sure, I started off with a completely fresh tree, and
> now it hangs with the original code, and fails like this with your
> replacement code:
>
> Running popen.test
> FAIL: popen.test: open-output-pipe:
tation fault.
#0 0x400729ca in scm_fileno (port=0x0) at ioext.c:180
180 port = SCM_COERCE_OUTPORT (port);
(gdb) where
#0 0x400729ca in scm_fileno (port=0x0) at ioext.c:180
#1 0x4005ad41 in ceval (x=0x404, env=0x40372710) at eval.c:4218
#2 0x4005b26e in ceval (x=, env
lieve scm_c_port_for_each() needs a
call to scm_remember_upto_here_1(ports) at the end.
--
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
___
Rob Browning <[EMAIL PROTECTED]> writes:
> Kevin Ryde <[EMAIL PROTECTED]> writes:
>
>> I suppose that's the killer, a port gc-ed prematurely. Perhaps
>> there'd be some significance in which one it was. port-for-each
>> looks pretty safe, maybe the
ge, then I think it
should probably be optional, so that you can just turn it on for code
that was written with the changed semantics in mind.
--
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
pthreads and fork unless we were very careful, and I'm beginning to
wonder again.
--
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
___
Gui
using
--without-threads.
Thanks
--
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-devel mailing list
Guile-devel@gnu.org
http://lists.g
Rob Browning <[EMAIL PROTECTED]> writes:
> In any case, I'll see if I can still get it to hang using
> --without-threads.
I have a tree here where I added a (gc) call before and after the
port-for-each call in popen.scm (in the child). Given that and
--with-threads=yes, "
(force-aux p)
(with-mutex (promise-mutex promise)
(force-aux promise)))
--
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-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
101 - 200 of 271 matches
Mail list logo
