date:20120306

On Mar 6, 2012, at 7:47 PM, Walter Bright wrote:

> On 3/6/2012 7:19 PM, Sean Kelly wrote:
>> Slicing works, it just requires more care.
> 
> You can't mix sliced data and unsliced, unless you have extra data in your 
> structures to track this.

Ah, I see what you're saying.  True.

>> GC makes slicing work pretty much automatically, though you can end up with 
>> severe memory bloat.
> 
> I don't see how slicing produces bloat.

Slice ten bytes out of the middle of a ten MB buffer and the entire buffer 
sticks around.

Re: Arbitrary abbreviations in phobos considered ridiculous

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.


T

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

Re: Arbitrary abbreviations in phobos considered ridiculous

On Wed, Mar 07, 2012 at 04:42:50AM +0100, Adam D. Ruppe wrote:
> 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?

My first choice is actually 'cur', but I'm OK with 'curr'. I've
consistently used 'cur' for 'current' for at least the last decade and a
half, probably more.

T

-- 
Famous last words: I wonder what will happen if I do *this*...

Re: dereferencing null

Oh alright. Then we're in complete agreement. 

On Mar 6, 2012, at 8:05 PM, Walter Bright  wrote:

> On 3/6/2012 7:08 PM, Sean Kelly wrote:
>> Minor point, but some apps are designed such that segfaults are intended. I
>> worked on a DB that dynamically mapped memory in the segfault handler and
>> then resumed execution.  Since D is a systems languages, very few assumptions
>> can be made about error conditions.
> 
> Yes, and I've written a GC implementation that relied on intercepting invalid 
> page writes to construct its list of 'dirty' pages.
> 
> There's nothing in D preventing one from doing that, although for sure such 
> code will be very, very system specific.
> 
> What I'm talking about is the idea that one can recover from seg faults 
> resulting from program bugs.

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

On Tuesday, March 06, 2012 20:10:58 Andrei Alexandrescu wrote:
> On 3/6/12 7:43 PM, Jonathan M Davis wrote:
> > Because the level that you log something at and what you want to do in
> > terms of exceptions aren't necessarily related at all. It could easily be
> > that you want to log something and then do some series of operations
> > before throwing - even if the log level is the most severe level, and you
> > intend to throw an Error to kill the program. And as others have pointed
> > out, you might want to log a series of messages. Having std.log throw on
> > the first one makes it so that you can't log any others.
> 
> Then I guess you'd be well advised to use the function that "logs to the
> error log", not the one that "logs to the error log and then throws".
> No? I mean you're explaining how a screwdriver is not appropriate for
> pounding nails.

Sure, but std.log appears to have built in whether an exception is thrown or 
not into the log level itself. The log level and whether an exception is 
thrown are not necessarily related. Having one log function which throws and 
another which doesn't is fine. It's the fact that this proposal ties the 
exceptions to the log levels which is the problem.

> >>> std.log shouldn't be declaring _any_
> >>> exception types unless they're related to setting up the logging (_none_
> >>> which relate to functions which log).
> >> 
> >> Why?
> > 
> > Because as others have asserted, logging should not affect program flow.
> > It's
> > printing out messages to a log, which doesn't necessarily have _anything_
> > to do with throwing exceptions.
> 
> It does, because, as I mentioned, frequently one is interested in
> logging erroneous events that are followed by a breakage of flow.

Sure, you _may_ want to throw when you log, and having a way to do that in one 
command is fine. The problem is that you don't _always_ want to throw or not at 
a particular log level, and this std.log proposal ties to the two together.

> > And when you _do_ throw an exception, why on earth would anyone want a
> > LoggingException (or whatever std.log would call its exception type)? You
> > want an exception which relates to what went wrong, not what threw it.
> > The fact that you logged a message before throwing is incidental. Nothing
> > that catches the exception is going to care.
> 
> That I do agree with.

And the current proposal declares a CriticalException type which is thrown 
when logging at the critical level. So, while we may agree on this, the 
current proposal does not.

- Jonathan M Davis

Re: Extend vector ops to boolean operators?

On 7 March 2012 17:03, bearophile  wrote:
> James Miller:
>
>> What? I'm assuming you mean that you expect an array of `bool`s?
>
> Right. Vector operations like a[] To see how this is useful you probably must think in terms of vector-style 
> programming. In NumPy the use of arrays of booleans is common:
>
 from numpy import *
 a = array([3,6,8,9])
 a == 6
> array([False,  True, False, False], dtype=bool)
 a >= 7
> array([False, False,  True,  True], dtype=bool)
 a < 5
> array([ True, False, False, False], dtype=bool)
 # count all the even numbers
 sum( (a%2) == 0 )
> 2
 b = array([2,6,7,10])
 a == b
> array([False,  True, False, False], dtype=bool)
 a < b
> array([False, False, False,  True], dtype=bool)
>
>
> They are sometimes used as masks, it's useful if you have a Vector type that 
> supports multi-index syntax:
>
> i = scipy.array([0,1,2,1]) # array of indices for the first axis
> j = scipy.array([1,2,3,4]) # array of indices for the second axis
> a[i,j] # return array([a[0,1], a[1,2], a[2,3], a[1,4]])
> b = scipy.array([True, False, True, False])
> a[b] # return array([a[0], a[2]]) since only b[0] and b[2] are True
>
>
> Using the new CPU AVX registers you are able to perform a loop and work on 
> the items of an array in parallel until all the booleans of an array are 
> false. See this, expecially Listing 5:
>
> http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions/
>
> http://www.cs.uaf.edu/2011/spring/cs641/lecture/04_12_AVX.html
>
> Vector comparisons have a natural hardware implementataion with AVX/AVX2 
> instructions like _mm256_cmp_ps.
>
> Bye,
> bearophile

Hmm, I see your point, I think that with D's current operator
overloading you could implement most of that. Other than the
comparison syntax.

If vector comparison gets added, then there should be some very clear
documentation that it returns a vector, because I can imagine using it
in an if statement and then wondering why it always went through...

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


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

Because the level that you log something at and what you want to do in terms
of exceptions aren't necessarily related at all. It could easily be that you
want to log something and then do some series of operations before throwing -
even if the log level is the most severe level, and you intend to throw an
Error to kill the program. And as others have pointed out, you might want to
log a series of messages. Having std.log throw on the first one makes it so
that you can't log any others.


Then I guess you'd be well advised to use the function that "logs to the 
error log", not the one that "logs to the error log and then throws". 
No? I mean you're explaining how a screwdriver is not appropriate for 
pounding nails.



std.log shouldn't be declaring _any_
exception types unless they're related to setting up the logging (_none_
which relate to functions which log).


Why?


Because as others have asserted, logging should not affect program flow.
It's
printing out messages to a log, which doesn't necessarily have _anything_ to
do with throwing exceptions.


It does, because, as I mentioned, frequently one is interested in 
logging erroneous events that are followed by a breakage of flow.



It's merely for providing information about what
the program is doing. If you have it throwing exceptions - _especially_
exceptions which are specific to it - you're conflating two separate concepts:
logging to a log file and having the program report errors. They _can_ be
related, but they often aren't.


Well all I can say is they are in my experience. Some logging libraries 
have primitives that throw, some don't. I prefer a library that has the 
option in it because I use it all the time with glog.



And when you _do_ throw an exception, why on earth would anyone want a
LoggingException (or whatever std.log would call its exception type)? You want
an exception which relates to what went wrong, not what threw it. The fact
that you logged a message before throwing is incidental. Nothing that catches
the exception is going to care.


That I do agree with.


Andrei

Re: dereferencing null


On 3/6/2012 7:08 PM, Sean Kelly wrote:

Minor point, but some apps are designed such that segfaults are intended. I
worked on a DB that dynamically mapped memory in the segfault handler and
then resumed execution.  Since D is a systems languages, very few assumptions
can be made about error conditions.


Yes, and I've written a GC implementation that relied on intercepting invalid 
page writes to construct its list of 'dirty' pages.


There's nothing in D preventing one from doing that, although for sure such code 
will be very, very system specific.


What I'm talking about is the idea that one can recover from seg faults 
resulting from program bugs.

Re: dereferencing null


On 3/6/2012 8:05 PM, Walter Bright wrote:

What I'm talking about is the idea that one can recover from seg faults
resulting from program bugs.


I've written about this before, but I want to emphasize that attempting to 
recover from program BUGS is the absolutely WRONG way to go about writing 
fail-safe, critical, fault-tolerant software.

Re: Extend vector ops to boolean operators?

2012-03-06 Thread bearophile

James Miller:

> What? I'm assuming you mean that you expect an array of `bool`s?

Right. Vector operations like a[]>> from numpy import *
>>> a = array([3,6,8,9])
>>> a == 6
array([False,  True, False, False], dtype=bool)
>>> a >= 7
array([False, False,  True,  True], dtype=bool)
>>> a < 5
array([ True, False, False, False], dtype=bool)
>>> # count all the even numbers
>>> sum( (a%2) == 0 )
2
>>> b = array([2,6,7,10])
>>> a == b
array([False,  True, False, False], dtype=bool)
>>> a < b
array([False, False, False,  True], dtype=bool)


They are sometimes used as masks, it's useful if you have a Vector type that 
supports multi-index syntax:

i = scipy.array([0,1,2,1]) # array of indices for the first axis
j = scipy.array([1,2,3,4]) # array of indices for the second axis
a[i,j] # return array([a[0,1], a[1,2], a[2,3], a[1,4]])
b = scipy.array([True, False, True, False])
a[b] # return array([a[0], a[2]]) since only b[0] and b[2] are True


Using the new CPU AVX registers you are able to perform a loop and work on the 
items of an array in parallel until all the booleans of an array are false. See 
this, expecially Listing 5:

http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions/

http://www.cs.uaf.edu/2011/spring/cs641/lecture/04_12_AVX.html

Vector comparisons have a natural hardware implementataion with AVX/AVX2 
instructions like _mm256_cmp_ps.

Bye,
bearophile

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

On 7 March 2012 16:43, Jonathan M Davis  wrote:
> On Tuesday, March 06, 2012 19:27:35 Andrei Alexandrescu wrote:
>> On 3/6/12 7:04 PM, Jonathan M Davis wrote:
>> > On Tuesday, March 06, 2012 18:19:23 Jose Armando Garcia wrote:
>> >> Fatal and Critical are exactly these continence functions... To
>> >> reiterate. fatal will always assert and critical will always throw. It
>> >> is impossible for the user to disable these things.
>> >
>> > No, because they affect the log level. The concept of throwing and the log
>> > level should be _completely_ separate.
>>
>> Why?
>
> Because the level that you log something at and what you want to do in terms
> of exceptions aren't necessarily related at all. It could easily be that you
> want to log something and then do some series of operations before throwing -
> even if the log level is the most severe level, and you intend to throw an
> Error to kill the program. And as others have pointed out, you might want to
> log a series of messages. Having std.log throw on the first one makes it so
> that you can't log any others.
>
>> > std.log shouldn't be declaring _any_
>> > exception types unless they're related to setting up the logging (_none_
>> > which relate to functions which log).
>>
>> Why?
>
> Because as others have asserted, logging should not affect program flow. It's
> printing out messages to a log, which doesn't necessarily have _anything_ to
> do with throwing exceptions. It's merely for providing information about what
> the program is doing. If you have it throwing exceptions - _especially_
> exceptions which are specific to it - you're conflating two separate concepts:
> logging to a log file and having the program report errors. They _can_ be
> related, but they often aren't.
>
> And when you _do_ throw an exception, why on earth would anyone want a
> LoggingException (or whatever std.log would call its exception type)? You want
> an exception which relates to what went wrong, not what threw it. The fact
> that you logged a message before throwing is incidental. Nothing that catches
> the exception is going to care.
>
> - Jonathan M Davis

Surprisingly, I agree with the idea that fatal and critical shouldn't
throw, or at least shouldn't throw by default, maybe a configuration
option would allow for that functionality. Logging probably shouldn't
affect program flow.

Its possible that I may need to log a "critical" error, then do some
graceful shutdown.

In my opinion, critical and error should /not/ throw by default,
however they should be able to get an optional Exception to throw, if
that is appropriate behavior.

