Re: std.xml should just go

2011-02-11 Thread Bruno Medeiros
On 04/02/2011 21:07, Steven Schveighoffer wrote: On Fri, 04 Feb 2011 15:44:46 -0500, Jeff Nowakowski wrote: On 02/03/2011 10:07 PM, Walter Bright wrote: The way to get a high performance string parser in D is to take advantage of one of D's unique features - slices. Java, C++, C#, etc., all

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

2011-02-11 Thread Jean Crystof
Bruno Medeiros Wrote: > On 09/02/2011 23:02, Ulrik Mikaelsson wrote: > > 2011/2/9 Bruno Medeiros: > >> > >> It's unlikely you will see converted repositories with a lot of changing > >> blob data. DVCS, at the least in the way they work currently, simply kill > >> this workflow/organization-patter

Re: d-programming-language.org

2011-02-11 Thread Bruno Medeiros
On 30/01/2011 08:03, Andrei Alexandrescu wrote: I've had some style updates from David Gileadi rotting in a zip file in my inbox for a good while. It took me the better part of today to manually merge his stale files with the ones in the repository, which have in the meantime undergone many chang

Re: High performance XML parser

2011-02-11 Thread Michael Rynn
On Mon, 07 Feb 2011 10:37:46 -0500, Robert Jacques wrote: > On Mon, 07 Feb 2011 07:40:30 -0500, Steven Schveighoffer > wrote: > >> On Fri, 04 Feb 2011 17:36:50 -0500, Tomek Sowiński wrote: >> >>> Steven Schveighoffer napisał: >>> Here is how I would approach it (without doing any research)

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

2011-02-11 Thread Bruno Medeiros
On 09/02/2011 14:27, Michel Fortin wrote: On 2011-02-09 07:49:31 -0500, Bruno Medeiros said: On 04/02/2011 20:11, Michel Fortin wrote: On 2011-02-04 11:12:12 -0500, Bruno Medeiros said: Can Git really have an usable but incomplete local clone? Yes, it's called a shallow clone. See the --

Re: Stupid little iota of an idea

2011-02-11 Thread foobar
Andrei Alexandrescu Wrote: > > I don't find the name "iota" stupid. > > Andrei Of course _you_ don't. However practically all the users _do_ find it poorly named, including other developers in the project.. This is the umpteenth time this comes up in the NG and incidentally this is the only

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

2011-02-11 Thread Bruno Medeiros
On 09/02/2011 23:02, Ulrik Mikaelsson wrote: 2011/2/9 Bruno Medeiros: It's unlikely you will see converted repositories with a lot of changing blob data. DVCS, at the least in the way they work currently, simply kill this workflow/organization-pattern. I very much suspect this issue will become

Re: inlining or not inlining...

2011-02-11 Thread bearophile
spir: > People possibly interested in the question of inlining (or more generally > factors of (in)efficiency) must start somehow, granted. But making it even > more > difficult than necessary, while we all know it is inherently a very complex > topic, does not bring much, don't you think? > I

Re: inlining or not inlining...

