Re: scope(~this)

[thedeemon via Digitalmars-d-learn]

On Monday, 13 March 2017 at 14:28:01 UTC, Inquie wrote:

On Monday, 13 March 2017 at 05:18:18 UTC, Nicholas Wilson wrote:

On Sunday, 12 March 2017 at 21:38:44 UTC, Inquie wrote:
Is there any easy way to create a scope for termination of 
the object?


I have a template method that takes a type and allocates and 
deallocates based on that type.


class bar
{
   void foo(T)()
   {
  T x;
  alloc(x);
  scope(~this) dealloc(x); // hypothetical that wraps the 
statement in a lambda and deallocates in the destructor


  ... x must stay allocated until class instance 
termination(has to do with COM, can't release it in foo)

   }

}



I think the feature you're asking for is too complicated/involved 
for a language feature. Because it means there must be some 
implicit array in each object of your 'bar' class that holds some 
number of closures that will be executed in destructor. This 
affects object's memory layout and raises questions of allocating 
memory for those closures and since those closures will have 
pointers to some data (like 'x' here) it affects garbage 
collection. So there are a lot of things to be careful about and 
things that might affect other language features we haven't 
thought about yet. This is something quite big and something that 
affects a lot of code, not just a couple of classes you'll write 
in your one app. Probably it would be better to implement it as a 
library feature. Just make a base class having a method for 
registering such closures and calling them in destructor, and 
inherit from it or just embed it in your 'bar'.

Re: Phobos function to check if files are identical?

[XavierAP via Digitalmars-d-learn]

On Monday, 13 March 2017 at 17:47:09 UTC, H. S. Teoh wrote:


Binary comparison is easy. Just read the files by fixed-sized 
chunks and compare them.


Follow up question... What is the best @safe way? Since 
File.byChunk() is @system. Just out of curiosity, I would rather 
use it and flag my code @trusted, although I guess there could be 
concurrency issues I have to take into account anyway... anything 
else?

Re: code folding

[XavierAP via Digitalmars-d-learn]

On Tuesday, 14 March 2017 at 00:38:12 UTC, Vladimir Panteleev 
wrote:


If you have enough declarations in one file that they call for 
code folding, it may be better to move them to a separate 
module. Public imports and aliases allow doing this without 
breaking any code.


[...]

Generally speaking, I would recommend to simply avoid code 
folding altogether:


https://blog.codinghorror.com/the-problem-with-code-folding/


Indeed good point:
http://stackoverflow.com/questions/475675/when-is-a-function-too-long

Re: Null-Safe Dereference Operator

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

On Tuesday, 14 March 2017 at 01:08:50 UTC, Jonathan M Davis wrote:
It does not, though if you really wanted to, you could probably 
create template that did the same thing fairly easily.


I recently added something similar to dom.d, since I wanted to 
pull a header if present, and was ok with a null string if there 
wasn't one.


I used to write:

string header;
if(auto e = document.querySelector("h1"))
   header = e.innerText;

but now i can write:

string header = document.optionSelector("h1").innerText;

http://dpldocs.info/experimental-docs/arsd.dom.Element.optionSelector.html


Since the selector syntax is already a DSL for descending into 
the tree, you don't typically need to chain it far, but the 
optionSelector magic allows it anyway:


// all of this becomes null-safe dereferencing...
document.optionSelector("h1").firstChild.nextSibling.innerText



The return value is a new type:

http://dpldocs.info/experimental-docs/arsd.dom.MaybeNullElement.html

That uses opDispatch and type checking to wrap. Here is the 
complete source code, that you might be able to adapt to your 
object too, or make it REALLY generic and use it anywhere:


---
struct MaybeNullElement(SomeElementType) {

this(SomeElementType ele) {

this.element = ele;

}

SomeElementType element;


	/// Forwards to the element, wit a null check inserted that 
propagates null.

auto opDispatch(string method, T...)(T args) {
alias type = typeof(__traits(getMember, element, method)(args));
static if(is(type : Element)) {
if(element is null)
return MaybeNullElement!type(null);
return __traits(getMember, element, method)(args);
} else static if(is(type == string)) {
if(element is null)
return cast(string) null;
return __traits(getMember, element, method)(args);
} else static if(is(type == void)) {
if(element is null)
return;
__traits(getMember, element, method)(args);
} else {
static assert(0);
}
}

/// Allows implicit casting to the wrapped element.
alias element this;
}
---




Now, the C# thing is cool because you can use it with any object, 
but in my experience, I don't *need* it with most objects. I 
found I mostly want it with XML and JSON, so I just adapted those 
two specific classes to allow something like the above and now 
get a decent amount of mileage out of it without needing the 
general-purpose operator.


You can templatize that MaybeNull thing to work on arbitrary 
objects too, then write like 
`NullSafe(obj).chain.as.much.as.you.want` if you like, but 
another benefit of me finding I mostly wanted it on just those 
two things is I made a shortcut method: document.optionSelector 
rather than `nullSafe(document.querySelector)` or whatever.


You could also make some kind of UFCS null safe chainer:

obj.ns.foo.ns.bar

where there is a NullSafe!T ns(T obj) {} that returns a null-safe 
wrapper; a user-defined function taking the place of the language 
operator.




So, no, D doesn't have the C# thing, but there are a few other 
options you can explore to do something similar.

[Issue 14893] std.concurrency: can't send shared arrays or shared structs

[via Digitalmars-d-bugs]

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

tasuke...@gmail.com changed:

   What|Removed |Added

 CC||tasuke...@gmail.com

--

Re: Declaring interfaces with a constructor

[evilrat via Digitalmars-d-learn]

On Monday, 13 March 2017 at 19:31:52 UTC, David  Zhang wrote:


Basically, I want to define a common interface for a group of 
platform-specific classes, except that they should ideally also 
share constructor parameters. What I want to do is then alias 
them to a common name, selecting the implementation for the 
target platform at compile time.


like this?
--
import std.stdio;

abstract class PublicInterface
{
this(int, int) {} // must have body, see below
}

version(broken) {
 alias ActualImpl = NotCompile;
}
else {
 alias ActualImpl = PlatformSpecificClass;
}

// put behind version too, this just for demonstration
class PlatformSpecificClass : PublicInterface
{
this(int a, int b)
{
super(a,b); // yeah, downside of this approach
writeln(a,b);
}
}

version(broken) {
 class NotCompile : PublicInterface
 {
  // no interface ctor
 }
}

void main()
{
new ActualImpl(1,2);
}
-

there is also way to do this using templates and duck typing, I 
think it will be more idiomatic way since ranges and stuff 
heavily use it to provide such generalism, though just like you 
say, I would prefer to have strict interface for such use case...

Re: Can i using D & LLVM & SDL2 for Android?

[rikki cattermole via Digitalmars-d-learn]

On 14/03/2017 6:08 AM, Joakim wrote:

On Monday, 13 March 2017 at 09:33:39 UTC, rikki cattermole wrote:

On 13/03/2017 7:48 PM, Joakim wrote:

[...]


Why exactly doesn't the Android port support dlopen, dlsym and dlclose?
It is provided by the NDK libc.

At least according to this[0].

[0] https://developer.android.com/ndk/guides/stable_apis.html


I was more talking about D shared libraries, which I'm assuming
DerelictSDL2 qualifies as and would require Phobos built as a shared
library.  That hasn't been tried yet on Android.


DerelictSDL2 would be statically linked, it would dynamically bind via 
dlopen, dlsym and dlclose to SDL itself which would be compiled as a 
shared library.


This is how Derelict based libraries work.

Re: Null-Safe Dereference Operator

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, March 14, 2017 00:51:02 Jolly James via Digitalmars-d-learn 
wrote:
> Does anybody know, if D has a null-safe dereference operator like
> C# does (?.) or something similar?

It does not, though if you really wanted to, you could probably create
template that did the same thing fairly easily.

- Jonathan M Davis

[Issue 10226] core.simd inefficient codegen

[via Digitalmars-d-bugs]

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

--- Comment #12 from Martin Nowak  ---
The cause for the example in comment 11 seems to be the void16 parameters of
__simd_sto which breaks the

