[Issue 14503] BigInt to binary/octal and lower case "%x" (hexadecimal format)
https://issues.dlang.org/show_bug.cgi?id=14503 e10s changed: What|Removed |Added CC||electrolysis.j...@gmail.com --- Comment #1 from e10s --- Fix BigInt.toString with "%x" https://github.com/D-Programming-Language/phobos/pull/3240 > I believe that we need to add new format specifiers for the data type BigInt +1. --
[Issue 14517] New: Templated static ctor + separate compilation = module cycles
https://issues.dlang.org/show_bug.cgi?id=14517
Issue ID: 14517
Summary: Templated static ctor + separate compilation = module
cycles
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: schvei...@yahoo.com
Even though druntime plays a role, I'm marking this as DMD, since druntime
cannot figure this out without compiler help.
Example:
mod1.d ==
module mod1;
import std.stdio;
struct S(T)
{
shared static T t;
shared static this() {writeln(T.stringof); _t = 5;}
}
void main() {}
mod2.d ==
module mod2;
import mod1;
import mod3;
S!int x;
mod3.d ==
module mod3;
import mod1;
import mod2;
S!int x;
command line
dmd mod1.d mod2.d mod3.d
./mod1
int
dmd -c mod2.d
dmd -c mod3.d
dmd mod1.d mod2.o mod3.o
./mod1
object.Exception@src/rt/minfo.d(162): Aborting: Cycle detected between modules
with ctors/dtors:
mod2 -> mod3 -> mod2
Note that the module ctor only runs once (I only see one printout of 'int'), so
at least that is figured out at runtime.
Examination of the module info using druntime debugging printfs shows that in
the first case (when all 3 modules are compiled at once), mod1 is marked as
having a static CTOR, mod2 and 3 are not. In the second case, mod1 is not
marked as having a static ctor, mod2 and mod3 are.
I wonder if a separate "linkage" module info with just the static ctors
dependent on both modules should be created with a dependency on the
instantiating and the template module could be created, which should eliminate
any issues (it's definitely possible right now to construct a cycle between
instantiating and template modules). The instantiating module should have a
dependency on the linkage module as well, since there could be a cycle there
also! It's a very complex issue, but probably not very common.
--
[Issue 14517] Templated static ctor + separate compilation = module cycles
https://issues.dlang.org/show_bug.cgi?id=14517 Jonathan M Davis changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m Severity|normal |blocker --- Comment #1 from Jonathan M Davis --- This currently blocks https://github.com/D-Programming-Language/druntime/pull/990 from working. --
[Issue 14517] Templated static ctor + separate compilation = module cycles
https://issues.dlang.org/show_bug.cgi?id=14517 Steven Schveighoffer changed: What|Removed |Added Severity|blocker |normal --- Comment #2 from Steven Schveighoffer --- It's not a blocker, as we can work around that, see my new comments in the PR. --
[Issue 14505] File doesn't rewind read pointer for a+ mode on Windows DMC
https://issues.dlang.org/show_bug.cgi?id=14505 Steven Schveighoffer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Steven Schveighoffer --- (In reply to Vladimir Panteleev from comment #6) > (In reply to Steven Schveighoffer from comment #5) > > It tells the current position of the file descriptor. There is no different > > "read" or "write" pointer. When writing, the C library (or the OS in the > > case of Unixen) seeks the stream to the end. > > Is that part of the specification? If so, then that contradicts with your > above claims and one of the libcs is clearly buggy. That's for "a", and the specification says what happens only on write, not what happens on open (at least clearly). That means it's implementation defined. Here is a quote from my C 90 spec: "r" open text file for reading "w" create text file for writing; discard previous contents if any "a" append; open or create text file for writing at end of file "r+" open text file for update (i.e. reading and writing) "w+" create text file for update; discard previous contents if any "a+" append; open or create text file for update, writing at end Update mode permits reading and writing the same file; fflush or a file-positioning function must be called between a read and a write or vice versa. END QUOTE It does not specifically say what ftell should return immediately after opening. Only that append writes at the end of the file. Now, one could play lawyer and say that "at end of file" could describe how to open and not how to write, but I think that is not what was intended. The K&R book I have shows an example of how to implement fopen as an example of how to use unix system interface functions, and shows using lseek to the end of the file on 'a'. It leaves out how to implement the '+' version. This, however, is NOT part of the C specification, it's just an example implementation. Now, clearly it does say that you have to seek between reads and writes, but it does not say what you have to do on the first read or write. But I think this doesn't apply to the "a" style opens, as those say writing at end of file. I'm pretty sure the spec is ambiguous enough to allow all the implementations here. I'm going to close as WONTFIX, as technically it's a difference in implementations but I don't think we should fix it in D-land. If someone wants to fix DMC (and Walter's OK with that), then sure. If someone thinks MSVCRT is buggy, good luck with that one :) --
[Issue 14518] Review wiki wish-list proposal for a renewed file-based archive API
https://issues.dlang.org/show_bug.cgi?id=14518 Liam McSherry changed: What|Removed |Added Summary|Review wiki wish-list |Review wiki wish-list |proposal for a renewed API |proposal for a renewed |file-based archives |file-based archive API --
[Issue 14518] New: Review wiki wish-list proposal for a renewed API file-based archives
https://issues.dlang.org/show_bug.cgi?id=14518 Issue ID: 14518 Summary: Review wiki wish-list proposal for a renewed API file-based archives Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: mcsherry.l...@gmail.com On the wiki, there is (and has been for a couple of years) a wish-list[1] with a suggestion that there should be an common API for file-based archives (such as zip and tar). The downside of specifying an API is deprecation of std.zip's current API. I would like to contribute tar code to Phobos, so knowing whether or not there is (or will be) a common API for file-based archives would help me. [1]: http://wiki.dlang.org/Wish_list#Compression.2Farchiving --
[Issue 14502] dmd -O optimization breaks app
https://issues.dlang.org/show_bug.cgi?id=14502 --- Comment #8 from Tomáš Chaloupka --- Actually read it before. Tried to use prepared script with specific backtrace, but could not make it work with timeout (wrong output from gdb then). So now trying with just simple: #!/bin/bash TIME=12 timeout $TIME rdmd --force -O -release test.d 2>&1 > /dev/null if [ $? -eq 139 ]; then timeout $TIME rdmd --force -release test.d 2>&1 > /dev/null if [ $? -eq 124 ]; then timeout $TIME rdmd --force test.d 2>&1 > /dev/null if [ $? -eq 124 ]; then exit 0 else exit 1 fi else exit 1 fi fi exit 1 which is at least faster thanks to timeout usage. --
[Issue 14517] Templated static ctor + separate compilation = module cycles
https://issues.dlang.org/show_bug.cgi?id=14517 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu --- Comment #3 from Martin Nowak --- You probably learned that for C++, avoid static constructors because the initialization order quickly becomes a mess. The problem here is that both mod2 and mod3 depend on a constructor, but also have a cyclic dependency. We could somehow (using linker tricks) try to push the ctors/dtors into mod1. I'm not sure I understand your idea Steven. --
[Issue 14517] Templated static ctor + separate compilation = module cycles
https://issues.dlang.org/show_bug.cgi?id=14517 --- Comment #4 from Steven Schveighoffer --- If you look at PR 990 that Jonathan linked, you will see that it's not so cut and dry. Essentially ANY separate compiled module that imports another module that has some template constructors, even if they aren't used in that module, but used somewhere else, will flag that module as having ctors. The test I ran showed modules like std.traits having module bits flipped on because of core.time having static ctors in an instantiated template. That makes no sense whatsoever -- there's not even an instantiation of MonoTimeImpl in std.traits. Let me first say that we need to fix this regardless of how it's done or how complete the fix is. We absolutely cannot mark some module as having static ctors because of modules somewhere else in the import chain that have nothing to do with the given module. If this means banning static ctor/dtor in templates, so be it (though I think that's a bit difficult to swallow). And thinking some more about my idea, I don't think it will work. What we likely need is a way to say that mod2 or mod3 can "upgrade" mod1's bit (at runtime). Perhaps we can discuss at dconf '15. --
[Issue 14519] New: [Enh] foreach on strings should return replacementDchar rather than throwing
https://issues.dlang.org/show_bug.cgi?id=14519
Issue ID: 14519
Summary: [Enh] foreach on strings should return
replacementDchar rather than throwing
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bugzi...@digitalmars.com
Consider:
@safe pure nothrow @nogc void bar();
void foo(string s) @safe pure nothrow @nogc {
foreach (dchar c; s)
bar();
}
This fails to compile because foreach over a decoded string can throw. It also
incorrectly is regarded as @nogc, because the throw can allocate.
Changing foreach to return replacementDchar on invalid UTF encodings fixes
these problems, and makes it possible to do faster loops.
--
[Issue 14519] [Enh] foreach on strings should return replacementDchar rather than throwing
https://issues.dlang.org/show_bug.cgi?id=14519 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev --- As discussed in the newsgroup: please don't do this. --
[Issue 14511] Profiler does not work with multithreaded programs
https://issues.dlang.org/show_bug.cgi?id=14511 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14511] Profiler does not work with multithreaded programs
https://issues.dlang.org/show_bug.cgi?id=14511 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/01087ce464d3b905d16e55799d02b710fcdd9939 fix Issue 14511 - Profiler does not work with multithreaded programs https://github.com/D-Programming-Language/druntime/commit/0f4f326fb476bbf80ca95e8f368bbb2c3d2f260d Merge pull request #1233 from WalterBright/fix14511 fix Issue 14511 - Profiler does not work with multithreaded programs --
[Issue 14502] dmd -O optimization breaks app
https://issues.dlang.org/show_bug.cgi?id=14502 --- Comment #9 from Tomáš Chaloupka --- So it ended up with an indeterministic version which sometimes pass, sometimes fails in all switches :( Is it actually failing for anyone else? --
[Issue 14520] New: [REG2.067.0] string/alias template overload
https://issues.dlang.org/show_bug.cgi?id=14520
Issue ID: 14520
Summary: [REG2.067.0] string/alias template overload
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: thecybersha...@gmail.com
/// test.d //
int f();
mixin template M(alias a) {}
mixin template M(string s) {}
mixin M!f;
/
test.d(4): Error: f cannot be interpreted at compile time, because it has no
available source code
Introduced in https://github.com/D-Programming-Language/dmd/pull/4375
--
[Issue 14000] Segmentation fault with profile
https://issues.dlang.org/show_bug.cgi?id=14000 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14511 --
[Issue 14511] Profiler does not work with multithreaded programs
https://issues.dlang.org/show_bug.cgi?id=14511 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14000 --
[Issue 14000] Segmentation fault with profile
https://issues.dlang.org/show_bug.cgi?id=14000 --- Comment #3 from Walter Bright --- This may fix it: https://issues.dlang.org/show_bug.cgi?id=14511 --
[Issue 14519] [Enh] foreach on strings should return replacementDchar rather than throwing
https://issues.dlang.org/show_bug.cgi?id=14519 Jonathan M Davis changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #2 from Jonathan M Davis --- (In reply to Vladimir Panteleev from comment #1) > As discussed in the newsgroup: please don't do this. If anything, I thought that the consensus lead towards making the change, but maybe I didn't pay enough attention to the discussion in question. Certainly, I'm very much in favor of making use of replacementDchar on invalid UTF in general and have code explicitly validate unicode if that's what's desired. There is some risk with making the change, since existing code may not handle the replacement character well, but very little string processing is going to actually care, and throwing exceptions like we currently do is not only a performance problem, it's hugely annoying when you need to actually process invalid unicode, which is pretty easy to have happen if you're doing stuff like parsing websites or files which were written by programs that didn't handle unicode correctly. --
[Issue 14519] [Enh] foreach on strings should return replacementDchar rather than throwing
https://issues.dlang.org/show_bug.cgi?id=14519 --- Comment #3 from Vladimir Panteleev --- > it's hugely annoying when you need to actually process invalid unicode Yeah, and it'll me a lot more than just "annoying" when you discover too late that your data's been irreversibly corrupted because it wasn't in the correct encoding. --
[Issue 14519] [Enh] foreach on strings should return replacementDchar rather than throwing
https://issues.dlang.org/show_bug.cgi?id=14519 --- Comment #4 from Vladimir Panteleev --- Here's a counter-proposal: when encountering invalid UTF-8, instead of throwing exceptions, throw errors. This will fix the nothrow and performance problems, and will avoid the risk of data corruption. The workaround is to pre-sanitize the input. The impact of breaking existing code is the same as the original proposal. --
