[Issue 9447] iota should generate char intervals too
http://d.puremagic.com/issues/show_bug.cgi?id=9447 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #4 from monarchdo...@gmail.com 2013-07-26 00:12:08 PDT --- (In reply to comment #3) (In reply to comment #2) It is definitely _not_ the case that adding 1 to a wchar or dchar will necessarily result in a valid value. In both of them, there's a block in the middle which is invalid. Just like at the implementation of isValidDchar. Is this the only restriction though? If that's so, it should be easy to implement this feature with a single runtime check to verify the range doesn't go over the invalid block. I think that is a bad idea. We should keep it simple: User asks to iterate over xchars of values low to high, and that is all we should return. When it comes to wchars or dchars, the notion of invalid is really in the eye of the beholder anyway. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4085] Steps toward a static foreach
http://d.puremagic.com/issues/show_bug.cgi?id=4085
--- Comment #8 from monarchdo...@gmail.com 2013-07-26 00:27:42 PDT ---
(In reply to comment #7)
(In reply to comment #4)
Copy pasting a proposed implementation from 10712. Pretty much the same
thing,
but also handles indiscriminate types. It passes the prior tests, as well as
handles the useage with doubles, or chars:
Just a reminder: elsewhere I asked for an improvement to iota(), to let it
optionally accept a string (like std.random.uniform) that allows to generate
complete intervals of a type or handy closed intervals:
iota
iota0, cast(ubyte)255)
http://d.puremagic.com/issues/show_bug.cgi?id=10466
I've taken note. I think it is a good idea, but it might be difficult to
implement what with all the overloads.
Currently I think it's impossible to generate the full range of a type like
ubyes with iota, and it's not handy to generate the complete range of
lowercase
char letters, you need to use iota('a', '{'), that currently doesn't work for
other reasons.
http://d.puremagic.com/issues/show_bug.cgi?id=6447
http://d.puremagic.com/issues/show_bug.cgi?id=9447
Fixing the issue of iota and non built-in integral is on my todo list.
BTW, you could also write it as (provided char is accepted at all):
iota('a', cast(char)('f' + 1))
or
iota!(char,char)('a', 'f'+1);
But in both cases, integral promotion kind of gets in the way of clean code
:/
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10713] [REG2.063] ICE with typeof(this.nonExistingField) in method signature
http://d.puremagic.com/issues/show_bug.cgi?id=10713 --- Comment #2 from github-bugzi...@puremagic.com 2013-07-26 00:50:13 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8ec7a0d6876d0946d7bff8fe73330b720d1fc6b8 fix Issue 10713 - ICE with typeof(this.nonExistingField) in method signature https://github.com/D-Programming-Language/dmd/commit/21b130d71a73b2d8f27c93bea9560cebeded1e1a Merge pull request #2382 from 9rnsr/fix10713 [REG2.063] Issue 10713 - ICE with typeof(this.nonExistingField) in method signature -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10713] [REG2.063] ICE with typeof(this.nonExistingField) in method signature
http://d.puremagic.com/issues/show_bug.cgi?id=10713 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6711] with doesn't work with alias this
http://d.puremagic.com/issues/show_bug.cgi?id=6711 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #7 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-07-26 03:05:17 PDT --- The test-case in Issue 9807 still doesn't work, so I've reopened this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10716] New: Horrifically slow compilation for array literals inside functions
http://d.puremagic.com/issues/show_bug.cgi?id=10716
Summary: Horrifically slow compilation for array literals
inside functions
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2013-07-26 03:19:49 PDT ---
I found this in the DMD test suite. One file, test44.d, takes much longer to
compile than any of the others. The actual test is basically just this:
---
void main()
{
int [] x = [
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
];
}
---
but copy the 1,1,1,1, line a thousand times.
The slow compilation happens in the glue layer: compiling with dmd -o- is
instantaneous, but dmd -c takes minutes.
Which is really silly since it can should just compile to a malloc + memcpy
from data segment.
Compiling with -O makes it even worse.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10596] A method with out contract and auto return type causes segfault
http://d.puremagic.com/issues/show_bug.cgi?id=10596 Henning Pohl henn...@still-hidden.de changed: What|Removed |Added Keywords||pull CC||henn...@still-hidden.de --- Comment #2 from Henning Pohl henn...@still-hidden.de 2013-07-26 04:19:03 PDT --- https://github.com/D-Programming-Language/dmd/pull/2383 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10717] New: std.ascii.toLower and toUpper should return char instead of dchar and avoid me to use a bad cast(char)
http://d.puremagic.com/issues/show_bug.cgi?id=10717 Summary: std.ascii.toLower and toUpper should return char instead of dchar and avoid me to use a bad cast(char) Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2013-07-26 05:06:14 PDT --- If I use functions from std.ascii I am stating that I am working with ASCII chars. Also std.ascii docs say: All of the functions in std.ascii accept unicode characters but effectively ignore them. So if I use std.ascii.toLower on an ASCII char, in most times (all times so far) I want the result to be a char. If std.ascii.toLower returns a dchar it forces me to use a cast(char) in most (or all) cases. Such cast doesn't increase safety at all, it actually decreases it. So I'd like std.ascii.toLower and std.ascii.toUpper to return char. (This has a severity 'normal' instead of 'enhancement' because I regard that as a bug in the design of those two functions.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10718] New: std.algorithm.copy should keep the type of the characters it copies
http://d.puremagic.com/issues/show_bug.cgi?id=10718
Summary: std.algorithm.copy should keep the type of the
characters it copies
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-07-26 05:11:55 PDT ---
Phobos Range-based functions see strings and char[] to arrays of dchar, but I
think that behavour is not good for std.algorithm.copy too:
import std.algorithm: copy;
void main() {
char[5] arr1 = hello, arr2;
arr1[].copy(arr2[]); // Error.
dchar[arr1.length] arr3;
arr1[].copy(arr3[]); // OK.
}
(Ali from D learns says that he would expect copy to maintain the same type.)
See also:
import std.array: array;
void main() {
char[5] arr = hello;
pragma(msg, typeof(arr.array)); // Prints: dchar[]
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10717] std.ascii.toLower and toUpper should return char instead of dchar and avoid me to use a bad cast(char)
http://d.puremagic.com/issues/show_bug.cgi?id=10717 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com Severity|normal |enhancement --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2013-07-26 05:17:49 PDT --- I really don't think that this is a bug. By taking dchar, they work with ranges of dchar and allow you to operate on strings that contain Unicode in cases where all you care about are particular ASCII characters (like when you only care about ASCII whitespace in a string - not Unicode whitespace - but the string contains Unicode characters). And as soon the functions accept dchar, they must return dchar, or they'll destroy any Unicode characters that get passed in. A reasonable enhancement request would be to overload these functions with overloads which take char and return char, but there is actual value in having them accept and return dchar, and it would break existing code if they stopped. So, the functions that are there are there to stay, but you may get overloads which operate specifically on char. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10718] std.algorithm.copy should keep the type of the characters it copies
http://d.puremagic.com/issues/show_bug.cgi?id=10718
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
--- Comment #1 from monarchdo...@gmail.com 2013-07-26 05:45:10 PDT ---
(In reply to comment #0)
Phobos Range-based functions see strings and char[] to arrays of dchar, but I
think that behavour is not good for std.algorithm.copy too:
import std.algorithm: copy;
void main() {
char[5] arr1 = hello, arr2;
arr1[].copy(arr2[]); // Error.
dchar[arr1.length] arr3;
arr1[].copy(arr3[]); // OK.
}
I think it would be better if copy (like every other phobos algorithm) used the
knowledge that a dchar can be converted to a stream of characters, if needed.
For example, according to your suggestion, if std.algorithm.copy simply
iterated on the chars, then copying a unicode string into an array of dchar
would fail catastrophically, and that is not acceptable at all.
EG, this *must* work:
string s = 日本語;
dchar[3] d;
s.copy(d[]);
On the other hand, we should be able to make this work:
dchar[3] d = 日本語d;
char[] s = new char[](12);
d.copy(s);
(Ali from D learns says that he would expect copy to maintain the same type.)
I strongly disagree. std.algorithm operates on ranges. a string is a range of
dchars.
See also:
import std.array: array;
void main() {
char[5] arr = hello;
pragma(msg, typeof(arr.array)); // Prints: dchar[]
}
The documentation of array explicitly says it will behave this way, as it
provides an RA range of the iterated range. That is part of its design, and
can't change.
That said, I had suggested (and partially worked on long ago) the option to
specify what types you want array to produce. EG:
auto myDoubles = array!double(myRangeOfInts);
The same can be obtained with myRangeOfInts.map!cast(double)a().array();,
but it is not as convenient.
Further more, this suggestion would allow this:
dchar[3] d = 日本語d;
auto s = d[].array!(immutable char)(d);
Which would not be possible via a map! workaround.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10717] std.ascii.toLower and toUpper should return char instead of dchar and avoid me to use a bad cast(char)
http://d.puremagic.com/issues/show_bug.cgi?id=10717 --- Comment #2 from bearophile_h...@eml.cc 2013-07-26 07:33:37 PDT --- (In reply to comment #1) So, the functions that are there are there to stay, but you may get overloads which operate specifically on char. OK. Thank for your comments and corrections Jonathan. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10718] std.algorithm.copy should keep the type of the characters it copies
http://d.puremagic.com/issues/show_bug.cgi?id=10718
--- Comment #2 from bearophile_h...@eml.cc 2013-07-26 07:42:59 PDT ---
(In reply to comment #1)
I strongly disagree. std.algorithm operates on ranges. a string is a range of
dchars.
In code like this the map yield chars, yet copy converts them to dchar, is this
good?
import std.range, std.algorithm;
void main() {
char[5] arr;
auto r = 5.iota.map!(i = cast(char)(i + 'a'));
static assert(is(typeof(r.front) == char)); // OK
r.copy(arr[]); // error
}
Thank you for your answers. Do you suggest to close down this issue?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9813] Signalling NaN initialization does not always work correctly on x86
http://d.puremagic.com/issues/show_bug.cgi?id=9813 --- Comment #4 from Don clugd...@yahoo.com.au 2013-07-26 07:47:40 PDT --- *** Issue 6303 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 6303] Order of float declaration changes NaN throwing behavior
http://d.puremagic.com/issues/show_bug.cgi?id=6303 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Don clugd...@yahoo.com.au 2013-07-26 07:47:40 PDT --- This is a symptom of bug 9813. *** This issue has been marked as a duplicate of issue 9813 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10031] Link to old wiki on dlang.org
http://d.puremagic.com/issues/show_bug.cgi?id=10031 Jameson beatgam...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Jameson beatgam...@gmail.com 2013-07-26 08:06:29 PDT --- Merged and deployed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6711] with doesn't work with alias this
http://d.puremagic.com/issues/show_bug.cgi?id=6711 --- Comment #8 from Henning Pohl henn...@still-hidden.de 2013-07-26 09:04:01 PDT --- https://github.com/D-Programming-Language/dmd/pull/2386 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1983] Delegates violate const
http://d.puremagic.com/issues/show_bug.cgi?id=1983 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||zan77...@nifty.com --- Comment #12 from Kenji Hara k.hara...@gmail.com 2013-07-26 10:21:27 PDT --- *** Issue 8781 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 8781] delegate breaks const/immutable/shared correctness
http://d.puremagic.com/issues/show_bug.cgi?id=8781 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-07-26 10:21:27 PDT --- *** This issue has been marked as a duplicate of issue 1983 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6711] with doesn't work with alias this
http://d.puremagic.com/issues/show_bug.cgi?id=6711 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10162] Opposite of std.string.representation
http://d.puremagic.com/issues/show_bug.cgi?id=10162 --- Comment #1 from bearophile_h...@eml.cc 2013-07-26 10:34:57 PDT --- An alternative name for such function is assumeChars. And it should return char[], const(char)[] or immutable(char)[] according to the input being a ubyte[], const(ubyte)[] or immutable(ubyte)[]. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6711] with doesn't work with alias this
http://d.puremagic.com/issues/show_bug.cgi?id=6711 --- Comment #9 from github-bugzi...@puremagic.com 2013-07-26 10:34:14 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/efba4e047b4d2a1da522d418a0491aebe0e68f36 additional fix for issue 6711 https://github.com/D-Programming-Language/dmd/commit/e96ff4d28950603b8a5bd3e8c35511bd3072e7fa Merge pull request #2386 from hpohl/6711 additional fix for issue 6711 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10162] Opposite of std.string.representation
http://d.puremagic.com/issues/show_bug.cgi?id=10162 --- Comment #2 from bearophile_h...@eml.cc 2013-07-26 10:36:22 PDT --- (In reply to comment #1) It could also return wchar[], const(wchar)[], immutable(wchar)[] according to the input being a ushort[], const(ushort)[] or immutable(ushort)[]. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10201] = void initialization should not be allowed in @safe
http://d.puremagic.com/issues/show_bug.cgi?id=10201
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
--- Comment #2 from monarchdo...@gmail.com 2013-07-26 13:05:21 PDT ---
(In reply to comment #1)
So it is not that dangerous in that sense, but can be used to workaround some
guarantees provided by disabled constructor. Prohibiting all void initalizers
in @safe may be both more simple and consistent.
It is dangerous in the sense that for a struct that is not POD, you are
violating its internal integrity, at which point, it has no way to guarantee
the safety of its own internal operations.
I mentioned this in
https://github.com/D-Programming-Language/phobos/pull/1434#issuecomment-21644766
with the example:
//
struct S
{
private size_t index;
private ubyte[1] arr;
ref ubyte get() @trusted
{
return arr.ptr[index];
}
}
void main() @safe
{
S s = void;
ubyte a = s.get();
}
//
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10596] A method with out contract and auto return type causes segfault
http://d.puremagic.com/issues/show_bug.cgi?id=10596 --- Comment #3 from github-bugzi...@puremagic.com 2013-07-26 15:58:51 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/338998c8894451d83597ad4c274a17ac5b32e5e4 fix issue 10596 - A method with out contract and auto return type causes segfault https://github.com/D-Programming-Language/dmd/commit/87f79bb281b9cbf2b46028a3084f28f2daff164e Merge pull request #2383 from hpohl/10596 fix issue 10596 - A method with out contract and auto return type causes segfault -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10596] A method with out contract and auto return type causes segfault
http://d.puremagic.com/issues/show_bug.cgi?id=10596 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10719] New: Loading classes in runtime
http://d.puremagic.com/issues/show_bug.cgi?id=10719
Summary: Loading classes in runtime
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: freeslav...@gmail.com
--- Comment #0 from Roman freeslav...@gmail.com 2013-07-26 17:37:00 PDT ---
There is kinda plugin here (code is for linux or other posix system with dlfcn)
Why does it crush when using interface instead of abstract class?
(-version=inter)
//dinter.d
module dinter;
version(inter) {
pragma(msg, Using interface);
interface Dinter {
int foo(int a, int b);
}
}
else {
pragma(msg, Using abstract class);
abstract class Dinter {
int foo(int a, int b);
}
}
//dimpl.d
//dmd -shared -fPIC dimpl.d dinter.d -oflibdimpl.so
//dmd -shared -fPIC dimpl.d dinter.d -oflibdimpl.so -verstion=inter
module dimpl;
import dinter;
class Dimpl : Dinter {
override int foo(int a, int b) {
return a+b;
}
}
extern(C) Dinter create() {
return new Dimpl;
}
//dmain.d
//dmd dmain.d -L-rpath=. -L-ldl
//dmd dmain.d -L-rpath=. -L-ldl -version=inter
import dinter;
import std.c.linux.linux;
import std.string : toStringz;
alias extern(C) Dinter function() CreateFn;
int main(string[] args) {
void* lib = dlopen(toStringz(./libdimpl.so), RTLD_LAZY);
assert(lib);
auto create = cast(CreateFn)dlsym(lib, toStringz(create));
assert(create);
Dinter d = create();
assert(d.foo(3,7)==10);
return 0;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10716] Horrifically slow compilation for array literals inside functions
http://d.puremagic.com/issues/show_bug.cgi?id=10716 --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2013-07-26 19:44:18 PDT --- https://github.com/D-Programming-Language/dmd/pull/2388 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10716] Horrifically slow compilation for array literals inside functions
http://d.puremagic.com/issues/show_bug.cgi?id=10716 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2013-07-26 20:06:03 PDT --- This could be related to bug# 8449. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
