Passing directory as compiler argument not finding file

[Jamie via Digitalmars-d-learn]

With a directory structure as follows:

run/
A/
a.d

Where a.d is:
===
module A.d;


I'm attempting to compile from the run/ directory. If I run with
dmd ../A/a.d

it compiles successfully, however if I pass it the directory
dmd -I=../A a.d

it doesn't compile. Also, if I pass the exact directory
dmd -I=/../A a.d

it doesn't compile.

Both times I get the error
Error: module `a` is in the file 'a.d' which cannot be read

However it then shows the import path as being
import path[0] = ../A

for the first way and
import path[0] = /../A
for the second way.

Am I using the -I compiler option incorrectly?

Re: Migrating an existing more modern GC to D's gc.d

[Ikeran via Digitalmars-d]

On Tuesday, 10 April 2018 at 06:47:53 UTC, Jonathan M Davis wrote:
As it stands, it's impossible to have thread-local memory 
pools. It's quite legal to construct an object as shared or 
thread-local and cast it to the other. In fact, it's _highly_ 
likely that that's how any shared object of any complexity is 
going to be constructed. Similarly, it's extremely common to 
allocate an object as mutable and then cast it to immutable 
(either using assumeUnique or by using a pure function where 
the compiler does the cast implicitly for you if it can 
guarantee that the return value is unique), and immutable 
objects are implicitly shared. At minimum, there would have to 
be runtime hooks to do something like move an object between 
pools when it is cast to shared or immutable (or back) in order 
to ensure that an object was in the right pool, but if that 
requires copying the object rather than just moving the memory 
block, then it can't be done, because every pointer or 
reference pointing to that object would have to be rewritten 
(which isn't supported by the language).


It's a bit easier than that. When you cast something to shared or 
immutable, or allocate it as shared or immutable, you pin the 
object on the local heap. When the thread-local collector runs, 
it won't collect that object, since another thread might know 
about it. Then, when you run the global collector, it will 
determine which shared objects are still reachable and unpin 
things as appropriate.


That unpinning process requires a way to look up the owning 
thread for a piece of memory, which can be done in logarithmic 
time relative to the number of contiguous segments of address 
space.


Casting away from shared would not call any runtime functions; 
even if it were guaranteed that the cast were done on the 
allocating thread, it's likely that there exists another 
reference to the item in another thread.


This would discourage the use of immutable, since it wouldn't 
benefit from thread-local heaps.

Re: Escaping address of

[Uknown via Digitalmars-d-learn]

On Wednesday, 11 April 2018 at 16:25:20 UTC, Jonathan M Davis 
wrote:

[...]


Adding a destructor makes the compiler return an error about 
lifetimes, with or without -dip1000


https://run.dlang.io/is/ddXqNu

Re: Is using function() in templates possible at all?

[Nicholas Wilson via Digitalmars-d-learn]

On Wednesday, 11 April 2018 at 22:13:33 UTC, Sjoerd Nijboer wrote:

On Wednesday, 11 April 2018 at 21:29:27 UTC, Alex wrote:

I would say, alias template parameter is your friend.
https://dlang.org/spec/template.html#TemplateAliasParameter

class SortedList(T, alias comparer)


It works, thank you!
But just to be shure, there's no way to have this more strongly 
typed in D so I can enforce that `comparer`is a funciton or 
delegate with a specific definition?



There is, with template constraints:

class SortedList(T, alias comparer) if(is(typeof(comparer(T.init) 
: int))

{
//...
}

Re: Parse .eml files

[bachmeier via Digitalmars-d-learn]

On Wednesday, 11 April 2018 at 15:20:08 UTC, Martin Tschierschke 
wrote:


My question in the moment is, how do I invoke Thunderbird to 
display a certain single mail (or maildir) file?
How do I use Thunderbird as the client, to show, to answer or 
to forward these mails.
An alternative would be to use a browser based mailer? Handling 
all attachments is an other purpose.


Can you use executeShell and call Thunderbird from the command 
line? Something like


executeShell("thunderbird -compose \"subject='My Christmas 
Gift',body='Please send me a new car',to='sa...@claus.net'")


http://kb.mozillazine.org/Command_line_arguments_%28Thunderbird%29

[Issue 18755] New: std.typecons.Rebindable breaks @safe-ty

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18755
   Summary: std.typecons.Rebindable breaks @safe-ty
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: safe
  Severity: critical
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: c...@klickverbot.at

This compiles and runs with DMD 2.079:

---
class Foo {
auto opCast(T)() @system immutable pure nothrow {
*(cast(uint*)0xdeadbeef) = 0xcafebabe;
return T.init;
}
}

void main() @safe {
import std.typecons;
auto r = Rebindable!(immutable Foo)(new Foo); // oops
}
---

--

Re: I used to be able to use a bffer for toUTF operation, what happened ?

[deadalnix via Digitalmars-d]

On Wednesday, 11 April 2018 at 12:41:24 UTC, Vladimir Panteleev 
wrote:

On Wednesday, 11 April 2018 at 12:04:24 UTC, deadalnix wrote:

This used to be an option:

dchar val = ...;
char[4] buf;
toUTF8(buf, val);

Now I'm getting an error.


This std.utf.toUTF8 overload was deprecated in 2.074.0 and 
finally removed in 2.077.0:


https://run.dlang.io/is/O57AGU (click Run)

Do you have deprecation messages turned on?


Yes, but I skipped a few version.

encode as proposed indeed does the job, so no problem.

Thanks everybody.

Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted

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

On Wed, Apr 11, 2018 at 08:45:15PM +, Dmitry Olshansky via 
Digitalmars-d-announce wrote:
[...]
> What would have made contract trully powerful for me is them being
> emitted at caller side. This way if I use a release build of library
> but debugging my app I still get my stupidity guarded by contracts of
> the API. *
[...]

I say this should be the next step.  We should write up a DIP for this.


T

-- 
Creativity is not an excuse for sloppiness.

Re: Is using function() in templates possible at all?

[Sjoerd Nijboer via Digitalmars-d-learn]

On Wednesday, 11 April 2018 at 21:29:27 UTC, Alex wrote:

I would say, alias template parameter is your friend.
https://dlang.org/spec/template.html#TemplateAliasParameter

class SortedList(T, alias comparer)


It works, thank you!
But just to be shure, there's no way to have this more strongly 
typed in D so I can enforce that `comparer`is a funciton or 
delegate with a specific defenition?
Right now i'm relying on the template to error on some different 
place which might not give such a readable error message to the 
user.

[Issue 18751] chunkBy predicate cannot access local variable

[d-bugmail--- via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   Keywords|pull|
  Component|phobos  |dmd

--- Comment #3 from hst...@quickfur.ath.cx ---
PR has been closed, as it has been decided this needs to be addressed in the
compiler rather than the library.

--

PixelPerfectEngine v0.9.4-alpha.2

[solidstate1991 via Digitalmars-d-announce]

https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.9.4-alpha.2
The editor is almost usable (still needs a way to import tiles 
from its own proprietary format), and now has a working, although 
still a bit slow and unstable transformable tile layer with 
mode7-esque capabilities.

Re: Is using function() in templates possible at all?

[Alex via Digitalmars-d-learn]

On Wednesday, 11 April 2018 at 21:07:03 UTC, Sjoerd Nijboer wrote:


class SortedList(T, int function(T) comparer)


I would say, alias template parameter is your friend.
https://dlang.org/spec/template.html#TemplateAliasParameter

´´´
import std.stdio;
import std.range;

void main()
{
auto list = new SortedList!(Vector3, v => v.y)();

assert(list.array.empty);
list.foo(Vector3.init);
}

struct Vector3 { float x, y, z; }

class SortedList(T, alias comparer)
{
T[] array;

auto foo(T t)
{
for(int i = 0; i < array.length; i++)
{
if(comparer(this.array[i]) <=  comparer(t))
{
//do stuff
array[i] = t;
}
}
}
}
´´´

Re: Strange Thread Causing Duplicating `writeln`

[Jonathan via Digitalmars-d-learn]

On Tuesday, 10 April 2018 at 23:59:08 UTC, Steven Schveighoffer 
wrote:

On 4/9/18 6:56 PM, Jonathan wrote:

On Monday, 9 April 2018 at 22:53:31 UTC, Jonathan wrote:

On Monday, 9 April 2018 at 22:49:07 UTC, Cym13 wrote:
I don't know, but I can't reproduce either with dmd or ldc. 
What was your compilation line?


dmd -run file.d


I am on Window 10 btw.


It's a windows 32-bit issue (specifically, DMC's FILE *, upon 
which std.stdio.File is based, is thread unsafe).


Try -m64.

https://issues.dlang.org/show_bug.cgi?id=18483
http://bugzilla.digitalmars.com/issues/show_bug.cgi?id=327

-Steve


Hum, thank you.

[Issue 16206] traits getOverloads fails when one of the overload is a templatized function

[d-bugmail--- via Digitalmars-d-bugs]

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

johanenge...@weka.io changed:

   What|Removed |Added

   Keywords||industry
 CC||johanenge...@weka.io

--

Is using function() in templates possible at all?

[Sjoerd Nijboer via Digitalmars-d-learn]

I am trying to do a binary insert into my sorted array.
To sort classes and structs I would like to give a delegate `(t) 
=> t.myValue` to sort on that value whitout having to implement 
an interface or specifically declare opCmp for every class I want 
to have sorted.
After all, I might want one group of objects of a given class 
sorted in one way and another group of objects sorted on another 
way depending on the usecase.
In C# this is done by passing on a lambda in for instance a LinQ 
expression to sort such list after insertion, and is also usefull 
in other circumstances.


But is it possible in D to do something simular but then pass on 
this Function() during compile time?


something like
`
void main() { SortedList!(Vector3, (v) => v.y) list; }

struct Vector3 { float x, y, z; }

class SortedList(T, int function(T) comparer)
{
T[] array;

int foo(T t)
{
for(int i = 0; i < array.lenght; i++)
{
if(comparer(this.otherT) <=  comparer(t))
{
//do stuff
array[i] = t;
}
}
}
}
`

Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted

[Dmitry Olshansky via Digitalmars-d-announce]

On Friday, 6 April 2018 at 12:26:36 UTC, Mike Parker wrote:
Congratulations to Zach Tollen and everyone who worked on DIP 
1009. It took a painful amount of time to get it through the 
process, but it had finally come out of the other side with an 
approval. The proposal itself was approved early on, but it 
needed quite a bit of revision to get to an acceptable final 
draft. The DIP in its final form:



https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1009.md


 What would have made contract trully powerful for me is them 
being emitted at caller side. This way if I use a release build 
of library but debugging my app I still get my stupidity guarded 
by contracts of the API. *


Now *that* would be marvelous. Otherwise having a debug build for 
each of libraries just to check my precondition is too much of 
drag I’d say. After all libraries are typically stable code that 
are (presumably) debugged and you want them to be fast.


* Templates kind of muddy the waters being conpiled with the 
flags of caller (another reason why they are a mess). Meaning 
they will work with contracts if caller choses to have debug 
build.

Re: #include C headers in D code

[Kagamin via Digitalmars-d-announce]

On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis 
wrote:
It's one thing for someone who is familiar with D to weigh the 
options and decide that being tied to ldc is okay. It's quite 
another to tell someone who isn't familiar with D that in order 
to use D, they have to use a feature which only works with a 
specific compiler that is not the reference compiler and which 
will likely never work with the reference compiler.


I'd say, you can focus on negative aspects if the auditory will 
analyze them, but it's a bad strategy if you only want to 
overcome prejudice.

Re: #include C headers in D code

[Kagamin via Digitalmars-d-announce]

On Wednesday, 11 April 2018 at 12:22:56 UTC, bachmeier wrote:
It also wouldn't work with GDC. Given that GDC has been added 
to GCC, it would be a bad idea to tell people they need to use 
LDC to work with C code.


Currently porting a project to linux, stuff is so severely 
outdated, pretty much no dependency was satisfied  by the distro, 
in wich case for D it would be better to install ldc just to not 
touch gdc :)
Granted, it's only a problem for active projects, but what 
projects are inactive?

Re: Migrating an existing more modern GC to D's gc.d

[Dmitry Olshansky via Digitalmars-d]

On Tuesday, 10 April 2018 at 07:22:14 UTC, David Bennett wrote:
On Tuesday, 10 April 2018 at 06:43:28 UTC, Dmitry Olshansky 
wrote:

On Tuesday, 10 April 2018 at 06:10:10 UTC, David Bennett wrote:
I was thinking about messing with the GC in my free time just 
yesterday... how hard would it be:


[snip]


Lost immutable and that thread-local is often casted to 
immutable, sometimes by compiler.

See assumeUnique and its ilk in Phobos.

Same with shared - it’s still often the case that you allocate 
thread-local then cast to shared.


People cast from thread local to shared? ...okay thats no 
fun...  :(


I can understand the other way, thats why i was leaning on the 
conservative side and putting more stuff in the global pools.


Well you might want to build something as thread-local and then 
publish as shared.



That is indeed something we should at some point have. Needs 
cooperation from the language such as explicit functions for 
shared<->local conversions that run-time is aware of.




So the language could (in theory) inject a __move_to_global(ref 
local, ref global) when casting to shared and the GC would need 
to update all the references in the local pages to point to the 
new global address?


I think it could be __to_shared(ptr, length) to let GC know that 
block should be added to global set of sorts. That will foobar 
the GC design quite a bit but to have per thread GCs I’d take 
that risk.


But then keeping in mind transitive nature of shared Maybe 
not ;)


Maybe it should work the other way around - keep all in global 
pool, and have per-thread ref-sets of some form. Tricky anyway.

Re: Is it a bug that a parent class that access its own private members from derived classes gets deprecation warning?

[bauss via Digitalmars-d]

On Wednesday, 11 April 2018 at 17:58:25 UTC, Jonathan M Davis 
wrote:
On Sunday, April 08, 2018 13:00:02 bauss via Digitalmars-d 
wrote:

[...]


I don't know. It could be argued either way. I think that the 
logic as to why


[...]


The thing is, it makes no sense why it shouldn't be legal since 
you can just cast to the base type, by that alone you're escaping 
the restriction that it's supposed to have.


And it really goes against that private is module level.

If it was module level then you should be able to access the 
member regardless of the reference to it.

Re: Mission impossible

[Kagamin via Digitalmars-d]

If it doesn't work, hack it:

struct S {
static void func(T)(uint a, T t) {
}

static void func1() {
}

alias func=func1;
}

Re: Is it a bug that a parent class that access its own private members from derived classes gets deprecation warning?

[Timon Gehr via Digitalmars-d]

On 11.04.2018 19:58, Jonathan M Davis wrote:

I don't know. It could be argued either way.


Not really. bauss is right about this.
https://en.wikipedia.org/wiki/Liskov_substitution_principle

Re: Release: nanovega.d rendering lib like html5 canvas

[drug via Digitalmars-d-announce]

11.04.2018 21:13, Adam D. Ruppe пишет:

On Wednesday, 11 April 2018 at 17:26:19 UTC, drug wrote:
That's it - 
https://github.com/drug007/nanogui/tree/interacting_with_checkbox


So MouseEvent is sent on mouse motion too, and redrawing on each motion 
might back up the queue.


Otherwise, nothing obvious jumps out at me so I might have to take a 
closer look later.

Yes, the reason was spamming events like a crazy, fixed.

Hospitals Depending On Telephone Interpretation Services to Communicate With Patients Speaking Different Languages

[markmst via Digitalmars-d-learn]

A healthcare facility called River's Edge Hospital and Clinic in 
Minnesota is using a special video interpretation service that 
can connect an interpreter with a patient through a video 
conference to offer necessary interpretation services.If the 
patient feels that there is an inadequacy in the interpretation 
services provided to them, they may complain about the hospital 
to the state Department of Human Rights.


It is a special video conference service that offers a convenient 
and affordable means to get in touch with an interpreter whose 
services could be needed only on certain occasions. Stephanie 
Holden, the CMO of the hospital said that the service was started 
at the hospital about a year ago.


She shared that her hospital has just migrated from phone to 
video. It has been a good change for them to have this special 
video service available. Both the patient and the healthcare 
providers can see the interpreter simultaneously. Holden feels 
that there is a greater value when the faces of the interpreters 
can be seen rather than just hearing their voices. She also added 
that the step taken by the hospital has fetched them positive 
reviews on the satisfaction surveys conducted on their patients.


On an average, the hospital uses this service about 5 to 10 times 
every month. Mostly, the patients in the emergency and urgent 
care department use this interpretation service. The hospital 
only uses those interpreters who are certified in healthcare 
interpretation services.


www.language-school.hk

Re: #include C headers in D code

[Walter Bright via Digitalmars-d-announce]

On 4/11/2018 3:25 AM, Atila Neves wrote:
I did the best I could having seen some macros. It's likely there are cases I've 
missed, or that maybe the translation in the link above doesn't work even for 
what it's supposed to be doing (I have no confidence about catching all the C 
casts for instance).


If there are other cases, I'll fix them as they're encountered. It's possible 
some of them can't be fixed and the user will have to work around them. Right 
now I have a feeling it will probably be ok. Time will tell (assuming I have 
users!).



That's right. There is no general solution. One can only look for common 
patterns and do those. For example,


  #define X 15

is a common pattern and can be reliably rewritten as:

  enum X = 15;

Re: Release: nanovega.d rendering lib like html5 canvas

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

On Wednesday, 11 April 2018 at 17:26:19 UTC, drug wrote:
That's it - 
https://github.com/drug007/nanogui/tree/interacting_with_checkbox


So MouseEvent is sent on mouse motion too, and redrawing on each 
motion might back up the queue.


Otherwise, nothing obvious jumps out at me so I might have to 
take a closer look later.

Re: Is it a bug that a parent class that access its own private members from derived classes gets deprecation warning?

[Jonathan M Davis via Digitalmars-d]

On Sunday, April 08, 2018 13:00:02 bauss via Digitalmars-d wrote:
> On Sunday, 8 April 2018 at 10:48:19 UTC, user1234 wrote:
> > On Saturday, 7 April 2018 at 20:46:39 UTC, bauss wrote:
> >> On Saturday, 7 April 2018 at 20:34:57 UTC, user1234 wrote:
> >>> On Saturday, 7 April 2018 at 20:14:49 UTC, bauss wrote:
>  jesus that became a long title.
> 
>  Anyway as the title says, is it a bug that a parent class
>  that access its own private members from derived classes
>  gets deprecation warning?
> >>>
> >>> If the import is selective no. (`import foo : Foo;`)
> >>> If the import is for the whole module i'd say yes. (`import
> >>> foo;`)
> >>
> >> What do you mean?
> >>
> >> The problem is that "Foo" cannot access "_baz" without
> >> deperecation warning, but "_baz" is a part of "Foo".
> >
> > _baz is private and not protected. The deprecation was
> > introduced because bug 314 broke the private protection.
>
> I think it's better demonstrated like this, because to me the
> behavior makes no sense.
>
> Especially since you can just cast "Bar" to "Foo" and then you're
> allowed to do it.
>
> Since we're inside Foo then it shouldn't care whether "_baz" is
> private or not.
>
> I could understand if the function was located within Bar, but
> it's not.
>
> It's perfectly normal in other languages that supports classes to
> access private members of parent's as long as you're within the
> parent's encapsulation.
>
> // a.d
> module a;
>
> class Foo
> {
>   private:
>   bool _baz;
>
>   public:
>   void handleBar(T : Foo)(T[] foos)
>   {
>   foreach (child; foos)
>   {
>   child._baz = true; // Not ok.
>   (cast(Foo)child)._baz = true; // Ok.
>   }
>   }
> }
>
> // b.d
> module b;
>
> import a;
>
> class Bar : Foo
> {
>
> }
>
> // main.d
>
> module main;
>
> import b;
>
> void main()
> {
>   auto bars = [new Bar, new Bar];
>   auto bar = new Bar;
>   bar.handleBar(bars);
> }

I don't know. It could be argued either way. I think that the logic as to
why

child._baz = true;

is not legal is because you're accessing it through a class reference that
does not have access to _baz, since it's private to the base class. Allowing
access to the base class member via a derived class reference arguably
violates private.

On the other hand, this is inside a member function of the base class, and
the base class has access to the private members - even if they're in an
object other than the current one. And by that logic, it should be legal to
access the base class member even though it's through a derived class
reference.

Usually, base classes don't handle any references for derived classes (they
may handle derived classes through base class references but not usually
through actual derived class references), and this sort of thing doesn't
come up. As such, I think that the obvious result would be the current
behavior regardless of whether that is actually the best behavior.

I suspect that this particular situation was never really thought through in
the implementation, but I don't know. And since I think that there are good
arguments in both directions, I really don't know whether the current
implementation is better or whether what you're trying to do should be
legal. Certainly, it seems like a valid enhancement request, though I have
no idea whether Walter would think that what you're trying to do should work
or not. I wouldn't be surprised either way.

- Jonathan M Davis

Re: Is it a bug that a parent class that access its own private members from derived classes gets deprecation warning?

[bauss via Digitalmars-d]

On Wednesday, 11 April 2018 at 17:20:23 UTC, martin wrote:

On Monday, 9 April 2018 at 17:16:56 UTC, bauss wrote:

On Monday, 9 April 2018 at 17:05:45 UTC, martin wrote:>>

Actually, this behaves as i would expect.
`_baz` is a private member of Foo (to be precise: it belongs 
to module `a`)

in handleBar(), you iterate `Bar[]` - which is in module `b`.
By casting it to Foo, you are accessing the wanted module 
(`a`) again.


but handleBar() is in a.

This behavior is allowed in ex. C#


`_baz` is a member of `module a : Foo` - `_baz`, as is 
`handleBar()`.

`protected` is the Access specifier you want.
If i understand you correctly, you want it to behave as  if 
`_baz` would be a member of `handleBar()`


If this is really possible in C#, it lets my eyebrow raise.


Execute the following C# program and it will work just fine:

It's a really common pattern with OOP.

public class Foo
{
private string _baz;

public void HandleBar(Bar bar)
{
bar._baz = "Hello";
}
}

public class Bar : Foo
{
}

...

var bar = new Bar();
bar.HandleBar(bar);

Re: Is it a bug that a parent class that access its own private members from derived classes gets deprecation warning?

[bauss via Digitalmars-d]

On Wednesday, 11 April 2018 at 17:34:40 UTC, bauss wrote:

On Wednesday, 11 April 2018 at 17:20:23 UTC, martin wrote:

On Monday, 9 April 2018 at 17:16:56 UTC, bauss wrote:

On Monday, 9 April 2018 at 17:05:45 UTC, martin wrote:>>

Actually, this behaves as i would expect.
`_baz` is a private member of Foo (to be precise: it belongs 
to module `a`)

in handleBar(), you iterate `Bar[]` - which is in module `b`.
By casting it to Foo, you are accessing the wanted module 
(`a`) again.


but handleBar() is in a.

This behavior is allowed in ex. C#


`_baz` is a member of `module a : Foo` - `_baz`, as is 
`handleBar()`.

`protected` is the Access specifier you want.
If i understand you correctly, you want it to behave as  if 
`_baz` would be a member of `handleBar()`


If this is really possible in C#, it lets my eyebrow raise.


Execute the following C# program and it will work just fine:

It's a really common pattern with OOP.

public class Foo
{
private string _baz;

public void HandleBar(Bar bar)
{
bar._baz = "Hello";
}
}

public class Bar : Foo
{
}

...

var bar = new Bar();
bar.HandleBar(bar);


Also protected is not the access modifier I want.

I only want to set it through the parent class and it should only 
be used within the parent class.


But it's on each child passed to the parent class that it's set.

The children should NEVER touch the variable.

Re: Release: nanovega.d rendering lib like html5 canvas

[drug via Digitalmars-d-announce]

11.04.2018 16:59, Adam D. Ruppe пишет:

On Saturday, 7 April 2018 at 09:13:06 UTC, drug wrote:

https://github.com/drug007/nanogui

I would be glad if you take a look


Do you have a complete example I can just compile and run to get started?


That's it - 
https://github.com/drug007/nanogui/tree/interacting_with_checkbox


Window, Label and Checkbox example + dragging (you can move Window)
But it lags, so definitely I use arsd.simpledisplay in a wrong way.

Re: Is it a bug that a parent class that access its own private members from derived classes gets deprecation warning?

[martin via Digitalmars-d]

On Monday, 9 April 2018 at 17:16:56 UTC, bauss wrote:

On Monday, 9 April 2018 at 17:05:45 UTC, martin wrote:>>

Actually, this behaves as i would expect.
`_baz` is a private member of Foo (to be precise: it belongs 
to module `a`)

in handleBar(), you iterate `Bar[]` - which is in module `b`.
By casting it to Foo, you are accessing the wanted module 
(`a`) again.


but handleBar() is in a.

This behavior is allowed in ex. C#


`_baz` is a member of `module a : Foo` - `_baz`, as is 
`handleBar()`.

`protected` is the Access specifier you want.
If i understand you correctly, you want it to behave as  if 
`_baz` would be a member of `handleBar()`


If this is really possible in C#, it lets my eyebrow raise.

Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted

[Zach Tollen via Digitalmars-d-announce]

On Wednesday, 11 April 2018 at 16:16:33 UTC, Jonathan M Davis 
wrote:
If we actually end up with a language improvement that makes it 
so that contracts are compiled in based on the caller instead 
of the callee, then I'll start using contracts. Until then, I'm 
not generally going to bother.


My first proposal suggested allowing the contracts at the top of 
the function body. If you mixed that idea with what H.S. Teoh 
later proposed, the result would have looked like:


int fun(int a) {
   in(a >= 0);
   out(r; r > 0);
   ...
}

It's not much different from if you did:

int fun(int a) {
   assert(a >= 0);
   typeof(return) result;
   scope(success) assert(result > 0);
   ...use `result`...
}

For anyone who wants even more convenience in how to write 
contracts this idea would still possible to add, although it's 
probably not that important.


But that idea received criticism on principle, that contracts are 
part of the signature and not the body. I didn't much care about 
the criticism myself, because I just wanted the contracts to be 
as ergonomic as possible so that people would use them. They 
seemed like a feature of D whose syntax was not up to the same 
standards as the rest of D, whose syntax otherwise is a major 
selling point.


However, eventually I was convinced that the accepted proposal is 
better precisely because of the possibility of a future 
implementation where the caller checks rather than the callee. In 
this case the contracts *must* be in the signature, because the 
body could be missing altogether. So basically, I agree with H.S. 
Teoh. A future DIP which allows caller-side checking will be all 
about the implementation, rather than about the syntax, and may 
or may not face opposition precisely for that reason, I don't 
know. From the user's point of view it amounts to nothing more 
than being able to use contracts in more places, i.e. in 
precompiled code, and with better error messages that fault the 
caller instead of the callee. I don't feel technically qualified 
to write that DIP, but I'm glad that the current DIP is designed 
with that one in mind.

Re: Escaping address of

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, April 11, 2018 16:08:06 Nick Treleaven via Digitalmars-d-learn 
wrote:
> Is this a known bug? With v2.079.0, with or without -dip1000:
>
> @safe unittest
> {
>  struct S
>  {
>  int i;
>  }
>  auto p = ().i;
> }
>
> The address of field `i` should not escape, right? It's also
> incorrectly allowed when using an lvalue of S (when -dip1000 is
> not present).

Without -dip1000, @safe code specifically disallows & on local variables.
Beyond that, I'm not sure. Arguably, it should disallow it entirely, though
if the compiler can guarantee that the address is on the heap, then it's
probably fine. However, IMHO, regardless of @safe or DIP 1000, your example
should not be legal period. It's taking the address of the field of a
temporary, which is _never_ a valid thing to do, @safe or not. I guess that
the compiler isn't smart enough to figure out that that's what's going on,
since it's i itself that it's getting the address for and not the temporary
directly, but even if it can't be smart enough for some reason to figure out
that what's going on here is never okay, that & should still be @system,
since it's not taking the address of something on the heap.

- Jonathan M Davis

Re: DUB: Only fetch and cache packages in dub.json without running build

[Clinton via Digitalmars-d]

On Tuesday, 10 April 2018 at 15:31:41 UTC, John Colvin wrote:

On Tuesday, 10 April 2018 at 13:50:38 UTC, Clinton wrote:

[...]


As far as I understand it, `dub describe` fetches everything. 
Then you can cache `~/.dub/packages/`.


Alternatively you can do `dub describe --cache=local` to put 
the packages in the current directory. You could then use `dub 
add-path .` or add `--cache=local` to all future calls to use 
those locally fetched packages.


Even better:
% mkdir cache
% cd cache
% dub describe --root=../ --cache=local

and then either
% dub build --root=../ --cache=local
or
% dub add-path .
% cd ../
% dub build

which keeps things nice and clean


Just tried this on my CircleCI setup. Works perfectly! Thanks 
everyone!

Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted

[Jonathan M Davis via Digitalmars-d-announce]

On Wednesday, April 11, 2018 07:47:14 H. S. Teoh via Digitalmars-d-announce 
wrote:
> On Tue, Apr 10, 2018 at 11:43:00PM -0600, Jonathan M Davis via
> Digitalmars-d-announce wrote: [...]
>
> > IMHO, for contracts to be worth much outside of the inheritance case,
> > we'd need to do something like make it so that contracts are compiled
> > in based on whether the caller used -release or not rather than
> > whether the callee did.
>
> This is what should have been done in the first place, and I'd argue
> that this is the direction we should be going in. The current
> implementation of contracts greatly diminish their value, though
> personally I'd still use them because they convey intent better than
> just sticking a bunch of asserts at the top of the function body.
>
> > If that were done, then there would be real value in using contracts,
> > and I'd be a lot more excited about the new syntax. As it is, it seems
> > like a nice improvement that's ultimately pointless.
>
> [...]
>
> I consider this as a first step in improving DbC support in D.  The next
> step is to make it so that in-contracts are enforced on the caller's
> side rather than the callee's side.  IIRC, the original version of this
> DIP included something to this effect, but it was eventually taken off
> in order to stay more focused in scope so that the chances of acceptance
> would be higher.  But I hope that eventually a future DIP would address
> this more fundamental and important issue.

If we actually end up with a language improvement that makes it so that
contracts are compiled in based on the caller instead of the callee, then
I'll start using contracts. Until then, I'm not generally going to bother.

And that reminds me, I was considering putting together a DIP to fix the
situation with invariants and void initialization. Thanks to the fact that
opAssign checks the state of the object prior to assigning it, you basically
can't use invariants with anything that you would void initialize, which
means that I basically never use invariants, and unlike in and out
contracts, invariants are actually a huge boon when they're appropriate,
since they insert checks with _every_ public function call, which would be a
royal pain to do by hand. Because of this issue, I'd previously argued that
opAssign should not check the state of the object before assigning it, but
Walter rejected that, and in rare cases, you actually do care about the
state of the object before assigning it, so that makes some sense, but it's
a huge problem when void initialization gets involved. So, I was thinking
that maybe we should have a way to indicate at the call site that an
assignment should not call the invariant prior to calling opAssign in that
specific case. But I haven't gotten much past that in figuring it out, since
it's not all that high on my priority list. It's really annoying if you use
invariants, but my solution has been to just not use them, so it's a problem
but not one that actively gets in my way at the moment. It's just that I
then lose out on invariants. :|

- Jonathan M Davis

Escaping address of

[Nick Treleaven via Digitalmars-d-learn]

Is this a known bug? With v2.079.0, with or without -dip1000:

@safe unittest
{
struct S
{
int i;
}
auto p = ().i;
}

The address of field `i` should not escape, right? It's also 
incorrectly allowed when using an lvalue of S (when -dip1000 is 
not present).

Re: DUB: Only fetch and cache packages in dub.json without running build

[Clinton via Digitalmars-d]

On Tuesday, 10 April 2018 at 15:31:41 UTC, John Colvin wrote:

On Tuesday, 10 April 2018 at 13:50:38 UTC, Clinton wrote:

[...]


As far as I understand it, `dub describe` fetches everything. 
Then you can cache `~/.dub/packages/`.


Alternatively you can do `dub describe --cache=local` to put 
the packages in the current directory. You could then use `dub 
add-path .` or add `--cache=local` to all future calls to use 
those locally fetched packages.


Even better:
% mkdir cache
% cd cache
% dub describe --root=../ --cache=local

and then either
% dub build --root=../ --cache=local
or
% dub add-path .
% cd ../
% dub build

which keeps things nice and clean


Wow, this is helpful! I thought describe only showed which 
packages were currently cached or just output based on the 
dub.json. I'm going to try this out.

Re: Parse .eml files

[Martin Tschierschke via Digitalmars-d-learn]

On Wednesday, 11 April 2018 at 02:37:39 UTC, bachmeier wrote:

On Monday, 9 April 2018 at 19:17:20 UTC, Adam D. Ruppe wrote:

[...]

I had a chance to try this out and it worked without a problem. 
I did have to download color.d in addition to the other 
dependencies you listed. In the event that Google brings 
someone here, this is a complete working program:


import std.file, std.stdio, std.string;
import arsd.email;

void main(string[] args) {
  string[] f = std.file.readText(args[1]).splitLines();
  auto em = new IncomingEmailMessage(f);
  writeln("From: ", em.from);
  writeln("To: ", em.to);
  writeln("Subject: ", em.subject);
  writeln(em.textMessageBody);
}

Compile with

dmd *.d -ofreademail

And run

./reademail 'email message.eml'


Very cool, I was looking for something similar, thank you both 
for sharing!


My goal is to store mails in a mysql table with fulltext index, 
connected to a existing old crm solution via the email address as 
a foreign key.


My question in the moment is, how do I invoke Thunderbird to 
display a certain single mail (or maildir) file?
How do I use Thunderbird as the client, to show, to answer or to 
forward these mails.
An alternative would be to use a browser based mailer? Handling 
all attachments is an other purpose.

[Issue 7443] Better diagnostic on wrongly written static constructor

[d-bugmail--- via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #2 from RazvanN  ---
PR : https://github.com/dlang/dmd/pull/8164

--

Re: #include C headers in D code

[rumbu via Digitalmars-d-announce]

On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
Here's my blog post about my project that allows directly 
#including C headers in D*


https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/


Cannot manage to build it on Windows:

D:\git\dpp>dub build
WARNING: A deprecated branch based version specification is used 
for the dependency libclang. Please use numbered versions 
instead. Also note that you can still use the dub.selections.json 
file to override a certain dependency to use a branch instead.

Performing "debug" build using dmd for x86.
libclang ~master: target for configuration "library" is up to 
date.
dpp 0.0.1+commit.41.g60f98e4: building configuration 
"executable"...

Linking...
OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Warning 183: Extension not .RES : clang.lib
C:\Users\[]\AppData\Roaming\dub\packages\libclang-master\libclang\.dub\build\library-debug-windows-x86-dmd_2079-78261F5A299D700FEEC2C0E7B51191C1\libclang.lib(1)
 : Error 52: .DEF Syntax Error


D:\git\dpp>dub build --arch=x86_64
WARNING: A deprecated branch based version specification is used 
for the dependency libclang. Please use numbered versions 
instead. Also note that you can still use the dub.selections.json 
file to override a certain dependency to use a branch instead.

Performing "debug" build using dmd for x86_64.
libclang ~master: target for configuration "library" is up to 
date.
dpp 0.0.1+commit.41.g60f98e4: building configuration 
"executable"...

Linking...
LINK : fatal error LNK1104: cannot open file 'clang.lib'
Error: linker exited with status 1104
dmd failed with exit code 1.

Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted

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

On Wed, Apr 11, 2018 at 05:23:58AM +, really? via Digitalmars-d-announce 
wrote:
> On Friday, 6 April 2018 at 17:36:20 UTC, H. S. Teoh wrote:
> > 
> > Yeah, I think having expression syntax will make contracts more
> > readable.  We'll just have to see.
> > 
> 
> Sorry, but I fail to see how (1) is more readable than (2)
> 
> (1)
> in(s.length > 0, "s must not be empty")
> 
> (2)
> in { assert(s.length > 0, "s must not be empty"); }
> 
> 
> In (1) The assert .. is removed.
> In (1) The scope indicators {} .. are removed.
> In (1) The semicolon..is removed.
> 
> Removing all these things equates to being more readable??
> 
> Sure, it makes it more concise, but more readable??

Yes, because it removes unnecessary syntactical noise from the line. All
of that verbose baggage -- braces, "assert", semicolons, is just
needless syntactic boilerplate that's repeated verbatim every single
time you write a contract, and all for what? Just to express a contract
consisting of a single, simple expression.

Besides, the `keyword(expression)` syntax has precedence in signature
constraints:

auto myFunc(Args)(Args...)
if (Args.length == 2)   // <---
...

So now to add a contract:

auto myFunc(Args)(Args...)
if (Args.length == 2)
in (Args[0] < 100)  // consistent with sig constraint syntax
...


> I assert that it does not. But now..do I use the assert keyword.. or
> not? Do I end with semicolon..or not??
> 
> This just removes things that are still needed elsewhere in your code,
> but now... you have to remember that sometimes you need those things,
> and sometimes you don't.
[...]

It's no different from needing to "remember" that the condition of an
if-statement does not require {} and semicolons.  According to your
logic, for consistency's sake we should start writing if-statements like
this instead:

if {
assert(myCondition == true);
assert(myOtherCondition == false);
} then {
...
}

I wouldn't say it's less readable, but again, needless boilerplate.  If
you love so much boilerplate, perhaps Java may be a better language for
you.


T

-- 
Lottery: tax on the stupid. -- Slashdotter

Re: Infer return type from assignment

[ixid via Digitalmars-d-learn]

On Wednesday, 11 April 2018 at 14:33:06 UTC, Adam D. Ruppe wrote:

On Wednesday, 11 April 2018 at 14:26:53 UTC, ixid wrote:
Is it possible to infer a template's return type from what 
it's assigned to? If not is this a difficult or worthless 
feature to add?


Not really. The function call needs to make sense by itself:

fun(a)

needs to be a complete thing for a lot of things in the 
language to work. Type checking assumes it is there, inference 
assumes it is there, overloading assumes it s there, etc.


void foo(int);
void foo(float);

foo(fun(a)); // what happens?


So I don't say anything is impossible that isn't a paradox... 
but the effort level to solve all these problems would be 
really high for D.


I am sure there are all sorts of thorns involved but for your 
example a somewhat arbitrarily defined fallback hierarchy of 
types from most complex to most simple, with it matching the most 
'simple' that it can.

Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted

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

On Tue, Apr 10, 2018 at 11:43:00PM -0600, Jonathan M Davis via 
Digitalmars-d-announce wrote:
[...]
> IMHO, for contracts to be worth much outside of the inheritance case,
> we'd need to do something like make it so that contracts are compiled
> in based on whether the caller used -release or not rather than
> whether the callee did.

This is what should have been done in the first place, and I'd argue
that this is the direction we should be going in. The current
implementation of contracts greatly diminish their value, though
personally I'd still use them because they convey intent better than
just sticking a bunch of asserts at the top of the function body.


> If that were done, then there would be real value in using contracts,
> and I'd be a lot more excited about the new syntax. As it is, it seems
> like a nice improvement that's ultimately pointless.
[...]

I consider this as a first step in improving DbC support in D.  The next
step is to make it so that in-contracts are enforced on the caller's
side rather than the callee's side.  IIRC, the original version of this
DIP included something to this effect, but it was eventually taken off
in order to stay more focused in scope so that the chances of acceptance
would be higher.  But I hope that eventually a future DIP would address
this more fundamental and important issue.


T

-- 
Shin: (n.) A device for finding furniture in the dark.

Re: #include C headers in D code

[Jacob Carlborg via Digitalmars-d-announce]

On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
Here's my blog post about my project that allows directly 
#including C headers in D*


I don't know the exact details of your project but can't you just:

1. Copy the includes
2. Paste them into a C file
3. Run DStep on the C file
4. Replace the includes in the first file with the result from 
DStep


This would require changing DStep to always return `false` here 
[1]. Or perhaps run the preprocessor to expand the includes and 
then run DStep.


[1] 
https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L326


--
/Jacob Carlborg

Re: Infer return type from assignment

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

On Wednesday, 11 April 2018 at 14:26:53 UTC, ixid wrote:
Is it possible to infer a template's return type from what it's 
assigned to? If not is this a difficult or worthless feature to 
add?


Not really. The function call needs to make sense by itself:

fun(a)

needs to be a complete thing for a lot of things in the language 
to work. Type checking assumes it is there, inference assumes it 
is there, overloading assumes it s there, etc.


void foo(int);
void foo(float);

foo(fun(a)); // what happens?


So I don't say anything is impossible that isn't a paradox... but 
the effort level to solve all these problems would be really high 
for D.

Re: #include C headers in D code

[Jacob Carlborg via Digitalmars-d-announce]

On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
Here's my blog post about my project that allows directly 
#including C headers in D*


BTW, you can steal the config script [1] from DStep to help 
detect locations of LLVM/libclang. It also supports static 
linking. Supports manually specifying the path to LLVM if needed.


[1] 
https://github.com/jacob-carlborg/dstep/blob/master/configure.d


--
/Jacob Carlborg

Infer return type from assignment

[ixid via Digitalmars-d-learn]

Is it possible to infer a template's return type from what it's 
assigned to? If not is this a difficult or worthless feature to 
add?


OUT fun(IN, OUT)(IN value) {
return value.to!OUT;
}

void main() {
float a = 5.0;
int b = fun(a);
}

Re: Release: nanovega.d rendering lib like html5 canvas

[drug via Digitalmars-d-announce]

11.04.2018 16:59, Adam D. Ruppe пишет:


Do you have a complete example I can just compile and run to get started?


Yes, but it needs to be pushed. I've ported Window, Widget, Label and 
Checkbox (may be something else) and interacting by means of mouse 
(clicking, motion and dragging). But it has lags and I need your advice. 
I'll push it in 4-5 hours.

Re: [OT] gdc status

[Daniel Kozak via Digitalmars-d-announce]

AFAIK, GDC does not make it, so hopefully it will be merge with gcc 9

On Wed, Apr 11, 2018 at 3:44 PM, drug via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> 11.04.2018 16:26, Uknown пишет:
>
> On Wednesday, 11 April 2018 at 13:17:23 UTC, drug wrote:
>>
>>> 11.04.2018 15:22, bachmeier пишет:
>>>
 On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote:
 ... Given that GDC has been added to GCC...

>>> Is it true? I don't see anything like that here
>>> https://gcc.gnu.org/gcc-8/changes.html
>>>
>>
>> Here's relevant news from Phoronix:
>>
>> https://www.phoronix.com/scan.php?page=news_item=D-Frontend-For-GCC
>>
>> Here's the relevant announcement:
>> https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html
>>
> I've read it. Unfortunately it doesn't answer my question. I've heard
> there were some problems.
>

Re: Release: nanovega.d rendering lib like html5 canvas

[drug via Digitalmars-d-announce]

11.04.2018 16:30, bauss пишет:

The documentation should probably be updated to match ddoc.


Sure, of course, but it has low priority now. It is just proof of 
concept. First of all I'm interested in estimation of changes I've made. 
For example I'm trying to keep const qualifier as most as possible and 
either I use passing by value (most of all) or change api to allow using 
const qualifier on D side too (in fact one time). Is it worth effort, 
has it some caveats?

Re: Release: nanovega.d rendering lib like html5 canvas

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

On Saturday, 7 April 2018 at 09:13:06 UTC, drug wrote:

https://github.com/drug007/nanogui

I would be glad if you take a look


Do you have a complete example I can just compile and run to get 
started?

Re: [OT] gdc status

[drug via Digitalmars-d-announce]

11.04.2018 16:26, Uknown пишет:

On Wednesday, 11 April 2018 at 13:17:23 UTC, drug wrote:

11.04.2018 15:22, bachmeier пишет:

On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote:
... Given that GDC has been added to GCC...
Is it true? I don't see anything like that here 
https://gcc.gnu.org/gcc-8/changes.html


Here's relevant news from Phoronix:

https://www.phoronix.com/scan.php?page=news_item=D-Frontend-For-GCC

Here's the relevant announcement:
https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html
I've read it. Unfortunately it doesn't answer my question. I've heard 
there were some problems.

Re: Release: nanovega.d rendering lib like html5 canvas

[bauss via Digitalmars-d-announce]

On Saturday, 7 April 2018 at 09:13:06 UTC, drug wrote:

https://github.com/drug007/nanogui

I would be glad if you take a look


The documentation should probably be updated to match ddoc.

Re: [OT] gdc status

[Uknown via Digitalmars-d-announce]

On Wednesday, 11 April 2018 at 13:17:23 UTC, drug wrote:

11.04.2018 15:22, bachmeier пишет:
On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis 
wrote:

... Given that GDC has been added to GCC...
Is it true? I don't see anything like that here 
https://gcc.gnu.org/gcc-8/changes.html


Here's relevant news from Phoronix:

https://www.phoronix.com/scan.php?page=news_item=D-Frontend-For-GCC

Here's the relevant announcement:
https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html

[OT] gdc status

[drug via Digitalmars-d-announce]

11.04.2018 15:22, bachmeier пишет:

On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote:
... Given that GDC has been added to GCC...
Is it true? I don't see anything like that here 
https://gcc.gnu.org/gcc-8/changes.html

Re: I used to be able to use a bffer for toUTF operation, what happened ?

[Vladimir Panteleev via Digitalmars-d]

On Wednesday, 11 April 2018 at 12:04:24 UTC, deadalnix wrote:

This used to be an option:

dchar val = ...;
char[4] buf;
toUTF8(buf, val);

Now I'm getting an error.


This std.utf.toUTF8 overload was deprecated in 2.074.0 and 
finally removed in 2.077.0:


https://run.dlang.io/is/O57AGU (click Run)

Do you have deprecation messages turned on?

Re: #include C headers in D code

[bachmeier via Digitalmars-d-announce]

On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis 
wrote:


It's one thing for someone who is familiar with D to weigh the 
options and decide that being tied to ldc is okay. It's quite 
another to tell someone who isn't familiar with D that in order 
to use D, they have to use a feature which only works with a 
specific compiler that is not the reference compiler and which 
will likely never work with the reference compiler.


It also wouldn't work with GDC. Given that GDC has been added to 
GCC, it would be a bad idea to tell people they need to use LDC 
to work with C code.

Re: I used to be able to use a bffer for toUTF operation, what happened ?

[John Colvin via Digitalmars-d]

On Wednesday, 11 April 2018 at 12:04:24 UTC, deadalnix wrote:

This used to be an option:

dchar val = ...;
char[4] buf;
toUTF8(buf, val);

Now I'm getting an error. Looking at the doc, it seems that 
there are only option returning a string, which I assume is 
allocated on the GC. Has the function moved somewhere else ? If 
not, what's going on ?


std.utf.encode ?

I used to be able to use a bffer for toUTF operation, what happened ?

[deadalnix via Digitalmars-d]

This used to be an option:

dchar val = ...;
char[4] buf;
toUTF8(buf, val);

Now I'm getting an error. Looking at the doc, it seems that there 
are only option returning a string, which I assume is allocated 
on the GC. Has the function moved somewhere else ? If not, what's 
going on ?

Re: Deprecating this(this)

[Nick Treleaven via Digitalmars-d]

On Thursday, 5 April 2018 at 18:46:25 UTC, H. S. Teoh wrote:

I like this idea.  Except the syntax could be improved:

this(this orig) // <-- N.B.
{


It's already valid syntax, equivalent to `this(typeof(this) 
orig)`. It can be called explicitly, but is ignored for implicit 
construction. Perhaps we will just enable `this(typeof(this) 
orig)` for implicit construction too, if there's no postblit 
defined.

[Issue 18712] [Reg 2.072] bogus "switch skips declaration" error with case in mixin

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from Martin Nowak  ---
Also see issue 16254

--

[Issue 18712] [Reg 2.072] bogus "switch skips declaration" error with case in mixin

[d-bugmail--- via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu
Summary|bogus "switch skips |[Reg 2.072] bogus "switch
   |declaration" error with |skips declaration" error
   |case in mixin   |with case in mixin
 OS|Windows |All

--- Comment #1 from Martin Nowak  ---
Digger says https://github.com/dlang/dmd/pull/5869.

And btw yes, deprecation warnings should be deduplicated before printing, maybe
simply by hashing the error and the source code location.

--

Re: d2sqlite3 db.run, where lies the bug?

[ag0aep6g via Digitalmars-d]

On 04/11/2018 04:08 AM, Ralph Amissah wrote:

Generous, I merely stumbled on it and shouted out, you fixed it. I would be
grateful if you please file the bug and your fix.


There you go: https://github.com/biozic/d2sqlite3/pull/43

[Issue 14909] Template argument of std.algorithm.iteration.chunkBy cannot access a local variable

[d-bugmail--- via Digitalmars-d-bugs]

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com
Summary|Template argument of|Template argument of
   |std.algoirthm.iteration.chu |std.algorithm.iteration.chu
   |nkBy cannot access a local  |nkBy cannot access a local
   |variable|variable

--

Re: code-d 0.17.0 + serve-d 0.1.2

[Laurent Tréguier via Digitalmars-d-announce]

On Tuesday, 10 April 2018 at 14:00:49 UTC, WebFreak001 wrote:

What about workspaces?

Multi workspaces in vscode aren't implemented yet though.


By multi workspaces, do you mean a multi-root workspace ? If so, 
multi-roots arrived with LSP 3.6.0 / vscode-languageclient 3.4.0 
(if you meant something else then nevermind this comment)

Re: #include C headers in D code

[Atila Neves via Digitalmars-d-announce]

On Wednesday, 11 April 2018 at 06:24:38 UTC, Jacob Carlborg wrote:

On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
Here's my blog post about my project that allows directly 
#including C headers in D*


https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/


How do you deal with macros containing invalid D code, i.e. 
`#define foo(T) sizeof(T)`?


https://github.com/atilaneves/dpp/issues/22
https://github.com/atilaneves/dpp/blob/60f98e4fee2fac0117ac430216ef9c5c25c511fe/tests/issues.d#L229
https://github.com/atilaneves/dpp/blob/60f98e4fee2fac0117ac430216ef9c5c25c511fe/source/dpp/cursor/macro_.d#L55

I did the best I could having seen some macros. It's likely there 
are cases I've missed, or that maybe the translation in the link 
above doesn't work even for what it's supposed to be doing (I 
have no confidence about catching all the C casts for instance).


If there are other cases, I'll fix them as they're encountered. 
It's possible some of them can't be fixed and the user will have 
to work around them. Right now I have a feeling it will probably 
be ok. Time will tell (assuming I have users!).

[Issue 18753] chunkBy compile error causes ICE

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #1 from RazvanN  ---
PR : https://github.com/dlang/dmd/pull/8161

--

Re: #include C headers in D code

[Atila Neves via Digitalmars-d-announce]

On Wednesday, 11 April 2018 at 06:21:47 UTC, Jacob Carlborg wrote:

On Tuesday, 10 April 2018 at 23:44:46 UTC, Atila Neves wrote:

The beauty of using libclang is that name mangling issues 
don't exist. :)


How is that not going to be an issue? Are you adding 
`pragma(mangle)` everywhere?


Yes.

I don't know how to deal with class templates yet though, since 
none of their member functions have mangled symbols until they're 
instantiated. Which obviously doesn't happen at the declaration.

Re: #include C headers in D code

[Atila Neves via Digitalmars-d-announce]

On Wednesday, 11 April 2018 at 06:12:49 UTC, rikki cattermole 
wrote:

On 09/04/2018 11:03 PM, Atila Neves wrote:
Here's my blog post about my project that allows directly 
#including C headers in D*


https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/


The summary is that, modulo bugs, things like this work:

     #include 
     void main() { printf("Hello world\n".ptr); }

So far it's successfully compiled whilst #including pthread, 
libcurl, openssl and others. The blog and the github README 
have more information, and feel free to reply to this with 
questions.


dub: http://code.dlang.org/packages/dpp
reddit: 
https://www.reddit.com/r/programming/comments/8axj53/include_c_headers_in_d_code/


hacker news: It's in there somewhere, search around.

Atila

* Technically, "D + #include directives + C macros"


Any chance objectice-c as well?


I don't know Objective-C. The only way I can think of to even get 
close to getting it to work is by copying the relevant tests from 
dstep. I also don't think the language is nearly as important as 
C and C++ in terms of fostering D adoption.


So probably no unless someone sends PRs my way.

[Issue 18753] chunkBy compile error causes ICE

[d-bugmail--- via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com
   Assignee|nob...@puremagic.com|razvan.nitu1...@gmail.com

--

Re: #include C headers in D code

[Jonathan M Davis via Digitalmars-d-announce]

On Wednesday, April 11, 2018 09:23:29 Kagamin via Digitalmars-d-announce 
wrote:
> On Monday, 9 April 2018 at 19:36:23 UTC, Atila Neves wrote:
> > If you add to all that "No, really, it's ok, there's this
> > project that forked one of the compilers. No, it's not the
> > reference compiler. There's just this bit of non-standard
> > syntax to learn that's neither C nor D", then the chances of
> > convincing any "normal" engineer are 0.
>
> It is the reference compiler though (which is the frontend), the
> backend is different, but they don't want the dmc backend do
> they? Also recently it started to use pragma and import syntax,
> which are both D.

Yes, the frontend is shared, but you don't just use the frontend. You use
the whole compiler. dmd is the reference compiler and what your average
programmer coming to D is going to expect to be using (at least initially).
And telling folks that they have to use a language feature that is not
supported by the reference compiler is not going to go over well with a lot
of people. It would be one thing to tell them that they should use ldc,
because it generates faster code. That doesn't involve forking the language.
Your code would then still work just fine with dmd. It would just be slower.
It's quite another thing to tell them to use a feature that dmd doesn't
support. That _would_ be forking the language, and it would mean writing
programs that would not work with the reference compiler. Many folks are not
going to be happy with the idea of using a fork rather than the real deal.
Some folks will probably be fine with it, but in general, it just plain
looks bad.

It's one thing for someone who is familiar with D to weigh the options and
decide that being tied to ldc is okay. It's quite another to tell someone
who isn't familiar with D that in order to use D, they have to use a feature
which only works with a specific compiler that is not the reference compiler
and which will likely never work with the reference compiler.

- Jonathan M Davis

Re: #include C headers in D code

[Kagamin via Digitalmars-d-announce]

On Monday, 9 April 2018 at 19:36:23 UTC, Atila Neves wrote:
If you add to all that "No, really, it's ok, there's this 
project that forked one of the compilers. No, it's not the 
reference compiler. There's just this bit of non-standard 
syntax to learn that's neither C nor D", then the chances of 
convincing any "normal" engineer are 0.


It is the reference compiler though (which is the frontend), the 
backend is different, but they don't want the dmc backend do 
they? Also recently it started to use pragma and import syntax, 
which are both D.

Re: =void in struct definition

[Jonathan M Davis via Digitalmars-d]

On Wednesday, April 11, 2018 11:31:16 Shachar Shemesh via Digitalmars-d 
wrote:
> On 11/04/18 10:58, Jonathan M Davis wrote:
> > All objects are initialized with their init values prior to the
> > constructor being called. So, whether an object is simply
> > default-initialized or whether the constructor is called, you're going
> > to get the same behavior except for the fact that the constructor would
> > normally do further initialization beyond the init value. As such, if
> > there's a problem with the
> > default-initialized value, you're almost certainly going to get the same
> > problem when you call a constructor.
> >
> > - Jonathan M Davis
>
> That's horrible!
>
> That means that constructor initialized objects, regardless of size, get
> initialized twice.

Well, only the stuff you initialize in the constructor gets initialized
twice, but yeah, it could result in effectively initializing everything
twice if you initialize everything in the constructor. It's one of those
design choices that's geared towards correctness, since it avoids ever
dealing with the type having garbage, and the fact that you can do stuff
like

struct S
{
int _i;

this(int i)
{
foo();
_i = 42;
}

void foo()
{
writeln(_i);
}
}

means that if it doesn't initialize it with the init value first, then you
get undefined behavior, because _i would then be garbage when it's read
(which isn't necessarily a big deal with an int but could really matter if
it were something like a pointer). It also factors into how classes are
guaranteed to be fully initialized to the correct type _before_ any
constructors are run (avoiding the problems that you get in C++ when calling
virtual functions in constructors or destructors). Unfortunately, because
you're allowed to call arbitrary functions before initializing members, it's
also possible to violate the type system with regards to const or immutable.
e.g.

struct S
{
immutable int _i;

this(int i)
{
foo();
_i = 42;
}

void foo()
{
writeln(_i);
}
}

reads _i before it's fully initialized, so its state isn't identical every
time it's accessed like it's supposed to be. However, because the object is
default-initialized first, you never end up reading garbage, and the
behavior is completely deterministic even if it arguably violates the type
system. What the correct solution to that particular problem is, I don't
know (probably at least disallowing calling any member functions prior to
initializing any immutable or const members), but the fact that the object
is default-initialized first reduces the severity of the problem.

And while you can end up with portions of an object effectively being
initialized twice, for your average struct, I doubt that it matters much.
It's when you start doing stuff like having large static arrays that it
really becomes a problem. It also wouldn't surprise me if ldc optimized out
some of the double-initializations at least some of the time, but I very
much doubt that dmd's optimizer is ever that smart. Depending on the
implementation of the constructor though, I would think that it would be
possible for the compiler to determine that it doesn't actually need to
default-initialize the struct first (or that it can just default-initialize
pieces of it), because it can guarantee that a member variable isn't read
before it's initialized by the constructor. So, at least in theory, the
front end should be able to do some optimizations there. However, I have no
idea if it ever does.

I think that in theory, the idea is that we want initializion to be as
correct as possible, so there should be no garbage or undefined behavior
involved, and in the case of classes, the object should be fully the type
that it's supposed to be when its constructor is called so that you don't
get bad behavior from virtual functions, but we then have = void so that
specific variables can avoid that extra initialization cost when profiling
or whatnot show that it's important. So, if you have something like

struct S
{
int _a;
int[5000] _b;

this(int a)
{
_a = a;
}
}

then it's going to behave well as far as correctness goes, and then if the
initialization is too expensive, you do

S s = void;
s._a = 42;

I think that the problem is that void initialization was intended
specifically for local variables, and the idea of = void for member
variables was not really thought through. So, you can easily do something
like

S s = void;
s._a = 42;

right now and avoid the default-initialization, but you can't cleanly do

struct S
{
int _a;
int[5000] _b = void;

this(int a)
{
_a = a;
}
}

So, the process is completely manual, which obviously sucks if it's
something that you _always_ want to do with the type.

In general, D favors correctness over peformance with the idea that it gives
you backdoors to get around the correctness guarantees in order to get 

Re: Mission impossible

[Uknown via Digitalmars-d]

On Wednesday, 11 April 2018 at 08:59:36 UTC, Shachar Shemesh 
wrote:

On 11/04/18 11:51, Uknown wrote:

On Wednesday, 11 April 2018 at 08:47:12 UTC, Basile B. wrote:
On Wednesday, 11 April 2018 at 08:36:41 UTC, Shachar Shemesh 
[...]

What else is it?

Shachar


I thought there was a relevant rule about member templates, but 
there isn't any such thing. My bad

Re: Mission impossible

[rikki cattermole via Digitalmars-d]

On 11/04/2018 8:36 PM, Shachar Shemesh wrote:

struct S {
     static void func(T)(uint a, T t) {
     }

     static void func() {
     }
}

Your mission, Jim, should you choose to accept it, is this:

Get a pointer to the version of the function that accepts no arguments.

As always, should you or any of your Force be caught or killed, the 
Secretary will disavow any knowledge of your actions. This disc will 
self-destruct in ten seconds.


Good luck, Jim.


import std.stdio;
void main()
{
writeln("Hello D ", !(S, "func"));
wrapper!(S, "func");
}

struct S {
static void func(T)(uint a, T t) {
writeln("a");
}

static void func() {
writeln("b");
}
}

pragma(inline, true)
auto wrapper(T, string name, Args...)(Args args) {
mixin("return T." ~ name ~ "(args);");
}

Re: Mission impossible

[Shachar Shemesh via Digitalmars-d]

On 11/04/18 11:51, Uknown wrote:

On Wednesday, 11 April 2018 at 08:47:12 UTC, Basile B. wrote:

On Wednesday, 11 April 2018 at 08:36:41 UTC, Shachar Shemesh wrote:

struct S {
    static void func(T)(uint a, T t) {
    }

    static void func() {
    }
}

Your mission, Jim, should you choose to accept it, is this:

Get a pointer to the version of the function that accepts no arguments.

As always, should you or any of your Force be caught or killed, the 
Secretary will disavow any knowledge of your actions. This disc will 
self-destruct in ten seconds.


Good luck, Jim.


I suppose __traits(getOverloads) doesn't work because of a bug ?


The template hides any other overloads that func() has:


IF it is defined before it. If it is defined after it, it does not (but 
it is then possible that the non-template version hides the template one).


The problem is that S has two members called "func". One is a function, 
and the other is a template. "getOverloads" is not built to distinguish 
between the two.



I'm not sure if its a bug though


What else is it?

Shachar

Re: Mission impossible

[Uknown via Digitalmars-d]

On Wednesday, 11 April 2018 at 08:47:12 UTC, Basile B. wrote:
On Wednesday, 11 April 2018 at 08:36:41 UTC, Shachar Shemesh 
wrote:

struct S {
static void func(T)(uint a, T t) {
}

static void func() {
}
}

Your mission, Jim, should you choose to accept it, is this:

Get a pointer to the version of the function that accepts no 
arguments.


As always, should you or any of your Force be caught or 
killed, the Secretary will disavow any knowledge of your 
actions. This disc will self-destruct in ten seconds.


Good luck, Jim.


I suppose __traits(getOverloads) doesn't work because of a bug ?


The template hides any other overloads that func() has:

https://run.dlang.io/is/yMJXRz

I'm not sure if its a bug though

Re: Mission impossible

[Simen Kjærås via Digitalmars-d]

On Wednesday, 11 April 2018 at 08:47:12 UTC, Basile B. wrote:
On Wednesday, 11 April 2018 at 08:36:41 UTC, Shachar Shemesh 
wrote:

struct S {
static void func(T)(uint a, T t) {
}

static void func() {
}
}

Your mission, Jim, should you choose to accept it, is this:

Get a pointer to the version of the function that accepts no 
arguments.


As always, should you or any of your Force be caught or 
killed, the Secretary will disavow any knowledge of your 
actions. This disc will self-destruct in ten seconds.


Good luck, Jim.


I suppose __traits(getOverloads) doesn't work because of a bug ?


That'd be https://issues.dlang.org/show_bug.cgi?id=16206. Reorder 
the two functions, and it works.


--
  Simen

Re: Mission impossible

[Jonathan M Davis via Digitalmars-d]

On Wednesday, April 11, 2018 08:47:12 Basile B. via Digitalmars-d wrote:
> On Wednesday, 11 April 2018 at 08:36:41 UTC, Shachar Shemesh
>
> wrote:
> > struct S {
> >
> > static void func(T)(uint a, T t) {
> > }
> >
> > static void func() {
> > }
> >
> > }
> >
> > Your mission, Jim, should you choose to accept it, is this:
> >
> > Get a pointer to the version of the function that accepts no
> > arguments.
> >
> > As always, should you or any of your Force be caught or killed,
> > the Secretary will disavow any knowledge of your actions. This
> > disc will self-destruct in ten seconds.
> >
> > Good luck, Jim.
>
> I suppose __traits(getOverloads) doesn't work because of a bug ?

It looks like having the templated function makes it so that
__traits(getOverloads, ...) gives an empty AliasSeq. It's probably something
that got missed when it was made possible to overload templated functions
with non-templated functions.

- Jonathan M Davis

Re: Mission impossible

[Basile B. via Digitalmars-d]

On Wednesday, 11 April 2018 at 08:36:41 UTC, Shachar Shemesh 
wrote:

struct S {
static void func(T)(uint a, T t) {
}

static void func() {
}
}

Your mission, Jim, should you choose to accept it, is this:

Get a pointer to the version of the function that accepts no 
arguments.


As always, should you or any of your Force be caught or killed, 
the Secretary will disavow any knowledge of your actions. This 
disc will self-destruct in ten seconds.


Good luck, Jim.


I suppose __traits(getOverloads) doesn't work because of a bug ?

Mission impossible

[Shachar Shemesh via Digitalmars-d]

struct S {
static void func(T)(uint a, T t) {
}

static void func() {
}
}

Your mission, Jim, should you choose to accept it, is this:

Get a pointer to the version of the function that accepts no arguments.

As always, should you or any of your Force be caught or killed, the 
Secretary will disavow any knowledge of your actions. This disc will 
self-destruct in ten seconds.


Good luck, Jim.

Re: =void in struct definition

[Shachar Shemesh via Digitalmars-d]

On 11/04/18 10:58, Jonathan M Davis wrote:

All objects are initialized with their init values prior to the constructor
being called. So, whether an object is simply default-initialized or whether
the constructor is called, you're going to get the same behavior except for
the fact that the constructor would normally do further initialization
beyond the init value. As such, if there's a problem with the
default-initialized value, you're almost certainly going to get the same
problem when you call a constructor.

- Jonathan M Davis



That's horrible!

That means that constructor initialized objects, regardless of size, get 
initialized twice.


Shachar

Re: =void in struct definition

[Jonathan M Davis via Digitalmars-d]

On Wednesday, April 11, 2018 10:45:40 Shachar Shemesh via Digitalmars-d 
wrote:
> On 09/04/18 14:22, Jonathan M Davis wrote:
> > On Monday, April 09, 2018 14:06:50 Shachar Shemesh via Digitalmars-d 
wrote:
> >> struct S {
> >>
> >> int a;
> >> int[5000] arr = void;
> >>
> >> }
> >>
> >> void func() {
> >>
> >> S s;
> >>
> >> }
> >>
> >> During the s initialization, the entire "S" area is initialized,
> >> including the member arr which we asked to be = void.
> >>
> >> Is this a bug?
> >
> > It looks like Andrei created an issue about it as an enhancement request
> > several years ago:
> >
> > https://issues.dlang.org/show_bug.cgi?id=11331
> >
> > - Jonathan M Davis
>
> Except that issue talks about default constructed objects. My problem
> happens also with objects constructed with a constructor:
>
>
> extern(C) void func(ref S s);
>
> struct S {
>  uint a;
>  int[5000] arr = void;
>
>  this(uint val) {
>  a = val;
>  }
> }
>
> void main() {
>  auto s = S(12);
>
>  // To prevent the optimizer from optimizing s away
>  func(s);
> }
>
> $ ldc2 -c -O3 -g test.d
> $ objdump -S -r test.o | ddemangle > test.s
>
>  <_Dmain>:
>  }
> }
>
> void main() {
> 0:48 81 ec 28 4e 00 00sub$0x4e28,%rsp
> 7:48 8d 7c 24 04  lea0x4(%rsp),%rdi
>  auto s = S(12);
> c:31 f6   xor%esi,%esi
> e:ba 20 4e 00 00  mov$0x4e20,%edx
>13:e8 00 00 00 00  callq  18 <_Dmain+0x18>
>   14: R_X86_64_PLT32  memset-0x4
>  a = val;
>18:c7 04 24 0c 00 00 00movl   $0xc,(%rsp)
>1f:48 89 e7mov%rsp,%rdi
>
>  // To prevent the optimizer from optimizing s away
>  func(s);
>22:e8 00 00 00 00  callq  27 <_Dmain+0x27>
>   23: R_X86_64_PLT32  func-0x4
> }
>27:31 c0   xor%eax,%eax
>29:48 81 c4 28 4e 00 00add$0x4e28,%rsp
>30:c3  retq
>
>
> Notice the call to memset.
>
> Shachar

