www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - External lib unittests: they're killin me!

reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
Y'know what we need? This compiler flag:

   -unittest=pagkage.name.*

Damn near every codebase in D uses "unittest{}" sections. Obviously
that's good.

But it's also bad:

I cannot flip on unittests for my project (where "I" and "my" can be
substituted with the name of any D user) without *also* flipping on
unittests for every source-library used, transitively. Unless the lib
versions-out their unittests with "version(Unittest_MyLibXXX)"...And
none of them do. (well, mostly)

This *can* be fine, *when*:

- They're all fast.

- Their sum doesn't make DMD's memory usage go kabloom.

- They all have all their prereqs already setup (sometimes the need for
  some configuration isn't easily avoidable, example: setting up a DB
  user/login).

- And none of them have any failures...on the *exact*
  OS/arch/compiler/compiler-version combination that I happen to be
  using. Oh, and the exact versions of any other dependent libs.

We could say "Let's just recommend good style is to version out your
unittest blocks". But that's programming by convention: All it takes is
one lib not playing ball, or one unittest in one lib that just happened
to forget it, and then the poor user is back to "ad-hoc patching"-land.
And it's boiler-plate, anyway.

So alright...Who's with me?!!! "Yeaaaa......!!!!!" (<-- Belushi running
out the door)
May 20 2013
next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--001a11c2ce16920f8204dd317552
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 20, 2013 at 6:52 PM, Nick Sabalausky <
SeeWebsiteToContactMe semitwist.com> wrote:

 Y'know what we need? This compiler flag:

    -unittest=pagkage.name.*

I would like that as well. Here's a workaround in the meantime: dmd -c -unittest a; dmd -c b; dmd -oftest -main -unittest *.o ./test => will only run unittest of a, not b. Another thing we need is named unittests: unittest(my_test_1){...} It's been requested so many times and I still don't get the arguments against them. Here's a common workflow: 1) I write a function fun. 2) I write a function test_fun that tests fun. 3) I run test_fun in isolation (saves time, only need to run that) 4) Later on, once its debugged I turn test_fun into a unittest. Having unittest(test_fun){...} would simplify this routine.
 Damn near every codebase in D uses "unittest{}" sections. Obviously
 that's good.

 But it's also bad:

 I cannot flip on unittests for my project (where "I" and "my" can be
 substituted with the name of any D user) without *also* flipping on
 unittests for every source-library used, transitively. Unless the lib
 versions-out their unittests with "version(Unittest_MyLibXXX)"...And
 none of them do. (well, mostly)

 This *can* be fine, *when*:

 - They're all fast.

 - Their sum doesn't make DMD's memory usage go kabloom.

 - They all have all their prereqs already setup (sometimes the need for
   some configuration isn't easily avoidable, example: setting up a DB
   user/login).

 - And none of them have any failures...on the *exact*
   OS/arch/compiler/compiler-version combination that I happen to be
   using. Oh, and the exact versions of any other dependent libs.

 We could say "Let's just recommend good style is to version out your
 unittest blocks". But that's programming by convention: All it takes is
 one lib not playing ball, or one unittest in one lib that just happened
 to forget it, and then the poor user is back to "ad-hoc patching"-land.
 And it's boiler-plate, anyway.

 So alright...Who's with me?!!! "Yeaaaa......!!!!!" (<-- Belushi running
 out the door)

--001a11c2ce16920f8204dd317552 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Mon, May 20, 2013 at 6:52 PM, Nick Sa= balausky <span dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsiteToContactMe semi= twist.com" target=3D"_blank">SeeWebsiteToContactMe semitwist.com</a>&gt;</s= pan> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Y&#39;know what we need? This compiler flag:= <br> <br> =A0 =A0-unittest=3Dpagkage.name.*<br></blockquote><div><br></div><div>I wou= ld like that as well.</div><div><br></div><div>Here&#39;s a workaround in t= he meantime:</div><div><div>dmd -c -unittest a;</div></div><div><div>dmd -c= b;</div> </div><div>dmd -oftest -main -unittest *.o</div><div>./test =3D&gt; will on= ly run unittest of a, not b.</div><div><br></div><div>Another thing we need= is named unittests:</div><div><br></div><div>unittest(my_test_1){...}</div=

