On Tuesday, 24 January 2017 at 00:52:34 UTC, Robert burner
Schadek wrote:
I have this program that used to compile with 72 but with 73
dmd is complaining that
"Error: escaping reference to local variable t"
auto ref f2(T)(auto ref T t, auto ref T s) {
return t;
}
auto ref f1(T)(auto re
The blacklisted functions are now down to only two.
Those are the bitswap function in druntime.
Because the interpreter does handle all values as 64bit
internally it tends to miscompile code that uses xor on 32bit
values.
And the second one is the "to" template from std.conv;
Because of the a
On Monday, 23 January 2017 at 22:09:27 UTC, David Nadlinger wrote:
On Monday, 23 January 2017 at 17:42:00 UTC, Stefan Koch wrote:
interpret3.d passes!!!
The only remaining issues that cause miscompiled code are
UTF(8/16/32) encoding and decoding issues.
Is that without bailing out?
— David
Nice idea, but didn't work either. Just got more errors. And my
eyes hurt now.
On 24 January 2017 at 10:52, Robert burner Schadek via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> I have this program that used to compile with 72 but with 73 dmd is
> complaining that
> "Error: escaping reference to local variable t"
>
> auto ref f2(T)(auto ref T t, auto ref T s) {
>
I have this program that used to compile with 72 but with 73 dmd
is complaining that
"Error: escaping reference to local variable t"
auto ref f2(T)(auto ref T t, auto ref T s) {
return t;
}
auto ref f1(T)(auto ref T t, auto ref T s) {
return f2(t, s);
}
unittest {
int a
On Monday, 23 January 2017 at 01:46:58 UTC, FatalCatharsis wrote:
On Monday, 23 January 2017 at 00:46:30 UTC, Profile Anaysis
wrote:
The real issue is ambiguity. Any time you have a cycle you
must be able to get out of it and so your rules must be
organized so that one always checks to see if t
On Monday, 23 January 2017 at 17:42:00 UTC, Stefan Koch wrote:
interpret3.d passes!!!
The only remaining issues that cause miscompiled code are
UTF(8/16/32) encoding and decoding issues.
Is that without bailing out?
— David
V Mon, 23 Jan 2017 17:42:00 +
Stefan Koch via Digitalmars-d napsáno:
> interpret3.d passes!!!
>
> The only remaining issues that cause miscompiled code are
> UTF(8/16/32) encoding and decoding issues.
WOW
On 1/23/17 6:42 PM, Stefan Koch wrote:
interpret3.d passes!!!
Now that's something!
The only remaining issues that cause miscompiled code are UTF(8/16/32)
encoding and decoding issues.
---
Dmitry Olshansky
On Monday, 23 January 2017 at 17:42:00 UTC, Stefan Koch wrote:
interpret3.d passes!!!
The only remaining issues that cause miscompiled code are
UTF(8/16/32) encoding and decoding issues.
Wow! Getting close know!
On 01/16/2017 02:39 AM, Jacob Carlborg wrote:
On 2017-01-09 22:41, aberba wrote:
This seemed to be an effort (among others) to bring GUI cross platform
to standard D but some language/compiler/Phobos/Deimos/manpower issues
were the drag.
https://github.com/Devisualization
We now have DLangUI.
On Monday, 23 January 2017 at 17:39:00 UTC, ixid wrote:
Speaking of killing things with fire (OT) - what's happening
with the comma operator? I want delicious tuples like Go.
They were deprecated in 2.072.0.
http://dlang.org/changelog/2.072.0.html#deprecated_commaexp
On Monday, 23 January 2017 at 17:39:00 UTC, ixid wrote:
On Friday, 11 September 2015 at 21:16:06 UTC, Brian Schott
wrote:
On Friday, 11 September 2015 at 20:29:56 UTC, Vladimir
Panteleev wrote:
Apparently it was decided at DConf 2015 to remove std.stream
and friends from Phobos.
Kill it with
interpret3.d passes!!!
The only remaining issues that cause miscompiled code are
UTF(8/16/32) encoding and decoding issues.
On Friday, 11 September 2015 at 21:16:06 UTC, Brian Schott wrote:
On Friday, 11 September 2015 at 20:29:56 UTC, Vladimir
Panteleev wrote:
Apparently it was decided at DConf 2015 to remove std.stream
and friends from Phobos.
Kill it with fire.
Speaking of killing things with fire (OT) - what'
On Sunday, 1 May 2016 at 17:06:19 UTC, Seb wrote:
On Sunday, 1 May 2016 at 14:31:10 UTC, Bauss wrote:
On Friday, 11 September 2015 at 20:29:56 UTC, Vladimir
Panteleev wrote:
https://github.com/D-Programming-Language/phobos/pull/3631
Apparently it was decided at DConf 2015 to remove std.stream
On Thursday, 19 January 2017 at 07:39:10 UTC, Jacob Carlborg
wrote:
If I'm looking for a new type of application I'll dismiss those
that don't look native very quickly. Unless I know beforehand
that the application is very good, then I'll give it some more
time.
I think it has more to do with
On 23/01/17 15:18, Andrei Alexandrescu wrote:
On 1/23/17 5:44 AM, Shachar Shemesh wrote:
If, instead of increasing its size by 100%, we increase it by a smaller
percentage of its previous size, we still maintain the amortized O(1)
cost (with a multiplier that might be a little higher, but see th
On 23/01/17 15:18, Andrei Alexandrescu wrote:
On 1/23/17 5:44 AM, Shachar Shemesh wrote:
If, instead of increasing its size by 100%, we increase it by a smaller
percentage of its previous size, we still maintain the amortized O(1)
cost (with a multiplier that might be a little higher, but see th
On Sunday, 8 January 2017 at 09:18:19 UTC, Suliman wrote:
Simply picking a worker thread + worker fiber when task is
assigned and sticking to it until finished should work good
enough. It is also important to note though that "fiber" is
not the same as "task". Former is execution context primit
On 1/23/17 5:44 AM, Shachar Shemesh wrote:
If, instead of increasing its size by 100%, we increase it by a smaller
percentage of its previous size, we still maintain the amortized O(1)
cost (with a multiplier that might be a little higher, but see the trade
off). On the other hand, we can now reu
On Monday, 23 January 2017 at 11:30:35 UTC, Shachar Shemesh wrote:
It is possible to tweak the numbers based on the overall use.
For example, add 100% for arrays smaller than 1MB, 50% for 1MB
- 100MB, and 20% for arrays above 100MB big. This would
eliminate the performance degradation for almos
One more thing.
It is possible to tweak the numbers based on the overall use. For
example, add 100% for arrays smaller than 1MB, 50% for 1MB - 100MB, and
20% for arrays above 100MB big. This would eliminate the performance
degradation for almost all users.
Shachar
On 23/01/17 12:44, Shachar
On 23/01/17 13:05, Markus Laker wrote:
On Monday, 23 January 2017 at 10:44:50 UTC, Shachar Shemesh wrote:
Of course, if, instead of 50% we increase by less (say, 20%), we could
reuse previously used memory even sooner.
Yes, you're right, of course: expansion of strings and other arrays is a
cl
On Monday, 23 January 2017 at 10:44:50 UTC, Shachar Shemesh wrote:
Of course, if, instead of 50% we increase by less (say, 20%),
we could reuse previously used memory even sooner.
Yes, you're right, of course: expansion of strings and other
arrays is a classic time-versus-space trade-off. How
On Saturday, 21 January 2017 at 15:55:35 UTC, Xavier Bigand wrote:
I don't see any other use case than for initialized maths
struct to an invalid state, and because it is generally in
template that working with integers and floats it is easier to
have same properties (when it have the same mean
On Monday, 23 January 2017 at 09:06:49 UTC, Nordlöw wrote:
Good job.
There are more good news
uint fn()
{
uint x = 7;
modx(&x);
return x;
}
void modx(uint* x)
{
*x = 12;
}
static assert(fn() == 12);
This code does now compile with newCTFE :)
On 23/01/17 11:15, Markus Laker wrote:
A 2GiB disk file caused tinycat.d to use over 4GiB of memory.
When extending arrays, a common approach is to double the size every
time you run out of space. This guarantees an amortized O(1) cost of append.
Unfortunately, this also guarantees that we
On Monday, 23 January 2017 at 01:55:59 UTC, Andrei Alexandrescu
wrote:
I recall reported size for special files is zero. We special
case std.file.read for those. -- Andrei
Special files are a bit of a distraction, in any case, because
it's easy to create a large disk file full of zeroes:
msl
On Monday, 23 January 2017 at 07:57:35 UTC, Stefan Koch wrote:
It was very hard to find this.
Good job.
I just fixed a bug related to the unsupported floating point.
~master phobos compiles again and runs the unit-tests.
I will probably have to spent the rest of the month with fixing
bugs that function-call support has uncovered.
Since now newCTFE sees much more code before bailing out.
I have
32 matches
Mail list logo
