Re: phobo's std.file is completely broke!
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 should. 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 types) of Y for which X fails? Answer: Ideally, no. At least to the extent realistically possible. So what should a well-designed function X do when faced with known-to-be unsupported input Y?[1] Here are the possibilities[2]: ([1] "Unsupported" is defined here as "for the given input, the function does not correctly and successfully perform its intended goal".) ([2] Again, we're assuming "to the extent realistically possible" is still in play here.) 1. Add support for input Y to function X. 2. Reject input Y (via either: abort, throw or static compile error) 3. Accept input Y and allow one of the following to occur[3]: Silently fail to perform the expected task, silently do the wrong thing, or trigger an unclear error (assert/exception/compile) from deeper in the callstack. ([3] Note that which one of these three possibilities occurs is dependent on function X's exact implementation details.) Of these three possibilities for a function X faced with unsupported input Y, the first two options are (in theory) acceptable[4]. The third possibility is absolutely not acceptable [to the extent realistically possible.] ([4] The library containing function X may impose additional restrictions on what is/isn't acceptable.) So, what does this mean in our specific situation? If good API design is followed, then any filesystem-based API, when running on Windows and faced with a path exceeding the local system's size limit, must do one of the following: 1. Modify Phobos to support long filepaths even on Windows versions below Win10 v1607. 2. Detect and reject any non-\\?\ path longer than MAX_PATH-12 bytes[5]. 3. Provide a very good justification why possibilities #1 and #2 are sufficiently unrealistic/problematic. ([5] Note that the following still technically satisfy possibility #2 since they do not involve passing unsupported input to the given function, but they could still be optionally determined unacceptable if desired: A. Rejecting all paths longer than MAX_PATH-12 bytes, even if \\?\-based. B. Rejecting too-long paths even on Win10 v1607+ with LongPathsEnabled set in the registry.) No, that's completely nuts! A library, especially a standard library, should not introduce new limitations, but pampering over the limitations of the platform is not the right thing to do. This is debatable. Why, exactly, is pampering over pre-Win10-v1607's maximum non-\\?\ filepath length a bad thing? Exactly what problems does it cause? If the platforms API is piling POS, there's nothing a sane library can do about. That is patently untrue. It might be true in specific circumstances, but it is not generally true. If you believe it to be true in this specific case, then please explain *how*/*why* there is nothing the library can do about it. If your app writes to a FAT12 formatted floppy disk you don't expect the library to implement code to alleviate its limitation, like 8+3 filenames or fixed number of files in the root directory. The general rule of thumb is: "Typical situations should work as expected, atypical situations should be possible." Therefore, please explain *ANY* one of the following: 1. How writing to a FAT12 formatted floppy disk qualifies as a typical situation. 2. How abstracting over the MAX_PATH limitation makes writing to a FAT12 formatted floppy impossible. 3. How my claim of "Typical situations should work as expected, atypical situations should be possible" is fundamentally wrong for D.
Re: phobo's std.file is completely broke!
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 - it is problematic for technical reasons. It seems you are the one ignoring the problems with it...
Re: Copy Constructor DIP and implementation
On Wednesday, 19 September 2018 at 00:05:15 UTC, Jonathan M Davis wrote: On Tuesday, September 18, 2018 10:58:39 AM MDT aliak via Digitalmars-d- announce wrote: This will break compilation of current code that has an explicit copy constructor, and the fix is simply to add the attribute @implicit. In that case, why not just use a transitional compiler switch? Why force everyone to mark their copy constructors with @implicit forever? The whole point of adding the attribute was to avoid breaking existing code. - Jonathan M Davis Well one breaks compilation and the other is silent code changes. And No.compilerSwitch > Yes.compilerSwitch when possible. I'm actually not strongly for @implicit btw.
Re: phobo's std.file is completely broke!
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. None would ever be, considering you obviously have decided to ignore such a simple solution to the 260 character limit...
Re: Mobile is the new PC and AArch64 is the new x64
On Tuesday, 18 September 2018 at 18:06:37 UTC, Neia Neutuladh wrote: On Tuesday, 18 September 2018 at 07:53:31 UTC, Joakim wrote: On Monday, 17 September 2018 at 22:27:41 UTC, Neia Neutuladh wrote: On Monday, 17 September 2018 at 15:47:14 UTC, Joakim wrote: Not sure why that matters if you agree with Kay that HTML is an abortion? :) I actually think it's great that mobile is killing off the web, as the Comscore usage stats I linked earlier show. HTML is a somewhat open standard. I'm more happy with HTML and Javascript, as ugly as they are and as dominated by Google and Microsoft as they are, than having to target private companies' frameworks. So you'd rather target an incredibly badly designed open standard than a mostly open source "private company's" framework that's certainly not great, but much better? It's no contest for me, give me the latter any day. And then of course, there's always cross-platform OSS toolkits like Flutter or DlangUI. Thinking about it a bit more, the openness of the platform is more important. Android and iOS are effectively closed platforms. You *can* sideload apps, but it's rare to find someone willing to do so. If you're not on the app stores, your app isn't going to get a thousandth as much traction. I'll note that you wrote "app stores," and for Android there are actually multiple. There's the official Play store from google, the Amazon appstore, app stores for OSS apps like F-Droid or Fossdroid, and over 400 app stores in China, where those first two app stores are almost never used: https://www.appinchina.co/market/app-stores/ Anyone can install any app store on their Android device and get any apps they want, though as you note, most outside China just go with the pre-installed Play or Amazon store. Windows, on the other hand, has long been an open platform; you can develop for it and publish your programs and Microsoft won't get in the way. Though that is now changing with their new UWP platform, which by default must be installed from their own app store, the Microsoft Store. The link for the Windows/AArch64 device in my original post notes that they expect most Windows/AArch64 apps to be UWP apps, and so you'd get them from an app store just like Android most of the time. I read that they do have similar allowances for side-loading UWP apps as Android though, and of course older win32/64 apps on normal Wintel devices isn't affected by this. So an open source cross-platform toolkit controlled by a single entity isn't bad. I use GTK+ a lot, for instance. But the web and HTML is a better situation than Android and iOS and their toolkits. I don't think the app stores are that big a deal as long as side-loading and multiple app stores are always allowed. Of course, that's not the case on iOS, one of the many reasons I've never really used an iOS device.
Re: phobo's std.file is completely broke!
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 but to implement low-level abstraction function (GetPhysicalPath() etc) to make the file system classes work similarly across all four systems. Do the PS2, GameCube and Xbox filesystems all have identical file path limits? And, did any of the paths in your game exceed 260 characters in length? These comparisons are not helpful.
Re: phobo's std.file is completely broke!
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. Another is adding a good deal of extra logic that performs additional OS calls and generates additional GC garbage to work around API problems even on systems that don't need it.
Re: phobo's std.file is completely broke!
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/bqsjebjxuljlqusao...@forum.dlang.org I proposed something a little different: https://forum.dlang.org/post/dnlbtkmdcjucqetkw...@forum.dlang.org
Re: phobo's std.file is completely broke!
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 failed to notice that `\\?\` != `\\.\`) He never actually
made any comment after that was pointed out.
If a clean, simple solution can be found that allows long paths on Windows
to work seemlessly without subtle side effects, then I don't see why it
can't be implemented, but it needs to be something that's not going to cause
problems. Otherwise, it needs to be left up to the caller to do whatever
happens to be correct for their particular circumstances. We want Phobos to
work seemlessly across platforms where reasonably possible, but
unfortunately, it's not always reasonable. Either way, Microsoft has clearly
made a mess of this. So, I don't know how reasonable it is to work around
it. Regardless, we either need to figure out a sane way to work around the
problem (without causing new problems in the process) or document it so that
the situation is clear.
Exactly. And this is precisely why I'm irritated by just how much of
this entire thread has been meaningless high-level philosophical
hand-wringing, with barely any attention paid to the technical details
of the problem itself.
Though I admit, I've allowed myself to get dragged into it, too. So
allow me to rectify that:
1. For reference, here is the relevant MS documentation:
https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#file-and-directory-names
2. For reference, here is the existing bug report discussion:
https://issues.dlang.org/show_bug.cgi?id=8967
3. Building on what Vladimir and Jay have said in the bug report, I
propose we do this:
- We add a public function to Phobos which takes a a UTF-8 path and does
the following:
- No-op outside of Windows
- No-op if the path is less than MAX_PATH-12 bytes. (Worrying about
the case where the real limit is MAX_PATH-1 would be inconsequential and
thus needless.)
- No-op if the path begins with "\\" (and is therefore either a
network share path, a "\\.\" device path, is already a "\\?\" path, or
is just some undetectable malformed path that happens to look like one
of the above)
- Otherwise, returns:
toUTF16z(buildNormalizedPath("\\?", path.toAbsolute))
- By "no-op" above, I really mean: toUTF16z(path)
- In all cases where Phobos passes a path to WinAPI, the path is first
passed through this function (except for any specific cases where it can
be shown that the path should NOT be passed through this function).
4. What technical problems does this proposal have?
5. For each technical problem with the proposal: How can the proposal be
adjusted to compensate? Or, why can the technical problem NOT be
reasonably solved? Or in general: How should this proposal be modified,
and why?
Re: phobo's std.file is completely broke!
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 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior." -- From: https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation It goes on to explain the registry setting for that. If it did I wouldn't have had this problem and wasted a day of my life trying to figure out what is going on(I didn't design my program around having to hack such things, I just assumed they would work, because, after all, they should, right?). I, too, spent a LOT of time fighting the Windows filesystem APIs. See e.g. * https://dump.thecybershadow.net/d78d9911adc16ec749914b6923759454/longpathdelete.d (that also sets ownership/ACLs via external processes, as the C API is unreasonably complicated). The problem is 100% due to Windows. It was one of the big reasons why I moved to Linux for software development. Such problems do not exist there. Agreed, but this sounds to me like a perfect reason to abstract away as much as that garbage as we reasonably can. D's in the business of improving the user-experience of programming, not the promotion of one OS over another. Bear in mind, the very point of plenty of things in Phobos, or any std lib for that matter, is to abstract away the need to waste everyone's time making them fiddle about with pointless little OS differences. Sure, there are going to be things that can't be reasonably abstracted away, but that's FAR from justifying not doing what we can. Again: normal expectations should be the default and just work, exceptional needs should still be possible. 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.
Re: extern(C++, ns) is wrong
On Tuesday, September 18, 2018 6:22:55 PM MDT Manu via Digitalmars-d wrote: > On Mon, 17 Sep 2018 at 06:00, Atila Neves via Digitalmars-d > > wrote: > > On Sunday, 16 September 2018 at 17:46:26 UTC, Steven > > > > Schveighoffer wrote: > > > On 9/14/18 6:41 PM, Neia Neutuladh wrote: > > >> Specifically, Walter wants this to compile: > > >> > > >> module whatever; > > >> extern(C++, foo) void doStuff(); > > >> extern(C++, bar) void doStuff(); > > >> > > >> And he's not too concerned that you might have to use doubly > > >> fully qualified names to refer to C++ symbols, like: > > >> > > >> import core.stdcpp.sstream; > > >> import core.stdcpp.vector; > > >> core.stdcpp.vector.std.vector v; > > > > > > This is probably the best explanation of why the current > > > situation sucks. > > > > > > -Steve > > > > Agreed. Up until now, I didn't even understand the rationale for > > why it works the way it does. > > https://github.com/dlang/dmd/pull/8667 > > O_O > > Thank you Walter for coming to the party! Oh, wow. I sure wasn't expecting that. I thought that he'd made it pretty clear that a DIP was needed, and even then, it didn't seem likely that it would be accepted. This is awesome. I guess that he finally came around. - Jonathan M Davis
Re: phobo's std.file is completely broke!
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 response on it basically indicates that we > > should > > just close it as "won't fix," we never actually did > > 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 failed to notice that `\\?\` != `\\.\`) He never actually > made any comment after that was pointed out. If a clean, simple solution can be found that allows long paths on Windows to work seemlessly without subtle side effects, then I don't see why it can't be implemented, but it needs to be something that's not going to cause problems. Otherwise, it needs to be left up to the caller to do whatever happens to be correct for their particular circumstances. We want Phobos to work seemlessly across platforms where reasonably possible, but unfortunately, it's not always reasonable. Either way, Microsoft has clearly made a mess of this. So, I don't know how reasonable it is to work around it. Regardless, we either need to figure out a sane way to work around the problem (without causing new problems in the process) or document it so that the situation is clear. - Jonathan M Davis
Re: phobo's std.file is completely broke!
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 noting that the discussion made it very clear that Walter's viewpoint on the matter was based on his own misunderstanding (ie, mistakenly failed to notice that `\\?\` != `\\.\`) He never actually made any comment after that was pointed out.
Re: phobo's std.file is completely broke!
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 "...to the extent reasonably possible." suffixed to his statement.
Re: Copy Constructor DIP and implementation
On Wednesday, 19 September 2018 at 00:05:15 UTC, Jonathan M Davis
wrote:
On Tuesday, September 18, 2018 10:58:39 AM MDT aliak via
Digitalmars-d- announce wrote:
This will break compilation of current code that has an
explicit copy constructor, and the fix is simply to add the
attribute @implicit.
In that case, why not just use a transitional compiler switch?
Why force everyone to mark their copy constructors with
@implicit forever? The whole point of adding the attribute was
to avoid breaking existing code.
- Jonathan M Davis
Apparently because extending copy constructors are intended to be
extended to types other than typeof(this), which would also be
implicit, and then @implicit is to make sure that you actually
want this(ref SomethingElse){ ... } to be implicitly called when
A a;
B b;
...
b = a;
which I think is a bad idea, not the least of which is because
thats what opAssign is for.
See https://github.com/dlang/DIPs/pull/129#discussion_r218006614
Re: Access to structures defined in C
On Tuesday, 18 September 2018 at 13:47:50 UTC, Atila Neves wrote:
On Tuesday, 18 September 2018 at 02:39:39 UTC, Joe wrote:
The second type is like that shown above. The first is a
simpler array of pointers to int, e.g.,
int *yp = {2, 4, 0};
int *yq = {10, 12, 0};
This is valid C in the sense that it compiles, but I doubt it
does what you think it does. This is equivalent code:
int *yp = 2;
int *yq = 10;
Sorry, Atila, I got confused looking at my two cases. I should
have said "an array of ints", e.g.,
int yp[] = {2, 4, 0};
int yq[] = {10, 12, 0};
int *ys[] = {yp, yq, 0};
This isn't even valid C code.
It is, because C treats 'yp' as a pointer.
In D, I first declared these as
int[] yp = [2, 4];
int[] yq = [10, 12];
__gshared int*[] ys = [ , ];
D dynamic arrays are not equivalent to C arrays.
It's hard to see what you're trying to do with the code you
posted. Have you tried instead to use a tool to translate the C
headers?
At this point, I've translated everything, even the code above. I
had to use 'immutable(int [])' in the second and higher level
arrays like 'ys' so that they could refer to 'yp' and 'yq'
(without the address operators).
I still have to make several changes to the library code because
these arrays were declared as dynamic arrays of pointers, of size
1, to bypass bounds checking. Now they're proper dynamic arrays,
and I can use foreach on them and get other D benefits.
However, I still would like to have a deeper understanding of the
"static variable yp cannot be read at compile time" error
messages which went away when I declared yp immutable.
Re: How to use math functions in dcompute?
On Wednesday, 19 September 2018 at 00:11:13 UTC, Nicholas Wilson wrote: On Tuesday, 18 September 2018 at 06:25:33 UTC, Sobaya wrote: On Tuesday, 18 September 2018 at 01:39:51 UTC, Nicholas Wilson wrote: On Tuesday, 18 September 2018 at 00:25:33 UTC, Sobaya wrote: I'm waiting for the update. How's your progress? I t appears I have broke SPIR-V completely somewhere along the line, I may release a v0.2 with out it, hopefully within the week. I declared like: pragma(LDC_intrinsic, "llvm.nvvm.cos.f32") T cos(T)(T val) if (__traits(isFloating, T)); It also doesn't work. pragma(LDC_intrinsic, "llvm.nvvm.cos.f#") // note the # in place of 32 T cos(T)(T val) if (__traits(isFloating, T)); (Just don't use real with it.) OR pragma(LDC_intrinsic, "llvm.nvvm.cos.f32") float cos(float val) And if they don't work, use pragma(LDC_intrinsic, "llvm.cos.f#") // note the # in place of 32 T cos(T)(T val) if (__traits(isFloating, T)); (Just don't use real with it.)
Re: extern(C++, ns) is wrong
On Mon, 17 Sep 2018 at 06:00, Atila Neves via Digitalmars-d wrote: > > On Sunday, 16 September 2018 at 17:46:26 UTC, Steven > Schveighoffer wrote: > > On 9/14/18 6:41 PM, Neia Neutuladh wrote: > > > >> Specifically, Walter wants this to compile: > >> > >> module whatever; > >> extern(C++, foo) void doStuff(); > >> extern(C++, bar) void doStuff(); > >> > >> And he's not too concerned that you might have to use doubly > >> fully qualified names to refer to C++ symbols, like: > >> > >> import core.stdcpp.sstream; > >> import core.stdcpp.vector; > >> core.stdcpp.vector.std.vector v; > > > > This is probably the best explanation of why the current > > situation sucks. > > > > -Steve > > Agreed. Up until now, I didn't even understand the rationale for > why it works the way it does. https://github.com/dlang/dmd/pull/8667 O_O Thank you Walter for coming to the party!
Re: How to use math functions in dcompute?
On Tuesday, 18 September 2018 at 06:25:33 UTC, Sobaya wrote: On Tuesday, 18 September 2018 at 01:39:51 UTC, Nicholas Wilson wrote: On Tuesday, 18 September 2018 at 00:25:33 UTC, Sobaya wrote: I'm waiting for the update. How's your progress? I t appears I have broke SPIR-V completely somewhere along the line, I may release a v0.2 with out it, hopefully within the week. I declared like: pragma(LDC_intrinsic, "llvm.nvvm.cos.f32") T cos(T)(T val) if (__traits(isFloating, T)); It also doesn't work. pragma(LDC_intrinsic, "llvm.nvvm.cos.f#") // note the # in place of 32 T cos(T)(T val) if (__traits(isFloating, T)); (Just don't use real with it.) OR pragma(LDC_intrinsic, "llvm.nvvm.cos.f32") float cos(float val)
[Issue 15512] extern(C++, ns) should consider taking a string
https://issues.dlang.org/show_bug.cgi?id=15512 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 15512] extern(C++, ns) should consider taking a string
https://issues.dlang.org/show_bug.cgi?id=15512 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/d9747003d45d205ff5348bfbe3f5d9779ae62732 Fix Issue 15512 - Implement better C++ name mangling feature. --
Re: Copy Constructor DIP and implementation
On Tuesday, September 18, 2018 10:58:39 AM MDT aliak via Digitalmars-d- announce wrote: > This will break compilation of current code that has an explicit > copy constructor, and the fix is simply to add the attribute > @implicit. In that case, why not just use a transitional compiler switch? Why force everyone to mark their copy constructors with @implicit forever? The whole point of adding the attribute was to avoid breaking existing code. - Jonathan M Davis
Re: phobo's std.file is completely broke!
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 bit further up in this thread: https://forum.dlang.org/post/gyaswfyzwoofaozki...@forum.dlang.org Ah, don't know how I managed to miss that. Thanks.
Re: One awesome GC feature we will use in Mir!
On Tuesday, 18 September 2018 at 14:23:44 UTC, 9il wrote: I just remember that D's GC has NO_SCAN [1] attribute! I thought D libraries like Mir and Lubeck only had to care about when to call GC.addRange after allocations that contain pointers to GC-backed storage and GC.removeRange before their corresponding deallocations. But that's perhaps only when using non-GC-backed allocators (not using new), right?
[Issue 5363] const + alias this = wrong code
https://issues.dlang.org/show_bug.cgi?id=5363 RazvanN changed: What|Removed |Added CC||nilsboss...@googlemail.com --- Comment #8 from RazvanN --- *** Issue 9354 has been marked as a duplicate of this issue. *** --
[Issue 9354] overload resolution picks alias this over const conversion
https://issues.dlang.org/show_bug.cgi?id=9354 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from RazvanN --- *** This issue has been marked as a duplicate of issue 5363 *** --
Re: GCC: Submission of D Front End, next round
On Tuesday, 18 September 2018 at 20:00:21 UTC, Eugene Wissner wrote: Just reposting here two links Johannes left in the Slack: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00931.html "The D Language Front-End Is Trying Now To Get Into GCC 9 Going on for a while now have been D language front-end patches for GCC to allow this programming language to be supported by the GNU Compiler Collection. It's been a long battle getting to this state but it looks like it soon might be mainlined. Last June was the approval by the GCC Steering Committee to allow D support in GCC. While the committee approved of its addition, the D language front-end didn't end up getting merged in time for the GCC 8 stable release that took place earlier this year." [1] [1] https://www.phoronix.com/scan.php?page=news_item=GCC-9-D-Language-Patches phoronix.comphoronix.com This looks like a tremendous amount of work! Bravo to the GDC team and I'm keeping my fingers crossed on this patch getting accepted into mainline. -Doc
Re: phobo's std.file is completely broke!
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.dlang.org/post/gyaswfyzwoofaozki...@forum.dlang.org
Re: BetterC + Windows + setjmp longjmp
On Tuesday, 18 September 2018 at 20:01:48 UTC, SrMordred wrote: longjmp is crashing so may be related to the struct declaration. Well just found a thread of the same problem, just that in my case with 64x crashes too. https://forum.dlang.org/post/mmxwhdypncaeikknl...@forum.dlang.org
[Issue 6777] alias this disables casting for classes
https://issues.dlang.org/show_bug.cgi?id=6777 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #10 from RazvanN --- PR: https://github.com/dlang/dmd/pull/8712 --
GCC: Submission of D Front End, next round
Just reposting here two links Johannes left in the Slack: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00931.html "The D Language Front-End Is Trying Now To Get Into GCC 9 Going on for a while now have been D language front-end patches for GCC to allow this programming language to be supported by the GNU Compiler Collection. It's been a long battle getting to this state but it looks like it soon might be mainlined. Last June was the approval by the GCC Steering Committee to allow D support in GCC. While the committee approved of its addition, the D language front-end didn't end up getting merged in time for the GCC 8 stable release that took place earlier this year." [1] [1] https://www.phoronix.com/scan.php?page=news_item=GCC-9-D-Language-Patches phoronix.comphoronix.com
Re: phobo's std.file is completely broke!
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 command fails. These paths are not all that long but over 256 limit. (For windows) Please file a bug report with reproducible examples if you believe it's a bug. I feel people need to stop saying this. It feels like people are just being told to say this if there is a bug. There is a larger issue, Bugzilla doesn't and isn't working. Someone will probably throw up some stats about how many bugs are filed and how many are resolved. Those exist because someone working on Dlang comes across a bug that affects them, creates a patch for it first, then goes and creates a bugzilla entry and marks it resolved. Issues are rarely resolved by anyone other than the person that created the bug report to begin with. Or issues created by a team member is resolved by another team member. While that's admittedly all-too-true, filing a proper bug report is still an essential step. Like you, I'm all for bringing attention to important issues on the newsgroup. However, it is CRUCIAL for this to be IN ADDITION to filing a bug report, and NOT INSTEAD of filing a bug report. Correct. There's no point in having a lengthy discussion on the topic without a bug report because it'll just waste their time and then they'll complain that their bug is being ignored. Unless there is a change in the operation of this project, all bugs reported in the forum need to be addressed by telling them to file a bug report.
Re: BetterC + Windows + setjmp longjmp
longjmp is crashing so may be related to the struct declaration.
Re: phobo's std.file is completely broke!
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 to make usage simpler ("do what I mean").
The tradeoff is performance and complexity. Performance is generally an
important factor for users of system programming languages, and
complexity is a source of unforeseen problems in non-trivial use cases.
Consider, for example, how integers are treated in D and Python. D's
integers are fixed-length and roll over on overflow. Python integers are
bigints, which makes them slower, but can handle numbers of any size.
From your posts, it sounds like you're looking for a programming
language closer to Python than to D.
D's philosophy is (or at least is supposed to be) "Whenever possible,
the right thing should be default, alternatives should still be
possible." (And if I'm mistaken on that, then I've very much chosen the
wrong language to use.)
Note that this does not contradict D's integer behaviour, because
changing that would be *prohibitively* expensive and cause the need for
workarounds to be common yet very difficult (if even possible).
Therefore, it is a justifiable exception to the rule.
By contrast, I find it difficult to believe that a fix to the OP's
problem would be prohibitively expensive. Of course, maybe I'm wrong.
And maybe, as some have vaguely suggested, the WinAPI makes a correct
fix impossible. **BUT**, unfortunately, I (as well as the OP) have no
way to know because there appears to be a distressingly blatant LACK of
technical discussion on the specific OP problem itself. Instead, all I'm
seeing is a bunch of high-level design-philosophy bickering left
completely divorced from the specifics of the original problem in question.
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). But sheesh, people,
it's *no wonder* he's gotten upset about it. I would too, and so would
most of the rest of you (I've seen it happen).
Re: BetterC + Windows + setjmp longjmp
On Tuesday, 18 September 2018 at 03:09:18 UTC, Mike Parker wrote:
On Tuesday, 18 September 2018 at 00:24:23 UTC, SrMordred wrote:
Yes, i'm using signal(SIGSEGV, sigfn_t func), it catches
correctly, but end the execution after.
I find the alternatives of setjmp/longjmp and sigaction, but
none are avaliable on windows afaik.
setjmp/longjmp are available on windows (image loaders using
libpng, lua, quake3, and lots of old C code make use of them):
https://msdn.microsoft.com/en-us/library/xe7acxfb.aspx?f=255=-2147217396
https://msdn.microsoft.com/en-us/library/3ye15wsy.aspx
You can declare the functions in your own code and they should
link just fine. It would be helpful if you also submit a PR to
add them to DRuntime for Windows.
As for sigaction, a quick search suggests it isn't available
(and it doesn't show up in MSDN):
https://stackoverflow.com/questions/32389905/sigaction-and-porting-linux-code-to-windows
I think this may be going beyond my knowledge ;/
(Trying to follow setjmp.h, don´t have experience doing this)
enum _SIGSET_NWORDS = (1024 / (8 * (ulong.sizeof)));
struct __sigset_t
{
ulong[_SIGSET_NWORDS] __val;
}
struct __jmp_buf_tag
{
long[8] __jmpbuf;
int __mask_was_saved;
__sigset_t __saved_mask;
};
alias __jmp_buf_tag[1] jmp_buf;
extern (C) @nogc nothrow int setjmp(ref jmp_buf) ;
extern (C) @nogc nothrow void longjmp(ref jmp_buf, int);
OK, things linked fine.
I´m trying to escape a sigfault with signal + set/longjmp:
jmp_buf buf;
extern(C) nothrow @nogc void h1(int code) { longjmp(buf, 1); }
//main
signal(SIGSEGV, );
auto x = setjmp(buf);
if(x == 1) ... (go elsewhere)
else
//forcing some sigfault
There are no compilation errors. But my program still just
crashes after sigfault.
So maybe setjmp/longjmp are not working properly.
Or is not possible to escape a crash.
Or i completely misunderstood everything :P
Re: phobo's std.file is completely broke!
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) Please file a bug report with reproducible examples if you believe it's a bug. I feel people need to stop saying this. It feels like people are just being told to say this if there is a bug. There is a larger issue, Bugzilla doesn't and isn't working. Someone will probably throw up some stats about how many bugs are filed and how many are resolved. Those exist because someone working on Dlang comes across a bug that affects them, creates a patch for it first, then goes and creates a bugzilla entry and marks it resolved. Issues are rarely resolved by anyone other than the person that created the bug report to begin with. Or issues created by a team member is resolved by another team member. While that's admittedly all-too-true, filing a proper bug report is still an essential step. Like you, I'm all for bringing attention to important issues on the newsgroup. However, it is CRUCIAL for this to be IN ADDITION to filing a bug report, and NOT INSTEAD of filing a bug report.
Re: fearless v0.0.1 - shared made easy (and @safe)
On Tuesday, 18 September 2018 at 17:34:10 UTC, 12345swordy wrote: On Tuesday, 18 September 2018 at 17:20:26 UTC, Atila Neves wrote: The `shared` keyword currently means one of two things: 1. You can use core.atomic with it 2. It's some struct and you BYOM (Bring Your Own Mutex) [...] Why is this is an external 3rd party library isn't of the standard library? -Alexander Agreed, this is great!
Re: Mobile is the new PC and AArch64 is the new x64
On Tuesday, 18 September 2018 at 07:53:31 UTC, Joakim wrote: On Monday, 17 September 2018 at 22:27:41 UTC, Neia Neutuladh wrote: On Monday, 17 September 2018 at 15:47:14 UTC, Joakim wrote: Not sure why that matters if you agree with Kay that HTML is an abortion? :) I actually think it's great that mobile is killing off the web, as the Comscore usage stats I linked earlier show. HTML is a somewhat open standard. I'm more happy with HTML and Javascript, as ugly as they are and as dominated by Google and Microsoft as they are, than having to target private companies' frameworks. So you'd rather target an incredibly badly designed open standard than a mostly open source "private company's" framework that's certainly not great, but much better? It's no contest for me, give me the latter any day. And then of course, there's always cross-platform OSS toolkits like Flutter or DlangUI. Thinking about it a bit more, the openness of the platform is more important. Android and iOS are effectively closed platforms. You *can* sideload apps, but it's rare to find someone willing to do so. If you're not on the app stores, your app isn't going to get a thousandth as much traction. Windows, on the other hand, has long been an open platform; you can develop for it and publish your programs and Microsoft won't get in the way. So an open source cross-platform toolkit controlled by a single entity isn't bad. I use GTK+ a lot, for instance. But the web and HTML is a better situation than Android and iOS and their toolkits.
Re: phobo's std.file is completely broke!
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) to make the file system classes work similarly across all four systems. That wasn't an easy task, but it made the life so much easier for the game programmers that it was obvious this was "the right thing" to do. The fact that D's standard library has already bitten me several time with its platform specific problem clearly shows that you have chosen another path. That's your right, but don't expect those who develop cross-platform tools in D to be happy to HAVE to put ugly "version ( ... )" stuff in their code when their software suddenly break on some platforms for unknown (= undocumented) reasons...
Re: One awesome GC feature we will use in Mir!
On Tuesday, 18 September 2018 at 17:21:17 UTC, 9il wrote: Thanks! Is there is information about how GC set flags for `new` on the site? I think it's something like this: The compiler lowers `new T[]` to _d_newarrayT or _d_newarrayiT [1]. These functions get a TypeInfo as a parameter. The actual TypeInfo object is generated by the compiler [2]. __arrayAlloc (called by _d_newarray*) then sets BlkAttr.NO_SCAN depending on what's in TypeInfo.flags. [3] [1]: https://github.com/dlang/druntime/blob/542b680f2c2e09e7f4b494898437c61216583fa5/src/rt/lifetime.d#L966-L1014 [2]: https://github.com/dlang/dmd/blob/3adcc9e4a0813d26725bb3c9e747ef8d4a2a8296/src/dmd/typinf.d#L35 [3]: https://github.com/dlang/druntime/blob/542b680f2c2e09e7f4b494898437c61216583fa5/src/rt/lifetime.d#L425
Re: fearless v0.0.1 - shared made easy (and @safe)
On Tuesday, 18 September 2018 at 17:20:26 UTC, Atila Neves wrote: The `shared` keyword currently means one of two things: 1. You can use core.atomic with it 2. It's some struct and you BYOM (Bring Your Own Mutex) [...] Why is this is an external 3rd party library isn't of the standard library? -Alexander
Re: fearless v0.0.1 - shared made easy (and @safe)
On Tuesday, 18 September 2018 at 17:20:26 UTC, Atila Neves wrote: The `shared` keyword currently means one of two things: 1. You can use core.atomic with it 2. It's some struct and you BYOM (Bring Your Own Mutex) [...] Whahh!! You made my day! /Paolo
fearless v0.0.1 - shared made easy (and @safe)
The `shared` keyword currently means one of two things:
1. You can use core.atomic with it
2. It's some struct and you BYOM (Bring Your Own Mutex)
Do you have to send mutable data to other threads? Are you tired
of locking a mutex and casting? Now you don't have to:
https://code.dlang.org/packages/fearless
I was envious of std::sync::Mutex from Rust and thought: can I
use DIP1000 to make this work in D and be @safe? Turns out, yes.
I'm going to write a blog post about this explaining the why and
how. I'm too tired right now though, so here's some code:
// compile with -dip1000
import fearless;
struct Foo {
int i;
}
int* gEvilInt;
void main() @safe {
// create an instance of Exclusive!Foo allocated on the GC
heap
auto foo = gcExclusive!Foo(42);
// from now the value inside `foo` can only be used by
calling `lock` (a.k.a. `borrow`)
{
int* oldIntPtr; // only here to demostrate scopes, see
below
auto xfoo = foo.lock(); // get exclusive access to the
data (this locks a mutex)
safeWriteln("i: ", xfoo.i);
xfoo.i = 1;
safeWriteln("i: ", xfoo.i);
// can't escape to a global
static assert(!__traits(compiles, gEvilInt = ));
// ok to assign to a local that lives less
int* intPtr;
static assert(__traits(compiles, intPtr = ));
// not ok to assign to a local that lives longer
static assert(!__traits(compiles, oldIntPtr = ));
}
// Demonstrate sending to another thread and mutating
auto tid = spawn(, thisTid);
tid.send(foo);
receiveOnly!Ended;
safeWriteln("i: ", foo.lock.i);
}
struct Ended{}
void func(Tid tid) @safe {
receive(
(Exclusive!Foo* m) {
auto xfoo = m.lock;
xfoo.i++;
},
);
tid.send(Ended());
}
// for some reason the writelns here are all @system
void safeWriteln(A...)(auto ref A args) {
import std.stdio: writeln;
import std.functional: forward;
() @trusted { writeln(forward!args); }();
}
Re: One awesome GC feature we will use in Mir!
On Tuesday, 18 September 2018 at 17:21:17 UTC, 9il wrote: On Tuesday, 18 September 2018 at 16:29:30 UTC, Vladimir Thanks! Is there is information about how GC set flags for `new` on the site? Today my English is so bad =/ sorry
Re: One awesome GC feature we will use in Mir!
On Tuesday, 18 September 2018 at 16:29:30 UTC, Vladimir Panteleev
wrote:
On Tuesday, 18 September 2018 at 16:15:45 UTC, 9il wrote:
If a user allocates new double[], GC will scan whole array
memory, because it is assumed that user may reuse this memory
for types that have references.
Are you sure? That doesn't sound right.
I know this is the case for void[] - even though you can't put
pointers in it, it could hold "anything", so the GC strays on
the safe side and assumes it has pointers.
There was (is?) a problem with e.g. std.file.read("a") ~
std.file.read("b") - even though read marked the memory as not
containing pointers, the result of concatenation is a new
void[], which the GC thinks might contain pointers.
Thanks! Is there is information about how GC set flags for `new`
on the site?
Re: One awesome GC feature we will use in Mir!
On Tuesday, 18 September 2018 at 16:19:23 UTC, Vladimir Panteleev wrote: On Tuesday, 18 September 2018 at 14:23:44 UTC, 9il wrote: I just remember that D's GC has NO_SCAN [1] attribute! This will be added by default when for Mir allocations if type representation tuple has not references. For example, are Slice!(double*, 2) should never be scanned by GC, but it will be in GC heap until something refers it. Not sure if this is what you mean or not, but the D GC already doesn't scan types which do not contain references. This was added in D 1.000, see TypeInfo.flags&1. NO_SCAN is a way to further override that. Ah, awesome! Did not know about it. Need to review all allocations this allocations in Mir anyway. If you mean that Slice itself (when on the heap) should not be scanned by the GC, I'm not sure that's a good idea. Is it not conceivable that a Slice would be the only reference left pointing at a block of memory in the heap? Sure, Slice with GC allocated pointer should be referenced (btw, it is struct).
Re: Copy Constructor DIP and implementation
On Monday, 17 September 2018 at 23:32:39 UTC, Jonathan M Davis
wrote:
On Monday, September 17, 2018 5:07:22 PM MDT Manu via
Digitalmars-d-announce wrote:
[...]
Except that @implicit could be introduced for other
constructors without having it on copy constructors, and the
fact that copy constructors will require it is just going to
cause bugs, because plenty of folks are going to forget to use
it and end up with the default copying behavior instead of
their custom copy constructor being used. Good testing should
find that pretty quickly, but it's almost certainly going to be
a common bug, and it has no need to exist. It's all there in
order to avoid breaking code that's likely only theoretical and
not something that actual D code bases have done. And if there
is a stray code base that did it, it's certainly going to be in
the extreme minority, and the code will almost certainly work
as a proper copy constructor anyway, since that's pretty much
the only reason to write such a constructor. So, we'd be trying
to avoid breaking very rare code by introducing a feature that
will definitely cause bugs. IMHO, it would be _far_ better to
just use a transitional -dip* compiler flag like we have with
other DIPs. It would also give us the benefit of being able to
bang on the implementation a bit before making it the normal
behavior.
We can still add @implicit to other constructors for implicit
construction with a later DIP (assuming that Walter and Andrei
could be convinced of it). I don't see how having it on copy
constructors really helps with that. It just means that the
attribute would already be there, not that it would necessarily
ever be used for what you want, and _not_ having it on copy
constructors wouldn't prevent it from being used for implicit
construction if such a DIP were ever accepted. So, while I
understand that you want implicit construction, I think that
it's a huge mistake to tie that up into copy constructors,
particularly since it really doesn't make sense to have copy
constructors that aren't implicit, and having @implicit for
copy constructiors is going to cause bugs when it's forgotten.
- Jonathan M Davis
I think this can be made in to a compiler error.
The logic would be if there is any copy constructor defined (by
copy constructor I mean a constructor that gets passed an object
that can be used to construct typeof(this) - so ignore definition
in DIP), then default copy construction is a compiler error
unless an @implicit copy constructor is defined.
struct A {
this(ref A) {}
}
A a;
A b = a; // error, cannot implicitly copy because an explicit one
is provided
A c = A(a); // ok
This will break compilation of current code that has an explicit
copy constructor, and the fix is simply to add the attribute
@implicit.
Re: One awesome GC feature we will use in Mir!
On Tuesday, 18 September 2018 at 16:15:45 UTC, 9il wrote:
If a user allocates new double[], GC will scan whole array
memory, because it is assumed that user may reuse this memory
for types that have references.
Are you sure? That doesn't sound right.
I know this is the case for void[] - even though you can't put
pointers in it, it could hold "anything", so the GC strays on the
safe side and assumes it has pointers.
There was (is?) a problem with e.g. std.file.read("a") ~
std.file.read("b") - even though read marked the memory as not
containing pointers, the result of concatenation is a new void[],
which the GC thinks might contain pointers.
Re: One awesome GC feature we will use in Mir!
On Tuesday, 18 September 2018 at 15:55:38 UTC, Nordlöw wrote: On Tuesday, 18 September 2018 at 14:23:44 UTC, 9il wrote: I just remember that D's GC has NO_SCAN [1] attribute! This will be added by default when for Mir allocations if type representation tuple has not references. For example, are Slice!(double*, 2) should never be scanned by GC, but it will be in GC heap until something refers it. Let me know if you have ideas how to further improve memory management and required API in Mir and Lubeck. [1] https://dlang.org/phobos/core_memory.html#.GC.BlkAttr.NO_SCAN Best, Ilya Can you elaborate on why this is the case? Mir users work with time-series, matrixes, tensors. A lot of numeric and scientific data. Almost all structures are plain. mir.series is used instead of associative arrays. Associative arrays are used only to define data set, and then AA converted to Series of immutable (represented as two arrays). In practice 99% of data are plain arrays, and ~80% of this arrays are arrays composed of doubles, ints, or POD structs. Such types does not contains references to other GC allocated memory. So, we can reduce GC latency 5 times for production code. If a user allocates new double[], GC will scan whole array memory, because it is assumed that user may reuse this memory for types that have references. So, the main idea, is that if one allocates a Matrix of doubles, then just turn off scanning of its internal data. Casting from array of doubles to say strings is not @safe, so we have the language instrument to prevent memory leaks for user code. As side effect this will reduce false pointers too.
Re: One awesome GC feature we will use in Mir!
On Tuesday, 18 September 2018 at 14:23:44 UTC, 9il wrote: I just remember that D's GC has NO_SCAN [1] attribute! This will be added by default when for Mir allocations if type representation tuple has not references. For example, are Slice!(double*, 2) should never be scanned by GC, but it will be in GC heap until something refers it. Not sure if this is what you mean or not, but the D GC already doesn't scan types which do not contain references. This was added in D 1.000, see TypeInfo.flags&1. NO_SCAN is a way to further override that. If you mean that Slice itself (when on the heap) should not be scanned by the GC, I'm not sure that's a good idea. Is it not conceivable that a Slice would be the only reference left pointing at a block of memory in the heap?
Re: One awesome GC feature we will use in Mir!
On Tuesday, 18 September 2018 at 14:23:44 UTC, 9il wrote: I just remember that D's GC has NO_SCAN [1] attribute! This will be added by default when for Mir allocations if type representation tuple has not references. For example, are Slice!(double*, 2) should never be scanned by GC, but it will be in GC heap until something refers it. Let me know if you have ideas how to further improve memory management and required API in Mir and Lubeck. [1] https://dlang.org/phobos/core_memory.html#.GC.BlkAttr.NO_SCAN Best, Ilya Can you elaborate on why this is the case?
One awesome GC feature we will use in Mir!
I just remember that D's GC has NO_SCAN [1] attribute! This will be added by default when for Mir allocations if type representation tuple has not references. For example, are Slice!(double*, 2) should never be scanned by GC, but it will be in GC heap until something refers it. Let me know if you have ideas how to further improve memory management and required API in Mir and Lubeck. [1] https://dlang.org/phobos/core_memory.html#.GC.BlkAttr.NO_SCAN Best, Ilya
Re: Is it possible to translate this API's C headers?
On Tuesday, 18 September 2018 at 13:39:40 UTC, Atila Neves wrote: It does C++ as well, just not all (or even close at this point) of it. I doubt it'd work on any real C++ codebase right now, but who knows. It definitely won't if any of the headers use the standard library, which is likely to happen. It doesn't look like that, https://github.com/ultralight-ux/ultralight-0.9-api/blob/master/include/Ultralight/Vector.h - this is probably the most complex code there.
Re: Access to structures defined in C
On Tuesday, 18 September 2018 at 02:39:39 UTC, Joe wrote:
On Sunday, 10 June 2018 at 17:59:12 UTC, Joe wrote:
That worked but now I have a more convoluted case: a C array
of pointers to int pointers, e.g.,
int **xs[] = {x1, x2, 0};
int *x1[] = {x1a, 0};
int *x2[] = {x2a, x2b, 0};
...
int x2a[] = { 1, 3, 5, 0};
Only the first line is exposed (and without the
initialization). So I tried:
extern(C) __gshared extern int**[1] xs;
After a long hiatus, I'm back to working on something related
to the above, but now that various other C pieces have been
converted to D I'm down to converting these static arrays to D.
There are two arrays that are giving me trouble. The second
type is like that shown above. The first is a simpler array of
pointers to int, e.g.,
int *yp = {2, 4, 0};
int *yq = {10, 12, 0};
This is valid C in the sense that it compiles, but I doubt it
does what you think it does. This is equivalent code:
int *yp = 2;
int *yq = 10;
int *ys[] = {yp, yq, 0};
This isn't even valid C code.
In D, I first declared these as
int[] yp = [2, 4];
int[] yq = [10, 12];
__gshared int*[] ys = [ , ];
D dynamic arrays are not equivalent to C arrays.
It's hard to see what you're trying to do with the code you
posted. Have you tried instead to use a tool to translate the C
headers?
Re: Is it possible to translate this API's C headers?
On Monday, 17 September 2018 at 19:13:06 UTC, Jonathan M Davis wrote: On Monday, September 17, 2018 7:43:21 AM MDT Kagamin via Digitalmars-d-learn wrote: try dpp https://github.com/atilaneves/dpp Since according to Mike's post, it's C++ code, dpp wouldn't help, because it currently only supports C and not C++. - Jonathan M Davis It does C++ as well, just not all (or even close at this point) of it. I doubt it'd work on any real C++ codebase right now, but who knows. It definitely won't if any of the headers use the standard library, which is likely to happen. It turns out that parsing C++ is a lot of work. Who knew? :P
[Issue 19251] Alias this does not get called on struct qualified type
https://issues.dlang.org/show_bug.cgi?id=19251 --- Comment #1 from RazvanN --- PR : https://github.com/dlang/dmd/pull/8711 --
[Issue 19251] New: Alias this does not get called on struct qualified type
https://issues.dlang.org/show_bug.cgi?id=19251
Issue ID: 19251
Summary: Alias this does not get called on struct qualified
type
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: razvan.nitu1...@gmail.com
struct A
{
int[] a;
immutable(A) fun()
{
writeln("Yo");
return immutable A([7]);
}
alias fun this;
}
void main()
{
A a;
immutable A b = a; // error: cannot implicitly convert expression a of
type A to immutable(A)
}
This code should print YO.
--
[Issue 19250] New: DWARF Backtraces with very long symbol names read out of bounds when printing
https://issues.dlang.org/show_bug.cgi?id=19250 Issue ID: 19250 Summary: DWARF Backtraces with very long symbol names read out of bounds when printing Product: D Version: D2 Hardware: All OS: Linux Status: NEW Severity: critical Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: marcio...@gmail.com DWARF Backtraces with very long symbol names will print garbage, and sometimes crash. --
Re: dub doesn't work with dmd 1:2.082.0-1.0?
On Thursday, 13 September 2018 at 14:31:53 UTC, Jesse Phillips wrote: Can you find /usr/bin/dmd or run dmd? Sorry if I wasn't clear enough, but I have dmd installed, and dub WAS working until upgrade of dmd. I suspect that problem occurs because dub wasn't upgraded from 1.10 -> 1.11, due to some problems with ArchLinux32 packaging - dub doesn't have dmd as dependency, probably because it doesn't require dmd specifically, but there is a 'provide' thingy that all D compiler packages have, so that's one way to fix this - to add this thingy as dependecy to dub, but maintainers seem to have problems with building newer versions of dub for 32-bit OS, the are already discussing this issue, so yeah, problem is not in dub/dmd itself (never suspected it to be), but rather, in compatability with 32 bit systems or between themselves. If anyone here is good with building dub, please take a look at this thread: https://bbs.archlinux32.org/viewtopic.php?pid=5004 , maybe you will be able to help?
Re: phobo's std.file is completely broke!
On Tuesday, 18 September 2018 at 06:16:50 UTC, Ecstatic Coder
wrote:
This attitude is unfortunately the cause of a lot frustration
among cross-platform developers like me.
I chose D for my file scripting needs because it's a
cross-platform language.
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.
How do you expect the following to "work the same" across all
platforms:
import std.stdio;
import std.file;
auto fn = "a.txt";
auto f = File(fn, "w");
remove(fn);
or this:
import std.file;
write("a", "a");
write("A", "A");
assert(readText("a") == "a");
assert(readText("A") == "A");
There will always be inherent differences between platforms,
because they are wildly different. Using this sentiment as an
argument for Phobos to smooth over this one particular difference
that you care about, and for which incidentally an apparent
solution appears to be available, is fallacious.
Re: Is it possible to translate this API's C headers?
On Monday, 17 September 2018 at 03:16:33 UTC, spikespaz wrote: Could one of you give me pointers about how to go about this? I have the dynamic link libraries, the static libraries, and the header includes. Every other language other than C++ will have the same problem as you interacting with this library, so you could follow this plan. Step 1 Chime in https://github.com/ultralight-ux/ultralight/issues/15 and wait until it is implemented: everyone will need this since its a C++ library hence unusable from any other language Step 2 Ask for binary releases in dynlib form, or build them yourselves. Step 3 Implement a BindBC or Derelict library
[Issue 19240] std.typecons.Tuple should check for reserved identifiers
https://issues.dlang.org/show_bug.cgi?id=19240 Simen Kjaeraas changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #1 from Simen Kjaeraas --- This is caused by a typo in distinctFieldNames. PR: https://github.com/dlang/phobos/pull/6712 --
Re: phobo's std.file is completely broke!
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 support unicode, I used bullet • as utf8 prefix and heuristically detected that names starting with that prefix are utf8 encoded and decoded from that.
Re: Mobile is the new PC and AArch64 is the new x64
On Monday, 17 September 2018 at 22:27:41 UTC, Neia Neutuladh wrote: On Monday, 17 September 2018 at 15:47:14 UTC, Joakim wrote: Not sure why that matters if you agree with Kay that HTML is an abortion? :) I actually think it's great that mobile is killing off the web, as the Comscore usage stats I linked earlier show. HTML is a somewhat open standard. I'm more happy with HTML and Javascript, as ugly as they are and as dominated by Google and Microsoft as they are, than having to target private companies' frameworks. So you'd rather target an incredibly badly designed open standard than a mostly open source "private company's" framework that's certainly not great, but much better? It's no contest for me, give me the latter any day. And then of course, there's always cross-platform OSS toolkits like Flutter or DlangUI. On Monday, 17 September 2018 at 23:42:03 UTC, Dave Jones wrote: On Monday, 17 September 2018 at 15:47:14 UTC, Joakim wrote: On Sunday, 16 September 2018 at 15:41:41 UTC, tide wrote: On Sunday, 16 September 2018 at 15:11:42 UTC, Joakim wrote: I say that almost 30% drop in PC sales over the last 7 Might be, but so is trying to convince everyone your predictions are correct so they will focus their work on the issues important to you. Not at all, because if my predictions are correct, this language will disappear along with the PC platform it's built on. And I've never suggested anybody work on anything "important to [me]," my original post even stated that D may never do well on mobile. You are making your arguments to fit your desires. I can't make head nor tails of this claim, you have a talent for vague non sequiturs. My arguments are based on data, the overwhelming sales numbers I linked. I have no idea what desires you think are involved, I suspect you don't either. :) Plateaus almost never happen, it's not the natural order of things. OK the market stabilises. I don't see how you changing the word you used changes anything about the underlying phenomenon: that doesn't happen. You're seriously suggesting that markets never stabilise, say oil prices stay steady for a few years or some such? Prices flit all over the place, that's not what we're talking about. Oil _production_ has been remarkably consistent and growing for many, many decades: https://commons.m.wikimedia.org/wiki/File:Crude_NGPL_IEAtotal_1960-2008.svg The only hiccup was in the early '80s because of extraordinary measures taken by governments, like price controls and cartel orders, which was still only a 15% drop. If oil production ever drops 30% because some workable substitute comes along, as has happened to PCs now, yes, there is no chance of stabilization. It will be a steady decline from there, as these trends have a kind of momentum. Most households have more devices than ever before, and hardware is only getting cheaper. The idea that people will have to choose just one device is plainly wrong. You need to get out in the world a bit more. The majority of smartphones these days are bought in emerging markets where _nobody in their home has ever owned a PC or used the internet_. I've talked to these working stiffs in developing markets, you clearly haven't. And what happens when the emerging markets mature? Do they still just cling on to one smart phone in the house? Or are they yearning for more technology? They buy more mobile devices, the PC will be long since dead and gone. I find it strange that you think the PC won't also be rolled up by mobile like this. Can you put a 3GB hard drive in your phone? Why would I ever want to do this when I noted my phone has 128 GBs of space? ;) If you mean 3 _TB_, yes, I simply attach my slim 1 TB external drive and back up whatever I want over USB 3.0. So you're not averse to having some external hardware sat on your desk. Hmmm. My original post links to examples of using your smartphone connected to a keyboard and monitor or a laptop shell, so I'm not sure where you ever got the idea I was against "external hardware." Or a high end graphics card? Smartphones come with very powerful graphics cards these days, plenty powerful enough to drive lots of graphic loads. Not if you're into high end gaming. The vast majority of PCs don't have cards capable of that either. For the few who want it, there will be specialized solutions, whether consoles or whatever. Or a soundcard with balanced outputs? Some phones come with high-end DACs and the like, or you could always attach something externally if you really needed to. There's no such thing as professional audio breakout box for android AFAIK. Up until a few years ago the problem was Android couldn't do low latency audio, I'm not sure if the situation has changed. If and when that becomes a market that actually matters, somebody will cater to it, just as google optimized the Android video stack for VR a couple years
Re: phobo's std.file is completely broke!
On Monday, 17 September 2018 at 22:58:46 UTC, tide wrote:
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 resolution.
Funny the other guy was saying to create a bugzilla issue.
Do that *first*.
That's already been done.
The path needs to be normalized, which means that \.\ and
\..\ fragments need to be removed away first. Depending on
your interpretation of symlinks/junctions/etc.,
"foo/bar/../" might mean something else than "foo/" if "bar"
is a reparse point.
All these issues yet for some reason this function was
included in the lot:
https://dlang.org/phobos/std_path.html#absolutePath
[...]
This issue exists anyways, you'd only expand the path when it
need to be used. If the file changes within milliseconds, I
don't see that happening often and if it does there's a flaw
in your design that'd happen even if the path didn't have to
be constructed first.
You've missed the point. Complexity breeds bugs and unexpected
behavior. The expectation is that D's function to delete a
file should do little else than call the OS function.
If *YOU* are OK with the consequences of complexity, implement
this in YOUR code, but do not enforce it upon others.
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 between their code not working and code working.
I'm sure people would rather their code work than not work in
this case.
So you pass a valid path (selected by a user through a UI) to
rmDir, and it doesn't remove the directory. You think this is
acceptable behavior?
It is absolutely not acceptable behavior. Complain 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.
"Workaround" ;)
That's the problem actually.
As suggested previously, the std.file functions should call a
GetPhysicalPath function which just returns the path unchanged on
Linux and MacOS, and on Windows simply checks if the file path is
smaller or not than the 256 character limit, and if needed makes
it absolute and prefixes it.
This has no performance impact, and brings a consistent behavior
across platforms.
THAT would be a nice solution for the cross-platform developers
who erroneously think that the standard library is already Doing
The Right Thing (TM) so that their code doesn't need
platform-specific "workarounds"...
Re: How to use math functions in dcompute?
On Tuesday, 18 September 2018 at 01:39:51 UTC, Nicholas Wilson wrote: On Tuesday, 18 September 2018 at 00:25:33 UTC, Sobaya wrote: I'm waiting for the update. How's your progress? I t appears I have broke SPIR-V completely somewhere along the line, I may release a v0.2 with out it, hopefully within the week. I declared like: pragma(LDC_intrinsic, "llvm.nvvm.cos.f32") T cos(T)(T val) if (__traits(isFloating, T)); It also doesn't work.
Re: Removing zlib1.dll in favor of zlib1.lib
If you can not access the dll files that are present in the computer. This error occur when the dll file is not installed in your system then download https://unfitpc.com/zlib1-dll and run all the files.
Re: phobo's std.file is completely broke!
On Saturday, 15 September 2018 at 23:06:57 UTC, Jonathan M Davis wrote: On Saturday, September 15, 2018 6:54:50 AM MDT Josphe Brigmo via Digitalmars-d wrote: On Saturday, 15 September 2018 at 12:38:41 UTC, Adam D. Ruppe wrote: > On Saturday, 15 September 2018 at 10:57:56 UTC, Josphe Brigmo > > wrote: >> Phobos *NEEDS* to be modified to work with these newer OS's. > > You need to look at the source code before posting. The code > for remove is literally > > DeleteFileW(name); > > it is a one-line wrapper, and obviously uses the unicode > version. > > 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) proves that phobos is not up to par. Using std.file should be on par with using the Windows API from C or C++. It doesn't try to fix the arguably broken behavior of the Windows API with regards to long paths but requires that the programmer deal with them just like they would in C/C++. The main differences are that the std.file functions in question use D strings rather than C strings, and they translate them to the UTF-16 C strings for you rather than requiring you to do it. But they don't do anything like add "\\?\" for you any more than the Windows API itself does that. If you consider that to be broken, then sorry. For better or worse, it was decided that it was better to let the programmer deal with those intricacies rather than trying to tweak the input to make it work based on the idea that that could have undesirable consequences in some circumstances. On some level, that does suck, but the Windows API does not make it easy to make this work like it would on a *nix system without introducing subtle bugs. If you find that the std.file functions don't work whereas using the same input to the Windows API functions in C/C++ would have, then there's a bug in the D code, and it needs to be fixed, but if it acts the same as the C/C++ code, then it's working as intended. - Jonathan M Davis This attitude is unfortunately the cause of a lot frustration among cross-platform developers like me. I chose D for my file scripting needs because it's a cross-platform language. 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. Unfortunately D fails at being consistent. I recently learned this lesson with my Resync tool. No everybody wants the cross-platform to behave inconsistently. For example, in the past I've implemented a proprietary cross-platform C++ game engine for Windows, PS2, Xbox and GameCube. The games needed some tuning for the graphics, etc. But code-wise, the engine made the games behave consistently across the different platforms. This was all about making each method of each class behaving the same. As simple as that. Indeed, on some platforms, the game engine also provided extra classes and/or methods to add some functionalities specific to these platforms. But the common trunc was implemented (!) to behave the same. That was what our game developers expected...
