Re: Feature idea: scope (failure, ExceptionSpecification) for catching exceptions
On 3/26/15, Vladimir Panteleev via Digitalmars-d wrote: > What is your use case for only logging specific exception types? We already have scope(failure) with its defined semantics (it will not swallow the exception), changing that would be bad. So the only workable solution I see is to extend it via 'scope(failure, ExceptionType ex)'. It's not that I want to catch specific exceptions, but instead I really love using scope but often find myself wishing I could catch the exception, swallow it (not rethrow it) and log it, without a try/catch. Sometimes you're not allowed to propagate an exception (think nothrow functions, functions that interact with C, functions invoked in different threads, etc), so you have to try/catch and use logging. I kind of think extending scope could make this nicer to work with. It was just a passing thought, though. :)
Re: Advise for syntax highlighting
On 2015-03-28 01:01, Jesse Phillips wrote: Statement [e.g. debug, return, function, with] (that needs fixed) Not sure what you mean. Probably should be Identifier for consistency [e.g. _arugments, __vptr, _ctor] I completely forgot about these. Should these be the same as __ctfe? Which I guess is your third (special recognized built-in), though __LINE__ is a constant in Vim's highlighting [e.g. null, __VERSION__]. Yeah, both null and __LINE__ are constants in TextMate as well. I probably didn't use the correct name for describing it. * __traits identifiers __traits(allMembers, Foo); In this case "allMembers". Basically the same question and alternatives as for the "__ctfe" variable. Identifier Same as __LINE__ or? -- /Jacob Carlborg
Re: readln() doesn't stop to read the input.
On Saturday, 28 March 2015 at 03:07:31 UTC, jonaspm wrote:
module main;
import std.stdio;
import std.string;
int main(string[] args)
{
int resp;
char[] p, q;
writefln("MENU DE OPCIONES");
writefln("1) Modus Ponens");
writefln("2) Modus Tollens");
writefln("3) Silogismo Hipotetico");
writefln("4) Salir");
do{
writeln("Introduce la opcion que deseas: ");
readf(" %d", &resp);
}while(resp<1 || resp>4);
write("Write p:");
readln(p); // This is skipped. ¿?
p = chomp(p);
write("Write q:");
readln(q);
q = chomp(q);
writeln("p: ",p); // Doesn't write anything.
writeln("q: ",q); // Writes what you typed in the keyboard
back on readln();
return 0;
}
The problem is that the `readf` call doesn't read the first line
completely. It leaves the newline. The first `readln` call then
picks up that newline and stops right there, resulting in an
empty line.
I'm not sure how the `readf` could be changed to consume the
newline. I tried " %d\n" and " %d ". They don't seem to do it.
But you can add a `readln();` after the `readf` call and it works.
Re: Advise for syntax highlighting
On Saturday, 28 March 2015 at 00:01:48 UTC, Jesse Phillips wrote: Probably should be Identifier for consistency [e.g. _arugments, __vptr, _ctor] Isn't __ctor just a DMD thing? I don't think we should be highlighting symbols which aren't guaranteed to even exist for a particular implementation.
Re: A reason to choose D over Go
On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote: On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote: On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote: I actually think that there are two large categories of programmers: those like writing the same loops over and over again and those who use algorithms. I agree, at some point I learned that there is a huge cultural distinction between C and C++ programmers. yes, the other main distinction are the people who correctly put the * next to the type because it's part of the type, or the wrong people who put it next to the variable name because they're heathens +1
Re: Human unreadable documentation - the ugly seam between simple D and complex D
On Friday, 27 March 2015 at 18:38:32 UTC, rumbu wrote: schwartzSort it's a nice name only if you are German. Hardly. The name's just as meaningless on its own. It may be easier for us Germans to remember the spelling, but even we have to memorize that "tz", as "schwarz" (black) is more common a word.
Re: readln() doesn't stop to read the input.
You can clear the input stream:
while(getchar() != '\n') {};
Or just use readln:
int resp = readln.chomp.to!int;
Re: Human unreadable documentation - the ugly seam between simple D and complex D
D has documented unittests (they appear in the docs as if part of the Examples section). The only excuses for example code in Phobos to be untested are supposed to be that it is an incomplete fragment or that it is old code from before we had the feature. — David I added some just recently, because it wasn't possible to add unittest to the module level. https://github.com/D-Programming-Language/phobos/blob/master/std/container/package.d
Re: What Features Should A GUI toolkit have?
I'd like to see D with GUI framework like JUCE. That's what would make me use D more. For now I'll stick with C++ and JUCE. I know it sounds superficial to have your choice of language based so much on GUI, but I write software for average people to use, not for other programmers (and not for servers). Average people use GUIs. I like with JUCE how it's very easy to make your own UI elements when you need to by using drawing primitives inside a paint() function. Then you can apply transforms to zoom in/out or manipulate easily.
Re: A reason to choose D over Go
On 2015-03-27 19:27:37 +, Martin Nowak said: On Friday, 27 March 2015 at 19:00:16 UTC, Chris wrote: "Also, and this counts for something I think, Go is a trendy language right now, so when it comes to recruiting, I think having Go as a critical part of Repustate’s tech stack will help." Stop the world, I wanna get out! I was recently told by a commercial D user, that using D helps them to more easily identify good programmers. Every programmer I know who was worth their salt was at least interested in D. -S.
Re: Mono-D on downloads page?
https://github.com/D-Programming-Language/dlang.org/pull/946
DIP66 1.2 (Multiple) alias this. Continuation of work.
http://wiki.dlang.org/DIP66 First I want to apologize for the long absence. I was very busy for those months and now I ready to continue the work. This DIP has been approved with three clarifications: about is-expression, about opDispatch and about "common" inheritance. I've reflected those clarifications in this DIP version, and if it is OK, I'll start adaptation of my github PR to this DIP.
Re: Why dont dlang check NullPointer?
On Thu, Mar 26, 2015 at 9:13 PM, deadalnix via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Friday, 27 March 2015 at 03:59:30 UTC, zhmt wrote: > >> >>> The best way to do that is to separate the server modules into >>> independent processes. Then if one crashes, the others keep running without >>> fear of corruption. >>> >>> So instead of server modules, try doing mini servers that communicate >>> with the main server. This is how a lot of newer programs are written >>> because of the reliability and security benefits it offers. >>> >> >> But this will make the developement more difficult for me, or not >> acceptable. >> >> Is there any other ways? >> > > http://www.deadalnix.me/2012/03/24/get-an-exception-from-a- > segfault-on-linux-x86-and-x86_64-using-some-black-magic/ > > There is a hook in the runtime to enable this if you want. > You post only mentions linux, not OSX (and a comment showed: "According to several people I talked to, it is possible to do a similar stuff on BSD like systems (including OSX). But I’m really not a specialist of such platforms, so I can’t really explain you how." Could anyone post such a solution? If there's no easy way to do it, there should be a way (eg a compiler option) to throw an exception on null pointer access. Even if it's unsafe, it would help for debugging (eg printing relevant application specific context). This is made worse by the fact that stacktraces are not very helpful on OSX (eg line number often missing etc). > > BUT, null pointer exception or not, Adam is right. Have your stuff run in > multiple process that you can restart. This is more reliable, this is more > secure, this is easier to update without downtime, and so on... This is far > superior solution for server stuff. >
Re: Why dont dlang check NullPointer?
On Saturday, 28 March 2015 at 22:53:54 UTC, Timothee Cour wrote: If there's no easy way to do it, there should be a way (eg a compiler option) to throw an exception on null pointer access. Even if it's unsafe, it would help for debugging (eg printing relevant application specific context). This is made worse by the fact that stacktraces are not very helpful on OSX (eg line number often missing etc). In that case, it should be an Error, not an Exception, since it'll be disabled in release mode.
Re: Making byLine faster: we should be able to delegate this
What about hugepagesize system on LINUX ?
Re: Making byLine faster: we should be able to delegate this
Java has disruptor to provide the fatest way to ring file. website: http://lmax-exchange.github.io/disruptor/ technical information: http://lmax-exchange.github.io/disruptor/files/Disruptor-1.0.pdf
Re: [OT]: Congrats Andrei!
Congratz Andrei and Sanda
Re: DIP66 1.2 (Multiple) alias this. Continuation of work.
On Saturday, 28 March 2015 at 19:52:15 UTC, IgorStepanov wrote: http://wiki.dlang.org/DIP66 First I want to apologize for the long absence. I was very busy for those months and now I ready to continue the work. This DIP has been approved with three clarifications: about is-expression, about opDispatch and about "common" inheritance. I've reflected those clarifications in this DIP version, and if it is OK, I'll start adaptation of my github PR to this DIP. You're awesome, Igor. Thanks for taking on hard problems.
