[dmd-internals] dmd commit, revision 657

[Sean Kelly]

I do think that versioning is the way to go if the goal is to expose only a standard, defined API. If I receive a patch where parts were clearly copied from another version, I simply reject it. If the effort is manual though I trust it's correct and wait for bug reports to say otherwise. 

Regarding the test suite... I was working with the private one yesterday and it took me a while to figure out how to make it work. Platform-specific scripts is bad enough, but scripts that can only be run via the shell app that ships with DMD?  Really?  I wasn't sure how to override the settings it uses so I even had to edit the script to make it work. Might be fine for a personal test suite, but for a publicly available one it needs work. :-)

Sent from my iPhone

On Sep 2, 2010, at 11:40 PM, Walter Bright <walter at digitalmars.com> wrote:

> 
> 
> Brad Roberts wrote:
>> On 9/2/2010 3:00 PM, Walter Bright wrote:
>>  
>>> Brad Roberts wrote:
>>>    
>>>> The major wish I have is that walter would start using the public test suite
>>>> rather than the private one.  I'm working on getting the public one to work on
>>>> windows -- making good progress, it runs most of the tests now.
>>>> 
>>>>        
>>> It already works fine on Windows, and I disagree that it needed reengineering so
>>> that it wouldn't.
>>>    
>> 
>> If you honestly think what I did was engineer it so that it wouldn't work on
>> windows, we need to talk.
> 
> No, I don't mean that at all, and apologize for implying that. I meant the current setup is simple and effective and works on all the supported platforms.
> 
> I should add that Andrei agrees with you about this and disagrees with me strongly. So keep that in mind when you read the following.
> 
>>  It needed reenginering for other reasons (probably
>> incomplete, but this is off the top of my head and quickly written):
>> 
>> 1) to use a single driver for all platforms rather than one for each that were
>> never kept in sync -- an old argument you keep loosing
>>  
> 
> Except that there is much customization from one platform to the next. Switches are different, commands are different, paths are different, extensions are different, generated files are different, etc.
> 
> Not sure I keep losing the argument. For example, Phobos1 used to have std.c.stdio loaded with version declarations for the different _iobuf's for each platform. The trouble was, when one updated one platform one tended to break the others. Even worse, adding a new platform meant someone would just cut & paste the info from some other platform, and assume it worked. This added a bunch of work for me as I had to go through and vet every declaration. Things got better when I separated out each platform into its own import. These problems resurfaced with druntime, which tries to do a lot using version declarations instead of separate platform files.
> 
> So yes, on the one hand you can add files to all platforms simultaneously. On the other, there's constant breakage of the platforms the updater didn't test on.
> 
>> 2) to run tests in parallel -- your attempts at doing that in your custom shell
>> engine didn't work out terribly well
>>  
> 
> I didn't spend that much time on the multithreading, either <g>. One problem was that the text output of the different threads got interleaved, a problem that multithreaded make also has. The other problem is that optlink must always run on core 0, meaning that multithreading the test suite on Windows does not actually speed it up. Until I can fix that problem with optlink, it wasn't worth the effort to continue working on parallelizing the tests.
> 
> I've also got things set up now so that with one command I can fire off 4 windows, and have each window ssh'ing into a different machine and running the build & test suite (Windows, Linux, OSX and FreeBSD). Those obviously all run in parallel (!). I can watch them all run on one screen.
> 
>> 3) to separate test driver output from test output -- spewing all that output to
>> the screen is a mess.  Tests should have a single line of output: name of test
>> and pass or fail
>>  
> 
> I guess I never had any trouble noticing when one failed and which one it was.
> 
>> 4) to make it easy to run subsets of the test suite, specifically easy to run
>> the one that's failing.
>>  
> 
> I'm not sure what the problem is with typing:
> 
>  dmc test23
> 
> 
>> 5) to run _all_ of the test suite -- note the 4 bugs I filed based on the
>> failure tests that hadn't been run or would have caught a couple regressions.
>>  
> 
> That failing was mine in not keeping the suite updated, not a fault in the methodology.
> 
>> Also of potential interest.. the biggest problem I've had with the windows
>> support is switching from / to \ based on os since optlink can't handle it.  It
>> looked like everything else was happy -- though dmd might have had some issues,
>> I didn't try to isolate the issue between the two.  The o vs obj and nothing vs
>> .exe were trivial.  Support for \ is a pain in the ass.. having to \\ in places
>> -- right now something somewhere is retaining both \\'s rather than treating it
>> as one escaped.  I got frustrated with that and your post so I set aside the
>> project for the evening.
>>  
> 
> The \ issue is always a problem. I'm always running into windows software, including Microsoft software, that doesn't recognize /.
> 
>> I'll finish it tomorrow or this weekend, maybe.
>> 
>> 
>>  
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals