Re: For Inspiration: arena-based, quad-color incremental, generational, non-copying, high-speed, cache-optimized garbage collector

On Sunday, 4 February 2018 at 08:41:04 UTC, rikki cattermole wrote: Single threaded simplifies a lot. So no, not useful. Useful for server applications that more often than not have independent threads.

Re: Annoyance with new integer promotion deprecations

On Monday, 5 February 2018 at 23:18:58 UTC, Timon Gehr wrote: On 05.02.2018 22:56, Walter Bright wrote: It's necessary. Working C expressions cannot be converted to D while introducing subtle changes in behavior. ... Neither byte nor dchar are C types. The idea is a byte can be implicitly

Re: Annoyance with new integer promotion deprecations

On Monday, 5 February 2018 at 21:38:23 UTC, Simen Kjærås wrote: If you were negating a byte, the code does have compile-time known values, since there's a limit to what you can stuff into a byte. If you weren't, the warning is warranted. I will admit the case of -(-128) could throw it off, thou

Re: Annoyance with new integer promotion deprecations

On Tuesday, 6 February 2018 at 07:18:59 UTC, Walter Bright wrote: Except for 16 bit shorts. Shorts will exact a penalty :-) and so shorts should only be used for data packing purposes. Which CPU model are you thinking of?

Re: Language Idea #6892: in array ops, enable mixing slices and random access ranges

On Tuesday, 6 February 2018 at 02:14:35 UTC, Meta wrote: What do you think? It's already possible, with only very slightly worse aesthetics: [Good stuff] We can do better than that, though: import std.range, std.array, std.algorithm; struct Vec(Range) if (isInputRange!Range) { Range rn

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On Monday, 5 February 2018 at 20:12:09 UTC, Walter Bright wrote: On 2/5/2018 12:06 AM, Boris-Barboris wrote: I think that would be most logical thing to have, but that would also imply preprocessor, or at least it's restricted subset, wich you most probably though about as well. Sure. I could

Re: Thread safe reference counting

On Saturday, 3 February 2018 at 14:41:06 UTC, Kagamin wrote: That RCSharedAllocator PR made me think, so this is my take on how to keep reference counted allocator in shared storage: https://run.dlang.io/is/r1z1dd You might also want to look at Atila Neves's automem package. It uses atomic in

!Alert! dlang.org SSL Error

Chromium: ERR_SSL_PROTOCOL_ERROR With Firefox and Chomium and with different Ubuntu Versions (17.10 and 16.04.) Firefox - Google translated: Error: Secure connection failed An error occurred while connecting to dlang.org. SSL has received an entry that has exceeded the maximum allowed lengt

Re: Annoyance with new integer promotion deprecations

On Tuesday, 6 February 2018 at 07:15:33 UTC, Walter Bright wrote: The thing is, when there are mixed integer sizes and signedness, there is no intuitive and correct solution. Each set of rules comes with its own set of cases where there are unintuitive behaviors. So, why doing any promotion at

Re: Language Idea #6892: in array ops, enable mixing slices and random access ranges

On Tuesday, 6 February 2018 at 09:02:46 UTC, Simen Kjærås wrote: On Tuesday, 6 February 2018 at 02:14:35 UTC, Meta wrote: What do you think? It's already possible, with only very slightly worse aesthetics: [Good stuff] We can do better than that, though: [More good stuff] The problem i

Re: Language Idea #6892: in array ops, enable mixing slices and random access ranges

On Tuesday, 6 February 2018 at 02:14:35 UTC, Meta wrote: It's already possible, with only very slightly worse aesthetics: struct VecOp(T) { T[] arr; pragma(inline, true) T[] opOpAssign(string op: "+", Range)(Range r) { int i; foreach (e; r) {

Re: Language Idea #6892: in array ops, enable mixing slices and random access ranges

On Tuesday, 6 February 2018 at 12:13:22 UTC, Guillaume Piolat wrote: On Tuesday, 6 February 2018 at 09:02:46 UTC, Simen Kjærås wrote: On Tuesday, 6 February 2018 at 02:14:35 UTC, Meta wrote: What do you think? It's already possible, with only very slightly worse aesthetics: [Good stuff]

