* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Johannes Schindelin @ 2007-09-07 10:21 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <a1bbc6950709061721r537b153eu1b0bb3c27fb7bd51@mail.gmail.com>
Hi,
On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
> Anyway I don't mean to start a religious C vs. C++ war.
You have a very strange way of not meaning to start a C vs. C++ war.
> It's a matter of beliefs and as such pointless.
No, it's not. As has been shown by some very good _arguments_. Once you
have facts to back up your claims, it is not any belief any longer.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-svn: remove --first-parent, add --upstream
From: Lars Hjemli @ 2007-09-07 10:13 UTC (permalink / raw)
To: Peter Baumann; +Cc: Eric Wong, Junio C Hamano, git
In-Reply-To: <20070907084352.GD4538@xp.machine.xx>
On 9/7/07, Peter Baumann <waste.manager@gmx.de> wrote:
> lets reset 'trunk' to its state before the merge and
> 'branch1' to the merge commit, before fixing the bug in 'branch1'.
>
> a-b-c-d-e trunk
> \ \
> \ -x-y m branch1
Yeah, this would certainly not be handled correctly by dcommit using
--first-parent (but it could be handled by (a correct implementation
of) --upstream).
Thanks for the example, I had a feeling something like this could
occur. So I guess I'll have another go at --upstream this weekend.
[btw: could you please stop messing with 'Mail-Followup-To:'? When
replying to your mail, I don't want everyone _except_ you in the 'To:'
header...]
--
larsh
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Johannes Schindelin @ 2007-09-07 10:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Nix, Steven Grimm, Linus Torvalds,
Git Mailing List
In-Reply-To: <7vk5r3adlx.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 6 Sep 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 5 Sep 2007, Junio C Hamano wrote:
> >
> >> @@ -20,6 +20,7 @@ static const char builtin_gc_usage[] = "git-gc [--prune] [--aggressive]";
> >>
> >> static int pack_refs = 1;
> >> static int aggressive_window = -1;
> >> +static int gc_auto_threshold = 6700;
> >
> > Please don't do that.
> >
> > When you share objects with another git directory, git-gc --auto can
> > get rid of the objects when some objects go away in the referenced
> > repository.
>
> I thought the whole point of "gc --auto" was to have something
> that does not lose/prune any objects, even the ones that do not
> seem to be referenced from anywhere. That is why invocations of
> "git gc --auto" do not say --prune as you saw the second patch,
> and the repack command "gc --auto" runs is "repack -d -l"
> instead of "repack -a -d -l", which means that it does run
> git-prune-packed after repacking but not git-prune.
>
> Maybe I am missing something...
No, _I_ missed the fact that no pack is rewritten...
Sorry for the line noise,
Dscho
^ permalink raw reply
* Re: [PATCH] git-svn: fix "Malformed network data" with svn:// servers
From: Eric Wong @ 2007-09-07 10:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, 430091
In-Reply-To: <20070907073424.GA16468@mayonaise>
Eric Wong <normalperson@yhbt.net> wrote:
> We have a workaround for the reparent function not working
> correctly on the SVN native protocol servers. This workaround
> opens a new connection (SVN::Ra object) to the new
> URL/directory.
>
> Since libsvn appears limited to only supporting one connection
> at a time, this workaround invalidates the Git::SVN::Ra object
> that is $self inside gs_fetch_loop_common(). So we need to
> restart that connection once all the fetching is done for each
> loop iteration to be able to run get_log() successfully.
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
Actually, drop this for now. Seems to cause the SVN to block
when doing do_switch() again...
--
Eric Wong
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Andreas Ericsson @ 2007-09-07 9:41 UTC (permalink / raw)
To: Walter Bright; +Cc: git
In-Reply-To: <fbr2iv$ugg$1@sea.gmane.org>
Walter Bright wrote:
> Wincent Colaiuta wrote:
>> Git is all about speed, and C is the best choice for speed, especially
>> in context of Git's workload.
>
> I can appreciate that. I originally got into writing compilers because
> my game (Empire) ran too slowly and I thought the existing compilers
> could be dramatically improved.
>
> And technically, yes, you can write code in C that is >= the speed of
> any other language (other than asm). But practically, this isn't
> necessarily so, for the following reasons:
>
> 1) You wind up having to implement the complex, dirty details of things
> yourself. The consequences of this are:
>
> a) you pick a simpler algorithm (which is likely less efficient - I
> run across bubble sorts all the time in code)
>
> b) once you implement, tune, and squeeze all the bugs out of those
> complex, dirty details, you're reluctant to change it. You're reluctant
> to try a different algorithm to see if it's faster. I've seen this
> effect a lot in my own code. (I translated a large body of my own C++
> code that I'd spent months tuning to D, and quickly managed to get
> significantly more speed out of it, because it was much simpler to try
> out different algorithms/data structures.)
>
I haven't seen this in the development of git, although to be fair, you
didn't mention the number of developers that were simultaneously working
on your project. If it was you alone, I can imagine you were reluctant to
change it just to see if something is faster.
Opensource projects with many contributors (git, linux) work differently,
since one or a few among the plethora of authors will almost always be
a true expert at the problem being solved.
The current pack-format and how it's read is one such example. It was
done once, by the combined efforts of Linus and Junio (this is all off
the top of my head and I cba to go looking up the details, so bear with
me if there are errors). Linus and Junio are both very good C-programmers,
but the handling of packfiles was not what you'd call their specialty.
Along came Nicolas Pitre, another excellent C programmer, who probably
has done some similar work before. He constructed a better algorithm,
eventually resulting in the ultimate performance win with a net gain
in both time and size (gj, Nicolas).
The point is that, given enough developers, *someone* is bound to
find an algorithm that works so well that it's no longer worth
investing time to even discuss if anything else would work better,
either because it moves the performance bottleneck to somewhere else
(where further speedups would no longer produce humanly measurable
improvements), or because the action seems instantanous to the user
(further improvements simply aren't worth it, because no valuable
resource will be saved from it).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Pierre Habouzit @ 2007-09-07 9:41 UTC (permalink / raw)
To: Walter Bright; +Cc: git
In-Reply-To: <fbqmdu$udg$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2814 bytes --]
On Fri, Sep 07, 2007 at 05:09:26AM +0000, Walter Bright wrote:
> Linus Torvalds wrote:
> >And if you want a fancier language, C++ is absolutely the worst one to
> >choose. If you want real high-level, pick one that has true high-level
> >features like garbage collection or a good system integration, rather
> >than something that lacks both the sparseness and straightforwardness of
> >C, *and* doesn't even have the high-level bindings to important
> >concepts. IOW, C++ is in that inconvenient spot where it doesn't help
> >make things simple enough to be truly usable for prototyping or simple
> >GUI programming, and yet isn't the lean system programming language that
> >C is that actively encourags you to use simple and direct constructs.
>
> The D programming language is a different take than C++ has on growing C.
> I'm curious what your thoughts on that are (D has garbage collection,
> while still retaining the ability to directly manage memory). Can you
> enumerate what you feel are the important concepts?
Well, to me D has two significant drawbacks to be "ready to use". The
first one is that it doesn't has bit-fields. I often deal with bit-fields
on structures that have a _lot_ of instances in my program, and the
bit-field is chosen for code readability _and_ structure size efficiency.
I know you pretend that using masks manually often generates better
code. But in my case, speed does not matter _that_ much. I mean it does,
but not that this micro-level as access to the bit-field is not my
inner-loop.
The other second issue I have, is that there is no way to do:
import (C) "foo.h"
And this is a big no-go (maybe not for git, but as a general issue)
because it impedes the use of external libraries with a C interface a
_lot_. E.g. I'd really like to use it to use some GNU libc extensions,
but I can't because it has too many dependencies (some async getaddrinfo
interface, that need me to import all the signal events and so on
extensions in the libc, with bitfields, wich send us back to the first
point).
I also have a third, but non critical issue, I absolutely don't like
phobos :) Though I'm obviously free to chose another library. D has
definitely many many many real advances over C (like the .init, .size,
... and so on fields, known types, and whatever portability nightmare
the C impose us). In fact I like to use D like I code in C, using
modules and functions, and very few classes, as few as I can. And even
(under- ?) using D like this, it is a real pleasure to work with. I'm
really eager to see gdc be more stable.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-07 9:31 UTC (permalink / raw)
To: git
In-Reply-To: <fbr4oi$5ko$1@sea.gmane.org>
Walter Bright <boost@digitalmars.com> writes:
> David Kastrup wrote:
>> Walter Bright <boost@digitalmars.com> writes:
>>
>>> A canonical example is that of a loop. Consider a simple C loop over
>>> an array:
>>>
>>> void foo(int array[10])
>>> {
>>> for (int i = 0; i < 10; i++)
>>> { int value = array[i];
>>> ... do something ...
>>> }
>>> }
>>>
>>> It's simple, but it has a lot of problems:
>>>
>>> 1) i should be size_t, not int
>>
>> Wrong. size_t is for holding the size of memory objects in bytes, not
>> in terms of indices. For indices, the best variable is of the same
>> type as the declared index maximum size, so here it is typeof(10),
>> namely int.
>
> The easiest way to show the error is consider the code being ported to
> a typical 64 bit C compiler. int's are still 32 bits, yet the array
> can be larger than 32 bits.
Not if it is an array declared of size 10. And if it isn't, you have
no business stating so in the function prototype.
Willfully obfuscate programming does not prove anything.
>>> 2) array is not checked for overflow
>>
>> Why should it?
>
> Because the 10 array dimension is not statically checked in C. I
> could pass it a pointer to 3 ints without the compiler
> complaining. This makes it a potential maintenance problem.
Nonsense. Again, C won't keep you from shooting yourself in the foot.
>>> 3) 10 may not be the actual array dimension
>>
>> Your point is?
>
> Array buffer overflow errors are commonplace in C, because array
> dimensions are not automatically checked at either compile or run
> time.
No, because programmers get things wrong. You can tell C compilers to
check all array accesses, but that is a performance issue. For gcc,
we have
`-fmudflap -fmudflapth -fmudflapir'
For front-ends that support it (C and C++), instrument all risky
pointer/array dereferencing operations, some standard library
string/heap functions, and some other associated constructs with
range/validity tests. Modules so instrumented should be immune to
buffer overflows, invalid heap use, and some other classes of C/C++
programming errors. The instrumentation relies on a separate
runtime library (`libmudflap'), which will be linked into a
program if `-fmudflap' is given at link time. Run-time behavior
of the instrumented program is controlled by the `MUDFLAP_OPTIONS'
environment variable. See `env MUDFLAP_OPTIONS=-help a.out' for
its options.
Why isn't it the default? Because it is a performance issue.
>>> 5) type of array may change, but the type of value may not get
>>> updated
>>
>> Huh?
>
> Let's say our fearless maintenance programmer decides to make it an
> array of longs, not an array of ints. He overlooks changing the type
> of value in the loop.
Again: C does not prevent you from shooting yourself in the foot.
>>> 6) crashes if array is NULL
>>
>> Certainly. Your point being?
>
> I consider an array that is NULL to have no members,
Nobody else does that.
> so instead of crashing the loop should execute 0 times.
If the loop count is zero, this is what will happen.
>>> 7) only works with arrays and pointers
>>
>> Since there are only arrays and pointers in C, not really a
>> restriction.
>
> C has structs, too, as well as more complicated user defined
> collections. Essentially, you cannot (simply) write generic
> algorithms in C, because you cannot (simply) generically express
> iteration.
Of course you can. Macros exist.
>> Most of those are toy concerns. They prevent problems that don't
>> actually occur much in practice.
>
> I beg to differ - buffer overflow bugs are common and expensive.
Then compile your program with appropriate options. The key word is
"option". You don't have to take the performance hit if you don't
want or need it.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Wincent Colaiuta @ 2007-09-07 9:19 UTC (permalink / raw)
To: Paul Wankadia; +Cc: git
In-Reply-To: <loom.20070907T055946-637@post.gmane.org>
El 7/9/2007, a las 6:06, Paul Wankadia escribió:
> Wincent Colaiuta <win <at> wincent.com> writes:
>
>>> I just wanted to get a sense of how many people share this "Git
>>> should
>>> be in pure C" doctrine.
>>
>> Count me as one of them. Git is all about speed, and C is the best
>> choice for speed, especially in context of Git's workload.
>
> I concur, but I also feel that D, Clean and OCaml are viable
> alternatives.
Yes, they have reputation for speed[1], but also a smaller number of
people know them[2].
[1] <http://shootout.alioth.debian.org/gp4/benchmark.php?
test=all&lang=all>
[2] <http://www.tiobe.com/tpci.htm>
Cheers,
Wincent
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Walter Bright @ 2007-09-07 9:14 UTC (permalink / raw)
To: git
In-Reply-To: <851wda7ufz.fsf@lola.goethe.zz>
David Kastrup wrote:
> Walter Bright <boost@digitalmars.com> writes:
>
>> A canonical example is that of a loop. Consider a simple C loop over
>> an array:
>>
>> void foo(int array[10])
>> {
>> for (int i = 0; i < 10; i++)
>> { int value = array[i];
>> ... do something ...
>> }
>> }
>>
>> It's simple, but it has a lot of problems:
>>
>> 1) i should be size_t, not int
>
> Wrong. size_t is for holding the size of memory objects in bytes, not
> in terms of indices. For indices, the best variable is of the same
> type as the declared index maximum size, so here it is typeof(10),
> namely int.
The easiest way to show the error is consider the code being ported to a
typical 64 bit C compiler. int's are still 32 bits, yet the array can be
larger than 32 bits. You're right in that what we want to be able to do
is typeof(array dimension), but there is no way to do that automatically
in C, which is my point. If the array dimension changes, you have to
carefully check to make sure every loop dependency on the type is
updated, too.
size_t will always work, however, making it a better choice than int, at
least for C.
>> 2) array is not checked for overflow
>
> Why should it?
Because the 10 array dimension is not statically checked in C. I could
pass it a pointer to 3 ints without the compiler complaining. This makes
it a potential maintenance problem. Also, the maintenance programmer may
change the array dimension in the function signature, but overlook
changing it in the for loop. Again, a maintenance problem.
>> 3) 10 may not be the actual array dimension
>
> Your point is?
Array buffer overflow errors are commonplace in C, because array
dimensions are not automatically checked at either compile or run time.
This is an expensive problem. Some C APIs try to deal with this by
passing a second argument for arrays giving the dimension (snprintf, for
example), but this tends to be sporadic, not conventional. It being
extra work for the programmer inevitably means it doesn't get done.
>> 4) may be more efficient to step through the array with pointers,
>> rather than indices
>
> No. It is a beginners' and advanced users' mistake to think using
> pointers for access is a good idea. Trivial optimizations are what a
> compiler is best at, not the user. Using pointer manipulation will
> more often than not break loop unrolling, loop reversal, strength
> reduction and other things.
C compilers vary widely in the optimizations they'll do for simple
loops. I see often enough attempts by programmers to take such matters
into their own hands. I agree with you on that - and suggest the
language should not tempt the user to do such optimizations.
>> 5) type of array may change, but the type of value may not get
>> updated
>
> Huh?
Let's say our fearless maintenance programmer decides to make it an
array of longs, not an array of ints. He overlooks changing the type of
value in the loop. Suddenly, things subtly break because of overflows.
Or maybe he changed the int to an unsigned, now the divides in the loop
give different answers. Etc. There really isn't any compiler/language
help in finding these kinds of problems.
>> 6) crashes if array is NULL
>
> Certainly. Your point being?
I consider an array that is NULL to have no members, so instead of
crashing the loop should execute 0 times.
>> 7) only works with arrays and pointers
>
> Since there are only arrays and pointers in C, not really a restriction.
C has structs, too, as well as more complicated user defined
collections. Essentially, you cannot (simply) write generic algorithms
in C, because you cannot (simply) generically express iteration. Of
course, you can still express anything in C if you're willing to work
hard enough to get it. Me, I'm too lazy <g>. It's like why I can't play
chess - everytime I try to play it instead I think about writing a
program to do the hard work for me.
>> As a programmer, I'm specifying exactly what I want to happen without
>> much extra puffery. It's less typing, simpler, and more resistant to
>> bugs.
>>
>> 1) correct loop index type is selected based on the type of array
>> 2) arrays carry with them their dimension, so foreach is guaranteed to
>> step through the loop the correct number of times
>> 3) implementation decides if pointers will do a better job than
>> indices, based on the compilation target
>> 4) type of value is inferred automatically from the type of array, so
>> no worries if the type changes
>> 5) Null arrays have 0 length, so no crashing
>> 6) works with any collection type
>
> Most of those are toy concerns. They prevent problems that don't
> actually occur much in practice.
I beg to differ - buffer overflow bugs are common and expensive. The
nice thing about the D loop is it is LESS typing than the C one - you
get the extra robustness for free.
Let's look at the code gen for the inner loop for C:
L8: push [EBX*4][ESI]
call near ptr _bar
inc EBX
add ESP,4
cmp EBX,0Ah
jb L8
and for D:
LE: mov EAX,[EBX]
call near ptr _D4test3barFiZv
add EBX,4
cmp EBX,ESI
jb LE
I think you can see that performance isn't an impediment.
^ permalink raw reply
* Re: [PATCH 6/7] Eradicate yet-another-buffer implementation in buitin-rerere.c
From: Pierre Habouzit @ 2007-09-07 9:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7v642m7vhr.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]
On Fri, Sep 07, 2007 at 08:03:28AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > crap, and I did that in the 5th patch as well. well, I'll maybe send
> > privately a "fixed" version of the patch to junio then, to avoid
> > flooding the list with spacing issues.
>
> Heh, no need. I can fix them up locally here.
okay, perfect.
> For me personally, your use of Mail-Followup-To: header is very
> much more irritating. When I want to talk to you, I want my MUA
> to put YOUR name on To: header, not Johannes. I consider it
> rude and selfish to use M-F-T to avoid getting duplicates from a
> mailing list you subscribe to.
>
> I have said this often enough in the past, and have been trying
> not to say this unless necessary. It is sad and happy at the
> same time that I still occasionary need to bring this up.
>
> Sad because I have to get irritated enough before I say this,
I'm sorry, I'll remove it (for the next mail though, I'm too lazy to
change that right now). It's a policy on Debian lists to force M-F-T,
and it's indeed not very practical on lists like the lkml or git. I
could have guessed that myself.
> and happy because it means I found another person who is worth
> communicating with and expect to communicate again with on the
> list.
heh, thanks :)
> Please, don't.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-svn: remove --first-parent, add --upstream
From: Peter Baumann @ 2007-09-07 8:43 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Eric Wong, Junio C Hamano, git
In-Reply-To: <8c5c35580709061723m7e01c9d4p1b1936dc1d590459@mail.gmail.com>
On Fri, Sep 07, 2007 at 02:23:58AM +0200, Lars Hjemli wrote:
> On 9/7/07, Peter Baumann <waste.manager@gmx.de> wrote:
> > Wouldn't it be much more pleasant to say something like
> >
> > git-svn dcommit --on the_branch
> >
> > whereas 'the_branch' is the name of the upstream branch as specified
> > in the fetch/branch section in the git config?
>
> Well, git-svn extracts the svn url, revision and repo uuid from the
> commit message, while your proposal only specifies the url. But I'm
> still not certain that there is a need for --upstream or anything
> similar if git-svn always uses 'git log --first-parent' (see
> http://article.gmane.org/gmane.comp.version-control.git/57951).
>
First parent is a heuristic (and a good one, me thinks).
If you did something like this:
(1) Start state:
a-b-c-d-e trunk (both trunk and branch1 are imported
\ from SVN)
\-x-y branch1
(2) Hm. My Branch 'branch1' should be ready to be merged to 'trunk', so
lets do it (not yet dcommited)
a-b-c-d-e- m trunk
\ /
\ -x-y branch1
(3) ARGH. I just discovered a serious bug in 'branch1' and can't just merge
it into 'trunk', yet. But the merge was painfull enough so I don't want to
redo it again, so lets reset 'trunk' to its state before the merge and
'branch1' to the merge commit, before fixing the bug in 'branch1'.
a-b-c-d-e trunk
\ \
\ -x-y m branch1
Notice that this DAG is identical to the one in (2), but just the branch
labels stick to different commits. And if you now want to commit the
merge 'm' to 'branch1' before fixing the bug you are screwed, because
--first-parent will give you 'e' instead of 'y'.
Yes, I know that this example isn't something happening every day, but
at least it shows that --first-parent could *only* be a heuristic and
not something you would rely 100% on. And if you imagine several people
who are sharing their git commits for codereview with pulling/pushing,
it isn't obvious what branch got merged into the other, because it is
possible that the other person did the merge.
Don't get me wrong, --first-parent *is* an improvement over the current
behaviour, but I think it is simply not the *best* we can do.
-Peter
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Walter Bright @ 2007-09-07 8:36 UTC (permalink / raw)
To: git
In-Reply-To: <D7BEA87D-1DCF-4A48-AD5B-0A3FDC973C8A@wincent.com>
Wincent Colaiuta wrote:
> Git is all about speed, and C is the best
> choice for speed, especially in context of Git's workload.
I can appreciate that. I originally got into writing compilers because
my game (Empire) ran too slowly and I thought the existing compilers
could be dramatically improved.
And technically, yes, you can write code in C that is >= the speed of
any other language (other than asm). But practically, this isn't
necessarily so, for the following reasons:
1) You wind up having to implement the complex, dirty details of things
yourself. The consequences of this are:
a) you pick a simpler algorithm (which is likely less efficient - I
run across bubble sorts all the time in code)
b) once you implement, tune, and squeeze all the bugs out of those
complex, dirty details, you're reluctant to change it. You're reluctant
to try a different algorithm to see if it's faster. I've seen this
effect a lot in my own code. (I translated a large body of my own C++
code that I'd spent months tuning to D, and quickly managed to get
significantly more speed out of it, because it was much simpler to try
out different algorithms/data structures.)
2) Garbage collection has an interesting and counterintuitive
consequence. If you compare n malloc/free's with n gcnew/collections,
the malloc/free will come out faster, and you conclude that gc is slow.
But that misses one huge speed advantage of gc - you can do FAR fewer
allocations! For example, I've done a lot of string manipulating
programs in C. The basic problem is keeping track of who owns each
string. This is done by, when in doubt, make a copy of the string.
But if you have gc, you don't worry about who owns the string. You just
make another pointer to it. D takes this a step further with the concept
of array slicing, where one creates windows on existing arrays, or
windows on windows on windows, and no allocations are ever done. It's
just pointer fiddling.
------
Walter Bright
http://www.digitalmars.com C, C++, D programming language compilers
http://www.astoriaseminar.com Extraordinary C++
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-07 8:26 UTC (permalink / raw)
To: Walter Bright; +Cc: git
In-Reply-To: <fbr1a2$qm7$1@sea.gmane.org>
Walter Bright <boost@digitalmars.com> writes:
> A canonical example is that of a loop. Consider a simple C loop over
> an array:
>
> void foo(int array[10])
> {
> for (int i = 0; i < 10; i++)
> { int value = array[i];
> ... do something ...
> }
> }
>
> It's simple, but it has a lot of problems:
>
> 1) i should be size_t, not int
Wrong. size_t is for holding the size of memory objects in bytes, not
in terms of indices. For indices, the best variable is of the same
type as the declared index maximum size, so here it is typeof(10),
namely int.
> 2) array is not checked for overflow
Why should it?
> 3) 10 may not be the actual array dimension
Your point is?
> 4) may be more efficient to step through the array with pointers,
> rather than indices
No. It is a beginners' and advanced users' mistake to think using
pointers for access is a good idea. Trivial optimizations are what a
compiler is best at, not the user. Using pointer manipulation will
more often than not break loop unrolling, loop reversal, strength
reduction and other things.
> 5) type of array may change, but the type of value may not get
> updated
Huh?
> 6) crashes if array is NULL
Certainly. Your point being?
> 7) only works with arrays and pointers
Since there are only arrays and pointers in C, not really a restriction.
>
> Since this thread is talking about C++, let's look at the C++ version:
>
> void foo(std::vector<int> array)
> {
> for (std::vector<int>::const_iterator
> i = array.begin();
> i != array.end();
> i++)
> {
> int value = *i;
> ... do something ...
> }
> }
Where is my barf bag?
> Frankly, I don't want to write loops that way. I want to write them
> like this:
>
> void foo(int[] array)
> {
> foreach (value; array)
> {
> ... do something ...
> }
> }
>
> As a programmer, I'm specifying exactly what I want to happen without
> much extra puffery. It's less typing, simpler, and more resistant to
> bugs.
>
> 1) correct loop index type is selected based on the type of array
> 2) arrays carry with them their dimension, so foreach is guaranteed to
> step through the loop the correct number of times
> 3) implementation decides if pointers will do a better job than
> indices, based on the compilation target
> 4) type of value is inferred automatically from the type of array, so
> no worries if the type changes
> 5) Null arrays have 0 length, so no crashing
> 6) works with any collection type
Most of those are toy concerns. They prevent problems that don't
actually occur much in practice.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Walter Bright @ 2007-09-07 8:15 UTC (permalink / raw)
To: git
In-Reply-To: <85k5r27wkv.fsf@lola.goethe.zz>
David Kastrup wrote:
> Walter Bright <boost@digitalmars.com> writes:
>> The D programming language is a different take than C++ has on growing
>> C. I'm curious what your thoughts on that are (D has garbage
>> collection, while still retaining the ability to directly manage
>> memory). Can you enumerate what you feel are the important concepts?
>
> A design is perfect not when there is no longer anything you can add
> to it, but if there is no longer anything you can take away.
I like to phrase that a slightly different way: anyone can make
something complicated, but it takes genius to make something simple.
A very big goal for D is to make what should be simple code, simple. It
turns out that what's simple for a computer is complex for a human. So
to design a language that is simple for programmers is (unfortunately) a
rather complex problem. Or perhaps I'm just not smart enough <g>.
A canonical example is that of a loop. Consider a simple C loop over an
array:
void foo(int array[10])
{
for (int i = 0; i < 10; i++)
{ int value = array[i];
... do something ...
}
}
It's simple, but it has a lot of problems:
1) i should be size_t, not int
2) array is not checked for overflow
3) 10 may not be the actual array dimension
4) may be more efficient to step through the array with pointers, rather
than indices
5) type of array may change, but the type of value may not get updated
6) crashes if array is NULL
7) only works with arrays and pointers
Since this thread is talking about C++, let's look at the C++ version:
void foo(std::vector<int> array)
{
for (std::vector<int>::const_iterator
i = array.begin();
i != array.end();
i++)
{
int value = *i;
... do something ...
}
}
It has fewer latent bugs, but still:
1) type of array may change, but the type of value may not get updated
2) too darned much typing
3) it's more complicated, not simpler
Frankly, I don't want to write loops that way. I want to write them like
this:
void foo(int[] array)
{
foreach (value; array)
{
... do something ...
}
}
As a programmer, I'm specifying exactly what I want to happen without
much extra puffery. It's less typing, simpler, and more resistant to bugs.
1) correct loop index type is selected based on the type of array
2) arrays carry with them their dimension, so foreach is guaranteed to
step through the loop the correct number of times
3) implementation decides if pointers will do a better job than indices,
based on the compilation target
4) type of value is inferred automatically from the type of array, so no
worries if the type changes
5) Null arrays have 0 length, so no crashing
6) works with any collection type
[This example is extracted from a presentation I've made.]
------
Walter Bright
http://www.digitalmars.com C, C++, D programming language compilers
http://www.astoriaseminar.com Extraordinary C++
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-07 8:08 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Dmitry Kakurin, Linus Torvalds, Matthieu Moy
In-Reply-To: <200709070841.33057.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Friday 2007 September 07, David Kastrup wrote:
>
> (Disclaimer: I'm certainly not joining the "C++ for git" chant; this reply is
> merely to the statements made about C++ in David's message).
>
>> The problem with C++ is that every C++ developer has his own style,
>> and reuse is an illusion within that style. Take a look at classes
>> implementing matrix arithmetic: there are as many around as the day is
>> long, and all of them are incompatible with one another.
>
> One could say the same about any API. "Take a look at that C
> library libXYZ - it does exactly the same thing as libPQR but all
> the function calls and structures are different. Conclusion: C is
> shit". Obviously nonsense.
The difference is that you can pass structures from one library into
another with tolerable efficiency. Because there are only basically 2
ways to lay out a two-dimensional array of floats.
>> With regard to programming styles, C++ does not support multiple
>> inheritance. For a single project grown from a single start, you
>> can
>
> Multiple inheritance is the spawn of the devil, but C++ _does_
> support it.
What about "With regard to programming styles" did you not understand?
I was not talking about a technical feature at class level, but about
code merging from multiple sources.
> I would imagine the reason people often turn up wanting to rewrite
> Linux and git in C++ is because they are so object oriented in
> nature already and it's natural to think "wouldn't this be even
> better if I wrote it in an object oriented language"? Maybe, maybe
> not, but why bother?
Maintainability and extensibility certainly are valid arguments for
rewrites. But C++ does not really shine in that regard.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 6/7] Eradicate yet-another-buffer implementation in buitin-rerere.c
From: Junio C Hamano @ 2007-09-07 8:03 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Johannes Schindelin
In-Reply-To: <20070906171734.GG8451@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> crap, and I did that in the 5th patch as well. well, I'll maybe send
> privately a "fixed" version of the patch to junio then, to avoid
> flooding the list with spacing issues.
Heh, no need. I can fix them up locally here.
For me personally, your use of Mail-Followup-To: header is very
much more irritating. When I want to talk to you, I want my MUA
to put YOUR name on To: header, not Johannes. I consider it
rude and selfish to use M-F-T to avoid getting duplicates from a
mailing list you subscribe to.
I have said this often enough in the past, and have been trying
not to say this unless necessary. It is sad and happy at the
same time that I still occasionary need to bring this up.
Sad because I have to get irritated enough before I say this,
and happy because it means I found another person who is worth
communicating with and expect to communicate again with on the
list.
Please, don't.
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Andy Parkins @ 2007-09-07 7:41 UTC (permalink / raw)
To: git; +Cc: David Kastrup, Dmitry Kakurin, Linus Torvalds, Matthieu Moy
In-Reply-To: <85ejhb7yzw.fsf@lola.goethe.zz>
On Friday 2007 September 07, David Kastrup wrote:
(Disclaimer: I'm certainly not joining the "C++ for git" chant; this reply is
merely to the statements made about C++ in David's message).
> The problem with C++ is that every C++ developer has his own style,
> and reuse is an illusion within that style. Take a look at classes
> implementing matrix arithmetic: there are as many around as the day is
> long, and all of them are incompatible with one another.
One could say the same about any API. "Take a look at that C library libXYZ -
it does exactly the same thing as libPQR but all the function calls and
structures are different. Conclusion: C is shit". Obviously nonsense.
> With regard to programming styles, C++ does not support multiple
> inheritance. For a single project grown from a single start, you can
Multiple inheritance is the spawn of the devil, but C++ _does_ support it.
Forgetting about the terrible STL, to me there really is no difference between
C and C++; you can be object oriented in C. Take a look at the Linux kernel,
it should be printed out, rolled up and used to beat the ideas into students
learning C++/Java/C#. Object oriented design is a choice, and if you really
wanted you could do it in assembly.
I would imagine the reason people often turn up wanting to rewrite Linux and
git in C++ is because they are so object oriented in nature already and it's
natural to think "wouldn't this be even better if I wrote it in an object
oriented language"? Maybe, maybe not, but why bother?
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-07 7:40 UTC (permalink / raw)
To: Walter Bright; +Cc: git
In-Reply-To: <fbqmdu$udg$1@sea.gmane.org>
Walter Bright <boost@digitalmars.com> writes:
> Linus Torvalds wrote:
>> And if you want a fancier language, C++ is absolutely the worst one
>> to choose. If you want real high-level, pick one that has true
>> high-level features like garbage collection or a good system
>> integration, rather than something that lacks both the sparseness
>> and straightforwardness of C, *and* doesn't even have the high-level
>> bindings to important concepts.
>>
>> IOW, C++ is in that inconvenient spot where it doesn't help make
>> things simple enough to be truly usable for prototyping or simple
>> GUI programming, and yet isn't the lean system programming language
>> that C is that actively encourags you to use simple and direct
>> constructs.
>
> The D programming language is a different take than C++ has on growing
> C. I'm curious what your thoughts on that are (D has garbage
> collection, while still retaining the ability to directly manage
> memory). Can you enumerate what you feel are the important concepts?
A design is perfect not when there is no longer anything you can add
to it, but if there is no longer anything you can take away.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Subject: [PATCH] git-merge-pack
From: Junio C Hamano @ 2007-09-07 7:34 UTC (permalink / raw)
To: Johannes Sixt
Cc: Linus Torvalds, Johannes Schindelin, Nicolas Pitre, Nix,
Steven Grimm, Git Mailing List
In-Reply-To: <46E0F998.1080202@eudaptics.com>
Johannes Sixt <j.sixt@eudaptics.com> writes:
> Junio C Hamano schrieb:
>> This is a beginning of "git-merge-pack" that combines smaller
>> packs into one.
>
> This gives a new meaning to the term "merge". IMHO, "git-combine-pack"
> would be a better name.
Yeah, that makes sense, but I think this can and should be done
as part of pack-objects itself as Nico suggested.
So consider that patch scrapped for now.
^ permalink raw reply
* [PATCH] git-svn: fix "Malformed network data" with svn:// servers
From: Eric Wong @ 2007-09-07 7:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, 430091
In-Reply-To: <20070807134220.23420.qmail@c96e4a6cce1e57.315fe32.mid.smarden.org>
We have a workaround for the reparent function not working
correctly on the SVN native protocol servers. This workaround
opens a new connection (SVN::Ra object) to the new
URL/directory.
Since libsvn appears limited to only supporting one connection
at a time, this workaround invalidates the Git::SVN::Ra object
that is $self inside gs_fetch_loop_common(). So we need to
restart that connection once all the fetching is done for each
loop iteration to be able to run get_log() successfully.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Gerrit Pape <pape@smarden.org> wrote:
> On Wed, Jul 04, 2007 at 02:07:42PM -0700, Eric Wong wrote:
> > Although this fixes blocking reads, this does *not* fix the
> > "Malformed network data" issue, which has been around for a
> > while...
> >
> > I'll try to find time to fix the "Malformed network data" bug
> > in a few days time, but it's not fatal (just restart git-svn,
> > this error happens at a point where it's not possible to have
> > a corrupted import).
>
> Hi, this still is a problem we face on Debian with 1.5.3-rc3
> http://bugs.debian.org/436142
> http://bugs.debian.org/430091
>
> I'm sorry, I didn't manage to provide a patch.
Sorry for the latency again.
git-svn.perl | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index d3c8cd0..7df4098 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3175,6 +3175,7 @@ sub gs_do_switch {
$reparented = 1;
} else {
$ra = Git::SVN::Ra->new($full_url);
+ $self->{-invalid} = 1;
}
}
$ra ||= $self;
@@ -3310,6 +3311,11 @@ sub gs_fetch_loop_common {
$min = $max + 1;
$max += $inc;
$max = $head if ($max > $head);
+ if ($self->{-invalid}) {
+ my $ra_url = $self->{url};
+ $self = undef;
+ $self = Git::SVN::Ra->new($ra_url);
+ }
}
}
--
Eric Wong
^ permalink raw reply related
* Re: very slow cherry-pick'ing (old-2.6-bkcvs tree)
From: Johannes Sixt @ 2007-09-07 7:27 UTC (permalink / raw)
To: Erez Zadok; +Cc: Git Mailing List
In-Reply-To: <200709062351.l86NpnAK004807@agora.fsl.cs.sunysb.edu>
Erez Zadok schrieb:
> Our group maintains Unionfs on the latest -rc kernel, but we also maintain
> several backports going all the way to 2.6.9. Once we complete the
> development and testing of a feature/fix in -latest, we cherry-pick those
> commits to older backports, and test those. When I cherry-pick from -latest
> to my 2.6.{22,21,20,19,18} repositories, it works reasonably fast. But when
> I cherry-pick to my 2.6.9 tree, it runs about 20 times slower! Why? Is
> there anything I can do to inspect what's going on and perhaps speed up the
> cherry-picking process?
>
> Some info:
>
> My 2.6.{18,19,20,21,22} trees were cloned from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.<N>.y.git
>
> My 2.6.9 tree, however, was cloned from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/old-2.6-bkcvs.git
>
> after which, I truncated the tree (git-reset) to Linus commit which read
> "Linux 2.6.9-final".
I *think* that the reason for this is that those repositories don't have any
commits in common (but I don't have clones to verify my claim). Since
cherry-pick does merge-recursive, it tries to find a suitable merge base,
but since there is no history in common, it walks both histories all the way
down only to find that there is no possible merge base.
You could improve the situation if you graft the histories together:
echo $first_commit_in_2.6.12 $suitable_commit_in_bkcvs > .git/info/grafts
-- Hannes
^ permalink raw reply
* Re: Subject: [PATCH] git-merge-pack
From: Andy Parkins @ 2007-09-07 7:24 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Linus Torvalds, Johannes Schindelin,
Nicolas Pitre, Nix, Steven Grimm
In-Reply-To: <7v1wdb9ymf.fsf_-_@gitster.siamese.dyndns.org>
On Friday 2007 September 07, Junio C Hamano wrote:
> builtin-merge-pack.c | 87
Can I suggest not calling it git-merge-pack? It makes it look like it's a new
merge strategy called "pack"...
git-merge-base
git-merge-file
git-merge-index
git-merge-octopus
git-merge-one-file
git-merge-ours
git-merge-recur
git-merge-recursive
git-merge-resolve
git-merge-stupid
git-merge-subtree
git-merge-tree
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Walter Bright @ 2007-09-07 5:09 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0709070203200.5626@evo.linux-foundation.org>
Linus Torvalds wrote:
> And if you want a fancier language, C++ is absolutely the worst one to
> choose. If you want real high-level, pick one that has true high-level
> features like garbage collection or a good system integration, rather than
> something that lacks both the sparseness and straightforwardness of C,
> *and* doesn't even have the high-level bindings to important concepts.
>
> IOW, C++ is in that inconvenient spot where it doesn't help make things
> simple enough to be truly usable for prototyping or simple GUI
> programming, and yet isn't the lean system programming language that C is
> that actively encourags you to use simple and direct constructs.
The D programming language is a different take than C++ has on growing
C. I'm curious what your thoughts on that are (D has garbage collection,
while still retaining the ability to directly manage memory). Can you
enumerate what you feel are the important concepts?
^ permalink raw reply
* Re: Subject: [PATCH] git-merge-pack
From: Johannes Sixt @ 2007-09-07 7:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Johannes Schindelin, Nicolas Pitre, Nix,
Steven Grimm, Git Mailing List
In-Reply-To: <7v1wdb9ymf.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> This is a beginning of "git-merge-pack" that combines smaller
> packs into one.
This gives a new meaning to the term "merge". IMHO, "git-combine-pack" would
be a better name.
-- Hannes
^ permalink raw reply
* Re: rebase from ambiguous ref discards changes
From: Pierre Habouzit @ 2007-09-07 6:55 UTC (permalink / raw)
To: Keith Packard; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <1189133898.30308.58.camel@koto.keithp.com>
[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]
On Fri, Sep 07, 2007 at 02:58:18AM +0000, Keith Packard wrote:
> On Thu, 2007-09-06 at 16:26 -0700, Junio C Hamano wrote:
>
> > Perhaps you have ".git/master" by mistake?
>
> oops.
>
> $ find .git -name master
> ..git/master
> ..git/refs/heads/master
> ..git/refs/remotes/kyle/master
> ..git/refs/remotes/origin/master
> ..git/refs/remotes/otc/master
> ..git/logs/refs/heads/master
> ..git/logs/refs/remotes/fdo/master
> ..git/logs/refs/remotes/kyle/master
> ..git/logs/refs/remotes/origin/master
> ..git/logs/refs/remotes/otc/master
>
> So, I think that explains where the ambiguous master came from. Seems
> like rebase should be able to bail out before breaking things though.
Actually if I get this right, it didn't broke anything, it just
rebased your ".git/master" :) It just chose the wrong desambiguation for
some reason.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox