On Tuesday, 4 September 2018 at 09:40:23 UTC, Ecstatic Coder wrote:
> But it seems that the latest version of "std.file.copy" now completely ignores the "PreserveAttributes.no" argument on Windows, which made recent Windows builds of Resync fail on read-only files.
>
> Very typical...
>
> While D remains my favorite file scripting language, I must admit that this is quite disappointing for such an old language, compared to similar languages like Crystal.

Windows can simply be a pain to work with though. Look at Crystal itself, it doesn't support Windows natively as far as I know, so of course you won't have Windows-specific bugs in Crystal...

On Tuesday, 4 September 2018 at 09:56:13 UTC, rikki cattermole wrote:
> On 04/09/2018 9:40 PM, Ecstatic Coder wrote:
>> But it seems that the latest version of "std.file.copy" now completely ignores the "PreserveAttributes.no" argument on Windows, which made recent Windows builds of Resync fail on read-only files.
>
> What???
>
> There is nothing in the changelog between 2.080.0 and 2.082.0 for changes to std.file.
>
> Version from July 2017[0]. Version from 2.082.0[1]. They look the same to me.
>
> [0] https://github.com/dlang/phobos/blob/d8959320e0c47a1861e32bbbf6a3ba30a019798e/std/file.d#L3430
> [1] https://github.com/dlang/phobos/blob/v2.082.0/std/file.d#L4216

Mayb I'm wrong, but what I can say is that I've recently updated DMD and compiled a windows build of Resync, and that I *HAD* to make Windows-specific code that removes the "read-only" attributes only on Windows.

attributes = source_file_path.getAttributes();
source_file_path.getTimes( access_time, modification_time );

version ( Windows )
{
    if ( target_file_path.exists() )
    {
        target_file_path.setAttributes( attributes & ~1 );
    }

    source_file_path.copy( target_file_path, PreserveAttributes.no );
    target_file_path.setAttributes( attributes & ~1 );
    target_file_path.setTimes( access_time, modification_time );
    target_file_path.setAttributes( attributes );
}
else
{
    if ( target_file_path.exists() )
    {
        target_file_path.setAttributes( 511 );
    }

    source_file_path.copy( target_file_path, PreserveAttributes.no );
    target_file_path.setAttributes( attributes );
    target_file_path.setTimes( access_time, modification_time );
}

Honestly I don't see why I have to make this ugly fix on Windows, while the Linux version has always worked fine on read-only files.

On 04/09/2018 10:27 PM, Ecstatic Coder wrote:
> On Tuesday, 4 September 2018 at 09:56:13 UTC, rikki cattermole wrote:
>> On 04/09/2018 9:40 PM, Ecstatic Coder wrote:
>>> But it seems that the latest version of "std.file.copy" now completely ignores the "PreserveAttributes.no" argument on Windows, which made recent Windows builds of Resync fail on read-only files.
>>
>> What???
>>
>> There is nothing in the changelog between 2.080.0 and 2.082.0 for changes to std.file.
>>
>> Version from July 2017[0]. Version from 2.082.0[1]. They look the same to me.
>>
>> [0] https://github.com/dlang/phobos/blob/d8959320e0c47a1861e32bbbf6a3ba30a019798e/std/file.d#L3430 
>>
>> [1] https://github.com/dlang/phobos/blob/v2.082.0/std/file.d#L4216
> 
> Mayb I'm wrong, but what I can say is that I've recently updated DMD and compiled a windows build of Resync, and that I *HAD* to make Windows-specific code that removes the "read-only" attributes only on Windows.
> 
> attributes = source_file_path.getAttributes();
> source_file_path.getTimes( access_time, modification_time );
> 
> version ( Windows )
> {
>      if ( target_file_path.exists() )
>      {
>          target_file_path.setAttributes( attributes & ~1 );
>      }
> 
>      source_file_path.copy( target_file_path, PreserveAttributes.no );
>      target_file_path.setAttributes( attributes & ~1 );
>      target_file_path.setTimes( access_time, modification_time );
>      target_file_path.setAttributes( attributes );
> }
> else
> {
>      if ( target_file_path.exists() )
>      {
>          target_file_path.setAttributes( 511 );
>      }
> 
>      source_file_path.copy( target_file_path, PreserveAttributes.no );
>      target_file_path.setAttributes( attributes );
>      target_file_path.setTimes( access_time, modification_time );
> }
> 
> Honestly I don't see why I have to make this ugly fix on Windows, while the Linux version has always worked fine on read-only files.

