Re: Modules

[rikki cattermole via Digitalmars-d-learn]

On 24/07/2016 2:28 PM, Rufus Smith wrote:

NM, ignore. Seems it was something else going on. Although, if you know
how how dmd resolves this stuff exactly, it would be nice to know. Does
it just use the module names regardless of path or does the path where
the module is located have any play(assuming they are properly passed to
the compiler).


My understanding is this:

1. For each file passed, use supplied module name
2. If an import is unknown look at each of the directories passed via -I 
and find it based upon a/b/c.d for module a.b.c;
3. For each file passed, if an import is unknown try to guess based upon 
paths


Of course rdmd adds another level of behavior on top and is mostly based 
upon the third one.


If in doubt, try using dub. It can show you all this without looking at 
code ;)

Re: Modules

[Rufus Smith via Digitalmars-d-learn]

NM, ignore. Seems it was something else going on. Although, if 
you know how how dmd resolves this stuff exactly, it would be 
nice to know. Does it just use the module names regardless of 
path or does the path where the module is located have any 
play(assuming they are properly passed to the compiler).

Modules

[Rufus Smith via Digitalmars-d-learn]

How do module names and actual folder paths relate?

For my own libraries, I use the file path as module name, more or 
less.


e.g.,

module foo.bar.x;

is in folder foo\bar.

I imported some external lib that has it's own layout, but I 
wanted to incorporate it in to my lib, so I stuck it in a sub 
folder. DMD complains though.


I can't change the source because that is brittle, but I don't 
want it to be sitting in Root because that is messy.



foo
   bar
  x
   baz
  y
  baz.d(package)


where y is the external lib I imported. It uses it's own layout 
scheme though.



I tried to use a package and import the modules as anyone would, 
then I could just import the package, but that doesn't work 
either.


module foo.baz;

public import y;


So, all I want to do is use someone elses d files and put them in 
a subdir without having to modify their files to get it to 
work(to be able to import them like anything else). Is this 
another impossibility?

Re: Cannot compare object.opEquals is not nogc

[Rufus Smith via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 22:48:07 UTC, Lodovico Giaretta 
wrote:

On Saturday, 23 July 2016 at 21:44:05 UTC, Rufus Smith wrote:
On Saturday, 23 July 2016 at 17:27:24 UTC, Lodovico Giaretta 
wrote:
- we trust what we are doing: e.g. we cannot mark a thing 
@nogc, but we know it is and the profiler confirms that no 
allocation happens, so we are happy; our aim is having code 
that doesn't freeze because of collections, and not marking 
code @nogc.


This is bad. It only creates a faulty foundation. The whole 
point of nogc is to enforce nogc behavior. If you don't use it 
your not enforcing anything and then things slip by only to 
create problems later. This mentality is completely wrong and 
leads to decay.


While you are right on this, we must be pragmatical: we 
currently do not enforce that pointers point to valid memory 
locations, that private members are not accessed outside the 
module with tricky arithmetics, we have tons of things that 
work by convention, because the compiler simply can't check 
them all and some are even intrinsically uncheckable. In this 
environment of "code by trust", @nogc is the least of the 
problems, also because, I insist, it can be checked with the 
profiler, or you can plug a custom GC to druntime that asserts 
every time you try to call its functions (work is being made to 
make the GC independent and pluggable).


This is exactly why we are discussing this right now, because 
someone decided that it was ok to ignore other use cases which 
eventually turn out to be quite important.


Well, I think that deciding that opXXX must always be @nogc, 
ignoring other use cases that may need the GC, is blatantly 
wrong. By asking that Object.opXXX be @nogc, you are making the 
error the error you said others made.


This just isn't right. What your saying is that because someone 
screwed up, we must live with the screw up and build everyone 
around the screw up. This mentality is why everyone is so screwed 
up in the first place, do you not see that?


And I think you really have a misconception about the GC vs nogc. 
One can rewrite GC code, such as an GC based opEquals, without 
limitations. They can allocate on the stack, use malloc and free 
when done, etc. opEquals generally doesn't have state. So you it 
is possible to around around. It's probably always possible to 
rewrite a GC opEquals to use nogc without too much difficulty.


BUT, it is impossible to use a GC opEquals in nogc code! This 
means there is no work around. What you claim is that we accept 
the impossiblity(which makes nogc useless) just to avoid having 
to rewrite some GC opEquals code. We can't rewrite the nogc side, 
it's set in stone. We are screwed from the start when we attempt 
to do nogc code because at some point we will have to do 
comparisons. It's the same problem with purity and any other 
transitive relationship.


All "workarounds" are just as limited because basically we added 
the relationship if A is nogc and A uses B, then B must be nogc. 
Yet, we start with B is GC. Hence we never ever have A use B, 
because A's can only use nogc.


To see it simpler, What if everything in D was GC based. All code 
was marked GC(even statements, types, etc). Do you agree that 
nogc would be absolutely useless? We couldn't build up anything 
because we couldn't include any code. This is the extreme case.


Conversely, if everything was built up using nogc, we could write 
GC based code just fine, could we not?


Therefore, claiming that we stay with GC based code just prevents 
using more and more nogc code. The more GC based code D gets, the 
less useful nogc gets and we are back were we started.


Since nogc is more critical in the foundational layers, as it 
affects everything built on it, all core features should be nogc. 
This way, the user isn't can decide when to break away from the 
GC code, which will only affect everything after that point.


This is a one way street, pretending it is two way only enriches 
the lawyers and eventually makes everyone unhappy. Making the D 
dependent on the GC was a mistake that many wasted man hours will 
go in to trying to unravel.  Trying to carry on this mistake just 
wastes more hours.


I understand that it is a mess, but it got that way from the 
mistake in the first place, not from trying to undo the 
mistake(which is illogical because there would be no nogc if 
there wasn't a gc in the first place).  I also understand that 
there is some desire to keep things "backwards compatible". This 
is also a mistake, not only does it prolong the pain and 
suffering but is irrational. 1. A fork can be made. Those people 
that have based their code on the GC can continue using an older 
version. Their code works at that point, does it not? So just 
stop going down that dead end path. They have what they need, 
it's not like they will lose anything(virtually nothing except in 
most cases). Moving in the correct direction is always better, 
regardless of 

Re: How to pause terminal in D on Linux?

[Zekereth via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 19:08:00 UTC, WhatMeWorry wrote:
What I thought would be trivial is becoming a nightmare. Can 
anybody set me straight.  Thanks in advance.


[...]


Use the getchar() function.

void pause(const string msg = "Press enter/return to continue...")
{
write(msg);
getchar();
}

Re: Expression template

[ketmar via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 23:36:40 UTC, Etranger wrote:
is there any good benchmarking lib like the #[bench] in rust 
that I can use ?)


dunno, i'm usually just using std.datetime.benchmark.

Re: Expression template

[ag0aep6g via Digitalmars-d-learn]

On 07/23/2016 01:05 PM, Etranger wrote:

1- Is there a cleaner way to do it ? I had to use struct because I want
every thing to happen at compile time and on the stack (without gc). And
I had to use string mixins because template mixin does not work the way
I tried to use it ( see the error last line).


To avoid the string mixin, you can let VecExpression take an alias of 
the mixin template (Vec_impl/VecSum_impl) and the list of arguments:



struct VecExpression(alias mixinTemplate, mixinArgs ...)
{
  mixin mixinTemplate!mixinArgs;
  VecSum!(typeof(this), VecExpression!RHS) opBinary
(string op, RHS ...)(ref VecExpression!RHS rhs)
  {
/* ... */
  }
}
/* ... */
alias Vec(int n) = VecExpression!(Vec_impl, n);
/* ... */
alias VecSum(E1, E2) = VecExpression!(VecSum_impl, E1, E2);



Instead of mixing the fields into VecExpression, you could mix opBinary 
into distinct Vec/VecSum structs:



mixin template opBinaryMixin()
{
  VecSum!(typeof(this), RHS) opBinary(string op, RHS)(ref RHS rhs)
  {
static if (op == "+") return typeof(return)(, );
  }
}

struct Vec(int n)
{
  double[n] elems;

  /* ... */

  mixin opBinaryMixin!();
}

struct VecSum(E1, E2)
{
  E1 * e1;
  E2 * e2;

  /* ... */

  mixin opBinaryMixin!();
}


A bit of type strictness is lost here, since opBinary accepts anything, 
not just Vec/VecSum. If that strictness is needed, you could check 
specifically for Vec/VecSum, or maybe mix in a little identifier along 
with opBinary and check for that.



You can also try std.typecons.scoped [1] to put classes on the stack. 
That would get around any kind of mixin.



[1] https://dlang.org/phobos/std_typecons.html#.scoped

Expression template

[Etranger via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 19:08:45 UTC, ketmar wrote:
2OP: sorry, i can barely read that code. this has nothing to do 
with your skills, it is the topic -- i've never seen clean lazy 
evaluation code. after all, this is a hack.


still, i think that such a library worth at least some work.

as for "is my code/approach is good enough", i know only two 
answers.

1. yes, 'cause it works.
2. no, 'cause it doesn't work.
so if your code works, it is good. ;-)

i mean that such hacks will be somewhat ugly anyway, so just 
write a brief explanation in comments and go on.


sorry, it is probably not what you wanted to hear... ;-)


Oh no thanks ;-) I came here specially to see if there is some 
well known technique that I didn't hear about (I searched allot 
before posting here). If there is no such technique than it is 
just more interesting to explore !