Re: !Alert! dlang.org SSL Error

On Tuesday, 6 February 2018 at 10:05:52 UTC, Martin Tschierschke wrote: Chromium: ERR_SSL_PROTOCOL_ERROR With Firefox and Chomium and with different Ubuntu Versions (17.10 and 16.04.) Firefox - Google translated: Error: Secure connection failed An error occurred while connecting to dlang.or

Re: !Alert! dlang.org SSL Error

On Tuesday, 6 February 2018 at 13:18:26 UTC, Jakub Łabaj wrote: On Tuesday, 6 February 2018 at 10:05:52 UTC, Martin Tschierschke wrote: Chromium: ERR_SSL_PROTOCOL_ERROR With Firefox and Chomium and with different Ubuntu Versions (17.10 and 16.04.) Firefox - Google translated: Error: Secure

Re: !Alert! dlang.org SSL Error

On Tuesday, 6 February 2018 at 13:31:23 UTC, Seb wrote: On Tuesday, 6 February 2018 at 13:18:26 UTC, Jakub Łabaj wrote: On Tuesday, 6 February 2018 at 10:05:52 UTC, Martin Tschierschke wrote: Chromium: ERR_SSL_PROTOCOL_ERROR [...] Please contact the owner of the website to inform him of this

Re: !Alert! dlang.org SSL Error

On Tuesday, 6 February 2018 at 13:42:18 UTC, Martin Tschierschke wrote: Please contact the owner of the website to inform him of this issue. Same for me. I don't have any issues on my machine with Chrome and Firefox.. Hmm, my phone with chrome on android7 and chrome on ipad2 no problems,too

Re: Bye bye, fast compilation times

On Tuesday, 6 February 2018 at 06:11:55 UTC, Dmitry Olshansky wrote: On Tuesday, 6 February 2018 at 05:45:35 UTC, Steven Schveighoffer wrote: On 2/6/18 12:35 AM, Dmitry Olshansky wrote: That’s really bad idea - isEmail is template so the burden of freaking slow ctRegex is paid on per instanti

Re: Bye bye, fast compilation times

On Tuesday, 6 February 2018 at 13:51:01 UTC, Nathan S. wrote: Just use the run-time version, it’s not that much slower. But then again static ipRegex = regex(...) will parse and build regex at CTFE. Maybe lazy init? FYI I've made a pull request that replaces uses of regexes in std.net.isema

Re: !Alert! dlang.org SSL Error

On Tuesday, 6 February 2018 at 13:45:20 UTC, Martin Tschierschke wrote: On Tuesday, 6 February 2018 at 13:42:18 UTC, Martin Tschierschke wrote: Please contact the owner of the website to inform him of this issue. Same for me. I don't have any issues on my machine with Chrome and Firefox..

Re: !Alert! dlang.org SSL Error

On Tuesday, 6 February 2018 at 13:42:18 UTC, Martin Tschierschke wrote: On Tuesday, 6 February 2018 at 13:31:23 UTC, Seb wrote: On Tuesday, 6 February 2018 at 13:18:26 UTC, Jakub Łabaj wrote: On Tuesday, 6 February 2018 at 10:05:52 UTC, Martin Tschierschke wrote: Chromium: ERR_SSL_PROTOCOL_ERR

Re: !Alert! dlang.org SSL Error

On Tuesday, 6 February 2018 at 14:05:46 UTC, Seb wrote: Vladimir already did so an hour ago. Though his web presence is blank for me at the moment: https://www.janknepper.com Works for me again.

Re: !Alert! dlang.org SSL Error

On Tuesday, 6 February 2018 at 14:32:41 UTC, Jakub Łabaj wrote: On Tuesday, 6 February 2018 at 14:05:46 UTC, Seb wrote: Vladimir already did so an hour ago. Though his web presence is blank for me at the moment: https://www.janknepper.com Works for me again. I also had this happen yesterda

Re: !Alert! dlang.org SSL Error

On 02/06/2018 09:05 AM, Seb wrote: On Tuesday, 6 February 2018 at 13:42:18 UTC, Martin Tschierschke wrote: On Tuesday, 6 February 2018 at 13:31:23 UTC, Seb wrote: On Tuesday, 6 February 2018 at 13:18:26 UTC, Jakub Łabaj wrote: On Tuesday, 6 February 2018 at 10:05:52 UTC, Martin Tschierschke wr

