Re: std.experimental.checkedint is ready for comments!

[Walter Bright via Digitalmars-d]

On 6/17/2016 7:20 PM, tsbockman wrote:

It's been on DUB since before this review started, and I plan to support it
(including incorporating some of the feedback from this thread).


Thanks, that's a good plan.

Re: Issues getting DCD to work on Windows

[Mike Parker via Digitalmars-d-learn]

On Friday, 17 June 2016 at 16:58:42 UTC, OpenJelly wrote:
Trying to set up an IDE on Windows 7 with code completion but 
my issues keep coming back to DCD. The tests failed the one 
time I could get the tests to go beyond it waiting for another 
instance of DCD to close. The path is added to my PATH 
variable, I've rebuilt it from source with the .bat file to 
install it on Windows and rebuilt it with dub as per the github 
instructions... I even changed one of its source files to 
import winsock2 instead of winsock because the build output 
kept warning me about a depreciation... probably made it worse 
as I've now got prompts telling me about Socket OS Exceptions.


Anyone got a clue what I could be doing wrong and how I can fix 
it?


I compiled it with dub and started using it with VS Code just 
fine. Now and again a Socket exception pops up, but it works. You 
say you're running the tests? That means you compiled it, right?


dub build --build=release

You might want to add -ax86_64 to that as well if you are running 
64-bit Windows.

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Saturday, 18 June 2016 at 01:28:38 UTC, Walter Bright wrote:

On 6/17/2016 4:38 PM, tsbockman wrote:
This is, of course, his prerogative as lead designer for 
Phobos, but it also

kills any interest I have in working on the project for free.



You know, I do sympathize, even if I don't agree. One big 
motivation for D in the first place was the C++ community not 
being interested in my contributions. Ironically, they're 
adopting them one by one anyway :-)


Indeed, D has many excellent ideas. I hope that some day you'll 
consider allowing a breaking "D3" though, as the D language 
design also has a great deal of technical debt accumulated from 
the blitz of feature additions in D2.


If that debt can be payed off, I don't think that any of the 
currently popular languages could compete with it.


If you're not interested in continuing with this, I suggest 
packaging it up and making it available via Dub. Sort of let 
the marketplace decide.


It's been on DUB since before this review started, and I plan to 
support it (including incorporating some of the feedback from 
this thread).

Re: ARSD PNG memory usage

[Adam D. Ruppe via Digitalmars-d-learn]

On Saturday, 18 June 2016 at 01:57:49 UTC, Joerg Joergonson wrote:
Ok. Also, maybe the GC hasn't freed some of those temporaries 
yet.


The way GC works in general is it allows allocations to just 
continue until it considers itself under memory pressure. Then, 
it tries to do a collection. Since collections are expensive, it 
puts them off as long as it can and tries to do them as 
infrequently as reasonable. (some GCs do smaller collections to 
spread the cost out though, so the details always differ based on 
implementation)


So, you'd normally see it go up to some threshold then stabilize 
there, even if it is doing a lot of little garbage allocations.


However, once the initialization is done here, it shouldn't be 
allocating any more. The event loop itself doesn't when all is 
running normally.

Templated class defaults and inheritence

[Joerg Joergonson via Digitalmars-d-learn]

I have something like

class X;
class subfoo : X;
class subbaz : X;

class foo : X
{
subfoo bar;
}

class baz : X;


which I have modified so that

class subbaz : subfoo;
class baz : foo;

(essentially baz is now a derivation of foo while before it was 
of X)


the problem is that subbaz uses subfoo bar; when it also needs to 
use a derived type. (so it is a full derivation of foo and subfoo)



To accomplish that I parameterized foo so I can do

class foo!T : X
{
T bar;
}


and I can now do

class baz : foo!subbaz;


There are two problems with this though:


1. How can I create a default foo!(T = subfoo) so I can just 
instantiate classes like new foo() and it is the same as 
foo!subfoo()? I tried creating a class like class foo : 
foo!subfoo; but I get a collision. I guess an alias will work 
here just fine though?(just thought of it)


2. The real problem is that baz isn't really a true derivation of 
foo like it should be. foo!subfoo and foo!subbaz are different 
types. I want the compiler to realize that foo!subbaz(and hence 
baz) is really a derived foo!subfoo and ultimately X.


I'm pretty sure D can do this, just haven't figure out how.

Thanks.

Re: ARSD PNG memory usage

[Adam D. Ruppe via Digitalmars-d-learn]

On Saturday, 18 June 2016 at 01:20:16 UTC, Joerg Joergonson wrote:
Error: undefined identifier 'sleep', did you mean function 
'Sleep'?		


"import core.thread; sleep(10);"


It is `Thread.sleep(10.msecs)` or whatever time - `sleep` is a 
static member of the Thread class.



They mention to use PeekMessage and I don't see you doing that, 
not sure if it would change things though?


I am using MsgWaitForMultipleObjectsEx which blocks until 
something happens. That something can be a timer, input event, 
other message, or an I/O thing... it doesn't eat CPU unless 
*something* is happening.

Re: ARSD PNG memory usage

[Joerg Joergonson via Digitalmars-d-learn]

On Saturday, 18 June 2016 at 01:46:32 UTC, Adam D. Ruppe wrote:
On Saturday, 18 June 2016 at 01:44:28 UTC, Joerg Joergonson 
wrote:
I simply removed your nextpowerof2 code(so the width and 
height wasn't being enlarged) and saw no memory change). 
Obviously because they are temporary buffers, I guess?


right, the new code free() them right at scope exit.

If this is the case, then maybe there is one odd temporary 
still hanging around in png?


Could be, though the png itself has relatively small overhead, 
and the opengl texture adds to it still. I'm not sure if video 
memory is counted by task manager or not... but it could be 
loading up the whole ogl driver that accounts for some of it. I 
don't know.


Ok. Also, maybe the GC hasn't freed some of those temporaries 
yet. What's strange is that when the app is run, it seems to do a 
lot of small allocations around 64kB or something for about 10 
seconds(I watch the memory increase in TM) then it stabilizes. 
Not a big deal, just seems a big weird(maybe some type of lazy 
allocations going on)



Anyways, I'm much happier now ;) Thanks!

Re: ARSD PNG memory usage

[Adam D. Ruppe via Digitalmars-d-learn]

On Saturday, 18 June 2016 at 01:44:28 UTC, Joerg Joergonson wrote:
I simply removed your nextpowerof2 code(so the width and height 
wasn't being enlarged) and saw no memory change). Obviously 
because they are temporary buffers, I guess?


right, the new code free() them right at scope exit.

If this is the case, then maybe there is one odd temporary 
still hanging around in png?


Could be, though the png itself has relatively small overhead, 
and the opengl texture adds to it still. I'm not sure if video 
memory is counted by task manager or not... but it could be 
loading up the whole ogl driver that accounts for some of it. I 
don't know.

Re: ARSD PNG memory usage

[Joerg Joergonson via Digitalmars-d-learn]

On Friday, 17 June 2016 at 14:39:32 UTC, kinke wrote:

On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:

LDC x64 uses about 250MB and 13% cpu.

I couldn't check on x86 because of the error

phobos2-ldc.lib(gzlib.c.obj) : fatal error LNK1112: module 
machine type 'x64' conflicts with target machine type 'X86'


not sure what that means with gzlib.c.ojb. Must be another bug 
in ldc alpha ;/


It looks like you're trying to link 32-bit objects to a 64-bit 
Phobos.
The only pre-built LDC for Windows capable of linking both 
32-bit and 64-bit code is the multilib CI release, see 
https://github.com/ldc-developers/ldc/releases/tag/LDC-Win64-master.



Yes, it looks that way but it's not the case I believe(I did 
check when this error first came up). I'm using the phobo's libs 
from ldc that are x86.


I could be mistaken but

phobos2-ldc.lib(gzlib.c.obj)

suggests that the problem isn't with the entire phobos lib but 
gzlib.c.obj and that that is the only one marked incorrectly, 
since it's not for all the other imports, it seems something got 
marked wrong in that specific case?

Re: ARSD PNG memory usage

[Joerg Joergonson via Digitalmars-d-learn]

On Saturday, 18 June 2016 at 00:56:57 UTC, Joerg Joergonson wrote:

On Friday, 17 June 2016 at 14:48:22 UTC, Adam D. Ruppe wrote:

[...]


Yes, same here! Great! It runs around 122MB in x86 and 107MB 
x64. Much better!



[...]


Yeah, strange but good catch! It now works in x64! I modified 
it to to!wstring(title).dup simply to have the same title and 
classname.



[...]


I have the opposite on memory but not a big deal.



[...]


I will investigate this soon and report back anything. It 
probably is something straightforward.



[...]


I found this on non-power of 2 textures:

https://www.opengl.org/wiki/NPOT_Texture


https://www.opengl.org/registry/specs/ARB/texture_non_power_of_two.txt

It seems like it's probably a quick and easy add on and you 
already have the padding code, it could easily be optional(set 
a flag or pass a bool or whatever).


it could definitely same some serious memory for large textures.

e.g., a 3000x3000x4 texture takes about 36MB or 2^25.1 bytes. 
Since this has to be rounded up to 2^26 = 67MB, we almost have 
doubled the amount of wasted space.


Hence, allowing for non-power of two would probably reduce the 
memory footprint of my code to near 50MB(around 40MB being the 
minimum using uncompressed textures).


I might try to get a working version of that at some point. 
Going to deal with the cpu thing now though.


Thanks again.


Never mind about this. I wasn't keeping in mind that these 
textures are ultimately going to end up in the video card memory.


I simply removed your nextpowerof2 code(so the width and height 
wasn't being enlarged) and saw no memory change). Obviously 
because they are temporary buffers, I guess?


If this is the case, then maybe there is one odd temporary still 
hanging around in png?

Re: std.experimental.checkedint is ready for comments!

[Walter Bright via Digitalmars-d]

On 6/17/2016 4:38 PM, tsbockman wrote:

This is, of course, his prerogative as lead designer for Phobos, but it also
kills any interest I have in working on the project for free.



You know, I do sympathize, even if I don't agree. One big motivation for D in 
the first place was the C++ community not being interested in my contributions. 
Ironically, they're adopting them one by one anyway :-)


If you're not interested in continuing with this, I suggest packaging it up and 
making it available via Dub. Sort of let the marketplace decide.

Re: ARSD PNG memory usage

[Joerg Joergonson via Digitalmars-d-learn]

The CPU usage is consistently very low on my computer. I still 
don't know what could be causing it for you, but maybe it is 
the temporary garbage... let us know if the new patches make a 
difference there.




Ok, I tried the breaking at random method and I always ended up 
in system code and no stack trace to... seems it was an alternate 
thread(maybe GC?). I did a sampling profile and got this:


Function Name   Inclusive  Exclusive Inclusive % Exclusive %
_DispatchMessageW@4 10,361  5   88.32   0.04
[nvoglv32.dll]  7,874   745 67.12   6.35
_GetExitCodeThread@85,745   5,745   48.97   48.97
_SwitchToThread@0   2,166   2,166   18.46   18.46

So possibly it is simply my system and graphics card. For some 
reason NVidia might be using a lot of cpu here for no apparent 
reason?


DispatchMessage is still taking quite a bit of that though?


Seems like someone else has a similar issue:

https://devtalk.nvidia.com/default/topic/832506/opengl/nvoglv32-consuming-a-ton-of-cpu/


https://github.com/mpv-player/mpv/issues/152


BTW, trying sleep in the MSG loop

Error: undefined identifier 'sleep', did you mean function 
'Sleep'?		


"import core.thread; sleep(10);"

;)

Adding a Sleep(10); to the loop dropped the cpu usage down to 
0-1% cpu!


http://stackoverflow.com/questions/33948837/win32-application-with-high-cpu-usage/33948865

Not sure if that's the best approach though but it does work.

They mention to use PeekMessage and I don't see you doing that, 
not sure if it would change things though?

pure D jpeg encoder, public domain

[ketmar via Digitalmars-d-announce]

as a complement to jpeg decoder, here[1] is jpeg encoder from the 
same author. surprisingly, it is more than two times smaller; i 
took a look at it and decided: why, we should have both!


author claims that is supports baseline grayscale and RGB jpegs. 
i tested it on some images i have, but no heavily testing was 
done. it *should* work, though, as it is straightforward port.


it is completely independent of decoder, and self-contained.

unlicense, the same as encoder. yep, i know, i know, i'm very 
sorry. fork it and relicense!



[1] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/jpege.d

Re: ARSD PNG memory usage

[Joerg Joergonson via Digitalmars-d-learn]

On Friday, 17 June 2016 at 14:48:22 UTC, Adam D. Ruppe wrote:

On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:
ok, then it's somewhere in TrueColorImage or the loading of 
the png.


So, opengltexture actually does reallocate if the size isn't 
right for the texture... and your image was one of those sizes.


The texture pixel size needs to be a power of two, so 3000 gets 
rounded up to 4096, which means an internal allocation.


But it can be a temporary one! So ketmar tackled png.d's 
loaders' temporaries and I took care of gamehelper.d's...


And the test program went down about to 1/3 of its memory 
usage. Try grabbing the new ones from github now and see if it 
works for you too.




Yes, same here! Great! It runs around 122MB in x86 and 107MB x64. 
Much better!




Well, It works on LDC x64! again ;) This seems like an issue 
with DMD x64? I was thinking maybe it has to do the layout of 
the struct or something, but not sure.


