On 04/10/2015 12:29 PM, Walter Bright wrote:
So someone passes an RCO via ref to avoid the inc/dec, and because
that imposes
safety issues we turn it into some sort of pass by value under the hood,
defeating the purpose, and provide an opt-out via @system opAssign.
Or you could pass it by
A small reminder, as the next point release isn't that far away, we're
now using stable branches to incorporate important bug fixes.
This means I won't look through master trying to identify relevant
commits. If there is anything that needs to go into 2.067.1 but was
accidentally merged into
On 04/10/2015 11:29 PM, Walter Bright wrote:
The latter.
Can you update that part in the DIP, it wasn't clear that the temporary
selectively pins RCO fields of a normal struct passed by ref.
On 04/11/2015 01:04 AM, Andrei Alexandrescu wrote:
What makes MessageBox special?
Andrei
For some reason the linker drags in another copy of the concurrency
module (part of it to be precise concurrency_329_3ee.o).
That collides with concurrency.o the to be tested module.
I don't have time
On 04/10/2015 09:54 AM, Daniel Murphy wrote:
Is anybody else interested in seeing this in the next release?
Give me at least a few days. I have a new idea how to make that library
AA happen. Might be able to implement that over the weekend.
On 04/09/2015 10:59 AM, Sönke Ludwig wrote:
As far as the profiler results can be trusted, a good chunk of the time
gets spent for reading individual bytes from memory, but there must be
something else low-level going on that make things this bad. However,
there is nothing fundamental in the
On 04/08/2015 03:56 PM, Sönke Ludwig wrote:
The problem is that even the pull parser alone is relatively slow. Also,
for some reason the linker reports unresolved symbols as soon as I build
without the -debug flag...
The review hasn't yet started and I'm already against the stream
parser,
On 04/09/2015 02:10 PM, John Colvin wrote:
Still getting trounced across the board by rapidjson.
Yep, anyone knows why? They don't even use a lazy parser.
On 04/08/2015 08:32 PM, tcha wrote:
Now with release numbers.
D new - debug - 14.98s, 1782.0Mb
8.53s, 1786.8Mb
D new Gdc - debug - 29.08s, 1663.9Mb
GDC still misses @nogc support.
D new Ldc - 16.99s, 1663.0Mb
18.76s, 1664.1Mb
D new lazy - debug - 11.50s, 213.2Mb
4.57s, 206Mb
D new lazy Gdc
On Tuesday, 7 April 2015 at 22:22:35 UTC, Andrei Alexandrescu
wrote:
On 4/7/15 11:42 AM, Martin Nowak wrote:
What's still missing is a faster AST interpreter for CTFE
though.
A JIT would be nice. -- Andrei
Maxine understood the point, see
http://dconf.org/2013/talks/chevalier_boisvert.pdf
On Wednesday, 8 April 2015 at 07:14:32 UTC, Iain Buclaw wrote:
With this lib it gets to [2]:
D - 7.48s, 1794.0Mb
Gdc and Ldc cannot build it with release (debug works) [3] and
[4]
Have you tried to use the pull/stream parser?
On Tuesday, 7 April 2015 at 23:38:21 UTC, Andrei Alexandrescu
wrote:
Ah, I thought the array embeds KeyValue directly. Thx! -- Andrei
It should if they are relatively small compared to the pointer,
or at least store the key inline. As we recently discussed about
the freeing bug in the AA, it
On Wednesday, 8 April 2015 at 09:58:31 UTC, Sönke Ludwig wrote:
Initial numbers that I just collected have not been as good as
expected. I'll have to take a closer look at the compiler
output.
I made a note, will see if I time to help with that. Algebraic
might be a problem as it's based on
On Tuesday, 7 April 2015 at 22:58:44 UTC, weaselcat wrote:
http://goo.gl/forms/MmsuInzDL0
Emacs
On Wednesday, 8 April 2015 at 09:12:00 UTC, Martin Nowak wrote:
The biggest problems in writing an AA library implementation
sorted by difficulty are:
There is a clear acceptance list for a good AA here.
https://github.com/D-Programming-Language/druntime/pull/934#issuecomment-65916801
On Tuesday, 7 April 2015 at 19:07:01 UTC, w0rp wrote:
On Tuesday, 7 April 2015 at 18:35:27 UTC, Martin Nowak wrote:
One thing I was wondering about, which you might know more
about, is that I had to set my load factor to be half the size
of the array, as quadratic probing seems to fail when
On Wednesday, 8 April 2015 at 06:26:04 UTC, Daniel Murphy wrote:
If we're lucky this will happen before the 2.068 release.
That would be great, though being able to compile ddmd with ldc
and/or gdc is necessary IMO to make it releasable. What's missing
to make that work?
On Tuesday, 7 April 2015 at 22:33:52 UTC, Steven Schveighoffer
wrote:
Until that point, all these discussions on AA updates are
useless.
I really don't that all or nothing attitude, it condemns an
important step, just because something better might be possible.
It's also very comfortable,
On 04/07/2015 08:28 AM, Jacob Carlborg wrote:
vibe.d has a template system. It's based on Jade, which seems to be
based on Haml.
There is also a runtime template system,
http://code.dlang.org/packages/mustache-d.
See https://github.com/D-Programming-GDC/gdcproject for an example.
On 04/06/2015 11:09 PM, Brad Anderson wrote:
We actually have a JSON parser meant to replace std.json that should be
very high performance. You can try it out now using dub:
http://code.dlang.org/packages/std_data_json
It also includes a stream parser for the highest performance
On 03/25/2015 10:38 PM, weaselcat wrote:
Anyone know if there's been any comparisons of different
heapSizeFactor values? Primarly, compared to the default 2, 1.5 or 1.618.
has anyone working on the GC actually done any comparisons of the new
options?
Yes, we compared different values and 2
On 04/07/2015 07:24 PM, Walter Bright wrote:
https://github.com/D-Programming-Language/dmd/blob/master/src/root/stringtable.c
uses quadratic probing instead of linked lists, but this is not cache
friendly, either.
Quite to the contrary, it's very cache friendly.
The triangular numbers are
1
On 04/07/2015 06:06 PM, Adam D. Ruppe wrote:
In my web projects. I used compile time stuff sometimes too, but the
runtime loading ultimately won out for the ease of editing by me and by
the frontend team - they can edit html too without needing to worry
about rerunning a compiler.
That's why
On Monday, 6 April 2015 at 08:21:46 UTC, Sönke Ludwig wrote:
Apart from that, the major additions are:
We also made dub a lot faster
https://github.com/D-Programming-Language/dub/pull/388.
On 04/06/2015 03:39 AM, Dennis Ritchie wrote:
Thanks. I hope that in the near future will be a powerful D macrosystem.
Don't expect too much enthusiasm about adding macros.
- D already has very good metaprogramming capabilities and most stuff
macros can do, can already be achieved using
On 04/04/2015 05:12 PM, Kagamin wrote:
I think, leave the seed zero and only provide a function to change it:
extern(C) void _d_setHashSeed(int seed);
Sounds good, accepting patches :).
https://issues.dlang.org/show_bug.cgi?id=14414
On 04/03/2015 06:40 PM, w0rp wrote:
I can probably help a little, if there's a bug list of things
that need to be done, etc.
Well, there is
https://issues.dlang.org/buglist.cgi?component=websiteslist_id=199823query_format=advancedresolution=---,
but it's mostly about documentation issues.
I
On 04/03/2015 06:11 PM, w0rp wrote:
Now, I am not the most fantastic Computer Science guy in the world, and
I probably got a few things wrong. If anyone would like to look at my
code and point out mistakes, please do. I will add any improvements
suggested.
You should use triangular numbers
On 04/02/2015 02:10 PM, Kagamin wrote:
The vulnerability presentation suggests perl solution (random hash seed)
is good enough, it doesn't slow down anything. The seed can be left zero
and initialized by an application as needed. One can also use a longer
key and add more its bits every,
On Friday, 3 April 2015 at 00:41:06 UTC, weaselcat wrote:
maybe wishful thinking, but it would be nice if this was on dub
until it does get some sort of review, but I'm not sure how
much work it would take to get it on there.
I turned this into a separate repo at some point,
On Thursday, 2 April 2015 at 08:32:13 UTC, anonymous wrote:
It would be nice to have such a good matrix multiplication in
Phobos but I think there are more important things to work on
(GC, AA, ...),
I'm not asking for a linear algebra library in phobos, although
we need one in dub and should
On 04/01/2015 11:20 PM, w0rp wrote:
Phobos documentation was restructured, and the new structure is good.
However, changing the URLs for the documentation has left behind a few
broken links, some of which I'm seeign in Google search results. For
example, this page I just saw.
On Wednesday, 1 April 2015 at 07:10:20 UTC, Andrei Alexandrescu
wrote:
Everything can be specified in the command line. -- Andrei
This might be a feasible approach for dlang.org or phobos (it's
already tedious there), but this doesn't work when you actually
want to use a compiler from the
On Wednesday, 1 April 2015 at 19:20:14 UTC, Dicebot wrote:
The way I have set it up personally, there is a single
/etc/dmd.conf for latest released package and bunch of
~/devel/dlang-X/bin folders, each with own dmd binary and own
dmd.conf side by side with that dmd binary - all added to PATH.
On Wednesday, 1 April 2015 at 21:20:49 UTC, w0rp wrote:
We sould track down the old links and redirect to the new
documentation pages.
Working on a fix, will hopefully be deployed tomorrow.
https://github.com/D-Programming-Language/dlang.org/pull/951
BTW, we could really need more people with
On Thursday, 2 April 2015 at 04:11:02 UTC, weaselcat wrote:
was it a conscious decision to make the AA [] operator not work
like map/etc in C++?
What do you mean?
On 04/02/2015 01:39 AM, bearophile wrote:
built-in functions for arithmetics with overflow checking
Your persistent interest in integer overflow checks make we wonder if
you were responsible for this?
http://www.around.com/ariane.html
On 04/02/2015 03:35 AM, weaselcat wrote:
the benchmark pointed out two sore areas in D(AA and std.json,) would be
nice to see AA get updated as I often completely avoid using the
built-in AA.
I filed two ERs already, both are pretty isolated and not too hard to
implement. I hope I don't have
On 04/01/2015 10:31 PM, novice2 wrote:
Can DMD compiler do it itself, as one of optimizations?
Even more interesting a complete blog post about devirtualization.
http://hubicka.blogspot.de/2014/02/devirtualization-in-c-part-4-analyzing.html
On 04/01/2015 10:31 PM, novice2 wrote:
Can DMD compiler do it itself, as one of optimizations?
You could do it as part of LTO or whole program optimization.
It requires another compiler/linker phase, so it's not easy to achieve,
maybe the LDC/GDC people have LTO running?
GCC5 comes with a big
On 03/31/2015 08:20 PM, cym13 wrote:
https://github.com/kostya/benchmarks
We made a massive jump towards the upper ranks.
#4 ¹
https://github.com/kostya/benchmarks/tree/master/brainfuck#user-content-benchmark-benchb
#2
tl;dr, please reconsider changing the conf order or splitting the conf file
https://github.com/D-Programming-Language/dmd/pull/4256#issuecomment-88316771
That dmd.conf is driving me crazy.
I need a dmd.conf in my dmd repo, so that I can use dmd-master. It
wouldn't work without a config and
On 04/01/2015 04:54 AM, Andrei Alexandrescu wrote:
I don't understand this part. -conf= should essentially remove all
notion of .conf files whatsoever.
That's only half of the story, because without a config dmd doesn't know
where to find druntime/phobos or how to link a binary.
You really
On 03/31/2015 05:51 AM, deadalnix wrote:
Yes, compiler to perform significantly better with GC than with other
memory management strategy. Ironically, I think that weighted a bit too
much in favor of GC for language design in the general case.
Why? Compilers use a lot of long-lived data
On 03/31/2015 08:46 PM, Andrei Alexandrescu wrote:
Let's see: https://github.com/kostya/benchmarks/pull/4
Please fire up a profiler, you never know anything.
On Monday, 30 March 2015 at 09:31:26 UTC, Johannes Pfau wrote:
Another thing to worry about with hash tables is this:
http://events.ccc.de/congress/2012/Fahrplan/events/5152.en.html
https://www.youtube.com/watch?v=wGYj8fhhUVA
Mmh, that's a topic for specialized hash tables IMO.
A generic hash
On Monday, 30 March 2015 at 11:23:13 UTC, thedeemon wrote:
Here's a variant of a open addressing hash table (Robin Hood
one) that uses std.container.Array instead of relying on GC:
https://bitbucket.org/infognition/robinhood/src/
(see rbhash.d, the rest is just tests)
Not documented yet, sadly.
On 03/31/2015 04:45 PM, Idan Arye wrote:
But unittests already have names(http://dpaste.dzfl.pl/b15e94000f15), so
the only required change is to allow the user to specify that name. This
should be much simpler than adding entirely new fields.
That's the line number, which can't be used as
On 04/01/2015 12:58 AM, deadalnix wrote:
So now we are going to change the language for this ?
There is a natural name for unitests, the name of the module. We have
way to break module into pieces in a backward compatible manner now, so
it's all good.
Are you saying one should split off
On 04/01/2015 01:11 AM, Andrei Alexandrescu wrote:
The reasonable course is to see how far we can get with a library-only
solution. Amaury, want to work on that? -- Andrei
In any case you should talk to Atila Neves who wrote a really good
unittest library.
On 03/31/2015 11:01 PM, Atila Neves wrote:
This is true, but importing modules by name can be code that is
generated. Which is exactly what I do with dtest [1] and unit-threaded
[2]. It's not that big of a deal when it's part of the build system.
Dub does it as well (dub test), because if you
On 03/31/2015 09:07 PM, Andrei Alexandrescu wrote:
True. I don't have time to put this on my plate, does anyone? -- Andrei
Very little, here is my outcome.
- brainfuck = better backend, better AA
The switch in the run loop doesn't use a switch table.
A lot of time is also spent on AA
On Tuesday, 31 March 2015 at 21:17:04 UTC, Martin Nowak wrote:
The simplest and most efficient way to do quadratic probing is
to use triangular numbers and a power of 2 sized hash table.
I'd be glad if someone implemented that for our current AA.
https://issues.dlang.org/show_bug.cgi?id=14385
On 03/31/2015 11:12 PM, Martin Nowak wrote:
Anyone benchmarked that SipHash?
No way we use this for druntime.
https://github.com/rurban/smhasher#readme
I think we should have a flexible Hash in std.container though, that
should allow to use a customized hash function.
On 03/30/2015 11:52 PM, Andrei Alexandrescu wrote:
I'd like to make a DIP for named unittests. Who can help me with that?
Why a DIP, isn't the only question what syntax to use.
unittest (myname) vs. unittest (mynameexpression)
Andrei
There is an ER and an half of an implementation.
On 03/31/2015 08:24 PM, deadalnix wrote:
I'm going to propose again the same thing as in the past :
- before CTFE switch pool.
- CTFE in the new pool.
- deep copy result from ctfe pool to main pool.
- ditch ctfe pool.
No, it's trivial enough to implement a full AST interpreter.
The way
On Sunday, 29 March 2015 at 22:32:34 UTC, Martin Nowak wrote:
I guess that's the counterpart to `get(key, default)` that also
inserts
the default value. That's a very much needed primitive for our
AA,
because currently you end up doing at least 1 unnecessary
lookup.
On 03/30/2015 01:14 AM, Martin Krejcirik wrote:
It seems like every DMD release makes compilation slower. This time I
see 10.8s vs 7.8s on my little project. I know this is generally least
of concern, and D1's lighting-fast times are long gone, but since Walter
often claims D's superior
On 03/29/2015 10:20 PM, Jonathan wrote:
Hey folks,
I'm been starting to work on Debian bugs and found that most of the
issues are eventually ranked from easy to hard to fix. I wondering if we
can do the same (if not already). I think it would encourage new folks
to pick up tasks (like
On 03/30/2015 05:19 PM, Jonathan wrote:
Actually, this is a good alternative: post here if anyone knows about
simple bugs that I can tackle.
Although Martin, I wouldn't considering writing patches involving atomic
ops to be easy/simple bugs. However, I think I know enough x86 asm to
write
On 03/29/2015 05:19 PM, w0rp wrote:
4. I ended up writing my own library hashmap, which when I tested ages
ago competed with the standard associative array in terms of
performance. This allows me to mark many things @safe pure nothrow.
Destroy!
Nice docs.
Always use open addressing when
On Friday, 27 March 2015 at 19:00:16 UTC, Chris wrote:
Also, and this counts for something I think, Go is a trendy
language right now, so when it comes to recruiting, I think
having Go as a critical part of Repustate’s tech stack will
help.
Stop the world, I wanna get out!
I was recently
We replace the old cherry-pick approach by introducing stable branches,
more info here http://wiki.dlang.org/DIP75#Branching_strategy.
This avoids having to manually identify bugfixes to be cherry-picked
into the release branch (2.067.0 is missing at least 2 fixes) and helps
us to do point
On 03/27/2015 04:30 PM, Shammah Chancellor wrote:
What am I missing?
A way to configure this and have it look for the most relevant
`.dfmtcfg` file! :)
That is to say, make it look up from the current directory recursively
until it finds a config file, and use that.This will greatly
On Friday, 27 March 2015 at 21:37:23 UTC, Brad Anderson wrote:
It's not clear who will be merging stable into master and when
(it's a shame Github doesn't let you target multiple branches).
Not sure we need a strict rule here and it shouldn't be necessary
to do this after each merge. Could be
On Wednesday, 25 March 2015 at 02:53:02 UTC, Rikki Cattermole
wrote:
a) A global variable that is only read before init of runtime
b) CLI args
c) CLI variables
So, wheres d? Configure by function call. I think I should get
more involved with druntime development..
You need to configure the
On Wednesday, 25 March 2015 at 19:49:38 UTC, Walter Bright wrote:
[1] http://downloads.dlang.org
Should be corrected now.
Almost, the links on the release page are wrong.
http://downloads.dlang.org/releases/
On 03/24/2015 10:11 PM, John Colvin wrote:
This cannot be added to homebrew until there is a new stable release of
dub.
Why is that?
Anyhow dub is in beta and ready soon.
On Tuesday, 24 March 2015 at 18:01:26 UTC, Andrei Alexandrescu
wrote:
Yes, amazing job. Let's gear up for the next release with
http://wiki.dlang.org/DIP75 sooner! -- Andrei
Well 2 month, that's right before dconf, sounds like a good plan.
On 03/24/2015 06:22 PM, CraigDillabaugh wrote:
Congratulations to Martin and everyone else who contributed.
And particularly thanks to Kenji and Walter for the fast bug fixing.
On Sunday, 22 March 2015 at 20:35:31 UTC, Mengu wrote:
trust me, from an undecided but experienced developer's
perspective there are so many reasons to choose D over Go. on
the
otherhand same person has a lot more reasons to choose Go over
D.
i'm writing a very long blog post about this. if
On 03/24/2015 12:59 PM, Szymon Gatner wrote:
From the changelog I don't understand what improvements have been made
to D to increase C++ interop but that is not so important to us now.
Yes, that's really lame. We need to convince Daniel to write changelog
entries.
There is another nice fix that
Glad to announce D 2.067.0.
This release comes with many improvements.
The GC is a lot faster for most use-cases, we have improved C++
interoperability and fixed plenty of bugs.
See the changelog for more details.
http://dlang.org/changelog.html
Download pages and documentation will be updated
On 03/24/2015 03:11 PM, Vlad Levenfeld wrote:
Anything going on with this? Been looking forward to seeing it for awhile.
I think we should settle on a syntax and split DIP32 in a tuple part and
a pattern matching part.
The proposal wasn't yet formally accepted, partly because we wanted to
wait,
On 03/24/2015 07:00 PM, Andrei Alexandrescu wrote:
I have one regret - the changelog is a lot more scarce than it should
because it doesn't list (or link to) a complete list of bugfixes. The
impression to first comers is that we have a release with 8 total items.
Hardly impressive.
Also
On Tuesday, 24 March 2015 at 19:54:06 UTC, Brad Roberts wrote:
For what it's worth, that's how things were setup a long time
ago (by me), but a lot of people argued enough that it was
dropped. I can't remember why.
If you look at the existing changelogs, they are much more
detailed.
On 03/23/2015 10:55 AM, Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?=
shortt...@hotmail.com wrote:
Perhaps it's too much to wish for, but I think the editor would be the
better place for this. IntelliJ IDEA can display short methods as single
line. They're still multiline in the source, but on screen
On 03/22/2015 08:56 PM, Walter Bright wrote:
If you could write a brief article about it, that would be great! I
think there's a lot of potential for D in that space, and having such
articles will help promulgate the idea.
An article would exceed the amount of code I wrote, but I did read up
On 03/23/2015 02:49 PM, Szymon Gatner wrote:
Been waiting for this for almost 2 years, might as well wait for another
release. Seriously tho, it is surprising how much little attention is
put into C++/D integration considering all the recent fuss about this.
And yes, I've tried mixed C++/D app
On Sunday, 22 March 2015 at 09:42:41 UTC, Ozan Süel wrote:
But why is GC (Garbage Collector) not running? Following the
explanations in http://wiki.dlang.org/Memory_Management memory
usage should be something around 220KB.
The GC maps memory from the underlying OS in pool sized chunks.
The
On Sunday, 22 March 2015 at 07:11:05 UTC, Suliman wrote:
Could you explain why pure vibed do not good for static files?
It's mainly a replacement for `python -m SimpleHTTPServer`, and
is just a very small tool around vibe.d's serveStaticFiles, which
does a good job at serving static files
On 03/15/2015 12:15 AM, Brian Schott wrote:
What am I missing?
Sorry haven't read the whole thread.
I think there should be an option (even default on) to allow small
single line functions.
This can sometimes be fairly annoying. For example when writing range
adapters, see
This blog post describes what to consider when switching from python to go.
http://blog.repustate.com/migrating-code-from-python-to-golang-what-you-need-to-know/#tips
It's very interesting, because the long list of things to give up for
more efficient go code reads like an argumentation against
On 03/19/2015 11:47 AM, Benjamin Thaut wrote:
This is going to be a lot of fun as soon as tons of currently private
functions in phobos are public due to the usage of export.
Why would export make private functions public?
On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote:
I actually think that there are two large categories of
programmers: those like writing the same loops over and over
again and those who use algorithms.
I agree, at some point I learned that there is a huge cultural
distinction
Sharing a useful tool of mine.
http://code.dlang.org/packages/serve
On 03/19/2015 08:02 AM, Rainer Schuetze wrote:
The COFF32 lib is built through win64.mak. This is an excerpt from my
build script to create lib32\phobos32mscoff.lib:
set dm_make=c:\l\dmc\bin\make
set vs=vs12
set vcdir=c:\l\%vs%\vc
set cl32=%vcdir%/bin/cl.exe
set ar32=%vcdir%/bin/lib.exe
On 03/04/2015 05:54 AM, Vladimir Panteleev wrote:
Finally, this is the first stable release with binary downloads for all
major platforms:
Nice, out of curiosity. How did you build the releases for all the
platforms?
On Tuesday, 17 March 2015 at 18:07:32 UTC, Szymon Gatner wrote:
Will 2.067 contain libphobos for linking with 32 bit windows
apps (COFF 32)?
No work in that direction of which I know. Can DMD generate COFF
for 32-bit now?
On 03/18/2015 01:13 AM, Manu via Digitalmars-d-announce wrote:
Yes. Has for a while.
We're really hanging out for the 32bit COFF libs to ship with DMD.
Well, someone should add a build target to
https://github.com/D-Programming-Language/phobos/blob/master/win32.mak.
How is the phobos.lib called
Release Candidate for 2.067.0
http://downloads.dlang.org/pre-releases/2.x/2.067.0/
http://ftp.digitalmars.com/
You can get the binaries here until they are mirrored.
https://dlang.dawg.eu/downloads/dmd.2.067.0-rc1/
We fixed the few remaining issues.
On Saturday, 14 March 2015 at 17:31:56 UTC, Andrei Alexandrescu
wrote:
I was looking at easy installation of dmd on ubuntu, and found
this:
http://d-apt.sourceforge.net/
Should we make it part of the official distribution?
We could try to host an apt and yum repo on dlang.org.
Might be
On Monday, 16 March 2015 at 04:54:12 UTC, Adam D. Ruppe wrote:
Ruby has over 6,000 packages,
...starting with letter A. It's over 100K in total.
http://www.modulecounts.com/
On 03/15/2015 12:48 AM, Walter Bright wrote:
On 3/14/2015 4:15 PM, Brian Schott wrote:
What am I missing?
I suggest defining The One True Way and have no configuration options.
It's a bit late to enforce a particular D code style on all the existing
code and people already using D.
Something
On Wednesday, 11 March 2015 at 16:35:22 UTC, Andrei Alexandrescu
wrote:
I would agree it would be bad if dustmite and dub were
locked-in to only work with dmd. Is that the case?
No, both support all three D compilers.
On Wednesday, 11 March 2015 at 08:00:22 UTC, Vladimir Panteleev
wrote:
On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei
Alexandrescu wrote:
It doesn't seem so to me. You find easy weaknesses in my
vision and pump on them instead of working on making it
stronger. That's the easy but that
This beta will be followed by a release candidate by the end of
the week.
Will soon be mirrored here and is also available via travis-ci.
http://downloads.dlang.org/pre-releases/2.x/2.067.0/
http://ftp.digitalmars.com/
For now you can get the binaries from my private server.
On Wednesday, 11 March 2015 at 05:15:08 UTC, Andrei Alexandrescu
wrote:
Google returns such links so it's important the pages look
professional. Could somebody fluent with ddox get on this
sooner than ASAP please? This is important and urgent, even
more so than a blocker on the release because
On Sunday, 8 March 2015 at 15:18:25 UTC, Daniel Murphy wrote:
I would prefer long periods between host compiler version
bumps, but is building completely from source really a concern?
From a release building standpoint a new release must be
buildable with the last release. I'd even opt for
On Wednesday, 4 March 2015 at 02:59:18 UTC, Brian Schott wrote:
All builds and unit tests for EMSI's data processing libraries
pass with this beta.
:)
1001 - 1100 of 1476 matches
Mail list logo
