The @@@BUG@@@ the size of China - std.conv.d - Target parse(Target, Source)(ref Source s, uint radix)
So whilst attempt to convert from a hex string (without the 0x) to int I bumped into the @@@BUG@@@ the size of China https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L2270 Is there a bugzilla issue number tracking this? Searching for conv and parse in the issue tracker didn't turn it up Is this a phobos bug or a compiler bug? I followed the example in the unit test to get a workaround but I don't understand why the workaround works!
Re: The @@@BUG@@@ the size of China - std.conv.d - Target parse(Target, Source)(ref Source s, uint radix)
On Tuesday, 8 December 2015 at 00:40:29 UTC, tsbockman wrote: Someone still needs to review the PR, though. Thanks! Looks like it's been merged already. It was a double problem... I failed to read the bit about advancing the ref and then the old big @@@BUG@@@ comment in the unit test made me think it was a bug. Thanks! Great response, I appreciate it!
Autodecode in the wild and An Awful Hack to std.regex
Don't you just hate it when you google a problem and find a post
from yourself asking the same question?
In 2013 I ran into the UTF8 invalid char autodecode UTFException,
and the answer then was "use std.encoding.sanitize" and my
opinion looking at the implementation, was then, as is now... Eww!
Since then, I'm glad to see Walter Bright agrees that autodecode
is problematic.
http://forum.dlang.org/thread/nh2o9i$hr0$1...@digitalmars.com
After wading through 46 pages of that, and Jack Stouffers handy
blog entry and the longish discussion thread on it...
https://forum.dlang.org/post/eozguhavggchzzruz...@forum.dlang.org
Maybe I missed something.
What am I supposed to do here in 2016?
I was happily churning through 25 gigabytes of data with
foreach( line; File( file).byLine()) {
auto c = line.matchFirst( myRegex);
.
.
When I hit an invalid codepoint...Again.
What is an efficient (elegant) solution?
An inelegant solution was to hack into the point that throws the
exception and "Do It Right" (for various values of Right)
diff -u /usr/include/dmd/phobos/std/regex/internal/ir.d{~,}
--- /usr/include/dmd/phobos/std/regex/internal/ir.d~ 2015-12-03
14:41:31.0 +1300
+++ /usr/include/dmd/phobos/std/regex/internal/ir.d 2016-07-28
11:04:55.525480585 +1200
@@ -591,7 +591,7 @@
pos = _index;
if(_index == _origin.length)
return false;
-res = std.utf.decode(_origin, _index);
+res = std.utf.decode!(UseReplacementDchar.yes)(_origin,
_index);
return true;
}
@property bool atEnd(){
That "Works For Me".
But it vaguely feels to me that that template parameter needs to
be trickled all the way up the regex engine.
Re: Autodecode in the wild and An Awful Hack to std.regex
On Thursday, 28 July 2016 at 15:48:58 UTC, Seb wrote: We call them DIP (D Improvement Proposals) and I think it's a lot more productive way to discuss improvements than in the forum. Eh. I hoped that somewhere in that explosion of discussion on the topic the problem had been solved and I had just missed it and merely had to use that. Also this idea is a bit immature for a DIP... I haven't look at the regex code beyond the the stack trace it died on. ie. * Would this even be a Good Idea for a dip or is it better solve by another existing means? * I only inspected and changed one occurrence of decode (the one that broke) is there any other route in the regex engine that could throw a UTFException? * Would adding an additional template parameter with default break existing code? Or would I have to provide a shim?
Momentary Eh?! for a Dynamic Language Programmmer. Tuples vs Arrays. Just rambling.
I guess between perl and Ruby and Scheme etc. I got used to creating hybrid containers Want a pair of [string, fileList]? Just make an Array with two items, one a string, one and array of strings. Done. D barfed... leaving me momentarily stunned... then Oh Yes, type safety, Tuple's are the answer where Tuples where Tuples... Eventually found http://dlang.org/tuple.html and more specifically the somewhat unexpectedly named http://dlang.org/phobos/std_typecons.html and off I went... I do have a personal design guideline of when you adding too much behaviour to a heterocontainer, refactor into a class. But I guess I have never realised how often I do casually create heterogenous containers Just rambling and musing.
Re: Momentary Eh?! for a Dynamic Language Programmmer. Tuples vs Arrays. Just rambling.
On Monday, 23 June 2014 at 21:26:19 UTC, Chris Williams wrote: More likely what you want are variants: Hmm. Interesting. Yes, Variant and VariantArray are much closer to the dynamic language semantics... But the interesting thing is Tuple is much closer to "What I Mean" when I create these things. I probably should used Rubies http://ruby-doc.org/core-2.0/Struct.html but apart from naming the elements it gives me nothing beyond more keystrokes to enter. Tuple is very similar, but also grants type safety.
Re: Momentary Eh?! for a Dynamic Language Programmmer. Tuples vs Arrays. Just rambling.
On Monday, 23 June 2014 at 21:49:29 UTC, Ary Borenszweig wrote: Union types are very common (I use them every day), and IMHO it's very nice to have them included in the language (either built-in or as a library solution). As a library solution I would do something like this: Union!(int, string)[] elements; Hmm. egrepping through /usr/include/dmd fails to find '\bUnion\b', are you sure you don't mean Algebraic?
Re: very short pipeShell program
Ali, of course, is right. The only thing I'd add is for a Windowsy programmer (unless you have cygwin installed) you probably want something like "cmd.exe" instead of bash.
Another rambling musing by a Dynamic Programmer - map!
So in Ruby and R and Scheme and... I have happily used map / collect for years and years. Lovely thing. So I did the dumb obvious of string[] stringList = map!...; And D barfed, wrong type, some evil voldemort thing again. So.. auto stringList = map!; and we're good.. and happily use it as foreach( s; stringList) Suddenly the words in the map! documentation made sense to me... unlike Ruby, map doesn't allocate and populate an array. It just returns a lazy range. No array is allocated (unless I ask for one), it just does the lambda when I want it in the foreach! Cool! Very very cunning. Very light on resources. I itch to get D working in the OpenEmbedded environment...
Re: Benchmark games, Rust, big ints and Pi
On Monday, 10 February 2014 at 22:19:19 UTC, bearophile wrote: http://dpaste.dzfl.pl/821527e71343 Your paste has expired / no longer there but the subject has come up again... http://www.wilfred.me.uk/blog/2014/10/20/the-fastest-bigint-in-the-west/ https://lobste.rs/s/sfie8j/the_fastest_bigint_in_the_west I thought to take a poke at it from this point of view. Ruby "wins" the game for shortest code... I wondered whether D could score high both on the terse/readable and speed categories. Do you still have your implementation hanging around?
Prefer Signed or Unsigned in D?
C/C++ discussion here http://blog.robertelder.org/signed-or-unsigned-part-2/ D rules here... http://dlang.org/type.html#integer-promotions
Re: Prefer Signed or Unsigned in D?
On Wednesday, 2 September 2015 at 11:03:00 UTC, ponce wrote: On Tuesday, 1 September 2015 at 23:06:50 UTC, John Carter wrote: C/C++ discussion here http://blog.robertelder.org/signed-or-unsigned-part-2/ D rules here... http://dlang.org/type.html#integer-promotions Everything Bjarne said still applies equally to D code, since integer promotion is identical with C from what I understand. Hmm. What Robert Elder says also applies still. And in my world his argument about undefined behavior carries weight. Bugs that emerge from different optimizations / different versions of the compiler / on different CPU's are nightmares in my domain. Here is a bug that existed in the JDK for 9 years (and probably in many other places) http://googleresearch.blogspot.co.nz/2006/06/extra-extra-read-all-about-it-nearly.html So given the advice on mixing unsigned and signed, and the complexity of Dominikus's code to get signed and unsigned code to compare sanely Maybe if his code becomes standard in D... Yup, mixing signed and unsigned is A Bad Thing, and you best go with whatever your base libraries give you. The whole problem http://www.di.unipi.it/~ruggieri/Papers/semisum.pdf ...makes me feel vaguely ill and long for a Numerical Tower. I really must get around to benchmarking BigInt
Re: Prefer Signed or Unsigned in D?
On Wednesday, 2 September 2015 at 21:43:17 UTC, ponce wrote: Additionally, I was said weeks ago on this NG that and signed overflow in D is not actually Undefined Behaviour. Interesting.. The reference is fairly terse on exactly what happens, is it more formally specified anywhere? In which case Elder's objection melts away for D and becomes explicitly "prefer signed for D, but don't mix". For integral operands, the *, /, and % correspond to multiply, divide, and modulus operations. For multiply, overflows are ignored and simply chopped to fit into the integral type.
