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 reply Timothee Cour <thelastmammoth gmail.com> writes:
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)
May 20 2013
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 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 reply 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
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 reply 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
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 next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
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.
May 21 2013
prev 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 "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  

(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
parent reply 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:

 (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
parent reply Timothee Cour <thelastmammoth gmail.com> writes:
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:

 (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 22 2013
next sibling parent reply 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
parent Timothee Cour <thelastmammoth gmail.com> writes:
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
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 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 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
parent reply 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
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 reply "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
next sibling parent reply "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
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 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 reply "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
parent reply "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
parent reply "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
parent reply "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
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 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
next sibling parent reply "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
parent reply "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
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 reply 1100110 <0b1100110 gmail.com> writes:
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.


=20
 Quotes are your friend.
=20
 -unittest=3D"package.name.*"
=20
 Problem solved. _Not_ having the shell expand globs would be horrific. =


Every=20

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


d be=20

 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
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 parent reply "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
parent reply "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
parent reply "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
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 parent reply "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
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 parent reply "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
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
prev 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