May 22, 2013
On Wed, May 22, 2013 at 10:19 AM, Nick Sabalausky < SeeWebsiteToContactMe@semitwist.com> wrote:

> On Wed, 22 May 2013 10:06:46 -0700
> Timothee Cour <thelastmammoth@gmail.com> wrote:
>
> > it's only module level granularity.
> >
> > I agree that a library solution is the way to go, however there needs
> > to be a way to have finer granularity, ie being able to call
> > individual unittests. I gave the reasons in the 2nd post in this
> > thread. Syntax would be: unittest(test_fun){...}
> > having a short syntax such as this will make people use it.
> >
> > digressing, I wish there would be a simple non-anonymous way to vote for such features, to see whether most people agree/disagree. It's easier than voting by email, which invariably gets lost in digressions (as I'm doing here).
> >
>
> Bugzilla has a voting system <http://d.puremagic.com/issues/>. Every user has up to 10 votes to place on whatever tickets they want.
>
> I'm aware of that and used it. I find it limited (voting limits, no -1)
and harder to use than necessary. It should be a 1 click operation.


May 22, 2013
On Tuesday, May 21, 2013 14:34:37 Nick Sabalausky wrote:
> On Tue, 21 May 2013 19:02:19 +0200
> 
> Jacob Carlborg <doob@me.com> wrote:
> > On 2013-05-21 03:52, Nick Sabalausky wrote:
> > > Y'know what we need? This compiler flag: -unittest=pagkage.name.*
> > 
> > That exact syntax will probably cause some problems with the shell.
> 
> Ugh, yea, that's right. I love the unix shell, but I'm convinced that having the shell expand globs was a colossal mistake.

Quotes are your friend.

-unittest="package.name.*"

Problem solved. _Not_ having the shell expand globs would be horrific. Every program would then have to handle that internally, and the results would be incredibly inconsistent.

- Jonathan M Davis
May 22, 2013
On Tue, May 21, 2013 at 08:56:13PM +0200, Jacob Carlborg wrote:
> On 2013-05-21 20:34, Nick Sabalausky wrote:
> 
> >Ugh, yea, that's right. I love the unix shell, but I'm convinced that having the shell expand globs was a colossal mistake.
> 
> I think it's mostly very handy.
[...]

I'm a total unix shell geek (my X11 environment is basically a glorified terminal, no window decorations, everything is maximized, no mouse dependence, etc.), but I have to agree that having the shell expand globs was a mistake.

The *reasoning* behind it was NOT a mistake: you want a standard syntax for wildcards across the board, that users can rely on, instead of cp taking one syntax, mv another syntax, and ls yet another syntax. (One example of this latter is the sheer number of regex variations on a typical unix installation, many of which are mutually incompatible, or compatible but with subtle variations that nobody can remember.  It's an embarrassment!)

The *chosen solution*, though, was mistake. The correct solution was to have a globbing function in a standard library that programs would use to expand wildcards.  That's what shared libs are for!!! Having the shell expand wildcards always, by default, causes stupid leaning toothpick syndromes when you *don't* want something expanded. Indeed, the eagerness with which the shell interpolates *everything* is a major annoyance. The worst example is writing bash hexadecimal escapes. If you want a literal \x0d, say, you could just write it like that. But if you're using echo, it has to survive another layer of interpolation, so it has to be \\x0d. But lest this simple case mislead you, let me point out that if you write "echo \\00", that will *not* echo a binary zero... because something, somewhere, seems to specially want to interpolate (or interpret) binary zeroes in an unexpected place; the correct way to write it is \\0000. But if this echo has to pass through, say, a shell 'read' command unscathed, yet another layer of interpolation has to be guarded against, and it becomes a monstrous \\\\0000. And when you want a literal backslash, it's yet another set of exceptions to an otherwise simplistic escape sequence.

If strings were only interpolated in the final piece of code that needs it to be interpolated -- like inside the program that needs to expand wildcards by calling the shared lib's glob function -- things would be a LOT saner.


T

-- 
One Word to write them all,
One Access to find them,
One Excel to count them all,
And thus to Windows bind them.
-- Mike Champion
May 23, 2013
On Wed, 22 May 2013 13:06:46 -0400, Timothee Cour <thelastmammoth@gmail.com> wrote:

> it's only module level granularity.

The compiler needs to help to fix this, as far as I know, it simply lumps all the unit tests into one function, but I don't remember if that's still true.

But I think we need at *least* one more important feature (one that Walter had agreed should be done when we discussed it at dconf):

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

Then you could mark unit tests with @attributes, and annotate how they should be run by the runtime.

-Steve
May 23, 2013
On Wed, 22 May 2013 14:26:53 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Tuesday, May 21, 2013 14:34:37 Nick Sabalausky wrote:
>> On Tue, 21 May 2013 19:02:19 +0200
>>
>> Jacob Carlborg <doob@me.com> wrote:
>> > On 2013-05-21 03:52, Nick Sabalausky wrote:
>> > > Y'know what we need? This compiler flag:
>> > > -unittest=pagkage.name.*
>> >
>> > That exact syntax will probably cause some problems with the shell.
>>
>> Ugh, yea, that's right. I love the unix shell, but I'm convinced that
>> having the shell expand globs was a colossal mistake.
>
> Quotes are your friend.
>
> -unittest="package.name.*"

ahem...

-unittest='package.name.*'

:)

