Re: Slice expressions - exact evaluation order, dollar

On 26.06.2016 10:08, Iain Buclaw via Digitalmars-d wrote:
>
>      > Evaluation order should be strictly left-to-right. DMD and GDC
>     get it wrong
>      > here.
>      >
>
>     It is evaluated left-to-right. getBase() -> getLowerBound() ->
>     getUpperBound().
>
>
> Ah, I see what you mean.  I think you may be using an old GDC version.
> Before I used to cache the result of getBase().
>
> Old codegen:
>
> _base = *(getBase());
> _lwr = getLowerBound(_base.length);
> _upr = getUpperBound(_base.length);
> r = {.length=(_upr - _lwr), .ptr=_base.ptr + _lwr * 4};
>
> ---

This seems to be what I'd expect. It's also what CTFE does.
CTFE and run time behaviour should be identical. (So either one of them 
needs to be fixed.)

> Now when creating temporaries of references, the reference is stabilized
> instead.
>
(Continue reading)

kinke via Digitalmars-d | 26 Jun 11:29 2016

Re: Slice expressions - exact evaluation order, dollar

On Sunday, 26 June 2016 at 08:08:58 UTC, Iain Buclaw wrote:
> Now when creating temporaries of references, the reference is 
> stabilized instead.
>
> New codegen:
>
> *(_ptr = getBase());
> _lwr = getLowerBound(_ptr.length);
> _upr = getUpperBound(_ptr.length);
> r = {.length=(_upr - _lwr), .ptr=_ptr.ptr + _lwr * 4};
> ---
>
> I suggest you fix LDC if it doesn't already do this. :-)

