Re: The difference between the dates in years
On 2/10/2024 6:01 PM, matheus via Digitalmars-d-learn wrote: On Saturday, 10 February 2024 at 22:11:48 UTC, Brad Roberts wrote: Back when I was doing lots of software developer interviews, one of my frequent questions involved date math. This wasn't because it's difficult from a coding standpoint, but that it's NOT a coding problem. The key part of the question is realization that it's a requirements question. The thing that makes dates complicated is defining what the question actually is. The topic _seems_ like it should be simple, but the deeper you dig the more you realize it's anything but simple. Interesting but I have a doubt, they (Interviewees) should do the test with already existing Date Functions of given language or write new ones? Matheus. My interviews were never tests, they were discussions that might also involve coding tasks. In this case, the discussion was about requirements gathering disguised initially as a coding task. By and large, I never put a lot of weight on the coding parts themselves and mostly focused on problem solving and thinking skills. If the candidate couldn't get past writing code and wouldn't ask questions, that was a very bad sign.
Re: The difference between the dates in years
Back when I was doing lots of software developer interviews, one of my frequent questions involved date math. This wasn't because it's difficult from a coding standpoint, but that it's NOT a coding problem. The key part of the question is realization that it's a requirements question. The thing that makes dates complicated is defining what the question actually is. The topic _seems_ like it should be simple, but the deeper you dig the more you realize it's anything but simple. On 2/10/2024 7:53 AM, Alexander Zhirov via Digitalmars-d-learn wrote: Is it possible to calculate the difference between dates in years using regular means? Something like that ``` writeln(Date(1999, 3, 1).diffMonths(Date(1999, 1, 1))); ``` At the same time, keep in mind that the month and day matter, because the difference between the year, taking into account the month that has not come, will be less. My abilities are not yet enough to figure it out more elegantly.
Re: malloc error when trying to assign the returned pointer to a struct field
On 9/8/2023 12:59 AM, rempas via Digitalmars-d-learn wrote: u64 _cap = 0; // Total amount of elements (not bytes) we can this._ptr = cast(T*)malloc(size); I'm pretty sure this is your problem. You're allocating size bytes which is only going to work where sizeof(T) == 1. Changing to malloc(size * sizeof(T)) is likely going to work better.
Re: purity question
On 5/28/2017 6:46 PM, Brad Roberts via Digitalmars-d-learn wrote: Here's the bug that I'm digging into today, a clear example of an api that _should_ be pure, but based on the implementation is rather difficult for the compiler to infer. https://issues.dlang.org/show_bug.cgi?id=17442
Re: purity question
On 5/28/2017 6:36 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Sunday, May 28, 2017 17:53:25 Brad Roberts via Digitalmars-d-learn wrote:
On 5/28/2017 5:34 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Sunday, May 28, 2017 16:49:16 Brad Roberts via Digitalmars-d-learn
wrote:
Is there a mechanism for declaring something pure when it's built from
parts which individually aren't?
string foo(string s)
{
// do something arbitrarily complex with s that doesn't touch
globals or change global state except possibly state of the heap or gc
return s;
}
you can cast
Ok, so there essentially isn't. I'm well aware of the risks of lying to
the compiler, but it's also not sufficiently smart to unravel complex
code. Combined with there being interesting parts of the standard
libraries that themselves aren't marked pure, there's a real need for
escape hatches.
Well, the big thing is that there are a number of functions in Phobos that
need to have someone go over them and fix them so that they are inferred to
be pure when they should be. Some work has been done in that area, and the
situation is certainly better than it once was, but not enough work has been
done to make it so that we can at all reasonably that everything in Phobos
that should be pure is and what isn't shouldn't be.
A simple example: anything that has a malloc/free pair.
Yeah, if you do it right, you should be fine, but you have to do it right,
and it's very easy to miss some detail that makes it wrong to insist to the
compiler that what you're doing is pure. So, arguably, having anything more
user-friendly than a cast is pretty dangerous. Having folks slap something
like @assume_pure on things (if there were such an attribute) could be
pretty risky. We already have enough trouble with @trusted on that front.
Ultimately, we want to be in a position where needing to get around pure is
very rare, and in most cases, I'd just tell folks to give up on pure on that
piece of code rather than trying to hack it into working.
- Jonathan M Davis
Again, of course it's possible to do it wrong. Escape hatches are like
that. And of course things are being worked on and improved, I'm one of
the ones that's done a good bit of that at various points in time. I'm
really not seeking a lesson or lecture in why it's dangerous.
Here's the bug that I'm digging into today, a clear example of an api
that _should_ be pure, but based on the implementation is rather
difficult for the compiler to infer.
Re: purity question
On 5/28/2017 6:27 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Monday, May 29, 2017 01:01:46 Stefan Koch via Digitalmars-d-learn wrote:
On Monday, 29 May 2017 at 00:53:25 UTC, Brad Roberts wrote:
On 5/28/2017 5:34 PM, Jonathan M Davis via Digitalmars-d-learn
wrote:
On Sunday, May 28, 2017 16:49:16 Brad Roberts via
Digitalmars-d-learn wrote:
Is there a mechanism for declaring something pure when it's
built from
parts which individually aren't?
string foo(string s)
{
// do something arbitrarily complex with s that doesn't
touch
globals or change global state except possibly state of the
heap or gc
return s;
}
you can cast
Ok, so there essentially isn't. I'm well aware of the risks of
lying to the compiler, but it's also not sufficiently smart to
unravel complex code. Combined with there being interesting
parts of the standard libraries that themselves aren't marked
pure, there's a real need for escape hatches. A simple
example: anything that has a malloc/free pair.
There is
void[] myPureMalloc(uint size) pure @trusted nothrow @nogc
{
alias pure_malloc_t = pure nothrow void* function(size_t size);
return (cast(pure_malloc_t)malloc)(size)[0 .. size];
}
There was a whole discussion or 3 is PRs about making malloc pure, and IIRC,
it was done and then decided that it wasn't safe to do some for one reason
or another (IIRC, it had to do with what would happen when calls were
elided, because the caller was strongly pure, but I'm not sure). So, I'd be
_very_ careful about deciding that it was safe to call malloc in pure code.
I expect that it's just fine in some contexts, but it's easy enough to screw
up and mark something as pure when it really shouldn't be because of some
detail you missed that you should be _really_ careful about decided to cast
to pure.
- Jonathan M Davis
That's one reason I explicitly referenced malloc/free pairs. It's a lot
easier to be sure that those together aren't violating purity.
Re: purity question
On 5/28/2017 6:01 PM, Stefan Koch via Digitalmars-d-learn wrote:
On Monday, 29 May 2017 at 00:53:25 UTC, Brad Roberts wrote:
On 5/28/2017 5:34 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Sunday, May 28, 2017 16:49:16 Brad Roberts via
Digitalmars-d-learn wrote:
Is there a mechanism for declaring something pure when it's built from
parts which individually aren't?
string foo(string s)
{
// do something arbitrarily complex with s that doesn't touch
globals or change global state except possibly state of the heap or gc
return s;
}
you can cast
Ok, so there essentially isn't. I'm well aware of the risks of lying
to the compiler, but it's also not sufficiently smart to unravel
complex code. Combined with there being interesting parts of the
standard libraries that themselves aren't marked pure, there's a real
need for escape hatches. A simple example: anything that has a
malloc/free pair.
There is
void[] myPureMalloc(uint size) pure @trusted nothrow @nogc
{
alias pure_malloc_t = pure nothrow void* function(size_t size);
return (cast(pure_malloc_t)malloc)(size)[0 .. size];
}
That's still a cast. It's a nice way to isolate the cast, but it's
clearly still there. And as I said, that's just one simple example.
Re: purity question
On 5/28/2017 5:34 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
On Sunday, May 28, 2017 16:49:16 Brad Roberts via Digitalmars-d-learn wrote:
Is there a mechanism for declaring something pure when it's built from
parts which individually aren't?
string foo(string s)
{
// do something arbitrarily complex with s that doesn't touch
globals or change global state except possibly state of the heap or gc
return s;
}
you can cast
Ok, so there essentially isn't. I'm well aware of the risks of lying to
the compiler, but it's also not sufficiently smart to unravel complex
code. Combined with there being interesting parts of the standard
libraries that themselves aren't marked pure, there's a real need for
escape hatches. A simple example: anything that has a malloc/free pair.
purity question
Is there a mechanism for declaring something pure when it's built from
parts which individually aren't?
string foo(string s)
{
// do something arbitrarily complex with s that doesn't touch
globals or change global state except possibly state of the heap or gc
return s;
}
Re: spam in bugzilla
I've been marking the accounts as spam and moving the bugs to a specific spam product/category. The last few days have been unusual. If it keeps up, I'll investigate ways of potentially dealing with it better, but I really don't want to add friction to the signup process. It's hard enough to get people to report bugs in general, I don't want to make it harder. On 11/23/2016 11:09 AM, Jonathan M Davis via Digitalmars-d-learn wrote: On Wednesday, November 23, 2016 13:31:45 Steven Schveighoffer via Digitalmars-d-learn wrote: See here: https://issues.dlang.org/show_bug.cgi?id=16737 I don't want to close/change anything, because the guy's email is the reporter, and he'll get any updates. Is there a way to mark something as spam so it gets deleted, and so there are no emails sent to the reporter? If there is, it probably requires Brad to do it. - Jonathan M Davis
Re: Is memory-safe IO possible?
On 1/22/2016 9:10 AM, Chris Wright via Digitalmars-d-learn wrote: On Fri, 22 Jan 2016 08:36:14 +, Kagamin wrote: Should be possible. Why not? Because almost no IO routines in Phobos are marked @safe, which implies that it's difficult in practice or that people simply haven't done it. I checked std.file, std.net.curl, and std.stdio; a handful of things are @safe while the vast majority aren't. I want everything I do to be @safe. Unfortunately, "everything I do" includes IO (and std.json), and while it's not sprinkled throughout my code, the call stack has enough variety that I can't mark very much @safe at the end of the day. At the very least, it would be nice to say: I can't entirely trust some of the code I'm calling, but at least for the code I'm writing here, stop me from doing anything stupid. A @tryToBeSafeIsh, if you will. Correct, the bug isn't that the documentation is missing about why it's not @safe. The bug is that a whole lot of phobos (and druntime) should be @safe but the work hasn't been done to mark it as such. At this point in time, there's not many interesting apps that could mark their main with @safe, which is a real shame.
Re: Calling D from C, C++, Python…
On 9/12/15 9:20 AM, Adam D. Ruppe via Digitalmars-d-learn wrote: On Saturday, 12 September 2015 at 09:47:55 UTC, Jacob Carlborg wrote: Well, if your D function doesn't use anything of the runtime I guess it's not necessary. Right. If you don't call into the threading system in the druntime, you should be ok. Keep in mind though that the GC uses the threads and the new expression, array literals, array append, and others use the GC. Runtime.initialize is also what calls static and module constructors... and might have responsibility for fixing up dynamic casting of class objects in a shared lib too, I'm not sure about that. But if you avoid the bulk of the runtime functions, indeed you can get away without initializing it. Just that null thread handle is likely to cause segfaults in places where you might not expect if you don't. It is best to initialize it. Lots of C libraries need an init an teardown call, so surely the Python interop provides some solution for it. idk what it would be though. I think it's safest to say (and it belongs in the spec somewhere) that executing D code before initializing the runtime results in undefined behavior, or something along those lines. You can get away with it in some circumstances, but it's at your own risk.
Re: Startup files for STM32F4xx
On 4/25/2015 10:02 PM, Timo Sintonen via Digitalmars-d-learn wrote: -Import mess. Phobos files import several other files. Some of them cannot be used. Work is going on to remove unnecessary imports and use scoped imports. It is important that imports for unittests are only in unittest blocks. -All functions have to be nogc. Active work is going on also in this area. The files should just be tried one by one to see if they can be compiled. It's important to note that most of the work occurring on these fronts is use-case driven. Not much is happening for the sake of completeness (except to some degree by Walter). So, your needs where they don't overlap with someone else's needs, might well take a long time to get done unless you do some of the driving. Even tackling the improvement of one or two api's helps drive towards completion.
Re: Valgrind
Valgrind has a mechanism for teaching it how to ignore certain patterns. A long time ago I setup suppressions for the gc, but the code has changed out from under that version so the work would need to be redone. On 4/20/2015 7:23 PM, Martin Nowak via Digitalmars-d-learn wrote: On Monday, 20 April 2015 at 13:28:57 UTC, John Colvin wrote: The only special thing to take in to account is that valgrind will choke on DMD generated floating point code I actually fixed this problem a while ago. https://github.com/D-Programming-Language/dmd/pull/4368 An actual problem with valgrind is the GC, because most of it's operations appear to valgrind as memory corruptions. You can GC.disable() collections, use gcstub.d, or help Vladimir with his valgrind/GC support to make things work. http://dlang.org/phobos/core_memory.html#.GC.disable https://github.com/D-Programming-Language/druntime/blob/master/src/gcstub/gc.d https://github.com/CyberShadow/druntime/commits/valgrind
Re: std.conv.to purity
While snprintf might be one thing that provides to be an interesting
obstacle, the better answer to why std.conv.to isnt pure is that no one
has invested the time to work through issues like that to make it so.
It _should_ be pure.
On 2/14/2015 12:32 PM, ketmar via Digitalmars-d-learn wrote:
On Sat, 14 Feb 2015 19:59:58 +, Gary Willoughby wrote:
On Saturday, 14 February 2015 at 12:24:51 UTC, ketmar wrote:
On Sat, 14 Feb 2015 11:29:28 +, Jack Applegame wrote:
why std.conv.to is not pure?
string foo(real v) pure { return v.to!string; }
// Error: pure function 'foo' cannot call impure function
'std.conv.to!string.to!(real).to'
'cause float-string conversion is damned hard task. to perform this
conversion `to!` falls back to `formatValue` from std.format,
which in turn using `snprintf()` from libc.
Forgive me being a bit dense but that doesn't necessarily mean it's
impure though, right?
yes, you are right, it *may* be pure. yet `snprintf()` can't be marked as
`pure`, so it contaminates everything. and there are no guarantees that
`snprintf()` is pure even for known arguments (compiler can't prove that,
and libc is free to do any funny things in it), so it will be wrong to
just force-reimport it as `pure`.
tl;dr: we need native D float-string converter to allow purity in this
case. you are free to force-hack purity flag on function if you want, but
this can be wrong and may lead to various heisenbugs.
native pure D converter will also allow CTFE, btw, which is impossible
now.
Re: Getting libcurl for 64 bit Windows
The one that the win64 auto-tester uses is here:
http://downloads.dlang.org/other/
curl-7.28.1-devel-rainer.win64.zip
There's a newer one available there, but I can't vouch for it.
On 6/26/14, 11:49 AM, Andrei Alexandrescu via Digitalmars-d-learn wrote:
On 6/26/14, 11:11 AM, Mark Isaacson wrote:
Managed to build it successfully I think, but have actually
returned to the problem that initially caused me to want to try
and build the library in the first place:
If I try to build a simple program:
import std.stdio;
import std.net.curl;
void main() {
writeln(Hello world);
}
The program compiles, but does not print Hello World at
runtime... it just stops, and seemingly does nothing.
Trying to determine the root cause of that now.
Mark is my intern, and we're currently blocked by this in creating an important
demo for tomorrow.
Does anyone have good instructions for building libcurl on Win64, or prebuild
.lib and .dll files?
Thanks very much,
Andrei
