Re: dmd 2.064 beta 4
On 10/27/2013 10:09 PM, Manu wrote: I just realised yesterday that the libs bundled with dmd (curl.lib in my case) doesn't have a win64 version bundled. Can you put a binary for that in lib64? ... although it new appears to be gone completely in that new bundle. Is that the new standard? Is there somewhere they should be sourced? They never were there in the zip files, though the windows installer will download them. Can you also rename the libs in lib64/ to remove the '64' on the end? That's pretty annoying in build script to have different lib names. They've had the 64 suffix for a year now. Why is it an issue now? It would also require changing the compiler and the scripts all at the last minute, and would presumably break peoples' existing scripts?
Re: dmd 2.064 beta 4
On 28 October 2013 17:29, Walter Bright newshou...@digitalmars.com wrote: On 10/27/2013 10:09 PM, Manu wrote: I just realised yesterday that the libs bundled with dmd (curl.lib in my case) doesn't have a win64 version bundled. Can you put a binary for that in lib64? ... although it new appears to be gone completely in that new bundle. Is that the new standard? Is there somewhere they should be sourced? They never were there in the zip files, though the windows installer will download them. Ah, well wherever they come from, it's a problem that only one exists. Can you also rename the libs in lib64/ to remove the '64' on the end? That's pretty annoying in build script to have different lib names. They've had the 64 suffix for a year now. Why is it an issue now? It would also require changing the compiler and the scripts all at the last minute, and would presumably break peoples' existing scripts? Because we're finally cleaning it all up, might as well finish the job. The linux libs right next door aren't named separately. Consistency is nice. Refer to Don's talk. Removing hacks in build scripts (or any code) is usually met with rejoice :)
Re: dmd 2.064 beta 4
On Monday, 28 October 2013 at 10:13:22 UTC, Manu wrote: On 28 October 2013 17:29, Walter Bright newshou...@digitalmars.com wrote: On 10/27/2013 10:09 PM, Manu wrote: Refer to Don's talk. Removing hacks in build scripts (or any code) is usually met with rejoice :) While we are at it: std.complex vs complex literals?
Re: dmd 2.064 beta 4
On 28 October 2013 14:36, eles e...@eles.com wrote: On Monday, 28 October 2013 at 10:13:22 UTC, Manu wrote: On 28 October 2013 17:29, Walter Bright newshou...@digitalmars.com wrote: On 10/27/2013 10:09 PM, Manu wrote: Refer to Don's talk. Removing hacks in build scripts (or any code) is usually met with rejoice :) While we are at it: std.complex vs complex literals? Complex isn't deprecated yet... but it has been in the pipeline for a few years now. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: dmd 2.064 beta 4
On Monday, 28 October 2013 at 05:09:35 UTC, Manu wrote: I just realised yesterday that the libs bundled with dmd (curl.lib in my case) doesn't have a win64 version bundled. Can you put a binary for that in lib64? ... although it new appears to be gone completely in that new bundle. Is that the new standard? Is there somewhere they should be sourced? As Walter said, curl is installed by the installer and isn't included with dmd. I'll try to find some time to make a new curl zip that includes a 64 bit curl.
Re: dmd 2.064 beta 4
On Monday, 28 October 2013 at 17:16:42 UTC, Walter Bright wrote: On 10/28/2013 9:56 AM, Iain Buclaw wrote: On 28 October 2013 14:36, eles e...@eles.com wrote: Also, asking for such changes really doesn't belong in the beta thread. Yes, sorry about that. Anyway, the bikeshed is still out there for painting.
Re: dmd 2.064 beta 4
On 29 October 2013 03:21, Brad Anderson e...@gnuk.net wrote: On Monday, 28 October 2013 at 05:09:35 UTC, Manu wrote: I just realised yesterday that the libs bundled with dmd (curl.lib in my case) doesn't have a win64 version bundled. Can you put a binary for that in lib64? ... although it new appears to be gone completely in that new bundle. Is that the new standard? Is there somewhere they should be sourced? As Walter said, curl is installed by the installer and isn't included with dmd. I'll try to find some time to make a new curl zip that includes a 64 bit curl. Explains why it disappeared when unzipping the new build ;) Cheers. That'd be tops.
Re: Dynamic loading
On Sunday, 27 October 2013 at 08:23:26 UTC, Benjamin Thaut wrote: Am 27.10.2013 09:08, schrieb Steve Teale: Any progress? Yes. The implementation of the linux part seems to be done and will be included in 2.064. On windows it will take some time because export has to be fixed first. Kind Regards Benjamin Thaut Thanks Benjamin - Linux will suit me ;=)
Re: Unittest assertion failure messages in OSX
On 10/26/2013 12:12 AM, Kapps wrote:
With git master using OSX Mavericks I'm noticing that I'm no longer
seeing any assertion failure messages from inside unittest blocks.
For example with:
import std.stdio;
unittest {
writeln(Reached unittest.);
assert(0);
writeln(After failed assertion.);
}
Output:
rdmd -main -unittest test2.d
Reached unittest.
Replacing unittest with void main(), the assertion message prints out
properly. Is this something that's just odd with my setup, or is this
happening to others running OSX / git master?
Ping.
Could others chime in and reopen this bug please. It has just been
closed as WORKSFORWALTER. ;)
http://d.puremagic.com/issues/show_bug.cgi?id=11362
Ali
Re: proposal(+working code): catch block callback before stack unwinds to allow attaching debugger
On 27 October 2013 23:43, Timothee Cour thelastmamm...@gmail.com wrote:
ideal syntax would be something along those lines:
try{...}
catch(SomeThrowableType e, callback_before_unwinding){...}
with callback_before_unwinding of type 'void function(Throwable t)'
The semantics of which is:
if 'e' is about to be caught in this particular catch block, call
callback_before_unwinding(e) _before_ unwinding stack and entering catch
block.
Advantages are:
* it allows one to, for example, attach a debugger before stack unwinds and
entering this catch block
* the debugger is only attached at that point, hence not making the regular
program slower
* it doesn't affect other catch blocks nor does it affect how
exceptions/errors are thrown
* it could even allow one to make speed up exception handling, by computing
backtrace _only_ inside this callback_before_unwinding, so that usual
exceptions (std.conv conversions etc) can be caught without any backtrace
inside the main program while unusual unintended exceptions would be caught
at the root and show proper stack trace.
This saves a lot of time when debugging issues, at _zero_ cost in
performance.
Does libunwind allow that? Otherwise could it be adapted to do that?
GDB has 'catch throw' and 'catch catch' as convenient C++ breakpoint
placeholders in the debugger. Can certainly implement them for D too.
http://www.delorie.com/gnu/docs/gdb/gdb_31.html
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Re: std.allocator ready for some abuse
On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu wrote: Hello, I know it's been a long wait. Hopefully it was worth it. The alpha release of untyped allocators is ready for tire-kicking and a test drive. About time! ;) But it was definitely worth waiting for. I don't have that much experience with using custom allocators, but API-wise, this looks great. Not overburdened, but not underpowered either. I would suggest a different name for goodAllocSize(), though. Maybe actualAllocSize() or just allocSize(). This may be a stupid question, but is expand() useful outside the allocator infrastructure itself? Would you ever use that instead of reallocate() in a container, for instance? Lars
Re: Unittest assertion failure messages in OSX
On 10/28/2013 12:31 AM, Walter Bright wrote: On 10/27/2013 11:59 PM, Ali Çehreli wrote: Could others chime in and reopen this bug please. It has just been closed as WORKSFORWALTER. ;) http://d.puremagic.com/issues/show_bug.cgi?id=11362 Correction: it worksforme in the 2.064 beta. The commit that broke it occurs only in the 2.065 master. Thank you! :) Ali
Re: Unittest assertion failure messages in OSX
On 10/27/2013 11:59 PM, Ali Çehreli wrote: Could others chime in and reopen this bug please. It has just been closed as WORKSFORWALTER. ;) http://d.puremagic.com/issues/show_bug.cgi?id=11362 Correction: it worksforme in the 2.064 beta. The commit that broke it occurs only in the 2.065 master.
Re: ARM bare-metal programming in D (cont) - volatile
On Sun, 2013-10-27 at 02:12 -0700, Walter Bright wrote: […] Bitfield code generation for C compilers has generally been rather crappy. If you wanted performant code, you always had to do the masking yourself. Endianism and packing have always been the bête noir of bitfields due to it not being part of the standard but left as compiler specific – sort of essentially in a way due to the vast difference in targets. Given a single compiler for a given target I never found the generated code poor. Using the UNIX compiler in early 1980s and the AVR compiler suites we used in the 2000s generated code always seemed fine. What's your evidence for hand crafted code being better than compiler generated code? I've written device drivers, and have designed, built, and programmed single board computers. I've never found dealing with the oddities of memory mapped I/O and bit flags to be of any difficulty. But don't you find: *x = (1 7) (1 9) to lead directly to the use of macros: SET_SOMETHING_READY(x) to hide the lack of immediacy of comprehension of the purpose of the expression? Do you really find and | operations to be ugly? I don't find them any uglier than + and *. Maybe that's because of my hardware background. It's not the operations that are the problem, it is the expressions using them that lead to code that is the antithesis of self-documenting. Almost all code using , , and | invariable ends up being replaced with macros in C and C++ so as to avoid using functions. The core point here is that this sort of code fails as soon as a function call is involved, functions cannot be used as a tool of abstraction. At least with C and C++. Clearly D has a USP over C and C++ here in that macros can be replaced by CTFE. But how to guarantee that a function is fully evaluated at compile time and not allowed to generate a function call. Only then can functions be used instead of macros to make such code self documenting. Much better to have a bitfield system that works. Especially on architectures such as AVR where there are areas of bit addressable memory. Although Intel only have words accessible memory, not all architectures do. C (and thus C++) hacked a solution that worked fine for the one compiler with the PDP and VAX targets. It was only when there were multiple compilers and multiple targets that the problem arose. There is nothing really wrong with the C bitfield syntax it was just that different compilers did different things for the same target. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Heads up, g++ in Xcode 5 points to Clang
On 2013-10-28 00:52, Timothee Cour wrote: genuine question: is there any advantage of gcc over llvm ? Betting over clang/llvm/lldb seems to make more sense. No, I don't see any advantage. Although I don't like that Apple silently changes what gcc/g++ is. -- /Jacob Carlborg
Re: std.allocator ready for some abuse
On Sunday, 27 October 2013 at 10:45:31 UTC, Andrei Alexandrescu wrote: Just implemented AlignedMallocator and pushed. http://erdani.com/d/phobos-prerelease/std_allocator.html#.AlignedMallocator Untested on Windows. It seems inconsistent that allocate() forwards to alignedAllocate(), while reallocate() does not forward to alignedReallocate(). Why is this? Lars
Re: ARM bare-metal programming in D (cont) - volatile
On Fri, 2013-10-25 at 13:04 -0700, Walter Bright wrote: […] I've written device drivers and embedded systems. The quantity of code that deals with memory-mapped I/O is a very, very small part of those programs. The subset of that code that needs to exactly control the read and write cycles is tinier still. (For example, when writing to a memory-mapped video buffer, such control is quite unnecessary.) Any of the methods I presented are not a significant burden. Adding two lines of inline assembler to get exactly what you want isn't hard, and you can hide it behind a mixin if you like. And, of course, you'll still need inline assembler to deal with the other system-type operations needed for embedded systems work. For example, setting up the program stack, setting the segment registers, etc. No language provides support for them outside of inline assembler or assembler intrinsics. My experience, admittedly late 1970s, early 1980s then early 2000s concurs with yours that only a small amount of code requires this read and write behaviour, but where it is needed it is crucial and in areas where every picosecond matters (*). I disagree with your point about memory video buffers as a general statement, it depends on the buffering and refresh strategy of the buffer. Some frame buffers are very picky and so exact read and write behaviour of the code is needed. Less so now though fortunately. Using functions is a burden here if it involves a function call, only macros are feasible as units of abstraction. Moreover this is the classic approach to inline assembler some form of macro so as to create a comprehensible abstraction. The problem with inline assembler is that you need versions for every target architecture making it a source code and build nightmare. OK there are directory hierarchy idioms and build idioms that make it easier (**), but inline assembler should only really be an answer in cases where there are hardware instructions on a given target that it cannot reasonable be expected that the compiler can generate from the source code. Classics here are the elliptic function libraries, and the context switch operations. So the issue is not the approach per se but how that is encoded in the source code to make it readable and comprehensible AND performant. Volatile as a variable modifier always worked for me in the past but it got bad press and all compiler writers ignored it as a feature till it became useless. Perhaps it is time to reclaim volatile for D give it a memory barrier semantic so that there can be no instruction reordering around the read and write operations, and make it a tool for those who need it. After all no-one is actually using for anything just now are they? (*) OK a small exaggeration in late 1970s where the time scale was 18ms, but you get my point. (**) Actually it is much easier to do with build tools such as SCons and Waf than it ever was with Make, and the GNU Auto tools (especially on Windows), and even CMake. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: proposal(+working code): catch block callback before stack unwinds to allow attaching debugger
On Mon, Oct 28, 2013 at 12:08 AM, Iain Buclaw ibuc...@ubuntu.com wrote:
On 27 October 2013 23:43, Timothee Cour thelastmamm...@gmail.com wrote:
ideal syntax would be something along those lines:
try{...}
catch(SomeThrowableType e, callback_before_unwinding){...}
with callback_before_unwinding of type 'void function(Throwable t)'
The semantics of which is:
if 'e' is about to be caught in this particular catch block, call
callback_before_unwinding(e) _before_ unwinding stack and entering catch
block.
Advantages are:
* it allows one to, for example, attach a debugger before stack unwinds
and
entering this catch block
* the debugger is only attached at that point, hence not making the
regular
program slower
* it doesn't affect other catch blocks nor does it affect how
exceptions/errors are thrown
* it could even allow one to make speed up exception handling, by
computing
backtrace _only_ inside this callback_before_unwinding, so that usual
exceptions (std.conv conversions etc) can be caught without any backtrace
inside the main program while unusual unintended exceptions would be
caught
at the root and show proper stack trace.
This saves a lot of time when debugging issues, at _zero_ cost in
performance.
Does libunwind allow that? Otherwise could it be adapted to do that?
GDB has 'catch throw' and 'catch catch' as convenient C++ breakpoint
placeholders in the debugger. Can certainly implement them for D too.
http://www.delorie.com/gnu/docs/gdb/gdb_31.html
I'm worried about that from performance standpoint:
* that implies running the normal program execution while attached to a
debugger, which would be slower
* catch throw will stop at every thrown exception as opposed to the ones
that are caught at a certain 'root' point.
In what I suggested (and implemented for dmd), it has 0 performance penalty
and only triggers when a thrown exception is caught in a particular
location; debugger isn't attached during normal program execution.
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Re: Heads up, g++ in Xcode 5 points to Clang
On Monday, 28 October 2013 at 08:02:45 UTC, Jacob Carlborg wrote: No, I don't see any advantage. Although I don't like that Apple silently changes what gcc/g++ is. They are trying to phase out GCC altogether, as they are stuck with an ancient version due to licensing issues (GPLv3). The Clang driver was specifically engineered to be a drop-in replacement for GCC, so given that many Makefiles are hard-coded to use gcc or g++, I think what they are doing makes sense. David
Re: ARM bare-metal programming in D (cont) - volatile
On 10/28/2013 1:13 AM, Russel Winder wrote: My experience, admittedly late 1970s, early 1980s then early 2000s concurs with yours that only a small amount of code requires this read and write behaviour, but where it is needed it is crucial and in areas where every picosecond matters (*). I disagree with your point about memory video buffers as a general statement, it depends on the buffering and refresh strategy of the buffer. Some frame buffers are very picky and so exact read and write behaviour of the code is needed. Less so now though fortunately. I've not only built my own single board computers with video buffers, but I've written code for several graphics boards back in the 80's. None needed exact read/write behavior. Using functions is a burden here if it involves a function call, only macros are feasible as units of abstraction. Moreover this is the classic approach to inline assembler some form of macro so as to create a comprehensible abstraction. If you want every picosecond, you're really best off writing a few lines of inline asm. Then you can craft exactly what you need. The problem with inline assembler is that you need versions for every target architecture making it a source code and build nightmare. When you're writing code for memory-mapped I/O, it is NOT going to be portable, pretty much by definition! (Are there any two different target architectures with exactly the same memory-mapped I/O stuff?) OK there are directory hierarchy idioms and build idioms that make it easier (**), but inline assembler should only really be an answer in cases where there are hardware instructions on a given target that it cannot reasonable be expected that the compiler can generate from the source code. Classics here are the elliptic function libraries, and the context switch operations. So the issue is not the approach per se but how that is encoded in the source code to make it readable and comprehensible AND performant. Volatile as a variable modifier always worked for me in the past but it got bad press and all compiler writers ignored it as a feature till it became useless. Perhaps it is time to reclaim volatile for D give it a memory barrier semantic so that there can be no instruction reordering around the read and write operations, and make it a tool for those who need it. After all no-one is actually using for anything just now are they? Ask any two people, even ones in this thread, what volatile means, and you'll get two different answers. Note that the issues of reordering, caching, cycles, and memory barriers are separate and distinct issues. Those issues also vary dramatically from one architecture to the next. (For example, what really happens with a+=1 ? Should it generate an INC, or an ADD, or a MOV/ADD/MOV triple for MMIO? Where do the barriers go? Do you even need barriers? Should a LOCK prefix be emitted? How is the compiler supposed to know just how the MMIO works on some particular computer board?)
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
Walter Bright: http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8 I have found one of the several voices that reminds us of the advantages of dynamic typing: http://www.srl.inf.ethz.ch/workshop2013/eth-vitek.pdf (I was away for few days.) Bye, bearophile
Re: Heads up, g++ in Xcode 5 points to Clang
On 2013-10-28 09:40, David Nadlinger wrote: They are trying to phase out GCC altogether, as they are stuck with an ancient version due to licensing issues (GPLv3). The Clang driver was specifically engineered to be a drop-in replacement for GCC, so given that many Makefiles are hard-coded to use gcc or g++, I think what they are doing makes sense. I know the story, doesn't mean I like it. I like that they're changing to the LLVM tool chain, but not they way they're doing it. Apparently some tests fails when DMD is compiled with Clang. -- /Jacob Carlborg
Re: ARM bare-metal programming in D (cont) - volatile
On Monday, 28 October 2013 at 08:42:12 UTC, Walter Bright wrote: On 10/28/2013 1:13 AM, Russel Winder wrote: Ask any two people, even ones in this thread, what volatile means, and you'll get two different answers. Note that the issues of reordering, caching, cycles, and memory barriers are separate and distinct issues. Those issues also vary dramatically from one architecture to the next. volatile = fickle (For example, what really happens with a+=1 ? Should it generate an INC, or an ADD, or a MOV/ADD/MOV triple for MMIO? Where do the barriers go? Do you even need barriers? Should a LOCK prefix be emitted? How is the compiler supposed to know just how the MMIO works on some particular computer board?) read [address] into registry (mov) registry++ (add) write registry to [address] (mov) You cannot do it otherwise (that is, a shortcut operator). Shortcut operators on fickle memory location shall be simply forbidden. Compiler is able to complain about that. Only explicit reads and writes shall be possible. OK, go with peek() and poke() if you feel it's better and easier (this avoids the a+=1 problem). At least as a first step. But put those into the compiler/phobos, not force somebody to write ASM or C for that. If D send people back to a C compiler, it would never displace C. Templated peek() and poke() are 5 LOCs. Put those in a std.hardware module and, if you prefer, leave it undocumented. Since we discuss this matter, it could have been solved 10 times.
Backtraces on Linux 64-bit
Hi all, Does anybody know what's the current story with 64-bit Linux backtraces? I've seen a couple of posts here and on stackoverflow (like this http://stackoverflow.com/questions/10527901/d2-not-getting-any-backtrace-info), couldn't find any definitive answers for the 64-bit case. ./test(pure @safe immutable(char)[] std.exception.enforce!(immutable(char)[]).enforce(immutable(char)[], lazy const(char)[], immutable(char)[], ulong)+0x6a) [0x50a85e] ./test(_Dmain+0x17f) [0x4a188b] ./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void runMain()+0x18) [0x529740] ./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void tryExec(scope void delegate())+0x2a) [0x529272] ./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void runAll()+0x40) [0x529790] ./test(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void tryExec(scope void delegate())+0x2a) [0x529272] ./oracle(_d_run_main+0x1ae) [0x52922e] ./test(main+0x17) [0x52907b] /lib64/libc.so.6(__libc_start_main+0xe6) [0x7f87dd21dc36] Note: I have the -L--export-dynamic flag enabled in dmd.conf, but it doesn't seem to do much; I'm running dmd64 v2.063.2.
Re: Empty VS null array?
On Friday, 25 October 2013 at 16:31:54 UTC, Max Samukha wrote: If you define the string type to include null, then null should be either identical to empty in *all cases* or distinct from that in all cases. AFAIK, that's how equality operator works, use it and you will get the desired semantics. Should be no problem.
Re: Empty VS null array?
I find that have repeated myself a lot in each section/reply below, I am not sure whether you'd prefer I just reply with those points once, or inline, I chose inline so as it make it clear I was not ignoring your points, and to make it clear which of my arguments apply to which point... :) On Fri, 25 Oct 2013 12:41:36 +0100, Kagamin s...@here.lot wrote: On Monday, 21 October 2013 at 10:33:01 UTC, Regan Heath wrote: null strings are no different to null class references, they're not a special case. True. That's an implementation detail which has no meaning for business logic. This argument applies both ways. If D conflates null and empty, then this restricts business logic with an implementation detail. We agree that D has no place in defining business logic, therefore it follows that the more flexible option is preferable as it is neutral in its effect on business logic. However, this decision, like most is a cost/benefit analysis and in the case of strings the case can be made that they should be a value type, and never null. I can get behind such a decision, as it would mean D was taking a side, finally. If strings cannot be null then we actually benefit from the current conflation of the two, by avoiding having to do null reference checking, and the associated exception/crash. I would prefer to go the other way and allow a consistent null/empty distinction but either option is better than the status quo where we have to check for null (cost) but gain no benefit from this, because we cannot use the null state consistently. When implementation deviates from business logic, one ends up fixing the implementation details everywhere in order to implement business logic. That's why string.IsNullOrEmpty is used. I almost never need to use string.IsNullOrEmpty. The reason why is simple. An empty string is just one value a string may hold, and my code does not generally treat it as special except in certain specific cases where I make that additional check (your blank username example, for one). Null is the only special state a string reference can have, so I check for this and this alone. People seem to have this odd idea that null is somehow an invalid state for a string /reference/ (c# strings are reference types), it's not. That's the very problem: null and empty are valid states and must be treated equally as no data, but they can't for purely technical reasons. I never treat null and empty equally as no data that is my whole point. They are not the same thing conceptually, you should never treat them as the same thing. null means no data, empty is just one possible state of data. You might make the business logic decision of disallowing empty values, of treating an empty value as if no value was given. The two would still be conceptually separate, but your code would be making the decision to treat them in the same way. You encode this decision in the function which accesses the input, once, and your problems are all solved. If you make the mistake of conflating null and empty in your input layer then you restrict your business logic and create the very problem you're complaining about here, stop conflating them and the problem simply vanishes. If your input mechanism or a 3rd party library is conflating them, then you can add a business/conversion layer to convert empty to null and all your code can ignore the empty case and simply concentrate on checking for null, as it should already do - because this is unavoidable in any case. This is KISS, collapse the 2 possible error states into 1 and check for that. People also seem to elevate empty strings to some sort of special status, that's like saying 0 has some special status for int - it doesn't it's just one of a number of possible values. In fact, int having no null like state is a problem causing solutions like boxing to elevate the value type to a reference in order to allow a null state for int. You want to check ints for null everywhere too? No. (Strawman). There are some cases where people wrap int in nullable however as there are some use cases where you do want to be able to indicate no data using a single variable. This is the flexibility of a reference type, and the cost is the check for null. If you do cost/benefit analysis for int with this in mind it is clearly not a type we want as a reference type - the performance penalty alone kills this. Yet, in D we've decided to inconsistently remove that functionality from string for no gain. If string could not actually be null then we'd gain something from the limitation, instead we lose functionality and gain nothing - you still have to check your strings for null in D. Huh? Null slices work just like empty ones - that's why this topic was started in the first place. One doesn't have to check slices for nulls, only for length.
Re: Heads up, g++ in Xcode 5 points to Clang
On 28/10/13 00:52, Timothee Cour wrote: genuine question: is there any advantage of gcc over llvm ? For Apple, probably not. But GCC supports a much, much wider set of architectures than LLVM.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Monday, 28 October 2013 at 08:59:59 UTC, bearophile wrote: Walter Bright: http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8 I have found one of the several voices that reminds us of the advantages of dynamic typing: http://www.srl.inf.ethz.ch/workshop2013/eth-vitek.pdf (I was away for few days.) Bye, bearophile I started getting suspicious at the slide where (s)he claimed that 9.3% of the world's software uses Objective-C while 9.1% of the worlds software uses C++. Thats a lot of people writing apps for iPhones I find that hard to believe, and I don't think that is what TIOBE is even claiming to begin with. Looking at the current index I wonder how much stock you can put in those rankings anyway. Craig
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Monday, 28 October 2013 at 13:06:43 UTC, Craig Dillabaugh wrote: On Monday, 28 October 2013 at 08:59:59 UTC, bearophile wrote: Walter Bright: http://www.reddit.com/r/programming/comments/1oi8wd/ruby_is_a_dying_language/ccs8yr8 I have found one of the several voices that reminds us of the advantages of dynamic typing: http://www.srl.inf.ethz.ch/workshop2013/eth-vitek.pdf (I was away for few days.) Bye, bearophile I started getting suspicious at the slide where (s)he claimed that 9.3% of the world's software uses Objective-C while 9.1% of the worlds software uses C++. Thats a lot of people writing apps for iPhones I find that hard to believe, and I don't think that is what TIOBE is even claiming to begin with. Looking at the current index I wonder how much stock you can put in those rankings anyway. Craig While I am at it, I should point out that 3 of the top 5 languages according to TIOBE are static. Not that I put any stock in what TIOBE claims :o) And #5 is everyone's favorite PHP (for October 2013)! Craig
Re: Heads up, g++ in Xcode 5 points to Clang
On Monday, 28 October 2013 at 12:39:53 UTC, Joseph Rushton Wakeling wrote: On 28/10/13 00:52, Timothee Cour wrote: genuine question: is there any advantage of gcc over llvm ? For Apple, probably not. But GCC supports a much, much wider set of architectures than LLVM. sure, but i would prefer LLVM license over GCC if i were in Apple dev team(and that what they did). also LLVM is quite young, so who knows what people contribute to it in near future...
Re: std.allocator ready for some abuse
On 10/28/13 1:03 AM, Lars T. Kyllingstad wrote: On Sunday, 27 October 2013 at 10:45:31 UTC, Andrei Alexandrescu wrote: Just implemented AlignedMallocator and pushed. http://erdani.com/d/phobos-prerelease/std_allocator.html#.AlignedMallocator Untested on Windows. It seems inconsistent that allocate() forwards to alignedAllocate(), while reallocate() does not forward to alignedReallocate(). Why is this? Lars Two reasons: (1) Posix does not support aligned reallocation. That would make forwarding a pessimization on that OS; (2) On Windows, realloc() cannot be applied to memory gotten with _aligned_malloc and vice versa. Andrei
Re: std.allocator ready for some abuse
On 10/28/13 8:15 AM, Andrei Alexandrescu wrote: On 10/28/13 1:03 AM, Lars T. Kyllingstad wrote: On Sunday, 27 October 2013 at 10:45:31 UTC, Andrei Alexandrescu wrote: Just implemented AlignedMallocator and pushed. http://erdani.com/d/phobos-prerelease/std_allocator.html#.AlignedMallocator Untested on Windows. It seems inconsistent that allocate() forwards to alignedAllocate(), while reallocate() does not forward to alignedReallocate(). Why is this? Lars Two reasons: (1) Posix does not support aligned reallocation. That would make forwarding a pessimization on that OS; (2) On Windows, realloc() cannot be applied to memory gotten with _aligned_malloc and vice versa. Andrei Oh, my mistake. On Windows reallocate() should forward to alignedReallocate. Andrei
Re: Heads up, g++ in Xcode 5 points to Clang
On 28/10/13 14:22, evilrat wrote: sure, but i would prefer LLVM license over GCC if i were in Apple dev team(and that what they did). also LLVM is quite young, so who knows what people contribute to it in near future... Surely, but we should have sympathy for Apple's desire to be able to exert proprietary control over their products because ... ? :-) Don't get me wrong, LLVM itself is a fantastic project, and as long as people contribute great code to great free software projects I don't really mind what their motivation is, but if Apple's goal is to avoid the patent-related provisions of GPLv3, we could be in for a nasty surprise at some point in the future if compiler-related patents Apple holds become part of the battleground of the computing market. From a purely technical point of view, Apple doesn't need a compiler that supports a wide range of platforms, so GCC's much broader range of hardware support is irrelevant to it. But it's an advantage GCC continues to have in the bigger picture.
Re: ARM bare-metal programming in D (cont) - volatile
On 10/28/2013 2:33 AM, eles wrote: (For example, what really happens with a+=1 ? Should it generate an INC, or an ADD, or a MOV/ADD/MOV triple for MMIO? Where do the barriers go? Do you even need barriers? Should a LOCK prefix be emitted? How is the compiler supposed to know just how the MMIO works on some particular computer board?) read [address] into registry (mov) registry++ (add) write registry to [address] (mov) You cannot do it otherwise (that is, a shortcut operator). That overlooks what happens if another thread changes the memory in between the read and the write. Hence the issues of memory barriers, lock prefixes, etc. Since we discuss this matter, it could have been solved 10 times. Pull requests are welcome!
Re: ARM bare-metal programming in D (cont) - volatile
On 10/28/2013 12:49 AM, Russel Winder wrote: On Sun, 2013-10-27 at 02:12 -0700, Walter Bright wrote: […] Bitfield code generation for C compilers has generally been rather crappy. If you wanted performant code, you always had to do the masking yourself. Endianism and packing have always been the bête noir of bitfields due to it not being part of the standard but left as compiler specific – sort of essentially in a way due to the vast difference in targets. Given a single compiler for a given target I never found the generated code poor. Using the UNIX compiler in early 1980s and the AVR compiler suites we used in the 2000s generated code always seemed fine. What's your evidence for hand crafted code being better than compiler generated code? Generally the shifting is unnecessary, but the compiler doesn't know that as the spec says the values need to be right-justified. Also, I often set/reset/test many fields at once - doesn't work to well with bitfields. Endianism should not be an issue if you're dealing with MMIO, since MMIO is going to be extremely target-specific and hence so is your code to deal with it. I've written device drivers, and have designed, built, and programmed single board computers. I've never found dealing with the oddities of memory mapped I/O and bit flags to be of any difficulty. But don't you find: *x = (1 7) (1 9) to lead directly to the use of macros: SET_SOMETHING_READY(x) to hide the lack of immediacy of comprehension of the purpose of the expression? My bit code usually looks like: x |= FLAG_X | FLAG_Y; x = ~(FLAG_Y | FLAG_Z); if (x (FLAG_A | FLAG_B)) ... You'll find stuff like that all through the dmd source code :-) Do you really find and | operations to be ugly? I don't find them any uglier than + and *. Maybe that's because of my hardware background. It's not the operations that are the problem, it is the expressions using them that lead to code that is the antithesis of self-documenting. Almost all code using , , and | invariable ends up being replaced with macros in C and C++ so as to avoid using functions. The core point here is that this sort of code fails as soon as a function call is involved, functions cannot be used as a tool of abstraction. At least with C and C++. I thought that with modern inlining, this was no longer an issue. Clearly D has a USP over C and C++ here in that macros can be replaced by CTFE. But how to guarantee that a function is fully evaluated at compile time and not allowed to generate a function call. Only then can functions be used instead of macros to make such code self documenting. enum X = foo(args); guarantees that foo(args) is evaluated at compile time. I.e. in any context that requires a value at compile time guarantees that it will get evaluated at compile time. If it is not required at compile time, it will not attempt CTFE on it.
Re: Heads up, g++ in Xcode 5 points to Clang
On Monday, 28 October 2013 at 15:49:41 UTC, Joseph Rushton Wakeling wrote: On 28/10/13 14:22, evilrat wrote: sure, but i would prefer LLVM license over GCC if i were in Apple dev team(and that what they did). also LLVM is quite young, so who knows what people contribute to it in near future... Surely, but we should have sympathy for Apple's desire to be able to exert proprietary control over their products because ... ? :-) Do you have any evidence that they've exerted proprietary control over llvm, say by adding closed modules to their compiler? I actually talked to the head llvm guy at Apple about this possibility a couple years back and he was adamantly against anyone outside closing up parts of the compiler. Of course, he may not get to make that decision at Apple and we can't know the truth unless we peek at the source for the shipping compiler at Apple, but I haven't seen any evidence that llvm isn't developed in the open. Have you? Don't get me wrong, LLVM itself is a fantastic project, and as long as people contribute great code to great free software projects I don't really mind what their motivation is, but if Apple's goal is to avoid the patent-related provisions of GPLv3, we could be in for a nasty surprise at some point in the future if compiler-related patents Apple holds become part of the battleground of the computing market. While I do not buy Apple products because of their odious patent stance, I highly doubt they would ever use such compiler patents, if they even have any. Microsoft has a patent on continually scanning a document for spelling errors and highlighting them (http://www.google.com/patents/US5787451), yet _as far as we know_ (and according to a former Microsoft employee - http://keithcu.com/wordpress/?page_id=1548), they've never asserted it on the dozens of applications with such spell-checking in their text editing controls, including this Chrome browser tab I'm currently typing into. I agree that it is a problem that Apple doesn't do a patent grant for their open source projects, assuming they even have any compiler or other software patents on them, but I'm skeptical they'd ever enforce those anyway. Also, IANAL, but I believe they'd never be able to extract any money from such a lawsuit anyway, since they don't make any money from clang or Safari and give them away for free. From a purely technical point of view, Apple doesn't need a compiler that supports a wide range of platforms, so GCC's much broader range of hardware support is irrelevant to it. But it's an advantage GCC continues to have in the bigger picture. Sure.
Re: Heads up, g++ in Xcode 5 points to Clang
On 2013-10-28 16:49, Joseph Rushton Wakeling wrote: Surely, but we should have sympathy for Apple's desire to be able to exert proprietary control over their products because ... ? :-) Don't get me wrong, LLVM itself is a fantastic project, and as long as people contribute great code to great free software projects I don't really mind what their motivation is, but if Apple's goal is to avoid the patent-related provisions of GPLv3, we could be in for a nasty surprise at some point in the future if compiler-related patents Apple holds become part of the battleground of the computing market. From a purely technical point of view, Apple doesn't need a compiler that supports a wide range of platforms, so GCC's much broader range of hardware support is irrelevant to it. But it's an advantage GCC continues to have in the bigger picture. From what I've heard and read (mostly from WWDC videos) Apple doesn't feel they can technically do what they want with a compiler with GCC. I guess they technically can but it's too much work with the GCC code base. -- /Jacob Carlborg
Re: Dynamic loading
On Sunday, 27 October 2013 at 08:23:26 UTC, Benjamin Thaut wrote: Am 27.10.2013 09:08, schrieb Steve Teale: Any progress? Yes. The implementation of the linux part seems to be done and will be included in 2.064. On windows it will take some time because export has to be fixed first. Kind Regards Benjamin Thaut Is there a description somewhere of how this will work? Is it language, Phobos, linker, or what.
Re: Heads up, g++ in Xcode 5 points to Clang
On 2013-10-28 18:33, Joakim wrote: I actually talked to the head llvm guy at Apple about this possibility a couple years back and he was adamantly against anyone outside closing up parts of the compiler. Of course, he may not get to make that decision at Apple and we can't know the truth unless we peek at the source for the shipping compiler at Apple, but I haven't seen any evidence that llvm isn't developed in the open. Have you? No, but LLVM shipped by Apple might not be the same LLVM you can access the source code to. -- /Jacob Carlborg
Re: Dynamic loading
On 2013-10-28 18:45, Steve Teale wrote: Is there a description somewhere of how this will work? Is it language, Phobos, linker, or what. I guess it's compiler and runtime. -- /Jacob Carlborg
Re: Dynamic loading
On Monday, 28 October 2013 at 17:49:23 UTC, Jacob Carlborg wrote: On 2013-10-28 18:45, Steve Teale wrote: Is there a description somewhere of how this will work? Is it language, Phobos, linker, or what. I guess it's compiler and runtime. That sounds a bit implausible. New language keyword or something to load a library or object file. My best guess is that extern(C) dlopen() will just work correctly, failing that I'd think we need an equivalent Phobos call.
Re: Heads up, g++ in Xcode 5 points to Clang
On 28/10/13 18:33, Joakim wrote: Do you have any evidence that they've exerted proprietary control over llvm, say by adding closed modules to their compiler? I understand how you could interpret it that way, but my email didn't actually suggest that Apple had any plans to close-source the compiler. My impression -- and I'm happy to be proven wrong -- is that Apple disliked the idea of a GPLv3-licensed compiler because its patent grants might have created problems for other parts of their software portfolio, which indeed _are_ proprietary. While I do not buy Apple products because of their odious patent stance, I highly doubt they would ever use such compiler patents, if they even have any. Microsoft has a patent on continually scanning a document for spelling errors and highlighting them (http://www.google.com/patents/US5787451), yet _as far as we know_ (and according to a former Microsoft employee - http://keithcu.com/wordpress/?page_id=1548), they've never asserted it on the dozens of applications with such spell-checking in their text editing controls, including this Chrome browser tab I'm currently typing into. I think we've all seen enough software history to know that highly unlikely is not the same as won't happen. :-) I agree that it is a problem that Apple doesn't do a patent grant for their open source projects, assuming they even have any compiler or other software patents on them, but I'm skeptical they'd ever enforce those anyway. Also, IANAL, but I believe they'd never be able to extract any money from such a lawsuit anyway, since they don't make any money from clang or Safari and give them away for free. I doubt they'd try to use their patents to extract money from anyone, but I could see them using them to put a competitor out of business. If (say) Firefox OS or Ubuntu Touch become significant forces in the mobile/tablet market, I wouldn't put it past any of the traditional mobile players to pull out their patent portfolios to try and damage them.
Re: Dynamic loading
On Monday, 28 October 2013 at 18:01:14 UTC, Steve Teale wrote: That sounds a bit implausible. New language keyword or something to load a library or object file. My best guess is that extern(C) dlopen() will just work correctly, failing that I'd think we need an equivalent Phobos call. 1) it is not new, it is the old one that needs fixing : http://dlang.org/attribute.html#ProtectionAttribute 2) it work just fine in Linux (dlopen) because all symbols are exported there by default. Proper symbol visibility definition is still needed for any cross-platform implementation (and for some optimization potential). Right now on Linux naive dlopen + calling Phobos stdio function from shared lib works on 2.064beta so you can be calm about that part.
Re: core.runtime.GC memory alignment
On Monday, 28 October 2013 at 02:44:54 UTC, Manu wrote:
I had a lot of informal conversations with Walter trying to get
my head
around the details here.
To my recollection, the intent was that it should behave like
C, and that
S.alignof must certainly == 128 in that case. It can't work
otherwise.
Alignment must be inherited by parent structures.
But is that really what it means though? From the above
conversation, it would instead appear to mean that:
struct S
{
int i;
align(128) int j;
}
in this case, the *padding* needed until we reach j is 128 bytes.
It doesn't mean that S itself need to be 128 aligned.
I also recall commenting on that case with ulong. On most
architectures it
only needs to be 4 byte aligned, but that one is arch specific.
Does it make sense (and should it be illegal) in that case to
have anything with alignment 8 ? I just don't see how something
like malloc would be able to deal with them otherwise... ?
Re: Heads up, g++ in Xcode 5 points to Clang
On 28/10/13 18:48, Jacob Carlborg wrote: From what I've heard and read (mostly from WWDC videos) Apple doesn't feel they can technically do what they want with a compiler with GCC. I guess they technically can but it's too much work with the GCC code base. It certainly seems to be true that LLVM is moving faster innovation-wise. I don't know how much of that is down to any architectural advantages, how much might be because they support less targets and so have a lower maintenance burden, and how much of it is just the scale of resources being put into it.
Re: ARM bare-metal programming in D (cont) - volatile
On Monday, 28 October 2013 at 16:06:48 UTC, Walter Bright wrote: On 10/28/2013 2:33 AM, eles wrote: That overlooks what happens if another thread changes the memory in between the read and the write. Hence the issues of memory barriers, lock prefixes, etc. Synchronizing the access to the resource is the job of the programmer. He will take a mutex for it. You do that inside the kernel space, not in the user space. There is just one kernel, and it is able to synchronize with itself. Put this into perspective. Pull requests are welcome! You pre-approve?
Re: Heads up, g++ in Xcode 5 points to Clang
On 28 October 2013 18:38, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 28/10/13 18:48, Jacob Carlborg wrote: From what I've heard and read (mostly from WWDC videos) Apple doesn't feel they can technically do what they want with a compiler with GCC. I guess they technically can but it's too much work with the GCC code base. It certainly seems to be true that LLVM is moving faster innovation-wise. I don't know how much of that is down to any architectural advantages, how much might be because they support less targets and so have a lower maintenance burden, and how much of it is just the scale of resources being put into it. I don't see it that way. Up until now at least I haven't seen anything they do that wasn't already do-able in GCC. They just do a better job at PR (which is what you expect from Apple anyway). -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Help needed testing automatic win64 configuration
On 20.10.2013 05:51, Brad Anderson wrote: Fifth and hopefully final version. Not much changed. I put this together so it represented the final iteration of my changes that will be going into pull requests. I stopped it from downloading a modified dmd2beta.zip (because of the licensing issue I'd forgotten about) and just download the original and move phobos64.lib and gcstub64.obj to lib64 in the installer. DMD now supports (as of 2.064 beta 2) LINKCMD in Environment64 so I no longer need dmd changes. http://gnuk.net/dmd-2.064-beta-new-sc.ini-5.exe People using Visual Studio Express 2010 and Windows SDK 7.0A: Sorry, couldn't think of a good solution for that combo. Thanks to everyone who helped me test. Relevant pull requests: https://github.com/D-Programming-Language/dmd/pull/2684 https://github.com/D-Programming-Language/phobos/pull/1652 https://github.com/D-Programming-Language/installer/pull/22 (putting some finishing touches on this in a moment then calling it good) I finally got around to making a version of Visual D that should work for x64 out of the box with both the zip distribution and the new D windows installer. Unfortunately it has to override the settings made by the installer to sc.ini. I have prepared a release candidate here: https://github.com/D-Programming-Language/visuald/releases 3 tiny nitpicks regarding the D installer: - it does not remember the directory of a previous installation - it is listed in the Program and Features as a mere D without any further info. That could be a bit more verbose. - it would be nice if it could also provide a download of the 64-bit curl library The link to the Visual D installer will probably get invalid pretty soon, so maybe we should add some LATEST file somewhere in the repository to grab the link to the latest release?
Re: Heads up, g++ in Xcode 5 points to Clang
On Monday, 28 October 2013 at 18:34:11 UTC, Joseph Rushton Wakeling wrote: On 28/10/13 18:33, Joakim wrote: Do you have any evidence that they've exerted proprietary control over llvm, say by adding closed modules to their compiler? I understand how you could interpret it that way, but my email didn't actually suggest that Apple had any plans to close-source the compiler. No, I got it, I knew you said they'd be able to exert proprietary control, not that they'd done it. I was just wondering if you had evidence that they actually had done any of that already, since I don't follow llvm closely. It is a valid concern, as Google has been closing up a bunch of their initially Apache-licensed Android apps: http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/ But the source is still out there for the older versions, and these companies don't have any responsibility to keep giving their work away for free. My impression -- and I'm happy to be proven wrong -- is that Apple disliked the idea of a GPLv3-licensed compiler because its patent grants might have created problems for other parts of their software portfolio, which indeed _are_ proprietary. Yeah, the GPLv3 is why Apple and FreeBSD stopped updating to the latest gcc after 4.2.1, which was the last GPLv2 release. OS X 10.8 and iOS 6 were completely built by clang and FreeBSD 10, the next major release, is making clang the default compiler. I don't know if it's because of patent grants or other aspects of GPLv3. While I do not buy Apple products because of their odious patent stance, I highly doubt they would ever use such compiler patents, if they even have any. Microsoft has a patent on continually scanning a document for spelling errors and highlighting them (http://www.google.com/patents/US5787451), yet _as far as we know_ (and according to a former Microsoft employee - http://keithcu.com/wordpress/?page_id=1548), they've never asserted it on the dozens of applications with such spell-checking in their text editing controls, including this Chrome browser tab I'm currently typing into. I think we've all seen enough software history to know that highly unlikely is not the same as won't happen. :-) Valid point. I agree that it is a problem that Apple doesn't do a patent grant for their open source projects, assuming they even have any compiler or other software patents on them, but I'm skeptical they'd ever enforce those anyway. Also, IANAL, but I believe they'd never be able to extract any money from such a lawsuit anyway, since they don't make any money from clang or Safari and give them away for free. I doubt they'd try to use their patents to extract money from anyone, but I could see them using them to put a competitor out of business. If (say) Firefox OS or Ubuntu Touch become significant forces in the mobile/tablet market, I wouldn't put it past any of the traditional mobile players to pull out their patent portfolios to try and damage them. How do they put them out of business if they don't get money out of them? They could stop them from using that patented functionality, but you can usually design around such patents, unless they're overly broad, so it's a small hindrance, not really going to put you out of business. Of course, traditional mobile players are a different issue, as they actually make money by selling the features they're patenting. On Monday, 28 October 2013 at 17:45:39 UTC, Jacob Carlborg wrote: On 2013-10-28 18:33, Joakim wrote: I actually talked to the head llvm guy at Apple about this possibility a couple years back and he was adamantly against anyone outside closing up parts of the compiler. Of course, he may not get to make that decision at Apple and we can't know the truth unless we peek at the source for the shipping compiler at Apple, but I haven't seen any evidence that llvm isn't developed in the open. Have you? No, but LLVM shipped by Apple might not be the same LLVM you can access the source code to. Yep, that's why I mentioned that we can't know the truth unless we peek at the source for the shipping compiler at Apple. :) On Monday, 28 October 2013 at 19:02:35 UTC, Iain Buclaw wrote: On 28 October 2013 18:38, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: It certainly seems to be true that LLVM is moving faster innovation-wise. I don't know how much of that is down to any architectural advantages, how much might be because they support less targets and so have a lower maintenance burden, and how much of it is just the scale of resources being put into it. I don't see it that way. Up until now at least I haven't seen anything they do that wasn't already do-able in GCC. They just do a better job at PR (which is what you expect from Apple anyway). Really? The claims that llvm has a cleaner codebase, is easier to use because it's all properly split
Re: Dynamic loading
On 2013-10-28 19:00, Steve Teale wrote: That sounds a bit implausible. New language keyword or something to load a library or object file. My best guess is that extern(C) dlopen() will just work correctly, failing that I'd think we need an equivalent Phobos call. Sorry, I wasn't very clear. The correct function to use is core.runtime.Runtime.loadLibrary: https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L178 -- /Jacob Carlborg
Re: Dynamic loading
On 2013-10-28 19:00, Steve Teale wrote: On Monday, 28 October 2013 at 17:49:23 UTC, Jacob Carlborg wrote: On 2013-10-28 18:45, Steve Teale wrote: Is there a description somewhere of how this will work? Is it language, Phobos, linker, or what. I guess it's compiler and runtime. That sounds a bit implausible. New language keyword or something to load a library or object file. My best guess is that extern(C) dlopen() will just work correctly, failing that I'd think we need an equivalent Phobos call. It's not completely done yet but I think core.runtime.Runtime.loadLibrary will be the function used to load libraries. See: https://github.com/D-Programming-Language/druntime/pull/617 -- /Jacob Carlborg
Re: ARM bare-metal programming in D (cont) - volatile
On 10/28/2013 11:50 AM, eles wrote: Pull requests are welcome! You pre-approve? It'll be subject to review by the community.
Re: Heads up, g++ in Xcode 5 points to Clang
On 2013-10-28 19:33, Joseph Rushton Wakeling wrote: On 28/10/13 18:33, Joakim wrote: Do you have any evidence that they've exerted proprietary control over llvm, say by adding closed modules to their compiler? I understand how you could interpret it that way, but my email didn't actually suggest that Apple had any plans to close-source the compiler. My impression -- and I'm happy to be proven wrong -- is that Apple disliked the idea of a GPLv3-licensed compiler because its patent grants might have created problems for other parts of their software portfolio, which indeed _are_ proprietary. Apple uses libclang in Xcode, that is, the dynamic library. They can't do that with GCC from a license perspective? -- /Jacob Carlborg
Re: std.allocator ready for some abuse
On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu wrote: Please destroy! I've literally sweat as I'm sending this :o). Andrei Going through the code today after reading the thread for the past few days I was blown away by the depth of the concepts involved. Now the information in the article Memory Allocation: Either Love It or Hate It (or just think it’s okay) makes a lot more sense. The composability and customizability of the design look good. This is not an area of coding that I am that familiar with but I am interested in trying out a couple of ideas using the code in the coming weeks. I had a good laugh when I saw the ASCII art before the definition of NullAllocator. Pretty cool! Thanks for this work. Joseph
Re: Heads up, g++ in Xcode 5 points to Clang
On 28 October 2013 20:22, Joakim joa...@airpost.net wrote: On Monday, 28 October 2013 at 19:02:35 UTC, Iain Buclaw wrote: On 28 October 2013 18:38, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: It certainly seems to be true that LLVM is moving faster innovation-wise. I don't know how much of that is down to any architectural advantages, how much might be because they support less targets and so have a lower maintenance burden, and how much of it is just the scale of resources being put into it. I don't see it that way. Up until now at least I haven't seen anything they do that wasn't already do-able in GCC. They just do a better job at PR (which is what you expect from Apple anyway). Really? The claims that llvm has a cleaner codebase, is easier to use because it's all properly split up into different libraries, and introduces new features like better error reporting: that's all PR? GCC approach to libraries has not been to load them dynamically, take libiberty for example: http://gcc.gnu.org/onlinedocs/libiberty/Using.html#Using - and the better error reporting was in gcc, just off by default (Clang added a little more with addition of ~~ tildas ~~). From what I've read and gathered from David over a period of some conversations. Clang infrastructure-wise is much like gcc-3.3/gcc-4.0 was - they have a well defined AST that is capable of representing everything you'd expect in a typical C-family language, with a backdoor to lower level register/assembly representations for target-specific implementations. The direction that GCC went in later versions was closing the backdoor and moving backend-specific code in various frontends to the middle end. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Heads up, g++ in Xcode 5 points to Clang
On Monday, 28 October 2013 at 19:02:35 UTC, Iain Buclaw wrote: I don't see it that way. Up until now at least I haven't seen anything they do that wasn't already do-able in GCC. Have you looked at the quality of error messages in Clang or its explicitly designed tooling/IDE integration API? The way I see it is that LLVM and Clang have certainly enriched the playing field, also pushing GCC forward in the process (and it is still in the lead in some areas – e.g. OpenMP, where even though Intel recently donated their code to LLVM, Clang still isn't quite there). You make it sound like GCC already did everything before that Clang/LLVM do now, and that's certainly not the case. ;) David
Re: Heads up, g++ in Xcode 5 points to Clang
On 2013-10-28 20:02, Iain Buclaw wrote: I don't see it that way. Up until now at least I haven't seen anything they do that wasn't already do-able in GCC. They just do a better job at PR (which is what you expect from Apple anyway). I didn't say it wasn't doable. I can't say for sure since I haven't looked at the GCC code base and only looked briefly at the LLVM code base. But according to Apple it would be too much work to implement the features they wanted. Also, Apple uses libclang in Xcode, that is, the dynamic library. They can't do that with GCC from a license perspective? -- /Jacob Carlborg
Re: Heads up, g++ in Xcode 5 points to Clang
On Monday, 28 October 2013 at 21:07:07 UTC, Iain Buclaw wrote: From what I've read and gathered from David over a period of some conversations. Clang infrastructure-wise is much like gcc-3.3/gcc-4.0 was - they have a well defined AST that is capable of representing everything you'd expect in a typical C-family language, with a backdoor to lower level register/assembly representations for target-specific implementations. If you are referring to LLVM here: Yes and no. It's true that the LLVM IR is mostly target-independent (except for data type sizes and so on) with a number of backdoors in the form of inline assembly, special intrinsics and so on. But at the same time, the LLVM IR is also of a very different quality than GCC GENERIC, being strictly in SSA form. I have not looked into the current GCC architecture in any detail, but I'd guess that LLVM itself starts approximately at the point where the middle-end does in GCC. Clang itself is obviously on a higher layer, but unlike GENERIC, its data structures are not designed to be reused for non-C-family languages. So, the questions of whether its AST can represent every concept from another language or if it needs contains backdoors to a lower level are somewhat moot. David
Re: core.runtime.GC memory alignment
On Monday, 28 October 2013 at 18:33:49 UTC, monarch_dodra wrote:
But is that really what it means though? From the above
conversation, it would instead appear to mean that:
struct S
{
int i;
align(128) int j;
}
in this case, the *padding* needed until we reach j is 128
bytes.
Like Manu, I think the only sane way for align() to behave is
like GCC's/Clang's aligned attribute, which would both add
padding such that j is at offset 128, and ensure that any
variables of type S are aligned to 128 bytes as well.
I just don't see how something like malloc would be able to
deal with them otherwise... ?
Raw system malloc(), without knowing anything about the type,
obviously cannot honor any special alignment requests. Thus,
usually special primitives exist which accept an additional
parameter to specify the target alignment (cf. the std.allocator
discussion). If you really want to use C malloc() for your
256-byte-aligned objects, you have to handle things yourself,
e.g. by over-allocating and then adjusting the base pointer or
similar strategies.
David
Re: Dynamic loading
On Monday, 28 October 2013 at 20:44:11 UTC, Jacob Carlborg wrote: That sounds a bit implausible. New language keyword or something to load a library or object file. My best guess is that extern(C) dlopen() will just work correctly, failing that I'd think we need an equivalent Phobos call. It's not completely done yet but I think core.runtime.Runtime.loadLibrary will be the function used to load libraries. See: https://github.com/D-Programming-Language/druntime/pull/617 In the current implementation, just loading a library using the C functions would indeed work, as the D runtime registration/initialization happens in a C .ctor. The actual implementation in druntime is a bit more complex, mainly to handle thread synchronization. David
Re: Heads up, g++ in Xcode 5 points to Clang
On 28 October 2013 21:24, David Nadlinger c...@klickverbot.at wrote: On Monday, 28 October 2013 at 21:07:07 UTC, Iain Buclaw wrote: From what I've read and gathered from David over a period of some conversations. Clang infrastructure-wise is much like gcc-3.3/gcc-4.0 was - they have a well defined AST that is capable of representing everything you'd expect in a typical C-family language, with a backdoor to lower level register/assembly representations for target-specific implementations. If you are referring to LLVM here: Yes and no. It's true that the LLVM IR is mostly target-independent (except for data type sizes and so on) with a number of backdoors in the form of inline assembly, special intrinsics and so on. But at the same time, the LLVM IR is also of a very different quality than GCC GENERIC, being strictly in SSA form. I have not looked into the current GCC architecture in any detail, but I'd guess that LLVM itself starts approximately at the point where the middle-end does in GCC. That is pretty much what I gathered. SSA forms are something of a middle-end representation lowered from the GENERIC it receives from the frontend. Clang itself is obviously on a higher layer, but unlike GENERIC, its data structures are not designed to be reused for non-C-family languages. So, the questions of whether its AST can represent every concept from another language or if it needs contains backdoors to a lower level are somewhat moot. I didn't say it needs to contain backdoors, I was just pointing out that with LLVM you have the choice to drop to lower level if you choose to, I'd imagine at some cost to the optimiser too. For example, you are free to implement your own calling convention from within the front-end in LLVM. Something of which is not considered something to be language-dependent by GCC, so you have no control over eg: *which* parameters are passed in registers, the only possible talking with the backend is through target hooks and setting the back-end attributes (such as 'regparm') to give hints. -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Dynamic loading
On Sunday, 27 October 2013 at 08:08:08 UTC, Steve Teale wrote: Any progress? There is no way to do something best with llvm? I don't really understand why for static and dynamic libraries we need rely on OS implementation. llvm intermediate byte code isn't fast enough translatable at runtime? Actual binaries format on Windows and Linux seems old and limited, I dream of cross platforms compilers that are based on binaries format that contains all necessary information to be able to operate correct inlining,... It's a real strength that VM based language have to be binary inter-operable. A lot of Java developers don't see C/C++ as portable languages just cause of the necessity to rebuild binaries on each OS even their runs on same architecture.
Re: Heads up, g++ in Xcode 5 points to Clang
On 28/10/13 20:02, Iain Buclaw wrote: I don't see it that way. Up until now at least I haven't seen anything they do that wasn't already do-able in GCC. They just do a better job at PR (which is what you expect from Apple anyway). Ah, that was the option I overlooked :-)
Re: Heads up, g++ in Xcode 5 points to Clang
On 28/10/13 22:07, David Nadlinger wrote: Have you looked at the quality of error messages in Clang or its explicitly designed tooling/IDE integration API? Yea, the quality of error messages with Clang is spectacular. I still remember the first time I tried using it -- just on a whim -- and was shocked that code that compiled cleanly with GCC generated pages and pages of errors and warnings. But once I'd got past the shock and actually read them, I realized that they were actually telling me very explicitly what to do to fix the problem, and that they were resolving unnecessary ambiguities in my source code. But to be fair, we were talking about the backend, not the C/C++ compiler frontend.
Re: Heads up, g++ in Xcode 5 points to Clang
On 28/10/13 21:22, Joakim wrote: Really? The claims that llvm has a cleaner codebase, is easier to use because it's all properly split up into different libraries, and introduces new features like better error reporting: that's all PR? It's my understanding from Iain's talks that the GCC backend is now much cleaner and friendlier than it used to be. I don't know how that compares to LLVM, but it may be that reports of the relative cleanliness of the two codebases are out of date.
Re: core.runtime.GC memory alignment
On 29 October 2013 04:33, monarch_dodra monarchdo...@gmail.com wrote:
On Monday, 28 October 2013 at 02:44:54 UTC, Manu wrote:
I had a lot of informal conversations with Walter trying to get my head
around the details here.
To my recollection, the intent was that it should behave like C, and that
S.alignof must certainly == 128 in that case. It can't work otherwise.
Alignment must be inherited by parent structures.
But is that really what it means though? From the above conversation, it
would instead appear to mean that:
struct S
{
int i;
align(128) int j;
}
in this case, the *padding* needed until we reach j is 128 bytes.
It doesn't mean that S itself need to be 128 aligned.
Both should be true, if it's not, it's a bug.
I also recall commenting on that case with ulong. On most architectures it
only needs to be 4 byte aligned, but that one is arch specific.
Does it make sense (and should it be illegal) in that case to have
anything with alignment 8 ? I just don't see how something like malloc
would be able to deal with them otherwise... ?
Well SIMD vector's require at least 16 byte alignment, so say goodbye to a
major subsection of your CPU ;)
I've never seen a malloc implementation that returns memory that is less
than 16 byte aligned. If you expect higher alignment, typically you use OS
provided AliognedAlloc primitives, or you use tricks like overallocating
and offseting.
Re: Tristate - wanna?
27.10.2013 4:08, Timon Gehr пишет: On 10/26/2013 05:42 PM, Andrei Alexandrescu wrote: While messing with std.allocator I explored the type below. I ended up not using it, but was surprised that implementing it was quite nontrivial. Should we add it to stdlib? Theory: http://en.wikipedia.org/wiki/Three-state_logic The term tri-state[1] should not be confused with ternary logic (3-value logic). So this thread is about a three-valued logic with same truth tables as in Kleene's and Priest's logics. See: * http://en.wikipedia.org/wiki/Many-valued_logic * http://en.wikipedia.org/wiki/Three-valued_logic -- Денис В. Шеломовский Denis V. Shelomovskij
Why are the exec* functions deprecated in std.process?
I am using the new std.process and am disappointed with it. There is no convenient function to replace the running process with a new one. There used to be the exec() family of functions, which conveniently use string[] for arguments etc., but now the doc says: These functions are scheduled for deprecation. Please use spawnShell instead (or, alternatively, the homonymous C functions declared in std.c.process.) The problems are: 1. spawnShell does NOT do the same thing as exec*. The former waits for the spawned process and then continues the calling process. The latter _replaces_ the running process with the new process. 2. The homonym (not homonymous btw) functions in std.c.process use in char*, not string, which makes them unpleasant to use. So... what to do here? Andrei
Re: core.runtime.GC memory alignment
On Tuesday, 29 October 2013 at 00:45:59 UTC, Manu wrote:
On 29 October 2013 04:33, monarch_dodra
monarchdo...@gmail.com wrote:
On Monday, 28 October 2013 at 02:44:54 UTC, Manu wrote:
I had a lot of informal conversations with Walter trying to
get my head
around the details here.
To my recollection, the intent was that it should behave like
C, and that
S.alignof must certainly == 128 in that case. It can't work
otherwise.
Alignment must be inherited by parent structures.
But is that really what it means though? From the above
conversation, it
would instead appear to mean that:
struct S
{
int i;
align(128) int j;
}
in this case, the *padding* needed until we reach j is 128
bytes.
It doesn't mean that S itself need to be 128 aligned.
Both should be true, if it's not, it's a bug.
http://dlang.org/attribute.html#align
---
The alignment for the fields of an aggregate does not affect the
alignment of the aggregate itself - that is affected by the
alignment setting outside of the aggregate.
align (2) struct S {
align (1):
byte a; // placed at offset 0
int b;// placed at offset 1
long c; // placed at offset 5
}
auto sz = S.sizeof; // 14
---
My understanding of that is S is not affected by the alignment of
its fields.
Re: Dynamic loading
On Monday, 28 October 2013 at 22:25:12 UTC, Flamaros wrote: On Sunday, 27 October 2013 at 08:08:08 UTC, Steve Teale wrote: Any progress? There is no way to do something best with llvm? I don't really understand why for static and dynamic libraries we need rely on OS implementation. llvm intermediate byte code isn't fast enough translatable at runtime? Actual binaries format on Windows and Linux seems old and limited, I dream of cross platforms compilers that are based on binaries format that contains all necessary information to be able to operate correct inlining,... maybe our childrens will see it one day :) It's a real strength that VM based language have to be binary inter-operable. A lot of Java developers don't see C/C++ as portable languages just cause of the necessity to rebuild binaries on each OS even their runs on same architecture. to be honest, many C/C++ developers don't think it is portable, so Java developers are not alone here O_-
Re: core.runtime.GC memory alignment
My understanding of that is S is not affected by the alignment of its fields. To clarify, I mean the *alignment* of S is not affected by the alignment of its fields.
Re: Bug in RefCounted?
On Sunday, 27 October 2013 at 23:33:55 UTC, Ali Çehreli wrote: On 10/27/2013 03:04 PM, monarch_dodra wrote: it *could* be an (older) emplace bug. Do you reproduce with head? I had tested it with head. No, doesn't happen on head. Thanks for testing that. I'm not set up to build dmd or phobos myself. Also, keep in mind that DMD *is* allowed to destroy the same object several times. That's news to me. I know that objects may never be destroyed but why multiple times? How many lives do they have? ;) Yeah, I'd like to know this as well. I do remember structs allocated on the heap don't have their destructors called at all due to the GC not being precise, I think. But one object allowed to be destructed multiple times? That sounds really bad.. If that's true a lot of my code is probably incorrect.
Re: Class References
On Monday, 28 October 2013 at 11:22:03 UTC, Jeroen Bollen wrote:
Is it possible in D to create an enum of class references?
Something around the lines of:
enum ClassReferences : Interface {
CLASS1 = ClassOne,
CLASS2 = ClassTwo
}
Short answer: No
Long answer: the enum values must be compile-time constants,
that's what enums are all about. Addresses and references are not
compile-time constants.
What is the use case? There is probably a simple way of doing
what you want. Why not:
interface Interface{}
class ClassOne : Interface {}
class ClassTwo : Interface {}
struct ClassReferences
{
Interface classOne, classTwo;
}
void main()
{
auto c1 = new ClassOne();
auto c2 = new ClassTwo();
/* either this*/
ClassReferences crs;
crs.classOne = c1;
crs.classtwo = c2;
/* or this */
auto crs = ClassReferences(c1,c2);
}
Re: conv text and pure
On Thursday, 24 October 2013 at 00:02:30 UTC, bearophile wrote: Jonathan M Davis: Progress is being made on that however (as evidenced by the fact that format can now be pure in the beta for 2.064). Now two of the most common offenders of pure/nothrow in my high level code are iota() and arr.dup. Bye, bearophile Is arr.dup really impure or is it something queued up to become pure? Thanks Dan
Re: Class References
On Monday, 28 October 2013 at 11:22:03 UTC, Jeroen Bollen wrote:
Is it possible in D to create an enum of class references?
Something around the lines of:
enum ClassReferences : Interface {
CLASS1 = ClassOne,
CLASS2 = ClassTwo
}
You can define class references in module scope and initialize
them in module constructor. This will not help if you want to
have working classes in compile time, but may be useful in
runtime.
Re: Class References
On Monday, 28 October 2013 at 12:10:37 UTC, John Colvin wrote:
On Monday, 28 October 2013 at 11:22:03 UTC, Jeroen Bollen wrote:
Is it possible in D to create an enum of class references?
Something around the lines of:
enum ClassReferences : Interface {
CLASS1 = ClassOne,
CLASS2 = ClassTwo
}
Short answer: No
Long answer: the enum values must be compile-time constants,
that's what enums are all about. Addresses and references are
not compile-time constants.
This is an arbitrary limitation imposed by Don and I disagree
with him. According to opinion you presented providing classes at
CT requires having addresses but it can be viewed other way -
providing classes at CT requires some valid value which should be
preserved for using in RT. For example, nobody complains that
having enumeration constant or module scope immutable qualified
basic type int at CT requires to have some address. Although
int belongs to value type category, int as module variable has
address. Example to illustrate issue:
enum E : int[] { A = [0,1] }
immutable EI = [0,1];
enum EE = [0, 1];
void main()
{
E e1, e2;
assert (e1 == e2 e1 == [0,1]);
e1[0] = 1;
assert(e2[0] == 0);
//EI[0] = 1; // Error: cannot modify immutable expression EI[0]
assert(EI[0] == 0);
// EE[0] = 1; // Error: constant [0, 1][0] is not an lvalue
assert(EE[0] == 0);
}
Dynamic arrays like classes are reference types, so there are
addresses involved. Not only this shows that CT references are
possible, but that dmd can support similar behavior for classes.
Replace int[] with some class and you will arrive that there is
something wrong about idea that enum values must be compile-time
constants, addresses and references are not compile-time
constants, thus reference types can't be compile-time
expressions.
Re: Bug in RefCounted?
On Monday, 28 October 2013 at 10:07:15 UTC, Rene Zwanenburg wrote: Yeah, I'd like to know this as well. I do remember structs allocated on the heap don't have their destructors called at all due to the GC not being precise, I think. But one object allowed to be destructed multiple times? That sounds really bad.. If that's true a lot of my code is probably incorrect. Hum... I seem to remember having replied earlier, but I guess I forgot to hit send. In any case, I could be mistaken, but I simply know that under certain circumstances, it can happen. I don't know if that's a bug though. I'll try to find the cases where it happens. Furthermore, you must *always* make sure that the T.init state is destroyable (which is not the case here).
Re: -profile and nothrow
Reduced:
module b;
class B {
this() {}
}
module a;
import b;
class C : B {}
class D(X) : X {}
alias D!(C) HtmlPanel;
dmd -profile a.d
Error: 'a.C.this' is not no throw
Everything is ok without the profile... may I post a bug report
for this?
/Paolo
On Monday, 28 October 2013 at 15:20:59 UTC, Paolo Invernizzi
wrote:
Hi all,
Compiling my application with 2.064.beta.4 and 2.063.2 with the
-profile switch, I have an error like:
Error: 'foo.ui.Widgets.this' is not no throw
I've read something similar involving contracts, but this seems
something different.
Of course everything compiles and run fine without the
-profile switch.
Any clue, or may I try to reduce (it is a BIG codebase)?
Thanks,
Paolo
Re: -profile and nothrow
Any difference in semantics between -profile and normal flow is a bug, so, yes, please report to bugzilla.
Re: Bug in RefCounted?
On Monday, 28 October 2013 at 16:53:11 UTC, monarch_dodra wrote:
On Monday, 28 October 2013 at 10:07:15 UTC, Rene Zwanenburg
wrote:
Yeah, I'd like to know this as well. I do remember structs
allocated on the heap don't have their destructors called at
all due to the GC not being precise, I think.
But one object allowed to be destructed multiple times? That
sounds really bad.. If that's true a lot of my code is
probably incorrect.
Hum... I seem to remember having replied earlier, but I guess I
forgot to hit send.
In any case, I could be mistaken, but I simply know that under
certain circumstances, it can happen.
OK
I don't know if that's a
bug though. I'll try to find the cases where it happens.
So do you *know* cases or suspect that they may exists? Or
remember some bug issue?
Here is my attempt:
import std.stdio;
struct S
{
int i;
this(int i) { writefln(ctor, %X, i); this.i = i; }
this(this) { writefln(postblit, %X, %X, this, i); }
~this() { writefln(dtor, %X, %X, this, i); }
}
auto foo()
{
S s = S(1);
return { s = S(2); } ;
}
void main()
{
foo()();
}
ctor, 1
dtor, 77ED8FF8, 1
ctor, 2
dtor, 7FFFDB30, 1
Inside foo() function object 's' is destroyed twice: first time
as a regular struct at the end of block scope, second time before
assigning S(2).
There are other tools: union bug, control flow tricks, __traits,
__dtor but they are move obvious.
Re: Bug in RefCounted?
On Monday, 28 October 2013 at 10:07:15 UTC, Rene Zwanenburg wrote:
On Sunday, 27 October 2013 at 23:33:55 UTC, Ali Çehreli wrote:
That's news to me. I know that objects may never be destroyed
but why multiple times? How many lives do they have? ;)
Yeah, I'd like to know this as well. I do remember structs
allocated on the heap don't have their destructors called at
all due to the GC not being precise, I think.
The fact that structs are movable and there is too few struct
runtime reflection makes them noncollectable. However, you can
wrap struct inside class, in such case struct dtor will be called.
But one object allowed to be destructed multiple times? That
sounds really bad.. If that's true a lot of my code is probably
incorrect.
I think one need to be aware of this bug (no dtor), rather than
cases when dtor is called multiple times.
import std.stdio;
struct S
{
int i;
this(int i) { writefln(ctor, %X, i); this.i = i; }
this(this) { writefln(postblit, %X, %X, this, i); }
~this() { writefln(dtor, %X, %X, this, i); }
}
int this_throws() { throw new Exception(); }
void foo(S s, int i) {}
void main()
{
try { foo(S(1), this_throws); }
catch(Exception e) {}
}
Re: Bug in RefCounted?
On 10/28/2013 12:30 PM, Maxim Fomin wrote:
So do you *know* cases or suspect that they may exists? Or remember some
bug issue?
Here is my attempt:
import std.stdio;
struct S
{
int i;
this(int i) { writefln(ctor, %X, i); this.i = i; }
this(this) { writefln(postblit, %X, %X, this, i); }
~this() { writefln(dtor, %X, %X, this, i); }
}
auto foo()
{
S s = S(1);
return { s = S(2); } ;
}
void main()
{
foo()();
}
ctor, 1
dtor, 77ED8FF8, 1
ctor, 2
dtor, 7FFFDB30, 1
Inside foo() function object 's' is destroyed twice: first time as a
regular struct at the end of block scope, second time before assigning
S(2).
Ok, that's too much! :( Inspired by your program, the following delegate
completely misses the point:
import std.stdio;
struct S
{
int i;
~this() { i = 666; }
}
auto foo()
{
S s = S(1);
// When I see the following delegate, I think the lifetime of s is
// extended. I expect my delegate to print 1.
return { writeln(s); } ;
}
void main()
{
// Unfortunately, the following prints 666!
foo()();
}
What is the purpose of writeln in that delegate? Obviously, to print 1.
Yet it doesn't happen that way. Is this accepted to be a bug? Should the
programmer 'new' the object instead?
Ali
Re: Array of associative array.
On Monday, 28 October 2013 at 21:26:41 UTC, Auto cannot infer type from initializer wrote: public static CompilerTable = [ /// \brief DMD [-c : -c, -debug : -debug, -g : -g, -gc : -gc, -I : -I, -inline : -inline, -L : -L, -lib : -lib, -noboundscheck : -noboundscheck, -O : -O, -o- : -o-, -odobjdir: -odobjdir, -offilename : -offilename, -profile : -profile, -release : -release, -unittest: -unittest, -w : -w, -wi : -wi], /// \brief LDC [-c : -c, -debug : -debug, -g : -g, -gc : -gc, -I : -I, -inline : -inline, -L : -L, -lib : -lib, -noboundscheck : -noboundscheck, -O : -O, -o- : -o-, -odobjdir: -odobjdir, -offilename : -offilename, -profile : -profile, -release : -release, -unittest: -unittest, -w : -w, -wi : -wi], /// \brief GDC [-c : -c, -debug : -fdebug, -g : -g, -gc : -g, -I : -I, -inline : -finline-functions, -L : -Wl, -lib : , -noboundscheck : -noboundscheck, -O : -O3, -o- : -fsyntax-only, -odobjdir: -od, -offilename : -o, -profile : -profile, -release : -release, -unittest: -unittest, -w : -Wall, -wi : -Wextra] ]; Error: variable org.ghrum.installer.option.CompilerTable cannot infer type from initializer The declaration is public static auto CompilerTable = [ ... ]
Re: Array of associative array.
On Monday, 28 October 2013 at 21:27:46 UTC, Auto cannot infer type from initializer wrote: On Monday, 28 October 2013 at 21:26:41 UTC, Auto cannot infer type from initializer wrote: public static CompilerTable = [ /// \brief DMD [-c : -c, -debug : -debug, -g : -g, -gc : -gc, -I : -I, -inline : -inline, -L : -L, -lib : -lib, -noboundscheck : -noboundscheck, -O : -O, -o- : -o-, -odobjdir: -odobjdir, -offilename : -offilename, -profile : -profile, -release : -release, -unittest: -unittest, -w : -w, -wi : -wi], /// \brief LDC [-c : -c, -debug : -debug, -g : -g, -gc : -gc, -I : -I, -inline : -inline, -L : -L, -lib : -lib, -noboundscheck : -noboundscheck, -O : -O, -o- : -o-, -odobjdir: -odobjdir, -offilename : -offilename, -profile : -profile, -release : -release, -unittest: -unittest, -w : -w, -wi : -wi], /// \brief GDC [-c : -c, -debug : -fdebug, -g : -g, -gc : -g, -I : -I, -inline : -finline-functions, -L : -Wl, -lib : , -noboundscheck : -noboundscheck, -O : -O3, -o- : -fsyntax-only, -odobjdir: -od, -offilename : -o, -profile : -profile, -release : -release, -unittest: -unittest, -w : -Wall, -wi : -Wextra] ]; Error: variable org.ghrum.installer.option.CompilerTable cannot infer type from initializer The declaration is public static auto CompilerTable = [ ... ] Had to use string[string][] instead of auto.
Re: Array of associative array.
On 10/28/2013 02:39 PM, Wolftein wrote:
Error: variable org.ghrum.installer.option.CompilerTable cannot
infer type from initializer
The declaration is public static auto CompilerTable = [ ... ]
Had to use string[string][] instead of auto.
Looks like a compiler bug to me. Reduced:
void foo(T)(T)
{
pragma(msg, T.stringof);
}
void main()
{
// Works and prints string[string][]
pragma(msg, typeof([ [ a : a] ]).stringof);
// Works and prints string[string][]
foo([ [ a : a] ]);
// However, this fails
auto a = [ [ a : a] ];
}
Is there a reason why the last line cannot be compiled?
Ali
Re: Array of associative array.
On 10/28/13, Ali Çehreli acehr...@yahoo.com wrote: Looks like a compiler bug to me. Reduced: Is there a reason why the last line cannot be compiled? Could be one of these: http://d.puremagic.com/issues/show_bug.cgi?id=9295 http://d.puremagic.com/issues/show_bug.cgi?id=9520 There's a bunch of these array literal bugs.
Re: conv text and pure
On Monday, October 28, 2013 13:40:03 Daniel Davidson wrote: On Thursday, 24 October 2013 at 00:02:30 UTC, bearophile wrote: Jonathan M Davis: Progress is being made on that however (as evidenced by the fact that format can now be pure in the beta for 2.064). Now two of the most common offenders of pure/nothrow in my high level code are iota() and arr.dup. Bye, bearophile Is arr.dup really impure or is it something queued up to become pure? It's essentially a bug that the compiler does not consider it pure. Memory allocation is valid in pure functions, and dup is just as pure as new is. It can't be pure if copying the array's elements isn't pure (e.g. if the elements have impure postblits), but it can certainly be pure for the built-in types and any user-defined types for which copying is pure. - Jonathan M Davis
[Issue 11342] shared libs don't play well with etc.c.zlib
http://d.puremagic.com/issues/show_bug.cgi?id=11342 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||INVALID --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2013-10-27 22:59:45 PDT --- Don't link in the unshared version of phobos when building a shared library, otherwise you'll get multiple definitions of the same symbols. Any shared libs you create should be linked against libphobos2.so, not -lphobos2. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11344] [2.064 beta] Error: object.destroy called with argument types matches both
http://d.puremagic.com/issues/show_bug.cgi?id=11344 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2013-10-27 23:19:22 PDT --- https://github.com/D-Programming-Language/druntime/pull/647 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11362] Unit test assertion failure messages not printed
http://d.puremagic.com/issues/show_bug.cgi?id=11362 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||WORKSFORME --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2013-10-27 23:29:47 PDT --- The sample program works correctly for me on Win32, Linux and OSX. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11362] Unit test assertion failure messages not printed
http://d.puremagic.com/issues/show_bug.cgi?id=11362 --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2013-10-27 23:30:18 PDT --- As of dmd 2.064 beta 4, that is. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11330] Directory named as imported module should not stop module search
http://d.puremagic.com/issues/show_bug.cgi?id=11330 --- Comment #11 from Walter Bright bugzi...@digitalmars.com 2013-10-27 23:45:52 PDT --- (In reply to comment #9) I don't see how a list of search paths is like a number of nested scopes. It's always been that way, and C and C++ compilers operate the same way. To override, you put a path in front of the list of paths. The clear hierarchy is the ones earlier in the list override the ones later, i.e. the first found rule. Just like nested scopes. This is besides my argument, anyway, so I understand you're replying about the suggestion for module hijack protection? This was in response to the idea that errors should be generated if a file appears in more than one path. If that's not the case, then it's even more unclear to me why this change was introduced, and why it is considered beneficial. The change was made so that existing modules, like std.algorithm, could be split into multiple modules without breaking existing code. See http://wiki.dlang.org/DIP37 2. The import system is designed to map onto the file system. Using file/directory names that match module/package names is how it is supposed to work, if there are matching names that have nothing to do with D will cause problems. This does not address my arguments in comment #2. Also, without context, your quote can be used to defend a hypothetical change in DMD to reject modulename.txt files, if they exist in the search path and modulename is imported somewhere, which is absurd. Which is the main point of my argument: D compilers should not treat filesystem directories that match imported D modules as if they are made for use for D. .d files are for D compilers, directories are for everyone. Directory names have always been regarded as having a 1:1 correspondence with package names in D. This is not new. std.algorithm corresponds to std/algorithm.d As far as I know, no other implementation of a package system in any other language behaves as DMD behaves now. As I recall, this was debated at length and was implemented months ago. I hope this isn't an attempt to sweep a regression under the rug to get 2.064 out quicker: - I have stumbled upon this problem twice, in two different situations. - This change affected two other users (issue 11241 and issue 11243). I am sorry it breaks some existing setups, but the behavior is designed, and is not a bug. There were several proposals, and this one broke the least and before this everyone has liked it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11362] Unit test assertion failure messages not printed
http://d.puremagic.com/issues/show_bug.cgi?id=11362
--- Comment #4 from Ali Cehreli acehr...@yahoo.com 2013-10-27 23:56:18 PDT ---
Well, this is broken on git head then. The following session compares two
programs with a single assert expression.
One has it in main:
good.d:
void main()
{
assert(false, something is wrong);
}
The other has it in a unittest block:
unittest
{
assert(false, something is wrong);
}
void main()
{}
Under Linux (SL6), the former prints both the assertion failure message and the
stack trace; the latter does not do any of that. The consolation is that the
latter returns a non-zero error code.
Here is my interaction:
$ ./wbd | grep DMD
DMD64 D Compiler v2.064-devel-acc0cb0
$ cat good.d
void main()
{
assert(false, something is wrong);
}
$ ./wbd good.d
$ ./good
core.exception.AssertError@good.d(3): something is wrong
./good() [0x401a65]
./good() [0x4019c1]
./good() [0x401ecc]
./good() [0x401c8e]
./good() [0x401e8b]
./good() [0x401c8e]
./good() [0x401c0f]
./good() [0x4019e3]
/lib64/libc.so.6(__libc_start_main+0xfd) [0x301621ecdd]
$ echo $?
1
$ cat bad.d
unittest
{
assert(false, something is wrong);
}
void main()
{}
$ ./wbd bad.d -unittest
$ ./bad
$ echo $?
1
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11362] Unit test assertion failure messages not printed
http://d.puremagic.com/issues/show_bug.cgi?id=11362 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2013-10-28 00:14:40 PDT --- (In reply to comment #4) Well, this is broken on git head then. Evidently. The commit identified above is not in the 2.064 beta. I'll reopen then for 2.065. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11342] shared libs don't play well with etc.c.zlib
http://d.puremagic.com/issues/show_bug.cgi?id=11342 Artem Tarasov lomerei...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #3 from Artem Tarasov lomerei...@gmail.com 2013-10-28 01:19:20 PDT --- But it is linked against _shared_ version. Moreover, it is impossible to link against libphobos2.a because it's not compiled with -fPIC. I have to specify -L-lphobos2 on the command line just for that, otherwise DMD tries to use static libphobos2.a, and linker barks that it should be recompiled with -fPIC /usr/bin/ld: /home/artem/dmd2/linux/bin64/../lib64/libphobos2.a(lifetime_46c_6c8.o): relocation R_X86_64_32 against `_D15TypeInfo_Shared7__ClassZ' can not be used when making a shared object; recompile with -fPIC /home/artem/dmd2/linux/bin64/../lib64/libphobos2.a: could not read symbols: Bad value collect2: ld returned 1 exit status -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8507] (Regression 2.060) rdmd hangs and mutex failures
http://d.puremagic.com/issues/show_bug.cgi?id=8507 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added CC||safety0ff.b...@gmail.com --- Comment #2 from safety0ff.bugz safety0ff.b...@gmail.com 2013-10-28 02:19:31 PDT --- Works fine on my Linux x86-64 system. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7149] Segfault on Array Append from Multiple Threads in GDC and LDC: Race Condition?
http://d.puremagic.com/issues/show_bug.cgi?id=7149 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added CC||safety0ff.b...@gmail.com --- Comment #1 from safety0ff.bugz safety0ff.b...@gmail.com 2013-10-28 02:23:21 PDT --- The LDC GDC issues have been closed in their trackers, can this be closed? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7149] Segfault on Array Append from Multiple Threads in GDC and LDC: Race Condition?
http://d.puremagic.com/issues/show_bug.cgi?id=7149 Iain Buclaw ibuc...@ubuntu.com changed: What|Removed |Added Status|NEW |RESOLVED CC||ibuc...@ubuntu.com Resolution||FIXED --- Comment #2 from Iain Buclaw ibuc...@ubuntu.com 2013-10-28 02:30:15 PDT --- Yes, see this pull into druntime: https://github.com/D-Programming-Language/druntime/commit/01212a6b3f7d369347f485b64336b6cd2c55d46e -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11321] Can't link _D6object15__T7reserveTyaZ7reserveFNaNbNeKAyamZm
http://d.puremagic.com/issues/show_bug.cgi?id=11321 --- Comment #7 from Dicebot pub...@dicebot.lv 2013-10-28 04:47:40 PDT --- (In reply to comment #4) There's only one of me. I welcome any help in reducing this example to something more tractable. Sure, but is not a legitimate reason to close a valid (though incomplete) bug report with RESOLVED/WORKSFORME. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11330] Directory named as imported module should not stop module search
http://d.puremagic.com/issues/show_bug.cgi?id=11330 --- Comment #12 from Vladimir Panteleev thecybersha...@gmail.com 2013-10-28 15:33:14 EET --- (In reply to comment #11) The change was made so that existing modules, like std.algorithm, could be split into multiple modules without breaking existing code. This does not explain or justify the problem this bug report is describing. See http://wiki.dlang.org/DIP37 The DIP specification says NOTHING about treating the first directory in its search path as the match for a package. As far as I can see, the behavior in question is an artifact of a poor implementation. In fact, the DIP says the following: Also, having a package and module with the same name will result in an ambiguity error when you try and import them (e.g. foo/bar/package.d and foo/bar.d). So the current behavior actually deviates from the design! Directory names have always been regarded as having a 1:1 correspondence with package names in D. This is not new. std.algorithm corresponds to std/algorithm.d This does not explain or justify the problem this bug report is describing. As I recall, this was debated at length and was implemented months ago. I do not recall any discussion that reached a consensus that the first directory in D's search path should be treated as the match for an import of the same name. I am sorry it breaks some existing setups, but the behavior is designed, and is not a bug. There were several proposals, and this one broke the least and before this everyone has liked it. I am sorry, but judging by your arguments quoted above, I must conclude that you either don't understand the problem, or are unable to justify the current behavior. I must ask you to read my arguments carefully and respond to my clarification requests directly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
