On 08/07/14 19:54, David Nadlinger wrote:
Hi all,
I am excited to share news about two changes that recently made their
way into the development version of LDC, changes that might be
interesting for many of you Linux users out there.
The first is that LDC now supports linker-level dead code eli
On Wednesday, 9 July 2014 at 04:50:39 UTC, Walter Bright wrote:
On 7/8/2014 9:12 PM, Mike wrote:
From what I've observed, I don't think users are complaining
that D doesn't do
ref counting.
The recurrent observation is "I use C++/Rust/Whatever because
they do ref counting, and D uses GC. The
On Wednesday, 9 July 2014 at 04:50:39 UTC, Walter Bright wrote:
The question doesn't make sense. What is a ref counted int?
From the typecons documentation:
Example:
// A pair of an $(D int) and a $(D size_t) - the latter being the
// reference count - will be dynamically allocated
auto rc1 =
On Tue, Jul 08, 2014 at 07:42:50PM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/8/2014 3:37 PM, bearophile wrote:
> >Walter Bright:
> >
> >>3. 'ref' means 'borrowed', to use Rust's terminology
> >>
> >>We're almost there with this. This means better escape analysis,
> >>too.
> >
> >Is "scop
On 7/8/2014 9:12 PM, Mike wrote:
From what I've observed, I don't think users are complaining that D doesn't do
ref counting.
The recurrent observation is "I use C++/Rust/Whatever because they do ref
counting, and D uses GC. Therefore I cannot use D."
I believe they are complaining that D
On Wednesday, 9 July 2014 at 04:12:50 UTC, Mike wrote:
My question was sincere, I really wanted to know more about the
differences RefCounted and what you proposed.
shared_ptr supports multi-threading, weak pointers and
destructors.
If RefCounted is intended to have shared_ptr semantics,
On 9/07/2014 1:54 p.m., luminousone wrote:
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote:
There's been some discussion about vibe.d recently on reddit (e.g.
http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443)
and I was wondering to what ex
On 9/07/2014 1:09 p.m., Puming wrote:
Vibe.d is more like a base library for async I/O, networking and
concurrency, a full stack WEB framework should be built on top of it
which focus on application development and ease of use for newcomers.
Sonke has said that too. Vibe.d should focus on perform
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 Wednesday, 9 July 2014 at 03:18:54 UTC, Brad Anderson wrote:
Well, for starters RefCounted doesn't work with classes. That
needs to be implemented. I'm not sure what was problematic about
implementing it for classes though (anyone reading know?).
idk if this is what the Phobos devs were thin
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 7/8/2014 2:31 PM, Brian Schott wrote:
http://wiki.dlang.org/DIP65
tldr: There are parser and specification bugs and I want to fix them. It will
break some poorly-written code, but I think I can automate the upgrade process.
I don't want to break existing code. The grammar ambiguity issue ca
On 7/8/2014 3:37 PM, bearophile wrote:
Walter Bright:
3. 'ref' means 'borrowed', to use Rust's terminology
We're almost there with this. This means better escape analysis, too.
Is "scope" still left for future usage, or used for a different purpose, or
deprecated?
That would have to be add
On 7/8/2014 3:21 PM, bearophile wrote:
Walter Bright:
but it doesn't go so far as creating a Unique!T type.
What about the already present std.typecons.Unique?
It's not good enough.
In your list I'd like to add another point:
9. Built-in tuples usable in all the most important situations
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, and would be very attractive, much like
C++'s shared_ptr.
How do
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu
wrote:
There's been some discussion about vibe.d recently on reddit
(e.g.
http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443)
and I was wondering to what extent that's meaningful:
"has anyone ever
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
7. "D-Routines" - goroutines for D
Goroutines are the killer feature of Go for a number of
sensible people. We pretty much have this already with fibers,
but what is lacking is a scheduler, which will take some
effort, and a "Ch
On Wednesday, 9 July 2014 at 01:13:39 UTC, Nick Sabalausky wrote:
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu
wrote:
There's been some discussion about vibe.d recently on reddit
(e.g.
http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443)
and I
Also, in playframework, vert.x and nodejs, they all have a
plugin/module system, that people could easily compose plugins to
make a website. (I call it plugin because that is what play used
to call it, now they all call it a module but that name will
easily conflict with D's sourcecode modules)
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu
wrote:
There's been some discussion about vibe.d recently on reddit
(e.g.
http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443)
and I was wondering to what extent that's meaningful:
"has anyone ever
Vibe.d is more like a base library for async I/O, networking and
concurrency, a full stack WEB framework should be built on top of
it which focus on application development and ease of use for
newcomers. Sonke has said that too. Vibe.d should focus on
performance, networking, and other lowerlev
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, and
would be very attractive, much like C++'s shared_ptr.
How does this differ from std.typecons
On Wednesday, 9 July 2014 at 00:25:55 UTC, Meta wrote:
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
8. NotNull!T type
For those that want a non-nullable reference type. This should
be doable as a library type.
I remember Andrei seemed pretty gung-ho about mitigating
nullabl
On Tuesday, 8 July 2014 at 22:21:43 UTC, bearophile wrote:
Walter Bright:
but it doesn't go so far as creating a Unique!T type.
What about the already present std.typecons.Unique?
In your list I'd like to add another point:
9. Built-in tuples usable in all the most important situations
(wi
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
8. NotNull!T type
For those that want a non-nullable reference type. This should
be doable as a library type.
I remember Andrei seemed pretty gung-ho about mitigating nullable
references in the language[0] (he made a thread about
On Tuesday, 8 July 2014 at 23:43:47 UTC, Meta wrote:
https://github.com/andralex/std_allocator
This is much more recent:
https://github.com/andralex/phobos/blob/allocator/std/allocator.d
On Tuesday, 8 July 2014 at 23:18:53 UTC, Remo wrote:
So how about memory pool for D ?
It there already one ?
Andrei is working a lot on them. They look very good.
Is the code public already ?
https://github.com/andralex/std_allocator
On Tuesday, 8 July 2014 at 23:23:40 UTC, David Nadlinger wrote:
The __bss_start/_end symbols have somehow turned LOCAL, whereas
they should be globally visible to override the ones defined in
libdruntime.so.
Sorry for the monologue, but this might be related:
https://sourceware.org/bugzilla/s
On Tuesday, 8 July 2014 at 22:44:30 UTC, David Nadlinger wrote:
On Tuesday, 8 July 2014 at 20:43:19 UTC, Joseph Rushton
Wakeling wrote:
Tried building hap.random's benchmarknew with the
shared-library build of ldc, and got this error when I tried
to run the resulting executable:
Fatal Error w
On Tuesday, 8 July 2014 at 22:56:56 UTC, bearophile wrote:
Remo:
unique_ptr is helpful in 90% of the time.
shared_ptr is necessary in may be another 9%.
Memory pool is helpful in another cases.
And only in 0.1% case GC is really needed. :)
Are you forgetting the RefCount?
shared_ptr uses re
On Tuesday, 8 July 2014 at 22:44:30 UTC, David Nadlinger wrote:
As strange as it might sound, I'm actually rather relieved that
you ran into this issue. I previously thought Martin's
collision detection code was at fault (see
https://github.com/D-Programming-Language/druntime/pull/791#issuecomm
Remo:
unique_ptr is helpful in 90% of the time.
shared_ptr is necessary in may be another 9%.
Memory pool is helpful in another cases.
And only in 0.1% case GC is really needed. :)
Are you forgetting the RefCount?
But I use D because it has a GC and it doesn't look like C++, I
am not writing
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
Distilling the discussions about D that are elsewhere than this
forum, some consistent themes emerge which we need to address
to broaden the appeal of D. All of them require some
organization and focussed effort to complete.
There'
On Tuesday, 8 July 2014 at 20:43:19 UTC, Joseph Rushton Wakeling
wrote:
Tried building hap.random's benchmarknew with the
shared-library build of ldc, and got this error when I tried to
run the resulting executable:
Fatal Error while loading '/opt/ldc/lib/libphobos2-ldc.so.65':
The mod
Walter Bright:
3. 'ref' means 'borrowed', to use Rust's terminology
We're almost there with this. This means better escape
analysis, too.
Is "scope" still left for future usage, or used for a different
purpose, or deprecated?
Bye,
bearophile
Walter Bright:
but it doesn't go so far as creating a Unique!T type.
What about the already present std.typecons.Unique?
In your list I'd like to add another point:
9. Built-in tuples usable in all the most important situations
(with a syntax that doesn't kill possible future improvements o
On 08/07/2014 10:01 PM, Iain Buclaw via Digitalmars-d wrote:
But the imperial system *isn't* idiotic. :o)
14 lbs is a stone? apart from that its fine ^^
And everyone should drive on the left.
I drive in the middle, it works fine until I meet other road users.
A...
On Tuesday, 8 July 2014 at 20:39:34 UTC, Walter Bright wrote:
This is all great news, congratulations!
Thanks. There was quite a bit of staring at obscure backtraces
and object file dumps involved. The most persistent issue was
what revealed itself to be a nasty race condition in
core.thread
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu
wrote:
If there's sheer work needed for completing vibe.d, I think it
would be great if the domain-savvy part of the community would
rally around it. Serving dlang.org and dconf.org off of vibe.d
would be awesome dogfooding.
Google
http://wiki.dlang.org/DIP65
tldr: There are parser and specification bugs and I want to fix
them. It will break some poorly-written code, but I think I can
automate the upgrade process.
Distilling the discussions about D that are elsewhere than this forum, some
consistent themes emerge which we need to address to broaden the appeal of D.
All of them require some organization and focussed effort to complete.
There's been enough jawboning about them. I figure all of them can be
On Tuesday, 8 July 2014 at 20:38:59 UTC, Marc Schütz wrote:
But as you already noted, there needs to be a mechanism to
restrict escaping of pointers.
Yes, there ought to be, at least for @safe code.
Do you have some concrete idea how that could be solved?
For my use, yes. Since I am conside
On 8 July 2014 21:20, deadalnix via Digitalmars-d
wrote:
> On Friday, 4 July 2014 at 07:39:51 UTC, Russel Winder via
>
> Digitalmars-d wrote:
>>
>> On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via Digitalmars-d wrote:
>> […]
>>>
>>> Powered by Martian Technology
>>
>>
>> @SarcasticRover is telli
On Tuesday, 8 July 2014 at 17:54:48 UTC, David Nadlinger wrote:
And secondly, proper support for building druntime/Phobos as
shared libraries and loading D shared objects dynamically has
now arrived in LDC! As you might be aware, Martin Nowak has
spent a considerable amount of effort on adding
This is all great news, congratulations!
On the gc-sections front, Martin had gotten it to work for DMD on Linux but then
had to back it out because it failed with the ld.gold linker.
If it works for ldc with ld.gold, can you please help explain what went wrong
for dmd?
There's been some discussion about vibe.d recently on reddit (e.g.
http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443)
and I was wondering to what extent that's meaningful:
"has anyone ever tied a real webservice to vibe.d? I actually tried. its
nowhere near
On 7/8/2014 1:39 PM, Walter Bright wrote:
This is all great news, congratulations!
On the gc-sections front, Martin had gotten it to work for DMD on Linux but then
had to back it out because it failed with the ld.gold linker.
If it works for ldc with ld.gold, can you please help explain what we
A custom allocator can also be specified. The nice thing is, that
this doesn't even need new syntax:
process(A a) {
int x;
{
MyCustomAllocator alloc;
GC.pushAllocator(alloc);
scope(exit) GC.popAllocator();
auto y = new ...;
// alloc's destructor i
On Friday, 4 July 2014 at 07:39:51 UTC, Russel Winder via
Digitalmars-d wrote:
On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via
Digitalmars-d wrote:
[…]
Powered by Martian Technology
@SarcasticRover is telling us "Do not come to Mars." Perhaps its
commentary need censoring ;-)
He also ge
On Tuesday, 8 July 2014 at 17:54:48 UTC, David Nadlinger wrote:
The first is that LDC now supports linker-level dead code
elimination on Linux. If you happen to be familiar with the
-f{function,data}-sections/--gc-sections options of the GNU
toolchain, their equivalent is now enabled by default
On Tuesday, 8 July 2014 at 17:54:48 UTC, David Nadlinger wrote:
I am excited to share news about two changes that recently made
their way into the development version of LDC, changes that
might be interesting for many of you Linux users out there.
Sounds great -- congratulations to all the LDC
On Tuesday, 8 July 2014 at 18:04:14 UTC, Brad Anderson wrote:
Maybe I'm misunderstanding but why not just use reset()?
reset deletes the currently referenced object.
On Tuesday, 8 July 2014 at 18:23:41 UTC, Sean Kelly wrote:
On Tuesday, 8 July 2014 at 18:04:14 UTC, Brad Anderson wrote:
Maybe I'm misunderstanding but why not just use reset()?
reset deletes the currently referenced object.
Oh, I see what you were going for now.
On Tuesday, 8 July 2014 at 17:16:27 UTC, Marco Leise wrote:
2) Druntime must adapt to the system's C compiler's ABI.
(by the use of libunwind)
Yes, longjmp() could happen in a callback and may be expected to
unwind the stack (depending on the dev environment).
On Tuesday, 8 July 2014 at 17:55:15 UTC, Sean Kelly wrote:
Well sure, but you can't use a class instance living on the
stack
as the context for a callback. At that point, whatever smart
pointer you're using has to be discarded. This is actually why
I
find little use for std::shared_ptr--it
On Tuesday, 8 July 2014 at 15:23:30 UTC, Atila Neves wrote:
On Tuesday, 8 July 2014 at 14:24:10 UTC, Sean Kelly wrote:
On Tuesday, 8 July 2014 at 02:31:50 UTC, Átila Neves wrote:
On Monday, 7 July 2014 at 18:15:32 UTC, Sean Kelly wrote:
With asynchronous event-driven code (ie. server code), I
Hi all,
I am excited to share news about two changes that recently made
their way into the development version of LDC, changes that might
be interesting for many of you Linux users out there.
The first is that LDC now supports linker-level dead code
elimination on Linux. If you happen to be
Am Thu, 19 Jun 2014 12:59:00 -0700
schrieb Walter Bright :
> With nothrow and @nogc annotations, we've been motivated to add these
> annotations to C system API functions, because obviously such functions
> aren't
> going to throw D exceptions or call the D garbage collector.
>
> But this expo
On Tuesday, 8 July 2014 at 16:55:54 UTC, bearophile wrote:
D is in beta release, so that pull request has to wait for
2.067+.
We use release branches now. There is no reason for development
activity to decline during the beta period – other than people
being busy with addressing beta tester f
Seems to me that most of the utility beyond maintaining graph
like structures can be covered by making the compiler aware of
region allocator semantics. Assuming that the use of GC is
constrained locally and does not consume too much space. I think
it would work out ok for loading of smaller files
Meta:
https://github.com/D-Programming-Language/dmd/pull/3615
D is in beta release, so that pull request has to wait for 2.067+.
Bye,
bearophile
On Tuesday, 8 July 2014 at 15:57:40 UTC, David Gileadi wrote:
On Friday, 4 July 2014 at 20:31:20 UTC, Walter Bright wrote:
On 7/4/2014 5:49 AM, Andrej Mitrovic via Digitalmars-d wrote:
Now *that* I definitely cannot work on. It's a complete
conflict of
interest due to our two companies. :)
D
On Tuesday, 8 July 2014 at 12:24:32 UTC, John Colvin wrote:
There was talk of something like immutable(char)[$] =
"héllo͂"; working, but I don't know where that went.
https://github.com/D-Programming-Language/dmd/pull/3615
On Friday, 4 July 2014 at 20:31:20 UTC, Walter Bright wrote:
On 7/4/2014 5:49 AM, Andrej Mitrovic via Digitalmars-d wrote:
Now *that* I definitely cannot work on. It's a complete
conflict of
interest due to our two companies. :)
Dang, we can't afford any mutiny on the bounty!
I just have to
On Tuesday, 8 July 2014 at 14:24:10 UTC, Sean Kelly wrote:
On Tuesday, 8 July 2014 at 02:31:50 UTC, Átila Neves wrote:
On Monday, 7 July 2014 at 18:15:32 UTC, Sean Kelly wrote:
With asynchronous event-driven code (ie. server code), I don't
see any way to avoid all use of new / delete.
std::m
On Tuesday, 8 July 2014 at 14:24:10 UTC, Sean Kelly wrote:
But you're ultimately passing something as a void* to a library
call and receiving it later as the context for a callback.
That value has to live on the heap.
Well to be fair, you could make the context an index into an
array.
On Tuesday, 8 July 2014 at 02:31:50 UTC, Átila Neves wrote:
On Monday, 7 July 2014 at 18:15:32 UTC, Sean Kelly wrote:
With asynchronous event-driven code (ie. server code), I don't
see any way to avoid all use of new / delete.
std::make_unique and std::make_shared are what you're
"supposed"
http://mars-lang.appspot.com/
On Tuesday, 8 July 2014 at 11:31:49 UTC, Oluca wrote:
On Tuesday, 8 July 2014 at 11:26:55 UTC, John Colvin wrote:
On Tuesday, 8 July 2014 at 11:22:42 UTC, John Colvin wrote:
On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:
I remember that slices was one thing you would no longer
int[10] a = [0,1,2,3,4,5,6,7,8,9]; //a static array, on the
stack
auto s = a[]; //a normal slice, backed by stack memory*
auto s1 = a[3 .. 5]; //ditto
I see. Thanks for the examples. What about strings? Do they
depend on GC?
They are just slices / arrays.
On Tuesday, 8 July 2014 at 11:26:55 UTC, John Colvin wrote:
On Tuesday, 8 July 2014 at 11:22:42 UTC, John Colvin wrote:
On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:
I remember that slices was one thing you would no longer have
if you disable the GC, but I can't think of any ot
On Tuesday, 8 July 2014 at 11:22:42 UTC, John Colvin wrote:
On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:
I remember that slices was one thing you would no longer have
if you disable the GC, but I can't think of any others.
You can definitely use slices without the GC and they
On Tuesday, 8 July 2014 at 10:25:17 UTC, Oluca wrote:
On Tuesday, 8 July 2014 at 10:07:18 UTC, Tobias Pankrath wrote:
On Tuesday, 8 July 2014 at 09:57:15 UTC, Oluca wrote:
- No, it can't be disabled if you want to keep using
"impressive
features" of the language.
What do CTFE, mixins, Ds pow
On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:
I remember that slices was one thing you would no longer have
if you disable the GC, but I can't think of any others.
You can definitely use slices without the GC and they are still
awesome without the GC.
What you cannot do is cre
On Tuesday, 8 July 2014 at 06:08:58 UTC, Brian Schott wrote:
On Tuesday, 8 July 2014 at 06:02:51 UTC, Iain Buclaw via
Digitalmars-d wrote:
I would ask why are you passing integers to isNaN.
We passed T to isNaN, and sometimes T was uint.
I would like to have a NaN in any type and be able to
On Tuesday, 8 July 2014 at 10:25:17 UTC, Oluca wrote:
- You can't use slices. You can't make use of most of the
Standard Library functionality.
You just cannot append to them.
- It matters, because you can't manually manage life-time of
the objects. See, you have to keep a reference to a C-
On Tuesday, 8 July 2014 at 10:07:18 UTC, Tobias Pankrath wrote:
On Tuesday, 8 July 2014 at 09:57:15 UTC, Oluca wrote:
- No, it can't be disabled if you want to keep using
"impressive
features" of the language.
What do CTFE, mixins, Ds powerful template mechanism, immutable
+
slices, sane op
On Tuesday, 8 July 2014 at 09:57:15 UTC, Oluca wrote:
- No, it can't be disabled if you want to keep using "impressive
features" of the language.
What do CTFE, mixins, Ds powerful template mechanism, immutable +
slices, sane operator overloading, opDispatch, alias this and
UFCS, RAII + scope st
On Tuesday, 8 July 2014 at 03:37:51 UTC, Adrian wrote:
Hi all,
I know there's been quite some discussion about the GC in D,
but I've been busy doing other things and haven't been
following that closely.
So I'd appreciate it if someone could fill me in about
proceedings/decisions in this reg
Marc Schütz:
There might also be other changes necessary, some kind of
ownership tracking / borrowing for example, to make this safe.
(Manual memory management without help from the language can
easily lead to all kinds of bugs.)
In the end Bartoz could be right.
Bye,
bearophile
On Tuesday, 8 July 2014 at 03:37:51 UTC, Adrian wrote:
+ Has the GC been dropped?
No, and no matter what exactly will be done, it surely will
always stay at least as an option, and most probably will be
enabled by default.
+ If not, can it be disabled entirely/completely?
This is alre
On Thursday, 3 July 2014 at 17:38:22 UTC, w0rp wrote:
On Thursday, 3 July 2014 at 13:16:34 UTC, Chris wrote:
[I haven't had time to follow the entire thread, but] I like
the design, it's a good starting point. Especially the
integration of the logo. Nice and clean. (The current logo is
just to
On Friday, 4 July 2014 at 17:05:16 UTC, Walter Bright wrote:
On 7/4/2014 3:38 AM, Don wrote:
What is "the longest type supported by the native hardware"? I
don't know what
that means, and I don't think it even makes sense.
Most of the time, it is quite clear.
For example, Sparc has 128-bit q
83 matches
Mail list logo
