Am Mon, 18 Jan 2016 05:59:15 +
schrieb tcak <1ltkrs+3wyh1ow7kz...@sharklasers.com>:
> I, due to a need, will start implementation of distributed memory
> system.
>
> Idea is that:
>
> Let's say you have allocated 1 GiB space in memory. This memory
> is blocked into 4 KiB.
>
> After some r
On 18 January 2016 at 17:54, tsbockman via Digitalmars-d-announce <
digitalmars-d-annou...@puremagic.com> wrote:
> On Monday, 18 January 2016 at 15:47:07 UTC, Manu wrote:
>
>> Love your work guys! Thanks for keeping at it.
>>
>> One question though, what's the plan for moving to DMD latest? Both
>
On Wednesday, 20 January 2016 at 07:58:20 UTC, Marco Leise wrote:
Am Mon, 18 Jan 2016 05:59:15 +
schrieb tcak <1ltkrs+3wyh1ow7kz...@sharklasers.com>:
I, due to a need, will start implementation of distributed
memory system.
Idea is that:
Let's say you have allocated 1 GiB space in memory
On 1/19/2016 11:51 PM, Manu via Digitalmars-d wrote:
You admit
This is where a debate about ideas leaves the rails. This is not a court, nobody
has alleged a crime. I want to bring it back on the track.
I want to help you be successful with interfacing D with C++. You have posted
several bu
On Wednesday, 20 January 2016 at 07:51:27 UTC, Manu wrote:
1. C++ has namespaces. They went and invented a whole 'nother
thing called modules. Evidently not even they think that
modules and namespaces are the same thing.
You admit that modules supersede namespaces. We have modules,
we use
mo
Greetings
I am struggling with strange memory corruption issues with
dmd-2.069.2 release.
The issue shows up only when I load a shared library created from
D code from C and call some D functions from the C side. But
since the program control is completely with the D code, and data
structur
Am Wed, 20 Jan 2016 09:12:57 +
schrieb Bottled Gin :
> Greetings
>
> I am struggling with strange memory corruption issues with
> dmd-2.069.2 release.
>
Could be GC scanning issues. Can you try disabling the garbage collector
and see if it still crashes?
On Wednesday, 20 January 2016 at 08:38:35 UTC, Walter Bright
wrote:
On 1/19/2016 11:51 PM, Manu via Digitalmars-d wrote:
You admit
This is where a debate about ideas leaves the rails. This is
not a court, nobody has alleged a crime. I want to bring it
back on the track.
I want to help you
On Wednesday, 20 January 2016 at 11:06:53 UTC, Daniel Kozak wrote:
On Wednesday, 20 January 2016 at 09:12:57 UTC, Bottled Gin
wrote:
Greetings
I am struggling with strange memory corruption issues with
dmd-2.069.2 release.
[...]
As a workaround you can mark Hash class as a shared
final sh
On Wednesday, 20 January 2016 at 09:12:57 UTC, Bottled Gin wrote:
Greetings
I am struggling with strange memory corruption issues with
dmd-2.069.2 release.
[...]
As a workaround you can mark Hash class as a shared
final shared class Hash
On Wednesday, 20 January 2016 at 11:08:46 UTC, Daniel Kozak wrote:
On Wednesday, 20 January 2016 at 11:06:53 UTC, Daniel Kozak
wrote:
On Wednesday, 20 January 2016 at 09:12:57 UTC, Bottled Gin
wrote:
Greetings
I am struggling with strange memory corruption issues with
dmd-2.069.2 release.
[
On Wednesday, 20 January 2016 at 09:12:57 UTC, Bottled Gin wrote:
Greetings
I am struggling with strange memory corruption issues with
dmd-2.069.2 release.
...
./main
Start frop from C
0 -> @�+
The last line is the content of an array which is actually
filled with only dashe
On Wednesday, 20 January 2016 at 11:49:29 UTC, Daniel Kozak wrote:
On Wednesday, 20 January 2016 at 09:12:57 UTC, Bottled Gin
wrote:
Greetings
I am struggling with strange memory corruption issues with
dmd-2.069.2 release.
...
./main
Start frop from C
0 -> @�+
The last line
On 20 January 2016 at 18:38, Walter Bright via Digitalmars-d
wrote:
> On 1/19/2016 11:51 PM, Manu via Digitalmars-d wrote:
>>
>> You admit
>
>
> This is where a debate about ideas leaves the rails. This is not a court,
> nobody has alleged a crime. I want to bring it back on the track.
>
> I want
On 20 January 2016 at 18:37, deadalnix via Digitalmars-d
wrote:
> On Wednesday, 20 January 2016 at 07:51:27 UTC, Manu wrote:
>>>
>>> 1. C++ has namespaces. They went and invented a whole 'nother thing
>>> called modules. Evidently not even they think that modules and namespaces
>>> are the same th
On Wednesday, 20 January 2016 at 12:47:44 UTC, Manu wrote:
No, I really *really* didn't.
It seems I have a habit of being completely misunderstood.
Just for your information, I understand what you mean Manu :)
(and agree with you).
I guess it might be helpful if you could spell out (in pseu
Another workaround is to use GC.addRoot for dynamic allocated
data in Dynamic.proc
void proc () {
import core.memory: GC;
dash.length = 32;
GC.addRoot(cast(void*)dash.ptr);
dash[] = '-';
}
And another one is hold pointer to data:
class Dynamic {
static char[] space;
stat
V Wed, 20 Jan 2016 13:58:46 +
Bottled Gin via Digitalmars-d napsáno:
> >> Another workaround is to use GC.addRoot for dynamic allocated
> >> data in Dynamic.proc
> >>
> >> void proc () {
> >> import core.memory: GC;
> >> dash.length = 32;
> >> GC.addRoot(cast(void*)dash.ptr);
> >
On 01/19/2016 08:08 PM, Ivan Kazmenko wrote:
On Tuesday, 19 January 2016 at 13:52:08 UTC, Andrei Alexandrescu wrote:
On 01/18/2016 09:21 PM, Ivan Kazmenko wrote:
Do you think sort and topN would be attackable if they used a
per-process-seeded RNG as per Xinok's idea? -- Andrei
Yes, but with a
On 01/20/2016 10:20 AM, Andrei Alexandrescu wrote:
[snip]
And btw I now understand better why medianOfMedians is not so fast in
practice. In fact my wishy-washy version at
https://github.com/andralex/phobos/commit/9e004c35b824aac108e0e615183065e73384e9f9
seems to be practically attractive for
On 01/19/2016 09:26 PM, Timon Gehr wrote:
On 01/20/2016 02:20 AM, Andrei Alexandrescu wrote:
I've seldom have code write itself so beautifully. Which, of course,
means it needs to be destroyed.
https://github.com/D-Programming-Language/phobos/pull/3938 -- Andrei
This is not an implementation o
On Wednesday, 20 January 2016 at 12:47:44 UTC, Manu wrote:
2. Multiple modules cannot have the same name in D.
I'm not sure what situation you're imagining where modules
would be created with the same names...?
How do you plan to map C++'s standard lib ? One giant hundred
of thousands of
On Wednesday, 20 January 2016 at 05:32:08 UTC, Walter Bright
wrote:
Actual code examples of the serious problems would be
appreciated. All the namespace code examples you posted were
bugs that have since been fixed, or were misunderstandings that
were explained.
IMO his description was alread
Kingsley is developing a D plugin for IntelliJ IDEA – which is a Good
Thing™.
However, as I have said before, I think CLion (a C++ IDE, where
IntelliJ IDEA is really a JVM languages IDE) would be a far better
place for D to be supported.
Given CLion is CMake based, CMake-D is important to getting
On 21/01/16 5:40 AM, Russel Winder via Digitalmars-d wrote:
Kingsley is developing a D plugin for IntelliJ IDEA – which is a Good
Thing™.
However, as I have said before, I think CLion (a C++ IDE, where
IntelliJ IDEA is really a JVM languages IDE) would be a far better
place for D to be supported
This is one of those cases in which we were pedantically right to not
add them, but their equivalents look like crap.
https://github.com/D-Programming-Language/phobos/pull/3942
Andrei
On Wednesday, 20 January 2016 at 16:38:19 UTC, Marc Schütz wrote:
// a.d
module a;
extern(C++, ns) {
void fooa();
void bar();
}
// b.d
module b;
extern(C++, ns) {
void foob();
}
void bar();
// main.d
import a, b;
void main() {
fooa(); // ok
foob(); // ok
bar()
Thanks Daniel
I have added the testcase to a more obscure testcase that I had
raised on Bugzilla earlier.
https://issues.dlang.org/show_bug.cgi?id=15513
I want to request developers to show some love.
Regards
- Puneet
On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
> This is one of those cases in which we were pedantically right to not
> add them, but their equivalents look like crap.
>
> https://github.com/D-Programming-Language/phobos/pull/3942
[...]
I don't like this.
Hi everyone,
After reading the thread "Distributed Memory implementation":
http://forum.dlang.org/post/oqcfifzolmolcvyup...@forum.dlang.org
And more precisely the suggestion of Dragos Carp on page 2:
http://forum.dlang.org/post/txgabyyoutitketlp...@forum.dlang.org
I looked at the joiner sou
On Tue, Jan 19, 2016 at 04:00:32PM -0800, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Jan 19, 2016 at 10:19:22PM +, tsbockman via Digitalmars-d wrote:
> > Could I persuade someone from the compiler team to take a look at
> > this bug report I filed?
> > https://issues.dlang.org/show_bug.c
On Wednesday, 20 January 2016 at 17:36:29 UTC, Maverick Chardet
wrote:
The most important issue that comes to my mind is that the
operations would not take constant time... A trivial
implementation would be in O(k) where k is the number of joined
ranges, and with some precomputation in O(k) tim
It took a while but I finally got around to adapting a Let's
Encrypt ACME client to my hosting system with automatic renewals
etc. Enjoy!
https://forum.dlang.org/
Adam, your turn!
Currently, std.range.primitives.ElementType has no sig constraints, so
it will pick up all sorts of things that aren't ranges. This is not so
nice, because ranges aren't the only thing that have elements, and it
would be nice if such a good name as ElementType could be reused for
other user-define
On 2016-01-19 20:59, Vladimir Panteleev wrote:
Yep, plus now that we use a narrow font :P
Made it narrower + hid it on very narrow viewports (incl. portrait iPhone).
Thanks. But now when the column is removed, it's not enough
margin/padding on the right side, for the "Last Post" column.
--
On Wednesday, 20 January 2016 at 17:36:29 UTC, Maverick Chardet
wrote:
Hi everyone,
After reading the thread "Distributed Memory implementation":
http://forum.dlang.org/post/oqcfifzolmolcvyup...@forum.dlang.org
And more precisely the suggestion of Dragos Carp on page 2:
http://forum.dlang.or
On Wednesday, 20 January 2016 at 17:25:56 UTC, JohnCK wrote:
On Wednesday, 20 January 2016 at 16:38:19 UTC, Marc Schütz
wrote:
I think the first error is correct:
bar(); // Error: b.bar at b.d(6) conflicts with
a.ns.bar at a.d(5)
Yes, I put this one in to show why the next lines a
On 01/20/2016 12:29 PM, H. S. Teoh via Digitalmars-d wrote:
On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
This is one of those cases in which we were pedantically right to not
add them, but their equivalents look like crap.
https://github.com/D-Programm
On Wed, Jan 20, 2016 at 02:30:10PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 01/20/2016 12:29 PM, H. S. Teoh via Digitalmars-d wrote:
> >On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu via
> >Digitalmars-d wrote:
> >>This is one of those cases in which we were pedanti
On 01/20/2016 06:29 PM, H. S. Teoh via Digitalmars-d wrote:
On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
This is one of those cases in which we were pedantically right to not
add them, but their equivalents look like crap.
https://github.com/D-Programm
So this is available for Java: http://java-performance.info/jmh/. The
framework uses attributes such as @Benchmark,
@BenchmarkMode(Mode.AverageTime), @OutputTimeUnit(TimeUnit.MICROSECONDS)
etc. to great effect. Far as I can imagine, runtime reflection is used.
We should do the same, just with
On Wednesday, 20 January 2016 at 17:36:29 UTC, Maverick Chardet
wrote:
The most important issue that comes to my mind is that the
operations would not take constant time... A trivial
implementation would be in O(k) where k is the number of joined
ranges, and with some precomputation in O(k) tim
On Wednesday, 20 January 2016 at 18:54:34 UTC, H. S. Teoh wrote:
Currently, std.range.primitives.ElementType has no sig
constraints, so it will pick up all sorts of things that aren't
ranges. This is not so nice, because ranges aren't the only
thing that have elements, and it would be nice if
On 1/20/2016 4:17 AM, Manu via Digitalmars-d wrote:
-- name.x.d
module name.x;
-- name.y.d
module name.y;
import name.x;
extern(C++, name) int x;
This won't work any more than:
import name.y;
struct name { }
woul
Yes, something like that would be nice. But as the website states
you need to use maven to build the project that uses that library.
I can only suspect, but I think they use maven to collect all
functions that use @Benchmark. And this leads to the problem the
unittest library proposal for phob
On Wednesday, 20 January 2016 at 17:16:00 UTC, Andrei
Alexandrescu wrote:
This is one of those cases in which we were pedantically right
to not add them, but their equivalents look like crap.
https://github.com/D-Programming-Language/phobos/pull/3942
As it seems related, let me share my perso
I am writing some code for a library, and an interesting situation comes
up. Let's say you have some code that can deal with wchar, dchar, or
char arrays. You template the code based on the code unit type, but the
input comes in as a file stream (which is bytes).
What I have been doing is this
On 01/20/2016 06:16 PM, Andrei Alexandrescu wrote:
This is one of those cases in which we were pedantically right to not
add them, but their equivalents look like crap.
https://github.com/D-Programming-Language/phobos/pull/3942
Andrei
One reason why dual notions usually both receive names is
On Wednesday, 20 January 2016 at 21:27:15 UTC, Steven
Schveighoffer wrote:
It would be cool if the compiler could "expand" a finitely
instantiable template (one with a finite number of ways it can
be instantiated) based on a runtime value, and do the switch
for me.
Can't you just write a wrap
On 01/20/2016 09:56 PM, Walter Bright wrote:
On 1/20/2016 4:17 AM, Manu via Digitalmars-d wrote:
-- name.x.d
module name.x;
-- name.y.d
module name.y;
import name.x;
extern(C++, name) int x;
This won't work ...
The
On 1/20/16 4:44 PM, David Nadlinger wrote:
On Wednesday, 20 January 2016 at 21:27:15 UTC, Steven Schveighoffer wrote:
It would be cool if the compiler could "expand" a finitely
instantiable template (one with a finite number of ways it can be
instantiated) based on a runtime value, and do the sw
On 1/20/2016 1:47 PM, Timon Gehr wrote:
On 01/20/2016 09:56 PM, Walter Bright wrote:
On 1/20/2016 4:17 AM, Manu via Digitalmars-d wrote:
-- name.x.d
module name.x;
-- name.y.d
module name.y;
import name.x;
extern(C++, name) int x;
On 1/20/2016 4:47 AM, Manu via Digitalmars-d wrote:
As a bonus, the project's C++ namespace 'libname' is already present
in the fully qualified name, it's the top level package! No point
repeating that as 'libname.feature.libname.symbol'.
You can always write a module that all it does is import
Thank you all for your comments! I'm not making a PR for now
because however I implement this, there will be complexity issues
that need to be discussed...
On Wednesday, 20 January 2016 at 20:23:08 UTC, Jonathan M Davis
wrote:
On Wednesday, 20 January 2016 at 17:36:29 UTC, Maverick Chardet
wr
On 1/20/2016 8:38 AM, Marc Schütz wrote:
IMO his description was already quite clear, but here you are:
What's missing is why this is a *serious* problem. All you've got to do is add a
qualifier.
On Wednesday, 20 January 2016 at 22:00:45 UTC, Steven
Schveighoffer wrote:
Imagine if you such a call returned something, and you simply
used it throughout the rest of your function. The compiler
could rewrite this as a template and compile all three versions
and branch to the appropriate one,
Dne 20.1.2016 v 23:01 Walter Bright via Digitalmars-d napsal(a):
> I understand his suggestion. I asked Manu to elaborate what the "serious
> problems" are. This code snippet doesn't work as it is not supposed to
> work, but still unknown is what the "serious problem" with it is - and I
> want to e
On 1/20/2016 3:12 PM, Martin Drašar via Digitalmars-d wrote:
The "serious" problem is
that the decision to have a namespace introduce a new scope needlessly
complicates writing D-like interfaces to C++ code, while catering for
one specific use-case that is considered niche.
Adding a qualifier h
I managed to create a compile-time random number generator.
Proof of concept, with some explanatory comments:
http://dpaste.dzfl.pl/668646ce6d71
Just thought this might be of interest to some of you here.
On 21 January 2016 at 06:56, Walter Bright via Digitalmars-d
wrote:
> On 1/20/2016 4:17 AM, Manu via Digitalmars-d wrote:
>>
>> -- name.x.d
>> module name.x;
>> -- name.y.d
>> module name.y;
>> import name.x;
>> extern(C++, name) int x;
>> --
On 21 January 2016 at 01:32, Simen Kjaeraas via Digitalmars-d
wrote:
> On Wednesday, 20 January 2016 at 12:47:44 UTC, Manu wrote:
>
> 2. Multiple modules cannot have the same name in D.
I'm not sure what situation you're imagining where modules would be
created wit
On 21 January 2016 at 08:01, Walter Bright via Digitalmars-d
wrote:
> On 1/20/2016 1:47 PM, Timon Gehr wrote:
>>
>> On 01/20/2016 09:56 PM, Walter Bright wrote:
>>>
>>> On 1/20/2016 4:17 AM, Manu via Digitalmars-d wrote:
-- name.x.d
module name.x;
-- name.y.
On Tuesday, 19 January 2016 at 21:40:01 UTC, Walter Bright wrote:
Please do not conflate not agreeing with my answers with not
responding.
I am not claiming that you weren't participating in the
discussion threads or something like that. But in all your
arguments you seem to presume that (bad
On Wednesday, 20 January 2016 at 20:56:49 UTC, Walter Bright
wrote:
On 1/20/2016 4:17 AM, Manu via Digitalmars-d wrote:
You claim this is a problem that must desperately be solved:
int x;
extern(C++, ns) int x;
The soluti
On Wednesday, 20 January 2016 at 22:13:09 UTC, Walter Bright
wrote:
You can always write a module that all it does is import a
bunch of other modules, with a bunch of aliases which can be
used to make those imports appear in another namespace:
module core.stdcpp.vector
extern (C+
On 21 January 2016 at 08:15, Walter Bright via Digitalmars-d
wrote:
> On 1/20/2016 8:38 AM, Marc Schütz wrote:
>>
>> IMO his description was already quite clear, but here you are:
>
>
> What's missing is why this is a *serious* problem. All you've got to do is
> add a qualifier.
It's 'serious' in
On Tuesday, 19 January 2016 at 21:46:07 UTC, Walter Bright wrote:
On 1/19/2016 12:35 PM, David Nadlinger wrote:
You'd run into all kinds of
weird issues, as Manu pointed out – many of which have
hopefully been fixed by
Walter in the meantime.
Please read the thread. I fixed them and posted h
On Wednesday, 20 January 2016 at 23:35:31 UTC, Manu wrote:
On 21 January 2016 at 01:32, Simen Kjaeraas via Digitalmars-d
wrote:
On Wednesday, 20 January 2016 at 12:47:44 UTC, Manu wrote:
2. Multiple modules cannot have the same name in D.
I'm not sure what situation you're imagining where
EMSI has a D version of rec.h from GNU recutils[1]. If somebody
creates a repository for this I can get these bindings into
Deimos pretty quickly.
[1]
https://www.gnu.org/software/recutils/manual/recutils.html#Purpose
On Wednesday, 20 January 2016 at 23:21:04 UTC, CTRNG wrote:
I managed to create a compile-time random number generator.
Proof of concept, with some explanatory comments:
http://dpaste.dzfl.pl/668646ce6d71
Just thought this might be of interest to some of you here.
That's clever (and devious
On Tuesday, 19 January 2016 at 22:14:42 UTC, Walter Bright wrote:
1. C++ has namespaces. They went and invented a whole 'nother
thing called modules. Evidently not even they think that
modules and namespaces are the same thing.
C++ modules (as per N4465, etc.) are a whole different story and
On Thursday, 21 January 2016 at 00:33:34 UTC, Brian Schott wrote:
If somebody creates a repository for this I can get these
bindings into Deimos pretty quickly.
IIRC only Walter, Andrei and Brad have the necessary permissions
to create new repositories.
— David
What would you all say to the following proposal (and should I
make a DIP?)
1. deprecate pragma(mangle)
2. deprecate extern(C++, ns)
3. deprecate @selector()
4. Introduce a better, more general extern() as follows:
extern ( [, ] )
Which would *only* influence mangling and calling convention
On Wednesday, 20 January 2016 at 23:21:49 UTC, Walter Bright
wrote:
On 1/20/2016 3:12 PM, Martin Drašar via Digitalmars-d wrote:
The "serious" problem is
that the decision to have a namespace introduce a new scope
needlessly
complicates writing D-like interfaces to C++ code, while
catering for
On Wednesday, 20 January 2016 at 23:21:04 UTC, CTRNG wrote:
I managed to create a compile-time random number generator.
Proof of concept, with some explanatory comments:
http://dpaste.dzfl.pl/668646ce6d71
Just thought this might be of interest to some of you here.
That's nearly as fun as us
On 01/20/2016 04:22 PM, Ivan Kazmenko wrote:
On Wednesday, 20 January 2016 at 17:16:00 UTC, Andrei Alexandrescu wrote:
This is one of those cases in which we were pedantically right to not
add them, but their equivalents look like crap.
https://github.com/D-Programming-Language/phobos/pull/3942
On 01/20/2016 12:36 PM, Maverick Chardet wrote:
Hi everyone,
After reading the thread "Distributed Memory implementation":
http://forum.dlang.org/post/oqcfifzolmolcvyup...@forum.dlang.org
And more precisely the suggestion of Dragos Carp on page 2:
http://forum.dlang.org/post/txgabyyoutitketlp..
I'm not sure what situation you're imagining where modules
would be created with the same names...?
How do you plan to map C++'s standard lib ? One giant hundred
of thousands of line C++ file ?
Surely it would map by file.
#include -> import stl.vector;
#include -> import stl.map;
#inclu
On 1/20/2016 3:53 PM, tsbockman wrote:
The thought of needing to do that for (potentially) every single symbol being
imported is depressing. What happened to DRY?
Since it is completely mechanical, it's an ideal candidate for writing a
metafunction to do it:
module stl--
privat
On 1/20/2016 4:51 PM, Anon wrote:
What would you all say to the following proposal (and should I make a DIP?)
DIPs are always welcome.
On 01/21/2016 01:32 AM, tsbockman wrote:
On Wednesday, 20 January 2016 at 23:21:04 UTC, CTRNG wrote:
I managed to create a compile-time random number generator.
Proof of concept, with some explanatory comments:
http://dpaste.dzfl.pl/668646ce6d71
Just thought this might be of interest to some o
On Thursday, 21 January 2016 at 01:11:19 UTC, Andrei Alexandrescu
wrote:
On 01/20/2016 04:22 PM, Ivan Kazmenko wrote:
1. The minimum or maximum element itself. I write it as
a.minPos.front. That's almost fine, but maybe there is a more
expressive way?
Sadly, no. I'm very willing to add an ov
On 01/20/2016 09:36 PM, Ivan Kazmenko wrote:
So, min(Range) + tuple expansion = problem.
OK, convinced. There's of course the option of (min|max)Element. -- Andrei
Seeing the recent extern(C++) threads, and much concern therein,
I'd like to propose DIP87: http://wiki.dlang.org/DIP87
Destroy to your heart's content.
On Thursday, 21 January 2016 at 01:37:12 UTC, Walter Bright wrote:
On 1/20/2016 4:51 PM, Anon wrote:
What would you all say to the following proposal (and should I
make a DIP?)
DIPs are always welcome.
Done.
http://forum.dlang.org/post/ldtluvnhuznvbebcb...@forum.dlang.org
On 21/01/16 5:21 PM, Anon wrote:
Seeing the recent extern(C++) threads, and much concern therein, I'd
like to propose DIP87: http://wiki.dlang.org/DIP87
Destroy to your heart's content.
It was great until I saw:
extern(auto, "myMoveTo:")
After all:
extern(C/C++/D/Objective-C[, string])
Is th
On Thursday, 21 January 2016 at 04:42:00 UTC, Rikki Cattermole
wrote:
On 21/01/16 5:21 PM, Anon wrote:
Seeing the recent extern(C++) threads, and much concern
therein, I'd
like to propose DIP87: http://wiki.dlang.org/DIP87
Destroy to your heart's content.
It was great until I saw:
extern(aut
On Wednesday, 20 January 2016 at 19:04:18 UTC, Jacob Carlborg
wrote:
On 2016-01-19 20:59, Vladimir Panteleev wrote:
Yep, plus now that we use a narrow font :P
Made it narrower + hid it on very narrow viewports (incl.
portrait iPhone).
Thanks. But now when the column is removed, it's not eno
On 21/01/16 6:46 PM, Anon wrote:
snip
I thought I did a good enough job of explaining that in the DIP so I
wouldn't have to here.
I was trying to explain some better semantics because how it is
currently with strings can be and is a bit ambiguous.
On Thursday, 21 January 2016 at 04:21:06 UTC, Anon wrote:
Seeing the recent extern(C++) threads, and much concern
therein, I'd like to propose DIP87: http://wiki.dlang.org/DIP87
Destroy to your heart's content.
This propose to change everything while not even providing
anything more than wha
On Thursday, 21 January 2016 at 01:49:27 UTC, Timon Gehr wrote:
It only works because compile-time introspection is ill-defined
though. I don't expect it to keep working indefinitely.
That aspect can easily be replaced by __LINE__ and __FILE__.
91 matches
Mail list logo