  (tyfloating(em->Ety) != 0) == (tyfloating(e->Ety) != 0)

condition in localizer.

https://github.com/dlang/dmd/blob/0089ae06db7c7b4bebe4d11bfcf02eab69936d81/src/ddmd/backend/glocal.c#L344


The assignment of value

{
(__vector(float[4])* p = [0];) , ((__vector(float[4]) value = b - c;));
__simd_sto(cast(XMM)3857, cast(__vector(void[16]))*p,
cast(__vector(void[16]))value);
}

is optimized to this el

el:0x9003b0 cnt=0 cs=0 *  TYsigned char[16] 0x900350
 el:0x900350 cnt=0 cs=0 var  TY*  __a_8
el:0x8ffc94 cnt=0 cs=0 -  TYsigned char[16] 0x8ffbd4 0x8ffc34
 el:0x8ffbd4 cnt=0 cs=0 var  TYfloat[4]  b
 el:0x8ffc34 cnt=0 cs=0 var  TYfloat[4]  c

which assigns a float[4] vector to a byte[16] vector.

--

Re: code folding

[Vladimir Panteleev via Digitalmars-d-learn]

On Monday, 13 March 2017 at 21:33:56 UTC, Inquie wrote:
One can say that it is a useless feature because D doesn't have 
it... or one could say that D is useless because it doesn't 
have it. A nice balance is simply to say "It is a useful 
feature that has proven it's worth and it is time that D 
implements something like it". As D becomes more mainstream, 
these features will be requested. D should learn from other 
language/compilers just as other languages/compilers have 
learned from it. (it's a two a way street)


FYI: The "you must implement my feature request or D will never 
succeed" attitude is rather common and never helpful. Not to 
mention that such an argument would be demonstrably false: every 
popular language without the feature you want has apparently 
succeeded despite not having said feature.


When one had a shit load of types in a single file, it is nice 
to be able to fold them. It is also nice to be able to group 
them in some way(hence the question) and fold the group so that 
large chunks of the file can be visibly reduced.


If you have enough declarations in one file that they call for 
code folding, it may be better to move them to a separate module. 
Public imports and aliases allow doing this without breaking any 
code.


If you would like a way to achieve code folding without involving 
language constructs, I think the starting point would be your 
IDE/editor's D plugin vendor. Once implemented in one editor, the 
syntax could be implemented in others and be informally 
standardized.


I don't think that it would make sense to introduce it into the 
language syntax proper. The #region syntax in C# makes sense for 
C# because, as already mentioned, the language vendor is also the 
main IDE vendor; but also because C#, like Java, requires a lot 
more boilerplate - writing programs in C# is much more tedious 
without an IDE than with. This is not the case of D, which was 
designed to solve problems that would otherwise require 
boilerplate code in the language itself.


Generally speaking, I would recommend to simply avoid code 
folding altogether:


https://blog.codinghorror.com/the-problem-with-code-folding/

Re: code folding

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, March 13, 2017 19:51:59 Inquie via Digitalmars-d-learn wrote:
> On Monday, 13 March 2017 at 18:26:22 UTC, Jonathan M Davis wrote:
> > On Monday, March 13, 2017 17:29:41 Inquie via
> >
> > Digitalmars-d-learn wrote:
> >> Does D have any nice way to specify a block for cold folding?
> >> I have a very large set of structs and I'd like to be able to
> >> code fold them all at once and together.
> >>
> >> I have been using
> >>
> >> static if(true)
> >> {
> >>
> >>  ... junk
> >>
> >> }
> >>
> >> but the static if is uninformative since that is the only line
> >> that is shown when folded. A comment helps but still kinda
> >> ugly.
> >>
> >> C# has #regions and hopefully D has something as useful.
> >
> > Code-folding is an IDE thing, not a language thing. So, it's
> > not the sort of thing that would normally be built into a
> > language. If Microsoft did it with C#, it's only because they
> > assumed that everyone would use Visual Studio, but I would
> > guess that #region actually does more than just enable code
> > folding. However, since I've done relatively little with C#, I
> > don't know.
> >
> > So, how code folding works is going to depend entirely on
> > whatever IDE or code editor you're using. If you told us which
> > IDE you were using, maybe someone here could give you some
> > tips, but it's going to be specific to your IDE. Normally, I
> > think that folks just code fold based on braces if they're
> > doing fode folding, but I don't know. I've certainly never
> > heard of anyone adding anything to a source file just to enable
> > code folding.
> >
> > - Jonathan M Davis
>
> This is wrong. It is a language feature.

I mean that the code folding itself is not a language feature. It's
something that the IDE does. The compiler doesn't care one whit about code
folding. If #region in C# is there to tell the IDE that the programmer wants
that to be foldable, and that's all it does, then the language has a feature
to help inform IDEs about how the program wants the code to be foldable.
It's still not the language or compiler that does the code folding.

And as I said, if C# has something like this, it's because Microsoft assumed
that you were going to be using Visual Studio, which they control. Languages
don't normally have any features that have anything to do with code editors,
because they don't normally assume anything about the editor that you're
using. C++ doesn't have anything like it (though it looks like Microsoft
added a non-standard extension for it). Neither does Java, python, ruby,
javascript, or PHP - just to name a few. There may be _some_ other language
out there that does, but it's simply not the sort of thing that most
languages do, because they're not usually written with specific editors in
mind. Microsoft with C# is the oddball here, because they control both the
language and the primary editor.

- Jonathan M Davis

Re: Recursive template instantiation

[ag0aep6g via Digitalmars-d-learn]

On 03/13/2017 11:58 PM, Stefan Koch wrote:

On Monday, 13 March 2017 at 22:05:24 UTC, Jack Applegame wrote:

Is this a bug?


No it's not

struct C
{
  B!C;
}
is an error.

Howto compute C ?   <--\
let's check the members;   |
The member needs a template.   |
Howto compute the template ?   |
let's compute the parameters.  |
What is the first Parameter ?  |
Its C. |
Howoto compute C---/


I don't think that's it.

Here's a variant where B is not instantiated with C:


struct A()
{
~this() { enum s = C.sizeof; }
}

struct B() { A!() foo; }
struct C { B!() bar; }


How to compute C?
Check members.
For member `B!() bar;`, resolve `B!()`.
Check members of `B!()`.
For member `A!() foo;` resolve `A!()`.
Check members of `A!()`.
No members => size = 0 (or rather 1, I guess).
Bubble up.

But the compiler seems to get confused by the destructor. I guess it 
incorrectly(?) sees a need to analyze C again before it can finish up 
`A!()`?

Re: Recursive template instantiation

[ag0aep6g via Digitalmars-d-learn]

On 03/14/2017 12:02 AM, Stefan Koch wrote:

On Monday, 13 March 2017 at 22:59:36 UTC, ag0aep6g wrote:

[...]


struct A(T) {
void m() {
char[T.sizeof] data;
}
}
/* ... rest as above ... */


I don't see how the destructor makes a difference. Soo, bug?


Try to use m.


Works no problem?


struct A(T) {
void m() {
char[T.sizeof] data;
import std.stdio;
writeln(T.sizeof);
}
}

struct B(T) {
A!T foo;
}

struct C {
B!C bar;
}

void main() {
C c;
c.bar.foo.m();
}


Prints "1".

Re: Recursive template instantiation

[Stefan Koch via Digitalmars-d-learn]

On Monday, 13 March 2017 at 22:59:36 UTC, ag0aep6g wrote:

On 03/13/2017 03:26 PM, Jack Applegame wrote:

I'm pretty sure that this code should compile
(https://dpaste.dzfl.pl/cf1e1ee6ef4b):

struct A(T) {
~this() {
char[T.sizeof] data;
}
}

struct B(T) {
A!T foo;
}

struct C {
B!C bar;
}

void main() {
C c;
}

But it doesn't:
/d300/f416.d(3): Error: struct f416.C no size because of 
forward
reference /d300/f416.d(12): Error: template instance 
f416.B!(C) error

instantiating


It compiles when it's a normal method instead of a destructor:


struct A(T) {
void m() {
char[T.sizeof] data;
}
}
/* ... rest as above ... */


I don't see how the destructor makes a difference. Soo, bug?


Try to use m.

Re: ranges of characters and the overabundance of traits that go with them

[Jonathan M Davis via Digitalmars-d]

On Monday, March 13, 2017 23:40:55 Dmitry Olshansky via Digitalmars-d wrote:
> On 3/13/17 8:08 PM, H. S. Teoh via Digitalmars-d wrote:
> > Ugh.  What a horrible mess!
> >
> > I think, instead of wading through the specifics and losing sight of the
> > forest for the myriad trees, we should take a step back and consider the
> > big picture.
>
> [snip excellent answer]
>
> This is IMHO the right way forward. We (Phobos maintainers) created the
> mess, now it's time to cleanup but not at the expense of the user.
> All the isSomeString, isSomeOtherString can just be a reminiscent of the
> old days that is internal to the implementation.

That makes sense for the APIs of public-facing functions. However, at least
some portion of programmers who are not writing Phobos functions are going
to need to use all of those same traits to write their own code. In most
cases, we can clean up the APIs so that they hide the specializations, but
anyone who needs to write specializations in their own code will need the
same traits that Phobos uses. So, we can reduce the complications and
negative impact that come from having to deal with all of these traits in
generic code, but we can't actually eliminate it. Best case, the folks that
aren't going to bother writing any generic code of their own don't have to
worry about it, but anyone writing their own generic code - especially if it
involves ranges of characters - is still stuck with the problem in their own
code. So, we really can't make the various traits internal - at least not
without basically saying that everyone needs to rewrite them in their own
code, which is just going to create a different set of problems.

Overall though, I completely agree that we should move towards simplifying
the template constraints on the public-facing APIs so that the code that
doesn't need to use all of the various traits in its public API doesn't.

- Jonathan M Davis

Re: Recursive template instantiation

[ag0aep6g via Digitalmars-d-learn]

On 03/13/2017 03:26 PM, Jack Applegame wrote:

I'm pretty sure that this code should compile
(https://dpaste.dzfl.pl/cf1e1ee6ef4b):

struct A(T) {
~this() {
char[T.sizeof] data;
}
}

struct B(T) {
A!T foo;
}

struct C {
B!C bar;
}

void main() {
C c;
}

But it doesn't:
/d300/f416.d(3): Error: struct f416.C no size because of forward
reference /d300/f416.d(12): Error: template instance f416.B!(C) error
instantiating


It compiles when it's a normal method instead of a destructor:


struct A(T) {
void m() {
char[T.sizeof] data;
}
}
/* ... rest as above ... */


I don't see how the destructor makes a difference. Soo, bug?

Re: ranges of characters and the overabundance of traits that go with them

[Jonathan M Davis via Digitalmars-d]

On Monday, March 13, 2017 12:08:12 H. S. Teoh via Digitalmars-d wrote:
> 2) The /* user-readable constraints */  ought to be one of a small
> number of self-describing templates that tell the user exactly what the
> *intent* of the function is (note, *intent*, as in, implementation
> limitations should not be a factor).
>
> The current mess of isSomeString, isConvertibleToString, isNarrowString,
> etc., really should be internal to Phobos, and should not be exposed to
> the user at all. At the most, I'd say just ONE template that works for
> all strings and string-like ranges (and whatever else we wish to
> include) ought to be exposed to the user.  What should be done within
> Phobos itself (in private std.* space) is another matter -- we do need
> to handle the dirty details like auto-decoding, narrow strings, etc.,
> here. But the point is that this should be *internal* to Phobos, not
> exposed to the user like dirty laundry.

Simplifying public-facing template constraints makes a lot of sense.
However, that doesn't mean that all of the various traits should be private
or hidden within Phobos - just that the public functions themselves should
make their template constraints as general as possible. Remember that
there's nothing special about what Phobos is doing. It's just that it
happens to be the standard library, so it's used by a lot of folks. The rest
of the D ecosystem has all of these same concerns, and so even if 3rd party
libraries and programs also make their public-facing template constraints as
simple as possible, they're still going to need to use all of these traits
internally in the same way that Phobos does. These complexities can be
hidden on some level at the API level, but anyone writing APIs or writing
code that uses APIs but needs to do stuff that the APIs don't do for them is
still going to have to worry about these complexities.

> For the rest of the cases, my question is, is there any reason to *not*
> accept any arbitrary range of characters?

I'm not convinced that it never makes sense to have a function just operates
on arrays and not ranges. Certainly, lots of programs will be written that
way, because it takes more effort to make something work with generic ranges
than it does to work with arrays, and the extra effort often isn't worth it
if you're not creating a library to distribute to other programmers.

For the most part, something like Phobos should be using ranges, not just
arrays, but they're still a real thing for the D ecosystem at large -
especially if the code is mixing range behavior with appending. In
particular, that's not an uncommon thing to do in string code. So, while I
do think that we should be very wary of adding code to Phobos that operates
on arrays and not ranges, we should also remember that that's not always the
best way to do things in actual programs that are written to do a specific
thing - potentially on a tight schedule - rather than being generic and put
out in the wild for everyone to use.

> 4) Implicit conversions:  this is a tricky one, esp. once you factor in
> alias this.  Am I right to assume that this is mostly coming from
> functions that used to take strings explicitly, but later were
> templatized, thus losing some of the original implicit conversions?  If
> so, I'm inclined to do this:
>
>   auto myFunc(R)(R r)
>   /* N.B. no sig constraints */
>   {
>   static if (isConvertibleTo!(R,x))
>   ...
>   ... /* handle dirty laundry cases internally here */
>   }
>
> then document in the ddocs exactly what is expected of the incoming
> type. I.e., accept everything, then sort out the different cases
> internall as an implementation detail.

As I pointed on in my original post (though with how large it is, it
probably isn't hard to forget), this doesn't actually work properly with
implicit conversions - at least not in the general case. In particular, if
you have a function that takes a string or takes an array and is templated
on character type, it will currently accept static arrays, enums, and
user-defined types that implicitly convert to string. For static arrays, and
user-defined types that convert to strings in a similar manner to static
arrays (i.e. they're returning a slice of memory that will not be valid when
the object being converted goes out of scope), you have a safety problem if
do the implicit conversion inside the function. It needs to happen at the
call site, and that means _not_ doing something like

auto foo(T)(T t)
if(isConvertibleToString!T)
{...}

- at least not in the general case. The problem is when any portion of the
original range is returned from the function. For instance, with this
ridiculously simple example

auto foo(inout(char)[] str)
{
return str;
}

char[10] sa;
auto bar = foo(sa);

you have no safety problem so long as no slice of bar is returned from the
function that it's in. However, if you templatize foo

auto foo(R)(R range)
if(isForwardRange!R && 

Re: ranges of characters and the overabundance of traits that go with them

[Dmitry Olshansky via Digitalmars-d]

On 3/13/17 8:08 PM, H. S. Teoh via Digitalmars-d wrote:

Ugh.  What a horrible mess!

I think, instead of wading through the specifics and losing sight of the
forest for the myriad trees, we should take a step back and consider the
big picture.


[snip excellent answer]

This is IMHO the right way forward. We (Phobos maintainers) created the 
mess, now it's time to cleanup but not at the expense of the user.
All the isSomeString, isSomeOtherString can just be a reminiscent of the 
old days that is internal to the implementation.


---
Dmitry Olshansky

Re: Visual D 0.44 released - VC project integration and Concord debugger extension

[Rainer Schuetze via Digitalmars-d-announce]

On 13.03.2017 18:56, Inquie wrote:

On Monday, 13 March 2017 at 08:12:41 UTC, Rainer Schuetze wrote:



On 12.03.2017 13:09, Rainer Schuetze wrote:

I'm glad to finally announce the release of a new version of Visual D,
the Visual Studio extension for the D programming language.


Unfortunately, a bug turned up, causing the default dmd executable
search path to contain a bad character.

Here's a new version:
https://github.com/dlang/visuald/releases/tag/v0.44.1


Small complaint here. Can the installer remember the previous install
dir? I get tired of typing it in every time. It remembers the dmd dir
just find(the next page).

I know it's not that big a deal ;) But would make the installer
virtually silent rather than requiring input.



As long as you don't uninstall Visual D, the path should be remembered. 
I usually just install over the previous version without uninstalling 
(no guarantee that this will work in the future, though).

Re: Recursive template instantiation

[Jack Applegame via Digitalmars-d-learn]

Is this a bug?

Re: code folding

[bachmeier via Digitalmars-d-learn]

On Monday, 13 March 2017 at 19:51:59 UTC, Inquie wrote:


This is wrong. It is a language feature.

#region lets you specify a block of code that you can expand or 
collapse when using the outlining feature of the Visual Studio 
Code Editor. In longer code files, it is convenient to be able 
to collapse or hide one or more regions so that you can focus 
on the part of the file that you are currently working on. The 
following example shows how to define a region:


Obviously it is useful for the IDE, but if it was not a 
language feature then the code would not compile(as it's not a 
comment).


From my understanding of the feature, it does the same as

// region

... code to be folded ...

// endregion

An IDE can then read those comments and allow code folding. It 
might meet some definition of a language feature, but it is 
nothing more than a comment.


I use visual studio and if it was an IDE feature then I could 
insert #regions in it and it would compile. This would, of 
course, break anyone else code that doesn't use an IDE that 
supports it... hence it has to be a language feature(or some 
type of meta comment thing, which it is not in this case).


I don't understand how it would break your code.

Re: code folding

[Inquie via Digitalmars-d-learn]

On Monday, 13 March 2017 at 21:17:31 UTC, XavierAP wrote:

On Monday, 13 March 2017 at 17:29:41 UTC, Inquie wrote:


I have been using

static if(true)
{
... junk
}


Indeed #region is part of the C# specification, even if it has 
no effect on the code. (The specification does not say anything 
about folding/collapsing, just about "marking sections of 
code", although I guess most IDEs supporting it will follow the 
example of MS's reference implementation.)


Short answer, D does not have this, as far as I know.

I don't really think it's good substitute practice to insert 
meaningless static if(true)... Even if you're really used to 
that feature, and even if you're right that it does the job and 
doesn't change the generated code.


Unfortunately you can't get this folding easily (I'm sure some 
Vim wizard would come up with something). Instead if you want 
to mark regions of code, that's what comments are for. You 
can't get the folding you want unfortunately (outside of 
naturally existing bracket pairs) but you can use your editor 
to search forward and backward in the file for whatever text, 
e.g.


//region: foo//



That's not the point. The point is that the IDE I use(VS, which 
is the most common IDE on windows), requires an actual block to 
fold. Folding is useful so it is not an irrelevant issue. Even 
notepad++ can fold blocks if it can determine what a block, so 
this isn't an "IDE" specific thing nor an "IDE" specific feature.


When one had a shit load of types in a single file, it is nice to 
be able to fold them. It is also nice to be able to group them in 
some way(hence the question) and fold the group so that large 
chunks of the file can be visibly reduced.


One can say that it is a useless feature because D doesn't have 
it... or one could say that D is useless because it doesn't have 
it. A nice balance is simply to say "It is a useful feature that 
has proven it's worth and it is time that D implements something 
like it". As D becomes more mainstream, these features will be 
requested. D should learn from other language/compilers just as 
other languages/compilers have learned from it. (it's a two a way 
street)


If D supported such simple stuff hacks would not be required to 
do the simple things.

Re: Phobos function to check if files are identical?

[XavierAP via Digitalmars-d-learn]

On Monday, 13 March 2017 at 17:47:09 UTC, H. S. Teoh wrote:


Why it is not easy to do by hand?


Sorry typo, I had intended to type "I know it is easy"

Re: code folding

[XavierAP via Digitalmars-d-learn]

On Monday, 13 March 2017 at 17:29:41 UTC, Inquie wrote:


I have been using

static if(true)
{
... junk
}


Indeed #region is part of the C# specification, even if it has no 
effect on the code. (The specification does not say anything 
about folding/collapsing, just about "marking sections of code", 
although I guess most IDEs supporting it will follow the example 
of MS's reference implementation.)


Short answer, D does not have this, as far as I know.

I don't really think it's good substitute practice to insert 
meaningless static if(true)... Even if you're really used to that 
feature, and even if you're right that it does the job and 
doesn't change the generated code.


Unfortunately you can't get this folding easily (I'm sure some 
Vim wizard would come up with something). Instead if you want to 
mark regions of code, that's what comments are for. You can't get 
the folding you want unfortunately (outside of naturally existing 
bracket pairs) but you can use your editor to search forward and 
backward in the file for whatever text, e.g.


//region: foo//

[Issue 8573] A simpler Phobos function that returns the index of the mix or max item

[via Digitalmars-d-bugs]

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

Jakub Łabaj  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||uaaabbj...@gmail.com
 Resolution|--- |FIXED

--- Comment #6 from Jakub Łabaj  ---
Implemented as stated in comments.

--

Re: code folding

[Inquie via Digitalmars-d-learn]

On Monday, 13 March 2017 at 18:26:22 UTC, Jonathan M Davis wrote:
On Monday, March 13, 2017 17:29:41 Inquie via 
Digitalmars-d-learn wrote:
Does D have any nice way to specify a block for cold folding? 
I have a very large set of structs and I'd like to be able to 
code fold them all at once and together.


I have been using

static if(true)
{
 ... junk
}

but the static if is uninformative since that is the only line 
that is shown when folded. A comment helps but still kinda 
ugly.


C# has #regions and hopefully D has something as useful.


Code-folding is an IDE thing, not a language thing. So, it's 
not the sort of thing that would normally be built into a 
language. If Microsoft did it with C#, it's only because they 
assumed that everyone would use Visual Studio, but I would 
guess that #region actually does more than just enable code 
folding. However, since I've done relatively little with C#, I 
don't know.


So, how code folding works is going to depend entirely on 
whatever IDE or code editor you're using. If you told us which 
IDE you were using, maybe someone here could give you some 
tips, but it's going to be specific to your IDE. Normally, I 
think that folks just code fold based on braces if they're 
doing fode folding, but I don't know. I've certainly never 
heard of anyone adding anything to a source file just to enable 
code folding.


- Jonathan M Davis


This is wrong. It is a language feature.

#region lets you specify a block of code that you can expand or 
collapse when using the outlining feature of the Visual Studio 
Code Editor. In longer code files, it is convenient to be able to 
collapse or hide one or more regions so that you can focus on the 
part of the file that you are currently working on. The following 
example shows how to define a region:


Obviously it is useful for the IDE, but if it was not a language 
feature then the code would not compile(as it's not a comment).


I use visual studio and if it was an IDE feature then I could 
insert #regions in it and it would compile. This would, of 
course, break anyone else code that doesn't use an IDE that 
supports it... hence it has to be a language feature(or some type 
of meta comment thing, which it is not in this case).


Just because you have never heard of it doesn't mean much... it 
is anecdotal... before the year 0BC no one ever heard of 
computers... or antibiotics, or spacecraft, or transistors, or 
just about anything we have to day.

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:

[ ... ]


I just fixed a bug in ref support;
It should now work with slices.

I also made it _slightly_ easier to make ABI changes for slice, 
since I expect the structure to change as soon as concat support 
is added.

(e.g. slices will get a refcount, capacity and an origin ptr)

[Issue 10226] core.simd inefficient codegen

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #11 from Martin Nowak  ---
cat > bug.d << CODE
import core.simd;

alias vec = __vector(double[2]);

void storeUnaligned(ref vec a, in ref vec val)
{
__simd_sto(XMM.STOUPD, a, val);
}

void test(ref vec a, in vec b)
{
__simd_sto(XMM.STOUPD, a, b * b); // works
immutable tmp = b * b;
__simd_sto(XMM.STOUPD, a, tmp); // dips stack
storeUnaligned(a, tmp); // dips stack
}
CODE
dmd -c -O -release -inline bug

mulpd   xmm1, xmm3  ; 000C _ 66: 0F 59. CB
movapd  xmmword ptr [rsp], xmm1 ; 0010 _ 66: 0F 29. 0C
24
movdqa  xmm2, xmmword ptr [rsp] ; 0015 _ 66: 0F 6F. 14
24
movupd  xmmword ptr [rdi], xmm2 ; 001A _ 66: 0F 11. 17

Turns out that dmd's codegen is almost prohibitively inefficient, the
intermediate value unnecessarily get pushed to the stack.

--

Re: Phobos function to check if files are identical?

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

On Mon, Mar 13, 2017 at 10:47:09AM -0700, H. S. Teoh via Digitalmars-d-learn 
wrote:
[...]
> P.S. I just realized that std.stdio.chunks() doesn't return a range.
> Bah. File an enhancement request. I might even submit a PR for it. ;-)
[...]
> P.P.S.  It's not overly hard to write an alternative version of
> std.stdio.chunks that returns a real range.
[...]

Bah, I'm an idiot.  Just use File.byChunk instead of .chunks. Here's a
fully-working example:

import std.stdio;

bool equal(File f1, File f2)
{
import std.algorithm.comparison : equal;
enum bufSize = 4096;
return f1.byChunk(bufSize).equal(f2.byChunk(bufSize));
}

int main(string[] args) {
if (args.length < 3)
{
stderr.writeln("Please specify filenames");
return 1;
}

if (equal(File(args[1]), File(args[2])))
writeln("Files are identical.");
else
writeln("Files differ.");
return 0;
}


T

-- 
INTEL = Only half of "intelligence".

[OT] LLVM 4.0 released - LDC mentioned in release notes

[Kai Nacke via Digitalmars-d-announce]

Hi all!

LLVM 4.0 has been released! See the release notes here: 
http://releases.llvm.org/4.0.0/docs/ReleaseNotes.html

Downloads: http://releases.llvm.org/download.html#4.0.0

As usual LDC is mentioned in the release notes, too: 
http://releases.llvm.org/4.0.0/docs/ReleaseNotes.html#ldc-the-llvm-based-d-compiler

IMHO this is good advertisement for D & LDC.

Regards,
Kai

Re: Declaring interfaces with a constructor

[David Zhang via Digitalmars-d-learn]

On Monday, 13 March 2017 at 17:52:09 UTC, XavierAP wrote:

On Monday, 13 March 2017 at 02:15:21 UTC, David  Zhang wrote:
What it says on the tin. Is there a way to create interfaces 
with a constructor or must I use an abstract class.


What do you want to do in your constructor? I can't think of 
anything that wouldn't change some state, either of the class 
(but interfaces aren't allowed to have fields either, precisely 
because they may not have state), or the global state 
(worse...). Just curious.


Additionally, is there a way to force the linker to link a 
function in a class without an implementation with another 
that does have an implementation?


I'm not sure if you mean the same as generating "interface 
files"?

[1] https://dlang.org/dmd-windows.html#interface-files


Basically, I want to define a common interface for a group of 
platform-specific classes, except that they should ideally also 
share constructor parameters. What I want to do is then alias 
them to a common name, selecting the implementation for the 
target platform at compile time.

Re: ranges of characters and the overabundance of traits that go with them

[H. S. Teoh via Digitalmars-d]

Ugh.  What a horrible mess!

I think, instead of wading through the specifics and losing sight of the
forest for the myriad trees, we should take a step back and consider the
big picture.

1) First of all, the user-facing API should be as simple as possible,
and things like which overload gets which type are, apropos Walter's
recent post, implementation details that ought not to be exposed to the
user directly.  So instead of:

