Re: Module Name Resolution

[ketmar via Digitalmars-d-learn]

On Wednesday, 26 October 2016 at 05:27:53 UTC, Jason C. Wells 
wrote:
Hence the repeated advice to supply all the filenames on the 
command line.


this is basically 'cause dmd doesn't automatically compile and 
link imported modules. it you won't specify module in dmd command 
line, dmd will only look for type declarations in that module, 
but will not compile any actual code from it. so the link stage 
fill fail, 'cause it will try to link with non-existing code. the 
easiest way to solve that is just pass all modules to dmd. or use 
rdmd -- it automatically process imports and invokes dmd with 
built module list (that is what i am using, for example).

Re: Module Name Resolution

[ketmar via Digitalmars-d-learn]

On Wednesday, 26 October 2016 at 04:51:23 UTC, Jason C. Wells 
wrote:

I am reading through Ketmar's iv.d/nanovg/package.d:

  module iv.nanovg;
  public import iv.nanovg.nanovg;

This looks like three levels of hierarchy, but is it?


it maps to "iv/nanovg/nanovg.d" according to dmd map rules. i 
used to have all the code in package.d, but later moved it out to 
nanovg.d.


i.e. last name is always a file, everything before it is a 
directory.


I'm a little confused because the corresponding directory in 
ketmar's source code is named "iv.d" rather than "iv" which is 
what I would have thought to find based on the import.


this is a repository name. it is supposed to be named just "iv", 
and git names main directory by repository name if you are doing 
a simple clone. my bad, i should have made that clear.


I see mention of a subpackage in my previous thread. Is this 
how a subpackage is implemented?


actually, packages and subpackages are just a convenient terms 
for something that is not strictly defined in D. this is more a 
convention: if we'll place all the files in directory, say, 
"mypkg/a.d", "mypkg/b.d", and add package.d there as 
"mypkg/package.d", then we'll be able to just write "import 
mypkg;". dmd will automatically look for "mypkg/package.d" in 
this case.


so, when you're writing "import iv.nanovg;", dmd looks for 
"iv/nanovg/package.d", and process it. package.d does more 
imports, so dmd loads 'em too. the only magic here is special 
"package.d" file.

Re: Can we get unitests to not run with program start ?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, October 26, 2016 05:24:45 deadalnix via Digitalmars-d wrote:
> Seriously that makes no sense, almost everybody has it own hack
> to have a different main when building for unitests, and we look
> like clown.
>
> We all like to talk about language feature and all, but
> seriously, this kind of thing is what hurts us the most. We kind
> of live with it because we all have our workaround here, but
> really, it looks stupid to anyone that don't the tricks, and
> really, it should looks silly to anyone that knows the trick.
>
> Can I have my unittest build do not complain if there is no main
> and not run main ?

Ideally, the -unittest build would just replace main (whatever it was) or
run something instead of main without actually starting main, and if there
were no main, it wouldn't complain about the lack thereof.

That being said, using -main when unit testing libraries and declaring main
in applications to look something like

version(unittest) void main() {}
else int main(string[] args) {...}

doesn't seem like all that big a deal to me. Not ideal, but not a big deal.

Regardless, I really don't think that it ever makes sense to actually run
main after running the unit tests. So, in that sense, what dmd does with
-unittest is downright weird. I assume that it just seemed like the easiest
way to integrate them though and that that's why it was done that way. And I
wouldn't mind it if it were fixed so that declaring main for unit tests was
not required and that main never actually ran after the unit tests. However,
I bet that if we changed it, _someone_ would complain. Someone always does,
even if the change makes perfect sense and the previous behavior didn't.

- Jonathan M Davis

Re: Module Name Resolution

[Jason C. Wells via Digitalmars-d-learn]

Suddenly it occurs to me that the module namespace and the 
filesystem namespace do not necessarily have a one for one match, 
even though they do by default. When one specifies all the D 
source files on the command line, any differences between the 
module namespace and the filesystem namespace are handled 
automagically by dmd. The "module" declaration is the code by 
which the module namespace is manually defined.


Hence the repeated advice to supply all the filenames on the 
command line.

Can we get unitests to not run with program start ?

[deadalnix via Digitalmars-d]

Seriously that makes no sense, almost everybody has it own hack 
to have a different main when building for unitests, and we look 
like clown.


We all like to talk about language feature and all, but 
seriously, this kind of thing is what hurts us the most. We kind 
of live with it because we all have our workaround here, but 
really, it looks stupid to anyone that don't the tricks, and 
really, it should looks silly to anyone that knows the trick.


Can I have my unittest build do not complain if there is no main 
and not run main ?

Module Name Resolution

[Jason C. Wells via Digitalmars-d-learn]

I am reading through: https://dlang.org/spec/module.html. I'll 
soon be working through a previous example provided by Mike 
Parker.


I am reading through Ketmar's iv.d/nanovg/package.d:

  module iv.nanovg;
  public import iv.nanovg.nanovg;

This looks like three levels of hierarchy, but is it?

Should I interpret that import as:

iv
 --nanovg
--nanovg

Perhaps it really means:

iv.nanovg
  --nanovg

I'm a little confused because the corresponding directory in 
ketmar's source code is named "iv.d" rather than "iv" which is 
what I would have thought to find based on the import.


I see mention of a subpackage in my previous thread. Is this how 
a subpackage is implemented?


Thanks,
Jason

Re: Battle-plan for CTFE

[Stefam Koch via Digitalmars-d-announce]

On Tuesday, 25 October 2016 at 17:19:26 UTC, Jacob Carlborg wrote:


Very impressive :)


Thanks.

I just got the following code to compile and execute correctly.

bool strEq(string a, string b)
{
if (a.length != b.length)
{
return false;
}
uint length = cast(uint) a.length;

while(length--)
{
auto c1 = a[length];
auto c2 = b[length];
if (c1 != c2)
{
return false;
}
}

return true;
}

static assert(!strEq("Hello","World"));
static assert(strEq("World","World"));

I used the generated bytecode to make == for strings work.

Re: Linus' idea of "good taste" code

[H. S. Teoh via Digitalmars-d]

On Tue, Oct 25, 2016 at 03:53:54PM -0700, Walter Bright via Digitalmars-d wrote:
> It's a small bit, but the idea here is to eliminate if conditionals where 
> possible:
> 
> https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e
> 
> This is something we could all do better at. Making code a straight
> path makes it easier to reason about and test.

Not only easier to reason about, but probably performs better too.
Conditionals introduce pipeline hazards. (Though, arguably, not very
significant here because the loop would dominate the running time.)


> Eliminating loops is something D adds, and goes even further to making
> code a straight line.
> 
> One thing I've been trying to do lately when working with DMD is to
> separate code that gathers information from code that performs an
> action. (The former can then be made pure.) My code traditionally has
> it all interleaved together.

