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
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 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
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
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/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 09:58 PM, Walter Bright wrote:
Should be up now.
Thanks
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
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
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?
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
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.
http://wiki.dlang.org/DIP22
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
On Monday, 1 December 2014 at 07:53:05 UTC, Walter Bright wrote:
Well, I had tagged 1.0.0, then fixed a problem :-)
Well 1.0.0 is reserved for the first stable release, usually
you'd begin with 0.1.0 or so.
Good idea BTW.
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
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
digitalmars-d@puremagic.com wrote:
Okay, so I'm prepping up a
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: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
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 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?
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 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.
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
Actually not too bad :).
https://dlang.dawg.eu/coverage/
https://coveralls.io/r/MartinNowak/dmd
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
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/18/2014 08:34 PM, Walter Bright wrote:
Should say in the title that you reduced build times by 60%. Otherwise,
have to read all the way to the end to find it!
It's a great statistic, and having it in the title people will have more
reason to read the article.
Thanks for the tip, I now
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.
On Tuesday, 18 November 2014 at 13:37:54 UTC, Lázaro Armando via
Digitalmars-d-learn wrote:
this is very old. try git HEAD instead, it should help.
How could I do that using dub?
Running `dub upgrade` should be enough as a new version of vibe.d
was just released.
On 11/01/2014 10:02 PM, Nordlöw wrote:
Could you add a reference on how to DUB-build a library as dynamic
instead of static library to easy the process for newcomers?
Not really, as I said in the article.
Shared libraries are still a bit cumbersome to use with dub though.
Basically I just
Second part on my series to reduce vibe.d turnaround time.
In this part we'll reduce compilation time by 60%.
https://code.dawg.eu/reducing-vibed-turnaround-time-part-2-less-compiling.html
-Martin
On Tuesday, 18 November 2014 at 00:55:31 UTC, Vladimir Panteleev
wrote:
On Tuesday, 18 November 2014 at 00:41:42 UTC, Martin Nowak
wrote:
Second part on my series to reduce vibe.d turnaround time.
In this part we'll reduce compilation time by 60%.
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]:
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
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
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
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
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
It would be great to have more people helping with code review,
so that less pull requests get stuck, leading to less frustration
for the precious contributors.
For example I just wanted to add callOnce. This was factored out
from a change that loads curl at runtime.
On 11/10/2014 03:48 PM, Steven Schveighoffer wrote:
Opinion from those in the know:
When extern(C) is used in druntime, my understanding is that the reason
is twofold:
1. Because the compiler requires certain symbols for hooks.
2. To get around some requirements that druntime knows better,
On 11/11/2014 06:24 PM, Jacob Carlborg wrote:
BTW, the reason to implement native TLS is because otherwise we need to
implement basically what the dynamic linker is already doing for TLS our
self. Since it would be nice to have native TLS support anyway I thought
that was a better idea.
What's
On 11/11/2014 03:05 PM, Jacob Carlborg wrote:
There were some changes to the compiler as well, adding some hooks when
a dynamic library is loaded. But that shouldn't be needed on OS X since
the dynamic linker have native support for this.
Yes, you need a constructor and destructor in each
On Friday, 7 November 2014 at 11:17:16 UTC, sdvcn wrote:
os:windows 2008r2sp1 6.1.7601 x64
We just found another bug with out win64 stack switching function.
Will be fixed soon
https://issues.dlang.org/show_bug.cgi?id=12800#c6.
On Monday, 27 October 2014 at 07:42:30 UTC, Benjamin Thaut wrote:
Any reasons why such a pull request would not get accepted?
I did that for the exception hierarchy and sure would accept that
for TypeInfo. Not so sure about Object itself, as it would nail
down the API.
On Tuesday, 28 October 2014 at 21:32:14 UTC, ketmar via
Digitalmars-d wrote:
On Tue, 28 Oct 2014 08:37:43 -0400
I think a few simple functions can suffice for druntime's
purposes. We don't need a kitchen sink function (pun intended).
ah, those famous last words... ;-) from my observations it's
On Tuesday, 28 October 2014 at 23:06:32 UTC, Manu via
Digitalmars-d wrote:
Video games consoles are very real, and very now.
What architecture/platform?
The indirect function call argument seems a bit displaced for
toString.
This puts the burden on the caller to ensure enough space is
Microsoft's linker can reduplicate templates, they call it
identical comdat folding.
On Friday, 31 October 2014 at 11:43:39 UTC, Dragos Carp wrote:
github and http://downloads.dlang.org/releases/2014/ say YES,
but http://dlang.org/ and
http://forum.dlang.org/group/digitalmars.D.announce say NO...
Andrei didn't get got to this, though I wonder why he is the one
that needs to
On Tuesday, 11 March 2014 at 18:23:08 UTC, Jacob Carlborg wrote:
A DIP is available here [1] and the latest implementation is
available here [2].
[1] http://wiki.dlang.org/DIP43
Instead of adding the selector syntaxsyntax you could reuse
pragma mangle.
extern (Objective-C)
class
On 10/28/2014 09:07 AM, Daniel N wrote:
Awesome, would be nice if it was included with the default install for
2.067+
It says 0.1.x, maybe when it's over 0.5.x :).
In any case I'm really glad to see this moving forward.
This is the first post on my new blog https://code.dawg.eu/.
It starts with a 3 part series on reducing vibe.d turnaround times
during development.
https://code.dawg.eu/reducing-vibed-turnaround-time-part-1-faster-linking.html
There is also a friendly comment system.
On Friday, 17 October 2014 at 11:30:48 UTC, Marc Schütz wrote:
Marginally related: Page fault handling in user space.
http://lwn.net/Articles/615086/
Maybe this can be used as an alternative to forking.
Definitely good news for moving GCs.
On Wednesday, 8 October 2014 at 18:25:00 UTC, Rainer Schuetze
wrote:
I'm benchmarking my Windows version of a concurrent GC with it.
It does quite a lot of allocations, and this is causing some
serious trouble because marking cannot compete with the rate of
allocation, causing some tests to
On 10/28/2014 05:19 AM, Walter Bright wrote:
Before we add a bunch of more Deimos projects, can something be
done about the turnaround for Deimos pull requests? Right now, it
looks like the only way to get a pull merged is to ping you
personally to merge it.
There are 13 members of Team Deimos
On Tuesday, 28 October 2014 at 04:19:48 UTC, Walter Bright wrote:
Please, guys, I'd really appreciate it if you'd use your names
as github handles. You might think your handle is memorably
associated with your name, but when there are 50 such I
definitely lose the associations.
On Tuesday, 28 October 2014 at 02:10:47 UTC, Andrei Alexandrescu
wrote:
On 10/24/14 10:51 AM, ROOAR wrote:
I really liked this proposal for resumable lambda:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4244.pdf
Is this related to the video? -- Andrei
There is a good sumarry
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 only after the
promise (future) was set.
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 terminate when there are
no fibers waiting to execute. It should
On Tuesday, 28 October 2014 at 08:38:50 UTC, Robert burner
Schadek wrote:
Actually, that is only true for LogLevel given to a log call at
runtime. calls to info, trace etc. are guarded with static if.
So you're not paying any runtime overhead when calling log
functions with LogLevel build in
On Tuesday, 28 October 2014 at 10:05:47 UTC, Robert burner
Schadek wrote:
On Tuesday, 28 October 2014 at 09:39:24 UTC, Martin Nowak wrote:
On Tuesday, 28 October 2014 at 08:38:50 UTC, Robert burner
Schadek wrote:
Actually, that is only true for LogLevel given to a log call
at runtime. calls to
On Tuesday, 28 October 2014 at 09:00:54 UTC, Robert burner
Schadek wrote:
The second two are wanted and disabling a LogLevel at CT of
phobos should be banned anyway. But no the less, it is one more
option the user has to manipulate the Logger.
And this is where the leakage happens because
On Tuesday, 28 October 2014 at 17:05:13 UTC, Andrei Alexandrescu
wrote:
I'm not sure but as far as I understand this one issue forces
Go code to have a strong networking effect (must call into Go
code designed especially for cooperative threading). That
forces a lot of rewriting of existing
On Tuesday, 28 October 2014 at 12:02:16 UTC, Robert burner
Schadek wrote:
It is a design goal to disable certain LogLevel at CT of a
compile unit (CU).
e.g. make all logs to trace function template do nothing
One idea to make this working is to use prefixed version
identifiers.
Obviously
On 10/28/2014 07:22 PM, Martin Nowak wrote:
On Tuesday, 28 October 2014 at 12:02:16 UTC, Robert burner Schadek wrote:
It is a design goal to disable certain LogLevel at CT of a compile
unit (CU).
e.g. make all logs to trace function template do nothing
One idea to make this working is to use
On 10/27/2014 09:08 AM, Robert burner Schadek wrote:
And again I'm saying fixing the LogLevel at CT is not good enough. And
the other part of the solution uses class just like std.logger.
Right, a CT LogLevel only works for certain use-cases and I never
claimed that it works for everything
On 10/27/2014 09:22 AM, Robert burner Schadek wrote:
It is a good think then that the *DisableLogging versions are only used
inside a template that is used inside a templates. Though version
statements attached to a phobos compilation should only have impact on
the unittest of phobos.
On 10/27/2014 09:49 PM, Dicebot wrote:
This is exactly what is wrong :) Using std.logger inside Phobos itself
is a big no. Actually even finding yourself in position where you may
want to do it indicates some Phobos design issue.
Well the same problem also applies to any other library that I
On 10/27/2014 01:36 PM, Robert burner Schadek wrote:
Well, as far as I can see his argument was based on old code that has
long been rewritten and he hasn't answered since I pointed that out.
How do come to that insight?
On 10/27/2014 09:28 AM, Robert burner Schadek wrote:
If it where done this way, yes of course you're right. But it is not,
please take a look a the source first.
I'm looking at
https://github.com/burner/phobos/blob/logger/std/experimental/logger/core.d
and this is exactly how this works.
On 10/28/2014 12:58 AM, Robert burner Schadek wrote:
Disabling a version at CT of the lib has no consequence to compile units
that are not compiled with that version statement.
Yes setting a version in my app has no effect on the library, that's the
problem because I cannot disable logging
On 10/28/2014 01:01 AM, Robert burner Schadek wrote:
is different from the code that has been in the PR for quite some time.
And the code you show does exactly what you say and the current code
does something different.
No it behaves the same.
isLoggingActive is a template in phobos
doSome
On 10/26/2014 05:12 PM, Sean Kelly wrote:
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 will be in pretty good shape. The FiberScheduler is
a good start though, if you want to
On 10/26/2014 02:37 AM, Vic wrote:
JRE has Oracle and 100 devs, CLR has MS and 100 dec, there are 7
for D, and it should be narrow, like LUA. It should have 7% of
their platform. Majority of scared cows must be killed, the
sooner leaders realize the better.
I'd actually also like to see less
On 10/06/2014 06:02 AM, Andrei Alexandrescu wrote:
Some more couple thousands would buy us things like a web designer.
Well we had some people working on a new website (http://w0rp.com:8010/)
and if someone had collaborated with them to advance and integrate the
work we would have a new
On 10/25/2014 06:43 PM, Dicebot wrote:
Because of that I am going to start voting despite some arguments being
still in process. I hope that won't cause any tension.
The dependency on external version identifiers in phobos is still a
complete bummer and there are still many implementation
On 10/11/2014 03:34 PM, Robert burner Schadek wrote:
- Why do loggers have to be classes?
As answered multiply times before, to build log hierarchies.
You can easily create classes from structs, that's what I said 2 lines
below.
Add a Logger interface and a loggerObject to wrap structures
On 10/26/2014 11:14 PM, Martin Nowak wrote:
As answered multiply times before, to build log hierarchies.
You can easily create classes from structs, that's what I said 2 lines
below.
And you could also log into a tuple of logger structs without polymorphism.
On 10/24/2014 02:16 PM, Robert burner Schadek wrote:
On Friday, 24 October 2014 at 11:01:40 UTC, Martin Nowak wrote:
On Sunday, 12 October 2014 at 12:06:44 UTC, Robert burner Schadek wrote:
What's stopping an interface or class to implement a logging concept?
Same as last time:
Logger[],
On 10/26/2014 10:11 PM, ketmar via Digitalmars-d wrote:
please, no! ;-) there is alot sense of having many things in phobos.
for beginners it's much easier to use just compiler and standard
library, for example. it's much easier than oh, well, compiler. and
that strange 'dub' thing.
Well dmd
On 10/26/2014 11:27 PM, Robert burner Schadek wrote:
it is not really a dependency as the one template that uses the version
identifier uses them optionally.
It simply doesn't work, e.g. you could not statically disable logging in
phobos without recompiling phobos.
cat lib.d CODE
version
On 10/26/2014 11:29 PM, Robert burner Schadek wrote:
And I forgot to add, no better solution presented itself in one year.
Well I showed one solution, but reduce it to its essence.
If you allow to define a Logger with a LogLevel know at compile time and
you statically pass the LogLevel of
On 10/27/2014 12:45 AM, Martin Nowak wrote:
but reduce it to its essence.
but let's reduce
On 10/27/2014 12:45 AM, Martin Nowak wrote:
If you allow to define a Logger with a LogLevel know at compile time and
you statically pass the LogLevel of your message to the logging function
you can elide that call. For anything else you need a runtime check.
You are trying to globally define a
On 10/11/2014 03:34 PM, Robert burner Schadek wrote:
As answered multiply times before, to build log hierarchies.
You don't need classes for hierarchies. You need them for runtime
polymorphism. We're already building complex hierarchies with Ranges,
same can be done for loggers, see
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 particular scheduling mechanism and of
course consumes much
On Friday, 24 October 2014 at 02:42:13 UTC, frustrated wrote:
Two days later and I still cant get a 'Hello World' to compile.
Hmm, sorry for whatever went wrong. It would be nice if you let
us know what went wrong.
It is far beyond me how a project can exist for so many years
and still not
On Friday, 24 October 2014 at 02:44:48 UTC, Adam D. Ruppe wrote:
I always just use the zip which works fine out of the box
without even needing to be installed.
We're missing an installation guide on a prominent place on the
front page.
Such things really scare away a lot of people.
On Saturday, 11 October 2014 at 13:34:29 UTC, Robert burner
Schadek wrote:
All that code is contained in 30 line template, That is by far
the best working option anybody could come up with
I even proposed an alternative that uses type tags instead.
http://dpaste.dzfl.pl/95fb6a4e086d
And I
On Sunday, 12 October 2014 at 12:06:44 UTC, Robert burner Schadek
wrote:
What's stopping an interface or class to implement a logging
concept?
Same as last time:
Logger[], Logger without a LogLevel not real useful IMO, (new)
no thread safety by default
I don't understand your answer. Do you
On Friday, 8 August 2014 at 09:16:11 UTC, Robert burner Schadek
wrote:
could you elaborate please? Currently I use the version
statements in two template functions. I'm not sure why one
would brand this negatively as a leak into the library.
For example we don't reinstatiate templates if they
On Friday, 24 October 2014 at 10:59:43 UTC, Martin Nowak wrote:
And I showed that it did not work.
Found it
http://forum.dlang.org/post/hmzfcxlafwlgoovuw...@forum.dlang.org
On Friday, 24 October 2014 at 12:45:38 UTC, Kagamin wrote:
On Friday, 24 October 2014 at 10:42:48 UTC, Martin Nowak wrote:
We're missing an installation guide on a prominent place on
the front page.
Such things really scare away a lot of people.
All gcc, clang, ldc etc are installed in the
On 10/20/2014 12:32 AM, MrSmith wrote:
Than any module can search for registered modules and try to cast them
to concrete type (upcast).
That can't work because the notion of types only exists during
compilation. Therefor it's not possible to load new types at runtime and
use them in code
On 10/08/2014 10:01 PM, Andrei Alexandrescu wrote:
That's a bummer. Can we get the compiler to remove the if (__ctfe)
code after semantic checking?
Andrei
It seems that __ctfe is treated as constant in the backend.
At least there is no asm code generated for these examples (even without
On 10/08/2014 11:40 PM, Timon Gehr wrote:
This is probably a regression somewhere after 2.060, because with 2.060
I get
Error: variable __ctfe cannot be read at compile time
Error: expression __ctfe is not constant or does not evaluate to a bool
as I'd expect.
Marked the bugzilla case as
On Friday, 17 October 2014 at 05:38:05 UTC, thedeemon wrote:
Gentlemen, do I understand correctly that you're trying to find
a Windows-friendly switch to something that will never see the
light on Windows (because of being based on fork)?
No we want general runtime configuration, not only for
On Monday, 25 August 2014 at 18:10:33 UTC, Gary Willoughby wrote:
class Foo
{
private int foo;
mixin Proxy!(foo);
this(int x)
{
this.foo = x;
}
}
Apparently Proxy
On Wednesday, 23 July 2014 at 21:14:35 UTC, Brian Schott wrote:
$ ./dscanner --styleCheck ~/tmp/test.d
test.d(1:8)[warn]: 'A' has method 'opCmp', but not 'opEquals'.
Nice
1301 - 1400 of 1476 matches
Mail list logo