auto func(R)(R r)
if (isInputRange!R && ...) { ...}
auto func(C)(C[] s)
if (isSomeChar!C) { ... }
auto func(R)(R r)
if (isWhoKnowsWhat!R && !isNotWhoKnowsWhatElse!R) { ... }

we really should consolidate the whole overload set into a single
template function:

auto func(R)(R r)
if (/* user-readable constraints */)
{
static if (isWhatever!R)
return implA(r);
else static if (isWhateverElse!R)
return implB(r);
else ...
else static assert(0, niceErrorMessageHere);
}

implA, implB, etc., can then be useful for deprecating stuff that's
otherwise hard to deprecate, like no longer accepting implicitly
convertible enums, alias this, or whatever.

2) The /* user-readable constraints */  ought to be one of a small
number of self-describing templates that tell the user exactly what the
*intent* of the function is (note, *intent*, as in, implementation
limitations should not be a factor).  For example, is the function
operating on r in a range-like way? Or is it primarily treating r as a
more-or-less opaque blob that has string-like characteristics (e.g.,
pass it as a filename to the OS)?  I think there are only a very small
number of such cases, and Phobos' user-facing API really should limit
themselves to only these cases and nothing more.

The current mess of isSomeString, isConvertibleToString, isNarrowString,
etc., really should be internal to Phobos, and should not be exposed to
the user at all. At the most, I'd say just ONE template that works for
all strings and string-like ranges (and whatever else we wish to
include) ought to be exposed to the user.  What should be done within
Phobos itself (in private std.* space) is another matter -- we do need
to handle the dirty details like auto-decoding, narrow strings, etc.,
here. But the point is that this should be *internal* to Phobos, not
exposed to the user like dirty laundry.