Separation of concerns is a typical "good taste" practice. It's why the
range-based pipeline idiom is so effective. When you compound multiple
concerns into a single piece of code, it inevitably gets tangled into a
complex mess that has lots of room for bugs to hide in. It's that whole
philosophy with Jackson Structured Programming again: make your code
structure 1-to-1 with your data structure, and edge cases and ad hoc
complexities vanish, along with their respective bug potentials.

If the input structure doesn't match the code structure for whatever
reason, say for algorithmic reasons, the best approach is to transform
the data into a matching structure first, then operate on it. I.e., your
"gather data, then operate on it" idea.  Trying to do both at the same
time typically leads to well-known warning signs: boolean flags,
recycled variables with conflicting meanings, proliferating
if-statements, complex looping conditions, etc., all the result of ad
hoc attempts at resolving the structure conflict between data and code.


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you 
wish you hadn't.

Re: Namespace for a module defined by its import path

[Mike Parker via Digitalmars-d]

On Tuesday, 25 October 2016 at 22:25:51 UTC, Jeff Thompson wrote:
On Tuesday, 25 October 2016 at 19:54:42 UTC, Jonathan Marler 
wrote:
On Tuesday, 25 October 2016 at 06:47:14 UTC, Jeff Thompson 
wrote:

[...]


Sorry if I didn't understand something, couldn't you do this?

/commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/version/lib.d
/commit_df0741a84c8a967ea08674090afdff4e9a58d23e/version/lib.d


If I do that, can lib.d avoid the following module statement?
module 
commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94.version.lib


dmd -I/commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/version/ 
main.d
dmd -I//commit_df0741a84c8a967ea08674090afdff4e9a58d23e/version/ 
main.d

Re: The DLang UPB Languages and Systems Research Scholarship

[Mike Parker via Digitalmars-d-announce]

On Tuesday, 25 October 2016 at 22:15:38 UTC, Andrei Alexandrescu 
wrote:
The D Language Foundation is proud to announce its first 
scholarship, offered to CS and EE students at University 
"Politehnica" Bucharest in Romania. More details here:


http://dlang.org/dlangupb-scholarship.html


For anyone tempted to share this on /r/programming, please wait! 
I hope to do a blog post about this on Friday, so I'll post to 
reddit then. Thanks!

Re: Linus' idea of "good taste" code

[bluecat via Digitalmars-d]

On Tuesday, 25 October 2016 at 22:53:54 UTC, Walter Bright wrote:
It's a small bit, but the idea here is to eliminate if 
conditionals where possible:


https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e

This is something we could all do better at. Making code a 
straight path makes it easier to reason about and test.


Eliminating loops is something D adds, and goes even further to 
making code a straight line.


One thing I've been trying to do lately when working with DMD 
is to separate code that gathers information from code that 
performs an action. (The former can then be made pure.) My code 
traditionally has it all interleaved together.


Interesting, that's going in my tips.txt file. Quick question, if 
you don't mind. What would be the top three things you've learned 
that significantly made you a better programmer?

Linus' idea of "good taste" code

[Walter Bright via Digitalmars-d]

It's a small bit, but the idea here is to eliminate if conditionals where 
possible:

https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e

This is something we could all do better at. Making code a straight path makes 
it easier to reason about and test.


Eliminating loops is something D adds, and goes even further to making code a 
straight line.


One thing I've been trying to do lately when working with DMD is to separate 
code that gathers information from code that performs an action. (The former can 
then be made pure.) My code traditionally has it all interleaved together.

Re: vibe.d with explicit threads/threadpool instead of fibers

[Arun Chandrasekaran via Digitalmars-d-learn]

On Tuesday, 25 October 2016 at 21:23:21 UTC, Arun Chandrasekaran 
wrote:
I am looking for a RESTful framework in D, which can interact 
with an existing backend processes (C++) via ZeroMQ and shared 
memory. I thought vibe.d might be a viable option. But I 
discussed with someone on Freenode #d and found that vibe.d 
doesn't support explicit threading [1].


I looked at vibe.d examples, one of them uses futures [1], which 
implies explicit thread handling is possible. But I'm not sure 
about pre-spawned threadpool.


[1] 
https://github.com/rejectedsoftware/vibe.d/blob/master/examples/future/source/app.d

Re: Namespace for a module defined by its import path

[Jeff Thompson via Digitalmars-d]

On Tuesday, 25 October 2016 at 19:54:42 UTC, Jonathan Marler 
wrote:
On Tuesday, 25 October 2016 at 06:47:14 UTC, Jeff Thompson 
wrote:

[...]


Sorry if I didn't understand something, couldn't you do this?

/commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/version/lib.d
/commit_df0741a84c8a967ea08674090afdff4e9a58d23e/version/lib.d


If I do that, can lib.d avoid the following module statement?
module commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94.version.lib

The DLang UPB Languages and Systems Research Scholarship

[Andrei Alexandrescu via Digitalmars-d-announce]

The D Language Foundation is proud to announce its first scholarship, 
offered to CS and EE students at University "Politehnica" Bucharest in 
Romania. More details here:


http://dlang.org/dlangupb-scholarship.html

We are very excited about this program and hope to extend it to other 
universities in the future.



Thanks,

Andrei

Re: Reducing the cost of autodecoding

[safety0ff via Digitalmars-d]

On Tuesday, 25 October 2016 at 21:46:30 UTC, safety0ff wrote:


P.S. I am aware that this pessimises popFront for code which 
only counts codepoints without inspecting them.


Unfortunately it also changes the API of popFront to throw on 
invalid characters.


So the example would need to be reworked.

Re: Reducing the cost of autodecoding

[safety0ff via Digitalmars-d]

On Wednesday, 12 October 2016 at 13:53:03 UTC, Andrei 
Alexandrescu wrote:


Now it's time to look at the end-to-end cost of autodecoding.


Some food for thought:

- front necessarily needs to compute the number of bytes to 
advance.
- We can't change the API to share data between front and 
popFront, however we can create a situation where a pure function 
gets duplicate calls removed by the compiler.


Since we require that the ascii test gets inlined into the caller 
of front/popFront to improve ascii performance, we have a 
situation similar to this:


alias Result = Tuple!("codepoint",dchar,"advance",int);
auto decode(const char[] str) pure
{ pragma(inline,true);
  if (str[0] < 0x80) return Result(str[0],1);
  else return decodeNonAscii(str);
}

dchar front(const char[] str) pure
{ pragma(inline,true);
  return str.decode.codepoint;
}

void popFront(ref const(char)[] str)
{ pragma(inline,true);
  return str[str.decode.advance..$];
}

When used in front/popFront pairs, the duplicated decode calls 
get merged and we don't do any duplicate work (unlike the current 
situation.)