All objects are initialized with their init values prior to the constructor
being called. So, whether an object is simply default-initialized or whether
the constructor is called, you're going to get the same behavior except for
the fact that the constructor would normally do further initialization
beyond the init value. As such, if there's a problem with the
default-initialized value, you're almost certainly going to get the same
problem when you call a constructor.

- Jonathan M Davis

Re: =void in struct definition

[Shachar Shemesh via Digitalmars-d]

On 09/04/18 14:22, Jonathan M Davis wrote:

On Monday, April 09, 2018 14:06:50 Shachar Shemesh via Digitalmars-d wrote:

struct S {
int a;
int[5000] arr = void;
}

void func() {
S s;
}

During the s initialization, the entire "S" area is initialized,
including the member arr which we asked to be = void.

Is this a bug?


It looks like Andrei created an issue about it as an enhancement request
several years ago:

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

- Jonathan M Davis



Except that issue talks about default constructed objects. My problem 
happens also with objects constructed with a constructor:



extern(C) void func(ref S s);

struct S {
uint a;
int[5000] arr = void;

this(uint val) {
a = val;
}
}

void main() {
auto s = S(12);

// To prevent the optimizer from optimizing s away
func(s);
}

$ ldc2 -c -O3 -g test.d
$ objdump -S -r test.o | ddemangle > test.s

 <_Dmain>:
}
}