Thanks all for your answers !

I thinks I'll continue exploring the lazy evaluation path and 
keep looking if there is a cleaner way to do it.
I'll specifically try to adapt lazy evaluation to ndsilces and 
see if I can have tangible results with benchmarks (by the way is 
there any good benchmarking lib like the #[bench] in rust that I 
can use ?) and study mir like it was suggested by Seb. I'll be 
very happy if I could contribute something useful for the D 
community :)

Re: Cannot compare object.opEquals is not nogc

[Lodovico Giaretta via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 21:44:05 UTC, Rufus Smith wrote:
On Saturday, 23 July 2016 at 17:27:24 UTC, Lodovico Giaretta 
wrote:
- we trust what we are doing: e.g. we cannot mark a thing 
@nogc, but we know it is and the profiler confirms that no 
allocation happens, so we are happy; our aim is having code 
that doesn't freeze because of collections, and not marking 
code @nogc.


This is bad. It only creates a faulty foundation. The whole 
point of nogc is to enforce nogc behavior. If you don't use it 
your not enforcing anything and then things slip by only to 
create problems later. This mentality is completely wrong and 
leads to decay.


While you are right on this, we must be pragmatical: we currently 
do not enforce that pointers point to valid memory locations, 
that private members are not accessed outside the module with 
tricky arithmetics, we have tons of things that work by 
convention, because the compiler simply can't check them all and 
some are even intrinsically uncheckable. In this environment of 
"code by trust", @nogc is the least of the problems, also 
because, I insist, it can be checked with the profiler, or you 
can plug a custom GC to druntime that asserts every time you try 
to call its functions (work is being made to make the GC 
independent and pluggable).


This is exactly why we are discussing this right now, because 
someone decided that it was ok to ignore other use cases which 
eventually turn out to be quite important.


Well, I think that deciding that opXXX must always be @nogc, 
ignoring other use cases that may need the GC, is blatantly 
wrong. By asking that Object.opXXX be @nogc, you are making the 
error the error you said others made.

Re: Cannot compare object.opEquals is not nogc

[Lodovico Giaretta via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 21:44:05 UTC, Rufus Smith wrote:
Templates are not the end all be all. They don't allow for 
run-time polymorphism, which is an important aspect of software.


Ok, so you need runtime polymorphism. And you want it in @nogc 
code. That's not difficult. Just have the base class of your 
hierarchy declare its opXXX @nogc. This is possible, because 
non-@nogc functions can be overridden by @nogc ones (as logical). 
Now you can have your function accept parameters of your base 
class, and it will be @nogc. And without forcing every class of 
the D world to have opXXX @nogc.

I don't see why this wouldn't be enough...

Re: Cannot compare object.opEquals is not nogc

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, July 23, 2016 21:33:29 Rufus Smith via Digitalmars-d-learn wrote:
> I am trying to write some general code that works on arbitrary
> types. I need to compare, obviously, as that is relatively basic
> thing on objects.

That's part of of why attribute inferrence works on templates. That way, the
template isn't constrained with regards to which attributes it uses. If it
can be nothrow or @nogc or whatnot, then the compiler will infer it as such,
and it can be used in code that requires those attributes, but if the
template can't have those attributes with a particular set of template
arguments, then they won't be inferred, and the template will still work,
whereas if the attributes had been put on the template, it wouldn't.

Templates are straight-up the solution for dealing with an arbitrary mix
of attributes. Unfortunately, virtual functions are fundamentally
incompatible with templates, so even if the Object is fixed so that it
doesn't have opEquals, opCmp, toHash, and toString on it, the ones that are
declared on derived classes are still going to have to pick a set up
attributes and will restrict what further derived classed do. It's just that
the programmer will then have been able to choose those restrictions in
their base class rather than being forced by what druntime did with Object.
Classes and generic code really don't mix well and can't mix well when the
generic code needs to be part of the class instead of a free function.

- Jonathan M Davis

Re: Cannot compare object.opEquals is not nogc

[Rufus Smith via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 17:27:24 UTC, Lodovico Giaretta 
wrote:
On Saturday, 23 July 2016 at 17:04:42 UTC, Jonathan Marler 
wrote:
On Saturday, 23 July 2016 at 16:46:20 UTC, Jonathan Marler 
wrote:

[...]


Actually Im going to disagree with myself. This technique 
actually wouldn't work with virtual methods:)


I don't think we have the big problems with @nogc that people 
points out.


I mean, we cannot decide that specific methods or opXXX must 
always be @nogc. That's too restrictive.


So, what we need to do is:

- use templates: with them, we can have our algorithms be @safe 
when applied to @safe types, @nogc when applied to @nogc types, 
and so on; for example, instead of taking a specific delegate 
type, we shall always accept a generic type, and use traits to 
guarantee it is some delegate; in this way, we can accept @safe 
delegate and propagate @safety to our algorithm, or accept 
@system and have our algorithm usable in @system code; same 
with @nogc et al.


- when we use virtual methods, we are giving up all 
compiler-checked attributes; in this situation we have two 
options:
- we trust what we are doing: e.g. we cannot mark a thing 
@nogc, but we know it is and the profiler confirms that no 
allocation happens, so we are happy; our aim is having code 
that doesn't freeze because of collections, and not marking 
code @nogc.


This is bad. It only creates a faulty foundation. The whole point 
of nogc is to enforce nogc behavior. If you don't use it your not 
enforcing anything and then things slip by only to create 
problems later. This mentality is completely wrong and leads to 
decay. This is exactly why we are discussing this right now, 
because someone decided that it was ok to ignore other use cases 
which eventually turn out to be quite important.


If, say, D was built without the GC, then adding the GC would be 
much easier and more logical than what has been done, which is 
built with GC and trying to remove it.


- we must have @nogc (or @whatever): then we know we cannot 
use certain classes, because they are definitely @nogc; so we 
cast the objects we get to the classes/interfaces that we know 
are @nogc (and are marked as such), and then our code is @nogc; 
as you see, you don't need Object to have @nogc methods; you 
only need the specific classes you use have it; if you want to 
work on generic objects, and as such cannot do specific casts, 
then you should definitely be using templates.


The only real problems I found till now are:
- some things in Phobos that shall be @nogc are not; they shall 
be refactored to have that attribute (but this is not always 
easy and requires time)
- the interface IAllocator is mostly used with @nogc 
allocators, but cannot have the said attribute (as I explained 
above, it must not restrict the possibility of allocators); it 
shall have a sub-interface NoGCAllocator, so that code can 
accept a @nogc allocator parameter without using templates (of 
course templates are fine, and are what we use now, but if 
everyone uses templates, why have IAllocator in the first 
place? IMHO we must have or both or none).


Templates are not the end all be all. They don't allow for 
run-time polymorphism, which is an important aspect of software. 
What we should have is that when something is added or removed we 
are 100%(or close as we can get) that the feature is correct and 
causes no side effects. D's GC causes side effects because it was 
assumed that there would not be any.  Now the future is hear and 
it's up to us to try and unravel the mess the past created. It's 
always best to just do it right in the first place, it saves 
everyone from the headache.


DMD should probably be branched, and all GC stuff removed, then 
built back up to have the proper features that the GC version 
has. I think someone has essentially done this on their own, but 
never built it up to full capacity.

Re: Cannot compare object.opEquals is not nogc

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, July 23, 2016 11:25:02 Steven Schveighoffer via Digitalmars-d-
learn wrote:
> The real problem here is that there is a base method at all. We have
> been striving to remove it at some point, but it is very difficult due
> to all the legacy code which is written.
>
> Almost all the Object base methods need to be removed IMO. You can add
> them at a higher level if you need them, and then specify your
> requirements for derived classes.
>
> Including opHash, opCmp, toString, etc.

https://issues.dlang.org/show_bug.cgi?id=9769
https://issues.dlang.org/show_bug.cgi?id=9770
https://issues.dlang.org/show_bug.cgi?id=9771
https://issues.dlang.org/show_bug.cgi?id=9772

This PR would largely fix the opEquals problem (though it doesn't deal with
actually removing opEquals from Object, just making it so that you don't
need it):

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

However, it's just languished (probably because it's in druntime and not
terribly interesting). But actually removing opEquals and replacing the
others gets a lot more interesting (e.g. we have to finishing templatizing
the built-in AAs as one of the steps), so as critical as that PR is, it's
only one small step.

- Jonathan M Davis

Re: Cannot compare object.opEquals is not nogc

[Rufus Smith via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 17:23:37 UTC, Marco Leise wrote:

Am Sat, 23 Jul 2016 13:18:03 +
schrieb Rufus Smith :

Trying to compare a *ptr value with a value in nogc code 
results in the error:


Error: @nogc function '...' cannot call non-@nogc function
'object.opEquals'

Shouldn't object opEquals be marked?


The only situation that you can work around is if the 'object' 
is actually known to be one of your @nogc objects. Then you can 
simply downcast before calling opEquals.


It's certainly limiting, but just an artifact of OOP and I can 
assure you that making D usable without GC has been high on the 
priority list (for an community driven open-source project 
anyways). Phobos got reworked to get rid of unnecessary GC 
allocations and Andrei Alexandrescu contemplated making 
object's methods @nogc at one point.


If you need a restricted object hierarchy, you'll have to write 
a new "NoGcObject" base class. opEquals would still take 
"object", though you can avoid a dynamic cast by writing:


  (cast(NoGcObject)cast(void*)obj).someMethod();

The cast to void* prior to the downcast drops the class type 
information and a dynamic cast becomes a static cast.


I am trying to write some general code that works on arbitrary 
types. I need to compare, obviously, as that is relatively basic 
thing on objects.


About the only half-ass solution I can think of is to use 
introspection and require the type to support a nogc version of 
Equals. Of course, this only passes the buck.


The problem is, D was designed with GC in mind, which was flawed 
from the get go and now trying to undo the tangled mess leads to 
"We can't do that because it's not backwards compatible".  So one 
crack leads to another to another. From what I gather, this isn't 
just a problem with nogc but many "after the fact enhancements" 
that don't work the way they should because of lack of foresight 
on the designers of D.

Re: JSON Serialization with runtime filtering.

[yawniek via Digitalmars-d-learn]

On Friday, 22 July 2016 at 12:36:31 UTC, Alexander Milushev wrote:
I there any json serialization library which allow to make 
decision about ignoring fields in runtime? I trying to write 
rest client but server accept either 'cmd' or 'args' field for 
example and I need to find solution.


can you give an example? i'm not sure what you mean by "ignore at 
runtime"
if its simply ignoring fields of a struct then thats easily 
doable with https://github.com/tamediadigital/asdf

Re: DConf 2016 on YouTube

[burjui via Digitalmars-d-announce]

Excellent, thanks to all people involved! DConfs are my favourite 
conferences: great speakers and very interesting topics. I wish 
Adam Ruppe had a talk at this one, I absolutely love his 
presentation style and sense of humour.

Re: proposal: private module-level import for faster compilation

[Jacob Carlborg via Digitalmars-d]

On 2016-07-22 10:28, Dicebot wrote:


.. which naturally leads to watching about Benjamin DConf talk about
fixing "export" and that is where everything clicks together. Organizing
large projects as bunch of small static libraries per package and
defining public API of those via `export` (and not just public) would
achieve this topic goal and much more, all without changing the language.


How does this relate to templates? Or is the suggestion to now use 
templates on API boundaries?


--
/Jacob Carlborg

Re: Transform/Compile to C/CPP as a target

[Jacob Carlborg via Digitalmars-d-learn]

On 2016-07-23 14:27, ParticlePeter wrote:

Is there any kind of project or workflow that converts D (subset) to
C/CPP ?


No idea about the status but: 
https://github.com/adamdruppe/tools/blob/dtoh/dtoh.d


--
/Jacob Carlborg

Re: Expression template

[ketmar via Digitalmars-d-learn]

2OP: sorry, i can barely read that code. this has nothing to do 
with your skills, it is the topic -- i've never seen clean lazy 
evaluation code. after all, this is a hack.


still, i think that such a library worth at least some work.

as for "is my code/approach is good enough", i know only two 
answers.

1. yes, 'cause it works.
2. no, 'cause it doesn't work.
so if your code works, it is good. ;-)

i mean that such hacks will be somewhat ugly anyway, so just 
write a brief explanation in comments and go on.


sorry, it is probably not what you wanted to hear... ;-)

How to pause terminal in D on Linux?

[WhatMeWorry via Digitalmars-d-learn]

What I thought would be trivial is becoming a nightmare. Can 
anybody set me straight.  Thanks in advance.


void writeAndPause(string s)
{
writeln(s);
// writeln("Press any key to continue...");  // works fine on 
Windows
// executeShell("pause");// works fine on 
Windows


I tried the following read command and it works great in a Ubuntu 
shell:

read -rsp $'Press any key to continue...\n' -n 1 key

but when I put it in executeShell it doesn't pause and returns

executeShell(`read -rsp $'Press any key to continue...\n' -n 1 
key`);
executeShell("read -rsp $'Press any key to continue...\n' -n 1 
key");


returns /bin/sh: 1: read: Illegal option -s


I tried the spawnShell...

auto pid = spawnShell(`read -n1 -r -p "Press any key to 
continue..." key`);

wait(pid);

 returns  /bin/sh: 1: read: Illegal option -n
}

Re: Expression template

[ketmar via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 12:27:39 UTC, rikki cattermole wrote:
Either way I recommend you not worry about it. Compilers can be 
smart and dmd is mostly good enough in this department.


he has something to worry about. remember, this is scientific 
department, where ours 4x4 matrices are child's play. one removed 
temporary can save hours of calculations there.

[Issue 12918] Copying-constructing structs onto the heap

[via Digitalmars-d-bugs]

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

Thayne  changed:

   What|Removed |Added

 CC||astrotha...@gmail.com

--- Comment #4 from Thayne  ---
A workaround for this is to allocate a Foo then assign it to the struct.

struct Foo
{
int i;
}

void main()
{
auto f = Foo(5);
auto g = new Foo;
*g = f;
}

However, if the Foo struct has the default constructor disabled (@disable
this();) then this doesn't work, even if postblit isn't disabled. The only way
I can think of to get this to work in general would be something like this:

auto f= Foo(5);
auto g = cast(Foo*) (new ubyte[Foo.sizeof]).ptr;
*g = f;

which is pretty awkward.

--

[Issue 16312] "Error: Overlapping fields" caused by use of deprecated features in referred to fields

[via Digitalmars-d-bugs]

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

--- Comment #3 from Marco Leise  ---
I just got the overlapping fields error after a bunch of "undefined identifier"
errors. So it doesn't only happen after deprecated features are used. It
happens with both dmd 2.069 and 2.071.1 at least. Other compilers were not
tested.

--

Re: Cannot compare object.opEquals is not nogc

[Lodovico Giaretta via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 17:04:42 UTC, Jonathan Marler wrote:
On Saturday, 23 July 2016 at 16:46:20 UTC, Jonathan Marler 
wrote:

[...]


Actually Im going to disagree with myself. This technique 
actually wouldn't work with virtual methods:)


I don't think we have the big problems with @nogc that people 
points out.


I mean, we cannot decide that specific methods or opXXX must 
always be @nogc. That's too restrictive.


So, what we need to do is:

- use templates: with them, we can have our algorithms be @safe 
when applied to @safe types, @nogc when applied to @nogc types, 
and so on; for example, instead of taking a specific delegate 
type, we shall always accept a generic type, and use traits to 
guarantee it is some delegate; in this way, we can accept @safe 
delegate and propagate @safety to our algorithm, or accept 
@system and have our algorithm usable in @system code; same with 
@nogc et al.


- when we use virtual methods, we are giving up all 
compiler-checked attributes; in this situation we have two 
options:
- we trust what we are doing: e.g. we cannot mark a thing 
@nogc, but we know it is and the profiler confirms that no 
allocation happens, so we are happy; our aim is having code that 
doesn't freeze because of collections, and not marking code @nogc.
- we must have @nogc (or @whatever): then we know we cannot 
use certain classes, because they are definitely @nogc; so we 
cast the objects we get to the classes/interfaces that we know 
are @nogc (and are marked as such), and then our code is @nogc; 
as you see, you don't need Object to have @nogc methods; you only 
need the specific classes you use have it; if you want to work on 
generic objects, and as such cannot do specific casts, then you 
should definitely be using templates.


The only real problems I found till now are:
- some things in Phobos that shall be @nogc are not; they shall 
be refactored to have that attribute (but this is not always easy 
and requires time)
- the interface IAllocator is mostly used with @nogc allocators, 
but cannot have the said attribute (as I explained above, it must 
not restrict the possibility of allocators); it shall have a 
sub-interface NoGCAllocator, so that code can accept a @nogc 
allocator parameter without using templates (of course templates 
are fine, and are what we use now, but if everyone uses 
templates, why have IAllocator in the first place? IMHO we must 
have or both or none).

Re: Cannot compare object.opEquals is not nogc

[Marco Leise via Digitalmars-d-learn]

Am Sat, 23 Jul 2016 13:18:03 +
schrieb Rufus Smith :

> Trying to compare a *ptr value with a value in nogc code results 
> in the error:
> 
> Error: @nogc function '...' cannot call non-@nogc function 
> 'object.opEquals' 
> 
> Shouldn't object opEquals be marked?

The only situation that you can work around is if the 'object'
is actually known to be one of your @nogc objects. Then you
can simply downcast before calling opEquals.

It's certainly limiting, but just an artifact of OOP and I can
assure you that making D usable without GC has been high on
the priority list (for an community driven open-source project
anyways). Phobos got reworked to get rid of unnecessary GC
allocations and Andrei Alexandrescu contemplated making
object's methods @nogc at one point.

If you need a restricted object hierarchy, you'll have to
write a new "NoGcObject" base class. opEquals would still take
"object", though you can avoid a dynamic cast by writing:

  (cast(NoGcObject)cast(void*)obj).someMethod();

The cast to void* prior to the downcast drops the class type
information and a dynamic cast becomes a static cast.

-- 
Marco

Re: DConf Videos

[Marco Leise via Digitalmars-d]

Am Thu, 21 Jul 2016 23:04:11 +
schrieb sarn :

> On Thursday, 21 July 2016 at 13:45:28 UTC, Steven Schveighoffer 
> wrote:
> > On 6/6/16 6:40 AM, sarn wrote:  
> >> What's the best source of DConf videos at the moment?  Are 
> >> there are any
> >> edited versions released?
> >>
> >> I'd like to share some of my favourite talks.  
> >
> > They are starting to arrive! 
> > https://twitter.com/sociomantic/status/756101557163270144
> >
> > https://www.youtube.com/watch?v=DwoFb34bxAk
> >
> > Video looks awesome, nice job!
> >
> > -Steve  
> 
> Nice!  Thanks to everyone who put the work into making these 
> videos!

Finally in high resolution! Thanks for the uploads.

-- 
Marco

Re: Cannot compare object.opEquals is not nogc

[Jonathan Marler via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 16:46:20 UTC, Jonathan Marler wrote:

[...]


Actually Im going to disagree with myself. This technique 
actually wouldn't work with virtual methods:)

Re: Terminix Stable 1.2.0 Released

[Iain Buclaw via Digitalmars-d-announce]

On 23 July 2016 at 16:24, Matthias Klumpp via Digitalmars-d-announce
 wrote:
>
> 3) Making LDC available for more architectures, or making GDC support a
> higher version of the Phobos standard library and build shared libraries.
> At time, LDC is the better fit because of shared library support and higher
> Phobos version. Current D projects are hard to compile with GDC because of
> the latter reason.
> More architectures are not per-se essential, but would be awesome to have.
> This feature request summarizes the status of arch support for D in free
> compilers: https://github.com/ldc-developers/ldc/issues/1636
>

Well, as GDC is supporting the last C++ release, the only next logical
step would be to get bootstrapping from 2.068 to 2.071 or whatever
version of the frontend has sufficiently ironed out all compatibility
regressions.

This means that backporting compiler fixes and the standard library
from upstream is acceptably on the cards.  It's just that the
feature-set will remain the same as 2.068.

>
> 5) Have hardening supported for the D compilers:
> https://wiki.debian.org/HardeningWalkthrough
>

As per the wiki, if you use GDC then there's nothing for you to do.

Re: Cannot compare object.opEquals is not nogc

[Jonathan Marler via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 15:25:02 UTC, Steven Schveighoffer 
wrote:

On 7/23/16 10:53 AM, Rufus Smith wrote:
On Saturday, 23 July 2016 at 14:15:03 UTC, Lodovico Giaretta 
wrote:

On Saturday, 23 July 2016 at 13:18:03 UTC, Rufus Smith wrote:
Trying to compare a *ptr value with a value in nogc code 
results in

the error:

Error: @nogc function '...' cannot call non-@nogc function
'object.opEquals'

Shouldn't object opEquals be marked?


If object.opEquals is marked @nogc, than all D classes must 
implement
it as @nogc, because (of course) you cannot override a @nogc 
method
with a not-@nogc one (while the opposite is possible, of 
course).
So marking it @nogc is not only a big breaking change, but 
also very

limiting.


Um, this isn't right. GC code can always call non-gc code.


The issue is that for *classes*, the proper way to add an 
opEquals is to override the base version. The base version 
existed LONG before @nogc did, and so it's not appropriately 
marked.


Not only that, but @nogc is too limiting (if I want to use GC 
in opEquals, I should be able to).


The real problem here is that there is a base method at all. We 
have been striving to remove it at some point, but it is very 
difficult due to all the legacy code which is written.


Almost all the Object base methods need to be removed IMO. You 
can add them at a higher level if you need them, and then 
specify your requirements for derived classes.


Including opHash, opCmp, toString, etc.

If you mark opEquals nogc, it breaks nothing except 
implementations of
opEquals that use the GC. GC code can still call it nogc 
opequals, it
only enforces opEquals code to avoid the GC itself, which 
isn't a

terrible thing.


It breaks all classes which use GC in opEquals. Note that you 
can't really compare two immutable or const objects either! 
(well, actually you can, but that's because the runtime just 
casts away const and lets you have undefined behavior).



What is terrible is that nogc code can never have any equality
comparisons! It is impossible unless one manually tests them, 
but how?
Every method would be brittle. Do a memory test? compare 
element by

element? One can't predict what to do.


It is unfortunate. I hope we can fix it. I'd rather not add 
another exception like we have for comparing const objects.


So, you are trying off laziness to break nogc. As it stands, 
if nogc
code can't compare equality, it is broken and useless. Why put 
it in the

language then?


@nogc is not useless, it just cannot handle Objects at the 
moment.


Broke! Even if opEquals of T does not use any GC we can't 
write test to
be nogc, which means we can't have S be nogc or anything that 
depends on
S that is nogc. This must be a dirty trick played by the 
implementors of

nogc to keep everyone on the gc nipple?


I assure you, it's not a trick. It's legacy. It needs fixing, 
but the fix isn't painless or easy.


-Steve


I've seen this type of problem many times before when using the 
@nogc attribute.  With alot of work, and breaking changes, you 
could fix it in the case of opEquals, and in the end you still 
end up with the restriction that you can't use the GC in 
opEquals, which may be a good thing, but some would disagree.  
But this is a common problem and I think a more exhaustive 
solution would be to allow @nogc code to call that that is either 
marked as nogc, or inferred to be @nogc.  Instead of treating 
@nogc as a special compiler directive to check for GC code, the 
compiler could check for GC code in all cases, and infer the 
attribute for all functions.  Then @nogc would simply be a way 
for the developer to tell the compiler to make sure they aren't 
using @nogc where they don't intend to.  This allows code that is 
written without @nogc to be called from code that does use it.  
It takes an effort away from the developer and moves it to the 
compiler.  It allows @nogc to work with existing code.


Maybe this would result in a big performance hit on the compiler 
because now it would always have to check for GC code, instead of 
just when it's specified with @nogc...not sure.


Anyway, this is just a general overview.  There's obviously alot 
of details and specifics that were glossed over but I think the 
general idea could be a good solution.

[Issue 16312] "Error: Overlapping fields" caused by use of deprecated features in referred to fields

[via Digitalmars-d-bugs]

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

Marco Leise  changed:

   What|Removed |Added

   Keywords|rejects-valid   |

--- Comment #2 from Marco Leise  ---
This report is about the first point, yes. Even if treated as an error,
"deprecated" means the compiler can still handle the situation. I suggest, not
to poison the AST for "deprecated as error" and "warning as error", but just
print the error and continue compilation as normal. (And return -1 from main.)
Does that seem feasible?

--

Re: Cannot compare object.opEquals is not nogc

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/23/16 10:53 AM, Rufus Smith wrote:

On Saturday, 23 July 2016 at 14:15:03 UTC, Lodovico Giaretta wrote:

On Saturday, 23 July 2016 at 13:18:03 UTC, Rufus Smith wrote:

Trying to compare a *ptr value with a value in nogc code results in
the error:

Error: @nogc function '...' cannot call non-@nogc function
'object.opEquals'

Shouldn't object opEquals be marked?


If object.opEquals is marked @nogc, than all D classes must implement
it as @nogc, because (of course) you cannot override a @nogc method
with a not-@nogc one (while the opposite is possible, of course).
So marking it @nogc is not only a big breaking change, but also very
limiting.


Um, this isn't right. GC code can always call non-gc code.


The issue is that for *classes*, the proper way to add an opEquals is to 
override the base version. The base version existed LONG before @nogc 
did, and so it's not appropriately marked.


Not only that, but @nogc is too limiting (if I want to use GC in 
opEquals, I should be able to).


The real problem here is that there is a base method at all. We have 
been striving to remove it at some point, but it is very difficult due 
to all the legacy code which is written.


Almost all the Object base methods need to be removed IMO. You can add 
them at a higher level if you need them, and then specify your 
requirements for derived classes.


Including opHash, opCmp, toString, etc.


If you mark opEquals nogc, it breaks nothing except implementations of
opEquals that use the GC. GC code can still call it nogc opequals, it
only enforces opEquals code to avoid the GC itself, which isn't a
terrible thing.


It breaks all classes which use GC in opEquals. Note that you can't 
really compare two immutable or const objects either! (well, actually 
you can, but that's because the runtime just casts away const and lets 
you have undefined behavior).



What is terrible is that nogc code can never have any equality
comparisons! It is impossible unless one manually tests them, but how?
Every method would be brittle. Do a memory test? compare element by
element? One can't predict what to do.


It is unfortunate. I hope we can fix it. I'd rather not add another 
exception like we have for comparing const objects.



So, you are trying off laziness to break nogc. As it stands, if nogc
code can't compare equality, it is broken and useless. Why put it in the
language then?


@nogc is not useless, it just cannot handle Objects at the moment.


Broke! Even if opEquals of T does not use any GC we can't write test to
be nogc, which means we can't have S be nogc or anything that depends on
S that is nogc. This must be a dirty trick played by the implementors of
nogc to keep everyone on the gc nipple?


I assure you, it's not a trick. It's legacy. It needs fixing, but the 
fix isn't painless or easy.


-Steve

Re: Cannot compare object.opEquals is not nogc

[Lodovico Giaretta via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 14:53:49 UTC, Rufus Smith wrote:

Um, this isn't right. GC code can always call non-gc code.

If you mark opEquals nogc, it breaks nothing except 
implementations of opEquals that use the GC. GC code can still 
call it nogc opequals, it only enforces opEquals code to avoid 
the GC itself, which isn't a terrible thing.


That's what I meant. Sorry for being not clear. IMHO, it is very 
limiting to forbid the use of the GC in opEquals. And it would 
definitely break a lot of code.


What is terrible is that nogc code can never have any equality 
comparisons! It is impossible unless one manually tests them, 
but how? Every method would be brittle. Do a memory test? 
compare element by element? One can't predict what to do.


@nogc code can have @nogc comparisons, as long as it does not use 
other objects whose comparison requires the GC. See more below.


So, you are trying off laziness to break nogc. As it stands, if 
nogc code can't compare equality, it is broken and useless. Why 
put it in the language then?


struct S(T)
{
   @nogc void test(T t1, T t2)
   {
  if (t1 == t2) return true;
  return false;
   }
}

Broke! Even if opEquals of T does not use any GC we can't write 
test to be nogc, which means we can't have S be nogc or 
anything that depends on S that is nogc. This must be a dirty 
trick played by the implementors of nogc to keep everyone on 
the gc nipple?


If opEquals of T does not use the GC, then the compiler will 
infer the attribute @nogc for your test function. Remember: 
templated functions will be inferred @nogc whenever possible. 
Just, don't put @nogc explicitly, so the code will be @nogc if 
T.opEquals is @nogc and otherwise it will be not-@nogc.


Equality comparison is more fundamental than the GC in 
programming. There is no fundamental reason why equality 
comparison depends on the GC.


All I can hope for now is that there is a robust way to compare 
that I can use that is marked nogc. Else all my nogc code is 
broke. I guess one has this problem with all opOp's!


With templates (as you show in your code) you have no problem, 
just let the compiler infer the attributes, as I said.
With runtime OOP it is more of a trouble, but in D runtime OOP is 
not used that much, and it is rarely used in critical @nogc code.

Re: Cannot compare object.opEquals is not nogc

[Rufus Smith via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 14:15:03 UTC, Lodovico Giaretta 
wrote:

On Saturday, 23 July 2016 at 13:18:03 UTC, Rufus Smith wrote:
Trying to compare a *ptr value with a value in nogc code 
results in the error:


Error: @nogc function '...' cannot call non-@nogc function 
'object.opEquals'		


Shouldn't object opEquals be marked?


If object.opEquals is marked @nogc, than all D classes must 
implement it as @nogc, because (of course) you cannot override 
a @nogc method with a not-@nogc one (while the opposite is 
possible, of course).
So marking it @nogc is not only a big breaking change, but also 
very limiting.


Um, this isn't right. GC code can always call non-gc code.

If you mark opEquals nogc, it breaks nothing except 
implementations of opEquals that use the GC. GC code can still 
call it nogc opequals, it only enforces opEquals code to avoid 
the GC itself, which isn't a terrible thing.


What is terrible is that nogc code can never have any equality 
comparisons! It is impossible unless one manually tests them, but 
how? Every method would be brittle. Do a memory test? compare 
element by element? One can't predict what to do.


So, you are trying off laziness to break nogc. As it stands, if 
nogc code can't compare equality, it is broken and useless. Why 
put it in the language then?


struct S(T)
{
   @nogc void test(T t1, T t2)
   {
  if (t1 == t2) return true;
  return false;
   }
}

Broke! Even if opEquals of T does not use any GC we can't write 
test to be nogc, which means we can't have S be nogc or anything 
that depends on S that is nogc. This must be a dirty trick played 
by the implementors of nogc to keep everyone on the gc nipple?


Equality comparison is more fundamental than the GC in 
programming. There is no fundamental reason why equality 
comparison depends on the GC.


All I can hope for now is that there is a robust way to compare 
that I can use that is marked nogc. Else all my nogc code is 
broke. I guess one has this problem with all opOp's!

[Issue 16314] New: private copyBackwards is broken

[via Digitalmars-d-bugs]

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

  Issue ID: 16314
   Summary: private copyBackwards is broken
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

Bug found by reviewing the source code. So, no user code example

--

Re: Terminix Stable 1.2.0 Released

[qsdjlf via Digitalmars-d-announce]

On Saturday, 23 July 2016 at 14:24:08 UTC, Matthias Klumpp wrote:

On Saturday, 23 July 2016 at 11:40:20 UTC, qsdjlf wrote:

[...]
integration in distribution could be a good signal, what a 
say, Excellent signal, for the D language. I know that some 
people here are mostly starving at commercial usage...but for 
me such tools written in D and available in linux distros via 
their package manager would be a much more significant sign.


It is also something that brings people to D - a good toolchain 
and many projects using D and being established in Linux 
distributions is a *huge* influence.


Unfortunately, D is still a bit painful in Linux distros.
Those issues should be resolved to make integration easier:

1) Stable ABI for the D language which ideally also works 
across compilers


2) Fixing dub bugs and adding features - at time, dub is pretty 
unusable for distro packaging, which is why we use Terminix' 
Automake support.

Specifically, these issues need to be addressed:
 - Find & use system dub packages: 
https://github.com/dlang/dub/issues/838
 - Make dub compile by-file and not compile everything with one 
compiler command (for very large projects this makes 
parallelization hard and can also bring down less powerful 
build slaves)
 - Add "dub install" to install a project: 
https://github.com/dlang/dub/issues/839
 - "dub test" shouldn't override the main binary, otherwise we 
can't run tests properly in distros at compile-time: 
https://github.com/dlang/dub/issues/840


3) Making LDC available for more architectures, or making GDC 
support a higher version of the Phobos standard library and 
build shared libraries.
At time, LDC is the better fit because of shared library 
support and higher Phobos version. Current D projects are hard 
to compile with GDC because of the latter reason.
More architectures are not per-se essential, but would be 
awesome to have. This feature request summarizes the status of 
arch support for D in free compilers: 
https://github.com/ldc-developers/ldc/issues/1636


4) Resolving weird LDC bugs like this one: 
https://github.com/ldc-developers/ldc/issues/1618 - might 
actually be an LLVM issue, but I don't know enough to pin down 
the issue.


5) Have hardening supported for the D compilers: 
https://wiki.debian.org/HardeningWalkthrough


6) Ideally have the free D compilers agree on a common set of 
compiler options, like clang supports gcc compiler flags. That 
allows distros to apply compiler flags globally, e.g. to enable 
hardening.


