On 2/10/2019 6:19 AM, Mike Parker wrote:
Victor Porton decided to port an app he developed for a research project from
Ada to D. In the process, he created a bindings and a wrapper for a C library,
librdf. In this post, he shares the approach he took to translating the C API
into the D wrapper.
On 2/6/2019 11:53 AM, aberba wrote:
I've gotten preoccupied lately with startup stuff and other form distractions,
but I hope to be able to write more D related articles and tutorials on my blog
(aberba.netlify.com) and other mediums this year.
Great! Keep 'em coming!
On 1/31/2019 1:46 PM, Andrei Alexandrescu wrote:
The proposal could actually disallow rvalues that have lvalue syntax, such as
"symbol", "symbol[expr]", "symbol.symbol", "symbol.symbol[expr]", etc. Ugh. Gets
hairy quickly.
That's why it's problematic to have a rule that rvalues can be implicit
On 1/30/2019 5:55 PM, Manu wrote:
lets replace 10 with a short variable named: S
"a short variable named: S" is an lvalue, so why would the rewrite be
attempted? S must be an rvalue for any rewrite to occur. We're talking
about rvalues here.
This illustrates why this should be compared with C+
On 1/29/2019 3:45 AM, Andrei Alexandrescu wrote:
I am talking about this:
int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
if (alloc.reallocate(a, 200 * int.sizeof)
{
assert(a.length == 200);
}
Even simpler:
void func(ref void* p) {
free(p); // frees (1)
On 1/28/2019 10:10 PM, Manu wrote:
Furthermore, D has these match levels:
1. exact
2. const
3. conversion
4. no match
If there are two or more matches at the same level, the decision is made based
on partial ordering. How does adding the new ref/value overloading fit int
On 1/26/2019 8:28 AM, Rubn wrote:
[...]
The point is, the DIP needs to spell this out in an organized and complete
fashion, like any proper spec does.
We all want a better specified language, let's make it happen.
On 1/25/2019 7:44 PM, Manu wrote:
I never said anything about 'rvalue references',
The DIP mentions them several times in the "forum threads" section. I see you
want to distinguish the DIP from that; I recommend a section clearing that up.
However, my points about the serious problems with @
On 1/25/2019 2:57 AM, kinke wrote:
On Thursday, 24 January 2019 at 23:59:30 UTC, Walter Bright wrote:
On 1/24/2019 1:03 PM, kinke wrote:
(bool __gate = false;) , ((A __pfx = a();)) , ((B __pfy = b();)) , __gate =
true , f(__pfx, __pfy);
There must be an individual gate for each of __pfx and
On 1/24/2019 11:53 PM, Nicholas Wilson wrote:
That the conflation of pass by reference to avoid copying and mutation is not
only deliberate but also mitigated by @disable.
The first oddity about @disable is it is attached to the foo(int), not the
foo(ref int). If I wanted to know if foo(ref in
No, it is not rejected in principle. Finding serious errors in it on the eve of
approval is disappointing, and is not auspicious for being in a hurry to approve it.
For example, I spent a lot of time working on ARC, and was all set to move
forward with it when Timon stepped in and showed it was
On 1/24/2019 12:01 PM, kinke wrote:
`out` params are default-initialized on entry.
Ignoring backwards compatibility for a second, I think getting rid of that would
actually be beneficial (most args are probably already default-initialized by
the callee in the line above the call...)
The compi
On 1/24/2019 4:21 PM, Elie Morisse wrote:
I didn't see that coming and I'm deeply frustrated and disappointed by this
review and rejection.
On the contrary. It is good to find conceptual errors before implementing it.
They're a LOT cheaper to fix earlier rather than when it is in the field.
On 1/24/2019 4:31 PM, 12345swordy wrote:
And wait for another 180+ days for a fix? Come on dude, can you understand the
frustration being display here?
Of course it's frustrating. On the other hand, we've had a lot of problems
stemming from implementing features without thoroughly understandin
On 1/24/2019 1:03 PM, kinke wrote:
(bool __gate = false;) , ((A __pfx = a();)) , ((B __pfy = b();)) , __gate = true
, f(__pfx, __pfy);
There must be an individual gate for each of __pfx and pfy. With the rewrite
above, if b() throws then _pfx won't be destructed.
(All this rigamarole is part
On 1/24/2019 1:31 AM, Manu wrote:
This process is pretty unsatisfying, because it ships off to a
black-box committee, who were apparently able to misunderstand the
substance of the proposal and then not seek clarification, and despite
the only legitimate issue from my perspective being easily cor
On 1/17/2019 11:31 AM, H. S. Teoh wrote:
[...]
Thanks for the thoughtful and well-written piece.
But there is a counterpoint: symmetry in mathematics is one thing, but symmetry
in human intuition is not. Anytime one is dealing in human interfaces, one runs
into this. I certainly did with the
On 1/17/2019 8:06 AM, bpr wrote:
Was that a pre C++11 version of C++, or a more modern one?
pre C++11
On 1/16/2019 4:19 PM, H. S. Teoh wrote:
On Wed, Jan 16, 2019 at 11:43:19PM +, John Carter via
Digitalmars-d-announce wrote:
...I do find it remarkable that I can read the d code quite easily
without reaching for the reference manual, but to make sense of his
C++, it sends me trawling around
On 1/16/2019 3:43 PM, John Carter wrote:
Somebody on the C++ side has written a reply
https://brevzin.github.io/c++/2019/01/15/if-constexpr-isnt-broken/
From the article:
D (with corrections):
static if (maxLength < 0xFFFE) {
alias CellIdx = uint16_t;
} else {
alias CellIdx =
On 1/15/2019 11:39 AM, 12345swordy wrote:
If there were a dip that involves
deprecating class,
I wouldn't worry about that getting very far :-)
On 1/15/2019 11:08 PM, Nicholas Wilson wrote:
I'm pretty sure Jacob is talking about a completely different type of macro
(i.e. not textual substitution), AST macros.
I understand he means AST macros, but they aren't fundamentally different in the
characteristic I'm talking about.
I'd be i
On 1/15/2019 10:39 AM, Jacob Carlborg wrote:
Perhaps we shouldn't support user defined types or functions either ;)
You deliberately wrote that, and I'm confident you'd never try to pass that off
as good work.
With macros, however, programmers are convinced they are creating models of
clari
On 1/15/2019 1:10 AM, Jacob Carlborg wrote:
The AST macros I've been talking about have never been able to create new
syntax.
Template expressions can't, either, but what they do is hijack the syntax for
completely different purposes. The poor reader will be looking at code, and it
will beha
On 1/14/2019 10:49 AM, Jacob Carlborg wrote:
But Ddoc has macros ;)
Indeed it does. But the macros cannot be used to create syntax, and there is no
token concatenation. Macros cannot define other macros.
On 1/13/2019 9:31 PM, Paul Backus wrote:
Scheme is probably the language that takes this idea of a minimal "core
language" with powerful metaprogramming facilities the furthest, and the result
is a fragmented ecosystem that makes writing portable, non-trivial programs
close to impossible. (See
On 1/12/2019 7:51 AM, Andrei Alexandrescu wrote:
https://youtube.com/watch?v=tcyb1lpEHm0
One major takeaway is that the bugs/line are the same regardless of the language
used. This means that languages that enable more expression in fewer lines of
code result in fewer bugs for the same functi
On 1/12/2019 7:51 AM, Andrei Alexandrescu wrote:
https://youtube.com/watch?v=tcyb1lpEHm0
Wonderful talk! The questions asked at the end were great, too.
On 1/2/2019 5:25 AM, Martin Nowak wrote:
Glad to announce D 2.084.0, ♥ to the 53 contributors.
Have we ever had 53 for one release before? Wow!
On 12/18/2018 2:12 PM, viniarck wrote:
neovim/vim8 users out there, if you'd like to have an alternative to deoplete,
ncm2 is async and really fast, works out of the box, and it has integration with
UltiSnippets to further expand all the arguments of the completion in place. So
far, I've been q
On 12/25/2018 10:54 AM, Joakim wrote:
[...]
It's fine that you disagree with others, and it's ok when you insult me, but
when you insult others it's time to stop.
On 12/24/2018 4:30 AM, Vijay Nayar wrote:
I've been doing quite a bit of work this year on the Google S2 Geometric Library
in D. If I can benchmark the library against the C++ version or show how it can
be used to tackle some of the trickier real-time problems in large-scale web
services, would
On 12/24/2018 2:22 PM, Steven Schveighoffer wrote:
I'm sure Walter and Andrei would
not discourage more D conferences or conference-like gatherings.
Speaking for myself (and I'm sure Andrei would agree) we're all for it.
On 12/23/2018 3:40 PM, Rubn wrote:
I'll take that to assume you aren't paying for your own ticket, your own hotel
expenses, etc. I wonder if you would feel differently about this if you had to
pay for all these out of your own pocket.
I paid my own expenses for DConf. So did many of the speake
On 12/23/2018 2:59 AM, Joakim wrote:
I wish those organizing DConf would focus on that more.
You're free to organize D meetups and conferences as you see fit. Heck, C++ has
many conferences, run by different organizations with different ideas on how to
do it. Nothing wrong with that.
Even A
On 12/23/2018 1:36 AM, Russel Winder wrote:
If people want to have a DConf, it is not your position to tell them they
cannot.
No worries, we're full steam ahead on DConf 2019. I, for one, am greatly looking
forward to it and seeing everybody.
On 12/22/2018 10:20 PM, Joakim wrote:
Honestly, yours are routinely the worst presentations at DConf. Your strength as
a presenter is when you dig deeply into a bunch of technical detail or present
some new technical paradigm, similar to Andrei. Yet, your DConf keynotes usually
go the exact opp
On 12/22/2018 7:11 AM, Joakim wrote:
I've never been to DConf
I suggest actually attending and seeing for yourself.
On 12/22/2018 6:26 AM, Atila Neves wrote:
If you don't like conferences you don't have to go. I for one am excited about
being in London in May. Please don't sour it for other who think/feel like I do.
That's right. And hefting a pint with Atila is guaranteed to be a highlight of
the conferenc
On 12/22/2018 5:33 AM, Russel Winder wrote:
it's on at the exact same time as DevoxxUK 2019 which is at the
Business Design Centre. :-(
Please inform DevoxxUK they need to shift their schedule.
On 12/13/2018 10:29 AM, Adam D. Ruppe wrote:
The attribute spam is almost longer than the function itself.
Attributes only start to matter when creating code that will be around for a
long time (such as reusable libraries). It's a waste of effort for short term code.
On 12/17/2018 2:01 PM, Adam D. Ruppe wrote:
Well, I am getting back into it:
http://dpldocs.info/this-week-in-d/Blog.Posted_2018_12_17.html
Thank you, Adam!
On 12/15/2018 11:53 AM, Atila Neves wrote:
@safe and pure though...
@safe is not so hard to adopt, since by using @trusted one can proceed
incrementally.
Going pure, however, is much harder (at least for me) because I'm not used to
programming that way. Making a function pure often requires
On 12/15/2018 2:48 PM, Neia Neutuladh wrote:
The way to fix this is to replace the entire parser and get rid of the
idea of AST poisoning; at the first error, you give up on parsing the
entire file. From there, you can try recovering from specific errors with
proper testing.
DMD tries to contin
On 12/15/2018 3:29 AM, Basile B. wrote:
The time to write this announce, already 5 "crashers" found.
Great! Please post them to bugzilla.
On 12/11/2018 4:51 AM, Nicholas Wilson wrote:
> Returning a reference
Wow, thats f*ck'n stupid! https://run.dlang.io/is/SAplYw
It's quite deliberate.
ref in C++ is a type constructor, but it's so special-cased to behave like a
storage class, it might as well be one. In D it is.
(For example
#4 on HackerNews front page!
https://news.ycombinator.com/
33 points at the moment!
On 12/2/2018 7:39 PM, Vladimir Panteleev wrote:
Could you please reply to my GitHub comments?
Done.
Due to name mangling changes required by compatibility with C++11, wchar_t will
no longer mangle the same as wchar. Yes, I know, argghhh. What this means for
Windows API calls is that the alias for WCHAR will change from wchar to wchar_t.
To get a head start on this, when you're writing interfa
On 11/23/2018 5:23 AM, welkam wrote:
Currently D reads the all files
that are passed in command line before starting lexing/parsing, but in principle
we could start lexing/parsing after first file is read. In fact we could start
after first file`s first line is read.
DMD used to do that. But
On 11/23/2018 6:37 AM, welkam wrote:
Your post on reddit received more comments than D front ends inclusion to GCC.
If you titled your post differently you probably wouldn't had such success so
from my perspective its a net positive. Sure there are few people that took the
wrong message but the
On 11/23/2018 2:12 AM, Jacob Carlborg wrote:
Would it be possible to have one string table per thread and merge them to one
single shared string table before continuing with the next phase?
It'd probably be even slower because one would have to rewrite all the pointers
into the string table.
On 11/21/2018 8:48 PM, Vladimir Panteleev wrote:
On Wednesday, 21 November 2018 at 20:51:17 UTC, Walter Bright wrote:
Unfortunately, you're right. The title will leave the impression "D is slow at
compiling". You have to carefully read the article to see otherwise, and fe
I neglected point out, however, that the article itself is a home run! Thank
you, Vladimir!
On 11/21/2018 5:55 AM, Guillaume Piolat wrote:
On Wednesday, 21 November 2018 at 11:18:22 UTC, Nicholas Wilson wrote:
On Wednesday, 21 November 2018 at 08:07:52 UTC, Vladimir Panteleev wrote:
https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/
On 11/21/2018 3:19 AM, Iain Buclaw wrote:
On Wednesday, 21 November 2018 at 10:56:02 UTC, Walter Bright wrote:
Wouldn't it be awesome to have the lexing/parsing of the imports all done in
parallel? The main difficulty in getting that to work is dealing with the
shared string table.
On 11/21/2018 2:16 AM, Vladimir Panteleev wrote:
On Wednesday, 21 November 2018 at 09:46:44 UTC, Walter Bright wrote:
It works by allocating memory from a memory-mapped file, which serves as the
precompiled header.
Hey, that's a great idea! Can we do this for DMD? :D
On a more serious
On 11/21/2018 12:07 AM, Vladimir Panteleev wrote:
https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/
I implemented precompiled headers for Digital Mars C++. It took a lng time
to work all the bugs out of it. It's also a brittle system. It wo
On 11/13/2018 8:37 PM, Isaac S. wrote:
It probably depends on where someone is from (asinine isn't considered a big
insult where I live [rural US]).
Regardless of that, I will admit I did overstep (especially in calling Walter
ignorant) and so I do apologize to Walter (I'm sorry that sounds in
On 11/13/2018 8:49 PM, Jonathan M Davis wrote:
Not AFAIK, but calling someone or something extremely stupid or foolish is
almost always a terrible idea in a professional discussion (or pretty much
any discussion that you want to be civil) - especially if it can be
interpreted as calling the perso
On 11/13/2018 7:12 PM, Isaac S. wrote:
why should an enum
not convert to its declared type, rather than blindly using its literal value.
Just using the literal value discards the secondary-type information the
programmer had given it.
D has the following match levels:
1. exact
2. conversion
On 11/13/2018 3:50 PM, Isaac S. wrote:
is asinine and ignorant.
Some friendly advice - nobody is going to pay serious attention to articles that
sum up with such unprofessional statements. Continuing the practice will just
result in the moderators removing them.
On 11/13/2018 3:29 PM, Rubn wrote:
enum : int { a = 127 }
To reiterate, this does not create an anonymous enum type. 'a' is typed as
'int'. Technically,
`a` is a manifest constant of type `int` with a value of `127`.
> enum A : int { a = 127 }
`a` is a manifest constant of type `A` with a
On 11/13/2018 12:23 AM, aliak wrote:
Doesn't the above miss a step, and wouldn't it be:
1) A.a =>
2) A.a =>
So basically for the f(short) path you have 3 steps instead of 2 for the f(int)
path.
So does it matter how many implicit conversions need to happen before D stops
trying? Or is i
On 11/12/2018 1:39 PM, 12345swordy wrote:
OK, I got to know what language you were using at the time, because I am curious
at what other oddities does it have.
I wish I could remember what it was. It was like 40 years ago :-)
On 11/12/2018 12:34 PM, Neia Neutuladh wrote:
Tell me more about this "consistency".
int f(short s) { return 1; }
int f(int i) { return 2; }
enum : int { a = 0 }
enum A : int { a = 0 }
pragma (msg, f(a)); // calls f(int)
pragma (msg, f(A.a)); // calls f(short)
I.e. it's consistent.
Here's
On 11/12/2018 11:28 AM, Adam D. Ruppe wrote:
D used to have a `bit` type, wy back in the day. It was renamed to `bool`
way back in D 0.148, released Feb 25, 2006.
D's old bit type was not a bool. It literally was a single bit, and an array of
bits was packed into an int by the compiler.
On 11/12/2018 8:28 AM, 12345swordy wrote:
The issue that I see is unintended implicit conversation when passing values to
functions that have both int and bool overloads.
The exact same thing happens when there are both int and short overloads.
The underlying issue is is bool a one bit integer
On 11/12/2018 2:05 AM, Jonathan M Davis wrote:
*sigh* Well, I guess that's the core issue right there. A lot of us would
strongly disagree with the idea that bool is an integral type and consider
code that treats it as such as inviting bugs.
In my college daze I was learning programming alongsi
On 11/11/2018 3:58 PM, Mike Franklin wrote:
This is a significant milestone. Congratulations, Walter!
Many people helped out with this, too.
There are still a few .c files in
https://github.com/dlang/dmd/tree/master/src/dmd/backend, so what's the
significance of those?
tk.c
fp.c
os.c
strt
As:
https://github.com/dlang/dmd/pull/8946
removes the header files for the old C++ code!
On 11/8/2018 9:23 AM, welkam wrote:
And where can i read about naming convention? My guess its not documented
anywhere and would not be in foreseeable future or ever. Also are you sure you
are not talking about two letter variables like
sc for scope
fd for function declaration
td for template d
On 11/7/2018 11:41 PM, Manu wrote:
I'm on an i7 with 8 threads and plenty of ram... although threads are
useless, since DMD only uses one ;)
So does every other compiler.
To do a multicore build, you'll need to use a makefile that supports -j.
On 11/7/2018 10:08 PM, Vladimir Panteleev wrote:
It does seem to take more time now; I wonder why.
That's easy. It's because nobody has profiled it for years.
Another reason is the backend being in D now, it is being compiled with DMD
rather than gcc/clang.
Slides and video link:
http://nwcpp.org/october-2018.html
On 11/7/2018 2:08 PM, H. S. Teoh wrote:
I don't speak for the compiler devs, but IMO, one-letter variables are
OK if they are local, and cover a relatively small scope. Java-style
verbosity IMO makes code *harder* to read because the v
On 11/7/2018 1:49 PM, welkam wrote:
One of biggest and needless hurdle I face in reading DMD code is single letter
variable name. If I change one letter variable names to more descriptive ones
would that patch be welcomed or considered needless change?
Sorry, it would not be welcome. Single le
On 11/6/2018 3:00 PM, H. S. Teoh wrote:
What sort of refactoring are we looking at? Any low-hanging fruit here
that we non-compiler-experts can chip away at?
Simply going with foreach loops is a nice improvement.
With the recent merging of the last of the big files machobj.d:
https://github.com/dlang/dmd/pull/8911
I'm happy to say we're over the hump in converting the backend to D!
Remaining files are minor: tk.c, cgen.c, dt.c, fp.c, os.c, outbuf.c,
sizecheck.c, strtold.c and mem.c. I'll probably leave
On 11/2/2018 5:44 PM, Laeeth Isharc wrote:
When one encounters a new idea that's unfamiliar sometimes it's easy to think
that because it's unfamiliar it must be unsound. That can be a mistake. It
might be better to suspend judgement for a while and keep an open mind.
So true. My ideas on how
On 10/31/2018 6:25 AM, 12345swordy wrote:
Again what consist of a module of being "too large"?
That seems to me that more of a art then a science.
If you're looking for a rigid rule, you won't find one.
But a good indicator is if it contains more than one abstraction that has
nothing particul
On 10/31/2018 3:48 AM, Sebastien Alaiwan wrote:
I think there might be some confusion between "leaky abstraction" and
"insufficient encapsulation".
Thanks for the excellent description of the difference.
It appears to be identified as malware by Windows Defender:
https://issues.dlang.org/show_bug.cgi?id=18786#c10
and on hackernews:
https://news.ycombinator.com/item?id=18347138
Thank you, Martin!
On 10/28/2018 8:43 PM, Mike Parker wrote:
Congratulations are in order for Iain Buclaw. His efforts have been rewarded in
a big way.
I think that's an understatement. It's a massive achievement by Iain, and he did
it pretty much all on his own. Very few developers have both the technical chops
On 10/28/2018 8:43 PM, Mike Parker wrote:
Congratulations are in order for Iain Buclaw. His efforts have been rewarded in
a big way. Last Friday, he got the greenlight to move forward with submitting
his changes into GCC:
Reddit:
https://www.reddit.com/r/programming/comments/9sb74k/the_d_lang
On 10/21/2018 1:29 PM, David Gileadi wrote:
There’s a bit more to the story, but it boils down to the fact that since I
don’t have permissions to update the feature branch, I’m basically dead in
the water. So the work is all done and ready, but I have no path forward to
get it in. And it’s a bit
On 10/15/2018 2:23 PM, Walter Bright wrote:
I'm giving a presentation at:
http://nwcpp.org/
See you there!
Had a nice crowd there last night. Apparently lots of people were interested in
this topic!
Video: https://www.youtube.com/watch?v=lbp6vwdnE0k&feature=youtu.be
Sli
On 10/16/2018 1:50 AM, Dukc wrote:
On Monday, 15 October 2018 at 21:23:13 UTC, Walter Bright wrote:
I'm giving a presentation at:
Is there a video about your talk "taking advantage of D in existing C codebases"
at Code Europe? I recall that you were going to share it.
They
On 10/16/2018 3:26 AM, Dennis wrote:
Will it be streamed live?
No. It will be recorded, and posted later.
On 10/15/2018 3:30 PM, Nicholas Wilson wrote:
On Monday, 15 October 2018 at 21:23:13 UTC, Walter Bright wrote:
I'm giving a presentation at:
http://nwcpp.org/
See you there!
Where'd you get your time machine from? I want one!
Gaaah! I mean Oct. 17.
I'm giving a presentation at:
http://nwcpp.org/
See you there!
On 10/7/2018 8:41 AM, greentea wrote:
Date: September 7 to 9, 2018.
Location: Manchester, UK
GDC - D front-end GCC
https://www.youtube.com/watch?v=iXRJJ_lrSxE
Nice work, Iain!
On 9/11/2018 8:08 AM, RazvanN wrote:
[1] https://github.com/dlang/DIPs/pull/129
[2] https://github.com/dlang/dmd/pull/8688
Thank you, RazvanN!
On 8/31/2018 1:19 PM, Nick Sabalausky (Abscissa) wrote:
(IF the
programmer in question even has the expertise to implement such a system
correctly anyway - and most don't).
The closer you can get to the ideal, the better. It's not all or nothing.
I'll have done my job if people would just qui
https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/
On 8/22/2018 4:01 AM, Mihails wrote:
In my opinion, this functionality _should_ be part of
compiler itself, similar to .di generation.
This is not a bad idea.
On 6/29/2018 1:43 AM, Ecstatic Coder wrote:
Game development is a very special use case, but personally I don't think that
many of those who use C++ for close-to-the-metal development should be that much
interested in switching to D, because most of its standard libraries depend on
the presence
On 6/14/2018 12:30 PM, Jordan Wilson wrote:
I remember reading your answer on how you generate income. You said you bought
high and sold low. I suffered several losses before I realised your particular
sense of humor.
My superpower is control over the stock market. Immediately after I buy a s
On 6/14/2018 4:19 AM, jmh530 wrote:
I found myself getting in trouble when I was texting and being sarcastic. I
always add the little winky face now. People don't get mad anymore, but instead
just say I'm not funny. Good trade-off.
My sense of humor tends to the droll side, and people who don'
On 6/14/2018 2:53 AM, Unsafe wrote:
"D only has advantages" ??
What is the point of such a post?
Read the parent post.
To me, it just comes across as being DPRK like propaganda.
Evidently my brand of humor got lost in translation. I grovel and beg for
forgiveness, and will appropriately
401 - 500 of 2708 matches
Mail list logo
