On 22/09/14 23:04, tn wrote:
What is the recommended way of versioning bindings? If the binding of
the target library 1.2.3 is versioned as 1.2.3 and a bug is fixed in the
binding (no change in the target library), how should the new version of
the binding for target version 1.2.3 be versioned?
Am 23.09.2014 03:50, schrieb K.K.:
This inclusion into the DMD install, is just that DMD comes with
the dub.exe and .dll's (and ofcourse the linux mac equivalents)
in it's folders, correct?
Yes, that's it basically.
On Tuesday, 23 September 2014 at 06:22:27 UTC, Jacob Carlborg
wrote:
On 22/09/14 23:04, tn wrote:
What is the recommended way of versioning bindings? If the
binding of
the target library 1.2.3 is versioned as 1.2.3 and a bug is
fixed in the
binding (no change in the target library), how
On 22/09/2014 19:59, Vladimir Panteleev wrote:
Firefox requires 4GB of memory to build.
Chromium requires 8GB of memory to build.
Android requires 16GB of memory to build.
Thanks for the info, I didn't realize.
If you want to work on big projects, you WILL need a decent computer.
I think
Hi everyone,
just wanted to announce a further small version bump of Mono-D.
And yeah, despite my 2 week-break, development still continues!
Cheers,
Alex
On Tuesday, 23 September 2014 at 14:02:47 UTC, Alexander Bothe
wrote:
Hi everyone,
just wanted to announce a further small version bump of Mono-D.
And yeah, despite my 2 week-break, development still continues!
Cheers,
Alex
Durr, forgot to put in links:
Release notes:
On Monday, 22 September 2014 at 13:23:33 UTC, simendsjo wrote:
My guess is the average for developers is ~8GB. 2GB RAM is
really not
enough for pretty much anything these days - the browser alone
easily
chews 3-4GB on moderate use.
You have to admit that this is ridiculous. I updated to the
On Saturday, 20 September 2014 at 20:07:46 UTC, Vladimir
Panteleev wrote:
Yet another release ruined by a DMD -inline wrong-code bug :(
It seems like use of -inline is not recommended then?
On 09/23/2014 04:48 PM, Joakim wrote:
On Monday, 22 September 2014 at 13:23:33 UTC, simendsjo wrote:
My guess is the average for developers is ~8GB. 2GB RAM is really not
enough for pretty much anything these days - the browser alone easily
chews 3-4GB on moderate use.
You have to admit
Arch Linux package has been updated. Does not include
auto-completion right now, will do a point release with it
soon-ish
On 9/23/14, 7:06 AM, Alexander Bothe wrote:
On Tuesday, 23 September 2014 at 14:02:47 UTC, Alexander Bothe wrote:
Hi everyone,
just wanted to announce a further small version bump of Mono-D. And
yeah, despite my 2 week-break, development still continues!
Cheers,
Alex
Durr, forgot to put
On Tue, 23 Sep 2014 18:29:17 +0200
simendsjo via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
But if your parents want Facebook and Instagram, you better give them
a pretty beefy computer.
i'll give 'em opera 12. yes, it's dead, but it's the only browser that
can work
Hello.
last night i ported ZMBV video codec to D. ZMBV is videocodec invented
by DosBox team to record old videogames' gameplay. if you are into
writing old-school games, it can be handy to embed the
possibility to creating gameplay video directly in your game.
it's only codec for now (i.e. it
On 2014-09-23 10:08, tn wrote:
In your suggestion, once version 1.2.4 of the target library is
released, the first binding version targeting that would then be
1.2.4+1.2.4 or 1.2.5+1.2.4 or what?
If the previous binding version was 1.2.3+1.2.3 the next would be
1.2.4+1.2.4. Just increment as
On Tuesday, 23 September 2014 at 12:31:12 UTC, MrSmith wrote:
On Sunday, 21 September 2014 at 02:36:46 UTC, Brian Schott
wrote:
Some of you may have noticed this article posted to
/r/programming:
http://uniblock.tumblr.com/post/97868843242/noise. I ported
the algorithm to D and uploaded it
Already read it on Twitter - nice to hear this! :)
On Tuesday, 23 September 2014 at 16:53:23 UTC, Andrei
Alexandrescu wrote:
Awesome! I'm using it on OSX, works nice. -- Andrei
On Tuesday, 23 September 2014 at 12:31:12 UTC, MrSmith wrote:
On Sunday, 21 September 2014 at 02:36:46 UTC, Brian Schott
wrote:
Some of you may have noticed this article posted to
/r/programming:
http://uniblock.tumblr.com/post/97868843242/noise. I ported
the algorithm to D and uploaded it
On Tuesday, 23 September 2014 at 03:03:49 UTC, Manu via
Digitalmars-d wrote:
I still think most of those users would accept RC instead of
GC. Why not
support RC in the language, and make all of this library noise
redundant?
Library RC can't really optimise well, RC requires language
support to
On 23 September 2014 15:37, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 9/22/14, 9:53 PM, Manu via Digitalmars-d wrote:
On 23 September 2014 14:41, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
23-Sep-2014 03:11, Andrei Alexandrescu пишет:
On 9/22/14, 12:34 PM, Dmitry Olshansky wrote:
22-Sep-2014 01:45, Ola Fosheim Grostad пишет:
On Sunday, 21 September 2014 at 17:52:42 UTC, Dmitry Olshansky wrote:
to use non-atomic ref-counting and have far less cache pollution (the
set of fibers
On 23 September 2014 16:19, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tuesday, 23 September 2014 at 03:03:49 UTC, Manu via Digitalmars-d
wrote:
I still think most of those users would accept RC instead of GC. Why not
support RC in the language, and make all of this
23-Sep-2014 10:47, Manu via Digitalmars-d пишет:
On 23 September 2014 16:19, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
On Tuesday, 23 September 2014 at 03:03:49 UTC, Manu via
Digitalmars-d wrote:
I still think most of
Experimental JavaScript compiler [written in D] shakes up ideas
about speed, simplicity:
http://www.javaworld.com/article/2686955/html-css-js/experimental-javascript-compiler-shakes-up-ideas-about-speed-simplicity.html
Unless I missed something so far no post has been made in this
forum to
On Tuesday, 23 September 2014 at 07:31:30 UTC, Bienlein wrote:
Experimental JavaScript compiler [written in D] shakes up ideas
about speed, simplicity:
http://www.javaworld.com/article/2686955/html-css-js/experimental-javascript-compiler-shakes-up-ideas-about-speed-simplicity.html
Unless I
On Tuesday, 23 September 2014 at 03:07:41 UTC, Jet wrote:
I hope the Dlang can have the Micro-thread at the
language-level. Like the Goroutine, maby.
Sure it can - it's called Fibers:
http://dlang.org/phobos/core_thread.html#.Fiber
V Tue, 23 Sep 2014 08:06:35 +
Idan Arye via Digitalmars-d digitalmars-d@puremagic.com napsáno:
On Tuesday, 23 September 2014 at 03:07:41 UTC, Jet wrote:
I hope the Dlang can have the Micro-thread at the
language-level. Like the Goroutine, maby.
Sure it can - it's called Fibers:
On Tuesday, 23 September 2014 at 00:15:51 UTC, Oscar Martin wrote:
http://blog.mgm-tp.com/2014/04/controlling-gc-pauses-with-g1-collector
(*) What if:
- It is forbidden for __gshared have references/pointers to
objects allocated by the GC (if the compiler can help with this
prohibition,
Marc Schütz:
http://wiki.dlang.org/User:Schuetzm/scope
If a mutable argument of a function is tagged as unique, the type
system guarantees that there are no other references to it. So
can a function 'foo' like this be strongly pure?
int[] foo(unique int[] a) pure {
a[0]++;
return
On 9/22/2014 4:20 AM, Manu via Digitalmars-d wrote:
On 22 September 2014 13:19, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
On 9/21/2014 4:27 AM, Manu via Digitalmars-d wrote:
It's also extremely hard to unittest; explodes
Manu, once again your posts have the message embedded twice in them, making for
very large posts. What's happening is the posts have the text in plain text,
then the text again in HTML.
Please configure your news editor to only produce the plain text messages. The
HTML versions are ignored
On Tuesday, 23 September 2014 at 09:04:48 UTC, Kagamin wrote:
On Tuesday, 23 September 2014 at 00:15:51 UTC, Oscar Martin
wrote:
http://blog.mgm-tp.com/2014/04/controlling-gc-pauses-with-g1-collector
(*) What if:
- It is forbidden for __gshared have references/pointers to
objects allocated by
On Tuesday, 23 September 2014 at 09:17:48 UTC, bearophile wrote:
Marc Schütz:
http://wiki.dlang.org/User:Schuetzm/scope
If a mutable argument of a function is tagged as unique, the
type system guarantees that there are no other references to
it. So can a function 'foo' like this be
On Tuesday, 23 September 2014 at 09:46:17 UTC, Walter Bright
wrote:
Have you tried auto ref?
For some purposes, auto ref does the wrong thing. Whether you get
a reference depends on whether you pass an lvalue or an rvalue.
But some templates need to take either a struct by reference, or
a
On 9/23/14 5:17 AM, bearophile wrote:
Marc Schütz:
http://wiki.dlang.org/User:Schuetzm/scope
If a mutable argument of a function is tagged as unique, the type system
guarantees that there are no other references to it. So can a function
'foo' like this be strongly pure?
int[] foo(unique
On 9/23/14 6:26 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
Ok, I take it back ;-) Steven is right. It is however the case that this
function's return value would still be unique.
Yes, it could be unique. I haven't read this thread really, so I don't
know what has been proposed,
On Tuesday, 23 September 2014 at 10:16:26 UTC, Marc Schütz wrote:
On Tuesday, 23 September 2014 at 09:17:48 UTC, bearophile wrote:
Marc Schütz:
http://wiki.dlang.org/User:Schuetzm/scope
If a mutable argument of a function is tagged as unique, the
type system guarantees that there are no
The question is how thread-local GC will account for data passed
to another thread.
On Monday, 22 September 2014 at 15:54:23 UTC, Manu via
Digitalmars-d wrote:
We arrive at yet another case of it should have been that way
from the
start wrt 'scope'.
The baggage of annotation, and the lack of annotation to
existing code is a
pretty big pill to swallow.
If it were just part of
On Tuesday, 23 September 2014 at 10:29:25 UTC, Steven
Schveighoffer wrote:
On 9/23/14 6:26 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
Ok, I take it back ;-) Steven is right. It is however the case
that this
function's return value would still be unique.
Yes, it could be
Steven Schveighoffer:
int[] foo(unique int[] a) pure {
...
I don't think so. Strong pure function optimizations would not
work for something like:
auto x = foo(a) ~ foo(a);
This is similar to:
unique x1 = foo(a);
unique x2 = foo(a);
unique x = x1 ~ x2;
When the call to the first foo
On 23 September 2014 19:45, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 9/22/2014 4:20 AM, Manu via Digitalmars-d wrote:
On 22 September 2014 13:19, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
On
On 23 September 2014 19:48, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Manu, once again your posts have the message embedded twice in them, making
for very large posts. What's happening is the posts have the text in plain
text, then the text again in HTML.
Please
On 23 September 2014 20:23, via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tuesday, 23 September 2014 at 09:46:17 UTC, Walter Bright wrote:
Have you tried auto ref?
For some purposes, auto ref does the wrong thing. Whether you get a
reference depends on whether you pass an lvalue
On 9/23/14 7:11 AM, bearophile wrote:
Steven Schveighoffer:
int[] foo(unique int[] a) pure {
...
I don't think so. Strong pure function optimizations would not work
for something like:
auto x = foo(a) ~ foo(a);
This is similar to:
unique x1 = foo(a);
unique x2 = foo(a);
unique x = x1 ~
On 23 September 2014 21:02, via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 22 September 2014 at 15:54:23 UTC, Manu via Digitalmars-d wrote:
We arrive at yet another case of it should have been that way from the
start wrt 'scope'.
The baggage of annotation, and the lack of
On Tuesday, 23 September 2014 at 10:38:29 UTC, Kagamin wrote:
The question is how thread-local GC will account for data
passed to another thread.
std.concurrency.send() could notify the GC.
Steven Schveighoffer:
This begs the question, what is the point of having strong
purity if you can't optimize based on it?
Linear typing gives some guarantees that help the GC a lot, and
avoid some coding mistakes. And some people could answer you that
having (strongly) pure functions is a
On Tuesday, 23 September 2014 at 08:14:50 UTC, Daniel Kozak via
Digitalmars-d wrote:
V Tue, 23 Sep 2014 08:06:35 +
Idan Arye via Digitalmars-d digitalmars-d@puremagic.com
napsáno:
On Tuesday, 23 September 2014 at 03:07:41 UTC, Jet wrote:
I hope the Dlang can have the Micro-thread at the
On 23 September 2014 17:17, Dmitry Olshansky via Digitalmars-d
digitalmars-d@puremagic.com wrote:
23-Sep-2014 10:47, Manu via Digitalmars-d пишет:
On 23 September 2014 16:19, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
On Tuesday, 23
V Tue, 23 Sep 2014 12:14:15 +
Atila Neves via Digitalmars-d digitalmars-d@puremagic.com napsáno:
On Tuesday, 23 September 2014 at 08:14:50 UTC, Daniel Kozak via
Digitalmars-d wrote:
V Tue, 23 Sep 2014 08:06:35 +
Idan Arye via Digitalmars-d digitalmars-d@puremagic.com
napsáno:
On Monday, 22 September 2014 at 23:11:42 UTC, Andrei Alexandrescu
wrote:
I agree. It does have legs however. We should learn a few
things from it, such as green threads, dependency management,
networking libraries. Also Go shows that good quality tooling
makes a lot of a difference. And of
On Tuesday, 23 September 2014 at 12:19:52 UTC, Daniel Kozak via
Digitalmars-d wrote:
I know, but I mean there is no scheduler in standard library or
at language-level
That code has been written for almost a year now. Someone will
pull it eventually :-/
On Monday, 22 September 2014 at 09:45:23 UTC, Ola Fosheim Grostad
wrote:
Locking fibers to threads will cost you more than using
threadsafe features. One 300ms request can then starve waiting
fibers even if you have 7 free threads. That's bad for latency,
because then all fibers on that
On 18/09/2014 17:49, H. S. Teoh via Digitalmars-d wrote:
On Thu, Sep 18, 2014 at 05:05:31PM +0100, Bruno Medeiros via Digitalmars-d
wrote:
On 01/08/2014 05:12, Walter Bright wrote:
On 7/31/2014 2:21 PM, Sean Kelly wrote:
Thoughts?
If a process detects a logic error, then that process is in
On 19/09/2014 12:34, Chris wrote:
keep the salaries low
HAHAHAHAHAHAHA..
Man, that was so funny, good one, bro!
Java salaries low, lol...
--
Bruno Medeiros
https://twitter.com/brunodomedeiros
The lack of clear direction or communication thereof. A
continual adding of new stuff to try and appease the theoretical
masses who will certainly come flocking to D if implemented, and
a lack of attention paid to tightening up what we've already got
and deprecating old stuff that no one
On Monday, 22 September 2014 at 14:56:26 UTC, Andrei Alexandrescu
wrote:
On 9/22/14, 2:39 AM, Don wrote:
On Sunday, 21 September 2014 at 18:09:26 UTC, Andrei
Alexandrescu wrote:
On 9/21/14, 8:29 AM, ketmar via Digitalmars-d wrote:
On Sun, 21 Sep 2014 08:15:29 -0700
Andrei Alexandrescu via
Guys, all this fighting around. Can't we do something like the
following and sort this out?
-
import std.string;
import std.typecons;
private struct RealTypedef(T, T init_val, string cookie)
{
/// implementation here...
}
template Typedef(T, T init_val = T.init,
string cookie = ,
Andrej Mitrovic:
alias Same_Type_1 = Typedef!(void*, null, cookie);
alias Same_Type_2 = Typedef!(void*, null, cookie);
static assert(is(Same_Type_1 == Same_Type_2)); // unsafe
*only if you request it*
I suggest to not offer this usage possibility.
Bye,
bearophile
On 9/22/14, 11:44 PM, Manu via Digitalmars-d wrote:
On 23 September 2014 15:37, Andrei Alexandrescu via Digitalmars-d
The trouble with library types like RefCounted!, is that they appear to
be conceptually backwards to me.
RefCounted!T suggests that T is a parameter to RefCounted, ie,
RefCounted
On 9/23/14, 12:17 AM, Dmitry Olshansky wrote:
In my imagination it would be along the lines of
@ARC
struct MyCountedStuff{ void opInc(); void opDec(); }
So that would be a pointer type or a value type? Is there copy on write
somewhere? -- Andrei
On 9/22/14, 11:47 PM, Manu via Digitalmars-d wrote:
On 23 September 2014 16:19, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote:
On Tuesday, 23 September 2014 at 03:03:49 UTC, Manu via
Digitalmars-d wrote:
I still think most of
On Monday, 22 September 2014 at 17:21:50 UTC, Andrei Alexandrescu
wrote:
I would agree with that. If I'd do it over again I'd probably
make the string the second argument with no default.
That's not the problem though.
You can make the argument that it's not that much of a burden.
And on
And what GC does? Pins the allocated blocks for another thread?
On Tuesday, 23 September 2014 at 15:23:16 UTC, Kagamin wrote:
And what GC does? Pins the allocated blocks for another thread?
Assuming there is one thread-local GC per thread, it transfers
responsibility of the allocated data from the sender to the
receiver. This means, the old GC doesn't
Do you guys remember 'Harmonia' ? A promising GUI-tool
once developed in D1 by Andrew Fedoniouk. [1,2,3]
Unfortunately he stopped the development long time ago and
changed his tools.
The reasoning is now explained in his recent blog post [4]
Interesting (regarding the recent GC-discussion
On 9/23/14, 5:51 AM, Wyatt wrote:
On Monday, 22 September 2014 at 23:11:42 UTC, Andrei Alexandrescu wrote:
I agree. It does have legs however. We should learn a few things from
it, such as green threads, dependency management, networking
libraries. Also Go shows that good quality tooling makes
On 9/23/14, 6:41 AM, Sean Kelly wrote:
On Tuesday, 23 September 2014 at 12:19:52 UTC, Daniel Kozak via
Digitalmars-d wrote:
I know, but I mean there is no scheduler in standard library or at
language-level
That code has been written for almost a year now. Someone will pull it
eventually :-/
On 9/23/14, 7:29 AM, Sean Kelly wrote:
The lack of clear direction or communication thereof.
* C++ compatibility
* Everything GC-related
Probably a distant third is improving build tooling. But those two are
more important that everything else by an order of magnitude.
Andrei
On 9/23/14, 7:43 AM, Don wrote:
On Monday, 22 September 2014 at 14:56:26 UTC, Andrei Alexandrescu wrote:
On 9/22/14, 2:39 AM, Don wrote:
Yes, but you're advocating a hack.
Oh but I very much disagree.
Now you are scaring me. It worries me that this kind of solution can
be viewed as
On Tuesday, 23 September 2014 at 15:43:41 UTC, Andrei
Alexandrescu wrote:
Yah, we definitely should have one of our mythical lieutenants
on that. -- Andrei
I distinctly remember someone offering to write one and being
shot down (by Walter?).
-Wyatt
On Monday, 22 September 2014 at 09:39:29 UTC, Don wrote:
Having said that, though, the success of 'alias this' does
raise some interesting questions about how useful the concept
of a typedef is. Certainly it's much less useful than when
Typedef was created.
My feeling is that almost every
On Tuesday, 23 September 2014 at 15:47:21 UTC, Andrei
Alexandrescu wrote:
On 9/23/14, 7:29 AM, Sean Kelly wrote:
The lack of clear direction or communication thereof.
* C++ compatibility
* Everything GC-related
Probably a distant third is improving build tooling. But those
two are more
On Tuesday, 23 September 2014 at 15:44:19 UTC, Andrei
Alexandrescu wrote:
On 9/23/14, 6:41 AM, Sean Kelly wrote:
On Tuesday, 23 September 2014 at 12:19:52 UTC, Daniel Kozak via
Digitalmars-d wrote:
I know, but I mean there is no scheduler in standard library
or at
language-level
That code
On 9/23/14, 9:05 AM, Dicebot wrote:
On Monday, 22 September 2014 at 09:39:29 UTC, Don wrote:
Having said that, though, the success of 'alias this' does raise some
interesting questions about how useful the concept of a typedef is.
Certainly it's much less useful than when Typedef was created.
On 9/23/14, 9:02 AM, Wyatt wrote:
On Tuesday, 23 September 2014 at 15:43:41 UTC, Andrei Alexandrescu wrote:
Yah, we definitely should have one of our mythical lieutenants on
that. -- Andrei
I distinctly remember someone offering to write one and being shot down
(by Walter?).
The offer was
On Tuesday, 23 September 2014 at 16:01:35 UTC, Andrei
Alexandrescu wrote:
mixin(makeTypedef!(HMENU, void*));
struct HMENU { void* _; alias _ this; }
Don't even have to import a Phobos module for it!
On 9/23/14, 9:06 AM, Sean Kelly wrote:
On Tuesday, 23 September 2014 at 15:47:21 UTC, Andrei Alexandrescu wrote:
On 9/23/14, 7:29 AM, Sean Kelly wrote:
The lack of clear direction or communication thereof.
* C++ compatibility
* Everything GC-related
Probably a distant third is improving
On 9/23/14, 9:11 AM, Sean Kelly wrote:
On Tuesday, 23 September 2014 at 15:44:19 UTC, Andrei Alexandrescu wrote:
On 9/23/14, 6:41 AM, Sean Kelly wrote:
On Tuesday, 23 September 2014 at 12:19:52 UTC, Daniel Kozak via
Digitalmars-d wrote:
I know, but I mean there is no scheduler in standard
On 9/23/14, 9:15 AM, Adam D. Ruppe wrote:
On Tuesday, 23 September 2014 at 16:01:35 UTC, Andrei Alexandrescu wrote:
mixin(makeTypedef!(HMENU, void*));
struct HMENU { void* _; alias _ this; }
Don't even have to import a Phobos module for it!
Even better. I love good idioms! -- Andrei
On Tuesday, 23 September 2014 at 16:20:25 UTC, Andrei
Alexandrescu wrote:
I guess you can disable the whole feature on Win64 and leave it
to someone else to introduce it. You can't work on this stuff
without a box. -- Andrei
Yes, but don't forget that there are still a few actual,
unresolved
On Tue, Sep 23, 2014 at 09:26:51AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 9/23/14, 9:15 AM, Adam D. Ruppe wrote:
On Tuesday, 23 September 2014 at 16:01:35 UTC, Andrei Alexandrescu wrote:
mixin(makeTypedef!(HMENU, void*));
struct HMENU { void* _; alias _ this; }
Don't even
On 9/23/14, 9:27 AM, David Nadlinger wrote:
On Tuesday, 23 September 2014 at 16:20:25 UTC, Andrei Alexandrescu wrote:
I guess you can disable the whole feature on Win64 and leave it to
someone else to introduce it. You can't work on this stuff without a
box. -- Andrei
Yes, but don't forget
On 9/23/14, 8:10 AM, Wyatt wrote:
On Monday, 22 September 2014 at 17:21:50 UTC, Andrei Alexandrescu wrote:
I would agree with that. If I'd do it over again I'd probably make the
string the second argument with no default.
That's not the problem though.
You can make the argument that it's
Andrei Alexandrescu:
It's the poetic injustice of Typedef is broken/unusable I
have a problem with. -- Andrei
You seem the only one with such problem :-)
Bye,
bearophile
On Tuesday, 23 September 2014 at 16:19:00 UTC, Andrei
Alexandrescu wrote:
So why not mix in Typedef? -- Andrei
Why would I ever want it? Plain struct is absolutely superior to
it.
On 9/23/14, 9:37 AM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Sep 23, 2014 at 09:26:51AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 9/23/14, 9:15 AM, Adam D. Ruppe wrote:
On Tuesday, 23 September 2014 at 16:01:35 UTC, Andrei Alexandrescu wrote:
mixin(makeTypedef!(HMENU,
On Tuesday, 23 September 2014 at 16:19:31 UTC, Andrei
Alexandrescu wrote:
On 9/23/14, 9:06 AM, Sean Kelly wrote:
On Tuesday, 23 September 2014 at 15:47:21 UTC, Andrei
Alexandrescu wrote:
On 9/23/14, 7:29 AM, Sean Kelly wrote:
The lack of clear direction or communication thereof.
* C++
On Tuesday, 23 September 2014 at 10:38:29 UTC, Kagamin wrote:
The question is how thread-local GC will account for data
passed to another thread.
I was briefly discussing this with Andrei at (I think) DConf
2013. I suggested moving data to a separate global GC heap on
casting stuff to
Andrei Alexandrescu:
* C++ compatibility
* Everything GC-related
Probably a distant third is improving build tooling. But those
two are more important that everything else by an order of
magnitude.
In parallel there are other things like ddmd, checked ints in
core library, perhaps to
On 9/23/14, 9:40 AM, Paolo Invernizzi wrote:
I'm starting to think that there will be a lot of buzz and fuss about D
as soon as good bindings to popular C++ libs will appear in the wild...
Yah, and core.stdcpp will be quite the surprise. -- Andrei
On 9/23/14, 9:44 AM, bearophile wrote:
Andrei Alexandrescu:
It's the poetic injustice of Typedef is broken/unusable I
have a problem with. -- Andrei
You seem the only one with such problem :-)
Argumentum ad populum again? You really are out of points to make. -- Andrei
On 9/23/14, 9:41 AM, Dicebot wrote:
On Tuesday, 23 September 2014 at 16:19:00 UTC, Andrei Alexandrescu wrote:
So why not mix in Typedef? -- Andrei
Why would I ever want it? Plain struct is absolutely superior to it.
worksforme
On Tue, Sep 23, 2014 at 04:41:27PM +, Dicebot via Digitalmars-d wrote:
On Tuesday, 23 September 2014 at 16:19:00 UTC, Andrei Alexandrescu wrote:
So why not mix in Typedef? -- Andrei
Why would I ever want it? Plain struct is absolutely superior to it.
So what are we arguing about here? If
On Tuesday, 23 September 2014 at 16:38:14 UTC, Andrei
Alexandrescu wrote:
On 9/23/14, 9:27 AM, David Nadlinger wrote:
On Tuesday, 23 September 2014 at 16:20:25 UTC, Andrei
Alexandrescu wrote:
I guess you can disable the whole feature on Win64 and leave
it to
someone else to introduce it. You
On Tuesday, 23 September 2014 at 16:50:26 UTC, Andrei
Alexandrescu wrote:
On 9/23/14, 9:40 AM, Paolo Invernizzi wrote:
I'm starting to think that there will be a lot of buzz and
fuss about D
as soon as good bindings to popular C++ libs will appear in
the wild...
Yah, and core.stdcpp will be
On Tuesday, 23 September 2014 at 16:56:36 UTC, Sean Kelly wrote:
I wasn't aware of any. Someone suggested moving Generator to a
separate module and I explained why this isn't advisable. If
there are other issues, I would appreciate it if someone would
restate them.
1) There is still
We need a libunwind expert to figure out a good approach for handling
exceptions thrown by C++ code into D.
Is anyone fluent with libunwind?
Andrei
On 9/23/14, 9:56 AM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Sep 23, 2014 at 04:41:27PM +, Dicebot via Digitalmars-d
wrote:
On Tuesday, 23 September 2014 at 16:19:00 UTC, Andrei Alexandrescu
wrote:
So why not mix in Typedef? -- Andrei
Why would I ever want it? Plain struct is
On Tuesday, 23 September 2014 at 17:36:33 UTC, Andrei
Alexandrescu wrote:
(b) there are no significant ways to improve Typedef in ways
that would be difficult to the struct-based approach (e.g.
disallow implicit conversion to base type, adding constructors
etc).
I think disallowing stuff is
1 - 100 of 262 matches
Mail list logo
