Re: Fiber overhead

On Saturday, 4 February 2017 at 06:54:01 UTC, Ali Çehreli wrote: On 02/03/2017 08:47 PM, Profile Anaysis wrote: What is the overhead of using a fiber? The performance overhead of call() and yield() are comparable to function calls because it's simply a few register assignments in each case.

Re: The extent of trust in errors and error handling

On 02/01/2017 06:29 PM, Chris Wright wrote: > On Wed, 01 Feb 2017 11:25:07 -0800, Ali Çehreli wrote: >> 1) There is the well-known issue of whether Error should ever be caught. >> If Error represents conditions where the application is not in a defined >> state, hence it should stop operating as

[Issue 17139] [BLOCKING] dscanner needs to handle 'scope' function attributes

https://issues.dlang.org/show_bug.cgi?id=17139 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/4fab50175481d9b1c00ae168c444580de92f258c fix issue 17139 - dscanner needs to handle 'scope'

[Issue 17139] [BLOCKING] dscanner needs to handle 'scope' function attributes

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

Re: The extent of trust in errors and error handling

On 02/01/2017 01:27 PM, Joakim wrote: > On Wednesday, 1 February 2017 at 19:25:07 UTC, Ali Çehreli wrote: >> tl;dr - Seeking thoughts on trusting a system that allows "handling" >> errors. >> >> [...] > > Have you seen this long post from last year, where Joe Duffy laid out > what they did with

Re: Fiber overhead

On 02/03/2017 08:47 PM, Profile Anaysis wrote: What is the overhead of using a fiber? The performance overhead of call() and yield() are comparable to function calls because it's simply a few register assignments in each case. (Change the stack pointer, etc.) Memory overhead is memory for

Re: GSoC Project Idea's Part 2

On Friday, 3 February 2017 at 04:12:10 UTC, Craig Dillabaugh wrote: So the GSoC ideas page is now at least partially complete, you can find it here: https://wiki.dlang.org/GSOC_2017_Ideas In the previous thread some of you (Rikki, Adam) had suggested some improvements to dub/the

Re: Name That Technique!

On 02/03/2017 06:50 PM, Ali Çehreli wrote: "the imp idiom" might do but imps have a very insignificant appearance in Harry Potter. But they have much significance in Doom :) ...part of which takes place on Phobos ;)

Fiber overhead

What is the overhead of using a fiber?

Re: A public domain game written in D

On Friday, 3 February 2017 at 21:14:48 UTC, Dukc wrote: http://lixgame.com/ A public domain game very much like Lemmings. I'm almost sure some of you here have played Lemmings. NOTE: I have not made or even contributed to that project. I just stumbled upon it when surfing the net and

Re: GC question

On Friday, 3 February 2017 at 11:36:26 UTC, osa1 wrote: On Friday, 3 February 2017 at 10:49:00 UTC, Kagamin wrote: Leaks are likely in 32-bit processes and unlikely in 64-bit processes. See e.g. https://issues.dlang.org/show_bug.cgi?id=15723 This looks pretty bad. I think I'll consider

Re: Thoughts about exception reporting

On Fri, 03 Feb 2017 19:50:19 +, pineapple wrote: > - nothrow might be repurposed to mean "doesn't throw recoverable > exceptions", and it not forbid throwing objects that inherit from Error. That's what it means today: void foo() nothrow { throw new Error("Ohai!"); }

Re: Automatic imports?

