Re: Best way for handle missing args in REST interface in vibed

I wrote next code: void foo(string _error = null) { writeln("Error"); } override: @errorDisplay!foo Json doTrackSpeedAnalyze(int trackid, string startDateTime, string endDateTime) // /api/mytrack?trackid=123=2000=2010 {

Re: purity question

On Monday, 29 May 2017 at 08:49:07 UTC, ketmar wrote: Brad Roberts wrote: libraries that themselves aren't marked pure, there's a real need for escape hatches. A simple example: anything that has a malloc/free pair. they aren't pure. it is a sad misconception about purity, which D makes

Re: purity question

Ola Fosheim Grøstad wrote: On Monday, 29 May 2017 at 08:49:07 UTC, ketmar wrote: pure. and while various functions in std.math, for example, are marked `pure`, they aren't too. Out of curiosity, which functions in std.math aren't "pure" in the D sense? almost all of them, 'cause they

Best way for handle missing args in REST interface in vibed

I am doing REST interface with vibed. And thinking about handling errors, if users forgot to pass all expected args in function. For example: foo(int x, int y) // get request { } /api/foo?x=111 And if user is forgot to pass `y` we will get error in the browser. What is the right way to

Re: Best way for handle missing args in REST interface in vibed

On Monday, 29 May 2017 at 12:23:59 UTC, Suliman wrote: I am doing REST interface with vibed. And thinking about handling errors, if users forgot to pass all expected args in function. For example: foo(int x, int y) // get request { } /api/foo?x=111 And if user is forgot to pass `y` we will

Re: purity question

On Monday, 29 May 2017 at 11:25:06 UTC, ketmar wrote: almost all of them, 'cause they depends on FPU rounding settings. Well, yeah. IIRC contemporary floating point machine language instructions allow embedding of rounding mode into the instruction. A pity languages are lagging behind,

Re: Built-in RAII in D

On Monday, 29 May 2017 at 11:06:20 UTC, Ola Fosheim Grøstad wrote: One fun tutorial would be to integrate with a tedious C++ framework and let the GC take care of allocations in C++ code where speed doesn't matter. Then write a C++ integration tutorial around it. That could be a selling

Re: Built-in RAII in D

On Monday, 29 May 2017 at 11:58:56 UTC, evilrat wrote: Can't sell to those who don't buy. I can't say for all, but I have noticed that those who generally use C++ will tell that speed matters "everywhere" (oh right, they do use C++ "for a reason") Well, I am in that C++ group... So yes, you

[Issue 17450] escaping delegate context pointer not detected for member functions

https://issues.dlang.org/show_bug.cgi?id=17450 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/e3e8ce24b0ca5b0aa0f300da854fef439973df03 fix Issue 17450 - escaping delegate context pointer not

Re: Best way for handle missing args in REST interface in vibed

On Monday, 29 May 2017 at 12:23:59 UTC, Suliman wrote: I am doing REST interface with vibed. And thinking about handling errors, if users forgot to pass all expected args in function. For example: foo(int x, int y) // get request { } /api/foo?x=111 And if user is forgot to pass `y` we will

A Few thoughts on C, C++, and D

A few thoughts not entirely random but without a well thought out storyline, prompted by a couple of recent threads here. I like the comment from DConf that D should be the successor to Vala for writing GObject-based code. We have GtkD and in it GStreamer. Writing programs in C with them is a

Re: A Few thoughts on C, C++, and D

On Monday, 29 May 2017 at 16:08:11 UTC, Russel Winder wrote: A few thoughts not entirely random but without a well thought out storyline, prompted by a couple of recent threads here. I like the comment from DConf that D should be the successor to Vala for writing GObject-based code. We have

Re: [OT] I found a bug in Excel 2016

