date:20120307

On Thu, Mar 08, 2012 at 06:37:13AM +0100, Martin Nowak wrote:
> On Thu, 08 Mar 2012 06:12:20 +0100, H. S. Teoh
>  wrote:
> 
> >I'm playing around with writing an AA implementation that doesn't
> >require typeinfos to work, using aaA.d as reference. One thing I
> >don't quite understand: what's binit used for, and why is it
> >necessary? It seems redundant to me, since D always initializes
> >pointer arrays to nulls (right?).
> >
> It's used to avoid extra allocations when only very few buckets are
> needed.

Ah, that makes sense. Thanks!


T

-- 
It's bad luck to be superstitious. -- YHL

Re: Arbitrary abbreviations in phobos considered ridiculous

On Thursday, March 08, 2012 00:52:57 Nick Sabalausky wrote:
> "Ary Manzana"  wrote in message
> news:jj94mb$1i7v$1...@digitalmars.com...
> 
> > Here's something I wrote today:
> > 
> > parent_ids = results.map{|x|
> > x['_source']['parent_ids']}.flatten.uniq.compact
> > Hash[Site.find(parent_ids).map{|x| [x.id, x]}]
> 
> When you format it like that (that is to say, when you *don't* format it),
> yea, it's unreadable. Which is why I do such things like this:
> 
> parent_ids =
> results
> .map{|x| x['_source']['parent_ids']}
> .flatten.uniq
> .compactHash[
> Site.find(parent_ids).map{|x| [x.id, x]}
> ]

I actually tend to find code like that hard to read, because all of the 
operations are inside out in comparison to normal. But since the only 
difference between his example and yours is the formatting, I agree yours is 
easier to read. Still, I'd much prefer if such code didn't use UFCS, since I 
find it much harder to read that way. It's just so backwards.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

"Ary Manzana"  wrote in message 
news:jj94mb$1i7v$1...@digitalmars.com...
>
> Here's something I wrote today:
>
> parent_ids = results.map{|x| 
> x['_source']['parent_ids']}.flatten.uniq.compact
> Hash[Site.find(parent_ids).map{|x| [x.id, x]}]
>

When you format it like that (that is to say, when you *don't* format it), 
yea, it's unreadable. Which is why I do such things like this:

parent_ids =
results
.map{|x| x['_source']['parent_ids']}
.flatten.uniq
.compactHash[
Site.find(parent_ids).map{|x| [x.id, x]}
]

Re: dereferencing null


On 03/07/2012 11:17 PM, Jonathan M Davis wrote:

On Wednesday, March 07, 2012 22:58:44 Chad J wrote:

On 03/07/2012 10:40 PM, Jonathan M Davis wrote:

On Wednesday, March 07, 2012 22:36:50 Chad J wrote:

On 03/07/2012 10:08 PM, Jonathan M Davis wrote:

On Wednesday, March 07, 2012 20:44:59 Chad J wrote:

On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:

You can use sentinels other than null.

-Steve


Example?


Create an instance of the class which is immutable and represents an
invalid value. You could check whether something is that value with the
is operator, since there's only one of it. You could even make it a
derived class and have all of its functions throw a particular exception
if someone tries to call them.

- Jonathan M Davis


Makes sense.  Awfully labor-intensive though.  Doesn't work well on

classes that can't be easily altered.  That is, it violates this:

- Do not modify the implementation of UnreliableResource.  It's not
always
possible.


But, maybe it can be turned it into a template and made to work for
arrays too...


Personally, I'd probably just use null. But if you want a sentinel other
than null, it's quite feasible.

- Jonathan M Davis


Wait, so you'd use null and then have the program unconditionally crash
whenever you (inevitably) mess up sentinel logic?


Yes. Proper testing will find most such problems. And it's not like having a
non-null sentinel is going to prevent you from having problems. It just means
that you're not distinguishing between a variable that you forgot to
initialize and one which you set to the sentinel value. Your program can die
from a variable being null in either case. And in _both_ cases, it's generally
unsafe to continue executing your program anyway.



The important difference in using explicit sentinel values here is that 
they are not null, and thus very unlikely to have been caused by memory 
corruption.  It allows us to distinguish between the two sources of 
empty variables.


With a better way to do sentinel values, I can isolate my cleaner 
looking code from the scarier looking code that comes from any number of 
places.


I also am not too worried about null values that come from stuff that 
was simply forgotten, instead of intentionally nulled.  I DO tend to 
catch those really early in testing, and they are unlikely to happen to 
begin with due to the close association between declaration and 
initialization.



And honestly, in my experience, null pointers are a very rare thing. You catch
them through solid testing.

- Jonathan M Davis



Sorry, your testing doesn't help me as well as you probably wish it 
does.  Our experiences must be very different.  I run into a lot of 
cases where things can't be tested automatically, or at least not 
easily.  Think along the lines of graphics operations, interactively 
driven code (ex: event lifetimes), network code, etc.  Testing can help 
things between endpoints, but it doesn't help much where the rubber 
meets the road.


And that's just game dev.  Then I go to work at my job, the one that 
makes money, and experience code from the 80s.  Rewriting it is 
completely impractical for near-term projects (though a complete 
phase-out of crufty old crap is on the horizon one way or another!). 
Yes it has bugs.  If I had an attitude of "crash on every little nit" 
then these things wouldn't last a few seconds (OK, exaggeration).  So I 
recover as well as possible, and occasionally rewrite strategically 
important pieces.  But the world is NOT perfect, so relying on it being 
perfect is %100 unhelpful to me.  Also, "quit your job" is not an 
acceptable solution. ;)  Now, in principle, we will never have to deal 
with D code like that.  Nonetheless, these experiences do make me 
severely afraid of lacking the tools that keep me safe.


And then there are still those occasional weird problems where sentinel 
values are needed, and its so stateful that there's a vanishingly 
close-to-zero chance that testing will catch the stuff that it needs to.
So I test it as well as I can and leave a "if all else fails, DO THIS" 
next to the dubious code.  Indiscriminate segfaulting deprives me of 
this last-ditch option.  There is no longer even a way to crash 
elegantly.  It all just goes to hell.


Long story short: in practice, I find that recovering from sentinel 
dereference is not only VERY safe, but also orders of magnitude less 
frustrating for both my users and me.


(Memory corruption, on the other hand, is something I am very unfamiliar 
with, and sort of afraid of.  So I'm willing to ditch nulls.)

Re: AA implementation question

2012-03-07 Thread Martin Nowak

On Thu, 08 Mar 2012 06:12:20 +0100, H. S. Teoh   
wrote:



I'm playing around with writing an AA implementation that doesn't
require typeinfos to work, using aaA.d as reference. One thing I don't
quite understand: what's binit used for, and why is it necessary? It
seems redundant to me, since D always initializes pointer arrays to
nulls (right?).


It's used to avoid extra allocations when only very few buckets are needed.

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-07 Thread Sean Cavanaugh


On 3/7/2012 8:20 PM, Kapps wrote:

On Wednesday, 7 March 2012 at 19:12:25 UTC, H. S. Teoh wrote:

Supporting stuff like 5.hours will introduce additional complications to
D's lexical structure, though. The lexer will have to understand it as
(int:5)(.)(ident:hours) rather than (float:5.)(ident:hours). And then if
you actually *wanted* a float, you'd have another ambiguity: 5..hours
could mean (float:5.)(.)(ident:hours) or (int:5)(..)(hours). And
5.0.hours just looks... weird.


T


Actually, Kenji's pull request for UFCS already takes care of this.
Things like 5. aren't allowed, nor is 5.f; a number has to follow the
decimal. So 5.f would invoke UFCS function f with the integer 5. I
believe this change is already merged, though the rest of the UFCS pull
request isn't unfortunately.


I can definitely confirm that porting C/C++ floating point literals to D 
is a huge pain in the ass because of this change, so its definitely in 
to the degree it breaks my math and physics libs heavily :)

AA implementation question

I'm playing around with writing an AA implementation that doesn't
require typeinfos to work, using aaA.d as reference. One thing I don't
quite understand: what's binit used for, and why is it necessary? It
seems redundant to me, since D always initializes pointer arrays to
nulls (right?).


T

-- 
There are three kinds of people in the world: those who can count, and those 
who can't.

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-07 Thread Mike Parker


On 3/8/2012 4:27 AM, Jonathan M Davis wrote:

On Wednesday, March 07, 2012 08:47:48 Steven Schveighoffer wrote:

On Tue, 06 Mar 2012 12:09:47 -0500, Andrej Mitrovic

  wrote:

I'll never forgive std.datetime for this mistake:

auto sw = StopWatch(AutoStart.yes);
writeln(sw.peek.hnsecs);
writeln(sw.peek.nsecs);
writeln(sw.peek.usecs);
writeln(sw.peek.msecs);
writeln(sw.peek.secs); // bz NOPE
writeln(sw.peek.seconds);

I misspell this thing every single time I use stopwatch to count seconds.


this is a no-brainer:

Duration dur(string units)(long length) @safe pure nothrow
if(units == "weeks" ||
units == "days" ||
units == "hours" ||
units == "minutes" ||
units == "seconds" ||
units == "secs" || // added
units == "msecs" ||
units == "usecs" ||
units == "hnsecs" ||
units == "nsecs")
{
return Duration(convert!(units, "hnsecs")(length));
}

// etc, everywhere "seconds" is used, add "secs" as well.

I'll see if I can do a pull request.


I've avoided that primarily because it results in inconsistent code. It's
pretty much equivalent to adding extraneous aliases, though it's not as bad,
since it's not a general symbol. But if it's a sufficient usability improvement,
then maybe it's a good idea.



In this case, I think it very much is. I saw your explanation earlier 
that everything sub-second is abbreviated, but to me (and several 
others, obviously) that's just unintuitive. I see "msecs", "usecs", and 
so on and I naturally think "secs" rather than "seconds", most likely 
because it's a part of each abbreviation. Steve's solution is the right 
one, I think.

Re: dereferencing null

On Wednesday, March 07, 2012 22:58:44 Chad J wrote:
> On 03/07/2012 10:40 PM, Jonathan M Davis wrote:
> > On Wednesday, March 07, 2012 22:36:50 Chad J wrote:
> >> On 03/07/2012 10:08 PM, Jonathan M Davis wrote:
> >>> On Wednesday, March 07, 2012 20:44:59 Chad J wrote:
>  On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:
> > You can use sentinels other than null.
> > 
> > -Steve
>  
>  Example?
> >>> 
> >>> Create an instance of the class which is immutable and represents an
> >>> invalid value. You could check whether something is that value with the
> >>> is operator, since there's only one of it. You could even make it a
> >>> derived class and have all of its functions throw a particular exception
> >>> if someone tries to call them.
> >>> 
> >>> - Jonathan M Davis
> >> 
> >> Makes sense.  Awfully labor-intensive though.  Doesn't work well on
> >> 
> >> classes that can't be easily altered.  That is, it violates this:
> >>> - Do not modify the implementation of UnreliableResource.  It's not
> >>> always
> >>> possible.
> >> 
> >> But, maybe it can be turned it into a template and made to work for
> >> arrays too...
> > 
> > Personally, I'd probably just use null. But if you want a sentinel other
> > than null, it's quite feasible.
> > 
> > - Jonathan M Davis
> 
> Wait, so you'd use null and then have the program unconditionally crash
> whenever you (inevitably) mess up sentinel logic?

Yes. Proper testing will find most such problems. And it's not like having a 
non-null sentinel is going to prevent you from having problems. It just means 
that you're not distinguishing between a variable that you forgot to 
initialize and one which you set to the sentinel value. Your program can die 
from a variable being null in either case. And in _both_ cases, it's generally 
unsafe to continue executing your program anyway.

And honestly, in my experience, null pointers are a very rare thing. You catch 
them through solid testing.

- Jonathan M Davis

Re: Is it bad for object.di to depend on core.exception?

On Wed, Mar 07, 2012 at 08:06:55PM -0800, Sean Kelly wrote:
> On Mar 3, 2012, at 6:45 PM, H. S. Teoh wrote:
> 
> > So I'm still working on fixing issue 5030, which *should* have been a
> > trivial fix. But I'm running into a bunch of circumstantial problems,
> > among which is this new method in AssociativeArray(Key,Value):
> > 
> >Value opIndex(Key key, string file=__FILE__, size_t line=__LINE__)
> >{
> > auto p = key in *cast(Value[Key]*)(&p);
> > if (p) return *p;
> > throw new RangeError(file, line);
> >}
> > 
> > Originally it was simply Value opIndex(Key key) without any range check,
> > which is probably a bad idea, so I added the throw RangeError in there.
> > 
> > However, this introduces a dependency from object.di to core.exception.
> 
> Have the function above call something like:
> 
> Value opIndex(…) {
> …
> throw _d_newRangeError(file, line);
> }
> 
> Throwable _d_newRangeError(string, size_t); // defined in object_d (not .di).

Good idea, I'll do that. Thanks!


T

-- 
They pretend to pay us, and we pretend to work. -- Russian saying

Re: Is it bad for object.di to depend on core.exception?

2012-03-07 Thread Sean Kelly

On Mar 3, 2012, at 6:45 PM, H. S. Teoh wrote:

> So I'm still working on fixing issue 5030, which *should* have been a
> trivial fix. But I'm running into a bunch of circumstantial problems,
> among which is this new method in AssociativeArray(Key,Value):
> 
>Value opIndex(Key key, string file=__FILE__, size_t line=__LINE__)
>{
>   auto p = key in *cast(Value[Key]*)(&p);
>   if (p) return *p;
>   throw new RangeError(file, line);
>}
> 
> Originally it was simply Value opIndex(Key key) without any range check,
> which is probably a bad idea, so I added the throw RangeError in there.
> 
> However, this introduces a dependency from object.di to core.exception.

Have the function above call something like:

Value opIndex(…) {
…
throw _d_newRangeError(file, line);
}

Throwable _d_newRangeError(string, size_t); // defined in object_d (not .di).

Re: dereferencing null


On 03/07/2012 10:40 PM, Jonathan M Davis wrote:

On Wednesday, March 07, 2012 22:36:50 Chad J wrote:

On 03/07/2012 10:08 PM, Jonathan M Davis wrote:

On Wednesday, March 07, 2012 20:44:59 Chad J wrote:

On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:

You can use sentinels other than null.

-Steve


Example?


Create an instance of the class which is immutable and represents an
invalid value. You could check whether something is that value with the
is operator, since there's only one of it. You could even make it a
derived class and have all of its functions throw a particular exception
if someone tries to call them.

- Jonathan M Davis


Makes sense.  Awfully labor-intensive though.  Doesn't work well on

classes that can't be easily altered.  That is, it violates this:

- Do not modify the implementation of UnreliableResource.  It's not always
possible.

But, maybe it can be turned it into a template and made to work for
arrays too...


Personally, I'd probably just use null. But if you want a sentinel other than
null, it's quite feasible.

- Jonathan M Davis


Wait, so you'd use null and then have the program unconditionally crash 
whenever you (inevitably) mess up sentinel logic?

Re: Is it bad for object.di to depend on core.exception?

On Thu, Mar 08, 2012 at 12:37:20PM +1100, Daniel Murphy wrote:
> "H. S. Teoh"  wrote in message 
> news:mailman.176.1331147910.4860.digitalmar...@puremagic.com...
> > On Sun, Mar 04, 2012 at 07:31:49AM +0100, Martin Nowak wrote:
> >> Wasn't the latest proposal that we add a working AA implementation
> >> to the runtime and switch the compiler after that has settled?
> >
> > Is somebody working on that? If not, I may take a crack at doing it.
[...]
> I was the one that recently tried to get AAs rolled back to the D1
> implemenation (unsuccessfully) but I'm not working on a
> reimplementation.  The closed pull requests are sitting on github if
> you'd like to take a look at them.
> 
> For it to be 'fixed', AAs need to be able to do all the things they
> can do now, including producing error messages with V[K] instead of
> AssociativeArray!(K, V), magic initialization and the same reference
> semantics.  They also need to _work_ in ctfe, either because the
> implementation is available and ctfeable, or because the calls get
> translated late enough that the interpreter can pick out the
> IndexExps/DotIdExps and treat them specially.
> 
> At the moment I'm leaning towards doing the translations in the glue
> layer, and using ufcs for everything else, but whatever works.
> There's a thread on the internals mailing list that lists some of the
> issues with the current implementation. 
[...]

Hmm. If this is going to involve major changes in *both* druntime and
dmd, I may have bitten off a bit more than I can chew. :-/ I was going
on the original statement that we build a workable AA implementation in
object_.d first, then port the compiler over. Trying to do everything at
once seems like too big a project to pull off successfully in one shot.


T

-- 
Without geometry, life would be pointless. -- VS

Re: dereferencing null

On Wednesday, March 07, 2012 22:36:50 Chad J wrote:
> On 03/07/2012 10:08 PM, Jonathan M Davis wrote:
> > On Wednesday, March 07, 2012 20:44:59 Chad J wrote:
> >> On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:
> >>> You can use sentinels other than null.
> >>> 
> >>> -Steve
> >> 
> >> Example?
> > 
> > Create an instance of the class which is immutable and represents an
> > invalid value. You could check whether something is that value with the
> > is operator, since there's only one of it. You could even make it a
> > derived class and have all of its functions throw a particular exception
> > if someone tries to call them.
> > 
> > - Jonathan M Davis
> 
> Makes sense.  Awfully labor-intensive though.  Doesn't work well on
> 
> classes that can't be easily altered.  That is, it violates this:
> > - Do not modify the implementation of UnreliableResource.  It's not always
> > possible.
> But, maybe it can be turned it into a template and made to work for
> arrays too...

Personally, I'd probably just use null. But if you want a sentinel other than 
null, it's quite feasible.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

On Thursday, March 08, 2012 16:18:39 James Miller wrote:
> On 8 March 2012 15:56, Jonathan M Davis  wrote:
> > On Thursday, March 08, 2012 01:22:42 Stewart Gordon wrote:
> >> On 07/03/2012 08:10, Jacob Carlborg wrote:
> >> 
> >> 
> >> > Yeah, Clock.now() would be good and Data.today() as well.
> >> 
> >> My utility library has, for consistency, DateValue.now, TimeValue.now and
> >> DateTime.now.
> > 
> > I specically avoided giving a way to get the time with any type other than
> > SysTime (and TickDuration for using a monotonic clock), because I believe
> > that it leads to incorrect behavior. Any time that you're dealing with
> > the system clock, you should be dealing with SysTime. Date, TimeOfDay,
> > and DateTime are for when you need the date and/or time but don't care
> > about what absolute time it's associated with in the real world. Treating
> > DateTime as corresponding to a specific point in time is just going to
> > cause problems, because it has no time zone. It could correspond to over
> > 24 different times. By restricting getting the time to SysTime, it
> > encourages the writing of correct code.
> > 
> > - Jonathan M Davis
> 
> It tends to be better to go for proper timezoned code from the outset,
> a workmate just had to add timezone support to the entire app
> recently, took him about 2 weeks.

Definitely. The whole reason that I wrote std.datetime and that SysTime works 
the way that it does is because I've had to deal with enough time-related bugs 
at work that I was sick of it, and I wanted to make sure that D had a solution 
that did it right. And by maintaining its time in UTC internally and just 
adjusting the time to a particular time zone when required for output (e.g. 
getting the year of the SysTime or converting it to a string), a whole host of 
conversion errors are avoided (DST is _the_ largest mistake with regards to 
time in the history of computing IMHO).

Unfortunately, errors are still possible (e.g. sometimes you have to create a 
SysTime from a DateTime, and that can't be done without risking DST-related 
errors), but I believe that SysTime manages to reduce them about as much as is 
possible. So, in general, if you use SysTime, time should just be handled 
correctly without you having to worry about all of the details - like the time 
zone. But it also gives you the power to do more if you _do_ care about the 
details (e.g. selecting a specific time zone).

- Jonathan M Davis

Re: dereferencing null


On 03/07/2012 10:08 PM, Jonathan M Davis wrote:

On Wednesday, March 07, 2012 20:44:59 Chad J wrote:

On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:

You can use sentinels other than null.

-Steve


Example?


Create an instance of the class which is immutable and represents an invalid
value. You could check whether something is that value with the is operator,
since there's only one of it. You could even make it a derived class and have
all of its functions throw a particular exception if someone tries to call
them.

- Jonathan M Davis


Makes sense.  Awfully labor-intensive though.  Doesn't work well on 
classes that can't be easily altered.  That is, it violates this:

- Do not modify the implementation of UnreliableResource.  It's not always 
possible.


But, maybe it can be turned it into a template and made to work for 
arrays too...

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-07 Thread James Miller

On 8 March 2012 15:56, Jonathan M Davis  wrote:
> On Thursday, March 08, 2012 01:22:42 Stewart Gordon wrote:
>> On 07/03/2012 08:10, Jacob Carlborg wrote:
>> 
>>
>> > Yeah, Clock.now() would be good and Data.today() as well.
>>
>> My utility library has, for consistency, DateValue.now, TimeValue.now and
>> DateTime.now.
>
> I specically avoided giving a way to get the time with any type other than
> SysTime (and TickDuration for using a monotonic clock), because I believe that
> it leads to incorrect behavior. Any time that you're dealing with the system
> clock, you should be dealing with SysTime. Date, TimeOfDay, and DateTime are
> for when you need the date and/or time but don't care about what absolute time
> it's associated with in the real world. Treating DateTime as corresponding to
> a specific point in time is just going to cause problems, because it has no
> time zone. It could correspond to over 24 different times. By restricting
> getting the time to SysTime, it encourages the writing of correct code.
>
> - Jonathan M Davis

It tends to be better to go for proper timezoned code from the outset,
a workmate just had to add timezone support to the entire app
recently, took him about 2 weeks.

--
James Miller

Re: dereferencing null

On Wednesday, March 07, 2012 20:44:59 Chad J wrote:
> On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:
> > You can use sentinels other than null.
> > 
> > -Steve
> 
> Example?

Create an instance of the class which is immutable and represents an invalid 
value. You could check whether something is that value with the is operator, 
since there's only one of it. You could even make it a derived class and have 
all of its functions throw a particular exception if someone tries to call 
them.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

On Wednesday, March 07, 2012 22:55:51 Stewart Gordon wrote:
> The mention of this one reminds me of another issue: capitalisation
> consistency.  It would be nice to standardise whether acronyms/initialisms
> occurring within names have just the first letter or all letters
> capitalised.  I'm thinking best is to treat them as words and therefore
> capitalise just the first letter.  Though I've been known to do otherwise
> in the past.

I'm completely in favor of treating acronyms as being all captalized if the 
first letter is capitilized and all lowercase if the first letter is lowercase. 
It's actually a bit of a pet peeve of mine when people do stuff like Ascii 
instead of ASCII. And most of Phobos goes with fully capitilizing rather than 
just capitilizing the first letter. It's not completely consistent though.

> But it's confusing enough that there are still many functions in Phobos
> whose names are all lowercase when they should be camelCase.

That's _mostly_ been fixed. The main remaining culprits that I'm aware of are 
the std.string functions which take patterns. There was some discussion of 
replacing them with functions which take regexes. If we do that, then they'll 
be replaced with properly camelcased names. But _most_ of the function names 
in Phobos have been fixed to be properly camelcased.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

On Thursday, March 08, 2012 01:22:42 Stewart Gordon wrote:
> On 07/03/2012 08:10, Jacob Carlborg wrote:
> 
> 
> > Yeah, Clock.now() would be good and Data.today() as well.
> 
> My utility library has, for consistency, DateValue.now, TimeValue.now and
> DateTime.now.

I specically avoided giving a way to get the time with any type other than 
SysTime (and TickDuration for using a monotonic clock), because I believe that 
it leads to incorrect behavior. Any time that you're dealing with the system 
clock, you should be dealing with SysTime. Date, TimeOfDay, and DateTime are 
for when you need the date and/or time but don't care about what absolute time 
it's associated with in the real world. Treating DateTime as corresponding to 
a specific point in time is just going to cause problems, because it has no 
time zone. It could correspond to over 24 different times. By restricting 
getting the time to SysTime, it encourages the writing of correct code.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-07 Thread Martin Nowak


On Thu, 08 Mar 2012 01:00:48 +0100, Timon Gehr  wrote:


On 03/07/2012 11:30 PM, Jonathan M Davis wrote:

On Wednesday, March 07, 2012 17:06:21 Nick Sabalausky wrote:

Ahh, yea I remember now. I'd argue (strongly) that if a symbol is
inaccessible than it should never conflict with a symbol that is  
accessible.
After all, is there really much more point to the "visible vs  
accessible"
distinction besides just being able to say "Symbol  is private"  
instead

of "Unrecognzed symbol "?


Well, truth be told, it should be possible for the compiler to still  
say that
the symbol is private rather than that it's unrecognized. Just because  
it's
hidden for overload resolution and the like doesn't mean that the  
compiler

couldn't still recognize it as existing but inaccessible in cases where
there's no other match. It _is_ probably easier to implement it with the
"unrecognized symbol" behavior though.

Private symbols can be proposed during the spell correction lookup.



The only real downside that I can think of of making private symbols  
hidden is
that it could cause issues when symbols are changed to or from private,  
but
the way that overload sets are handled probably prevents that from  
being a
real issue. It may break code, but I don't think that it would silently  
break
code to change a symbol to or from private, which would be the real  
problem.


- Jonathan M Davis


Yes, private symbols probably shouldn't be hidden completely. For  
example, private constructors convey special semantics. (their existence  
also removes the default constructor) But private symbols should never  
conflict with public symbols. Probably it is best to also disallow  
overloading private symbols against public symbols.

It doesn't work out if you want to overload private/public constructors.

https://github.com/D-Programming-Language/dmd/pull/739

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-07 Thread Kapps


On Wednesday, 7 March 2012 at 19:12:25 UTC, H. S. Teoh wrote:
Supporting stuff like 5.hours will introduce additional 
complications to
D's lexical structure, though. The lexer will have to 
understand it as
(int:5)(.)(ident:hours) rather than (float:5.)(ident:hours). 
And then if
you actually *wanted* a float, you'd have another ambiguity: 
5..hours

could mean (float:5.)(.)(ident:hours) or (int:5)(..)(hours). And
5.0.hours just looks... weird.


T


Actually, Kenji's pull request for UFCS already takes care of 
this. Things like 5. aren't allowed, nor is 5.f; a number has to 
follow the decimal. So 5.f would invoke UFCS function f with the 
integer 5. I believe this change is already merged, though the 
rest of the UFCS pull request isn't unfortunately.

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-07 Thread Ary Manzana


On 3/6/12 9:25 PM, Jonathan M Davis wrote:

On Tuesday, March 06, 2012 20:58:52 Ary Manzana wrote:

On 3/6/12 8:43 PM, Jonathan M Davis wrote:

On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote:

writeln(time.toISOExtendedString()); // bzzt, wrong, but this
used to work!


Yes, and it was quickly changed to toISOExtString, because
toISOExtendedString is painfully long. toISOExtString is bad enough, but
you can't really make it any shorter without making the name
uninformative.


Nope, apparently, I meant "dur". Ridiculous.


A Duration needs to be constructed with a template, and
duration!"hours"(13), duration!"seconds"(44), etc. is painfully long when
used in expressions. So, it was shortened to dur. I don't know of any
other abbreviation which would make sense.


Painfully long?

How much time does it take you to type 5 more chars? How much time does
it take you to understand "dur" when you read it instead of "duration"?


I agree with H.S. Teoh in that abbreviations should be meaniful and
consistent but that they _should_ be used where applicable. Code becomes
painfully long otherwise - especially when chaining function calls and
the like.


Code becomes painfully long when you write lots of lines, not when you
write long lines. Specially when you write lots of boilerplate lines.


You don't write much code in functional style, do you?


Here's something I wrote today:

parent_ids = results.map{|x| 
x['_source']['parent_ids']}.flatten.uniq.compact

Hash[Site.find(parent_ids).map{|x| [x.id, x]}]

Or I could have written:

Hash[
  Site.find(
results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact
  ).map{|x| [x.id, x]}
]

No abbreviation at all, many function calls, functional style in the 
middle (the couple of "map").


In Ruby it's not such a big problem to have descriptive names.

I guess in D it would be longer because of all the template invocation, 
the argument types, etc. I just guess it, I'm not sure.



If you chain functions

much, then long names very quickly result in long lines, which makes the code
harder to read, and can quickly lead to expressions having to be multiple
lines, simply because the symbol names involved were overly verbose.

While, I grant you that duration!"minutes"(5) might be more immediately clear
than dur!"minutes"(5) is, I don't buy that it makes all that much of a
differences. You're not going to mistake dur for anything else even if it
doesn't immediately occur to you that it's an abbreviation for duration, and
the units make it very clear that it's related to time. And since dur is
something that's likely to be commonly used, it will very quick and easy to
remember what it is.


The problem is not mistaking it with something else. The problem is when 
you want to write it. In Ruby my mind works like this:


Mind: "How would I get a span for 5 seconds?"
Mind: "Let's try 5.seconds"
Mind: "Wow, it works!"

I'm trying to remember cases when I just wrote what my mind thought it 
was correct and I was *so* surprised it worked out of the box in Ruby. 
Like writing array.last, and get it to work, instead of 
array[array.length - 1]. But in D, from the docs 
(http://dlang.org/arrays.html )


bar[$-1] // retrieves last element of the array

I read: bar dollar minus one wait what??

Now, in D I try:

5.seconds

and it doesn't work. I have to write this very unintuitive:

dur!"minutes"(5)

Was it really necessary to implement it that way?

Again, the problem is not understanding the meaning, the problem is 
guessing what you have to write and get it right the first time.

Re: dereferencing null


On 03/07/2012 07:39 PM, Timon Gehr wrote:

On 03/08/2012 01:24 AM, Chad J wrote:


Though, more to the point:
I would probably forbid "Foo foo = new Foo(this);". The design that
leads to this is creating circular dependencies, which is usually bad to
begin with.


Circular object references are often justified.


Would we lose much of value?


Well this would amount to forbidding escaping an object from its
constructor, as well as forbidding calling any member functions from the
constructor. Also, if you *need* to create a circular structure, you'd
have to use sentinel objects. Those are worse than null.



OK, that does sound unusually harsh.

Re: dereferencing null


On 03/07/2012 02:09 PM, Jonathan M Davis wrote:

On Wednesday, March 07, 2012 07:55:35 H. S. Teoh wrote:

It's not that the null pointer itself corrupts memory. It's that the
null pointer is a sign that something may have corrupted memory *before*
you got to that point.

The point is, it's impossible to tell whether the null pointer was
merely the result of forgetting to initialize something, or it's a
symptom of a far more sinister problem. The source of the problem could
potentially be very far away, in unrelated code, and only when you tried
to access the pointer, you discover that something is wrong.

At that point, it may very well be the case that the null pointer isn't
just a benign uninitialized pointer, but the result of a memory
corruption, perhaps an exploit in the process of taking over your
application, or some internal consistency error that is in the process
of destroying user data. Trying to continue is a bad idea, since you'd
be letting the exploit take over, or allowing user data to get even more
corrupted than it already is.


Also, while D does much more to protect you from stuff like memory corruption
than C/C++ does, it's still a systems language. Stuff like that can definitely
happen. If you're writing primarily in SafeD, then it's very much minimized,
but it's not necessarily eliminated. All it takes is a bug in @system code
which could corrupt memory, and voila, you have corrupted memory, and an @safe
function could get a segfault even though it's correct code. It's likely to be
a very rare occurrence, but it's possible. A since when you get a segfault,
you can't know what caused it, you have to assume that it could have been
caused by one of the nastier possibilites rather than a relatively benign one.

And since ultimately, your program should be checking for null before
derefencing a variable in any case where it could be null, segfaulting due to
dereferencing a null pointer is a program bug which should be caught in
testing - like assertions in general are - rather than having the program
attempt to recover from it. And if you do _that_, the odds of a segfault being
due to something very nasty just go up, making it that much more of a bad idea
to try and recover from one.

- Jonathan M Davis


I can see where you're coming from now.

As I mentioned in another post, my lack of consideration for this 
indicator of memory corruption is probably a reflection of my bias 
towards VM'd languages.


I still don't buy the whole "it's a program bug that should be caught in 
testing".  I mean... true, but sometimes it isn't.  Especially since 
testing and assertions can never be %100 thorough.  What then?  Sorry, 
enjoy your suffering?


At that point I would like to have a better way to do sentinel values. 
I'd at least like to get an exception of some kind if I try to access a 
value that /shouldn't/ be there (as opposed to something that /should/ 
be there but /isn't/).


Combine that with sandboxing and I might just be satisfied for the time 
being.


See my reply to Steve for more details.  It's the one that starts like this:


Example?

Here, if you want, I'll start with a typical case.  Please make it right.

class UnreliableResource
{
this(string sourceFile) {...}
this(uint userId) {...}
void doTheThing() {...}
}

Re: dereferencing null


On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:

On Wed, 07 Mar 2012 10:10:32 -0500, Chad J
 wrote:


On Wednesday, 7 March 2012 at 14:23:18 UTC, Chad J wrote:

I spoke too soon!
We missed one:

1. You forgot to initialize a variable.
2. Your memory has been corrupted, and some corrupted pointer
now points into no-mem land.
3. You are accessing memory that has been deallocated.
4. null was being used as a sentinal value, and it snuck into
a place where the value should not be a sentinal anymore.

I will now change what I said to reflect this:

I think I see where the misunderstanding is coming from.

I encounter (1) from time to time. It isn't a huge problem because
usually if I declare something the next thing on my mind is
initializing it. Even if I forget, I'll catch it in early testing. It
tends to never make it to anyone else's desk, unless it's a
regression. Regressions like this aren't terribly common though. If
you make my program crash from (1), I'll live.

I didn't even consider (2) and (3) as possibilities. Those are far
from my mind. I think I'm used to VM languages at this point (C#,
Java, Actionscript 3, Haxe, Synergy/DE|DBL, etc). In the VM, (2) and
(3) can't happen. I never worry about those. Feel free to crash these
in D.

I encounter (4) a lot. I really don't want my programs crashed when
(4) happens. Such crashes would be super annoying, and they can happen
at very bad times.


You can use sentinels other than null.

-Steve


Example?

Here, if you want, I'll start with a typical case.  Please make it right.

class UnreliableResource
{
this(string sourceFile) {...}
this(uint userId) {...}
void doTheThing() {...}
}

void main()
{
// Set this to a sentinal value for cases where the source does
//   not exist, thus preventing proper initialization of res.
UnreliableResource res = null;

// The point here is that obtaining this unreliable resource
//   is tricky business, and therefore complicated.
//
if ( std.file.exists("some_special_file") )
{
res = new UnreliableResource("some_special_file");
}
else
{
uint uid = getUserIdSomehow();
if ( isValidUserId(uid) )
{
res = new UnreliableResource(uid);
}
}

// Do some other stuff.
...

// Now use the resource.
try
{
thisCouldBreakButItWont(res);
}
// Fairly safe if we were in a reasonable VM.
catch ( NullDerefException e )
{
writefln("This shouldn't happen, but it did.");
}
}

void thisCouldBreakButItWont(UnreliableResource res)
{
if ( res != null )
{
res.doTheThing();
}
else
{
doSomethingUsefulThatCanHappenWhenResIsNotAvailable();
writefln("Couldn't find the resource thingy.");
writefln("Resetting the m-rotor.  (NOO!)");
}
}

Please follow these constraints:

- Do not use a separate boolean variable for determining whether or not 
'res' could be created.  This violates a kind of SSOT 
(http://en.wikipedia.org/wiki/Single_Source_of_Truth) because it allows 
cases where the hypothetical "resIsInitialized" variable is true but res 
isn't actually initialized, or where "resIsInitialized" is false but res 
is actually initialized.  It also doesn't throw catchable exceptions 
when the uninitialized class has methods called on it.  In my pansy 
VM-based languages I always prefer to risk the null sentinal.


- Do not modify the implementation of UnreliableResource.  It's not 
always possible.


- Try to make the solution something that could, in principle, be placed 
into Phobos and reused without a lot of refactoring in the original code.


...

Now I will think about this a bit...

This reminds me a lot of algebraic data types.  I kind of want to say 
something like:

auto res = empty | UnreliableResource;

and then unwrap it:

...
thisCantBreakAnymore(res);
}

void thisCantBreakAnymore(UnreliableResource res)
{
res.doTheThing();
}

void thisCantBreakAnymore(empty)
{
doSomethingUsefulThatCanHappenWhenResIsNotAvailable();
writefln("Couldn't find the resource thingy.");
writefln("Resetting the m-rotor.  (NOO!)");
}


I'm not absolutely sure I'd want to go that path though, and since D is 
unlikely to do any of those things, I just want to be able to catch an 
exception if the sentinel value tries to have the "doTheThing()" method 
called on it.


I can maybe see invariants being used for this:

class UnreliableResource
{
bool initialized = false;

invariant
{
if (!initialized)
throw new Exception("Not initialized.");
}

void initialize(string sourceFile)
{

Re: Is it bad for object.di to depend on core.exception?

2012-03-07 Thread Daniel Murphy

"H. S. Teoh"  wrote in message 
news:mailman.176.1331147910.4860.digitalmar...@puremagic.com...
> On Sun, Mar 04, 2012 at 07:31:49AM +0100, Martin Nowak wrote:
>> Wasn't the latest proposal that we add a working AA implementation to
>> the runtime and switch the compiler after that has settled?
>
> Is somebody working on that? If not, I may take a crack at doing it.
>
> And by runtime you mean object_.d, right? aaA.d is already part of
> druntime, from what I understand. :-)
>
>
> T
>
> -- 
> If it breaks, you get to keep both pieces. -- Software disclaimer notice

I was the one that recently tried to get AAs rolled back to the D1 
implemenation (unsuccessfully) but I'm not working on a reimplementation. 
The closed pull requests are sitting on github if you'd like to take a look 
at them.

For it to be 'fixed', AAs need to be able to do all the things they can do 
now, including producing error messages with V[K] instead of 
AssociativeArray!(K, V), magic initialization and the same reference 
semantics.  They also need to _work_ in ctfe, either because the 
implementation is available and ctfeable, or because the calls get 
translated late enough that the interpreter can pick out the 
IndexExps/DotIdExps and treat them specially.

At the moment I'm leaning towards doing the translations in the glue layer, 
and using ufcs for everything else, but whatever works.  There's a thread on 
the internals mailing list that lists some of the issues with the current 
implementation.

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-07 Thread Bernard Helyer


On Wednesday, 7 March 2012 at 18:39:41 UTC, Nick Sabalausky wrote:

"Adam D. Ruppe"  wrote in message
news:sgmfyzmrfygshlmfq...@forum.dlang.org...

On Tuesday, 6 March 2012 at 20:20:47 UTC, Derek wrote:
Should we use American or English spelling? Color verses 
Colour, for example?


I can go either way. I lean toward English spelling
though, simply because America is the exceptional
country (in the world and on the newsgroup too) in
this regard.



British English may be the more "official" English, with 
American English as
a mere variation, but AIUI, the "de facto international 
language" is
American English, not British English, as a result of the US 
being a
long-time major economic superpower (for better or worse). 
England used to
be a major superpower, but that was centuries ago, and from 
what I can tell,
American English seems to be the preferred "de facto standard" 
English now.



But, either option is better than "Clr" or "Col".


"clr" is the verb "clear" and "col" is "column" :)


In my programs I use British English because that's what I use, 
and anything else looks 'wrong' to me. If the API is particularly 
public, I usually provide an alias. Then again, I'm just a 
colonial hick, so what would I know? :P

Re: Arbitrary abbreviations in phobos considered ridiculous


On 07/03/2012 08:10, Jacob Carlborg wrote:


Yeah, Clock.now() would be good and Data.today() as well.


My utility library has, for consistency, DateValue.now, TimeValue.now and 
DateTime.now.

Stewart.

Re: Arbitrary abbreviations in phobos considered ridiculous


On 07/03/2012 19:03, H. S. Teoh wrote:


clr == common language runtime
col == polysemous word meaning anything from column to color to collect to 
colon.



When I went to school, the _word_ "col" meant a mountain pass, not any of those 
things.

Stewart.

Re: dereferencing null


On 03/08/2012 01:24 AM, Chad J wrote:

On 03/07/2012 04:41 AM, Timon Gehr wrote:

On 03/07/2012 02:40 AM, Chad J wrote:

But to initialize non-null fields, I suspect we would need to be able to
do stuff like this:

class Foo
{
int dummy;
}

class Bar
{
Foo foo = new Foo();

this() { foo.dummy = 5; }
}

Which would be lowered by the compiler into this:

class Bar
{
// Assume we've already checked for bogus assignments.
// It is now safe to make this nullable.
Nullable!(Foo) foo;

this()
{
// Member initialization is done first.
foo = new Foo();

// Then programmer-supplied ctor code runs after.
foo.dummy = 5;
}
}

I remember C# being able to do this. I never understood why D doesn't
allow this. Without it, I have to repeat myself a lot, and that is just
wrong ;).]