--
James Miller

Re: Arbitrary abbreviations in phobos considered ridiculous

On Wednesday, March 07, 2012 04:42:50 Adam D. Ruppe wrote:
> 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?

Definitely. I would pretty much never use current, because curr will do the job 
just as well, and it's shorter.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

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. On some level, it's unavoidable, 
and D has some great tools for minimizing the impact, but I also don't think 
that there's much reason to pick a name which is likely to cause conflicts with 
other modules when another name wouldn't, unless the other name is just 
horrible in comparison.

- Jonathan M Davis

Re: John Carmack applauds D's pure attribute


On 3/6/2012 7:19 PM, Sean Kelly wrote:

Slicing works, it just requires more care.


You can't mix sliced data and unsliced, unless you have extra data in your 
structures to track this.



GC makes slicing work pretty much automatically, though you can end up with 
severe memory bloat.


I don't see how slicing produces bloat.

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Nick Sabalausky

"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.

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

On Tuesday, March 06, 2012 19:27:35 Andrei Alexandrescu wrote:
> On 3/6/12 7:04 PM, Jonathan M Davis wrote:
> > On Tuesday, March 06, 2012 18:19:23 Jose Armando Garcia wrote:
> >> Fatal and Critical are exactly these continence functions... To
> >> reiterate. fatal will always assert and critical will always throw. It
> >> is impossible for the user to disable these things.
> > 
> > No, because they affect the log level. The concept of throwing and the log
> > level should be _completely_ separate.
> 
> Why?

Because the level that you log something at and what you want to do in terms 
of exceptions aren't necessarily related at all. It could easily be that you 
want to log something and then do some series of operations before throwing - 
even if the log level is the most severe level, and you intend to throw an 
Error to kill the program. And as others have pointed out, you might want to 
log a series of messages. Having std.log throw on the first one makes it so 
that you can't log any others.

> > std.log shouldn't be declaring _any_
> > exception types unless they're related to setting up the logging (_none_
> > which relate to functions which log).
> 
> Why?

Because as others have asserted, logging should not affect program flow. It's 
printing out messages to a log, which doesn't necessarily have _anything_ to 
do with throwing exceptions. It's merely for providing information about what 
the program is doing. If you have it throwing exceptions - _especially_ 
exceptions which are specific to it - you're conflating two separate concepts: 
logging to a log file and having the program report errors. They _can_ be 
related, but they often aren't.

And when you _do_ throw an exception, why on earth would anyone want a 
LoggingException (or whatever std.log would call its exception type)? You want 
an exception which relates to what went wrong, not what threw it. The fact 
that you logged a message before throwing is incidental. Nothing that catches 
the exception is going to care.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Adam D. Ruppe

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?

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Brad Anderson

On Wednesday, 7 March 2012 at 03:24:23 UTC, Jonathan M Davis 
wrote:

On Wednesday, March 07, 2012 03:49:46 Adam D. Ruppe wrote:

Though, I still say the underlying silliness remains
ridiculous. currentTime >> currTime.


I don't understand this complaint at all. curr is an incredibly 
common

abbreviation for current.

- Jonathan M Davis


I agree.  curr isn't exactly uncommon.  I'd personally probably 
go with currentTime but it's perfectly readable as currTime.


Since it's already in Clock I'd even consider just using 'time' 
or 'now' but I don't feel strongly about it.


Regards,
Brad Anderson

Re: Arbitrary abbreviations in phobos considered ridiculous


On 3/6/12 7:32 PM, Brad Anderson wrote:

On Wednesday, 7 March 2012 at 00:25:19 UTC, Jonathan M Davis wrote:

On Tuesday, March 06, 2012 17:00:19 Brad Anderson wrote:

I wasn't around for the creation of datetime but I'm curious why a boost
datetime-like duration construction shortcut approach to durations
wasn't
used. That is, you can write weeks(1), months(6), years(10), hours(17),
minutes(12), etc. (although there is now days(int) for some reason).


Because then you've got incredibly common names used as top-level
symbols.


I understand the concern but, for what it's worth, I write project
scheduling software professionally so I spend a lot of time working with
dates and durations. I'd have no problem with these being top level even
though the chance of symbol clashing would be much higher for me than
most programmers. A standard library's datetime module seems like it
should have first dibs on those names anyway. I think it should gobble
up that real estate.


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.)


Andrei

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Brad Anderson

On Wednesday, 7 March 2012 at 00:25:19 UTC, Jonathan M Davis 
wrote:

On Tuesday, March 06, 2012 17:00:19 Brad Anderson wrote:
I wasn't around for the creation of datetime but I'm curious 
why a boost
datetime-like duration construction shortcut approach to 
durations wasn't
used. That is, you can write weeks(1), months(6), years(10), 
hours(17),
minutes(12), etc. (although there is now days(int) for some 
reason).


Because then you've got incredibly common names used as 
top-level symbols.


I understand the concern but, for what it's worth, I write 
project scheduling software professionally so I spend a lot of 
time working with dates and durations.  I'd have no problem with 
these being top level even though the chance of symbol clashing 
would be much higher for me than most programmers.  A standard 
library's datetime module seems like it should have first dibs on 
those names anyway.  I think it should gobble up that real estate.


It's also not generic at all. As it stands, you can have a 
function which does
dur!units(value). You can't do that with weeks(1), months(6), 
etc.




That is a very nice feature for me as I have to work in arbitrary 
base units (seconds, minutes, days, hours, etc.) extensively.  I 
definitely would want that genericity to remain.  The aliases 
Nick wrote appear to be a good addition (unless I'm overlooking a 
problem with them).  You keep the genericity but get brevity with 
the package.


Although I still haven't really made use of it yet, it was really 
relieving to find D had such an extensive datetime module.  A lot 
of languages and libraries try to get away with doing the bare 
minimum (often just very thin and obvious wrappers over what the 
OS does) so thank you for putting so much time (I can only assume 
with how large the module is) and thought into designing 
something powerful that befits a powerful language.


Regards,
Brad Anderson



- Jonathan M Davis

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


On 3/6/12 7:04 PM, Jonathan M Davis wrote:

On Tuesday, March 06, 2012 18:19:23 Jose Armando Garcia wrote:

Fatal and Critical are exactly these continence functions... To
reiterate. fatal will always assert and critical will always throw. It
is impossible for the user to disable these things.


No, because they affect the log level. The concept of throwing and the log
level should be _completely_ separate.


Why?


std.log shouldn't be declaring _any_
exception types unless they're related to setting up the logging (_none_ which
relate to functions which log).


Why?


Adding an extra function which logs and then throws the exception that it's
given is fine, but that should have _nothing_ to do with the log level.


Why?


Asserting or throwing unconditionally like std.log does now is completely
unacceptable IMHO.


Why?


Logging should _not_ affect program flow.


Why?

Once again, the fallacy police finds you in violation of asserting the 
hypothesis as its own sustaining argument.



Andrei

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


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

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


On 3/6/12 5:07 PM, Jonathan M Davis wrote:

As it stands, std.log is conflating two separate concepts - logging and and
error handling.


Throwing an exception is not error handling. If it were, so many 
entities would do so, the whole concept would become devoid of meaning.


Andrei

Re: Arbitrary abbreviations in phobos considered ridiculous

On Wednesday, March 07, 2012 03:49:46 Adam D. Ruppe wrote:
> Though, I still say the underlying silliness remains
> ridiculous. currentTime >> currTime.

I don't understand this complaint at all. curr is an incredibly common 
abbreviation for current.

- Jonathan M Davis

Re: John Carmack applauds D's pure attribute

Slicing works, it just requires more care. GC makes slicing work pretty much 
automatically, though you can end up with severe memory bloat. 

On Mar 6, 2012, at 6:25 PM, Walter Bright  wrote:

> On 3/6/2012 4:27 AM, Manu wrote:
>> On 26 February 2012 00:55, Walter Bright >Most straight up GC vs malloc/free benchmarks miss something crucial. A GC
>>allows one to do substantially *fewer* allocations. It's a lot faster to 
>> not
>>allocate than to allocate.
>> Do you really think that's true?
> 
> Yes.
> 
>> Are there any statistics to support that?
> 
> No, just my experience using both.
> 
> Consider strings. In C, I'd often have a function that returns a string. The 
> caller then (eventually) free's it. That means the string must have been 
> allocated by malloc. That means that if I want to:
> 
>   return "foo";
> 
> I have to replace it with:
> 
>   return strdup("foo");
> 
> It means I can't do the "small string" optimization. It means I cannot return 
> the tail of some other string. I cannot return a malloc'd string that 
> anything else points to. I *must* return a *unique* malloc'd string.
> 
> This carries into a lot of data structures, and means lots of extra 
> allocations.
> 
> Next problem: I can't do array slicing. I have to make copies instead.
> 
> You suggested using ref counting. That's only a partial solution. Setting 
> aside all the problems of getting it right, consider getting a stream of 
> input from a user. With GC, you can slice it and store those slices in a 
> symbol table - no allocations at all. No chance of that without a GC, even 
> with ref counting.

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

On Tuesday, March 06, 2012 19:10:14 Sean Kelly wrote:
> Sorry. For some reason I thought info was callable directly without the
> leading log portion.

It _is_ callable that way. Just look at the example at the top:

http://jsancio.github.com/phobos/phobos/std_log.html

- Jonathan M Davis

Re: Extend vector ops to boolean operators?

On 7 March 2012 15:35, Peter Alexander  wrote:
> On Tuesday, 6 March 2012 at 23:57:07 UTC, James Miller wrote:
>>
>> On 7 March 2012 10:58, Kapps  wrote:
>>>
>>> On Tuesday, 6 March 2012 at 20:28:40 UTC, H. S. Teoh wrote:


 It'd be really cool if I could do this:

        void func(int[] vector, int[] bounds) {
                assert(vector[] >= 0 && vector[] < bounds[]);

                ...
        }

 Is there any reason why we shouldn't implement this?


 T
>>>
>>>
>>>
>>> Would this be possible with UFCS?
>>>
>>> int opCmp(T)T([] array, T element) { ... }
>>> int opCmp(T)(T[] array1, T[] array2) { ... }
>>
>>
>> I like this idea, at least adding an opSliceCmp operator-overload
>> would do as a start, I think thats the correct name for it. I can't be
>> bothered to check.
>>
>> --
>> James Miller
>
>
> It has to be done as vector operations.
>
> a[] < b[] should equal [a[0] < b[0], a[1] < b[1], ... ]
>
> What the OP has asked for is not a vector operation, so it shouldn't use the
> vector op syntax.

What? I'm assuming you mean that you expect an array of `bool`s? While
I agree that most vector operations should return a vector, comparison
makes more sense as returning a straight bool, most of the time you
aren't going to want to just have an array of bools. The only use case
i can think of is this:

auto c = a[] < b[]
foreach (i : c) {
if (i) doSomething();
else doSomethingElse();
}

Which can be easily re-written as

for (int i; i < a.length; i++) {
if (a[i] < b[i]) doSomething();
else doSomethingElse();
}

(ignoring things like proper checking etc.)

Of course most vector ops should return vectors, but most other ops
return proper types too, comparison ops tend to be the exception to
the rule.

--
James Miller

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

Sorry. For some reason I thought info was callable directly without the leading 
log portion. 

On Mar 6, 2012, at 1:37 PM, Jose Armando Garcia  wrote:

> On Tue, Mar 6, 2012 at 12:43 PM, Sean Kelly  wrote:
>> On Mar 6, 2012, at 11:39 AM, Jose Armando Garcia wrote:
>> 
>>> Seriously everyone. What are we spending some much effort on this?
>>> What is wrong with:
>>> 
>>> import log = std.log;
>>> log.info("cool");
>> 
>> Why should the default be unqualified names?  Is this simply a desire to not 
>> change std.log so we can just get it in already?
> 
> What are you proposing?
> 
> struct Log {
>  static alias log!Severity.info info;
>  ...
> }
> 
> I am not exactly sure when this idiom became popular. I don't know if
> this is an C++ idiom or a Java idiom but I do know that it is a broken
> hack. C++ developers use it because the name-spacing facility is
> limiting. Java uses it because everything is a class and they don't
> have the concept of compile time objects. We don't need this hack in
> D. D's module mechanism make this C++/Java idiom unnecessary.
> 
> 
> Thanks,
> -Jose

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Bill