I have a fix for this too, though I don't understand why it 
works


I just .dup'd the string literal before passing it to Windows. 
I think dmd is putting the literal in a bad place for these 
functions (they do bit tests to see if it is a pointer or an 
atom, so maybe it is in an address where the wrong bits are set)




Yeah, strange but good catch! It now works in x64! I modified it 
to to!wstring(title).dup simply to have the same title and 
classname.


In any case, the .dup seems to fix it, so all should work on 32 
or 64 bit now. In my tests, now that the big temporary arrays 
are manually freed, the memory usage is actually slightly lower 
on 32 bit, but it isn't bad on 64 bit either.


I have the opposite on memory but not a big deal.


The CPU usage is consistently very low on my computer. I still 
don't know what could be causing it for you, but maybe it is 
the temporary garbage... let us know if the new patches make a 
difference there.


I will investigate this soon and report back anything. It 
probably is something straightforward.


Anyways, We'll figure it all out at some point ;) I'm really 
liking your lib by the way. It's let me build a gui and get a 
lot done and just "work". Not sure if it will work on X11 with 
just a recompile, but I hope ;)



It often will! If you aren't using any of the native event 
handler functions or any of the impl.* members, most things 
just work (exception being the windows hotkey functions, but 
those are marked Windows anyway!). The basic opengl stuff is 
all done for both platforms. Advanced opengl isn't implemented 
on Windows yet though (I don't know it; my opengl knowledge 
stops in like 1998 with opengl 1.1 so yeah, I depend on 
people's contributions for that and someone did Linux for me, 
but not Windows yet. I think.)


I found this on non-power of 2 textures:

https://www.opengl.org/wiki/NPOT_Texture


https://www.opengl.org/registry/specs/ARB/texture_non_power_of_two.txt

It seems like it's probably a quick and easy add on and you 
already have the padding code, it could easily be optional(set a 
flag or pass a bool or whatever).


it could definitely same some serious memory for large textures.

e.g., a 3000x3000x4 texture takes about 36MB or 2^25.1 bytes. 
Since this has to be rounded up to 2^26 = 67MB, we almost have 
doubled the amount of wasted space.


Hence, allowing for non-power of two would probably reduce the 
memory footprint of my code to near 50MB(around 40MB being the 
minimum using uncompressed textures).


I might try to get a working version of that at some point. Going 
to deal with the cpu thing now though.


Thanks again.

[Issue 16152] dpl-docs/ddox doesn't show documentation for eponymous template member

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 16152] dpl-docs/ddox doesn't show documentation for eponymous template member

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/73c6475e4be442350a727d80e562bb2328f494b1
Merge pull request #1373 from s-ludwig/master

Fix issue 16152 - Fix merging of eponymous template doc comments.

--

[Issue 12699] Possibly wrong code in object_.d

[via Digitalmars-d-bugs]

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

David Nadlinger  changed:

   What|Removed |Added

 CC||c...@klickverbot.at

--- Comment #2 from David Nadlinger  ---
Somewhat related to issue 12516 in that the API shouldn't be @trusted in the
first place.

--

[Issue 12516] TypeInfo.getHash should not be trusted

[via Digitalmars-d-bugs]

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

David Nadlinger  changed:

   What|Removed |Added

   Keywords||safe
 CC||c...@klickverbot.at

--

Re: std.experimental.checkedint is ready for comments!

[Walter Bright via Digitalmars-d]

On 6/17/2016 3:17 PM, Robert burner Schadek wrote:

* Andrei, Walter create a specific task list and designs


I do all the time. The net result - nothing happens.

People do what they want to do when it's volunteer work. Presenting people with 
a list of things to work on does not result in work getting done on it.



> you two have to delegate/trust other people/lieutenants

We've done a lot of that. For example, Andrei is in charge of the library. 
Several people are empowered to pull stuff. Brad is in charge of the autotester 
and bugzilla. Martin handles releases. Mike is in charge of the blog. Dicebot 
recently took charge of DIPs. Etc. etc.


A common theme there, however, is they are self-selected. Assigning people to do 
things has never worked.


Realistically, however, the review of SafeInt was delegated. tsbockman received 
a lot of feedback, advice, and ideas from the community. If Andrei's comments 
are all wrong-headed, that's one thing. But if they are on target, then we as a 
community need to get better when we advise and comment on proposals. Including me.



> rant off

So please excuse my counter-rant :-)

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Friday, 17 June 2016 at 20:49:54 UTC, Walter Bright wrote:

On 6/17/2016 7:52 AM, tsbockman wrote:
What caught me off guard here isn't that Andrei had to approve 
it in some sense
- it's that the judgment of everyone else who approved my 
design seemingly
became irrelevant the moment that Andrei decided he could do 
better.


History is full of examples of individuals who decide they can 
do better, against all conventional wisdom, and are eventually 
proven correct.


That has nothing to do with my point: "better" is subjective, and 
I thought the judgment and goals of others would be given more 
weight.


Andrei has an enviable track record in the industry of having 
disruptive ideas that later became mainstream. He's also very 
well paid as a consultant to give advice to the programming 
teams of companies. His comments are worthy of serious 
consideration.


I have a finite amount of time, energy, and motivation to work on 
this.


I might have considered his proposed expansion of the scope of 
the project if it had come earlier, when I was actively seeking 
input from people about what features were important to them. 
That connection did not happen, though.


Regardless, it is not clear to me that his requirements are 
actually compatible with mine; I don't really care how wonderful 
his ideas are if he's trying to solve a (subtly) different 
problem than I am. As far as I can tell, Andrei is perfectly 
willing to sacrifice my requirements to make room in his 
complexity "budget" for his own.


This is, of course, his prerogative as lead designer for Phobos, 
but it also kills any interest I have in working on the project 
for free.

Re: pure D JPEG decoder, with progressive JPEG support, public domain

[ketmar via Digitalmars-d-announce]

On Friday, 17 June 2016 at 23:17:56 UTC, Xinok wrote:

On Friday, 17 June 2016 at 22:15:47 UTC, ketmar wrote:
i put it under unlicense[1], as some other works of the same 
author is using it, and it is basically the same PD.


[1] http://unlicense.org/


Unfortunately, using unlicense is just as problematic as using 
public domain:


https://programmers.stackexchange.com/questions/147111/what-is-wrong-with-the-unlicense


alas, that is all i can do without breaking the "spirit" of the 
original terms. i'm ok with it, and people still can fork the 
code and relicense in under Boost/MIT.

Re: pure D JPEG decoder, with progressive JPEG support, public domain

[Xinok via Digitalmars-d-announce]

On Friday, 17 June 2016 at 22:15:47 UTC, ketmar wrote:
i put it under unlicense[1], as some other works of the same 
author is using it, and it is basically the same PD.


[1] http://unlicense.org/


Unfortunately, using unlicense is just as problematic as using 
public domain:


https://programmers.stackexchange.com/questions/147111/what-is-wrong-with-the-unlicense

The next best thing is the CC0 license (Creative Commons Zero) 
which is better written than unlicense but it's currently not 
recommended for software / source code.


http://copyfree.org/content/standard/licenses/cc0/license.txt

After that, the most-open licenses with good legal standing would 
be Boost and MIT but then you run into the same issues again with 
incompatible licenses.


I don't have any recommendations but I thought it was worth 
pointing out that unlicense isn't the solution here.

Re: Garbage Collector

[dewitt via Digitalmars-d]

On Friday, 17 June 2016 at 21:47:36 UTC, Joerg Joergonson wrote:

On Friday, 17 June 2016 at 04:20:23 UTC, Jonathan Marler wrote:

On Wednesday, 15 June 2016 at 13:38:33 UTC, ketmar wrote:

On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote:

[...]


you are wrong. and you definitely know nothing about garbage 
collection, virtual machines and code generation. i wonder 
why people keep coming with "suggestions" and "solutions" 
without even a small knowledge in problem field.


That's pretty harsh Ketmar.  It's obvious he knows the general 
ideas and was just wondering if using the .NET GC was a viable 
option.  I think responding to others in such a demeaning way 
is harmful to the D community as it isolates people.  It 
doesn't encourage people to be curious or want to start a 
discussion.  Having people, especially newcomers to D come in 
and make suggestions and solutions is a great thing for a 
community.  It means they saw enough potential in the language 
to want to know more and maybe even how they could contribute.


It also makes ketmar look like a tard and childish. Konstantin 
said he 'believed' something then ketmar responded with a 
fallacious attack. Maybe ketmar needs to take his meds? ;)


The idea that "a community" cannot create a GC is false.  It is 
not too complex as there are plenty of complex projects that are 
community driven.  A better assumption would be he doesn't 
believe THIS community can create a GC.  Not that I believe 
either because there is no reason a community driven GC would not 
be successful. There are plenty of good GCs out there like Java's 
for instance and work great for the ecosystem of the language but 
even if we had the greatest then some D devs would still be upset 
because a lot of D devs come from C/C++ and do not want the GC.   
 Both statements made assumptions and I do not think they are 
even close to the worst things said on this forum.  ppl chill a 
little.  Light one up, Drink one, put some rounds down range, 
whatever you gotta do to lighten up a little.

Re: std.experimental.checkedint is ready for comments!

[Robert burner Schadek via Digitalmars-d]

What you said is true, but IMO you're missing the point.

IMO the current D Process is just backward. Having people working 
on stuff openly, with intend for phobos inclusion, for a lot of 
months and that putting it up for review clearly does not work.
And if you and/or Andrei at that point say "Na". That is just 
frustrating, no matter how good the reasons are.