It is not sufficient.

class Bar{
Foo foo = new Foo(this);
void method(){...}
}
class Foo{
this(Bar bar){bar.foo.method();}
}


Lowered it a bit to try to compile, because it seems Foo doesn't have a
method() :

import std.stdio;

class Bar{
Foo foo;
this()
{
foo = new Foo(this);
}
void method(){ writefln("poo"); }
}
class Foo{
this(Bar bar){bar.foo.method();}
}

void main()
{
}

And, it doesn't:
main.d(12): Error: no property 'method' for type 'main.Foo'



Just move the method from Bar to Foo.

import std.stdio;

class Bar{
Foo foo;
this()
{
foo = new Foo(this);
}
}
class Foo{
this(Bar bar){bar.foo.method();}
void method(){ writefln("poo"); }
}

void main()
{
auto bar = new Bar;
}




Though, more to the point:
I would probably forbid "Foo foo = new Foo(this);". The design that
leads to this is creating circular dependencies, which is usually bad to
begin with.


Circular object references are often justified.


Would we lose much of value?


Well this would amount to forbidding escaping an object from its 
constructor, as well as forbidding calling any member functions from the 
constructor. Also, if you *need* to create a circular structure, you'd 
have to use sentinel objects. Those are worse than null.

Re: dereferencing null


