Re: Contract checking (Re: enforce()?)
On Wed, 30 Jun 2010 20:03:07 +0100, Norbert Nemec wrote: On 30/06/10 17:45, Sean Kelly wrote: Norbert Nemec Wrote: On 28/06/10 12:59, bearophile wrote: Norbert Nemec: [...] to place code for input contract checking in the *calling* code. [...] Output contract checks, on the other hand should be compiled inside the returning routine. Is this a positive thing to do? Can this be done? (D must support separate compilation, but in many situations this is not done/necessary, so maybe in such situations it can be done). Is Eiffel doing it? if it's a good thing and it's doable then what kind of changes does it require to the compiler? These are good and pragmatic questions that you ask. The whole issue only arises when doing separate compilation of a library and an application. (I use the term application for any code that uses the library.) In an idea world (beware, I am switching of pragmatic thinking mode for a moment), I would describe the situation would as follows: Either part can be compiled in debug mode or in release mode. Debug mode in the library means that you want to debug the library code itself. Release mode in the library means that you trust the library code to be correct and switch off all internal checks. I see the choice of release for disabling contracts as a huge mistake in nomenclature. For libraries, I would ship a checked and unchecked build (with -release disabled and enabled), but none with -debug or -unittest set. Those are for internal testing and the user shouldn't care to turn on debug code in a library simply because he's debugging his own app. The idea of compiling the in contract into the application code is an interesting one, but I suspect it could be tricky. Consider an unchecked build of the library, a checked build of the app, and now taking the address of a library function. Worse, what if a library routine returns the address of another library routine? Now the application has a reference to an unchecked version of the function, even if the involved technical hurdles are surmounted (multiple entry points or the like). That's indeed an interesting aspect: Design by Contract (DbC) and function pointers. I am not sure how these concepts would merge properly at all. The contracts are part of the interface, so they should in fact be part of the function pointer type! Of course this would quickly become ridiculous. A strongly object oriented language like Eiffel can in principle do without function pointers. Instead, one can in most cases use classes with virtual functions that offer very similar functionality. A class interface comes with all the contracts, so everything is safe and sound. I really do not know how to deal with function pointers in the clean DbC paradigm. If you assign a function with input contracts to a function pointer, whoever uses the pointer does not know about the contracts. This however, breaks down the strong DbC concept and turns contracts into mere run time checks. Does this mean that D should give up the goal of proper DbC? Simply do the pragmatic thing and pick the best pieces from DbC without worrying about formal completeness? I guess so... This is all very confused, and is reflected in D implementing contracts all wrong. Contracts do not belong to function pointers or any other dynamic state -- they apply to the invoker, and thus the static type. Isn't that obvious? If I have Foo f = getSomeFoo(); result = f.method (args), the args must satisfy the contract for Foo.method(), regardless of what method() in the object returned by getSomeFoo() is willing to accept (it must, of course, not require more than Foo.method() does; TDPL at least gets that right). And the guarantees on result must be those promised by Foo.method(), not some much weaker promise given by method() in its base class (and there is no need to check stronger guarantees made by method() the actual derived object, since the caller didn't ask for them). The D implementation works much too hard to get the wrong result, both in complexities of the compiler and in executing a bunch of irrelevant code that is ignored if it fails in preconditions or succeeds in postconditions, and after all that it fails to enforce requirements it should and to guarantee promises that it should. -- JB
Re: blog: Overlooked Essentials for Optimizing Code
Jesse Phillips schrieb: Is there information on what the output of trace.log and trace.def mean? And I guess I can run the demaingler against this output, any tools already handle this? Documentation of the profilers output would be helpful indeed. That last table in trace.log is self-documenting and already contains the most important information: what function is executed how often, how much time does that take and how much of that time is used within that function itself (Func Time) opposed to the time taken by functions called from that function (Tree Time - Func Time) Don't know about the rest of trace.log though - maybe it's the fan in and fan out, which is essentially the call graph. From it, you can tell why and from where foo() is being called 1000 times when you only thought it should be called 3 times. (which a good profiler will tell you according to Walter on reddit[1])? Also: The output would be much more readable if it was demangled. A tool that parses trace.log and generates a nice (html?) representation of the data would be really cool :-) Cheers, - Daniel [1] http://www.reddit.com/r/programming/comments/dc6ir/overlooked_essentials_for_optimizing_code/c0z4yxu
Re: blog: Overlooked Essentials for Optimizing Code
Daniel Gibson metalcae...@gmail.com wrote in message news:i6fa0l$j7...@digitalmars.com... Jesse Phillips schrieb: Is there information on what the output of trace.log and trace.def mean? And I guess I can run the demaingler against this output, any tools already handle this? Documentation of the profilers output would be helpful indeed. That last table in trace.log is self-documenting and already contains the most important information: what function is executed how often, how much time does that take and how much of that time is used within that function itself (Func Time) opposed to the time taken by functions called from that function (Tree Time - Func Time) Don't know about the rest of trace.log though - maybe it's the fan in and fan out, which is essentially the call graph. From it, you can tell why and from where foo() is being called 1000 times when you only thought it should be called 3 times. (which a good profiler will tell you according to Walter on reddit[1])? Also: The output would be much more readable if it was demangled. A tool that parses trace.log and generates a nice (html?) representation of the data would be really cool :-) An interactively-inspectible one would be really great. (More work though, obviously.)
Re: blog: Overlooked Essentials for Optimizing Code
Nick Sabalausky schrieb: Daniel Gibson metalcae...@gmail.com wrote in message news:i6fa0l$j7...@digitalmars.com... Jesse Phillips schrieb: Is there information on what the output of trace.log and trace.def mean? And I guess I can run the demaingler against this output, any tools already handle this? Documentation of the profilers output would be helpful indeed. That last table in trace.log is self-documenting and already contains the most important information: what function is executed how often, how much time does that take and how much of that time is used within that function itself (Func Time) opposed to the time taken by functions called from that function (Tree Time - Func Time) Don't know about the rest of trace.log though - maybe it's the fan in and fan out, which is essentially the call graph. From it, you can tell why and from where foo() is being called 1000 times when you only thought it should be called 3 times. (which a good profiler will tell you according to Walter on reddit[1])? Also: The output would be much more readable if it was demangled. A tool that parses trace.log and generates a nice (html?) representation of the data would be really cool :-) An interactively-inspectible one would be really great. (More work though, obviously.) Via integration into an IDE maybe? That'd be cool - run the profiler and afterwards click on the function names in the representation to get to the functions and to the points they're called (from the fan in/out data) - maybe with annotations in/next to the source or something like that. If any IDE dev reads this: Proper integration of the profiler would be a killer feature :-) (But honestly I'd be thankful for any IDE with proper auto completion and maybe refactoring that works on Linux - the eclipse plugins don't seem to work for me, codeblocks neither..)
Re: std.concurrency: Returning from spawned function
On Sat, 2010-09-11 at 00:52 -0400, Sean Kelly wrote: dsimcha Wrote: I was thinking about ways to improve std.concurrency w/o compromising its safety or the simplicity of what already works. Isn't it unnecessarily restrictive that a spawned function must return void? Since the spawned thread dies when the spawned function returns, the return value could safely be moved to the owner thread. Therefore, the return values wouldn't even have to be immutable/shared/lacking indirection. The return value could, for example, be stored in Tid, with attempts to retrieve it blocking until the spawned thread returns. That each spawn() results in the creation of a thread whose lifetime ends when the function returns is an implementation details. It could as easily be a thread pool that resets its TLS data when picking up a new operation, user-space thread, etc. In short, I don't think that the behavior of a thread exiting should be a motivating factor for design changes. Does this gain anything over sending a message on exit? I guess it is really a question of message passing versus data parallelism. Clearly in a message passing idiom asynchronous function execution can (possibly should) always be handled by void functions. In a data parallel context you generally want a function that returns the value. The idiom here is to create a sequence and then to create a new sequence which is a function applied to each element of the old sequence delivering a value to the new sequence -- parallel arrays. Algorithmically the computation on each result element is independent, even in the case where non-local read access are allowed, so this is embarrassingly parallel. It is left as a runtime implementation issue as to how the computations map to threads and thence to processors. C ++0x doesn't really get this right, but Chapel and X10 are getting close, but they are full PGAS (partitioned global address space) languages, so they should do. Haskell, via DPH, is also getting there. As indeed in Java -- assuming Java 7 ever makes it into production. I think my real point is that data parallelism shouldn't have to be manually constructed from asynchronous functions, as long as you have closures -- either explicitly or implicitly (as can be constructed with C++ and Java). -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Contract checking (Re: enforce()?)
Jay Byrd: This is all very confused, and is reflected in D implementing contracts all wrong. If you know well the ideas of DbC, and you think there are some problems in the DbC of D2, then I suggest you to not just write what's wrong, why it is wrong and what bad things such wrong design may cause, and what you suggest to change, starting from the most important changes. Maybe Walter will change nothing, but if you write just a little rant where you say that all is wrong, probably nothing will change, and what you have written is useless. Bye, bearophile
Re: Contract checking (Re: enforce()?)
then I suggest you to not just write what's... Ignore that 'not', please.
Re: Overlooked Essentials for Optimizing Code
Walter Bright newshou...@digitalmars.com wrote in message news:i6e7tm$jj...@digitalmars.com... Nick Sabalausky wrote: 1. Using a profiler 2. Looking at the assembly code being executed Somehow I knew you were going to say that ;) What's interesting is how controversial this is. I've heard every reason in the book (and some very inventive ones) justifying not using a profiler or looking at the assembler. You also need to understand things that can cause problems with asm. For example the Borland compiler used to and probably still does often copy doubles by using 2 32 bit moves. This means any time they are loaded into the fpu soon after a copy you'll get a store to load forwarding stall, which can be around 30 cycles penalty. As float/doubles are passed via the stack, this meant quite a performance hit for code that used doubles over code that used single precision or extended. (Extended was coppied via the FPU so it want a problem).
Re: blog: Overlooked Essentials for Optimizing Code
Sean Kelly Wrote: == Quote from Bane (branimir.milosavlje...@gmail.com)'s article DMD built in profiler don't work yet with multithreaded apps. Is there a plan to change that or.. ? Yes. It's on my to do list, but other things have had priority. Thanks for reply. Can I help with something? I don't have mush experience with that, though.
Re: Bizprac database.. Urgent
Daniel Gibson metalcae...@gmail.com wrote: Walter Bright schrieb: Robert M. Münch wrote: Also known as the 1000 Mann und 1 Befehl pattern. Captain Rumpelstoss: But... how will I learn to fly, Herr Colonel? Colonel Manfred von Holstein: The way we do everything in the German army: from the book of instructions. So people in the German army have to be able to read? I can't believe that ;-) First chapter of the Book ov Eenstruktions: How to read. -- Simen
Re: Random string samples unicode
There randomCover() doesn't work with a string, a dstrings or with a char[].
If later you need to process that res dchar[] with std.string you will have
troubles.
The problems are more widespread, this is a simple generator of terms of the
look and say sequence (to generate a member of the sequence from the previous
member, read off the digits of the previous member, counting the number of
digits in groups of the same digit:
http://en.wikipedia.org/wiki/Look_and_say_sequence ):
import std.stdio, std.conv, std.algorithm;
string lookAndSay(string input) {
string result;
foreach (g; group(input))
result ~= to!string(g._1) ~ (cast(char)g._0);
return result;
}
void main() {
string last = 1;
writeln(last);
foreach (i; 0 .. 10) {
last = lookAndSay(last);
writeln(last);
}
}
I was not able to remove that cast(char), even if I replace all strings in that
program with dstrings.
Is someone else using D2?
Bye,
bearophile
Safe Asynchronous Functions (was: Re: std.concurrency: Returning from spawned function )
== Quote from Sean Kelly (s...@invisibleduck.org)'s article That each spawn() results in the creation of a thread whose lifetime ends when the function returns is an implementation details. Fair enough. I didn't realize this was just an implementation detail. In this case you're absolutely right. It could as easily be a thread pool that resets its TLS data when picking up a new operation, user-space thread, etc. I don't know the details of how TLS is implemented. Would it be possible to reset all TLS data for a given thread? If so, I could make my std.parallelism module that's currently in review (formerly parallelfuture for those who haven't been following the Phobos list) support **safe** asynchronous function calls for a limited but useful number of cases: 1. Like for std.concurrency, all arguments must be free of unshared aliasing. 2. The callable object must be a function pointer, not a delegate, template alias parameter or object w/ overloaded opCall. 3. If I could reset all TLS data in the worker thread upon returning, then I could allow for arbitrarily complex object graphs as the return type, since the worker thread could be guaranteed to not have any local references to the object after the task returned. This would probably be better than using std.concurrency for these cases because even though asynchronous function calls look somewhat similar to message passing, trying to use std.concurrency for such things is really shoehorning. std.parallelism is actually designed for asynchronous function calls, but currently has the disadvantage of being completely unsafe in that it allows unchecked data sharing. Also note that what I'm proposing would only be an additional feature for std.parallelism, which would probably be called something like safeTask. It would still allow all the unchecked data sharing you could handle in @system mode. In short, I don't think that the behavior of a thread exiting should be a motivating factor for design changes. Does this gain anything over sending a message on exit? It allows safely passing an arbitrarily complex object graph because the fact that the thread is exiting means you're moving it from one thread to another rather than sharing it.
Re: Random string samples unicode
I think this might be a compiler bug:
import std.conv : to;
void main()
{
string mystring;
dchar mydchar;
// ok, appending dchar to string
mystring ~= mydchar;
// error: incompatible types for
// ((cast(uint)mydchar) ~ (cast(uint)mydchar)): 'uint' and 'uint'
mystring ~= mydchar ~ mydchar;
}
On Sat, Sep 11, 2010 at 3:42 PM, bearophile bearophileh...@lycos.com wrote:
There randomCover() doesn't work with a string, a dstrings or with a char[].
If later you need to process that res dchar[] with std.string you will have
troubles.
The problems are more widespread, this is a simple generator of terms of the
look and say sequence (to generate a member of the sequence from the
previous member, read off the digits of the previous member, counting the
number of digits in groups of the same digit:
http://en.wikipedia.org/wiki/Look_and_say_sequence ):
import std.stdio, std.conv, std.algorithm;
string lookAndSay(string input) {
string result;
foreach (g; group(input))
result ~= to!string(g._1) ~ (cast(char)g._0);
return result;
}
void main() {
string last = 1;
writeln(last);
foreach (i; 0 .. 10) {
last = lookAndSay(last);
writeln(last);
}
}
I was not able to remove that cast(char), even if I replace all strings in
that program with dstrings.
Is someone else using D2?
Bye,
bearophile
Re: Safe Asynchronous Functions (was: Re: std.concurrency: Returning from spawned function )
dsimcha Wrote: I don't know the details of how TLS is implemented. Would it be possible to reset all TLS data for a given thread? Definitely for some platforms, possibly for all of them (perhaps requiring some trickery). Look at thread_entryPoint in core.thread for a clue on how TLS is implemented.
Re: blog: Overlooked Essentials for Optimizing Code
Bane Wrote: Sean Kelly Wrote: == Quote from Bane (branimir.milosavlje...@gmail.com)'s article DMD built in profiler don't work yet with multithreaded apps. Is there a plan to change that or.. ? Yes. It's on my to do list, but other things have had priority. Thanks for reply. Can I help with something? I don't have mush experience with that, though. I tried a quick adaption a while back and failed... the code uses globals directly within functions sometimes and not others, etc. It's really going to take a substantial rewrite to get things right. The basic idea is that each thread will keep its own data and merge it into a collective dataset on termination.
Re: Random string samples unicode
Andrej Mitrovic: I think this might be a compiler bug: I'll add it to Bugzilla later. But even if you remove that bug, forcing me to use dstrings in the whole program is strange. Or maybe it's a good thing, and the natural state for D programs is to just use dstrings everywhere. Andrei may offer his opinion on the situation. Bye, bearophile
Re: blog: Overlooked Essentials for Optimizing Code
Sean Kelly Wrote: Bane Wrote: Sean Kelly Wrote: == Quote from Bane (branimir.milosavlje...@gmail.com)'s article DMD built in profiler don't work yet with multithreaded apps. Is there a plan to change that or.. ? Yes. It's on my to do list, but other things have had priority. Thanks for reply. Can I help with something? I don't have mush experience with that, though. I tried a quick adaption a while back and failed... the code uses globals directly within functions sometimes and not others, etc. It's really going to take a substantial rewrite to get things right. The basic idea is that each thread will keep its own data and merge it into a collective dataset on termination. I'll dig the dmd code to see whats going on, but my love for c is bit rusty... Thanx.
Re: Random string samples unicode
On 9/11/10 9:48 CDT, Andrej Mitrovic wrote:
I think this might be a compiler bug:
import std.conv : to;
void main()
{
string mystring;
dchar mydchar;
// ok, appending dchar to string
mystring ~= mydchar;
// error: incompatible types for
// ((cast(uint)mydchar) ~ (cast(uint)mydchar)): 'uint' and 'uint'
mystring ~= mydchar ~ mydchar;
}
You can't concatenate two integrals.
Andrei
Re: Random string samples unicode
On 9/11/10 10:24 CDT, bearophile wrote: Andrej Mitrovic: I think this might be a compiler bug: I'll add it to Bugzilla later. But even if you remove that bug, forcing me to use dstrings in the whole program is strange. Or maybe it's a good thing, and the natural state for D programs is to just use dstrings everywhere. Andrei may offer his opinion on the situation. Bye, bearophile This goes into bearophile's odd posts coming now and then. Andrei
Re: blog: Overlooked Essentials for Optimizing Code
Bane Wrote: Sean Kelly Wrote: Bane Wrote: Sean Kelly Wrote: == Quote from Bane (branimir.milosavlje...@gmail.com)'s article DMD built in profiler don't work yet with multithreaded apps. Is there a plan to change that or.. ? Yes. It's on my to do list, but other things have had priority. Thanks for reply. Can I help with something? I don't have mush experience with that, though. I tried a quick adaption a while back and failed... the code uses globals directly within functions sometimes and not others, etc. It's really going to take a substantial rewrite to get things right. The basic idea is that each thread will keep its own data and merge it into a collective dataset on termination. I'll dig the dmd code to see whats going on, but my love for c is bit rusty... Thanx. The code is in druntime. src/rt/trace.d, I believe.
Re: Random string samples unicode
Andrei Alexandrescu: You can't concatenate two integrals. The compiler has full type information, so what's wrong in concatenating two char or two dchar into a string or dstring? And I think there are other problems: http://d.puremagic.com/issues/show_bug.cgi?id=4853 Bye, bearophile
Re: Random string samples unicode
Andrei Alexandrescu: This goes into bearophile's odd posts coming now and then. You aren't helping solve those problems. Bye, bearophile
Re: Random string samples unicode
The compiler has full type information, so what's wrong in concatenating two
char or two dchar into a string or dstring?
But in C the ~ among two chars has a different meaning, so in D you may at best
disallow it.
And I think there are other problems:
http://d.puremagic.com/issues/show_bug.cgi?id=4853
So that's invalid, I have closed it.
Using a bit of contortions it's possible to write lookAndSay() with no casts,
but the code is not good still:
import std.stdio, std.conv, std.algorithm;
string lookAndSay(string input) {
string result;
foreach (g; group(input)) {
string s = to!string(g._1);
s ~= g._0; // string ~ dchar wrong, string ~= dchar good
result ~= s;
}
return result;
}
void main() {
string last = 1;
writeln(last);
foreach (i; 0 .. 10) {
last = lookAndSay(last);
writeln(last);
}
}
Bye,
bearophile
Re: Random string samples unicode
foreach (g; group(input)) {
string s = to!string(g._1);
s ~= g._0; // string ~ dchar wrong, string ~= dchar good
result ~= s;
}
Shorter:
foreach (g; group(input))
result ~= text(g._1, g._0);
bearophile
Re: D2 and FreeBSD - and: debugging (DWARF); lzma/xz hacks
On 08/04/2010 22:43, Shin Fujishiro wrote: Marco Righelemarco_righ...@yahoo.it wrote: [...] I could build dmd 2.047 as follows: % mkdir 2.047 % cd 2.047 % fetch http://ftp.digitalmars.com/dmd.2.047.zip % unzip dmd.2.047.zip % cd dmd2/src/dmd/src % fetch -o 4191.patch 'http://d.puremagic.com/issues/attachment.cgi?id=629' % fetch -o 4198.patch 'http://d.puremagic.com/issues/attachment.cgi?id=632' % patch -l -p2 4191.patch % patch -l -p1 4198.patch % gmake -f freebsd.mak % cp dmd ~/bin Compiler is gcc 4.2.1 on FreeBSD/i386 8-STABLE. Does this work for you? When compiling druntime, a static assertion triggers during linking: src/rt/llmath.d(286): Error: static assert (0x1p+63L == 0x1p+52L) is false gmake: *** [lib/libdruntime.a] Error 1 I'm not sure, but you might be using a non-patched version accidentally. Have you copied the newly-built dmd executable to, for example, ~/bin? I built druntime with the patched dmd 2.047: % cd 2.047/dmd2/src/druntime % fetch -o 3528.patch 'http://d.puremagic.com/issues/attachment.cgi?id=703' % patch -l -p0 3528.patch % gmake -f posix.mak Finally I was unable to compile phobos, as I encountered errors in different modules, including references to freebsd related files that aren't in the zip I downloaded. The following file is not in the release zip. Please download it: http://svn.dsource.org/projects/phobos/trunk/phobos/std/c/freebsd/socket.d And here's a quick-hacked FreeBSD makefile that I use: http://gist.github.com/508638 I could build Phobos with the following command lines: % cd 2.047/dmd2/src/phobos % mkdir std/c/freebsd % fetch -o std/c/freebsd/socket.d 'http://svn.dsource.org/projects/phobos/trunk/phobos/std/c/freebsd/socket.d' % fetch -o my-freebsd.mak 'http://gist.github.com/raw/508638/b4f85e2de4f41a22a09fb895aa48b7a62fefb71e/my-freebsd.mak' % gmake -f my-freebsd.mak Am I supposed to use a different version of the compiler/libraries ? The patches should be valid for recent few releases including 2.047. I may be wrong though... [...] For the record, here is what I had to change for dmd 2.048: - 4191.patch and 3528.patch are no longer needed (already applied) - modfl() was missing in src/druntime/src/core/stdc/math.d only for FreeBSD with a comment // nontrivial conversion, adding it back _seems_ to work according to quick tests (was the problem that real * i.e. long double * wasn't working properly for C bindings in earlier versions and the FreeBSD bindings just hadn't been updated yet?) I've put the patch here: http://people.freebsd.org/~nox/tmp/d/dmd.2.048-druntime-modfl.patch - (at least) std.concurrency and std.exception need to be added to my-freebsd.mak, I've put that patch here: http://people.freebsd.org/~nox/tmp/d/dmd.2.048-phobos-myfreebsdmak.patch == And wrt debugging: I tested both gdb head (checked out after the D patches went in) and Doug Rabson's D-aware debugger ngdb which he annouced as a 'Technology Preview' here: http://lists.freebsd.org/pipermail/freebsd-current/2009-August/011071.html ..and I found two things: a) gdb still chokes on dmd -g debug symbols because the D DWARF extensions conflict with DWARF-4: http://d.puremagic.com/issues/show_bug.cgi?id=4180 disabling the DW_TAG_type_unit case in gdb/dwarf2read.c at least makes it no longer complain: http://people.freebsd.org/~nox/tmp/d/d-gdb-dwarf2read.c.patch b) both debuggers treat arrays as unsigned long long (like main()'s standard string[] args) - at least ngdb prints them correctly if I do a manual cast: (ngdb) p *cast(char [][] *)args I then looked at the debug symbols using readelf -w and found it's actually dmd's fault not the debugger's, the array really seems to be marked as the unsigned long long type: 1a4: Abbrev Number: 3 (DW_TAG_base_type) DW_AT_name: unsigned long long DW_AT_byte_size : 8 DW_AT_encoding: 7 (unsigned) .. 2516: Abbrev Number: 5 (DW_TAG_formal_parameter) DW_AT_name: args DW_AT_type: a4 DW_AT_location: 2 byte block: 91 8 (DW_OP_fbreg: 8) Any chance this can be changed? :) (I suspect this is a DWARF-only problem i.e. it `works on Windows'?) == And finally, I've generated liblzma bindings using bcd, adjusted them for D2, http://people.freebsd.org/~nox/tmp/d/lzma.d (sorry about the httpd treating .d as application/octet-stream) - and then made a small threaded .xz compression hack to try out D2, http://people.freebsd.org/~nox/tmp/d/xzj.d This is very much a WIP but can already be used to compress files or stdin to another file or stdout (so it can be used in pipes and with tar's --use-compress-program), using all cores. Binaries at:
Re: Overlooked Essentials for Optimizing Code
Hello Walter, Nick Sabalausky wrote: 1. Using a profiler 2. Looking at the assembly code being executed Somehow I knew you were going to say that ;) What's interesting is how controversial this is. I've heard every reason in the book (and some very inventive ones) justifying not using a profiler or looking at the assembler. what would it take to add a built in ASM dump to DMD? Putting that in would remove the need for an external tool and might even allow more useful output like adding source line numbers as comments. -- ... IXOYE
Re: Contract checking (Re: enforce()?)
Sat, 11 Sep 2010 07:16:56 -0400, bearophile wrote: Jay Byrd: This is all very confused, and is reflected in D implementing contracts all wrong. If you know well the ideas of DbC, and you think there are some problems in the DbC of D2, then I suggest you to not just write what's wrong, why it is wrong and what bad things such wrong design may cause, and what you suggest to change, starting from the most important changes. Maybe Walter will change nothing, but if you write just a little rant where you say that all is wrong, probably nothing will change, and what you have written is useless. Bye, bearophile People are doing it wrong. They shouldn't come and rant here. They should write compiler patches instead. All discussion is bad, real code matters.
Re: Overlooked Essentials for Optimizing Code
BCS wrote: what would it take to add a built in ASM dump to DMD? Putting that in would remove the need for an external tool and might even allow more useful output like adding source line numbers as comments. Compile with -g and obj2asm will add source lines as comments.
Re: Safe Asynchronous Functions (was: Re: std.concurrency: Returning from spawned function )
== Quote from Sean Kelly (s...@invisibleduck.org)'s article dsimcha Wrote: I don't know the details of how TLS is implemented. Would it be possible to reset all TLS data for a given thread? Definitely for some platforms, possibly for all of them (perhaps requiring some trickery). Look at thread_entryPoint in core.thread for a clue on how TLS is implemented. Interesting. Now that I've given it more thought, though, using this is probably a bad idea for lightweight task-based concurrency because resetting TLS at all properly would require re-running thread-local module c'tors (arbitrarily expensive), not just blitting a few things (cheap). I guess I'll have to resort to disallowing arbitrary indirection in return types in any safe subset of std.parallelism.
Re: Safe Asynchronous Functions (was: Re: std.concurrency: Returning from spawned function )
On 2010-09-11 18:14:25 -0400, dsimcha dsim...@yahoo.com said: Interesting. Now that I've given it more thought, though, using this is probably a bad idea for lightweight task-based concurrency because resetting TLS at all properly would require re-running thread-local module c'tors (arbitrarily expensive), not just blitting a few things (cheap). I guess I'll have to resort to disallowing arbitrary indirection in return types in any safe subset of std.parallelism. You could still allow it for pure functions. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Overlooked Essentials for Optimizing Code
Walter Bright wrote: BCS wrote: what would it take to add a built in ASM dump to DMD? Putting that in would remove the need for an external tool and might even allow more useful output like adding source line numbers as comments. Compile with -g and obj2asm will add source lines as comments. Is this also supported on linux? I can't get it to work.
Re: Overlooked Essentials for Optimizing Code
Lutger wrote: Walter Bright wrote: BCS wrote: what would it take to add a built in ASM dump to DMD? Putting that in would remove the need for an external tool and might even allow more useful output like adding source line numbers as comments. Compile with -g and obj2asm will add source lines as comments. Is this also supported on linux? I can't get it to work. Unfortunately, no.
Well, it's been a total failure
I'm running Fedora 13.x86_64 and I've tried various ways of getting a D compiler to work. None have succeeded. 1. a. I can't install dmd 2.048: # rpm -Uvh /downloads/dmd-2.048-0.i386.rpm error: Failed dependencies: gcc(x86-32) = 4.2.3 is needed by dmd-2.048-0.i386 I don't know what package will satisfy this dependency. b. dmd is a closed compiler. Not good. I'm really not comfortable running a compiler for which I don't have access to the source. The risk of undetected malware is too great. c. So, I give up on dmd. 2. I can't run ldc because a. The ldc RPM requires Tango, even though this is not an RPM dependency for ldc, i.e. you can install ldc without any errors. b. The installation instructions for Fedora on the LDC web site are incorrect. yum install ldc works, but yum install tango doesn't. yum install tango-devel is the correct command. (This is the first time I've heard of pkg-devel without a corresponding pkg.) c. After I've gotten everything installed, it still doesn't work. I get $ ldc hello.d hello.d(5): Error: module stdio cannot read file 'std/stdio.d' d. OK, so I link /usr/include/d/tango/stdc to /usr/include/d/tango/std, but it still doesn't work. I get: $ ldc hello.d hello.d(8): Error: undefined identifier writefln hello.d(8): Error: function expected before (), not writefln of type int e. ldc only supports D v1. f. All of this is too much for me. I give up on ldc. 3. I can't get gdc to compile. a. First I have to get gcc-4.4.4 to compile, but that requires a 4 year old version of automake. I have to downgrade. b. After that's fixed, I'm still running into errors that prevent a build. The errors change from changeset to changeset. So, I'm giving up on gdc. Getting a D compiler to run on x86_64 Linux is too hard. I'm giving up on D. I'm posting this message not as a plea for help, but to illustrate how hard it is to get D to run on Fedora.x86_64. The success of D depends on high quality, open source compilers being available (my belief), and so far, D doesn't seem to be mature enough to be considered, at least on Fedora.x86_64. But, on the plus side, the existence of the book The D Programming Language is a major step in getting D accepted as a serious system programming language. Maybe installation will improve and D will move forward. --- Vladimir -- Vladimir G. Ivanovichttp://www.leonora.org +1 650 450 4101 vladi...@acm.org signature.asc Description: OpenPGP digital signature
Re: Well, it's been a total failure
Vladimir G. Ivanovic wrote: I'm running Fedora 13.x86_64 and I've tried various ways of getting a D compiler to work. None have succeeded. 1. a. I can't install dmd 2.048: # rpm -Uvh /downloads/dmd-2.048-0.i386.rpm error: Failed dependencies: gcc(x86-32) = 4.2.3 is needed by dmd-2.048-0.i386 I don't know what package will satisfy this dependency. You need the i686 versions of some packages, probably start with libgcc (yum install libgcc.i686) and glibc, I don't remember which exactly are required. I have dmd running on 64 bit fedora just fine, it can work. There is also a 64-bit dmd in the making which should solve all those problems. b. dmd is a closed compiler. Not good. I'm really not comfortable running a compiler for which I don't have access to the source. The risk of undetected malware is too great. dmd is not open source, but not closed source either :) You can compile it from scratch, the source is included with the zip file.
Re: Well, it's been a total failure
On 11/09/10 23:52, Vladimir G. Ivanovic wrote:
I'm running Fedora 13.x86_64 and I've tried various ways of getting a
D compiler to work. None have succeeded.
1. a. I can't install dmd 2.048:
# rpm -Uvh /downloads/dmd-2.048-0.i386.rpm
error: Failed dependencies:
gcc(x86-32)= 4.2.3 is needed by dmd-2.048-0.i386
I don't know what package will satisfy this dependency.
I've never used fedora, so I'll skip anything further about rpms.
b. dmd is a closed compiler. Not good. I'm really not comfortable
running a compiler for which I don't have access to the source. The
risk of undetected malware is too great.
Only the backend is closed, and the source is still available. The front
end is dual licensed under the GPL and artistic licenses:
http://www.dsource.org/projects/dmd/browser/trunk/src
c. So, I give up on dmd.
2. I can't run ldc because
a. The ldc RPM requires Tango, even though this is not an RPM
dependency for ldc, i.e. you can install ldc without any errors.
Again, I know nothing of RPMs/Fedora, but I can say ldc doesn't require
tango - it's just a lot nicer to use if you have a standard library :)
b. The installation instructions for Fedora on the LDC web site are
incorrect. yum install ldc works, but yum install tango doesn't.
yum install tango-devel is the correct command. (This is the first
time I've heard ofpkg-devel without a correspondingpkg.)
c. After I've gotten everything installed, it still doesn't work. I get
$ ldc hello.d
hello.d(5): Error: module stdio cannot read file 'std/stdio.d'
std is part of phobos, and phobos does not support ldc. A hello world
using tango would look like this:
---
import tango.io.Stdout;
void main() {
Stdout(Hello World!).newline;
}
d. OK, so I link /usr/include/d/tango/stdc to
/usr/include/d/tango/std, but it still doesn't work. I get:
$ ldc hello.d
hello.d(8): Error: undefined identifier writefln
hello.d(8): Error: function expected before (), not writefln
of type int
Again, phobos doesn't support ldc.
e. ldc only supports D v1.
Correct.
f. All of this is too much for me. I give up on ldc.
3. I can't get gdc to compile.
a. First I have to get gcc-4.4.4 to compile, but that requires a 4
year old version of automake. I have to downgrade.
b. After that's fixed, I'm still running into errors that prevent a
build. The errors change from changeset to changeset. So, I'm giving
up on gdc.
I've only used gdc once, and it was a long time ago - I can't help here.
Even then I do know that dmd is the only D compiler that supports D2
currently. Gdc is getting there.
Getting a D compiler to run on x86_64 Linux is too hard. I'm giving up
on D.
Been there, done that :/
I'm posting this message not as a plea for help, but to illustrate how
hard it is to get D to run on Fedora.x86_64. The success of D depends
on high quality, open source compilers being available (my belief),
and so far, D doesn't seem to be mature enough to be considered, at
least on Fedora.x86_64.
This will change most likely when dmd gets 64 bit support - this is
progressing rapidly.
--
Robert
http://octarineparrot.com/
Re: Overlooked Essentials for Optimizing Code
Walter Bright wrote: Lutger wrote: Walter Bright wrote: BCS wrote: what would it take to add a built in ASM dump to DMD? Putting that in would remove the need for an external tool and might even allow more useful output like adding source line numbers as comments. Compile with -g and obj2asm will add source lines as comments. Is this also supported on linux? I can't get it to work. Unfortunately, no. Ok, objdump looks promising instead. It can do something with the source: objdump -d -l -S -Mintel stuff.o
Re: Overlooked Essentials for Optimizing Code
Hello Walter, Lutger wrote: Walter Bright wrote: BCS wrote: what would it take to add a built in ASM dump to DMD? Putting that in would remove the need for an external tool and might even allow more useful output like adding source line numbers as comments. Compile with -g and obj2asm will add source lines as comments. Is this also supported on linux? I can't get it to work. Unfortunately, no. Back to my origonal point, which was only a for example... -- ... IXOYE
Re: Well, it's been a total failure
On Saturday 11 September 2010 15:52:49 Vladimir G. Ivanovic wrote: I'm running Fedora 13.x86_64 and I've tried various ways of getting a D compiler to work. None have succeeded. 1. a. I can't install dmd 2.048: # rpm -Uvh /downloads/dmd-2.048-0.i386.rpm error: Failed dependencies: gcc(x86-32) = 4.2.3 is needed by dmd-2.048-0.i386 I don't know what package will satisfy this dependency. b. dmd is a closed compiler. Not good. I'm really not comfortable running a compiler for which I don't have access to the source. The risk of undetected malware is too great. c. So, I give up on dmd. I've never understood this. It's not like you're going to look through the code and find the malware yourself. So, whether there's malware or not, it's not like you're going to find it. You have to rely on the compiler developers to do that. And when it comes down to it, have to trust your compiler developers or it makes no sense to use their compiler. Most compilers are written by large, well-known companies, and it would make no sense for them to put malware in their code anyway. In the case of dmd, it's done by Digital Mars, which is definitely a solid compiler vender, though fortunately, you can get dmd totally for free. Walter Bright is well-known in the compiler community. It's not like he's going to be putting malware in dmd. He has enough trouble getting his job done as it is. And as has been pointed out by others, the source for dmd is completely available. It's just that the backend does not have a license which makes it free to be alter or re-used by others. Getting a D compiler to run on x86_64 Linux is too hard. I'm giving up on D. It really isn't all that hard. I mean, it _told_ you what you needed to install - the 32-bit version of gcc. Granted, it would be nice if dmd's page listed exactly what you needed to install to get dmd to run, but the packages themselves differ from distro to distro. And since you have an RPM, it should be incredibly straightforward to install the dependencies with your package manager. You don't even need to try and figure out which packages have the files that you're looking for (which isn't particularly hard with a good package manager). It's _telling you_. A 64-bit version of dmd is forthcoming, and then your multilib issues will go away, but if you can't even install an RPM when it tells what it's missing dependencies are, then you're going to have trouble with a lot of packages in Linux. And honestly, if this is all it takes to stop you from using D, then you obviously aren't all that motivated. Yes, it would be nice if it were easier to install dmd, but that's pretty much life with Linux rather than an issue with dmd. Regardless, there are plenty of folks here who would be happy to help you - many of which use dmd with 64-bit fedora. So, your first post saying that you quit rather than asking for help isn't going to help you much or motivate people to help you. - Jonathan M Davis
Re: Contract checking (Re: enforce()?)
On 11/09/10 08:18, Jay Byrd wrote: Contracts do not belong to function pointers or any other dynamic state -- they apply to the invoker, and thus the static type. Isn't that obvious? In fact, it is yet one step more complex than that: as the name itself suggests, contracts are between the caller (static type) and the callee (dynamic type). Theoretically, the type system has to ensure that both sides are able to fulfill their part of the contract. The dynamic type must be a subtype of the static type (including equality). In subtyping, in-contracts may be weakened, out-contracts may be strengthened (in other words, a subtype may require less and promise more). This is all fine, theoretically sound and easy to handle in a clean way for object oriented design as it is done in Eiffel. The complication in D are function pointers and delegates (FP/DG). For a clean design, the type of a FP/DG would need to include contract information. Contracts are part of the interface and a FP/DG would have to include this. Obviously, this would make FP/DG syntax rather awkward. Furthermore, FP/DG assignments would need to be type-checked at compile time, so contract compatibility would have to be checked at compile time as well. This would be completely impossible. I conclude that within pure OOP, contracts can have strong compile-time support. In-contracts should be checked by the caller, out-contracts by the callee and both checks could be eliminated if the compiler can verify at compile time that they are fulfilled. With FP/DG, this breaks down and I believe the best one can do is to implement contracts as run-time checks in the callee, just as it is done in D. The only detail that I would wish for is a more fine-grained tuning of DbC contract checks in the compiler and a clearer conceptual separation of the concepts of assertions and contracts. However, the former is an implementation detail and the latter has been discussed to death before.
Re: D2 and FreeBSD - and: debugging (DWARF); lzma/xz hacks
On 9/11/2010 11:25 AM, Juergen Lock wrote: snip lots of good info about dmd and freebsd Assuming you don't want these to get lost, you really ought to file bugzilla entries for them. Posts in a newsgroup/mailing list are a great way to have them lost in the noise and to time. Later, Brad
Re: slow runtime
Jonathan M Davis: In any case, if you're looking to avoid GC collection cycles, it sounds like std.gc.disable() and std.gc.enable() will help. But remember that that will increase the odds that it will have to allocate more memory from the OS, which isn't cheap either. It's almost certainly cheap_er_, but it still wouldn't be cheap. Also, with D's current GC, that means that your program will use more memory overall. From my tests, the disable() is useful when you want to just build a data structure, so when you need to quickly allocate many small parts, and then you call enable() when the data structure is done. This avoids many possible collections in the middle, and may lower the running time significantly. Recently the Python GC has introduces some similar automatic optimizations: http://docs.python.org/dev/whatsnew/2.7.html#optimizations The garbage collector now performs better for one common usage pattern: when many objects are being allocated without deallocating any of them. This would previously take quadratic time for garbage collection, but now the number of full garbage collections is reduced as the number of objects on the heap grows. The new logic only performs a full garbage collection pass when the middle generation has been collected 10 times and when the number of survivor objects from the middle generation exceeds 10% of the number of objects in the oldest generation. (Suggested by Martin von Löwis and implemented by Antoine Pitrou; issue http://bugs.python.org/issue4074 .) I don't know of something similar, may be done automatically by the current D GC. Bye, bearophile
string to char*
Hello, I'm having a problem in passing a value to char* expecting function in D 2.0. Already tried: to!(char*)(my string); but it seems like there (Phobos) is no template like this. Then, tried: cast(char*)to!(char[])(my string) which looked ok, but i think it's not a proper way to do that. Most strings converted this way works properly, but once: char* string1 = cast(char*)to!(char[])(my string 1); char* string2 = cast(char*)to!(char[])(my string 2); resulted: string1 = my string 1 string2 = my string 1my string 2 I can't manage this problem, could You hint me?
opIndex() overloading for multiple arrays
Hey guys,
is it possible to overload opIndex() with a multiple array, for
example:
class Example {
...
char[] opIndex(uint index1, uint index2) {
return my text to return;
}
...
}
Example t = new Example();
writefln(t[0][10]);
Looking forward to hearing from anyone :)
Re: string to char*
On 2010-09-11 15:13, Simen kjaeraas wrote: Why does the function expect a char*? If it is an external C function, and it might change the passed values, you should make a duplicate mutable string, or use char[] in lieu of string. If it is an external C function that will *not* change the passed values, and you have write access to the D headers to interface to C, use const char* instead. If no write access, I would use cast(char*)myString.ptr. Yes, it's external C function and I can modify bindings (just bindings, not ABI). Now I'll trace back library which is interfacing to me and possibly fix bindings. You helped me already, thanks a lot. I can already go on (this language is so cool btw.).
Re: string to char*
I'm interfacing with Scintilla (C++), but it works in a different way. It uses messages, which allows it to be linked with practically any language. But I can still pass parameters to be modified by passing the address of the variable instead (the wrapper takes care of that). Although linking with C++ is difficult, having proper C linkage is a great thing. There's a ton of libraries out there ready to be used right now in D. 2010/9/11 Mariusz Gliwiński alienballa...@gmail.com: On 2010-09-11 15:13, Simen kjaeraas wrote: Why does the function expect a char*? If it is an external C function, and it might change the passed values, you should make a duplicate mutable string, or use char[] in lieu of string. If it is an external C function that will *not* change the passed values, and you have write access to the D headers to interface to C, use const char* instead. If no write access, I would use cast(char*)myString.ptr. Yes, it's external C function and I can modify bindings (just bindings, not ABI). Now I'll trace back library which is interfacing to me and possibly fix bindings. You helped me already, thanks a lot. I can already go on (this language is so cool btw.).
Re: opIndex() overloading for multiple arrays
Thanks for reply... exactly, what I need.
Re: Input handling? (newbie alert!)
Jonathan M Davis: You mean computer science? That's the English term - in the US at least. http://en.wikipedia.org/wiki/Informatics_%28academic_field%29 Most of Computer Science is not about computers, and most of it is not a science. It's more a cross between mathematics and engineering. Bye, bearophile
Re: string to char*
shd:
I'm having a problem in passing a value to char* expecting function
in D 2.0. Already tried:
to!(char*)(my string);
A solution, maybe correct:
import std.string: toStringz, indexOf;
import std.c.string: strlen;
import std.stdio: writeln;
void main() {
string s = my string;
assert(indexOf(s, '\0') == -1); // useful
char* p = cast(char*)toStringz(s);
writeln(strlen(p));
}
But keep in mind this string p is managed by the D GC.
That cast to cast(char*) is not nice.
There is no need to dup the string given to toStringz because it performs the
dup internally (wasting a initialization of 'copy'), this is the cleaned up
implementation of toStringz:
const(char)* toStringz(string s) {
char[] copy = new char[s.length + 1];
copy[0 .. s.length] = s;
copy[s.length] = 0;
return copy.ptr;
}
I don't know why it returns a const(char)* instead of a char*. Do you know why?
Bye,
bearophile
Re: Input handling? (newbie alert!)
On Saturday 11 September 2010 08:51:11 bearophile wrote: Jonathan M Davis: You mean computer science? That's the English term - in the US at least. http://en.wikipedia.org/wiki/Informatics_%28academic_field%29 Most of Computer Science is not about computers, and most of it is not a science. It's more a cross between mathematics and engineering. Bye, bearophile I'm not necessarily saying that computer science is the best term for the field in question. It is, however, the official term. And I would hazard a guess that a large portion of programmers in the US won't even know what you mean if you use the term informatics. Most of them will likely think about bioinformatics, since the term is used. So, if you're looking to be clearly understood, computer science is the term to use. - Jonathan M Davis
Re: Input handling? (newbie alert!)
Hm, to me informatics made sense :) Not sure if I ever heard it used in English, but it sounds more suitable than computer science, which (no matter how it's officially used) sounds like it would include everything that deals with computers, so hardware as well. As for what Jesse said, yeah, know that D is a stricter language, and in many ways it makes sense, but sometimes you sure get to wish for some more wiggle room. (Oh yeah, figured out what cast did from a compiler error.) Right now just managed to fully port into D my toy Ruby script (which generates 2 randomized characters, which you get to name, and has them duel it out in text, including a tiny AI moment because each starts with a potion which they use when appropriate). 2 days ago I was staring at that code and didn't even know where to begin porting it. I'm sure it's a really ugly job, but hey, it runs! (The only difference being that Ruby round = D lround, but that's apparently not implemented yet in D2.) So let's see what's next. And thanks again. Haven't seen readln() used in any of the examples I glanced over, so would have had no idea about it otherwise...
Re: Input handling? (newbie alert!)
On Saturday 11 September 2010 13:54:19 Cavalary wrote: Hm, to me informatics made sense :) Not sure if I ever heard it used in English, but it sounds more suitable than computer science, which (no matter how it's officially used) sounds like it would include everything that deals with computers, so hardware as well. Informatics is essentially the term used in at least some European languages other than English. Personally, I think that the name is no better - if not worse - than computer science, since it implies that it has to do with the study of information, which doesn't necessarily have anything to do with computers, math, or logic. Apparently the term is already taken by more or less that anyway: http://en.wikipedia.org/wiki/Informatics_(academic_field) . But I've never heard a term which really properly captured what computer science / informatics is. All candidates have problems of one sort or another. In any case, I was just pointing out to Bearophile that the official English term is computer science so that he's better able to communicate in English (from this and other posts, I gather that English is not his first language, though he's definitely fluent). What the best term would technically be really isn't of consequence, since it's not like we really get to pick at this point. And thanks again. Haven't seen readln() used in any of the examples I glanced over, so would have had no idea about it otherwise... The examples on D's site are generally both sparse and old. Many of the projects on dsource are either D1 and/or old, so it's not a great place to look for examples either. The reality of the matter at this point is that you're going to have to read through the Phobos docs if you want to find all of the functions which could be useful to you. Also, I think that many of the examples in the language documentation in particular (rather than the Phobos docs) are more likely to be C in style rather than taking advantage of more idiomatic D stuff like ranges. My guess is that that's because a fair bit of it was done by Walter rather than Andrei. In any case, good examples of D code are rather lacking at this point, so you'll have to explore the Phobos docs yourself and pay attention to what people post. For that matter, you could dive in the Phobos code and have a look there. std.range and std.algorithm are probably particularly good to look at - though neither would really help you with I/O. However, Andrei's recently published book The D Programming Language (typically referred to as TDPL around here) is a fantastic source for learning about D. So, if you haven't picked that up yet, I highly recommend it. It's the best introductory book to a programming language that I've ever read (probably in part because it doesn't assume that you've never programmed in your life and have no clue what basic stuff like variables or if statements are - it does explain how they work in D though). Howeve, t does mean shelling out around $40, so whether it's worth it depends on how serious you are about learning and using D. - Jonathan M Davis
Re: Generic collection/element function signatures in D2 versus D1
Jacob Carlborg d...@me.com wrote in message
news:i5t61q$2j7...@digitalmars.com...
If you're not going to modify the content of the array I think this will
work:
void foo (T) (const(T)[] collection, T elem) {}
This will allow both mutable, immutable and const arrays. But it will not
let you modify the array like this:
collection[3] = 'a';
On DMD 2.048, This isn't working for me:
-
void foo(T)(const(T)[] coll, T elem)
{
}
void main()
{
string x = hello;
foo(x, x[1]);
}
-
Result:
-
testStringAndChar.d(8): Error: template testStringAndChar.foo(T) does not
match any function template declaration
testStringAndChar.d(8): Error: template testStringAndChar.foo(T) cannot
deduce template function from argument types !()(string,immutable(char))
-
I figured that was just because 'const(immutable(T))[]' doesn't make much
sence, so I tried this and got the exact same error messages:
-
import std.traits;
void foo(T)(const(Unqual!T)[] coll, T elem)
{
}
void main()
{
string x = hello;
foo(x, x[1]);
}
-
It seems to be a problem with IFTI, because this does work with both
versions:
foo!char(x, x[1]);
Kind of a pain.
Re: Generic collection/element function signatures in D2 versus D1
On 9/11/2010 9:32 PM, Nick Sabalausky wrote:
Jacob Carlborg d...@me.com wrote in message
news:i5t61q$2j7...@digitalmars.com...
If you're not going to modify the content of the array I think this will
work:
void foo (T) (const(T)[] collection, T elem) {}
This will allow both mutable, immutable and const arrays. But it will not
let you modify the array like this:
collection[3] = 'a';
On DMD 2.048, This isn't working for me:
-
void foo(T)(const(T)[] coll, T elem)
{
}
void main()
{
string x = hello;
foo(x, x[1]);
}
-
Result:
-
testStringAndChar.d(8): Error: template testStringAndChar.foo(T) does not
match any function template declaration
testStringAndChar.d(8): Error: template testStringAndChar.foo(T) cannot
deduce template function from argument types !()(string,immutable(char))
-
I figured that was just because 'const(immutable(T))[]' doesn't make much
sence, so I tried this and got the exact same error messages:
-
import std.traits;
void foo(T)(const(Unqual!T)[] coll, T elem)
{
}
void main()
{
string x = hello;
foo(x, x[1]);
}
-
It seems to be a problem with IFTI, because this does work with both
versions:
foo!char(x, x[1]);
Kind of a pain.
http://d.puremagic.com/issues/show_bug.cgi?id=2594
[Issue 4852] New: core.demangle cannot demangle functions with class/struct return types
http://d.puremagic.com/issues/show_bug.cgi?id=4852
Summary: core.demangle cannot demangle functions with
class/struct return types
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: patch
Severity: normal
Priority: P2
Component: druntime
AssignedTo: s...@invisibleduck.org
ReportedBy: r.sagita...@gmx.de
--- Comment #0 from Rainer Schuetze r.sagita...@gmx.de 2010-09-11 05:05:20
PDT ---
There are similar bug reports regarding std.demangle, but as it is
reimplemented in core.demangle, I've created this new bug report.
for example:
_D3dmd6Parser6Parser15parsePrimaryExpMFZC3dmd10Expression10Expression
if demangled to
dmd dmd.Parser.Parser.parsePrimaryExp()
but it should be
dmd.Expression.Expression dmd.Parser.Parser.parsePrimaryExp()
This is caused by parseLName() not continue reading after eating the first
identifier of the fully qualified class name.
Index: demangle.d
===
--- demangle.d(revision 390)
+++ demangle.d(working copy)
@@ -378,20 +378,26 @@
debug(trace) printf( parseLName+\n );
debug(trace) scope(success) printf( parseLName-\n );
-auto n = decodeNumber();
+while( true )
+{
+auto n = decodeNumber();
-if( !n || n buf.length || n buf.length - pos )
-error( LName must be at least 1 character );
-if( '_' != tok() !isAlpha( tok() ) )
-error( Invalid character in LName );
-foreach( e; buf[pos + 1 .. pos + n] )
-{
-if( '_' != e !isAlpha( e ) !isDigit( e ) )
+if( !n || n buf.length || n buf.length - pos )
+error( LName must be at least 1 character );
+if( '_' != tok() !isAlpha( tok() ) )
error( Invalid character in LName );
+foreach( e; buf[pos + 1 .. pos + n] )
+{
+if( '_' != e !isAlpha( e ) !isDigit( e ) )
+error( Invalid character in LName );
+}
+
+put( buf[pos .. pos + n] );
+pos += n;
+if( !isDigit( tok() ) )
+break;
+put( . );
}
-
-put( buf[pos .. pos + n] );
-pos += n;
}
/*
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4247] Cannot create default-constructed struct on heap when constructor is defined
http://d.puremagic.com/issues/show_bug.cgi?id=4247 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2010-09-11 06:37:01 PDT --- You can't make your own default constructor for structs, this is explained in TDPL. A constructor with no arguments is created by default, with each field of a struct initialized to it's type's .init property. You cannot override this. See page 244 in TDPL. Also, since when are structs allowed to be allocated on the heap? TDPL explicitly states that structs have scoped lifetime. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4247] Cannot create default-constructed struct on heap when constructor is defined
http://d.puremagic.com/issues/show_bug.cgi?id=4247
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #2 from bearophile_h...@eml.cc 2010-09-11 07:00:37 PDT ---
(In reply to comment #1)
Also, since when are structs allowed to be allocated on the heap? TDPL
explicitly states that structs have scoped lifetime.
I double TDPL says this. And if it says so, then it's wrong. TDPL is not a
religious book.
You cannot override this. See page 244 in TDPL.
The reason given at page 244 is that all type needs a statically defined init.
On the other hand the need to allocate a struct on the heap with no arguments
is real, and the current workarounds look bad for a nice language as D2. This
small program shows that you can create a S2 on the stack:
struct S1 {}
struct S2 {
this(int) {}
}
void main() {
S1 s1a;
auto s1b = new S1;
S2 s2a; // OK
auto s2b = new S2; // ERR
}
So I think new S2; may just create the same struct that S2 s2a; creates,
but allocate it on the heap instead of the stack. I think this is a solution.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4247] Cannot create default-constructed struct on heap when constructor is defined
http://d.puremagic.com/issues/show_bug.cgi?id=4247 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #3 from nfx...@gmail.com 2010-09-11 07:10:59 PDT --- (In reply to comment #1) Also, since when are structs allowed to be allocated on the heap? TDPL explicitly states that structs have scoped lifetime. If structs couldn't be allocated on the heap, you'd have to forget about struct arrays. And this is pure bullshit. E.g. this wouldn't be allowed anymore: S[] array; array.length = 1; You couldn't seriously want this to be illegal. (This code snippet also shows that it's advantageous to force structs having a simple default ctor, i.e. one that doesn't require the runtime to run code on each element to construct it.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4849] Remove str.string.abbrev()
http://d.puremagic.com/issues/show_bug.cgi?id=4849
--- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2010-09-11
07:58:00 PDT ---
I think this might need renaming, but also I would want this to have additional
functionality. If some characters are capitalized, you should be able to
abbreviate by using only those chars, e.g.:
static string[] list = [ FoodAndDrinks, FoodAndCocacola ];
auto abbrevs = std.string.abbrev(list);
foreach (key, value; abbrevs)
{
writefln(%s = %s, key, value);
}
This should print out, among other things:
...
FAD = FoodAndDrinks
FooAD = FoodAndDrinks
FAC = FoodAndCocacola
Then it would be much more usable as an autocomplete feature. But I don't know
if this belongs in Phobos.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4247] Cannot create default-constructed struct on heap when constructor is defined
http://d.puremagic.com/issues/show_bug.cgi?id=4247 --- Comment #4 from Andrej Mitrovic andrej.mitrov...@gmail.com 2010-09-11 08:00:51 PDT --- (In reply to comment #2) (In reply to comment #1) Also, since when are structs allowed to be allocated on the heap? TDPL explicitly states that structs have scoped lifetime. I double TDPL says this. And if it says so, then it's wrong. TDPL is not a religious book. It's not a religious book, but since the D docs aren't kept up to date, who can you trust? And AFAIK Andrei Walter have both reviewed TDPL and agree with what it states there. As for structs on the heap, I simply didn't know it was possible to do that, so maybe I judged to quickly from what I've read. Whether it's legal or not is not up to me, so don't take it personal please. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4853] New: Problems with some dchar/dstring concats
http://d.puremagic.com/issues/show_bug.cgi?id=4853
Summary: Problems with some dchar/dstring concats
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: s...@invisibleduck.org
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-09-11 08:41:59 PDT ---
(Partially found by Andrej Mitrovic)
This D2 program shows something strange:
void main() {
string s;
char c;
dchar d;
dstring ds;
s ~= d;// OK
s ~= c ~ c;// ERR
s ~= ~ c ~ c; // OK
s ~= d ~ d ~ d; // ERR
ds ~= d ~ d; // ERR
ds ~= d ~ d ~ d; // OK
}
DMD 2.048 shows:
test.d(7): Error: incompatible types for ((cast(int)c) ~ (cast(int)c)): 'int'
and 'int'
test.d(9): Error: cannot append type immutable(dchar)[] to type string
test.d(10): Error: incompatible types for ((cast(uint)d) ~ (cast(uint)d)):
'uint' and 'uint'
What's the right way to append two dchar to a string?
I think even this line of code may eventually become correct:
string cc = 'a' ~ 'b';
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4849] Remove str.string.abbrev()
http://d.puremagic.com/issues/show_bug.cgi?id=4849 --- Comment #4 from bearophile_h...@eml.cc 2010-09-11 08:45:49 PDT --- Even if you want to keep it in Phobos, it needs to be renamed and to be moved out of the std.string module. Because it's not a commonly useful string functionality, it muds the string API. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4247] Cannot create default-constructed struct on heap when constructor is defined
http://d.puremagic.com/issues/show_bug.cgi?id=4247 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #5 from Andrei Alexandrescu and...@metalanguage.com 2010-09-11 09:57:21 PDT --- (In reply to comment #4) (In reply to comment #2) (In reply to comment #1) Also, since when are structs allowed to be allocated on the heap? TDPL explicitly states that structs have scoped lifetime. I double TDPL says this. And if it says so, then it's wrong. TDPL is not a religious book. It's not a religious book, but since the D docs aren't kept up to date, who can you trust? And AFAIK Andrei Walter have both reviewed TDPL and agree with what it states there. As for structs on the heap, I simply didn't know it was possible to do that, so maybe I judged to quickly from what I've read. Whether it's legal or not is not up to me, so don't take it personal please. :) Obviously there are many ways to allocate struct objects on the heap: using new, as members of class objects, or as elements of arrays. All of them are described in TDPL. If some particular sentence of TDPL seems to rule out such possibilities please let me know. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4247] Cannot create default-constructed struct on heap when constructor is defined
http://d.puremagic.com/issues/show_bug.cgi?id=4247 --- Comment #6 from Andrej Mitrovic andrej.mitrov...@gmail.com 2010-09-11 10:45:49 PDT --- (In reply to comment #5) (In reply to comment #4) (In reply to comment #2) (In reply to comment #1) Also, since when are structs allowed to be allocated on the heap? TDPL explicitly states that structs have scoped lifetime. I double TDPL says this. And if it says so, then it's wrong. TDPL is not a religious book. It's not a religious book, but since the D docs aren't kept up to date, who can you trust? And AFAIK Andrei Walter have both reviewed TDPL and agree with what it states there. As for structs on the heap, I simply didn't know it was possible to do that, so maybe I judged to quickly from what I've read. Whether it's legal or not is not up to me, so don't take it personal please. :) Obviously there are many ways to allocate struct objects on the heap: using new, as members of class objects, or as elements of arrays. All of them are described in TDPL. If some particular sentence of TDPL seems to rule out such possibilities please let me know. Described where exactly? I haven't seen any snippet of code using new for struct objects in the structs section from page 240 onwards. There's a mention of using classes inside structs, and dynamic arrays inside structs (where the postblit constructor comes in handy), but no mention on how to use structs on the heap. Maybe it's in a different section..? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4853] Problems with some dchar/dstring concats
http://d.puremagic.com/issues/show_bug.cgi?id=4853 --- Comment #1 from bearophile_h...@eml.cc 2010-09-11 11:00:25 PDT --- Probably 'a' ~ 'b' is not allowed in D to keep (in)compatibility with C language, because it has a different meaning in C. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4853] Problems with some dchar/dstring concats
http://d.puremagic.com/issues/show_bug.cgi?id=4853 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from bearophile_h...@eml.cc 2010-09-11 11:03:53 PDT --- Given that, and given that appending a dchar to a string is allowed, but appending a dstring to a string is not allowed, there are no bugs here. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4828] ICE w/ non-boolean dot expression sth.template_instance in static if
http://d.puremagic.com/issues/show_bug.cgi?id=4828 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2010-09-11 13:22:37 PDT --- http://www.dsource.org/projects/dmd/changeset/669 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4751] Regression(1.062, 2.047) ICE(constfold.c) after error
http://d.puremagic.com/issues/show_bug.cgi?id=4751 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2010-09-11 14:05:38 PDT --- http://www.dsource.org/projects/dmd/changeset/670 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3996] Regression(2.041) ICE(glue.c) Passing struct as AA template parameter (Algebraic with struct)
http://d.puremagic.com/issues/show_bug.cgi?id=3996 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2010-09-11 14:17:47 PDT --- http://www.dsource.org/projects/dmd/changeset/672 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4854] New: writefln Segmentation fault if no globals
http://d.puremagic.com/issues/show_bug.cgi?id=4854
Summary: writefln Segmentation fault if no globals
Product: D
Version: D2
Platform: x86
OS/Version: Mac OS X
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: alex...@mac.com
--- Comment #0 from Alex Burton alex...@mac.com 2010-09-11 14:29:49 PDT ---
Hi,
I have dmd version 2.048, OS X 10.5.8
If I compile this :
import std.stdio;
int main()
{
writefln(%d,0);
return 0;
}
with dmd file.d
and then run it
I get segmentation fault in writefln
if I then compile this :
import std.stdio;
int x;
int main()
{
writefln(%d,0);
return 0;
}
and run it, it works.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4826] Regression(2.041) cannot create associative array and compiler crash
http://d.puremagic.com/issues/show_bug.cgi?id=4826 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #7 from Walter Bright bugzi...@digitalmars.com 2010-09-11 16:18:28 PDT --- http://www.dsource.org/projects/dmd/changeset/673 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4430] Regression(2.037) erroneous matching on specialized template function
http://d.puremagic.com/issues/show_bug.cgi?id=4430 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2010-09-11 16:47:38 PDT --- http://www.dsource.org/projects/dmd/changeset/674 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4173] Regression(2.037) Explicitly instantiated templates still try to do IFTI in some cases
http://d.puremagic.com/issues/show_bug.cgi?id=4173 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #6 from Walter Bright bugzi...@digitalmars.com 2010-09-11 17:51:22 PDT --- http://www.dsource.org/projects/dmd/changeset/675 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1715] Template specialization checks for equality rather than convertibility
http://d.puremagic.com/issues/show_bug.cgi?id=1715 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2010-09-11 17:52:32 PDT --- http://www.dsource.org/projects/dmd/changeset/675 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1970] Templated interfaces not matched
http://d.puremagic.com/issues/show_bug.cgi?id=1970 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2010-09-11 17:53:00 PDT --- http://www.dsource.org/projects/dmd/changeset/675 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3627] -of with a filename with a double extension confuses linker
http://d.puremagic.com/issues/show_bug.cgi?id=3627 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2010-09-11 18:35:13 PDT --- http://www.dsource.org/projects/dmd/changeset/676 and 677 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