Hang on a second.

assert(preserve == Yes.preserveAttributes);

Something is smelling an awful lot here.

Up to Windows 7 CopyFileW which is used for Windows didn't copy the attributes over[0] but it does now.

This is a bug on our end, which should include a fallback to copying manually the file contents over.

[0] https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-copyfilew

On Tuesday, 4 September 2018 at 00:16:16 UTC, Nick Sabalausky (Abscissa) wrote:
> On 09/03/2018 02:55 PM, Joakim wrote:
>> On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M Davis wrote:
>>> But if you're ever expecting IDE support to be a top priority of many of the contributors, then you're going to be sorely disappointed. It's the sort of thing that we care about because we care about D being successful, but it's not the sort of thing that we see any value in whatsoever for ourselves
>> 
>> Why is that? I've never used an IDE much, but I wonder why you don't and what your impressions are of why many other core D users don't either.
>
> I used to use them all the time, but it got too frustratingly difficult to find ones that didn't take forever to start up, and didn't lag like crazy while trying to get my work done.
>
> Plus, I've done so much development on so many platforms that (even if only at the time) didn't have much in the way of either IDE or debugger support (or good support for *my* current IDE and required me to use *their* IDE), that I just learned how to be productive with basic editor + file manager + command line. With those, I can do pretty much anything I need for just about any platform/language.
>
> Whenever I've relied on an IDE, I was constantly dealing with bad support for X in language Z, no support for Y when deving for platform W, trying to do Q was a big series of steps that could NOT be easily automated, etc...It was an endless mess, and trying to add support for XYZ was always a major project in an of itself. And there was ALWAYS something new I needed support for, but couldn't get and didn't have the time to build. It was a series of prisons. Weening myself off IDEs freed me.
>
> I'll tell you, it's REALLY nice being able to get my work done, *improve* my workflow as I see fit(!!), in just about any language I need, for just about any target platform I need, without ever having to whine about "I can't use your tech unless you build better integration with this one particular IDE!" (Sound similar to anything often heard around here? ;))
>
> Plus, plain old non-IDE editors have come a LONG, long way in the last 20 years. (For example, syntax highlighting used to be something you mainly just got with the IDEs. Not anymore!)

I fully understand this. I think most of the IDE users get this. But there is another _fact_of_life_ that some of us (most of us..?) still have to deal with - we don't have a choice in this _at_work_!

We work full-time for employers which, in my case, employs thousands of engineers - and as a result engineering principles are applied to everything - including tools. So all SW dev teams here use standardized tooling/processes/coding standards/etc. - you simply do not have a choice to use your own editor of choice.

In my case it is C++ and C# on Visual Studio Professional, in other teams (say web based portals/etc) it is maybe Java on eclipse, etc.

In my team we often still have to do support/bug fixes/upgrades on legacy projects from people that are not even working here anymore. Most of the time migrating a complex project to your favorite IDE/editor/build system/whatever is simply not an option.

Nick - I suspect you work for yourself or on occasion as a contractor in different environments (and for  different customers) - so this is perfectly OK for you to have that view and opinion. But please be aware it is not the full story for others!

I don't get to use D at work so am strictly a D 'hobbyist' at home. So at home I can play with D and for some other toys (Raspberry-Pi!) and can use Sublime Text3 or cross compile C++ using Codeblocks or any other editor of my choice. (I just never made the jump to Vim/Emacs). But the same choices are not available at work.

