Re: Why I won't fix phobos bugs anymore

On Friday, 3 June 2016 at 05:18:49 UTC, Patrick Schluter wrote: On Thursday, 2 June 2016 at 20:20:58 UTC, Andrei Alexandrescu wrote: On 06/02/2016 03:41 PM, Basile B. wrote: Yesterday I've took the decision not to propose anymore PR for Phobos bugfixes, even if most of the time it's easy. 1)

Re: Why I won't fix phobos bugs anymore

On Thursday, 2 June 2016 at 20:20:58 UTC, Andrei Alexandrescu wrote: On 06/02/2016 03:41 PM, Basile B. wrote: Yesterday I've took the decision not to propose anymore PR for Phobos bugfixes, even if most of the time it's easy. 1) It can take up to 2 or 3 weeks until a "phobos bugfix" get

Re: Phobos needs a (part-time) maintainer

On Thursday, 2 June 2016 at 21:04:46 UTC, qznc wrote: On Thursday, 2 June 2016 at 20:59:52 UTC, Basile B. wrote: Eventually I'll come back to bugfix if they take Jake, but not you Seb. For a reason or another I don't like you wilzbach. You are frustrated. I get that. Don't make this

Re: Free the DMD backend

On Thursday, 2 June 2016 at 18:16:33 UTC, Basile B. wrote: It's also that LDC is at front end 2.070 and GDC 2.067 ;););) GDC is actively maintained and it would have the latest features if more developers come, what would happen if it would be the reference compiler.

Re: D's Auto Decoding and You

On Thursday, 2 June 2016 at 21:33:02 UTC, Andrei Alexandrescu wrote: Should I assume some normalization occurred on the way? I'm just looking over std.uni's section on normalization and realizing that I had basically no idea what it is or what's going on. The wikipedia page on unicode

Re: [OT] Things I like about Andrei

On 03/06/2016 2:17 PM, Adam D. Ruppe wrote: A lot of us, myself included, have been very critical of Andrei lately but I want to list of the excellent work he has done over the years: First, early D was very different to D of today. Andrei changed that, for the better. He's a genius of

Re: [OT] Things I like about Andrei

He's also very good looking!! That makes a difference! ;)

Re: D's Auto Decoding and You

On Thursday, 2 June 2016 at 21:31:39 UTC, Jack Stouffer wrote: On Thursday, 2 June 2016 at 21:21:50 UTC, jmh530 wrote: I was a little confused by something in the main autodecoding thread, so I read your article again. Unfortunately, I don't think my confusion is resolved. I was trying one of

Re: [OT] Things I like about Andrei

On Friday, 3 June 2016 at 02:17:51 UTC, Adam D. Ruppe wrote: A lot of us, myself included, have been very critical of Andrei lately but I want to list of the excellent work he has done over the years: First, early D was very different to D of today. Andrei changed that, for the better. He's

Re: Lifetime tracking

On Friday, 3 June 2016 at 00:40:09 UTC, Stefan Koch wrote: On Friday, 3 June 2016 at 00:31:31 UTC, Walter Bright wrote: If they cover the cases that matter, it's good. Rust has the type system annotations you want, but Rust has a reputation for being difficult to write code for. I think we

[OT] Things I like about Andrei

A lot of us, myself included, have been very critical of Andrei lately but I want to list of the excellent work he has done over the years: First, early D was very different to D of today. Andrei changed that, for the better. He's a genius of innovation with templates and good at getting to

Re: Broken links continue to exist on major pages on dlang.org

On Thursday, 2 June 2016 at 20:34:24 UTC, Andrei Alexandrescu wrote: Interestingly it came as encouraging and empowering some fledgling work that had compelling things going for it (including but not limited to enthusiastic receipt in this forum), which ironically is exactly what you just

Re: Unicode Normalization (and graphemes and locales)

On Friday, 3 June 2016 at 00:14:13 UTC, Walter Bright wrote: 5. Normalization, graphemes, and locales should all be explicitly opt-in with corresponding library code. Add decoding to that list and we're right there with you. 7. At some point, as the threads on autodecode amply illustrate,

