date:20150917

2015-09-17 Thread Ola Fosheim Grøstad via Digitalmars-d

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

Daniel Kozak  changed:

   What|Removed |Added

URL||http://dlang.org/changelog/
   ||2.067.0.html#gc-options

--

Re: Implement the "unum" representation in D ?


On Wednesday, 16 September 2015 at 23:28:23 UTC, H. S. Teoh wrote:
I'm not so sure how well this will work in practice, though, 
unless we have a working prototype that proves the benefits.  
What if you have a 10*10 unum matrix, and during some operation 
the size of the unums in the matrix changes?  Assuming the 
worst case, you could have started out with 10*10 unums with 
small exponent/mantissa, maybe fitting in 2-3 cache lines, but 
after the operation most of the entries expand to 7-bit 
exponent and 31-bit mantissa, so now your matrix doesn't fit 
into the allocated memory anymore.  So now your hardware has to 
talk to druntime to have it allocate new memory for storing the 
resulting unum matrix?


Let's not make it so complicated. The internal CPU format could 
just be 32 and 64 bit. The key concept is about recording 
closed/open intervals and precision. If you spend 16 cores of a 
256 core tiled coprocessor on I/O you still have 240 cores left.


For the external format, it depends on your algorithm. If you are 
using map reduce you load/unload working sets, let the 
coprocessor do most of the work and combine the results. Like an 
actor based pipeline.


The problem is more that average programmers will have real 
trouble making good use of it, since the know-how isn't there.


The author proposed GC, but I have a hard time imagining a GC 
implemented in *CPU*, no less, colliding with
the rest of the world where it's the *software* that controls 
DRAM allocation.  (GC too slow for your application? Too bad, 
gotta upgrade your CPU...)


That's a bit into the future, isn't it? But local memory is 
probably less that 256K and designed for the core, so… who knows 
what extras you could build in? If you did it, the effect would 
be local, but it sounds too complicated to be worth it.


But avoid thinking that the programmer address memory directly. 
CPU+Compiler is one package. Your interface is the compiler, not 
the CPU as such.


The way I see it from reading the PDF slides, is that what the 
author is proposing would work well as a *software* library, 
perhaps backed up by hardware support for some of the 
lower-level primitives.  I'm a bit skeptical of the claims of


First you would need to establish that there are numerical 
advantages that scientists require in some specific fields.


Then you need to build it into scientific software and accelerate 
it. For desktop CPUs, nah... most people don't care about 
accuracy that much.


Standards like IEEE1788 might also make adoption of unum less 
likely.

[Issue 15078] New: GC documentation should reflect 2.067 changes

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

  Issue ID: 15078
   Summary: GC documentation should reflect 2.067 changes
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: kozz...@gmail.com

ATM there is no information how to tweak GC

http://forum.dlang.org/post/mailman.151.1442258932.22025.digitalmar...@puremagic.com

--

Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX

On Thursday, 17 September 2015 at 06:40:56 UTC, ponce wrote:

On Wednesday, 16 September 2015 at 23:24:29 UTC, bitwise wrote:

I was trying to solve this one myself, but the modifications
to DMD's backend that are needed are out of reach for me right
now.

If you're willing to build your own druntime, you may be able
to get by.

I'd prefer a solution that works with existing compilers, but
maybe building a custom LDC is possible if I figure it out.

Unfortunately, this is a complex problem and you can't just flip
a few switches and make it work.

In practive I've found that the D shared libraries I produce
can be dlopen/dlclose any number of times, simultaneous too.
Using both LDC and DMD, don't know why it works.
The thing that doesn't work is the C host program dlopen'ing
the shared library, dlclose it, then dlopen another shared
library written in C.

Calling dlopen won't initialize the runtime in the shared
library. Although your program doesn't crash, you may find that
it does once you start calling into the shared lib... or it may
leak memory because the GC was never initialized. You can call
Runtime.initialize() from druntime yourself, but as you know,
there is the callback issue.

I think LDC may be farther along in terms of shared library
support. You may want to ask David Nadlinger about this. I think
the problem with LDC was that it only supported statically loaded
shared libs for osx. I'm not sure if this is still the case, but
it looks like it:

https://github.com/ldc-developers/druntime/blob/002d0aed65cd24dfcbbc782d9aed2f9112f27b4e/src/rt/sections_ldc.d#L372

Anyways, when main() of a D program runs, it calls rt_init()
and rt_term(). If you don't have a D entry point in your
program, you have to retrieve these from your shared lib(which
has druntime statically linked) using dlsym() and call them
yourself.

I don't control the host program. My shared libs do have an
entrypoint, from which I call Runtime.initialize().

I can also use LDC global constructor/destructor to call
Runtime.initialize / Runtime.terminate, but it doesn't work any
better because of the callback.

I don't think there is any way around this beside building a
custom runtime and implementing the function I suggested.

Thanks for your answer. This is really helpful, though I don't
understand the first thing about what images, headers and
sections are in this context.

As a last resort, you may be able to use OSX Distributed Objects,
depending on what your shared library does. This is basically a
wrapper around linux pipes, but with a simple RPC-like interface.
Depending on how much talk there is between the host program and
your shared lib, this may or may not be a good solution.

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/DistrObjects/DistrObjects.html

Basically, you would make an Objective-C shared library with a C
interface, into which the host program could call. This shared
library would then spawn a second process as needed, which would
load the D shared library. You would then use distributed objects
to call from the Objective-C shared library to the D shared
library. When you were done with the D shared library, you would
simply terminate the second process.

Bit

Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX

2015-09-17 Thread ponce via Digitalmars-d

On Wednesday, 16 September 2015 at 23:24:29 UTC, bitwise wrote:

I was trying to solve this one myself, but the modifications to
DMD's backend that are needed are out of reach for me right now.

If you're willing to build your own druntime, you may be able
to get by.

I'd prefer a solution that works with existing compilers, but
maybe building a custom LDC is possible if I figure it out.

If I understand correctly, you want to repeatedly load/unload
the same shared library, correct? I ask because druntime for
osx only supports loading a single image at a time:

https://github.com/D-Programming-Language/druntime/blob/1e25749cd01ad08dc08319a3853fbe86356c3e62/src/rt/sections_osx.d#L26

In practive I've found that the D shared libraries I produce can
be dlopen/dlclose any number of times, simultaneous too. Using
both LDC and DMD, don't know why it works.
The thing that doesn't work is the C host program dlopen'ing the
shared library, dlclose it, then dlopen another shared library
written in C.

I don't control the host program. My shared libs do have an
entrypoint, from which I call Runtime.initialize().

I can also use LDC global constructor/destructor to call
Runtime.initialize / Runtime.terminate, but it doesn't work any
better because of the callback.

https://github.com/D-Programming-Language/druntime/blob/478b6c5354470bc70e688c45821eea71b766e70d/src/rt/dmain2.d#L158

Now, initSections() and finiSections() are responsible for
setting up the image. If you look at initSections(), the
function "_dyld_register_func_for_add_image" is the one that
causes the crash, because there is no way to remove the
callback, which will reside in your shared lib.

https://github.com/D-Programming-Language/druntime/blob/1e25749cd01ad08dc08319a3853fbe86356c3e62/src/rt/sections_osx.d#L76

So what happens is, when you call
_dyld_register_func_for_add_image, dyld will call your callback
for every shared-library/image(including the main application's
image) that is currently loaded. However, you can skip the
callback and just call "sections_osx_onAddImage" yourself.

You would have to add something like this to sections_osx.d,
and call it instead of adding the callback:

void callOnAddImage()
{
// dladdr() should give you information about the
// shared lib in which the symbol you pass resides.
// Passing the address of this function should work.
Dl_info info;
int ret = dladdr(cast(void*), );
assert(ret);

// "dli_fbase" is actually a pointer to
// the mach_header for the shared library.
// once you have the mach_header, you can
// also retrieve the image slide, and finally
// call sections_osx_onAddImage().
mach_header* header = cast(mach_header*)info.dli_fbase;
intptr_t slide = _dyld_get_image_slide(header);
sections_osx_onAddImage(header, slide);
}

Now, if you look at finiSections(), it seems to be incomplete.
There is nothing like sections_osx_onRemoveImage, so you'll
have to complete it to make sure the library is unloaded
correctly:

https://github.com/D-Programming-Language/druntime/blob/1e25749cd01ad08dc08319a3853fbe86356c3e62/src/rt/sections_osx.d#L83

You'll may have to make other mods here and there to get this
working correctly, but this is the bulk of it.

Bit

Thanks for your answer. This is really helpful, though I don't
understand the first thing about what images, headers and
sections are in this context.

[Issue 14916] opDispatch: no property error for parameter type mismatch

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

Ozan Nurettin Süel  changed:

   What|Removed |Added

 CC||ozan.nurettin.sueel@gmail.c
   ||om
   Severity|normal  |major

--

[Issue 14916] opDispatch: no property error for parameter type mismatch

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

Ozan Nurettin Süel  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #1 from Ozan Nurettin Süel  ---
OpDispatch is a important functionality to bring state-of-the-art language
flexibility.

--

Re: dmd codegen improvements

2015-09-17 Thread Joakim via Digitalmars-d

On Wednesday, 16 September 2015 at 20:44:00 UTC, Walter Bright 
wrote:

On 9/16/2015 7:16 AM, Bruno Medeiros wrote:

On 28/08/2015 22:59, Walter Bright wrote:
People told me I couldn't write a C compiler, then told me I 
couldn't
write a C++ compiler. I'm still the only person who has ever 
implemented
a complete C++ compiler (C++98). Then they all (100%) laughed 
at me for

starting D, saying nobody would ever use it.

My whole career is built on stepping over people who told me 
I couldn't

do anything and wouldn't amount to anything.


So your whole career is fundamentally based not on bringing 
value to the
software world, but rather merely proving people wrong? That 
amounts to living
your professional life in thrall of other people's validation, 
and it's not

commendable at all. It's a waste of your potential.

It is only worthwhile to prove people wrong when it brings you 
a considerable
amount of either monetary resources or clout - and more so 
than you would have

