Re: My statements related to terminating my SAoC relationship

2018-10-16 Thread Nemanja Boric via Digitalmars-d

On Monday, 15 October 2018 at 21:26:52 UTC, solidstate1991 wrote:


I try to resume my work on improving mago, but on a much 
smaller scale and lower priority since I have to spend time 
finding a job, which is a very hard thing in this fascist 
country called Hungary, while also not supporting said fascist 
regime. While the state propaganda says there's a big shortage 
on workforce (to the point that supposedly humanitarians are 
being reeducated for Java developers), I also see a lot of 
people being rejected with bogus claims which tells me that 
there's something fishy, and hearing some controversies of 
political opponents' families suddenly losing their jobs says 
me that they're persecuting their political opponents at any 
means possible.




Hello,

I just wanted to say that you could consider finding the job 
abroad. Given

that you're an EU citizen, moving to Germany
or Austria (or Czech Republic, or Netherlands, or anywhere inside 
EU) is possible
without any bureaucratic issues, and you should use that 
opportunity.


It may sound scary, but it's actually much easier than you think, 
and maybe
that's just what you need! You may also be able to negotiate 
moving bonus which should

cover the rent & food for a month - until the first paycheck.


Re: LDC2 1.9.0 beta 1 bug

2018-10-04 Thread Nemanja Boric via Digitalmars-d
On Thursday, 4 October 2018 at 12:51:27 UTC, Shachar Shemesh 
wrote:
I got this as a report from a user, not directly running this, 
which is why I'm not opening a bug report.


[...]


I'm pretty sure I saw an issue in bugzilla few weeks ago... Found 
it:


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


Re: Truly @nogc Exceptions?

2018-09-21 Thread Nemanja Boric via Digitalmars-d

On Friday, 21 September 2018 at 10:06:06 UTC, Nemanja Boric wrote:
On Friday, 21 September 2018 at 09:10:06 UTC, Jonathan M Davis 
wrote:

[...]


The @__future is fully (to a reasonable degree) implemented - 
and the `Throwable.message` was marked with this attribute to 
prevent breaking the user code when introducing this field, and 
it probably can just be removed from there at this point (since 
many releases have been released).


[...]


Interesting quote from Martin on that PR:

With regards to Throwable.message we agreed on making it one of 
the first users of an upcoming reference counted string. 
Details on the design of the reference counted string first to 
be discussed on dlang-study.


Re: Truly @nogc Exceptions?

2018-09-21 Thread Nemanja Boric via Digitalmars-d
On Friday, 21 September 2018 at 09:10:06 UTC, Jonathan M Davis 
wrote:

[...]
I think that the message member was added by Dicebot as an 
attempt to fix this issue, because Sociomantic needed it, but I 
don't know exactly what's going on with that or @__future.


- Jonathan M Davis


The @__future is fully (to a reasonable degree) implemented - and 
the `Throwable.message` was marked with this attribute to prevent 
breaking the user code when introducing this field, and it 
probably can just be removed from there at this point (since many 
releases have been released).


This is the PR when Throwable.message was first introduced: 
https://github.com/dlang/druntime/pull/1445 We had the same 
discussion there, and you can see sociomantic's use case in 
Mihail's comments there. The entire PR have a very good 
discussion and we (not Sociomantic) still need sink-based method 
IIUC.


Re: Of possible interest: fast UTF8 validation

2018-05-18 Thread Nemanja Boric via Digitalmars-d

On Friday, 18 May 2018 at 08:44:41 UTC, Joakim wrote:


I was surprised to see that adding a emoji to a text message I 
sent last year cut my message character quota in half.  I 
googled why this was and it turns out that when you add an 
emoji, the text messaging client actually changes your message 
encoding from UTF-8 to UTF-16! I don't know if this is a 
limitation of the default Android messaging client, my telco 
carrier, or SMS, but I strongly suspect this is widespread.




Welcome to my world (and probably world of most Europeans) where 
I don't type ć, č, ž and other non-ascii letters since early 
2000s, even though SMS are today mostly flat rate and people chat 
via WhatsApp anyway.


Re: Issues with Socket.accept() and SIGUSR1

2017-12-08 Thread Nemanja Boric via Digitalmars-d

On Friday, 8 December 2017 at 23:11:47 UTC, Adam D. Ruppe wrote:

On Friday, 8 December 2017 at 22:27:41 UTC, LeqxLeqx wrote:
Normally the accept will throw a timeout and then the loop 
will continue to listen, but sometimes (and I can't find a 
decent pattern) the Socket.accept() method will raise a 
SIGUSR1 rather than throwing an exception of any kind.


That probably means the *other* thread started a garbage 
collection cycle. The D GC uses that signal to pause threads 
while it scans memory, so they don't change out from under it 
mid-scan.


All you need to do is try the accept again if that happens. It 
isn't really an exception, it is just an EINTR - signal call 
interrupted - and you are supposed to just try again when that 
happens (unless the interruption meant the program is now 
instructed to terminate e.g. SIGINT)


Sorry, I've completely missed your first paragraph! It's after 
midnight here, good night!


Re: Issues with Socket.accept() and SIGUSR1

2017-12-08 Thread Nemanja Boric via Digitalmars-d

On Friday, 8 December 2017 at 22:27:41 UTC, LeqxLeqx wrote:

Hello,

I've been trying to create a small server-client program, and 
I've run into a rather strange problem. There's a thread 
separate from the main which accepts incoming connections. The 
established connections are then passed over to the main thread 
for the actual logic of the interaction, and the accept thread 
loops back to listen for further connections.


[...]


Looking the trace, your thread 2 had not raised, but received a 
signal. I have a feeling GC collection starts from another 
thread, and GC sends SIGUSR1 to all (registered to the runtime) 
threads to pause them, while the collection is running. As Adam 
said, repeat the call (check how Phobos sockets are handling this 
and what you should do), and you probably want to instruct the 
debugger to ignore SIGUSR1/2.


Re: Druntime and non-D threads

2017-12-08 Thread Nemanja Boric via Digitalmars-d

On Friday, 8 December 2017 at 09:33:03 UTC, Ali Çehreli wrote:
5) We depend on SIGUSR1 (and SIGUSR2, which may not be 
necessary but it's a different topic) to suspend non-D threads. 
Does that work with all threads? What if the calling framework 
has other uses for those signals? Would we be interfering with 
them?




As the signal handlers are setup per-process, having the non-D 
threads setup `SIGUSR1/2` will probably screw the entire GC, not 
just for these threads. I feel you must ensure that the non-D 
threads don't try to setup these handlers after the `rt_init` 
(which in turns calls `thread_init`) is called, otherwise you're 
screwed. This is also valid in inverse - you shouldn't use 
SIGUSR1/2 in non-D threads, since after calling `rt_init` the 
signal handlers will be replaced with druntime's ones.


Re: Adding Markdown to Ddoc

2017-12-06 Thread Nemanja Boric via Digitalmars-d
On Wednesday, 6 December 2017 at 04:11:33 UTC, Walter Bright 
wrote:

https://help.github.com/articles/basic-writing-and-formatting-syntax/

Anyone interested in picking up the flag?

(I know this has come up before, and I've been opposed to it, 
but I've changed my mind.)


These are great news. We are using harbored-mod 
(https://github.com/dlang-community/harbored-mod) which does this 
for quite some time, but it feels like a second-class citizen 
compared to the ddoc.


Re: What does the following program do?

2017-12-05 Thread Nemanja Boric via Digitalmars-d
On Tuesday, 5 December 2017 at 14:11:02 UTC, Shachar Shemesh 
wrote:

import std.algorithm: move;
import std.stdio;
import std.string;

class A {
int val;

override string toString() const {
return "A(%s)".format(val);
}
}

struct B {
int val;
}

void main() {
B b = B(12);
B* bp = &b;
B* bp2;

writefln("bp=%s bp2=%s", bp, bp2);
move( bp, bp2 );
writefln("bp=%s bp2=%s", bp, bp2);

A a1 = new A();
a1.val = 42;
A a2;

writefln("a1=%s (%s) a2=%s (%s)", a1, cast(void*)a1, a2, 
cast(void*)a2);

move( a1, a2 );
writefln("a1=%s (%s) a2=%s (%s)", a1, cast(void*)a1, a2, 
cast(void*)a2);


B b2;
writefln("b=%s b2=%s", b, b2);
move( b, b2 );
writefln("b=%s b2=%s", b, b2);
}

Answer:
bp=7FFFAB559970 bp2=null
bp=7FFFAB559970 bp2=7FFFAB559970
a1=A(42) (7FD1B79E9000) a2=null (null)
a1=A(42) (7FD1B79E9000) a2=A(42) (7FD1B79E9000)
b=B(12) b2=B(0)
b=B(12) b2=B(12)

"move" was supposed to initialize "source" to init. This does 
not appear to be the case. Is that a bug? Where?


```
b=B(12) b2=B(0)
b=B(12) b2=B(12)
```

bit will change if you declare destructor in your struct. As per 
the documentation:


If T is a struct with a destructor or postblit defined, source 
is reset to its .init value after it is moved into target, 
otherwise it is left unchanged.


as for others I understand you have the same problem here - per 
documentation, these are not  structs with destructors, so moving 
the pointers (references) doesn't clear the source one.


Re: Project Elvis

2017-10-29 Thread Nemanja Boric via Digitalmars-d
On Sunday, 29 October 2017 at 18:02:25 UTC, Jonathan M Davis 
wrote:
On Sunday, October 29, 2017 17:35:25 Nemanja Boric via 
Digitalmars-d wrote:

On Sunday, 29 October 2017 at 17:19:44 UTC, Jonathan M Davis

wrote:
> On Sunday, October 29, 2017 16:44:39 Ola Fosheim Grøstad via
>
> Digitalmars-d wrote:
>> On Sunday, 29 October 2017 at 16:29:57 UTC, Jonathan M Davis
>>
>> wrote:
>> > valid using ?:, I would think that you'd want to be doing 
>> > the same check with stuff like if statements anyway. So, 
>> > it sounds to me like overloading opCast!bool would work 
>> > just fine.

>>
>> If you try to do:
>>
>> some_float ?: 0.0
>>
>> then it will do nothing as cast(bool)std.math.NaN(0) => true
>
> NaN is supposed to always be false.

OT, but I had to :-)

```
void main()
{
  import std.stdio;

  float x;
  x? writeln("Oh no, a NaN!") : writeln("All good.");
}
```

Same happens for assert(float.nan) - it doesn't fail.


Sounds like a bug to me. NaN is supposed to be false whenever 
it's used in a comparison. If it it's true when cast directly 
to bool, then that's inconsistent.


- Jonathan M Davis


We've already reported this as a bug (I actually got quite burned 
on it, trusting assert(float_value) to prevent NaN's escaping the 
function), but there were different opinions on this, so it never 
got anywhere: https://issues.dlang.org/show_bug.cgi?id=13489


Re: Project Elvis

2017-10-29 Thread Nemanja Boric via Digitalmars-d
On Sunday, 29 October 2017 at 17:19:44 UTC, Jonathan M Davis 
wrote:
On Sunday, October 29, 2017 16:44:39 Ola Fosheim Grøstad via 
Digitalmars-d wrote:

On Sunday, 29 October 2017 at 16:29:57 UTC, Jonathan M Davis

wrote:
> valid using ?:, I would think that you'd want to be doing 
> the same check with stuff like if statements anyway. So, it 
> sounds to me like overloading opCast!bool would work just 
> fine.


If you try to do:

some_float ?: 0.0

then it will do nothing as cast(bool)std.math.NaN(0) => true


NaN is supposed to always be false.


OT, but I had to :-)