On 03/07/2012 04:41 AM, Timon Gehr wrote:

On 03/07/2012 02:40 AM, Chad J wrote:

But to initialize non-null fields, I suspect we would need to be able to
do stuff like this:

class Foo
{
int dummy;
}

class Bar
{
Foo foo = new Foo();

this() { foo.dummy = 5; }
}

Which would be lowered by the compiler into this:

class Bar
{
// Assume we've already checked for bogus assignments.
// It is now safe to make this nullable.
Nullable!(Foo) foo;

this()
{
// Member initialization is done first.
foo = new Foo();

// Then programmer-supplied ctor code runs after.
foo.dummy = 5;
}
}

I remember C# being able to do this. I never understood why D doesn't
allow this. Without it, I have to repeat myself a lot, and that is just
wrong ;).]


It is not sufficient.

class Bar{
Foo foo = new Foo(this);
void method(){...}
}
class Foo{
this(Bar bar){bar.foo.method();}
}


Lowered it a bit to try to compile, because it seems Foo doesn't have a 
method() :


import std.stdio;

class Bar{
  Foo foo;
  this()
  {
foo = new Foo(this);
  }
  void method(){ writefln("poo"); }
}
class Foo{
  this(Bar bar){bar.foo.method();}
}

void main()
{
}

And, it doesn't:
main.d(12): Error: no property 'method' for type 'main.Foo'

Though, more to the point:
I would probably forbid "Foo foo = new Foo(this);".  The design that 
leads to this is creating circular dependencies, which is usually bad to 
begin with.  Would we lose much of value?

Re: Arbitrary abbreviations in phobos considered ridiculous


On 03/08/2012 01:08 AM, foobar wrote:

On Wednesday, 7 March 2012 at 21:39:39 UTC, Timon Gehr wrote:

On 03/07/2012 09:04 PM, foobar wrote:

On Wednesday, 7 March 2012 at 10:08:53 UTC, Timon Gehr wrote:

On 03/06/2012 10:30 PM, deadalnix wrote:


auto helps too.


This remark was explicitly about _Java_ code style.


Wrong. This is an issue with the *language*, NOT the naming convention.


It is hard to imagine how it could be concluded that this is not what
the post has expressed.


Come on, do we really need to discuss the difference between a
programming language and its coding conventions?
The fact that Java has flaws *as a language* is completely orthogonal to
the fact that it has an excellent coding convention which can also be
used with other languages such as D.

One of the reasons for Java's success is its code style despite being a
simplistic language. It might be painful to write "duration" instead of
"dur" when working on your own pet project but it's in a different story
when dealing with large enterprise systems. IMO D will not catch on in a
larger setting (in the enterprise) as long as it refuses to grow up and
keeps it advocating its 1337 hacker attitude.



To make this clear, we agree on the relevant issues. There obviously has 
been a misunderstanding, and it does not make sense to argue about it.

Re: inout and function/delegate parameters


On 03/07/2012 04:41 PM, Steven Schveighoffer wrote:

On Tue, 06 Mar 2012 05:11:34 -0500, Timon Gehr  wrote:


On 03/06/2012 12:27 AM, Steven Schveighoffer wrote:
...


There are two parts to inout, one is that it can be one function called
3 different ways, the other is that you know it's constant during
function execution. Some people like that second part, even if it
doesn't fully guarantee everything. I.e. there's a reason people use
const in C++ besides it being trendy.



By passing a delegate that changes an inout-matched argument it is
made explicit that inout data may change. Technically, none of the
existing guarantees are lost, we just add some expressiveness to the
type system.


Yes, I understand that it works. I know that it doesn't violate
technically any const guarantees.



Yes, that is not what I was after:

void foo(inout(int)*x, void delegate(inout(int)*) dg)
// both inout's denote the same wildcard
{   dg(x);
}

void main(){
int x;
foo(&x, (p){*p=2;}); // this currently cannot be valid code
}

The function call is explicit about that may change the inout parameter. 
There are no guarantees lost. It is the call site who changes the 
parameter. Code that currently has the guarantee that the parameter 
won't change will keep it, because there is no valid code that could 
silently change semantics under the change and does not use some fancy 
introspection.

Re: inout and function/delegate parameters


On 03/07/2012 11:37 PM, Stewart Gordon wrote:

On 07/03/2012 15:41, Steven Schveighoffer wrote:


In fact, I think this is valid D code:

int i;
const int *pi = &i;
int *p = cast()pi;
*p = 5; // legal because I know this points at i, and i is really mutable


cast() is an abomination. I'm not sure OTTOMH whether it's a bug that it
works.



It is not legal code. I did not point it out because it was clear what 
was meant. cast() only casts away the top level of modifiers. It is 
perfectly safe except for class objects.

Re: Arbitrary abbreviations in phobos considered ridiculous


On Wednesday, 7 March 2012 at 21:39:39 UTC, Timon Gehr wrote:

On 03/07/2012 09:04 PM, foobar wrote:

On Wednesday, 7 March 2012 at 10:08:53 UTC, Timon Gehr wrote:

On 03/06/2012 10:30 PM, deadalnix wrote:


auto helps too.


This remark was explicitly about _Java_ code style.


Wrong. This is an issue with the *language*, NOT the naming 
convention.


It is hard to imagine how it could be concluded that this is 
not what the post has expressed.


Come on, do we really need to discuss the difference between a 
programming language and its coding conventions?
The fact that Java has flaws *as a language* is completely 
orthogonal to the fact that it has an excellent coding convention 
which can also be used with other languages such as D.


One of the reasons for Java's success is its code style despite 
being a simplistic language. It might be painful to write 
"duration" instead of "dur" when working on your own pet project 
but it's in a different story when dealing with large enterprise 
systems. IMO D will not catch on in a larger setting (in the 
enterprise) as long as it refuses to grow up and keeps it 
advocating its 1337 hacker attitude.

Re: Arbitrary abbreviations in phobos considered ridiculous


On 03/07/2012 11:30 PM, Jonathan M Davis wrote:

On Wednesday, March 07, 2012 17:06:21 Nick Sabalausky wrote:

Ahh, yea I remember now. I'd argue (strongly) that if a symbol is
inaccessible than it should never conflict with a symbol that is accessible.
After all, is there really much more point to the "visible vs accessible"
distinction besides just being able to say "Symbol  is private" instead
of "Unrecognzed symbol "?


Well, truth be told, it should be possible for the compiler to still say that
the symbol is private rather than that it's unrecognized. Just because it's
hidden for overload resolution and the like doesn't mean that the compiler
couldn't still recognize it as existing but inaccessible in cases where
there's no other match. It _is_ probably easier to implement it with the
"unrecognized symbol" behavior though.

The only real downside that I can think of of making private symbols hidden is
that it could cause issues when symbols are changed to or from private, but
the way that overload sets are handled probably prevents that from being a
real issue. It may break code, but I don't think that it would silently break
code to change a symbol to or from private, which would be the real problem.

- Jonathan M Davis


Yes, private symbols probably shouldn't be hidden completely. For 
example, private constructors convey special semantics. (their existence 
also removes the default constructor) But private symbols should never 
conflict with public symbols. Probably it is best to also disallow 
overloading private symbols against public symbols.

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-07 Thread Jos van Uden


On 6-3-2012 19:35, H. S. Teoh wrote:

On Tue, Mar 06, 2012 at 07:13:47PM +0100, Alex Rønne Petersen wrote:



(Also, seriously, I think you're over-dramatizing the Java variable
naming thing; I rarely see names that are as bad as you claim...)

[...]

OK, I exaggerated a little. :-) But my point stands, that I find many of
these names just way too long for my tastes. Like BufferedOutputStream.
Or ByteArrayOutputStream.  Ugh. I mean, we're writing programs here, not
essays. Why spell things out in full if we don't need to?


long time = System.currentTimeMillis();

I use a macro for that one :-)

Jos

Re: inout and function/delegate parameters

On Wed, 07 Mar 2012 18:01:10 -0500, Stewart Gordon   
wrote:



On 07/03/2012 22:48, Steven Schveighoffer wrote:
On Wed, 07 Mar 2012 17:37:53 -0500, Stewart Gordon  
 wrote:


cast() is an abomination. I'm not sure OTTOMH whether it's a bug that  
it works.


Sorry, it's just easier than typing cast(int*).


Which is another abomination.  The means of casting away constancy  
should be explicit.


I agree, but it doesn't make it illegal.  It was just a means to show what  
I meant.





But from an API point of view, I look at at inout as guaranteeing  
anything the parameter
points at won't change while inside the function *using that  
parameter*. Even though it's
legal, it's disingenuous (at least as long as we define inout that  
way).


That's what const is for.


And inout. Sorry, it was meant that way, even if you don't agree.


Maybe _you_ meant it that way, but did anyone else?


I actually designed it...

http://d.puremagic.com/issues/show_bug.cgi?id=1961

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP2

-Steve

Re: Lexer and parser generators using CTFE

