On 09-Aug-2015 12:33, Manu via Digitalmars-d wrote:
On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote:
[snip]
Even though it is hard for you to still be here, I hope you do continue to
help D
On 09/08/15 11:04, Johannes Pfau wrote:
Do you support shared libraries on OSX with that emulated TLS system
for all use cases?
Shared libraries are not supported at all on OS X.
--
/Jacob Carlborg
On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 8/8/2015 7:40 PM, Manu via Digitalmars-d wrote:
1. DMD has unsatisfactory codegen for anything other than debug builds.
Do you mean the codegen is slower? But consider that the bottleneck in most
https://issues.dlang.org/show_bug.cgi?id=7044
--- Comment #49 from Martin Nowak c...@dawg.eu ---
Great to see some momentum for this.
We also need something like this to select different libs based on m32coff or
the installed VC version, see
On Friday, 7 August 2015 at 18:29:05 UTC, Steven Schveighoffer
wrote:
On 8/7/15 1:38 PM, rsw0x wrote:
Probably a question for Martin Nowak as he seems to do a lot
of the GC
work - but I'm curious why the GC takes basically zero
advantage of D's
compile time magic(allocations are funneled
https://issues.dlang.org/show_bug.cgi?id=7044
--- Comment #51 from Martin Nowak c...@dawg.eu ---
I think requiring a `-confsection` switch limits the usefulness a lot.
One reason for the extended ini format is that we can make the linking
configurable for certain targets, e.g. m32coff or msvc14
https://issues.dlang.org/show_bug.cgi?id=7044
--- Comment #53 from Martin Nowak c...@dawg.eu ---
(In reply to Martin Nowak from comment #52)
We could solve this by always adding -L--as-needed -L-lcurl (which requires
libcurl-dev packages)
In the meantime LDC took this approach.
On Sunday, 9 August 2015 at 09:37:41 UTC, Joakim wrote:
On Sunday, 9 August 2015 at 09:15:16 UTC, ref2401 wrote:
Does the fund exist?
Are there sponsors?
How can one donate some money to D?
We do something even better, you can place bounties on specific
issues that you're willing to pay for:
On Saturday, 8 August 2015 at 13:42:03 UTC, John Colvin wrote:
That would be neat, but the thing is you can already do this:
auto sub = arr[idx + 123 * 10 .. $][0 .. 1];
The only argument that might hold weight is that calculating
opDollar and doing two index/slice operations might be
On Sunday, 9 August 2015 at 10:21:06 UTC, NVolcz wrote:
There seems like there are many problems with DMD and many
problems asked here in the newsgroup are answered with don't
use DMD.
Maybe it's time to deprecate DMD? Maybe at least make sure it's
up to date with the ecosystem.
Sorry didn't
On 09/08/15 09:33, Walter Bright wrote:
We ship Phobos as a shared library on Linux, OSX and FreeBSD.
No on OS X.
--
/Jacob Carlborg
On Sunday, 9 August 2015 at 10:40:06 UTC, Nordlöw wrote:
Couldn't the chunk logic be deduced aswell?
Yes :)
See update at:
https://github.com/nordlow/justd/blob/a633b52876388921ec49c189f374746f7b4d8c93/tests/t_rawio.d
What would a suitable value for `preferred_disk_write_size` be?
Is
https://issues.dlang.org/show_bug.cgi?id=7044
--- Comment #52 from Martin Nowak c...@dawg.eu ---
Sorry for taking over this bug report, none of the dmd.conf enhancements
address the original issue.
Linking is already fully configurable since we have both the `-defaultlib=` and
the `-conf=`
On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote:
snip /
It's not so much language problems, it's tooling problems. It's
the most important and perhaps most neglected aspect of the D
ecosystem.
1. DMD has unsatisfactory codegen for anything other than debug
builds.
2. DMD generates x87
On Sunday, 9 August 2015 at 00:50:16 UTC, Ali Çehreli wrote:
Ali
Now benchmarks write and read separately:
https://github.com/nordlow/justd/blob/0d746b2c1800a82a61a6cb7edcabfd9664066b2c/tests/t_rawio.d
Couldn't the chunk logic be deduced aswell? Something like:
void
https://issues.dlang.org/show_bug.cgi?id=7044
--- Comment #50 from Dicebot pub...@dicebot.lv ---
Leandro is on (quite long) sick leave right now. I will start poking Walter
again about this issue once he is back.
--
On 9 August 2015 at 20:04, Dmitry Olshansky via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 09-Aug-2015 12:33, Manu via Digitalmars-d wrote:
On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 9/08/2015 2:40 p.m., Manu via Digitalmars-d
On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 9/08/2015 2:40 p.m., Manu via Digitalmars-d wrote:
[...]
Don't worry about it!
But I see your point. All we can do is truck on.
You will enjoy my latest blog post I think[0].
I reiterate
Am Sun, 9 Aug 2015 02:17:11 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/9/2015 2:07 AM, Johannes Pfau wrote:
DMD has the advantage that whenever a frontend pull request requires
glue layer changes you get at and once by the contributor. But for
LDC and GDC the glue layer
On Sunday, 9 August 2015 at 09:15:16 UTC, ref2401 wrote:
Does the fund exist?
Are there sponsors?
How can one donate some money to D?
We do something even better, you can place bounties on specific
issues that you're willing to pay for:
https://www.bountysource.com/teams/d
If the issue
On 8/9/2015 2:33 AM, Johannes Pfau wrote:
Sure. I'm not arguing that LDC or GDC should be the default, just
wanted to explain why we could really need some more contributors for GDC/LDC
;-)
We could use more contributors in general!
On 8/9/2015 2:25 AM, Iain Buclaw via Digitalmars-d wrote:
Now we have the testsuite, which seems to be a good enough gauge for finding
problems. However if there's been a change (eg: refactor) between what codegen
is lowered in the frontend vs. glue, then it becomes a commit hunt trawling
On 9 Aug 2015 11:35 am, Johannes Pfau via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am Sun, 9 Aug 2015 02:17:11 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/9/2015 2:07 AM, Johannes Pfau wrote:
DMD has the advantage that whenever a frontend pull request requires
On 9 August 2015 at 07:31, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 8/8/2015 7:40 PM, Manu via Digitalmars-d wrote:
1. DMD has unsatisfactory codegen for anything other than debug builds.
Do you mean the codegen is slower? But consider that the bottleneck in
On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:
On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote:
...
This pretty much hit the nail on the head on why dmd needs
deprecated.
I'm tired of seeing 'BUT IT WORKS ON WINDOWS' as an excuse. I
don't care if it works on windows, it
On 9 August 2015 at 08:36, Tofu Ninja via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:
On Sunday, 9 August 2015 at 02:41:00 UTC, Manu wrote:
...
This pretty much hit the nail on the head on why dmd needs deprecated.
I'm tired
On Sunday, 9 August 2015 at 06:59:15 UTC, Iain Buclaw wrote:
On 9 August 2015 at 08:36, Tofu Ninja via Digitalmars-d
digitalmars-d@puremagic.com wrote:
[...]
(Neo)Vim? :o)
[...]
Not sure which environment you refer to, but most times I've
been pinged
into discussion, the problem was
On 9 August 2015 at 09:03, rsw0x via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sunday, 9 August 2015 at 06:59:15 UTC, Iain Buclaw wrote:
On 9 August 2015 at 08:36, Tofu Ninja via Digitalmars-d
digitalmars-d@puremagic.com wrote:
[...]
(Neo)Vim? :o)
[...]
Not sure which
On 8/8/2015 11:38 PM, Iain Buclaw via Digitalmars-d wrote:
I know that at least for the benefit of std.math, we should allow any precision
without expensive casting to and from real, which has been found to be a
performance problem on various benchmarks (GDC, LDC, DMD, doesn't matter).
I
On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote:
If the libraries were shared, this would reduce linking time, which in various
benchmarks I've done is where most small projects spend the majority of their
time doing. But no one has as of yet come up with a feasibly implementable idea
On 8/8/2015 11:36 PM, Tofu Ninja wrote:
On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:
dmd not being deprecated continues the cycle of gdc/ldc lagging versions
behind and being understaffed in manpower.
I think another point to look at is how far gdc and ldc have come while still
On 9 August 2015 at 09:28, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 8/8/2015 11:38 PM, Iain Buclaw via Digitalmars-d wrote:
I know that at least for the benefit of std.math, we should allow any
precision
without expensive casting to and from real, which has been
On 9 August 2015 at 09:33, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote:
If the libraries were shared, this would reduce linking time, which in
various
benchmarks I've done is where most small projects spend the
On 8/9/2015 12:36 AM, Iain Buclaw via Digitalmars-d wrote:
What about intrinsics?
https://github.com/D-Programming-Language/phobos/blob/94f718e5c69939f595fb839d3aae24878f126d78/std/math.d#L630
There isn't a simd cosine instruction, so making cos(double) builtin
accomplishes nothing. However,
On 9 August 2015 at 09:53, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 8/9/2015 12:36 AM, Iain Buclaw via Digitalmars-d wrote:
What about intrinsics?
https://github.com/D-Programming-Language/phobos/blob/94f718e5c69939f595fb839d3aae24878f126d78/std/math.d#L630
On 8/9/2015 12:51 AM, Iain Buclaw via Digitalmars-d wrote:
On 9 August 2015 at 09:33, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
On 8/9/2015 12:18 AM, Iain Buclaw via Digitalmars-d wrote:
If the libraries were shared, this
On 8/9/2015 1:05 AM, Iain Buclaw via Digitalmars-d wrote:
This is on Windows? I'm not seeing this on Linux. http://goo.gl/58yhwU
You're seeing that on Linux because doubles are passed/returned in XMM0 on
Linux, and the only way to load XMM0 into the x87 is to pass it through a memory
On 8/9/2015 1:11 AM, Walter Bright wrote:
You're seeing that on Linux because doubles are passed/returned in XMM0 on
Linux, and the only way to load XMM0 into the x87 is to pass it through a memory
location. There's still no casting to/from real, even in that asm code.
BTW, if you want to
On 8/8/2015 6:08 AM, Temtaime wrote:
Any ideas ? Should i try to create a DIP ?
It's a good suggestion, but the responses here pretty much cover the territory
adequately with existing features. I don't think a new feature for this is
justified. But we're always looking for better ideas, so
Am Sun, 9 Aug 2015 01:05:35 -0700
schrieb Walter Bright newshou...@digitalmars.com:
I don't understand your question. On Linux, TLS data is inserted into
the same section that gcc puts it. On OSX, where gcc didn't support
TLS, dmd did create it into a data segment. Every time a new thread
was
Am Sun, 9 Aug 2015 00:32:00 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/8/2015 11:36 PM, Tofu Ninja wrote:
On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:
dmd not being deprecated continues the cycle of gdc/ldc lagging
versions behind and being understaffed in
We can read files at compile-time:
enum file = import(fileName);
But we cannot write to a file or create files at compile time.
Generating code at compile-time and mixing it in is fun but has a
few flaws.
It isn't debuggable, the generated code cannot be directly
inspected (we have to use
Does the fund exist?
Are there sponsors?
How can one donate some money to D?
On 8/9/2015 2:07 AM, Johannes Pfau wrote:
DMD has the advantage that whenever a frontend pull request requires
glue layer changes you get at and once by the contributor. But for
LDC and GDC the glue layer changes have to be implemented by GDC/LDC
devs.
If LDC were the default, then the GDC
On 8/9/2015 2:04 AM, Johannes Pfau wrote:
That statement is too broad to be true ;-) GCC's emulated TLS doesn't
have adjacent memory for TLS variables and it works fine with D
(and the GC). It is a little bit slower than if we had adjacent memory.
OTOH this approach works with all kinds of
Andrei has been working on a D foundation. I'm not sure where it's at.
On 9 August 2015 at 19:15, ref2401 via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Does the fund exist?
Are there sponsors?
How can one donate some money to D?
On 9 August 2015 at 11:07, Johannes Pfau via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am Sun, 9 Aug 2015 00:32:00 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/8/2015 11:36 PM, Tofu Ninja wrote:
On Sunday, 9 August 2015 at 05:18:33 UTC, rsw0x wrote:
dmd not
https://issues.dlang.org/show_bug.cgi?id=5100
--- Comment #10 from Iain Buclaw ibuc...@gdcproject.org ---
For a while now I've been thinking that the bottleneck is probably to do with
alignment, but I'd have to get out my (now two generations old) atom netbook to
investigate further.
--
https://issues.dlang.org/show_bug.cgi?id=14849
--- Comment #10 from Martin Nowak c...@dawg.eu ---
https://github.com/D-Programming-Language/druntime/pull/1341
--
https://issues.dlang.org/show_bug.cgi?id=14871
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
I don't have much experience and time to contribute to code-base
directly. But I'd like to donate some money every month. I think
(hope) there are several guys who would like to donate to. There
must be the way to do it.
On Sunday, 9 August 2015 at 12:54:39 UTC, Nicholas Wilson wrote:
On Sunday, 9 August 2015 at 01:29:16 UTC, Christopher Davies
wrote:
[...]
using UFCS (universal function call syntax) you would normally
write that as:
records =records.filter!(r = r[where] == val)();
and then leveraging D's
On Sunday, 9 August 2015 at 13:40:51 UTC, cym13 wrote:
On Sunday, 9 August 2015 at 13:22:02 UTC, Reflexive wrote:
You can use std.algorithm.remove for that. If you need more
advanced ways to remove elements, you may want to switch from a
regular dynamic array to a std.container.array.
I get
I wrote import std.algorithm.remove ;, and I dont have any longer
any error. But, it dont want to remove the item. Here is the
source, the problem is in the shuffle() method :
// sabot.d
// version 0.0.1
import std.stdio ;
import std.random ;
import std.algorithm : remove ;
void main(){
https://issues.dlang.org/show_bug.cgi?id=14892
Issue ID: 14892
Summary: -profile=gc doesn't account for GC API allocations
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Hi
I have seen that it is possible to remove an element from a
associative array, but dont find any reference, including in D's
specification, about any element removing in dynamic array. I can
use loops for that, but isnt any way to simple reduce a dynamic
array size ?
Thank you
https://issues.dlang.org/show_bug.cgi?id=14889
Issue ID: 14889
Summary: ICE: Assertion `o-dyncast() == DYNCAST_DSYMBOL'
failed.
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
On 09-Aug-2015 15:27, Manu via Digitalmars-d wrote:
On 9 August 2015 at 20:04, Dmitry Olshansky via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 09-Aug-2015 12:33, Manu via Digitalmars-d wrote:
On 9 August 2015 at 13:34, Rikki Cattermole via Digitalmars-d
digitalmars-d@puremagic.com
On 8/9/15 5:15 AM, Walter Bright wrote:
On 8/9/2015 2:04 AM, Johannes Pfau wrote:
That statement is too broad to be true ;-) GCC's emulated TLS doesn't
have adjacent memory for TLS variables and it works fine with D
(and the GC). It is a little bit slower than if we had adjacent memory.
OTOH
On 9 August 2015 at 23:52, Dmitry Olshansky via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 09-Aug-2015 15:27, Manu via Digitalmars-d wrote:
On 9 August 2015 at 20:04, Dmitry Olshansky via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 09-Aug-2015 12:33, Manu via Digitalmars-d
On Sunday, 9 August 2015 at 14:23:33 UTC, Chris Davies wrote:
The problem is, based on user input, I am optionally filtering
a list, possibly passing it through 0, 1, 2 or more filters
based on their input. Each successive filter runs on either the
original range or the result of the previous
On Sunday, 9 August 2015 at 14:00:55 UTC, Rikki Cattermole wrote:
I'm actually at the point where I believe the addition of
string import was a bad one. No. I prefer preprocessing into a
D file first.
It irks me, you have to be pretty careful with them, but at
least a preprocessed file you
On Sunday, 9 August 2015 at 11:06:34 UTC, Nordlöw wrote:
On Sunday, 9 August 2015 at 10:40:06 UTC, Nordlöw wrote:
Couldn't the chunk logic be deduced aswell?
Yes :)
See update at:
https://github.com/nordlow/justd/blob/a633b52876388921ec49c189f374746f7b4d8c93/tests/t_rawio.d
What would a
On Sunday, 9 August 2015 at 15:37:23 UTC, Binarydepth wrote:
So I should use the REF like this ?
import std.stdio : writeln;
void main() {
immutable a=5;
int[a] Arr;
foreach(num; 0..a) {
Arr[num] = num;
}
foreach(num, ref ele;
On Sunday, 9 August 2015 at 09:15:16 UTC, ref2401 wrote:
Does the fund exist?
Are there sponsors?
How can one donate some money to D?
Ask a D developer you appreciate (in private) to give you his
paypal/email, and pay him directly like he's a musician on the
side of the road. He will be
https://issues.dlang.org/show_bug.cgi?id=14891
Issue ID: 14891
Summary: profilegc_setlogfilename w/o null-terminated string
might fail during fopen
Product: D
Version: D2
Hardware: All
OS: All
On 09/08/15 15:53, Andrei Alexandrescu wrote:
Where is the bugzilla issue etc :o). -- Andrei
It's been there for a while [1] ;)
[1] https://issues.dlang.org/show_bug.cgi?id=9476
--
/Jacob Carlborg
On 09-Aug-2015 20:29, karabuta wrote:
A lot of request are made most often about what needs to be added in D
and what is lacking (multiple compilers, debugging tools, IDEs, GUI,
...). I think a lot has been done already and I suggest focus should be
centered on making them stable. Sadly, some
On 09/08/15 13:38, Manu via Digitalmars-d wrote:
In fact, we've been discussing for a few months that we'd have have
another very promising opportunity to use D at work in a really
appropriate context if I could rely on Android and iOS appearing
within 6-12 months or so.
There's been quite a
On 09-Aug-2015 16:22, ref2401 wrote:
I don't have much experience and time to contribute to code-base
directly. But I'd like to donate some money every month. I think (hope)
there are several guys who would like to donate to. There must be the
way to do it.
Other options involve hiring
On Sunday, 9 August 2015 at 00:22:53 UTC, Jay Norwood wrote:
On Saturday, 8 August 2015 at 18:28:25 UTC, Binarydepth wrote:
This is the new code :
foreach(num; 0..liEle) {//Data input loop
write(Input the element : , num+1, );
readf( %d,
On Sunday, 9 August 2015 at 09:37:41 UTC, Joakim wrote:
We do something even better, you can place bounties on specific
issues that you're willing to pay for:
The bounty thing is pretty useless to me. The amounts don't even
cover the administrative overhead (working through all the hassle
to
On Sunday, 9 August 2015 at 14:24:38 UTC, Reflexive wrote:
Error: module remove is in file 'std/algorithm/remove.d' which
cannot be read
remove() is a function in module std.algorithm:
import std.algorithm: remove;
remove(foo);
On 10/08/2015 2:24 a.m., Reflexive wrote:
On Sunday, 9 August 2015 at 13:40:51 UTC, cym13 wrote:
On Sunday, 9 August 2015 at 13:22:02 UTC, Reflexive wrote:
You can use std.algorithm.remove for that. If you need more advanced
ways to remove elements, you may want to switch from a regular
On Sunday, 9 August 2015 at 16:42:16 UTC, Jay Norwood wrote:
The i+3 initialization is just so you can see that v is the Arr
member (not the index) in the other loops.
import std.stdio : writeln;
void main() {
immutable a=5;
int[a] Arr;
foreach(i, ref v; Arr) {
On 10/08/2015 1:22 a.m., ref2401 wrote:
I don't have much experience and time to contribute to code-base
directly. But I'd like to donate some money every month. I think (hope)
there are several guys who would like to donate to. There must be the
way to do it.
Perhaps, what we should do is a
On 8/9/15 5:07 AM, JDemler wrote:
We can read files at compile-time:
enum file = import(fileName);
But we cannot write to a file or create files at compile time.
Generating code at compile-time and mixing it in is fun but has a few
flaws.
It isn't debuggable, the generated code cannot be
On 8/9/15 5:15 AM, ref2401 wrote:
Does the fund exist?
Are there sponsors?
How can one donate some money to D?
There will be a possibility with the D Language Foundation, hopefully by
the end of this year. -- Andrei
On Sunday, 9 August 2015 at 15:37:23 UTC, Binarydepth wrote:
So I should use the REF like this ?
import std.stdio : writeln;
void main() {
immutable a=5;
int[a] Arr;
foreach(num; 0..a) {
Arr[num] = num;
}
foreach(num, ref ele;
On 10/08/2015 1:57 a.m., cym13 wrote:
On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu wrote:
On 8/9/15 5:07 AM, JDemler wrote:
We can read files at compile-time:
enum file = import(fileName);
But we cannot write to a file or create files at compile time.
Generating code at
https://issues.dlang.org/show_bug.cgi?id=14890
Issue ID: 14890
Summary: [REG 2.068.0-rc1] Can not construct a RedBlackTree of
Tuples
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
On Sunday, 9 August 2015 at 10:40:06 UTC, Nordlöw wrote:
On Sunday, 9 August 2015 at 00:50:16 UTC, Ali Çehreli wrote:
Ali
Now benchmarks write and read separately:
I benchmarked my first results:
D:\visd\raw\raw\Releaseraw
time write msecs:457
time read msecs:75
This is for 160MB of
A lot of request are made most often about what needs to be added
in D and what is lacking (multiple compilers, debugging tools,
IDEs, GUI, ...). I think a lot has been done already and I
suggest focus should be centered on making them stable. Sadly,
some have even been abandoned after all the
On Sunday, 9 August 2015 at 12:52:24 UTC, Adam D. Ruppe wrote:
On Sunday, 9 August 2015 at 09:37:41 UTC, Joakim wrote:
We do something even better, you can place bounties on
specific issues that you're willing to pay for:
The bounty thing is pretty useless to me. The amounts don't
even cover
On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu
wrote:
On 8/9/15 5:07 AM, JDemler wrote:
We can read files at compile-time:
enum file = import(fileName);
But we cannot write to a file or create files at compile time.
Generating code at compile-time and mixing it in is fun
On 10/08/2015 2:38 a.m., jmh530 wrote:
On Sunday, 9 August 2015 at 14:00:55 UTC, Rikki Cattermole wrote:
I'm actually at the point where I believe the addition of string
import was a bad one. No. I prefer preprocessing into a D file first.
It irks me, you have to be pretty careful with them,
On Sunday, 9 August 2015 at 15:30:32 UTC, Reflexive wrote:
I wrote import std.algorithm.remove ;, and I dont have any
longer any error. But, it dont want to remove the item. Here is
the source, the problem is in the shuffle() method :
...
Why not just use std.random.shuffle [1]?
import
This seems like a reasonable use but errors, obviously I can do
it in many other ways:
ulong[] result = iota(1UL, 10UL).array;
Error: static assert Argument types in (ulong) are not all
convertible to size_t:
(ulong) C:\D\dmd2\src\phobos\std\array.d 516
And while I'm here why do
On 08/09/2015 10:13 PM, ixid wrote:
This seems like a reasonable use but errors, obviously I can do it in
many other ways:
ulong[] result = iota(1UL, 10UL).array;
Error: static assert Argument types in (ulong) are not all convertible
to size_t: (ulong)
09.08.2015 23:22, Reflexive пишет:
Try to use
this.sabotarray = this.sabotarray.remove(id_card);
remove() removes element(s) but doesn't change length of 'old' array. To
get new length you should use 'new' array that returned from remove().
In this case I get rid of two excessive kings in
On Sunday, 9 August 2015 at 20:23:00 UTC, Reflexive wrote:
I see that remove() removes the value of the element but keeps
the same size of the array, and replace the value by a new one
at the end. The method :
class sabot{
card[] sabotarray ;
(...)
card getCard(){
On 8/9/2015 4:38 AM, Manu via Digitalmars-d wrote:
On 9 August 2015 at 15:31, Walter Bright via Digitalmars-d
But waiting for someone else to discover the same thing on some other piece
of code means you'll be waiting a long time.
I understand, but that's not sustainable.
We can't be in a
On Sunday, 9 August 2015 at 20:38:05 UTC, drug wrote:
09.08.2015 23:22, Reflexive пишет:
Try to use
this.sabotarray = this.sabotarray.remove(id_card);
remove() removes element(s) but doesn't change length of 'old'
array. To get new length you should use 'new' array that
returned from
On Sunday, 9 August 2015 at 21:06:10 UTC, anonymous wrote:
On Sunday, 9 August 2015 at 17:43:59 UTC, 岩倉 澪 wrote:
Afaict it is the best way to do what I'm trying to do, and
since the data is mutable and cast to immutable with
assumeUnique, casting it back to mutable shouldn't be a
problem.
On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu
wrote:
On 8/9/15 5:07 AM, JDemler wrote:
We can read files at compile-time:
enum file = import(fileName);
But we cannot write to a file or create files at compile time.
Generating code at compile-time and mixing it in is fun
On Sunday, 9 August 2015 at 14:00:55 UTC, Rikki Cattermole wrote:
On 10/08/2015 1:57 a.m., cym13 wrote:
On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu
wrote:
On 8/9/15 5:07 AM, JDemler wrote:
We can read files at compile-time:
enum file = import(fileName);
But we cannot
On Sunday, 9 August 2015 at 20:13:38 UTC, ixid wrote:
This seems like a reasonable use but errors, obviously I can do
it in many other ways:
ulong[] result = iota(1UL, 10UL).array;
Error: static assert Argument types in (ulong) are not all
convertible to size_t:
(ulong)
On Sunday, 9 August 2015 at 17:29:08 UTC, karabuta wrote:
A lot of request are made most often about what needs to be
added in D and what is lacking (multiple compilers, debugging
tools, IDEs, GUI, ...). I think a lot has been done already and
I suggest focus should be centered on making them
On Sunday, 9 August 2015 at 17:43:59 UTC, 岩倉 澪 wrote:
Afaict it is the best way to do what I'm trying to do, and
since the data is mutable and cast to immutable with
assumeUnique, casting it back to mutable shouldn't be a
problem. Technically casting away immutable might be undefined
On 8/9/2015 12:59 PM, ponce wrote:
Well, for Win64 the codegen is simply wrong. I don't even care if the codegen is
fast or not, but correct should be a given. Biggest problem for me so far.
There's nothing I nor anyone else can do with comments like this.
It passes the executable part of the
1 - 100 of 143 matches
Mail list logo
