On Fri, Aug 21, 2015 at 07:17:03PM -0700, Walter Bright via Digitalmars-d wrote:
On 8/19/2015 10:25 AM, deadalnix wrote:
Replicating a scalar SSA like LLVM does not make a lot of sense.
What would make a lot of sense would be to start work on an
experimental SIMD SSA implemented in D that
On 08/22/2015 02:04 AM, deadalnix wrote:
On Thursday, 20 August 2015 at 20:39:01 UTC, Timon Gehr wrote:
On 08/20/2015 10:26 PM, David Nadlinger wrote:
On Thursday, 20 August 2015 at 16:45:18 UTC, Márcio Martins wrote:
Having 2 empty strings evaluate differently is very unintuitive and
On 8/22/2015 5:20 AM, Ilya Yaroshenko wrote:
Hi All!
I am going to implement associative arrays with manual memory management
based on amazing std.experimental.allocator by Andrei
http://wiki.dlang.org/Review/std.experimental.allocator
I will be happy to receive any advices about algorithms,
https://issues.dlang.org/show_bug.cgi?id=9785
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
CC|
On Saturday, 22 August 2015 at 02:12:41 UTC, BBasile wrote:
On Friday, 21 August 2015 at 20:09:22 UTC, Laeeth Isharc wrote:
I have four arrays of ints, each array representing a kind of
event associated with that int (they all map to the same
space). Each array might have the same number
On Saturday, 22 August 2015 at 02:17:04 UTC, Walter Bright wrote:
On 8/19/2015 10:25 AM, deadalnix wrote:
Replicating a scalar SSA like LLVM does not make a lot of
sense. What would
make a lot of sense would be to start work on an experimental
SIMD SSA
implemented in D that could leverage
Am Thu, 20 Aug 2015 22:21:30 -0700
schrieb H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com:
On Fri, Aug 21, 2015 at 05:15:00AM +, deadalnix via Digitalmars-d
wrote:
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
This function:
Am Fri, 21 Aug 2015 07:24:58 +
schrieb Benjamin Thaut c...@benjamin-thaut.de:
I don't think this is a good idea. That's just abusing a already
existing keyword. Export basically means Make this function or
class visible across shared library boundaries.
+1. I think we should be very
On 8/21/2015 12:24 AM, Benjamin Thaut wrote:
Export basically means Make this function or class visible across
shared library boundaries. I don't see how this connects to the object factory.
Object.factory() only has a point when it is used to instantiate classes in a
DLL/so. It fits in
On Thursday, 20 August 2015 at 15:57:47 UTC, John Colvin wrote:
On Thursday, 20 August 2015 at 15:25:57 UTC, Chris wrote:
Is there a way to flush a thread's message box other than
aborting the thread? MailBox is private:
Am Thu, 20 Aug 2015 23:16:10 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/20/2015 11:00 PM, Mike wrote:
Ideally it would be nice to only pull in those ModuleInfo instances
that are actually needed in the program, and by association, only
pull in those TypeInfo instances
https://issues.dlang.org/show_bug.cgi?id=10378
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords||pull
--- Comment #15 from
On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
Disabling TypeInfo forces one to compromise on slicing,
postblit
Why slicing and postblit would need typeinfo?
See below for the source code. Some obvious, some not.
* dynamic
On 21 August 2015 at 13:03, Mike via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
Disabling TypeInfo forces one to compromise on slicing, postblit
Why slicing and postblit
On 8/21/15 7:03 AM, Mike wrote:
On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
Disabling TypeInfo forces one to compromise on slicing, postblit
Why slicing and postblit would need typeinfo?
See below for the source code.
https://issues.dlang.org/show_bug.cgi?id=14758
Johannes Pfau johannesp...@gmail.com changed:
What|Removed |Added
CC||johannesp...@gmail.com
coming from a computer graphics and image processing background
i'd love to have a standard way to deal with matrices.
But matrices come in a lot of different flavors, which need
different implementations.
- computer graphics applications need mostly 1d-4d vectors and
matrices.
On 21-Aug-2015 13:44, Walter Bright wrote:
On 8/21/2015 12:24 AM, Benjamin Thaut wrote:
Export basically means Make this function or class visible across
shared library boundaries. I don't see how this connects to the
object factory.
Object.factory() only has a point when it is used to
On Thursday, 20 August 2015 at 19:41:44 UTC, Jonathan M Davis
wrote:
On Thursday, 20 August 2015 at 17:50:11 UTC, Steven
Schveighoffer wrote:
if(arr != null)
Definitely don't do that. IMHO, == null and != null should
be illegal. If you really want to check for null, then you need
to use is
On 8/21/15 7:22 AM, Iain Buclaw via Digitalmars-d wrote:
Where removing RTTI disables D feature's in a compromising way, I'd
start by questioning the why.
Eg: Why does array literals need RTTI? Looking at _d_arrayliteralTX
implementation, it only does the following with the given TypeInfo
On Friday, 21 August 2015 at 11:31:16 UTC, dominik wrote:
- computer graphics applications need mostly 1d-4d vectors and
matrices.
vec2, vec3, vec4, mat2, mat3, mat4 was what i ment obviously
On Friday, 21 August 2015 at 00:29:35 UTC, TheHamster wrote:
Parameter paths, a thousand words summed up:
[...]
Essentially it could reduce overhead of writing common sets of
overloaded functions.
unfortunately, with std.traits a template can be shorter and it
will cover more type (all
Yes, Go has sacrificed some compute performance in favour of
latency and convenience. They have also released GC improvement
plans for 1.6:
https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6ofZXX3yPziAf0V27A64Mo/edit
It is rather obvious that a building a good concurrent GC is a
On 8/20/15 11:15 PM, Jonathan M Davis wrote:
On Thursday, 20 August 2015 at 20:43:39 UTC, Steven Schveighoffer wrote:
This makes me think you misunderstand what I am doing.
If you care about whether an array is empty, you check whether its
length is 0 or you call empty (which checks whether
On Thursday, 20 August 2015 at 21:16:40 UTC, Walter Bright wrote:
On 8/19/2015 3:09 AM, Chris wrote:
#3 Here we go again... I wonder what's the problem with this.
I still think it's
a very handy shorthand for cumbersome `x = x + 1` or even `x
+= 1`. And no, it's
not confusing, because it is
On 08/21/2015 12:50 PM, Steven Schveighoffer wrote:
So checking whether the array is null (i.e. empty) *is* what I'm doing,
Nah, you're checking whether it /equals/ null. :-)
On 8/21/15 6:59 AM, Johannes Pfau wrote:
Am Thu, 20 Aug 2015 23:16:10 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/20/2015 11:00 PM, Mike wrote:
Ideally it would be nice to only pull in those ModuleInfo instances
that are actually needed in the program, and by association,
Am Fri, 21 Aug 2015 11:03:00 +
schrieb Mike n...@none.com:
On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
Disabling TypeInfo forces one to compromise on slicing,
postblit
Why slicing and postblit would need
https://issues.dlang.org/show_bug.cgi?id=14946
--- Comment #1 from Steven Schveighoffer schvei...@yahoo.com ---
https://github.com/D-Programming-Language/druntime/pull/1353
--
https://issues.dlang.org/show_bug.cgi?id=14758
--- Comment #13 from Mike slavo5...@yahoo.com ---
(In reply to Martin Nowak from comment #10)
I don't think you can properly use D on a small SoC with TypeInfo or
ModuleInfo.
Yes, it is seldom needed, but the current toolchain implementation is
Currently, -cov requires you to run the coverage-instrumented program in
the directory you compiled, so that it can find the source. Is there a
way to tell the instrumented program where the source is if you run it
in another directory? Alternatively, is there a way to specify the
output
On 8/21/15 7:03 AM, Mike wrote:
On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
Disabling TypeInfo forces one to compromise on slicing, postblit
Why slicing and postblit would need typeinfo?
See below for the source code.
https://issues.dlang.org/show_bug.cgi?id=3806
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.dlang.org/show_bug.cgi?id=14758
--- Comment #12 from Sobirari Muhomori dfj1es...@sneakemail.com ---
Downcasts can be done the COM way:
void* TypeId(T)=TypeId;
final T toType(T)()
{
cast(T)toType(TypeId!T); //reinterpret_cast
}
override void* toType(void* typeId)
{
On Friday, 21 August 2015 at 10:50:40 UTC, Steven Schveighoffer
wrote:
On 8/20/15 11:15 PM, Jonathan M Davis wrote:
On Thursday, 20 August 2015 at 20:43:39 UTC, Steven
Schveighoffer wrote:
This makes me think you misunderstand what I am doing.
If you care about whether an array is empty, you
On Thursday, 20 August 2015 at 15:31:13 UTC, tony288 wrote:
So I wrong some code. But it seems the time to process a shared
struct shared long is always the same. Regardless of adding
paddings.
Should it be different?
On Friday, 21 August 2015 at 13:54:04 UTC, Vladimir Panteleev
wrote:
Also, at least spell my name right please.
Sorry.
- Jonathan M Davis
On Friday, 21 August 2015 at 09:14:16 UTC, Kagamin wrote:
On Thursday, 20 August 2015 at 20:26:09 UTC, David Nadlinger
wrote:
It's even worse: http://dpaste.dzfl.pl/ba3376feca8e
The arrays are equal, but their Boolean value is not.
I don't get how Andrei can reconcile this with his D avoids
On 8/21/15 10:12 AM, Jonathan M Davis wrote:
I know full-well that that's what you're doing, but that's not what your
average programmer is going to expect. Anyone not intimately familiar
with the ins and outs of D's arrays - or even a D programmer who's not
paying really close attention - is
https://issues.dlang.org/show_bug.cgi?id=14943
Ivan Kazmenko ga...@mail.ru changed:
What|Removed |Added
CC||ga...@mail.ru
--
On Friday, 21 August 2015 at 12:41:17 UTC, Steven Schveighoffer
wrote:
I have no idea. It probably should be guaranteed, because what
is the point of having an always inlined function that
generates it's own code?
If it is guaranteed, almost makes me want to abuse it for this:
pragma(inline,
On 8/21/15 7:57 AM, Dicebot wrote:
On Friday, 21 August 2015 at 11:48:12 UTC, Steven Schveighoffer wrote:
Sure:
pragma(inline, true) T[] _d_arrayliteral(T)(size_t length)
-Steve
Btw, are `pragma(inline, true)` function actually guaranteed to not have
own code gen? :)
I have no idea. It
https://issues.dlang.org/show_bug.cgi?id=3806
Mike slavo5...@yahoo.com changed:
What|Removed |Added
CC||slavo5...@yahoo.com
--- Comment #2
On 21 August 2015 at 14:43, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Friday, 21 August 2015 at 12:41:17 UTC, Steven Schveighoffer wrote:
I have no idea. It probably should be guaranteed, because what is the
point of having an always inlined function that generates it's
On 2015-08-21 12:44, Walter Bright wrote:
Object.factory() only has a point when it is used to instantiate classes
in a DLL/so. It fits in nicely with export.
It's useful for deserialization as well.
--
/Jacob Carlborg
On 2015-08-21 10:52, Benjamin Thaut wrote:
Yes, the usual problem was that it only works with default constructors.
Also it doesn't work with nested classes e.g.
class Outer
{
class Inner
{
}
}
I don't know if that is fixed now.
It sounds like both of these could be fixed. BTW, in
On 2015-08-21 05:52:40 +, Lars T. Kyllingstad said:
Recently, I've played around with the idea of making a pure D
implementation of Scalable Protocols, which was created by Martin
Sustrik, one of the original ZMQ authors. He invented SP and the
reference implementation, nanomsg
How expensive putting a flag for the compiler?
--exportall, -ea
to export all, otherwise, only the classes with export keyword
are to be exported.
On 08/21/2015 01:43 AM, Walter Bright wrote:
I'm still amazed by how even modern C++ code bases embed the trickiest,
most bizarre uses of the preprocessor and then build their entire code
structure around it.
I probably haven't seen all the stuff you have, but I find that's the
only way to
On Friday, 21 August 2015 at 11:43:11 UTC, Steven Schveighoffer
wrote:
On 8/21/15 7:34 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Thursday, 20 August 2015 at 19:41:44 UTC, Jonathan M Davis
wrote:
On Thursday, 20 August 2015 at 17:50:11 UTC, Steven
Schveighoffer wrote:
if(arr
On Friday, 21 August 2015 at 12:59:09 UTC, John Colvin wrote:
On Friday, 21 August 2015 at 10:43:22 UTC, Chris wrote:
On Thursday, 20 August 2015 at 15:57:47 UTC, John Colvin wrote:
On Thursday, 20 August 2015 at 15:25:57 UTC, Chris wrote:
Is there a way to flush a thread's message box other
On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the
program. To make it work, though, every class in the program
has to have a TypeInfo generated for it.
On Friday, 21 August 2015 at 10:43:22 UTC, Chris wrote:
On Thursday, 20 August 2015 at 15:57:47 UTC, John Colvin wrote:
On Thursday, 20 August 2015 at 15:25:57 UTC, Chris wrote:
Is there a way to flush a thread's message box other than
aborting the thread? MailBox is private:
On 21 August 2015 at 13:57, Dicebot via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Friday, 21 August 2015 at 11:48:12 UTC, Steven Schveighoffer wrote:
Sure:
pragma(inline, true) T[] _d_arrayliteral(T)(size_t length)
-Steve
Btw, are `pragma(inline, true)` function actually
On Friday, 21 August 2015 at 13:11:14 UTC, Iain Buclaw wrote:
If it is guaranteed, almost makes me want to abuse it for this:
pragma(inline, true)
string foo()
{
if (!__ctfe)
assert(false);
// ...
}
(for compilers other than LDC)
That enforces that foo() is always folded at
On Friday, 21 August 2015 at 13:18:17 UTC, Jacob Carlborg wrote:
On 2015-08-21 12:44, Walter Bright wrote:
Object.factory() only has a point when it is used to
instantiate classes
in a DLL/so. It fits in nicely with export.
It's useful for deserialization as well.
Btw we use it for
On 8/21/15 1:06 AM, Walter Bright wrote:
This function:
http://dlang.org/phobos/object.html#.Object.factory
enables a program to instantiate any class defined in the program. To
make it work, though, every class in the program has to have a TypeInfo
generated for it. This leads to bloat:
On 8/20/15 9:53 PM, Timon Gehr wrote:
On 08/21/2015 03:51 AM, Timon Gehr wrote:
Even if an import is unused, if there is at least one lookup of some
identifier from any different module, it will have to be analyzed.
(But not /transitively/. I think this is where the gains of lazy imports
On Thursday, 20 August 2015 at 17:32:24 UTC, Jonathan M Davis
wrote:
On Thursday, 20 August 2015 at 17:01:07 UTC, anonymous wrote:
A compiler change disallowing such use of arrays was done and
then reverted. See
https://issues.dlang.org/show_bug.cgi?id=4733. I haven't
followed things closely
On Friday, 21 August 2015 at 02:02:57 UTC, rsw0x wrote:
On Friday, 21 August 2015 at 01:20:27 UTC, jmh530 wrote:
On Friday, 21 August 2015 at 00:00:09 UTC, H. S. Teoh wrote:
The gdc version, by contrast, inlines *everything*,
This could be why I've observed performance differentials in
dmd
Is there a good posting somewhere that summarizes the current best
practices for making const-correct (ie works for all of
mutable/const/immutable) structs?
On Friday, 21 August 2015 at 12:45:52 UTC, Kagamin wrote:
On Thursday, 20 August 2015 at 15:31:13 UTC, tony288 wrote:
So I wrong some code. But it seems the time to process a
shared struct shared long is always the same. Regardless of
adding paddings.
Should it be different?
Hi
all
On Friday, 21 August 2015 at 14:34:49 UTC, Steven Schveighoffer
wrote:
On 8/21/15 10:12 AM, Jonathan M Davis wrote:
I know full-well that that's what you're doing, but that's not
what your
average programmer is going to expect. Anyone not intimately
familiar
with the ins and outs of D's
On Friday, 21 August 2015 at 13:54:04 UTC, Vladimir Panteleev
wrote:
It broke a crapton of my code.
… in a way for which a fix is trivial to automate, even without a
full-fledged parser.
– David
On 8/18/15 1:21 PM, Sönke Ludwig wrote:
Am 18.08.2015 um 00:37 schrieb Andrei Alexandrescu:
On 8/17/15 2:56 PM, Sönke Ludwig wrote:
- The enum is useful to be able to identify the types outside of the D
code itself. For example when serializing the data to disk, or when
communicating with C
https://issues.dlang.org/show_bug.cgi?id=14946
Issue ID: 14946
Summary: druntime coverage tests fail intermittently
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: major
On Friday, 21 August 2015 at 09:21:48 UTC, John Colvin wrote:
On Friday, 21 August 2015 at 00:29:35 UTC, TheHamster wrote:
Parameter paths, a thousand words summed up:
void foo(p1, p2|p3|p4, p5|p6, |*p7|p8){ ... }
[...]
Could you give an example of where this enables something
really new
https://issues.dlang.org/show_bug.cgi?id=14944
Jonathan M Davis issues.dl...@jmdavisprog.com changed:
What|Removed |Added
CC|
On 07/30/2015 02:40 PM, Jacob Carlborg wrote:
On 2015-07-30 06:41, Walter Bright wrote:
I agree with your goal of readability. And if someone wants to write
code that emphasizes it's JSON, they can write it as
std.data.json.parseStream. (It's not about saving typing, it's about
avoiding extra
On 08/21/2015 12:22 PM, Dicebot wrote:
On Friday, 21 August 2015 at 15:00:04 UTC, Nick Sabalausky wrote:
Is there a good posting somewhere that summarizes the current best
practices for making const-correct (ie works for all of
mutable/const/immutable) structs?
- mark methods const
- avoid
On Friday, 21 August 2015 at 01:29:12 UTC, H. S. Teoh wrote:
On Fri, Aug 21, 2015 at 01:20:25AM +, jmh530 via
Digitalmars-d wrote:
On Friday, 21 August 2015 at 00:00:09 UTC, H. S. Teoh wrote:
The gdc version, by contrast, inlines *everything*,
This could be why I've observed performance
On Fri, Aug 21, 2015 at 03:09:42PM +, Ivan Kazmenko via Digitalmars-d wrote:
On Friday, 21 August 2015 at 01:29:12 UTC, H. S. Teoh wrote:
On Fri, Aug 21, 2015 at 01:20:25AM +, jmh530 via Digitalmars-d wrote:
On Friday, 21 August 2015 at 00:00:09 UTC, H. S. Teoh wrote:
The gdc
I know inserting into the middle of arrays isn't the most
efficient thing to do, but I have my reasons... I could increase
the length by 1 and then shuffle all the values back one at a
time... but I assume it'd be better to rewrite the back half as a
single chunk?
I don't really know how to
On Friday, 21 August 2015 at 15:00:04 UTC, Nick Sabalausky wrote:
Is there a good posting somewhere that summarizes the current
best practices for making const-correct (ie works for all of
mutable/const/immutable) structs?
Prepare for pain.
On 08/14/2015 04:33 PM, Walter Bright wrote:
That is, the ECMA 404 spec. There seems to be more than one JSON spec.
www.ecma-international.org/.../files/.../ECMA-404.pdf
Amusingly, that ECMA-404 link results in an actual HTTP 404.
On Friday, 21 August 2015 at 15:58:22 UTC, Nick Sabalausky wrote:
It also fucks up UFCS, and I'm a huge fan of UFCS.
Are you saying that import json : parseJSON = parse;
foo.parseJSON.bar; does not work?
– David
On 08/18/2015 09:18 AM, Andrei Alexandrescu wrote:
On 8/18/15 2:31 AM, Jacob Carlborg wrote:
I don't think this is excessive. We should strive to have small modules.
We already have/had problems with std.algorithm and std.datetime, let's
not repeat those mistakes. A module with 2000 lines is
On Friday, 21 August 2015 at 16:25:40 UTC, Nick Sabalausky wrote:
Module boundaries should be determined by organizational
grouping, not by size.
By organizational grouping as well as encapsulation concerns.
Modules are the smallest units of encapsulation in D,
visibility-wise.
— David
On Friday, 21 August 2015 at 14:35:53 UTC, Chris wrote:
On Friday, 21 August 2015 at 12:59:09 UTC, John Colvin wrote:
On Friday, 21 August 2015 at 10:43:22 UTC, Chris wrote:
On Thursday, 20 August 2015 at 15:57:47 UTC, John Colvin
wrote:
On Thursday, 20 August 2015 at 15:25:57 UTC, Chris
On 08/15/2015 01:03 AM, Walter Bright wrote:
On 8/14/2015 9:58 PM, suliman wrote:
On Friday, 14 August 2015 at 20:44:59 UTC, Walter Bright wrote:
Config files will work fine with json format.
Walter, and what I should to do for commenting stringin config for
test purpose?
How it's can be done
On Friday, 21 August 2015 at 15:00:04 UTC, Nick Sabalausky wrote:
Is there a good posting somewhere that summarizes the current
best practices for making const-correct (ie works for all of
mutable/const/immutable) structs?
- mark methods const
- avoid reference type fields
;)
On 8/21/15 12:25 PM, Nick Sabalausky wrote:
On 08/18/2015 09:18 AM, Andrei Alexandrescu wrote:
On 8/18/15 2:31 AM, Jacob Carlborg wrote:
I don't think this is excessive. We should strive to have small modules.
We already have/had problems with std.algorithm and std.datetime, let's
not repeat
On Friday, 21 August 2015 at 13:54:04 UTC, Vladimir Panteleev
wrote:
On Thursday, 20 August 2015 at 17:32:24 UTC, Jonathan M Davis
wrote:
On Thursday, 20 August 2015 at 17:01:07 UTC, anonymous wrote:
A compiler change disallowing such use of arrays was done and
then reverted. See
On 8/19/15 4:55 AM, Sönke Ludwig wrote:
Am 19.08.2015 um 03:58 schrieb Andrei Alexandrescu:
On 8/18/15 1:24 PM, Jacob Carlborg wrote:
On 2015-08-18 17:18, Andrei Alexandrescu wrote:
Me neither if internal. I do see a problem if it's public. -- Andrei
If it's public and those 20 lines are
On 8/21/15 12:31 PM, Nick Sabalausky wrote:
On 08/21/2015 12:22 PM, Dicebot wrote:
On Friday, 21 August 2015 at 15:00:04 UTC, Nick Sabalausky wrote:
Is there a good posting somewhere that summarizes the current best
practices for making const-correct (ie works for all of
On 8/21/15 3:22 PM, Andrei Alexandrescu wrote:
On 8/21/15 2:50 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Aug 21, 2015 at 02:21:06PM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:
On 8/21/15 2:03 PM, tired_eyes wrote:
On Friday, 21 August 2015 at 17:30:43 UTC, Andrei Alexandrescu
On 8/21/2015 6:29 AM, Dicebot wrote:
On Friday, 21 August 2015 at 13:18:17 UTC, Jacob Carlborg wrote:
On 2015-08-21 12:44, Walter Bright wrote:
Object.factory() only has a point when it is used to instantiate classes
in a DLL/so. It fits in nicely with export.
It's useful for
On Friday, 21 August 2015 at 20:47:36 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 21 August 2015 at 20:41:58 UTC, deadalnix wrote:
On Friday, 21 August 2015 at 10:11:52 UTC, Ola Fosheim Grøstad
wrote:
Replicating a scalar SSA like LLVM does not make a lot of
sense. What would make a lot of
Chris wend...@tcd.ie wrote:
[...]
As if most people were too stpid to grasp the concept that `x++` is
the same as `x += 1` (which is intellectually as 'challenging' as `x++`, by
the way).
Because it's not.
++x is the same as x+=1, not x++.
Tobi
Hello Majestio,
MvDda We have already moved to http://dlanguage.ru
Cool, but could you please make your captcha accessible without
vision?
Thanks!
--
With best regards from Ukraine,
Andre
Skype: Francophile
Twitter: @m_elensule; Facebook: menelion
My blog: http://menelion.oire.org/
I have four arrays of ints, each array representing a kind of
event associated with that int (they all map to the same space).
Each array might have the same number multiple times and each
array will be of different length.
So I would like to plot the int line on x axis and show number of
On 8/21/2015 6:29 AM, Andrei Alexandrescu wrote:
Knee-jerk reaction: sensible and meaningful, but we need to make a good case for
breaking code. -- Andrei
The case is:
https://issues.dlang.org/show_bug.cgi?id=14758
i.e. D being unusable for embedded systems because of bloat.
And it always
On Friday, 21 August 2015 at 20:01:21 UTC, Vladimir Panteleev
wrote:
This warning almost doesn't break any code!
It indeed doesn't break almost any code. Yours is quite the
outlier.
— David
On Fri, Aug 21, 2015 at 03:22:25PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
On 8/21/15 2:50 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Aug 21, 2015 at 02:21:06PM -0400, Andrei Alexandrescu via
Digitalmars-d wrote:
On 8/21/15 2:03 PM, tired_eyes wrote:
On Friday, 21 August
On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
Disabling TypeInfo forces one to compromise on slicing,
postblit
Why slicing and postblit would need typeinfo?
Because the runtime implementation is broken and rely on it
https://issues.dlang.org/show_bug.cgi?id=7648
--- Comment #13 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos
https://github.com/D-Programming-Language/phobos/commit/3a025da7c69f66b28c0eed53aa9ea1ccced01623
Cleanup for Issue
Here's a direct link to the posting as I'm sure nobody wants to
upvote it.
https://news.ycombinator.com/item?id=10095332
On Friday, 21 August 2015 at 10:11:52 UTC, Ola Fosheim Grøstad
wrote:
Replicating a scalar SSA like LLVM does not make a lot of
sense. What would make a lot of sense would be to start work
WAT ?
When simplifying over scalars you make a trade off. By having a
simplifier that is optimized
On 08/21/2015 10:01 PM, Vladimir Panteleev wrote:
I just write code this way, because I find the empty/null distinction
obvious and useful. Shocking, I know.
One of the main reasons this might be considered shocking is because
DMD does not cleanly make this distinction. [] is null.
On Friday, 21 August 2015 at 20:09:22 UTC, Laeeth Isharc wrote:
I have four arrays of ints, each array representing a kind of
event associated with that int (they all map to the same
space). Each array might have the same number multiple times
and each array will be of different length.
So
1 - 100 of 191 matches
Mail list logo