Of these points 1, 2 and 4 are very important, 3 would be 
really nice to have and 5 and 6 would be going the extra mile 
to make D awesome in distros and us as distribution vendors 
really happy.


+1 very good post. Good lightening of the problem.

Re: Terminix Stable 1.2.0 Released

[Matthias Klumpp via Digitalmars-d-announce]

On Saturday, 23 July 2016 at 11:40:20 UTC, qsdjlf wrote:

[...]
integration in distribution could be a good signal, what a say, 
Excellent signal, for the D language. I know that some people 
here are mostly starving at commercial usage...but for me such 
tools written in D and available in linux distros via their 
package manager would be a much more significant sign.


It is also something that brings people to D - a good toolchain 
and many projects using D and being established in Linux 
distributions is a *huge* influence.


Unfortunately, D is still a bit painful in Linux distros.
Those issues should be resolved to make integration easier:

1) Stable ABI for the D language which ideally also works across 
compilers


2) Fixing dub bugs and adding features - at time, dub is pretty 
unusable for distro packaging, which is why we use Terminix' 
Automake support.

Specifically, these issues need to be addressed:
 - Find & use system dub packages: 
https://github.com/dlang/dub/issues/838
 - Make dub compile by-file and not compile everything with one 
compiler command (for very large projects this makes 
parallelization hard and can also bring down less powerful build 
slaves)
 - Add "dub install" to install a project: 
https://github.com/dlang/dub/issues/839
 - "dub test" shouldn't override the main binary, otherwise we 
can't run tests properly in distros at compile-time: 
https://github.com/dlang/dub/issues/840


3) Making LDC available for more architectures, or making GDC 
support a higher version of the Phobos standard library and build 
shared libraries.
At time, LDC is the better fit because of shared library support 
and higher Phobos version. Current D projects are hard to compile 
with GDC because of the latter reason.
More architectures are not per-se essential, but would be awesome 
to have. This feature request summarizes the status of arch 
support for D in free compilers: 
https://github.com/ldc-developers/ldc/issues/1636


4) Resolving weird LDC bugs like this one: 
https://github.com/ldc-developers/ldc/issues/1618 - might 
actually be an LLVM issue, but I don't know enough to pin down 
the issue.


5) Have hardening supported for the D compilers: 
https://wiki.debian.org/HardeningWalkthrough


6) Ideally have the free D compilers agree on a common set of 
compiler options, like clang supports gcc compiler flags. That 
allows distros to apply compiler flags globally, e.g. to enable 
hardening.


Of these points 1, 2 and 4 are very important, 3 would be really 
nice to have and 5 and 6 would be going the extra mile to make D 
awesome in distros and us as distribution vendors really happy.

Re: Cannot compare object.opEquals is not nogc

