== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
On Saturday 17 July 2010 22:10:07 strtr wrote:
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
On Saturday 17 July 2010 18:59:18 strtr wrote:
That is [dollar sign, euro sign]
The reason I post it
On Saturday 17 July 2010 23:01:28 strtr wrote:
Cheated? I thought that you were trying to figure out why the code wasn't
d oing
what you expected it to be doing. So, of course I ran it.
Though, it's more likely that I have an x86 emulator in my brain which
can run
dmd than that I
On Saturday 17 July 2010 22:52:21 strtr wrote:
I think I'll start subject tagging my posts: [D1/D2]
std.stdio in D1 doesn't mention a write function and feeding the writef
function an illegal UTF string will result in a UTF exception.
With this information, what do you think the output
On Sunday 18 July 2010 00:38:38 Jonathan M Davis wrote:
On Saturday 17 July 2010 22:52:21 strtr wrote:
I think I'll start subject tagging my posts: [D1/D2]
std.stdio in D1 doesn't mention a write function and feeding the writef
function an illegal UTF string will result in a UTF exception.
On Sunday 18 July 2010 00:46:36 Jonathan M Davis wrote:
I'll file a bug report
- Jonathan M Davis
Wait. That's not the problem. Or at least, that's not the problem that needs to
be reported. The problem is that we're not compiling with -w. If you compile
with -w, then statements such as
I am doing this and it is throwing an exception.
string d = readln( );
int i = to!int( d );
I tried
string d = 50;
int i = to!int( d );
and that worked ok.
Jonathan M Davis:
You should pretty much never deal with each individual char or wchar in a
string
or wstring. Do the conversion to dchar or dstring if you want to access
individual characters. You can also use std.utf.stride() to iterate over to
the
next code unit which starts a code
On Sunday 18 July 2010 04:13:03 bearophile wrote:
Jonathan M Davis:
You should pretty much never deal with each individual char or wchar in a
string or wstring. Do the conversion to dchar or dstring if you want to
access individual characters. You can also use std.utf.stride() to
iterate
Andrei checked readf in a few days ago:
http://www.dsource.org/projects/phobos/changeset/1721
So, it should be in the next release (end of July/beginning of August?)
Would readf help you?
For files, there is also std.file.slurp if you know the way your file is
formatted:
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
On Sunday 18 July 2010 04:13:03 bearophile wrote:
Jonathan M Davis:
You should pretty much never deal with each individual char or wchar in a
string or wstring. Do the conversion to dchar or dstring if you want to
access
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
On Sunday 18 July 2010 00:46:36 Jonathan M Davis wrote:
I'll file a bug report
- Jonathan M Davis
Wait. That's not the problem. Or at least, that's not the problem that needs
to
be reported. The problem is that we're not
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
On Saturday 17 July 2010 23:01:28 strtr wrote:
Cheated? I thought that you were trying to figure out why the code wasn't
d oing
what you expected it to be doing. So, of course I ran it.
Though, it's more likely that I
On Sunday 18 July 2010 06:16:09 strtr wrote:
I agree with the warning. A good warning would get people to read up on
UTF. And if you really want to have char you'll need to cast:
foreach(cast(char)c; chars)
Actually, the cast would be totally unnecessary. Putting
foreach(char c; chars)
would
I'm trying to link a C routine to a D program, passing string
parameters, but I keep getting segmentation errors.
As you can see, these are simple test routines, so the names don't
reflect current status, but merely where I intend to arrive...but I've
hit severe roadblocks.
(FWIW, I've tried
Have a look at the unittest of std.json: the only non-trivial test is commented
out as currently broken.
Smells like std.json has deep problems when it comes to real-world examples.
But then: running the unittest shows that the actual result is
On 07/18/2010 01:56 PM, bearophile wrote:
Charles Hixson:
extern (C) void dbdefine (char[] inStr, ref char[255] outStr);
I think C and D char[] don't go well together. D arrays are 2-word long
structs. Try again with something simpler, like a pointer and length.
Bye,
bearophile
On Sunday 18 July 2010 10:59:21 strtr wrote:
I totally agree that putting a cast there is probably not really a solution
(or legal).
Warnings for all non-dchar types.
Is there anybody using foreach(c;chars) || foreach(char c;chars) correctly
(which couldn't be done with ubytes)?
As soon as
Hello Mario,
That is, shall we produce canonical JSON text at the price of
efficiency.
Or, shall the perfect implementation of JSON objects as associative
arrays be dropped?
Or, what else?
Unless JSON requiers that the keys be in some order, the correct solution
is to make the check
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
On Sunday 18 July 2010 10:59:21 strtr wrote:
I totally agree that putting a cast there is probably not really a solution
(or legal).
Warnings for all non-dchar types.
Is there anybody using foreach(c;chars) || foreach(char
On Sunday 18 July 2010 17:15:15 strtr wrote:
I actually knew about unicode, but I mistakenly thought a char to be a code
point (thus variable in size).
Somehow I missed any documentation telling me otherwise.
Now that I look for it it actually says:
char |unsigned 8 bit UTF-8
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
On Sunday 18 July 2010 00:46:36 Jonathan M Davis wrote:
I'll file a bug report
- Jonathan M Davis
Wait. That's not the problem. Or at least, that's not the problem that needs
to
be reported. The problem is that we're not
On Sunday 18 July 2010 17:36:58 strtr wrote:
I don't agree with this bug report because of two reasons.
1. Warnings are supposed to be warnings, not errors. If you want to see
those warnings you'll use -w.
What you probably want is for the dmd to have a -!w flag instead (warnings
by
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
On Sunday 18 July 2010 17:36:58 strtr wrote:
I don't agree with this bug report because of two reasons.
1. Warnings are supposed to be warnings, not errors. If you want to see
those warnings you'll use -w.
What you
On Sunday 18 July 2010 19:14:11 strtr wrote:
I'm not sure whether you missed my point or are simple thinking out loud
about unreachable code being a warning.
My point was that the unreachable warning was wrong as there is no
unreachable code.
Except that there _is_. You just can't see it.
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
On Sunday 18 July 2010 19:14:11 strtr wrote:
I'm not sure whether you missed my point or are simple thinking out loud
about unreachable code being a warning.
My point was that the unreachable warning was wrong as there is no
On Sunday 18 July 2010 19:47:37 strtr wrote:
Thanks for the explanation!
But what you are talking about is implementation, nowhere in the spec does
it say anything like this (or did I just miss it :).
I could find only this about scope(failure):
scope(failure) executes
26 matches
Mail list logo
