On Wednesday, 26 October 2016 at 05:32:51 UTC, Jonathan M Davis
wrote:
That being said, using -main when unit testing libraries and
declaring main in applications to look something like
version(unittest) void main() {}
else int main(string[] args) {...}
doesn't seem like all that big a deal to
On Wednesday, October 26, 2016 05:24:45 deadalnix via Digitalmars-d wrote:
> Seriously that makes no sense, almost everybody has it own hack
> to have a different main when building for unitests, and we look
> like clown.
>
> We all like to talk about language feature and all, but
> seriously, this
Seriously that makes no sense, almost everybody has it own hack
to have a different main when building for unitests, and we look
like clown.
We all like to talk about language feature and all, but
seriously, this kind of thing is what hurts us the most. We kind
of live with it because we all
On Tue, Oct 25, 2016 at 03:53:54PM -0700, Walter Bright via Digitalmars-d wrote:
> It's a small bit, but the idea here is to eliminate if conditionals where
> possible:
>
> https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e
>
> This is
On Tuesday, 25 October 2016 at 22:25:51 UTC, Jeff Thompson wrote:
On Tuesday, 25 October 2016 at 19:54:42 UTC, Jonathan Marler
wrote:
On Tuesday, 25 October 2016 at 06:47:14 UTC, Jeff Thompson
wrote:
[...]
Sorry if I didn't understand something, couldn't you do this?
/commit_b3bf5c7725c98ee3
On Tuesday, 25 October 2016 at 22:53:54 UTC, Walter Bright wrote:
It's a small bit, but the idea here is to eliminate if
conditionals where possible:
https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e
This is something we could all do
It's a small bit, but the idea here is to eliminate if conditionals where
possible:
https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a#.nhth1eo4e
This is something we could all do better at. Making code a straight path makes
it easier to reason
On Tuesday, 25 October 2016 at 19:54:42 UTC, Jonathan Marler
wrote:
On Tuesday, 25 October 2016 at 06:47:14 UTC, Jeff Thompson
wrote:
[...]
Sorry if I didn't understand something, couldn't you do this?
/commit_b3bf5c7725c98ee3e49dfc4e47318162f138fe94/version/lib.d
/commit_df0741a84c8a967ea086
On Tuesday, 25 October 2016 at 21:46:30 UTC, safety0ff wrote:
P.S. I am aware that this pessimises popFront for code which
only counts codepoints without inspecting them.
Unfortunately it also changes the API of popFront to throw on
invalid characters.
So the example would need to be rewor
On Wednesday, 12 October 2016 at 13:53:03 UTC, Andrei
Alexandrescu wrote:
Now it's time to look at the end-to-end cost of autodecoding.
Some food for thought:
- front necessarily needs to compute the number of bytes to
advance.
- We can't change the API to share data between front and
popFr
On Tuesday, 25 October 2016 at 06:47:14 UTC, Jeff Thompson wrote:
On Tuesday, 25 October 2016 at 00:42:59 UTC, Adam D. Ruppe
wrote:
[...]
A variant of this is where the version name is the Git commit
hash. Instead of "version1" and "version2" it is:
/commit_b3bf5c7725c98ee3e49dfc4e47318162f
On 10/25/16 3:32 PM, Stefam Koch wrote:
On Tuesday, 25 October 2016 at 19:16:07 UTC, Steven Schveighoffer wrote:
Should behave better on 32-bit system.
You could also store 3-bits to avoid extra addition.
The whole point of a LUT to begin with is to reduce instructions.
Yes, I know. But a
On Tuesday, 25 October 2016 at 19:16:07 UTC, Steven Schveighoffer
wrote:
On 10/25/16 12:57 PM, Dmitry Olshansky wrote:
On 10/12/16 3:53 PM, Andrei Alexandrescu wrote:
So we've had a good run with making popFront smaller. In ASCII
microbenchmarks with ldc, the speed is indistinguishable from
s
On 10/25/16 12:57 PM, Dmitry Olshansky wrote:
On 10/12/16 3:53 PM, Andrei Alexandrescu wrote:
So we've had a good run with making popFront smaller. In ASCII
microbenchmarks with ldc, the speed is indistinguishable from s = s[1 ..
$]. Smaller functions make sure that the impact on instruction cac
On 10/12/16 3:53 PM, Andrei Alexandrescu wrote:
So we've had a good run with making popFront smaller. In ASCII
microbenchmarks with ldc, the speed is indistinguishable from s = s[1 ..
$]. Smaller functions make sure that the impact on instruction cache in
larger applications is not high.
[snip]
On Tuesday, 25 October 2016 at 15:08:14 UTC, Dmitry Olshansky
wrote:
Hi, have you found a review manager yet?
No, the NG was rather silent, so sill looking for one.
As it is a runtime module and not Phobos, I'd be willing to
volunteer - but only quite some time later (probably about 1
month
On 10/25/16 2:39 PM, Guillaume Piolat wrote:
On Saturday, 15 October 2016 at 14:08:25 UTC, Dmitry Olshansky wrote:
The module aims to provide portable interface to virtual memory
management unit of the OS. Some common recipes such as locking memory
and allocating executable memory should be easi
Last two are ok, I do not see any error
Dne 25.10.2016 v 15:24 Satoshi via Digitalmars-d napsal(a):
I posted 3 more bugs what I found.
Seriously, can someone fix these bugs, please?
Thanks!
https://issues.dlang.org/show_bug.cgi?id=16590
I posted 3 more bugs what I found.
Seriously, can someone fix these bugs, please?
Thanks!
https://issues.dlang.org/show_bug.cgi?id=16590
On 10/25/2016 05:17 AM, Jacob wrote:
I sort of feel that issues.dlang.org is an unmaintained mess. Anyone has
access to it every aspect of editing anyone else's issue, so anyone
could be added really without any oversight.
Yet there's very little vandalism going on, aside from the occasional
s
On Tuesday, 25 October 2016 at 03:17:02 UTC, Jacob wrote:
I sort of feel that issues.dlang.org is an unmaintained mess.
I don't think its state is much worse than that of a typical
bugtracker for projects of this scale.
Anyways for the site itself, it seems to be lacking features.
It is a
On Saturday, 15 October 2016 at 14:08:25 UTC, Dmitry Olshansky
wrote:
The module aims to provide portable interface to virtual memory
management unit of the OS. Some common recipes such as locking
memory and allocating executable memory should be easily
accessible.
In general the task is next
On Tuesday, 25 October 2016 at 03:17:02 UTC, Jacob wrote:
...
1. The vast, vast majority of problems attributed to
collaboration software are actually the fault of a lack of
communication skills. This situation is no different. Changing
the software will not fix any problems in organization
On Tuesday, 25 October 2016 at 07:05:20 UTC, Era Scarecrow wrote:
Hmm as an experiment I changed from doubles to reals, and got
a slightly higher result, up to 85 giving us a 58/64
Of course floating precision is not unlimited :)
On Monday, 24 October 2016 at 19:03:51 UTC, Era Scarecrow wrote:
It's only good through 71 iterations (longs) then it starts
having errors. Also for some odd reason the input is one off,
so I had to add a -1 to the input for it to align. This makes
it accurate to 41/64 bit results.
71: 308061
25 matches
Mail list logo