[Lodovico Giaretta via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 13:18:03 UTC, Rufus Smith wrote:
Trying to compare a *ptr value with a value in nogc code 
results in the error:


Error: @nogc function '...' cannot call non-@nogc function 
'object.opEquals'		


Shouldn't object opEquals be marked?


If object.opEquals is marked @nogc, than all D classes must 
implement it as @nogc, because (of course) you cannot override a 
@nogc method with a not-@nogc one (while the opposite is 
possible, of course).
So marking it @nogc is not only a big breaking change, but also 
very limiting.

Cannot compare object.opEquals is not nogc

[Rufus Smith via Digitalmars-d-learn]

Trying to compare a *ptr value with a value in nogc code results 
in the error:


Error: @nogc function '...' cannot call non-@nogc function 
'object.opEquals'		


Shouldn't object opEquals be marked?

Re: Terminix Stable 1.2.0 Released

[Gerald via Digitalmars-d-announce]

On Saturday, 23 July 2016 at 09:27:14 UTC, phant0m wrote:
Nice work! By the way, Terminix is present in the Arch Linux 
AUR.
But it seems that it's very inconvenient for me. I don't use 
gnome and I don't like the fat titlebars (client side 
decorations). Moreover, the Terminix window doesn't have a 
shadow (because it's not a "plain" window with titlebar) in 
KDE. Without a shadow sometimes it's hard to tell where is the 
edge of the window. Is there an ability to remove the client 
side decoration and switch back to the default titlebar?


If you go into dconf with dconf-editor, there is a setting under 
com/gexperts/Terminix to disable the CSS and use a regular 
titlebar.

Re: Expression template

[Etranger via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 12:27:39 UTC, rikki cattermole wrote:


If you evaluate it as v = a + b + c instead of v = a + (b + c) 
you will still have a temporary value. Remember structs are 
just the values they carry and are basically optimized out. 
Either way I recommend you not worry about it. Compilers can be 
smart and dmd is mostly good enough in this department.


If you use dynamic arrays and not fixed sized arrays, they will 
go into the heap, so be careful with what you do with them. 
Fixed sized arrays like gl3n does is fairly cheap since it goes 
on to the stack and in some cases only in registers.


Usually if we solve it on IRC we post the solution that we come 
up with on the post.


For small matrices of fixed size, lazy evaluation may not be 
worth it, but for large matrices and vectors, it is worth it. For 
example, for testing purpose, I wrote 2 versions of and MLP 
(multi-layered perceptron) lib, one that uses openBLAS and one 
with Eigen. The one with Eigen was significantly faster than the 
one with openBLAS tanks to lazy evaluation. No wonder all the 
most known c++ linear algebra lib use this method (Eigen, 
Armadillo, Blitz++, Boost uBlas, ...).


This link http://eigen.tuxfamily.org/dox/TopicLazyEvaluation.html 
explain better than me the advantages of this technique. Given 
the emphasize of D over generics, I think it is worth to explore 
this direction (I hope with better results than what I wrote !).

Re: Transform/Compile to C/CPP as a target

[ParticlePeter via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 12:29:45 UTC, rikki cattermole wrote:

On 24/07/2016 12:27 AM, ParticlePeter wrote:
Is there any kind of project or workflow that converts D 
(subset) to

C/CPP ?


This probably will interest you for ldc: 
http://stackoverflow.com/questions/5180914/llvm-ir-back-to-human-readable-source-language


Cool, I didn't know that one but I also didn't invest time in 
LLVM till now.
However, this converts bitcode to C/CPP, my guess would be that 
the job can be done much better if the original D source would be 
used in tandem.

Re: Transform/Compile to C/CPP as a target

[rikki cattermole via Digitalmars-d-learn]

On 24/07/2016 12:27 AM, ParticlePeter wrote:

Is there any kind of project or workflow that converts D (subset) to
C/CPP ?


This probably will interest you for ldc: 
http://stackoverflow.com/questions/5180914/llvm-ir-back-to-human-readable-source-language

Re: Expression template

[rikki cattermole via Digitalmars-d-learn]

On 24/07/2016 12:09 AM, Etranger wrote:

On Saturday, 23 July 2016 at 11:19:34 UTC, rikki cattermole wrote:

On 23/07/2016 11:05 PM, Etranger wrote:
[snip]


* start of code **
import std.stdio;
import std.traits;
import std.conv;

struct VecExpression(alias mixins) {
  mixin (mixins);
  VecSum!(typeof(this), VecExpression!(RHS)) opBinary(string op, alias
RHS)(ref VecExpression!(RHS) rhs)
{
  static if (op == "+") return VecSum!(typeof(this),
VecExpression!(RHS))(, );
}
}


mixin template Vec_impl(int n) {
  double[n] elems;

  @disable this();

  this(double[n] e){
elems=e;
  }

  double opIndex(int i) {
return elems[i];
  }
}

alias Vec(alias n) = VecExpression!("mixin
Vec_impl!("~to!string(n)~");"); //Vec(int n) does not work

mixin template VecSum_impl(E1, E2) {
  E1 * e1;
  E2 * e2;

  @disable this();

  this(E1 * ee1, E2 * ee2){
e1=ee1;
e2=ee2;
  }

  double opIndex(int i) {
return (*e1)[i]+(*e2)[i];
  }
}

alias VecSum(E1, E2) = VecExpression!("mixin
VecSum_impl!("~fullyQualifiedName!E1~","~fullyQualifiedName!E2~");");

void main()
{
  Vec!(3) v1 = Vec!(3)([5., 2., 3.]), v2 = Vec!(3)([1., 4., 3.]), v3 =
Vec!(3)([3., 2., 1.]);
  auto res = v1+v2;
  for(int i=0; i < 3; ++i){
writefln("%f + %f = %f", v1[i], v2[i],  res[i]);
  }
  auto res2 = res+v3;
  for(int i=0; i < 3; ++i){
writefln("%f + %f = %f", res[i], v3[i],  res2[i]);
  }
  writeln(res);
  writeln(res2);

  // VecExpression!(Vec_impl!(3)) ve; // Error: template instance
Vec_impl!3 mixin templates are not regular templates
}

* end of code **

My questions:

1- Is there a cleaner way to do it ? I had to use struct because I want
every thing to happen at compile time and on the stack (without gc). And
I had to use string mixins because template mixin does not work the way
I tried to use it ( see the error last line).

2- Is there a safer way to do it (without using pointers) ?

3- Do you think I'll hit a wall with this approach ?

4- Do you known any D libs that uses expression template for linear
algebra ?

I thank you in advance for your help and wish you a nice weekend (and
apologize for my bad english) :)


My goodness that code is awful.

I have a fair idea what you are attempting to do here.
So I'm going to point you directly to gl3n. Its meant for game dev so
won't provide you a 100% solution. But it should give you ideas of how
to do it.

https://github.com/Dav1dde/gl3n/blob/master/gl3n/linalg.d#L49

If you have any questions and want somebody to talk with you instead
of write, reply cycle. Please hop on to Freenode #d channel.


Hi and thanks for your quick replay.

A looked to the gl3n code, although the code is clear and clean, it is
not really what I want to do in my example.

The gl3n is eager evaluation. If I write "v = v1+v2+v3;", then it will
create a temporary variable "tmp1=v1+v2;" then a second temp
"tmp2=tmp1+v3;" and finally "v=tmp2;".

what I'm trying to do to use lazy evaluation in order to create only one
tmp that will that will directly hold the result of v1[i]+v2[i]+v3[i].
That concept is then generalized in order to perform more optimization
based on entire expression trees, no just tow operands.

And thanks for the suggestion regarding the channel, I'll try to use it
as soon as I have the time. I feel on advantage of the forum is that it
stays for other people and not just for me.

best regards


If you evaluate it as v = a + b + c instead of v = a + (b + c) you will 
still have a temporary value. Remember structs are just the values they 
carry and are basically optimized out. Either way I recommend you not 
worry about it. Compilers can be smart and dmd is mostly good enough in 
this department.


If you use dynamic arrays and not fixed sized arrays, they will go into 
the heap, so be careful with what you do with them. Fixed sized arrays 
like gl3n does is fairly cheap since it goes on to the stack and in some 
cases only in registers.


Usually if we solve it on IRC we post the solution that we come up with 
on the post.

Transform/Compile to C/CPP as a target

[ParticlePeter via Digitalmars-d-learn]

Is there any kind of project or workflow that converts D (subset) 
to C/CPP ?

Re: Expression template

[Etranger via Digitalmars-d-learn]

On Saturday, 23 July 2016 at 11:19:34 UTC, rikki cattermole wrote:

On 23/07/2016 11:05 PM, Etranger wrote:
[snip]


* start of code **
import std.stdio;
import std.traits;
import std.conv;

struct VecExpression(alias mixins) {
  mixin (mixins);
  VecSum!(typeof(this), VecExpression!(RHS)) opBinary(string 
op, alias

RHS)(ref VecExpression!(RHS) rhs)
{
  static if (op == "+") return VecSum!(typeof(this),
VecExpression!(RHS))(, );
}
}


mixin template Vec_impl(int n) {
  double[n] elems;

  @disable this();

  this(double[n] e){
elems=e;
  }

  double opIndex(int i) {
return elems[i];
  }
}

alias Vec(alias n) = VecExpression!("mixin
Vec_impl!("~to!string(n)~");"); //Vec(int n) does not work

mixin template VecSum_impl(E1, E2) {
  E1 * e1;
  E2 * e2;

  @disable this();

  this(E1 * ee1, E2 * ee2){
e1=ee1;
e2=ee2;
  }

  double opIndex(int i) {
return (*e1)[i]+(*e2)[i];
  }
}

alias VecSum(E1, E2) = VecExpression!("mixin
VecSum_impl!("~fullyQualifiedName!E1~","~fullyQualifiedName!E2~");");

void main()
{
  Vec!(3) v1 = Vec!(3)([5., 2., 3.]), v2 = Vec!(3)([1., 4., 
3.]), v3 =

Vec!(3)([3., 2., 1.]);
  auto res = v1+v2;
  for(int i=0; i < 3; ++i){
writefln("%f + %f = %f", v1[i], v2[i],  res[i]);
  }
  auto res2 = res+v3;
  for(int i=0; i < 3; ++i){
writefln("%f + %f = %f", res[i], v3[i],  res2[i]);
  }
  writeln(res);
  writeln(res2);

  // VecExpression!(Vec_impl!(3)) ve; // Error: template 
instance

Vec_impl!3 mixin templates are not regular templates
}

* end of code **

My questions:

1- Is there a cleaner way to do it ? I had to use struct 
because I want
every thing to happen at compile time and on the stack 
(without gc). And
I had to use string mixins because template mixin does not 
work the way

I tried to use it ( see the error last line).

2- Is there a safer way to do it (without using pointers) ?

3- Do you think I'll hit a wall with this approach ?

4- Do you known any D libs that uses expression template for 
linear

algebra ?

I thank you in advance for your help and wish you a nice 
weekend (and

apologize for my bad english) :)


My goodness that code is awful.

I have a fair idea what you are attempting to do here.
So I'm going to point you directly to gl3n. Its meant for game 
dev so won't provide you a 100% solution. But it should give 
you ideas of how to do it.


https://github.com/Dav1dde/gl3n/blob/master/gl3n/linalg.d#L49

If you have any questions and want somebody to talk with you 
instead of write, reply cycle. Please hop on to Freenode #d 
channel.


Hi and thanks for your quick replay.

A looked to the gl3n code, although the code is clear and clean, 
it is not really what I want to do in my example.


The gl3n is eager evaluation. If I write "v = v1+v2+v3;", then it 
will create a temporary variable "tmp1=v1+v2;" then a second temp 
"tmp2=tmp1+v3;" and finally "v=tmp2;".


what I'm trying to do to use lazy evaluation in order to create 
only one tmp that will that will directly hold the result of 
v1[i]+v2[i]+v3[i]. That concept is then generalized in order to 
perform more optimization based on entire expression trees, no 
just tow operands.


And thanks for the suggestion regarding the channel, I'll try to 
use it as soon as I have the time. I feel on advantage of the 
forum is that it stays for other people and not just for me.


best regards

Re: Terminix Stable 1.2.0 Released

[qsdjlf via Digitalmars-d-announce]

On Friday, 22 July 2016 at 19:24:58 UTC, Gerald wrote:

On Friday, 22 July 2016 at 17:30:30 UTC, sdhdfhed wrote:

On Friday, 22 July 2016 at 13:54:41 UTC, Gerald wrote:
I've pushed out the latest stable version of Terminix, a 
tiling terminal emulator for Linux written in D using GtkD. 
The following new features have been added:


Design changes as per discussion in #372
Support for background images
Limited support for automatic profile switching
Globally disable shortcuts
Copy on select preference
Support for a Visual Bell
Numerous bug fixes

More information is available at 
https://github.com/gnunn1/terminix.


I'm always looking for contributors, so if anyone is 
interested in lending a hand feel free to join the party.


Is terminix already 'officially' packaged by any distro ?


It has been packaged for Debian though there is still an issue 
with LDC to be sorted out:


https://github.com/gnunn1/terminix/issues/25#issuecomment-233138093

The biggest challenge is getting D's tool chain supported, the 
release of 1.0 of LDC is what is making this possible for 
Terminix since DMD is a non-starter for most distros.


integration in distribution could be a good signal, what a say, 
Excellent signal, for the D language. I know that some people 
here are mostly starving at commercial usage...but for me such 
tools written in D and available in linux distros via their 
package manager would be a much more significant sign.

Re: DConf 2016 on YouTube

[qsdjlf via Digitalmars-d-announce]

On Thursday, 21 July 2016 at 16:35:44 UTC, Ali Çehreli wrote:

Stealing the opportunity to announce this news... :)

  
https://www.youtube.com/playlist?list=PL3jwVPmk_PRyTWWtTAZyvmjDF4pm6EX6z


Reddit:


https://www.reddit.com/r/programming/comments/4txf9w/dconf_2016_video_playlist/

Ali


Watched already what interested me (i.e read the slide before for 
those) so the Weka guy and Walter explanations about compilers. I 
have to say that "inline" questions is very good (compared to the 
formal talk then the guy ask if there's any question at then 
end...). It works.

Re: Expression template

[rikki cattermole via Digitalmars-d-learn]

On 23/07/2016 11:05 PM, Etranger wrote:
[snip]


* start of code **
import std.stdio;
import std.traits;
import std.conv;

struct VecExpression(alias mixins) {
  mixin (mixins);
  VecSum!(typeof(this), VecExpression!(RHS)) opBinary(string op, alias
RHS)(ref VecExpression!(RHS) rhs)
{
  static if (op == "+") return VecSum!(typeof(this),
VecExpression!(RHS))(, );
}
}


mixin template Vec_impl(int n) {
  double[n] elems;

  @disable this();

  this(double[n] e){
elems=e;
  }

  double opIndex(int i) {
return elems[i];
  }
}

alias Vec(alias n) = VecExpression!("mixin
Vec_impl!("~to!string(n)~");"); //Vec(int n) does not work

mixin template VecSum_impl(E1, E2) {
  E1 * e1;
  E2 * e2;

  @disable this();

  this(E1 * ee1, E2 * ee2){
e1=ee1;
e2=ee2;
  }

  double opIndex(int i) {
return (*e1)[i]+(*e2)[i];
  }
}

alias VecSum(E1, E2) = VecExpression!("mixin
VecSum_impl!("~fullyQualifiedName!E1~","~fullyQualifiedName!E2~");");

void main()
{
  Vec!(3) v1 = Vec!(3)([5., 2., 3.]), v2 = Vec!(3)([1., 4., 3.]), v3 =
Vec!(3)([3., 2., 1.]);
  auto res = v1+v2;
  for(int i=0; i < 3; ++i){
writefln("%f + %f = %f", v1[i], v2[i],  res[i]);
  }
  auto res2 = res+v3;
  for(int i=0; i < 3; ++i){
writefln("%f + %f = %f", res[i], v3[i],  res2[i]);
  }
  writeln(res);
  writeln(res2);

  // VecExpression!(Vec_impl!(3)) ve; // Error: template instance
Vec_impl!3 mixin templates are not regular templates
}

* end of code **

My questions:

1- Is there a cleaner way to do it ? I had to use struct because I want
every thing to happen at compile time and on the stack (without gc). And
I had to use string mixins because template mixin does not work the way
I tried to use it ( see the error last line).

2- Is there a safer way to do it (without using pointers) ?

3- Do you think I'll hit a wall with this approach ?

4- Do you known any D libs that uses expression template for linear
algebra ?

I thank you in advance for your help and wish you a nice weekend (and
apologize for my bad english) :)


My goodness that code is awful.

I have a fair idea what you are attempting to do here.
So I'm going to point you directly to gl3n. Its meant for game dev so 
won't provide you a 100% solution. But it should give you ideas of how 
to do it.


https://github.com/Dav1dde/gl3n/blob/master/gl3n/linalg.d#L49

If you have any questions and want somebody to talk with you instead of 
write, reply cycle. Please hop on to Freenode #d channel.

Expression template

[Etranger via Digitalmars-d-learn]

Hello all,

I will greatly appreciate if you could help me with my first step 
in the D land.


*YOU CAN SKIP DIRECTLY TO THE QUESTION BELLOW*:

Please allow me to introduce myself and give you my feelings 
about the D language then I'll ask my question. I'm a 
mathematician that works mainly on computer vision and machine 
learning for a research institute. All my CV code is written in 
C++ (runs on android and iOs) and no need to say that I'm 
desperately looking to replace it by a more modern language. My 
main complains about C++ are safety, implicit conversion between 
numeric types, tooling (no unified package manager, benchmarking 
or testing framework), verbose generics, poor standard library 
(although boost is great, but then compile time goes crazy), not 
so great at writing "high level" code when needed ... it just old.


I looked into some contenders: D, ocaml, Go, rust, even Haskell! 
GC languages are definitely not an option for computer vision and 
low level machine learning (writing ML libs), so GO, ocaml and 
haskell are out. (Although I use Go for production when I have to 
deal with concurrency and networks (getting energy data from 
sensors or web crawlers). The language is meh but the finishing 
(tooling, stability, documentation and libraries) is great).


So the only left possible alternatives are D and rust. I looked 
into D few years later but didn't look far as it was advertised 
as a GC language and the community (and support) seemed too 
small, and the tooling/libs not so great. I spent allot of time 
following rust and learning it, and put allot of hope in it. 
However, today rust seems to have 3 main deal breaking weaknesses 
for my particular use :


1-Bad C++ interop, and no plans to make it better. For me as for 
many developers in my field, I cannot work without my tools (like 
openCV, Eigen, Armadillo ...). No matter how good the language 
is, if it does not allow me to use well known and tested 
libraries that I need in my day job (or offers equivalent quality 
libs), I just cannot use it, its impossible.


2- Limited support for generics and little interest at enhancing 
them. Generic programming is essential to build highly efficient 
numeric libraries, like Eigen and Armadillo that relays heavily 
on expression templates to avoid temporaries. Rust still does not 
support integer template parameters and its trait based generics 
may be more secure but are very hard to use and impractical for 
non trivial generic code.


3- Memory management. The borrow checker is a real advantage when 
there is a need for highly efficient code. But for the less 
demanding applications in term of efficiency, it is a burden and 
I think a GC is more adapted for such applications.


Although rust is a wonderful language with a great community, The 
points 1 and 2 are deal breaking for me, and are what made me 
return to D and have a better look (expect allot of peoples like 
me I think when the hype start to diminish around rust and people 
that have tasted a modern programming language find them self 
unable to return to C++ but too limited by rust constraints).


By contrast, the 3 main weaknesses of rust (for me) are what 
attract me to the D language:


1- Good foundations for a full C++ interopt. Although we still 
cannot use C++ libs without any bindings like in objective-C. The 
work made so far on the D compiler + Calypso ( 
https://github.com/Syniurge/Calypso ) give me hope that one day, 
I'll just be able to put and "import opencv2.core;" into my code 
and use D in my work. By the way, make Calypso an official 
project to allow full interop with C++, stabilize one compiler on 
all major platforms and I'll throw C++ from the window and never 
look back.


2- Great at generics (hello Andrei !)

3- Optional Gc with I hope full support for non-GC memory 
management soon.


In brief, D is great, if you give it full c++ interop and 
stabilize the compiler(s) and the tooling, get backed by some big 
name in the industry, I think it is condemned to succeed.


THE QUESTION

Expression templates are heavily used in C++ to build highly 
efficient linear algebra libraries with lazy evaluation. I order 
to learn D, I'm trying to implement such system in D, so I can 
maybe interface it with ndslices and translate a linear algebra 
lib like Eigen in D.


For a first step, I tried to translate the example given here 
https://en.wikipedia.org/wiki/Expression_templates , and here is 
my attempt:


* start of code **
import std.stdio;
import std.traits;
import std.conv;

struct VecExpression(alias mixins) {
  mixin (mixins);
  VecSum!(typeof(this), VecExpression!(RHS)) opBinary(string op, 
alias RHS)(ref VecExpression!(RHS) rhs)

{
  static if (op == "+") return VecSum!(typeof(this), 
VecExpression!(RHS))(, );

}
}


mixin template Vec_impl(int n) {
  double[n] elems;

  @disable this();

  this(double[n] e){
elems=e;
  }

  double opIndex(int i) {
   

Re: Terminix Stable 1.2.0 Released

[Martin Tschierschke via Digitalmars-d-announce]

On Friday, 22 July 2016 at 13:54:41 UTC, Gerald wrote:
I've pushed out the latest stable version of Terminix, a tiling 
terminal emulator for Linux written in D using GtkD. The 
following new features have been added:


Design changes as per discussion in #372
Support for background images
Limited support for automatic profile switching
Globally disable shortcuts
Copy on select preference
Support for a Visual Bell
Numerous bug fixes

More information is available at 
https://github.com/gnunn1/terminix.


I'm always looking for contributors, so if anyone is interested 
in lending a hand feel free to join the party.


Nice! I will test it on our Ubuntu 14.04 + XFCE4 thin client 
environment.


On my personal wish list is the feature to mix mouse and terminal 
interaction:
With some programs hyperlinks are detected an can be opened with 
mouse click.


It would be very cool, to allow the detection of ls command and 
offering mouse support for opening files or cd / changing 
directories.


I am using always lt as alias for ls -lrt, to see the last 
modified files, than just clicking on the file to get an open 
dialogue would be very cool.


In the moment I am using a small script: openlast [command], to 
open the last modified file with command or if omitted with 
gnome-open, but this does not work if you want to open an other 
file than the last one. And it ends up again with typing the 
program name or copying with the mouse.


Regards mt.

Re: DConf 2016 on YouTube

[lobo via Digitalmars-d-announce]

On Thursday, 21 July 2016 at 16:35:44 UTC, Ali Çehreli wrote:

Stealing the opportunity to announce this news... :)

  
https://www.youtube.com/playlist?list=PL3jwVPmk_PRyTWWtTAZyvmjDF4pm6EX6z


Reddit:


https://www.reddit.com/r/programming/comments/4txf9w/dconf_2016_video_playlist/

Ali


Thanks to all for getting the videos done.

I've watched a few now and they've all been very good. My 
personal favourite so far is Don Clugston's talk on floating 
point. Funny with some great information for the average 
programmer, i.e. me.


bye,
lobo

Re: full path to source file __FILE__

[Martin Tschierschke via Digitalmars-d-learn]

On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler wrote:
Is there a way to get the full path of the current source file? 
Something like:


__FILE_FULL_PATH__

I'm asking because I'm rewriting a batch script in D, meant to 
be ran with rdmd.  However, the script needs to know it's own 
path.  The original batch script uses the %~dp0 variable for 
this, but I'm at a loss on how to do this in D.  Since rdmd 
compiles the executable to the %TEMP% directory, thisExePath 
won't work.


BATCH
-
echo "Directory of this script is " %~dp0


What about using a wrapper around rdmd, so the program is 
executed with an
additional parameter or an environment variable containing 
"FULL_PATH".


When I started with D, I "accidentaly" wrote my own replacement 
script for rdmd
compiling xyz.d with dmd to xyz or calling xyz depending on the 
modification times of the files.


Regards mt.

Re: Terminix Stable 1.2.0 Released

[phant0m via Digitalmars-d-announce]

On Friday, 22 July 2016 at 13:54:41 UTC, Gerald wrote:
I've pushed out the latest stable version of Terminix, a tiling 
terminal emulator for Linux written in D using GtkD. The 
following new features have been added:


Design changes as per discussion in #372
Support for background images
Limited support for automatic profile switching
Globally disable shortcuts
Copy on select preference
Support for a Visual Bell
Numerous bug fixes

More information is available at 
https://github.com/gnunn1/terminix.


I'm always looking for contributors, so if anyone is interested 
in lending a hand feel free to join the party.


Nice work! By the way, Terminix is present in the Arch Linux AUR.
But it seems that it's very inconvenient for me. I don't use 
gnome and I don't like the fat titlebars (client side 
decorations). Moreover, the Terminix window doesn't have a shadow 
(because it's not a "plain" window with titlebar) in KDE. Without 
a shadow sometimes it's hard to tell where is the edge of the 
window. Is there an ability to remove the client side decoration 
and switch back to the default titlebar?

Re: DConf Videos

[Walter Bright via Digitalmars-d]

On 7/23/2016 12:42 AM, Dmitry wrote:

I added DConf 2016


Thanks!

Re: DConf Videos

[Dmitry via Digitalmars-d]

On Saturday, 23 July 2016 at 02:32:49 UTC, Walter Bright wrote:

http://wiki.dlang.org/Videos
(though it needs updating)


I added DConf 2016

[Issue 16313] New: Duplicate symbol generated

[via Digitalmars-d-bugs]

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

  Issue ID: 16313
   Summary: Duplicate symbol generated
   Product: D
   Version: D2
  Hardware: x86_64
OS: Mac OS X
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: jmalim...@gmail.com

The compiler generates duplicated symbols for "my_array" in the following code
snippet and causes the linker to fail. 
The issue is triggered by the circular reference in line 18 (which is perfectly
legal btw). Commenting that line and the error goes away. This issue is present
in 2.071.1 on OSX and windows at least, but not present in version 2.067.1, at
least not in OSX or linux.   

01  struct Foo {
02  int a;
03  immutable(Foo[])* b;
04  this(int _a, immutable(Foo[])* _b)
05  {
06  a = _a;
07  b = _b;
08  }
09  this(int _a)
10  {
11  this(_a, null);
12  }
13  };
14
15  immutable Foo[] my_array = [
16  Foo(1),
17  Foo(2),
18  Foo(3, _array),
19  ];
20
21  void main()
22  {
23  int a = my_array[0].a;
24  }

--