So I propose that you and Andrei create a list of high level 
goals for the compiler as well as for phobos/druntime. Nothing 
abstract, specific stuff properly also design specifics. And 
attach explanations why those things should be done.


For example:

Stuff that needs to be in phobos:
* sync/async Database abstraction that is nogc
* Value Range Integer type
* 

I think you get the idea about the list.
Than you write in big letters.
"To everybody that wants to contribute a modules to phobos look 
at the above list and pick you module. All other module ideas may 
be rejected for whatever reason by Andrei. If you have an idea 
for a module not on the list get the design approved by Andrei 
before you start coding to avoid frustration later."


I know, this is an open source project and you can't tell people 
what to do because you don't pay us any money. But you could tell 
us what you think is important to make D number one. At least 
then people know what the lay of the land is and don't have to 
guess. And by saying "yes" or "no" at the end of the development 
of new stuff, you're actually doing this already. Only at the 
wrong point in time, IMO.



Additionally, IMO at some point you two have to delegate/trust 
other people/lieutenants. You two simply don't have the time to 
do all the necessary reviewing to make the D Process scale. And 
you two make mistakes as well. core.checkedint and etc.c.odbc is 
just deadbeef. (Please nobody start a discussion about that here. 
Even if those two module are a success, last time I checked 
Walter and Andrei are human so they make mistakes. And Andrei 
actually said so at DConf as well.)



So an action list from my POV.
* Andrei, Walter create a specific task list and designs
* make this list obvious to find. github README (See comment 
above) 
* disable the auto quote feature of the forum. This feature is 
just poisonous for the discussion culture of this forum. 
Everybody is just trying to disprove the other without actually 
trying to bring the discussion/D forward.
* something like https://github.com/facebook/mention-bot would be 
nice. It will properly also help finding lieutenants.


rant off

p.s. Warning: Parent post is not quoted. Ignore Explain Fit it 
for me

I f** hate it.

Re: pure D JPEG decoder, with progressive JPEG support, public domain

[ketmar via Digitalmars-d-announce]

On Friday, 17 June 2016 at 13:35:58 UTC, John Colvin wrote:

On Friday, 17 June 2016 at 13:05:47 UTC, ketmar wrote:
finally, the thing you all waited for years is here! pure D 
no-frills JPEG decoder with progressive JPEG support! Public 
Domain! one file! no Phobos or other external dependecies! it 
even has some DDoc! grab it[1] now while it's hot!


[1] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/jpegd.d


awesome.

Without wanting to start a huge thing about this, see 
http://linuxmafia.com/faq/Licensing_and_Law/public-domain.html 
and http://www.rosenlaw.com/lj16.htm and please at least add an 
optional licencing under a traditional permissive open-source 
license (boost would be nice, who knows, maybe phobos should 
have jpeg support?).


i put it under unlicense[1], as some other works of the same 
author is using it, and it is basically the same PD.


[1] http://unlicense.org/

Re: ARSD PNG memory usage

[Joerg Joergonson via Digitalmars-d-learn]

On Friday, 17 June 2016 at 14:48:22 UTC, Adam D. Ruppe wrote:

On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:

[...]


So, opengltexture actually does reallocate if the size isn't 
right for the texture... and your image was one of those sizes.


[...]



Cool, I'll check all this out and report back. I'll look into the 
cpu issue too.


Thanks!

Re: Garbage Collector

[Joerg Joergonson via Digitalmars-d]

On Friday, 17 June 2016 at 04:20:23 UTC, Jonathan Marler wrote:

On Wednesday, 15 June 2016 at 13:38:33 UTC, ketmar wrote:

On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote:

[...]


you are wrong. and you definitely know nothing about garbage 
collection, virtual machines and code generation. i wonder why 
people keep coming with "suggestions" and "solutions" without 
even a small knowledge in problem field.


That's pretty harsh Ketmar.  It's obvious he knows the general 
ideas and was just wondering if using the .NET GC was a viable 
option.  I think responding to others in such a demeaning way 
is harmful to the D community as it isolates people.  It 
doesn't encourage people to be curious or want to start a 
discussion.  Having people, especially newcomers to D come in 
and make suggestions and solutions is a great thing for a 
community.  It means they saw enough potential in the language 
to want to know more and maybe even how they could contribute.


It also makes ketmar look like a tard and childish. Konstantin 
said he 'believed' something then ketmar responded with a 
fallacious attack. Maybe ketmar needs to take his meds? ;)

Re: Variadic function with parameters all of a specific type

[ketmar via Digitalmars-d-learn]

On Friday, 17 June 2016 at 21:20:01 UTC, Timon Gehr wrote:

On 17.06.2016 23:00, Nordlöw wrote:
I want to create a function that takes a variadic number of 
arguments
all of a specific type, say T, without having to create 
GC-allocated

heap array.

Is there a better way than:

f(Args...)(Args args)
 if (allSameType!(Args, T);

in terms of template bloat?


alias T=int;

void foo(T[] a...)@nogc{}

void bar()@nogc{
foo(1,2,3);
}


this. the compiler is smart, it is creating a slice of stack 
memory here. note that you can't just assign `a` to, for example, 
global or member: when execution of `foo` ends, `a` will still 
point to stack memory. if you need to store `a` somewhere, be 
sure to `.dup` it.

Re: Variadic function with parameters all of a specific type

[Timon Gehr via Digitalmars-d-learn]

On 17.06.2016 23:00, Nordlöw wrote:

I want to create a function that takes a variadic number of arguments
all of a specific type, say T, without having to create GC-allocated
heap array.

Is there a better way than:

f(Args...)(Args args)
 if (allSameType!(Args, T);

in terms of template bloat?


alias T=int;

void foo(T[] a...)@nogc{}

void bar()@nogc{
foo(1,2,3);
}

Re: How to get access to Voldemort / private thingies

[cy via Digitalmars-d-learn]

On Friday, 17 June 2016 at 19:49:18 UTC, Johan Engelen wrote:

Hi all,
  Is there another way to get access to Voldemort class 
methods, or private class members, other than using


Voldemort data is pretty well protected though. Because unlike 
protection attributes, modularizing stuff in functions actually 
means something.


I mean, D doesn't exactly make it easy. You can't normally define 
a function in a different file it's declared in. But if you use 
extern(C) to avoid mangling getObject, you can pretty much 
provide interface.d and secrets.o and without analyzing the 
binary machine code, there's no way to tell the size or nature of 
what getObject returns, aside from that it (claims) to have 
pointers to functions that match the interface.


interface.d:
interface Object { ... };
extern(C) Object getObject();

secrets.d:
class Vold : Object { ... };
extern(C) Object getObject() { ... return new Vold(...); ... }

secrets.o: 

Because of the guarantee that you can link to opaque .o files, 
there's no general way to introspect into just what a function 
does, because that function might not have any source at all.


(I suppose you could instrument "new" itself in the raw runtime, 
to at least get the size of it. Assuming it wasn't malloc'd, or 
static...)

Re: Button: A fast, correct, and elegantly simple build system.

[jmh530 via Digitalmars-d-announce]

On Monday, 30 May 2016 at 19:16:50 UTC, Jason White wrote:


Note that this is still a ways off from being production-ready. 
It needs some polishing. Feedback would be most appreciated 
(file some issues!). I really want to make this one of the best 
build systems out there.




I found the beginning of the tutorial very clear. I really liked 
that it can produce a png of the build graph. I also liked the 
Lua build description for DMD. Much more legible than the make 
file.


However, once I got to the "Going Meta: Building the Build 
Description" section of the tutorial, I got a little confused.


I found it a little weird that the json output towards the end of 
the tutorial don't always match up. Like, where did the .h files 
go from the inputs? (I get that they aren't needed for running 
gcc, but you should mention that) Why is it displaying cc instead 
of gcc? I just feel like you might be able to split things up a 
little and provide a few more details. Like, this is how to do a 
base version, then say this is how you can customize what is 
displayed. Also, it's a little terse on the details of things 
like what the cc.binary is doing. Always err on the side of 
explaining things too much rather than too little, IMO.

Variadic function with parameters all of a specific type

[Nordlöw via Digitalmars-d-learn]

I want to create a function that takes a variadic number of 
arguments all of a specific type, say T, without having to create 
GC-allocated heap array.


Is there a better way than:

f(Args...)(Args args)
if (allSameType!(Args, T);

in terms of template bloat?

Re: std.experimental.checkedint is ready for comments!

[Walter Bright via Digitalmars-d]

On 6/17/2016 7:52 AM, tsbockman wrote:

What caught me off guard here isn't that Andrei had to approve it in some sense
- it's that the judgment of everyone else who approved my design seemingly
became irrelevant the moment that Andrei decided he could do better.


History is full of examples of individuals who decide they can do better, 
against all conventional wisdom, and are eventually proven correct. Andrei has 
an enviable track record in the industry of having disruptive ideas that later 
became mainstream. He's also very well paid as a consultant to give advice to 
the programming teams of companies. His comments are worthy of serious 
consideration.




This implies that the only safe way to go about design a new module, is to
collaborate closely with Andrei from the start.


The goal is to have only the best in Phobos, even if the process of getting 
there is inefficient, frustrating, and slow. D has moved beyond the point where 
we can accept anything less.


A beneficial, leveraging side effect is improving the skills of the people doing 
the work by coaching, reviewing, and critiquing the work. Andrei's review of 
SafeInt has elements that apply to just about everything in Phobos - things we 
all need to get better at.


I'd like to see his review here morphed into a best practices checklist others 
can use when reviewing Phobos code.

[Issue 16181] Overloading doesn't consider default arguments with regards to ambiguity

[via Digitalmars-d-bugs]

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

Danila Letunovskiy  changed:

   What|Removed |Added

 CC||kap...@mail.ru

--- Comment #1 from Danila Letunovskiy  ---
And this Error

int foo(int a, int b=2){
return a + b;
}

int foo(float a){
return a;
}

void main() {
writeln( foo(12) );
}

--

Re: Button: A fast, correct, and elegantly simple build system.

[H. S. Teoh via Digitalmars-d-announce]

On Fri, Jun 17, 2016 at 07:30:42PM +, Fool via Digitalmars-d-announce wrote:
> On Friday, 17 June 2016 at 08:23:50 UTC, Atila Neves wrote:
> > I agree, but CMake/ninja, tup, regga/ninja, reggae/binary are all
> > correct _and_ fast.
> 
> 'Correct' referring to which standards? There is an interesting series
> of blog posts by Mike Shal:
> 
> http://gittup.org/blog/2014/03/6-clobber-builds-part-1---missing-dependencies/
> http://gittup.org/blog/2014/05/7-clobber-builds-part-2---fixing-missing-dependencies/
> http://gittup.org/blog/2014/06/8-clobber-builds-part-3---other-clobber-causes/
> http://gittup.org/blog/2015/03/13-clobber-builds-part-4---fixing-other-clobber-causes/

To me, "correct" means:

- After invoking the build tool, the workspace *always* reflects a
  valid, reproducible build. Regardless of initial conditions, existence
  or non-existence of intermediate files, stale files, temporary files,
  or other detritus. Independent of environmental factors. Regardless of
  whether a previous build invocation was interrupted in the middle --
  the build system should be able to continue where it left off,
  reproduce any partial build products, and produce exactly the same
  products, bit for bit, as if it had not been interrupted before.

- If anything changes -- and I mean literally ANYTHING -- that might
  cause the build products to be different in some way, the build tool
  should detect that and update the affected targets accordingly the
  next time it's invoked.  "Anything" includes (but is not limited to):

   - The contents of source files, even if the timestamp stays
 identical to the previous version.

   - Change in compiler flags, or any change to the build script itself;

   - A new version of the compiler was installed on the system;

   - A system library was upgraded / a new library was installed that
 may get picked up at link time;

   - Change in environment variables that might cause some of the build
 commands to work differently (yes I know this is a bad thing -- it
 is not recommended to have your build depend on this, but the point
 is that if it does, the build tool ought to detect it).

   - Editing comments in a source file (what if there's a script that
 parses comments? Or ddoc?);

   - Reverting a patch (that may leave stray source files introduced by
 the patch).

   - Interrupting a build in the middle -- the build system should be
 able to detect any partially-built products and correctly rebuild
 them instead of picking up a potentially corrupted object in the
 next operation in the pipeline.

- As much as is practical, all unnecessary work should be elided. For
  example:

   - If I edit a comment in a source file, and there's an intermediate
 compile stage where an object file is produced, and the object file
 after the change is identical to the one produced by the previous
 compilation, then any further actions -- linking, archiving, etc.
 -- should not be done, because all products will be identical.

   - More generally, if my build consists of source file A, which gets
 compiled to intermediate product B, which in turn is used to
 produce final product C, then if A is modified, the build system
 should regenerate B. But if the new B is identical to the old B,
 then C should *not* be regenerated again.

  - Contrariwise, if modifications are made to B, the build system
should NOT use the modified B to generate C; instead, it should
detect that B is out-of-date w.r.t. A, and regenerate B from A
first, and then proceed to generate C if it would be different
from before.

   - Touching the timestamp of a source file or intermediate file should
 *not* cause the build system to rebuild that target, if the result
 will actually be bit-for-bit identical with the old product.

   - In spite of this work elision, the build system should still ensure
 that the final build products are 100% reproducible. That is, work
 is elided if and only if it is actually unnecessary; if a comment
 change actually causes something to change (e.g., ddocs are
 different now), then the build system must rebuild all affected
 subsequent targets.

- Assuming that a revision control system is in place, and a workspace
  is checked out on revision X with no further modifications, then
  invoking the build tool should ALWAYS, without any exceptions, produce
  exactly the same outputs, bit for bit.  I.e., if your workspace
  faithfully represents revision X in the RCS, then invoking the build
  tool will produce the exact same binary products as anybody else who
  checks out revision X, regardless of their initial starting
  conditions.

   - E.g., I may be on revision Y, then I run svn update -rX, and there
 may be stray intermediate files strewn around my workspace that are
 not in a fresh checkout of revision X, the build tool should still
 

Re: How to get access to Voldemort / private thingies

[cy via Digitalmars-d-learn]

On Friday, 17 June 2016 at 20:12:53 UTC, cy wrote:

  writeln("see ",wow," for any equipment you need.");


Oh, and as you can see it's important to automate that, so you 
don't make any mistakes while copying.

Slice expressions - exact evaluation order, dollar

[kinke via Digitalmars-d]

The following snippet is interesting:

<<<
__gshared int step = 0;
__gshared int[] globalArray;

ref int[] getBase()
{
assert(step == 0);
++step;
return globalArray;
}

int getLowerBound(size_t dollar)
{
assert(step == 1);
++step;
assert(dollar == 0);
globalArray = [ 666 ];
return 1;
}

int getUpperBound(size_t dollar)
{
assert(step == 2);
++step;
assert(dollar == 1);
globalArray = [ 1, 2, 3 ];
return 3;
}

// LDC issue #1433
void main()
{
auto r = getBase()[getLowerBound($) .. getUpperBound($)];
assert(r == [ 2, 3 ]);
}




Firstly, it fails with DMD 2.071 because $ in the upper bound 
expression is 0, i.e., it doesn't reflect the updated length (1) 
after evaluating the lower bound expression. LDC does.
Secondly, DMD 2.071 throws a RangeError, most likely because it's 
using the initial length for the bounds checks too.


Most interesting IMO though is the question when the slicee's 
pointer is to be loaded. This is only relevant if the base is an 
lvalue and may therefore be modified when evaluating the bound 
expressions. Should the returned slice be based on the slicee's 
buffer before or after evaluating the bounds expressions?
This has been triggered by 
https://github.com/ldc-developers/ldc/issues/1433 as LDC loads 
the pointer before evaluating the bounds.

How to get access to Voldemort / private thingies

[Johan Engelen via Digitalmars-d-learn]

Hi all,
  Is there another way to get access to Voldemort class methods, 
or private class members, other than using "pragma(mangle, ...)" 
on user symbols?


Example code:

In library, and _should not_ be changed :
```
Object getObject() {
class Vold : Object {
int store;
this(int i) {
   store = i;
}
}
return new Vold(2);
}

class Thread
{
 private:
 static struct AAA
 {
  int i;
 }
__gshared AAA*  sm_cbeg;
}
```

And then the code seeking access:
```
pragma(mangle, "mangled name of Vold's constructor")
private extern(C) void defaultTraceInfoCtor(Object) @nogc;

struct A
{
int i;
}
__gshared extern {
pragma(mangle, "the mangled symbol name") A* sm_cbeg;
}
```

Go mad on the "code seeking access" :-) The problem is that the 
types of `defaultTraceInfoCtor` and `sm_cbeg` are incorrect. If I 
can get the types to match (internally in the compiler), I'm 
happy.


Thanks,
  Johan

Re: Button: A fast, correct, and elegantly simple build system.

[Fool via Digitalmars-d-announce]

On Friday, 17 June 2016 at 08:23:50 UTC, Atila Neves wrote:
I agree, but CMake/ninja, tup, regga/ninja, reggae/binary are 
all correct _and_ fast.


'Correct' referring to which standards? There is an interesting 
series of blog posts by Mike Shal:


http://gittup.org/blog/2014/03/6-clobber-builds-part-1---missing-dependencies/
http://gittup.org/blog/2014/05/7-clobber-builds-part-2---fixing-missing-dependencies/
http://gittup.org/blog/2014/06/8-clobber-builds-part-3---other-clobber-causes/
http://gittup.org/blog/2015/03/13-clobber-builds-part-4---fixing-other-clobber-causes/

Re: Debugging D in windows

[moe via Digitalmars-d-debugger]

On Friday, 17 June 2016 at 09:24:10 UTC, Rainer Schuetze wrote:



On 16.06.2016 22:56, moe wrote:

On Thursday, 16 June 2016 at 07:40:17 UTC, moe wrote:

[...]



I still can't get past this error. It might be worth 
mentioning that the
problem only occurs when building for 64bit with the -m64 
flag. Is this

a known issue? Does D have problems with 64bit on windows?


The 64-bit version uses the linker and the runtime of the 
Visual C installation.


Check the [Environment64] section in sc.ini in the 
dmd2\windows\bin folder: it should set the LIB environment 
variable to the library folder of your Visual C installation. 
The dmd installer usually does this automatically, but might 
have failed for some reason or you have opted out of detecting 
it. In the latter case you should open the "VS x64 Native Tools 
Command Prompt" to invoke dmd.


Awesome!

I just downloaded the zip file and adjusted some environment 
variables manually. I removed it again and used the installer 
instead. The sc.ini file now shows all the correct path and 
everything works as expected.


Thanks for taking the time to answer!

Re: dlang-requests 0.1.7 released

[ikod via Digitalmars-d-announce]

On Tuesday, 14 June 2016 at 14:59:37 UTC, Andrei Alexandrescu 
wrote:

On 6/11/16 7:03 PM, ikod wrote:

Hello,

Dlang-requests is library created under influence of 
Python-requests,

with primary goal of easy to use and performance.


...


Thanks! Does the project have a dub presence? How does it 
compare feature-wise and speed-wise with curl? -- Andrei


Hello,

Finally, I made some improvements and run minimal performance 
tests against command-line curl. I wrote simple code for file 
download using dlang-requests, run it and curl for the same 
urls(httpbin server on my notebook) and compare "total", 
"system", and "user" time for different cases. You can find 
numbers and code below.
So my conclusion is - performances are comparable for these 
cases, but there is some field for improvement in dlang-requests.


Case 1 - 50Mb of random data, no any encoding
Case 2 - 50Mb of random data, transfer chunked
Case 3 - 50Mb of random data, transfer chunked, content gzip

  measured times, sec
-
 |   user|   system  |   total
 Case|---|---|---
 | d-r | curl|  d-r| curl| d-r | curl
-|-|-|-|-|-|-
  1  | 0.17| 0.14| 0.20| 0.32| 51.7| 52.2
  2  | 0.19| 0.11| 0.15| 0.21| 51.8| 51.9
  3  | 0.21| 0.15| 0.11| 0.15| 51.5| 52.1


import std.stdio;
import requests;

pragma(lib, "ssl");
pragma(lib, "crypto");

void main()
{
auto sink = File("/dev/null", "wb");
auto rq = Request();
rq.useStreaming = true;
auto rs = 
rq.get("http://127.0.0.1:8080/stream-bytes/5120;);

auto stream = rs.receiveAsRange();
while(!stream.empty) {
sink.rawWrite(stream.front);
stream.popFront;
}
}

Re: std.parallelism.taskPool daemon threads not terminating

[Moritz Maxeiner via Digitalmars-d-learn]

On Friday, 17 June 2016 at 14:29:57 UTC, Russel Winder wrote:


A priori, assuming I am not missing anything, this behaviour 
seems entirely reasonable.


I agree that when using non-daemon threads (and I personally 
think that should be the default) that it is. But I cannot bring 
that into accord with the documentation of taskPool (the 
property)[1]:



Returns a lazily initialized global instantiation of TaskPool.
[...]
The worker threads in this pool are daemon threads, meaning 
that it is not necessary to call TaskPool.stop or 
TaskPool.finish before terminating the main thread.


A daemon thread is automatically terminated when all non-daemon 
threads have terminated.
A non-daemon thread will prevent a program from terminating as 
long as it has not terminated.


The above - while not explicitly stating that daemon-threads do 
not prevent a program from terminating - are - to me - strongly 
suggesting it (and if they do indeed not, then I would ask how 
daemon threads are differnt from non-daemon threads in the 
context of TaskPool, since I'm unable to make it out from the 
documentation).


The task is an infinite loop so it never terminates. This means 
the threadpool does not stop working, which means the program 
does not terminate.


Yes, that example is intentionally chosen that way to make my 
point. I initially discovered this while putting of a synchronous 
read of STDIN in a loop, but that example might have diverted 
attention to something other than I intended.




I suspect that daemon may not mean what you think it means. At 
least not with respect to the threadpool.


I do, too, which is why I asked here, since after having read the 
relevant documentation several times with significant time delay 
in between I still cannot make out how else to interpret it (and 
I got no reply in #dlang IRC).


[1] https://dlang.org/library/std/parallelism/task_pool.html

[Issue 16178] Can't alias a mixin

[via Digitalmars-d-bugs]

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

Danila Letunovskiy  changed:

   What|Removed |Added

 CC||kap...@mail.ru

--- Comment #1 from Danila Letunovskiy  ---
вот так ещё можно

mixin("alias foo = " ~ bar!T ~ ";");

--

Issues getting DCD to work on Windows

[OpenJelly via Digitalmars-d-learn]

Trying to set up an IDE on Windows 7 with code completion but my 
issues keep coming back to DCD. The tests failed the one time I 
could get the tests to go beyond it waiting for another instance 
of DCD to close. The path is added to my PATH variable, I've 
rebuilt it from source with the .bat file to install it on 
Windows and rebuilt it with dub as per the github instructions... 
I even changed one of its source files to import winsock2 instead 
of winsock because the build output kept warning me about a 
depreciation... probably made it worse as I've now got prompts 
telling me about Socket OS Exceptions.


Anyone got a clue what I could be doing wrong and how I can fix 
it?

Re: Different struct sizeof between linux and windows

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, June 17, 2016 13:21:04 Vladimir Panteleev via Digitalmars-d-learn 
wrote:
> On Friday, 17 June 2016 at 13:11:35 UTC, Kagamin wrote:
> > time_t is 64-bit on windows:
> > https://msdn.microsoft.com/en-us/library/1f4c8f33.aspx
>
> Windows does not have the concept of "time_t". The C runtime in
> use does.
>
> We use the DigitalMars C runtime for the 32-bit model, which is
> the default one. The Microsoft one is used for 64-bit and 32-bit
> COFF. I'm not sure how the MS C library deals with time_t,
> however the time() function (as exported from the library file /
> DLL) is the 32-bit version. If I were to guess, the C headers
> define a macro which redirects time() calls to the 64-bit version
> when appropriate. The D bindings don't copy that behavior.

The VS C runtime uses a macro to indicate whether time_t should be treated
as 32-bit or 64-bit on 32-bit systems. I thought that the default was
32-bit, but it looks like it's actually 64-bit, with the macro being
_USE_32BIT_TIME_T.

https://msdn.microsoft.com/en-us/library/1f4c8f33(v=vs.140).aspx

I guess that that the correct way to handle that would be to make it so that
druntime defines it as 64-bit by default and then has a version identifier
to change the behavior, but I don't know how that sort of thing has been
handled with the Win32 stuff in general. In the case of the stupid
unicode-related macros, IIRC, the solution is to just force you to use
either the A or W functions explicitly (preferably the W functions) rather
than making either of them the default or using a version identifier. That
approach really isn't an option here though, since the names don't changee
but rather the types.

- Jonathan M Davis

Re: Optimizations and performance

[Jack Stouffer via Digitalmars-d]

On Wednesday, 8 June 2016 at 22:19:47 UTC, Bauss wrote:
D definitely needs some optimizations, I mean look at its 
benchmarks compared to other languages: 
https://github.com/kostya/benchmarks


Welp, I tried making it faster and I apparently made it slower: 
https://github.com/kostya/benchmarks/pull/89


Oops.

[Issue 16181] New: Overloading doesn't consider default arguments with regards to ambiguity

[via Digitalmars-d-bugs]

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

  Issue ID: 16181
   Summary: Overloading doesn't consider default arguments with
regards to ambiguity
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b.hel...@gmail.com

The following code compiles:
---
int foo(int a, int b=2) {
return a + b;
}

int foo(int a) {
return a;
}

int main() {
return foo(12);
}
---

The interaction between default arguments and overloading doesn't appear to be
documented, which should be rectified regardless, but isn't this ambiguous? The
above code is rejected by C++ compilers as 'ambiguous', and I would certainly
expect an error to be generated in this particular case.

--

Re: Different struct sizeof between linux and windows

[Vladimir Panteleev via Digitalmars-d-learn]

On Friday, 17 June 2016 at 16:16:48 UTC, Kagamin wrote:
On Friday, 17 June 2016 at 13:21:04 UTC, Vladimir Panteleev 
wrote:
Windows does not have the concept of "time_t". The C runtime 
in use does.


The D bindings don't copy that behavior.


D defining C runtime type different from C runtime causes this 
error.


If I were to import the time() function from MSVCR*.dll, what 
size its return value would be?

Re: Different struct sizeof between linux and windows

[Kagamin via Digitalmars-d-learn]

On Friday, 17 June 2016 at 13:21:04 UTC, Vladimir Panteleev wrote:
Windows does not have the concept of "time_t". The C runtime in 
use does.


The D bindings don't copy that behavior.


D defining C runtime type different from C runtime causes this 
error.

Re: Areas of D usage

[Seb via Digitalmars-d]

Thanks again for your feedback.
In general, do you know about the "Improve this page" button on 
top right?
It's a very convenient & fast way to directly fix smaller 
nitpicks ;-)


 @crimaniak


As engineer I don't like gears in the 'Embedded applications' 
paragraph: they are not match.


Fair enough - do you have an idea for something that could be a 
better match?

At the moment we use FontAwesome: http://fontawesome.io/icons/

- @Ola Fosheim Grøstad

Try to view the page as a sceptical visitor and look for signs 
of a overly slick salesman.


Yes as said this page isn't perfect yet, and I/we are more than 
happy about reviewers ;-)


Too much text, try to tone down the evangelical subjectivity. 
It makes me suspicious and I instantly distrust all the 
information on the page.


CyberShadow just had a pass over it, but you are cordially 
invited to improve upon it!


Is there any substance to «projects that show the rising 
popularity of D among game developers»?


This is taken a bit out of context - the sentence is:
"Many pure-D open source projects show the rising popularity of D 
among game developers. Examples are the cross-platform 3D game 
engine Dash and the D game development toolkit gfm."


If you think this requires additional clarity, please submit a PR!

Why describe the language on a page with examples of usage at 
all?
Why not just have one entry for each product and describe D's 
role in it.


Because this page is intended for first-time users that are not 
very familiar with D.
The idea is to give a broad overview over each area and give 
arguments about benefits of using D in this field - something 
that isn't very obvious when you start to learn D. In fact it 
took me quite long to find all this information and put it to one 
common place.


For instance, was the entire Remedy game implemented in D? Give 
a neutral synopsis, then link to the external page.


Afaik a AAA game has million lines of code, so of course it 
wasn't done entirely in D. The sentence only says "use":


"Remedy Entertainment has successfully shipped the first AAA game 
to use D code for XBox One and Windows 10. For more details, see 
Ethan Watson's presentation."


Isn't that neutral? Otherwise please submit a PR to fix it ;-)

- @yawniek

i would remove (or push down) XOmB. its bad if the first link 
is a very outdated project (yes there is a branch that had some 
activity this year, but still).
powernex is much more interesting since its under active 
development.


thanks:

https://github.com/dlang/dlang.org/pull/1379

- @Dominikus Dittes Scherkl


One bug in GPU Programming:
"Thanks to the power the power of D’s type system..."


Fixed earlier by @CyberShadow.

- @Guillaume Piolat

Better not mention either! GFM is a pile of mostly useless 
uncontroversial code I wrote that is very far from what an 
engine would look like. It does barely anything.
DASH was ambitious enough to be mentionned but developement has 
stalled unfortunately.


(I didn't know this, so I guess a potential reader won't either.)

As you seem to know a lot more about this area, would you be so 
kind to help out and improve this section?


It is my opinion that the people that need social proof don't 
want to see such projects but only the high-profile ones like 
Remedy's game.


I think also smaller projects besides the big fishes are nice.
At least I like variety & active communities.

Re: Button: A fast, correct, and elegantly simple build system.

[Dicebot via Digitalmars-d-announce]

On 06/17/2016 06:20 PM, H. S. Teoh via Digitalmars-d-announce wrote:
>> If you happen to be unlucky enough to work on a project so large you
>> need to watch the file system, then use the tup backend I guess.
> [...]
> 
> Yes, I'm pretty sure that describes a lot of software projects out there
> today. The scale of software these days is growing exponentially, and
> there's no sign of it slowing down.  Or maybe that's just an artifact of
> the field I work in? :-P

Server-side domain is definitely getting smaller beause micro-service
hype keeps growing (and that is one of hypes I do actually support btw).

Re: pure D JPEG decoder, with progressive JPEG support, public domain

[ag0aep6g via Digitalmars-d-announce]

On 06/17/2016 04:08 PM, Kagamin wrote:

Uh oh, a license is revokable? What happens when boost license is revoked?


No, it's not, but you can publish stuff under multiple licenses at the 
same time.

Re: size_t vs uintptr_t

[Guillaume Boucher via Digitalmars-d]

I was referring to this diff in the pull linked request:

-private size_t _alignUp(size_t alignment)(size_t n)
+private uintptr_t _alignUp(uintptr_t alignment)(uintptr_t n)

size_t is the correct type.  There is no reason to change it.

Re: pure D JPEG decoder, with progressive JPEG support, public domain

[Andrei Alexandrescu via Digitalmars-d-announce]

On 06/17/2016 09:05 AM, ketmar wrote:

finally, the thing you all waited for years is here! pure D no-frills
JPEG decoder with progressive JPEG support! Public Domain! one file! no
Phobos or other external dependecies! it even has some DDoc! grab it[1]
now while it's hot!

[1] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/jpegd.d


https://www.reddit.com/r/programming/comments/4oj7ja/public_domain_jpeg_decoder_with_progressive/

Andrei

Re: Button: A fast, correct, and elegantly simple build system.

[H. S. Teoh via Digitalmars-d-announce]

On Fri, Jun 17, 2016 at 09:00:45AM +, Atila Neves via 
Digitalmars-d-announce wrote:
> On Friday, 17 June 2016 at 06:18:28 UTC, H. S. Teoh wrote:
> > On Fri, Jun 17, 2016 at 05:41:30AM +, Jason White via
> > Digitalmars-d-announce wrote: [...]
> > > Where Make gets slow is when checking for changes on a ton of
> > > files.  I haven't tested it, but I'm sure Button is faster than
> > > Make in this case because it checks for changed files using
> > > multiple threads.  Using the file system watcher can also bring
> > > this down to a near-zero time.
> > 
> > IMO using the file system watcher is the way to go. It's the only
> > way to beat the O(n) pause at the beginning of a build as the build
> > system scans for what has changed.
> 
> See, I used to think that, then I measured. tup uses fuse for this and
> that's exactly why it's fast. I was considering a similar approach
> with the reggae binary backend, and so I went and timed make, tup,
> ninja and itself on a synthetic project. Basically I wrote a program
> to write out source files to be compiled, with a runtime parameter
> indicating how many source files to write.
> 
> The most extensive tests I did was on a synthetic project of 30k
> source files. That's a lot bigger than the vast majority of developers
> are ever likely to work on. As a comparison, the 2.6.11 version of the
> Linux kernel had 17k files.

Today's software projects are much bigger than you seem to imply. For
example, my work project *includes* the entire Linux kernel as part of
its build process, and the size of the workspace is dominated by the
non-Linux components. So 30k source files isn't exactly something
totally far out.


> A no-op build on my laptop was about (from memory):
> 
> tup: <1s
> ninja, binary: 1.3s
> make: >20s
> 
> It turns out that just stat'ing everything is fast enough for pretty
> much everybody, so I just kept the simple algorithm. Bear in mind the
> Makefiles here were the simplest possible - doing anything that
> usually goes on in Makefileland would have made it far, far slower. I
> know: I converted a build system at work from make to hand-written
> ninja and it no-op builds went from nearly 2 minutes to 1s.

Problem: stat() isn't good enough when network file sharing is involved.
It breaks correctness by introducing heisenbugs caused by (sometimes
tiny) differences in local hardware clocks. It also may break if two
versions of the same file share the same timestamp (often thought
impossible, but quite possible with machine-generated files and a
filesystem that doesn't have subsecond resolution -- and it's rare
enough that when it does happen people are left scratching their heads
for many wasted hours).   To guarantee correctness you need to compute a
digest of file contents, not just timestamp.


> If you happen to be unlucky enough to work on a project so large you
> need to watch the file system, then use the tup backend I guess.
[...]

Yes, I'm pretty sure that describes a lot of software projects out there
today. The scale of software these days is growing exponentially, and
there's no sign of it slowing down.  Or maybe that's just an artifact of
the field I work in? :-P


T

-- 
Never step over a puddle, always step around it. Chances are that whatever made 
it is still dripping.

Re: std.experimental.checkedint is ready for comments!

[jmh530 via Digitalmars-d]

On Friday, 17 June 2016 at 14:52:27 UTC, tsbockman wrote:


What caught me off guard here isn't that Andrei had to approve 
it in some sense - it's that the judgment of everyone else who 
approved my design seemingly became irrelevant the moment that 
Andrei decided he could do better.


I hope you don't get too discouraged. Even if not in phobos, the 
project is still worth having.

Re: Cross platform android ldc compiler

[wobbles via Digitalmars-d]

On Friday, 17 June 2016 at 13:35:01 UTC, Andre Pany wrote:

On Friday, 17 June 2016 at 12:26:18 UTC, Gerald wrote:

On Friday, 17 June 2016 at 11:48:23 UTC, Andre Pany wrote:

[...]


For windows and mac VirtualBox is included in the docker 
installation routine. Most users won't even notice Virtual Box 
is working behind the scene of docker.


Last time I checked vagrant, I thought vagrant is a generator 
for virtual box images, but i will check again and include it 
into my research.


Kind regards
Andre


Docker will be changing in the near future - there'll be no 
VirtualBox from now on. At least, I don't think so going from the 
Beta, but maybe it's just even more hidden from the user now.

[Issue 16180] Unable to dispose an interface with std.experiment.allocator

[via Digitalmars-d-bugs]

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

--- Comment #3 from b2.t...@gmx.com ---
I don't know. It's maybe worth asking Hackerpilot if his fork is still needed,
the issues are addressed now, almost a year after the pull to phobos.
In emsi containers the submodule allocators is very outdated:

https://github.com/Hackerpilot/experimental_allocator/tree/cd8196a5b063b9019ea5529239da3181cc4fdc4f

--

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Friday, 17 June 2016 at 08:58:51 UTC, Jacob Carlborg wrote:

On 2016-06-17 00:30, Walter Bright wrote:


Andrei is in charge of the library and has my full support.


We have to make it very clear, somewhere, exactly what requires 
Andrei's approval and what doesn't. No, I cannot do that 
because I don't know the requirements.


What caught me off guard here isn't that Andrei had to approve it 
in some sense - it's that the judgment of everyone else who 
approved my design seemingly became irrelevant the moment that 
Andrei decided he could do better.


This implies that the only safe way to go about design a new 
module, is to collaborate closely with Andrei from the start.

Re: ARSD PNG memory usage

[Adam D. Ruppe via Digitalmars-d-learn]

On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:
ok, then it's somewhere in TrueColorImage or the loading of the 
png.


So, opengltexture actually does reallocate if the size isn't 
right for the texture... and your image was one of those sizes.


The texture pixel size needs to be a power of two, so 3000 gets 
rounded up to 4096, which means an internal allocation.


But it can be a temporary one! So ketmar tackled png.d's loaders' 
temporaries and I took care of gamehelper.d's...


And the test program went down about to 1/3 of its memory usage. 
Try grabbing the new ones from github now and see if it works for 
you too.



Well, It works on LDC x64! again ;) This seems like an issue 
with DMD x64? I was thinking maybe it has to do the layout of 
the struct or something, but not sure.


I have a fix for this too, though I don't understand why it 
works


I just .dup'd the string literal before passing it to Windows. I 
think dmd is putting the literal in a bad place for these 
functions (they do bit tests to see if it is a pointer or an 
atom, so maybe it is in an address where the wrong bits are set)


In any case, the .dup seems to fix it, so all should work on 32 
or 64 bit now. In my tests, now that the big temporary arrays are 
manually freed, the memory usage is actually slightly lower on 32 
bit, but it isn't bad on 64 bit either.



The CPU usage is consistently very low on my computer. I still 
don't know what could be causing it for you, but maybe it is the 
temporary garbage... let us know if the new patches make a 
difference there.


Anyways, We'll figure it all out at some point ;) I'm really 
liking your lib by the way. It's let me build a gui and get a 
lot done and just "work". Not sure if it will work on X11 with 
just a recompile, but I hope ;)