F i L Wrote:

> I personally find it much easier to remember and use longer, more 
> sentance-like method names. However, Jonathan and others 
> obviously feel more comfortable writing with a high level of 
> abbreviation, which they justify rather well. Still, if D's goal 
> is to gain popularity, I think it should take notices of other 
> rising languages like C#.
> 
> The problem with making any change to Phobos is backwards 
> compatibility. So, what if there was a way to satisfy both 
> parties and keep backwards compatibility? Is there any compelling 
> reason why simply wrapping Phobos into a different format would 
> be such bad thing? Meaning:
> 
>  // system.io
> 
>  private import std.stdio;
> 
>  alias write   Write;
>  alias writeln WriteLine;
>  // etc...
> 
> Besides keeping things in-sync and error messages referring to 
> the original function names (which could be amended), I don't see 
> why such a library couldn't be written as a way to make the 
> language easier to swallow to potential D users coming from 
> Java/C#. Microsoft used similar tactics with J#/F# to help the 
> Java/Python folks adapt their code to .NET.

good idea ! can refer to the java c # naming specification, to work out d own 
naming specification

good luck£¡
Bill

Re: dereferencing null

On Mar 6, 2012, at 6:29 PM, Walter Bright  wrote:

> On 3/6/2012 5:29 PM, Chad J wrote:
>> But what do you say to the notion of isolation? someFunc is isolated from
>> riskyShenanigans becuase it /knows/ what state is touched by 
>> riskyShenanigans.
>> If riskyShenanigans does something strange and unexpected, and yes, it does 
>> have
>> a bug in it, then I feel that someFunc should be able to reset the state 
>> touched
>> by riskyShenanigans and continue.
> 
> 
> That's the theory. But in practice, when you get a seg fault, there's (at 
> minimum) a logical error in your program, and it is in an undefined state. 
> Since memory is all shared, you have no idea whether that error is isolated 
> or not, and you *cannot* know, because there's a logic error you didn't know 
> about.

Minor point, but some apps are designed such that segfaults are intended. I 
worked on a DB that dynamically mapped memory in the segfault handler and then 
resumed execution.  Since D is a systems languages, very few assumptions can be 
made about error conditions.

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

On Tuesday, March 06, 2012 18:19:23 Jose Armando Garcia wrote:
> Fatal and Critical are exactly these continence functions... To
> reiterate. fatal will always assert and critical will always throw. It
> is impossible for the user to disable these things.

No, because they affect the log level. The concept of throwing and the log 
level should be _completely_ separate. std.log shouldn't be declaring _any_ 
exception types unless they're related to setting up the logging (_none_ which 
relate to functions which log).

Adding an extra function which logs and then throws the exception that it's 
given is fine, but that should have _nothing_ to do with the log level. 
Asserting or throwing unconditionally like std.log does now is completely 
unacceptable IMHO. Logging should _not_ affect program flow.

- Jonathan M Davis

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

2012-03-06 Thread Robert Jacques

On Tue, 06 Mar 2012 17:20:29 -0600, Jose Armando Garcia
wrote:

On Tue, Mar 6, 2012 at 2:03 PM, Robert Jacques wrote:

On Tue, 06 Mar 2012 13:41:32 -0600, Jose Armando Garcia
wrote:

On Tue, Mar 6, 2012 at 10:11 AM, Robert Jacques wrote:

On Tue, 06 Mar 2012 11:44:13 -0600, Jose Armando Garcia

wrote:

On Tue, Mar 6, 2012 at 9:32 AM, Robert Jacques wrote:

On Tue, 06 Mar 2012 11:01:19 -0600, Jose Armando Garcia

wrote:

On Wed, Feb 29, 2012 at 4:13 PM, 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

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.

Interesting observation on logging. I like your theoretical
observation and explanation. To me the most important thing is
usability and unfortunately people are used to log levels as a order
concept. Meaning error is higher severity than info so if I am logging
info events I should probably also log error events.

If we go with a mechanism like the one you describe above there is no
order so the configuration is a little more complicated or verbose I
should say. Instead of saying we should log everything "greater" than
warning the user needs to say that they want to log known-cause,
known-effect, breaks-flow events. This mean that there are 27 (= 3^3)
configuration combinations. To implement this we need 3 configuration
nobs with 3 values (on, off, both).

Thoughts?
-Jose

There are only 8 possible configurations and they are nicely ordered in
terms of severity. So I don't see this as a problem. Also, if you went
with
a combinatorial approach, shouldn't it be 2^8 = 256, not 3^3 = 27
values?

Yes. If you want to enable and disable each individual "level" then
you need 8 configuration options which leads to 2^8.

I suggested 3^3 as a more reasonable options that matches how the
developer is logging but doesn't give you as much expressiveness as
the 2^8 option.

In practice, all you'd need to take is a flag with the desired levels.
i.e.

// Automatically set logging levels using the standard severity ordering
config.minSeverity(Severity.Warning);

// Manually set the logging levels
config.setSeverities(Severity.Warning|
Severity.Error|
Severity.Critical|
Severity.Severe|
Severity.Fatal);

I don't see the problem with including both methods and a large advantage
to
having a standardized severity framework.

Interesting. If you find this useful, I think we can add this in a
future release as it shouldn't break existing modules that maybe using
the library.

This began as a discussion regarding Richard's organization of logging
severity. That organization isn't something that can be trivially included
at a later date.

Please be explicit in what you are requesting... If you have an API even better.