void main() {
   0:   48 81 ec 28 4e 00 00sub$0x4e28,%rsp
   7:   48 8d 7c 24 04  lea0x4(%rsp),%rdi
auto s = S(12);
   c:   31 f6   xor%esi,%esi
   e:   ba 20 4e 00 00  mov$0x4e20,%edx
  13:   e8 00 00 00 00  callq  18 <_Dmain+0x18>
14: R_X86_64_PLT32  memset-0x4
a = val;
  18:   c7 04 24 0c 00 00 00movl   $0xc,(%rsp)
  1f:   48 89 e7mov%rsp,%rdi

// To prevent the optimizer from optimizing s away
func(s);
  22:   e8 00 00 00 00  callq  27 <_Dmain+0x27>
23: R_X86_64_PLT32  func-0x4
}
  27:   31 c0   xor%eax,%eax
  29:   48 81 c4 28 4e 00 00add$0x4e28,%rsp
  30:   c3  retq


Notice the call to memset.

Shachar

[Issue 18698] static foreach + __traits(allMembers, moduleName)

[d-bugmail--- via Digitalmars-d-bugs]

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

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||simen.kja...@gmail.com

--- Comment #17 from Simen Kjaeraas  ---
As a workaround for now, you can use a string mixin:


import std.conv : to;
string create() {
string s = "";
static foreach (i, e; __traits(allMembers, mixin(__MODULE__))) {
s ~= "int n"~i.to!string~";";
}
return s;
}
mixin(create());
pragma(msg, __traits(allMembers, mixin(__MODULE__))); // tuple("object",
"create", "n0", "n1")