3) The purpose of a particular template function, concerning which
Jonathan wrote:

> In general, when you templatize a function involving strings, you're
> doing one of
> 
> - create a generic function that works on any range (which just so
>   happens to include strings)
> - create a function that specifically operates on strings (but is
>   templated so that it can operate on different constness or operate
>   on different character types)
> - create a function that specifically operates on a range of
>   characters, which happens to include strings
> - create a function that operates on strings or ranges of characters
>   or operates on types that implicitly convert to a string type
> - templatize a function that used to take string (or took any dynamic
>   array of characters) and make it take any range of characters

I think the first case (generic function that works on any range) is the
simplest to handle. It just accepts anything that's a range of the level
of functionality (input, forward, bidi, etc.) required by the function,
and that's good enough.  Everything else, like whether something is a
narrow string, enum, alias this, or whatever we decide to support / not
support, should be handled as implementation details. The user shouldn't
have to care about this. Inside the user-facing function, we can either
use static ifs or overloads of private implementation functions to do
whatever needs to be done to handle all those different cases.

For the rest of the cases, my question is, is there any reason to *not*
accept any arbitrary range of characters? Sure, the current
implementation may not be able to handle all the different combinations,
but again, that's implementation details.  In fact, I'd even say that as
far as is possible, we should try to generalize functions into the
previous category (works on any range).  If that's not possible, e.g.,
the function relies on the fact that the elements must be some kind of
characters, then I'd say it should, if at all possible, accept *any*
range of characters regardless of the specifics (it's a string / wstring
/ dstring, it's a user-defined range over char/wchar/dchar, etc.).

If there's any function that *cannot* be generalized into something that
accepts any arbitrary range of characters, I'd like to know about it.
I'm expecting that if there are any, they should be in the minority, so
they shouldn't need special template constraints specially dedicated for
their special use case -- we 

Re: TLS

[Rainer Schuetze via Digitalmars-d-learn]

On 13.03.2017 14:35, M-exe wrote:

On Friday, 10 March 2017 at 21:32:05 UTC, sarn wrote:

On Friday, 10 March 2017 at 19:24:29 UTC, bauss wrote:

Mark your variables with __gshared. I would say shred, but it has
some restrictions to it, where __gshared is the equivalent to global
variables in C.


immutable variables are also not put in TLS.


Thank you for yours replys but there is a tls directory even when I
compile empty main..


It's very likely that there are TLS variables in druntime that are 
linked in. You can identify them by looking at the map file.

Re: code folding

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, March 13, 2017 17:29:41 Inquie via Digitalmars-d-learn wrote:
> Does D have any nice way to specify a block for cold folding? I
> have a very large set of structs and I'd like to be able to code
> fold them all at once and together.
>
> I have been using
>
> static if(true)
> {
>  ... junk
> }
>
> but the static if is uninformative since that is the only line
> that is shown when folded. A comment helps but still kinda ugly.
>
> C# has #regions and hopefully D has something as useful.

Code-folding is an IDE thing, not a language thing. So, it's not the sort of
thing that would normally be built into a language. If Microsoft did it with
C#, it's only because they assumed that everyone would use Visual Studio,
but I would guess that #region actually does more than just enable code
folding. However, since I've done relatively little with C#, I don't know.

So, how code folding works is going to depend entirely on whatever IDE or
code editor you're using. If you told us which IDE you were using, maybe
someone here could give you some tips, but it's going to be specific to your
IDE. Normally, I think that folks just code fold based on braces if they're
doing fode folding, but I don't know. I've certainly never heard of anyone
adding anything to a source file just to enable code folding.

- Jonathan M Davis

[Issue 16342] std.algorithm.fill can't fill a char[]?

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/bab801c6723a945282b9b778c671791e6676937c
fix issue 16342 - add std.algorithm.mutation.fill fallback for mutable strings

https://github.com/dlang/phobos/commit/c6aa7b8ada515c487687e42ebf6d2d733e0cab93
Merge pull request #5128 from BBasile/issue-16342

fix issue 16342 - add std.algorithm.mutation.fill fallback for mutable strings
merged-on-behalf-of: Jack Stouffer 

--

Re: Phobos function to check if files are identical?

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

P.P.S.  It's not overly hard to write an alternative version of
std.stdio.chunks that returns a real range. Something like this should
do:

// Warning: untested code
auto realChunks(File f, size_t blockSize)
{
static struct Result
{
private File f;
private ubyte[] buffer;
bool empty = true;
ubyte[] front;

this(File _f, size_t blockSize)
{
f = _f;
buffer.length = blockSize;
empty = false;
popFront();
}
void popFront()
{
front = f.rawRead(buffer);
if (front.length == 0)
empty = true;
}
}
return Result(f, blockSize);
}


T

-- 
A program should be written to model the concepts of the task it performs 
rather than the physical world or a process because this maximizes the 
potential for it to be applied to tasks that are conceptually similar and, more 
important, to tasks that have not yet been conceived. -- Michael B. Allen

Re: Visual D 0.44 released - VC project integration and Concord debugger extension

[Inquie via Digitalmars-d-announce]

On Monday, 13 March 2017 at 08:12:41 UTC, Rainer Schuetze wrote:



On 12.03.2017 13:09, Rainer Schuetze wrote:
I'm glad to finally announce the release of a new version of 
Visual D,

the Visual Studio extension for the D programming language.


Unfortunately, a bug turned up, causing the default dmd 
executable search path to contain a bad character.


Here's a new version: 
https://github.com/dlang/visuald/releases/tag/v0.44.1


Small complaint here. Can the installer remember the previous 
install dir? I get tired of typing it in every time. It remembers 
the dmd dir just find(the next page).


I know it's not that big a deal ;) But would make the installer 
virtually silent rather than requiring input.

Re: Phobos function to check if files are identical?

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

On Mon, Mar 13, 2017 at 04:50:49PM +, XavierAP via Digitalmars-d-learn 
wrote:
> It's not easy to do by hand of course, but I was wondering if there
> was one simple function taking two file names and just returning a
> bool or something like that. I haven't found it in std.file.

Why it is not easy to do by hand?  All you have to do is open the two
files, then iterate over their data and compare.  Of course, you'd want
to chunk them up to minimize I/O roundtrips, but it'd be something along
the lines of:

bool isEqual(string filename1, string filename2) {
import std.algorithm.comparison : equal;
import std.range : zip;
import std.stdio : File, chunks;

auto f1 = File(filename1);
auto f2 = File(filename2);

size_t blockSize = 4096; // or something similar

return f1.chunks(blockSize).equal(f2.chunks(blockSize));
}


> If such a function doesn't exist in Phobos but there's a good
> implementation in some other library, I'm interested to know. Although
> this time it's for a unit test so I'd rather implement it in two lines
> than add a dependency.
> 
> And otherwise to write it by hand, how do you think is the best way?
> And in terms of performance? By chunks in case of a binary comparison?
> And what about the case of a text comparison?
[...]

Binary comparison is easy. Just read the files by fixed-sized chunks and
compare them.

Text comparison is a can of worms. What kind of comparison do you have
in mind? Case-sensitive or insensitive? Is it ASCII or Unicode? What
kind of Unicode encoding is involved?  Are the files expected to be in
one of the normalization forms, or is it free-for-all?  Do you expect
grapheme equivalence or just character equivalence?  Depending on the
answer to these questions, text comparison can range from trivial to
hair-raisingly complex.

But the fundamental ideas remain the same: read a stream of characters /
graphemes from each file in tandem, preferably buffered, and compare
them using some given comparison function.


P.S. I just realized that std.stdio.chunks() doesn't return a range.
Bah. File an enhancement request. I might even submit a PR for it. ;-)


