On Tuesday, 2 October 2018 at 18:14:55 UTC, Andrei Alexandrescu
wrote:
Kate Gregory makes a good argument on something I've often
commented in code reviews: https://youtu.be/n0Ak6xtVXno?t=2682
I very much like LLVM's practices, and one of them is it's Coding
Standards.
It prescribes early ret
On Thursday, 26 July 2018 at 12:53:44 UTC, rikki cattermole wrote:
On 27/07/2018 12:45 AM, Johan Engelen wrote:
In D, we don't have placement new, great! And now, I learn
that the _standard library_ _does_ have something that looks
like placement new, but without extra guarantees of the spec
On Thursday, 26 July 2018 at 21:22:45 UTC, Petar Kirov
[ZombineDev] wrote:
Please excuse if my question is too naive, but how does this
change anything?
The main insight is to reason about things in terms of language
semantics, not in terms of actual memory addresses and
instructions as pro
On Wednesday, 25 July 2018 at 08:11:59 UTC, rikki cattermole
wrote:
Standard solution[0].
[0] https://dlang.org/phobos/std_conv.html#.emplace.4
Thanks for pointing to D's placement new. This is bad news for my
devirtualization work; before, I thought D is in a better
situation than C++, but
On Thursday, 12 July 2018 at 10:22:33 UTC, Shachar Shemesh wrote:
On 11/07/18 20:04, Johan Engelen wrote:
On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
DIP 1014, "Hooking D's struct move semantics", is now ready
for final review.
after quick read:
(would be much easier to do
On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu
wrote:
I now deeply regret ever telling Razvan to mention future
possible directions. This DIP must do implicit copy
constructors and do it well, nothing less and nothing more.
Strongly agree with this.
In my review on Github I h
On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
DIP 1014, "Hooking D's struct move semantics", is now ready for
final review.
after quick read:
(would be much easier to do inline commenting, but it appears
that's not supported)
### Section "Code emitted by the compiler on mov
On Tuesday, 3 July 2018 at 01:07:53 UTC, Walter Bright wrote:
Please post bug reports (including documentation problems) on
bugzilla!
https://issues.dlang.org/show_bug.cgi?id=19057
The changelog of 2.079 says:
"
3. Function parameters with default values are now allowed after
variadic template parameters
Function parameters with default values are now allowed after
variadic template parameters and when IFTI is used, always take
their default values.
...
"
However, param
On Tuesday, 5 June 2018 at 14:48:23 UTC, FeepingCreature wrote:
I'm just posting to clear up the misunderstanding that a call
to a pure function can be removed. Actually, even calls to
strongly pure functions cannot always be removed. This is
because there is one thing that a pure function can
On Thursday, 7 June 2018 at 15:18:49 UTC, H. S. Teoh wrote:
Now all you have to do is to add operator overloading to make
the wrapper type infectious, and a convenience function that
can be easily typed, and you get:
[...]
I'd like to have this in the stdlib, what are the chances?
-Johan
On Monday, 4 June 2018 at 18:47:02 UTC, Dennis wrote:
On Monday, 4 June 2018 at 18:11:47 UTC, Steven Schveighoffer
wrote:
BTW, do you have cross-module inlining on? I wonder if that
makes a difference if you didn't have it on before. (I'm
somewhat speaking from ignorance, as I've heard people t
On Tuesday, 22 May 2018 at 00:30:22 UTC, SrMordred wrote:
We're working to get each talk into separate videos, but it
may take a while.
Thank you very much!
(for some odd reason the day 2 and 3 didn´t appear to me on
youtube when I searched)
The videos are marked "Unlisted" on Youtube. Can s
On Monday, 12 March 2018 at 01:10:41 UTC, Richard wrote:
The first is the use of BetterC, although from what I can tell
DMD now has support for a minimal runtime feature as part of
2.079.0
https://dlang.org/changelog/2.079.0.html#minimal_runtime
so hopefully when this makes it's way into LDC
On Wednesday, 25 April 2018 at 19:05:53 UTC, H. S. Teoh wrote:
On Wed, Apr 25, 2018 at 06:33:56PM +, Johan Engelen via
Digitalmars-d wrote:
The profiling runtime must be linked in. On Unixes, the file
is "libldc_rt.profile-x86_64.a".
[...]
This library appears to be missi
On Wednesday, 25 April 2018 at 17:31:06 UTC, H. S. Teoh wrote:
I'm trying to figure out how to do a traditional instrumented
profile with LDC. All docs that I've managed to find so far
say to use -fprofile-instr-generate, but when I try that, I get
a ton of linker errors complaining of undefin
On Monday, 9 April 2018 at 11:06:50 UTC, Shachar Shemesh wrote:
struct S {
int a;
int[5000] arr = void;
}
void func() {
S s;
}
During the s initialization, the entire "S" area is
initialized, including the member arr which we asked to be =
void.
Is this a bug?
Could be optimized, ye
On Sunday, 18 March 2018 at 04:25:48 UTC, Manu wrote:
What is so hard about implementing a pow intrinsic that CTFE
can use?
It's ridiculous that we can't CTFE any non-linear function...
It's one of those blocker bugs that's been there almost 10
years.
It's been available in LDC since 1.6.0.
h
On Tuesday, 6 March 2018 at 20:25:10 UTC, Johan Engelen wrote:
On Tuesday, 6 March 2018 at 18:19:13 UTC, Luís Marques wrote:
On my LLVM fork for RISC-V and MSP430 work it doesn't build
(no llvm/Support/DJB.h) and on the latest stable, 5.0.1, cmake
fails to configure (Unknown CMake command
"add
On Tuesday, 6 March 2018 at 18:19:13 UTC, Luís Marques wrote:
On my LLVM fork for RISC-V and MSP430 work it doesn't build (no
llvm/Support/DJB.h) and on the latest stable, 5.0.1, cmake
fails to configure (Unknown CMake command
"add_llvm_install_targets").
LLDB and LLVM need to be version sync
Hi all,
Currently, `guardPageSize` is not stored in core.thread.Fiber.
It's only used during construction, so it's currently not
necessary to store it. However, for Fiber stack usage tracking, I
need it elsewhere too.
Is it agreeable to add an m_guardPageSize member to Fiber to
store the inf
_Please_ keep the mail/nntp/... discussion separate or private.
It's clobbering the topic.
Thanks,
Johan
On Sunday, 18 February 2018 at 20:01:39 UTC, Jonathan M Davis
wrote:
On Sunday, February 18, 2018 19:42:07 Johan Engelen via
Digitalmars-d wrote:
> There are hundreds of lines I need to molest to make the
> compiler shut up. I won't type another line of code on my
> colour libr
On Sunday, 18 February 2018 at 19:26:43 UTC, Manu wrote:
The 'solution' so add cast(int) and then cast back is not okay.
I have code
that does a lot of work on bytes/shorts (colour components are
small
integers that receive a lot of maths), and most lines get 3-4
times longer
because of thes
On Thursday, 15 February 2018 at 19:04:53 UTC, Benny wrote:
https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=plaintext
https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=json
D is finally showing up in the upper and middle parts of the
tests. In some tests Vi
On Monday, 5 February 2018 at 19:32:37 UTC, Timothee Cour wrote:
just filed https://issues.dlang.org/show_bug.cgi?id=18377:
If I may add something semi-relevant to the current discussion,
have a look here:
https://clang.llvm.org/docs/SourceBasedCodeCoverage.html
It is non-trivial to add llvm
If you're going to FOSDEM this year, you can hear about D in a
(perhaps) unexpected setting: heterogenous computing, i.e.
Nicholas's work on DCompute.
https://fosdem.org/2018/schedule/event/heterogenousd/
Cheers,
Johan
On Saturday, 27 January 2018 at 16:18:26 UTC, Thomas Mader wrote:
Can't answer your question but have a little question.
How is the behavior different to the situation in C++?
In C++, the dynamic type of an object changes during construction
and destruction (e.g. base class ctor calls base cl
I'm working on devirtualization and for that it's crucial to know
some spec details (or define them in the spec if they aren't yet).
Currently, calling non-final member functions in the destructor
is allowed and these indirect calls are to the possibly
overridden functions of derived classes.
On Friday, 26 January 2018 at 18:40:23 UTC, Seb wrote:
In case someone wants to play with DMD as a library, it got a
lot easier as of today.
Very cool.
*cough* fuzz target *ahem* *cough* continuous fuzzing *cough* .
;)
Johan
On Sunday, 7 January 2018 at 15:40:16 UTC, thinwybk wrote:
For everyone interested in the technological stuff refer to a
short summary in this repository:
https://github.com/fkromer/ros2-d-client-library
This is not too late for a GSoC project. We can add it as an idea
to the GSoC page, wit
On Tuesday, 16 January 2018 at 18:03:41 UTC, kinke wrote:
On Tuesday, 16 January 2018 at 13:09:06 UTC, Daniel Kozak wrote:
On Tue, Jan 16, 2018 at 12:51 PM, Joakim via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
On Monday, 15 January 2018 at 13:25:26 UTC, Daniel Kozak
wrote:
So why
On Wednesday, 10 January 2018 at 05:46:04 UTC, Nicholas Wilson
wrote:
On Sunday, 7 January 2018 at 16:52:55 UTC, Random D user wrote:
While not directly applicable to 'technical debt', has anyone
ever written a fuzzer for dmd?
Johan Engelen has used LLVM libFuzzer on it.
And I've been workin
On Tuesday, 9 January 2018 at 20:43:05 UTC, Wild wrote:
On Tuesday, 9 January 2018 at 18:28:46 UTC, Johan Engelen wrote:
Extra info:
LDC should also recognize the libclang_rt.asan and
libclang_rt.fuzzer libraries if they are in the same path
where LDC would try to find the libldc copies. So th
On Tuesday, 9 January 2018 at 17:54:11 UTC, kinke wrote:
On Tuesday, 9 January 2018 at 15:27:56 UTC, Wild wrote:
On Tuesday, 9 January 2018 at 15:19:37 UTC, Atila Neves wrote:
I don't know who's the current maintainer of the Arch Linux D
packages. ldc1.7.0 from the Arch repositories doesn't wor
On Tuesday, 2 January 2018 at 17:16:54 UTC, Steven Schveighoffer
wrote:
I would actually recommend ddocing each of the overloads of
destroy individually instead of lumping them together,
identifying what happens with each one.
I first wrote an extra one for just structs, but then decided to
On Tuesday, 2 January 2018 at 14:22:06 UTC, Temtaime wrote:
Why not zerofy the object ?
Please keep the discussion on the topic of documentation, thanks.
-Johan
On Wednesday, 22 November 2017 at 22:16:12 UTC, thinwybk wrote:
On Wednesday, 22 November 2017 at 19:02:17 UTC, thinwybk wrote:
On Saturday, 29 July 2017 at 10:21:32 UTC, Johan Engelen wrote:
Hi all,
Are there any robot folks out here that are working with
ROS and would be able to work on cr
On Monday, 4 December 2017 at 20:33:56 UTC, thinwybk wrote:
Hi everyone,
as far as I know there is a statement coverage analyzer built
into DMD https://dlang.org/code_coverage.html . Are there code
coverage analyzers for D which support branch coverage and
other more advanced coverage metrics
Hi all,
I'm working on (basic) devirtualization, and am wondering how
immutable the vptr is in D. There is no clear spec on this.
I am currently assuming that an object's vptr is completely
immutable and that use of the object after changes to its vptr
are UB (in contrast to the more complica
On Thursday, 26 October 2017 at 06:04:56 UTC, Shachar Shemesh
wrote:
There's a fundamental problem with scope(exit) and
scope(failure). Consider the following code:
{
a = allocate_something();
scope(exit) a.cleanup();
...
assert(a.nothingHorribleWentWrong);
}
Ideally, if that asser
On Monday, 23 October 2017 at 12:49:18 UTC, Nicholas Wilson wrote:
On Monday, 23 October 2017 at 10:42:44 UTC, Dmitry Olshansky
wrote:
On Monday, 23 October 2017 at 09:06:21 UTC, Per Nordlöw wrote:
int foo()
{
auto x = [1, 2]; // should be allocated on the stack
return y = x[0] + x[1];
On Sunday, 24 September 2017 at 21:21:27 UTC, kinke wrote:
On Sunday, 24 September 2017 at 21:01:06 UTC, Johan Engelen
wrote:
So... what's correct? :-)
2.075+. ;)
See https://github.com/dlang/dmd/pull/6754.
Thanks kinke.
(now on to fix LDC's codegen ;-)
DMD <= 2.074 and DMD >= 2.075 disagree on struct alignment.
```
struct UInt {
align(1):
uint a;
}
struct Bug {
ubyte one;
UInt two;
}
static assert(Bug.two.offsetof == 4); // Error DMD>=2.075, 1 == 4
is false
static assert(Bug.sizeof == 8); // Error DMD>=2.075, 5 == 8 is
false
http://asm.dlang.org/ does not have DMD 2.072, 2.073, 2.074,
2.075, nor 2.076.
Thanks for updating the site.
Cheers,
Johan
On Friday, 15 September 2017 at 06:17:33 UTC, Thorsten Sommer
wrote:
Thank you very much for the different approaches. Vladimir, I
installed the GDB today and try to gain new insights with it.
Rikki, we are aware of the advantages of LDC. But first of all
we want the program to run with DMD. Af
On Tuesday, 5 September 2017 at 22:59:12 UTC, Jonathan M Davis
wrote:
dmd and the spec were written with the assumption that the CPU
is going to segfault your program when you dereference a null
pointer. In the vast majority of cases, that assumption holds.
In my terminology, "dereference" i
On Monday, 4 September 2017 at 21:23:50 UTC, Moritz Maxeiner
wrote:
On Monday, 4 September 2017 at 17:58:41 UTC, Johan Engelen
wrote:
(The spec requires crashing on null dereferencing, but this
spec bit is ignored by DMD and LDC, I assume in GDC too.
Crashing on `null` dereferencing requires a
On Monday, 4 September 2017 at 14:28:14 UTC, Dukc wrote:
On Sunday, 3 September 2017 at 03:04:58 UTC, Uknown wrote:
In C, the `restrict` keyword implies that 2 or more pointer
arguments in a function call do not point to the same data.
I really don't see where the restrict keyword is needed at
On Monday, 4 September 2017 at 09:47:12 UTC, Moritz Maxeiner
wrote:
On Monday, 4 September 2017 at 09:15:30 UTC, ag0aep6g wrote:
On 09/04/2017 06:10 AM, Moritz Maxeiner wrote:
Indeed, but it also means that - other than null
dereferencing - pointer issues can by made into reference
issues my d
On Tuesday, 22 August 2017 at 18:26:46 UTC, Johan Engelen wrote:
It was discussed briefly during my DConf 2016 talk
2017.
On Friday, 18 August 2017 at 12:09:04 UTC, kinke wrote:
On Friday, 18 August 2017 at 09:42:25 UTC, Jack Applegame wrote:
For some reason, the LDC default initializes the structure,
even if initialization of all its members is specified as
void. I believe that this is wrong.
Afaik, this has be
On Tuesday, 15 August 2017 at 03:53:44 UTC, Michael V. Franklin
wrote:
An implementation of binary assignment operators for @property
functions has been submitted to the DMD pull request queue at
https://github.com/dlang/dmd/pull/7079.
[snip]
Walter has requested that I make this forum post t
On Wednesday, 9 August 2017 at 18:43:27 UTC, Walter Bright wrote:
On 8/8/2017 2:04 PM, Jacob Carlborg wrote:
[snip]
Of course, there's always pragma(mangle) as well.
Yes these work:
```
pragma(mangle, convertMangleToCppRef(g.mangleof))
void g(Klass);
pragma(mangle, mangleAsCpp("v
Hi all,
Currently, it is not possible to call the C++ function "void
foo(Klass&)" when Klass is an extern(C++) _class_ on the D side.
You have to declare Klass as a D _struct_, otherwise there is no
way to get the correct mangling. When Klass has virtual
functions, you're hosed.
For more c
On Thursday, 3 August 2017 at 12:33:54 UTC, Andrei Alexandrescu
wrote:
There's a bit of irony you can read a file during compilation
but not pass a string.
I always wondered about this. It makes things more cumbersome
than needed.
Is it a conscious decision to not allow passing a string dir
On Monday, 31 July 2017 at 21:41:47 UTC, aberba wrote:
On Saturday, 29 July 2017 at 10:21:32 UTC, Johan Engelen wrote:
Hi all,
Are there any robot folks out here that are working with ROS
and would be able to work on creating a D client library for
it?
Mike as been doing some foundation wo
On Saturday, 29 July 2017 at 23:09:38 UTC, Jonathan M Davis wrote:
[1] https://dlang.org/spec/class.html#deallocators
If destroy has been called on a class object, then it is a bug
to access it at any point after that (IIRC, the expectation is
that it will blow up in your face, because the v
On Saturday, 29 July 2017 at 22:15:41 UTC, Moritz Maxeiner wrote:
Since in your example the (stack) variable `foo` is still
referring to the (heap) memory location of the destroyed object
Ah yes of course, thanks!
- Johan
I'd like to check a bit of info I need for Address Sanitizer
checking.
The spec says [1]:
Use the destroy function to finalize an object by calling its
destructor. The memory of the object is not immediately
deallocated, instead the GC will collect the memory of the object
at an undetermined
Hi all,
Are there any robot folks out here that are working with ROS
and would be able to work on creating a D client library for it?
ROS is used a lot at our university and in robot research in
general, and most people use the C++ client (the main one, next
to Python). In arguing for teach
On Friday, 21 July 2017 at 21:32:48 UTC, Andrei Alexandrescu
wrote:
It's bizarre even lexically: "If the following ... oh wait let
me insert some stuff ... as I was saying, if the following
condition happens..."
(excuse me for muddying the waters)
We do have a construct like that already:
``
On Friday, 21 July 2017 at 21:37:39 UTC, Johan Engelen wrote:
On Friday, 21 July 2017 at 20:53:18 UTC, Walter Bright wrote:
On 7/21/2017 12:06 PM, Johan Engelen wrote:
< [...]
Another option is to use a pointer to the asan functions, like:
if (asan_fp)
(*asan_fp)(args...)
The asan
On Friday, 21 July 2017 at 20:53:18 UTC, Walter Bright wrote:
On 7/21/2017 12:06 PM, Johan Engelen wrote:
< [...]
Thanks for your work on this. It is important to support such
valuable tools.
One way making such things pretty much cost-free in the olden
days was to trick the linker into writ
On Friday, 21 July 2017 at 20:56:02 UTC, Walter Bright wrote:
On 7/21/2017 12:06 PM, Johan Engelen wrote:
I've added AddressSanitizer [1] support to LDC, and it is
able to nicely catch bugs like this one:
If anyone is game, it would be cool to do an LLVM compile of
DMD so AddressSanitizer
On Thursday, 20 July 2017 at 21:17:45 UTC, Walter Bright wrote:
Some time ago, I wrote about the X Macro in C:
https://digitalmars.com/articles/b51.html
I used it from time to time in C code. It's one of the things I
actually like about the C preprocessor. But in translating the
aged C code
Hi all,
I've added AddressSanitizer [1] support to LDC, and it is able
to nicely catch bugs like this one:
```
void foo(int* arr) {
arr[10] = 1;
}
void main() {
int[10] a;
foo(&a[0]);
}
```
It works for malloc'ed memory, but not yet for GC'd memory. Our
GC pool memory is malloc'
On Friday, 14 July 2017 at 23:51:24 UTC, Walter Bright wrote:
On 7/14/2017 9:53 AM, Johan Engelen wrote:
What happens in that in one kind of compilation, @nogc is
deduced for a function. But in another compilation, it isn't.
Thus references to the function will have the wrong mangling,
and lin
The frontend is automatically deducing things like @nogc and
nothrow, but it is flaky and results in linker errors for a
complex codebase (Weka's).
What happens in that in one kind of compilation, @nogc is deduced
for a function. But in another compilation, it isn't. Thus
references to the fu
On Wednesday, 12 July 2017 at 20:12:03 UTC, Steven Schveighoffer
wrote:
...
Which means this may cause a bunch of nuisance errors.
It's a trade-off between nuisance in some cases (the Phobos ones
can be solved with val = abs(val), or with static if), and
possibly catching bugs in other cases.
On Tuesday, 11 July 2017 at 20:02:07 UTC, Johan Engelen wrote:
On Tuesday, 11 July 2017 at 19:57:06 UTC, Johan Engelen wrote:
On Tuesday, 11 July 2017 at 19:46:00 UTC, Johan Engelen wrote:
The Weka folks would like to see a compile error on negating
unsigned types:
Also this nice hackery woul
On Tuesday, 11 July 2017 at 19:57:06 UTC, Johan Engelen wrote:
On Tuesday, 11 July 2017 at 19:46:00 UTC, Johan Engelen wrote:
The Weka folks would like to see a compile error on negating
unsigned types:
Also this nice hackery would need a workaround:
```
if ((y&(-y))==y)
```
http://www.ex
On Tuesday, 11 July 2017 at 19:46:00 UTC, Johan Engelen wrote:
The Weka folks would like to see a compile error on negating
unsigned types:
Also this nice hackery would need a workaround:
```
if ((y&(-y))==y)
```
The Weka folks would like to see a compile error on negating
unsigned types:
```
uint total = 0;
void add(int x) { total += x; }
ubyte popCount() { return 5; }
add(popCount());
add(-popCount());
writeln(total); // <-- what does this print? (behavior is
different from C)
```
After adding the e
On Wednesday, 5 July 2017 at 09:41:40 UTC, Nicholas Wilson wrote:
Hi all,
Now that I've (finally) finished my honours thesis,
Grats!
I've got time to start working on dcompute again.
Yay!
* LDC/LLVM releases that support SPIR-V. I've got OSX covered,
Windows/Linux would be nice to have.
This code:
```
void fun() {
auto a = new int;
}
```
results in this assembly output on asm.dlang.org:
```
void example.fun():
push rbp
movrbp,rsp
subrsp,0x10
movedi,0x0
call 12
movQWORD PTR [rbp-0x8],rax
leave
ret
```
It'd help a lot if relocation entries are als
The spec (or DMD frontend) is broken regarding struct
initialization with explicit mention of member field names:
https://dlang.org/spec/struct.html#static_struct_init
The spec says:
"The static initializer syntax can also be used to initialize
non-static variables, provided that the member nam
On Saturday, 24 June 2017 at 18:16:46 UTC, FoxyBrown wrote:
Nice to know it's being worked on. I am not really familiar
with llvm but it seems like it can be quite useful. I'm I
correct that basically llvm is an intermediate
representation(sorta like C#/VBS/F#/etc's IR)?
This means that one
On Saturday, 24 June 2017 at 17:42:48 UTC, Johan Engelen wrote:
Does anybody know a workaround?
I got something with mixins now that seems to work.
```
void foo(string modname)() {
mixin("static import mod = " ~ modname ~ ";");
foreach(name; __traits(allMembers, mod)) {
pragma(
This code no longer compiles (regression since 2.072, [1]):
```
module example;
import std.meta: staticIndexOf;
struct Attrib {}
@Attrib enum TEST = 123;
void foo() {
foreach(name; __traits(allMembers, example)) {
pragma(msg, name);
pragma(msg, __traits(getAttributes, __trai
On Friday, 23 June 2017 at 19:56:17 UTC, Joakim wrote:
Just last night, I was thinking about some easy way to let ldc
users cross-compile the stdlib themselves from the regular ldc
download, and I thought of doing it with dub, the D package
manager, since we now distribute dub alongside ldc.
On Friday, 23 June 2017 at 04:16:57 UTC, Manu wrote:
I just want to suggest to the LDC guys that it might be a nice
idea to have the installer
Wait, "the installer" ? Afaik there is no LDC installer.
https://github.com/ldc-developers/ldc/issues/1754
On Wednesday, 21 June 2017 at 15:11:39 UTC, Joakim wrote:
the gcc tree:
https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html
Congratulations to Iain and the gdc team. :)
Congratulations! Great achievement.
- Johan
On Monday, 5 June 2017 at 05:22:44 UTC, Sebastien Alaiwan wrote:
The whole simplified toolchain and example project live here:
https://github.com/Ace17/dscripten
Are you planning on upstreaming some of your work to LDC? Please
do! :-)
Looks like it is relatively easy to integrate most of you
On Saturday, 3 June 2017 at 04:25:27 UTC, Jesse Phillips wrote:
I compared these two: LDC -O3 -release
Quick note:
Keep in mind that LDC does not do cross-module inlining
(non-template functions) by default yet. It's good to check
whether you see big differences with
`-enable-cross-module-i
On Saturday, 6 May 2017 at 23:53:45 UTC, Ethan Watson wrote:
Rather than a city meet up monthly, what about a continental
meet up quarterly?
Can we get a cool acronym / name for this thing? Helps when
talking with people about it. ;-)
cheers,
Johan
On Saturday, 6 May 2017 at 23:53:45 UTC, Ethan Watson wrote:
... Rather than a city meet up monthly, what about a
continental meet up quarterly?
... Anyone else think this is a great idea?
+1 !
-Johan
On Saturday, 15 April 2017 at 15:11:08 UTC, Laeeth Isharc wrote:
Not sure how much memory ldc takes to build. If it would be
helpful for ARM I could contribute a couple of servers on
scaleway or similar.
That'd be great. Can you take initiative and send a mail to Kai
and ask him about the
On Thursday, 6 April 2017 at 09:39:05 UTC, kinke wrote:
What LDC would primarily need is a CI platform supporting ARM
(and ideally AArch64) in order to make it a true first-class
target. We don't know of a free CI platform, so ARM isn't
tested automatically, and it's currently mostly up to po
On Monday, 10 April 2017 at 13:20:00 UTC, Matthias Klumpp wrote:
Btw, at time we are just ignore the ABI issues, and
surprisingly nothing broke yet, indicating that ABI breakage
isn't very common or not affecting commonly used interfaces
much.
One big ABI change was in 2.071:
https://issue
On Sunday, 2 April 2017 at 11:44:16 UTC, David Nadlinger wrote:
On Sunday, 2 April 2017 at 10:55:22 UTC, Johan Engelen wrote:
a ~ "abc" "def";
If the order is important, make it `a ~ ("abc" ~ "def")`
instead. I'd argue that with concatenation usually being
left-associative, clearly statin
On Sunday, 2 April 2017 at 10:02:09 UTC, Tobias Pankrath wrote:
On Sunday, 2 April 2017 at 09:22:38 UTC, Johan Engelen wrote:
Did we lose the ability to break strings across lines?
[1]
https://dlang.org/changelog/2.072.0.html#deprecated_implicit_cat
Delimited strings are the way to go.
So
On Sunday, 2 April 2017 at 10:05:57 UTC, Jonathan M Davis wrote:
On Sunday, April 02, 2017 11:47:52 Jacob Carlborg via
Digitalmars-d wrote:
On 2017-04-02 11:22, Johan Engelen wrote:
> Since 2.072, implicit string concatenation is deprecated
> [1]. Can someone give me a link to the discussion ab
Since 2.072, implicit string concatenation is deprecated [1].
Can someone give me a link to the discussion about this?
I am wondering about the language spec changes involved.
```
"abc"
"def"
```
means something different than
```
"abc"
~ "def"
```
right? (for example because opBinary!(“
On Wednesday, 8 March 2017 at 17:16:58 UTC, Johan Engelen wrote:
Does LLVM trunk automatically build an LLD LTO plugin on
Windows? If not, we should ask about it on the LLVM mailing
list.
Er... stop me before doing something stupid :)
LTO is of course a native feature of LLD.
On Tuesday, 7 March 2017 at 22:38:33 UTC, kinke wrote:
Yep, I gave LLD 3.9 a try on Win64 some weeks ago. Works out of
the box as drop-in replacement for Microsoft's link.exe, incl.
usage of environment variables.
Niiice. Awesome indeed!
Does LLVM trunk automatically build an LLD LTO plugin
On Tuesday, 7 March 2017 at 18:42:40 UTC, Johan Engelen wrote:
It works on OS X too.
And OS X is the only platform for which we package the LTO
linker binaries in the release.
Has anybody tried LLD on Windows for D already?
https://lld.llvm.org/windows_support.html
If LLD works (or another l
On Tuesday, 7 March 2017 at 18:15:52 UTC, Temtaime wrote:
On Sunday, 5 March 2017 at 19:52:12 UTC, Daniel Kozak wrote:
Dne 5.3.2017 v 20:31 Temtaime via Digitalmars-d napsal(a):
On Sunday, 5 March 2017 at 17:17:13 UTC, Las wrote:
Is Phobos compiled with LTO enabled?
There is no LTO with D.
On Sunday, 5 March 2017 at 19:52:12 UTC, Daniel Kozak wrote:
Dne 5.3.2017 v 20:31 Temtaime via Digitalmars-d napsal(a):
On Sunday, 5 March 2017 at 17:17:13 UTC, Las wrote:
Is Phobos compiled with LTO enabled?
There is no LTO with D.
Yes it is
https://johanengelen.github.io/ldc/2016/11/10/Li
On Sunday, 5 March 2017 at 21:00:32 UTC, Dmitry Olshansky wrote:
On 3/5/17 6:17 PM, Las wrote:
Is Phobos compiled with LTO enabled?
LTO is *link* time optimization so I'd say it makes no sense
for libraries, as they are not linked.
Static libraries _are_ linked into your executable and LTO
1 - 100 of 285 matches
Mail list logo
