Re: Overloading relational operators separately; thoughts?

On Wednesday, September 28, 2016 21:15:32 Walter Bright via Digitalmars-d wrote: > Because then something other than comparison is happening with <=, <, >, >= > and there'll be nothing in the code to give the user a hint. [snip] > D has many very powerful modeling abilities, but so far we've

Re: D, ZeroMQ, Nanomsg

On Thursday, 29 September 2016 at 04:18:55 UTC, Nikolay wrote: Be aware - Nanomsg project is mostly dead now. lol. if one drama queen moved out, that doesn't mean that the project is dead. it only means: "godspeed, drama queen."

Re: Module names shadowing defined functions/templates.

On 9/28/2016 9:17 PM, Minty Fresh wrote: While I can imagine there are technical challenges that have caused this issue to be the way it is, it's still a pretty major flaw to try to work around. Overloading of names is a constant minefield of unexpected problems, arbitrary rules to

Re: Overloading relational operators separately; thoughts?

On Thursday, 29 September 2016 at 04:39:37 UTC, Minty Fresh wrote: This applies to operator overloads just like everything else. They're just syntactic sugar for functions. Documenting their behavior is just as necessary. I disagree with this. Operators are different in that the symbols

Re: Overloading relational operators separately; thoughts?

On Thursday, 29 September 2016 at 04:15:32 UTC, Walter Bright wrote: On 9/28/2016 1:40 PM, Timon Gehr wrote: What's wrong with that usage? Because then something other than comparison is happening with <=, <, >, >= and there'll be nothing in the code to give the user a hint. There's also

Re: D, ZeroMQ, Nanomsg

On Wednesday, 28 September 2016 at 11:53:05 UTC, Russel Winder wrote: Has anyone wrapped Nanomsg? Be aware - Nanomsg project is mostly dead now. See http://sealedabstract.com/rants/nanomsg-postmortem-and-other-stories/

Re: Module names shadowing defined functions/templates.

On Thursday, 29 September 2016 at 02:26:15 UTC, Joakim wrote: I ran into this too, it is annoying. I think you're supposed to use different names. It's a rather painful limitation if that were the case. Going with the example I gave, what would an alternative name for the module be? All it's

Re: Overloading relational operators separately; thoughts?

On 9/28/2016 1:40 PM, Timon Gehr wrote: What's wrong with that usage? Because then something other than comparison is happening with <=, <, >, >= and there'll be nothing in the code to give the user a hint. (This is NOT expression templates.) Right, but it's an enabler of expression

Re: Module names shadowing defined functions/templates.

On Thursday, 29 September 2016 at 01:54:42 UTC, Minty Fresh wrote: I ran into this issue just recently when trying to write a least-squares optimization function. Notably, module leastsq; T[] leastsq(alias func, T)(T[] vec, . . .) { . . . } It becomes impossible to import and

Re: Module names shadowing defined functions/templates.

As an addendum to the above, the error message I posted was from the overload that takes a delegate as a runtime parameter. Trying to pass template arguments just gives you: Error: template instance leastsq!((p) => p) leastsq is not a template declaration, it is a import

Module names shadowing defined functions/templates.

I ran into this issue just recently when trying to write a least-squares optimization function. Notably, module leastsq; T[] leastsq(alias func, T)(T[] vec, . . .) { . . . } It becomes impossible to import and call this template function from outside the module it's declared

Re: Reinstalled Mac

On Thursday, 29 September 2016 at 01:33:00 UTC, Joel wrote: Oops, I got confused and installed with homebrew. I was going to try DVM. Jacob is also the author of DVM, so he might be a bit biased. ;) I've had good experiences using Homebrew, although you sometimes have to wait a day or three

Re: Reinstalled Mac

On Wednesday, 28 September 2016 at 09:34:46 UTC, Jacob Carlborg wrote: On 2016-09-28 10:18, Joel wrote: I've got my Mac reinstalled. I haven't installed D (dmd) yet. I would like to hear what people think. I'm thinking using home brew. And install the latest Code X. You need Xcode and I

[Issue 16563] [REG HEAD] Wrong struct size/alignment in local struct

https://issues.dlang.org/show_bug.cgi?id=16563 --- Comment #2 from uplink.co...@googlemail.com --- The hacky fix for this looks like this: --- a/src/dstruct.d +++ b/src/dstruct.d @@ -299,7 +299,8 @@ extern (C++) class StructDeclaration : AggregateDeclaration if (semanticRun == PASSinit)

