One of my old interests has been storing data as s-expressions. But just
"storing" data is kind of useless, unless you can also search through it,
query it. And, from experience, search/query is mostly useless without
typing. Is `(foo (bar baz))` of type `(surname (given-name occupation))`
or is it
I will ponder how to do that, it will take at least several weeks; I'll
file it through the normal guile bug report system. -- linas
On Mon, Aug 5, 2019 at 1:07 PM Mark H Weaver wrote:
> Hi Linas,
>
> Linas Vepstas writes:
> > However -- if one does call `scm_error`
this within guile; my code is
creating threads outside of guile, and launching `scm_eval` in each (and
ignoring the resulting error). This was leading to a crash after 5-10
minutes.
-- Linas
On Wed, Jul 17, 2019 at 10:52 PM Linas Vepstas
wrote:
> Oh, I get it. I think the bug is this: VM_D
t_callee_vcode (scm_thread *thread)
vp->ip = SCM_FRAME_VIRTUAL_RETURN_ADDRESS (vp->fp);
+ if (vp->unused) { vp->unused = 0; return 0; }
scm_error (scm_arg_type_key, NULL, "Wrong type to apply: ~S",
scm_list_1 (proc), scm_list_1 (proc));
}
On Wed, Jul 17, 2019 at
Seem to be narrowing it down ... or at least, I have more details ...
On Wed, Jul 17, 2019 at 4:44 PM Linas Vepstas
wrote:
>
>
> On Wed, Jul 17, 2019 at 12:49 PM Mark H Weaver wrote:
>
>> Hi Linas,
>>
>> > Investigating the crash with good-old printf's
On Wed, Jul 17, 2019 at 12:49 PM Mark H Weaver wrote:
> Hi Linas,
>
> > Investigating the crash with good-old printf's in libguile/vm.c produces
> > a vast ocean of prints ... that should have not been printed, and/or
> should
> > have been actual errors, but somehow were not handled by scm_error
x7efcd152baa0
sp_min=0x7efcd152b888
stack_lim=0x7efcd152b000
duuude wrong type to apply!
The addresses all look healthy. I also added a guard-word, looking
for memory corruption, but none was found. Next up: decoding the
SCM by hand, and figuring out why it's there.
-- Linas
On Sun, Jul 14,
=0x2965ca0) at ../../libguile/symbols.c:244
The parallelism is low because of this one lock. This appears to be the
primary bottleneck for my workload.
-- Linas
On Sun, Jul 14, 2019 at 5:03 PM Linas Vepstas
wrote:
> Below was for
> guile (GNU Guile) 2.9.2.14-1fb399
>
> --linas
>
Below was for
guile (GNU Guile) 2.9.2.14-1fb399
--linas
On Sun, Jul 14, 2019 at 4:59 PM Linas Vepstas
wrote:
>
> So, here's my next installment on using guile-2.9.2. The first installment
> said that I'd piled up CPU-months of guile 2.9.2 experience without any
>
So, here's my next installment on using guile-2.9.2. The first installment
said that I'd piled up CPU-months of guile 2.9.2 experience without any
crashes. Well, now, a different workload crashes in minutes. Below is a
highly simplified, edited gdb session -- it crashes because it unexpectedly
abo
Hi Mark,
Sorry for the late reply; my email client mananged to hide your email where
I won't see it. I need to fix this.
On Thu, Jun 6, 2019 at 11:28 PM Mark H Weaver wrote:
>
> You'll need to look at the stack frames on the Scheme stack. It can be
> done from GDB if necessary, but it might be
I'm trying to understand how scm_jit_enter_mcode leads to
scm_timed_lock_mutex ... I want to know who is attempting to lock, and why
... and how to work around this...
Background: par-for-each works poorly for my app, I want to understand why.
Specifically, how par-for-each and n-par-for-each work
I've put in a cumulative of 36 hours guile-2.9.2 multi-threaded stress
testing on two different OS/compiler/glibc combinations, and have seen
exactly zero crashes or hangs so far. So it's perfect. Sorry for earlier
confusion. -- linas
On Sun, May 26, 2019 at 11:40 PM Linas Veps
2.9.2 is crash
free (for the last 6 hours) on one os/compiler/glibc combination, I have to
cross-check on another.
--linas
On Sun, May 26, 2019 at 8:40 AM Linas Vepstas
wrote:
> Hi Andy,
>
> Thanks! I just tried out the master branch of guile in git (the one
> tagged v2.9.2). It now
I haven't
tried to dig deeper yet.
-- Linas
On Thu, May 23, 2019 at 2:28 PM Andy Wingo wrote:
> Hi!
>
> On Thu 06 Dec 2018 06:21, Linas Vepstas writes:
>
> > After sending the email below, I scanned the guile-devel archives,
> > and I see Thomas Morley talking a
ses of hacks and ick and
needless complexity and confusing confusion.)
-- Linas
On Wed, Dec 5, 2018 at 9:56 PM Linas Vepstas wrote:
>
> So I pulled guile-2.9.1(beta) today, and gave it a spin. Looks
> good/great! One bug -- some crazy multithreading bug,
> reported as #33641
>
>
So I pulled guile-2.9.1(beta) today, and gave it a spin. Looks
good/great! One bug -- some crazy multithreading bug,
reported as #33641
My use case: guile calling C++ code, which calls guile, which
calls C, ad nauseum. I have some 133 unit tests, of which
maybe 3/4ths tweak guile in some way. All
Sorry for the very late reply,
I just applied these patches, and hope to upload a new version today,
if all goes well.
--linas
On Tue, Apr 28, 2015 at 8:23 AM, 宋文武 wrote:
> Hi, Guilers!
>
> I'd like to package guile-dbi and guile-dbd-* and artanis finally for
> GNU Guix. What's the state of gu
Follow-up Comment #13, bug #24867 (project guile):
To answer my own question:
-- compile test case below, as:
cc define-race.c -lpthread -lguile-2.0 -I/usr/include/guile/2.0
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x75d44700 (LWP 7601)]
0x77243bc9 in
Follow-up Comment #12, bug #24867 (project guile):
Sooo .. is this bug fixed in guile-2.0.5 or 2.0.9?
Because I'm currently staring at the five-year-old work-around for this bug,
wondering if I should remove it or not. It's definitely a bottle-neck for my
app (natural language processing for open
Thanks Neil !
--linas
On 22 March 2010 14:00, Andy Wingo wrote:
> Hi Peter (& Neil & co),
>
> On Mon 22 Mar 2010 09:10, Peter Brett writes:
>>
>> We get people coming to the gEDA user mailing list on a regular basis
>> saying, "Where can I find a version of gEDA for Windows?" and the
>> Windows builds we've put out ha
hopefully shed light on the matter.
-- linas
-- Forwarded message --
From: Joel Pitt
Date: 22 February 2010 20:43
Subject: Re: [opencog-dev] osx port status
To: linasveps...@gmail.com
Cc: opencog-develop...@googlegroups.com
On Mon, Jan 25, 2010 at 5:02 PM, Linas Vepstas wrote:
FYI,
I just tripped over
http://en.wikipedia.org/wiki/Comparison_of_application_virtual_machines
and noticed that guile-1.9 is notable in its absence
from the list... For the point of view of good advertising
for guile, and drumming up new users/maintainers, it might
be good to get listed there.
2009/12/16 Ludovic Courtès :
> Hi Linas,
>
> Linas Vepstas writes:
>
>> I have a new feature request -- it would be useful, in a variety of
>> situations,
>> to be able to provide an opaque (void *) pointer when calling make_gsubr,
>> and then getting
2009/12/15 Ludovic Courtès :
> Changes since the 1.9.5 pre-release:
> *** Simplify representation of primitive procedures
>
> It used to be that there were something like 12 different typecodes
> allocated to primitive procedures, each with its own calling convention.
> Now there is only one,
2009/12/11 Mike Gran :
> I think I prefer that the coder take the responsibility of calling
> setlocale, but, I only think that because it is how C works. I'm used
> to that convention.
>
OK works for me.
--linas
Hi,
I'm experiencing trouble loading a module in guile-1.9.5
I maintain the guile-dbi module at http://home.gna.org/guile-dbi/
and am having trouble getting guile-1.9.5 to find the module:
$ /usr/local/bin/guile
Guile Scheme interpreter 0.5 on Guile 1.9.5
Copyright (C) 2001-2008 Free Software Fo
2009/12/6 Mike Gran :
>
>> > need to call (setlocale LC_ALL "")
>
> But for Guile to store characters as codepoints, declaring a locale
> pretty much a requirement now.
Would it make sense to add (setlocale LC_ALL "") to some default,
e.g. boot-9.scm ?
--linas
2009/12/6 Mike Gran :
>> From: Linas Vepstas
>
>
>> Then, from the guile prompt, I can evaluate the following:
>>
>> (new-node "てみました。")
>>
>> and get the output "The name is てみました。"
>>
>>
>> However, in guile-1.
Hi,
I seem to see either a regression in guile-1.9.5 with regard
to UTF-8 strings, or at least some sort of incompatible change.
In guile-1.8.6, I am able to do the following:
SCM new_node (SCM sname)
{
char * cname = scm_to_locale_string(sname);
printf ("The name is %s\n", cname);
f
2009/11/29 Ludovic Courtès :
> Hi,
>
> Linas Vepstas writes:
>
>> --- libguile/tags.h.orig 2009-11-28 19:18:36.0 -0600
>> +++ libguile/tags.h 2009-11-28 19:18:52.0 -0600
>> @@ -110,7 +110,7 @@
>> /* This is the default, which provides a
2009/11/28 Linas Vepstas :
> 2009/11/17 Ludovic Courtès :
>> We are pleased to announce GNU Guile release 1.9.5.
>
> Now I'm getting a crash.
>
> third crashes with following stack trace:
>
> Program received signal SIGPWR, Power fail/restart.
I retract this b
2009/11/17 Ludovic Courtès :
> We are pleased to announce GNU Guile release 1.9.5.
Now I'm getting a crash.
guile-1.9..5 built with gc-7.1, and running three threads:
one thread is sleeping
another thread is waiting on select()
third crashes with following stack trace:
Program received signal S
2009/11/17 Ludovic Courtès :
> We are pleased to announce GNU Guile release 1.9.5.
FWIW, it appears that guile-1.9.5 does not work with the default
bdw-gc in ubuntu/debian, which is gc-6.8 -- I got the crash below
downloading, compiling, installing gc-7.1 seems to fix the
problem.
BTW, I am vagu
2009/11/28 Ludovic Courtès :
> Hi Linas,
>
> Linas Vepstas writes:
>
>> error: non-local function ‘static*
>> opencog::SchemeSmob::ss_incoming_set(*)’ uses
>> anonymous type
>
> Lilypond is written in C++ and... (looks at the logs...) ... it has
> the sa
Hi Ludo
2009/11/17 Ludovic Courtès :
> We are pleased to announce GNU Guile release 1.9.5.
I just tried 1.9.5 today, and am getting compile errors in
my app, which I did not get in 1.8.6 or 1.9.0 :
error: non-local function ‘static*
opencog::SchemeSmob::ss_incoming_set(*)’ uses
anonymous type
a
2009/8/15 Ludovic Courtès :
> ** Incomplete support for Unicode characters and strings
>
> Internally, strings are now represented either in the `latin-1'
> encoding, one byte per character, or in UTF-32, with four bytes per
> character.
Will this eventually move to UTF8? European languages t
FYI,
I've been running guile-1.9.0 for a while, and recently saw the error message
warning: stack count incorrect!
print out on stdout. I greped for it and found:
libguile/stacks.c: scm_puts ("warning: stack count incorrect!\n",
scm_current_error_port ());
I'm not sure what triggered
2009/6/21 Andy Wingo :
> Took me a little while to understand it, but it seems the patch is
> right. I committed and pushed it to master. Linas, can you try again?
Yes, that fixes it for me.
--linas
2009/6/20 Andy Wingo :
> On Sat 20 Jun 2009 05:00, Linas Vepstas writes:
>
>> Running r6rs-ports.test
>> /bin/sh: line 4: 7268 Segmentation fault ${dir}$tst
>> FAIL: check-guile
>
> A few more things you could try, in addition to what Neil and Ludovic
2009/6/19 Ludovic Courtès :
> We are pleased to announce GNU Guile release 1.9.0.
FYI,
'make check' fails for me, with the blow. Should I ignore
this, or dig into it?
--linas
Everything before the below seems to have passed.
Then...
Running alist.test
Running and-let-star.test
Running arbiters
2009/6/19 Ludovic Courtès :
> We are pleased to announce GNU Guile release 1.9.0.
...
> provide
> feedback to `guile-de...@gnu.org'.
Hmm. 'libunistring' is so new that not even debian
has a package for it. Its also labelled as 'alpha'.
You sure you want to/need to have a dependency on this?
--li
2009/3/26 Neil Jerram :
>
> - and that scm_c_eval_string consists of reading (=> symbol lookup)
> followed by evaluation (=> module obarray lookup), and that each
> scm_c_eval_string call is fast enough to be completed well within one
> time slice.
One way to stress test such situations is to call
2009/3/26 Neil Jerram :
> Linas Vepstas writes:
>
>> I reviewed patch2 as best I could,
>
> Thanks!
>
>> it looks to me like new_bucket is never released.
>> I assume that the scm_acons did a malloc, but
>> maybe not
>
> Yes, but the garbage collec
2009/3/25 Neil Jerram :
> #2 makes the symbols hash thread-safe, and it appears that this
> completely fixes the define-race problem.
I reviewed patch2 as best I could, but I'm cross-eyed
cause its late at night, and I don't know guile internals
well. So I'm not sure my review means much. Howev
2009/3/25 Neil Jerram :
> Linas Vepstas writes:
>
>> Well, once you identify the section that needs locking,
>> you'll want to use an rwlock instead of a mutex. The
>> rwlock (pthread_rwlock_rdlock) allows multiple
>> simultaneous readers. The writer
2009/3/11 Neil Jerram :
> Neil Jerram writes:
>
>> #
>> #
>> ERROR: ERROR: Unbound variable: x1-100499
>> Unbound variable: define
>> ERROR: Unbound variable: x4-100596
>> ERROR: Unbound variable: define
>> ERROR: Unbound variable: define
>> ERROR: Unbound variable: define
>> guile-define test cas
2009/3/6 Andy Wingo :
> Hi Linas,
>
> On Thu 05 Mar 2009 22:56, Linas Vepstas writes:
>
>> Perhaps I'm naive, perhaps some naming convention
>> could be used to indicate that SCM_OUT_OF_RANGE
>> will never return? None of the functions in the call stack
>&g
2009/3/5 Neil Jerram :
> Linas Vepstas writes:
>
>> I don't understand the patch.
>>
>> libguile/scmsigs.c has a SCM_CRITICAL_SECTION_START
>> at line 339, which seems to be balanced by
>> SCM_CRITICAL_SECTION_END;
>> at lines 442 and 461, right bef
2009/3/5 Neil Jerram :
>> Yes, it's an unrelated bug. All of the places that raise errors (and
>> so exit non-locally) should exit the critical section first.
>
>> You're absolutely right. I'll leave this part out, and generate a
>> separate patch for it.
>
> Here's the separate patch...
Err, OK
2009/3/5 Neil Jerram :
>> Yes, it's an unrelated bug. All of the places that raise errors (and
>> so exit non-locally) should exit the critical section first.
>
>> You're absolutely right. I'll leave this part out, and generate a
>> separate patch for it.
>
> Here's the separate patch...
Looks g
2009/3/4 Neil Jerram :
> Here's another lock ordering fix. (For 1.8.x at least, I haven't
> checked if it's relevant to master yet.)
I skimmed it quickly, looks reasonable, except for this:
else
- SCM_OUT_OF_RANGE (2, handler);
+ {
+ SCM_CRITICAL_SECTION_END;
+
Hi,
2009/3/2 Mitchell Wand :
> I am pleased to officially announce the results of the election for the
> Scheme Language Steering Committee.
Thanks to all who voted. I'm not familiar with the work
of the steering committee, and so abstained; however,
as a scheme user, I am very concerned about i
2009/2/11 Neil Jerram :
> Linas Vepstas writes:
>
>> Err, sort of, yes, unless I misunderstand. Guile 1.8 makes
>> a certain basic assumption that is splattered throughout
>> the code; it rather intentionally re-orders the order in which
>> one of the locks is t
2009/2/11 Neil Jerram :
> I've started working through the lock ordering and threading issues
> that we have. My plan is (with 1.8.x)
>
> - first to address problems reported by helgrind (since I think we
> should take advantage of external tools before adding debug code to
> Guile internally)
>
2009/1/16 :
> Neil Jerram wrote:
>> scm_init_guile has always been a bit problematic, as it requires lots
>> of heuristic and OS-dependent code to try to determine where the base
>> of the stack is. It's never been formally deprecated, but we have
>> always advised people to use scm_boot_gu
I feel obligated to respond, having made all sorts of noise.
2009/1/15 Neil Jerram :
> whether people think that scm_init_guile is really needed.
kill it. there seem to be perfectly adequate ways of
living without it. Unfortunately, the current documentation
describing how to use guile with thr
cal section
check, for only for the current thread.
Signed-off-by: Linas Vepstas
---
libguile/throw.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: guile-1.8.6/libguile/throw.c
===
--- guile-1.8.6.orig
The scm_makfrom0str routie is deprecated, don't use it.
Signed-off-by: Linas Vepstas
---
libguile/debug-malloc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: guile-1.8.6/libguile/debug-malloc.c
===
---
Is it "safe" or "legal" to use define in multiple threads?
I am currently looking at an infinite loop in guile, it looks
like there's a pair with cdr pointing to itself. The pair is
a hashtable bucket. I'm reading through hashtab.c
and see no locking at all, and so it seems probable that
this cir
2008/11/15 Neil Jerram <[EMAIL PROTECTED]>:
> 2008/11/11 Ludovic Courtès <[EMAIL PROTECTED]>:
>> BTW, we need to consider releasing 1.8.6 one of these days! ;-)
>
> Yes. Do we have any particular more things to get into this? (I
> don't think I have anything.)
I'm seeing frequent and wide-spre
2008/11/13 Andy Wingo <[EMAIL PROTECTED]>:
> For my part I apologize for not having the cycles
Fine, I'm hacking around it for now, but would like to see
something for 1.8.6.
> On Thu 13 Nov 2008 05:56, "Linas Vepstas" <[EMAIL PROTECTED]> writes:
>
>>
ly in time for guile-1.8.6!
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
---
libguile/threads.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
Index: guile-1.8.5/libguile/threads.c
===
2008/11/12 Linas Vepstas <[EMAIL PROTECTED]>:
> Today, I got a new crash. I have multiple threads, which
> are doing nothing but a bunch of define's, in parallel.
> (They're loading scheme code from various files).
Studying the code just a little bit more, this looks l
2008/11/11 Andy Wingo <[EMAIL PROTECTED]>:
>> Any ideas for binary compatibility for the "micro" revisions?
>
> I think it needs to be guaranteed.
>
>> I recently discovered that a library compiled against 1.8.3
>> would core dump when used with an application compiled
>> against 1.8.5.
Ludovic a
2008/11/10 Neil Jerram <[EMAIL PROTECTED]>:
>
> I also think it will help us manage API incompatibilities better. I
> think our default position from now on should be to maintain
> source-level (API) compatibility, but it is inevitable that there will
> be exceptions to this.
Any ideas for binary
67 matches
Mail list logo
