OST to PST Converter
There is a fast and effective OST to PST Converter tool which can export OST file to PST file format easily, without affecting the original information. You can work on the OST to PST Converter software without any hesitation because it does not require any extra technical skill to install and run this ATS OST to PST Converter software. Get more details: http://www.bulkecommerce.com/store/ats-ost-to-pst-converter-software-159.html
Re: Feature to get or add value to an associative array.
On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:
You can get a pointer from the ref return:
Value* p = &aa.slot("key", { inserted = true; return
Value.init; });
This is not @safe, even with -dip1000:
Error: cannot take address of ref return of f() in @safe function
main
Re: Issues with debugging GC-related crashes #2
On Monday, 16 April 2018 at 16:36:48 UTC, Matthias Klumpp wrote:
#2 0x751341c8 in
_D2rt4util9container5treap__T5TreapTS2gc11gcinterface5RangeZQBf7opApplyMFNbMDFNbKQBtZiZ9__lambda2MFNbKxSQCpQCpQCfZi (e=...) at treap.d:47
dg = {context = 0x7fffc140 "\320\065\206", funcptr
= 0x75121d10
<_D2gc4impl12conservativeQw3Gcx7markAllMFNbbZ14__foreachbody3MFNbKSQCm11gcinterface5RangeZi>}
#3 0x75134238 in
_D2rt4util9container5treap__T5TreapTS2gc11gcinterface5RangeZQBf13opApplyHelperFNbxPSQDeQDeQDcQCv__TQCsTQCpZQDa4NodeMDFNbKxSQDiQDiQCyZiZi (node=0x7568700, dg=...) at treap.d:221
Indeed, this is iteration over Treap!Range used to store ranges
added with addRange method.
https://github.com/ldc-developers/druntime/blob/ldc/src/gc/impl/conservative/gc.d#L2182
Re: Feature to get or add value to an associative array.
On Wednesday, 18 April 2018 at 16:04:13 UTC, Giles Bathgate wrote:
I understand where you are coming from, but I am not sure it is
appropriate to shoehorn every use case into one api.
It is not shoehorning, the difference here is just returning by
ref vs pointer. I understand that, as the pointer address is not
needed by the caller, it is cleaner to use ref. The problem is
that local refs are not supported by D, and so I would need to do
this (at least in safe code):
import std.functional : unaryFun;
bool ins;
aa.update("key", {ins = true; return 1;}).unaryFun!((v){ if (ins)
v++; });
This seems pretty convoluted. It could be made a bit better if D
supported UFCS for lambdas, then unaryFun wouldn't be needed.
BTW, I like the name `update`.
void createOrUpdate(K, V)(ref V[K] aa, K key, V delegate()
create, void delegate(V*) update);
Again, would the delegate calls always be inlined, in all cases?
I think having a low-level API in druntime is appropriate, it's a
runtime library after all.
Re: Feature to get or add value to an associative array.
On Thursday, 19 April 2018 at 08:20:02 UTC, Giles Bathgate wrote: On Wednesday, 18 April 2018 at 21:04:53 UTC, Jordan Wilson wrote: Thinking seems sound, although having a name starting with "get" does have the advantage of being more related to the existing get. Ah yes, good point. I think now we've had the discussion about other use cases though that ultimately there might need to be an "atomic" AddOrUpdate style function too, which I was thinking could just be called 'update'. The necessity to keep them all starting with get seemed less important. How about something like "forceGet" to make clear you will get it, even if it wasn't there before.
Re: Feature to get or add value to an associative array.
On 04/20/2018 10:24 AM, Nick Treleaven wrote:
On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:
You can get a pointer from the ref return:
Value* p = &aa.slot("key", { inserted = true; return Value.init; });
This is not @safe, even with -dip1000:
Error: cannot take address of ref return of f() in @safe function main
Hm. Do you know why that's not allowed? I can't see how it would be less
safe than returning a pointer, and I can't find a mention of it in DIP
1000 [1]. Maybe it's just a case of incomplete/buggy implementation?
[1] https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
Re: Feature to get or add value to an associative array.
On Friday, April 20, 2018 10:56:37 ag0aep6g via Digitalmars-d wrote:
> On 04/20/2018 10:24 AM, Nick Treleaven wrote:
> > On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:
> >> You can get a pointer from the ref return:
> >>
> >> Value* p = &aa.slot("key", { inserted = true; return Value.init;
> >> });
> >
> > This is not @safe, even with -dip1000:
> >
> > Error: cannot take address of ref return of f() in @safe function main
>
> Hm. Do you know why that's not allowed? I can't see how it would be less
> safe than returning a pointer, and I can't find a mention of it in DIP
> 1000 [1]. Maybe it's just a case of incomplete/buggy implementation?
>
>
> [1] https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
The compiler assumes that a pointer is valid when determining whether code
is @safe. It then disallows operations that it can't guarantee are @safe
even if the pointer is valid, and it disallows taking the address in cases
where it can't guarantee that that's @safe. Basically, it verifies the
@safety of pointers when they're created and then assumes that they're @safe
after that. So, passing around a pointer is perfectly @safe, whereas taking
the address of a ref return value to get a pointer is not.
- Jonathan M Davis
Re: Feature to get or add value to an associative array.
On Friday, 20 April 2018 at 09:24:26 UTC, Jonathan M Davis wrote: The compiler assumes that a pointer is valid when determining whether code is @safe. [...] Basically, it verifies the @safety of pointers when they're created and then assumes that they're @safe after that. Can't it do the same for ref returns? Unsafe stuff like returning a ref to a local is already disallowed, just like returning a pointer to a local. So the compiler checks the safety on creation, at least in some cases. So, passing around a pointer is perfectly @safe, whereas taking the address of a ref return value to get a pointer is not. It's still not clear to me how taking the address of a ref return is necessarily less safe than using a returned pointer. Do you maybe have an example in code that shows the difference? It seems to me that refs and pointers are very much equivalent. I should always be able to turn one into the other.
Re: D vs nim
On Thu, 2018-04-19 at 16:50 +, Per Nordlöw via Digitalmars-d wrote: > On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote: > > P.S., the example on the language's frontpage is cool! > > > > http://nim-lang.org/ > > > > Why should I be excited? > > Nim is the only language that leverages automated proof > > technology to perform a disjoint check for your parallel code. > > Working on disjoint data means no locking is required and yet > > data races are impossible: > > I believe Rust's rayon [1] can do this too... > > [1] https://github.com/rayon-rs/rayon Has anyone got Pony on their list of interesting languages? -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Reddit Post: Overview of the Efficient Programming Languages (v.3)
On Thursday, 19 April 2018 at 10:34:26 UTC, Per Nordlöw wrote: On Tuesday, 17 April 2018 at 15:10:35 UTC, Nerve wrote: Overview of the Efficient Programming Languages (v.3): C++, Rust, Swift, Scala, Dlang, Kotlin, Nim, Julia, Golang, Python. http://reddit.com/r/programming/comments/8cw2xn/overview_of_the_efficient_programming_languages/ Nice overview. Thanks. Wasn't me who wrote the post, I was just linking here in the forum so people could know the post exists and could discuss it there.
May 1: Traditional Maibaumaufstellung (Maypole erection) in Munich
Hi all, to all the people who arrive a bit early in Munich. In Southern Germany Maibäume (Maypoles) are an old tradition about which people make a big fuzz. So on the May 1st in and around Munich there will be small festivities for their erection. Munich's city portal has a few pointers and a video from last year: http://www.muenchen.de/veranstaltungen/events/erster-mai.html And there are a few other sites with a more extensive list: http://www.ganz-muenchen.de/freizeitfitness/volksfeste/maibaum/1mai.html https://www.maibaum-kalender.de/uebersicht See you soon.
Re: Feature to get or add value to an associative array.
On Friday, 20 April 2018 at 08:37:59 UTC, Nick Treleaven wrote:
Again, would the delegate calls always be inlined, in all cases?
I think having a low-level API in druntime is appropriate, it's
a runtime library after all.
So the low-level API you are requesting is part of the pull
request, the low-level API is called _aaGetX, whereas the
previous API was _aaGetY, the new API adds a boolean out
parameter `found` and if you really wanted to you could do this:
-
extern (C) void* _aaGetX(void** paa, const
TypeInfo_AssociativeArray ti, in size_t valuesize, in void* pkey,
out bool found) pure nothrow;
V* slot(K, V)(ref V[K] aa, K key, out bool found)
{
return cast(V*) _aaGetX(cast(void**)&aa, typeid(V[K]),
V.sizeof, &key, found);
}
-
I am also benchmarking the `update` function I talked about
previously.
https://gist.github.com/GilesBathgate/8409b5889ebb7b1302627c50f342a28b
The results seem to indicate that there isn't much in it
performance wise.
test1 [56 ms, 377 µs, and 4 hnsecs]
test2 [56 ms, 262 µs, and 2 hnsecs]
I can't fathom why the delegates version is faster, but I am just
putting it down to luck ;)
Re: Feature to get or add value to an associative array.
On Friday, 20 April 2018 at 02:12:37 UTC, Jonathan M Davis wrote: Out of all of those, I _really_ hope that you don't go with require. It sounds like the sort of thing that you'd get in a library having to do with unit testing or contracts and gives no indication whatsoever as to what it does. Yes I know. I gave up on trying to find a single verb or runTogetherWords that would describe exactly what it does, and instead opted for something that I like, and added documentation to describe what it does. I don't think I will find a name that everybody likes. But I am open to more suggestions as its probably the easiest aspect of the PR to change.
Re: Feature to get or add value to an associative array.
On 4/20/18 4:24 AM, Nick Treleaven wrote:
On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:
You can get a pointer from the ref return:
Value* p = &aa.slot("key", { inserted = true; return Value.init; });
This is not @safe, even with -dip1000:
Error: cannot take address of ref return of f() in @safe function main
Hm... I would have expected it to work in dip1000.
Hard for me to understand what dip1000 is doing, but it seems like an
omission:
@safe ref int foo(return ref int x) { return x; }
void main() @safe
{
int x;
scope int *xp = &x; // OK with dip1000
xp = foo(x); // Error, even though it's exactly the same
}
And in this case, it doesn't even need to be scope, as it's GC data. How
does one communicate that the ref return is of GC data and can be
escaped as much as you want?
-Steve
Re: Feature to get or add value to an associative array.
On Friday, 20 April 2018 at 14:02:17 UTC, Steven Schveighoffer
wrote:
On 4/20/18 4:24 AM, Nick Treleaven wrote:
On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:
You can get a pointer from the ref return:
Value* p = &aa.slot("key", { inserted = true; return
Value.init; });
This is not @safe, even with -dip1000:
Error: cannot take address of ref return of f() in @safe
function main
Hm... I would have expected it to work in dip1000.
Hard for me to understand what dip1000 is doing, but it seems
like an omission:
@safe ref int foo(return ref int x) { return x; }
void main() @safe
{
int x;
scope int *xp = &x; // OK with dip1000
xp = foo(x); // Error, even though it's exactly the same
}
And in this case, it doesn't even need to be scope, as it's GC
data. How does one communicate that the ref return is of GC
data and can be escaped as much as you want?
-Steve
The error seems to be about type mismatching, it works if you use
auto. I don't see how you could convert the `ref int` to `int *`
https://run.dlang.io/is/eIJMIK
Re: Feature to get or add value to an associative array.
On 4/20/18 10:34 AM, Uknown wrote:
On Friday, 20 April 2018 at 14:02:17 UTC, Steven Schveighoffer wrote:
On 4/20/18 4:24 AM, Nick Treleaven wrote:
On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:
You can get a pointer from the ref return:
Value* p = &aa.slot("key", { inserted = true; return Value.init;
});
This is not @safe, even with -dip1000:
Error: cannot take address of ref return of f() in @safe function main
Hm... I would have expected it to work in dip1000.
Hard for me to understand what dip1000 is doing, but it seems like an
omission:
@safe ref int foo(return ref int x) { return x; }
void main() @safe
{
int x;
scope int *xp = &x; // OK with dip1000
xp = foo(x); // Error, even though it's exactly the same
}
And in this case, it doesn't even need to be scope, as it's GC data.
How does one communicate that the ref return is of GC data and can be
escaped as much as you want?
The error seems to be about type mismatching, it works if you use auto.
I don't see how you could convert the `ref int` to `int *`
https://run.dlang.io/is/eIJMIK
Sorry, it was a typo. In my real code I have:
xp = &(foo(x));
That's what I get for hand-typing instead of copy-pasting :)
-Steve
Re: Feature to get or add value to an associative array.
On Friday, 20 April 2018 at 15:00:39 UTC, Steven Schveighoffer wrote: On 4/20/18 10:34 AM, Uknown wrote: On Friday, 20 April 2018 at 14:02:17 UTC, Steven Schveighoffer wrote: On 4/20/18 4:24 AM, Nick Treleaven wrote: On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote: [...] Sorry, it was a typo. In my real code I have: xp = &(foo(x)); That's what I get for hand-typing instead of copy-pasting :) -Steve It seems like a bug. Changing foo to take and return an `int *` works as expected https://run.dlang.io/is/3NYXYv
Re: #dbugfix Issue 16486 200$
On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote: [snip] They are used in mir-lapack [5]. The bug fix also required for mir (Sparse, CompressedTensor), and for the future Dlang image library. I was experimenting with one of the open methods matrix examples [1] and trying to replace the virtual methods with templates. My example [3] does it statically and with structs so that it could be used with mir. However, the moment you try to make it a little bit more complicated and allow the type of the underlying matrix data to be templated, then it hits up against this issue and you can't rely on aliases any more. I would support a DIP. [1] https://github.com/jll63/openmethods.d/tree/master/examples/matrix/source [2] http://www.di.unipi.it/~nids/docs/templates_vs_inheritance.html [3] https://run.dlang.io/gist/9da210e321af95e1ce373b5a6621e4f8
Re: #dbugfix Issue 16486 200$
On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote: [snip] They are used in mir-lapack [5]. The bug fix also required for mir (Sparse, CompressedTensor), and for the future Dlang image library. I was experimenting with one of the open methods matrix examples [1] and trying to replace the virtual methods with templates. My example [3] does it statically and with structs so that it could be used with mir. However, the moment you try to make it a little bit more complicated and allow the type of the underlying matrix data to be templated, then it hits up against this issue and you can't rely on aliases any more. I would support a DIP. [1] https://github.com/jll63/openmethods.d/tree/master/examples/matrix/source [2] http://www.di.unipi.it/~nids/docs/templates_vs_inheritance.html [3] https://run.dlang.io/gist/9da210e321af95e1ce373b5a6621e4f8
Re: #dbugfix Issue 16486 200$
On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote: [snip] They are used in mir-lapack [5]. The bug fix also required for mir (Sparse, CompressedTensor), and for the future Dlang image library. I was experimenting with one of the open methods matrix examples [1] and trying to replace the virtual methods with templates. My example [3] does it statically and with structs so that it could be used with mir. However, the moment you try to make it a little bit more complicated and allow the type of the underlying matrix data to be templated, then it hits up against this issue and you can't rely on aliases any more. I would support a DIP. [1] https://github.com/jll63/openmethods.d/tree/master/examples/matrix/source [2] http://www.di.unipi.it/~nids/docs/templates_vs_inheritance.html [3] https://run.dlang.io/gist/9da210e321af95e1ce373b5a6621e4f8
Re: #dbugfix Issue 16486 200$
On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote: [snip] They are used in mir-lapack [5]. The bug fix also required for mir (Sparse, CompressedTensor), and for the future Dlang image library. I was experimenting with one of the open methods matrix examples [1] and trying to replace the virtual methods with templates. My example [3] does it statically and with structs so that it could be used with mir. However, the moment you try to make it a little bit more complicated and allow the type of the underlying matrix data to be templated, then it hits up against this issue and you can't rely on aliases any more. I would support a DIP. [1] https://github.com/jll63/openmethods.d/tree/master/examples/matrix/source [2] http://www.di.unipi.it/~nids/docs/templates_vs_inheritance.html [3] https://run.dlang.io/gist/9da210e321af95e1ce373b5a6621e4f8
Re: #dbugfix Issue 16486 200$
On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote: [snip] They are used in mir-lapack [5]. The bug fix also required for mir (Sparse, CompressedTensor), and for the future Dlang image library. I was experimenting with one of the open methods matrix examples [1] and trying to replace the virtual methods with templates. My example [3] does it statically and with structs so that it could be used with mir. However, the moment you try to make it a little bit more complicated and allow the type of the underlying matrix data to be templated, then it hits up against this issue and you can't rely on aliases any more. I would support a DIP. [1] https://github.com/jll63/openmethods.d/tree/master/examples/matrix/source [2] http://www.di.unipi.it/~nids/docs/templates_vs_inheritance.html [3] https://run.dlang.io/gist/9da210e321af95e1ce373b5a6621e4f8
Re: #dbugfix Issue 16486 200$
On Friday, 20 April 2018 at 16:03:40 UTC, jmh530 wrote: On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote: [...] I was experimenting with one of the open methods matrix examples [1] and trying to replace the virtual methods with templates. My example [3] does it statically and with structs so that it could be used with mir. However, the moment you try to make it a little bit more complicated and allow the type of the underlying matrix data to be templated, then it hits up against this issue and you can't rely on aliases any more. I would support a DIP. [1] https://github.com/jll63/openmethods.d/tree/master/examples/matrix/source [2] http://www.di.unipi.it/~nids/docs/templates_vs_inheritance.html [3] https://run.dlang.io/gist/9da210e321af95e1ce373b5a6621e4f8 Sorry, the stupid thing keeps telling me it's down for maintenance.
OT - Replacing strings with slices in C# - high performance improvement
.NET Core 2.1 was announced, with emphasis on using Span instead of classic String class all around the framework. For people not familiar with C#, Span is similar to a D array slice. https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/
Re: isInputRange is false for non-copyable types
foreach(ref e; range)
{
}
On idea is to have `ref` foreach to say that you would like to
iterate your range without copying. The syntax could be:
foreach(e; ref range)
{
}
or:
ref foreach(e; range)
{
}
At least it will not break existing code. But this means that in
each case you should make a decision about `ref`/non ref.
Re: Issues with debugging GC-related crashes #2
On Friday, 20 April 2018 at 05:32:32 UTC, Dmitry Olshansky wrote: On Friday, 20 April 2018 at 00:11:25 UTC, Matthias Klumpp wrote: On Thursday, 19 April 2018 at 18:45:41 UTC, kinke wrote: [...] Jup, I did that already, it just took a really long time to run because when I made the change to print errno I also enabled detailed GC profiling (via the PRINTF* debug options). Enabling the INVARIANT option for the GC is completely broken by the way, I enforced the compile to work by casting to shared, with the result of the GC locking up forever at the start of the program. [...] I think the order of operations is wrong, here is an example from containers: allocator.dispose(buckets); static if (useGC) GC.removeRange(buckets.ptr); If GC triggers between dispose and removeRange, it will likely segfault. Indeed! It's also the only place where this is shuffled around, all other parts of the containers library do this properly. The thing I wonder about is though, that the crash usually appeared in an explicit GC.collect() call when the application was not running multiple threads. At that point, the GC - as far as I know - couldn't have triggered after the buckets were disposed of and the ranges were removed. But maybe I am wrong with that assumption. This crash would be explained perfectly by that bug.
Re: Issues with debugging GC-related crashes #2
On Friday, 20 April 2018 at 18:30:30 UTC, Matthias Klumpp wrote: On Friday, 20 April 2018 at 05:32:32 UTC, Dmitry Olshansky wrote: On Friday, 20 April 2018 at 00:11:25 UTC, Matthias Klumpp wrote: On Thursday, 19 April 2018 at 18:45:41 UTC, kinke wrote: [...] [...] I think the order of operations is wrong, here is an example from containers: allocator.dispose(buckets); static if (useGC) GC.removeRange(buckets.ptr); If GC triggers between dispose and removeRange, it will likely segfault. Indeed! It's also the only place where this is shuffled around, all other parts of the containers library do this properly. The thing I wonder about is though, that the crash usually appeared in an explicit GC.collect() call when the application was not running multiple threads. At that point, the GC - as far as I know - couldn't have triggered after the buckets were disposed of and the ranges were removed. But maybe I am wrong with that assumption. This crash would be explained perfectly by that bug. Turns out that was indeed the case! I created a small testcase which managed to very reliably reproduce the issue on all machines that I tested it on. After reordering the dispose/removeRange, the crashes went away completely. I submitted a pull request to the containers library to fix this issue: https://github.com/dlang-community/containers/pull/107 I will also try to get the patch into the components in Debian and Ubuntu, so we can maybe have a chance of updating the software center metadata for Ubuntu before 18.04 LTS releases next week. Since asgen uses HashMaps for pretty much everything, an most of the time with GC-managed elements, this should improve the stability of the application greatly. Thanks a lot for the help in debugging this, I learned a lot about DRuntime internals in the process. Also, it is no exaggeration to say that the appstream-generator project would not be written in D (there was a Rust prototype once...) and I would probably not be using D as much (or at all) without the helpful community around it. Thank you :-)
Re: D vs nim
On Friday, 20 April 2018 at 11:07:30 UTC, Russel Winder wrote: On Thu, 2018-04-19 at 16:50 +, Per Nordlöw via Digitalmars-d wrote: On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote: > P.S., the example on the language's frontpage is cool! > > http://nim-lang.org/ > > Why should I be excited? > Nim is the only language that leverages automated proof > technology to perform a disjoint check for your parallel > code. > Working on disjoint data means no locking is required and yet > data races are impossible: I believe Rust's rayon [1] can do this too... [1] https://github.com/rayon-rs/rayon Has anyone got Pony on their list of interesting languages? Yep, I have. To bad about no curly braces, though.
Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.
On 4/17/18 4:49 PM, Steven Schveighoffer wrote:
On 4/17/18 12:18 PM, Nick Treleaven wrote:
Thanks for making this pull, I've thought about solving this before. I
think the function needs to provide a way to tell if the value was
already present.
Not as straightforward, but it can be done:
bool inserted = false;
auto p = aa.getOrAdd("key", {inserted = true; return new Person; });
Let me say I was surprised that this doesn't actually work. An in-line
lambda will NOT work as a lazy parameter, even though that's EXACTLY
what a lazy parameter is implemented as! And variadic lazy parameters
are explicitly typed this way.
Has that ever worked? I could have sworn it did...
-Steve
Re: D vs nim
On Friday, 20 April 2018 at 11:07:30 UTC, Russel Winder wrote: Has anyone got Pony on their list of interesting languages? I had spent some time looking over the reference capabilities [1], but I'm not sure I have the time to actually program in the language. The isolated type seemed like the most interesting take-away. I think someone on the D forums had been trying to get something similar. [1] https://tutorial.ponylang.org/capabilities/reference-capabilities.html
Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.
On Friday, April 20, 2018 16:35:43 Steven Schveighoffer via Digitalmars-d
wrote:
> On 4/17/18 4:49 PM, Steven Schveighoffer wrote:
> > On 4/17/18 12:18 PM, Nick Treleaven wrote:
> >> Thanks for making this pull, I've thought about solving this before. I
> >> think the function needs to provide a way to tell if the value was
> >> already present.
> >
> > Not as straightforward, but it can be done:
> >
> > bool inserted = false;
> > auto p = aa.getOrAdd("key", {inserted = true; return new Person; });
>
> Let me say I was surprised that this doesn't actually work. An in-line
> lambda will NOT work as a lazy parameter, even though that's EXACTLY
> what a lazy parameter is implemented as! And variadic lazy parameters
> are explicitly typed this way.
>
> Has that ever worked? I could have sworn it did...
I'm not sure. I mucked around with lazy like this when I was originally
working on stuff like assertThrown and assertPred 7 or 8 years ago, but I've
done _very_ little with lazy since then. My gut reaction is that it worked,
but it might not have. If you add parens after it so that you call it, it
does work, since then the result is the correct type. And if you ignore the
exact details of how lazy is implemented and consider that it's supposed to
take an expression that evaluates to a specific type, a lambda doesn't match
that unless it's called. So, it does make sense from that perspective and is
likely why it works the way it does. The compiler would basically have to
special-case delegates to accept stuff like lambdas when the type of the
lazy parameter is not a delegate. And if it _did_ special-case it, then
things might get interesting if you actually had a lazy parameter that was a
delegate. So, I don't know if it should work or not, but the workaround is
pretty simple - just add parens to call it.
- Jonathan M Davis
Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.
On Friday, 20 April 2018 at 20:35:43 UTC, Steven Schveighoffer wrote: Let me say I was surprised that this doesn't actually work. An in-line lambda will NOT work as a lazy parameter, even though that's EXACTLY what a lazy parameter is implemented as! And variadic lazy parameters are explicitly typed this way. I kind of expected it to work too. However, I just created a template to allow this to work with my PR. https://github.com/dlang/druntime/pull/2162/files#diff-a68e58fcf0de5aa198fcaceafe4e8cf9R2344 Getting it right took a few head-scratchers, but I put that down to my lack of experience with D ;)
Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.
On Friday, April 20, 2018 22:03:04 Giles Bathgate via Digitalmars-d wrote: > On Friday, 20 April 2018 at 20:35:43 UTC, Steven Schveighoffer > > wrote: > > Let me say I was surprised that this doesn't actually work. An > > in-line lambda will NOT work as a lazy parameter, even though > > that's EXACTLY what a lazy parameter is implemented as! And > > variadic lazy parameters are explicitly typed this way. > > I kind of expected it to work too. However, I just created a > template to allow this to work with my PR. > > https://github.com/dlang/druntime/pull/2162/files#diff-a68e58fcf0de5aa198f > caceafe4e8cf9R2344 > > Getting it right took a few head-scratchers, but I put that down > to my lack of experience with D ;) Honestly, I think that it's a terrible idea to special-case it like that. If we want to argue for making it work in the language, that's fine, but if we special-case it like this, then it will work with some functions that have lazy parameters and not others, and the result will be confusing. Besides, all it takes to be able to pass a lamdba or delegate to a lazy parameter is to actually call it when passing it. So, if you add parens after the braces, it works. There's no need to go and add a special case for it to the function. - Jonathan M Davis
Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.
On Friday, 20 April 2018 at 22:21:13 UTC, Jonathan M Davis wrote:
Honestly, I think that it's a terrible idea to special-case it
like that. If we want to argue for making it work in the
language, that's fine, but if we special-case it like this,
then it will work with some functions that have lazy parameters
and not others, and the result will be confusing. Besides, all
it takes to be able to pass a lamdba or delegate to a lazy
parameter is to actually call it when passing it. So, if you
add parens after the braces, it works. There's no need to go
and add a special case for it to the function.
Again lack of experience, so I presume you can just do:
bool inserted = false;
auto p = aa.getOrAdd("key", {inserted = true; return new Person;
}());
I hadn't realised that until now. I enjoy your brutal honesty by
the way ;)
Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.
On Friday, April 20, 2018 22:46:54 Giles Bathgate via Digitalmars-d wrote:
> On Friday, 20 April 2018 at 22:21:13 UTC, Jonathan M Davis wrote:
> > Honestly, I think that it's a terrible idea to special-case it
> > like that. If we want to argue for making it work in the
> > language, that's fine, but if we special-case it like this,
> > then it will work with some functions that have lazy parameters
> > and not others, and the result will be confusing. Besides, all
> > it takes to be able to pass a lamdba or delegate to a lazy
> > parameter is to actually call it when passing it. So, if you
> > add parens after the braces, it works. There's no need to go
> > and add a special case for it to the function.
>
> Again lack of experience, so I presume you can just do:
>
> bool inserted = false;
> auto p = aa.getOrAdd("key", {inserted = true; return new Person;
> }());
>
> I hadn't realised that until now. I enjoy your brutal honesty by
> the way ;)
Yes. That should work. e.g. this
import std.stdio;
void foo(lazy string l)
{
}
void main()
{
foo({writeln("foo"); return "str";}());
}
compiles and runs just fine without printing anything, whereas you get a
compilation error if you don't have the parens after the closing brace.
- Jonathan M Davis
Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.
On Friday, 20 April 2018 at 23:13:58 UTC, Jonathan M Davis wrote:
Yes. That should work. e.g. this
import std.stdio;
void foo(lazy string l)
{
}
void main()
{
foo({writeln("foo"); return "str";}());
}
compiles and runs just fine without printing anything, whereas
you get a compilation error if you don't have the parens after
the closing brace.
Ok cool. I've updated the PR since basically, I agree with your
points about it being confusing to cater for the special case.
Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.
On 4/20/18 6:46 PM, Giles Bathgate wrote:
On Friday, 20 April 2018 at 22:21:13 UTC, Jonathan M Davis wrote:
Honestly, I think that it's a terrible idea to special-case it like
that. If we want to argue for making it work in the language, that's
fine, but if we special-case it like this, then it will work with some
functions that have lazy parameters and not others, and the result
will be confusing. Besides, all it takes to be able to pass a lamdba
or delegate to a lazy parameter is to actually call it when passing
it. So, if you add parens after the braces, it works. There's no need
to go and add a special case for it to the function.
Again lack of experience, so I presume you can just do:
bool inserted = false;
auto p = aa.getOrAdd("key", {inserted = true; return new Person; }());
I hadn't realised that until now. I enjoy your brutal honesty by the way ;)
The drawback here, of course, is that it's a lambda calling a lambda (if
you end up using the value).
But of course, your overload was the same thing.
I'm just surprised it doesn't work, especially when this works:
// lazy variadic
void foo(int delegate()[] dgs...)
{
dgs[0]();
}
foo(1); // ok, same as { return 1; }
foo({inserted = true; return 1;}); // ok
Of course, it's not as nice syntax inside the function.
-Steve
Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.
On 4/20/18 5:40 PM, Jonathan M Davis wrote:
On Friday, April 20, 2018 16:35:43 Steven Schveighoffer via Digitalmars-d
wrote:
On 4/17/18 4:49 PM, Steven Schveighoffer wrote:
On 4/17/18 12:18 PM, Nick Treleaven wrote:
Thanks for making this pull, I've thought about solving this before. I
think the function needs to provide a way to tell if the value was
already present.
Not as straightforward, but it can be done:
bool inserted = false;
auto p = aa.getOrAdd("key", {inserted = true; return new Person; });
Let me say I was surprised that this doesn't actually work. An in-line
lambda will NOT work as a lazy parameter, even though that's EXACTLY
what a lazy parameter is implemented as! And variadic lazy parameters
are explicitly typed this way.
Has that ever worked? I could have sworn it did...
I'm not sure. I mucked around with lazy like this when I was originally
working on stuff like assertThrown and assertPred 7 or 8 years ago, but I've
done _very_ little with lazy since then. My gut reaction is that it worked,
but it might not have. If you add parens after it so that you call it, it
does work, since then the result is the correct type. And if you ignore the
exact details of how lazy is implemented and consider that it's supposed to
take an expression that evaluates to a specific type, a lambda doesn't match
that unless it's called. So, it does make sense from that perspective and is
likely why it works the way it does.
But, it *is* a delegate. literally, that's what gets implemented (and it
has to be that way). I suppose if it's inlined, the compiler could take
some leeway, but that is the same with a delegate literal passed to a
function that takes a delegate anyway.
The fact that lazy variadics are explicitly delegates makes this even
more annoying. I wish we could have the best of both worlds (non-ugly
calls inside the function, and easy binding to whatever you want at the
call side). I'm not even sure why lazy variadics are the way they are, I
can instantly think of a better syntax for them.
The compiler would basically have to
special-case delegates to accept stuff like lambdas when the type of the
lazy parameter is not a delegate. And if it _did_ special-case it, then
things might get interesting if you actually had a lazy parameter that was a
delegate.
This is pretty easy, does your delegate return a delegate or an int? ;)
This is a super-solvable problem, I'm just surprised it wasn't this way
before, I could have sworn I've done this in the past.
So, I don't know if it should work or not, but the workaround is
pretty simple - just add parens to call it.
This results in a double delegate call -- the compiler makes a delegate
that calls your delegate. Not optimal, but yes it does work.
-Steve
Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.
On 4/20/18 7:21 PM, Giles Bathgate wrote:
On Friday, 20 April 2018 at 23:13:58 UTC, Jonathan M Davis wrote:
Yes. That should work. e.g. this
import std.stdio;
void foo(lazy string l)
{
}
void main()
{
foo({writeln("foo"); return "str";}());
}
compiles and runs just fine without printing anything, whereas you get
a compilation error if you don't have the parens after the closing brace.
Ok cool. I've updated the PR since basically, I agree with your points
about it being confusing to cater for the special case.
Yeah, I didn't mean for the special case to happen -- I thought it just
worked!
I should have tested my original code... Sorry.
-Steve
Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.
On Friday, April 20, 2018 19:27:20 Steven Schveighoffer via Digitalmars-d
wrote:
> On 4/20/18 6:46 PM, Giles Bathgate wrote:
> > On Friday, 20 April 2018 at 22:21:13 UTC, Jonathan M Davis wrote:
> >> Honestly, I think that it's a terrible idea to special-case it like
> >> that. If we want to argue for making it work in the language, that's
> >> fine, but if we special-case it like this, then it will work with some
> >> functions that have lazy parameters and not others, and the result
> >> will be confusing. Besides, all it takes to be able to pass a lamdba
> >> or delegate to a lazy parameter is to actually call it when passing
> >> it. So, if you add parens after the braces, it works. There's no need
> >> to go and add a special case for it to the function.
> >
> > Again lack of experience, so I presume you can just do:
> >
> > bool inserted = false;
> > auto p = aa.getOrAdd("key", {inserted = true; return new Person; }());
> >
> > I hadn't realised that until now. I enjoy your brutal honesty by the way
> > ;)
> The drawback here, of course, is that it's a lambda calling a lambda (if
> you end up using the value).
>
> But of course, your overload was the same thing.
>
> I'm just surprised it doesn't work, especially when this works:
>
> // lazy variadic
> void foo(int delegate()[] dgs...)
> {
> dgs[0]();
> }
>
> foo(1); // ok, same as { return 1; }
> foo({inserted = true; return 1;}); // ok
>
> Of course, it's not as nice syntax inside the function.
Honestly, I would have considered it a bug that it accepts 1, since that's
not a delegate or lambda or anything of the sort, and the function is
explicitly typed to take delegates.
- Jonathan M Davis
Re: Why don't lazy parameters bind to delegates? Was: Feature to get or add value to an associative array.
On Friday, April 20, 2018 19:36:57 Steven Schveighoffer via Digitalmars-d
wrote:
> On 4/20/18 5:40 PM, Jonathan M Davis wrote:
> > On Friday, April 20, 2018 16:35:43 Steven Schveighoffer via
> > Digitalmars-d
> >
> > wrote:
> >> On 4/17/18 4:49 PM, Steven Schveighoffer wrote:
> >>> On 4/17/18 12:18 PM, Nick Treleaven wrote:
> Thanks for making this pull, I've thought about solving this before.
> I
> think the function needs to provide a way to tell if the value was
> already present.
> >>>
> >>> Not as straightforward, but it can be done:
> >>>
> >>> bool inserted = false;
> >>> auto p = aa.getOrAdd("key", {inserted = true; return new Person; });
> >>
> >> Let me say I was surprised that this doesn't actually work. An in-line
> >> lambda will NOT work as a lazy parameter, even though that's EXACTLY
> >> what a lazy parameter is implemented as! And variadic lazy parameters
> >> are explicitly typed this way.
> >>
> >> Has that ever worked? I could have sworn it did...
> >
> > I'm not sure. I mucked around with lazy like this when I was originally
> > working on stuff like assertThrown and assertPred 7 or 8 years ago, but
> > I've done _very_ little with lazy since then. My gut reaction is that
> > it worked, but it might not have. If you add parens after it so that
> > you call it, it does work, since then the result is the correct type.
> > And if you ignore the exact details of how lazy is implemented and
> > consider that it's supposed to take an expression that evaluates to a
> > specific type, a lambda doesn't match that unless it's called. So, it
> > does make sense from that perspective and is likely why it works the
> > way it does.
>
> But, it *is* a delegate. literally, that's what gets implemented (and it
> has to be that way). I suppose if it's inlined, the compiler could take
> some leeway, but that is the same with a delegate literal passed to a
> function that takes a delegate anyway.
If we want to make the compiler accept it, then I'm not necessarily against
it, but arguably, the fact that it uses a delegate is an implementation
detail. In principle, what you're doing with a lazy parameter is just saying
that the expression being passed to it isn't immediately evaluated. Having
it then accept expressions that don't result in the type of the lazy
parameter is then pretty weird.
> The fact that lazy variadics are explicitly delegates makes this even
> more annoying. I wish we could have the best of both worlds (non-ugly
> calls inside the function, and easy binding to whatever you want at the
> call side). I'm not even sure why lazy variadics are the way they are, I
> can instantly think of a better syntax for them.
Well, this thread is the first that I've heard of "lazy variadics." Until I
saw your other post about them, I assumed that you meant something like
auto foo(Args...)(lazy Args args)
{
...
}
I would haven't have assumed that
void foo(int delegate()[] dgs...)
{
dgs[0]();
}
had anything to do with lazy, and the fact that it works with anything that
doesn't implictly convert to a delegate seems like a bug to me, especially
when
void foo(int delegate() dg)
{
dg();
}
doesn't compile when it's passed an int. IMHO, they should be consistent.
> > The compiler would basically have to
> > special-case delegates to accept stuff like lambdas when the type of the
> > lazy parameter is not a delegate. And if it _did_ special-case it, then
> > things might get interesting if you actually had a lazy parameter that
> > was a delegate.
>
> This is pretty easy, does your delegate return a delegate or an int? ;)
>
> This is a super-solvable problem, I'm just surprised it wasn't this way
> before, I could have sworn I've done this in the past.
Of course it's solvable, but that doesn't mean that it's ultimately a good
idea. It does have corner cases that may or may not be a problem. e.g.
something like
void foo(lazy int delegate() dg)
{
}
could be a problem if
void foo(lazy int i)
{
}
accepts delegates whose result is an int. I'm not necessarily against making
it possible, but I would consider the fact that lazy is implemented via a
delegate to be an implementation detail of lazy, and if lazy parameters
started accepting lambdas whose result was the right type, then that means
that
auto foo(string str) {...}
and
auto foo(lazy string str) {...}
would accept different arguments even though their parameters are the same
type, and I question that that's a good idea. I'm sure that it would work on
some level, and the corner cases probably wouldn't matter often, but it
seems much cleaner to me if lazy has no effect on what is accepted and just
has an effect on whether that code is run immediately.
> > So, I don't know if it should work or not, but the workaround is
> > pretty simple - just add parens to call it.
>
> This results in a double delegate call -- the compiler makes a delegate
> that calls your delegate. Not optimal, but yes it does work.
Sure, it
Re: OT - Replacing strings with slices in C# - high performance improvement
On Friday, 20 April 2018 at 16:33:44 UTC, rumbu wrote: .NET Core 2.1 was announced, with emphasis on using Span instead of classic String class all around the framework. For people not familiar with C#, Span is similar to a D array slice. https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/ And we’re trying to move towards a string library type and away from raw slices :)
Enstella Exchange EDB to PST Recovery Software to Recover Exchange EDB to PST
Follow uncomplicated step of Enstella Exchange EDB to PST Recovery Software that helps to fix all Exchange EDB errors which generate by mistake like as: - unavailability of internet, jet engine errors, dirty shutdown errors etc and you can recover Exchange EDB mails to PST/EML/MSG and other format including with all attachment/ properties/ journal/ calendar/ junk mails/ emails information and videos etc. This application also gives the possibility to extract selective Emails from Exchange Mailboxes by filtering to dates “from date” to “to date” as well you can made separate folder at required location for save recovered data . When you recovered EDB Database File into PST that time you can choose split PST option to divide large PST File into small PST File up to 5 GB. Get more features information about this software so visit here :- http://convertedbtopstfreeware.blogspot.in/ Download Free Demo version :- http://www.enstella.com/dl/dlsoft.php?id=1