I really miss the appreciation of this fact in these incessant 'use Vim/Emacs' answers to people's queries on IDE support is the forum. This is not the reality for many people at work - this article [1] describes the reason why businesses prefer IDE's quite nicely.

Most of my colleagues are not interested in hobby coding at home - they consider their family life separate to their professional lives - and that is perfectly OK. It is their choice. But it makes it impossible for people like me to even try to push their managers to "try D" if it does not fit into the workflow/processes that are already followed. For me (like for Manu [2]) this absolutely necessitates that it supports Visual Studio integration _out_of_the_box_!

When I read answers like yours and Jonathan's it always makes me wonder: does D want to cater for the kind of businesses I describe as well? If not, ok - that is a perfectly valid answer and D can, as a consequence remain the slightly obscure language it has been up to now - used by enthusiasts that are willing to go the extra mile to get stuff done, and can hack around any limitation. That is perfectly fine.

But if the D community want to achieve the big critical-mass breakthrough into mainstream programming with lots of commercial customers I suspect that Manu's views [2] need to be realized and the tooling need to be on par than what Java/C# devs are used to.

I know the "we use Vim/Emacs, why don't you pitch in and help on VisualD if you want to use it" view is valid opinion, but it will not bring the masses since it will never happen - the critical mass is composed of devs that want to _use_ VS/eclipse/etc - not _develop_ to enable them. Besides, they are not coding at home, and there is very little incentive for said enterprises to assist with this - they see it simply as a cost if D does not offer sufficient benefit over C#/java/etc. So this is not going to happen except as an effort inside the D community itself.

[1] https://codecraft.co/2014/05/13/why-you-should-use-an-ide-instead-of-vim-or-emacs/
[2] https://forum.dlang.org/post/mailman.3572.1536035692.29801.digitalmars-d@puremagic.com

On Tuesday, 4 September 2018 at 01:36:53 UTC, Mike Parker wrote:
> On Monday, 3 September 2018 at 18:26:57 UTC, Chris wrote:
>
> And of course, low manpower and funding aren't the complete picture. Management also play a role. Both Walter and Andrei have freely admitted they are not managers and that they're learning as they go. Mistakes have been made. In hindsight, some decisions should have gone a different way. But that is not the same as not caring, or not understanding/
>
> So please, don't attribute any disingenuous motives to any of the core team members. They all want D to succeed. Identifying core problems and discussing ways to solve them is a more productive way to spend our bandwidth.

I think D's 'core' problem, is that it's trying to compete with, what are now, widely used, powerful, and well supported languages, with sophisticate ecosystems in place already. C/C++/Java/C# .. just for beginners.

Then it's also trying to compete with startup languages (Go, Rust ....) - and some of those languages have billion dollar organisations behind them, not to mention the talent levels of their *many* designers and contributors.

C++ is much more than just a langauge. It's an established, international treaty on what the language must be.

Java is backed by Oracle (one the of the largest organisations in the world).

Go is backed by Google...Rust by Mozilla...(both billion dollar global companies).

So one has to wonder, what would motivate a person (or an organisation) to focus their attention on D.

That is not a statement about the quality of D. It's a statement about the competitive nature of programming languages.

If you've ever read 'No Contest - the case against competition' by Alfie Kohn, then you'd know (or at least you might agree with that statement) that competition  is not an inevitable part of human nature. "It warps recreation by turning the playing into a battlefield."

I wonder has already happened to D.

D should, perhaps, focus on being a place for recreation, where one can focus on technical excellence, instead of trying to compete in the battlefield.

I just do not see, how D can even defeat its' major competitors.

Instead D could be a place where those competitors come to look for great ideas (which, as I understand it, does occur .. ranges for example).

In any case, you have to work out what it is, that is going to motivate people to focus their attention on D.

