On Friday, 4 March 2016 at 06:55:29 UTC, Shachar Shemesh wrote:
On 03/03/16 19:31, Andrei Alexandrescu wrote:
https://www.mailinator.com/tymaPaulMultithreaded.pdf
On a completely different note, me and a colleague started a
proof of concept to disprove the claim that blocking+threads is
slow
On Wednesday, 27 January 2016 at 09:33:16 UTC, Kagamin wrote:
On Tuesday, 26 January 2016 at 20:33:34 UTC, Chris Wright wrote:
You can use fibers in C++ if you find a library to do it
(boost might?). You might be able to find a Java library for
it, but it's difficult and might require bytecode
On Friday, 16 October 2015 at 21:54:11 UTC, Jonathan M Davis
wrote:
[...]
std.concurrency.MessageBox is an example of why you might mix
synchronized and non-synchronized data in a class. No methods are
synchronized though because it's too blunt an instrument.
Synchronization happens internal
On Friday, 16 October 2015 at 06:49:06 UTC, Dicebot wrote:
On Friday, 16 October 2015 at 06:26:30 UTC, Jacob Carlborg
wrote:
On 2015-10-15 16:28, Andrei Alexandrescu wrote:
That may be worrisome. Any information on how many are using
DWT, and
how badly it would break if we pulled the change?
On Tuesday, 13 October 2015 at 11:51:02 UTC, ponce wrote:
On Tuesday, 13 October 2015 at 10:57:55 UTC, Marco Leise wrote:
Yep, I prefer to think it sets of variables that need mutex
protection. And these are not generally the set of member
fields in a class.
Exactly. And that makes things u
On Thursday, 18 December 2014 at 09:20:27 UTC, Jacob Carlborg
wrote:
On 2014-12-17 23:24, Sean Kelly wrote:
Hah. I tried RoR once. I couldn't get the environment set up
and running and eventually just gave up.
I don't know when you tried it last time, but today it's very
easy to install:
On Wednesday, 17 December 2014 at 17:09:34 UTC, Andrei
Alexandrescu wrote:
On 12/4/14 6:39 PM, deadalnix wrote:
On Thursday, 4 December 2014 at 13:48:04 UTC, Russel Winder via
Digitalmars-d wrote:
It's an argument for Java over Python specifically but a bit
more
general in reality. This stood
On Monday, 15 December 2014 at 11:32:30 UTC, Atila Neves wrote:
My personal preference is still for C++ done in a similar
manner as vibe.d as I think it's the sweet spot between ease
of use and scalability provided you have a talented team, but
I've seen Java be used successfully for servicing
On Monday, 15 December 2014 at 14:39:50 UTC, Daniel Murphy wrote:
"Stephan Schiffels" wrote in message
news:mzlhbfypcihvyatta...@forum.dlang.org...
This doesn't work for me, for some reason. I reserve via
GC.reserve(4_000_000_000), ensured that it does return at
least that amount, but the Ga
On Sunday, 14 December 2014 at 18:25:26 UTC, Joakim wrote:
On Sunday, 14 December 2014 at 17:09:31 UTC, Paulo Pinto wrote:
You mean scale like Twitter and LinkedIn?
Maybe that's why they still lose money hand over fist,
especially Twitter, because of all the extra servers they have
to buy. :
On Sunday, 14 December 2014 at 17:09:31 UTC, Paulo Pinto wrote:
On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote:
I don't doubt that this has been your experience on enterprise
projects with a known and stable userbase, but you can't tell
me you were able to support the same amount o
On Friday, 12 December 2014 at 17:57:41 UTC, Trent Forkert wrote:
I've looked into writing a binding for ICU recently, but
ultimately decided to abandon that idea in favor of writing a
replacement for it in D.
Wow... really? You're actually going to write transcoders for
all available enco
On Friday, 12 December 2014 at 15:47:09 UTC, Joakim wrote:
It seems like pointless repetition and there are many more
examples of this, as I keep running into it when adding
bionic/Android support. Martin suggested that it would be
useful to have a default case that asserts for an unsupporte
All the stack tracing stuff is wired through Throwable, so some
duplication may need to occur if it were changed to an interface.
On Saturday, 6 December 2014 at 16:32:30 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Sat, Dec 06, 2014 at 05:10:09PM +0100, Joseph Rushton
Wakeling via Digitalmars-d wrote:
On 05/12/14 23:03, deadalnix via Digitalmars-d wrote:
>http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_res
On Thursday, 4 December 2014 at 16:44:51 UTC, Temtaime wrote:
Why when an DMD developer said « no » to you in ticket you go
to the forum and troll there ?
If one wants debug information he will use debug version of
phobos. In fine-tune application there's no need for -gs flag.
With stack info
On Tuesday, 2 December 2014 at 00:13:03 UTC, Andrei Alexandrescu
wrote:
I wonder if there's some way to filter out robots, build
machines etc. Ideas?
The User-Agent header would be a good place to start.
On Monday, 1 December 2014 at 20:42:06 UTC, Jacob Carlborg wrote:
On 2014-12-01 18:03, Sean Kelly wrote:
A few years back, clang was generating an invalid copy ctor
for a struct
in DMD. I assume this has long since been fixed, but clearly
clang still
has a few bugs.
Lately I've only been abl
A few years back, clang was generating an invalid copy ctor for a
struct in DMD. I assume this has long since been fixed, but
clearly clang still has a few bugs.
Yes, I'd be curious to see the code. I also suspect that the
functionality in core may not be sufficiently advertised. At one
point he mentions using yieldForce to simulate a barrier, which
suggests he wasn't aware of core.sync.barrier.
On Friday, 21 November 2014 at 10:24:09 UTC, Kagamin wrote:
On Thursday, 25 September 2014 at 21:59:15 UTC, Sean Kelly
wrote:
On Thursday, 25 September 2014 at 13:55:42 UTC, Wyatt wrote:
The caveat for D being this design requires read and write
barriers and I'm pretty sure I recall correctly
On Saturday, 15 November 2014 at 01:43:07 UTC, Robert burner
Schadek wrote:
This PR
https://github.com/D-Programming-Language/phobos/pull/2724 adds
an generic way of handling Exception in Range processing.
quickfur and Dicebot ask me to start a thread here so the
concept could be discussed.
On Thursday, 20 November 2014 at 00:08:08 UTC, Andrei
Alexandrescu wrote:
I think we're in good shape with unsigned.
I'd actually prefer signed. Index-based algorithms can be tricky
to write correctly with unsigned index values. The reason size_t
is unsigned in Druntime is because I felt t
On Wednesday, 19 November 2014 at 02:16:36 UTC, Steven
Schveighoffer wrote:
Well, I just realized that D AA's "load factor" is 4 (see
below). That means, for a hash table with 4 buckets, you need
to add 17 items to generate a rehash. It also means that you
are guaranteed to have one bucket wi
On Tuesday, 18 November 2014 at 14:24:18 UTC, FrankLike wrote:
Many excellent projects such as dfl,dgui,tango, many 'length'
which type is 'int' or 'uint',they are D's,many people like
it.but they should migrate to 64 bit.So if 'length' type is
'int',they can work on 64 bit,but now,they must
On Sunday, 16 November 2014 at 17:38:54 UTC, Ola Fosheim Grøstad
wrote:
But keep in mind that you also have to account for fibers that
move between threads.
Yes. There are a lot of little "gotchas" with thread-local
allocation.
We'll have to change the way "immutable" is treated for
allocations. Which I think is a good thing. Just because
something can be shared doesn't meant that I intend to share it.
On Tuesday, 11 November 2014 at 17:24:31 UTC, Jacob Carlborg
wrote:
On 2014-11-11 15:05, Jacob Carlborg wrote:
The first step would be to implement native TLS, see this
issue [1].
BTW, the reason to implement native TLS is because otherwise we
need to implement basically what the dynamic lin
It's been a while since I Dded this, but I think the GC will
effectively call minimize after collecting, so any collected
large allocations should be returned to the OS. Allocations
larger than 4K get their own dedicated pool, so fragmentation
shouldn't come into play here.
Try following the big allocation with a really small allocation
to clear out any registers that may be referencing the large
block.
On Monday, 10 November 2014 at 23:08:55 UTC, Logan Capaldo wrote:
So just to be clear, there are _some_ legitimate uses of extern
(C) in druntime, yes? rt_init/rt_term, rt_loadLibrary,
thread_init(? think this one can be bootstrapped from D code),
...?
Yes. There are a few functions meant
On Monday, 10 November 2014 at 19:59:02 UTC, Andrei Alexandrescu
wrote:
On 11/10/14 7:42 AM, Sean Kelly wrote:
To address your question a bit more fully, it seems like this
is
something the range proposal for C++ is better suited for. Then
appending would just be a special case of inserting at
On Monday, 10 November 2014 at 16:59:47 UTC, Dicebot wrote:
Right now question is, however, are there any legitimate uses
of `extern(C)` in druntime or those all can be replaced with
`pragma(mangle, "XXX") extern(D)`?
I don't think there's any reason to use extern (C) in druntime
any more.
On Monday, 10 November 2014 at 15:52:56 UTC, Steven Schveighoffer
wrote:
On 11/10/14 10:40 AM, Dicebot wrote:
This was an answer to "you can't forward declare extern
(D) functions"
I think Sean's point is that is another historical reason why
we used extern(C), back when pragma(mangle) didn't
To address your question a bit more fully, it seems like this is
something the range proposal for C++ is better suited for. Then
appending would just be a special case of inserting at a specific
position. I've got to say, if I had the time I'd implement the
C++ ranges in D. They seem more power
It doesn't really address your question, but if you're mostly
inserting you may want to store it as a heap and sort before
lookup.
Also, eliminating compile time dependencies between namespaces.
Everything can import core.*, but nothing outside rt is allowed
to import rt modules and nothing outside gc is allowed to import
gc modules. This allows us to theoretically choose the compiler
runtime and GC at link time and also a
Or when you declare an instance of the variable, disable
auto-initialization via "=void", then do a memset(0).
On Saturday, 8 November 2014 at 00:21:52 UTC, Walter Bright wrote:
https://news.ycombinator.com/item?id=8574184
It's a good succinct writeup. Rust sounds pretty cool, if still
quite immature. The comments in Hacker News are enlightening as
well.
On Thursday, 6 November 2014 at 23:00:19 UTC, H. S. Teoh via
Digitalmars-d wrote:
So today, I was playing around with profiling and optimizing my
sliding
block puzzle solver, and found some interesting things:
1) The GC could use some serious improvement: it just so
happens that
the solver's a
On Monday, 3 November 2014 at 03:29:05 UTC, Walter Bright wrote:
I have considerable experience with what programs can do when
continuing to run after a bug. This was on real mode DOS, which
infamously does not seg fault on errors.
It's AWFUL. I've had quite enough of having to reboot the
o
I see generators as being somewhat like opApply in terms of how
they're written. So a single generator would recurve across the
entire tree. Allocating a new generator per node isn't going to
be very efficient, even if we optimize for that case.
On Wednesday, 29 October 2014 at 14:58:39 UTC, Russel Winder via
Digitalmars-d wrote:
Hopefully those companies then go to the wall. C++14 is the
only C++ in 2014.
Our current target platform is almost a decade old, so if current
trends continue, C++14 will be the only C++ in 2024.
In all
On Wednesday, 29 October 2014 at 06:30:14 UTC, deadalnix wrote:
https://code.google.com/p/go/source/diff?spec=svn11b6d55be06401b56985cb5c97d4f9829c980706&r=11b6d55be06401b56985cb5c97d4f9829c980706&format=side&path=/doc/go_mem.html
That sounds about right.
+1
On Wednesday, 29 October 2014 at 13:28:28 UTC, Bruno Medeiros
wrote:
Even if we could correctly differentiate between precondition
failures and postcondition ones, what would that gives us of
use?
It would give us an idea of where to look for the bug. Also, it
provides the option of discre
On Tuesday, 28 October 2014 at 07:59:32 UTC, Martin Nowak wrote:
On Monday, 27 October 2014 at 16:32:25 UTC, Sean Kelly wrote:
That's the reason why the await adapter is so powerful.
It's should be possible to await a promise (future) to let the
scheduler know that it should resume the Fiber onl
On Tuesday, 28 October 2014 at 08:02:23 UTC, Martin Nowak wrote:
On Monday, 27 October 2014 at 21:43:47 UTC, Sean Kelly wrote:
Yep. Every logical thread is a Fiber executed in a
round-robin manner by a pool of kernel threads. Pooled
threads are spun up on demand (to a set upper limit) and
te
On Monday, 27 October 2014 at 22:59:50 UTC, Brad Anderson wrote:
Again, just out of curiosity, have you ever looked at Windows
user-mode scheduling or Google's user-level threads[1][2]
(under 200ns context-switch times)? I first heard of them from
a post on the Rust forum[3] which suggested M
On Monday, 27 October 2014 at 20:54:38 UTC, Brad Anderson wrote:
Just out of curiosity, what's the goal of MultiScheduler? Is it
intended to be an M:N scheduler?
Yep. Every logical thread is a Fiber executed in a round-robin
manner by a pool of kernel threads. Pooled threads are spun up
o
On Friday, 24 October 2014 at 19:09:23 UTC, Walter Bright wrote:
You can insert your own handler with
core.assertHandler(myAssertHandler). Or you can catch(Error).
But you don't want to try doing anything more than notification
with that - the program is in an unknown state.
Also be aware t
On Sunday, 26 October 2014 at 16:12:29 UTC, Sean Kelly wrote:
On Sunday, 26 October 2014 at 15:35:28 UTC, FrankLike wrote:
Many persons like go's goroutine,but how about is the same
thing in D?
We need a better Scheduler. It's something I've been planning
to do, but had held off until the ba
On Sunday, 26 October 2014 at 20:47:47 UTC, Martin Nowak wrote:
How do you want to tackle the integration of Fibers/Schedulers
and blocking APIs? That's the more important part of goroutines.
http://blog.nindalf.com/how-goroutines-work/#goroutinesblocking
That will be tricky, since some of o
On Saturday, 25 October 2014 at 20:49:26 UTC, Walter Bright wrote:
https://github.com/D-Programming-Deimos
http://en.docsity.com/news/programming-2/free-libraries-for-everyday-work-in-popular-languages/
These appear to have C interfaces, so should be tractable for D
without too much effort.
On Sunday, 26 October 2014 at 03:37:47 UTC, Maxime
Chevalier-Boisvert wrote:
I also wanted to ask if there was an implementation of an
object pool in the standard library. If not, I'm wondering what
the best way to implement this is. Is there any way to overload
new and destroy?
Andrei has
On Sunday, 26 October 2014 at 15:35:28 UTC, FrankLike wrote:
Many persons like go's goroutine,but how about is the same
thing in D?
We need a better Scheduler. It's something I've been planning to
do, but had held off until the base Scheduler proposal was
accepted. At that point I think D w
On Saturday, 25 October 2014 at 15:20:53 UTC, Trass3r wrote:
This totally smells like a remnant as the code matches the
initial custom Win32 D ABI.
Yep. I thought the D calling convention matched the C calling
convention on 64-bit. Didn't Walter even state this explicitly
at some point?
Alright, done. It's a pretty interesting proposal. They are
effectively closures with coroutine-like semantics. It seems
like the overhead for a complex system might actually be greater
than with classic coroutines, as closure data allocations could
be happening all over the place, but this is
On Friday, 24 October 2014 at 10:33:40 UTC, Martin Nowak wrote:
This is so much better than Fibers.
http://youtu.be/KUhSjfSbINE
What I like most about the proposal is that you can adapt await
by specializing template functions, similar to how range based
foreach works.
It also isn't tied to a
Yes on a sufficiently old version of Linux you will have to
recompile DMD. I doubt this is the user's problem though, as
people in this situation are generally pretty used to
encountering this.
On Tuesday, 21 October 2014 at 19:32:17 UTC, Marco Leise wrote:
Do you think it would be bad if a pthread_mutex_t* was
declared as shared or only usable when shared ?
No. But the issue in general concerns me. Like say my class
contains a C style FILE*. If shared is transitive, then
fprintf(
On Tuesday, 21 October 2014 at 16:36:30 UTC, Marc Schütz wrote:
I think `shared` by itself is fine, as long as it is only take
to mean "this method can cope with the parameters being
shared". It's `synchronized` and casting that cause the
trouble, because they are too coarse, and synchronized
On Tuesday, 21 October 2014 at 13:10:57 UTC, Marco Leise wrote:
Am Mon, 20 Oct 2014 16:18:51 +
schrieb "Sean Kelly" :
But to the point: Doesn't defining it as shared means that it
can not have _any_ unshared methods? Ok, fair enough. So even
if a method is only working on technically unshare
On Monday, 20 October 2014 at 13:29:47 UTC, Marco Leise wrote:
What guarantees is shared supposed to provide?
Shared means that multiple threads can access the data. The
guarantee is that if it is not shared, and not immutable, that
only the current thread can see it.
What if I have a thread t
On Saturday, 18 October 2014 at 19:53:23 UTC, Sean Kelly wrote:
On Friday, 17 October 2014 at 18:27:34 UTC, Ary Borenszweig
wrote:
Once its done you can compare its performance against other
languages with this benchmark:
https://github.com/kostya/benchmarks/tree/master/json
Wow, the C++Ra
On Friday, 17 October 2014 at 18:27:34 UTC, Ary Borenszweig wrote:
Once its done you can compare its performance against other
languages with this benchmark:
https://github.com/kostya/benchmarks/tree/master/json
Wow, the C++Rapid parser is really impressive. I threw together
a test with m
All that said, after a quick scan I really like the range
proposal for C++. In particular, the idea of positions is a nice
one, as it addresses an awkward issue with D ranges.
On Friday, 17 October 2014 at 09:17:52 UTC, ZombineDev wrote:
I saw [this][0] proposal for adding ranges to C++'s standard
library. The [paper][1] looks at D style ranges, but concludes:
Since iterators can implement D ranges, but D ranges cannot be
used to implement iterators, we conclude that
On Saturday, 18 October 2014 at 05:10:20 UTC, Walter Bright wrote:
I understand that some have to work with poorly written
libraries that incorrectly use assert. If that's the only issue
with those libraries, you're probably lucky :-) Short term, I
suggest editing the code of those libraries,
Its a holdover from when we were trying to eliminate imports in
druntime because of the associated overhead. I'd submit a
bugzilla about it.
On Thursday, 16 October 2014 at 19:56:57 UTC, Dicebot wrote:
Libraries tend to be forked and modified. Libraries aren't
always tested in environment similar to specific production
case.
This seems relevant:
http://www.tele-task.de/archive/video/flash/16130/
On Thursday, 16 October 2014 at 18:53:22 UTC, monnoroch wrote:
So if both are true, that clearly means that the right solution
would be to introduce four categories: a cross product of the
obove:
- bugs, that are recoverable
- bugs, that are unrecoverable
- input errors, that are recoverable
-
On Thursday, 16 October 2014 at 18:49:13 UTC, Walter Bright wrote:
On 10/16/2014 6:46 AM, Sean Kelly wrote:
On Thursday, 16 October 2014 at 07:44:37 UTC, Walter Bright
wrote:
Don't throw Errors when you need to unwind. Throw Exceptions.
I.e. use enforce() instead of assert().
I'm more concern
On Thursday, 16 October 2014 at 07:44:37 UTC, Walter Bright wrote:
On 10/15/2014 6:54 PM, Sean Kelly wrote:
I hate to say it, but I'm inclined to treat nothrow the same
as in C++, which is
to basically pretend it's not a part of the language. The
efficiency is nice,
but not if it means that thr
On Wednesday, 15 October 2014 at 03:18:31 UTC, Walter Bright
wrote:
However, the compiler is still going to regard the assert() as
nothrow, so the unwinding from an Exception won't happen until
up stack a throwing function is encountered.
I hate to say it, but I'm inclined to treat nothrow t
Oh, it looks like you aren't checking for 0x7F (DEL) as a control
character.
On Sunday, 12 October 2014 at 19:40:56 UTC, Walter Bright wrote:
Programming languages are always imperfect models, it's like
the 2x4's you buy at the hardware store are never straight. You
just learn to deal with it, because perfectly straight ones
would be prohibitively expensive.
Well...
On Sunday, 12 October 2014 at 18:17:29 UTC, Andrei Alexandrescu
wrote:
** The string after lexing is correctly scanned and stored in
raw format (escapes are not rewritten) and decoded on demand.
Problem with decoding is that it may allocate memory, and it
would be great (and not difficult) to
It's a clean break and easy to fix, and eliminated a confusing
ambiguity. I'm all for it.
On Sunday, 5 October 2014 at 23:01:48 UTC, Walter Bright wrote:
Definitely unwinding may or may not happen from Error throws,
"nothrow" functions may throw Errors, and optimizers need not
account for Errors being thrown.
This is the real concern. If an Error is thrown out of a nothrow
func
On Sunday, 5 October 2014 at 18:06:49 UTC, Etienne wrote:
Programmers cost money, it would be nice to have a D Foundation
where companies can donate and maybe eventually use the funds
to pay for professional staffing rather than relying only on
contributors. The D foundation can eventually gr
On Thursday, 2 October 2014 at 10:37:02 UTC, Kevin Lamonte wrote:
Would PR
https://github.com/D-Programming-Language/phobos/pull/1910
provide a way given a Tid to determine: a) What underlying
concurrency model it is using (Thread, Fiber, process, future)?
b) Uniquely identify that structure
On Saturday, 4 October 2014 at 09:18:41 UTC, Walter Bright wrote:
Threads are not isolated from each other. They are not. Not.
Not.
Neither are programs that communicate in some fashion. I'll
grant that the possibility of memory corruption doesn't exist in
this case (a problem unique to sy
On Saturday, 4 October 2014 at 09:04:58 UTC, Walter Bright wrote:
Airplane avionics systems all abort on error, yet the airplanes
don't fall out of the sky.
To be fair, the's a function of aerodynamics more than system
design. But I see what you're getting at.
On Saturday, 4 October 2014 at 08:15:51 UTC, Walter Bright wrote:
On 10/3/2014 8:43 AM, Sean Kelly wrote:
My point, and I think Kagamin's as well, is that the entire
plane is a system
and the redundant internals are subsystems. They may not
share memory, but they
are wired to the same sensors
On Friday, 3 October 2014 at 17:51:16 UTC, monarch_dodra wrote:
Also, I don't think "postconditions" are meant to check
"callee" errors. That's what asserts do. Rather, postconditions
are verifications that can ony occur *after* the call. For
example, a function that takes an input range (no
On Friday, 3 October 2014 at 17:38:40 UTC, Brad Roberts via
Digitalmars-d wrote:
The part of Walter's point that is either deliberately
overlooked or somewhat misunderstood here is the notion of a
fault domain. In a typical unix or windows based environment,
it's a process. A fault within t
On Friday, 3 October 2014 at 18:00:58 UTC, Piotrek wrote:
And as I can see it, all subsystems related to the "small
failure" was shut down. But what is also important information
was not clearly provided to the pilots:
"Despite the fact that they were aware that altitude was
declining rapid
I finally realized what's been bugging me about thew program
logic error, airplane vs. server discussion, and rather than have
it lost in the other thread I thought I'd start a new one. The
actual problem driving these discussions is that the vocabulary
we're using to describe error conditions
On Friday, 3 October 2014 at 12:16:30 UTC, Jacob Carlborg wrote:
On 03/10/14 13:27, Kagamin wrote:
Do you interpret airplane safety right? As I understand,
airplanes are
safe exactly because they recover from assert failures and
continue
operation. Your suggestion is when seat 2A creaks, shut
On Wednesday, 1 October 2014 at 22:42:27 UTC, Jeremy Powers via
Digitalmars-d wrote:
If you see "throws Exception" in java code chances are the code
is broken,
same as if you see "catch (Exception" - this tells you nothing
about the
exception that happened, and hence you can do nothing with it
On Wednesday, 1 October 2014 at 17:53:43 UTC, H. S. Teoh via
Digitalmars-d wrote:
But Sean's idea only takes strings into account. Strings aren't
the only
allocated resource Phobos needs to deal with. So extrapolating
from that
idea, each memory management struct (or whatever other
aggregate
On Wednesday, 1 October 2014 at 08:55:55 UTC, Andrei Alexandrescu
wrote:
On 9/30/14, 9:10 AM, Sean Kelly wrote:
Quite honestly, I can't imagine how I could write a template
function in D that needs to work with this approach.
You mean write a function that accepts a memory management
policy,
On Wednesday, 1 October 2014 at 08:55:55 UTC, Andrei Alexandrescu
wrote:
On 9/30/14, 9:10 AM, Sean Kelly wrote:
Is this for exposition purposes or actually how you expect it
to work?
That's pretty much what it would take. The key here is that
RCString is almost a drop-in replacement for str
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:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub
On Tuesday, 30 September 2014 at 22:41:15 UTC, Sean Kelly 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 he
On Tuesday, 30 September 2014 at 21:19:44 UTC, Ethan wrote:
With a codebase like ours (mostly C++, some D), there's a few
things we need. Deterministic garbage collection is a big one -
when our C++ object is being destroyed, we need the D object to
be destroyed at the same time in most cases
On Tuesday, 30 September 2014 at 19:19:18 UTC, Steven
Schveighoffer wrote:
Hm... looked at the code, I have no idea how the GC would
handle user-defined stuff. It seems to only deal with bits it
knows about (i.e. APPENDABLE is specifically handled in gc/gc.d)
It wouldn't. The GC was just go
On Tuesday, 30 September 2014 at 17:51:18 UTC, Steven
Schveighoffer wrote:
On 9/30/14 1:23 PM, Sean Kelly wrote:
(except for the
definition of the APPENDABLE BlkAttr, which really should be
defined externally and within the user-reserved range of the
bitfield instead of the GC-reserved range, b
On Tuesday, 30 September 2014 at 15:46:54 UTC, Steven
Schveighoffer wrote:
So I made the call to put it at the beginning of the block,
which obviously doesn't change, and offset everything by 16
bytes to maintain alignment.
It may very well be that we can put it at the end of the block
inst
On Tuesday, 30 September 2014 at 13:42:14 UTC, Dicebot wrote:
Is such behaviour intended?
Yes. As far as the GC is concerned, asking for the size of an
interior pointer is asking for the size of a slice of the data,
and as slices are not extendable it will always return 0. All of
the APPENDA
1 - 100 of 250 matches
Mail list logo