The root cause is, as Ketmar pointed out in comment #2, that
__traits(allMembers) tries to expand the static foreach, and the static foreach
calls __traits(allMembers), leading to unbounded mutual recursion and
eventually a stack overflow. The exact same issue occurs if a template mixin in
used in place of the string mixin in the above example.

This makes some sense - how can you iterate over all members when the list
isn't complete yet? For the sake of pragmatism though, it's probably sensible
to allow iteration of the incomplete list, and certainly having the compiler
crash is less than optimal.

--

Re: Migrating an existing more modern GC to D's gc.d

[Paulo Pinto via Digitalmars-d]

On Tuesday, 10 April 2018 at 18:31:28 UTC, Jacob Carlborg wrote:

On 2018-04-10 08:47, Jonathan M Davis wrote:

Regardless, I think that it's clear that in order to do 
anything with
thread-local pools, we'd have to lock down the type system 
even further to
disallow casts to or from shared or immutable, and that would 
really be a
big problem given the inherent restrictions on those types and 
how shared is

intended to be used.


Apple's GC for Objective-C (before it had ARC) was using 
thread-local pools. I wonder how they manged to do that in a 
language that doesn't have a type system that differentiates 
between TLS and shared memory.


They were doing it quite bad.

One of the reasons that always gets lost when discussing the 
merits of ARC over GC in Objective-C, is that Apple never managed 
to make the GC work without issues given its underlying C 
semantics.


