On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei Alexandrescu
wrote:
First off, we're considering eliminating destructor calls from
within the GC entirely. It makes for a faster and better GC,
but the real reason here is that destructors are
philosophically bankrupt in a GC environment. I
On Tuesday, 6 May 2014 at 15:43:22 UTC, Manu via Digitalmars-d
wrote:
I think it's safe to attribute this almost entirely to
the fact it exists in my fork where nobody will find it, rather
than
'exp', where people can still report usage experience,
feedback, and
keep me on track.
As other
On Sunday, 11 May 2014 at 08:59:42 UTC, Walter Bright wrote:
D also cannot be performance competitive with C++ if pervasive
ARC is used and memory safety is retained. Rust is attempting
to solve this problem by using 'borrowed' pointers, but this is
unproven technology, see my reply to Manu
On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
There is very little use of @, it's mostly and ~. Heck
I didn't find any @ while casually browsing the code. It's like
they are not using it at all.
Similarly in current C++ std::shared_ptr is barely there while
std::unique_ptr is
On Monday, 12 May 2014 at 00:44:54 UTC, Andrei Alexandrescu wrote:
On 5/11/14, 2:49 PM, ponce wrote:
On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
There is very little use of @, it's mostly and ~.
Heck I
didn't find any @ while casually browsing the code. It's like
they are
On Monday, 12 May 2014 at 00:44:54 UTC, Andrei Alexandrescu wrote:
On 5/11/14, 2:49 PM, ponce wrote:
On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
There is very little use of @, it's mostly and ~.
Heck I
didn't find any @ while casually browsing the code. It's like
they are
On Thursday, 29 May 2014 at 12:10:23 UTC, Joseph Rushton Wakeling
via Digitalmars-d wrote:
Requiring people to prove themselves in a popularity contest
first seems to me to get in the way of the aim to have a
fast-moving,
able-to-quickly-get-user-feedback-and-make-breaking-changes
part of the
On Thursday, 29 May 2014 at 16:53:53 UTC, Joseph Rushton Wakeling
via Digitalmars-d wrote:
On 29/05/14 18:22, ponce via Digitalmars-d wrote:
Is it really fast moving when you have to wait for compiler
releases? I don't
think so.
Fair point. What I was really trying to say
On Thursday, 29 May 2014 at 19:41:48 UTC, Wyatt wrote:
On Thursday, 29 May 2014 at 19:15:29 UTC, ponce wrote:
Now you have another problem, how do you know that something
looks good from a design point of view for inclusion in
std.experimental? Reviews like for Phobos inclusion?
Especially
On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:
Just thought it would be nice to give a heads up about Apple's
plans to replace Objective-C in the long run.
The language was presented today at the WWDC Keynote, looks
like Ruby, uses ARC alongside the Objective-C runtime.
My thoughts while browsing the site:
- function-leve type inference much like Rust
- no constness in the type-system (I like it)
- class are reference types, structs are values types, much
like D and C#
- runtime dispacthed OO interfaces called protocols. Blend
the difference between runtime
On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:
On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:
- no exceptions (!)
How do they do error handling ?
I guess error codes, a proven technology!
The lack of exceptions put this language firmly in the
irrelevant bracket.
Add that
On Tuesday, 3 June 2014 at 00:57:53 UTC, Chris Cain wrote:
On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:
On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:
- no exceptions (!)
How do they do error handling ?
I haven't read too much into Swift but languages with ADTs,
pattern
On Thursday, 5 June 2014 at 04:35:18 UTC, Russel Winder via
Digitalmars-d wrote:
I think Pike, Cox, et al. disagree; for them exceptions are
only a
termination mechanism and return codes are the way of
communicating. If
Swift has no exceptions, then Apple must be following the Go
model
On Sunday, 15 June 2014 at 21:18:10 UTC, Dicebot wrote:
If spending only reasonable time is in question - oh yes. If
you are eager to spend months of spare time - there are some
possibilities ;) btw ironically this is when I have felt in
love with generic paradigm, with reasoning wow, this
On Monday, 16 June 2014 at 10:39:42 UTC, Chris Cain wrote:
On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote:
Does D have a mature SFML or SDL binding?
http://code.dlang.org/packages/derelict-sfml2
and
http://code.dlang.org/packages/derelict-sdl2
Are available.
I have personally
On Monday, 16 June 2014 at 11:46:57 UTC, Chris Cain wrote:
On Monday, 16 June 2014 at 10:51:11 UTC, ponce wrote:
Ahem, looks like I commited something too early. This is a bug.
In the mean time you can use the ==1.1.1 version.
Actually, sadly, you can't use gfm at all (or, at least, I
can't)
On Monday, 16 June 2014 at 10:24:46 UTC, John Petal wrote:
Are there any advices you can give me?
If nothing can convince you, learning D will make it way easier
to learn C++, and you won't write the same C++ either.
On Tuesday, 17 June 2014 at 04:24:54 UTC, c0de517e wrote:
Hi everybody. I'm Angelo Pesce, the author of the post on
c0de517e.
Hi, I think the general idea of your post is 100% accurate, the
bigger risk for D is people not willing to move from C++. I work
in C++ full-time and it's an
On Thursday, 26 June 2014 at 21:01:40 UTC, Araq wrote:
Spark is a research language that does not work, as I've
discovered and discussed with you before. It cannot be
determined the max stack usage at compile time, again, this is
the halting problem.
What?! It's easily solvable: Forbid
On Saturday, 5 July 2014 at 06:43:31 UTC, Russel Winder via
Digitalmars-d wrote:
All the C++ folk are saying that with C++14 is you are using
any heap at
all you are more than likely doing it wrong. Modern C++ idiom
is for
completely new/delete free code.
Minor nitpick, it is indeed devoid
On Wednesday, 9 July 2014 at 02:44:54 UTC, Walter Bright wrote:
On 7/8/2014 6:01 PM, Mike wrote:
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
1. Ref Counting
I believe that ARC is a pipe dream for D, as we've discussed
extensively here.
But a ref counted object should work,
On Friday, 11 July 2014 at 05:41:50 UTC, Manu via Digitalmars-d
wrote:
I've thought of allowing throw new ..., and yours would be
in addition to
that, in @nogc functions, but was waiting to see how this
would play out a
bit first.
I should add, I'm not sure I see that my case should be 'in
On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:
- D is/has become complex. metaprograming, generics, macros,
etc. This is a culture issue, very hard to fix cultural issues
w/o losing most commiters. Just a fast system lang w/o headers,
'boost' and such. All this other stuff can be 3rd
On Sunday, 13 July 2014 at 12:18:40 UTC, Jacob Carlborg wrote:
On 2014-07-13 13:57, Robert burner Schadek wrote:
Anyone else?
I agree with Sönke.
if I change it back, people will argue that that is redundant
and
unintuitive. Than I will change it back again and the
discussion starts
On Saturday, 12 July 2014 at 16:20:16 UTC, Russel Winder via
Digitalmars-d wrote:
Sad if true, I want the capability to be on the bleeding edge.
If the
possibility of specifying version exists then people who want
hygiene
are covered. Removing the facility of ~master stops those of
use who
On Monday, 14 July 2014 at 17:18:05 UTC, Jeremy Powers via
Digitalmars-d wrote:
We can argue about these things forever, but ultimately all
that really
matters is: does it do what we need? As long as the API works,
and lets
one build fancier functionality underneath, it is good.
(Though,
On Tuesday, 15 July 2014 at 21:28:24 UTC, Walter Bright wrote:
Peek/poke has a 40 year history of being used for MMIO, and
I've never heard of it being used for concurrency. I don't
think there's endemic confusion, quite unlike volatile.
There is a huge confusion about volatile in the native
On Friday, 18 July 2014 at 15:44:21 UTC, Andrei Alexandrescu
wrote:
On 7/17/14, 11:53 PM, Jacob Carlborg wrote:
On 18/07/14 03:55, Israel Rodriguez wrote:
This man has it right. I dont think quality is a huge issue
though
unless youre watching something that needs to be sensitive to
the eye
On Sunday, 20 July 2014 at 16:15:53 UTC, linkrope wrote:
At least in the code of our company, logging a formatted string
is the basic use case.
The function for the basic use case should not require a suffix
letter.
I'm in 100% disagreement. If you don't add the f suffix, users
will write:
On Tuesday, 22 July 2014 at 07:55:04 UTC, Dragos Carp wrote:
I'm in 100% disagreement. If you don't add the f suffix, users
will write:
info(user provided string that could contain format);
This is a crash if the user provided string happens to
contains %s.
I wouldn't use such an API which
On Tuesday, 22 July 2014 at 08:44:06 UTC, linkrope wrote:
On Tuesday, 22 July 2014 at 07:27:38 UTC, ponce wrote:
On Sunday, 20 July 2014 at 16:15:53 UTC, linkrope wrote:
By the way: Instead of what I really need, I get a NullLogger.
I have no clue, why I never ever missed such an oddity.
I
On Tuesday, 22 July 2014 at 10:24:33 UTC, linkrope wrote:
On Tuesday, 22 July 2014 at 09:51:24 UTC, ponce wrote:
On Tuesday, 22 July 2014 at 08:44:06 UTC, linkrope wrote:
On Tuesday, 22 July 2014 at 07:27:38 UTC, ponce wrote:
On Sunday, 20 July 2014 at 16:15:53 UTC, linkrope wrote:
By the
On Monday, 28 July 2014 at 12:43:03 UTC, Dominikus Dittes Scherkl
wrote:
On Sunday, 27 July 2014 at 13:17:42 UTC, Iain Buclaw wrote:
The cent and ucent keywords have been reserved since...
well... certainly before the first D1 (as opposed to D0.xx)
release [2]. But that's all they have ever
On Tuesday, 29 July 2014 at 05:11:33 UTC, Dicebot wrote:
(sorry for being a bit late, was distracted)
std.logger proposal by Robert Schadek enters voting period
which will last two weeks starting from now.
Discussion thread :
http://forum.dlang.org/post/zhvmkbahrqtgkptdl...@forum.dlang.org
On Thursday, 31 July 2014 at 09:13:53 UTC, Walter Bright wrote:
On 7/31/2014 1:23 AM, Daniel Murphy wrote:
Walter Bright wrote in message
news:lrbpvj$mih$1...@digitalmars.com...
5. assert(0); is equivalent to a halt, and the compiler won't
remove it.
This is not the same definition the
On Thursday, 31 July 2014 at 11:01:56 UTC, Marc Schütz wrote:
On Thursday, 31 July 2014 at 10:24:07 UTC, ponce wrote:
If I write:
---
switch(expr())
{
case 0: doIt();
case 1: doThat();
default:
assert(0);
}
---
Will the optimizer be able to remove the default: case?
Assuming fall-through
On Thursday, 31 July 2014 at 19:03:14 UTC, Walter Bright wrote:
It means if the control flow does actually get there, a HALT is
executed.
Fine.
On Thursday, 31 July 2014 at 20:52:30 UTC, Sean Kelly wrote:
On Wednesday, 30 July 2014 at 22:01:23 UTC, Walter Bright wrote:
3. Use of assert to validate input is utterly wrong and will
not be supported. Use such constructs at your own risk.
...
6. enforce() is meant to check for input
API looks great but I'd like to see some simple
serialize/deserialize
functions as in vibed:
http://vibed.org/api/vibe.data.json/deserializeJson
http://vibed.org/api/vibe.data.json/serializeToJson
vibe uses UDAs to customize the serialization output. That's
actually
not json specific and
On Monday, 18 August 2014 at 18:56:42 UTC, b wrote:
Besides that, in C++ it works like this.
90% of objects: value types, on stack or embedded into other
objects
9% of objects: unique types, use unique_ptr, no overhead
~1% of objects: shared, use shared_ptr/weak_ptr etc.
With GC you
On Tuesday, 19 August 2014 at 07:26:07 UTC, ketmar via
Digitalmars-d wrote:
but why?! see 'scoped' to scope allocations. and, for example,
'File',
which is refcounted internally. plus 'scope()' finalizers.
i'm pretty sure that scoped ownership in D at least on par with
C++, if
not better and
On Tuesday, 19 August 2014 at 17:11:21 UTC, bachmeier wrote:
My last interaction with Rust was when I commented that
adoption would be hurt if they require an understanding of the
memory model just to get started, to which they responded more
or less that it's not a big deal. At that point I
On Monday, 25 August 2014 at 22:32:36 UTC, Dicebot wrote:
On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler
wrote:
Hello everyone,
I've been working on SDL support for DUB and wanted to get
some people's opinions on whether we should really use SDL.
I've posted my thoughts here:
On Monday, 25 August 2014 at 19:52:56 UTC, Jonathan Marler wrote:
Maybe if DUB started using it...other tools and software would
look into it?
That was already the idea behind using SDL, since it's seldom
used in the wild.
On Friday, 29 August 2014 at 02:21:07 UTC, Andrei Alexandrescu
wrote:
Dear community, are you ready for this?
Yes! Whatever needs be done.
On Friday, 19 September 2014 at 15:32:38 UTC, Andrei Alexandrescu
wrote:
Please chime in with thoughts.
Coudln't we throw value types instead? (like in C++)
On Saturday, 20 September 2014 at 09:09:38 UTC, Marc Schütz wrote:
On Saturday, 20 September 2014 at 09:05:15 UTC, ponce wrote:
On Friday, 19 September 2014 at 15:32:38 UTC, Andrei
Alexandrescu wrote:
Please chime in with thoughts.
Coudln't we throw value types instead? (like in C++)
But
On Saturday, 20 September 2014 at 16:41:20 UTC, Andrei
Alexandrescu wrote:
On 9/20/14, 2:05 AM, ponce wrote:
On Friday, 19 September 2014 at 15:32:38 UTC, Andrei
Alexandrescu wrote:
Please chime in with thoughts.
Coudln't we throw value types instead? (like in C++)
My knee-jerk reaction is
On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
What do you think are the worst parts of D?
Proper D code is supposed to have lots of attributes (pure const
nothrow @nogc) that brings little and makes it look bad.
On Wednesday, 24 September 2014 at 05:44:15 UTC, ketmar via
Digitalmars-d wrote:
On Tue, 23 Sep 2014 21:59:53 -0700
Brad Roberts via Digitalmars-d digitalmars-d@puremagic.com
wrote:
I understand quite thoroughly why c++ support is a big win
i believe it's not.
Every C++ shop I've been
On Friday, 26 September 2014 at 18:29:15 UTC, David Gileadi wrote:
On 9/26/14, 11:25 AM, Walter Bright wrote:
I see the Apple blog did mention D. A glorious exception!
Which is odd because Swift doesn't support exception handling :)
From what I got on release Swift is quite odd:
- regular
On Friday, 19 September 2014 at 23:47:06 UTC, Max Klyga wrote:
Jonathan Blow just recorded a talk about the needs and ideas
for a programming language for game developer.
https://www.youtube.com/watch?v=TH9VCN6UkyQ
This talk mentions D quite a lot of times.
D is mentioned as the most probable
On Sunday, 28 September 2014 at 12:24:23 UTC, Dicebot wrote:
Previous review thread :
http://forum.dlang.org/post/zhvmkbahrqtgkptdl...@forum.dlang.org
Previous voting thread (also contains discussion in the end) :
http://forum.dlang.org/post/vbotavcclttrgvzcj...@forum.dlang.org
Code :
On Monday, 13 October 2014 at 08:29:42 UTC, 岩倉 澪 wrote:
From what I've found, there was some work on this in the past
(http://forum.dlang.org/thread/wokfqqbexazcguffw...@forum.dlang.org?page=6#post-thclpgdlfxxhhfklwsoj:40forum.dlang.org),
but a pull request was never made/I don't seem to find
On Monday, 13 October 2014 at 08:53:28 UTC, Peter Alexander wrote:
Looks like Bjarne has proposed UFCS for C++
http://isocpp.org/files/papers/N4174.pdf
No mention of D though...
UFCS could be fun in C++ with dependence on import order and the
best-match rule.
I feel like we need a NG thread for D users to come and ask for
new libraries/bindings.
Express your needs! Here are mines.
1. A windowing library to replace some of SDL usage. Some
programs like audio plugins are usually done without any
dependent dynamic library. It could also make one
On Wednesday, 22 October 2014 at 08:25:25 UTC, Rikki Cattermole
wrote:
On 22/10/2014 9:13 p.m., ponce wrote:
I feel like we need a NG thread for D users to come and ask
for new
libraries/bindings.
Express your needs! Here are mines.
1. A windowing library to replace some of SDL usage. Some
On Wednesday, 22 October 2014 at 19:49:48 UTC, Jacob Carlborg
wrote:
On 2014-10-22 10:13, ponce wrote:
2. A binary serialization library that support versions of
data schemes.
Would allow to load previous versions of data when the scheme
has
changed and fields have been added/removed.
On Wednesday, 22 October 2014 at 15:11:39 UTC, Adam D. Ruppe
wrote:
On Wednesday, 22 October 2014 at 08:13:20 UTC, ponce wrote:
1. A windowing library to replace some of SDL usage.
My simpledisplay.d is aimed to do some of this.
https://github.com/adamdruppe/arsd
It also depends on my
On Wednesday, 29 October 2014 at 04:37:47 UTC, Walter Bright
wrote:
http://www.codergears.com/Blog/?p=421
This is interesting as it relates to D's choices:
1. No common build system ,Visual Studio, make and CMake are
the most widely used
D - no change.
2. Namesapces not widely used
D -
On Wednesday, 29 October 2014 at 19:38:16 UTC, dan wrote:
What IDE/EDITOR do you use for D? What plugins if you use Vim?
VisualD + vanilla Sublime Text for heavy editing.
On Saturday, 1 November 2014 at 11:31:32 UTC, bearophile wrote:
Third part of the A Programming Language for Games, by
Jonathan Blow:
https://www.youtube.com/watch?v=UTqZNujQOlA
Discussions:
http://www.reddit.com/r/programming/comments/2kxi89/jonathan_blow_a_programming_language_for_games/
Hi,
First, I'd like to point out this question is better asked in
DerelictBgfx issues or digitalmars.D.learn, this NG is for
general D discussion.
On Thursday, 6 November 2014 at 06:44:49 UTC, olivier henley
wrote:
Hi,
May I ask what is the rational to not ship the core libs with
the
On Thursday, 6 November 2014 at 16:36:41 UTC, olivier henley
wrote:
First, I'd like to point out this question is better asked in
DerelictBgfx issues or digitalmars.D.learn, this NG is for
general D discussion.
Not agree. DerelictBgfx is one of the most interesting project
D has to show off
I think there is a misunderstanding: bgfx _examples_ are kind
of cool, but they were only ported for basic testing of the
bindings, and maybe should be removed now to avoid rot.
I just don't see the point to not share the most common target
dependencies libs. Therefore the examples can run out of the
box for most people and some super cool project can be show
cased for D rapidly. This leads to hooking. That's it that's
all and this is the key.
Common libraries
On Thursday, 6 November 2014 at 19:35:27 UTC, olivier henley
wrote:
On Thursday, 6 November 2014 at 17:23:21 UTC, ponce wrote:
There were PR since to update to latest API so these binaries
would be outdated already.
This would be easier if bgfx had numbered releases and its API
changed
On Wednesday, 12 November 2014 at 09:56:57 UTC, Paulo Pinto
wrote:
On Wednesday, 12 November 2014 at 08:55:30 UTC, deadalnix wrote:
On Wednesday, 12 November 2014 at 08:38:14 UTC, Ola Fosheim
In addition, the whole
CPU industry is backpedaling on the transactional memory
concept. That is
On Wednesday, 12 November 2014 at 11:19:59 UTC, Ola Fosheim
Grøstad wrote:
STM = software based transactional memory (without hardware
support)
I was meaning HTM instead, good catch.
Haswell does not have buffered transactions so you wait for the
commit, but there are presentations out where
On Sunday, 16 November 2014 at 13:39:24 UTC, FrankLike wrote:
Many old projects need move from x86 to x64,but the 'length'
type is size_t,it will change on x64,so a lot of work must to
do.but I find some info which is help for d:
http://www.dotnetperls.com/array-length.
it means:
test length
On Monday, 17 November 2014 at 23:14:32 UTC, Vladimir Panteleev
wrote:
Would you trade 0.1% in performance for a better debugging
experience?
Yes, of course. In most programs, a day of work can give = 1%
speed-up, and debugging can take many more.
On Tuesday, 25 November 2014 at 01:12:03 UTC, Walter Bright wrote:
On 11/24/2014 4:51 PM, Brian Schott wrote:
On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright
wrote:
Anyone know anything about this?
https://www.reddit.com/r/programming/comments/2n9gfb/d_is_for_data_science/cmbssac
On Tuesday, 3 September 2013 at 13:41:09 UTC, Andrej Mitrovic
wrote:
So I suggest the dsource WinAPI team to move to Github (or
maybe some
other more visible hosting service like Bitbucket).
That way people can use submodules, and they can also use Dub
if the
dev team adds this support.
Using the fact that a negative 64-bit integer is also a negative
32-bit integer when truncated, you could use 2x SSE2 32-bit
comparison.
- one for [v0 , v1] - [vlow, vlow] compared to [0, 0] (result
should be = 0, signed comparison)
- one for [v0 , v1] - [vhigh, vhigh] compared to [0, 0]
On Monday, 8 December 2014 at 16:57:20 UTC, ponce wrote:
Using the fact that a negative 64-bit integer is also a
negative 32-bit integer when truncated,
Oops. This assumption is wrong.
On Monday, 8 December 2014 at 22:37:08 UTC, ponce wrote:
vresult - mask 31 (for each dword)
Correction:
vresult - mask 63 (for each qword)
On Monday, 8 December 2014 at 16:32:50 UTC, Martin Nowak wrote:
I want to do bounds checking of 2 (4 on avx) ulongs (64-bit) at
a time.
ulong2 vval = [v0, v1];
ulong2 vlow = [low, low];
ulong2 vhigh = [high, high];
int res = PMOVMSKB(vval = vlow vval vhigh);
I figured out sort of a
On Friday, 12 December 2014 at 11:58:04 UTC, Martin Nowak wrote:
On 12/11/2014 10:34 PM, Walter Bright wrote:
D already does this. It's been said before, Jonathan is
reinventing D,
piece by piece :-)
What does that mean, it's been said?
Didn't anyone actually try to tell him about D?
I
On Sunday, 14 December 2014 at 10:31:29 UTC, Paolo Invernizzi
wrote:
We are using Vibe also here in Milan: it's maintained since a
long time, and it has plenty of adopters, but... it's just too
big.
Sönke is doing a remarkable job, but, for example, I've a mail
server in production using vibe
On Monday, 15 December 2014 at 10:46:30 UTC, Dicebot wrote:
I don't plan it and don't realistically ever expect it.
Considering the fact that game development industry is
traditionally one of the worst in contributing upstream I also
don't have any motivation to convince them adopt D.
If
On Monday, 15 December 2014 at 11:12:55 UTC, Stephan Schiffels
wrote:
3.) Most of the memory is used in one huge array, perhaps I
should simply use malloc and free for that particular array to
avoid the GC from running so often.
Yes. That way you know with certainty the GC won't scan it.
On Saturday, 20 December 2014 at 12:39:01 UTC, Bienlein wrote:
This way a lot of people out there have built server side
systems with Go in record time. All the startups using Go are
proof for this.
I would be wary of extrapolating best practices from what
startups do.
Startups succeed when
On Saturday, 20 December 2014 at 14:06:51 UTC, Paulo Pinto wrote:
That is why I seldom buy into hype driven development.
Usually on our teams if a specific technology wasn't explicitly
requested by the customer, whoever is bringing it in has to
answer what is the business value to the
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 Thursday, 1 January 2015 at 14:16:05 UTC, Adam D. Ruppe wrote:
On Thursday, 1 January 2015 at 10:10:53 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
My problem is very much the opposite: it's not that only ddoc
can process ddoc syntax, it's that raw ddoc syntax is, often,
not very
On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via
Digitalmars-d wrote:
I've been working on a pretty comprehensive module for dealing
with
colours in various formats and colour spaces and conversions
between
all of these.
It seems like a hot area for duplicated effort, since anything
that
On Thursday, 1 January 2015 at 14:41:00 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
On 01/01/15 15:26, Adam D. Ruppe via Digitalmars-d wrote:
Again those are: *bold* and `code`.
I would be inclined to prefer ``code`` or ```code```, simply
because it's valid D syntax to have,
On Thursday, 1 January 2015 at 15:46:07 UTC, Manu via
Digitalmars-d wrote:
On 2 January 2015 at 01:09, ponce via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via
Digitalmars-d wrote:
I've been working on a pretty comprehensive module
On Wednesday, 21 January 2015 at 19:51:57 UTC, Walter Bright
wrote:
I can't say, but it's undeniable what people consider modern.
(I like the older style, as it is denser and easier to
navigate.)
I'm not a big fan of these sites either, but because of
association with bold marketing.
As I
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be
So. I've reported lots of bugs in DUB and fixed some, and since
using it I never looked back. It does seem more stable these days.
On Monday, 2 February 2015 at 08:09:39 UTC, Vladimir Panteleev
wrote:
So, in order to start using Dub, I'd need to:
- restructure the directory layout of my
On Monday, 2 February 2015 at 00:35:14 UTC, deadalnix wrote:
Fast compile time, bearable syntax, thread safety arc so on...
C++ is building on faulty foundation. I see them talking
example from us as a good news.
I don't see any way writing C++ could become a much better
experience than
On Monday, 2 February 2015 at 09:25:31 UTC, Mathias LANG wrote:
On Monday, 2 February 2015 at 09:03:56 UTC, Vladimir Panteleev
wrote:
Is that so? Won't a security fix entail a version bump,
requiring a change in the requirements file of the parent
project? Also, does Dub really check for
On Monday, 2 February 2015 at 10:13:27 UTC, Vladimir Panteleev
wrote:
On Monday, 2 February 2015 at 10:09:00 UTC, Joseph Rushton
Wakeling wrote:
Well, as long as the requirements are expressed in the form,
package-name: =1.2.3
This will allow Dub to pick a new major version with
On Monday, 2 February 2015 at 13:10:56 UTC, Mike Parker wrote:
On 2/2/2015 7:13 PM, Vladimir Panteleev wrote:
On Monday, 2 February 2015 at 10:09:00 UTC, Joseph Rushton
Wakeling wrote:
Well, as long as the requirements are expressed in the form,
package-name: =1.2.3
This will allow Dub
On Monday, 2 February 2015 at 16:56:56 UTC, ponce wrote:
A = B = C v1.2.3
A = D = C v1.3.6
Even if C v1.2.3 and v1.3.6 are API-compatible, you can't build
A if you don't control both B and C.
So, version ranges are necessary for an ecosystem of libraries.
Erratum: if you don't control both
On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright wrote:
The solution is to regard @trusted as a means of encapsulating
unsafe operations, not escaping them. Encapsulating them means
that the interface from the @trusted code is such that it is
usable from safe code without having to
On Saturday, 7 February 2015 at 10:02:23 UTC, ponce wrote:
If I understand correctly, your rule o be a trusted function is:
Unable to create a memory corrutpion whatever the arguments.
But here:
- dest or src could be the null slice
- the assert would go away in release
So I though this
On Tuesday, 3 February 2015 at 08:54:04 UTC, ketmar wrote:
On Tue, 03 Feb 2015 02:44:01 +, Martin Nowak wrote:
I'm often literally baffled that people don't even try to fix
obviously
trivial bugs.
maybe that's 'cause they have their work to do, and fixing bugs
in dub is
not a part of
1 - 100 of 480 matches
Mail list logo