You seem to be saying that, raising money so you can pay people, is enough.

But I wonder about that.

On Tuesday, 4 September 2018 at 13:34:03 UTC, TheSixMillionDollarMan wrote:
> On Tuesday, 4 September 2018 at 01:36:53 UTC, Mike Parker wrote:
>> On Monday, 3 September 2018 at 18:26:57 UTC, Chris wrote:
>>
>> And of course, low manpower and funding aren't the complete picture. Management also play a role. Both Walter and Andrei have freely admitted they are not managers and that they're learning as they go. Mistakes have been made. In hindsight, some decisions should have gone a different way. But that is not the same as not caring, or not understanding/
>>
>> So please, don't attribute any disingenuous motives to any of the core team members. They all want D to succeed. Identifying core problems and discussing ways to solve them is a more productive way to spend our bandwidth.
>
> I think D's 'core' problem, is that it's trying to compete with, what are now, widely used, powerful, and well supported languages, with sophisticate ecosystems in place already. C/C++/Java/C# .. just for beginners.
>
> Then it's also trying to compete with startup languages (Go, Rust ....) - and some of those languages have billion dollar organisations behind them, not to mention the talent levels of their *many* designers and contributors.
>
> C++ is much more than just a langauge. It's an established, international treaty on what the language must be.
>
> Java is backed by Oracle (one the of the largest organisations in the world).
>
> Go is backed by Google...Rust by Mozilla...(both billion dollar global companies).
>
> So one has to wonder, what would motivate a person (or an organisation) to focus their attention on D.
>
> That is not a statement about the quality of D. It's a statement about the competitive nature of programming languages.
>
> If you've ever read 'No Contest - the case against competition' by Alfie Kohn, then you'd know (or at least you might agree with that statement) that competition  is not an inevitable part of human nature. "It warps recreation by turning the playing into a battlefield."
>
> I wonder has already happened to D.
>
> D should, perhaps, focus on being a place for recreation, where one can focus on technical excellence, instead of trying to compete in the battlefield.
>
> I just do not see, how D can even defeat its' major competitors.
>
> Instead D could be a place where those competitors come to look for great ideas (which, as I understand it, does occur .. ranges for example).
>
> In any case, you have to work out what it is, that is going to motivate people to focus their attention on D.
>
> You seem to be saying that, raising money so you can pay people, is enough.
>
> But I wonder about that.

That's a good question, let me see if I can answer it.

Do you know what the first search engine for the web was and when it was created? It wasn't Yahoo, google, or Bing:

https://en.m.wikipedia.org/wiki/Web_search_engine#History

The first search engines were created in 1993, google came along in 1998 after at least two dozen others in that list, and didn't make a profit till 2001. Some of those early competitors were giant "billion dollar global companies," yet it's google that dominates the web search engine market today.

Why is that? Well, for one, resources don't matter for software on the internet as much as ideas. It's not that resources don't matter, but that they take a back seat to your fundamental design and the ideas behind it.

And coming up with that design and ideas takes time, the "developmental stage" that Laeeth refers to above. In that incubation stage, you're better off _not_ having a bunch of normal users who want a highly polished product, just a bunch of early adopters who can give you good feedback and are okay with rough edges. For D, that means all the advanced features don't fully play together well yet, and there are various bugs here and there. To use it, you have to be okay with that.

Now, it's a fair question to ask when D will leave that developmental stage and get more resources towards that polish, as Chris asks, and I'm not saying I know the answers to those questions. And let me be clear: as long as you don't push the envelope with mixing those advanced D features and are okay working around some bugs here and there, you're probably good now.

But simply asserting that others are rushing full-speed ahead with more resources and therefore they will win completely misunderstands how the game has changed online. Resources do matter, but they're not the dominant factor like they used to be for armies or manufacturing. Ideas are now the dominant factor, and D has plenty of those. ;)

