On Monday, 11 May 2015 at 07:12:05 UTC, Per Nordlöw wrote:
I guess we should support bi-directional access through back()
and popBack() aswell right?
Does this mean that we need to statically check whether the
SortedRanges support Bidirectional access or not? Or is a
SortedRange by
On Monday, 11 May 2015 at 07:05:30 UTC, Per Nordlöw wrote:
So I implemented a first working version of merge() by reusing
roundRobin(). Working version at:
https://github.com/nordlow/justd/blob/master/range_ex.d#L599
Destroy!
I guess we should support bi-directional access through back()
On Sunday, 10 May 2015 at 16:11:41 UTC, Jacob Carlborg wrote:
I would like to announce that DWT recently got support for
64bit, both on Linux and Windows. Compiling for 32bit COFF
should also work on Windows.
All this work was done by kntroh and Jesse Phillips, thank you
very much.
Great!
https://issues.dlang.org/show_bug.cgi?id=14549
--- Comment #2 from Puneet Goel pun...@coverify.org ---
(In reply to Kenji Hara from comment #1)
https://github.com/D-Programming-Language/dmd/pull/4635
Sorry for checking this late.
This PR causes another regression for me. I will file it in a
On 2015-05-10 10:14, Oren Tirosh wrote:
I think it should work for any two structs as long their fields are
public and individually assignment-compatible.
Just for the record, tupleof bypasses protection.
--
/Jacob Carlborg
https://issues.dlang.org/show_bug.cgi?id=14571
Issue ID: 14571
Summary: Large static arraus seem to lock up DMD
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
On Monday, 11 May 2015 at 03:09:53 UTC, Adam D. Ruppe wrote:
http://arsdnet.net/this-week-in-d/may-10.html
https://twitter.com/adamdruppe/status/597598994227924992
The tip could probably use a rewrite in editing, but I'm out of
time again tonight and I hope I got the point across anyway. As
On Thursday, 7 May 2015 at 21:53:24 UTC, Per Nordlöw wrote:
Thanks. These are good ideas in general. I'm curious to why
something like merge isn't already in Phobos. The most similar
existing range in Phobos is probably
So I implemented a first working version of merge() by reusing
On Sunday, 10 May 2015 at 21:44:59 UTC, Dicebot wrote:
Well choice between two presented options seems obvious so I
suspect a catch :)
Well, exactly like with the shared library visibility the only
catch might be Walter's and Andrei's opinion.
There's also a fork of Dscanner that adds PlantUML output:
https://github.com/funkwerk/Dscanner
-dmitri.
On 2015-05-10 10:12, Jonathan M Davis wrote:
Those are really the only ones that I've ever thought made sense, and in
several cases, the things that folks want are things that I very much
_don't_ want (e.g. continuing to execute a unittest block after an
assertion failure).
I don't think most
On 2015-05-08 21:45, Walter Bright wrote:
This is an interesting problem, one that I faced with Warp.
The solution was to make the function being tested a function template.
Then, in the unit test I replace the 'file' argument to the function
with a static array of test data.
I don't really
On Monday, 11 May 2015 at 09:09:09 UTC, tcak wrote:
[code]
import std.stdio;
class Connection{
private void other() shared{}
public void close() shared{
synchronized( this ){
other();
}
}
public void
https://issues.dlang.org/show_bug.cgi?id=5227
--- Comment #12 from Manu turkey...@gmail.com ---
(In reply to Iain Buclaw from comment #11)
(In reply to Manu from comment #10)
(In reply to Iain Buclaw from comment #8)
(In reply to Manu from comment #7)
log() works!
I doubt that,
On Mon, 11 May 2015 09:40:28 +
tcak via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Monday, 11 May 2015 at 09:20:50 UTC, Daniel Kozák wrote:
On Mon, 11 May 2015 09:09:07 +
tcak via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
I think
On Monday, 11 May 2015 at 08:31:19 UTC, Timothee Cour wrote:
git clone git://github.com/D-Programming-Language/dmd.git
cd dmd
make -f posix.mak MODEL=64
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C src
-f posix.mak
no cpu specified, assuming X86
dmd idgen.d
g++ -m64: No such
here's a single symbol from my project
On Friday, 8 May 2015 at 19:45:35 UTC, Walter Bright wrote:
On 5/8/2015 7:00 AM, Chris wrote:
The only drawback is that sometimes the logic of a program
does not allow to
test every little bit, especially when handling files is
concerned.
This is an interesting problem, one that I faced with
On Monday, 11 May 2015 at 09:55:36 UTC, Marc Schütz wrote:
In addition to an immutable/shared heap, it may also be
necessary to transfer data from one thread to another. The
shared heap is for data with shared ownership, while other data
with (unique) ownership can be sent to other threads.
https://issues.dlang.org/show_bug.cgi?id=14565
--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/druntime
https://github.com/D-Programming-Language/druntime/commit/6ce3287415567e2c63eca8bb73b7252a5c4f4d1c
fix Issue 14565 -
https://issues.dlang.org/show_bug.cgi?id=14573
Issue ID: 14573
Summary: Extreme memory usage when `synchronized( object )` is
used
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
On Monday, 11 May 2015 at 10:48:22 UTC, tcak wrote:
On Monday, 11 May 2015 at 10:30:11 UTC, Daniel Kozak wrote:
On Monday, 11 May 2015 at 10:24:57 UTC, Daniel Kozák wrote:
On Mon, 11 May 2015 09:40:28 +
tcak via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
But yes I
On Mon, 11 May 2015 09:09:07 +
tcak via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
[code]
import std.stdio;
class Connection{
private void other() shared{}
public void close() shared{
synchronized( this ){
other();
On Monday, 11 May 2015 at 09:20:50 UTC, Daniel Kozák wrote:
On Mon, 11 May 2015 09:09:07 +
tcak via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
I think synchronize(this) prevents GC from collect memory
I am not sure whether this is expected behaviour from
https://issues.dlang.org/show_bug.cgi?id=5227
--- Comment #11 from Iain Buclaw ibuc...@gdcproject.org ---
(In reply to Manu from comment #10)
(In reply to Iain Buclaw from comment #8)
(In reply to Manu from comment #7)
log() works!
I doubt that, CTFE isn't powerful enough yet.
On Monday, 11 May 2015 at 08:18:54 UTC, Jacob Carlborg wrote:
On 2015-05-10 10:12, Jonathan M Davis wrote:
Those are really the only ones that I've ever thought made
sense, and in
several cases, the things that folks want are things that I
very much
_don't_ want (e.g. continuing to execute a
git clone git://github.com/D-Programming-Language/dmd.git
cd dmd
make -f posix.mak MODEL=64
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C src -f posix.mak
no cpu specified, assuming X86
dmd idgen.d
g++ -m64: No such file or directory
--- errorlevel 255
make[1]: *** [idgen] Error 255
On Sunday, 10 May 2015 at 09:50:00 UTC, Andrei Alexandrescu wrote:
3. Thread-local vs. shared objects
Currently in D it's legal to allocate memory in one thread and
deallocate it in another. (One simple way to look at it is
casting to shared.) This has a large performance cost that only
On Monday, 11 May 2015 at 07:12:05 UTC, Per Nordlöw wrote:
I guess we should support bi-directional access through back()
and popBack() aswell right?
I believe I have BidirectionalRange support aswell now at
https://github.com/nordlow/justd/blob/master/range_ex.d#L597
On Mon, 11 May 2015 09:40:28 +
tcak via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Monday, 11 May 2015 at 09:20:50 UTC, Daniel Kozák wrote:
On Mon, 11 May 2015 09:09:07 +
tcak via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
I think
https://issues.dlang.org/show_bug.cgi?id=14571
--- Comment #2 from Manu turkey...@gmail.com ---
More amazing that a quadratic increase in compile time as a result of linear
increase in array size, is that script you just produced... that is truly
astonishing!
Seriously, I'm speechless. O_O
--
https://issues.dlang.org/show_bug.cgi?id=14572
Issue ID: 14572
Summary: cannot build dmd from source anymore: 'g++ -m64: No
such file or directory'
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
[code]
import std.stdio;
class Connection{
private void other() shared{}
public void close() shared{
synchronized( this ){
other();
}
}
public void hasData() shared{ writeln(Has Data); }
}
void main() {
https://issues.dlang.org/show_bug.cgi?id=14571
ag0ae...@gmail.com changed:
What|Removed |Added
Keywords||performance
CC|
On Monday, 11 May 2015 at 10:30:11 UTC, Daniel Kozak wrote:
On Monday, 11 May 2015 at 10:24:57 UTC, Daniel Kozák wrote:
On Mon, 11 May 2015 09:40:28 +
tcak via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
But yes I would say, it is not intentional behaviour. It
should
On Sunday, 10 May 2015 at 09:50:00 UTC, Andrei Alexandrescu wrote:
3. Thread-local vs. shared objects
Currently in D it's legal to allocate memory in one thread and
deallocate it in another. (One simple way to look at it is
casting to shared.) This has a large performance cost that only
Am Sun, 10 May 2015 19:51:26 +
schrieb Dicebot pub...@dicebot.lv:
On Friday, 8 May 2015 at 05:26:01 UTC, Benjamin Thaut wrote:
Pro:
- Its the plain windows shared library mechanism in all its
uglyness.
I wonder if anyone can provide more Pro input :)
Yep, this is an area where I
On Mon, 11 May 2015 12:24:34 +
weaselcat via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
On Monday, 11 May 2015 at 12:22:34 UTC, Dennis Ritchie wrote:
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote:
Inspired by ponce idioms list for D I've set up
On 2015-05-11 11:33, weaselcat wrote:
I'd put the symbol here, but it's too long and got rejected by the NG.
So, you can view it here. https://paste.ee/r/cIuGm
Haha :)
--
/Jacob Carlborg
On Monday, 11 May 2015 at 12:53:26 UTC, John Colvin wrote:
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote:
Inspired by ponce idioms list for D I've set up something
similar.
There are some themes in D which come up regulary and are
discussed to the vomit. If something is agreed, it
Would like to suggest strip to be added to the page. It makes
wonders to the final executable.
On Friday, 8 May 2015 at 15:47:11 UTC, Vladimir Panteleev wrote:
On Thursday, 7 May 2015 at 22:27:57 UTC, Walter Bright wrote:
But let's not forget the meat and potatoes on our plate while
looking
On Monday, 11 May 2015 at 12:22:34 UTC, Dennis Ritchie wrote:
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote:
Inspired by ponce idioms list for D I've set up something
similar.
There are some themes in D which come up regulary and are
discussed to the vomit. If something is agreed, it
John Colvin wrote in message news:jsnuhemrispqiwvwl...@forum.dlang.org...
Do you
1) already have a version of dmd installed (relatively new requirement)
Yeah, it's this. Which page is this that needs updating?
Am Sun, 10 May 2015 10:37:13 -0400
schrieb bitwise bitwise@gmail.com:
I'm not sure I understand what you're trying to say.
Bit
I'm trying to hijack your thread and communicate that .di
files are important for D since they allow the compiler to
stop recursively importing modules at
On Monday, 11 May 2015 at 10:54:10 UTC, Jonathan M Davis wrote:
doing the allocation, but I don't see how we can get rid of the
possibility of an object being allocated on one thread and
deallocated on another without making major changes to shared -
and std.concurrency isn't going to work
Inspired by ponce idioms list for D I've set up something similar.
There are some themes in D which come up regulary and are
discussed to the vomit. If something is agreed, it gets forgotten
sometimes and the theme disappears into oblivion (for a few
months :P). To prevent this, I've collected
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote:
Inspired by ponce idioms list for D I've set up something
similar.
There are some themes in D which come up regulary and are
discussed to the vomit. If something is agreed, it gets
forgotten sometimes and the theme disappears into
On Monday, 11 May 2015 at 12:22:34 UTC, Dennis Ritchie wrote:
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote:
Inspired by ponce idioms list for D I've set up something
similar.
There are some themes in D which come up regulary and are
discussed to the vomit. If something is agreed, it
Why did Microsoft go with that approach,
Maybe they didn't know better back then. Historically DLLs
initially didn't support data symbols at all, only functions
where supported. For functions its not a problem if they are
duplicated because usually you don't compare pointers to
functions a
On Monday, 11 May 2015 at 12:46:59 UTC, Marco Leise wrote:
Am Sun, 10 May 2015 10:37:13 -0400
schrieb bitwise bitwise@gmail.com:
I'm not sure I understand what you're trying to say.
Bit
I'm trying to hijack your thread and communicate that .di
files are important for D since they
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote:
Inspired by ponce idioms list for D I've set up something
similar.
There are some themes in D which come up regulary and are
discussed to the vomit. If something is agreed, it gets
forgotten sometimes and the theme disappears into
On Monday, 11 May 2015 at 12:25:27 UTC, Daniel Murphy wrote:
John Colvin wrote in message
news:jsnuhemrispqiwvwl...@forum.dlang.org...
Do you
1) already have a version of dmd installed (relatively new
requirement)
Yeah, it's this. Which page is this that needs updating?
I don't see the
On Monday, 11 May 2015 at 13:21:01 UTC, Timon Gehr wrote:
On 05/11/2015 01:59 PM, Namespace wrote:
Inspired by ponce idioms list for D I've set up something
similar.
There are some themes in D which come up regulary and are
discussed to
the vomit. If something is agreed, it gets forgotten
struct MyStruct {
this(int a, int b) {
this.a = a;
this.b = b;
}
immutable int a;
immutable int b;
}
void main(string[] args) {
MyStruct[] arr = new MyStruct[3];
arr[0] = MyStruct(5, 7);
}
Why does it
On Monday, 11 May 2015 at 13:37:27 UTC, ref2401 wrote:
Why does it happen?
You'd just be writing to the immutable memory through a different
name.
Consider if someone took a reference to one of those immutable
ints, expecting it to never change. Then you wrote a new struct
over the same
On Monday, 11 May 2015 at 13:44:14 UTC, Adam D. Ruppe wrote:
On Monday, 11 May 2015 at 13:37:27 UTC, ref2401 wrote:
Why does it happen?
You'd just be writing to the immutable memory through a
different name.
Consider if someone took a reference to one of those immutable
ints, expecting it
On 05/11/2015 01:59 PM, Namespace wrote:
Inspired by ponce idioms list for D I've set up something similar.
There are some themes in D which come up regulary and are discussed to
the vomit. If something is agreed, it gets forgotten sometimes and the
theme disappears into oblivion (for a few
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote:
http://dgame.github.io/dneeds/
There seems to be some overlap with some existing wiki pages:
http://wiki.dlang.org/Language_design_discussions
http://wiki.dlang.org/Language_issues
On Monday, 11 May 2015 at 13:21:01 UTC, Timon Gehr wrote:
On 05/11/2015 01:59 PM, Namespace wrote:
Inspired by ponce idioms list for D I've set up something
similar.
There are some themes in D which come up regulary and are
discussed to
the vomit. If something is agreed, it gets forgotten
On Monday, 11 May 2015 at 13:21:01 UTC, Timon Gehr wrote:
The stack memory goes right out of scope after having been
sliced.
I hate that static arrays are implicitly sliced. It leads to
common memory safety bugs in places like that.
https://imgflip.com/i/lcf39
On Monday, 11 May 2015 at 09:33:42 UTC, weaselcat wrote:
here's a single symbol from my project
The underlying problem is that symbols names grow quadratically
when combining templated ranges, because each range's name is a
template argument to the next range. Sometimes name occur twice,
as
Thanks for the insight into how this affects MSVC++, too.
How much work do you think would have to be done at startup of
an application like Firefox or QtCreator if they were not in
C++, but D?
Most of us have no idea what the algorithm would look like and
what data sets to expect.
I guess
Can we please not turn this thread into an XML vs JSON flamewar?
XML is one of the most popular data formats (for better or for
worse), so a parser would be a good addition to the standard
library.
Am Mon, 11 May 2015 12:50:48 +
schrieb weaselcat weasel...@gmail.com:
On Monday, 11 May 2015 at 12:46:59 UTC, Marco Leise wrote:
Am Sun, 10 May 2015 10:37:13 -0400
schrieb bitwise bitwise@gmail.com:
I'm not sure I understand what you're trying to say.
Bit
I'm trying
On Monday, 11 May 2015 at 13:51:59 UTC, Vladimir Panteleev wrote:
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote:
http://dgame.github.io/dneeds/
There seems to be some overlap with some existing wiki pages:
http://wiki.dlang.org/Language_design_discussions
On Friday, 8 May 2015 at 05:26:01 UTC, Benjamin Thaut wrote:
And Step 2) at program start up time. This means that symbols
don't have identity. If different shared libraries provide the
same symbol it may exist multiple times and multiple instances
might be in use.
Can you elaborate a bit on
https://issues.dlang.org/show_bug.cgi?id=12289
--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/druntime
https://github.com/D-Programming-Language/druntime/commit/b96aa6962ac477bf711f7bedc4cc326534025ce2
Fix Issue 12289 -
On 5/10/15 5:08 AM, Timon Gehr wrote:
On 05/10/2015 01:48 PM, Timon Gehr wrote:
bool expand(ref void[] b, size_t delta);
Post: !result || b.length == old(b).length + delta Expands b by
delta bytes. If delta == 0, succeeds without changing b. If b is null,
the call evaluates b =
On 5/11/15 1:19 AM, Jacob Carlborg wrote:
On 2015-05-10 10:12, Jonathan M Davis wrote:
Those are really the only ones that I've ever thought made sense, and in
several cases, the things that folks want are things that I very much
_don't_ want (e.g. continuing to execute a unittest block after
On 05/10/2015 11:09 PM, Adam D. Ruppe wrote:
http://arsdnet.net/this-week-in-d/may-10.html
https://twitter.com/adamdruppe/status/597598994227924992
The tip could probably use a rewrite in editing, but I'm out of time
again tonight and I hope I got the point across anyway. As someone who
really
On Monday, 11 May 2015 at 14:57:46 UTC, Marco Leise wrote:
Is that what would happen?
Yes, that's exactly what would happen. You could go one step
further and not do it for all symbols, instead you make the
compiler emit a additional section with references to all
relevant data symbols.
On Monday, 11 May 2015 at 15:20:12 UTC, Alex Parrill wrote:
Can we please not turn this thread into an XML vs JSON flamewar?
This is not a flamewar, JSON is ad hoc and I use it a lot, but it
isn't actually suitable as a file and archival exchange format.
It is important that people
https://issues.dlang.org/show_bug.cgi?id=14549
--- Comment #3 from Puneet Goel pun...@coverify.org ---
Reduced code. With the PR applied, I get dmd assertion failure:
$ dmd /tmp/test.d
dmd: attrib.c:1219: virtual Dsymbols* StaticIfDeclaration::include(Scope*,
ScopeDsymbol*): Assertion `scope'
NOTE: it's on a new laptop; not sure whether build rules implicitly assume
(maybe by error?) that something should be there beyond g++/clang/dmd but
the error message i get isn't helpful.
1) already have a version of dmd installed (relatively new requirement)
yes (via homebrew; on a new laptop):
On 5/10/15 5:58 AM, Timon Gehr wrote:
Keep in mind that currently, entire regions of memory can change from
mutable to immutable implicitly when returned from pure functions.
Furthermore, as Michel points out, the ways 'immutable' can be leveraged
is constrained by the fact that it implies
On 05/11/2015 05:28 PM, Andrei Alexandrescu wrote:
On 5/10/15 5:08 AM, Timon Gehr wrote:
On 05/10/2015 01:48 PM, Timon Gehr wrote:
bool expand(ref void[] b, size_t delta);
Post: !result || b.length == old(b).length + delta Expands b by
delta bytes. If delta == 0, succeeds without
https://issues.dlang.org/show_bug.cgi?id=14574
Issue ID: 14574
Summary: revert attributes
Product: D
Version: future
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Am 11.05.2015 um 16:21 schrieb Martin Nowak:
Can you elaborate a bit on that?
How would you run into such an ODR violation, by linking against
multiple import libraries that contain the same symbol?
I will post some code examples later. Code usually shows the issue best.
Last time we
On 5/11/15 11:06 AM, Timon Gehr wrote:
- If the rounding function is not piecewise constant with one fixed
point per piece, it can happen that 'allocated = needed' but 'allocated
goodAllocSize(needed)'. Then, the allocated size will be inconsistent
with goodAllocSize. (This is why I recommended
On 05/11/2015 08:06 PM, Timon Gehr wrote:
On 05/11/2015 05:28 PM, Andrei Alexandrescu wrote:
On 5/10/15 5:08 AM, Timon Gehr wrote:
On 05/10/2015 01:48 PM, Timon Gehr wrote:
bool expand(ref void[] b, size_t delta);
Post: !result || b.length == old(b).length + delta Expands b by
delta
https://issues.dlang.org/show_bug.cgi?id=6045
Iain Buclaw ibuc...@gdcproject.org changed:
What|Removed |Added
CC||ibuc...@gdcproject.org
https://issues.dlang.org/show_bug.cgi?id=14576
Iain Buclaw ibuc...@gdcproject.org changed:
What|Removed |Added
Keywords||spec
--
https://issues.dlang.org/show_bug.cgi?id=6045
Iain Buclaw ibuc...@gdcproject.org changed:
What|Removed |Added
Blocks||14576
--- Comment #8
On Monday, 11 May 2015 at 21:15:33 UTC, Dzhon Smit wrote:
...
time sbcl --dynamic-space-size 4GB --script fib.lisp
0
1.16user 1.49system 0:02.67elapsed 99%CPU (0avgtext+0avgdata
1658860maxresident)k
ldc -O5 -release -boundscheck=off fib.d
$ time ./fib
0
1.33user 0.81system 0:02.15elapsed
It may be a good idea to prealocate the whole array so you don't resize the
dynamic arrays every execution of the loop.
2015-05-11 23:30 GMT+02:00 weaselcat via Digitalmars-d
digitalmars-d@puremagic.com:
On Monday, 11 May 2015 at 21:15:33 UTC, Dzhon Smit wrote:
...
time sbcl
On Saturday, 9 May 2015 at 23:32:49 UTC, Adam D. Ruppe wrote:
On Saturday, 9 May 2015 at 13:00:01 UTC, wobbles wrote:
On Linux, I'm able to edit a file descriptor after I've
created it to tell it to read/write asynchronously, I cant
seem to find anything similar on windows however.
On Mon, 11 May 2015 21:15:31 +
Dzhon Smit via Digitalmars-d digitalmars-d@puremagic.com wrote:
Just in case you wonder, here's a comparison of the Fibonacci
numbers. The D code was written by Dennis Ritchie (a user of
this forum, not the guy who invented C).
[code]import std.stdio,
I took the time to research the status quo in D compiler
availability on a variety of OSs.
http://wiki.dlang.org/Compilers#Package_and.2For_binary_availability.2C_by_platform_and_compiler
The reason I am posting this in announce is that, for it to be
worth having, it will need to be kept up
https://issues.dlang.org/show_bug.cgi?id=14576
Iain Buclaw ibuc...@gdcproject.org changed:
What|Removed |Added
Depends on||6045
--
Just in case you wonder, here's a comparison of the Fibonacci
numbers. The D code was written by Dennis Ritchie (a user of
this forum, not the guy who invented C).
[code]import std.stdio, std.bigint;
void main() {
BigInt[] fib1, fib2;
BigInt last = 0, next = 1;
int n = 10;
On 5/11/2015 7:04 AM, Martin Nowak wrote:
On Monday, 11 May 2015 at 09:33:42 UTC, weaselcat wrote:
here's a single symbol from my project
The underlying problem is that symbols names grow quadratically when combining
templated ranges, because each range's name is a template argument to the
On Monday, 11 May 2015 at 14:04:07 UTC, Martin Nowak wrote:
On Monday, 11 May 2015 at 09:33:42 UTC, weaselcat wrote:
here's a single symbol from my project
The underlying problem is that symbols names grow quadratically
when combining templated ranges, because each range's name is a
All those allocations aren't helping. Here's a much more idiomatic D
version:
import std.stdio, std.bigint;
import std.range;
void main() {
int n = 10;
auto fib1 = recurrence!(a[n-1] + a[n-2])(BigInt(0), BigInt
(1)).takeExactly(n);
auto fib2 = recurrence!(a[n-1] +
On Monday, 11 May 2015 at 21:30:20 UTC, weaselcat wrote:
On Monday, 11 May 2015 at 21:15:33 UTC, Dzhon Smit wrote:
...
time sbcl --dynamic-space-size 4GB --script fib.lisp
0
1.16user 1.49system 0:02.67elapsed 99%CPU (0avgtext+0avgdata
1658860maxresident)k
ldc -O5 -release -boundscheck=off
https://issues.dlang.org/show_bug.cgi?id=14547
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, 11 May 2015 21:38:10 + (UTC)
Justin Whear via Digitalmars-d digitalmars-d@puremagic.com wrote:
All those allocations aren't helping. Here's a much more idiomatic D
version:
import std.stdio, std.bigint;
import std.range;
void main() {
int n = 10;
auto fib1
https://issues.dlang.org/show_bug.cgi?id=14547
--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/4adaa202f70c237bd4678fc1e8dc09d4c7ace229
fix Issue 14547 - Ddoc
On Monday, 11 May 2015 at 21:15:33 UTC, Dzhon Smit wrote:
Just in case you wonder, here's a comparison of the Fibonacci
numbers. The D code was written by Dennis Ritchie (a user of
this forum, not the guy who invented C).
[code]import std.stdio, std.bigint;
void main() {
BigInt[] fib1,
On 2015-05-11 17:45, Andrei Alexandrescu wrote:
For now, here's a snapshot of flags that the allocation primitives
should know about:
enum AllocOptions
{
/// Allocate an array, not an individual object
array,
/// Allocate a string of characters
string,
/// Plan to let the GC
1 - 100 of 153 matches
Mail list logo