So naturally having the compiler do what developers were already 
doing by hand with Framework derived classes was a safer way than 
ensuring Objective-C's GC would never crash.


Apple used to have a GC caveats document that was long taken down 
from their site.


This is one of the few surviving ones,

https://developer.apple.com/library/content/releasenotes/Cocoa/RN-ObjectiveC/#//apple_ref/doc/uid/TP40004309-CH1-DontLinkElementID_1

Re: Homebrew dmd betas

[Martin Nowak via Digitalmars-d-announce]

On Tuesday, 10 April 2018 at 08:46:55 UTC, John Colvin wrote:

Available now on homebrew :)


Thanks

I try to keep homebrew up to date with the latest betas, but 
the stats show that almost no-one ever downloads them, despite 
reasonable numbers getting the stable version. See for example 
https://github.com/Homebrew/homebrew-core/pull/24348#issuecomment-367021918 .


I will continue to keep adding the betas for my own use anyway, 
but please, PLEASE, install the betas and test them, it's so 
simple, just `brew upgrade dmd --devel`.


You can then switch freely between the beta and the stable 
versions with `brew switch dmd 2.079.0`, `brew switch dmd 
2.079.1-beta.1`.


And for all other supported platforms but Windows, just use

curl -fsS https://dlang.org/install.sh | bash -s dmd-beta