[Issue 16563] [REG HEAD] Wrong struct size/alignment in local struct

https://issues.dlang.org/show_bug.cgi?id=16563 uplink.co...@googlemail.com changed: What|Removed |Added CC||uplink.co...@googlemail.com

Re: DIP 1002 (TryElseExpression) added to the queue

On 9/28/2016 3:12 PM, Idan Arye wrote: Consider this: try { auto foo = Foo(); } catch (FooCreationException) { // ... } else { foo.doSomethingWithFoo(); } I agree with Steven. Having the 'else' continue on with a scope that is already closed by } is

Re: DIP 1002 (TryElseExpression) added to the queue

On 9/28/16 7:40 PM, Andrei Alexandrescu wrote: // With scope void assertNot(string s) { try { scope(success) assert(0, s); decode(s,DecodeMode.STRICT); } catch (DecodeException e) {} } Sorry, this is not semantically equivalent. Replace with: // With scope void assertNot(string s) {

Re: DIP 1002 (TryElseExpression) added to the queue

On 9/28/16 9:10 AM, pineapple wrote: I submitted a PR addressing some of the mentioned criticisms: https://github.com/dlang/DIPs/pull/46 Thanks. The Phobos examples compared: (1) // Current unittest { bool ok = true; try { auto r2 = assumeSorted([ 677, 345, 34, 7, 5 ]);

Re: Overloading relational operators separately; thoughts?

On Wednesday, 28 September 2016 at 20:40:49 UTC, Timon Gehr wrote: This is not surprising. C++ has no good options. This is further made worse by some C++'s more inane design decisions (ie. allowing overloading of the comma operator).

Re: DIP 1002 (TryElseExpression) added to the queue

On 9/28/16 7:36 AM, Dicebot wrote: Merged draft DIPs are not set in stone - Andrei's comment is not sign of immediate rejection but a request to make a PR to improve mentioned things. It's not a sign of rejection at all! I'm not even discussing the technical merits of the language feature

Re: DIP 1002 (TryElseExpression) added to the queue

On 9/28/16 7:17 AM, pineapple wrote: These were not documented as a requirement anywhere that I saw. I'd have been happy to comply, if I had known this was the practice. Yah, we're also learning the ropes. Bear with us - this is one of the first DIPs using the new flow. I don't know enough

Re: DIP 1002 (TryElseExpression) added to the queue

On Wednesday, 28 September 2016 at 21:00:00 UTC, Steven Schveighoffer wrote: Declaring variables that you need in the right scopes is pretty straightforward. Having scopes magically continue around other separate scopes (catch scopes) doesn't look correct. I get why it's desired, but it

[Issue 16501] packed ndslices does not compile

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

[Issue 16503] [ndslice] prevents fastmath LDC attribute

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

[Issue 16503] [ndslice] prevents fastmath LDC attribute

https://issues.dlang.org/show_bug.cgi?id=16503 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/99532a8f410f4e15dc1908974cdddf73852ac4a6 fix issue 16503 : add fast math bridge for LDC --

[Issue 16501] packed ndslices does not compile

https://issues.dlang.org/show_bug.cgi?id=16501 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/a3f205a19e2cc9fc9cae7ce84c1db3b63850eb97 fix 16501 and fix issue 16501

Re: The XML and JSON library

On Wednesday, 28 September 2016 at 21:40:12 UTC, Szabo Bogdan wrote: Awesome! I guess the interface of the `std.experimental.xml` package will not change too soon... and I guess that I can assume that I can try to use it in my projects... Definitely give it a try and if you have something

Re: The XML and JSON library

On Sunday, 25 September 2016 at 09:12:03 UTC, Lodovico Giaretta wrote: On Sunday, 25 September 2016 at 08:26:58 UTC, Basile B. wrote: On Sunday, 25 September 2016 at 08:19:22 UTC, Szabo Bogdan wrote: Hi! I think that there are a few years since, the phobos support for XML and JSON were kind

Re: Parameterized delegate attributes

On Wednesday, 28 September 2016 at 20:23:10 UTC, pineapple wrote: But using a templated opApply currently breaks type inference in `foreach`, right? It'd be really nice if that were fixed. Yeah, it would be nice, but I don't think it's technically possible to fix it. The compiler cannot

Re: DIP 1002 (TryElseExpression) added to the queue

On 9/28/16 4:18 PM, pineapple wrote: On Wednesday, 28 September 2016 at 17:56:13 UTC, Steven Schveighoffer wrote: The more I think about this submission, I feel like the benefits are quite slim. This is not and was not intended to be a glorious, incredible addition to the language. It is

GC blessed for C++ (again)

https://www.reddit.com/r/programming/comments/54xnbg/herb_sutters_experimental_deferred_and_unordered/ Ali

Re: Overloading relational operators separately; thoughts?

On 28.09.2016 22:16, Walter Bright wrote: On 9/28/2016 6:58 AM, Timon Gehr wrote: An excellent example of that is the std.regex package. It's actually a bad example, because it is irrelevant: it is obviously a bad idea to implement regex using operator overloading, because the regex operators

Re: Overloading relational operators separately; thoughts?

On Wednesday, 28 September 2016 at 20:16:08 UTC, Walter Bright wrote: To reiterate, operator overloading exists in D to support the inclusion of arithmetic library types. Any other purpose is discouraged, and that includes expression templates and things like << for iostreams. It seeds

Re: Overloading relational operators separately; thoughts?

On Wednesday, 28 September 2016 at 20:16:08 UTC, Walter Bright wrote: Because there is no way to stop the former but still have operator overloading. To reiterate, operator overloading exists in D to support the inclusion of arithmetic library types. Any other purpose is discouraged, and

Re: Parameterized delegate attributes

On Wednesday, 28 September 2016 at 17:00:49 UTC, Lodovico Giaretta wrote: but a good compiler should be able to recognize functions with the same code and fold them; for example, if a function takes a generic pointer, chances are it doesn't need to be duplicated for every pointer type. But

Re: DIP 1002 (TryElseExpression) added to the queue

On Wednesday, 28 September 2016 at 20:18:06 UTC, pineapple wrote: This is not and was not intended to be a glorious, incredible addition to the language. It is meant to shove D a couple inches further in the direction of modern programming constructs. Everywhere a programmer can use `else`

Re: DIP 1002 (TryElseExpression) added to the queue

On Wednesday, 28 September 2016 at 17:56:13 UTC, Steven Schveighoffer wrote: The more I think about this submission, I feel like the benefits are quite slim. This is not and was not intended to be a glorious, incredible addition to the language. It is meant to shove D a couple inches further

Re: Overloading relational operators separately; thoughts?

On 9/28/2016 6:58 AM, Timon Gehr wrote: An excellent example of that is the std.regex package. It's actually a bad example, because it is irrelevant: it is obviously a bad idea to implement regex using operator overloading, because the regex operators have no D equivalent. Yet this "obviously

Re: FreeTree posible memory corruption ?

On Wednesday, 28 September 2016 at 19:55:35 UTC, ag0aep6g wrote: On Wednesday, 28 September 2016 at 19:39:14 UTC, Temtaime wrote: [...] That's not phobos's source. You can find it at . [...] I've recently fixed two issues in FreeTree's code. I think the

Re: FreeTree posible memory corruption ?

On Wednesday, 28 September 2016 at 19:39:14 UTC, Temtaime wrote: Look here : https://github.com/Hackerpilot/experimental_allocator/blob/master/src/std/experimental/allocator/building_blocks/free_tree.d#L297 That's not phobos's source. You can find it at . It

Re: Overloading relational operators separately; thoughts?

On Wednesday, 28 September 2016 at 04:02:59 UTC, Walter Bright wrote: The use of them to create DSLs (a technique called "expression templates" in C++) is discouraged in D, for several reasons. The recommended way to create DSLs in D is to parse strings using CTFE. I don't really come from a

Re: Overloading relational operators separately; thoughts?

On 9/28/2016 2:48 AM, Matthias Bentrup wrote: In Mathematics the comparison operators are also commonly used for semi orders, which cannot be implemented by opCmp, because opCmp has no way to indicate that two values are incomparable. Interestingly the floating point types are semi ordered (due

Re: DIP 1002 (TryElseExpression) added to the queue

On 9/28/2016 12:47 AM, Andrei Alexandrescu wrote: * Please remove colloquialisms. Characterizations such as "fantastically useful" are unlikely to be a convincing motivator and have no place in a DIP. * The motivation section should showcase examples that currently are not possible or are

FreeTree posible memory corruption ?

Look here : https://github.com/Hackerpilot/experimental_allocator/blob/master/src/std/experimental/allocator/building_blocks/free_tree.d#L297 It tries to find a block inside the tree. If it fails, it allocates n bytes passed to the function. Look a little down and you see a deallocate method.

[Issue 16563] New: [REG HEAD] Wrong struct size/alignment in local struct

https://issues.dlang.org/show_bug.cgi?id=16563 Issue ID: 16563 Summary: [REG HEAD] Wrong struct size/alignment in local struct Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: wrong-code

Re: DIP 1002 (TryElseExpression) added to the queue

On 9/28/16 1:56 PM, Steven Schveighoffer wrote: The more I think about this submission, I feel like the benefits are quite slim. The else clause is really simply a disabling of all the exception handlers at the end of the function. The uses seem very Didn't finish this sentence. "very

Re: DIP 1002 (TryElseExpression) added to the queue

On 9/28/16 7:58 AM, John Colvin wrote: On Wednesday, 28 September 2016 at 07:47:32 UTC, Andrei Alexandrescu wrote: * The "Breaking changes" section should include how the following change in semantics would be addressed. Consider: try if (expression) try { ... } catch

compile errors should show import chain (eg module is in file which cnanot be read)

oftentimes when compiling a program one gets errors such as: Error: module vibe is in file 'vibe/vibe.d' which cannot be read it can be hard to trace where is the offending file that imports said missing module. Could we also print the import chain in error message. eg: foo.bar => foo2.bar2 =>

[Issue 16562] New: Icon for D files

https://issues.dlang.org/show_bug.cgi?id=16562 Issue ID: 16562 Summary: Icon for D files Product: D Version: D2 Hardware: x86_64 OS: All Status: NEW Severity: enhancement Priority: P1

[Issue 16561] New: API documentation: C runtime behavior of std.ascii.newline

https://issues.dlang.org/show_bug.cgi?id=16561 Issue ID: 16561 Summary: API documentation: C runtime behavior of std.ascii.newline Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW

Re: Macintosh text file with invalid line breaks are created

On Wednesday, 28 September 2016 at 16:53:24 UTC, Vladimir Panteleev wrote: On Wednesday, 28 September 2016 at 06:52:51 UTC, Andre Pany wrote: Since the file is opened in text mode (which is the default), the C runtime automatically translates the single \n to a \r\n pair when writing the

Re: Problem parsing IPv4/IPv6 addresses with std.socket.parseAddress

On Wednesday, 28 September 2016 at 16:49:54 UTC, Vladimir Panteleev wrote: On Wednesday, 28 September 2016 at 15:34:56 UTC, Dsciple wrote: I don't understand what prevents such function (in turn calling some OS-level C function) from doing its job at compile time too. Guess it's a very

Re: The XML and JSON library

On Monday, 26 September 2016 at 09:29:55 UTC, Chris wrote: On Sunday, 25 September 2016 at 09:12:03 UTC, Lodovico Giaretta wrote: On Sunday, 25 September 2016 at 08:26:58 UTC, Basile B. wrote: And... It's almost ready. I just have to find some time to finish up some bits and add more

Re: Parameterized delegate attributes

On Wednesday, 28 September 2016 at 16:20:18 UTC, Eyal Lotem wrote: [...] I would just make opApply a templated function, for the following reasons: 1) You are saying that having this feature in the language would spare some template instantiations and code generations; but a good compiler

[Issue 11870] replace dynamic symbol table (--export-dynamic) for backtraces

https://issues.dlang.org/show_bug.cgi?id=11870 --- Comment #6 from yazan.dab...@gmail.com --- I don't think this should be closed. The implementation only provides file and line information. Function names are still extracted using `backtrace_symbols` which, AFAIR, need `--export-dynamic`. BTW,

[Issue 11870] replace dynamic symbol table (--export-dynamic) for backtraces

https://issues.dlang.org/show_bug.cgi?id=11870 Martin Nowak changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 11870] replace dynamic symbol table (--export-dynamic) for backtraces

https://issues.dlang.org/show_bug.cgi?id=11870 Martin Nowak changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co

[Issue 7454] Add file and line numbers to Linux stack traces using addr2line

https://issues.dlang.org/show_bug.cgi?id=7454 Martin Nowak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: Problem parsing IPv4/IPv6 addresses with std.socket.parseAddress

On Wednesday, 28 September 2016 at 15:34:56 UTC, Dsciple wrote: I don't understand what prevents such function (in turn calling some OS-level C function) from doing its job at compile time too. Guess it's a very challanging thing to do at compile-time, or should I open an issue with the

Parameterized delegate attributes

struct Example { int opApply(int delegate(int x) dlg) const { return dlg(0); } } Example.opApply now cannot be used in a @nogc context, even though it is fully @nogc whenever dlg is. Ditto with nothrow, pure, @safe and other attributes. For a large code-base containing

Make your language unusable: D is missing in the list

http://codegolf.stackexchange.com/questions/61115/make-your-language-unusable?page=1=votes#tab-top Destroy, literally! :)

Re: Overloading relational operators separately; thoughts?

On Wednesday, 28 September 2016 at 14:27:58 UTC, Chris Wright wrote: Increment, decrement, and test for equality is sufficient mathematically, but we want programs that terminate in our lifetimes. Only for BigInts you need those three. For ints decrement is not needed. And for most other

Re: Problem parsing IPv4/IPv6 addresses with std.socket.parseAddress

On Wednesday, 28 September 2016 at 09:56:06 UTC, Marc Schütz wrote: You could solve the problem as you suggested by moving the initializations into a constructor, but if your default values are only ever IPs (i.e., no hostname resolution necessary), you could also add an additional function

Re: DIP 1002 (TryElseExpression) added to the queue

On Wednesday, 28 September 2016 at 11:17:05 UTC, pineapple wrote: On Wednesday, 28 September 2016 at 07:47:32 UTC, Andrei Alexandrescu wrote: * I saw in the forum that the "else" clause is supposed to run in the scope of the "try" statement, but that is not mentioned in the proposal. Even

Re: How to Write @trusted Code in D

On Wednesday, 28 September 2016 at 14:44:17 UTC, Mike Parker wrote: Are you referring to ssize_t? If so, that's not a typo. It's the signed version of size_t. The * should be next to the void, though. I thought you meant size_t, but glad to know that I wasn't totally wrong.

Re: :end to terminate attribute:

On Wednesday, 28 September 2016 at 10:14:25 UTC, Mike Parker wrote: Yeah, that's what I couldn't remember. I'll dig up the discussion read up on it again. These two DIPs drafts also try to tackle the attribute problem: http://wiki.dlang.org/DIP64 http://wiki.dlang.org/DIP79

Re: D, ZeroMQ, Nanomsg

On Wednesday, 28 September 2016 at 11:55:15 UTC, JN wrote: On Wednesday, 28 September 2016 at 11:53:05 UTC, Russel Winder wrote: Hi, I see that some people have wrapped in various different ways ZeroMQ. Was this manually, or using DStep? Has anyone wrapped Nanomsg? If yes, was this manually

Re: How to Write @trusted Code in D

On Wednesday, 28 September 2016 at 14:34:20 UTC, jmh530 wrote: On Wednesday, 28 September 2016 at 14:02:45 UTC, Mike Parker wrote: Steven Schveighoffer has contributed an article to the blog explaining @trusted and advising on its proper usage. Post:

Re: How to Write @trusted Code in D

On Wednesday, 28 September 2016 at 14:02:45 UTC, Mike Parker wrote: Steven Schveighoffer has contributed an article to the blog explaining @trusted and advising on its proper usage. Post: https://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/ Reddit:

Re: Overloading relational operators separately; thoughts?

On Wed, 28 Sep 2016 10:06:43 +, pineapple wrote: > I think the cleanest possible solution would be to allow comparison > operators to be overridden with opBinary and opBinaryRight, as well, but > use opCmp and opEquals instead if they exist. I can't think of any way > this would break existing

Re: Overloading relational operators separately; thoughts?

On Tue, 27 Sep 2016 23:05:54 -0700, Jonathan M Davis via Digitalmars-d wrote: > On Wednesday, September 28, 2016 03:28:50 Minty Fresh via Digitalmars-d > wrote: >> Lastly, if operators are intended to behave so strictly, why does this >> not extend then to binary arithmetic operators (+, -, *, /,

Re: Overloading relational operators separately; thoughts?

On Wednesday, 28 September 2016 at 13:58:35 UTC, Timon Gehr wrote: Assume I have two symbolic expressions a and b: Expression a=variable("a"), b=variable("b"); Why should I be allowed to do auto c = a + b; // symbolic value a + b but not auto d = a <= b; // symbolic value a <= b The string

How to Write @trusted Code in D

Steven Schveighoffer has contributed an article to the blog explaining @trusted and advising on its proper usage. Post: https://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/ Reddit:

Re: Overloading relational operators separately; thoughts?

On 28.09.2016 06:02, Walter Bright wrote: On 9/27/2016 6:18 PM, Minty Fresh wrote: So, I'm just interested in other people's thoughts are on the subject, and whether there are any plans to allow overloading these operators separately. The limitations are deliberate based on the idea that

Re: DIP 1002 (TryElseExpression) added to the queue

I submitted a PR addressing some of the mentioned criticisms: https://github.com/dlang/DIPs/pull/46

Re: Overloading relational operators separately; thoughts?

On 28.09.2016 11:48, Matthias Bentrup wrote: On Wednesday, 28 September 2016 at 04:02:59 UTC, Walter Bright wrote: The limitations are deliberate based on the idea that comparison operators need to be consistent and predictable, and should have a close relationship to the mathematical meaning

Re: Diet-NG 1.0.0 released

Sönke, I am your biggest fan, but you never reply me. Hm, definitely sorry about that! I miss a certain percentage of issues/forum messages these days because of the limited time I have left for processing them. But if you have a link, I'll try to reply ASAP! Is this guy a bot ? Seems so

Re: D, ZeroMQ, Nanomsg

On Wednesday, 28 September 2016 at 11:53:05 UTC, Russel Winder wrote: Hi, I see that some people have wrapped in various different ways ZeroMQ. Was this manually, or using DStep? Has anyone wrapped Nanomsg? If yes, was this manually or using DStep. derelict_extras-nanomsg was converted

Re: D, ZeroMQ, Nanomsg

On Wednesday, 28 September 2016 at 11:53:05 UTC, Russel Winder wrote: Hi, I see that some people have wrapped in various different ways ZeroMQ. Was this manually, or using DStep? Has anyone wrapped Nanomsg? If yes, was this manually or using DStep. http://code.dlang.org/packages/nanomsg

Re: DIP 1002 (TryElseExpression) added to the queue

On Wednesday, 28 September 2016 at 07:47:32 UTC, Andrei Alexandrescu wrote: * The "Breaking changes" section should include how the following change in semantics would be addressed. Consider: try if (expression) try { ... } catch (Exception) { ... } else { ... }

Re: D, ZeroMQ, Nanomsg

On Wednesday, 28 September 2016 at 11:53:05 UTC, Russel Winder wrote: Hi, I see that some people have wrapped in various different ways ZeroMQ. Was this manually, or using DStep? Has anyone wrapped Nanomsg? If yes, was this manually or using DStep. Not sure how they did it, but there are

D, ZeroMQ, Nanomsg

Hi, I see that some people have wrapped in various different ways ZeroMQ. Was this manually, or using DStep? Has anyone wrapped Nanomsg? If yes, was this manually or using DStep. -- Russel. = Dr Russel Winder t:

Re: DIP 1002 (TryElseExpression) added to the queue

On 09/28/2016 09:47 AM, Andrei Alexandrescu wrote: > ... I have added references to both your and Walter comments to DIP1002 review section: https://github.com/dlang/DIPs/pull/44 signature.asc Description: OpenPGP digital signature

Re: DIP 1002 (TryElseExpression) added to the queue

On 09/28/2016 01:17 PM, pineapple wrote: > On Wednesday, 28 September 2016 at 07:47:32 UTC, Andrei Alexandrescu wrote: >> * Please remove colloquialisms. Characterizations such as >> "fantastically useful" are unlikely to be a convincing motivator and >> have no place in a DIP. >> >> * The

Re: DIP 1002 (TryElseExpression) added to the queue

On Wednesday, 28 September 2016 at 10:50:00 UTC, Jack Stouffer wrote: On Wednesday, 28 September 2016 at 10:45:11 UTC, Andrei Alexandrescu wrote: Assertions such as "makes the code cleaner" are likely to add value only if backed up by evidence (case studies, realistic examples). This is

Re: DIP 1002 (TryElseExpression) added to the queue

On Wednesday, 28 September 2016 at 07:47:32 UTC, Andrei Alexandrescu wrote: * Please remove colloquialisms. Characterizations such as "fantastically useful" are unlikely to be a convincing motivator and have no place in a DIP. * The "Description" section should be more detailed and less

Re: DIP 1002 (TryElseExpression) added to the queue

On Wednesday, 28 September 2016 at 07:33:48 UTC, ikod wrote: Thanks! There is also useful for/else construct in Python https://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops I'd like to see it in D. While I appreciate being able to use

Re: :end to terminate attribute:

On 9/28/16 11:48 AM, ZombineDev wrote: AFAIR, last year or so, Andrei approved the proposal for attr(bool expr), eg: @nogc: // no gc code here @nogc(false): Yah, we've got to have something. There's been quibbles over syntax but nothing better came up that is as comprehensive. @nogc(true)

Re: DIP 1002 (TryElseExpression) added to the queue

On Wednesday, 28 September 2016 at 10:45:11 UTC, Andrei Alexandrescu wrote: Assertions such as "makes the code cleaner" are likely to add value only if backed up by evidence (case studies, realistic examples). This is based on my anecdotal experience. I also posted an example in the original

Re: DIP 1002 (TryElseExpression) added to the queue

On 9/28/16 12:19 PM, Jack Stouffer wrote: On Tuesday, 27 September 2016 at 09:30:10 UTC, Dicebot wrote: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md PR: https://github.com/dlang/DIPs/pull/43 Abstract: In Python, the try/catch/finally syntax is augmented with an additional

Re: DIP 1002 (TryElseExpression) added to the queue

On Tuesday, 27 September 2016 at 09:30:10 UTC, Dicebot wrote: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md PR: https://github.com/dlang/DIPs/pull/43 Abstract: In Python, the try/catch/finally syntax is augmented with an additional clause, termed else. It is a fantastically

Re: :end to terminate attribute:

On Wednesday, 28 September 2016 at 09:48:27 UTC, ZombineDev wrote: AFAIR, last year or so, Andrei approved the proposal for attr(bool expr), eg: Yeah, that's what I couldn't remember. I'll dig up the discussion read up on it again.

Re: Overloading relational operators separately; thoughts?

I'd also like to point out a generally sound design principle: Give the programmer as much power and flexibility as possible - but don't forget to provide tools for simplifying common use cases, and don't forget to define sensible defaults. It makes a lot of sense that opCmp and opEquals

Re: Overloading relational operators separately; thoughts?

On Wednesday, 28 September 2016 at 03:28:50 UTC, Minty Fresh wrote: Using strings and mixins does have quite a number of downsides. The additional work required to past the DSL aside, you also usually lose the scope in which things are declared (especially if you wish to reference or declare

Re: Reinstalled Mac

On Wednesday, 28 September 2016 at 09:34:23 UTC, Mike Parker wrote: Use the DMD installer instead on dlang.org Any particular reason? I've been using homebrew for it. I like the simple command line update. Not really. I didn't know it was up-to-date. Las time I tried it wasn't up-to-date

Re: Problem parsing IPv4/IPv6 addresses with std.socket.parseAddress

On Tuesday, 27 September 2016 at 14:57:26 UTC, Dsciple wrote: struct ConfigParams { // ... // Define configuration parameters' static default fields static immutable BindAddresses defaultBindAddresses = BindAddresses([ BindAddress("192.168.2.10") ]); // ... } Yepp, that's

Re: :end to terminate attribute:

On Wednesday, 28 September 2016 at 09:48:27 UTC, ZombineDev wrote: On Wednesday, 28 September 2016 at 09:43:38 UTC, Mike Parker wrote: [...] AFAIR, last year or so, Andrei approved the proposal for attr(bool expr), eg: @nogc: // no gc code here @nogc(false): // code that's allowed to

Re: Overloading relational operators separately; thoughts?

On Wednesday, 28 September 2016 at 04:02:59 UTC, Walter Bright wrote: The limitations are deliberate based on the idea that comparison operators need to be consistent and predictable, and should have a close relationship to the mathematical meaning of the operators. In Mathematics the

Re: Required DMD changes for Mir and few thoughts about D future

On Wednesday, 28 September 2016 at 09:41:02 UTC, Jacob Carlborg wrote: On 2016-09-28 11:06, Ilya Yaroshenko wrote: Done. Full DMD performance Issues related to Mir list can be found here https://github.com/libmir/mir/wiki/Compiler-and-druntime-bugs#dmd-performance-issues It found be better

Re: :end to terminate attribute:

On Wednesday, 28 September 2016 at 09:43:38 UTC, Mike Parker wrote: Let's try this again. This attribute block can be terminated by a corresponding protection attribute block: // Begin private private: void foo() {} // End private public: void bar() {} But not all attributes have a

  1   2   >