"Nick Sabalausky"  wrote in message 
news:jikfpi$25cc$1...@digitalmars.com...
> "Nick Sabalausky"  wrote in message 
> news:jikcit$201o$1...@digitalmars.com...
>>
>> Hmm, maybe I need to think about what it would take to make Goldie able 
>> to parse at compile-time...
>>
>
> Just gave it a quick shot. It was looking like it might not be too bad, 
> but then I hit:
>
> Assertion failure: 'ctfeStack.stackPointer() == 0' on line 4823 in file 
> 'interpret.c'
>
> Bleh.
>
> (This was with DMD 2.058)

Filed: http://d.puremagic.com/issues/show_bug.cgi?id=7667

Re: inout and function/delegate parameters


On 07/03/2012 22:48, Steven Schveighoffer wrote:

On Wed, 07 Mar 2012 17:37:53 -0500, Stewart Gordon  wrote:



cast() is an abomination. I'm not sure OTTOMH whether it's a bug that it works.


Sorry, it's just easier than typing cast(int*).


Which is another abomination.  The means of casting away constancy should be 
explicit.



But from an API point of view, I look at at inout as guaranteeing anything the 
parameter
points at won't change while inside the function *using that parameter*. Even 
though it's
legal, it's disingenuous (at least as long as we define inout that way).


That's what const is for.


And inout. Sorry, it was meant that way, even if you don't agree.


Maybe _you_ meant it that way, but did anyone else?

Stewart.

Re: Arbitrary abbreviations in phobos considered ridiculous


On 06/03/2012 16:38, Adam D. Ruppe wrote:

One of the stumbling blocks on using std.datetime is how
many bizarre abbreviations it has.

auto time = Clock.currentTime(); // bzzt, wrong

if(time - something > duration!"hours"(4)) // bzzt, wrong

writeln(time.toISOExtendedString()); // bzzt, wrong, but this used to work!



The mention of this one reminds me of another issue: capitalisation consistency.  It would 
be nice to standardise whether acronyms/initialisms occurring within names have just the 
first letter or all letters capitalised.  I'm thinking best is to treat them as words and 
therefore capitalise just the first letter.  Though I've been known to do otherwise in the 
past.


But it's confusing enough that there are still many functions in Phobos whose names are 
all lowercase when they should be camelCase.


The Java API is in a mess in this respect:
http://www.mindprod.com/jgloss/inconsistencies.html

We'd have no trouble avoiding this if only Phobos was designed to be free of such 
inconsistencies from its beginning.


Stewart.

Re: inout and function/delegate parameters

On Wed, 07 Mar 2012 17:37:53 -0500, Stewart Gordon   
wrote:



On 07/03/2012 15:41, Steven Schveighoffer wrote:


In fact, I think this is valid D code:

int i;
const int *pi = &i;
int *p = cast()pi;
*p = 5; // legal because I know this points at i, and i is really  
mutable


cast() is an abomination.  I'm not sure OTTOMH whether it's a bug that  
it works.


Sorry, it's just easier than typing cast(int*).

And I believe it's legal, as long as you *know* that the underlying data  
is mutable.  The above code snippit is legal, because it is shown as long  
as the first two lines are included that the actual data is mutable.


But from an API point of view, I look at at inout as guaranteeing  
anything the parameter
points at won't change while inside the function *using that  
parameter*. Even though it's

legal, it's disingenuous (at least as long as we define inout that way).


That's what const is for.


And inout.  Sorry, it was meant that way, even if you don't agree.

-Steve

Re: inout and function/delegate parameters


On 07/03/2012 15:41, Steven Schveighoffer wrote:


In fact, I think this is valid D code:

int i;
const int *pi = &i;
int *p = cast()pi;
*p = 5; // legal because I know this points at i, and i is really mutable


cast() is an abomination.  I'm not sure OTTOMH whether it's a bug that it works.


But from an API point of view, I look at at inout as guaranteeing anything the 
parameter
points at won't change while inside the function *using that parameter*. Even 
though it's
legal, it's disingenuous (at least as long as we define inout that way).


That's what const is for.

The whole point of inout is that the caller has the choice of whether to pass in and get 
out again mutable, const or immutable data.  Allowing the caller to pass in a delegate 
with a mutable, const or immutable parameter would fit right in with this.




As usual, you find and poke holes in all my arguments :) I'm thinking that in 
order to
make this work we need a way to specify an inout modifier really represents the 
matched
type rather than a full-fledged inout parameter.



Yes, and ways of specifying this have been suggested early in this thread.

Stewart.

Re: Arbitrary abbreviations in phobos considered ridiculous

On Wednesday, March 07, 2012 17:06:21 Nick Sabalausky wrote:
> Ahh, yea I remember now. I'd argue (strongly) that if a symbol is
> inaccessible than it should never conflict with a symbol that is accessible.
> After all, is there really much more point to the "visible vs accessible"
> distinction besides just being able to say "Symbol  is private" instead
> of "Unrecognzed symbol "?

Well, truth be told, it should be possible for the compiler to still say that 
the symbol is private rather than that it's unrecognized. Just because it's 
hidden for overload resolution and the like doesn't mean that the compiler 
couldn't still recognize it as existing but inaccessible in cases where 
there's no other match. It _is_ probably easier to implement it with the 
"unrecognized symbol" behavior though.

The only real downside that I can think of of making private symbols hidden is 
that it could cause issues when symbols are changed to or from private, but 
the way that overload sets are handled probably prevents that from being a 
real issue. It may break code, but I don't think that it would silently break 
code to change a symbol to or from private, which would be the real problem.

- Jonathan M Davis

Re: Poll of the week: main OS and compiler

On Wednesday, March 07, 2012 23:07:11 Mars wrote:
> On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:
> > Personally, I just want to be able to link like a normal
> > windows developer.
> > My code is C/C++, built with VC, and I want to link my D app
> > against those
> > libs using the VC linker, and debug with Visual Studio. This is
> > the
> > workflow I think the vast majority of Windows devs will expect,
> > and it
> > sounds simple enough. This is the only thing standing between
> > me using D
> > for any major projects, and just experimenting with the
> > language for
> > evaluation, or just academic interest.
> > 64bit is far less important to me personally, VisualC linker
> > compatibility
> > is the big one. I just want to link against my C code without
> > jumping
> > through lots of hoops.
> 
> That's exactly my problem... and although I love D, these hurdles
> made me take a step back, to C++, while I wait for this to
> change, so I can finally use D efficiently.
> 
> I'm sure this isn't a trivial task, but the problematic isn't new
> after all. Why hasn't it been addressed yet? In my eyes this
> should be a top priority, to make it easier for new users to get
> into D. Till this poll I actually believed the problem was that D
> isn't used much by Windows users.

I don' think that Walter really views it as much of a problem - or if he does, 
he didn't used to. Remember that he's used to an environment where he doesn't 
use Visual Studio or Microsoft's C++ compiler. And his customers use dmc just 
like he does (since they're his customers), so many of the people that he 
interacts with in the C/C++ world are not necessarily particularly Microsoft-
centric on Windows.

Add to that the enormous task that it is to actually make dmd work with COFF 
or 64-bit or anything of the sort on Windows, and it's no wonder that it 
hasn't happened yet.

To be fair, there are plenty of other things that have needed to be done, and 
what we have for Windows does work, even if it's suboptimal. So, it's not all 
that unreasonable that the issue would be put off as long as it has been. And 
Walter _has_ been slowing working on porting optlink to C (the fact that it's 
written in assembly makes it really fast but hard to maintain and change), 
which would make it possible to then start porting stuff to 64-bit and 
considering COFF and stuff like that.

I expect that we'll get there eventually, but there's so much to do, and this 
particular issue is not only hard, but there's pretty much only one person 
currently qualified to do it, so it hasn't happened yet.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

On Wed, 07 Mar 2012 10:25:32 -0500, Steven Schveighoffer  
 wrote:


On Wed, 07 Mar 2012 08:47:48 -0500, Steven Schveighoffer  
 wrote:



I'll see if I can do a pull request.


Almost done, need to test:

https://github.com/schveiguy/druntime/commit/cf9d1ba4f5498c447d91497cb5edbd735d2b4c7e

Actually cleans up a lot of the template constraints too...


https://github.com/D-Programming-Language/druntime/pull/173

https://github.com/D-Programming-Language/phobos/pull/483

-Steve

Re: Arbitrary abbreviations in phobos considered ridiculous

"Jonathan M Davis"  wrote in message 
news:mailman.186.1331156894.4860.digitalmar...@puremagic.com...
> On Wednesday, March 07, 2012 15:34:44 Nick Sabalausky wrote:
>> "Jonathan M Davis"  wrote in message
>> news:mailman.180.1331149159.4860.digitalmar...@puremagic.com...
>>
>> > On Tuesday, March 06, 2012 21:56:38 H. S. Teoh wrote:
>> >> On Tue, Mar 06, 2012 at 07:48:37PM -0800, Jonathan M Davis wrote:
>> >> >
>> >> > True, but if names conflict, you then have to worry about using the
>> >> > full import paths for symbols, which can get annoying.
>> >>
>> >> [...]
>> >>
>> >> I thought that's what module aliases were for.
>> >
>> > They can help, but thanks to the fact that they impact any other 
>> > modules
>> > that
>> > import that module, they're often unacceptable.
>>
>> That's just an implementation bug, though, isn't it? And wasn't it 
>> recently
>> fixed?
>
> It's a design issue. Yes, the bug that private didn't affect aliases was 
> fixed,
> but private does _not_ hide symbols. It only makes them inaccessible. So, 
> for
> instance, if std.datetime were to alias std.string.indexOf to indexOf, 
> then
> every module which imports both std.algorithm and std.datetime would then 
> have
> to either alias std.algorithm.indexOf themselves or use the full import 
> path.
> So, as it stands, private aliases are pretty much useless.

Ahh, yea I remember now. I'd argue (strongly) that if a symbol is 
inaccessible than it should never conflict with a symbol that is accessible. 
After all, is there really much more point to the "visible vs accessible" 
distinction besides just being able to say "Symbol  is private" instead 
of "Unrecognzed symbol "?

Re: Poll of the week: main OS and compiler

2012-03-07 Thread Mars


On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:
Personally, I just want to be able to link like a normal 
windows developer.
My code is C/C++, built with VC, and I want to link my D app 
against those
libs using the VC linker, and debug with Visual Studio. This is 
the
workflow I think the vast majority of Windows devs will expect, 
and it
sounds simple enough. This is the only thing standing between 
me using D
for any major projects, and just experimenting with the 
language for

evaluation, or just academic interest.
64bit is far less important to me personally, VisualC linker 
compatibility
is the big one. I just want to link against my C code without 
jumping

through lots of hoops.


That's exactly my problem... and although I love D, these hurdles 
made me take a step back, to C++, while I wait for this to 
change, so I can finally use D efficiently.


I'm sure this isn't a trivial task, but the problematic isn't new 
after all. Why hasn't it been addressed yet? In my eyes this 
should be a top priority, to make it easier for new users to get 
into D. Till this poll I actually believed the problem was that D 
isn't used much by Windows users.

Re: Arbitrary abbreviations in phobos considered ridiculous

"H. S. Teoh"  wrote in message 
news:mailman.175.1331147548.4860.digitalmar...@puremagic.com...
> On Wed, Mar 07, 2012 at 01:50:03PM -0500, Nick Sabalausky wrote:
>> Course, I can still live with just 'alias dur!"years" years;..etc...'.
>> The *main* thing is that we can just do "hours(5)"...(or heck, once
>> UFCS finally gets fixed: "5.hours")
> [...]
>
> Hooray! Ruby syntax FTW!
>
> Tangential comment:
>
> Before I discovered D, Ruby was among the top candidates in my list of
> programming languages close to my ideals. Once D pulls off UFCS, it will
> trump Ruby in so many more ways... such as being able to effectively
> extend class methods just by declaring module-level functions of the
> form:
>
> retType func(classname obj, ...);
>
> (which I believe is already (somewhat?) supported). Among many other
> things.
>

I'm not really much of a ruby fan, except in comparison to python (I think 
ruby's whole "It's like English, just write it like you'd expect it to be 
written" thing is both untrue and misguided). But yea, UFCS is awesome 
(erm..."will be" awesome...eventually...I hope...).

> Supporting stuff like 5.hours will introduce additional complications to
> D's lexical structure, though. The lexer will have to understand it as
> (int:5)(.)(ident:hours) rather than (float:5.)(ident:hours). And then if
> you actually *wanted* a float, you'd have another ambiguity: 5..hours
> could mean (float:5.)(.)(ident:hours) or (int:5)(..)(hours). And
> 5.0.hours just looks... weird.
>

That "5."/".5" float syntax need to die anyway. It's just pointless and gets 
in the way of things that *aren't* pointless like UFCS.

I agree that "5.0.hours" looks a little weird, but meh, it's good enough and 
there's no fundamental problem with it (and it's a hell of a lot better than 
"5. .hours"). And you can just do "(5.0).hours" if you really want.

Re: Review of Jose Armando Garcia Sancio's std.log

2012-03-07 Thread Jose Armando Garcia

On Wed, Mar 7, 2012 at 1:53 PM, David Nadlinger  wrote:
> On Monday, 13 February 2012 at 15:50:05 UTC, David Nadlinger wrote:
>>
>> Barring any objections, the review period starts now and ends in three
>> weeks, on March 6th, followed by a week of voting.
>
>
> Okay, everyone, by the original schedule, the review period would have ended
> yesterday. However, I don't think it makes sense to start a vote right now,
> where several points are actively discussed.
>
> After discussing the situation with Jose, I think the best option is to
> extend the review period for another few days, until next Monday. Jose will
> try to answer any open comments so everybody can get a good idea of what the
> library does and what others expect it to do until the vote starts next
> week.
>

Thanks David! I will have to some time later today to answer some of
the open questions.

> Thanks for the comments and review so far,
> David

Re: Arbitrary abbreviations in phobos considered ridiculous


On 03/07/2012 10:47 PM, Jonathan M Davis wrote:

On Wednesday, March 07, 2012 15:34:44 Nick Sabalausky wrote:

"Jonathan M Davis"  wrote in message
news:mailman.180.1331149159.4860.digitalmar...@puremagic.com...


On Tuesday, March 06, 2012 21:56:38 H. S. Teoh wrote:

On Tue, Mar 06, 2012 at 07:48:37PM -0800, Jonathan M Davis wrote:

On Tuesday, March 06, 2012 19:35:29 Andrei Alexandrescu wrote:

In fact there is no such thing as a top level in D. (I was quite
surprised to learn that a few years ago, and found it quite
brilliant of Walter.)


True, but if names conflict, you then have to worry about using the
full import paths for symbols, which can get annoying.


[...]

I thought that's what module aliases were for.


They can help, but thanks to the fact that they impact any other modules
that
import that module, they're often unacceptable.


That's just an implementation bug, though, isn't it? And wasn't it recently
fixed?


It's a design issue. Yes, the bug that private didn't affect aliases was fixed,
but private does _not_ hide symbols. It only makes them inaccessible. So, for
instance, if std.datetime were to alias std.string.indexOf to indexOf, then
every module which imports both std.algorithm and std.datetime would then have
to either alias std.algorithm.indexOf themselves or use the full import path.
So, as it stands, private aliases are pretty much useless. It's just like how
private functions can affect function overloading in spite of the fact that
other modules can't use them.

