Re: As many thanks As possible to who crates D and UFCS feature
On Friday, 12 May 2017 at 20:53:56 UTC, Bastiaan Veelo wrote: Is it safe to say that these 40 lines of D do the same as your 324 lines of C++ [1]? No. I cannot say that. Since this is not a full port of renrem in C++ to D. It was just an example in D, nothing else. This, and your comments on the difficulties of building renrem [2] versus doing "rdmd", and the steepness of the learning curve (1 year C++ vs 2 weeks D), and the productivity (2 hours D vs ?? C++) I am not sure about understanding your purpose correctly. I think are plenty material for a nice little blog. Which English Grammar rule is used here? Sorry but I do not know! are: linking verb after think: main verb and subject! --- I just want to say D is easy to learn and use; that is it. I have no arguing about which Language is better no not. Of course that program with C++, took me 1 month until it got ready, but in 2 days I could ported to D, since I had the already experience of implementing it. Mike Parker runs the D blog, and I think he might be interested. No need to worry about the english language, you are safe with Mike. I'll see if I can get you his attention. Sorry ... Still could not understand ... except you may want me to put such post in D blog not here, and in this case, your are right, the best way for such examples is on a blog or similar. Sorry for posting it here.
Re: SysTime.fromISOString
On Saturday, May 13, 2017 07:33:35 Russel Winder via Digitalmars-d-learn wrote: > A priori I thought 2015 was a perfectly valid ISO8601 date-time > specification. It appears that SysTime.fromISOString disagrees: > > core.time.TimeException@/usr/include/d/std/datetime.d(8553): Invalid > ISO String: 2015 > > So am I right or wrong. > https://en.wikipedia.org/wiki/ISO_8601https://en.wikipedia.org/wiki/ISO_8 > 601 The ISO representation of a date is MMDD, and the extended ISO representation is -MM-DD. would be a truncated representation. The standard has language such as "If, by agreement, truncated representations are used" to talk about truncated representations, but it's not part of the actual, standard string representation. It's just giving guidance on what applications should do if they decide to not use the full string representation when communicating with one another, and it's not expected that an application that supports the standard would support truncated representations. It's only "by agreement," between two applications, not standard. std.datetime only supports the full, standard string representation, and for SysTime, that also includes the time, not just the date. std.datetime.Date would be the closest, but it represents a date, not just a year, so it's MMDD or -MM-DD. If you want to pass a string to SysTime.fromISOString, it's going to need to be MMDDTHHMMSS (optionally with fractional seconds and a time zone). And really, there isn't much useful that can be done with a SysTime that was constructed from just a year anyway. The best SysTime could do would be to assume you meant 2015-01-01T00:00:00. It operates on the system time in hecto-nanoseconds and really isn't meant be operating on dates (that's what Date and DateTime are for). Converting 2015 to a SysTime with no information would be like trying to construct a time_t in C with just 2015. That usually doesn't make much sense. Nothing in std.datetime operates simply on a year. The closest that you're going to get to that is Date. Regardless, if you know that you're just dealing with a year, and that's it, you can just call to!int on it and pass it to the constructor of SysTime, DateTime, or Date (depending on which you want to use) with whatever values you want to set for the month, day, etc. Using a function like fromISOString would just be overkill if all you have is a year, even if it did accept truncated representations. But the truncated representations are not required by the standard, so they're not supported. - Jonathan M Davis
Re: How to avoid throwing an exceptions for a built-in function?
On Saturday, 13 May 2017 at 02:40:17 UTC, Mike B Johnson wrote:
You are not making a lot of sense:
1. Exception do bubble up, so you don't need to "handle"
exceptions at the call site if you don't want to. The whole
point of exceptions is do effectively do what you want.
2. You say that you don't have to deal with it in your code but
you are trying to deal with it now.
You are not clear on exactly what you are trying to accomplish.
Can you be more specific on why you do not want to add a
try/catch/if-else/ifThrown/etc? Is it because you don't need to
handle it in your own usage? If that is true, will others ever
use it?
Basically all you have to do is ask yourself this:
"Do I need to EVER handle the case where the data is invalid?"
If you do(e.g., other users will use your code) then you better
implement some type of exception handling. Else all you have to
do is always put in the right data(not good because it might
bite you in the ass one day).
If you just want less noise when the program crashes, just put
a try/catch block in main and catch all generic exceptions and
exit with a simple error message like "There was an ERROR, I do
not know why...".
Way arguing when a simple code can clarify the subject? right?
If am not clear so consider me as an stupid man, no problem at
all.
but CAN you please solve it for me?
import std.stdio: writeln;
import std.conv:to;
void main( string[] args ){
string str = "10";
int index;
index = to!int( str ); // okay, no exception are thrown
str = "some-words";
index = to!int( str ); // problem, an exception is thrown
}
Please run this code and convert "some-words" to int by using to!
function without facing any exception. Thanks
Re: How to avoid throwing an exceptions for a built-in function?
On Friday, May 12, 2017 10:42:18 H. S. Teoh via Digitalmars-d-learn wrote: > On Fri, May 12, 2017 at 12:47:04PM +0200, ag0aep6g via Digitalmars-d-learn wrote: > > On 05/12/2017 10:32 AM, k-five wrote: > > > Interesting! I was worried about performance and for that I did not > > > want to use try-catch. > > > So (isNumberic) is a good solution. > > > http://dlang.org/phobos/std_traits.html#isNumeric > > > > If you're doing this for speed, you better be benchmarking. Exceptions > > are slow when they're thrown. But if no exception is being thrown, > > try-catch is probably faster than checking isNumeric beforehand. > > Yes, when it comes to performance-related issues, always profile, > profile, profile. (Or benchmark, benchmark, benchmark. Anything that > gives you actual measurements rather than subjective judgment calls.) > Far too often, what we think will perform poorly is actually nowhere > near the real bottleneck in the program, and we end up wasting too much > time "optimizing" something that doesn't even make a noticeable > difference in the end. Whereas, using a profiler early on will help you > zero in on the real bottlenecks, and you could potentially make huge > performance savings with much less effort. For the most part, when parsing a string, std.conv.to's approach of just parsing the string and throwing an exception if/when it fails is the most efficient, because it's only going to parse the string once, whereas calling a function to validate the string's format and _then_ do the conversion would mean parsing the string twice. It's just that if you are in a situation where the string is likely not to be in the correct format, then having a bunch of exceptions thrown will harm performance. To best handle that, we'd need an alternate conversion function that did something like return the failure condition and passed the result via an out parameter or one which took a default value and returned that on failure instead of what was actaully parsed. So, ideally, we'd have other functions in std.conv to handle such cases, but in the vast majority of cases, throwing an exception on failure is going to be the most efficient solution. But obviously, to know what's actually happening with your code, you're going to have to profile and benchmark it - especially if you're throwing exceptions on a regular basis but not super frequently, because then it's quickly an open question as to whether parsing twice to avoid the exception or letting the exception be thrown and caught would be faster. Odds are though that unless you're converting in a tight loop, the relative costs won't matter much, even if one is clearly more expensive than the other, simply because it's not a bottleneck in your program. But you won't know that for sure unless you profile. However, unless you're parsing a lot of invalid strings, I'd be very surprised if always parsing twice were more efficient than parsing only once and throwing an exception on failure. And D exceptions are fairly efficient at this point if you don't call toString, because we stripped out most of the string processing that they were doing up front before. It used to be pretty painful when you did a lot of tests that tested the error cases, because the exceptions really increased the time that the tests took, but that's no longer the case (IIRC, the improvements literally saved seconds of execution time in std.datetime's unit tests). - Jonathan M Davis
Re: Lookahead in unittest
On Friday, May 12, 2017 14:46:30 H. S. Teoh via Digitalmars-d-learn wrote:
> On Fri, May 12, 2017 at 05:23:23PM -0400, Steven Schveighoffer via
> Digitalmars-d-learn wrote: [...]
>
> > Note, you can achieve what you want with version(unittest):
> >
> > version(unittest)
> > {
> >
> >class A { B b; }
> >class B { }
> >
> > }
> >
> > unittest
> > {
> >
> >// use A and B here
> >
> > }
>
> [...]
>
> This advice, unfortunately, needs to be tempered with caution about
> namespace pollution and accidental dependency of things outside
> unittests on things inside a version(unittest) block. There's also the
> issue of library code introducing extraneous import dependencies that
> are really only necessary for unittesting, but get pulled in anyway
> because user code happens to compile with -unittest.
Yeah, that can get annoying, though I think that the only real problem in
general is imports. If you use version(unittest) on imports, then you run
the risk of having imports that are required for normal operation being only
available when you compile with -unittest and not catching it. But unless
you have a problem using version(unittest) types or functions in your actual
code (which would be kind of weird), then I wouldn't expect it to be a
problem.
However, in many cases, it makes sense to just move the declarations into
the unittest blocks (especally if they're only used in one unittest block),
and then you avoid the whole problem (though in this case, you'd want to
mark the classes as static if you put them in the unittest block).
- Jonathan M Davis
Re: std.getopt and std.datetime
On Saturday, May 13, 2017 06:53:25 Russel Winder via Digitalmars-d-learn wrote: > Is there a canonical, idiomatic way of processing std.datetime objects > using std.getopt? > > Currently, I am suffering: > > /usr/include/d/std/getopt.d(921): Error: static assert "Dunno how to deal > with type SysTime*" > > which on the one hand is understandable, albeit dreadful English, but > then I suppose it is American not English At best, it's slang. It's not proper anything. https://github.com/dlang/phobos/pull/5388 - Jonathan M Davis
Re: How to avoid throwing an exceptions for a built-in function?
On Saturday, 13 May 2017 at 08:50:20 UTC, k-five wrote:
Way arguing when a simple code can clarify the subject? right?
If am not clear so consider me as an stupid man, no problem at
all.
but CAN you please solve it for me?
import std.stdio: writeln;
import std.conv:to;
void main( string[] args ){
string str = "10";
int index;
index = to!int( str ); // okay, no exception are thrown
str = "some-words";
index = to!int( str ); // problem, an exception is thrown
}
Please run this code and convert "some-words" to int by using
to! function without facing any exception. Thanks
Please don't take it the wrong way. It just seems that Mike was
as confused by your questions as I was initially. But it's clear
that's just the language barrier, nothing more. See, you said:
Why I do not want to take care of that? Because I just need the
value, if the string is valid, otherwise no matter what the
value of string is.
...but it doesn't make sense to have an int "value" for a string
like "some-words". *Unless* one defines a "not-a-number"
equivalent for an int, i.e. 0 or some other value. That part was
hard to infer from what you were saying :) It might've been
obvious for you, but hard to understand from what you wrote.
This was what made things clear:
I just want to silent this exception...
Mostly, the source of the confusion was the "I don't want to
handle the exception". But in fact what you were asking was was
there a way to somehow ignore the exception and just return some
predefined value in case of an error. So in fact, you did want to
handle the exception (or rather, an exceptional case), you just
wanted to do it without inserting control flow instructions
(try/catch) into your code. I think the latter part already got
covered in others' replies.
Nobody was trying to insult you. With this being a multi-lingual
and multi-cultural community, remember that understanding goes
both ways, and we're sometimes caught right in the middle, in the
clash of mentalities.
Re: How to avoid throwing an exceptions for a built-in function?
On Saturday, 13 May 2017 at 09:05:17 UTC, Jonathan M Davis wrote: For the most part, when parsing a string, std.conv.to's approach of just parsing the string and throwing an exception if/when it fails is the most efficient, because it's only going to parse the string once, whereas calling a function to validate the string's format and _then_ do the conversion would mean parsing the string twice.It's just that if you are in a situation where the string is likely not to be in the correct format, then having a bunch of exceptions thrown will harm performance. To best handle that, we'd need an alternate conversion function that did something like return the failure condition and passed the result via an out parameter or one which took a default value and returned that on failure instead of what was actaully parsed. So, ideally, we'd have other functions in std.conv to handle such cases, but in the vast majority of cases, throwing an exception on failure is going to be the most efficient solution. I did not know this. But obviously, to know what's actually happening with your code, you're going to have to profile and benchmark it - Can you please give a link or page or something to read about profile or benchmark. I have no experience with those. --- For a such purpose I already used std::stringstream in C++, and I assumed may or may not D has a such family. ( to!, parse!, ... ) Not only an invalid string like "word" for to!int, makes it being thrown, but an empty string like: "" also makes it. string str = "word"; int index = to!int( str ); // throws str = ""; int index = to!int( str ); // throws, as well! Of course throwing is useful some times, but definitely not ALWAYS, and it is better to have a convert function that never throws anything. Although [Andrei Alexandrescu] told me that the parse! family is used for such a case: Use the "parse" family: https://dlang.org/phobos/std_conv.html#parse -- Andrei but it throws as well.
Re: As many thanks As possible to who crates D and UFCS feature
On Saturday, 13 May 2017 at 08:23:55 UTC, k-five wrote: On Friday, 12 May 2017 at 20:53:56 UTC, Bastiaan Veelo wrote: Is it safe to say that these 40 lines of D do the same as your 324 lines of C++ [1]? No. I cannot say that. Since this is not a full port of renrem in C++ to D. It was just an example in D, nothing else. OK understood. This, and your comments on the difficulties of building renrem [2] versus doing "rdmd", and the steepness of the learning curve (1 year C++ vs 2 weeks D), and the productivity (2 hours D vs ?? C++) I am not sure about understanding your purpose correctly. I think are plenty material for a nice little blog. Which English Grammar rule is used here? Sorry but I do not know! are: linking verb after think: main verb and subject! I am sorry for expressing myself poorly. What I meant to say is that it looked like you can write an interesting article about your experience learning and using C++ and learning and using D, comparing the two. D could come out of that comparison favourably considering 1) how long it takes to learn, 2) how much code you need to write, 3) whether there are difficulties along the way, and 4) how productive you can be (getting things done). I may have been jumping to conclusions, but it could still be an interesting read, especially for people that consider learning C++ or D. In particular the focus on UFCS is interesting, as that can be rather alien to beginners, and something you are enthusiastic about. I just want to say D is easy to learn and use; that is it. I have no arguing about which Language is better no not. Of course that program with C++, took me 1 month until it got ready, but in 2 days I could ported to D, since I had the already experience of implementing it. Understood. Mike Parker runs the D blog, and I think he might be interested. No need to worry about the english language, you are safe with Mike. I'll see if I can get you his attention. Sorry ... Still could not understand ... except you may want me to put such post in D blog not here, and in this case, your are right, the best way for such examples is on a blog or similar. Sorry for posting it here. Posting it here is fine. You could also have posted in the general forum, as it is more of a compliment than a question. But if you want to write more about your positive experience, then a blog article might be nice. It would reach more people, and it would maybe help some of them. If you want to do that work, then maybe Mike Parker would want to put it on the D blog, and help you polish it. Whatever you decide to do, thanks for sharing your experience here :-) Bastiaan.
Re: As many thanks As possible to who crates D and UFCS feature
On Saturday, 13 May 2017 at 10:15:34 UTC, Bastiaan Veelo wrote: On Saturday, 13 May 2017 at 08:23:55 UTC, k-five wrote: [...] OK understood. [...] I am sorry for expressing myself poorly. What I meant to say is that it looked like you can write an interesting article about your experience learning and using C++ and learning and using D, comparing the two. D could come out of that comparison favourably considering 1) how long it takes to learn, 2) how much code you need to write, 3) whether there are difficulties along the way, and 4) how productive you can be (getting things done). I may have been jumping to conclusions, but it could still be an interesting read, especially for people that consider learning C++ or D. In particular the focus on UFCS is interesting, as that can be rather alien to beginners, and something you are enthusiastic about. [...] Understood. [...] Posting it here is fine. You could also have posted in the general forum, as it is more of a compliment than a question. But if you want to write more about your positive experience, then a blog article might be nice. It would reach more people, and it would maybe help some of them. If you want to do that work, then maybe Mike Parker would want to put it on the D blog, and help you polish it. Whatever you decide to do, thanks for sharing your experience here :-) Bastiaan. On Saturday, 13 May 2017 at 10:15:34 UTC, Bastiaan Veelo wrote: -- Okay, and NOW I understood what you are trying to say. First of all I thought you got mad at me. And I became sad. Since; I tell this really that I was so happy about the code in D, that I would want to share my happiness here with others and not expressing myself. Still I am a beginner and learner. Thanks anyway.
Re: As many thanks As possible to who crates D and UFCS feature
On Saturday, 13 May 2017 at 10:51:09 UTC, k-five wrote: Okay, and NOW I understood what you are trying to say. First of all I thought you got mad at me. And I became sad. My sincere apologies! Always assume the best in people :-) I am glad you asked for clarification. [...] Still I am a beginner and learner. I am too, and learners we are all. Thanks anyway. Welcome.
Re: SysTime.fromISOString
On Sat, 2017-05-13 at 01:52 -0700, Jonathan M Davis via Digitalmars-d- learn wrote: > […] > The ISO representation of a date is MMDD, and the extended ISO > representation is -MM-DD. would be a truncated > representation. The > standard has language such as "If, by agreement, truncated > representations > are used" to talk about truncated representations, but it's not part > of the > actual, standard string representation. It's just giving guidance on > what > applications should do if they decide to not use the full string > representation when communicating with one another, and it's not > expected > that an application that supports the standard would support > truncated > representations. It's only "by agreement," between two applications, > not > standard. std.datetime only supports the full, standard string > representation, and for SysTime, that also includes the time, not > just the > date. std.datetime.Date would be the closest, but it represents a > date, not > just a year, so it's MMDD or -MM-DD. If you want to pass a > string to > SysTime.fromISOString, it's going to need to be > MMDDTHHMMSS (optionally > with fractional seconds and a time zone). My reading is that -MM is an allowed form: I was wrong to suggest was allowed. For times hh:mm is allowed as well as hh:mm:ss. fromIsoString should allow for MMDDTHHMMSS and -MM-DDThh:mm:ss shouldn't it? > And really, there isn't much useful that can be done with a SysTime > that was > constructed from just a year anyway. The best SysTime could do would > be to > assume you meant 2015-01-01T00:00:00. It operates on the system time > in > hecto-nanoseconds and really isn't meant be operating on dates > (that's what > Date and DateTime are for). Converting 2015 to a SysTime with no > information > would be like trying to construct a time_t in C with just 2015. That > usually > doesn't make much sense. Nothing in std.datetime operates simply on a > year. > The closest that you're going to get to that is Date. I agree I need to construct a Date or DateTime from the string and then a SysTime from that. I was just being lazy earlier. > Regardless, if you know that you're just dealing with a year, and > that's it, > you can just call to!int on it and pass it to the constructor of > SysTime, > DateTime, or Date (depending on which you want to use) with whatever > values > you want to set for the month, day, etc. Using a function like > fromISOString > would just be overkill if all you have is a year, even if it did > accept > truncated representations. But the truncated representations are not > required by the standard, so they're not supported. Indeed. However I believe the standard defines more than is accepted. The code: auto newDate = Date.fromISOString(date_buffer); leads to: core.time.TimeException@/usr/include/d/std/datetime.d(12932): Invalid ISO String: 2015-05-10 I'd suggest 2015-05-10 is a perfectly good ISO8601 compliant date and so highlights a bug/ -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: std.getopt and std.datetime
On Sat, 2017-05-13 at 02:23 -0700, Jonathan M Davis via Digitalmars-d- learn wrote: > […] > At best, it's slang. It's not proper anything. > > https://github.com/dlang/phobos/pull/5388 > > - Jonathan M Davis Indeed. Thanks for getting a pull request in to ameliorate the difficulty. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: SysTime.fromISOString
On Saturday, May 13, 2017 12:06:57 Russel Winder via Digitalmars-d-learn wrote: > On Sat, 2017-05-13 at 01:52 -0700, Jonathan M Davis via Digitalmars-d- > learn wrote: > My reading is that -MM is an allowed form: I was wrong to suggest > was allowed. -MM is still truncated and therefore only permitted if applications agree to it. > For times hh:mm is allowed as well as hh:mm:ss. Rereading the spec, yes, HH:MM is permitted instead of HH:MM:SS, but HH is not, and any truncation of -MM-DD is considered a truncation and therefore only permitted if the applications involved agree to it. So, arguably fromISOString and fromISOExtString should be changed to allow HHMM and HH:MM respectively but not HH, -MM, MM, or . > fromIsoString should allow for MMDDTHHMMSS and -MM-DDThh:mm:ss > shouldn't it? MMDDTHHMMSS is the ISO basic format, and -MM-DDTHH:MM:SS is the ISO extended format (so, they're both from the same standard, but they're not the same format). fromISOString handles the ISO basic format, and fromISOExtString handles the ISO extended format. > > Regardless, if you know that you're just dealing with a year, and > > that's it, > > you can just call to!int on it and pass it to the constructor of > > SysTime, > > DateTime, or Date (depending on which you want to use) with whatever > > values > > you want to set for the month, day, etc. Using a function like > > fromISOString > > would just be overkill if all you have is a year, even if it did > > accept > > truncated representations. But the truncated representations are not > > required by the standard, so they're not supported. > > Indeed. However I believe the standard defines more than is accepted. > The code: > > auto newDate = Date.fromISOString(date_buffer); > > leads to: > > core.time.TimeException@/usr/include/d/std/datetime.d(12932): Invalid ISO > String: 2015-05-10 > > I'd suggest 2015-05-10 is a perfectly good ISO8601 compliant date and > so highlights a bug/ fromISOString is throwing, because you're giving it the extended format. For that, you need to use fromISOExtString. - Jonathan M Davis
Re: SysTime.fromISOString
And this seems awkward:
auto date = Clock.currTime();
auto date_buffer = date.toISOString();
…
try {
date = SysTime.fromISOString(date_buffer);
} catch (DateTimeException dte) {
try {
date =
SysTime(DateTime.fromISOString(date_buffer));
} catch (DateTimeException ddttee) {
date =
SysTime(Date.fromISOString(date_buffer));
}
}
Even though it works, well with 20150510 if not 2015-05-10.
I suspect I am doing it wrong. :-)
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: SysTime.fromISOString
On Sat, 2017-05-13 at 04:24 -0700, Jonathan M Davis via Digitalmars-d- learn wrote: > […] > > -MM is still truncated and therefore only permitted if > applications > agree to it. But didn't that come is as standard in the 2000 standard along with -- MM-DD for yearless date? > > For times hh:mm is allowed as well as hh:mm:ss. > > Rereading the spec, yes, HH:MM is permitted instead of HH:MM:SS, but > HH is > not, and any truncation of -MM-DD is considered a truncation and > therefore only permitted if the applications involved agree to it. I'm still going to fight for -MM, but not to the extent of buying the latest standard document from ISO! > So, arguably fromISOString and fromISOExtString should be changed to > allow > HHMM and HH:MM respectively but not HH, -MM, MM, or . > > > fromIsoString should allow for MMDDTHHMMSS and -MM- > > DDThh:mm:ss > > shouldn't it? > > MMDDTHHMMSS is the ISO basic format, and -MM-DDTHH:MM:SS is > the ISO > extended format (so, they're both from the same standard, but they're > not > the same format). fromISOString handles the ISO basic format, and > fromISOExtString handles the ISO extended format. OK, we have my error, two different calls. Of course this means for a string from the users you have to attempt a parse in one format and then on exception try the other format. From a programmer perspective trying to build a SysTime from user input is really awkward. Unless I am missing a magic parse function. > > > Regardless, if you know that you're just dealing with a year, and > > > that's it, > > > you can just call to!int on it and pass it to the constructor of > > > SysTime, > > > DateTime, or Date (depending on which you want to use) with > > > whatever > > > values > > > you want to set for the month, day, etc. Using a function like > > > fromISOString > > > would just be overkill if all you have is a year, even if it did > > > accept > > > truncated representations. But the truncated representations are > > > not > > > required by the standard, so they're not supported. > > > > Indeed. However I believe the standard defines more than is > > accepted. > > The code: > > > > auto newDate = Date.fromISOString(date_buffer); > > > > leads to: > > > > core.time.TimeException@/usr/include/d/std/datetime.d(12932): > > Invalid ISO > > String: 2015-05-10 > > > > I'd suggest 2015-05-10 is a perfectly good ISO8601 compliant date > > and > > so highlights a bug/ > > fromISOString is throwing, because you're giving it the extended > format. For > that, you need to use fromISOExtString. From the perspective of someone trying to parse "Input ISO format string" really, really awkward. I do not want to use Vladimirs parse since it copes with to many formats, I just want IS8601 compliant parse (hence not using parse822Format. You have pointed out why I was getting the error, but I think you can accept that the tools that are there for converting strings to IS dates need a bit of amendment to make them easy for programmers to work with. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: SysTime.fromISOString
On Saturday, May 13, 2017 12:31:38 Russel Winder via Digitalmars-d-learn
wrote:
> And this seems awkward:
>
>
> auto date = Clock.currTime();
> auto date_buffer = date.toISOString();
> …
> try {
> date = SysTime.fromISOString(date_buffer);
> } catch (DateTimeException dte) {
> try {
> date =
> SysTime(DateTime.fromISOString(date_buffer));
> } catch (DateTimeException ddttee) {
> date =
> SysTime(Date.fromISOString(date_buffer));
> }
> }
>
> Even though it works, well with 20150510 if not 2015-05-10.
>
> I suspect I am doing it wrong. :-)
Well, Clock.currTime() gives you a SysTime, not a Date. So, your date
variable is a SysTime, and date_buffer is going to be something like
"20170513T123138.12392". Calling SysTime.fromISOString will therefore work
on that without throwing, and calling either Date.fromISOString or
DateTime.fromISOString is going to throw, because Date doesn't support the
time (just the date), and DateTime doesn't support the fractional seconds or
a time zone (though you wouldn't currently get a time zone in this case,
because I still need to fix it so that LocalTime gives you a time zone for
to*String - if the time zone isn't there, then local time is assumed, so
what it's doing right now is technically correct, but it's error-prone).
std.datetime's from*String functions are designed to be fairly strict about
parsing, so you need to be fairly sure of what kind of string you're dealing
with. Certainly, you need to know whether you're dealing with the basic ISO
format or the extended ISO format, and you need to know which pieces are
going to be in the string. If it's going to be just the date (e.g.
2012-12-21), then you're going to need to use Date. If it's going to be just
the time (e.g. 04:19:22), then you're going to need to use TimeOfDay. If
it's going to be the date and the time (e.g. 2012-12-21T04:19:22), then you
can use either SysTime or DateTime, but if it's the data and the time and
includes the fractional seconds and/or a time zone (e.g.
2012-12-21T:04:19:22.0002, 2012-12-21T:04:19:22+08:00, or
2012-12-21T:04:19:22.0002+08:00), then you'll need to use SysTime, because
DateTime does not support either the fractional seconds or a time zone.
Each type is expecting a string with the pieces (date, time, fractional
seconds, and time zone) that it supports and that they'll all be there. The
only stuff that's optional is the fractional seconds and time zone when
dealing with SysTime, because the spec does not require that they be there.
If you were trying to be lax with the parsing and accept the various
combinations of what's legal, then you'd be stuck doing something like
SysTime st;
try
{
// If it's -MM-DDTHH:MM:SS.FFFZ
// If it's -MM-DDTHH:MM:SS.FFZ
// If it's -MM-DDTHH:MM:SS.FZ
// If it's -MM-DDTHH:MM:SS.Z
// If it's -MM-DDTHH:MM:SS.FFFZ
// If it's -MM-DDTHH:MM:SS.FFZ
// If it's -MM-DDTHH:MM:SS.FZ
// or -MM-DDTHH:MM:SSZ
// or -MM-DDTHH:MM:SS.FFF
// or -MM-DDTHH:MM:SS.FF
// or -MM-DDTHH:MM:SS.F
// or -MM-DDTHH:MM:SS.
// or -MM-DDTHH:MM:SS.FFF
// or -MM-DDTHH:MM:SS.FF
// or -MM-DDTHH:MM:SS.F
// or -MM-DDTHH:MM:SS
st = SysTime.fromISOExtString(str);
}
catch(DateTimeException)
{
try
{
// If it's just -MM-DD
st = SysTime(Date.fromISOExtString(str));
}
catch(DateTimeException)
{
// If it's just HH:MM:SS
st = SysTime(Date.init, TimeOfDay.fromISOExtString(str));
}
}
But that would be downright bizarre in the case where it was just HH:MM:SS,
because then you'd end up with a SysTime on January 1st, 1 A.D. And while
getting just the date is less awkward, it's still kind off to then operate
on that as a SysTime. The time would always be at midnight.
Really, just parsing an "ISO formatted string" and allowing either the date
or time to be optional doesn't make much sense to me. That implies that you
don't really know what it's for, since the meaning of something that is just
a date and the meaning of something that is just a time are completely
different.
Regardless, std.datetime was designed with the idea that you knew whether
you were dealing with a date, a time, or both a date and a time when dealing
with ISO formatted strings.
- Jonathan M Davis
Re: How to avoid throwing an exceptions for a built-in function?
On Saturday, 13 May 2017 at 09:51:40 UTC, k-five wrote: On Saturday, 13 May 2017 at 09:05:17 UTC, Jonathan M Davis But obviously, to know what's actually happening with your code, you're going to have to profile and benchmark it - Can you please give a link or page or something to read about profile or benchmark. I have no experience with those. Profiling: Halfway down this page: http://www.digitalmars.com/ctg/trace.html Two programs for visualising bottlenecks: https://bitbucket.org/andrewtrotman/d-profile-viewer https://code.dlang.org/packages/profdump Benchmarking: https://youtu.be/QELK73JSpFk?list=PL3jwVPmk_PRxo23yyoc0Ip_cP3-rCm7eB (fresh from DConf) https://dlang.org/library/std/datetime/benchmark.html https://code.dlang.org/packages/std_benchmark https://code.dlang.org/packages/benchmarkplotter
Re: SysTime.fromISOString
On Saturday, May 13, 2017 12:56:31 Russel Winder via Digitalmars-d-learn wrote: > On Sat, 2017-05-13 at 04:24 -0700, Jonathan M Davis via Digitalmars-d- > > learn wrote: > > […] > > > > -MM is still truncated and therefore only permitted if > > applications > > agree to it. > > But didn't that come is as standard in the 2000 standard along with -- > MM-DD for yearless date? > > > > For times hh:mm is allowed as well as hh:mm:ss. > > > > Rereading the spec, yes, HH:MM is permitted instead of HH:MM:SS, but > > HH is > > not, and any truncation of -MM-DD is considered a truncation and > > therefore only permitted if the applications involved agree to it. > > I'm still going to fight for -MM, but not to the extent of buying > the latest standard document from ISO! As I said, per the standard, -MM is a truncated representation, and applications can agree that they'll support it, but it's not required. All of the sections on truncated representations have language such as "If, by agreement, truncated representations are used". Each of the from*String functions are quite specific about what they support. The only portion that's optional that std.datetime supports is the fractional seconds. It looks like I need to make HHMM and HH:MM supported to completely follow the spec (since that's considered a reduction in precision rather than a truncation and is not listed as optional), but all of the various truncations are considered optional by the spec and therefore not supported by std.datetime (and supporting them risks problems with ambiguity - e.g. you can't distinguish from HHMM). > > So, arguably fromISOString and fromISOExtString should be changed to > > allow > > HHMM and HH:MM respectively but not HH, -MM, MM, or . > > > > > fromIsoString should allow for MMDDTHHMMSS and -MM- > > > DDThh:mm:ss > > > shouldn't it? > > > > MMDDTHHMMSS is the ISO basic format, and -MM-DDTHH:MM:SS is > > the ISO > > extended format (so, they're both from the same standard, but they're > > not > > the same format). fromISOString handles the ISO basic format, and > > fromISOExtString handles the ISO extended format. > > OK, we have my error, two different calls. Of course this means for a > string from the users you have to attempt a parse in one format and > then on exception try the other format. From a programmer perspective > trying to build a SysTime from user input is really awkward. Unless I > am missing a magic parse function. > > fromISOString is throwing, because you're giving it the extended > > format. For > > that, you need to use fromISOExtString. > > From the perspective of someone trying to parse "Input ISO format > string" really, really awkward. I do not want to use Vladimirs parse > since it copes with to many formats, I just want IS8601 compliant parse > (hence not using parse822Format. > > You have pointed out why I was getting the error, but I think you can > accept that the tools that are there for converting strings to IS dates > need a bit of amendment to make them easy for programmers to work with. The expectation is that you know which format you're dealing with. std.datetime is not written with the idea that you're dealing with a string with an arbitrary date/time format, and it's going to figure out what it is. It's written with the idea that you know exactly which format the string is in, and it converts the string based on the rules for that format. The ISO basic format and ISO extended format are two different formats. And in my experience, when applications are exchanging information via ISO strings, it's well-defined which format they're going to use. If you're actually dealing with a situation where it's not well-defined, then yes, using std.datetime becomes more painful. A magic parsing function which supported both the ISO basic format and the ISO extended format as well as the various truncated versions of those formats could be written, but it would be very error-prone and in at least some situations, it would be ambiguous, meaning that it could easily make the wrong choice. Using the truncated forms really only works when two applications have agreed on exactly how they're going to handle that, which is likely the reason that the spec says that they're there for if applications agree upon them rather than requiring that an application that supports either the ISO basic format or the ISO extended format supports the truncated versions. - Jonathan M Davis
Re: SysTime.fromISOString
On Sat, 2017-05-13 at 05:30 -0700, Jonathan M Davis via Digitalmars-d- learn wrote: > > […] I can see I am not going to win the -MM discussion so I'll stand down. Until I have read the latest version of the standard – I remain sure this is a reduced accuracy not a truncated representation. But I could just be wrong. > The expectation is that you know which format you're dealing with. > std.datetime is not written with the idea that you're dealing with a > string > with an arbitrary date/time format, and it's going to figure out what > it is. > It's written with the idea that you know exactly which format the > string is > in, and it converts the string based on the rules for that format. > The ISO > basic format and ISO extended format are two different formats. And > in my > experience, when applications are exchanging information via ISO > strings, > it's well-defined which format they're going to use. If you're > actually > dealing with a situation where it's not well-defined, then yes, using > std.datetime becomes more painful. I have just done the obvious cascaded try/catch block to try from the most specific to the least specific, but I'll drop that here as you have got stuck in to dealing with in the other email. (Which is great, thanks for taking the time.) > A magic parsing function which supported both the ISO basic format > and the > ISO extended format as well as the various truncated versions of > those > formats could be written, but it would be very error-prone and in at > least > some situations, it would be ambiguous, meaning that it could easily > make > the wrong choice. Using the truncated forms really only works when > two > applications have agreed on exactly how they're going to handle that, > which > is likely the reason that the spec says that they're there for if > applications agree upon them rather than requiring that an > application that > supports either the ISO basic format or the ISO extended format > supports the > truncated versions. I think my situation is not the general case so actually I have no problem. But I shall shift this to the other thread. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: SysTime.fromISOString
On Sat, 2017-05-13 at 05:03 -0700, Jonathan M Davis via Digitalmars-d-
learn wrote:
>
[…]
> SysTime st;
> try
> {
> // If it's -MM-DDTHH:MM:SS.FFFZ
> // If it's -MM-DDTHH:MM:SS.FFZ
> // If it's -MM-DDTHH:MM:SS.FZ
> // If it's -MM-DDTHH:MM:SS.Z
> // If it's -MM-DDTHH:MM:SS.FFFZ
> // If it's -MM-DDTHH:MM:SS.FFZ
> // If it's -MM-DDTHH:MM:SS.FZ
> // or -MM-DDTHH:MM:SSZ
> // or -MM-DDTHH:MM:SS.FFF
> // or -MM-DDTHH:MM:SS.FF
> // or -MM-DDTHH:MM:SS.F
> // or -MM-DDTHH:MM:SS.
> // or -MM-DDTHH:MM:SS.FFF
> // or -MM-DDTHH:MM:SS.FF
> // or -MM-DDTHH:MM:SS.F
> // or -MM-DDTHH:MM:SS
> st = SysTime.fromISOExtString(str);
> }
> catch(DateTimeException)
> {
> try
> {
> // If it's just -MM-DD
> st = SysTime(Date.fromISOExtString(str));
> }
A variation on this is where I have gone, so that you are not telling
me I am doing it wrong, means it is probably the least worst solution.
I do a cascade of attempting to construct using SysTime.fromISOString,
SysTime.fromISOExtString, DateTime.fromISOString,
DateTime.fromISOExtString, Date.fromISOString, Date.fromISAExtString
(creating a SysTime in the latter four cases obviously).
> catch(DateTimeException)
> {
> // If it's just HH:MM:SS
> st = SysTime(Date.init, TimeOfDay.fromISOExtString(str));
> }
> }
I haven't got to this stage as yet, but I suspect I am going to have
to.
> But that would be downright bizarre in the case where it was just
> HH:MM:SS,
> because then you'd end up with a SysTime on January 1st, 1 A.D. And
> while
> getting just the date is less awkward, it's still kind off to then
> operate
> on that as a SysTime. The time would always be at midnight.
I think you have to use the current date/time and extract the Date to
initialise. Times have to be in extended format to avoid the HHMM
conflict you pointed out.
> Really, just parsing an "ISO formatted string" and allowing either
> the date
> or time to be optional doesn't make much sense to me. That implies
> that you
> don't really know what it's for, since the meaning of something that
> is just
> a date and the meaning of something that is just a time are
> completely
> different.
I disagree. There is now and some temporal location in the past.
Separating out durations makes that easy. Using a time means sometime
today before now or is an error. Using a date/time means before today
or is an error. This is not a general case, it is a specific need for
the use of two date/times, and it seems all viable to me. Actually I
can probably separate date/times and times as well as separating out
durations before now to make things easier.
> Regardless, std.datetime was designed with the idea that you knew
> whether
> you were dealing with a date, a time, or both a date and a time when
> dealing
> with ISO formatted strings.
I'll get round it. Now I have "from the horses mouth" the guidance
around my questions, I am fairly confident of where to go to achieve
the goal. It will not be pretty, but it will be doable without having
to create a magic parsing function.
Thanks for your exchanges on this, most constructive and most helpful.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Access specifiers and visibility
On Wednesday, 10 May 2017 at 01:42:47 UTC, Andrew Edwards wrote: Attempting to update a git repo to current D, I encounter the following deprecation messages: src/glwtf/signals.d-mixin-256(256,2): Deprecation: glwtf.input.BaseGLFWEventHandler._on_key_down is not visible from module glwtf.signals src/glwtf/signals.d-mixin-256(256,2): Deprecation: glwtf.input.BaseGLFWEventHandler._on_key_up is not visible from module glwtf.signals src/glwtf/signals.d-mixin-256(256,2): Deprecation: glwtf.input.BaseGLFWEventHandler._on_mouse_button_down is not visible from module glwtf.signals src/glwtf/signals.d-mixin-256(256,2): Deprecation: glwtf.input.BaseGLFWEventHandler._on_mouse_button_up is not visible from module glwtf.signals Those error messages are often misleading. The name of the symbol alone is (often, always?) right but the module/package it says it's from is often nonsense. I often get deprecation messages saying things like "myPackage.myModule.to is not visible from module myPackage.myOtherModule", when the real problem is I forgot to import std.conv in myPackage.myOtherModule.
Re: Lookahead in unittest
On 5/12/17 5:46 PM, H. S. Teoh via Digitalmars-d-learn wrote:
On Fri, May 12, 2017 at 05:23:23PM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
[...]
Note, you can achieve what you want with version(unittest):
version(unittest)
{
class A { B b; }
class B { }
}
unittest
{
// use A and B here
}
[...]
This advice, unfortunately, needs to be tempered with caution about
namespace pollution and accidental dependency of things outside
unittests on things inside a version(unittest) block. There's also the
issue of library code introducing extraneous import dependencies that
are really only necessary for unittesting, but get pulled in anyway
because user code happens to compile with -unittest.
This actually already happens. Any imports count, even inside unittests.
But yes, this does mean that symbols in the version(unittest) are in the
module namespace.
You could create a struct or class namespace to avoid the pollution, as
long as you use really horrible names that wouldn't possibly conflict.
-Steve
Do array literals still always allocate?
import std.random;
import std.stdio;
int[4] testfunc(int num) @nogc
{
return [0, 1, num, 3];
}
int main()
{
int[4] arr = testfunc(uniform(0, 15));
writeln(arr);
return 0;
}
I've read a bunch of stuff that seems to indicate that array
literals are always heap-allocated, even when being used to
populate a static array. However, testfunc() above compiles as
@nogc. This would indicate to me that D does the smart thing and
avoids a heap allocation for an array literal being used to
populate a static array. Is all the old stuff I was reading just
out-of-date now?
Re: Do array literals still always allocate?
On Saturday, 13 May 2017 at 18:32:16 UTC, Lewis wrote:
import std.random;
import std.stdio;
int[4] testfunc(int num) @nogc
{
return [0, 1, num, 3];
}
int main()
{
int[4] arr = testfunc(uniform(0, 15));
writeln(arr);
return 0;
}
I've read a bunch of stuff that seems to indicate that array
literals are always heap-allocated, even when being used to
populate a static array.
On the contrary, when initializing static arrays, allocation is
not needed.
Note that what's *conceptually* happening in testfunc is this:
int[4] testfunc(int num) @nogc
{
typeof(return) result = [0, 1, num, 3];
return result;
}
i.e. the type and size of the storage is known beforehand, all
there is to do is copy the elements:
0044e528 <@nogc int[4] test.testfunc(int)>:
44e528: 55 push %rbp
44e529: 48 8b ecmov%rsp,%rbp
44e52c: 48 83 ec 10 sub$0x10,%rsp
44e530: 48 89 7d f8 mov%rdi,-0x8(%rbp)
44e534: c7 07 00 00 00 00 movl $0x0,(%rdi) #
0 goes at offset 0
44e53a: c7 47 04 01 00 00 00movl $0x1,0x4(%rdi) #
1 at offset 4
44e541: 89 77 08mov%esi,0x8(%rdi) #
parameter at offset 8
44e544: c7 47 0c 03 00 00 00movl $0x3,0xc(%rdi) #
3 at offset 12
44e54b: 48 8b 45 f8 mov-0x8(%rbp),%rax
44e54f: c9 leaveq
44e550: c3 retq
Is all the old stuff I was reading just out-of-date now?
Where exactly did you read that initialization of a static array
requires an allocation? That source should be abolished...
errrm... corrected!
Re: Do array literals still always allocate?
On Saturday, 13 May 2017 at 18:32:16 UTC, Lewis wrote:
import std.random;
import std.stdio;
int[4] testfunc(int num) @nogc
{
return [0, 1, num, 3];
}
int main()
{
int[4] arr = testfunc(uniform(0, 15));
writeln(arr);
return 0;
}
I've read a bunch of stuff that seems to indicate that array
literals are always heap-allocated, even when being used to
populate a static array. However, testfunc() above compiles as
@nogc. This would indicate to me that D does the smart thing
and avoids a heap allocation for an array literal being used to
populate a static array. Is all the old stuff I was reading
just out-of-date now?
It's just out of date. Can't remember the version, but this did
use to allocate. It doesn't any more. But only for this case. In
most cases it does allocate.
-Steve
code.demangle can't demangle a type.
So in this document: http://yshui.gitlab.io/sdpc/sdpc/parsers/whitespace.html Part of the type name is still mangled. I found ddox use core.demangle.demangleType internally. So I guess code.demangle is following behind dmd? Is there a better way to demangle a name?
Re: Do array literals still always allocate?
On Saturday, 13 May 2017 at 18:32:16 UTC, Lewis wrote:
import std.random;
import std.stdio;
int[4] testfunc(int num) @nogc
{
return [0, 1, num, 3];
}
int main()
{
int[4] arr = testfunc(uniform(0, 15));
writeln(arr);
return 0;
}
I've read a bunch of stuff that seems to indicate that array
literals are always heap-allocated, even when being used to
populate a static array. However, testfunc() above compiles as
@nogc. This would indicate to me that D does the smart thing
and avoids a heap allocation for an array literal being used to
populate a static array. Is all the old stuff I was reading
just out-of-date now?
1D arrays it doesn't, 2D or higher it does.
Re: Do array literals still always allocate?
On Saturday, 13 May 2017 at 19:22:09 UTC, Steven Schveighoffer wrote: It's just out of date. Can't remember the version, but this did use to allocate. It doesn't any more. But only for this case. In most cases it does allocate. Okay cool, that's good to hear. For reference the most recent place I remember seeing this was http://stackoverflow.com/questions/6751575/how-to-initialise-static-arrays-in-d-without-a-gc-allocation (although I've definitely seen others in the past). I'll add an answer to the SO question to clarify that this is no longer an issue. Thanks all!
Re: File Input
On Monday, 8 May 2017 at 10:34:42 UTC, k-five wrote:
On Monday, 8 May 2017 at 10:22:53 UTC, JV wrote:
On Monday, 8 May 2017 at 09:26:48 UTC, k-five wrote:
On Monday, 8 May 2017 at 08:54:50 UTC, JV wrote:
---
If I continue to learn D I will do but there is no guarantee
and it got ready :)
https://github.com/k-five/D-By-Example
if you have git, download them:
git clone https://github.com/k-five/D-By-Example.git
Hey i'm not sure if i should create a new post for this but
how should i fix this it doesn't pause and store but just keeps
reading
string studNum;
readf("%s",&studNum);
write(studNum);
