Re: Confused about github rebasing
On 2012-03-16 04:52, James Miller wrote: Also, git-svn isn't actually that bad... It is. You can't properly use git because you have to make sure it's compatible with svn, like linear history. If you don't have a linear history you're in big trouble. -- /Jacob Carlborg
Re: Confused about github rebasing
On Friday, March 16, 2012 08:52:47 Jacob Carlborg wrote: On 2012-03-16 04:52, James Miller wrote: Also, git-svn isn't actually that bad... It is. You can't properly use git because you have to make sure it's compatible with svn, like linear history. If you don't have a linear history you're in big trouble. Yeah. I use git-svn at work, because I like it a lot better than using pure svn, but it's _nowhere_ near as good as pure git. There are just too many features that you have to be careful with or avoid. - Jonathan M Davis
State of D toolchain architecture support?
Hello, I am currently evaluating D2, and have questions. Language-wise, D2 looks very interesting to me. I do have concerns about the toolchain and architecture support, however. First of all, there is DMD, LDC, GDC. Of these three, LDC seems to be preferred. x86-64 support is apparently solid, at least I was able to make 64-bit builds with LDC. But what about ARM? If I understand this correctly, the real question is whether or not the druntime library supports the architecture properly. This does not seem to be the case with druntime and ARM. Threads like http://www.digitalmars.com/d/archives/digitalmars/D/druntime_140097.html do not sound promising. I do not wish to spend time learning something with a shoddy base. If I am to port or create projects with the language, I need solid architecture and compiler support. Can some D users enlighten me about the current state? Platforms I wish to support: win32 and linux. Architectures: ARM (v5, v7), x86 (32 and 64 bit), perhaps also SH4 and MIPS, though these two are not necessary right now.
Re: regex issue
On 16.03.2012 7:36, Joshua Niehus wrote:
Hello,
Does anyone know why I would get different results between
ctRegex and regex in the following snippet?
Ehm, because they have different engines that _should_ give identical
results. And the default one apparently has a bug, that I'm looking into.
Fill the bug report plz.
Thanks,
Josh
---
#!/usr/local/bin/rdmd
import std.stdio, std.regex;
void main() {
string strcmd = ./myApp.rb -os OSX -path \/GIT/Ruby
Apps/sec\ -conf 'no timer';
auto ctre = ctRegex!(`(.*)|('.*')`, g);
auto re = regex (`(.*)|('.*')`, g);
auto ctm = match(strcmd, ctre);
foreach(ct; ctm)
writeln(ct.hit());
auto m = match(strcmd, re);
foreach(h; m)
writeln(h.hit());
}
/* output */
/GIT/Ruby Apps/sec
'no timer'
/GIT/Ruby Apps/sec
--
Dmitry Olshansky
Re: Confused about github rebasing
On 2012-03-16 09:08, Jonathan M Davis wrote: On Friday, March 16, 2012 08:52:47 Jacob Carlborg wrote: On 2012-03-16 04:52, James Miller wrote: Also, git-svn isn't actually that bad... It is. You can't properly use git because you have to make sure it's compatible with svn, like linear history. If you don't have a linear history you're in big trouble. Yeah. I use git-svn at work, because I like it a lot better than using pure svn, but it's _nowhere_ near as good as pure git. There are just too many features that you have to be careful with or avoid. Exactly, you need to be very careful and follow a strict workflow to avoid breaking svn. -- /Jacob Carlborg
Re: regex issue
On Friday, 16 March 2012 at 08:34:18 UTC, Dmitry Olshansky wrote: Ehm, because they have different engines that _should_ give identical results. And the default one apparently has a bug, that I'm looking into. Fill the bug report plz. Ok, submitted: id 7718 Thanks, Josh
Re: State of D toolchain architecture support?
On Friday, 16 March 2012 at 08:23:39 UTC, dv wrote: I do not wish to spend time learning something with a shoddy base. If I am to port or create projects with the language, I need solid architecture and compiler support. Can some D users enlighten me about the current state? Platforms I wish to support: win32 and linux. Architectures: ARM (v5, v7), x86 (32 and 64 bit), perhaps also SH4 and MIPS, though these two are not necessary right now. At this I can not recommend you use D based on your requirements. Support for Windows and Linux, however we don't have a good selection of users making use of different architectures such as those you list. LDC is not Windows friendly (LLVM does not support exceptions on Windows). It would be nice for you to join the community and try getting some pet projects working on the platforms you desire, as the community is in need of some solid work in this direction.
Capturing caller's file/line number in variadic template functions
I'm writing some unittests with very repetitive tests for a myriad of
different types, so I wrote a helper function:
version(unittest) {
void checkConsistency(T...)(T args) {
foreach (a; args) {
assert(isConsistent(a));
}
}
}
unittest {
A a;
B b;
C c;
checkConsistency(a,b,c);
}
However, when a consistency check fails, the assert error points to
checkConsistency instead of the unittest, so it's a pain trying to
figure out exactly which test case failed. I tried adding default
arguments to checkConsistency:
void checkConsistency(T...)(T args, string file=__FILE__,
size_t line=__LINE__) { ... }
but this causes compile errors because when C==string, then the call is
ambiguous.
Is there an easy of working around this?
T
--
To err is human; to forgive is not our policy. -- Samuel Adler
Re: Capturing caller's file/line number in variadic template functions
16.03.2012 20:23, H. S. Teoh пишет:
I'm writing some unittests with very repetitive tests for a myriad of
different types, so I wrote a helper function:
version(unittest) {
void checkConsistency(T...)(T args) {
foreach (a; args) {
assert(isConsistent(a));
}
}
}
unittest {
A a;
B b;
C c;
checkConsistency(a,b,c);
}
However, when a consistency check fails, the assert error points to
checkConsistency instead of the unittest, so it's a pain trying to
figure out exactly which test case failed. I tried adding default
arguments to checkConsistency:
void checkConsistency(T...)(T args, string file=__FILE__,
size_t line=__LINE__) { ... }
but this causes compile errors because when C==string, then the call is
ambiguous.
Is there an easy of working around this?
T
What happens if you insert some dummy type ?:
void checkConsistency(T...)(T args, Delimiter dm = Delimiter.init,
string file=__FILE__, size_t line=__LINE__) { ... }
Re: Capturing caller's file/line number in variadic template functions
On Friday, 16 March 2012 at 18:21:54 UTC, H. S. Teoh wrote:
void checkConsistency(T...)(T args, string file=__FILE__,
size_t line=__LINE__) { ... }
but this causes compile errors because when C==string, then the
call is
ambiguous.
Is there an easy of working around this?
Put the string file = blaha in the template argument list,
before the variadic.
voic checkConsistency(string file = __FILE__, int line =
__LINE__, T...)(T t) {
Re: Capturing caller's file/line number in variadic template functions
On Mar 16, 2012 2:29 PM, Adam D. Ruppe destructiona...@gmail.com wrote:
Put the string file = blaha in the template argument list,
before the variadic.
voic checkConsistency(string file = __FILE__, int line = __LINE__,
T...)(T t) {
But then you have to write it each time.
Re: Capturing caller's file/line number in variadic template functions
On Fri, Mar 16, 2012 at 08:26:30PM +0200, Mantis wrote:
16.03.2012 20:23, H. S. Teoh пишет:
I'm writing some unittests with very repetitive tests for a myriad of
different types, so I wrote a helper function:
version(unittest) {
void checkConsistency(T...)(T args) {
foreach (a; args) {
assert(isConsistent(a));
}
}
}
unittest {
A a;
B b;
C c;
checkConsistency(a,b,c);
}
However, when a consistency check fails, the assert error points to
checkConsistency instead of the unittest, so it's a pain trying to
figure out exactly which test case failed. I tried adding default
arguments to checkConsistency:
void checkConsistency(T...)(T args, string file=__FILE__,
size_t line=__LINE__) { ... }
but this causes compile errors because when C==string, then the call is
ambiguous.
[...]
What happens if you insert some dummy type ?:
void checkConsistency(T...)(T args, Delimiter dm = Delimiter.init,
string file=__FILE__, size_t line=__LINE__) { ... }
Actually, I found the solution: the compiler understands __FILE__ and
__LINE__ in compile-time arguments too, so this works:
void checkConsistency(string file=__FILE__, size_t
line=__LINE__, T...)(T args)
{
...
}
It's a bit painful with the assert statement, because it doesn't let you
control the file/line number of the AssertError, but this can be worked
around by using std.string.format:
assert(isConsistent(a),
inconsistency found in %s(%d).format(file,line));
The AssertError will still point to checkConsistency, but the error
message will tell you where the caller is.
T
--
The early bird gets the worm. Moral: ewww...
Re: Capturing caller's file/line number in variadic template functions
On Fri, 16 Mar 2012 14:23:37 -0400, H. S. Teoh hst...@quickfur.ath.cx
wrote:
I'm writing some unittests with very repetitive tests for a myriad of
different types, so I wrote a helper function:
version(unittest) {
void checkConsistency(T...)(T args) {
foreach (a; args) {
assert(isConsistent(a));
}
}
}
unittest {
A a;
B b;
C c;
checkConsistency(a,b,c);
}
However, when a consistency check fails, the assert error points to
checkConsistency instead of the unittest, so it's a pain trying to
figure out exactly which test case failed.
I know this is already answered, but do you get a stack trace? Shouldn't
the second stack frame point to the offending line?
-Steve
Re: Capturing caller's file/line number in variadic template functions
On Fri, Mar 16, 2012 at 02:31:47PM -0400, Kevin Cox wrote:
On Mar 16, 2012 2:29 PM, Adam D. Ruppe destructiona...@gmail.com wrote:
Put the string file = blaha in the template argument list,
before the variadic.
voic checkConsistency(string file = __FILE__, int line = __LINE__,
T...)(T t) {
But then you have to write it each time.
No you don't. The compiler automatically infers the compile-time
arguments for you. This works:
int a;
char b;
float c;
checkConsistency(a,b,c);
// Gets translated to:
checkConsistency!(__FILE__, __LINE__, int, char, float)(a,b,c);
exactly as I wanted.
T
--
People say I'm arrogant, but they're just ignorant fools.
Re: Capturing caller's file/line number in variadic template functions
On Friday, 16 March 2012 at 18:31:58 UTC, Kevin Cox wrote: But then you have to write it each time. Nah, it just works, at least for the implicit calls: checkConsistency(1, 2, 3); // calls checkConsistenct!(__FILE__, __LINE__, int, string, int)(1, 2, 3);
Re: Capturing caller's file/line number in variadic template functions
On Fri, Mar 16, 2012 at 02:30:25PM -0400, Steven Schveighoffer wrote: [...] I know this is already answered, but do you get a stack trace? Shouldn't the second stack frame point to the offending line? [...] I didn't compile with debugging turned on, so it only showed a hex address. Using compile-time args for __FILE__ and __LINE__ lets me see the offending line even when debug is off. (And actually, the offending line is several frames down; the top few frames look like unittest scaffolding the compiler inserted for catching assert errors and handling unittest-specific stuff. Kinda painful to figure out where the problem is if a straight error message will tell you immediately. :-)) T -- Indifference will certainly be the downfall of mankind, but who cares? -- Miquel van Smoorenburg
Re: Capturing caller's file/line number in variadic template functions
16.03.2012 20:35, H. S. Teoh пишет:
[...]
Actually, I found the solution: the compiler understands __FILE__ and
__LINE__ in compile-time arguments too, so this works: void
checkConsistency(string file=__FILE__, size_t line=__LINE__, T...)(T
args) { ... } It's a bit painful with the assert statement, because it
doesn't let you control the file/line number of the AssertError, but
this can be worked around by using std.string.format:
assert(isConsistent(a), inconsistency found in
%s(%d).format(file,line)); The AssertError will still point to
checkConsistency, but the error message will tell you where the caller
is. T
Yes, but the code is duplicated per every instance of template, and
template is instantiated whenever it's CT-parameters change. This isn't
much of a problem with functions that are meant to run at compile-time
only (except that static locals will not work properly), but for
run-time functions that may be undesired.
Re: Capturing caller's file/line number in variadic template functions
On Fri, 16 Mar 2012 14:41:40 -0400, H. S. Teoh hst...@quickfur.ath.cx wrote: On Fri, Mar 16, 2012 at 02:30:25PM -0400, Steven Schveighoffer wrote: [...] I know this is already answered, but do you get a stack trace? Shouldn't the second stack frame point to the offending line? [...] I didn't compile with debugging turned on, so it only showed a hex address. Using compile-time args for __FILE__ and __LINE__ lets me see the offending line even when debug is off. (And actually, the offending line is several frames down; the top few frames look like unittest scaffolding the compiler inserted for catching assert errors and handling unittest-specific stuff. Kinda painful to figure out where the problem is if a straight error message will tell you immediately. :-)) Right, but I dislike this sort of boilerplaty stuff, especially for unit tests. It should be avoidable... -Steve
Re: preprocessor pass equivalent?
On Thu, Mar 15, 2012 at 02:51:33PM +0100, Adam D. Ruppe wrote: On Thursday, 15 March 2012 at 08:35:48 UTC, Jay Norwood wrote: Is there some option, similar to -E gcc option, that would generate the analogous listing for D? You could add one to the compiler in just a few lines; there's already a function that does it, but it isn't called from anywhere. [...] Alright, so I hacked dmd a little to make this a runtime option: I changed the default symfile extension from .d to .ds so that it won't overwrite the original source files, and added the option -sym to turn it on/off. Check it out: https://github.com/quickfur/dmd/tree/gensymfile Playing around with it a little, I notice that it doesn't output template bodies, even though calls to template functions are left intact. It also doesn't expand [] into opIndex/opIndexAssign, for example. So you can't actually compile the output if you're using templates, AFAICT. I'm guessing that by this point the compiler has stored all templates in a symbol table somewhere, so it only has the bare template declarations left. T -- The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator.
Re: preprocessor pass equivalent?
On Saturday, 17 March 2012 at 00:13:33 UTC, H. S. Teoh wrote: Playing around with it a little, I notice that it doesn't output template bodies, even though calls to template functions are left intact. It also doesn't expand [] into opIndex/opIndexAssign, I didn't play with this yet.. but it might not have to do this. On arrays, [] is a primitive, not a function. opIndex should only show up on custom types. For the templates, I'd be surprised if they weren't there somewhere. My D - JS code works in the same location (after running semantic) and templates just work in there. The instantiations might be in a weird place though.
Re: preprocessor pass equivalent?
On Sat, Mar 17, 2012 at 01:21:56AM +0100, Adam D. Ruppe wrote: On Saturday, 17 March 2012 at 00:13:33 UTC, H. S. Teoh wrote: Playing around with it a little, I notice that it doesn't output template bodies, even though calls to template functions are left intact. It also doesn't expand [] into opIndex/opIndexAssign, I didn't play with this yet.. but it might not have to do this. On arrays, [] is a primitive, not a function. opIndex should only show up on custom types. Yes, but I was testing with my custom AA implementation. For the templates, I'd be surprised if they weren't there somewhere. My D - JS code works in the same location (after running semantic) and templates just work in there. The instantiations might be in a weird place though. Could be. I didn't really do much, just copied the code from your previous email as-is. I don't know enough about dmd internals to be able to do much more (though I'll have to get up to speed soon, if my AA implementation ends up going into druntime). T -- IBM = I'll Buy Microsoft!
Re: Capturing caller's file/line number in variadic template functions
On Friday, 16 March 2012 at 18:21:54 UTC, H. S. Teoh wrote:
void checkConsistency(T...)(T args, string file=__FILE__,
size_t line=__LINE__) { ... }
but this causes compile errors because when C==string, then the
call is
ambiguous.
Does it make sense to consider to add a new type to hold the file
name and line? So the types clash can be avoided:
class file_line
{
this(string f=__FILE__, size_t ln=__LINE__)
{
file = f;
line = ln;
}
string file;
size_t line;
};
void checkConsistency(T...)
(T args, file_line pos = new file_line) {...}
checkConsistency!(A,B,C)(a,b,c);
Seems to work, but requires an explicit checkConsistency call - I
didn't manage to make it implicit.
