Re: D Logic bug
On Thursday, 11 October 2018 at 14:35:34 UTC, James Japherson wrote: Took me about an hour to track this one down! A + (B == 0) ? 0 : C; D is evaluating it as (A + (B == 0)) ? 0 : C; That's why shouldn't compose it like that. It's been a constant source of bugs in C/C++ code: https://www.viva64.com/en/b/0583/#ID0E1CAC
Re: Deep nesting vs early returns
On Tuesday, 2 October 2018 at 18:14:55 UTC, Andrei Alexandrescu wrote: Kate Gregory makes a good argument on something I've often commented in code reviews: https://youtu.be/n0Ak6xtVXno?t=2682 Sean Parent covered early exits years ago in an excellent talk I just can't find anymore (maybe someone can point me to it?). He nicely described how all that nesting builds up a huge context you need to keep in your brain while trying to reason about the function.
Re: John Regehr on "Use of Assertions"
On Wednesday, 5 September 2018 at 19:35:46 UTC, Meta wrote: I think the only sane way to use asserts as an optimization guide is when the program will abort if the condition does not hold. Which is the usual behavior of assert. I'm all for using them to optimize but it's not clear how to do that. You can't just blindly turn it into assume since that may actually impede optimizations: https://llvm.org/docs/LangRef.html#llvm-assume-intrinsic
Re: fix C ABI
On Friday, 7 September 2018 at 04:36:20 UTC, Mike Franklin wrote: On Thursday, 6 September 2018 at 01:24:35 UTC, Laeeth Isharc wrote: https://issues.dlang.org/show_bug.cgi?id=19179 https://issues.dlang.org/show_bug.cgi?id=5570 https://issues.dlang.org/show_bug.cgi?id=13957 According to BountySource (https://www.bountysource.com/teams/d/issues?tracker_ids=383571) Issue 5570 already has a bounty of $445. With the addition of your $500 that would make the bounty $945, which isn't bad. Must be pretty hard to fix though if yebblies couldn't do it.
Re: Messing with betterC and string type.
On Friday, 7 September 2018 at 08:26:11 UTC, Kagamin wrote: You can sort of have custom literals like in C++ String s(object.string t){ return String(t); } foo("this".s); Awesome :D
Re: John Regehr on "Use of Assertions"
On Sunday, 2 September 2018 at 21:12:39 UTC, Nick Sabalausky (Abscissa) wrote: This does make me think of one thing: Shouldn't assert expressions be required to be pure? (even if only weakly pure) Not sure how much practical problems that would create, but at least in theory it certainly sounds like the right thing. Exactly. You may still catch assert(!fclose(f)) but not other non-obvious functions. Nice trick to find them in C: https://stackoverflow.com/questions/10593492/catching-assert-with-side-effects/35294344#35294344
Re: John Regehr on "Use of Assertions"
On Saturday, 1 September 2018 at 20:15:15 UTC, Walter Bright wrote: Note the "may or may not be evaluated." We've debated this here before. I'm rather pleased that John agrees with me on this. It shouldn't allow side-effects then though. https://run.dlang.io/is/P6VnYd Also a common source of bugs in C.
Re: D is dead
On Friday, 24 August 2018 at 09:52:20 UTC, Walter Bright wrote: On 8/24/2018 1:45 AM, Trass3r wrote: Are you referring to http://wg21.link/P0709 ? Yes. (please don't use link shorteners, they tend to go poof) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r1.pdf I expect it to always point to the latest revision. Not sure if it's an official WG21 service though. Anyway, very interesting paper and approach. I'm eager to see how this will work out.
Re: D is dead
On Thursday, 23 August 2018 at 23:27:51 UTC, Walter Bright wrote: Back to throwing constructors. 1) They are expensive, adding considerable hidden bloat in the form of finally blocks, one for each constructing field. These unwinding frames defeat optimization. The concept of "zero-cost exception handling" is a bad joke. (Even Chandler Carruth stated that the LLVM basically gives up trying to optimize in the presence of exception handlers.) Herb Sutter has a recent paper out proposing an alternative, completely different, error handling scheme for C++ because of this issue. Are you referring to http://wg21.link/P0709 ?
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Thursday, 23 August 2018 at 07:37:07 UTC, Iain Buclaw wrote: Possible Solution: Make all globals hidden by default unless 'export'. Same mess as in C++. But there you have -fvisibility=hidden at least to fix it. Side effects: Everyone will be spending weeks to months fixing their libraries in order to only mark what should be visible outside the current compilation unit as 'export'. Shouldn't it be sufficient to put an export: at the top of each module to roll back to the old behavior and do the real fix later? Benefits: Faster compile times, as in, in the most extreme example I've built one project on github with gdc -O2 and build time went from 120 seconds to just 3! So why not add such an opt-in flag to all compilers, deprecate the old behavior and do the switch at some point.
Re: core.attribute - Remove friction for compiler attributes
On Tuesday, 20 October 2015 at 07:57:29 UTC, Marco Leise wrote: For a while now GDC and LDC have supported a variety of their backend's attributes, like inlining or compiling a specific function with SSE4 in an otherwise generic x64 build. I think we should unify those into a common core.attribute, either aliasing or replacing the vendor specific symbols. They don't need to be functional immediately. There are two things that I see need to be discussed. I couldn't agree more. It's awkward having to write such boilerplate code just to get something as common as @inline to compile across compilers. Another example: https://github.com/JinShil/stm32f42_discovery_demo/blob/d61819015/source/runtime/object.d#L16 And for embedded applications @used, @section(".xy") and @weak would also be useful.
C++ static exceptions proposal
http://wg21.link/P0709 Interesting read. Looks like they want to bake something like llvm::Expected into the language. I wonder if D shares all these dynamic exceptions issues. In any case it should become relevant if they really change the C ABI as well.
Re: Shout out to D at cppcon, when talkign about ranges.
Here's the original discussion with Eric's elaborate answer: http://ericniebler.com/2014/02/21/introducing-iterables/#comment-403 Because I want to leverage the vast amount of iterator-based code already written, and because in my experience, I don’t find that ranges as primitives solve all the problems that iterators do. Many algorithms return positions. These all suffer the same problem as find. One algorithm implementation isn’t sufficient; you need bunches of differently-named algorithms that differ only in the subrange they return. As for the political argument: I want ranges in the standard. There is just no way the C++ standardization committee would ever consider a range-only interface.
Re: Shout out to D at cppcon, when talkign about ranges.
On Tuesday, 6 October 2015 at 22:39:01 UTC, Ulrich Küttler wrote: Yes, this is an explanation. Thanks. So the argument being C++ customs. Now that you mention it, this seems to be the argument in Eric's D4128 paper, too. I was hoping for a somewhat deeper reasoning. Out of curiously, I am still trying to grasp all the implications. Ranges are hard. Another one is "odd number of iterators algorithms" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4128.html#appendix-3-d-ranges-and-algorithmic-complexity D’s choice of algorithmic basis operations is inherently less efficient than C++’s.
Re: OPTLINK Error 45 Too Much DEBUG Data for Old CodeView format
Just save yourself lots of headaches and abandon the optlink/omf crap with -m64 resp. -m32mscoff.
Re: dmd test coverage
Plenty of not covered lines are actually assert(0)'s.
Re: Microsoft now giving away VS 2013
On Thursday, 13 November 2014 at 09:36:26 UTC, Manu via Digitalmars-d wrote: On 13 November 2014 10:57, Walter Bright wrote: This is good news for D! It lowers the bar for writing 64 bit D code on Windows, and it also enables us to abandon support for versions of VS prior to 2013. Many, many corporate VS users get stuck on legacy versions of VS for a very long time. We still use VS2010 at work for instance, with no plan to upgrade. It would be a shame to lose legacy VS support, but I think the focus should certainly emphasise these future releases. It's perfectly possible to install newer versions side-by-side and even combine the new IDE with the old crap compiler for transitioning, which I've done since the very first CTP. Starting with 2013 the express editions are also fully usable and only lack plugin support. The rest is just excuses.
Re: `alias newSymbol = existingSymbol` or `alias existingSymbol newSymbol`
Let the bikeshedding begin. They treat the style guide like the holy bible.
Re: Linux 64bit Calling Convention
https://github.com/D-Programming-Language/dmd/pull/4092
Re: Arduino and D
my work has stalled as I try to find a way to make the experience more polished, and less like patchwork. It's a shame this went nowhere: https://issues.dlang.org/show_bug.cgi?id=12270
Re: LDC 0.15.0 alpha1 released! Please help test!
Does this msvc based build output gdb-compatible debugging symbols? No DWARFs in there.
Re: Linux 64bit Calling Convention
On Thursday, 28 February 2013 at 01:03:08 UTC, Maxime Chevalier wrote: I did some further testing: void foo(int a, int b) { writefln(a: %s, a); writefln(b: %s, b); } unittest { foo(1, 2); asm { mov RDI, 1; mov RSI, 2; call foo; } } Produces: a: 1 b: 2 a: 2 b: 1 Unless I'm mistaken, DMD does not respect the C calling convention on Linux/AMD64. True. For extern(D) dmd passes parameters in reverse order on Win64 and Linux64! What the heck?
Re: Linux 64bit Calling Convention
On Thursday, 28 February 2013 at 02:02:09 UTC, Walter Bright wrote: On 2/27/2013 5:03 PM, Maxime Chevalier wrote: Unless I'm mistaken, DMD does not respect the C calling convention on Linux/AMD64. To use the C calling convention, specify extern (C) for the function. This is about extern(D).
Re: Linux 64bit Calling Convention
Looking at the code extern(D) is in the _revfunc list in optabgen. Which seems to cause params to be reversed independent of the architecture in FuncDeclaration::toObjFile // Reverse params[] entries. Meaning Linux x32 would also be affected. This totally smells like a remnant as the code matches the initial custom Win32 D ABI.
Re: Linux 64bit Calling Convention
Yes it's clearly stated on the ABI page (and sane). Nobody ever noticed cause it's hard to spot this in assembly. But it was very salient and disturbing in llvm IR.
Re: Consistent bugs with dmd -O -inline in a large project
LDC is 2.065 Already 2.066 in the repo.
Re: template constraint diagnostics
I don't think it would be too difficult. You are analyzing an expression that evaluates to false, and it wouldn't take much to dig down to find out which subexpressions cause the false to occur. I think it's not that straightforward in dmd as it simply delegates the constraint to the interpreter and uses the resulting bool.
Re: Consistent bugs with dmd -O -inline in a large project
What should I do? Am I stuck with not using -O and -inline for now, hoping that things will improve in the future? Step 1) DustMite the heck out of it and create a bug report. Step 2) Start using ldc/gdc for release builds if possible.
template constraint diagnostics
http://youtu.be/qwXq5MqY2ZA?t=33m57s I wish we had diagnostics like that in D.
Re: dsource and WinAPI
the long-term solution is to include the [win32] headers in druntime ™
Re: How do I write __simd(void16*, void16) ?
On Wednesday, 8 October 2014 at 18:56:31 UTC, Etienne wrote: I can't seem to find this function anywhere: __simd(void16*, void16) MOVDQU = void _mm_storeu_si128 ( __m128i *p, __m128i a) MOVDQU = __m128i _mm_loadu_si128 ( __m128i *p) Is there a module by now that allows to directly write Intel intrinsics?
Re: Local functions infer attributes?
On Sunday, 28 September 2014 at 02:56:57 UTC, deadalnix wrote: Also, inferring everything is quite expensive and we want D to compile fast. Doesn't the compiler have to do that anyway? I'd expect a proper compiler to check if my code is actually what I claim it is. It's quite easy to mark something as e.g. nogc in the first version and later on add code with allocations.
Re: What's blocking DDMD?
https://auto-tester.puremagic.com/?projectid=10 Just windows left now. Looks like a dash is missing? ofmagicport\magicport2.exe magicport\magicport2.d magicport\ast.d magicport\scanner.d magicport\tokens.d magicport\parser.d magicport\dprinter.d magicport\typenames.d magicport\visitor.d magicport\namer.d Error: 'ofmagicport\magicport2.exe' not found
Re: Once in a while, you got to stop complaining and say thank you.
Btw was there any specific commit / release that reduced memory concumption or it was a gradual improvement? No idea. One could use Digger to generate a graph of SDC build times over time like in the DConf talk.
Re: 438-byte Hello, world Win32 EXE in D
And how do ldc and gdc do? =)
Re: Lieutenant needed: build and release process
Since Git 1.8.2 you can bound a submodule to a branch. Ah cool didn't know that.
Re: Lieutenant needed: build and release process
You could also use submodules (or subtrees, haven't tried them yet).
Re: Lieutenant needed: build and release process
with 3 pull request queues Good argument for the separation :)
Re: Installing LDC on Windows
SEH was patented, so llvm doesn't support it. That has changed.
Re: Installing LDC on Windows
On Saturday, 6 September 2014 at 21:54:00 UTC, David Nadlinger wrote: On Saturday, 6 September 2014 at 17:51:16 UTC, Trass3r wrote: SEH was patented, so llvm doesn't support it. That has changed. Has it? SEH on Win64 is something entirely different from the original (x86) SEH design, and not covered by said patent. Ok 2in1. 1) As far as I know the x86 SEH patent expired in June. 2) For x64 the implementation is very close now: https://github.com/ldc-developers/ldc/issues/166#issuecomment-54522891
Re: LDC 0.14.0 alpha1 released! Please help test!
Thanks for the help with the Win64 version and for providing the binary! :) fwiw A bunch of tests still crash.
Re: LDC 0.14.0 alpha1 released! Please help test!
I also have an experimental Win64 MSVC version. https://github.com/Trass3r/ldc/releases
Re: Optlink Contribution
I don't think dmd comes with a COFF64 linker now, users are just told to install Visual Studio or the Windows SDK for a linker. No reason you can't do the same with COFF32. Optlink can stick around with OMF for a couple releases. I suspect nobody would use it when given the choice of COFF32 support. Anybody seriously programming on Windows uses VS anyway. But at least for 32 bit http://lld.llvm.org/windows_support.html could be packaged.
Re: 64-bit DMD for windows?
Is there a PR now?
Re: Optlink Contribution
What makes it craziest is that there's a COFF32 branch lying around that nobody merges: http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmar...@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com Same procedure as every year.
Re: What is the status of DLL programming in D 2.065?
On Saturday, 26 July 2014 at 07:53:54 UTC, Matt wrote: Are we able to create DLLs easily enough in D now? Do we still need to tell our D DLLs to share their GCs with the calling EXE? And is the wiki page fully up to date on the matter? If not where can we find the up to date information? Or should we be using core.runtime.Runtime.loadLibrary()? I think so, though the page is still 32-bit/Optlink centric. http://wiki.dlang.org/Win32_DLLs_in_D Just created a Win64 dll the other day: https://github.com/Trass3r/hooksample But haven't investigated GC/runtime sharing.
Re: Showing a user specified error message when no overloads match
Yeah that's the price we pay for the simplicity. Also most constraints directly or indirectly consist of a complex boolean expressions and you don't get any hint which part failed and why.
Re: Stack trace linux/windows why the difference
On linux more work should be done to get line infos, I'm investigating how to get then. Cheers ! That's the spirit!
function default arguments depending on other arguments
void foo(int a, int b = a) { } is illegal in C++ because order of evaluation is undefined. But since D defines the order to be left to right couldn't it also allow this?
core.stdc.fenv on Win64
The implementation doesn't seem to be correct. Could anybody versed in this look into it? version(Windows) { private extern __gshared fenv_t _FE_DFL_ENV; fenv_t* FE_DFL_ENV = _FE_DFL_ENV; } There's no such symbol in the libcmt and it fails to link. http://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/include/fenv.h#l87
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
druntime: make -f win64.mak DMD=../windows/bin/dmd.exe CC=\c:\l\vc10\bin64\cl.exe\ target phobos: make -f win64.mak DMD=../windows/bin/dmd.exe CC=\c:\l\vc10\bin64\cl.exe\ MAKE=c:\l\dmc\bin\make AR=\c:/l/vc10/bin64/lib.exe\ LIB=..\lib64\phobos64.lib That works? So it probably doesn't need the includes set in the makefile.
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
Nope doesn't. Setting VCDIR and SDKDIR via the make command works.
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
Setting VCDIR and SDKDIR via the make command works. Works for me. Maybe you need a newer version of make (there was a silent update in 2012, my version is 5.06). Well if you don't set VCDIR you won't get proper include paths. So no clue why it works for you.
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
The pdb debug format is not supported, AFAIK. But that format is not documented and I don't think you could add D extensions anyway. So does LLVM really support PDB? As long as they rely on the MS linker they only need to emit proper debug info into the object files. But that's still TODO: http://clang.llvm.org/docs/MSVCCompatibility.html#abi-features
Re: LinkedIn Article to be: Why you need to start moving off C/C++ to D, now.
Any other good blog posts / social media comments / pointers I can digest and use? http://planet.dsource.org
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
Digger is awesome. Have never heard of it before this talk. Unfortunately it's a huge PITA to get a Win64 build with it cause of those stupid hardcoded \Program Files (x86)\Microsoft Visual Studio 10.0\VC paths. The modified makefiles etc are always reverted by Digger before building.
Re: DConf 2014 Day 2 Talk 4: Reducing D Bugs by Vladimir Panteleev
You can add the compiler to the make command line with some magic quoting. My build script calls druntime: make -f win64.mak DMD=../windows/bin/dmd.exe CC=\c:\l\vc10\bin64\cl.exe\ target phobos: make -f win64.mak DMD=../windows/bin/dmd.exe CC=\c:\l\vc10\bin64\cl.exe\ MAKE=c:\l\dmc\bin\make AR=\c:/l/vc10/bin64/lib.exe\ LIB=..\lib64\phobos64.lib Isn't the make call hardcoded in Digger?
Re: array initializers
Can you reproduce this?
Re: TypeInfo in the library
Any news on this?
Re: Rosettacode example collection
Somebody (I think bearophile) mentioned a while back that they had a folder with all the D solutions from Rosettacode. Yeah that would indeed be nice to have.
Re: Dconf 2014 Day 2 Talk 5: Tooling: Bringing Developers and Development Together by Brad Roberts
http://youtu.be/Es8st0E5428 Thx alot! Enables me to watch it easily on my tv :)
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
http://youtu.be/n9RNxUQ0Cyk
array initializers
If you have immutable int[] arr = [0,1,0,3]; Couldn't the type of the literal be inferred as immutable? Then you could put the data into read-only memory, and maybe even elide the copy to the heap? The immutable arr type is even passed to ArrayLiteralExp::inferType but doesn't influence the literal type. But not sure what this is supposed to do.
Re: array initializers
By the way, LDC already does this today (even without optimizations turned on). My ldc doesn't. I had to cast(immutable) to actually get it to put the data as a constant. And even then it's still copied to the GC heap.
Re: array initializers
auto foo() { immutable int[] arr = [0, 1, 0, 3]; return arr; } --- produces (with optimizations on, but just for brevity) --- define { i64, i32* } @_D4test3fooFZyAi() #0 { ret { i64, i32* } { i64 4, i32* getelementptr inbounds ([4 x i32]* @.immutablearray, i32 0, i32 0) } } --- Indeed. But bool blub() { immutable int[] arr = [0,0,0,0,0,0,0,0]; return arr == [1,1,1,1,1,1,1,1]; } yields @.immutablearray = internal constant [8 x i32] zeroinitializer @.arrayliteral = internal unnamed_addr constant [8 x i32] [i32 1, i32 1, i32 1, i32 1, i32 1, i32 1, i32 1, i32 1] define i1 @_D13arrayliterals4blubFZb() #0 { %.gc_mem = tail call { i64, i8* } @_d_newarrayvT(%object.TypeInfo* @_D11TypeInfo_Ai6__initZ, i64 8) %.ptr = extractvalue { i64, i8* } %.gc_mem, 1 tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %.ptr, i8* bitcast ([8 x i32]* @.arrayliteral to i8*), i64 32, i32 1, i1 false) %tmp27 = tail call i32 @_adEq2({ i64, i8* } { i64 8, i8* bitcast ([8 x i32]* @.immutablearray to i8*) }, { i64, i8* } %.gc_mem, %object.TypeInfo* bitcast (%typeid(immutable(int)[])* @_D12TypeInfo_Ayi6__initZ to %object.TypeInfo*)) #2 %tmp28 = icmp ne i32 %tmp27, 0 ret i1 %tmp28 }
Re: array initializers
And private immutable int[] aaa = [0,1,2,3,4,5,6,7]; int foo() pure nothrow { int sum; foreach (int i; aaa) sum += i; return sum; } @_D5immut3aaayAi = constant { i64, i32* } { i64 8, i32* getelementptr inbounds ([8 x i32]* @.constarray, i32 0, i32 0) } @.constarray = internal global [8 x i32] [i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7] define i32 @_D5immut3fooFNaNbZi() #0 { forbody: %tmp15 = load i32* getelementptr inbounds ([8 x i32]* @.constarray, i64 0, i64 0), align 16 %tmp15.1 = load i32* getelementptr inbounds ([8 x i32]* @.constarray, i64 0, i64 1), align 4 %tmp19.1 = add i32 %tmp15.1, %tmp15 %tmp15.2 = load i32* getelementptr inbounds ([8 x i32]* @.constarray, i64 0, i64 2), align 8 %tmp19.2 = add i32 %tmp15.2, %tmp19.1 ... while with cast(immutable)[0,1,... : @_D5immut3aaayAi = constant { i64, i32* } { i64 8, i32* getelementptr inbounds ([8 x i32]* @.dynarrayStorage, i32 0, i32 0) } @.dynarrayStorage = internal unnamed_addr constant [8 x i32] [i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7] define i32 @_D5immut3fooFNaNbZi() #0 { endfor: ret i32 28 }
Re: Question about @nogc in D 2.066
http://forum.dlang.org/thread/pxotrowaqcenrpnnw...@forum.dlang.org
Re: Run Microsoft Analyzer over dmd source code
Is there a way to disable exceptions with MSVC like -fno-exceptions for GCC to help get rid of the associated false positives? Sure, no /EHsc and /D_HAS_EXCEPTIONS=0 for its STL.
Re: Why is the Win32 boilerplate the way it is?
The only question I have is what happens when you use SUBSYSTEM:WINDOWS:4.0 (Which I understand means XP or higher) and the program runs on something older? WinXP is dead :)
Re: Why are breakpoints caught by the runtime?
On Monday, 16 June 2014 at 01:23:28 UTC, Daniel Murphy wrote: Trass3r wrote Is there any good reason to catch that? I really want the debugger to fire up. I know, I hate this. You can disable it by changing rt_trapExceptions in dmain2.d in druntime to false and rebuilding druntime, which is horrible but what I usually do. Unfortunately it is read before Dmain and the module constructors are run so it's tricky to clear on startup. So you can't even do something like extern extern (C) __gshared bool rt_trapExceptions; void main() { rt_trapExceptions = false; asm { int 3; } } Strangely enough now my original example triggers the debugger. Not a clue what changed.
Re: what is going on with cgcs.c:351?
I think it should be possible to run DustMite on some big project like phobos to actually search for such internal errors.
Why are breakpoints caught by the runtime?
void main() { asm { int 3; } } object.Error: Breakpoint 0x00402013 in _Dmain at bptest.d(6) 0x00402314 in void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll().void __lambda1() 0x004022E7 in void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() 0x00402200 in _d_run_main Is there any good reason to catch that? I really want the debugger to fire up.
Re: Why are breakpoints caught by the runtime?
Win7 x64
Re: Why are breakpoints caught by the runtime?
It is default windows runtime behavior Yeah but couldn't/shouldn't it let breakpoints through?
Re: enum scope
On Thursday, 26 January 2012 at 01:06:46 UTC, Trass3r wrote: When writing C bindings I usually create lots of aliases via a string mixin to pull enum members into the enclosing scope so it's compatible to C. Would it be wise to let the compiler do this automatically for extern(C) enums? Does anyone know how you would implement this in the compiler?
generic image processing library?
Is there any generic D image processing library similar to Adobe's boost::GIL?
Re: Compiling dmd on Windows
On Saturday, 1 February 2014 at 19:28:54 UTC, Andrej Mitrovic wrote: On 2/1/14, Paulo Pinto pj...@progtools.org wrote: Shouldn't those makefiles use Windows only tools? Those makefiles should be just one makefile that works across platforms by using GNU Make, but some people love the idea of maintaining 10 different makefiles that are already awfully out of sync, all because DM Make exists. Actually there should something along the lines of a CMakeLists.txt so you are free to use whatever you want, including IDEs.
Re: GPGPUs
On Sunday, 18 August 2013 at 18:35:45 UTC, Russel Winder wrote: https://github.com/Trass3r/cl4d I had missed that as well. Bad Google and GitHub skills on my part clearly. I think the path is now obvious, ask if the owner will turn this repository over to a group so that it can become the focus of future work via the repositories wiki and issue tracker. I will fork this repository as is and begin to analyse the status quo wrt the discussion recently on the email list. Interesting. I discovered this thread via the just introduced traffic analytics over at Github ^^ Haven't touched the code for a long time but there have been some active forks. I've been thinking to offer push rights to them for quite a while but never got around to it.
CMake script for dmd source
Has anyone ever created a CMakeLists.txt for the dmd source?
Re: CMake script for dmd source
Do you need help?
anyone ever tried to DustMite C++ code?
..and thus already has a working splitter?
Re: D SFML2 derelict
compiled with: dmd hello.d rdmd hello.d
Re: Debugging compiler crashes?
dmd: glue.c:542: virtual void FuncDeclaration::toObjFile(int): Assertion `semanticRun == PASSsemantic3done' failed. Aborted wouter@carillon:~/code/d/DustMite$ ... and I'm not yet that fluent in D to understand what's going on. Any ideas? pass dustmite.d before dsplit.d known problem, but the error message has changed
Re: Debugging compiler crashes?
... the order of files matters? Yuck. Yep it's a bug.
Re: Handling of compiler patches
1) Currently the patches that Walter applies written by other people come mostly from the most recent ones. I think this is not good. Yep, github's default sort method sucks. They should really implement some sort of voting scheme or something like a ready to merge button for prolific contributors. Interestingly enough they even seem to have a 'votes' field for pull requests internally (http://develop.github.com/p/pulls.html) but I haven't seen any voting system yet. I suggest to do the opposite, this means to manage that list more like a queue (first in - first out), so I suggest Walter to look for patches to apply starting from the oldest ones. This has the advantage that the patches don't get too much old, so they rot less. +1 It's just annoying having to keep pull requests up-to-date forever. AND it definitely pisses contributors off. At least I won't submit anything anymore if the pulls just rot anyways. Also I really wonder if Walter's using the autotester. Most patches are ridiculously small and/or non-critical, so reviewing the code by hand can't take that long. And if you properly use the autotester instead of manually running the testsuite to verify it doesn't break anything you should really be able to merge a whole bunch of pulls in no time. Why is the process still so slow?
Re: Lack of warning messages
A notice for some unused imports would be great too... You could create a brute-force tool. Rip off an import statement at a time and see if it still compiles. One could probably modify DustMite to do that.
Re: DMD + msvc
Object generation is an unholy disaster of IFDEF's and my brain has melted every time I try to venture into it Funnily enough, cppcheck shares your opinion on the backend: Interrupted checking because of too many #ifdef configurations
FWIW: results of cppcheck on dmd sources
http://trass3r.github.com/dmd-cppcheck/ Seems like the tool isn't dead after all so I tried it out with the dmd sources. Some false positives but also some valid points. E.g. http://trass3r.github.com/dmd-cppcheck/15.html#line-960 looks particularly interesting.
Re: FWIW: results of cppcheck on dmd sources
There are surprisingly few notices of memory leaks considering DMD uses a GC. This is news to me. Has the GC been re-enabled?
And for completeness: results of HEAD clang analyzer
http://trass3r.github.com/dmd-clang/
Re: FWIW: results of cppcheck on dmd sources
I think in general fixing cppcheck's complaints makes the code more understandable and maintainable, even if it doesn't actually fix anything. +1
Re: FWIW: results of cppcheck on dmd sources
This is news to me. Has the GC been re-enabled? No, it's just that cppcheck doesn't (and cannot) detect global memory leaks - only very localized ones. btw, what is the stance on adding some manual memory freeing, at least for obvious local leaks?
Re: GDC review process.
1) D Inline Asm and naked function support is raising far too many alarm bells. So would just be easier to remove it and avoid all the other comments on why we need middle-end and backend headers in gdc. And the C++ frontend doesn't need these headers for its inline assembler implementation?
Re: GDC review process.
Plus, gcc asm syntax is horrible, and DMD's is really nice. yep, ATT vs. Intel syntax :)
Re: GDC review process.
Please be informed that GCC inline asm supports Intel syntax... With -masm=intel.
Re: DMD + msvc
Does this somewhat vague statement meant that we are getting COFF support in the near term? Yes, because that is necessary for MSVC linker compatibility. Hooray!
Re: Casting the Result of splitter() into a string array
If you want to convert a range to an array, use std.array.array This is a constant source of confusion and it also is a crappy design to use a function in a totally different module for this purpose imho. Can't these Result types get an eval() method and/or be made implicitly convertible to an array where appropriate? The C++ matrix library Eigen uses this approach and it works out fantastically. a*b returns an object representing this expression. If I do want to use this I write 'auto c=a*b;'. If I want the result I can explicitly use its eval() method (which is especially useful inside a bigger expression) or something like 'Matrix c=a*b;' which also evaluates the expression.
Re: align(16) struct member throws an exception with movdqa
test code please
Re: align(16) struct member throws an exception with movdqa
import std.stdio, core.simd; void main() { int4 v; } Internal error: ..\ztc\cgcod.c 1447 Building Debug\dtest1.exe failed! Works fine on Linux. Maybe the 32Bit check doesn't work for Windoze? -m32 on Linux yields Error: SIMD vector types not supported on this platform
Re: align(16) struct member throws an exception with movdqa
I think it has been fixed for the next version of DMD already. Any idea why align isn't letting me use movdqa? Cause align doesn't work the way you think it does. In fact I still don't understand how it works at all.