Richard proposed an organizational framework for logging severity, which many
people including myself and yourself found valuable. In another thread I
proposed a logical extension of this framework to make the logging call self
documenting. You criticized both as having being overly complex with regard to
setting the runtime severity level, to which I proposed a reasonable counter
argument. Your response to the counter argument is to suggest making one aspect
of it a possible future extension. ?? This seemed to ignore Richard's original
suggestion and the extreme value of having a set of well-documented and
standardized logging guidelines so that multiple code monkeys / projects 'play
well' together. Better yet, by specifying those levels in terms of their
conceptual components at the call site, code reviewers can instantly see the
nature of what is being logged, without having to remember what each of those
log levels mean. And not having to remember the classifications red!
uces
the radius of comprehension needed to use / review the library (http://pragprog.com/magazines/2010-04/tangled-up-in-tools).

P.S.
You could also set config options using method chaining / fluent interfaces:

config.logWarnings.logErrors.logCriticals.logSevers.logFatals;

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Adam D. Ruppe


On Wednesday, 7 March 2012 at 02:38:55 UTC, Nick Sabalausky wrote:

alias duration!"years" years;
All (real) problems solved.


I'm Adam D. Ruppe, and I approve this message.

Though, I still say the underlying silliness remains
ridiculous. currentTime >> currTime.

Re: dereferencing null

2012-03-06 Thread bearophile

Chad J:

> I can't seem to download the PDF... it always gives me just two bytes.
> 
> But to initialize non-null fields, I suspect we would need to be able to 
> do stuff like this:

There are some links here:
http://d.puremagic.com/issues/show_bug.cgi?id=4571

Bye,
bearophile

Re: Arbitrary abbreviations in phobos considered ridiculous

On Tue, Mar 06, 2012 at 09:18:13PM -0500, Nick Sabalausky wrote:
[...]
> 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;

+1.


> 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.

Name collisions can be solved by D's excellent import mechanisms. If
somebody imports std.datetime and gets a collision, well just write
std.datetime.secs and my.own.module.secs instead. If that's too verbose,
import aliases are there precisely for these kinds of situations.

This is an excellent idea.  I say we should go with this.


T

-- 
Food and laptops don't mix.

Re: Extend vector ops to boolean operators?

2012-03-06 Thread Peter Alexander


On Tuesday, 6 March 2012 at 23:57:07 UTC, James Miller wrote:

On 7 March 2012 10:58, Kapps  wrote:

On Tuesday, 6 March 2012 at 20:28:40 UTC, H. S. Teoh wrote:


It'd be really cool if I could do this:

       void func(int[] vector, int[] bounds) {
               assert(vector[] >= 0 && vector[] < 
bounds[]);


               ...
       }

Is there any reason why we shouldn't implement this?


T



Would this be possible with UFCS?

int opCmp(T)T([] array, T element) { ... }
int opCmp(T)(T[] array1, T[] array2) { ... }


I like this idea, at least adding an opSliceCmp 
operator-overload
would do as a start, I think thats the correct name for it. I 
can't be

bothered to check.

--
James Miller


It has to be done as vector operations.

a[] < b[] should equal [a[0] < b[0], a[1] < b[1], ... ]

What the OP has asked for is not a vector operation, so it 
shouldn't use the vector op syntax.

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Nick Sabalausky

"Jonathan M Davis"  wrote in message 
news:mailman.117.1331079921.4860.digitalmar...@puremagic.com...
> On Tuesday, March 06, 2012 17:00:19 Brad Anderson wrote:
>> I wasn't around for the creation of datetime but I'm curious why a boost
>> datetime-like duration construction shortcut approach to durations wasn't
>> used. That is, you can write weeks(1), months(6), years(10), hours(17),
>> minutes(12), etc. (although there is now days(int) for some reason).
>
> Because then you've got incredibly common names used as top-level symbols.

In this case, I can't imagine that would be a realistic problem in practice. 
There aren't many things that can be called, for example, "hours":

1. There's the concept of the duration itself, which is already covered by 
std.datetime and core.time, so nobody needs to reinvent that wheel (and if 
they do, they're not going to be importing std.datetime anyway).

2. There's "number of hours". In which case there's plenty of options: A. 
Change it to "numHours" or something descriptive like "hoursOfPlaytime" 
(which is a better idea anyway - if you're in the habit of using vars named 
like "hours", those can just as easily collide with each other as they can 
collide with "std.datetime.hours"). B. Keep it "hours" and remember this 
isn't C++: We have many excellent features for dealing with symbol 
name-collisions. And in many/most cases, you'll never even have a collision 
anyway.

3. Nothing. That's it, just those two: The "concept of hours as a duration" 
and "number of hours". Thie first is a complete non-issue, and the second is 
a miniscule issue at most.

I think the name collision issue (is this case) is just worrying over 
nothing.

> It's also not generic at all. As it stands, you can have a function which 
> does
> dur!units(value). You can't do that with weeks(1), months(6), etc.
>

First of all, I can't imagine that would be needed frequently enough to 
justify having to always use "dur" or "duration". Second, as I said in 
another post, just drop this in:

alias duration!"years" years;
alias duration!"months" months;
alias duration!"weeks" weeks;
alias duration!"days" days;
alias duration!"hours" hours;
alias duration!"minutes" minutes;
alias duration!"seconds" seconds;
alias duration!"msecs" msecs;
alias duration!"usecs" usecs;
alias duration!"hnsecs" hnsecs;

All (real) problems solved.

Re: dereferencing null

On Tue, Mar 06, 2012 at 08:29:35PM -0500, Chad J wrote:
[...]
> But what do you say to the notion of isolation?  someFunc is
> isolated from riskyShenanigans becuase it /knows/ what state is
> touched by riskyShenanigans.  If riskyShenanigans does something
> strange and unexpected, and yes, it does have a bug in it, then I
> feel that someFunc should be able to reset the state touched by
> riskyShenanigans and continue.
>
> The thing I find really strange here is that there's this belief
> that if feature A is buggy then the unrelated feature B shouldn't
> work either. Why?  Shouldn't the user be able to continue using
> feature B?

If feature A is buggy and the user is trying to use it, then there's a
problem. If the user doesn't use feature A or knows that feature A is
buggy and so works around it, then feature A doesn't (shouldn't) run and
won't crash.

> Btw, crashing a program is bad.  That can lose data that the user
> has entered but not yet stored.  I should have a very good reason
> before I let this happen.

I don't know what your software design is, but when I write code, if
there is the possibility of data loss, I always make the program backup
the data at intervals. I don't trust the integrity of user data after a
major problem like dereferencing a null pointer happens. Obviously
there's a serious logic flaw in the program that led to this, so all
bets are off as to whether the user's data is even usable.

> It would also be extremely frustrating for a user to have a program
> become crippled because some feature they don't even use will
> occasionally dereference null and crash the thing.  Then they have
> to wait for me to fix it, and I'm busy, so it could be awhile.

The fact that the unused feature running even though the user isn't
using it is, to me, a sign that something like a null pointer
dereference should be fatal, because it means that what you assumed the
unused feature was doing before in the background was consistent, but it
turns out to be false, so who knows what else it has been doing wrong
before it hit the null pointer. I should hate for the program to
continue running after that, since consistency has been compromised;
continuing will probably only worsen the problem.

> My impression so far is that this hinges on some kind of "where
> there's one, there's more" argument.  I am unconvinced because
> programs tend to have bugs anyways.  riskyShenanigans doing a
> null-dereference once doesn't mean it's any more likely to produce
> corrupt results the rest of the time: it can produce corrupt results
> anyways, because it is a computer program written by a fallible
> human being.  Anyone trying to be really careful should validate the
> results in someFunc.

It sound like what you want is some kind of sandbox isolation function,
and null pointers are just the most obvious problem among other things
that could go wrong.

We could have a std.sandbox module that can run some given code (say
PossiblyBuggyFeatureA) inside a sandbox, so that if it dereferences a
null pointer, corrupts memory, or whatever, it won't affect
UnrelatedFeatureB which runs in a different sandbox, or the rest of the
system. This way you can boldly charge forward in spite of any problems,
because you know that only the code inside the sandbox is in a bad
state, and the rest of the program (presumably) is still in good working
condition.

In Linux this is easily implemented by fork() and perhaps chroot() (if
you're *really* paranoid) and message-passing (so the main program is
guaranteed to have no corruption even when BadPluginX goes crazy and
starts trashing memory everywhere). I don't know about Windows, but I
assume there is some way to do sandboxing as well.

T

-- 
Customer support: the art of getting your clients to pay for your own 
incompetence.

Re: dereferencing null


On 3/6/2012 5:29 PM, Chad J wrote:

But what do you say to the notion of isolation? someFunc is isolated from
riskyShenanigans becuase it /knows/ what state is touched by riskyShenanigans.
If riskyShenanigans does something strange and unexpected, and yes, it does have
a bug in it, then I feel that someFunc should be able to reset the state touched
by riskyShenanigans and continue.



That's the theory. But in practice, when you get a seg fault, there's (at 
minimum) a logical error in your program, and it is in an undefined state. Since 
memory is all shared, you have no idea whether that error is isolated or not, 
and you *cannot* know, because there's a logic error you didn't know about.


Continuing on after the program has entered an unknown an undefined state is 
just a recipe for disaster.

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Bill

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.
> 
> 
> This is almost as bad as "creat" and "umount". It's like
> these names are deliberately designed to fail your
> first guess. Our minds are pretty good at remembering
> words and sentences; it is an existing database in there
> that follow established patterns.
> 
> Arbitrary abbreviations only work through special-cased
> brute force rote memorization.
> 
> 
> And the dmd spellchecker doesn't always help:
> 
> Error: template instance duration!("hours") template 'duration' 
> is not defined, did you mean Duration?
> 
> 
> Nope, apparently, I meant "dur". Ridiculous.
> 
> 
> 
> std.datetime isn't the only one that does this, of course.
> rndGen() in the middle of sane names like "unpredictableSeed"
> and "randomShuffle". There's more, too.
> 
> 
> 
> 
> 
> Some abbreviations are justified by precedent. rmdir() has
> been around for a long time, so we know what it is. Stringz
> is similarly classic. "printf" is one of the earliest words
> many of us saw as programmers.
> 
> But "dur"? "curr"?
> 
> 
> What the hell? Can we please stop this?

Agree !!! that this is the the phobos biggest flaw , the lack of a good naming 
convention . It is time to formulate a good naming convention .

good luck
Bill

Re: John Carmack applauds D's pure attribute


On 3/6/2012 4:27 AM, Manu wrote:

On 26 February 2012 00:55, Walter Bright 

Yes.


Are there any statistics to support that?


No, just my experience using both.

Consider strings. In C, I'd often have a function that returns a string. The 
caller then (eventually) free's it. That means the string must have been 
allocated by malloc. That means that if I want to:


   return "foo";

I have to replace it with:

   return strdup("foo");

It means I can't do the "small string" optimization. It means I cannot return 
the tail of some other string. I cannot return a malloc'd string that anything 
else points to. I *must* return a *unique* malloc'd string.


This carries into a lot of data structures, and means lots of extra allocations.

Next problem: I can't do array slicing. I have to make copies instead.

You suggested using ref counting. That's only a partial solution. Setting aside 
all the problems of getting it right, consider getting a stream of input from a 
user. With GC, you can slice it and store those slices in a symbol table - no 
allocations at all. No chance of that without a GC, even with ref counting.

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

2012-03-06 Thread Geoffrey Biggs


On 07/03/12 11:12, Jose Armando Garcia wrote:

On Tue, Mar 6, 2012 at 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. It gets conflated with the non-fatal errors, both in the source
and in the logging output (which may, for example, be filtering for fatal
errors to phone someone in the middle of the night while errors just send an
email). Another point worth considering is that I cannot use the fatal level
and be able to re-compile my software with logging disabled, because that
will change the program flow.


Fatal and Critical severity cannot be disabled either at runtime or at
compile. In other words fatal log messages will always assert(true)
and critical log messages will always throw.


Forcing the two semantic concepts (logging and error handling) together
needlessly restricts the ways the library can be used. It is nice to
encapsulate frequent patterns, but providing a convenience function that
throws an error, or a new level ("terminate" or something) is a better
approach than forcing that pattern on everyone. Based on the name, it's a
*logging* library, not an error handling library.


Fatal and critical are these convenience functions.


OK, I took another look at the docs. I see your point now. Sorry for 
making a fuss.


However, I think that in this case, the log levels usable without 
killing the program are too coarse. This may be a matter of taste, though.


Geoff

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Nick Sabalausky

"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.

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

On Tue, Mar 6, 2012 at 5:07 PM, Jonathan M Davis  wrote:
> On Tuesday, March 06, 2012 16:59:09 Andrei Alexandrescu wrote:
>> I don't see why the agitation around this particular matter. It's a
>> matter of convenience, much like writeln (as opposed to just write).
>> Let's admit that it often happens that you want to log some troublesome
>> stuff just before throwing an exception with essentially the same
>> message, so the thing is shown on the screen and also persisted in the
>> log. Without a critical level, the pattern would be:
>>
>> string message = stuff() + ": " + moreStuff();
>> log.error(message);
>> throw new Exception(message);
>>
>> It's nice to encapsulate this frequent pattern, hence:
>>
>> log.critical(stuff() + ": " + moreStuff());
>>
>> If you want to log but not throw, use log.error. I don't think the
>> response "dont use those libraries either" is meaningful.
>
> I think that it would be far more meaningful to have a logging function which
> you pass the exception to throw.
This exactly how I am thinking of extending critical. I don't have an
API yet but the intent is that you can pass an exception to critical
and the module will throw it for you. Very similar to how enforce
works.

> That way, you can throw whatever is
> appropriate for your program, not have std.log throw a logging exception of
> some kind. Such a function would be a convenience function where the
> programmer is explicitly saying that they want to log and then throw rather
> than having logging functions throw as a matter of course if the logging level
> is critical enough. What if you want to log such a message _without_ throwing?
>
I think we are going around in circles. If you don't want to abort or
throw then use error.

> As it stands, std.log is conflating two separate concepts - logging and and
> error handling. Providing a convenience function to make that easier is fine,
> but making it so that the normal logging functions deal with error handling is
> not.
>
Fatal and Critical are exactly these continence functions... To
reiterate. fatal will always assert and critical will always throw. It
is impossible for the user to disable these things.

Thanks,
-Jose
> - Jonathan M Davis

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

On Tue, Mar 6, 2012 at 6:05 PM, Geoffrey Biggs
 wrote:
> On 07/03/12 09:59, Andrei Alexandrescu wrote:
>>
>> I don't see why the agitation around this particular matter. It's a
>> matter of convenience, much like writeln (as opposed to just write).
>> Let's admit that it often happens that you want to log some troublesome
>> stuff just before throwing an exception with essentially the same
>> message, so the thing is shown on the screen and also persisted in the
>> log. Without a critical level, the pattern would be:
>>
>> string message = stuff() + ": " + moreStuff();
>> log.error(message);
>> throw new Exception(message);
>>
>> It's nice to encapsulate this frequent pattern, hence:
>>
>> log.critical(stuff() + ": " + moreStuff());
>>
>> If you want to log but not throw, use log.error. I don't think the
>> response "dont use those libraries either" is meaningful.
>
>
> That approach means that if I actually do have a fatal error, I can't mark
> it as such. It gets conflated with the non-fatal errors, both in the source
> and in the logging output (which may, for example, be filtering for fatal
> errors to phone someone in the middle of the night while errors just send an
> email). Another point worth considering is that I cannot use the fatal level
> and be able to re-compile my software with logging disabled, because that
> will change the program flow.
>
Fatal and Critical severity cannot be disabled either at runtime or at
compile. In other words fatal log messages will always assert(true)
and critical log messages will always throw.

> Forcing the two semantic concepts (logging and error handling) together
> needlessly restricts the ways the library can be used. It is nice to
> encapsulate frequent patterns, but providing a convenience function that
> throws an error, or a new level ("terminate" or something) is a better
> approach than forcing that pattern on everyone. Based on the name, it's a
> *logging* library, not an error handling library.
>
Fatal and critical are these convenience functions.

> Geoff

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

2012-03-06 Thread Geoffrey Biggs


On 07/03/12 09:59, Andrei Alexandrescu wrote:

I don't see why the agitation around this particular matter. It's a
matter of convenience, much like writeln (as opposed to just write).
Let's admit that it often happens that you want to log some troublesome
stuff just before throwing an exception with essentially the same
message, so the thing is shown on the screen and also persisted in the
log. Without a critical level, the pattern would be:

string message = stuff() + ": " + moreStuff();
log.error(message);
throw new Exception(message);

It's nice to encapsulate this frequent pattern, hence:

log.critical(stuff() + ": " + moreStuff());

If you want to log but not throw, use log.error. I don't think the
response "dont use those libraries either" is meaningful.


That approach means that if I actually do have a fatal error, I can't 
mark it as such. It gets conflated with the non-fatal errors, both in 
the source and in the logging output (which may, for example, be 
filtering for fatal errors to phone someone in the middle of the night 
while errors just send an email). Another point worth considering is 
that I cannot use the fatal level and be able to re-compile my software 
with logging disabled, because that will change the program flow.


Forcing the two semantic concepts (logging and error handling) together 
needlessly restricts the ways the library can be used. It is nice to 
encapsulate frequent patterns, but providing a convenience function that 
throws an error, or a new level ("terminate" or something) is a better 
approach than forcing that pattern on everyone. Based on the name, it's 
a *logging* library, not an error handling library.


Geoff

Re: dereferencing null

2012-03-06 Thread Chad J


On 03/06/2012 12:19 PM, Timon Gehr wrote:

On 03/06/2012 04:46 PM, foobar wrote:

On Tuesday, 6 March 2012 at 10:19:19 UTC, Timon Gehr wrote:


This is quite close, but real support for non-nullable types means
that they are the default and checked statically, ideally using data
flow analysis.


I agree that non-nullable types should be made the default and
statically checked but data flow analysis here is redundant.
consider:
T foo = ..; // T is not-nullable
T? bar = ..; // T? is nullable
bar = foo; // legal implicit coercion T -> T?
foo = bar; // compile-time type mismatch error
//correct way:
if (bar) { // make sure bar isn't null
// compiler knows that cast(T)bar is safe
foo = bar;
}



Right. This example already demonstrates some simplistic data flow
analysis.



of course we can employ additional syntax sugar such as:
foo = bar || ;

furthermore:
foo.method(); // legal
bar.method(); // compile-time error

it's all easily implementable in the type system.


Actually it requires some thinking because making initialization of
non-null fields safe is not entirely trivial.

For example:
http://pm.inf.ethz.ch/publications/getpdf.php/bibname/Own/id/SummersMuellerTR11.pdf


CTFE and static constructors solve that issue for static data.


I can't seem to download the PDF... it always gives me just two bytes.

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 ;).  Allowing this kind of initialization might also make it 
possible for us to have zero-argument struct constructors.

