On Thursday, 25 December 2014 at 14:55:32 UTC, Xinok wrote:
On Thursday, 25 December 2014 at 10:52:07 UTC, Martin Nowak
wrote:
On Saturday, 20 December 2014 at 22:11:35 UTC, Xinok wrote:
(1) We need a precise garbage collector. The fact that a
garbage-collected language experiences memory
On Saturday, 20 December 2014 at 22:11:35 UTC, Xinok wrote:
I think the problem of memory management can be reduced to two
points:
(1) The garbage collector for D is sub-par.
I want to try out a few obvious things in the next couple of
weeks.
- better predictable memory access during markin
On Saturday, 20 December 2014 at 20:14:21 UTC, Ola Fosheim
Grøstad wrote:
1. A well thought out ownership system to replace GC with
compiler protocols/mechanisms that makes good static analysis
possible and pointers alias free. It should be designed before
"scope" is added and a GC-free runtim
On Tuesday, 23 December 2014 at 17:34:29 UTC, Dmitry Olshansky
wrote:
- final decision on @property
That one is easy, there is already a semi-offical decision.
http://wiki.dlang.org/DIP23
On Monday, 22 December 2014 at 09:05:03 UTC, Peter Alexander
wrote:
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak
wrote:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, prote
On Sunday, 21 December 2014 at 12:48:42 UTC, Dicebot wrote:
On Sunday, 21 December 2014 at 12:26:04 UTC, Jacob Carlborg
wrote:
On 2014-12-21 10:46, Dicebot wrote:
Stuff that immediately comes to my mind:
- some way to define implicit conversion from literals (done
at CT)
Any ideas on that?
On Monday, 22 December 2014 at 11:06:13 UTC, Francesco Cattoglio
wrote:
On Saturday, 20 December 2014 at 20:13:31 UTC, weaselcat wrote:
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak
wrote:
Unique! and RefCounted! in a usable state.
+1
No RefCounted classes and non-reentrant GC
On Saturday, 20 December 2014 at 19:22:05 UTC, safety0ff wrote:
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak
wrote:
Just wondering what the general sentiment is.
Multiple alias this (DIP66 / #6083.)
It's already in :), at least the DIP just got approved.
Would it really
We lost a big opportunity last year, so let's be better prepared
this time.
Application for organizations starts in 6 weeks on Feb 9,
deadline is Feb 20.
Any volunteer for managing the application?
There is a wiki page as a starting point
http://wiki.dlang.org/GSOC_2015_Ideas.
The ideas need
On Monday, 22 December 2014 at 11:55:36 UTC, Kagamin wrote:
- delegates is another type system hole, if it's not going to
be fixed, then it should be documented
We did fix a few things there, are the rest filed in Bugzilla?
- members of Object
???
- evaluate contracts at the caller side
-
On Wednesday, 24 December 2014 at 10:35:46 UTC, Paolo Invernizzi
wrote:
On Wednesday, 24 December 2014 at 02:38:02 UTC, Andrei
Alexandrescu wrote:
On 12/20/14 9:39 AM, Martin Nowak wrote:
Shared semantics and improving multithreading also come to
mind. -- Andrei
O God! +1000 ;-P
True, a
On Tuesday, 23 December 2014 at 15:49:46 UTC, Andrei Alexandrescu
wrote:
Congratulations, Igor! -- Andrei
Good news, congratulations Igor.
On Saturday, 20 December 2014 at 19:51:18 UTC, Benjamin Thaut
wrote:
Am 20.12.2014 18:39, schrieb Martin Nowak:
Shared library support on Windows ;-)
That's not really a language thing, but indeed important.
On Saturday, 20 December 2014 at 18:42:52 UTC, Vic wrote:
- find all features that are not being maintained or are just
top heavy and deprecate.
- find features that should or could be downstream, and
deprecate.
Any particular suggestions?
On Wednesday, 24 December 2014 at 22:52:12 UTC, Dicebot wrote:
On Wednesday, 24 December 2014 at 22:12:02 UTC, Andrei
Alexandrescu wrote:
An emerging pattern (which Walter will effect for dip69) is to
initially make it opt-in as a flag:
dip -dip69 test.d
Great!
+1
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, protection and visibility rules (DIP22, 313, 314)
- finishing non-GC memory management
On 12/20/2014 06:12 PM, Martin Nowak wrote:
On 12/17/2014 09:45 AM, Manu via Digitalmars-d wrote:
Other languages do much less than D which is a full-blown C++ replacement.
We've made huge progress in the past few years
Most important, we started to grow an ecosystem.
http://code.dlang.org/
On 12/17/2014 09:45 AM, Manu via Digitalmars-d wrote:
Well... when? I've been here 6 years. When can I start to use D for my work?
Other languages seem to have a higher velocity. Are we fighting a losing battle?
Other languages do much less than D which is a full-blown C++ replacement.
We've ma
On 12/15/2014 10:12 AM, Walter Bright wrote:
Would it work if I deleted the tags from the test branch?
Deleting the dub.json on the test branch should work.
But you can also leave things as they are, the test branch isn't available.
http://code.dlang.org/packages/dmdscript
On 12/15/2014 09:31 AM, Jacob Carlborg wrote:
I've complained about this before. As far as I know it's not currently
possible. I would rather tell dub myself which versions are available.
Not making all tags available that match a pattern.
Well here is the code
https://github.com/D-Programmin
On 12/13/2014 02:53 AM, Walter Bright wrote:
Dmitry Olshansky has graciously ported DMDScript (a Javascript engine
written in D) to D2.
https://github.com/DigitalMars/DMDScript
I have been trying to get it into dub, but have been stalled by the
following when I attempt to register:
Repos
On 12/14/2014 09:37 AM, Manu via Digitalmars-d wrote:
Sadly, I failed to create a new commercial D user this week, and I'm
really disappointed.
It was rejected for exactly the same practical reasons I've been saying forever.
Doesn't surprise me too much to be honest. We aren't there yet and I'm
On 12/14/2014 09:37 AM, Manu via Digitalmars-d wrote:
The real trouble hit when vibe.d's WebSocket support didn't work as
advertised; it crashed in various circumstances, and debugging was
impossible.
Please file that one https://github.com/rejectedsoftware/vibe.d/issues.
What browser did you u
The current issue is if I build a dynamic library with DUB and call
externals form another application, and my D code
allocates anything on heap, the calling process crashes with
SIGSEV.
Don't forget to link against libphobos2.so using -defaultlib=libphobos2.so.
Cross post from the D.announce newsgroup, to reach a broader audience.
http://forum.dlang.org/post/m6b7r2$18ri$1...@digitalmars.com
On 12/14/2014 03:50 PM, Gabor Mezo wrote:
Hello,
I've created a simple db dynamic lib project.
https://github.com/D-Programming-Language/dub/issues/352
On 12/12/2014 06:13 PM, Martin Nowak wrote:
No, you don't want to accept the answer. That's slightly different than
not getting none.
Let me amend that I'm glad you didn't run away and are still working on
separating kernel specific from libc specific stuff. That will help
On 12/12/2014 06:13 PM, Martin Nowak wrote:
On 12/12/2014 04:47 PM, Joakim wrote:
I asked about this on github but didn't get a good answer, so I'm asking
here. What's with all the repeated OS blocks in druntime?
No, you don't want to accept the answer. That's sl
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 unsupported OS, but many of these blocks don't have that
either.
Because i
ciency, control, and modeling power,
with safety and programmer productivity.".
https://www.youtube.com/watch?v=TH9VCN6UkyQ#t=1626
But to understand how much more productive D is in comparison to C++,
he'd have to actually code something.
-Martin
On 12/11/2014 10:34 PM, Walter Bright wrote:
D already does this. It's been said before, Jonathan is reinventing D,
piece by piece :-)
What does that mean, it's been said?
Didn't anyone actually try to tell him about D?
On 12/12/2014 11:42 AM, bearophile wrote:
Martin Nowak:
OK, I think that it will be enough to add a Phobos function like this
(what's the right Phobos module to put it?)
Did you just volunteer to make a pull :)?
As usual, having a problem to find the right place myself.
Would put it clo
On 12/12/2014 10:54 AM, bearophile wrote:
This code:
struct Vec { float x = 1, y = 5, z = 9; }
auto v = new Vec(void);
Means having defined a struct with explicitly statically defined fields,
and then allocate one of it on the heap without initializing its fields.
It's equivalent to:
auto v = c
On 12/11/2014 03:45 PM, Tobias Pankrath wrote:
std.container.Array is shadowed by std.container.Array!bool.
redBlackTree shadows RedBlackTree as well.
We fixed that issue already, please have a look at the preview.
https://dlang.dawg.eu/library/index.html
https://dlang.dawg.eu/library-prerelea
On 03/10/2014 03:56 PM, Andrei Alexandrescu wrote:
All: how does one turn off css hyphenation?
Andrei
You're again using that crappy JS hyphenation?
Last time we had a performance problem with it, I wrote this super
efficient D library http://code.dlang.org/packages/hyphenate.
It could easily
On 12/12/2014 02:05 AM, Martin Nowak wrote:
You're again using that crappy JS hyphenation?
No, you don't it's css hyphenation. Sorry for the tone.
On Thursday, 11 December 2014 at 12:22:46 UTC, Martin Nowak wrote:
Already submitted a bunch of pulls.
https://github.com/D-Programming-Language/dlang.org/pulls?q=is%3Apr+author%3AMartinNowak+is%3Aclosed
I'd be thankful for any help on that.
Cloning dlang.org and running make -f posi
What's up with this new website design ?
Drafts looked good.
Yeah, draft looks good, but this didn't got the priority and
support it deserves.
My plan is to incrementally improve the current website until it
looks reasonable.
Already submitted a bunch of pulls.
You can see a preview here http
On 12/10/2014 07:30 AM, Shammah Chancellor wrote:
I think meetups are a great way to evangelize.
And to colaborate
On 12/09/2014 05:22 PM, John Colvin wrote:
which of course Kenji already has a pull for, less than 3 hours later :)
It's right on time, it's right on time
ess
you give more details, you are not likely to get reasonable answers.
Just my opinion...
Martin
smime.p7s
Description: Elektronicky podpis S/MIME
On 12/08/2014 06:20 PM, John Colvin wrote:
To conceptually get what it's doing here, the trick is that it's
offsetting the values so as to simulate unsigned comparisons using
signed instructions.
All too easy, but would've taken me a pen and paper to realize :).
On 12/08/2014 06:05 PM, John Colvin wrote:
Well gcc gives me:
Tried that with dmd, it gave me.
bug.d(5): Error: incompatible types for ((a) >= (l)):
'__vector(ulong[4])' and '__vector(ulong[4])'
bug.d(5): Error: incompatible types for ((a) < (h)):
'__vector(ulong[4])' and '__vector(ulong[4])
On 12/08/2014 05:57 PM, ponce wrote:
This doesn't work if vhigh - vlow spans a too large area.
It won't unless you allocate more than 4GB of RAM.
On 12/08/2014 05:55 PM, John Colvin wrote:
I don't quite understand what you mean by "save one conditional".
Instead of
if (v >= low && v < high)
it's
if (cast(size_t)(v - low) < size)
So there is only one branch.
There are other ways to eliminate one branch, for example this.
if ((v >=
On 12/08/2014 06:21 PM, Etienne wrote:
Are you using it for the binary search part (find pool) ?
Nope the binary search is surprisingly fine, but I had it on my list of
subjects for quite a while too.
On Monday, 8 December 2014 at 16:32:50 UTC, Martin Nowak wrote:
Usually (scalar) I'd use this, which makes use of unsigned wrap
to safe one conditional
immutable size = cast(ulong)(vhigh - vlow);
if (cast(ulong)(v0 - vlow) < size) {}
if (cast(ulong)(v1 - vlow) < size) {}
over
if
{}
Maybe this can be used on SIMD too (saturated sub or so)?
-Martin
On 12/03/2014 09:36 PM, Jordi Sayol via Digitalmars-d wrote:
El 03/12/14 a les 19:49, Martin Nowak via Digitalmars-d ha escrit:
On 12/03/2014 02:01 AM, Brad Anderson wrote:
Why use the DigitalMars FTP?
http://downloads.dlang.org/ is the official place for them.
We should convince Brad to
On 12/07/2014 02:02 PM, Russel Winder via Digitalmars-d wrote:
I wonder if Copr could be used to create a Fedora project repository
for all the D bits and pieces in the way that D-Apt does things for
Debian?
https://fedorahosted.org/copr/wiki/UserDocs
Is it really worth the effort?
We're alre
On 12/07/2014 02:02 PM, Russel Winder via Digitalmars-d wrote:
I wonder if Copr could be used to create a Fedora project repository
for all the D bits and pieces in the way that D-Apt does things for
Debian?
https://fedorahosted.org/copr/wiki/UserDocs
There is a dmd.spec by Dejan Lekic, btw.
On 12/05/2014 09:15 AM, Shammah Chancellor wrote:
I didn't notice a D meetup group in SF. Is anyone else in here
interested in doing something like this once a month?
We could have a video cast over to the Berlin meetup :).
On 12/04/2014 03:32 PM, Daniel Murphy wrote:
FWIW I don't really like this - it feels like a hack. I'd rather just
declare a private logger alias (or something like that) and use that in
the library. Decision can be made at compile time, doesn't require
reverse module imports, doesn't depend on
On 11/18/2014 06:00 PM, Marco Leise wrote:
Without fully understanding the issue, omitting the frame
pointer on GNU amd64 systems is the default and is supposed to
work using DWARF debug information. So there should be no need
for a stack frame pointer, right?
Are you mostly concerned with Windo
On 11/18/2014 12:14 AM, Vladimir Panteleev wrote:
Personally, I think the 0.1% is practically negligible considering the
advantages. My proposal was rejected, so I'd like to hear more opinions
about this. What do you think?
If it were only 0.1% at maximum for any code, it wouldn't be a problem.
On 11/18/2014 06:15 PM, Vladimir Panteleev wrote:
And indeed, for printing the stack trace for an unhandled exception,
Druntime currently walks the stack frames:
We're working on that to replace it with more enriched DWARF processing,
e.g. to show line numbers.
On 11/19/2014 09:14 AM, Kagamin wrote:
I'm afraid, DWARF is not designed to unwind segfaults, it works only
with DWARF exceptions.
-fasynchronous-unwind-tables
On 11/18/2014 07:49 PM, Steven Schveighoffer wrote:
I refuse to let the fact that we package every platform's download into
one zip to be some sort of argument :) DMD is the only distribution that
I've ever seen do this.
We're shifting away from this, there are per-platform zips and
installer
On 12/04/2014 10:54 PM, Martin Nowak wrote:
On 12/04/2014 09:41 PM, Walter Bright wrote:
Yes, it would be written:
scope ref T setVal(ref T t)
{
t.val = 12;
return t;
}
But when there is no scope on the argument, I could not call setVal with
a local T variable.
Ah
On 12/04/2014 09:41 PM, Walter Bright wrote:
Yes, it would be written:
scope ref T setVal(ref T t)
{
t.val = 12;
return t;
}
But when there is no scope on the argument, I could not call setVal with
a local T variable.
On Thursday, 4 December 2014 at 12:57:59 UTC, Ben wrote:
Hi All,
I am a Berlin based D developer who has been working with D for
about 2 and a half years. Like other more well known names in
these forums I work for a company called Sociomantic.
I am interested in organizing some meetups for
On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP69
Great stuff.
Will this be possible, it's a fairly important use-case.
scope ref T setVal(scope ref T t)
{
t.val = 12;
return t;
}
Another question, how would a reference counted pointer tak
On Thursday, 4 December 2014 at 11:21:27 UTC, Marc Schütz wrote:
Errors for scope violations are only reported in @safe code.
Why? If I've explicitly designated a reference as scope, why
should it be ignored in un-@safe code?
Agreed, it should also work for any other code with some function
On Thursday, 4 December 2014 at 10:37:12 UTC, Robert burner
Schadek wrote:
That is much nicer, thank you for taking the time.
Couldn't way just say that we don't import __MODULE__ but
rather __MODULE__ ~ "_loggerinfo.d" and then describe the
import constraint in the documentation.
Importing
On Thursday, 4 December 2014 at 10:44:22 UTC, Ola Fosheim Grøstad
wrote:
I like the direction you are taking, but I think the better
solution is to have:
It's a nice idea for generic feature testing flags, but it's a
lot of implementation work in the compiler. And it seems odd to
implement a
On Thursday, 4 December 2014 at 10:37:12 UTC, Robert burner
Schadek wrote:
That is much nicer, thank you for taking the time.
Couldn't way just say that we don't import __MODULE__ but
rather __MODULE__ ~ "_loggerinfo.d" and then describe the
import constraint in the documentation.
Good idea,
On Thursday, 4 December 2014 at 08:42:36 UTC, Kagamin wrote:
Not bad. Does info="baz" compile?
That's not my business, if it's callable with a single argument,
it would work, but it's not @property.
On Thursday, 4 December 2014 at 08:14:56 UTC, Jacob Carlborg
wrote:
On 2014-12-04 02:10, Martin Nowak wrote:
I just found a very compelling alternative solution to the
LogLevel
disabling problem. This was one of the reasons for the delay
of std.log
and the current solution still isn't
On 12/04/2014 03:41 AM, Rikki Cattermole wrote:
Okay its a lot simpler and far less context specific.
One thing I think should be addressed is at runtime, to override these
defaults.
Just use a value instead of an enum, and you can configure the log level
at runtime.
https://gist.github.com/
I just found a very compelling alternative solution to the LogLevel
disabling problem. This was one of the reasons for the delay of std.log
and the current solution still isn't great [1].
This idea here achieves
- fine grained control over log levels (per module/package)
- zero overhead for sta
On 11/27/2014 10:30 AM, Gary Willoughby wrote:
There seems to be an effort to resurrect ctags[1] so i've taken the D
language support from this patch and applied it to the newly resurrected
ctags.
[1]: https://github.com/fishman/ctags
How about making turning it into a pull request?
On 12/03/2014 09:31 PM, Dmitry Olshansky wrote:
Yep, this is so because all unit tests live in a shared library.
Mmm. Why pack unittests into a shared library?
Well to test phobos as shared library, which is still supposed to become
the default at some point.
So we need a special test ru
On 10/30/2014 12:11 AM, Robert burner Schadek wrote:
That can actually be added to the current state of std.logger without
breaking any api. The string mixin, version string matching isn't really
pretty, but it gets the job done. Anyway IMO your approach presented
here and my approach can go hand
On 12/03/2014 09:58 PM, Walter Bright wrote:
Should be up now.
Thanks
On 12/03/2014 09:36 PM, Jordi Sayol via Digitalmars-d wrote:
year folder can be replaced by version folder. This will keep files tidy and
will make easier to maintain install scripts.
Even better +1
On 12/03/2014 02:01 AM, Brad Anderson wrote:
Why use the DigitalMars FTP?
http://downloads.dlang.org/ is the official place for them.
We should convince Brad to drop year subfolders (or add redirects), as
it makes it much harder to maintain install scripts.
On 12/02/2014 11:22 PM, MrSmith wrote:
Can i have interface compiled only in one dll, and others dlls that use
this one will not have it compiled, only import it?
Yes, you'd need to link against the dll containing the interfaces.
In fact you could link against your executable too, but that's a
On 12/03/2014 12:55 AM, H. S. Teoh via Digitalmars-d wrote:
struct S {
static import std.format;
alias format = std.format.format;
// ^^^ the above line is what makes s.format() break.
}
It's equivalent to
private alias format
On Tuesday, 2 December 2014 at 17:10:12 UTC, Jacob Carlborg wrote:
DMD 2.066.1 is missing in the Digitalmars FTP. The release
candidates are present but the final release is missing. This
breaks DVM.
I asked several times that it gets uploaded, but never received
any response.
Let's try it a
http://wiki.dlang.org/DIP22
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?
We should probably do something to identify all the downloads
coming from Travis-CI and other CI solutions.
On Thursday, 27 November 2014 at 21:41:41 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Nov 27, 2014 at 11:30:49PM +0200, ketmar via
Digitalmars-d wrote:
On Thu, 27 Nov 2014 23:17:34 +0300
Dmitry Olshansky via Digitalmars-d
wrote:
> Okay, so I'm prepping up a SCons build of Phobos. It com
On Thursday, 27 November 2014 at 20:17:55 UTC, Dmitry Olshansky
wrote:
What I know(?) so far:
1. First we build library in one go - trivial to reproduce.
2. Then we compile each unittest with -c and -deps to dump
actual dependencies.
Yes, we compile one object file per module because memory do
On 11/29/2014 05:25 PM, Robert burner Schadek wrote:
Yes, there is a lock free, thread local indirection now. That can be
used to build a lock free, thread local logger.
p.s. You should have taken the phun
I commented on the relevant commit.
https://github.com/burner/phobos/commit/8a3aad5df52
On Friday, 14 November 2014 at 21:49:09 UTC, David Nadlinger
wrote:
On Friday, 14 November 2014 at 21:46:00 UTC, Robert burner
Schadek wrote:
You can always roll your own non locking Logger, but the
default should be thread-safe.
You can't, since you need to inherit from Logger, which already
On Tuesday, 25 November 2014 at 14:29:12 UTC, ponce wrote:
On Tuesday, 25 November 2014 at 01:12:03 UTC, Walter Bright
wrote:
On 11/24/2014 4:51 PM, Brian Schott wrote:
On Tuesday, 25 November 2014 at 00:37:00 UTC, Walter Bright
wrote:
Anyone know anything about this?
https://www.reddit.com/r
On Saturday, 29 November 2014 at 00:20:38 UTC, Daniel Murphy
wrote:
I think @disabled with a custom message would be perfect for
this. static assert only works for templates.
We just need someone to implement this.
https://issues.dlang.org/show_bug.cgi?id=8728
On Thursday, 27 November 2014 at 21:52:27 UTC, MrSmith wrote:
Can you suggest a good way to design mod system? Where each mod
can depend on others and use their real functionality. All mods
should be in form of dlls.
No DLL per module, just releasing a complete Phobos.DLL. If you
want to ship
On 11/28/2014 01:12 AM, Andrei Alexandrescu wrote:
On 11/27/14 3:32 AM, Martin Nowak wrote:
Actually not too bad :).
https://dlang.dawg.eu/coverage/
https://coveralls.io/r/MartinNowak/dmd
Wow, coveralls.io looks pretty nice! -- Andrei
And there is actually D support to upload dmd coverage
On 11/21/2014 04:36 AM, Jonathan Marler wrote:
This could be useful for the standard library to expose different
implementations based on whether or not the application is using the GC.
https://issues.dlang.org/show_bug.cgi?id=9511
Actually not too bad :).
https://dlang.dawg.eu/coverage/
https://coveralls.io/r/MartinNowak/dmd
On 11/25/2014 11:01 AM, Kagamin wrote:
Maybe we can have a function, which will search the typeinfo based on
type name, like C++ does it?
No!
https://issues.dlang.org/show_bug.cgi?id=7020#c2
On 11/24/2014 07:20 PM, MrSmith wrote:
I've got little test here
https://gist.github.com/MrSmith33/8750dd43c0843d45ccf8#file-sharedmodule2-d-L17-L29.
I have one application and two dlls. Application loads both dlls, calls
their factory functions and then passes each IModule instance that it
got
On Wednesday, 19 November 2014 at 02:16:36 UTC, Steven
Schveighoffer wrote:
Any thoughts from the experts out there?
We'll throw the current implementation away and implement an open
addressing AA once we get to it. So don't worry about the load
factor right now.
https://github.com/D-Programm
On Monday, 17 November 2014 at 20:51:36 UTC, Walter Bright wrote:
Not only that, the runtime check would occur every time an
object is created, yet the .init will always be the same. Doing
this check would, I fear, cause people to disable invariants as
not worth the expense.
If it's init data
On Tuesday, 18 November 2014 at 00:51:03 UTC, deadalnix wrote:
On Monday, 17 November 2014 at 20:02:36 UTC, Martin Nowak wrote:
Walter is about to fix an old bug [1] so that invariants are
now called before destruction and for non-default construction.
A remaining question is whether
Walter is about to fix an old bug [1] so that invariants are now called
before destruction and for non-default construction.
A remaining question is whether invariants should also be called for
default construction [2].
[1]: https://github.com/D-Programming-Language/dmd/pull/4136
[2]: https:/
On Friday, 31 October 2014 at 15:35:55 UTC, Dicebot wrote:
On Tuesday, 28 October 2014 at 22:03:18 UTC, Martin Nowak wrote:
2nd iteration of that idea.
For me it looks like the cure is worse than the disease. Simply
not distributing precompiled libraries with log level
force-reduced (or at
On Wednesday, 29 October 2014 at 23:11:44 UTC, Robert burner
Schadek wrote:
That can actually be added to the current state of std.logger
without breaking any api.
Just a few additions to handle LoggerCT (which needs a better
name).
Anyway IMO your approach presented here and my approach can
On Wednesday, 29 October 2014 at 23:16:28 UTC, Robert burner
Schadek wrote:
The reason for the crowbar sometimes you need to disable all
calls to the Logger or any calls to a specific LogLevel in the
compile unit, even for Logger not wrapped in LoggerCT.
Only that there is no clean boarder bet
701 - 800 of 1785 matches
Mail list logo