On Fri, May 26, 2017 at 06:16:29PM -0400, Steven Schveighoffer via Digitalmars-d wrote: > On 5/26/17 10:38 AM, Steven Schveighoffer wrote: > > Here is my story: > > > > http://www.schveiguy.com/blog/2017/05/how-to-report-a-bug-to-microsoft/ > > > > And it worked:

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, 29 May 2017 at 08:41:05 UTC, Jonathan M Davis wrote: I probably didn't say it very well. With C++, if you have const T&, it will accept both lvalues and rvalues. A number of folks (particularly those writing games) want an equivalent to that in D where they can then pass both

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, 29 May 2017 at 07:46:07 UTC, Stanislav Blinov wrote: On Monday, 29 May 2017 at 07:39:40 UTC, Dukc wrote: [snip] Explicitly? It is: import std.stdio; struct S { int v; } void foo(ref S s) { writeln("took S by ref: ", s.v); } void foo(S s) { writeln("took rvalue

Re: Best way for handle missing args in REST interface in vibed

@rootPathFromName interface API { @path("mytrack") @method(HTTPMethod.GET)Json doTrackSpeedAnalyze(int trackid, string startDateTime, string endDateTime); } class MyRouter : API { Config config; Database database; this(Config config, Database database) {

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, 29 May 2017 at 07:39:40 UTC, Dukc wrote: I think it's mostly about good taste on what you define functions to take as ref input. I have a feeling the present way is not a big problem in practice because it is intuitive somehow. Besides, member functions mutate their class/struct

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, 29 May 2017 at 08:40:27 UTC, ketmar wrote: yet i must say that using pointers in a code where they should be references makes me... nervous. it just doesn't feel right. but meh, i'll trade that (and safety, 'cause `&` is unsafe) for "call site ref indicator". So one win with

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, 29 May 2017 at 15:31:26 UTC, WebFreak001 wrote: well for the extension functions I wrote that if the ref parameter is the first argument and it's called with ufcs syntax, it could implicitly add the ref probably. I don't think there are any big issues with that, it does look like a

[Issue 17451] ICE in ddmd/declaration.d(2179)

https://issues.dlang.org/show_bug.cgi?id=17451 Walter Bright changed: What|Removed |Added Keywords||ice

[Issue 17451] ICE in ddmd/declaration.d(2179)

https://issues.dlang.org/show_bug.cgi?id=17451 Walter Bright changed: What|Removed |Added Hardware|x86_64 |All

Another "D is cool" post

So, recently in one of my pet projects I have a bit of code that takes a string, fills in a code template, invokes the D compiler to create a shared object, then loads the object with dlopen() and calls dlsym() to get the entry point into the compiled code as a function pointer. I've written the

[Issue 15517] std.experimental.logger: using 'sharedLog' to change to file logging for default logger does not work

https://issues.dlang.org/show_bug.cgi?id=15517 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/27b6122d942e17edeb7db6aafd148f6ab88a1f19 fix Issue 15517 was already fixed but had no fixture

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, May 29, 2017 17:19:27 Stanislav Blinov via Digitalmars-d wrote: > `in` is `const scope` Walter recently changed is that in is now just const, because scope was not properly implemented previously, and folks were using in all over the place, so the odds of code breaking when scope was

[Issue 17452] New: Undefined references in std.container.array

https://issues.dlang.org/show_bug.cgi?id=17452 Issue ID: 17452 Summary: Undefined references in std.container.array Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: regression

Re: Another "D is cool" post

On Monday, 29 May 2017 at 19:07:03 UTC, H. S. Teoh wrote: So, recently in one of my pet projects I have a bit of code that takes a string, fills in a code template, invokes the D compiler to create a shared object, then loads the object with dlopen() and calls dlsym() to get the entry point

Re: Another "D is cool" post

On Monday, 29 May 2017 at 19:07:03 UTC, H. S. Teoh wrote: So, recently in one of my pet projects I have a bit of code that takes a string, fills in a code template, invokes the D compiler to create a shared object, then loads the object with dlopen() and calls dlsym() to get the entry point

Re: Another "D is cool" post

On 5/29/17 12:07 PM, H. S. Teoh via Digitalmars-d wrote: [snip an excellent post] I think a longish post like this would make an excellent shortish post for the D blog. In any case, great writeup!

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote: On Monday, May 29, 2017 17:19:27 Stanislav Blinov via Digitalmars-d wrote: `in` is `const scope` Walter recently changed is that in is now just const, because scope was not properly implemented previously, and folks were using

Re: Another "D is cool" post

On Monday, 29 May 2017 at 19:54:22 UTC, Guillaume Boucher wrote: Seems like the perfect job for a scripting language like Python. I'm not sure why you decided to compare everything to C. Even C programmers will agree with you that in D you can do things in a shorter way -- just

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, May 29, 2017 20:00:12 Stanislav Blinov via Digitalmars-d wrote: > On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote: > > On Monday, May 29, 2017 17:19:27 Stanislav Blinov via > > > > Digitalmars-d wrote: > >> `in` is `const scope` > > > > Walter recently changed is that in

Re: A Few thoughts on C, C++, and D

On Monday, 29 May 2017 at 16:08:11 UTC, Russel Winder wrote: A few thoughts not entirely random but without a well thought out storyline, prompted by a couple of recent threads here. I like the comment from DConf that D should be the successor to Vala for writing GObject-based code. We have

Re: A Few thoughts on C, C++, and D

On Monday, 29 May 2017 at 17:09:21 UTC, aberba wrote: IMO, the most important thing is getting the job done. * getting the job done right. Otherwise, you are just going to accumulate patchy code for which you will pay down the line continuously.

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, 29 May 2017 at 05:39:41 UTC, Nick Sabalausky (Abscissa) wrote: Did you intend that as a response to my post or to the OP? Sounds more like it was directed at the OP. I tried to reply to: <

Re: binding to C++

27.05.2017 02:44, Nicholas Wilson пишет: Thats weird. DMD may have got the mangling wrong. Could you post the exact mangling (i.e. non-demangled)? And if DMD has got it wrong and its just the one function you could just `pragma(mangle, ...);` it. I use pragma(mangle, "...") (how I forget about

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote: Should the language spec say that those functions should get called with `foo(ref input);` so that surprises like this where the user doesn't check the docs/implementation can't happen (like in C#)? I think it's mostly about good

[Issue 17450] escaping delegate context pointer not detected for member functions

https://issues.dlang.org/show_bug.cgi?id=17450 Tomer Filiba (weka) changed: What|Removed |Added CC||to...@weka.io --

[Issue 17451] ICE in ddmd/declaration.d(2179)

https://issues.dlang.org/show_bug.cgi?id=17451 --- Comment #2 from greensunn...@gmail.com --- > According to a bisect this can happen since: > https://github.com/dlang/dmd/pull/6550 Please ignore, the PR in which the failing check was introduced is: https://github.com/dlang/dmd/pull/6065 --

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, 29 May 2017 at 07:39:40 UTC, Dukc wrote: But what would be worth a consideration, is that perhaps one should be allowed to pass rvalues as reference with something like this? According to TDPL, ref arguments do not take rvalues to prevent bugs where you accidently copy something

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, May 29, 2017 07:39:40 Dukc via Digitalmars-d wrote: > But what would be worth a consideration, is that perhaps one > should be allowed to pass rvalues as reference with something > like this? According to TDPL, ref arguments do not take rvalues > to prevent bugs where you accidently

[Issue 17423] @safe code seg faults

https://issues.dlang.org/show_bug.cgi?id=17423 greensunn...@gmail.com changed: What|Removed |Added CC||greensunn...@gmail.com --- Comment

Re: Any video editing folks n da house?

On Wednesday, 24 May 2017 at 09:27:59 UTC, Andrei Alexandrescu wrote: I'm thinking publicly available videos so the footage is already out there. One question I'd want to ask is: What is the legal status of the resulting video? This is purely because of software licensing. My nonlinear

[Issue 17451] New: ICE in ddmd/declaration.d(2179)

https://issues.dlang.org/show_bug.cgi?id=17451 Issue ID: 17451 Summary: ICE in ddmd/declaration.d(2179) Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: major Priority: P1

Re: DCompute is now in the master branch of LDC

On 29/05/2017 10:33 AM, Nicholas Wilson wrote: Hi all, I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions require LLVM 3.9.1 or greater for NVPTX/CUDA and my fork[1] of LLVM for SPIRV. Someone (sorry I've forgotten who!)

Re: DCompute is now in the master branch of LDC

On Monday, 29 May 2017 at 09:39:53 UTC, rikki cattermole wrote: On 29/05/2017 10:33 AM, Nicholas Wilson wrote: Hi all, I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions require LLVM 3.9.1 or greater for NVPTX/CUDA and my

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, May 29, 2017 09:17:31 Ola Fosheim Grøstad via Digitalmars-d wrote: > On Monday, 29 May 2017 at 08:41:05 UTC, Jonathan M Davis wrote: > > With C++, if you have const T&, it will accept both lvalues and > > rvalues. A number of folks (particularly those writing games) > > want an

Re: DCompute is now in the master branch of LDC

On 29/05/2017 10:52 AM, Nicholas Wilson wrote: On Monday, 29 May 2017 at 09:39:53 UTC, rikki cattermole wrote: On 29/05/2017 10:33 AM, Nicholas Wilson wrote: Hi all, I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, 29 May 2017 at 07:51:13 UTC, Jonathan M Davis wrote: I expect that we're going to see a DIP related to rvalue references at some point here, because some of the folks (particularly the game folks) think that it's critical to be able to have a function that doesn't care whether it's

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

Ola Fosheim Grostad wrote: This is information that a good IDE could be designed to provide. when people start talking about how IDE can help to solve particular language problem, it is a clear sign of bad language design.

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

Nick Sabalausky (Abscissa) wrote: In response to any claim that this isn't a real problem in practice, I submit the possibility that, if it indeed isn't a real problem, maybe that's *because* of people (like Stefan and ketmar) simply avoiding the feature entirely so that it *doesn't* become a

Re: purity question

Brad Roberts wrote: libraries that themselves aren't marked pure, there's a real need for escape hatches. A simple example: anything that has a malloc/free pair. they aren't pure. it is a sad misconception about purity, which D makes even more complex by allowing to mark, for example,

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, 29 May 2017 at 08:41:05 UTC, Jonathan M Davis wrote: With C++, if you have const T&, it will accept both lvalues and rvalues. A number of folks (particularly those writing games) want an equivalent to that in D where they can then pass both lvalues and rvalues without incurring a

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

Meta wrote: On Sunday, 28 May 2017 at 19:10:49 UTC, ketmar wrote: Meta wrote: If a parameter is marked as ref then you have to assume it will be modified by the function (unless it's const/inout/immutable). If it's marked as out then you know it will be. If you didn't know that the

Re: Safe code as an I/O requirement

On Sunday, 28 May 2017 at 16:58:53 UTC, aberba wrote: https://lwn.net/Articles/708196/ From the look of things and feedbacks from several security analysts and system developers, [exposed] I/O needs to be memory safe. GStreamer multimedia library developed in C has safety issues [see

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

Nicholas Wilson wrote: On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote: Imagine you wrote a function void foo(ref int a) { if (std.random.uniform(0, 10) == 0) a = 0; // Actual code doing something } [...] It seems nice in theory but how will it interact with generic code?

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, May 29, 2017 08:22:23 Ola Fosheim Grøstad via Digitalmars-d wrote: > On Monday, 29 May 2017 at 07:51:13 UTC, Jonathan M Davis wrote: > > I expect that we're going to see a DIP related to rvalue > > references at some point here, because some of the folks > > (particularly the game

[Semi-OT] DoS with hashing

Interesting article: https://emboss.github.io/blog/2012/12/14/breaking-murmur-hash-flooding-dos-reloaded/ I remember seeing some discussion on this previously on the forums. https://issues.dlang.org/show_bug.cgi?id=7179 Any update on this issue?

DCompute is now in the master branch of LDC

Hi all, I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions require LLVM 3.9.1 or greater for NVPTX/CUDA and my fork[1] of LLVM for SPIRV. Someone (sorry I've forgotten who!) at dconf said they'd make a docker image of

Re: Ali's slides from his C++Now talk

On Monday, 29 May 2017 at 06:18:14 UTC, Ali Çehreli wrote: On 05/28/2017 05:41 PM, Corey Lubin wrote: > On Tuesday, 23 May 2017 at 23:31:48 UTC, Joakim wrote: >> Enjoying going through these: >> >> http://ddili.org/AliCehreli_CppNow_2017_Competitive_Advantage_with_D.no_pause.pdf >> > > I was

Re: Ali's slides from his C++Now talk

On 05/28/2017 05:41 PM, Corey Lubin wrote: > On Tuesday, 23 May 2017 at 23:31:48 UTC, Joakim wrote: >> Enjoying going through these: >> >> http://ddili.org/AliCehreli_CppNow_2017_Competitive_Advantage_with_D.no_pause.pdf >> > > I was particularly amused by the very last slide... Clever. :)) It

[Issue 17451] ICE in ddmd/declaration.d(2179)

https://issues.dlang.org/show_bug.cgi?id=17451 --- Comment #1 from greensunn...@gmail.com --- According to a bisect this can happen since: https://github.com/dlang/dmd/pull/6550 --

Re: Ali's slides from his C++Now talk

On 05/28/2017 11:35 PM, mate wrote: >> :C >> :C++ >> :D > What was the reaction of the C++ crowd seeing this? I was out of time and was being shoved off stage but I managed to go quickly to the last slide. I remember hearing laughs from the audience. :) It's easy to make jokes like

Re: [Semi-OT] DoS with hashing

On Monday, 29 May 2017 at 09:08:45 UTC, Random-dev wrote: Interesting article: https://emboss.github.io/blog/2012/12/14/breaking-murmur-hash-flooding-dos-reloaded/ I remember seeing some discussion on this previously on the forums. https://issues.dlang.org/show_bug.cgi?id=7179 Any update on

Re: Built-in RAII in D

On Sunday, 28 May 2017 at 18:38:21 UTC, Moritz Maxeiner wrote: On Sunday, 28 May 2017 at 17:34:30 UTC, Nerve wrote: With regards to your popularity argument: IMHO the only people we should concern ourselves with are those that evaluate which are the right tools for their current task as

Re: Built-in RAII in D

On Monday, 29 May 2017 at 01:36:31 UTC, Mike Parker wrote: More broadly, I think what we need to be doing is teaching people that D's GC is not their grandfather's GC and that, unless they are doing something highly specialized, they probably don't need alternatives. The GC is fine by itself

Re: purity question

On Monday, 29 May 2017 at 08:49:07 UTC, ketmar wrote: pure. and while various functions in std.math, for example, are marked `pure`, they aren't too. Out of curiosity, which functions in std.math aren't "pure" in the D sense?

[Issue 17454] New: ABI non-conformity: produces unaligned placement of struct on stack

https://issues.dlang.org/show_bug.cgi?id=17454 Issue ID: 17454 Summary: ABI non-conformity: produces unaligned placement of struct on stack Product: D Version: D2 Hardware: x86_64 OS: Windows

Re: A Few thoughts on C, C++, and D

On 5/29/2017 1:36 PM, Moritz Maxeiner via Digitalmars-d wrote: On Monday, 29 May 2017 at 17:09:21 UTC, aberba wrote: IMO, the most important thing is getting the job done. * getting the job done right. Otherwise, you are just going to accumulate patchy code for which you will pay down the

Re: A Few thoughts on C, C++, and D

On Monday, 29 May 2017 at 20:58:54 UTC, Brad Roberts wrote: Each time someone wraps a new library, each time someone fixes some bug because it affects them, etc.. these all push things forward inch by inch. Eventually that mass might actually reach critical. But even if it doesn't, things

[Issue 17453] I Have Many Issues

https://issues.dlang.org/show_bug.cgi?id=17453 --- Comment #1 from Soar --- 2.can support more highlight of library(class,struct)? 3.can more good support for IntelliSense? such like "this.?" "variable.?" 4.is there have any possibility to support a official GUI design tool(Of

Re: Another "D is cool" post

On Monday, 29 May 2017 at 19:51:26 UTC, David Gileadi wrote: On 5/29/17 12:07 PM, H. S. Teoh via Digitalmars-d wrote: [snip an excellent post] I think a longish post like this would make an excellent shortish post for the D blog. Yes, please.

[Issue 17264] [REG2.073] uniq fails with const elements

https://issues.dlang.org/show_bug.cgi?id=17264 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/113502af744fb82d68e8f51fd73831b628dcc1eb std.algorithm.iteration: Add test for issue 17264 --

[Issue 17330] [REG 2.072] BigInt's constructor used to be pure

https://issues.dlang.org/show_bug.cgi?id=17330 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/9e342bcc77f05b97fb8e0e176f5d9f5d44205dba Fix Issue 17330 - [REG 2.072] BigInt's constructor used

Re: RAII pointers

On Monday, 29 May 2017 at 23:39:17 UTC, Russel Winder wrote: C++ allows one to create types that are pointer types but wrap a primitive pointer to give RAII handling of resources. For example: class Dvb::FrontendParameters_Ptr { private: dvb_v5_fe_parms * ptr; public:

Re: DCompute is now in the master branch of LDC

On Tuesday, 30 May 2017 at 02:46:12 UTC, Walter Bright wrote: On 5/29/2017 6:10 PM, Nicholas Wilson wrote: there are also GitHub topics [1] which I will also properly fill out. I just done a pass over the README.md [1]: https://github.com/blog/2309-introducing-topics Good. Making the

Re: Built-in RAII in D

On 05/29/2017 06:25 AM, aberba wrote: On Sunday, 28 May 2017 at 18:38:21 UTC, Moritz Maxeiner wrote: On Sunday, 28 May 2017 at 17:34:30 UTC, Nerve wrote: With regards to your popularity argument: IMHO the only people we should concern ourselves with are those that evaluate which are the

Re: Another "D is cool" post

On Tue, May 30, 2017 at 01:44:58AM +, Mike Parker via Digitalmars-d wrote: > On Monday, 29 May 2017 at 19:51:26 UTC, David Gileadi wrote: > > On 5/29/17 12:07 PM, H. S. Teoh via Digitalmars-d wrote: > > > [snip an excellent post] > > I think a longish post like this would make an excellent

[Issue 17453] New: I Have Many Issues

https://issues.dlang.org/show_bug.cgi?id=17453 Issue ID: 17453 Summary: I Have Many Issues Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: critical Priority: P1

[Issue 17453] I Have Many Issues

https://issues.dlang.org/show_bug.cgi?id=17453 --- Comment #2 from Soar --- and other bugs. when i create a project,has myproject/core/exception.d directory and file hierarchy the VisualD will give me a error in the time.d because the std library of timd.d has import

Re: DCompute is now in the master branch of LDC

On Monday, 29 May 2017 at 20:36:26 UTC, Walter Bright wrote: On 5/29/2017 2:33 AM, Nicholas Wilson wrote: Hi all, I'm happy to announce that the dcompute modifications to LDC are now in the master branch of LDC. The dcompute extensions require LLVM 3.9.1 or greater for NVPTX/CUDA and my

RAII pointers

C++ allows one to create types that are pointer types but wrap a primitive pointer to give RAII handling of resources. For example: class Dvb::FrontendParameters_Ptr { private: dvb_v5_fe_parms * ptr; public: FrontendParameters_Ptr(FrontendId const & fei,

Re: DCompute is now in the master branch of LDC

On 5/29/2017 3:52 PM, Nicholas Wilson wrote: How about calling it D-GPU ? I bet you'd get a lot more clicks on a name like that. Thanks, I called it dcompute because naming things is right up there with cache invalidation. Calling it D-GPU would be misleading because there should be no reason

Re: DCompute is now in the master branch of LDC

On Tuesday, 30 May 2017 at 00:12:51 UTC, Walter Bright wrote: On 5/29/2017 3:52 PM, Nicholas Wilson wrote: How about calling it D-GPU ? I bet you'd get a lot more clicks on a name like that. Thanks, I called it dcompute because naming things is right up there with cache invalidation. Calling

[Issue 17452] Undefined references in std.container.array

https://issues.dlang.org/show_bug.cgi?id=17452 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/e162658601c930748440957561aca47abda5fc41 Fix Issue 17452 - Undefined references in

[Issue 17452] Undefined references in std.container.array

https://issues.dlang.org/show_bug.cgi?id=17452 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 17451] ICE in ddmd/declaration.d(2179)

https://issues.dlang.org/show_bug.cgi?id=17451 uplink.co...@googlemail.com changed: What|Removed |Added Severity|major |regression --- Comment #4 from

[Issue 17340] [REG 2.074.0] isNumeric!bool should not be true

https://issues.dlang.org/show_bug.cgi?id=17340 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/83f757c17737cca5faeecdc77cae350f0bad9a4e Fix issue 17340 - isNumeric!bool should not be true

[Issue 17282] [REG 2.074.0-b1] std.conv.parse throws with -debug

https://issues.dlang.org/show_bug.cgi?id=17282 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/813efcb7e4b6c109f223cd00013218fbd289025d Fix Issue 17282 - std.conv.parse throws with -debug

Re: RAII pointers

On Monday, 29 May 2017 at 23:39:17 UTC, Russel Winder wrote: C++ allows one to create types that are pointer types but wrap a primitive pointer to give RAII handling of resources. For example: [...] std.stdio.File does basically the same thing with C's FILE*

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, May 29, 2017 21:13:53 Stanislav Blinov via Digitalmars-d wrote: > On Monday, 29 May 2017 at 20:31:18 UTC, Jonathan M Davis wrote: > > On Monday, May 29, 2017 20:00:12 Stanislav Blinov via > > > > Digitalmars-d wrote: > >> On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote: >

Re: Value closures (no GC allocation)

On Thursday, 25 May 2017 at 03:10:04 UTC, Adam D. Ruppe wrote: Snip I think the discussion is going in two orthogonal directions, which are: 1) Capture by value. This is the ability to have a lambda which behaves as expected in the example Vittorio showed void delegate()[] arr;

Re: A Few thoughts on C, C++, and D

On Monday, 29 May 2017 at 21:43:30 UTC, bachmeier wrote: Incremental is key. It's what enabled me to use D for my work. Apologies to anyone that feels only enterprise code bases with at least 10 million lines of code are worth talking about, but good luck convincing anyone to rewrite a code

Re: DCompute is now in the master branch of LDC

On 5/29/2017 6:10 PM, Nicholas Wilson wrote: there are also GitHub topics [1] which I will also properly fill out. I just done a pass over the README.md [1]: https://github.com/blog/2309-introducing-topics Good. Making the content google-friendly is also extremely important. Back in the

Re: A Few thoughts on C, C++, and D

On Tuesday, 30 May 2017 at 01:46:02 UTC, bachmeier wrote: I'm not necessarily disagreeing with RW's post. My reading is that the goal would be to get D into the enterprise, but maybe I misinterpreted. If D as a successor to Vala leads to more projects like Tilix, that's great. I never quite

Re: RAII pointers

On Monday, 29 May 2017 at 23:39:17 UTC, Russel Winder wrote: C++ allows one to create types that are pointer types but wrap a primitive pointer to give RAII handling of resources. For example: class Dvb::FrontendParameters_Ptr { private: dvb_v5_fe_parms * ptr; public:

Re: A Few thoughts on C, C++, and D

On Monday, 29 May 2017 at 22:20:34 UTC, Ola Fosheim Grøstad wrote: I don't think Russel Winder was talking about enterprise code, but for a language to take hold you need at least one significant publicly visible application written in it. E.g. Go has Docker, Rust has a Firefox engine, and

[Issue 17275] [REG 2.072.0] AssertError@declaration.d(2121): Assertion failure

https://issues.dlang.org/show_bug.cgi?id=17275 --- Comment #4 from Walter Bright --- https://github.com/dlang/dmd/pull/6845 --

Re: A Few thoughts on C, C++, and D

On Monday, 29 May 2017 at 16:08:11 UTC, Russel Winder wrote: I like the comment from DConf that D should be the successor to Vala for writing GObject-based code. We have GtkD and in it GStreamer. Writing programs in C with them is a real pain in the a### and using C++ is only a little bit

Re: Should out/ref parameters require the caller to specify out/ref like in C#?

On Monday, 29 May 2017 at 20:31:18 UTC, Jonathan M Davis wrote: On Monday, May 29, 2017 20:00:12 Stanislav Blinov via Digitalmars-d wrote: On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote: > On Monday, May 29, 2017 17:19:27 Stanislav Blinov via > > Digitalmars-d wrote: >> `in` is

Re: Value closures (no GC allocation)

On Monday, 29 May 2017 at 21:26:11 UTC, MakersF wrote: 1) Capture by value. This is the ability to have a lambda which behaves as expected in the example Vittorio showed That's a known bug in the implementation; it is supposed to work that way now. (Though the bug has been open for so long

  1   2   >