On Thursday, 24 April 2014 at 14:10:07 UTC, Jacob Carlborg wrote:
On 24/04/14 09:19, Atila Neves wrote:
I did, yeah, that's why I asked that question recently about
calling D
from Ruby.
Right, that was you.
I also thought of using Thrift and played about with it but
in the end decided
On Thursday, 24 April 2014 at 18:55:20 UTC, Jacob Carlborg wrote:
On 2014-04-23 15:24, Atila Neves wrote:
Like testing with Cucumber? Wish you could call native D code
with it?
Now you can!
http://code.dlang.org/packages/unencumbered
https://github.com/atilaneves/unencumbered
I especially
On Thursday, 24 April 2014 at 18:53:22 UTC, Jacob Carlborg wrote:
On 2014-04-23 15:24, Atila Neves wrote:
Like testing with Cucumber? Wish you could call native D code
with it?
Now you can!
http://code.dlang.org/packages/unencumbered
https://github.com/atilaneves/unencumbered
I especially
On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote:
On Thursday, 24 April 2014 at 18:53:22 UTC, Jacob Carlborg
wrote:
On 2014-04-23 15:24, Atila Neves wrote:
Like testing with Cucumber? Wish you could call native D code
with it?
Now you can!
On Friday, 25 April 2014 at 08:52:18 UTC, Atila Neves wrote:
On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote:
On Thursday, 24 April 2014 at 18:53:22 UTC, Jacob Carlborg
wrote:
On 2014-04-23 15:24, Atila Neves wrote:
Like testing with Cucumber? Wish you could call native D
code
On Friday, 25 April 2014 at 09:45:06 UTC, Rikki Cattermole wrote:
Also when using things like __LINE__ keep them to template
args, as they are inferred to the initiation if possible.
This is antipattern. Default function arguments for __LINE__ and
__FILE__ are also evaluated at call site.
On Friday, 25 April 2014 at 10:02:45 UTC, Dicebot wrote:
On Friday, 25 April 2014 at 09:45:06 UTC, Rikki Cattermole
wrote:
Also when using things like __LINE__ keep them to template
args, as they are inferred to the initiation if possible.
This is antipattern. Default function arguments for
For those who are interested in the Excelsior Jet AOT Java to native compiler
http://www.excelsiorjet.com/charity
Note: non-upgradable, no support
On Friday, 25 April 2014 at 10:20:47 UTC, Rikki Cattermole wrote:
On Friday, 25 April 2014 at 10:02:45 UTC, Dicebot wrote:
On Friday, 25 April 2014 at 09:45:06 UTC, Rikki Cattermole
wrote:
Also when using things like __LINE__ keep them to template
args, as they are inferred to the initiation
On Friday, 25 April 2014 at 11:11:18 UTC, Atila Neves wrote:
Is there any other way to achieve @Given(regexp) that also
gets passed in the line number automatically without the
template param? If so I'll glady use it, if not I think Rikki's
solution seems to be the simplest so far.
Atila
On Friday, 25 April 2014 at 11:11:18 UTC, Atila Neves wrote:
On Friday, 25 April 2014 at 10:20:47 UTC, Rikki Cattermole
wrote:
On Friday, 25 April 2014 at 10:02:45 UTC, Dicebot wrote:
On Friday, 25 April 2014 at 09:45:06 UTC, Rikki Cattermole
wrote:
Also when using things like __LINE__ keep
On Friday, 25 April 2014 at 12:18:41 UTC, John Colvin wrote:
On Friday, 25 April 2014 at 11:11:18 UTC, Atila Neves wrote:
On Friday, 25 April 2014 at 10:20:47 UTC, Rikki Cattermole
wrote:
On Friday, 25 April 2014 at 10:02:45 UTC, Dicebot wrote:
On Friday, 25 April 2014 at 09:45:06 UTC, Rikki
whilst bootstrapping the process and also for some tests I
wrote for my
MQTT broker. I think this should work but I can't try it right
You have a MQTT broker? Free? Open-source? Can I haz teh code plx!
Am 25.04.2014 15:00, schrieb Dejan Lekic:
whilst bootstrapping the process and also for some tests I wrote for my
MQTT broker. I think this should work but I can't try it right
You have a MQTT broker? Free? Open-source? Can I haz teh code plx!
https://github.com/atilaneves/mqtt
BTW,
On Friday, 25 April 2014 at 13:07:43 UTC, Sönke Ludwig wrote:
Am 25.04.2014 15:00, schrieb Dejan Lekic:
whilst bootstrapping the process and also for some tests I
wrote for my
MQTT broker. I think this should work but I can't try it
right
You have a MQTT broker? Free? Open-source? Can I haz
On Friday, 25 April 2014 at 13:00:20 UTC, Dejan Lekic wrote:
whilst bootstrapping the process and also for some tests I
wrote for my
MQTT broker. I think this should work but I can't try it right
You have a MQTT broker? Free? Open-source? Can I haz teh code
plx!
On 4/25/14, Jos van Uden via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
For those who are interested in the Excelsior Jet AOT Java to native
compiler
http://www.excelsiorjet.com/charity
Note: non-upgradable, no support
If it's OT it does not belong to D.announce.
I know we don't place much value in TIOBE and it's brethren. However, I
thought that this was a milestone worthy of a note anyways.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
--
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
On Friday, 25 April 2014 at 19:51:22 UTC, Adam Wilson wrote:
I know we don't place much value in TIOBE and it's brethren.
However, I thought that this was a milestone worthy of a note
anyways.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Well, in fact last month D was
On Friday, 25 April 2014 at 19:51:22 UTC, Adam Wilson wrote:
I know we don't place much value in TIOBE
What do you mean, we're in the top 20! Now's the time to put
value in TIOBE :)
On Friday, 25 April 2014 at 20:22:32 UTC, Théo Bueno wrote:
I just don't understand how they make their calculations.
http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm
Apparently they use:
+D programming -3-D programming -DTrace
?
They claim 90% confidence, but I
On 24/04/14 23:49, bearophile wrote:
Yes, sorry, I know this could cause some troubles, but if you think hard
about the situation, you will see that this is currently the best (or
less bad) solution. It was recently discussed in D.learn, but I can't
find the thread. So let's not discuss it
Hi,everyone,
Here has a error after run: main.exe 11 or main.exe 10 :
module main;
import std.stdio,std.conv;
template find(T)
{
size_t find(T[] Array,T Element)
{
size_t i;
foreach(T ArrayElement; Array)
{
On 04/25/2014 09:14 AM, FrankLike via Digitalmars-d wrote:
Hi,everyone,
Here has a error after run: main.exe 11 or main.exe 10 :
template find(T)
{
size_t find(T[] Array,T Element)
{
find returns a size_t being a nonnegativ number.
return -1;
But here it returns -1.
In
On 4/25/14, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Recently, I observed a conversation happening on the github pull request
system.
Another case of hijacking is the std.conv.text function. I've seen two
people so far that have accidentally called the global
On Friday, 25 April 2014 at 07:52:20 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
Another case of hijacking is the std.conv.text function. I've
seen two
people so far that have accidentally called the global text
function
by mistake, e.g.:
Make that three. The ability to call non-@property
On 4/25/2014 1:06 AM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Apr 25, 2014 at 12:24:47AM -0400, Nick Sabalausky via Digitalmars-d
wrote:
I would think basic computing features like text editing, copy/paste,
and filenames would make trivially short work of conforming to various
templates
On Thursday, 24 April 2014 at 21:48:46 UTC, Nick Sabalausky wrote:
Markdown:
*italic*
**bold**
**_bold and italic_**
That looks like semantic markup. Visual markup would be
/italic/
*bold*
_underlined_
I'm thinking more about some standardization of web skins,
then people
will choose their
Different strokes for different folks.
https://github.com/rejectedsoftware/ddox/pull/49
Walter Bright:
Pointing out these issues is exactly what @nogc is designed to
do.
Using @nogc is like putting your code under a newly invented
microscope, it allows to see things that I missed before :-)
Bye,
bearophile
On Thursday, 24 April 2014 at 13:35:39 UTC, bearophile wrote:
immutable int x = 3;
auto result = data[].map!(y = y * x);
}
test.d(1,6): Error: function D main @nogc function allocates a
closure with the GC
Such kind of code is common, so a good amount of range-based
code can't be
On 25/04/2014 08:29, Matthias Walter via Digitalmars-d wrote:
size_t find(T[] Array,T Element)
{
find returns a size_t being a nonnegativ number.
return -1;
But here it returns -1.
For size_t and uint 'dmd -w' seems to allow returning literal -1, but
with ubyte I get:
On Friday, 25 April 2014 at 07:14:48 UTC, FrankLike wrote:
Hi,everyone,
Here has a error after run: main.exe 11 or main.exe 10 :
[…]
Why?
size_t (the return type of your find()) is always non-negative,
hence the if condition is never false.
In the future, you might want to consider
On Fri, 25 Apr 2014 07:52:42 -0400, Nick Treleaven
ntrel-pub...@yahoo.co.uk wrote:
On 25/04/2014 08:29, Matthias Walter via Digitalmars-d wrote:
size_t find(T[] Array,T Element)
{
find returns a size_t being a nonnegativ number.
return -1;
But here it returns -1.
For
On Fri, 25 Apr 2014 07:28:27 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 24 April 2014 at 13:35:39 UTC, bearophile wrote:
immutable int x = 3;
auto result = data[].map!(y = y * x);
}
test.d(1,6): Error: function D main @nogc function allocates
On Fri, 25 Apr 2014 00:58:51 -0400, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
If it doesn't work to override a free function with a member
function, I honestly don't see much point to UFCS. The whole idea
behind it is to make it so that you don't have to care
On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer
wrote:
One interesting thing about this is that the compiler
implementation may make some @nogc code valid on some
compilers, and invalid on others, even though the resulting
execution is the same.
I don't think this is a
On Fri, 25 Apr 2014 03:52:09 -0400, Andrej Mitrovic via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 4/25/14, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Recently, I observed a conversation happening on the github pull request
system.
Another case of
On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer
wrote:
It could. I don't think the compiler is smart enough, as it
would need to verify result doesn't go anywhere (flow analysis).
In that case I'd like to see recursive inlining, if it makes
stack allocations more probable.
On Friday, 25 April 2014 at 12:21:40 UTC, David Nadlinger wrote:
On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer
wrote:
One interesting thing about this is that the compiler
implementation may make some @nogc code valid on some
compilers, and invalid on others, even though the
On Fri, 25 Apr 2014 08:21:38 -0400, David Nadlinger c...@klickverbot.at
wrote:
On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer wrote:
One interesting thing about this is that the compiler implementation
may make some @nogc code valid on some compilers, and invalid on
On Friday, 25 April 2014 at 12:59:55 UTC, Steven Schveighoffer
wrote:
On Fri, 25 Apr 2014 08:21:38 -0400, David Nadlinger
c...@klickverbot.at wrote:
On Friday, 25 April 2014 at 12:07:00 UTC, Steven Schveighoffer
wrote:
One interesting thing about this is that the compiler
implementation may
Thank you,everyone.
I should use the 'int'.
I use the 'size_t',that lets the range changed by the
platform(X86 or X64),but forgot 'size_t' is another 'uint'.
Thank you everyone again.
Frank.
On Fri, 25 Apr 2014 09:20:08 -0400, Dicebot pub...@dicebot.lv wrote:
On Friday, 25 April 2014 at 12:59:55 UTC, Steven Schveighoffer wrote:
I don't know that it's desirable to have @nogc reject code even though
an allocation does not occur. I agree the situation is not ideal, but
@nogc is
Dicebot:
It is unacceptable to have code that fails with one compiler
and works with the other despite the shared frontend version.
Such enhanced @nogc attributes must be placed into
compiler-specific attribute space and not as a core language
feature.
This problem was underlined during
On Friday, 25 April 2014 at 14:01:07 UTC, Steven Schveighoffer
wrote:
It is unacceptable to have code that fails with one compiler
and works with the other despite the shared frontend version.
Such enhanced @nogc attributes must be placed into
compiler-specific attribute space and not as a
On Friday, 25 April 2014 at 12:21:04 UTC, Steven Schveighoffer
wrote:
I think this really comes down to a poorly named function.
textOf, toText, textify even, are better names that wouldn't
cause this problem.
-Steve
Well, in this case, yes, because it's a noun. For all functions
that are
On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot pub...@dicebot.lv wrote:
On Friday, 25 April 2014 at 14:01:07 UTC, Steven Schveighoffer wrote:
It is unacceptable to have code that fails with one compiler and works
with the other despite the shared frontend version. Such enhanced
@nogc
On Fri, 25 Apr 2014 11:29:37 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot pub...@dicebot.lv wrote:
On Friday, 25 April 2014 at 14:01:07 UTC, Steven Schveighoffer wrote:
But what really is the difference between a function that is marked
On Friday, 25 April 2014 at 15:29:38 UTC, Steven Schveighoffer
wrote:
On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot pub...@dicebot.lv
Which is the very reason why I was so insisting of defining
exact set of cases when optimisation is to be guaranteed in
spec (before releasing @nogc).
On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu
wrote:
So I'd dlang.org to foster a behavior depending on the
available real estate, as follows:
* Cap cpl at e.g. 110 on very large screens.
* As the available width decreases, reduce cpl up to 60.
* If cpl with sidebar falls
On Friday, 25 April 2014 at 15:32:40 UTC, Steven Schveighoffer
wrote:
You know what, in fact, @nogc may need to be re-branded as
compiler-specific.
You should have a compiler switch that let's you get
compiler-optimal non-portable @nogc.
This is one of the largest problems left in the implementation of
D purity:
https://issues.dlang.org/show_bug.cgi?id=9148
One example of the refused code:
void foo(const int[] a) {
int bar() pure {
return a[0];
}
}
void main() {}
Bye,
bearophile
On Saturday, 26 April 2014 at 01:57:06 UTC, bearophile wrote:
This is one of the largest problems left in the implementation
of D purity:
https://issues.dlang.org/show_bug.cgi?id=9148
One example of the refused code:
void foo(const int[] a) {
int bar() pure {
return a[0];
}
On Fri, 25 Apr 2014 23:26:29 -0400, Xinok xi...@live.com wrote:
On Saturday, 26 April 2014 at 01:57:06 UTC, bearophile wrote:
This is one of the largest problems left in the implementation of D
purity:
https://issues.dlang.org/show_bug.cgi?id=9148
One example of the refused code:
void
On Fri, 25 Apr 2014 20:50:46 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 25 April 2014 at 15:32:40 UTC, Steven Schveighoffer wrote:
You know what, in fact, @nogc may need to be re-branded as
compiler-specific.
You should have a compiler switch that
On Saturday, 26 April 2014 at 04:49:07 UTC, Steven Schveighoffer
wrote:
In any case, I don't need another explanation, I don't think it
will ever make sense to me.
It makes sense because there are two different use cases:
1. Library authors who need a more conservative interpretation of
On Friday, 25 April 2014 at 06:11:45 UTC, Jacob Carlborg wrote:
On 25/04/14 07:30, Chris Piker wrote:
I've not been able to find instructions on building DWT using
gdc. The
gdc package for Linux Mint 16 didn't come with an rdmd script
(or gdmd
for that matter either). If someone on the list
Hi !
http://dpaste.dzfl.pl/2fa3dd2ea834
Why S.init not pure ? Is it expected behavior or bug ?
Thanks!
On Friday, 25 April 2014 at 04:23:45 UTC, Ali Çehreli wrote:
On 04/24/2014 08:32 PM, Jeremy DeHaan wrote:
added the -cov switch to my unit test build
Then you must execute the program. :)
Ali
I did, but still nothing. I even tried using the switch in a
debug build and the same thing
On Friday, 25 April 2014 at 07:59:29 UTC, Temtaime wrote:
Hi !
http://dpaste.dzfl.pl/2fa3dd2ea834
Why S.init not pure ? Is it expected behavior or bug ?
Thanks!
Fix
http://dpaste.dzfl.pl/03f73cd958f4
Hi, MrSmith !
Yes, i know that, but my question isn't about it.
I want to type `pure:` at module's beginning and have all
function(in classes, too) declared as pure.
I think `pure:` should do it. But it doesn't.
On Friday, 25 April 2014 at 09:08:50 UTC, Temtaime wrote:
Hi, MrSmith !
Yes, i know that, but my question isn't about it.
I want to type `pure:` at module's beginning and have all
function(in classes, too) declared as pure.
I think `pure:` should do it. But it doesn't.
pure is not a
Hi ! Thanks for reply.
Why so ?
And why @nogc not transitive too ?
__traits(getProtection) allows us to know if something is
private, protected, etc. But how would one go about determining
that from another module? The problem here is if module foo
defines a function foofunc that is private, trying to use
__traits(getProtection) from another module fails to
On Friday, 25 April 2014 at 11:51:48 UTC, bearophile wrote:
They are not the same type:
void main() {
import std.typecons: Tuple;
alias T1 = const Tuple!(int, int);
alias T2 = Tuple!(const int, const int);
static assert(is(T1 == T2)); // Fails.
}
This type difference causes
They are not the same type:
void main() {
import std.typecons: Tuple;
alias T1 = const Tuple!(int, int);
alias T2 = Tuple!(const int, const int);
static assert(is(T1 == T2)); // Fails.
}
This type difference causes some troubles when you use tuples.
Bye,
bearophile
Dicebot:
Why would you even expect those to be same types? These 2 types
are also different:
struct A
{
const int x;
}
alias A_ = const(A);
In general a tuple is a higher level data structure compared to a
struct. So it's not unreasonable to expect a Tuple to be more
flexible than a
On Friday, 25 April 2014 at 12:17:31 UTC, bearophile wrote:
In general a tuple is a higher level data structure compared to
a struct. So it's not unreasonable to expect a Tuple to be more
flexible than a struct.
Well, wrong :) std.typecons.Tuple IS a struct -
Dicebot:
Well, wrong :) std.typecons.Tuple IS a struct -
https://github.com/D-Programming-Language/phobos/blob/master/std/typecons.d#L388
Nope, that's just an implementation detail. They are two quite
different data structures. Example: slicing a tuple always has a
meaning, while slicing a
On Friday, 25 April 2014 at 12:42:33 UTC, bearophile wrote:
Dicebot:
Well, wrong :) std.typecons.Tuple IS a struct -
https://github.com/D-Programming-Language/phobos/blob/master/std/typecons.d#L388
Nope, that's just an implementation detail. They are two quite
different data structures.
Dicebot:
std.typecons.Tuple is just a subset of all structs implementing
specific behavior. It still acts as struct everywhere when
applicable.
A subset is not the same as the whole set.
You are missing something important about what a data structure
is. Take a look at your computer
I was just expressing a little frustration :-)
An example; despite it looks simple I am missing something:
import std.typecons: Tuple, tuple;
import std.algorithm: reduce;
struct Foo { int x; }
auto foo(in Tuple!(Foo[]) arg, int) {
return tuple(arg[0]);
}
void main() {
int[] data;
On Friday, 25 April 2014 at 12:54:25 UTC, bearophile wrote:
Dicebot:
std.typecons.Tuple is just a subset of all structs
implementing specific behavior. It still acts as struct
everywhere when applicable.
A subset is not the same as the whole set.
You are missing something important about
Dicebot:
It would be weird exception of general type system rules with
no practical justification I can readily imagine.
I partially disagree. It could be useful to have structural
typing (http://en.wikipedia.org/wiki/Structural_type_system )
only on tuples (and not on structs), because the
import std.typecons: Tuple, tuple;
import std.algorithm: reduce;
struct Foo { int x; }
auto foo(in Tuple!(Foo[]) arg, int) {
return tuple(arg[0]);
}
void main() {
int[] data;
Foo[] empty;
auto seed = tuple(empty);
reduce!foo(seed, data);
}
I have found a solution:
import
On Friday, 25 April 2014 at 11:51:48 UTC, bearophile wrote:
They are not the same type:
void main() {
import std.typecons: Tuple;
alias T1 = const Tuple!(int, int);
alias T2 = Tuple!(const int, const int);
static assert(is(T1 == T2)); // Fails.
}
This type difference causes
Meta:
I think it's a bad idea to make these equal for this reason: if
T1 == T2, then you would expect Unqual!T1 == Unqual!T2. However:
alias T1 = const Tuple!(int, int);
alias T2 = Tuple!(const int, const int);
assert(is(T1 == T2));
alias UnT1 = Unqual!T1; // Tuple!(int, int)
alias UnT2 =
On Friday, 25 April 2014 at 13:18:13 UTC, bearophile wrote:
Dicebot:
It would be weird exception of general type system rules with
no practical justification I can readily imagine.
I partially disagree. It could be useful to have structural
typing
Fibers are more lightweight, they're not kernel objects. Threads
are scheduled by kernel (usually). Fibers are better if you can
get better resource usage with manual scheduling - less context
switches, or don't want to consume resources need by threads.
On Saturday, 12 April 2014 at 10:41:19 UTC, hicman wrote:
will the library build for x64?
It will build but not true x64.
On Friday, 11 April 2014 at 12:33:27 UTC, FrankLike wrote:
On Thursday, 14 November 2013 at 16:17:53 UTC, Heinz wrote:
You have to manually set the tooltip's max width
On Fri, 2014-04-25 at 17:10 +, Kagamin via Digitalmars-d-learn
wrote:
Fibers are more lightweight, they're not kernel objects. Threads
are scheduled by kernel (usually). Fibers are better if you can
get better resource usage with manual scheduling - less context
switches, or don't want
On Thursday, 14 November 2013 at 16:17:53 UTC, Heinz wrote:
You have to manually set the tooltip's max width to a fixed
value using the tooltip handle and Win32 API, by doing this
you're telling the tooltip object it is a multiline tooltip and
from now on it will accept \r\n as end of line:
hi everyone.
I'm trying to symmetrically encrypt some text using the openssl
bindings. My code compiles and fails silently. Clearly there is
something very wrong with it - it could be my novice D skills, or
my misuse of the openssl binding.
auto chunk = new ubyte[](16);
foreach(ref
On Fri, 25 Apr 2014 19:06:31 +, brad clawsie wrote:
hi everyone.
I'm trying to symmetrically encrypt some text using the openssl
bindings. My code compiles and fails silently. Clearly there is
something very wrong with it - it could be my novice D skills, or my
misuse of the openssl
Justin Whear:
brad clawsie:
b = cast(ubyte[]) s;
Better to use std.string.representation.
It doesn't look like you're allocating space for `e` or `d`,
e.g. `auto e
= new ubyte[](256);`, so those arrays have a length of 0, in
which case
the encrypt/decrypt functions are just trashing
Dicebot:
For your objections to make sense tuple would need to be
inroduced as completely new first class type system entity. As
this will never happen,
I think first class tuples will happen in D, because the current
tuple situation is quite bad.
But this thread is not about built-in
https://issues.dlang.org/show_bug.cgi?id=12639
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
--- Comment
https://issues.dlang.org/show_bug.cgi?id=12606
--- Comment #7 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/3b74627a464197f526e6b3a9a54334e3ced60fc8
fix Issue 12606 - Mismatch
https://issues.dlang.org/show_bug.cgi?id=12606
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.dlang.org/show_bug.cgi?id=12640
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC|
https://issues.dlang.org/show_bug.cgi?id=12640
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
Summary|@nogc introduces a spurious |Error inside a
https://issues.dlang.org/show_bug.cgi?id=12640
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
OS|Windows |All
--
https://issues.dlang.org/show_bug.cgi?id=12640
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
Assignee|nob...@puremagic.com
https://issues.dlang.org/show_bug.cgi?id=12640
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
Keywords||pull
---
https://issues.dlang.org/show_bug.cgi?id=12170
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://issues.dlang.org/show_bug.cgi?id=12641
Issue ID: 12641
Summary: D1: __FILE__ and __LINE__ default argument behaviour
Product: D
Version: D1
Hardware: x86_64
OS: Linux
Status: NEW
Severity:
https://issues.dlang.org/show_bug.cgi?id=12623
Vladimir Panteleev thecybersha...@gmail.com changed:
What|Removed |Added
Keywords||pull
https://issues.dlang.org/show_bug.cgi?id=10233
Issue 10233 depends on issue 12623, which changed state.
Issue 12623 Summary: Special lexing case not mentioned in language spec
https://issues.dlang.org/show_bug.cgi?id=12623
What|Removed |Added
https://issues.dlang.org/show_bug.cgi?id=11319
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC|
1 - 100 of 164 matches
Mail list logo