On Tuesday, 4 September 2018 at 14:23:33 UTC, Joakim wrote:
> The first search engines were created in 1993, google came along in 1998 after at least two dozen others in that list, and didn't make a profit till 2001. Some of those early competitors were giant "billion dollar global companies," yet it's google that dominates the web search engine market today.
>
> Why is that? Well, for one, resources don't matter for software on the internet as much as ideas. It's not that resources don't matter, but that they take a back seat to your fundamental design and the ideas behind it.

Google had a $100k angel round in 1998 and a $25 million Series A in 1999. The difference between Google and the $12 billion-ish valued Lycos of the time was not insurmountable, yes, but $25 million was enough to hire dozens of developers, lease offices, and buy the hardware they needed.

Similarly, we don't need Google-level funding to produce a developer ecosystem that's sufficiently polished not to be a blocker for corporate VS-only types who rely on autocomplete. But we need a bit more than $4k for that, or it's always going to be someone's personal project that's mostly complete but might be abandoned in six months.

> The first search engines were created in 1993, google came along in 1998 after at least two dozen others in that list, and didn't make a profit till 2001. Some of those early competitors were giant "billion dollar global companies," yet it's google that dominates the web search engine market today.
>
> Why is that?

Their original page-rank algorithm. Basically, they found an efficient way of emulating random clicks to all outgoing links from a page and thus got better search result rankings.

It was a matter of timing.

On Tue, 04 Sep 2018 11:56:54 +0000, ShadoLight wrote:

> I know the "we use Vim/Emacs, why don't you pitch in and help on VisualD
> if you want to use it" view is valid opinion, but it will not bring the
> masses since it will never happen - the critical mass is composed of
> devs that want to _use_ VS/eclipse/etc - not _develop_ to enable them.
> Besides, they are not coding at home,
> and there is very little incentive for said enterprises to assist with
> this - they see it simply as a cost if D does not offer sufficient
> benefit over C#/java/etc. So this is not going to happen except as an
> effort inside the D community itself.

I would be surprised if VisualD isn't on the D foundation's list (see [1]). They just have other things that (right or wrong) are higher priority right now.

And Rainer Schuetze has been making major improvements, both to VisualD and to D on Windows in general. It is getting better.[2]

Until there's money on VisualD's development, this constant back and forth isn't going to change much. People that don't use VisualD aren't likely to work on it, and won't be able to test their work if they do. It really is going to take people who use it and decide it's worth improving.

--Ryan


[1]: https://dlang.org/blog/2018/07/13/funding-code-d/

[2]: I was going to add "just at the pace of one person's spare time," then realized he's actually offering much better support than a well-known vendor I've spent $10,000+ with on one of my major problems...

On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote:
> On Friday, August 24, 2018 6:05:40 AM MDT Mike Franklin via Digitalmars-d wrote:
>> > You're basically trying to bypass the OS' public API if you're trying to bypass libc.
>>
>> No I'm trying to bypass libc and use the OS API directly.
>
> And my point is that most OSes consider libc to be their OS API (Linux doesn't, but it's very much abnormal in that respect).

Well, it used to be the case that it was normal to call OS directly by using traps, but since the context switch is so expensive on modern CPUs we a have a situation where the calling stub is a fraction of the calling cost these days. Thus most don't bother with it.

What usually can happen if you don't use the c-stubs with dynamic linkage is that your precompiled program won't work with new versions of the OS. But that can also happen with static linkage.

> Trying to bypass it means reimplementing core OS functionality and risking all of the bugs that go with it.

It is the right thing to do for a low level language. Why have libc as a dependency if you want to enable hardware oriented programming? Using existing libraries also put limits on low level language semantics.

> If you're talking about avoiding libc functions like strcmp that's one thing, but if you're talking about reimplementing stuff that uses syscalls, then honestly, I think that you're crazy.

No it isn't a crazy position, why the hostile tone? Libc isn't available in many settings. Not even in webassembly.