Re: D2 port of Sociomantic CDGC available for early experiments
Am 11.10.2014 06:25, schrieb Andrei Alexandrescu: On 10/10/14, 7:54 PM, Walter Bright wrote: On 10/10/2014 5:45 PM, Leandro Lucarella wrote: I still don't understand why wouldn't we use environment variables for what they've been created for, it's foolish :-) Because using environment variables to tune program X will also affect programs A-Z. Nope. Try this at your Unix command prompt: echo $CRAP CRAP=hello echo $CRAP CRAP=world echo $CRAP in windows there are user-environment-variables (walter talking about) and shell-environment variables (like in your example) setting user-environement variables will affect every program thats why java is not using them
Re: DConf 2014 Keynote: High Performance Code Using D by Walter Bright
Am 18.07.2014 07:54, schrieb Walter Bright: On 7/17/2014 9:40 PM, dennis luehring wrote: i understand your focus on dmd - but talking about fast code and optimizing WITHOUT even trying to compare with other compiler results is just a little bit strange for someone who stated speed = money The point was to get people to look at the asm output of the compiler, as results can be surprising (as you've also discovered). ...of the compilerS - please :) can you post your (full, closed) D array access example from the talk so i don't need to play around with the optimizer to get your asm results
Re: DConf 2014 Keynote: High Performance Code Using D by Walter Bright
Am 18.07.2014 04:52, schrieb Walter Bright: On 7/16/2014 7:21 AM, dennis luehring wrote: can you give an short (working) example code to show the different resulting assembler for your for-rewrite example - and what compilers your using for testing - only dmd or gdc? I used dmd. i sometimes got the feeling that you underestimate the sheer power of todays clang or gcc optimizers - so partly what gdc/ldc can do with your code reminds me of brian schotts exmaple of his sse2 optimized version of his lexer - the dmd generated was much faster then the normal version, but gdc/ldc results of the unoptimized versions are still 50% faster i understand your focus on dmd - but talking about fast code and optimizing WITHOUT even trying to compare with other compiler results is just a little bit strange for someone who stated speed = money
Re: DConf 2014 Keynote: High Performance Code Using D by Walter Bright
Am 15.07.2014 18:20, schrieb Andrei Alexandrescu: http://www.reddit.com/r/programming/comments/2aruaf/dconf_2014_keynote_high_performance_code_using_d/ https://www.facebook.com/dlang.org/posts/885322668148082 https://twitter.com/D_Programming/status/489081312297635840 Andrei @Walter can you give an short (working) example code to show the different resulting assembler for your for-rewrite example - and what compilers your using for testing - only dmd or gdc? this example: T[10] array for(int i = 0; i < 10; ++i) foo(array[i]) i've tested some combination on http://gcc.godbolt.org/ with clang 3.4.1 and gcc4.9x and i can't see any difference
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
Am 12.06.2014 11:17, schrieb Dmitry Olshansky: This one thing I'm loosing sleep over - what precisely is so good in CTFE code generation in_practical_ context (DSL that is quite stable, not just tiny helpers)? By the end of day it's just about having to write a trivial line in your favorite build system (NOT make) vs having to wait for a couple of minutes each build hoping the compiler won't hit your system's memory limits. And these couple of minutes are more like 30 minutes at a times. Worse yet unlike proper build system it doesn't keep track of actual changes (same regex patterns get recompiled over and over), at this point seamless integration into the language starts felling like a joke. And speaking of seamless integration: just generate a symbol name out of pattern at CTFE to link to later, at least this much can be done relatively fast. And voila even the clunky run-time generation is not half-bad at integration. Unless things improve dramatically CTFE code generation + mixin is just our funny painful toy. you should write a big top post about your CTFE experience/problems - it is important enough
Re: Interview at Lang.NEXT
Am 05.06.2014 11:42, schrieb Jonathan M Davis via Digitalmars-d-announce: if(cond) var = "hello world"; else var = 42; The fact that an if statement could change the type of a variable is just atrocious IMHO. Maybe I've just spent too much of my time in statically typed languages, but I just do not understand the draw that dynamically typed languages have for some people. They seem to think that avoiding a few simple things that you have to do in your typical statically typed language is somehow a huge improvement when it causes them so many serious problems that static languages just don't have. maybe some sort of misunderstanded generic style of programming in prior D times :)
Re: Interview at Lang.NEXT
Am 04.06.2014 19:57, schrieb Meta: On Wednesday, 4 June 2014 at 17:55:15 UTC, bearophile wrote: How many good usages of D Variant do you know? Bye, bearophile It depends on what you mean by a good usage. I rarely ever use Variant, but you *can* use it if you need weak and/or dynamic typing. but D+Variant is still far away from an untyped language - because everything needs to be based on Variant - every signature... so it isn't an ~"correct"~ solution in this context
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
woudl be nice to have some sort of example by example comparison or as an extension to the page http://dlang.org/cpptod.html Am 28.05.2014 07:40, schrieb Jesse Phillips: On Wednesday, 28 May 2014 at 05:30:18 UTC, Philippe Sigaud via Digitalmars-d-announce wrote: I did a translation of most of the code in the slides. http://dpaste.dzfl.pl/72b5cfcb72e4 I'm planning to transform it into blog post (or series). Right now it just has some scratch notes. Feel free to let me know everything I got wrong. That's a good idea. I think most of us did that while listening to the talk. I kept telling myself: 'oh wait, that'd simpler in D' or 'that does not exist in D'. As for the class inheritance problem, I'd also be interested in an answer. When he explained why C++ inferred a const int type as int, he tripped me up because D does drop const for value types. But D does the simple to explain thing, may not be the expected thing (seen questions about it in D.learn), but it is simple to explain.
Re: warp: a fast C and C++ preprocessor
Am 28.03.2014 19:27, schrieb Andrei Alexandrescu: Facebook is open-sourcing warp, a fast C and C++ preprocessor written by Walter Bright. currently any ideas why clang could be 40% faster? https://news.ycombinator.com/item?id=7489724
Re: New debugger for D!!!
Am 28.01.2014 18:23, schrieb Sarath Kodali: >the question is - debuggers needs to throw masses >of information around - why put a slow JSON parser between, >every single step command gets JSONed, parsed, singlestep, >result gets JSOned etc... millions of times - why? I'm not fixated on JSON:) I thought that is more popular now-a-days:). Today dbg outputs in human readable format. After the alpha release, I will add the machine readable format - what everyone prefers. clear - i would just use a plugin system for adding json or whatever communication (like pin do) so its still api based - not (text/binary) protocol based from the very beginning
Re: New debugger for D!!!
Am 28.01.2014 17:24, schrieb dennis luehring: Am 28.01.2014 17:16, schrieb Sarath Kodali: I expect this is how it will be even with dbg and IDEs. The IDE will have a plugin that sits between the debugger and IDE. The communication between the IDE plugin and debugger will be over a socket and the dbg output will be in JSON format so that IDE plugin can parse it properly. Depending on the IDE, the plugin will be either a library (dll) or an independent executable. its a little bit different to pin because pin is the host of the given tool-communication dll - so the dll interface is the interface not JSON (pin(tool dll<--)-- any protocol --> ide/whatever in your idea dbg <--- socker/JASON --> ide/whatever the question is - debuggers needs to throw masses of information around - why put a slow JSON parser between, every single step command gets JSONed, parsed, singlestep, result gets JSOned etc... millions of times - why? i would suggest an real tool api for loaded protocol-drivers - like pin do - and implement a control_dbg_with_tcp_and_json.dll as a driver this way its still possible to build a super fast tracing server on top of dbg - else JSON will become a problem - without any need because the same target is reachable with a driver-dll(plugin)
Re: New debugger for D!!!
Am 28.01.2014 17:16, schrieb Sarath Kodali: I expect this is how it will be even with dbg and IDEs. The IDE will have a plugin that sits between the debugger and IDE. The communication between the IDE plugin and debugger will be over a socket and the dbg output will be in JSON format so that IDE plugin can parse it properly. Depending on the IDE, the plugin will be either a library (dll) or an independent executable. its a little bit different to pin because pin is the host of the given tool-communication dll - so the dll interface is the interface not JSON (pin(tool dll<--)-- any protocol --> ide/whatever in your idea dbg <--- socker/JASON --> ide/whatever the question is - debuggers needs to throw masses of information around - why put a slow JSON parser between, every single step command gets JSONed, parsed, singlestep, result gets JSOned etc... millions of times - why?
Re: New debugger for D!!!
Am 28.01.2014 04:00, schrieb Sarath Kodali: I'm also planning to add a JSON or CSV output format so that it will be easy to parse the output when integrating with IDEs. So I would recommend that you wait till I release 1.0 version - sometime before Dconf 2014 - hopefully! why don't ease the IDE integration even more - for example the pin tool from intel (ptools.org) is a normal executable (the server) but you can give pin a tool/commander dll per commandline which is then responsible for controling the debugger - this way its very easy to integrate the debugger into any environment fast and performant examples pin.exe -t idadbg.dll <- starts pin with an IDA-tool-dll to be able to control pin with the ida debugger pin.exe -t vsdbg.dll <- starts pin with an vs-studio debug helper this way you can use pin as an debugger for VStudio etc. csv and json is nice - but there a much nicer ways of doing ipc
Re: dmd 2.065 beta 1
Am 18.01.2014 15:13, schrieb Andrew Edwards: On 1/18/14, 8:42 AM, Daniel Murphy wrote: "Andrew Edwards" wrote in message news:lbdumk$2oki$1...@digitalmars.com... [1] ftp://ftp.digitalmars.com/dmd.2.065.beta.1.zip Windows bin folder is empty. I'd post on the list but I'm not sure it's working at the moment. Thanks. New file uploaded. still not fully automated build down to zip file :)
Re: Start of dmd 2.064 beta program
Am 31.10.2013 17:44, schrieb Leandro Lucarella: dennis luehring, el 31 de October a las 15:28 me escribiste: >>Must always use script_no1 or script_no1.d? > >And maybe one day I have a lot of .py files that I intend to >replace with D scripts TRANSPARENTLY for their user. > >Will D bow at me why I use the .py extension? > >Is D trying to shoot his own foot? It really seems to succeed >quite well. > >My boss is right: is just a toy pretending to be serious. sorry, but this is a very stupid comment: 1. never ever was a language successful(or not) because of its file-extension behavior - maybe in your world 2. i hope there is no other tool around try to find/analyse/whatever real Python programs by using the extension - else you need to change that anyway 3. "My boss is right: is just a toy pretending to be serious" - maybe, maybe not - but not because of your stupid file extension comments I think even when the wording isn't the best, what he says is true. Sometimes is hard to sell the language when things that are so trivial and fundamental (as letting file names have arbitrary names, at least for scripts) not only are broken, but are justified by the community. That's definitely not serious and discouraging. sorry for my wording - but pressure sentence like "My boss is right: is just a toy pretending to be serious" aren't fair also
Re: Start of dmd 2.064 beta program
Am 31.10.2013 16:22, schrieb eles:
On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring
wrote:
Am 31.10.2013 16:01, schrieb eles:
On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring
wrote:
Am 31.10.2013 15:45, schrieb eles:
On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring
wrote:
Am 31.10.2013 15:29, schrieb eles:
On Thursday, 31 October 2013 at 14:28:05 UTC, dennis
luehring
i don't see any chance/strategy to get D in your current
development - so if you don't want to code Python ("I WANT
pointers") anymore - try to
find a job where you can write C/C++ or D - or else your need
(and real hard interest to get your Boss in the Boart) for D
seems to be not big enough - i would quit my job very fast if
someone forces me to write Python code most of the time - thats
all
Frankly, just stop advising me to take a new job. It is the kind
of advice that I really find intrusive and unbearable.
no problem :)
so tell the story what would happen if D scripts will be without .d?
is your Boss then more interested or can you introduce D-scripts then
silently - what would happen?
Re: Start of dmd 2.064 beta program
Am 31.10.2013 16:01, schrieb eles:
On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring
wrote:
Am 31.10.2013 15:45, schrieb eles:
On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring
wrote:
Am 31.10.2013 15:29, schrieb eles:
On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring
wrote:
3. "My boss is right: is just a toy pretending to be
serious"
better try to find a more experienced, serious Boss
Do you offer yourself for his job?
why should i?
Then don't tell me what I should feel to do about my job.
'Cause you don't deserve other answer than "why should I"?
i don't see any chance/strategy to get D in your current development -
so if you don't want to code Python ("I WANT pointers") anymore - try to
find a job where you can write C/C++ or D - or else your need (and real
hard interest to get your Boss in the Boart) for D seems to be not big
enough - i would quit my job very fast if someone forces me to write
Python code most of the time - thats all
Re: Start of dmd 2.064 beta program
Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. "My boss is right: is just a toy pretending to be serious" better try to find a more experienced, serious Boss Do you offer yourself for his job? why should i?
Re: Start of dmd 2.064 beta program
Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. "My boss is right: is just a toy pretending to be serious" better try to find a more experienced, serious Boss Do you offer yourself for his job? Maybe because I don't want to have a code base written in several languages? And seriously, about your former argument about the importance of the extension in being serious or not: accepting arbitrary extension was the reason for C++ doom? just 0,001% of it - but a clear definition is always bettern then a floaty like "you should use .d as extension"
Re: Start of dmd 2.064 beta program
Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. "My boss is right: is just a toy pretending to be serious" - maybe, maybe not - but not because of your stupid file extension comments It adds. Tell to my boss about that extensions and he will be grateful for you providing him ONE MORE REASON to laugh. At me. question: why are you using D if 1. Python works for you 2. Python doesnt suffer from the BIG-BIG file-extension problem 3. your laughing Boss tells you D is a toy i don't get it better try to find a more experienced, serious Boss
Re: Start of dmd 2.064 beta program
Must always use script_no1 or script_no1.d? And maybe one day I have a lot of .py files that I intend to replace with D scripts TRANSPARENTLY for their user. Will D bow at me why I use the .py extension? Is D trying to shoot his own foot? It really seems to succeed quite well. My boss is right: is just a toy pretending to be serious. sorry, but this is a very stupid comment: 1. never ever was a language successful(or not) because of its file-extension behavior - maybe in your world 2. i hope there is no other tool around try to find/analyse/whatever real Python programs by using the extension - else you need to change that anyway 3. "My boss is right: is just a toy pretending to be serious" - maybe, maybe not - but not because of your stupid file extension comments thx
Re: ArtemisD: A D port of Artemis Entity System Framework for games.
Am 07.10.2013 11:57, schrieb Elvis Zhou: seem nice - BUT it seems too java oop like and very ungeneric, is there a real need to derive from component? It's simple enough without over design IMO. yes - if the need of beeing part of the hierachy is not a problem :) most D libraries try to be more generic and not that strong coupled - but that comes from the java background of the project still nice
Re: ArtemisD: A D port of Artemis Entity System Framework for games.
Am 07.10.2013 11:18, schrieb Elvis Zhou: ArtemisD: A D port of Artemis Entity System Framework About Artemis Artemis is a high performance Entity System framework for games, written in Java, and is a framework to manage entities in a game world. It is inspired by Entity Systems are the future of MMORPG blog series by Adam Martin. http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ We also borrowed ideas from Ted Brown who implemented a simple high-performance Entity System in Processing based on Adam Martin's blog. http://www.openprocessing.org/sketch/18023 The framework is based on the concept that entities in a game world exist as pure identifiers,their components contain only data, and systems process entities based on their aspects.This promotes separation of concern and simplifies game design tremendously. ArtemisD: https://github.com/elvisxzhou/artemisd http://code.dlang.org Refer to http://gamadu.com/artemis for more info about Artemis. Any suggestion or PR is welcome! Elvis seem nice - BUT it seems too java oop like and very ungeneric, is there a real need to derive from component?
Re: Article: Increasing the D Compiler Speed by Over 75%
Am 12.08.2013 17:00, schrieb Richard Webb: Another little observation: Dsymbol::toPrettyChars() potentially calls toChars() twice on each symbol (so it creates 2 copies of the string representation). Some instances of toChars() just return a literal string, but for templates it can do a bunch of work. Doesn't sounds like the most efficient approach? Saying that though, it looks like a lot of the calls to that are to build error strings that are never displayed because errors are gagged, which doesn't sound ideal either? i think it would be better to start a new thread for discussion optimization - its getting too deep in here :)
Re: New malloc() for win32 that should produce faster DMD's and faster D code that uses malloc()
Am 05.08.2013 19:52, schrieb Walter Bright: On 8/5/2013 4:01 AM, Richard Webb wrote: Using the latest DMD and this snn.lib, i'm seeing it take about 11.5 seconds to compile the algorithm unit tests (when i tried it last week, it was taking closer to 17 seconds). For comparison, the MSVC build takes about 10 seconds on the same machine (Athlon 64X2 6000+). Keep up the good work :-) So I guess the DMC code generator isn't as awful as has been assumed! This is hardly the first time the culprit was a library routine, not the code generator. don't start the party to early there are still 1.5 seconds left :)
Re: New malloc() for win32 that should produce faster DMD's and faster D code that uses malloc()
Am 04.08.2013 11:28, schrieb Denis Shelomovskij: 04.08.2013 1:55, Walter Bright пОÑеÑ: The execrable existing implementation was scrapped, and the new one uses Windows HeapAlloc(). http://ftp.digitalmars.com/snn.lib This is for testing porpoises, and of course for those that Feel Da Need For Speed. So I suppose you use `HeapFree` too? Please, be sure you use this Windows API BOOL/BOOLEAN bug workaround: https://github.com/denis-sh/phobos-additions/blob/e061d1ad282b4793d1c75dfcc20962b99ec842df/unstd/windows/heap.d#L178 but please without using two ifs and GetVersion on every free call
Re: New malloc() for win32 that should produce faster DMD's and faster D code that uses malloc()
your're right it was RtlAllocateHeap Am 04.08.2013 11:25, schrieb Denis Shelomovskij: 04.08.2013 11:53, dennis luehring пОÑеÑ: Am 04.08.2013 09:35, schrieb Walter Bright: On 8/4/2013 12:19 AM, Joseph Rushton Wakeling wrote: On Sunday, 4 August 2013 at 06:07:54 UTC, dennis luehring wrote: ever tested nedmalloc (http://www.nedprod.com/programs/portable/nedmalloc/) or other malloc allocators? "Windows 7, Linux 3.x, FreeBSD 8, Mac OS X 10.6 all contain state-of-the-art allocators and no third party allocator is likely to significantly improve on them in real world results." So there may be minimal returns from incorporating nedmalloc on modern OS's ... ? As I wrote earlier, Microsoft has enormous incentive to make Heap as fast as possible, as it will pay dividends for every Microsoft software product and software designed for Windows. I'm sure the engineers there know all about the various strategies available on the intarnets. Why not take advantage of their work? HeapAlloc is a forwarder to RtlHeapAlloc and C++ new does call RtlHeapAlloc directly - would it be better to use this kernel32 api directly? (maybe if used in druntime to reduce dll dependencies) Up to Windows XP (at least) KERNEL32's HeapAlloc function is forwarded to RtlAllocateHeap [1] function exported by NTDLL so there is no runtime performance overhead. There is no RtlHeapAlloc function on my Windows XP and I can't find any information about it on the web. Looks like a Windows 6.x stuff or a mistake in name. Also note there are tons of errors because of such "slightly different" names. If we are talking about "Heap*" functions: 1. Incorrect "RtlAllocHeap" name here [2]. 2. Incorrect "HeapFree" function signature (4-byte BOOL is returned but it is just a wrapper of RtlFreeHeap which returns 1-byte BOOLEAN) (fixed in Windows 6.x). [1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff552108(v=vs.85).aspx [2] http://msdn.microsoft.com/ru-ru/magazine/cc301808(en-us).aspx
Re: New malloc() for win32 that should produce faster DMD's and faster D code that uses malloc()
Am 04.08.2013 09:35, schrieb Walter Bright: On 8/4/2013 12:19 AM, Joseph Rushton Wakeling wrote: On Sunday, 4 August 2013 at 06:07:54 UTC, dennis luehring wrote: ever tested nedmalloc (http://www.nedprod.com/programs/portable/nedmalloc/) or other malloc allocators? "Windows 7, Linux 3.x, FreeBSD 8, Mac OS X 10.6 all contain state-of-the-art allocators and no third party allocator is likely to significantly improve on them in real world results." So there may be minimal returns from incorporating nedmalloc on modern OS's ... ? As I wrote earlier, Microsoft has enormous incentive to make Heap as fast as possible, as it will pay dividends for every Microsoft software product and software designed for Windows. I'm sure the engineers there know all about the various strategies available on the intarnets. Why not take advantage of their work? HeapAlloc is a forwarder to RtlHeapAlloc and C++ new does call RtlHeapAlloc directly - would it be better to use this kernel32 api directly? (maybe if used in druntime to reduce dll dependencies)
Re: New malloc() for win32 that should produce faster DMD's and faster D code that uses malloc()
Am 03.08.2013 23:55, schrieb Walter Bright: The execrable existing implementation was scrapped, and the new one uses Windows HeapAlloc(). http://ftp.digitalmars.com/snn.lib This is for testing porpoises, and of course for those that Feel Da Need For Speed. ever tested nedmalloc (http://www.nedprod.com/programs/portable/nedmalloc/) or other malloc allocators?
Re: Increasing D Compiler Speed by Over 75%
Am 01.08.2013 08:16, schrieb Rainer Schuetze: On 01.08.2013 07:33, dennis luehring wrote: Am 31.07.2013 23:24, schrieb Rainer Schuetze: On 31.07.2013 09:00, Walter Bright wrote: On 7/30/2013 11:40 PM, dennis luehring wrote: currently the vc builded dmd is about 2 times faster in compiling That's an old number now. Someone want to try it with the current HEAD? I have just tried yesterdays dmd to build Visual D (it builds some libraries and contains a few short non-compiling tasks in between): can you also give us also timings for (dmd_dmc|dmd_msc) std\algorithm -unittest -main std.algorithm -unittest -main: dmd_dmc 20 sec, std new 61 sec dmd_msc 11 sec, std new 13 sec std.algorithm -unittest -main -O: dmd_dmc 27 sec, std new 68 sec dmd_msc 16 sec, std new 18 sec results from mingw, vs2012(13) and llvm-clang builds would be also very interesting, but i don't know if dmd can be build with mingw or clang out of the box under windows
Re: Increasing D Compiler Speed by Over 75%
Am 01.08.2013 08:16, schrieb Rainer Schuetze: On 01.08.2013 07:33, dennis luehring wrote: Am 31.07.2013 23:24, schrieb Rainer Schuetze: On 31.07.2013 09:00, Walter Bright wrote: On 7/30/2013 11:40 PM, dennis luehring wrote: currently the vc builded dmd is about 2 times faster in compiling That's an old number now. Someone want to try it with the current HEAD? I have just tried yesterdays dmd to build Visual D (it builds some libraries and contains a few short non-compiling tasks in between): can you also give us also timings for (dmd_dmc|dmd_msc) std\algorithm -unittest -main std.algorithm -unittest -main: dmd_dmc 20 sec, std new 61 sec dmd_msc 11 sec, std new 13 sec std.algorithm -unittest -main -O: dmd_dmc 27 sec, std new 68 sec dmd_msc 16 sec, std new 18 sec so we can "still" say das msc builds are around two times faster - or even faster
Re: Increasing D Compiler Speed by Over 75%
Am 31.07.2013 23:24, schrieb Rainer Schuetze: On 31.07.2013 09:00, Walter Bright wrote: On 7/30/2013 11:40 PM, dennis luehring wrote: currently the vc builded dmd is about 2 times faster in compiling That's an old number now. Someone want to try it with the current HEAD? I have just tried yesterdays dmd to build Visual D (it builds some libraries and contains a few short non-compiling tasks in between): can you also give us also timings for (dmd_dmc|dmd_msc) std\algorithm -unittest -main
Re: Increasing D Compiler Speed by Over 75%
Am 31.07.2013 09:00, schrieb Walter Bright: On 7/30/2013 11:40 PM, dennis luehring wrote: currently the vc builded dmd is about 2 times faster in compiling That's an old number now. Someone want to try it with the current HEAD? tried to but failed downloaded dmd-master.zip (from github) downloaded dmd.2.063.2.zip buidl dmd-master with vs2010 copied the produces dmd_msc.exe to dmd.2.063.2\dmd2\windows\bin dmd.2.063.2\dmd2\src\phobos>..\..\windows\bin\dmd.exe std\algorithm -unittest -main gives Error: cannot read file ûmain.d (what is this "û" in front of main.d?) dmd.2.063.2\dmd2\src\phobos>..\..\windows\bin\dmd_msc.exe std\algorithm -unittest -main gives std\datetime.d(31979): Error: pure function 'std.datetime.enforceValid!"hours".enforceValid' cannot call impure function 'core.time.TimeException.this' std\datetime.d(13556): Error: template instance std.datetime.enforceValid!"hours" error instantiating std\datetime.d(31984): Error: pure function 'std.datetime.enforceValid!"minutes".enforceValid' cannot call impure function 'core.time.TimeException.this' std\datetime.d(13557): Error: template instance std.datetime.enforceValid!"minutes" error instantiating std\datetime.d(31989): Error: pure function 'std.datetime.enforceValid!"seconds".enforceValid' cannot call impure function 'core.time.TimeException.this' std\datetime.d(13558): Error: template instance std.datetime.enforceValid!"seconds" error instantiating std\datetime.d(33284):called from here: (TimeOfDay __ctmp1990; , __ctmp1990).this(0, 0, 0) std\datetime.d(33293): Error: CTFE failed because of previous errors in this std\datetime.d(31974): Error: pure function 'std.datetime.enforceValid!"months".enforceValid' cannot call impure function 'core.time.TimeException.this' std\datetime.d(8994): Error: template instance std.datetime.enforceValid!"months" error instantiating std\datetime.d(32012): Error: pure function 'std.datetime.enforceValid!"days".enforceValid' cannot call impure function 'core.time.TimeException.this' std\datetime.d(8995): Error: template instance std.datetime.enforceValid!"days" error instantiating std\datetime.d(33389):called from here: (Date __ctmp1999; , __ctmp1999).this(-3760, 9, 7) std\datetime.d(33458): Error: CTFE failed because of previous errors in this Error: undefined identifier '_xopCmp' and a compiler crash my former benchmark where done the same way and it worked without any problems - this master seems to have problems
Re: Increasing D Compiler Speed by Over 75%
Am 30.07.2013 11:04, schrieb Temtaime: DMC is ugly compiler. It will be much nicer if you'll use mingw for that purpose on Windows. GCC usually generates more faster code that VC does. http://sourceforge.net/projects/mingwbuilds/ > DMC is ugly compiler. ugly means bad or miss-designed, but please show me a better 16/32(64) bit full c/c++ compiler out there > GCC usually generates more faster code that VC does. currently the vc builded dmd is about 2 times faster in compiling, do you think that a mingw build will even top this?
Re: DScanner is ready for use
Am 28.07.2013 00:27, schrieb Brian Schott: DScanner is a tool for analyzing D source code. It has the following features: * Prints out a complete AST of a source file in XML format. * Syntax checks code and prints warning/error messages * Prints a listing of modules imported by a source file * Syntax highlights code in HTML format * Provides more meaningful "line of code" count than wc * Counts tokens in a source file The lexer/parser/AST are located in the "std/d" directory in the repository. These files should prove useful to anyone else working on D tooling. https://github.com/Hackerpilot/Dscanner Aside: the D grammar that I reverse-engineered can be located here: https://rawgithub.com/Hackerpilot/DGrammar/master/grammar.html would be nice to habe some sort of binary output (beside xml and json) to ease (and maybe speed-up) the usage
Re: Increasing D Compiler Speed by Over 75%
Am 25.07.2013 20:03, schrieb Walter Bright: http://www.reddit.com/r/programming/comments/1j1i30/increasing_the_d_compiler_speed_by_over_75/ do you compare dmc based and visualc based dmd builds? the vc dmd build seems to be always two times faster - how does that look with your optimization?
Re: monarch dodra granted write access to phobos, druntime, and tools
Am 23.07.2013 21:23, schrieb Andrei Alexandrescu: On 7/23/13 8:27 AM, Leandro Lucarella wrote: You don't need push access to the blessed repository to contribute, THAT's why git exists! Only people merging stuff needs push access and is good to keep that team as small as possible (and if there is a review bottleneck then it is too small and needs to be expanded). Right now, fortunately, the lack of review doesn't seem to be a huge bottleneck, and while having committed, smart people helping could be beneficial, I think is wise not to give every contributor push access to the repo right now. I'm very surprised by your outlook. My perception is that the long queue of pending pull requests not being reviewed is the single most important bottleneck at this point in history in the path of D. By my estimates I think we'd improve the speed of D's development by at least one third if we solve this one issue. There's no other issue offering so much impact. I also think it may transform into a major crisis (an inflection point in pull requests rate followed by a decline) if we leave this unresolved. We must find a solution to reviewing pull requests, and fast. Andrei what about something like an (linux) stage repository, more integrated pull request, more main repo aspirants
Re: DConf 2013 Day 1 Talk 3: Distributed Caching Compiler for D by Robert Schadek
Am 14.05.2013 08:18, schrieb Walter Bright: On 5/13/2013 10:19 PM, dennis luehring wrote: Am 13.05.2013 14:01, schrieb Andrei Alexandrescu: Watch, discuss, vote up! http://reddit.com/r/programming/comments/1e8mwq/dconf_2013_day_1_talk_3_distributed_caching/ Andrei it seems that the http://www.phoronix.com/ guys miss the dconf completely - they write about rust, go, D in gcc, kernel udpates etc. - but absolutely nothing about dconf :( Email them about it! is there something like an overview page with slides, videos etc.? dconf.org - could someone change the main page to reflect the success of the conference :)
Re: DConf 2013 Day 1 Talk 3: Distributed Caching Compiler for D by Robert Schadek
Am 13.05.2013 14:01, schrieb Andrei Alexandrescu: Watch, discuss, vote up! http://reddit.com/r/programming/comments/1e8mwq/dconf_2013_day_1_talk_3_distributed_caching/ Andrei it seems that the http://www.phoronix.com/ guys miss the dconf completely - they write about rust, go, D in gcc, kernel udpates etc. - but absolutely nothing about dconf :(
Re: February 20, 2013—Component Programming in D—Walter Bright - slides & video
Am 22.02.2013 21:22, schrieb Walter Bright: First off I would like to thank everyone who donated to our camera drive. but they still missing a wireless microphone for the questioners :) good talk - but i think you should be more clear about the target of your presentation, its started with simple components and ranges and then it mutated very fast into pipeline programming (design, paradigm, threading, multiple in/out pipes) questions - and except that everything can handled by throwing an exception, the error handling in complex pipeline programming "can" be much harder, very doable in D - but D(it libs) isn't currently in a state for doing complex pipeline programming out "of the box" (or designed for beeing so) it think that wasn't clear enough through the talk
DPaste should become something like an standard for dlang.org
dlang samples should be run by DPaste - maybe with an cache for not calling the compiler for each visit :) also bugzilla sample should be DPasted per default anyone got plans for this
Re: Getting ready for 2.061
Am 22.12.2012 13:15, schrieb Russel Winder: After New Year/Hogmanay, or earlier if possible, I will reinvestigate all the factors and update the issue appropriately. sound for me like an bug in the dmd code generation - ldc frontend code should be nearly the same (or better: i don't think that the ldc guys fix silently frontend bugs), backend is totaly different, phobos should be also the same
Re: Getting ready for 2.061
Am 22.12.2012 11:31, schrieb Russel Winder: On Sat, 2012-12-22 at 01:10 -0800, Jonathan M Davis wrote: [âŠ] It sounds like no one even has a clue which project the bug is in. It's clearly a major problem, but unless someone can figure out what's wrong, it's obviously not going to be fixed. Someone analysed this for a couple of days after the report was put in and came up with some hypotheses, I guess the record is in the mail list archive. There was another flurry of activity when I raised whether this was going to be fixed a few weeks later, and Walter said put in a bug report, but I already had. End of activity. Which is a bit strange for such a serious regression. LDC works fine so I just don't use DMD. Simple workaround :-) so first you need to update your bug-report - you stated that ldc is also not working - thats a bug in you bug report :)
Re: User Defined Attributes
Am 06.11.2012 18:32, schrieb David Nadlinger: On Tuesday, 6 November 2012 at 17:00:27 UTC, Walter Bright wrote: Ok, I ask again, what use case for a UDA is there for function parameters? (Note that IDL isn't it, as D already has enough parameter attributes to support IDL.) What »IDL« are you referring to here? At least as far as I am aware, IDL usually just refers to an »interface definition language« in general, so I'm not quite sure what you mean if you are talking about »enough to support IDL«. Actually, the Thrift IDL would be a perfect example of how attributes on parameters can be useful. A simple service definition in a .thrift could look like this: http://svn.apache.org/repos/asf/thrift/trunk/tutorial/tutorial.thrift
Re: User Defined Attributes
Am 06.11.2012 18:17, schrieb Walter Bright:> On 11/6/2012 9:06 AM, deadalnix wrote:> Le 06/11/2012 16:15, Walter Bright a écrit : > >> On 11/6/2012 5:14 AM, Adam D. Ruppe wrote: > >>> Hmmm, it didn't work on the most important place for my use case, > >>> function > >>> parameters: > >> > >> It didn't occur to me to enable that. > >> > > > > It should work everywhere or not work at all. > > You can't have @pure attributes on function parameters, either. Parameters don't > work like regular declarations, never have, and I don't know of a language where > they do. They even have a different grammar. > but why should an UDA only extend the semantic of regular declarations? can't you please give us a bad-usage example why it is/should be forbidden to use UDA on parameters (and please - we are not talking about pure, in, out and stuff like that)
Re: User Defined Attributes
Am 06.11.2012 18:32, schrieb David Nadlinger:
On Tuesday, 6 November 2012 at 17:00:27 UTC, Walter Bright wrote:
Ok, I ask again, what use case for a UDA is there for function
parameters? (Note that IDL isn't it, as D already has enough
parameter attributes to support IDL.)
What »IDL« are you referring to here? At least as far as I am
aware, IDL usually just refers to an »interface definition
language« in general, so I'm not quite sure what you mean if you
are talking about »enough to support IDL«.
Actually, the Thrift IDL would be a perfect example of how
attributes on parameters can be useful. A simple service
definition in a .thrift could look like this:
---
service Calculator {
i32 calculate(1:i32 a, 2:i32 b, 3:Op op)
}
perfect example - thx alot
Re: User Defined Attributes
Am 06.11.2012 18:14, schrieb Walter Bright:> On 11/6/2012 9:00 AM, dennis luehring wrote: >> 1. what if my needs are beyond D? >> >> for example my idl allows me to define a type based query source for parameters >> >> CalculateStuff( TypeX [source="\\placement\(typeA|typeB|typeC)"] my_usage ) >> >> this defines the source of assignable objects to this method > > Has this capability ever been used? all the while - the complete object-to-object lifecycle of composits etc. is managed by this - no coded object creation is happening its partially based on the naked object pattern the next step will be a complete managed(and hopefully more efficient) loading/locking strategy - but still in around 800k lines of C++ :(
Re: User Defined Attributes
Am 06.11.2012 17:50, schrieb Walter Bright:
On 11/6/2012 8:42 AM, dennis luehring wrote:
Am 06.11.2012 16:18, schrieb Walter Bright:> On 11/6/2012 6:30 AM, dennis
luehring wrote:
> > Am 06.11.2012 14:14, schrieb Adam D. Ruppe:
> >> On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright wrote:
> >>> User Defined Attributes (UDA) are compile time expressions that
> >>> can be attached to a declaration.
> >>
> >> Hmmm, it didn't work on the most important place for my use case,
> >> function parameters:
> >>
> >> void a(["test"] int foo) {
> >> pragma(msg, __traits(getAttributes, foo));
> >> }
> >
> > sad - but its still very young feature :)
> >
> > im using something like an description on my methods to describe
parameter
> > "features" for an resource manager - something like "read", "write",
"copy",
> > "read_write" etc.
> But there's already out=write, read=all of them, read_write=ref, copy=not a
ref
> or an out.
and now expand that to an higher level manager that use such information for
implementing(generating) runtime loading and locking strategies in a tree/graph
based environment - based on the parameters needs ... i've got something like
that in C++ using its own interface description language and an generator
But D already has parameter attributes that cover those bases. What would UDAs
add to that? (I know C++ is deficient in this, which is why IDL was invented,
but I don't see what UDAs add to what D already provides - no IDL is needed for
D).
just 2 questions:
1. what if my needs are beyond D?
for example my idl allows me to define a type based query source for
parameters
CalculateStuff( TypeX [source="\\placement\(typeA|typeB|typeC)"] my_usage )
this defines the source of assignable objects to this method
2. what is the reason for stopping right before parameters? (except less
coding on your side)
Re: User Defined Attributes
Am 06.11.2012 16:18, schrieb Walter Bright:> On 11/6/2012 6:30 AM,
dennis luehring wrote:
> > Am 06.11.2012 14:14, schrieb Adam D. Ruppe:
> >> On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright wrote:
> >>> User Defined Attributes (UDA) are compile time expressions that
> >>> can be attached to a declaration.
> >>
> >> Hmmm, it didn't work on the most important place for my use case,
> >> function parameters:
> >>
> >> void a(["test"] int foo) {
> >> pragma(msg, __traits(getAttributes, foo));
> >> }
> >
> > sad - but its still very young feature :)
> >
> > im using something like an description on my methods to describe
parameter
> > "features" for an resource manager - something like "read",
"write", "copy",
> > "read_write" etc.
> But there's already out=write, read=all of them, read_write=ref,
copy=not a ref
> or an out.
and now expand that to an higher level manager that use such information
for implementing(generating) runtime loading and locking strategies in a
tree/graph based environment - based on the parameters needs ... i've
got something like that in C++ using its own interface description
language and an generator
>
> I don't know what use UDAs would be for parameters.
>
exact the same as for every other symbol - it enriches the semantic
meaning of that symbol :)
Re: User Defined Attributes
Am 06.11.2012 14:14, schrieb Adam D. Ruppe:
On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright wrote:
User Defined Attributes (UDA) are compile time expressions that
can be attached to a declaration.
Hmmm, it didn't work on the most important place for my use case,
function parameters:
void a(["test"] int foo) {
pragma(msg, __traits(getAttributes, foo));
}
sad - but its still very young feature :)
im using something like an description on my methods to describe
parameter "features" for an resource manager - something like "read",
"write", "copy", "read_write" etc.
to have this at compiletime available by using UDAs on parameters + an
compiletime generator would be absolutely briliant
my vote +1 for UDAs on parameters
Re: User Defined Attributes
Am 06.11.2012 10:04, schrieb Jakob Ovrum: On Tuesday, 6 November 2012 at 09:03:49 UTC, dennis luehring wrote: you're just to deep catched in the .Net-Everything-Is-Done-In-Runtime-Paradigm - thats all :) No. ok not you - but many others
Re: User Defined Attributes
Am 06.11.2012 09:49, schrieb Jakob Ovrum: But, I yield until someone comes up with actual examples of how these UDAs are useful, because I can't think of anything interesting at the moment. I guess I should go read over the old discussions you linked (I remember participating, but can't remember any specifics). you're just to deep catched in the .Net-Everything-Is-Done-In-Runtime-Paradigm - thats all :) most of the stuff .Net does in runtime is not absolutely needed at runtime - but they need to because there is no compiletime reflection system available at all - and that trains developer to always thing in runtime-aspects - always
Re: NaNs Just Don't Get No Respect
Am 19.08.2012 06:12, schrieb Jonathan M Davis: On Friday, August 17, 2012 17:03:13 Walter Bright wrote: Our discussion on this in the last few days inspired me to write a blog post about it: http://www.reddit.com/r/programming/comments/yehz4/nans_just_dont_get_no_res pect/ http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723 FWIW, I'm very surprised by how negatively many programmers seem to react to NaN. I think that how D handles it is great. i think many of these programmers seems to think that D is introducing this NaN-Type ...
Re: Uniform Function Call Syntax in D - GameDev.net
Am 02.07.2012 07:13, schrieb Jonathan M Davis: On Monday, July 02, 2012 07:00:23 dennis luehring wrote: Am 01.07.2012 23:02, schrieb Walter Bright: > On 7/1/2012 11:53 AM, Nick Sabalausky wrote: >> That successfully compiles and prints "Member". Same thing happens if >> you move the UFCS func and Foo definition out into their own separate >> modules. But I was expecting a conflict error at compile-time. Is this >> a bug? > > No, it's correct behavior. A real member overrides. isn't that some sort of highjacking then? More like it avoids hijacking. It stops you from creating a function which is used instead of the one which is on the class or struct. Granted, this does mean that you could be surprised about your external function not being called, and adding a new member function could cause your existing external function to no longer be called (which could be a problem), but realistically there's no other way to handle the situation. It's possible to explicitly give a path to the free function (e.g. path.to.function), but there's no way to do that for a member function, since there's only one way to call it. So, if you were forced to disambiguate, you could never indicate anything else other than the free function - not without introducing a new syntax to indicate the member function. - Jonathan M Davis but the compiler selects the member-functions silently - thats odd, ok i will see it very fast - but then i need to change my code anyway - so whats the reason for the silent "overwrite"?
Re: Uniform Function Call Syntax in D - GameDev.net
Am 01.07.2012 23:02, schrieb Walter Bright: On 7/1/2012 11:53 AM, Nick Sabalausky wrote: That successfully compiles and prints "Member". Same thing happens if you move the UFCS func and Foo definition out into their own separate modules. But I was expecting a conflict error at compile-time. Is this a bug? No, it's correct behavior. A real member overrides. isn't that some sort of highjacking then?
Re: DCT: D compiler as a collection of libraries
Am 11.05.2012 13:50, schrieb Ary Manzana: On 5/11/12 4:22 PM, Roman D. Boiko wrote: What about line and column information? Indices of the first code unit of each line are stored inside lexer and a function will compute Location (line number, column number, file specification) for any index. This way size of Token instance is reduced to the minimum. It is assumed that Location can be computed on demand, and is not needed frequently. So column is calculated by reverse walk till previous end of line, etc. Locations will possible to calculate both taking into account special token sequences (e.g., #line 3 "ab/c.d"), or discarding them. But then how do you do to efficiently (if reverse walk is any efficient) compute line numbers? Usually tokens are used and discarded. I mean, somebody that uses the lexer asks tokens, process them (for example to highlight code or to build an AST) and then discards them. So you can reuse the same Token instance. If you want to peek the next token, or have a buffer of token, you can use a freelist ( http://dlang.org/memory.html#freelists , one of the many nice things I learned by looking at DMD's source code ). So adding line and column information is not like wasting a lot of memory: just 8 bytes more for each token in the freelist. it would be better to add something like an ColumnLine-collector-thing - that if applied is able to hold this information, so no waste if its not needed i think there are several parts that can work like that
Re: DCT: D compiler as a collection of libraries
Am 11.05.2012 11:33, schrieb Roman D. Boiko: -very fast in parsing/lexing - there need to be a benchmark enviroment from the very start Will add that to May roadmap. are using slices for prevent coping everything around? the parser/lexer need to be as fast as the original one - maybe even faster - else it won't replace walters at any time - because speed does matter here very much
Re: DCT: D compiler as a collection of libraries
Am 11.05.2012 11:23, schrieb Roman D. Boiko: On Friday, 11 May 2012 at 09:19:07 UTC, dennis luehring wrote: does the parser/lexer allow half-finished syntax parsing? for being useable in an IDE for syntax-highlighting while coding? That's planned, but I would like to see your usage scenarios (pseudo-code would help a lot). try to syntaxhiglight while coding - thats the scenario, parts of the source code isn't fully valid while writing
Re: DCT: D compiler as a collection of libraries
Am 11.05.2012 11:02, schrieb Jacob Carlborg: For this to happen, for Walter to start using this, I think there would be a greater change if the frontend was a port of the DMD frontend and not changed too much. or a pure D version of it with the features: -very fast in parsing/lexing - there need to be a benchmark enviroment from the very start -easy to extend and fix and think that is what walter wants from an D-ish frontend in the first place
Re: DCT: D compiler as a collection of libraries
Am 11.05.2012 10:01, schrieb Roman D. Boiko: There were several discussions about the need for a D compiler library. I propose my draft implementation of lexer for community review: https://github.com/roman-d-boiko/dct Lexer is based on Brian Schott's project https://github.com/Hackerpilot/Dscanner, but it has been refactored and extended (and more changes are on the way). The goal is to have source code loading, lexer, parser and semantic analysis available as parts of Phobos. These libraries should be designed to be usable in multiple scenarios (e.g., refactoring, code analysis, etc.). My commitment is to have at least front end built this year (and conforming to the D2 specification unless explicitly stated otherwise for some particular aspect). Please post any feed here. A dedicated project web-site will be created later. does the parser/lexer allow half-finished syntax parsing? for being useable in an IDE for syntax-highlighting while coding?
Re: unzip parallel, 3x faster than 7zip
Am 06.04.2012 01:53, schrieb Jay Norwood: I'm curious why win7 is such a dog when removing directories. I see a lot of disk read activity going on which seems to dominate the delete time. try windows safe-mode (without network :} - your virus scanner is disabled), press F8 before windows start - thats seems to remove many strange pauses,blockings etc. - still no idea why, but a good testenvironment
Re: unzip parallel, 3x faster than 7zip
Am 05.04.2012 19:04, schrieb Timon Gehr: On 04/05/2012 06:37 PM, dennis luehring wrote: Am 05.04.2012 16:04, schrieb Jay Norwood: I uploaded a parallel unzip here, and the main in the examples folder. Testing on my ssd drive, unzips a 2GB directory structure in 17.5 secs. 7zip took 55 secs on the same file. it makes no sense to benchmark different algorithm zip<->7zip compare only unzip and parallel unzip - nothing else makes sense I think he is talking about 7zip the standalone software, not 7zip the compression algorithm. 7zip took 55 secs _on the same file_. that is ok but he still compares different implementations
Re: unzip parallel, 3x faster than 7zip
Am 05.04.2012 16:04, schrieb Jay Norwood: I uploaded a parallel unzip here, and the main in the examples folder. Testing on my ssd drive, unzips a 2GB directory structure in 17.5 secs. 7zip took 55 secs on the same file. it makes no sense to benchmark different algorithm zip<->7zip compare only unzip and parallel unzip - nothing else makes sense
Re: UFCS for D
or just use http://cdburnerxp.se/ Am 30.03.2012 10:30, schrieb Nick Sabalausky: "Walter Bright" wrote in message news:jl3l0c$jn2$1...@digitalmars.com... On 3/29/2012 7:05 PM, Nick Sabalausky wrote: I don't understand why people think it's ok for basic, basic shit that would have ran fine on a Pentium 1 (and less) to now require what quite literally is a super-fucking-computer-on-the-desktop just to run acceptably. Seriously, what the fuck's the point of buying all this insanely powerful hardware if software just turns the damn thing right back into a fucking single-core P1? That's just insane. People are seriously fucking bat-shit crazy. I'm in complete agreement with you. It's like when I bought a new dvd burner, and had to upgrade Nero Burning to deal with it. The old Nero was 6Mb, the new one was 90Mb (!) Yea, needing to upgrade Nero bugged me too. And even ignoring filesize, each new version of Nero kept getting worse anyway (the original was actually pretty good, but they quickly put a stop to that). I just use ImgBurn/DVD Decryptor/DVD Shrink for ripping/burning ISOs and InfraRecorder for everything else. They're s much better than *any* commercial package I've seen in at least ten years. They do the job, do it well, and all with *no* bullshit/bloat/skins or any other such crap.
Re: parallel copy directory, faster than robocopy
Am 14.02.2012 05:58, schrieb Jay Norwood: Attached is the source for a small parallel app that copies a source folder to a destination. It creates the directory structure first using the breadth ordering, then uses a parallel foreach loop with the taskPool to copy all the regular files in parallel. On my corei7, this copied a 1.5GB folder with around 36K entries to a destination in about 11.5 secs (src and dest on the same ssd drive). This was about a second better than robocopy, which is the fastest alternative I could find. The regular win7-64 copy takes 41 secs for the same folder. I'd like to add wildcard processing for the sources, but haven't found a good example. do you compare single-threaded robocopy with your implementation or multithreaded? you can command robocopy to use multiple threads with /MT[:n]
Re: Mozilla Rust 0.1
Am 24.01.2012 10:40, schrieb Walter Bright: On 1/23/2012 11:50 PM, dennis luehring wrote: The Rust compiler 0.1 is unleashed http://www.reddit.com/r/programming/comments/opgxd/mozilla_and_the_rust_community_release_rust_01_a/ looks nice - but rusts #fmt macro is nothing compared to std.metastrings and is not even library based :) It's hard to find any definitive information, but Rust appears to have no exception handling and no generics. generics like are here described http://doc.rust-lang.org/doc/tutorial.html#generics but for exceptions they only got the fail()-thing http://doc.rust-lang.org/doc/tutorial.html#failure
Mozilla Rust 0.1
The Rust compiler 0.1 is unleashed http://www.reddit.com/r/programming/comments/opgxd/mozilla_and_the_rust_community_release_rust_01_a/ looks nice - but rusts #fmt macro is nothing compared to std.metastrings and is not even library based :)
Re: A tutorial on D templates
https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf can't open the pdf with acrobat reader under win7 :( (the file seems to be ok, contains the pdf header) im using the latest acrobat reader x
Re: Visual D 0.3.24 released
Am 09.05.2011 15:56, schrieb Michal Minich: V Sun, 08 May 2011 11:31:29 +0200, Rainer Schuetze wrote: as the newest version of Visual D includes some major improvements, I'd like to announce its release here. Many thanks for the great work you put into this IDE. Since I switched to it from Descent, it is great productivity booster for me. The debugger support is fantastic. One improvement I would welcome - is project manager that automatically matches file system structure and allows to inc/exclude specific files and folders - similarly as in C#. i still hope that Rainer getting interested in Descent like features - especially the compile-time debugging...
IDA Pro 6.1 got D support
http://hex-rays.com/idapro/61/index.html + FLIRT: added autodetection of the programs written in the D language + FLIRT: added Digital Mars FLIRT signatures
Re: Mustache template engine
Am 25.02.2011 15:26, schrieb Masahiro Nakagawa: the old days (of D)? A year and a half. code available? why the switch to pure runtime based? When CMS using compile-time template exists, how does user update template file? ok but when used as (for example) debugging help is no need for runtime loading, for example i use templates likes this for graph debugging - but it would be nice to reduce the runtime loading (even my large string) to compile-time :)
Re: Mustache template engine
In the old days, I implemented the compile-time template engine using similar approch :) the old days (of D)? - why the switch to pure runtime based?
Re: Mustache template engine
Am 25.02.2011 09:29, schrieb dennis luehring:
would be great to have this available at compiletime
better said - an at compiletime generated render-code - would be
blasting fast because of just combining the template-chunks inside of an
huge write - or every type of section
so something like this:
--- basic.mustache ---
Hello {{name:%s}}
You have just won ${{value:%i}}!
{{#in_ca}}
Well, ${{taxed_value:%f}}, after taxes.
{{/in_ca}}
---
would be mixined/compiled to something like:
class TemplateEngine
{
mixin( generate template-members/sections/renderer) )
//section:main
struct main: section
--> string name
--> int value
--> string mixined_renderer()
{
auto writer = appender!string();
formattedWrite(writer, "Hello %s\nYou have just won
$%i!\n%s",name,value,section_in_ca.mixined_renderere());
return writer.data;
}
//struct section_in_ca: sections
--> in_ca [] blocks;
string mixined_renderer()
{
string tmp;
foreach( block blocks )
{
tmp ~= block.mixined_renderer();
}
return tmp;
}
//section:in_ca
struct in_ca
--> float taxted_value
--> mixined_renderer
void mixined_renderer( _writer )
{
auto writer = appender!string();
formattedWrite(writer, "Well, $%f, after taxes.\n",taxed_value);
return writer.data;
}
//.in_ca.create add new in_ca section to the section_in_ca.blocks
// and section can have inner sections etc
string render()
{
return main.mixined_renderer();
}
}
and if its runned to the end you can even check if inputs are const and
remove completely the depending code... the idea is to generated to
"write"-code as compact as possible
Re: Mustache template engine
Am 24.02.2011 18:57, schrieb Masahiro Nakagawa:
3 weeks ago, I discussed template engine with Goro Fuji(a.k.a Xslate
author).
In the process, I noticed D does not have template engine library.
So I wrote the D version of Mustache.
https://bitbucket.org/repeatedly/mustache4d/src
would be great to have this available at compiletime - something like an
write(ln) with typeckecks and block functionality :)
with a nice inner mixin that generates an frontend for the template-vars
a little bit like the
http://www.digitalmars.com/d/2.0/phobos/std_bitmanip.html bitfield! template
example-style refering to your basic.d example
--- basic.mustache ---
Hello {{name:%s}}
You have just won ${{value:%i}}!
{{#in_ca}}
Well, ${{taxed_value:%f}}, after taxes.
{{/in_ca}}
---
alias MustacheEngine!(string,import("basic.mustache")) My_Special_Template;
void main()
{
My_Special_Template my_special_template;
my_special_template.name = "Chris";
my_special_template.value = 1;
auto in_ca_section = my_special_template.in_ca.create();
in_ca_section.taxted_value = 1 - (1 * 0.4);
write(my_special_template.render());
}
Re: Optlink 8.00.10
Am 23.02.2011 01:52, schrieb Walter Bright: This fixes a couple of crashers, 2436 and 3372, that were causing people lots of trouble: http://ftp.digitalmars.com/link.8.00.10.zip can you please update the dmd1/dmd2 packages with this version current dmd2.052 seems to be still using 8.00.8
Re: New web newsreader - requesting participation
Am 01.02.2011 14:42, schrieb Adam Ruppe: Trass3r Wrote: Speaking of newsgroup web interface, interestingly while the main D site points to this crappy reader: http://www.digitalmars.com/pnews/indexing.php?server=news.digitalmars.com&group=digitalmars.D.announce there still is a hidden one which is much better imho: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce Wow, this one is a lot better than the other one! And it's proper name is "Web-News". Now I feel bad for calling the other one web news, it's like slandering this much better program. I still think we can do better though! but wouldn't it be better to use the newer frontend now and switch then - after your development is finished (i mean the feature stable release, not the very first alpha) to your implementation...
Re: New web newsreader - requesting participation
Am 01.02.2011 09:37, schrieb Trass3r: Speaking of newsgroup web interface, interestingly while the main D site points to this crappy reader: http://www.digitalmars.com/pnews/indexing.php?server=news.digitalmars.com&group=digitalmars.D.announce there still is a hidden one which is much better imho: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce and there is the updated 1.6.4 version whichs looks a little more better http://sourceforge.net/projects/web-news/ why don't use this one and style it like the D main page?
Re: data.d
Yea, but I wonder how much longer it is going to be before 32-bit is dead as a dodo except on things like netbooks. it "consumes" (leaves holes useable by others) to much memory because of the allocation strategie - that is also a problem under 64bit
Re: Bug fix week
Am 24.05.2010 16:08, schrieb Don: > 4056 Template instantiation with bare parameter not documented why don't remove this feature? it isn't syntactic sugar just an "alternative" syntax (how many other alternative syntaxes needed?)
Re: dmd 1.059 and 2.044 release
Am 03.05.2010 01:29, schrieb Bernard Helyer: On 03/05/10 09:28, Walter Bright wrote: Highlights are the improved gdb support, better error messages, better json support, unittest changes, and a number of nuisance compiler bugs fixed. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.059.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.044.zip Thanks to the many people who contributed to this update! Unfortunately, GDB still doesn't work with it over here. Robert is going to try one of my test cases and see what he can see. some got an D able GDB version for windows around?
Re: Visual D released
I installed it, but it won't load the Visual D package. Too bad... i've read the following on the http://www.jcxsoftware.com/ php-ide plugin extension page "... The express edition has limited functionality but one of its biggest limitations is that you can not load third party plug-ins like VS.Php. Lukily enough, VS.Php comes with its own copy of the Visual Studio shell in case you don't own Visual Studio Professional..." so it seems that there is an solution available
Re: Visual D released
Also, the VS2010 Express versions are not out yet not fully correct http://www.microsoft.com/express/downloads/#Visual_Studio_2010_Express_Downloads >..., let's hope for some > policy change from Microsoft. i hope
Re: dmd 1.058 and 2.043 release
What's the rationale behind this? (I don't like this). The flexibility comes in handy now and then. but isn't that an abstract form of hijacking then? or an sideeffect smelling like that?
Re: Taunting
Ary Borenszweig schrieb: Daniel Keep wrote: grauzone wrote: BCS wrote: Reply to Ary, http://www.youtube.com/watch?v=rtYCFVPfx4M The clunk you just heard is my jaw bouncing on the floor NICE! It would be very nice to have such a debugging feature. Too bad it's hardcoded into a very bug GUI system. Yes, heaven forbid Ary spends his time adding and improving features when he should be building a new editor from the ground up. In all seriousness, I hate IDEs because they are big, slow, and waste vast tracts of prime monitor space. But I'm willing to put up with that for Descent's compile-time view and (hopefully soon) compile-time debugging. If I could get that in a super fast, light programming editor, I'd use that instead. But I can't. Although it is annoying when I'm out and about on my little netbook and can't use Eclipse. C'est la vie. Another problem with Descent is that it's kind of buggy (yes, I know it). But most of the bugs are because of errors in the semantic analysis ported from DMD's front end. So, for example, some template instantiations fail when they shouldn't. maybe we should think about extending dmd itselfe to give you and runtime interface to the compile which can be used for features like that - any ideas?
Re: Open source dmd on Reddit!
Sure, they're open to _severe_ abuse, but for the case when they are used to generate source code (eg, from a DSL), they are absolutely perfect, and not a hack at all. In that particular scenario, they are much better than AST macros could ever be. They're a replacement for creating a text file, adding a line to your makefile in order to invoke a program to read the text file and spit out a d source file, then add another line in the makefile to compile that d file, then link it in, and try to integrate the whole thing seamlessly. They're a beautiful solution to a really ugly problem. It's not fair to regard them simply as a hack to get around language limitations. @Walter - please add this perfect description to the mixin page ;-)
