Re: Need a Faster Compressor

[Marco Leise via Digitalmars-d]

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)

[Ali Çehreli via Digitalmars-d-announce]

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...

[Era Scarecrow via Digitalmars-d-learn]

 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?

[Mike Parker via Digitalmars-d-learn]

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

[via Digitalmars-d-bugs]

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?

[Jon Degenhardt via Digitalmars-d-learn]

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

[via Digitalmars-d-bugs]

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)

[via Digitalmars-d-bugs]

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

[Era Scarecrow via Digitalmars-d]

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

[Era Scarecrow via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[via Digitalmars-d-bugs]

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

[via Digitalmars-d-bugs]

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

[via Digitalmars-d-bugs]

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++

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16029

Adam D. Ruppe  changed:

   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

[via Digitalmars-d-bugs]

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

[David Nadlinger via Digitalmars-d-announce]

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

[Jonathan M Davis via Digitalmars-d]

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

[poliklosio via Digitalmars-d]

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?

[Ali Çehreli via Digitalmars-d-learn]

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

[Anon via Digitalmars-d]

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

[Michael Chen via Digitalmars-d]

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

[Johan Engelen via Digitalmars-d-announce]

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

[Andrei Alexandrescu via Digitalmars-d]

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

[Andrei Alexandrescu via Digitalmars-d]

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

[Andrei Alexandrescu via Digitalmars-d]

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

[WebFreak001 via Digitalmars-d]

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

[Xinok via Digitalmars-d]

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

[Rishub Nagpal via Digitalmars-d-learn]

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

[Richard Delorme via Digitalmars-d-announce]

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

[Joakim via Digitalmars-d-announce]

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

[David Nadlinger via Digitalmars-d-announce]

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

[via Digitalmars-d-bugs]

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?

[Sameer Pradhan via Digitalmars-d]

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

[Joakim via Digitalmars-d]

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

[Lass Safin via Digitalmars-d]

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?

[Daniel N via Digitalmars-d-learn]

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

[Sameer Pradhan via Digitalmars-d]

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15925

Kenji Hara  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--

[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored

[via Digitalmars-d-bugs]

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

[via Digitalmars-d-bugs]

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

[Dmitry via Digitalmars-d-announce]

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

[Walter Bright via Digitalmars-d]

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

[Bauss via Digitalmars-d-announce]

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

[Walter Bright via Digitalmars-d]

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

[Dmitry via Digitalmars-d]

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

[Era Scarecrow via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Sönke Ludwig via Digitalmars-d-announce]

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?

[Meta via Digitalmars-d-learn]

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

[Walter Bright via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15925

Walter Bright  changed:

   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

[via Digitalmars-d-bugs]

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?

[Jon Degenhardt via Digitalmars-d-learn]

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

[qznc via Digitalmars-d]

On Monday, 4 March 2013 at 19:11:17 UTC, Steven Schveighoffer 
wrote:
On Mon, 04 Mar 2013 12:35:23 -0500, Andrei Alexandrescu 
 wrote:



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

[Karabuta via Digitalmars-d-learn]

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

[David Nadlinger via Digitalmars-d-announce]

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

[Walter Bright via Digitalmars-d]

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

[Stefan Koch via Digitalmars-d]

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

[Rainer Schuetze via Digitalmars-d]

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

[Marco Leise via Digitalmars-d]

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

[Era Scarecrow via Digitalmars-d]

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

[WebFreak001 via Digitalmars-d]

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

[Rainer Schuetze via Digitalmars-d]

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

[Era Scarecrow via Digitalmars-d]

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

[poliklosio via Digitalmars-d]

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

[Rainer Schuetze via Digitalmars-d]

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?

[Era Scarecrow via Digitalmars-d-learn]

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

[Era Scarecrow via Digitalmars-d]

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

[Stefan Koch via Digitalmars-d]

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

[WebFreak001 via Digitalmars-d]

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

[via Digitalmars-d-bugs]

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

[via Digitalmars-d-bugs]

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

[via Digitalmars-d-bugs]

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

[Marco Leise via Digitalmars-d]

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

[Abdulhaq via Digitalmars-d-announce]

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

[poliklosio via Digitalmars-d]

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

[Joakim via Digitalmars-d]

On Sunday, 22 May 2016 at 09:45:05 UTC, Manu wrote:
On 22 May 2016 at 18:09, Xiaoxi via Digitalmars-d 
 wrote:

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

[via Digitalmars-d-bugs]

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

[Vadim Lopatin via Digitalmars-d-learn]

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

[Atila Neves via Digitalmars-d-announce]

On Saturday, 21 May 2016 at 13:51:11 UTC, Manu wrote:
On 21 May 2016 at 23:20, Andrei Alexandrescu via 
Digitalmars-d-announce  
wrote:

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

[via Digitalmars-d-bugs]

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

[via Digitalmars-d-bugs]

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

[Guillaume Piolat via Digitalmars-d-learn]

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

[via Digitalmars-d-bugs]

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

[chmike via Digitalmars-d-learn]

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

[Marco Leise via Digitalmars-d]

⬅ 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

[Stefan Koch via Digitalmars-d]

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

[ixid via Digitalmars-d-learn]

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

[Stefan Koch via Digitalmars-d]

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?

[TheDGuy via Digitalmars-d-learn]

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

[WebFreak001 via Digitalmars-d-debugger]

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

[Jonathan M Davis via Digitalmars-d-learn]

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

[Guillaume Piolat via Digitalmars-d-learn]

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

[deadalnix via Digitalmars-d]

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

[deadalnix via Digitalmars-d]

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

[WebFreak001 via Digitalmars-d]

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`