39;t get the arguments against them.</div><div>Here&#39;s a common workflow= :</div><div><br></div><div>1) I write a function fun.</div><div>2) I write = a function test_fun that tests fun.</div> <div>3)=A0I run test_fun in isolation (saves time, only need to run that)</= div><div>4)=A0Later on, once its debugged I turn test_fun into a unittest.<= /div><div><br></div><div>Having unittest(test_fun){...} would simplify this= routine.</div> <div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Damn near every codebase in D uses &quot;unittest{}&quot; sections. Obvious= ly<br> that&#39;s good.<br> <br> But it&#39;s also bad:<br> <br> I cannot flip on unittests for my project (where &quot;I&quot; and &quot;my= &quot; can be<br> substituted with the name of any D user) without *also* flipping on<br> unittests for every source-library used, transitively. Unless the lib<br> versions-out their unittests with &quot;version(Unittest_MyLibXXX)&quot;...= And<br> none of them do. (well, mostly)<br> <br> This *can* be fine, *when*:<br> <br> - They&#39;re all fast.<br> <br> - Their sum doesn&#39;t make DMD&#39;s memory usage go kabloom.<br> <br> - They all have all their prereqs already setup (sometimes the need for<br> =A0 some configuration isn&#39;t easily avoidable, example: setting up a DB= <br> =A0 user/login).<br> <br> - And none of them have any failures...on the *exact*<br> =A0 OS/arch/compiler/compiler-version combination that I happen to be<br> =A0 using. Oh, and the exact versions of any other dependent libs.<br> <br> We could say &quot;Let&#39;s just recommend good style is to version out yo= ur<br> unittest blocks&quot;. But that&#39;s programming by convention: All it tak= es is<br> one lib not playing ball, or one unittest in one lib that just happened<br> to forget it, and then the poor user is back to &quot;ad-hoc patching&quot;= -land.<br> And it&#39;s boiler-plate, anyway.<br> <br> So alright...Who&#39;s with me?!!! &quot;Yeaaaa......!!!!!&quot; (&lt;-- Be= lushi running<br> out the door)<br> <br> </blockquote></div><br> --001a11c2ce16920f8204dd317552--
May 20 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-21 03:52, Nick Sabalausky wrote:
 Y'know what we need? This compiler flag:

     -unittest=pagkage.name.*

I wouldn't say no to that flag. Hmm, I'm wondering if it's possible to get the same functionality by implementing your own unit test runner. -- /Jacob Carlborg
May 20 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 I wouldn't say no to that flag.

D built-in unittests are rather under-engineered. Some standard way to run only part of the unittests is necessary. Bye, bearophile
May 20 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--001a11c2f402195d0004dd35cf30
Content-Type: text/plain; charset=ISO-8859-1

On Tue, May 21, 2013 at 12:35 AM, Jens Mueller <jens.k.mueller gmx.de>wrote:

 Jacob Carlborg wrote:
 On 2013-05-21 03:52, Nick Sabalausky wrote:
Y'know what we need? This compiler flag:

    -unittest=pagkage.name.*

I wouldn't say no to that flag. Hmm, I'm wondering if it's possible to get the same functionality by implementing your own unit test runner.

It is possible and we shouldn't push functionality into the compiler when the issue is solvable in a library. https://github.com/jkm/dtest (shameless plug) has the command line switch --include to specify which modules should be tested. Jens

That looks good, will try. However it doesn't address the issue of individual unittests (see 2nd post). Compiler support is needed for named unittests. --001a11c2f402195d0004dd35cf30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Tue, May 21, 2013 at 12:35 AM, Jens M= ueller <span dir=3D"ltr">&lt;<a href=3D"mailto:jens.k.mueller gmx.de" targe= t=3D"_blank">jens.k.mueller gmx.de</a>&gt;</span> wrote:<br><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">Jacob Carlborg wrote:<br> &gt; On 2013-05-21 03:52, Nick Sabalausky wrote:<br> &gt; &gt;Y&#39;know what we need? This compiler flag:<br> &gt; &gt;<br> &gt; &gt; =A0 =A0-unittest=3Dpagkage.name.*<br> &gt;<br> &gt; I wouldn&#39;t say no to that flag. Hmm, I&#39;m wondering if it&#39;s= possible<br> &gt; to get the same functionality by implementing your own unit test<br> &gt; runner.<br> <br> </div></div>It is possible and we shouldn&#39;t push functionality into the= compiler<br> when the issue is solvable in a library.<br> <a href=3D"https://github.com/jkm/dtest" target=3D"_blank">https://github.c= om/jkm/dtest</a> (shameless plug) has the command line<br> switch --include to specify which modules should be tested.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> Jens<br> </font></span></blockquote></div><br><div>That looks good, will try. Howeve= r it doesn&#39;t address the issue of individual unittests (see 2nd post). = Compiler support is needed for named unittests.</div><div><br></div> --001a11c2f402195d0004dd35cf30--
May 21 2013
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Timothee Cour wrote:
 On Tue, May 21, 2013 at 12:35 AM, Jens Mueller <jens.k.mueller gmx.de>wrote:
 
 Jacob Carlborg wrote:
 On 2013-05-21 03:52, Nick Sabalausky wrote:
Y'know what we need? This compiler flag:

    -unittest=pagkage.name.*

I wouldn't say no to that flag. Hmm, I'm wondering if it's possible to get the same functionality by implementing your own unit test runner.

It is possible and we shouldn't push functionality into the compiler when the issue is solvable in a library. https://github.com/jkm/dtest (shameless plug) has the command line switch --include to specify which modules should be tested. Jens

That looks good, will try. However it doesn't address the issue of individual unittests (see 2nd post). Compiler support is needed for named unittests.

Johannes Pfau had a pull request for that very feature. But I'd argue running separate unittests is the only feature that is strictly needed from the compiler. I mean to have named unittests you can use either UDAs name("myname") unittest { } or something like unittest { unittestName("myname"); } Either way this is already doable in a good manner. If there was a possibility to execute individual unittests it'll be straightforward to add named unittests to dtest. dmd developers are a scarce resource. Jens
May 21 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-21 09:35, Jens Mueller wrote:

 It is possible and we shouldn't push functionality into the compiler
 when the issue is solvable in a library.
 https://github.com/jkm/dtest (shameless plug) has the command line
 switch --include to specify which modules should be tested.

I'm using an rspec influenced library I wrote: https://github.com/jacob-carlborg/dspec Not very advanced. I still need a good way to run the tests. Now I'm just using a shell script. To see it in action, have a look here: https://github.com/jacob-carlborg/orange/tree/master/tests Yes, it does some operator overload abuse. -- /Jacob Carlborg
May 21 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-05-21 14:34, Jens Mueller wrote:

 I have already seen it. I'm also looking for a more natural way to write
 tests. dspec goes in that direction but I found its syntax
 (describe("...") in {} and it("...") in {}) not convincing.