It often will! If you aren't using any of the native event 
handler functions or any of the impl.* members, most things just 
work (exception being the windows hotkey functions, but those are 
marked Windows anyway!). The basic opengl stuff is all done for 
both platforms. Advanced opengl isn't implemented on Windows yet 
though (I don't know it; my opengl knowledge stops in like 1998 
with opengl 1.1 so yeah, I depend on people's contributions 
for that and someone did Linux for me, but not Windows yet. I 
think.)

Re: I'd love to see DScript one day ...

[Chris via Digitalmars-d]

On Tuesday, 14 June 2016 at 13:02:37 UTC, Adam D. Ruppe wrote:

On Tuesday, 14 June 2016 at 09:30:02 UTC, Chris wrote:
So, what I ideally want to do isn't actually a scripting 
language, but rather a really easy to use IPC and D build 
library.


The end user thinks it is a script, it works the same way, they 
write a little program and load it up, but the application 
actually compiles it as D into an independent exe and spins it 
up as a new process, communication over a pipe and/or shared 
memory or something. The user script can then crash 
independently! And they can use the whole D language. The whole 
interface of interop can be automatically generated.


Of course, the problem with the build thing is the program you 
write might need to be distributed with a D compiler though 
I don't think that's a dealbreaker, D compilers aren't that big 
and could be downloaded on demand by your program. (Well, dmd 
isn't, ldc/gdc is 10x bigger.)


Could we build on this:

https://github.com/Hackerpilot/libdparse

?

Re: pure D JPEG decoder, with progressive JPEG support, public domain

[ketmar via Digitalmars-d-announce]

On Friday, 17 June 2016 at 14:33:41 UTC, ketmar wrote:
ah, just fork it and slap Boost license on top! i myself have 
no objections, and i doubt that the original author will object 
too.


p.s. i'm pretty sure that somebody *will* fork it soon to get it 
to code.dlang.org. i won't do that myself, but again, i have no 
objections.

Re: ARSD PNG memory usage

[kinke via Digitalmars-d-learn]

On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:

LDC x64 uses about 250MB and 13% cpu.

I couldn't check on x86 because of the error

phobos2-ldc.lib(gzlib.c.obj) : fatal error LNK1112: module 
machine type 'x64' conflicts with target machine type 'X86'


not sure what that means with gzlib.c.ojb. Must be another bug 
in ldc alpha ;/


It looks like you're trying to link 32-bit objects to a 64-bit 
Phobos.
The only pre-built LDC for Windows capable of linking both 32-bit 
and 64-bit code is the multilib CI release, see 
https://github.com/ldc-developers/ldc/releases/tag/LDC-Win64-master.

Re: pure D JPEG decoder, with progressive JPEG support, public domain

[ketmar via Digitalmars-d-announce]

On Friday, 17 June 2016 at 14:28:52 UTC, Rory McGuire wrote:
Thanks for that info. I don't think it would help if ketmar 
made it MIT / Boost licensed or any other, if the original 
authors relatives chose to dispute the license it the fact that 
the code is based on the PD code would make it hard to protect.


ah, just fork it and slap Boost license on top! i myself have no 
objections, and i doubt that the original author will object too.

Re: std.parallelism.taskPool daemon threads not terminating

[Russel Winder via Digitalmars-d-learn]

On Fri, 2016-06-17 at 00:14 +, Moritz Maxeiner via Digitalmars-d-
learn wrote:
> So, I am probably overlooking something obvious, but here goes:
> According to my understanding of daemon threads and what is 
> documented here[1],
> this following program should terminate once the druntime shuts 
> down, as the thread working on the task is supposed to be a 
> daemon thread:
> 
> > import std.parallelism;
> > 
> > void main()
> > {
> > taskPool.put(task({ while(true) {} }));
> > }
> 
> The actual behaviour (with dmd 2.071 and ldc2 1.0.0), however, is 
> that the program keeps running.

A priori, assuming I am not missing anything, this behaviour seems
entirely reasonable. The task is an infinite loop so it never
terminates. This means the threadpool does not stop working, which
means the program does not terminate.

> In contract, this behaves as expected:
> 
> > import core.thread;
> > 
> > void main()
> > {
> >    with (new Thread({ while(true) {} })) {
> >    isDaemon = true;
> >    start();
> >    }
> > }
> 
> Commenting out setting the isDaemon property will achieve the 
> same behaviour as the taskPool example. Is this the intended 
> behaviour of taskPool (because it does have isDaemon set)?

I suspect that daemon may not mean what you think it means. At least
not with respect to the threadpool.

> 
> [1] https://dlang.org/library/std/parallelism/task_pool.html
-- 

Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: pure D JPEG decoder, with progressive JPEG support, public domain

[Rory McGuire via Digitalmars-d-announce]

On Fri, Jun 17, 2016 at 3:35 PM, John Colvin via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 17 June 2016 at 13:05:47 UTC, ketmar wrote:
>
>> finally, the thing you all waited for years is here! pure D no-frills
>> JPEG decoder with progressive JPEG support! Public Domain! one file! no
>> Phobos or other external dependecies! it even has some DDoc! grab it[1] now
>> while it's hot!
>>
>> [1] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/jpegd.d
>>
>
> awesome.
>
> Without wanting to start a huge thing about this, see
> http://linuxmafia.com/faq/Licensing_and_Law/public-domain.html and
> http://www.rosenlaw.com/lj16.htm and please at least add an optional
> licencing under a traditional permissive open-source license (boost would
> be nice, who knows, maybe phobos should have jpeg support?).
>

Thanks for that info. I don't think it would help if ketmar made it MIT /
Boost licensed or any other, if the original authors relatives chose to
dispute the license it the fact that the code is based on the PD code would
make it hard to protect.

I think that source code under PD might get exception to the laws in those
articles because of the way PD is used globally and what its intent is, and
what our common understanding of it is. However that would probably go to
court to settle.

Re: pure D JPEG decoder, with progressive JPEG support, public domain

[ketmar via Digitalmars-d-announce]

On Friday, 17 June 2016 at 13:51:29 UTC, Andrei Alexandrescu 
wrote:
Nice, thanks for this work. I see it has 3213 lines. I take it 
the source is https://github.com/richgel999/jpeg-compressor. 
How many lines from there are reflected in the D code? -- Andrei


it's a complete port of jpegd.h+jpegd.cpp (so, no encoder). it is 
almost 1:1 to c++ code, including fancy templated row/col 
decoders and 4x4 matrix mini-class. mostly sed work, and after i 
made it to compile (and fixed silly bug in CLAMP that i 
introduced) it "just works". i replaced stream reader class with 
delegate (we have such a great delegates in D, so let's use 'em! 
;-), but otherwise the code is unmodified.


ah, i also put `.ptr` to array access to skip bounds checking -- 
i love to build my code with bounds checking on, and i don't feel 
that i need it in this decoder -- it should be fairly well-tested.


so you may assume that all of the lines there are came from c++ 
(sans some curly brackets).


of course, one can do much better work by writing "idiomatic" D 
code, i guess, but that would be much greater work -- not a 
"port", but "rewrite".

Re: Parsing D Maybe Not Such a Good Idea <_<;

[Russel Winder via Digitalmars-d]

On Fri, 2016-06-17 at 08:07 +, Basile B. via Digitalmars-d wrote:
> 
[…]
> Yes, libdparse is the reference and when someone has to parse D 
> code he really should use it. Among all the D libraries it's the 
> one I know the more. I use it to build the CE's symbol list (it's 
> an AST visitor) and to detect the "TODO comments" ;)
> 
[…]

One can only wonder why this is not the reference parser, the one that
DMD and all other tools can then use.

-- 

Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: Telegram Supergroup as an alternative to IRC

[Dechcaudron via Digitalmars-d]

On Friday, 17 June 2016 at 12:53:49 UTC, sigod wrote:
I think it's wrong to suggest to replace IRC with Telegram. 
Instead, let's use Telegram as other means of communication.


Sure, that's what I meant.

Also, does anyone knows who has control over @dlang 
(https://telegram.me/dlang) channel?


No idea. It's dead, sadly. We can probably contact the admin if 
we push hard enough.

Re: pure D JPEG decoder, with progressive JPEG support, public domain

[ketmar via Digitalmars-d-announce]

On Friday, 17 June 2016 at 13:35:58 UTC, John Colvin wrote:
Without wanting to start a huge thing about this, see 
http://linuxmafia.com/faq/Licensing_and_Law/public-domain.html 
and http://www.rosenlaw.com/lj16.htm and please at least add an 
optional licencing under a traditional permissive open-source 
license (boost would be nice, who knows, maybe phobos should 
have jpeg support?).


ah, i know about PD caveats. but the original source was PD, so i 
don't feel like adding any other license on top of it will be 
good. not that it is legally impossible, i just want to keep it 
as the original author intended. after all, anybody can just fork 
it and add any license he wants. it is unlikely that the thing 
will get extensive upgrades anyway. ;-)

