Re: [Semi-OT] to!string(enumType)

On Friday, 19 May 2017 at 21:01:09 UTC, Jonathan M Davis wrote: Wait, what? Doesn't D specifically _not_ have SFINAE? You can use static if to test what compiles, and the branch whose condition compiles is then the on that gets compiled in, which kind of emulates what you'd get with SFINAE,

Re: [Semi-OT] to!string(enumType)

On Friday, 19 May 2017 at 20:23:16 UTC, Dominikus Dittes Scherkl wrote: On Friday, 19 May 2017 at 17:47:42 UTC, Stefan Koch wrote: On Friday, 19 May 2017 at 17:34:28 UTC, Dominikus Dittes Scherkl wrote: [...] the static assert tells what's going on. It it does result in a simple overload not

Re: [Semi-OT] to!string(enumType)

On Friday, 19 May 2017 at 17:34:28 UTC, Dominikus Dittes Scherkl wrote: On Friday, 19 May 2017 at 00:14:05 UTC, Stefan Koch wrote: string enumToString(E)(E v) { static assert(is(E == enum), "emumToString is only meant for enums"); Why that assert? We can check it at compiletime.

Re: Fantastic exchange from DConf

On Friday, 19 May 2017 at 16:29:59 UTC, Timon Gehr wrote: On 19.05.2017 17:12, Steven Schveighoffer wrote: I mean libraries which only contain @safe and @system calls. i.e.: $ grep -R '@trusted' libsafe | wc -l 0 mixin("@"~"trusted void nasty(){ corruptAllTheMemory(); }"); dmd -vcg-ast

Re: Code improvement for DNA reverse complement?

On Friday, 19 May 2017 at 07:29:44 UTC, biocyberman wrote: I am solving this problem http://rosalind.info/problems/revc/ as an exercise to learn D. This is my solution: https://dpaste.dzfl.pl/8aa667f962b7 Is there some D tricks I can use to make the `reverseComplement` function more concise

Re: [Semi-OT] to!string(enumType)

On Thursday, 18 May 2017 at 23:15:46 UTC, ag0aep6g wrote: On 05/19/2017 12:31 AM, Stefan Koch wrote: string enumToString(E)(E v) { static assert(is(E == enum), "emumToString is only meant for enums"); mixin ({ string result = "final switch(v) {\n";

Re: [Semi-OT] to!string(enumType)

On Thursday, 18 May 2017 at 22:31:47 UTC, Stefan Koch wrote: Granted this version will result in undefined behavior if you pass something like (cast(ET) 3) to it. But the 55x increase in compilation speed is well worth it :) This code will replicate to!string behavior perfectly but will

Re: [Semi-OT] to!string(enumType)

On Thursday, 18 May 2017 at 22:31:47 UTC, Stefan Koch wrote: Hi, I just took a look into commonly used functionality of Phobos. Such as getting the string representation of a enum. [...] Using -vcg-ast we see that it expands to ~50 lines.

[Semi-OT] to!string(enumType)

Hi, I just took a look into commonly used functionality of Phobos. Such as getting the string representation of a enum. the following code: import std.conv; enum ET { One, Two } static assert(to!string(ET.One) == "One"); takes about 220 milliseconds to compile. creating a 7.5k object

Re: CTFE Status 2

On Tuesday, 16 May 2017 at 13:44:27 UTC, Stefan Koch wrote: [ ... ] The reason ABI issues. Where exactly ? No Idea. Not just abi issues ... There are more fundamental problems where we sometimes forget to allocate space, for locals (of composite types).

Re: llvm-d 2.2 Dynamic loading (yet again)

On Wednesday, 17 May 2017 at 14:55:12 UTC, Moritz Maxeiner wrote: In response to a DConf 2017 request regarding this, llvm-d again supports dynamic loading. The API is essentially the same as is was for llvm 1.x, though you have to enable it with D versions. [...] Many Thanks.

Re: Replacing std.math raw pointer arithmetic with a union type

On Wednesday, 17 May 2017 at 19:26:32 UTC, tsbockman wrote: On Wednesday, 17 May 2017 at 15:30:29 UTC, Stefan Koch wrote: the special case it supports if cast(uint*) and cast(ulong*) What about casting from real* when real.sizeof > double.sizeof? unsupported. The code in ctfeExpr

Re: Replacing std.math raw pointer arithmetic with a union type

On Wednesday, 17 May 2017 at 15:15:04 UTC, Walter Bright wrote: On 5/16/2017 8:02 PM, tsbockman wrote: Such code is verbose, hard to read, and, judging by the bugs and missing specializations I've found, hard to write correctly. It is also not compatible with CTFE. CTFE does support things

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] So ... I just encountered more ABI issues; related to slices which are part of structures. struct R { uint[] s1; uint[] s2; } like this. R returnSlices(int[] s1, int[] s2) { return R(s1[], s2[]); } static

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] So I have fixed a few cases of outer function evaluation. Unfortunately this exposed some hard to track down bugs in how expressions are handled. The JIT and Debugger features are on ice, until those bugs are

Re: CTFE Status 2

On Friday, 12 May 2017 at 11:21:56 UTC, Stefan Koch wrote: ... anyway. I am happy this is fixed now. Now I am less happy. The fallout of this fix causes code in std.ascii to miscompile. Apperantly we don't make sure our function list is cleared before finalization.

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Hi Guys, Outer function arguments are now supperted. meaning this code will now work: int[] filterBy(int[] arr , bool function(uint) fn) { int[] result = []; uint resultLength; result.length = arr.length;

Re: The cost of doing compile time introspection

On Thursday, 11 May 2017 at 21:57:06 UTC, Timon Gehr wrote: On 10.05.2017 16:28, Stefan Koch wrote: On Wednesday, 10 May 2017 at 14:03:58 UTC, Biotronic wrote: On Wednesday, 10 May 2017 at 11:45:05 UTC, Moritz Maxeiner wrote: [CTFE slow] First, as you may know, Stefan Koch is working on an

Re: Concerns about using struct initializer in UDA?

On Thursday, 11 May 2017 at 11:36:17 UTC, Andre Pany wrote: On Thursday, 11 May 2017 at 10:51:09 UTC, Stefan Koch wrote: On Thursday, 11 May 2017 at 10:49:58 UTC, Andre Pany wrote: [...] We have that syntax already. I do not understand. Should the syntax I have written already work as I

Re: Concerns about using struct initializer in UDA?

On Thursday, 11 May 2017 at 10:49:58 UTC, Andre Pany wrote: Hi, I know there are concerns about struct initialization in method calls but what is about struct initializer in UDA? Scenario: I want to set several UDA values. At the moment I have to create for each value a structure with

Re: struct File. property size.

On Thursday, 11 May 2017 at 07:24:00 UTC, AntonSotov wrote: import std.stdio; int main() { auto big = File("bigfile", "r+"); //bigfile size 20 GB writeln(big.size); // ERROR! return 0; } // std.exception.ErrnoException@std\stdio.d(1029): Could

Re: Static foreach pull request

On Wednesday, 10 May 2017 at 18:41:30 UTC, Timon Gehr wrote: On 10.05.2017 16:21, Stefan Koch wrote: On Wednesday, 10 May 2017 at 14:13:09 UTC, Timon Gehr wrote: On 10.05.2017 15:18, Stefan Koch wrote: if you try assert([] is null), it should fail. It doesn't. I have tried to make that

Re: Lookahead in unittest

On Wednesday, 10 May 2017 at 16:09:06 UTC, Raiderium wrote: Heyo, On 2.074.0, the following test fails with "Error: undefined identifier 'B' " unittest { class A { B b; } class B { } } I can't figure out if this is intended behaviour. It's making a template-heavy module

Re: The cost of doing compile time introspection

On Wednesday, 10 May 2017 at 14:03:58 UTC, Biotronic wrote: On Wednesday, 10 May 2017 at 11:45:05 UTC, Moritz Maxeiner wrote: [CTFE slow] First, as you may know, Stefan Koch is working on an improved CTFE engine that will hopefully make things a lot better. It will not; This is issue is

Re: Static foreach pull request

On Wednesday, 10 May 2017 at 14:13:09 UTC, Timon Gehr wrote: On 10.05.2017 15:18, Stefan Koch wrote: if you try assert([] is null), it should fail. It doesn't. I have tried to make that point before, unsuccessfully. Empty arrays may or may not be null, but the empty array literal is always

Re: Problems with Array Assignment?

On Wednesday, 10 May 2017 at 13:34:30 UTC, Samwise wrote: I'm really sure this is just a stupid mistake I made, but I can't for the life of me figure out what is going on. Basically I'm trying to assign a reference to an object to an array, and the objects exist (an explicit destructor is

Re: Static foreach pull request

On Wednesday, 10 May 2017 at 13:11:46 UTC, Atila Neves wrote: On Wednesday, 10 May 2017 at 11:12:06 UTC, Stefan Koch wrote: null : () { Slice* s; s = null; return s; } [] : () { Slice* s; s = alloca(sizeof(*s)); s.base = null; s.length = 0; return s; } Therefore null.length =>

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Thanks to Daniel Murphy's input; '&&' works now in my experimental version. I hope to get it to pass the auto-tester soon! This is a big step :) Thanks Daniel.

Re: Static foreach pull request

On Wednesday, 10 May 2017 at 09:42:53 UTC, Timon Gehr wrote: On 09.05.2017 23:56, Timon Gehr wrote: core.exception.AssertError@ddmd/blockexit.d(90): Assertion failure ... Thanks! (It's a known issue though:

Re: DConf 2017 Hackathon report

On Wednesday, 10 May 2017 at 10:55:09 UTC, Atila Neves wrote: I felt like a wizard afterwards for modifying the compiler, which is a nice bonus. Nice, I usually feel confused after modifying the compiler. Now if only I could get the autotester to be green... Just think about how much

Re: Turn .opApply into ranges

On Tuesday, 9 May 2017 at 17:23:36 UTC, Yuxuan Shui wrote: I wondered if I can turn struct that defines opApply into ranges. And it turns out to be surprisingly easy: https://gist.github.com/yshui/716cfe987c89997760cabc2c951ca430 Maybe we can phase out opApply support in foreach? ;) BTW, is

Re: Structure of platform specific vs non platform specific code

On Tuesday, 9 May 2017 at 15:28:20 UTC, WhatMeWorry wrote: On Monday, 8 May 2017 at 21:16:53 UTC, Igor wrote: Hi, I am following Casey Muratori's Handmade Hero and writing it in DLang. This sounds very interesting. Maybe make it a public github project? It can only accessible for those

Re: -vcg-ast dmd command line switch

On Sunday, 7 May 2017 at 15:16:48 UTC, Ali Çehreli wrote: I've just commented on the following thread on the 'internals' newsgroup: http://forum.dlang.org/thread/tiiuucwivajgsnoos...@forum.dlang.org I think this should be improved to display code that is being mixed-in. Ali I just

Re: reasoning of evaluating code after return in current block (static if return)

On Sunday, 7 May 2017 at 23:41:00 UTC, bastien penavayre wrote: On Sunday, 7 May 2017 at 23:20:26 UTC, Adam D. Ruppe wrote: [...] I just realized that I accidentally posted this while editing. I agree with you on that this is barely different from just adding "else". [...] compile your

Re: CTFE Status 2

On Wednesday, 3 May 2017 at 08:23:54 UTC, Nordlöw wrote: On Wednesday, 3 May 2017 at 07:35:56 UTC, Stefan Koch wrote: On Wednesday, 3 May 2017 at 06:10:22 UTC, Adrian Matoga wrote: So you're going to reinvent TCP in your debugging protocol? No. there is no need for a full blown recovery

Re: CTFE Status 2

On Wednesday, 3 May 2017 at 06:10:22 UTC, Adrian Matoga wrote: So you're going to reinvent TCP in your debugging protocol? No. there is no need for a full blown recovery mechanism. For the typical usecase a lossless orderd connection can be assumed. And most things are not order dependent

Re: See you soon at dconf

On Wednesday, 3 May 2017 at 06:45:05 UTC, Bastiaan Veelo wrote: On Tuesday, 2 May 2017 at 20:19:02 UTC, Stefan Koch wrote: Hi, I am very happy to see you soon at dconf. Likewise! I am at the airport as I type. Bastiaan. are you in Berlin already ? I am going to arrive near 19:00. Anyone up

Re: CTFE Status 2

On Tuesday, 2 May 2017 at 22:08:31 UTC, Moritz Maxeiner wrote: On Tuesday, 2 May 2017 at 09:55:56 UTC, Stefan Koch wrote: [...] I intended for the debugging functionality to be exposed via a udp socket listening on localhost. Such that a debug-ui does not have to deal with ipc difficulties.

See you soon at dconf

Hi, I am very happy to see you soon at dconf. And I apologize in advance for my nearly slideless talk. Hope this time there is dmd on the machine! Cheers Stefan

Re: CTFE Status 2

On Monday, 1 May 2017 at 19:06:24 UTC, H. S. Teoh wrote: On Mon, May 01, 2017 at 06:23:08PM +, Stefan Koch via Digitalmars-d wrote: [...] I'm not sure about providing a debugger UI inside the compiler itself... it's certainly possible, and could lead to interesting new ways of using

Re: DConf Hackathon Ideas

On Monday, 1 May 2017 at 17:04:42 UTC, Iain Buclaw wrote: On 1 May 2017 at 16:51, Mike Parker via Digitalmars-d wrote: On Monday, 1 May 2017 at 14:38:11 UTC, Joseph Rushton Wakeling wrote: On Thursday, 27 April 2017 at 16:33:02 UTC, singingbush wrote: SDL

Re: CTFE Status 2

On Sunday, 30 April 2017 at 19:52:27 UTC, H. S. Teoh wrote: On Sun, Apr 30, 2017 at 01:26:09PM +, Stefan Koch via Digitalmars-d wrote: On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: > [ ... ] Big news! The first step to include debug info has been done. Yes this me

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Big news! The first step to include debug info has been done. Yes this means you will be able to step through ctfe code while the compiler executes it.

Re: Transitive bit-packing of fields

On Sunday, 30 April 2017 at 11:02:52 UTC, Nordlöw wrote: Have anybody found a way to do transitive packing of bitfields? For instance, in import std.bitmanip : bitfields; struct X { // one bit too many to fit in one byte mixin(bitfields!(bool, `a`, 1, bool, `b`,

Re: CTFE Status 2

On Friday, 28 April 2017 at 17:53:04 UTC, Stefan Koch wrote: On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Hi Guys, I just implemented sliceAssigment. meaning the following code will now compile: uint[] assignSlice(uint from, uint to, uint[] stuff) { uint[]

Re: CTFE Status 2

On Friday, 28 April 2017 at 08:47:43 UTC, Stefan Koch wrote: On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] After a little of exploration of the JIT, I have now determined that a simple risc architecture is still the best. (codegen for scaled loads is hard :p) I

Re: CTFE Status 2

On Friday, 28 April 2017 at 17:53:04 UTC, Stefan Koch wrote: On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Hi Guys, I just implemented sliceAssigment. meaning the following code will now compile: uint[] assignSlice(uint from, uint to, uint[] stuff) { uint[]

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Hi Guys, I just implemented sliceAssigment. meaning the following code will now compile: uint[] assignSlice(uint from, uint to, uint[] stuff) { uint[] slice; slice.length = to + 4; foreach (uint i; 0 .. to

Re: CTFE Status 2

On Friday, 28 April 2017 at 13:03:42 UTC, Nordlöw wrote: On Friday, 28 April 2017 at 08:47:43 UTC, Stefan Koch wrote: After a little of exploration of the JIT, I have now determined that a simple risc architecture is still the best. (codegen for scaled loads is hard :p) Do you mean no Jit?

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] After a little of exploration of the JIT, I have now determined that a simple risc architecture is still the best. (codegen for scaled loads is hard :p) I am now back to fixing non-compiling code, such as : struct S

Re: CTFE Status 2

On Thursday, 27 April 2017 at 08:51:17 UTC, Dmitry Olshansky wrote: On 4/27/17 4:15 AM, Stefan Koch wrote: On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Hi Guys, As you already probably know some work has been done in the past week to get an x86 jit rolling. It

Re: CTFE Status 2

On Thursday, 27 April 2017 at 03:33:03 UTC, H. S. Teoh wrote: Is it possible at all to use any of the backend (in particular what parts of the optimizer that are pertinent), or is the API not conducive for this? T It is of course possible to use dmds backend but not very desirable, dmds

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Hi Guys, As you already probably know some work has been done in the past week to get an x86 jit rolling. It is designed to produce very simple code with _any_ optimization at all. Since optimization introduces

Re: Shortest quine in D

On Wednesday, 26 April 2017 at 23:19:32 UTC, H. S. Teoh wrote: --hello.d:-- import std.stdio;void main(){write(import("hello.d"));} Thanks to string imports, quines in D are actually trivial. :-D T use __FILE__ to make it a little more portable

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

On Monday, 24 April 2017 at 11:29:01 UTC, Ola Fosheim Grøstad wrote: What are scaled loads? x86 has addressing modes which allow you to multiply an index by a certain set of scalars and add it as on offset to the pointer you want to load. Thereby making memory access patterns more

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

On Sunday, 23 April 2017 at 02:45:09 UTC, evilrat wrote: On Saturday, 22 April 2017 at 10:38:45 UTC, Stefan Koch wrote: On Saturday, 22 April 2017 at 03:03:32 UTC, evilrat wrote: [...] If you could share the code it would be appreciated. If you cannot share it publicly come in irc sometime.

Re: DIP 1005 - Preliminary Review Round 1

On Saturday, 22 April 2017 at 16:13:20 UTC, Timon Gehr wrote: This is how it works for static if, and it is also how it will work for static foreach, so it is even consistent with other language features. So you will touch up your static foreach DIP ? If so I am okay with building the

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

On Saturday, 22 April 2017 at 14:22:18 UTC, John Colvin wrote: On Thursday, 20 April 2017 at 12:56:11 UTC, Stefan Koch wrote: Hi Guys, I just begun work on the x86 jit backend. Because right now I am at a stage where further design decisions need to be made and those decisions need to be

Re: typeof(this) return wrong type

On Saturday, 22 April 2017 at 11:33:22 UTC, Andrey wrote: Hello, I trying to add custom attribute OnClickListener, the problem is that typeof always return BaseView type instead of MyView. struct OnClickListener { string id; } class BaseView { void onCreate() {

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

On Saturday, 22 April 2017 at 03:03:32 UTC, evilrat wrote: On Thursday, 20 April 2017 at 14:54:20 UTC, Stefan Koch wrote: On Thursday, 20 April 2017 at 14:35:27 UTC, Suliman wrote: Could you explain where it can be helpful? It's helpful for newCTFE's development. :) The I estimate the jit

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

On Saturday, 22 April 2017 at 03:03:32 UTC, evilrat wrote: On Thursday, 20 April 2017 at 14:54:20 UTC, Stefan Koch wrote: On Thursday, 20 April 2017 at 14:35:27 UTC, Suliman wrote: Could you explain where it can be helpful? It's helpful for newCTFE's development. :) The I estimate the jit

Re: multiple `alias this` suggestion

On Friday, 21 April 2017 at 16:41:45 UTC, Meta wrote: On Friday, 21 April 2017 at 16:21:57 UTC, H. S. Teoh wrote: On Fri, Apr 21, 2017 at 08:17:28AM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...] This is interesting, and would be timely to discuss before an implementation of

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

On Thursday, 20 April 2017 at 14:35:27 UTC, Suliman wrote: Could you explain where it can be helpful? It's helpful for newCTFE's development. :) The I estimate the jit will easily be 10 times faster then my bytecode interpreter. which will make it about 100-1000x faster then the current

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

On Thursday, 20 April 2017 at 12:56:11 UTC, Stefan Koch wrote: Hi Guys, I just begun work on the x86 jit backend. Because right now I am at a stage where further design decisions need to be made and those decisions need to be informed by how a _fast_ jit-compatible x86-codegen is

{OT} Youtube Video: newCTFE: Starting to write the x86 JIT

Hi Guys, I just begun work on the x86 jit backend. Because right now I am at a stage where further design decisions need to be made and those decisions need to be informed by how a _fast_ jit-compatible x86-codegen is structured. Since I do believe that this is an interesting topic; I will

Re: Thoughts from newcommer

On Tuesday, 18 April 2017 at 16:42:38 UTC, Andrei Alexandrescu wrote: On 04/18/2017 03:00 AM, Shachar Shemesh wrote: D would have the ability to have a nice container that would do RAII (for classes since for structs, __dtors are called automatically) That's just it, though. They are not.

Re: Interpolated strings

On Wednesday, 19 April 2017 at 12:10:33 UTC, Jonas Drewsen wrote: On Wednesday, 19 April 2017 at 12:03:47 UTC, Stefan Koch wrote: On Wednesday, 19 April 2017 at 11:59:51 UTC, Jonas Drewsen wrote: What about supporting an optional prefix inside the {} like: int year = 2017; format($"The date

Re: Interpolated strings

On Wednesday, 19 April 2017 at 11:59:51 UTC, Jonas Drewsen wrote: What about supporting an optional prefix inside the {} like: int year = 2017; format($"The date is {%04d year}"); so if there is a % immediately following the { then the chars until next whitespace is format specifier. You can

Re: Optilink bugs(or DMD)

On Wednesday, 19 April 2017 at 03:52:54 UTC, Nierjerson wrote: Major optilink bugs, blocker. Code is long but demonstrates the issue. Compiles with ldc. [...] There are two instances of void ForegroundColor(cSolidColor rhs)

Re: Interpolated strings

On Tuesday, 18 April 2017 at 06:54:11 UTC, Jacob Carlborg wrote: On 2017-04-17 21:28, Jonas Drewsen wrote: The page could also list pre-approved language changes such as async functions (which Walter wants afaik). Another feature that can be implemented with AST macros. This is starting to

Re: Generating switch at Compile Time

On Thursday, 13 April 2017 at 21:06:52 UTC, Jesse Phillips wrote: I realize that this is likely really pushing the compile time generation but a recent change to the switch statement[1] is surfacing because of this usage. uninitswitch2.d(13): Deprecation: 'switch' skips declaration of

Re: Duplicated functions not reported?

On Sunday, 16 April 2017 at 17:10:14 UTC, Temtaime wrote: On Sunday, 16 April 2017 at 15:54:16 UTC, Stefan Koch wrote: On Sunday, 16 April 2017 at 10:56:37 UTC, Era Scarecrow wrote: On Saturday, 15 April 2017 at 11:10:01 UTC, Stefan Koch wrote: It would requires an O(n^2) check per

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Hi Guys, I just fixed default initialization of structs. So now a larger portion of code will be compiled and executed by newCTFE. my_struct MyStruct; will now work, before it would trigger a bailout. NOTE: this will

Re: Thoughts from newcommer

On Sunday, 16 April 2017 at 14:25:22 UTC, Andrei Alexandrescu wrote: On 4/16/17 3:50 AM, Shachar Shemesh wrote: https://issues.dlang.org/show_bug.cgi?id=14246 I'd raised the importance and urgency of this issue in the past. Walter is really overloaded for the time being. Any volunteer wants

Re: Duplicated functions not reported?

On Sunday, 16 April 2017 at 10:56:37 UTC, Era Scarecrow wrote: On Saturday, 15 April 2017 at 11:10:01 UTC, Stefan Koch wrote: It would requires an O(n^2) check per declaration. Even it is never used. which would make imports that much more expensive. Seems wrong to me... If you made a

Re: Suboptimal array copy in druntime?

On Sunday, 16 April 2017 at 10:08:22 UTC, Guillaume Chatelet wrote: I was looking at the _d_arrayassign family functions in druntime: https://github.com/dlang/druntime/blob/master/src/rt/arrayassign.d#L47 https://github.com/dlang/druntime/blob/master/src/rt/arrayassign.d#L139 [...] Nope.

Re: Strange stack variable corruption error after calling extern(C) function

On Sunday, 16 April 2017 at 08:34:12 UTC, cc wrote: All this with extern(Windows) rather than extern(C) by the way. Why not use loadLibraryA ? then all the problems go away :) this is how derelict does it as well.

Re: Duplicated functions not reported?

On Saturday, 15 April 2017 at 09:17:08 UTC, Jacob Carlborg wrote: I'm not sure if I'm missing something obvious here, but the following code compiles and runs: void foo() {} void foo() {} void main() {} Although if I do call "foo", the compiler will complain that it matches both versions of

Re: CTFE Status 2

On Saturday, 15 April 2017 at 10:30:57 UTC, Moritz Maxeiner wrote: On Saturday, 15 April 2017 at 10:10:54 UTC, Stefan Koch wrote: On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: Hi Guys, due to the old CTFE status thread getting to page 30, I am now starting a new one.

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: Hi Guys, due to the old CTFE status thread getting to page 30, I am now starting a new one. [...] The llvm backend is back in a fully working state. It's about 2times slower in my then my interpreter ;)

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: { ... } Wonderful news! Most of the Byteocode macros are gone! meaning less templates and faster bytecode generartion!

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Hi I want to share another story. I was pretty happy to have recursive function calls working. So happy in fact that I overlooked that they were actually generated twice. Let me illustrate what happend. Suppose we

Re: Deduplicating template reflection code

On Friday, 14 April 2017 at 08:24:00 UTC, Johannes Pfau wrote: I've got this code duplicated in quite some functions: - foreach (member; __traits(derivedMembers, API)) { // Guards against private members static if (__traits(compiles, __traits(getMember, API,

{OT} Youtube video: finding an eliusive bug with CTFE

Hi Guys, while building newCTFE is ran into a really nasty bug. Which took me hours to find, but with CTFE and __traits it is preventable and will never haunt me again. Because I was so happy that I could prevent this bug; I want to share it with the whole world:

Re: Dlang Features You Would Like To Share

On Wednesday, 12 April 2017 at 21:40:48 UTC, bluecat wrote: What are some features that you have discovered that you would like to share with the community? For me, one thing I found interesting was the ability to define structures dynamically using mixins: import std.stdio; import

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Comma expressions should now work.

Re: CTFE Status 2

On Wednesday, 12 April 2017 at 09:19:39 UTC, Stefan Koch wrote: On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] I just found more states we get into, that should be impossible to ever get into. I am stumped. Baffled. And seriously befuddled! So .. this is

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] I just fixed the static assert((null ~ null) is null); Hence I can now enable string-concat!

Re: ctfe append too slow, but can't speed up

On Tuesday, 11 April 2017 at 02:20:37 UTC, Jethro wrote: ctfe string appending is way to slow, I have tried the suggested methods and nothing works and slows down by at least an order of magnitude. I need a drop in replacement(no other changes) that can take over the duties of string and

Re: CTFE using of replaceAll from std.regex posible?

On Wednesday, 12 April 2017 at 12:00:27 UTC, Martin Tschierschke wrote: It there a way to use "replaceAll" at compile time? Regards mt. Not yet :) I assume it would bring the current system to it's needs. I you want to experiment you could replace malloc with new.

Re: The New CTFE Engine on the Blog

On Wednesday, 12 April 2017 at 05:51:20 UTC, Ali Çehreli wrote: On 04/10/2017 06:07 AM, Mike Parker wrote: Stefan has been diligently keeping us all updated on NewCTFE here in the forums. Now, he's gone to the blog to say something to tell the world about it. The blog:

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] I just found more states we get into, that should be impossible to ever get into. I am stumped. Baffled. And seriously befuddled!

Re: Thoughts from newcommer

On Tuesday, 11 April 2017 at 19:57:19 UTC, Piotr Kowalski wrote: Hello D community, I am language polyglot that lately got interested in D. I love it, it's very elegant language, so simple and so powerful same time. I will write some thoughts as outsider. The reason I am looking at D in

Re: CTFE Status 2

On Monday, 10 April 2017 at 20:49:58 UTC, Stefan Koch wrote: On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Hi Guys :) I am currently fixing a bug involving complex members of structs (where complex means (slice, struct, array or pointer)) I did expect them to be

{OT} Youtube video small tutorial to work with newCTFE's IR

Hi Guys, I have uploaded a video showing howto implement pow in newCTFE's IR. I hope that this is of interest to some of you :) Cheers, Stefan

Re: CTFE Status 2

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Hi Guys :) I am currently fixing a bug involving complex members of structs (where complex means (slice, struct, array or pointer)) I did expect them to be broken ... but not to be _that_ broken :) struct S {

Re: The D ecosystem in Debian with free-as-in-freedom DMD

On Monday, 10 April 2017 at 15:11:01 UTC, Jack Stouffer wrote: On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote: 3) Will DMD support more architectures in the near future? How should the architecture issue be handled? This can be definitively answered as "no",

Re: Strange CTFE issue, string replacement

On Sunday, 9 April 2017 at 20:20:55 UTC, Jethro wrote: On Sunday, 9 April 2017 at 19:55:57 UTC, Stefan Koch wrote: On Sunday, 9 April 2017 at 19:38:33 UTC, Jethro wrote: [...] The constructor is nuts. You do not need to zero the string! Also avoid templates if you can. Please don't

Re: Strange CTFE issue, string replacement

On Sunday, 9 April 2017 at 19:38:33 UTC, Jethro wrote: I tried to make a string like replacement called fstring which uses buffering to avoid lots of little allocations. The problem is, that it actually causes the compiler to use 10x the memory and about 10 times slower. It doesn't do

Re: -fPIC and 32-bit dmd.conf settings

On Sunday, 9 April 2017 at 09:23:07 UTC, Joseph Rushton Wakeling wrote: Thanks for the explanation. TBH I find myself wondering whether `-fPIC` should be in the flags defined in dmd.conf _at all_ (even for 64-bit environments); surely that should be on request of individual project builds

<    1   2   3   4   5   6   7   8   9   10   >