On Thursday, 28 May 2015 at 03:09:07 UTC, ketmar wrote:
i think
that there is some sense in trading some speed for better
distribution.
what do you think?
We discussed most part of this already.
http://forum.dlang.org/post/mff4id$hj8$1...@digitalmars.com
And we're already using MurmurHash3
On Wednesday, 27 May 2015 at 21:24:25 UTC, bitwise wrote:
Basically, I've gone back to the idea of using the dylib
ctor/dtors. I don't think we really even need the image-added
callback, at least not for dylibs.
Looks good. The compiler could add a simple ctor/dtor to any D
object.
On Thursday, 28 May 2015 at 20:22:44 UTC, rumbu wrote:
- lack of a decimal data type - you cannot perform monetary
calculation using floating point.
http://dlang.org/phobos/std_bigint.html?
- lack of a chinese or japanese calendar in the std.datetime
module;
- missing of overflow checks for
On Friday, 29 May 2015 at 09:50:29 UTC, weaselcat wrote:
Walter said likely/unlikely won't be implemented as the
compiler already assumes the first condition is the more likely
one the last time this was brought up.
That is not what he said
On Friday, 29 May 2015 at 11:22:53 UTC, IgorStepanov wrote:
Sorry, I meant
f.opIndex!(true)(5).opIndexAssign(Foo(42), 3);
Added to the ER.
https://issues.dlang.org/show_bug.cgi?id=7753#c6
On Friday, 29 May 2015 at 13:12:58 UTC, IgorStepanov wrote:
Thanks, but unfortunately, writing enhacement request to
bugzilla is equals to writing to /dev/null :)
No it's not, it keeps us from rediscussing the same stuff over
and over.
I'll create a DIP about this, when I'll have a free
On Friday, 29 May 2015 at 13:12:58 UTC, IgorStepanov wrote:
What do you want about this syntax? Maybe you may suggest a
better solution?
The discussion drifts a little OT, if we have opIndexCreate, then
the library AA can be more compatible, but it still won't be a
drop-in replacement.
On Friday, 29 May 2015 at 21:58:16 UTC, IgorStepanov wrote:
I suggest you to answer to the following two question:
1. What way to transit to the new AA would be acceptable?
One that doesn't break any code, carefully deprecates necessary
semantic changes, and provides an improved
On Friday, 29 May 2015 at 12:55:13 UTC, Chris wrote:
Fair play to you! We should bundle these efforts. What about a
page where we collect all this stuff like I miss this feature
in D, and here's my own library for it. We all have stuff like
this in the attic somewhere.
http://code.dlang.org/
On Tuesday, 26 May 2015 at 16:25:52 UTC, bitwise wrote:
Isn't it better to avoid private undocumented functions?
Not only better, but mandatory, otherwise Apple will reject the
app from the app store.
Calling back into an unloaded image without proving a mean to
deregister the callback is a
On Wednesday, 27 May 2015 at 06:45:49 UTC, Jacob Carlborg wrote:
I'm not sure. The ___tls_get_addr function [1] is used when
accessing a TLS variable on OS X. In all native
implementations, both on OS X and Linux, the parameter is not
just a void* but struct containing the image header as
On Monday, 25 May 2015 at 23:39:18 UTC, IgorStepanov wrote:
On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
BTW, I have one idea. We may declare the AA ABI:
AA is a
On Tuesday, 26 May 2015 at 16:25:52 UTC, bitwise wrote:
Since all global functions and symbols are shared between
images anyways, receiving the callback in the main image would
be fine. So in this case, unregistering the callbacks is no
longer needed.
That only works when the host executable
On Sunday, 24 May 2015 at 15:13:41 UTC, Vladimir Panteleev wrote:
Could you elaborate on what these magic semantics are?
and no easy solution exists for the ++aa[key1][key2] case.
Is this specific to the pre-increment? aa[key1][key2]++ is
generally a useful pattern.
This applies to
On Monday, 25 May 2015 at 14:33:43 UTC, bitwise wrote:
At this point, my impression is that it would be very
impractical, if not impossible to have separate druntimes for
each shared library. Even when you do link separate runtimes,
dyld still treats all the exported symbols as shared.
Yes,
On Monday, 25 May 2015 at 19:40:52 UTC, bitwise wrote:
1) _dyld_register_func_for_add_image should be taken care of
with the above two fixes
You still cannot unregister the callback, so it can't be used for
dynamically loading druntime. Last time we talked about this
problem, we found some
Would be interesting to get some opinions on this.
https://github.com/D-Programming-Language/druntime/pull/1282
On Wednesday, 20 May 2015 at 21:35:38 UTC, bitwise wrote:
Heh.. That's pretty useless. Any idea on the state of things?
Like if there are plans to support this in the near future(few
months)? I couldn't find many conversations on this. This
kinda-totally ruins my plans(on OSX at least).
Have
On Thursday, 21 May 2015 at 08:07:49 UTC, Jacob Carlborg wrote:
I don't think anyone is working on this. Native TLS is a
prerequisite which requires changes both to the compiler and
the runtime. There's an enhancement request for native TLS [1].
One could also make emulated TLS work with
On Wednesday, 20 May 2015 at 17:28:50 UTC, Andrei Alexandrescu
wrote:
1. How to update Pmiss efficiently? Most allocations should be
fast, so it shouldn't be update with every call to allocate().
What I have now is I update every K calls.
A one-pole low pass filter is a very efficient moving
On Thursday, 21 May 2015 at 01:31:37 UTC, bitwise wrote:
I've been reading over all the bugs and conversations I can
find, but I'm still confused about exactly what's going on here.
What I need:
-load a dynamic library on OSX using dlopen or
Runtime.loadLibrary
-use dlsym to retrieve my
On Wednesday, 20 May 2015 at 17:28:50 UTC, Andrei Alexandrescu
wrote:
There is a bothersome issue with freelists fronting
general-purpose allocators
(https://en.wikipedia.org/wiki/Free_list): they can grow
indefinitely. Because they keep memory allocated in their
parent, they cause
On Thursday, 21 May 2015 at 15:51:38 UTC, bitwise wrote:
I'm not sure exactly what you mean about integrated runtime.
I think he means Phobos/Druntime as shared library.
Looking in /usr/share/dmd/lib, I see phobos as a static library
(which I'm assuming includes druntime, which I don't see
On Tuesday, 19 May 2015 at 07:56:27 UTC, Atila Neves wrote:
Aren't predictable branches cheap on current architectures?
Yes they are, and it seems one would rarely if ever call isPowOf2
with 0 in std.allocator. A good thing to do, is to use a good
hardware event profiler like perf, and
On Saturday, 16 May 2015 at 09:07:57 UTC, Iain Buclaw wrote:
or have it's mangled symbol be renamed to something other than
a 'V' that does not clash with other types/identifiers.
Well, change it to whatever letter works, if that resolves
mangling ambiguities.
On Monday, 11 May 2015 at 21:18:53 UTC, Walter Bright wrote:
D already does (for Win32) a generic compression on names. It
works a lot better than poorly reinventing compression - it's
far less complex, less buggy, easier to implement, etc.
I'd support adding a Win32-like compressor. The
On Monday, 11 May 2015 at 09:33:42 UTC, weaselcat wrote:
here's a single symbol from my project
The underlying problem is that symbols names grow quadratically
when combining templated ranges, because each range's name is a
template argument to the next range. Sometimes name occur twice,
as
On Friday, 8 May 2015 at 05:26:01 UTC, Benjamin Thaut wrote:
And Step 2) at program start up time. This means that symbols
don't have identity. If different shared libraries provide the
same symbol it may exist multiple times and multiple instances
might be in use.
Can you elaborate a bit on
On Sunday, 3 May 2015 at 12:42:23 UTC, Dzugaru wrote:
Just did another test and it seems its not safe at all. Reusing
the fibers with reset without properly exiting the function
leads to eventual stack overflow.
It won't cleanup the old stack, so it may leak resources. It will
properly reset
On Sunday, 3 May 2015 at 01:57:45 UTC, Jens Bauer wrote:
I'll not be working much on a malloc, but I will be thinking a
little about a size-optimized / well-performing malloc could be
written (approximately).
Perhaps I could combine my MiniMalloc with clusters of small
blocks.
Newlib already
On Sunday, 3 May 2015 at 12:33:36 UTC, Dzugaru wrote:
Documentation says This fiber must be in state TERM. but in
the core.thread I see In contract only on reset without
parameters (bug maybe?) and with HOLD condition too:
assert( m_state == State.TERM || m_state == State.HOLD );
Does that
On Friday, 1 May 2015 at 23:22:31 UTC, Dennis Ritchie wrote:
Maybe someone will show a primitive packed array. I really can
not imagine how to do it on D.
Look at BitArray for an example
On Sunday, 3 May 2015 at 04:15:58 UTC, Mike wrote:
My idea:
1. Members of the D leadership/committers form a working group.
2. The working group creates of list of bugs they are willing
to work on.
3. Hackathon is announced. To motivate participants, the
working group agrees to fix a bug of
On Sunday, 3 May 2015 at 04:15:58 UTC, Mike wrote:
My idea:
1. Members of the D leadership/committers form a working group.
2. The working group creates of list of bugs they are willing
to work on.
3. Hackathon is announced. To motivate participants, the
working group agrees to fix a bug of
On Sunday, 3 May 2015 at 00:59:07 UTC, Mike wrote:
I suggest refraining from requiring or preventing any feature,
including garbage collection and exceptions. Rather, we can
gradually make each feature available as the need arises, and
the user can opt in and make their own tradeoffs.
Yes
On Monday, 27 April 2015 at 17:25:50 UTC, Johannes Pfau wrote:
Since 2.066 the binaries on gdcproject.org are built with
crosstool-NG
(and an additional D script) in a docker container.
That's interesting, do the Windows binaries have some binary
dependency on MinGW?
It currently seems that
On Saturday, 2 May 2015 at 04:53:51 UTC, Jens Bauer wrote:
The problem I've seen with most C-solutions, is that once
someone uses printf, the binary suddenly grows out of
proportions. (It may be because the programmer included a line
for debugging only, and that causes the otherwise 1K program
On Saturday, 2 May 2015 at 08:33:34 UTC, Timo Sintonen wrote:
It is ok for me and it is used in our production code that does
not yet use D. I am still open for other solutions.
These functions should be at least extern C because library
code written in C may use them.
Newlib already comes
On Saturday, 2 May 2015 at 04:53:51 UTC, Jens Bauer wrote:
Is it possible to write the malloc so it's garbage
collector-friendly ?
Garbage collection on microcontrollers doesn't make sense,
because the memory consumption will always be significantly
higher than with deterministic memory
On Friday, 1 May 2015 at 06:57:08 UTC, Timo Sintonen wrote:
* Is dynamic memory allocation a requirement of D, or a
library feature?
We should agree whether we are making only yet another C
compiler or do we want the D compiler. The ability to use
object oriented features was the reason I
On Saturday, 2 May 2015 at 08:46:56 UTC, Timo Sintonen wrote:
Std.format, as suggested, would be too big. I tis easty to copy
the printf formatter from libc sources. Or just write an own.
No need to rewrite libc, just link against it and use whatever is
needed.
It is a matter of taste if it
On Friday, 1 May 2015 at 19:45:18 UTC, Walter Bright wrote:
I suspect this kind of change and check would be appropriate
for a D linter, and not be part of the core language.
Yes it would fit nicely into a static analyzer, but DMD is
currently the only semantic analyzer we have.
On Saturday, 2 May 2015 at 15:15:50 UTC, Jens Bauer wrote:
Will it be possible to have associative arrays without garbage
collection ?
You can write an AA container. A RefCounted AA implementation
might allow unsafe escaping though.
What about dynamic strings and dynamic arrays, don't they
On 04/30/2015 08:43 AM, Timo Sintonen wrote:
Printf is a little tricky. It is actually a file operation to stdout and
that is actually a syscall to kernel.
No, you usually have to implement some hook for outputting yourself,
e.g. putc or write, printf solely takes care of the formatting.
On 04/30/2015 01:30 PM, Mike wrote:
While this may seem simple to achieve, I think it will raise a few
questions that will need answering.
* Can ModuleInfo be leveraged, without introducing overhead, to call
module constructors and static constructors? They might be useful for
hardware
On 04/27/2015 03:42 PM, Timo Sintonen wrote:
The basic idea has been to make as little changes as possible. I started
by compiling object.d and then added files and modified them one by one
until there were no compile or link errors. Then I added other files
that could be compiled without
On 04/29/2015 09:15 PM, Jonathan M Davis wrote:
Yeah, but I think that it's safe to say that std.allocator is not the
normal case
std.allocator really isn't a general example.
I'm exclusively using if (ary.length) or if (!ary.empty) in my code to
avoid the problem.
Occasionally I'm using if
https://issues.dlang.org/show_bug.cgi?id=13454
A fairly simple solution to this would be to compile unittests
only for root modules (the ones that are part of the
compilation), not for imported modules.
Then everyone can decide for which modules to use -unittest.
On 04/27/2015 09:52 AM, Per =?UTF-8?B?Tm9yZGzDtnci?=
per.nord...@gmail.com wrote:
Does someone have any answers to these questions or should I wait until
the prel. pull request is done?:
•Figure out a way to template-parameterize radixSortImpl to make it
work on aggregate element types
On Monday, 27 April 2015 at 10:56:17 UTC, Steven Schveighoffer
wrote:
Everything to alter is in lifetime.d. It would be trivial to
create this.
https://issues.dlang.org/show_bug.cgi?id=13988
The only thing is to have a malloc-based AA for tracking
On Sunday, 26 April 2015 at 22:05:36 UTC, Dicebot wrote:
Side note : when updating Arch package to 2.067.1 I decided to
add `-L-lcurl` option to default `dmd.conf` in context of
recent discussion on topic. Please report if that causes any
issues with link order bugs - I couldn't trigger any
On Monday, 27 April 2015 at 05:30:55 UTC, Timo Sintonen wrote:
One of the biggest issues has been the multilib build. If it is
solved now we are one step closer to be able to build binaries.
Great, I tried to find out how GDC binaries are build, but
couldn't find any script.
How much stuff
On 04/26/2015 05:55 PM, Jens Bauer wrote:
Done.
http://wiki.dlang.org/Microcontroller_startup_files
-This is my first successful Wiki page, BTW. :)
Nice, minilibd seems to be maintained as well, you happen to know the
author?
I'd really like to see binary releases of GDC for arm-none-eabi
On 04/26/2015 08:18 AM, Rikki Cattermole wrote:
I already asked on D.ldc. No reply.
I even included links to the differences between what PNaCL supports and
LLVM IR.
What are they supposed to say? Obviously doable but requires lots of work.
This is one of those particular interests that
On 04/26/2015 12:58 PM, Daniel Murphy wrote:
Yes, if we had an AA in phobos.
Yes, I think phobos should get a few more optimized containers.
SparseSet
DenseSet
SparseHash
DenseHash
They should be configurable w.r.t. load factor, equality comparison, and
allocation policy (when std.allocator
On 04/26/2015 07:29 PM, Jens Bauer wrote:
I may be able to put together some kind of recipe for building the
GCC+GDC I have.
Unfortunately, I have not been able to build with multilib yet, so my
setup cannot build code for Cortex-M0; it keeps stuffing Cortex-M3 and
Cortex-M4 instructions in
We're glad to announce dmd 2.067.1 which includes several regression and
bug fixes over 2.067.0.
http://dlang.org/changelog.html#2.067.1
Please report any bug you encounter at https://issues.dlang.org/.
On 04/26/2015 09:16 AM, Per =?UTF-8?B?Tm9yZGzDtnci?=
per.nord...@gmail.com wrote:
I have a radix sort implementation at
https://github.com/nordlow/justd/blob/master/intsort.d#L92intsort.d
which beats Phobos own Quicksort by a factor 1.5 to 4 depending on
element type (Intergral or
On 04/23/2015 05:29 PM, Steven Schveighoffer wrote:
https://github.com/D-Programming-Language/druntime/pull/1229
It would be interesting to know how the new AA performs in this test.
Went from 11s down to 9s, ~20% improvement.
On Saturday, 25 April 2015 at 07:04:58 UTC, Jens Bauer wrote:
Things that can be recycled would be carefully written drivers,
such as LCD drivers that uses the SPI protocol. The SPI
interface itself cannot be recycled, though, as each device has
different SPI hardware and different GPIO
On Saturday, 25 April 2015 at 05:07:04 UTC, Jens Bauer wrote:
I hope to find a good way to use import for microcontroller
libraries, so it'll be easy for everyone. I'm thinking about
something like ...
import mcu.stm32f439.all
I think that belongs in the makefile/dub.json as
On Saturday, 25 April 2015 at 05:07:04 UTC, Jens Bauer wrote:
While I remember it ... I had to nullify a number of imports in
stdint. They simply do not belong in there. :)
Eg. I do not want FILE* if I aks for stdint. But FILE* is
forced upon me, because wchar_t includes it. What does a
On Saturday, 25 April 2015 at 07:31:45 UTC, Jens Bauer wrote:
I wonder if you can get e.g. interfaces and classes working.
I hope I will. ;)
I think classes are really a must. The only thing that I
(currently) see that could perhaps block this from working,
would be missing support for
On 04/24/2015 12:08 PM, extrawurst wrote:
let's just use the github stars system. i guess the github API allows us
to query those too. maybe we can even star a project from the registry
too ?!
Interesting idea, but github centric. We already have download numbers
and would just need to cache
Just want to make this a bit more visible.
https://github.com/D-Programming-Language/phobos/pull/3206#issuecomment-95681812
We just added entabber to std.phobos, and AFAIK, it's the first range
algorithm that transforms narrow strings to a range of chars, instead of
decoding the original string
On 04/23/2015 05:43 PM, Jesse Phillips wrote:
In order to keep the projects in code.dlang.org relevant, I think it is
important that we provide a way to have the primary project change
hands, rather than require the fork be placed on to code.dlang.org too[2].
Write a mail to Söhnke, he can
On 04/23/2015 08:49 PM, Steven Schveighoffer wrote:
If you are going to fork, you need to give it a new name. This is
standard practice for open source projects.
It's a common practice on github to take over small but no longer
maintained projects. You give credit to the original author and
On 04/24/2015 10:44 PM, Walter Bright wrote:
4. Autodecoding is inefficient, especially considering that few
algorithms actually need decoding. Re-encoding the result back to UTF8
is another inefficiency.
I'm afraid we are stuck with autodecoding, as taking it out may be far
too disruptive.
On Saturday, 25 April 2015 at 01:32:16 UTC, Jens Bauer wrote:
This is most likely where the egg cracks open. i'm pretty sure
we willl see people migrating to using D (at first a mixture
between D and C, because of the libraries from the vendors),
but later, there'll surely be projects which
On Friday, 24 April 2015 at 02:09:06 UTC, Walter Bright wrote:
On 4/23/2015 6:26 AM, Steven Schveighoffer wrote:
I agree it should have been done, not saying it's OK to break
the process in
some cases. I'm just explaining why it probably happened the
way it did.
Yes, it should have been
On 04/22/2015 06:10 PM, Namespace wrote:
Any changelog to compare 2067 and 2067.1?
Just a few regression fixes, see the github comparisons in the OP.
On 04/18/2015 07:21 PM, Shammah Chancellor wrote:
1) SDC, libd-llvm, and libd together are ~ 30KLOC of idiomatic and very
intelligible D code. Compare this with the 300KLOC for the DMD frontend.
1.1) The 30KLOC is clean and easy to get into. It took me less than
3 days to get into it and
On 04/22/2015 01:36 PM, Dicebot wrote:
-d is your enemy, If you remove that, there will be a clear warning
Deprecation: variable XXX.S.FLAG_ON immutable field with initializer
should be static, __gshared, or an enum. You decided to ignore and hide
it, why the surprise about the breakage?
On 04/22/2015 08:49 AM, Dan Olson wrote:
Mind if I add it then? I've lived with etags for so long that my
fingers automatically reach for M-. for D names too.
Please do, it would be really helpful, at least to me.
Interesting trivia, I even found this bug in the documentation of the
first dmd release http://downloads.dlang.org/releases/0.x/0.100/dmd.100.zip.
Checking For Empty Strings
C++ strings use a function to determine if a string is empty:
string str;
if (str.empty())
On Wednesday, 22 April 2015 at 07:18:36 UTC, ponce wrote:
OT: How to know the list of D compilers available on Travis CI?
Any release/pre-release is available, and it's now also possible
to use the latest dmd, gdc, and ldc release by omitting the
version suffix.
On Saturday, 18 April 2015 at 15:24:27 UTC, w0rp wrote:
@nogc
void main() {
throw new Foo(Oh no!);
}
Though until https://issues.dlang.org/show_bug.cgi?id=14119 is
resolved the tracehandler GC allocates anyhow.
Why are malloc exceptions better then gc exceptions? Are you
throwing so many
First beta for the 2.067.1 point release.
http://downloads.dlang.org/pre-releases/2.x/2.067.1/
http://ftp.digitalmars.com/
Also available on Travis-CI as dmd-2.067.1-b1.
This beta comes with 9 dmd, 1 druntime, and 3 phobos fixes.
On Tuesday, 21 April 2015 at 15:36:28 UTC, Jadbox wrote:
What's the best equivalent to Rust's structural enum/pattern
(match)ing? Is it also possible to enforce exhaustive matches?
Basically, I'm curious on what the best way to do ADTs in D.
If it needs to be really fast, use final switch on
On Monday, 20 April 2015 at 13:28:57 UTC, John Colvin wrote:
The only special thing to take in to account is that valgrind
will choke on DMD generated floating point code
I actually fixed this problem a while ago.
https://github.com/D-Programming-Language/dmd/pull/4368
An actual problem with
On Sunday, 19 April 2015 at 23:38:49 UTC, Freddy wrote:
C libraries have a pattern of
HiddenType* getObj();
void freeObj(HiddenType*);
Is there any way I can make the GC search for a HiddenType*
and run freeObj when the pointer is not found.
You can't turn an arbitrary pointer into
On 04/09/2015 04:44 AM, Andrei Alexandrescu wrote:
The idea is to spend a week concentrating efforts on writing code for
all aspects of D (with a focus on, but not limited to, D's github
repos). Should be fun! At the end of the week we'll count the bugs fixed
and pulled PRs and compare them
On Sunday, 12 April 2015 at 22:45:37 UTC, Zach the Mystic wrote:
The basic suggestion is that D has a function attribute which
expressly indicates that a function is separately compiled,
thus eliminating all ambiguity and mystery about what can and
can't be inferred.
Yeah, as you already
On Sunday, 12 April 2015 at 07:12:47 UTC, Walter Bright wrote:
At one point, I had implemented it for auto return functions,
because the source must exist for them, too, but it got a lot
of resistance and was dropped.
I thought that was already in, but it isn't.
On Sunday, 12 April 2015 at 08:55:17 UTC, Walter Bright wrote:
There's still an issue of a private function being called by a
template, and the definition of that private function is
compiled separately.
That's the problem of the author of that template. He would still
have to annotate that
On Sunday, 12 April 2015 at 07:17:07 UTC, Walter Bright wrote:
On 4/11/2015 4:33 AM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Saturday, 11 April 2015 at 09:41:07 UTC, Walter Bright
wrote:
A quick read of this suggests it is doing the Rust model of
only one mutable reference at
On Sunday, 12 April 2015 at 02:07:54 UTC, weaselcat wrote:
I thought as much, that's unsettling because dmd is already
starting to feel dog slow.
We might have some sort of performance bug in the latest release.
https://issues.dlang.org/show_bug.cgi?id=14431
If you know how to use a profiler,
On Sunday, 12 April 2015 at 12:06:50 UTC, bearophile wrote:
I think D Zen asks for safety on default and opt-out on request.
Marc talked about unique ownership vs. shared ownership, not
about safe vs. unsafe.
On Sunday, 12 April 2015 at 09:42:19 UTC, Daniel N wrote:
FYI, I wrote an enhancement request for this already. In case
the discussion reaches a conclusion this time around, you might
want to update the status:
https://issues.dlang.org/show_bug.cgi?id=13567
Oh great, can you help me to turn
On 04/11/2015 01:03 PM, w0rp wrote:
At the moment, auto-decoding isn't part of the language
That won't change anytime soon.
Sorry to open yet another topic.
I'm repeatedly finding myself in situations where I write functions like
this.
private @property bool empty() const @safe pure nothrow @nogc
{
return impl is null || !impl.count;
}
This is obviously a joke, because the compiler very well
On Friday, 10 April 2015 at 21:26:14 UTC, Walter Bright wrote:
This would be a bad design of an RCO. RCO's must be constructed
to not allow pointers to the payload other than by ref.
And taking the address of that is already unsafe.
On 04/09/2015 01:10 AM, Walter Bright wrote:
http://wiki.dlang.org/DIP77
It's a very interesting proposal to tackle this specific problem.
As with all the scope/lifetime related stuff, I find it extremely
difficult to anticipate all the needs and foresee how this will
integrate with the rest of
On 04/05/2015 05:16 AM, Andrei Alexandrescu wrote:
Right now the allocator design works well as a flexible malloc/free
implementation, but has no support for tracing-based garbage collection.
I am evaluating whether I should add tracing capabilities to
std.allocator, or stop here. Tracing
On 04/12/2015 12:35 AM, weaselcat wrote:
How does this differ from e.g, if the function was templated?
It doesn't, if you decide to analyze each imported function to perform
attribute inference, then that's just like treating all of them like
template instances.
This approach doesn't scale to
On Friday, 10 April 2015 at 13:44:27 UTC, Daniel Murphy wrote:
Who wouldn't? But realistically, how many more years until
that happens?
I'll better change it right now, have been cooking up some stuff.
On Friday, 10 April 2015 at 07:54:44 UTC, Daniel Murphy wrote:
It only works with integral types of at most 32-bits at the
moment, but most built-in types are fairly easy to support.
The downside is requires re-implementing druntime's AA and
hashing algorithms in the compiler, and keeping
On 04/10/2015 07:28 PM, Steven Schveighoffer wrote:
Also empty should work for AAs.
How should abc.front work? Do you want to move unicode decoding of
char and wchar arrays into object.d?
We already have unicode decoding in druntime, the old and slow version
though. Wouldn't cost much to
On 04/09/2015 01:10 AM, Walter Bright wrote:
http://wiki.dlang.org/DIP77
In the first problem example:
struct S {
RCArray!T array;
}
void main() {
auto s = S(RCArray!T([T()])); // s.array's refcount is now 1
foo(s, s.array[0]); // pass by ref
}
void foo(ref S s,
901 - 1000 of 1476 matches
Mail list logo