Re: pure D JPEG decoder, with progressive JPEG support, public domain

[Kagamin via Digitalmars-d-announce]

On Friday, 17 June 2016 at 13:35:58 UTC, John Colvin wrote:
Without wanting to start a huge thing about this, see 
http://linuxmafia.com/faq/Licensing_and_Law/public-domain.html 
and http://www.rosenlaw.com/lj16.htm and please at least add an 
optional licencing under a traditional permissive open-source 
license (boost would be nice, who knows, maybe phobos should 
have jpeg support?).


Uh oh, a license is revokable? What happens when boost license is 
revoked?

[Issue 16180] Unable to dispose an interface with std.experiment.allocator

[via Digitalmars-d-bugs]

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

--- Comment #2 from Maik Klein  ---
Okay I found the bug. It was using emsi_container as a dependency, even though
I did not use it. 

It seems to have a dependency on std.experimental.allocator version 2.70, which
then somehow overshadowed the current version of std.experimental.allocator.

And the bug that I am reporting still existed in 2.70 but seems to be fixed in
2.71.

So I guess I maybe should report this as an dub issue?

--

Re: pure D JPEG decoder, with progressive JPEG support, public domain

[John Colvin via Digitalmars-d-announce]

On Friday, 17 June 2016 at 13:05:47 UTC, ketmar wrote:
finally, the thing you all waited for years is here! pure D 
no-frills JPEG decoder with progressive JPEG support! Public 
Domain! one file! no Phobos or other external dependecies! it 
even has some DDoc! grab it[1] now while it's hot!


[1] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/jpegd.d


awesome.

Without wanting to start a huge thing about this, see 
http://linuxmafia.com/faq/Licensing_and_Law/public-domain.html 
and http://www.rosenlaw.com/lj16.htm and please at least add an 
optional licencing under a traditional permissive open-source 
license (boost would be nice, who knows, maybe phobos should have 
jpeg support?).

[Issue 16180] Unable to dispose an interface with std.experiment.allocator

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 CC||b2.t...@gmx.com