Re: Lifetime tracking

On Friday, 3 June 2016 at 00:31:31 UTC, Walter Bright wrote: If they cover the cases that matter, it's good. Rust has the type system annotations you want, but Rust has a reputation for being difficult to write code for. I think we can incorporate typesafe borrowing without making it

Re: Lifetime tracking

On 6/2/2016 5:21 PM, Walter Bright wrote: Please give an example. I see you did, so ignore that.

Re: Lifetime tracking

On 6/2/2016 4:29 PM, Timon Gehr wrote: // need to know that lifetime of a ends not after lifetime of b void assign(S,T)(ref S a, T b){ a = b; } void foo(scope int* k){ void bar(){ scope int* x; // need to check that lifetime of x ends not after lifetime of k

Re: Lifetime tracking

On 6/2/2016 4:05 PM, Timon Gehr wrote: I'd like to point out again why that design is inadequate: Whenever the type checker is using a certain piece of information to check validity of a program, there should be a way to pass that kind of information across function boundaries. Otherwise the

Re: The Case Against Autodecode

On 6/2/2016 3:27 PM, John Colvin wrote: I wonder what rationale there is for Unicode to have two different sequences of codepoints be treated as the same. It's madness. There are languages that make heavy use of diacritics, often several on a single "character". Hebrew is a good example.

Re: The Case Against Autodecode

On 6/2/2016 2:25 PM, deadalnix wrote: On Thursday, 2 June 2016 at 20:27:27 UTC, Walter Bright wrote: I wonder what rationale there is for Unicode to have two different sequences of codepoints be treated as the same. It's madness. To be able to convert back and forth from/to unicode in a

Unicode Normalization (and graphemes and locales)

On 6/2/2016 4:29 PM, Jonathan M Davis via Digitalmars-d wrote: > How do you suggest that we handle the normalization issue? Should we just > assume NFC like std.uni.normalize does and provide an optional template > argument to indicate a different normalization (like normalize does)? Since >

Re: Areas of D usage

On Thursday, 2 June 2016 at 21:47:13 UTC, qznc wrote: On Thursday, 2 June 2016 at 13:59:13 UTC, Seb wrote: If I left out an area or you miss an application/usage - please let me know! The Javascript JIT Compiler Higgs: https://github.com/higgsjs/Higgs Vibe.d needs some examples. Looks like

Re: non empty slices

On Thursday, 2 June 2016 at 23:44:49 UTC, ag0aep6g wrote: On 06/03/2016 01:35 AM, ag0aep6g wrote: The alternative `peek` method is not documented to throw an exception, but it's not @nogc either. No idea why. Maybe Algebraic does GC allocations internally. I wouldn't know for what, though. Or

Re: The Case Against Autodecode

On 6/2/2016 4:29 PM, Jonathan M Davis via Digitalmars-d wrote: How do you suggest that we handle the normalization issue? Started a new thread for that one.

[Issue 14403] DDox: std.algorithm index links are 404

https://issues.dlang.org/show_bug.cgi?id=14403 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/dlang.org https://github.com/dlang/dlang.org/commit/8e12e01f388097bc947ef8e7ace1fef5926b3521 Merge pull request #1322 from s-ludwig/master Fix

Re: Lifetime tracking

On Thursday, 2 June 2016 at 23:29:57 UTC, Timon Gehr wrote: On 03.06.2016 01:12, tsbockman wrote: On Thursday, 2 June 2016 at 23:05:40 UTC, Timon Gehr wrote: Whenever the type checker is using a certain piece of information to check validity of a program, there should be a way to pass that

Re: Lifetime tracking

On 03.06.2016 01:29, Timon Gehr wrote: [1] It might be possible to get that example to pass the type checker with 'return' annotations only if I change 'ref' to 'out', but often more than two lifetimes are involved, and then it falls flat on its face. To be slightly more explicit: void

Re: non empty slices

On Thursday, 2 June 2016 at 23:35:53 UTC, ag0aep6g wrote: It's the Algebraic. The `get` method isn't @nogc. The documentation [1] says that it may throw an exception, which is most probably being allocated through the GC. So that's a reason why it can't be @nogc. The alternative `peek`