T

-- 
There are four kinds of lies: lies, damn lies, and statistics.

Re: Declaring interfaces with a constructor

[XavierAP via Digitalmars-d-learn]

On Monday, 13 March 2017 at 02:15:21 UTC, David  Zhang wrote:
What it says on the tin. Is there a way to create interfaces 
with a constructor or must I use an abstract class.


What do you want to do in your constructor? I can't think of 
anything that wouldn't change some state, either of the class 
(but interfaces aren't allowed to have fields either, precisely 
because they may not have state), or the global state (worse...). 
Just curious.


Additionally, is there a way to force the linker to link a 
function in a class without an implementation with another that 
does have an implementation?


I'm not sure if you mean the same as generating "interface files"?
[1] https://dlang.org/dmd-windows.html#interface-files

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Monday, 13 March 2017 at 15:49:35 UTC, Joakim wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch 
wrote:
Hi Guys, due to the old CTFE status thread getting to page 30, 
I am now starting a new one.


[...]


Hey Stefan, you have been working on this for many months now: 
is someone funding your work?  If not, you should put up a 
bitcoin address or something, I know I'd contribute.


Hi Joakim,

My work does get sponsored by the D Language Foundation.
Therefore any Donations best be directed to them.

If someone wants to support my work specifically it's best to 
contact me personally.


I have been thinking about setting up a Patreon account and 
decided it was too much trouble; considering that there is not a 
large number of people who even know my of work.


Cheers, Stefan

D IDE Coedit - version 3 released.

[Basile B. via Digitalmars-d-announce]

Finally, after four betas, the third version of my D IDE [0] is 
available.


The change log for this new version quite important.

Major additions:

- GDB commander, a GDB UI, only under linux.
- Project groups.
- Compiler paths, defines and select several D compilers.

Picked among the other additions:

- support for the DUB scripts (in addition to my runnable module 
system).

- support for DUB SDL projects in read-only mode.
- Halstead metrics for D.

But there is really much more [1].

As usual, I provide binaries for linux and Windows.

[0]: https://github.com/BBasile/Coedit
[1]: https://github.com/BBasile/Coedit/releases/tag/3_gold

code folding

[Inquie via Digitalmars-d-learn]

Does D have any nice way to specify a block for cold folding? I 
have a very large set of structs and I'd like to be able to code 
fold them all at once and together.


I have been using

static if(true)
{
... junk
}

but the static if is uninformative since that is the only line 
that is shown when folded. A comment helps but still kinda ugly.


C# has #regions and hopefully D has something as useful.

Re: Can you fix this code to avoid using pointers?

[XavierAP via Digitalmars-d-learn]

On Monday, 13 March 2017 at 14:47:20 UTC, H. S. Teoh wrote:
On Sat, Mar 11, 2017 at 08:07:39PM +, XavierAP via 
Digitalmars-d-learn wrote: [...]

But I still like the version with pointers ;)


There's nothing wrong with using pointers in D.  The fact that 
D alleviates most cases of (explicit) pointers is a testament 
to just how awesome it is. ;-)  But that shouldn't deter anyone 
from using (explicit) pointers once in a while.  In fact, D 
makes it such that it's a lot safer using pointers than in 
C/C++, mainly because it alleviates most of the dangerous use 
cases for pointers so what's left is generally harmless stuff. 
Unless your code for whatever reason is involved in heavy 
pointer hackery (like OS writing), but that's not a typical use 
case.


I did it again ;)

enum params = [
"Radius of disk in m",
"Integration step size along radius",
"Total integration time in s",
"Integration step size along time",
"Time step size for output",
"Initial temperature in C",
"Edge temperature in C",
"Flow temperature in C",
"2D conductivity in W K^-1",
"2D diffusivity in m^2 s^-1",
"Convective coefficient in W m^-2 K^-1" ];

real*[params.length] vals = [
, , , , ,
, , ,
, ,  ];

import std.conv: to;

/* ... */

foreach(i, param; params)
{
/* ... */
*vals[i] = to!real(val);
}

I had the same requirement to make separate named scalars instead 
of an array; but also an array was handier to assign the values 
inside a loop; and I needed a readable  and simple way to map 
between them. An array of pointers is perfect I think.


And the only dangerous thing I could do with the pointers is 
arithmetic on them instead of the pointed values, but: "pointer 
arithmetic not allowed in @safe functions." So all is good :)

Re: TLS

[Joakim via Digitalmars-d-learn]

On Friday, 10 March 2017 at 06:41:46 UTC, M-exe wrote:
I found that D is great language, but for my own reasons I'm 
trying to use it without TLS at all.


Can the TLS directory be avoided? (compiling on windows)


I don't know what you mean by the TLS directory, can you explain?

I mean, can it avoided without losing GC and main language 
features?


You could probably modify druntime so that it doesn't use any 
Thread-Local Storage, but Phobos uses it extensively, as global 
and static variables are put in TLS by default since D 2.030:


https://dlang.org/migrate-to-shared.html

Are you against emulated TLS also?  If not, I have modified dmd, 
ldc, and druntime to use the same emulated TLS scheme Walter came 
up with for OS X, for my Android port:


https://github.com/dlang/dmd/pull/3643
https://github.com/ldc-developers/ldc/pull/1447
https://github.com/dlang/druntime/pull/784

You may be able to use something similar on Windows, depending on 
how feasible such an emulated TLS scheme is there and if you want 
to dig into these details.

Re: Ocean v3.0.0: First fully public release!

