Am 27.01.2018 um 08:40 schrieb Walter Bright:
This clearly should be in bugzilla.
https://issues.dlang.org/show_bug.cgi?id=18324
--
Kind Regards
Benjamin Thaut
On Saturday, 27 January 2018 at 23:12:01 UTC, H. S. Teoh wrote:
On Sat, Jan 27, 2018 at 09:22:07PM +, timotheecour via
Digitalmars-d wrote: [...]
```
28 dscanner0x00010d59f428
@safe void
...
I proposed a compile-time introspected getopt() replacement
bef
On Saturday, 27 January 2018 at 23:12:01 UTC, H. S. Teoh wrote:
I proposed a compile-time introspected getopt() replacement
before
https://github.com/jasonwhite/darg this?
On Sat, Jan 27, 2018 at 03:48:19PM -0800, Timothee Cour wrote:
[...]
> eg `ldc -hash-threshold` would be 1 option.
[...]
> with a small threshold:
>
> mangled:
> _D8analysis3run__T9shouldRunℂ0abf2284dd3
>
> demangled:
> pure nothrow @nogc @safe immutable(char)[] analysis.run.shouldRun.ℂ0abf2284dd
* This has nothing to do with name mangling.
Yes and no, these things are coupled. We can improve the situation by
forcing the size of mangled and demangled symbols to be < threshold,
eg `ldc -hash-threshold` would be 1 option.
example:
current mangled:
_D8analysis3run__T9shouldRunVAyaa20_666c6f
On Sat, Jan 27, 2018 at 09:22:07PM +, timotheecour via Digitalmars-d wrote:
[...]
> ```
> 28 dscanner0x00010d59f428 @safe void
> std.getopt.getoptImpl!(std.getopt.config, immutable(char)[], bool*,
> immutable(char)[], bool*, immutable(char)[], bool*, immutable(c
but this should be handled at the compiler level, with no change in
standard library getopt, eg using a hashing scheme (cf `ldc
-hashthres`)
On Sat, Jan 27, 2018 at 2:38 PM, Kagamin via Digitalmars-d
wrote:
> IIRC several years ago somebody created a dub package with DbI getopt. I
> think it woul
IIRC several years ago somebody created a dub package with DbI
getopt. I think it wouldn't suffer from this issue.
On Saturday, 27 January 2018 at 10:38:46 UTC, Kagamin wrote:
dmd
see also this horrendous stacktrace when calling getopt with a
bad argument:
full stacktrace:
https://gist.github.com/timotheecour/d6b623bd3d223f5d958cd86adffd7807
just 1 line of this stacktrace:
```
28 dscanner
dmd
On Saturday, 27 January 2018 at 07:40:16 UTC, Walter Bright wrote:
This clearly should be in bugzilla.
As phobos or dmd bug?
On 1/25/2018 10:21 AM, Benjamin Thaut wrote:
So I was thinking to myself: Is it really a good idea to lower string switches
to a template if it results in such symbols? This symbol alone takes 17815 Bytes.
If we think this is a good idea, should we rewrite this particular string switch
to use
On 1/25/18 1:41 PM, H. S. Teoh wrote:
On Thu, Jan 25, 2018 at 07:21:29PM +0100, Benjamin Thaut via Digitalmars-d
wrote:
If we think this is a good idea, should we rewrite this particular
string switch to use a associative array instead to avoid the overly
long symbol name?
[...]
I believe
On Thu, Jan 25, 2018 at 11:42:03AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
> On Thursday, January 25, 2018 19:21:29 Benjamin Thaut via Digitalmars-d
> wrote:
> > If we think this is a good idea, should we rewrite this particular
> > string switch to use a associativ
ases as merely requiring a
unique symbol, then we could just substitute the whole monstrous thing
with a hash, like an MD5 or SHA checksum, which will be much less than
100 bytes.
> If we think this is a good idea, should we rewrite this particular
> string switch to use a associative
Am 25.01.2018 um 19:42 schrieb Jonathan M Davis:
That particular switch statement is in a function that's deprecated and
scheduled to be completely removed in about six months, so I don't see much
point in worrying about it unless it's causing serious problems, and while
that
On Thursday, January 25, 2018 19:21:29 Benjamin Thaut via Digitalmars-d
wrote:
> If we think this is a good idea, should we rewrite this particular
> string switch to use a associative array instead to avoid the overly
> long symbol name?
That particular switch statement is in a functi
Africa/Lubumbashi", "Africa/Nouakchott", "Africa/Porto-Novo",
"America/Anchorage", "America/Araguaina", "America/Boa_Vista",
"America/Catamarca", "America/Chihuahua", "America/Fortaleza",
"America/Glace_Bay", "America/Goose_Bay", "America/Guatemala",
"America/Guayaquil", "America/Matamoros", "America/Menominee",
"America/Monterrey", "America/Sao_Paulo", "America/St_Thomas",
"America/Vancouver", "Antarctica/Mawson", "Antarctica/Palmer",
"Antarctica/Vostok", "Asia/Kuala_Lumpur", "Asia/Novokuznetsk",
"Europe/Bratislava", "Europe/Copenhagen", "Europe/Luxembourg",
"Europe/San_Marino", "Europe/Simferopol", "Europe/Zaporozhye",
"Pacific/Enderbury", "Pacific/Galapagos", "Pacific/Kwajalein",
"Pacific/Marquesas", "Pacific/Pago_Pago", "Pacific/Rarotonga",
"Pacific/Tongatapu", "Africa/Addis_Ababa", "Africa/Brazzaville",
"Africa/Ouagadougou", "America/Costa_Rica", "America/Grand_Turk",
"America/Guadeloupe", "America/Hermosillo", "America/Kralendijk",
"America/Louisville", "America/Martinique", "America/Montevideo",
"America/Montserrat", "America/Paramaribo", "America/Rio_Branco",
"America/St_Vincent", "America/Whitehorse", "Antarctica/McMurdo",
"Antarctica/Rothera", "Asia/Srednekolymsk", "Asia/Yekaterinburg",
"Atlantic/Reykjavik", "Atlantic/St_Helena", "Australia/Adelaide",
"Australia/Brisbane", "Australia/Lindeman", "Europe/Isle_of_Man",
"Europe/Kaliningrad", "Pacific/Kiritimati", "Africa/Johannesburg",
"America/El_Salvador", "America/Los_Angeles", "America/Mexico_City",
"America/Pangnirtung", "America/Porto_Velho", "America/Puerto_Rico",
"America/Rainy_River", "America/Tegucigalpa", "America/Thunder_Bay",
"America/Yellowknife", "Arctic/Longyearbyen", "Atlantic/Cape_Verde",
"Australia/Lord_Howe", "Australia/Melbourne", "Indian/Antananarivo",
"Pacific/Guadalcanal", "Africa/Dar_es_Salaam", "America/Blanc-Sablon",
"America/Buenos_Aires", "America/Campo_Grande", "America/Danmarkshavn",
"America/Dawson_Creek", "America/Indiana/Knox", "America/Indianapolis",
"America/Rankin_Inlet", "America/Santa_Isabel", "America/Scoresbysund",
"Antarctica/Macquarie", "Pacific/Bougainville", "Pacific/Port_Moresby",
"America/Cambridge_Bay", "America/Coral_Harbour",
"America/Indiana/Vevay", "America/Lower_Princes",
"America/Port_of_Spain", "America/Santo_Domingo",
"America/St_Barthelemy", "America/Swift_Current",
"Australia/Broken_Hill", "America/Bahia_Banderas",
"America/Port-au-Prince", "Atlantic/South_Georgia",
"America/Argentina/Salta", "America/Indiana/Marengo",
"America/Indiana/Winamac", "America/Argentina/Tucuman",
"America/Argentina/Ushuaia", "America/Indiana/Tell_City",
"America/Indiana/Vincennes", "Antarctica/DumontDUrville",
"America/Argentina/La_Rioja", "America/Argentina/San_Juan",
"America/Argentina/San_Luis", "America/Indiana/Petersburg",
"America/Kentucky/Monticello", "America/North_Dakota/Beulah",
"America/North_Dakota/Center", "America/Argentina/Rio_Gallegos",
"America/North_Dakota/New_Salem").__switch(scope const(immutable(char)[]))
So I was thinking to myself: Is it really a good idea to lower string
switches to a template if it results in such symbols? This symbol alone
takes 17815 Bytes.
If we think this is a good idea, should we rewrite this particular
string switch to use a associative array instead to avoid the overly
long symbol name?
--
Kind Regards
Benjamin Thaut
On Friday, 5 January 2018 at 22:55:43 UTC, Adam D. Ruppe wrote:
On Friday, 5 January 2018 at 22:45:15 UTC, Walter Bright wrote:
I could easily spend 30 hours per day just reading the n.g.
Learn threads tend to be quite short. Just skim the first post
in a thread to see what people talk about.
On Friday, 5 January 2018 at 22:45:15 UTC, Walter Bright wrote:
On 1/5/2018 3:04 AM, Paolo Invernizzi wrote:
Adam suggested Walter to follow the 'learn' forum to have a
cleaner idea about common problems in the language usage, and
Walter replied that he prefers to invest his time digging and
On Friday, 5 January 2018 at 22:45:15 UTC, Walter Bright wrote:
On 1/5/2018 3:04 AM, Paolo Invernizzi wrote:
Adam suggested Walter to follow the 'learn' forum to have a
cleaner idea about common problems in the language usage, and
Walter replied that he prefers to invest his time digging and
On Friday, 5 January 2018 at 22:45:15 UTC, Walter Bright wrote:
I could easily spend 30 hours per day just reading the n.g.
Learn threads tend to be quite short. Just skim the first post in
a thread to see what people talk about. It takes mere minutes,
spread out over the day.
On 1/5/2018 3:04 AM, Paolo Invernizzi wrote:
Adam suggested Walter to follow the 'learn' forum to have a cleaner idea about
common problems in the language usage, and Walter replied that he prefers to
invest his time digging and solving Bugzilla issues...
I could easily spend 30 hours per day
On Friday, 5 January 2018 at 13:22:00 UTC, Paolo Invernizzi wrote:
- be quantitative: your download statistics are a good start,
try to collect from commercials statistics about the length of
the codebase, the compilation times, how many are using a
feature (C++ integration, allocators, scope
On Friday, 5 January 2018 at 13:02:20 UTC, Andrei Alexandrescu
wrote:
On 1/5/18 6:04 AM, Paolo Invernizzi wrote:
Andrei recently posted that he is following less the forums as
he prefer to invest his time in a different way ...
Adam suggested Walter to follow the 'learn' forum to have a
cleaner
On 1/5/18 6:04 AM, Paolo Invernizzi wrote:
Andrei recently posted that he is following less the forums as he prefer
to invest his time in a different way ...
Adam suggested Walter to follow the 'learn' forum to have a cleaner idea
about common problems in the language usage, and Walter replied t
On Thursday, 4 January 2018 at 12:11:36 UTC, rjframe wrote:
Python has more than 6000, 2000+ with patches[2].
Most appears to be library related or improvement requests…
I don't think numbers is the right metric.
Tools with as many users as Python will get a lot of issues
reported irrespecti
On Thursday, 4 January 2018 at 19:06:14 UTC, Jonathan M Davis
wrote:
On Thursday, January 04, 2018 10:27:37 H. S. Teoh via
Digitalmars-d wrote:
On Thu, Jan 04, 2018 at 10:23:57AM +, Paolo Invernizzi via
Digitalmars-d wrote:
> On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh
> wrote:
On Thursday, 4 January 2018 at 20:05:30 UTC, Steven Schveighoffer
wrote:
On 1/4/18 2:21 PM, H. S. Teoh wrote:
Another person I miss is bearophile... while AFAIK he did not
actually
contribute code, he was very active in submitting bugs and
enhancement
requests, many of which led to significant
On Thursday, 4 January 2018 at 18:27:37 UTC, H. S. Teoh wrote:
So, one can choose to be part of the noise, or part of the real
work. If you don't like the way certain things are done, then
step up and do it differently.
I hear this argument too much in the D community. It is not the
solution
On 1/4/18 2:21 PM, H. S. Teoh wrote:
Another person I miss is bearophile... while AFAIK he did not actually
contribute code, he was very active in submitting bugs and enhancement
requests, many of which led to significant improvements to D. He also
just dropped off the radar without any sign of
On Thu, Jan 04, 2018 at 12:06:14PM -0700, Jonathan M Davis via Digitalmars-d
wrote:
> On Thursday, January 04, 2018 10:27:37 H. S. Teoh via Digitalmars-d wrote:
> > On Thu, Jan 04, 2018 at 10:23:57AM +, Paolo Invernizzi via
> Digitalmars-d wrote:
[...]
> > > I'm missing Kenji...
> >
> > Me to
On Thursday, January 04, 2018 10:27:37 H. S. Teoh via Digitalmars-d wrote:
> On Thu, Jan 04, 2018 at 10:23:57AM +, Paolo Invernizzi via
Digitalmars-d wrote:
> > On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh wrote:
> > > [...]
> >
> > I'm missing Kenji...
>
> Me too. :-( Does anybody
On Thu, Jan 04, 2018 at 10:23:57AM +, Paolo Invernizzi via Digitalmars-d
wrote:
> On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh wrote:
> > [...]
>
> I'm missing Kenji...
Me too. :-( Does anybody know what happened to him? He just sortof
dropped off the radar suddenly and I haven't
On Thursday, 4 January 2018 at 12:11:36 UTC, rjframe wrote:
At the time of writing:
Ansible has 3391 open bugs[1] (and ~master is often used in
production).
Python has more than 6000, 2000+ with patches[2].
GCC (C and C++ components only) has 3119[3].
Bugs are part of software. That's just li
On Thu, 04 Jan 2018 06:16:45 +, codephantom wrote:
> This is not my area of experise, but, if I were a manager evaluating the
> merits of D for use in a corporate software project, and then I went off
> to bugzilla and looked at the items for D.. I'd pause and think.wtf
> is going on here.
On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh wrote:
It all comes down to who's doing the actual work vs. who's just
telling others what they think they should be doing, which
rarely, if ever, works.
I think that view really needs to be challenged.
Those who might be willing to c
On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh wrote:
[...]
I'm missing Kenji...
On Thu, Jan 04, 2018 at 06:39:24AM +, Mike Parker via Digitalmars-d wrote:
[...]
> In the meantime, you could help reduce the pile by picking a bug to fix
> today. Multiple people, particularly those concerned about the number of old
> issues still open, who donate one or two days a month to fi
On Thursday, 4 January 2018 at 06:39:24 UTC, Mike Parker wrote:
I have an idea I'm working on to potentially help get older
bugs squashed and older PRs merged. I need to hash out the
details before getting it going, but I'll blog about when (and
if) it comes to fruition. There are no guarante
On Thursday, 4 January 2018 at 06:39:24 UTC, Mike Parker wrote:
If you know how to get a bunch of volunteers with such varied
interests to work in a concerted direction, please do tell.
This is the mystery behind everything in the universe.
Why haven't you solved it yet?
On Thursday, 4 January 2018 at 06:16:45 UTC, codephantom wrote:
I doubt very much whether just allowing stuff to pile up in
some bugzilla repository, is a best practice.
Several bugs get wiped in each release, as the changelogs clearly
show. It's not as if they're being ignored.
If you kn
On Thursday, 4 January 2018 at 05:28:40 UTC, IM wrote:
To clarify, I too like D. It is certainly very pleasant to work
with. This post wasn't about GitHub issues vs Bugzilla. That
was a get-off-at-a-tangent topic. This post is about what's
needed for a more mature D; mature enough for extreme
On Tuesday, 2 January 2018 at 16:32:50 UTC, H. S. Teoh wrote:
On Tue, Jan 02, 2018 at 09:57:08AM +, Patrick Schluter via
Digitalmars-d wrote:
On Monday, 1 January 2018 at 18:32:37 UTC, Pjotr Prins wrote:
[...]
> I am just going to share my thoughts a little. Github, in my
> opinion, is hyp
On Tue, Jan 02, 2018 at 09:57:08AM +, Patrick Schluter via Digitalmars-d
wrote:
> On Monday, 1 January 2018 at 18:32:37 UTC, Pjotr Prins wrote:
[...]
> > I am just going to share my thoughts a little. Github, in my
> > opinion, is hype and even though I depend on it today, I am trying
> > to d
On Monday, 1 January 2018 at 18:32:37 UTC, Pjotr Prins wrote:
On Monday, 1 January 2018 at 02:02:03 UTC, rjframe wrote:
That's probably not the best method of effecting change.
It killed off the discussion nicely, indeed.
I am just going to share my thoughts a little. Github, in my
opinion,
On Monday, 1 January 2018 at 02:02:03 UTC, rjframe wrote:
That's probably not the best method of effecting change.
It killed off the discussion nicely, indeed.
I am just going to share my thoughts a little. Github, in my
opinion, is hype and even though I depend on it today, I am
trying to d
On Sun, 31 Dec 2017 17:19:22 -0700, Jonathan M Davis wrote:
> Yes, it would be a pain to switch away from github at this point, but if
> github went down permanently tomorrow, it would just be an annoying
> roadblock. We almost certainly wouldn't lose any code (at most, a few
> c
On Sun, 31 Dec 2017 23:50:04 +, Mengu wrote:
> - d leadership is dusty and so are their tools. we are no js community
> and hope we never become anything like them but bugzilla is a hundred
> years old. i am on github, i am on this ml and i also need a bugzilla
> account?
That's probably not
enty of projects on github don't use
github issues.
If we were starting from scratch, then maybe it would make sense to use
github issues instead of our own bugzilla, but given that we already have
bugzilla, it works just fine, and github issues really don't seem to offer
anything signi
ways right,
especially when you're trying to get them to donate their time
to an open source project. It's more essential than ever that
we lower barriers to participation; if Github issues is the hip
new thing all the kids like, then we need to switch to that. We
shouldn't be cons
em to donate their time to an open
source project. It's more essential than ever that we lower
barriers to participation; if Github issues is the hip new thing
all the kids like, then we need to switch to that. We shouldn't
be constantly switching to the shiniest new toy, but nor shoul
On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe
wrote:
On Saturday, 30 December 2017 at 02:37:24 UTC, IM wrote:
Just curious, why Bugzilla and not something else?
Bugzilla was the most well-known solution at the time. Keep in
mind the D bugzilla has been around since 2006. As far
On Monday, 6 November 2017 at 10:10:29 UTC, Atila Neves wrote:
Checking for types at runtime is a code smell in OOP. Sometimes
necessary, especially if doing multiple dispatch, but never
done gladly. There's already a way to dispatch on type: virtual
functions.
Atila
More on that:
https://w
On Thursday, 2 November 2017 at 20:37:11 UTC, user1234 wrote:
switch (i)
default: break;
}
you have 3 non-ambiguous and contiguous statements without a
block: a switch, a default case (the "free-floating" one) and a
break. Now why is this allowed is another story ;)
I&
and better
readable, if instead of:
if(bitmapObject.classinfo == typeof(Bitmap4Bit)){
...
}else if(bitmapObject.classinfo == typeof(Bitmap8Bit)){...
I could easily use this:
switch(bitmapObject.classinfo){
case typeof(Bitmap4Bit):
...
case typeof(Bitmap8Bit):
}
On the other hand I cannot
and better
readable, if instead of:
if(bitmapObject.classinfo == typeof(Bitmap4Bit)){
...
}else if(bitmapObject.classinfo == typeof(Bitmap8Bit)){...
I could easily use this:
switch(bitmapObject.classinfo){
case typeof(Bitmap4Bit):
...
case typeof(Bitmap8Bit):
}
On the other hand I cannot
and better
readable, if instead of:
if(bitmapObject.classinfo == typeof(Bitmap4Bit)){
...
}else if(bitmapObject.classinfo == typeof(Bitmap8Bit)){...
I could easily use this:
switch(bitmapObject.classinfo){
case typeof(Bitmap4Bit):
...
case typeof(Bitmap8Bit):
}
On the other hand I cannot
and better
readable, if instead of:
if(bitmapObject.classinfo == typeof(Bitmap4Bit)){
...
}else if(bitmapObject.classinfo == typeof(Bitmap8Bit)){...
I could easily use this:
switch(bitmapObject.classinfo){
case typeof(Bitmap4Bit):
...
case typeof(Bitmap8Bit):
}
On the other hand I cannot
== typeof(Bitmap4Bit)){
...
}else if(bitmapObject.classinfo == typeof(Bitmap8Bit)){...
I could easily use this:
switch(bitmapObject.classinfo){
case typeof(Bitmap4Bit):
...
case typeof(Bitmap8Bit):
}
On the other hand I cannot really think other uses for such
language feature, maybe with structs.
On Thursday, 17 August 2017 at 13:11:51 UTC, Enamex wrote:
On Wednesday, 16 August 2017 at 14:19:59 UTC, SrMordred wrote:
On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
[...]
There are two thinks of c++ that I miss a little on D:
- Structured binding
- Uniform initialization
Bu
On Wednesday, 16 August 2017 at 14:19:59 UTC, SrMordred wrote:
On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler
wrote:
Without alot of usage, it will just be an esoteric construct
that looks confusing to the average devel
On Wednesday, 16 August 2017 at 13:40:47 UTC, Guillaume Boucher
wrote:
On Wednesday, 16 August 2017 at 12:58:03 UTC, Joakim wrote:
That is correct. After a while it gets tiring to see a
neverending stream of complexity added to the language while
things that would actually help (like IDE suppor
On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler
wrote:
Without alot of usage, it will just be an esoteric construct
that looks confusing to the average developer.
That is correct. After a while it gets tiring to see a
On Wednesday, 16 August 2017 at 13:40:47 UTC, Guillaume Boucher
wrote:
I like that. Feature freeze D until *all* bug reports are
closed.
While that would mean no more features for several years, I
think it would benefit the language in the long run, both
internally (less discussions about in
On Wednesday, 16 August 2017 at 12:58:03 UTC, Joakim wrote:
That is correct. After a while it gets tiring to see a
neverending stream of complexity added to the language while
things that would actually help (like IDE support) do not get
any attention.
+1, though I'd go for bug-fixing over ID
On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler
wrote:
Without alot of usage, it will just be an esoteric construct
that looks confusing to the average developer.
That is correct. After a while it gets tiring to see a
On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler wrote:
Without alot of usage, it will just be an esoteric construct
that looks confusing to the average developer.
That is correct. After a while it gets tiring to see a
neverending stream of complexity added to the language while
t
On Tuesday, 15 August 2017 at 20:17:40 UTC, ag0aep6g wrote:
On 08/15/2017 08:55 PM, Daniel Kozak wrote:
C++17 will have this feature:
https://tech.io/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/init-statement-for-ifswitch
What do you think about it, can we have something si
On 08/15/2017 08:55 PM, Daniel Kozak wrote:
C++17 will have this feature:
https://tech.io/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/init-statement-for-ifswitch
What do you think about it, can we have something similar to that.
Maybe something like this:
int func() retu
On Tuesday, 15 August 2017 at 19:24:00 UTC, Daniel Kozak wrote:
int func() { return 5; }
int func() return 5;
was a typo in all my previous posts :)
On Tuesday, 15 August 2017 at 19:04:32 UTC, Daniel Kozak wrote:
On Tuesday, 15 August 2017 at 18:55:57 UTC, Daniel Kozak wrote:
C++17 will have this feature:
int func() return 5;
with(auto x = func()) if (condition(x))
do_something_with(x);
else
do_something_else_with(x);
this would b
On Tuesday, 15 August 2017 at 18:55:57 UTC, Daniel Kozak wrote:
C++17 will have this feature:
https://tech.io/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/init-statement-for-ifswitch
What do you think about it, can we have something similar to
that.
Maybe something like this
C++17 will have this feature:
https://tech.io/playgrounds/2205/7-features-of-c17-that-will-simplify-your-code/init-statement-for-ifswitch
What do you think about it, can we have something similar to that.
Maybe something like this:
int func() return 5;
with(auto x = func()) if (condition(x))
On Sunday, 7 May 2017 at 15:16:48 UTC, Ali Çehreli wrote:
I've just commented on the following thread on the 'internals'
newsgroup:
http://forum.dlang.org/thread/tiiuucwivajgsnoos...@forum.dlang.org
I think this should be improved to display code that is being
mixed-in.
Ali
I just sub
I've just commented on the following thread on the 'internals' newsgroup:
http://forum.dlang.org/thread/tiiuucwivajgsnoos...@forum.dlang.org
I think this should be improved to display code that is being mixed-in.
Ali
On Tuesday, 28 March 2017 at 05:37:11 UTC, Nick Sabalausky
(Abscissa) wrote:
On 03/26/2017 11:25 PM, Adam Wilson wrote:
Hi Everyone,
I know that the licensing around OpenSSL has been a somewhat
controversial topic around the D world. So I though that you
might find
this bit of news interestin
On 03/26/2017 11:25 PM, Adam Wilson wrote:
Hi Everyone,
I know that the licensing around OpenSSL has been a somewhat
controversial topic around the D world. So I though that you might find
this bit of news interesting:
https://www.openssl.org/blog/blog/2017/03/22/license/
What was it before?
Hi Everyone,
I know that the licensing around OpenSSL has been a somewhat
controversial topic around the D world. So I though that you might find
this bit of news interesting:
https://www.openssl.org/blog/blog/2017/03/22/license/
--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;
On Saturday, 6 August 2016 at 09:35:32 UTC, Walter Bright wrote:
On 8/6/2016 1:21 AM, Ilya Yaroshenko wrote:
We need 2 new pragmas with the same syntax as `pragma(inline,
xxx)`:
1. `pragma(fusedMath)` allows fused mul-add, mul-sub, div-add,
div-sub operations.
2. `pragma(fastMath)` equivalent
On 8/6/2016 11:45 PM, Ilya Yaroshenko wrote:
So it does make sense that allowing fused operations would be equivalent to
having no maximum precision.
Fused operations are mul/div+add/sub only.
Fused operations does not break compesator subtraction:
auto t = a - x + x;
So, please, make them as s
On 6 August 2016 at 22:12, David Nadlinger via Digitalmars-d
wrote:
> On Saturday, 6 August 2016 at 10:02:25 UTC, Iain Buclaw wrote:
>>
>> No pragmas tied to a specific architecture should be allowed in the
>> language spec, please.
>
>
> I wholeheartedly agree. However, it's not like FP optimisat
On Saturday, 6 August 2016 at 22:32:08 UTC, Walter Bright wrote:
On 8/6/2016 3:14 PM, David Nadlinger wrote:
Of course, if floating point values are strictly defined as
having only a
minimum precision, then folding away the rounding after the
multiplication is
always legal.
Yup.
So it does
On Saturday, 6 August 2016 at 21:56:06 UTC, Walter Bright wrote:
On 8/6/2016 1:06 PM, Ilya Yaroshenko wrote:
Some applications requires exactly the same results for
different architectures
(probably because business requirement). So this optimization
is turned off by
default in LDC for example
On 8/6/2016 3:14 PM, David Nadlinger wrote:
On Saturday, 6 August 2016 at 21:56:06 UTC, Walter Bright wrote:
Let me rephrase the question - how does fusing them alter the result?
There is just one rounding operation instead of two.
Makes sense.
Of course, if floating point values are stri
On Saturday, 6 August 2016 at 21:56:06 UTC, Walter Bright wrote:
Let me rephrase the question - how does fusing them alter the
result?
There is just one rounding operation instead of two.
Of course, if floating point values are strictly defined as
having only a minimum precision, then folding
e different optimisations in a more tasteful
manner as appropriate for their particular application.
Experience has shown that people – even those intimately familiar with FP
semantics – expect a catch-all kitchen-sink switch for all natural optimisations
(natural when equating FP values with
On 8/6/2016 1:06 PM, Ilya Yaroshenko wrote:
Some applications requires exactly the same results for different architectures
(probably because business requirement). So this optimization is turned off by
default in LDC for example.
Let me rephrase the question - how does fusing them alter the re
perience has shown that people – even those intimately familiar
with FP semantics – expect a catch-all kitchen-sink switch for
all natural optimisations (natural when equating FP values with
real numbers). This is why the shorthand exists.
— David
On Saturday, 6 August 2016 at 12:48:26 UTC, Iain Buclaw wrote:
There are compiler switches for that. Maybe there should be
one pragma to tweak these compiler switches on a per-function
basis, rather than separately named pragmas.
This might be a solution for inherently compiler-specific
sett
On Saturday, 6 August 2016 at 10:02:25 UTC, Iain Buclaw wrote:
No pragmas tied to a specific architecture should be allowed in
the language spec, please.
I wholeheartedly agree. However, it's not like FP optimisation
pragmas would be specific to any particular architecture. They
just describe
On Saturday, 6 August 2016 at 19:51:11 UTC, Walter Bright wrote:
On 8/6/2016 2:48 AM, Ilya Yaroshenko wrote:
I don't know what the point of fusedMath is.
It allows a compiler to replace two arithmetic operations with
single composed
one, see AVX2 (FMA3 for intel and FMA4 for AMD) instruction
s
On 8/6/2016 2:48 AM, Ilya Yaroshenko wrote:
I don't know what the point of fusedMath is.
It allows a compiler to replace two arithmetic operations with single composed
one, see AVX2 (FMA3 for intel and FMA4 for AMD) instruction set.
I understand that, I just don't understand why that wouldn't
On 8/6/2016 3:02 AM, Iain Buclaw via Digitalmars-d wrote:
No pragmas tied to a specific architecture should be allowed in the
language spec, please.
A good point. On the other hand, a list of them would be nice so implementations
don't step on each other.
On 8/6/2016 5:09 AM, Johannes Pfau wrote:
I think this restriction is also quite arbitrary.
You're right that there are gray areas, but the distinction is not arbitrary.
For example, mangling does not affect the interface. It affects the name.
Using an attribute has more downsides, as it affe
On 6 August 2016 at 16:11, Patrick Schluter via Digitalmars-d
wrote:
> On Saturday, 6 August 2016 at 10:02:25 UTC, Iain Buclaw wrote:
>>
>> On 6 August 2016 at 11:48, Ilya Yaroshenko via Digitalmars-d
>> wrote:
>>>
>>> On Saturday, 6 August 2016 at 09:35:32 UTC, Walter Bright wrote:
>>
On Saturday, 6 August 2016 at 10:02:25 UTC, Iain Buclaw wrote:
On 6 August 2016 at 11:48, Ilya Yaroshenko via Digitalmars-d
wrote:
On Saturday, 6 August 2016 at 09:35:32 UTC, Walter Bright
wrote:
No pragmas tied to a specific architecture should be allowed in
the language spec, please.
H
On 6 August 2016 at 13:30, Ilya Yaroshenko via Digitalmars-d
wrote:
> On Saturday, 6 August 2016 at 11:10:18 UTC, Iain Buclaw wrote:
>>
>> On 6 August 2016 at 12:07, Ilya Yaroshenko via Digitalmars-d
>> wrote:
>>>
>>> On Saturday, 6 August 2016 at 10:02:25 UTC, Iain Buclaw wrote:
O
Am Sat, 6 Aug 2016 02:29:50 -0700
schrieb Walter Bright :
> On 8/6/2016 1:21 AM, Ilya Yaroshenko wrote:
> > On Friday, 5 August 2016 at 20:53:42 UTC, Walter Bright wrote:
> >
> >> I agree that the typical summation algorithm suffers from double
> >> rounding. But that's one algorithm. I would ap
On Saturday, 6 August 2016 at 11:10:18 UTC, Iain Buclaw wrote:
On 6 August 2016 at 12:07, Ilya Yaroshenko via Digitalmars-d
wrote:
On Saturday, 6 August 2016 at 10:02:25 UTC, Iain Buclaw wrote:
On 6 August 2016 at 11:48, Ilya Yaroshenko via Digitalmars-d
wrote:
On Saturday, 6 August 2016
1 - 100 of 1069 matches
Mail list logo