Re: non empty slices

On 06/03/2016 01:35 AM, ag0aep6g wrote: The alternative `peek` method is not documented to throw an exception, but it's not @nogc either. No idea why. Maybe Algebraic does GC allocations internally. I wouldn't know for what, though. Or it misses a @nogc somewhere. I've looked at the source to

Re: non empty slices

On 06/03/2016 01:17 AM, Alex wrote: But still, I can't mark the f-method @nogc, and this is not due to the writeln calls... why GC is invoked, although everything is known and no memory allocation should happen? It's the Algebraic. The `get` method isn't @nogc. The documentation [1] says that

Re: Lifetime tracking

On 03.06.2016 01:12, tsbockman wrote: On Thursday, 2 June 2016 at 23:05:40 UTC, Timon Gehr wrote: Whenever the type checker is using a certain piece of information to check validity of a program, there should be a way to pass that kind of information across function boundaries. Otherwise the

Re: The Case Against Autodecode

On Thursday, June 02, 2016 15:48:03 Walter Bright via Digitalmars-d wrote: > On 6/2/2016 3:23 PM, Andrei Alexandrescu wrote: > > On 06/02/2016 05:58 PM, Walter Bright wrote: > >> > * s.balancedParens('〈', '〉') works only with autodecoding. > >> > * s.canFind('ö') works only with autodecoding. It

Re: Creating a "fixed-range int" with opDispatch and/or alias this?

On Wednesday, 1 June 2016 at 19:59:51 UTC, Mark Isaacson wrote: I'm trying to create a type that for all intents and purposes behaves exactly like an int except that it limits its values to be within a certain range [a,b]. Theoretically, I would think this looks something like: ... It looks

Re: The Case Against Autodecode

On Thursday, June 02, 2016 22:27:16 John Colvin via Digitalmars-d wrote: > On Thursday, 2 June 2016 at 20:27:27 UTC, Walter Bright wrote: > > I wonder what rationale there is for Unicode to have two > > different sequences of codepoints be treated as the same. It's > > madness. > > There are

Re: The Case Against Autodecode

On Thursday, June 02, 2016 18:23:19 Andrei Alexandrescu via Digitalmars-d wrote: > On 06/02/2016 05:58 PM, Walter Bright wrote: > > On 6/2/2016 1:27 PM, Andrei Alexandrescu wrote: > >> The lambda returns bool. -- Andrei > > > > Yes, I was wrong about that. But the point still stands with: > > >

Re: non empty slices

On Thursday, 2 June 2016 at 22:17:32 UTC, ag0aep6g wrote: Yeah, can't do it that way. You have only one f_impl call, but want it to go to different overloads based on dynamic information (caseS). That doesn't work. You need three different f_impl calls. You can generate them, so there's

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 21:56:10 UTC, Walter Bright wrote: Yes, you have a good point. But we do allow things like: byte b; if (b == 1) ... Why allowing char/wchar/dchar comparisons is wrong: void main() { string s = "Привет"; foreach (c; s) assert(c != 'Ñ'); }

Re: Lifetime tracking

On Thursday, 2 June 2016 at 23:05:40 UTC, Timon Gehr wrote: On 03.06.2016 00:29, Walter Bright wrote: On 6/2/2016 3:10 PM, Marco Leise wrote: we haven't looked into borrowing/scoped enough That's my fault. As for scoped, the idea is to make scope work analogously to DIP25's 'return ref'. I

Lifetime tracking

On 03.06.2016 00:29, Walter Bright wrote: On 6/2/2016 3:10 PM, Marco Leise wrote: we haven't looked into borrowing/scoped enough That's my fault. As for scoped, the idea is to make scope work analogously to DIP25's 'return ref'. I don't believe we need borrowing, we've worked out another

Re: The Case Against Autodecode

