From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Panicz Maciej Godek Newsgroups: gmane.lisp.guile.user Subject: Re: guile-2.0 on mingw: the sequel Date: Tue, 27 Aug 2013 23:51:16 +0200 Message-ID: References: <83vc2wj4hz.fsf@gnu.org> <83li3siues.fsf@gnu.org> <838uzrioqr.fsf@gnu.org> <83mwo5hjut.fsf@gnu.org> <87zjs5aeps.fsf@tines.lan> <83li3phdcp.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b3a8a8e52dddc04e4f4df20 X-Trace: ger.gmane.org 1377640433 4344 80.91.229.3 (27 Aug 2013 21:53:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Aug 2013 21:53:53 +0000 (UTC) Cc: "guile-user@gnu.org" To: Eli Zaretskii Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Aug 27 23:53:52 2013 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VERCx-0001jx-3C for guile-user@m.gmane.org; Tue, 27 Aug 2013 23:53:51 +0200 Original-Received: from localhost ([::1]:58898 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VERCw-0006LG-Bc for guile-user@m.gmane.org; Tue, 27 Aug 2013 17:53:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VERAW-0003tf-DE for guile-user@gnu.org; Tue, 27 Aug 2013 17:51:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VERAT-0001W6-OB for guile-user@gnu.org; Tue, 27 Aug 2013 17:51:20 -0400 Original-Received: from mail-vb0-x236.google.com ([2607:f8b0:400c:c02::236]:39997) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VERAT-0001W1-Iq; Tue, 27 Aug 2013 17:51:17 -0400 Original-Received: by mail-vb0-f54.google.com with SMTP id q14so3602767vbe.13 for ; Tue, 27 Aug 2013 14:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HJehjMXwxgvmH4zIUUdTc3TxL//sPSLjmXjEmAYOwyI=; b=oPo55k/k5a1t9aCBY0/XFASmZI+Hyq+/wchv8ILVZnJSLMZngydQl5bXzL7L2uU1vG 8Cwaf4YXIYypZ6M0oLXgSYDCxRC74fE1+/JAX5eMjphyl7PcelwO8ciYsjAMUAjGG7Gp HkT6XqWrMZPCsJahuHLnxujA50PBoHaHeePFpucGjumumdNYWBnqcVB6JQKCvpdK2Z9A MxvJHfmLdpzXJy8Xt3PGp2j2AawI0vh0YUCtnng0dxdtMXHw6OUP2Z6HTqnmJ+YZTSio C1yulgDN/WW0LXOu79cJKap8FEBPEtPRApp2/l1TIPQSHw/vgzozVrpcwBSwd6tcw1md e3/g== X-Received: by 10.220.88.13 with SMTP id y13mr10387877vcl.20.1377640276743; Tue, 27 Aug 2013 14:51:16 -0700 (PDT) Original-Received: by 10.221.45.135 with HTTP; Tue, 27 Aug 2013 14:51:16 -0700 (PDT) In-Reply-To: <83li3phdcp.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400c:c02::236 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:10727 Archived-At: --047d7b3a8a8e52dddc04e4f4df20 Content-Type: text/plain; charset=ISO-8859-1 Hi, firstly -- thanks a lot for the efforts for straightening the matters. I'm having a busy time right now, but I will try to apply your solution ASAP, and so I need you to know how much I appreciate it! > > > I guess you didn't configure without threads on GNU/Linux, did you? > > > If not, I suggest to try that, my impression is that Guile without > > > threads is not used too much on Posix platforms. > > > > Hydra, a continuous integration system, runs Guile's "make check" with > > threads disabled on several POSIX platforms, so there's no need for > > Panicz to do this test. > > Sorry, I disagree. "make check" is not the issue here: Guile passes > it on my machine with flying colors (see my reports back then). And > yet a simple program shown by Panicz aborts due to "stack overflow". > I was suggesting to configure Guile on GNU/Linux without threads and > run that same program: perhaps it will also fail. > So I eventually tried that (after having set up a virtual box especially for that purpose), and everything went smoothly -- the "hello" message was displayed without any complaints, despite the lack of threads. In the meantime I've been still trying to build guile+bdw-gc with thread support, and to spot the exact place which causes the error message to pop out, but it's terribly slow (all the components of libguile and guile.exe get rebuilt from scratch, in spite of the fact that the error occurs at the guile-procedures.texi generation stage), and I've been just placing some output messages here and there throughout procedures in libgc/win32_threads.c (I wonder if there's any way to configure the program, whether it be libgc or guile, so that it would print the C backtrace when the popup appears) Best regards, M. --047d7b3a8a8e52dddc04e4f4df20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
firstly -- thanks a lot for the efforts for straightening th= e matters.
I'm having a busy time right now, but I will try t= o apply your
solution ASAP, and so I need you to know how much I appreciate it!
=A0
> > I guess you didn't configure without threads on GNU/Linux, di= d you?
> > If not, I suggest to try that, my impression is that Guile withou= t
> > threads is not used too much on Posix platforms.
>
> Hydra, a continuous integration system, runs Guile's "make ch= eck" with
> threads disabled on several POSIX platforms, so there's no need fo= r
> Panicz to do this test.

Sorry, I disagree. =A0"make check" is not the issue here: G= uile passes
it on my machine with flying colors (see my reports back then). =A0And
yet a simple program shown by Panicz aborts due to "stack overflow&quo= t;.
I was suggesting to configure Guile on GNU/Linux without threads and
run that same program: perhaps it will also fail.

So I eventually tri= ed that (after having set up a virtual box especially
for that purpose), and everything went smoothly -- the "hel= lo" message
was displayed without any complaints, despite th= e lack of threads.

In the meantime I've been still trying to build guile+bdw-= gc with
thread support, and to spot the exact place whic= h causes the error
message to pop out, but = it's terribly slow (all the components of
libguile and guile.exe get rebuilt from scratch, in spite of the fact
=
that the error occurs at the guile-procedures.te= xi generation stage),
and I've been jus= t placing some output messages here and there
throughout procedures in libgc/win32_threads.c (= I wonder if there's
any way to configur= e the program, whether it be libgc or guile,
=A0so that it would print the C backtrace when the popup appears)

Best regards,
M.
--047d7b3a8a8e52dddc04e4f4df20--