[Leandro Lucarella via Digitalmars-d-announce]

On Monday, 13 March 2017 at 11:33:42 UTC, Nicholas Wilson wrote:
On Monday, 13 March 2017 at 11:08:51 UTC, Leandro Lucarella 
wrote:

On Friday, 10 March 2017 at 16:31:53 UTC, Andrea Fontana wrote:
On Friday, 10 March 2017 at 15:19:51 UTC, Leandro Lucarella 
wrote:

Hi dear D community!

We wanted to share with you some nice news and big 
milestone: we are (finally!) going completely public with 
Ocean development!


From github page:
General purpose, platform-dependant, high-performance library 
for D


You missed it :)


I don't get this. What did I miss exactly? :)


Your OP doesn't say what Ocean does.


Right, the library itself was announced a long time ago here but 
maybe I shouldn't assume people in this forum don't change (and 
it has good memory, I know I don't :D).


Extended description, in case is useful:

Ocean is a general purpose library, compatible with both D1 and 
D2, with a focus on supporting the development of 
high-performance, real-time applications. This focus has led to 
several noteworthy design choices:


* Ocean is not cross-platform. The only supported platform is 
Linux.
* Ocean assumes a single-threaded environment. Fiber-based 
multi-tasking is favoured,

  internally.
* Ocean aims to minimise use of the D garbage collector. GC 
collect cycles can be very
  disruptive to real-time applications, so Ocean favours a model 
of allocating resources

  once then reusing them, wherever possible.

Ocean began life as an extension of Tango, some elements of which 
were eventually merged into Ocean.

Re: Can i using D & LLVM & SDL2 for Android?

[Joakim via Digitalmars-d-learn]

On Monday, 13 March 2017 at 09:33:39 UTC, rikki cattermole wrote:

On 13/03/2017 7:48 PM, Joakim wrote:

[...]


Why exactly doesn't the Android port support dlopen, dlsym and 
dlclose?

It is provided by the NDK libc.

At least according to this[0].

[0] https://developer.android.com/ndk/guides/stable_apis.html


I was more talking about D shared libraries, which I'm assuming 
DerelictSDL2 qualifies as and would require Phobos built as a 
shared library.  That hasn't been tried yet on Android.


On Monday, 13 March 2017 at 10:11:35 UTC, Mike Parker wrote:

On Monday, 13 March 2017 at 06:48:01 UTC, Joakim wrote:


[...]


The alpha release of DerelictSDL2 3.0 supports static linking.

When compiling manually, it requires 
-version=DerelictSDL_static on the command line and all files 
matching "derelict/sdl2/internal/*_dyn*.d" should be excluded 
from the build.


When building DerelictSDL2 with DUB, specifying 
-cderelict-sdl2-static gets the job done, or the same can be 
added as a subConfiguration value in a project's dub.json/sdl 
file.


Thanks for the update, didn't know that.

Phobos function to check if files are identical?

[XavierAP via Digitalmars-d-learn]

It's not easy to do by hand of course, but I was wondering if 
there was one simple function taking two file names and just 
returning a bool or something like that. I haven't found it in 
std.file.


If such a function doesn't exist in Phobos but there's a good 
implementation in some other library, I'm interested to know. 
Although this time it's for a unit test so I'd rather implement 
it in two lines than add a dependency.


And otherwise to write it by hand, how do you think is the best 
way? And in terms of performance? By chunks in case of a binary 
comparison? And what about the case of a text comparison?


Thanks

Re: Munich D Meetup - March 28ths - Clean Code Competition

[Casey Sybrandy via Digitalmars-d-announce]

Will the results of this be published somewhere?  It would be 
interesting to see how the different languages compare.

Re: Update on Unums

[John Colvin via Digitalmars-d-announce]

On Monday, 13 March 2017 at 15:08:56 UTC, H. S. Teoh wrote:
On Mon, Mar 13, 2017 at 08:32:04AM +, Nick B via 
Digitalmars-d-announce wrote:
If I get the approval to post Johns latest presentation, I 
will do so.

[...]

Link?


urmm...

Re: CTFE Status 2

[Meta via Digitalmars-d]

On Monday, 13 March 2017 at 15:49:35 UTC, Joakim wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch 
wrote:
Hi Guys, due to the old CTFE status thread getting to page 30, 
I am now starting a new one.


[...]


Hey Stefan, you have been working on this for many months now: 
is someone funding your work?  If not, you should put up a 
bitcoin address or something, I know I'd contribute.


There's Patreon, but they don't support bitcoin currently.

Re: CTFE Status 2

[Joakim via Digitalmars-d]

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
Hi Guys, due to the old CTFE status thread getting to page 30, 
I am now starting a new one.


[...]


Hey Stefan, you have been working on this for many months now: is 
someone funding your work?  If not, you should put up a bitcoin 
address or something, I know I'd contribute.

Re: Update on Unums

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

On Mon, Mar 13, 2017 at 08:32:04AM +, Nick B via Digitalmars-d-announce 
wrote:
> Hi Everyone
> 
> Here is an update on Unums.
> 
> John L Gustafson at the Multicore World 2017 Conference, in
> Wellington,  New Zealand, in February 2017, gave another presentation
> to his Unum idea.   He has again reworked the basis of his idea again.
> He has now called this latest version: Type 3 Unums (2017), and
> introduced new labels of Posits and Valids for contrasting Calculation
> Esthetics.
> 
> If I get the approval to post Johns latest presentation, I will do so.
[...]

Link?


T

-- 
MSDOS = MicroSoft's Denial Of Service

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

[Nick Treleaven via Digitalmars-d]

On Saturday, 11 March 2017 at 19:28:16 UTC, H. S. Teoh wrote:
So the idea is to analyse the format string at compile-time to 
determine exactly what functionality is actually used, and 
instantiate only that. Think of it as a format-string 
mini-compiler: given a format string and a list of argument 
types, compile it into the equivalent minimal D code. E.g.:


format("abc%sdef", s)

should get compiled into:

"abc" ~ s ~ "def"   // N.B.: no floating-point code, no
// width handling, etc.


Sounds good, and it would be more efficient at runtime. But as 
the type checking is easier, and the interface is the same, I 
think we could add type checking now and hopefully do the CT 
parsing later.

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

[H. S. Teoh via Digitalmars-d]

On Sat, Mar 11, 2017 at 08:55:12PM +, Ola Fosheim Grøstad via Digitalmars-d 
wrote:
> On Friday, 10 March 2017 at 22:41:43 UTC, H. S. Teoh wrote:
> > The problem is that "<<" was designed to be a bit-shift operator,
> > and as such it has a specific precedence level in the hierarchy of
> > operators.
> 
> Fair point. IIRC Algol68 allowed custom precedence levels. Found this:
> http://www.kestrel.edu/home/people/meertens/publications/papers/Operator-Priority_Grammar_for_ALGOL_68+.pdf

Custom precedence levels make the language a pain to parse, esp. by
external 3rd party tools.  Which generally also means (good) tooling
will be harder to come by.  Doesn't seem like a commensurate price with
the little replaceable benefit that you get.


> At the other end of the spectrum Pony requires explicit parens for
> operators outside the most familiar ones ("+", "-", "*"...).

This may not be a bad idea, actually. How many among us can actually
memorize the entire precedence hierarchy of C/C++ operators? I certainly
can't. Meaning that most of the time you'd already be writing
parentheses anyway, just to be sure, so it wouldn't be an onerous
requirement to always write them.


T

-- 
My program has no bugs! Only undocumented features...

Re: Can you fix this code to avoid using pointers?

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

On Sat, Mar 11, 2017 at 08:07:39PM +, XavierAP via Digitalmars-d-learn 
wrote:
[...]
> I realized that the code that sparked the question made no sense and
> should be done in a different way... As is always the case when these
> questions come up.
> But I still like the version with pointers ;)

There's nothing wrong with using pointers in D.  The fact that D
alleviates most cases of (explicit) pointers is a testament to just how
awesome it is. ;-)  But that shouldn't deter anyone from using
(explicit) pointers once in a while.  In fact, D makes it such that it's
a lot safer using pointers than in C/C++, mainly because it alleviates
most of the dangerous use cases for pointers so what's left is generally
harmless stuff. Unless your code for whatever reason is involved in
heavy pointer hackery (like OS writing), but that's not a typical use
case.


T


-- 
All problems are easy in retrospect.

Re: how to assign tuple named Tuple easily

[Inquie via Digitalmars-d-learn]

On Monday, 13 March 2017 at 00:23:36 UTC, ag0aep6g wrote:

On 03/13/2017 01:02 AM, Inquie wrote:

Ok, it doesn't work for appending though ;)

[...]

Tuple!(int, "A", double, "B")[] y;
y ~= tuple(3, 2.5);


Interestingly, this works:

Tuple!(int, "A", double, "B")[] y;
y.length += 1;
y[$ - 1] = tuple(3, 2.5);


yeah, seems more like a bug/feature issue. If the compiler can 
figure it out with assignment, it should also be able to figure 
it out with appending EXACTLY because what you wrote. Since a 
default append is effectively the code you wrote above there 
should be no difference between the two. In fact, I would have 
hoped that appending built in arrays would have been expanded 
using the pattern you specifically implemented which should then 
not produce the error and simplify life.

Re: scope(~this)

[Inquie via Digitalmars-d-learn]

On Monday, 13 March 2017 at 05:18:18 UTC, Nicholas Wilson wrote:

On Sunday, 12 March 2017 at 21:38:44 UTC, Inquie wrote:
Is there any easy way to create a scope for termination of the 
object?


I have a template method that takes a type and allocates and 
deallocates based on that type.