On 03.06.2016 00:23, Andrei Alexandrescu wrote: On 06/02/2016 05:58 PM, Walter Bright wrote: On 6/2/2016 1:27 PM, Andrei Alexandrescu wrote: The lambda returns bool. -- Andrei Yes, I was wrong about that. But the point still stands with: > * s.balancedParens('〈', '〉') works only with

Re: The Case Against Autodecode

On 03.06.2016 00:26, Walter Bright wrote: On 6/2/2016 3:11 PM, Timon Gehr wrote: Well, this is a somewhat different case, because 1 is just not representable as a byte. Every value that fits in a byte fits in an int though. It's different for code units. They are incompatible both ways.

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 22:20:49 UTC, Walter Bright wrote: On 6/2/2016 2:05 PM, tsbockman wrote: Presumably if someone marks their own PR as "do not merge", it means they're planning to either close it themselves after it has served its purpose, or they plan to fix/finish it and then

Re: The Case Against Autodecode

On 6/2/2016 3:10 PM, Marco Leise wrote: we haven't looked into borrowing/scoped enough That's my fault. As for scoped, the idea is to make scope work analogously to DIP25's 'return ref'. I don't believe we need borrowing, we've worked out another solution that will work for ref counting.

Re: Why does DMD on Debian need xdg-utils