Re: Annoyance with new integer promotion deprecations

On Tue, Feb 06, 2018 at 10:43:39AM +, Dominikus Dittes Scherkl via Digitalmars-d wrote: [...] > Every type should have a NAN value. For the signed types the extra > useless .min is a perfect candidate for a NAN. That allows -x to > always be of the same type as x, which I think is a good thi

Re: !Alert! dlang.org SSL Error

On 02/06/2018 09:40 AM, Simen Kjærås wrote: On Tuesday, 6 February 2018 at 14:32:41 UTC, Jakub Łabaj wrote: On Tuesday, 6 February 2018 at 14:05:46 UTC, Seb wrote: Vladimir already did so an hour ago. Though his web presence is blank for me at the moment: https://www.janknepper.com Works fo

Re: Quora: Why hasn't D started to replace C++?

On 01/31/2018 10:01 PM, Walter Bright wrote: On 1/31/2018 6:14 PM, Jonathan M Davis wrote: I have to wonder if my settings are right. I've never noticed any color in error messages. Messing around with some errors right now, the only color I see is that "Error:" is in red, and some of the text

Re: Annoyance with new integer promotion deprecations

On Mon, Feb 05, 2018 at 11:18:59PM -0800, Walter Bright via Digitalmars-d wrote: [...] > Except for 16 bit shorts. Shorts will exact a penalty :-) and so > shorts should only be used for data packing purposes. Really?! How so? T -- Talk is cheap. Whining is actually free. -- Lars Wirzenius

Book - Art of community

A good book that I came across - http://www.artofcommunityonline.org/

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On Monday, 5 February 2018 at 22:56:47 UTC, Jonathan M Davis wrote: On Monday, February 05, 2018 18:54:32 John Gabriele via Digitalmars-d wrote: What is the specific purpose of -betterC? I see from that it's (A) useful when targeting constrained environment

Re: !Alert! dlang.org SSL Error

On Tuesday, 6 February 2018 at 14:57:27 UTC, Jan Knepper wrote: [...] Will keep an eye on it. Everybody else who hits the website regularly who experiences the problem, please report ASAP. Thanks! Jan Thank you, no SSL error! But some missing text: In the News section: Stay updated with

-libpath?

What do people think of adding an argument to DMD to add library search paths? Currently the only way I know how to do this would be via linker-specific flags, i.e. GCC: -L-L/usr/lib MSVC: -L-libpath:C:\mylibs OPTLINK: -L+C:\mylibs\ NOTE: the optlink version only works if no .def file is spe

Re: !Alert! dlang.org SSL Error

On Tuesday, 6 February 2018 at 17:42:04 UTC, Martin Tschierschke wrote: On Tuesday, 6 February 2018 at 14:57:27 UTC, Jan Knepper wrote: [...] Will keep an eye on it. Everybody else who hits the website regularly who experiences the problem, please report ASAP. Thanks! Jan Thank you, no SSL e

Re: Bye bye, fast compilation times

On Tue, Feb 06, 2018 at 05:44:17AM +, Dmitry Olshansky via Digitalmars-d wrote: [...] > Honestly I’m tired to hell of working with our compiler and its > compile time features. When it doesn’t pee itself due to OOM I’m > almost happy. Heh, dmd's famous memory usage is causing me tons of grief

Re: Bye bye, fast compilation times