And TBH, you would have to have a file named literally "-unittest=package.name.xyz" for that to actually be expanded by the shell.  I don't think it really would be an issue.

-Steve
May 23, 2013
On Wed, 22 May 2013 17:51:49 -0400, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> The correct solution was to
> have a globbing function in a standard library that programs would use
> to expand wildcards.  That's what shared libs are for!!!

This might be the "correct" solution, but it's not the solution that would have worked :)  ESPECIALLY in open-source-land.

-Steve
May 23, 2013
On Wednesday, May 22, 2013 20:26:25 Steven Schveighoffer wrote:
> On Wed, 22 May 2013 14:26:53 -0400, Jonathan M Davis <jmdavisProg@gmx.com>
> > Quotes are your friend.
> > 
> > -unittest="package.name.*"
> 
> ahem...
> 
> -unittest='package.name.*'
> 
> :)

Actually, in this case, there's no difference. The globbing won't occur inside either type of quotes.

> And TBH, you would have to have a file named literally "-unittest=package.name.xyz" for that to actually be expanded by the shell. I don't think it really would be an issue.

True enough.

- Jonathan M Davis
May 23, 2013
On Wed, 22 May 2013 20:36:09 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Wednesday, May 22, 2013 20:26:25 Steven Schveighoffer wrote:
>> On Wed, 22 May 2013 14:26:53 -0400, Jonathan M Davis <jmdavisProg@gmx.com>
>> > Quotes are your friend.
>> >
>> > -unittest="package.name.*"
>>
>> ahem...
>>
>> -unittest='package.name.*'
>>
>> :)
>
> Actually, in this case, there's no difference. The globbing won't occur inside
> either type of quotes.

Oh, that's right, it's variable expansion that occurs inside of doubles but not singles, not globbing.

Don't I look dumb now :)  And now I have these stupid -unittest=blah.x files on my home directory...

-Steve
May 23, 2013
On Wed, May 22, 2013 at 08:27:50PM -0400, Steven Schveighoffer wrote:
> On Wed, 22 May 2013 17:51:49 -0400, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> 
> >The correct solution was to have a globbing function in a standard library that programs would use to expand wildcards.  That's what shared libs are for!!!
> 
> This might be the "correct" solution, but it's not the solution that would have worked :)  ESPECIALLY in open-source-land.
[...]

True. But in open source land you just submit patches if something doesn't call glob that should. Or in the worst case, fork. :-P  But OK, I concede that realistically speaking, this would be unworkable.

Regardless, I've oft mused about writing my own shell that does *not* glob by default. It would, of course, have convenient ways of doing that (perhaps a single-char prefix/suffix that turns it on). This would be done in a controlled manner so you could control exactly when and where interpolation happens. (But I may just end up reinvent Perl though. :-P)


T

-- 
There are four kinds of lies: lies, damn lies, and statistics.
May 23, 2013
On 05/22/2013 01:26 PM, Jonathan M Davis wrote:
> On Tuesday, May 21, 2013 14:34:37 Nick Sabalausky wrote:
>> On Tue, 21 May 2013 19:02:19 +0200
>>
>> Jacob Carlborg <doob@me.com> wrote:
>>> On 2013-05-21 03:52, Nick Sabalausky wrote:
>>>> Y'know what we need? This compiler flag: -unittest=pagkage.name.*
>>>
>>> That exact syntax will probably cause some problems with the shell.
>>
>> Ugh, yea, that's right. I love the unix shell, but I'm convinced that having the shell expand globs was a colossal mistake.
> 
> Quotes are your friend.
> 
> -unittest="package.name.*"
> 
> Problem solved. _Not_ having the shell expand globs would be horrific. Every program would then have to handle that internally, and the results would be incredibly inconsistent.
> 
> - Jonathan M Davis

Just get zsh, apparently it doesn't glob unless it actually matches something.

So unless there's a file named -unittest="package.name.version" it's all good.