[Issue 15476] New: DDOC_UNDEFINED_MACRO is undocumented

[via Digitalmars-d-bugs]

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

  Issue ID: 15476
   Summary: DDOC_UNDEFINED_MACRO is undocumented
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: destructiona...@gmail.com

http://dlang.org/spec/ddoc.html

"If the macro name is undefined, the replacement text has no characters in it."

Not true.

--

Re: So You Want To Write Your Own Language

[The Old One via Digitalmars-d-announce]

On Thursday, 24 December 2015 at 16:37:29 UTC, Jacob Carlborg 
wrote:

On 24/12/15 02:08, Walter Bright wrote:

This has resurfaced on Reddit:

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


In the comments, about the cluttered syntax. For the 
attributes, due to legacy reasons, it seems like D got all the 
defaults wrong. System instead of safe, mutable instead of 
immutable, not pure instead of pure and so on. We might not be 
able to get rid of any attributes but if some of these defaults 
were different perhaps it would not be necessary to use so many 
attributes all the time.


I know that many here don't agree but personally I think the 
language could have less syntax it had AST macros. Some syntax 
that is built-in now could be moved to library code in the form 
of macros.


I agree. As we all know, these choices have much to do with 
trying not to disturb all the welcome people from C/C++. But now 
that D is becoming a more self-confident language, and a larger 
percentage of newcomers to D have other backgrounds than C/C++, 
it is becoming increasingly important to have the language "do 
the Right Thing" from the outset.


By now the former C/C++ programmer has to learn an entirely new 
language, as compared to 5 or especially 10 years ago, when D 
could (well, at least sarcastically) be described as just another 
Dialect of C.


Today, D is a proud and strong, and not even a new, language, and 
the Default choices of system/safe, (im)mutable, (not)safe, etc., 
should be based only on choices that are obvious when we look at 
D now and in the foreseeable future. Not on what the past was.

[Issue 15477] New: Forward reference error corner case with base class and template specialization arguments

[via Digitalmars-d-bugs]

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

  Issue ID: 15477
   Summary: Forward reference error corner case with base class
and template specialization arguments
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: syniu...@gmail.com

Related to issue 12152, there are still bogus forward reference errors.

class QObjectPrivate : QObjectData
{
struct Sender
{
void *sender;
int signal;
int ref_;
}
}

class QObjectData
{
uint o;
QTypeInfo!uint ti;
}

struct QTypeInfo(T : uint)
{
immutable string info = "a";
}

struct QTypeInfo(T : QObjectPrivate.Sender)
{
immutable string info = "b";
}
-
Error: class main.QObjectPrivate is forward referenced when looking for
'Sender'

The order of declaration matters, if the base class QObjectData is declared
before QObjectPrivate then it compiles fine. So the workaround is simple if you
can just modify the code, but this happens with Qt5 mapped by Calypso where
this isn't an option.

What happens is:
1/ ClassDeclaration::semantic() on QObjectPrivate tries to run semantic() on
the base class QObjectData
2/ semantic() on QObjectData calls semantic() on the template instance
QTypeInfo!uint
3/ TemplateInstance::findTempDecl() attempts to semantic() the specialization
arguments of all the QTypeInfo overloads

But for the QObjectPrivate.Sender one, ClassDeclaration::search("Sender") fails
because the ClassDeclaration for QObjectPrivate doesn't have a symtab yet.

