February 28, 2016
On 2/28/2016 1:35 AM, Iain Buclaw via Digitalmars-d wrote:
> Surely with Fibers everything would be deterministic though?

I don't see the point of fibers if:

1. they are running on the same core
2. none of them do any waiting, such as waiting on I/O requests

The only I/O a compiler does is reading the source files and writing the object file. At one time, dmd did have an async thread to read the source files, but that was removed as discussed in this thread.

To speed up dmd, using multicores is necessary, and that requires synchronization.
February 29, 2016
On 29 February 2016 at 00:43, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 2/28/2016 1:35 AM, Iain Buclaw via Digitalmars-d wrote:
>
>> Surely with Fibers everything would be deterministic though?
>>
>
> I don't see the point of fibers if:
>
> 1. they are running on the same core
>

That's a reasonable stance to have.  I was only considering the speed up of using yield/continue on a declarations' semantic pass verses the double round-robin we currently do for a couple of passes just because of forward-reference issues.


March 01, 2016
On 26/02/2016 06:19, Walter Bright wrote:
>
> I wish LLVM would switch to the Boost license, in particular removing
> this clause:
>
> "Redistributions in binary form must reproduce the above copyright
> notice, this list of conditions and the following disclaimers in the
> documentation and/or other materials provided with the distribution."
>
> Reading it adversely means if I write a simple utility and include a few
> lines from LLVM, I have to include that license in the binary and a
> means to print it out. If I include a bit of code from several places,
> each with their own version of that license, there's just a bunch of
> crap to deal with to be in compliance.

Then add the license info to a "readme" or "copyright" file. Is that really such a hassle? It seems a trivial task to me. For example:
https://github.com/rust-lang/rust/blob/master/COPYRIGHT
(that file is included in the binary distributions)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
6 7 8 9 10 11 12 13 14 15 16
Next ›   Last »