Fedora 35, with Guile 2.2.7 and libgc 8.0.4)
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Sun, Feb 14, 2021 at 11:35 AM Han-Wen Nienhuys wrote:
> >> Thanks. It turns out my previous fix introduced ABI
> >> breakage, so I reworked it to not change function
> >> signatures or struct sizes. It's also split up in more
> >> parts
On Wed, Feb 10, 2021 at 11:18 PM Thien-Thi Nguyen wrote:
>
>
> () Han-Wen Nienhuys
> () Tue, 9 Feb 2021 09:59:07 +0100
>
>> Thanks. It turns out my previous fix introduced ABI
>> breakage, so I reworked it to not change function
>> signatures or
On Sun, Jan 17, 2021 at 7:37 PM Han-Wen Nienhuys wrote:
> On Sun, Jan 17, 2021 at 12:10 AM Thien-Thi Nguyen wrote:
> >your timing is fortuitous. I just spent the christmas
> >holidays delving into GUILE 1.8's heap expansion strategy and
> >
On Sun, Jan 17, 2021 at 12:10 AM Thien-Thi Nguyen wrote:
>
>
> () Han-Wen Nienhuys
> () Tue, 12 Jan 2021 09:20:55 +0100
>
>your timing is fortuitous. I just spent the christmas
>holidays delving into GUILE 1.8's heap expansion strategy and
>
these days?
I'd be happy to polish it up (ie. add a proper test) for inclusion in
GUILE 1.8.9,
cheers,
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
at statprof.scm:251:4
6.7% #x2212b88
Is there a way to get insight into what these hex addresses (?) mean?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
`(define q "i am Q\n"))
>
> This is very much expected. The macro body contains two side-effect
> free expressions (namely quoted lists) and returns the last one which is
..
> You probably wanted something like
> `(begin (define p ...) (define q ...))
d'oh! I am an idiot.
Thanks,
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
ew (command-and-args . definition)
`(define p "i am P\n")
`(define q "i am Q\n"))
(my-macro-old 1 2)
(my-macro-new 1 2)
(display x1)
(display x2)
(display q)
(display p)
thanks,
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
>
No, I think it's because in some phases of the program, there is a lot of
heap growth, with little garbage generation. This causes frequent
(expensive) GCs that don't reclaim anything.
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
m/lilypond/lilypond/blob/c5ffa540fdbe52486b9575567ede70be575adb47/scm/define-markup-commands.scm#L305
and seeing how the error message changes.
I still don't understand why some code is executed compile time (the
expansion of the markup macro) while other is not (defining the
make-x-markup functi
+lilypond-devel for visibility.
On Sat, Feb 1, 2020 at 10:54 AM Han-Wen Nienhuys wrote:
>
> Here is an example that shows better how things work, and what might
> be the cause of my problems. Is it right that programmatically set
> contents of "current-module&qu
e a documentation bug. Try fiddling with the
> arguments to eval when and see if you can make it work.
>
> --
> Linus Björnstam
>
> On Fri, 31 Jan 2020, at 20:17, Han-Wen Nienhuys wrote:
> > On Fri, Jan 31, 2020 at 7:20 PM Linus Björnstam
> > wrote:
> > >
On Tue, Jan 28, 2020 at 11:41 PM Han-Wen Nienhuys wrote:
> Unfortunately, it looks like the adoption of the BDW GC library caused
> a ~6x slowdown, causing an overall end-to-end slowdown of 50%.
>
> I was wondering if you folks would have tips to further tune GC for
>
:58+0100 2020
[hanwen@localhost lilypond]$ guile2.2 e.scm
Fri Jan 31 20:16:00+0100 2020
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
.
> (inner ,name ,value))
>
> I doubt you can make the old code work in newer guiles, since I doubt any
> scheme is a s lax about expansion time and macro time separation.
> --
> Linus Björnstam
>
> On Wed, 29 Jan 2020, at 00:08, Han-Wen Nienhuys wrote:
sible to attach doc strings to (define-syntax .. )
declarations, and if so, where do they go?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Thu, Jan 30, 2020 at 9:05 AM Han-Wen Nienhuys wrote:
>
> [guile1.8]$ grep -ir define-syntax-rule .
>
> (empty)
>
> I need something that works in GUILE 1.8 too.
>
> this is what I got from David Kastrup:
>
> >Got any comments about macros being sooo yes
y I get this error message?
On Wed, Jan 29, 2020 at 4:06 PM Ricardo Wurmus wrote:
>
>
> Han-Wen Nienhuys writes:
>
> > Some of the lilypond Scheme files do the following:
> >
> >
> > (define decl '())
> > (define (make-var n v) (list "var" n v))
hat support this; can somebody point
me to them? From where I stand, it looks like a huge performance
regression.
On Tue, Jan 28, 2020 at 11:41 PM Han-Wen Nienhuys wrote:
>
> Hi folks,
>
> after a long hiatus I have started getting involved with LilyPond
> again, and one of the
sion foo 1)
(display decl)
(newline)
In GUILE 2.2, this yields
;;; WARNING: compilation of /home/hanwen/vc/lilypond/q.scm failed:
;;; unhandled constant #
What does this error message mean, and what should I do to address the problem?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
won't surface until we start trying to use Guile 2.0 more.
There may be lots of hairiness in the module interface; I sort of made
up functions as I went along, since it was largely undocumented.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
fit?).
I recommend you push a branch to savannah, for everyone to see what is
happening.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
:
- what is the performance impact?
- does BDW GC handle weak references correctly?
- What about various (undoubtedly little used) areas where GC interacts
with the interpreter: port de-allocation, guardians, etc.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Ping?
Han-Wen Nienhuys escreveu:
Ludovic Courtès escreveu:
Yes, fine by me, but no rush. ;-)
Do you mean anything specific by no rush here?
I just meant I'm not gonna do it Right Now but that's fine by me if
somebody else does.
Please see dev/hanwen on savannah.
--
Han-Wen
: installing `build-aux/depcomp'
configure.in:51: required file `config.h.in' not found
configure.in:86: required file `build-aux/ltmain.sh' not found
[EMAIL PROTECTED] guile-x]$ echo $?
1
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Do we have a consensus?
Ludovic Courtès escreveu:
The GH interface was marked as deprecated in
* Explain GH deprecation plan for scm documentation.
Let's really drop it now.
Why? It doesn't cost much to keep it, does it?
--
Han-Wen Nienhuys - [EMAIL PROTECTED
leading to race conditions) when there is no explicit start-thread
call in the code? The program (lilypond) does run through the
regular GUILE boot procedure.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Andy Wingo escreveu:
On Tue 09 Sep 2008 07:58, Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Is there any code in GUILE that would create a thread (possibly
leading to race conditions) when there is no explicit start-thread
call in the code? The program (lilypond) does run through
Ludovic Courtès escreveu:
Hello,
Is anyone against getting rid of `AM_MAINTAINER_MODE'?
If in doubt, see (info (automake) maintainer-mode). :-)
Getting rid of anything that starts with AM_ has my full support.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Ludovic Courtès escreveu:
Hi,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Han-Wen Nienhuys escreveu:
Ludovic Courtès escreveu:
+/*
+ Classic MIT Hack, see e.g. http://www.tekpool.com/?cat=9
+ */
+int scm_i_uint_bit_count(unsigned int u
Ludovic Courtès escreveu:
Hi,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
i686-mingw32-gcc -mms-bitfields -DHAVE_CONFIG_H
-I/home/lilydev/vc/gub/target/mingw/src/guile-1.9.git -I..
-I/home/lilydev/vc/gub/target/mingw/src/guile-1.9.git/lib -I../lib -Wall
-Wmissing-prototypes -g -O2 -MT
* libguile/gc.c (scm_i_gc): Change assert into deprecation warning.
* libguile/private-gc.h (nil): introduce scm_i_last_marked_cell_count,
as a private mechanism for maintaining cell counts. Previous
versions incremented scm_cells_allocated in an inlined function, so
loading dynamic
commits that are identified as
Changes from Arch/CVS synchronization
and
merge from 1.8
I tend to look at development history with gitk. I realize these
commits are from the CVS era, but it makes me loose track of what
is happening where.
--
Han-Wen Nienhuys - [EMAIL PROTECTED
Neil Jerram escreveu:
2008/9/7 Han-Wen Nienhuys [EMAIL PROTECTED]:
I am not using and enhancing GUILE primarily for fun. A large part of
the lilypond architecture in written in it, and performance problems
in GUILE often translate directly to problems in LilyPond. The reason
I delved
code (with pretty linear history graphs and GNU
compliant commit messages!) without a desire to actually ship
anything.
So, what are the goals in this group?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Neil Jerram escreveu:
2008/9/2 Han-Wen Nienhuys [EMAIL PROTECTED]:
If you are doing memq? for something you already know to
somewhere in front of the list [...]
Why would you do that? In two senses:
1. I know memq gives you the tail of the list, but I usually use its
result only
Neil Jerram escreveu:
2008/9/7 Han-Wen Nienhuys [EMAIL PROTECTED]:
OK - I will admit that interpreter/GC hacking is cool, but on the
downside, when I try to do anything, the intertia/resistance I feel in
the community here is a big turnoff for me.
Do you mean regarding releases (as you say
you can understand that I have a somewhat different basic
attitude wrt GUILE development.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
that noone knows
how to deal with.
All this also makes me wonder why there are no Gnucash developers
here, since I recall they actually do use GUILE for a lot of stuff.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Ludovic Courtès escreveu:
Hi,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Ludovic Courtès escreveu:
Note that what we agreed on was to provide ChangeLog-style comments in
the Git log entry, which this patch doesn't have.
Can you explain me exactly what you want and why?
I'm
Ludovic Courtès escreveu:
Hi,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Please check dev/hanwen for changes.
The `HACKING' changes looks good overall, thank you! The complete
description in the commit message should rather be complete
ChangeLog-style description in the commit
, then please go ahead.
Pushed (without changelog entry).
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
of sight.
comments?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
keep looking at it. You have any luck
narrowing things down with Helgrind?
No, there is no consistent lock ordering in Guile at all, so Helgrind gives
1000s of errors.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Ludovic Courtès escreveu:
Hello,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
autoreconf: running: aclocal --force
autoreconf: configure.in: not using Libtool
autoreconf: running: /home/hanwen/usr/pkg/ac/bin/autoconf --force
configure.in:20: error: possibly undefined macro
of memoizing
was supposed to be confluent (ie. duplicate runs would yield independent
results.)
/* The Lookup Car Race
- by Eva Luator
This was added by Marius Vollmer, but at the time, GUILE did not support
real posix threads, so any problem may not have manifested itself before.
--
Han-Wen
to worry about the
file
headers anymore.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
SCM_SETCELL() which overwrites car
and
cdr atomically.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
a 32 bit binary.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
things like that, but it
doesn't seem to be well documented.
Try magit (by Marius Vollmer, our previous overlord). It lets you create
commits by marking individual patch hunks.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Han-Wen Nienhuys escreveu:
The use of scm_gc_mark() outside of GC is fundamentally broken, since it
creates race conditions in the presence of threads.
I was not aware that this was the case.
My impression was that the mark phase is global; it requires all threads
that were in guile mode
, but the changes to ChangeLog ensure
that every cherry pick will need manual conflict resolution.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
,
`master' is left in the previous state, which is better IMO.
'master' in its previous states grows the heap to 600M doing the 1000-fold
version of srfi-18 test I posted. I think it's not a good solution.
Commenting out the assert for x86-64 should yield better behavior.
--
Han-Wen Nienhuys - [EMAIL
you
send out something.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
there is nothing to reclaim.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Han-Wen Nienhuys escreveu:
even the lazy smob case I wrote about here:
http://thread.gmane.org/gmane.lisp.guile.user/6372
I would classify the use of mark bits outside of the mark phase as outside
of the defined API. If you want to have weak pointer semantics, use
a weak hashtable
Ludovic Courtès escreveu:
Hello,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Ludovic Courtès escreveu:
Off the top of my head: incorrect indentation, missing spaces around
brackets, and more importantly comments (see (standards.info)Comments).
The code I went through should not have
it appears in.)
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
am still a bit novice with git,
in that some of the default behaviors for git branches were changed not
too long ago. The nit thing was an attempt at breaking master, but I
forgot to remove it.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Han-Wen Nienhuys escreveu:
Ludovic Courtès escreveu:
Not quite actually: the hell = scm_malloc (...) bit is still broken.
?
BTW, can you please avoid pushing small topic branches like nit and
dev/with-gnulib to Savannah, as we can't distinguish them from big
branches like vm?
Sorry
preconceptions because I also follow LilyPond development, which is
more turbulent, with more mistakes going in at a higher pace, but also more
discussion and more bugfixing going in at a higher pace.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Ludovic Courtès escreveu:
Hi Han-Wen,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Ludovic Courtès escreveu:
is kind of hard to review in a glimpse. Does it just randomly clean
things up (whatever that means---it does not follow the GCS, for
GCS?
GNU Coding Standards, the thing we're
Ludovic Courtès escreveu:
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Running the test suite through valgrind, I get some fishy errors.
So was that fixed by this commit?
commit 51ef99f7fa9fb766fbb48619fc5863ab9914591d
Author: Han-Wen Nienhuys [EMAIL PROTECTED]
Date: Sat Aug 16
is one of the more interesting parts. Only
the evaluator is more funky, but I lack the braincells to deal with that
competently.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
is
cleaned up only once - (on iteration 1000), and remains 'live' after
that, so there may still be some bugs lurking.
BTW2 stress.scm says
(char-set #\.) ;; double-cell
char-sets are smobs and use single cells, AFAICT.
--
Han-Wen Nienhuys - [EMAIL PROTECTED
?
It's not that I see many reviews of your commits on the list passing by.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
software for a living during my 40 hour work week, and don't much time
for GUILE to spare.
If you think you need to roll back this change, please revoke my
commit privilege and sort things out yourself. The garbage collector
isn't that complicated after all.
--
Han-Wen Nienhuys - [EMAIL
Han-Wen Nienhuys escreveu:
I had a look at pulling this change apart, but it is tricky since
many of the changes are interrelated.
If you think you need to roll back this change, please revoke my
commit privilege and sort things out yourself. The garbage collector
isn't that complicated
)) [EMAIL PROTECTED] (or (hashq-ref
thread-exception-handlers ct) (hashq-set! thread-exception-handlers ct (list
initial-handler) #f))
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
ways.
Could someone modify the pre-inst-guile to make sure it always tries
to load locally compiled modules first?
Thanks!
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
with locking errors.
(there are many locks in the code, and no fixed ordering.)
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Ludovic Courtès escreveu:
Hi,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
After switching from the 1.8 branch to master, I get
./autogen.sh: line 22: gnulib-tool: command not found
I'm on Fedora 9. Where do I get gnulib-tool ?
With git-clone git://git.sv.gnu.org/gnulib.git
Ludovic Courtès escreveu:
Hi Han-Wen,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
I've implemented an env var GUILE_MAX_HEAP_SIZE (- some lilypond users
were complaining that running lily on large sets of files keeps
growing the heap forever, leading to trashing).
Of course, the correct
Ludovic Courtès escreveu:
Hi Han-Wen,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
I've implemented an env var GUILE_MAX_HEAP_SIZE (- some lilypond users
were complaining that running lily on large sets of files keeps
growing the heap forever, leading to trashing).
Of course, the correct
Hello,
I've implemented an env var GUILE_MAX_HEAP_SIZE (- some lilypond users were
complaining that running lily on large sets of files keeps growing the heap
forever, leading to trashing).
Please comment on the patch; it's in branch dev/hanwen on sv.git.gnu.org
--
Han-Wen Nienhuys - [EMAIL
is no reason at
all.
Another consideration is being able to do cross builds, and for that one
should avoid AC_TRY_RUN.
Cross builds need a slew of overrides anyway. As long as the macro provides
a way to override from the environment, cross-builds should not be a problem.
--
Han-Wen Nienhuys
is (not) munging my strings?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
might be UTF-x encoded).
What do I use if I want to have guaranteed O(1) indexing -that is- if
I want to manipulate strings of bytes?
How would I read the contents of a binary file without jumping through
encoding hoops?
FWIW, I think ttn's suggestion is an excellent one.
--
Han-Wen
for a byte array
is. Are we expected to do all our 8-bit data manipulations on uniform
vectors or similar?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
the underlying (const char*)
of a string should be internal? If you are writing C++, doing
const char* ptr = scm_i_string_chars(scmval);
string x(ptr);
is the most straightforward and efficient way to create a string.
Using the API incurs an additional malloc, memcpy and free.
--
Han-Wen Nienhuys
quick.
On a related note: how close could this get to executing the C-bindings? The
Guile
interpreter contains lots of C code that could have just as well have been
written in Scheme. It would be cool to drop some of this if there is no
speed penalty?
--
Han-Wen Nienhuys - [EMAIL PROTECTED
-Ssuspect_text -p branch --
the ChangeLog looks like a joke.
* We did have some autogenerated changelogs for a while, but I have
never seen any evidence that they were used.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
of the side-project
to core as well.
IMO Until there is a need, importing random bitrot is a waste of time, and will
confuse newcoming hackers.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Thien-Thi Nguyen escreveu:
() Han-Wen Nienhuys [EMAIL PROTECTED]
() Thu, 27 Mar 2008 11:28:56 -0300
this is a non-issue. You can do the import to a seperate git repo
later, and then do a merge into core. This will add all the history
of the side-project to core as well.
IMO
/ optimization options?
Isn't it be possible to catch SIGSEGV, and check whether it was
caused by overflow?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
memory use explode.
Have you looked at Hans Boehm's GC benchmarks? He has collected
several test cases; it is wise to run any changes through all of the
test cases, so you can make sure you don't accidentally break
performance in one case while fixing something else.
--
Han-Wen Nienhuys - [EMAIL
Hi,
unfortunately, I'm traveling these two weeks, so I have little
opportunity to look at this right now.
2007/9/3, Ludovic Courtès [EMAIL PROTECTED]:
Hi Han-Wen,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Applied, with corrections.
I noticed the (supposedly related) regression compared
])
+gl_PO_BASE([])
This is unrelated.
yes, I know. Too lazy to strip this from the output. But won't apply to CVS.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
Guile-devel mailing list
Guile-devel@gnu.org
http
. If we go this route,
the conversion should be redone; it's not a big deal, it only takes a couple
hours.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org
and file tree-views
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
for solaris (I maintain a half-baked mingw Git version,
I could add solaris too).
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
. That could be the
correct switch for guile -- there is no downside to switching to
subversion relative to CVS.
Frankly, I think it's nuts not to go with a distributed system if
transitioning away from CVS. The only pertinent question is git or
mercurial.
--
Han-Wen Nienhuys - [EMAIL PROTECTED
. This means that
I can make small fixes (eg. a make dist failure) to build a release locally
and merge them back into the repository HEAD later. My releases are
not inconvenienced by large hacks that are pushed to the HEAD.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl
possible with git. Even more so, because you can actually track the
the author (the person writing the patch) separately from the committer
(person having write access to the repository). This makes tracking the
copyright status (ie. who wrote what) of a project much more transparent.
--
Han-Wen
Kevin Ryde escreveu:
I've struck, in 1.8, port-for-each passing a freed cell to its iterator
func. Eg. guile -s foo.scm on
Hi,
Please see the patch attached. Comments welcome.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
diff --git a/libguile/fports.c b/libguile
numbers I didn't know alone.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
1 - 100 of 166 matches
Mail list logo