On Thursday, 2 June 2016 at 21:32:28 UTC, Mathias Lang wrote: It shouldn't be necessary. I believe that is because of `dmd -man`, which open a web browser. That's an apt-d issue (in hopefully Jordi Sayol will read this) which prevents using this repository if your machine has no X (I guess

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 20:27:27 UTC, Walter Bright wrote: On 6/2/2016 12:34 PM, deadalnix wrote: On Thursday, 2 June 2016 at 19:05:44 UTC, Andrei Alexandrescu wrote: Pretty much everything. Consider s and s1 string variables with possibly different encodings (UTF8/UTF16). * s.all!(c =>

Re: The Case Against Autodecode

On 6/2/2016 3:11 PM, Timon Gehr wrote: Well, this is a somewhat different case, because 1 is just not representable as a byte. Every value that fits in a byte fits in an int though. It's different for code units. They are incompatible both ways. Not exactly. (c == 'ö') is always false for

Re: The Case Against Autodecode

On 06/02/2016 05:58 PM, Walter Bright wrote: On 6/2/2016 1:27 PM, Andrei Alexandrescu wrote: The lambda returns bool. -- Andrei Yes, I was wrong about that. But the point still stands with: > * s.balancedParens('〈', '〉') works only with autodecoding. > * s.canFind('ö') works only with

Re: non empty slices

On 06/02/2016 11:37 PM, Alex wrote: Just tried this instead of your f-function: void f(int[] arr) { A result; import std.meta; alias TL = AliasSeq!(Empty, int, Many!int); int caseS; switch (arr.length) { case 0: result = Empty.init; caseS = 0; break;

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 22:03:01 UTC, default0 wrote: *sigh* reading comprehension. ... Please do not take what I say out of context, thank you. Earlier you said: The level 2 support description noted that it should be opt-in because its slow. My main point is simply that you

Re: The Case Against Autodecode

Am Thu, 2 Jun 2016 15:05:44 -0400 schrieb Andrei Alexandrescu : > On 06/02/2016 01:54 PM, Marc Schütz wrote: > > Which practical tasks are made possible (and work _correctly_) if you > > decode to code points, that don't already work with code units? > > Pretty

Re: The Case Against Autodecode

On 02.06.2016 23:56, Walter Bright wrote: On 6/2/2016 1:12 PM, Timon Gehr wrote: ... It is not meaningful to compare utf-8 and utf-16 code units directly. Yes, you have a good point. But we do allow things like: byte b; if (b == 1) ... Well, this is a somewhat different case,

Re: Areas of D usage

On Thursday, 2 June 2016 at 21:47:13 UTC, qznc wrote: On Thursday, 2 June 2016 at 13:59:13 UTC, Seb wrote: If I left out an area or you miss an application/usage - please let me know! The Javascript JIT Compiler Higgs: https://github.com/higgsjs/Higgs Wow that's a great example! Vibe.d

Re: non empty slices

On 06/02/2016 10:11 PM, Alex wrote: The cool thing about the Algebraic is as I expected, that it doesn't change it's type... And the hard thing is, that I'm not used to its Empty, Many, ... things yet. I just made those up on the spot. Note that Many is not actually implemented at all. There

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 21:51:51 UTC, tsbockman wrote: On Thursday, 2 June 2016 at 21:38:02 UTC, default0 wrote: On Thursday, 2 June 2016 at 21:30:51 UTC, tsbockman wrote: 1) It does not say that level 2 should be opt-in; it says that level 2 should be toggle-able. Nowhere does it say

Re: The Case Against Autodecode

On 02.06.2016 23:46, Andrei Alexandrescu wrote: On 6/2/16 5:43 PM, Timon Gehr wrote: .̂ ̪.̂ (Copy-paste it somewhere else, I think it might not be rendered correctly on the forum.) The point is that if I do: ".̂ ̪.̂".normalize!NFC.byGrapheme.findAmong([Grapheme("."),Grapheme(",")]) no

Re: The Case Against Autodecode

On 6/2/2016 1:27 PM, Andrei Alexandrescu wrote: The lambda returns bool. -- Andrei Yes, I was wrong about that. But the point still stands with: > * s.balancedParens('〈', '〉') works only with autodecoding. > * s.canFind('ö') works only with autodecoding. It returns always false without. Can

Re: The Case Against Autodecode

On 6/2/2016 1:12 PM, Timon Gehr wrote: On 02.06.2016 22:07, Walter Bright wrote: On 6/2/2016 12:05 PM, Andrei Alexandrescu wrote: * s.all!(c => c == 'ö') works only with autodecoding. It returns always false without. The o is inferred as a wchar. The lamda then is inferred to return a wchar.

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 21:38:02 UTC, default0 wrote: On Thursday, 2 June 2016 at 21:30:51 UTC, tsbockman wrote: 1) It does not say that level 2 should be opt-in; it says that level 2 should be toggle-able. Nowhere does it say which of level 1 and 2 should be the default. 2) It says that

Re: Areas of D usage

On Thursday, 2 June 2016 at 13:59:13 UTC, Seb wrote: If I left out an area or you miss an application/usage - please let me know! The Javascript JIT Compiler Higgs: https://github.com/higgsjs/Higgs Vibe.d needs some examples. Looks like their website does not have any.

Re: The Case Against Autodecode

On 6/2/16 5:43 PM, Timon Gehr wrote: .̂ ̪.̂ (Copy-paste it somewhere else, I think it might not be rendered correctly on the forum.) The point is that if I do: ".̂ ̪.̂".normalize!NFC.byGrapheme.findAmong([Grapheme("."),Grapheme(",")]) no match is returned. If I use your method with dchars,

Re: The Case Against Autodecode

On 6/2/16 5:38 PM, cym13 wrote: Allow me to try another angle: - There are different levels of unicode support and you don't want to support them all transparently. That's understandable. Cool. - The level you choose to support is the code point level. There are many good arguments about

Re: The Case Against Autodecode

On 02.06.2016 23:23, Andrei Alexandrescu wrote: On 6/2/16 5:19 PM, Timon Gehr wrote: On 02.06.2016 23:16, Timon Gehr wrote: On 02.06.2016 23:06, Andrei Alexandrescu wrote: As the examples show, the examples would be entirely meaningless at code unit level. So far, I needed to count the

Re: The Case Against Autodecode

On 6/2/16 5:38 PM, deadalnix wrote: On Thursday, 2 June 2016 at 21:37:11 UTC, Andrei Alexandrescu wrote: On 6/2/16 5:35 PM, deadalnix wrote: On Thursday, 2 June 2016 at 21:24:15 UTC, Andrei Alexandrescu wrote: On 6/2/16 5:20 PM, deadalnix wrote: The good thing when you define works by

Re: non empty slices

On Thursday, 2 June 2016 at 20:11:21 UTC, Alex wrote: On Thursday, 2 June 2016 at 16:21:03 UTC, ag0aep6g wrote: void f(int[] arr) { A a = arrayToA(arr); foreach (T; A.AllowedTypes) { if (T* p = a.peek!T) f_impl(*p); } } You totally hit

Re: The Case Against Autodecode

On 6/2/16 5:37 PM, Andrei Alexandrescu wrote: On 6/2/16 5:35 PM, deadalnix wrote: On Thursday, 2 June 2016 at 21:24:15 UTC, Andrei Alexandrescu wrote: On 6/2/16 5:20 PM, deadalnix wrote: The good thing when you define works by whatever it does right now No, it works as it was designed. --

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 20:29:48 UTC, Andrei Alexandrescu wrote: On 06/02/2016 04:22 PM, cym13 wrote: A:“We should decode to code points” B:“No, decoding to code points is a stupid idea.” A:“No it's not!” B:“Can you show a concrete example where it does something useful?” A:“Sure, look

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 21:37:11 UTC, Andrei Alexandrescu wrote: On 6/2/16 5:35 PM, deadalnix wrote: On Thursday, 2 June 2016 at 21:24:15 UTC, Andrei Alexandrescu wrote: On 6/2/16 5:20 PM, deadalnix wrote: The good thing when you define works by whatever it does right now No, it works

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 21:30:51 UTC, tsbockman wrote: On Thursday, 2 June 2016 at 21:07:19 UTC, default0 wrote: The level 2 support description noted that it should be opt-in because its slow. 1) It does not say that level 2 should be opt-in; it says that level 2 should be toggle-able.