class bar
{
   void foo(T)()
   {
  T x;
  alloc(x);
  scope(~this) dealloc(x); // hypothetical that wraps the 
statement in a lambda and deallocates in the destructor


  ... x must stay allocated until class instance 
termination(has to do with COM, can't release it in foo)

   }

}

Now, x cannot be a field because T is unknown(i suppose I 
could use object, void*, etc, but...).




If it is COM then you should use IUnknown (the COM root 
interface),or if you are expecting multiple calls to foo, an 
array of IUnknown. I think the GC will clean up completely for 
you in either case and call release(?) on the member(s).


Also as it is COM you probably don't need to template it, just 
choose T to be the most recent ancestor of all (old) T's you 
would be expecting foo to be instantiated with (e.g. IUnknown 
if you expect any COM object.


Sorry, but that is missing the point! First, it isn't that 
simple. I do not think the GC will call release as the GC has no 
idea of COM nor the interfaces. While it might be safe not to 
release them and let the OS deal with it, this is not standard. 
The template is to not part of COM but required to dynamically 
instantiate the COM interface that is not supplied(using 
GetIDsOfNames).


So, the way it work is, I have a function that takes an interface 
which specifies the dynamic COM functions. Using 
GetIDsOfNames(since that seems to be the only way) gets the 
function pointers to these functions in which I build up a new 
object representing that interface. The problem is, One must use 
CoCreateInterface to create the COM object to use 
GetIDsOfNames(neither of which depends on the interface). But 
CoCreateInterface returns the interface with the Release function 
as a member and this function must be called later(at terminate 
of the overall class handling all this stuff).


But since I have to create a variable with the interface to get 
the methods and to pass to CoCreateInstance, and eventually use 
it to call Release, I can't discard the variable at the end of 
the function.


Basically the interface's lifetime must exist for the entirety of 
the containing object. Normally one would use the constructor and 
class fields to manage this, but it is impossible here because 
the actual interfaces are unknown at compile time(they are 
extracted from an idl by this class).


The only thing I could do is keep an array of all these IUnknown 
interfaces(sorta using the above technique), since IUnknown has 
the Release function in it, basically using your suggestion or 
what I originally said is a feasible solution.


But this pollutes the class name space unnecessarily(I know it is 
just an array, but ultimately should be unnecessary).


Rather, if I could simply use a

scope(~this) or some other mechanism, everything will be 
automatically taken care of.


scope(~this) X.Release();

would realize that X, the local variable in the function, will be 
used and the GC will not free it just like delegates do(although 
it would need to be copied to the heap so future function calls 
won't corrupt the value when used on the stack, or, alternatively 
I could malloc it in the function instead).


Then, on destruction, the scope is executed. X still exists.

In this case, it's 1 line of code rather than about 5(a class 
field array, an append, and calling release on all appends in the 
destructor). It's very clear and very precise.


It's very similar to scope(exit) for function but for 
classes(since classes can "exit" too).


It may be better to call it

scope(this)

which is more clear(when the scope of the object instance is 
over, then "execute" what follows).


I think this feature would actually be quite useful. Instead of 
handling many things in the destructor, we can handle them on 
site. e.g., any class resources that are allocated could then 
have a scope(this) right after allocation to deallocate them 
instead of having to push it in the the destructor which 
separates the code visually and programmatically. The same 
argument which is used to make scope(exit) useful, but on a 
higher level... Which, if we follow it, we should then also have 
scope(application) or something for application level scope.

Recursive template instantiation

[Jack Applegame via Digitalmars-d-learn]

I'm pretty sure that this code should compile 
(https://dpaste.dzfl.pl/cf1e1ee6ef4b):


struct A(T) {
~this() {
char[T.sizeof] data;
}
}

struct B(T) {
A!T foo;
}

struct C {
B!C bar;
}

void main() {
C c;
}

But it doesn't:
/d300/f416.d(3): Error: struct f416.C no size because of forward 
reference /d300/f416.d(12): Error: template instance f416.B!(C) 
error instantiating


Notice that the same C++ code compiles without problems:

template struct A {
~A() {
char data[sizeof(T)];
}
};

template struct B {
A foo;
};

struct C {
B bar;
};

int main() {
C c;
}

A simple recursion is compiled successfully 
(https://dpaste.dzfl.pl/5a8ff73bfa88):


struct A(T) {
~this() {
char[T.sizeof] data;
}
}

struct C {
A!C bar;
}

void main() {
C c;
}

Re: how to assign tuple named Tuple easily

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

On Monday, 13 March 2017 at 14:09:58 UTC, Inquie wrote:
Yeah, so, surely though we can extract the names from the 
variable and then supply those like I mentioned?


Yeah, we prolly could, but a simpler thing might be to just use 
typeof:


Tuple!(int, "A")[] x;
x ~= typeof(x[0])(3);


x ~= tuple!x(3)

? Seems like it would probably be rather trivial with a bit of 
template code?


Yeah, tuple could certainly adapt to do that too, but I see you 
would write:



x ~= tuple!typeof(x)(3, 5.0);


and the `tuple!` there is unnecessary: if you already use 
`typeof(x[0])` (you still need a `[0]` in there to get the type 
of the element instead of the array), then you can just construct 
it right there with the next set of parens.

Re: how to assign tuple named Tuple easily

[Inquie via Digitalmars-d-learn]

On Monday, 13 March 2017 at 00:51:27 UTC, Adam D. Ruppe wrote:

On Monday, 13 March 2017 at 00:02:12 UTC, Inquie wrote:
I just figured it didn't work in general, but seems to be an 
issue with appending.


Oh, it is because of the implicit construction thing, see my 
answer here to learn more: 
http://stackoverflow.com/a/42285015/1457000


You can construct the named tuple from a tuple() but you can't 
convert one to another since the names change the type.


I don't think the language has a solution with this since you 
can't implicit construct nor overload operators on built in 
arrays (if it is a custom array, you can do an opOpAssign).


What you could do is

alias ShortName = Tuple!(int, "A");

ShortName[] a;
a ~= ShortName(3);

... of course, at that point, you can also just use a regular 
struct too...



Yeah, so, surely though we can extract the names from the 
variable and then supply those like I mentioned?


Tuple!(int, "A")[] x;
x ~= tuple!(ExtractTupleNames!x)(3);

which would be equivalent to

x ~= tuple!("A")(3)

which, of course, works.

ExtractTupleNames is a template that surely can get the names 
from x? Knowing it's type and that every other element of the 
type is a "name" it should be able to get the names then provide 
them to tuple? From there, we could redefine tuple to do this 
automatically as


x ~= tuple!x(3)

? Seems like it would probably be rather trivial with a bit of 
template code?



Ok, I did this real quick, maybe you can see how to improve it 
and reduce verbosity:


import std.typecons, std.typetuple, std.meta, std.string, 
std.array, std.range;


template ExtractTupleNames(T)
{   

string fix()
{
enum q = (T.stringof[7..$-3]);  
return "alias ExtractTupleNames = AliasSeq!("~q~");";
}

mixin(fix());

}

void main(string[] argv)
{


Tuple!(int, "A", double, "B")[] x;

x ~= tuple!("A", "B")(3, 5.0);
x ~= tuple!(int, "A", double, "B")(3, 5.0);
x ~= tuple!(ExtractTupleNames!(typeof(x)))(3, 5.0);
}

The goal would be to not have to specify the long string each 
time.


e.g., the third line would be either

x ~= tuple!(x)(3, 5.0);

or

x ~= tuple!typeof(x)(3, 5.0);

It would be nice if we could pass a "run time" variable since we 
are only going to use it's type in the first place(avoids having 
to specify the typeof at the call point).


I realize that we will probably have to redefine tuple but I'm ok 
with that as it only makes it more robust.

Re: TLS

[M-exe via Digitalmars-d-learn]

On Friday, 10 March 2017 at 21:32:05 UTC, sarn wrote:

On Friday, 10 March 2017 at 19:24:29 UTC, bauss wrote:
Mark your variables with __gshared. I would say shred, but it 
has some restrictions to it, where __gshared is the equivalent 
to global variables in C.


immutable variables are also not put in TLS.


Thank you for yours replys but there is a tls directory even when 
I compile empty main..

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Monday, 13 March 2017 at 11:53:59 UTC, Kagamin wrote:

On Friday, 10 March 2017 at 11:32:14 UTC, Stefan Koch wrote:
I am currently working on integrating 64bit values into 
codegen API.


How can dmd generate 64-bit code if backend doesn't support 
64bit values?


I was referring to my newCTFE Bytecode-codegen.
It is separate from dmd's backend.

Just for completeness sake, it is perfectly possible to generate 
x86_64 code without supporting 64bit values, you will just have 
alot of zeros in the upper bits :)


dmd does support 64bit values of course.

Re: CTFE Status 2

[Kagamin via Digitalmars-d]

On Friday, 10 March 2017 at 11:32:14 UTC, Stefan Koch wrote:
I am currently working on integrating 64bit values into codegen 
API.


How can dmd generate 64-bit code if backend doesn't support 64bit 
values?

Re: Ocean v3.0.0: First fully public release!

[Nicholas Wilson via Digitalmars-d-announce]

On Monday, 13 March 2017 at 11:08:51 UTC, Leandro Lucarella wrote:

On Friday, 10 March 2017 at 16:31:53 UTC, Andrea Fontana wrote:
On Friday, 10 March 2017 at 15:19:51 UTC, Leandro Lucarella 
wrote:

Hi dear D community!

We wanted to share with you some nice news and big milestone: 
we are (finally!) going completely public with Ocean 
development!


From github page:
General purpose, platform-dependant, high-performance library 
for D


You missed it :)


I don't get this. What did I miss exactly? :)


Your OP doesn't say what Ocean does.

Re: Ocean v3.0.0: First fully public release!

[Leandro Lucarella via Digitalmars-d-announce]

On Friday, 10 March 2017 at 16:31:53 UTC, Andrea Fontana wrote:
On Friday, 10 March 2017 at 15:19:51 UTC, Leandro Lucarella 
wrote:

Hi dear D community!

We wanted to share with you some nice news and big milestone: 
we are (finally!) going completely public with Ocean 
development!


From github page:
General purpose, platform-dependant, high-performance library 
for D


You missed it :)


I don't get this. What did I miss exactly? :)

Re: GDC options

[Russel Winder via Digitalmars-d-learn]

