Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 2012-10-01 06:19, Walter Bright wrote: Also, consider that in C++ you can throw any type, such as an int. There is no credible way to make this work reasonably in D, as exceptions are all derived from Exception. Really, I had not idea that was possible. A workaround could be to convert to a string, wrap it in an exception class and pass to D. -- /Jacob Carlborg
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 2012-10-01 06:35, Andrej Mitrovic wrote: Is that a bug or a feature? :) Actually you can do the same thin in Ruby, at least with strings. This is can be kind of nice, no need to create a new exception type. But in Ruby the string is wrapped in an instance of RuntimeError, so that might not be comparable. raise foo Is the same as: raise RuntimeError.new(foo) -- /Jacob Carlborg
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On Monday, October 01, 2012 08:14:03 Jacob Carlborg wrote: On 2012-10-01 06:19, Walter Bright wrote: Also, consider that in C++ you can throw any type, such as an int. There is no credible way to make this work reasonably in D, as exceptions are all derived from Exception. Really, I had not idea that was possible. A workaround could be to convert to a string, wrap it in an exception class and pass to D. Which would make the exception handling that much mor expensive. I would think that making it so that proper exception types are handled appropriately is plenty. There are limits to what can be reasonably done (just like at the limits that we have already when dealing with C++ from D). It's already arguably rather stupid to throw anything other than a proper exception type even if the language will let you. At some point, it _will_ be up to the programmer to do the right thing regardless of what level of compatibility we provide. - Jonathan M Davis
Re: John Chapman (Juno), calling for John Chapman (not spam)
On Sunday, 30 September 2012 at 16:31:38 UTC, Jesse Phillips wrote: I wish to get a hold of John Chapman because he has a license https://github.com/JesseKPhillips/Juno-Windows-Class-Library/blob/master/juno/licence.txt Which changes the second paragraph of the Boost License as quoted below: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. I am looking to get permission to license under Boost such that it would be compatible with Phobos and allow for possible inclusion of some parts. I will also make the public statement that my contributions can be licensed under Boost. Yes, that's me. Sorry you haven't been able to get hold of me. I would never have changed the text of the licence, so the Boost licence itself must have been updated in the intervening years. If you need to alter the text of the licence to make it compatible, you have my permission.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On Mon, 01 Oct 2012 08:16:13 +0200 Jacob Carlborg d...@me.com wrote: On 2012-10-01 06:35, Andrej Mitrovic wrote: Is that a bug or a feature? :) Actually you can do the same thin in Ruby, at least with strings. This is can be kind of nice, no need to create a new exception type. But in Ruby the string is wrapped in an instance of RuntimeError, so that might not be comparable. raise foo Is the same as: raise RuntimeError.new(foo) Haxe can throw anything, too. I've always found it borderline useless, and frequently a pain.
Re: Simple GEdit .lang github color scheme
OK, simple feedback : it doesn't recognize the lazy keyword. Except for that, it is really good.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 2012-10-01 14:30, Nick Sabalausky wrote: Haxe can throw anything, too. I've always found it borderline useless, and frequently a pain. I find it quite annoying to have to create new classes for exceptions all the time. And since D constructors aren't inherited I need to also create a constructor that just forwards to the base class. Just useless boilerplate code. -- /Jacob Carlborg
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On Monday, October 01, 2012 19:14:45 Jacob Carlborg wrote: On 2012-10-01 14:30, Nick Sabalausky wrote: Haxe can throw anything, too. I've always found it borderline useless, and frequently a pain. I find it quite annoying to have to create new classes for exceptions all the time. And since D constructors aren't inherited I need to also create a constructor that just forwards to the base class. Just useless boilerplate code. If you really need to declare new exception types all that often, I'd be inclined to think that you're creating a lot of needless exception types. But even if that's not the case and you really need many, new exception types with no extra member variables, it's trivial to create a mixin for doing that, though you don't get any ddoc if you do that. - Jonathan M Davis
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 2012-10-01 19:23, Jonathan M Davis wrote: If you really need to declare new exception types all that often, I'd be inclined to think that you're creating a lot of needless exception types. But even if that's not the case and you really need many, new exception types with no extra member variables, it's trivial to create a mixin for doing that, though you don't get any ddoc if you do that. It's not that many in a single project but I have projects and I prefer to have at least one exception base class in each. Yeah, mixins and ddoc does not go hand in hand. -- /Jacob Carlborg
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On Mon, 01 Oct 2012 19:14:45 +0200 Jacob Carlborg d...@me.com wrote: On 2012-10-01 14:30, Nick Sabalausky wrote: Haxe can throw anything, too. I've always found it borderline useless, and frequently a pain. I find it quite annoying to have to create new classes for exceptions all the time. And since D constructors aren't inherited I need to also create a constructor that just forwards to the base class. Just useless boilerplate code. If I'm being lazy, I'll just throw a normal Exception: throw new Exception(Whatever happened); So it's almost as convenient as throwing a string (just a little more typing), but unlike throwing strings or other non-Exceptions, you still get the benefits of: 1. Always having the benefits of Exception, such as a stack trace. 2. Never having to deal with, or even consider the possibility of, What if some stupid lib or callback decides to throw something nonsensical like an int or a Widget? And a catch(Exception e) (or rather catch(Error e)) will always catch everything. Some languages have a catch all, from any unspecified type, but then you can't have have any way to access whatever was thrown (unless it's a dynamic language). But, what you said about Ruby is an interesting idea. Ie, that throwing a string is really just sugar for throwing a normal exception. I didn't know that about Ruby. It would be kinda neat if we could do: throw Shit happened; And instead of actually throwing a string, it was just sugar for: throw new Exception(Shit happened); That'd be pretty cool. On a related, but goofier, note: http://semitwist.com/articles/article/view/stupid-coder-tricks-debugging-exception-handlers
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 2012-10-01 22:00, Nick Sabalausky wrote: But, what you said about Ruby is an interesting idea. Ie, that throwing a string is really just sugar for throwing a normal exception. I didn't know that about Ruby. It would be kinda neat if we could do: throw Shit happened; And instead of actually throwing a string, it was just sugar for: throw new Exception(Shit happened); That'd be pretty cool. Yeah, I wouldn't want this to become a regular String at the catch site, that would be pretty bad. On a related, but goofier, note: http://semitwist.com/articles/article/view/stupid-coder-tricks-debugging-exception-handlers That's interesting. But that's also just like creating a function error which throws an exception. Which I end up doing sometimes. -- /Jacob Carlborg
Re: Simple GEdit .lang github color scheme
On Monday, 1 October 2012 at 12:44:45 UTC, deadalnix wrote:
OK, simple feedback : it doesn't recognize the lazy keyword.
Except for that, it is really good.
Whoops, I added that awhile ago but forgot to re-upload. Here's a
updated version with 'ref', 'lazy', and bracket/operator
highlighting.
http://reign-studios.com/d-downloads/reign.lang.tar.gz
I like the bracket/operator highlighting, but if you don't want
it just remove these lines:
lines 209 - 211:
context id=operators style-ref=type
match
extended=true[\(\)\{\}\[\]lt;gt;=\~\.,\/\!\%\^\amp;\*\+\-\:;]/match
/context
line 274:
context ref=operators/
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On Monday, 1 October 2012 at 04:18:52 UTC, Walter Bright wrote: Also, consider that in C++ you can throw any type, such as an int. There is no credible way to make this work reasonably in D, as exceptions are all derived from Exception. You could just detect C++ exceptions in the SEH handler and wrap them in a ForeignLanguageException or CppException class with a Variant-type member. Not saying that this is necessarily an essential feature, though. David
Re: It seems pure ain't so pure after all
On Monday, 1 October 2012 at 05:43:39 UTC, Alex Rønne Petersen wrote: As far as purity goes, pow2 *is* pure. ... According to http://en.wikipedia.org/wiki/Pure_function it's not: The [pure] function always evaluates the same result value given the same argument value(s)
Re: It seems pure ain't so pure after all
On Monday, October 01, 2012 07:43:59 Alex Rønne Petersen wrote:
This is a corner case.
__ctfe is there to allow special-cased CTFE code when absolutely
necessary. By necessity, this separates a function into two worlds:
compile time and run time.
As far as purity goes, pow2 *is* pure. It just does something different
depending on whether you run it at compile time or run time. I don't see
this as a problem in practice.
It would be kind of like complaining that a pure function returns different
values on Linux and Windows due to a version statement or static if. It's just
that in the thing that varies is compile time vs runtime not the target
machine. e.g.
int func(int val) pure
{
version(linux)
return val + 2;
else version(Windows)
return val + 3;
}
- Jonathan M Davis
Re: It seems pure ain't so pure after all
On Monday, October 01, 2012 07:58:39 Tommi wrote: On Monday, 1 October 2012 at 05:43:39 UTC, Alex Rønne Petersen wrote: As far as purity goes, pow2 *is* pure. ... According to http://en.wikipedia.org/wiki/Pure_function it's not: The [pure] function always evaluates the same result value given the same argument value(s) Forget what Wikipedia says about pure. If you focus on that, you're going to be complaining about D's pure left and right, because what it's talking about and what D does are related but very different. D takes a very practical approach to functional purity. You should read this: http://stackoverflow.com/questions/8572399 - Jonathan M Davis
Re: It seems pure ain't so pure after all
On Monday, 1 October 2012 at 06:01:24 UTC, Jonathan M Davis wrote:
It would be kind of like complaining that a pure function
returns different
values on Linux and Windows due to a version statement or
static if. It's just
that in the thing that varies is compile time vs runtime not
the target
machine. e.g.
Actually... let's not even worry about the definition of the word
'pure'. Let's just ask ourselves: do we really want to live in a
world where people can write code like that:
void main()
{
auto x = pow2(3);
enum y = pow2(3);
assert(x == y + 3);
writeln(Take that mr. \math\ professor!);
readln();
}
Re: It seems pure ain't so pure after all
On 9/30/2012 11:09 PM, Tommi wrote:
On Monday, 1 October 2012 at 06:01:24 UTC, Jonathan M Davis wrote:
It would be kind of like complaining that a pure function returns different
values on Linux and Windows due to a version statement or static if. It's
just
that in the thing that varies is compile time vs runtime not the target
machine. e.g.
Actually... let's not even worry about the definition of the word 'pure'.
Let's just ask ourselves: do we really want to
live in a world where people can write code like that:
void main()
{
auto x = pow2(3);
enum y = pow2(3);
assert(x == y + 3);
writeln(Take that mr. \math\ professor!);
readln();
}
So, Tommi, do you have a suggestion or proposal to make or are you just trying
to point and snicker? There's a
multitude of ways that bad programmers can write bad code.
Re: It seems pure ain't so pure after all
On Monday, October 01, 2012 08:09:38 Tommi wrote:
On Monday, 1 October 2012 at 06:01:24 UTC, Jonathan M Davis wrote:
It would be kind of like complaining that a pure function
returns different
values on Linux and Windows due to a version statement or
static if. It's just
that in the thing that varies is compile time vs runtime not
the target
machine. e.g.
Actually... let's not even worry about the definition of the word
'pure'. Let's just ask ourselves: do we really want to live in a
world where people can write code like that:
void main()
{
auto x = pow2(3);
enum y = pow2(3);
assert(x == y + 3);
writeln(Take that mr. \math\ professor!);
readln();
}
Then don't write a function which claims to square a value and does something
else. That's just bad naming. No language is going to prevent programmers from
being idiots.
A function which uses __ctfe should probably do essentially the same thing at
both runtime and compile time, but it _has_ __ctfe, because the runtime
implementation won't work at compile time, and it's up to the programmer to
make sure that the function does what it's supposed to at both compile time
and runtime. The compiler can't possibly enforce that.
- Jonathan M Davis
Re: It seems pure ain't so pure after all
On Monday, 1 October 2012 at 06:13:51 UTC, Brad Roberts wrote: So, Tommi, do you have a suggestion or proposal to make or are you just trying to point and snicker? There's a multitude of ways that bad programmers can write bad code. I can't provide a solution until we've agreed that there is a problem.
Re: dynamic library building and loading
On 2012-10-01 01:42, Rob T wrote: It seems that an attempt to make the runtime shared is well under way. Did anything get into the main dmd branch or has the effort been stalled or ...? Seems pretty stalled. I will look at this too. Thanks for the pointers. No problem. -- /Jacob Carlborg
Re: Getting started with D - Phobos documentation sucks
On 2012-09-30 21:23, Adam D. Ruppe wrote: What hurts me most in doing it is just that it is C++... I know my way around the compiler reasonably well. Not great but good enough to get by... but doing new code is just such a pain. Little things like no auto, forward declarations, weak sauce arrays and strings. Ugh, it just isn't D. I completely agree. Can't we start to use C++11 soon. At least it has auto. And then dmd has its own rules that trip me up. Aren't supposed to use dynamic_cast, can't use tabs, just all kinds of style things that grind me. I know a few of these rules were due to old compilers having problem with some of the C++ features (templates). Is this still a problem or is there other reasons? I know that Clang doesn't use dynamic_cast or RTTI for that matter. -- /Jacob Carlborg
Re: It seems pure ain't so pure after all
On Monday, 1 October 2012 at 06:18:48 UTC, Jonathan M Davis wrote: A function which uses __ctfe should probably do essentially the same thing at both runtime and compile time, but it _has_ __ctfe, because the runtime implementation won't work at compile time, and it's up to the programmer to make sure that the function does what it's supposed to at both compile time and runtime. The compiler can't possibly enforce that. Thus we're in a situation where pure means pure only by convention, not because it's enforced by the compiler. It's like const in c++ then, it's const only by convention, only because people promise that they're not going to mutate it. I don't like rules that are enforced only by everybody relying on good manners.
Re: Getting started with D - Phobos documentation sucks
On 2012-10-01 04:55, Adam D. Ruppe wrote: A problem I've been having ever since I started doing professional programming is that my focus time is a lot less than it used to be. I used to be able to sit down and spend a full month on one single thing, very few distractions as the monday return to work was /not/ inevitable... But recently that time has been limited to only three days, if I'm lucky, before something comes up and takes my attention away. That's the big issue. I'm basically limited to one or two hours per day, if I'm lucky. Last week I only got a couple of minutes per day. This weekend I spent debugging DWT which lead nowhere, which felt like quite waste. -- /Jacob Carlborg
Re: It seems pure ain't so pure after all
On Monday, October 01, 2012 08:25:39 Tommi wrote: On Monday, 1 October 2012 at 06:18:48 UTC, Jonathan M Davis wrote: A function which uses __ctfe should probably do essentially the same thing at both runtime and compile time, but it _has_ __ctfe, because the runtime implementation won't work at compile time, and it's up to the programmer to make sure that the function does what it's supposed to at both compile time and runtime. The compiler can't possibly enforce that. Thus we're in a situation where pure means pure only by convention, not because it's enforced by the compiler. It's like const in c++ then, it's const only by convention, only because people promise that they're not going to mutate it. I don't like rules that are enforced only by everybody relying on good manners. No. We're not in that situation at all. The function will do the same thing with every call at compile time, and it will do the same thing with every call at runtime. It's like you're complaining about the fact that a function on a big endian machine doesn't do exactly the same thing as when it's compiled for a little endian machine. It's being compiled for a different environment, so its behavior can change. __ctfe really isn't all that different from static if or version blocks which effectively result in different functions depending on how or where the code is compiled. What isn't enforced is that the function does the same thing at compile time as at runtime, and you can't enforce that any more than you can enforce that it does the same thing on one machine as another when they have different architectures or OSes or whatot. By using __ctfe, you are providing an alternate implementation for compile time just like you could provide alternate implementations for different OSes or architectures. - Jonathan M Davis
Re: It seems pure ain't so pure after all
On Sunday, September 30, 2012 23:38:43 Jonathan M Davis wrote:
On Monday, October 01, 2012 08:25:39 Tommi wrote:
Thus we're in a situation where pure means pure only by
convention, not because it's enforced by the compiler. It's like
const in c++ then, it's const only by convention, only because
people promise that they're not going to mutate it. I don't like
rules that are enforced only by everybody relying on good manners.
No. We're not in that situation at all. The function will do the same thing
with every call at compile time, and it will do the same thing with every
call at runtime. It's like you're complaining about the fact that a
function on a big endian machine doesn't do exactly the same thing as when
it's compiled for a little endian machine. It's being compiled for a
different environment, so its behavior can change. __ctfe really isn't all
that different from static if or version blocks which effectively result in
different functions depending on how or where the code is compiled.
What isn't enforced is that the function does the same thing at compile time
as at runtime, and you can't enforce that any more than you can enforce
that it does the same thing on one machine as another when they have
different architectures or OSes or whatot. By using __ctfe, you are
providing an alternate implementation for compile time just like you could
provide alternate implementations for different OSes or architectures.
While __ctfe is not used in a static if, that's effectively the behavior that
it has. You're basically complaining about how these two functions don't
return the same value:
static if(__ctfe)
{
int pow2(int val) pure
{
return 6;
}
}
else
{
int pow2(int val) pure
{
return val * val;
}
}
They're effectively completely different functions that share the same name
(and
presumably the same intent), but they're implementations are different, and
it's obviously up to the programmer to make sure that they do what they're
supposed to do. It has _nothing_ to do with pure.
- Jonathan M Davis
Re: It seems pure ain't so pure after all
On 10/1/12 2:19 AM, Tommi wrote: On Monday, 1 October 2012 at 06:13:51 UTC, Brad Roberts wrote: So, Tommi, do you have a suggestion or proposal to make or are you just trying to point and snicker? There's a multitude of ways that bad programmers can write bad code. I can't provide a solution until we've agreed that there is a problem. Don't want to sound dismissive, but the short answer is there is no problem. Andrei
Re: Idea: Introduce zero-terminated string specifier
On Sunday, 30 September 2012 at 20:27:16 UTC, Andrej Mitrovic wrote: On 9/30/12, deadalnix deadal...@gmail.com wrote: If you know that a string is 0 terminated, you can easily create a slice from it as follow : char* myZeroTerminatedString; char[] myZeroTerminatedString[0 .. strlen(myZeroTerminatedString)]; It is clean and avoid to modify the stdlib in an unsafe way. What does that have to do with writef()? You can call to!string, but that's beside the point. The point was getting rid of this verbosity when using C APIs. You should anyway wrap those APIs not to pollute D call with lower level APIs. As such I don't find the verbosity, as you put it, that much of an issue. Then again, I favor the Pascal family of languages for systems programming. -- Paulo
Re: It seems pure ain't so pure after all
I'll have to consider all functions potentially schizophrenic then. They might do one thing at compile-time and another at run-time. I was going to make a feature request to add a compiler flag for making more functions execute at compile-time than those which the compiler *has* to. But this __ctfe thing renders that impossible.
Re: Idea: Introduce zero-terminated string specifier
On Monday, 1 October 2012 at 06:58:41 UTC, Paulo Pinto wrote: You should anyway wrap those APIs not to pollute D call with lower level APIs. I have to agree, esp when it applies to pointers. We should not forget that one of the objectives of D is to make coding safe by getting rid of the need to use pointers and other unsafe features. It encourages safe practice by making safe practice much easier to do than using unsafe practice. It however allows unsafe practice where necessary, but the programmer has to intentionally do something extra to make that happen. I think the suggestion of introducing a null string specifier fundamentally goes against the objectives of D, and if introduced will unltimately degrade the quality of the language. --rt
Re: It seems pure ain't so pure after all
On Monday, October 01, 2012 09:46:43 Tommi wrote: I'll have to consider all functions potentially schizophrenic then. They might do one thing at compile-time and another at run-time. That's only the case if they're buggy, so that's pretty much the same as considering all functions potentially buggy. I was going to make a feature request to add a compiler flag for making more functions execute at compile-time than those which the compiler *has* to. But this __ctfe thing renders that impossible. I have no idea how you could possibly use a compiler flag for that, whether __ctfe or not. It really doesn't make sense to try and make functions in general run at compile time. Most of the time, functions need to be run at runtime, otherwise you wouldn't even need to generate an executable, just a result. And you _can't_ determine ahead of time which functions can be safely executed at compile time either, because that's an instance of the halting problem. So, it really doesn't make sense to have the compiler trying to evaluate functions at compile time when it hasn't been explicitly told to. And it works just fine to assign the result of a function call to enum if you want a specific function call to be executed at compile time, so I really don't think that this is an issue anyway. - Jonathan M Davis
Re: It seems pure ain't so pure after all
On Monday, 1 October 2012 at 06:25:19 UTC, Tommi wrote: On Monday, 1 October 2012 at 06:18:48 UTC, Jonathan M Davis wrote: A function which uses __ctfe should probably do essentially the same thing at both runtime and compile time, but it _has_ __ctfe, because the runtime implementation won't work at compile time, and it's up to the programmer to make sure that the function does what it's supposed to at both compile time and runtime. The compiler can't possibly enforce that. Thus we're in a situation where pure means pure only by convention, not because it's enforced by the compiler. It's like const in c++ then, it's const only by convention, only because people promise that they're not going to mutate it. I don't like rules that are enforced only by everybody relying on good manners. The only real problem here is that you wrote a function called pow2 that effectively returns 6 unconditionally. I doubt your math professor would be particularly impressed. If you had used __ctfe properly, it would return the same value both at compile-time and runtime. At present, __ctfe is a necessary evil as CTFE can be severely crippled without it.
Re: Idea: Introduce zero-terminated string specifier
Adam D. Ruppe wrote: On Saturday, 29 September 2012 at 02:11:12 UTC, Alex Rønne Petersen wrote: While the idea is reasonable, the problem then becomes that if you accidentally pass a non-zero terminated char* to %sz, all hell breaks loose just like with printf. That's the same risk with to!string(), yes? We aren't really losing anything by adding it. Also this reminds me of the utter uselessness of the current behavior of %s and a pointer - it prints the address. Why not specialize current %s for character pointer types so it will print null terminated strings? It's always possible to cast to void* to print an address.
Re: Idea: Introduce zero-terminated string specifier
On Monday, 1 October 2012 at 09:17:52 UTC, Piotr Szturmaj wrote: Adam D. Ruppe wrote: On Saturday, 29 September 2012 at 02:11:12 UTC, Alex Rønne Petersen wrote: Also this reminds me of the utter uselessness of the current behavior of %s and a pointer - it prints the address. Why not specialize current %s for character pointer types so it will print null terminated strings? It's always possible to cast to void* to print an address. It's not safe to assume that pointers to characters are generally null terminated.
Re: Idea: Introduce zero-terminated string specifier
Jakob Ovrum wrote: On Monday, 1 October 2012 at 09:17:52 UTC, Piotr Szturmaj wrote: Adam D. Ruppe wrote: On Saturday, 29 September 2012 at 02:11:12 UTC, Alex Rønne Petersen wrote: Also this reminds me of the utter uselessness of the current behavior of %s and a pointer - it prints the address. Why not specialize current %s for character pointer types so it will print null terminated strings? It's always possible to cast to void* to print an address. It's not safe to assume that pointers to characters are generally null terminated. Yes, but programmer should know what he's passing anyway.
Re: Idea: Introduce zero-terminated string specifier
On Monday, October 01, 2012 11:18:16 Piotr Szturmaj wrote: Adam D. Ruppe wrote: On Saturday, 29 September 2012 at 02:11:12 UTC, Alex Rønne Petersen wrote: While the idea is reasonable, the problem then becomes that if you accidentally pass a non-zero terminated char* to %sz, all hell breaks loose just like with printf. That's the same risk with to!string(), yes? We aren't really losing anything by adding it. Also this reminds me of the utter uselessness of the current behavior of %s and a pointer - it prints the address. Why not specialize current %s for character pointer types so it will print null terminated strings? It's always possible to cast to void* to print an address. Honestly? One of Phobos' best features is the fact that %s works for _everything_. Specializing it for _anything_ would be horrible. It would also break a _ton_ of code. Who even uses %d, %f, etc. if they don't need to use format specifiers? It's just way simpler to always use %s. I'm not completely against the idea of %zs, but I confess that I have to wonder what someone is doing if they really need to print zero-terminated strings all that often in D for anything other than quick debugging (in which case to!string works just fine), since only stuff directly interacting with C code will even care. And if it's really that big a deal, and you're constantly interacting with C code like that, you can always use the appropriate C function - printf - and then it's a non-issue. - Jonathan M Davis
Re: Idea: Introduce zero-terminated string specifier
On Monday, 1 October 2012 at 09:42:08 UTC, Piotr Szturmaj wrote: Jakob Ovrum wrote: On Monday, 1 October 2012 at 09:17:52 UTC, Piotr Szturmaj wrote: Adam D. Ruppe wrote: On Saturday, 29 September 2012 at 02:11:12 UTC, Alex Rønne Petersen wrote: Also this reminds me of the utter uselessness of the current behavior of %s and a pointer - it prints the address. Why not specialize current %s for character pointer types so it will print null terminated strings? It's always possible to cast to void* to print an address. It's not safe to assume that pointers to characters are generally null terminated. Yes, but programmer should know what he's passing anyway. The thinking the programmer should only works in one man teams. As soon as you start having teams with disparate programming knowledge among team members, you can forget everything about the programmer should. .. Paulo
Re: dynamic library building and loading
Am Sat, 29 Sep 2012 15:19:30 +0200 schrieb Jacob Carlborg d...@me.com: On 2012-09-28 20:25, Maxim Fomin wrote: I tried to check how TLS, EX, etc. (mostly exposed to dll issue) are working and here is some kind of test: https://github.com/mxfm/sharedtest. Unfortunately scope(exit) isn't executed when it is situated in a shared library and which calls some throwing function from another shared library. Unittests aren't working either. Regarding other parts - they seem to work. That's a fairly uninteresting test. You are linking to the dynamic library. What's interesting is loading a dynamic library using dlopen, or similar. What's the point of using dynamic libraries if you're linking with them? There are some reasons for dynamic libraries linked at compile time, one is that we have to start somewhere and they are required for plugins / dynamically loaded libraries as well ;-) So I started a small test suite for GDC (could be adapted to other compilers). It currently only tests compile time linking of dynamic libraries, but adjusting the test to use runtime loading should be easy. But it's pointless as long as we have no runtime support. https://github.com/jpf91/dso-test It should also be enhanced to test multiple shared libraries. The good news: * Exception handling is working * ModuleInfos are working * unit tests are working * Static variables, gshared variables, tls variables are working * Object.factory is working * Calling functions, passing function pointers, passing classes between dso/app is working The bad news: * The GC doesn't scan TLS/__gshared/static data in dynamic libraries, it only scans the main app.
Re: Dangling if
F i L:
This is exactly why I think the '{}' brackets should be a
requirement and not the '()' brackets:
if a == b { doSomething(); }
if a == b
{ doSomething(); }
if a == b
{
doSomething();
doSomethingElse();
}
I know this will never happen in D, but it's how it should be,
IMO.
This is what Go designers think.
Bye,
bearophile
Re: Idea: Introduce zero-terminated string specifier
Le 30/09/2012 21:58, Vladimir Panteleev a écrit : On Sunday, 30 September 2012 at 18:31:00 UTC, deadalnix wrote: If you know that a string is 0 terminated, you can easily create a slice from it as follow : char* myZeroTerminatedString; char[] myZeroTerminatedString[0 .. strlen(myZeroTerminatedString)]; It is clean and avoid to modify the stdlib in an unsafe way. That's what to!string already does. How does to!string know that the string is 0 terminated ?
Re: Idea: Introduce zero-terminated string specifier
Paulo Pinto wrote:
On Monday, 1 October 2012 at 09:42:08 UTC, Piotr Szturmaj wrote:
Jakob Ovrum wrote:
On Monday, 1 October 2012 at 09:17:52 UTC, Piotr Szturmaj wrote:
Adam D. Ruppe wrote:
On Saturday, 29 September 2012 at 02:11:12 UTC, Alex Rønne Petersen
wrote:
Also this reminds me of the utter uselessness of the current
behavior of
%s and a pointer - it prints the address.
Why not specialize current %s for character pointer types so it will
print null terminated strings? It's always possible to cast to void*
to print an address.
It's not safe to assume that pointers to characters are generally null
terminated.
Yes, but programmer should know what he's passing anyway.
The thinking the programmer should only works in one man teams.
As soon as you start having teams with disparate programming knowledge
among team members, you can forget everything about the programmer
should.
I experienced such team at my previous work and I know what you mean. My
original thoughts was based on telling writef that I want print a
null-terminated string rather than address. to!string will surely work,
but it implies double iteration, one in to!string to calculate length
(seeking for 0 char) and one in writef (printing). With long strings
this is suboptimal. What about something like this:
struct CString(T)
if (isSomeChar!T)
{
T* str;
}
@property
auto cstring(S : T*, T)(S str)
if (isSomeChar!T)
{
return CString!T(str);
}
string test = abc;
immutable(char)* p = test.ptr;
writefln(%s, p.cstring); // prints abc
Here the char pointer type is annotated as null terminated string and
writefln can use this information.
Re: Idea: Introduce zero-terminated string specifier
On Monday, 1 October 2012 at 10:56:36 UTC, deadalnix wrote: Le 30/09/2012 21:58, Vladimir Panteleev a écrit : On Sunday, 30 September 2012 at 18:31:00 UTC, deadalnix wrote: If you know that a string is 0 terminated, you can easily create a slice from it as follow : char* myZeroTerminatedString; char[] myZeroTerminatedString[0 .. strlen(myZeroTerminatedString)]; It is clean and avoid to modify the stdlib in an unsafe way. That's what to!string already does. How does to!string know that the string is 0 terminated ? By convention (it doesn't).
Re: Idea: Introduce zero-terminated string specifier
Jonathan M Davis wrote: On Monday, October 01, 2012 11:18:16 Piotr Szturmaj wrote: Adam D. Ruppe wrote: On Saturday, 29 September 2012 at 02:11:12 UTC, Alex Rønne Petersen wrote: While the idea is reasonable, the problem then becomes that if you accidentally pass a non-zero terminated char* to %sz, all hell breaks loose just like with printf. That's the same risk with to!string(), yes? We aren't really losing anything by adding it. Also this reminds me of the utter uselessness of the current behavior of %s and a pointer - it prints the address. Why not specialize current %s for character pointer types so it will print null terminated strings? It's always possible to cast to void* to print an address. Honestly? One of Phobos' best features is the fact that %s works for _everything_. Specializing it for _anything_ would be horrible. It would also break a _ton_ of code. Who even uses %d, %f, etc. if they don't need to use format specifiers? It's just way simpler to always use %s. OK, I think you're right. I'm not completely against the idea of %zs, but I confess that I have to wonder what someone is doing if they really need to print zero-terminated strings all that often in D for anything other than quick debugging (in which case to!string works just fine), since only stuff directly interacting with C code will even care. And if it's really that big a deal, and you're constantly interacting with C code like that, you can always use the appropriate C function - printf - and then it's a non-issue. Imagine you're serializing great amount of text when some of the text come from a C library (as null-terminated char*) and you're using format() with %s specifiers. Direct handling of C strings would be just faster because it avoids double iteration.
Re: Dangling if
On Fri, 28 Sep 2012 06:03:41 +0200, Bernard Helyer b.hel...@gmail.com wrote: By the time the compiler even has a concept of an 'if statement' or a 'block' the whitespace is long gone. Not to say you couldn't change the lexing model to detect such things, but it's not a simple as you make it sound. Not so with my compiler implementation. It would be trivial to add such a check to the Parser. A newline is its own (whitespace) Token, so it would simply require looking for two consecutive newline tokens, in order to give an error or a warning for that case. However, including such special checks would quickly bloat the Parser code and make it difficult to read. A better solution would be a class which traverses the parse tree and implements the checks in its methods. Another more complex way to do this is to design a querying language (similar to XPath) which returns a set of Nodes according to a query string, on which you can perform arbitrary checks. -- My D Compiler: http://code.google.com/p/dil
Re: Idea: Introduce zero-terminated string specifier
Am Mon, 01 Oct 2012 13:22:46 +0200
schrieb Piotr Szturmaj bncr...@jadamspam.pl:
Paulo Pinto wrote:
On Monday, 1 October 2012 at 09:42:08 UTC, Piotr Szturmaj wrote:
Jakob Ovrum wrote:
On Monday, 1 October 2012 at 09:17:52 UTC, Piotr Szturmaj wrote:
Adam D. Ruppe wrote:
On Saturday, 29 September 2012 at 02:11:12 UTC, Alex Rønne
Petersen wrote:
Also this reminds me of the utter uselessness of the current
behavior of
%s and a pointer - it prints the address.
Why not specialize current %s for character pointer types so
it will print null terminated strings? It's always possible to
cast to void* to print an address.
It's not safe to assume that pointers to characters are generally
null terminated.
Yes, but programmer should know what he's passing anyway.
The thinking the programmer should only works in one man teams.
As soon as you start having teams with disparate programming
knowledge among team members, you can forget everything about the
programmer should.
I experienced such team at my previous work and I know what you mean.
My original thoughts was based on telling writef that I want print a
null-terminated string rather than address. to!string will surely
work, but it implies double iteration, one in to!string to calculate
length (seeking for 0 char) and one in writef (printing). With long
strings this is suboptimal. What about something like this:
struct CString(T)
if (isSomeChar!T)
{
T* str;
}
@property
auto cstring(S : T*, T)(S str)
if (isSomeChar!T)
{
return CString!T(str);
}
string test = abc;
immutable(char)* p = test.ptr;
writefln(%s, p.cstring); // prints abc
Here the char pointer type is annotated as null terminated string
and writefln can use this information.
If CString implemented a toString method (probably the variant taking a
sink delegate), this would already work. I'm not sure about performance
though: Isn't writing out bigger buffers a lot faster than writing
single chars? You could print every char individually, but wouldn't a
p[0 .. strlen(p)] usually be faster?
Re: Idea: Introduce zero-terminated string specifier
Le 01/10/2012 13:29, Vladimir Panteleev a écrit : On Monday, 1 October 2012 at 10:56:36 UTC, deadalnix wrote: Le 30/09/2012 21:58, Vladimir Panteleev a écrit : On Sunday, 30 September 2012 at 18:31:00 UTC, deadalnix wrote: If you know that a string is 0 terminated, you can easily create a slice from it as follow : char* myZeroTerminatedString; char[] myZeroTerminatedString[0 .. strlen(myZeroTerminatedString)]; It is clean and avoid to modify the stdlib in an unsafe way. That's what to!string already does. How does to!string know that the string is 0 terminated ? By convention (it doesn't). It is unsafe as hell oO
Re: I have a feature request: Named enum scope inference
Le 29/09/2012 14:04, Bernard Helyer a écrit : Yeah, to respond to the larger topic, the with statement is more than enough here. I'm not convinced that complicating lookup rules further is worth it. Well, they are not complicated, they are mostly undefined.
A study on immutability usage
I am back.
This study regards how final is used in Java programs, and
generally how immutability is used and is useful:
http://whiley.org/2012/09/30/profiling-field-initialisation-in-java/
Slides:
http://www.ecs.vuw.ac.nz/~djp/files/RV2012.ppt
Paper, Pro ling Field Initialisation in Java, by Stephen
Nelson, David J. Pearce, and James Noble:
http://www.ecs.vuw.ac.nz/~djp/files/RV2012.pdf
Some quotations from the paper:
Unkel and Lam developed the term stationary field to describe
fields which are never observed to change, that is, all writes
precede all reads [for such field in all instances of the class]
Our results from 14 Java applications indicates that 72-82% of
fields are stationary
programmers are sometimes forced (or voluntarily choose) to
initialise fields late (i.e. after the constructor has
completed). This prevents such fields from being marked final
even when they are designed to be immutable.
They show a little example that in D becomes similar to (I have
made them not abstract):
class Parent {
private const Child child;
public this(in Child c) pure nothrow {
this.child = c;
}
}
class Child {
private Parent parent; // can't be const
public void setParent(Parent p) pure nothrow {
this.parent = p;
}
}
void main() {
auto c = new Child;
auto p = new Parent(c); // can't be const
c.setParent(p);
}
The programmer intends that every Parent has a Child and
vice-versa and, furthermore, that these do not change for the
life of the program. He/she has marked the eld Parent.child as
nal in an e ort to enforce this. However, he/she is unable to
mark the eld Child.parent as nal because one object must be
constructed before the other.
In the end they say that maybe it's good to have language-level
support for this usage. It's quite common for language designers
to turn idioms into built-in features. In the D community a
stationary field is probably very similar to what's named
logical const field.
In the last section of the paper about Related Work, they show
links to several ideas to implement logical const fields:
Several works have looked at permitting type-safe late
initialisation of objects in a programming language. Summers and
Mull epresented a lightweight system for type checking delayed
object initialiation which is sufficiently expressive to handle
cyclic initialisation [6]. Fahndrich and Xia's Delayed Types
[2] use dynamically nested regions in an ownership-style type
system to represent this post-construction initialisation phase,
and ensure that programs do not access uninitialised fields.
Haack and Poll [1] have shown how these techniques can be
applied speci cally to immutability, and Leino et al. [3] show
how ownership transfer (rather than nesting) can achieve a
similar result. Qi and Myers' Masked Types [21] use type-states
to address this problem by incorporating a list of uninitialised
fields (masked fields) into object types. Gil and Shragai [22]
address the related problem of ensuring correct initialisation
between subclass and superclass constructors within individual
objects. Based on our results, we would expect such type systems
to be of bene t to real programs.
Even if late initialized const fields are not really const, and
the compiler is not able to use this information in any useful
way, they seem useful for (active and enforced) documentation and
to avoid some bugs.
Bye,
bearophile
Re: It seems pure ain't so pure after all
Le 01/10/2012 08:07, Jonathan M Davis a écrit : On Monday, October 01, 2012 07:58:39 Tommi wrote: On Monday, 1 October 2012 at 05:43:39 UTC, Alex Rønne Petersen wrote: As far as purity goes, pow2 *is* pure. ... According to http://en.wikipedia.org/wiki/Pure_function it's not: The [pure] function always evaluates the same result value given the same argument value(s) Forget what Wikipedia says about pure. If you focus on that, you're going to be complaining about D's pure left and right, because what it's talking about and what D does are related but very different. D takes a very practical approach to functional purity. You should read this: http://stackoverflow.com/questions/8572399 - Jonathan M Davis Or that : http://klickverbot.at/blog/2012/05/purity-in-d/
Re: dynamic library building and loading
On 2012-10-01 12:42, Johannes Pfau wrote: There are some reasons for dynamic libraries linked at compile time, one is that we have to start somewhere and they are required for plugins / dynamically loaded libraries as well ;-) So I started a small test suite for GDC (could be adapted to other compilers). It currently only tests compile time linking of dynamic libraries, but adjusting the test to use runtime loading should be easy. But it's pointless as long as we have no runtime support. https://github.com/jpf91/dso-test It should also be enhanced to test multiple shared libraries. The good news: * Exception handling is working * ModuleInfos are working * unit tests are working * Static variables, gshared variables, tls variables are working * Object.factory is working * Calling functions, passing function pointers, passing classes between dso/app is working That's good. Have you tested this with DMD? The bad news: * The GC doesn't scan TLS/__gshared/static data in dynamic libraries, it only scans the main app. That should be fairly trivial on Mac OS X. But I'm suspecting it won't be that easy on Linux. BTW, is the runtime and phobos statically linked both with the dynamic library and the executable? -- /Jacob Carlborg
Re: dynamic library building and loading
On 1 October 2012 13:34, Jacob Carlborg d...@me.com wrote: On 2012-10-01 12:42, Johannes Pfau wrote: There are some reasons for dynamic libraries linked at compile time, one is that we have to start somewhere and they are required for plugins / dynamically loaded libraries as well ;-) So I started a small test suite for GDC (could be adapted to other compilers). It currently only tests compile time linking of dynamic libraries, but adjusting the test to use runtime loading should be easy. But it's pointless as long as we have no runtime support. https://github.com/jpf91/dso-test It should also be enhanced to test multiple shared libraries. The good news: * Exception handling is working * ModuleInfos are working * unit tests are working * Static variables, gshared variables, tls variables are working * Object.factory is working * Calling functions, passing function pointers, passing classes between dso/app is working That's good. Have you tested this with DMD? The bad news: * The GC doesn't scan TLS/__gshared/static data in dynamic libraries, it only scans the main app. That should be fairly trivial on Mac OS X. But I'm suspecting it won't be that easy on Linux. BTW, is the runtime and phobos statically linked both with the dynamic library and the executable? -- /Jacob Carlborg On Linux, there has already been an runtime implementation written that scans /proc/self/maps and adds all data sections to the GC that way. Whether or not DMD wishes to go down that route is their own decision. I am looking into a solution that doesn't have any bearing on what platform it's running on... Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Dangling if
On 10/1/12, Aziz K. aziz.koek...@gmail.com wrote: Not so with my compiler implementation. It would be trivial to add such a check to the Parser. I'm realizing now it's not just blank spaces. There could be a comment line instead. :)
Re: Dangling if
Nick Sabalausky: I don't think there's ever been a time I've forgotten to add curly braces when adding another statement to a one-statement 'if' or 'else' clause. Even if you never err on this, it's a known source of bugs (that Python and Go avoid) for average coders. Bye, bearophile
Re: Dangling if
On Sun, 30 Sep 2012 11:42:40 +0200
monarch_dodra monarchdo...@gmail.com wrote:
On Friday, 28 September 2012 at 17:40:17 UTC, Andrej Mitrovic
wrote:
On 9/28/12, Bernard Helyer b.hel...@gmail.com wrote:
By the time the compiler even has a concept of an 'if
statement'
or a 'block' the whitespace is long gone. Not to say you
couldn't change the lexing model to detect such things,
but it's not a simple as you make it sound.
I see, so it's an implementation limitation. I guess we'll have
to
resort to that dlint tool which will have to be built.
Personally, EVEN when I'm doing a 1 line if, I *still* wrap it in
a block. EG:
if(a == 0)
a = 1;
or
if(a == 0) a = 1;
Becomes:
if(a == 0)
{a = 1;}
or
if(a == 0) {a = 1;}
It might look iffy at first, but very quickly feels natural. It
may look like it requires (god forbid) useless typing, but when
that 1 liner becomes a 2 liner, it saves your life.
It has saved mine more than once actually!
I've done the dangling if bug often. One day I said no-more!.
I've addopted the above format, and it has not happened to me
since.
Further more, thanks to D's ban on if();, you can litterally
never fail with this format. I warmly recommend it to every one.
I don't know if maybe this is somehow related to my inability to accept
or feel comfortable with indent-based languages, but I don't think
there's ever been a time I've forgotten to add curly braces when adding
another statement to a one-statement 'if' or 'else' clause. It's just
automatically the first thing I do, kinda like automatically turning
the headlights off when I park the car (although the headlights thing
is admittedly much more subconscious than the curly braces). I'll
forget a semicolon pretty often, but the {} I haven't had a problem
with.
I might just be weird, though.
Re: [OT] Gibberish webpages
On Monday, 1 October 2012 at 12:54:45 UTC, Andrei Alexandrescu wrote: I have a Google alert on D programming language and it sometimes yields pages like this: http://swpp.co.uk/lovegovee.php?lib=1612 It looks like random sentences either scraped from other sites or generated using a language model. What would be the purpose of all this? Thanks, Andrei To hit random search results and make some delicious ad money.
[OT] Gibberish webpages
I have a Google alert on D programming language and it sometimes yields pages like this: http://swpp.co.uk/lovegovee.php?lib=1612 It looks like random sentences either scraped from other sites or generated using a language model. What would be the purpose of all this? Thanks, Andrei
Re: [OT] Gibberish webpages
It seems a markov-chain generated page :) Some months ago I took all user-comments (thousands) from the website I'm working for, and using a markov chain I published new random comments. We should try with newsgroup archives. So we can post random dlang questions and answers :) Il giorno lun, 01/10/2012 alle 14.56 +0200, Bernard Helyer ha scritto: On Monday, 1 October 2012 at 12:54:45 UTC, Andrei Alexandrescu wrote: I have a Google alert on D programming language and it sometimes yields pages like this: http://swpp.co.uk/lovegovee.php?lib=1612 It looks like random sentences either scraped from other sites or generated using a language model. What would be the purpose of all this? Thanks, Andrei To hit random search results and make some delicious ad money.
Re: dynamic library building and loading
On 2012-10-01 14:40, Iain Buclaw wrote: On Linux, there has already been an runtime implementation written that scans /proc/self/maps and adds all data sections to the GC that way. Whether or not DMD wishes to go down that route is their own decision. I am looking into a solution that doesn't have any bearing on what platform it's running on... Well, /proc isn't available on Mac OS X so I think you have to continue looking. -- /Jacob Carlborg
Re: dynamic library building and loading
On 2012-10-01 12:42, Johannes Pfau wrote: There are some reasons for dynamic libraries linked at compile time, one is that we have to start somewhere and they are required for plugins / dynamically loaded libraries as well ;-) So I started a small test suite for GDC (could be adapted to other compilers). It currently only tests compile time linking of dynamic libraries, but adjusting the test to use runtime loading should be easy. But it's pointless as long as we have no runtime support. https://github.com/jpf91/dso-test Isn't dmain2 used when building shared libraries using GDC? That's where the implementation of rt_init is located. -- /Jacob Carlborg
Re: dynamic library building and loading
On 2012-10-01 14:40, Iain Buclaw wrote: On Linux, there has already been an runtime implementation written that scans /proc/self/maps and adds all data sections to the GC that way. Whether or not DMD wishes to go down that route is their own decision. I am looking into a solution that doesn't have any bearing on what platform it's running on... I think this is already working on Mac OS X. It's handled by: https://github.com/D-Programming-Language/druntime/blob/master/src/rt/memory_osx.d#L82 https://github.com/D-Programming-Language/druntime/blob/master/src/rt/memory_osx.d#L133 -- /Jacob Carlborg
Re: Idea: Introduce zero-terminated string specifier
On Mon, 01 Oct 2012 05:54:30 -0400, Jonathan M Davis jmdavisp...@gmx.com wrote: I'm not completely against the idea of %zs, but I confess that I have to wonder what someone is doing if they really need to print zero-terminated strings all that often in D for anything other than quick debugging (in which case to!string works just fine) to!string necessarily allocates, I think that is not a small problem. I think %s should treat char * as if it is zero-terminated. Invariably, you will have two approaches to this problem: 1. writefln(%s, mycstring); = 0xptrlocation 2. hm.., I guess I'll just use to!string = vulnerable to non-zero-terminated strings! or 2. hm.., to!string will allocate, I guess I'll just use writefln(%s, mycstring[0..strlen(mycstring)]); = vulnerable to non-zero-terminated strings! So how is forcing the user to use one of these methods any safer? I don't see any casts in there... , since only stuff directly interacting with C code will even care. And if it's really that big a deal, and you're constantly interacting with C code like that, you can always use the appropriate C function - printf - and then it's a non-issue. Nobody should ever *ever* use printf, unless you are debugging druntime. It's not a non-issue. printf has no type checking whatsoever. Using it means 1) non-typechecked code (i.e., accidentally pass an int instead of a string, or forget to pass an arg for a specifier, and you've crashed your code), and 2) you have locked yourself into using C's streams (something I hope to remedy in the future). Besides, it doesn't *gain* you anything over having writef(ln) just support char *. Bottom line -- if to!string(arg) is supported, writefln(%s, arg) should be supported, and do the same thing. -Steve
Re: Getting started with D - Phobos documentation sucks
On Sun, 30 Sep 2012 07:02:15 -0400, Jacob Carlborg d...@me.com wrote: On 2012-09-30 04:17, Adam D. Ruppe wrote: On Saturday, 29 September 2012 at 17:20:48 UTC, Dmitry Olshansky wrote: Agreed. What's needed to make it a reality ? Need to integrate my helper program into the website build process. Is it just me that thinks that having a tool that fixes the generated documentation is ridiculous. The compiler should be modified to generate the documentation we want to have. it's not just you... -Steve
Re: It seems pure ain't so pure after all
On Mon, 01 Oct 2012 01:40:37 -0400, Tommi tommitiss...@hotmail.com wrote:
import std.stdio;
int pow2(int val) pure
{
if (__ctfe)
return 6;
else
return val * val;
}
void main()
{
assert(pow2(3) == 9);
static assert(pow2(3) == 6);
writeln(9 = 6 ... I knew it! '6' was faking it all along);
readln();
}
You have a bug in your code, here let me fix that for you:
int pow2(int val) pure
{
return val * val;
}
OK, on to the next thread...
-Steve
Re: Dangling if
On Mon, 01 Oct 2012 14:41:01 +0200, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: I'm realizing now it's not just blank spaces. There could be a comment line instead. :) Okay, but that doesn't really make it more difficult. :-) -- My D Compiler: http://code.google.com/p/dil
Re: Idea: Introduce zero-terminated string specifier
Johannes Pfau wrote:
struct CString(T)
if (isSomeChar!T)
{
T* str;
}
@property
auto cstring(S : T*, T)(S str)
if (isSomeChar!T)
{
return CString!T(str);
}
string test = abc;
immutable(char)* p = test.ptr;
writefln(%s, p.cstring); // prints abc
Here the char pointer type is annotated as null terminated string
and writefln can use this information.
If CString implemented a toString method (probably the variant taking a
sink delegate), this would already work.
I reworked this example to form a forward range:
http://dpaste.dzfl.pl/7ab1eeec
The major advantage over %zs is that it could be used anywhere, not
only with writef().
For example C binding writers may change:
extern(C) char* getstr();
to
extern(C) cstring getstr();
so the string may be immediately used with writef();
I'm not sure about performance
though: Isn't writing out bigger buffers a lot faster than writing
single chars? You could print every char individually, but wouldn't a
p[0 .. strlen(p)] usually be faster?
I think it internally prints single characters anyway. At least it must
test each character if it's not zero valued. strlen() does that.
Re: Getting started with D - Phobos documentation sucks
I think documentation is really important, and something has to
be done about it. How can a newcomer get started with D when he
doesn't have a readable documentation of Phobos?
A couple of random things I'd like to see:
1. Improve index.html. It's the first thing new users are likely
to see about Phobos and it appears to contain an overview of the
modules, but in fact it only lists half the modules of Phobos and
the description of most modules is too short to be useful. There
should also be a getting-started guide that lists the most common
data types and functions and which module contains them (to!T,
Tuple, writeln, ) and it should also discuss the 'built-in'
types for completeness, like slices, hashes and strings, since in
other languages these are standard library components.)
2. To make the documentation easier to Google, put the keyword
D2 on every page of the Phobos documentation, e.g. the heading
could change from std.file to std.file (D2). Nowadays when I
search for something about D Language, I often find a page
about D1 instead of D2.
The articles should be reviewed too. For example the page on
tuples http://dlang.org/tuple.html makes it sound like you're
supposed to define your own Tuple type instead of using the one
in std.typecons; in fact it suggests
template Tuple(E...) { alias E Tuple; }
which is really a TypeTuple isn't it?
Re: dynamic library building and loading
Am Mon, 01 Oct 2012 14:34:21 +0200 schrieb Jacob Carlborg d...@me.com: On 2012-10-01 12:42, Johannes Pfau wrote: There are some reasons for dynamic libraries linked at compile time, one is that we have to start somewhere and they are required for plugins / dynamically loaded libraries as well ;-) So I started a small test suite for GDC (could be adapted to other compilers). It currently only tests compile time linking of dynamic libraries, but adjusting the test to use runtime loading should be easy. But it's pointless as long as we have no runtime support. https://github.com/jpf91/dso-test It should also be enhanced to test multiple shared libraries. The good news: * Exception handling is working * ModuleInfos are working * unit tests are working * Static variables, gshared variables, tls variables are working * Object.factory is working * Calling functions, passing function pointers, passing classes between dso/app is working That's good. Have you tested this with DMD? Not yet. The bad news: * The GC doesn't scan TLS/__gshared/static data in dynamic libraries, it only scans the main app. That should be fairly trivial on Mac OS X. But I'm suspecting it won't be that easy on Linux. BTW, is the runtime and phobos statically linked both with the dynamic library and the executable? I tested two different configurations: druntime and phobos are shared libraries as well (this is the correct solution, it's mostly working except for the GC issues) druntime and phobos static linking: phobos and druntime are statically linked into the app, libdso.so is not linked against druntime/phobos at all. (this is a hack to get better test results: With a shared druntime, you can't call GC.collect twice, because the first call frees important objects in druntime and then the second call segfaults)
Re: dynamic library building and loading
Am Mon, 01 Oct 2012 15:11:49 +0200 schrieb Jacob Carlborg d...@me.com: On 2012-10-01 12:42, Johannes Pfau wrote: There are some reasons for dynamic libraries linked at compile time, one is that we have to start somewhere and they are required for plugins / dynamically loaded libraries as well ;-) So I started a small test suite for GDC (could be adapted to other compilers). It currently only tests compile time linking of dynamic libraries, but adjusting the test to use runtime loading should be easy. But it's pointless as long as we have no runtime support. https://github.com/jpf91/dso-test Isn't dmain2 used when building shared libraries using GDC? That's where the implementation of rt_init is located. the problem is that we don't want the C main function in a shared libgdruntime.so, because you might want to use libgdruntime.so in a C/C++ app which has it's own main function. So we currently don't link in dmain2.o into the shared library and it must be included manually when linking an application. (But dmain2 also contains some stuff that really should be in libdruntime.so, so this source file should probably be split up at some time.)
Re: Dangling if
On Monday, October 01, 2012 08:56:25 Nick Sabalausky wrote:
I don't know if maybe this is somehow related to my inability to accept
or feel comfortable with indent-based languages, but I don't think
there's ever been a time I've forgotten to add curly braces when adding
another statement to a one-statement 'if' or 'else' clause. It's just
automatically the first thing I do, kinda like automatically turning
the headlights off when I park the car (although the headlights thing
is admittedly much more subconscious than the curly braces). I'll
forget a semicolon pretty often, but the {} I haven't had a problem
with.
I'm in the same boat. I've never had a problem with this, and it baffles me
that
people keep thinking that it's an issue.
I might just be weird, though.
Well, you are. ;)
But not because of this.
- Jonathan M Davis
P.S. #1 reason to hate languages which don't use braces: there's no way in vim
to hop to the beginning or end of a scope block (or function) from the other
end. And _man_ is that annoying. God bless braces.
Re: dynamic library building and loading
On 1 October 2012 16:06, Johannes Pfau nos...@example.com wrote: Am Mon, 01 Oct 2012 15:11:49 +0200 schrieb Jacob Carlborg d...@me.com: On 2012-10-01 12:42, Johannes Pfau wrote: There are some reasons for dynamic libraries linked at compile time, one is that we have to start somewhere and they are required for plugins / dynamically loaded libraries as well ;-) So I started a small test suite for GDC (could be adapted to other compilers). It currently only tests compile time linking of dynamic libraries, but adjusting the test to use runtime loading should be easy. But it's pointless as long as we have no runtime support. https://github.com/jpf91/dso-test Isn't dmain2 used when building shared libraries using GDC? That's where the implementation of rt_init is located. the problem is that we don't want the C main function in a shared libgdruntime.so, because you might want to use libgdruntime.so in a C/C++ app which has it's own main function. That is at least one of the theories behind it anyway. :-) The more I think about it, the less I think I would want a C++ app to link against a D shared library though. With C, there will need to be defined a common interface header - similar to what used to be mars.h in rt/ but also contain some useful runtime functions. Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Dangling if
On Monday, 1 October 2012 at 12:56:05 UTC, Nick Sabalausky wrote:
On Sun, 30 Sep 2012 11:42:40 +0200
monarch_dodra monarchdo...@gmail.com wrote:
On Friday, 28 September 2012 at 17:40:17 UTC, Andrej Mitrovic
wrote:
On 9/28/12, Bernard Helyer b.hel...@gmail.com wrote:
By the time the compiler even has a concept of an 'if
statement'
or a 'block' the whitespace is long gone. Not to say you
couldn't change the lexing model to detect such things,
but it's not a simple as you make it sound.
I see, so it's an implementation limitation. I guess we'll
have to
resort to that dlint tool which will have to be built.
Personally, EVEN when I'm doing a 1 line if, I *still* wrap it
in a block. EG:
if(a == 0)
a = 1;
or
if(a == 0) a = 1;
Becomes:
if(a == 0)
{a = 1;}
or
if(a == 0) {a = 1;}
It might look iffy at first, but very quickly feels natural.
It may look like it requires (god forbid) useless typing,
but when that 1 liner becomes a 2 liner, it saves your life.
It has saved mine more than once actually!
I've done the dangling if bug often. One day I said
no-more!. I've addopted the above format, and it has not
happened to me since.
Further more, thanks to D's ban on if();, you can litterally
never fail with this format. I warmly recommend it to every
one.
I don't know if maybe this is somehow related to my inability
to accept
or feel comfortable with indent-based languages, but I don't
think
there's ever been a time I've forgotten to add curly braces
when adding
another statement to a one-statement 'if' or 'else' clause.
It's just
automatically the first thing I do, kinda like automatically
turning
the headlights off when I park the car (although the
headlights thing
is admittedly much more subconscious than the curly braces).
I'll
forget a semicolon pretty often, but the {} I haven't had a
problem
with.
I might just be weird, though.
Modern cars do have a warning system - The car makes a beep noise
when opening the door while the headlights are on to remind the
driver to turn them off.
Regarding indent-based languages - It has more cognitive costs
for the programmer:
1. Tab vs. spaces holly-wars, how many spaces to use, etc, now
become language enforced instead of a human style choice.
2. Some redundant syntax noise is necessary in a language, to
make it easier for humans to see the code, even if it's
redundant from the compiler's perspective.
A good programming language should resemble more a natural
language than a mathematically rigorous language that is easily
machine parsed. After all, we are _not_ computers. Programming
language design is after all in large part a UX/UI question.
Re: Dangling if
On Monday, 1 October 2012 at 15:26:20 UTC, Jonathan M Davis wrote:
On Monday, October 01, 2012 08:56:25 Nick Sabalausky wrote:
I don't know if maybe this is somehow related to my inability
to accept
or feel comfortable with indent-based languages, but I don't
think
there's ever been a time I've forgotten to add curly braces
when adding
another statement to a one-statement 'if' or 'else' clause.
It's just
automatically the first thing I do, kinda like automatically
turning
the headlights off when I park the car (although the
headlights thing
is admittedly much more subconscious than the curly braces).
I'll
forget a semicolon pretty often, but the {} I haven't had a
problem
with.
I'm in the same boat. I've never had a problem with this, and
it baffles me that
people keep thinking that it's an issue.
I might just be weird, though.
Well, you are. ;)
But not because of this.
- Jonathan M Davis
P.S. #1 reason to hate languages which don't use braces:
there's no way in vim
to hop to the beginning or end of a scope block (or function)
from the other
end. And _man_ is that annoying. God bless braces.
That would be an issue with your editor of choice not the
languages in question - I'm sure there are more suitable
editors/IDEs for such languages which are indent aware (as well
as scripts that add that functionality for vim).
RFC: DConf 2013
The project is not live, it will be within a few days. In the spirit of having the community actively participate, I'm making this as transparent as it gets. Please comment: http://www.kickstarter.com/projects/dlang/1177501541?token=df96761a Your feedback and suggestions are welcome. Thanks, Andrei
Re: Dangling if
On Monday, October 01, 2012 17:38:42 foobar wrote: P.S. #1 reason to hate languages which don't use braces: there's no way in vim to hop to the beginning or end of a scope block (or function) from the other end. And _man_ is that annoying. God bless braces. That would be an issue with your editor of choice not the languages in question - I'm sure there are more suitable editors/IDEs for such languages which are indent aware (as well as scripts that add that functionality for vim). It's built in to be able to hop between matching parens and braces and whatnot. Indention just doesn't work with that. You'd have to something completely different to be able to hop around in a lanugage without braces. And I'd rather have an editor that can do everything that vim can do than use a glorified notepad like most IDEs are. Most programmers don't use their keyboard to navigate through code because their editors are too primitive to do it. I have _nothing_ good to say about languages which choose to be indentation- sensitive, completely aside from editor issues. It's just that the editor issues made it so that instead of just not liking the idea, I now absolutely hate it. - Jonathan M Davis
Re: RFC: DConf 2013
On 1 October 2012 17:25, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: The project is not live, it will be within a few days. In the spirit of having the community actively participate, I'm making this as transparent as it gets. Please comment: http://www.kickstarter.com/projects/dlang/1177501541?token=df96761a Your feedback and suggestions are welcome. I will try my hardest to attend to it. :-) Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Dangling if
On 28 September 2012 02:43, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
So I just had a bug I thought I'd never have: dpaste.dzfl.pl/5c0ab8b8
It's pretty obvious what's going on from that code snippet. But in a
larger codebase where refactoring happens often it's easy to make a
mistake of leaving out a dangling if statement, which is exactly
what happened here.
It could be controversial, but maybe we should consider banning the
use of blank spaces between the beginning of a *non-blocked* if
statement and the next statement. IOW:
This is OK:
if (state) {
statement 1..
}
statement 2..
This is not ok:
if (state)
statement 1..
statement 2..
Thoughts?
Use an editor that indents code correctly. (I use vim ;-)
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Re: dynamic library building and loading
On 2012-10-01 17:03, Johannes Pfau wrote: I tested two different configurations: druntime and phobos are shared libraries as well (this is the correct solution, it's mostly working except for the GC issues) I agree. druntime and phobos static linking: phobos and druntime are statically linked into the app, libdso.so is not linked against druntime/phobos at all. (this is a hack to get better test results: With a shared druntime, you can't call GC.collect twice, because the first call frees important objects in druntime and then the second call segfaults) Ok. -- /Jacob Carlborg
Re: dynamic library building and loading
On 2012-10-01 17:06, Johannes Pfau wrote: the problem is that we don't want the C main function in a shared libgdruntime.so, because you might want to use libgdruntime.so in a C/C++ app which has it's own main function. So we currently don't link in dmain2.o into the shared library and it must be included manually when linking an application. (But dmain2 also contains some stuff that really should be in libdruntime.so, so this source file should probably be split up at some time.) I'm not sure if I follow this correctly or not, but why is this needed to be handled manually? If you pass -shared to the compiler just skip linking dmain2.o, otherwise link with it. Would that work? -- /Jacob Carlborg
qtD
Anybody knows, project qtd (http://www.dsource.org/projects/qtd/) is alive or died? Last changes was one year ago. Tracking system contains critical bugs and nobody fixes. There may be other working bindings for Qt?
Re: It seems pure ain't so pure after all
On Monday, 1 October 2012 at 08:04:49 UTC, Jonathan M Davis wrote: And you _can't_ determine ahead of time which functions can be safely executed at compile time either, because that's an instance of the halting problem. I don't understand (I did read what halting problem means just now, but I still don't understand). If there was no __ctfe variable, and thus a guarantee that all functions do the same thing at compile-time and run-time, couldn't the compiler just try aggressively to execute all function calls at compile-time? Obviously it wouldn't bother trying CTFE for function calls that had arguments which weren't evaluable at compile-time. Nor would it bother with functions that it knows have memory allocations or other limitations of CTFE. If not a compiler flag, then it could be a function attribute. Just like c++ function attribute constexpr, which guarantees that the function executes at compile time given you provide it with compile-time evaluable arguments (and there are limitations to what the function can do). Why wouldn't this attribute be possible with D?
Re: Dangling if
On Monday, 1 October 2012 at 16:44:34 UTC, Jonathan M Davis wrote: On Monday, October 01, 2012 17:38:42 foobar wrote: P.S. #1 reason to hate languages which don't use braces: there's no way in vim to hop to the beginning or end of a scope block (or function) from the other end. And _man_ is that annoying. God bless braces. That would be an issue with your editor of choice not the languages in question - I'm sure there are more suitable editors/IDEs for such languages which are indent aware (as well as scripts that add that functionality for vim). It's built in to be able to hop between matching parens and braces and whatnot. Indention just doesn't work with that. You'd have to something completely different to be able to hop around in a lanugage without braces. And I'd rather have an editor that can do everything that vim can do than use a glorified notepad like most IDEs are. Most programmers don't use their keyboard to navigate through code because their editors are too primitive to do it. I have _nothing_ good to say about languages which choose to be indentation- sensitive, completely aside from editor issues. It's just that the editor issues made it so that instead of just not liking the idea, I now absolutely hate it. - Jonathan M Davis As I commented else-thread, I don't like indentation-sensitive languages either. Regarding the editor issue, I too prefer vim in the text-editor category but I consider it unfit for anything more than scripts and small C programs. For starters, the keyboard shortcuts are indeed highly optimized - for a right-handed person. Being a hard-core lefty, I truly hate the defaults on almost all software and going about changing those in vim is unintuitive and truly annoying. I prefer IDE's (e.g. Eclipse) code navigation features. For starters they don't have that horrible notion of ijkl for arrows which my fingers (on my right hand!) will never be able to learn, nor do I need to count words, lines, letters, etc to do useful stuff. So it all boils to that famous saying - YMMV.
Re: It seems pure ain't so pure after all
On Monday, 1 October 2012 at 08:00:47 UTC, Jakob Ovrum wrote: The only real problem here is that you wrote a function called pow2 that effectively returns 6 unconditionally. I doubt your math professor would be particularly impressed. If you had used __ctfe properly, it would return the same value both at compile-time and runtime. At present, __ctfe is a necessary evil as CTFE can be severely crippled without it. I solemnly swear not to use __ctfe improperly. But my problem with it is, that there *exists* the possibility of improper use of __ctfe. Plus, I just realized, I've never actually met any math professor. I never went to a university (nor study programming for that matter).
Re: It seems pure ain't so pure after all
On Monday, 1 October 2012 at 17:46:00 UTC, Tommi wrote: On Monday, 1 October 2012 at 08:04:49 UTC, Jonathan M Davis wrote: And you _can't_ determine ahead of time which functions can be safely executed at compile time either, because that's an instance of the halting problem. I don't understand (I did read what halting problem means just now, but I still don't understand). If there was no __ctfe variable, and thus a guarantee that all functions do the same thing at compile-time and run-time, couldn't the compiler just try aggressively to execute all function calls at compile-time? Obviously it wouldn't bother trying CTFE for function calls that had arguments which weren't evaluable at compile-time. Nor would it bother with functions that it knows have memory allocations or other limitations of CTFE. If not a compiler flag, then it could be a function attribute. Just like c++ function attribute constexpr, which guarantees that the function executes at compile time given you provide it with compile-time evaluable arguments (and there are limitations to what the function can do). Why wouldn't this attribute be possible with D? __ctfe is a horrible yet very useful hack to address the underlying issue - the execution model for CTFE, which I personally do not agree with. Adding a compiler flag for the existing model, makes no sense whatsoever. Functions are essentially a run-time abstraction and the compiler generally speaking has no business trying to execute them at compile-time. The compiler is after all *not* an interpreter. Besides, what would be the use case for such a flag anyway? If you already know that all parameters are known at compile-time, you can already tell the compiler to execute the function by assigning to a static/enum variable. IMO, this mixing of code for various stages of execution is bad design but this cannot be changed in a backwards compatible way.
Re: It seems pure ain't so pure after all
On Monday, 1 October 2012 at 06:09:18 UTC, Tommi wrote: Actually... let's not even worry about the definition of the word 'pure'. Let's just ask ourselves: do we really want to live in a world where people can write code like that: Yes, yes we do, because if we didn't there wouldn't be a _ctfe to make this possible.
Re: It seems pure ain't so pure after all
On Monday, 1 October 2012 at 17:53:35 UTC, Tommi wrote: On Monday, 1 October 2012 at 08:00:47 UTC, Jakob Ovrum wrote: The only real problem here is that you wrote a function called pow2 that effectively returns 6 unconditionally. I doubt your math professor would be particularly impressed. If you had used __ctfe properly, it would return the same value both at compile-time and runtime. At present, __ctfe is a necessary evil as CTFE can be severely crippled without it. I solemnly swear not to use __ctfe improperly. But my problem with it is, that there *exists* the possibility of improper use of __ctfe. Can you name a programming language that supports CTFE, but doesn't allow the possibility of misuse? Actually, can you name any language with a safety or purity feature that cannot be thwarted by a motivated programmer? To echo Jonathan's sentiment, no programming language can stop a programmer who is determined to write stupid code from doing so. For the sake of discussion, here's an example of a pure function in Haskell (arguably the purest language in wide use today) that happily returns a random integer every time it is called. import System.IO.Unsafe import System.Random pureFunction :: () - Int pureFunction x = unsafePerformIO impureInside where impureInside = getStdRandom (randomR (1,6)) main = do print (pureFunction ()) print (pureFunction ()) print (pureFunction ()) This prints three random integers between 1 and 6 when executed. -- Graham
Re: It seems pure ain't so pure after all
On Monday, October 01, 2012 19:46:16 Tommi wrote: On Monday, 1 October 2012 at 08:04:49 UTC, Jonathan M Davis wrote: And you _can't_ determine ahead of time which functions can be safely executed at compile time either, because that's an instance of the halting problem. I don't understand (I did read what halting problem means just now, but I still don't understand). If there was no __ctfe variable, and thus a guarantee that all functions do the same thing at compile-time and run-time, __ctfe exists purely so that you can provide an alternate implementation which works at compile time when the normal implementation doesn't (since CTFE _is_ more restrictive in what it allows than running a function at runtime is). couldn't the compiler just try aggressively to execute all function calls at compile-time? So, the compiler is supposed to run every function at compile time and then back up if it a function doesn't work? It can't even always know for sure when a function doesn't work (e.g. infinite loop). This would absolutely _tank_ compilation times. Most functions _can't_ be run at compile time simply because of how they're called, and the compiler can't necessarily know that unless it does full flow analysis if not outright _runs_ every function, which would be _incredibly_ expensive. If not a compiler flag, then it could be a function attribute. Just like c++ function attribute constexpr, which guarantees that the function executes at compile time given you provide it with compile-time evaluable arguments (and there are limitations to what the function can do). Why wouldn't this attribute be possible with D? CTFE was specifically designed with the idea that you would not need to mark functions as CTFEable. You can call _any_ function at compile time. Some will fail, because they're doing things that CTFE won't allow, but that's quickly caught, because it happens at compile time. It completely avoids needing to mark functions as CTFEable all over the place (which would generally mean that functions wouldn't be CTFEable, because people would frequently not mark them as CTFEable). constexpr is in direct conflict with that design goal. And if you want a function to be executed at compile time, you assign its result to an enum or static variable. Done. It's easy and straightforward. I really don't understand why this is an issue at all. - Jonathan M Davis
Re: It seems pure ain't so pure after all
On Monday, October 01, 2012 19:53:53 Tommi wrote: I solemnly swear not to use __ctfe improperly. But my problem with it is, that there *exists* the possibility of improper use of __ctfe. I could just as easily name a function pow2 and make it return the square root. I could overload operator + to do operator -. I could make it so that a function does one thing on Linux and does something completely different and unreleated on Windows. There are _tons_ of places in programming where the programmer has to not be an idiot or their fellow programmers are going to end up with tons of pain. __ctfe is no different from static if or version or any feature which makes it so that the block of code is different on different machines, and it's generally a whale of a lot less error-prone than stuff like endianness issues. It's even trivial to use the same unit tests to test that your function does the same thing in CTFE as at runtime, which you can test on the same machine, unlike with architecture and OS differences. I really think that you're blowing this way out of proportion. Certainly, you think that there's a problem here when the rest of us don't. - Jonathan M Davis
Re: Idea: Introduce zero-terminated string specifier
On 10/1/12, Piotr Szturmaj bncr...@jadamspam.pl wrote: For example C binding writers may change: extern(C) char* getstr(); to extern(C) cstring getstr(); I don't think you can reliably do that because of semantics w.r.t. passing parameters on the stack vs in registers based on whether a type is a pointer or not. I've had this sort of bug when wrapping C++ where the C++ compiler was passing a parameter in one way but the D compiler expected the parameters to be passed, simply because I tried to be clever and fake a return type. See: http://forum.dlang.org/thread/mailman.1547.1346632732.31962.d@puremagic.com#post-mailman.1557.1346690320.31962.d.gnu:40puremagic.com
Re: Idea: Introduce zero-terminated string specifier
On 10/1/12, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: but the D compiler expected the parameters to be passed missing in another way there.
Re: RFC: DConf 2013
On Monday, 1 October 2012 at 16:25:12 UTC, Andrei Alexandrescu wrote: The project is not live, it will be within a few days. In the spirit of having the community actively participate, I'm making this as transparent as it gets. Please comment: http://www.kickstarter.com/projects/dlang/1177501541?token=df96761a Your feedback and suggestions are welcome. Thanks, Andrei Nice, I like the raise money first approach. Make it possible for those unable to attend to contribute to its success. I don't see myself being able to make it, but I'll have to keep it in mind. I was going to write up a suggestion, but instead I'm going to write why I see the suggestion bad. I was going to suggest an unlimited tier for the expected ticket price. But that doesn't make sense as there will need to be a limit on attendees.
__ctfe
On Mon, Oct 1, 2012 at 8:36 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: [Creating a new thread for this] __ctfe exists purely so that you can provide an alternate implementation which works at compile time when the normal implementation doesn't (since CTFE _is_ more restrictive in what it allows than running a function at runtime is). Something I wanted to ask for a long time: is there any runtime speed penalty in using __ctfe? I have functions that are OK at runtime and do not work at compile-time. If I find a way to make them work at CT and use __ctfe to distinguish the two branches, will runtime execution become slower?
std.lexer?
Jonathan M. Davis worked on a D lexer this summer, that seemed almost ready in August. Not pushing JMD, but: any news on this front?
Re: __ctfe
On Monday, 1 October 2012 at 19:22:37 UTC, Philippe Sigaud wrote:
Something I wanted to ask for a long time: is there any runtime
speed penalty in using __ctfe?
No. What happens is when it goes to the compile the runtime code,
__ctfe is a constant false, so then the optimizer can see it is
obviously dead code and eliminate the branch entirely. You don't
even have to use the -O switch to get this:
void test() {
if(__ctfe) {
asm { nop; nop; nop; nop; }
} else {
asm { hlt; }
}
}
$ dmd test.d -c
$ objdump --disassemble test.o
Disassembly of section .text._D4test4testFZv:
_D4test4testFZv:
0: 55 push %ebp
1: 8b ec mov%esp,%ebp
3: f4 hlt
4: 5d pop%ebp
5: c3 ret
Note that there's no trace of a compare, jmp, nor the nops from
the dead ctfe branch.
Re: Getting started with D - Phobos documentation sucks
On Saturday, 29 September 2012 at 15:29:46 UTC, Mr. Anonymous wrote: Hi guys. I was browsing the book Programming in D by Ali Çehreli. It was pretty much clear, and then I stumbled upon this on page 89: 20.9 Exercises 1. Browse the documentations of the std.string, std.array, std.algorithm, and std.range modules. OK, let's open the D website and browse the documentation of std.string: http://dlang.org/phobos/std_string.html What do we see? A bunch of links that look like SEO tags of a spam website, followed by a mess of anything - structs, classes, functions, and what not. Do you really think somebody who learns programming can understand anything here? Compare this with, e.g., an msdn reference: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684852(v=vs.85).aspx A clear division of enums, functions, macros, structs, ... http://msdn.microsoft.com/en-us/library/windows/desktop/ms684847(v=vs.85).aspx The functions are divided by usage, with a short explanation next to each function. I think documentation is really important, and something has to be done about it. How can a newcomer get started with D when he doesn't have a readable documentation of Phobos? OK, I looked at it, and I saw that the links are generated by javascript. So I decided to try and write a better javascript function for creating links. Here's what I came up with: The JS code: http://pastebin.com/Pz4fb4JR Screenshots: http://i.imgur.com/gwxrI.png, http://i.imgur.com/qGGQn.png As you can see, the code works for both the website html and the one bundled with dmd. If my function finds nothing, it falls back to it's old version of anchor list. This solution is quite bad and temporary, but what we have now is not much better, so, for a while, I think it's worth using. P.S. I saw in the comments that Adam D. Ruppe came up with a better solution, but it requires an external tool. My solution requires a small javascript change, which should be very easy to integrate.
Re: Getting started with D - Phobos documentation sucks
Mr. Anonymous wrote: OK, I looked at it, and I saw that the links are generated by javascript. So I decided to try and write a better javascript function for creating links. Here's what I came up with: The JS code: http://pastebin.com/Pz4fb4JR Screenshots: http://i.imgur.com/gwxrI.png, http://i.imgur.com/qGGQn.png As you can see, the code works for both the website html and the one bundled with dmd. If my function finds nothing, it falls back to it's old version of anchor list. This solution is quite bad and temporary, but what we have now is not much better, so, for a while, I think it's worth using. I've also tried to improve it: http://forum.dlang.org/thread/jb0ril$17oa$1...@digitalmars.com But I think that top positioned index is bad. It should be on the left, or the right pane.
Re: __ctfe
On Mon, Oct 1, 2012 at 9:30 PM, Adam D. Ruppe destructiona...@gmail.com wrote: On Monday, 1 October 2012 at 19:22:37 UTC, Philippe Sigaud wrote: Something I wanted to ask for a long time: is there any runtime speed penalty in using __ctfe? No. What happens is when it goes to the compile the runtime code, __ctfe is a constant false, so then the optimizer can see it is obviously dead code and eliminate the branch entirely. Cool.I feared it was a runtime-determined value, somehow. $ dmd test.d -c $ objdump --disassemble test.o Disassembly of section .text._D4test4testFZv: _D4test4testFZv: 0: 55 push %ebp 1: 8b ec mov%esp,%ebp 3: f4 hlt 4: 5d pop%ebp 5: c3 ret Note that there's no trace of a compare, jmp, nor the nops from the dead ctfe branch. OK, I'm sold. Thanks!
Re: Getting started with D - Phobos documentation sucks
On Monday, 1 October 2012 at 19:39:35 UTC, Piotr Szturmaj wrote: Mr. Anonymous wrote: OK, I looked at it, and I saw that the links are generated by javascript. So I decided to try and write a better javascript function for creating links. Here's what I came up with: The JS code: http://pastebin.com/Pz4fb4JR Screenshots: http://i.imgur.com/gwxrI.png, http://i.imgur.com/qGGQn.png As you can see, the code works for both the website html and the one bundled with dmd. If my function finds nothing, it falls back to it's old version of anchor list. This solution is quite bad and temporary, but what we have now is not much better, so, for a while, I think it's worth using. I've also tried to improve it: http://forum.dlang.org/thread/jb0ril$17oa$1...@digitalmars.com But I think that top positioned index is bad. It should be on the left, or the right pane. Why hasn't it been integrated? I guess the reason is that everybody says that's not a solution, we have to fix x and y, but nobody actually fixes that stuff, and the reality is that we're left with an unusable list of anchored SEO-spam links for years. That's why I did the change as simple as possible - it should take no more than a minute to replace the function. P.S. can somebody create a pull request for this at github? I'm not familiar with this stuff.
Re: It seems pure ain't so pure after all
On Monday, 1 October 2012 at 18:36:23 UTC, Jonathan M Davis wrote: CTFE was specifically designed with the idea that you would not need to mark functions as CTFEable. You can call _any_ functio at compile time. Some will fail, because they're doing things that CTFE won't allow, but that's quickly caught, because it happens at compile time. It completely avoids needing to mark functions as CTFEable all over the place (which would generally mean that functions wouldn't be CTFEable, because people would frequently not mark them as CTFEable). constexpr is in direct conflict with that design goal. That's not what I suggested. I meant that all functions would still be implicitly CTFEable by default, but an attribute like force_ctfe would make it so that the function is guaranteed to execute at compile-time when its arguments are compile-time constants. And if you want a function to be executed at compile time, you assign its result to an enum or static variable. Done. It's easy and straightforward. I really don't understand why this is an issue at all. The issue to me is complicating the syntax of your code. The problem is *having* to assign the result first to an enum, when I shouldn't have to. I would like to be able to just say fun(times) and be confident that that's going to be evaluated at compile-time. I feel like I've done my part of the deal here, I provided the compile-time argument, and now I'd expect the compiler to do his part and evaluate the function at compile-time (if it has that force_ctfe attribute).
Re: It seems pure ain't so pure after all
On Mon, 01 Oct 2012 16:10:48 -0400, Tommi tommitiss...@hotmail.com wrote:
On Monday, 1 October 2012 at 18:36:23 UTC, Jonathan M Davis wrote:
CTFE was specifically designed with the idea that you would not need to
mark functions as CTFEable. You can call _any_ functio
at compile time. Some will fail, because they're doing things that CTFE
won't allow, but that's quickly caught, because it happens at compile
time. It completely avoids needing to mark
functions as CTFEable all over the place (which would generally
mean that functions wouldn't be CTFEable, because people would
frequently not mark them as CTFEable). constexpr is in direct
conflict with that design goal.
That's not what I suggested. I meant that all functions would still be
implicitly CTFEable by default, but an attribute like force_ctfe would
make it so that the function is guaranteed to execute at compile-time
when its arguments are compile-time constants.
And if you want a function to be executed at compile time, you assign
its result to an enum or static variable. Done. It's easy
and straightforward. I really don't understand why this is an
issue at all.
The issue to me is complicating the syntax of your code. The problem is
*having* to assign the result first to an enum, when I shouldn't have
to. I would like to be able to just say fun(times) and be confident
that that's going to be evaluated at compile-time. I feel like I've done
my part of the deal here, I provided the compile-time argument, and now
I'd expect the compiler to do his part and evaluate the function at
compile-time (if it has that force_ctfe attribute).
We already have that, use templates:
private auto _funimpl(string s) {
/* what was previously in fun(string) */
}
template fun(string s)
{
enum fun = _funimpl(s);
}
// usage:
fun!(times); // always executes _funimpl at compile time
-Steve
Re: It seems pure ain't so pure after all
On Monday, 1 October 2012 at 20:16:09 UTC, Steven Schveighoffer
wrote:
We already have that, use templates:
private auto _funimpl(string s) {
/* what was previously in fun(string) */
}
template fun(string s)
{
enum fun = _funimpl(s);
}
// usage:
fun!(times); // always executes _funimpl at compile time
Yes, I know. And this helps even more:
template ct(alias expr)
{
enum ct = expr;
}
auto fun(string s)
{
...
}
// usage:
ct!(fun(times))
But that's still a nuisance.
