Re: Zip vs Enumerate
On Wednesday, 20 June 2018 at 03:44:58 UTC, Jordan Wilson wrote: Is there anything I can do to improve zip, before I go ahead and change to the faster but slightly less readable enumerate? The problem might be that zip checks both arrays for empty during each step, enumerate only the first one. Try appending takeExactly(1000) on the result of zip. It might be even faster than enumerate.
Re: Zip vs Enumerate
On Wednesday, 20 June 2018 at 04:40:42 UTC, Cym13 wrote: On Wednesday, 20 June 2018 at 03:44:58 UTC, Jordan Wilson wrote: [...] This sounds like a very limited case: if you're not zipping against a iota(foo) then there's no comparing with enumerate, they simply don't do the same thing at all, and if you are then it sounds like enumerate expresses the purpose of using an index way better than a zipped iota IMHO. Is there anything about your true use case that would be worth mentionning to better understand your situation? My bad, I didn't read your example thoroughly enough.
Re: Zip vs Enumerate
On Wednesday, 20 June 2018 at 03:44:58 UTC, Jordan Wilson wrote:
Hello,
Idiomatically, I make use of zip, however, when looking to
speed up my program, notice that using enumerate leads to a
20-30% improvement:
void main(){
auto x = iota(1_000).array;
auto y = iota(1_000).array;
auto func1() {
return zip(x,y).map!(a => a[0]+a[1])
.array;
}
auto func2() {
return x.enumerate
.map!(a => a.value + y[a.index])
.array;
}
assert(func1.equal(func2));
import std.datetime.stopwatch;
auto r = benchmark!(func1, func2)(10_000);
// r[0] approx 1794 ms
// r[1] approx 1295 ms
}
Is there anything I can do to improve zip, before I go ahead
and change to the faster but slightly less readable enumerate?
In my particular case, all ranges that I zip are of the same
length, but not sure how I can leverage that information.
Thanks,
Jordan
This sounds like a very limited case: if you're not zipping
against a iota(foo) then there's no comparing with enumerate,
they simply don't do the same thing at all, and if you are then
it sounds like enumerate expresses the purpose of using an index
way better than a zipped iota IMHO.
Is there anything about your true use case that would be worth
mentionning to better understand your situation?
Zip vs Enumerate
Hello,
Idiomatically, I make use of zip, however, when looking to speed
up my program, notice that using enumerate leads to a 20-30%
improvement:
void main(){
auto x = iota(1_000).array;
auto y = iota(1_000).array;
auto func1() {
return zip(x,y).map!(a => a[0]+a[1])
.array;
}
auto func2() {
return x.enumerate
.map!(a => a.value + y[a.index])
.array;
}
assert(func1.equal(func2));
import std.datetime.stopwatch;
auto r = benchmark!(func1, func2)(10_000);
// r[0] approx 1794 ms
// r[1] approx 1295 ms
}
Is there anything I can do to improve zip, before I go ahead and
change to the faster but slightly less readable enumerate? In my
particular case, all ranges that I zip are of the same length,
but not sure how I can leverage that information.
Thanks,
Jordan
Re: I can share non shared things?
On 6/19/18 4:09 PM, gdelazzari wrote: So, let's say I have this code https://run.dlang.io/is/CaMJjd It doesn't compile, and that makes sense since myNotSharedObject is... not shared. So I can fix it by making the class shared and making a shared instance of it, like this https://run.dlang.io/is/hoMFD1 And that's how shared is supposed to work, right? Cool, I like it. But then I try this and... it compiles and runs? https://run.dlang.io/is/mNQsH1 Or, even worse, even this compiles and runs https://run.dlang.io/is/oyzHcw So, if I can share non-shared variables/objects/whatever, then what's the point of shared? Using Thread directly like that, you can override shared when passing data around. It's because natively, pthreads (or whatever threading system) doesn't care about shared, so it's on you to make sure you use it correctly. Note that before TDPL, shared was this "new undefined" concept, even in D2, and Thread existed in D1 where there was no shared concept. If you want full shared guards, use std.concurrency only. -Steve
I can share non shared things?
So, let's say I have this code https://run.dlang.io/is/CaMJjd It doesn't compile, and that makes sense since myNotSharedObject is... not shared. So I can fix it by making the class shared and making a shared instance of it, like this https://run.dlang.io/is/hoMFD1 And that's how shared is supposed to work, right? Cool, I like it. But then I try this and... it compiles and runs? https://run.dlang.io/is/mNQsH1 Or, even worse, even this compiles and runs https://run.dlang.io/is/oyzHcw So, if I can share non-shared variables/objects/whatever, then what's the point of shared?
Re: What is the point of nothrow?
On Tuesday, 19 June 2018 at 12:26:15 UTC, Kagamin wrote: On Friday, 15 June 2018 at 17:46:02 UTC, wjoe wrote: D allows various levels of performance and safety. Though I'd say Errors not working in debug mode is not intended, the Intention matters not. By definition all program state is invalid at the point an Error was thrown. From there on it is impossible to rely on any output, too, because it could be either correct, corrupted, or completely invalid. The program is in invalid state when it hits a bug before Error is thrown, this is seen as a property of a buggy algorithm, Error is thrown only as a diagnostic of a bug that has happened already. The state is invalid in a sense that the program shouldn't continue to serve its intended purpose. Even if Error was technically correctly unwound, it won't necessarily provide a correct cleanup when algorithm doesn't expect an exception. Though in case of D situation may be not as clear as there is safe code, but we just recently had a nasty memory corruption bug caused by incorrect trusted code. I wrote that 4 days ago. I lost some sleep over that matter and am long past the idea of trying to correctly clean up in this situation. You would know that had you read my more recent posts. A core dump is created by the OS. In a format that a native debugger understands. Most of the time a stack trace is enough to diagnose the error I'll say it again. The program must have a console(like) device attached. Otherwise you will not have a stack trace - or at least it needs to be redirected to a file but that's not very newbie friendly either because each shell has their own way of doing it and csh, for example, can't even redirect individually. I'm not sure about Windows. Even if possible, considering the heavy focus on GUI, I doubt it's considered best practices there and is a PITA for sure. But maybe I missed something else and the only purpose of D is to make console applications for *NIX like OSs and expect users to be professional enough to save that stack trace before they close the terminal ? And how can you be sure that this bug didn't corrupt memory of the druntime or anything else related to the stack trace, or even that it is a single bug ? And how useful is a stack trace that shows a back trace to the point of the location the Error was thrown compared to a back trace to the location of the bug (report)? and provides a better UX than a core dump (especially to Please explain. A core dump has everything a printed stack trace has and more and is as easy as using the debugger itself. newbies). I saw gdb crash trying to make sense of a debugged program too. Runtime allows to override failure handlers, but it's not centralized. And what guarantee is there that the runtime doesn't crash trying to print a stack trace ? Could happen just as likely.
Re: What is the point of nothrow?
On Friday, 15 June 2018 at 17:46:02 UTC, wjoe wrote: D allows various levels of performance and safety. Though I'd say Errors not working in debug mode is not intended, the Intention matters not. By definition all program state is invalid at the point an Error was thrown. From there on it is impossible to rely on any output, too, because it could be either correct, corrupted, or completely invalid. The program is in invalid state when it hits a bug before Error is thrown, this is seen as a property of a buggy algorithm, Error is thrown only as a diagnostic of a bug that has happened already. The state is invalid in a sense that the program shouldn't continue to serve its intended purpose. Even if Error was technically correctly unwound, it won't necessarily provide a correct cleanup when algorithm doesn't expect an exception. Though in case of D situation may be not as clear as there is safe code, but we just recently had a nasty memory corruption bug caused by incorrect trusted code. A core dump is created by the OS. In a format that a native debugger understands. Most of the time a stack trace is enough to diagnose the error and provides a better UX than a core dump (especially to newbies). I saw gdb crash trying to make sense of a debugged program too. Runtime allows to override failure handlers, but it's not centralized.
Re: Orange check failling all of a sudden
On 2018-06-11 20:00, DigitalDesigns wrote:
Changed some things in my app but unrelated to serialization and now my
app fails when trying to read the xml that was generated at the output
of the previous run.
Where it is failing is here:
void checkSpace(ref string s) @safe pure // rule 3
{
import std.algorithm.searching : countUntil;
import std.ascii : isWhite;
import std.utf : byCodeUnit;
mixin Check!("Whitespace");
ptrdiff_t i = s.byCodeUnit.countUntil!(a => !isWhite(a));
if (i == -1 && s.length > 0 && isWhite(s[0]))
s = s[$ .. $];
else if (i > -1)
s = s[i .. $];
if (s is old) fail();
}
s =
="1.0" encoding="UTF-8"?>
Actual xml data(first 3 lines):
It seems odd that it should fail when munching whitespace. It seems that
the checker is getting off to a bad start from the get go.
-[orange.xml.PhobosXml.CheckException]0x03135880
{err=0x, tail="="1.0" encoding="UTF-8"?>
orange.xml.PhobosXml.CheckException
+orange.xml.PhobosXml.XMLException0x03135880 {}
orange.xml.PhobosXml.XMLException
err0xorange.xml.PhobosXml.CheckException
+tail"="1.0" encoding="UTF-8"?>
...const(char)[]
+msg"Whitespace"const(char)[]
line0uint
column0uint
This was all working fine before and I'm not sure how it broke. The
xmllint shows the xml is well formed so this is buggy code.
Note that if I also remove all the xml inside data then the same error
occurs, so this is my xml:
that still fails when checking whitespace.
The XML parts all come from the standard library, slightly tweaked. Can
you please check if std.xml has the same problem?
--
/Jacob Carlborg
Re: Orange check failling all of a sudden
On 2018-06-12 02:13, DigitalDesigns wrote: I also get a lot of inout's attached to key names. Seems excessive but inout(inout(double)[]) Maybe they are necessary but seems like they are redundant. I don't think they're technically necessary. -- /Jacob Carlborg
Re: Get static fields!
On Saturday, 16 June 2018 at 05:05:19 UTC, DigitalDesigns wrote: tupleof does not return static fields as does not Fields. Currently the only method seems to be use allMembers, but that returns members requiring filtering, which there is no good filtering checks. I'd simply like to get all the fields of a type, static and non-static. std.traits.hasStaticMember is your friend: import std.meta : Filter, staticMap, Alias, ApplyLeft; import std.traits : hasStaticMember; alias FilterMembers(T, alias Fn) = Filter!(ApplyLeft!(Fn, T), __traits(allMembers, T)); alias StaticNamesTuple(T) = FilterMembers!(T, hasStaticMember); And if you want them as aliases: alias getMember(T, string name) = Alias!(__traits(getMember, T, name)); alias GetMembers(T, names...) = staticMap!(ApplyLeft!(getMember, T), names); alias StaticMembersTuple(T) = GetMembers!(T, StaticNamesTuple!T); -- Simen
Re: Orange check failling all of a sudden
On 2018-06-13 02:31, DigitalDesigns wrote: Also, is there any way to have a field as optional? Right now when I update a filed in a serialized type the app crashes because it can't find the field in the serialized data(since it was just added in the code). This requires either regenerating the data or manually adding the serialized field to each entry... both are impractical. The only way would be to implement the serialization yourself, i.e. implement `toData` and `fromData`, but I don't think there's a way to check if a field is present in the serialized data. So it might not be so easy. It would be nice to disable missing fields from throwing. While I could catch one error it would be a pain to try and catch an arbitrary number of them. You can set the "errorCallback" [1] to an empty delegate or whatever you see fit. But this callback will be called for other errors as well. Maybe an attribute is better used: @allowDefaultSerialized [1] https://github.com/jacob-carlborg/orange/blob/master/orange/serialization/Serializer.d#L133 -- /Jacob Carlborg
Re: Create a List or Dictionary.
On 06/19/2018 11:50 AM, Sunny wrote: I read about D here - https://www.tutorialspoint.com/d_programming/index.htm I'd advise against using that tutorial. Last time I looked at it, it seemed to be of low quality [1]. And the better parts seemed to be stolen from Ali Çehreli's "Programming in D", which is available for free, too: http://ddili.org/ders/d.en/ [1] https://forum.dlang.org/post/onstqa$255e$1...@digitalmars.com
Re: What is the point of nothrow?
On Monday, 18 June 2018 at 20:23:48 UTC, Jonathan M Davis wrote: On Monday, June 18, 2018 15:22:48 wjoe via Digitalmars-d-learn wrote: On Saturday, 16 June 2018 at 21:25:01 UTC, Jonathan M Davis wrote: > every feature that you can't use in betterC is considered a > loss, and efforts are being made to make more of them work. > There's always going to be a limit to that, and some D > features just plain require druntime (just like some of > C++'s features require a runtime), but it was never the > point of betterC to strip out a bunch of D features. That's > just the natural It is what it is and if what it is is the best tool to fix a problem I would not hesitate to use it to that end. But you make it sound like betterC _should only_ work if actual D code is called otherwise stick with good old C. From the POV of a C programmer most of what betterC offers is a net gain and nothing is a loss because what are they losing by upgrading from C? And in general not paying for something you don't use or need is considered a gain, no? I'm saying that -betterC is a subset of D that does not include D's runtime, and it includes as many of D's features as it currently can without using the runtime. You can choose to use it and never use normal D code, but the reason that it was created in the first place was so that it would be easier to port C code to D. Without -betterC, you tend to be forced to port the entire program at once, whereas with it, you can port it in pieces and then only switch to normal D once everything has been ported over. But there are some folks who elect to just write code targetting -betterC and who never intend for it to work as normal D code. That's not how it came across. It came across like the _entire_ purpose of it is to call D stuff without the need to deal with the druntime and nothing else. Please tell me. How would I disable just the Error mechanism, for example ? As far as I can tell it's not sufficient that I don't use nothrow in my code because if it was used in phobos or druntime or some other D code I'd have to deal with it. As with pretty much every other feature, if you don't want any Errors, you just don't use anything that uses it. The same goes with the GC and other features that you might choose to avoid. In some cases, that can be quite limiting, but it is possible to avoid it. It's simply that just like with any feature, avoiding it means losing out on features. So basically everything safe for what is betterC. The primary difference with nothrow over most other features is that the compiler inserts code by default for Exceptions if nothrow isn't there. So, using nothrow is required to turn that off, whereas for most other features, they only get used if you choose to use them (or use something that uses them). But it has nothing to do with Errors either way. The only way to avoid those is to never use a feature that could throw them (which can be done but would be so limiting that it's probably a waste of time). If having the program crash due to an error condition being considered fatal is unacceptable to you, then D will be I never made that claim. Unacceptable to me is the implemented mechanism. unacceptable to you - including with -betterC, since in that case, the Errors get turned into failed C assertions that aren't compiled out. So, you won't get the stack unwinding, but your program will be purposefully killed either way, because it encountered an error condition that is considered fatal. You're yes, it will be terminated via sigabrt. Which is the way it's supposed to be. Not to continue running to a function that prints possibly invalid stuff, iff a console like device is attached, and abort in a central, completely unrelated, part of the druntime. If no console is attached, you'll end up with nothing. Seriously, the entire mechanism is contradicting itself. How can it declare program state invalid and unfit to continue at the point the Error was detected and thrown but do it regardless ? free to disagree with that approach, and you're free to disagree with which error conditions are considered fatal, but it's part of using D. So, you'll either have to learn to live with that or use a different language. - Jonathan M Davis One could also argue that Exceptions are an integral part of using D and there is really never a situation where you need to turn it off just like there is never a situation where you would catch an Error. Deal with it. If a programming language doesn't so much as to help the developer to be more productive, e.g. by making it easier to squash bugs but, by definition i.e. invalid program state, make it impossible to troubleshoot them, then this language is at least a bad decision from an economic point of view. Which makes it a toy language. I know that much of what can be done actually works in practice but that's not the point. As soon as
Re: Create a List or Dictionary.
On Tuesday, 19 June 2018 at 09:07:46 UTC, Cym13 wrote: On Tuesday, 19 June 2018 at 05:52:00 UTC, Sunny wrote: On Monday, 18 June 2018 at 13:23:37 UTC, Cym13 wrote: Yes, this is what need, thank you very much for your help. :-) [...] I recommend that you take the D tour if you can, it explains all those fundamental features quite well I think. https://tour.dlang.org/ I read about D here - https://www.tutorialspoint.com/d_programming/index.htm I've been studying D for about 5 days, I switched from C #, I figured it all out, but with a convenient implementation of the sheets there was a problem.
Re: Create a List or Dictionary.
On Tuesday, 19 June 2018 at 05:52:00 UTC, Sunny wrote: On Monday, 18 June 2018 at 13:23:37 UTC, Cym13 wrote: Yes, this is what need, thank you very much for your help. :-) [...] I recommend that you take the D tour if you can, it explains all those fundamental features quite well I think. https://tour.dlang.org/
