* (no subject) @ 2004-10-14 19:23 Tanisha Villalobos 0 siblings, 0 replies; 12+ messages in thread From: Tanisha Villalobos @ 2004-10-14 19:23 UTC (permalink / raw) Hi again, Here is Tanisha Villalobos. I write to you because we are accepting your m= ortgage application. Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month = payment. Approval process will take 1 minute, so please fill out the form on our we= bsite: http://lockian-growth.refi-talk.com Thank you. Best Regards Tanisha Villalobos First Account Manager _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Merging ‘bdw-gc-static-alloc’ @ 2009-10-02 9:15 Ludovic Courtès 2009-10-02 16:26 ` Andy Wingo 0 siblings, 1 reply; 12+ messages in thread From: Ludovic Courtès @ 2009-10-02 9:15 UTC (permalink / raw) To: guile-devel Hello! Following the inlining of stringbuf storage (ba54a2026beaadb4e7566d4b9e2c9e4c7cd793e6), the ‘bdw-gc-static-alloc' branch introduces a small source-level incompatibility. Namely, the following no longer works: const char foo[] = "foo"; SCM_SYMBOL (s_foo, foo); Because of the macrology that’s used to statically allocate stringbufs [0], the string has to be a literal: SCM_SYMBOL (s_foo, "foo"); The use of non-literal strings occurred only in ‘eval.c’ in Guile proper [1]. The question is: should we merge ‘bdw-gc-static-alloc’ despite this incompatibility (it can be argued that this won’t hurt many people and can be easily worked around)? If the answer is “no”, we still have the option of merging other aspects of the ‘bdw-gc-static-alloc’ branch, such as static allocation of subrs. What do you think? Thanks, Ludo’. [0] http://git.sv.gnu.org/gitweb/?p=guile.git;a=blobdiff;f=libguile/snarf.h;h=9eaccf60c14d825e657718e6f75257e293649f84;hp=c3113e1a7a977f95eb922e924855244dfe4d6cc2;hb=5f236208d0d864546e59afa0f5a11c9b3ba14b10;hpb=f0eb5ae6c173aed35965b0561897fda1d8ff0db1 [1] http://git.sv.gnu.org/gitweb/?p=guile.git;a=blobdiff;f=libguile/eval.c;h=e58c05410c2831d4061eb92b4ee2883c9203c919;hp=59db42976242e12fd41995e5e1fa5d169bd3b9bf;hb=5f236208d0d864546e59afa0f5a11c9b3ba14b10;hpb=d7e7a02a6251c8ed4f76933d9d30baeee3f599c0 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Merging ‘bdw-gc-static-alloc’ 2009-10-02 9:15 Merging ‘bdw-gc-static-alloc’ Ludovic Courtès @ 2009-10-02 16:26 ` Andy Wingo 2009-10-23 9:16 ` Ludovic Courtès 0 siblings, 1 reply; 12+ messages in thread From: Andy Wingo @ 2009-10-02 16:26 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel On Fri 02 Oct 2009 02:15, ludo@gnu.org (Ludovic Courtès) writes: > Because of the macrology that’s used to statically allocate stringbufs [0], > the string has to be a literal: > > SCM_SYMBOL (s_foo, "foo"); > > What do you think? Need more information :) How widespread is the non-literal usage? Could you grep the source packages of the Guile users that you have identified for occurrences of this idiom? Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Merging ‘bdw-gc-static-alloc’ 2009-10-02 16:26 ` Andy Wingo @ 2009-10-23 9:16 ` Ludovic Courtès 2009-10-23 12:57 ` Andy Wingo 0 siblings, 1 reply; 12+ messages in thread From: Ludovic Courtès @ 2009-10-23 9:16 UTC (permalink / raw) To: guile-devel Hi, Andy Wingo <wingo@pobox.com> writes: > On Fri 02 Oct 2009 02:15, ludo@gnu.org (Ludovic Courtès) writes: > >> Because of the macrology that’s used to statically allocate stringbufs [0], >> the string has to be a literal: >> >> SCM_SYMBOL (s_foo, "foo"); >> >> What do you think? > > Need more information :) How widespread is the non-literal usage? Could > you grep the source packages of the Guile users that you have identified > for occurrences of this idiom? Apparently this is going to be rare. I’ve found no occurrences here: http://www.google.fr/codesearch?q=SCM_%28GLOBAL_%29%3FSYMBOL&hl=fr&btnG=Rechercher+du+code “grep -r -E \ 'SCM_(GLOBAL_)?SYMBOL[[:blank:]]*\([^,]+,[[:blank:]]*[^"]+\)' \ gnucash-2.2.9 guile-avahi guile-cairo-1.4.0 \ guile-gnome-platform-2.16.1 gnutls mailutils-2.1 snd-9.4” doesn’t show any occurrence either. So I’d be tempted to merge this in. What do you think? Ludo’. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Merging ‘bdw-gc-static-alloc’ 2009-10-23 9:16 ` Ludovic Courtès @ 2009-10-23 12:57 ` Andy Wingo 2009-11-02 21:44 ` Ludovic Courtès 0 siblings, 1 reply; 12+ messages in thread From: Andy Wingo @ 2009-10-23 12:57 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel EHLO On Fri 23 Oct 2009 11:16, ludo@gnu.org (Ludovic Courtès) writes: > Andy Wingo <wingo@pobox.com> writes: > >> On Fri 02 Oct 2009 02:15, ludo@gnu.org (Ludovic Courtès) writes: >> >>> Because of the macrology that’s used to statically allocate stringbufs [0], >>> the string has to be a literal: >>> >>> SCM_SYMBOL (s_foo, "foo"); >>> >>> What do you think? >> >> Need more information :) How widespread is the non-literal usage? Could >> you grep the source packages of the Guile users that you have identified >> for occurrences of this idiom? > > Apparently this is going to be rare. I’ve found no occurrences here: > > So I’d be tempted to merge this in. > > What do you think? Roll on, merge train, roll on! I have finished case-lambda, but am rebasing and cleaning up patches I haven't pushed yet. So it's a race. Gentlemen, start your git rebase & push! A -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Merging ‘bdw-gc-static-alloc’ 2009-10-23 12:57 ` Andy Wingo @ 2009-11-02 21:44 ` Ludovic Courtès 2009-11-03 20:57 ` (no subject) Neil Jerram 0 siblings, 1 reply; 12+ messages in thread From: Ludovic Courtès @ 2009-11-02 21:44 UTC (permalink / raw) To: guile-devel [-- Attachment #1: Type: text/plain, Size: 592 bytes --] Hello! I merged that branch in ‘master’. ... and soon after I noticed this glitch with ‘SCM_DEFINE’: when ‘SCM_SUPPORT_STATIC_ALLOCATION’ is defined, it requires a previous C declaration of the subr being defined. For instance: SCM_DEFINE (foo, "foo", 1, 0, 0, (SCM x), "") { ... } must now be preceded by: extern SCM foo (SCM); This is not a problem in Guile core where we compile with ‘-Wmissing-prototypes’ and provide public declarations for all ‘SCM_DEFINE’d functions, but it may be a problem in projects that don’t. This is easily remedied this way: [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Type: text/x-patch, Size: 624 bytes --] --- a/libguile/snarf.h +++ b/libguile/snarf.h @@ -101,14 +101,15 @@ SCM_SNARF_DOCS(primitive, FNAME, PRIMNAME, ARGLIST, REQ, OPT, VAR, DOCSTRING) /* Static subr allocation. */ #define SCM_DEFINE(FNAME, PRIMNAME, REQ, OPT, VAR, ARGLIST, DOCSTRING) \ SCM_SYMBOL (scm_i_paste (FNAME, __name), PRIMNAME); \ -SCM_SNARF_HERE( \ +SCM_SNARF_HERE( \ static const char scm_i_paste (s_, FNAME) [] = PRIMNAME; \ + extern SCM FNAME ARGLIST; \ SCM_IMMUTABLE_SUBR (scm_i_paste (FNAME, __subr), \ scm_i_paste (FNAME, __name), \ REQ, OPT, VAR, &FNAME); \ SCM FNAME ARGLIST \ [-- Attachment #3: Type: text/plain, Size: 679 bytes --] However, there are potentially 2 problems with this: 1. The declaration could conflict with a previous, slightly different one. Apparently, a given function declaration and the same one decorated with GCC function attributes are considered the same, so this should be OK. However, I’m slightly concerned about MSVC’s __declspec: does it work if it sees: __declspec(dllexport) extern SCM foo (SCM); extern SCM foo (SCM); If it works, that probably means this point is moot. 2. The automatically added ‘extern’ declaration makes ‘-Wmissing-prototypes’ useless, which is annoying. Thoughts? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 12+ messages in thread
* (no subject) 2009-11-02 21:44 ` Ludovic Courtès @ 2009-11-03 20:57 ` Neil Jerram 2009-11-05 22:30 ` Merging ‘bdw-gc-static-alloc’ Ludovic Courtès 0 siblings, 1 reply; 12+ messages in thread From: Neil Jerram @ 2009-11-03 20:57 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel ludo@gnu.org (Ludovic Courtès) writes: > should be OK. However, I’m slightly concerned about MSVC’s > __declspec: does it work if it sees: > > __declspec(dllexport) extern SCM foo (SCM); > extern SCM foo (SCM); I don't know for sure, but I know I've seen "function redeclared with different linkage" warnings in the past, and this could well be one of the situations that generates such warnings. But what about using SCM_API instead of extern? Wouldn't that always generate the right code? (At least for building guile itself.) > If it works, that probably means this point is moot. > > 2. The automatically added ‘extern’ declaration makes > ‘-Wmissing-prototypes’ useless, which is annoying. I guess it depends if the primitives in question are designed to be used only from Scheme, or also from other C files. If they're only for Scheme, it's a nice feature that SCM_DEFINE does everything needed and the developer doesn't need a matching prototype. If they're for other C files, the missing prototype warning could be helpful. Then again, the developer will get some kind of warning anyway when trying to use the function from another file. So I think the balance is in favour of SCM_DEFINE including the prototype. Neil ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Merging ‘bdw-gc-static-alloc’ 2009-11-03 20:57 ` (no subject) Neil Jerram @ 2009-11-05 22:30 ` Ludovic Courtès 2009-11-08 22:21 ` (no subject) Neil Jerram 0 siblings, 1 reply; 12+ messages in thread From: Ludovic Courtès @ 2009-11-05 22:30 UTC (permalink / raw) To: Neil Jerram; +Cc: guile-devel Hi Neil, Neil Jerram <neil@ossau.uklinux.net> writes: > ludo@gnu.org (Ludovic Courtès) writes: > >> should be OK. However, I’m slightly concerned about MSVC’s >> __declspec: does it work if it sees: >> >> __declspec(dllexport) extern SCM foo (SCM); >> extern SCM foo (SCM); > > I don't know for sure, but I know I've seen "function redeclared with > different linkage" warnings in the past, and this could well be one of > the situations that generates such warnings. Right. > But what about using SCM_API instead of extern? Wouldn't that always > generate the right code? (At least for building guile itself.) You’re right. It’ll work for building Guile itself, but most probably fail when building external libraries, because it will have SCM_API==dllimport whereas the symbols of the lib being built want dllexport. I have no idea how to fix this since third party libraries typically have their own ‘SCM_API’-like macro for that purpose. Well, we could just disable ‘SCM_SUPPORT_STATIC_ALLOCATION’ altogether for “Woe32” builds. What do you think? In the meantime, I’ve pushed this: http://git.savannah.gnu.org/cgit/guile.git/commit/?id=f4767979987530bb9d88dde6ebe61cdac6f756b9 . > I guess it depends if the primitives in question are designed to be used > only from Scheme, or also from other C files. If they're only for > Scheme, it's a nice feature that SCM_DEFINE does everything needed and > the developer doesn't need a matching prototype. If they're for other C > files, the missing prototype warning could be helpful. Yes, although ideally functions only for Scheme would be either static or with internal linkage, which calls for an ‘SCM_DEFINE_LOCAL’ macro or similar. > Then again, the developer will get some kind of warning anyway when > trying to use the function from another file. So I think the balance is > in favour of SCM_DEFINE including the prototype. Yes. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 12+ messages in thread
* (no subject) 2009-11-05 22:30 ` Merging ‘bdw-gc-static-alloc’ Ludovic Courtès @ 2009-11-08 22:21 ` Neil Jerram 0 siblings, 0 replies; 12+ messages in thread From: Neil Jerram @ 2009-11-08 22:21 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel ludo@gnu.org (Ludovic Courtès) writes: > Hi Neil, > > Neil Jerram <neil@ossau.uklinux.net> writes: > >> But what about using SCM_API instead of extern? Wouldn't that always >> generate the right code? (At least for building guile itself.) > > You’re right. It’ll work for building Guile itself, but most probably > fail when building external libraries, because it will have > SCM_API==dllimport whereas the symbols of the lib being built want > dllexport. > > I have no idea how to fix this since third party libraries typically > have their own ‘SCM_API’-like macro for that purpose. > > Well, we could just disable ‘SCM_SUPPORT_STATIC_ALLOCATION’ altogether > for “Woe32” builds. > > What do you think? We're talking here about macros that are always used in .c files, aren't we? (As opposed to headers that an application using the library would include.) So on Woe32, we actually always want dllexport. i.e. if the header has SCM_API SCM scm_frobate (SCM arg); and the SCM_DEFINE in .c expands to something that includes __declspec(dllexport) SCM scm_frobate (SCM arg); that should be good, because SCM_API will be __declspec(dllexport) when building the library. In the Scheme-only case, that does mean exporting something that doesn't need exporting - but either we can just live with that, or later add your suggestion of SCM_DEFINE_LOCAL. Regards, Neil ^ permalink raw reply [flat|nested] 12+ messages in thread
* i guess we're frozen & stuff @ 2009-08-10 19:41 Andy Wingo 2009-08-11 11:34 ` Greg Troxel 0 siblings, 1 reply; 12+ messages in thread From: Andy Wingo @ 2009-08-10 19:41 UTC (permalink / raw) To: guile-devel Hello Guilers, Today's the 10th, we release on the 15th, ergo we're frozen. What does this mean? Well I think the dilly is that we shouldn't be pushing to master, except to fix things that don't work at all, and to update documentation, NEWS, etc. What if you don't have push access? Well give Guile a try with your programs, run some benchmarks against 1.9.1, give the tires a good kick. From my part, I wrote a summary of what I've been up to here: http://wingolog.org/archives/2009/08/10/goto- Happy hacking! Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: i guess we're frozen & stuff 2009-08-10 19:41 i guess we're frozen & stuff Andy Wingo @ 2009-08-11 11:34 ` Greg Troxel 2009-08-11 13:59 ` Ken Raeburn 0 siblings, 1 reply; 12+ messages in thread From: Greg Troxel @ 2009-08-11 11:34 UTC (permalink / raw) To: Andy Wingo; +Cc: guile-devel [-- Attachment #1: Type: text/plain, Size: 997 bytes --] Today's the 10th, we release on the 15th, ergo we're frozen. What does this mean? Well I think the dilly is that we shouldn't be pushing to master, except to fix things that don't work at all, and to update documentation, NEWS, etc. What if you don't have push access? Well give Guile a try with your programs, run some benchmarks against 1.9.1, give the tires a good kick. Sorry, I've been distracted. Is this what we call 'master', and what I am running autobuilds against, along with the 1.8 branch? I will try to find time to install libunistring and get it to build. Have there been recent reports of success of 1.9.x on platforms other than GNU/Linux? Guile has been quite portable in the past and it's surely still very close if not there, and it would be a shame if 2.0 had issues. I realize this is hard for people to test if they don't have the platform, but it would be really good to have testing on at least one normal BSD and also Darwin. [-- Attachment #2: Type: application/pgp-signature, Size: 193 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: i guess we're frozen & stuff 2009-08-11 11:34 ` Greg Troxel @ 2009-08-11 13:59 ` Ken Raeburn 2009-08-12 22:41 ` Andy Wingo 0 siblings, 1 reply; 12+ messages in thread From: Ken Raeburn @ 2009-08-11 13:59 UTC (permalink / raw) To: guile-devel [-- Attachment #1: Type: text/plain, Size: 3445 bytes --] On Aug 11, 2009, at 07:34, Greg Troxel wrote: > Have there been recent reports of success of 1.9.x on platforms other > than GNU/Linux? Guile has been quite portable in the past and it's > surely still very close if not there, and it would be a shame if 2.0 > had > issues. I realize this is hard for people to test if they don't have > the platform, but it would be really good to have testing on at least > one normal BSD and also Darwin. The Mac build off of "master" fails for me currently in srfi-13.c, with the comparison-always-false warning Greg discussed. I hacked around that, but then guile-readline doesn't build: Making all in guile-readline ../libguile/guile-snarf -o readline.x ../../guile-readline/readline.c - DHAVE_CONFIG_H -I. -I.. -I../../guile-readline/.. -I../../guile- readline/lib -I./lib -g -O2 In file included from ../../guile-readline/readline.c:29: ../../guile-readline/../libguile.h:25:17: error: gmp.h: No such file or directory In file included from ../../guile-readline/../libguile.h:95, from ../../guile-readline/readline.c:29: ../../guile-readline/../libguile/strings.h:26:21: error: uniconv.h: No such file or directory Neither the path specified for libgmp nor the path specified for libunistring at configure time is included here. I don't think any of this is Mac-specific; I'm surprised that it works on GNU/Linux systems. Perhaps I'm building it in ways that are unusual for the other developers (build dir != src dir, libgmp and guile-1.8 installed in the same place, libgmp and libunistring installed in different nonstandard directories)? If I use CPPFLAGS=... and LDFLAGS=... instead of --with-libfoo-prefix configure options to specify paths to find libgmp and libunistring, the tests still pick old, installed Guile headers (which this time I've poisoned to highlight the problem) from those locations instead of the in-tree versions: Making all in test-suite Making all in standalone ../../libguile/guile-snarf -o test-asmobs-lib.x ../../../test-suite/ standalone/test-asmobs-lib.c -DHAVE_CONFIG_H -I. -I../../../test-suite/ standalone -I../.. -I/opt/local/include -I/Users/raeburn/dev/guile/ libunistring-0.9.1/I/include -g -O2 -I../../.. -I../../../lib -I../../ lib -I../.. In file included from /opt/local/include/libguile.h:30, from ../../../test-suite/standalone/test-asmobs- lib.c:23: /opt/local/include/libguile/__scm.h:3:2: error: #error Poison! I might be building Guile as part of a larger package (*cough*Emacs*cough*) that wants to include stuff from the same system directories (e.g., for MacPorts, pkgsrc, whatever) where an old version of Guile is installed, and thus Guile gets passed CPPFLAGS/ LDFLAGS settings that add that old version to the search paths. So I think the CPPFLAGS/LDFLAGS version needs to be made to work, as well as the --with-libfoo-prefix version. With the attached patch, I can get guile to build with CPPFLAGS= and LDFLAGS= ... someone more familiar than I am with automake will have to fix the guile-readline stuff. Even with my patch, it fails its tests: make check-TESTS Testing /Users/raeburn/dev/guile/git/guile/b3/meta/guile ... with GUILE_LOAD_PATH=/Users/raeburn/dev/guile/git/guile/test-suite ERROR: In procedure make_objcode_by_mmap: ERROR: bad header on object file: "GOOF-0.6-LE-4---" FAIL: check-guile Still looking into that.... Ken [-- Attachment #2: guile-master.diff --] [-- Type: application/octet-stream, Size: 1043 bytes --] --- a/test-suite/standalone/Makefile.am +++ b/test-suite/standalone/Makefile.am @@ -30,17 +30,20 @@ EXTRA_DIST = TESTS_ENVIRONMENT = "${top_builddir}/meta/uninstalled-env" +## Check for headers in $(srcdir) and bulid dir before $(CPPFLAGS), which +## may point us to an old, installed version of guile. +AM_CPPFLAGS = -I$(top_srcdir) -I$(top_builddir) \ + -I$(top_srcdir)/lib -I$(top_builddir)/lib + test_cflags = \ - -I$(top_srcdir)/test-suite/standalone \ - -I$(top_srcdir) -I$(top_builddir) \ - -I$(top_srcdir)/lib -I$(top_builddir)/lib \ + -I$(top_srcdir)/test-suite/standalone -I. \ $(EXTRA_DEFS) $(GUILE_CFLAGS) $(GCC_CFLAGS) AM_LDFLAGS = $(GUILE_CFLAGS) -snarfcppopts = \ - $(DEFS) $(DEFAULT_INCLUDES) $(CPPFLAGS) $(CFLAGS) -I$(top_srcdir) \ - -I$(top_srcdir)/lib -I$(top_builddir)/lib -I$(top_builddir) +snarfcppopts = \ + -I$(top_srcdir) -I$(top_srcdir)/lib -I$(top_builddir)/lib -I$(top_builddir) \ + -I. $(DEFS) $(DEFAULT_INCLUDES) $(CPPFLAGS) $(CFLAGS) SUFFIXES = .x .c.x: [-- Attachment #3: Type: text/plain, Size: 1 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: i guess we're frozen & stuff 2009-08-11 13:59 ` Ken Raeburn @ 2009-08-12 22:41 ` Andy Wingo 2009-09-16 19:00 ` Andy Wingo 0 siblings, 1 reply; 12+ messages in thread From: Andy Wingo @ 2009-08-12 22:41 UTC (permalink / raw) To: Ken Raeburn; +Cc: guile-devel Hi Ken, On Tue 11 Aug 2009 15:59, Ken Raeburn <raeburn@raeburn.org> writes: > Perhaps I'm building [Guile] in ways that are unusual for the other > developers (build dir != src dir, libgmp and guile-1.8 installed in > the same place, libgmp and libunistring installed in different > nonstandard directories)? Yes, I think this is the case. Your bug reports are appreciated. Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: i guess we're frozen & stuff 2009-08-12 22:41 ` Andy Wingo @ 2009-09-16 19:00 ` Andy Wingo 2009-09-25 21:59 ` Ken Raeburn 0 siblings, 1 reply; 12+ messages in thread From: Andy Wingo @ 2009-09-16 19:00 UTC (permalink / raw) To: Ken Raeburn; +Cc: guile-devel Hi Ken, On Tue 11 Aug 2009 15:59, Ken Raeburn <raeburn@raeburn.org> writes: > Perhaps I'm building [Guile] in ways that are unusual for the other > developers (build dir != src dir, libgmp and guile-1.8 installed in > the same place, libgmp and libunistring installed in different > nonstandard directories)? I think I fixed the case in which $prefix was not in LD_LIBRARY_PATH or the like. Can you update us on the status of your build issues? Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: i guess we're frozen & stuff 2009-09-16 19:00 ` Andy Wingo @ 2009-09-25 21:59 ` Ken Raeburn 2009-09-26 21:02 ` Ludovic Courtès 0 siblings, 1 reply; 12+ messages in thread From: Ken Raeburn @ 2009-09-25 21:59 UTC (permalink / raw) To: guile-devel On Sep 16, 2009, at 15:00, Andy Wingo wrote: > Hi Ken, > > On Tue 11 Aug 2009 15:59, Ken Raeburn <raeburn@raeburn.org> writes: > >> Perhaps I'm building [Guile] in ways that are unusual for the other >> developers (build dir != src dir, libgmp and guile-1.8 installed in >> the same place, libgmp and libunistring installed in different >> nonstandard directories)? > > I think I fixed the case in which $prefix was not in LD_LIBRARY_PATH > or > the like. Can you update us on the status of your build issues? Frequently failing. :-( On the bright side, using the --with-foo-prefix options, I haven't seen indications yet of the include- and load-path problems I saw before. Today (f60e892), it can't compile i18n.c at line 799 on my Mac because it tries to deference scm_t_locale which points to an incomplete type. Backing up to bcccf04, it builds okay, but lots of regexp tests fail with "illegal byte sequence" errors. With "make -k check", that's the only error reported. With f60e892, if I disable the defining of USE_GNU_LOCALE_API, I still get the regexp test errors, and srfi-18.test fails, but only sometimes: Running srfi-18.test WARNING: (srfi srfi-18): imported module (srfi srfi-34) overrides core binding `raise' throw from within critical section. error key: foo /bin/sh: line 1: 74711 Abort trap ${dir}$tst FAIL: check-guile I haven't checked if srfi-18.test has intermittent failures in the older revision. It might also matter that I was sometimes piping the test output through "more", which could've conceivably blocked process output for a while, changing the timing of events between threads. On GNU/Linux (RHEL 4), I had to download, build and install the GC library, and took the stable one linked to from the web page for the package. But that didn't declare GC_dump, so I had to disable warnings in the build. After that, building, installing and testing *seemed* to go just fine. I'm seeing another weird effect though -- sometimes some of the tests outputs are getting reported twice. In another test I just did on my Mac, the repetition isn't starting on line boundaries, though, so it looks like it's actually the output getting corrupted, vs re-running or re-reporting tests for no obvious reason: Running socket.test WARNING: (srfi srfi-18): imported module (srfi srfi-34) overrides core binding `raise' WARNING: (test-srfi-69): imported module (srfi srfi-69) overrides core binding `make-hash-table' WARNING: (test-srfi-69): imported module (srfi srfi-69) overrides core binding `hash-table?' exp" "illegal byte sequence" #f ("a<C7>"))) ERROR: regexp.test: regexp-quote: regexp/extended: (string "aX" 200 # \<C8> "a<C8>" "a<C8>") - arguments: ((regular-expression-syntax "make-regexp" "illegal byte sequence" #f ("a<C8>"))) I've seen the duplicated output on GNU/Linux too. In reproducing this, again, it seems to help to pipe the output through "more", and follow it slowly (i.e., so presumably the pipe will fill and output will occasionally be blocked). Ken ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: i guess we're frozen & stuff 2009-09-25 21:59 ` Ken Raeburn @ 2009-09-26 21:02 ` Ludovic Courtès 2009-09-28 17:22 ` Neil Jerram 0 siblings, 1 reply; 12+ messages in thread From: Ludovic Courtès @ 2009-09-26 21:02 UTC (permalink / raw) To: guile-devel Hi Ken, Ken Raeburn <raeburn@raeburn.org> writes: > Running srfi-18.test > WARNING: (srfi srfi-18): imported module (srfi srfi-34) overrides core > binding `raise' > throw from within critical section. > error key: foo > /bin/sh: line 1: 74711 Abort trap ${dir}$tst > FAIL: check-guile This must be related to http://savannah.gnu.org/bugs/?27457 . Contributions welcome! ;-) > On GNU/Linux (RHEL 4), I had to download, build and install the GC > library, and took the stable one linked to from the web page for the > package. But that didn't declare GC_dump, so I had to disable > warnings in the build. Which version is that? The declaration appears to be present at least in 7.1 and current CVS. Thanks, Ludo’. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: i guess we're frozen & stuff 2009-09-26 21:02 ` Ludovic Courtès @ 2009-09-28 17:22 ` Neil Jerram 2009-09-28 18:48 ` Ludovic Courtès 0 siblings, 1 reply; 12+ messages in thread From: Neil Jerram @ 2009-09-28 17:22 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Guile Development ludo@gnu.org (Ludovic Courtès) writes: > Hi Ken, > > Ken Raeburn <raeburn@raeburn.org> writes: > >> Running srfi-18.test >> WARNING: (srfi srfi-18): imported module (srfi srfi-34) overrides core >> binding `raise' >> throw from within critical section. >> error key: foo >> /bin/sh: line 1: 74711 Abort trap ${dir}$tst >> FAIL: check-guile > > This must be related to http://savannah.gnu.org/bugs/?27457 . > Contributions welcome! ;-) I will start looking at this later this evening. (Unless you're already investigating - in which case please let me know!) Regards, Neil ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: i guess we're frozen & stuff 2009-09-28 17:22 ` Neil Jerram @ 2009-09-28 18:48 ` Ludovic Courtès 2009-09-28 22:42 ` Neil Jerram 0 siblings, 1 reply; 12+ messages in thread From: Ludovic Courtès @ 2009-09-28 18:48 UTC (permalink / raw) To: Neil Jerram; +Cc: Guile Development Hi, Neil Jerram <neil@ossau.uklinux.net> writes: > ludo@gnu.org (Ludovic Courtès) writes: >> This must be related to http://savannah.gnu.org/bugs/?27457 . >> Contributions welcome! ;-) > > I will start looking at this later this evening. (Unless you're already > investigating - in which case please let me know!) I won’t look into it in the next days, so go ahead! ;-) (Note that you can assign the bug to yourself in the bug tracker, if you want.) Thanks, Ludo’. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: i guess we're frozen & stuff 2009-09-28 18:48 ` Ludovic Courtès @ 2009-09-28 22:42 ` Neil Jerram 2009-09-28 23:21 ` Bug #27457 (“Threads, mutexes, and critical sections”) Ludovic Courtès 0 siblings, 1 reply; 12+ messages in thread From: Neil Jerram @ 2009-09-28 22:42 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Guile Development ludo@gnu.org (Ludovic Courtès) writes: > Hi, > > Neil Jerram <neil@ossau.uklinux.net> writes: > >> ludo@gnu.org (Ludovic Courtès) writes: > >>> This must be related to http://savannah.gnu.org/bugs/?27457 . >>> Contributions welcome! ;-) >> >> I will start looking at this later this evening. (Unless you're already >> investigating - in which case please let me know!) > > I won’t look into it in the next days, so go ahead! ;-) Well... I don't see the throw from critical section problem. Instead, after a while, I see a hang, with one thread doing: #0 0xb7f06424 in __kernel_vsyscall () #1 0xb7acd255 in sem_wait@@GLIBC_2.1 () from /lib/i686/cmov/libpthread.so.0 #2 0xb7dc2018 in GC_stop_world () from /usr/lib/libgc.so.1 and all the others: #0 0xb7f06424 in __kernel_vsyscall () #1 0xb7b05837 in sigsuspend () from /lib/i686/cmov/libc.so.6 #2 0xb7dc222b in GC_suspend_handler_inner () from /usr/lib/libgc.so.1 #3 0xb7dc22b5 in GC_suspend_handler () from /usr/lib/libgc.so.1 #4 <signal handler called> In theory, each other thread must have called sem_post(), and the number of those sem_post()s should be the same as the number of times that the GC_stop_world thread calls sem_wait(), and so the GC_stop_world thread shouldn't be waiting. I wonder if there's a way that the pthread_kill(p->id, SIG_SUSPEND) in GC_stop_world can appear to succeed (by returning 0), but the signalled thread doesn't get the signal, or dies before it does the sem_post()? Regarding the throw from critical section problem, I guess I'm not seeing this because of not running on a multi-core machine. Can someone who does see this problem - run under GDB - set a breakpoint on the fprintf (stderr, "throw from within critical section.\n") line in throw.c - post the thread backtraces (thread apply all bt), when this breakpoint is hit? Thanks. Neil ^ permalink raw reply [flat|nested] 12+ messages in thread
* Bug #27457 (“Threads, mutexes, and critical sections”) 2009-09-28 22:42 ` Neil Jerram @ 2009-09-28 23:21 ` Ludovic Courtès 2009-09-30 20:59 ` (no subject) Neil Jerram 0 siblings, 1 reply; 12+ messages in thread From: Ludovic Courtès @ 2009-09-28 23:21 UTC (permalink / raw) To: guile-devel Hi Neil, Neil Jerram <neil@ossau.uklinux.net> writes: > ludo@gnu.org (Ludovic Courtès) writes: > >> Hi, >> >> Neil Jerram <neil@ossau.uklinux.net> writes: >> >>> ludo@gnu.org (Ludovic Courtès) writes: >> >>>> This must be related to http://savannah.gnu.org/bugs/?27457 . >>>> Contributions welcome! ;-) >>> >>> I will start looking at this later this evening. (Unless you're already >>> investigating - in which case please let me know!) >> >> I won’t look into it in the next days, so go ahead! ;-) > > Well... I don't see the throw from critical section problem. Instead, > after a while, I see a hang, with one thread doing: > > #0 0xb7f06424 in __kernel_vsyscall () > #1 0xb7acd255 in sem_wait@@GLIBC_2.1 () from /lib/i686/cmov/libpthread.so.0 > #2 0xb7dc2018 in GC_stop_world () from /usr/lib/libgc.so.1 > > and all the others: > > #0 0xb7f06424 in __kernel_vsyscall () > #1 0xb7b05837 in sigsuspend () from /lib/i686/cmov/libc.so.6 > #2 0xb7dc222b in GC_suspend_handler_inner () from /usr/lib/libgc.so.1 > #3 0xb7dc22b5 in GC_suspend_handler () from /usr/lib/libgc.so.1 > #4 <signal handler called> > > In theory, each other thread must have called sem_post(), and the number > of those sem_post()s should be the same as the number of times that the > GC_stop_world thread calls sem_wait(), and so the GC_stop_world thread > shouldn't be waiting. I should have mentioned this one: http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3185 . This is normally somewhat fixed in current BDW-GC CVS, but Guile itself may have troubles of its own dealing with cancellation. The critical section issue should be orthogonal, though. > Regarding the throw from critical section problem, I guess I'm not > seeing this because of not running on a multi-core machine. Can someone > who does see this problem > > - run under GDB > - set a breakpoint on the fprintf (stderr, "throw from within critical > section.\n") line in throw.c > - post the thread backtraces (thread apply all bt), when this breakpoint > is hit? Here it is: --8<---------------cut here---------------start------------->8--- Breakpoint 1, scm_ithrow (key=0x707060, args=0x404, noreturn=1) at throw.c:746 (gdb) thread apply all bt Thread 564 (Thread 0x7f90c0d20950 (LWP 18603)): #0 0x00007f90c6f3077a in times () from /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libc.so.6 #1 0x00007f90c85308cc in scm_c_get_internal_run_time () at stime.c:106 #2 0x00007f90c85439ec in vm_debug_engine (vp=0x7f90c0d1f860, program=0x7f90c0d1f860, argv=0x0, nargs=<value optimized out>) at vm-engine.c:59 #3 0x00007f90c853a751 in scm_c_with_throw_handler (tag=0x8e90c0, body=<value optimized out>, body_data=0x7f90c0d1fa50, handler=<value optimized out>, handler_data=<value optimized out>, lazy_catch_p=<value optimized out>) at throw.c:318 #4 0x00007f90c853a845 in scm_with_throw_handler (key=0x7f90c0d1f860, thunk=<value optimized out>, handler=0xc18da0) at throw.c:665 #5 0x00007f90c8545861 in vm_debug_engine (vp=0x703500, program=<value optimized out>, argv=<value optimized out>, nargs=<value optimized out>) at vm-i-system.c:605 #6 0x00007f90c853abc5 in scm_c_catch (tag=<value optimized out>, body=<value optimized out>, body_data=<value optimized out>, handler=<value optimized out>, handler_data=<value optimized out>, pre_unwind_handler=0, pre_unwind_handler_data=0x7f90c0d1fd60) at throw.c:243 #7 0x00007f90c853ad4e in scm_catch_with_pre_unwind_handler (key=0x7f90c0d1f860, thunk=<value optimized out>, handler=0xa2c900, pre_unwind_handler=0x204) at throw.c:627 #8 0x00007f90c853939b in really_launch (d=0x7fff794861b0) at threads.c:801 #9 0x00007f90c84d04aa in c_body (d=0x7f90c0d20000) at continuations.c:318 #10 0x00007f90c853abc5 in scm_c_catch (tag=<value optimized out>, body=<value optimized out>, body_data=<value optimized out>, handler=<value optimized out>, handler_data=<value optimized out>, pre_unwind_handler=0x7f90c8539fc0 <scm_handle_by_message_noexit>, pre_unwind_handler_data=0x0) at throw.c:243 #11 0x00007f90c84d08d7 in scm_i_with_continuation_barrier (body=<value optimized out>, body_data=<value optimized out>, handler=0x7f90c84d04c0 <c_handler>, handler_data=0x7f90c0d20000, pre_unwind_handler=<value optimized out>, pre_unwind_handler_data=<value optimized out>) at continuations.c:294 #12 0x00007f90c84d0970 in scm_c_with_continuation_barrier (func=<value optimized out>, data=<value optimized out>) at continuations.c:336 #13 0x00007f90c8539972 in scm_i_with_guile_and_parent (func=<value optimized out>, data=<value optimized out>, parent=<value optimized out>) at threads.c:709 #14 0x00007f90c8539a13 in launch_thread (d=0x7fff794861b0) at threads.c:814 #15 0x00007f90c7ffddb2 in GC_inner_start_routine (sb=<value optimized out>, arg=<value optimized out>) at ../pthread_support.c:1153 #16 0x00007f90c7ff7af5 in GC_call_with_stack_base (fn=0x66b61bdc, arg=0x7f90c0d1f860) at ../misc.c:1323 #17 0x00007f90c7dcaf97 in start_thread () from /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libpthread.so.0 #18 0x00007f90c6f6156d in clone () from /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libc.so.6 Thread 2 (Thread 0x7f90c61c0950 (LWP 18001)): #0 0x00007f90c7dd191b in read () from /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libpthread.so.0 #1 0x00007f90c85182b3 in signal_delivery_thread (data=<value optimized out>) at scmsigs.c:164 #2 0x00007f90c853abc5 in scm_c_catch (tag=<value optimized out>, body=<value optimized out>, body_data=<value optimized out>, handler=<value optimized out>, handler_data=<value optimized out>, pre_unwind_handler=0, pre_unwind_handler_data=0x0) at throw.c:243 #3 0x00007f90c853adb4 in scm_internal_catch (tag=0x2c, body=0x7f90c61bfb8f, body_data=0x1, handler=0xffffffffffffffff, handler_data=0x7f90c8217520) at throw.c:257 #4 0x00007f90c85391ce in really_spawn (d=0x7fff79486dd0) at threads.c:891 #5 0x00007f90c84d04aa in c_body (d=0x7f90c61c0000) at continuations.c:318 #6 0x00007f90c853abc5 in scm_c_catch (tag=<value optimized out>, body=<value optimized out>, body_data=<value optimized out>, handler=<value optimized out>, handler_data=<value optimized out>, pre_unwind_handler=0x7f90c8539fc0 <scm_handle_by_message_noexit>, pre_unwind_handler_data=0x0) at throw.c:243 #7 0x00007f90c84d08d7 in scm_i_with_continuation_barrier (body=<value optimized out>, body_data=<value optimized out>, handler=0x7f90c84d04c0 <c_handler>, handler_data=0x7f90c61c0000, pre_unwind_handler=<value optimized out>, pre_unwind_handler_data=<value optimized out>) at continuations.c:294 #8 0x00007f90c84d0970 in scm_c_with_continuation_barrier (func=<value optimized out>, data=<value optimized out>) at continuations.c:336 #9 0x00007f90c8539972 in scm_i_with_guile_and_parent (func=<value optimized out>, data=<value optimized out>, parent=<value optimized out>) at threads.c:709 #10 0x00007f90c85399e3 in spawn_thread (d=0x7fff79486dd0) at threads.c:903 #11 0x00007f90c7ffddb2 in GC_inner_start_routine (sb=<value optimized out>, arg=<value optimized out>) at ../pthread_support.c:1153 #12 0x00007f90c7ff7af5 in GC_call_with_stack_base (fn=0xfffffffffffffe00, arg=0x7f90c61bfb8f) at ../misc.c:1323 #13 0x00007f90c7dcaf97 in start_thread () from /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libpthread.so.0 #14 0x00007f90c6f6156d in clone () from /nix/store/s88vdfglm94x7jn0vqm24pqhq460s0c7-glibc-2.9/lib/libc.so.6 Thread 1 (Thread 0x7f90c89bd6f0 (LWP 17980)): #0 scm_ithrow (key=0x707060, args=0x404, noreturn=1) at throw.c:746 #1 0x00007f90c84f00a0 in scm_i_gsubr_apply_list (self=0x707060, args=<value optimized out>) at gsubr.c:316 #2 0x00007f90c8545861 in vm_debug_engine (vp=0x703f00, program=<value optimized out>, argv=<value optimized out>, nargs=<value optimized out>) at vm-i-system.c:605 #3 0x00007f90c84e4b90 in scm_c_with_fluid (fluid=0x6602c0, value=0x4, cproc=0x7f90c84e49e0 <apply_thunk>, cdata=0xc106c0) at fluids.c:382 #4 0x00007f90c8545861 in vm_debug_engine (vp=0x703f00, program=<value optimized out>, argv=<value optimized out>, nargs=<value optimized out>) at vm-i-system.c:605 #5 0x00007f90c853abc5 in scm_c_catch (tag=<value optimized out>, body=<value optimized out>, body_data=<value optimized out>, handler=<value optimized out>, handler_data=<value optimized out>, pre_unwind_handler=0, pre_unwind_handler_data=0x7fff79486100) at throw.c:243 #6 0x00007f90c853ad4e in scm_catch_with_pre_unwind_handler (key=0x707060, thunk=<value optimized out>, handler=0xc10620, pre_unwind_handler=0x204) at throw.c:627 #7 0x00007f90c84f00a0 in scm_i_gsubr_apply_list (self=0x707060, args=<value optimized out>) at gsubr.c:316 #8 0x00007f90c8545ba6 in vm_debug_engine (vp=0x703f00, program=<value optimized out>, argv=<value optimized out>, nargs=<value optimized out>) at vm-i-system.c:689 #9 0x00007f90c8545861 in vm_debug_engine (vp=0x703f00, program=<value optimized out>, argv=<value optimized out>, nargs=<value optimized out>) at vm-i-system.c:605 #10 0x00007f90c84e4b90 in scm_c_with_fluid (fluid=0x6c68e0, value=0x4, cproc=0x7f90c84e49e0 <apply_thunk>, cdata=0x8e80c0) at fluids.c:382 #11 0x00007f90c8545861 in vm_debug_engine (vp=0x703f00, program=<value optimized out>, argv=<value optimized out>, nargs=<value optimized out>) at vm-i-system.c:605 #12 0x00007f90c84d4df3 in scm_dynamic_wind (in_guard=0x8e8280, thunk=0x8e82a0, out_guard=0x8e81c0) at dynwind.c:112 #13 0x00007f90c8545861 in vm_debug_engine (vp=0x703f00, program=<value optimized out>, argv=<value optimized out>, nargs=<value optimized out>) at vm-i-system.c:605 #14 0x00007f90c853d60f in scm_vm_apply (vm=0x6ff1f0, program=0x8e84c0, args=0x404) at vm.c:406 #15 0x00007f90c8545861 in vm_debug_engine (vp=0x703f00, program=<value optimized out>, argv=<value optimized out>, nargs=<value optimized out>) at vm-i-system.c:605 #16 0x00007f90c84d1122 in scm_sys_start_stack (id=0x104, thunk=0x8cfe20) at debug.c:483 #17 0x00007f90c8545ba6 in vm_debug_engine (vp=0x703f00, program=<value optimized out>, argv=<value optimized out>, nargs=<value optimized out>) at vm-i-system.c:689 #18 0x00007f90c853abc5 in scm_c_catch (tag=<value optimized out>, body=<value optimized out>, body_data=<value optimized out>, handler=<value optimized out>, handler_data=<value optimized out>, pre_unwind_handler=0, pre_unwind_handler_data=0x7fff79486c30) at throw.c:243 #19 0x00007f90c853ad4e in scm_catch_with_pre_unwind_handler (key=0x707060, thunk=<value optimized out>, handler=0x8cfe60, pre_unwind_handler=0x204) at throw.c:627 #20 0x00007f90c84f00a0 in scm_i_gsubr_apply_list (self=0x707060, args=<value optimized out>) at gsubr.c:316 #21 0x00007f90c8545861 in vm_debug_engine (vp=0x703f00, program=<value optimized out>, argv=<value optimized out>, nargs=<value optimized out>) at vm-i-system.c:605 #22 0x00007f90c84d1122 in scm_sys_start_stack (id=0x104, thunk=0x8cc0a0) at debug.c:483 #23 0x00007f90c8545861 in vm_debug_engine (vp=0x703f00, program=<value optimized out>, argv=<value optimized out>, nargs=<value optimized out>) at vm-i-system.c:605 #24 0x00007f90c853abc5 in scm_c_catch (tag=<value optimized out>, body=<value optimized out>, body_data=<value optimized out>, handler=<value optimized out>, handler_data=<value optimized out>, pre_unwind_handler=0x7f90c853a590 <scm_handle_by_proc>, pre_unwind_handler_data=0x7fff794871f0) at throw.c:243 #25 0x00007f90c853ad4e in scm_catch_with_pre_unwind_handler (key=0x707060, thunk=<value optimized out>, handler=0xa58fc0, pre_unwind_handler=0x8c5de0) at throw.c:627 #26 0x00007f90c84f00a0 in scm_i_gsubr_apply_list (self=0x707060, args=<value optimized out>) at gsubr.c:316 #27 0x00007f90c8545861 in vm_debug_engine (vp=0x703f00, program=<value optimized out>, argv=<value optimized out>, nargs=<value optimized out>) at vm-i-system.c:605 #28 0x00007f90c84d4df3 in scm_dynamic_wind (in_guard=0xa58120, thunk=0xa58100, out_guard=0xa580e0) at dynwind.c:112 #29 0x00007f90c8545861 in vm_debug_engine (vp=0x703f00, program=<value optimized out>, argv=<value optimized out>, nargs=<value optimized out>) at vm-i-system.c:605 #30 0x00007f90c84db73c in ceval (x=0x8b52c0, env=0x8b5220) at eval.i.c:1136 #31 0x00007f90c84e353a in scm_eval_x (exp=0x89b650, module_or_state=0x804720) at eval.c:4095 #32 0x00007f90c85195ff in scm_shell (argc=2, argv=0x7fff79487ae8) at script.c:771 #33 0x00007f90c84f611f in invoke_main_func (body_data=0x7fff794879e0) at init.c:378 #34 0x00007f90c84d04aa in c_body (d=0x7fff79487910) at continuations.c:318 #35 0x00007f90c853abc5 in scm_c_catch (tag=<value optimized out>, body=<value optimized out>, body_data=<value optimized out>, handler=<value optimized out>, handler_data=<value optimized out>, pre_unwind_handler=0x7f90c8539fc0 <scm_handle_by_message_noexit>, pre_unwind_handler_data=0x0) at throw.c:243 #36 0x00007f90c84d08d7 in scm_i_with_continuation_barrier (body=<value optimized out>, body_data=<value optimized out>, handler=0x7f90c84d04c0 <c_handler>, handler_data=0x7fff79487910, pre_unwind_handler=<value optimized out>, pre_unwind_handler_data=<value optimized out>) at continuations.c:294 #37 0x00007f90c84d0970 in scm_c_with_continuation_barrier (func=<value optimized out>, data=<value optimized out>) at continuations.c:336 #38 0x00007f90c8539972 in scm_i_with_guile_and_parent (func=<value optimized out>, data=<value optimized out>, parent=<value optimized out>) at threads.c:709 #39 0x00007f90c84f60d5 in scm_boot_guile (argc=<value optimized out>, argv=<value optimized out>, main_func=0x1, closure=0x1) at init.c:361 #40 0x0000000000400b50 in main (argc=7368800, argv=0x404) at guile.c:70 --8<---------------cut here---------------end--------------->8--- Hope this helps, Ludo’. ^ permalink raw reply [flat|nested] 12+ messages in thread
* (no subject) 2009-09-28 23:21 ` Bug #27457 (“Threads, mutexes, and critical sections”) Ludovic Courtès @ 2009-09-30 20:59 ` Neil Jerram 2009-10-01 17:21 ` Bug #27457 (“Threads, mutexes, and critical sections”) Ludovic Courtès 2009-10-01 19:45 ` Bug #27457 (“Threads, mutexes, and critical sections”) Ken Raeburn 0 siblings, 2 replies; 12+ messages in thread From: Neil Jerram @ 2009-09-30 20:59 UTC (permalink / raw) To: Ludovic Courtès, Ken Raeburn; +Cc: guile-devel ludo@gnu.org (Ludovic Courtès) writes: > I should have mentioned this one: > http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3185 . > > This is normally somewhat fixed in current BDW-GC CVS, but Guile itself > may have troubles of its own dealing with cancellation. Thanks. I thought already about cancellation, but I couldn't see anything in the test program that would do that. Do you know of anything in that program, or in BDW-GC, that does a pthread_cancel? > The critical section issue should be orthogonal, though. Yes. > Here it is: Thanks, and thanks to Ken also. I've cherry-picked the following branch_release-1-8 fixes. commit 499c43b03225abb8d3af9087b7630d523b74e13a Author: Neil Jerram <neil@ossau.uklinux.net> Date: Thu Mar 5 20:03:33 2009 +0000 Avoid throw from critical section, given invalid sigaction call (This is for a different critical section problem, but which still occurs (prior to this commit) in master.) commit 3009b5d557e1ebfd828fd0de9b1da5abb2f6ec9a Author: Neil Jerram <neil@ossau.uklinux.net> Date: Tue Mar 10 23:55:31 2009 +0000 Fix spurious `throw from within critical section' errors (This is the commit that I hope will fix the errors that you're seeing.) Can you see how the test runs now? Also, can I check my thinking on one other fix, and how it interacts with BDW-GC? commit 2bfcaf2605f8366d8c708c148bde5313b88497e0 Author: Neil Jerram <neil@ossau.uklinux.net> Date: Wed Mar 4 23:45:11 2009 +0000 Lock ordering: don't allocate when in critical section (scm_sigaction_for_thread) With BDW-GC I believe that allocation in a critical section is no longer a problem, specifically because - the stop-the-world mechanism uses signals and sigsuspend - whereas Guile GC used mutexes - and hence there are no concerns about lock ordering - it doesn't matter if there are threads waiting for the critical section when a GC happens, because the signal mechanism will still interrupt them. Is that right? Thanks! Neil ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug #27457 (“Threads, mutexes, and critical sections”) 2009-09-30 20:59 ` (no subject) Neil Jerram @ 2009-10-01 17:21 ` Ludovic Courtès 2009-10-01 21:05 ` (no subject) Neil Jerram 2009-10-01 19:45 ` Bug #27457 (“Threads, mutexes, and critical sections”) Ken Raeburn 1 sibling, 1 reply; 12+ messages in thread From: Ludovic Courtès @ 2009-10-01 17:21 UTC (permalink / raw) To: Neil Jerram; +Cc: Ken Raeburn, guile-devel Hi Neil, Neil Jerram <neil@ossau.uklinux.net> writes: > ludo@gnu.org (Ludovic Courtès) writes: > >> I should have mentioned this one: >> http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3185 . >> >> This is normally somewhat fixed in current BDW-GC CVS, but Guile itself >> may have troubles of its own dealing with cancellation. > > Thanks. I thought already about cancellation, but I couldn't see > anything in the test program that would do that. Do you know of > anything in that program, or in BDW-GC, that does a pthread_cancel? Hmm no, sorry for the confusion. The srfi-18 test this was taken from did use cancellation, though. > I've cherry-picked the following branch_release-1-8 fixes. > > commit 499c43b03225abb8d3af9087b7630d523b74e13a > Author: Neil Jerram <neil@ossau.uklinux.net> > Date: Thu Mar 5 20:03:33 2009 +0000 > > Avoid throw from critical section, given invalid sigaction call > > (This is for a different critical section problem, but which still > occurs (prior to this commit) in master.) Good that you noticed it was missing from ‘master’. (BTW ‘signals.test’ should be changed to GPLv3+ and have a ‘define-module’ clause.) > commit 3009b5d557e1ebfd828fd0de9b1da5abb2f6ec9a > Author: Neil Jerram <neil@ossau.uklinux.net> > Date: Tue Mar 10 23:55:31 2009 +0000 > > Fix spurious `throw from within critical section' errors > > (This is the commit that I hope will fix the errors that you're seeing.) > > Can you see how the test runs now? The abort () is apparently never reached with this patch. It took me some time to understand this: - if (scm_i_critical_section_level) + if (thread->critical_section_level) { fprintf (stderr, "continuation invoked from within critical section.\n"); abort (); Critical sections concern all the threads in guile mode. Thus I would think that the question “are the threads in a critical section?” cannot be answered by looking at a per-thread ‘critical_section_level’. However, it really seems that the intent was really to forbid ‘throw’s when the *current thread* is holding the critical section mutex, so the patch is correct but I find the name ‘critical_section_level’ is slightly misleading. What do you think? > Also, can I check my thinking on one other fix, and how it > interacts with BDW-GC? > > commit 2bfcaf2605f8366d8c708c148bde5313b88497e0 > Author: Neil Jerram <neil@ossau.uklinux.net> > Date: Wed Mar 4 23:45:11 2009 +0000 > > Lock ordering: don't allocate when in critical section (scm_sigaction_for_thread) > > With BDW-GC I believe that allocation in a critical section is no longer > a problem, specifically because > > - the stop-the-world mechanism uses signals and sigsuspend - whereas > Guile GC used mutexes - and hence there are no concerns about lock > ordering > > - it doesn't matter if there are threads waiting for the critical > section when a GC happens, because the signal mechanism will still > interrupt them. > > Is that right? Yes. BTW, rest assured: thanks to libgc we won’t get any Helgrind report! :-) Thanks, Ludo’. ^ permalink raw reply [flat|nested] 12+ messages in thread
* (no subject) 2009-10-01 17:21 ` Bug #27457 (“Threads, mutexes, and critical sections”) Ludovic Courtès @ 2009-10-01 21:05 ` Neil Jerram 0 siblings, 0 replies; 12+ messages in thread From: Neil Jerram @ 2009-10-01 21:05 UTC (permalink / raw) To: Ludovic Courtès; +Cc: Ken Raeburn, guile-devel ludo@gnu.org (Ludovic Courtès) writes: >>> This is normally somewhat fixed in current BDW-GC CVS, but Guile itself >>> may have troubles of its own dealing with cancellation. >> >> Thanks. I thought already about cancellation, but I couldn't see >> anything in the test program that would do that. Do you know of >> anything in that program, or in BDW-GC, that does a pthread_cancel? > > Hmm no, sorry for the confusion. The srfi-18 test this was taken from > did use cancellation, though. OK, thanks for clarifying that. I guess there must be something other than cancellation lurking. > Good that you noticed it was missing from ‘master’. (BTW ‘signals.test’ > should be changed to GPLv3+ and have a ‘define-module’ clause.) Thanks, done. >> commit 3009b5d557e1ebfd828fd0de9b1da5abb2f6ec9a >> Author: Neil Jerram <neil@ossau.uklinux.net> >> Date: Tue Mar 10 23:55:31 2009 +0000 >> >> Fix spurious `throw from within critical section' errors >> >> (This is the commit that I hope will fix the errors that you're seeing.) >> >> Can you see how the test runs now? > > The abort () is apparently never reached with this patch. > > It took me some time to understand this: > > - if (scm_i_critical_section_level) > + if (thread->critical_section_level) > { > fprintf (stderr, "continuation invoked from within critical section.\n"); > abort (); > > Critical sections concern all the threads in guile mode. Thus I would > think that the question “are the threads in a critical section?” cannot > be answered by looking at a per-thread ‘critical_section_level’. That's not the question here. The question is "is _this_ thread in a critical section?" There's no reason (AFAIK) why thread A shouldn't throw while thread B is in a critical section. Note that access to the critical section is controlled by a mutex, not by (scm_i_)critical_section_level. (scm_i_)critical_section_level only exists to catch genuine "throw from critical section" errors. > However, it really seems that the intent was really to forbid ‘throw’s > when the *current thread* is holding the critical section mutex, so the > patch is correct but I find the name ‘critical_section_level’ is > slightly misleading. The tricky detail here is that scm_i_critical_section_mutex is initialized as a recursive mutex, so the implication is that it's possible for a thread to enter the critical section multiple times. Hence we need some kind of "level", instead of just a boolean "in_critical_section". > What do you think? I have no objection to a more intuitive name, if you can suggest one. >> Is that right? > > Yes. Thanks. > BTW, rest assured: thanks to libgc we won’t get any Helgrind report! > :-) I assume you mean because most of the helgrind reports involved the heap_mutex, which no longer exists. Presumably we could still (in theory) get helgrind reports for other mutexes? Regards, Neil ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug #27457 (“Threads, mutexes, and critical sections”) 2009-09-30 20:59 ` (no subject) Neil Jerram 2009-10-01 17:21 ` Bug #27457 (“Threads, mutexes, and critical sections”) Ludovic Courtès @ 2009-10-01 19:45 ` Ken Raeburn 2009-10-01 20:44 ` (no subject) Neil Jerram 1 sibling, 1 reply; 12+ messages in thread From: Ken Raeburn @ 2009-10-01 19:45 UTC (permalink / raw) To: Neil Jerram; +Cc: Ludovic Courtès, guile-devel On Sep 30, 2009, at 16:59, Neil Jerram wrote: > I've cherry-picked the following branch_release-1-8 fixes. With these fixes, indeed, I can't reproduce the problem any more; I left the test program running for over an hour, whereas before it would trigger the problem almost immediately. Thanks! Ken ^ permalink raw reply [flat|nested] 12+ messages in thread
* (no subject) 2009-10-01 19:45 ` Bug #27457 (“Threads, mutexes, and critical sections”) Ken Raeburn @ 2009-10-01 20:44 ` Neil Jerram 0 siblings, 0 replies; 12+ messages in thread From: Neil Jerram @ 2009-10-01 20:44 UTC (permalink / raw) To: Ken Raeburn; +Cc: Ludovic Courtès, guile-devel Ken Raeburn <raeburn@raeburn.org> writes: > On Sep 30, 2009, at 16:59, Neil Jerram wrote: >> I've cherry-picked the following branch_release-1-8 fixes. > > With these fixes, indeed, I can't reproduce the problem any more; I > left the test program running for over an hour, whereas before it > would trigger the problem almost immediately. > Thanks! Great news; thanks for trying and confirming that. Neil ^ permalink raw reply [flat|nested] 12+ messages in thread
* (no subject) @ 2004-10-03 22:32 Karen Ferguson 0 siblings, 0 replies; 12+ messages in thread From: Karen Ferguson @ 2004-10-03 22:32 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1.1: Type: text/plain; charset="iso-5748-8", Size: 401 bytes --] Hi again, Here is Karen Ferguson. I wite you because we are accepting your mortgage application. Our office confirms you can get a $220.000 loÀn for a $352.00 per month payment. Approval process will take 1 minute, so please fill out the form on our website: http://methodic.moneyintelligent.info/j8/o0o.php?jq1=101 Thank you. Best Regards Karen Ferguson First Account Manager [-- Attachment #2: Type: text/plain, Size: 143 bytes --] _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* (no subject)
@ 2002-11-09 8:29 Dirk Herrmann
2002-11-09 20:42 ` Clinton Ebadi
0 siblings, 1 reply; 12+ messages in thread
From: Dirk Herrmann @ 2002-11-09 8:29 UTC (permalink / raw)
Cc: guile-devel
Clinton Ebadi wrote:
> > I don't care how memoization works. I understand there are
> > optimization issues. Optimizing isn't important to me, or
> > I would not use an interpretive language as my "extension
> > language". If you add a disabling mechanism, then you'll
> > have the best of all worlds. You can memoize/optimize to
> > your heart's content, and I'll disable it for my purposes.
> > If that is not practical and Guile becomes, essentially,
> > an semi-compiled language with constraints on where
> > defines may happen, then my goose will be cooked.
>
> Not to mention how Guile wouldn't be Scheme anymore. Why can't code be
> memiozied and compiled incrementally?
First, why wouldn't guile be scheme any more if conditional definitions
are disallowed? They are disallowed by R5RS, so actually, if you
understand "being scheme" as "conforming to R5RS" then currently guile is
not scheme and disallowing conditional definitions will bring it one step
closer to "being scheme" :-)
Second, certainly can code be memoized and compiled incrementally.
However, this would have to be done every time the code was read in again,
since in an expression like (if <condition> (define <foo> <bar)) the value
of <condition> may change every time the code is read in. That is, we
would reduce our possibility to pre-compile code. Pre compiling code,
however, is one of our options to speed up guile's starting time (aside
from optimizing guile's module system...).
Best regards,
Dirk Herrmann
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: (no subject) 2002-11-09 8:29 Dirk Herrmann @ 2002-11-09 20:42 ` Clinton Ebadi 0 siblings, 0 replies; 12+ messages in thread From: Clinton Ebadi @ 2002-11-09 20:42 UTC (permalink / raw) Cc: guile-devel On Saturday 09 November 2002 03:29, Dirk Herrmann wrote: > > Not to mention how Guile wouldn't be Scheme anymore. Why can't code be > > memiozied and compiled incrementally? > > First, why wouldn't guile be scheme any more if conditional definitions > are disallowed? They are disallowed by R5RS, so actually, if you > understand "being scheme" as "conforming to R5RS" then currently guile is > not scheme and disallowing conditional definitions will bring it one step > closer to "being scheme" :-) I was referring to the part where you would have to reload your code if a binding changed and the whole (define define define-private) etc. not working. -- http://unknownlamer.org Truth lies in loneliness When hope is long gone by _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* (no subject)
@ 2002-08-04 16:33 Han-Wen
2002-08-04 18:38 ` Rob Browning
0 siblings, 1 reply; 12+ messages in thread
From: Han-Wen @ 2002-08-04 16:33 UTC (permalink / raw)
Cc: guile-devel
Subject: status: separation of expansion/optimization/memoization/execution
In-Reply-To: <Pine.GSO.4.05.10208022349150.5209-100000@sallust.ida.ing.tu-bs.de>
References: <Pine.GSO.4.05.10208022349150.5209-100000@sallust.ida.ing.tu-bs.de>
X-Mailer: VM 7.05 under Emacs 21.2.1
Reply-To: hanwen@cs.uu.nl
FCC: ~/persoonlijk/Mail/sent
dirk@sallust.ida.ing.tu-bs.de writes:
> Hi folks,
> [ eval hacking ]
I'm just wondering -- Some time ago Keisuke Nishida (sp?) was working on
a byte compiler for GUILE that offered major speedups in many
cases. Is that still being pursued?
--
Han-Wen Nienhuys | hanwen@cs.uu.nl | http://www.cs.uu.nl/~hanwen
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: (no subject) 2002-08-04 16:33 Han-Wen @ 2002-08-04 18:38 ` Rob Browning 0 siblings, 0 replies; 12+ messages in thread From: Rob Browning @ 2002-08-04 18:38 UTC (permalink / raw) Cc: Dirk Herrmann, guile-devel Han-Wen <hanwen@cs.uu.nl> writes: > I'm just wondering -- Some time ago Keisuke Nishida (sp?) was > working on a byte compiler for GUILE that offered major speedups in > many cases. Is that still being pursued? Not at the moment. He had to stop working on that (at least for a while), and I can't recall if he though he'd be able to get back to it. Regardless, I think the general plan was to first get the evaluation process cleaned up a bit and then step back and consider what comes next. There as been discussion of scm->c, jit, lightning-based-jit, gcc-front-end-based[1], and traditional byte compilation. Once the evaluation process better separates memoization and execution from each other and from the other steps (a la Dirk's current work). It should be a lot easier to explore the possibilities. [1] which with the addition of -foptimiize-sibling is now at least one step more likely to be feasible, though perhaps still not the right idea. I'm still not sure that gcc's intermediate language has all the features you'd really need. Interesting related link: http://gcc.gnu.org/frontends.html -- see FLIM -- a realy simple example gcc front end, and Ksi, a compiler from a very thin sexp representation of gcc's intermedate trees to machine code, and Gont a high level language that spits out forms to be processed by Ksi on the back-end. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* (no subject) @ 2002-03-30 16:59 ±è°æÀÏ 0 siblings, 0 replies; 12+ messages in thread From: ±è°æÀÏ @ 2002-03-30 16:59 UTC (permalink / raw) [-- Attachment #1: Type: text/html, Size: 4702 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-11-08 22:21 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-10-14 19:23 (no subject) Tanisha Villalobos -- strict thread matches above, loose matches on Subject: below -- 2009-10-02 9:15 Merging ‘bdw-gc-static-alloc’ Ludovic Courtès 2009-10-02 16:26 ` Andy Wingo 2009-10-23 9:16 ` Ludovic Courtès 2009-10-23 12:57 ` Andy Wingo 2009-11-02 21:44 ` Ludovic Courtès 2009-11-03 20:57 ` (no subject) Neil Jerram 2009-11-05 22:30 ` Merging ‘bdw-gc-static-alloc’ Ludovic Courtès 2009-11-08 22:21 ` (no subject) Neil Jerram 2009-08-10 19:41 i guess we're frozen & stuff Andy Wingo 2009-08-11 11:34 ` Greg Troxel 2009-08-11 13:59 ` Ken Raeburn 2009-08-12 22:41 ` Andy Wingo 2009-09-16 19:00 ` Andy Wingo 2009-09-25 21:59 ` Ken Raeburn 2009-09-26 21:02 ` Ludovic Courtès 2009-09-28 17:22 ` Neil Jerram 2009-09-28 18:48 ` Ludovic Courtès 2009-09-28 22:42 ` Neil Jerram 2009-09-28 23:21 ` Bug #27457 (“Threads, mutexes, and critical sections”) Ludovic Courtès 2009-09-30 20:59 ` (no subject) Neil Jerram 2009-10-01 17:21 ` Bug #27457 (“Threads, mutexes, and critical sections”) Ludovic Courtès 2009-10-01 21:05 ` (no subject) Neil Jerram 2009-10-01 19:45 ` Bug #27457 (“Threads, mutexes, and critical sections”) Ken Raeburn 2009-10-01 20:44 ` (no subject) Neil Jerram 2004-10-03 22:32 Karen Ferguson 2002-11-09 8:29 Dirk Herrmann 2002-11-09 20:42 ` Clinton Ebadi 2002-08-04 16:33 Han-Wen 2002-08-04 18:38 ` Rob Browning 2002-03-30 16:59 ±è°æÀÏ
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).