Re: Line endings when redirecting output to file on windows.
On 6/3/18 12:24 PM, Bastiaan Veelo wrote: On Sunday, 3 June 2018 at 15:42:48 UTC, rikki cattermole wrote: On 04/06/2018 3:24 AM, Bastiaan Veelo wrote: I need some help understanding where extra '\r' come from when output is redirected to file on Windows. First, this works correctly: rdmd --eval="(\"hello\" ~ newline).toFile(\"out.txt\");" As expected, out.txt contains "hello\r\n". I would expect the following to do the same, but it doesn't: rdmd --eval="write(\"hello\" ~ newline);" > out.txt Now out.txt contains "hello\r\r\n". Who is doing the extra conversion here, and how do I stop it? Thanks! Bastiaan. That would be cmd. Not sure you can stop it without piping it after rdmd to remove the \r. No, it's not cmd. It's File, or more specifically, FILE * from C. Thanks. It is starting to dawn on me that I shouldn't use `newline` and `toFile` to write text files, but rather always use "\n" as line ending and use `write` for both writing to stdout and file. rdmd --eval="File(\"out.txt\", \"w\").write(\"hello\n\");" and rdmd --eval="write(\"hello\n\");" > out.txt both produce "hello\r\n" on Windows. Am I correct, or is there a more idiomatic way of writing strings to text files? Windows C library has this bizarro mode for FILE * called "text" mode, which is the default. In this mode, it scans all output, and anywhere it sees a '\n', it replaces it with "\r\n". the `newline` variable contains "\r\n". So what you have done is, output "hello\r\n", and File helpfully replaces that "\n" to "\r\n", giving you "\r\r\n". The correct answer, as you have guessed, is don't use newline :) Just use \n. It's portable, and line endings on Windows are less important these days. If you want to turn off text mode, set the mode to binary, as this should work (note the "wb" mode): rdmd --eval="File(\"out.txt\", \"wb\").write(\"hello\" ~ newline);" Note there is also a rawWrite method, which temporarily turns it into binary mode, and will work as well: rdmd --eval="File(\"out.txt\", \"w\").rawWrite(\"hello\" ~ newline);" -Steve
Re: Convert a huge SQL file to CSV
On 6/3/18 2:04 AM, biocyberman wrote: On Friday, 1 June 2018 at 10:15:11 UTC, Martin Tschierschke wrote: On Friday, 1 June 2018 at 09:49:23 UTC, biocyberman wrote: I need to convert a compressed 17GB SQL dump to CSV. A workable solution is to create a temporary mysql database, import the dump, query by python, and export. But i wonder if there is something someway in D to parse the SQL file directly and query and export the data. I imagine this will envolve both parsing and querying because the data is stored in several tables. I am in the process of downloading the dump now so I can’t give excerpt of the data. You don't need python: https://michaelrigart.be/export-directly-mysql-csv/ SELECT field1, field2 FROM table1 INTO OUTFILE '/path/to/file.csv' FIELDS TERMINATED BY ',' ENCLOSED BY '"' FIELDS ESCAPED BY '\' LINES TERMINATED BY '\n'; Most important: INTO OUTFILE : here you state the path where you want MySQL to store the CSV file. Keep in mind that the path needs to be writeable for the MySQL user You can write a parser for SQL in D, but even if the import into mysql would take some time, it's only compute time and not yours. Regards mt. Ah yes, thank you Martin. I forgot that we can do a "batch" SQL query where mysql server can parse and run query commands. So no need for Python. But I am still currently waiting for the import to finish the importing of mysql dump. It took 18 hours and is still counting! The whole mysql database is 68GB at the moment. Can we avoid the import and query the database dump directly? Well, it could be done quick-and-dirty by simply ignoring most of SQL syntax, and focusing on the actual things used in the dump. mysqldump is pretty consistent with how it outputs data. You might even be able to do it with an awk script :) -Steve
Re: Confusion/trying to understand CTFE keywords
On Monday, June 04, 2018 14:05:28 gdelazzari via Digitalmars-d-learn wrote:
> On Monday, 4 June 2018 at 03:18:05 UTC, Jonathan M Davis wrote:
> > So, while static _seems_ somewhat inconsistent at first, the
> > way it's used is pretty consistent overall. The main
> > inconsistency is the places where static is essentially
> > implicit rather than explicit (such as module-level variables
> > or structs nested in other structs or classes).
>
> I'm not getting this however. I mean, sure, it's totally
> consistent if you consider the cases you described, but what I
> meant is that in a piece of code like
>
> static if (a == 3)
> {
>// stuff...
> }
> static else if (a == 2)
> {
>// other stuff...
> }
> else
> {
>// etc...
> }
>
> the "static" keyword has a different meaning, in this case it
> means that the if gets evaluated at compile time. This is the
> kind of inconsistency I was talking about.
Yeah, that would be inconsistent with the others. I'd forgotten about those
when I wrote my reply. Basically, in the case of static if, static foreach,
and static assert, it just means that it's the compile-time variant of the
construct in question. The keyword reuse works well, but it is inconsistent
with the other uses. I guess that it could be argued that they don't have a
context, because they're done at compile-time, whereas the runtime variants
are run within a specific context, but I think that that's stretching
things. However, static used with static if, static foreach, and static
assert seems to be very easy for people to understand, whereas some of the
other ways it's used often cause confusion at first. Certainly, it seems to
be far less confusing for folks than using enum for manifest constants has
been.
> Of course "static if" doesn't sound bad at all, it somehow
> conveys the idea of what it actually does. My confusion was
> regarding the fact that "static" is also used for other things
> (the ones you described) and then I would also expect that, to
> define a compile-time value, I would use the same keyword again,
> like
>
> static myCompileTimeValue = 5 * 2;
>
> instead of
>
> enum myCompileTimeValue = 5 * 2;
>
> of course this wouldn't be possible with the keyword "static",
> since `static val = 4;` would have a totally different meaning in
> the language, and that's why "enum" is used I guess. But then why
> not `enum if (...) { ... }`? Again, forget about the keywords
> themselves, I'm just talking about using the same one which is
> different from keywords that also do other different (or
> completely different, or slightly different, but still different)
> things. I get that "enum" has somewhat of a sense, when doing
> `enum val = 4;`, after reading the related book chapter, but
> yeah... that's not the problem, as I hope you now understood what
> I mean.
Using enum instead of static in contexts such as static if would be using
enum in a drastically different context from where enum is normally used
(the issue of manifest constants already causes a fair bit of confusion),
whereas static seems fairly natural there, and folks are used to static
meaning multiple things. In both C/C++ and D, static gets used in multiple
contexts where most folks would think that they were completely different
when in fact it's possible to come up with a definition that covers most or
all of the contexts in which it's used. So, regardless of whether static is
actually used consistently, it doesn't feel consistent. So, reusing it for
static if is likely to seem much more reasonable to many folks, whereas I
think that relatively few would think that reusing enum for that would have
made sense. But language design is a bit of an art. It's an interesting
combination of doing what makes sense from the standpoint of the compiler
writer and what makes sense from the standpoint of the programmer using the
language.
> This argument I started was kind of a first-impression as a
> newcomer to the language, with the hope of getting to better
> understand it. Also I thought it's beneficial for the community
> to have feedback from new users.
Constructive feedback is always welcome. And even if nothing in the language
gets changed because of feedback, it does help us understand where people
need help learning the language.
- Jonathan M Davis
Re: Confusion/trying to understand CTFE keywords
On Monday, 4 June 2018 at 03:18:05 UTC, Jonathan M Davis wrote:
I think that part of your problem here comes from the fact that
you think of enum or static are "CTFE keywords." That's not
what they are at all. Yes, they can trigger CTFE, but they're
not the only way.
...
Thank you very much for the extensive explanation, I really
appreciate it. I'm slowly getting the point here, also by reading
the relevant parts of the book you linked.
I was aware of the meaning of the static keyword (coming from
other languages where it has similar meaning), but your re-cap
was great anyway since I now have a clear view of how exactly
works in D with the various features of the language.
So, while static _seems_ somewhat inconsistent at first, the
way it's used is pretty consistent overall. The main
inconsistency is the places where static is essentially
implicit rather than explicit (such as module-level variables
or structs nested in other structs or classes).
I'm not getting this however. I mean, sure, it's totally
consistent if you consider the cases you described, but what I
meant is that in a piece of code like
static if (a == 3)
{
// stuff...
}
static else if (a == 2)
{
// other stuff...
}
else
{
// etc...
}
the "static" keyword has a different meaning, in this case it
means that the if gets evaluated at compile time. This is the
kind of inconsistency I was talking about.
Of course "static if" doesn't sound bad at all, it somehow
conveys the idea of what it actually does. My confusion was
regarding the fact that "static" is also used for other things
(the ones you described) and then I would also expect that, to
define a compile-time value, I would use the same keyword again,
like
static myCompileTimeValue = 5 * 2;
instead of
enum myCompileTimeValue = 5 * 2;
of course this wouldn't be possible with the keyword "static",
since `static val = 4;` would have a totally different meaning in
the language, and that's why "enum" is used I guess. But then why
not `enum if (...) { ... }`? Again, forget about the keywords
themselves, I'm just talking about using the same one which is
different from keywords that also do other different (or
completely different, or slightly different, but still different)
things. I get that "enum" has somewhat of a sense, when doing
`enum val = 4;`, after reading the related book chapter, but
yeah... that's not the problem, as I hope you now understood what
I mean.
If you haven't yet, I'd suggest reading
http://ddili.org/ders/d.en/index.html
Even if you understand most of the content already, it will
probably help fill in some of the holes you have in your
understanding, and depending on how much you've done with D, it
may contain quite a bit of new content that will help you out.
- Jonathan M Davis
Again, thank you very much for the time you took to answer with
that amount of quality information, I really appreciate it. And I
also appreciate the suggestion about the book, which I'll read as
soon as I can. Maybe I'm missing somewhat of a broader view of
the language that, once acquired, will make me understand the
real meanings/reasons behind those keywords.
This argument I started was kind of a first-impression as a
newcomer to the language, with the hope of getting to better
understand it. Also I thought it's beneficial for the community
to have feedback from new users.
Thank you very much again,
Giacomo
Re: how to define infix function
On Saturday, 2 June 2018 at 23:17:48 UTC, Simen Kjærås wrote:
unittest
{
import std.algorithm.comparison;
alias min = Operator!(std.algorithm.comparison.min);
assert(1 /min/ 3 == 1);
}
Why not:
alias Δ = Operator!(std.algorithm.comparison.min);
assert(1 /Δ/ 3 == 1);
To improve readibility :)