I really, REALLY would like to be able to have a syntax like this: describe("foo") { it("bar") { // asserts } }
 I was thinking about something like
 a.should == 10;
 or similar. But that has its own problems. Anyway writing/executing
 unittests in D needs to become more fun.

That syntax is the next step for dspec. But that would be put inside the it-blocks, not instead of. It would be instead of the asserts. -- /Jacob Carlborg
May 21 2013
prev sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Jacob Carlborg wrote:
 On 2013-05-21 09:35, Jens Mueller wrote:
 
It is possible and we shouldn't push functionality into the compiler
when the issue is solvable in a library.
https://github.com/jkm/dtest (shameless plug) has the command line
switch --include to specify which modules should be tested.

I'm using an rspec influenced library I wrote: https://github.com/jacob-carlborg/dspec Not very advanced. I still need a good way to run the tests. Now I'm just using a shell script. To see it in action, have a look here: https://github.com/jacob-carlborg/orange/tree/master/tests Yes, it does some operator overload abuse.

I have already seen it. I'm also looking for a more natural way to write tests. dspec goes in that direction but I found its syntax (describe("...") in {} and it("...") in {}) not convincing. I was thinking about something like a.should == 10; or similar. But that has its own problems. Anyway writing/executing unittests in D needs to become more fun. Jens
May 21 2013
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Jacob Carlborg wrote:
 On 2013-05-21 03:52, Nick Sabalausky wrote:
Y'know what we need? This compiler flag:

    -unittest=pagkage.name.*

I wouldn't say no to that flag. Hmm, I'm wondering if it's possible to get the same functionality by implementing your own unit test runner.

It is possible and we shouldn't push functionality into the compiler when the issue is solvable in a library. https://github.com/jkm/dtest (shameless plug) has the command line switch --include to specify which modules should be tested. Jens
May 21 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 20 May 2013 22:46:42 -0400, Timothee Cour  
<thelastmammoth gmail.com> wrote:

 On Mon, May 20, 2013 at 6:52 PM, Nick Sabalausky <
 SeeWebsiteToContactMe semitwist.com> wrote:

 Y'know what we need? This compiler flag:

    -unittest=pagkage.name.*

I would like that as well. Here's a workaround in the meantime: dmd -c -unittest a; dmd -c b; dmd -oftest -main -unittest *.o ./test => will only run unittest of a, not b.

This does not work if b is made of templates. -Steve
May 21 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 20 May 2013 21:52:51 -0400, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:

 So alright...Who's with me?!!! "Yeaaaa......!!!!!" (<-- Belushi running
 out the door)

I think we can handle this without compiler help. The runtime is responsible for running unit tests. It actually provides a hook to allow you to override the unit tests. See here: http://dlang.org/phobos/core_runtime.html#.Runtime.moduleUnitTester (set in a shared static ctor). All you have to do is just run the module's unit tests you desire. I would argue the "stock" unit test runner could be configured by an environment variable to be able to run/exclude whatever you want. This is eminently fixable in the library with a small pull request. -Steve
May 21 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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. -- /Jacob Carlborg
May 21 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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. -- /Jacob Carlborg
May 21 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
23-May-2013 01:51, H. S. Teoh пишет:
 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.

Windows had it in WinAPI - FindFirst/FindNext. Programmers basically had it yet it didn't mean they used it even half-consistently (nor it was complete glob pattern). -- Dmitry Olshansky
May 22 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 May 2013 14:34:37 -0400, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> 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.

Fully disagree! For free, every single command line application, including custom ones, handles expansion in exactly the same way. Compare to windows command line... -Steve
May 21 2013
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
parent 1100110 <0b1100110 gmail.com> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=3Dpagkage.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. =20 -unittest=3D"package.name.*" =20 Problem solved. _Not_ having the shell expand globs would be horrific. =

 program would then have to handle that internally, and the results woul=

 incredibly inconsistent.
=20
 - Jonathan M Davis

Just get zsh, apparently it doesn't glob unless it actually matches something. So unless there's a file named -unittest=3D"package.name.version" it's al= l good.
May 22 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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 22 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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 22 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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 22 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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 22 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 22 May 2013 21:58:38 -0400, 1100110 <0b1100110 gmail.com> wrote:

 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.

All shells do this. I don't know what the behavior would be otherwise. -Steve
May 22 2013
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 22 May 2013 at 18:27:07 UTC, Jonathan M Davis wrote:
 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.

Interesting... Does it expand wildcards when you execute the program with a syscall like evecve(2)?
May 23 2013
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Tuesday, 21 May 2013 at 18:58:33 UTC, Steven Schveighoffer 
wrote:
 Fully disagree!  For free, every single command line 
 application, including custom ones, handles expansion in 
 exactly the same way.  Compare to windows command line...

Something wrong with FindFirstFile and FindNextFile functions?
May 23 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 23 May 2013 09:49:59 -0400, Kagamin <spam here.lot> wrote:

 On Tuesday, 21 May 2013 at 18:58:33 UTC, Steven Schveighoffer wrote:
 Fully disagree!  For free, every single command line application,  
 including custom ones, handles expansion in exactly the same way.   
 Compare to windows command line...

Something wrong with FindFirstFile and FindNextFile functions?

No I mean, I want to pass in all the files in a directory to a windows command line tool. But the tool has to "opt in" to allow me to use wildcards. In other words, the tool receives "*.*" as a parameter, and it is responsible for expanding. If it doesn't, I'm SOL. Compare to Unix, I don't care what the tool supports, I am in control of the expressiveness of what I want to say. -Steve
May 23 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 23 May 2013 09:38:05 -0400, Kagamin <spam here.lot> wrote:

 On Wednesday, 22 May 2013 at 18:27:07 UTC, Jonathan M Davis wrote:
 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.

Interesting... Does it expand wildcards when you execute the program with a syscall like evecve(2)?

No, the shell expands wildcards, not the OS. -Steve
May 23 2013
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 23 May 2013 at 13:56:26 UTC, Steven Schveighoffer 
wrote:
 No I mean, I want to pass in all the files in a directory to a 
 windows command line tool.  But the tool has to "opt in" to 
 allow me to use wildcards.

What if the tool handles argv[1] and exits? Or writes to argv[2] if any.
 No, the shell expands wildcards, not the OS.

It was just a sarcastic comment about incredible consistency of wildcard expansion in linux.
May 23 2013
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
A simple file copy utility.

int main(string[] args)
{
   byte[] data = readFile(args[1]);
   writeFile(args[2],data);
   return 0;
}
May 23 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 23, 2013 at 06:21:59PM +0200, Kagamin wrote:
 On Thursday, 23 May 2013 at 13:56:26 UTC, Steven Schveighoffer
 wrote:
No I mean, I want to pass in all the files in a directory to a
windows command line tool.  But the tool has to "opt in" to allow me
to use wildcards.

What if the tool handles argv[1] and exits? Or writes to argv[2] if any.
No, the shell expands wildcards, not the OS.

It was just a sarcastic comment about incredible consistency of wildcard expansion in linux.

Exactly!! That's why I said that the chosen solution was wrong, even though the idea behind it (consistent wildcards across the board) was sound. Putting this expansion in the shell was just a poor choice. It should either be done by the program itself (via a common library routine to ensure consistency) or by the kernel (so exec*() will automatically inherit it). Putting it in the shell led to a series of consequences that eventually produced the stupid inconsistencies we have to deal with today. T -- If lightning were to ever strike an orchestra, it'd always hit the conductor first.
May 23 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 23 May 2013 12:29:53 -0400, Kagamin <spam here.lot> wrote:

 A simple file copy utility.

 int main(string[] args)
 {
    byte[] data = readFile(args[1]);
    writeFile(args[2],data);
    return 0;
 }

What is the point of this? -Steve
May 23 2013
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 23 May 2013 12:21:59 -0400, Kagamin <spam here.lot> wrote:

 On Thursday, 23 May 2013 at 13:56:26 UTC, Steven Schveighoffer wrote:
 No I mean, I want to pass in all the files in a directory to a windows  
 command line tool.  But the tool has to "opt in" to allow me to use  
 wildcards.

What if the tool handles argv[1] and exits? Or writes to argv[2] if any.

Then you can't pass it more than one parameter? I don't get the point.
 No, the shell expands wildcards, not the OS.

It was just a sarcastic comment about incredible consistency of wildcard expansion in linux.

Having the expansion of wildcards built into the OS would be bad. I don't need to get into that. -Steve
May 23 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
May 21 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 21 May 2013 12:23:01 -0400
"Steven Schveighoffer" <schveiguy yahoo.com> wrote:

 On Mon, 20 May 2013 21:52:51 -0400, Nick Sabalausky  
 <SeeWebsiteToContactMe semitwist.com> wrote:
 
 So alright...Who's with me?!!! "Yeaaaa......!!!!!" (<-- Belushi
 running out the door)