This completely follows how private is designed. So, it's not a bug. But there
are definitely arguments for changing how private works (e.g. the fact that you
can't really alias stuff within a module without affecting other modules). The
trick is convincing Walter to change it.

- Jonathan M Davis


There is absolutely no remotely valid argument against changing the 
behavior that does not involve a discussion of the compiler internals.

Re: Review of Jose Armando Garcia Sancio's std.log

2012-03-07 Thread David Nadlinger

On Monday, 13 February 2012 at 15:50:05 UTC, David Nadlinger 
wrote:
Barring any objections, the review period starts now and ends 
in three weeks, on March 6th, followed by a week of voting.


Okay, everyone, by the original schedule, the review period would 
have ended yesterday. However, I don't think it makes sense to 
start a vote right now, where several points are actively 
discussed.


After discussing the situation with Jose, I think the best option 
is to extend the review period for another few days, until next 
Monday. Jose will try to answer any open comments so everybody 
can get a good idea of what the library does and what others 
expect it to do until the vote starts next week.


Thanks for the comments and review so far,
David

Re: Arbitrary abbreviations in phobos considered ridiculous

On Wednesday, March 07, 2012 15:34:44 Nick Sabalausky wrote:
> "Jonathan M Davis"  wrote in message
> news:mailman.180.1331149159.4860.digitalmar...@puremagic.com...
> 
> > On Tuesday, March 06, 2012 21:56:38 H. S. Teoh wrote:
> >> On Tue, Mar 06, 2012 at 07:48:37PM -0800, Jonathan M Davis wrote:
> >> > On Tuesday, March 06, 2012 19:35:29 Andrei Alexandrescu wrote:
> >> > > In fact there is no such thing as a top level in D. (I was quite
> >> > > surprised to learn that a few years ago, and found it quite
> >> > > brilliant of Walter.)
> >> > 
> >> > True, but if names conflict, you then have to worry about using the
> >> > full import paths for symbols, which can get annoying.
> >> 
> >> [...]
> >> 
> >> I thought that's what module aliases were for.
> > 
> > They can help, but thanks to the fact that they impact any other modules
> > that
> > import that module, they're often unacceptable.
> 
> That's just an implementation bug, though, isn't it? And wasn't it recently
> fixed?

It's a design issue. Yes, the bug that private didn't affect aliases was fixed, 
but private does _not_ hide symbols. It only makes them inaccessible. So, for 
instance, if std.datetime were to alias std.string.indexOf to indexOf, then 
every module which imports both std.algorithm and std.datetime would then have 
to either alias std.algorithm.indexOf themselves or use the full import path. 
So, as it stands, private aliases are pretty much useless. It's just like how 
private functions can affect function overloading in spite of the fact that 
other modules can't use them.

This completely follows how private is designed. So, it's not a bug. But there 
are definitely arguments for changing how private works (e.g. the fact that you 
can't really alias stuff within a module without affecting other modules). The 
trick is convincing Walter to change it.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous


On 03/07/2012 09:04 PM, foobar wrote:

On Wednesday, 7 March 2012 at 10:08:53 UTC, Timon Gehr wrote:

On 03/06/2012 10:30 PM, deadalnix wrote:


auto helps too.


This remark was explicitly about _Java_ code style.


Wrong. This is an issue with the *language*, NOT the naming convention.


It is hard to imagine how it could be concluded that this is not what 
the post has expressed.

Re: Review of Jose Armando Garcia Sancio's std.log

2012-03-07 Thread kennytm

"Richard van Scheijen"  wrote:
> When logging the severity level should convey a certain insight that the
> developer has about the code. This can be done with a 3 bit field. These
> are: known-cause, known-effect and breaks-flow.
> 
> This creates the following matrix:
> 
> KC KE BF Severity
> =
> 1  1  0  Trace
> 0  1  0  Info
> 1  0  0  Notice
> 0  0  0  Warning
> 1  1  1  Error
> 0  1  1  Critical
> 1  0  1  Severe
> 0  0  1  Fatal
> 

Minor nit: if you rearrange it as

AllowFlow / KnownEffect / KnownCause

Then the description will correspond exactly to their integer values. 

111 (7) = Trace
110 (6) = Info
101 (5) = Notice
100 (4) = Warning
011 (3) = Error
010 (2) = Critical
001 (1) = Severe
000 (0) = Fatal

> A known cause is when the developer knows why a log event is made. e.g.:
> if you cannot open a file, you do not know why.
> A known effect is when he/she knows what happens after. Basically, you
> can tell if it is a catch-all by this flag.
> 
> When a severity should only be handled by a debugger, the normal debug
> statement should be used. This is in essence a 4th bit.
> 
> I hope this helpful in the search for a good level system.

Re: Arbitrary abbreviations in phobos considered ridiculous

"Jonathan M Davis"  wrote in message 
news:mailman.180.1331149159.4860.digitalmar...@puremagic.com...
> On Tuesday, March 06, 2012 21:56:38 H. S. Teoh wrote:
>> On Tue, Mar 06, 2012 at 07:48:37PM -0800, Jonathan M Davis wrote:
>> > On Tuesday, March 06, 2012 19:35:29 Andrei Alexandrescu wrote:
>> > > In fact there is no such thing as a top level in D. (I was quite
>> > > surprised to learn that a few years ago, and found it quite
>> > > brilliant of Walter.)
>> >
>> > True, but if names conflict, you then have to worry about using the
>> > full import paths for symbols, which can get annoying.
>>
>> [...]
>>
>> I thought that's what module aliases were for.
>
> They can help, but thanks to the fact that they impact any other modules 
> that
> import that module, they're often unacceptable.
>

That's just an implementation bug, though, isn't it? And wasn't it recently 
fixed?

Re: Arbitrary abbreviations in phobos considered ridiculous

"Andrej Mitrovic"  wrote in message 
news:mailman.179.1331149059.4860.digitalmar...@puremagic.com...
> On 3/7/12, H. S. Teoh  wrote:
>> The human brain is highly capable of inferring intention from context
>
> I don't think our brains should be wasted on decyphering
> abbreviations. Too much abbreviations could drive a sane person nuts.

Yes, but OTOH, too much fully-spelled-out stuff makes code much harder to 
read (even without going as far as the Java extreme). Good use of common 
abbreviations is easier to read than full words. For example, "i18n". Or 
"5*2" instead of "five times two". No decyphering is needed at all with good 
common abbreviations, and they decrease verbosity which improves 
readability.

Re: Arbitrary abbreviations in phobos considered ridiculous


On Wednesday, 7 March 2012 at 10:08:53 UTC, Timon Gehr wrote:

On 03/06/2012 10:30 PM, deadalnix wrote:


auto helps too.


This remark was explicitly about _Java_ code style.


Wrong. This is an issue with the *language*, NOT the naming 
convention.

Re: Arbitrary abbreviations in phobos considered ridiculous


On Tuesday, 6 March 2012 at 18:36:08 UTC, Adam D. Ruppe wrote:

On Tuesday, 6 March 2012 at 18:06:46 UTC, H. S. Teoh wrote:

I have to disagree on this one.


If it was actually
"gratuitouslyOverlongFullySpelledOutVariableNames" I might
agree, but curr vs current is a whole other story.

Abbreviating a concept makes sense: i, j, rather than
iterationIndex or whatever. You might say "std.random.uniform"
rather than "randomNumberFromASetWithAUniformDistribution".

But, abbreviating /words/ is where it gets silly.
"rndNumSetUniDist" is a worse name than the long one,
since not only is it verbose, it has bizarre abbreviations
to remember too!

"dur" is the same concept as "duration"; it isn't a simpler
name. It isn't even significantly shorter. The biggest
difference is it isn't my first guess.


The fault is with inconsistency, not with abbreviations.


It is some of both: inconsistency with words I already
know (regular English) is what leads to the first guess
being wrong.


vote +infinity * 2
The most important point IMO - abbreviate concepts, not words.

Re: Arbitrary abbreviations in phobos considered ridiculous


On Tuesday, 6 March 2012 at 18:22:03 UTC, deadalnix wrote:

Le 06/03/2012 19:08, H. S. Teoh a écrit :

On Tue, Mar 06, 2012 at 05:38:09PM +0100, Adam D. Ruppe wrote:

One of the stumbling blocks on using std.datetime is how
many bizarre abbreviations it has.

auto time = Clock.currentTime(); // bzzt, wrong

if(time - something>  duration!"hours"(4)) // bzzt, wrong

writeln(time.toISOExtendedString()); // bzzt, wrong, but this 
used

to work!



Why aren't we using real words here? Real words are easier
to remember and easier to type.

[...]

I have to disagree on this one. One of the reasons I hate Java 
so much
is because of its 
gratuitouslyOverlongFullySpelledOutVariableNames.


Let me stop you just here.

Name come in a context. Hence variable names are in a function, 
that is in a class, that is in a package, that is in another 
package, ..., that is in a project.


If you need a very long name to cite something, it doesn't 
means that it should be abbreviated. It means that it is in the 
wrong place and you need to refactor.


When you come up with such a variable name, the code is telling 
you something. « Hey dude, stop here what you do, refactor and 
put that stuff in a convenient place before continuing ! »


Unfortunately, many dev understands it as « Hey, this name is 
too long, let use an abbreviation ! ». No you have fucked up 
variable name in a fucked software architecture.


This happen a lot in java. But remember, 90% of everything is 
crap.


I fully agree. More over, Java's verbosity problem often comes 
from redundant repetitions in the language itself such as:
MyWonderfulClass instance = new MyWonderfulClass(); // class name 
repeated


The Java/C# naming conventions themselves are wonderfully 
consistent and easy to remember/type (especially in an IDE like 
Eclipse that knows to match "MWC" to the "MyWonderfulClass").
I honestly believe that people who use horrible C/Unix like 
conventions should not be allowed to touch a keyboard.


At my previous work I had the "pleasure" to use legacy code in C 
and Fortran. One time I needed to figure out how to do something 
and was pointed to an ancient function who's name was an 
undecipherable 5 letter abbreviation,  probably written by 
someone who retired long ago. luckily it had comments, *but* the 
comments themselves were also fucking abbreviated! This is truly 
the most evil way to torture future junior programmers who will 
be unfortunate enough to inherit your code.


So no, abbreviations are *NOT* acceptable. Haven't we suffered 
enough?

Re: Arbitrary abbreviations in phobos considered ridiculous

On Tuesday, March 06, 2012 21:56:38 H. S. Teoh wrote:
> On Tue, Mar 06, 2012 at 07:48:37PM -0800, Jonathan M Davis wrote:
> > On Tuesday, March 06, 2012 19:35:29 Andrei Alexandrescu wrote:
> > > In fact there is no such thing as a top level in D. (I was quite
> > > surprised to learn that a few years ago, and found it quite
> > > brilliant of Walter.)
> > 
> > True, but if names conflict, you then have to worry about using the
> > full import paths for symbols, which can get annoying.
> 
> [...]
> 
> I thought that's what module aliases were for.

They can help, but thanks to the fact that they impact any other modules that 
import that module, they're often unacceptable.

- Jonathan m Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-07 Thread Andrej Mitrovic

On 3/7/12, H. S. Teoh  wrote:
> The human brain is highly capable of inferring intention from context

I don't think our brains should be wasted on decyphering
abbreviations. Too much abbreviations could drive a sane person nuts.
E.g.:

http://lolcats.icanhascheezburger.com/2012/03/07/funny-cat-pictures-ai-is-not-shy/#comments

All is good with moderation though. :p

Re: NNTP rules, news.digitalmars.com sucks

2012-03-07 Thread Gour

On Wed, 7 Mar 2012 07:59:10 -0800
"H. S. Teoh"  wrote:

> ROTFLMAO!!! That would certainly be the day, when D forums can lay
> claims to being the largest NNTP community online. That would be when
> D takes over the world. :D

Well, at the moment digitalmars.D is the biggest newsgroup (number of
messages) which I follow with wxwidgets-devel being the 2nd one.


Sincerely,
Gour


-- 
All the liberated souls in ancient times acted with this 
understanding of My transcendental nature. Therefore you should 
perform your duty, following in their footsteps.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature

Re: Arbitrary abbreviations in phobos considered ridiculous

On Wednesday, March 07, 2012 08:47:48 Steven Schveighoffer wrote:
> On Tue, 06 Mar 2012 12:09:47 -0500, Andrej Mitrovic
> 
>  wrote:
> > I'll never forgive std.datetime for this mistake:
> > 
> > auto sw = StopWatch(AutoStart.yes);
> > writeln(sw.peek.hnsecs);
> > writeln(sw.peek.nsecs);
> > writeln(sw.peek.usecs);
> > writeln(sw.peek.msecs);
> > writeln(sw.peek.secs); // bz NOPE
> > writeln(sw.peek.seconds);
> > 
> > I misspell this thing every single time I use stopwatch to count seconds.
> 
> this is a no-brainer:
> 
> Duration dur(string units)(long length) @safe pure nothrow
> if(units == "weeks" ||
> units == "days" ||
> units == "hours" ||
> units == "minutes" ||
> units == "seconds" ||
> units == "secs" || // added
> units == "msecs" ||
> units == "usecs" ||
> units == "hnsecs" ||
> units == "nsecs")
> {
> return Duration(convert!(units, "hnsecs")(length));
> }
> 
> // etc, everywhere "seconds" is used, add "secs" as well.
> 
> I'll see if I can do a pull request.

I've avoided that primarily because it results in inconsistent code. It's 
pretty much equivalent to adding extraneous aliases, though it's not as bad, 
since it's not a general symbol. But if it's a sufficient usability 
improvement, 
then maybe it's a good idea.

- Jonathan M Davis

Re: Is it bad for object.di to depend on core.exception?

On Sun, Mar 04, 2012 at 07:31:49AM +0100, Martin Nowak wrote:
> Wasn't the latest proposal that we add a working AA implementation to
> the runtime and switch the compiler after that has settled?

Is somebody working on that? If not, I may take a crack at doing it.

And by runtime you mean object_.d, right? aaA.d is already part of
druntime, from what I understand. :-)

T

-- 
If it breaks, you get to keep both pieces. -- Software disclaimer notice

Re: Arbitrary abbreviations in phobos considered ridiculous

On Wed, Mar 07, 2012 at 01:50:03PM -0500, Nick Sabalausky wrote:
> "Jacob Carlborg"  wrote in message 
> news:jj74p4$n9r$3...@digitalmars.com...
> > On 2012-03-07 03:18, Nick Sabalausky wrote:
[...]
> >> I say fuck it: Let's just toss this into core.time (or std.datetime
> >> or whatever) and be done:
> >>
> >> alias dur!"years" years;
> >> alias dur!"months" months;
> >> alias dur!"weeks" weeks;
> >> alias dur!"days" days;
> >> alias dur!"hours" hours;
> >> alias dur!"minutes" minutes;
> >> alias dur!"seconds" seconds;
> >> alias dur!"msecs" msecs;
> >> alias dur!"usecs" usecs;
> >> alias dur!"hnsecs" hnsecs;
> >>
> >> And then we have the brevity issue solved (and in fact, improved
> >> over "dur"), so then "dur" can (and should) change to "duration"
> >> without screwing up brevity. And all probelms are optimally solved.
> >> As for the possibility of new name collisions: Honestly, in this
> >> case I see no reason to give a shit.
> >
> > I agree, adding these aliases would be a good idea.
> >
> 
> I like that so many people agree with this. But I do want to point out
> again, just in case anyone missed it, that I'm hoping it would
> *actually* be:
> 
> alias duration!"years" years;
> alias duration!"months" months;
> etc...
> 
> Since the aliases themselves mitigate the need for "duration" itself to be 
> shortened.

+1.

> Course, I can still live with just 'alias dur!"years" years;..etc...'.
> The *main* thing is that we can just do "hours(5)"...(or heck, once
> UFCS finally gets fixed: "5.hours")
[...]

Hooray! Ruby syntax FTW!

Tangential comment:

Before I discovered D, Ruby was among the top candidates in my list of
programming languages close to my ideals. Once D pulls off UFCS, it will
trump Ruby in so many more ways... such as being able to effectively
extend class methods just by declaring module-level functions of the
form:

retType func(classname obj, ...);

(which I believe is already (somewhat?) supported). Among many other
things.

Supporting stuff like 5.hours will introduce additional complications to
D's lexical structure, though. The lexer will have to understand it as
(int:5)(.)(ident:hours) rather than (float:5.)(ident:hours). And then if
you actually *wanted* a float, you'd have another ambiguity: 5..hours
could mean (float:5.)(.)(ident:hours) or (int:5)(..)(hours). And
5.0.hours just looks... weird.

T

-- 
"How are you doing?" "Doing what?"

Re: dereferencing null

On Wednesday, March 07, 2012 07:55:35 H. S. Teoh wrote:
> It's not that the null pointer itself corrupts memory. It's that the
> null pointer is a sign that something may have corrupted memory *before*
> you got to that point.
> 
> The point is, it's impossible to tell whether the null pointer was
> merely the result of forgetting to initialize something, or it's a
> symptom of a far more sinister problem. The source of the problem could
> potentially be very far away, in unrelated code, and only when you tried
> to access the pointer, you discover that something is wrong.
> 
> At that point, it may very well be the case that the null pointer isn't
> just a benign uninitialized pointer, but the result of a memory
> corruption, perhaps an exploit in the process of taking over your
> application, or some internal consistency error that is in the process
> of destroying user data. Trying to continue is a bad idea, since you'd
> be letting the exploit take over, or allowing user data to get even more
> corrupted than it already is.

Also, while D does much more to protect you from stuff like memory corruption 
than C/C++ does, it's still a systems language. Stuff like that can definitely 
happen. If you're writing primarily in SafeD, then it's very much minimized, 
but it's not necessarily eliminated. All it takes is a bug in @system code 
which could corrupt memory, and voila, you have corrupted memory, and an @safe 
function could get a segfault even though it's correct code. It's likely to be 
a very rare occurrence, but it's possible. A since when you get a segfault, 
you can't know what caused it, you have to assume that it could have been 
caused by one of the nastier possibilites rather than a relatively benign one.

And since ultimately, your program should be checking for null before 
derefencing a variable in any case where it could be null, segfaulting due to 
dereferencing a null pointer is a program bug which should be caught in 
testing - like assertions in general are - rather than having the program 
attempt to recover from it. And if you do _that_, the odds of a segfault being 
due to something very nasty just go up, making it that much more of a bad idea 
to try and recover from one.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

On Wed, Mar 07, 2012 at 01:38:08PM -0500, Nick Sabalausky wrote:
> "Adam D. Ruppe"  wrote in message 
> news:sgmfyzmrfygshlmfq...@forum.dlang.org...
[[...]
> > But, either option is better than "Clr" or "Col".
> 
> "clr" is the verb "clear" and "col" is "column" :)
[...]

clr == common language runtime
col == polysemous word meaning anything from column to color to collect to 
colon.

;-)

Jokes aside, though I'm not suggesting we actually do this, I frankly
find Col an acceptable abbreviation for *both* "Color" and "Column",
because context usually makes it clear which one is meant. The human
brain is highly capable of inferring intention from context (which is
why function overloading is even remotely workable in the first place).
Witness, for example, the variety of meanings the word 'set' may have
depending on context. It's a horribly overloaded, overused, and
ambiguous word, objectively speaking. But we also use it every day
without even thinking twice, even in programming (e.g., set a variable
vs. a set of objects vs. an object of type Set vs. language rules set in
stone).