On Tue, Feb 06, 2018 at 05:35:44AM +, Dmitry Olshansky via Digitalmars-d wrote: > On Tuesday, 6 February 2018 at 04:35:42 UTC, Steven Schveighoffer wrote: > > On 2/5/18 11:09 PM, psychoticRabbit wrote: [...] > > > > > > import std.net.isemail; > > > > > > void main() > > > { > > >     a

Re: Bye bye, fast compilation times

On 2/6/18 2:07 PM, H. S. Teoh wrote: I'm not sure I'm seeing the value of using ctRegex here. What's wrong with a module static runtime regex initialized by a static this()? No, I'd rather have it initialized on first call. And before anyone complains about initializing the regex if user co

Re: Bye bye, fast compilation times

On 2/5/2018 9:35 PM, Dmitry Olshansky wrote: That’s really bad idea - isEmail is template so the burden of freaking slow ctRegex is paid on per instantiation basis. Could be horrible with separate compilation. std.string.isEmail() in D1 was a simple function. Maybe regex is just the wrong sol

Re: Annoyance with new integer promotion deprecations

On 2/5/2018 10:08 PM, H. S. Teoh wrote: IMO, we should extend this past just one statement. It would lead to more possibilities for optimizations and possibly other features too. Though I understand that Walter has reservations about doing this for some reason. What you're asking for is data fl

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote: I am sure there will be lots of opinions regarding this post but its suffice to say that my decision to go with Go ( no pun intended ) is finally. I hope this final post is some indication of the issues that have plagued my decision proce

Re: Bye bye, fast compilation times

On 2/6/18 3:11 PM, Walter Bright wrote: On 2/5/2018 9:35 PM, Dmitry Olshansky wrote: That’s really bad idea - isEmail is template so the burden of freaking slow ctRegex is paid on per instantiation basis. Could be horrible with separate compilation. std.string.isEmail() in D1 was a simple fun

cast overly permissive with extern(C++ ) classes; should cast through `void*`

should we force force casting through `void*` for extern(C++) classes ? i.e. `cast(Derived) cast(void*) base_instance;` currently, `cast(A) unrelad_cpp_instance` happily compiles but shouldn't, it's very error prone even though the cast syntax suggests type safety; especially a problem if we make

Re: Bye bye, fast compilation times

another weird gotcha: auto s="foo".isEmail; writeln(s.toString); // ok writeln(s); // compile error On Tue, Feb 6, 2018 at 12:30 PM, Steven Schveighoffer via Digitalmars-d wrote: > On 2/6/18 3:11 PM, Walter Bright wrote: >> >> On 2/5/2018 9:35 PM, Dmitry Olshansky wrote: >>> >>> That’s rea

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster wrote: The opencl package in dub is a crude wrapper around the original C API. I couldn't find any sha lib, so I've started porting a reference sha3 implementation from C. Don't port libraries like that, just call them directly. Por

Re: cast overly permissive with extern(C++ ) classes; should cast through `void*`

On Tuesday, 6 February 2018 at 20:39:09 UTC, Timothee Cour wrote: should we force force casting through `void*` for extern(C++) classes ? i.e. `cast(Derived) cast(void*) base_instance;` currently, `cast(A) unrelad_cpp_instance` happily compiles but shouldn't, it's very error prone even though

Re: Casts

On Wednesday, 22 October 2008 at 18:43:15 UTC, Denis Koroskin wrote: On Wed, 22 Oct 2008 22:39:10 +0400, bearophile wrote: [...] You can use the following short-cut to avoid double casting: if (auto foo = cast(Foo)obj) { ... } else if (auto bar = cast(Bar)bar) { ... } else { ..

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On Tue, Feb 06, 2018 at 08:55:31PM +, Adam D. Ruppe via Digitalmars-d wrote: > On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster wrote: > > The opencl package in dub is a crude wrapper around the original C > > API. I couldn't find any sha lib, so I've started porting a > > referenc

Re: cast overly permissive with extern(C++ ) classes; should cast through `void*`

On Tuesday, 6 February 2018 at 21:13:50 UTC, timotheecour wrote: On Tuesday, 6 February 2018 at 20:39:09 UTC, Timothee Cour wrote: should we force force casting through `void*` for extern(C++) classes ? i.e. `cast(Derived) cast(void*) base_instance;` currently, `cast(A) unrelad_cpp_instance` h

Re: Casts

On 2/6/18 4:16 PM, timotheecour wrote: On Wednesday, 22 October 2008 at 18:43:15 UTC, Denis Koroskin wrote: On Wed, 22 Oct 2008 22:39:10 +0400, bearophile wrote: [...] You can use the following short-cut to avoid double casting: if (auto foo = cast(Foo)obj) {     ... } else if (auto bar =

Re: Casts

On Tuesday, 6 February 2018 at 21:35:11 UTC, Steven Schveighoffer wrote: On 2/6/18 4:16 PM, timotheecour wrote: On Wednesday, 22 October 2008 at 18:43:15 UTC, Denis Koroskin wrote: On Wed, 22 Oct 2008 22:39:10 +0400, bearophile wrote: [...] You can use the following short-cut to avoid dou

Re: Casts

On Tuesday, 6 February 2018 at 21:41:14 UTC, Jonathan Marler wrote: Lol, I did the same thing once...I think I may have clicked a link on an old thread, and when I went back to the "page view" it must have gone back to the "page view" where the original thread was listed. I saw an interesti

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On Tuesday, 6 February 2018 at 20:55:31 UTC, Adam D. Ruppe wrote: On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster wrote: The opencl package in dub is a crude wrapper around the original C API. I couldn't find any sha lib, so I've started porting a reference sha3 implementation fro

Re: Casts

well even old threads are useful to update when there's new information ; because they show up in search results so good to keep answers up to date (and provide link to newer info) On Tue, Feb 6, 2018 at 1:44 PM, jmh530 via Digitalmars-d wrote: > On Tuesday, 6 February 2018 at 21:41:14 UTC, Jona

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On Tuesday, February 06, 2018 21:44:16 Ralph Doncaster via Digitalmars-d wrote: > One reason I considered porting was to > see if dmd outputs better code than gcc. It almost certainly won't. dmd compiles code lightning fast and has a decent optimizer, but it's really not on par with gcc or llvm's

Re: Bye bye, fast compilation times

On 2018-02-06 21:11, Walter Bright wrote: std.string.isEmail() in D1 was a simple function. Maybe regex is just the wrong solution for this problem. If I recall correctly, the current implementation of std.net.isEmail was requested by you. -- /Jacob Carlborg

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On 2018-02-06 10:51, Atila Neves wrote: I tried Warp on a non-trivial C codebase. It didn't work (by which I mean the code wouldn't compile with it). I don't know how clang managed to build a (for all practical purposes I can see) bug-compatible preprocessor from scratch to gcc, but it did and

Re: Bye bye, fast compilation times

On 2/6/2018 2:03 PM, Jacob Carlborg wrote: On 2018-02-06 21:11, Walter Bright wrote: std.string.isEmail() in D1 was a simple function. Maybe regex is just the wrong solution for this problem. If I recall correctly, the current implementation of std.net.isEmail was requested by you. Regardl

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On Tuesday, 6 February 2018 at 21:44:16 UTC, Ralph Doncaster wrote: Is there an automatic way to make D wrappers for all the C function calls? https://github.com/jacob-carlborg/dstep

Re: Bye bye, fast compilation times

On 2/6/2018 12:30 PM, Steven Schveighoffer wrote: The regex in question I think is to ensure an email address like abc@192.168.0.5 has a valid IP address. The D1 function doesn't support that requirement. I admit, I've never used it, so I don't know why it needs to be so complex. But I assume

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On Tue, Feb 06, 2018 at 09:44:16PM +, Ralph Doncaster via Digitalmars-d wrote: [...] > Although I'm new to D, I do know crypto quite well, and especially > sha3/keccak. One reason I considered porting was to see if dmd outputs > better code than gcc. On x86_64 with the xmm registers there is

Re: Bye bye, fast compilation times

On Tue, Feb 06, 2018 at 02:29:07PM -0800, Walter Bright via Digitalmars-d wrote: > On 2/6/2018 12:30 PM, Steven Schveighoffer wrote: > > The regex in question I think is to ensure an email address like > > abc@192.168.0.5 has a valid IP address. The D1 function doesn't > > support that requirement.

Re: Annoyance with new integer promotion deprecations

On Monday, 5 February 2018 at 23:56:51 UTC, Adam D. Ruppe wrote: 1) Given: byte a, b; byte c = a + b; The cast seems a bit silly: you are already explicitly using `byte` everywhere, so your intention is pretty clear: you only want to use the bytes and are ok with the rest of it being

Re: cast overly permissive with extern(C++ ) classes; should cast through `void*`

On Tuesday, 6 February 2018 at 21:34:07 UTC, timotheecour wrote: On Tuesday, 6 February 2018 at 21:13:50 UTC, timotheecour wrote: [...] Actually how about introducing a library solution for explicit casting: * works with UFCS chains (unlike cast) * DSL is very intuitive, readable and extens

Re: Bye bye, fast compilation times

On 2/6/18 5:23 PM, Walter Bright wrote: On 2/6/2018 2:03 PM, Jacob Carlborg wrote: On 2018-02-06 21:11, Walter Bright wrote: std.string.isEmail() in D1 was a simple function. Maybe regex is just the wrong solution for this problem. If I recall correctly, the current implementation of std.net

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On Monday, 5 February 2018 at 22:02:09 UTC, Boris-Barboris wrote: Oh, and look what I just found: https://github.com/rust-lang/rust/issues/26179 Oh, look: https://github.com/ldc-developers/druntime/blob/7b77937c70b4aba720e98727dcaad3323c29bd8d/src/ldc/intrinsics.di#L579-L587 — David

Re: cast overly permissive with extern(C++ ) classes; should cast through `void*`

> Like assumeUnique? https://dlang.org/library/std/exception/assume_unique.html what do you mean? u mean adding "unique" to the DSL list ? maybe! * for cast on extern C++ classes, why not use the same logic as what C++ uses for dynamic_cast? (simplified because we don't support multople inherita

Re: cast overly permissive with extern(C++ ) classes; should cast through `void*`

On Tuesday, 6 February 2018 at 23:15:07 UTC, Timothee Cour wrote: Like assumeUnique? https://dlang.org/library/std/exception/assume_unique.html what do you mean? u mean adding "unique" to the DSL list ? maybe! You asked: Actually how about introducing a library solution for explicit castin

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On Tuesday, 6 February 2018 at 23:08:48 UTC, David Nadlinger wrote: On Monday, 5 February 2018 at 22:02:09 UTC, Boris-Barboris wrote: Oh, and look what I just found: https://github.com/rust-lang/rust/issues/26179 Oh, look: https://github.com/ldc-developers/druntime/blob/7b77937c70b4aba720e987

Re: Bye bye, fast compilation times

On Tuesday, 6 February 2018 at 22:51:51 UTC, Steven Schveighoffer wrote: On 2/6/18 5:23 PM, Walter Bright wrote: On 2/6/2018 2:03 PM, Jacob Carlborg wrote: On 2018-02-06 21:11, Walter Bright wrote: std.string.isEmail() in D1 was a simple function. Maybe regex is just the wrong solution for th

Re: cast overly permissive with extern(C++ ) classes; should cast through `void*`

assumeUnique has a very specific use case; i was describing a more general way to handle various types of cast (and be explicit about whats allowed) as mentioned above On Tue, Feb 6, 2018 at 3:18 PM, Seb via Digitalmars-d wrote: > On Tuesday, 6 February 2018 at 23:15:07 UTC, Timothee Cour wrote:

Re: cast overly permissive with extern(C++ ) classes; should cast through `void*`

but yes, API would look similar: auto Cast(T)(T a) if(...) {} auto Cast(string dsl)(T a) {} On Tue, Feb 6, 2018 at 3:31 PM, Timothee Cour wrote: > assumeUnique has a very specific use case; i was describing a more > general way to handle various types of cast (and be explicit about > whats allow

Re: Bye bye, fast compilation times

On 02/06/2018 01:11 AM, Dmitry Olshansky wrote: On Tuesday, 6 February 2018 at 05:45:35 UTC, Steven Schveighoffer wrote: On 2/6/18 12:35 AM, Dmitry Olshansky wrote: That’s really bad idea - isEmail is template so the burden of freaking slow ctRegex is paid on per instantiation basis. Could be

Re: Annoyance with new integer promotion deprecations

On 02/06/2018 01:22 AM, H. S. Teoh wrote: No need to wait for the future, you can do this today: enum toStr(alias X) = X.stringof; enum x = 100; pragma(msg, toStr!1); pragma(msg, toStr!3.14159); pragma(msg, "Hello " ~ toStr!10 ~ " world"); pragma

Re: Annoyance with new integer promotion deprecations

On Wednesday, 7 February 2018 at 00:00:05 UTC, Nick Sabalausky (Abscissa) wrote: //pragma(msg, 3.14159.text); // Ugh, ok, floats don't work though :( So I saw a stb_sprintf with a from-scratch impl, including floats, public domain. Someone on IRC was thinking about porting it. Maybe we shou

Re: Annoyance with new integer promotion deprecations

On Wed, Feb 07, 2018 at 12:10:14AM +, Adam D. Ruppe via Digitalmars-d wrote: > On Wednesday, 7 February 2018 at 00:00:05 UTC, Nick Sabalausky (Abscissa) > wrote: > > //pragma(msg, 3.14159.text); // Ugh, ok, floats don't work though :( > > So I saw a stb_sprintf with a from-scratch impl, includ

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On Tuesday, 6 February 2018 at 21:44:16 UTC, Ralph Doncaster wrote: Is there an automatic way to make D wrappers for all the C function calls? Yeah, I hear the dstep https://github.com/jacob-carlborg/dstep works well, though I haven't personally used it - I just bring in C functions by hand a

Re: Annoyance with new integer promotion deprecations

On Tue, Feb 06, 2018 at 12:23:02PM -0800, Walter Bright via Digitalmars-d wrote: > On 2/5/2018 10:08 PM, H. S. Teoh wrote: > > IMO, we should extend this past just one statement. It would lead to > > more possibilities for optimizations and possibly other features > > too. Though I understand that

Re: Annoyance with new integer promotion deprecations

On Tue, Feb 06, 2018 at 10:38:36PM +, Luís Marques via Digitalmars-d wrote: [...] > Yeah, it's annoying. For my MSP430 work (16-bit, lots of shorts and > bytes) I created a generic type which works around this, so you would > do: > > byte c = a.nx + b; > > where .nx means "non-extending" and

Re: Bye bye, fast compilation times

On Tue, Feb 06, 2018 at 11:20:53PM +, Andres Clari via Digitalmars-d wrote: [...] > Switching from ctRegex! to regex yielded a 50% build time reduction, > and from what I read even the normal regex are slowing things down > considerably. I seem to vaguely recall that in some cases, ctRegex mig

Re: Annoyance with new integer promotion deprecations

On Wednesday, 7 February 2018 at 00:24:26 UTC, H. S. Teoh wrote: I really like your .nx idea! It neatly sidesteps the nonsensical mandatory casts and on top of that documents intent (the .nx being a telltale sign of truncation -- much better than arbitrary implicit rules). I think I'll adopt

Re: cast overly permissive with extern(C++ ) classes; should cast through `void*`

On Tuesday, 6 February 2018 at 23:32:49 UTC, Timothee Cour wrote: but yes, API would look similar: auto Cast(T)(T a) if(...) {} auto Cast(string dsl)(T a) {} Ah I see. I think this is already partially done in Phobos (which shows the usefulness): https://github.com/dlang/phobos/blob/master/

Re: Bye bye, fast compilation times

On Wednesday, 7 February 2018 at 00:36:22 UTC, H. S. Teoh wrote: On Tue, Feb 06, 2018 at 11:20:53PM +, Andres Clari via Digitalmars-d wrote: [...] [...] I seem to vaguely recall that in some cases, ctRegex might even perform slower than regex(). But either way, my use cases for regexes

Re: cast overly permissive with extern(C++ ) classes; should cast through `void*`

ugh... dynamicCast is private... On Tue, Feb 6, 2018 at 5:13 PM, Seb via Digitalmars-d wrote: > On Tuesday, 6 February 2018 at 23:32:49 UTC, Timothee Cour wrote: >> >> but yes, API would look similar: >> >> auto Cast(T)(T a) if(...) {} >> auto Cast(string dsl)(T a) {} > > > Ah I see. > I think th

Re: Bye bye, fast compilation times

On Mon, Feb 05, 2018 at 01:27:57PM -0800, H. S. Teoh via Digitalmars-d wrote: > One of my D projects for the past while has been taking unusually long > times to compile. This morning, I finally decided to sit down and > figure out exactly why. [...] I don't want this thread to turn into ragging

Re: Bye bye, fast compilation times

On Wed, Feb 07, 2018 at 01:22:02AM +, Andres Clari via Digitalmars-d wrote: [...] > Is there some tutorial or example for using SCons with dub > dependencies? Not that I know of. Basically what I did was: - Create a dummy dub project in a subdirectory, containing a dummy source file contai

Re: Bye bye, fast compilation times

On Wednesday, 7 February 2018 at 01:20:04 UTC, H. S. Teoh wrote: So I'd like to propose that we do something similar to what we did with template instantiations a couple of years ago: make it so that unittests are only instantiated if the module they occur in is being compiled, otherwise ignore

Re: Bye bye, fast compilation times

On Tuesday, February 06, 2018 17:20:04 H. S. Teoh via Digitalmars-d wrote: > So I'd like to propose that we do something similar to what we did with > template instantiations a couple of years ago: make it so that unittests > are only instantiated if the module they occur in is being compiled, > ot

Re: Bye bye, fast compilation times

On Wednesday, February 07, 2018 01:47:19 jmh530 via Digitalmars-d wrote: > On Wednesday, 7 February 2018 at 01:20:04 UTC, H. S. Teoh wrote: > > So I'd like to propose that we do something similar to what we > > did with template instantiations a couple of years ago: make it > > so that unittests ar

Re: Bye bye, fast compilation times

On Tuesday, 6 February 2018 at 20:11:56 UTC, Walter Bright wrote: std.string.isEmail() in D1 was a simple function. Maybe regex is just the wrong solution for this problem. [...] C .. D style. I love it! (bugs and all).

Re: Bye bye, fast compilation times

how about using same syntax (and reusing logic) as newly introduced: ` -i=+foo.bar,+baz-baz.bad` `dmd -unittest=+foo.bar,+baz,-baz.bad rest_of_arguments` which would only enable unittests as specified? It's flexible and intuitive On Tue, Feb 6, 2018 at 5:56 PM, Jonathan M Davis via Digitalmars-d

Re: Annoyance with new integer promotion deprecations

On Monday, 5 February 2018 at 20:45:22 UTC, H. S. Teoh wrote: On Mon, Feb 05, 2018 at 03:23:20PM -0500, Steven Schveighoffer via Digitalmars-d wrote: On 2/5/18 2:30 PM, H. S. Teoh wrote: > Even better yet: > > byte b; >b = -b; // Deprecation error > > WAT In the future, -b

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On Tuesday, 6 February 2018 at 23:08:48 UTC, David Nadlinger wrote: Oh, look: https://github.com/ldc-developers/druntime/blob/7b77937c70b4aba720e98727dcaad3323c29bd8d/src/ldc/intrinsics.di#L579-L587 — David Not gcc, no platforms, BEBEBEBEBEBE. On the serious note: nice, good to see.

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On Tuesday, 6 February 2018 at 23:08:48 UTC, David Nadlinger wrote: Apparently, GDC folks do not populate builtin module, so there's no easy way to look check it, besides actually trying to compile: https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/builtins.d#L24

Re: Bye bye, fast compilation times

On 2/6/2018 2:51 PM, Steven Schveighoffer wrote: The regex problem is being solved: https://github.com/dlang/phobos/pull/6129 Great!

#dbugfix Issue 2043

https://issues.dlang.org/show_bug.cgi?id=2043 It's a really old bug, and top-voted in bugzilla according to https://issues.dlang.org/buglist.cgi?bug_status=__open__&columnlist=component%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Cvotes&list_id=218657&order=votes%20DESC%2Cpriority%2Cbu

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

On Wednesday, 7 February 2018 at 06:29:01 UTC, Boris-Barboris wrote: On Tuesday, 6 February 2018 at 23:08:48 UTC, David Nadlinger wrote: Apparently, GDC folks do not populate builtin module, so there's no easy way to look check it, besides actually trying to compile: https://github.com/D-P

Re: #dbugfix Issue 2043

On Wednesday, 7 February 2018 at 07:15:36 UTC, Mike Franklin wrote: https://issues.dlang.org/show_bug.cgi?id=2043 It's a really old bug, and top-voted in bugzilla according to https://issues.dlang.org/buglist.cgi?bug_status=__open__&columnlist=component%2Cbug_status%2Cresolution%2Cshort_desc%2C