I think we can handle this without compiler help. The runtime is responsible for running unit tests. It actually provides a hook to allow you to override the unit tests. See here: http://dlang.org/phobos/core_runtime.html#.Runtime.moduleUnitTester (set in a shared static ctor). All you have to do is just run the module's unit tests you desire.

Neat, I had no idea.
 I would argue the "stock" unit test runner could be configured by an  
 environment variable to be able to run/exclude whatever you want.
 This is eminently fixable in the library with a small pull request.
 

I think that definitely sounds like the way to go.
May 21 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/21/13, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:
 Y'know what we need? This compiler flag:

    -unittest=pagkage.name.*

FWIW I work around this by implementing the unit test runner function. I've mentioned this here: http://www.reddit.com/r/programming/comments/1edih2/dconf_2013_day_1_talk_4_writing_testable_code_in/c9zg3ry
May 21 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--001a11c209d245440e04dd519748
Content-Type: text/plain; charset=ISO-8859-1

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


On Tue, May 21, 2013 at 11:36 AM, Nick Sabalausky <
SeeWebsiteToContactMe semitwist.com> wrote:

 On Tue, 21 May 2013 12:23:01 -0400
 "Steven Schveighoffer" <schveiguy yahoo.com> wrote:

 On Mon, 20 May 2013 21:52:51 -0400, Nick Sabalausky
 <SeeWebsiteToContactMe semitwist.com> wrote:

 So alright...Who's with me?!!! "Yeaaaa......!!!!!" (<-- Belushi
 running out the door)