Re: The Case Against Autodecode

On 6/2/16 5:35 PM, deadalnix wrote: On Thursday, 2 June 2016 at 21:24:15 UTC, Andrei Alexandrescu wrote: On 6/2/16 5:20 PM, deadalnix wrote: The good thing when you define works by whatever it does right now No, it works as it was designed. -- Andrei Nobody says it doesn't. Everybody says

Re: The Case Against Autodecode

On 6/2/16 5:35 PM, ag0aep6g wrote: On 06/02/2016 11:27 PM, Andrei Alexandrescu wrote: On 6/2/16 5:24 PM, ag0aep6g wrote: On 06/02/2016 11:06 PM, Andrei Alexandrescu wrote: Nope, that's a radically different matter. As the examples show, the examples would be entirely meaningless at code unit

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 21:24:15 UTC, Andrei Alexandrescu wrote: On 6/2/16 5:20 PM, deadalnix wrote: The good thing when you define works by whatever it does right now No, it works as it was designed. -- Andrei Nobody says it doesn't. Everybody says the design is crap.

Re: The Case Against Autodecode

On 06/02/2016 11:27 PM, Andrei Alexandrescu wrote: On 6/2/16 5:24 PM, ag0aep6g wrote: On 06/02/2016 11:06 PM, Andrei Alexandrescu wrote: Nope, that's a radically different matter. As the examples show, the examples would be entirely meaningless at code unit level. They're simply not

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 21:07:19 UTC, default0 wrote: The level 2 support description noted that it should be opt-in because its slow. 1) It does not say that level 2 should be opt-in; it says that level 2 should be toggle-able. Nowhere does it say which of level 1 and 2 should be the

Re: The Case Against Autodecode

On 6/2/16 5:27 PM, Andrei Alexandrescu wrote: On 6/2/16 5:24 PM, ag0aep6g wrote: Just like there is no single code point for 'a⃗' so you can't search for it in a range of code points. Of course you can. Correx, indeed you can't. -- Andrei

Re: D's Auto Decoding and You

On 6/2/16 5:27 PM, Steven Schveighoffer wrote: On 6/2/16 5:21 PM, jmh530 wrote: On Tuesday, 17 May 2016 at 14:06:37 UTC, Jack Stouffer wrote: If you think there should be any more information included in the article, please let me know so I can add it. I was a little confused by something

Re: D's Auto Decoding and You

On 6/2/16 5:21 PM, jmh530 wrote: On Tuesday, 17 May 2016 at 14:06:37 UTC, Jack Stouffer wrote: If you think there should be any more information included in the article, please let me know so I can add it. I was a little confused by something in the main autodecoding thread, so I read your