--- Comment #1 from b2.t...@gmx.com ---
(In reply to Maik Klein from comment #0)
> I opened a stack overflow question which contains all the needed details 
> 
> http://stackoverflow.com/questions/37868594/disposing-a-class-with-an-
> interface?lq=1

There a dispose overload that works with interface. It's available because you
can retrieve the object that implements the interface using "cast(Object) itf".

So to me the report is invalid:

uint a;
interface Bar{}
class Foo: Bar
{
~this(){a = 1;}
}

void main()
{
import std.experimental.allocator.mallocator;
import std.experimental.allocator;
auto f = Mallocator.instance.make!Foo();
Bar b = f;
Mallocator.instance.dispose(b);
assert(a == 1);
}
I think that on S.O you ignore what is done here

https://github.com/dlang/phobos/blob/master/std/experimental/allocator/package.d#L1135

This is basically what allows to destroy an object from its interface.

--

vibe.d - asynchronously wait() for process to exit

[Vladimir Panteleev via Digitalmars-d-learn]

std.process.wait() will wait for a child process to exit and 
return its exit code. How can this be done in Vibe.d, without 
blocking other fibers and without creating a new thread?


In my library I did it like this: 
https://github.com/CyberShadow/ae/blob/master/sys/process.d
(register a SIGCHLD signal handler, which pings the main thread 
via a socket).


Geod24 on IRC suggested signalfd + createFileDescriptorEvent. I 
think this would work, but isn't it possible to wrap the fd 
returned by signalfd into a Vibe.d stream and read it directly? 
I'm just not sure how.


I noticed libasync also provides notification for POSIX signals, 
but I've no idea where to start with using that in a Vibe.d 
program.

Re: pure D JPEG decoder, with progressive JPEG support, public domain

[Andrei Alexandrescu via Digitalmars-d-announce]

On 06/17/2016 09:05 AM, ketmar wrote:

finally, the thing you all waited for years is here! pure D no-frills
JPEG decoder with progressive JPEG support! Public Domain! one file! no
Phobos or other external dependecies! it even has some DDoc! grab it[1]
now while it's hot!

[1] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/jpegd.d


Nice, thanks for this work. I see it has 3213 lines. I take it the 
source is https://github.com/richgel999/jpeg-compressor. How many lines 
from there are reflected in the D code? -- Andrei

Re: Cross platform android ldc compiler

[Andre Pany via Digitalmars-d]

On Friday, 17 June 2016 at 12:26:18 UTC, Gerald wrote:

On Friday, 17 June 2016 at 11:48:23 UTC, Andre Pany wrote:

Hi,

I want to share an idea with you. I do not know how far I will
come myself with this idea due to my lack of linux and ldc 
knowledge.


There is a great virtualization tool called docker. With this
tool it is possible to create images of software tools. This 
images

will run out of the box on every system (mac/linux/windows).

I think of a docker image containing ldc and all necessary 
dependencies

for compiling an android/ios application. The D source code you
can store in a shared directory between your host system and 
the
docker virtual system. The docker image could in addition 
provide

a web interface to start the compilation/linking process.

In the end, if you have the docker image, you will have s.th. 
like a

"D android compiler as a service" which works on every major
operation system. Just install docker and select the image 
from the free

docker marketplace.


Docker doesn't run natively on Windows and OSX, it requires a 
VM such as VirtualBox, since it depends on linux kernel 
features like cgroups. IMHO, a better solution for a 
development environment then docker would be Vagrant 
(https://www.vagrantup.com) as this is the sort of use case it 
is designed around and it is based on VMs from the get-go 
(though it can work with docker as a provider as well),


For windows and mac VirtualBox is included in the docker 
installation routine. Most users won't even notice Virtual Box is 
working behind the scene of docker.


Last time I checked vagrant, I thought vagrant is a generator for 
virtual box images, but i will check again and include it into my 
research.


Kind regards
Andre

Re: Different struct sizeof between linux and windows

[Vladimir Panteleev via Digitalmars-d-learn]

On Friday, 17 June 2016 at 13:11:35 UTC, Kagamin wrote:
time_t is 64-bit on windows: 
https://msdn.microsoft.com/en-us/library/1f4c8f33.aspx


Windows does not have the concept of "time_t". The C runtime in 
use does.


We use the DigitalMars C runtime for the 32-bit model, which is 
the default one. The Microsoft one is used for 64-bit and 32-bit 
COFF. I'm not sure how the MS C library deals with time_t, 
however the time() function (as exported from the library file / 
DLL) is the 32-bit version. If I were to guess, the C headers 
define a macro which redirects time() calls to the 64-bit version 
when appropriate. The D bindings don't copy that behavior.

Re: Different struct sizeof between linux and windows

[Kagamin via Digitalmars-d-learn]

time_t is 64-bit on windows: 
https://msdn.microsoft.com/en-us/library/1f4c8f33.aspx

pure D JPEG decoder, with progressive JPEG support, public domain

[ketmar via Digitalmars-d-announce]

finally, the thing you all waited for years is here! pure D 
no-frills JPEG decoder with progressive JPEG support! Public 
Domain! one file! no Phobos or other external dependecies! it 
even has some DDoc! grab it[1] now while it's hot!


[1] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/jpegd.d

Re: Telegram Supergroup as an alternative to IRC

[sigod via Digitalmars-d]

On Thursday, 16 June 2016 at 14:33:07 UTC, Dechcaudron wrote:

Hey there community,

I've been using D for the last couple of months already. I 
usually have to drop by the IRC to ask some fast questions and 
so on, but IRC and its clients' limitations make it kind of a 
pain to communicate through it.


If anybody uses Telegram around here, its Desktop client would 
prove an amazing alternative and its supergroups can host up to 
5000 people. I understand there are some major differences, but 
all in all I understand the advantages outweight the cons. 
Mentions, for example, are way easier to use, as well as 
replies, link and media sharing...


So, anybody willing to join me? Even if it's 3 people in the 
beggining, it'll be alright. Just send a message to 
@Dechcaudron from Telegram and I'll answer so we can assemble 
the group :D


I think it's wrong to suggest to replace IRC with Telegram. 
Instead, let's use Telegram as other means of communication.


Also, does anyone knows who has control over @dlang 
(https://telegram.me/dlang) channel?

Re: Default initialization of structs?

[David Nadlinger via Digitalmars-d-learn]

On Friday, 17 June 2016 at 11:10:12 UTC, Gary Willoughby wrote:
Thanks, I forgot to mention I'm also doing lots of other stuff 
in the constructor to private fields too.


struct Foo(T)
{
private int _bar;
private void* _baz;

this(int bar = 8)
{
this._bar = bar;
this._baz = malloc(this._bar);
}
}

So I have to at least run a constructor.


Structs cannot have a default constructor; .init is required to 
be a valid state (unless you @disable default construction). This 
is a deliberate language restriction, although you can argue 
about its value.


What you can do as a workaround is to provide a public static 
factory method while disabling default construction.


 — David

Re: Default initialization of structs?

[Johan Engelen via Digitalmars-d-learn]

On Friday, 17 June 2016 at 10:50:55 UTC, Gary Willoughby wrote:
I have a struct where I need to perform default initialization 
of some members but the compiler doesn't allow to define a 
default constructor which allow optional arguments.


This is a fairly recent change (2.068->2.069 or 2.070), so if you 
browse the release notes you may be able to figure out exactly 
why this is not allowed.


-Johan

Re: Cross platform android ldc compiler

[Gerald via Digitalmars-d]

On Friday, 17 June 2016 at 11:48:23 UTC, Andre Pany wrote:

Hi,

I want to share an idea with you. I do not know how far I will
come myself with this idea due to my lack of linux and ldc 
knowledge.


There is a great virtualization tool called docker. With this
tool it is possible to create images of software tools. This 
images

will run out of the box on every system (mac/linux/windows).

I think of a docker image containing ldc and all necessary 
dependencies

for compiling an android/ios application. The D source code you
can store in a shared directory between your host system and the
docker virtual system. The docker image could in addition 
provide

a web interface to start the compilation/linking process.

In the end, if you have the docker image, you will have s.th. 
like a

"D android compiler as a service" which works on every major
operation system. Just install docker and select the image from 
the free

docker marketplace.


Docker doesn't run natively on Windows and OSX, it requires a VM 
such as VirtualBox, since it depends on linux kernel features 
like cgroups. IMHO, a better solution for a development 
environment then docker would be Vagrant 
(https://www.vagrantup.com) as this is the sort of use case it is 
designed around and it is based on VMs from the get-go (though it 
can work with docker as a provider as well),

Re: OpenGL Setup?

[Leandro Motta Barros via Digitalmars-d-learn]

I have been using Textadept ( http://foicica.com/textadept/ ) with
Textadept-d ( https://github.com/Hackerpilot/textadept-d ). I use mostly on
Linux for development, but I've recently spent two or three days on Windows
and things worked well enough for me.

(Coming for someone who has used Emacs for everything int he last 15+
years, this must mean something :-) )

Hope this helps,

LMB


On Fri, Jun 17, 2016 at 8:51 AM, OpenJelly via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:

> On Thursday, 16 June 2016 at 19:52:58 UTC, OpenJelly wrote:
>
>>
>> Trying to get VS Code to work with code-d... can't get dcd to work with
> it. It says it's failed to kill the dcd server when I try to reload it. It
> wasn't appearing in task manager (but dcd-client was) and manually starting
> it up didn't make it work in vs code. Trying to restart it in cmd freezes
> that window and the task refuses to kill. I'm trying to fix it now but I
> don't even know why it's not working...
>
> The arsd stuff just gives me a thick list of internal errors when I try to
> import it through dub. But I might almost have GLFW working... I can't
> really tell yet, but I did finally find the right dll to link to (files in
> the Windows x64 binaries kept giving me an error, but the one x64 dll in
> the x86 download ended up working).
>
> Not keen to try vim if it doesn't have the features I need to compensate
> for being a shitty programmer.
>

[Issue 5305] Cannot take pointer to intrinsic function

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--

[Issue 5305] Cannot take pointer to intrinsic function

[via Digitalmars-d-bugs]

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

--- Comment #7 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/fad9e24cff5aff88c5635b010076bf6d39e659e7
fix Issue 5305 - intrinsic functions have @safe stripped of them in release
mode

https://github.com/dlang/dmd/commit/5f8f6f569eb9d5076c8e2ad68237e18c86052eb0
Merge pull request #5845 from WalterBright/test5305

fix Issue 5305 - intrinsic functions have @safe stripped of them in r…

--

[Issue 16180] New: Unable to dispose an interface with std.experiment.allocator

[via Digitalmars-d-bugs]

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

  Issue ID: 16180
   Summary: Unable to dispose an interface with
std.experiment.allocator
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: maikkl...@googlemail.com

I opened a stack overflow question which contains all the needed details 

http://stackoverflow.com/questions/37868594/disposing-a-class-with-an-interface?lq=1

--

Re: OpenGL Setup?

[OpenJelly via Digitalmars-d-learn]

On Thursday, 16 June 2016 at 19:52:58 UTC, OpenJelly wrote:


Trying to get VS Code to work with code-d... can't get dcd to 
work with it. It says it's failed to kill the dcd server when I 
try to reload it. It wasn't appearing in task manager (but 
dcd-client was) and manually starting it up didn't make it work 
in vs code. Trying to restart it in cmd freezes that window and 
the task refuses to kill. I'm trying to fix it now but I don't 
even know why it's not working...


The arsd stuff just gives me a thick list of internal errors when 
I try to import it through dub. But I might almost have GLFW 
working... I can't really tell yet, but I did finally find the 
right dll to link to (files in the Windows x64 binaries kept 
giving me an error, but the one x64 dll in the x86 download ended 
up working).


Not keen to try vim if it doesn't have the features I need to 
compensate for being a shitty programmer.

Cross platform android ldc compiler

[Andre Pany via Digitalmars-d]

Hi,

I want to share an idea with you. I do not know how far I will
come myself with this idea due to my lack of linux and ldc 
knowledge.


There is a great virtualization tool called docker. With this
tool it is possible to create images of software tools. This 
images

will run out of the box on every system (mac/linux/windows).

I think of a docker image containing ldc and all necessary 
dependencies

for compiling an android/ios application. The D source code you
can store in a shared directory between your host system and the
docker virtual system. The docker image could in addition provide
a web interface to start the compilation/linking process.

In the end, if you have the docker image, you will have s.th. 
like a

"D android compiler as a service" which works on every major
operation system. Just install docker and select the image from 
the free

docker marketplace.

Kind regards
André

Re: Beta release DUB 1.0.0-beta.1

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

Am 17.06.2016 um 13:06 schrieb mark_mcs:

I'm not sure if this is a defect or a conscious decision so I thought
I'd ask the question first. Is there a reason why Dub on Windows uses
the APPDATA environment variable, rather than LOCALAPPDATA? The APPDATA
variable points to the roaming profile directory which means that my
entire Dub cache is uploaded when I log out, then downloaded again when
I log back in. Should I raise a github issue for this? Seems like an
easy fix for a 1.0.0 release.


It currently stores both, the configuration and cached packages in the 
same folder, while it should put the configuration in APPDATA and the 
cached packages in LOCALAPPDATA (so it's indeed a defect). It's an easy 
fix, but too late in the release process now. It could go into 1.0.1, 
though.

Re: Default initialization of structs?

[Namespace via Digitalmars-d-learn]

The Factory-Pattern would be a good idea.

Re: Default initialization of structs?

[Gary Willoughby via Digitalmars-d-learn]

On Friday, 17 June 2016 at 10:53:40 UTC, Lodovico Giaretta wrote:

struct Foo(T)
{
private int _bar = 1;

this(int bar)
{
this._bar = bar;
}
}

auto foo = Foo!(string)();

This should do the trick.


Thanks, I forgot to mention I'm also doing lots of other stuff in 
the constructor to private fields too.


struct Foo(T)
{
private int _bar;
private void* _baz;

this(int bar = 8)
{
this._bar = bar;
this._baz = malloc(this._bar);
}
}

So I have to at least run a constructor.

Re: Beta release DUB 1.0.0-beta.1

[mark_mcs via Digitalmars-d-announce]

On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote:
DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is 
support for single-file packages, which can be used to write 
shebang-style scripts on Posix systems:


#!/usr/bin/env dub
/++ dub.sdl:
name "colortest"
dependency "color" version="~>0.0.3"
+/

void main()
{
import std.stdio : writefln;
import std.experimental.color.conv;
import std.experimental.color.hsx;
import std.experimental.color.rgb;

auto yellow = RGB!("rgb", float)(1.0, 1.0, 0.0);
writefln("Yellow in HSV: %s", 
yellow.convertColor!(HSV!()));

}

With "chmod +x" it can then simply be run as ./colortest.d.

Apart from that, the release contains some bug fixes, most 
notably it doesn't query the registry for each build any more.


Full change log:
https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

Download (Latest Preview):
http://code.dlang.org/download


I'm not sure if this is a defect or a conscious decision so I 
thought I'd ask the question first. Is there a reason why Dub on 
Windows uses the APPDATA environment variable, rather than 
LOCALAPPDATA? The APPDATA variable points to the roaming profile 
directory which means that my entire Dub cache is uploaded when I 
log out, then downloaded again when I log back in. Should I raise 
a github issue for this? Seems like an easy fix for a 1.0.0 
release.

Re: Default initialization of structs?

[Lodovico Giaretta via Digitalmars-d-learn]

On Friday, 17 June 2016 at 10:50:55 UTC, Gary Willoughby wrote:
I have a struct where I need to perform default initialization 
of some members but the compiler doesn't allow to define a 
default constructor which allow optional arguments.


struct Foo(T)
{
private int _bar;

this(int bar = 1)
{
this._bar = bar;
}
}

auto foo = Foo!(string) // error

Are there any patterns or idioms I could use to get the desired 
result? Or is it just the case if I use a constructor I have to 
pass values to it?


struct Foo(T)
{
private int _bar = 1;

this(int bar)
{
this._bar = bar;
}
}

auto foo = Foo!(string)();

This should do the trick.

Default initialization of structs?

[Gary Willoughby via Digitalmars-d-learn]

I have a struct where I need to perform default initialization of 
some members but the compiler doesn't allow to define a default 
constructor which allow optional arguments.


struct Foo(T)
{
private int _bar;

this(int bar = 1)
{
this._bar = bar;
}
}

auto foo = Foo!(string) // error

Are there any patterns or idioms I could use to get the desired 
result? Or is it just the case if I use a constructor I have to 
pass values to it?

[Issue 5305] Cannot take pointer to intrinsic function

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |---

--- Comment #6 from Walter Bright  ---
The test case I added is to verify that taking the address of sqrt from
std.math works.

--

Re: Areas of D usage

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 15 June 2016 at 20:01:09 UTC, Seb wrote:

On Thursday, 2 June 2016 at 23:57:55 UTC, jmh530 wrote:

On Thursday, 2 June 2016 at 21:47:13 UTC, qznc wrote:

On Thursday, 2 June 2016 at 13:59:13 UTC, Seb wrote:
If I left out an area or you miss an application/usage - 
please let me know!


The Javascript JIT Compiler Higgs: 
https://github.com/higgsjs/Higgs


Vibe.d needs some examples. Looks like their website does not 
have any.


Wasn't too many clicks away to get to the tutorial on building 
a chat service.


Thanks a lot for all your help!
The initial version is online now & please feel invited to 
improve upon this document:


http://dlang.org/areas-of-d-usage.html


"For example have a look at the cross-platform 3D game engine 
Dash or at the D game development toolkit gfm. "


Better not mention either! GFM is a pile of mostly useless 
uncontroversial code I wrote that is very far from what an engine 
would look like. It does barely anything.


DASH was ambitious enough to be mentionned but developement has 
stalled unfortunately.


Do mention Derelict instead!

It is my opinion that the people that need social proof don't 
want to see such projects but only the high-profile ones like 
Remedy's game.

[Issue 4541] Intrinsic functions do not have pointers

[via Digitalmars-d-bugs]

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

Mathias Lang  changed:

   What|Removed |Added

 CC||b.hel...@gmail.com

--- Comment #7 from Mathias Lang  ---
*** Issue 5305 has been marked as a duplicate of this issue. ***

--

[Issue 5305] Cannot take pointer to intrinsic function

[via Digitalmars-d-bugs]

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

Mathias Lang  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mathias.l...@sociomantic.co
   ||m
 Resolution|--- |DUPLICATE
Summary|intrinsic functions have|Cannot take pointer to
   |@safe stripped of them in   |intrinsic function
   |release mode.   |

--- Comment #5 from Mathias Lang  ---
As mentioned by #c2, the issue is taking a pointer to an intrinsic function.
Closing as duplicate and renaming for clarity.

*** This issue has been marked as a duplicate of issue 4541 ***

--