Re: Head Const

[Walter Bright via Digitalmars-d]

On 2/17/2016 4:41 PM, Jonathan M Davis wrote:

Yes, but that really isn't going to help much code. It would be useless for
ref-counting const objects, it wouldn't allow you to put a mutex in a const
object, and you couldn't do anything with caching calculated properties in a
const object.


Embed a headconst pointer to the thing you want to mutate.

Re: Head Const

[Walter Bright via Digitalmars-d]

On 2/17/2016 2:38 PM, Andrei Alexandrescu wrote:

On 02/17/2016 04:07 PM, Walter Bright wrote:

On 2/17/2016 3:56 AM, Andrei Alexandrescu wrote:

On 02/16/2016 09:53 PM, Walter Bright wrote:

Most of what people find frustrating about D's transitive
const/immutable is its very nature of not being sloppy and full of
holes.


I thought it was the constructors and postblit that are the matter.
(It may seem
I'm on a snarky streak, but I do think that's the remaining issue with
immutable). -- Andrei


Logical const!


How do you mean that? I see no connection. -- Andrei


People want to relax transitive immutability so they can implement logical 
const.

Re: Head Const

[Bottled Gin via Digitalmars-d]

Greetings

Having coded a multithreaded library in D, I sorely miss headcost 
like specifier.


The library code dealt with lots of composite class object 
hierarchy where many element objects of a parent are *effectively 
immutable*. You build an effectively immutable object in the 
constructor of the parent class and then you are done since you 
do not assign to these object handles again. As a result there is 
no need to lock the parent object while accessing an *effectively 
immutable* object. The parent as well as child objects are 
mutable otherwise.


Dlang's immutable and const do not provide such a contract.

So +1 for headconst if this specifier can be used with class 
elements as well and not just in the function parameter list.


- Puneet

Re: Head Const

[Laeeth Isharc via Digitalmars-d]

On Wednesday, 17 February 2016 at 17:47:02 UTC, Jonathan M Davis 
wrote:
On Wednesday, 17 February 2016 at 17 you're not actually 
getting.


But in practice, it does prevent accidental mutation, and as 
long as the programmer is behaving themselves reasonably well,




Unfortunately, the net result is that while const is still very 
useful, there are a lot of cases in D where you can't use it, 
and you have to be a lot more careful about how and when you 
use it such that it gets used far less than in C++, and while 
where it _is_ used does provide much better guarantees, you 
lose out on a lot of protection against accidental mutation 
that your typical C++ code gets.


Things would be a bit friendlier for newcomers if the 
documentation were a bit clearer on the 'having to be a lot more 
careful on how and when you use it' so one doesnt end up finding 
this out the hard way.

Re: Official compiler

[rsw0x via Digitalmars-d]

On Thursday, 18 February 2016 at 06:57:01 UTC, Kai Nacke wrote:
On Wednesday, 17 February 2016 at 22:57:20 UTC, Márcio Martins 
wrote:

[...]


Hi,

even if DMD is the official reference compiler, the download 
page http://dlang.org/download.html already mentions "strong 
optimization" as pro of GDC/LDC vs. "very fast compilation 
speeds" as pro of DMD.


If we would make GDC or LDC the official compiler then the next 
question which pops up is about compilation speed


Regards,
Kai


an additional major pro of ldc/gdc is that they're under a free 
license and can be freely redistributed, dmd is not

Re: Official compiler

[Kai Nacke via Digitalmars-d]

On Wednesday, 17 February 2016 at 22:57:20 UTC, Márcio Martins 
wrote:
I was reading the other thread "Speed kills" and was wondering 
if there is any practical reason why DMD is the official 
compiler?


Currently, newcomers come expecting their algorithm from 
rosetta code to run faster in D than their current language, 
but then it seems like it's actually slower. What gives?


Very often the typical answer from this community is generally 
"did you use LDC/GDC?".


Wouldn't it be a better newcomer experience if the official 
compiler was either LDC or GDC?
For us current users it really doesn't matter what is labelled 
official, we pick what serves us best, but for a newcomer, the 
word official surely carries a lot of weight, doesn't it?


From a marketing point of view, is it better for D as a 
language that first-timers try the bleeding-edge, latest 
language features with DMD, or that their expectations of 
efficient native code are not broken?


Apologies if this has been discussed before...


Hi,

even if DMD is the official reference compiler, the download page 
http://dlang.org/download.html already mentions "strong 
optimization" as pro of GDC/LDC vs. "very fast compilation 
speeds" as pro of DMD.


If we would make GDC or LDC the official compiler then the next 
question which pops up is about compilation speed


Regards,
Kai

Re: IMAP library

[Laeeth Isharc via Digitalmars-d]

On Wednesday, 17 February 2016 at 09:43:44 UTC, crimaniak wrote:

On Wednesday, 17 February 2016 at 09:01:18 UTC, Mengu wrote:

hello everyone

i have checked code.dlang.org and github but i have not 
encountered an IMAP library. ..


https://github.com/Laeeth/d_etpan


I made a start but got sidetracked.  So I don't think that's 
close to usable from what I recall.  An alternative would be to 
port the C code from imapfilter to D.  I have done much of that 
but simply don't have time to finish.  So if someone wants to 
finish it then email me and I will give them what I have done so 
far.

Re: Head Const

[Daniel Murphy via Digitalmars-d]

On 16/02/2016 8:29 PM, Ola Fosheim Grøstad wrote:


I agree with the principle, but not as a library function, because:

1. you want virtual functions to work out ok


virtual functions don't even need mangling.  But even if they did it 
would work just fine anyway.




2. making D more reliant on macroish string processing is not good



It's not macroish string processing, it's embedding a subset of C++ 
declarations like a DSL.  The difference is that the C++ can be fully 
type-checked and semantically analysed, errors will not leak into the 
generated source.




You would need something along the lines of:

1. «extern "C++"» the essence of the class definition in plain C++ syntax

2. add to this syntax a translation for each parameter what it means in D.


E.g.

extern "C++" {

class X {
   mutable int rc;
   virtual func1(const A* ptr); @reinterpret(ptr, head_const_ptr!A)
   virtual func2(const A* ptr); @reinterpret(ptr, const A*)
   virtual func3(A* ptr);
   virtual func4(const A* ptr); @reinterpret(ptr, const_rc!A*)
};

}



We don't 'need' compiler support beyond what we have, for any of this.

Re: std.xml2 (collecting features)

[Alex Vincent via Digitalmars-d]

On Sunday, 3 May 2015 at 17:39:48 UTC, Robert burner Schadek 
wrote:
std.xml has been considered not up to specs nearly 3 years now. 
Time to build a successor. I currently plan the following 
featues for it:


- SAX and DOM parser
- in-situ / slicing parsing when possible (forward range?)
- compile time switch (CTS) for lazy attribute parsing
- CTS for encoding (ubyte(ASCII), char(utf8), ... )
- CTS for input validating
- performance

Not much code yet, I'm currently building the performance test 
suite https://github.com/burner/std.xml2


Please post you feature requests, and please keep the posts DRY 
and on topic.


I'm looking for a status update.  DUB doesn't seem to have many 
options posted.  I was thinking about starting a SAXParser 
implementation.

Re: Vulkan bindings

[Mike Parker via Digitalmars-d]

On Thursday, 18 February 2016 at 03:27:55 UTC, Alex Parrill wrote:



(IMO It would be cool to generate OpenGL and Vulkan bindings 
directly from the XML spec; std.xml doesn't work in CTFE. 
Though it would probably take a long time to compile)


https://github.com/Dav1dde/glad

Re: Vulkan bindings

[ZombineDev via Digitalmars-d]

On Thursday, 18 February 2016 at 03:27:55 UTC, Alex Parrill wrote:

On Tuesday, 16 February 2016 at 19:01:58 UTC, Satoshi wrote:

Hello Vulkan API 1.0 is here and I just wrapped it into D.

https://github.com/Rikarin/VulkanizeD

Have fun!


Please consider making it a Dub package!

(IMO It would be cool to generate OpenGL and Vulkan bindings 
directly from the XML spec; std.xml doesn't work in CTFE. 
Though it would probably take a long time to compile)


I started working on that. I've been reading the Python C Header 
generator code and I'm wondering if would be easier to just 
re-implement it in D, rather than trying to extend it. Currently 
the XML is very C oriented (e.g. has C macros in it), unlike the 
OpenGL spec which was written in a language agnostic way.


