Re: Redesign of dlang.org

[deadalnix via Digitalmars-d]

On Tuesday, 22 December 2015 at 16:58:40 UTC, Andrei Alexandrescu 
wrote:

On 12/22/2015 02:19 AM, Jacob Carlborg wrote:

On 2015-12-21 18:37, Andrei Alexandrescu wrote:

That's a large leap. I suggest using Ddoc instead of Sass 
compact CSS

files, see the existing instance at
https://github.com/D-Programming-Language/dlang.org/blob/master/css/cssmenu.css.dd.



CoffeeScript sounds like a nice thing to add and is from what 
I've heard

reasonably stable.

We can't make the site depend on dub at this time. There have 
been
situations in the past when dub wouldn't build and nobody was 
available
to work on it. At that time only the alternate documentation 
got broken,
but if the site depends on it we're looking at catastrophic 
failure.


I have no interest in using Ddoc. If that's a requirement we 
can close

down the redesign idea completely.


I was afraid you were going to say this. Looks like we're 
reaching an impasse again, so let me explain the situation from 
where I stand and kindly attempt to change your viewpoint a bit.


One simple matter of fact is that most work and maintenance on 
dlang.org 
(https://github.com/D-Programming-Language/dlang.org/graphs/contributors) is done by a handful of folks: Walter, myself, Kenji, Martin, Vladimir, followed by a long tail. Lately it's been Vladimir, Martin, and myself who did most maintenance work.


A consequence of that is when someone proposes a different 
technology for dlang.org, the proposal is really that Vladimir, 
Martin, and me become fluent in it. This is a very simple fact 
that I have had difficulty communicating. I've said several 
times that the only thing that would make e.g. vibe.d more used 
on dlang.org is the availability of people able and willing to 
help with it.


As far as I understand you are well versed in a variety of 
Web-related tools, and have your preferences in terms of 
tooling you use etc. That's totally cool. Also, my 
understanding is that you'd consider helping with the redesign 
but only as a one-off contribution; there'd be no implied 
commitment that you'd be available for solving various issues 
related to the technologies you propose. This makes things more 
difficult for everyone involved. What would help would be a bit 
more flexibility with the choices made and more convergence 
toward compromise. You can't come with a battery of large 
changes in a take it or leave it manner.



Thanks,

Andrei


First question first, how do one create a template from a design 
so that ddoc can generate using it ?


Also, the home page may be one of these that justify going off 
road. You often want something more out of the ordinary there as 
goals are different from the usual doc page. Is that possible to 
have a custom html (or whatever else) for the home page and keep 
using ddoc for everything else ?

Re: D could catch this wave: web assembly

[deadalnix via Digitalmars-d]

On Wednesday, 23 December 2015 at 07:37:39 UTC, Suliman wrote:
On Friday, 18 December 2015 at 10:21:49 UTC, Ola Fosheim 
Grøstad wrote:

On Thursday, 17 December 2015 at 20:22:41 UTC, yawniek wrote:

https://hacks.mozilla.org/2015/12/compiling-to-webassembly-its-happening/


Thanks for sharing! This looks promising.


Could anybody show how C++ App for web will look like? I really 
can't fund any examples except AST. Would it have access to DOM 
or it would look like Java applet?


WebAssembly is an AST representation, so I'm not sure what else 
you expect than an AST ?

Re: D could catch this wave: web assembly

[Suliman via Digitalmars-d]

On Wednesday, 23 December 2015 at 10:02:18 UTC, deadalnix wrote:

On Wednesday, 23 December 2015 at 07:37:39 UTC, Suliman wrote:
On Friday, 18 December 2015 at 10:21:49 UTC, Ola Fosheim 
Grøstad wrote:

On Thursday, 17 December 2015 at 20:22:41 UTC, yawniek wrote:

https://hacks.mozilla.org/2015/12/compiling-to-webassembly-its-happening/


Thanks for sharing! This looks promising.


Could anybody show how C++ App for web will look like? I 
really can't fund any examples except AST. Would it have 
access to DOM or it would look like Java applet?


WebAssembly is an AST representation, so I'm not sure what else 
you expect than an AST ?


For example I do not know JS. And only C++. How would look like 
my web-app with WASM?

Re: How is D doing?

[thedeemon via Digitalmars-d-learn]

On Tuesday, 22 December 2015 at 21:38:22 UTC, ZombineDev wrote:

Google Trends shows something interesting:
https://google.com/trends/explore#q=%2Fm%2F01kbt7%2C%20%2Fm%2F0dsbpg6%2C%20%2Fm%2F091hdj%2C%20%2Fm%2F03j_q%2C%20C%2B%2B=q=Etc%2FGMT-2


Today I Learned C++ is most interested by in Ethiopia. ;)

Re: Three Cool Things about D

[deadalnix via Digitalmars-d-announce]

On Wednesday, 23 December 2015 at 01:07:57 UTC, Walter Bright 
wrote:

On 12/22/2015 10:29 AM, David Nadlinger wrote:
Not sure about how it arrives at the crazily unrolled loop, 
but no recursion in

sight anymore.


It's doing tail recursion optimization, which turns the 
recursion into a loop.

Then the loop is unrolled 8 times.


You can't to tail recursion in it's basic form because there is a 
multiplication at the end.

Re: Most performant way of converting int to string

[Jakob Ovrum via Digitalmars-d-learn]

On Tuesday, 22 December 2015 at 17:23:11 UTC, Andrew Chapman 
wrote:

On Tuesday, 22 December 2015 at 17:18:16 UTC, cym13 wrote:
On Tuesday, 22 December 2015 at 17:15:27 UTC, Andrew Chapman 
wrote:
Sorry if this is a silly question but is the to! method from 
the conv library the most efficient way of converting an 
integer value to a string?


e.g.
string s = to!string(100);

I'm seeing a pretty dramatic slow down in my code when I use 
a conversion like this (when looped over 10 million 
iterations for benchmarking).


Cheers!


Out of curiosity a slow down compared to what? No conversion 
at all?


Yeah, if I include a simple conversion in my loop:

for({int i; i = 0;} i < num; i++) {
//string s = to!string(i);
Customer c = Customer(i, "Customer", 
"", i * 2);

string result = objS.serialize(c);
}

If I uncomment the "string s" line I'm seeing a 20% increase in 
running time, which given what's going on the rest of the code 
is quite surprising.  I've tried compiling with both dmd and 
ldc2 - it's the same under both.


Cheers.


Dynamic memory allocation is expensive. If the string is 
short-lived, allocate it on the stack:


enum maxDigits = to!string(ulong.max).length;
foreach(i; 0 .. num) {
char[maxDigits] buffer = void;
auto c = Customer(sformat(buffer[], "%s", i));
string result = objS.serialize(c);
}

