[Issue 9045] Feature request for std.asscii = function isNewline
http://d.puremagic.com/issues/show_bug.cgi?id=9045
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
--- Comment #7 from monarchdo...@gmail.com 2012-11-20 05:42:25 PST ---
(In reply to comment #1)
See representation on various systems:
http://en.wikipedia.org/wiki/Newline
In particular:
On Unix, and Mac OS X: LF (1 char)
On Windows: CR+LF (2 chars)
(In reply to comment #5)
Technically speaking, if you don't know which type of line endings a file uses
[SNIP]
Isn't the line ending a *file* totally irrelevant here? In the sense that it
is a nothing more than the system's *storage* format?
On my windows machine, the *strings* I manipulate don't have \r\n as a
newline, they have '\n'. That's the entire reason there is a rb and r
option when reading a file.
If you *do* have an \r\n in your stream, then either:
* You have an actual a '\r' in your stream, which is then followed by a new
line.
* You are actually erroneously manipulating a binary payload, which should be
of type ubyte[], and should not be using the std.ascii functions with it.
Under these circumstance, and following the unicode definition, I'd say:
return 0x0A = c c = 0x0D;
Is not only correct (for ascii), but any attempt to parse more than 1 character
for this info would be incorrect...
PS: WTF is \u{D A}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1188] Command-line arguments are encoded in CP_ACP on Windows instead of UTF-8
http://d.puremagic.com/issues/show_bug.cgi?id=1188 --- Comment #9 from github-bugzi...@puremagic.com 2012-11-20 06:16:55 PST --- Commits pushed to phobos-1.x at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/f52cb5c94078d9fe73ad9663a861bf195a833888 Fix Issue 1188 by copying args processing code from druntime https://github.com/D-Programming-Language/phobos/commit/7653b6a20c7053c1994a0496933278369cb93feb Merge pull request #962 from denis-sh/fix2-Issue-1188 Fix issue 1188 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9049] New: std.typecons.Proxy doesn't treat ref parameter correctly.
http://d.puremagic.com/issues/show_bug.cgi?id=9049
Summary: std.typecons.Proxy doesn't treat ref parameter
correctly.
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: zan77...@nifty.com
--- Comment #0 from SHOO zan77...@nifty.com 2012-11-20 06:37:34 PST ---
This code doesn't work:
-
import std.typecons, std.stdio;
struct A {
void foo(ref ubyte[] a) { a = [1]; }
}
struct B {
A a;
mixin Proxy!a;
}
void main() {
B b;
ubyte[] a;
b.foo(a);
assert(a.length == 1);
}
-
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8441] function expected, not my function
http://d.puremagic.com/issues/show_bug.cgi?id=8441 jfanati...@gmx.at changed: What|Removed |Added CC||jfanati...@gmx.at --- Comment #1 from jfanati...@gmx.at 2012-11-20 07:31:13 PST --- Can also reproduced with: https://github.com/eskimor/phobos/blob/new_signal/std/signals.d And is currently a blocker for a full signals2 implementation. Without it, I can only provide the FullSignal struct, which is good but does not support easily restriction of access to emit(). So users would have to redundantly create boilerplate code. Another option would be to use string mixins, but the syntax would not be as nice, so I would like to stick with the current implementation. To summarize the problem: A mixin seems not to work with methods that are templates themselves, resulting in strange errors like: std/signals.d(730): Error: no overload matches for disconnect(string method,ClassType) or std/signals.d(633): Error: function expected before (), not 'a.connect!(watch)' Tested with dmd 2.060 and current master (7c370f71641c4408ddc9ebd5709e6e182e34ad2b). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9050] New: compiler crash on return type inference
http://d.puremagic.com/issues/show_bug.cgi?id=9050
Summary: compiler crash on return type inference
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: ice
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: marco.le...@gmx.de
--- Comment #0 from Marco Leise marco.le...@gmx.de 2012-11-20 08:41:10 PST ---
This is probably some variation of some other bug, but it is hard to tell for
me. In the example below there is a recursive instantiation of foo, A and B. It
takes both calls to foo and the pure attribute to make the compiler crash.
Otherwise it prints:
test.d(4): Error: forward reference to inferred return type of function call
foo(A())
test.d(8): Error: template instance test.B!(int) error instantiating
test.d(10):instantiated from here: foo!()
struct A(T) {}
struct B(T) {
unittest {
foo(A!int());
}
}
auto foo()(A!int base) pure {
return B!int();
}
auto l = foo(A!int());
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7444] Require [] for array copies too
http://d.puremagic.com/issues/show_bug.cgi?id=7444 --- Comment #10 from github-bugzi...@puremagic.com 2012-11-20 09:55:06 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/28dedee456e741f02f08a944f41daa9e46236224 Issue 7444 - Require [] for array copies too https://github.com/D-Programming-Language/phobos/commit/9a6dad8a2ac5841bdcfa2b86082450818f6eefab Merge pull request #960 from 9rnsr/fix7444 Supplemental changes for Issue 7444 - Require [] for array copies too -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9045] Feature request for std.asscii = function isNewline
http://d.puremagic.com/issues/show_bug.cgi?id=9045
--- Comment #8 from Dmitry Olshansky dmitry.o...@gmail.com 2012-11-20
12:13:48 PST ---
(In reply to comment #7)
(In reply to comment #1)
See representation on various systems:
http://en.wikipedia.org/wiki/Newline
In particular:
On Unix, and Mac OS X: LF (1 char)
On Windows: CR+LF (2 chars)
(In reply to comment #5)
Technically speaking, if you don't know which type of line endings a file
uses
[SNIP]
Isn't the line ending a *file* totally irrelevant here? In the sense that it
is a nothing more than the system's *storage* format?
There is no system's encoding. It died and buried in the same toomb as FTP
ASCII mode long time ago. After all files are transfered in many different ways
expecting someone to transcode line-endings everywhere is plain impossible (you
don't always know the target system). So by the end of day reasonable programs
just deal with all the zoo of them.
On my windows machine, the *strings* I manipulate don't have \r\n as a
newline, they have '\n'. That's the entire reason there is a rb and r
option when reading a file.
And I'd say rb option is a woefully broken thing. In fact putting \n does in
fact store \r\n in this mode. You are far safer with binary mode at least it's
WYSIWG.
If you *do* have an \r\n in your stream, then either:
* You have an actual a '\r' in your stream, which is then followed by a new
line.
Under these circumstance, and following the unicode definition, I'd say:
return 0x0A = c c = 0x0D;
Is not only correct (for ascii), but any attempt to parse more than 1
character
for this info would be incorrect...
No, no and no. It's the fact of life (or rather the standard) that \r\n is a
single entity. And it can't be parsed other the by looking at two characters
(or rather codepoints).
PS: WTF is \u{D A}
It's 2 dchars : \r\n. That is 0x0D and 0x0A. They are being cute and use
flexible width syntax not the old ones: \u and \U.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9045] Feature request for std.asscii = function isNewline
http://d.puremagic.com/issues/show_bug.cgi?id=9045
--- Comment #9 from Jonathan M Davis jmdavisp...@gmx.com 2012-11-20 12:29:09
PST ---
Any code that only cares about \n or \r\n isn't going to work with a function
which returns true for both. And any code that doesn't care is going to be
ill-served by a such a function, because the reality is that you need to watch
for \r and \n as individual characters and properly handle the cases when
they're separate as well as when they're apart. And the fact that one of them
is multiple characters generally screws with trying to check for them with a
single function in the middle of iterating. Rather, you have to watch for \r
and \n individually and then figure out whether you're dealing with them singly
or together and act appropriately. A function which returns true for a string
is generally useless for the kind of situations where you'd be checking for
newlines, so I'm highly skeptical that such a function is of any real value.
Instead, you end up with stuff like
for(auto range = str.save; !range.empty; range.popFront())
{
switch(range.front)
{
case '\r':
auto temp = range.save;
temp.popFront();
if(temp.front == '\n')
{
range.popFront();
goto case '\n';
}
goto default;
case '\n':
//do whatever you do for end of line
break;
default:
//do whatever you do for individual characters
break;
}
}
And if you all you want to know is whether a particular string starts or ends
with a newline, then it's easy enough to just do str.startsWith(\n, \r\n)
or str.endsWith(\n, \r\n). That gets uglier when you need to deal with
unicode rather than just \n an \r\n, but then all I believe that you really
need is to add [paraSep], and [lineSep] to the list.
I'm not sure that a function telling you whether a string designates the end of
a line is completely useless, but in pretty much every case that I can see code
caring, such a function wouldn't work very well.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9051] New: [CTFE] Working with non-trivial immutable globals?
http://d.puremagic.com/issues/show_bug.cgi?id=9051
Summary: [CTFE] Working with non-trivial immutable globals?
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dmitry.o...@gmail.com
--- Comment #0 from Dmitry Olshansky dmitry.o...@gmail.com 2012-11-20
12:50:42 PST ---
I'm wondering if this is supposed to work. By all means I don't see why it has
to try this(this) in this case (and moreover fail).
struct Set{
uint[] arr;
this(this){ } //comment out to make it compile
}
pure auto getMeASet(uint[] arr)
{
return Set(arr);
}
immutable set = getMeASet([1,2,3,4]);
pure auto getSecond(in Set set)
{
return set.arr[1];
}
pragma(msg, getSecond(set));
And the diagnostic spits all kinds of nonsense:
D:\D\ctfe_glob.d(20): Error: variable ctfe_glob.__cpcttmp6 of type struct
const(Set) uses this(this), which is not allowed in static initialization
D:\D\ctfe_glob.d(20):while evaluating pragma(msg, getSecond((const
const(Set) __cpcttmp6 = Set([1u, 2u, 3u, 4u]);
, __cpcttmp6)))
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9049] std.typecons.Proxy doesn't treat ref parameter correctly.
http://d.puremagic.com/issues/show_bug.cgi?id=9049 --- Comment #1 from github-bugzi...@puremagic.com 2012-11-20 17:11:08 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/a8305d0b21eb459d41d1fd1a062705e8f22408c8 fix Issue 9049 - std.typecons.Proxy doesn't treat ref parameter correctly. http://d.puremagic.com/issues/show_bug.cgi?id=9049 https://github.com/D-Programming-Language/phobos/commit/04952af5ad6dc5e4e1e54d9064316c08d0f56df6 Merge pull request #963 from shoo/fix9049 fix Issue 9049 - std.typecons.Proxy doesn't treat ref parameter correctly -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9049] std.typecons.Proxy doesn't treat ref parameter correctly.
http://d.puremagic.com/issues/show_bug.cgi?id=9049 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8959] IsExpression should support syntax which has no Identifier in all cases
http://d.puremagic.com/issues/show_bug.cgi?id=8959 --- Comment #2 from github-bugzi...@puremagic.com 2012-11-20 18:34:35 PST --- Commit pushed to fix8959 at https://github.com/D-Programming-Language/d-programming-language.org https://github.com/D-Programming-Language/d-programming-language.org/commit/df2e07a8e473abfd757146966a788775819637b6 fix Issue 8959 - IsExpression should support syntax which has no Identifier in all cases -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9026] Template mixin identifier as template alias parameter doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=9026 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1353] Can't use typeof() in base class list.
http://d.puremagic.com/issues/show_bug.cgi?id=1353 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||ogon...@gmail.com --- Comment #4 from Kenji Hara k.hara...@gmail.com 2012-11-20 19:48:17 PST --- *** Issue 9048 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9048] Error: base classes expected instead of typeof when instantiating anonymous class
http://d.puremagic.com/issues/show_bug.cgi?id=9048
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||DUPLICATE
--- Comment #2 from Kenji Hara k.hara...@gmail.com 2012-11-20 19:48:17 PST ---
(In reply to comment #0)
new class typeof(this) {};
new class typeof(new Object()) {};
Using typeof in base class list is allowed in 2.061head, by fixing issue 1353.
*** This issue has been marked as a duplicate of issue 1353 ***
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
