Re: Simple GEdit .lang github color scheme
deadalnix wrote: Sound nice. How can I use that on my computer ? What do I do with the files ? You need to move the files into their 'gtksourceview-3.0' folders. On Linux (and other OS's should be similar), do: 1. find or create the following user directories: ~/.local/share/gtksourceview-3.0/styles ~/.local/share/gtksourceview-3.0/language-specs 2. Move the downloaded files into their respective folders, 'D.lang' to 'language-specs' and 'github.xml' to 'styles'. (Note, the download already contains this hierarchy) Alternatively (although I don't recommend it), you can move the files to: /usr/share/gtksourceview-3.0/... (overwriting the existing D.lang file) which will change it for all users. Hope that helps. Let me know if you have any problems, or find any highlighting bugs. Thanks.
Re: Review of Andrei's std.benchmark
Stepping back for a moment, I think we're facing two key issues here: The first key issue is that the docs for std.benchmark don't adequately explain Andre's intended charter/scope for it, it's methodology or the rationale for its methodology. So people see benchmark and they think oh, ok, for timing stuff, but it appears to be intended as being for very specific use-cases. I think this entire discussion serves as evidence that, at the very least, it needs to communicate that scope/methodology/rationale better that it currently does. If all of us are having trouble getting it, then others certainly will too. Aside from that, there's the second key issue: whether the current intended scope is sufficient. Should it be more general in scope and not so specialized? Personally, I would tend to think do, and I think that seems to the the popular notion. But I don't know for sure. If it should be more generalized, than does it need to be so for the first iteration, or can it be done later after being added to phobos? That, I have no idea.
Re: [OT] Was: totally satisfied :D
On Friday, 21 September 2012 at 21:37:23 UTC, Nick Sabalausky wrote: On Fri, 21 Sep 2012 22:13:22 +0200 Paulo Pinto pj...@progtools.org wrote: On Friday, 21 September 2012 at 19:09:48 UTC, H. S. Teoh wrote: The saddest thing is that people are paying big bucks for this kind of enterprise code. It's one of those things that make me never want to pay for *any* kind of software... why waste the money when you can download the OSS version for free? Yeah a lot of OSS code is crap, but it's not like it's any worse than the crap you pay for. Welcome to my world. As a Fortune 500 outsourcing consulting company employee, I see this type of code everyday. I find it depressing to see just how *easy* it is to have dailywtf-worthy material. They anonymized my name as Nate here: http://thedailywtf.com/Articles/We_Have_Met_the_Enemy.aspx Note also that the ' ...code here and ' ...more code here sections were typically HUGE. And that was only scratching the surface of the lunacy that was going on there - both in and out of the codebase. I've been sticking to contract stuff now, largely because I really just can't take that sort of insanity anymore (not that I ever could). If I ever needed to go back to 9-5 code, or cubicles, or open-floorplan warrooms, I'd *really* be in trouble. One of the reasons that keeps me in the company is the offer around my area. Many of the other companies I would work for, are the same type or I will be forced to switch region for something better. -- Paulo
Re: Review of Andrei's std.benchmark
On 2012-21-09 22:58:36, Andrei Alexandrescu wrote: On 9/21/12 5:39 AM, Jacob Carlborg wrote: After your replay to one of Manu's post, I think I misunderstood the std.benchmark module. I was thinking more of profiling. But are these quite similar tasks, couldn't std.benchmark work for both? This is an interesting idea. It would delay release quite a bit because I'd need to design and implement things like performance counters and such. I certainly think the two use cases are similar enough to warrant their inclusion in a common module. That does not preclude std.benchmark being included as is now, and extended with profiling features at some later point. -- Simen
Re: Infer function template parameters
On 2012-09-21, 21:29, Jonas Drewsen wrote: A mentioned in the proposal (albeit not very clear) it requires non-templated function definitions to include both type and param names. If only one name is provided in a definition is always a param name. Unfortunately this is a breaking change for some code and that does speak against the proposal. Not only is it a breaking change, it breaks one of the basic design desiderata of D - if it's valid C it either fails to compile or compiles with the same behavior as in C. -- Simen
Re: [OT] Was: totally satisfied :D
On Fri, 21 Sep 2012 15:37:46 -0700
H. S. Teoh hst...@quickfur.ath.cx wrote:
The sad part is that so many of the commenters have no idea that
adjacent C literals are concatenated at compile-time. It's a very nice
way to put long strings in code and have it nicely indented, something
that is sorely lacking in most languages. But regardless, why are they
posting if they clearly don't know C that well?!
Heh, actually I didn't even know about it until I learned it from D
and then learned that D got it from C (does D still do it, or is that
one of those to be deprecated things?)
But then dealing with strings is something I generally tried to avoid
in C anyway ;)
Note also that the ' ...code here and ' ...more code here
sections were typically HUGE.
Speaking of 1000-line functions... yeah I routinely work with those
monsters.
*cough* DMD's main() *cough* ;)
Although it's actually, surprisingly, not too bad in DMD's case, all
things considered. Took me by surprise at first though, I really wasn't
expecting it.
And that was only scratching the surface of the lunacy that was
going on there - both in and out of the codebase.
I have seen code whose function names are along the lines of do_it()
and do_everything(). As well as do_main() and
${program_name}_main() in addition to main().
What really gets me is that these are the sorts of things that are
harped on in chapter 1 of just about any decent intro to programming
book. So where did these people even learn to code in the first place?
Heck, back in college, I used to be a CS tutor for first semester
programming students. Even *they* wrote better code, no exaggeration.
(Well, except for the handful of students, and I could always tell which
ones they were, who were from the class of Mrs. Let's Teach OOP
*Before* Basic Flow Of Execution. Those poor students couldn't write
*any* code, let alone good or bad code. I felt bad for them.)
I've been sticking to contract stuff now, largely because I really
just can't take that sort of insanity anymore (not that I ever
could). If I ever needed to go back to 9-5 code, or cubicles, or
open-floorplan warrooms, I'd *really* be in trouble.
I really should start doing contract work. Being stuck with the same
project and dealing with the same stupid code that never gets fixed is
just very taxing on the nerves.
Yea, contract has it's upsides, although naturally it has it's own
perils too. Making a living at it is *damn* hard (either that or I'm
just REALLY bad at self-employment...but it's probably both), and
frankly I'm still trying to figure out how to do it.
And you can forget about health care if you're in the US: Non-group
premiums on insurance (read: legalized casinos without the neon lights
and cocktails) are just as expensive as paying out-of-pocket (remember,
the house *always* has the advantage), and that's if you're lucky enough
to have never had a gap in coverage. If you have, then your premiums
are literally buying you nothing unless you *ahem* win and get mangled
by a car or get a terminal disease or something.
Not to discourage you though. Everything sucks, it's just finding a
suck that you can live with, y'know ;) Personally, I'm still
looking...
Re: Extending unittests [proposal] [Proof Of Concept]
Am Fri, 21 Sep 2012 23:15:33 +0200
schrieb Jens Mueller jens.k.muel...@gmx.de:
I like the BOOST unit test library's approach, which has two types
of assert: BOOST_CHECK and BOOST_REQUIRE. After a BOOST_CHECK
fails, the test keeps running, but BOOST_REQUIRE throws an exception
to stop the test. When testing a series of inputs in a loop, it is
useful (for debugging) to see the complete set of which ones succeed
and which ones fail. For this feature (continuation) to be really
useful though, it needs to be able to output context information on
failure (e.g. during iteration 13 of input group B).
This leads us to the distinction of exceptions and errors. It is safe
to catch exceptions but less so for errors. At least it is far more
dangerous and less advised to continue execution but should not be
prohibited I think.
Jens
I don't know, I'd expect Exceptions, Errors and assert to always exit
the current scope, so I'd expect this to always work:
unittest
{
throw new Exception();
assert(1 == 2);
auto a = *cast(int*)null; //should never be executed
}
I think a proper unit test framework should supply an additional check
method:
unittest
{
check(a == 1); //always continue execution
check(b == 2); //always continue execution
check(c == 3); //always continue execution
}
This can be implemented in library code: Have a module level array of
failed checks, then let check append to that array. Analyze the result
after every unit test run and empty the array. Then call the next test
and so on.
It's always something
I just spent about 3 hours tracking down the strangest problem. Win64 exception handling would work fine, but when I'd turn on -g, it would crash. At first I thought I'm generating a bad object file with -g. But since dmd isn't emitting any Win64 symbolic debug info, a check shows the object files are the same with and without -g. So it must be something with linking? I spent a lot of time going over and over the relocation fixups (could there be a missing offset?), but could find nothing wrong. Instrumenting the Phobos eh handler code, it seems my handler table was pointing off into la-la land when linking with /DEBUG. What the hell? I thought I'd dump the first byte of where it was pointing to, and look in the assembler output and see if that byte was at a predictable offset from where it was supposed to be. The actual function started with C3, but the handler table pointed to E9. There was no E9 in the object file. What the hell? Finally, it dawned on me. E9 is a JMP instruction! For some reason, the Microsoft linker inserts a bunch of trampolines when linking for debug. The fix, then, was for the eh handler to look and see if the handler table is pointing to an E9, and if so, then adjust the function address to be where ever the JMP goes. And so it goes...
Re: LDC blacklisted in Ubuntu
On Fri, 2012-09-21 at 21:00 +0100, Joseph Rushton Wakeling wrote: […] Isn't it worth someone from the LDC team discussing with the Ubuntu people concerned (e.g. the person who decided to blacklist the package) and try and get their feedback and advice on packaging? My experience is that the Ubuntu team are fairly friendly and helpful. Perhaps even better talk with the Debian people to find a route into the Debian repository, which then automatically gets to be part of Ubuntu and Mint. AFAICS the reason this situation has arisen is because you've got a bug on Launchpad that never got communicated as far as the LDC devs. Opening that channel of communication could help prevent something like this happening again. Indeed. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Review of Andrei's std.benchmark
On 2012-09-21 21:59, Andrei Alexandrescu wrote: I think you have discovered a major issue. Ideas on how to attack this? The standard way to solve this would be to move the initialization code from a static constructor to a function what will be called and do the initialization lazy. But since this several layers of string mixins what will make it more complicated. Can you give a short example of how the mixed in code will look like? -- /Jacob Carlborg
Re: Extending unittests [proposal] [Proof Of Concept]
On 2012-09-21 22:57, Jens Mueller wrote: Test::Unit, the default testing framework for Ruby on Rails prints a dot for each successful test. That is fine. But you don't need the name of the unittest then. I'm just saying that different testing library to things differently. There are probably testing libraries out there that do print the name of the test. -- /Jacob Carlborg
Re: Extending unittests [proposal] [Proof Of Concept]
On 2012-09-21 23:11, Jens Mueller wrote: But if you have an assert in some algorithm to ensure some invariant or in a contract it will be handled by myUnitTestSpecificAssertHandler. But I think that is not a drawback. Don't you want to no whenever an assert is violated? Oh, you mean like that. Sure, but that will only show up as a failed test. For example, in the Ruby world there are two different testing frameworks: Rspec and test-unit. Rspec makes not difference between a thrown exception or a failed test (assert). Test-unit on the other hand do make a difference of these scenarios. I'm leaning more towards the Rspec way of handling this. -- /Jacob Carlborg
Re: Review of Andrei's std.benchmark
On Friday, 21 September 2012 at 20:43:13 UTC, Jonathan M Davis wrote: On Friday, September 21, 2012 15:59:31 Andrei Alexandrescu wrote: On 9/19/12 4:11 PM, Øivind wrote: New question for you :) To register benchmarks, the 'scheduleForBenchmarking' mixin inserts a shared static initializer into the module. If I have a module A and a module B, that both depend on eachother, than this will probably not work..? The runtime will detect the init cycle and fail with the following error: Cycle detected between modules with ctors/dtors Or am I wrong now? I think you have discovered a major issue. Ideas on how to attack this? Some of us have been asking for ages for the ability to mark a static constructor as not depending on anything so that the runtime _doesn't_ think that there's a circular dependency, but Walter has been against the idea when it's been brought up. That would _really_ help here. Without redesigning std.benchmark so that it doesn't use static constructors, I don't know how you can fix that. Normally, if you really need a static constructor, you go through the pain of creating a separate module which does the initialization for you (like std.stdio does). But that won't work in this case, because you're mixing it in. So, unless you can redesign it so that std.benchmark doesn't require static constructors, it may have to be a limitation of std.benchmark that it can't be used where it would create a circular dependency. Unfortunately, the circular dependency issue makes static constructors almost useless outside of isolated cases, even though they rarely actually have circular dependencies. It's one of the few places in D that I'd say that there's a major design flaw. - Jonathan M Davis Is there a way to solve the dependency issue without forbidding static constructors in modules with cyclic dependencies? I.e. for two modules with static init referencing eachother, an analysis of the static init code could be used to detect circular dependencies instead of the import statements?
Re: Review of Andrei's std.benchmark
On 9/22/12 8:28 AM, Øivind wrote: Is there a way to solve the dependency issue without forbidding static constructors in modules with cyclic dependencies? I think an idea just occurred to me. The rules for static ctors and dtors were invented before import was allowed inside a scope. We could have taken advantage of that. Say we restrict symbol visibility inside static cdtors to ONLY symbols within the current module. If some static cdtor needs a symbol from a different module, it must import it explicitly (even if the current module already imports it). In this setup it should be possible to compute, in a fine-grained manner, the dependencies of static cdtors. Unfortunately that would be a breaking change. Andrei
Re: Review of Andrei's std.benchmark
On Saturday, 22 September 2012 at 13:03:06 UTC, Andrei Alexandrescu wrote: On 9/22/12 8:28 AM, Øivind wrote: Is there a way to solve the dependency issue without forbidding static constructors in modules with cyclic dependencies? I think an idea just occurred to me. The rules for static ctors and dtors were invented before import was allowed inside a scope. We could have taken advantage of that. Say we restrict symbol visibility inside static cdtors to ONLY symbols within the current module. If some static cdtor needs a symbol from a different module, it must import it explicitly (even if the current module already imports it). In this setup it should be possible to compute, in a fine-grained manner, the dependencies of static cdtors. Unfortunately that would be a breaking change. Andrei It gets a bit ugly maybe, but we could do a mix of the proposals that have come before and this one, e.g. add a @nocycliccheck (or similar) to the static constructor, and in that case only allow access to current module and those imorted inside the ctor scope..
Re: Review of Andrei's std.benchmark
On Saturday, 22 September 2012 at 13:25:47 UTC, Øivind wrote: On Saturday, 22 September 2012 at 13:03:06 UTC, Andrei Alexandrescu wrote: On 9/22/12 8:28 AM, Øivind wrote: Is there a way to solve the dependency issue without forbidding static constructors in modules with cyclic dependencies? I think an idea just occurred to me. The rules for static ctors and dtors were invented before import was allowed inside a scope. We could have taken advantage of that. Say we restrict symbol visibility inside static cdtors to ONLY symbols within the current module. If some static cdtor needs a symbol from a different module, it must import it explicitly (even if the current module already imports it). In this setup it should be possible to compute, in a fine-grained manner, the dependencies of static cdtors. Unfortunately that would be a breaking change. Andrei It gets a bit ugly maybe, but we could do a mix of the proposals that have come before and this one, e.g. add a @nocycliccheck (or similar) to the static constructor, and in that case only allow access to current module and those imorted inside the ctor scope.. We would probably not call it '@nycycliccheck' since you propose to still do these checks, but only local imports :) Would need another name for it.
Re: Counter-Proposal: restrict tagged functions
On 2012-09-01, 18:20, Dmitry Olshansky wrote: The idea in a nutshell: - specify a way attach tags to function declarations (to paint functions) - allow specifying is-a relation between tags (supertags and subtags). - add restrict specification that allows user to enforce on a block of code the following: a) disallow use of certain language features b) allow(or disallow) calling function with specific tags - fit with existing world and provide clean migration path, specify defaults I claim that it's enough to implement pure/safe/trusted/nothrow/nogc and proposed nogc. I'm sorry I have not gotten around to commenting on this before, but I *really* like this proposal. As foobar has said, a general annotation system would be real nice, but as far as I can see, it can be built on top of this, at a later point. Also, I cannot see that this has been turned into a proper DIP. :p http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs -- Simen
Re: Review of Andrei's std.benchmark
On 2012-09-22, 15:28, Øivind wrote: It gets a bit ugly maybe, but we could do a mix of the proposals that have come before and this one, e.g. add a @nocycliccheck (or similar) to the static constructor, and in that case only allow access to current module and those imorted inside the ctor scope.. We would probably not call it '@nycycliccheck' since you propose to still do these checks, but only local imports :) Would need another name for it. @noglobalimports. :p -- Simen
Re: It's always something
On 2012-09-22 09:19:33 +, Walter Bright newshou...@digitalmars.com said: I just spent about 3 hours tracking down the strangest problem. Win64 exception handling would work fine, but when I'd turn on -g, it would crash. At first I thought I'm generating a bad object file with -g. But since dmd isn't emitting any Win64 symbolic debug info, a check shows the object files are the same with and without -g. So it must be something with linking? I spent a lot of time going over and over the relocation fixups (could there be a missing offset?), but could find nothing wrong. Instrumenting the Phobos eh handler code, it seems my handler table was pointing off into la-la land when linking with /DEBUG. What the hell? I thought I'd dump the first byte of where it was pointing to, and look in the assembler output and see if that byte was at a predictable offset from where it was supposed to be. The actual function started with C3, but the handler table pointed to E9. There was no E9 in the object file. What the hell? Finally, it dawned on me. E9 is a JMP instruction! For some reason, the Microsoft linker inserts a bunch of trampolines when linking for debug. The fix, then, was for the eh handler to look and see if the handler table is pointing to an E9, and if so, then adjust the function address to be where ever the JMP goes. And so it goes... But there should be a reason why there's a jump there. Have you found it? If you're just bypassing the jump you might be breaking something else. For instance, this jump table might have been a mean to allow the debugger to more easily break on exceptions. Or it might be something else, I don't know, but it's likely there's a reason. You should keep a record of those anomalies somewhere, it might prove useful as a starting point to investigating problems future problems that might arise. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: Review of Andrei's std.benchmark
On 2012-09-22, 15:04, Andrei Alexandrescu wrote: On 9/22/12 8:28 AM, Øivind wrote: Is there a way to solve the dependency issue without forbidding static constructors in modules with cyclic dependencies? I think an idea just occurred to me. The rules for static ctors and dtors were invented before import was allowed inside a scope. We could have taken advantage of that. Say we restrict symbol visibility inside static cdtors to ONLY symbols within the current module. If some static cdtor needs a symbol from a different module, it must import it explicitly (even if the current module already imports it). In this setup it should be possible to compute, in a fine-grained manner, the dependencies of static cdtors. Unfortunately that would be a breaking change. That *is* neat. I guess putting it on the deprecation path could work. This is a change we'd really, *really* like to see. -- Simen
Re: reference to 'self' inside a function
On 19/09/2012 08:24, Jacob Carlborg wrote:
On 2012-09-19 01:21, Rob T wrote:
Actually I find the __traits system a bit convoluted and inconsistent
with other similar features. There seems to be a real need to unify the
different methods of reflection in D.
For example, I can do this without using __traits
int i;
writeln( i.stringof );
and I can do this
void function x() {};
writeln( x.stringof );
but it won't work for the main function
int main(char[][] args)
{
writeln( main.stringof ); // compile error (bug?)
}
I think the reason for this is that the compiler will resolve main as
a function call, but it will fail because no arguments are given. This
is a typical feature where it seems no one really know how it should
behave. .stringof is very poorly documented. It says nothing about what
the returned string might look like.
I don't think that's true, is it? It would be true if main was marked
@property, but it isn't, so it's only a call if you have () after it.
I'd expect main to resolve to either a function or (if overloaded) a
function set, and then - if it's not a set - you could pass it around
like a C function pointer. (If it is a set, I have no idea.)
but this works
writeln(__traits( identifier, main ));
It seems that __traits(itentifier, ) and .stringof are two ways of
getting access to the same information.
Hmm, it does seem that way, doesn't it?
So why do we have __traits and the built in properties that overlap in
functionality? Why is it inconsistently applied as seen with function
main (although that could simply be a bug)? The situation is rather
confusing.
.stringof was available long before D2 was created, __traits is only
available in D2. I think __traits was create to try to improve the
compile time reflection abilities in D.
If it helps, I recently discovered the std.traits library, which wraps a
lot of those ugly low-level-looking things in cleaner-looking things. I
couldn't see the 'self' use case in there though.
Re: Review of Andrei's std.benchmark
On 9/19/12 3:13 AM, Jacob Carlborg wrote:
On 2012-09-17 23:13, Jens Mueller wrote:
Post all feedback to this thread. Constructive feedback is very much
appreciated.
To conclude in more Andrei like words: Happy destruction!
* Why is scheduleForBenchmarking a string? Can't it be a template mixin?
Good point, I'll look into it.
* What's the most appropriate way of just timing a block of code?
Something like this:
auto time = benchmark!({ /* some code */ })(1);
If that's the case then I suggest setting a default value of 1 for the
n parameter.
A default value of n would depend on the speed of the function and the
granularity of the system's timer. That overload of benchmark is
imperfect (rather rigid) but we must keep it for backwards compatibility.
* If I want to format the printed result differently, say in HTML, how
would I do that? Should I use the benchmark function and iterate the
BenchmarkResult array?
That is correct. printBenchmarks() does not use any magic - it just
looks at that same array.
* BTW why doesn't benchmark return the BenchmarkResult array?
Will look into it.
* Is this module so important to keep it as a top level module? I'm
thinking something like a utility package or a time/date package. How
about std.util.benchmark?
Not sure.
Andrei
Re: It's always something
You should keep a record of those anomalies somewhere, it might prove useful as a starting point to investigating problems future problems that might arise. You are right. I think it is a good thing Walter took the time out to write about this. In the absence of better documentation this post might come in handy (we can always use Google).
Re: Review of Andrei's std.benchmark
- It is very strange that the documentation of printBenchmarks uses neither of the words average or minimum, and doesn't say how many trials are done I suppose the obvious interpretation is that it only does one trial, but then we wouldn't be having this discussion about averages and minimums right? Øivind says tests are run 1000 times... but it needs to be configurable per-test (my idea: support a _x1000 suffix in function names, or _for1000ms to run the test for at least 1000 milliseconds; and allow a multiplier when when running a group of benchmarks, e.g. a multiplier argument of 0.5 means to only run half as many trials as usual.) Also, it is not clear from the documentation what the single parameter to each benchmark is (define iterations count.) I don't think it's a good idea because the for 1000 ms doesn't say anything except how good the clock resolution was on the system. I'm as strongly convinced we shouldn't print useless information as I am we should print useful information. I am puzzled about what you think my suggestion meant. I am suggesting allowing the user to configure how long benchmarking takes. Some users might want to run their benchmark for an hour to get stable and reliable numbers; others don't want to wait and want to see results ASAP. Perhaps the *same* user will want to run benchmarks quickly while developing them and then do a final run with more trials once their benchmark suite is complete. Also, some individual benchmark functions will take microseconds to complete; others may take seconds to complete. All I'm suggesting are simple ways to avoid wasting users' time, without making std.benchmark overly complicated.
Re: reference to 'self' inside a function
On 18/09/2012 22:21, Rob T wrote:
On Tuesday, 18 September 2012 at 19:57:05 UTC, Ben Davis wrote:
Wild stab in the dark, but would something like this work:
void myfunction() {
int dummy;
auto self = __traits(parent, dummy);
}
though it would be better if something like __traits(enclosing) were
supported.
This hack will generate the enclosing function name
void function x()
{
int dummy;
auto funcname = __traits( identifier, __traits( parent, dummy ) );
writefln( funcname );
}
Obviously the above solution is not reasonable, esp for a language that
attempts to provide good reflection abilities.
I've just made a wrapper that helps - you have to use mixin with it:
string scopeName()
{
return q{__traits(identifier, __traits(parent, {}))};
}
void main()
{
writeln(mixin(scopeName()));
}
That should be quite usable, except if the user forgets the mixin() part
- unfortunately that potential bug seems to be statically undetectable.
Re: Review of Andrei's std.benchmark
On Saturday, September 22, 2012 09:04:09 Andrei Alexandrescu wrote: On 9/22/12 8:28 AM, Øivind wrote: Is there a way to solve the dependency issue without forbidding static constructors in modules with cyclic dependencies? I think an idea just occurred to me. The rules for static ctors and dtors were invented before import was allowed inside a scope. We could have taken advantage of that. Say we restrict symbol visibility inside static cdtors to ONLY symbols within the current module. If some static cdtor needs a symbol from a different module, it must import it explicitly (even if the current module already imports it). In this setup it should be possible to compute, in a fine-grained manner, the dependencies of static cdtors. Unfortunately that would be a breaking change. It's a nice thought, but it wouldn't work. If nothing else .di files completely ruin it. 1. I don't think that it's actually required that static constructors be in a .di file. So, the compiler couldn't know for sure whether the modules being imported had static constructors. 2. Even if all static constructors had to be in a .di file, local imports ruin it, because the function bodies (which can definitely be elided from .di files) could contain local imports to modules which have static constructors and cause circular dependencies. - Jonathan M Davis
Re: Extending unittests [proposal] [Proof Of Concept]
Jacob Carlborg wrote: On 2012-09-21 23:11, Jens Mueller wrote: But if you have an assert in some algorithm to ensure some invariant or in a contract it will be handled by myUnitTestSpecificAssertHandler. But I think that is not a drawback. Don't you want to no whenever an assert is violated? Oh, you mean like that. Sure, but that will only show up as a failed test. For example, in the Ruby world there are two different testing frameworks: Rspec and test-unit. Rspec makes not difference between a thrown exception or a failed test (assert). Test-unit on the other hand do make a difference of these scenarios. I'm leaning more towards the Rspec way of handling this. What does it mean to make no distinction in RSpec? Both should be reported. In D you just see either an AssertError or SomeException. Jens
Re: Extending unittests [proposal] [Proof Of Concept]
Johannes Pfau wrote:
Am Fri, 21 Sep 2012 23:15:33 +0200
schrieb Jens Mueller jens.k.muel...@gmx.de:
I like the BOOST unit test library's approach, which has two types
of assert: BOOST_CHECK and BOOST_REQUIRE. After a BOOST_CHECK
fails, the test keeps running, but BOOST_REQUIRE throws an exception
to stop the test. When testing a series of inputs in a loop, it is
useful (for debugging) to see the complete set of which ones succeed
and which ones fail. For this feature (continuation) to be really
useful though, it needs to be able to output context information on
failure (e.g. during iteration 13 of input group B).
This leads us to the distinction of exceptions and errors. It is safe
to catch exceptions but less so for errors. At least it is far more
dangerous and less advised to continue execution but should not be
prohibited I think.
Jens
I don't know, I'd expect Exceptions, Errors and assert to always exit
the current scope, so I'd expect this to always work:
unittest
{
throw new Exception();
assert(1 == 2);
auto a = *cast(int*)null; //should never be executed
}
That should definitely be the default.
I think dmd also warns about such code.
I think a proper unit test framework should supply an additional check
method:
unittest
{
check(a == 1); //always continue execution
check(b == 2); //always continue execution
check(c == 3); //always continue execution
}
This can be implemented in library code: Have a module level array of
failed checks, then let check append to that array. Analyze the result
after every unit test run and empty the array. Then call the next test
and so on.
gtest also has ASSERT_* and EXPECT_*. I used EXPECT_* rarely.
I think it complicates matters for little reason. Because in D you then
have assert, enforce, and check. I would prefer if assert and enforce
are the only ones. Though semantics for enforce and check are a little
different. An exception is like a check. It may fail and can be handled.
Jens
Re: It's always something
On 9/22/2012 6:37 AM, Michel Fortin wrote: But there should be a reason why there's a jump there. Have you found it? If you're just bypassing the jump you might be breaking something else. For instance, this jump table might have been a mean to allow the debugger to more easily break on exceptions. Or it might be something else, I don't know, but it's likely there's a reason. Such trampolines are most often used so that a function can be easily hot swapped with another function. This may be a debugging feature of VS. It took me so long to figure this one out because I had no idea that the MS linker would do this. You should keep a record of those anomalies somewhere, it might prove useful as a starting point to investigating problems future problems that might arise. I'll probably write a blog post about it eventually.
Re: Reference semantic ranges and algorithms (and std.random)
On Friday, 21 September 2012 at 19:47:16 UTC, Jonathan M Davis wrote: On Friday, September 21, 2012 15:20:49 monarch_dodra wrote: #3 The only thing I'm having an issue with is save. IMO, it is exceptionally dangerous to have a PRNG be a ForwardRange: It should only be saved if you have a damn good reason to do so. You can still dup if you want (manually) (if you think that is smart), but I don't think it should answer true to isForwardRange. It is _very_ crippling to a range to not be a forward range. There's lots of stuff that requires it. And I really don't see what the problem is. _Maybe_ it's okay for them to be input ranges and not forward ranges, but in general, I think that we need to be _very_ careful about doing that. It can be really, really annoying when a range is not a forward range. Reference type ranges could have a payload property which would return the underlying value type range which would be a forward range. If you need a forward range, you could just use that.
2.060 deb package on Linux Mint 13
Though Mint 13 is very similar to ubuntu 12, I cannot seem to get the deb package to install. I get dependency errors on gcc, gcc-mulitlib, and xdg-utils. apt-get assures me these are all the latest version. Still, dpkg won't install dmd2. I understand the wisdom seems to be to just use the zip file and set your path locally. But maybe someone has either been across this, or want's to know there's an issue on Mint. I'm not that good w/ linux package mgrs, but I'm willing to slog through if anyone has suggestions to try. Jason
how is this considered hiding methods?
Can someone please tell me why the following code gives these
errors?
Error: class main.BirdZoo use of main.VertebrateZoo.take(Animal
animal_) hidden by BirdZoo is deprecated
Error: class main.ParrotZoo use of main.VertebrateZoo.take(Animal
animal_) hidden by ParrotZoo is deprecated
/// The code:
class Animal { }
class Vertebrate { }
class Bird: Animal { }
class Parrot: Bird { }
class VertebrateZoo
{
void take(Animal animal_)
{
if(auto vertebrate = cast(Vertebrate)animal_)
take(vertebrate);
}
abstract void take(Vertebrate vertebrate_);
}
class BirdZoo: VertebrateZoo
{
override void take(Vertebrate vertebrate_)
{
if(auto bird = cast(Bird)vertebrate_)
take(bird);
}
abstract void take(Bird bird_);
}
class ParrotZoo: BirdZoo
{
override void take(Bird bird_)
{
if(auto parrot = cast(Parrot)bird_)
take(parrot);
}
abstract void take(Parrot parrot_);
}
Re: how is this considered hiding methods?
On Saturday, 22 September 2012 at 07:48:02 UTC, Gor Gyolchanyan
wrote:
Can someone please tell me why the following code gives these
errors?
Error: class main.BirdZoo use of main.VertebrateZoo.take(Animal
animal_) hidden by BirdZoo is deprecated
Error: class main.ParrotZoo use of
main.VertebrateZoo.take(Animal animal_) hidden by ParrotZoo is
deprecated
/// The code:
class Animal { }
class Vertebrate { }
class Bird: Animal { }
class Parrot: Bird { }
class VertebrateZoo
{
void take(Animal animal_)
{
if(auto vertebrate = cast(Vertebrate)animal_)
take(vertebrate);
}
abstract void take(Vertebrate vertebrate_);
}
class BirdZoo: VertebrateZoo
{
override void take(Vertebrate vertebrate_)
{
if(auto bird = cast(Bird)vertebrate_)
take(bird);
}
abstract void take(Bird bird_);
}
class ParrotZoo: BirdZoo
{
override void take(Bird bird_)
{
if(auto parrot = cast(Parrot)bird_)
take(parrot);
}
abstract void take(Parrot parrot_);
}
I figured it out:
class BirdZoo: VertebrateZoo
{
alias VertebrateZoo.take take;
override void take(Vertebrate vertebrate_)
{
if(auto bird = cast(Bird)vertebrate_)
take(bird);
}
abstract void take(Bird bird_);
}
class ParrotZoo: BirdZoo
{
alias BirdZoo.take take;
override void take(Bird bird_)
{
if(auto parrot = cast(Parrot)bird_)
take(parrot);
}
abstract void take(Parrot parrot_);
}
Re: how is this considered hiding methods?
On 9/22/12, Jonathan M Davis jmdavisp...@gmx.com wrote:
But why the compiler would now require that you do that, I
don't know. If that's the way that thnigs currently are, it starts to become
a bit odd that the base class functions aren't automatically available.
http://dlang.org/hijack.html
There's a good reason why, consider:
class Foo
{
void foo(int) { }
}
class Bar : Foo
{
alias super.foo foo;
void foo(double) { }
}
void main()
{
auto bar = new Bar;
bar.foo(1); // calls Foo.foo
}
Now let's say Foo is a library class and you upgrade to a new version
of the library without realizing that the base method was removed:
class Foo
{
}
class Bar : Foo
{
alias super.foo foo; // error
void foo(double) { }
}
This now becomes a compile-time error. Without using the alias which
triggers the error the literal 1 would be implicitly converted to a
double and you'd end up invoking your own 'foo' method (which is no
longer an overload).
Re: how is this considered hiding methods?
On 9/22/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
using the alias
But I do think this can be further improved in the language. Take this
for example:
import std.stdio;
class Foo
{
void meth(double) { writeln(Foo.meth); }
}
class Bar : Foo
{
alias super.meth meth;
void meth(int) { writeln(Bar.meth); }
}
class Doo : Bar
{
alias super.meth meth;
void meth(long) { writeln(Doo.meth); }
}
void main()
{
auto doo = new Doo;
doo.meth(1); // calls Bar.meth
}
Now let's say the Doo clas removes the meth overload and the alias:
class Foo
{
void meth(double) { writeln(Foo.meth); }
}
class Bar : Foo
{
// gone
}
class Doo : Bar
{
alias super.meth meth;
void meth(long) { writeln(Doo.meth); }
}
void main()
{
auto doo = new Doo;
doo.meth(1); // now calls Doo.meth
}
We might have wanted the super alias in Doo to only work against the
Bar base class so the compiler can notify us if Doo.meth is removed.
The language doesn't have a way to warn us of this.
I would prefer if super.alias meant to take overloads of all base
classes into account and that we could use ClassName.alias to only
import the overload set of a specific base class. That way this would
trigger a CT error:
class Foo
{
void meth(double) { writeln(Foo.meth); }
}
class Bar : Foo
{
}
class Doo : Bar
{
alias Bar.meth meth; // error: no overload set in Bar
void meth(long) { writeln(Doo.meth); }
}
Re: how is this considered hiding methods?
On 9/22/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Now let's say the Doo clas removes the meth overload and the alias: Sorry that should be the Bar class.
Re: how is this considered hiding methods?
On 9/22/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: I would prefer if super.alias meant to take overloads of all base classes into account. Although this would be kind of counter-intuitive since 'super' already means the direct base class.
Re: Passing associative array to another thread
On 21.9.2012 19:01, Jacob Carlborg wrote:
Perhaps declaring the associative array as shared. An alternative
would be to serialize the aa, pass it to another thread, and deserialize
it. That would though create a copy.
Hi Jacob,
thanks for the hint. Making it shared sounds a bit fishy to me. My
intention is to pass some read only data, that are in fact thread local
and there is no real need to make them shared.
The (de)serialization is possible but the overhead seems a bit
pointless. I will alter the code to use something else than AAs if there
is no other way.
The data I am trying to pass is in fact just name-value pairs. I have
tried to use Tuples, but I have hit another batch of problems. One was
related to issue #5783, but another made me really scratch my head...
This compiles ok:
struct S { Tuple!int i; }
This does not:
struct S {
Tuple!int i;
SysTime t;
}
Error: function
std.typecons.Tuple!(int).Tuple.opEquals!(const(Tuple!(int))).opEquals
(const(Tuple!(int)) rhs) is not callable using argument types
(const(Tuple!(int))) const
This looks a lot like the #5783, but I don't understand, why it only
shows up with the SysTime in place...
Martin
Re: Passing associative array to another thread
On 2012-09-22 11:24, Martin Drasar wrote: thanks for the hint. Making it shared sounds a bit fishy to me. My intention is to pass some read only data, that are in fact thread local and there is no real need to make them shared. The whole point of thread local data is that it's only accessible from a single thread. If you want to share it with another thread you have, as far as I know, there options: 1. Declare it as shared 2. Declare it as immutable 3. Make a copy, i.e. serialize the data The (de)serialization is possible but the overhead seems a bit pointless. I will alter the code to use something else than AAs if there is no other way. The data I am trying to pass is in fact just name-value pairs. I have tried to use Tuples, but I have hit another batch of problems. One was related to issue #5783, but another made me really scratch my head... Looking at your original example I don't understand why the immutable aa won't work. That's the whole point of immutable, it's safe to share among threads. It's probably a bug somewhere. I think someone else can answer these questions better than me. -- /Jacob Carlborg
Re: Passing associative array to another thread
On Saturday, September 22, 2012 12:30:30 Jacob Carlborg wrote: Looking at your original example I don't understand why the immutable aa won't work. That's the whole point of immutable, it's safe to share among threads. It's probably a bug somewhere. I think someone else can answer these questions better than me. The problem with immutable is probably due to this bug: http://d.puremagic.com/issues/show_bug.cgi?id=5538 And casting to shared probably won't work due to this bug: http://d.puremagic.com/issues/show_bug.cgi?id=6585 std.variant needs quite a bit of work done to it, and it's causing problems with std.concurrency is this case. In the interim, I suspect that just about the only way to get an AA across threads is to just make it shared and not use std.concurrency at all, as undesirable as that may be. Your serialization suggestion would probably be the only other choice, though that would require something like Orange, as Phobos doesn't have such facilities. - Jonathan M Davis
Re: Passing associative array to another thread
On 22.9.2012 13:19, Jonathan M Davis wrote: The problem with immutable is probably due to this bug: http://d.puremagic.com/issues/show_bug.cgi?id=5538 And casting to shared probably won't work due to this bug: http://d.puremagic.com/issues/show_bug.cgi?id=6585 std.variant needs quite a bit of work done to it, and it's causing problems with std.concurrency is this case. In the interim, I suspect that just about the only way to get an AA across threads is to just make it shared and not use std.concurrency at all, as undesirable as that may be. Your serialization suggestion would probably be the only other choice, though that would require something like Orange, as Phobos doesn't have such facilities. - Jonathan M Davis Hi Jonathan, I will work around the AA. As I have said, it is used only to pass name-value pairs. So no need to ditch the entire std.concurrency because of that. Martin
Re: Passing associative array to another thread
Am Sat, 22 Sep 2012 12:30:30 +0200 schrieb Jacob Carlborg d...@me.com: On 2012-09-22 11:24, Martin Drasar wrote: thanks for the hint. Making it shared sounds a bit fishy to me. My intention is to pass some read only data, that are in fact thread local and there is no real need to make them shared. The whole point of thread local data is that it's only accessible from a single thread. If you want to share it with another thread you have, as far as I know, there options: 1. Declare it as shared There's also __gshared. 2. Declare it as immutable 3. Make a copy, i.e. serialize the data
Re: Passing associative array to another thread
On 22.9.2012 13:50, Johannes Pfau wrote: 1. Declare it as shared There's also __gshared. Yup, that works. Thanks
object.error: Privileged Instruction
What does the message in the subject mean?
Here's a testcase (tested on dmd 2.060 on win7 32-bit):
import core.exception;
import core.runtime; // comment out this, and no stacktrace is
printed
void myAssertHandler(string file, size_t line, string msg = null)
{ }
static this() {
setAssertHandler(myAssertHandler);
f();
}
version(unittest) {
void f() {
//assert(false); // without message, object.error:
Breakpoint
assert(false, aoeu); // with message, object.error:
Privileged Instruction
}
}
Re: object.error: Privileged Instruction
Privilege instruction is an assembly instruction which can be executed only at a certain executive process context, typically os kernel. AFAIK assert(false) was claimed to be implemented by dmd as a halt instruction, which is privileged one. However, compiled code shows that dmd generates int 3 instruction for assert(false) statement and 61_6F_65_75 which is binary representation of aoeu for assert(false, aoeu) statement and the latter is interpreted as privileged i/o instruction.
Re: object.error: Privileged Instruction
On Saturday, September 22, 2012 21:19:27 Maxim Fomin wrote: Privilege instruction is an assembly instruction which can be executed only at a certain executive process context, typically os kernel. AFAIK assert(false) was claimed to be implemented by dmd as a halt instruction, which is privileged one. However, compiled code shows that dmd generates int 3 instruction for assert(false) statement and 61_6F_65_75 which is binary representation of aoeu for assert(false, aoeu) statement and the latter is interpreted as privileged i/o instruction. It's a normal assertion without -release. With -release, it's a halt instruction on Linux but IIRC it's something slightly different (albeit similar) on Windows, though it might be halt there too. - Jonathan M Davis
system vs. execvp ?
Hi! This works as expected: string cmd = dmd src/xyz.d; int i = system(cmd); But this not: string[] cmd; cmd ~= src/xyz.d; int i = execvp(dmd,cmd); Of course, dmd is in PATH (Win7). What is wrong here? tia Peter
Re: system vs. execvp ?
On Sunday, September 23, 2012 00:53:48 Peter Sommerfeld wrote: Hi! This works as expected: string cmd = dmd src/xyz.d; int i = system(cmd); But this not: string[] cmd; cmd ~= src/xyz.d; int i = execvp(dmd,cmd); Of course, dmd is in PATH (Win7). What is wrong here? Please elaborate on what doesn't work as expected. We can't help you if you don't tell us what's wrong. system should run your command in a new process and return, whereas execvp will run it and never return, because the new process replaces your current one. Now, looking at the docs for std.process.execvp, they seem to think that the exec functions are going to return, but that's not what the man pages for the C functions (which they're calling) say, nor is it how they behave. Maybe that's your problem? http://linux.die.net/man/3/exec http://msdn.microsoft.com/en-us/library/3xw6zy53.aspx - Jonathan M Davis
Re: system vs. execvp ?
On 9/23/12, Peter Sommerfeld nore...@rubrica.at wrote: What is wrong here? string[] cmd; cmd ~= dmd; cmd ~= src/xyz.d; int i = execvp(dmd,cmd); 1st arg should always be the app name, even though apps typically ignore/skip the first arg.
Re: system vs. execvp ?
On Sunday, September 23, 2012 01:12:34 Andrej Mitrovic wrote: On 9/23/12, Peter Sommerfeld nore...@rubrica.at wrote: What is wrong here? string[] cmd; cmd ~= dmd; cmd ~= src/xyz.d; int i = execvp(dmd,cmd); 1st arg should always be the app name, even though apps typically ignore/skip the first arg. Are you sure about that? That seems pretty messed up if that's the case. Yes, the first element in the argument list that main gets is the name of the program, but it's pretty messed up if any of the exec* functions require that you give the program name as the first argument rather than it being appropriately added by that program before its main is called. I'd be very surprised if you were correct about this. - Jonathan M Davis
Re: system vs. execvp ?
On Saturday, September 22, 2012 16:10:11 Jonathan M Davis wrote: Now, looking at the docs for std.process.execvp, they seem to think that the exec functions are going to return, but that's not what the man pages for the C functions (which they're calling) say, nor is it how they behave. The problem with the documentation has been reported: http://d.puremagic.com/issues/show_bug.cgi?id=8708 - Jonathan M Davis
Re: system vs. execvp ?
On 9/23/12, Jonathan M Davis jmdavisp...@gmx.com wrote: I'd be very surprised if you were correct about this. I was wrong, it's for a different reason: http://stackoverflow.com/questions/3027320/why-first-arg-to-execve-must-be-path-to-executable
Re: system vs. execvp ?
Jonathan M Davis wrote: Peter Sommerfeld wrote: This works as expected: string cmd = dmd src/xyz.d; int i = system(cmd); But this not: string[] cmd; cmd ~= src/xyz.d; int i = execvp(dmd,cmd); Of course, dmd is in PATH (Win7). What is wrong here? Please elaborate on what doesn't work as expected. We can'thelp you if you don't tell us what's wrong. Well, system(cmd) compiles xyz.d and creates an executable. execvp(cmd) does call dmd but that behaves as if no arguments where given (Usage msg etc). No executables are created. system should run your command in a new process and return,whereas execvp will run it and never return, because the new process replaces your current one. I did not know that it does not return. Anyway, it should compile the args IMHO but it does not. Peter
Testing for template argument being result of takeExactly
I'm trying to test whether a template argument is the type returned by
takeExactly, and I haven't been able to sort out the template voodoo required
yet. It would be a lot easier if I had a variable to work with, but I just
have the type, and the fancy is expression required to pull it off is fancy
enough that I haven't been able to sort it out yet. At present, I have this:
import std.range;
import std.stdio;
template Hello(R)
if(is(R r == U, V, V w, U = typeof(takeExactly(w, 1
{
alias R Hello;
}
void main()
{
auto str = hello;
auto t = takeExactly(str, 3);
writeln(t);
Hello!(typeof(t)) h = t;
writeln(h);
}
I need Hello to instatiate if R is the type returned by takeExactly and fail
to instantiate otherwise. At present, the code gives these compilation errors:
q.d(15): Error: template instance Hello!(Result) Hello!(Result) does not match
template declaration Hello(R) if (is(R r == U,V,V w,U =
typeof(takeExactly(w,1
q.d(15): Error: Hello!(Result) is used as a type
q.d(16): Error: template std.stdio.writeln does not match any function
template declaration
q.d(16): Error: template std.stdio.writeln(T...) cannot deduce template
function from argument types !()(_error_)
So, clearly I don't have the is expression right, and this is seriously
pushing the edge of my knowledge of is expressions. So, any help would be
appreciated. Thanks.
- Jonathan M Davis
Re: Testing for template argument being result of takeExactly
Jonathan M Davis: So, clearly I don't have the is expression right, and this is seriously pushing the edge of my knowledge of is expressions. So, any help would be appreciated. Thanks. I have done some tries, but I have failed, I am sorry :-) The is() syntax is a part of D good to burn on a campfire. But takeExactly returns a Result struct defined inside it, so it even possible for the is() syntax to work on this inner (hidden?) type? Generally the idea of defining structs inside looks nice, but seems a source for troubles. Bye, bearophile
Re: Testing for template argument being result of takeExactly
On Sunday, September 23, 2012 02:57:36 bearophile wrote: Jonathan M Davis: So, clearly I don't have the is expression right, and this is seriously pushing the edge of my knowledge of is expressions. So, any help would be appreciated. Thanks. I have done some tries, but I have failed, I am sorry :-) The is() syntax is a part of D good to burn on a campfire. The power that it provides is useful if not outright necessary, but it could definitely use some improvements in the usability camp once you go beyond the basics. But I don't even know how you'd go about designing it so that it was more user friendly. But takeExactly returns a Result struct defined inside it, so it even possible for the is() syntax to work on this inner (hidden?) type? Generally the idea of defining structs inside looks nice, but seems a source for troubles. Yeah. Increasingly, it looks like Voldemort types are a bad idea as nice as they are in principle. But we have yet to reach the point where it's clear that we need to ditch them. We may yet get there though. - Jonathan M Davis
How to Instantiate struct defined in template
Hello,
I am trying to figure out how templates work and tried to define
the
following template to define vertices of any dimension and
operations
on them.
import std.stdio;
import std.random;
import std.range;
import std.conv;
import std.math;
/*
* T must be one of the floating point types
* float, double, real _ I should be enforcing this.
*/
template vt(T)
{
struct vertex {
this(T[] crds...) {
if( crds.length 2 ) {
throw new.Exception(To small!);
} else {
coords.length = crds.length;
foreach(ref v_coord, in_coord; lockstep(coords, crds))
{
v_coord = in_coord;
}
}
}
@property T x() { return coords[0];}
@property T y() { return coords[1];}
@property T z() { return ( coords.length 3 ? T.nan :
coords[2] ); }
}
T euclid_dist(T a, T b) {
T sum = 0;
foreach( ref a_crd, ref b_crd; lockstep( a.coords, b.coords )
) {
sum += (a_crd - b_crd)*(a_crd - b_crd );
}
return sqrt(sum);
}
} //End of template
int main(string argv[] ) {
vt!(float).vertex v1(0.0,0.0);
vt!(float).vertex v2(3.0,4.0);
writefln(The distance between vertex 1 and vertex 2 is ,
vt!(float).euclid_dist(v1, v2) );
}
When I try to compile this I get the message:
vertex.d(57): Error: found 'v1' when expecting ';' following
statement
vertex.d(58): Error: found 'v2' when expecting ';' following
statement
Lines 57 and 58 are the first two lines in my main() function. I
can't figure out why, from the examples I've looked at I am using
the syntax properly, but am clearly missing something.
Also, since I don't really know what I am doing any criticisms on
how I am defining the vertex template are welcome.
Cheers,
Craig
Re: How to Instantiate struct defined in template
On Sunday, 23 September 2012 at 04:03:28 UTC, Jonathan M Davis
wrote:
On Sunday, September 23, 2012 05:49:06 Craig Dillabaugh wrote:
Hello,
clip
Before anything, I'd question why you declared vt at all. If
all you're
putting in it is a single struct, then just templatize the
struct directly:
struct Vertex(T)
{
...
}
Now, it looks like you have a free function in there as well -
euclid_dist -
but there's no reason to put that in the same template. Just
templatize it
directly. Then you get
T euclid_dist(T)(T a, T b) {...}
And main ends up looking something like
void main()
{
auto v1 = Vertex!float(0.0, 0.0);
auto v2 = Vertex!float(2.0, 4.0);
writefln(The distance between vertex 1 and vertex 2 is %s,
euclid_dist(v1, v2));
}
Thanks. I've switched my code to follow your suggestion. One thing
there was a typo in my euclid_dist function, the code for it, and
main now look like:
T euclid_dist(T)(vertex!T a, vertex!T b) {
T sum = 0;
foreach( ref a_crd, ref b_crd; lockstep( a.coords, b.coords ) ) {
sum += (a_crd - b_crd)*(a_crd - b_crd );
}
return sqrt(sum);
}
int main(string argv[] ) {
auto v1 = vertex!float(0.0,0.0);
auto v2 = vertex!float(3.0,4.0);
writeln(The distance between vertex 1 and vertex 2 is ,
euclid_dist!float(v1, v2) );
return 0;
}
One question. Is there any way to get the function template to
deduce the type of T from the vertices I pass, so that I can
call:
euclid_dist(v1, v2) )
instead of:
euclid_dist!float(v1, v2) );
It's actually fairly to explicitly declare a template in D
outside of
eponymous templates. If you're dealing with a user-defined type
or function, it
almost always makes more sense to templatize them directly.
Now, as for the exact error message, it's because the syntax
that you're using
to define v1 and v2 is illegal. You'd need to do either
vt!float.vertex v1 = vt!float(0.0, 0.0);
or preferrably.
auto v1 = vt!float(0.0, 0.0);
You can't construct the type on the left-hand side of the
assignment operator
like that.
- Jonathan M Davis
,
Re: How to Instantiate struct defined in template
On Sunday, 23 September 2012 at 04:51:31 UTC, Jonathan M Davis wrote: On Sunday, September 23, 2012 06:37:30 Craig Dillabaugh wrote: One question. Is there any way to get the function template to deduce the type of T from the vertices I pass, so that I can call: euclid_dist(v1, v2) ) instead of: euclid_dist!float(v1, v2) ); It should infer the types just fine as-is. Templated functions can pretty much always infer the template arguments from their function arguments. It's with types that that doesn't work (so a constructor requires template arguments, but a function does not). - Jonathan M Davis Yes, you are right. I thought I had tried it without the !float and it hadn't worked, but I guess not. Thanks again for all your help. Craig
[Issue 8706] New: Tool reference page
http://d.puremagic.com/issues/show_bug.cgi?id=8706 Summary: Tool reference page Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: ma...@maxim-fomin.ru --- Comment #0 from Maxim Fomin ma...@maxim-fomin.ru 2012-09-21 23:56:55 PDT --- It seems to be broken http://dlang.org/pdf-tools-cover.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8496] Assignment of function literal to function pointer variable with non-D linkage broken
http://d.puremagic.com/issues/show_bug.cgi?id=8496
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Summary|(Regression 2.060) |Assignment of function
|Assignment of function |literal to function pointer
|literal to function pointer |variable with non-D linkage
|variable with non-D linkage |broken
|broken |
Severity|regression |enhancement
--- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-09-22 03:23:45 PDT ---
This is not a regression.
In 2.059, this was accidentally allowed by the cause same with bug 8397. It's
already fixed in 2.060.
(Therefore, the call of function pointer f might had been broken in 2.059)
And, lambda type inference does not infer function linkage in current
implementation. Then, (){} is always extern(D), and the error is expected.
But, it is reasonable feature. So I change the importance to 'enhancement'.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8387] Semantic errors in opDispatch body are not reported
http://d.puremagic.com/issues/show_bug.cgi?id=8387 --- Comment #1 from Daniel Cousens daniel...@bigpond.com 2012-09-22 03:24:53 PDT --- *** Issue 8547 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8547] Pure Functions Compilation - Not consistent errors
http://d.puremagic.com/issues/show_bug.cgi?id=8547 Daniel Cousens daniel...@bigpond.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Daniel Cousens daniel...@bigpond.com 2012-09-22 03:24:53 PDT --- *** This issue has been marked as a duplicate of issue 8387 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8496] Assignment of function literal to function pointer variable with non-D linkage broken
http://d.puremagic.com/issues/show_bug.cgi?id=8496
--- Comment #2 from Kenji Hara k.hara...@gmail.com 2012-09-22 03:26:34 PDT ---
I'd like to update sample code.
alias extern (C) void function() FP;
void main()
{
FP fp = (){};
fp = (){};
}
The fp declaration and assignment should infer the lambda's linkage.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8680] SpanMode.breadth is incorrectly named and implementation fails in Linux
http://d.puremagic.com/issues/show_bug.cgi?id=8680
--- Comment #10 from ent...@cantab.net 2012-09-22 07:09:23 PDT ---
(In reply to comment #9)
listdir was deprecated for a very good reason. Would you now kindly consider
the steps to fold this into a Range.
Oh wow, I didn't realise dirEntries supported bidirectional iteration. That's
interesting. A reverse breadth-first iteration would be a special thing to try
and implement, and I can't see it usefully doing anything other than
precalculating the lot. Reversing the order of files in a shallow iteration is
of questionable use if the sorting of entries isn't defined anyway (I suppose
only if you rely on the order being consistent and call it twice). Reversing
preorder and postorder depth-first will give you postorder and preorder
respectively (along with a reversed child ordering which is meaningless as
above). I wonder if anyone has actually used the reversibility of dirEntries?
If we had the sorting option, here's how I'd see it working (for forward
iteration):
- Always lazily iterate the recursion into subdirectories.
- When sorting is not requested, also lazily iterate each directory's direct
contents.
- When sorting IS requested, each directory's direct contents will need
requesting in a block - OR alternatively, the sort is specified as a set of
parameters which are passed directly to the underlying OS (if the underlying OS
has the corresponding options of course), and then it can still be done lazily.
Actually I have no idea if the current implementations are able to be lazy
within a single directory.
The 'Finish reporting each directory's contents before processing its children'
option (weaker than breadth-first) will not impede laziness, but will require
the directory's subdirectories to be buffered up and remembered (if they aren't
already precalculated).
As for the reverse iteration option - I can see that it was easy to implement
for the existing depth-first options, but it would be annoying to implement for
breadth-first. While it's not impossible to implement, I would view it as
acceptable for reverse breadth-first to be defined as a runtime error.
I don't think I can convert this to code without knowing how the underlying API
looks. I have a feeling it would have to be done separately for different OS's.
But it should be trivial - my main goal was to define the behaviour precisely
enough to avoid misunderstanding, which I think we've done with the latest
pseudocode? You didn't say explicitly if you want both the options I suggested,
but I guess you like the first one (where you buffer up a directory's
subdirectories and then process them once you've finished that directory's
direct contents)?
What I can do is propose an API that I think covers all the use cases:
enum SpanMode {
shallow, ///f1, d1, d2, f2
depthFirstPreorder, ///f1, d1, d1/sd, d1/sd/sf, d2, d2/sd, d2/sd/sf, f2
depthFirstPostorder, ///f1, d1/sd/sf, d1/sd, d1, d2/sd/sf, d2/sd, d2, f2
contiguousLevelsPreorder, ///f1, d1, d2, f2, d1/sd, d1/sd/sf, d2/sd, d2/sd/sf
contiguousLevelsPostorder,///d1/sd/sf, d1/sd, d2/sd/sf, d2/sd, f1, d1, d2, f2
breadthFirst, ///f1, d1, d2, f2, d1/sd, d2/sd, d1/sd/sf, d2/sd/sf
//This syntax apparently isn't supported yet...
@deprecated breadth = depthFirstPreorder,
@deprecated depth = depthFirstPostorder,
}
///If supplied, levelSorter is applied to the whole result in case of
'shallow',
///otherwise each 'shallow' result computed internally along the way.
///Note that supplying a levelSorter may impede the algorithm's laziness.
auto dirEntries(string path, SpanMode mode, bool followSymlink = true, void
delegate(T[]) levelSorter = null); //T being string or DirEntry, ideally put
in caller's control if possible
We can implement any traversal with shallow, why bother adding depth and
breadth or anything else?
I'm very glade you have brought up the naming and implementation issue as I am
relying on a behavior which isn't defined, and now I can plan to correct this.
But it would be nice if the standard library included the use case I would be
using.
Agreed, provided it can be done in a way that's simple to understand. I shied
away from it earlier because I couldn't think of decent names and I thought it
would do more harm than good if the names were bad. But I think
contiguousLevels is clear.
For the sorting case, I was merely suggesting that the sort could be put
in the user's control, so they can sort alphabetically or by timestamp or
however they want.
With those examples I see this as a very useful addition. Just not supporting
the traversal I use.
Incorporated above :)
So the above options can be reversed in all possible permutations to give
what
you want here.
And that is even easier if the traversal is already a range.
Well you say that, but... foreach_reverse simultaneously reverses the file
order in addition to the preorder/postorder
[Issue 8496] Assignment of function literal to function pointer variable with non-D linkage broken
http://d.puremagic.com/issues/show_bug.cgi?id=8496 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-09-22 11:23:46 PDT --- https://github.com/D-Programming-Language/dmd/pull/1135 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8686] Tuple cannot define with type that has only mutable opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=8686 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8707] New: Internal error: ../ztc/cod1.c 1689
http://d.puremagic.com/issues/show_bug.cgi?id=8707
Summary: Internal error: ../ztc/cod1.c 1689
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: blo...@hotmail.com
--- Comment #0 from Christopher Crouzet blo...@hotmail.com 2012-09-22
14:02:55 PDT ---
The code below gives an Internal error: ../ztc/cod1.c 1689
Tested with dmd v2.060.
// --
int test( T )( T array )
{
return 0;
}
void main()
{
immutable int[5][2] array2d = [[1, 2, 3, 4, 5], [6, 7, 8, 9, 10]];
static int result = test( array2d );
}
// --
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8708] New: Documentation for std.process.exec family is inaccurate
http://d.puremagic.com/issues/show_bug.cgi?id=8708 Summary: Documentation for std.process.exec family is inaccurate Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmx.com --- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-09-22 16:15:35 PDT --- It implies that the exec* functions return upon success, which they do not. Rather, the new process replaces the current process, and they only return if the exec* call fails. To quote the man page: The exec() functions only return if an error has have occurred. The return value is -1, and errno is set to indicate the error. http://linux.die.net/man/3/exec http://msdn.microsoft.com/en-us/library/3xw6zy53.aspx -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8475] postblits fails attributes qualifying when in a template.
http://d.puremagic.com/issues/show_bug.cgi?id=8475 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-09-22 21:14:22 PDT --- https://github.com/D-Programming-Language/dmd/pull/1137 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8150] Throwing nothrow struct constructor?
http://d.puremagic.com/issues/show_bug.cgi?id=8150 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-09-22 22:22:46 PDT --- https://github.com/D-Programming-Language/dmd/pull/1138 https://github.com/D-Programming-Language/druntime/pull/309 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