Re: D's Auto Decoding and You

On Thursday, 2 June 2016 at 21:21:50 UTC, jmh530 wrote: I was a little confused by something in the main autodecoding thread, so I read your article again. Unfortunately, I don't think my confusion is resolved. I was trying one of your examples (full code I used below). You claim it works, but

Re: Why does DMD on Debian need xdg-utils

It shouldn't be necessary. I believe that is because of `dmd -man`, which open a web browser. That's an apt-d issue (in hopefully Jordi Sayol will read this) which prevents using this repository if your machine has no X (I guess you discovered that on a server, as I did). 2016-06-02 20:17

Re: The Case Against Autodecode

On 02.06.2016 22:51, Andrei Alexandrescu wrote: On 06/02/2016 04:50 PM, Timon Gehr wrote: On 02.06.2016 22:28, Andrei Alexandrescu wrote: On 06/02/2016 04:12 PM, Timon Gehr wrote: It is not meaningful to compare utf-8 and utf-16 code units directly. But it is meaningful to compare Unicode

Re: The Case Against Autodecode

On 6/2/16 5:20 PM, deadalnix wrote: The good thing when you define works by whatever it does right now No, it works as it was designed. -- Andrei

Re: The Case Against Autodecode

On 6/2/16 5:23 PM, Timon Gehr wrote: On 02.06.2016 22:51, Andrei Alexandrescu wrote: On 06/02/2016 04:50 PM, Timon Gehr wrote: On 02.06.2016 22:28, Andrei Alexandrescu wrote: On 06/02/2016 04:12 PM, Timon Gehr wrote: It is not meaningful to compare utf-8 and utf-16 code units directly. But

Re: The Case Against Autodecode

On 02.06.2016 23:20, deadalnix wrote: The sample code won't count the instance of the grapheme 'ö' as some of its encoding won't be counted, which definitively count as doesn't work. It also has false positives (you can combine 'ö' with some combining character in order to get some strange

Re: The Case Against Autodecode

On 6/2/16 5:24 PM, ag0aep6g wrote: On 06/02/2016 11:06 PM, Andrei Alexandrescu wrote: Nope, that's a radically different matter. As the examples show, the examples would be entirely meaningless at code unit level. They're simply not possible. Won't compile. They do compile. There is no

Re: The Case Against Autodecode

On 06/02/2016 11:24 PM, ag0aep6g wrote: They're simply not possible. Won't compile. There is no single UTF-8 code unit for 'ö', so you can't (easily) search for it in a range for code units. Just like there is no single code point for 'a⃗' so you can't search for it in a range of code points.

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 20:27:27 UTC, Walter Bright wrote: On 6/2/2016 12:34 PM, deadalnix wrote: On Thursday, 2 June 2016 at 19:05:44 UTC, Andrei Alexandrescu wrote: Pretty much everything. Consider s and s1 string variables with possibly different encodings (UTF8/UTF16). * s.all!(c =>

Re: The Case Against Autodecode

On 06/02/2016 11:06 PM, Andrei Alexandrescu wrote: Nope, that's a radically different matter. As the examples show, the examples would be entirely meaningless at code unit level. They're simply not possible. Won't compile. There is no single UTF-8 code unit for 'ö', so you can't (easily)

Re: The Case Against Autodecode

On 6/2/16 5:19 PM, Timon Gehr wrote: On 02.06.2016 23:16, Timon Gehr wrote: On 02.06.2016 23:06, Andrei Alexandrescu wrote: As the examples show, the examples would be entirely meaningless at code unit level. So far, I needed to count the number of characters 'ö' inside some string exactly

Re: year to date pull statistics (week ending 2016-05-28)

On Thursday, 2 June 2016 at 18:36:02 UTC, Basile B. wrote: On Tuesday, 31 May 2016 at 23:48:00 UTC, Brad Roberts wrote: [...] You should take Jack Stouffer in dlang ;) . Perso I think that in the phobos the problem is that the people who should manage it are not enough available. I am

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 20:13:52 UTC, Andrei Alexandrescu wrote: On 06/02/2016 03:34 PM, deadalnix wrote: On Thursday, 2 June 2016 at 19:05:44 UTC, Andrei Alexandrescu wrote: Pretty much everything. Consider s and s1 string variables with possibly different encodings (UTF8/UTF16). *

