On Tuesday, 27 August 2019 at 17:11:33 UTC, Mike Franklin wrote:
If you look at the vibe.d compile-time graph, you'll see
there's a 2.5s increase around Mid-2014.
Sorry, that should be Mid-2015.
On Tuesday, 27 August 2019 at 12:58:20 UTC, Vladimir Panteleev
wrote:
It will eventually zero in to commit-level accuracy after it's
been running for a while. I cleared the database as the last
time it was running, it was on another CPU, so the timings are
going to be different. (Still need
On Monday, 26 August 2019 at 18:51:54 UTC, Vladimir Panteleev
wrote:
Here's the original blog post:
https://blog.thecybershadow.net/2015/05/05/is-d-slim-yet/
I'll give it a kick and get it back online if there is
interest. Seems wasteful to reimplement it from scratch, though.
It's great
On Wednesday, 17 July 2019 at 13:56:38 UTC, RazvanN wrote:
We have encouraged the graduating students to participate to
SAOC and also we are in discussions with some of them to
initiate them into contributing to D.
And we'd love to have them. "Well done!" to everyone involved.
Mike
On Monday, 15 July 2019 at 14:58:55 UTC, Mike Parker wrote:
In the Draft Review for Walter's DIP, Argument Ownership and
Function Calls (which in the next half hour or so will be
starting a community review as DIP 1021), some folks asked for
some information about the bigger picture. In
On Monday, 15 July 2019 at 13:00:08 UTC, Vladimir Panteleev wrote:
We are trying to implement many of those `extern(C)` runtime
hooks as templates. Those templates need to be implicitly
imported through object.d. That means code that was in `rt`
is converted to a template, and then moved to
On Monday, 15 July 2019 at 13:06:58 UTC, Vladimir Panteleev wrote:
On Monday, 15 July 2019 at 12:42:57 UTC, Mike Franklin wrote:
... and are the exception, not the rule. I believe they
should be moved to `rt`.
BTW, from this discussion it seems to me that you did not have
a good overview of
On Monday, 15 July 2019 at 12:27:22 UTC, Vladimir Panteleev wrote:
This isn't exactly true. The restriction is that core should
not *import* rt. Have a look at all the extern(C) definitions
in Druntime - using extern(C) functions to communicate between
the compiler and rt, as well as core and
On Monday, 15 July 2019 at 12:40:50 UTC, Vladimir Panteleev wrote:
- core.internal.hash contains the implementation of hashing
routines used for associative arrays.
- core.internal.arrayop contains the implementation of array
vector operations. This one doesn't seem to be too far from
your
On Monday, 15 July 2019 at 12:19:02 UTC, Vladimir Panteleev wrote:
You don't need to move the implementations themselves into
core.internal. Adding declarations there for the rt
implementations would suffice.
Many of the implementations in `rt/array` are templates, so the
entire
On Monday, 15 July 2019 at 12:02:35 UTC, Seb wrote:
I think that fits core.internal better than rt. Have you
considered that during said discussion?
The implementations in `rt/array` contain templates that are
ports of runtime hooks that used to reside in `rt`. The
implementations also
On Monday, 15 July 2019 at 10:52:08 UTC, Vladimir Panteleev wrote:
On Thursday, 4 July 2019 at 12:57:43 UTC, Mike Franklin wrote:
The copy should take place when building druntime from the
makefiles. The files to be copied are listed at
On Thursday, 4 July 2019 at 12:48:15 UTC, Robert M. Münch wrote:
So, the problem is, that digger somehow misses to copy over the
new source to the install directory. It does for some parts
(phobos, but I'm not sure if for every file necessary) but not
for druntime files.
I just manually
On Thursday, 4 July 2019 at 10:01:10 UTC, Robert M. Münch wrote:
On 2019-07-04 08:11:26 +, Martin Nowak said:
Glad to announce D 2.087.0, ♥ to the 63 contributors.
This release comes with types matching single template alias
parameters,
nested template methods/local template functions,
On Saturday, 25 May 2019 at 21:56:57 UTC, Murilo wrote:
Sorry people
It's ok. I know you meant well, and we're happy to have people
in this community so passionate about D.
Mike
On Saturday, 25 May 2019 at 03:22:50 UTC, Murilo wrote:
On the 6th of June(6/6) we celebrate the D day on Normandy, but
I have decided to turn it into our own holiday to celebrate the
D language.
I'm sure you mean well, but I will be spending D-Day remembering
the sacrifice of these men:
On Friday, 24 May 2019 at 11:41:12 UTC, Atila Neves wrote:
I'd been holding off on announcing this until DIP1008 actually
got implemented, and now it has:
https://code.dlang.org/packages/nogc
This dub package has a @nogc version of `std.conv.text` (which
probably isn't as good yet) that,
On Friday, 17 May 2019 at 20:59:43 UTC, Mike Franklin wrote:
I don't think it does because `Queue!(T).store` has infinite
lifetime beyond that of even `main`, at least as far as the
compiler is concerned. The compiler doesn't have enough
information to know that `store` is tied to the
On Friday, 17 May 2019 at 17:03:51 UTC, Meta wrote:
If you look at `main` above, `rawData` has the same lifetime as
the `dataRange` struct returned from `makeDataRange` and the
queue returned from `copyToQueue`. True, there is some
traditionally unsafe stuff happening in between; however, I
On Friday, 17 May 2019 at 05:22:30 UTC, Mike Franklin wrote:
My assessment (which could be wrong):
`scope` and `return` only apply to pointers and `ref`s. If you
remove all `scope` and `return` attributes from the function
`push`, it works fine.
I consider it a bug that the compiler
On Friday, 17 May 2019 at 04:50:52 UTC, Meta wrote:
Walter, can I get you to take a look at this post I made a few
months ago, and the contained example? I feel that this is a
case that *should* definitely work, but I'm not sure if it can
*currently* work - and so far, nobody else seems to be
On Wednesday, 15 May 2019 at 01:15:43 UTC, Andrei Alexandrescu
wrote:
That we even discuss just how bad bool is while we have no done
deals for safety, reference counting, shared, package
distribution/versioning, pay-as-you-go runtime, collections,
..., is a fascinating puzzle.
It can all
On Wednesday, 15 May 2019 at 00:23:44 UTC, Andrei Alexandrescu
wrote:
There are many clowny things in D, of which bool is at best
somewhere beyond the radar. I suggest investing time *
expertise in the larger ones.
Once again, I disagree with what you think is important. `bool`
is a
On Tuesday, 14 May 2019 at 15:40:19 UTC, Kagamin wrote:
On Sunday, 12 May 2019 at 06:27:21 UTC, Nick Sabalausky
(Abscissa) wrote:
All this effort strongly implies that there's no such thing as
a satisfactory bool type *in languages which conflate booleans
with integers*
FWIW I write C# for
On Saturday, 11 May 2019 at 20:35:40 UTC, Exil wrote:
Sure it is convenient to have some properties of bool also be
similar to an integer, but it can definitely not be swapped in
to be used like a 1-bit integer and there are already plenty of
special rules for it.
Thanks for that analysis.
On Saturday, 11 May 2019 at 20:35:40 UTC, Exil wrote:
Regarding the discussion of how bool is handled...
It's a one bit integer so it should behave like a one bit
integer
https://www.youtube.com/watch?v=cpTAtiboIDs#t=2h17m50s
I think Walter is conflating how bool is stored in memory with
On Saturday, 11 May 2019 at 05:39:12 UTC, H. S. Teoh wrote:
So potentially a D-based memcpy could have multiple concrete
implementations (copying strategies) that are statically chosen
based on the properties of T, like alignment and size.
Exactly.
[...]
However, DMD won't do the right
On Saturday, 11 May 2019 at 00:32:54 UTC, H. S. Teoh wrote:
When it comes to performance, I've essentially given up looking
at DMD output. DMD's inliner gives up far too easily, leading
to a lot of calls that aren't inlined when they really should
be, and DMD's optimizer does not have loop
On Saturday, 11 May 2019 at 00:09:08 UTC, Mike Franklin wrote:
On Friday, 10 May 2019 at 23:51:56 UTC, H. S. Teoh wrote:
I'm not 100% sure it's a good idea to implement memcpy in D
just to prove that it can be done / just to say that we're
independent of libc. Libc implementations of
On Friday, 10 May 2019 at 23:51:56 UTC, H. S. Teoh wrote:
I'm not 100% sure it's a good idea to implement memcpy in D
just to prove that it can be done / just to say that we're
independent of libc. Libc implementations of fundamental
operations, esp. memcpy, are usually optimized to next week
On Friday, 10 May 2019 at 17:55:53 UTC, Johan Engelen wrote:
Why would you use inline assembly ? (generalizing but:
extremely bad portability, bad performance, bad readability)
The only reason to use inline assembly is to achieve something
that can't be achieved directly with D. For
On Friday, 10 May 2019 at 05:20:59 UTC, Eugene Wissner wrote:
- Memcmp, memcpy, memmove and memset are named equal, copy,
copyBackward and fill respectively. I just wanted to create
native implementations that are bit safer than their C
counterparts. So they do the same job, but accept void[]
On Thursday, 9 May 2019 at 07:45:41 UTC, Andrei Alexandrescu
wrote:
Just checked, it works:
https://youtu.be/Vj6jNAlv03o
Thank You!
On Wednesday, 8 May 2019 at 08:21:33 UTC, Thomas Brix Larsen
wrote:
I am able to join with Firefox. I can see the video, but no
audio. I'm still troubleshooting.
Mike
I had to click Audio Connection -> Computer to get audio.
You mean the "Call using computer" option. That gives me an
On Wednesday, 8 May 2019 at 08:00:15 UTC, Andrej Mitrovic wrote:
On Wednesday, 8 May 2019 at 07:57:40 UTC, Mike Parker wrote:
The venue uses WebEx for livestreaming. All the information is
available in this PDF:
https://drive.google.com/open?id=1yekllbfOmxHqJNuuWIVeP9vNeROmfp1I
"When
On Sunday, 5 May 2019 at 05:23:26 UTC, Eugene Wissner wrote:
you may remember that I'm working on a library named "tanya"
(https://github.com/caraus-ecms/tanya). It is now almost
phobos-free and I reimplemented some routines from libc for
x86-64 linux. Ideally I'd like to get rid of libc for
On Monday, 22 April 2019 at 12:24:16 UTC, Mike Parker wrote:
To coincide with the announcement of DStep 1.0.0, Jacob
submitted a post to the D Blog that goes into detail on all the
new stuff included in this release.
The blog:
https://dlang.org/blog/2019/04/22/dstep-1-0-0/
Reddit:
On Friday, 12 April 2019 at 17:55:28 UTC, Piotrek wrote:
Coding guidelines like MISRA and AUTOSAR have been developed
and matured for C++ for years. There is no equivalent for D
for it to be even considered by the automotive industry.
Well, MISRA is an evidance that C (C++) is quite error
On Saturday, 26 January 2019 at 10:24:05 UTC, Sebastiaan Koppe
wrote:
Spasm is a betterC library for web development that uses LDC to
compile to WebAssembly, and I just released a major update.
It now has bindings to most web api's, like the dom, fetch,
audio, webgl, etc.
[...]
See the
On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote:
When something like an object system is made part of the
language (or at the very least, the standard library), it
becomes a focal point [2] that the community can coordinate
around. Due to the diverse, distributed nature of any
On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu
wrote:
https://youtube.com/watch?v=tcyb1lpEHm0
I especially like how design by introspection was contrasted with
concepts and metaclasses, culminating in "We want to generate
more smart code, not more boilerplate. We want to
On Tuesday, 11 December 2018 at 14:38:25 UTC, Steven
Schveighoffer wrote:
@property: This was almost about to be awesome, but squabbling
amongst the D core team killed it.
Yes, the problem with @property is that it is neither correctly
implemented nor completely implemented. And to do the
On Monday, 10 December 2018 at 18:27:48 UTC, Neia Neutuladh wrote:
I wrote a post about language-agnostic (or, more accurately,
cross- language) build tools, primarily using D as an example
and Dub as a benchmark.
Spoiler: dub wins in speed, simplicity, dependency management,
and actually
On Sunday, 11 November 2018 at 23:40:16 UTC, Walter Bright wrote:
As:
https://github.com/dlang/dmd/pull/8946
removes the header files for the old C++ code!
This is a significant milestone. Congratulations, Walter!
There are still a few .c files in
On Monday, 29 October 2018 at 03:43:49 UTC, 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:
Congratulations! Iain. It's an extraordinary
On Sunday, 2 September 2018 at 12:08:37 UTC, Martin Nowak wrote:
Seems like they knew most artifacts within the installer by now,
scanning for the submitted binary was a lot faster than last
time.
I guess we should keep an eye on this for the next releases,
could you
take care of this Mike?
On Sunday, 2 September 2018 at 01:05:10 UTC, Martin Nowak wrote:
Glad to announce D 2.082.0.
The Windows installer gave me no warning messages this time.
Thanks, everyone.
Mike
On Friday, 24 August 2018 at 10:09:07 UTC, Uknown wrote:
This is all very nice. I agree that this kind of thing should
be a part of the compiler, but I think it should be a compiler
plugin. If dmd had compiler plugins, I think stuff like this
and `dpp` would be much nicer to use.
I agree.
On Saturday, 18 August 2018 at 08:22:54 UTC, Mike Franklin wrote:
It's a little old, but from what I'm reading we need
"reputation" with Microsoft or an EV certificate, or publish on
the Windows Store.
I'm also reading that once the executable has been downloaded a
number of times from
On Saturday, 18 August 2018 at 08:04:41 UTC, Mike Franklin wrote:
I'll research a little and see if I can find some more
information.
This thread was also quite informative:
https://stackoverflow.com/questions/12311203/how-to-pass-the-smart-screen-on-win8-when-install-a-signed-application
On Saturday, 18 August 2018 at 08:04:41 UTC, Mike Franklin wrote:
I'll research a little and see if I can find some more
information.
Ok, so it is indeed signed: https://imgur.com/a/jGdoXSc
I found this which was disappointing:
On Saturday, 18 August 2018 at 08:04:41 UTC, Mike Franklin wrote:
I get the "Windows Defender SmartScreen prevented an
unrecognized app from starting. Running this app might put
your PC at risk" message. In other words this:
On Saturday, 18 August 2018 at 06:52:21 UTC, Martin Nowak wrote:
On Friday, 17 August 2018 at 22:01:29 UTC, Mike Franklin wrote:
On Friday, 17 August 2018 at 20:01:32 UTC, Martin Nowak wrote:
Windows installer and binaries are now code-signed -
On Friday, 17 August 2018 at 20:01:32 UTC, Martin Nowak wrote:
Glad to announce the first beta for the 2.082.0 release
According to https://issues.dlang.org/show_bug.cgi?id=18786
VirusTotal used to report a virus for the installer. This beta
is now reporting clean:
On Friday, 17 August 2018 at 20:01:32 UTC, Martin Nowak wrote:
Windows installer and binaries are now code-signed -
https://dlang.org/changelog/2.082.0.html#signed_windows_binaries
Was this beta installer supposed to be signed? Because it
doesn't seem to be.
Mike
On Saturday, 4 August 2018 at 09:43:13 UTC, Dukc wrote:
On Saturday, 4 August 2018 at 02:39:23 UTC, Mike Franklin wrote:
Cool! Can we now deprecate and eventually jettison C/C++
bindings from druntime, please?
Why?
The C standard library not a true and intrinsic dependency of D,
and is
On Sunday, 5 August 2018 at 04:47:42 UTC, tanner00 wrote:
Hi, I’m interested in working on this project and just wanted
to touch base. Is there any word on who will be mentoring this
project? I’m entering college this fall but I’ve been
programming since a very young age and enjoy systems
On Saturday, 4 August 2018 at 01:27:49 UTC, Laeeth Isharc wrote:
Thanks to Seb and Atila it is now very easy to show a D
program just #includeing C headers. If just works. Modulo
bugs. In time I am hopeful Atila will start to have more of
C++ headers working too.
On Monday, 23 July 2018 at 10:24:14 UTC, Ecstatic Coder wrote:
But this BetterC minimalistic standard library (allocations,
arrays, strings, slices, maps) is something which can be reused
by many similar hardware-level projects.
This is a project on its own, and as I said, I think it should
On Monday, 23 July 2018 at 09:52:54 UTC, Zheng (Vic) Luo wrote:
Regarding floating point operations, I plan to use
dmd.builtins/ldc.builtins instead of linking with libm.
That reminds me. Something else to consider is that some of
these microcontrollers don't have FPUs. Graphics libraries
On Sunday, 22 July 2018 at 17:12:31 UTC, Ecstatic Coder wrote:
2/ Nuklear (https://github.com/vurtun/nuklear)
Reading the documentation for Nuklear, I found this:
https://rawgit.com/vurtun/nuklear/master/doc/nuklear.html#drawing
To draw all draw commands accumulated over a frame you need
On Monday, 23 July 2018 at 06:24:04 UTC, Zheng (Vic) Luo wrote:
Should we assume a multi-threading model?
I say, no. To get threads on microcontrollers, you typically
first need to implement a Real-time Operating System (RTOS). If
you want to implement an RTOS in D, and then build the
On Monday, 23 July 2018 at 08:08:03 UTC, Mike Franklin wrote:
You can those software building blocks in their own module, and
let the user of the software rasterizer library link it their
own implementation if they wish to deviate from the spirit of
the proposal.
Yikes! too many typos
On Monday, 23 July 2018 at 06:24:04 UTC, Zheng (Vic) Luo wrote:
Moreover, The term "dependency-free" in the project description
often confuses me, because as a hardware-agnostic library the
project does have to depend on external implementations like
"sin"/"memset" or even "thread_start", and
On Monday, 23 July 2018 at 06:00:14 UTC, Zheng (Vic) Luo wrote:
Thank you for the suggestion. Previously I interned at a VR
company and had some experiences writing code related to
graphics, but I don't have any experience on embedded system
programming, so I was wondering that do I need to
On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote:
We're also in search of potential mentors and ideas for student
projects
I posted a number of different ideas for ROSEdu Summer of Code at
https://forum.dlang.org/post/aqlzjjfrwwxswptil...@forum.dlang.org. I believe those ideas
On Sunday, 22 July 2018 at 16:33:10 UTC, Zheng (Vic) Luo wrote:
I'm interested in the "Graphics library for resource
constrained embedded systems" project and have some spare time
this autumn, but I have some questions:
- Does this project aim at creating a hardware-agnostic
rasterizer
On Thursday, 5 July 2018 at 09:40:46 UTC, kinke wrote:
I failed to see a benefit from being able to use classes with
static members only (abuse as namespace?)
Yeah, pretty much, but also static inheritance. You can see the
pattern where I use it at
On Thursday, 5 July 2018 at 10:57:17 UTC, Mike Franklin wrote:
I failed to see a benefit from being able to use classes with
static members only (abuse as namespace?)
Yeah, pretty much, but also static inheritance. You can see
the pattern where I use it at
On Wednesday, 4 July 2018 at 20:38:54 UTC, kinke wrote:
Glad to announce the first beta for LDC 1.11.
Thanks for all the work on this.
I notice the minimal2.d test from the DMD test suite is disabled:
On Monday, 18 June 2018 at 02:31:25 UTC, Mike Franklin wrote:
Unfortunately the code gen is quite a bit worse:
Scratch that. If compiling with -O it seems to do the right
thing.
Mike
On Sunday, 17 June 2018 at 17:00:00 UTC, David Nadlinger wrote:
On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote:
https://github.com/JinShil/memcpyD
[…]
Feedback, advise, and pull requests to improve the
implementation are most welcome.
The memcpyD implementation is buggy;
On Thursday, 14 June 2018 at 20:35:23 UTC, baz wrote:
I asked on IRC yesterday and actually tHose memcpy are not the
memcpy we use to copy wide chunks, apparently it's rather for
an internal druntime thing, i.e cpy type to type so likely
always aligned.
Correct! D already has features like
On Wednesday, 13 June 2018 at 12:45:26 UTC, Fra Mecca wrote:
I get this on Linux 4.16.3-gentoo, AMD FX(tm)-6100 Six-Core
Processor, 8GiB ram,
using ldc2 -O3L:
size memcpyC memcpyD
1 5 0
2 0 0
4 0 0
8 0 0
16 1519 0
32 1833 0
64 3816 0
128 7543 0
256 146500 0
512 194818 0
1024 329593 846142
2048
On Wednesday, 13 June 2018 at 08:55:40 UTC, drug wrote:
Ubuntu 18.04 Linux 4.15.0-23-generic
AMD® Fx(tm)-8350 eight-core processor × 8
size memcpyC memcpyD
1 51089 36921
2 45896 35733
4 46079 36200
8 48443 37509
16 48669 24925
32 52917 27787
64 55631 44928
128 84282 47795
256 107350 66009
512
On Wednesday, 13 June 2018 at 10:13:13 UTC, Dukc wrote:
On Wednesday, 13 June 2018 at 09:59:52 UTC, Mike Franklin wrote:
The benchmark doesn't allocate any data; it's just copying
data.
Mike
Ah of course. I was thinking other stuff while writing.
Well, actually, I probably should divide
On Wednesday, 13 June 2018 at 09:40:05 UTC, Dukc wrote:
If I read your benchmark graphs right, they claimed that
allocating 16 kilobytes takes over 10^^6 usecs, with both
mallocs. Doesn't that mean over a second, 16 kilobytes? Can't
be! Are you confusing usecs with nsecs?
The benchmark
I had a little fun today kicking the crap out of C's memcpy with
a D implementation.
https://github.com/JinShil/memcpyD
Request for help: I don't have a Linux system running on real
hardware at this time, nor do I have a wide range of platforms
and machines to test with. If you'd like to
On Thursday, 24 May 2018 at 01:52:24 UTC, Nick Sabalausky
(Abscissa) wrote:
"C++, now powered by D" :)
:) +1
On Tuesday, 8 May 2018 at 08:53:36 UTC, Vladimir Panteleev wrote:
I heard there was a bit of general interest on the subject, so
would be interesting to hear about more potential use cases.
I've been recently assigned the task of building a web-based
Ladder Logic editor/compiler
On Friday, 20 April 2018 at 10:36:25 UTC, drug wrote:
20.04.2018 13:03, Joakim пишет:
You are aware that gdb has built-in support for demangling D
for 3-4 years now?
But how to enable it? It doesn't work out of box at least for
me.
I believe you enable it with `-demangle=dlang`
The
On Tuesday, 3 April 2018 at 23:50:24 UTC, Arredondo wrote:
I could not get this to work for me in the past (I'm using
Windows 10). I saw this announcement so I decided to try again.
I have a little more experience to share...
std.process.ProcessException@std\process.d(753): Failed to
spawn
On Tuesday, 3 April 2018 at 23:50:24 UTC, Arredondo wrote:
I could not get this to work for me in the past (I'm using
Windows 10). I saw this announcement so I decided to try again.
I'm using it in Windows 10 right now, but I did have trouble
trying to upgrade an existing installation. To
On Friday, 23 February 2018 at 09:18:33 UTC, Jacob Carlborg wrote:
On 2018-02-19 11:49, Martin Nowak wrote:
Glad to announce the first beta for the 2.079.0 release, ♥ to
the 77
contributors for this release.
The following is a regression that breaks DWT:
extern (C) void foo(int) { }
extern
On Tuesday, 20 February 2018 at 08:46:02 UTC, meppl wrote:
@"16.": https://dlang.org/changelog/2.079.0.html#minimal_runtime
So, now someone could "easily" write his own memory managment
for allocations who would be usually done by the default GC -
e.g. classes?
Easily? unlikely, but it's
On Monday, 19 February 2018 at 18:50:47 UTC, Dukc wrote:
Huh? Did I understand right? Just add an empty object.d into
your project and --BetterC is now basically needless, plus the
executable is most likely even smaller?
Kindof, but not exactly. The -betterC switch still adds some
nuance
On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread
today and I thought this is an excellent opportunity to revive
my blog and finally write an article showing why I like D so
much:
On Wednesday, 7 February 2018 at 21:33:22 UTC, Jacob Carlborg
wrote:
This has been long overdue but I would like to announce that
I've just released an official Dub package for the DWT library
http://code.dlang.org/packages/dwt
This is great! Nice work, and thank you!
Mike
On Saturday, 27 January 2018 at 01:31:45 UTC, Seb wrote:
https://github.com/dlang-tour/core/pull/649
It's fixed now. I have also increased the maximal output limit
to 500.000 bytes - I hope that's enough for everyone :O
Seb, you're awesome! Thanks for all these great features.
Mike
On Monday, 8 January 2018 at 22:16:25 UTC, rumbu wrote:
This is my first D finalized project (+16k loc).
I know that there are other two projects intended to provide a
decimal data type for D, but I consider mine the most complete
and most compliant to the standards (at least until now).
On Thursday, 4 January 2018 at 17:40:55 UTC, David Nadlinger
wrote:
it would be fairly easy to manually look up the set of
ModuleInfos in a druntime-less D program.
ModuleInfo is declared and defined in druntime
On Thursday, 14 December 2017 at 06:26:16 UTC, Seb wrote:
It's interesting to see that no one complained about gdc not
being there - I thought that this would be the first comment.
Allow me to be the first.
But seriously, considering the use case for run.dlang.io, I don't
see the need for
On Tuesday, 12 December 2017 at 18:37:38 UTC, Seb wrote:
After it has been in stealth mode for quite a while, I'm happy
to announce that there's https://run.dlang.io
I've actually been using it a lot recently to communicate
bugs/ideas/patterns with others.
Due to the nightlies, I can
93 matches
Mail list logo