Re: dereferencing null

2012-03-06 Thread Chad J


On 03/06/2012 03:39 PM, Mantis wrote:

06.03.2012 8:04, Chad J пишет:

On 03/06/2012 12:07 AM, Jonathan M Davis wrote:


If you dereference a null pointer, there is a serious bug in your
program.
Continuing is unwise. And if it actually goes so far as to be a segfault
(since the hardware caught it rather than the program), it is beyond
a doubt
unsafe to continue. On rare occasion, it might make sense to try and
recover
from dereferencing a null pointer, but it's like catching an
AssertError. It's
rarely a good idea. Continuing would mean trying to recover from a
logic error
in your program. Your program obviously already assumed that the
variable
wasn't null, or it would have checked for null. So from the point of
view of
your program's logic, you are by definition in an undefined state, and
continuing will have unexpected and potentially deadly behavior.

- Jonathan M Davis


This could be said for a lot of things: array-out-of-bounds
exceptions, file-not-found exceptions, conversion exception, etc. If
the programmer thought about it, they would have checked the array
length, checked for file existence before opening it, been more
careful about converting things, etc.


It's different: with array-out-of-bounds there's no hardware detection,
so its either checked in software or unchecked (in best case you'll have
access violation or segfault, but otherwise going past the bounds of
array leads to undefined behavior). Both file-not-found and conv
exceptions often rely on user's input, in which case they do not
necessarily mean bug in a program.



Alright.


To me, the useful difference between fatal and non-fatal things is how
well isolated the failure is. Out of memory errors and writes into
unexpected parts of memory are very bad things and can corrupt
completely unrelated sections of code. The other things I've
mentioned, null-dereference included, cannot do this.

Null-dereferences and such can be isolated to sections of code. A
section of code might become compromised by the dereference, but the
code outside of that section is still fine and can continue working.

Example:
[...]
And if riskyShenanigans were to modify global state... well, it's no
longer so well isolated anymore. This is just a disadvantage of global
state, and it will be true with many other possible exceptions too.

Long story short: I don't see how an unexpected behavior in one part
of a program will necessarily create unexpected behavior in all parts
of the program, especially when good encapsulation is practiced.

Thoughts?


If riskyShenanigans nullifies reference in a process, then it must check
it before dereferencing. There's obviously a bug, and if program will
leave a proper crash log you shouldn't have problems finding and fixing
this bug. If you don't have access to function's source, then you cannot
guarantee it's safeness and isolation, so recovering from exception is
unsafe.


But what do you say to the notion of isolation?  someFunc is isolated 
from riskyShenanigans becuase it /knows/ what state is touched by 
riskyShenanigans.  If riskyShenanigans does something strange and 
unexpected, and yes, it does have a bug in it, then I feel that someFunc 
should be able to reset the state touched by riskyShenanigans and 
continue.


The thing I find really strange here is that there's this belief that if 
feature A is buggy then the unrelated feature B shouldn't work either. 
Why?  Shouldn't the user be able to continue using feature B?


Btw, crashing a program is bad.  That can lose data that the user has 
entered but not yet stored.  I should have a very good reason before I 
let this happen.


It would also be extremely frustrating for a user to have a program 
become crippled because some feature they don't even use will 
occasionally dereference null and crash the thing.  Then they have to 
wait for me to fix it, and I'm busy, so it could be awhile.


My impression so far is that this hinges on some kind of "where there's 
one, there's more" argument.  I am unconvinced because programs tend to 
have bugs anyways.  riskyShenanigans doing a null-dereference once 
doesn't mean it's any more likely to produce corrupt results the rest of 
the time: it can produce corrupt results anyways, because it is a 
computer program written by a fallible human being.  Anyone trying to be 
really careful should validate the results in someFunc.

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

On Tuesday, March 06, 2012 16:59:09 Andrei Alexandrescu wrote:
> I don't see why the agitation around this particular matter. It's a
> matter of convenience, much like writeln (as opposed to just write).
> Let's admit that it often happens that you want to log some troublesome
> stuff just before throwing an exception with essentially the same
> message, so the thing is shown on the screen and also persisted in the
> log. Without a critical level, the pattern would be:
> 
> string message = stuff() + ": " + moreStuff();
> log.error(message);
> throw new Exception(message);
> 
> It's nice to encapsulate this frequent pattern, hence:
> 
> log.critical(stuff() + ": " + moreStuff());
> 
> If you want to log but not throw, use log.error. I don't think the
> response "dont use those libraries either" is meaningful.

I think that it would be far more meaningful to have a logging function which 
you pass the exception to throw. That way, you can throw whatever is 
appropriate for your program, not have std.log throw a logging exception of 
some kind. Such a function would be a convenience function where the 
programmer is explicitly saying that they want to log and then throw rather 
than having logging functions throw as a matter of course if the logging level 
is critical enough. What if you want to log such a message _without_ throwing?

As it stands, std.log is conflating two separate concepts - logging and and 
error handling. Providing a convenience function to make that easier is fine, 
but making it so that the normal logging functions deal with error handling is 
not.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread F i L

I personally find it much easier to remember and use longer, more 
sentance-like method names. However, Jonathan and others 
obviously feel more comfortable writing with a high level of 
abbreviation, which they justify rather well. Still, if D's goal 
is to gain popularity, I think it should take notices of other 
rising languages like C#.


The problem with making any change to Phobos is backwards 
compatibility. So, what if there was a way to satisfy both 
parties and keep backwards compatibility? Is there any compelling 
reason why simply wrapping Phobos into a different format would 
be such bad thing? Meaning:


// system.io

private import std.stdio;

alias write   Write;
alias writeln WriteLine;
// etc...

Besides keeping things in-sync and error messages referring to 
the original function names (which could be amended), I don't see 
why such a library couldn't be written as a way to make the 
language easier to swallow to potential D users coming from 
Java/C#. Microsoft used similar tactics with J#/F# to help the 
Java/Python folks adapt their code to .NET.

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


On 3/6/12 4:31 PM, Geoffrey Biggs wrote:

On 07/03/12 09:25, Jonathan M Davis wrote:

On Tuesday, March 06, 2012 13:08:42 Brad Roberts wrote:

On Tue, 6 Mar 2012, Jose Armando Garcia wrote:

Fix now:

1. Add thread name attribute to the default logger
2. Check that the example compile
3. Come up with a better name for Rich and rich template
4. Add @safe pure nothrow const to as many methods as possible
5. Remove check when setting Configuration.logger


I still believe pretty strongly that the logger must not affect
application flow, ie, not throw or exit the app. From the feed back,
I am
not alone in thinking that. I don't believe that "well, don't use those
log levels" is a workaround if for no other reason that there will be
libraries that contain them and that becomes a "dont use those libraries
either" response.


Agreed. The logging functions should _not_ throw.


+1.

Is std.log a logging library or a complete error management library?

If it's a logging library, the last thing it should be doing is
affecting program flow. In the case of fatal, in particular, the program
may need to do something else after logging the fatal error before
terminating. You could argue that the program should do that before
logging the fatal error, but I don't think that's nice semantics.

On the other hand, if it's a complete error management library, it
probably shouldn't be called std.log.


I don't see why the agitation around this particular matter. It's a 
matter of convenience, much like writeln (as opposed to just write). 
Let's admit that it often happens that you want to log some troublesome 
stuff just before throwing an exception with essentially the same 
message, so the thing is shown on the screen and also persisted in the 
log. Without a critical level, the pattern would be:


string message = stuff() + ": " + moreStuff();
log.error(message);
throw new Exception(message);

It's nice to encapsulate this frequent pattern, hence:

log.critical(stuff() + ": " + moreStuff());

If you want to log but not throw, use log.error. I don't think the 
response "dont use those libraries either" is meaningful.



Andrei

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

On Tue, Mar 06, 2012 at 07:25:23PM -0500, Jonathan M Davis wrote:
> On Tuesday, March 06, 2012 13:08:42 Brad Roberts wrote:
[...]
> > I still believe pretty strongly that the logger must not affect
> > application flow, ie, not throw or exit the app. From the feed back,
> > I am not alone in thinking that. I don't believe that "well, don't
> > use those log levels" is a workaround if for no other reason that
> > there will be libraries that contain them and that becomes a "dont
> > use those libraries either" response.
> 
> Agreed. The logging functions should _not_ throw.
[...]

+1. Logging functions are for ... logging? Not for managing errors.
Leave it up to the user to define something like the following, if
they're so inclined:

void logAndAbort(T...)(string fmt, T args) {
critical(fmt.format(args));
throw new CriticalError(...);
}

One shouldn't have to write a try/catch block just so one can log a
critical message and continue doing whatever it is needs to be done.
(For example, you might want to log a critical condition immediately to
ensure the sysadmin sees the message, before proceeding to attempt
self-recovery that *may* fail and crash the system, and thereby lose the
ability to log a message.) Let the user decide whether or not to throw.

T

-- 
Why have vacation when you can work?? -- EC

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

On Tue, Mar 06, 2012 at 03:52:56PM -0800, Jose Armando Garcia wrote:
> On Tue, Mar 6, 2012 at 3:27 PM, Andrej Mitrovic
>  wrote:
> > On 3/7/12, Jose Armando Garcia  wrote:
> >> http://jsancio.github.com/phobos/phobos/std_log.html#fileNamePrefixes
> >
> > That was what I was looking for but I didn't find it at first. I think
> > that info about what the defaults are
> > ([program].[hostname].[user].[severity].log.[datetime].[pid]) might be
> > useful somewhere at the top. But that's just my 2 cents..
> 
> Yeah. I am not terribly happy how ddoc and dlang.org organizes the
> documentation. I have been thinking of duplicating a lot of the
> documentation to the top but I have two main objections that are
> holding back. 1. document duplication and 2. overloading the user with
> information. I would like the top of the document with enough
> information and example for the regular user to just start logging.
> They can later come back and read the whole thing when they want to
> configure and tweak things. Thoughts?
[...]

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.

T

-- 
What doesn't kill me makes me stranger.

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

2012-03-06 Thread Geoffrey Biggs


On 07/03/12 09:25, Jonathan M Davis wrote:

On Tuesday, March 06, 2012 13:08:42 Brad Roberts wrote:

On Tue, 6 Mar 2012, Jose Armando Garcia wrote:

Fix now:

1. Add thread name attribute to the default logger
2. Check that the example compile
3. Come up with a better name for Rich and rich template
4. Add @safe pure nothrow const to as many methods as possible
5. Remove check when setting Configuration.logger


I still believe pretty strongly that the logger must not affect
application flow, ie, not throw or exit the app. From the feed back, I am
not alone in thinking that. I don't believe that "well, don't use those
log levels" is a workaround if for no other reason that there will be
libraries that contain them and that becomes a "dont use those libraries
either" response.


Agreed. The logging functions should _not_ throw.


+1.

Is std.log a logging library or a complete error management library?

If it's a logging library, the last thing it should be doing is 
affecting program flow. In the case of fatal, in particular, the program 
may need to do something else after logging the fatal error before 
terminating. You could argue that the program should do that before 
logging the fatal error, but I don't think that's nice semantics.


On the other hand, if it's a complete error management library, it 
probably shouldn't be called std.log.


That's my opinion as an uninformed user.

Geoff

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

On Tuesday, March 06, 2012 13:08:42 Brad Roberts wrote:
> On Tue, 6 Mar 2012, Jose Armando Garcia wrote:
> > Future:
> > 
> > 1. Allowing filtering of regular log messages (like info, warning,
> > etc) based on the module. Similar to how vlog works.
> 
> Once you add module filtering to the regularly log messages, what's the
> point of having the separate vlog? I think this needs to be figured out
> before merge, not at some vague future.
> 
> > Fix now:
> > 
> > 1. Add thread name attribute to the default logger
> > 2. Check that the example compile
> > 3. Come up with a better name for Rich and rich template
> > 4. Add @safe pure nothrow const to as many methods as possible
> > 5. Remove check when setting Configuration.logger
> 
> I still believe pretty strongly that the logger must not affect
> application flow, ie, not throw or exit the app. From the feed back, I am
> not alone in thinking that. I don't believe that "well, don't use those
> log levels" is a workaround if for no other reason that there will be
> libraries that contain them and that becomes a "dont use those libraries
> either" response.

