Re: Need a Faster Compressor
Am Sun, 22 May 2016 13:02:37 -0700 schrieb Walter Bright: > On 5/22/2016 9:06 AM, Marco Leise wrote: > > Are there any objections > > against the benchmarking method or the license? > > BSD may cause problems. > > > Can the implementation be in D? > > Not yet. > > > If not, should we link against the > > system liblz4.so/a > > No. > > > or copy the C code into the backend? > > Yes. Can you elaborate on how copying the source overrules your above license concerns? I would create a directory "lz4" for the sources, compile them like we compile zlib now and install dmd with a backend license stating that it uses lz4 licensed under BSD? > > Is a pre-filled dictionary worthwhile? > > The trouble with that is the demangler would need the same dictionary, right? > If > so, that would be problematic. Right, it's probably more trouble than worth it. -- Marco
A language comparison (seeking productivity-enhancing, well-designed, and concise languages)
Found on Reddit: https://www.reddit.com/r/programming/comments/4kmfp6/the_best_quality_programming_languages/ The list: http://www.slant.co/topics/5984/~productivity-enhancing-well-designed-and-concise-rather-than-popular-or-time-tested-programming-languag Ali
Proper way to write benchmark code...
Is there a good article written for this? Preferably for D specifically... I notice as I'm working a bit with my challenge to make/update the symbol/id compressor that perhaps the GC is getting in the way and skewing the results. Means a number of what I've put up as benchmark values may wildly off. So forgive my ignorance. So first, compiling flags. What should be used? So far -inline -noboundscheck -O -release Flags for a C program (if it comes into play?) I only can see -o -c to be applicable (then link it to your program). How do I work around/with the GC? what code should I use for benchmarks? Currently I'm trying to use the TickDuration via Benchmark, but it isn't exactly an arbitrary unit of time. If benchmark is a bad choice, what's a good one? As for the GC, since it might be running or pause threads in order to run, how do I ensure it's stopped before I do my benchmarks? Here's what I have so far... import core.thread : thread_joinAll; import core.memory; import std.datetime : benchmark; //test functions //actual functions slower than lambdas?? auto f1 = (){}; auto f2 = (){}; int rounds = 100_000; GC.collect(); //GC.reserve(1024*1024*32); //no guarantee of reserves. So would this help? thread_joinAll(); //guarentees the GC is done? GC.disable(); //turned off auto test1 = benchmark!(f1)(rounds); GC.collect(); //collect between tests thread_joinAll(); //make sure GC is done? auto test2 = benchmark!(f2)(rounds); //collect, joinall ... //optional cleanup after the fact? Or leave the program to do it after exiting? //GC.enable(); //GC.collect(); Is it better to have a bunch of free memory and ignore leaks? Or to free memory as it's going through for cases that require it? //compress returns memory malloc'd, compiled with DMC and C code. char *compress(cast(char*) ptr, int size); auto f3 = (){ compress(cast(char*) haystack.ptr, haystack.length); //this with leaks? GC.free(compress(cast(char*) haystack.ptr, haystack.length)); //or this? }; Is memory allocated by DMC freed properly by GC.free if I end up using it this way? (For all I know GC.free ignores the pointer). If I do a separate allocations to match what the functions and calls did, can I subtract it to get a cleaner set of statistics? Or is that line of thinking a wrong? auto f3_mm = (){ void *ptr = GC.malloc(1024); GC.free(ptr); }; auto test2 = benchmark!(f3, f3_mm)(rounds); //f3-f3_mm = delta? For the functions/lambdas passed to benchmark, is it better to provide all the information in the function and not have data stored elsewhere? Or store it all as a pure function? Does the overhead of the extra stack pointer make any difference? Is it better to collect all the tests and output the results all at once? Or is it okay or better to output the statistics as they are finished (between benchmarks and before the collection/thread_joinall calls)? What other things should I do/consider when writing basic benchmark code?
Re: Is there a way to make a class variable visible but constant to outsiders, but changeable (mutable) to the class itself?
On Sunday, 22 May 2016 at 19:29:59 UTC, Meta wrote: Const *is* necessary to prevent _myVar being written to through code like: f.myVar = 4; Of course this isn't necessary for value types, but for reference types. I was referring specifically to marking the function const, not the return type. Marking the return type const is highly context-dependent. It's perfectly reasonable to return a non-const class reference from a getter property. As long as the internal reference is private, it isn't going to be overwritten externally without a setter property. I don't see how it could be considered necessary. For a pointer, sure, to prevent *(bar.fooVer) = Foo(10). But for class references it's only necessary if you don't want the returned instances members to be modified. It's also useful for value types, IMO, for preventing someone from doing this: f.myVar = 4; And wondering why the code has no effect. The compiler already gives an error message describing the problem: Error: function mod.Foo.myVar () is not callable using argument types (int) How does const help here?
[Issue 16063] DLL projects seem to ignore DllMain, won't link
https://issues.dlang.org/show_bug.cgi?id=16063 --- Comment #1 from Manu--- Seems that it expects '/DLL' given to the linker, but it's not. I added -L/DLL to additional options and it links. This should probably be there automatically. --
Re: Is there a way to clear an OutBuffer?
On Sunday, 22 May 2016 at 23:01:07 UTC, Ali Çehreli wrote: On 05/22/2016 11:59 AM, Jon Degenhardt wrote: Is there a way to clear an OutBuffer, but without freeing the internally managed buffer? Something similar to std.array.appender.clear method. Intent would be to reuse the OutBuffer, but without reallocating memory for the buffer. --Jon Currently not possible. Enhancement request perhaps? Looking at the implementation, setting its 'offset' member seems to work. Based on example from documentation: import std.outbuffer; void main() { OutBuffer b = new OutBuffer(); b.writefln("a%sb", 16); assert(b.toString() == "a16b\n"); b.offset = 0; b.writefln("a%sb", 16); assert(b.toString() == "a16b\n"); } Bug report perhaps? :) Ali Thanks. Enhancement request: https://issues.dlang.org/show_bug.cgi?id=16062
[Issue 16063] New: DLL projects seem to ignore DllMain, won't link
https://issues.dlang.org/show_bug.cgi?id=16063 Issue ID: 16063 Summary: DLL projects seem to ignore DllMain, won't link Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: normal Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com I create a DLL project: Properties -> General -> Output Type = DLL, Subsystem = Windows I get the error when linking: error LNK2019: unresolved external symbol WinMain referenced in function "int __cdecl invoke_main(void)" (?invoke_main@@YAHXZ) Seems to want WinMain, even though it's a DLL. If I change 'Subsystem' to 'Not Set', it complains that main() is missing instead. --
[Issue 16062] New: Add 'clear' method to OutBuffer (std.outbuffer)
https://issues.dlang.org/show_bug.cgi?id=16062 Issue ID: 16062 Summary: Add 'clear' method to OutBuffer (std.outbuffer) Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: jrdemail2000-dl...@yahoo.com Enhancement request: Add an API to OutBuffer (std.outbuffer) to clear the data in an OutBuffer. The intent is to reuse the OutBuffer, but without reallocating the memory for the internally managed buffer. This would be similar to std.array.appender.clear method. It appear that this could be done by setting the 'offset' member of the OutBuffer to zero. If this works correctly, a clear API could be exposed that implements this. A forum thread on this topic: https://forum.dlang.org/thread/bbjgfradpwqaelaru...@forum.dlang.org --
Re: Hide input string from stdin
On Sunday, 22 May 2016 at 22:38:46 UTC, Michael Chen wrote: I tried to write a small program that receive string as password. However, I didn't find available library for hide input string, even in core library. Any suggestion? Hmmm if you don't mind flooding the console (with either a pattern or spaces or newlines), you could spawn a separate thread to spam the console until it gets the flag to quit... Certainly not the best idea, but it would work... (Probably).
Re: Need a Faster Compressor
On Sunday, 22 May 2016 at 19:44:08 UTC, Era Scarecrow wrote: ... Well here's the rundown of some numbers. min_compress uses a tiny window, big_compress was my original algorithmn but modified to use 16k total for a window. reduced_id_compress is the original except reduced to a 220 window and 2 byte constant output. Along with the compressed outputs of each. min_compress: [TickDuration(46410084)] 0.779836 big_compress: [TickDuration(47998202)] 0.806545 orig_id_compress: [TickDuration(59519257)] baseline reduced_id_compress:[TickDuration(44033192)] 0.739894 1001 (original size) 72 testexpansion.s!(æεó▌æ╗int).så°Resulà≡Ñ╪¢╨╘ÿ¼É ↑─↑╜►╘fñv├ÿ╜ ↑│↑Ä .foo() 73 testexpansion.s!(ÅæεÅó▌Åæ╗int).sÅå°ResulÅà≡ÅÑ╪Å¢╨Å╘ÿżÉ₧├ÿÄ╜É╝▓ÿëåâ.foo() 67 tes╤xpansion.s!(ÇææÇóóÇææint)∙⌡ResulÇàÅÇѺǢ»Ç╘τǼ∩ë├τü╜∩¢▓τ².foo() 78 testexpansion.s!(æ2óCæ2int).så(Resulà0ÑH¢P╘ê¼É╘íñÖ├ê┤ÿσ║ñ¬├ê¼É╘íñÖ├êÉ1å).foo() min_compress: [TickDuration(29210832)] 0.82391 big_compress: [TickDuration(31058664)] 0.87601 orig_id_compress: [TickDuration(35466130)] baseline reduced_id_compress:[TickDuration(25032532)] 0.705977 629 (original size) 52 E.s!(à·è⌡àδint).så°Resulà≡ÖΣÅ▄╝╝ö┤ líd _Ög læ◄.foo() 61 E.s!(Åà·Åè⌡Åàδint).sÅå°ResulÅà≡ÅÖΣÅÅ▄Å╝╝Åö┤₧ç∞ÄÖΣ¡ó╠ïå╗.foo() 52 E.s!(ΣÇèèΣint)∙⌡ResulÇàÅÇÖ¢ÇÅúÇ╝├Çö╦ëçôüÖ¢Æó│².foo() 52 E.s!(à&è+à).så(Resulà0Ö<ÅD╝döl ┤í╝ ┴Ö╣ ┤æ9.foo()
Re: [OT] On Giving Presentations
On 5/22/2016 1:50 PM, Joakim wrote: Did you mean to link to the first point? http://alumni.media.mit.edu/~cahn/life/gian-carlo-rota-10-lessons.html#lecturing yes
[Issue 16061] New: 2.071.1-b1 regression -- Works with 2.071
https://issues.dlang.org/show_bug.cgi?id=16061 Issue ID: 16061 Summary: 2.071.1-b1 regression -- Works with 2.071 Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: regression Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: pun...@coverify.org $ dmd -c foo.d Fails with 2.071.1-b1 with error: bar.d(3): Error: T.Zoo is not a template, it is a overloadset bar.d(8): Error: template instance bar.Boo!(Foo) error instantiating foo.d(3): Error: mixin foo.Foo.Bar!() error instantiating // file foo.d class Foo { import bar; mixin Bar; } // file bar.d class Zoo(V) {} template Boo(T) { alias Boo = T.Zoo!T; } mixin template Bar() { class Zoo(V) {} alias U = typeof(this); alias BooThis = Boo!U; } --
[Issue 16060] New: extern(C++) abstract base class and interface
https://issues.dlang.org/show_bug.cgi?id=16060 Issue ID: 16060 Summary: extern(C++) abstract base class and interface Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com In this case, we have an example of single-inheritance in C++, but D treats this construct as multiple-inheritance, and the struct's don't match. C++: #include class I { public: virtual void f1() = 0; virtual float f2() = 0; }; class Test : public I { public: int t; Test(int t) : t(t) {} }; class Blah : public Test { public: Blah() : Test(0xbaadf00d) {} void f1() {} float f2() { return 10.f; } }; extern "C" { I* test() { return new Blah; } Test* test2() { return new Blah; } } D: -- import std.stdio; extern (C++) interface I { void f1(); float f2(); } extern (C++) abstract class Test : I { int t; } extern (C) I test(); extern (C) Test test2(); int main(string[] argv) { auto i = test(); i.f1(); auto j = test2(); float f = j.f2(); // CRASH! looks up vtable address: [i + 8], expect: vtable at [i] writeln("Hello D-World! ", f); return 0; } --
[Issue 16059] New: needed better error messages for failed overloads
https://issues.dlang.org/show_bug.cgi?id=16059 Issue ID: 16059 Summary: needed better error messages for failed overloads Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: poliklosio.dl...@gmail.com I think I may have an idea for a usable solution to improve error messages. Example of an error I got from dmd: C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(298,24): Error: template std.conv.toImpl cannot deduce function from argument types !(ubyte[])(RangeT!(Array!ubyte)), candidates are: C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(364,3): std.conv.toImpl(T, S)(S value) if (isImplicitlyConvertible!(S, T) && !isEnumStrToStr!(S, T) && !isNullToStr!(S, T)) C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(478,3): std.conv.toImpl(T, S)(ref S s) if (isRawStaticArray!S) C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(494,3): std.conv.toImpl(T, S)(S value) if (!isImplicitlyConvertible!(S, T) && is(typeof(S.init.opCast!T()) : T) && !isExactSomeString!T && !is(typeof(T(value C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(545,3): std.conv.toImpl(T, S)(S value) if (!isImplicitlyConvertible!(S, T) && is(T == struct) && is(typeof(T(value C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(594,3): std.conv.toImpl(T, S)(S value) if (!isImplicitlyConvertible!(S, T) && is(T == class) && is(typeof(new T(value C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(298,24):... (9 more, -v to show) ... src\app.d(36,36): Error: template instance std.conv.to!(ubyte[]).to!(RangeT!(Array!ubyte)) error instantiating dmd failed with exit code 1. There are multiple problems with this error message: - The information that the source of the problem was the call to a "to" function is not at the top. - It is missing some very important information, in particular the general idea of what types are accepted by the "to" function. It only shows the way the constrains are *implemented*, it doesn't tell directly what the author wanted to achieve. When one writes 20 overloads, its usually because there is some commmon property among the accepted types which cannot be easily expressed with the type system. - It doesn't show any useful speculation as to what mith be the cause of the error in this particular use case. There was a forum thread started by Andrei about other improvements to messages already: http://forum.dlang.org/post/nfllhq$19tk$1...@digitalmars.com but it was focused on generating better messages from the constraints themselves, which is, IMHO, an inferior solution if not a lost cause. I would like to propose another solution which may improve experience regardless of the number of overloads, architecture of constrains and all the other technical issues, by laveraging the expressive power of English language. If the library writer could write something like this (example for the std.conv.to case): pragma(on_overload_resolution_error, "toImpl", " You used the \"to\" function incorrectly which failed at the point of toImpl template instantiation. The \"to\" function is meant for simple convertions which typically preserve the converted value, for example from double -> int, or double[] -> int[]. Typical mistakes when calling the \"to\" function involve: Calling on range types rather than arrays... ") This tells the compiler to display the "You used the ..." message at the top of the appropriate error message, in case there is an overload resolution error when using the toImpl function. --
[Issue 16029] D exception aborts program when called from C++
https://issues.dlang.org/show_bug.cgi?id=16029 Adam D. Ruppechanged: What|Removed |Added CC||destructiona...@gmail.com --- Comment #1 from Adam D. Ruppe --- This actually works for me.. what are some other details of your setup? --
[Issue 15547] 64-bit struct alignment in core.sys.windows.setupapi inconsistent with msvc
https://issues.dlang.org/show_bug.cgi?id=15547 j...@red.email.ne.jp changed: What|Removed |Added CC||j...@red.email.ne.jp --- Comment #1 from j...@red.email.ne.jp --- We can get a work around with string mixin( though a bit ugly hack). See my PR for issue 16049. https://github.com/dlang/druntime/pull/1576 (including "Add AlignedStr helper and fix setupapi" ) Otherwise, an old enhancement request of issue 9766 could resolve this simply. --
Re: amoeba, a chess engine written in D
On Sunday, 22 May 2016 at 21:22:30 UTC, Richard Delorme wrote: A question: why singleobj is not activated by a -Ox options? It changes compiler behaviour – only a single object file is produced. Historically, the default behaviour was used by some people/build systems for incremental compilation. However, since incremental compilation only works when exactly the same (sub)sets of commands are invoked every time these days, -singleobj should arguably be on by default, at least when producing an executable. This is actually what ldmd2 does already, but we should probably take the plunge and break backwards compatibility to enable it for the main driver too. I can't think of a scenario where you wouldn't want to be using it. — David
Re: Hide input string from stdin
On Sunday, May 22, 2016 22:38:46 Michael Chen via Digitalmars-d wrote: > I tried to write a small program that receive string as password. > However, I didn't find available library for hide input string, > even in core library. Any suggestion? If you're using *nix, then you can use ncurses. http://code.dlang.org/packages/ncurses e.g. I have this function in one of my programs: string getPassword() { import deimos.ncurses.curses; import std.conv; enum bs = 127; enum enter = 10; initscr(); raw(); noecho(); timeout(-1); scope(exit) endwin(); printw("password: "); refresh(); dchar[] password; while(1) { immutable c = getch(); if(c == enter) break; if(c == bs) { if(!password.empty) { password = password[0 .. $ - 1]; password.assumeSafeAppend(); } } else password ~= c; } return to!string(password); } - Jonathan M Davis
Re: D plugin for Visual Studio Code
On Sunday, 22 May 2016 at 21:33:49 UTC, WebFreak001 wrote: On Sunday, 22 May 2016 at 17:49:08 UTC, poliklosio wrote: Oh, I see. I didn't realize you don't have a Windows machine available. I'll try to build the newest version when I have the time. Its pretty unfortunate that it doesn't work because VSCode is the only editor that has all ticks on this page https://wiki.dlang.org/Editors so people new to D are more likely to try VSCode first (like me), only wasting time if they are on Windows. windows hates me too much, these permission issues don't make any sense. Why wouldn't dub be able to write the lib file to the project directory? Fixing workspace-d-installer is just as important as fixing workspace-d for windows. Also the laptop is so super slow, I think my Windows VM would be faster. Gonna try and fix the issues on there in the next few days. Maybe you are trying to write to the Program Files folder which became unwritable without admin priviledges since approximately Windows 7? Anyway, good luck! I hope you don't give up. For those who wonder what works on Windows, Eclipse + DDT works great for me (specifically Windows 7).
Re: Is there a way to clear an OutBuffer?
On 05/22/2016 11:59 AM, Jon Degenhardt wrote: Is there a way to clear an OutBuffer, but without freeing the internally managed buffer? Something similar to std.array.appender.clear method. Intent would be to reuse the OutBuffer, but without reallocating memory for the buffer. --Jon Currently not possible. Enhancement request perhaps? Looking at the implementation, setting its 'offset' member seems to work. Based on example from documentation: import std.outbuffer; void main() { OutBuffer b = new OutBuffer(); b.writefln("a%sb", 16); assert(b.toString() == "a16b\n"); b.offset = 0; b.writefln("a%sb", 16); assert(b.toString() == "a16b\n"); } Bug report perhaps? :) Ali
Re: DMD producing huge binaries
On Sunday, 22 May 2016 at 21:40:07 UTC, Andrei Alexandrescu wrote: On 05/21/2016 06:27 PM, Anon wrote: On Saturday, 21 May 2016 at 20:50:56 UTC, Walter Bright wrote: On 5/21/2016 1:49 PM, Walter Bright wrote: We already have a compressor in the compiler source for compressing names: https://github.com/dlang/dmd/blob/master/src/backend/compress.c A faster one would certainly be nice. Anyone game? Note how well it does: https://issues.dlang.org/show_bug.cgi?id=15831#c5 The underlying symbols are still growing exponentially. Nobody has the RAM for that, regardless of what size the resultant binary is. Compressing the symbol names is a bandage. The compiler needs a new kidney. My understanding is that the encoding "auto" return in the mangling makes any exponential growth disappear. Is that the case? -- Andrei No: auto foo(T)(T x) { struct Vold { T payload; } return Vold(x); } foo(5) _D3mod10__T3fooTiZ3fooFNaNbNiNfiZS3mod10__T3fooTiZ3fooFiZ4Vold foo(5).foo _D3mod38__T3fooTS3mod10__T3fooTiZ3fooFiZ4VoldZ3fooFNaNbNiNfS3mod10__T3fooTiZ3fooFiZ4VoldZS3mod38__T3fooTS3mod10__T3fooTiZ3fooFiZ4VoldZ3fooFS3mod10__T3fooTiZ3fooFiZ4VoldZ4Vold foo(5).foo.foo _D3mod94__T3fooTS3mod38__T3fooTS3mod10__T3fooTiZ3fooFiZ4VoldZ3fooFS3mod10__T3fooTiZ3fooFiZ4VoldZ4VoldZ3fooFNaNbNiNfS3mod38__T3fooTS3mod10__T3fooTiZ3fooFiZ4VoldZ3fooFS3mod10__T3fooTiZ3fooFiZ4VoldZ4VoldZS3mod94__T3fooTS3mod38__T3fooTS3mod10__T3fooTiZ3fooFiZ4VoldZ3fooFS3mod10__T3fooTiZ3fooFiZ4VoldZ4VoldZ3fooFS3mod38__T3fooTS3mod10__T3fooTiZ3fooFiZ4VoldZ3fooFS3mod10__T3fooTiZ3fooFiZ4VoldZ4VoldZ4Vold Lengths: 62 | 174 | 398 Just dropping the return types to a single character ($) shrinks the names, but it doesn't solve the core of the problem. Still exponential: foo(5) _D3mod1010__T3fooTiZ3fooFNaNbNiNfiZ($) foo(5).foo _D3mod38__T3fooT(S3mod10__T3fooTiZ3fooFiZ4Vold)Z3fooFNaNbNiNf(S3mod10__T3fooTiZ3fooFiZ4Vold)Z{$} foo(5).foo.foo _D3mod94__T3fooT{S3mod38__T3fooT(S3mod10__T3fooTiZ3fooFiZ4Vold)Z3fooF(S3mod10__T3fooTiZ3fooFiZ4Vold)Z4Vold}Z3fooFNaNbNiNf{S3mod38__T3fooT(S3mod10__T3fooTiZ3fooFiZ4Vold)Z3fooF(S3mod10__T3fooTiZ3fooFiZ4Vold)Z4Vold}Z$ Lengths: 36 | 90 | 202 Note: the part inside () is the return type of the first. The part in {} is the return type of the second. I left those in for illustrative purposes.
Hide input string from stdin
I tried to write a small program that receive string as password. However, I didn't find available library for hide input string, even in core library. Any suggestion?
Re: My ACCU 2016 keynote video available online
On Thursday, 19 May 2016 at 12:54:48 UTC, Jens Müller wrote: For example what's equivalent to gdc's -ffast-math in ldc. This is: https://github.com/ldc-developers/ldc/pull/1472 Working on performance improvements is a lot of fun. Please feed us with code that doesn't run as fast as it should! :) Johan
Re: Project: better partition
On 05/22/2016 05:33 PM, Xinok wrote: The idea is simple: alternate the check for equality in hopes of skipping some equal elements. Unfortunately, this modification requires a little more work and TWO sentinels at either end of the range because it may skip over the first. So that's slower than what I have in my slides. Why not use that? -- Andrei
Re: DMD producing huge binaries
On 05/21/2016 03:13 PM, Kagamin wrote: On Saturday, 21 May 2016 at 18:18:21 UTC, Andrei Alexandrescu wrote: He said that that won't happen any longer, the growth was because of the return type. Is that correct? https://issues.dlang.org/show_bug.cgi?id=15831#c4 Looks like growth is due to the fact that the voldemort type is in the scope of a function and function is fun!(T).fun(T) - hence each level multiplies by 2. And return type is not part of the mangled name already - that would cause circular dependency, you would need the voldemort type mangling to generate it. Just to make sure I understand: do you agree or disagree that there's no more exponential growth if we encode "auto return" in the mangling? Thx! -- Andrei
Re: DMD producing huge binaries
On 05/21/2016 06:27 PM, Anon wrote: On Saturday, 21 May 2016 at 20:50:56 UTC, Walter Bright wrote: On 5/21/2016 1:49 PM, Walter Bright wrote: We already have a compressor in the compiler source for compressing names: https://github.com/dlang/dmd/blob/master/src/backend/compress.c A faster one would certainly be nice. Anyone game? Note how well it does: https://issues.dlang.org/show_bug.cgi?id=15831#c5 The underlying symbols are still growing exponentially. Nobody has the RAM for that, regardless of what size the resultant binary is. Compressing the symbol names is a bandage. The compiler needs a new kidney. My understanding is that the encoding "auto" return in the mangling makes any exponential growth disappear. Is that the case? -- Andrei
Re: D plugin for Visual Studio Code
On Sunday, 22 May 2016 at 17:49:08 UTC, poliklosio wrote: Oh, I see. I didn't realize you don't have a Windows machine available. I'll try to build the newest version when I have the time. Its pretty unfortunate that it doesn't work because VSCode is the only editor that has all ticks on this page https://wiki.dlang.org/Editors so people new to D are more likely to try VSCode first (like me), only wasting time if they are on Windows. windows hates me too much, these permission issues don't make any sense. Why wouldn't dub be able to write the lib file to the project directory? Fixing workspace-d-installer is just as important as fixing workspace-d for windows. Also the laptop is so super slow, I think my Windows VM would be faster. Gonna try and fix the issues on there in the next few days.
Re: Project: better partition
On Wednesday, 18 May 2016 at 19:54:19 UTC, Andrei Alexandrescu wrote: ... No worries. Please take anything you need from there for your code, make it better, and contribute it back to the stdlib! -- Andrei As it turns out, easier said than done. I've been thinking about it for a few days now but I don't see a simple way to optimally merge the two techniques. The way that I alternate between iterating "lo" and "hi" (or lef/rig in my code) doesn't really work when you need to keep the iterator stationary until something fills the vacancy. This is the best solution I have so far and it doesn't feel like a good solution at that: for (;;) { ++lo; for (;;) { if(r[lo] < p) ++lo; else break; if(r[lo] <= p) ++lo; else break; } if(lo > hi) lo = hi; r[hi] = r[lo]; --hi; for (;;) { if(p < r[hi]) --hi; else break; if(p <= r[hi]) --hi; else break; } if(lo >= hi) break; r[lo] = r[hi]; } The idea is simple: alternate the check for equality in hopes of skipping some equal elements. Unfortunately, this modification requires a little more work and TWO sentinels at either end of the range because it may skip over the first. In most real-world data, there's only marginal gains to be made in skipping over equal elements, too small to justify compromising the gains achieved by using sentinels and vacancies. So unless an optimal solution exists, it's just not worth it.
Re: OpenGL with D tutorials
On Sunday, 22 May 2016 at 12:13:07 UTC, ixid wrote: What is the best OpenGL tutorial with D to use? I've tried to use d-gamedev-intro and opengl-tutorials and seem to get errors, files that are no longer included are needed (dgl)? and deprecation messages. Perhaps use a C++ tutorial : http://www.learnopengl.com/ You can attempt to do the examples in D using GFM
Re: amoeba, a chess engine written in D
On Sunday, 22 May 2016 at 11:20:44 UTC, John Colvin wrote: LDC might benefit from copying the _popcnt source from ldc's druntime in to your code as it has a problem inlining it from druntime. You might also see a benefit from the -single-obj flag (enabled by default in ldmd). Thank you for those advices. I succeeded to have popcnt in the LCD build, (using llvm_ctpop). -singleobj looks like a good idea too. for the above test: original: 18.7 s with popcnt & singleobj: 11.1s. LDC is now close to GDC in performance. A question: why singleobj is not activated by a -Ox options? -- Richard
Re: Release DUB 0.9.25, new logo and updated website design
On Sunday, 22 May 2016 at 19:36:39 UTC, Sönke Ludwig wrote: This version marks the final milestone before the 1.0.0 release, which is scheduled for mid-June. The API has been cleaned up and will be kept backwards compatible throughout 1.x.x (0.9.25->1.0.0 may still have some breaking changes). Beginning with version 1.0.0, DUB will also become part of the DMD compiler distribution, so that no additional setup will be required to build DUB projects. Nice work, looking forward to seeing dub be part of the dmd package, hope the same can be done for ldc. I'll see if I can get it running on Android/ARM, don't want to leave out those who want to build D libraries on their Android tablet. ;)
Re: My ACCU 2016 keynote video available online
On Thursday, 19 May 2016 at 12:54:48 UTC, Jens Müller wrote: But ldc looks so bad. Any comments from ldc users or developers? Because I see this in many other measurements as well. This definitely does not match up with my experience. Particularly if you see this in many measurements, there might be something iffy with the way you test. Could you please post a runnable snippet that demonstrates the issue? In general, could you please directly post any performance issues to the LDC issue tracker on GitHub? We are quite interested in them, but I only happened to come across this post by chance. — David
[Issue 16026] std.math.frexp!float() wrong for very small subnormal values
https://issues.dlang.org/show_bug.cgi?id=16026 --- Comment #6 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/a6a1957be301860b1fa5d9205f1edd7a39cc0a1a Fix issue 16026: std.math.frexp!float() wrong for very small subnormal values https://github.com/dlang/phobos/commit/4991b82304b421f56e5394ba849826ee3251c89f Merge pull request #4337 from tsbockman/issue_16026 Fix issue 16026: std.math.frexp!float() wrong for very small subnormals --
Re: Interest in Boston area D meetups?
On Tuesday, 17 May 2016 at 13:17:35 UTC, Steven Schveighoffer wrote: Is anyone interested in having D meetups in Boston area? I'm not familiar with really any other locals (well, there is one person I know of :) -Steve I would love to be part of the Boston D community. Maybe we can meet on/near the D line? Could not help making a pun. :-) -- Sameer
Re: [OT] On Giving Presentations
On Sunday, 22 May 2016 at 18:35:16 UTC, Walter Bright wrote: http://alumni.media.mit.edu/~cahn/life/gian-carlo-rota-10-lessons.html#expository A lot of us wind up giving presentations now and then, and all of us can improve. This article has some great advice, and is a good read, too. Did you mean to link to the first point? http://alumni.media.mit.edu/~cahn/life/gian-carlo-rota-10-lessons.html#lecturing
Re: D plugin for Visual Studio Code
On Sunday, 22 May 2016 at 12:16:36 UTC, Martin Nowak wrote: Anyone working on a D language plugin for Visual Studio's cross platform IDE? Of course we're late to the party, language support for everything else is already there. http://code.visualstudio.com/ How is the D language experience on Atom and Sublime Text? There are about 3 plug-ins for D on Atom, all of which aren't exactly spectacular. They are all missing a few keywords IIRC and/or also fuck up your syntax highlighting quite badly with some constructions (primarily the ones with parentheses).
Re: Is there a way to make a class variable visible but constant to outsiders, but changeable (mutable) to the class itself?
On Saturday, 21 May 2016 at 17:32:47 UTC, dan wrote: Is it possible to have a class which has a variable which can be seen from the outside, but which can only be modified from the inside? Something like: class C { int my_var = 3; // semi_const?? void do_something() { my_var = 4; } } Yes, I prefer this idiom: class C { union { private int var_rw; public const(int) var_ro; } }
Re: [OT] On Giving Presentations
On Sunday, 22 May 2016 at 18:35:16 UTC, Walter Bright wrote: http://alumni.media.mit.edu/~cahn/life/gian-carlo-rota-10-lessons.html#expository A lot of us wind up giving presentations now and then, and all of us can improve. This article has some great advice, and is a good read, too. Very nice pointer. Although it is 20 years old (from circa 1996), it still makes so much sense. -- Sameer
[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored
https://issues.dlang.org/show_bug.cgi?id=15925 Kenji Harachanged: What|Removed |Added Resolution|FIXED |INVALID --
[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored
https://issues.dlang.org/show_bug.cgi?id=15925 github-bugzi...@puremagic.com changed: What|Removed |Added Resolution|INVALID |FIXED --
[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored
https://issues.dlang.org/show_bug.cgi?id=15925 --- Comment #6 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/f0f38381ed27fd8a4d2e36d13623698970cff7bd Revert "[REG 2.071] Fix Issue 15925 - Import declaration from mixin templates are ignored" https://github.com/dlang/dmd/commit/64f3fdb27b6d9d465c307b45c26a6c9fe10844b8 Merge pull request #5800 from dlang/revert-5724-fix-15925-stable Revert "[REG 2.071] Fix Issue 15925 - Import declaration from mixin templates are ignored" --
Re: Release DUB 0.9.25, new logo and updated website design
On Sunday, 22 May 2016 at 19:36:39 UTC, Sönke Ludwig wrote: registry, and the site style has been adjusted to fit the general dlang.org design (thanks to Sebastian Wilzbach!). Hi. Is possible change font to something more readable? For example, like font on http://dlang.org
Re: Need a Faster Compressor
On 5/22/2016 9:06 AM, Marco Leise wrote: Are there any objections against the benchmarking method or the license? BSD may cause problems. Can the implementation be in D? Not yet. If not, should we link against the system liblz4.so/a No. or copy the C code into the backend? Yes. Is a pre-filled dictionary worthwhile? The trouble with that is the demangler would need the same dictionary, right? If so, that would be problematic.
Re: Release DUB 0.9.25, new logo and updated website design
On Sunday, 22 May 2016 at 19:36:39 UTC, Sönke Ludwig wrote: This version marks the final milestone before the 1.0.0 release, which is scheduled for mid-June. The API has been cleaned up and will be kept backwards compatible throughout 1.x.x (0.9.25->1.0.0 may still have some breaking changes). Beginning with version 1.0.0, DUB will also become part of the DMD compiler distribution, so that no additional setup will be required to build DUB projects. [...] I love the new look! Congratulations on the latest version!
Re: Need a Faster Compressor
On 5/22/2016 10:44 AM, Rainer Schuetze wrote: You are right about the symbols using the VC mangling. The test case "1.s.s.s.s.s" in the bugreport translated to C++ yields ?foo@Result@?1???$s@UResult@?1???$s@UResult@?1???$s@UResult@?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@testexpansion@@YA@U1?1???$s@H@2@YA@H@Z@@Z@@testexpansion@@YA@U1?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@2@YA@U1?1???$s@H@2@YA@H@Z@@Z@@Z@@testexpansion@@YA@U1?1???$s@UResult@?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@testexpansion@@YA@U1?1???$s@H@2@YA@H@Z@@Z@@2@YA@U1?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@2@YA@U1?1???$s@H@2@YA@H@Z@@Z@@Z@@Z@@testexpansion@@YA@U1?1???$s@UResult@?1???$s@UResult@?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@testexpansion@@YA@U1?1???$s@H@2@YA@H@Z@@Z@@testexpansion@@YA@U1?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@2@YA@U1?1???$s@H@2@YA@H@Z@@Z@@Z@@2@YA@U1?1???$s@UResult@?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@testexpansion@@YA@U1?1???$s@H@2@YA@H@Z@@Z@@2@YA@U1?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@2@YA@U1?1???$s@H@2@YA@H@Z@@Z@@Z@@Z@@Z@QAEXXZ Haha, thus showing why people should never invent their own ad-hoc crypto nor compression algorithms :-) _ZZN13testexpansion1sIZNS0_IZNS0_IZNS0_IZNS0_IiEEDaT_E6ResultEES1_S2_E6ResultEES1_S2_E6ResultEES1_S2_E6ResultEES1_S2_EN6Result3fooEv Note "Result" appearing 5 times. It's still crappy compression. Ironically, this design predates the much worse VC++ one. which is only 39 characters longer than the compressed version of the D symbol. It uses a much smaller character set, though. The much smaller character set can be done, if desired, by using base64 encoding. The compressor is careful to not emit 0 bytes, as those definitely would screw up bintools, but the rest seem unperturbed by binary strings.
Re: D plugin for Visual Studio Code
On Sunday, 22 May 2016 at 18:07:55 UTC, WebFreak001 wrote: Actually, I can use my mother's laptop. Gonna try to fix it now Check debugger also, please, because it also doesn't work.
Re: Need a Faster Compressor
On Sunday, 22 May 2016 at 19:21:13 UTC, Walter Bright wrote: On 5/22/2016 3:32 AM, Era Scarecrow wrote: Curiously the extra 95 symbols actually is just enough to keep compression up and bring speed to about 37% speed gain, with it looks like no disadvantages. You're doing the gods' work, Era! Maybe... I have to wonder if LZ4 from the looks of things will take over instead. Have to see how it performs (and if we can integrate it); Meanwhile the main advantage of id_compress (as I'm tinkering with it) is it makes no changes to the signature/behavior so taking advantage of it's boost in speed can be immediate (although it will no doubt have a bit weaker compression, and demangling needs to be re-written for it). Honestly the majority of speed gains with id_compress are simply from having a much smaller window(1023 to 220), also resulting in a smaller footprint for the compressed output (3 bytes to 2 bytes). Compare to the speed gains from my new algorithm (at 20% faster) is pretty constant, and retains a HUGE window (pre-scans 8k, has a 2k window) that it can find matches from, so it will win in compression. If LZ4 is half as good as the initial results are then I'd go with it instead.
Re: Need a Faster Compressor
On 5/22/2016 3:32 AM, Era Scarecrow wrote: [...] My idea for speeding things up is every time a new character c is matched in pattern[], a bit is set in mask: ulong mask; ... mask |= 1 << (c & 63); Then, when scanning for longer matches, test: if (!((1 << (id[i + matchlen - 1] & 63)) & mask)) i += matchlen; because we know that id[i + matchlen - 1] cannot match any of the characters in the current match. The two expressions look complex, but they should compile to single instructions on x64.
Release DUB 0.9.25, new logo and updated website design
This version marks the final milestone before the 1.0.0 release, which is scheduled for mid-June. The API has been cleaned up and will be kept backwards compatible throughout 1.x.x (0.9.25->1.0.0 may still have some breaking changes). Beginning with version 1.0.0, DUB will also become part of the DMD compiler distribution, so that no additional setup will be required to build DUB projects. In preparation to that, it also received a thorough optical overhaul. The newly designed logo (which has appeared in some other spots already) has been integrated on the package registry, and the site style has been adjusted to fit the general dlang.org design (thanks to Sebastian Wilzbach!). Some major changes to DUB itself are: - Builds on frontend versions up to 2.071.0 - Implements proper optional dependency semantics, where using an optional dependency can now be controlled using dub.selections.json - "dub init" is now interactive by default (use -n to disable) - Contains some critical changes regarding path based dependencies - New "convert" and "search" commands - It now supports "git submodule" style packages that put their D sources at the root of the repository and expect to be checked out into a folder with the name of the package/repository. This builds on a new folder structure for downloaded packages and may require a re-download of affected packages to take effect. If you run into any issues, try removing all cached packages with "dub remove *". Full change log: https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md Download: http://code.dlang.org/download
Re: Is there a way to make a class variable visible but constant to outsiders, but changeable (mutable) to the class itself?
On Sunday, 22 May 2016 at 03:06:44 UTC, Mike Parker wrote: On Saturday, 21 May 2016 at 19:17:00 UTC, dan wrote: Thanks Vit, Meta, and Yuxuan for your speedy help! So 3 pieces to put together, function, const, and @property (and i guess final for protection against subclasses). Minimally, there are two pieces to this: a private member variable and a function. class Foo { private int _myVar; int myVar() { return _myVar; } } The private is necessary because class members in D are all public by default. If it isn't there, then _myVar can be directly modified outside of the module. Be aware, though (if you aren't already), that private members *are* accessible outside of the class in the same module, e.g.: module foo; class Foo { private int _myVar; int myVar() { return _myVar; } } void printMyVar() { import std.stdio : writeln; auto f = new Foo; writeln(f); } As for 'const' and '@property', neither is strictly a requirement to implement this idiom. Adding const means that you can call the function through const references, but if that's not something you want to allow for some reason, then don't add it. @property right now doesn't really do anything other than allow for self-documenting code. Perhaps one day it will be fully implemented and require callers to drop the parentheses in calls to @property functions, but for now it doesn't do that. Use it as much as you want, but just understand it isn't necessary for the functionality you are after. Const *is* necessary to prevent _myVar being written to through code like: f.myVar = 4; Of course this isn't necessary for value types, but for reference types. It's also useful for value types, IMO, for preventing someone from doing this: f.myVar = 4; And wondering why the code has no effect.
Re: Need a Faster Compressor
On 5/22/2016 3:32 AM, Era Scarecrow wrote: Curiously the extra 95 symbols actually is just enough to keep compression up and bring speed to about 37% speed gain, with it looks like no disadvantages. Then again I still need a larger set to test things on, but it's very promising! You're doing the gods' work, Era!
Re: Need a Faster Compressor
On 5/22/2016 2:57 AM, Era Scarecrow wrote: Question Walter (or Andrei): Would it be terrible to have lower characters as part of the identifier string? I'm referring to characters under 32 (control characters, especially the \r, \n and \t). Currently there's a bug in id_compress() where it doesn't take into account UTF-8 sequences, as a subset of them are allowed as identifiers. I rue the day I allowed that in D, but we're kinda stuck with it. I kinda hate disallowing control characters, because then the compressor gets a bit specific.
Re: Need a Faster Compressor
On 5/22/2016 5:50 AM, deadalnix wrote: On Sunday, 22 May 2016 at 01:36:39 UTC, Walter Bright wrote: Just a note: large lookup tables can have cold cache performance problems. 16k lookup table are the gold standard. I like 64 bit vectors because the lookup and test can be done in one instruction, and the vector cached in a register!
Re: Need a Faster Compressor
On 5/22/2016 2:07 AM, Era Scarecrow wrote: On Sunday, 22 May 2016 at 08:50:47 UTC, Walter Bright wrote: On 5/21/2016 11:26 PM, Era Scarecrow wrote: With 1 Million iterations: new_compress: TickDuration(311404604) id_compress TickDuration(385806589) Approx 20% increase in speed (if i'm reading and did this right). It is promising. Need more! Well there's other good news. While I was working with about 2Mb for the data size in general, it can be reduced it looks like to about 8k-16k, and run entirely on the stack. It doesn't appear to gain any speed, or any speed gained is lost with better memory management. Although based on how things look, the id_compress might perform better with a max window of 255 and max match of 127. I'll give the original one a tweak based on my own findings and see if it turns out true. There's also https://github.com/dlang/dmd/pull/5799 which should make things faster.
[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored
https://issues.dlang.org/show_bug.cgi?id=15925 Walter Brightchanged: What|Removed |Added CC||bugzi...@digitalmars.com Resolution|FIXED |INVALID --- Comment #5 from Walter Bright --- This is not a bug, the behavior is on purpose and as designed. This was discussed at length for an analogous case, imports in base classes. --
[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored
https://issues.dlang.org/show_bug.cgi?id=15925 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to revert-5724-fix-15925-stable at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/f0f38381ed27fd8a4d2e36d13623698970cff7bd Revert "[REG 2.071] Fix Issue 15925 - Import declaration from mixin templates are ignored" --
Is there a way to clear an OutBuffer?
Is there a way to clear an OutBuffer, but without freeing the internally managed buffer? Something similar to std.array.appender.clear method. Intent would be to reuse the OutBuffer, but without reallocating memory for the buffer. --Jon
faster splitter
On Monday, 4 March 2013 at 19:11:17 UTC, Steven Schveighoffer wrote: On Mon, 04 Mar 2013 12:35:23 -0500, Andrei Alexandrescuwrote: That's comparable, please file an enh request. http://d.puremagic.com/issues/show_bug.cgi?id=9646 Below is an implementation, which matches MySplitter with dmd, but not with ldc. More precisely: dmd -O -release -inline -noboundscheck: std.algorithm.splitter took 5 secs, 170 ms, and 656 μs MySplitter took 4 secs, 835 ms, 748 μs, and 1 hnsec my_splitter took 4 secs, 862 ms, 914 μs, and 4 hnsecs ldc2 -O -release: std.algorithm.splitter took 3 secs, 540 ms, and 84 μs MySplitter took 2 secs, 288 ms, and 535 μs my_splitter took 3 secs, 463 ms, and 897 μs CPU: Intel i7 M 620 2.67GHz dmd: v2.070.2 ldc: 0.17.1 (based on DMD v2.068.2 and LLVM 3.7.1) auto my_splitter(alias pred = "a == b", Range, Separator)(Range r, Separator s) if (is(typeof(binaryFun!pred(r.front, s.front)) : bool) && (hasSlicing!Range || isNarrowString!Range) && isForwardRange!Separator && (hasLength!Separator || isNarrowString!Separator)) { import std.algorithm.searching : find; import std.conv : unsigned; static struct Result { private: Range _input; Separator _separator; size_t _next_index; bool _empty; @property auto separatorLength() { return _separator.length; } void findIndex() { auto found = find!pred(_input, _separator); _next_index = _input.length - found.length; } public: this(Range input, Separator separator) { _input = input; _separator = separator; _empty = false; findIndex(); } @property Range front() { assert(!empty); return _input[0 .. _next_index]; } static if (isInfinite!Range) { enum bool empty = false; // Propagate infiniteness } else { @property bool empty() { return _empty; } } void popFront() { assert(!empty); if (_input.empty) { _empty = true; assert(_next_index == 0); } else if (_input.length == _next_index) { _input = _input[$ .. $]; _empty = true; } else { _input = _input[_next_index + separatorLength .. $]; findIndex(); } } static if (isForwardRange!Range) { @property typeof(this) save() { auto ret = this; ret._input = _input.save; return ret; } } } return Result(r, s); }
Re: Game Development Using D
On Saturday, 21 May 2016 at 15:53:18 UTC, David wrote: Hi, I want to try to create a game using D. I'm a complete newbie though (other than having C/C++ experience). Where would I start? Does D have an openGL binding? I am assuming I'll need to leverage a good amount C APIs? Any list of these that would be useful it a game setting? Obviously this all depends on *how* much work I want to do. Ideally, I'd like a collection of tools that will get me roughly the equivalent of what XNA provides. If you don't know much OpenGL, go for DSFML https://github.com/Jebbs/DSFML
Re: amoeba, a chess engine written in D
On Friday, 20 May 2016 at 23:16:01 UTC, Richard Delorme wrote: The source can be compiled with dmd, ldc or gdc, but the best performance are obtained with the latter (almost twice faster). Allowing LDC to do cross-module optimisations (by adding the -singleobj flag) and make use of popcnt increased the performance by 47% for one specific benchmark, which should bring it into the same ballpark as GDC. See https://github.com/abulmo/amoeba/pull/2 for more details. PGO might still give the latter a bit of an edge, though, as LDC's implementation is still experimental and there is a lot of unused potential for making use of the profile data in LLVM's optimiser. — David
[OT] On Giving Presentations
http://alumni.media.mit.edu/~cahn/life/gian-carlo-rota-10-lessons.html#expository A lot of us wind up giving presentations now and then, and all of us can improve. This article has some great advice, and is a good read, too.
Re: Need a Faster Compressor
On Sunday, 22 May 2016 at 18:18:46 UTC, Marco Leise wrote: If you provide the decompressor, we're set. :) I am already working on a non-ctfeable version that does not use slices. And therefore should be faster. But decompression is only needed for demangling.
Re: Need a Faster Compressor
On 22.05.2016 20:12, Era Scarecrow wrote: On Sunday, 22 May 2016 at 18:04:25 UTC, Rainer Schuetze wrote: On 22.05.2016 19:56, Era Scarecrow wrote: Unless ? is the proper/valid character those are far more likely to be failed UTF-8 decoding. Care to double check? ? is an allowed character in VC++ and for example permits unambiguous demangling. The gcc style using only alpha numeric characters and '_' can also just be plain C symbols. Not quite what I asked. Is the sample provided accurate? Is having 3 ?s in a row what should be there not just spitting a ? because it doesn't know how to decode it? The 3 consecutive ?s are also in the object file, so they are actually part of the mangled symbol. VC++ uses only ASCII characters for mangling (which D should do, too, IMO).
Re: Need a Faster Compressor
Am Sun, 22 May 2016 17:19:38 + schrieb Stefan Koch: > Here are my answers please take them with a grain of ignorance. > […] Maybe you are right about the dictionary. I haven't put much any thought into it. Anyways I was looking for input from the core devs who are affected by this. > However I agree with Martins point: It is a waste of resources > re-implementing something that already has a perfectly fine > implementation. I already loosely copied and fixed up the compressor in the attached proof of concept. Thanks to the two languages' similarities it was a matter of an hour or so. If you provide the decompressor, we're set. :) -- Marco
Re: Need a Faster Compressor
On Sunday, 22 May 2016 at 18:04:25 UTC, Rainer Schuetze wrote: On 22.05.2016 19:56, Era Scarecrow wrote: Unless ? is the proper/valid character those are far more likely to be failed UTF-8 decoding. Care to double check? ? is an allowed character in VC++ and for example permits unambiguous demangling. The gcc style using only alpha numeric characters and '_' can also just be plain C symbols. Not quite what I asked. Is the sample provided accurate? Is having 3 ?s in a row what should be there not just spitting a ? because it doesn't know how to decode it?
Re: D plugin for Visual Studio Code
On Sunday, 22 May 2016 at 17:49:08 UTC, poliklosio wrote: On Sunday, 22 May 2016 at 17:04:01 UTC, WebFreak001 wrote: [...] Oh, I see. I didn't realize you don't have a Windows machine available. I'll try to build the newest version when I have the time. Its pretty unfortunate that it doesn't work because VSCode is the only editor that has all ticks on this page https://wiki.dlang.org/Editors so people new to D are more likely to try VSCode first (like me), only wasting time if they are on Windows. Actually, I can use my mother's laptop. Gonna try to fix it now
Re: Need a Faster Compressor
On 22.05.2016 19:56, Era Scarecrow wrote: On Sunday, 22 May 2016 at 17:44:22 UTC, Rainer Schuetze wrote: You are right about the symbols using the VC mangling. The test case "1.s.s.s.s.s" in the bugreport translated to C++ yields ?foo@Result@?1???$s@UResult@?1???$s@UResult@?1???$s i.e. 936 characters. I think this is due to the very bad limitation of just back referencing the first 10 types. Unless ? is the proper/valid character those are far more likely to be failed UTF-8 decoding. Care to double check? ? is an allowed character in VC++ and for example permits unambiguous demangling. The gcc style using only alpha numeric chanracters and '_' can also just be plain C symbols.
Re: Need a Faster Compressor
On Sunday, 22 May 2016 at 17:44:22 UTC, Rainer Schuetze wrote: You are right about the symbols using the VC mangling. The test case "1.s.s.s.s.s" in the bugreport translated to C++ yields ?foo@Result@?1???$s@UResult@?1???$s@UResult@?1???$s i.e. 936 characters. I think this is due to the very bad limitation of just back referencing the first 10 types. Unless ? is the proper/valid character those are far more likely to be failed UTF-8 decoding. Care to double check?
Re: D plugin for Visual Studio Code
On Sunday, 22 May 2016 at 17:04:01 UTC, WebFreak001 wrote: On Sunday, 22 May 2016 at 15:35:23 UTC, poliklosio wrote: The code-d plugin doesn't work on Windows for a very long time (months). There is even an issue on github https://github.com/Pure-D/code-d/issues/38 Do you have any plans of fixing it or is Windows low priority? It would be nice to fix it but I have no way of testing if it actually worked. Everything works here on linux, even if I change dcd to use TCP instead of unix domain sockets. I made some minor changes to catch some errors, can you recompile workspace-d and update code-d and try if it works now? Oh, I see. I didn't realize you don't have a Windows machine available. I'll try to build the newest version when I have the time. Its pretty unfortunate that it doesn't work because VSCode is the only editor that has all ticks on this page https://wiki.dlang.org/Editors so people new to D are more likely to try VSCode first (like me), only wasting time if they are on Windows.
Re: Need a Faster Compressor
On 22.05.2016 00:58, Walter Bright wrote: On 5/21/2016 3:41 PM, Guillaume Boucher wrote: Sorry if I didn't memorize everything in this forum from the last 20 years, can you give a link to some reasoning? DMC++ matches the Microsoft name mangling scheme, which includes such compression. It proved hopelessly inadequate, which is why I implemented compress.c in the first place (it was for the DMC++ compiler). (And frankly, I don't see how an ad-hoc scheme like that could hope to compare with a real compression algorithm.) You are right about the symbols using the VC mangling. The test case "1.s.s.s.s.s" in the bugreport translated to C++ yields ?foo@Result@?1???$s@UResult@?1???$s@UResult@?1???$s@UResult@?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@testexpansion@@YA@U1?1???$s@H@2@YA@H@Z@@Z@@testexpansion@@YA@U1?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@2@YA@U1?1???$s@H@2@YA@H@Z@@Z@@Z@@testexpansion@@YA@U1?1???$s@UResult@?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@testexpansion@@YA@U1?1???$s@H@2@YA@H@Z@@Z@@2@YA@U1?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@2@YA@U1?1???$s@H@2@YA@H@Z@@Z@@Z@@Z@@testexpansion@@YA@U1?1???$s@UResult@?1???$s@UResult@?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@testexpansion@@YA@U1?1???$s@H@2@YA@H@Z@@Z@@testexpansion@@YA@U1?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@2@YA@U1?1???$s@H@2@YA@H@Z@@Z@@Z@@2@YA@U1?1???$s@UResult@?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@testexpansion@@YA@U1?1???$s@H@2@YA@H@Z@@Z@@2@YA@U1?1???$s@UResult@?1???$s@H@testexpansion@@YA@H@Z@@2@YA@U1?1???$s@H@2@YA@H@Z@@Z@@Z@@Z@@Z@QAEXXZ i.e. 936 characters. I think this is due to the very bad limitation of just back referencing the first 10 types. The gcc mangling allows arbitrary back references and is closer to what some have proposed. It yields _ZZN13testexpansion1sIZNS0_IZNS0_IZNS0_IZNS0_IiEEDaT_E6ResultEES1_S2_E6ResultEES1_S2_E6ResultEES1_S2_E6ResultEES1_S2_EN6Result3fooEv which is only 39 characters longer than the compressed version of the D symbol. It uses a much smaller character set, though. This is my translation of the test case to C++14: namespace testexpansion { template struct S { void foo(){} }; template auto testexpansion_s(T t) { #ifdef bad struct Result { void foo(){} }; return Result(); #else return S(); #endif } void xmain() { auto x = s(s(s(s(s(1); x.foo(); } }
Re: Is there a 128-bit integer in D?
On Sunday, 22 May 2016 at 12:03:16 UTC, Guillaume Piolat wrote: I don't know how this works, someone has to propose it, clean it up and respond to feedback I guess. Glancing briefly at the source, it appears (from what I saw) it's heavily based on doubling the size of a lower type (2 64's to equal a 128, etc). This means to get the next level up you double again. So if I read it right for example, the opIncrease does this almost verbatim: opIncrease() { //aka ++ low++; if (low == 0) //overflow detection high++; } Going from native up one level is easy enough, but to do a 256 type it would do the same from a lower level. Meaning the int256 type does opIncrease on 2 int128 types, which break down to the native long type. Making a 256 or 512 silently creates all the lower ones until it can lower to a native type as the starting point. More importantly is if they fully act as built-in types with their declarations, except (for maybe auto promotion of course, although that might work too). The only two operations that are going to be slow no matter how you slice it are multiply and divide. If you don't use multiply or divide, your code will be fast regardless how many levels it goes.
Re: Need a Faster Compressor
On Sunday, 22 May 2016 at 16:06:07 UTC, Marco Leise wrote: There are a few open questions, for me at least. Are there other proposals with good properties? Are there any objections against the benchmarking method or the license? Can the implementation be in D? If not, should we link against the system liblz4.so/a or copy the C code into the backend? Is a pre-filled dictionary worthwhile? If so, which words should go in it? The latter is important because changes to the Dlang mangling need to be reflected in other projects outside our direct control, too. How it's being benchmarked does make me question it a bit. I avoided doing multi-threading so my results are as they would run on 1 CPU/Core, while adding multi-threading probably isn't too hard to do (at least in D). Then there's the wonder of how many cores, and other details. A compressor designed to run in parallel will naturally be in it's own element there. This of course assumes we are allowed to in the first place; The compiler may already be using those cores for other tasks: Scanning other files, optimizing code, CTFE, etc, to which point speed gained in compression may not actually translate to an overall speedup if you are stealing CPU cycles. As for a dictionary and being primed, I'm trying to figure out what would be in it myself. Commonly used templates and keywords that appear in symbols are so far my best guess. I'd avoid library names unless they'd appear in the symbols (so 'std.core' might not mean much, while 'unittestL' does). Then again I don't have a good sample of what I'd actually encounter live, maybe every major library import would be good thing to have.
Re: Need a Faster Compressor
On Sunday, 22 May 2016 at 16:06:07 UTC, Marco Leise wrote: There are a few open questions, for me at least. Are there other proposals with good properties? Are there any objections against the benchmarking method or the license? Can the implementation be in D? If not, should we link against the system liblz4.so/a or copy the C code into the backend? Is a pre-filled dictionary worthwhile? If so, which words should go in it? The latter is important because changes to the Dlang mangling need to be reflected in other projects outside our direct control, too. Here are my answers please take them with a grain of ignorance. I do not think prefilling the dictionary will do much good since LZ is all about finding prefixs anyway. I am for copying the sourcecode into our source-tree we don't want to be dependent on LZ4 library being available on the users system. I think re-implementing it in D is also fine as long as the function is extern(C). However I agree with Martins point: It is a waste of resources re-implementing something that already has a perfectly fine implementation. The only reason why I re-implemented the LZ4 decompression was to use it at CTFE.
Re: D plugin for Visual Studio Code
On Sunday, 22 May 2016 at 15:35:23 UTC, poliklosio wrote: The code-d plugin doesn't work on Windows for a very long time (months). There is even an issue on github https://github.com/Pure-D/code-d/issues/38 Do you have any plans of fixing it or is Windows low priority? It would be nice to fix it but I have no way of testing if it actually worked. Everything works here on linux, even if I change dcd to use TCP instead of unix domain sockets. I made some minor changes to catch some errors, can you recompile workspace-d and update code-d and try if it works now?
[Issue 16049] core.sys.windows structs have wrong sizes and aligns
https://issues.dlang.org/show_bug.cgi?id=16049 --- Comment #3 from j...@red.email.ne.jp --- (In reply to jiki from comment #2) > Note that I deferred to commit a module MMSYSTEM > because it gets many conflicts with/without my previous commit #1574 for > issue 15959. Fixed. --
[Issue 16056] immutable delegate can mutate through context pointer
https://issues.dlang.org/show_bug.cgi?id=16056 --- Comment #5 from ag0ae...@gmail.com --- (In reply to Eyal Lotem from comment #4) > immutable void delegate() pure > > vs. > > immutable void delegate() immutable pure When the delegate is part of an immutable struct instance, it has the former type, too: struct S { void delegate() pure f; } immutable s = S(); pragma(msg, typeof(s.f)); /* immutable(void delegate() pure) */ I suppose your point is that it should be the latter type, with two "immutable"s. Fair enough, but I don't think that distinction is worth having. D doesn't have head const with pointers. Why should we make delegates a special case? So in my opinion, `immutable void delegate()` should imply an immutable context pointer, making it the same type as `immutable void delegate() immutable`. Just like `immutable(int*)` is the same as `immutable(immutable(int)*)`. The compiler agrees (to some extent): alias A = immutable int* delegate(); alias B = immutable int* delegate() immutable; static assert(is(A == B)); /* passes */ But then there's this: void main() { int x = 1; const void delegate() dg1 = { ++x; }; const void delegate() const dg2 = { ++x; }; } That compiles, but when you take the dg1 line away, then the dg2 line isn't accepted anymore. And when you swap them around, both lines are rejected. There's obviously something wrong here. I've filed a separate issue: https://issues.dlang.org/show_bug.cgi?id=16058 --
[Issue 16058] New: `immutable delegate()` and `immutable delegate() immutable` are considered equal but treated differently
https://issues.dlang.org/show_bug.cgi?id=16058 Issue ID: 16058 Summary: `immutable delegate()` and `immutable delegate() immutable` are considered equal but treated differently Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: accepts-invalid Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: ag0ae...@gmail.com Spin-off from issue 16056. dmd considers the two types to be equal: alias A = immutable int* delegate(); alias B = immutable int* delegate() immutable; static assert(is(A == B)); /* passes */ That's ok. But it treats them differently. This is accepted with `-version=V1`, but it's rejected with `-version=V2`: version (V1) alias T = immutable void delegate(); version (V2) alias T = immutable void delegate() immutable; void main() { int x = 1; T dg = { ++x; }; } Both V1 and V2 should be rejected. Furthermore, when you use both types, the first one determines how the second is treated. This is accepted: void main() { int x = 1; immutable void delegate() dg1 = { ++x; }; immutable void delegate() immutable dg2 = { ++x; }; } Swap the two delegates lines and both are rejected. Again, both variants should be rejected. All this applies to const as well, of course. --
Re: Need a Faster Compressor
Am Sun, 22 May 2016 14:06:52 + schrieb Stefan Koch: > On Sunday, 22 May 2016 at 14:05:23 UTC, Marco Leise wrote: > > ⬅ Download proof of concept > > > > This is a proof of concept micro-benchmark compressing the > > 37_640 bytes symbol from the bug report linked above with both > > id_compress from the dmd backend and lz4 (without dictionary). > > The lz4 result is additionally transformed to 7-bits similar to > > base-64. > > > > Original size: 37640 bytes > > > > id_compress : 5243 ms for 10_000 iterations, 800 bytes > > lz4 : 71 ms for 10_000 iterations, 389 bytes > > > > That roughly corresponds to a 2x higher compression ratio at > > 70x faster compression speed. > > Please submit a PR. There are a few open questions, for me at least. Are there other proposals with good properties? Are there any objections against the benchmarking method or the license? Can the implementation be in D? If not, should we link against the system liblz4.so/a or copy the C code into the backend? Is a pre-filled dictionary worthwhile? If so, which words should go in it? The latter is important because changes to the Dlang mangling need to be reflected in other projects outside our direct control, too. -- Marco
Re: amoeba, a chess engine written in D
On Saturday, 21 May 2016 at 10:10:21 UTC, Richard Delorme wrote: On Saturday, 21 May 2016 at 00:29:13 UTC, extrawurst wrote: [...] Yes, It is a strong program, but far from the top programs yet. In the ccrl scale: http://www.computerchess.org.uk/ccrl/4040/ I guess its rating is close to 2700. The move generator is pretty fast, though: $ amoeba-linux-x64-sse4.2 perft -d 7 perft 7 : 3195901860 leaves in 17.920 s178344094 leaves/s [...] Congratulations 2700 is great, vastly better than I managed many years ago. Do you plan to take it further?
Re: D plugin for Visual Studio Code
On Sunday, 22 May 2016 at 12:47:36 UTC, WebFreak001 wrote: On Sunday, 22 May 2016 at 12:42:51 UTC, nazriel wrote: Bad in the sense that you are required to actually do the searching ;) And it breaks the convention used by other language plugins. So as you can see by the presence of this topic, plugin (which is really top notch btw) is easily overlooked When I made the plugin there was no convention because there were only some syntax highlighting packages and maybe 4 or 5 actual plugins for anything more than syntax highlighting. Any idea for a better plugin name? I can easily rename it in the marketplace and it will still be installable with `code-d` The code-d plugin doesn't work on Windows for a very long time (months). There is even an issue on github https://github.com/Pure-D/code-d/issues/38 Do you have any plans of fixing it or is Windows low priority?
Re: D <-> C++ exceptions
On Sunday, 22 May 2016 at 09:45:05 UTC, Manu wrote: On 22 May 2016 at 18:09, Xiaoxi via Digitalmars-dwrote: On Sunday, 22 May 2016 at 05:12:51 UTC, Manu wrote: On 22 May 2016 at 11:35, Walter Bright via Digitalmars-d wrote: On 5/21/2016 5:36 PM, Manu via Digitalmars-d wrote: Where are we with exceptions? I am now working against a C++ codebase that uses exceptions, on both linux and windows. Is it still only DWARF that works? That's right. Is MSCOFF work active, or on the back-burner? I think ldc2 has full native support of "everything", win32 , win64, unix, plus it has a very recent phobos and as a bonus it only uses 64bit real on windows. It doesn't have debuginfo. Have you tried lately? MS has been pushing some support into llvm, and I think the ldc guys who've been working on Windows support have tried to pull it in.
[Issue 16056] immutable delegate can mutate through context pointer
https://issues.dlang.org/show_bug.cgi?id=16056 --- Comment #4 from Eyal Lotem--- immutable void delegate() pure(In reply to ag0aep6g from comment #3) > (In reply to Eyal Lotem from comment #2) > > This is simpler -- but this simpler example isn't a bug: a pure func that > > takes a mutable delegate is "weakly pure" because it doesn't take an > > immutable argument. You could say that the simplified pure func takes an > > explicitly mutable argument, so it is known to be weakly pure. > > pure_func's parameter isn't mutable. It's explicitly marked immutable. immutable void delegate() pure vs. immutable void delegate() immutable pure Arguably, you can claim that if you've chosen the former form, you knowingly forfeited mutability for the delegate. However, once the delegate is wrapped in a struct, you would expect that transitivity would take care of full immutability. --
Re: Game Development Using D
On Saturday, 21 May 2016 at 15:53:18 UTC, David wrote: Hi, I want to try to create a game using D. I'm a complete newbie though (other than having C/C++ experience). Where would I start? Does D have an openGL binding? I am assuming I'll need to leverage a good amount C APIs? Any list of these that would be useful it a game setting? Obviously this all depends on *how* much work I want to do. Ideally, I'd like a collection of tools that will get me roughly the equivalent of what XNA provides. In DlangUI there is Tetris game example Repository: https://github.com/buggins/dlangui Tetris: https://github.com/buggins/dlangui/tree/master/examples/tetris Clone repository, cd dlangui/examples/tetris, dub run As well, there are OpenGL example https://github.com/buggins/dlangui/tree/master/examples/opengl and DMiner example (minecraft-like rendering engine) https://github.com/buggins/dlangui/tree/master/examples/dminer
Re: My ACCU 2016 keynote video available online
On Saturday, 21 May 2016 at 13:51:11 UTC, Manu wrote: On 21 May 2016 at 23:20, Andrei Alexandrescu via Digitalmars-d-announcewrote: On 05/21/2016 04:45 AM, Manu via Digitalmars-d-announce wrote: [...] I guess a lot more detail would be necessary here. A bunch of good folks (at least better than me) have worked for over a decade on C++ concepts and three (three!) proposals later it's still unclear whether they're a good idea. -- Andrei I agree it's not clear to me either. I haven't seen any proposals for D. Have there been any? Not quite the same but: https://github.com/dlang/phobos/pull/3677 https://wiki.dlang.org/DIP84#Implementation Atila
[Issue 15959] core.sys.windows modules should be modified for x64
https://issues.dlang.org/show_bug.cgi?id=15959 --- Comment #9 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/caf04060ca300ac0ca68e68e9b8de6fecec281cc Merge pull request #1574 from qchikara/additional-15959 Fix issue 15959 additional fixes --
[Issue 16056] immutable delegate can mutate through context pointer
https://issues.dlang.org/show_bug.cgi?id=16056 --- Comment #3 from ag0ae...@gmail.com --- (In reply to Eyal Lotem from comment #2) > This is simpler -- but this simpler example isn't a bug: a pure func that > takes a mutable delegate is "weakly pure" because it doesn't take an > immutable argument. You could say that the simplified pure func takes an > explicitly mutable argument, so it is known to be weakly pure. pure_func's parameter isn't mutable. It's explicitly marked immutable. --
Re: OpenGL with D tutorials
On Sunday, 22 May 2016 at 14:04:48 UTC, ixid wrote: On Sunday, 22 May 2016 at 12:55:47 UTC, Guillaume Piolat wrote: On Sunday, 22 May 2016 at 12:13:07 UTC, ixid wrote: What is the best OpenGL tutorial with D to use? I've tried to use d-gamedev-intro and opengl-tutorials and seem to get errors, files that are no longer included are needed (dgl)? and deprecation messages. Not a tutorial by any means but this example program can get you started with the annoying "Modern" OpenGL: https://github.com/d-gamedev-team/gfm/blob/master/examples/simpleshader/simpleshader.d Thanks, I have tried to get all the libraries and link them and now get a huge number of error messages (I am almost certainly missing or have mis-installed something, it doesn't complain about failing to import anything though. SeverityCodeDescription Project FileLineSuppression State Error Error 42: Symbol Undefined _D3gfm4sdl26window10SDL2Window11swapBuffersMFZv (void gfm.sdl2.window.SDL2Window.swapBuffers()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D8derelict7opengl39functions7glClearPWNbNikZv C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl23sdl4SDL213processEventsMFZv (void gfm.sdl2.sdl.SDL2.processEvents()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl7program9GLProgram3useMFZv (void gfm.opengl.program.GLProgram.use()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl3vao5GLVAO6unbindMFZv (void gfm.opengl.vao.GLVAO.unbind()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl7program9GLProgram5unuseMFZv (void gfm.opengl.program.GLProgram.unuse()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D8derelict7opengl39functions10glViewportPWNbNiZv C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl28keyboard12SDL2Keyboard9isPressedMFiZb (bool gfm.sdl2.keyboard.SDL2Keyboard.isPressed(int)) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl26window10SDL2Window8setTitleMFAyaZv (void gfm.sdl2.window.SDL2Window.setTitle(immutable(char)[])) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl7program9GLProgram7uniformMFAyaZC3gfm6opengl7uniform9GLUniform (gfm.opengl.uniform.GLUniform gfm.opengl.program.GLProgram.uniform(immutable(char)[])) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl23sdl4SDL28keyboardMFZC3gfm4sdl28keyboard12SDL2Keyboard (gfm.sdl2.keyboard.SDL2Keyboard gfm.sdl2.sdl.SDL2.keyboard()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4math6matrix21__T6MatrixTfVii4Vii4Z6Matrix8identityFNaNbNiNfZS3gfm4math6matrix21__T6MatrixTfVii4Vii4Z6Matrix C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D8derelict4sdl29functions12SDL_GetTicksPUNbNiZk C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Consider using DUB then. $ dub Package logger can be installed with version 2.66.0. Use "dub upgrade" to perform those changes. Performing "debug" build using dmd for x86_64. colorize 1.0.5: target for configuration "library" is up to date. gfm:logger 6.0.2: target for configuration "library" is up to date. derelict-util 2.0.6: target for configuration "library" is up to date. derelict-gl3 1.0.18: target for configuration "library" is up to date. gfm:math 6.0.2: target for configuration "library" is up to date. gfm:opengl 6.0.2: target for configuration "library" is up to date. derelict-sdl2 1.9.7: target for configuration "library" is up to date. gfm:sdl2 6.0.2: target for configuration "library" is up to date. simpleshader ~master: target for configuration "application" is up to date. To force a rebuild of up-to-date targets, run again with --force. Running ./simpleshader
[Issue 16056] immutable delegate can mutate through context pointer
https://issues.dlang.org/show_bug.cgi?id=16056 --- Comment #2 from Eyal Lotem--- (In reply to ag0aep6g from comment #1) > The struct doesn't really matter here, as far as I see. Simplified code: > > > import std.stdio; > > pure void pure_func(immutable void delegate() pure f) > { > f(); > } > > void main() { > int y; > writeln("Before: ", y); > pure_func({ y++; }); > writeln("After: ", y); > } > > > Possibly a duplicate of issue 11043 or issue 1983. This is simpler -- but this simpler example isn't a bug: a pure func that takes a mutable delegate is "weakly pure" because it doesn't take an immutable argument. You could say that the simplified pure func takes an explicitly mutable argument, so it is known to be weakly pure. When you do take an immutable argument in a pure function -- the immutability is supposed to be transitive -- so it is supposed to be strongly pure. --
Re: mutable keyword
There is a benefit in not allowing to get pointers to class members. It allows to have movable object instances and this give access to some faster GC algorithms like generational garbage collection which is in use in Java. As an old C++ programmer and newbee in D programming, the D constness and immutability concepts are confusing. They are so strong that I hardly see any use for them with objects. There would be a much wider use to be able to tell user that he may assume the object is constant from the interface point of view. This is a huge help in code readability and program validity checking. I had the impression that this is the principle used for the pure keyword. I would vote against the introduction of the mutable keyword as it exist in C++ because it is a half backed solution. First it tells the compiler that this variable is modifiable at any time by any method of the class. This is way I always felt uncomfortable using mutable. It punches a big hole in the constness protection. The other problem is with inheritance (I know it's old school, but ok). If a derived class needs to modify a member variable of a base class that wasn't declared mutable, you're stuck. That is why C++ introduced the const_cast. This is much better in that the hole in the constness protection is very limited, but the code is also less pleasant to read. How could be the D way to solve this ? My feeling is that it could be by introducing a mutate{...} block. All instructions in that block would be allowed to modify the const object. The developer intent would be clear, the code readable and the hole limited. The difference with the C++ model is that in C++ we switch off the constness flag of member variables for a persistent or short time, in D we would switch off constness control in a block of instructions. I didn't thought of all the implications yet. I only talked about const objects. I still need to find a use case for immutable objects /S
Re: Need a Faster Compressor
⬅ Download proof of concept This is a proof of concept micro-benchmark compressing the 37_640 bytes symbol from the bug report linked above with both id_compress from the dmd backend and lz4 (without dictionary). The lz4 result is additionally transformed to 7-bits similar to base-64. Original size: 37640 bytes id_compress : 5243 ms for 10_000 iterations, 800 bytes lz4 : 71 ms for 10_000 iterations, 389 bytes That roughly corresponds to a 2x higher compression ratio at 70x faster compression speed. -- Marco import std.bitmanip; import core.stdc.string; struct S(T) { void foo(){ throw new Exception("1");} } auto s(T)(T t) { struct Result { void foo(){ throw new Exception("2");} } return Result(); } void main() { import core.stdc.stdlib; import std.stdio; import std.datetime; string text = 1.s.s.s.s.s.s.s.s.s.s.foo.mangleof; writefln("Original size: %s", text.length); size_t comprSize, comprSize2; char* buffer; StopWatch sw; sw.start(); foreach (i; 0 .. 10_000) { buffer = cast(char*)malloc((LZ4_compressBound(text.length) * 8 + 6) / 7); comprSize = LZ4_compress_fast(text.ptr, buffer, text.length); comprSize2 = (comprSize * 8 + 6) / 7; foreach_reverse (k; 0 .. comprSize2) { size_t idx = k * 7 / 8; ubyte bit = k * 7 % 8; ubyte _7bit = buffer[idx] >> bit; if (bit > 1) _7bit |= buffer[idx+1] << (8 - bit); _7bit &= 0x7F; _7bit += '!'; buffer[k] = _7bit; } } sw.stop(); writefln("%s ms for 10_000 iterations", sw.peek.msecs); writefln("Compressed size: %s", comprSize2); writefln("Compressed bytes: %s", cast(ubyte[])buffer[0 .. comprSize2]); stdout.flush(); sw.start(); foreach (i; 0 .. 10_000) id_compress(text.ptr, text.length, ); sw.stop(); writefln("%s ms for 10_000 iterations", sw.peek.msecs); writefln("Compresed size (id_compress): %s", comprSize); } // Default value is 14, for 16KB, which nicely fits into Intel x86 L1 cache enum LZ4_MEMORY_USAGE = 14; enum LZ4_HASHLOG = LZ4_MEMORY_USAGE-2; enum HASH_SIZE_U32= (1 << LZ4_MEMORY_USAGE) / uint.sizeof; enum COPYLENGTH = 8; enum MINMATCH = 4; enum MFLIMIT = COPYLENGTH + MINMATCH; enum LZ4_minLength= MFLIMIT + 1; enum LASTLITERALS = 5; // Increase this value ==> compression run slower on incompressible data enum LZ4_skipTrigger = 6U; enum MAXD_LOG = 16; enum MAX_DISTANCE = (1 << MAXD_LOG) - 1; enum LZ4_MAX_INPUT_SIZE = 0x7E00; /* 2 113 929 216 bytes */ enum LZ4_64Klimit = 64*1024 + (MFLIMIT-1); enum tableType_t { byPtr, byU32, byU16 }; struct Token { mixin(bitfields!( size_t, "matchLength", 4, size_t, "literalLength", 4, )); } struct LZ4_stream { uint[HASH_SIZE_U32] hashTable; uint currentOffset; uint initCheck; const char* dictionary; uint dictSize; } size_t LZ4_compressBound(size_t isize) { return isize > LZ4_MAX_INPUT_SIZE ? 0 : isize + (isize/255) + 16; } ushort LZ4_read16(in void* memPtr) { ushort val16; memcpy(, memPtr, 2); return val16; } uint LZ4_read32(in void* memPtr) { uint val32; memcpy(, memPtr, 4); return val32; } size_t LZ4_read_ARCH(in void* p) { size_t result = void; memcpy(, p, (void*).sizeof); return result; } uint LZ4_hashSequence(size_t sequence, const tableType_t tableType) { immutable hashLog = (tableType == tableType_t.byU16) ? LZ4_HASHLOG+1 : LZ4_HASHLOG; version (D_LP64) { enum prime5bytes = 889523592379UL; immutable hashMask = (1<> 40 - hashLog) & hashMask; } else { return sequence * 2654435761 >> MINMATCH * 8 - hashLog; } } uint LZ4_hashPosition(in void* p, tableType_t tableType) { return LZ4_hashSequence(LZ4_read_ARCH(p), tableType); } void LZ4_putPositionOnHash(in char* p, uint h, ref LZ4_stream tableBase, const tableType_t tableType, in char* srcBase) { with (tableType_t) final switch (tableType) { case byPtr: const(char)** hashTable = cast(const(char)**)tableBase.hashTable.ptr; hashTable[h] = p; return; case byU32: uint* hashTable = cast(uint*)tableBase.hashTable.ptr; hashTable[h] = cast(uint) (p-srcBase); return; case byU16: ushort* hashTable = cast(ushort*)tableBase.hashTable.ptr; hashTable[h] = cast(ushort)(p-srcBase); return; } } void LZ4_putPosition(in char* p, ref LZ4_stream tableBase, const tableType_t tableType, in char* srcBase) { uint h = LZ4_hashPosition(p, tableType); LZ4_putPositionOnHash(p, h, tableBase, tableType, srcBase); } const(char*) LZ4_getPositionOnHash(uint h, ref const LZ4_stream
Re: Need a Faster Compressor
On Sunday, 22 May 2016 at 14:05:23 UTC, Marco Leise wrote: ⬅ Download proof of concept This is a proof of concept micro-benchmark compressing the 37_640 bytes symbol from the bug report linked above with both id_compress from the dmd backend and lz4 (without dictionary). The lz4 result is additionally transformed to 7-bits similar to base-64. Original size: 37640 bytes id_compress : 5243 ms for 10_000 iterations, 800 bytes lz4 : 71 ms for 10_000 iterations, 389 bytes That roughly corresponds to a 2x higher compression ratio at 70x faster compression speed. Please submit a PR.
Re: OpenGL with D tutorials
On Sunday, 22 May 2016 at 12:55:47 UTC, Guillaume Piolat wrote: On Sunday, 22 May 2016 at 12:13:07 UTC, ixid wrote: What is the best OpenGL tutorial with D to use? I've tried to use d-gamedev-intro and opengl-tutorials and seem to get errors, files that are no longer included are needed (dgl)? and deprecation messages. Not a tutorial by any means but this example program can get you started with the annoying "Modern" OpenGL: https://github.com/d-gamedev-team/gfm/blob/master/examples/simpleshader/simpleshader.d Thanks, I have tried to get all the libraries and link them and now get a huge number of error messages (I am almost certainly missing or have mis-installed something, it doesn't complain about failing to import anything though. SeverityCodeDescription Project FileLineSuppression State Error Error 42: Symbol Undefined _D3gfm4sdl26window10SDL2Window11swapBuffersMFZv (void gfm.sdl2.window.SDL2Window.swapBuffers()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D8derelict7opengl39functions7glClearPWNbNikZv C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl23sdl4SDL213processEventsMFZv (void gfm.sdl2.sdl.SDL2.processEvents()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl7program9GLProgram3useMFZv (void gfm.opengl.program.GLProgram.use()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl3vao5GLVAO6unbindMFZv (void gfm.opengl.vao.GLVAO.unbind()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl7program9GLProgram5unuseMFZv (void gfm.opengl.program.GLProgram.unuse()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D8derelict7opengl39functions10glViewportPWNbNiZv C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl28keyboard12SDL2Keyboard9isPressedMFiZb (bool gfm.sdl2.keyboard.SDL2Keyboard.isPressed(int)) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl26window10SDL2Window8setTitleMFAyaZv (void gfm.sdl2.window.SDL2Window.setTitle(immutable(char)[])) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm6opengl7program9GLProgram7uniformMFAyaZC3gfm6opengl7uniform9GLUniform (gfm.opengl.uniform.GLUniform gfm.opengl.program.GLProgram.uniform(immutable(char)[])) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4sdl23sdl4SDL28keyboardMFZC3gfm4sdl28keyboard12SDL2Keyboard (gfm.sdl2.keyboard.SDL2Keyboard gfm.sdl2.sdl.SDL2.keyboard()) C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D3gfm4math6matrix21__T6MatrixTfVii4Vii4Z6Matrix8identityFNaNbNiNfZS3gfm4math6matrix21__T6MatrixTfVii4Vii4Z6Matrix C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\ Error Error 42: Symbol Undefined _D8derelict4sdl29functions12SDL_GetTicksPUNbNiZk C:\Users\Adam\Documents\Visual Studio 2015\Projects\opengl\opengl\
Re: Need a Faster Compressor
On Sunday, 22 May 2016 at 12:12:09 UTC, Martin Nowak wrote: Yes, LZO, LZ4, or snappy would be good choices. They are real-time compression algorithms, i.e. it's faster to compress and write to main memory than w/o compression. Yes the LZ compressors are very good for this usecase Please don't write anything on your own. There is a meta library for those algorithms http://blosc.org/, for which I added Deimos headers http://code.dlang.org/packages/d-blosc. Agreed. The existing implementations have been fine-tuned for performance, and we should use them as leverage.
Re: Use Requests to send data to webpage - how?
On Friday, 20 May 2016 at 14:42:19 UTC, TheDGuy wrote: On Friday, 20 May 2016 at 09:21:33 UTC, Kagamin wrote: Does this work? Request rq = Request(); Response rs = rq.exec!"GET"("http://somewebpage.org/;, [parameter:data]); No :( If i call my SQL.php function directly with: Response rs = rq.exec!"GET"("http://site/SQL.php;, ["action":"insertTemp","value":"7"]); it works perfectly fine. But i don't understand why my html site does not get that request...Any ideas?
Re: mago-mi: Mago debugger GDB MI compatible interface
On Friday, 13 May 2016 at 15:28:55 UTC, Vadim Lopatin wrote: Hello, I'm working on GDB MI compatible interface for Mago debugger. ... Once ready, I'm planning to use it in DlangIDE under Windows. I hope some day it may be used instead of gdb and llvm-mi under Windows by other IDEs which are compatible with GDB MI interface. Thanks, I will add it to code-debug so Windows users can also debug their D programs in visual studio code.
Re: mutable keyword
On Sunday, May 22, 2016 09:42:54 Jack Applegame via Digitalmars-d-learn wrote: > On Saturday, 21 May 2016 at 21:49:23 UTC, Jonathan M Davis wrote: > > Rebindable is in kind of a weird grey area. It involves a > > union, not casting, and it's only ever mutating the class > > reference, not the object itself. Certainly, if it mutated the > > object, it would be undefined behavior, but it's just mutating > > the reference - but then again, the type system itself doesn't > > really differentiate between the two. So, I suspect that what > > it comes down to is that Rebindable is doing something that you > > really shouldn't, but because it's using a union rather than a > > cast, and it's so limited in what it's mutating, its behavior > > is effectively defined in the sense that the compiler has no > > leeway, but's probably still technically undefined. I don't > > know what Walter would say though. Certainly, if casting were > > involved, it would be undefined behavior without question, and > > it's not the sort of thing that you should be doing in your own > > code. > > > > [...] > > I agree. But I think we need something that allows *logical* > const and immutable. > Strict binding constness to physical memory constancy is not > always necessary and sometimes even harmful. Actually doing logical const/immutable isn't really possible. Not even C++ does that. Rather, it provides backdoors that you can then use to implement a sort of logical const, but there is zero guarantee that that's actually what's happening. It's completely a matter of convention at that point. At best, it would be possible to indicate that a portion of a type is const or immutable while allowing certain parts of it to be mutable, in which case, there are zero constness guarantees about the part that's always mutable and no guarantees that the stuff that's mutable isn't part of the logical state of the object. Given how const and immutable work in D, having any portion of them be treated as mutable, becomes highly problematic. It could theoretically be done by having to mark such variables with an attribute and mark such types with a similar attribute so that the compiler knows that the type in question is not really following the rules of const or immutable and thus doesn't make any assumptions about it like it would normally, but it risks getting rather complicated, and Walter is most definitely not in favor of such an idea. He is absolutely adamant that const is useless unless it's fully const with no backdoors whatsoever. So, I'd be very surprised if any kind of @mutable were added to the language. Certainly, you'd have to have a very strong technical reason to convince him otherwise, and odds are that he's just going to tell you to not use const, if it's not going to work for the type to be const. - Jonathan M Davis
Re: OpenGL with D tutorials
On Sunday, 22 May 2016 at 12:13:07 UTC, ixid wrote: What is the best OpenGL tutorial with D to use? I've tried to use d-gamedev-intro and opengl-tutorials and seem to get errors, files that are no longer included are needed (dgl)? and deprecation messages. Not a tutorial by any means but this example program can get you started with the annoying "Modern" OpenGL: https://github.com/d-gamedev-team/gfm/blob/master/examples/simpleshader/simpleshader.d
Re: Need a Faster Compressor
On Sunday, 22 May 2016 at 01:36:39 UTC, Walter Bright wrote: Just a note: large lookup tables can have cold cache performance problems. 16k lookup table are the gold standard.
Re: Need a Faster Compressor
On Saturday, 21 May 2016 at 21:12:15 UTC, Walter Bright wrote: The current one is effective, but slow: https://github.com/dlang/dmd/blob/master/src/backend/compress.c Anyone want to make a stab at making it faster? Changing the format is fair game, as well as down and dirty assembler if that's what it takes. So really, how good are you at fast code? Mandatory goldmine on compression: http://fastcompression.blogspot.fr/
Re: D plugin for Visual Studio Code
On Sunday, 22 May 2016 at 12:42:51 UTC, nazriel wrote: Bad in the sense that you are required to actually do the searching ;) And it breaks the convention used by other language plugins. So as you can see by the presence of this topic, plugin (which is really top notch btw) is easily overlooked When I made the plugin there was no convention because there were only some syntax highlighting packages and maybe 4 or 5 actual plugins for anything more than syntax highlighting. Any idea for a better plugin name? I can easily rename it in the marketplace and it will still be installable with `code-d`