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: 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 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: 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, 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-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: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: 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 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, 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 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, 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, 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 01-10-2012 07:40, Tommi 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();
}
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.
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
It seems pure ain't so pure after all
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();
}
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 20:24:17 UTC, Andrei Alexandrescu wrote: It would be great if we had some more finalized things. 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. And after I switch focus to something else, I often don't come back to the other thing for quite a long time. It is pushed down to the bottom of an ever growing list. So if it isn't finished in just a few days, it means I probably won't finish it for at least many months, and there's not a great deal I can do about that in the short term, at least not without spending 14 hours a day every day doing nothing but code, and blargh.
Re: dynamic library building and loading
On Sunday, 30 September 2012 at 10:57:24 UTC, Jacob Carlborg wrote: On 2012-09-30 08:41, Rob T wrote: I think most of us know that we need to support all types of libraries. Static and dynamic, both for link time and runtime. OK we're all in agreement on this point. You can have a look at the work done by Martin Nowak: https://github.com/dawgfoto/druntime/commits/SharedRuntime 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 ...? I've only recently been learning what's going on with D and why it is what it is, so a breif history lesson may be needed once in a while. You can replace the GC at link time. Here's an example of a stubbed implemented of the GC: http://dsource.org/projects/tango/browser/trunk/tango/core/rt/gc/stub I will look at this too. Thanks for the pointers. --rt
Re: Dangling if
monarch_dodra wrote:
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.
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.
Re: Idea: Introduce zero-terminated string specifier
On Sunday, 30 September 2012 at 19:58:16 UTC, Vladimir Panteleev wrote: 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. I aggere you... href="http://www.tercumesirketi.com/";>Tercüme || href="http://www.tercumesirketi.com/";>Tercüme Büroları
Re: Idea: Introduce zero-terminated string specifier
On 9/30/12, 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. > 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.
Re: Getting started with D - Phobos documentation sucks
On 9/30/12 11:53 AM, Adam D. Ruppe wrote: On Sunday, 30 September 2012 at 15:41:46 UTC, Adam D. Ruppe wrote: If you want to write the code, feel free. I'm sorry, this probably came across as rude, but the answer for why not do it the right way is simply that the right way takes time and I don't feel like putting it in. Apparently not very many other people do either, since we've had the status quo for a long time now. A quick helper app can be slapped together in a fraction of the time of a more proper fix. I don't think the comeback was rude because many great improvements to D came exactly this way - pull requests followed through by talented and interested contributors. On the other hand, if I were to criticize anything, Adam has a lot of great work brought to the proof-of-concept stage but not finalized. It would be great if we had some more finalized things. Andrei
Re: Idea: Introduce zero-terminated string specifier
On Sunday, 30 September 2012 at 18:58:11 UTC, Paulo Pinto wrote: +1 We don't need to preserve C's design errors regarding strings and vectors. The problem is that, unsurprisingly, most C APIs (not just libc, but also most C libraries and OS APIs) use zero-terminated strings. The philosophy of ignoring the existence of C strings throughout all of D makes working with such APIs needlessly verbose (and sometimes annoying, as D code will compile and produce unexpected results).
Re: Idea: Introduce zero-terminated string specifier
On Saturday, 29 September 2012 at 02:07:38 UTC, Andrej Mitrovic wrote: I've noticed I'm having to do a lot of to!string calls when I want to call the versatile writef() function. So I was thinking, why not introduce a special zero-terminated string specifier which would both alleviate the need to call to!string and would probably save on needless memory allocation. If all we want to do is print something, why waste time duplicating a string? I just checked and std.conv.to always allocates a copy, even when constness doesn't require it. It should not reallocate when constness doesn't change, or is a safe conversion (e.g. immutable -> const). A discussion on a related topic (formatting of C strings results in unexpected behavior) is here: http://d.puremagic.com/issues/show_bug.cgi?id=8384
Re: Idea: Introduce zero-terminated string specifier
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.
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 17:27:43 UTC, Jacob Carlborg wrote: I would like to fix it but I think the DMD code base is quite horrible and just a big mess. 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. 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.
Re: Idea: Introduce zero-terminated string specifier
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. +1 We don't need to preserve C's design errors regarding strings and vectors. -- Paulo
Re: Idea: Introduce zero-terminated string specifier
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.
Re: Getting started with D - Phobos documentation sucks
On 2012-09-30 17:53, Adam D. Ruppe wrote: On Sunday, 30 September 2012 at 15:41:46 UTC, Adam D. Ruppe wrote: If you want to write the code, feel free. I'm sorry, this probably came across as rude, but the answer for why not do it the right way is simply that the right way takes time and I don't feel like putting it in. Apparently not very many other people do either, since we've had the status quo for a long time now. A quick helper app can be slapped together in a fraction of the time of a more proper fix. Yeah I know. I would like to fix it but I think the DMD code base is quite horrible and just a big mess. I've tried several times to fix small bugs or tried to do some other modifications. But every time I fail because I have no idea what I'm doing and the DMD code base is far from easy to work. -- /Jacob Carlborg
Re: Getting started with D - Phobos documentation sucks
On 2012-09-30 17:37, Adam D. Ruppe wrote: On Sunday, 30 September 2012 at 15:31:30 UTC, Jacob Carlborg wrote: And we're back at the fact that we need a compiler library. Not necessarily... the ddoc comments are available in the compiler's json output (use -X and -D together in dmd). It doesn't do syntax highlighting and could offer a lot more info than it does now... but it does give enough to approximate your own ddoc. I'm using the json output for dpldocs.info version two: http://dpldocs.info/search/search?searchTerm=std.regex If think the whole idea of the JSON output is a workaround for not having the compiler available as a library. -- /Jacob Carlborg
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 15:41:46 UTC, Adam D. Ruppe wrote: If you want to write the code, feel free. I'm sorry, this probably came across as rude, but the answer for why not do it the right way is simply that the right way takes time and I don't feel like putting it in. Apparently not very many other people do either, since we've had the status quo for a long time now. A quick helper app can be slapped together in a fraction of the time of a more proper fix.
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 15:36:50 UTC, Jacob Carlborg wrote: What's wrong with "hey, lets fix this the right way for a change". If you want to write the code, feel free.
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 15:31:30 UTC, Jacob Carlborg wrote: And we're back at the fact that we need a compiler library. Not necessarily... the ddoc comments are available in the compiler's json output (use -X and -D together in dmd). It doesn't do syntax highlighting and could offer a lot more info than it does now... but it does give enough to approximate your own ddoc. I'm using the json output for dpldocs.info version two: http://dpldocs.info/search/search?searchTerm=std.regex
Re: Getting started with D - Phobos documentation sucks
On 2012-09-30 15:49, Adam D. Ruppe wrote: Eh, maybe. I just find doing fancier things inside the compiler to be a pain in the butt. Basically D > C++. And it is harder to get code into dmd than it is to just do your own thing. But really what matters is that we get something that doesn't suck results wise. We could always change the ddoc implementation later. That might be true but it's this kind of attitude that makes the source code a big mess and software suck. It's always "we fix this later", well "later" is never going to happen. It's always patch on workaround on fix on patch, and so on. What's wrong with "hey, lets fix this the right way for a change". -- /Jacob Carlborg
Re: Getting started with D - Phobos documentation sucks
On 2012-09-30 17:00, foobar wrote: Which is why the doc generation utility should be a separate tool and not built directly into the compiler. I understand Walter's desire to have batteries included with D (doc generation, unit-testing, profiling, ...) but that does not mean they should be welded in. The DMD distribution could just as well provide a set of auxiliary _standalone_ utilities for that. And we're back at the fact that we need a compiler library. -- /Jacob Carlborg
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 13:48:41 UTC, Adam D. Ruppe wrote: On Sunday, 30 September 2012 at 11:01:50 UTC, Jacob Carlborg wrote: 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. Eh, maybe. I just find doing fancier things inside the compiler to be a pain in the butt. Basically D > C++. And it is harder to get code into dmd than it is to just do your own thing. But really what matters is that we get something that doesn't suck results wise. We could always change the ddoc implementation later. Which is why the doc generation utility should be a separate tool and not built directly into the compiler. I understand Walter's desire to have batteries included with D (doc generation, unit-testing, profiling, ...) but that does not mean they should be welded in. The DMD distribution could just as well provide a set of auxiliary _standalone_ utilities for that. DMD already has JSON output. Can't that be standardized and used with a separate ddoc utility written in D?
Re: Rust and D
On 28-09-2012 19:42, Froglegs wrote: The Rust website says this: Generic typesyes, only simple, non-turing-complete substitution After seeing that I just assumed the language was worthless and ignored it.. is there something more to this? Let me just clarify to everyone that Rust *does* have macros, which is certainly better than nothing at all: https://github.com/mozilla/rust/blob/master/doc/tutorial-macros.md -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 11:01:50 UTC, Jacob Carlborg wrote: 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. Eh, maybe. I just find doing fancier things inside the compiler to be a pain in the butt. Basically D > C++. And it is harder to get code into dmd than it is to just do your own thing. But really what matters is that we get something that doesn't suck results wise. We could always change the ddoc implementation later.
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 11:22:02 UTC, Jonathan M Davis wrote: The main problem IMHO is how the links are generated, making it impossible to have links to symbols with the same name in the same module Yeah, I did a pull request to dmd to add a new macro to fix this, but I also included a change to the escaping rules and the powers that be weren't convinced of them (though they should be, ddoc is virtually unusable for documenting html and also for outputting other document formats without it or something like it). Anyway though I need to separate out my ddoc fixes into individual pull requests and I haven't gotten around to it yet. Maybe I'll try to fit it in today. After we allow a DDOC_PSYMBOL macro, we update std.ddoc to use it for the anchors and then we're set. Though, it still doesn't account for overloaded functions... but meh it's a *lot* better than we have now.
Re: Getting started with D - Phobos documentation sucks
On Sunday, 30 September 2012 at 10:08:17 UTC, Dmitry Olshansky wrote: I'll give it a whirl. cool. BTW search the code for the word "HACK". There's one that rewrites css links to be absolute and one that adds some inline style. Those are there so I can test it from a different domain that doesn't have the whole website available. Probably safe to leave them there, but surely cleaner to comment that out before committing to the real thing.
Re: Getting started with D - Phobos documentation sucks
While we're speaking about docs improvement, I believe there is one more thing that could use a fix - clickable identifiers. I don't know how much of an effort it would require, so consider it a wishlist, but for stuff like: static @property @safe TickDuration currAppTick(); TickDuration should be a clickable link leading to core.time.TickDuration class docs. Example: http://docs.oracle.com/javase/1.4.2/docs/api/javax/swing/Icon.html#paintIcon(java.awt.Component, java.awt.Graphics, int, int) notice how Component and Graphics are clickable so you can instantly jump to their relevant declarations. This feature along with the abovementioned improvements would probably make the documentation a useful and intuitive tool.
Re: Getting started with D - Phobos documentation sucks
On Sunday, September 30, 2012 13:02:15 Jacob Carlborg 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. That's what I've always thought. The main problem IMHO is how the links are generated, making it impossible to have links to symbols with the same name in the same module even if they're in different scopes (e.g. a free function and one in a class). And that's definitely not the sort of thing that an external tool should be fixing. - Jonathan M Davis
Re: Getting started with D - Phobos documentation sucks
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. -- /Jacob Carlborg
Re: dynamic library building and loading
On 2012-09-30 08:41, Rob T wrote: There are plenty of cases where you have to use a dynamically loaded lib even if you know before hand what will be loaded. I think you understand this if I read your posts correctly. In my case I have a pre-existing C++ app that is designed to load user defined C++ plugins. I wanted to interface D to one of my own C++ plugins, but I apparently cannot do it reliably because of initialization issues with the GC and possibly some other obscure items. But now we're back at plugins. I think this part of the discussion is starting to run in circles and become quite pointless. I think most of us know that we need to support all types of libraries. Static and dynamic, both for link time and runtime. If I can figure out what needs to be done to resolve the problem in enough detail, then maybe I can hack the runtime source and roll out a solution. You can have a look at the work done by Martin Nowak: https://github.com/dawgfoto/druntime/commits/SharedRuntime He has a couple of other useful branches as well, for example: https://github.com/dawgfoto/druntime/commits/dmain2Refactoring On Mac OS X there's also the problem with TLS. There is no native support for TLS in Mac OS X prior to Lion (10.7). DMD has rolled its own implementation that needs to be adapted to support dynamic libraries. The GC always seems to pop up as a source of problems. For long term solution, the GC should be made 100% optional (in practice as opposed to in theory), the standard library ought to be made to work with or wothout a GC (or simply without), and the GC itself should be easily replaceable with alternate versions. I think this idea has already been discussed elsewhere, and is on the TODO list (I hope!). You can replace the GC at link time. Here's an example of a stubbed implemented of the GC: http://dsource.org/projects/tango/browser/trunk/tango/core/rt/gc/stub This is for Tango but the druntime is based on the Tango runtime so I would guess most of this would be the same. -- /Jacob Carlborg
Re: Getting started with D - Phobos documentation sucks
On 30-Sep-12 06: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. Program here: http://arsdnet.net/d-web-site/improveddoc.d libs needed https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff dom.d and characterencodings.d When I tried this earlier, I couldn't even get the basic website to build on my box from github. I think it needs github phobos too but meh, I moved on to something else and never got back to it. But if the website makefile built and ran that program across the html it generates, it should be set. I'll give it a whirl. The current auto generated _index_ at the top is intolerable. It won't surprise me if this alone has attributed to having say 20% less newcomers. Not to mention some cool functions that just got lost in this noise :) -- Dmitry Olshansky
Re: Dangling if
On Sunday, September 30, 2012 11:42:40 monarch_dodra wrote: > Personally, EVEN when I'm doing a 1 line if, I *still* wrap it in > a block. EG: To each their own. Personally, it drives me nuts to have braces when they're completely unnecessary. I use braces only when the condition or body is more than one line long. And I don't think that I've _ever_ run into a dangling else problem (if nothing else, because I'd always use braces in cases where it could happen). But everyone seems to run into different problems. > Further more, thanks to D's ban on "if();", you can litterally > never fail with this format. That is definitely one of D's better design choices. - Jonathan M Davis
Re: Dangling if
On Friday, 28 September 2012 at 17:40:17 UTC, Andrej Mitrovic
wrote:
On 9/28/12, Bernard Helyer 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.
Re: dynamic library building and loading
On Friday, 28 September 2012 at 21:26:47 UTC, Iain Buclaw wrote: The way I intend to address it is to have each module handle it's own gshared/thread data and pass the information to the D runtime during the module construction stage (.ctor) - there is already something done this way for _Dmodule_ref - so it may end up being that two new fields will be tacked onto it; void[] tlsdata, void[] gsharedata; I re-built libgphobos and libgdruntime with -fPIC and I can now successfully create dynamically loaded D libs. I have successfully linked a dynamic D lib to a C++ app, executing some test code successfully. I have not yet tried to dlopen a dynamic D lib from C++, but I will try maybe tomorrow. My simple dynamic lib test seems to run fine, but I understand that there may be problems, such as the GC failing to work properly, and perhaps more can/will go wrong as per Jacob's post http://forum.dlang.org/post/k4219f$uft$1...@digitalmars.com Any idea when/if you will get around to implementing a fix? Wish I could help but I've only just started looking at the source code, so whatever I try to fix will probably cause more harm than good for a while (but it's a start). --rt
