Re: Release D 2.087.0
On Monday, 15 July 2019 at 20:57:59 UTC, Johannes Pfau wrote:
I don't see how "should be made public" can be interpreted as
"should be installed", especially considering that templates
need source code installed (core.internal), but that's
completely orthogonal to what functions should be private
(core.internal) / public to users of druntime.
However, I'll open a PR to clarify that paragraph.
Yes, clarifying that paragraph is a good idea. The intended
meaning used to be unambiguous especially given this part:
"If a public module consists of a header file and an
implementation file (which are both maintained by hand) then it
is OK to import private modules in the implementation file."
This refers to the fact that some modules (object, core.thread)
used to have hand-written .di files to separate the public
interface from the implementations (which made use of rt.*
imports).
Now that those duplicate .di files have (fortunately!) been done
away with, I can see how the wording could be unclear without
that prior knowledge. And in either case, avoiding to use heavily
overloaded terms ("private"/"public") without further explanation
is a good idea.
This split has been in place since back in the D1/Tango days.
Sure, the core vs rt split did. But core.internal did not exist
in D1.
How core is organised internally has little do with whether rt is
public or not.
— David
Re: Release D 2.087.0
On Monday, 15 July 2019 at 20:27:16 UTC, Johannes Pfau wrote: I guess this should be documented somewhere then. See druntime/CONTRIBUTING.md: ``` In general, only modules in the 'core' package should be made public. The single exception is the 'object' module which is not in any package. The convention is to put private modules in the 'rt' or 'gc' packages depending on what they do and only put public modules in 'core'. Also, always avoid importing private modules in public modules. […] ``` This split has been in place since back in the D1/Tango days. — David
Re: Release D 2.087.0
On Monday, 15 July 2019 at 19:41:11 UTC, Johannes Pfau wrote: And duplicating extern(C) declarations, syncing them manually, ... is a safety liability and maintainance nightmare (see my other post). So in no way should we start to add more such functions interfacing rt to core.internal. core.internal.traits.externDFunc takes care of the safety aspect. This is a non-issue. (Interdependencies should be avoided regardless, of course; it is still just a crutch.) — David
Re: Release D 2.087.0
On Monday, 15 July 2019 at 14:00:23 UTC, Mike Franklin wrote: I'm sorry it broke digger, but digger is not how we typically build DMD, druntime, and Phobos. It also breaks the LDC build system. Just shipping rt.* too by itself would be simple, but as the frontend takes various libraries when referring to rt symbols internally (using types that don't match, etc.), compiling code that uses certain parts of rt.* at the same time as rt.* itself leads to non-obvious breakage. The easiest way of making sure this doesn't happen is to just not ship rt.*. Either way, there is a simple resolution here: Put new template code or other artefacts that are actually used via import in core.* (e.g. core.internal.*). This also provides a natural boundary between legacy code and the new runtime interface. If more and more code gets template-ised, rt.* will slowly wither away, but there is nothing wrong with that. At some point, it will just cease to exist naturally. — David
Re: Release D 2.087.0
On Monday, 15 July 2019 at 19:52:57 UTC, David Nadlinger wrote: On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote: My understanding is the `rt` is the language implementation and `core` is the low level library for users. This understanding would be mistaken. We haven't been shipping `rt` on the import path for a long time. `core.internal` exists precisely to fill this role, i.e. code that needs to be around at druntime import time, but isn't supposed to be accessed directly by users. (Corollary: This should be fixed in a point release to unbreak various tooling and dependent build systems.)
Re: Release D 2.087.0
On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote: My understanding is the `rt` is the language implementation and `core` is the low level library for users. This understanding would be mistaken. We haven't been shipping `rt` on the import path for a long time. `core.internal` exists precisely to fill this role, i.e. code that needs to be around at druntime import time, but isn't supposed to be accessed directly by users. — David
Re: Encouraging preliminary results implementing memcpy in D
On Sunday, 17 June 2018 at 17:00:00 UTC, David Nadlinger wrote: core.simd.loadUnaligned instead Ah, well… https://issues.dlang.org/show_bug.cgi?id=19001 — David
Re: Encouraging preliminary results implementing memcpy in D
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; it assumes that all
arguments are aligned to their size. This isn't necessarily true.
For example, `ubyte[1024].alignof == 1`, and struct alignment can
also be set explicitly using align(N).
On x86, you can get away with this in a lot of cases even though
it's undefined behaviour [1], but this is not necessarily the
case for SSE/AVX instructions. In fact, that's probably a pretty
good guess as to where those weird crashes you mentioned come
from.
On other architectures, unaligned accesses might be outright
unsupported.
For loading into vector registers, you can use
core.simd.loadUnaligned instead (ldc.simd.loadUnaligned for LDC –
LDC's druntime has not been updated yet after {load,
store}Unaligned were added upstream as well).
— David
[1] This is applying C rules to D, where creation of unaligned
pointers is undefined behaviour. The D specification doesn't
mention
Re: LDC 1.10.0 beta
On Monday, 14 May 2018 at 18:31:13 UTC, Jacob Carlborg wrote: Out of curiosity, how come the Objective-C integration seem to always lack behind when LDC merges a new DMD release with some new Objective-C integration? Is it less prioritized, not so much knowledge in this area, something else? Basically all of the latter – many of us LDC devs are not really interested in the Objective-C integration for our own/company use, and kinke (who has been doing virtually all of the frontend merging work lately) IIRC doesn't have access to an OS X box. Not breaking existing features without direct access to a target is one thing, but implementing new features off the CI only is another. Help would be very welcome, though. — David
Re: DConf 2018 Livestream
On Thursday, 10 May 2018 at 09:11:20 UTC, Walter Bright wrote: This isn't the only time videos of my talks (and others) have been lost due to technical problems or simple screwups. I'm tired of this happening. One hopes that the contract with the respective company providing A/V services would include penalties for that case (which could be funnelled into the foundation funds). — David
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 20:32:05 UTC, Seb wrote: On Tuesday, 10 April 2018 at 16:51:57 UTC, Atila Neves wrote: If you get to the point where you can #include , it will be doubly impressive! Not *if*, *when*. ;) Atila FYI people have been fighting with this for a long time: https://github.com/dlang/druntime/pull/1316 FYI this appears to work just fine in Calypso: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/libstdc%2B%2B/vector.d — David
Re: Vision document for H1 2018
On Thursday, 15 March 2018 at 10:48:45 UTC, Radu wrote: You have to remember that the really big first client of betterC(++) was DMD, porting DMD from C++ was a big undertaking. Right now both DMD and LDC use a form of betterC, so it is critical to have it finalized. This is entirely wrong. DMD and LDC rely extern(C++), but this has nothing to do with -betterC whatsoever. Both compilers link and initialise the runtime as normal (and then disable the GC at runtime). — David
Re: Release D 2.078.0
On Thursday, 4 January 2018 at 13:03:21 UTC, Mike Parker wrote:
https://dlang.org/blog/2018/01/04/dmd-2-078-0-has-been-released/
In normal D code, struct destructors are executed when an
instance goes out of scope. This is handled by DRuntime, […]
This is slightly inaccurate. Regular stack cleanup doesn't
involve the runtime at all; druntime only comes into play for
exception handling. Since destructors also need to be run when
the scope is left by an exception, they are implemented via `try
{} finally {}` internally. The EH part of these depends on
druntime, but not the regular path.
One of the seemingly obscure features dependent upon DRuntime
is the ModuleInfo type. It’s a type that works quietly behind
the scenes as one of the enabling mechanisms of reflection and
most D programmers will likely never hear of it.
This is somewhat confusingly worded as well. It's actually mostly
the other way around – druntime depends on ModuleInfo to be
emitted, crucially for static constructor, destructors and unit
tests to be run. At least without shared libraries in the
picture, it would be fairly easy to manually look up the set of
ModuleInfos in a druntime-less D program.
— David
Re: Blog post: using dynamic libraries in dub
On Thursday, 21 December 2017 at 12:43:51 UTC, Jacob Carlborg wrote: On 2017-12-20 11:31, Benjamin Thaut wrote: Would this work in all cases? Do tls variables work across Linux shared libraries? As far as I know it works on Linux and FreeBSD, but it doesn't work on macOS. I don't know about windows. Just to clarify, that's true for for DMD only – TLS should work just fine on macOS with LDC. Do we expect all dub libraries to have correct export annotations once export goes live? No. There would probably have to be some sort of compatibility flag to avoid breaking all libraries on systems where symbols are visible externally by default (Linux, ...). — David
Re: run.dlang.io - a modern way to run D code
On Wednesday, 13 December 2017 at 01:14:26 UTC, Seb wrote: Also the storage on the machine is limited and we can't drop an unlimited amount of Docker images there. Shouldn't the overhead from that be fairly manageable? After all, the last layer would only be as large as a single DMD/LDC installation. Surely you would have at least a few gigabytes spare on the server? — David
Re: LDC 1.6.0-beta1
On Saturday, 2 December 2017 at 15:47:23 UTC, Jacob Carlborg wrote: On 2017-12-02 13:41, kinke wrote: Nope, unfortunately still waiting for one of my compadres to create and upload the OSX package. Have you thought of automatically build and upload packages using Travis CI? That would be a good idea. Also, I uploaded the OS X package just now. (Didn't realise it wasn't built yet…). —David
Re: LDC 1.5.0
On Friday, 3 November 2017 at 23:50:33 UTC, Nicholas Wilson wrote: Does `-link-internally` mean that you don't require command line tool/dev installation for OS X and Windows? That would be awesome for getting workshops for non-programmers (the biologists at my Uni) to work. You still need the system libraries to link against, unfortunately. — David
Re: Libdivide ported to D
On Sunday, 14 May 2017 at 15:30:19 UTC, Walter Bright wrote: On 5/14/2017 3:39 AM, Tomer Filiba wrote: Of course it only applies to runtime division -- the compiler can do the same if the divisor is known in compile time. I hate to say this, but modern compilers already do this for generated runtime code when dividing by a constant. […] As Tomer points out, a runtime implementation can still be useful if the divisor is only known dynamically (but constant across number of operations). — David
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Saturday, 22 April 2017 at 10:12:04 UTC, Arek wrote: And no output for ARM64. :/ LDC has beta-quality support for AArch64. --David
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 09:30:28 UTC, Jacob Carlborg wrote: And no official support on macOS. LDC officially supports shared libraries on macOS. -David
Re: dmd Backend converted to Boost License
On Friday, 7 April 2017 at 22:57:39 UTC, Walter Bright wrote:
Thanks for pointing that out, I didn't know that. I just
assumed LDC would have gone with a clang-style inline assembler
(does clang even have inline asm?).
LDC supports both DMD-style asm {} blocks as well as LLVM's
native inline assembly format, which is very similar to GCC's,
with explicit clobber specifications and explicit parameter
passing (https://wiki.dlang.org/LDC_inline_assembly_expressions).
The latter is useful on non-x86 platforms as well as to allow
more optimizations of functions using inline asm such as inlining
(although inlining in particular can also be enabled for
DMD-style asm blocks using a pragma).
There are also inline IR expressions for the few situations where
you don't want to drop down all the way to inline assembly but
still need to crack open the hood and control the emitted LLVM
IR: https://wiki.dlang.org/LDC_inline_IR. For example, we use it
to implement some target-independent SIMD intrinsics in the
library.
— David
Re: dmd Backend converted to Boost License
On Friday, 7 April 2017 at 21:49:22 UTC, Walter Bright wrote: Note that this also resolves the long-standing legal issue with D's inline assembler being backend licensed, and so not portable to gdc/ldc. Just to clarify for people not usually frequenting these circles: LDC does support DMD-style inline assembly, but we use a different implementation. — David
Re: Need help
On Wednesday, 15 March 2017 at 09:19:17 UTC, Jack Applegame wrote: I think that fixing such bugs is quite general interest. I'm not asking to do enhancement required solely to me. I'm asking to fix a bug, very bad bug. The reason why your post is not appropriate here is in the name of the forum: "announce". Many D users follow this list – and in part indeed via email – to keep up with interesting news, developments, and events in the wider community. If the volume becomes too high, the forum loses its reason to exist, and we could just merge it into the general forum entirely. If you are having trouble figuring out what to post here, a great way to start is to ask yourself: "What would happen if every D user posted here?" What would happen if every D user posted about the initial release of their smaller project/a fresh release of their well-known project here? Great, that will keep people up to speed with what's happening in the community. What would happen if everybody posted about bugs they find and want fixed here? Not so much. There are many more severe issues discovered frequently, yet you don't read about them here – because the bug tracker is the place to report them. Of course, in this case, you might want to inform compiler developers that you can offer a bounty for timely fixes. But the appropriate place to do so is the DMD development list, or maybe – if you think that the wider D audience might be able to help – the general dm.D forum. It goes without saying that respecting the rules and workings of a community you want help from will drastically increase the chances of actually receiving it. — David
Re: Need help
On Wednesday, 15 March 2017 at 07:37:53 UTC, Jack Applegame wrote: Dear developers. I need help fixing issue #17257 (https://issues.dlang.org/show_bug.cgi?id=17257) and related bug (https://forum.dlang.org/post/zpxzbctiijfhjujsz...@forum.dlang.org). This is a forum for announcements of general interest. Please take that into consideration before posting here. Thanks. — David
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On Monday, 27 February 2017 at 17:13:24 UTC, Seb wrote: A solution for the moment is to point people at the ddoc version, e.g. https://dlang.org/phobos/std_algorithm_comparison.html#.among Sure, linking only that would definitely work. — David
Re: New (page-per-artifact) standard library doc examples are now editable and runnable
On Monday, 27 February 2017 at 15:41:18 UTC, Seb wrote: Is it redditable? Yes, finally :) Can we fix the fact that the docs are duplicated for template functions before any big announcements? See e.g. https://dlang.org/library-prerelease/std/algorithm/comparison/among.html from above. This leaves quite the bad impression, as it makes the page look like an unstructured mess at first glance. - David
Re: Updated LDC snap package with link-time optimization (LTO) support
On Thursday, 9 February 2017 at 17:16:35 UTC, Joseph Rushton Wakeling wrote: This package should be possible to install on Ubuntu 16.04 or later, or Ubuntu 14.04, as well as any other distro making available a recent version of snapd (2.21 or later): https://snapcraft.io/docs/core/install Hmm, for whatever reason, Arch still ships 2.16 by default… Seems to work fine on Ubuntu 16.10, though. — David
LDC 1.1.0 released
Hi all, Version 1.1.0 of LDC, the LLVM-based D compiler, has finally been released: https://github.com/ldc-developers/ldc/releases/tag/v1.1.0 Please head over to the digitalmars.D.ldc forums for more details and discussions: http://forum.dlang.org/post/etynfqwjosdvuuukl...@forum.dlang.org — David
Re: LDC talk @ FOSDEM'17
On Monday, 23 January 2017 at 19:56:33 UTC, Johan Engelen wrote: Great! :-) Keep me in the loop when preparing your slides! ;-) Glad to help out in any way as well. I might also make it to FOSDEM myself this year, but that's not quite sure yet. — David
Re: [GSoC] Precise GC
On Saturday, 3 September 2016 at 12:22:25 UTC, thedeemon wrote: On Friday, 2 September 2016 at 14:55:26 UTC, jmh530 wrote: Anyway, with @safe unions, my thinking is that it would mean that the garbage collector can be made precise in @safe code in a way that it can't in @system code (assuming unions with pointers aren't snuck in through @trusted). GC (and runtime in general) has no idea what code is safe and what code is system. GC works with data at run-time. All @safe-related stuff is about code (not data!) and happens at compile-time. They are completely orthogonal and independent, as I understand. This is correct, but when designing a GC – in particular, a precise GC –, having the compiler emit additional helpful metadata to binaries is always an option worth considering. — David
Re: Beta D 2.071.2-b3
On Saturday, 3 September 2016 at 14:40:37 UTC, Martin Nowak wrote: Yes, it does help. As private prevents usage outside of a module it allows to do some optimizations that required whole program analysis otherwise, e.g. variables and functions can get internal linkage, thus reducing loads/stores and indirect calls. This doesn't really work that easily due to templates that depend on private data, and private data being referenced from alias parameters. Of course, all such cases can still be statically detected when compiling the module in question, but this is quite a bit less trivial than just looking at the protection level. — David
Re: Beta D 2.071.2-b3
On Friday, 2 September 2016 at 08:57:14 UTC, Basile B. wrote: On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote: std.traits wrappers should use __traits to build *safe* things (declaring that @trusted in the end). This has nothing to do with memory safety. Actually it does, albeit somewhat tangentially: Accessing private members from the outside must be @system since the @trusted implementation of a class might rely on nobody meddling with the private state. — David
Re: Battle-plan for CTFE
On Thursday, 1 September 2016 at 21:48:41 UTC, Rory McGuire wrote:
I was hoping that the error was coming from the CTFE engine as
it ran the code, but it comes up before ctfe execution I guess.
As a general comment, there is no such thing as a CTFE phase. It
is performed in-line with other semantic analysis as required.
__traits(compiles, _some_function_that_calls_), thinks that the
invalid code compiles even when it doesn't compile […]
No, you are missing the point. This:
---
void foo() {
@#$!
}
---
will always cause a compiler error, regardless of whether there
is a `__traits(compiles, foo())` somewhere else in the module.
__traits(compiles, …) only applies to its argument and doesn't
magically cause errors in code somewhere else to be ignored.
— David
Re: Battle-plan for CTFE
On Thursday, 1 September 2016 at 21:01:46 UTC, Rory McGuire wrote: I'm actually asking why we can't catch the ctfe error. You can, by using __traits(compiles, …). Surely the ctfe engine could be changed to catch unsupported code errors. (Not invalid, just unsupported at CT). It already does, see above. How is this related to try/catch? — David
Re: Battle-plan for CTFE
On Thursday, 1 September 2016 at 19:38:13 UTC, Stefan Koch wrote: I have something that will help with that a little bit. https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln when you apply this patch __ctfeWriteln() will output every compiletime avilable string to the console. More crucially, it also allows you to print runtime values during CTFE. pragma(msg, …) suffices to print compile-time constants. Very few people seem to have the correct mental model for the the interaction between compile-time features and CTFE, hence I think using precise terminology is an important first step. See also: https://github.com/dlang/dmd/pull/692 – it's about time we finally got __ctfeWrite() merged. — David
Re: Battle-plan for CTFE
On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote:
So why can't we even catch the Error during CTFE, that would at
least help somewhat.
You are mixing up runtime exceptions ("throw …") with compiler
errors (missing a semicolon). dm.D.learn should be able to help
clear that up.
— David
Re: Battle-plan for CTFE
On Thursday, 1 September 2016 at 16:43:53 UTC, Rory McGuire wrote: is that in one of the "semantic" passes the compiler has? For reference, I've laid out the reasons why this proposal couldn't work to Stefan here: https://github.com/dlang/dmd/pull/6098#issuecomment-243375543 The real reason is not so much in the pass structure of the compiler as in the fact that CTFE by definition executes the same function body that is also emitted to the runtime binary. — David
Re: Terminix Stable 1.2.0 Released
On Saturday, 23 July 2016 at 14:24:08 UTC, Matthias Klumpp wrote: 4) Resolving weird LDC bugs like this one: https://github.com/ldc-developers/ldc/issues/1618 - might actually be an LLVM issue, but I don't know enough to pin down the issue. Turns out that this is not actually a LDC/LLVM bug, but an artefact of Ubuntu 16.10 patching GCC to generate position-independent executables by default. Is DMD also affected by this? Does anybody know how other languages are dealing with the change? — David
Re: 4x faster strlen with 4 char sentinel
Hi Jay,
On Sunday, 26 June 2016 at 16:40:08 UTC, Jay Norwood wrote:
After watching Andre's sentinel thing, I'm playing with strlen
on char strings with 4 terminating 0s instead of a single one.
Seems to work and is 4x faster compared to the runtime version.
Please keep general discussions like this off the announce list,
which would e.g. be suitable for announcing a fleshed out
collection of high-performance string handling routines.
nothrow pure size_t strlen2(const(char)* c) {
if (c is null)
return 0;
size_t l=0;
while (*c){ c+=4; l+=4;}
while (*c==0){ c--; l--;}
return l+1;
}
A couple of quick hints:
- This is not a correct implementation of strlen, as it already
assumes that the array is terminated by four zero bytes. That
iterating memory with a stride of 4 instead of 1 will be faster
is a self-evident truth.
- You should be benchmarking against a "proper" SIMD-optimised
strlen implementation.
— David
Re: Iup and nukclear interface in D.
On Thursday, 23 June 2016 at 08:14:42 UTC, Mike Parker wrote: * extern(C) functions should, at a minimum, be declared as @nogc and nothrow for client code using those attributes. Be careful, though, if the C library supports user-specified callbacks to be set for some functionality – unless you also require those to be @nogc, that guarantee could easily be violated. — David
Re: amoeba, a chess engine written in D
On Sunday, 22 May 2016 at 21:22:30 UTC, Richard Delorme wrote: A question: why singleobj is not activated by a -Ox options? It changes compiler behaviour – only a single object file is produced. Historically, the default behaviour was used by some people/build systems for incremental compilation. However, since incremental compilation only works when exactly the same (sub)sets of commands are invoked every time these days, -singleobj should arguably be on by default, at least when producing an executable. This is actually what ldmd2 does already, but we should probably take the plunge and break backwards compatibility to enable it for the main driver too. I can't think of a scenario where you wouldn't want to be using it. — David
Re: My ACCU 2016 keynote video available online
On Thursday, 19 May 2016 at 12:54:48 UTC, Jens Müller wrote: But ldc looks so bad. Any comments from ldc users or developers? Because I see this in many other measurements as well. This definitely does not match up with my experience. Particularly if you see this in many measurements, there might be something iffy with the way you test. Could you please post a runnable snippet that demonstrates the issue? In general, could you please directly post any performance issues to the LDC issue tracker on GitHub? We are quite interested in them, but I only happened to come across this post by chance. — David
Re: amoeba, a chess engine written in D
On Friday, 20 May 2016 at 23:16:01 UTC, Richard Delorme wrote: The source can be compiled with dmd, ldc or gdc, but the best performance are obtained with the latter (almost twice faster). Allowing LDC to do cross-module optimisations (by adding the -singleobj flag) and make use of popcnt increased the performance by 47% for one specific benchmark, which should bring it into the same ballpark as GDC. See https://github.com/abulmo/amoeba/pull/2 for more details. PGO might still give the latter a bit of an edge, though, as LDC's implementation is still experimental and there is a lot of unused potential for making use of the profile data in LLVM's optimiser. — David
Re: Battle-plan for CTFE
Hi Stefan, On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: My Plan is as follows. I think you guys talked about it at the conference, but be sure to coordinate with Timon Gehr. You'll want to steal all the best ideas from the various implementations anyway. ;) Do Dataflow analysis on the code that is to be ctfe'd so we can tell beforehand if we need to store state in the ctfe stack or not. Or baring proper data-flow analysis: RefCouting the variables on the ctfe-stack could also be a solution. I presume by "store state" you mean persisting objects beyond the bounds of a single CTFE invocation? My first inclination here would simply be to make all allocations from a new arena each time CTFE is entered (can also re-use memory from prior runs for that), do a deep-copy of the result (converting it to full AST nodes, etc.), and then drop the entire arena. But probably you have thought of (and discarded) this already. — David
Re: DlangUI on Android
On Friday, 22 April 2016 at 18:48:26 UTC, David Nadlinger wrote: This is a reality now mostly due to Joakim's great LDC work. (the fact that we can deploy stuff to Android in the first place, that is – obviously, the UI layer is a whole separate story)
Re: DlangUI on Android
On Thursday, 21 April 2016 at 14:48:40 UTC, ANtlord wrote: Am I sleeping? Can we develop UI applications for Android on D? It's great! Yes – cool, right? This is a reality now mostly due to Joakim's great LDC work. — David
Re: Qt's MOC getting replicated in D for Calypso
On Thursday, 18 February 2016 at 23:48:44 UTC, Elie Morisse wrote: Calypso classes deriving from DMD ones will have to be converted to D […] This is not necessarily true. You should be able to inherit from an extern(C++) class just fine on the C++ side. Of course, Walter is busy converting various internals to D, but it should be possible to keep the parts you need accessible from C++. Please make sure let us know if we can do anything on the LDC side to make the transition easier. — David
Re: DigitalWhip
On Sunday, 14 February 2016 at 17:31:37 UTC, artemalive wrote: From ldc output: "-release - Disables asserts, invariants, contracts and boundscheck". We (LDC team) should clarify this description. In D2, -release does not disable bounds-checking for @safe code anymore. -singleobj really does the magic. I'll commit only this option. Thanks for the suggestion and for the pull request. It's my first pull request;) I'm not convinced that it makes for a good comparison to use different optimization settings for one of the compilers… — David
Re: DigitalWhip
Hi Artem, On Saturday, 13 February 2016 at 18:48:12 UTC, artemalive wrote: https://github.com/artemalive/DigitalWhip Your scripts had bounds checking enabled for LDC but not the other two D compilers. I posted a pull request with the fix. LDC isn't unreasonably slow any longer on a random EC2 box I used for a quick test: --- Compiler relative times: clang 1.00 gcc 1.02 ldc 1.07 dmd 2.07 --- — David
Re: Vision for the first semester of 2016
On Monday, 1 February 2016 at 11:42:54 UTC, Daniel Murphy wrote: The process will be complete when you've backported the entirety of 2.068. From what I recall, 2.068 was fairly painless to merge anyway compared to other releases. — David
Re: LDC 0.17.0-beta1 has been released!
On Thursday, 14 January 2016 at 20:57:02 UTC, Kai Nacke wrote: No. Since 0.16.0 we regard the Win64 support as production-ready. The only thing we are missing is a fancy one-click installer, pretty much. Even though you can just extract the binary release archives and use LDC as-is (it should auto-detect MSVC), many Windows programmers seem to like installers. — Davidw
Re: Three Cool Things about D
On Tuesday, 22 December 2015 at 19:07:55 UTC, Steven Schveighoffer wrote: Am I missing some new feature here? What does the 'this' mean? I have no idea, this must have been some sort of weird copy/paste or auto-correct mistake on my side. It's supposed to be "uint", as in Andrei's talk. — David
Re: Three Cool Things about D
On Wednesday, 23 December 2015 at 01:07:57 UTC, Walter Bright wrote: On 12/22/2015 10:29 AM, David Nadlinger wrote: Not sure about how it arrives at the crazily unrolled loop, but no recursion in sight anymore. It's doing tail recursion optimization, which turns the recursion into a loop. The recursive call is not quite a tail call by itself, which is what Andrei pointed out using that example. But yes, that's what happens. Then the loop is unrolled 8 times. Sure thing. I was rather surprised to see that happen given that I only compiled with -O1, though, as it seems to be quite an aggressive optimization. — David
Re: Three Cool Things about D
On Monday, 21 December 2015 at 17:28:51 UTC, Andrei Alexandrescu
wrote:
https://www.reddit.com/r/programming/comments/3xq2ul/codedive_2015_talk_three_cool_things_about_d/
By the way, even though I wholeheartedly share your sentiment
regarding those "functional" examples, I found it to be an
interesting example for the power of modern optimizers that LDC
manages to compile this
---
ulong factorial(this n) {
return n <= 1 ? 1 : n * factorial(n - 1);
}
---
to this:
---
__D4test9factorialFkZm:
mov eax, 1
cmp edi, 2
jb LBB0_7
mov ecx, edi
lea edx, [rdi + 7]
add edi, -2
mov eax, 1
testdl, 7
je LBB0_4
and edx, 7
neg edx
mov eax, 1
.align 4, 0x90
LBB0_3:
imulrax, rcx
dec rcx
inc edx
jne LBB0_3
LBB0_4:
cmp edi, 7
jb LBB0_7
add rcx, -3
.align 4, 0x90
LBB0_6:
lea rdx, [rcx + 3]
imulrdx, rax
lea rax, [rcx + 2]
lea rsi, [rcx + 1]
imulrax, rsi
imulrax, rdx
lea rdx, [rcx - 1]
imulrdx, rcx
lea rsi, [rcx - 2]
imulrsi, rdx
imulrsi, rax
lea rax, [rcx - 3]
lea rdx, [rcx - 4]
imulrax, rdx
imulrax, rsi
add rcx, -8
lea edx, [rcx + 3]
cmp edx, 1
ja LBB0_6
LBB0_7:
ret
---
Not sure about how it arrives at the crazily unrolled loop, but
no recursion in sight anymore.
— David
Re: IAP Tools for D
On Sunday, 20 December 2015 at 01:16:46 UTC, Jakob Jenkov wrote: According to Thrift's own docs their binary encoding is not compact. For compact encoding it seems they refer to Protobuf. There seems to be a confusion of terminology here. Thrift has a "Binary" protocol, which is not compact in the sense that it consists of the data fields more or less blitted into a message. There is also a "Compact" protocol, which is also a binary format, but employs things like variable-length integers to reduce size – similar to Protobuf. — David
Re: Testing Nightly Build Service
On Sunday, 13 December 2015 at 11:57:18 UTC, Iain Buclaw wrote: On 12 December 2015 at 16:48, Johan Engelen via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: Are there plans for adding nightlies for GDC and LDC? More like fortnightlies. :-) I don't know what the situation is in your camp, but as far as LDC is concerned, there is much more development activity than once every two weeks. ;) We currently have AppVeyor set up to push successful Windows builds to GitHub, and should probably do something similar for the Linux/OS X builds on Travis. For the latter, we'd need to set up a custom script if we wanted to push to a perpetually unfinished GitHub release as well, but we could also go for Bintray, S3, or wherever Martin will end up hosting the DMD files. — David
Re: https everywhere update - dlang.org gets an "A" now!
On Wednesday, 2 December 2015 at 22:17:20 UTC, Walter Bright wrote: https://www.ssllabs.com/ssltest/analyze.html?d=dlang.org=on Dlang.org gets an "A" now! Thanks to Jan Knepper's efforts. Thanks! Also displays as https in Chrome now. — David
Re: https everywhere update - dlang.org gets an "A" now!
On Friday, 4 December 2015 at 02:29:52 UTC, Brad Roberts wrote: I'm glad that letsencrypt is out there doing the publicity, but getting and using ssl certs has been free via startssl for several years now. What this new group is doing is the PR and marketing to get people to do it, of course under their own umbrella rather than another company's. The free StartSSL thing was also nigh-unusable – when I gave it a try, their in-browser CSR gen thing broke on whatever recent version of Firefox I was using, which left me with no cert, but them claiming I had exhausted their offer. They also have this weird thing where they offer "one host name plus domain" only, and charge users for revoking their cert (!). — David
Re: https everywhere!
On Monday, 23 November 2015 at 20:55:32 UTC, Walter Bright wrote: I'm pleased to announce that Jan Knepper has gotten us some proper certificates now, and dlang.org and digitalmars.com are now fully https! There are a number of issues with how SSL is set up on the server, from misconfiguration and/or outdated software: https://www.ssllabs.com/ssltest/analyze.html?d=dlang.org=on Compare this e.g. to issues.dlang.org, which achieves a solid A grade (although it uses a SHA-1 intermediary certificate, which will lead to issues soon): https://www.ssllabs.com/ssltest/analyze.html?d=issues.dlang.org=on — David
Re: https everywhere!
On Tuesday, 24 November 2015 at 19:13:22 UTC, duff wrote: You're part of the bikscheder team. What is this even supposed to mean? — David
Re: Beta D 2.069.0-b1
On Thursday, 8 October 2015 at 15:01:31 UTC, Martin Nowak wrote: On Thursday, 8 October 2015 at 12:20:23 UTC, Andrea Fontana wrote: Are dmd 2.069b1 binaries compiled with dmd 2.069b1 or with dmd 2.068.2? The last released compiler, we don't have any bootstrap method (using a small C++ compiler or so). One does not exclude the other. You could still re-build 2.069b1 using itself. — David
Re: D-Day for DMD is today!
On Friday, 28 August 2015 at 07:47:13 UTC, Johannes Pfau wrote: Current GDC master can compile DDMD, although it uses the 2.066.1 frontend. Iain backported the relevant C++ mangle changes: https://github.com/D-Programming-Language/dmd/pull/4957 The first LDC 2.067.1 beta is imminent. — David
Re: mood : simple vibe.d based blog implementation
On Friday, 14 August 2015 at 18:51:33 UTC, Dicebot wrote: - HTTPS-only By the way, Firefox on Mac does not recognize your TLS certificate as valid. – David
Re: D Language Runtime (klickverbot) - DConf 2015
On Wednesday, 24 June 2015 at 20:14:02 UTC, Walter Bright wrote: https://www.reddit.com/r/programming/comments/3axgwn/d_language_runtime_klickverbot_dconf_2015/ David, could you please post an AMA there? Done. I didn't even see your prompt before I did so. ;) - David
Re: D Language Runtime (klickverbot) - DConf 2015
On Wednesday, 24 June 2015 at 20:43:07 UTC, rsw0x wrote: He briefly mentions rtinfo then says it's not part of the talk, is RTinfo actually used for anything? AFAICT it's just a dummy value at the moment. Yes, it is just a dummy value in the upstream druntime repo, but people have been changing it in their local copies for precise GC, some forms of runtime reflection, or more crazy ideas (see Adam's work). - David
Re: Monday is last day for DConf 2015 registrations
On Friday, 22 May 2015 at 13:12:35 UTC, Daniel Murphy wrote: Steven Schveighoffer wrote in message news:mjkncd$21e7$1...@digitalmars.com... BTW, I will stress again that I'm going to be at the hotel all day Tuesday (and without a car) if anyone is interested in hanging out :) I'll be there from Saturday night. I am going to arrive Monday afternoon, probably with a car. — David
Re: Monday is last day for DConf 2015 registrations
On Monday, 18 May 2015 at 15:50:01 UTC, Joakim wrote: For those of us not going, any update on the live streaming setup? That was a great way for those not there to take part last time, even posing after-talk questions and conversing with those there over irc. :) I don't want to sell the conference team short, but having worked in professional A/V for business events, I wouldn't start organizing a livestream viewing party just yet. Producing a broadcast-quality, stable real-time video stream is no piece of cake, especially when you are doing it for the first time. Then again, setting up a laptop to push a crappy webcam stream to Twitch or YouTube Live should be easy enough, at least if the university LAN is well-designed enough to provide a half-decent uplink. — David
Re: [hackathon] ARE WE SLIM YET?
On Sunday, 3 May 2015 at 13:04:41 UTC, Vladimir Panteleev wrote: It measures stats about D built from D's entire GitHub history, as well as those of programs built with said D versions. Currently only two programs are tested (empty program and hello world), so please send PRs for meaningful benchmarks. Adding new programs is very easy: http://j.mp/1I7ELEc. You can find a few self-contained benchmarks at https://github.com/D-Programming-Dash. This is the compiler performance CI project I started a while ago, but unfortunately couldn't quite finish yet due to life/academia getting in the way. My focus for this project was a bit different, though. I primarily collected real-world test cases instead of trying to focus on the most meaningful ones, and there is quite a number of them. The history tracking display mode is not written yet, and the UI lacks a lot of tooltips, etc. (In case anybody is curious what the current state looks like: http://dash.klickverbot.at/dash1/compare/gdc_main:release_boundschecked@current..ldc_master:release_boundschecked@current. It seems that the system hit a GitHub API rate limit from which it failed to recover some time in January, though, so there are no recent results. Also, the server currently runs in debug mode and I didn't put any effort into front-end optimizations yet, so expect it to be slow.) — David
Re: This Week in D, issue 1
On Tuesday, 13 January 2015 at 14:08:58 UTC, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jan-12.html Great idea, hope the project will take off! One thing: I found the link coloring to be _very_ counter-intuitive. So much so that I in fact had to fire up the dev tools to figure out why some of the links were blue and some of them green. Since the default link color on pretty much all platforms is blue, green inevitably breaks with the user expectation that visited links are styled in some shade similar to the main link color. Overriding just the :visited color is questionable anyway. David
Re: This Week in D, issue 1
On Tuesday, 13 January 2015 at 23:20:49 UTC, MattCoder wrote:
Perhaps I misunderstood you. But here all links on that page
are blue, even the visited ones. I didn't see any green link
there, the only green text that I can see there, are the
comments in the code examples.
http://arsdnet.net/this-week-in-d/twid.css
has
---
a:visited {
color: green;
}
---
No idea why it's not rendering for you.
David
Re: LDC 0.15.0 alpha1 released! Please help test!
On Saturday, 25 October 2014 at 09:38:45 UTC, E.S. Quinn wrote: I notice that there's no mingw based windows version with his release. That's just an issue with building the packages for the alpha, the release will have a MinGW version. David
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 9 October 2014 at 18:33:25 UTC, Rainer Schuetze wrote: This is a gcc extension, which isn't supported under Windows by dmd. Can you add this attribute in GDC/LDC as part of a D file aswell? http://wiki.dlang.org/LDC-specific_language_changes#LDC_global_crt_ctor_and_LDC_global_crt_dtor David
Re: D2 port of Sociomantic CDGC available for early experiments
On Wednesday, 8 October 2014 at 17:39:46 UTC, Walter Bright wrote: Being on the front lines of tech support for 30 years, it is not an unjustified fear nor a hypothetical problem. What you could do is propose a secret switch to all dmd generated programs that the druntime switch checks before main() gets control, such as: app --druntimeSet=usexxx ...the regular app args ... I don't think this would work (without introducing extra hacks) when druntime is used as a shared library. Plus, when writing plugins in D, there might not even be a host D application to handle the command line flags. I'm not saying that command line arguments can't be made to work in these cases too, just that doing it will likely introduce quite a bit of extra complexity. David
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Friday, 3 October 2014 at 07:16:14 UTC, Kagamin wrote: On Thursday, 2 October 2014 at 12:44:08 UTC, eles wrote: I doubt. At least, not easily. However, installing LMDE should be a one-time process (it's a rolling distribution). Do rolling distributions guarantee to not overwrite fstab? How mint package update differs from a rolling distro package update? Arch Linux warns you about the conflict and installs the new files as e.g. /etc/fstab.pacnew. David
Re: New Beta: 2.066.1-rc1 is Now Available
On Thursday, 11 September 2014 at 16:51:34 UTC, Andrew Edwards wrote: DMD 2.066.1-rc1 is now available for testing. I found a new 2.066 regression: https://issues.dlang.org/show_bug.cgi?id=13478 It also exists in 2.066.0, but hopefully we can fix it before 2.066.1, as it currently blocks the merge of 2.066 to the master branch of LDC. David
Re: New Beta: 2.066.1-rc1 is Now Available
On Friday, 12 September 2014 at 02:35:44 UTC, Andrew Edwards wrote: On 9/12/14, 3:28 AM, Marco Leise wrote: P.S. Is this supposed to contain all 2.066 regression fixes pulled into master up to this point? As far as I can tell at least https://github.com/D-Programming-Language/dmd/pull/3961 from 4 days ago didn't get cherry picked yet. Or are these RCs more of a preliminary version? It just happens that that one wasn't approved prior to Kenji pushing in picking regressions that same day. That's the only one I can see missing. But that's why it's called an RC... Inevitably, we overlook something. This gives us time to identify and correct those oversights. Thank you for identifying it. Cherry-pick for the release branch: https://github.com/D-Programming-Language/dmd/pull/3985 Please pull before rc2. Cheers, David
Re: Voting: std.logger
On Sunday, 17 August 2014 at 02:55:52 UTC, Dicebot wrote: Results: http://wiki.dlang.org/Review/std.logger#Voting_for_std.experimental Seems like my vote (http://forum.dlang.org/post/anzeespykooeiaqis...@forum.dlang.org) went missing – not that it would change anything, of course (later in the thread, I pointed out some other (since fixed) issues, which was the more important part). I probably should've included 1) and 2) as separate bullet points to make counting easier. Cheers, David
Re: DConf 2014: SDC, a D Compiler as a Library
On Friday, 25 July 2014 at 15:44:32 UTC, Andrei Alexandrescu wrote: I don't understand. I click on the link, go to youtube, and the first image I see is the blue screen facebook DConf - Day 3 etc. YouTube shows the Gophers Hate Him! advertising slide for the video thumbnail. ;) Cheers, David
Re: DMD v2.066.0-b3
For convenience, the list of unresolved issues marked as regressions: https://issues.dlang.org/buglist.cgi?bug_severity=regressionresolution=--- Seems like there is still quite a way to go until we can release RC1. David
Re: DMD v2.066.0-b2
On Wednesday, 9 July 2014 at 12:11:13 UTC, Andrew Edwards wrote: remove the string components parameter form opDispatch to reveal the same error. Hm, could you elaborate a bit further on this? As per the spec, opDispatch requires a string parameter (http://dlang.org/operatoroverloading.html#Dispatch). Removing it means that the compiler no longer considers the template to match the opDispatch signature, and thus of course .xyz fails. David
Re: core.checkedint added to druntime
On Tuesday, 1 July 2014 at 22:07:01 UTC, Paul D Anderson wrote: Will this be in the 2.066 Beta? It's currently in Git master, so yes – but we definitely need to fix https://issues.dlang.org/show_bug.cgi?id=12958 before the release (mul is horribily broken). David
Re: LDC 0.13.0 has been released!
On Wednesday, 25 June 2014 at 18:43:34 UTC, Kai Nacke wrote: It will be based on 2.065. There are only a few issues left in this version. 2.066 will add new issues in addition to the existing once. That is the reason why I will not skip a frontend version. I support your decision. We have release building down to a science now, the most time-consuming thing is usually just waiting for the LLVM build to complete (apart from writing the release notes, of course – and having to wait for me to run the build process for the OS X packages on my notebook). The hard part is ironing out the one to two hard to debug issues that inevitable seem to crop up with every new frontend merge. David
Re: LDC 0.13.0 has been released!
On Tuesday, 24 June 2014 at 13:48:14 UTC, Nordlöw wrote: LDC 0.13.0, the LLVM-based D compiler, is available for download! Great job! Will there be Linux distribution (Ubuntu) packages available? Konstantinos Margaritis has been doing a fantastic job of keeping the Debian packages up to date lately, and it seems like the 0.13.0 packages are already being generated by the build system: https://buildd.debian.org/status/package.php?p=ldcsuite=sid As far as I know, this means that it will be available in Debian unstable shortly. When the packages will trickle down into your favorite distro/channel flavor is a different question, of course. David
Re: core.checkedint added to druntime
On Thursday, 19 June 2014 at 03:42:11 UTC, David Bregman wrote: I think the mulu implementation is incorrect. There can be an overflow even when r = 0. For example consider the int version with x = y = 116. I also noticed this; another easy counter-example would be 132 for ulong multiplication. Filed as: https://issues.dlang.org/show_bug.cgi?id=12958
Re: DMD 2.066 Alpha
On Thursday, 12 June 2014 at 18:25:36 UTC, Andrei Alexandrescu wrote: On 6/12/14, 6:34 AM, Dicebot wrote: It was decided and 100% certain - virtual is not going in. Need to remove it from DMD before this release is out. Yes please. -- Andrei Since we didn't seem to have a pull request for removing the attribute: https://github.com/D-Programming-Language/dmd/pull/3663 David
Re: dmd front end now switched to Boost license
On Saturday, 14 June 2014 at 18:43:59 UTC, Walter Bright wrote: And there's another advantage I neglected to mention - it allows DMDFE code to be moved into Phobos without issues. I don't think Nick's argument is particularly compelling, but the DDMD - Phobos connection definitely makes the change very worthwhile in my opinion. David
Re: LDC 0.13.0 beta 1 released!
On Sunday, 18 May 2014 at 11:58:20 UTC, bioinfornatics wrote: Woa uOuh shared lib support added :-) I love you Unfortunately building Phobos as a shared library is not quite supported yet. I added the technical underpinnings for it, but we still need somebody to go through and acutely actually test the feature resp. fix any remaining issues. David