```
void main()
{
import std.stdio;

float x;
x? writeln("Oh no, a NaN!") : writeln("All good.");
}
```

Same happens for assert(float.nan) - it doesn't fail.


Re: Advice requested for fixing issue 17914

2017-10-25 Thread Nemanja Boric via Digitalmars-d
On Wednesday, 25 October 2017 at 15:43:12 UTC, Steven 
Schveighoffer wrote:

On 10/25/17 11:27 AM, Nemanja Boric wrote:
On Wednesday, 25 October 2017 at 15:22:18 UTC, Nemanja Boric 
wrote:
On Wednesday, 25 October 2017 at 15:12:27 UTC, Nemanja Boric 
wrote:
On Wednesday, 25 October 2017 at 14:19:14 UTC, Jonathan M 
Davis wrote:
On Wednesday, October 25, 2017 09:26:26 Steven 
Schveighoffer via Digitalmars-d wrote:

[...]


Maybe there was a change in the OS(es) being used that 
affected the limit?


- Jonathan M Davis


Yes, the stack is not immediately unmapped because it's very 
common
just to reset the fiber and reuse it for handling the new 
connection -
creating new fibers (and doing unmap on termination) is a 
problem in the

real life (as this is as well).

At sociomantic we already had this issue: 
https://github.com/sociomantic-tsunami/tangort/issues/2 
Maybe this is the way to go - I don't see a reason why every 
stack should be mmaped separately.


I'm not sure that would allow us to mprotect the page guards, 
though.