I think we can handle this without compiler help. The runtime is responsible for running unit tests. It actually provides a hook to allow you to override the unit tests. See here: http://dlang.org/phobos/core_runtime.html#.Runtime.moduleUnitTester (set in a shared static ctor). All you have to do is just run the module's unit tests you desire.

Neat, I had no idea.
 I would argue the "stock" unit test runner could be configured by an
 environment variable to be able to run/exclude whatever you want.
 This is eminently fixable in the library with a small pull request.

I think that definitely sounds like the way to go.

--001a11c209d245440e04dd519748 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable it&#39;s only module level granularity.<div><br><div>I agree that a library= solution is the way to go, however there needs to be a way to have finer g= ranularity, ie being able to call individual unittests.</div><div>I gave th= e reasons in the 2nd post in this thread. Syntax would be: <span style=3D"b= ackground-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans= -serif;font-size:13px">unittest(test_fun){...}</span></div> <div><span style=3D"background-color:rgb(255,255,255);color:rgb(34,34,34);f= ont-family:arial,sans-serif;font-size:13px">having a short syntax such as t= his will make people use it.</span></div><div><span style=3D"background-col= or:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-s= ize:13px"><br> </span></div><div><span style=3D"background-color:rgb(255,255,255);color:rg= b(34,34,34);font-family:arial,sans-serif;font-size:13px">digressing, I wish= there would be a simple non-anonymous way to vote for such features, to se= e whether most people agree/disagree. It&#39;s easier than voting by email,= which invariably gets lost in digressions (as I&#39;m doing here).</span><= /div> <div><span style=3D"background-color:rgb(255,255,255);color:rgb(34,34,34);f= ont-family:arial,sans-serif;font-size:13px"><br></span></div><div><br><div = class=3D"gmail_quote">On Tue, May 21, 2013 at 11:36 AM, Nick Sabalausky <sp= an dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsiteToContactMe semitwist.com" t= arget=3D"_blank">SeeWebsiteToContactMe semitwist.com</a>&gt;</span> wrote:<= br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, 21 May 2013 12:23:= 01 -0400<br> &quot;Steven Schveighoffer&quot; &lt;<a href=3D"mailto:schveiguy yahoo.com"=
schveiguy yahoo.com</a>&gt; wrote:<br>

&gt; On Mon, 20 May 2013 21:52:51 -0400, Nick Sabalausky<br> &gt; &lt;<a href=3D"mailto:SeeWebsiteToContactMe semitwist.com">SeeWebsiteT= oContactMe semitwist.com</a>&gt; wrote:<br> &gt;<br> &gt; &gt; So alright...Who&#39;s with me?!!! &quot;Yeaaaa......!!!!!&quot; = (&lt;-- Belushi<br> &gt; &gt; running out the door)<br> &gt; &gt;<br> &gt;<br> &gt; I think we can handle this without compiler help.<br> &gt;<br> &gt; The runtime is responsible for running unit tests.<br> &gt;<br> &gt; It actually provides a hook to allow you to override the unit tests.<b= r> &gt; See here:<br> &gt; <a href=3D"http://dlang.org/phobos/core_runtime.html#.Runtime.moduleUn= itTester" target=3D"_blank">http://dlang.org/phobos/core_runtime.html#.Runt= ime.moduleUnitTester</a><br> &gt; (set in a shared static ctor). =A0All you have to do is just run the<b= r> &gt; module&#39;s unit tests you desire.<br> &gt;<br> <br> </div>Neat, I had no idea.<br> <div class=3D"im"><br> &gt; I would argue the &quot;stock&quot; unit test runner could be configur= ed by an<br> &gt; environment variable to be able to run/exclude whatever you want.<br> &gt; This is eminently fixable in the library with a small pull request.<br=

<br> </div>I think that definitely sounds like the way to go.<br> <br> </blockquote></div><br></div></div> --001a11c209d245440e04dd519748--
May 22 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
May 22 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--089e01294684b9956f04dd5227bf
Content-Type: text/plain; charset=ISO-8859-1

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)