Unfortunately, it's not possible to achieve the best code 
generation due to missed optimizations by the compilers (I 
haven't tried GDC.)
I've reported a highly reduce case to LDC github issue #1851 / 
LDC subforum.


Once we have this is possible only the decodeNonAscii, perhaps 
using the DFA method linked by ketmar.


P.S. I am aware that this pessimises popFront for code which only 
counts codepoints without inspecting them.

vibe.d with explicit threads/threadpool instead of fibers

[Arun Chandrasekaran via Digitalmars-d-learn]

I am looking for a RESTful framework in D, which can interact 
with an existing backend processes (C++) via ZeroMQ and shared 
memory. I thought vibe.d might be a viable option. But I 
discussed with someone on Freenode #d and found that vibe.d 
doesn't support explicit threading [1].


Can someone confirm the behaviour?
Is it not possible to allocate a bunch of threads or a threadpool 
for vibe.d to work with?


PS: We have this working already with C++ only solution where the 
frontend communication happens on protobuf over ZeroMQ. I'm just 
trying to migrate it to RESTful interface.


[1] http://pastebin.com/cAw2yaYg

Re: Namespace for a module defined by its import path

[Jonathan Marler via Digitalmars-d]

On Tuesday, 25 October 2016 at 06:47:14 UTC, Jeff Thompson wrote:
On Tuesday, 25 October 2016 at 00:42:59 UTC, Adam D. Ruppe 
wrote:

[...]


A variant of this is where the version name is the Git commit 
hash. Instead of "version1" and "version2" it is:


/commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/lib.d
/commit_df0741a84c8a967ea08674090afdff4e9a58d23e/lib.d

The file lib.d can't contain its own commit hash, so I can't 
put it in the module declaration. And different parts of the 
application rely on different versions so I need different 
application files to be able to import one or the other without 
conflict. I'm trying to escape the situation where a piece of 
code needs to know the path which the operating system uses to 
load it.


Sorry if I didn't understand something, couldn't you do this?

/commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/version/lib.d
/commit_df0741a84c8a967ea08674090afdff4e9a58d23e/version/lib.d

Re: Reducing the cost of autodecoding

[Steven Schveighoffer via Digitalmars-d]

On 10/25/16 3:32 PM, Stefam Koch wrote:

On Tuesday, 25 October 2016 at 19:16:07 UTC, Steven Schveighoffer wrote:



Should behave better on 32-bit system.

You could also store 3-bits to avoid extra addition.

The whole point of a LUT to begin with is to reduce instructions.



Yes, I know. But as I understand it, using 64-bit math on 32-bit systems 
is expensive also. Maybe not in this case...


-Steve

Re: Reducing the cost of autodecoding

[Stefam Koch via Digitalmars-d]

On Tuesday, 25 October 2016 at 19:16:07 UTC, Steven Schveighoffer 
wrote:

On 10/25/16 12:57 PM, Dmitry Olshansky wrote:

On 10/12/16 3:53 PM, Andrei Alexandrescu wrote:

So we've had a good run with making popFront smaller. In ASCII
microbenchmarks with ldc, the speed is indistinguishable from 
s = s[1 ..
$]. Smaller functions make sure that the impact on 
instruction cache in

larger applications is not high.

[snip]
Your mission, should you choose to accept it, is to define a 
combination

front/popFront that reduces the gap.



I'm sooo late to the party. Still a neat trick with UTF lookup 
table is
to cram it into a single word with bit packing. Since we only 
ever
consider top 5 bits of leading byte of which the top one can 
be safely
discarded with a quick < 0x80 check. This leaves us at 4bits 
-> 16 entry

table, fits nicely in a 64-bit word with 4bits per entry.


Half of the entries in your table are 0 (every char that starts 
with 10). In addition, you only need 2 bits to store the length 
(max byte sequence is 4, subtract 1 from sequence to get 2 
bits).


So I think you can fit this into a 16-bit word (8 entries of 2 
bits each). You just need to pre-check for the invalid 
sequences (you no longer have to check for 0 result):


if(c < 0x80) s = s[1 .. $];
else if(c < 0xc0 || c > 0xf7) throw new Exception("blah");
else s = s[1 + myStride(c) .. $];

Should behave better on 32-bit system.

You could also store 3-bits to avoid extra addition.

-Steve


The whole point of a LUT to begin with is to reduce instructions.

Re: Reducing the cost of autodecoding

[Steven Schveighoffer via Digitalmars-d]

On 10/25/16 12:57 PM, Dmitry Olshansky wrote:

On 10/12/16 3:53 PM, Andrei Alexandrescu wrote:

So we've had a good run with making popFront smaller. In ASCII
microbenchmarks with ldc, the speed is indistinguishable from s = s[1 ..
$]. Smaller functions make sure that the impact on instruction cache in
larger applications is not high.

[snip]

Your mission, should you choose to accept it, is to define a combination
front/popFront that reduces the gap.



I'm sooo late to the party. Still a neat trick with UTF lookup table is
to cram it into a single word with bit packing. Since we only ever
consider top 5 bits of leading byte of which the top one can be safely
discarded with a quick < 0x80 check. This leaves us at 4bits -> 16 entry
table, fits nicely in a 64-bit word with 4bits per entry.


Half of the entries in your table are 0 (every char that starts with 
10). In addition, you only need 2 bits to store the length (max byte 
sequence is 4, subtract 1 from sequence to get 2 bits).


So I think you can fit this into a 16-bit word (8 entries of 2 bits 
each). You just need to pre-check for the invalid sequences (you no 
longer have to check for 0 result):


if(c < 0x80) s = s[1 .. $];
else if(c < 0xc0 || c > 0xf7) throw new Exception("blah");
else s = s[1 + myStride(c) .. $];

Should behave better on 32-bit system.

You could also store 3-bits to avoid extra addition.

-Steve

Re: getting started with web server - vibe.d dub giving link error

[Karabuta via Digitalmars-d-learn]

On Monday, 24 October 2016 at 04:46:34 UTC, aman wrote:

On Sunday, 23 October 2016 at 19:23:04 UTC, Karabuta wrote:

[...]


Oh, I see. Actually it got installed auto-magically during dub 
installation I guess. Now I installed dmd with the script 
mention on the dlang download page.

curl -fsS https://dlang.org/install.sh | bash -s dmd

[...]


Make sure you install all the vibe.d dependencies. You can refer 
to my blog post at 
https://aberba.github.io/2016/hello-world-app-with-the-vibe.d-web-framework/ under the "Setting up your development environment" section.

Re: Battle-plan for CTFE

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-10-25 14:36, Stefam Koch wrote:


First perf data is in

The is measured with time src/dmd -c -ctfe-bc

old interpreter (without -ctfe-bc) :

real0m6.839s
user0m6.423s
sys0m0.407s

new interpreter (-ctfe-bc)

real0m0.549s
user0m0.547s
sys0m0.000s

LLVM Backend (-ctfe-bc -version=UseLLVMBackend) :

real0m0.039s
user0m0.027s
sys0m0.010s


The compiled code was :
int bug6498(int x)
{
int n = 0;
while (n < x)
++n;
return n;
}
static assert(bug6498(10_000_000)==10_000_000);


Very impressive :)

--
/Jacob Carlborg

Re: Reducing the cost of autodecoding

[Dmitry Olshansky via Digitalmars-d]

On 10/12/16 3:53 PM, Andrei Alexandrescu wrote:

So we've had a good run with making popFront smaller. In ASCII
microbenchmarks with ldc, the speed is indistinguishable from s = s[1 ..
$]. Smaller functions make sure that the impact on instruction cache in
larger applications is not high.

[snip]

Your mission, should you choose to accept it, is to define a combination
front/popFront that reduces the gap.



I'm sooo late to the party. Still a neat trick with UTF lookup table is 
to cram it into a single word with bit packing. Since we only ever 
consider top 5 bits of leading byte of which the top one can be safely 
discarded with a quick < 0x80 check. This leaves us at 4bits -> 16 entry 
table, fits nicely in a 64-bit word with 4bits per entry.


// construct in-word lookup table
ulong bitTable()
{
import std.utf;
ulong table;
for(size_t i = 128; i<256; i+= 8)
{
char[1] c = [ cast(char)i ];
try{
ulong s = std.utf.stride(c[0..1], 0);
table |= s<<(4*((i-128)>>3));
}
catch(Exception){
// keep zeros
}
}
return table;
}

uint myStride()(char c)
{
enum table = bitTable;
return (table >> ((c & 0x7f) >> 3)) & 0xF;
}

void myPopFront()(ref char[] s)
{
char c = s[0];
if(c < 0x80)
s = s[1..$];
else {
uint step = myStride(c);
if(!step) throw new Exception("blah");
s = s[step..$];
}
}

Accordingly myFront could be modified to use the same technique.
Can't check perf with LDC at the moment sadly.



Andrei

Re: Battle-plan for CTFE

[Stefam Koch via Digitalmars-d-announce]

On Tuesday, 25 October 2016 at 15:57:33 UTC, Wyatt wrote:

On Tuesday, 25 October 2016 at 12:36:56 UTC, Stefam Koch wrote:

LLVM Backend (-ctfe-bc -version=UseLLVMBackend) :

real0m0.039s
user0m0.027s
sys 0m0.010s


I think 20,000% is a pretty good speedup! ;)  Great stuff.

Now that JIT works, are you returning to focusing on feature 
coverage?


-Wyatt


Yes I have already started on solidifying struct, string and 
slice support.

Once this is done, most of the ctfe system is in place.
The rest will be costmetics.
Make no mistake structs and slices may seem trivial but there are 
a few complxities hiding involved.
Particularly handling of the this pointer and accsess to 
member-variables.

Slices require a proper memory mangament system to be in place.
All of this needs to be platform agnostic and representable in 
bytecode.

[Issue 5243] dmd -run potentially removes user files

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|edi33...@gmail.com

--

[Issue 4851] Three suggestions for std.random

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|edi33...@gmail.com

--

Re: Battle-plan for CTFE

[Wyatt via Digitalmars-d-announce]

On Tuesday, 25 October 2016 at 12:36:56 UTC, Stefam Koch wrote:

LLVM Backend (-ctfe-bc -version=UseLLVMBackend) :

real0m0.039s
user0m0.027s
sys 0m0.010s


I think 20,000% is a pretty good speedup! ;)  Great stuff.

Now that JIT works, are you returning to focusing on feature 
coverage?


-Wyatt

Re: Neural Networks / ML Libraries for D

[Saurabh Das via Digitalmars-d-learn]

On Tuesday, 25 October 2016 at 14:31:39 UTC, bachmeier wrote:

On Tuesday, 25 October 2016 at 13:58:33 UTC, Saurabh Das wrote:


[...]


Installation amounts to installing a couple of R packages that 
I have on Bitbucket, as described on the project page. I have 
basic usage examples there as well. You can find the project 
here:

https://bitbucket.org/bachmeil/embedr

[...]


This is excellent. I will try it out :) Thanks so much.

Re: Review manager wanted: core.vmm

[Dicebot via Digitalmars-d]

On Tuesday, 25 October 2016 at 15:08:14 UTC, Dmitry Olshansky 
wrote:

Hi, have you found a review manager yet?


No, the NG was rather silent, so sill looking for one.


As it is a runtime module and not Phobos, I'd be willing to 
volunteer - but only quite some time later (probably about 1 
month). Ping me via e-mail if no one else comes by that time.

Re: Review manager wanted: core.vmm

[Dmitry Olshansky via Digitalmars-d]

On 10/25/16 2:39 PM, Guillaume Piolat wrote:

On Saturday, 15 October 2016 at 14:08:25 UTC, Dmitry Olshansky wrote:

The module aims to provide portable interface to virtual memory
management unit of the OS. Some common recipes such as locking memory
and allocating executable memory should be easily accessible.

In general the task is next to impossible and therefore capabilities
of the current OS are captured into manifest constant to allow for
conditional adaptation to them (static ifs etc).

https://github.com/dlang/druntime/pull/1549

---
Dmitry Olshansky


Hi, have you found a review manager yet?


No, the NG was rather silent, so sill looking for one.

Re: Real Simple Question?

[Steven Schveighoffer via Digitalmars-d-learn]

On 10/22/16 5:34 PM, WhatMeWorry wrote:

On Saturday, 22 October 2016 at 20:51:14 UTC, Jonathan M Davis wrote:

On Saturday, October 22, 2016 20:35:27 WhatMeWorry via
Digitalmars-d-learn wrote:

[...]


Just put it in a separate module and then import it. e.g.

file: mypackage/constants.d
==
module mypackage.constants;

GLfloat[] vertices =
[
  // Positions  // Texture Coords
  -0.5f, -0.5f, -0.5f,  0.0f, 0.0f,
   0.5f, -0.5f, -0.5f,  1.0f, 0.0f,
   .
   (lots and lots of values)
   .
];


I would make this:

immutable GLfloat[] vertices

If you can do it. This will make it so it's a) accessible from pure 
functions, and b) will not create a separate thread-local copy for each 
thread (if you use threading).



Ok, but now I'm getting these error in my new mypackage/constants.d

...\common\vertex_data.d(5,15): Error: undefined identifier 'GLfloat'
...\common\vertex_data.d(53,12): Error: undefined identifier 'vec3'


It's difficult to know why without more code hints, but it appears that 
vertex_data.d needs to import the module that defines these types. Note 
that if you want to have an imported module provide these definitions 
from another module, then you need to public import the module.


So for instance (guessing at your code, since I don't know what you have 
for import statements):


mypackage/my_types.d:

alias GLfloat = float;
alias vec3 = GLfloat[3];

mypackage/constants.d:

public import mypackage.my_types; // this allows importers of 
constants.d to see the types used


GLfloat[] vertices = ...

vertex_data.d:

import mypackage.constants; // pulls in definitions from my_types.d

-Steve

Re: New to D

[Steven Schveighoffer via Digitalmars-d-learn]

On 10/22/16 1:25 AM, Mark wrote:

Hello, Im a 3rd year Comp Sci student in Edmonton Alberta, Canada.

Ive learned how to use C, and dabbled in C++ in school. Im also in a Oop
course using Java.

I picked up the book The D Programming Language by Alexrei Alexandrescu
a few years ago.
Lately Im really wanting to get into D, as It seems like a better
version of C, and feels like java in a way.