The advantages of using the vk.xml is that once the generator is 
complete you can easily adapt it for newer revisions of the spec. 
Also you have much more freedom in how you can organize the 
bindings (split by functions/structs/enums or logically by e.g. 
instance, device, command recording, queues, synchronization, 
shaders, pipelines, etc.), also it's easier to do other stuff 
like using D's builtin types instead of cstdint, generating 
ddoc-formatted function/struct/enum documentation and also 
ddoc-ed unittests from the spec examples. And maybe also provide 
two versions - one with vanilla names (easier if you are 
following tutorials) and one that's written in D style 
(http://dlang.org/dstyle.html) for those who prefer a more 
uniform syntax with the rest of the other D libraries out there.


I have completed the SPIR-V D header (which was trivial to 
generate from the .json file) and I'm also hoping to translate 
the other stuff from the LunarG SDK like the debug layers (no 
auto-generation would be possible there).


Given the advancements in the recent years of the D ecosystem 
(dub, high quality doc generators, CT generation of boilerplate, 
etc.), I think that D can offer even better developer experience 
than C++ for which the API was primary targeted.

Re: Vulkan bindings

[Kapps via Digitalmars-d]

On Thursday, 18 February 2016 at 03:38:42 UTC, Kapps wrote:


This is what I did with OpenGL for my own bindings. It had some 
nice benefits like having the documentation be (mostly) 
accessible.


Unfortunately, turns out the spec contains a lot of typos, 
including wrong arguments / function names.


And I should clarify, ahead of time to generate a .d file, not at 
compile-time. :P

Re: Vulkan bindings

[Kapps via Digitalmars-d]

On Thursday, 18 February 2016 at 03:27:55 UTC, Alex Parrill wrote:

On Tuesday, 16 February 2016 at 19:01:58 UTC, Satoshi wrote:

Hello Vulkan API 1.0 is here and I just wrapped it into D.

https://github.com/Rikarin/VulkanizeD

Have fun!


Please consider making it a Dub package!

(IMO It would be cool to generate OpenGL and Vulkan bindings 
directly from the XML spec; std.xml doesn't work in CTFE. 
Though it would probably take a long time to compile)


This is what I did with OpenGL for my own bindings. It had some 
nice benefits like having the documentation be (mostly) 
accessible.


Unfortunately, turns out the spec contains a lot of typos, 
including wrong arguments / function names.

Re: Vulkan bindings

[Alex Parrill via Digitalmars-d]

On Tuesday, 16 February 2016 at 19:01:58 UTC, Satoshi wrote:

Hello Vulkan API 1.0 is here and I just wrapped it into D.

https://github.com/Rikarin/VulkanizeD

Have fun!


Please consider making it a Dub package!

(IMO It would be cool to generate OpenGL and Vulkan bindings 
directly from the XML spec; std.xml doesn't work in CTFE. Though 
it would probably take a long time to compile)

Re: Official compiler

[rsw0x via Digitalmars-d]

On Thursday, 18 February 2016 at 02:29:52 UTC, Márcio Martins 
wrote:

On Thursday, 18 February 2016 at 00:06:10 UTC, Xinok wrote:
On Wednesday, 17 February 2016 at 22:57:20 UTC, Márcio Martins 
wrote:
I was reading the other thread "Speed kills" and was 
wondering if there is any practical reason why DMD is the 
official compiler?


...


I pretty much asked this same question a little over a year 
ago. Thread is here:


http://forum.dlang.org/thread/mjwitvqmaqlwvoudj...@forum.dlang.org


I am not proposing a new backend for DMD, that discussion is 
going nowhere. I am considering changing the compiler that is 
tagged as "official", instead.


It would probably be for the best if there was some push to make 
LDC 'the' D compiler over a 6 month or 1 year period that 
included getting LDC and DMD perfectly in sync(AFAIK there's 
currently heavily refactoring going on in the frontend to help 
this?)


LDC has the downside in that it's a lot slower than DMD. I've 
never worked on the LDC codebase so I'm not even sure if this 
could be fixed.

Re: Official compiler

[Márcio Martins via Digitalmars-d]

On Thursday, 18 February 2016 at 00:06:10 UTC, Xinok wrote:
On Wednesday, 17 February 2016 at 22:57:20 UTC, Márcio Martins 
wrote:
I was reading the other thread "Speed kills" and was wondering 
if there is any practical reason why DMD is the official 
compiler?


...


I pretty much asked this same question a little over a year 
ago. Thread is here:


http://forum.dlang.org/thread/mjwitvqmaqlwvoudj...@forum.dlang.org


I am not proposing a new backend for DMD, that discussion is 
going nowhere. I am considering changing the compiler that is 
tagged as "official", instead.

Re: Official compiler

[rsw0x via Digitalmars-d]

On Wednesday, 17 February 2016 at 22:57:20 UTC, Márcio Martins 
wrote:
I was reading the other thread "Speed kills" and was wondering 
if there is any practical reason why DMD is the official 
compiler?


[...]


Developer politics, I believe.
I'm curious where Andrei stands on this issue, IIRC he was upset 
at one point that dmd could not be redistributed properly on 
linux distros.

Re: Official compiler

[Márcio Martins via Digitalmars-d]

On Thursday, 18 February 2016 at 00:35:01 UTC, Chris Wright wrote:

On Wed, 17 Feb 2016 22:57:20 +, Márcio Martins wrote:

I was reading the other thread "Speed kills" and was wondering 
if there is any practical reason why DMD is the official 
compiler?


Walter Bright is the lead developer, and for legal reasons he 
will never touch source code from a compiler he didn't write. 
And since DMD is something like twice as fast as LDC, there's 
at least some argument in favor of keeping it around.


Should Walter retire, there's a reasonable chance that LDC will 
become the primary compiler. However, compilation speed is 
important.


I'm not sure how different LDC and DMD are, but perhaps you 
could use DMD for development and LDC for production builds?


Hmm, I think most of us involved with D for a while know which 
compiler to use and why, right?


But would it be beneficial to D as a language if we could make it 
so that the first compiler a newcomer interacts with, will be the 
one that produces code as fast as C/C++?


Walter and everyone else could continue working on DMD as the 
reference compiler and pushing language features. Everyone that 
uses DMD could continue using it. Nothing would have to change, 
except for the website, and perhaps some work on building 
installers for LDC and GDC to also a "Easy installation" 
description on the downloads section :)


Purely a marketing move, if that makes sense, I don't know...

Re: Head Const

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 17 February 2016 at 23:47:54 UTC, Walter Bright 
wrote:

On 2/17/2016 3:12 PM, Jonathan M Davis wrote:
On Wednesday, 17 February 2016 at 22:44:27 UTC, Walter Bright 
wrote:


It would seem that implementing headconst as a type 
constructor would let
people who wanted mutable members have their way, without 
introducing

backdoors in const.


I really don't see how that's the same thing at all. The main 
problems with
const pop up when what folks need is something like C++'s 
mutable, because they
need to be able to do something like a reference count or a 
mutex which is not
really part of the logical state of the object but is still 
part of the object.
Having some form of non-transitive const allows for things 
like a const pointer
to non-const data, but it doesn't help at all when what you 
need to do is treat
most of the object as const while treating a small portion of 
it as mutable.
Sure, that's not completely transitive, because parts of the 
object are mutable,
but it's specific parts of the object, not which part of a 
pointer declaration
is const and which isn't. Maybe I'm missing something, but I 
don't see how
adding non-transitive const to D in order to solve the C++ 
declaration problem
would help at all with the complaints that folks have with D's 
const. The
complaints with D's const are almost entirely about the lack 
of backdoors (be
they well-defined like a mutable attribute or a free-for-all 
like casting away

const and mutating).


If the headconst was one level up, the struct can have mutating 
members.


Yes, but that really isn't going to help much code. It would be 
useless for ref-counting const objects, it wouldn't allow you to 
put a mutex in a const object, and you couldn't do anything with 
caching calculated properties in a const object. All it means is 
that you can do something like have a const pointer to a mutable 
object, which in my experience is usually useless. There have 
been plenty of complaints about having to use Rebindable instead 
of having tail-const for classes, but I've rarely seen anyone 
complain about the lack of head-const. And what's usually the 
case is that folks want logical const, and I don't see how that's 
possible without either having something similar to C++'s mutable 
or make it well-defined to cast away const and mutate.


Having something similar to C++'s mutable would at least solve 
most of the problem while making it explicit and safe, whereas 
allowing casting away const and mutating would just throw all of 
the guarantees of const out the window and risk serious problems 
with immutable, making it so that all const really did was 
prevent accidental mutation and serve as documentation of intent. 
Something like @mutable would at least retain the guarantees that 
we currently have when @mutable isn't used and restrict the 
effects of removing const to very well defined areas such that it 
wouldn't run afoul of immutable.