--089e01294684b9956f04dd5227bf Content-Type: text/html; charset=ISO-8859-1 <br><br><div class="gmail_quote">On Wed, May 22, 2013 at 10:19 AM, Nick Sabalausky <span dir="ltr">&lt;<a href="mailto:SeeWebsiteToContactMe semitwist.com" target="_blank">SeeWebsiteToContactMe semitwist.com</a>&gt;</span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, 22 May 2013 10:06:46 -0700<br> Timothee Cour &lt;<a href="mailto:thelastmammoth gmail.com">thelastmammoth gmail.com</a>&gt; wrote:<br> <br> &gt; it&#39;s only module level granularity.<br> &gt;<br> &gt; I agree that a library solution is the way to go, however there needs<br> &gt; to be a way to have finer granularity, ie being able to call<br> &gt; individual unittests. I gave the reasons in the 2nd post in this<br> &gt; thread. Syntax would be: unittest(test_fun){...}<br> &gt; having a short syntax such as this will make people use it.<br> &gt;<br> &gt; digressing, I wish there would be a simple non-anonymous way to vote<br> &gt; for such features, to see whether most people agree/disagree. It&#39;s<br> &gt; easier than voting by email, which invariably gets lost in<br> &gt; digressions (as I&#39;m doing here).<br> &gt;<br> <br> </div>Bugzilla has a voting system &lt;<a href="http://d.puremagic.com/issues/" target="_blank">http://d.puremagic.com/issues/</a>&gt;. Every<br> user has up to 10 votes to place on whatever tickets they want.<br> <br></blockquote><div>I&#39;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.</div></div><br> --089e01294684b9956f04dd5227bf--
May 22 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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 22 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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 22 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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 22 2013
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 22 May 2013 at 17:06:59 UTC, Timothee Cour 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).

For a real life project you probably need a unittest framework. Current approach is for an optimistic case when you mostly have green test runs and just unittests are enough to test the whole system.
May 23 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, May 23, 2013 13:12:53 Steven Schveighoffer wrote:
 No, the shell expands wildcards, not the OS.

It was just a sarcastic comment about incredible consistency of wildcard expansion in linux.

Having the expansion of wildcards built into the OS would be bad. I don't need to get into that.

Agreed. Globbing is a shell thing, so it makes sense that the shell do it. It has nothing to do with the OS. Saying that it had anything to do with OS would be like saying that the fact that you had to escape ( was a feature of the OS. It would make no sense. All of that sort of thing is a feature of the shell. Programs just operate on the arguments that they're given and it just so happens that the shell provides some useful ways for the user to provide larger lists of files without typing them all. The OS has no business being involved in that. - Jonathan M Davis
May 23 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 23, 2013 at 01:43:52PM -0400, Jonathan M Davis wrote:
 On Thursday, May 23, 2013 13:12:53 Steven Schveighoffer wrote:
 No, the shell expands wildcards, not the OS.

It was just a sarcastic comment about incredible consistency of wildcard expansion in linux.

Having the expansion of wildcards built into the OS would be bad. I don't need to get into that.

Agreed. Globbing is a shell thing, so it makes sense that the shell do it. It has nothing to do with the OS. Saying that it had anything to do with OS would be like saying that the fact that you had to escape ( was a feature of the OS. It would make no sense. All of that sort of thing is a feature of the shell. Programs just operate on the arguments that they're given and it just so happens that the shell provides some useful ways for the user to provide larger lists of files without typing them all. The OS has no business being involved in that.

This reasoning breaks down when the program needs two or more large argument lists. On Windows/MSDOS, you could do things like "rename *.jpeg *.jpg" and it would do the right thing, but this is an utter PITA on Linux: mv doesn't support it, and even a program that *does* support it requires escaping to prevent shell interpolation, thus requiring infelicities like "mv \*.jpeg \*.jpg". I stand by my statement that wildcards should be handled by the program, not the shell. T -- A mathematician is a device for turning coffee into theorems. -- P. Erdos
May 23 2013
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 23 May 2013 13:47:25 -0400, H. S. Teoh <hsteoh quickfur.ath.cx>  
wrote:

 This reasoning breaks down when the program needs two or more large
 argument lists. On Windows/MSDOS, you could do things like "rename
 *.jpeg *.jpg" and it would do the right thing, but this is an utter PITA
 on Linux: mv doesn't support it, and even a program that *does* support
 it requires escaping to prevent shell interpolation, thus requiring
 infelicities like "mv \*.jpeg \*.jpg".

This is a HORRIBLE interface. You are using a wildcard to mean a back reference. I don't think that's a benefit, and it's actually a good example of why the shell should be your direct interface, not the program itself. -Steve
May 23 2013