T

-- 
Truth, Sir, is a cow which will give [skeptics] no more milk, and so
they are gone to milk the bull. -- Sam. Johnson

Re: Arbitrary abbreviations in phobos considered ridiculous

"Jacob Carlborg"  wrote in message 
news:jj74p4$n9r$3...@digitalmars.com...
> On 2012-03-07 03:18, Nick Sabalausky wrote:
>> "Jonathan M Davis"  wrote in message
>> news:mailman.110.1331077432.4860.digitalmar...@puremagic.com...
>>> On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote:

 Nope, apparently, I meant "dur". Ridiculous.
>>>
>>> A Duration needs to be constructed with a template, and
>>> duration!"hours"(13),
>>> duration!"seconds"(44), etc. is painfully long when used in expressions.
>>> So,
>>> it was shortened to dur. I don't know of any other abbreviation which
>>> would
>>> make sense.
>>>
>>
>> This is exactly why "dur" never bothered me. Now that Adam's brought it 
>> up,
>> I can see how it can be considered bad, but at the same time
>> 'duration!"seconds"(44)' is a rather long to way to refer to x number of
>> seconds.
>>
>> But, I'm thinking this whole "dur vs duration" matter is stupid anyway.
>> Seconds, hours, etc *are* durations. What the hell do we even need the 
>> "dur"
>> or "duration" for anyway?
>>
>> I say fuck it: Let's just toss this into core.time (or std.datetime or
>> whatever) and be done:
>>
>> alias dur!"years" years;
>> alias dur!"months" months;
>> alias dur!"weeks" weeks;
>> alias dur!"days" days;
>> alias dur!"hours" hours;
>> alias dur!"minutes" minutes;
>> alias dur!"seconds" seconds;
>> alias dur!"msecs" msecs;
>> alias dur!"usecs" usecs;
>> alias dur!"hnsecs" hnsecs;
>>
>> And then we have the brevity issue solved (and in fact, improved over
>> "dur"), so then "dur" can (and should) change to "duration" without 
>> screwing
>> up brevity. And all probelms are optimally solved. As for the possibility 
>> of
>> new name collisions: Honestly, in this case I see no reason to give a 
>> shit.
>
> I agree, adding these aliases would be a good idea.
>

I like that so many people agree with this. But I do want to point out 
again, just in case anyone missed it, that I'm hoping it would *actually* 
be:

alias duration!"years" years;
alias duration!"months" months;
etc...

Since the aliases themselves mitigate the need for "duration" itself to be 
shortened.

Course, I can still live with just 'alias dur!"years" years;..etc...'. The 
*main* thing is that we can just do "hours(5)"...(or heck, once UFCS finally 
gets fixed: "5.hours")

Re: Arbitrary abbreviations in phobos considered ridiculous

On Wed, Mar 07, 2012 at 01:24:03PM -0500, Nick Sabalausky wrote:
[...]
> My thoughts on "secs vs seconds":
> 
> 1. I don't feel real strongly either way.
> 
> 2. I like the suggestion someone had of allowing both "secs" and
> "seconds".  Normally I'd be against accepting alternate names (except
> as a transitional phase leading up to the deprecation of one of them),
> but in this case I think it could work without causing too much
> trouble.
> 
> 3. Jonathan pointed out that both "secs" and "seconds" are
> inconsistent with other durations. He said that "seconds" was chosen
> to be consistent with "minutes", "hours", etc., and that the rule is
> sub-second durations use "*secs". After thinking about that, I've come
> to the conclusion that it's more important for seconds to be
> consistent with seconds. Ie, Having "msecs" and "seconds" is a more
> major inconsistency than having "secs" and "minutes" because with the
> former you have two different spellings of the *same* word: seconds.
[...]

I agree. This is one example of what I said about consistency. If we're
going to abbreviate "seconds" to "secs" at all, we should abbreviate
*all* instances to "secs".

While I understand Jonathan's explanation of the rule of durations
longer/shorter than seconds, that's not something that someone
unfamiliar with the system would expect. Picking seconds as the boundary
between spelling it "seconds" vs. "secs" seems arbitrary. Why not pick
hours as the dividing line instead? Make it years, days, hours, mins,
secs, msecs, ...  instead. Or why not days, since days can't be
reasonably abbreviated?  Years, days, hrs, mins, secs, msecs, 

I think the right thing to do is to consistently abbreviate seconds as
secs. As a compromise with the current state of affairs, alias "seconds"
to "secs", as Nick suggests above.

T

-- 
Don't get stuck in a closet---wear yourself out.

Re: Arbitrary abbreviations in phobos considered ridiculous

"Jacob Carlborg"  wrote in message 
news:jj755f$r7u$1...@digitalmars.com...
> On 2012-03-07 04:46, Nick Sabalausky wrote:
>> "Adam D. Ruppe"  wrote in message
>> news:bwqkuqhyiygvgqswi...@forum.dlang.org...
>>> On Wednesday, 7 March 2012 at 03:24:23 UTC, Jonathan M Davis wrote:
 I don't understand this complaint at all. curr is an incredibly common
 abbreviation for current.
>>>
>>> Is it your *first* choice?
>>
>> In the general case, it frequently is for me. In the specific case of
>> Clock.curr(ent)?Time, I'm equally happy either way. Although I agree with
>> whoever it was (Brad?) that said "Clock.now()" would be even better.
>>
>>
>
> Yeah, Clock.now() would be good and Data.today() as well.
>

I dunno, on the second one, I think I'd prefer "Date.today()" ;)

(Nyuk nyuk nyuk)

Re: Arbitrary abbreviations in phobos considered ridiculous

"Adam D. Ruppe"  wrote in message 
news:sgmfyzmrfygshlmfq...@forum.dlang.org...
> On Tuesday, 6 March 2012 at 20:20:47 UTC, Derek wrote:
>> Should we use American or English spelling? Color verses Colour, for 
>> example?
>
> I can go either way. I lean toward English spelling
> though, simply because America is the exceptional
> country (in the world and on the newsgroup too) in
> this regard.
>

British English may be the more "official" English, with American English as 
a mere variation, but AIUI, the "de facto international language" is 
American English, not British English, as a result of the US being a 
long-time major economic superpower (for better or worse). England used to 
be a major superpower, but that was centuries ago, and from what I can tell, 
American English seems to be the preferred "de facto standard" English now.

'Course, I'm in the US, so I may simply be biased just because, as an 
american, I do,  for example, prefer "color" over "colour". (OTOH, I think 
the word "lorry" is awesome. Not sure if I spelled it right, though.)

Speaking of...do the British actually pronounce colour with a "u" sound? If 
not, I'd argue "color" really is a better spelling ;) (Not as good as 
"kulr", but whatever)

> But, either option is better than "Clr" or "Col".

"clr" is the verb "clear" and "col" is "column" :)

Re: Arbitrary abbreviations in phobos considered ridiculous

"Marco Leise"  wrote in message 
news:op.waszojl09y6py2@marco-pc.local...
>
>I have used Java commercially in Eclipse and I have to make a point for the
>combination of IDE and language here. What you really *type* for that is 
>(
>meaning ctrl+space):
>
>SCVEFW  = new new
>;
>SCVE  = .;
>throw ;
>
>resulting in the following code:
>
>try {
>SqlConstraintViolatedExceptionFactoryWrapper 
>sqlConstraintViolatedExceptionFactoryWrapper = new
>SqlConstraintViolatedExceptionFactoryWrapper(new
>SqlConstraintViolatedExceptionFactory());
>SqlConstraintViolatedException sqlConstraintViolatedException =
>sqlConstraintViolatedExceptionFactoryWrapper.createSqlConstraintViolatedException
>();
>throw sqlConstraintViolatedException;
>} catch (SqlConstraintViolatedExceptionFactoryWrapperException e) {
>// TODO Auto-generated catch block
>e.printStackTrace();
>} catch (SqlConstraintViolatedExceptionFactoryException e) {
>// TODO Auto-generated catch block
>e.printStackTrace();
>}
>
>That is 72 key strokes instead of 519. So the spelling (as in typing) 
>itself is not a
>problem with camel-case auto-complete, variable name and type based
>parameter guessing.

Yea, but it's still unreadable, though. And even regarding the typing, 
that's really only applicable to Java since Java's the only language which 
pretty much everyone uses with an Eclipse-style IDE. And the only reason why 
everyone does that is because Java's completely unusable without it. Neither 
of those are applicable to D or pretty much *anything* other than Java.

>I tried to use "secs", at least two times. It is one of these cases where a
>minor annoyance adds up until someone eventually starts a rant about it.
>And a lot of people realize that they found the situation odd as well, but 
>not
>an issue. I can see the reasoning behind making templated functions short,
>as in "dur", but it is inconsistent with Duration and almost like foo() and
>bar) :)

My thoughts on "secs vs seconds":

1. I don't feel real strongly either way.

2. I like the suggestion someone had of allowing both "secs" and "seconds". 
Normally I'd be against accepting alternate names (except as a transitional 
phase leading up to the deprecation of one of them), but in this case I 
think it could work without causing too much trouble.

3. Jonathan pointed out that both "secs" and "seconds" are inconsistent with 
other durations. He said that "seconds" was chosen to be consistent with 
"minutes", "hours", etc., and that the rule is sub-second durations use 
"*secs". After thinking about that, I've come to the conclusion that it's 
more important for seconds to be consistent with seconds. Ie, Having "msecs" 
and "seconds" is a more major inconsistency than having "secs" and "minutes" 
because with the former you have two different spellings of the *same* word: 
seconds.

Re: D Wiki - Why is it in such shambles?

2012-03-07 Thread Andrej Mitrovic

On 3/7/12, Brad Anderson  wrote:
> - Do we even want a moderated wiki? Given the current state of the wiki it
> could be a good thing but given the current rate of pull request merging it
> could be a bad thing.

FWIW pull requests for dpl.org seem to be merged much faster than
pulls for phobos/dmd. There are still a few pulls left that are quite
old, but these are either waiting for implementation changes or still
have some bugs that need fixing.

Personally I'd wholeheartedly welcome an integrated wiki to the site,
having all information in one place is great for newcomers, and we
would finally have an incentive to reorganize and update information
from the old wiki.

Re: D Wiki - Why is it in such shambles?

2012-03-07 Thread Brad Anderson

On Wed, Mar 7, 2012 at 8:33 AM, Justin C Calvarese
wrote:

> On Wednesday, 7 March 2012 at 14:43:59 UTC, Bruno Medeiros wrote:
>
>> On 03/03/2012 01:55, Jesse Phillips wrote:
>>
>>> On Friday, 2 March 2012 at 14:49:54 UTC, Robert Rouse wrote:
>>>
 I'm relatively new to D, so I'm looking at everything I can. The D
 wiki linked from the D site has so much outdated information and
 entries that are more talk pages than actual entries (e.g.
 http://prowiki.org/wiki4d/**wiki.cgi?ComingFrom/Ruby)

 If that wiki is not the best place to go for information (besides the
 newsgroup), what is?

>>>
>>> If you do not find the page helpful, please delete it/remove the
>>> reference to it. The wiki works best when someone is willing to
>>> make it better, and removing useless information is part of that.
>>>
>>
>> That's a tricky thing to do. While it's easy to add new information to
>> the wiki, removing it is not as clear-cut: it requires someone to be able
>> to determine that information is outdated/incorrect/obsolete, and to be
>> able to correct it (in case the correction is not as simple as deleting,
>> but rather fixing some entry). And even so, unless the error in the
>> information is glaring, people might be reticent to do it, as it implies
>> "interfering" with someone else's work, and one does not always know if
>> that is appropriate.
>>
>> I also generally agree it would be better to have some sort of process
>> set up around the wiki. Curate it in some way, or have a more managed,
>> distilled version, that would be of use for newcomers. Indeed, it seems to
>> me there is an important separation between some pages, those that are more
>> discussion like, or more relevant only to experienced/involved members of
>> the D community, and other pages which are quite important for beginners
>> (like the Editors page and others linked from dlang.org), to offer a
>> Getting-Started kind of information.
>>
>
> Responding as someone who used to be much more involved in the D Wiki (I
> don't do much anymore due to having less time available), I think that a
> new wiki should be set up as a dlang.org subdomain. We don't have to
> write the wiki software in D, we could use a popular existing package (such
> as MediaWiki, Trac, GitHub, etc.). I'm sure we could generate a centithread
> of discussion about the pros and cons of different wiki software.
>
> The current wiki was generously set up by an individual who donated server
> space and wiki software for the D community to use many years ago, but I
> don't believe that person would be offended if we migrated to another
> system. We should only migrate the most important pages first (and as we
> migrate pages, we could indicate on the old page where the new page is).
> We'd only migrate pages that are already largely up-to-date and that we
> intend to maintain. The less useful pages would probably never get migrated
> to the new site, but the information on those pages may still be of use to
> someone on the old site.
>
> As someone who created many of these pages that are now outdated or
> obsolete, I'd hate to see them all disappear due to a wave of deletionism
> from newer members of the D community who have more time for deleting than
> updating.
>
> That's my idea, but I don't have time to implement it myself (I would be
> willing to help), but maybe someone else will get inspired to make
> something like this happen.
>
> jcc7
>

One option, and I don't even know how I feel about this, could actually
make it powered by D (Ddoc specifically).  I have a pull request <
https://github.com/D-Programming-Language/d-programming-language.org/pull/98>
which enables website pages to be edited and a pull request made all online
(it's basically a moderated wiki).

Extending that by creating a wiki repository with appropriate moderators
and adding that to the website is how it'd probably work.  Anyone with a
github account could modify pages. One nice thing is that it'd match the
look and feel of the current website and would easily integrate with all
sections of it.  Syntax highlighting would work and references to
documentation would be trivial.

There are issues though.
- Do we even want a moderated wiki? Given the current state of the wiki it
could be a good thing but given the current rate of pull request merging it
could be a bad thing.
- It would require frequent ddoc generation and deployment by someone
(Andrei, from my understanding of website deployment).  A script could
probably be written to monitor for commits and do this automatically but
it's certainly more complicated than an off the shelf wiki.
- Not many people actually know ddoc syntax.  It's not that complicated to
figure out but it's something to keep in mind.
- New pages could not be created using the online editor.  You'd have to
clone the repository and add the new page by hand.

Anyway, it's just something I thought I

Re: NNTP rules, news.digitalmars.com sucks

2012-03-07 Thread Vladimir Panteleev

On Wednesday, 7 March 2012 at 13:01:48 UTC, Steven Schveighoffer 
wrote:
Do you mean a well known NNTP problem or just for our 
newsgroups?


Just the DigitalMars NNTP server. The server will refuse to 
accept new connections when the system load is above a certain 
threshold.

Re: NNTP rules, news.digitalmars.com sucks

On Wed, Mar 07, 2012 at 08:01:48AM -0500, Steven Schveighoffer wrote:
> On Tue, 06 Mar 2012 05:30:00 -0500, Vladimir Panteleev
>  wrote:
> 
> >On Tuesday, 6 March 2012 at 10:22:15 UTC, Gour wrote:
> >>On Mon, 05 Mar 2012 17:33:24 -0500
> >>"Steven Schveighoffer"  wrote:
> >>
> >>>Is this a common problem with news servers?  Is there some way to fix
> >>>this?
> >>
> >>I regularly post to news groups from my mailer (Claws) and never had a
> >>single problem like you quoted above.
> >
> >That only means you don't post enough ;)
> >
> >It's a problem well-known by regulars.
> 
> Do you mean a well known NNTP problem or just for our newsgroups?

This:

> I'd be crazy to think that digitalmars is the largest online NNTP
> community ever, right?

ROTFLMAO!!! That would certainly be the day, when D forums can lay
claims to being the largest NNTP community online. That would be when D
takes over the world. :D


> I wouldn't know, because this is the only newsgroup I use...
[...]

D newsgroups are really tame and low-volume, in comparison with the rest
of Usenet. And I mean, really, really, REALLY tame. There's some crazy
wild stuff going on out there in Usenet land.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- 
Christopher

Re: Review of Jose Armando Garcia Sancio's std.log

2012-03-07 Thread Dmitry Olshansky


On 07.03.2012 16:34, Steven Schveighoffer wrote:

On Wed, 07 Mar 2012 02:33:05 -0500, Dmitry Olshansky
 wrote:


Exception is a graceful shutdown, as it calls destructors & finally
blocks while unrolling the stack.


You're assuming the program uses finally/scope exit blocks to do
shutdown logic. This is not always the case. A library shouldn't force
certain development styles.



I do and within the reason. Doing graceful shutdown logic in 
scope/finally/destructors or what the heck the top-most catch(Exception) 
is not just a good practice. Otherwise an unexpected exception on the 
way up leaves debris and destruction behind, and the whole point of 
graceful shutdown is lost.
Yup, one can provide an alternative way of shutdown, yet one still has 
to think of unexpected exceptions.



--
Dmitry Olshansky

Re: dereferencing null

On Wed, Mar 07, 2012 at 09:22:27AM -0500, Chad J wrote:
> On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:
[...]
> >However, there are several causes of seg faults:
> >
> >1. You forgot to initialize a variable.
> >2. Your memory has been corrupted, and some corrupted pointer now
> >points into no-mem land.
> >3. You are accessing memory that has been deallocated.
> >
> >Only 1 is benign. 2 and 3 are fatal. Since you cannot know which of
> >these three happened, the only valid choice is to terminate.
> >
> >I think the correct option is to print a stack trace, and abort the
> >program.
> >
> 
> Alright, I think I see where the misunderstanding is coming from.
> 
> I have only ever encountered (1).  And I've encountered it a lot.
> 
> I didn't even consider (2) and (3) as possibilities.  Those are far
> from my mind.
> 
> I still have a nagging doubt though: since the dereference in
> question is null, then there is no way for that particular
> dereference to corrupt other memory.  The only way this happens in
> (2) and (3) is that related code tries to write to invalid memory.
> But if we have other measures in place to prevent that (bounds
> checking, other hardware signals, etc), then how is it still
> possible to corrupt memory?
[...]

It's not that the null pointer itself corrupts memory. It's that the
null pointer is a sign that something may have corrupted memory *before*
you got to that point.

The point is, it's impossible to tell whether the null pointer was
merely the result of forgetting to initialize something, or it's a
symptom of a far more sinister problem. The source of the problem could
potentially be very far away, in unrelated code, and only when you tried
to access the pointer, you discover that something is wrong.

At that point, it may very well be the case that the null pointer isn't
just a benign uninitialized pointer, but the result of a memory
corruption, perhaps an exploit in the process of taking over your
application, or some internal consistency error that is in the process
of destroying user data. Trying to continue is a bad idea, since you'd
be letting the exploit take over, or allowing user data to get even more
corrupted than it already is.

T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you 
wish you hadn't.

Re: Review of Jose Armando Garcia Sancio's std.log

2012-03-07 Thread David Gileadi

On 3/6/12 5:39 PM, H. S. Teoh wrote:

I don't like the current state of dlang.org docs either. There is little
or no intro paragraph to explain what on earth the module is used for or
why you should bother reading the rest of the page for the next hour or
so. It also doesn't give any motivating examples (I'm thinking of
std.range here) why this module is useful.

I think a good intro is a must to good documentation. Include some code
snippets to show typical usage of the module. How to change common
settings. Some explanation of why the user might find the module
helpful. It's OK to duplicate some docs here, within reason. It should
also be concise without being uninformative.

For example (from std.range):

This module defines the notion of range (by the membership tests
isInputRange, isForwardRange, isBidirectionalRange,
isRandomAccessRange), range capability tests (such as hasLength
or hasSlicing), and a few useful range incarnations.

is concise, but not very informative. Why should the user care what a
range is anyway? No explanation is given. Something like this may be a
beginning to better documentation:

This module defines the notion of a range. Ranges generalize the
concept of arrays, lists, or anything that involves sequential
access. This abstraction enables the same set of algorithms (see
std.algorithm) to be used with a vast variety of different
concrete types. For example, a linear search algorithm such as
std.find works not just for arrays, but for linked-lists, input
files, incoming network data, etc..

This module defines several templates ()for testing whether a given object is a range, and what
kind of range it is.

It also lets you construct new ranges out of existing ranges.
For example, retro lets you access a bidirectional range in
reverse, cycle creates a range that is an endless repetition of
the original range. ...

...

Basically, you're writing an overview to the module, so highlight its
main components, give some insight into why it's useful, etc., so that
the user can make sense of the long list of declarations that follow.

As it stands, std.range's page consists of a giant list of range-related
declarations that gives no hint to the user as to how they all fit
together. You basically have to wade through it until it somehow all
"clicks" together. That is poor documentation. The overview should give
some general categories of stuff that's found in the module (e.g. range
tests, constructing new ranges, etc., as I've tried to do above in my
one-shot attempt to improve std.range's docs). Include some examples of
really clever stuff that you can do with the help of the module. Such
examples are usually a very good way to get the user up-to-speed with
what the module has to offer.

I strongly agree, particularly in the case of ranges which are not a
familiar concept to many, but also with the general principle.

Re: inout and function/delegate parameters


On Tue, 06 Mar 2012 05:11:34 -0500, Timon Gehr  wrote:


On 03/06/2012 12:27 AM, Steven Schveighoffer wrote:
...


There are two parts to inout, one is that it can be one function called
3 different ways, the other is that you know it's constant during
function execution. Some people like that second part, even if it
doesn't fully guarantee everything. I.e. there's a reason people use
const in C++ besides it being trendy.



By passing a delegate that changes an inout-matched argument it is made  
explicit that inout data may change. Technically, none of the existing  
guarantees are lost, we just add some expressiveness to the type system.


Yes, I understand that it works.  I know that it doesn't violate  
technically any const guarantees.


In fact, I think this is valid D code:

int i;
const int *pi = &i;
int *p = cast()pi;
*p = 5; // legal because I know this points at i, and i is really mutable

But from an API point of view, I look at at inout as guaranteeing anything  
the parameter points at won't change while inside the function *using that  
parameter*.  Even though it's legal, it's disingenuous (at least as long  
as we define inout that way).


An interesting side note is that inout (if designed in this way) can allow  
the above code snippit to be modularized.








I'm not saying we cannot bend the rules to allow for this, because
clearly it doesn't violate the "true" constancy type of the data  
passed

in, but I don't think it's a straightforward change conceptually. I'm
not a compiler writer, so I don't know how this works in their minds,
I'd like to have their input.


Implementation of what you propose should be quite simple. The issue
is with the design, i.e. allowing both tying the inout in the delegate
parameter signature to the inout in the enclosing signature and having
an independent inout delegate parameter needs workable syntax.


I think it can be done:

1. determine inout match based on existing rules, excluding delegate
parameters.
2. change delegate parameter inouts to matched value.
3. Use implicit delegate conversion (using contravariance) to allow
passing delegates of proper type.

For example:

void foo(inout(int)* x, void delegate(inout(int)* y) dg);

void main()
{
int mx;
immutable int ix;
const int cx;

void bar1(int *mp) {}
void bar2(immutable(int) *ip) {}
void bar3(const(int) *cp) {}
void bar4(inout(int) *iop) {}

// inout matched as mutable due to mx, signature becomes void foo(int
*x, void delegate(int *y) dg);
foo(&mx, &bar1); // fine, direct match of both parameters
foo(&mx, &bar2); // not fine, immutable delegate does not implicitly
convert to mutable
foo(&mx, &bar3); // fine, const delegate can implicitly convert to  
mutable
foo(&mx, &bar4); // fine, inout delegate can implicitly convert to  
mutable


// signature becomes void foo(immutable(int) *x, void
delegate(immutable(int) *y) dg);
foo(&ix, &bar1); // error
foo(&ix, &bar2); // ok
foo(&ix, &bar3); // fine, const delegate can implicitly convert to
immutable
foo(&ix, &bar4); // fine, inout delegate can implicitly convert to
immutable

// signature becomes void foo(const(int) *x, void delegate(const(int)
*y) dg);
foo(&cx, &bar1); // error
foo(&cx, &bar2); // error
foo(&cx, &bar3); // ok
foo(&cx, &bar4); // ok

// etc...
}


I understand, but how would you support this use case?:

inout(int)[] foo(inout(int)[] delegate(inout(int)[] dg), inout(int)[]  
arr){

 int[] x = dg(new int[16]);
 immutable(int)[] y = dg(new immutable(int)[16]);
 // ...
 inout(int)[] z = dg(arr);
 return foo(z,y,z);
}


As usual, you find and poke holes in all my arguments :)  I'm thinking  
that in order to make this work we need a way to specify an inout modifier  
really represents the matched type rather than a full-fledged inout  
parameter.


This is not a good thing -- inout is already pretty weird and hard to  
understand.


Need to do some more thinking, maybe there's an easy way.


Note that Walter has explicitly rejected contravariance conversion for
delegates.


That is unfortunate.


You have good persuasive skills, maybe you can help :) See
bug http://d.puremagic.com/issues/show_bug.cgi?id=3180 and
http://d.puremagic.com/issues/show_bug.cgi?id=3075



IIRC Kenji Hara has already started attempts to loosen the restrictions  
regarding delegate implicit conversions. Hopefully Walter will  
reconsider.


I hope so.  This is a vastly awesome untapped low-hanging fruit.

-Steve

Re: John Carmack applauds D's pure attribute

On Wed, Mar 07, 2012 at 02:26:28AM -0800, Walter Bright wrote:
> On 3/6/2012 9:59 PM, Sean Kelly wrote:
> >Slice ten bytes out of the middle of a ten MB buffer and the entire
> >buffer sticks around.
[...]