I think the easiest way to proceed from here is to default the 
stack protection page to 0, so we avoid this regression. Once 
that's in, we can think about different allocation strategy 
for the fiber's stacks or throwing the exceptions on too many 
fibers (too bad mmap doesn't return error code, but you get 
SIGABRT instead :( )


mmap does return an error. And onOutMemoryError is called when 
it fails.


https://github.com/dlang/druntime/blob/master/src/core/thread.d#L4518

Which should throw an error:

https://github.com/dlang/druntime/blob/144c9e6e9a3c00aba82b92da527a52190fe91c97/src/core/exception.d#L542

however, when mprotect fails, it calls abort():

https://github.com/dlang/druntime/blob/master/src/core/thread.d#L4540


What do you think?


I think we should reverse the mprotect default, and try and 
determine a better way to opt-in to the limit.


Is this a Linux-specific problem? Are there issues with 
mprotect on other OSes? Or is Linux the only OS that supports 
mprotect?


-Steve



Reading FreeBSD man pages, it looks like at least FreeBSD has the 
same limitation in the mmap, but the man pages for the mprotect 
doesn't specify this. However, I believe it's just the issue in 
the man pages, as it would be the same thing really as with 
Linux. Linux's manpage for mprotect specifically says this:


   ENOMEM Changing the protection of a memory region would 
result in the
  total number of mappings with distinct attributes 
(e.g., read
  versus read/write protection) exceeding the allowed 
maximum.
  (For example, making the protection of a range 
PROT_READ in

  the middle of a region currently protected as
  PROT_READ|PROT_WRITE would result in three 
mappings: two
  read/write mappings at each end and a read-only 
mapping in the

  middle.)

so I was right about doubling the mappings.


> I think we should reverse the mprotect default, and try and
determine a better way to opt-in to the limit.


I agree: https://github.com/dlang/druntime/pull/1956


Re: Advice requested for fixing issue 17914

2017-10-25 Thread Nemanja Boric via Digitalmars-d
On Wednesday, 25 October 2017 at 15:32:36 UTC, Steven 
Schveighoffer wrote:

On 10/25/17 11:12 AM, Nemanja Boric wrote:
On Wednesday, 25 October 2017 at 14:19:14 UTC, Jonathan M 
Davis wrote:
On Wednesday, October 25, 2017 09:26:26 Steven Schveighoffer 
via Digitalmars-d wrote:

[...]


Maybe there was a change in the OS(es) being used that 
affected the limit?




Yes, the stack is not immediately unmapped because it's very 
common
just to reset the fiber and reuse it for handling the new 
connection -
creating new fibers (and doing unmap on termination) is a 
problem in the

real life (as this is as well).

At sociomantic we already had this issue: 
https://github.com/sociomantic-tsunami/tangort/issues/2 Maybe 
this is the way to go - I don't see a reason why every stack 
should be mmaped separately.


Hm... the mprotect docs specifically state that calling 
mprotect on something that's not allocated via mmap is 
undefined. So if you use GC to allocate Fiber stacks, you can't 
mprotect it.


I think what we need is a more configurable way to allocate 
stacks. There is a tradeoff to mprotect vs. simple allocation, 
and it's not obvious to choose one over the other.


I still am baffled as to why this is now showing up. Perhaps if 
you are using mmap as an allocator (as Fiber seems to be 
doing), it doesn't count towards the limit? Maybe it's just 
glommed into the standard allocator's space?


-Steve


I'm sorry I wrote several messages in the row, as the thoughts 
were
coming to me. I think the reason is that mprotect creates a new 
range, since it
needs to have distinct protection attributes, hence doubling the 
number of mappings.



Maybe it's just glommed into the standard allocator's space?



No, you get to see each fiber's stack allocated separately when 
you cat /proc/pid/mappings.


Re: Advice requested for fixing issue 17914

2017-10-25 Thread Nemanja Boric via Digitalmars-d
On Wednesday, 25 October 2017 at 15:22:18 UTC, Nemanja Boric 
wrote:
On Wednesday, 25 October 2017 at 15:12:27 UTC, Nemanja Boric 
wrote:
On Wednesday, 25 October 2017 at 14:19:14 UTC, Jonathan M 
Davis wrote:
On Wednesday, October 25, 2017 09:26:26 Steven Schveighoffer 
via Digitalmars-d wrote:

[...]


Maybe there was a change in the OS(es) being used that 
affected the limit?


- Jonathan M Davis


Yes, the stack is not immediately unmapped because it's very 
common
just to reset the fiber and reuse it for handling the new 
connection -
creating new fibers (and doing unmap on termination) is a 
problem in the

real life (as this is as well).

At sociomantic we already had this issue: 
https://github.com/sociomantic-tsunami/tangort/issues/2 Maybe 
this is the way to go - I don't see a reason why every stack 
should be mmaped separately.


I'm not sure that would allow us to mprotect the page guards, 
though.


I think the easiest way to proceed from here is to default the 
stack protection page to 0, so we avoid this regression. Once 
that's in, we can think about different allocation strategy for 
the fiber's stacks or throwing the exceptions on too many fibers 
(too bad mmap doesn't return error code, but you get SIGABRT 
instead :( )


What do you think?


Re: Advice requested for fixing issue 17914

2017-10-25 Thread Nemanja Boric via Digitalmars-d
On Wednesday, 25 October 2017 at 15:12:27 UTC, Nemanja Boric 
wrote:
On Wednesday, 25 October 2017 at 14:19:14 UTC, Jonathan M Davis 
wrote:
On Wednesday, October 25, 2017 09:26:26 Steven Schveighoffer 
via Digitalmars-d wrote:

[...]


Maybe there was a change in the OS(es) being used that 
affected the limit?


- Jonathan M Davis


Yes, the stack is not immediately unmapped because it's very 
common
just to reset the fiber and reuse it for handling the new 
connection -
creating new fibers (and doing unmap on termination) is a 
problem in the

real life (as this is as well).

At sociomantic we already had this issue: 
https://github.com/sociomantic-tsunami/tangort/issues/2 Maybe 
this is the way to go - I don't see a reason why every stack 
should be mmaped separately.


I'm not sure that would allow us to mprotect the page guards, 
though.


Re: Advice requested for fixing issue 17914

2017-10-25 Thread Nemanja Boric via Digitalmars-d
On Wednesday, 25 October 2017 at 13:26:26 UTC, Steven 
Schveighoffer wrote:

On 10/23/17 12:56 PM, Brian Schott wrote:

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

I need to get this issue resolved as soon as possible so that 
the fix makes it into the next compiler release. Because it 
involves cleanup code in a class destructor a design change 
may be necessary. Who should I contact to determine the best 
way to fix this bug?


It appears that the limitation applies to mmap calls as well, 
and mmap call to allocate the stack has been in Fiber since as 
far as I can tell the beginning. How has this not shown up 
before?


Although after the stack overflow protection for fibers number of 
mmap calls is the same, _I think_ mprotect actually splits the 
single mmapped region into two (as they share different 
protection bits). This effectively doubles the number of the 
regions. As a workaround (if you have lots of fibers and doesn't 
care about stack overflow protection) you can just pass zero for 
the guardPageSize: 
https://github.com/dlang/druntime/blob/master/src/core/thread.d#L4037


Re: Advice requested for fixing issue 17914

2017-10-25 Thread Nemanja Boric via Digitalmars-d
On Wednesday, 25 October 2017 at 14:19:14 UTC, Jonathan M Davis 
wrote:
On Wednesday, October 25, 2017 09:26:26 Steven Schveighoffer 
via Digitalmars-d wrote:

On 10/23/17 12:56 PM, Brian Schott wrote:
> Context: https://issues.dlang.org/show_bug.cgi?id=17914
>
> I need to get this issue resolved as soon as possible so 
> that the fix makes it into the next compiler release. 
> Because it involves cleanup code in a class destructor a 
> design change may be necessary. Who should I contact to 
> determine the best way to fix this bug?


It appears that the limitation applies to mmap calls as well, 
and mmap call to allocate the stack has been in Fiber since as 
far as I can tell the beginning. How has this not shown up 
before?


Maybe there was a change in the OS(es) being used that affected 
the limit?


- Jonathan M Davis


Yes, the stack is not immediately unmapped because it's very 
common
just to reset the fiber and reuse it for handling the new 
connection -
creating new fibers (and doing unmap on termination) is a problem 
in the

real life (as this is as well).

At sociomantic we already had this issue: 
https://github.com/sociomantic-tsunami/tangort/issues/2 Maybe 
this is the way to go - I don't see a reason why every stack 
should be mmaped separately.


Re: Advice requested for fixing issue 17914

2017-10-25 Thread Nemanja Boric via Digitalmars-d
On Wednesday, 25 October 2017 at 14:19:14 UTC, Jonathan M Davis 
wrote:
On Wednesday, October 25, 2017 09:26:26 Steven Schveighoffer 
via Digitalmars-d wrote:

On 10/23/17 12:56 PM, Brian Schott wrote:
> Context: https://issues.dlang.org/show_bug.cgi?id=17914
>
> I need to get this issue resolved as soon as possible so 
> that the fix makes it into the next compiler release. 
> Because it involves cleanup code in a class destructor a 
> design change may be necessary. Who should I contact to 
> determine the best way to fix this bug?


It appears that the limitation applies to mmap calls as well, 
and mmap call to allocate the stack has been in Fiber since as 
far as I can tell the beginning. How has this not shown up 
before?


Maybe there was a change in the OS(es) being used that affected 
the limit?


- Jonathan M Davis


On linux it's controllable by: `sysctl vm.max_map_count`


Re: Why is it so difficult to get a core dump for exceptions/errors?

2017-10-23 Thread Nemanja Boric via Digitalmars-d

On Monday, 23 October 2017 at 07:27:03 UTC, Iain Buclaw wrote:

On Monday, 23 October 2017 at 06:48:50 UTC, Nemanja Boric wrote:

On Sunday, 22 October 2017 at 11:16:56 UTC, Marenz wrote:

One thing that bugged me for years in D is how difficult it
Perhaps dmd druntime could be smarter here and also dump the 
stack trace to stderr.





It does as of v2.076: 
https://github.com/dlang/druntime/blob/e160a6ad90900917010619c944db2d55731b527d/src/rt/dwarfeh.d#L226





Re: Why is it so difficult to get a core dump for exceptions/errors?

2017-10-23 Thread Nemanja Boric via Digitalmars-d

On Monday, 23 October 2017 at 06:48:50 UTC, Nemanja Boric wrote:

On Sunday, 22 October 2017 at 11:16:56 UTC, Marenz wrote:
One thing that bugged me for years in D is how difficult it is 
to get a useful core dump.


```
Task terminated with unhandled exception: Invalid memory 
operation
Full error: 
core.exception.InvalidMemoryOperationError@src/core/exception.d(693): Invalid memory operation


uncaught exception
dwarfeh(224) fatal error
```



What version of compiler/runtime are you using? I've fixed this 
behaviour
(fatal error if no exception handler is found) in v2.076: 
https://github.com/dlang/druntime/pull/1673 and the fix should 
actually
call abort(): 
https://github.com/dlang/druntime/pull/1673/files#diff-6c3bc1200b51af9b16b902fd88879ca1R227


Judging from the output (dwarfeh(224) fatal error), this patch 
is not applied

in your runtime.


As for the core dump - the runtime actually calls abort (pre and 
post my patch, as it looks like). I'm not aware anything in the 
runtime handling SIGABRT, are you doing it in your application? 
Is your system setup to generate core files `ulimit -c unlimited` 
or similar? You should at least get in your stderr (not stdout) 
message that the SIGABRT was raised (and you did before IIRC, 
you've commented it on one PR).


Re: Why is it so difficult to get a core dump for exceptions/errors?

2017-10-22 Thread Nemanja Boric via Digitalmars-d

On Sunday, 22 October 2017 at 11:16:56 UTC, Marenz wrote:
One thing that bugged me for years in D is how difficult it is 
to get a useful core dump.


```
Task terminated with unhandled exception: Invalid memory 
operation
Full error: 
core.exception.InvalidMemoryOperationError@src/core/exception.d(693): Invalid memory operation


uncaught exception
dwarfeh(224) fatal error
```



What version of compiler/runtime are you using? I've fixed this 
behaviour
(fatal error if no exception handler is found) in v2.076: 
https://github.com/dlang/druntime/pull/1673 and the fix should 
actually
call abort(): 
https://github.com/dlang/druntime/pull/1673/files#diff-6c3bc1200b51af9b16b902fd88879ca1R227


Judging from the output (dwarfeh(224) fatal error), this patch is 
not applied

in your runtime.


Re: code.dlang.org is offline?

2017-09-22 Thread Nemanja Boric via Digitalmars-d

On Friday, 22 September 2017 at 08:14:43 UTC, Szabo Bogdan wrote:

Hi,

Is there a reason why code.dlang.org is offline?

Thanks,
Bogdan


Works from here.

Best,
Nemanja


Re: Exception chaining and collectException

2017-08-22 Thread Nemanja Boric via Digitalmars-d

On Tuesday, 22 August 2017 at 07:03:03 UTC, Nemanja Boric wrote:

On Monday, 21 August 2017 at 20:15:53 UTC, Ali Çehreli wrote:

On 08/19/2017 01:58 PM, Nemanja Boric wrote:

C++ also provides a way to inspect if you're in the middle of 
the stack
unwinding caused by an exception, to make this a bit more 
controllable,

and I would think we should provide the similar primitive:
.



I don't know whether C++11 changed matters but according to 
popular C++98 wisdom, we were told "Don't use 
[std::uncaught_exception]":


  www.gotw.ca/gotw/047.htm

Ali


Rationale for changing this in C++17 is actually comming from 
Herb Sutter and it is referring to gotw47: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3614.pdf


Sorry, on the phone, so I've pasted wrong link: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4152.pdf


Re: Exception chaining and collectException

2017-08-22 Thread Nemanja Boric via Digitalmars-d

On Monday, 21 August 2017 at 20:15:53 UTC, Ali Çehreli wrote:

On 08/19/2017 01:58 PM, Nemanja Boric wrote:

C++ also provides a way to inspect if you're in the middle of 
the stack
unwinding caused by an exception, to make this a bit more 
controllable,

and I would think we should provide the similar primitive:
.



I don't know whether C++11 changed matters but according to 
popular C++98 wisdom, we were told "Don't use 
[std::uncaught_exception]":


  www.gotw.ca/gotw/047.htm

Ali


Rationale for changing this in C++17 is actually comming from 
Herb Sutter and it is referring to gotw47: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3614.pdf


Re: Fix D's segfaults!

2017-08-21 Thread Nemanja Boric via Digitalmars-d

On Sunday, 20 August 2017 at 18:01:06 UTC, Johnson Jones wrote:
D has a major issue with segfaults! It always reports the fault 
in the lowest function that it occurs! This is completely 
useless!


std.file.FileException@std\file.d(755): Attempting to rename 
file X.lib to Y.lib: The system cannot find the file specified.


0x0041015E
0x00402C69
0x004025A3
0x00413ECF
0x00413E93
0x00413D94
0x0040DAD7
0x76D78744 in BaseThreadInitThunk
0x76FD582D in RtlGetAppContainerNamedObjectPath
0x76FD57FD in RtlGetAppContainerNamedObjectPath

This tells me nothing about where the error occurred in *my* 
program!


Dmd needs to be modified so that errors try to show from the 
source code. This should be obvious the reasons, if it is not 
possible, make it possible! There are no excuses why dmd should 
make me go on an easter egg hunt when a seg fault occurs.


There are many issues and ideas reported in bugzilla about this: 
https://issues.dlang.org/show_bug.cgi?id=14885 
https://issues.dlang.org/show_bug.cgi?id=5944 etc. Here's the one 
that specifically tackles the `FileException` and the problem 
you're reporting: https://issues.dlang.org/show_bug.cgi?id=13543


Re: Fix D's segfaults!

2017-08-21 Thread Nemanja Boric via Digitalmars-d

On Sunday, 20 August 2017 at 19:35:45 UTC, Ali Çehreli wrote:

On 08/20/2017 12:14 PM, Johnson Jones wrote:

>>> Dmd needs to be modified so that errors try to show from
the source
>>> code. This should be obvious the reasons, if it is not
possible, make
>>> it possible! There are no excuses why dmd should make me go
on an
>>> easter egg hunt when a seg fault occurs.

You can open an enhancement request at

  https://issues.dlang.org/enter_bug.cgi

I don't know how well it works with D but what I used to do 
with C++ was to put a break point at Exception constructor, 
which would give me the useful stack to go back to my own code.


Ali


The usual trick is to set the breakpoint on `_d_throwdwarf`.


Re: Exception chaining and collectException

2017-08-19 Thread Nemanja Boric via Digitalmars-d

On Friday, 18 August 2017 at 22:51:35 UTC, Walter Bright wrote:

On 8/18/2017 5:07 AM, Steven Schveighoffer wrote:
If we are to remove them, what happens when exceptions would 
normally chain?


In C++, throwing an exception while unwinding is a fatal error.



Well, you still can throw it, but you're not allowed to let it 
escape the destructor (you need to catch them before they would 
chain).


C++ also provides a way to inspect if you're in the middle of the 
stack unwinding caused by an exception, to make this a bit more 
controllable, and I would think we should provide the similar 
primitive: 
http://en.cppreference.com/w/cpp/error/uncaught_exception.




Re: addr2line not showing line numbers

2017-08-06 Thread Nemanja Boric via Digitalmars-d

On Sunday, 6 August 2017 at 06:20:28 UTC, Shachar Shemesh wrote:
gdb can break on function name, but cannot single step from 
that point, as it claims it has no line information.


Judging by the stack trace for 1) it looks like it's not breaking 
for the user provided main function (called by druntime), but on 
the druntime's main, called by glibc, which is possible to be 
built with no debug info?


Re: If Statement with Declaration

2017-07-19 Thread Nemanja Boric via Digitalmars-d

On Wednesday, 19 July 2017 at 14:26:52 UTC, Dukc wrote:

On Wednesday, 19 July 2017 at 13:37:50 UTC, Adam D. Ruppe wrote:

I like it.


Me too. I think this should also apply to switch and with 
statements. Perhaps while statements too.


Right, C++17 has it also for a switch:

```
If init-statement is used, the switch statement is equivalent to
{
init_statement
switch ( condition ) statement
}
```

http://en.cppreference.com/w/cpp/language/switch


Re: If Statement with Declaration

2017-07-19 Thread Nemanja Boric via Digitalmars-d

On Wednesday, 19 July 2017 at 13:30:56 UTC, sontung wrote:
So I was thinking of a way of extending if statements that have 
declarations. The following being as example of the current use 
of if statements with declarations:


if(int* weDontPollute = someFunc())
{
 // use weDontPollute
}

That's great and all, but it only works by checking if the 
variable evaluates to true or false. Which is fine for a 
pointer but otherwise useless for anything else, like integers 
where zero is usually valid input (index for array). So 
currently the only way to do something like this in the 
language, that i've found, is to use a for statement.


for(int i = someFunc(); i >= 0;)
{
// use i

break;
}

Not that ideal to use a for statement. It makes it hard to read 
and if the break condition isn't there it might very well be an 
infinite loop. So I was thinking of some sort of syntax like 
this:


if(int i = someFunc(); i >= 0)
{
// use i
}
Thoughts on this sort of feature?


This is included in C++17: 
http://en.cppreference.com/w/cpp/language/if


```
int demo() {
   if (auto it = m.find(10); it != m.end()) { return it->size(); }
   if (char buf[10]; std::fgets(buf, 10, stdin)) { m[0] += buf; }
...
```


Re: D Milestones

2017-07-12 Thread Nemanja Boric via Digitalmars-d

On Wednesday, 12 July 2017 at 13:11:47 UTC, Nicholas Wilson wrote:
On Wednesday, 12 July 2017 at 12:40:21 UTC, Martin Tschierschke 
wrote:
On Monday, 26 June 2017 at 18:16:12 UTC, Patrick Schluter 
wrote:

On Monday, 26 June 2017 at 12:58:00 UTC, Andrea Fontana wrote:

On Monday, 26 June 2017 at 10:14:08 UTC, Martin Tschierschke

[...]
So the first version 0.0.1 of this in the Wiki, please help to 
update!


https://wiki.dlang.org/Language_History_and_Future


If you're looking for more info Leandro's Keynote (DConf 2016?) 
has lots of history.


Yup, 2016: http://dconf.org/2016/talks/lucarella.html


Re: dmd and Archlinux

2017-07-09 Thread Nemanja Boric via Digitalmars-d

On Sunday, 9 July 2017 at 18:35:09 UTC, Antonio Corbi wrote:

Hi!

Are there any news about the status of packaging dmd for 
archlinux?


The last dmd compiler packaged is 2.074.0 and since the last 
batch of updated packages in archlinux, dmd generated objects 
fail to link with libphobos with erros like these:


/usr/bin/ld: /usr/lib/libphobos2.a(object_a_66e.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when 
making a shared object; recompile con -fPIC
/usr/bin/ld: /usr/lib/libphobos2.a(object_b_58c.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when 
making a shared object; recompile con -fPIC
/usr/bin/ld: /usr/lib/libphobos2.a(object_c_7f4.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when 
making a shared object; recompile con -fPIC
/usr/bin/ld: /usr/lib/libphobos2.a(object_d_a07.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when 
making a shared object; recompile con ...


A. Corbi


Hm, I can't reproduce this issue with dmd 2.074.0-1. I've just 
installed dmd and it works out

of the box:

```
➜  arch tmp% pacman -Q | grep phob
libphobos-devel 1:2.074.0-1
➜  arch tmp% pacman -Q | grep dmd
dmd 1:2.074.0-1
➜  arch tmp% cat test.d
import std.stdio;

void main()
{
writeln("hello!");
}
➜  arch tmp% dmd -c test.d
➜  arch tmp% dmd test.o
➜  arch tmp% ./test
hello!
```


Re: Automatic invariant generation

2017-07-07 Thread Nemanja Boric via Digitalmars-d

On Friday, 7 July 2017 at 08:21:50 UTC, Nicholas Wilson wrote:
The compiler seems to inset an `assert(this !is null, "null 
this");` into my struct.

which is for all intents and purposes.
struct Foo {
Bar b;
}

struct Bar {
void* ptr;
}

I tried disabling the invariant but it complained that 
invariant requires a function body.
Is there a way to disable the implicit generations of 
invariants for my code other than -release? Like for a 
particular subset of files (separate invocations of the 
compiler is not an acceptable approach.


The reason being that I do not support global variables (of any 
kind) at the moment in dcompute and the insertion of the string 
literal to the assert breaks that.


Related: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md


Re: Foreach loops on static arrays error message

2017-07-06 Thread Nemanja Boric via Digitalmars-d

On Thursday, 6 July 2017 at 08:49:33 UTC, Stefan Koch wrote:
On Thursday, 6 July 2017 at 08:26:42 UTC, Guillaume Chatelet 
wrote:

[...]


I'd say this is not often encoutered.
One should avoid using a different type then size_t for the 
index, as it can have negative performance implications.


Interesting. What would be the example of negative performance 
implication? I'm guilty of using the int on occasions.


Re: Fantastic exchange from DConf

2017-05-12 Thread Nemanja Boric via Digitalmars-d

On Friday, 12 May 2017 at 18:52:43 UTC, Joakim wrote:

On Saturday, 6 May 2017 at 09:53:52 UTC, qznc wrote:

On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:

[...]


Hm, Sociomantic removes the live captures the next day?

One request: Chop the panel discussion into one clip per 
question/topic, please. Alternatively, provide some means to 
easily jump to the start of each question.


Video of the exchange is now back up:

https://www.youtube.com/watch?v=Lo6Q2vB9AAg#t=24m37s

Question now starts at 22m:19s mark.


Oh no, my accent is terrible!
Time to stand in front of a mirror and rehersal :-).

When I said "outside community pressure", I meant "trends", but 
didn't make it clear then :(.




Re: DConf 2017 Hackathon report

2017-05-09 Thread Nemanja Boric via Digitalmars-d

On Tuesday, 9 May 2017 at 16:14:57 UTC, Nemanja Boric wrote:

On Tuesday, 9 May 2017 at 04:35:40 UTC, Ali Çehreli wrote:
Please list what we've achieved during the hackathon, 
including what is started but is likely to be finished in the 
coming days or months.


For me:

- Finished updating "Programming in D" to 2.074.0 (the HTML is 
now up to date but I could not get to the still manual work of 
preparing the ebooks)


- Contributed to the logo and branding discussions

- Opened two bugs

- Ate German cookies :)

Ali


I've fixed the FreeBSD-Current exception handling issue, so
that exception handling is now working there as well (I also 
suspect
that it was broken pretty much on all libundwind 64bit systems, 
just worked by accident, since the optimizer didn't try too 
hard.


It's something I wanted to do for a long time, but there's 
never time,

so having a day dedicated to it was pretty helpful!

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

It was pretty cool finding Jonathan who filed the bug in the 
same room, then
chasing Walter to talk about it, after hearing all war stories, 
including,

but not limited to, blue meteors.


Oh, also working with Martin and chasing him around the rooms to 
get
my druntime PR for fiber stack overflow protection 
(https://github.com/dlang/druntime/pull/1698)
merged after months and months is also worth mentioning, although 
it didn't happen during the hackaton :-)


Re: DConf 2017 Hackathon report

2017-05-09 Thread Nemanja Boric via Digitalmars-d

On Tuesday, 9 May 2017 at 04:35:40 UTC, Ali Çehreli wrote:
Please list what we've achieved during the hackathon, including 
what is started but is likely to be finished in the coming days 
or months.


For me:

- Finished updating "Programming in D" to 2.074.0 (the HTML is 
now up to date but I could not get to the still manual work of 
preparing the ebooks)


- Contributed to the logo and branding discussions

- Opened two bugs

- Ate German cookies :)

Ali


I've fixed the FreeBSD-Current exception handling issue, so
that exception handling is now working there as well (I also 
suspect
that it was broken pretty much on all libundwind 64bit systems, 
just worked by accident, since the optimizer didn't try too hard.


It's something I wanted to do for a long time, but there's never 
time,

so having a day dedicated to it was pretty helpful!

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

It was pretty cool finding Jonathan who filed the bug in the same 
room, then
chasing Walter to talk about it, after hearing all war stories, 
including,

but not limited to, blue meteors.


Re: See you soon at dconf

2017-05-03 Thread Nemanja Boric via Digitalmars-d

On Wednesday, 3 May 2017 at 15:05:02 UTC, Bastiaan Veelo wrote:

On Wednesday, 3 May 2017 at 14:38:41 UTC, Rene Zwanenburg wrote:
On Wednesday, 3 May 2017 at 13:36:45 UTC, Steven Schveighoffer 
wrote:
I am at the Ludwig van Beethoven hotel. Just had a 2 hour 
nap, couldn't sleep on the plane. So a few beers will do me 
well (first of which I'm having now ;). Where were you 
thinking to meet?


-Steve


Are you still at the hotel bar? I just went down there but saw 
no-one.


Sorry I lost cellular connection. Steve an I took the U7 to 
Ibis, 6 stops. We are 9 chaps atm. "Kurzstreckefahrkarte" is 
enough, the cheap ticket.


I might be wrong, but it's 6 stops for the Bus/Tram drive, and 
only three for the

U/S Bahn drive:

Einzelfahrausweise für Kurzstrecken gelten im Tarifbereich 
Berlin (AB,BC,ABC) für bis zu drei Stationen mit der S-Bahn, 
U-Bahn oder bis zu sechs Stationen mit Bus oder Straßenbahn.


http://www.s-bahn-berlin.de/aboundtickets/kurzstrecke.htm





Re: Have some down time at the year's end?

2017-02-10 Thread Nemanja Boric via Digitalmars-d
On Friday, 10 February 2017 at 17:15:12 UTC, Dominikus Dittes 
Scherkl wrote:
On Friday, 10 February 2017 at 14:36:31 UTC, Nemanja Boric 
wrote:
On Friday, 10 February 2017 at 02:42:10 UTC, Andrei 
Alexandrescu wrote:

On 02/09/2017 05:03 PM, Daniel Kozak wrote:
Is this still accurate? I mean if I change some issue to 
"trivial", is
there any process which will notify you or your students 
about it? Or

are they actively watch this list?


There is no automation. Thanks! -- Andrei


Speaking of the recent discussion of abandoned trivial PRs, 
here's

the one I submitted PR for, but got 0 attention:

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

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


Hmm. For me seems like you got some comments on your PR but 
didn't answer. Seems plausible not to include such PR.


You should check the dates ;-).
I got these comments today, only after writing this message.



Re: Have some down time at the year's end?

2017-02-10 Thread Nemanja Boric via Digitalmars-d
On Friday, 10 February 2017 at 02:42:10 UTC, Andrei Alexandrescu 
wrote:

On 02/09/2017 05:03 PM, Daniel Kozak wrote:
Is this still accurate? I mean if I change some issue to 
"trivial", is
there any process which will notify you or your students about 
it? Or

are they actively watch this list?


There is no automation. Thanks! -- Andrei


Speaking of the recent discussion of abandoned trivial PRs, here's
the one I submitted PR for, but got 0 attention:

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

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


Re: Best error msg ever

2017-02-10 Thread Nemanja Boric via Digitalmars-d

On Friday, 10 February 2017 at 04:02:17 UTC, Era Scarecrow wrote:
On Friday, 10 February 2017 at 02:53:50 UTC, Era Scarecrow 
wrote:
Seems the built in Date class wasn't the same as the Sql.Date 
that was being used (but had the same name). Apparently it 
took like 2 hours to figure out what was going on.


 Oh right forgot to mention one important detail. In Java the 
program compiled without errors; It was when it was trying to 
be used that it would crash unexpectedly. Refusing to compile 
is slightly better than crashing unexpectedly later.


I saw it happen with D as well: everything compiles, everything is
fine, and suddenly segfault. The issue was caused by template 
argument, two
modules with the same name, but from different packages (think 
`myalib.blah.morebla.foo` and `myblib.blah.morebla.foo`) and a 
cast
somewhere in the middle of the callstack which casted the first 
template argument to the second one, where the `myalib`'s foo was 
casted to `myblib`'s interface.


Worse of all, `myalib` and `myblib` were just mentioned in the 
imports,

far away from the call site.


Question about scope

2017-01-27 Thread Nemanja Boric via Digitalmars-d
Taken from 
https://github.com/dlang/druntime/pull/1750#discussion_r98181564:


```
void bar(scope char** c, scope int* n) @trusted
{
}

void foo() @safe
{
char[100] buf;
char* c = &buf[0];
int n;

bar(&c, &n);
}

void main()
{
foo();
}
```

This doesn't compile even with dip1000, but does compile when 
`buf` is moved out of the scope. Can somebody explain why it 
fails and what needs to be done with it?


Re: parent class get the subclass object

2017-01-16 Thread Nemanja Boric via Digitalmars-d

On Monday, 16 January 2017 at 16:31:41 UTC, Brian wrote:
On Monday, 16 January 2017 at 12:20:47 UTC, rikki cattermole 
wrote:

On 17/01/2017 1:15 AM, Brian wrote:

Dlang should support such coding. What should I do?

import std.stdio : writeln;

abstract class Base(T)
{
this()
{
_this = this;
}

void hello()
{
_this.world();
}

private
{
T _this;
}
}


class Sub : Base!Sub
{
void world()
{
writeln("Hello world");
}
}

void main()
{
Sub sub = new Sub;
sub.hello();
}



FYI, this would have been more appropriate in D.learn instead 
of the main forum.


import std.stdio;

abstract class Base {
void hello() {
world();
}

void world();
}

class Sub : Base {
override void world() {
writeln("Hello World");
}
}

void main() {
Sub sub = new Sub;
sub.hello();
}


No, you don't understand I want to express meaning.

other programing language is allow this.

Your code more like the old C++.

If a high-level programing language or need haevy like C++ impl 
code, It's very regret.


Can like rust / swift / php / java / C# ?


You're missing a cast, since `this` is a reference to a 
superclass.


import std.stdio : writeln;

abstract class Base(T)
{
this()
{
_this = cast(T)(this);
assert(_this);
}

void hello()
{
_this.world();
}

private
{
T _this;
}
}


class Sub : Base!Sub
{
void world()
{
writeln("Hello world");
}
}

void main()
{
Sub sub = new Sub;
sub.hello();
}



Re: Hangs on toStringZ()

2016-12-28 Thread Nemanja Boric via Digitalmars-d

On Wednesday, 28 December 2016 at 12:30:03 UTC, unDEFER wrote:
On Wednesday, 28 December 2016 at 11:32:09 UTC, Nemanja Boric 
wrote:
My other guess is that you're using D threads in your 
application?


Of course I'm using D threads, but with it all is normally.


Right, nothing wrong with threads, but super tricky to combine it 
with fork. So, it could be that one of your threads is using GC 
at the point of the forking, so it keeps the GC locked. Now you 
fork, and _all your threads don't exist anymore, they are 
vanished, and if you don't do some clever stuff in atfork 
handler, there will be no cleanup_ - you just have copy of the 
thread that called fork. So, the thread that should release GC 
lock doesn't exist anymore, and there's nothing to release mutex, 
and it will stay locked forever in your forked process.


Re: Hangs on toStringZ()

2016-12-28 Thread Nemanja Boric via Digitalmars-d
On Wednesday, 28 December 2016 at 11:30:22 UTC, Nemanja Boric 
wrote:
On Wednesday, 28 December 2016 at 11:21:34 UTC, Nemanja Boric 
wrote:

On Tuesday, 27 December 2016 at 17:27:14 UTC, unDEFER wrote:

[...]


Just a note here, string literals are already 0 terminated, so 
you don't need `toStringz` there.


Ah, I just saw Stefan already made this remark, sorry.

Given that you're in a forked process, it could be that you've 
just got your GC in a broken state (internal was locked prior 
to forking, and now you can't get the GC ever, since there's 
nothing to unlock it.


What you should do is following:

1. Allocate all needed data, convert all D strings into C 
strings, etc.

2. fork
3. exec immediately, not using anything from standard library 
between 2 and 3.


My other guess is that you're using D threads in your application?


Re: Hangs on toStringZ()

2016-12-28 Thread Nemanja Boric via Digitalmars-d
On Wednesday, 28 December 2016 at 11:21:34 UTC, Nemanja Boric 
wrote:

On Tuesday, 27 December 2016 at 17:27:14 UTC, unDEFER wrote:

Hello I have very simple line with exec-command:

execl("/bin/bash".toStringz(), "/bin/bash".toStringz(), 
"-c".toStringz(), command.toStringz(), null);


[...]


Just a note here, string literals are already 0 terminated, so 
you don't need `toStringz` there.


Ah, I just saw Stefan already made this remark, sorry.

Given that you're in a forked process, it could be that you've 
just got your GC in a broken state (internal was locked prior to 
forking, and now you can't get the GC ever, since there's nothing 
to unlock it.


What you should do is following:

1. Allocate all needed data, convert all D strings into C 
strings, etc.

2. fork
3. exec immediately, not using anything from standard library 
between 2 and 3.


Re: Hangs on toStringZ()

2016-12-28 Thread Nemanja Boric via Digitalmars-d

On Tuesday, 27 December 2016 at 17:27:14 UTC, unDEFER wrote:

Hello I have very simple line with exec-command:

execl("/bin/bash".toStringz(), "/bin/bash".toStringz(), 
"-c".toStringz(), command.toStringz(), null);


[...]


Just a note here, string literals are already 0 terminated, so 
you don't need `toStringz` there.


[OT] Screenshot of D program in the latest issue of Ct magazine

2016-12-24 Thread Nemanja Boric via Digitalmars-d

I thought I see familiar name :-)

http://imgur.com/a/TqGdj


Re: Why doesn't std.variant.visit automatically call the provided delegates?

2016-11-07 Thread Nemanja Boric via Digitalmars-d

On Saturday, 5 November 2016 at 20:15:14 UTC, Kapps wrote:


That's really confusing. I've used D for quite a while, and 
didn't know that. Admittedly I doubt I've ever tried () => { }, 
but given languages like C# which this syntax was partially 
taken from(?), that behaviour is very unexpected. That feels 
like it should be a compiler warning.


I was just going to say that after a weekend my mind on this is 
that this behavior is no different than C's:



if (x = 5) { }

issue. It deserves at least warning (if you make a delegate that 
returns delegate that can't be called).


Re: Why doesn't std.variant.visit automatically call the provided delegates?

2016-11-05 Thread Nemanja Boric via Digitalmars-d

On Saturday, 5 November 2016 at 10:09:55 UTC, Adam D. Ruppe wrote:
On Saturday, 5 November 2016 at 08:27:49 UTC, Nemanja Boric 
wrote:

[...]


It calls the function... which returns a delegate, which you 
never called.


This is one of the most common mistakes people are making: {} 
in D is a delegate, and () => is a delegate, therefore () => {} 
is a delegate that returns a delegate... usually NOT what you 
want.


What you wrote is equivalent to writing

delegate() callback(string s) {
   return delegate() {
 enforce(false);
 x = 2;
   };
}


Do not use the => syntax if there is more than one expression. 
You'll get what you want by simply leaving the => out:



   [...]


Oh, God. Thanks, Adam, all clear!

Thanks!


Why doesn't std.variant.visit automatically call the provided delegates?

2016-11-05 Thread Nemanja Boric via Digitalmars-d

```
import std.variant;
import std.stdio;
import std.exception;

void main()
{
Algebraic!(int, string) variant;

variant = 10;
int x = 0;
// Functions throws - uncomment and see
//variant.tryVisit!( (string s) => enforce(false),
//   (int i)=> enforce(false))();

// This - does nothing
variant.visit!((string s) => { enforce(false); x = 2; },
   (int i)=> { enforce(false); x = 3; 
})();

writeln("x = ", x);

// This works as expected
variant.visit!((string s) => { x = 2; }(),
   (int i) =>{ x = 3; }())();

writeln("x = ", x);
}
```


Re: colour lib needs reviewers

2016-09-15 Thread Nemanja Boric via Digitalmars-d

On Thursday, 15 September 2016 at 09:45:26 UTC, Marco Leise wrote:

Am Wed, 14 Sep 2016 23:44:16 -0700
schrieb Walter Bright :

I suspect that adding Markdown would help a lot (yes, I changed 
my mind about that).





https://github.com/kiith-sa/harbored-mod provides support for 
mixing ddoc and markdown. That's what we're using, and it's nice 
(especially because docs in source files look very close to 
generated ones), but it would be nicer if we could just use dmd 
for that, of course.


Re: Quality of errors in DMD

2016-09-04 Thread Nemanja Boric via Digitalmars-d
On Sunday, 4 September 2016 at 17:56:08 UTC, David Nadlinger 
wrote:
On Saturday, 3 September 2016 at 22:39:22 UTC, Walter Bright 
wrote:
Because it's useless to anyone but the compiler devs, and it 
adds cruft to the compiler. And even worse than useless, it 
confuses the user into thinking it is a meaningful message.


This is short-sighted, for the reason I pointed out in my 
earlier post. How would you go about reporting an ICE for a 
100k LOC test case without any idea about where to start 
looking?


In fact, that's precisely what happened to the guys at Weka 
before, although I'm certain they are not alone with this. They 
encountered ICEs when updating the compiler version with no way 
to narrow it down. Of course, *I* could just build DMD with 
symbols and have a look at what was going on in GDB, but that's 
the luxury of being a compiler dev.



Let's not pretend the user can debug the compiler.


They can create bug reports to help other people to do so, 
though.


 — David


I second this - sometimes you find it way too late: We had a 
nasty problem few weeks ago where *only compiling with `-O`*
kept crashing a compiler on a assertion 
(https://issues.dlang.org/show_bug.cgi?id=16225). And it was 
several thousands lines worth of code spread across many modules.


What I find useful is enabling debug prints of dmd, compiling and 
first concentration on the last mentioned module (I don't 
remember if this was already there, or if I extended some 
`writeln/printf`there). Then I approached it in the usual way - 
binary removing/putting back chunks of code.


Re: vibed.org is down

2016-09-02 Thread Nemanja Boric via Digitalmars-d

On Friday, 2 September 2016 at 11:24:53 UTC, Nemanja Boric wrote:

On Friday, 2 September 2016 at 10:32:07 UTC, Daniel Kozak wrote:

web@WebCN:~ $ ping ipult.cz
PING ipult.cz.eurocloud.cn (14.215.133.119) 56(84) bytes of 
data.
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=1 
ttl=64 time=0.031 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=2 
ttl=64 time=0.035 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=3 
ttl=64 time=0.028 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=4 
ttl=64 time=0.028 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=5 
ttl=64 time=0.030 ms




Given that there are 6-7000km from China to Czech Republic, 
your internet connection seems to be way faster than speed of 
light :-).


Ah, this is actually pinging some host in China, not the CZ. 
Sorry!


Re: vibed.org is down

2016-09-02 Thread Nemanja Boric via Digitalmars-d

On Friday, 2 September 2016 at 10:32:07 UTC, Daniel Kozak wrote:

web@WebCN:~ $ ping ipult.cz
PING ipult.cz.eurocloud.cn (14.215.133.119) 56(84) bytes of 
data.
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=1 
ttl=64 time=0.031 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=2 
ttl=64 time=0.035 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=3 
ttl=64 time=0.028 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=4 
ttl=64 time=0.028 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=5 
ttl=64 time=0.030 ms




Given that there are 6-7000km from China to Czech Republic, your 
internet connection seems to be way faster than speed of light 
:-).




[dpaste] compiler switch is broken

2016-07-04 Thread Nemanja Boric via Digitalmars-d
Not sure if the message should go here, but I can't find any 
contact info on dpaste.


We've noticed today that compiler switch no longer works, it 
compiles only with latest DMD, no matter what option is chosen.


Thanks!


Re: Hide input string from stdin

2016-05-23 Thread Nemanja Boric via Digitalmars-d

On Monday, 23 May 2016 at 15:56:14 UTC, Wyatt wrote:

On Sunday, 22 May 2016 at 22:38:46 UTC, Michael Chen wrote:
I tried to write a small program that receive string as 
password.
 However, I didn't find available library for hide input 
string, even in core library.  Any suggestion?


For Linux, I think you could just use getpass() from 
core.sys.posix.unistd.  Not sure what the Windows equivalent 
is.  An agnostic, user-facing version isn't a terrible idea.  
Or arguably better, a good way to disable echo on stdin; maybe 
file a bug about this against std.stdio?


-Wyatt


Here's example `getpass` (in C++, but can be translated 
trivially) for Windows, using `SetConsoleMode` with turning off 
`ENABLE_ECHO_OUTPUT`.


http://www.cplusplus.com/articles/E6vU7k9E/#WIN-e1


Re: Walter's Famous German Language Essentials Guide

2016-04-28 Thread Nemanja Boric via Digitalmars-d

On Thursday, 28 April 2016 at 13:49:15 UTC, jack wrote:

On Thursday, 28 April 2016 at 06:51:04 UTC, Ali Çehreli wrote:

On 04/26/2016 07:57 PM, Walter Bright wrote:
To prepare for a week in Berlin, a few German phrases is all 
you'll need

to fit in, get around, and have a great time:

1. Ein Bier bitte!
2. Noch ein Bier bitte!
3. Wo ist der WC!


The other language that helps in Berlin is Turkish. :)

Ali


unfortunately - too many islam and erdogan people


Please be civil.


Re: Directions to Ibis Hotel in Berlin from Tegel Airport

2016-04-26 Thread Nemanja Boric via Digitalmars-d

On Tuesday, 26 April 2016 at 19:21:13 UTC, Andrej Mitrovic wrote:
It's really not so bad anymore as it used to be. Credit cards 
are accepted in most stores or supermarkets, even "Netto" which 
is a discount-store and which started accepting Visa just last 
year. Other stores like "Real" and "Kaisers" will accept Visa, 
even many small shops will accept it.


Then again the Burger King at Alexanderplatz will for some 
reason *not* accept any credit card, while the McDonalds which 
is ~50 meters away will.


This is assuming you want to eat at those places while you're 
in Berlin, obviously there's great food here that you could try 
rather than go to the familiar fast-food chains.. If you're 
going to go for a döner kebab prepare some cash!


In some cases they might ask you for your ID (e.g. passport).

On 4/26/16, Johannes Pfau via Digitalmars-d 
 wrote:

Am Tue, 26 Apr 2016 12:25:41 +
schrieb Kagamin :


On Monday, 25 April 2016 at 09:16:11 UTC, Iain Buclaw wrote:
> Germany is a cash-in-hand country.  Credit cards are 
> rejected in most places that I've tried.


You mean debit cards are accepted? Anyway why credit cards? 
Aren't credit money more expensive than debit? The overdraft 
limit is just a fixed offset from zero and you pay extra 
interest, one could just imagine zero balance at his 
preferred offset and keep it there.


The girocard (sometimes called EC card) debit card system is 
accepted at most places: 
https://en.wikipedia.org/wiki/Girocard IIRC you need a german 
bank account though to own such a card ;-)


I was today to TXL, so I took some pictures while riding home (I 
was sitting on a passenger side).


First, here are the routes for 109 and U7:

https://www.bvg.de/images/content/linienverlaeufe/LinienverlaufBus109.pdf
https://www.bvg.de/images/content/linienverlaeufe/LinienverlaufU7.pdf

This is the U-Bahnhof Jakob-Keiser-Platz:

http://imgur.com/nCBxOho

This is the pink-orange building just before it (I took a picture 
when I passed it):


http://imgur.com/zrQw6Fn

In the bus, there's a display showing next station and a voice 
(in German, but even I can recognize the name of the station) 
telling the name of the next station. It's needed to indicate 
that you're going off the bus (this caught me when I was a new 
one) which needs to be pressed *before* the bus arrive to the 
station (if somebody has pressed it, you'll see red STOP on the 
right corner of the display) by pressing one of the green tasters 
on the yellow bars. Sorry for the potato quality:


http://imgur.com/gTzEtxh

And *bonus level*. If you didn't get off at U-Bahnhof 
Jakob-Keiser-Platz, 15 minutes after, 109 will get to U Bahnhof 
Adenauerplatz where you can catch U7 again (just after it turns 
right after S-Bahnhof Charlottenburg):


http://imgur.com/0TZWI7P





Re: Directions to Ibis Hotel in Berlin from Tegel Airport

2016-04-25 Thread Nemanja Boric via Digitalmars-d

On Monday, 25 April 2016 at 13:00:40 UTC, Chris wrote:

On Monday, 25 April 2016 at 12:03:12 UTC, Nemanja Boric wrote:

On Monday, 25 April 2016 at 11:12:04 UTC, Mike Parker wrote:



Taxi shortest route (20.9km) ~26 minutes, cost: €38.53 [1]

Bus+U-Bahn 53 minutes (if you don't have to wait 20 minutes for 
the bus)




Speaking of which, X9 also drives from the airport to U 
Jakob-Keiser Platz IIRC (beware, it's an express line so it's the 
first stop, be ready to press `Stop` button in the bus :-) ). 109 
and X9 should depart from like 10 meters away, and where every 
bus stands there's a display that tells how much time to the next 
bus.


(https://www.bvg.de/images/content/linienverlaeufe/LinienverlaufBusX9.pdf). I'm 
going tomorrow night to the airport anyway, so I'll confirm.


Re: Directions to Ibis Hotel in Berlin from Tegel Airport

2016-04-25 Thread Nemanja Boric via Digitalmars-d

On Monday, 25 April 2016 at 11:12:04 UTC, Mike Parker wrote:

On Monday, 25 April 2016 at 08:43:34 UTC, Jens Mueller wrote:


More questions?



I'll be getting out of the airport probably around 10:00 pm or 
so. I've seen online the subways run into the early am, but 
would I be better off grabbing a taxi at that time?


10:00PM is very early in the evening by Berlin standards, you 
should be fine :-).


Re: Directions to Ibis Hotel in Berlin from Tegel Airport

2016-04-25 Thread Nemanja Boric via Digitalmars-d

On Monday, 25 April 2016 at 08:56:59 UTC, Nemanja Boric wrote:

On Sunday, 24 April 2016 at 21:40:16 UTC, Walter Bright wrote:

[...]


You can buy it from driver, but I don't think buses accept 
credit cards (maybe I'm wrong), so you'll have to have some
euros by yourself. On TXL airport, just before you exit to the 
bus station there is a BVG (public transport) kiosk (see 
http://nanoparticles.org/Particles2011/TXL.gif) where you can 
buy tickets.


[...]


I got this part wrong:


You can switch to English and they accept credit cards.


Correct answer is:

You cannot pay by credit card. Only EC card which is like 
credit card without credit.


They really look the same :-).


Re: Directions to Ibis Hotel in Berlin from Tegel Airport

2016-04-25 Thread Nemanja Boric via Digitalmars-d

On Sunday, 24 April 2016 at 21:40:16 UTC, Walter Bright wrote:

On 4/24/2016 10:56 AM, Iain Buclaw via Digitalmars-d wrote:

On 24 April 2016 at 10:44, Walter Bright via Digitalmars-d
 wrote:
The hotel emailed them to me, I presume they know what 
they're doing :-) so

I thought I'd share:

Bus 109 to Jakob-Kaiser-Platz
Subway U 7 in the direction of Rudow to Grenzallee
Cross the street at the traffic light and turn left. The next 
street on the

right is Jahnstraße.
On the left side you will find our hotel.


Conveniently, also the directions to Berghain.  :-)



What's the best way to buy a ticket? On the bus itself, or is 
there a kiosk? Credit card?


You can buy it from driver, but I don't think buses accept credit 
cards (maybe I'm wrong), so you'll have to have some
euros by yourself. On TXL airport, just before you exit to the 
bus station there is a BVG (public transport) kiosk (see 
http://nanoparticles.org/Particles2011/TXL.gif) where you can buy 
tickets.


If you're adventurous, when you get out from the airport (from 
terminal A) to the bus stations, the bus stops are just in front 
of you and if you turn right you'll find ticket machines (looks 
like this 
https://www.bvg.de/en/Tickets/Other-ways-to-buy/At-ticket-machines) located by the wall. You can switch to English and they accept credit cards.


I'm not aware of all options, but you can buy single ticket for 
2.70 euro (I think?), 4 tickets for 9 euros, or you can buy 
weekly ticket (de. 7-Tage-Karte) and it costs 30EUR. If you're 
landing on TXL you'll just need AB zone.


Btw, single ticket is valid for your entire journey, (both Bus 
109 and U7) and if you're not buying it from driver, you need to 
validate it when you enter the bus (just stick it into the 
stamping machine).


I hope I didn't get anything wrong!


Re: [OT] Some neat ideas from the Kotlin language

2016-02-19 Thread Nemanja Boric via Digitalmars-d

On Friday, 19 February 2016 at 12:16:49 UTC, Jacob Carlborg wrote:

I like the way it's used in Scala:

val a = Option(value)
val b = a.map(e => e /* do something with the unrapped 
e).getOrElse(/* use a default value here */)


The Option type in Scala acts like a zero or one element 
collection. The Scala way can be implemented in D as well 
without any language support.




IMHO, without language support looks really bad - `map` really 
sticks out here.


What Rust is doing:

```
let foo: Option = bar();

let new_stuff = match foo {
   Some(x) => x,
   None => 0
}
```

(or similar, I don't have compiler handy).


Re: Distributed Memory implementation

2016-01-18 Thread Nemanja Boric via Digitalmars-d

On Monday, 18 January 2016 at 09:28:59 UTC, tcak wrote:

On Monday, 18 January 2016 at 08:12:03 UTC, Nemanja Boric wrote:

On Monday, 18 January 2016 at 05:59:15 UTC, tcak wrote:

[...]


Check https://dlang.org/phobos/std_experimental_allocator.html


Which part of this module provide the functionality of using 
non-consecutive memory(distributed) blocks like they are 
consecutive?


IIRC, none of them, sorry, but if you're going to implement it, 
my guess it that

it should be compatible with `std.experimental.allocator`.


Re: Distributed Memory implementation

2016-01-18 Thread Nemanja Boric via Digitalmars-d

On Monday, 18 January 2016 at 05:59:15 UTC, tcak wrote:
I, due to a need, will start implementation of distributed 
memory system.


Idea is that:

Let's say you have allocated 1 GiB space in memory. This memory 
is blocked into 4 KiB.


After some reservation, and free operations, now only the 
blocks 0, 12, and 13 are free to be allocated.


Problem is that those memory blocks are not consecutive.

With the implementation of distributed memory, those blocks 
will be appended into a struct or object (however it is 
implemented), and that struct or object will allow access to 
that 12 KiB of space (3 x 4 KiB blocks) like it is allocated in 
memory consecutively.


Is there anything like this in Phobos, or shall I start my own 
implementation?


Check https://dlang.org/phobos/std_experimental_allocator.html


Re: Synchronized classes have no public members

2015-10-13 Thread Nemanja Boric via Digitalmars-d
On Tuesday, 13 October 2015 at 06:58:28 UTC, Andrei Alexandrescu 
wrote:
https://github.com/D-Programming-Language/dmd/pull/5188 
implements a rule defined in TDPL: synchronized classes shall 
have no public members.


The motivation behind this limitation is that member accesses 
in synchronized objects should not occur without some handshake 
occurring. Public members would make that possible and easy.


Walter and I are on board with this change. However, it is a 
breaking change so we want to gather a level of community 
support before we push the button.



Thanks,

Andrei


While we're talking about this, what about this:

http://www.digitalmars.com/d/archives/digitalmars/D/Module_access_to_private_members_of_synchronized_classes_228775.html


In the TDPL, on page 419:
"Not so for synchronized classes, which obey the following 
rules:
- Access to private members is restricted to methods of the 
class."


I could rework commits from my experimental branch and submit a 
PR?


Re: Stroustrup is disappointed with D :(

2015-09-23 Thread Nemanja Boric via Digitalmars-d
On Tuesday, 22 September 2015 at 21:28:27 UTC, Ola Fosheim 
Grøstad wrote:


I tried to determine the actual author. It was not easy and I 
still don't know. :)


Me neither. I'm getting the impression that I am looking at a 
wall of guidelines-graffiti.


It was introduced in this commit:

https://github.com/isocpp/CppCoreGuidelines/commit/947cf3affcdfc392a316a32f73cdea7383ae55bd




Re: Vision

2015-08-31 Thread Nemanja Boric via Digitalmars-d

On Monday, 31 August 2015 at 10:47:12 UTC, qznc wrote:

On Monday, 31 August 2015 at 08:31:26 UTC, Joakim wrote:

[...]


Some visions for 2016 I guess:

* D Foundation
* ddmd
* std.allocator (important since various other Phobos additions 
wait for it)

* ARM/mobile support

It is more of a communication issue. There is no official place 
for news (like http://blog.rust-lang.org/). Andrei is kind of 
the spokesperson, but I'm not sure if he even wants to do that?


Maybe a more community based vision process would be an idea? 
For example, have a special session at DConf, where you put 
some Etherpad on the screen and write a vision statement until 
next DConf together. (I have never been able to attend, so no 
idea if this is feasible)


http://forum.dlang.org/thread/majurl$2457$1...@digitalmars.com


Re: Thoughts on replacement languages (Reddit + D)

2015-01-13 Thread Nemanja Boric via Digitalmars-d

It's also on /r/rust

http://www.reddit.com/r/rust/comments/2s7bnt/thoughts_about_rust_from_d_programmer/

On Monday, 12 January 2015 at 19:25:28 UTC, Andrei Alexandrescu 
wrote:

On 1/12/15 11:01 AM, Dicebot wrote:

On Monday, 12 January 2015 at 18:55:49 UTC, John Colvin wrote:

The import example misses that in D you can just do:

import mod1 = my.long.mod1;
import mod2 = my.long.mod2;


I was originally intending to mention how this is possible but 
not
pushed by language/compiler as the standard import approach 
and thus
effectively ignored. But it is the longest part already. Do 
you thing it

is important?


http://www.reddit.com/r/programming/comments/2s70mm/thoughts_about_rust_from_a_d_programmer/

Andrei




Re: Happy new year!

2014-12-31 Thread Nemanja Boric via Digitalmars-d

Срећна Нова Година!

On Wednesday, 31 December 2014 at 17:21:08 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

On 31/12/14 17:51, Iain Buclaw via Digitalmars-d wrote:

On 31 Dec 2014 15:00, "Craig Dillabaugh via Digitalmars-d"
> wrote:

>
> On Wednesday, 31 December 2014 at 14:55:00 UTC, Joseph
Rushton Wakeling wrote:
>>
>> On Wednesday, 31 December 2014 at 14:20:28 UTC, Manu via
Digitalmars-d wrote:
>>>
>>> Here's to an awesome 2015!
>>
>>
>> Blwyddyn Newydd Dda :-)
>
>
> Is that welsh?

That's Cymru to you!


Os treisiodd y gelyn fy ngwlad tan ei droed,
Mae hen iaith y Cymru mor fyw ag erioed ;-)

Look at me, posing like I actually speak it :-P




Re: Lost a new commercial user this week :(

2014-12-18 Thread Nemanja Boric via Digitalmars-d
On Thursday, 18 December 2014 at 09:12:54 UTC, bioinfornatics 
wrote:

Completely, I agree with dicebot.

For a webserver usually is a Linux for many reason not a 
windows.

Guy who want to use a windows as server :
case 1 is a noob
case 2 is a specifics needs



http://meta.stackexchange.com/questions/10369/which-tools-and-technologies-are-used-to-build-the-stack-exchange-network


Re: Do everything in Java…

2014-12-05 Thread Nemanja Boric via Digitalmars-d
The good thing about unit tests is that they tell you when you 
break existing code.


That's the great thing about unittests, and the reason why I 
write unittests. I work on a fairly complex code base and every 
now and then there's a new feature requested. Implementing 
features involves several to dozen of modules to be changed, and 
there's no way that I could guarantee that feature implementation 
didn't change behaviour of the existing code. I both hate and 
love when I `make` compiles and unittest fails.



 But you'll realize that soon enough anyway.


This is not good enough for me. Sometimes "soon enough" means 
week or two before somebody actually notice the bug in the 
implementation (again, very complex project that's simply not 
hand-testable), and that's definitively not soon enough keeping 
in mind amount of $$$ that you wasted into air.




On Friday, 5 December 2014 at 11:53:11 UTC, Chris wrote:

On Friday, 5 December 2014 at 09:27:16 UTC, Paulo  Pinto wrote:
On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright 
wrote:

On 12/4/2014 5:32 PM, ketmar via Digitalmars-d wrote:

http://www.teamten.com/lawrence/writings/java-for-everything.html
i didn't read the article, but i bet that this is just 
another article
about his language of preference and how any other language 
he tried
doesn't have X or Y or Z. and those X, Y and Z are something 
like "not
being on market for long enough", "vendor ACME didn't ported 
ACMElib to
it", "out staff is trained in G but not in M" and so on. 
boring.




From the article:

"Most importantly, the kinds of bugs that people introduce 
most often aren’t the kind of bugs that unit tests catch. 
With few exceptions (such as parsers), unit tests are a waste 
of time."


Not my experience with unittests, repeated over decades and 
with different languages. Unit tests are a huge win, even 
with statically typed languages.


Yes, but they cannot test everything. GUI code is specially 
ugly as it requires UI automation tooling.


They do exist, but only enterprise customers are willing to 
pay for it.


This is why WPF has UI automation built-in.

The biggest problem with unit tests are managers that want to 
see shiny reports, like those produced by tools like Sonar.


Teams than spend ridiculous amount of time writing superfluous 
unit tests just to match milestone targets.


Just because code has tests, doesn't mean the tests are 
testing what they should. But if they reach the magical 
percentage number then everyone is happy.


--
Paulo


Now is the right time to confess. I hardly ever use unit tests 
although it's included (and encouraged) in D. Why? When I write 
new code I "unit test" as I go along, with


debug writefln("result %s", result);

and stuff like this. Stupid? Unprofessional? I don't know. It 
works. I once started to write unit tests only to find out that 
indeed they don't catch bugs, because you only put into unit 
tests what you know (or expect) at a given moment (just like 
the old writefln()). The bugs I, or other people, discover 
later would usually not be caught by unit tests simply because 
you write for your own expectations at a given moment and don't 
realize that there are millions of other ways to go astray. So 
the bugs are usually due to a lack of imagination or a tunnel 
vision at the moment of writing code. This will be reflected in 
the unit tests as well. So why bother? You merely enshrine your 
own restricted and circular logic in "tests". Which reminds me 
of maths when teachers would tell us "And see, it makes perfect 
sense!", yeah, because they laid down the rules themselves in 
the first place.


The same goes for comparing your output to some "gold 
standard". The program claims to have an accuracy of 98%. Sure, 
because you wrote for the gold standard and not for the real 
world where it drastically drops to 70%.


The good thing about unit tests is that they tell you when you 
break existing code. But you'll realize that soon enough anyway.




Re: D Meetup in Berlin

2014-12-05 Thread Nemanja Boric via Digitalmars-d

Another Sociomantic developer here, and I'm in!

Mozilla is also starting organizing weekly hacking sessions for 
Rust in Berlin, so keep in mind that it doesn't need to be 
organized as a Dconf, just people hanging, discussing and coding 
is enough for me to be there!


On Friday, 5 December 2014 at 08:25:07 UTC, Mathias LANG wrote:

On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote:
Let me know if you are interested in taking part in this or 
any future Berlin based events.


I would be interested too.




Re: Comparing Parallelization in HPC with D, Chapel, and Go

2014-11-24 Thread Nemanja Boric via Digitalmars-d

Compilers and interpreters used
Turbo C++ IDE


:-)

On Monday, 24 November 2014 at 11:53:08 UTC, Craig Dillabaugh 
wrote:
On Monday, 24 November 2014 at 03:48:27 UTC, Andrei Amatuni 
wrote:
This prompted me to google for recent academic papers on D, 
which

led me to this:

http://research.ijcaonline.org/volume104/number7/pxc3898921.pdf

not exactly the most rigorous research, but it's pretty
favorable...


My main take away from that paper was that C is much slower 
than Java :o)


Based on those results it likely would have been trounced by 
Python or Ruby too.




Re: Register based error-handling?

2014-11-06 Thread Nemanja Boric via Digitalmars-d


If a function named "write" fails to write, it should throw an 
exception.  So what about functions that want to return error 
codes instead.  What I do is prefix the function with "try".  
You don't have to do that, but it helps me personally keep 
track of what functions require explicit error checking.  A 
function named "tryWrite" lets the user know the function may 
not write and they need to check somehow whether or not it 
failed.




Maybe you could consider something like returning `ResultErr>` (like in Rust) which will make you not forget to check for 
return code.


http://doc.rust-lang.org/std/result/



Re: What IDE/EDITOR do you use for D?

2014-10-30 Thread Nemanja Boric via Digitalmars-d

Nothing fancy - vim with vim-fugitive and NERDtree.