to unpack the beta to ~/dlang, and

source ~/dlang/dmd-2.079.1-beta.1/activate

to use the beta compiler.

Re: #include C headers in D code

[Jacob Carlborg via Digitalmars-d-announce]

On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
Here's my blog post about my project that allows directly 
#including C headers in D*


https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/


How do you deal with macros containing invalid D code, i.e. 
`#define foo(T) sizeof(T)`?


--
/Jacob Carlborg

Re: #include C headers in D code

[Jacob Carlborg via Digitalmars-d-announce]

On Tuesday, 10 April 2018 at 23:44:46 UTC, Atila Neves wrote:

The beauty of using libclang is that name mangling issues don't 
exist. :)


How is that not going to be an issue? Are you adding 
`pragma(mangle)` everywhere?


--
/Jacob Carlborg

Re: #include C headers in D code

[rikki cattermole via Digitalmars-d-announce]

On 09/04/2018 11:03 PM, Atila Neves wrote:
Here's my blog post about my project that allows directly #including C 
headers in D*


https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/ 



The summary is that, modulo bugs, things like this work:

     #include 
     void main() { printf("Hello world\n".ptr); }

So far it's successfully compiled whilst #including pthread, libcurl, 
openssl and others. The blog and the github README have more 
information, and feel free to reply to this with questions.


dub: http://code.dlang.org/packages/dpp
reddit: 
https://www.reddit.com/r/programming/comments/8axj53/include_c_headers_in_d_code/ 


hacker news: It's in there somewhere, search around.

Atila

* Technically, "D + #include directives + C macros"


Any chance objectice-c as well?