So, if we want to actually solve the problems that folks 
typically complain about with const, I think that something like 
@mutable is the way to go. Now, we can certainly decide that 
that's not worth it and that those idioms simply won't work in D 
as long as const is used, but I really don't think that 
head-const is going to solve the same problem at all or really 
make much of anyone much happier aside from how it helps with C++ 
interoperability. Adding tail-const for classes to the language 
would make a whale of a lot more people happy than head-const 
would even though Rebindable ostensibly solves that problem 
already.


- Jonathan M Davis

Re: Official compiler

[Chris Wright via Digitalmars-d]

On Wed, 17 Feb 2016 22:57:20 +, Márcio Martins wrote:

> I was reading the other thread "Speed kills" and was wondering if there
> is any practical reason why DMD is the official compiler?

Walter Bright is the lead developer, and for legal reasons he will never 
touch source code from a compiler he didn't write. And since DMD is 
something like twice as fast as LDC, there's at least some argument in 
favor of keeping it around.

Should Walter retire, there's a reasonable chance that LDC will become 
the primary compiler. However, compilation speed is important.

I'm not sure how different LDC and DMD are, but perhaps you could use DMD 
for development and LDC for production builds?

Re: Another new io library

[deadalnix via Digitalmars-d]

On Wednesday, 17 February 2016 at 23:15:51 UTC, Jonathan M Davis 
wrote:

On Wednesday, 17 February 2016 at 22:47:27 UTC, deadalnix wrote:
See async/await in C# 
(https://msdn.microsoft.com/fr-fr/library/hh191443.aspx)


Or for those poor souls who can't read French... ;)

https://msdn.microsoft.com/en-us/library/hh191443.aspx

- Jonathan M Davis


Thank you for the fixup :)

Re: Official compiler

[Xinok via Digitalmars-d]

On Wednesday, 17 February 2016 at 22:57:20 UTC, Márcio Martins 
wrote:
I was reading the other thread "Speed kills" and was wondering 
if there is any practical reason why DMD is the official 
compiler?


...


I pretty much asked this same question a little over a year ago. 
Thread is here:


http://forum.dlang.org/thread/mjwitvqmaqlwvoudj...@forum.dlang.org

Re: Head Const

[Walter Bright via Digitalmars-d]

On 2/17/2016 3:12 PM, Jonathan M Davis wrote:

On Wednesday, 17 February 2016 at 22:44:27 UTC, Walter Bright wrote:


It would seem that implementing headconst as a type constructor would let
people who wanted mutable members have their way, without introducing
backdoors in const.


I really don't see how that's the same thing at all. The main problems with
const pop up when what folks need is something like C++'s mutable, because they
need to be able to do something like a reference count or a mutex which is not
really part of the logical state of the object but is still part of the object.
Having some form of non-transitive const allows for things like a const pointer
to non-const data, but it doesn't help at all when what you need to do is treat
most of the object as const while treating a small portion of it as mutable.
Sure, that's not completely transitive, because parts of the object are mutable,
but it's specific parts of the object, not which part of a pointer declaration
is const and which isn't. Maybe I'm missing something, but I don't see how
adding non-transitive const to D in order to solve the C++ declaration problem
would help at all with the complaints that folks have with D's const. The
complaints with D's const are almost entirely about the lack of backdoors (be
they well-defined like a mutable attribute or a free-for-all like casting away
const and mutating).


If the headconst was one level up, the struct can have mutating members.

