https://issues.dlang.org/show_bug.cgi?id=14140
Ketmar Dark ket...@ketmar.no-ip.org changed:
What|Removed |Added
Summary|Bad codegen when variable |Bad codegen for CTFE
On Sat, 07 Feb 2015 09:23:42 -0800, H. S. Teoh via Digitalmars-d-learn
wrote:
On Sat, Feb 07, 2015 at 02:35:13PM +, Danny via Digitalmars-d-learn
wrote:
[...]
cut- gdc
A.d cc1d: ../../src/gcc/d/dfrontend/statement.c:293:
https://issues.dlang.org/show_bug.cgi?id=13474
--- Comment #6 from Илья Ярошенко ilyayaroshe...@gmail.com ---
F foo(F)(F c, F d) {
c += d;
c += d;
return c;
}
void test1() {
alias F = double;
enum F d = (cast(F)(2)) ^^ (F.max_exp - 1);
assert(foo(-d, d) == d);
}
--
https://issues.dlang.org/show_bug.cgi?id=13474
--- Comment #9 from Илья Ярошенко ilyayaroshe...@gmail.com ---
(In reply to yebblies from comment #8)
(In reply to Илья Ярошенко from comment #6)
F foo(F)(F c, F d) {
c += d;
c += d;
return c;
}
void test1() {
alias
On Sunday, 8 February 2015 at 09:52:50 UTC, Namespace wrote:
On Sunday, 8 February 2015 at 01:39:19 UTC, Gan wrote:
On Saturday, 7 February 2015 at 23:29:01 UTC, Namespace wrote:
On Saturday, 7 February 2015 at 22:09:03 UTC, Gan wrote:
Is there a better D graphics library in the works?
I'm
On Sat, 07 Feb 2015 21:33:46 +, Kenny wrote:
The above code snippet works correctly when I use LDC compiler (it finds
expected 'f' value and prints it to console). I'm wondering is it a bug
in DMD?
nope, this is a bug in your code. compiler (by the specs) is free to
perform intermediate
On Sunday, 8 February 2015 at 04:45:55 UTC, Andrei Alexandrescu
wrote:
On 2/7/15 8:21 PM, H. S. Teoh via Digitalmars-d wrote:
Come to think of it, is there any point in making malloc
@safe/@trusted
at all? I don't think it's possible to make free() @safe, so
what's the
purpose of making malloc
On 02/07/2015 06:35 AM, Danny wrote:
I'm trying to use immutable class instances and that seems to be really
difficult.
You are not alone. :)
Just some reminders:
- immutable is a requirement that may not be usable with every type.
- immutable string foo() {} is a member function that
nope, this is a bug in your code. compiler (by the specs) is
free to
perform intermediate calculations with any precision that is
not lower
than a highest used type (i.e. not lower that `float`'s one for
`while`
condition (`f + eps != f`). it may be even infinite precision,
so your
code may
On Sun, 08 Feb 2015 09:05:30 +, Kenny wrote:
Thanks, it's clear now. I still have one question in the above post, I
would appreciate if you check it too.
i've seen that, but i don't know the answer, sorry. here we have to
summon Walter to explain what his intentions was, how it should
For example, according to IEEE-754 specification if we work
with 32bit floating point numbers (floats in D) then the
following pseudo code prints 'Works'.
F32 f = 16777216.0f;
F32 f2 = f + 0.1f;
if is_the_same_binary_presentation(f, f2)
Print(Works);
As I understand D does not guarantee
https://issues.dlang.org/show_bug.cgi?id=13474
--- Comment #8 from yebblies yebbl...@gmail.com ---
(In reply to Илья Ярошенко from comment #6)
F foo(F)(F c, F d) {
c += d;
c += d;
return c;
}
void test1() {
alias F = double;
enum F d = (cast(F)(2)) ^^ (F.max_exp -
On Sunday, 8 February 2015 at 09:19:08 UTC, Kenny wrote:
For example, according to IEEE-754 specification if we work
with 32bit floating point numbers (floats in D) then the
following pseudo code prints 'Works'.
F32 f = 16777216.0f;
F32 f2 = f + 0.1f;
if is_the_same_binary_presentation(f, f2)
i think you are mixing two things here. IEEE doesn't specify
which
internal representation compilers should use, it only specifies
the
results for chosen representation. so if D specs states that
`float`
calculations are always performing with `float` precision (and
specs
aren't), your sample
On 02/07/2015 06:35 AM, Danny wrote:
What I'm trying to do is save space by putting often-used Attrs into an
array and just compressing references to those into 1 Byte in the other
data structures where it's used (these other data structures are not
thread-local).
The following is based on
On Sunday, 8 February 2015 at 01:39:19 UTC, Gan wrote:
On Saturday, 7 February 2015 at 23:29:01 UTC, Namespace wrote:
On Saturday, 7 February 2015 at 22:09:03 UTC, Gan wrote:
Is there a better D graphics library in the works?
I'm using SFML(which is very easy and has lots of features)
but it
https://issues.dlang.org/show_bug.cgi?id=13474
--- Comment #10 from yebblies yebbl...@gmail.com ---
(In reply to Илья Ярошенко from comment #9)
Can you open https://github.com/D-Programming-Language/dmd/pull/3992 please?
Why? The results are still visible here:
https://issues.dlang.org/show_bug.cgi?id=14147
Ketmar Dark ket...@ketmar.no-ip.org changed:
What|Removed |Added
CC||ket...@ketmar.no-ip.org
There is no right or wrong when you compare floating point
values for equality (and inequality) unless those values can be
represented exactly in the machine. 1.0 is famously not
representable exactly. (It is similar to how 1/3 cannot be
represented in the decimal system.)
Here I tested one
On 2015-02-05 22:35, Walter Bright wrote:
It's no different from:
Q: the compiler gave me a mismatched type error!
A: put in a cast and it'll compile!
The difference is if you do that the compiler won't disable type
checking for the whole function.
--
/Jacob Carlborg
https://issues.dlang.org/show_bug.cgi?id=14144
--- Comment #3 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/35df0364a5418909d6f6a1a85b2895d329b94b17
fix Issue 14144 - opAssign
https://issues.dlang.org/show_bug.cgi?id=13474
--- Comment #11 from Илья Ярошенко ilyayaroshe...@gmail.com ---
OK.
This is DMD optimization bug too.
DMD compiles (-d)+(d+d) instead of ((-d)+d)+d.
--
On Sunday, 8 February 2015 at 06:26:38 UTC, Ali Çehreli wrote:
On 02/07/2015 09:57 PM, Lave Zhang wrote:
Hi,
My first D program is like this:
---
import std.stdio;
void main(string[] args)
{
dstring s1 = hello你好d;
writeln(s1);
}
https://issues.dlang.org/show_bug.cgi?id=13474
--- Comment #7 from yebblies yebbl...@gmail.com ---
change(-1e100) calculates its result at real precision, then returns it in
ST(0). It is duplicated via the stack (truncating to double) but the full
precision value is then added with (1e104) and
On Sun, 08 Feb 2015 09:19:06 +, Kenny wrote:
I asked more about this case:
float f = 16777216.0f;
if (f == f + 1.0f)
writeln(Works);
Although all operands are 32bit FP the result is not guaranteed to be
equal to the result for FP32 computations as specified by IEEE-754.
i think you
Also note that denormal numbers is an issue, e.g. D assumes that
they are always supported, I think. Which frequently is not the
case...
https://issues.dlang.org/show_bug.cgi?id=14147
Issue ID: 14147
Summary: Compiler crash on identical functions in a single
module
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
H. S. Teoh:
Come to think of it, is there any point in making malloc
@safe/@trusted at all?
I am not asking for a @trusted function. I'd like a @system
template wrapper for malloc/calloc/free that is safer than the C
functions (safer because it's type-aware).
Bye,
bearophile
On Sat, 07 Feb 2015 13:02:58 +, Craig Dillabaugh wrote:
On Saturday, 7 February 2015 at 06:23:43 UTC, ketmar wrote:
On Fri, 06 Feb 2015 18:48:16 +, deadalnix wrote:
Well you are talking for talking, we are waiting on your awesome PRs.
easy deal. and i'm waiting for Andrei and Walter
https://issues.dlang.org/show_bug.cgi?id=13474
yebblies yebbl...@gmail.com changed:
What|Removed |Added
CC||yebbl...@gmail.com
--- Comment
https://issues.dlang.org/show_bug.cgi?id=14146
--- 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/1a4f77da9b19cda4d245c56e9e3e3411ff2bace7
fix Issue 14146 - ICE with
https://issues.dlang.org/show_bug.cgi?id=14146
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.dlang.org/show_bug.cgi?id=14140
Ketmar Dark ket...@ketmar.no-ip.org changed:
What|Removed |Added
CC||ket...@ketmar.no-ip.org
https://issues.dlang.org/show_bug.cgi?id=14140
--- Comment #3 from Ketmar Dark ket...@ketmar.no-ip.org ---
and, hehehe:
import std.stdio;
import std.string;
struct Vector3 {
union {
float[3] flat;
float[3][1] A;
}
string toString() const {
return format(`[%( %s %) ]`,
On 2015-02-08 01:39, Mike Parker wrote:
But apparently this can be done now with dub.selections.json.
Yes, exactly. I just replied to someone calming updating packages
automatically was a good idea. I also had to fight quite a lot to get
this feature into Dub.
--
/Jacob Carlborg
Am Sat, 07 Feb 2015 15:50:53 -0800
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
I was looking into ways to make core.stdc safer. That should be
relatively easy to do by defining a few wrappers. For example:
This might be a good idea, but it might also be more difficult than you
On 2015-02-03 19:00, Russel Winder via Digitalmars-d wrote:
Learn lessons from SBT vs. SCons/Gant/Gradle: SBT is a Scala build
system using Scala programs as input.
Some Scala folk got religious about Scala being the only right language
for Scala builds, and created what has become SBT.
On 2015-02-08 at 06:36, Mike Parker wrote:
On 2/8/2015 11:32 AM, FG wrote:
On 2015-02-08 at 01:20, Mike Parker wrote:
In your case, forget destructors and the destroy method. Just
implement a common method on all of your objects that need cleanup
(perhaps name it 'terminate') and call that.
https://issues.dlang.org/show_bug.cgi?id=481
--- Comment #28 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dlang.org
https://github.com/D-Programming-Language/dlang.org/commit/e17cfa04aa62d16a942e422f8e8e96af49b50187
Revert Issue 481
On Sunday, 8 February 2015 at 12:43:38 UTC, FG wrote:
On 2015-02-08 at 03:19, Andrei Alexandrescu wrote:
Indeed we have no safe way to wrap free.
How about this to prevent double free:
Wrapped malloc keeps a static thread-local lookup structure for
successful allocations (if having to
come to think of it, is there any point in making malloc
@safe/@trusted
at all? I don't think it's possible to make free() @safe, so
what's the
purpose of making malloc callable from @safe code?
At least two programs, widely used by folks here, never release
their memory. Those could be made
https://issues.dlang.org/show_bug.cgi?id=13548
yebblies yebbl...@gmail.com changed:
What|Removed |Added
CC||yebbl...@gmail.com
--- Comment
On 2015-02-08 at 03:19, Andrei Alexandrescu wrote:
Indeed we have no safe way to wrap free.
How about this to prevent double free:
Wrapped malloc keeps a static thread-local lookup structure for successful
allocations (if having to release memory from the same thread is an acceptable
On Thursday, 5 February 2015 at 16:34:38 UTC, Zach the Mystic
wrote:
Can you name one, or even imagine one? Bear in mind people like
Andrei and myself do not like to read or write the later form
and will use it much less, regardless of benefit.
Daniel Murphy has (function stubs with
On Sunday, 8 February 2015 at 01:57:55 UTC, Meta wrote:
On Sunday, 8 February 2015 at 00:31:42 UTC, Mike wrote:
Is `this` overloaded to mean this class in a static context
or is `this` only valid in a non-static context. Please
clarify, and if it's a bug, help me understand so I can make
an
https://issues.dlang.org/show_bug.cgi?id=14147
--- Comment #2 from Kenji Hara k.hara...@gmail.com ---
Reduced test case:
struct S(alias func) { void foo() { func(1); } }
void main()
{
}
pure auto mul(const int[] left, const int[] right)
{
S!(a = a)().foo();
}
pure auto mul(const int[]
https://issues.dlang.org/show_bug.cgi?id=13474
--- Comment #12 from yebblies yebbl...@gmail.com ---
(In reply to Илья Ярошенко from comment #11)
OK.
This is DMD optimization bug too.
DMD compiles (-d)+(d+d) instead of ((-d)+d)+d.
Yes. Is there a bug report for that specific bug?
--
On Thursday, 29 January 2015 at 08:05:28 UTC, Laeeth Isharc wrote:
On Wednesday, 28 January 2015 at 18:46:05 UTC, Benjamin Thaut
wrote:
Am 28.01.2015 um 18:05 schrieb Andrei Alexandrescu:
On 1/28/15 9:01 AM, Benjamin Thaut wrote:
On Wednesday, 28 January 2015 at 16:18:18 UTC, Andrei
On Sunday, 8 February 2015 at 10:39:22 UTC, Jacob Carlborg wrote:
On 2015-02-07 20:17, Vladimir Panteleev wrote:
I don't see how this setting is at all relevant to the problem
at hand.
Yes, sorry, sourcePaths and importPaths were the fields I
was thinking about. Although I think
On Thursday, 5 February 2015 at 00:37:31 UTC, Adam D. Ruppe wrote:
On Thursday, 5 February 2015 at 00:35:50 UTC, bearophile wrote:
Contracts can be read by tools, and they are part of the
function signature. Contracts should be encouraged and
increased, not discouraged.
I agree. Moreover,
On Tuesday, 3 February 2015 at 01:33:32 UTC, deadalnix wrote:
On Tuesday, 3 February 2015 at 00:59:26 UTC, Andrei
Alexandrescu wrote:
On 2/2/15 4:23 PM, eles wrote:
On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote:
Can we please change the file extensions in DMD from .c to
.cpp for
On Saturday, 7 February 2015 at 20:53:48 UTC, Meta wrote:
On Saturday, 7 February 2015 at 19:38:10 UTC, Marc Schütz wrote:
On Saturday, 7 February 2015 at 05:27:39 UTC, Andrei
Alexandrescu wrote:
On 2/6/15 8:28 PM, Jonathan Marler wrote:
Do you know if D might support that later or if there's
On 2015-02-07 20:17, Vladimir Panteleev wrote:
I don't see how this setting is at all relevant to the problem at hand.
Yes, sorry, sourcePaths and importPaths were the fields I was
thinking about. Although I think mainSourceFile may be needed as well,
otherwise dub will look for app.d.
--
https://issues.dlang.org/show_bug.cgi?id=13474
--- Comment #13 from Илья Ярошенко ilyayaroshe...@gmail.com ---
Yes. https://issues.dlang.org/show_bug.cgi?id=13485
--
https://issues.dlang.org/show_bug.cgi?id=13485
yebblies yebbl...@gmail.com changed:
What|Removed |Added
Keywords||pull
CC|
https://issues.dlang.org/show_bug.cgi?id=481
--- Comment #27 from github-bugzi...@puremagic.com ---
Commit pushed to revert-590-fix481 at
https://github.com/D-Programming-Language/dlang.org
https://github.com/D-Programming-Language/dlang.org/commit/e17cfa04aa62d16a942e422f8e8e96af49b50187
Revert
https://issues.dlang.org/show_bug.cgi?id=14093
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords||pull, rejects-valid
---
On Sunday, 8 February 2015 at 12:43:38 UTC, FG wrote:
On 2015-02-08 at 03:19, Andrei Alexandrescu wrote:
Indeed we have no safe way to wrap free.
How about this to prevent double free:
Wrapped malloc keeps a static thread-local lookup structure for
successful allocations (if having to
Hi Ketmar,
Hi Ali,
thank you!
On Sunday, 8 February 2015 at 09:42:14 UTC, Ali Çehreli wrote:
spawn(user, cucs, ubyte(3));
^to!
Other than that, it works.
(The Attributes are basically literal constants but the library
cannot know which are used in a given
https://issues.dlang.org/show_bug.cgi?id=14140
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords||CTFE
--
On Sunday, 8 February 2015 at 16:28:21 UTC, fra wrote:
On Sunday, 8 February 2015 at 16:22:36 UTC, fra wrote:
Missclick... Anywya:
class Something
{
@disable this();
this(int i) {}
}
produces an undefined reference error.
I guess it has to do with classes implicitly inheriting from
I just realized that you cannot define a disabled default
constructor for classes: writing code like this will give a
linker error
class Something
{
On 2015-02-08 at 15:56, mzf wrote:
On Saturday, 7 February 2015 at 06:08:39 UTC, ketmar wrote:
On Sat, 07 Feb 2015 04:30:07 +, Safety0ff wrote:
False pointers, current GC is not precise.
not only that. constantly allocating big chunks of memory will inevitably
lead to OOM due to
https://issues.dlang.org/show_bug.cgi?id=14115
--- Comment #10 from Zach the Mystic reachz...@gmail.com ---
Yeah, I'll download it. It was just intimidating to approach - a lot of new
stuff. I did find a way to view the files online - some skins are very
barebones, others are quite elaborate. I
On Sunday, 8 February 2015 at 16:22:36 UTC, fra wrote:
Missclick... Anywya:
class Something
{
@disable this();
this(int i) {}
}
produces an undefined reference error.
I guess it has to do with classes implicitly inheriting from
Object, and Object defining a this(), and @disable telling
On Sunday, 8 February 2015 at 13:03:28 UTC, Marc Schütz wrote:
On Thursday, 5 February 2015 at 16:34:38 UTC, Zach the Mystic
wrote:
Can you name one, or even imagine one? Bear in mind people
like Andrei and myself do not like to read or write the later
form and will use it much less,
Small update: std::vector is now working.
https://github.com/Syniurge/Calypso/blob/master/tests/calypso/libstdc%2B%2B/vector.d
I went back to simpler problems than getting Ogre to work and
will focus on the C++ standard lib until the common class
templates work.
On Sunday, 8 February 2015 at 15:23:13 UTC, Orvid King wrote:
No, because that looks like it should be indexing a uniform
multi-dimensional array, which it very definitely is not.
Oh, I didn't notice that conflict. So ok, disregard this
suggestion. I'll just use methods like the
Zach the Mystic wrote in message
news:qxtyqdeewrjurmwhk...@forum.dlang.org...
I don't know how the second assert could men somethign different from the
first. If you assert (anything but assert(0)) first thing, you certainly
are not checking for bugs *within* the function - you're checking
fra:
However making it a compiler error would be far, far better
I think this can be filed in Bugzilla as diagnostic enhancement:
class Foo {
@disable this();
this(int i) {}
}
void main() {}
Bye,
bearophile
On Sunday, 8 February 2015 at 17:12:20 UTC, Daniel Murphy wrote:
Zach the Mystic wrote in message
news:qxtyqdeewrjurmwhk...@forum.dlang.org...
I don't know how the second assert could men somethign
different from the first. If you assert (anything but
assert(0)) first thing, you certainly
On 2015-02-06 12:37, Dicebot wrote:
D is only cross-platfrom scripting language we can rely on. This is
probably biggest problem of make (apart from bunch of legacy syntax
crap) - any real build system needs relatively complicated build rules
for target transformation. However we can reasonably
https://issues.dlang.org/show_bug.cgi?id=13649
e10s electrolysis.j...@gmail.com changed:
What|Removed |Added
CC|
On Sunday, 8 February 2015 at 16:23:44 UTC, FG wrote:
2. auto buf = new byte[](1024*1024*100);
now the gc can't free this buf.
can i free it by manual?
Yes. import core.memory; GC.free(buf.ptr); // and don't use buf
afterwards
That won't work, see:
On 2015-02-08 at 19:15, safety0ff wrote:
On Sunday, 8 February 2015 at 16:23:44 UTC, FG wrote:
2. auto buf = new byte[](1024*1024*100);
now the gc can't free this buf.
can i free it by manual?
Yes. import core.memory; GC.free(buf.ptr); // and don't use buf afterwards
That
https://issues.dlang.org/show_bug.cgi?id=14150
Issue ID: 14150
Summary: std.getopt Documentation Page be Brokeded
Product: D
Version: unspecified
Hardware: x86
URL: http://dlang.org/library/std/getopt.html
OS:
On Sunday, 8 February 2015 at 15:28:10 UTC, Vladimir Panteleev
wrote:
On Sunday, 8 February 2015 at 15:20:17 UTC, karl wrote:
Hi, it's a bit unwieldy to write/read this:
result = src[base .. base+size];
instead of:
result = src[base, size];
If you don't want to write base twice, you can
On 2/8/15 5:16 AM, John Colvin wrote:
On Sunday, 8 February 2015 at 12:43:38 UTC, FG wrote:
On 2015-02-08 at 03:19, Andrei Alexandrescu wrote:
Indeed we have no safe way to wrap free.
How about this to prevent double free:
Wrapped malloc keeps a static thread-local lookup structure for
On 2/8/15 3:00 AM, Jacob Carlborg wrote:
On 2015-02-03 19:00, Russel Winder via Digitalmars-d wrote:
Learn lessons from SBT vs. SCons/Gant/Gradle: SBT is a Scala build
system using Scala programs as input.
Some Scala folk got religious about Scala being the only right language
for Scala
Thanks, my problem has been solved:)
---
import std.stdio;
import core.stdc.wchar_;
extern(C) int setlocale(int, char*);
static this()
{
fwide(core.stdc.stdio.stdout, 1);
setlocale(0, cast(char*)china);
}
int main(string[] args)
{
string s1 =
https://issues.dlang.org/show_bug.cgi?id=14147
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Depends on|2789|
--
https://issues.dlang.org/show_bug.cgi?id=14139
--- Comment #5 from Vladimir Panteleev thecybersha...@gmail.com ---
The VS solution included with DMD has a Release target, any reason you're not
using that?
--
Hi, it's a bit unwieldy to write/read this:
result = src[base .. base+size];
instead of:
result = src[base, size];
Maybe such syntax would be a welcome addition to D? I don't see
it conflicting with the existing grammar, and only the 2
slicing-operators need further extending to support it.
On Sunday, 8 February 2015 at 15:20:17 UTC, karl wrote:
Hi, it's a bit unwieldy to write/read this:
result = src[base .. base+size];
instead of:
result = src[base, size];
Maybe such syntax would be a welcome addition to D? I don't see
it conflicting with the existing grammar, and only the 2
We still have quite a few features which are listed as
to-be-deprecated, but without any dates listed:
http://dlang.org/deprecate.html
So, what's the status of these?
On Sun, 2015-02-08 at 12:00 +0100, Jacob Carlborg via Digitalmars-d wrote:
[…]
It's kind of the same in the D community. Before Dub existed I
started to work on both a package manager (Orbit) and a build tool
(never officially announced). I used Ruby as the description format
for package
https://issues.dlang.org/show_bug.cgi?id=2789
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Blocks||14147
--
https://issues.dlang.org/show_bug.cgi?id=14147
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Hardware|x86_64 |All
Depends on|
On Sunday, 8 February 2015 at 15:20:17 UTC, karl wrote:
Hi, it's a bit unwieldy to write/read this:
result = src[base .. base+size];
instead of:
result = src[base, size];
If you don't want to write base twice, you can write:
result = src[base..$][0..size];
On Sunday, 8 February 2015 at 15:20:17 UTC, karl wrote:
Hi, it's a bit unwieldy to write/read this:
result = src[base .. base+size];
instead of:
result = src[base, size];
Maybe such syntax would be a welcome addition to D? I don't see
it conflicting with the existing grammar, and only the 2
https://issues.dlang.org/show_bug.cgi?id=14148
Issue ID: 14148
Summary: .dup of associative array is not mutable
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority:
https://issues.dlang.org/show_bug.cgi?id=14149
Issue ID: 14149
Summary: Bad std.algorithm error messages
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: diagnostic
Severity:
https://issues.dlang.org/show_bug.cgi?id=14147
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords||ice, pull
--- Comment #3
Let me hear what comes out. ;)
https://issues.dlang.org/show_bug.cgi?id=2789
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Blocks||14147
--
https://issues.dlang.org/show_bug.cgi?id=14147
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Depends on||2789
--
https://issues.dlang.org/show_bug.cgi?id=2789
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Blocks|14147 |
--- Comment #11 from Kenji
On 2015-02-08 at 14:59, Russel Winder via Digitalmars-d wrote:
Well clearly it should be rejected, you have to s/Ruby/Python/ ;-)
LOL
As far as I can tell Rake remain the de facto standard tool
in the Ruby community and absolutely nowhere else.
That's by design. A rake gathers hay towards
On Saturday, 7 February 2015 at 06:30:32 UTC, tcak wrote:
I have two char arrays at the size of 16KB. I will copy a part
of data between them again and again.
arrayA[0 .. dataLen] = arrayB[0 .. dataLen];
Does the compiler generate code that uses SIMD operations
(128-bits memory copy)
On Saturday, 7 February 2015 at 06:08:39 UTC, ketmar wrote:
On Sat, 07 Feb 2015 04:30:07 +, Safety0ff wrote:
False pointers, current GC is not precise.
not only that. constantly allocating big chunks of memory will
inevitably
lead to OOM due to current GC design. you can check it with
1 - 100 of 151 matches
Mail list logo
