Re: array to string functional?
On Friday, 14 September 2018 at 20:43:45 UTC, SrMordred wrote: On Friday, 14 September 2018 at 19:44:37 UTC, berni wrote: a) I've got an int[] which contains only 0 und 1. And I want to end with a string, containing 0 and 1. So [1,1,0,1,0,1] should become "110101". Of course I can do this with a loop and ~. But I think it should be doable with functional style, which is something I would like to understand better. Can anyone help me here? (I think a.map!(a=>to!char(a+'0')) does the trick, but is this good style or is there a better way?) Yes, that's fine. That gives you a range; if you want an array, call array() with that expression. Also, since you know the addition won't overflow, you can substitute the to!char call with a cast (arr.map!(c => cast(char)(c + '0')).array). Another option is to index a string literal: arr.map!(c => "01"[c]).array auto a = [1,0,1,1,1,0,1,0,1,1,1,1,0]; a.map!(to!string) .join("") .chunks(4) .map!(to!string) //donĀ“t know why the chunks are not already strings at this point ;/ .writeln; That's needlessly complicated and inefficient; this will allocate one string per array element. If you don't need the result to be actual arrays, this works: auto res = [1,0,1,1,1,0,1,0,1,1,1,1,0] .map!(c => "01"[c]) .chunks(4); assert(equal!equal(res, ["1011","1010","","0"])); If you need a real array of arrays: auto arr = res .map!array .array; assert(arr == ["1011","1010","","0"]);
Re: array to string functional?
Can you post a complete, runnable example that illustrates your problem? Strange as it is, now it works here too... - I don't know, what went wrong yesterday. Thanks anyway. :-)
Re: x64 Privileged instruction
On Saturday, 15 September 2018 at 18:05:58 UTC, Josphe Brigmo wrote: I have always gotten these types of errors on x64 and, it may be my machine, it has happened with many dmd versions, visual D and visual studio... Oh, you mean the message that appears in Visual Studio, not stderr. Exception handling in Win64 is very different than on Win32, so that's probably it. Visual Studio probably doesn't know how to extract the error message from a D exception in Win64. If you run the D program without a debugger attached, you should see the exception message on stderr (or a MessageBox, if you're building a GUI executable).
Getting started with separate compilation
My project [1] has enough language coverage to expose two issues that break compilation. 1. Stack overflow in ddmd/dtemplate.d:6241, TemplateInstance::needsCodegen(); https://issues.dlang.org/show_bug.cgi?id=18026 2. -allinst gives undefined reference linker errors; https://issues.dlang.org/show_bug.cgi?id=19123 It's also of a size large enough that the memory needed to compile makes CircleCI kill the process. Locally I generally need to close my browsers to be able to build. I'd throw money at all these three problems if I knew it would help. #dbugfix :c Everything speaks for abandoning dub and moving ahead with something with which I can separately compile parts of the program for less memory, and use -allinst on key files to avoid issue 1 without triggering issue 2. --build-mode=singleFile exists, but I don't see anything in dub that would let me apply -allinst on a per-file basis. Are there any guides on where to get started with this? Any protips? Can dub still be used to some extent? [1]: https://github.com/zorael/kameloso
Re: array to string functional?
On Saturday, 15 September 2018 at 20:04:36 UTC, berni wrote: Anotherone I'm not getting to work: From some output with newlines I want to discard all lines, that start with a # and select part of the other lines with a regex. (I know the regex r".*" is quite useless, but it will be replaced by something more usefull.) I tried the following, but non worked: output.split("\n").filter!(a=>a.length>0 && a[0]!='#').matchFirst(r".*"); output.split("\n").filter!(a=>a.length>0 && a[0]!='#').array.matchFirst(r".*"); output.split("\n").filter!(a=>a.length>0 && a[0]!='#').array.map!(matchFirst(r".*")); output.split("\n").filter!(a=>a.length>0 && a[0]!='#').array.map!(a=>matchFirst(a,r".*")); Any ideas? Your last example works for me: https://run.dlang.io/is/F5n3mk Can you post a complete, runnable example that illustrates your problem?
Re: Pass 'this' as reference
On Saturday, September 15, 2018 11:44:05 AM MDT Jan via Digitalmars-d-learn wrote: > On Thursday, 13 September 2018 at 11:08:30 UTC, Jonathan M Davis > > wrote: > > [...] > > Thanks for clarifying Jonathan :) > But aren't the variables considered rvalues then? No. variables are _always_ lvalues. An lvalue is an object which is addressable and which can therefore be assigned a value (ignoring issues of constness). The name comes from the fact that lvalues are allowed on the left-hand side of an assignment operation, whereas rvalues are only allowed on the right. e.g. int i; int* p; are both lvalues. They have addresses and can be assigned to. i = 42; p = &i; auto p2 = &p; On the other hand, the return value of int foo(string s); is an rvalue. How it's actually stored is compiler-defined; you can't take its address, and you can't assign to it. foo("bar") = 42; // illegal auto p = &foo("bar"); // illegal On the other hand, ref int foo(string s); returns by ref, so it's returning an lvalue. Its address can be taken, and it can be assigned a value. foo("bar") = 42; // legal auto p = &foo("bar"); // legal Because a pointer or reference points to a specific address, even if the pointer itself is an rvalue, what it points to is almost always an lvalue, (the main case where it isn't an lvalue would be something like a function pointer, since you can take a function's address, but you can't assign to it). So, something like int* foo(string s); *foo("bar") = 42; compiles. However, ultimately, you can't know whether a particular value is an lvalue or rvalue without context. A variable is always an lvalue, whereas a return value usually isn't - but it can be if it's returned by ref. And a variable and return value could both be the same type - int, int*, string, etc. So, the type itself doesn't tell you whether something is an lvalue or rvalue. It's how it's stored that tells you. Ultimately though, if you want to know whether something is an lvalue or rvalue, consider whether it's something that can go on the left-hand side of an assignment operation (ignoring its constness), or whether it can only go on the right-hand side. https://msdn.microsoft.com/en-us/library/f90831hc.aspx https://stackoverflow.com/questions/17357888/exact-difference-between-rvalue-and-lvalue https://www.quora.com/What-is-lvalue-and-rvalue-in-C - Jonathan M Davis
Re: array to string functional?
Anotherone I'm not getting to work: From some output with newlines I want to discard all lines, that start with a # and select part of the other lines with a regex. (I know the regex r".*" is quite useless, but it will be replaced by something more usefull.) I tried the following, but non worked: output.split("\n").filter!(a=>a.length>0 && a[0]!='#').matchFirst(r".*"); output.split("\n").filter!(a=>a.length>0 && a[0]!='#').array.matchFirst(r".*"); output.split("\n").filter!(a=>a.length>0 && a[0]!='#').array.map!(matchFirst(r".*")); output.split("\n").filter!(a=>a.length>0 && a[0]!='#').array.map!(a=>matchFirst(a,r".*")); Any ideas?
Re: dealing with very long paths and names
On Saturday, September 15, 2018 8:45:55 AM MDT Vladimir Panteleev via Digitalmars-d-learn wrote: > On Friday, 14 September 2018 at 21:16:31 UTC, Jonathan M Davis > > wrote: > > Yeah, though if you write cross-platform applications or > > libraries (and ideally, most applications and libraries would > > be platform-agnostic), you can't necessarily avoid all of the > > Windows insanity, even if you yourself use a platform without > > those problems. > > Linux generally allows you to go ahead and use the filesystem as > a database, and this works pretty well in a lot of cases. > Filesystem performance is much better, and so are the limitations > - not just the path length as discussed in this thread, but also > the range of valid characters (anything except / and NUL is > fine). Plus, depending on your choice of filesystem, you get > bonus features like snapshots, incremental backups, and > deduplication. It's a boon for prototyping (or Linux-only > software). Oh, I don't disagree. I think that in general it makes _way_ more sense to use a *nix system for development (or most anything else) even if the software can run on multiple platforms. And actually, the primary reason that I use the OS I do (FreeBSD) is because of the filesystem (it has first class ZFS support unlike Linux). However, I'm a strong believer that in general, software should be cross-platform if it reasonably can be. That's usually the worst when folks use all kinds of Windows-specific stuff when they don't need to, but sometimes, Linux-isms do creep into code unnecessarily. Either way, while I've occasionally found something that Windows did better than *nix, far more often, it's shocking how bad their APIs are. And in this particular case, there really isn't a great solution. Trying to hide the Windows limitations by translating longer paths so that the Windows API is risky business, but leaving it up to the programmer to run into it and then scream in frustration like the OP is isn't great either. And of course, even if they outright fixed the problem in Windows tomorrow, it would probably be over a decade before you could rely on it given how long people use older versions of Windows. - Jonathan M Davis
Re: x64 Privileged instruction
On Saturday, 15 September 2018 at 14:57:20 UTC, Vladimir Panteleev wrote: On Thursday, 13 September 2018 at 05:50:53 UTC, Josphe Brigmo wrote: Privileged instruction Lots of code. I pretty much always get this error. Something must have gone really wrong to get this error. Most likely, the CPU instruction pointer ended up in a memory area without any code in it. Windows exception handling is tricky (see Don/Walter's recent discussion), but basic cases should be well-covered by the compiler/runtime test suite. So, I suspect one of the following happened: - Your program is exhibiting an edge case and uncovering a bug not covered by the test case. If this is the case, please reduce your program to a minimal, self-contained example, and file a bug report. - There is a bug in your program that is causing its memory to be corrupted. Using @safe can help narrow it down (https://dlang.org/spec/memory-safe-d.html). - There is something specific to your machine that causes the problem to occur there, but not on the test runners. This could happen e.g. due to software which alter behavior of other programs (like through DLL injection), or using a specific Windows version. You can eliminate this possibility by running the DMD test suite. When I run the code in x86 the error is from a throw and is a first chance exception and the error message is shown as normal. In x64, no changes to source, it is a privileged instruction error. I have always gotten these types of errors on x64 and, it may be my machine, it has happened with many dmd versions, visual D and visual studio... I doubt it is my machine and it seems to be completely dmdx64's fault. Basically I just program in x86 most of the time and compile for x64 because of things like this.
Re: Pass 'this' as reference
On Thursday, 13 September 2018 at 11:08:30 UTC, Jonathan M Davis wrote: [...] Thanks for clarifying Jonathan :) But aren't the variables considered rvalues then?
Re: array to string functional?
On Saturday, 15 September 2018 at 05:39:48 UTC, berni wrote: Oh, thanks. What I didn't know about was join. Now I wonder how I could have found out about it, without asking here? Even yet I know it's name I cannot find it, nighter in the language documentation nor in the library documentation. Probably the easiest way to find something in the documentation is to use the unofficial mirror at http://dpldocs.info/. Type "join" into the search box there, and you'll get `std.array.join` (the function I used) as the first result.
Re: x64 Privileged instruction
On Thursday, 13 September 2018 at 05:50:53 UTC, Josphe Brigmo wrote: Privileged instruction Lots of code. I pretty much always get this error. Something must have gone really wrong to get this error. Most likely, the CPU instruction pointer ended up in a memory area without any code in it. Windows exception handling is tricky (see Don/Walter's recent discussion), but basic cases should be well-covered by the compiler/runtime test suite. So, I suspect one of the following happened: - Your program is exhibiting an edge case and uncovering a bug not covered by the test case. If this is the case, please reduce your program to a minimal, self-contained example, and file a bug report. - There is a bug in your program that is causing its memory to be corrupted. Using @safe can help narrow it down (https://dlang.org/spec/memory-safe-d.html). - There is something specific to your machine that causes the problem to occur there, but not on the test runners. This could happen e.g. due to software which alter behavior of other programs (like through DLL injection), or using a specific Windows version. You can eliminate this possibility by running the DMD test suite.
Re: dealing with very long paths and names
On Friday, 14 September 2018 at 21:16:31 UTC, Jonathan M Davis wrote: Yeah, though if you write cross-platform applications or libraries (and ideally, most applications and libraries would be platform-agnostic), you can't necessarily avoid all of the Windows insanity, even if you yourself use a platform without those problems. Linux generally allows you to go ahead and use the filesystem as a database, and this works pretty well in a lot of cases. Filesystem performance is much better, and so are the limitations - not just the path length as discussed in this thread, but also the range of valid characters (anything except / and NUL is fine). Plus, depending on your choice of filesystem, you get bonus features like snapshots, incremental backups, and deduplication. It's a boon for prototyping (or Linux-only software).
Re: Variadic template with template arguments in pairs
On Wednesday, 12 September 2018 at 21:33:17 UTC, Paul Backus wrote: Another alternative is to write the function recursively: void doByPair(T, Rest...)(string desc, T* valuePtr, Rest rest) { writefln("%s %s: %s", T.stringof, desc, *valuePtr); if (rest.length) doByPair(rest); } Rest... is genius, I don't know why it never struck me before. My current solution doesn't support having chunks of varying sizes (ideally it would take 2 *or* 3), but the current use case is okay with just pairs for now. I imagine I could keep the same signature and just access a third argument with rest[0] and recursing on rest[1..$]. Many thanks!
Re: Why do some attributes have an @ symbol and others don't?
On Saturday, 15 September 2018 at 12:40:07 UTC, Gary Willoughby wrote: Is it just a legacy thing? Yeah, basically the ones that date back to before the @ thing don't have it, and the ones after it do.
Why do some attributes have an @ symbol and others don't?
Why do some attributes have an @ symbol and others don't? I thought it might be because some are used as keywords for other things but then 'pure' doesn't follow that rule. Any ideas? Is it just a legacy thing?
Re: remove file access denied(remove broke)
On Saturday, 15 September 2018 at 06:13:29 UTC, bauss wrote: On Friday, 14 September 2018 at 16:55:21 UTC, Josphe Brigmo wrote: On Friday, 14 September 2018 at 15:21:21 UTC, H. S. Teoh wrote: [...] It woudln't help. I'm dealing with over a million files and you'd need those files too. But basically all I have done is created a new rename function: void removeFile(string fn) { if (!isDir(fn)) { // remove(fn) setAttributes(fn, 0x80); auto ls = executeShell(`del /F /Q "`~fn~`"`); if (ls.status != 0) throw new Exception("Cannot delete file `"~fn~"`!"); } } And this works and functions appropriately. The other code is basically just recursively going through the directory as standard practice using dirEntries and deleting certain files(it's a little more complex since there is some logic on the file name, but nothing touches the file except delete). Went ahead and did the following in case anyone comes across your issue in the future: https://github.com/dlang/phobos/pull/6707 That way the documentation will at least be clear about it. Thanks. The problem ultimately is MAX_PATH. Seems that phobo's does not detect windows 10 nor use unicode for such things as it should which would not break simple code(one expects file routines to be well used and the bugs fixed). Seems not to many people use D for windows with long paths and files and hence D for windows. The fix is relatively simple ("prepend \\?\ or use the wide functions).