got doing something else with your time.

It's not clear to me that was always the case throughout your 
career... was it?


Wow, such an interpretation never occurred to me. I will 
reiterate that I worked on things that I believed had value and 
nobody else did. I.e. I did not need validation from others.


Yeah, I was a bit stunned that that is what Bruno took from your 
post.  I don't think anybody would question that writing a C or 
C++ compiler in the '80s and '90s had value, and I'm sure you did 
pretty well off them, considering you retired at 42 
(http://www.drdobbs.com/architecture-and-design/how-i-came-to-write-d/240165322).


Your point is that nobody thought _you_ or you _alone_ could do 
these valuable things, and you repeatedly proved them wrong.  
Those doubting you in this thread, about improving the dmd 
backend so it's competitive with llvm/gcc while still having time 
to work on the frontend, may or may not turn out to be right, but 
you certainly seem to have a good track record at proving such 
doubters wrong.

Re: dmd codegen improvements

2015-09-17 Thread Mike Parker via Digitalmars-d

On Wednesday, 16 September 2015 at 14:40:26 UTC, Bruno Medeiros 
wrote:
And on this aspect I think the development of D does very 
poorly. Often people clamored for a feature or change (whether 
people in the D community, or the C++ one), and Walter you went 
ahead and did it, regardless of whether it will actually 
increase D usage in the long run. You are prone to this, given 
your nature to please people who ask for things, or to prove 
people wrong (as you yourself admitted).


I apologize for not remembering any example at the moment, but 
I know there was quite a few, especially many years back. It 
usually went like this:


C++ community guy: "D is crap, it's not gonna be used without X"
*some time later*
Walter: "Ok, I've now implemented X in D!"
the same C++ community guy: either finds another feature or 
change to complain about (repeat), or goes silent, or goes 
"meh, D is still not good"
Me and other people from D community: "ok... now we have a new 
half-baked functionality in D, adding complexity for little 
value, and put here only to please people that are extremely 
unlikely to ever be using D whatever any case"...


I find this assessment inaccurate. In my own experience, I have 
come to see Walter as Dr. No (in a good sense!) in that he has 
said no to a great many feature requests over the years. The 
instances where a feature was implemented that took the community 
by surprise have been rare indeed. And even then, we are not 
privy to the support requests and other discussions that Walter 
has with the businesses using D. I'm confident that what goes on 
in his head when deciding to pursue a change or enhancement has 
little to do with willy-nilly complaints by C++ users.

Bloat with std.(string.)format?


If I have code like this:

auto builder = appender!string;
builder ~= "Hello, World!";
builder ~= "I'm here!";
builder ~= "Now I'm there!";

the object file grows by 10-11 lines with each call to `builder 
~=`. If I use this:


builder ~= format("%s", "Hello, World!");
builder ~= format("%s", "I'm here!");
builder ~= format("%s", "Now I'm there!");

The object file is more than twice as big and it grows by 20 
lines with each call to `format`.


If I use

builder ~= format("%s %s %s", "Hello, World!", "I'm here!", "Now 
I'm there!");


the code bloat is even worse.

There are many situation where a formatting string is preferable 
to concatenation, however it adds _a lot_ of bloat. Would a 
custom formatter be preferable to reduce code bloat or should 
std/format.d be optimized? (Or both?)


dmd 2.067.1
-release -boundscheck=off -inline -O

[Issue 14916] opDispatch: no property error for parameter type mismatch

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||diagnostic

--

Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX

2015-09-17 Thread Walter Bright via Digitalmars-d


On 9/16/2015 11:40 PM, ponce wrote:

On Wednesday, 16 September 2015 at 23:24:29 UTC, bitwise wrote:


I was trying to solve this one myself, but the modifications to DMD's backend
that are needed are out of reach for me right now.

If you're willing to build your own druntime, you may be able to get by.


I'd prefer a solution that works with existing compilers, but maybe building a
custom LDC is possible if I figure it out.


I seriously doubt this issue has anything to do with the compiler's code 
generator back end. It's more likely the problem is in druntime.

[Issue 15079] New: Assertion `fd->semanticRun == PASSsemantic3done' failed.

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

  Issue ID: 15079
   Summary: Assertion `fd->semanticRun == PASSsemantic3done'
failed.
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: schue...@gmx.net

dmd: glue.c:809: void FuncDeclaration_toObjFile(FuncDeclaration*, bool):
Assertion `fd->semanticRun == PASSsemantic3done' failed.


This happens when compiling current botan with dub in release mode:

git clone g...@github.com:etcimon/botan.git && cd botan
dub build -b release --force

Digger blames this merge commit:

commit 79e7b48fd45334301d1694653da993066b3d6946
Author: Hara Kenji 
Date:   Wed Sep 2 13:10:09 2015 +0900

dmd: Merge pull request #5019 from 9rnsr/merge_stable

https://github.com/D-Programming-Language/dmd/pull/5019

Merge branch 'merge_stable_convert' into merge_stable

diff --git a/dmd b/dmd
index ef811cf..d44cda0 16
--- a/dmd
+++ b/dmd
@@ -1 +1 @@
-Subproject commit ef811cf0e76f960eccfb56ef9c6448ed3513bb35
+Subproject commit d44cda0ccaf157ca8a22e9683939ad55c30632b5

Not sure how to bisect this further...

--

Reading Atributes (UDA) of overloaded functions

2015-09-17 Thread Ozan via Digitalmars-d-learn


Hi!

Is it possible to read all attributes in case of overloading 
functions? Example:


struct Att { string name; }
struct Att2 { string name; }
@Att void testUDA(string x) { writeln("test(string ",x,")"); }
@Att2 void testUDA(int x) { writeln("test(string ",x,")"); }

void main(string[] args)
{
testUDA("aaa");
testUDA(100);

foreach (attr; __traits(getAttributes, testUDA)) {
if (attr.stringof == "Att") writeln("Found Att");
if (attr.stringof == "Att2") writeln("Found Att2");
}
}

results in one (!) "Found Att".
Seems like "First comes, first wins".

Regards, Ozan

Re: dmd codegen improvements

2015-09-17 Thread Bruno Medeiros via Digitalmars-d


On 17/09/2015 08:10, Joakim wrote:

Yeah, I was a bit stunned that that is what Bruno took from your post.
I don't think anybody would question that writing a C or C++ compiler in
the '80s and '90s had value, and I'm sure you did pretty well off them,
considering you retired at 42
(http://www.drdobbs.com/architecture-and-design/how-i-came-to-write-d/240165322).



I didn't say that Walter's previous work didn't bring *any* value to the 
software world. It's not like people challenged him to write efficient 
lolcode or brainfuck(*) compilers, or some other silly challenge, which 
if he did would have a been a massive waste of time - even if it was 
technically a very admirable feat.


(*) - Yeah those languages weren't around at the time, but that's just 
an example.


My point was that one would certainly bring *more* value to the software 
world, if that is the primary focus of one's career, instead of merely 
proving people wrong.


That doesn't mean either one has to be an emotionless robot that never 
does something just for the sake of ego-boosting (which is really the 
only reward of proving people wrong - unless there are some monetary or 
other resources at stake). But Walter has so many stories of "I did this 
[massive project] to prove people wrong." which is what makes me wonder 
if there isn't too much focus on ego validation.



--
Bruno Medeiros
https://twitter.com/brunodomedeiros

Re: dmd codegen improvements

2015-09-17 Thread Bruno Medeiros via Digitalmars-d


On 17/09/2015 09:06, Mike Parker wrote:

On Wednesday, 16 September 2015 at 14:40:26 UTC, Bruno Medeiros wrote:

And on this aspect I think the development of D does very poorly.
Often people clamored for a feature or change (whether people in the D
community, or the C++ one), and Walter you went ahead and did it,
regardless of whether it will actually increase D usage in the long
run. You are prone to this, given your nature to please people who ask
for things, or to prove people wrong (as you yourself admitted).

I apologize for not remembering any example at the moment, but I know
there was quite a few, especially many years back. It usually went
like this:

C++ community guy: "D is crap, it's not gonna be used without X"
*some time later*
Walter: "Ok, I've now implemented X in D!"
the same C++ community guy: either finds another feature or change to
complain about (repeat), or goes silent, or goes "meh, D is still not
good"
Me and other people from D community: "ok... now we have a new
half-baked functionality in D, adding complexity for little value, and
put here only to please people that are extremely unlikely to ever be
using D whatever any case"...


I find this assessment inaccurate. In my own experience, I have come to
see Walter as Dr. No (in a good sense!) in that he has said no to a
great many feature requests over the years. The instances where a
feature was implemented that took the community by surprise have been
rare indeed. And even then, we are not privy to the support requests and
other discussions that Walter has with the businesses using D. I'm
confident that what goes on in his head when deciding to pursue a change
or enhancement has little to do with willy-nilly complaints by C++ users.


Dr. No for the D community. If someone from D community said "D won't 
succeed without X", or "D can't be made to work without X", that 
wouldn't have much clout with Walter. (unless that someone is behind a 
company using D commercially, or considering so)


But if people from the C++ community said it, OMG, then Walter goes 
"let's add it to D!", just to prove a point or something. *Mind you*: 
all this I'm saying is pre TDPL book stuff. After the book was out, 
things stabilized. But way back, even more so before D2, it would happen 
quite often. Again apologies for no references or examples, but this is 
all stuff from 4-7 years ago so it's hard to remember exact cases.


--
Bruno Medeiros
https://twitter.com/brunodomedeiros

[Issue 15071] filenames and module names with case-insensitive HFS+

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

--- Comment #3 from Sobirari Muhomori  ---
dmd chirplet.d mathutil.d -main

Does this work (lower case)?

--

Re: Checked integer type API design poll

2015-09-17 Thread tsbockman via Digitalmars-d

I see that someone selected "All of that and more, not listed 
here" in response to "How many math functions need versions with 
checked integer support?"


If anyone selects that option, please leave a comment explaining 
what other code you think needs explicit support for checked 
integer types.

Re: dmd codegen improvements

2015-09-17 Thread Bruno Medeiros via Digitalmars-d


On 17/09/2015 12:57, Bruno Medeiros wrote:

But if people from the C++ community said it, OMG, then Walter goes
"let's add it to D!", just to prove a point or something. *Mind you*:
all this I'm saying is pre TDPL book stuff. After the book was out,
things stabilized. But way back, even more so before D2, it would happen
quite often. Again apologies for no references or examples, but this is
all stuff from 4-7 years ago so it's hard to remember exact cases.


I do remember though, that the turning point for this was when Andrei 
joined the D team. Before that it was more or less like this:
Walter was the master compiler writer, wohoo, and if someone challenged 
him to add a feature, it went in. In most cases maybe Walter wasn't 
challenged directly, but someone in the C++ community would say "Ha, 
wouldn't it be great if C++ had X!", and then if D didn't had X already, 
it would get added, so Walter would go "Oh, you know what, D has X!!"


Little consideration was given to whether X was worthwhile or not in the 
big picture.


After Andrei came on board, things improved and became more like:
Andrei: "Hold on, first let's see if the use case for X is actually a 
real world need or not. If it is, let's see if it is not satisfactory to 
use existing D language features to solve that use case. And if it's 
not, only then we'll consider adding it. But even so let's try to add X 
in a more generic way, so that it easier to implement and/or so that it 
could solve other use cases as well."


--
Bruno Medeiros
https://twitter.com/brunodomedeiros

Re: Checked integer type API design poll

2015-09-17 Thread tsbockman via Digitalmars-d


On Thursday, 17 September 2015 at 08:40:17 UTC, Kagamin wrote:
As I understand, items with bigger average score are less 
popular?


For the ranking/sorting questions, yes. I think the number next 
to each item is the mean rank given it by the group.


A "1.0" would mean that people unanimously ranked that option as 
best.

Re: Bloat with std.(string.)format?

2015-09-17 Thread John Colvin via Digitalmars-d-learn


On Thursday, 17 September 2015 at 09:54:07 UTC, Chris wrote:

If I have code like this:

auto builder = appender!string;
builder ~= "Hello, World!";
builder ~= "I'm here!";
builder ~= "Now I'm there!";

the object file grows by 10-11 lines with each call to `builder 
~=`. If I use this:


builder ~= format("%s", "Hello, World!");
builder ~= format("%s", "I'm here!");
builder ~= format("%s", "Now I'm there!");

The object file is more than twice as big and it grows by 20 
lines with each call to `format`.


If I use

builder ~= format("%s %s %s", "Hello, World!", "I'm here!", 
"Now I'm there!");


the code bloat is even worse.

There are many situation where a formatting string is 
preferable to concatenation, however it adds _a lot_ of bloat. 
Would a custom formatter be preferable to reduce code bloat or 
should std/format.d be optimized? (Or both?)


dmd 2.067.1
-release -boundscheck=off -inline -O


Some initial bloat is expected, format is pretty big (although 
twice as big is a lot, unless your original code was quite 
small?). The extra bloat per call is likely due to inlining. I 
would hope that dmd would spot consecutive inlining of the same 
function and merge them, but perhaps it doesn't.


You could certainly make a less feature complete implementation 
of format that is smaller.


Have you tried with ldc or gdc. In particular, have you tried 
using ldc with --gc-sections on linux?

Re: Bloat with std.(string.)format?


On Thursday, 17 September 2015 at 10:33:44 UTC, John Colvin wrote:


Some initial bloat is expected, format is pretty big (although 
twice as big is a lot, unless your original code was quite 
small?).


It was in a test program. Only a few lines. But it would still 
add a lot of bloat in a program that uses it in different 
modules, wouldn't it?


The extra bloat per call is likely due to inlining. I would 
hope that dmd would spot consecutive inlining of the same 
function and merge them, but perhaps it doesn't.


You could certainly make a less feature complete implementation 
of format that is smaller.


Don't know if it's worth the trouble.

Have you tried with ldc or gdc. In particular, have you tried 
using ldc with --gc-sections on linux?


Not yet. GDC and LDC always lag behind (this time considerably), 
so I'm usually stuck with DMD for development.

Re: Thrift

2015-09-17 Thread Nikolay via Digitalmars-d-learn


On Wednesday, 16 September 2015 at 16:57:39 UTC, ddos wrote:

please help if you know how to get a simple example with d & 
thrift running

thx, dominik


Some time ago I could use facebook brunch with dlang: 
https://github.com/facebook/fbthrift

Re: GC performance: collection frequency

2015-09-17 Thread Dmitry Olshansky via Digitalmars-d


On 14-Sep-2015 21:47, H. S. Teoh via Digitalmars-d wrote:

Over in the d.learn forum, somebody posted a question about poor
performance in a text-parsing program. After a bit of profiling I
discovered that reducing GC collection frequency (i.e., GC.disable()
then manually call GC.collect() at some interval) improved program
performance by about 20%.



One thing that any remotely production-quality GC does is analyze the 
result of collection with respect to minimal headroom - X % (typically 
30-50%). If we freed Y % of heap where Y < X, then the GC should extend 
the heap so that it get within X % mark of free space in the extended heap.



--
Dmitry Olshansky

Re: Checked integer type API design poll

2015-09-17 Thread Kagamin via Digitalmars-d


As I understand, items with bigger average score are less popular?

[Issue 14886] [REG2.066] std.parallelism.parallel with large static array seems to hang compile

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #6 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5085

--

[Issue 15076] Get ID of current thread

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #2 from Jonathan M Davis  ---
I would think that the most natural thing to do (and what most folks would
likely look for) would be a static function/property on core.thread.Thread -
e.g. Thread.currThreadID - since that's where the thread stuff is.

--

Re: Runtime error when calling a callback in a parallel Task

2015-09-17 Thread Kagamin via Digitalmars-d-learn

Maybe compiler generates wrong code, try to debug at instruction 
level.

[Issue 15071] filenames and module names with case-insensitive HFS+

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

--- Comment #4 from John Colvin  ---
(In reply to Sobirari Muhomori from comment #3)
> dmd chirplet.d mathutil.d -main
> 
> Does this work (lower case)?

Yes.

--

Re: Reading Atributes (UDA) of overloaded functions

2015-09-17 Thread John Colvin via Digitalmars-d-learn


On Thursday, 17 September 2015 at 11:47:40 UTC, Ozan wrote:

Hi!

Is it possible to read all attributes in case of overloading 
functions? Example:


struct Att { string name; }
struct Att2 { string name; }
@Att void testUDA(string x) { writeln("test(string ",x,")"); }
@Att2 void testUDA(int x) { writeln("test(string ",x,")"); }

void main(string[] args)
{
testUDA("aaa");
testUDA(100);

foreach (attr; __traits(getAttributes, testUDA)) {
if (attr.stringof == "Att") writeln("Found Att");
if (attr.stringof == "Att2") writeln("Found Att2");
}
}

results in one (!) "Found Att".
Seems like "First comes, first wins".

Regards, Ozan


use __traits(getAttributes, /*...*/) on each of the members of 
the result of __traits(getOverloads, /*...*/)

Re: dmd codegen improvements

2015-09-17 Thread Kagamin via Digitalmars-d

Template metaprogramming is probably the only notable feature 
borrowed from C++ (more like a redesign?), the rest looks more 
like borrowed from Java. This actually turns C++ programmers away 
when they see so many things are done differently from C++.

Re: Reading Atributes (UDA) of overloaded functions

2015-09-17 Thread Ozan via Digitalmars-d-learn


On Thursday, 17 September 2015 at 12:36:42 UTC, John Colvin wrote:

On Thursday, 17 September 2015 at 11:47:40 UTC, Ozan wrote:

...
use __traits(getAttributes, /*...*/) on each of the members of 
the result of __traits(getOverloads, /*...*/)


Great! Thanks! Now it works:

foreach (ov; __traits(getOverloads, Test, "testUDA")) {
foreach (attr; __traits(getAttributes, ov)) {
if (attr.stringof == "Att") writeln("Found Att");
if (attr.stringof == "Att2") writeln("Found Att2");
if (attr.stringof == "Att3") writeln("Found Att3");
}
}

Regards, Ozan

Re: Bloat with std.(string.)format?

2015-09-17 Thread John Colvin via Digitalmars-d-learn


On Thursday, 17 September 2015 at 10:53:17 UTC, Chris wrote:
On Thursday, 17 September 2015 at 10:33:44 UTC, John Colvin 
wrote:


Some initial bloat is expected, format is pretty big (although 
twice as big is a lot, unless your original code was quite 
small?).


It was in a test program. Only a few lines. But it would still 
add a lot of bloat in a program that uses it in different 
modules, wouldn't it?


The upfront cost is paid only once per unique template arguments 
per binary. So no, it doesn't scale badly there.


Inlining, on the other hand, will - roughly speaking - increase 
binary sizes linearly with the number of calls. That's the cost 
you pay for (hopefully) better performance.


The extra bloat per call is likely due to inlining. I would 
hope that dmd would spot consecutive inlining of the same 
function and merge them, but perhaps it doesn't.


You could certainly make a less feature complete 
implementation of format that is smaller.


Don't know if it's worth the trouble.


I would say not worth it, unless you have a real problem with 
binary sizes for an actual finished product. Even then, I'd say 
you could get bigger, easier gains by messing around with 
-fvisibility settings, --gc-sections, strip etc. on GDC and LDC


Have you tried with ldc or gdc. In particular, have you tried 
using ldc with --gc-sections on linux?


Not yet. GDC and LDC always lag behind (this time 
considerably), so I'm usually stuck with DMD for development.


That's a shame.  
https://github.com/ldc-developers/ldc/releases/tag/v0.16.0-alpha3 
is at 2.067.1, is that not up-to-date enough?

Re: Reading Atributes (UDA) of overloaded functions

2015-09-17 Thread John Colvin via Digitalmars-d-learn


On Thursday, 17 September 2015 at 12:40:24 UTC, Ozan wrote:
On Thursday, 17 September 2015 at 12:36:42 UTC, John Colvin 
wrote:

On Thursday, 17 September 2015 at 11:47:40 UTC, Ozan wrote:

...
use __traits(getAttributes, /*...*/) on each of the members of 
the result of __traits(getOverloads, /*...*/)


Great! Thanks! Now it works:

foreach (ov; __traits(getOverloads, Test, "testUDA")) {
foreach (attr; __traits(getAttributes, ov)) {
if (attr.stringof == "Att") writeln("Found Att");
if (attr.stringof == "Att2") writeln("Found Att2");
if (attr.stringof == "Att3") writeln("Found Att3");
}
}

Regards, Ozan


Awesome. By the way, in the next release there will be some more 
tools in phobos for this stuff, see 
http://dlang.org/phobos-prerelease/std_traits.html#getSymbolsByUDA for a taster.

Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX

2015-09-17 Thread Stefan Koch via Digitalmars-d-announce

On Thursday, 17 September 2015 at 10:12:57 UTC, Walter Bright 
wrote:

On 9/16/2015 11:40 PM, ponce wrote:

On Wednesday, 16 September 2015 at 23:24:29 UTC, bitwise wrote:


I was trying to solve this one myself, but the modifications 
to DMD's backend

that are needed are out of reach for me right now.

If you're willing to build your own druntime, you may be able 
to get by.


I'd prefer a solution that works with existing compilers, but 
maybe building a

custom LDC is possible if I figure it out.


I seriously doubt this issue has anything to do with the 
compiler's code generator back end. It's more likely the 
problem is in druntime.


Based on previous posts you've made, it seems you already know 
that Martin's solution involves having DMD's back end add linux 
style ctors/dtors to the COMDAT section of every compiled D file, 
so I'm not sure what you mean by this.


If a callback provided to _dyld_register_func_for_add_image does 
not call sections_osx_onAddImage, then it must be called somehow.


   Bit

Re: FancyPars

On Wednesday, 16 September 2015 at 12:16:03 UTC, Bastiaan Veelo 
wrote:


Sounds like you want to share this, but I can't find a licence. 
In case this turns out to be useful, we would need one :-)


If you want I can prepare a PR for that, just let me know which 
licence to pick.


Best,
Bastiaan.


I am not sure.
The source should not be used in any product without my explicit 
permission.
However you may study it to get better in your understanding of 
dlang or parser technology

Re: GC performance: collection frequency

2015-09-17 Thread H. S. Teoh via Digitalmars-d

On Thu, Sep 17, 2015 at 11:26:17AM +0300, Dmitry Olshansky via Digitalmars-d 
wrote:
> On 14-Sep-2015 21:47, H. S. Teoh via Digitalmars-d wrote:
> >Over in the d.learn forum, somebody posted a question about poor
> >performance in a text-parsing program. After a bit of profiling I
> >discovered that reducing GC collection frequency (i.e., GC.disable()
> >then manually call GC.collect() at some interval) improved program
> >performance by about 20%.
> >
> 
> One thing that any remotely production-quality GC does is analyze the
> result of collection with respect to minimal headroom - X % (typically
> 30-50%). If we freed Y % of heap where Y < X, then the GC should
> extend the heap so that it get within X % mark of free space in the
> extended heap.
[...]

Excellent idea. Sounds reasonably simple to implement, though I'm not
exactly familiar with the current GC so I don't know if I'll be able to
implement this myself...


T

-- 
Gone Chopin. Bach in a minuet.

Re: LDC 0.16.0 alpha3 is out! Get it, test it, give feedback!

2015-09-17 Thread Jack Stouffer via Digitalmars-d-announce


On Thursday, 17 September 2015 at 15:19:07 UTC, John Colvin wrote:

dub build --compiler=ldc2 -v

will sometimes let you see more clearly when/where things went 
wrong.


Seems to be a segfault in LDC

$ dub build --force --compiler=ldc2 -v

A bunch of stuff for the dependancies

Using direct -l... flags for dl.
Running ldc2...
ldc2 
-of.dub/build/application-debug-posix.osx-x86_64-ldc_0-C7E5B672CD1184CE7A0D4F80B1606A44/dungeon -d-debug -g -w -oq -od=.dub/obj -d-version=Have_dungeon -d-version=Have_dgame -d-version=Have_derelict_sdl2 -d-version=Have_derelict_util -d-version=Have_derelict_gl3 -Isource/ -I../../../../.dub/packages/dgame-0.6.3/source/ -I../../../../.dub/packages/derelict-sdl2-1.9.7/source/ -I../../../../.dub/packages/derelict-util-2.0.3/source/ -I../../../../.dub/packages/derelict-gl3-1.0.15/source/ source/app.d source/engine.d source/enums.d source/inputhandler.d source/interfaces.d source/objects/enemies.d source/objects/player.d source/states/endgame.d source/states/game.d source/states/main_menu.d source/surfaces.d source/util/quadtree.d source/util/ringbuffer.d ../../../../.dub/packages/dgame-0.6.3/lib/libDgame.a ../../../../.dub/packages/derelict-sdl2-1.9.7/lib/libDerelictSDL2.a ../../../../.dub/packages/derelict-gl3-1.0.15/lib/libDerelictGL3.a ../../../../.dub/packages/derelict-util-!

2.0.3/lib/libDerelictUtil.a -L=-ldl
FAIL 
.dub/build/application-debug-posix.osx-x86_64-ldc_0-C7E5B672CD1184CE7A0D4F80B1606A44/ dungeon executable

Error executing command build:
ldc2 failed with exit code -11.


So I manually copied the command from dub to see what went wrong

$ ldc2 
-of.dub/build/application-debug-posix.osx-x86_64-ldc_0-C7E5B672CD1184CE7A0D4F80B1606A44/dungeon -d-debug -g -w -oq -od=.dub/obj -d-version=Have_dungeon -d-version=Have_dgame -d-version=Have_derelict_sdl2 -d-version=Have_derelict_util -d-version=Have_derelict_gl3 -Isource/ -I../../../../.dub/packages/dgame-0.6.3/source/ -I../../../../.dub/packages/derelict-sdl2-1.9.7/source/ -I../../../../.dub/packages/derelict-util-2.0.3/source/ -I../../../../.dub/packages/derelict-gl3-1.0.15/source/ source/app.d source/engine.d source/enums.d source/inputhandler.d source/interfaces.d source/objects/enemies.d source/objects/player.d source/states/endgame.d source/states/game.d source/states/main_menu.d source/surfaces.d source/util/quadtree.d source/util/ringbuffer.d ../../../../.dub/packages/dgame-0.6.3/lib/libDgame.a ../../../../.dub/packages/derelict-sdl2-1.9.7/lib/libDerelictSDL2.a ../../../../.dub/packages/derelict-gl3-1.0.15/lib/libDerelictGL3.a ../../../../.dub/packages/derelict-util-!

2.0.3/lib/libDerelictUtil.a -L=-ldl
[1]45808 segmentation fault  ldc2  -d-debug -g -w -oq 
-od=.dub/obj -d-version=Have_dungeon -Isource/

Re: FancyPars

2015-09-17 Thread Stefan Koch via Digitalmars-d-announce

On Wednesday, 16 September 2015 at 21:25:40 UTC, Bastiaan Veelo 
wrote:


Thanks. At first I thought that 
fancy_[ast|token|lexer|parser|printer].d were generated files 
because their content is so similar to the code produced in the 
vibe application. But on closer look I think it is the other 
way around: that the example grammar in vibe describes its own 
input format, and that the similarity in the produced output to 
said files is an illustration that it works the way it should. 
Am I close?


fancyPars has gone through a few iterations.
I used fancyPars to generate a parser for itself
and then fixed up the things that fancyPars cannot yet generate.

I eat my own dogfood!

Thanks for the pascal specs and your p2d.d
I will see what I can do about that.

Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX

2015-09-17 Thread Stefan Koch via Digitalmars-d-announce

On Thursday, 17 September 2015 at 15:12:43 UTC, Jacob Carlborg 
wrote:

On 2015-09-17 00:29, ponce wrote:

[...]


Easiest would be to not unload the library. If that doesn't 
work, replace "_dyld_register_func_for_add_image" [1] with 
"dyld_register_image_state_change_handler" [2].


[1] 
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/sections_osx.d#L76


[2] 
http://www.opensource.apple.com/source/dyld/dyld-353.2.3/include/mach-o/dyld_priv.h


dyld_register_image_state_change_handler does not provide a way 
to unregister the callback either, so I don't see how this helps.

Re: FancyPars


On Thursday, 17 September 2015 at 16:02:14 UTC, John Colvin wrote:

Yikes. Are you sure? Are you familiar with open source 
licensing?

I would be open to open-source the "base" of fp.
but keeping certin extentions for grammar analysis closed.

What license would you suggest for that.

Re: Load Qt UI XML File as GUI

2015-09-17 Thread Steven Schveighoffer via Digitalmars-d-learn


On 9/16/15 3:08 PM, Ali Çehreli wrote:

On 09/15/2015 09:36 PM, Steven Schveighoffer wrote:

On 9/16/15 12:03 AM, Mike McKee wrote:

Unfortunately, the http://dsource.org/forums/ doesn't appear to be
active -- I can't login after I registered. This is where the QtD
project has their forum. So, I'm asking this here.


Seems to have moved here, but it doesn't look fresh:

https://bitbucket.org/qtd/

dsource is dead (only there for archive reasons), don't use it.

-Steve


I wonder why this older one exists:

   https://github.com/qtd-developers/qtd

Ali


First line in .md file:

"Fork of bitbucket repo"

I'm guessing it's probably because D likes github?

-Steve

Re: LDC 0.16.0 alpha3 is out! Get it, test it, give feedback!

2015-09-17 Thread John Colvin via Digitalmars-d-announce

On Thursday, 17 September 2015 at 15:15:33 UTC, Jack Stouffer 
wrote:
My dub build is failing with LDC but working with DMD. All I 
get is this unhelpful error message


$ dub build --compiler=ldc2
Target derelict-util 2.0.3 is up to date. Use --force to 
rebuild.
Building derelict-sdl2 1.9.7 configuration "library", build 
type debug.

Running ldc2...
Target derelict-gl3 1.0.15 is up to date. Use --force to 
rebuild.

Building dgame 0.6.3 configuration "lib", build type debug.
Running ldc2...
Building dungeon ~master configuration "application", build 
type debug.

Running ldc2...
FAIL 
.dub/build/application-debug-posix.osx-x86_64-ldc_0-C7E5B672CD1184CE7A0D4F80B1606A44/ dungeon executable

Error executing command build:
ldc2 failed with exit code -11.

How does one debug dub builds?


dub build --compiler=ldc2 -v

will sometimes let you see more clearly when/where things went 
wrong.

Re: LDC 0.16.0 alpha3 is out! Get it, test it, give feedback!

2015-09-17 Thread David Gileadi via Digitalmars-d-announce


On 9/17/15 8:15 AM, Jack Stouffer wrote:

Building dungeon ~master ...


Forgive the unhelpful reply, but this line made me happy :)

Defining compile-time constants?

2015-09-17 Thread Tim K. via Digitalmars-d-learn


Hi!

I am wondering if there is any way to define constants to pass to 
the compiler like in C (especially useful in combination with 
Makefiles, for obvious reasons), i.e.:


gcc -DPREFIX=\"/usr/local\" -o myprogram main.c

Like this a program can look for certain files inside its prefix 
during runtime and the prefix can be modified for installation in 
different locations (like /usr, ~/bin, ...) at compile time.


But how do I do something like this in D? I am using GDC, but I'd 
be interested for solutions for DMD as well. Calling 
standard-library functions at runtime to figure out where the 
binary is located is okay for my current problem as well, but 
it's not as flexible as the "define whatever data at compile time 
and have it available at runtime".



Regards,
Tim

Re: Defining compile-time constants?

2015-09-17 Thread Rikki Cattermole via Digitalmars-d-learn


On 18/09/15 3:32 AM, Tim K. wrote:

Hi!

I am wondering if there is any way to define constants to pass to the
compiler like in C (especially useful in combination with Makefiles, for
obvious reasons), i.e.:

 gcc -DPREFIX=\"/usr/local\" -o myprogram main.c

Like this a program can look for certain files inside its prefix during
runtime and the prefix can be modified for installation in different
locations (like /usr, ~/bin, ...) at compile time.

But how do I do something like this in D? I am using GDC, but I'd be
interested for solutions for DMD as well. Calling standard-library
functions at runtime to figure out where the binary is located is okay
for my current problem as well, but it's not as flexible as the "define
whatever data at compile time and have it available at runtime".


Regards,
Tim


Well string imports, could work.
But you would need to save it to a file first.

Re: FancyPars

2015-09-17 Thread John Colvin via Digitalmars-d-announce


On Thursday, 17 September 2015 at 15:47:42 UTC, Stefan Koch wrote:
On Wednesday, 16 September 2015 at 12:16:03 UTC, Bastiaan Veelo 
wrote:


Sounds like you want to share this, but I can't find a 
licence. In case this turns out to be useful, we would need 
one :-)


If you want I can prepare a PR for that, just let me know 
which licence to pick.


Best,
Bastiaan.


I am not sure.
The source should not be used in any product without my 
explicit permission.
However you may study it to get better in your understanding of 
dlang or parser technology


Yikes. Are you sure? Are you familiar with open source licensing?

Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX

2015-09-17 Thread ponce via Digitalmars-d

On Thursday, 17 September 2015 at 15:12:43 UTC, Jacob Carlborg 
wrote:


Easiest would be to not unload the library.


I don't control what the host program does.


If that doesn't work, replace 
"_dyld_register_func_for_add_image" [1] with 
"dyld_register_image_state_change_handler" [2].


[1] 
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/sections_osx.d#L76


[2] 
http://www.opensource.apple.com/source/dyld/dyld-353.2.3/include/mach-o/dyld_priv.h


Looks good.

Re: Defining compile-time constants?

2015-09-17 Thread Adam D. Ruppe via Digitalmars-d-learn


On Thursday, 17 September 2015 at 15:32:25 UTC, Tim K. wrote:
I am wondering if there is any way to define constants to pass 
to the compiler like in C (especially useful in combination 
with Makefiles, for obvious reasons), i.e.:


My preference is to make an app.config module that lists these 
things as variables (or enums) in ordinary D code. Then tell 
users to edit that file to customize their build. (wp_config.php 
does this and people are reasonably happy with it. You could even 
write a little creation app if you wanted to avoid plain editing 
the file. Like makeconfig PREFIX="/usr/local" and it writes out 
the config.d file.)

Re: Bloat with std.(string.)format?


On Thursday, 17 September 2015 at 15:17:21 UTC, John Colvin wrote:

On Thursday, 17 September 2015 at 13:42:15 UTC, Chris wrote:
On Thursday, 17 September 2015 at 12:49:03 UTC, John Colvin 
wrote:

[...]


Thanks.

That's up to date enough now. Is it stable, though?


Reasonably so in my testing, but expect more bugs than in a 
full release.


For version 2.067.1 it took a long time this time. Maybe we 
should focus some of our efforts on LDC and GCD being up to 
date faster.


It would be great to have more people working on them, yes.


I suppose it's an area most people (including myself) shy away 
from. I know next to nothing about compiler implementation.

[Issue 15076] Get ID of current thread

2015-09-17 Thread Jack Stouffer via Digitalmars-d-announce

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #4 from Vladimir Panteleev  ---
https://github.com/D-Programming-Language/druntime/pull/1388
https://github.com/D-Programming-Language/phobos/pull/3654

(In reply to Jonathan M Davis from comment #2)
> I would think that the most natural thing to do (and what most folks would
> likely look for) would be a static function/property on core.thread.Thread -
> e.g. Thread.currThreadID - since that's where the thread stuff is.

Then we would have three conventions for such functions.

Currently, there is core.thread.getpid and std.process.thisProcessID.
Introducing something that's unlike neither of these would be very
inconsistent.

(In reply to Steven Schveighoffer from comment #3)
> What is the use case for this? Why doesn't Thread.getThis suffice?

Thread.getThis:

1. Returns a pointer, not the OS identifier. The pointer cannot be unique
per-process (esp. in the case of multiple D runtimes).

2. Requires that the current thread is registered with the D runtime. If it
isn't, it returns null.

--

Re: std.experimental.testing formal review

2015-09-17 Thread Atila Neves via Digitalmars-d


On Sunday, 13 September 2015 at 09:59:18 UTC, Dicebot wrote:
1) being able to mark test case as fatal (i.e. if internal 
handshake or sanity check fails there is no point in trying to 
run other tests)


I'm leaning towards not including this now and concentrating on 
getting it
approved - a PR to change std.experimental.testing later will be 
much

easier to deal with than doing it now.

2) being able to do weak ordering of tests (by defining strict 
sequence of groups so that parallelization/randomization only 
happens within such group) - I have used something as simple as 
numerical priority value so far for my needs


I did the check for random runs and renamed @singleThreaded to 
@serial in the PR.


Atila

Re: LDC 0.16.0 alpha3 is out! Get it, test it, give feedback!


On Wednesday, 16 September 2015 at 20:03:15 UTC, Kai Nacke wrote:

Hi everyone,

LDC 0.16.0 alpha3, the LLVM-based D compiler, is available for 
download!


Is there anyway to get dub to use this as a compiler so I can 
test this out?

Re: Why do abstract class functions require definitions?

2015-09-17 Thread Steven Schveighoffer via Digitalmars-d-learn


On 9/16/15 6:36 AM, Marc Schütz wrote:


Wouldn't the following behaviour be more useful as a default?

 abstract class Foo {
 void bar1() { } // non-abstract, obviously
 void bar2();// abstract, because it's in an abstract class
 // (different from now)
 extern void bar3(); // non-abstract, but defined externally
 }



My guess is that .di files need the bar2 syntax style.

-Steve

Re: Bloat with std.(string.)format?

2015-09-17 Thread John Colvin via Digitalmars-d-learn


On Thursday, 17 September 2015 at 13:42:15 UTC, Chris wrote:
On Thursday, 17 September 2015 at 12:49:03 UTC, John Colvin 
wrote:

[...]


Thanks.

That's up to date enough now. Is it stable, though?


Reasonably so in my testing, but expect more bugs than in a full 
release.


For version 2.067.1 it took a long time this time. Maybe we 
should focus some of our efforts on LDC and GCD being up to 
date faster.


It would be great to have more people working on them, yes.

Re: LDC 0.16.0 alpha3 is out! Get it, test it, give feedback!

2015-09-17 Thread Jack Stouffer via Digitalmars-d-announce

On Thursday, 17 September 2015 at 14:51:32 UTC, Jack Stouffer 
wrote:
On Wednesday, 16 September 2015 at 20:03:15 UTC, Kai Nacke 
wrote:

Hi everyone,

LDC 0.16.0 alpha3, the LLVM-based D compiler, is available for 
download!


Is there anyway to get dub to use this as a compiler so I can 
test this out?


My dub build is failing with LDC but working with DMD. All I get 
is this unhelpful error message


$ dub build --compiler=ldc2
Target derelict-util 2.0.3 is up to date. Use --force to rebuild.
Building derelict-sdl2 1.9.7 configuration "library", build type 
debug.

Running ldc2...
Target derelict-gl3 1.0.15 is up to date. Use --force to rebuild.
Building dgame 0.6.3 configuration "lib", build type debug.
Running ldc2...
Building dungeon ~master configuration "application", build type 
debug.

Running ldc2...
FAIL 
.dub/build/application-debug-posix.osx-x86_64-ldc_0-C7E5B672CD1184CE7A0D4F80B1606A44/ dungeon executable

Error executing command build:
ldc2 failed with exit code -11.

How does one debug dub builds?

[Issue 15080] extern(C++) classes have wrong static data layout

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

yebblies  changed:

   What|Removed |Added

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

--

[Issue 15080] extern(C++) classes have wrong static data layout

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

yebblies  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from yebblies  ---
https://github.com/D-Programming-Language/dmd/pull/5096

--

Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX

2015-09-17 Thread Jacob Carlborg via Digitalmars-d


On 2015-09-17 00:29, ponce wrote:

Context: On OSX, a C program can load a D shared library but once
unloaded the next dlopen will crash, jumping into a callback that
doesn't exist anymore.

I've filed it here: https://issues.dlang.org/show_bug.cgi?id=15060


It looks like this was known and discussed several times already:
http://forum.dlang.org/post/vixoqmidlbizawbxm...@forum.dlang.org (2015)
https://github.com/D-Programming-Language/druntime/pull/228 (2012)


Any idea to work-around this problem would be awesome.

I'm not looking for something correct, future-proof, or pretty. Any shit
that still stick to the wall will do. Anything!

The only case I need to support is: C host, D shared library, with
runtime statically linked.

Please help!


Easiest would be to not unload the library. If that doesn't work, 
replace "_dyld_register_func_for_add_image" [1] with 
"dyld_register_image_state_change_handler" [2].


[1] 
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/sections_osx.d#L76


[2] 
http://www.opensource.apple.com/source/dyld/dyld-353.2.3/include/mach-o/dyld_priv.h


--
/Jacob Carlborg

Re: dmd codegen improvements

2015-09-17 Thread jmh530 via Digitalmars-d

On Thursday, 17 September 2015 at 11:57:29 UTC, Bruno Medeiros 
wrote:


*Mind you*: all this I'm saying is pre TDPL book stuff. After 
the book was out, things stabilized.


Can I speak for the people who only became familiar with D after 
TDPL and say I don't really care about what you're talking about?

Re: LDC 0.16.0 alpha3 is out! Get it, test it, give feedback!

2015-09-17 Thread ponce via Digitalmars-d-announce

On Thursday, 17 September 2015 at 14:51:32 UTC, Jack Stouffer 
wrote:
On Wednesday, 16 September 2015 at 20:03:15 UTC, Kai Nacke 
wrote:

Hi everyone,

LDC 0.16.0 alpha3, the LLVM-based D compiler, is available for 
download!


Is there anyway to get dub to use this as a compiler so I can 
test this out?


Put the compiler in your PATH, and use the --compiler=ldc2 flag 
in DUB

Re: Bloat with std.(string.)format?

On Thursday, 17 September 2015 at 12:49:03 UTC, John Colvin wrote:

On Thursday, 17 September 2015 at 10:53:17 UTC, Chris wrote:
On Thursday, 17 September 2015 at 10:33:44 UTC, John Colvin
wrote:

Some initial bloat is expected, format is pretty big
(although twice as big is a lot, unless your original code
was quite small?).

It was in a test program. Only a few lines. But it would still
add a lot of bloat in a program that uses it in different
modules, wouldn't it?

The upfront cost is paid only once per unique template
arguments per binary. So no, it doesn't scale badly there.

Inlining, on the other hand, will - roughly speaking - increase
binary sizes linearly with the number of calls. That's the cost
you pay for (hopefully) better performance.

The extra bloat per call is likely due to inlining. I would
hope that dmd would spot consecutive inlining of the same
function and merge them, but perhaps it doesn't.

You could certainly make a less feature complete
implementation of format that is smaller.

Don't know if it's worth the trouble.

I would say not worth it, unless you have a real problem with
binary sizes for an actual finished product. Even then, I'd say
you could get bigger, easier gains by messing around with
-fvisibility settings, --gc-sections, strip etc. on GDC and LDC

Have you tried with ldc or gdc. In particular, have you tried
using ldc with --gc-sections on linux?

Not yet. GDC and LDC always lag behind (this time
considerably), so I'm usually stuck with DMD for development.

That's a shame.
https://github.com/ldc-developers/ldc/releases/tag/v0.16.0-alpha3 is at 2.067.1, is that not up-to-date enough?

Thanks.

That's up to date enough now. Is it stable, though? For version
2.067.1 it took a long time this time. Maybe we should focus some
of our efforts on LDC and GCD being up to date faster.

[Issue 15080] New: extern(C++) classes have wrong static data layout

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

  Issue ID: 15080
   Summary: extern(C++) classes have wrong static data layout
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: C++, wrong-code
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: yebbl...@gmail.com

import core.stdc.stdio;

extern(C++) class C
{
uint x = 1;
uint y = 2;

void func() {}
}
extern(C++) class D : C
{
uint z = 3;

override void func() {}
}

__gshared D c = new D();

void main()
{
printf("%u\n", c.x);
printf("%u\n", c.y);
printf("%u\n", c.z);
}

The offsets are wrong because dmd assumes there is always a monitor word.

--

[Issue 15076] Get ID of current thread

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #3 from Steven Schveighoffer  ---
What is the use case for this? Why doesn't Thread.getThis suffice?

--

Re: running code on the homepage

2015-09-17 Thread nazriel via Digitalmars-d

On Wednesday, 16 September 2015 at 20:52:08 UTC, Andrei 
Alexandrescu wrote:

On 09/16/2015 09:49 AM, nazriel wrote:
1-2 days more and we will be done with it so IMHO no need take 
any

additionals steps for it right now.


That's great, thanks for doing this. What is the current status 
with regard to making the online compilation infrastructure 
publicly accessible and improvable? Ideally everything would be


That's the plan.
Currently I am working on upgrading both frontend and backend to 
be up-to-date with current requirements. I am also trying to 
integrate the look of dpaste.dzfl.pl to match the one on 
dlang.org so we could make dpaste part of the *.dlang.org fleet.


Once I am done with those things (should take up to 2 weeks) - 
the whole product - frontend and backend will be fully 
open-sourced and available on github for forking.


Currently my main focus is on making Backend less restrictive so 
we can spawn threads, run all examples from dlang.org without 
restrictions etc.


The backend will be the first thing that will be open-sourced and 
it should happen before end of the current week (19.09.2015).



in the open, and we (= the fledgling D Language Foundation) 
would pay for the server infrastructure. Please advise, thanks.


I still need to catch up with Vladimir via @ if he is OK with 
moving dpaste backend into dedicated unprivileged LinuX 
Container. If yes - then probably we can stick with his server - 
if not we should discuss other options.


For the first 2 weeks it will run it on my server - but I would 
prefer to not place it on my server - in case I disappear for a 
while again ;)



-- Andrei


Best regards,
Damian Ziemba

Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX

2015-09-17 Thread John Colvin via Digitalmars-d-announce


On Thursday, 17 September 2015 at 16:17:11 UTC, bitwise wrote:
On Thursday, 17 September 2015 at 10:12:57 UTC, Walter Bright 
wrote:

On 9/16/2015 11:40 PM, ponce wrote:
On Wednesday, 16 September 2015 at 23:24:29 UTC, bitwise 
wrote:


I was trying to solve this one myself, but the modifications 
to DMD's backend

that are needed are out of reach for me right now.

If you're willing to build your own druntime, you may be 
able to get by.


I'd prefer a solution that works with existing compilers, but 
maybe building a

custom LDC is possible if I figure it out.


I seriously doubt this issue has anything to do with the 
compiler's code generator back end. It's more likely the 
problem is in druntime.


Based on previous posts you've made, it seems you already know 
that Martin's solution involves having DMD's back end add linux 
style ctors/dtors to the COMDAT section of every compiled D 
file, so I'm not sure what you mean by this.


If a callback provided to _dyld_register_func_for_add_image 
does not call sections_osx_onAddImage, then it must be called 
somehow.


   Bit


One solution which could work is to disallow static linking of 
druntime on OSX completelymeaning, either don't even 
distribute a static druntime for OSX, or make shared druntime the 
default. This way, druntime would only ever be initialized once 
per process. Knowing this, linux ctors/dtors could be added to 
druntime to initialize it, eliminating the need to call 
rt_init/rt_term before and after main(). Also, if druntime were 
loaded into a C-hosted binary, druntime would automatically be 
initialized by the ctors/dtors. Also, for the ctors/dtors, they 
could be added to the druntime build, and wouldn't having to be 
compiler generated.


I'm not sure about the difference in performance cost over static 
vs shared druntime, but it seems that this is the way things are 
done on OSX. If you look in /usr/lib/ on a mac, practically 
everything is a shared lib.


Bit

Re: FancyPars


On Thursday, 17 September 2015 at 16:33:12 UTC, Stefan Koch wrote:
On Thursday, 17 September 2015 at 16:02:14 UTC, John Colvin 
wrote:


Yikes. Are you sure? Are you familiar with open source 
licensing?

I would be open to open-source the "base" of fp.
but keeping certin extentions for grammar analysis closed.

What license would you suggest for that.


Assuming you wrote it all, you can license the code in whatever 
way you want. See http://choosealicense.com for more info. You 
can even use multiple licenses, or different licenses for 
different parts of the code.

Re: Behavior of opEquals


On 09/09/2015 09:20 PM, Timon Gehr wrote:


On 09/09/2015 01:32 AM, Jonathan M Davis wrote: (moved from above)

I really don't see any reason why it would even make sense to declare
operators separately from a type.


One reason is that single dispatch can be awkward. A textbook example
would be: ...


I just noticed that I missed to concretely mention one obvious use case:

Overloading mutating operators on reference types with ("logical") value 
semantics, possibly in combination with hash consing. E.g. 
classObject++, or classObject+=x.

Re: Passing Arguments on in Variadic Functions

2015-09-17 Thread jmh530 via Digitalmars-d-learn


On Monday, 14 September 2015 at 20:26:56 UTC, jmh530 wrote:

Thanks to you both. This works perfect.


I noticed that there's some interesting interplay with this 
technique and default arguments.


From below, it is required that you put the ones with default 
arguments last. If there are only two arguments, then it takes 
the second to be the default argument. However, I can't actually 
put just one argument, even though V is variadic and sample is a 
default. That seems strange to me because it makes it seem like 
sample really isn't optional.


Not sure if this is a bug or on purpose. The only way I can 
resolve it is by writing another function that just takes x 
(alternately one that takes x and sample only also works).


Also, it doesn't seem to let me put template constraints on V so 
that I could do something like constrain V to be numeric.


import std.algorithm : sum;
import std.stdio : writeln;

auto test(T, V ...)(T x, V seed, bool sample=true)
{
auto sum_x = sum(x, seed);
if (sample)
return sum_x;
else
return sum_x / 2;
}

void main()
{
int[] x = [10, 5, 15, 20, 30];
writeln(test(x, true));
writeln(test(x, false));
float seed = 1;
writeln(test(x, seed, true));
writeln(test(x, seed, false));
}

Re: Pretty Printing TickDuration

2015-09-17 Thread Nordlöw via Digitalmars-d-learn


On Thursday, 17 September 2015 at 16:54:02 UTC, Nordlöw wrote:

How do I convert an instance of `TickDuration` to that format?


Solution:

writeln("> Query took ", sw.peek().to!Duration);

Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX

2015-09-17 Thread Taylor Hillegeist via Digitalmars-d-learn


On Thursday, 17 September 2015 at 16:54:09 UTC, ponce wrote:

On Thursday, 17 September 2015 at 16:42:52 UTC, bitwise wrote:

[...]


I use static linking of druntime already all the time and rely 
on it to be able to do something instead of nothing (where 
would I even found that shared druntime?). Apart from this one 
horrible bug, static runtime seems very much working. Remove 
possibilities to do work would make my situation worse.


I can call rt_init / rt_term at the right place with LDC global 
constructor/destructors no problem. The problem is this 
callback that cannot be removed. Don't know why it's there in 
the first place since by definition a shared library can't 
control when it's unloaded.


It seems that you either haven't read, or did not understand my 
previous posts. This is a complicated problem, and unless you're 
willing to dig much deeper into it, then you'll have to deal with 
things the way they are.


   Bit

why are opCmp and opEquals not pure.

2015-09-17 Thread Stefan Koch via Digitalmars-d


Hi,
is there any reason why opCmp and opEquals are not pure ?
I would argue it is very counter-intuitive to mutate any state 
when comparing objects.


opCmp and opEquals not being annotated pure is a major problem 
for me in writing ctfe-able code.


since any call to Object.opEquals need to be warped in another 
function to be able to cast the Function pure.

Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX

2015-09-17 Thread ponce via Digitalmars-d


On Thursday, 17 September 2015 at 16:42:52 UTC, bitwise wrote:


One solution which could work is to disallow static linking of 
druntime on OSX completelymeaning, either don't even 
distribute a static druntime for OSX, or make shared druntime 
the default. This way, druntime would only ever be initialized 
once per process. Knowing this, linux ctors/dtors could be 
added to druntime to initialize it, eliminating the need to 
call rt_init/rt_term before and after main(). Also, if druntime 
were loaded into a C-hosted binary, druntime would 
automatically be initialized by the ctors/dtors. Also, for the 
ctors/dtors, they could be added to the druntime build, and 
wouldn't having to be compiler generated.


I'm not sure about the difference in performance cost over 
static vs shared druntime, but it seems that this is the way 
things are done on OSX. If you look in /usr/lib/ on a mac, 
practically everything is a shared lib.


Bit


I use static linking of druntime already all the time and rely on 
it to be able to do something instead of nothing (where would I 
even found that shared druntime?). Apart from this one horrible 
bug, static runtime seems very much working. Remove possibilities 
to do work would make my situation worse.


I can call rt_init / rt_term at the right place with LDC global 
constructor/destructors no problem. The problem is this callback 
that cannot be removed. Don't know why it's there in the first 
place since by definition a shared library can't control when 
it's unloaded.

Pretty Printing TickDuration

2015-09-17 Thread Nordlöw via Digitalmars-d-learn


Currently

import std.datetime: StopWatch;
StopWatch sw;
sw.start;
writeln(sw.peek());

prints for instance

TickDuration(279483)

I've seen Phobos doing something much more clever such as pretty 
printing of time in the format:


1 hour, 2 seconds, 3 milliseconds, etc.

How do I convert an instance of `TickDuration` to that format?

Re: Creating a DLL with a ActiveX interface.

On Wednesday, 16 September 2015 at 16:08:47 UTC, Taylor 
Hillegeist wrote:

export extern (Windows) void SayHello(Variant *Input_Variant)
{
string A = "HELLO WORLD!";
Input_Variant.CA_VariantSetCString(A.ptr);
}



So I made a terrible error. Looking at 
http://lunesu.com/uploads/ModernCOMProgramminginD.pdf
of the http://dlang.org/interface.html page I was given the 
impression that std.variant was a transparently equivalent to the 
com VARIANT. however:


std.variant != VARIANT for com

if anyone knows how to easily convert between the two i would be 
happy to know.


I did find a nice library for VARIANT: 
https://github.com/JesseKPhillips/Juno-Windows-Class-Library

Re: dmd codegen improvements

2015-09-17 Thread Laeeth Isharc via Digitalmars-d

On Thursday, 17 September 2015 at 11:47:36 UTC, Bruno Medeiros 
wrote:

On 17/09/2015 08:10, Joakim wrote:
Yeah, I was a bit stunned that that is what Bruno took from 
your post.
I don't think anybody would question that writing a C or C++ 
compiler in
the '80s and '90s had value, and I'm sure you did pretty well 
off them,

considering you retired at 42
(http://www.drdobbs.com/architecture-and-design/how-i-came-to-write-d/240165322).



I didn't say that Walter's previous work didn't bring *any* 
value to the software world. It's not like people challenged 
him to write efficient lolcode or brainfuck(*) compilers, or 
some other silly challenge, which if he did would have a been a 
massive waste of time - even if it was technically a very 
admirable feat.


(*) - Yeah those languages weren't around at the time, but 
that's just an example.


My point was that one would certainly bring *more* value to the 
software world, if that is the primary focus of one's career, 
instead of merely proving people wrong.


That doesn't mean either one has to be an emotionless robot 
that never does something just for the sake of ego-boosting 
(which is really the only reward of proving people wrong - 
unless there are some monetary or other resources at stake). 
But Walter has so many stories of "I did this [massive project] 
to prove people wrong." which is what makes me wonder if there 
isn't too much focus on ego validation.


Human beings are funny creatures, and able people like to be 
stretched to the limit of what's possible.  Having someone tell 
you there is no way you can do that is a hint that it's quite a 
difficult problem, and yet you may correctly perceive how it may 
be done.  A highly talented person of this sort has many ways in 
which in theory they might add most value, but many fewer viable 
ways, because they find it harder than most to do what they don't 
want to do.  (And creativity comes when you are following a path 
that is within you).  Cattell and Eysenck wrote about this, and 
lately Professor Bruce Charlton at Iqpersonalitygenius blog.


Plus, following what moves you may be a better guide than 
rational optimisation given that with the latter one is often 
fooling oneself since one doesn't even understand the structure 
of social calculus.


I personally find Walter's attitude quite inspiring, although I 
am not familiar with the pre TDPL days and not so interested at 
this moment.  At least you can say that he recognizes that 
management is difficult for him and did bring Andrei alongside, 
not something easy to do to yield total control.

Re: Passing Arguments on in Variadic Functions

2015-09-17 Thread Adam D. Ruppe via Digitalmars-d-learn


On Thursday, 17 September 2015 at 17:35:18 UTC, jmh530 wrote:
I noticed that there's some interesting interplay with this 
technique and default arguments.


Yeah, it expects the V... to consume the rest of the arguments so 
it doesn't really leave any room for the default arg.


I would actually just make it required or do separate functions 
with it. Optional and variadics don't mix well together.


(You could also loop through and look for a bool argument 
yourself but that is a bit messier.)


Also, it doesn't seem to let me put template constraints on V 
so that I could do something like constrain V to be numeric.


import std.meta;
import std.traits;

if(allSatisfy!(isNumeric, V))

should do it

Re: Creating a DLL with a ActiveX interface.

2015-09-17 Thread Adam D. Ruppe via Digitalmars-d-learn

On Thursday, 17 September 2015 at 17:58:49 UTC, Taylor Hillegeist 
wrote:
if anyone knows how to easily convert between the two i would 
be happy to know.


You'll just need to write an adapter... I started a minimal one 
here:


https://github.com/adamdruppe/com/blob/master/comhelpers.d#L123

but it was just getting... and I only supported string and int. 
But the same basic idea is both ways, break it up into basic 
families of types (string, int, float, pointer, whatever else) 
and convert to from by manually setting the type thing.

bug? for(int i=0;i<1;) vs while(true)


http://pastebin.com/fknwgjtz

i tried to call fibers in a loop forever, to multiplex some 
networking client worker fibers and a listener fiber

it seems to work correctly with  for(int i=0;i<1;)

with while(true) i get:

C:\dev\server_client>dub
Building server_client ~master configuration "application", build 
type debug.

Compiling using dmd...
source\app.d(72): Warning: statement is not reachable
FAIL 
.dub\build\application-debug-windows-x86-dmd_2068-32A80D3C074EAD350DDE74DB2

61C6BB5\ server_client executable
Error executing command run:
dmd failed with exit code 1.

How not to run after a DUB build ?

2015-09-17 Thread BBasile via Digitalmars-d-learn


Each time I execute

`dub.exe --build=release` (or any other the build type)

DUB tries to run the project after the build.

This generates often generates an error when dub process returns 
(and even if the build is OK) but actually I don't want DUB to 
run after building. Is there a switch to avoid the exexution 
after the build ?

[Issue 15081] New: [Vector Extensions]

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

  Issue ID: 15081
   Summary: [Vector Extensions]
   Product: D
   Version: D2
  Hardware: x86_64
   URL: http://dlang.org/
OS: Windows
Status: NEW
  Severity: minor
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: 00peb...@bsu.edu

void axpy (float[] x, const float[] y, const float a) {
x[] = a*x[] + y[];
}

void axpy1 (float[] x, const float[] y, const float a) {
x[] *= a;
x[] += y[];
}

void axpy2(float[] x, const float[] y, const float a) {
size_t index = 0;
for (;index < x.length; index++) {
x[index] = a * x[index] + y[index];
}
}

axpy1 and axpy2 compile fine, but axpy only compiles if I omit the const on the
"y" parameter.

Error message is:
Error: invalid array operation cast(const(float)[])(a * x[]) + y[] (possible
missing [])

Not clear to me why a*x[] is being cast to const or where the extra [] could be
inserted. Seems like maybe underlying implementation doesn't support a binary
operator between scalars and vectors, only an opAssign when one is const and
the other isn't.


 It appears the scalar multiply results in a const float[] and then

--

Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX

2015-09-17 Thread Jacob Carlborg via Digitalmars-d


On 2015-09-17 18:20, bitwise wrote:


dyld_register_image_state_change_handler does not provide a way to
unregister the callback either, so I don't see how this helps.


The dynamic library holding the callback is pinned. See the 
implementation of registerImageStateSingleChangeHandler, the first few 
lines.


[1] http://www.opensource.apple.com/source/dyld/dyld-353.2.3/src/dyld.cpp

--
/Jacob Carlborg

Re: Operator overloading or alternatives to expression templates


On 09/15/2015 06:53 PM, Andrei Alexandrescu wrote:

On 09/14/2015 03:35 PM, Timon Gehr wrote:

On 09/14/2015 08:09 PM, Andrei Alexandrescu wrote:

On 09/13/2015 10:06 AM, Martin Nowak wrote:

...
- language regularization

   It's surprising to find these "arbitrary" language limitations.
   The non-predictability of what's possible has always been a huge
issue
for me with C++, i.e. you come up with an idea, spend 4 hours
implementing it only to find out that the small detail x isn't
feasible.


This is the case in all powerful languages.


That's an overgeneralization.


Aren't they all :o).
...


I guess we have now established that there are at least two of them. :P


Furthermore, having arbitrary designed-in irregularities is not
comparable to implementing a system whose emergent behavior is not
understood sufficiently well. (D is guilty of both, but the former is
much easier to fix than the latter.)


Martin Odersky told me there's a constant problem with Scala ...


Both C++ and Scala have accidentally Turing-complete type systems.


I think what I'm trying to say is "I'm trying to do this very advanced
thing and the language support is insufficient" is the kind of argument
that needs to be made and taken with caution.
...


This is certainly the case, and I believe the necessary care has been 
applied. The language support required isn't actually very advanced, nor 
are all usage scenarios. Arbitrary restrictions are usually design mistakes.

Re: bug? for(int i=0;i<1;) vs while(true)


using DMD32 D Compiler v2.068.0 on windows x64

Re: why are opCmp and opEquals not pure.


On 09/17/2015 09:47 PM, Timon Gehr wrote:


Not all reasonable implementation are.


implementations

mysql-native: SQL Transaction support?

2015-09-17 Thread salvari via Digitalmars-d-learn

I'm using mysql-native library for massive data load. I've been 
trying to use transactions to improve performance but it doesn't 
seem to work.


I'm parsing a text input file, the generated sql is about 1 
million lines of SQL. By using mysql-native it takes about 4 
hours to load data.


I've tried to divide the sql in transactions by calling:

auto cmdStartTran = cdb.Command("start transaction;");
cmdStartTran.execSQL();

And some inserts later:
auto cmdCommit = cdb.Command("commit;");
cmdCommit.execSQL();

Parsing the input file to plain sql and executing the one million 
lines into the db takes more or less the same 4 hours.


But, by using transactions in the text file, the performance 
improves dramatically: 60 sec to load all data.


Is it posible that my mysql-native database connection has 
autocommit activated? How can I know?

Re: why are opCmp and opEquals not pure.


On 09/17/2015 08:37 PM, Stefan Koch wrote:

Hi,
is there any reason why opCmp and opEquals are not pure ?


Not all reasonable implementation are. Arguably, the methods shouldn't 
even be on Object.



I would argue it is very counter-intuitive to mutate any state when
comparing objects.
...


Not if it is done to improve performance, but not visible semantics.


opCmp and opEquals not being annotated pure is a major problem for me in
writing ctfe-able code.

since any call to Object.opEquals need to be warped in another function
to be able to cast the Function pure.



I don't get this point. You don't need any annotations to write 
ctfe-able code. Also, I think there were some efforts to make a template 
out of core.object.opEquals, in order to preserve the attributes. (Such 
that, as long as one doesn't work with plain Objects, the missing pure 
annotation would have no influence.)

Re: bug? for(int i=0;i<1;) vs while(true)

2015-09-17 Thread Stefan Koch via Digitalmars-d-announce


On Thursday, 17 September 2015 at 19:43:02 UTC, H. S. Teoh wrote:
On Thu, Sep 17, 2015 at 07:32:13PM +, ddos via 
Digitalmars-d-learn wrote:

http://pastebin.com/fknwgjtz

i tried to call fibers in a loop forever, to multiplex some 
networking

client worker fibers and a listener fiber
it seems to work correctly with  for(int i=0;i<1;)

with while(true) i get:

C:\dev\server_client>dub
Building server_client ~master configuration "application", 
build type

debug.
Compiling using dmd...
source\app.d(72): Warning: statement is not reachable
FAIL
.dub\build\application-debug-windows-x86-dmd_2068-32A80D3C074EAD350DDE74DB2
61C6BB5\ server_client executable
Error executing command run:
dmd failed with exit code 1.


Maybe just write:

for (;;) {
...
}

instead?  You can read `(;;)` as "ever". :-P

Also, could you post a (possibly reduced) code example that can 
be compiled?  It's kinda hard to figure out what's wrong when 
the code in the paste is incomplete.



T


yeah i tried for(;;) and it generates the same warning :)
sure, here is the full example, it's not too long anyways
( the example doesn't make much sense tho because socket.accept 
is blocking :P )

http://pastebin.com/9K0wRRD6

ps: pastebin needs D support :-D

Re: bug? for(int i=0;i<1;) vs while(true)

2015-09-17 Thread H. S. Teoh via Digitalmars-d-learn

On Thu, Sep 17, 2015 at 07:32:13PM +, ddos via Digitalmars-d-learn wrote:
> http://pastebin.com/fknwgjtz
> 
> i tried to call fibers in a loop forever, to multiplex some networking
> client worker fibers and a listener fiber
> it seems to work correctly with  for(int i=0;i<1;)
> 
> with while(true) i get:
> 
> C:\dev\server_client>dub
> Building server_client ~master configuration "application", build type
> debug.
> Compiling using dmd...
> source\app.d(72): Warning: statement is not reachable
> FAIL
> .dub\build\application-debug-windows-x86-dmd_2068-32A80D3C074EAD350DDE74DB2
> 61C6BB5\ server_client executable
> Error executing command run:
> dmd failed with exit code 1.

Maybe just write:

for (;;) {
...
}

instead?  You can read `(;;)` as "ever". :-P

Also, could you post a (possibly reduced) code example that can be
compiled?  It's kinda hard to figure out what's wrong when the code in
the paste is incomplete.


T

-- 
Любишь кататься - люби и саночки возить.

Re: FancyPars


On Thursday, 17 September 2015 at 16:55:42 UTC, John Colvin wrote:

Assuming you wrote it all, you can license the code in whatever 
way you want. See http://choosealicense.com for more info. You 
can even use multiple licenses, or different licenses for 
different parts of the code.


Hmm reading this. No license, is best for now.

@Bastian
  The FancyPars Grammar for pascal will look very very different 
from what you wrote.

  In FancyPars Grammars I worked very hard to avoid repetitions.
  FGPs do not just describe the language grammar. They are 
describing the AST-Structure.
  So just by reading the grammar a person working with the AST 
will know what is what and in which members-variables of the 
AST-Node which information is stored.
  I would recommed you open issues in the FancyPars-repo for 
stuff that is hard to understand.

Re: bug? for(int i=0;i<1;) vs while(true)

2015-09-17 Thread Adam D. Ruppe via Digitalmars-d-learn


On Thursday, 17 September 2015 at 19:32:16 UTC, ddos wrote:

source\app.d(72): Warning: statement is not reachable


What's there? Anything after an endless loop is potentially 
unreachable and dub treats warnings as errors.


With the for loop, the compiler can't be as sure that it is 
endless because plain for loops often have their variable changed 
inside and the compiler just isn't smart enough to actually check 
for that too.

Re: How not to run after a DUB build ?

2015-09-17 Thread BBasile via Digitalmars-d-learn


On Thursday, 17 September 2015 at 19:36:10 UTC, BBasile wrote:

Each time I execute

`dub.exe --build=release` (or any other the build type)

DUB tries to run the project after the build.

This generates often generates an error when dub process 
returns (and even if the build is OK) but actually I don't want 
DUB to run after building. Is there a switch to avoid the 
exexution after the build ?


NVM, just get that 'build' and '--build=' are two different 
things.


with  `dub.exe build --build=release` nothing is executed...

Re: bug? for(int i=0;i<1;) vs while(true)

On Thursday, 17 September 2015 at 19:35:05 UTC, Adam D. Ruppe 
wrote:
What's there? Anything after an endless loop is potentially 
unreachable and dub treats warnings as errors.


i see, thx

Re: Desperately looking for a work-around to load and unload D shared libraries from C on OSX

On Thursday, 17 September 2015 at 19:20:34 UTC, Jacob Carlborg 
wrote:

On 2015-09-17 18:20, bitwise wrote:

dyld_register_image_state_change_handler does not provide a 
way to

unregister the callback either, so I don't see how this helps.


The dynamic library holding the callback is pinned. See the 
implementation of registerImageStateSingleChangeHandler, the 
first few lines.


[1] 
http://www.opensource.apple.com/source/dyld/dyld-353.2.3/src/dyld.cpp


Ok, but this kinda defeats the purpose, as the op wants to unload 
the library ;)


Bit

[Issue 15081] [Vector Extensions]

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

Paul Buis <00peb...@bsu.edu> changed:

   What|Removed |Added

   Keywords||rejects-valid

--

[Issue 12752] std.algorithm.isPermutation