Agreed. The logging functions should _not_ throw.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

On Tuesday, March 06, 2012 17:00:19 Brad Anderson wrote:
> I wasn't around for the creation of datetime but I'm curious why a boost
> datetime-like duration construction shortcut approach to durations wasn't
> used. That is, you can write weeks(1), months(6), years(10), hours(17),
> minutes(12), etc. (although there is now days(int) for some reason).

Because then you've got incredibly common names used as top-level symbols. 
It's also not generic at all. As it stands, you can have a function which does 
dur!units(value). You can't do that with weeks(1), months(6), etc.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

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? 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.

No, dur is not a fantastic name, but when I had to choose between a name which 
become very long when combined with the required template argument, and dur, 
which is perfectly clear with minimal explanation - albeit not as clear as 
duration would be - but makes the symbol name shorter and therefore less of an 
issue to use in longer expressions, I went with the shorter name.

If anything, I'd argue that std.datetime and core.time have too many symbol 
names which are overly long in their attempt to be appropriately descriptive. 
I would have expected people to be complaining about the verboseness of some 
of them, not that some of them were abbreviated.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Ary Manzana


On 3/6/12 8:58 PM, 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"?


Also, it becomes long because it has a weird syntax, that either way is 
going to be hard to read. In Ruby (with active support) I can just do:


44.seconds

Why D doesn't do the same if it has UFCS? (I hope I got the acronym well)

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Brad Anderson

On Tue, Mar 6, 2012 at 4:53 PM, H. S. Teoh  wrote:

> On Tue, Mar 06, 2012 at 06:43:39PM -0500, 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.
>
> You *could* shorten String to Str, but that would be inconsistent with
> everything else (e.g. toString), so that's a no-go.
>
>
> > > 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.
> [...]
>
> I'm on the fence about this one. It's true that duration!"seconds"(44)
> is uncomfortably long, but 'dur' also tends towards the side of
> meaningless, esp. if it occurs only once or twice in otherwise-unrelated
> code. I'm inclined to leave it as 'duration' since I can't think of any
> good abbreviations for it either.
>
>
> T
>
> --
> A bend in the road is not the end of the road unless you fail to make
> the turn. -- Brian White
>

I wasn't around for the creation of datetime but I'm curious why a boost
datetime-like duration construction shortcut approach to durations wasn't
used.  That is, you can write weeks(1), months(6), years(10), hours(17),
minutes(12), etc. (although there is now days(int) for some reason).

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Ary Manzana


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.



Symbol names should be descriptive while still being as short as they can
reasonably be without losing meaning.

- Jonathan M Davis

Re: Extend vector ops to boolean operators?

On 7 March 2012 10:58, Kapps  wrote:
> On Tuesday, 6 March 2012 at 20:28:40 UTC, H. S. Teoh wrote:
>>
>> It'd be really cool if I could do this:
>>
>>        void func(int[] vector, int[] bounds) {
>>                assert(vector[] >= 0 && vector[] < bounds[]);
>>
>>                ...
>>        }
>>
>> Is there any reason why we shouldn't implement this?
>>
>>
>> T
>
>
> Would this be possible with UFCS?
>
> int opCmp(T)T([] array, T element) { ... }
> int opCmp(T)(T[] array1, T[] array2) { ... }

I like this idea, at least adding an opSliceCmp operator-overload
would do as a start, I think thats the correct name for it. I can't be
bothered to check.

--
James Miller

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

On Tue, Mar 6, 2012 at 3:27 PM, Andrej Mitrovic
 wrote:
> On 3/7/12, Jose Armando Garcia  wrote:
>> http://jsancio.github.com/phobos/phobos/std_log.html#fileNamePrefixes
>
> That was what I was looking for but I didn't find it at first. I think
> that info about what the defaults are
> ([program].[hostname].[user].[severity].log.[datetime].[pid]) might be
> useful somewhere at the top. But that's just my 2 cents..

Yeah. I am not terribly happy how ddoc and dlang.org organizes the
documentation. I have been thinking of duplicating a lot of the
documentation to the top but I have two main objections that are
holding back. 1. document duplication and 2. overloading the user with
information. I would like the top of the document with enough
information and example for the regular user to just start logging.
They can later come back and read the whole thing when they want to
configure and tweak things. Thoughts?

Thanks,
-Jose

Re: Arbitrary abbreviations in phobos considered ridiculous

On Tue, Mar 06, 2012 at 06:43:39PM -0500, 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.

You *could* shorten String to Str, but that would be inconsistent with
everything else (e.g. toString), so that's a no-go.

> > 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.
[...]

I'm on the fence about this one. It's true that duration!"seconds"(44)
is uncomfortably long, but 'dur' also tends towards the side of
meaningless, esp. if it occurs only once or twice in otherwise-unrelated
code. I'm inclined to leave it as 'duration' since I can't think of any
good abbreviations for it either.

T

-- 
A bend in the road is not the end of the road unless you fail to make
the turn. -- Brian White

Re: Arbitrary abbreviations in phobos considered ridiculous

On Tuesday, March 06, 2012 19:00:21 Andrej Mitrovic wrote:
> On 3/6/12, Dmitry Olshansky  wrote:
> > It's coming from separate stopwatch module that got merged with
> > std.datetime, so the blame is somewhat misplaced :)
> 
> I've argued about it with the current DateTime Czar, so it's not
> really missplaced. :)

Units which are sub-second are abbreviated. The others aren't. Making it
secs would be more consistent with the sub-second names, but it would make
it less consistent with the others. The only thing which would be completely
consistent would be to abbreviate them all or to abbreviate none of them.
Abbreviations get very ugly (and harder to remember IMO) with the larger
units, and not abbreviating the smaller ones makes them ludicrously long.
So, the compromise is to abbreviate the sub-second units and not the others.
And I believe that std.datetime and core.time are very consistent with
regards to how units are abbreviated.

Now, as for  TickDuration in specific, there's a good chance that it was the
way that it is when it was created - in which case choosing seconds over secs
for that wasn't me - but it's consistent with all of the rest of the time stuff
regardless.

- Jonathan M Davis

Re: Arbitrary abbreviations in phobos considered ridiculous

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.

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.

Symbol names should be descriptive while still being as short as they can 
reasonably be without losing meaning.

- Jonathan M Davis

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

On Mon, Mar 5, 2012 at 3:26 PM, David Nadlinger  wrote:
> Just a quick reply, more tomorrow:
>
>
> On 6 Mar 2012, at 0:03, Jose Armando Garcia wrote:
>>
>> What is your objection here? I don't remember reading your thoughts on
>> critical.
>
>
> Darn, my longer review post apparently didn't make it through the new web
> interface; hope I can dig it up again… Anyway, my main reservations about
> critical are that a CriticalException in my opinion has absolutely no
> semantic value (compared to e.g. a FileNotFoundException or at least
> FileException thrown from file I/O code).
>
> While I guess it works for programs where you know there is no way you can
> handle the exception and just want to do some rudimentary clean up before
> aborting with a message box/…, I wouldn't want to let it bubble up through
> any of my APIs if I'm writing a library, because there is no way a user can
> know how to handle it without the semantical meaning being defined (maybe in
> the docs, along the lines of »the program should assume nothing and shut
> itself down as quickly as possible« or whatever you design intention was).
>
> Makes sense?
>

Yep it makes sense. I was thinking about it this morning. My current
thinking is to add overloaded methods that look as follow:

critical(new Exception(...), "format string", params...)

This method records the message, exception and throws the exception specified.

error(new Exception(...), "format string", params...)

This method records the message and exception.

Everything else well stay the same. In other words if you don't pass
an exception to critical then it just throws the default exception:
CriticalException.

Or our other option is just to throw our hands in the air and decide
not to solve this problem. In other words remove Severity.fatal and
Severity.critical. Thoughts?

-Jose

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

2012-03-06 Thread Andrej Mitrovic

On 3/7/12, Jose Armando Garcia  wrote:
> http://jsancio.github.com/phobos/phobos/std_log.html#fileNamePrefixes

That was what I was looking for but I didn't find it at first. I think
that info about what the defaults are
([program].[hostname].[user].[severity].log.[datetime].[pid]) might be
useful somewhere at the top. But that's just my 2 cents..

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

On Tue, Mar 6, 2012 at 2:03 PM, Robert Jacques  wrote:
> On Tue, 06 Mar 2012 13:41:32 -0600, Jose Armando Garcia 
> wrote:
>>
>> On Tue, Mar 6, 2012 at 10:11 AM, Robert Jacques  wrote:
>>>
>>> On Tue, 06 Mar 2012 11:44:13 -0600, Jose Armando Garcia
>>> 
>>> wrote:


 On Tue, Mar 6, 2012 at 9:32 AM, Robert Jacques  wrote:
>
>
> On Tue, 06 Mar 2012 11:01:19 -0600, Jose Armando Garcia
> 
> wrote:
>
>> On Wed, Feb 29, 2012 at 4:13 PM, 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
>>>
>>> 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.
>>>
>>
>> Interesting observation on logging. I like your theoretical
>> observation and explanation. To me the most important thing is
>> usability and unfortunately people are used to log levels as a order
>> concept. Meaning error is higher severity than info so if I am logging
>> info events I should probably also log error events.
>>
>> If we go with a mechanism like the one you describe above there is no
>> order so the configuration is a little more complicated or verbose I
>> should say. Instead of saying we should log everything "greater" than
>> warning the user needs to say that they want to log known-cause,
>> known-effect, breaks-flow events. This mean that there are 27 (= 3^3)
>> configuration combinations. To implement this we need 3 configuration
>> nobs with 3 values (on, off, both).
>>
>> Thoughts?
>> -Jose
>
>
>
>
> There are only 8 possible configurations and they are nicely ordered in
> terms of severity. So I don't see this as a problem. Also, if you went
> with
> a combinatorial approach, shouldn't it be 2^8 = 256, not 3^3 = 27
> values?



 Yes. If you want to enable and disable each individual "level" then
 you need 8 configuration options which leads to 2^8.

 I suggested 3^3 as a more reasonable options that matches how the
 developer is logging but doesn't give you as much expressiveness as
 the 2^8 option.
>>>
>>>
>>>
>>> In practice, all you'd need to take is a flag with the desired levels.
>>> i.e.
>>>
>>> // Automatically set logging levels using the standard severity ordering
>>> config.minSeverity(Severity.Warning);
>>>
>>> // Manually set the logging levels
>>> config.setSeverities(Severity.Warning|
>>>                    Severity.Error|
>>>                    Severity.Critical|
>>>                    Severity.Severe|
>>>                    Severity.Fatal);
>>>
>>> I don't see the problem with including both methods and a large advantage
>>> to
>>> having a standardized severity framework.
>>
>>
>> Interesting. If you find this useful, I think we can add this in a
>> future release as it shouldn't break existing modules that maybe using
>> the library.
>
>
> This began as a discussion regarding Richard's organization of logging
> severity. That organization isn't something that can be trivially included
> at a later date.

Please be explicit in what you are requesting... If you have an API even better.

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

On Tue, Mar 6, 2012 at 2:44 PM, Andrej Mitrovic
 wrote:
> I still don't understand how to set the filename of the log file. Has
> this been added yet?

http://jsancio.github.com/phobos/phobos/std_log.html#fileNamePrefixes

Re: Arbitrary abbreviations in phobos considered ridiculous

On 7 March 2012 10:30, deadalnix  wrote:
> Le 06/03/2012 21:00, Timon Gehr a écrit :
>
>> On 03/06/2012 07:13 PM, 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...)
>>>
>>
>> It is not only about single names, but also about how many times you
>> have to spell them out in short intervals.
>>
>> try{
>> SqlConstraintViolatedExceptionFactoryWrapper
>> sqlConstraintViolatedExceptionFactoryWrapper = new
>> SqlConstraintViolatedExceptionFactoryWrapper(new
>> SqlConstraintViolatedExceptionFactory(...));
>> SqlConstraintViolatedException sqlConstraintViolatedException =
>>
>> sqlConstraintViolatedExceptionFactory.createSqlConstraintViolatedException(...);
>>
>> throw sqlConstraintViolatedException;
>> }catch(SqlConstraintViolatedExceptionFactoryWrapperException e){
>> // ...
>> }catch(SqlConstraintViolatedExceptionFactoryException e){
>> // ...
>> }
>>
>> Deliberately over-dramatized.
>
>
> As I said, names comes in a context. Overly long names tell about the fact
> that the name isn't at the right place and things should be refactored, to
> provide a nice place to that named stuff.
>
> auto helps too.

I agree with whoever was talking about balance. This isn't a
abbreviate vs not abbreviate discussion, its about when to abbreviate
and when not to. Personally, I think Clock.currentTime() is fine,
however Clock.currentTimeWithDST is not. There is also the argument of
line length, less of an issue nowadays, but I try to stick with
reasonable line-lengths, about 100 characters (was 80, but that ended
up being too limiting for most purposes), If I have to use overly
verbose names, then that eats into my "quota" for that line,
especially annoying when I have string arguments that I don't want to
have to split.

"dur" should be "duration" because its silly otherwise. Seconds should
be either "secs" /or/ "seconds", but should be consistent, I'd say
"secs" because it meshes well with the other, sub-second, times
("nsecs", "usecs" etc) and writing out "microseconds" is a bit
verbose, especially when you're probably outputting them as "12 us"
anyway...

--
James Miller

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

2012-03-06 Thread Andrej Mitrovic

I still don't understand how to set the filename of the log file. Has
this been added yet?

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

On Tue, Mar 6, 2012 at 1:08 PM, Brad Roberts  wrote:
> On Tue, 6 Mar 2012, Jose Armando Garcia wrote:
>
>> Future:
>>
>> 1. Allowing filtering of regular log messages (like info, warning,
>> etc) based on the module. Similar to how vlog works.
>
> Once you add module filtering to the regularly log messages, what's the
> point of having the separate vlog?  I think this needs to be figured out
> before merge, not at some vague future.
>
>> Fix now:
>>
>> 1. Add thread name attribute to the default logger
>> 2. Check that the example compile
>> 3. Come up with a better name for Rich and rich template
>> 4. Add @safe pure nothrow const to as many methods as possible
>> 5. Remove check when setting Configuration.logger
>
> I still believe pretty strongly that the logger must not affect
> application flow, ie, not throw or exit the app.  From the feed back, I am
> not alone in thinking that.  I don't believe that "well, don't use those
> log levels" is a workaround if for no other reason that there will be
> libraries that contain them and that becomes a "dont use those libraries
> either" response.
>

Yeah. I completely understand your point. I don't have a technical
argument for adding or removing fatal and critical. The only advantage
is that the developer is explicitly telling the logging framework when
the application will/may terminate. Instead of everyone having to
write:

void critical(...) {
  log.error(...);
  // force a flush. currently there is no way of expressing this so we
need to put this
  throw new ...;
}

and:

void fatal(...) {
  log.error(...);
  // force a flush. currently there is no way of expressing this so we
need to put this
  assert(true);
}

> My 2 cents,
> Brad
>

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

2012-03-06 Thread Robert Jacques

On Tue, 06 Mar 2012 13:32:37 -0600, Jose Armando Garcia  
 wrote:



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

On Mon, 05 Mar 2012 20:22:05 -0500, so  wrote:


On Monday, 5 March 2012 at 23:51:29 UTC, Steven Schveighoffer wrote:


On Mon, 05 Mar 2012 18:30:03 -0500, David Nadlinger  


wrote:


On Monday, 5 March 2012 at 21:55:08 UTC, Steven Schveighoffer wrote:


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.



Originally, the code used log!info and so on, but it was changed to  
the
current design right after review begin, the rationale being that  
you could

always use »import log = std.log« if you want the extra namespace.



That doesn't help.  Software isn't static.

import std.log;
import other; // defines B

class A : B
{
  void foo()
  {
 info("some info message"); // error! int isn't a function!
  }
}

other.d:

class B
{
  int info; // added later
}



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 'info', 'error', 'warning' are all common names, likely to be a  
very
attractive name for something that has nothing to do with (or cares  
about)

logging.  cout is not a common name or even an english word, so it's
unlikely someone has or wants to create a cout member.


Actually, I see this more as argument as to why cout is a horrible
name for a symbol in std.stdio. I suspect that the only reason that it
is there is to keep C developer migrating to D happy. It should
probably just be "out" like Java (System.out) and C# (Console.Out).


D doesn't have a cout, in stdio or elsewhere.

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

2012-03-06 Thread Robert Jacques

On Tue, 06 Mar 2012 13:41:32 -0600, Jose Armando Garcia  
 wrote:

On Tue, Mar 6, 2012 at 10:11 AM, Robert Jacques  wrote:
On Tue, 06 Mar 2012 11:44:13 -0600, Jose Armando Garcia  


wrote:


On Tue, Mar 6, 2012 at 9:32 AM, Robert Jacques   
wrote:


On Tue, 06 Mar 2012 11:01:19 -0600, Jose Armando Garcia

wrote:

On Wed, Feb 29, 2012 at 4:13 PM, 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

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.



Interesting observation on logging. I like your theoretical
observation and explanation. To me the most important thing is
usability and unfortunately people are used to log levels as a order
concept. Meaning error is higher severity than info so if I am  
logging

info events I should probably also log error events.

If we go with a mechanism like the one you describe above there is no
order so the configuration is a little more complicated or verbose I
should say. Instead of saying we should log everything "greater" than
warning the user needs to say that they want to log known-cause,
known-effect, breaks-flow events. This mean that there are 27 (= 3^3)
configuration combinations. To implement this we need 3 configuration
nobs with 3 values (on, off, both).

Thoughts?
-Jose




There are only 8 possible configurations and they are nicely ordered  
in

terms of severity. So I don't see this as a problem. Also, if you went
with
a combinatorial approach, shouldn't it be 2^8 = 256, not 3^3 = 27  
values?



Yes. If you want to enable and disable each individual "level" then
you need 8 configuration options which leads to 2^8.

I suggested 3^3 as a more reasonable options that matches how the
developer is logging but doesn't give you as much expressiveness as
the 2^8 option.



In practice, all you'd need to take is a flag with the desired levels.  
i.e.


// Automatically set logging levels using the standard severity ordering
config.minSeverity(Severity.Warning);

// Manually set the logging levels
config.setSeverities(Severity.Warning|
Severity.Error|
Severity.Critical|
Severity.Severe|
Severity.Fatal);

I don't see the problem with including both methods and a large  
advantage to

having a standardized severity framework.


Interesting. If you find this useful, I think we can add this in a
future release as it shouldn't break existing modules that maybe using
the library.


This began as a discussion regarding Richard's organization of logging  
severity. That organization isn't something that can be trivially included  
at a later date.

Re: Extend vector ops to boolean operators?

2012-03-06 Thread Kapps


On Tuesday, 6 March 2012 at 20:28:40 UTC, H. S. Teoh wrote:

It'd be really cool if I could do this:

void func(int[] vector, int[] bounds) {
assert(vector[] >= 0 && vector[] < bounds[]);
...
}

Is there any reason why we shouldn't implement this?


T


Would this be possible with UFCS?

int opCmp(T)T([] array, T element) { ... }
int opCmp(T)(T[] array1, T[] array2) { ... }

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

On Tue, Mar 6, 2012 at 1:08 PM, Brad Roberts  wrote:
> On Tue, 6 Mar 2012, Jose Armando Garcia wrote:
>
>> Future:
>>
>> 1. Allowing filtering of regular log messages (like info, warning,
>> etc) based on the module. Similar to how vlog works.
>
> Once you add module filtering to the regularly log messages, what's the
> point of having the separate vlog?  I think this needs to be figured out
> before merge, not at some vague future.
>

That is true the need for vlog is lessen from a configuration point of
view but not from a performance point of view.

Adding module filtering to info, warning, etc increases the
computational cost of determining if you should log. Right now that
computational cost is constant. It is equal to a comparison operation.
If you want module base filtering the computational complexity will
probably be O(n + l) where n is the number of modules/entry in the
filter and l is the minimum between the length of the module/file name
and the length of the filters.

This makes info, warning, error a great tool to use in production
across your program. While you can use vlog on a case by case basis in
testing environments.

Thanks,
-Jose

>> Fix now:
>>
>> 1. Add thread name attribute to the default logger
>> 2. Check that the example compile
>> 3. Come up with a better name for Rich and rich template
>> 4. Add @safe pure nothrow const to as many methods as possible
>> 5. Remove check when setting Configuration.logger
>
> I still believe pretty strongly that the logger must not affect
> application flow, ie, not throw or exit the app.  From the feed back, I am
> not alone in thinking that.  I don't believe that "well, don't use those
> log levels" is a workaround if for no other reason that there will be
> libraries that contain them and that becomes a "dont use those libraries
> either" response.
>
> My 2 cents,
> Brad
>

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

On Tue, Mar 6, 2012 at 12:43 PM, Sean Kelly  wrote:
> On Mar 6, 2012, at 11:39 AM, Jose Armando Garcia wrote:
>
>> Seriously everyone. What are we spending some much effort on this?
>> What is wrong with:
>>
>> import log = std.log;
>> log.info("cool");
>
> Why should the default be unqualified names?  Is this simply a desire to not 
> change std.log so we can just get it in already?

What are you proposing?

struct Log {
  static alias log!Severity.info info;
  ...
}

I am not exactly sure when this idiom became popular. I don't know if
this is an C++ idiom or a Java idiom but I do know that it is a broken
hack. C++ developers use it because the name-spacing facility is
limiting. Java uses it because everything is a class and they don't
have the concept of compile time objects. We don't need this hack in
D. D's module mechanism make this C++/Java idiom unnecessary.

Thanks,
-Jose

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread deadalnix


Le 06/03/2012 21:00, Timon Gehr a écrit :

On 03/06/2012 07:13 PM, 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...)



It is not only about single names, but also about how many times you
have to spell them out in short intervals.

try{
SqlConstraintViolatedExceptionFactoryWrapper
sqlConstraintViolatedExceptionFactoryWrapper = new
SqlConstraintViolatedExceptionFactoryWrapper(new
SqlConstraintViolatedExceptionFactory(...));
SqlConstraintViolatedException sqlConstraintViolatedException =
sqlConstraintViolatedExceptionFactory.createSqlConstraintViolatedException(...);

throw sqlConstraintViolatedException;
}catch(SqlConstraintViolatedExceptionFactoryWrapperException e){
// ...
}catch(SqlConstraintViolatedExceptionFactoryException e){
// ...
}

Deliberately over-dramatized.


As I said, names comes in a context. Overly long names tell about the 
fact that the name isn't at the right place and things should be 
refactored, to provide a nice place to that named stuff.


auto helps too.

Re: Extend vector ops to boolean operators?

2012-03-06 Thread Simen Kjærås


On Tue, 06 Mar 2012 21:35:11 +0100, Timon Gehr  wrote:


On 03/06/2012 09:30 PM, H. S. Teoh wrote:

It'd be really cool if I could do this:

void func(int[] vector, int[] bounds) {
assert(vector[]>= 0&&  vector[]<  bounds[]);
...
}

Is there any reason why we shouldn't implement this?


T



Comparing arrays already does lexical-style comparison (which makes  
sense).


Comparing two arrays makes sense, absolutely. Comparing one T[] and
one T currently does not. Also, foo[] already changes the behavior of
operators on foo, making it do a per-element compare would be in line
with this pattern.

This is also already in bugzilla:
http://d.puremagic.com/issues/show_bug.cgi?id=5636

Re: Extend vector ops to boolean operators?

2012-03-06 Thread Sean Cavanaugh


On 3/6/2012 2:30 PM, H. S. Teoh wrote:

It'd be really cool if I could do this:

void func(int[] vector, int[] bounds) {
assert(vector[]>= 0&&  vector[]<  bounds[]);
...
}

Is there any reason why we shouldn't implement this?


T



This same problem exists for making proper syntactical sugar for simd 
comparison functions.


