On 09/22/2018 04:46 PM, Jonathan Marler wrote:
Decided to play around with this for a bit. Made a "proof of concept"
library:
https://github.com/marler8997/longfiles
It's just a prototype/exploration on the topic. It allows you to
include "stdx.longfiles" instead
On Saturday, 22 September 2018 at 21:04:04 UTC, Vladimir
Panteleev wrote:
On Saturday, 22 September 2018 at 20:46:27 UTC, Jonathan Marler
wrote:
Decided to play around with this for a bit. Made a "proof of
concept" library:
I suggest using GetFullPathNameW instead of GetCurrentDirectory
+ ma
On Saturday, 22 September 2018 at 20:46:27 UTC, Jonathan Marler
wrote:
Decided to play around with this for a bit. Made a "proof of
concept" library:
I suggest using GetFullPathNameW instead of GetCurrentDirectory +
manual path appending / normalization. It's also what CoreFX
seems to be doi
access
the Win32 APIs directly.
Decided to play around with this for a bit. Made a "proof of
concept" library:
https://github.com/marler8997/longfiles
It's just a prototype/exploration on the topic. It allows you to
include "stdx.longfiles" instead of &
On Thursday, 20 September 2018 at 19:49:01 UTC, Nick Sabalausky
(Abscissa) wrote:
On 09/19/2018 11:45 PM, Vladimir Panteleev wrote:
On Thursday, 20 September 2018 at 03:23:36 UTC, Nick
Sabalausky (Abscissa) wrote:
(Not on a Win box at the moment.)
I added the output of my test program to the
On 09/19/2018 11:27 PM, Vladimir Panteleev wrote:
On Thursday, 20 September 2018 at 03:25:05 UTC, Nick Sabalausky
(Abscissa) wrote:
On 09/19/2018 11:23 PM, Nick Sabalausky (Abscissa) wrote:
rmdir(path);
Obviously meant "rmdir(dir);" here. Editing mishap.
and MAX_PATH instead of MAX_LENGTH,
On 09/19/2018 11:45 PM, Vladimir Panteleev wrote:
On Thursday, 20 September 2018 at 03:23:36 UTC, Nick Sabalausky
(Abscissa) wrote:
(Not on a Win box at the moment.)
I added the output of my test program to the gist:
https://gist.github.com/CyberShadow/049cf06f4ec31b205dde4b0e3c12a986#file-out
On Thu, Sep 20, 2018 at 03:45:07AM +, Vladimir Panteleev via Digitalmars-d
wrote:
[...]
> Actually it's crazier than that. The concatenation of the current
> directory plus the relative path must be < MAX_PATH (approx.).
> Meaning, if you are 50 directories deep, a relative path starting with
On 09/20/2018 03:59 AM, Nick Sabalausky (Abscissa) wrote:
On 09/19/2018 11:15 PM, Vladimir Panteleev wrote:
When the OS itself fails to properly deal with such files, I don't
think D has any business in *facilitating* their creation by default.
I used to be a pure Windows user for a long,
On 09/19/2018 11:15 PM, Vladimir Panteleev wrote:
On Wednesday, 19 September 2018 at 06:11:22 UTC, Vladimir Panteleev wrote:
One point of view is that the expected behavior is that the functions
succeed. Another point of view is that Phobos should not allow
programs to create files and director
On 09/20/2018 03:38 AM, Kagamin wrote:
On Thursday, 20 September 2018 at 02:48:06 UTC, Nick Sabalausky
(Abscissa) wrote:
What drives me mad is when allegedly cross-platform tools deliberately
propagate non-cross-platform quirks that could easily be abstracted
away and pretend that's somehow "he
On Thursday, 20 September 2018 at 02:48:06 UTC, Nick Sabalausky
(Abscissa) wrote:
What drives me mad is when allegedly cross-platform tools
deliberately propagate non-cross-platform quirks that could
easily be abstracted away and pretend that's somehow "helping"
me instead of making a complete
On Thursday, 20 September 2018 at 03:15:20 UTC, Vladimir
Panteleev wrote:
On Wednesday, 19 September 2018 at 06:11:22 UTC, Vladimir
Panteleev wrote:
One point of view is that the expected behavior is that the
functions succeed. Another point of view is that Phobos should
not allow programs to c
On Thursday, 20 September 2018 at 02:48:06 UTC, Nick Sabalausky
(Abscissa) wrote:
On 09/19/2018 02:33 AM, Jonathan Marler wrote:
What drives me mad is when you have library writers who try to
"protect" you from the underlying system by translating
everything you do into what they "think" you'
On Thursday, 20 September 2018 at 03:23:36 UTC, Nick Sabalausky
(Abscissa) wrote:
(Not on a Win box at the moment.)
I added the output of my test program to the gist:
https://gist.github.com/CyberShadow/049cf06f4ec31b205dde4b0e3c12a986#file-output-txt
assert( dir.toAbsolutePath.length > MAX_L
On Thursday, 20 September 2018 at 03:15:20 UTC, Vladimir
Panteleev wrote:
When the OS itself fails to properly deal with such files, I
don't think D has any business in *facilitating* their creation
by default.
Dear lord Windows is terrible. Can we just deprecate it?
On Thursday, 20 September 2018 at 03:23:36 UTC, Nick Sabalausky
(Abscissa) wrote:
I'm not sure I'm quite following you. Is this what you mean?:
string dir = ...; // Such that...
assert( dir.isRelativePath );
assert( dir.length < MAX_LENGTH-12 );
assert( dir.toAbsolutePath.length > MAX_LENGTH-12
On 09/19/2018 11:23 PM, Nick Sabalausky (Abscissa) wrote:
rmdir(path);
Obviously meant "rmdir(dir);" here. Editing mishap.
On Thursday, 20 September 2018 at 03:25:05 UTC, Nick Sabalausky
(Abscissa) wrote:
On 09/19/2018 11:23 PM, Nick Sabalausky (Abscissa) wrote:
rmdir(path);
Obviously meant "rmdir(dir);" here. Editing mishap.
and MAX_PATH instead of MAX_LENGTH, and absolutePath instead of
toAbsolutePath, and !
On 09/19/2018 07:04 AM, Vladimir Panteleev wrote:
On Wednesday, 19 September 2018 at 05:49:41 UTC, Nick Sabalausky
(Abscissa) wrote:
2. Detect and reject any non-\\?\ path longer than MAX_PATH-12 bytes[5].
This is not a good criteria: relative paths whose pointing to objects
whose absolute pa
On Wednesday, 19 September 2018 at 06:11:22 UTC, Vladimir
Panteleev wrote:
One point of view is that the expected behavior is that the
functions succeed. Another point of view is that Phobos should
not allow programs to create files and directories with invalid
paths. Consider, e.g. that a user
On 09/19/2018 01:49 PM, Neia Neutuladh wrote:
On Wednesday, 19 September 2018 at 08:54:42 UTC, Vladimir Panteleev wrote:
BTW, something follows from the above:
write(`C:\` ~ (short path) ~ `con`) will fail
but:
write(`C:\` ~ (long path) ~ `con`) will succeed.
This is just one issue I've not
On 09/19/2018 02:33 AM, Jonathan Marler wrote:
What drives me mad is when you have library writers
who try to "protect" you from the underlying system by translating
everything you do into what they "think" you're trying to do.
What drives me mad is when allegedly cross-platform tools delibe
On Wednesday, 19 September 2018 at 08:54:42 UTC, Vladimir
Panteleev wrote:
BTW, something follows from the above:
write(`C:\` ~ (short path) ~ `con`) will fail
but:
write(`C:\` ~ (long path) ~ `con`) will succeed.
This is just one issue I've noticed... there's probably more
lurking.
Also,
On Wednesday, 19 September 2018 at 08:13:31 UTC, Ecstatic Coder
wrote:
On Wednesday, 19 September 2018 at 05:32:47 UTC, Vladimir
Panteleev wrote:
On Wednesday, 19 September 2018 at 05:24:24 UTC, Ecstatic
Coder wrote:
None would ever be, considering you obviously have decided to
ignore such a si
On Wednesday, 19 September 2018 at 09:58:00 UTC, Vladimir
Panteleev wrote:
On my Windows VM, I get:
C:\(long path here): The filename or extension is too long.
(error 206)
This seems like a completely reasonable error message to me, so
I think we're good there already.
It can be a long fil
On Wednesday, 19 September 2018 at 10:29:11 UTC, Vladimir
Panteleev wrote:
- GetFullPathName is documented as also having the MAX_PATH
limit, but the framework seems to use it for normalization
BEFORE prepending the prefix.
https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fil
On Wednesday, 19 September 2018 at 11:04:13 UTC, Vladimir
Panteleev wrote:
On Wednesday, 19 September 2018 at 05:49:41 UTC, Nick
Sabalausky (Abscissa) wrote:
2. Detect and reject any non-\\?\ path longer than MAX_PATH-12
bytes[5].
This is not a good criteria: relative paths whose pointing to
On Wednesday, 19 September 2018 at 05:49:41 UTC, Nick Sabalausky
(Abscissa) wrote:
2. Detect and reject any non-\\?\ path longer than MAX_PATH-12
bytes[5].
This is not a good criteria: relative paths whose pointing to
objects whose absolute path exceeds MAX_PATH will fail, too. So,
it looks l
On Wednesday, 19 September 2018 at 09:27:29 UTC, Vladimir
Panteleev wrote:
This might be a change which we won't be able to back out of if
it turns out to be a bad idea, because then we break other
classes of programs that depend on this change. See
https://forum.dlang.org/post/eepblrtjmqzbtopy
On Wednesday, 19 September 2018 at 09:58:30 UTC, Kagamin wrote:
On Wednesday, 19 September 2018 at 06:26:21 UTC, Vladimir
Panteleev wrote:
Someone mentioned in this thread that .NET runtime does do the
long-path workaround automatically.
AFAIK, CoreFX does, but .net doesn't. .net did its own p
On Wednesday, 19 September 2018 at 06:26:21 UTC, Vladimir
Panteleev wrote:
Someone mentioned in this thread that .NET runtime does do the
long-path workaround automatically.
AFAIK, CoreFX does, but .net doesn't. .net did its own path
normalization and length check, which can be turned off sinc
On Wednesday, 19 September 2018 at 08:18:38 UTC, Nick Sabalausky
(Abscissa) wrote:
Instead, what it really means is that our APIs should be
designed to *REJECT* long paths with an appropriately
meaningful error message
On my Windows VM, I get:
C:\(long path here): The filename or extension is
On Wednesday, 19 September 2018 at 09:16:30 UTC, Nick Sabalausky
(Abscissa) wrote:
Essentially they boil down to "it is impossible to prove the
algorithm is correct" (for both detecting when the path fix is
needed, and fixing the path).
If you're referring to the inability to deterministically
On 09/19/2018 04:41 AM, Vladimir Panteleev wrote:
On Wednesday, 19 September 2018 at 08:37:17 UTC, Nick Sabalausky
(Abscissa) wrote:
What's the other issue(s)?
Essentially they boil down to "it is impossible to prove the algorithm
is correct" (for both detecting when the path fix is needed, a
On Wednesday, 19 September 2018 at 08:46:13 UTC, Vladimir
Panteleev wrote:
On Wednesday, 19 September 2018 at 08:36:35 UTC, Vladimir
Panteleev wrote:
If you're referring to NUL, COM1, COM2, etc, then this is
completely orthogonal.
Yes. How so? It is the same issue: paths with certain
properti
On Wednesday, 19 September 2018 at 08:36:35 UTC, Vladimir
Panteleev wrote:
If you're referring to NUL, COM1, COM2, etc, then this is
completely orthogonal.
Yes. How so? It is the same issue: paths with certain
properties are valid on all platforms except on Windows. Phobos
errors out when att
On Wednesday, 19 September 2018 at 08:37:17 UTC, Nick Sabalausky
(Abscissa) wrote:
What's the other issue(s)?
Essentially they boil down to "it is impossible to prove the
algorithm is correct" (for both detecting when the path fix is
needed, and fixing the path). Forcing the path transformati
On 09/19/2018 02:55 AM, Vladimir Panteleev wrote:
On Wednesday, 19 September 2018 at 06:34:33 UTC, Nick Sabalausky
(Abscissa) wrote:
- Does it actually, necessarily perform those additional OS calls?
We need to expand relative paths to absolute ones, for which we need to
fetch the current dir
s, it's Microsoft's fault.
You cannot evaluate any intrinsic merit here because the result
is beyond your control.
If one extra OS API call + allocation per std.file API call is
unacceptable, then explain how it is unacceptable. I disagree
that it is significant enough to be unacceptabl
They are certainly going to be less expensive that actual
filesystem operations that hit the physical disk, but it will
still be an unwanted overhead in 99.9% of cases.
In any case, the overhead is only one issue.
Seriously, checking the file path string *length* is above 260
characters to s
l the matter of overhead (one OS API call
(GetCurrentDirectory) and at least one GC allocation (for the current
directory buffer)).
If one extra OS API call + allocation per std.file API call is
unacceptable, then explain how it is unacceptable. I disagree that it is
significant enough to be unacc
On Wednesday, 19 September 2018 at 05:32:47 UTC, Vladimir
Panteleev wrote:
On Wednesday, 19 September 2018 at 05:24:24 UTC, Ecstatic Coder
wrote:
None would ever be, considering you obviously have decided to
ignore such a simple solution to the 260 character limit...
Add "ad hominem" to your p
On Wednesday, 19 September 2018 at 06:34:33 UTC, Nick Sabalausky
(Abscissa) wrote:
- Does it actually, necessarily perform those additional OS
calls?
We need to expand relative paths to absolute ones, for which we
need to fetch the current directory.
- Is it really?
Is what really what? I
mple of encapsulation, the
filesystem library should be it's own component with the windows
filesystem workaround being an optional "add-on" that the
filesystem library doesn't need to know about. This workaround
could look like an extra function in phobos...or you could even
write a module that wraps std.file and does the translation on a
per-call basis.
On 09/19/2018 12:04 AM, Vladimir Panteleev wrote:
On Wednesday, 19 September 2018 at 01:50:54 UTC, Nick Sabalausky
(Abscissa) wrote:
And at least for me, moving from Windows to Linux would have been a
LOT harder if it weren't for the OS abstractions that are already in
Phobos.
It's one thing
On Wednesday, 19 September 2018 at 06:16:21 UTC, Paolo Invernizzi
wrote:
On Wednesday, 19 September 2018 at 06:05:38 UTC, Vladimir
Panteleev wrote:
Operating on paths longer than MAX_PATH is not a typical
situation.
https://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/1499/
On Wednesday, 19 September 2018 at 05:49:41 UTC, Nick Sabalausky
(Abscissa) wrote:
[...]
Someone mentioned in this thread that .NET runtime does do the
long-path workaround automatically. One thing we could do is copy
EXACTLY what C# is doing.
The rationale being that:
- .NET is made by Mic
On Wednesday, 19 September 2018 at 06:05:38 UTC, Vladimir
Panteleev wrote:
Operating on paths longer than MAX_PATH is not a typical
situation.
https://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/1499/
The worst situation was node.js on Windows, anyway...
On Wednesday, 19 September 2018 at 06:05:38 UTC, Vladimir
Panteleev wrote:
[...]
One more thing:
There is the argument that the expected behavior of Phobos
functions creating filesystems objects with long paths is to
succeed and create those files. However, this results in
filesystem object
On Wednesday, 19 September 2018 at 05:49:41 UTC, Nick Sabalausky
(Abscissa) wrote:
This actually leads to an interesting point. Let's change gears
for a moment to "API Design Theory"...
Suppose you implement API function X which takes Y as an
argument. Question: Should X accept values (or type
On 09/17/2018 11:27 AM, Patrick Schluter wrote:
On Monday, 17 September 2018 at 12:37:13 UTC, Temtaime wrote:
It's problem with phobos.
It should be able handle all the paths whatever length they have, on
all the platforms without noising the user.
Even with performance penalty, but it shoul
On Wednesday, 19 September 2018 at 05:24:24 UTC, Ecstatic Coder
wrote:
None would ever be, considering you obviously have decided to
ignore such a simple solution to the 260 character limit...
Add "ad hominem" to your pile of fallacies, I guess. I've
addressed it twice in this thread already -
Do the PS2, GameCube and Xbox filesystems all have identical
file path limits?
Guess ;)
And, did any of the paths in your game exceed 260 characters in
length?
No. But the suggested GetPhysicalPath() solution would also work
equally well in this case.
These comparisons are not helpful.
On Tuesday, 18 September 2018 at 18:04:19 UTC, Ecstatic Coder
wrote:
There will always be inherent differences between platforms,
because they are wildly different.
Right.
Technically the PS2 console, the GameCube and the Xbox console
were very different from each other, so I had no choice bu
On Wednesday, 19 September 2018 at 01:50:54 UTC, Nick Sabalausky
(Abscissa) wrote:
And at least for me, moving from Windows to Linux would have
been a LOT harder if it weren't for the OS abstractions that
are already in Phobos.
It's one thing to call unlink on POSIX and RemoveFileW on
Windows
On Wednesday, 19 September 2018 at 02:20:45 UTC, Nick Sabalausky
(Abscissa) wrote:
3. Building on what Vladimir and Jay have said in the bug
report, I propose we do this:
This has been proposed before in this thread. I don't think it's
a good idea:
https://forum.dlang.org/post/bqsjebjxuljlqu
On 09/18/2018 09:46 PM, Jonathan M Davis wrote:
On Tuesday, September 18, 2018 7:28:43 PM MDT Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
It's worth noting that the discussion made it very clear that Walter's
viewpoint on the matter was based on his own misunderstanding (ie,
mistakenly
On 09/15/2018 06:40 AM, Vladimir Panteleev wrote:
On Saturday, 15 September 2018 at 10:05:26 UTC, Josphe Brigmo wrote:
Also, windows 10 does not have this problem
What do you mean by "windows 10"? Do you mean Explorer, the default file
manager?
According to MS docs:
"Starting in Windows
On Tuesday, September 18, 2018 7:28:43 PM MDT Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
> On 09/15/2018 08:14 PM, Jonathan M Davis wrote:
> > The issue was reported in bugzilla quite some time ago.
> >
> > https://issues.dlang.org/show_bug.cgi?id=8967
> >
> > However, while Walter's resp
On 09/15/2018 08:14 PM, Jonathan M Davis wrote:
The issue was reported in bugzilla quite some time ago.
https://issues.dlang.org/show_bug.cgi?id=8967
However, while Walter's response on it basically indicates that we should
just close it as "won't fix," we never actually did
It's worth notin
On 09/18/2018 05:25 AM, Vladimir Panteleev wrote:
On Tuesday, 18 September 2018 at 06:16:50 UTC, Ecstatic Coder wrote:
I expect that calling the function F on system X will work the same as
calling that same function on system Y.
You ask for the impossible.
I think it's safe to assume a ".
On 09/18/2018 06:14 PM, Bastiaan Veelo wrote:
On Tuesday, 18 September 2018 at 19:57:09 UTC, Nick Sabalausky
(Abscissa) wrote:
Yes, the OP needs to file a bug report (and if he's already done so,
then please post a link here for our reference).
It’s an old issue, and the OP posted the link a b
On Tuesday, 18 September 2018 at 19:57:09 UTC, Nick Sabalausky
(Abscissa) wrote:
Yes, the OP needs to file a bug report (and if he's already
done so, then please post a link here for our reference).
It’s an old issue, and the OP posted the link a bit further up in
this thread:
https://forum.d
On Tuesday, 18 September 2018 at 19:33:00 UTC, Nick Sabalausky
(Abscissa) wrote:
On 09/15/2018 09:54 AM, tide wrote:
On Friday, 14 September 2018 at 19:17:58 UTC, bachmeier wrote:
On Friday, 14 September 2018 at 19:06:14 UTC, Josphe Brigmo
wrote:
For very long file names it is broke and every c
On 09/15/2018 08:09 PM, Vladimir Panteleev wrote:
On Saturday, 15 September 2018 at 23:50:43 UTC, Josphe Brigmo wrote:
[...]
D is generally described as a system programming language. There is
value in favoring a simple and obvious implementation ("do what I say")
over going out of one's way
On 09/15/2018 09:54 AM, tide wrote:
On Friday, 14 September 2018 at 19:17:58 UTC, bachmeier wrote:
On Friday, 14 September 2018 at 19:06:14 UTC, Josphe Brigmo wrote:
For very long file names it is broke and every command fails. These
paths are not all that long but over 256 limit. (For windows)
There will always be inherent differences between platforms,
because they are wildly different.
Right.
Technically the PS2 console, the GameCube and the Xbox console
were very different from each other, so I had no choice but to
implement low-level abstraction function (GetPhysicalPath() etc)
F on system X will work the
same as calling that same function on system Y.
You ask for the impossible.
How do you expect the following to "work the same" across all
platforms:
import std.stdio;
import std.file;
auto fn = "a.txt";
On Tuesday, 18 September 2018 at 06:16:50 UTC, Ecstatic Coder
wrote:
I expect that calling the function F on system X will work the
same as calling that same function on system Y.
That's the contract in cross-platform programming.
Heh, I remember working around a filesystem that doesn't suppo
plain to
Microsoft. The OS should not allow users to create or select
paths that programs cannot operate on without jumping through
crazy hoops.
Not that crazy, you can get the actual absolutePath with one of
the OS functions. It isn't that difficult of a workaround.
"
ersion.
>
> https://github.com/dlang/phobos/blob/master/std/file.d#L1047
It doesn't matter, the fact is that something in phobos is
broke. Do you really expect me to do all the work? The fact
that using executeShell or "\\?\" solves 90% of the
problems(maybe all of them) pr
On Monday, 17 September 2018 at 22:58:46 UTC, tide wrote:
version(Windows)
{
if(path.length >= MAX_PATH)
{
// throw Exception(...) // effectively what happens now
// do workaround for
}
}
The complexity would only exist for those that need it. It'd be
the difference
On Sunday, 16 September 2018 at 22:40:45 UTC, Vladimir Panteleev
wrote:
On Sunday, 16 September 2018 at 16:17:21 UTC, tide wrote:
Nothing is "locked behind management". If you feel that some
issue important to you is stalled, you can create a forum
thread, or email Walter/Andrei to ask for a re
On 09/15/2018 06:57 AM, Josphe Brigmo wrote:
You are missing the point, MAX_PATH is more than just phobos. It's built
in to the windows design. Windows enforces it.
All ansi api calls are limited by MAX_PATH.
The way to fix it is to use the wide api calls which are not limited or
to use oth
On Monday, 17 September 2018 at 12:37:13 UTC, Temtaime wrote:
On Sunday, 16 September 2018 at 22:49:26 UTC, Vladimir
Panteleev wrote:
To elaborate:
On Sunday, 16 September 2018 at 22:40:45 UTC, Vladimir
Panteleev wrote:
If *YOU* are OK with the consequences of complexity,
implement this in YO
On Sunday, 16 September 2018 at 22:49:26 UTC, Vladimir Panteleev
wrote:
To elaborate:
On Sunday, 16 September 2018 at 22:40:45 UTC, Vladimir
Panteleev wrote:
If *YOU* are OK with the consequences of complexity, implement
this in YOUR code, but do not enforce it upon others.
This is much bett
To elaborate:
On Sunday, 16 September 2018 at 22:40:45 UTC, Vladimir Panteleev
wrote:
If *YOU* are OK with the consequences of complexity, implement
this in YOUR code, but do not enforce it upon others.
This is much better done in user code anyway, because you only
need to expand / normalize
On Sunday, 16 September 2018 at 16:17:21 UTC, tide wrote:
Nothing is "locked behind management". If you feel that some
issue important to you is stalled, you can create a forum
thread, or email Walter/Andrei to ask for a resolution.
Funny the other guy was saying to create a bugzilla issue.
On Sunday, 16 September 2018 at 03:19:12 UTC, Vladimir Panteleev
wrote:
On Sunday, 16 September 2018 at 02:58:30 UTC, tide wrote:
There are a lot of issues that aren't simple bugs that just
anyone can fix. They are issues that are locked behind
management. One's that are 4 years old for example
On Sunday, 16 September 2018 at 03:19:12 UTC, Vladimir Panteleev
wrote:
On Sunday, 16 September 2018 at 02:58:30 UTC, tide wrote:
There are a lot of issues that aren't simple bugs that just
anyone can fix. They are issues that are locked behind
management. One's that are 4 years old for example
On Sunday, 16 September 2018 at 03:19:12 UTC, Vladimir Panteleev
wrote:
On Sunday, 16 September 2018 at 02:58:30 UTC, tide wrote:
There are a lot of issues that aren't simple bugs that just
anyone can fix. They are issues that are locked behind
management. One's that are 4 years old for example
On Sunday, 16 September 2018 at 02:58:30 UTC, tide wrote:
There are a lot of issues that aren't simple bugs that just
anyone can fix. They are issues that are locked behind
management. One's that are 4 years old for example, they are
probably some bug locked behind management. That's why they g
On Sunday, 16 September 2018 at 01:33:52 UTC, Vladimir Panteleev
wrote:
On Sunday, 16 September 2018 at 01:19:46 UTC, tide wrote:
I guess that's why Bugzilla is a complete disaster. No one, at
all, is maintaining it. As there are only 2 people that can
really maintain it, and I don't see either
On Sunday, 16 September 2018 at 01:19:46 UTC, tide wrote:
I guess that's why Bugzilla is a complete disaster. No one, at
all, is maintaining it. As there are only 2 people that can
really maintain it, and I don't see either of them commenting
on bugs to provide direction, at least very often.
On Saturday, September 15, 2018 7:19:46 PM MDT tide via Digitalmars-d wrote:
> On Sunday, 16 September 2018 at 00:53:45 UTC, Jonathan M Davis
>
> wrote:
> > On Saturday, September 15, 2018 6:28:20 PM MDT Vladimir
> >
> > Panteleev via Digitalmars-d wrote:
> >> On Sunday, 16 September 2018 at 00:14:
On Sunday, 16 September 2018 at 00:53:45 UTC, Jonathan M Davis
wrote:
On Saturday, September 15, 2018 6:28:20 PM MDT Vladimir
Panteleev via Digitalmars-d wrote:
On Sunday, 16 September 2018 at 00:14:12 UTC, Jonathan M Davis
wrote:
> As for figuring out who is "officially" part of the dlang
> o
On Saturday, September 15, 2018 6:28:20 PM MDT Vladimir Panteleev via
Digitalmars-d wrote:
> On Sunday, 16 September 2018 at 00:14:12 UTC, Jonathan M Davis
>
> wrote:
> > As for figuring out who is "officially" part of the dlang org
> > (or at least has the rights to merge PRs from at least one
>
On Sunday, 16 September 2018 at 00:14:12 UTC, Jonathan M Davis
wrote:
As for figuring out who is "officially" part of the dlang org
(or at least has the rights to merge PRs from at least one
dlang repo), you can look here
https://github.com/orgs/dlang/people
though it's possible to hide your
On Saturday, 15 September 2018 at 18:21:43 UTC, Josphe Brigmo
wrote:
On Saturday, 15 September 2018 at 13:37:29 UTC, Vladimir
Panteleev wrote:
Can you list some programming languages that achieve this task
in a way you approve of?
Plenty, pick just about any one. C#, Haskell, javascript, lua,
on these boards.
The issue was reported in bugzilla quite some time ago.
https://issues.dlang.org/show_bug.cgi?id=8967
However, while Walter's response on it basically indicates that we should
just close it as "won't fix," we never actually did - which is something
that pr
On Saturday, 15 September 2018 at 23:50:43 UTC, Josphe Brigmo
wrote:
[...]
D is generally described as a system programming language. There
is value in favoring a simple and obvious implementation ("do
what I say") over going out of one's way to make usage simpler
("do what I mean"). The tra
On Saturday, 15 September 2018 at 18:21:43 UTC, Josphe Brigmo
wrote:
Can you list some programming languages that achieve this task
in a way you approve of?
Plenty, pick just about any one. C#, Haskell, javascript, lua,
python, perl, C++(yes, c++, we are not talking about language
features bu
ersion.
>
> https://github.com/dlang/phobos/blob/master/std/file.d#L1047
It doesn't matter, the fact is that something in phobos is
broke. Do you really expect me to do all the work? The fact
that using executeShell or "\\?\" solves 90% of the
problems(maybe all of them) pr
On Saturday, 15 September 2018 at 18:33:52 UTC, bachmeier wrote:
On Saturday, 15 September 2018 at 13:54:45 UTC, tide wrote:
On Friday, 14 September 2018 at 19:17:58 UTC, bachmeier wrote:
On Friday, 14 September 2018 at 19:06:14 UTC, Josphe Brigmo
wrote:
For very long file names it is broke and
sion.
> >
> > https://github.com/dlang/phobos/blob/master/std/file.d#L1047
>
> It doesn't matter, the fact is that something in phobos is broke.
> Do you really expect me to do all the work? The fact that using
> executeShell or "\\?\" solves 90% of the problems(m
On Saturday, 15 September 2018 at 18:33:36 UTC, Josphe Brigmo
wrote:
and the biggest problem is that I don't see any motivation in
the D community to make things better.
This is an open source project. If you're hoping that you can
report that something doesn't work the way you want it to and
and the biggest problem is that I don't see any motivation in the
D community to make things better. Anyone with the abilities to
make it better in the right way simply does not care about having
a proper plan to get D to where it needs to be. Hence, it gives
me no hope that D will ever reach a
On Saturday, 15 September 2018 at 13:54:45 UTC, tide wrote:
On Friday, 14 September 2018 at 19:17:58 UTC, bachmeier wrote:
On Friday, 14 September 2018 at 19:06:14 UTC, Josphe Brigmo
wrote:
For very long file names it is broke and every command fails.
These paths are not all that long but over
On Saturday, 15 September 2018 at 13:37:29 UTC, Vladimir
Panteleev wrote:
On Saturday, 15 September 2018 at 12:59:25 UTC, Josphe Brigmo
wrote:
The libraries are already copying the user's string and adding
the 0 termination prior to calling the windows api, so it
seems to me to be a reasonable
1 - 100 of 156 matches
Mail list logo