Isn't there some way of dealing with this? I mean, if the GC marks the
highest & lowest pointers that point to a 10MB block, it should be able
to free up the unused parts. (Though I can see how this can be tricky,
since the GC would have to understand which pointers involve arrays, so
that it doesn't truncate long slices, etc.).

T

-- 
Marketing: the art of convincing people to pay for what they didn't need
before which you can't deliver after.

Re: D Wiki - Why is it in such shambles?

2012-03-07 Thread Justin C Calvarese


On Wednesday, 7 March 2012 at 14:43:59 UTC, Bruno Medeiros wrote:

On 03/03/2012 01:55, Jesse Phillips wrote:

On Friday, 2 March 2012 at 14:49:54 UTC, Robert Rouse wrote:
I'm relatively new to D, so I'm looking at everything I can. 
The D
wiki linked from the D site has so much outdated information 
and

entries that are more talk pages than actual entries (e.g.
http://prowiki.org/wiki4d/wiki.cgi?ComingFrom/Ruby )

If that wiki is not the best place to go for information 
(besides the

newsgroup), what is?


If you do not find the page helpful, please delete it/remove 
the

reference to it. The wiki works best when someone is willing to
make it better, and removing useless information is part of 
that.


That's a tricky thing to do. While it's easy to add new 
information to the wiki, removing it is not as clear-cut: it 
requires someone to be able to determine that information is 
outdated/incorrect/obsolete, and to be able to correct it (in 
case the correction is not as simple as deleting, but rather 
fixing some entry). And even so, unless the error in the 
information is glaring, people might be reticent to do it, as 
it implies "interfering" with someone else's work, and one does 
not always know if that is appropriate.


I also generally agree it would be better to have some sort of 
process set up around the wiki. Curate it in some way, or have 
a more managed, distilled version, that would be of use for 
newcomers. Indeed, it seems to me there is an important 
separation between some pages, those that are more discussion 
like, or more relevant only to experienced/involved members of 
the D community, and other pages which are quite important for 
beginners (like the Editors page and others linked from 
dlang.org), to offer a Getting-Started kind of information.


Responding as someone who used to be much more involved in the D 
Wiki (I don't do much anymore due to having less time available), 
I think that a new wiki should be set up as a dlang.org 
subdomain. We don't have to write the wiki software in D, we 
could use a popular existing package (such as MediaWiki, Trac, 
GitHub, etc.). I'm sure we could generate a centithread of 
discussion about the pros and cons of different wiki software.


The current wiki was generously set up by an individual who 
donated server space and wiki software for the D community to use 
many years ago, but I don't believe that person would be offended 
if we migrated to another system. We should only migrate the most 
important pages first (and as we migrate pages, we could indicate 
on the old page where the new page is). We'd only migrate pages 
that are already largely up-to-date and that we intend to 
maintain. The less useful pages would probably never get migrated 
to the new site, but the information on those pages may still be 
of use to someone on the old site.


As someone who created many of these pages that are now outdated 
or obsolete, I'd hate to see them all disappear due to a wave of 
deletionism from newer members of the D community who have more 
time for deleting than updating.


That's my idea, but I don't have time to implement it myself (I 
would be willing to help), but maybe someone else will get 
inspired to make something like this happen.


jcc7

Re: Arbitrary abbreviations in phobos considered ridiculous

On Wed, Mar 07, 2012 at 03:30:15PM +0100, Andrej Mitrovic wrote:
> On 3/7/12, Steven Schveighoffer  wrote:
> > I'll see if I can do a pull request.
> 
> For my own purposes what I did was wrap StopWatch in a custom struct
> and used alias this to overwrite some of its functions. It's one of
> the things that makes D so great, I can basically rewrite an external
> API with zero hit on performance.

+1. And what makes D even greater, is that it can do this without stupid
convoluted syntax that either looks like line noise (*ahem*C++template
syntax*ahem*) or rewrites the entire language (*cough*Cmacros*ahem*).


> In fact, maybe we should add a note of this capability to the
> http://en.wikipedia.org/wiki/Adapter_pattern page (e.g. a
> "compile-time adapter" section)

Beware the deletionists, though, if you do it.


T

-- 
Let's call it an accidental feature. -- Larry Wall

Re: Arbitrary abbreviations in phobos considered ridiculous

On Wed, 07 Mar 2012 08:47:48 -0500, Steven Schveighoffer  
 wrote:



I'll see if I can do a pull request.


Almost done, need to test:

https://github.com/schveiguy/druntime/commit/cf9d1ba4f5498c447d91497cb5edbd735d2b4c7e

Actually cleans up a lot of the template constraints too...

-Steve

Re: dereferencing null

On Wed, 07 Mar 2012 10:10:32 -0500, Chad J  
 wrote:



On Wednesday, 7 March 2012 at 14:23:18 UTC, Chad J wrote:

On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:

On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
 wrote:



Why is it fatal?


A segmentation fault indicates that a program tried to access memory
that is not available. Since the 0 page is never allocated, any null
pointer dereferencing results in a seg fault.

However, there are several causes of seg faults:

1. You forgot to initialize a variable.
2. Your memory has been corrupted, and some corrupted pointer now  
points

into no-mem land.
3. You are accessing memory that has been deallocated.

Only 1 is benign. 2 and 3 are fatal. Since you cannot know which of
these three happened, the only valid choice is to terminate.

I think the correct option is to print a stack trace, and abort the
program.



Alright, I think I see where the misunderstanding is coming from.

I have only ever encountered (1).  And I've encountered it a lot.

I didn't even consider (2) and (3) as possibilities.  Those are far  
from my mind.


I still have a nagging doubt though: since the dereference in question  
is null, then there is no way for that particular dereference to  
corrupt other memory.  The only way this happens in (2) and (3) is that  
related code tries to write to invalid memory.  But if we have other  
measures in place to prevent that (bounds checking, other hardware  
signals, etc), then how is it still possible to corrupt memory?




[...]

-Steve


I spoke too soon!
We missed one:

1. You forgot to initialize a variable.
2. Your memory has been corrupted, and some corrupted pointer
  now points into no-mem land.
3. You are accessing memory that has been deallocated.
4. null was being used as a sentinal value, and it snuck into
  a place where the value should not be a sentinal anymore.

I will now change what I said to reflect this:

I think I see where the misunderstanding is coming from.

I encounter (1) from time to time.  It isn't a huge problem because  
usually if I declare something the next thing on my mind is initializing  
it.  Even if I forget, I'll catch it in early testing.  It tends to  
never make it to anyone else's desk, unless it's a regression.   
Regressions like this aren't terribly common though.  If you make my  
program crash from (1), I'll live.


I didn't even consider (2) and (3) as possibilities.  Those are far from  
my mind.  I think I'm used to VM languages at this point (C#, Java,  
Actionscript 3, Haxe, Synergy/DE|DBL, etc).  In the VM, (2) and (3)  
can't happen.  I never worry about those.  Feel free to crash these in D.


I encounter (4) a lot.  I really don't want my programs crashed when (4)  
happens.  Such crashes would be super annoying, and they can happen at  
very bad times.


You can use sentinels other than null.

-Steve

Re: Review of Jose Armando Garcia Sancio's std.log

2012-03-07 Thread Robert Jacques

On Tue, 06 Mar 2012 21:22:21 -0600, Andrei Alexandrescu  
 wrote:



On 3/6/12 6:05 PM, Geoffrey Biggs wrote:

That approach means that if I actually do have a fatal error, I can't
mark it as such.


Use log.fatal for those.

Andrei


But fatal "Logs a fatal severity message. Fatal log messages terminate the  
application after the message is persisted. Fatal log message cannot be  
disable at compile time or at run time." The point is that he want to log  
a fatal message and then terminate in a custom manner. I don't see a  
problem with convince functions that log and error and then throw, but not  
having the option to not throw is an unnecessary limitation.

Re: dereferencing null


On Wednesday, 7 March 2012 at 14:23:18 UTC, Chad J wrote:

On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:

On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
 wrote:



Why is it fatal?


A segmentation fault indicates that a program tried to access 
memory
that is not available. Since the 0 page is never allocated, 
any null

pointer dereferencing results in a seg fault.

However, there are several causes of seg faults:

1. You forgot to initialize a variable.
2. Your memory has been corrupted, and some corrupted pointer 
now points

into no-mem land.
3. You are accessing memory that has been deallocated.

Only 1 is benign. 2 and 3 are fatal. Since you cannot know 
which of

these three happened, the only valid choice is to terminate.

I think the correct option is to print a stack trace, and 
abort the

program.



Alright, I think I see where the misunderstanding is coming 
from.


I have only ever encountered (1).  And I've encountered it a 
lot.


I didn't even consider (2) and (3) as possibilities.  Those are 
far from my mind.


I still have a nagging doubt though: since the dereference in 
question is null, then there is no way for that particular 
dereference to corrupt other memory.  The only way this happens 
in (2) and (3) is that related code tries to write to invalid 
memory.  But if we have other measures in place to prevent that 
(bounds checking, other hardware signals, etc), then how is it 
still possible to corrupt memory?




[...]

-Steve


I spoke too soon!
We missed one:

1. You forgot to initialize a variable.
2. Your memory has been corrupted, and some corrupted pointer
   now points into no-mem land.
3. You are accessing memory that has been deallocated.
4. null was being used as a sentinal value, and it snuck into
   a place where the value should not be a sentinal anymore.

I will now change what I said to reflect this:

I think I see where the misunderstanding is coming from.

I encounter (1) from time to time.  It isn't a huge problem
because usually if I declare something the next thing on my mind
is initializing it.  Even if I forget, I'll catch it in early
testing.  It tends to never make it to anyone else's desk, unless
it's a regression.  Regressions like this aren't terribly common
though.  If you make my program crash from (1), I'll live.

I didn't even consider (2) and (3) as possibilities.  Those are
far from my mind.  I think I'm used to VM languages at this point
(C#, Java, Actionscript 3, Haxe, Synergy/DE|DBL, etc).  In the
VM, (2) and (3) can't happen.  I never worry about those.  Feel
free to crash these in D.

I encounter (4) a lot.  I really don't want my programs crashed
when (4) happens.  Such crashes would be super annoying, and they
can happen at very bad times.

--

Now then, I have 2 things to say about this:

- Why can't we distinguish between these?  As I said in my
previous thoughts, we should have ways of ruling out (2) and (3),
thus ensuring that our NullDerefException was caused by only (1)
or (4).  It's possible in VM languages, but given that the VM is
merely a cheesey abstraction, I beleive that it's always possible
to accomplish the same things in D %100 of the time.  Usually
this requires isolating the system bits from the abstractions.
Saying it can't be done would be giving up way too easily, and
you can miss the hidden treasure that way.

- If I'm given some sensible way of handling sentinal values then
(4) will become a non-issue.  Then that leaves (1-3), and I am OK
if those cause mandatory crashing.  I know I'm probably opening
an old can of worms, but D is quite powerful and I think we
should be able to solve this stuff.  My instincts tell me that
managing sentinal values with special patterns in memory (ex:
null values or separate boolean flags) all have pitfalls
(null-derefs or SSOT violations that lead to desync).  Perhaps
D's uber-powerful type system can rescue us?

The only other problem with this is... what if our list is not
exhaustive, and (5) exists?

Re: dereferencing null


On Wednesday, 7 March 2012 at 14:23:18 UTC, Chad J wrote:

On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:

On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
 wrote:



Why is it fatal?


A segmentation fault indicates that a program tried to access 
memory
that is not available. Since the 0 page is never allocated, 
any null

pointer dereferencing results in a seg fault.

However, there are several causes of seg faults:

1. You forgot to initialize a variable.
2. Your memory has been corrupted, and some corrupted pointer 
now points

into no-mem land.
3. You are accessing memory that has been deallocated.

Only 1 is benign. 2 and 3 are fatal. Since you cannot know 
which of

these three happened, the only valid choice is to terminate.

I think the correct option is to print a stack trace, and 
abort the

program.



Alright, I think I see where the misunderstanding is coming 
from.


I have only ever encountered (1).  And I've encountered it a 
lot.


I didn't even consider (2) and (3) as possibilities.  Those are 
far from my mind.


I still have a nagging doubt though: since the dereference in 
question is null, then there is no way for that particular 
dereference to corrupt other memory.  The only way this happens 
in (2) and (3) is that related code tries to write to invalid 
memory.  But if we have other measures in place to prevent that 
(bounds checking, other hardware signals, etc), then how is it 
still possible to corrupt memory?




[...]

-Steve


I spoke too soon!
We missed one:

1. You forgot to initialize a variable.
2. Your memory has been corrupted, and some corrupted pointer
 now points into no-mem land.
3. You are accessing memory that has been deallocated.
4. null was being used as a sentinal value, and it snuck into
 a place where the value should not be a sentinal anymore.

I will now change what I said to reflect this:

I think I see where the misunderstanding is coming from.

I encounter (1) from time to time.  It isn't a huge problem 
because usually if I declare something the next thing on my mind 
is initializing it.  Even if I forget, I'll catch it in early 
testing.  It tends to never make it to anyone else's desk, unless 
it's a regression.  Regressions like this aren't terribly common 
though.  If you make my program crash from (1), I'll live.


I didn't even consider (2) and (3) as possibilities.  Those are 
far from my mind.  I think I'm used to VM languages at this point 
(C#, Java, Actionscript 3, Haxe, Synergy/DE|DBL, etc).  In the 
VM, (2) and (3) can't happen.  I never worry about those.  Feel 
free to crash these in D.


I encounter (4) a lot.  I really don't want my programs crashed 
when (4) happens.  Such crashes would be super annoying, and they 
can happen at very bad times.


--

Now then, I have 2 things to say about this:

- Why can't we distinguish between these?  As I said in my 
previous thoughts, we should have ways of ruling out (2) and (3), 
thus ensuring that our NullDerefException was caused by only (1) 
or (4).  It's possible in VM languages, but given that the VM is 
merely a cheesey abstraction, I beleive that it's always possible 
to accomplish the same things in D %100 of the time.  Usually 
this requires isolating the system bits from the abstractions.  
Saying it can't be done would be giving up way too easily, and 
you can miss the hidden treasure that way.


- If I'm given some sensible way of handling sentinal values then 
(4) will become a non-issue.  Then that leaves (1-3), and I am OK 
if those cause mandatory crashing.  I know I'm probably opening 
an old can of worms, but D is quite powerful and I think we 
should be able to solve this stuff.  My instincts tell me that 
managing sentinal values with special patterns in memory (ex: 
null values or separate boolean flags) all have pitfalls 
(null-derefs or SSOT violations that lead to desync).  Perhaps 
D's uber-powerful type system can rescue us?


The only other problem with this is... what if our list is not 
exhaustive, and (5) exists?

Re: dereferencing null

On Wed, 07 Mar 2012 09:22:27 -0500, Chad J  
 wrote:



On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:

On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
 wrote:



Why is it fatal?


A segmentation fault indicates that a program tried to access memory
that is not available. Since the 0 page is never allocated, any null
pointer dereferencing results in a seg fault.

However, there are several causes of seg faults:

1. You forgot to initialize a variable.
2. Your memory has been corrupted, and some corrupted pointer now points
into no-mem land.
3. You are accessing memory that has been deallocated.

Only 1 is benign. 2 and 3 are fatal. Since you cannot know which of
these three happened, the only valid choice is to terminate.

I think the correct option is to print a stack trace, and abort the
program.



Alright, I think I see where the misunderstanding is coming from.

I have only ever encountered (1).  And I've encountered it a lot.


(1) occurs a lot, and in most cases, happens reliably.  Most QA cycles  
should find them.  There should be no case in which this is not a program  
error, to be fixed.
(2) and (3) are sinister because errors that occur are generally far away  
from the root cause, and the memory you are using is compromised.  For  
example, a memory corruption can cause an error several hours later when  
you try to use the corrupted memory.


If allowed to continue, such corrupt memory programs can cause lots of  
problems, e.g. corrupt your saved data, or run malicious code (buffer  
overflow attack).  It's not worth saving anything.


I didn't even consider (2) and (3) as possibilities.  Those are far from  
my mind.


I still have a nagging doubt though: since the dereference in question  
is null, then there is no way for that particular dereference to corrupt  
other memory.  The only way this happens in (2) and (3) is that related  
code tries to write to invalid memory.  But if we have other measures in  
place to prevent that (bounds checking, other hardware signals, etc),  
then how is it still possible to corrupt memory?


The null dereference may be a *result* of memory corruption.

example:

class Foo {void foo(){}}

void main()
{
   int[2] x = [1, 2];
   Foo f = new Foo;

   x.ptr[2] = 0; // oops killed f
   f.foo(); // segfault
}

Again, this one is benign, but it doesn't have to be.  I could have just  
nullified my return stack pointer, etc. along with f.


The larger point is, a SEGV means memory is not as it is expected.  Once  
you don't trust your memory, you might as well stop.


-Steve

Re: Review of Jose Armando Garcia Sancio's std.log

On Tue, 06 Mar 2012 14:19:27 -0500, Jose Armando Garcia  
 wrote:



On Mon, Mar 5, 2012 at 1:55 PM, Steven Schveighoffer
 wrote:

On Mon, 13 Feb 2012 10:50:04 -0500, David Nadlinger 
wrote:

There are several modules in the review queue right now, and to get  
things
going, I have volunteered to manage the review of Jose's std.log  
proposal.

Barring any objections, the review period starts now and ends in three
weeks, on March 6th, followed by a week of voting.




Some notes:

I dislike that logging affects function execution.  In particular, I  
don't
think the logging library should have any business throwing exceptions  
or
errors.  It should be invisible to the application.  The equivalent  
function
can be had by giving a wrapper function (i.e. log this message at the  
fatal
level, and then throw an error).  A use case I can see is printing  
several

fatal log messages before exiting.


Then don't use std.log.fatal. It is not like you are forced to use it.
You can implement the above by using std.log.error


Then I can't access the fatal level.

When I used Log4Net to log application errors, I only logged fatal errors  
to the event log (using an event log backend).  In fact, in that case, I  
was *catching* uncaught exceptions.  There was no need to throw another  
exception at that point.  My point is, whether to throw an exception or  
not should be up to the application, and having a fatal level can be  
utilized in other ways than "this is just like error but throws an  
exception".


Again, the logging library should not be in the business of dictating  
application design.


If fatal and critical logged an error at the "Error" logging level, and  
threw an appropriate exception, that would be a different story, because  
then it's just a convenience function.  But you have made two levels of  
logging unavailable without throwing exceptions.


As I brought up in another part of this thread, I envision the following  
pattern emerging:


try
{
   fatal("connection aborted!");
}
catch(LoggingError)
{
}

... // graceful shutdown of rest of the application
throw new LoggingError("connection aborted!");

The log aliases use names that are too common.  I think log.info is a  
better
symbol for logging than just 'info', which could be a symbol in a  
myriad of

places.  Given that D's symbol lookup rules allow shadowing of global
symbols, this does not work out very well.


This is a tough one. Should we be relying on D's module abstraction.
It is not scalable as a module designer and implementer to think about
other modules. This is why a lot of programming languages implement
the concept of namespaces.


The problem is that by default D pulls in a module's symbols into the  
current scope.  You have to go out of your way to *avoid* this.  By  
default you should be able to just import std.log and not have your local  
symbols shadow std.log's.


There are many solutions to this, as I have brought up elsewhere.


import log = std.log;
log.info("hello world");


I like this better:

import std.log;
// alias log.info info // if you desire
log.info("hello world");

Like others have stated, I think vlog is a) confusing, and b)  
unnecessary.
 Even reading the docs, I can't understand what it's used for, and why  
it

has such different syntax than the normal logging stuff.


I have tried to explain this before but it looks like I have failed. I
find it useful. If you are interested on a different explaination:
http://google-glog.googlecode.com/svn/trunk/doc/glog.html


Someone else pointed that out.  I think the documentation explanation  
there is much more complete than your version, and I think vlog is fine,  
it just needs a lot more documentation.


Do we have to make the logger a singleton?  I'd like to see cases where  
I

can have different log instances.  For example, an instance I can
enable/disable per class type, or an instance that logs to a diffferent
backend.  Or a non-shared instance which does not need to handle  
threading

issues (i.e. a per-thread file log). Does this help with the vlog issue?


My point of view here is that as a developer I never know how I want
to categorize my log during development. Some people use class name as
a hack for doing this. What about functional programs that don't use
class/objects? What about logical component/classes that span multiple
classes? I always found class based grouping for logging as a hack. D
made the observation that classes are not always the best abstraction
unit so it introduced modules. std.log filters based on modules
(actually source files to be exact but if D had __MODULE__, std.log
would use that instead.)


I wasn't speaking so much about filtering logging based on classes (and  
BTW, most logging libraries use hierarchical symbols to denote logging  
instances, they don't necessarily have to follow class names), but simply  
being able to have multiple log instances.  That is, instead of having one  
global instance of lo

Re: D Wiki - Why is it in such shambles?

2012-03-07 Thread Bruno Medeiros


On 03/03/2012 01:55, Jesse Phillips wrote:

On Friday, 2 March 2012 at 14:49:54 UTC, Robert Rouse wrote:

I'm relatively new to D, so I'm looking at everything I can. The D
wiki linked from the D site has so much outdated information and
entries that are more talk pages than actual entries (e.g.
http://prowiki.org/wiki4d/wiki.cgi?ComingFrom/Ruby )

If that wiki is not the best place to go for information (besides the
newsgroup), what is?


If you do not find the page helpful, please delete it/remove the
reference to it. The wiki works best when someone is willing to
make it better, and removing useless information is part of that.


That's a tricky thing to do. While it's easy to add new information to 
the wiki, removing it is not as clear-cut: it requires someone to be 
able to determine that information is outdated/incorrect/obsolete, and 
to be able to correct it (in case the correction is not as simple as 
deleting, but rather fixing some entry). And even so, unless the error 
in the information is glaring, people might be reticent to do it, as it 
implies "interfering" with someone else's work, and one does not always 
know if that is appropriate.


I also generally agree it would be better to have some sort of process 
set up around the wiki. Curate it in some way, or have a more managed, 
distilled version, that would be of use for newcomers. Indeed, it seems 
to me there is an important separation between some pages, those that 
are more discussion like, or more relevant only to experienced/involved 
members of the D community, and other pages which are quite important 
for beginners (like the Editors page and others linked from dlang.org), 
to offer a Getting-Started kind of information.



--
Bruno Medeiros - Software Engineer

Re: Review of Jose Armando Garcia Sancio's std.log

On Wed, 07 Mar 2012 07:09:17 -0500, Steven Schveighoffer  
 wrote:

On Tue, 06 Mar 2012 14:39:28 -0500, Jose Armando Garcia  
 wrote:

On Tue, Mar 6, 2012 at 12:25 AM, Jonathan M Davis   
wrote:

On Tuesday, March 06, 2012 09:14:16 so wrote:

On Tuesday, 6 March 2012 at 07:46:14 UTC, Jacob Carlborg wrote:
> On 2012-03-06 02:32, Jonathan M Davis wrote:
>
> The user can then alias "log!info" to "info" if he/she wants to.

Again, you are now forcing 2 common names instead of one as it is
now.
When you instantiate log!info where do you get "info" from?

Yes. My mistake - probably because the time stuff typicall takes such a
template argument as string, which would make this log!"info"(msg).  
However,
adding _log_ isn't necessarily bad, given that this is std.log that  
we're

talking about. It's info and the rest that are the problem.

Seriously everyone. What are we spending some much effort on this?

Because naming is important.  It's very difficult to change names once  
something is released.  I seriously could care less about implementation  
(didn't even look at it).  That can be fixed.  Naming can't.

What is wrong with:

import log = std.log;
log.info("cool");

What is wrong with

import std.log;
log.info("cool");

alternatively:

log_info("cool");
linfo("cool");
lginfo("cool");

There are so many choices besides just "info."  We should use something  
else.

-Steve

Re: Review of Jose Armando Garcia Sancio's std.log

On Tue, 06 Mar 2012 14:27:17 -0500, Jose Armando Garcia  
 wrote:


On Mon, Mar 5, 2012 at 5:32 PM, Jonathan M Davis   
wrote:

On Tuesday, March 06, 2012 02:22:05 so wrote:

That is not a counter-argument to something related to this
library but everything that lies in global namespace.
At its first state both severity levels and the "log" was in
global namespace. Now only severity levels.

You are also overlooking one crucial fact that this library will
be part of phobos, standard library. Which requires everyone to
adopt. When you see codes like this (below), you don't blame
standard library designers do you?

using namespace std;
int cout;


Except that cout is not exactly something that would be considered a  
normal

variable name. Something like info _is_. This logging module is taking
incredibly common names and shoving them as far into the global  
namespace as
anything can go in D which isn't a compiler built-in. _Not_ a good idea  
IMHO -

not without good reason. And I really don't think that this merits it.
log!info(msg) would work just fine and would be _far_ better.


using namesapce std;

matrix vector = new Matrix(...)

The variable vector conflicts with std::vector. Honestly, I can sit
here and come up with 10s or 100s of example where you want to use a
symbol that is expose by another module. You don't have to go far just
look at druntime and phobos. This the exact reason why modules and
namespace exist and one of the reason why people hate C's preprocessor
macros. D solved this problem years ago.


The not so trivial and important difference is here:

using namespace std;

That is, the default is, vector is *NOT* imported into your namespace.

For D modules, it is.

-Steve

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-07 Thread Andrej Mitrovic

On 3/7/12, Steven Schveighoffer  wrote:
> I'll see if I can do a pull request.

For my own purposes what I did was wrap StopWatch in a custom struct
and used alias this to overwrite some of its functions. It's one of
the things that makes D so great, I can basically rewrite an external
API with zero hit on performance.

In fact, maybe we should add a note of this capability to the
http://en.wikipedia.org/wiki/Adapter_pattern page (e.g. a
"compile-time adapter" section)

Re: dereferencing null