Re: accepts-invalid?
Nick Sabalausky wrote:
"Steven Schveighoffer" wrote in message
news:op.vhwolemleav...@localhost.localdomain...
On Mon, 23 Aug 2010 15:29:32 -0400, Nick Sabalausky wrote:
"klickverbot" wrote in message
news:i4ualh$1qh...@digitalmars.com...
Hello all,
currently, DMD accepts the following code, but the resulting binary
bus-errors at runtime:
---
import std.stdio;
void foo( string str ) () {
writefln( str );
}
void bar( string text ) {
foo!( text );
}
void main() { bar( "asdf" );
}
---
Shouldn't this be a compile-time error?
I'm pretty sure that should work fine in D1 without any errors. Although
on
1.062 I'm getting this (at run-time):
---
Error: 4invalid UTF-8 sequence
1
---
Wait, how can you pass a runtime string as a template parameter? I'm
pretty sure the whole thing is a bug.
Oh, yea, now I see it :)
It may be a duplicate of bug 2962.
Range literals
I know that D2 is supposed to be closed for new features, but I thought
I'd mention this anyway just in case it's deemed easy/simple enough for
inclusion, or even if it will just get considered for later on.
Anyway, we all know that we can do the following:
foreach (int x; 0..10)
writeln(x);
That will print 0, 1, 2 .. 9.
We could also write it like this:
foreach (int x; iota(0, 10))
writeln(x);
for the same effect.
If we want only odd numbers then we can use:
foreach (int x; filter!("a & 1")(iota(0, 10)))
writeln(x);
but what we cannot write is:
foreach (int x; filter!("a & 1")(0..10))
writeln(x);
because 0..10 isn't a range literal -- it's a special notation that only
applies to foreach loops and array slicing.
Proposal: Make a..b a literal that evaluates to iota(a, b) or some
built-in equivalent. Of course, the $ symbol would not be valid for
these literals.
More advanced proposal: Make .. into a binary operator, which is
language-defined for integer data types (takes two integers, returns
iota), and overloadable for user data-types. Why would you want to
overload it? For linked data-structures, it would be an ideal candidate
for creating a range between two links (linkA..linkB).
Pros
- Creates more uniformity and purity across the language i.e. if I can
use X and Y to the same effect (as above) then I expect f(X) and f(Y) to
have the same effect -- assuming that f is referentially transparent.
- Adds a nice, intuitive shorthand for a common practice, increasing the
productivity and readability of D code.
- It removes a special case of foreach.
- Doesn't (shouldn't?) break backwards-compatibility. If reliance on
std.algorithm.iota is a problem then perhaps it would be best encoded as
a D runtime type.
Cons
- Slicing still remains a special case, which might confuse people into
thinking that slicing is an operation that takes a range (arguably, this
is already the case)
- Requires core language and compiler changes.
I also have a proposal for slicing along the same lines, but I'll leave
that for later.
Re: Why C++ compiles slowly
Steven Schveighoffer wrote: With profiling enabled, gprof outputs this as the top hitters: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 77.76 6.68 6.68 2952 2.26 2.26 elf_findstr(Outbuffer*, char const*, char const*) 2.10 6.86 0.18 4342 0.04 0.04 searchfixlist elf_findstr definitely looks like a problem area. I can't look at it right now, so can you post this to bugzilla please?
Re: Fixing std.string
On Monday 23 August 2010 23:16:25 Michael Rynn wrote: > The problems are combinatorial, because of encoding schemes. > I imagine that when someone wants a function that is missing from > std.string, they might write one, and might even add to it. A lot of functions in Phobos are templated on string type, so you don't have to define multiple versions of them. Very few, if any, are actually defined for multiple string types. Now, because each template instantiation results in another version of the function in the resulting binary, if you try and use all of the functions with all of the string types, then you do get combinatorial problems. But thanks to the templates, you don't have to worry about it directly, and it's not like it's going to be a typical use case for most string functions to be used by multiple string types in the same program. It will happen, but not enough to generally be an issue. - Jonathan M Davis
Re: Range literals
On 24/08/10 08:56, Peter Alexander wrote: Proposal: Make a..b a literal that evaluates to iota(a, b) or some built-in equivalent. Indeed, this has been discussed before and I believe people were generally in favor of this idea. I agree that it should still be considered for DMD2. As I see it, this would not be a new feature on its own, but rather a modification to round up the existing set of features. Of course, the $ symbol would not be valid for these literals. Indeed -- the $ has nothing to do with the "range" but rather with the indexing expression within which it appears. I also have a proposal for slicing along the same lines, but I'll leave that for later. This was discussed along with it and is actually essential for the concept: With a..b turning into an expression of its own, 'opSlice' is not needed any more. The same effect could be achieved by overloading opIndex for the range expression's type. The whole idea is crucial for implementing multidimensional arrays. It is the simplest way to allow implementing mixed indexing expressions like myarray[a,b..c,d]
Re: Fixing std.string
On 20/08/10 03:22, dsimcha wrote: 3. Is there any good reason to avoid just templating everything to work with all 9 string types (mutable/const/immutable char/wchar/dchar[]) or whatever subset is reasonable for the given function? Wouldn't it be sufficient to take const as input? IIRC, both mutable and immutable can be implicitly converted to const and this exactly the purpose that const is designed for: data that I can't change but that other code may be able to change. Or am I mixing something up here?
Re: Fixing std.string
Norbert Nemec wrote: On 20/08/10 03:22, dsimcha wrote: 3. Is there any good reason to avoid just templating everything to work with all 9 string types (mutable/const/immutable char/wchar/dchar[]) or whatever subset is reasonable for the given function? Wouldn't it be sufficient to take const as input? IIRC, both mutable and immutable can be implicitly converted to const and this exactly the purpose that const is designed for: data that I can't change but that other code may be able to change. Or am I mixing something up here? What should the functions return, then? If the output is always const(char)[], I need to cast it to make it immutable(char)[] or char[], and casting is an unsafe operation. -- Simen
Re: Why C++ compiles slowly
Walter Bright: > elf_findstr definitely looks like a problem area. I can't look at it right > now, > so can you post this to bugzilla please? I am able to find two versions of elf_findstr, one in elfobj.c and one in machobj.c, so it may be possible to remove one of them. Its docstring doesn't seem to show the 'suffix' argument. I have seen that it performs strlen() of str and suffix at the beginning, so using fat pointers (C structs that keep ptr + len) as D may be enough to avoid those strelen calls and save some time. >From what I see it seems to perform a linear search inside an Outbuffer, >something like a search of strtab~strs inside an array of strings, so the >structure may be replaced by an associative set or ordered set lookup instead. Bye, bearophile
Why all the D hate?
- GDB developers refsue to apply up to date D patches - the language shootout included ALL other relevant languages, but hated D. This is very bad - D wiki had CSS style competition but someone wanted to keep the boring looking style. Wiki has sometimes also disk space problem - no Tango for D 2.0 (trying be fair and equal here. not only phobos!) - Lots of people constantly complaining D 2.0 situation - and suggesting feature improvements - forum trolls - many good software died. I need ddbi, kate intellisense plugin (not compatible anymore) - the forum web interfaces are bad. broken trees of message topics - when is time for (safe) d on dot net / java? When this all stops? When is D stable and we can build compilers and editors and debuggers and bring it back in language shootout (very bad for advertising D to have no D in the page!)
Re: contracts for external functions?
extern(C) int foo(int i)
in { assert(i > 7); }
out (result) { assert(result & 1); }
http://d.puremagic.com/issues/show_bug.cgi?id=4720
Re: How does D handle null pointers?
On Mon, 23 Aug 2010 16:30:15 -0400, Adam B wrote:
I was pondering bearophile's idea of having compile-time null
checking. Since adding new language syntax is often a hard thing to
sell to the language authors, perhaps we could get by with just a
compiler warning? Some static code analysis. For example:
--
char[] foo()
{
if (some condition)
return "yada";
else
return null; //compiler makes note that foo() might
return null
}
void bar()
{
char[] s = foo();
printf(s); //compiler issues warning because 's' has not been
null-checked
}
--
Or, if that's too heavy for the compiler, it could be done in a
separate program. (Is there a Lint like program for D?)
This kind of analysis is not possible by the compiler because of the
compilation model. Essentially, it's possible to force the compiler to
compile bar without having access to the source code of foo. Without
access to the source code, it cannot tell whether the result will be null
or not.
The object file format does not provide places to store such metadata
(whether a function returns null or not), so it's not possible to resolve
this. There are other compilation models which allow storage of metadata,
and I'm in favor of having such a system, but it would be a drastic change
from the current model. But essentially such a model allows complex
analysis of the code (including full escape analysis), and also allows you
to avoid sync problems such as compiling against newer sources but linking
with stale objects.
-Steve
Re: Algorithms & opApply
On Tue, 24 Aug 2010 01:59:51 -0400, Fawzi Mohamed wrote:
On 24-ago-10, at 04:26, dsimcha wrote:
[...]
3. Ranges are the flagship way of iterating through an object in D, as
they
should be. opApply has its uses, but they're relatively few and far
between. I'm
wondering if anyone besides bearophile and I think supporting opApply
is worth the
effort and potential bloat, if Walter cares enough to fix Bug 2443, and
if Andrei
considers it to be a reasonable part of std.range/std.algorithm's
design.
I already defended opApply in the past let me put this here again:
ranges abstract away one iteration step. This is useful because it means
that combining several of them, adancing in locksteo,... is possible and
easy to do
opApply abstracts away a whole loop. This makes complex loops simpler to
realize without having to resort to fibers, and it allows *parallel*
looping in a natural way (which cannot be done directly using only
single iteration operations.
In blip/dchem I use this quite a bit (for example for parallel loop
helpers, often my objects have obj.sLopp
obj.pLoop(blocksize=dafaultVal)).
I like very much to be able to do foreach (x;obj.pLoop){...}
Now they obviously are different kinds of abstractions, so looping in
lockstep is not possible with opApply, at most you can lockstep *one*
opApply with N iterators.
About the operations in algorithm well I am not too sure how much
support there should be, if they require just looping then yes, but (for
example) I think that almost all of them would fail if feeded with a
parallel opApply.
For sequential loops fibers can transform opApply in an iterator (just
as fibers can be used to easily make an iterator out of a complex loop).
But fiber have a relatively high cost.
So I suppose I would give support just to the basic stuff + conversion
for sequential loops (via fibers), keeping most of std.algorithm opApply
free
Building on this, (I once asked "do we need opApply anymore?"), I know of
several reasons ranges do not replace opApply:
1. opApply is a more natural fit for virtual functions.
2. opApply can use the stack, ranges cannot. This is useful for say
iterating a binary tree without parent pointers.
3. opApply supports the full syntax of foreach, which can include multiple
parameters in the loop.
I have proposed an enhancement in the past to make all callable symbols
foreachable, including delegates, normal functions, and functors. This
would obviate the need for a special "opApply" function (just use opCall
with the proper signature).
The bug is here: http://d.puremagic.com/issues/show_bug.cgi?id=2498
-Steve
Re: Why C++ compiles slowly
On Tue, 24 Aug 2010 03:58:57 -0400, Walter Bright wrote: Steven Schveighoffer wrote: With profiling enabled, gprof outputs this as the top hitters: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 77.76 6.68 6.68 2952 2.26 2.26 elf_findstr(Outbuffer*, char const*, char const*) 2.10 6.86 0.18 4342 0.04 0.04 searchfixlist elf_findstr definitely looks like a problem area. I can't look at it right now, so can you post this to bugzilla please? http://d.puremagic.com/issues/show_bug.cgi?id=4721 -Steve
Re: Why all the D hate?
On 08/24/2010 02:14 PM, igabrieL wrote: - GDB developers refsue to apply up to date D patches - the language shootout included ALL other relevant languages, but hated D. This is very bad - D wiki had CSS style competition but someone wanted to keep the boring looking style. Wiki has sometimes also disk space problem - no Tango for D 2.0 (trying be fair and equal here. not only phobos!) - Lots of people constantly complaining D 2.0 situation - and suggesting feature improvements - forum trolls - many good software died. I need ddbi, kate intellisense plugin (not compatible anymore) - the forum web interfaces are bad. broken trees of message topics - when is time for (safe) d on dot net / java? When this all stops? When is D stable and we can build compilers and editors and debuggers and bring it back in language shootout (very bad for advertising D to have no D in the page!) Lack of time and an abundance of trolls, mostly. And angry people from C++ land, but they are probably trolls. A lot of people is looking forward to what D is becoming, at least that has been my interpretation of forum discussions.
Re: Why all the D hate?
"Those who can, do. Those who can't, complain." -- Attributed to Linus Torvalds on Wikipedia.
Re: Why all the D hate?
Probably answering to a troll, but.. Tue, 24 Aug 2010 08:14:37 -0400, igabrieL wrote: > - GDB developers refsue to apply up to date D patches This is a copyright issue. GDB is owned by the FSF and you cannot use any Digital Mars code in it. You need to assign the copyright to them. > - the language shootout included ALL other relevant languages, but hated D. This is very bad I'm not sure what happened. It seams the shootout guy did not consider D revolutionary enough. It could also be the lack of a 64-bit compiler. He runs the tests on both 32 and 64-bit systems. When the 64-bit compiler comes out, maybe he has no reasons to leave it out. The benchmark code was already there, wasn't it. > - D wiki had CSS style competition but someone wanted to keep > the boring looking style. Wiki has sometimes also disk space problem No idea. > - no Tango for D 2.0 (trying be fair and equal here. not only phobos!) Maybe it will ported when D 2.0 is safe to use? First we need to be able to compile all examples shown in TDPL. > - Lots of people constantly complaining D 2.0 situation - and suggesting > feature improvements I believe D attracts people who want to leave their hand-mark in the language's design. The community members see that the language is in a constant 'work in progress' phase so they're dumping truckloads of feature suggestions before the language's author. These suggestions are mostly syntactical improvements taken from other languages because the community members rarely have any kind of knowledge in the field of programming language theory. > - forum trolls Thanks! > - many good software died. I need ddbi, kate intellisense plugin (not > compatible anymore) Please contribute! - the forum web interfaces are bad. broken trees of > message topics Please contribute! Write one in D. > - when is time for (safe) d on dot net / java? The SafeD spec needs to be beefed up quite a bit to be any useful for compiler writers. I think having a SafeD environemnt on .NET/JVM might be an interesting exercise. However, the language doesn't have many interesting new features to justify its existence on either platform. > > When this all stops? When is D stable and we can build compilers and > editors and debuggers and bring it back in language shootout (very bad > for advertising D to have no D in the page!) Already answered.
Re: Why all the D hate?
On 24/08/10 13:14, igabrieL wrote: - the language shootout included ALL other relevant languages, but hated D. This is very bad I recall that this was due to the lack of 64bit support and the lack of a Debian package that would work out of the box. The latter problem may be solved by now, but the site maintainer decided to wait for 64bit DMD to come out. - Lots of people constantly complaining D 2.0 situation - and suggesting feature improvements I view the latter point a clear sign of *love* not hate. The language is great and inspiring many ideas. People see that many good ideas have been picked up through discussion so they throw in their ideas as well. I see it as one big bonus of the D community that there is this forum in which newcomers and experts alike discuss their ideas freely and actually make a direct impact on the development. When this all stops? When is D stable and we can build compilers and editors and debuggers and bring it back in language shootout (very bad for advertising D to have no D in the page!) I doubt it will "stop" at any fixed point in time, but the situation has been improving gradually and I am optimistic that it will continue to do so.
update zlib used in phobos?
Phobos still uses 5 years old zlib 1.2.3 Couldn't that be updated to v1.2.5 (April 19, 2010)?
Re: update zlib used in phobos?
On Tue, Aug 24, 2010 at 07:29:57PM +0200, Trass3r wrote: > Phobos still uses 5 years old zlib 1.2.3 > Couldn't that be updated to v1.2.5 (April 19, 2010)? Yes, Walter and Andrei are planning to update it in the next month or so.
Re: Why all the D hate?
== Quote from retard (r...@tard.com.invalid)'s article > I believe D attracts people who want to leave their hand-mark in the > language's design. The community members see that the language is in a > constant 'work in progress' phase so they're dumping truckloads of > feature suggestions before the language's author. > These suggestions are mostly syntactical improvements taken from other > languages because the community members rarely have any kind of knowledge > in the field of programming language theory. IMHO this is a good thing as long as the language designer has enough of a backbone to know when to say no to things. (Except for the @property debacle I'd say Walter is such a language designer.) Maybe it's just my engineering background creeping in (like Walter, I have very little formal CS education and my degree is in engineering) but I **don't want** a language designed heavily from a theoretical perspective. I want a language that will make it easy for me to write efficient, readable, safe, terse, flexible and DRY code, not one that showcases cutting edge theoretical comp sci achievements. In fact the features of D that seem most theoretically grounded (the pure/nothrow/const/shared type system stuff) are my least favorite features of the language, largely because they interact so poorly with generic programming, which is more of a practical feature IMHO. > The SafeD spec needs to be beefed up quite a bit to be any useful for > compiler writers. Agreed. The implementation needs improvement as well. I refuse to take SafeD at all seriously until I can at least use it with std.getopt. I refuse to take it very seriously until it integrates well with generic programming. > I think having a SafeD environemnt on .NET/JVM might be > an interesting exercise. However, the language doesn't have many > interesting new features to justify its existence on either platform. Don't D's compile-time introspection and generic programming abilities count for something? They're the biggest reason I use D over C# or Java, and AFAIK D is the most mainstream language with a comparable level of compile time metaprogramming ability.
Re: Why all the D hate?
On Tue, 24 Aug 2010 13:44:38 -0400, dsimcha wrote: == Quote from retard (r...@tard.com.invalid)'s article I believe D attracts people who want to leave their hand-mark in the language's design. The community members see that the language is in a constant 'work in progress' phase so they're dumping truckloads of feature suggestions before the language's author. These suggestions are mostly syntactical improvements taken from other languages because the community members rarely have any kind of knowledge in the field of programming language theory. IMHO this is a good thing as long as the language designer has enough of a backbone to know when to say no to things. (Except for the @property debacle I'd say Walter is such a language designer.) Why all the @property hate? ;) -Steve
Re: Why C++ compiles slowly
Steven Schveighoffer wrote: On Tue, 24 Aug 2010 03:58:57 -0400, Walter Bright wrote: Steven Schveighoffer wrote: With profiling enabled, gprof outputs this as the top hitters: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 77.76 6.68 6.68 2952 2.26 2.26 elf_findstr(Outbuffer*, char const*, char const*) 2.10 6.86 0.18 4342 0.04 0.04 searchfixlist elf_findstr definitely looks like a problem area. I can't look at it right now, so can you post this to bugzilla please? http://d.puremagic.com/issues/show_bug.cgi?id=4721 Also, putting a printf in elf_findstr to print its arguments will be helpful.
Re: Why all the D hate?
igabrieL wrote: - and suggesting feature improvements [...] When is D stable It cannot be both stable and adding in endless new features.
Re: Why all the D hate?
dsimcha wrote: I think having a SafeD environemnt on .NET/JVM might be an interesting exercise. However, the language doesn't have many interesting new features to justify its existence on either platform. Don't D's compile-time introspection and generic programming abilities count for something? They're the biggest reason I use D over C# or Java, and AFAIK D is the most mainstream language with a comparable level of compile time metaprogramming ability. What we may be seeing here is an effect I noticed decades ago with the Zortech compiler. Let's say you have the Zortech compiler, and BrandX compiler. The feature lists of the two are: Zortech: A B C M N O S T U BrandX: A B C D M N O Reviewer concludes that Zortech lacks features because it doesn't do D. Reviewer never notices S T U because he's used to BrandX and so obviously S T U are not relevant. It's a very human thing. For example, back in 1995, a friend of mine would interview engineers. He'd show them a cell phone, and ask them how they would improve it. He'd get answers that were simple refinements of making phone calls. Nobody suggested adding a calculator, calendar, texting, email, music playing, a camera, etc. It simply never occurred to them because people thought of a phone as a phone, nothing more. Back in the 80's, I knew about OOP but saw no value in it. I'd never used it, and had no idea how to. It certainly wasn't on any of my "it would be nice if..." desires for a programming language feature.
Re: Why all the D hate?
retard, el 24 de agosto a las 15:36 me escribiste: > Probably answering to a troll, but.. > > > Tue, 24 Aug 2010 08:14:37 -0400, igabrieL wrote: > > > - GDB developers refsue to apply up to date D patches > > This is a copyright issue. GDB is owned by the FSF and you cannot use any > Digital Mars code in it. You need to assign the copyright to them. That's true, but I don't know where the original affirmation come from, who is trying to push patches to GDB now? I followed very closely the inclusion of D support patches in GDB and it took a lot of time to merge them because nobody cared to do it. When someone tried to do it, he just did (it took some time because of the paperwork needed, because as retard say, you have to assign the copyright to the FSF to include big changes, as D support patches was). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- TIGRE SE COMIO A EMPLEADO DE CIRCO: DETUVIERON A DUEÑO Y DOMADOR -- Crónica TV
Re: Why all the D hate?
== Quote from Walter Bright (newshou...@digitalmars.com)'s article > dsimcha wrote: > >> I think having a SafeD environemnt on .NET/JVM might be > >> an interesting exercise. However, the language doesn't have many > >> interesting new features to justify its existence on either platform. > > > > Don't D's compile-time introspection and generic programming abilities > > count for > > something? They're the biggest reason I use D over C# or Java, and AFAIK D > > is the > > most mainstream language with a comparable level of compile time > > metaprogramming > > ability. > What we may be seeing here is an effect I noticed decades ago with the Zortech > compiler. Let's say you have the Zortech compiler, and BrandX compiler. The > feature lists of the two are: > Zortech: A B C M N O S T U > BrandX: A B C D M N O > Reviewer concludes that Zortech lacks features because it doesn't do D. > Reviewer > never notices S T U because he's used to BrandX and so obviously S T U are not > relevant. > It's a very human thing. For example, back in 1995, a friend of mine would > interview engineers. He'd show them a cell phone, and ask them how they would > improve it. He'd get answers that were simple refinements of making phone > calls. > Nobody suggested adding a calculator, calendar, texting, email, music > playing, a > camera, etc. It simply never occurred to them because people thought of a > phone > as a phone, nothing more. > Back in the 80's, I knew about OOP but saw no value in it. I'd never used it, > and had no idea how to. It certainly wasn't on any of my "it would be nice > if..." desires for a programming language feature. http://en.wikipedia.org/wiki/Loss_aversion
Re: Why all the D hate?
Tue, 24 Aug 2010 17:44:38 +, dsimcha wrote: >> I think having a SafeD environemnt on .NET/JVM might be an interesting >> exercise. However, the language doesn't have many interesting new >> features to justify its existence on either platform. > > Don't D's compile-time introspection and generic programming abilities > count for something? They're the biggest reason I use D over C# or > Java, and AFAIK D is the most mainstream language with a comparable > level of compile time metaprogramming ability. Those are quite expressive features. However, without the close to metal aspect, D is too close to C# in my opinion. The metaprogramming things surely help when cleaning up useless boilerplate, but they aren't enough. Ruby, Python, Clojure, and F# all have more powerful features on top of a modern virtual machine and people seem to favor (J)Ruby and Python these days.
Re: Why all the D hate?
"retard" wrote in message news:i50ou2$v0...@digitalmars.com... > > I think having a SafeD environemnt on .NET/JVM might be > an interesting exercise. However, the language doesn't have many > interesting new features to justify its existence on either platform. > Aside from being a questionable statement, it's not particularly important either, since being able run the same code on multiple platforms IS often a significant feature. That's one of the reasons I'm using Haxe for a Flash/PHP project.
Re: Why all the D hate?
"retard" wrote in message news:i516du$v0...@digitalmars.com... > Tue, 24 Aug 2010 17:44:38 +, dsimcha wrote: > >>> I think having a SafeD environemnt on .NET/JVM might be an interesting >>> exercise. However, the language doesn't have many interesting new >>> features to justify its existence on either platform. >> >> Don't D's compile-time introspection and generic programming abilities >> count for something? They're the biggest reason I use D over C# or >> Java, and AFAIK D is the most mainstream language with a comparable >> level of compile time metaprogramming ability. > > Those are quite expressive features. However, without the close to metal > aspect, D is too close to C# in my opinion. So if you're writing something that needs to run on .NET, and you have to choose between [what you see as] two nearly identical languages, but one has good generic programming and the other just has generics, and they're ridiculously gimped generics at that, you'd rather use the latter?
Re: Why all the D hate?
Tue, 24 Aug 2010 15:37:52 -0400, Nick Sabalausky wrote: > "retard" wrote in message > news:i516du$v0...@digitalmars.com... >> Tue, 24 Aug 2010 17:44:38 +, dsimcha wrote: >> I think having a SafeD environemnt on .NET/JVM might be an interesting exercise. However, the language doesn't have many interesting new features to justify its existence on either platform. >>> >>> Don't D's compile-time introspection and generic programming abilities >>> count for something? They're the biggest reason I use D over C# or >>> Java, and AFAIK D is the most mainstream language with a comparable >>> level of compile time metaprogramming ability. >> >> Those are quite expressive features. However, without the close to >> metal aspect, D is too close to C# in my opinion. > > So if you're writing something that needs to run on .NET, and you have > to choose between [what you see as] two nearly identical languages, but > one has good generic programming and the other just has generics, and > they're ridiculously gimped generics at that, you'd rather use the > latter? For what's it worth, C# 4.0 also has many impressive features. You can see the list somewhere - something for the friends of dynamic typing, LINQ, lambda expressions etc. And it's not broken / a moving target 99% of the time => I can find 100 other commercial C# coders in just a few days.
How about a nabble forum archive?
Hello, I'm just wondering, would it be possible to register this mailing list on nabble? Replies would be grouped in topics and indexed for full text search, I think it would make this mailing list more convenient to use. Result looks like this http://lucene.472066.n3.nabble.com/Solr-User-f472068.html Just an idea, what do you think?
Re: Why all the D hate?
"igabrieL" wrote in message news:i50d3d$d1...@digitalmars.com... > - no Tango for D 2.0 (trying be fair and equal here. not only phobos!) http://www.dsource.org/projects/tango/forums/topic/883
Re: Why all the D hate?
"retard" wrote in message news:i51963$v0...@digitalmars.com... > > I can find 100 other commercial C# coders in just a few > days. Now, see that's something that always bugs the hell out of me. Any programmer who can code in, say imperative or OO style in one language and *can't* pick up another imperative or OO language with ease is incompetent. Period. But no one outside of (real) programmers ever seems to realize that. (One of the reasons I despise anyone who works anywhere near HR.) I don't always agree with Joel Spolsky (though I often do), but one thing I *absolutely* agree with him on is this: "The recruiters-who-use-grep, by the way, are ridiculed here, and for good reason. I have never met anyone who can do Scheme, Haskell, and C pointers who can't pick up Java in two days, and create better Java code than people with five years of experience in Java, but try explaining that to the average HR drone." - The Perils of JavaSchools: http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html Incidentally, that's also why I think all of those managers out there who choose PHP because "there are a lot of PHP programmers" are complete fucking morons.
Re: Why all the D hate?
Tue, 24 Aug 2010 16:29:01 -0400, Nick Sabalausky wrote: > "retard" wrote in message > news:i51963$v0...@digitalmars.com... >> >> I can find 100 other commercial C# coders in just a few days. > > Now, see that's something that always bugs the hell out of me. Any > programmer who can code in, say imperative or OO style in one language > and *can't* pick up another imperative or OO language with ease is > incompetent. Period. But no one outside of (real) programmers ever seems > to realize that. (One of the reasons I despise anyone who works anywhere > near HR.) > > I don't always agree with Joel Spolsky (though I often do), but one > thing I *absolutely* agree with him on is this: > > "The recruiters-who-use-grep, by the way, are ridiculed here, and for > good reason. I have never met anyone who can do Scheme, Haskell, and C > pointers who can't pick up Java in two days, and create better Java code > than people with five years of experience in Java, but try explaining > that to the average HR drone." > > - The Perils of JavaSchools: > http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html > > Incidentally, that's also why I think all of those managers out there > who choose PHP because "there are a lot of PHP programmers" are complete > fucking morons. The C# programmers naturally also have knowledge of the toolchain in general: build tools, unit testing tools, document generators, coding conventions, web frameworks, best utility libraries, and so on. Do you think commercial application development always starts from scratch? Even if you were Joel Spolsky, you would need few days or weeks to catch up with the more experienced team members. Unnecessary studying isn't acceptable when you need to produce a prototype in a week and the whole project only lasts for 6 months.
Re: Why C++ compiles slowly
On Tue, 24 Aug 2010 14:31:26 -0400, Walter Bright
wrote:
Steven Schveighoffer wrote:
On Tue, 24 Aug 2010 03:58:57 -0400, Walter Bright
wrote:
Steven Schveighoffer wrote:
With profiling enabled, gprof outputs this as the top hitters:
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls ms/call ms/call name
77.76 6.68 6.68 2952 2.26 2.26
elf_findstr(Outbuffer*, char const*, char const*)
2.10 6.86 0.18 4342 0.04 0.04 searchfixlist
elf_findstr definitely looks like a problem area. I can't look at it
right now, so can you post this to bugzilla please?
http://d.puremagic.com/issues/show_bug.cgi?id=4721
Also, putting a printf in elf_findstr to print its arguments will be
helpful.
Through some more work with printf, I have to agree with bearophile, this
lookup function is horrid.
I think it's supposed to look for a symbol in the symbol table, but it
uses a linear search through all symbols to find it. Not only that, but
the table is stored in one giant buffer, so once it finds the current
symbol it's checking against doesn't match, it has to still loop through
the remaining characters of the unmatched symbol to find the next 0 byte.
I added a simple running printout of how many times the function has been
called, along with how large the symbol table has grown.
The code is as follows:
static IDXSTR elf_findstr(Outbuffer *strtab, const char *str, const char
*suffix)
{
+static int ncalls = 0;
+ncalls++;
+printf("\r%d\t%d", ncalls, strtab->size());
+fflush(stdout);
const char *ent = (char *)strtab->buf+1;
const char *pend = ent+strtab->size() - 1;
At the end, the symbol table is over 4 million characters and the number
of calls is 12677. You can watch it slow down noticeably.
I also added some code to count the number of times a symbol is matched --
648, so about 5% of the time. This means that 95% of the time, the whole
table is searched.
If you multiply those factors together, and take into account the nature
of how it grows, you have probably 20 billion loop iterations. Whereas, a
hash table would probably be much faster. I'm thinking a correct
compilation time should be on the order of 3-4 seconds vs. 67 seconds it
now takes.
I am not sure how to fix it, but that's the gist of it. I think the
symbol table is so large because of the template proliferation of
dcollections, and the verbosity of D symbol names.
-Steve
Re: Why C++ compiles slowly
Am 24.08.2010 22:56, schrieb Steven Schveighoffer: I am not sure how to fix it, but that's the gist of it. I think the symbol table is so large because of the template proliferation of dcollections, and the verbosity of D symbol names. Why are D's symbols verbose? if I understood you corectly, dmd makes a linear search no matter if i used foo or ArrayOutOfBoundsException (that's a real Java exception).
Re: Why all the D hate?
"retard" wrote in message news:i51b74$v0...@digitalmars.com... > Tue, 24 Aug 2010 16:29:01 -0400, Nick Sabalausky wrote: > >> "retard" wrote in message >> news:i51963$v0...@digitalmars.com... >>> >>> I can find 100 other commercial C# coders in just a few days. >> >> Now, see that's something that always bugs the hell out of me. Any >> programmer who can code in, say imperative or OO style in one language >> and *can't* pick up another imperative or OO language with ease is >> incompetent. Period. But no one outside of (real) programmers ever seems >> to realize that. (One of the reasons I despise anyone who works anywhere >> near HR.) >> >> I don't always agree with Joel Spolsky (though I often do), but one >> thing I *absolutely* agree with him on is this: >> >> "The recruiters-who-use-grep, by the way, are ridiculed here, and for >> good reason. I have never met anyone who can do Scheme, Haskell, and C >> pointers who can't pick up Java in two days, and create better Java code >> than people with five years of experience in Java, but try explaining >> that to the average HR drone." >> >> - The Perils of JavaSchools: >> http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html >> >> Incidentally, that's also why I think all of those managers out there >> who choose PHP because "there are a lot of PHP programmers" are complete >> fucking morons. > > The C# programmers naturally also have knowledge of the toolchain in > general: build tools, unit testing tools, document generators, coding > conventions, web frameworks, best utility libraries, and so on. Do you > think commercial application development always starts from scratch? Even > if you were Joel Spolsky, you would need few days or weeks to catch up > with the more experienced team members. Unnecessary studying isn't > acceptable when you need to produce a prototype in a week and the whole > project only lasts for 6 months. There's always a learning/ramp-up period anyway when bringing on new team member. They have to get acclimated to the existing codebase and how the group has everything set up and policies/procedures, etc, all of which will vary from company to company even with the same langauge. When I took my first web development job, it was an ASP house (this was before ASP.NET), and I had never even looked at a line of ASP in my life, but learning it was trivial, especially compared to picking up the company-specific stuff. And if a manager goes hiring programmers when time's already tight, then the manager is an idiot because getting the new people up-to-speed is only going to cause more delay even if the language is the same (and again, the time to pick up the language is small compared to the other stuff). That's been shown time and time again.
Re: Why C++ compiles slowly
On Tue, 24 Aug 2010 17:05:30 -0400, Mafi wrote: Am 24.08.2010 22:56, schrieb Steven Schveighoffer: I am not sure how to fix it, but that's the gist of it. I think the symbol table is so large because of the template proliferation of dcollections, and the verbosity of D symbol names. Why are D's symbols verbose? if I understood you corectly, dmd makes a linear search no matter if i used foo or ArrayOutOfBoundsException (that's a real Java exception). A symbol includes the module name, and the mangled version of the function argument types, which could be class/struct names, plus any template info associated with it. For example, foo(HashSet!int hs) inside the module testme becomes: _D6testme3fooFC12dcollections7HashSet14__T7HashSetTiZ7HashSetZv -Steve
Re: Why C++ compiles slowly
On 2010-08-24 12:25, bearophile wrote: Walter Bright: elf_findstr definitely looks like a problem area. I can't look at it right now, so can you post this to bugzilla please? I am able to find two versions of elf_findstr, one in elfobj.c and one in machobj.c, so it may be possible to remove one of them. As the files indicate elfobj.c is for generating ELF (linux) object files and machobj.c is for generating Mach-O (osx) object files, both are needed. I guess he uses the same name for the functions to have a uniform interface, no need to change the code on the calling side. Its docstring doesn't seem to show the 'suffix' argument. I have seen that it performs strlen() of str and suffix at the beginning, so using fat pointers (C structs that keep ptr + len) as D may be enough to avoid those strelen calls and save some time. From what I see it seems to perform a linear search inside an Outbuffer, something like a search of strtab~strs inside an array of strings, so the structure may be replaced by an associative set or ordered set lookup instead. Bye, bearophile -- /Jacob Carlborg
Re: Why C++ compiles slowly
Steven Schveighoffer: > For example, foo(HashSet!int hs) inside the module testme becomes: > _D6testme3fooFC12dcollections7HashSet14__T7HashSetTiZ7HashSetZv And I think some more things needs to be added to that string, like a representation for the pure attribute, etc. Bye, bearophile
Re: Why all the D hate?
On Tue, 24 Aug 2010, Leandro Lucarella wrote: > retard, el 24 de agosto a las 15:36 me escribiste: > > Probably answering to a troll, but.. > > > > > > Tue, 24 Aug 2010 08:14:37 -0400, igabrieL wrote: > > > > > - GDB developers refsue to apply up to date D patches > > > > This is a copyright issue. GDB is owned by the FSF and you cannot use any > > Digital Mars code in it. You need to assign the copyright to them. > > That's true, but I don't know where the original affirmation come from, > who is trying to push patches to GDB now? I followed very closely the > inclusion of D support patches in GDB and it took a lot of time to merge > them because nobody cared to do it. When someone tried to do it, he just > did (it took some time because of the paperwork needed, because as > retard say, you have to assign the copyright to the FSF to include big > changes, as D support patches was). > I also have evidence that follow up patches to fix simple bugs aren't hard to get submitted to GDB. Mine was small enough to not need a copyright assignment form and only took a week or two -- mostly just that I didn't ping anyone after sending it to the patch mailing list. Later, Brad
Re: Why C++ compiles slowly
On Tuesday, August 24, 2010 14:37:09 bearophile wrote: > Steven Schveighoffer: > > For example, foo(HashSet!int hs) inside the module testme becomes: > > _D6testme3fooFC12dcollections7HashSet14__T7HashSetTiZ7HashSetZv > > And I think some more things needs to be added to that string, like a > representation for the pure attribute, etc. > > Bye, > bearophile They probably aren't there because 1. They have nothing to do with overrideability. 2. They have nothing to do with C linking. Presumably, dmd deals with those attributes at the appropriate time and then doesn't bother putting them in the symbol table because they're not relevant any more (or if they are relevant, it has other ways of getting at them). If they were actually necessary in the symbol name, they'd be there. If they aren't necessary, why bother putting them in there, making the symbol names even longer? - Jonathan M Davis
Re: Why all the D hate?
Tue, 24 Aug 2010 17:21:56 -0400, Nick Sabalausky wrote: > And if a manager goes hiring programmers when time's already tight, then > the manager is an idiot because getting the new people up-to-speed is > only going to cause more delay even if the language is the same (and > again, the time to pick up the language is small compared to the other > stuff). That's been shown time and time again. It's a bit different where I've worked. Most contracts were really short. You participate in about 3 to 12 smaller web service projects during the year. We rarely hired any juniors, you had to have 5+ years of real life commercial experience with typical frameworks (Stripes, Spring, Hibernate, Memcached, ASP.Net, Rails, Django, Symfony, jQuery, Maven, Apache configuration, SVN, Git, GCC, etc.). Sometimes a single project took only couple of months - a prototype milestone had a really tight schedule.
Re: Why C++ compiles slowly
Steven Schveighoffer wrote: Through some more work with printf, I have to agree with bearophile, this lookup function is horrid. It is now, but when it was originally written (maybe as long as 20 years ago) there were only a few strings in the table, and it was fine. It's just outlived its design. Clearly, it should now be a hash table. Just goes to show how useful a profiler is.
Re: Why C++ compiles slowly
On Tue, 24 Aug 2010 23:53:44 +0200, Jonathan M Davis wrote: On Tuesday, August 24, 2010 14:37:09 bearophile wrote: Steven Schveighoffer: > For example, foo(HashSet!int hs) inside the module testme becomes: > _D6testme3fooFC12dcollections7HashSet14__T7HashSetTiZ7HashSetZv And I think some more things needs to be added to that string, like a representation for the pure attribute, etc. Bye, bearophile They probably aren't there because 1. They have nothing to do with overrideability. 2. They have nothing to do with C linking. Presumably, dmd deals with those attributes at the appropriate time and then doesn't bother putting them in the symbol table because they're not relevant any more (or if they are relevant, it has other ways of getting at them). If they were actually necessary in the symbol name, they'd be there. If they aren't necessary, why bother putting them in there, making the symbol names even longer? Pure might be worth stuffing in the symbol name, as the compiler may optimize things differently for pure vs. non-pure(dirty?) code. E.g. the result of a large, pure function that takes a while to compute might be cached to prevent calling it twice. -- Simen
Re: Why C++ compiles slowly
== Quote from Walter Bright (newshou...@digitalmars.com)'s article > Steven Schveighoffer wrote: > > Through some more work with printf, I have to agree with bearophile, > > this lookup function is horrid. > It is now, but when it was originally written (maybe as long as 20 years ago) > there were only a few strings in the table, and it was fine. It's just > outlived > its design. Clearly, it should now be a hash table. > Just goes to show how useful a profiler is. Wow, now it's really hit home for me how much programming languages and libraries have advanced in the past 20 years. Nowadays any reasonable person would generally use a hash table even for small N because it's not any harder to code. Any modern language worth its salt comes with one either built in or in the standard lib. I guess 20 years ago this wasn't so.
Re: Why C++ compiles slowly
Jonathan M Davis: > They probably aren't there because > ... In Bugzilla there are some pure-related bugs (3833, 3086/3831, maybe 4505) that I think need that attribute in the mangled string. But as usual I may be wrong, and other ways to solve those problems may be invented. Bye, bearophile
Re: Self-compilation
On 08/22/2010 06:28 PM, Pedro Rodrigues wrote: There are already projects aiming to write a D compiler in D: http://www.dsource.org/projects/ddmd http://github.com/azizk/dil/ Regards Thanks for all the answers, but I was looking more for an official compiler, but it's great that there's people working on it. I don't know about anybody else, but languages that can compile themselves make me smile. Casey
Re: Self-compilation
languages that can compile themselves make me smile. Yep ddmd is a wonderful project :)
Link to that D doc-search tool?
Someone created a webpage a little while ago to jump to the D documentation for a given identifier. What was the URL to that? In a real example of irony, I searched the NG for that search tool, but couldn't find it.