Re: D's Auto Decoding and You

On Tuesday, 17 May 2016 at 14:06:37 UTC, Jack Stouffer wrote: If you think there should be any more information included in the article, please let me know so I can add it. I was a little confused by something in the main autodecoding thread, so I read your article again. Unfortunately, I

Re: Blocking points for further D adoption

On Thursday, 2 June 2016 at 21:01:53 UTC, Jacob Carlborg wrote: Don't you have that issue with most stuff. Not everything can fit everyone's need. Sure, it's a sliding scale. But, web servers, even ones that sit behind Apache or Nginx, are specialized much more than what we currently have in

Re: The Case Against Autodecode

On 02.06.2016 23:06, Andrei Alexandrescu wrote: As the examples show, the examples would be entirely meaningless at code unit level. So far, I needed to count the number of characters 'ö' inside some string exactly zero times, but I wanted to chain or join strings relatively often.

Re: The Case Against Autodecode

On 6/2/16 5:05 PM, tsbockman wrote: On Thursday, 2 June 2016 at 20:56:26 UTC, Walter Bright wrote: What is supposed to be done with "do not merge" PRs other than close them? Occasionally people need to try something on the auto tester (not sure if that's relevant to that particular PR,

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 20:52:29 UTC, ag0aep6g wrote: On 06/02/2016 10:36 PM, Andrei Alexandrescu wrote: By whom? The "support level 1" folks yonder at the Unicode standard? :o) -- Andrei Do they say that level 1 should be the default, and do they give a rationale for that? Would you

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 20:56:26 UTC, Walter Bright wrote: What is supposed to be done with "do not merge" PRs other than close them? Occasionally people need to try something on the auto tester (not sure if that's relevant to that particular PR, though). Presumably if someone marks

Re: The Case Against Autodecode

On 6/2/16 5:01 PM, ag0aep6g wrote: On 06/02/2016 10:50 PM, Andrei Alexandrescu wrote: It does not fall apart for code points. Yes it does. You've been given plenty examples where it falls apart. There weren't any. Your answer to that was that it operates on code points, not graphemes.

Re: Phobos needs a (part-time) maintainer

On Thursday, 2 June 2016 at 20:59:52 UTC, Basile B. wrote: Eventually I'll come back to bugfix if they take Jake, but not you Seb. For a reason or another I don't like you wilzbach. You are frustrated. I get that. Don't make this personal for others, please. Maybe you should ignore this

Re: Blocking points for further D adoption

On 2016-06-02 20:14, Jack Stouffer wrote: Just to be clear, it's not a good idea to have a full blown server in your stdlib. Non-toy web servers are complicated pieces of software involving > 10KLOC. Not only that, but there are many ways to skin a cat in this field. Different products need

Re: The Case Against Autodecode

On 06/02/2016 10:50 PM, Andrei Alexandrescu wrote: It does not fall apart for code points. Yes it does. You've been given plenty examples where it falls apart. Your answer to that was that it operates on code points, not graphemes. Well, duh. Comparing UTF-8 code units against each other

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 20:49:52 UTC, Andrei Alexandrescu wrote: On 06/02/2016 04:47 PM, tsbockman wrote: That doesn't sound like much of an endorsement for defaulting to only level 1 support to me - "it does not handle more complex languages or extensions to the Unicode Standard very

Re: Phobos needs a (part-time) maintainer

On Thursday, 2 June 2016 at 20:23:37 UTC, Seb wrote: On Thursday, 2 June 2016 at 20:17:32 UTC, Andrei Alexandrescu wrote: On 06/02/2016 03:41 PM, Basile B. wrote: Once a pr gets the label "@andrei". It basically means that "it's dead". You mean @andralex? You are right. I am sorry, I'm

  1   2   3   4   >