Moving the fix for issue 12152
(https://github.com/D-Programming-Language/dmd/pull/4469) to before
semantic'ing the base classes seems to fix it.


However this may not be the right way to see it.
ClassDeclaration::search("Sender") fails also because ->scope was set to NULL
at the beginning of ClassDeclaration::semantic on QObjectPrivate so search()
doesn't call semantic(). I haven't tested but that second call should work and
populate the symtab if it doesn't re-go through semantic() on the base class
(but at this point ->scope is also null for QObjectData so it won't). Anyway
simply moving the symtab populating seems like the simplest fix.

--

Re: So You Want To Write Your Own Language

[Joakim via Digitalmars-d-announce]

On Friday, 25 December 2015 at 02:56:31 UTC, Walter Bright wrote:

On 12/24/2015 5:25 AM, Joakim wrote:

Ah, I see you have it here instead:

https://www.digitalmars.com/articles/b90.html

Any idea why it's not indexed?


It's in the menu on the left.


Never mind, I looked some more and it is in google's index.  When 
I initially tried googling the phrase "perhaps you should 
consider taking up a career as a chartered accountant instead of 
writing a language" from that piece, it only turned up the spam 
site, same when I try it now.  I'm used to Google being pretty 
good at finding specific phrases like that, so I thought the 
article wasn't indexed.  Guess google is slipping...

[Issue 14804] Comparing two Nullables does not check if either is null

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 CC||b2.t...@gmx.com

--- Comment #1 from b2.t...@gmx.com ---
I was about to propose a PR that changes the behavior of Nullable but actually
I think your report is invalid:

1/ it only throws in asseert mode, which allows to detect a wrong usage when
testing the software and maybe to add some isNull() before comparing if
necessary.

2/ if a custom opEquals() is added, even if it works fine, it becomes quite
unclear how opCmp() should behave then.

see the changes:

https://github.com/BBasile/phobos/commit/f458ad1318e5536c91882c02397df262961c63a2#diff-4e008aedb3026d4a84f58323e53bf017R1930

so I suggest you to close.

--

Re: Redesign of dlang.org

[Andrei Alexandrescu via Digitalmars-d]

On 12/24/15 8:26 AM, Thomas Mader wrote:

On Thursday, 24 December 2015 at 06:43:32 UTC, Andrei Alexandrescu wrote:

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.


Thanks for those details your decision is much more clear now for me.
I didn't know that the documentation is switched to vibe.d already. So I
guess everything comes down to the following question. Do you want to
drop vibe.d or ddoc as a templating engine for the site?
Using both doesn't seem to make any sense and for me it's not clear
which way you want to go.


At the top level we all want a nice site, not to use or avoid specific 
technologies. We also need a site that the maintenance team can maintain 
effectively. This is something that tends to be forgotten.


We now added some use of vibe.d because (a) there was a champion who did 
the work (thanks Sönke! Also I recall Martin worked on that a bit), (b) 
it has advantages over ddoc, (c) there was hope that others will pick up 
on it.


Things have not yet reached critical mass. Giving up on vibe.d right now 
sounds like quite a bad decision. We'd lose some nice documentation, but 
more importantly we'd compromise the idea of reform of dlang.org. 
Conversely, replacing ddoc with vibe.d is not only a one-time effort, 
but effectively a maintenance burden for which we don't have enough 
qualified people.



I remember the decision being made that vibe.d should be more tightly
integrated into D and if that is still true the question for the
templating engine seems to already be settled.
If thats correct then allowing Jacob to do the work with vibe.d seems to
bring you one step further to the goal to introduce vibe.d


Again: vibe.d is being already used at dlang.org, yet it has seen little 
pickup. The key to making vibe.d successful on dlang.org is more folks 
fluent in vibe.d willing to help on a regular basis, not more drive-by work.



Andrei

[Issue 15464] Template parameter-dependent attributes

[via Digitalmars-d-bugs]

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

--- Comment #7 from Andrei Alexandrescu  ---
Thanks Daniel for the work and Kenji for the analysis!

There are similarities between this situation and:

static if (condition1)
void func(T)() if (condition2);

condition1 cannot use T because it hasn't "appeared" syntactically yet. Of
course, technically it's possible to make that work but it's not natural.

Somewhat similarly, for template functions it stands to reason that prefix
attributes apply to the template symbol, whereas postfix attributes apply to
the instantiation. Then:

* Attributes of the template propagate to the instantiation

* If there's a conflict between the template and instantiation attributes,
that's an error.

Sounds reasonable?

--

Mockup of my doc dream ideas

[Adam D. Ruppe via Digitalmars-d]

I wrote this manually as a mock of what I really want the docs to 
look like. I only marked up the top box and a wee bit of the 
bottom. The body text of the doc is written by us and is OK, but 
the function signature is a mess.


My mock:
http://arsdnet.net/mydoc.html

Verily, this is the status quo:
http://dlang.org/phobos/std_algorithm_searching.html#findSkip


First, you'll notice a big difference visually: the function 
signature is formatted in my example. The current thing is a mess 
of text.


I find one param per line to be much more readable, and this has 
precedent in professional documentation like Windows:


https://msdn.microsoft.com/en-us/library/windows/desktop/ms632679%28v=vs.85%29.aspx


When you start adding more default argument stuff, the break up 
per line makes a huge, huge difference IMO.


Next, observe the highlighted words... and go ahead and try to 
click on them. Oh snap! They are links to the language features 
used. This is the web, let's link all over the place. I want to 
have relevant conceptual overviews available one click away on 
every function.


The "would you like to know more" bit isn't just a Starship 
Troopers film reference, but also a bit of important information 
(not actually written in the mock) about the idiom used there. I 
know D about as well as anyone, and I had to pause for a second 
to realize what that constraint *actually* meant. Let's just 
explain it in a link. Ideally, that'd be written by the function 
author in a section of the doc that can link in, but if nothing 
else, recognized patterns can link to generic idiom explanations.



Don't put that mouse down yet! Hover over the template args 
section. Behold the tooltip title. A little thing but maybe 
useful.


And then the coup de grace: mouse over "R1" or "haystack" in the 
definition... notice how it highlights the other occurrences of 
it?


Since the signature is incomplete without the template args, the 
runtime args, AND the constraint, I wanted some way to tie them 
all together visually.


They come in three parts of the signature and cannot be easily 
combined by space, but the mouse over highlighting can draw your 
eye's attention to them from out of the crowd of text.


Mouse over R1 and you instantly see it is the first param and 
referenced as a forward range in the constraint. Constraints are 
too loose to automate much more than this, but just seeing it 
there without having to swim through every word will help you tie 
it together in your squishy puny human brain.




There's a fair chunk of writing to actually realize the 
overviews, but the highlighting and formatting stuff can be done 
automatically. I've started work on a program, using Brian 
Schott's libdparse, to see what I can do to this end but I'm 
exceedingly busy with a million things.


And I am up two hours past bed time again, ttyl all.

Re: How is D doing?

[beck via Digitalmars-d-learn]

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.
So far I've tried a while bunch of languages and i do like D 
the most, since i am used to C/C++ syntax also Java a bit, but 
i don't like Java.
Now i'm trying to can C/C++ and get accustomed to something 
more modern so D is my choice unless its a dead language.
I'm not looking into D for job opportunities. Just writing 
programs for my own amusement and maybe even profit some day.

my english is not good ~_~
i have the same question to ask.
before i have deeper learn and use on D
in china,we  have more attention to GO or Rust .
even not have a job  provided for D programer.

i am excited by the news for the answers.

Re: So You Want To Write Your Own Language

[Walter Bright via Digitalmars-d-announce]

On 12/24/2015 5:25 AM, Joakim wrote:

Ah, I see you have it here instead:

https://www.digitalmars.com/articles/b90.html

Any idea why it's not indexed?


It's in the menu on the left.

Re: So You Want To Write Your Own Language

[Jakob Jenkov via Digitalmars-d-announce]

On Thursday, 24 December 2015 at 16:37:29 UTC, Jacob Carlborg 
wrote:

On 24/12/15 02:08, Walter Bright wrote:

This has resurfaced on Reddit:

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


In the comments, about the cluttered syntax. For the 
attributes, due to legacy reasons, it seems like D got all the 
defaults wrong. System instead of safe, mutable instead of 
immutable, not pure instead of pure and so on. We might not be 
able to get rid of any attributes but if some of these defaults 
were different perhaps it would not be necessary to use so many 
attributes all the time.


I know that many here don't agree but personally I think the 
language could have less syntax it had AST macros. Some syntax 
that is built-in now could be moved to library code in the form 
of macros.



I think it depends a lot on your personal preference. For 
instance, I am always annoyed about immutable types being forced 
upon me (okay, they wouldn't be forced, but I'd have to work to 
get rid of them). I like mutable types.


Regarding the AST macros - I simply don't know enough about how 
that works in practice to have an opinion. Java doesn't have that 
stuff, so I don't know what I am missing :-)

Re: Mockup of my doc dream ideas

[James Hofmann via Digitalmars-d]

On Friday, 25 December 2015 at 05:06:47 UTC, Adam D. Ruppe wrote:
Next, observe the highlighted words... and go ahead and try to 
click on them. Oh snap! They are links to the language features 
used. This is the web, let's link all over the place. I want to 
have relevant conceptual overviews available one click away on 
every function.


Before I get to remarks about this demo, I'd like to connect the 
D doc situation with the current state of technical writing as I 
understand it(it's something I'm moving towards professionally). 
There's a set of trends I've identified in my survey of the 
landscape:


1. There's more code than ever and more of a need for code to be 
well-documented on a conceptual/hand-holding level, as well as 
the minimal "turn comments into docs" situation. "User manuals" 
are out - everyone wants easy UX - but "API docs" are in.
2. A shift away from proprietary tools like Word or Adobe 
Framemaker towards a heterogenous, open-format ecosystem - e.g. 
conversion tools like pandoc are important now.
3. "Topic-based authoring". This is mainly led by the DITA 
format, which imposes a particular *model* for how the 
documentation is laid out and how pieces of information may be 
related, vs. the more free-form linkage of a wiki or the linear 
text of traditional books. You typically see these topic-based 
systems appear in big enterprisey application software, but the 
general idea of fitting the text into a certain container is 
similar to the API doc tradition of following the 
class-and-method structure of the code.
4. A default approach that uses lighter markup like Markdown or 
wiki text in order to minimize the barriers to entry. "Heavy" 
formats like DocBook add friction to the prose-writing process, 
even though they're necessary once you pile on enough features. 
Authors may write in one and convert to the other.


The ideal documentation system for D addresses each of these - 
dedicated authors who are primarily adding prose text, a variety 
of output formats, models for defining code/data/textual 
relationships, and low friction inputs.


The mockup is good in that it cleans up the messy look and feel 
of the current presentation, and suggests the potential for 
interactivity. My main concern from a presentation standpoint is 
high latency, which in these interactive help systems typically 
comes in the form of slow page loads every time I try to click on 
something. My ideal system would stay one step ahead of me or 
allow me to stay on the same page as often as possible. Options 
for offline docs also usually fix the problem.


There is also a pretty good conceptual base in the existing ddoc 
system w/r to its goal of extending documentation comments. Its 
defaults are biased towards HTML presentation, which is OK, 
albeit not as trendy as Markdown.


What ddoc misses, though, is strong capability to invert the 
semantics towards prose-first - for example, if I wanted to write 
a very extensive tutorial that discusses a large codebase or how 
the codebase changes over time, then I'd write prose first, but 
reference an annotated version of the codebase so that I can call 
out specific parts of it. This is something that could be 
realized with a crude, hand-rolled system to extract the code and 
inline it, but it would most likely give up the semantic 
possibilities; I'd end up only having some syntax highlighting 
and not be able to let the reader click on the source and see the 
file in context, link function name callouts to their API 
documentation, etc.


One way to start seriously addressing all of these various issues 
is to export an annotated, pre-highlighted D source file with 
metadata, which could then be slurped up and processed again into 
an interactive API doc, a prose text, presentation slides, etc. 
This work can be seen as a two-parter: parsing the code and 
emitting useful, easily processed data - and then making default 
presentation of that data good, so that minimal effort is still 
rewarded. It's conceptually similar to the problem space of IDE 
integration, where different IDEs may want to query the source in 
different ways.


Semantic documentation source is also one of the rare situations 
where the XML ecosystem is at its best - XSLT basically exists to 
declaratively transform semantic markup into formatted 
presentation, as is done, for example, with DocBook. It wouldn't 
solve any *particular* problem to target XML, but it would expand 
people's ability to dream up and implement presentation-side 
solutions.

Re: So You Want To Write Your Own Language

[The Old One via Digitalmars-d-announce]

On Thursday, 24 December 2015 at 13:03:03 UTC, Walter Bright 
wrote:

On 12/23/2015 7:35 PM, Joakim wrote:
On Thursday, 24 December 2015 at 01:08:38 UTC, Walter Bright 
wrote:


Time to give your old articles a better home, I think, 
assuming you have the

copyright or can get it.


https://www.digitalmars.com/articles/b89.html


Firefox gives me this:

www.digitalmars.com uses an invalid security certificate.
The certificate is only valid for digitalmars.com
(Error code: ssl_error_bad_cert_domain)

And I believe this is an old problem.

Re: Pain when changing DMD version...

[John Colvin via Digitalmars-d]

On Thursday, 24 December 2015 at 17:20:02 UTC, JerryR wrote:
On Thursday, 24 December 2015 at 14:48:46 UTC, John Colvin 
wrote:
Often when you see breakage it's the compiler actually 
enforcing a pre-existing rule that the code in question broke.


So that made me think, there is any flag that I could turn on, 
and pass by over those errors?


JerryR.


No, because then we'd be stuck supporting every piece of code 
that used to compile, whether or not it was ever legal code. 
Illegal code that compiles is a bug; bugs must be fixed.


There are some changes that could be handled in the way you 
describe, e.g. the -dip25 flag. Doing more of these risks getting 
in to complicated interactions between them.


It's a reasonable request, but it's not going to happen except in 
carefully limited cases.

Re: Pain when changing DMD version...

[John Colvin via Digitalmars-d]

On Thursday, 24 December 2015 at 17:17:39 UTC, JerryR wrote:

On Thursday, 24 December 2015 at 16:05:18 UTC, bachmeier wrote:

But 2.060 was released in 2012...


Yes I know it's old but and the reason was to avoid breakage 
that already had happened before.


I know that sometimes this (Breakage) is inevitable as the 
language grows, but my concern here is that the language isn't 
new, and it's in version +2, and again I was changing from 
2.060 to 2.066... which looking now is already  lagged since 
the new version is 2.069.


JerryR.


I would strongly recommend moving straight to 2.069. It will take 
very little extra effort compared to going to 2.066 and there's 
been a lot of improvements and bugfixes since then. Some of the 
failures to compile you're seeing might even be bugs in 2.066!

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 21.12.2015 14:58, anonymous wrote:

http://d-ag0aep6g.rhcloud.com/

On GitHub if people want to play around with it:
https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign

That's a full clone of dlang.org in the new style. I just pasted it over
the old style, and hacked around on top of it until it worked, more or
less. It's a quick and dirty showcase. I touched everything, but
polished nothing. There are more rough edges than smooth ones.


Since Andrei and Jacob are having creative differences, I figured I'd 
just go ahead with this my way, without changes to the tooling.


This is a more proper implementation of the redesign than what I showed 
before:



http://d-ag0aep6g.rhcloud.com/

https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign


It's far from done, and I don't know if I'm going to work more on it 
over the holidays. So next year maybe.


Todo/notes:

* Legalities

What's the legal status of this? Did Ivan Smirnov give his permission to 
use the visuals? If not, can we get it, do we need it?


* Reorganization of the menu

I reorganized the menu quite a bit. The layout simply doesn't allow for 
many top level items. I don't think it's for the worse.


* Logo

Using the current D logo for now.

* Medium width menu bar

Try making the browser narrower until the main menu bar has two lines of 
text. I don't like that solution, but switching to the layout with the 
menu button seems silly at that point. Suggestions welcome.


* Subnav on narrow screens

Example: http://d-ag0aep6g.rhcloud.com/spec/intro.html

Can't have it as a side bar when the window is too narrow. Solution 
could be to have a link back to a dedicated TOC page instead. 
Suggestions welcome.


* "your code here" height

Many "your code here" snippets are too long. Cut them down, or change 
the layout to accommodate for them? I'd go with cutting them down. That 
may make the whole "your code here" idea pointless.


* Fonts

Do we go with Roboto Slab? What fallback fonts to use, and in what 
order? Candidates from the current dlang.org and from the mock-up are: 
Helvetica, Verdana, Arial, Deja Vu, BitStream Vera Sans.


I didn't adopt the monospace font from the mock-up, because it looked 
pretty bad to me (rather wide, isn't it?). Plain 'monospace' is DejaVu 
Sans Mono on my system. That one looks better, imo.


* That blank space below "Documentation" on the home page

If anyone has an idea on how to stuff it, shoot.

* Forum and twitter widgets

Does anyone make use of these? I'd totally throw them out, but it may 
better to be conservative for now. Have to style them properly then.


* forum.dlang.org and visuald.dlang.org

... will have to be updated, too. I think this is a good opportunity to 
unify the menu situation.


* "Home" link?

Do we need a named Home link in the menu bar, or is the clickable logo 
enough? There is no other way to get to the home page.


* "your code here" link

Would be nice if the subject line could be prefilled with "[your code 
here]".


* Javascript fallbacks

Simply haven't done those, yet.

* Deletions that would maybe go under the radar

These things were beloved by some (i.e. Andrei), but in the redesign 
they are no more:


  * the Slogan
  The D Programming Language
  Modern convenience. Modeling power. Native efficiency.
  * justified text (can easily make a comeback)
  * the GitHub ribbon in the upper right corner on the download page

Re: Redesign of dlang.org

[Andrei Alexandrescu via Digitalmars-d]

On 12/24/15 2:33 PM, anonymous wrote:

This is a more proper implementation of the redesign than what I showed
before:


http://d-ag0aep6g.rhcloud.com/

https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign


I like it a lot! -- Andrei

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

[karabuta via Digitalmars-d]

On Sunday, 20 December 2015 at 21:09:31 UTC, Jakob Jenkov wrote:

Writing a focused book of around 100 pages can be done in 3-6 
months. If more people chip in, it might even be faster.




There are these books floating around where various programmers 
actually come together to write them. Each author take charge of 
a section. They go like:


Problem: How to rename all files in a directory.
Solution: ..


They take advantage of common tasks and make them into a book. 
These books really sell. D community/Consortium can do similar if 
is worth it.

Re: Pain when changing DMD version...

[JerryR via Digitalmars-d]

On Thursday, 24 December 2015 at 16:05:18 UTC, bachmeier wrote:

But 2.060 was released in 2012...


Yes I know it's old but and the reason was to avoid breakage that 
already had happened before.


I know that sometimes this (Breakage) is inevitable as the 
language grows, but my concern here is that the language isn't 
new, and it's in version +2, and again I was changing from 2.060 
to 2.066... which looking now is already  lagged since the new 
version is 2.069.


JerryR.

Re: Pain when changing DMD version...

[JerryR via Digitalmars-d]

On Thursday, 24 December 2015 at 14:48:46 UTC, John Colvin wrote:
Often when you see breakage it's the compiler actually 
enforcing a pre-existing rule that the code in question broke.


So that made me think, there is any flag that I could turn on, 
and pass by over those errors?


JerryR.

Re: Pain when changing DMD version...

[Jack Stouffer via Digitalmars-d]

On Thursday, 24 December 2015 at 17:20:02 UTC, JerryR wrote:
On Thursday, 24 December 2015 at 14:48:46 UTC, John Colvin 
wrote:
Often when you see breakage it's the compiler actually 
enforcing a pre-existing rule that the code in question broke.


So that made me think, there is any flag that I could turn on, 
and pass by over those errors?


JerryR.


No. What John Colvin is referring to are bugs in the compiler 
that were fixed since 2.060.

Re: Pain when changing DMD version...

[bachmeier via Digitalmars-d]

On Thursday, 24 December 2015 at 17:17:39 UTC, JerryR wrote:

On Thursday, 24 December 2015 at 16:05:18 UTC, bachmeier wrote:

But 2.060 was released in 2012...


Yes I know it's old but and the reason was to avoid breakage 
that already had happened before.


I know that sometimes this (Breakage) is inevitable as the 
language grows, but my concern here is that the language isn't 
new, and it's in version +2, and again I was changing from 
2.060 to 2.066... which looking now is already  lagged since 
the new version is 2.069.


JerryR.


Based on my experience you should not see much breakage going 
from 2.066 to 2.069. When I moved from 2.062 to 2.064 there were 
a lot of problems. I don't expect to see that going forward. The 
quality of releases AFAICT is much better today.

Re: Voting For std.experimental.ndslice

[Jack Stouffer via Digitalmars-d]

On Sunday, 13 December 2015 at 05:10:17 UTC, Jack Stouffer wrote:
This is the voting thread to decide if the proposed addition to 
Phobos, std.experimental.ndslice, should be accepted.


Voting ends in three days.

Have a merry Christmas everyone!

Re: Most performant way of converting int to string

[Ivan Kazmenko via Digitalmars-d-learn]

On Tuesday, 22 December 2015 at 19:50:28 UTC, Daniel Kozák wrote:

V Tue, 22 Dec 2015 18:39:16 +
Ivan Kazmenko via Digitalmars-d-learn
 napsáno:
Does DMD, or Phobos function to!(string), do anything like 
that? The number of possible bases is not large anyway.  I've 
heard major C/C++ compilers do that, but have not looked for a 
proof myself.


Yes, IIRC, all D compilers should be able to change modulus and 
division to few additions, subtractions and bit shifts if base 
is known at compile time.


And phobos use this: 
https://github.com/D-Programming-Language/phobos/pull/1452


So, in a few common cases (bases 10 and 2, 4, 8, 16), you convert 
a runtime argument into a compile-time argument for the 
implementation function, and there, division is optimized at 
compile time.  Nice!

Re: What's wrong with my debugger?

[Rainer Schuetze via Digitalmars-d-learn]

On 24.12.2015 03:14, Chris wrote:

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)


One possible issue is that there are multiple variable declarations in 
the function with the names "outside, inside and collision". Dmd does 
not emit proper scope information for variables, so all variables show 
up anywhere in a function. (See for example 
https://github.com/D-Programming-Language/dmd/pull/2867).


In the locals window, mago displays all instances of variables, but with 
the same value (which might be some uninitialized value of a different 
declaration than expected). The Visual Studio debug engine shows 
different values, though.

Re: Multiple selective imports on one line

[earthfront via Digitalmars-d-learn]

On Wednesday, 23 December 2015 at 20:56:39 UTC, Basile B. wrote:
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



OK. I'm putting in my vote for this, and maybe even write up a 
pull request.


The value from this comes when using "component-oriented" 
programming, as touted by AA and WB: 
http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321


The combination of the good practice of local selective imports, 
and the use of various library functions to perform component 
oriented programming, results in verbose local "import" 
statements.


View the example below. The import section is nearly as dense as 
the component oriented block doing the actual work. This is 
smelly.



void main( string args[] )
{
  import std.exception: enforce;
  import std.array: array;
  import std.algorithm.iteration: map,filter;
  import std.string: removechars;

//..snip ..//

  auto file = File( args[1] );
  auto result =
file.byLineCopy( KeepTerminator.no, ',')
.array
.map!(a => removechars!string( a, "\"" ) )
.filter!isTriangleWord
.array
.length;

  writeln("Number of triangle words: ", result);
}


Understandably, this isn't a huge priority, but a spot for 
improvement none-the-less.


Dennis M. Ritchie's design in his comment seems to be the most 
concise:

import {std.array:array; std.algorithm.iteration:map,filter};

Re: Pain when changing DMD version...

[bachmeier via Digitalmars-d]

On Thursday, 24 December 2015 at 13:16:02 UTC, JerryR wrote:

On Thursday, 24 December 2015 at 05:50:06 UTC, Israel wrote:

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...
...you wont have to fix anything on the library's side.


Yes that's a way of thinking. But the problem that I'm facing 
right now is that I haven't tried to compile the others 
projects yet, so I may get some other errors too.


I usually see people on forums and reddit/hackernews 
complaining about Rust and the breakage along the different 
versions, back then they had not released the version 1.00 yet. 
So I wasn't expecting breakage along 2.XX in D.


JerryR.


But 2.060 was released in 2012. Recent compiler releases have 
been much more stable, in terms of not breaking much working code.

Re: So You Want To Write Your Own Language

[Jacob Carlborg via Digitalmars-d-announce]

On 24/12/15 02:08, Walter Bright wrote:

This has resurfaced on Reddit:

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


In the comments, about the cluttered syntax. For the attributes, due to 
legacy reasons, it seems like D got all the defaults wrong. System 
instead of safe, mutable instead of immutable, not pure instead of pure 
and so on. We might not be able to get rid of any attributes but if some 
of these defaults were different perhaps it would not be necessary to 
use so many attributes all the time.


I know that many here don't agree but personally I think the language 
could have less syntax it had AST macros. Some syntax that is built-in 
now could be moved to library code in the form of macros.


--
/Jacob Carlborg

Re: So You Want To Write Your Own Language

[Jakob Jenkov 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/



Hi Walther, interesting article. I guess it's like with 
entrepreneurship in general. It's a lot of work and lots of 
people will tell that you don't have what it takes, it won't 
work, you can't beat the big guys etc. But, as you progress and 
they see the results, more and more of them change their "no" to 
"maybe", "hmm..." and "yes".


I am working on a cloud project where we will also need to 
implement a little language that can run inside our cloud. The 
constraints are quite different from a general purpose language 
in terms of compilation / interpretation time, memory usage etc. 
so the design will probably be different than e.g. D.


I am looking forward to this project. Yes, it's geeky, and yes, 
it will probably "suck" in the first versions - but eventually we 
will get there, and it will work just fine.

Re: [DerelictSDL] SDL_RenderCopy does not accept optional arguements when written in a file aside from main

[Lucien via Digitalmars-d-learn]

On Thursday, 24 December 2015 at 09:41:39 UTC, Jack wrote:
So I have separated my texture rendering methods in another 
file and have run into a problem hence the title name.


#main.d
--

void render()
{
SDL_RenderClear(renderTarget);
renderSprite(renderTarget);
SDL_RenderPresent(renderTarget);
}
--
#other_file.d
---
void renderSprite(SDL_Renderer _renderTarget)
{

SDL_Texture texture = 
SDL_CreateTextureFromSurface(_renderTarget, 
IMG_Load("image.png"));


SDL_RenderCopy(_renderTarget,texture, null,null);
}
--

Error: cannot implicitly convert expression (null) of type 
typeof(null) to SDL_Rect
Error: cannot implicitly convert expression (null) of type 
typeof(null) to SDL_Rect


=
But when I do this:

#main.d
---

void render()
{
SDL_RenderClear(renderTarget);
SDL_RenderCopy(renderTarget,texture,null,null);
SDL_RenderPresent(renderTarget);
}


It works with no problem. I've DerelictSDL2.load and SDL_Init 
already.

So is this a bug or am I doing something wrong here?


You need a pointer to renderTarget.


#other_file.d

-
module my.sdl.project;

import derelict.sdl2.sdl;
import derelict.sdl2.image;


void renderSprite(SDL_Renderer* _renderTarget)
{
SDL_Texture* texture = 
SDL_CreateTextureFromSurface(_renderTarget, 
IMG_Load("image.png"));

SDL_RenderCopy(_renderTarget,texture, null,null);
}
---

#main.d
---

import my.sdl.project;
//...
---

[DerelictSDL] SDL_RenderCopy does not accept optional arguements when written in a file aside from main

[Jack via Digitalmars-d-learn]

So I have separated my texture rendering methods in another file 
and have run into a problem hence the title name.


#main.d
--

void render()
{
SDL_RenderClear(renderTarget);
renderSprite(renderTarget);
SDL_RenderPresent(renderTarget);
}
--
#other_file.d
---
void renderSprite(SDL_Renderer _renderTarget)
{

SDL_Texture texture = SDL_CreateTextureFromSurface(_renderTarget, 
IMG_Load("image.png"));


SDL_RenderCopy(_renderTarget,texture, null,null);
}
--

Error: cannot implicitly convert expression (null) of type 
typeof(null) to SDL_Rect
Error: cannot implicitly convert expression (null) of type 
typeof(null) to SDL_Rect


=
But when I do this:

#main.d
---

void render()
{
SDL_RenderClear(renderTarget);
SDL_RenderCopy(renderTarget,texture,null,null);
SDL_RenderPresent(renderTarget);
}


It works with no problem. I've DerelictSDL2.load and SDL_Init 
already.

So is this a bug or am I doing something wrong here?

Re: [DerelictSDL] SDL_RenderCopy does not accept optional arguements when written in a file aside from main

[Jack via Digitalmars-d-learn]

On Thursday, 24 December 2015 at 10:42:57 UTC, Lucien wrote:

On Thursday, 24 December 2015 at 09:41:39 UTC, Jack wrote:

[...]


You need a pointer to renderTarget.


#other_file.d

-
module my.sdl.project;

import derelict.sdl2.sdl;
import derelict.sdl2.image;


void renderSprite(SDL_Renderer* _renderTarget)
{
SDL_Texture* texture = 
SDL_CreateTextureFromSurface(_renderTarget, 
IMG_Load("image.png"));

SDL_RenderCopy(_renderTarget,texture, null,null);
}
---

#main.d
---

import my.sdl.project;
//...
---


I actually have a pointer in the original project but I seem to 
forgot it when I'm typing this example. Sorry bout the 
misunderstanding, but yeah problem still stands.

Re: Template parameter-dependent attributes

[deadalnix via Digitalmars-d]

On Wednesday, 16 December 2015 at 17:14:50 UTC, Andrei 
Alexandrescu 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.


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


If this won't work at all, I'll need to resort to expressing 
complexity via traits. Not as nice!



Thanks,

Andrei


What you are asking the compiler here is ambiguous. It is not 
clear if the attribute apply to the template (in which case 
argument may not be used) or the instantiated eponymous function 
in it.

Re: [DerelictSDL] SDL_RenderCopy does not accept optional arguements when written in a file aside from main

[Lucien via Digitalmars-d-learn]

On Thursday, 24 December 2015 at 11:32:24 UTC, Jack wrote:

On Thursday, 24 December 2015 at 10:42:57 UTC, Lucien wrote:

On Thursday, 24 December 2015 at 09:41:39 UTC, Jack wrote:

[...]


You need a pointer to renderTarget.


#other_file.d

-
module my.sdl.project;

import derelict.sdl2.sdl;
import derelict.sdl2.image;


void renderSprite(SDL_Renderer* _renderTarget)
{
SDL_Texture* texture = 
SDL_CreateTextureFromSurface(_renderTarget, 
IMG_Load("image.png"));

SDL_RenderCopy(_renderTarget,texture, null,null);
}
---

#main.d
---

import my.sdl.project;
//...
---


I actually have a pointer in the original project but I seem to 
forgot it when I'm typing this example. Sorry bout the 
misunderstanding, but yeah problem still stands.


I can't help you without your original code.

Re: So You Want To Write Your Own Language

[Joakim via Digitalmars-d-announce]

On Thursday, 24 December 2015 at 13:21:45 UTC, Joakim wrote:
On Thursday, 24 December 2015 at 13:03:03 UTC, Walter Bright 
wrote:

On 12/23/2015 7:35 PM, Joakim wrote:

[...]


https://www.digitalmars.com/articles/b89.html


That's a different article, the Gimli one, not the one with 
practical advice.  Also, I get a certificate error when I click 
on it, because it doesn't apply for the www subdomain.


Ah, I see you have it here instead:

https://www.digitalmars.com/articles/b90.html

Any idea why it's not indexed?

[Issue 15473] New: C++ mangling problem

[via Digitalmars-d-bugs]

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

  Issue ID: 15473
   Summary: C++ mangling problem
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

C++ produces this symbol:
?asAssocArray@Variant@ep@@QEBA?AU?$SharedMap@U?$AVLTree@UVariant@ep@@U12@U?$Compare@UVariant@ep@@@2@@ep@@@2@XZ

D produces this symbol:
?asAssocArray@Variant@ep@@QEBA?AU?$SharedMap@U?$AVLTree@UVariant@ep@@0U?$Compare@UVariant@ep@@@2@@ep@@@2@XZ


The difference is that little 'U12@' vs '0'. The MS linker de-mangles both
symbols to read identical, so I don't know what it means.


The C declaration:

namespace ep {
struct Variant
{
  ep::SharedMap> asAssocArray() const;
};
} // namespace


The D declaration:

extern (C++, ep) {
struct Variant
{
  SharedMap!(AVLTree!(Variant, Variant, Compare!Variant)) asAssocArray() const;
}
}


All those things are extern(C++, ep), and they work properly on their own.

--

Re: What's wrong with my debugger?

[Chris via Digitalmars-d-learn]

On Thursday, 24 December 2015 at 09:30:24 UTC, Rainer Schuetze 
wrote:
In the locals window, mago displays all instances of variables, 
but with the same value (which might be some uninitialized 
value of a different declaration than expected). The Visual 
Studio debug engine shows different values, though.


Hi, thanks for the reply but not actually, no, if I change the 
debug engine to VS and rebuild I get the same behaviour.

Re: So You Want To Write Your Own Language

[Walter Bright via Digitalmars-d-announce]

On 12/23/2015 7:35 PM, Joakim wrote:

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.


https://www.digitalmars.com/articles/b89.html

Re: So You Want To Write Your Own Language

[Walter Bright via Digitalmars-d-announce]

On 12/24/2015 3:43 AM, Jakob Jenkov wrote:

I am working on a cloud project where we will also need to implement a little
language that can run inside our cloud. The constraints are quite different from
a general purpose language in terms of compilation / interpretation time, memory
usage etc. so the design will probably be different than e.g. D.

I am looking forward to this project. Yes, it's geeky, and yes, it will probably
"suck" in the first versions - but eventually we will get there, and it will
work just fine.


I wish you the best for it.

Re: Pain when changing DMD version...

[JerryR via Digitalmars-d]

On Thursday, 24 December 2015 at 05:50:06 UTC, Israel wrote:

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...
...you wont have to fix anything on the library's side.


Yes that's a way of thinking. But the problem that I'm facing 
right now is that I haven't tried to compile the others projects 
yet, so I may get some other errors too.


I usually see people on forums and reddit/hackernews complaining 
about Rust and the breakage along the different versions, back 
then they had not released the version 1.00 yet. So I wasn't 
expecting breakage along 2.XX in D.


JerryR.

Re: Redesign of dlang.org

[Thomas Mader via Digitalmars-d]

On Thursday, 24 December 2015 at 06:43:32 UTC, Andrei 
Alexandrescu wrote:
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.


Thanks for those details your decision is much more clear now for 
me.
I didn't know that the documentation is switched to vibe.d 
already. So I guess everything comes down to the following 
question. Do you want to drop vibe.d or ddoc as a templating 
engine for the site?
Using both doesn't seem to make any sense and for me it's not 
clear which way you want to go.
I remember the decision being made that vibe.d should be more 
tightly integrated into D and if that is still true the question 
for the templating engine seems to already be settled.
If thats correct then allowing Jacob to do the work with vibe.d 
seems to bring you one step further to the goal to introduce 
vibe.d


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.)


At the moment my interest in Web Development is pretty low but I 
am interested to fix errors and add content as I see fit.

For that it's nice if the hurdle is as low as possible.
For me it probably doesn't make any difference if I need to use 
vibe.d or ddoc since I don't know them but I guess one of them is 
better suited for the task.

Re: Template parameter-dependent attributes

[deadalnix via Digitalmars-d]

On Thursday, 24 December 2015 at 13:23:51 UTC, Xiaoxi wrote:

prefix binds to template.


And implcit function arguments ?

Re: How is D doing?

[ShinraTensei via Digitalmars-d-learn]

On Thursday, 24 December 2015 at 05:44:03 UTC, Craig Dillabaugh 
wrote:

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


I strangely find this more fitting. :)
https://www.youtube.com/watch?v=ls3rD8VfiSY

Re: [DerelictSDL] SDL_RenderCopy does not accept optional arguements when written in a file aside from main

[Jack via Digitalmars-d-learn]

On Thursday, 24 December 2015 at 12:42:11 UTC, Lucien wrote:

On Thursday, 24 December 2015 at 11:32:24 UTC, Jack wrote:

On Thursday, 24 December 2015 at 10:42:57 UTC, Lucien wrote:

[...]


I actually have a pointer in the original project but I seem 
to forgot it when I'm typing this example. Sorry bout the 
misunderstanding, but yeah problem still stands.


I can't help you without your original code.


I think I fixed it. I was initializing SDL_Rects to nulls inside 
some of the arguments. It was a slight case of Spaghetti Code.

Oh well, thank you for your time.

[Issue 15473] C++ mangling problem

[via Digitalmars-d-bugs]

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

--- Comment #1 from Manu  ---
On a tangent, I'm having a lot of trouble with the fact that MSVC mangles
classes differently than struct's... I feel like I need a way to control which
to choose on the D side. UDA perhaps?

--

[Issue 15474] New: Ddoc - defining an empty macro at the end of a Macros section does not work

[via Digitalmars-d-bugs]

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

  Issue ID: 15474
   Summary: Ddoc - defining an empty macro at the end of a Macros
section does not work
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: destructiona...@gmail.com

/**
Test

test2

test3

Macros:
DDOC=$(BODY)
DDOC_BLANKLINE=
*/
module t2;



Generates:


Test

test2


test3




Those blank lines are still there. Swap the order of definition of those two
macros:


/**
Test

test2

test3

Macros:
DDOC_BLANKLINE=
DDOC=$(BODY)
*/
module t2;



Hey, look, blank line = nothing respected now!


Test

test2


test3





Notice that there isn't one between test2 and test3 anymore.

--

Re: Template parameter-dependent attributes

[deadalnix via Digitalmars-d]

On Monday, 21 December 2015 at 13:58:53 UTC, Andrei Alexandrescu 
wrote:

On 12/16/2015 12:14 PM, Andrei Alexandrescu wrote:
[snip]

I submitted https://issues.dlang.org/show_bug.cgi?id=15464, 
which is preapproved. There is a bit of a sense of urgency to 
it - it blocks the bigo library proposal and an article.


Takers?


Andrei


I think this is a bit pushed out of the door. What if I want to 
'attribute' the template itself ?

Re: Template parameter-dependent attributes

[Xiaoxi via Digitalmars-d]

On Thursday, 24 December 2015 at 12:45:12 UTC, deadalnix wrote:
On Monday, 21 December 2015 at 13:58:53 UTC, Andrei 
Alexandrescu wrote:

On 12/16/2015 12:14 PM, Andrei Alexandrescu wrote:
[snip]

I submitted https://issues.dlang.org/show_bug.cgi?id=15464, 
which is preapproved. There is a bit of a sense of urgency to 
it - it blocks the bigo library proposal and an article.


Takers?


Andrei


I think this is a bit pushed out of the door. What if I want to 
'attribute' the template itself ?


prefix binds to template.

Re: So You Want To Write Your Own Language

[Joakim via Digitalmars-d-announce]

On Thursday, 24 December 2015 at 13:03:03 UTC, Walter Bright 
wrote:

On 12/23/2015 7:35 PM, Joakim wrote:
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.


https://www.digitalmars.com/articles/b89.html


That's a different article, the Gimli one, not the one with 
practical advice.  Also, I get a certificate error when I click 
on it, because it doesn't apply for the www subdomain.

Re: D could catch this wave: web assembly

[Stefan Koch via Digitalmars-d]

On Thursday, 18 June 2015 at 08:05:48 UTC, John Colvin wrote:
This appears to have involvement from all major browser 
vendors, which provides hope it might actually catch on 
properly. An llvm backend will be created which will compile to 
"wasm", hopefully LDC and/or SDC could glue to this.


https://www.w3.org/community/webassembly/

https://github.com/WebAssembly

In particular, see 
https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md https://github.com/WebAssembly/design/blob/master/FAQ.md and https://github.com/WebAssembly/design/blob/master/MVP.md


As far as SDC support goes...
I am pretty torn.

We need more platforms to see if our API is going to hold up.
But at the same time we need to be focused on compiling more of 
D...

If someone is willing to do this I can provide a little support.

Re: Pain when changing DMD version...

[John Colvin via Digitalmars-d]

On Thursday, 24 December 2015 at 13:16:02 UTC, JerryR wrote:

On Thursday, 24 December 2015 at 05:50:06 UTC, Israel wrote:

On Thursday, 24 December 2015 at 04:06:40 UTC, JerryR wrote:

[...]


Upgrading GTKD is definitely the best route...
...you wont have to fix anything on the library's side.


Yes that's a way of thinking. But the problem that I'm facing 
right now is that I haven't tried to compile the others 
projects yet, so I may get some other errors too.


I usually see people on forums and reddit/hackernews 
complaining about Rust and the breakage along the different 
versions, back then they had not released the version 1.00 yet. 
So I wasn't expecting breakage along 2.XX in D.


JerryR.


Often when you see breakage it's the compiler actually enforcing 
a pre-existing rule that the code in question broke.

[Issue 15475] New: Ddoc code sample with unbalanced paren comes out as macro

[via Digitalmars-d-bugs]

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

  Issue ID: 15475
   Summary: Ddoc code sample with unbalanced paren comes out as
macro
   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

/**
---
// code sample with unbalanced (
---
*/
module t2;


Spits out:


// code sample with unbalanced $(LPAREN)



in the final code.

--

[Issue 15474] Ddoc - defining an empty macro at the end of a Macros section does not work

[via Digitalmars-d-bugs]

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

Adam D. Ruppe  changed:

   What|Removed |Added

   Severity|enhancement |minor

--