On 7/2/2017 7:27 AM, Vladimir Panteleev via Digitalmars-d wrote:
On Friday, 30 June 2017 at 12:48:12 UTC, Martin Krejcirik wrote:
DMD, Phobos and Druntime open regressions over time:
http://bid.iline.cz/~mk/tmp/regs.png
Used to be stable, but seems to be getting worse since 2016.
One thing
On Friday, 30 June 2017 at 12:48:12 UTC, Martin Krejcirik wrote:
DMD, Phobos and Druntime open regressions over time:
http://bid.iline.cz/~mk/tmp/regs.png
Used to be stable, but seems to be getting worse since 2016.
One thing that might have contributed to that is that until a
year or two
On Sat, Jul 01, 2017 at 12:57:35AM +0200, ag0aep6g via Digitalmars-d wrote:
> On 06/30/2017 02:48 PM, Martin Krejcirik wrote:
> > DMD, Phobos and Druntime open regressions over time:
> >
> > http://bid.iline.cz/~mk/tmp/regs.png
> >
> > Used to be stable, but see
On 06/30/2017 02:48 PM, Martin Krejcirik wrote:
DMD, Phobos and Druntime open regressions over time:
http://bid.iline.cz/~mk/tmp/regs.png
Used to be stable, but seems to be getting worse since 2016.
It's probably no coincidence that Kenji's last commits have been in 2016:
https://
On Friday, 30 June 2017 at 16:44:54 UTC, Seb wrote:
Btw, in case anyone wants to prevent regressions for their
project(s). There are two easy ways:
1) Add it to the Project-Tester which is run on _every_ PR for
{dmd,druntime,phobos} (-> make a PR to dlang/ci)
2) Enable daily crons [1]
On Friday, 30 June 2017 at 12:48:12 UTC, Martin Krejcirik wrote:
DMD, Phobos and Druntime open regressions over time:
http://bid.iline.cz/~mk/tmp/regs.png
Used to be stable, but seems to be getting worse since 2016.
I think this depends on your PoV. Thanks to the growing community
and more
DMD, Phobos and Druntime open regressions over time:
http://bid.iline.cz/~mk/tmp/regs.png
Used to be stable, but seems to be getting worse since 2016.
On 2/28/2015 3:01 PM, Martin Nowak wrote:
done
Thanks!
On 02/28/2015 11:35 PM, Walter Bright wrote:
> Can you please fix your newsreader submitter to not post these? They're
> fine for email, but out of place in the n.g.
done
On 2/28/2015 2:54 PM, Dicebot wrote:
PGP signatures are as meaningful in NG as they are in e-mail. It is an identity
proof.
1. it's not relevant in a n.g.
2. it doubles the size of most messages (not insignificant when just this n.g.
has > 250,000 messages in it)
PGP signatures are as meaningful in NG as they are in e-mail. It
is an identity proof.
On 2/28/2015 1:46 PM, Martin Nowak wrote:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBAgAGBQJU8jc6AAoJELJzgRYSuxk5NIAP/3sqCuwjoW7BfityRPZZLzK3
vc6+ye8D7/K40rOvhGng/96UqtfHD7AWmV3SCRde01TEA6OpOHc7pzMAwLcsA/qM
z7nJ1C905zUos4QpkpaF15Ujbkd7f0WoOQl25pkzJjiurJVmPe3SMOwkVdBqly8/
PNmPNtwvtBP
On 2/28/2015 1:46 PM, Martin Nowak wrote:
Quite a lot of the open regressions concern phobos.
Maybe some people not reading the dmd-beta list may help with that?
https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&am
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Quite a lot of the open regressions concern phobos.
Maybe some people not reading the dmd-beta list may help with that?
https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&am
On 2013-10-31 09:42, monarch_dodra wrote:
Adding a link always helps:
http://d.puremagic.com/issues/show_bug.cgi?id=11392
Do you have any idea if this worked in beta 1-3 ? It would help locate
the regression. I *pray* it's not in emplace :/
Just run a git bisect with an automated test.
--
/J
On Thursday, 31 October 2013 at 12:00:33 UTC, David Nadlinger
wrote:
On Thursday, 31 October 2013 at 08:56:12 UTC, Gary Willoughby
wrote:
This bug also seems to affect GDC and LDC.
http://forum.dlang.org/thread/wzzfsnshgdjdoypan...@forum.dlang.org#post-qrftnizdsbuimxicolov:40forum.dlang.org
H
On Thursday, 31 October 2013 at 08:56:12 UTC, Gary Willoughby
wrote:
This bug also seems to affect GDC and LDC.
http://forum.dlang.org/thread/wzzfsnshgdjdoypan...@forum.dlang.org#post-qrftnizdsbuimxicolov:40forum.dlang.org
How is this related to the (since fixed) LDC dirEntries issue?
The lat
On Thursday, 31 October 2013 at 08:42:49 UTC, monarch_dodra wrote:
On Thursday, 31 October 2013 at 01:19:59 UTC, Timothee Cour
wrote:
see my recent regressions I posted on bugzilla.
Adding a link always helps:
http://d.puremagic.com/issues/show_bug.cgi?id=11392
Do you have any idea if this
On 31 October 2013 08:56, Gary Willoughby wrote:
> On Thursday, 31 October 2013 at 08:42:49 UTC, monarch_dodra wrote:
>
>> On Thursday, 31 October 2013 at 01:19:59 UTC, Timothee Cour wrote:
>>
>>> see my recent regressions I posted on bugzilla.
>>>
>&
On Thursday, 31 October 2013 at 08:42:49 UTC, monarch_dodra wrote:
On Thursday, 31 October 2013 at 01:19:59 UTC, Timothee Cour
wrote:
see my recent regressions I posted on bugzilla.
Adding a link always helps:
http://d.puremagic.com/issues/show_bug.cgi?id=11392
Do you have any idea if this
On Thursday, 31 October 2013 at 01:19:59 UTC, Timothee Cour wrote:
see my recent regressions I posted on bugzilla.
Adding a link always helps:
http://d.puremagic.com/issues/show_bug.cgi?id=11392
Do you have any idea if this worked in beta 1-3 ? It would help
locate the regression. I *pray
On 10/31/13, 2:19, Timothee Cour wrote:
see my recent regressions I posted on bugzilla.
Ugh, you don't want to know how much time I wasted on this. I was
convinced it was something I had done, some old phobos somewhere.
see my recent regressions I posted on bugzilla.
On Sunday, 25 August 2013 at 20:02:49 UTC, Joseph Rushton
Wakeling wrote:
On 25/08/13 21:57, Dicebot wrote:
I do want to contribute one once I decide what I want to do
about a more
powerful server (such suite is a bit too hard for my small
VPS). Pretty sure
something can be done this year, but
On 25/08/13 21:57, Dicebot wrote:
I do want to contribute one once I decide what I want to do about a more
powerful server (such suite is a bit too hard for my small VPS). Pretty sure
something can be done this year, but will take some time (months+).
Is this something where we can do some crow
On Saturday, 24 August 2013 at 07:50:00 UTC, Joseph Rushton
Wakeling wrote:
I proposed something along these lines shortly after DConf:
http://forum.dlang.org/thread/mailman.47.1369319426.13711.digitalmar...@puremagic.com
I thought it could be useful both as a stability tester _and_
as a means
On 23/08/13 20:38, H. S. Teoh wrote:
One idea that occurred to me is to put large external projects under a
separate tester, not bound to the core dmd/druntime/phobos autotesting,
but an independent tester that regularly checks out git HEAD and
compiles & tests said large projects.
I proposed s
On Fri, Aug 23, 2013 at 11:07 AM, Walter Bright
wrote:
> That's exactly the problem. If these large projects are incorporated into
> the autotester, who is going to isolate/fix problems arising with them?
>
> The test suite is designed to be a collection of already-isolated issues,
> so understand
On Sat, Aug 24, 2013 at 01:18:14AM +0200, David Nadlinger wrote:
[...]
> Maybe we can pull this off with an improved beta process where all D
> users are actually persuaded to participate. But seeing that Walter
> seems to avoid incorporating any of the ideas in that direction that
> have been brou
On Friday, 23 August 2013 at 20:13:21 UTC, Andrej Mitrovic wrote:
On 8/23/13, H. S. Teoh wrote:
The devs can then monitor the
status of these tests independently, and when something goes
wrong, they
can ping whoever is responsible for that project to
investigate what
might be the cause.
Th
On 8/23/2013 3:11 PM, David wrote:
I find it funny how hard you try to get D "production ready" and make
(in my opinion) bad decisions affecting the future of D, but I hit every
release at least 3 regressions, 1 of these is mostly a real WTF.
Please join us in the beta test program,
gt; team, i.e. who is responsible for it has been badly blurred.
>
I find it funny how hard you try to get D "production ready" and make
(in my opinion) bad decisions affecting the future of D, but I hit every
release at least 3 regressions, 1 of these is mostly a real WTF.
At lea
On 8/23/13, H. S. Teoh wrote:
> The devs can then monitor the
> status of these tests independently, and when something goes wrong, they
> can ping whoever is responsible for that project to investigate what
> might be the cause.
That's basically the same thing I said in that other thread.
Consid
h keeping up with.
This way we don't slow down development / autotesting unnecessarily, and
still let the community know when there might be potential problems with
existing code. (It probably also helps for the core devs to be aware of
potential regressions without being held back from code c
On 8/23/2013 10:34 AM, Denis Shelomovskij wrote:
By the way, the ability to add costume projects to D autotester is already
proposed without any response:
http://forum.dlang.org/thread/kqm4ta$m7f$1...@digitalmars.com
The question comes up repeatedly, and I've answered it repeatedly, the latest
13.08.2013 21:49, glycerine пишет:
Grrr...
Apparently nobody has been testing the D - Apache Thrift bindings
since 2.061, and dmd has since accumulated multiple regressions
that affect the correctness of the Thrift implementation. I
emailed with David N. and he said that this was quite common
On Tuesday, August 13, 2013 19:49:51 glycerine wrote:
> Grrr...
>
> Apparently nobody has been testing the D - Apache Thrift bindings
> since 2.061, and dmd has since accumulated multiple regressions
> that affect the correctness of the Thrift implementation. I
> emailed with Da
Grrr...
Apparently nobody has been testing the D - Apache Thrift bindings
since 2.061, and dmd has since accumulated multiple regressions
that affect the correctness of the Thrift implementation. I
emailed with David N. and he said that this was quite common for
each release of dmd, and that
Am Sat, 13 Jul 2013 22:37:45 +0200
schrieb "Robert" :
>
> > But one comment though: Do you really need string mixins? I
> > think
> > "Signal!int mysignal;" is a much nicer syntax in D than using
>
> I agree and you don't need the string mixin, it is just for
> convenience. The signal itself i
On 7/14/13, Damian wrote:
> Having tried this I can't get ref parameters to work as function
> arguments, are they supported?
This is a language issue, you can't pass 'ref' as a template parameter.
On Friday, 12 July 2013 at 22:35:06 UTC, David wrote:
Am 12.07.2013 23:47, schrieb Robert:
I just finished a new implementation, replacing the template
mixin with
a string mixin. I also changed the name from signals2 to
signal. You can
find it here:
https://github.com/phobos-x/phobosx/blob/ma
But one comment though: Do you really need string mixins? I
think
"Signal!int mysignal;" is a much nicer syntax in D than using
I agree and you don't need the string mixin, it is just for
convenience. The signal itself is a struct. But what was
important to me was that one can easily restri
Am Sat, 13 Jul 2013 15:47:35 +0200
schrieb David :
> Am 13.07.2013 10:14, schrieb Robert:
> >
>
> [1]https://github.com/AndrejMitrovic/new_signals
> >
> >
> > Hmm, ok this implementation does not implement weak ref semantics,
> > but it does implement some fancy features like enabling
Am 13.07.2013 10:14, schrieb Robert:
>
[1]https://github.com/AndrejMitrovic/new_signals
>
>
> Hmm, ok this implementation does not implement weak ref semantics, but
> it does implement some fancy features like enabling/disabling emission,
> adding slots at a specified position and stuf
[1]https://github.com/AndrejMitrovic/new_signals
Hmm, ok this implementation does not implement weak ref
semantics, but it does implement some fancy features like
enabling/disabling emission, adding slots at a specified position
and stuff. At least for enabling/disabling I decided not to
On Saturday, 13 July 2013 at 01:24:11 UTC, Andrej Mitrovic wrote:
On 7/13/13, David wrote:
Bad timing, just got "our"[1] own implementation.
If I have time, I'll play around with it! Thanks for the great
work,
maybe we can get something working into phobos...
[1]https://github.com/AndrejMit
On 7/13/13, David wrote:
> Bad timing, just got "our"[1] own implementation.
> If I have time, I'll play around with it! Thanks for the great work,
> maybe we can get something working into phobos...
>
>
> [1]https://github.com/AndrejMitrovic/new_signals
Disclaimer: This is the work of Johannes P
Am 12.07.2013 23:47, schrieb Robert:
> I just finished a new implementation, replacing the template mixin with
> a string mixin. I also changed the name from signals2 to signal. You can
> find it here:
>
> https://github.com/phobos-x/phobosx/blob/master/source/phobosx/signal.d
>
> All unittests p
I just finished a new implementation, replacing the template mixin with
a string mixin. I also changed the name from signals2 to signal. You can
find it here:
https://github.com/phobos-x/phobosx/blob/master/source/phobosx/signal.d
All unittests pass, you don't need any patched compiler. I still h
Am 17.06.2013 22:23, schrieb Robert:
>>> Current master is an experimental CAS based implementation- untested and
>>> very likely to get completely reworked internally.
>>
>> Good to know, but that is already a few monce old, or? I remember seeing
>> CAS in the code though
> It is yes. It is blocke
> > Current master is an experimental CAS based implementation- untested and
> > very likely to get completely reworked internally.
>
> Good to know, but that is already a few monce old, or? I remember seeing
> CAS in the code though
It is yes. It is blocked and I got busy with other stuff, so I d
>> https://github.com/eskimor/phobos/blob/new_signal/std/signals.d
>>
>> It is completly unusable, "mixin Signal!() x" is blocked by bug, it
>> doesn't compile due to a wrong type (relativly easy fix), then when
>> using -unittest it fails to compile, compiler also doesn't give any
>> hints what ex
On Sun, 2013-06-16 at 15:25 +0200, David wrote:
> I looked into the "new std.signals" today:
Thanks for having a look :-)
>
> https://github.com/eskimor/phobos/blob/new_signal/std/signals.d
>
> It is completly unusable, "mixin Signal!() x" is blocked by bug, it
> doesn't compile due to a wrong
I looked into the "new std.signals" today:
https://github.com/eskimor/phobos/blob/new_signal/std/signals.d
It is completly unusable, "mixin Signal!() x" is blocked by bug, it
doesn't compile due to a wrong type (relativly easy fix), then when
using -unittest it fails to compile, compiler also doe
15.06.2013 14:19, David пишет:
>> http://dlang.org/phobos/std_signals.html#Signal
>> "Mixin to create a signal within a class object."
>>
>> So your `X` must be a class.
> Oh right I have totally overseen that, still used to work really well
> with 2.063
It can work only by accident iff the struct
14.06.2013 18:31, David пишет:
This code currently fails with a RangeError (used to work in 2.062)
// http://dpaste.dzfl.pl/332a71ec
import std.stdio;
import std.signals;
struct X {
mixin Signal!();
}
class O {
void m() {}
}
void main() {
O o = new O();
X[stri
This code currently fails with a RangeError (used to work in 2.062)
// http://dpaste.dzfl.pl/332a71ec
import std.stdio;
import std.signals;
struct X {
mixin Signal!();
}
class O {
void m() {}
}
void main() {
O o = new O();
X[string] aa;
aa["o"] = X.init;
On 09/11/2010 02:01, Don wrote:
If anyone would like to use the latest compiler release, but cannot
because of a compiler regression, please specify which bug is the
blocker (and whether you are using D1 or D2).
I'll try to get any such compiler regressions fixed in the next release.
== Quote from Don (nos...@nospam.com)'s article
> If anyone would like to use the latest compiler release, but cannot
> because of a compiler regression, please specify which bug is the
> blocker (and whether you are using D1 or D2).
> I'll try to get any such compiler re
If anyone would like to use the latest compiler release, but cannot
because of a compiler regression, please specify which bug is the
blocker (and whether you are using D1 or D2).
I'll try to get any such compiler regressions fixed in the next release.
60 matches
Mail list logo
