On 28 Dec 2014 21:25, bearophile via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
Iain Buclaw:
1.086s: bfgccjitd-runtime-O2
1.139s: bfgccjitd-runtime-O1
2.759s: bfgccjitd-O1
3.646s: bfgccjitd-O2
4.959s: bff-O2
Five times faster than bff is a lot :-)
On Monday, 29 December 2014 at 09:30:40 UTC, Vadim Lopatin wrote:
On Monday, 29 December 2014 at 07:35:13 UTC, ketmar via
Digitalmars-d-announce wrote:
ah, and another thing: freeimage sux for GNU/Linux. it looks
completely
alien and no sane GUI software requires it. i didn't looked at
the
On 29/12/2014 10:33 p.m., Vadim Lopatin wrote:
On Monday, 29 December 2014 at 09:30:40 UTC, Vadim Lopatin wrote:
On Monday, 29 December 2014 at 07:35:13 UTC, ketmar via
Digitalmars-d-announce wrote:
ah, and another thing: freeimage sux for GNU/Linux. it looks completely
alien and no sane GUI
On Mon, 29 Dec 2014 09:30:39 +
Vadim Lopatin via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
Initially, I've used libpng for loading images.
But it is compatible only with some particular version of
libpng.so
yep, libpng sux too.
Probably, it makes sense to move
On Monday, 29 December 2014 at 09:43:34 UTC, Rikki Cattermole
wrote:
On 29/12/2014 10:33 p.m., Vadim Lopatin wrote:
On Monday, 29 December 2014 at 09:30:40 UTC, Vadim Lopatin
wrote:
BTW, there is de_image package - Image loading and exporting
Devisualization.
It's native D implementation, and
On 30/12/2014 12:14 a.m., Vadim Lopatin wrote:
On Monday, 29 December 2014 at 09:43:34 UTC, Rikki Cattermole wrote:
On 29/12/2014 10:33 p.m., Vadim Lopatin wrote:
On Monday, 29 December 2014 at 09:30:40 UTC, Vadim Lopatin wrote:
BTW, there is de_image package - Image loading and exporting
On Friday, 26 December 2014 at 12:33:04 UTC, Vadim Lopatin wrote:
Hello!
DlangUI project is alive and under active development.
https://github.com/buggins/dlangui
Recent changes:
- new controls: ScrollWidget, TreeView, ComboBox, ...
- new dialogs: FileOpenDialog, MessageBox
- a lot of
On Friday, 26 December 2014 at 17:47:29 UTC, Jacob Carlborg wrote:
On 2014-12-25 14:12, Christian Schneider wrote:
Just for my information: Why is it no longer possible to have
multiple d
methods (or overloaded constructors) to map to the same
Objective-C
implementation?
I though it was
On Monday, 29 December 2014 at 09:30:40 UTC, Vadim Lopatin wrote:
I've tried to find some replacement for it, and found FreeImage
There is http://code.dlang.org/packages/dlib which includes
dlib.image - image processing (filters, color correction, FFT,
HDRI, graphics formats I/O, support for
On Monday, 15 December 2014 at 12:37:18 UTC, Stefan Koch wrote:
New videos are online :)
part 1:
https://www.youtube.com/watch?v=_YAUfd41URA
part 2:
https://www.youtube.com/watch?v=RGLgiPhwskM
please give me feedback in this thread
I have watched the videos in speed 2 (double speed) and they
It's the destructor in NSObject that causes the problem. I'll
take a look. Remove that and your example will work, after you
import the missing foundation.runtime in app.
Once again, thank you very much for your help! It works now with
the new @selector style, and I would had the biggest
On Monday, 29 December 2014 at 19:55:13 UTC, kdmult wrote:
On Monday, 29 December 2014 at 09:30:40 UTC, Vadim Lopatin
wrote:
I've tried to find some replacement for it, and found FreeImage
There is http://code.dlang.org/packages/dlib which includes
dlib.image - image processing (filters,
On 12/29/14, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
We're in the cooperative stage of D, and we need to move toward the
established organization stage.
Unrelated to this grander idea I really liked the recent Rust blog post:
On 29 December 2014 at 03:52, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 12/28/14 6:43 PM, Manu via Digitalmars-d wrote:
On 27 December 2014 at 02:21, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 12/25/14 5:18 PM, Mike Parker
On Saturday, 27 December 2014 at 08:32:29 UTC, Mike Parker wrote:
It would also be nice to anticipate that people looking to
operate on strings would look in std.string for things that are
elsewhere. Once upon a time, the std.string docs actually did
have a table of links for functions that
On Monday, 29 December 2014 at 09:35:25 UTC, Iain Buclaw via
Digitalmars-d wrote:
The new layout solves half the problem in that it hides the
template
constraints.
http://dlang.org/library/std/algorithm/sort.html
Shouldn't our focus also be to get the new layout out of
preview
mode and do
On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu
wrote:
There is a rub though. Not only you're telling what we'd need
to do to be more successful, you're also telling us how to do
it. Please don't. We are not adding type qualifiers to D if we
can avoid it, and generally we want
On 2014-12-29 06:39, Walter Bright wrote:
Having used both Ddoc and Markdown, I seriously disagree with this. Take
a look at the markdown source for DIP69. It's horrific.
Do you mean on the wiki? The wiki doesn't use Markdown. At least not
anyone I've seen.
--
/Jacob Carlborg
On Monday, 29 December 2014 at 00:50:10 UTC, Walter Bright wrote:
It's already possible. Change the macro definitions in the
std.ddoc file.
Sure. But I did think it might be a good idea to discuss things
here first before jumping into changing anything. After all, you
might have good
On 2014-12-29 01:45, Walter Bright wrote:
I don't want to use Markdown. The D wiki uses it, and once you step
outside of the trivial, you have to insert html that is crippled in
various erratic ways. Any non-trivial documentation winds up being one
ugly mo-fo.
I does not use Markdown.
On Tuesday, 23 December 2014 at 00:25:33 UTC, Walter Bright wrote:
On 12/22/2014 12:59 PM, Iain Buclaw via Digitalmars-d wrote:
On 22 December 2014 at 20:52, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 12/22/2014 9:40 AM, Adam D. Ruppe wrote:
By this time last year,
Now,I use the win32.winioctl.d file,find
:IOCTL_STORAGE_EJECT_MEDIA ' Value is 0x0202,if you use it ,will
get the error value 50.(by GetLastError()).
It should be 0x2d4808.If you use it ,it works ok.
Why have this kind of mistake?
Frank
Am 29.12.2014 um 13:00 schrieb FrankLike:
Now,I use the win32.winioctl.d file,find
:IOCTL_STORAGE_EJECT_MEDIA ' Value is 0x0202,if you use it ,will
get the error value 50.(by GetLastError()).
It should be 0x2d4808.If you use it ,it works ok.
Why have this kind of mistake?
Frank
maybe just
On 29/12/14 01:48, Walter Bright via Digitalmars-d wrote:
Ddoc does not generate html markup. It generates macro calls, and the macro
definitions default to expanding to html. You can override them to produce other
effects.
Yes, understood, but I'm talking about the defaults here -- it would
Hi all,
I've got a little problem regarding const. In fact, my problem
originates from C++ where I've tried to implement a visitor that
deals with both const and non-const objects. As this did not work
out, I checked whether it would work in D. Unfortunately, I could
not figure out how.
You need to overload on const, and also pass in a correctly typed
function as the argument (you can't call a function with a
mutable parameter with a const object.
import std.stdio;
class Hugo {
public int x = 42;
void blah(void function(Hugo h) f) {
f(this);
}
// OVERLOAD
Thank you for your answer. This kind of thing also works for C++,
but that would mean that I would implement the whole visitor
twice - one const and one non-const version. Is that really the
only way? Can't I tell the D compiler that the argument of that
lambda shares the const-ness of the
So I hope you understand; I've got no problem with changing the
type of the function g as you supposed. The bad thing is the
additional overload that results in duplicated code.
On 12/28/14 4:33 PM, Walter Bright wrote:
On 12/28/2014 12:04 PM, Peter Alexander wrote:
On Sunday, 28 December 2014 at 18:16:04 UTC, Andrei Alexandrescu wrote:
Very little breakage I can think of. Ranges usually don't own their
payload.
I'm thinking more about higher order ranges, e.g.
On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref. This should then simplify DIP69
significantly.
Please comment: http://wiki.dlang.org/DIP25
ref int hun() inout { return b; }
This doesn't make
On Wednesday, 24 December 2014 at 03:11:40 UTC, Andrei
Alexandrescu wrote:
On 12/20/14 6:47 PM, Steven Schveighoffer wrote:
On 12/20/14 5:20 AM, Dicebot wrote:
I'd like to have a cast where you must define both from and
to types
precisely.
I was actually thinking the same thing. This would
On Thursday, 25 December 2014 at 10:06:35 UTC, Martin Nowak wrote:
On Sunday, 21 December 2014 at 12:48:42 UTC, Dicebot wrote:
On Sunday, 21 December 2014 at 12:26:04 UTC, Jacob Carlborg
wrote:
On 2014-12-21 10:46, Dicebot wrote:
Stuff that immediately comes to my mind:
- some way to define
On Monday, 29 December 2014 at 13:22:41 UTC, Julian Kranz wrote:
So I hope you understand; I've got no problem with changing the
type of the function g as you supposed. The bad thing is the
additional overload that results in duplicated code.
So you can write something like this:
import
On 12/29/14 8:20 AM, Julian Kranz wrote:
Thank you for your answer. This kind of thing also works for C++, but
that would mean that I would implement the whole visitor twice - one
const and one non-const version. Is that really the only way? Can't I
tell the D compiler that the argument of that
On 12/29/14 9:18 AM, Steven Schveighoffer wrote:
Static-if applies to generic coding, i.e. templates. A template function
may work, but I don't think you even need static if:
class Hugo { ... }
void blah(T)(T obj, void function(T t) f) if(T : Hugo) { f(obj);}
um...
blah(T : Hugo)(T obj,
On Friday, 26 December 2014 at 01:11:42 UTC, Manu via
Digitalmars-d wrote:
Many bug reports and case studies, and often, a persistent
voice for
minority issues that don't get enough attention. My time spent
arguing
in this forum is substantial, and as annoying as it may seem, I
think
if I
Thank you for your answers. All of your suggestions go into the
right direction, however there's still one thing left that
breakes it: the method itself (blah()) needs to be marked as
const to be callable on a const object. Therefore, I need
something like
void blah(...)(...) if(this ia
On Monday, 29 December 2014 at 14:45:37 UTC, Dicebot wrote:
On Friday, 26 December 2014 at 01:11:42 UTC, Manu via
Digitalmars-d wrote:
Many bug reports and case studies, and often, a persistent
voice for
minority issues that don't get enough attention. My time spent
arguing
in this forum is
On Monday, 29 December 2014 at 15:17:30 UTC, Julian Kranz wrote:
Thank you for your answers. All of your suggestions go into the
right direction, however there's still one thing left that
breakes it: the method itself (blah()) needs to be marked as
const to be callable on a const object.
On Monday, 29 December 2014 at 12:19:34 UTC, dennis luehring
wrote:
Am 29.12.2014 um 13:00 schrieb FrankLike:
Now,I use the win32.winioctl.d file,find
:IOCTL_STORAGE_EJECT_MEDIA ' Value is 0x0202,if you use it
,will
get the error value 50.(by GetLastError()).
It should be 0x2d4808.If you use
On Monday, 29 December 2014 at 15:18:57 UTC, Gary Willoughby
wrote:
This is probably the most disgusting, selfish and deluded posts
i've read on this entire newsgroup.
I am pretty sure I have written worse.
If D is supposed to supplant C/C++, then the needs of those
users *must* be met,
On Monday, 29 December 2014 at 15:25:13 UTC, Daniel Kozak wrote:
On Monday, 29 December 2014 at 15:17:30 UTC, Julian Kranz wrote:
Thank you for your answers. All of your suggestions go into
the right direction, however there's still one thing left that
breakes it: the method itself (blah())
On Friday, 26 December 2014 at 22:01:30 UTC, user wrote:
don't use crap - use
http://forum.dlang.org/thread/ovgoajvboltrtciqf...@forum.dlang.org
it is great. works for 64bit!!
Thank you,if you have any question,I will help for you.
Frank
On 12/29/14 10:36 AM, Julian Kranz wrote:
On Monday, 29 December 2014 at 15:25:13 UTC, Daniel Kozak wrote:
On Monday, 29 December 2014 at 15:17:30 UTC, Julian Kranz wrote:
Thank you for your answers. All of your suggestions go into the right
direction, however there's still one thing left that
On 12/29/14 6:08 AM, Dicebot wrote:
On Wednesday, 24 December 2014 at 03:11:40 UTC, Andrei Alexandrescu wrote:
On 12/20/14 6:47 PM, Steven Schveighoffer wrote:
On 12/20/14 5:20 AM, Dicebot wrote:
I'd like to have a cast where you must define both from and to
types
precisely.
I was actually
No, actually I don't at all understand why the function does not
need to be const any longer since this code does not compile:
import std.stdio;
class Hugo {
public int x = 42;
void blah(this T)(void function(const Hugo h) f) {
f(this);
}
}
void main() {
Hugo hugo = new Hugo();
Sorry, copy+paste error, I of course meant the following :-/...
import std.stdio;
class Hugo {
public int x = 42;
void blah(void function(const Hugo h) f) {
f(this);
}
}
void main() {
Hugo hugo = new Hugo();
const Hugo inge = hugo;
void function(const Hugo h) g =
On 12/29/14 2:58 AM, John Colvin wrote:
On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu wrote:
There is a rub though. Not only you're telling what we'd need to do to
be more successful, you're also telling us how to do it. Please don't.
We are not adding type qualifiers to D if
On 12/29/14 6:07 AM, Steven Schveighoffer wrote:
On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref. This should then simplify DIP69
significantly.
Please comment: http://wiki.dlang.org/DIP25
ref
On Monday, 22 December 2014 at 20:51:46 UTC, Walter Bright wrote:
On 12/22/2014 12:04 AM, Dicebot wrote:
Point of transitive scope is to make easy to expose complex
custom data
structures without breaking memory safety.
I do understand that. Making it work with the type system is
another
On Monday, 29 December 2014 at 15:53:25 UTC, Steven Schveighoffer
wrote:
The compiler can infer attributes if a function is a template.
Not all attributes, but some of them.
-Steve
Ah, thanks, this explains it ;-). However, it's kind of uncool
that this only works for templates...
On Monday, 29 December 2014 at 15:18:57 UTC, Gary Willoughby
wrote:
This is probably the most disgusting, selfish and deluded posts
i've read on this entire newsgroup.
If D is supposed to supplant C/C++, then the needs of those
users *must* be met, especially without deriding those very
On Monday, 29 December 2014 at 16:03:41 UTC, Julian Kranz wrote:
On Monday, 29 December 2014 at 15:53:25 UTC, Steven
Schveighoffer wrote:
The compiler can infer attributes if a function is a template.
Not all attributes, but some of them.
-Steve
Ah, thanks, this explains it ;-). However,
On 12/29/14 10:51 AM, Andrei Alexandrescu wrote:
On 12/29/14 6:07 AM, Steven Schveighoffer wrote:
On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref. This should then simplify DIP69
significantly.
On Monday, 29 December 2014 at 16:03:41 UTC, Julian Kranz wrote:
On Monday, 29 December 2014 at 15:53:25 UTC, Steven
Schveighoffer wrote:
The compiler can infer attributes if a function is a template.
Not all attributes, but some of them.
-Steve
Ah, thanks, this explains it ;-). However,
On Monday, 29 December 2014 at 16:07:59 UTC, Joakim wrote:
I strongly disagree. Dicebot's post is completely true,
describing exactly how open source projects actually work,
No Dicebot described how open source projects *start*, big
difference.
I don't want to get into a massive argument
On Monday, 29 December 2014 at 16:19:35 UTC, Gary Willoughby
wrote:
On Monday, 29 December 2014 at 16:07:59 UTC, Joakim wrote:
I strongly disagree. Dicebot's post is completely true,
describing exactly how open source projects actually work,
No Dicebot described how open source projects
On Monday, 29 December 2014 at 15:50:15 UTC, Andrei Alexandrescu
wrote:
I see. I guess it's easy to add std.conv.explicitCast and
std.conv.implicitCast if there's enough impetus for it. --
Andrei
Yes, exactly. That was why I have asked general opinion about it
- don't want to add yet another
On Monday, 29 December 2014 at 16:09:33 UTC, Daniel N wrote:
On Monday, 29 December 2014 at 16:03:41 UTC, Julian Kranz wrote:
On Monday, 29 December 2014 at 15:53:25 UTC, Steven
Schveighoffer wrote:
The compiler can infer attributes if a function is a
template. Not all attributes, but some of
On Monday, 29 December 2014 at 16:13:03 UTC, Vlad Levenfeld wrote:
On Monday, 29 December 2014 at 16:03:41 UTC, Julian Kranz wrote:
On Monday, 29 December 2014 at 15:53:25 UTC, Steven
Schveighoffer wrote:
The compiler can infer attributes if a function is a
template. Not all attributes, but
On Monday, 29 December 2014 at 16:33:05 UTC, Joakim wrote:
If anybody cared about good Windows debugging support or
getting vibe.d working flawlessly on Windows, they'd have done
it already. Now, Manu might bring more attention to those
issues through his post and someone may decide to work
On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu
wrote:
Walter's reasoning was: we have inout for propagating
qualifiers from a parameter (this is also a parameter) to the
output, so we can use it for propagating aliasing information
as well.
Yay! I have been asking for it
On Sat, Dec 27, 2014 at 05:00:00PM -0800, Walter Bright via Digitalmars-d wrote:
This is so bad there isn't even a direct link to it, it hides in
shame. Just go here:
http://dlang.org/phobos/std_encoding.html#.transcode
and scroll up one entry. Here it is:
size_t encode(Tgt, Src,
On Monday, 29 December 2014 at 14:45:37 UTC, Dicebot wrote:
Wasting effort of core contributors on a toolchain I will
never use is against my interests and makes me naturally
hostile about it.
I don't think it needs to be a zero-sum game. Removing blockers
to entry can make an
On Monday, 29 December 2014 at 16:33:05 UTC, Joakim wrote:
But Dicebot is right that users are not the concern of those
outside a small core who contribute to D. Most contributors
are just scratching their own itch, and users are just
potential suckers who might add other features I want. ;)
On Monday, 29 December 2014 at 16:45:31 UTC, Dicebot wrote:
On Monday, 29 December 2014 at 15:50:15 UTC, Andrei
Alexandrescu wrote:
I see. I guess it's easy to add std.conv.explicitCast and
std.conv.implicitCast if there's enough impetus for it. --
Andrei
Yes, exactly. That was why I have
On Monday, 29 December 2014 at 05:39:16 UTC, Walter Bright wrote:
On 12/28/2014 8:44 AM, Kiith-Sa wrote:
It depends on the function being documented. For 'downcase',
such blocks are
overkill;
After doing it both ways for a while, I'm pretty convinced they
are not overkill even for trivial
On Monday, 29 December 2014 at 15:34:44 UTC, Dicebot wrote:
On Monday, 29 December 2014 at 15:18:57 UTC, Gary Willoughby
wrote:
This is probably the most disgusting, selfish and deluded
posts i've read on this entire newsgroup.
I am pretty sure I have written worse.
Time out, everyone. I
On Monday, 29 December 2014 at 18:42:17 UTC, Joseph Rushton
Wakeling wrote:
On Monday, 29 December 2014 at 15:34:44 UTC, Dicebot wrote:
This is widely advertised statement I can't agree with. For me
goal is having working language that works. Getting users is
indirect way to achieve that by
On 12/29/14 8:09 AM, Steven Schveighoffer wrote:
On 12/29/14 10:51 AM, Andrei Alexandrescu wrote:
On 12/29/14 6:07 AM, Steven Schveighoffer wrote:
On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
Walter and I have been working on revamping DIP25, which focuses on
tightening the screws of ref.
On Monday, 29 December 2014 at 19:00:06 UTC, Andrei Alexandrescu
wrote:
I tend to agree. You seem to have shown that reusing inout for
scope information becomes confusing. -- Andrei
What is the problem with using inout exactly as it is now (==
both for argument and return type) but defining
On 12/29/14 10:14 AM, Jonathan Marler wrote:
On Monday, 29 December 2014 at 16:45:31 UTC, Dicebot wrote:
On Monday, 29 December 2014 at 15:50:15 UTC, Andrei Alexandrescu wrote:
I see. I guess it's easy to add std.conv.explicitCast and
std.conv.implicitCast if there's enough impetus for it. --
On Monday, 29 December 2014 at 14:13:20 UTC, Daniel Kozak wrote:
On Monday, 29 December 2014 at 13:22:41 UTC, Julian Kranz wrote:
So I hope you understand; I've got no problem with changing
the type of the function g as you supposed. The bad thing is
the additional overload that results in
On Monday, 29 December 2014 at 13:20:39 UTC, Julian Kranz wrote:
Thank you for your answer. This kind of thing also works for
C++, but that would mean that I would implement the whole
visitor twice - one const and one non-const version. Is that
really the only way? Can't I tell the D compiler
On 12/29/14 10:58 AM, Joakim wrote:
On Monday, 29 December 2014 at 18:42:17 UTC, Joseph Rushton Wakeling wrote:
On Monday, 29 December 2014 at 15:34:44 UTC, Dicebot wrote:
This is widely advertised statement I can't agree with. For me goal
is having working language that works. Getting users
On Mon, 29 Dec 2014 15:18:56 +
Gary Willoughby via Digitalmars-d digitalmars-d@puremagic.com wrote:
This is probably the most disgusting, selfish and deluded posts
i've read on this entire newsgroup.
fsck. i was sure that this was written about me. i sucked again.
If D is supposed to
I'm wondering where we currently are on the process of releasing
2.067 ?
The reference page
http://wiki.dlang.org/Beta_Testing#Available_Downloads , is
horribly outdated, as DMD v2.066.1 was released, all known
regressions are marked as fixed on Bugzilla, and page's last
modification date is
On 12/29/2014 3:19 AM, Jacob Carlborg wrote:
On 2014-12-29 06:39, Walter Bright wrote:
Having used both Ddoc and Markdown, I seriously disagree with this. Take
a look at the markdown source for DIP69. It's horrific.
Do you mean on the wiki? The wiki doesn't use Markdown. At least not anyone
On 12/29/2014 10:34 AM, jklp wrote:
I like your sense of the compromise. DDoc is mostly usefull to generate the doc
as html but inside the sources, it's often **unreadable**. I think that you know
that documentation comments as markdow would be good but maybe you're scared
because of the
On 12/29/2014 5:53 AM, Steven Schveighoffer wrote:
On 12/28/14 4:33 PM, Walter Bright wrote:
inout is not transitive, so a ref on the container doesn't apply to a
ref on the contents if there's another level of indirection in there.
I'm not sure what you mean by this, but inout as a type
On 12/29/14 2:04 PM, Dicebot wrote:
On Monday, 29 December 2014 at 19:00:06 UTC, Andrei Alexandrescu wrote:
I tend to agree. You seem to have shown that reusing inout for scope
information becomes confusing. -- Andrei
What is the problem with using inout exactly as it is now (== both for
On 12/29/2014 3:24 AM, Joseph Rushton Wakeling wrote:
On Monday, 29 December 2014 at 00:50:10 UTC, Walter Bright wrote:
It's already possible. Change the macro definitions in the std.ddoc file.
Sure. But I did think it might be a good idea to discuss things here first
before jumping into
On Mon, 29 Dec 2014 15:36:57 +
Julian Kranz via Digitalmars-d digitalmars-d@puremagic.com wrote:
Uuuhm, you're right, it works :-D I don't completely understand
why the compiler does not require the function to be sonst any
longer...
we must get our big red letters and write somewhere:
On Monday, 29 December 2014 at 19:54:33 UTC, Steven Schveighoffer
wrote:
On 12/29/14 2:04 PM, Dicebot wrote:
On Monday, 29 December 2014 at 19:00:06 UTC, Andrei
Alexandrescu wrote:
I tend to agree. You seem to have shown that reusing inout
for scope
information becomes confusing. -- Andrei
On Monday, 29 December 2014 at 19:51:26 UTC, Walter Bright wrote:
The current defaults make it work without needing a style
sheet. That's pretty much the reason why they are the way they
are.
You could also just bundle a stylesheet with it, which would be
the best of both worlds. Have the
I'd better respond when I will not be as angry and tempted to go
into accusation mode.
On Monday, 29 December 2014 at 19:40:41 UTC, Mathias LANG wrote:
I'm wondering where we currently are on the process of releasing
2.067 ?
The reference page
http://wiki.dlang.org/Beta_Testing#Available_Downloads , is
horribly outdated, as DMD v2.066.1 was released, all known
regressions are
On 2014-12-29 20:48, Walter Bright wrote:
I don't care much for hybrids, they are confusing and ugly.
Markdown already support raw HTML. We could use Markdown but with Ddoc
macros instead of raw HTML.
BTW, Ddoc macros are really ugly.
--
/Jacob Carlborg
Thanks again for all answers :-).
On Monday, 29 December 2014 at 19:57:20 UTC, ketmar via
Digitalmars-d wrote:
On Mon, 29 Dec 2014 15:36:57 +
Julian Kranz via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Uuuhm, you're right, it works :-D I don't completely
understand why the
On 2014-12-29 20:47, Walter Bright wrote:
It uses something pretty similar. They all kinda mush together in my
mind :-(
Don't blame Markdown just because some other markup language you don't
like looks similar to you.
--
/Jacob Carlborg
On Mon, 29 Dec 2014 16:48:45 +
Julian Kranz via Digitalmars-d digitalmars-d@puremagic.com wrote:
Is that really cool? I mean, is wise to have the compiler treat
templates and non-templates differently? C++ has tons of such
inconsistencies which is the main reason I don't really like
On Mon, 29 Dec 2014 20:01:59 +
Julian Kranz via Digitalmars-d digitalmars-d@puremagic.com wrote:
Well, of course you're right; but the thing is - does it really
make sense to have a less powerful semantic for functions here?
Does it help in any way? I mean, if something works just
On Monday, 29 December 2014 at 16:48:46 UTC, Julian Kranz wrote:
Is that really cool? I mean, is wise to have the compiler treat
templates and non-templates differently? C++ has tons of such
inconsistencies which is the main reason I don't really like
C++...
Well, it is reasonable in light
On Monday, 29 December 2014 at 19:34:52 UTC, ketmar via
Digitalmars-d wrote:
please, explain me, *whose* exactly post was disgusting,
selfish and
deluded? 'cause now i'm completely lost.
Ok, i will explain because i think my point should be made clear
and because this thread is giving
On Mon, 29 Dec 2014 20:07:08 +
evenex via Digitalmars-d digitalmars-d@puremagic.com wrote:
Is that really cool? I mean, is wise to have the compiler treat
templates and non-templates differently? C++ has tons of such
inconsistencies which is the main reason I don't really like
On 12/29/14 2:07 PM, anonymous wrote:
On Monday, 29 December 2014 at 13:20:39 UTC, Julian Kranz wrote:
Thank you for your answer. This kind of thing also works for C++, but
that would mean that I would implement the whole visitor twice - one
const and one non-const version. Is that really the
On 12/29/14 3:11 PM, Steven Schveighoffer wrote:
On 12/29/14 2:07 PM, anonymous wrote:
On Monday, 29 December 2014 at 13:20:39 UTC, Julian Kranz wrote:
Thank you for your answer. This kind of thing also works for C++, but
that would mean that I would implement the whole visitor twice - one
On 12/29/14 2:57 PM, Dicebot wrote:
On Monday, 29 December 2014 at 19:54:33 UTC, Steven Schveighoffer wrote:
On 12/29/14 2:04 PM, Dicebot wrote:
On Monday, 29 December 2014 at 19:00:06 UTC, Andrei Alexandrescu wrote:
I tend to agree. You seem to have shown that reusing inout for scope
On 12/29/14 2:50 PM, Walter Bright wrote:
On 12/29/2014 5:53 AM, Steven Schveighoffer wrote:
On 12/28/14 4:33 PM, Walter Bright wrote:
inout is not transitive, so a ref on the container doesn't apply to a
ref on the contents if there's another level of indirection in there.
I'm not sure what
On Mon, 29 Dec 2014 20:09:08 +
Gary Willoughby via Digitalmars-d digitalmars-d@puremagic.com wrote:
D, as a project, already has a firmly entrenched goal and it's
motivation is to reach that goal. Anyone contributing to D must
acknowledge that goal and be prepared to sustain it through
1 - 100 of 241 matches
Mail list logo
