Exactly what I was talking about :D
Thanks for your efforts !!!
I'll download and test them right away.
testdasdas
test
This is the work I am related to or created myself.
- std.ui.windowing[0]
- std.ui.gui
- std.graphics.image[1]
- std.graphics.color[2]
- std.events[0]
- std.events.loop[0]
- std.audio
- std.sockets[0]
Any assistance to improving my work including[3] would be appreciated as
I am slow.
[0] http
Since a few months, I'm using D for all my command-line tools.
For that use case, the language and its standard libraries are
really perfect, making it the best scripting language I know,
completely exploding JavaScript, Python, Ruby, etc.
Now I would like to also use it to develop :
- web se
Thanks for the suggestions regarding the `scope` parameter
attribute. I'll look into it!
On Sunday, 21 May 2017 at 01:30:51 UTC, Adam D. Ruppe wrote:
On Sunday, 21 May 2017 at 00:49:23 UTC, Stanislav Blinov wrote:
[...] you *can* write out the struct now, it just has more
tedious syntax.
Thi
On Friday, 19 May 2017 at 10:38:56 UTC, Andre Pany wrote:
Should I file an issue for providing the 64 build of dmd on
windows?
As 64 bit is the default on the other platforms it should be
available for windows too by default.
Kind regards
André
We would find this useful too because we run ou
On Sunday, 21 May 2017 at 00:49:23 UTC, Stanislav Blinov wrote:
And it would be nice to be able to store the delegate longer
than current scope...
Important to note that this thing won't be a delegate, since
delegates don't have room to store by-value captures. It can
still be passed to isCal
On Saturday, 20 May 2017 at 13:06:01 UTC, Jonathan M Davis wrote:
...
Let's take the CTFE discussion to a different thread
On Sunday, 21 May 2017 at 00:43:58 UTC, Adam D. Ruppe wrote:
On Sunday, 21 May 2017 at 00:33:30 UTC, Vittorio Romeo wrote:
just manually writing out the struct functor being another
viable one. The c++ syntax sugar is nice, but I can live
without it.
Assembler is viable as well, but it's not
On Sunday, 21 May 2017 at 00:43:58 UTC, Adam D. Ruppe wrote:
What are your thoughts? Has something similar been proposed
before?
It has, and I actually don't hate it, but I also don't think it
is necessary because of the `scope` storage class being one
option and just manually writing out th
On Sunday, 21 May 2017 at 00:33:30 UTC, Vittorio Romeo wrote:
auto bar(T)(T x) @nogc
Make that `scope T x` and it will compile, using stack
allocation. Only worry is that you must not escape a reference to
the delegate; you are only allowed to use it in that function's
scope.
What are
Hello everyone, I recently started learning D (I come from a
Modern C++ background) and I was curious about closures that
require GC allocation. I wrote this simple example:
auto bar(T)(T x) @nogc
{
return x(10);
}
auto foo(int x) @nogc
{
return bar((int y)
On Saturday, May 20, 2017 12:34:09 PM PDT H. S. Teoh via Digitalmars-d
wrote:
> On Sat, May 20, 2017 at 07:53:58AM +, Stefan Koch via Digitalmars-d
wrote:
> > On Saturday, 20 May 2017 at 07:02:10 UTC, Walter Bright wrote:
> > > Also, have a GC makes CTFE real nice.
> >
> > Having to implement
On Sat, May 20, 2017 at 07:53:58AM +, Stefan Koch via Digitalmars-d wrote:
> On Saturday, 20 May 2017 at 07:02:10 UTC, Walter Bright wrote:
> >
> > Also, have a GC makes CTFE real nice.
>
> Having to implement a GC for newCTFE won't be nice though :o)
> I agree though being able to allocate m
On Sat, May 20, 2017 at 03:05:44PM +, Stefan Koch via Digitalmars-d wrote:
> On Saturday, 20 May 2017 at 14:59:37 UTC, Ola Fosheim Grøstad wrote:
> > On Saturday, 20 May 2017 at 13:36:14 UTC, Stefan Koch wrote:
> > > unions and other ABI-related things will be tricky.
> >
> > Isn't the unions
On Sat, May 20, 2017 at 12:00:37PM +, 9il via Digitalmars-d wrote:
> On Saturday, 20 May 2017 at 11:47:32 UTC, John Colvin wrote:
> > On Saturday, 20 May 2017 at 11:34:55 UTC, 9il wrote:
> > > On Saturday, 20 May 2017 at 11:30:54 UTC, John Colvin wrote:
> > > > [...]
> > >
> > > I just found t
On Saturday, 20 May 2017 at 15:05:44 UTC, Stefan Koch wrote:
Ah tagging behind the scene is an option, it comes with runtime
cost though.
(I guess you meant compile-time cost)
And tagging would disallow the tricky and very common usecase
of overlaying and int and a float.
This I understand,
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
...
|| works also fine now ... on it's own.
As soon as || and && are mixed wired things happen.
I am happy that the combinations I tried do at least expose the
issue.
This is one of the things that you can totally overlook if th
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
[ ... ]
So I just verified that the following code runs fine with newCTFE.
int[2] aaa2(bool b1, bool b2, bool b3)
{
int x = 0;
if (b1 && ++x && b2 && x++ && b3 && x++)
{
return [x, 1];
}
else
{
return [x, 0];
On Saturday, May 20, 2017 3:05:44 PM PDT Stefan Koch via Digitalmars-d
wrote:
> On Saturday, 20 May 2017 at 14:59:37 UTC, Ola Fosheim Grøstad
>
> wrote:
> > On Saturday, 20 May 2017 at 13:36:14 UTC, Stefan Koch wrote:
> >> unions and other ABI-related things will be tricky.
> >
> > Isn't the union
On Saturday, 20 May 2017 at 14:59:37 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 20 May 2017 at 13:36:14 UTC, Stefan Koch wrote:
unions and other ABI-related things will be tricky.
Isn't the unions issue quite easily solved by tagging behind
the scenes?
Ah tagging behind the scene is an op
On Friday, 19 May 2017 at 15:45:28 UTC, Mike Parker wrote:
Destroy!
In catch blocks, e is regarded as scope so that it cannot
escape the catch block.
...
Code that needs to leak the thrown exception object can clone
the object.
There's a contradiction here. Generic cloning cannot be
impl
On Saturday, 20 May 2017 at 13:36:14 UTC, Stefan Koch wrote:
unions and other ABI-related things will be tricky.
Isn't the unions issue quite easily solved by tagging behind the
scenes?
On Saturday, May 20, 2017 1:36:14 PM PDT Stefan Koch via Digitalmars-d
wrote:
> On Saturday, 20 May 2017 at 13:06:01 UTC, Jonathan M Davis wrote:
> > Yeah, especially when you're not allowed to manually allocate
> > memory in CTFE. :)
> >
> > And given that Stephan thinks that ref is too hard to i
On Saturday, 20 May 2017 at 13:06:01 UTC, Jonathan M Davis wrote:
Yeah, especially when you're not allowed to manually allocate
memory in CTFE. :)
And given that Stephan thinks that ref is too hard to implement
in newCTFE (IIRC from what he said at dconf anyway), I'd hate
to think what it wo
On Saturday, May 20, 2017 12:02:10 AM PDT Walter Bright via Digitalmars-d
wrote:
> On 5/19/2017 8:54 PM, Jonathan M Davis via Digitalmars-d wrote:
> > And the reality of the matter is that using the GC has real benefits,
> > and
> > trying to avoid it comes at a real cost, much as a number of C++
On Saturday, 20 May 2017 at 11:47:32 UTC, John Colvin wrote:
On Saturday, 20 May 2017 at 11:34:55 UTC, 9il wrote:
On Saturday, 20 May 2017 at 11:30:54 UTC, John Colvin wrote:
[...]
I just found that new LLVM solves this issue (and was very
surprised).
The reason that ndslice <=v0.6.1 was so
On Saturday, 20 May 2017 at 11:23:54 UTC, Timon Gehr wrote:
There is this PR that turns the deprecation messages into
compilation errors: https://github.com/dlang/dmd/pull/6554
If you or anyone wants to help pushing the deprecation phase,
please feel to adopt this PR, do the final polishing an
On Saturday, 20 May 2017 at 11:47:32 UTC, John Colvin wrote:
What's surprising about it? Thinking very simplistically (I
don't know how it actually works), if inlining happened first
then surely the later optimisation stages wouldn't have a
problem detecting the necessary loop invariants and
On Saturday, 20 May 2017 at 11:34:55 UTC, 9il wrote:
On Saturday, 20 May 2017 at 11:30:54 UTC, John Colvin wrote:
On Saturday, 20 May 2017 at 03:24:41 UTC, 9il wrote:
Hello,
When users write math code, they expect [2, 3, 4] that the
code like
[...]
What you are saying is that there is a s
On Saturday, 20 May 2017 at 11:30:54 UTC, John Colvin wrote:
On Saturday, 20 May 2017 at 03:24:41 UTC, 9il wrote:
Hello,
When users write math code, they expect [2, 3, 4] that the
code like
[...]
What you are saying is that there is a specific shortcoming
that you are observing in optimis
On Saturday, 20 May 2017 at 03:24:41 UTC, 9il wrote:
Hello,
When users write math code, they expect [2, 3, 4] that the code
like
[...]
What you are saying is that there is a specific shortcoming that
you are observing in optimisers, yes? Perhaps we should
investigate how to fix the optimi
On Saturday, 20 May 2017 at 03:24:41 UTC, 9il wrote:
The reason is that `matrixX[i, j]` is opIndex call, opIndex is
a function. It can be inlined. But optimizers can not split its
body and move half of opIndex computations out of the inner
loop, which it required for vectorization.
Hmm, look
On 20.05.2017 13:23, Timon Gehr wrote:
On 20.05.2017 12:52, Lucia Cojocaru wrote:
Hi,
I see array.sort and array.reverse are still in the deprecation phase.
Is there any planned date for their removal?
Deprecation: use std.algorithm.sort instead of .sort property
Deprecation: use std.algorithm
On 20.05.2017 12:52, Lucia Cojocaru wrote:
Hi,
I see array.sort and array.reverse are still in the deprecation phase.
Is there any planned date for their removal?
Deprecation: use std.algorithm.sort instead of .sort property
Deprecation: use std.algorithm.reverse instead of .reverse property
T
Hi,
I see array.sort and array.reverse are still in the deprecation
phase. Is there any planned date for their removal?
Deprecation: use std.algorithm.sort instead of .sort property
Deprecation: use std.algorithm.reverse instead of .reverse
property
Thanks,
Lucia
On Saturday, 20 May 2017 at 02:05:21 UTC, Jonathan M Davis wrote:
2. This really isn't going to fix the @nogc problem with
exceptions without either seriously overhauling how exceptions
are generated and printed or by having less informative error
messages. The problem is with how exception m
On Saturday, 20 May 2017 at 03:54:43 UTC, Jonathan M Davis wrote:
Because of the issue of lifetimes, some language features
simply cannot be implemented without the GC, and I think don't
see any point in trying to make it so that you can use all
features of D without the GC. That simply won't
On Saturday, 20 May 2017 at 02:25:45 UTC, Walter Bright wrote:
We'll be doing more invisible special casing in the future. For
example,
void foo(scope string s);
...
string s;
...
foo(s ~ "abc");
This array concatenation does not need to be done with the GC.
It's not fundamentally
On Saturday, 20 May 2017 at 07:02:10 UTC, Walter Bright wrote:
Also, have a GC makes CTFE real nice.
Having to implement a GC for newCTFE won't be nice though :o)
I agree though being able to allocate memory makes ctfe much more
useful then it would otherwise be.
On 5/19/2017 8:54 PM, Jonathan M Davis via Digitalmars-d wrote:
And the reality of the matter is that using the GC has real benefits, and
trying to avoid it comes at a real cost, much as a number of C++ progammers
want to complain and deride as soon as they hear that D has a GC. And
honestly, eve
42 matches
Mail list logo
