Re: array to string functional?

2018-09-15 Thread berni via Digitalmars-d-learn
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

2018-09-15 Thread Vladimir Panteleev via Digitalmars-d-learn
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

2018-09-15 Thread Anonymouse via Digitalmars-d-learn
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?

2018-09-15 Thread Paul Backus via Digitalmars-d-learn

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

2018-09-15 Thread Jonathan M Davis via Digitalmars-d-learn
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 = 
auto p2 = 

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 = ("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 = ("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?

2018-09-15 Thread berni via Digitalmars-d-learn
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

2018-09-15 Thread Jonathan M Davis via Digitalmars-d-learn
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

2018-09-15 Thread Josphe Brigmo via Digitalmars-d-learn
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

2018-09-15 Thread Jan via Digitalmars-d-learn
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?

2018-09-15 Thread Paul Backus via Digitalmars-d-learn

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

2018-09-15 Thread Vladimir Panteleev via Digitalmars-d-learn
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

2018-09-15 Thread Vladimir Panteleev via Digitalmars-d-learn
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

2018-09-15 Thread Anonymouse via Digitalmars-d-learn
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?

2018-09-15 Thread Adam D. Ruppe via Digitalmars-d-learn
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?

2018-09-15 Thread Gary Willoughby via Digitalmars-d-learn

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)

2018-09-15 Thread Josphe Brigmo via Digitalmars-d-learn

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).


Re: array to string functional?

2018-09-15 Thread bauss via Digitalmars-d-learn

On Saturday, 15 September 2018 at 06:16:59 UTC, bauss wrote:

On Friday, 14 September 2018 at 20:43:45 UTC, SrMordred wrote:


What you want is std.range.chunks


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;


They're not strings, because they're now 4 ranges of integers.

Then you map each of those 4 integer ranges into 4 strings.


Oh wait I didn't see your first map!(to!string)

I take back what I just said.


Re: array to string functional?

2018-09-15 Thread bauss via Digitalmars-d-learn

On Friday, 14 September 2018 at 20:43:45 UTC, SrMordred wrote:


What you want is std.range.chunks


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;


They're not strings, because they're now 4 ranges of integers.

Then you map each of those 4 integer ranges into 4 strings.


Re: remove file access denied(remove broke)

2018-09-15 Thread bauss via Digitalmars-d-learn

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.