!= ==  (opEquals is required to return a bool)

and

<= >= < > (opCmp is required to return an int)


Granted its possible to live without the sugar but the code looks more 
like asm, and reading the code takes longer without the operators in it.

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

2012-03-06 Thread Brad Roberts

On Tue, 6 Mar 2012, Jose Armando Garcia wrote:

> Future:
> 
> 1. Allowing filtering of regular log messages (like info, warning,
> etc) based on the module. Similar to how vlog works.

Once you add module filtering to the regularly log messages, what's the 
point of having the separate vlog?  I think this needs to be figured out 
before merge, not at some vague future.

> Fix now:
> 
> 1. Add thread name attribute to the default logger
> 2. Check that the example compile
> 3. Come up with a better name for Rich and rich template
> 4. Add @safe pure nothrow const to as many methods as possible
> 5. Remove check when setting Configuration.logger

I still believe pretty strongly that the logger must not affect 
application flow, ie, not throw or exit the app.  From the feed back, I am 
not alone in thinking that.  I don't believe that "well, don't use those 
log levels" is a workaround if for no other reason that there will be 
libraries that contain them and that becomes a "dont use those libraries 
either" response.

My 2 cents,
Brad

Re: dereferencing null

2012-03-06 Thread Mantis


06.03.2012 8:04, Chad J пишет:

On 03/06/2012 12:07 AM, Jonathan M Davis wrote:


If you dereference a null pointer, there is a serious bug in your 
program.

Continuing is unwise. And if it actually goes so far as to be a segfault
(since the hardware caught it rather than the program), it is beyond 
a doubt
unsafe to continue. On rare occasion, it might make sense to try and 
recover
from dereferencing a null pointer, but it's like catching an 
AssertError. It's
rarely a good idea. Continuing would mean trying to recover from a 
logic error
in your program. Your program obviously already assumed that the 
variable
wasn't null, or it would have checked for null. So from the point of 
view of

your program's logic, you are by definition in an undefined state, and
continuing will have unexpected and potentially deadly behavior.

- Jonathan M Davis


This could be said for a lot of things: array-out-of-bounds 
exceptions, file-not-found exceptions, conversion exception, etc.  If 
the programmer thought about it, they would have checked the array 
length, checked for file existence before opening it, been more 
careful about converting things, etc.


It's different: with array-out-of-bounds there's no hardware detection, 
so its either checked in software or unchecked (in best case you'll have 
access violation or segfault, but otherwise going past the bounds of 
array leads to undefined behavior). Both file-not-found and conv 
exceptions often rely on user's input, in which case they do not 
necessarily mean bug in a program.


To me, the useful difference between fatal and non-fatal things is how 
well isolated the failure is.  Out of memory errors and writes into 
unexpected parts of memory are very bad things and can corrupt 
completely unrelated sections of code.  The other things I've 
mentioned, null-dereference included, cannot do this.


Null-dereferences and such can be isolated to sections of code.  A 
section of code might become compromised by the dereference, but the 
code outside of that section is still fine and can continue working.


Example:
[...]
And if riskyShenanigans were to modify global state... well, it's no 
longer so well isolated anymore.  This is just a disadvantage of 
global state, and it will be true with many other possible exceptions 
too.


Long story short: I don't see how an unexpected behavior in one part 
of a program will necessarily create unexpected behavior in all parts 
of the program, especially when good encapsulation is practiced.


Thoughts?

If riskyShenanigans nullifies reference in a process, then it must check 
it before dereferencing. There's obviously a bug, and if program will 
leave a proper crash log you shouldn't have problems finding and fixing 
this bug. If you don't have access to function's source, then you cannot 
guarantee it's safeness and isolation, so recovering from exception is 
unsafe.

Re: Extend vector ops to boolean operators?

On Tue, Mar 06, 2012 at 09:35:11PM +0100, Timon Gehr wrote:
> On 03/06/2012 09:30 PM, H. S. Teoh wrote:
> >It'd be really cool if I could do this:
> >
> > void func(int[] vector, int[] bounds) {
> > assert(vector[]>= 0&&  vector[]<  bounds[]);
> > ...
> > }
> >
> >Is there any reason why we shouldn't implement this?
[...]
> 
> Comparing arrays already does lexical-style comparison (which makes sense).

What I wanted is not lexicographic comparison, but per-element
comparison:

v[]>=0   means  v[0]>0 && v[1]>0 && v[2]>0 && ...
v[]

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

On Mar 6, 2012, at 11:39 AM, Jose Armando Garcia wrote:

> Seriously everyone. What are we spending some much effort on this?
> What is wrong with:
> 
> import log = std.log;
> log.info("cool");

Why should the default be unqualified names?  Is this simply a desire to not 
change std.log so we can just get it in already?

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

On Mar 6, 2012, at 11:59 AM, Jose Armando Garcia wrote:
> 
> Future:
> 
> 1. Allowing filtering of regular log messages (like info, warning,
> etc) based on the module. Similar to how vlog works.
> 2. Add support for custom line formatters
> 3. Talk about adding config.setSeverity(...) which is a union of all
> the severity specified. The logical OR operator is not going to work
> because internally the values are 0,1, etc. and we use them to index
> into an array. One solution is to pass an array to
> config.setSeverity(…)

For future enhancements, I'd just reference the docs for Boost.Log :-p

Re: Extend vector ops to boolean operators?

2012-03-06 Thread Timon Gehr


On 03/06/2012 09:30 PM, H. S. Teoh wrote:

It'd be really cool if I could do this:

void func(int[] vector, int[] bounds) {
assert(vector[]>= 0&&  vector[]<  bounds[]);
...
}

Is there any reason why we shouldn't implement this?


T



Comparing arrays already does lexical-style comparison (which makes sense).

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Adam D. Ruppe


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.

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

Extend vector ops to boolean operators?

It'd be really cool if I could do this:

void func(int[] vector, int[] bounds) {
assert(vector[] >= 0 && vector[] < bounds[]);
...
}

Is there any reason why we shouldn't implement this?


T

-- 
He who laughs last thinks slowest.

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Derek

On Wed, 07 Mar 2012 03:38:09 +1100, Adam D. Ruppe  
 wrote:



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


Should we use American or English spelling? Color verses Colour, for  
example?



--
Derek Parnell
Melbourne, Australia

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Timon Gehr


On 03/06/2012 07:13 PM, 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...)



It is not only about single names, but also about how many times you 
have to spell them out in short intervals.


try{
SqlConstraintViolatedExceptionFactoryWrapper 
sqlConstraintViolatedExceptionFactoryWrapper = new 
SqlConstraintViolatedExceptionFactoryWrapper(new 
SqlConstraintViolatedExceptionFactory(...));
SqlConstraintViolatedException sqlConstraintViolatedException = 
sqlConstraintViolatedExceptionFactory.createSqlConstraintViolatedException(...);

throw sqlConstraintViolatedException;
}catch(SqlConstraintViolatedExceptionFactoryWrapperException e){
// ...
}catch(SqlConstraintViolatedExceptionFactoryException e){
// ...
}

Deliberately over-dramatized.

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

2012-03-06 Thread David Nadlinger

On Tuesday, 6 March 2012 at 19:47:50 UTC, Andrei Alexandrescu 
wrote:

On 3/6/12 11:36 AM, Jose Armando Garcia wrote:

import someSymboleThatDoesntCollide = std.log;


I think this works better:

static import log = std.log;


Isn't this just another case of DMD silently accepting 
superfluous attributes/modifiers?


David

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

On Mon, Feb 13, 2012 at 7:50 AM, 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.
>

Hi everyone,

I have been tracking all the changes we need to make immediately and
things we can add in the future without break backward compatibility
if have access to trello go here:
https://trello.com/card/std-log/4f33d3c6542c156960533efb/1#

Exporting things form trello looks like a pain but here it is:

Future:

1. Allowing filtering of regular log messages (like info, warning,
etc) based on the module. Similar to how vlog works.
2. Add support for custom line formatters
3. Talk about adding config.setSeverity(...) which is a union of all
the severity specified. The logical OR operator is not going to work
because internally the values are 0,1, etc. and we use them to index
into an array. One solution is to pass an array to
config.setSeverity(...)

Fix now:

1. Add thread name attribute to the default logger
2. Check that the example compile
3. Come up with a better name for Rich and rich template
4. Add @safe pure nothrow const to as many methods as possible
5. Remove check when setting Configuration.logger

Note: There were a few other things that were suggested here that I
have already fixed. Need to look at my commits for this.

Thanks,
-Jose

> ---
> Code:
> https://github.com/jsancio/phobos/commit/d114420e0791c704f6899d81a0293cbd3cc8e6f5
> Docs: http://jsancio.github.com/phobos/phobos/std_log.html
>
> Known remaining issues:
>  - Proof-reading of the docs is required.
>  - Not yet fully tested on Windows.
>
> Depends on: https://github.com/D-Programming-Language/druntime/pull/141
> (will be part of 2.058)
> ---
>
> Earlier drafts of this library were discussed last year, just search the NG
> and ML archives for "std.log".
>
> I think getting this right is vitally important so that we can avoid an
> abundance of partly incompatible logging libraries like in Java. Thus, I'd
> warmly encourage everyone to actively try out the module or compare it with
> any logging solution you might already be using in your project.
>
> Please post all feedback in this thread, and remember: Although
> comprehensive reviews are obviously appreciated, short comments are very
> welcome as well!
>
> David

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

On Tue, Mar 06, 2012 at 11:45:47AM -0800, Andrei Alexandrescu wrote:
> On 3/6/12 11:39 AM, Jose Armando Garcia wrote:
> >Seriously everyone. What are we spending some much effort on this?
> >What is wrong with:
> >
> >import log = std.log;
> >log.info("cool");
> 
> Indeed I think that should be fine.
[...]

+1. I think std.log is ready to merge, as is.


T

-- 
Questions are the beginning of intelligence, but the fear of God is the 
beginning of wisdom.

Re: Arbitrary abbreviations in phobos considered ridiculous

On Tue, Mar 06, 2012 at 08:47:11PM +0100, Alex Rønne Petersen wrote:
[...]
> My reply to all of the above: Is 'etc' not a universally well-known
> abbreviation? ;)
[...]

lol... now you're giving me ideas for another esolang, called Etc.
Recognized tokens are 'etc', and recognized keywords are 'etc'.
Statements are of the form 'etc'. Multiple occurrences of 'etc' can be
shortened to just 'etc', so here's a hello world program:

etc

And here's an Etc compiler written in Etc:

etc

And here's a program to cure world hunger and solve world peace:

etc

Isn't that a great language?! :P

T

-- 
The two rules of success: 1. Don't tell everything you know. -- YHL

Re: Arbitrary abbreviations in phobos considered ridiculous

2012-03-06 Thread Alex Rønne Petersen


On 06-03-2012 19:49, Nick Sabalausky wrote:

"H. S. Teoh"  wrote in message
news:mailman.70.1331058850.4860.digitalmar...@puremagic.com...


But my point stands, that I find many of
these names just way too long for my tastes. Like BufferedOutputStream.
Ugh. I mean, we're writing programs here, not
essays.



Exactly. Totally agree. I hate programming langauge arguments that amount to
"It's not like English!". Yea? So what? It *isn't* English and it's not
supposed to be!

It'd be a hell of a lot easier for someone unfamiliar with mathematical
symbols to read this:

5 times quantity 7 plus 3 end of quantity

Erm, I mean:

Five times quantity seven plus three end of quantity

Look! It's just normal English! And the editor can highlight it properly! No
need to remember arbitrary symbols that aren't spelled-out! I mean, shit,
how does a vertical and horizontal line mean "plus"? I can't remember that!

But obviously that would be stupid. You just (trivially) learn that + is
shorthand for "plus", ) is shorthand for "end of quantity", etc. (erm,
excuse me..."et cetera"), and that verbose mess becomes the far, FAR more
readable:

5 * (7+3)





My reply to all of the above: Is 'etc' not a universally well-known 
abbreviation? ;)


--
- Alex

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


On 3/6/12 11:36 AM, Jose Armando Garcia wrote:

import someSymboleThatDoesntCollide = std.log;


I think this works better:

static import log = std.log;


Andrei

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