However;

Ive run into a bit of a problem while writing some code. Im not sure if
Im doing something wrong, or maybe the things Im using are depreciated??

Code Blocks does not give any messages as to what is going wrong. I
haven't configured anything, and am not familiar with messing around
with IDE settings.

Its directly based off of the example on page 8.

here is the code that does not compile:


import std.stdio, std.string;

void main() { ... }

void dict() {

uint[string] dictionary;

foreach(line; stdin.byLine()) {

//chunk = splitter(strip(line); ## errors because of splitter

foreach(word; splitter(strip(line))) { ## errors because of
splitter ??

if(word in dictionary) continue;

//writeln(dictionary.length);  ## gives 0 ??

auto newID = dictionary.length;
dictionary[word] = newId;


I will note, that in addition to the other comments, this is going to 
result in corruption. Simply put, the buffer that `line` uses is reused 
for each line. So the string data used inside the associative array is 
going to change. This will result in not finding words already added 
when using the `word in dictionary` check.


You need to use dictionary[word.idup] = newId; This will duplicate the 
line into a GC string that will live as long as the AA uses it.


Alternatively, you can use byLineCopy, but this needlessly copies the 
line for each iteration, when you may find all the words in the line are 
already added.


-Steve

Re: Neural Networks / ML Libraries for D

[bachmeier via Digitalmars-d-learn]

On Tuesday, 25 October 2016 at 13:58:33 UTC, Saurabh Das wrote:



Oh that sounds pretty cool.

While I probably won't use it right now, embedding R inside D 
would be a good learning opportunity. Is it available on 
code.dlang.org or on GitHub?


Thanks
Saurabh


Installation amounts to installing a couple of R packages that I 
have on Bitbucket, as described on the project page. I have basic 
usage examples there as well. You can find the project here:

https://bitbucket.org/bachmeil/embedr

This is barebones, designed only to allow passing of data (via 
pointers) between the two languages and to execute R code from a 
D program. I have other libraries that do various things (call D 
functions from R, optimization, quadratic programming, ARMA 
estimation, etc.) but haven't yet had time to write examples or 
documentation. If you would like to see any of that or have 
questions about the embedr library, you can email me at the 
address given on this page:

http://www.k-state.edu/economics/staff/bios/bachmeier.html

Re: Neural Networks / ML Libraries for D

[Andrea Fontana via Digitalmars-d-learn]

On Tuesday, 25 October 2016 at 13:56:45 UTC, Saurabh Das wrote:
On Tuesday, 25 October 2016 at 11:55:27 UTC, maarten van damme 
wrote:
There is mir https://github.com/libmir/mir which is geared 
towards machine learning, I don't know if it has anything 
about neural networks, I've yet to use it. If you're only 
interested in neural networks, I've used FANN (a C library) 
together with D and it worked very well.


2016-10-25 13:17 GMT+02:00 Saurabh Das via Digitalmars-d-learn 
< digitalmars-d-learn@puremagic.com>:



Hello,

Are there any good ML libraries for D? In particular, looking 
for a neural network library currently. Any leads would be 
appreciated.


Thanks,
Saurabh


I saw mir but it didn't seem to have anything for NNs. I'll 
give FANN a try.


I used FANN with D too. And it's quite easy to use.

Andrea

[Issue 5236] [patch] std.format.formattedRead/unformatValue does not support the raw reading of integer types

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

   Assignee|and...@erdani.com   |razvan.nitu1...@gmail.com

--

Re: Neural Networks / ML Libraries for D

[Saurabh Das via Digitalmars-d-learn]

On Tuesday, 25 October 2016 at 13:26:49 UTC, bachmeier wrote:

On Tuesday, 25 October 2016 at 11:17:29 UTC, Saurabh Das wrote:

Hello,

Are there any good ML libraries for D? In particular, looking 
for a neural network library currently. Any leads would be 
appreciated.


Thanks,
Saurabh


I have written a project to embed R inside D and vice versa for 
my research (currently Linux only). Any neural network library 
for R is trivially available inside D. Ideally these libraries 
would be written in D but I'm a strong believer in reusing 
working code. If this is something that is of interest, let me 
know.


Oh that sounds pretty cool.

While I probably won't use it right now, embedding R inside D 
would be a good learning opportunity. Is it available on 
code.dlang.org or on GitHub?


Thanks
Saurabh

Re: Neural Networks / ML Libraries for D

[Saurabh Das via Digitalmars-d-learn]

On Tuesday, 25 October 2016 at 11:55:27 UTC, maarten van damme 
wrote:
There is mir https://github.com/libmir/mir which is geared 
towards machine learning, I don't know if it has anything about 
neural networks, I've yet to use it. If you're only interested 
in neural networks, I've used FANN (a C library) together with 
D and it worked very well.


2016-10-25 13:17 GMT+02:00 Saurabh Das via Digitalmars-d-learn 
< digitalmars-d-learn@puremagic.com>:



Hello,

Are there any good ML libraries for D? In particular, looking 
for a neural network library currently. Any leads would be 
appreciated.


Thanks,
Saurabh


I saw mir but it didn't seem to have anything for NNs. I'll give 
FANN a try.

Re: Real Simple Question?

[tcak via Digitalmars-d-learn]

On Saturday, 22 October 2016 at 21:34:36 UTC, WhatMeWorry wrote:
On Saturday, 22 October 2016 at 20:51:14 UTC, Jonathan M Davis 
wrote:

[...]


Ok, but now I'm getting these error in my new 
mypackage/constants.d


..\common\vertex_data.d(5,15): Error: undefined identifier 
'GLfloat'
..\common\vertex_data.d(53,12): Error: undefined identifier 
'vec3'


Is there a way to just suck in the text from say a .txt file 
that would not be compiled before inclusion in main.d?


You could format your array in JSON format, and read it in your 
program. That could be another solution.

[Issue 16590] Wrong di generation for ref methods

[via Digitalmars-d-bugs]

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

--- Comment #7 from Satoshi  ---
Attributes are stripped from destrutors.

e.g.
~this() @trusted { ... }

to 
~this();

--

[Issue 1761] TypeInfo.toString for function types always indicates no-parameter function

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|lucia.mcojoc...@gmail.com

--

[Issue 768] A switch to print predefined version identifiers

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

   Assignee|bugzi...@digitalmars.com|alexandru.razva...@gmail.co
   ||m

--

[Issue 16590] Wrong di generation for ref methods

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||and...@erdani.com
   Assignee|nob...@puremagic.com|razvan.nitu1...@gmail.com

--

[Issue 16590] Wrong di generation for ref methods

[via Digitalmars-d-bugs]

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

--- Comment #6 from Satoshi  ---
class Foo {
immutable(Foo) Dummy = new immutable(Foo);

private immutable pure nothrow @nogc @safe this() {

}

}


this() has stripped body and compiler thrown an error

"cannot be constructed at compile time, because the constructor has no
available source code"

--

Re: Neural Networks / ML Libraries for D

[bachmeier via Digitalmars-d-learn]

On Tuesday, 25 October 2016 at 11:17:29 UTC, Saurabh Das wrote:

Hello,

Are there any good ML libraries for D? In particular, looking 
for a neural network library currently. Any leads would be 
appreciated.


Thanks,
Saurabh


I have written a project to embed R inside D and vice versa for 
my research (currently Linux only). Any neural network library 
for R is trivially available inside D. Ideally these libraries 
would be written in D but I'm a strong believer in reusing 
working code. If this is something that is of interest, let me 
know.

Re: Bug in header file generation

[Daniel Kozak via Digitalmars-d]

Last two are ok, I do not see any error


Dne 25.10.2016 v 15:24 Satoshi via Digitalmars-d napsal(a):

I posted 3 more bugs what I found.
Seriously, can someone fix these bugs, please?

Thanks!


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

Re: Bug in header file generation

[Satoshi via Digitalmars-d]

I posted 3 more bugs what I found.
Seriously, can someone fix these bugs, please?

Thanks!


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

Re: Bug in std.allocator?

[ag0aep6g via Digitalmars-d-learn]

On 10/25/2016 11:30 AM, Benjamin Thaut wrote:

Please consider the following program:

[...]

I would assume that this program should run forever and never run out of
memory. But instead it triggers an assert inside alocator_list in pass
11. So I assume this is some bug in std.allocator?


I can confirm the crash with 2.071.2. But it doesn't happen with 
2.072.0-b2. So, bug that has already been fixed?



Also whats interresting. The first allocation in each new pass is _not_
the last allocation to be freed. Instead it seems to "leak" one
allocation each pass.

From the output of the program:

229a290fd60 <- same
229a2932570 <- leaked?
pass 11
229a290fd60 <- same


Also looks ok with 2.072.0-b2:

7f448c7ccdb0
7f448c7cd200
pass 99
7f448c7cd200
7f448c7ccdb0

[Issue 16590] Wrong di generation for ref methods

[via Digitalmars-d-bugs]

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

--- Comment #5 from Satoshi  ---
struct Foo(size_t Size = 42 / magic()) {

}


size_t magic() {
return 42;
}


This cannot resolve magic() function at compile time.

--

[Issue 16590] Wrong di generation for ref methods

[via Digitalmars-d-bugs]

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

--- Comment #4 from Satoshi  ---
class Foo {
protected void method42() {

}
}


class Bar : Foo {
   void method42() {

   }
}

Bar.method42() does not override any function

--

[Issue 16590] Wrong di generation for ref methods

[via Digitalmars-d-bugs]

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

--- Comment #3 from Satoshi  ---
methods marked as return, e.g.
void foo() return {

}

are exported in wring way.

--

[Issue 16590] Wrong di generation for ref methods

[via Digitalmars-d-bugs]

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

--- Comment #2 from Satoshi  ---
() @trusted {


}

block is rewritten as
() {

}

what is wrong

--

Re: State of issues.dlang.org

[ag0aep6g via Digitalmars-d]

On 10/25/2016 05:17 AM, Jacob wrote:

I sort of feel that issues.dlang.org is an unmaintained mess. Anyone has
access to it every aspect of editing anyone else's issue, so anyone
could be added really without any oversight.


Yet there's very little vandalism going on, aside from the occasional 
spam. We have oversight in the form of people watching every change that 
happens on the bug tracker.



There's no editing one's
comments so I often see people making multiple posts to themselves to
add more information or to correct themselves. That's just a minor
issue.


I don't think that's really an issue. Bugzilla sends out notification 
emails. An edit feature would complicate that. You'd have to read diffs 
instead of a human-written correction. I think that might be more 
annoying than having multiple comments. If any kind of discussion 
happens you're going to have many comments anyway.



There are 16k issues (I'm guessing every ID basically means a
unique issue) for DMD alone.


That's not for dmd alone, it's for all components: dlang.org, dmd, 
druntime, installer, phobos, tools, visuald. The 16000 issues also 
include fixed and otherwise closed ones.


Just dmd has about 3000 open issues at the moment [1]. If we filter out 
enhancements (so we have just actual bugs), the number goes down to 
about 2000 [2]. That's still a lot, but way less than 16000.



It has some issues where an individual made
a comment, no tags or anything was set, and then 2-3 years later its
remained like that til someone reserves it with a change or comment Only
for there only to be that one additional comment then the issue gets
buried for another year or so.


Well, that's because there are not enough people to fix the issues. I 
think especially the compiler team could use more hands.



There are so many like this and it is
unclear what exactly the issue is or what needs to be done with it.


If the issue description is lacking, ask for clarification. If the 
submitter doesn't respond and it's really not clear what the issue is 
about, close it. Leave comments explaining your actions.



Almost every issue is like this as well. There are some discussions in
some of the issues but a lot of the times nothing seems to be done about
them.


Sadly, yeah. But that's not an issue with Bugzilla, but an issue of too 
many bugs for too few developers.



Anyways for the site itself, it seems to be lacking features. When
viewing issues as a list there isn't that much information about the
issue, other than the summary.


You can change the columns by clicking on "change columns" below the list.

[...]

So now there are this many issues and it probably won't be an easy task
to go through all of them and determine which ones are actually valid.


Yeah, one at a time. Baby steps.


To weed out all the issues that can simply be deleted.


I don't think there actually are that many. I would guess that most bugs 
are actually bugs and most enhancement requests probably need a decision 
by Walter or Andrei.



It would be nice
to know what needs to be done for an issue, if it is a small enhancement
and can simply get a PR to add the functionality.


Easy bugs are usually fixed quickly. Maybe there are some (or many) open 
easy bugs, but when someone can figure that they're easy, that person 
can probably also quickly fix them. So there's not really a list of 
simple stuff.


However, Andrei has recently made an effort tagging issues with 
"bootcamp" [3]. He deems those issues to be fit for newcomers to D. But 
they're not necessarily simple. Might be small or medium sized projects 
of themselves.


For enhancements, you might want to get confirmation first that it's 
going to be accepted, before jumping in and implementing them. I.e., you 
need Walter or Andrei on board. There's a keyword for that: 
"preapproved" [4]. The "bootcamp" issues obviously also have been 
approved by Andrei.



If it is a bit bigger
of an enhancement and needs a DIP to add the functionality.


If that's so, I think it gets closed in Bugzilla. At least, that's what 
Andrei has done recently, if I remember correctly.



Or whether
an issue exists and how the issue needs to be handled. Is it a feature
that was implemented incorrectly and needs to be reworked. Or was it
possibly an oversight of a combination of features and a more thought
out solution needs to be created, which might involve something more
extreme as removing a previous feature.


The "severity" field covers this partially:

* enhancement: Not a bug, but a request for an additional feature or such.
* trivial: A bug that should be easy to fix (typos and such).
* minor, normal, major, critical: Greater levels of bugs.
* blocker: Mostly misused as far as I know. Should be blocking a 
release, is often used to indicate that the submitter's work is being 
blocked.

* regression: A new bug in an old feature.

Further than that, the submitter of a bug doesn't usually know how it 
came about. And working 

Re: State of issues.dlang.org

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 25 October 2016 at 03:17:02 UTC, Jacob wrote:

I sort of feel that issues.dlang.org is an unmaintained mess.


I don't think its state is much worse than that of a typical 
bugtracker for projects of this scale.



Anyways for the site itself, it seems to be lacking features.


It is a standard Bugzilla instance. We do not develop the 
software.


When viewing issues as a list there isn't that much information 
about the issue, other than the summary.


You can create custom views for whatever task you have at hand.

The "Product", completely useless, is D for everything on the 
site essentially.


We do not use many of Bugzilla's features. Support for multiple 
products is one of them. (Also is it lacking features or having 
too many?)


The "Resolution", only ever seen it as "---", maybe it means 
something for closed issues but I haven't seen any closed 
issues.


If something is unclear, please refer to the Bugzilla manual.

There's no, "needs work", or "enhancement" or any other 
description that can add to what the issue is or what it needs 
to have done to it.


The severity field has "enhancement" as an option.

If it is a bit bigger of an enhancement and needs a DIP to add 
the functionality.


Feature requests that require a DIP do not belong on Buzilla.

TLDR; The issue system in place right now needs to be removed 
and a better system with oversight put in place.


Err, no. Just because you haven't seen a Bugzilla instance 
elsewhere doesn't mean we should replace it. The UI is a bit 
90's, but otherwise it has served us well.

Re: Battle-plan for CTFE

[Stefam Koch via Digitalmars-d-announce]

On Tuesday, 25 October 2016 at 09:36:12 UTC, Stefam Koch wrote:

On Monday, 24 October 2016 at 06:37:12 UTC, Rory McGuire wrote:

Cool, thanks for the feedback.



I have take care of the blocker for now.
I turns out my tests contained wrong code that reused a 
register for multiple purposes.

LLVM does not like that.
So it assumed the wrong things while optimising and went into 
the wrong direction makeing complete bogus out of valid code.


First perf data is in

The is measured with time src/dmd -c -ctfe-bc

old interpreter (without -ctfe-bc) :

real0m6.839s
user0m6.423s
sys 0m0.407s

new interpreter (-ctfe-bc)

real0m0.549s
user0m0.547s
sys 0m0.000s

LLVM Backend (-ctfe-bc -version=UseLLVMBackend) :

real0m0.039s
user0m0.027s
sys 0m0.010s


The compiled code was :
int bug6498(int x)
{
int n = 0;
while (n < x)
++n;
return n;
}
static assert(bug6498(10_000_000)==10_000_000);

Re: Review manager wanted: core.vmm

[Guillaume Piolat via Digitalmars-d]

On Saturday, 15 October 2016 at 14:08:25 UTC, Dmitry Olshansky 
wrote:
The module aims to provide portable interface to virtual memory 
management unit of the OS. Some common recipes such as locking 
memory and allocating executable memory should be easily 
accessible.


In general the task is next to impossible and therefore 
capabilities of the current OS are captured into manifest 
constant to allow for conditional adaptation to them (static 
ifs etc).


https://github.com/dlang/druntime/pull/1549

---
Dmitry Olshansky


Hi, have you found a review manager yet?

[Issue 16574] [REG 2.072.0-b1] Unexplained errors about functions that overridde anything

[via Digitalmars-d-bugs]

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

--- Comment #15 from Martin Nowak  ---
(In reply to b2.temp from comment #14)
> (In reply to Martin Nowak from comment #13)
> > (In reply to b2.temp from comment #11)
> > > $ if [ -d kheops ]; then
> > > $ cd kheops
> > > $ git pull
> > > $ cd ..
> > > $ else
> > > $ git clone https://github.com/BBasile/kheops.git
> > > $ fi
> > > $ cd kheops/runnable
> > > $ dub default_alignment.d 
> > 
> > Mmh, apparently you don't see the problem w/ your test case, so I'm saying
> > this explicit.
> > The moment you add a new commit, or any of the your project's dependencies
> > gets updated, the bug might no longer be reproducible.
> 
> $ if ! [ -d kheops ]; then
> $ git clone https://github.com/BBasile/kheops.git
> $ fi
> $ 
> $ cd kheops
> $ git checkout a00f300c4281b2d4aaf95e7fabde48d3dc3816e9
> $ cd runnable
> $ dub default_alignment.d
> 
> > I've already spend a lot of time trying to reproduce this bug w/ your ever
> 
> So do I. I've manually compiled DMD and phobos about a hundred of times to
> find where default_alignment.d started not to work anymore. Also the
> (unfortunately) wrong reduction didn't pop from the magician hat.

I didn't mean to be unfriendly, it's just that such small formal problems eat a
lot of time.

> 'dub build --build=unittest' does nothing, you should have get  "Target is a
> library.

Nevermind, I always ran the default_alignment.d test as posted in comment 1.

> He's the author of the feature.

That's not development in any organization should work, exactly b/c people can 

> I have many others small applications like "default_alignment.d" that I run
> to track possible breakage. Once again I don't understand what you are
> trying to tell me. With DMD 2.071.2 they are all compiled, they run all.

Well, then it's a regression, but if you look at comment 6, it's rather
confusing to follow. Last time I tested the project wasn't compiling with any
version between 2.069 and 2.071 (see comment 8).

> > Lazy alias analysis is a huge improvement for compile times, 
> 
> Certainly.
> 
> > so we won't drop it light-hearted.
> 
> So don't drop it and make your release but keep in mind that there's an
> issue. Soon or later it will show the tip of its nose again.

Well that's why I'm spending time here. It's not even sure that the lazy alias
is the cause of this problem.

--

Re: Neural Networks / ML Libraries for D

[maarten van damme via Digitalmars-d-learn]

There is mir https://github.com/libmir/mir which is geared towards machine
learning, I don't know if it has anything about neural networks, I've yet
to use it. If you're only interested in neural networks, I've used FANN (a
C library) together with D and it worked very well.

2016-10-25 13:17 GMT+02:00 Saurabh Das via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com>:

> Hello,
>
> Are there any good ML libraries for D? In particular, looking for a neural
> network library currently. Any leads would be appreciated.
>
> Thanks,
> Saurabh
>
>

[Issue 16607] [REG2.072b1] forward reference error for nested struct

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Martin Nowak  ---
https://github.com/dlang/dmd/pull/6214

--

[Issue 16607] [REG2.072b1] forward reference error for nested struct

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

Summary|[REG2.072b1] "forward   |[REG2.072b1] forward
   |reference" error with   |reference error for nested
   |structs nested in struct|struct
   |templates   |

--

Neural Networks / ML Libraries for D

[Saurabh Das via Digitalmars-d-learn]

Hello,

Are there any good ML libraries for D? In particular, looking for 
a neural network library currently. Any leads would be 
appreciated.


Thanks,
Saurabh

Re: Battle-plan for CTFE

[Stefam Koch via Digitalmars-d-announce]

On Monday, 24 October 2016 at 06:37:12 UTC, Rory McGuire wrote:

Cool, thanks for the feedback.



I have take care of the blocker for now.
I turns out my tests contained wrong code that reused a register 
for multiple purposes.

LLVM does not like that.
So it assumed the wrong things while optimising and went into the 
wrong direction makeing complete bogus out of valid code.

Bug in std.allocator?

[Benjamin Thaut via Digitalmars-d-learn]

Please consider the following program:

import std.experimental.allocator.mallocator;
import std.experimental.allocator.building_blocks.allocator_list 
: AllocatorList;

import std.experimental.allocator.building_blocks.free_list;
import std.experimental.allocator;
import std.stdio;

enum uint size = 1104;

alias ScalableFreeList = AllocatorList!((n) =>
ContiguousFreeList!(Mallocator, 0, unbounded)(size * 128, 
size)

);

void main(string[] args)
{
  void[][20] allocs;
  ScalableFreeList allocator;

  for(int i=0; i < 100; i++)
  {
writefln("pass %d", i);
foreach(ref alloc; allocs)
{
  alloc = allocator.allocate(size);
  writefln("%x", alloc.ptr);
}

foreach(alloc; allocs)
{
  allocator.deallocate(alloc);
}
  }
}


I would assume that this program should run forever and never run 
out of memory. But instead it triggers an assert inside 
alocator_list in pass 11. So I assume this is some bug in 
std.allocator?


Also whats interresting. The first allocation in each new pass is 
_not_ the last allocation to be freed. Instead it seems to "leak" 
one allocation each pass.


From the output of the program:

229a290fd60 <- same
229a2932570 <- leaked?
pass 11
229a290fd60 <- same

Or can anyone see a bug in my program?

Kind Regards
Benjamin Thaut

[Issue 16637] New: DMG archive doesn't contain dub?

[via Digitalmars-d-bugs]

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

  Issue ID: 16637
   Summary: DMG archive doesn't contain dub?
   Product: D
   Version: D2
  Hardware: x86_64
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: installer
  Assignee: nob...@puremagic.com
  Reporter: 4bur...@gmail.com

Before I forget (I don't have OSX here, so I can't retest):

Installing latest dmg from dlang.org didn't brought `dub` for me. Installing
via `install.sh` worked fine.

--

Re: State of issues.dlang.org

[Jack Stouffer via Digitalmars-d]

On Tuesday, 25 October 2016 at 03:17:02 UTC, Jacob wrote:

...


1. The vast, vast majority of problems attributed to 
collaboration software are actually the fault of a lack of 
communication skills. This situation is no different. Changing 
the software will not fix any problems in organization or 
curation. Most the features you call useless are not useless in 
of themselves, but are "useless" because people don't use them.


99% of all collaboration could be done in excel if you have good 
communication skills.


2. We don't have the manpower to have a completely curated 
system. Any energy spent curating would be better spent fixing 
bugs.


3. It serves its purpose well in that very bad bugs that are 
reported with detail are fixed quickly.


4. Many people follow the bug feed on the forum, so a bug is 
almost always looked at at least once. Most bugs are usually 
considered not very high in priority, and so it's up to the 
volunteers to come in and fix them. Core team members are focused 
on regressions, new issues, and really bad bugs. Most of them 
don't have time for enhancements.


5. If you see an issue that doesn't have enough detail to be 
fixed, then close it.


6. No one is stopping you from putting together a better idea. I 
look forward to your DIP on the subject.

Re: Repeat and chunks

[Dorian Haglund via Digitalmars-d-learn]

On Monday, 24 October 2016 at 16:09:44 UTC, ag0aep6g wrote:

On 10/24/2016 04:25 PM, Dorian Haglund wrote:

The following code crashes with DMD64 D Compiler v2.071.2:

import std.algorithm;
import std.stdio;
import std.range;

int main()
{
  repeat(8, 10).chunks(3).writeln();

  return 0;
}


Looks like a bug. Doesn't happen with 2.072.0-b2, so it has 
apparently already been fixed.


Ok! I'll wait for the next release then. Thanks.

Re: [OT] fastest fibbonacci

[Andrea Fontana via Digitalmars-d]

On Tuesday, 25 October 2016 at 07:05:20 UTC, Era Scarecrow wrote:
 Hmm as an experiment I changed from doubles to reals, and got 
a slightly higher result, up to 85 giving us a 58/64



Of course floating precision is not unlimited :)

[Issue 5278] gentoo's 'hardended' gcc doesn't work with dmd

[via Digitalmars-d-bugs]

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

Lodovico Giaretta  changed:

   What|Removed |Added

 CC||lodov...@giaretart.net

--- Comment #33 from Lodovico Giaretta  ---
I can confirm that putting `-fPIC -defaultlib=libphobos2.so` in dmd.conf makes
DMD work correctly on hardened systems (tested on Ubuntu 16.10).

Binaries built this way are PIE and have Phobos linked dynamically. I didn't
manage to find a configuration that allows me to statically link Phobos, with
or without PIE.

--

Re: [OT] fastest fibbonacci

[Era Scarecrow via Digitalmars-d]

On Monday, 24 October 2016 at 19:03:51 UTC, Era Scarecrow wrote:
It's only good through 71 iterations (longs) then it starts 
having errors. Also for some odd reason the input is one off, 
so I had to add a -1 to the input for it to align. This makes 
it accurate to 41/64 bit results.


71: 308061521170129 308061521170129 true
72: 498454011879264 498454011879265 false


 Hmm as an experiment I changed from doubles to reals, and got a 
slightly higher result, up to 85 giving us a 58/64


83: 99194853094755497   99194853094755497   true
84: 160500643816367088  160500643816367088  true
85: 259695496911122585  259695496911122585  true
86: 420196140727489673  420196140727489674  false
87: 679891637638612258  679891637638612259  false
88: 1100087778366101931 1100087778366101933 false

Re: Namespace for a module defined by its import path

[Jeff Thompson via Digitalmars-d]

On Tuesday, 25 October 2016 at 00:42:59 UTC, Adam D. Ruppe wrote:

On Monday, 24 October 2016 at 21:06:18 UTC, Jeff Thompson wrote:
Basically, I want the namespace of the identifiers in the 
library module to be defined by the path which is use to load 
them *without needing to put the path in the module file.*  Is 
there some way to do this?


That's not going to work... but why do you want this? If they 
are different versions of the file, editing the module 
definition should be no real problem. You can use renamed 
imports or a helper module with public import to keep user code 
more compatible.


A variant of this is where the version name is the Git commit 
hash. Instead of "version1" and "version2" it is:


/commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/lib.d
/commit_df0741a84c8a967ea08674090afdff4e9a58d23e/lib.d

The file lib.d can't contain its own commit hash, so I can't put 
it in the module declaration. And different parts of the 
application rely on different versions so I need different 
application files to be able to import one or the other without 
conflict. I'm trying to escape the situation where a piece of 
code needs to know the path which the operating system uses to 
load it.