Note that this is unsafe if the string (sformat's return value) 
outlives the loop iteration, as this is `buffer`'s scope.

Re: Most performant way of converting int to string

[Jakob Ovrum via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 11:21:32 UTC, Jakob Ovrum wrote:
Dynamic memory allocation is expensive. If the string is 
short-lived, allocate it on the stack:


See also std.conv.toChars[1] for stringifying lazily/on-demand.

http://dlang.org/phobos/std_conv#toChars

[Issue 15470] Unnecessary markup in ddoc's html generation

[via Digitalmars-d-bugs]

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

--- Comment #6 from Adam D. Ruppe  ---
Indeed, the load time of these things is probably irrelevant. Minification
efforts, in general, are almost plain negligible after gzipping.

gzip though, does make a huge difference and we should ensure it is enabled.

--

[Issue 15470] Unnecessary markup in ddoc's html generation

[via Digitalmars-d-bugs]

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

--- Comment #7 from Andrei Alexandrescu  ---
I recall Jan has enabled compression a while ago. How do we check?

--

Re: D Consortium as Book / App Publisher... ?

[bachmeier via Digitalmars-d]

On Wednesday, 23 December 2015 at 03:05:46 UTC, Joakim wrote:
I've been thinking about contacting various D devs to see how 
much interest there is- I mentioned that I contacted one guy 
already- but I wasn't sure if I myself wanted to put time into 
this.  I really want to put these paid blogging ideas into use 
one day, but maybe D isn't the place to do it.


I don't think it would be worth your time to focus on D in 
general. If you want someone to pay more than a couple dollars a 
year, you need to offer something specific, and it needs to offer 
a direct, immediate career benefit. Web development with D might 
work if done right. Probably the better thing is to go into it 
with a low price and a goal of learning. Then you can move on to 
a more profitable market.

[Issue 15470] Unnecessary markup in ddoc's html generation

[via Digitalmars-d-bugs]

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

--- Comment #8 from Adam D. Ruppe  ---
Just load it with an empty cache with network console open.

Yes, the homepage is gzipped. It comes in at about 8 KB on the wire, not bad at
all.

--

Convert to string an enum item

[tcak via Digitalmars-d-learn]

[code]
import std.stdio;
import std.conv;

enum Values: ubyte{ One = 1, Two = 2 }

void main(){
writeln( std.conv.to!string( Values.One ) );
}
[/code]

Output is "One".

casting works, but to be able to cast correctly, I need to tell 
compiler that it is "ubyte".


Isn't there any NON-HACKISH solution to print out the value of 
enum item? And do not decrease the performance as well please. It 
runs on web server.



Problem comes from that:
I have written a struct for JsonArray. It has multiple append 
methods. One of them is "appendNumber".


public ref JsonArray appendNumber(N)( N num )
if( __traits( compiles, {auto x=num.min + num.max;} ) || 
__traits( compiles, {auto x=num.min_normal;} ) )

{
appendJSString( std.conv.to!string( num ) );
return this;
}

While I am passing an enum item to this function, as it has "min" 
and "max" attributes, it is accepted. But the resulting string is 
the name of enum item instead of its value. I do not want casting 
while enum knows its type already.

Re: Three Cool Things about D

[Andrei Alexandrescu via Digitalmars-d-announce]

On 12/23/2015 09:06 AM, Abdulhaq wrote:

A clip of the comedian that Andrei refers to can be seen here:

https://www.youtube.com/watch?v=uEY58fiSK8E


I love that bit! -- Andrei

[Issue 15457] Symbol Undefined __lseeki64

[via Digitalmars-d-bugs]

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

Byron Heads  changed:

   What|Removed |Added

   Severity|normal  |regression

--

[Issue 15470] Unnecessary markup in ddoc's html generation

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #5 from Andrei Alexandrescu  ---
We can do some of these with relative ease bot some others are likely to be
difficult. In particular,

float.nan

is an artifact of how generation occurs, first the code font is expanded then
the table tag is expanded. Merging those two is nontrivial with what we have.

I'll add that we generate a few tags that are in fact optional, see the list at
http://www.w3.org/TR/2011/WD-html5-20110525/syntax.html#optional-tags.

All of these issues in aggregate, including whitespace, would add to some
inefficiency. I think it may be unmeasurable or difficult to measure, and at
best add only to a couple percent. Certainly at this point "all of these things
can account for slower page loads, which can impact page ranking in search
engines" is pure speculation.

Do we want nice tight generated HTML? Somewhat. Does fixing this issue help?
Yes. Do we want fast-loading pages? Yes. Does fixing this issue help? Unlikely
to make any sensible improvement.

--

Re: Three Cool Things about D

[Abdulhaq via Digitalmars-d-announce]

On Monday, 21 December 2015 at 17:28:51 UTC, Andrei Alexandrescu 
wrote:

https://www.reddit.com/r/programming/comments/3xq2ul/codedive_2015_talk_three_cool_things_about_d/

https://www.facebook.com/dlang.org/posts/1192267587453587

https://twitter.com/D_Programming/status/678989872367988741


Andrei


A clip of the comedian that Andrei refers to can be seen here:

https://www.youtube.com/watch?v=uEY58fiSK8E

[Issue 15470] Unnecessary markup in ddoc's html generation

[via Digitalmars-d-bugs]

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

--- Comment #9 from Charles Smith  ---
(In reply to Andrei Alexandrescu from comment #5)
> We can do some of these with relative ease bot some others are likely to be
> difficult. In particular,
> 
> float.nan
> 
> is an artifact of how generation occurs, first the code font is expanded
> then the table tag is expanded. Merging those two is nontrivial with what we
> have.

This is what I figured, I figured I'd point it out just the same. Unfortunately
these kind of things can make designing new templates a bit chaotic, since you
end up with oddball things like:

div#search-box, span#search-query, span#search-dropdown, span#search-submit
{
border: 0.1em none #aaa;
}

I should've explicitly listed this as a concern.

> All of these issues in aggregate, including whitespace, would add to some
> inefficiency. I think it may be unmeasurable or difficult to measure, and at
> best add only to a couple percent. Certainly at this point "all of these
> things can account for slower page loads, which can impact page ranking in
> search engines" is pure speculation.

Fair enough, it was a weak argument, and as Adam pointed out, gzipping makes
this not even that. The only concern I was thinking of when pointing this out
was more for search engine page ranking, which favors compact compressed sites,
but I have no idea to what degree.

Nonconforming and deprecated html however is also present, and that is perhaps
a larger issue. I don't suspect browsers to just stop what they're doing
already that fixes the mistakes, so it might just be good to know for the
future.

--

Re: Convert to string an enum item

[Alex Parrill via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 13:11:28 UTC, tcak wrote:

[code]
import std.stdio;
import std.conv;

enum Values: ubyte{ One = 1, Two = 2 }

void main(){
writeln( std.conv.to!string( Values.One ) );
}
[/code]

Output is "One".

casting works, but to be able to cast correctly, I need to tell 
compiler that it is "ubyte".


Isn't there any NON-HACKISH solution to print out the value of 
enum item? And do not decrease the performance as well please. 
It runs on web server.




So you want the enum's integer value? Try casting it to an 
integer.


writeln(cast(ubyte) Values.One);

Re: dqml for Ubuntu Unity apps

[Adam Stokes via Digitalmars-d-announce]

On Sunday, 20 December 2015 at 13:25:48 UTC, Karabuta wrote:
I can't seem to wrap my head around using dqml and D backend 
for Ubuntu Unity app development. They have this 
UnityComponents qml module they use for UI in their SDK plus a 
C++ backend.


Has anyone made effort on using dqml and D backend? Sample code 
or any help will be sweet!! I really dislike C++, And 
Canonical's C++ coding style and naming convention makes it 
worst.


I don't have any experience using dqml with Unity Apps but I can 
certainly get you in touch with the right people to help you make 
sense of the c++ code so that you may better apply that with 
dqml. Is that something you'd be interested in? Anything specific 
that I can communicate to those developers that you currently 
have questions on?


Feel free to reply here or email me directly

Re: How is D doing?

[D via Digitalmars-d-learn]

I'm doing quite well, thank you.

Graphics/font/platform backends with common interfaces?

[Taylor Hillegeist via Digitalmars-d-learn]

So I have seen alot of projects that need the same sort of stuff.

graphics libraries
gui libraries
game libraries
ploting libaries

they would all benefit from a backend solution with a common 
interface for


color
fonts
drawing pen_style aliasing etc.

but each one i look at seems to have a built up solution with 
various degrees of integration with things like freetype gdi 
cairo sdl glew opengl.


Shouldn't there be like a common (interface/abstract class) that 
these back-ends can fulfill? maybe I am unaware of how these 
things are done. And perhaps there are performance reasons that 
many of these are baked in.


perhaps it should be like:

standard color implementation.
font interface that converts glyphs into drawing strokes.
and a standard set of drawing instructions with transforms.

//probably a grotesque simplification

interface font_do{
  glyphstrokes getstrokes(string characterstoget);
}

interface draw_do{
  drawpixel(double x,double y);
  drawline(double x,double y);
  drawglyph(glypstrokes g);
  getpostdrawnsize(glypstroks g)
  ... other things
}

D Testable Code

[Jakob Jenkov via Digitalmars-d]

D Testable Code is not detestable code... There is a little 
holiday "puzzle/joke" for you :-)


(I just watched a video from DConf 2013 about unit testing - 
sorry! )

Re: Multiple selective imports on one line

[earthfront via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 11:12:22 UTC, ZombineDev wrote:
Actually array() is from sts.array and correct way to use 
selective imports is:

import std.exception : enforce;
import std.array : array;
import std.algorithm.iteration : filter;
import std.functional : memoize;

If you want to import several symbols from one module, you can 
list them after the column like so:

import std.algorithm : any, find, sort /*, etc... */;


I hadn't compiled yet, so the array thing is indeed an error.
So there's no way to combine these _selective_ imports on a 
single line, like I can with regular _module_ imports:

  import std.exception, std.array, std.functional;

Correct?

Re: Convert to string an enum item

[Meta via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 17:43:52 UTC, Alex Parrill 
wrote:

On Wednesday, 23 December 2015 at 13:11:28 UTC, tcak wrote:

[code]
import std.stdio;
import std.conv;

enum Values: ubyte{ One = 1, Two = 2 }

void main(){
writeln( std.conv.to!string( Values.One ) );
}
[/code]

Output is "One".

casting works, but to be able to cast correctly, I need to 
tell compiler that it is "ubyte".


Isn't there any NON-HACKISH solution to print out the value of 
enum item? And do not decrease the performance as well please. 
It runs on web server.




So you want the enum's integer value? Try casting it to an 
integer.


writeln(cast(ubyte) Values.One);


He already mentioned that.

What you want to do is use std.traits.OriginalType 
(https://dlang.org/phobos/std_traits.html#OriginalType) like so:


to!string(cast(OriginalType!Values)Values.one)

Re: Convert to string an enum item

[Meta via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 17:43:52 UTC, Alex Parrill 
wrote:

On Wednesday, 23 December 2015 at 13:11:28 UTC, tcak wrote:

[code]
import std.stdio;
import std.conv;

enum Values: ubyte{ One = 1, Two = 2 }

void main(){
writeln( std.conv.to!string( Values.One ) );
}
[/code]

Output is "One".

casting works, but to be able to cast correctly, I need to 
tell compiler that it is "ubyte".


Isn't there any NON-HACKISH solution to print out the value of 
enum item? And do not decrease the performance as well please. 
It runs on web server.




So you want the enum's integer value? Try casting it to an 
integer.


writeln(cast(ubyte) Values.One);


He already mentioned that.

What you want to do is use std.traits.

Re: Multiple selective imports on one line

[earthfront via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 11:00:19 UTC, Jakob Ovrum wrote:
On Wednesday, 23 December 2015 at 10:51:52 UTC, earthfront 
wrote:
Now I'm left with a smattering of lines which are just 
selective imports from a single module:

  import std.exception:enforce;
  import std.algorithm:array;
  import std.algorithm.iteration:filter;
  import std.functional:memoize;

What is the proper way to combine these into one line?


There's no `array` in std.algorithm, and I don't see more than 
one import per module in your example, but I'm guessing what 
you want is:


import mod : a, b, c; // import a, b and c from mod


Sorry, no, I didn't want that. I should have typed above:
"I'm left with lines which are selective imports from various 
modules."


My goal is to import several symbols from different modules on 
one line.
I'm trying to figure out if it's possible or not. It makes the 
code more concise in some cases.

[Issue 15470] Unnecessary markup in ddoc's html generation

[via Digitalmars-d-bugs]

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

--- Comment #10 from Sobirari Muhomori  ---
(In reply to Charles Smith from comment #0)
> * Unnecessary span tags. Example: `float.nan` could be reduced to ` class="d_inlinecode donthyphenate notranslate">float.nan`

Not equivalent if you want the span to have a border.

--

Merry Christmas

[steven kladitis via Digitalmars-d-learn]

Twas the Night before Christmas and all through my D code.
The compiler was compiling the new and the olde.
Thanks to Walter,  Alexander and Ali.
I try to write more D code with happiness and Glee.
In the forums with help from folks like me galore.
I find I am not crazy, just need to learn more.
So with all my D code, bugs and all.
As long as I can compile and stay awake and from my chair not 
fall.

May all your code work be fast and work as fast as light.
I wish to All a Merry Christmas and to All a good night.

Re: Redesign of dlang.org

[Andrei Alexandrescu via Digitalmars-d]

On 12/23/15 4:59 AM, deadalnix wrote:

First question first, how do one create a template from a design so that
ddoc can generate using it ?


I don't understand this question. Ddoc is just pure macro expansion so 
you can use it in many ways, including to generate a verbatim copy of 
the input 
(https://github.com/D-Programming-Language/dlang.org/blob/master/verbatim.ddoc) 
or a text-only version of the input 
(https://github.com/D-Programming-Language/dlang.org/blob/master/plaintext.ddoc).



Also, the home page may be one of these that justify going off road. You
often want something more out of the ordinary there as goals are
different from the usual doc page. Is that possible to have a custom
html (or whatever else) for the home page and keep using ddoc for
everything else ?


Yah. Overall I think a redesign is needed simply because it's time. 
Second I think the particular redesign discussed here is nice in many 
ways. Third I think I'm being reasonable if I ask to introduce new or 
custom technology dependencies only with good reason.



Andrei

[Issue 15471] Show example of associative array initialization in documentation

[via Digitalmars-d-bugs]

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

--- Comment #2 from Mark Isaacson  ---
Yep, we're on the same page. Personally I find it difficult to decipher the
grammar. I'm sure that page is a barrier to new users. So yeah, the request
would be to get an example of that, a little code block, somewhere on
http://dlang.org/spec/hash-map.html

--

Re: Graphics/font/platform backends with common interfaces?

[Taylor Hillegeist via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 23:34:58 UTC, Rikki Cattermole 
wrote:

On 24/12/15 8:22 AM, Taylor Hillegeist wrote:

[...]


So far I've been implementing windowing and image libraries for 
Phobos.
Right now windowing works on Windows minice eventing. Once 
eventing is done it is ready for the first stage of feedback.


[...]


How do you handle fonts?

Pain when changing DMD version...

[JerryR via Digitalmars-d]

A couple of months ago, I decided to upgrade my DMD to a new 
version: 2.066, and today I needed compile that project again, 
which a year ago I had compiled with DMD 2.060.


Now if you look below you will see the errors that I'm getting 
with changing from DMD 2.060 to 2.066, and all the errors are 
from GTKD, not my program yet!


Well I'm bit disappointed and a bit lost in what to do, I don't 
know if I go back to 2.060 or upgrade the GTKD and I cross my 
fingers for my program still working.


 - What you used to do in cases like this?


Errors when changing from DMD 2.060 to 2.066:

C:\gtkd\src\gtkc\gtktypes.d(283): Error: enum member 
gtkc.gtktypes.GtkRcTokenTyp
e.INCLUDE initialization with (GtkRcTokenType.INVALID + 1) causes 
overflow for t

ype 'int'
C:\gtkd\src\gtkc\gtktypes.d(2184): Error: cannot implicitly 
convert expression (

16) of type int to GParamFlags

C:\gtkd\src\gtk\Widget.d(239): Error: cannot modify 'this' 
reference
C:\gtkd\src\gtk\Widget.d(242): Error: an earlier return statement 
skips construc

tor
C:\gtkd\src\glib\StringG.d(101): Error: cannot modify 'this' 
reference
C:\gtkd\src\gobject\Closure.d(138): Error: cannot modify 'this' 
reference
C:\gtkd\src\gobject\ObjectG.d(171): Error: cannot modify 'this' 
reference
C:\gtkd\src\gobject\ObjectG.d(238): Error: struct 
gtkc.Loader.Linker member load

edLibraries is not accessible
C:\gtkd\src\gobject\ParamSpec.d(110): Error: cannot modify 'this' 
reference
C:\gtkd\src\gobject\Value.d(124): Error: cannot modify 'this' 
reference
C:\gtkd\src\gdk\Pixbuf.d(131): Error: cannot modify 'this' 
reference
C:\gtkd\src\gdk\Pixbuf.d(138): Error: cannot modify 'this' 
reference
C:\gtkd\src\gdk\Pixbuf.d(141): Error: an earlier return statement 
skips construc

tor
C:\gtkd\src\glib\ErrorG.d(223): Error: cannot modify 'this' 
reference
C:\gtkd\src\gdkpixbuf\PixbufFormat.d(138): Error: cannot modify 
'this' reference


C:\gtkd\src\glib\ListSG.d(122): Error: cannot modify 'this' 
reference
C:\gtkd\src\gdk\Drawable.d(160): Error: cannot modify 'this' 
reference
C:\gtkd\src\gdk\Drawable.d(167): Error: cannot modify 'this' 
reference
C:\gtkd\src\gdk\Drawable.d(170): Error: an earlier return 
statement skips constr

uctor
C:\gtkd\src\gdk\Display.d(121): Error: cannot modify 'this' 
reference
C:\gtkd\src\gdk\Display.d(128): Error: cannot modify 'this' 
reference
C:\gtkd\src\gdk\Display.d(131): Error: an earlier return 
statement skips constru

ctor
C:\gtkd\src\gdk\Screen.d(140): Error: cannot modify 'this' 
reference


Jerry.

Re: So You Want To Write Your Own Language

[BLM768 via Digitalmars-d-announce]

On Thursday, 24 December 2015 at 01:08:38 UTC, Walter Bright 
wrote:

This has resurfaced on Reddit:

https://www.reddit.com/r/programming/comments/3xya5v/so_you_want_to_write_your_own_language/


I might end up using this. It seems like there aren't many better 
ways to really learn about programming than to build one's own 
language.

Re: Graphics/font/platform backends with common interfaces?

[Rikki Cattermole via Digitalmars-d-learn]

On 24/12/15 4:03 PM, Taylor Hillegeist wrote:

On Wednesday, 23 December 2015 at 23:34:58 UTC, Rikki Cattermole wrote:

On 24/12/15 8:22 AM, Taylor Hillegeist wrote:

[...]


So far I've been implementing windowing and image libraries for Phobos.
Right now windowing works on Windows minice eventing. Once eventing is
done it is ready for the first stage of feedback.

[...]


How do you handle fonts?


Once my existing backlog is complete I /may/ consider a font rasterizer.

Re: How is D doing?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Thursday, 24 December 2015 at 00:16:16 UTC, rsw0x wrote:
restrict it to 'programming' to get a more accurate assessment 
of D.

https://google.com/trends/explore#cat=0-5-31=%2Fm%2F01kbt7%2C%20%2Fm%2F0dsbpg6%2C%20%2Fm%2F091hdj%2C%20%2Fm%2F03j_q=1%2F2010%2061m=q=Etc%2FGMT-2

removed C++ because it just dwarfs the others.
D, as I expected, has a massive following in Japan. I'm still 
not quite sure why.


3 d language
3 d programming

?

Re: Redesign of dlang.org

[Andrei Alexandrescu via Digitalmars-d]

On 12/23/2015 04:35 PM, wobbles wrote:

On Wednesday, 23 December 2015 at 17:22:25 UTC, Andrei Alexandrescu wrote:

Third I think I'm being reasonable if I ask to introduce new or custom
technology dependencies only with good reason.


Andrei


I think that's very fair.

On your earlier point of getting people to work on the website and also
commit to helping out in future, is there an "official" thing here? Like
a contract (An unpaid contract, obviously :D)?

Or is it more a matter of trust from you and everyone else involved with
the site towards a person stating they'd like to help?


There is no contract, only a matter of building a history of good 
contributions. -- Andrei

What's wrong with my debugger?

[Chris via Digitalmars-d-learn]

Please see the linked screenshot: http://i.imgur.com/SpkXu5m.png

As you can see, the inside, outside and collision arrays don't 
seem to work with the debugger. They show a bogus lenght and a 
bogus memory address. Extracting the lenghts to separate 
variables outl, insl and coll show that the arrays actually 
behave properly, though.


Is that a debugger bug? Or maybe something I can fix? Thanks in 
advance.


DMD 2.069.2, Mago debugger, VisualD 3.43, compiling for 32 bits 
if that makes a difference (can't get either 64 bit compilation 
or LDC to work)

Re: So You Want To Write Your Own Language

[Joakim via Digitalmars-d-announce]

On Thursday, 24 December 2015 at 01:08:38 UTC, Walter Bright 
wrote:

This has resurfaced on Reddit:

https://www.reddit.com/r/programming/comments/3xya5v/so_you_want_to_write_your_own_language/


Will you be moving that article and your other work to your own 
domain?  One reddit commenter says that drdobbs link crashed his 
chrome tab, I've seen another drdobbs article start repeatedly 
reloading in a loop, and a Google search for a random phrase from 
this article doesn't even turn up this link but some spam site 
called impythonist that copy-pasted your article.


Time to give your old articles a better home, I think, assuming 
you have the copyright or can get it.

[Issue 13676] [ddoc] DDoc should wrap each part of function declaration in dedicated macro to allow more readable formatting

[via Digitalmars-d-bugs]

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

--- Comment #5 from landaire  ---
I want to note that I've done a little bit of work on this here:
https://github.com/D-Programming-Language/dmd/pull/5311

- Add function overload separator macro
- Add template constraint macro
- Add template param list macro
- Add template param macro

All related parts of function signatures are wrapped in their respective
macros.

--

Re: How is D doing?

[rsw0x via Digitalmars-d-learn]

On Tuesday, 22 December 2015 at 21:38:22 UTC, ZombineDev wrote:
On Tuesday, 22 December 2015 at 17:49:34 UTC, Jakob Jenkov 
wrote:
On Tuesday, 22 December 2015 at 03:30:32 UTC, ShinraTensei 
wrote:
I recently noticed massive increase in new languages for a 
person to jump into(Nim, Rust, Go...etc) but my question is 
weather the D is actually used anywhere or are there chances 
of it dying anytime soon.



Check out Google Trends. Searches for D Tutorial still beats 
searches for Scala Tutorial by a big margin:


https://google.com/trends/explore#q=d%20tutorial%2C%20scala%20tutorial


Google Trends shows something interesting:
https://google.com/trends/explore#q=%2Fm%2F01kbt7%2C%20%2Fm%2F0dsbpg6%2C%20%2Fm%2F091hdj%2C%20%2Fm%2F03j_q%2C%20C%2B%2B=q=Etc%2FGMT-2


restrict it to 'programming' to get a more accurate assessment of 
D.

https://google.com/trends/explore#cat=0-5-31=%2Fm%2F01kbt7%2C%20%2Fm%2F0dsbpg6%2C%20%2Fm%2F091hdj%2C%20%2Fm%2F03j_q=1%2F2010%2061m=q=Etc%2FGMT-2

removed C++ because it just dwarfs the others.
D, as I expected, has a massive following in Japan. I'm still not 
quite sure why.

So You Want To Write Your Own Language

[Walter Bright via Digitalmars-d-announce]

This has resurfaced on Reddit:

https://www.reddit.com/r/programming/comments/3xya5v/so_you_want_to_write_your_own_language/

[Issue 15464] Template parameter-dependent attributes

[via Digitalmars-d-bugs]

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

--- Comment #6 from Kenji Hara  ---
(In reply to Daniel Kozak from comment #5)
> So only postfix UDAs change and break, this can be  maybe avoid if this new
> lowering will be applied only to UDAs with templates parametrs.
> 
> The biggest problem I see here is consistency

Yes, my concern is consistency. Currently label, block, prefix, and postfix
style attributes (both built-ins and UDAs) have no difference. If attributes
conflict, the innermost attribute is precedence. And, prefix and postfix
position are treated as "same level". For example:

@safe void foo() @trusted {}
// Error, prefix @safe attribute conflicts with postfix @trusted

If this enhancement needs to break existing consistency, it should have clear
answers which derived from some new language design decisions. Otherwise the
enhancement will be a merely convenient feature and will increase the chaos in
D.

--

Re: Template parameter-dependent attributes

[Manu via Digitalmars-d]

On 17 December 2015 at 03:14, Andrei Alexandrescu via Digitalmars-d
 wrote:
> So, I wrote this beautiful BigO framework: <400 lines all told, clear code,
> real nice. Then I got this cold shower:
>
> void insertFrontMany(C, R)(C container, R range)
> @BigO(complexity!(C.insertFront) * linearTime)
> {
>...
> }
>
> My hope being of course that for containers with linear insertion time at
> the front I'll get quadratic, etc. The hitch is:
>
> test.d(377): Error: undefined identifier 'C.insertFront'
>
> So... attributes are currently not allowed to depend on template parameters,
> which is a serious damper on enthusiasm.

Remember that time I complained about this more than 2 and a half years ago?

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

> Seems to me this is a bug - different instantiations should have different
> attributes etc. Is there any matter of principle making this not work?

Seems like a bug to me too, since you can express it with a fully
expanded template, just not with the template syntax you actually use.

Re: Graphics/font/platform backends with common interfaces?

[Taylor Hillegeist via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 20:52:05 UTC, Adam D. Ruppe 
wrote:
On Wednesday, 23 December 2015 at 20:49:21 UTC, Taylor 
Hillegeist wrote:

|  GRAPICS LIB  |
+---+---+---+ <- what is this interface
|SDL|GDI|OPENGL.|
+---+---+---+


SDL, GDI, and OpenGL *are* graphics libs so it seems a bit 
silly to put an interface there.


I guess I'm thinking that to be able to switch between 
backends(gdi sdl) you use you must have a common interface. And 
if everyone had the same common interface it could be nice right?

Re: Multiple selective imports on one line

[Basile B. via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 19:34:26 UTC, earthfront wrote:
On Wednesday, 23 December 2015 at 11:00:19 UTC, Jakob Ovrum 
wrote:

[...]

My goal is to import several symbols from different modules on 
one line.
I'm trying to figure out if it's possible or not. It makes the 
code more concise in some cases.


This is not available in the grammar. You can still open a 
duplicate enhancement request.


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

see also:

http://forum.dlang.org/post/trrxoacvpyyqrdfqx...@forum.dlang.org

I remember also another NG thread about this. A guy wanted this 
feature because he thought that this would allow him to write 
faster during a Hackathlon or something like that.

Re: Graphics/font/platform backends with common interfaces?

[Taylor Hillegeist via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 21:07:12 UTC, Basile B. wrote:
On Wednesday, 23 December 2015 at 20:52:05 UTC, Adam D. Ruppe 
wrote:

[...]


yes silly, more specially as

- some of them are 2D with FP coordinates
- some of them are 2D with integral coordinates
- some of them are 2D with integral coordinates with 
transformation of the plan
- some of them are 2D with integral coordinates without 
transformation of the plan
- some of them are 3D FP float coordinates with transformation 
of the plan

- some of them are in DirectMode, some of them not.
- etc...

So this would result in 5 or 6 templatized (because of the 
coord type) interface.
IIRC Interfaces are not devirtualizables so that they can be 
extracted...


also to put SDL and OPENGL on the same level is a bit strange.


Thanks for letting me know! So is what your saying is that an 
common interface is not possible or practical or perhaps useful?

Re: Graphics/font/platform backends with common interfaces?

[Basile B. via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 21:19:14 UTC, Taylor Hillegeist 
wrote:
On Wednesday, 23 December 2015 at 21:12:11 UTC, Taylor 
Hillegeist wrote:
On Wednesday, 23 December 2015 at 21:07:12 UTC, Basile B. 
wrote:

[...]


Thanks for letting me know! So is what your saying is that an 
common interface is not possible or practical or perhaps 
useful?


Also wouldn't the least common denominator be
2D FP in Retained Mode?


Yes. and 2D FP immediate the most common then. GDI+, cairo, OGL 
ok. GDI with a lot of rouding.

Re: Graphics/font/platform backends with common interfaces?

[Taylor Hillegeist via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 21:12:11 UTC, Taylor Hillegeist 
wrote:

On Wednesday, 23 December 2015 at 21:07:12 UTC, Basile B. wrote:

[...]


Thanks for letting me know! So is what your saying is that an 
common interface is not possible or practical or perhaps useful?


Also wouldn't the least common denominator be
2D FP in Retained Mode?

Re: Multiple selective imports on one line

[ZombineDev via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 19:27:31 UTC, earthfront wrote:
On Wednesday, 23 December 2015 at 11:12:22 UTC, ZombineDev 
wrote:
Actually array() is from sts.array and correct way to use 
selective imports is:

import std.exception : enforce;
import std.array : array;
import std.algorithm.iteration : filter;
import std.functional : memoize;

If you want to import several symbols from one module, you can 
list them after the column like so:

import std.algorithm : any, find, sort /*, etc... */;


I hadn't compiled yet, so the array thing is indeed an error.
So there's no way to combine these _selective_ imports on a 
single line, like I can with regular _module_ imports:

  import std.exception, std.array, std.functional;

Correct?


Yes, it is not allowed by the grammar. I think the reason is that 
the list items would become ambiguous (the difference between 
selected symbols and module names could only be revealed after 
semantic analysis). See for example:


import abc : cba, dcb, bca : acb, dbc;
// What is dbc? A module or a member of bca?

Re: Graphics/font/platform backends with common interfaces?

[Rikki Cattermole via Digitalmars-d-learn]

On 24/12/15 8:22 AM, Taylor Hillegeist wrote:

So I have seen alot of projects that need the same sort of stuff.

graphics libraries
gui libraries
game libraries
ploting libaries

they would all benefit from a backend solution with a common interface for

color
fonts
drawing pen_style aliasing etc.

but each one i look at seems to have a built up solution with various
degrees of integration with things like freetype gdi cairo sdl glew opengl.

Shouldn't there be like a common (interface/abstract class) that these
back-ends can fulfill? maybe I am unaware of how these things are done.
And perhaps there are performance reasons that many of these are baked in.

perhaps it should be like:

standard color implementation.
font interface that converts glyphs into drawing strokes.
and a standard set of drawing instructions with transforms.

//probably a grotesque simplification

interface font_do{
   glyphstrokes getstrokes(string characterstoget);
}

interface draw_do{
   drawpixel(double x,double y);
   drawline(double x,double y);
   drawglyph(glypstrokes g);
   getpostdrawnsize(glypstroks g)
   ... other things
}


So far I've been implementing windowing and image libraries for Phobos.
Right now windowing works on Windows minice eventing. Once eventing is 
done it is ready for the first stage of feedback.


Image library is nearly ready for next batch of feedback, PNG 
read/writer is ugh not passing its tests for palette + Adam7 interlacing.


All in all looking at second half of next year for completion.

Manu Evans has been working on the color library which I use.
The vertices definition I am using is from gfm:math with permission for 
Phobos inclusion but that needs drastic changes and somebody to take 
ownership of.


Of course that really doesn't help when it comes to e.g. font 
rasterization. But they are core and must be working first.

Re: Graphics/font/platform backends with common interfaces?

[Taylor Hillegeist via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 20:23:25 UTC, rumbu wrote:

On Wednesday, 23 December 2015 at 19:22:01 UTC, Taylor

It was an initiative, but it looks abandoned now (Aurora 
Graphics):
Thread: 
http://forum.dlang.org/thread/op.w9w0efr1707...@invictus.hra.local

Source Code: https://github.com/auroragraphics/


I know I was excited when It was announced at DConf 2014. It 
really is too bad.


what can be done now? how are standards defined around here for 
the benefit of the community?


+---+
|   USER APP|
+---+
|   GUI LIB |
+---+ <- what is this interface
|  GRAPICS LIB  |
+---+---+---+ <- what is this interface
|SDL|GDI|OPENGL.|
+---+---+---+

But is there any standard interfaces?

[Issue 15471] Show example of associative array initialization in documentation

[via Digitalmars-d-bugs]

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

bb.t...@gmx.com changed:

   What|Removed |Added

 CC||bb.t...@gmx.com

--- Comment #1 from bb.t...@gmx.com ---
(In reply to Mark Isaacson from comment #0)
> We need an example of how to initialize associative arrays in the
> documentation at http://dlang.org/spec/hash-map.html
> 
> I look this up fairly frequently and it's just not readily searchable.
> Eventually I'll try to find time to fix this myself, but, it may be a while.

Since there already a paragraph named "Runtime Initialization of Immutable AAs"
I assume you speak about the 'AssocArrayLiteral' construct. Currently there's
only a description in the grammar:

http://dlang.org/spec/grammar.html#KeyValuePairs

--

Re: Redesign of dlang.org

[wobbles via Digitalmars-d]

On Wednesday, 23 December 2015 at 17:22:25 UTC, Andrei 
Alexandrescu wrote:
Third I think I'm being reasonable if I ask to introduce new or 
custom technology dependencies only with good reason.



Andrei


I think that's very fair.

On your earlier point of getting people to work on the website 
and also commit to helping out in future, is there an "official" 
thing here? Like a contract (An unpaid contract, obviously :D)?


Or is it more a matter of trust from you and everyone else 
involved with the site towards a person stating they'd like to 
help?

Re: Most performant way of converting int to string

[Ali Çehreli via Digitalmars-d-learn]

On 12/23/2015 02:29 PM, Andrew Chapman wrote:

> string v = toChars!(16,char,LetterCase.lower)(i);
>
> to convert an integer to Hex for example, but the compiler wasn't happy
> with it.  How would I convert an int to a string using this?

I had to squint at the error message to understand that the 16 
specialization for radix requires that the value is unsigned. The 
following works:


import std.conv;
import std.algorithm;

void main() {
assert(1234u// <-- unsigned
   .toChars!(16, char, LetterCase.lower)
   .equal("4d2"));
}

Ali

Re: Graphics/font/platform backends with common interfaces?

[rumbu via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 19:22:01 UTC, Taylor Hillegeist 
wrote:
So I have seen alot of projects that need the same sort of 
stuff.


graphics libraries
gui libraries
game libraries
ploting libaries

they would all benefit from a backend solution with a common 
interface for


color
fonts
drawing pen_style aliasing etc.

but each one i look at seems to have a built up solution with 
various degrees of integration with things like freetype gdi 
cairo sdl glew opengl.


Shouldn't there be like a common (interface/abstract class) 
that these back-ends can fulfill? maybe I am unaware of how 
these things are done. And perhaps there are performance 
reasons that many of these are baked in.


perhaps it should be like:

standard color implementation.
font interface that converts glyphs into drawing strokes.
and a standard set of drawing instructions with transforms.

//probably a grotesque simplification

interface font_do{
  glyphstrokes getstrokes(string characterstoget);
}

interface draw_do{
  drawpixel(double x,double y);
  drawline(double x,double y);
  drawglyph(glypstrokes g);
  getpostdrawnsize(glypstroks g)
  ... other things
}


It was an initiative, but it looks abandoned now (Aurora 
Graphics):
Thread: 
http://forum.dlang.org/thread/op.w9w0efr1707...@invictus.hra.local

Source Code: https://github.com/auroragraphics/

Re: Graphics/font/platform backends with common interfaces?

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

On Wednesday, 23 December 2015 at 20:49:21 UTC, Taylor Hillegeist 
wrote:

|  GRAPICS LIB  |
+---+---+---+ <- what is this interface
|SDL|GDI|OPENGL.|
+---+---+---+


SDL, GDI, and OpenGL *are* graphics libs so it seems a bit silly 
to put an interface there.

[Issue 15472] New: Ddoc macro on function with same name breaks

[via Digitalmars-d-bugs]

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

  Issue ID: 15472
   Summary: Ddoc macro on function with same name breaks
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: destructiona...@gmail.com

/**
test $(test test)

Macros:
test=bug
*/
void test() {}


dmd -D generates:

test $(test test)

The test in the macro name gets highlighted too by DDOC_PSYMBOL, breaking the
intended macro expansion!

--

Re: Most performant way of converting int to string

[Andrew Chapman via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 11:46:37 UTC, Jakob Ovrum wrote:
On Wednesday, 23 December 2015 at 11:21:32 UTC, Jakob Ovrum 
wrote:
Dynamic memory allocation is expensive. If the string is 
short-lived, allocate it on the stack:


See also std.conv.toChars[1] for stringifying lazily/on-demand.

http://dlang.org/phobos/std_conv#toChars


Thanks Jakob!  I did try toChars but I couldn't quite figure out 
a syntax of calling it that the compiler was happy with.  From 
memory I tried things along the lines of:


string v = toChars!(16,char,LetterCase.lower)(i);

to convert an integer to Hex for example, but the compiler wasn't 
happy with it.  How would I convert an int to a string using this?


Cheers.

Re: Graphics/font/platform backends with common interfaces?

[Basile B. via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 20:52:05 UTC, Adam D. Ruppe 
wrote:
On Wednesday, 23 December 2015 at 20:49:21 UTC, Taylor 
Hillegeist wrote:

|  GRAPICS LIB  |
+---+---+---+ <- what is this interface
|SDL|GDI|OPENGL.|
+---+---+---+


SDL, GDI, and OpenGL *are* graphics libs so it seems a bit 
silly to put an interface there.


yes silly, more specially as

- some of them are 2D with FP coordinates
- some of them are 2D with integral coordinates
- some of them are 2D with integral coordinates with 
transformation of the plan
- some of them are 2D with integral coordinates without 
transformation of the plan
- some of them are 3D FP float coordinates with transformation of 
the plan

- some of them are in DirectMode, some of them not.
- etc...

So this would result in 5 or 6 templatized (because of the coord 
type) interface.
IIRC Interfaces are not devirtualizables so that they can be 
extracted...


also to put SDL and OPENGL on the same level is a bit strange.

Re: Graphics/font/platform backends with common interfaces?

[Taylor Hillegeist via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 20:57:27 UTC, Taylor Hillegeist 
wrote:
On Wednesday, 23 December 2015 at 20:52:05 UTC, Adam D. Ruppe 
wrote:
On Wednesday, 23 December 2015 at 20:49:21 UTC, Taylor 
Hillegeist wrote:

|  GRAPICS LIB  |
+---+---+---+ <- what is this interface
|SDL|GDI|OPENGL.|
+---+---+---+


SDL, GDI, and OpenGL *are* graphics libs so it seems a bit 
silly to put an interface there.


I guess I'm thinking that to be able to switch between 
backends(gdi sdl) you use you must have a common interface. And 
if everyone had the same common interface it could be nice 
right?


maybe this is more what I'm thinking.

 +-+
 | USER APP|
 +-+
 | GUI LIB |
 +-+ <- what is this interface
 |GenericGL|
 +-+ <- what is this interface
 |NativeGL |
 +-+

Re: dqml for Ubuntu Unity apps

[Karabuta via Digitalmars-d-announce]

On Wednesday, 23 December 2015 at 19:14:53 UTC, Adam Stokes wrote:

On Sunday, 20 December 2015 at 13:25:48 UTC, Karabuta wrote:
I can't seem to wrap my head around using dqml and D backend 
for Ubuntu Unity app development. They have this 
UnityComponents qml module they use for UI in their SDK plus a 
C++ backend.


Has anyone made effort on using dqml and D backend? Sample 
code or any help will be sweet!! I really dislike C++, And 
Canonical's C++ coding style and naming convention makes it 
worst.


I don't have any experience using dqml with Unity Apps but I 
can certainly get you in touch with the right people to help 
you make sense of the c++ code so that you may better apply 
that with dqml. Is that something you'd be interested in? 
Anything specific that I can communicate to those developers 
that you currently have questions on?


Feel free to reply here or email me directly



They use their c++ backend to hookup to qml, configure bluetooth, 
network and stuff. I wanted to figure out how to transfer their 
UbuntuComponent qml module to dqml or rather use D in place of 
the C++ in a generated project from their SDK.


However, I have no idea how to even start. I was hopping anyone 
had a sample code somewhere I could use as reference. This 
requires a D programmer who is into Ubuntu and their unity 8 
stack I guess.

Re: Graphics/font/platform backends with common interfaces?

[Basile B. via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 21:12:11 UTC, Taylor Hillegeist 
wrote:

On Wednesday, 23 December 2015 at 21:07:12 UTC, Basile B. wrote:

[...]


Thanks for letting me know! So is what your saying is that an 
common interface is not possible or practical or perhaps useful?


It's possible but it seems to be complex.

Re: Pain when changing DMD version...

[Israel via Digitalmars-d]

On Thursday, 24 December 2015 at 04:06:40 UTC, JerryR wrote:
A couple of months ago, I decided to upgrade my DMD to a new 
version: 2.066, and today I needed compile that project again, 
which a year ago I had compiled with DMD 2.060.


[...]


Upgrading GTKD is definitely the best route. Most likely GTKD 
will have done some changes since the last time you used it so 
even if you upgrade GTKD you will still get errors but at least 
GTKD will now correspond to the compiler version so your errors 
will be fixable on your projects side and you wont have to fix 
anything on the library's side.

Re: How is D doing?

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

On Thu, Dec 24, 2015 at 12:16:16AM +, rsw0x via Digitalmars-d-learn wrote:
[...]
> D, as I expected, has a massive following in Japan. I'm still not
> quite sure why.

Maybe because one of the most prolific contributors to D, esp. to dmd,
(and by far) happens to be from Japan?


T

-- 
Many open minds should be closed for repairs. -- K5 user

Re: Redesign of dlang.org

[Thomas Mader via Digitalmars-d]

On Wednesday, 23 December 2015 at 17:22:25 UTC, Andrei 
Alexandrescu wrote:
Yah. Overall I think a redesign is needed simply because it's 
time. Second I think the particular redesign discussed here is 
nice in many ways. Third I think I'm being reasonable if I ask 
to introduce new or custom technology dependencies only with 
good reason.


That is very reasonable I too think but isn't it a question of 
viewpoint?

I see the dependency chain for a Website as follows:

1) HTML
2) HTML, CSS
3) HTML, CSS, Javascript

It seems that the dlang.org Homepage needs CSS and Javascript so 
3 is the minimal dependency chain.
Ddoc is an additional dependency already and might be more 
efficient to insiders but to outsiders it is an obstacle.
I think you are right in saying that the site should be build 
with technologies you are most efficient with but you should also 
consider the obstacle you are building up by this.
It's hard to estimate the outcome of dropping ddoc but you might 
get more helpers by this move.


So I guess it's a question of how many contributers you get by 
removing ddoc which nobody is able to tell beforehand.
For this reason why not just try to go without it for now and 
decide later on if it is worth it or not.
I can't imagine that you loose that much efficiency by dropping 
ddoc for some time and I don't think it would be that much work 
to switch to ddoc later on.
But on the other hand I don't have a clue and might be totally 
wrong. :-)


By this decision you would also get a contributor who is willing 
to build the initial site which is propably the hardest thing to 
do.

Re: How is D doing?

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

On Thu, Dec 24, 2015 at 07:19:20AM +, rsw0x via Digitalmars-d-learn wrote:
> On Thursday, 24 December 2015 at 06:10:55 UTC, H. S. Teoh wrote:
> >On Thu, Dec 24, 2015 at 12:16:16AM +, rsw0x via Digitalmars-d-learn
> >wrote: [...]
> >>D, as I expected, has a massive following in Japan. I'm still not
> >>quite sure why.
> >
> >Maybe because one of the most prolific contributors to D, esp. to
> >dmd, (and by far) happens to be from Japan?
> >
> >
> >T
> 
> I'm aware of Kenji, I'm just not sure why because I never notice that
> many Japanese posters here.
[...]

Maybe because this forum is English-based? Just a conjecture.


T

-- 
Perhaps the most widespread illusion is that if we were in power we would 
behave very differently from those who now hold it---when, in truth, in order 
to get power we would have to become very much like them. -- Unknown

Re: Most performant way of converting int to string

[Minas Mina via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 22:29:31 UTC, Andrew Chapman 
wrote:
On Wednesday, 23 December 2015 at 11:46:37 UTC, Jakob Ovrum 
wrote:
On Wednesday, 23 December 2015 at 11:21:32 UTC, Jakob Ovrum 
wrote:
Dynamic memory allocation is expensive. If the string is 
short-lived, allocate it on the stack:


See also std.conv.toChars[1] for stringifying lazily/on-demand.

http://dlang.org/phobos/std_conv#toChars


Thanks Jakob!  I did try toChars but I couldn't quite figure 
out a syntax of calling it that the compiler was happy with.  
From memory I tried things along the lines of:


string v = toChars!(16,char,LetterCase.lower)(i);

to convert an integer to Hex for example, but the compiler 
wasn't happy with it.  How would I convert an int to a string 
using this?


Cheers.


I haven't tested it, but:
`toChars` doesn't return a string -- that's the whole point :)
It returns a range, so you have to call it something like:
auto v = toChars!(16,char,LetterCase.lower)(i);

Re: How is D doing?

[rsw0x via Digitalmars-d-learn]

On Thursday, 24 December 2015 at 06:10:55 UTC, H. S. Teoh wrote:
On Thu, Dec 24, 2015 at 12:16:16AM +, rsw0x via 
Digitalmars-d-learn wrote: [...]
D, as I expected, has a massive following in Japan. I'm still 
not quite sure why.


Maybe because one of the most prolific contributors to D, esp. 
to dmd, (and by far) happens to be from Japan?



T


I'm aware of Kenji, I'm just not sure why because I never notice 
that many Japanese posters here. It seems quite popular on 
Twitter with Japanese users though which is why I'm familiar with 
its popularity in Japan.

Re: So You Want To Write Your Own Language

[Minas Mina via Digitalmars-d-announce]

On Thursday, 24 December 2015 at 01:08:38 UTC, Walter Bright 
wrote:

This has resurfaced on Reddit:

https://www.reddit.com/r/programming/comments/3xya5v/so_you_want_to_write_your_own_language/


Very good article, thanks!

Re: How is D doing?

[Craig Dillabaugh via Digitalmars-d-learn]

On Thursday, 24 December 2015 at 00:16:16 UTC, rsw0x wrote:

On Tuesday, 22 December 2015 at 21:38:22 UTC, ZombineDev wrote:
On Tuesday, 22 December 2015 at 17:49:34 UTC, Jakob Jenkov 
wrote:

clip



removed C++ because it just dwarfs the others.
D, as I expected, has a massive following in Japan. I'm still 
not quite sure why.


Hey, this can be D's theme song:

https://www.youtube.com/watch?v=Cg6rp20OGLo

Re: Redesign of dlang.org

[Andrei Alexandrescu via Digitalmars-d]

On 12/24/2015 01:14 AM, Thomas Mader wrote:

That is very reasonable I too think but isn't it a question of viewpoint?
I see the dependency chain for a Website as follows:

1) HTML
2) HTML, CSS
3) HTML, CSS, Javascript

It seems that the dlang.org Homepage needs CSS and Javascript so 3 is
the minimal dependency chain.
Ddoc is an additional dependency already and might be more efficient to
insiders but to outsiders it is an obstacle.
I think you are right in saying that the site should be build with
technologies you are most efficient with but you should also consider
the obstacle you are building up by this.
It's hard to estimate the outcome of dropping ddoc but you might get
more helpers by this move.

So I guess it's a question of how many contributers you get by removing
ddoc which nobody is able to tell beforehand.
For this reason why not just try to go without it for now and decide
later on if it is worth it or not.
I can't imagine that you loose that much efficiency by dropping ddoc for
some time and I don't think it would be that much work to switch to ddoc
later on.
But on the other hand I don't have a clue and might be totally wrong. :-)

By this decision you would also get a contributor who is willing to
build the initial site which is propably the hardest thing to do.


Currently dlang.org has over 62KLOC of Ddoc source, so any significant 
surgery on it will be a large effort. Dropping ddoc means we'd need to 
use another templating engine (getting back to raw html would be too 
much trouble), and 10 people have 11 ideas about which template engine 
is used by "everyone".


I can give you right now an estimate - dropping ddoc and replacing it 
with vibe.d is unlikely to be a landslide success. When the alternate 
documentation was introduced using vibe.d, my hope was that everybody 
would be all over it like a cheap white suit on rice, and that the use 
of vibe.d would organically grow to make the stdlib documentation 
stellar, and then engulf the main site. Sadly participation was scant, 
and we had a couple of vibe.d-related situations in which the maintainer 
division (ahem... Vladimir and myself) had no idea on what to do and had 
nobody to rely on.


Let me put that another way: for folks who want to improve dlang.org but 
for whom ddoc is an impediment, the option exists TODAY to work on large 
parts of the site that have nothing to do with it. Yet from what I can 
tell nobody is taking it. Would you have an interest? (Serious question.)



Thanks,

Andrei

Re: D Consortium as Book / App Publisher... ?

[Jakob Jenkov via Digitalmars-d]

I really want to put these paid blogging ideas into use one 
day, but maybe D isn't the place to do it.


Or - maybe D is exactly the right use case. D doesn't already 
have a ton of available material, but still as a decent size 
community.


I'd say the hardest part is to get information about those parts 
of D which are not documented. I find the D docs for Phobos 
pretty hard to read. There are very few explanations to the 
methods and classes.


The "read the code" dogma is not very helpful to beginners in a 
new language or API.

Re: D could catch this wave: web assembly

[Abdulhaq via Digitalmars-d]

On Wednesday, 23 December 2015 at 10:06:20 UTC, Suliman wrote:
For example I do not know JS. And only C++. How would look like 
my web-app with WASM?


First have a look at this, qt-emscripten:

http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos

WASM will allow programming languages and libraries to be 
compiled down to WASM code and then run in the browser, rather 
like is happening with qt-emscripten (C++ is converted to 
javascript). As regards how it is rendered, DOM, OpenGL etc., I 
guess that will be an implementation choice.

Multiple selective imports on one line

[earthfront via Digitalmars-d-learn]

I'm using hackerpilot's excellent textadept plugin + DCD, Dfmt, 
and Dscanner.
Upon saving files, it produces suggestions, much like warnings 
from the compiler.


One suggestion is to use selective imports in local scopes. OK, 
I'll do that.


Now I'm left with a smattering of lines which are just selective 
imports from a single module:

void foo()
{
  import std.exception:enforce;
  import std.algorithm:array;
  import std.algorithm.iteration:filter;
  import std.functional:memoize;

  //..Work..
}

What is the proper way to combine these into one line?

Re: Multiple selective imports on one line

[Jakob Ovrum via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 10:51:52 UTC, earthfront wrote:
I'm using hackerpilot's excellent textadept plugin + DCD, Dfmt, 
and Dscanner.
Upon saving files, it produces suggestions, much like warnings 
from the compiler.


One suggestion is to use selective imports in local scopes. OK, 
I'll do that.


Now I'm left with a smattering of lines which are just 
selective imports from a single module:

void foo()
{
  import std.exception:enforce;
  import std.algorithm:array;
  import std.algorithm.iteration:filter;
  import std.functional:memoize;

  //..Work..
}

What is the proper way to combine these into one line?


There's no `array` in std.algorithm, and I don't see more than 
one import per module in your example, but I'm guessing what you 
want is:


import mod : a, b, c; // import a, b and c from mod

Re: Multiple selective imports on one line

[ZombineDev via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 10:51:52 UTC, earthfront wrote:
I'm using hackerpilot's excellent textadept plugin + DCD, Dfmt, 
and Dscanner.
Upon saving files, it produces suggestions, much like warnings 
from the compiler.


One suggestion is to use selective imports in local scopes. OK, 
I'll do that.


Now I'm left with a smattering of lines which are just 
selective imports from a single module:

void foo()
{
  import std.exception:enforce;
  import std.algorithm:array;
  import std.algorithm.iteration:filter;
  import std.functional:memoize;

  //..Work..
}

What is the proper way to combine these into one line?


Actually array() is from sts.array and correct way to use 
selective imports is:

import std.exception : enforce;
import std.array : array;
import std.algorithm.iteration : filter;
import std.functional : memoize;

If you want to import several symbols from one module, you can 
list them after the column like so:

import std.algorithm : any, find, sort /*, etc... */;

Re: Three Cool Things about D

[Jakob Jenkov via Digitalmars-d-announce]

On Monday, 21 December 2015 at 17:28:51 UTC, Andrei Alexandrescu 
wrote:

https://www.reddit.com/r/programming/comments/3xq2ul/codedive_2015_talk_three_cool_things_about_d/

https://www.facebook.com/dlang.org/posts/1192267587453587

https://twitter.com/D_Programming/status/678989872367988741


Andrei



Interesting talk :-) Watched it while cooking.

[Issue 15464] Template parameter-dependent attributes

[via Digitalmars-d-bugs]

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

--- Comment #5 from Daniel Kozak  ---
(In reply to Kenji Hara from comment #4)
> (In reply to Andrei Alexandrescu from comment #0)
> > Per Timon Gehr's reply, implementation could achieved the feature by means 
> > of a lowering.
> 
> A function template declaration:
> 
> void foo(T)() @attr(T.field) {}
> 
> Is now lowered to:
> 
> @attr(T.field) template foo(T) { void foo() {} }
> 
> So, as Timon said, if we change the lowered form as follows, it will support
> the enhancement naturally.
> 
> template foo(T) { void foo() @attr(T.field) {} }
> 
> 
> However, I have some questions about the corner cases in the change.
>  ...
> 

My current PR affects only postfix udas, so

@uda(T.field) void f(T)(){} still does not compile and will have same behaviour
as before.

So only postfix UDAs change and break, this can be  maybe avoid if this new
lowering will be applied only to UDAs with templates parametrs.

The biggest problem I see here is consistency

--