Thx for the replies - so my testcase works for GDC already? So 
since what GDC is doing is what I came up for independently for 
LDC (PR #1566), I'd say DMD needs to follow suit.

Cpp/D interface semantic

This is currently part of the dmd test suite [1]:

> extern (C++) interface E
> {
>     int bar(int i, int j, int k);
> }
> 
> extern (C++) int callE(E);
> 
> static assert (callE.mangleof == "_Z5callEP1E");

The last line checks that callE() will pass its argument by 
pointer.

This is fine in the case where E is a D interface because of 
reference semantics: it should be passed by pointer.

But, in the case where an extern(C++) function calls an 
extern(C++) type should it be value semantic - as it is in C++ - 
or reference semantic - as it is in D?

Thoughts?

--
1. 
https://github.com/dlang/dmd/blob/master/test/compilable/cppmangle.d#L102

ted via Digitalmars-d | 26 Jun 09:01 2016

dmd (>2.068) compiler error

Unsure of exactly how to communicate this one, so posting here.

Compilation of https://github.com/dcarp/asynchronous.
Using 'dub --verbose build' produces:
dmd -lib
-of.dub/build/library-debug-linux.posix-x86_64-dmd_2071-7450FEAE5605F646044C35441C27D67E/libasynchronous.a
-debug -g -w -version=CryptoSafe -
version=Have_asynchronous -version=Have_libasync -version=Have_memutils -Isrc/
-I../../../../.dub/packages/libasync-0.7.9/libasync/source/ -
I../../../../.dub/packages/memutils-0.4.6/memutils/source/ src/asynchronous/events.d
src/asynchronous/futures.d src/asynchronous/libasync/events.d 
src/asynchronous/locks.d src/asynchronous/package.d src/asynchronous/protocols.d
src/asynchronous/queues.d src/asynchronous/streams.d 
src/asynchronous/tasks.d src/asynchronous/transports.d src/asynchronous/types.d -vcolumns
Enhanced memory security is enabled.
Memory debugger
enabled
../../../../.dub/packages/libasync-0.7.9/libasync/source/libasync/internals/socket_compat.d(57,16):
Deprecation: module std.c.linux.socket is deprecated - 
Import the appropriate core.sys.posix.* modules instead
Using Linux EPOLL for events

(successful compile) So far, so good.

However, if I do not use dub to compile the code, and compile into individual object files, then for the
following file:

/usr/bin/dmd -ofbuild/events.d.o -debug -g -w -version=CryptoSafe -version=Have_asynchronous
-version=Have_libasync -version=Have_memutils -Isrc    -
I../../../../.dub/packages/memutils-0.4.6/memutils/source/
(Continue reading)

Call to Action: making Phobos <at> safe

Andrei identified a key blocker for D adoption is the incomplete implementation 
of  <at> safe. I'm working on the compiler end. But Phobos has a lot of code that is 
pointlessly not  <at> safe, making it frustrating to write  <at> safe code that calls 
Phobos. Some are listed in Bugzilla, most are not.

So here's what to do:

1. Pick a module, any module, let's say 'std.foo'.

2. Compile it:

     dmd -unittest -main std/foo

and run:

     foo

to verify that the unittests work.

3. Take a look at foo.d and look for a unittest that is not marked  <at> safe.

4. Add  <at> safe to the unittest

5. Do Step 2 on it.

6. If it works, submit a PR with the annotation (well, try to collect a few of 
these in one module)

7. If it doesn't work, find out where the unsafe code is and fix it, and submit 
a PR.
(Continue reading)

Fiber local GC

Pony has a fiber local GC, which means collection can happen when 
the fiber is inactive  or even altogether skip collection if the 
fiber is short-lived.

Go is currently exploring a Transaction Oriented GC addition to 
the concurrent GC it already has:

https://docs.google.com/document/d/1gCsFxXamW8RRvOe5hECz98Ftk-tcRRJcDFANj2VwCB0/edit

It takes the same viewpoint. A go-routine (fiber) that is 
short-lived (like a HTTP request handler) can release everything 
in one swipe without collection.

I think this viewpoint is much more efficient and promising than 
D's thread-local viewpoint.

What D needs is a type qualifier that keeps data "fiber local" 
and possibly a transition mechanism like Pony has for detecting 
objects that should be allocated on a global heap (or less 
efficiently, "pin objects" that are exported outside the fiber).

DbI checked integral

Following the recent discussion about checkedint I found it fit to 
provide more detail on the design I was thinking about. A proof of 
concept is at 
https://gist.github.com/andralex/a0c0ad32704e6ba66e458ac48add4a99. Code 
is alpha quality and only thinly covered by unittests, but should give a 
good idea on how the library works.

The core type is Checked!(int, Hook), where Hook is a type that may 
provide state and behavior. The behavior of interest is incarnated by 
the following methods (all of which are optional and introspected): 
hookOpCast, onBadCast, hookOpEquals, onBadOpEquals, hookOpCmp, 
onBadOpCmp, hookOpUnary, hookOpBinary, and onOverflow.

By default, if Hook has no state and implements none of these methods, 
e.g. is void, then Checked!(int, void) is a user-defined type that 
mimics the behavior of int to the maximum extent possible.

Hooks may be interested in handling bad results (such as overflow, 
division by zero, wrong casts etc) with the onXxx methods. See e.g. 
Croak, which simply aborts the program with assert(0) upon any bad 
result. Alternatively, hooks may define hookXxx methods that customize 
dangerous operations in any way they want, including defining 
alternative typing rules (e.g. arrange that int * int yields long).

With Checked, user code may use some predefined hooks (only Croak 
provided for now), or define others specific to the application. Hooks 
may store state that is publicly accessible.

The next step is to implement more hooks to make sure the introspection 
API is expressive enough for a battery of desired behaviors (exceptions, 
(Continue reading)

Re: [OT] ...

On 24.06.2016 08:49, H. S. Teoh via Digitalmars-d wrote:
> ...How do you define "number of functions" when m and n are
> non-integer?
> ...

I don't. But even when n is an arbitrary real number, I still want empty 
products to be 1.

> ...
>
>> Have a look at this plot: http://www.wolframalpha.com/input/?i=x%5E-y
>> Can you even spot the discontinuity? (I can't.)
>
> That's because your graph is of the function x^(-y), which is a
> completely different beast from the function x^y.

It's a mirror image.

> If you look at the
> graph of the latter,

Then the point (0,0) is hidden.

> you can see how the manifold curves around x=0 in
> such a way that the curvature becomes extreme around (0,0), a sign of an
> inherent discontinuity.
> ...

Well, there's no question that the discontinuity is there. It's just 
that, if you want to expose the discontinuity by taking limits along 
(Continue reading)

Should % ever "overflow"?

In a checked environment, division may "overflow", e.g. -6 / 2u must be 
typed as uint but is not representable properly one.

How about remainder? I suppose one can make the argument that remainder 
should never overflow (save for rhs == 0), because it could be defined 
with either a positive or negative denominator (which is not part of the 
result).

What's the most reasonable behavior?

Andrei

When using the -profile flag is it known behaviour that phobos unit tests fail?

When using the -profile flag is it known behaviour that phobos 
unit tests fail?

(Ubuntu 16.04 - DMD64 D Compiler v2.071.0)

For example, when following these steps I get a failed unit test:

$ cd /usr/include/dmd/phobos/std/
$ rdmd -I/usr/include/dmd/phobos/std 
-I/usr/include/dmd/phobos/core -main -unittest -profile format.d

Without the -profile flag it works.

A comparison between Rust and D

https://maikklein.github.io/post/cmp-rust-d/

https://www.reddit.com/r/programming/comments/4po2j5/a_comparison_between_rust_and_d/


Gmane