On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky wrote:
Well, I think interesting part we're trying to look at here is
the ARC's impact on speed.
ARC without deep whole program analysis is bound to be slow. It
turns reads into writes. You even have to do writes to access
read-only da
On Tuesday, 17 June 2014 at 03:08:48 UTC, Walter Bright wrote:
Assuming you are talking about C macros:
I was talking about macros in general. :-)
expert on the C preprocessor." Why would a freakin' macro
processor even have an ecological niche for a world leading
expert on it? The mind bogg
On Monday, 16 June 2014 at 21:47:22 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Mon, Jun 16, 2014 at 01:31:21PM -0700, H. S. Teoh via
Digitalmars-d wrote:
On Mon, Jun 16, 2014 at 06:37:56PM +, Wyatt via
Digitalmars-d wrote:
> On Monday, 16 June 2014 at 17:52:29 UTC, H. S. Teoh via
> Digital
On 17/06/2014 7:59 p.m., monarch_dodra wrote:
On Monday, 16 June 2014 at 21:47:22 UTC, H. S. Teoh via Digitalmars-d
wrote:
On Mon, Jun 16, 2014 at 01:31:21PM -0700, H. S. Teoh via Digitalmars-d
wrote:
On Mon, Jun 16, 2014 at 06:37:56PM +, Wyatt via Digitalmars-d wrote:
> On Monday, 16 June
On 6/16/2014 9:24 PM, c0de517e wrote:
Hi everybody. I'm Angelo Pesce, the author of the post on c0de517e.
Welcome - nice of you to drop by!
On 6/16/2014 10:02 PM, Manu via Digitalmars-d wrote:
Granted. I don't really understand the situation well enough to
comment with any authority. What are the conditions that create the
requirement, or could relax it?
inc
try {
... code that may throw an exception ...
}
finally {
dec;
}
On 6/16/2014 10:30 PM, Nick Sabalausky wrote:
is this a cost that would *always* be paid,
Yes.
I've probably written 30+ posts explaining this again and again. Nobody believes
me. I beg you to write some code and disassemble it and see for yourself.
On 17/06/14 06:44, H. S. Teoh via Digitalmars-d wrote:
String mixins? Auto-completion? I dunno, that sounds like a stretch to
me. How would an IDE handle autocompletion for things like like:
string generateCode() {
string code = "int x=";
if (solveFermats
On 6/17/2014 2:56 AM, "Ola Fosheim Grøstad"
" wrote:
On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky wrote:
Well, I think interesting part we're trying to look at here is the
ARC's impact on speed.
ARC without deep whole program analysis is bound to be slow.[...]
Right, but what I'
On Tuesday, 17 June 2014 at 08:23:08 UTC, Jacob Carlborg wrote:
That would require semantic analysis. Basically evaluate the
string mixin and to autocomplete on the resulted code.
But consider something like gofix/dfix where you have to
propagate changes back to the original prefix string. Wha
On Tuesday, 17 June 2014 at 08:36:10 UTC, Nick Sabalausky wrote:
But even if nothing else, Manu's certainly right about one
thing: What we need is some hard empirical data.
Sure. Empirical data is needed on many levels:
1. How fast can you get the GC if you exploit all possibilities
for seman
Walter Bright:
But it is not uninitialized. All out parameters are default
initialized to their .init value.<
I don't agree with this opinion, as they *are* initialized.<
The documentation of Microsoft SAL2, several discussions, and
some other things I've read tell me that if you want your
On 6/17/2014 4:23 AM, Walter Bright wrote:
On 6/16/2014 10:30 PM, Nick Sabalausky wrote:
is this a cost that would *always* be paid,
Yes.
I've probably written 30+ posts explaining this again and again. Nobody
believes me. I beg you to write some code and disassemble it and see for
yourself.
On Tuesday, 17 June 2014 at 08:55:52 UTC, bearophile wrote:
Walter Bright:
But it is not uninitialized. All out parameters are default
initialized to their .init value.<
I don't agree with this opinion, as they *are* initialized.<
[...]
void foo(out int x) {}
void bar(out int x) { x = 10; }
On 6/17/2014 1:59 AM, Nick Sabalausky wrote:
It's not that I don't believe you, I guess I must have just missed a lot of
those posts, or probably glanced through them too quickly. I'm more interested
in this topic now than I was before, so I'm just trying to get up to speed (so
to speak). I'll tr
On 6/17/2014 4:43 AM, "Ola Fosheim Grøstad"
" wrote:
On Tuesday, 17 June 2014 at 08:23:08 UTC, Jacob Carlborg wrote:
That would require semantic analysis. Basically evaluate the string
mixin and to autocomplete on the resulted code.
But consider something like gofix/dfix where you have to prop
On Monday, 16 June 2014 at 13:53:39 UTC, Byron Heads wrote:
Does github link issues with pull requests (and the
conversation) and
commits? Does it link issues with sub issues/tasks? Can
Issues link to
other repos (link issues that are in both runtime and std lib)?
If it
does have these featu
What if x is an "optional" out parameter: EG: something you
only set if other conditions are met? Do you want to make sure
that x is at least assigned to once, or rather make it an error
to have a control path that *doesn't* assign anything to it.
Either way:
1. Making it an error to have
I think D2 has too many competing features to experiment, so an
experimental D-- implemented in D2 would be most interesting
IMO. But it takes a group effort… :-/
What's the point? Nimrod already exists and answers most of your
questions. If only you would know how to ask...
On 6/17/2014 1:55 AM, bearophile wrote:
Walter Bright:
But it is not uninitialized. All out parameters are default initialized to
their .init value.<
I don't agree with this opinion, as they *are* initialized.<
The documentation of Microsoft SAL2, several discussions, and some other things
I'
On 6/17/2014 5:10 AM, Walter Bright wrote:
On 6/17/2014 1:59 AM, Nick Sabalausky wrote:
Keep in mind, for people in certain areas, the allure of a memory
management
system with no/minimal collection pauses, minimized memory
requirements and good
behavior in low-memory conditions (even if it all
On 17 June 2014 10:24, Walter Bright via Digitalmars-d
wrote:
> On 6/17/2014 1:55 AM, bearophile wrote:
>>
>> Walter Bright:
>>
>>> But it is not uninitialized. All out parameters are default initialized
>>> to
>>> their .init value.<
>>> I don't agree with this opinion, as they *are* initialized.
On Tuesday, 17 June 2014 at 09:10:14 UTC, Walter Bright wrote:
On 6/17/2014 1:59 AM, Nick Sabalausky wrote:
Oh, I totally understand where it's coming from. I'm trying to
point out that ARC is not a magic zero-cost system. Its costs
are SUBSTANTIAL. But in order to understand those costs, it i
On 6/16/2014 9:32 PM, H. S. Teoh via Digitalmars-d wrote:
Do string mixins have scoping of names?
Yes, of course, since they are D code.
And how would you syntax-highlight a string mixin that's assembled from
arbitrary string fragments?
You wouldn't need to, since the text editor sees only
Walter Bright:
and D's 'out' has nothing to do with strictness.<
Strictness is how a language handles every own feature :-)
Frankly, I think D's parameter classes and array slices are far
simpler and more effective than SAL2.<
I have not used SAL so I can't tell. It has nonnull compile-ti
Walter:
and D's 'out' has nothing to do with strictness.<
I think Ada requires all out arguments to be initialized manually
inside the function.
Bye,
bearophile
On Tue, 17 Jun 2014 15:02:32 +1000
Manu via Digitalmars-d wrote:
> I can't imagine exceptions would appear in hot code very often/ever?
They could definitely appear in hot code if the exception is for a case that
is very rare, but it's certainly true that if an exception is likely to be
thrown f
Am 17.06.2014 11:30, schrieb Walter Bright:
And how would you syntax-highlight a string mixin that's assembled from
arbitrary string fragments?
You wouldn't need to, since the text editor sees only normal D code.
the text editor sees just D-code-Strings - so no syntax-highlight except
that
On Tue, 17 Jun 2014 07:12:46 +0100
Russel Winder via Digitalmars-d wrote:
> On Mon, 2014-06-16 at 11:10 +, Kiith-Sa via Digitalmars-d wrote:
> > If you see "abandoned libraries", you're probably looking at
> > DSource, which is dead. Everything has long since moved to GitHub.
>
> If true, the
On Tue, 17 Jun 2014 02:24:43 -0700
Walter Bright via Digitalmars-d wrote:
> On 6/17/2014 1:55 AM, bearophile wrote:
> > Walter Bright:
> >
> I see it as annoying and nothing to do with 'strictness'. D default
> initializes all variables that don't have an explicit initializer.
> This is normal fo
Walter Bright:
How much often do I need to write a function like foo?
I think it's uncommon.
I suspect that is a guess.
I have just studied all usages of out arguments in my code, and I
have never left an out argument uninitialized inside the function
body. When I use an out argument, I al
On Tuesday, 17 June 2014 at 09:24:32 UTC, Araq wrote:
What's the point? Nimrod already exists and answers most of your
questions. If only you would know how to ask...
If you know the answers then I am an eager listener. Go ahead! :-)
But isn't Nimrod a source-2-source compiler/translator?
In
On Tuesday, 17 June 2014 at 09:17:21 UTC, Nick Sabalausky wrote:
I think you're hitting on the fundamental limitations of
automated code-updating tools here: They can't be treated as
trusted black-boxes.
I don't think this is a fundamental limitation of tools, but a
consequence of language de
On 17 June 2014 18:18, Walter Bright via Digitalmars-d
wrote:
> On 6/16/2014 10:02 PM, Manu via Digitalmars-d wrote:
>
>> I can't imagine exceptions would appear in hot code very often/ever?
>
>
> I've tried to explain this to you for months. You don't believe my
> explanations, we just go round i
On Tue, 2014-06-17 at 03:32 -0700, Jonathan M Davis via Digitalmars-d
wrote:
[…]
> It's well known by the D community that most of dsource is abandoned and
> useless at this point, but as I understand it, no one knows how to get ahold
> of the fellow who runs it, so that makes it very difficult to
On Tuesday, 17 June 2014 at 10:25:39 UTC, dennis luehring wrote:
Am 17.06.2014 11:30, schrieb Walter Bright:
And how would you syntax-highlight a string mixin that's
assembled from
arbitrary string fragments?
You wouldn't need to, since the text editor sees only normal D
code.
the text e
On Tuesday, 17 June 2014 at 10:25:39 UTC, dennis luehring wrote:
Am 17.06.2014 11:30, schrieb Walter Bright:
And how would you syntax-highlight a string mixin that's
assembled from
arbitrary string fragments?
You wouldn't need to, since the text editor sees only normal D
code.
the text e
C# forces you to set a default value for out parameters, and I
personally find it annoying. The very nature of out parameters is
often that you use it in a situation where there *may* be a
result. Again using a C# example, 'bool
Dictionary.TryGetValue(key, out foo)'. I don't care what the
valu
On 17 June 2014 18:36, Nick Sabalausky via Digitalmars-d
wrote:
> On 6/17/2014 2:56 AM, "Ola Fosheim Grøstad"
> " wrote:
>>
>> On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky wrote:
>>>
>>> Well, I think interesting part we're trying to look at here is the
>>> ARC's impact on speed.
>>
>
On Tuesday, 17 June 2014 at 11:59:23 UTC, Manu via Digitalmars-d
wrote:
On 17 June 2014 18:36, Nick Sabalausky via Digitalmars-d
wrote:
On 6/17/2014 2:56 AM, "Ola Fosheim Grøstad"
" wrote:
On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky
wrote:
Well, I think interesting part we're
On 16/06/14 17:16, Manu via Digitalmars-d wrote:
What say you to that, Walter?
Apple have committed to pervasive ARC, which you consistently argue is
not feasible...
Have I missed something, or is this a demonstration that it is
actually practical?
I think Swift is only intended for high level
On Tuesday, 17 June 2014 at 10:32:57 UTC, Jonathan M Davis via
Digitalmars-d wrote:
but as I understand it, no one knows how to get ahold of the
fellow who runs it
Nah, it's pretty simple. Just send him an email. I did this some
time last year, and even posted to the NG about it.
that make
On 17/06/14 05:18, Walter Bright wrote:
Note that Swift seems to not do exceptions (I may be wrong, again, I
know little about Swift), which is one way to avoid that problem.
It does not support exceptions.
--
/Jacob Carlborg
On 17 June 2014 22:26, w0rp via Digitalmars-d
wrote:
> On Tuesday, 17 June 2014 at 00:22:55 UTC, Manu via Digitalmars-d wrote:
>>
>>
>> -Ofast seems to perform the same as C++. -Ofast allegedly does
>> basically what '-release -noboundscheck' does. You'd never try and
>> benchmark D code without t
On Tuesday, 17 June 2014 at 12:10:13 UTC, Jacob Carlborg wrote:
On 16/06/14 17:16, Manu via Digitalmars-d wrote:
What say you to that, Walter?
Apple have committed to pervasive ARC, which you consistently
argue is
not feasible...
Have I missed something, or is this a demonstration that it is
On Monday, 16 June 2014 at 20:32:57 UTC, H. S. Teoh via
Digitalmars-d wrote:
Another recent "enterprise" nastiness I ran into: having
several functions with identical name in the source tree, each
of which does something completely different, and which one
ends up in the executable depends on wh
On Tuesday, 17 June 2014 at 00:22:55 UTC, Manu via Digitalmars-d
wrote:
On 17 June 2014 10:08, deadalnix via Digitalmars-d
wrote:
On Monday, 16 June 2014 at 15:16:44 UTC, Manu via
Digitalmars-d wrote:
What say you to that, Walter?
Apple have committed to pervasive ARC, which you consistently
On 06/17/14 11:30, Walter Bright via Digitalmars-d wrote:
> On 6/16/2014 9:32 PM, H. S. Teoh via Digitalmars-d wrote:
>
>> And how would you syntax-highlight a string mixin that's assembled from
>> arbitrary string fragments?
>
> You wouldn't need to, since the text editor sees only normal D code
On 6/16/14, 10:09 PM, Jesse Phillips wrote:
On Sunday, 15 June 2014 at 15:37:22 UTC, Andrew Edwards wrote:
Observe the following truths:
1) Issue tricking and resolution are kept separate in our community
2) That which is not visible garners no attention
Your message has not convinced
On Tuesday, 17 June 2014 at 13:13:00 UTC, Artur Skawina via
Digitalmars-d wrote:
artur (who implemented both features last weekend; it started
out as a
fun "let's-see-how-D-would-look-if-it-had-this"-project, but
after making
them work and then converting a few small programs, almost
immediatel
On 06/17/2014 02:02 AM, Walter Bright wrote:
On 6/16/2014 3:51 PM, bearophile wrote:
test.d(1,21): Error: uninitialised out argument of 'test3.foo' function
But it is not uninitialized. All out parameters are default initialized
to their .init value.
struct S{ @disable this(); }
void foo(ou
Timon Gehr:
struct S{ @disable this(); }
void foo(out S s){} // ?
If you compile this code:
struct Foo {
@disable this();
}
void foo(out Foo x) {}
void main() {}
Gives a good error message (with a typo):
test.d(4): Error: cannot have out parameter of type Foo because
the default cons
On Tuesday, 17 June 2014 at 13:24:11 UTC, Dicebot wrote:
On Tuesday, 17 June 2014 at 13:13:00 UTC, Artur Skawina via
Digitalmars-d wrote:
artur (who implemented both features last weekend; it started
out as a
fun "let's-see-how-D-would-look-if-it-had-this"-project, but
after making
them work an
On 16/06/14 12:24, John Petal wrote:
Does D have a mature and cross-platform GUI library?
I would recommend DWT [1], although it currently doesn't work on OS X
(I'm working on that).
[1] https://github.com/d-widget-toolkit/dwt
--
/Jacob Carlborg
http://www.unicode.org/versions/Unicode7.0.0/
On Tuesday, 17 June 2014 at 13:36:48 UTC, John Colvin wrote:
On Tuesday, 17 June 2014 at 13:24:11 UTC, Dicebot wrote:
On Tuesday, 17 June 2014 at 13:13:00 UTC, Artur Skawina via
Digitalmars-d wrote:
artur (who implemented both features last weekend; it started
out as a
fun "let's-see-how-D-woul
On Tue, 17 Jun 2014 09:23:50 -0400, Andrew Edwards
wrote:
On 6/16/14, 10:09 PM, Jesse Phillips wrote:
On Sunday, 15 June 2014 at 15:37:22 UTC, Andrew Edwards wrote:
Observe the following truths:
1) Issue tricking and resolution are kept separate in our community
2) That which is not
On Tuesday, 17 June 2014 at 13:36:48 UTC, John Colvin wrote:
also, foreach that works outside of function scope would be
awesome:
mixin template A(TL ...)
{
foreach(i, T; TL)
{
mixin("T v" ~ i.to!string);
}
}
It is not "also", it is primary use case of
On Tuesday, 17 June 2014 at 13:52:48 UTC, Dicebot wrote:
On Tuesday, 17 June 2014 at 13:36:48 UTC, John Colvin wrote:
also, foreach that works outside of function scope would be
awesome:
mixin template A(TL ...)
{
foreach(i, T; TL)
{
mixin("T v" ~ i.to!string);
Understood... Sorry for the noise.
On 6/17/14, 9:53 AM, Steven Schveighoffer wrote:
On Tue, 17 Jun 2014 09:23:50 -0400, Andrew Edwards
wrote:
On 6/16/14, 10:09 PM, Jesse Phillips wrote:
On Sunday, 15 June 2014 at 15:37:22 UTC, Andrew Edwards wrote:
Observe the following truths:
1) Issue
On Tue, 17 Jun 2014 01:02:32 -0400, Manu via Digitalmars-d
wrote:
On 17 June 2014 13:18, Walter Bright via Digitalmars-d
wrote:
On 6/16/2014 5:48 PM, Manu via Digitalmars-d wrote:
Hmmm, I still don't buy it,
I know, but you also have not responded to my explanation of why. Such
as
t
On Tuesday, 17 June 2014 at 13:23:48 UTC, Andrew Edwards wrote:
The argument I'm hearing from the majority (at least those who
choose to respond) is "too much work for minimal gain."
I stand by the point that gain is not minimal, it is actually
negative. Loss of power search tools is huge damag
On Tuesday, 17 June 2014 at 13:23:48 UTC, Andrew Edwards wrote:
The issue I'm trying to solve is to make "issues" more visible
to people who work on them. By putting those issues in the same
location where developers work, they immediately become more
visible. Does it solve the overall problem?
On Tuesday, 17 June 2014 at 14:00:44 UTC, John Colvin wrote:
I though the primary use of static foreach was to force the
compiler to attempt compile-time iteration even for
non-TemplateArgList arguments like arrays known at compile-time
If static foreach acts as code generator there is no pract
On 06/17/2014 04:00 PM, John Colvin wrote:
I though the primary use of static foreach was to force the
compiler to attempt compile-time iteration even for
non-TemplateArgList arguments like arrays known at compile-time
e.g.
static foreach(el; [1,2,3,4])
{
pragma(msg, el);
}
or
static f
On 6/17/14, 10:32 AM, Jesse Phillips wrote:
On Tuesday, 17 June 2014 at 13:23:48 UTC, Andrew Edwards wrote:
The issue I'm trying to solve is to make "issues" more visible to
people who work on them. By putting those issues in the same location
where developers work, they immediately become more
On 06/17/2014 03:36 PM, John Colvin wrote:
also, foreach that works outside of function scope would be awesome:
mixin template A(TL ...)
{
foreach(i, T; TL)
{
mixin("T v" ~ i.to!string);
}
}
Also, identifier mixins might then somewhat clean up a lot of code. The
cas
17-Jun-2014 17:43, dennis luehring пишет:
http://www.unicode.org/versions/Unicode7.0.0/
OMG
The "good" news is we haven't implemented yet the collation algorithm,
so no need to re-implement it! :)
P.S. Seriously we should be good to go, with a minor semi-automated
update to std.uni tables.
Is there any particular reason why this is accepted? (I
introduced it by mistake):
void foo(int = 3) {}
I guess it could be useful to ensure binary compatibility when
you expect to add the parameter later?
On Tue, 17 Jun 2014 11:15:43 -0400, Luís Marques
wrote:
Is there any particular reason why this is accepted? (I
introduced it by mistake):
void foo(int = 3) {}
I guess it could be useful to ensure binary compatibility when
you expect to add the parameter later?
Of course this should
On Tue, 17 Jun 2014 11:19:46 -0400, Steven Schveighoffer
wrote:
Of course this should be accepted.
I want to apologize, that came out sounding condescending, I didn't mean
it that way.
-Steve
On Tuesday, 17 June 2014 at 15:25:22 UTC, Steven Schveighoffer
wrote:
Of course this should be accepted.
I want to apologize, that came out sounding condescending, I
didn't mean it that way.
No problem. Thanks for clarifying this for me, I was just wanted
to understand if/why this was useful
On Tue, Jun 17, 2014 at 11:16:22AM +, via Digitalmars-d wrote:
> On Tuesday, 17 June 2014 at 09:17:21 UTC, Nick Sabalausky wrote:
> >I think you're hitting on the fundamental limitations of automated
> >code-updating tools here: They can't be treated as trusted
> >black-boxes.
>
> I don't thin
On Tue, 17 Jun 2014 15:27:16 +0200
Timon Gehr via Digitalmars-d wrote:
> On 06/17/2014 02:02 AM, Walter Bright wrote:
> > On 6/16/2014 3:51 PM, bearophile wrote:
> >> test.d(1,21): Error: uninitialised out argument of 'test3.foo'
> >> function
> >
> > But it is not uninitialized. All out paramete
On Tue, Jun 17, 2014 at 06:56:11AM +, via Digitalmars-d wrote:
> On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky wrote:
> >Well, I think interesting part we're trying to look at here is the ARC's
> >impact on speed.
>
> ARC without deep whole program analysis is bound to be slow.
[..
On Tue, Jun 17, 2014 at 09:36:09PM +1000, Manu via Digitalmars-d wrote:
> On 17 June 2014 18:18, Walter Bright via Digitalmars-d
> wrote:
> > On 6/16/2014 10:02 PM, Manu via Digitalmars-d wrote:
> >
> >> I can't imagine exceptions would appear in hot code very
> >> often/ever?
> >
> >
> > I've tri
Am 17.06.2014 16:58, schrieb Dmitry Olshansky:
17-Jun-2014 17:43, dennis luehring пОÑеÑ:
http://www.unicode.org/versions/Unicode7.0.0/
OMG
The "good" news is we haven't implemented yet the collation algorithm,
so no need to re-implement it! :)
P.S. Seriously we should be good to go, wit
On 06/17/2014 01:16 PM, "Ola Fosheim Grøstad"
" wrote:
On Tuesday, 17 June 2014 at 09:17:21 UTC, Nick Sabalausky wrote:
I think you're hitting on the fundamental limitations of automated
code-updating tools here: They can't be treated as trusted black-boxes.
I don't think this is a fundamental
On Tue, Jun 17, 2014 at 07:59:22AM +, monarch_dodra via Digitalmars-d wrote:
[...]
> We recently did some cleanup in our organization in regards to a
> couple functions whose argument counts were are too damn high: We
> created a helper-class which actually contains the arguments. So the
> call
On Tuesday, 17 June 2014 at 16:34:23 UTC, Timon Gehr wrote:
On 06/17/2014 01:16 PM, "Ola Fosheim Grøstad"
" wrote:
Programming languages are in general still quite primitive
(not specific
to D), they still rely on convention rather than formalisms.
...
That's a very odd statement to make ab
On Tuesday, 17 June 2014 at 16:08:18 UTC, H. S. Teoh via
Digitalmars-d wrote:
I think you are underestimating the complexity of programming.
No need to go ad hominem. I don't underestimate anything. What
makes you think so?
Automated
tools can only go so far -- ultimately, human intervention
On Tue, Jun 17, 2014 at 06:58:28PM +0400, Dmitry Olshansky via Digitalmars-d
wrote:
> 17-Jun-2014 17:43, dennis luehring пишет:
> >http://www.unicode.org/versions/Unicode7.0.0/
The page says the publication date isn't until October 15, 2014.
> OMG
>
> The "good" news is we haven't implemented
On 06/17/2014 06:53 PM, "Ola Fosheim Grøstad"
" wrote:
On Tuesday, 17 June 2014 at 16:34:23 UTC, Timon Gehr wrote:
On 06/17/2014 01:16 PM, "Ola Fosheim Grøstad"
" wrote:
Programming languages are in general still quite primitive (not specific
to D), they still rely on convention rather than f
On Tue, Jun 17, 2014 at 04:50:07PM +, via Digitalmars-d wrote:
> On Tuesday, 17 June 2014 at 16:08:18 UTC, H. S. Teoh via
> Digitalmars-d wrote:
> >I think you are underestimating the complexity of programming.
>
> No need to go ad hominem. I don't underestimate anything. What
> makes you thin
On Tuesday, 17 June 2014 at 17:03:34 UTC, Timon Gehr wrote:
If you are only talking about those languages, not at all.
Yes, I was only talking about the ones that are suitable for
creating commercial games given the topic of the thread.
(Languages that are based on Horn-clauses and the like
On Tuesday, 17 June 2014 at 15:15:44 UTC, Luís Marques wrote:
Is there any particular reason why this is accepted? (I
introduced it by mistake):
void foo(int = 3) {}
I guess it could be useful to ensure binary compatibility when
you expect to add the parameter later?
Actually there is no
On 6/17/2014 12:13 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Jun 17, 2014 at 06:56:11AM +, via Digitalmars-d wrote:
On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky wrote:
Well, I think interesting part we're trying to look at here is the ARC's
impact on speed.
ARC without
On 6/17/2014 2:31 AM, eles wrote:
It is not (only) about cost, it is about determinism. Exceptions are on the
error recovery path, so they are less important to be deterministic.
Yes, I do understand that. What I am trying to get across is that ARC can often
consume MORE aggregate time than GC
On Tuesday, 17 June 2014 at 16:15:27 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Tue, Jun 17, 2014 at 06:56:11AM +, via Digitalmars-d
wrote:
On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky
wrote:
>Well, I think interesting part we're trying to look at here
>is the ARC's
>impact o
On Tuesday, 17 June 2014 at 17:19:25 UTC, H. S. Teoh via
Digitalmars-d wrote:
The halting problem is equivalent to Kolgomorov complexity,
which in
turn relates to optimal compression, which has applications in
global
optimization problems in compiler technology. Sure, the way some
textbooks pre
On 6/17/2014 8:19 AM, Wyatt wrote:
On Tuesday, 17 June 2014 at 10:32:57 UTC, Jonathan M Davis via
Digitalmars-d wrote:
but as I understand it, no one knows how to get ahold of the
fellow who runs it
Nah, it's pretty simple. Just send him an email. I did this some
time last year, and even po
On Tue, Jun 17, 2014 at 06:04:56PM +, deadalnix via Digitalmars-d wrote:
> On Tuesday, 17 June 2014 at 16:15:27 UTC, H. S. Teoh via
> Digitalmars-d wrote:
> >On Tue, Jun 17, 2014 at 06:56:11AM +, via Digitalmars-d wrote:
> >>On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky wrote:
>
On 6/17/2014 4:36 AM, Manu via Digitalmars-d wrote:
On 17 June 2014 18:18, Walter Bright via Digitalmars-d
wrote:
On 6/16/2014 10:02 PM, Manu via Digitalmars-d wrote:
I can't imagine exceptions would appear in hot code very often/ever?
I've tried to explain this to you for months. You don'
On 6/17/2014 5:21 AM, Jacob Carlborg wrote:
On 17/06/14 05:18, Walter Bright wrote:
Note that Swift seems to not do exceptions (I may be wrong, again, I
know little about Swift), which is one way to avoid that problem.
It does not support exceptions.
I wouldn't be surprised if it doesn't in
On Tue, Jun 17, 2014 at 06:08:57PM +, via Digitalmars-d wrote:
> On Tuesday, 17 June 2014 at 17:19:25 UTC, H. S. Teoh via
> Digitalmars-d wrote:
[...]
> >There's no need to get rid of string mixins just because of that 1%
> >of code that actually needs to use them. Nobody says that the
> >trans
On 6/17/2014 4:59 AM, Manu via Digitalmars-d wrote:
What other position can I take on this issue?
Instead of taking positions, you can do some research. Understand how shared_ptr
works and what it costs, for starters. Try out Rust/Swift, disassemble the code,
and try to understand the tradeof
On Tuesday, 17 June 2014 at 18:15:24 UTC, Walter Bright wrote:
It is not possible to understand the tradeoffs with ARC without
understanding the cost of the DEC.
One thing D has going for it compared to C++ for reference
counting is shared vs. unshared types. At least ARC in D
wouldn't have
On Tue, 17 Jun 2014 13:55:33 -0400, Nick Sabalausky
wrote:
Limitations of the separate compilation model have come up before. For
example, the inability to retrieve all the subclasses of a base class.
This is not an issue that can be solved by removing separate compilation.
Dynamically l
On Tuesday, 17 June 2014 at 18:17:21 UTC, Walter Bright wrote:
I wouldn't be surprised if it doesn't in order to make ARC more
palatable.
I don't know, but on iOS you are supposed to save state to disk
continuously so that the app can die silently and reboot to where
you left off. And mobile
On Tue, Jun 17, 2014 at 11:15:29AM -0700, Walter Bright via Digitalmars-d wrote:
> On 6/17/2014 4:36 AM, Manu via Digitalmars-d wrote:
[...]
> >If we can't experiment with the compiler's ability to eliminate
> >redundant RC related work, then we aren't 'experimenting' with
> >anything of interest.
1 - 100 of 214 matches
Mail list logo