Re: Another new io library

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 17 February 2016 at 22:47:27 UTC, deadalnix wrote:
See async/await in C# 
(https://msdn.microsoft.com/fr-fr/library/hh191443.aspx)


Or for those poor souls who can't read French... ;)

https://msdn.microsoft.com/en-us/library/hh191443.aspx

- Jonathan M Davis

Re: Head Const

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 17 February 2016 at 22:44:27 UTC, Walter Bright 
wrote:


It would seem that implementing headconst as a type constructor 
would let people who wanted mutable members have their way, 
without introducing backdoors in const.


I really don't see how that's the same thing at all. The main 
problems with const pop up when what folks need is something like 
C++'s mutable, because they need to be able to do something like 
a reference count or a mutex which is not really part of the 
logical state of the object but is still part of the object. 
Having some form of non-transitive const allows for things like a 
const pointer to non-const data, but it doesn't help at all when 
what you need to do is treat most of the object as const while 
treating a small portion of it as mutable. Sure, that's not 
completely transitive, because parts of the object are mutable, 
but it's specific parts of the object, not which part of a 
pointer declaration is const and which isn't. Maybe I'm missing 
something, but I don't see how adding non-transitive const to D 
in order to solve the C++ declaration problem would help at all 
with the complaints that folks have with D's const. The 
complaints with D's const are almost entirely about the lack of 
backdoors (be they well-defined like a mutable attribute or a 
free-for-all like casting away const and mutating).


- Jonathan M Davis

Official compiler

[Márcio Martins via Digitalmars-d]

I was reading the other thread "Speed kills" and was wondering if 
there is any practical reason why DMD is the official compiler?


Currently, newcomers come expecting their algorithm from rosetta 
code to run faster in D than their current language, but then it 
seems like it's actually slower. What gives?


Very often the typical answer from this community is generally 
"did you use LDC/GDC?".


Wouldn't it be a better newcomer experience if the official 
compiler was either LDC or GDC?
For us current users it really doesn't matter what is labelled 
official, we pick what serves us best, but for a newcomer, the 
word official surely carries a lot of weight, doesn't it?


From a marketing point of view, is it better for D as a language 
that first-timers try the bleeding-edge, latest language features 
with DMD, or that their expectations of efficient native code are 
not broken?


Apologies if this has been discussed before...

Re: Another new io library

[deadalnix via Digitalmars-d]

First, I'm very happy to see that. Sounds like a good project. 
Some remarks:
 - You seems to be using classes. These are good to compose at 
runtime, but we can do better at compile time using value types. 
I suggest using value types and have a class wrapper that can be 
used to make things composable at runtime if desirable.
 - Being able to read.write from an io device in a generator like 
manner is I think important if we are rolling out something new. 
Literally the only thing that can explain the success of Node.js 
is this (everything else is crap). See async/await in C# 
(https://msdn.microsoft.com/fr-fr/library/hh191443.aspx) or Hack 
(https://docs.hhvm.com/hack/async/introduction).

 - I like the input range stuff. Input ranges needs more love.
 - Please explain valves more.
 - ...
 - Profit ?

Re: Head Const

[Walter Bright via Digitalmars-d]

On 2/17/2016 2:31 PM, Jonathan M Davis wrote:

We _could_ have something like @mutable on member variables which made them
mutable in spite of being in a const object and which made it illegal for that
type to ever be immutable, but we'd be forced to have an additional attribute on
the type itself (e.g. @contains_mutable) because of the opaque type issue, and
at that point, the compiler could just look at the attribute on the type to know
that it couldn't be immutable, and similar to abstract, it could then require
that any type that it's a member of t hen be marked with that attribute. So,
it's uglier than simply marking a member variable with @mutable, but it's
certainly feasible.


It would seem that implementing headconst as a type constructor would let people 
who wanted mutable members have their way, without introducing backdoors in const.

Re: Head Const

[Andrei Alexandrescu via Digitalmars-d]

On 02/17/2016 04:07 PM, Walter Bright wrote:

On 2/17/2016 3:56 AM, Andrei Alexandrescu wrote:

On 02/16/2016 09:53 PM, Walter Bright wrote:

Most of what people find frustrating about D's transitive
const/immutable is its very nature of not being sloppy and full of
holes.


I thought it was the constructors and postblit that are the matter.
(It may seem
I'm on a snarky streak, but I do think that's the remaining issue with
immutable). -- Andrei


Logical const!


How do you mean that? I see no connection. -- Andrei

Re: Head Const

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 17 February 2016 at 22:06:20 UTC, Walter Bright 
wrote:

On 2/17/2016 10:54 AM, Marc Schütz wrote:

That's already covered in the DIP, see my reply to Dicebot.


Note that D supports opaque types, meaning it is not always 
possible to transitively follow all types to see if they have 
mutable members.


We _could_ have something like @mutable on member variables which 
made them mutable in spite of being in a const object and which 
made it illegal for that type to ever be immutable, but we'd be 
forced to have an additional attribute on the type itself (e.g. 
@contains_mutable) because of the opaque type issue, and at that 
point, the compiler could just look at the attribute on the type 
to know that it couldn't be immutable, and similar to abstract, 
it could then require that any type that it's a member of t hen 
be marked with that attribute. So, it's uglier than simply 
marking a member variable with @mutable, but it's certainly 
feasible.


The question really is whether we want such a backdoor in const 
and whether it's worth the extra complication. It _would_ be 
explicitly marked, making it fairly easy to determine when a 
const type might actually mutate some of its state (though 
presumably, if it's used responsibly, it would only mutate state 
that was really part of the logical state of the object - e.g. a 
mutex or a reference count). So, while const would be weakened on 
some level, it wouldn't be completely invisible, and you couldn't 
accidentally have a member variable with an @mutable member, 
since you'd be forced to mark the type containing it with 
@contains_mutable. And it _would_ allow a number of idioms that 
many folks keep wanting and complaining about without actually 
making it defined behavior to cast away const and mutate (even 
Andrei has been running into issues lately with containers and 
RCString where he's needed @mutable and then done stuff like cast 
away const and mutating, thinking that that was okay as long as 
the underlying object wasn't immutable). It would be a backdoor, 
but it would be a well-defined one rather than allowing a 
free-for-all.


I honestly don't know whether adding something like @mutable is a 
good idea or not, but it is very clear that there are a number of 
idioms that are impossible in D when const is involved that lead 
a lot of programmers to either not use const or to cast it away 
and mutate, thinking that that's okay, because it's okay in C++, 
and it does tend to work as long as immutable isn't involved, 
much as it's undefined behavior. Having @mutable would make const 
usable for a lot of programs that otherwise have to mostly 
abandon it, but it would add some extra complication to the 
language, and it would mean that there's a backdoor in const, 
even if it's one that's actually safe to use (unlike casting away 
const and mutating).


But what _is_ clear to me is that transitive const has been a big 
win, and while I can definitely live with C++'s version of const 
if I have to, it drives me nuts now that it's not transitive. 
Without transitivity, it's too easy to end up with mutable 
references to stuff from const functions, just because they're 
not directly part of the object. Transitivity fixes all that.


- Jonathan M Davis

Re: Head Const

[Walter Bright via Digitalmars-d]

On 2/17/2016 10:54 AM, Marc Schütz wrote:

That's already covered in the DIP, see my reply to Dicebot.


Note that D supports opaque types, meaning it is not always possible to 
transitively follow all types to see if they have mutable members.

Re: Head Const

[Walter Bright via Digitalmars-d]

On 2/17/2016 4:03 AM, Jakob Ovrum wrote:

How about disallowing immutable data with extern(C++) types? With extern(C++)
data always mutable, `const` could safely be reused to mean C++ const in
bindings. Any `mutable`-style code would be implemented in C++.


That doesn't help with trying to match the mangling for:

   mutable pointer to const pointer to mutable pointer to const pointer to 
mutable pointer to void


It's still an interesting idea, but it would precluded passing any D immutable 
data structures to C++ code. I tend to think such needs to be possible, with the 
proviso that you'd have to verify that the C++ end did not violate the 
immutability rules. It's normal practice to write C++ code as if const were 
transitive.

Re: OT: Vulkan released

[Xavier Bigand via Digitalmars-d]

Le 17/02/2016 12:54, Vladimir Panteleev a écrit :

On Tuesday, 16 February 2016 at 21:27:22 UTC, Ola Fosheim Grøstad wrote:

On Tuesday, 16 February 2016 at 19:03:13 UTC, Zoadian wrote:

I'll write derelict bindings.


600 lines of code to display a triangle...


I found this:

https://pbs.twimg.com/media/CbUg4_5WEAANwhc.jpg:orig


Lol I am in case where vulkan could help for my day job. But we are 
following Qt3D module that can help us for a lot of other issue with our 
current 3D engine.


Qt3D will support vulkan as backend.

Re: Any actively maintained qt bindings for D?

[Jeremy DeHaan via Digitalmars-d]

On Wednesday, 17 February 2016 at 20:56:27 UTC, Rishub Nagpal 
wrote:

Qtd hasn't been updated in 3 years
Does anyone know of anactively maintained qt library?


I think QML bindings exists, but as far as I know direct Qt 
bindings don't exist/aren't updated.


I want to do a GSoC proposal for direct bindings to Qt, though. I 
have a lot of ideas for doing a binding to Qt proper, but the 
only way I can do it is if I have time.

Re: Head Const

[Walter Bright via Digitalmars-d]

On 2/17/2016 3:56 AM, Andrei Alexandrescu wrote:

On 02/16/2016 09:53 PM, Walter Bright wrote:

Most of what people find frustrating about D's transitive
const/immutable is its very nature of not being sloppy and full of holes.


I thought it was the constructors and postblit that are the matter. (It may seem
I'm on a snarky streak, but I do think that's the remaining issue with
immutable). -- Andrei


Logical const!

Any actively maintained qt bindings for D?

[Rishub Nagpal via Digitalmars-d]

Qtd hasn't been updated in 3 years
Does anyone know of anactively maintained qt library?

Re: Can I get more opinions on increasing the logo size on the site please

[anonymous via Digitalmars-d]

On 10.02.2016 22:31, anonymous wrote:

I've shot him an email.


No response for a week. Trying a GitHub @-mention now:
https://github.com/D-Programming-Language/dlang.org/pull/1212#issuecomment-185381136

Re: Speed kills

[Basile B. via Digitalmars-d]

On Wednesday, 17 February 2016 at 19:01:38 UTC, Basile B. wrote:

That's more subtile than that.

The oldest 64 bit processor (AMD64) supports SSE, always. So 
when we do "cast(int) 0.1;" on X86_64, the backend always 
generate SSE instructions.


The oldest 32 bit processor (X86) doesn't support SSE, maybe 
MMX (not sure). So when we do "cast(int) 0.1;" on X86, the 
backend always generate FPU instructions.


This is how I understand the post 'I've landed onto'.
My current work always use SSE so it's not conform with the "at 
least available" feature.


Also, forgot to say, but an uniform API is needed to set the 
rounding mode, whether SSE is used or the FPU...

Re: Head Const

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 17 February 2016 at 19:03:25 UTC, Jonathan M Davis 
wrote:
As soon as you start using pointers or containers or pointers 
or anything like that, pretty quickly, you can get situations 
like where the container is const, but its elements aren't.


Yes, generic containers is an issue in C++. You can't just recast 
the template parameter as const, as the internals could depend on 
it not being const when the container was instantiated (if-test 
on const in the constructor). This is a problem we get when 
meta-programming becomes powerful enough.


The easy way out is to use a wrapper and implement the constness 
in the wrapper (a class with just a pointer and methods). 
Basically implement a reference type for container access.

Re: OT: Nature on the 'end' of Moore's Law

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 17 February 2016 at 18:24:36 UTC, Kagamin wrote:
I'm thinking more about distributed platforms. We made our 
server support farm configuration, and the customer was happy 
to buy 6 farm nodes and plans to add 3 more. For some reason a 
farm is cheaper than one big iron server?


It probably has to do with yield (number of faulty chips), market 
size and competition. The volume was too low for IBM, so IBM 
recently "sold" their chip manufacturing plant to Global 
Foundaries by paying them $1billion to take it. (a negative price 
of $1billion)


High end Xeon CPU (22nm):
E7-8893 v3 (45M Cache, 3.20 GHz), 4 cores
tray price: $6841
price in Norway: $11000

Desktop (14nm):
i7-6700K Processor (8M Cache, up to 4.20 GHz), 4 cores
street price in Norway: $344

The beefy Xeon has a very big cache and is more reliable, but 
slower and xpensive...

Re: Head Const

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 17 February 2016 at 18:16:54 UTC, Ola Fosheim 
Grøstad wrote:
On Wednesday, 17 February 2016 at 17:47:02 UTC, Jonathan M 
Davis wrote:
definitely sucks. But interestingly, the more I've used D, the 
less happy I've been with C++'s const. It just has too many 
holes. In particular, the fact that it's not transitive is


What you could consider in C++ is to fully encapsulate your 
field values and use member functions to access them. Which is 
considered good modelling anyway.


So if you access a member as "get_child() const", you return a 
const reference, which makes it transitive.


As soon as you start using pointers or containers or pointers or 
anything like that, pretty quickly, you can get situations like 
where the container is const, but its elements aren't. So, you 
may not be able to mutate the stuff that's directly a member of 
the class, you can still mutate stuff that it refers to or even 
owns. D doesn't allow that, which I think is a definite 
improvement. If you return a reference or pointer to a member 
variable from a const member function in D, it's const through 
and through with no holes, and I think that that is unequivocally 
a good thing.


Where things get annoying is the type of situation where you'd 
mark something mutable in C++, since those just don't work at all 
in D. You're forced to not use const or redesign what you're 
doing so that it doesn't need mutable (which usually means not 
using const).


- Jonathan M Davis

Re: Speed kills

[Basile B. via Digitalmars-d]

On Wednesday, 17 February 2016 at 18:50:45 UTC, Jack Stouffer 
wrote:

On Wednesday, 17 February 2016 at 18:26:47 UTC, Basile B. wrote:
Anyway, not good for phobos, why? When looking for 
documentation yesterday night I've landed on a post by Walter 
who explained that the library for a system programming 
language shouldn't be specific to an architecture.


While I don't know about the post you're talking about, I don't 
think what Walter says applies to internal version blocks in a 
function. You could make it so on AMD lround and friends are 
much faster by using those ASM routines. Also, std.math is 
already chock full of architecture specific code.


That's more subtile than that.

The oldest 64 bit processor (AMD64) supports SSE, always. So when 
we do "cast(int) 0.1;" on X86_64, the backend always generate SSE 
instructions.


The oldest 32 bit processor (X86) doesn't support SSE, maybe MMX 
(not sure). So when we do "cast(int) 0.1;" on X86, the backend 
always generate FPU instructions.


This is how I understand the post 'I've landed onto'.
My current works always use SSE so it's not conform with the "at 
least available" feature.

Re: Head Const

[Marc Schütz via Digitalmars-d]

On Wednesday, 17 February 2016 at 02:51:06 UTC, Walter Bright 
wrote:

On 2/16/2016 11:29 AM, Marc Schütz wrote:
For example, it's always possible to use a global mutable 
associative array to
store additional data connected with an immutable or const 
object (ignoring
purity issues for the moment). That's safe because from the 
outside, there's no
observable change to the state of the object itself, and the 
global AA's type

(shared/thread-local) prevents race conditions.


The trouble with that is you're relying on the programmer to 
ensure correctness. It'll revert D to C++ "trust the 
programmer" semantics.


Are you referring to the quoted passage, or my DIP? If the 
latter, please note that it was initially written for a different 
purpose. Operations with @mutables will be @system, which is our 
usual way to deal with situations in which the programmer has to 
ensure correctness. The unsafe (@trusted) part is very small and 
well encapsulated, the unsafety doesn't leak.




Furthermore, with the current mechanical guarantee of 
immutability, it opens up the possibility of relying on such 
beyond merely observable behavior - such as immutable data 
being placed in ROM, or special GC semantics.


That's already covered in the DIP, see my reply to Dicebot.

Re: Speed kills

[Jack Stouffer via Digitalmars-d]

On Wednesday, 17 February 2016 at 18:26:47 UTC, Basile B. wrote:
Anyway, not good for phobos, why? When looking for 
documentation yesterday night I've landed on a post by Walter 
who explained that the library for a system programming 
language shouldn't be specific to an architecture.


While I don't know about the post you're talking about, I don't 
think what Walter says applies to internal version blocks in a 
function. You could make it so on AMD lround and friends are much 
faster by using those ASM routines. Also, std.math is already 
chock full of architecture specific code.

Re: Head Const

[Marc Schütz via Digitalmars-d]

On Wednesday, 17 February 2016 at 02:20:15 UTC, Dicebot wrote:
One example of a existing guarantee you won't be able to keep, 
for example, is that any immutable allocation can be completely 
put into separate read-only memory.


Yes, and it would be rejected statically (rule 2). I therefor 
don't consider this a problem.


A very important property for building optimized allocators if 
you keep in mind sharing goals of immutability.


This is considered too (rule 3). An object can only be immutable 
if all its embedded @mutable members are marked as shared.




For example, it's always possible to use a global mutable 
associative array to store additional data connected with an 
immutable or const object (ignoring purity issues for the 
moment). That's safe because from the outside, there's no 
observable change to the state of the object itself, and the 
global AA's type (shared/thread-local) prevents race 
conditions.


Yes and this is how I believe it must be done.

There's no reason why we can't have the same guarantees for 
embedded members, without resorting to an external AA. Have a 
look at my DIP [1] for lazy initialization of const members, 
which I now realize can be adapted to this use case. 
Basically, just replace `lazy` by `@mutable`, and most of the 
DIP is still valid. I'll try updating it when I find the time.


[1] http://wiki.dlang.org/DIP85


The problem with this DIP is that it speaks about type system 
semantics and what matters first is memory model (which is 
currently very under-defined as soon as you step from a "the 
GC" world).


I'd say most of the memory model issues are the same as those 
with shared, which is just as undefined currently. That leaves 
possible reordering of accesses to immutable data. I don't have a 
complete answer to that at the moment, but most of it is likely 
also covered by the fact that the @mutable members must be shared 
in this case.




Physical immutability is demanding but it also has great value 
in its simplicity and being hard to fool. Any language change 
that is going to reject this notion has to be really strongly 
justified in terms of what is gained and what is lost and not 
come simply because expressing such semantics is possible.

Re: OT: Nature on the 'end' of Moore's Law

[Chris Wright via Digitalmars-d]

On Wed, 17 Feb 2016 18:06:00 +, Ola Fosheim Grøstad wrote:

> And well, with new materials, the potential for higher speeds.
> These researchers managed to get a silicon-germanium transistor up to
> 800Ghz (cryonic) and the article speaks of the possibility of running at
> Thz.
> 
> http://www.news.gatech.edu/2014/02/17/silicon-germanium-chip-sets-new-
speed-record
> 
> Moore's law deals with the number of transistors on the same chip. But
> who cares if you can have faster and more?

Distance penalties.

First there's the design issue of routing electrical impulses to 
different parts of the chip without interfering with other paths. You can 
solve that by making the chip even bigger, and you can partially address 
it with heavy duty constraint solvers.

Then there's that pesky speed of electrical signal transmission. A bigger 
chip incurs that penalty more often.

One thing you can do is simply replicate your CPU multiple times. We 
currently have multicore CPUs to do this in a convenient way, but this 
involves some caution with cache invalidation and shared memory. Muck 
about with scheduling and shared memory stuff and you could get more 
isolated parallelism, allowing cheaper manycore CPUs. Not sure if that 
would be much of a benefit.

OT: Need help with translation D-faq to other languages

[Suliman via Digitalmars-d]

Hello, I wrote pretty good FAQ about D on Russian language. I 
need help with translation it to English and Germany and possible 
to other languages.


http://dlang.ru/Why-D-is-Better

I hope it people will like it, it will help to attract more 
people and help noobs better understand what D is.

Re: Speed kills

[Basile B. via Digitalmars-d]

On Monday, 15 February 2016 at 23:13:13 UTC, Jack Stouffer wrote:

On Monday, 15 February 2016 at 22:29:00 UTC, Basile B. wrote:
we could get ceil/trunc/round/floor, also almost as easily 
fmod, hypoth.

classic but I dont get why thery're not in std.math.


Seems like you know a lot about the subject, and I know you 
contributed to phobos before, so how about making a PR for this 
:)


In the meantime:

https://github.com/BBasile/iz/blob/master/import/iz/math.d

Actually when i've participated to this conversation I didn't 
remember that it was not good on X86. Using SSE rouding is really 
only good on AMD64, otherwise loading the input parameter "sucks" 
a lot (even for a 32 bit float since it's not directly in EAX or 
XMMO).


Anyway, not good for phobos, why? When looking for documentation 
yesterday night I've landed on a post by Walter who explained 
that the library for a system programming language shouldn't be 
specific to an architecture.

Re: OT: Nature on the 'end' of Moore's Law

[Kagamin via Digitalmars-d]

On Wednesday, 17 February 2016 at 17:57:11 UTC, Ola Fosheim 
Grøstad wrote:

On Wednesday, 17 February 2016 at 17:10:37 UTC, Kagamin wrote:
On Tuesday, 16 February 2016 at 18:28:19 UTC, Laeeth Isharc 
wrote:

A pity given data sets keep getting bigger.


Can't it be parallelized on server, and client will only 
receive presentable data? Then your only concern will be 
energy consumption.


Yes, it looks like server/HPC increasingly is becoming a 
separate CPU market again.
I read somewhere that next gen high end APU from AMD might have 
a TDP of 200/300W (pretty hot) and basically integrate a 
full-blown GPU and use HBM memory (>128GB/s?).


I'm thinking more about distributed platforms. We made our server 
support farm configuration, and the customer was happy to buy 6 
farm nodes and plans to add 3 more. For some reason a farm is 
cheaper than one big iron server?

Re: Head Const

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 17 February 2016 at 17:47:02 UTC, Jonathan M Davis 
wrote:
definitely sucks. But interestingly, the more I've used D, the 
less happy I've been with C++'s const. It just has too many 
holes. In particular, the fact that it's not transitive is


What you could consider in C++ is to fully encapsulate your field 
values and use member functions to access them. Which is 
considered good modelling anyway.


So if you access a member as "get_child() const", you return a 
const reference, which makes it transitive.


What is annoying in C++ is that there is no getter/setter 
syntax...

Re: OT: Nature on the 'end' of Moore's Law

[Ola Fosheim Grøstad via Digitalmars-d]

And well, with new materials, the potential for higher speeds. 
These researchers managed to get a silicon-germanium transistor 
up to 800Ghz (cryonic) and the article speaks of the possibility 
of running at Thz.


http://www.news.gatech.edu/2014/02/17/silicon-germanium-chip-sets-new-speed-record

Moore's law deals with the number of transistors on the same 
chip. But who cares if you can have faster and more?

Re: Allocation failures

[Marc Schütz via Digitalmars-d]

On Wednesday, 17 February 2016 at 01:09:20 UTC, Adam D. Ruppe 
wrote:
On Wednesday, 17 February 2016 at 00:45:35 UTC, Chris Wright 
wrote:
http://dpldocs.info/search/search?searchTerm=emplace to create 
an exception object in manually allocated memory.


Aye, this overload: 
http://dpldocs.info/experimental-docs/std.conv.emplace.3.html


though the example there is awful, wtf is it even trying to 
show?


I guess it is primarily supposed to be a unittest to verify that 
emplace works with interfaces...

Re: OT: Nature on the 'end' of Moore's Law

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 17 February 2016 at 17:10:37 UTC, Kagamin wrote:
On Tuesday, 16 February 2016 at 18:28:19 UTC, Laeeth Isharc 
wrote:

A pity given data sets keep getting bigger.


Can't it be parallelized on server, and client will only 
receive presentable data? Then your only concern will be energy 
consumption.


Yes, it looks like server/HPC increasingly is becoming a separate 
CPU market again.
I read somewhere that next gen high end APU from AMD might have a 
TDP of 200/300W (pretty hot) and basically integrate a full-blown 
GPU and use HBM memory (>128GB/s?).


Intel is going from 14nm to 10nm in 2017. IBM has succeeded with 
7nm silicon-germanium and it is projected for 2018?


So yes, sure, density is reaching a limit, but that does not mean 
that you won't get more effective CPUs, larger dies, stacked 
layers, higher yields (cheaper chips), more cpus per server, 
integrated cooling solutions, cheaper FPGAs, faster memory etc...

Re: Head Const

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 17 February 2016 at 17:25:40 UTC, rsw0x wrote:
It's weird because usually D prefers the practical solution 
over the ivory tower one. Nearly every time I end up using 
immutable or const for anything beyond say, a trivial function 
parameter, I always end up removing it.
My C++ code is often far, far more 'const correct' than my D 
code.


Well, Walter's take on it is that because C++'s const doesn't 
actually guarantee anything, it really isn't much different from 
simply documenting your code, and it's essentially useless. And 
to a point, he's right. All C++'s const does is prevent 
accidental mutation and serve as documentation that the code 
isn't supposed to mutate the logical state of the object. It's 
trivially circumvented to the point that it doesn't actually 
guarantee anything and can't actually be relied on for anything.


So, essentially the argument is that C++'s const isn't actually 
practical. It's just fooling you into thinking that you're 
getting guarantees that you're not actually getting.


But in practice, it does prevent accidental mutation, and as long 
as the programmer is behaving themselves reasonably well, it 
functions as documentation. And IMHO that definitely is worth 
something, much as Walter thinks that it isn't. So, while C++'s 
const doesn't really guarantee much, I'd much rather have it than 
nothing.


A lot of what it comes down to though from a purely practical 
standpoint is that because we have immutable, const naturally 
becomes more restrictive, and while immutable obviously can't be 
used in many cases, it _does_ allow for cleaner, more efficient 
code where it can be used. So, as soon as you have immutable, 
you're almost forced to go to where D is with const - at least as 
long as const can refer to something that's immutable.


Unfortunately, the net result is that while const is still very 
useful, there are a lot of cases in D where you can't use it, and 
you have to be a lot more careful about how and when you use it 
such that it gets used far less than in C++, and while where it 
_is_ used does provide much better guarantees, you lose out on a 
lot of protection against accidental mutation that your typical 
C++ code gets.


Personally, I'm quite divided on the matter. The extra guarantees 
of D's const are very nice to have, but since it doesn't have any 
backdoors, there are a number of idioms that simply can't be done 
in D as long as const is involved, which definitely sucks. But 
interestingly, the more I've used D, the less happy I've been 
with C++'s const. It just has too many holes. In particular, the 
fact that it's not transitive is incredibly annoying, making it 
trivial to have cases where you give mutable access to something 
where you intended for it to be const, but it was only partially 
const. Even if we were to do something like add @mutable to D, I 
never want to see non-transitive const in D, and I wish that 
C++'s const were transitive, even if all of the rest of it was 
the same.


- Jonathan M Davis

Re: Head Const

[rsw0x via Digitalmars-d]

On Tuesday, 16 February 2016 at 10:31:05 UTC, Guillaume Piolat 
wrote:
On Tuesday, 16 February 2016 at 01:04:44 UTC, Walter Bright 
wrote:
2. supports single assignment style of programming, even if 
the data is

otherwise mutable

Like 'final'?  We did get rid of that...


Maybe we should resurrect it.


I'm trying to say it politely.
D2 const story is more complicated than its competitors.

Both D1 "final" and C++ const always felt more useful and 
practical to me that the whole D2 immutable/const/inout thing. 
The current scheme seems to have marginal value in practice, 
lots of complexity, and is harder to use well (Unqual, inout) 
etc. Constructors can break it. I don't know why we should be 
that happy about our constness, maybe someone can explain.


+1

It's weird because usually D prefers the practical solution over 
the ivory tower one. Nearly every time I end up using immutable 
or const for anything beyond say, a trivial function parameter, I 
always end up removing it.

My C++ code is often far, far more 'const correct' than my D code.

Re: OT: Nature on the 'end' of Moore's Law

[Kagamin via Digitalmars-d]

On Tuesday, 16 February 2016 at 18:28:19 UTC, Laeeth Isharc wrote:

A pity given data sets keep getting bigger.


Can't it be parallelized on server, and client will only receive 
presentable data? Then your only concern will be energy 
consumption.

Re: OT: Vulkan released

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 17 February 2016 at 11:54:22 UTC, Vladimir 
Panteleev wrote:

I found this:

https://pbs.twimg.com/media/CbUg4_5WEAANwhc.jpg:orig


Yes, Vulkan seems to be more suited for building a generic engine 
than a small scale application.

Re: Allocation failures

[Chris Wright via Digitalmars-d]

On Wed, 17 Feb 2016 02:24:51 +, cym13 wrote:

> On Wednesday, 17 February 2016 at 02:23:34 UTC, cym13 wrote:
>> Such errors are static errors, they aren't allocated on the stack, a
>> 128 bytes buffer is shared accross threads to keep them.
> 
> Sorry, of course I meant they *are* allocated on the stack.

In the context of exceptions, you can't allocate them on the stack at the 
point at which you throw them. As soon as you throw them, the stack frame 
is invalidated (to run destructors for stack-scoped items, possibly other 
things), so your exception object is at least moderately likely to be 
corrupted.

You *could* allocate them on the stack in, say, main(), but then you'd 
have to pass a reference to them down the stack somehow. Kind of awkward.

Re: Implement the "unum" representation in D ?

[jmh530 via Digitalmars-d]

On Wednesday, 17 February 2016 at 08:11:21 UTC, Nick B wrote:

Hi

John Gustafson was in town (Wellington, NZ) for the Multicore 
World Conference 2016 ( http://www.multicoreworld.com/) 
conference. I caught up with him, tonight, and spoke to him for 
about two hours. Here is a quick summary of what we discussed.  
John has just redesigned Unums, to address the design issues in 
version 1.0.  He presented his Powerpoint presentation to the 
conference, with the details of Unums 2.0 (this is a tentative 
name at present).  Its a improved design, but I will only brief 
detail it:  "It  will have  more dynamic range with 16-bit 
values than IEEE half-precision, but only by a small amount. 
Still remarkable to be uniformly better in dynamic range and 
precision, with support for inexact values and perfect 
reciprocation. If a language supports just one unum data type, 
John believes it should be the 16-bit one".  John has agreed to 
provide a link to the Powerpoint presentation, in a couple of 
weeks, and then later, a link to his new published paper on the 
subject, when it is ready.  There will likely be a new book, 
building on version 1.0, and, again, tentatively titled 'Unums 
2.0'. I also discussed with him, about integrating it with D. 
At the present, there is a 'C' codebase under construction, but 
this could be rewritten in D in the future.  D may require some 
language changes, and a new phobos library, to support this 
advanced functionality. Of course Walter will have decide if he 
wants this advanced numbering system as a part of D.




I would be interested in the Powerpoint when it becomes available.

As for getting it to work in D, I'm not sure how much language 
changes would be necessary. If they can get it to work in C, then 
surely it would work in D. After all, the book has an 
implementation in python (albeit this is not the latest and great 
version apparently).


Wrt phobos, I would just recommend that whatever unum library 
gets eventually written has a companion with the equivalent of 
the functions from std.math.

Re: Head Const

[Shachar Shemesh via Digitalmars-d]

On 16/02/16 12:31, Guillaume Piolat wrote:

I'm trying to say it politely.
D2 const story is more complicated than its competitors.

Both D1 "final" and C++ const always felt more useful and practical to
me that the whole D2 immutable/const/inout thing. The current scheme
seems to have marginal value in practice, lots of complexity, and is
harder to use well (Unqual, inout) etc. Constructors can break it. I
don't know why we should be that happy about our constness, maybe
someone can explain.



Seconded. It is one of the main tools I was using in C++ to avoid 
introducing bugs that I find completely unusable in D.


I've tried to introduce it into code I'm writing. I'm used to such 
things being a problem to add later for code that was not written this 
way in advance. That's the case in C++ too. Here, however, there are 
many cases where I simply couldn't get it to the finish line. Between 
not being able to have head const, needing to mutate vars in a const 
object (a la refcount) and the compiler deciding functions are pure, I 
often end up facing a problem where I say "okay, forget it".


And that's a real shame. We have at least one case where we're 
introducing runtime checks to make sure no one is accidentally changing 
a global var put there for reference, where declaring it const would 
have provided compile time assurance that we're okay.


Shachar

Re: Allocation failures

[Chris Wright via Digitalmars-d]

On Wed, 17 Feb 2016 01:09:20 +, Adam D. Ruppe wrote:

> On Wednesday, 17 February 2016 at 00:45:35 UTC, Chris Wright wrote:
>> http://dpldocs.info/search/search?searchTerm=emplace to create an
>> exception object in manually allocated memory.
> 
> Aye, this overload:
> http://dpldocs.info/experimental-docs/std.conv.emplace.3.html
> 
> though the example there is awful, wtf is it even trying to show?
> 
> 
> But anyway, you can also throw a static object. That's actually what
> outOfMemoryError does
> 
> - it throws a statically allocated object.

Sure, but that's pretty annoying. You have to ensure that you will never 
need to throw two of the same exception at the same time -- or you 
allocate several statically and go through hoops to ensure you're using 
one that's not currently in use.

It's a lot easier to malloc and free exceptions. Since they're presumably 
only cropping up in exceptional circumstances, there's a lot less worry 
about making many small allocations.

Re: Allocation failures

[Mike Parker via Digitalmars-d]

On Wednesday, 17 February 2016 at 14:01:17 UTC, Jardík wrote:


consider this solved (where can I mark it as such?).


The forum is a web fronted for a news server. No such feature.

Re: Head Const

[sclytrack via Digitalmars-d]

On Wednesday, 17 February 2016 at 12:46:08 UTC, Jonathan M Davis 
wrote:
but violate the type system by casting away const and mutating, 
not realizing that unlike C++, it's undefined behavior in D.


Regardless of whether Walter's (and thus D's) stance on const 
is the right one, it clearly doesn't jive with what a lot of 
folks (particularly those from C++) are looking for or 
expecting.


- Jonathan M Davis


struct (bla1, bla2) Test
{
int rc;
bla1 int number;
(bla2) Payload payload;

void doSomething() (shared, immutable)
{
}
}

(shared, immutable) Test obj;

bla1 becomes shared and bla2 becomes immutable, but
the payload might not be immutable because it is
(bla2) instead of just bla2.
---
Can it be made in a way that the blablas do not
participate in the static if?

Could "shared", "immutable" be separated from
the type int, float?

(shared, immutable) Test!(int, float) obj;
---
I did some "const(immutable) int" and the the
compiler says basic type expected.

What is the basic type from "const(shared, immutable)",
would that be "const(shared const, const)"?

And then the basic type from "const(const, immutable)"
would be "const".
---
Also would it be possible to determine the implicit
conversion rules based solely on these qualifiers and
not on the content of the object?

(const, const) Test t = new (const, immutable) Test();
const Test t = new (const,const) Test();
---

Re: Another new io library

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 17 February 2016 at 10:54:56 UTC, John Colvin wrote:
Why not just say it's a ubyte and then compose with ranges from 
there?


You could put a range interface on it... but I think it would be 
of very limited value. For one, what about fseek? How does that 
interact with the range interface?



Or, what about reading a network interface where you get 
variable-sized packets?


A ubyte[] is probably the closest thing you can get to 
usefulness, but even then you'd need non-range buffering controls 
to make it efficient and usable. Consider the following:


Packet 1: 11\nHello
Packet 2:  World05\nD ro
Packet 3: x


You take the ubyte[] thing that gives each packet at a time as it 
comes off the hardware interface. Good, you can process as it 
comes and it fits the range interface.


But it isn't terribly useful. Are you going to copy the partial 
message into another buffer so the next range.popFront doesn't 
overwrite it? Or will you present the incomplete message from 
packet 1 to the consumer? The former is less than efficient (and 
still needs to wrap the range in some other interface to make the 
user code pretty) and the latter leads to ugly user code being 
directly exposed.


Copying it into a buffer is probably the most sane... but it is a 
wasteful copy if your existing buffer has enough space. But how 
to you say that to a range? popFront takes no arguments.


What about packet 2, which has part of the first message and part 
of the second message? Can you tell it that you already consumed 
the first six bytes and it can now append the next packet to the 
existing buffer, but please return that slice on the next call?




Ranges are great for a sequence of data that is the same type on 
each call. Files, however, tend to have variable length (which 
you might want to skip large sections of) and different types of 
data as you iterate through them.


I find std.stdio's byChunk and byLine to be almost completely 
useless in my cases.

Re: Allocation failures

[Jardík via Digitalmars-d]

On Wednesday, 17 February 2016 at 06:52:21 UTC, thedeemon wrote:
So keep GC heap for small litter (including exceptions) and use 
other allocators for large pieces of data. This way you may get 
best of what D offers without long-GC-pause or 
out-of-memory-termination pains.


I will probably do that. Since others said I can actually catch 
that out of memory error and that the destructors will run (and 
thus free some of the resources) I see no problem in writing it 
in D. I am happy it doesn't force abort()s as some other 
languages (rust) or libraries (glib). Thank you everyone for 
answering my questions and consider this solved (where can I mark 
it as such?).

Re: Head Const

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 17 February 2016 at 11:56:29 UTC, Andrei 
Alexandrescu wrote:

On 02/16/2016 09:53 PM, Walter Bright wrote:

Most of what people find frustrating about D's transitive
const/immutable is its very nature of not being sloppy and 
full of holes.


I thought it was the constructors and postblit that are the 
matter. (It may seem I'm on a snarky streak, but I do think 
that's the remaining issue with immutable). -- Andrei


Yes, those are design problems with D's const that we really need 
to figure out how to fix, but they're not necessarily what people 
complain about. Many folks want to be able to do things like lazy 
initialization or caching or have a mutable reference count in a 
const/immutable object. The problems that usually come up 
basically boil down to folks wanting logical const rather than 
the compiler actually guaranteeing that data cannot be mutated 
via a const reference to that data without violating the type 
system. Lots of people basically want holes in const, because 
that's what C++ has, and not having holes in const prevents a 
number of potentially useful idioms (heck, you were trying to get 
around it with a container that you posted in the main newsgroup 
semi-recently and in RCString when you posted about it in 
dlang-study the other day).


We need to solve the constructor/postblit issues in order for D's 
const to really work like it's supposed to, but even if that 
problem were solved, the basic tenet of D's design for const - 
that it has no backdoors - is what really makes it so that many 
folks avoid const completely, whereas others use it but violate 
the type system by casting away const and mutating, not realizing 
that unlike C++, it's undefined behavior in D.


Regardless of whether Walter's (and thus D's) stance on const is 
the right one, it clearly doesn't jive with what a lot of folks 
(particularly those from C++) are looking for or expecting.


- Jonathan M Davis

Re: [dlang.org] Getting the ddox pages out of limbo

[Sönke Ludwig via Digitalmars-d]

Am 12.02.2016 um 18:19 schrieb anonymous:

ddox has a number of issues that make it currently not feasible to just
switch over:

* Macro for "path to base of docs"?
 https://github.com/rejectedsoftware/ddox/issues/87


I'm a little worried about introducing such special behavior, because it 
could lead to doc comments that are incompatible with vanilla Ddoc.


* macros from parent scopes are not known in child scopes
 https://github.com/rejectedsoftware/ddox/issues/116

* treating of underscore not consistent with dmd
 https://github.com/rejectedsoftware/ddox/issues/117


Both fixed now.

Re: Vulkan bindings

[Satoshi via Digitalmars-d]

On Wednesday, 17 February 2016 at 10:55:22 UTC, Rikki Cattermole 
wrote:

On 17/02/16 8:01 AM, Satoshi wrote:

Hello Vulkan API 1.0 is here and I just wrapped it into D.

https://github.com/Rikarin/VulkanizeD

Have fun!


Btw you removed Khronos header/license declaration.
I'm copying back the original to my variation of these bindings.


Fixed.

Re: Head Const

[Jakob Ovrum via Digitalmars-d]

On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote:

rears its head again :-)

Head Const is what C++ has for const, i.e. it is not 
transitive, applies to one level only. D has transitive const.


What head const will do for us:

1. make it easy to interface to C++ code that uses const, as 
currently it is not very practical to do so, you have to resort 
to pragma(mangle)


2. supports single assignment style of programming, even if the 
data is otherwise mutable


The downside is, of course, language complexity.


How about disallowing immutable data with extern(C++) types?  
With extern(C++) data always mutable, `const` could safely be 
reused to mean C++ const in bindings. Any `mutable`-style code 
would be implemented in C++.

Re: Head Const

[Andrei Alexandrescu via Digitalmars-d]

On 02/16/2016 09:53 PM, Walter Bright wrote:

Most of what people find frustrating about D's transitive
const/immutable is its very nature of not being sloppy and full of holes.


I thought it was the constructors and postblit that are the matter. (It 
may seem I'm on a snarky streak, but I do think that's the remaining 
issue with immutable). -- Andrei

Re: Head Const

[Andrei Alexandrescu via Digitalmars-d]

On 02/16/2016 09:51 PM, Walter Bright wrote:

On 2/16/2016 11:29 AM, Marc Schütz wrote:

For example, it's always possible to use a global mutable associative
array to
store additional data connected with an immutable or const object
(ignoring
purity issues for the moment). That's safe because from the outside,
there's no
observable change to the state of the object itself, and the global
AA's type
(shared/thread-local) prevents race conditions.


The trouble with that is you're relying on the programmer to ensure
correctness. It'll revert D to C++ "trust the programmer" semantics.


That doesn't seem the case to me. -- Andrei

Re: OT: Vulkan released

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 16 February 2016 at 21:27:22 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 16 February 2016 at 19:03:13 UTC, Zoadian wrote:

I'll write derelict bindings.


600 lines of code to display a triangle...


I found this:

https://pbs.twimg.com/media/CbUg4_5WEAANwhc.jpg:orig

Re: Head Const

[Andrei Alexandrescu via Digitalmars-d]

On 02/16/2016 09:44 PM, Walter Bright wrote:

On 2/16/2016 5:35 AM, Dicebot wrote:

In my opinion @mutable would be a disaster of much higher destructive
impact than head const. I am very opposed to it no matter how it is
designed. Once you start considering it, you are better at simply
throwing away existing const system and starting it all from scratch
with D3. Logical const is harmful as it doesn't give and serious
guarantees but gives developer a false sense of confidence.



I agree with you on that, and I've argued from that position before.

Note that head const does not introduce any watering down nor
destruction of the const/immutable/sharing type system. The main
downside of head const would be language complexity.


I profoundly oppose such an outlook. It has a name - prejudice, pure and 
simple. Rejecting possible future ideas "no matter what" even before 
they exist is extremely damaging.


Consider:

"I oppose implicit narrowing conversions regardless how they are designed"

"static if is fundamentally flawed"

"Variadics cannot be both simple and safe"

etc.


Andrei

Re: OT: Vulkan released

[Zardoz via Digitalmars-d]

On Tuesday, 16 February 2016 at 19:05:03 UTC, Rikki Cattermole 
wrote:

On 17/02/16 8:03 AM, Zoadian wrote:

On Tuesday, 16 February 2016 at 14:20:51 UTC, Ola Fosheim

I'll write derelict bindings.


I'll steal it once you've done that for alphaPhobos :)
Maybe even get Windows context creation made within a few weeks 
(depends on when I get a new GPU).


I could test It when i update my GPU drivers

Re: Vulkan bindings

[Rikki Cattermole via Digitalmars-d]

On 17/02/16 8:01 AM, Satoshi wrote:

Hello Vulkan API 1.0 is here and I just wrapped it into D.

https://github.com/Rikarin/VulkanizeD

Have fun!


Btw you removed Khronos header/license declaration.
I'm copying back the original to my variation of these bindings.

Re: Another new io library

[John Colvin via Digitalmars-d]

On Wednesday, 17 February 2016 at 07:15:01 UTC, Steven 
Schveighoffer wrote:

On 2/17/16 1:58 AM, Rikki Cattermole wrote:


A few things:
https://github.com/schveiguy/iopipe/blob/master/source/iopipe/traits.d#L126
why isn't that used more especially with e.g. window?
After all, window seems like a very well used word...


Not sure what you mean.


I don't like that a stream isn't inherently an input range.
This seems to me like a good place to use this abstraction by 
default.


What is front for an input stream? A byte? A character? A word? 
A line?


Why not just say it's a ubyte and then compose with ranges from 
there?

Re: IMAP library

[crimaniak via Digitalmars-d]

On Wednesday, 17 February 2016 at 09:01:18 UTC, Mengu wrote:

hello everyone

i have checked code.dlang.org and github but i have not 
encountered an IMAP library. ..


https://github.com/Laeeth/d_etpan

IMAP library

[Mengu via Digitalmars-d]

hello everyone

i have checked code.dlang.org and github but i have not 
encountered an IMAP library. there's an application at work that 
i want to convert to D and IMAP is an essential part as i read 
emails and download the attachments. so i thought let's give it a 
shot and create the library for D before i convert the 
application.


i'd appreciate it if someone knowledgable jumps in and build the 
library with me or guide my way. also, i am thinking of using 
pegged in this case for parsing as i think it'd make things 
easier.


what do you guys think?

Re: Another new io library

[yawniek via Digitalmars-d]

On Wednesday, 17 February 2016 at 07:15:01 UTC, Steven 
Schveighoffer wrote:

On 2/17/16 1:58 AM, Rikki Cattermole wrote:
What would be the benefit of having it an input range by 
default?


-Steve


https://en.wikipedia.org/wiki/Principle_of_least_astonishment
something the D community is lacking a bit in general imho.

but awesome library, will definitely use, thanks!

Re: Implement the "unum" representation in D ?

[Nick B via Digitalmars-d]

Hi

John Gustafson was in town (Wellington, NZ) for the Multicore 
World Conference 2016 ( http://www.multicoreworld.com/) 
conference. I caught up with him, tonight, and spoke to him for 
about two hours. Here is a quick summary of what we discussed.  
John has just redesigned Unums, to address the design issues in 
version 1.0.  He presented his Powerpoint presentation to the 
conference, with the details of Unums 2.0 (this is a tentative 
name at present).  Its a improved design, but I will only brief 
detail it:  "It  will have  more dynamic range with 16-bit values 
than IEEE half-precision, but only by a small amount. Still 
remarkable to be uniformly better in dynamic range and precision, 
with support for inexact values and perfect reciprocation. If a 
language supports just one unum data type, John believes it 
should be the 16-bit one".  John has agreed to provide a link to 
the Powerpoint presentation, in a couple of weeks, and then 
later, a link to his new published paper on the subject, when it 
is ready.  There will likely be a new book, building on version 
1.0, and, again, tentatively titled 'Unums 2.0'. I also discussed 
with him, about integrating it with D. At the present, there is a 
'C' codebase under construction, but this could be rewritten in D 
in the future.  D may require some language changes, and a new 
phobos library, to support this advanced functionality. Of course 
Walter will have decide if he wants this advanced numbering 
system as a part of D.


As an aside, John mentioned that Rex Computing 
(http://www.rexcomputing.com/) is using Unums with the Julia 
language, for their new hyper-efficient processor architecture. 
It will be interesting to see what these whiz kids deliver in 
time.


cheers
Nick