On Sun, 2017-03-12 at 16:38 +0100, Johannes Pfau via Digitalmars-d-
learn wrote:
> 
[…]
> 
> https://github.com/D-Programming-GDC/GDMD/tree/dport
> 
> gdmd -unittest --main
> 
> The unittest flag for GDC is -funittest but there's no flag to
> generate
> a main function. gdmd generates a temporary file with a main function
> to implement this.

gdmd is not packaged with gdc so isn't a general solution. gdmd, like
rdmd, should be packaged.

Having dmd, ldc, and gdc have different command lines is really ###
awkward when using SCons and Meson. It is a shame that dmd and ldc do
not just use the standard GCC option set.

-- 
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: Can i using D & LLVM & SDL2 for Android?

[dummy via Digitalmars-d-learn]

On Monday, 13 March 2017 at 10:11:35 UTC, Mike Parker wrote:

On Monday, 13 March 2017 at 06:48:01 UTC, Joakim wrote:


[...]


The alpha release of DerelictSDL2 3.0 supports static linking.

When compiling manually, it requires 
-version=DerelictSDL_static on the command line and all files 
matching "derelict/sdl2/internal/*_dyn*.d" should be excluded 
from the build.


When building DerelictSDL2 with DUB, specifying 
-cderelict-sdl2-static gets the job done, or the same can be 
added as a subConfiguration value in a project's dub.json/sdl 
file.


thanks for advices!! :-)

Re: Can i using D & LLVM & SDL2 for Android?

[dummy via Digitalmars-d-learn]

On Monday, 13 March 2017 at 06:48:01 UTC, Joakim wrote:

On Thursday, 9 March 2017 at 10:35:18 UTC, dummy wrote:

[...]


Regarding the link to that forum post, that bug has since been 
found and fixed.


If you're planning on using Derelict, there is an issue where 
all Derelict libraries are loaded as shared libraries, whereas 
the Android port currently doesn't support loading shared 
libraries.  If DLangUI is using SDL2, maybe he has a header 
file that allows him to statically link against SDL2, which you 
could reuse.


Otherwise, you may need to generate one using DStep:

https://github.com/jacob-carlborg/dstep

or modify the DerelictSDL2 files to allow you to link 
statically.


thx! i will try it. :-D

How can I get changed members in class object?

[donglei via Digitalmars-d-learn]

In hibernate,update object is set all table columns to sql.
code for example:
```
//orm entity
class User {
int id;
string firstName;
string lastName;

}
Session sess = factory.openSession();
User user =sess.createQuery("FROM User WHERE 
first_name=:firstName").setParameter("firstName","balabala").uniqueResult!User();


user.lastName = "new balabala";//change last name

sess.update(user);

```
when exec update method ,hibernate generate sql like that
```
UPDATE user SET first_name =?, last_name =? WHERE id=?

```

but i just want to modify or update last_name column, maybe sql is
```
UPDATE user SET  last_name =? WHERE id=?

```
does hibernate has a method to update changed columns only？

how can i do that?

Re: Can i using D & LLVM & SDL2 for Android?

[Mike Parker via Digitalmars-d-learn]

On Monday, 13 March 2017 at 06:48:01 UTC, Joakim wrote:

If you're planning on using Derelict, there is an issue where 
all Derelict libraries are loaded as shared libraries, whereas 
the Android port currently doesn't support loading shared 
libraries.  If DLangUI is using SDL2, maybe he has a header 
file that allows him to statically link against SDL2, which you 
could reuse.


Otherwise, you may need to generate one using DStep:

https://github.com/jacob-carlborg/dstep

or modify the DerelictSDL2 files to allow you to link 
statically.


The alpha release of DerelictSDL2 3.0 supports static linking.

When compiling manually, it requires -version=DerelictSDL_static 
on the command line and all files matching 
"derelict/sdl2/internal/*_dyn*.d" should be excluded from the 
build.


When building DerelictSDL2 with DUB, specifying 
-cderelict-sdl2-static gets the job done, or the same can be 
added as a subConfiguration value in a project's dub.json/sdl 
file.

[Issue 17254] New: The code completion box is too narrow on Surface pro 3

[via Digitalmars-d-bugs]

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

  Issue ID: 17254
   Summary: The code completion box is too narrow on Surface pro 3
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: visuald
  Assignee: nob...@puremagic.com
  Reporter: bitwo...@qq.com

Created attachment 1639
  --> https://issues.dlang.org/attachment.cgi?id=1639=edit
narrow list box

My computer is Surface pro 3. 
See the attachment.

--

Re: Update on Unums

[rikki cattermole via Digitalmars-d-announce]

On 13/03/2017 9:32 PM, Nick B wrote:

Hi Everyone

Here is an update on Unums.

John L Gustafson at the Multicore World 2017 Conference, in Wellington,
New Zealand, in February 2017, gave another presentation to his Unum
idea.   He has again reworked the basis of his idea again.  He has now
called this latest version: Type 3 Unums (2017), and introduced new
labels of Posits and Valids for contrasting Calculation Esthetics.

If I get the approval to post Johns latest presentation, I will do so.

cheers
Nick


Nice!

Re: Can i using D & LLVM & SDL2 for Android?

[rikki cattermole via Digitalmars-d-learn]

On 13/03/2017 7:48 PM, Joakim wrote:

On Thursday, 9 March 2017 at 10:35:18 UTC, dummy wrote:

On Wednesday, 8 March 2017 at 10:24:24 UTC, Joakim wrote:

On Tuesday, 7 March 2017 at 12:06:48 UTC, dummy wrote:

Just thought. I do want to know. :-)

As far as I know is,
  * LDC2 woring on NDK(yah!)
  * Native OpenGLES:
http://wiki.dlang.org/Build_LDC_for_Android#Build_a_sample_OpenGL_Android_app_ported_to_D

  * Dlangui working on Android that based on SDL2:
https://github.com/buggins/dlangui /
https://dlang.org/blog/2016/10/07/project-highlight-dlangui/

regards,


Yes, though I have not tried SDL2 myself.


https://forum.dlang.org/post/hbumubsbrzffvgria...@forum.dlang.org

Ah, you're right.
I will trying DerelictSDL2.

Thx :-)


Regarding the link to that forum post, that bug has since been found and
fixed.

If you're planning on using Derelict, there is an issue where all
Derelict libraries are loaded as shared libraries, whereas the Android
port currently doesn't support loading shared libraries.  If DLangUI is
using SDL2, maybe he has a header file that allows him to statically
link against SDL2, which you could reuse.

Otherwise, you may need to generate one using DStep:

https://github.com/jacob-carlborg/dstep

or modify the DerelictSDL2 files to allow you to link statically.


Why exactly doesn't the Android port support dlopen, dlsym and dlclose?
It is provided by the NDK libc.

At least according to this[0].

[0] https://developer.android.com/ndk/guides/stable_apis.html

Re: ranges of characters and the overabundance of traits that go with them

[Andrea Fontana via Digitalmars-d]

On Sunday, 12 March 2017 at 03:23:21 UTC, Jonathan M Davis wrote:
Okay, I'm sorry, but this is a wall of text, and I don't know 
how to actually make it short. If you really want the TLDR 
version, look for the =='s at the bottom which mark off the 
conclusion, but you're not going to understand the reasoning if 
you skip the wall of text. Now, to the post...

[...]


Very well-written and interesting post!

Update on Unums

[Nick B via Digitalmars-d-announce]

Hi Everyone

Here is an update on Unums.

John L Gustafson at the Multicore World 2017 Conference, in 
Wellington,  New Zealand, in February 2017, gave another 
presentation to his Unum idea.   He has again reworked the basis 
of his idea again.  He has now called this latest version: Type 3 
Unums (2017), and introduced new labels of Posits and Valids for 
contrasting Calculation Esthetics.


If I get the approval to post Johns latest presentation, I will 
do so.


cheers
Nick

Re: Visual D 0.44 released - VC project integration and Concord debugger extension

[Rainer Schuetze via Digitalmars-d-announce]

On 12.03.2017 13:09, Rainer Schuetze wrote:

I'm glad to finally announce the release of a new version of Visual D,
the Visual Studio extension for the D programming language.


Unfortunately, a bug turned up, causing the default dmd executable 
search path to contain a bad character.


Here's a new version: https://github.com/dlang/visuald/releases/tag/v0.44.1

[Issue 17252] Invalid PATH variable in build script

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #2 from Rainer Schuetze  ---
fixed in https://github.com/dlang/visuald/releases/tag/v0.44.1

--

[Issue 17252] Invalid PATH variable in build script

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||r.sagita...@gmx.de
 Resolution|INVALID |---

--- Comment #1 from Rainer Schuetze  ---
I suspect you've created this issue for one of the RCs for 0.44. It's actually
a bug still in the release.

--

Re: Can i using D & LLVM & SDL2 for Android?

[Joakim via Digitalmars-d-learn]

On Thursday, 9 March 2017 at 10:35:18 UTC, dummy wrote:

On Wednesday, 8 March 2017 at 10:24:24 UTC, Joakim wrote:

On Tuesday, 7 March 2017 at 12:06:48 UTC, dummy wrote:

Just thought. I do want to know. :-)

As far as I know is,
  * LDC2 woring on NDK(yah!)
  * Native OpenGLES: 
http://wiki.dlang.org/Build_LDC_for_Android#Build_a_sample_OpenGL_Android_app_ported_to_D
  * Dlangui working on Android that based on SDL2: 
https://github.com/buggins/dlangui / 
https://dlang.org/blog/2016/10/07/project-highlight-dlangui/


regards,


Yes, though I have not tried SDL2 myself.


https://forum.dlang.org/post/hbumubsbrzffvgria...@forum.dlang.org

Ah, you're right.
I will trying DerelictSDL2.

Thx :-)


Regarding the link to that forum post, that bug has since been 
found and fixed.


If you're planning on using Derelict, there is an issue where all 
Derelict libraries are loaded as shared libraries, whereas the 
Android port currently doesn't support loading shared libraries.  
If DLangUI is using SDL2, maybe he has a header file that allows 
him to statically link against SDL2, which you could reuse.


Otherwise, you may need to generate one using DStep:

https://github.com/jacob-carlborg/dstep

or modify the DerelictSDL2 files to allow you to link statically.