2011-02-11 Thread spir
On 02/11/2011 07:53 AM, so wrote: While in isolation that's a good idea, how far should it be taken? Should the compiler emit information on which variables wound up in which registers, and why? What about other of the myriad of compiler optimizations? Isn't Inlining by far the most important (

Re: inlining or not inlining...

2011-02-11 Thread spir
On 02/11/2011 07:32 AM, Walter Bright wrote: spir wrote: Thus, at best, we would need to know a bit about criteria used by the compiler for deciding whether to inline or not; provided a doc explaining this is at all readable by people who do not have the compiler-writer gene. Aside that, let us

Re: inlining or not inlining...

2011-02-11 Thread so
But I'm sure this sort of thing is also highly variable based on type of applications, code style, language, etc. Indeed it is, for example you won't hear much complaints from game developers because they rely on GPU for most of the computations these days, but there are other areas where c

Re: How will we fix opEquals?

2011-02-11 Thread Jonathan M Davis
On Friday 11 February 2011 02:43:11 spir wrote: > On 02/11/2011 07:13 AM, Jonathan M Davis wrote: > >>> We _must_ have it there, so anyone overriding those functions _must_ > >>> > >>> > > use it for those functions. They could create non-const versions > >>> > > in addition to > >>> > > the

Re: Stupid little iota of an idea

2011-02-11 Thread spir
On 02/11/2011 02:38 AM, Nick Sabalausky wrote: "Max Samukha" wrote in message news:ij10n7$25p0$1...@digitalmars.com... On 02/10/2011 05:18 PM, Andrei Alexandrescu wrote: On 2/10/11 12:30 AM, Olivier Pisano wrote: Le 09/02/2011 21:08, Ary Manzana a écrit : On 2/9/11 3:54 PM, bearophile wrote:

Re: Stupid little iota of an idea

2011-02-11 Thread spir
On 02/11/2011 03:06 AM, Jonathan M Davis wrote: I feel pretty much the same way. iota seems like a horrible name as far as figuring out what the function does from its name goes. I don't know what a good name would be though (genSequence?) why not "interval"? (not obvious enough ;-) denis -- _

Re: inlining or not inlining...

2011-02-11 Thread bearophile
Walter: > While in isolation that's a good idea, how far should it be taken? Should the > compiler emit information on which variables wound up in which registers, and > why? What about other of the myriad of compiler optimizations? Inlining is an important optimization, so give this informatio

Re: More on Rust

2011-02-11 Thread spir
On 02/11/2011 08:39 AM, Jim wrote: Jacob Carlborg Wrote: On 2011-02-10 20:15, Walter Bright wrote: Nick Sabalausky wrote: "bearophile" wrote in message news:iivb5n$na3$1...@digitalmars.com... auto x; if (localtime().hours>= 8) { x = "awake!" } else { x = "asleep, go away." } log "I'm " + x;

Re: inlining or not inlining...

2011-02-11 Thread spir
On 02/11/2011 09:33 AM, Jim wrote: Regardless, I would _hope_ that the compiler would be smart enough to make > intelligent choices about inlining. That's probably one of those areas that can > always be improved however. I also think that this decision should be left to the compiler. The i

Re: How will we fix opEquals?

2011-02-11 Thread spir
On 02/11/2011 07:13 AM, Jonathan M Davis wrote: We _must_ have it there, so anyone overriding those functions _must_ > > use it for those functions. They could create non-const versions in > > addition to > > the const ones, > > It is the whole point, they can't. Hmm. You're right (I jus

Re: inlining or not inlining...

2011-02-11 Thread so
Wrappers and frequent matrix, vector operations are -a- very serious examples that inlining is must. Now, it doesn't matter how easy or hard, -have- +how+ could we get around this? This is a great +excuse+ for an annotation. duh... how hard to synchronize brain, hands and eyes...

Re: inlining or not inlining...

2011-02-11 Thread so
No, not even close. The first step is figure out where your program is slow, and then why it is slow. For example, if it is slow because foo() is being called 1,000,000 times, you'll get a one thousand times speedup if you can tweak your algorithms so that it is only called 1,000 times. I t

Re: inlining or not inlining...

2011-02-11 Thread Brad Roberts
On 2/11/2011 12:37 AM, Walter Bright wrote: > so wrote: >>> While in isolation that's a good idea, how far should it be taken? Should >>> the compiler emit information on which >>> variables wound up in which registers, and why? What about other of the >>> myriad of compiler optimizations? >> >>

Re: More on Rust

2011-02-11 Thread Jean Crystof
Jim Wrote: > Jacob Carlborg Wrote: > > > On 2011-02-10 20:15, Walter Bright wrote: > > > Nick Sabalausky wrote: > > >> "bearophile" wrote in message > > >> news:iivb5n$na3$1...@digitalmars.com... > > >>> auto x; > > >>> if (localtime().hours >= 8) { > > >>> x = "awake!" > > >>> } else { > > >>>

Re: More on Rust

2011-02-11 Thread Jacob Carlborg
On 2011-02-11 08:39, Jim wrote: Jacob Carlborg Wrote: On 2011-02-10 20:15, Walter Bright wrote: Nick Sabalausky wrote: "bearophile" wrote in message news:iivb5n$na3$1...@digitalmars.com... auto x; if (localtime().hours>= 8) { x = "awake!" } else { x = "asleep, go away." } log "I'm " + x;

Re: Stupid little iota of an idea

2011-02-11 Thread Jacob Carlborg
On 2011-02-10 23:05, Andrei Alexandrescu wrote: On 2/10/11 9:47 AM, spir wrote: Even then, noone forces D2 to blindly reproduce stupid naming from APL/C++, I guess. Or what? I don't find the name "iota" stupid. Andrei Of course you don't think it's stupid, you named it. It starts to look m

Re: Stupid little iota of an idea

2011-02-11 Thread Jacob Carlborg
On 2011-02-11 04:15, Nick Sabalausky wrote: "Andrej Mitrovic" wrote in message news:mailman.1476.1297391467.4748.digitalmar...@puremagic.com... What the hell does "to!" have to do with anything. Disregard my last post, it's obviously 3 AM and I'm talking gibberish. I just meant that "iota" l

Re: inlining or not inlining...

2011-02-11 Thread Walter Bright
so wrote: While in isolation that's a good idea, how far should it be taken? Should the compiler emit information on which variables wound up in which registers, and why? What about other of the myriad of compiler optimizations? Isn't Inlining by far the most important (most practical) optimi

Re: inlining or not inlining...

2011-02-11 Thread Walter Bright
Jonathan M Davis wrote: Regardless, I would _hope_ that the compiler would be smart enough to make intelligent choices about inlining. That's probably one of those areas that can always be improved however. I agree completely. All compilers could use better register allocation algorithms, too

Re: inlining or not inlining...

2011-02-11 Thread Jim
Jonathan M Davis Wrote: > On Thursday 10 February 2011 22:35:34 Walter Bright wrote: > > Stewart Gordon wrote: > > > On 09/02/2011 12:14, spir wrote: > > >> Hello, > > >> > > >> Walter states that inline annotations are useless, since programmers > > >> cannot generally know > > >> which function

Re: inlining or not inlining...

2011-02-11 Thread Walter Bright
so wrote: You cannot force inlining in C(++) either. The inline keyword is only a suggestion. I'm not understanding your last comment that a .lib would be required. That's not correct, as since you're supplying the full source anyway (needed for inlining), just compile in that source from the

<    1   2