On 2/3/2017 4:01 PM, Ali Çehreli wrote: void foo(std.datetime.Duration dur) { // ... } Can the compiler automatically import std.datetime for both the implementation above and the user? Or, too much beer at work on this Friday? :o) How does the compiler know that "std" is supposed to be

Automatic imports?

On 02/03/2017 06:43 AM, Dominikus Dittes Scherkl wrote: > DIP 1005 provides new syntax to make it possible to avoid global imports. I haven't followed DIP 1005 closely. Has there been any discussion of automatic imports that seems to have potential to make both the user's and implementor's

Re: Name That Technique!

On Friday, 3 February 2017 at 23:33:58 UTC, Walter Bright wrote: I agree, it's pretty dazz! We need to give this technique a memorable name (not an acronym). I thought "Voldemort Types" turned out rather well, whereas CTFE is klunky, UFCS is even worse. The absolute worst is C++ SFINAE. Any

Re: Name That Technique!

On 02/03/2017 03:33 PM, Walter Bright wrote: >> On 2/3/17 10:41 AM, Daniel N wrote: >>> auto fun_time(imp!"std.datetime".SysTime tm) > We need to give this technique a memorable name (not an acronym). If it's going to stay "imp" (which I initially found confusing; How about "Import"?), "the

Name That Technique!

On 2/3/2017 11:14 AM, Andrei Alexandrescu wrote: On 2/3/17 10:41 AM, Daniel N wrote: On Friday, 3 February 2017 at 14:43:01 UTC, Dominikus Dittes Scherkl wrote: DIP 1005 provides new syntax to make it possible to avoid global imports. Any thoughts? I like it! template imp(string mod) {

Re: Snap packages for D compilers and core projects

On Sunday, 29 January 2017 at 20:07:50 UTC, Joseph Rushton Wakeling wrote: I started by trying to snap LDC, mainly because the cmake build system made for a very easy integration with the snapcraft package-build system. The LDC developers have been kind enough to accept this as an official

Snap package for LDC 1.1.0 available to test

As of earlier today, a snap package for LDC 1.1.0 has been published in the 'edge' channel of the Ubuntu store. Snap packages are a new format developed by Ubuntu to facilitate upstreams being able to provide the latest versions of their apps directly to users. The format is also designed to

Re: Snap packages for D compilers and core projects

On Friday, 3 February 2017 at 08:51:38 UTC, qznc wrote: I just tried FlatPak and Snap. Snap is actually useable. One of the first things that struck me about snap packaging was the ease of its syntax and how straightforward it was to get things working. I actually started creating snap

Re: Is there anything fundamentally wrong with this code?

On 02/03/2017 11:43 AM, WhatMeWorry wrote: On Friday, 3 February 2017 at 18:37:15 UTC, Johan Engelen wrote: On Friday, 3 February 2017 at 17:20:43 UTC, WhatMeWorry wrote: [...] The error is in this line. Instead of assigning to the `postProc` at module scope, you are defining a new

Re: memcpy() comparison: C, Rust, and D

On 2/3/2017 4:10 AM, Atila Neves wrote: Right, but we're talking about finding memory corruption bugs _before_ they manifest themselves. As I mentioned in my other reply, if you have memory corruption bugs in common cross-platform code, valgrind and asan will (nearly always) catch them. You

Re: Boston D Meetup 2/9: `shared` Experiences

On Monday, 30 January 2017 at 21:48:57 UTC, Steven Schveighoffer wrote: Attention fellow Boston D enthusiasts: I have set up a meetup for February, and Michael Coulombe will give a presentation on his experiences with shared. As before, this will be at the Capital One Cafe in the back bay

Re: Workaround for DIP 1005

On Friday, 3 February 2017 at 20:04:22 UTC, Daniel Nielsen wrote: On Friday, 3 February 2017 at 19:14:16 UTC, Andrei Alexandrescu wrote: Wow. This is... brilliant. Thanks for the great idea. I ran a few tests and it seems to be doing out of the box most of what we want with DIP1005 with no

A public domain game written in D

http://lixgame.com/ A public domain game very much like Lemmings. I'm almost sure some of you here have played Lemmings. NOTE: I have not made or even contributed to that project. I just stumbled upon it when surfing the net and thought you may be interested to hear.

[Issue 17139] [BLOCKING] dscanner needs to handle 'scope' function attributes

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

Re: Workaround for DIP 1005

On Friday, 3 February 2017 at 19:14:16 UTC, Andrei Alexandrescu wrote: Wow. This is... brilliant. Thanks for the great idea. I ran a few tests and it seems to be doing out of the box most of what we want with DIP1005 with no language change at all. Congratulations! Andrei Thank you very

Thoughts about exception reporting

Something I keep going back and forth on is the best way to handle exception reporting in different contexts. There are so many idioms to use here and none of them feel quite ideal. I'm not sure the best way to improve it, but I'm hoping a discussion might produce some useful ideas. Some

Re: LDC 1.1.0 released

On Friday, 3 February 2017 at 12:21:09 UTC, deadalnix wrote: On Wednesday, 1 February 2017 at 03:43:10 UTC, David Nadlinger wrote: Hi all, Version 1.1.0 of LDC, the LLVM-based D compiler, has finally been released: https://github.com/ldc-developers/ldc/releases/tag/v1.1.0 Please head over

Re: Is there anything fundamentally wrong with this code?

On Friday, 3 February 2017 at 18:37:15 UTC, Johan Engelen wrote: On Friday, 3 February 2017 at 17:20:43 UTC, WhatMeWorry wrote: [...] The error is in this line. Instead of assigning to the `postProc` at module scope, you are defining a new local variable and assigning to it.

Re: How to write Good IDE?

On Wednesday, 1 February 2017 at 15:12:42 UTC, unDEFER wrote: And what important for you for Good IDE? Simple IDE. It is possible that that is useful from this what is. I permanently use it as it is very quickly. https://www.youtube.com/watch?v=RBan5Dwt_JM

Re: Workaround for DIP 1005

On 2/3/17 2:14 PM, Andrei Alexandrescu wrote: On 2/3/17 10:41 AM, Daniel N wrote: On Friday, 3 February 2017 at 14:43:01 UTC, Dominikus Dittes Scherkl wrote: DIP 1005 provides new syntax to make it possible to avoid global imports. Any thoughts? I like it! template imp(string mod) {

Re: Workaround for DIP 1005

On 2/3/17 10:41 AM, Daniel N wrote: On Friday, 3 February 2017 at 14:43:01 UTC, Dominikus Dittes Scherkl wrote: DIP 1005 provides new syntax to make it possible to avoid global imports. Any thoughts? I like it! template imp(string mod) { mixin("import imp = " ~ mod ~ ";"); } auto

Re: D IDE Coedit - version 3 beta 3

On Monday, 30 January 2017 at 23:32:12 UTC, dminded wrote: Ok, the debugger also works if i write a bit more then just a 'writeln' into main. How can i set breakpoints? If i click on the left side of a row, a little red dot appears. But the debugger seems to ignore it and instead every

Re: CTFE Status

On Wednesday, 1 February 2017 at 11:53:09 UTC, Stefan Koch wrote: On Tuesday, 31 January 2017 at 16:21:27 UTC, Stefan Koch wrote: function pointer support is coming! This is more difficult then I expected, since the argument handling system was build without considering that we could have

Re: Is there anything fundamentally wrong with this code?

On Friday, 3 February 2017 at 17:20:43 UTC, WhatMeWorry wrote: -file post_processor.d -- module post_processor; class PostProcessor { ... GLuint FBO; } -file game.d --- module game; PostProcessor postProc; //

Re: unDE 0.2.0 - unusual command line and keybar

On Friday, 3 February 2017 at 17:11:26 UTC, Chris Wright wrote: I think `mkdirRecurse` doesn't complain about directories that already exist. Thank you!

[Issue 17141] New: CommonType!(dchar, char) returns uint

https://issues.dlang.org/show_bug.cgi?id=17141 Issue ID: 17141 Summary: CommonType!(dchar, char) returns uint Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1

Is there anything fundamentally wrong with this code?

The code below compiles fine but I always get a run time abort with the error down below. Isn't the postProc at module scope so shouldn't the class instance always be around (ie not deallocated?) If it helps, this was translated from C++ code. Thanks. -file

Re: unDE 0.2.0 - unusual command line and keybar

On Fri, 03 Feb 2017 14:18:05 +, Basile B. wrote: > Also before that there's two FileException thrown because you use > mkdir() systematically with a silent try catch. You should rather test > if the the directories exist (when you create ~/.unde/ and > ~/.unde/bdb/, global_state.d) because it

Re: Workaround for DIP 1005

On Fri, 03 Feb 2017 14:43:01 +, Dominikus Dittes Scherkl wrote: > fun.ST fun() > { > import someModule.SomeType; > alias ST = SomeType; > ... > } What compiler version is this? I'm getting segfaults with both 2.072.2 and 2.073.0. Reported as

[Issue 17140] Segfault when using function-name-qualified renamed import as function return type

https://issues.dlang.org/show_bug.cgi?id=17140 Chris Wright changed: What|Removed |Added OS|Windows |Linux --

[Issue 17140] Segfault when using function-name-qualified renamed import as function return type

https://issues.dlang.org/show_bug.cgi?id=17140 --- Comment #1 from Chris Wright --- Doesn't have to be a static import: --- fun.S fun() { import std.socket; alias S = Socket; return null; } --- --

[Issue 17140] Segfault when using function-name-qualified renamed import as function return type

https://issues.dlang.org/show_bug.cgi?id=17140 Chris Wright changed: What|Removed |Added Keywords||ice --

[Issue 17140] New: Segfault when using function-name-qualified renamed import as function return type

https://issues.dlang.org/show_bug.cgi?id=17140 Issue ID: 17140 Summary: Segfault when using function-name-qualified renamed import as function return type Product: D Version: D2 Hardware: x86_64 OS: Windows

[Issue 17130] [Reg 2.074] ambiguous implicit super call when inheriting core.sync.mutex.Mutex

https://issues.dlang.org/show_bug.cgi?id=17130 Martin Nowak changed: What|Removed |Added Keywords||pull --- Comment #4 from

Re: unDE 0.2.0 - unusual command line and keybar

On Friday, 3 February 2017 at 14:18:05 UTC, Basile B. wrote: Also before that there's two FileException thrown because you use mkdir() systematically with a silent try catch. You should rather test if the the directories exist (when you create ~/.unde/ and ~/.unde/bdb/, global_state.d)

Re: unDE 0.2.0 - unusual command line and keybar

On Friday, 3 February 2017 at 14:05:58 UTC, Basile B. wrote: What is the name of the static lib we have to install for for "DB" ? /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: ne peut trouver -ldb collect2: error: ld returned 1 exit status Error: linker exited

Re: Workaround for DIP 1005

On Friday, 3 February 2017 at 14:59:09 UTC, rikki cattermole wrote: On 04/02/2017 3:43 AM, Dominikus Dittes Scherkl wrote: DIP 1005 provides new syntax to make it possible to avoid global imports. But this can already be worked around with some nice trick: Any thoughts? Needless syntax

Re: Workaround for DIP 1005

On Friday, 3 February 2017 at 14:43:01 UTC, Dominikus Dittes Scherkl wrote: DIP 1005 provides new syntax to make it possible to avoid global imports. Any thoughts? I like it! template imp(string mod) { mixin("import imp = " ~ mod ~ ";"); } auto fun_time(imp!"std.datetime".SysTime tm) {

Re: GSoC Project Idea's Part 2

On 04/02/2017 3:53 AM, CRAIG DILLABAUGH wrote: On Friday, 3 February 2017 at 04:14:58 UTC, rikki cattermole wrote: FYI there has been a few people asking about GSOC on #D, any chance you could hang out there so if anybody turns up you can help em' out? I will make a point of going on #D

Re: Workaround for DIP 1005

On 04/02/2017 3:43 AM, Dominikus Dittes Scherkl wrote: DIP 1005 provides new syntax to make it possible to avoid global imports. Till now global imports are necessary if a function uses types declared in some imported module within it's declaration or definition (otherwise a local import will

Re: GSoC Project Idea's Part 2

On Friday, 3 February 2017 at 04:14:58 UTC, rikki cattermole wrote: On 03/02/2017 5:12 PM, Craig Dillabaugh wrote: So the GSoC ideas page is now at least partially complete, you can find it here: https://wiki.dlang.org/GSOC_2017_Ideas In the previous thread some of you (Rikki, Adam) had

Workaround for DIP 1005

DIP 1005 provides new syntax to make it possible to avoid global imports. Till now global imports are necessary if a function uses types declared in some imported module within it's declaration or definition (otherwise a local import will do). But this can already be worked around with some

Any full-text search library

Is there any usable full-text search library? for D I couldn't find any except the Elasticsearch client called elasticsearch-d in the package registry a very old Lucene port for D1 called dlucene. This is it or did I miss something?

Re: unDE 0.2.0 - unusual command line and keybar

On Friday, 3 February 2017 at 14:05:58 UTC, Basile B. wrote: On Friday, 3 February 2017 at 13:48:39 UTC, Basile B. wrote: On Sunday, 29 January 2017 at 19:00:30 UTC, unDEFER wrote: unDE's not DE which in the future must be replacement for all programs in OS. But today is very original file

Re: unDE 0.2.0 - unusual command line and keybar

On Friday, 3 February 2017 at 13:48:39 UTC, Basile B. wrote: On Sunday, 29 January 2017 at 19:00:30 UTC, unDEFER wrote: unDE's not DE which in the future must be replacement for all programs in OS. But today is very original file manager, image and text viewer and (what discovered with 0.2.0

Re: unDE 0.2.0 - unusual command line and keybar

On Sunday, 29 January 2017 at 19:00:30 UTC, unDEFER wrote: unDE's not DE which in the future must be replacement for all programs in OS. But today is very original file manager, image and text viewer and (what discovered with 0.2.0 version) command line and keybar. More information:

Re: How to write Good IDE?

On Friday, 3 February 2017 at 12:37:53 UTC, Jacob Carlborg wrote: The old Eclipse plugin for D1, Descent [1], is the gold standard when it comes to IDE's for D. Check the features list [2] to get some ideas and inspiration. [1] http://www.dsource.org/projects/descent [2]

Re: vibe.d 0.8.0 and 0.7.31 beta releases

Am 03.02.2017 um 10:28 schrieb yazd: On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote: The first release of the revamped core module [1] is nearing, and along with that, a compatible vibe.d release (0.8.0). The new core module is still opt-in in this release and can be activated

Re: LDC 1.1.0 released

On Friday, 3 February 2017 at 12:21:09 UTC, deadalnix wrote: What's the state of cent/ucent ? Unchanged as https://github.com/ldc-developers/ldc/pull/1659 is still pending and Kai doesn't have time ATM. If you're very interested in 128-bit integers, please consider continuing that PR

Re: memcpy() comparison: C, Rust, and D

On Thursday, 2 February 2017 at 20:37:32 UTC, Random D user wrote: What if d had a -safe-defaults switch? It should be ok, since safe is stricter than unsafe right? Yes, we need this because module-level '@safe:' doesn't allow inferrence of @system. This way old/existing code would compile

Re: vibe.d 0.8.0 and 0.7.31 beta releases

On Friday, 3 February 2017 at 12:25:42 UTC, Dominikus Dittes Scherkl wrote: On Friday, 3 February 2017 at 09:28:26 UTC, yazd wrote: Is it possible to have non-@safe callbacks be part of the non-deprecated API? Why? A @safe API allows you to use it within @safe code, but it doesn't require you

Re: How to write Good IDE?

On 2017-02-01 16:12, unDEFER wrote: Hello! So my unDE 0.2.0 is released (http://forum.dlang.org/thread/yzfthfipouzhejfsk...@forum.dlang.org), and this means that the time to write unDE 0.3.0 - text editor and IDE. And I grab my head when thinking how much I want to implement. 1) It must shows

Re: vibe.d 0.8.0 and 0.7.31 beta releases

On Friday, 3 February 2017 at 09:28:26 UTC, yazd wrote: Is it possible to have non-@safe callbacks be part of the non-deprecated API? Why? A @safe API allows you to use it within @safe code, but it doesn't require you to also write @safe code. Especially if you don't like to annotate your code

Re: LDC 1.1.0 released

On Wednesday, 1 February 2017 at 03:43:10 UTC, David Nadlinger wrote: Hi all, Version 1.1.0 of LDC, the LLVM-based D compiler, has finally been released: https://github.com/ldc-developers/ldc/releases/tag/v1.1.0 Please head over to the digitalmars.D.ldc forums for more details and

Re: memcpy() comparison: C, Rust, and D

On Thursday, 2 February 2017 at 20:50:58 UTC, Walter Bright wrote: On 2/2/2017 6:19 AM, Atila Neves wrote: Also, unless you're testing possible bugs in compiler backends or the C standard library, it mostly doesn't matter. Compile on regular x86/Linux and run valgrind/asan there. I've often

Re: Request for conference talk

On Thursday, 2 February 2017 at 21:09:38 UTC, Chris Engelbert wrote: Hey guys, we organize a conference (TopConf) this year for the first time in Dusseldorf, Germany. I would like to see if there are interested speakers to give a talk about D. The conference is hold in English and is not

Re: memcpy() comparison: C, Rust, and D

On Thursday, 2 February 2017 at 16:44:26 UTC, Chris Wright wrote: On Thu, 02 Feb 2017 14:19:02 +, Atila Neves wrote: Also, unless you're testing possible bugs in compiler backends or the C standard library, it mostly doesn't matter. Compile on regular x86/Linux and run valgrind/asan there.

Re: GC question

On Friday, 3 February 2017 at 10:49:00 UTC, Kagamin wrote: Leaks are likely in 32-bit processes and unlikely in 64-bit processes. See e.g. https://issues.dlang.org/show_bug.cgi?id=15723 This looks pretty bad. I think I'll consider something else until D's memory management story gets better.

Re: Request for conference talk

On Thursday, 2 February 2017 at 21:09:38 UTC, Chris Engelbert wrote: Hey guys, we organize a conference (TopConf) this year for the first time in Dusseldorf, Germany. I would like to see if there are interested speakers to give a talk about D. The conference is hold in English and is not

Re: GC question

On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote: Are there any disallowed memory operations? Currently can't touch GC from destructor during collection. Another concern is interoperability with C-allocated memory: GC knows nothing about C heap. How often does it leak? Leaks

[Issue 17139] [BLOCKING] dscanner needs to handle 'scope' function attributes

https://issues.dlang.org/show_bug.cgi?id=17139 ZombineDev changed: What|Removed |Added CC|

Re: The reason of vibed slow down (request timeout)

On Friday, 3 February 2017 at 06:46:37 UTC, Suliman wrote: If I open it's from VPS (as localhost:8080) it's work same as from Internet (no do not open at all). One this I may suggest is the port if its used already (8080). Try to use; import std.process: environment; settings.port =

Re: vibe.d 0.8.0 and 0.7.31 beta releases

On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote: The first release of the revamped core module [1] is nearing, and along with that, a compatible vibe.d release (0.8.0). The new core module is still opt-in in this release and can be activated using a `subConfiguration

Re: Snap packages for D compilers and core projects

On Monday, 30 January 2017 at 16:53:34 UTC, Joseph Rushton Wakeling wrote: Snap packaging started as something Ubuntu were developing for their use-case, but started gaining cross-distro interest last year (probably because AFAICT its feature-set and simplicity of use is quite a bit ahead of

Re: Typo on the grammar section of the spec

On 02/02/2017 10:07 PM, FatalCatharsis wrote: > Cool, is there some place to make an issue for it? Try the two links at the top of each page: "Report a bug" and "Improve this page" > Don't want any unsuspecting goobers like me falling for it :P. People who read those pages down to every