druntime unit test failures on FreeBSD
I am consistently seeing this when I try and run druntime's unit tests on FreeBSD for either 2.067 or master: 0.000s PASS release64 object 0.000s PASS release64 core.atomic 0.008s PASS release64 core.bitop 0.000s PASS release64 core.checkedint 0.000s PASS release64 core.demangle 0.000s PASS release64 core.exception 0.000s PASS release64 core.math 0.000s PASS release64 core.memory posix.mak:230: recipe for target 'obj/64/core/thread' failed gmake: *** [obj/64/core/thread] Illegal instruction gmake: *** Deleting file 'obj/64/core/thread' 2.066 works fine, so I assume that something was introduced since then, but clearly the autotesters are working for FreeBSD, so I have to wonder whether I have an environmental problem with my machine or whether I've just done something differently from the autotesters and am hitting a problem in either the compiler or in druntime that's a general problem that the autotester doesn't hit for whatever reason. I'm running the latest 64-bit PC-BSD. I have no idea what the autotesters are running. Is anyone else seeing anything like this? - Jonathan M Davis
Re: DIP76: Autodecode Should Not Throw
On Monday, April 06, 2015 20:16:19 Walter Bright via Digitalmars-d wrote: http://wiki.dlang.org/DIP76 I am fully in favor of this. Most code really doesn't care about invalid unicode, and if it does, it can check explicitly. Using the replacement character is much cleaner and follows the Unicode standard. And in my experience, if I run into invalid Unicode, I generally have to process it regardless, forcing me to do something like use the replacement character anyway. The fact that std.utf.decode throws just becomes an annoyance. About the only real downside to this that I can think of is that if you're writing a new string algorithm, and you botch it such that it mangles the Unicode, right now, you'd quickly get exceptions, whereas with this change, you wouldn't. But if you're testing your string-based code with Unicode rather than just ASCII, then that should still get caught. Regardless, I think that this is the way to go. - Jonathan M Davis
Re: Any D plugins for recent Xcode?
On Saturday, 18 April 2015 at 20:18:56 UTC, Dan Olson wrote: Yeah, I was hoping somone might have done the same for Xcode 6. I've never poked at how Xcode plugins works, maybe somehow it can be upgraded. I have gotten the impression that the Xcode plugin API changes often and is undocumented, making it hard to maintain something non-Apple. http://www.joelonsoftware.com/articles/fog000339.html
Re: SDC needs you -- redux
On Sunday, 19 April 2015 at 05:04:56 UTC, Andrei Alexandrescu wrote: On 4/18/15 3:08 PM, Mengu wrote: On Saturday, 18 April 2015 at 21:21:42 UTC, Andrei Alexandrescu wrote: On 4/18/15 10:21 AM, Shammah Chancellor wrote: The tooling for golang is a major reason for it's adoption. This tooling looks like gofix, gofmt, govet, etc. We need this tooling to be able to succeed. Agreed (as with your entire call to arms - nicely done). Where's a complete description of Go's out-of-the-box tooling? That's definitely an example we can draw inspiration from. -- Andrei here it is: https://golang.org/cmd/ many of them are also passed to go cmd as an argument. like go fmt, go vet, go test, etc. Cool, thanks! Looking forward to tips from Go users about which tools are most appreciated and appropriate for a D incarnation. -- Andrei gofmt, much like python's standardized formatting, made contributing to go projects much easier IMO. While the same can't be done for D, hopefully dfmt becomes a standard tool and each dub project can just include a dfmt.conf or something to make contributing easier. I agree with the OP on the tooling point, just look at C++. C++ had historically zero(okay, some - but it sucked! ctags were awful, etc.) tooling before clang hit the scene. IMO clang/LLVM was a complete game changer for C++ tooling, and I hope D can do the same. Clang has a static analyzer, a formatter, a modernizer... Hell, clang(and obv. libclang) can dump the AST right from its driver, and even has autocompletion built into it(-code-completion-at) Also, it offers many sanitizers now(undefined behavior, thread, memory, address, leak, dataflow, probably others I forgot). AFAIK a few of these are usable with LDC?
Request for testers: GDC-5.1 Release Candidate branched
Hi, GCC-5.1 has hit RC, and so it's all rush again to get bug fixes in quick before the window closes. Packages are up on Debian: https://packages.debian.org/experimental/gdc-5 Latest changes however are on github: https://github.com/D-Programming-GDC/GDC/tree/gdc-5 Updates/Fixes from gdc-4.9 include: - Front-end updated from 2.065.0 to 2.066.1 - Added goto support for GDC Extended Inline Assembler - Added -fbounds-check=safe compiler option - Added Runtime support for EMUTLS targets - Added new gcc.attributes section, weak and alias - Partially fixed thunk support for externally referenced methods (only variadic methods now don't work) - Improved Closure/Frame chaining, all tests now passing in the testsuite[1] - Improved NRVO support to take advantage of Return Slot Optimisation (RSO), all tests now passing in the testsuite[2] Last feature I am working on getting in is runtime exception chaining support. If anyone has any grand ideas, they'd be more than welcome. [1]: https://github.com/D-Programming-GDC/GDC/commit/84e77850a4e9184526d9b571fb8bdfda4dc103a1#diff-cbd05be6883e1f976bc2eee00b1e6bcaL2442 [2]: https://github.com/D-Programming-GDC/GDC/commit/b9bbf568c20d806bc8570c8cefe41bf57c729bb1#diff-2a4fd18a3f136c982c89e12064e0b6baL551 Regards Iain.
Re: Today's programming challenge - How's your Range-Fu ?
On Saturday, 18 April 2015 at 16:01:20 UTC, Andrei Alexandrescu
wrote:
On 4/18/15 4:35 AM, Jacob Carlborg wrote:
On 2015-04-18 12:27, Walter Bright wrote:
That doesn't make sense to me, because the umlauts and the
accented e
all have Unicode code point assignments.
This code snippet demonstrates the problem:
import std.stdio;
void main ()
{
dstring a = e\u0301;
dstring b = é;
assert(a != b);
assert(a.length == 2);
assert(b.length == 1);
writefln(a, , b);
}
If you run the above code all asserts should pass. If your
system
correctly supports Unicode (works on OS X 10.10) the two
printed
characters should look exactly the same.
\u0301 is the combining acute accent [1].
[1] http://www.fileformat.info/info/unicode/char/0301/index.htm
Isn't this solved commonly with a normalization pass? We should
have a normalizeUTF() that can be inserted in a pipeline. Then
the rest of Phobos doesn't need to mind these combining
characters. -- Andrei
Normalisation can allow some simplifications, sometimes, but
knowing whether it will or not requires a lot of a priori
knowledge about the input as well as the normalisation form.
Re: [hackathon] One week left to the first D Hackathon!
On Saturday, 18 April 2015 at 16:26:41 UTC, Andrei Alexandrescu wrote: Join us for one week starting Saturday April 25th for the first D Hackathon! The D Hackathon is one week of intense participation and collaboration on anything and everything related to the D programming language. All participants are encouraged to collaborate on the online forums (http://forum.dlang.org/group/digitalmars.D), github repos (https://github.com/D-Programming-Language), IRC (#d on irc.freenode.net, use your favorite IRC client or https://webchat.freenode.net). Please prepend forum posts related to hackathon with [hackathon]. (There should be little else!) Complete n00bs are encouraged to participate (tell your friends!) and part of the purpose of the D Hackathon is to lower the barrier to entry for would-be collaborators by means of better documentation and tooling. Let's focus on creating a better, more inviting out-of-the-box experience for everyone, and above all a better D language. We'll officially measure hackathon results by the number of preexisting bugs fixed, but do feel free to work on anything you think is important to you. There is no other rule than getting good work done. See you in one week! Andrei Good day! May be it is silly question, but I can't understand. Can I take a part in hackaton remotely? And second question. Will hackaton's projects be published? Thank you. I'm sorry, if my english is not clear.
Re: [hackathon] One week left to the first D Hackathon!
On Saturday, 18 April 2015 at 16:26:41 UTC, Andrei Alexandrescu wrote: Join us for one week starting Saturday April 25th for the first D Hackathon! The D Hackathon is one week of intense participation and collaboration on anything and everything related to the D programming language. All participants are encouraged to collaborate on the online forums (http://forum.dlang.org/group/digitalmars.D), github repos (https://github.com/D-Programming-Language), IRC (#d on irc.freenode.net, use your favorite IRC client or https://webchat.freenode.net). Please prepend forum posts related to hackathon with [hackathon]. (There should be little else!) Complete n00bs are encouraged to participate (tell your friends!) and part of the purpose of the D Hackathon is to lower the barrier to entry for would-be collaborators by means of better documentation and tooling. Let's focus on creating a better, more inviting out-of-the-box experience for everyone, and above all a better D language. We'll officially measure hackathon results by the number of preexisting bugs fixed, but do feel free to work on anything you think is important to you. There is no other rule than getting good work done. See you in one week! Andrei Good day! May be it is silly question, but I can't understand. Can I take a part in hackaton remotely? And second question. Will hackaton's projects be published? Thank you. I'm sorry, if my english is not clear.
[Issue 14463] New: DMD crashes compiling module level immutable struct that takes an array in ctor
https://issues.dlang.org/show_bug.cgi?id=14463
Issue ID: 14463
Summary: DMD crashes compiling module level immutable struct
that takes an array in ctor
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: minor
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: dzug...@gmail.com
DMD on Windows v2.067 (seems to work on dpaste (presumably 2.065 there))
module main;
struct Boo
{
private int[1] c;
this(int[] x)
{
c = x;
}
}
immutable Boo a = Boo([1]);
Works without immutable, works if declaration of a is moved below module
level, works with constructor accepting plain value.
--
Re: Input ranges
On Saturday, 18 April 2015 at 22:01:56 UTC, Ulrich Küttler wrote: Input ranges from std.stdio are used for reading files. So assuming we create a file auto f = File(test.txt, w); f.writeln(iota(5).map!(a = repeat(to!string(a), 4)).joiner.joiner(\n)); f.close(); We should be able groupBy (chunkBy) its lines: writeln(File(test.txt).byLine.groupBy!((a,b) = a == b)); The result is just one group, that is all lines are considered equal: [[0, 0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3, 4, 4, 4, 4]] Alas, byLine reuses the same buffer for each line and thus groupBy keeps comparing each line with itself. There is a version of byLine that makes copies: writeln(File(test.txt).byLineCopy.groupBy!((a,b) = a == b)); Indeed, the result is as expected: [[0, 0, 0, 0], [1, 1, 1, 1], [2, 2, 2, 2], [3, 3, 3, 3], [4, 4, 4, 4]] Yeah, byLine is dangerous. byLineCopy should probably have been the default. Maybe we should rename byLine to byLineNoCopy (doing the proper deprecation dance, of course). A final test with the undocumented byRecord method (the mapping after groupBy is for beauty only and does not change the result): writeln(File(test.txt) .byRecord!string(%s) .groupBy!((a,b) = a == b) .map!(map!(a = a[0]))); Here, the result is most peculiar: [[0, 0, 0, 0], [1, 1, 1], [2, 2, 2], [3, 3, 3], [4, 4, 4]] Is byRecord broken? (It is undocumented after all.) In a way, because it does not contain any indirection. The current fields tuple is a simple member of the ByRecord struct. In contrast, the ByLineCopy struct is just a wrapper to a ref counted ByLineCopyImpl struct with a simple note: /* Ref-counting stops the source range's ByLineCopyImpl * from getting out of sync after the range is copied, e.g. * when accessing range.front, then using std.range.take, * then accessing range.front again. */ I am uncomfortable at this point. Simple and efficient input ranges fail in unexpected ways. Internal indirections make all the difference. It feels like input ranges are hiding something that should not be hidden. What am I missing? I guess the problem is the mix of value and reference semantics. ByRecord's `current` is a value, but its `file` has reference semantics. So, a copy of a ByRecord affects one part of the original but not the other. Maybe copying should be `@disable`d for such ranges/structs. Then you couldn't pass it by value to groupBy. Instead you would have to use something like (the fixed version of) refRange, which works properly.
Re: Request for testers: GDC-5.1 Release Candidate branched
On 19 April 2015 at 09:13, Iain Buclaw ibuc...@gdcproject.org wrote: Last feature I am working on getting in is runtime exception chaining support. If anyone has any grand ideas, they'd be more than welcome. First attempt: https://github.com/D-Programming-GDC/GDC/compare/master...ibuclaw:eh_chaining Can someone have a review? In particular, I'd like to know when and when not to chain Exception and/or Error objects together. Regards Iain.
Re: Request for testers: GDC-5.1 Release Candidate branched
On 19 April 2015 at 13:50, Iain Buclaw ibuc...@gdcproject.org wrote: On 19 April 2015 at 09:13, Iain Buclaw ibuc...@gdcproject.org wrote: Last feature I am working on getting in is runtime exception chaining support. If anyone has any grand ideas, they'd be more than welcome. First attempt: https://github.com/D-Programming-GDC/GDC/compare/master...ibuclaw:eh_chaining Can someone have a review? In particular, I'd like to know when and when not to chain Exception and/or Error objects together. For instance, if a new exception is thrown inside a catch handler, what then? If a caught exception is thrown, what then? Regards Iain.
Re: I have made a discovery
On Sunday, 19 April 2015 at 02:50:59 UTC, Rikki Cattermole wrote: So I went with closest I thought it was to make the point. I don't understand what the point is... is it just syntax?
[Issue 4060] Phobos + linux problems with files 2GB
https://issues.dlang.org/show_bug.cgi?id=4060 Joakim db...@joakim.fea.st changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Joakim db...@joakim.fea.st --- This has since been fixed: https://github.com/D-Programming-Language/phobos/commit/3eb9454c78bf6000c773695c03b2ca4bc4babb3a#diff-7945921c543e1ab7460797aeb759d7c5L521 --
Re: SDC needs you -- redux
On Sunday, 19 April 2015 at 05:04:56 UTC, Andrei Alexandrescu wrote: Cool, thanks! Looking forward to tips from Go users about which tools are most appreciated and appropriate for a D incarnation. -- Andrei gofmt -r 'foo - bar' - accurate, context-sensitive renaming without need for any external tool.
Why is object.opEquals not defined as pure?
The following method definition is not possible because
object.opEquals is not defined as pure.
private pure ushort GetTypeHexadecimalValue(TypeInfo myType)
{
if (myType == typeid(byte))
return 0x01;
// some similar lines for other different basic types
throw new Exception(Unknown type passed);
}
What is the reason behind this? is opEquals modifying any global
or object member variables?
Re: if(arr) now a warning
On Friday, April 10, 2015 09:27:55 w0rp via Digitalmars-d wrote: I think it's worth changing this. if (arr) translating to if (arr.length == 0) Is immediately obvious for anyone coming from at least a Python background. I have implemented my own hashmaps in a similar way. For my maps, the length is stored in the map so it can be retrieved in O(1) time, and cast(bool) results in map.length == 0. (This extends also to empty sets.) If we need a deprecation path, we can do it. We just warn about if (arr) for a while, so you are told to use if(arr.length == 0) or if (arr.ptr is null) for a while, then we change the behaviour in another release. I agree with the change, because the current behavior is error-prone. However, I'd just as soon leave if(arr) as illegal so that there's no confusion over it later. Just because one set of folks think that if(arr) is clearly equivalant to if(arr.length != 0) doesn't mean another set of folks will - especially if it's based on what other languages are up to. For instance, while python folks might think that it would be intuitive if if(arr) were equivalent to if(arr.length != 0), the C folks would think that the current behavior of it being equivalent to if(arr is null) would be more intuitive, since they're used to thinking of arrays as pointers. By simply forcing folks to be explicit and say if(arr.length != 0) or if(arr is null), we avoid the problem entirely. - Jonathan M Davis
Re: druntime unit test failures on FreeBSD
On Sunday, 19 April 2015 at 07:36:13 UTC, Jonathan M Davis wrote: I am consistently seeing this when I try and run druntime's unit tests on FreeBSD for either 2.067 or master: 0.000s PASS release64 object 0.000s PASS release64 core.atomic 0.008s PASS release64 core.bitop 0.000s PASS release64 core.checkedint 0.000s PASS release64 core.demangle 0.000s PASS release64 core.exception 0.000s PASS release64 core.math 0.000s PASS release64 core.memory posix.mak:230: recipe for target 'obj/64/core/thread' failed gmake: *** [obj/64/core/thread] Illegal instruction gmake: *** Deleting file 'obj/64/core/thread' 2.066 works fine, so I assume that something was introduced since then, but clearly the autotesters are working for FreeBSD, so I have to wonder whether I have an environmental problem with my machine or whether I've just done something differently from the autotesters and am hitting a problem in either the compiler or in druntime that's a general problem that the autotester doesn't hit for whatever reason. I'm running the latest 64-bit PC-BSD. I have no idea what the autotesters are running. Is anyone else seeing anything like this? I dusted off the old FreeBSD VM I had lying around and tried it out. For me, it hangs in core.thread on FreeBSD 9.1 i386 from a couple years ago when I try to run the druntime unit tests with dmd/druntime HEAD. At least most of the time, I just tried it again and it returned and passed once, out of ten times.
Re: I have made a discovery
On Sunday, 19 April 2015 at 09:57:52 UTC, w0rp wrote: The interesting thing about this is that 'throw new ExceptionType(...)' could be reference counted. The downside of What's wrong with just putting exceptions in a dedicated memory area like C++?
[Issue 14463] DMD crashes compiling module level immutable struct that takes an array in ctor
https://issues.dlang.org/show_bug.cgi?id=14463 --- Comment #1 from dzug...@gmail.com --- c[] = x[]; works too --
Re: Why is object.opEquals not defined as pure?
On Sunday, April 19, 2015 08:03:09 Muahmmad Adel via Digitalmars-d wrote:
The following method definition is not possible because
object.opEquals is not defined as pure.
private pure ushort GetTypeHexadecimalValue(TypeInfo myType)
{
if (myType == typeid(byte))
return 0x01;
// some similar lines for other different basic types
throw new Exception(Unknown type passed);
}
What is the reason behind this? is opEquals modifying any global
or object member variables?
If it were pure, then _every_ class' opEquals would have to be pure. The
same goes with const, @safe, and nothrow. And while some of those attributes
work for most implementations, they don't work for all - especially when
stuff like caching or lazy initialization gets involved. opEquals, opCmp,
toString, and toHash all have this problem. After much discussion on this in
the past, it was decided to remove all 4 of those functions from Object,
forcing base classes to implement them. Unlike in Java or C#, we have proper
templates, so there's really no need to use Object to call those functions,
and it should work to not have them on Object at all.
The problem is that that change hasn't been implemented yet. It was agreed
upon, and some work has been done towards it, but it's nowhere near
complete (e.g. the work required to templatize the free function opEquals
which calls opEquals on class instances has been blocked by compiler bugs).
So, we really haven't done what needs to be done to get this problem solved,
and until we do, the attribute situation on Object's built-in functions is a
bit of a mess.
The associated issues in bugzilla:
https://issues.dlang.org/show_bug.cgi?id=9769
https://issues.dlang.org/show_bug.cgi?id=9770
https://issues.dlang.org/show_bug.cgi?id=9771
https://issues.dlang.org/show_bug.cgi?id=9772
- Jonathan M Davis
Re: Building website from git master, why does it checkout DMD v2.066.1 and die?
On 2015-04-19 10:56, Jacob Carlborg wrote: The makefile isn't updated, see [1]. Trying adding STABLE_DMD_VER=2.067.0 to the command you're running. That won't work because someone thought it was a good idea to split the download site per year :( . Try overriding STABLE_DMD_URL [1] instead. [1] https://github.com/D-Programming-Language/dlang.org/blob/master/posix.mak#L31 -- /Jacob Carlborg
Re: Building website from git master, why does it checkout DMD v2.066.1 and die?
On 2015-04-18 20:52, Gary Willoughby wrote: I'm trying to build the website from git master and i'm getting some errors. Here is the last part of the output: Any ideas what the issue is here? The makefile isn't updated, see [1]. Trying adding STABLE_DMD_VER=2.067.0 to the command you're running. [1] https://github.com/D-Programming-Language/dlang.org/blob/master/posix.mak#L29-L31 -- /Jacob Carlborg
Re: Any D plugins for recent Xcode?
On 2015-04-19 02:28, Michel Fortin wrote: It's undocumented API, and they sometime change it although not that much. Xcode 4 broke the plugin and I didn't put much effort into figuring out what was wrong. Feel free to fork and fix it if you want, the code is on Github. https://github.com/michelf/d-for-xcode/ Xcode 4 was a big change compared to Xcode 3. Hopefully there aren't that many changes in later versions. There are many other plugins that work with Xcode 6 that one can look at. There's even a package manager for Xcode plugins [1], which is a good starting point to find other plugins. [1] http://alcatraz.io/ -- /Jacob Carlborg
Re: I have made a discovery
The interesting thing about this is that 'throw new ExceptionType(...)' could be reference counted. The downside of not getting rid of the 'new' overloading at some point is that it can make the operator do surprising and unexpected things, so the rationale for getting rid of it is similar to the rationale behind disallowing overloading of '' and '||'. What I found more interesting is that class constructors themselves can be marked @nogc, which I never thought to do before. So whatever syntax we end up with for 'allocate with this other allocator and call this constructor' could take advantage of that. I'm not sure how that will end up looking in the end, but I am reminded of Objective C again, where allocation and construction are explicitly separated. // Enough time in Wonderland makes this seem perfectly natural. MyClass* foo = [[MyClass alloc] initWithNumber:3];
Re: I have made a discovery
On 19/04/2015 11:48 p.m., Adam D. Ruppe wrote: On Sunday, 19 April 2015 at 02:50:59 UTC, Rikki Cattermole wrote: So I went with closest I thought it was to make the point. I don't understand what the point is... is it just syntax? I was just toying with different syntax's regarding allocation. Atleast to me, none of them really fit.
Re: Where is COFFIMPLIB
On 2015-04-18 20:20, Darrell Gallion wrote: Thought there were other complications on Windows for 64bit? I don't know, I never used it. -- /Jacob Carlborg
Re: Building website from git master, why does it checkout DMD v2.066.1 and die?
On 2015-04-19 10:56, Jacob Carlborg wrote: The makefile isn't updated, see [1]. Trying adding STABLE_DMD_VER=2.067.0 to the command you're running. Pull request: https://github.com/D-Programming-Language/dlang.org/pull/968 -- /Jacob Carlborg
Re: Today's programming challenge - How's your Range-Fu ?
On 19/04/15 10:51, Abdulhaq wrote: MiOn Sunday, 19 April 2015 at 02:20:01 UTC, Shachar Shemesh wrote: On 18/04/15 21:40, Walter Bright wrote: Also, notice that some letters can only be achieved using multiple code points. Hebrew diacritics, for example, do not, typically, have a composite form. My name fully spelled (which you rarely would do), שַׁחַר, cannot be represented with less than 6 code points, despite having only three letters. Yes Arabic is similar too Actually, the Arab presentation forms serve a slightly different purpose. In Hebrew, the presentation forms are mostly for Bibilical text, where certain decorations are usually done. For Arabic, the main reason for the presentation forms is shaping. Almost every Arabic letter can be written in up to four different forms (alone, start of word, middle of word and end of word). This means that Arabic has 28 letters, but over 100 different shapes for those letters. These days, when the font can do the shaping, the 28 letters suffice. During the DOS days, you needed to actually store those glyphs somewhere, which means that you needed to allocate a number to them. In Hebrew, some letters also have a final form. Since the numbers are so significantly smaller, however, (22 letters, 5 of which have final forms), Hebrew keyboards actually have all 27 letters on them. Going strictly by the Unicode way, one would be expected to spell שלום with U05DE as the last letter, and let the shaping engine figure out that it should use the final form (or add a ZWNJ). Since all Hebrew code charts contained a final form Mem, however, you actually spell it with U05DD in the end, and it is considered a distinct letter. Shachar
Re: Any D plugins for recent Xcode?
On 2015-04-18 22:18, Dan Olson wrote: Another approach is to use different IDE that can supports iOS dev (download, debug). Not sure what is available, but these folks setup Eclipse for Java iOS dev. Xamarin [1] seems to have pretty good support for iOS development. They collaborating with Microsoft to make C# (.Net) the first choice for developing cross-platform mobile applications. Their IDE is based on (or the new) MonoDevelop, which a D plugin already exists for, Mono-D [2]. I've look at a couple of their talks and it looks really good. Although I still prefer to use Xcode. [1] http://xamarin.com/ [2] https://github.com/aBothe/Mono-D -- /Jacob Carlborg
Re: Today's programming challenge - How's your Range-Fu ?
On Sunday, 19 April 2015 at 02:20:01 UTC, Shachar Shemesh wrote: U0065+U0301 rather than U00e9. Because of legacy systems, and because they would rather have the ISO-8509 code pages be 1:1 mappings, rather than 1:n mappings, they introduced code points they really would rather do without. That's probably right. It is in fact a major feat to have the world adopt a new standard wholesale, but there are also difficult semiotic issues when you encode symbols and different languages view symbols differently (e.g. is ä an a or do you have two unique letters in the alphabet?) Take å, it can represent a unit (ångström) or a letter with a circle above it, or a unique letter in the alphabet. The letter æ can be seen as a combination of ae or a unique letter. And we can expect languages, signs and practices to evolve over time too. How can you normalize encodings without normalizing writing practice and natural language development? That would be beyond the mandate of a unicode standard organization...
Re: Linker errors building tools from git master
On Saturday, 18 April 2015 at 17:15:40 UTC, Gary Willoughby wrote: Any ideas why i'm getting these linker errors? This seems to be because i wasn't correctly specifying the newly generated phobos lib in the dmd.conf.
Re: Request for testers: GDC-5.1 Release Candidate branched
On Sunday, 19 April 2015 at 07:13:16 UTC, Iain Buclaw wrote: Hi, GCC-5.1 has hit RC, and so it's all rush again to get bug fixes in quick before the window closes. Packages are up on Debian: https://packages.debian.org/experimental/gdc-5 Latest changes however are on github: https://github.com/D-Programming-GDC/GDC/tree/gdc-5 Updates/Fixes from gdc-4.9 include: - Front-end updated from 2.065.0 to 2.066.1 - Added goto support for GDC Extended Inline Assembler - Added -fbounds-check=safe compiler option - Added Runtime support for EMUTLS targets - Added new gcc.attributes section, weak and alias - Partially fixed thunk support for externally referenced methods (only variadic methods now don't work) - Improved Closure/Frame chaining, all tests now passing in the testsuite[1] - Improved NRVO support to take advantage of Return Slot Optimisation (RSO), all tests now passing in the testsuite[2] Last feature I am working on getting in is runtime exception chaining support. If anyone has any grand ideas, they'd be more than welcome. [1]: https://github.com/D-Programming-GDC/GDC/commit/84e77850a4e9184526d9b571fb8bdfda4dc103a1#diff-cbd05be6883e1f976bc2eee00b1e6bcaL2442 [2]: https://github.com/D-Programming-GDC/GDC/commit/b9bbf568c20d806bc8570c8cefe41bf57c729bb1#diff-2a4fd18a3f136c982c89e12064e0b6baL551 Regards Iain. I don't have too much to report (which is a good thing in this case): I did a fresh install from source, following [1], and I didn't encounter any problems. I was already compiling my code with an earlier GDC version that used the 2.066.1 front-end (which is required for my code) because it gives me a 2.5x speed increase for my code execution (in my Linux VM at least), so I love the new release already :-D Cheers, Stefan [1] http://wiki.dlang.org/GDC/Installation/Generic
Re: I have made a discovery
On Saturday, 18 April 2015 at 15:24:27 UTC, w0rp wrote: Consider also the coming addition to the language for class reference counting methods opAddRef and opRelease. Since it's classes we are talking about, wouldn't that mean we need to do a virtual function call each time a class reference gets assigned or goes out of scope(and twice when it gets reassigned)?
Re: nginx module bindings
On 2015-04-19 01:03, Shammah Chancellor wrote: I included the -I flag for the location of those included headers. It seems as if maybe it is not including anything. With that said, I am using clan release_34, because I cannot build 32 on MacOS X. Is there a build script you can inspect to see if it does anything magic? These [1] are the versions that are tested by Travis on OS X. You can always download pre-compiled versions of libclang here [2]. libclang can be placed in any of the standard search paths or in the same directory as the binary. [1] https://github.com/jacob-carlborg/dstep/blob/master/test.d#L321-L327 [2] http://llvm.org/releases/index.html -- /Jacob Carlborg
Re: if(arr) now a warning
On Sunday, 19 April 2015 at 08:05:46 UTC, Jonathan M Davis wrote: On Friday, April 10, 2015 09:27:55 w0rp via Digitalmars-d wrote: I think it's worth changing this. if (arr) translating to if (arr.length == 0) Is immediately obvious for anyone coming from at least a Python background. I have implemented my own hashmaps in a similar way. For my maps, the length is stored in the map so it can be retrieved in O(1) time, and cast(bool) results in map.length == 0. (This extends also to empty sets.) If we need a deprecation path, we can do it. We just warn about if (arr) for a while, so you are told to use if(arr.length == 0) or if (arr.ptr is null) for a while, then we change the behaviour in another release. I agree with the change, because the current behavior is error-prone. However, I'd just as soon leave if(arr) as illegal so that there's no confusion over it later. Just because one set of folks think that if(arr) is clearly equivalant to if(arr.length != 0) doesn't mean another set of folks will - especially if it's based on what other languages are up to. For instance, while python folks might think that it would be intuitive if if(arr) were equivalent to if(arr.length != 0), the C folks would think that the current behavior of it being equivalent to if(arr is null) would be more intuitive, since they're used to thinking of arrays as pointers. By simply forcing folks to be explicit and say if(arr.length != 0) or if(arr is null), we avoid the problem entirely. - Jonathan M Davis Unfortunately it also disables this very useful idiom: if(auto name = getName()) I.e. declaration and conditional in one.
Re: Today's programming challenge - How's your Range-Fu ?
MiOn Sunday, 19 April 2015 at 02:20:01 UTC, Shachar Shemesh wrote: On 18/04/15 21:40, Walter Bright wrote: I'm not arguing against the existence of the Unicode standard, I'm saying I can't figure any justification for standardizing different encodings of the same thing. A lot of areas in Unicode are due to pre-Unicode legacy. I'm guessing here, but looking at the code points, é (U00e9 - Latin small letter E with acute), which comes from Latin-1, which is designed to follow ISO-8859-1. U0301 (Combining acute accent) comes from Combining diacritical marks. The way I understand things, Unicode would really prefer to use U0065+U0301 rather than U00e9. Because of legacy systems, and because they would rather have the ISO-8509 code pages be 1:1 mappings, rather than 1:n mappings, they introduced code points they really would rather do without. This also explains the presentation forms code pages (e.g. http://www.unicode.org/charts/PDF/UFB00.pdf). These were intended to be glyphs, rather than code points. Due to legacy reasons, it was not possible to simply discard them. They received code points, with a warning not to use these code points directly. Also, notice that some letters can only be achieved using multiple code points. Hebrew diacritics, for example, do not, typically, have a composite form. My name fully spelled (which you rarely would do), שַׁחַר, cannot be represented with less than 6 code points, despite having only three letters. The last paragraph isn't strictly true. You can use UFB2C + U05B7 for the first letter instead of U05E9 + U05C2 + U05B7. You would be using the presentation form which, as pointed above, is only there for legacy. Shachar or shall I say שחר Yes Arabic is similar too
Re: Today's programming challenge - How's your Range-Fu ?
On Saturday, 18 April 2015 at 17:50:12 UTC, Walter Bright wrote: On 4/18/2015 4:35 AM, Jacob Carlborg wrote: \u0301 is the combining acute accent [1]. [1] http://www.fileformat.info/info/unicode/char/0301/index.htm I won't deny what the spec says, but it doesn't make any sense to have two different representations of eacute, and I don't know why anyone would use the two code point version. é might be obvious, but Unicode isn't just for writing European prose. Uses for combining characters includes (but is *nowhere* near to limited to) mathematical notation, where the combinatorial explosion of possible combinations that still belong to one grapheme cluster (character is a familiar but misleading word when talking about Unicode) would trivially become an insanely (more atoms than in the universe levels of) large number of characters. Unicode is a nightmarish system in some ways, but considering how incredibly difficult the problem it solves is, it's actually not too crazy.
Re: GtkD 3.1.0 released, GTK+ with D.
On Thursday, 26 March 2015 at 22:41:01 UTC, Mike Wey wrote: GtkD is a D binding and OO wrapper of Gtk+ and is released on the LGPL license. Shortly after the last release, GtkD has been updated for GTK+ 3.16. GtkD 3.1.0 is now available on gtkd.org: http://gtkd.org/download.html Mike, Broadly speaking, how much work is involved in converting an app using GtkD 2.4? Thanks Steve
[Issue 14454] Lambda template param doesn't compile with -inline *** is a nested function and cannot be accessed from ***
https://issues.dlang.org/show_bug.cgi?id=14454 dzug...@gmail.com changed: What|Removed |Added Hardware|x86_64 |x86 --
Re: Reuse object memory?
It seems that D has currently no direct support to reuse object
memory.
D should add a new-placement syntax:
Foo f = new Foo(42);
new (f) Foo(23);
and/or should add an emplace overload which takes an object:
T emplace(T, Args...)(ref T obj, auto ref Args args) if (is(T ==
class)) {
if (obj is null)
return null;
enum size_t ClassSize = __traits(classInstanceSize, T);
void[] buf = (cast(void*) obj)[0 .. ClassSize];
import std.conv : emplace;
return emplace!(T)(buf, args);
}
Adding pointers to GC with destructers
C libraries have a pattern of HiddenType* getObj(); void freeObj(HiddenType*); Is there any way I can make the GC search for a HiddenType* and run freeObj when the pointer is not found.
Re: [hackathon] One week left to the first D Hackathon!
On Sunday, 19 April 2015 at 13:03:22 UTC, ANtlord wrote: On Saturday, 18 April 2015 at 16:26:41 UTC, Andrei Alexandrescu wrote: Join us for one week starting Saturday April 25th for the first D Hackathon! The D Hackathon is one week of intense participation and collaboration on anything and everything related to the D programming language. All participants are encouraged to collaborate on the online forums (http://forum.dlang.org/group/digitalmars.D), github repos (https://github.com/D-Programming-Language), IRC (#d on irc.freenode.net, use your favorite IRC client or https://webchat.freenode.net). Please prepend forum posts related to hackathon with [hackathon]. (There should be little else!) Complete n00bs are encouraged to participate (tell your friends!) and part of the purpose of the D Hackathon is to lower the barrier to entry for would-be collaborators by means of better documentation and tooling. Let's focus on creating a better, more inviting out-of-the-box experience for everyone, and above all a better D language. We'll officially measure hackathon results by the number of preexisting bugs fixed, but do feel free to work on anything you think is important to you. There is no other rule than getting good work done. See you in one week! Andrei Good day! May be it is silly question, but I can't understand. Can I take a part in hackaton remotely? And second question. Will hackaton's projects be published? Thank you. I'm sorry, if my english is not clear. I can't speak for Andrei, but I think this is more of a casual do some work on something valuable to D session rather than a formal hackathon. I think everyone will be working remotely.
Re: Input ranges
On Sunday, 19 April 2015 at 21:42:23 UTC, Ulrich Küttler wrote: groupBy is a nice example as it laboriously adds reference semantics to forward ranges but assumes input ranges to posses reference semantics by themselves. All ranges are input ranges, though. Input ranges are the least specialised category. I think it's a mistake to assume/require anything only for input ranges that are not forward ranges. I guess we could require reference semantics for all input ranges (including forward ranges and higher-ups). That would be a rather clean way out of this mess. But it would be a major effort. And I guess it would hurt performance, maybe a lot. [...] Again, I agree. Disallow copying for such ranges would prevent the error, still it would be a bit harsh. It is not just groupBy that goes astray. You can also get strange results from take: auto r = File(test.txt).byRecord!string(%s); foreach (i; 0 .. 5) writeln(r.take(4).map!(a = a[0])); That would also not be possible if ByRecord had an `@disable this(this);`. But I'm not at all sure that this is the way to go. It's bound to be forgotten, and there are probably places where it's needlessly restrictive. I was hoping to find some communication how input ranges should be done. I'm right there with you. This is all a bit iffy. I suspect that this is an oversight in the design of ranges, as the documentation of std.range doesn't say anything on the topic. This may be too advanced for D.learn. I don't think Andrei and Walter come down here very often. Maybe take it to the general board. At this point the solution in byLineCopy feels ad hoc. I think byLineCopy solves a different problem. ByLine already has this: https://github.com/D-Programming-Language/phobos/blob/v2.067.0/std/stdio.d#L1592-L1598
[Issue 9721] Code coverage for templates
https://issues.dlang.org/show_bug.cgi?id=9721 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #2 from Martin Nowak c...@dawg.eu --- We can't merge this with the existing coverage, it's more like a -staticcov. Seems pretty complex for what it achieves. --
[Issue 14465] New: CTFE exception stacktrace shows location of Exception constructor
https://issues.dlang.org/show_bug.cgi?id=14465
Issue ID: 14465
Summary: CTFE exception stacktrace shows location of Exception
constructor
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
cat bug.d CODE
class E : Exception
{
this(string msg)
{
super(msg);
}
}
bool foo()
{
throw new E(message);
}
static assert(foo());
CODE
dmd -c bug
bug.d(5): Error: uncaught CTFE exception bug.E(message)
bug.d(11):thrown from here
bug.d(14):called from here: foo()
bug.d(14):while evaluating: static assert(foo())
The first line shouldn't be present in the stacktrace, b/c that's code
constructing the exception, which happens before the exception is thrown.
--
readText for large files on Windows.
This function works fine for large text files like 100Mb or 1Gb but failed when I tried to read 6Gb file. This happens on Windows x64. The possible reason that it uses read(in char[], size_t) function and on windows it calls GetFileSize. This function returns file size as 32 bit value. If you need size for files larger then 4Gb then this function provides out parameter where you can pass reference to another 32 bit value. But in DMD 2.067 this function is called as auto size = trustedGetFileSize(h, null); thus we never get correct size for files larget then 4Gb. Is it a bug?
[Issue 14465] CTFE exception stacktrace shows location of Exception constructor
https://issues.dlang.org/show_bug.cgi?id=14465 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added Keywords||pull CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de --- https://github.com/D-Programming-Language/dmd/pull/4599 --
Re: Building website from git master, why does it checkout DMD v2.066.1 and die?
On Sunday, 19 April 2015 at 16:21:45 UTC, Jacob Carlborg wrote: Do you have libcurl installed? Yeah and i've looked at the build scripts etc, and can't see anything obviously wrong.
Re: [hackathon] One week left to the first D Hackathon!
On Sunday, 19 April 2015 at 19:38:14 UTC, Gary Willoughby wrote: Also the tools repository needs work to build too. This is because of the `if(arr)` warnings. I think there are pull requests waiting[2] but until they are merged a few of the tools are broken which breaks the whole build. Dustmite also needs to be amended upstream[3]. Waiting on definitive yes/no regarding the compiler change and code breakage from Walter/Andrei.
Re: Reuse object memory?
On 04/19/2015 09:04 AM, Namespace wrote:
Is it somehow possible to reuse the memory of an object?
Yes, when you cast a class variable to void*, you get the address of the
object.
@nogc
T emplace(T, Args...)(ref T obj, auto ref Args args) nothrow if (is(T ==
class)) {
There is already std.conv.emplace:
import std.conv;
import core.memory;
class Foo
{
int i;
this(int i)
{
this.i = i;
}
}
void main()
{
void* buffer = GC.calloc(1234);
enum FooSize = __traits(classInstanceSize, Foo);
/* These two object are constructed on a void[] slice: */
auto f = emplace!Foo(buffer[0..FooSize], 42);
auto f2 = emplace!Foo(buffer[0..FooSize], 43);
/* f3 is constructed on top of an existing object: */
auto f2_addr = cast(void*)f2;
auto f3 = emplace!Foo(f2_addr[0..FooSize], 44);
/* At this point, all three reference the same object: */
assert(f.i == f2.i);
assert(f.i == f3.i);
}
Ali
[Issue 8196] Compiler pages are missing -nofloat flag
https://issues.dlang.org/show_bug.cgi?id=8196 Gary Willoughby d...@nomad.so changed: What|Removed |Added CC||d...@nomad.so --- Comment #2 from Gary Willoughby d...@nomad.so --- Has this gone now? --
Trial migration of Dsource bindings project to Github
In the light of problems with SVN on dsource, the Bindings project has been migrated to GitHub on a trial basis. Apparently this is more or less the last active project on Dsource, so after a brief discussion on another thread I have decided to give it a try. So it's now at: https://github.com/smjgordon/bindings Please don't confuse this with dsource-bindings, which is an automatically updated mirror of the Dsource project. The one I have linked to is a new repository on GitHub which may become the live repository for the Bindings project. For those of you who are still unfamiliar with GitHub, it's a Subversion repository just like we had on dsource, so you don't need to learn a new way of working or obtain any new tools - you just need to set up a GitHub account if you don't have one already. Could people please try checking out the project on GitHub, and committing a change? There's still plenty of work to do on WindowsAPI so you could do some of the work there. (The wiki is broken at the moment, so I don't recommend trying to edit the module list there, but as a temporary measure you could just post on this thread if you're going to do some major work on one or more of the files.) Failing that, there's a file test.txt (directly under trunk) which you could make a dummy edit to. But whatever you do, please be sure to reply to this thread to let me know whether or not you could commit successfully. If the decision is made to relocate Bindings permanently to GitHub, the wiki pages will be migrated in due course. Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: dsource.org moved
On Friday, 17 April 2015 at 21:34:07 UTC, Stewart Gordon wrote: Has Walter promised us that every pull request for the WindowsAPI bindings will be put in right away? Pull requests are merged once they pass review and automatic testing. Walter Bright is not the only person who can merge pull requests - anyone with commit access can. Even if he had, what would be the point? It would greatly slow down the whole process. We have SVN repositories so that people can just put their updates straight in, Only those who have access can do that. Getting patches into the bindings repository has been historically difficult. Committers have had to commit patches on behalf of other people. and everyone else not only has access to the update straight away but can obtain it with either a one-line command line invocation or a few mouse clicks. Git is not different in this regard. Proposed changes are immediately available in your personal fork.
[Issue 14466] New: destructive move
https://issues.dlang.org/show_bug.cgi?id=14466 Issue ID: 14466 Summary: destructive move Product: D Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: c...@dawg.eu Currently the moved from object has to be reinitialized in order to avoid double freeing in it's destructor. Both operations reinitialization and destroying the moved from object are superfluous, if we had a mean to tell the compiler not to destroy a particular object. https://github.com/D-Programming-Language/phobos/blob/41d1162619039e8e535060b920ff54cc2c44ebbb/std/algorithm/mutation.d#L1015 A destructive move intrinsic would turn an object into an rvalue, disable destruction of the moved from object, and disallow any further usage of the moved from object. The object must be unaliased to make destructive move @safe. Destructively moving anything but named variables (such as fields or single array elements) would be prohibited as it adds compiler complexity or runtime overhead. --
Re: [hackathon] One week left to the first D Hackathon!
On Sunday, 19 April 2015 at 19:38:14 UTC, Gary Willoughby wrote: Also the tools repository needs work to build too. This is because of the `if(arr)` warnings. I think there are pull requests waiting[2] but until they are merged a few of the tools are broken which breaks the whole build. Dustmite also needs to be amended upstream[3]. Waiting on definitive yes/no regarding the compiler change and code breakage from Walter/Andrei.
[Issue 14427] Regression: navigation for phobos documentation has disappeared
https://issues.dlang.org/show_bug.cgi?id=14427 --- Comment #6 from Vladimir Panteleev thecybersha...@gmail.com --- Yeah, that shouldn't be difficult to put together. Just cache uploaded files to a local copy and add a diff Makefile target that diffs built vs. last-uploaded files. I'll add it to my list but not sure when I'll get to this. --
Re: Building website from git master, why does it checkout DMD v2.066.1 and die?
On Sunday, 19 April 2015 at 16:20:23 UTC, Gary Willoughby wrote: If i pass the correct information on the command line it gets past the library errors but now shows linker errors. I'm not seeing the compilation errors when building on the staging server, so not sure why you're getting them. I would suggest to try creating a new directory, cloning dlang.org into a subdirectory of that directory, and then running the build - posix.mak should fetch and build the remaining components. And as for the link errors - this is on a Ubuntu (or Ubuntu-based) distribution, right? Here's my workaround: https://issues.dlang.org/show_bug.cgi?id=12572#c5
[Issue 14427] Regression: navigation for phobos documentation has disappeared
https://issues.dlang.org/show_bug.cgi?id=14427 --- Comment #7 from Vladimir Panteleev thecybersha...@gmail.com --- The pinnacle of your idea is a GitHub bot that pastes diff links on each dlang.org pull request, BTW. --
Re: Reuse object memory?
And if I have an already instantiated object? Foo f = new Foo(); // reuse f's memory Is there an nicer way to override the memory instead of: void[] buf = (cast(void*) f)[0 .. __traits(classInstanceSize, Foo)]; buf = typeid(Foo).init[]; // or: buf = f.classinfo.init[]; ? The void* cast looks very ugly.
Re: Input ranges
On Sunday, 19 April 2015 at 11:33:26 UTC, anonymous wrote: I guess the problem is the mix of value and reference semantics. ByRecord's `current` is a value, but its `file` has reference semantics. So, a copy of a ByRecord affects one part of the original but not the other. I agree. Yet I am convinced most (all?) proper input ranges read input from an external source. (Reference semantic right there.) Input ranges are one-pass ranges after all. Therefore, reference semantics are required in any case (unless the use of the range is known beforehand.) groupBy is a nice example as it laboriously adds reference semantics to forward ranges but assumes input ranges to posses reference semantics by themselves. Maybe copying should be `@disable`d for such ranges/structs. Then you couldn't pass it by value to groupBy. Instead you would have to use something like (the fixed version of) refRange, which works properly. Again, I agree. Disallow copying for such ranges would prevent the error, still it would be a bit harsh. It is not just groupBy that goes astray. You can also get strange results from take: auto r = File(test.txt).byRecord!string(%s); foreach (i; 0 .. 5) writeln(r.take(4).map!(a = a[0])); I was hoping to find some communication how input ranges should be done. At this point the solution in byLineCopy feels ad hoc.
Re: dsource.org moved
The wiki is terribly broken at the moment. I just edited a page http://www.dsource.org/projects/bindings/wiki/WikiStart and it changed every linebreak to the literal string `\r\n`. The page looks OK in preview, but then it breaks when you actually save it. Stewart. -- My email address is valid but not my primary mailbox and not checked regularly. Please keep replies on the 'group where everybody may benefit.
Re: [hackathon] One week left to the first D Hackathon!
On Sunday, 19 April 2015 at 13:03:22 UTC, ANtlord wrote: On Saturday, 18 April 2015 at 16:26:41 UTC, Andrei Alexandrescu wrote: Join us for one week starting Saturday April 25th for the first D Hackathon! The D Hackathon is one week of intense participation and collaboration on anything and everything related to the D programming language. All participants are encouraged to collaborate on the online forums (http://forum.dlang.org/group/digitalmars.D), github repos (https://github.com/D-Programming-Language), IRC (#d on irc.freenode.net, use your favorite IRC client or https://webchat.freenode.net). Please prepend forum posts related to hackathon with [hackathon]. (There should be little else!) Complete n00bs are encouraged to participate (tell your friends!) and part of the purpose of the D Hackathon is to lower the barrier to entry for would-be collaborators by means of better documentation and tooling. Let's focus on creating a better, more inviting out-of-the-box experience for everyone, and above all a better D language. We'll officially measure hackathon results by the number of preexisting bugs fixed, but do feel free to work on anything you think is important to you. There is no other rule than getting good work done. See you in one week! Andrei Good day! May be it is silly question, but I can't understand. Can I take a part in hackaton remotely? And second question. Will hackaton's projects be published? Thank you. I'm sorry, if my english is not clear. I can't speak for Andrei, but I think this is more of a casual do some work on something valuable to D session rather than a formal hackathon. I think everyone will be working remotely.
Re: Trial migration of Dsource bindings project to Github
On Sunday, 19 April 2015 at 23:14:13 UTC, Stewart Gordon wrote: For those of you who are still unfamiliar with GitHub, Stewart, I haven't seen an active D project that WASN'T hosted on GitHub for years now. Could people please try checking out the project on GitHub, and committing a change? Git commits are local, and will always succeed. I'm guessing you actually want to allow anyone to push their commits to your repository, which is not how collaboration on GitHub works. You may want to read up on pull requests: https://help.github.com/articles/using-pull-requests/ I'm sorry about the Dsource malfunctions. When I took over hosting, my goal was to archive it in a read-only state. The move has eaten much more of my time than I have anticipated, because it depends so much on ancient software that is difficult to get running these days short of making a virtual machine. There's still plenty of work to do on WindowsAPI so you could do some of the work there. (The wiki is broken at the moment, so I don't recommend trying to edit the module list there, but as a temporary measure you could just post on this thread if you're going to do some major work on one or more of the files.) The module list has no value these days. Most people in that list no longer use D. Git allows quickly checking the history of any one file. Contributions to the project itself have been so few that it makes no sense to partition out module ownership. If the decision is made to relocate Bindings permanently to GitHub, the wiki pages will be migrated in due course. Given that SVN is going the way of RCS and CVS, it's not really an if.
Re: [hackathon] One week left to the first D Hackathon!
On Saturday, 18 April 2015 at 16:26:41 UTC, Andrei Alexandrescu wrote: Join us for one week starting Saturday April 25th for the first D Hackathon! The D Hackathon is one week of intense participation and collaboration on anything and everything related to the D programming language. All participants are encouraged to collaborate on the online forums (http://forum.dlang.org/group/digitalmars.D), github repos (https://github.com/D-Programming-Language), IRC (#d on irc.freenode.net, use your favorite IRC client or https://webchat.freenode.net). Please prepend forum posts related to hackathon with [hackathon]. (There should be little else!) Complete n00bs are encouraged to participate (tell your friends!) and part of the purpose of the D Hackathon is to lower the barrier to entry for would-be collaborators by means of better documentation and tooling. Let's focus on creating a better, more inviting out-of-the-box experience for everyone, and above all a better D language. We'll officially measure hackathon results by the number of preexisting bugs fixed, but do feel free to work on anything you think is important to you. There is no other rule than getting good work done. See you in one week! Andrei This sounds awesome! I'm going to give the website and phobos documentation a pass making corrections and adding examples, beefing up, etc. So i'll trawl bugzilla looking for low hanging fruit/easy stuff to get my feet wet. I've run into a few problems[1] with building the website and documentation. DMD, druntime and phobos all build easily but dlang.org sources are a pain. I wonder if anyone has built the website recently from scratch to make sure it all works? Also the tools repository needs work to build too. This is because of the `if(arr)` warnings. I think there are pull requests waiting[2] but until they are merged a few of the tools are broken which breaks the whole build. Dustmite also needs to be amended upstream[3]. [1]: http://forum.dlang.org/thread/wwktjyurctmdffmfe...@forum.dlang.org [2]: https://github.com/D-Programming-Language/tools/pull/166/files [3]: https://github.com/CyberShadow/DustMite
[Issue 4153] [cov] Code coverage output improvement
https://issues.dlang.org/show_bug.cgi?id=4153 Martin Nowak c...@dawg.eu changed: What|Removed |Added Status|NEW |RESOLVED CC||c...@dawg.eu Resolution|--- |FIXED --
[Issue 14464] New: coverage merge doesn't work
https://issues.dlang.org/show_bug.cgi?id=14464 Issue ID: 14464 Summary: coverage merge doesn't work Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: c...@dawg.eu Using dmd_coverSetMerge(true) to combine the coverage results of multiple runs produces garbage numbers, because the code in rt.cover that parses the existing .lst files is broken [¹]. Enabling merge only works if .lst files already exist, otherwise coverage generation is silently skipped. Merging coverage reports should be the default, similar to gcov and dmd's -prof, as overwriting existing data is rarely useful. [¹]: https://github.com/D-Programming-Language/druntime/blob/111892fa6ac6bb2005f4f13b4c6bad98399f65b1/src/rt/cover.d#L174 --
Re: Request for testers: GDC-5.1 Release Candidate branched
On Sunday, 19 April 2015 at 12:04:19 UTC, Stefan Frijters wrote: On Sunday, 19 April 2015 at 07:13:16 UTC, Iain Buclaw wrote: Hi, GCC-5.1 has hit RC, and so it's all rush again to get bug fixes in quick before the window closes. Packages are up on Debian: https://packages.debian.org/experimental/gdc-5 Latest changes however are on github: https://github.com/D-Programming-GDC/GDC/tree/gdc-5 Updates/Fixes from gdc-4.9 include: - Front-end updated from 2.065.0 to 2.066.1 - Added goto support for GDC Extended Inline Assembler - Added -fbounds-check=safe compiler option - Added Runtime support for EMUTLS targets - Added new gcc.attributes section, weak and alias - Partially fixed thunk support for externally referenced methods (only variadic methods now don't work) - Improved Closure/Frame chaining, all tests now passing in the testsuite[1] - Improved NRVO support to take advantage of Return Slot Optimisation (RSO), all tests now passing in the testsuite[2] Last feature I am working on getting in is runtime exception chaining support. If anyone has any grand ideas, they'd be more than welcome. [1]: https://github.com/D-Programming-GDC/GDC/commit/84e77850a4e9184526d9b571fb8bdfda4dc103a1#diff-cbd05be6883e1f976bc2eee00b1e6bcaL2442 [2]: https://github.com/D-Programming-GDC/GDC/commit/b9bbf568c20d806bc8570c8cefe41bf57c729bb1#diff-2a4fd18a3f136c982c89e12064e0b6baL551 Regards Iain. I don't have too much to report (which is a good thing in this case): I did a fresh install from source, following [1], and I didn't encounter any problems. I was already compiling my code with an earlier GDC version that used the 2.066.1 front-end (which is required for my code) because it gives me a 2.5x speed increase for my code execution (in my Linux VM at least), so I love the new release already :-D Cheers, Stefan [1] http://wiki.dlang.org/GDC/Installation/Generic thank you for work, i like it :) but, this version support android?
I need dmd2's Arm platform compile.
I need to use DMD compilation arm or arm64 version, don't know DMD now support for the arm. I think it is very important to the arm of a structure, such as rust/go is good enough to support the architecture. I hope we can improve in arm.
Re: Today's programming challenge - How's your Range-Fu ?
On Sun, 19 Apr 2015 07:54:36 +, John Colvin wrote: é might be obvious, but Unicode isn't just for writing European prose. it is also to insert pictures of the animals into text. Unicode is a nightmarish system in some ways, but considering how incredibly difficult the problem it solves is, it's actually not too crazy. it's not crazy, it's just broken in all possible ways: http://file.bestmx.net/ee/articles/uni_vs_code.pdf signature.asc Description: PGP signature
Re: Today's programming challenge - How's your Range-Fu ?
On Sunday, 19 April 2015 at 19:58:28 UTC, ketmar wrote: On Sun, 19 Apr 2015 07:54:36 +, John Colvin wrote: é might be obvious, but Unicode isn't just for writing European prose. it is also to insert pictures of the animals into text. There's other uses for unicode?
Re: [hackathon] One week left to the first D Hackathon!
On Saturday, 18 April 2015 at 16:26:41 UTC, Andrei Alexandrescu wrote: Join us for one week starting Saturday April 25th for the first D Hackathon! The D Hackathon is one week of intense participation and collaboration on anything and everything related to the D programming language. All participants are encouraged to collaborate on the online forums (http://forum.dlang.org/group/digitalmars.D), github repos (https://github.com/D-Programming-Language), IRC (#d on irc.freenode.net, use your favorite IRC client or https://webchat.freenode.net). Please prepend forum posts related to hackathon with [hackathon]. (There should be little else!) Complete n00bs are encouraged to participate (tell your friends!) and part of the purpose of the D Hackathon is to lower the barrier to entry for would-be collaborators by means of better documentation and tooling. Let's focus on creating a better, more inviting out-of-the-box experience for everyone, and above all a better D language. We'll officially measure hackathon results by the number of preexisting bugs fixed, but do feel free to work on anything you think is important to you. There is no other rule than getting good work done. See you in one week! Andrei This sounds awesome! I'm going to give the website and phobos documentation a pass making corrections and adding examples, beefing up, etc. So i'll trawl bugzilla looking for low hanging fruit/easy stuff to get my feet wet. I've run into a few problems[1] with building the website and documentation. DMD, druntime and phobos all build easily but dlang.org sources are a pain. I wonder if anyone has built the website recently from scratch to make sure it all works? Also the tools repository needs work to build too. This is because of the `if(arr)` warnings. I think there are pull requests waiting[2] but until they are merged a few of the tools are broken which breaks the whole build. Dustmite also needs to be amended upstream[3]. [1]: http://forum.dlang.org/thread/wwktjyurctmdffmfe...@forum.dlang.org [2]: https://github.com/D-Programming-Language/tools/pull/166/files [3]: https://github.com/CyberShadow/DustMite
Re: I have made a discovery
On 2015-04-19 11:57, w0rp wrote: I'm not sure how that will end up looking in the end, but I am reminded of Objective C again, where allocation and construction are explicitly separated. // Enough time in Wonderland makes this seem perfectly natural. MyClass* foo = [[MyClass alloc] initWithNumber:3]; And in Swift they removed then need to call alloc. -- /Jacob Carlborg
Reuse object memory?
Is it somehow possible to reuse the memory of an object?
My current idea is:
@nogc
T emplace(T, Args...)(ref T obj, auto ref Args args) nothrow if
(is(T == class)) {
if (obj is null)
return null;
enum size_t SIZE = __traits(classInstanceSize, T);
void[] buf = (cast(void*) obj)[0 .. SIZE];
buf = typeid(T).init[];
//obj = cast(T) buf.ptr;
static if (args.length)
obj.__ctor(args);
return obj;
}
Foo f = new Foo(42);
Foo f2 = emplace(f, 23);
But is there a more elegant way to do that? Maybe without calling
the internal __ctor?
In C++ you can do that:
#include iostream
class Foo {
public:
int id;
explicit Foo(int _id) : id(_id) { }
};
int main() {
Foo* f = new Foo(42);
std::cout f ':' f-id std::endl;
new (f) Foo(23);
std::cout f ':' f-id std::endl;
delete f;
}
Re: Building website from git master, why does it checkout DMD v2.066.1 and die?
On Sunday, 19 April 2015 at 09:06:58 UTC, Jacob Carlborg wrote:
On 2015-04-19 10:56, Jacob Carlborg wrote:
The makefile isn't updated, see [1]. Trying adding
STABLE_DMD_VER=2.067.0 to the command you're running.
Pull request:
https://github.com/D-Programming-Language/dlang.org/pull/968
If i pass the correct information on the command line it gets
past the library errors but now shows linker errors.
This is the command i'm using:
make -f posix.mak DMD=../dmd/src/dmd DUB_VER=0.9.23
STABLE_DMD_VER=2.067.0
STABLE_DMD_URL=http://downloads.dlang.org/releases/2.x/2.067.0/dmd.2.067.0.linux.zip
Here are the errors:
...
touch ../dub-0.9.23/.cloned
mkdir -p /tmp/.stable_dmd-2.067.0
TMPFILE=$(mktemp deleteme.) curl -fsSL
http://downloads.dlang.org/releases/2.x/2.067.0/dmd.2.067.0.linux.zip
${TMPFILE}.zip \
unzip -qd /tmp/.stable_dmd-2.067.0 ${TMPFILE}.zip rm
${TMPFILE}.zip
cd ../dub-0.9.23
DC=/tmp/.stable_dmd-2.067.0/dmd2/linux/bin64/dmd ./build.sh
Generating version file...
Running /tmp/.stable_dmd-2.067.0/dmd2/linux/bin64/dmd...
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl.o):
In function `_D3std3net4curl4HTTP21_sharedStaticCtor1542FZv':
std/net/curl.d:(.text._D3std3net4curl4HTTP21_sharedStaticCtor1542FZv+0xf):
undefined reference to `curl_version_info'
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl.o):
In function `_D3std3net4curl4Curl21_sharedStaticCtor1544FZv':
std/net/curl.d:(.text._D3std3net4curl4Curl21_sharedStaticCtor1544FZv+0xf):
undefined reference to `curl_global_init'
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl.o):
In function `_D3std3net4curl4Curl21_sharedStaticDtor1545FZv':
std/net/curl.d:(.text._D3std3net4curl4Curl21_sharedStaticDtor1545FZv+0x5):
undefined reference to `curl_global_cleanup'
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl_c57_192.o):
In function `_D3std3net4curl4HTTP4Impl6__dtorMFZv':
std/net/curl.d:(.text._D3std3net4curl4HTTP4Impl6__dtorMFZv+0x19):
undefined reference to `curl_slist_free_all'
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl_c60_65b.o):
In function `_D3std3net4curl4HTTP16addRequestHeaderMFAxaAxaZv':
std/net/curl.d:(.text._D3std3net4curl4HTTP16addRequestHeaderMFAxaAxaZv+0x11b):
undefined reference to `curl_slist_append'
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl_c79_ea.o):
In function `_D3std3net4curl3FTP4Impl6__dtorMFZv':
std/net/curl.d:(.text._D3std3net4curl3FTP4Impl6__dtorMFZv+0x18):
undefined reference to `curl_slist_free_all'
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl_c79_ea.o):
In function `_D3std3net4curl3FTP3dupMFZS3std3net4curl3FTP':
std/net/curl.d:(.text._D3std3net4curl3FTP3dupMFZS3std3net4curl3FTP+0xab):
undefined reference to `curl_slist_append'
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl_c79_ea.o):
In function `_D3std3net4curl3FTP13clearCommandsMFZv':
std/net/curl.d:(.text._D3std3net4curl3FTP13clearCommandsMFZv+0x20):
undefined reference to `curl_slist_free_all'
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl_c79_ea.o):
In function `_D3std3net4curl3FTP10addCommandMFAxaZv':
std/net/curl.d:(.text._D3std3net4curl3FTP10addCommandMFAxaZv+0x67):
undefined reference to `curl_slist_append'
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl_c7e_432.o):
In function `_D3std3net4curl4Curl10initializeMFZv':
std/net/curl.d:(.text._D3std3net4curl4Curl10initializeMFZv+0x47):
undefined reference to `curl_easy_init'
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl_c7f_149.o):
In function `_D3std3net4curl4Curl3dupMFZS3std3net4curl4Curl':
std/net/curl.d:(.text._D3std3net4curl4Curl3dupMFZS3std3net4curl4Curl+0x2b):
undefined reference to `curl_easy_duphandle'
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl_c83_37c.o):
In function `_D3std3net4curl4Curl8shutdownMFZv':
std/net/curl.d:(.text._D3std3net4curl4Curl8shutdownMFZv+0x1a):
undefined reference to `curl_easy_cleanup'
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl_c85_14c.o):
In function
`_D3std3net4curl4Curl3setMFE3etc1c4curl10CurlOptionAxaZv':
std/net/curl.d:(.text._D3std3net4curl4Curl3setMFE3etc1c4curl10CurlOptionAxaZv+0x5d):
undefined reference to `curl_easy_setopt'
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl_c86_14c.o):
In function
`_D3std3net4curl4Curl3setMFE3etc1c4curl10CurlOptionlZv':
std/net/curl.d:(.text._D3std3net4curl4Curl3setMFE3etc1c4curl10CurlOptionlZv+0x2e):
undefined reference to `curl_easy_setopt'
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl_c87_14c.o):
In function
`_D3std3net4curl4Curl3setMFE3etc1c4curl10CurlOptionPvZv':
Re: Building website from git master, why does it checkout DMD v2.066.1 and die?
On 2015-04-19 18:20, Gary Willoughby wrote:
Here are the errors:
...
touch ../dub-0.9.23/.cloned
mkdir -p /tmp/.stable_dmd-2.067.0
TMPFILE=$(mktemp deleteme.) curl -fsSL
http://downloads.dlang.org/releases/2.x/2.067.0/dmd.2.067.0.linux.zip
${TMPFILE}.zip \
unzip -qd /tmp/.stable_dmd-2.067.0 ${TMPFILE}.zip rm
${TMPFILE}.zip
cd ../dub-0.9.23 DC=/tmp/.stable_dmd-2.067.0/dmd2/linux/bin64/dmd
./build.sh
Generating version file...
Running /tmp/.stable_dmd-2.067.0/dmd2/linux/bin64/dmd...
/media/Data/Projects/D/dmd/phobos/generated/linux/release/64/libphobos2.a(curl.o):
In function `_D3std3net4curl4HTTP21_sharedStaticCtor1542FZv':
std/net/curl.d:(.text._D3std3net4curl4HTTP21_sharedStaticCtor1542FZv+0xf):
undefined reference to `curl_version_info'
Do you have libcurl installed?
--
/Jacob Carlborg
Re: Today's programming challenge - How's your Range-Fu ?
On Sunday, 19 April 2015 at 19:58:28 UTC, ketmar wrote: On Sun, 19 Apr 2015 07:54:36 +, John Colvin wrote: it's not crazy, it's just broken in all possible ways: http://file.bestmx.net/ee/articles/uni_vs_code.pdf Ketmar Great link, and a really good arguement about the problems with Unicode. Quote from 'Instead of Conclusion' Yes. This is the root of Unicode misdesign. They mixed up two mutually exclusive approaches. They blended badly two different abstraction levels: the textual level which corresponds to a language idea and the graphical level which does not care of a language, yet cares of writing direction, subscripts, superscripts and so on. In other words we need two different Unicodes built on these two opposite principles, instead of the one built on an insane mix of controversial axioms. end quote. Perhaps Unicode needs to be rebuild from the ground up ?
[Issue 14427] Regression: navigation for phobos documentation has disappeared
https://issues.dlang.org/show_bug.cgi?id=14427 --- Comment #8 from Andrei Alexandrescu and...@erdani.com --- (In reply to Vladimir Panteleev from comment #7) The pinnacle of your idea is a GitHub bot that pastes diff links on each dlang.org pull request, BTW. Well it's diffs between built files, not sources. --
[Issue 14427] Regression: navigation for phobos documentation has disappeared
https://issues.dlang.org/show_bug.cgi?id=14427 --- Comment #9 from Vladimir Panteleev thecybersha...@gmail.com --- That's what I meant. --
Re: readText for large files on Windows.
On 20/04/2015 7:06 a.m., Kenny wrote: This function works fine for large text files like 100Mb or 1Gb but failed when I tried to read 6Gb file. This happens on Windows x64. The possible reason that it uses read(in char[], size_t) function and on windows it calls GetFileSize. This function returns file size as 32 bit value. If you need size for files larger then 4Gb then this function provides out parameter where you can pass reference to another 32 bit value. But in DMD 2.067 this function is called as auto size = trustedGetFileSize(h, null); thus we never get correct size for files larget then 4Gb. Is it a bug? It should probably be using GetFileSizeEx instead. https://msdn.microsoft.com/en-us/library/windows/desktop/aa364957(v=vs.85).aspx So yes, bug.
Re: Adding pointers to GC with destructers
On 04/19/2015 04:38 PM, Freddy wrote: C libraries have a pattern of HiddenType* getObj(); void freeObj(HiddenType*); Is there any way I can make the GC search for a HiddenType* and run freeObj when the pointer is not found. Not automatically. Check out addRange and addRoot: http://dlang.org/phobos/core_memory.html Ali
Re: druntime unit test failures on FreeBSD
On Sunday, April 19, 2015 08:18:55 Joakim via Digitalmars-d wrote: I dusted off the old FreeBSD VM I had lying around and tried it out. For me, it hangs in core.thread on FreeBSD 9.1 i386 from a couple years ago when I try to run the druntime unit tests with dmd/druntime HEAD. At least most of the time, I just tried it again and it returned and passed once, out of ten times. Lovely. That certainly begs the question as to what the autotester boxes are doing differently then, since they're not seeing the problem. It wouldn't surprise me in the least if they're runnig an older version of FreeBSD, but you're clearly running one that's far from up-to-date. :| LOL. Well, I just switched to FreeBSD from Linux so that I could take proper advantage of ZFS, so I may be stuck looking random problems that pop up on FreeBSD - though this is consistent enough that I'd expect to see it on the autotester, so I'm quite confused. - Jonathan M Davis
Re: Adding pointers to GC with destructers
On Sun, 19 Apr 2015 23:38:47 +, Freddy wrote: C libraries have a pattern of HiddenType* getObj(); void freeObj(HiddenType*); Is there any way I can make the GC search for a HiddenType* and run freeObj when the pointer is not found. wrap it in class/struct and run `freeObj()` in destructor. signature.asc Description: PGP signature
Re: Today's programming challenge - How's your Range-Fu ?
On Mon, 20 Apr 2015 01:27:36 +, Nick B wrote: Perhaps Unicode needs to be rebuild from the ground up ? alas, it's too late. now we'll live with that unicode crap for many years. signature.asc Description: PGP signature
[Issue 14467] arr.capacity sometimes erroneously returns 0
https://issues.dlang.org/show_bug.cgi?id=14467
--- Comment #1 from Ketmar Dark ket...@ketmar.no-ip.org ---
it looks right to me. consider this code:
void main () {
auto a0 = new int[10];
auto a1 = a0[5..$];
a1 ~= 42;
a0 ~= 667;
}
here if `a1.capacity` will not be 0, the last item of `a1` will become `667`,
as druntime will reuse memory for `a0`, and that memory is already used by
`a1`.
as there is no dataflow analysis, compiler can't tell if `arr` in your case is
the only ref to the array. so compiler conservatively sets slice capacity to
`0`, triggering copy-on-append behavior.
--
[Issue 14467] New: arr.capacity sometimes erroneously returns 0
https://issues.dlang.org/show_bug.cgi?id=14467
Issue ID: 14467
Summary: arr.capacity sometimes erroneously returns 0
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: regression
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: schvei...@yahoo.com
Works in 2.066.1, fails in 2.067:
void main()
{
auto arr = new int[10];
assert(arr.capacity == 15);
arr = arr[5..$];
assert(arr.capacity == 10);
}
I'll take a look at the code, see if I can figure out the fix.
--
Re: I need dmd2's Arm platform compile.
On Sunday, April 19, 2015 18:45:25 Brian via Digitalmars-d wrote: I need to use DMD compilation arm or arm64 version, don't know DMD now support for the arm. I think it is very important to the arm of a structure, such as rust/go is good enough to support the architecture. I hope we can improve in arm. dmd only supports x86 and x86_64, and I wouldn't expect that to change, given the backend that it uses and how much work it would be to add additional platforms. If you want support for other plaftorms, you're going to have to look at ldc or gdc. I know that work has been done to support ARM there, but I don't know what its current state is. - Jonathan M Davis
[Issue 14468] New: [Reg 2.068.0-devel] overload mismatch for template instance with typesafe variadic parameter
https://issues.dlang.org/show_bug.cgi?id=14468
Issue ID: 14468
Summary: [Reg 2.068.0-devel] overload mismatch for template
instance with typesafe variadic parameter
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
cat bug.d CODE
void foo(T)(T[]...)
{
}
void foo(bool flag, T)(T[]...)
{
}
void test()
{
foo!int();
}
CODE
dmd -c bug
bug.d(11): Error: template bug.foo cannot deduce function from argument types
!(int)(), candidates are:
bug.d(1):bug.foo(T)(T[]...)
bug.d(5):bug.foo(bool flag, T)(T[]...)
Apparently introduced by
https://github.com/D-Programming-Language/dmd/pull/4261.
--
64bit linking on Windows without Visual Studio
Hey all, While browsing the other day I stumbled across a linker called polink (part of the Pelles C suite). After only a few tries I got a working 64bit Hello World executable to be produced using it. The terms of service is incredibly permissive, and it looks like we can use it how ever we want (though this would need confirmation). I'm wondering if this could be a possible replacement for needing to install Visual Studio along side the D compiler. Thoughts?
Re: 64bit linking on Windows without Visual Studio
On Mon, 20 Apr 2015 04:05:19 +, Jeremiah DeHaan wrote: Hey all, While browsing the other day I stumbled across a linker called polink (part of the Pelles C suite). After only a few tries I got a working 64bit Hello World executable to be produced using it. The terms of service is incredibly permissive, and it looks like we can use it how ever we want (though this would need confirmation). I'm wondering if this could be a possible replacement for needing to install Visual Studio along side the D compiler. Thoughts? i think that even if it can't be distributed with DMD, it would be great to write about it in Wiki, so we can direct people there. signature.asc Description: PGP signature
[Issue 14467] arr.capacity sometimes erroneously returns 0
https://issues.dlang.org/show_bug.cgi?id=14467
Jonathan M Davis issues.dl...@jmdavisprog.com changed:
What|Removed |Added
CC||issues.dl...@jmdavisprog.co
||m
--- Comment #2 from Jonathan M Davis issues.dl...@jmdavisprog.com ---
(In reply to Ketmar Dark from comment #1)
it looks right to me. consider this code:
void main () {
auto a0 = new int[10];
auto a1 = a0[5..$];
a1 ~= 42;
a0 ~= 667;
}
here if `a1.capacity` will not be 0, the last item of `a1` will become
`667`, as druntime will reuse memory for `a0`, and that memory is already
used by `a1`.
as there is no dataflow analysis, compiler can't tell if `arr` in your case
is the only ref to the array. so compiler conservatively sets slice capacity
to `0`, triggering copy-on-append behavior.
It would be the runtime, not the compiler, since it would be done at runtime.
But regardless, your example involves appending to one of the slices, whereas
Steven's does not. As I understand it, the runtime knows what the farthest
point into the memory block is that a slice has referred to is - which in
Steven's example would be 10. It doesn't matter how many arrays refer to that
block of memory, until one of the expands into the free space at the end, the
farthest point used stays the same, and they should all have the capacity to
grow into that space. That should only change once one of the actually uses
some of that space - like in your example. Once that happens, the array which
refers to the farthest point in the block of memory has the remainder of the
block of memory as part of its capacity, whereas the others would not - their
capacity would have to be either their length or 0 - and then when one of them
is appended to, it would have to be reallocated.
But as I understand it, it doesn't matter if more than one array refers to to
the end of the used portion of the memory block. It only matters whether an
array refers to the last portion used. If it doesn't, then it has no capacity
to grow. If it does, then it does, even if other arrays refer to the same
memory. And whichever array grows into that memory is the one that gets it, and
the others will have to be reallocated if they are appended to.
capacity is a calculated property. The arrays themselves only have a ptr and
length property, and the runtime does not keep track of which slices refer to
which memory block. It only keeps track of stuff like the farthest that an
array has grown into it, and capacity is calculated by looking at the array
passed in to the capacity function and looking at the block that it refers to,
not by actually keeping track of the capacity of the array. That's part of why
appending can be expensive, but we're kind of stuck with that without making
the arrays themselves more complicated and doing stuff like making them
reference-counted, which has a different set of pros and cons, but definitely
would be harder to make work with having dynamic arrays being able to refer to
static arrays and malloced buffers and the like, which works just fine right
now.
--
[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed
https://issues.dlang.org/show_bug.cgi?id=14431 --- Comment #6 from Martin Nowak c...@dawg.eu --- That orange library is a really terrible example. Why would someone use single file compilation for object and header only to pack everything into a static library. If I do build everything at once (including headergen -Hfimport -op) this takes 400ms instead of 8.5s. There is still a slowdown from 400ms to 450ms comparing 2.066.1 and 2.067.0. Seems to be mostly cause by more allocations in the compiler. --
[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed
https://issues.dlang.org/show_bug.cgi?id=14431 --- Comment #7 from Martin Nowak c...@dawg.eu --- This slowdown comes from https://github.com/D-Programming-Language/dmd/pull/4384, which does instantiate additional templates in order to resolve link bugs. The problem is amplified by using single file compilation. --
[Issue 14467] arr.capacity sometimes erroneously returns 0
https://issues.dlang.org/show_bug.cgi?id=14467 --- Comment #4 from Ketmar Dark ket...@ketmar.no-ip.org --- but to rehabilitate myself a little i can tell you what was changed since 2.066. `GC.query` used to return block info regardless of the address passed, and now it works only if base address passed. with the following patch assert is ok again: diff --git a/src/rt/lifetime.d b/src/rt/lifetime.d index 23c611b..dde17af 100644 --- a/src/rt/lifetime.d +++ b/src/rt/lifetime.d @@ -719,7 +719,7 @@ body // step 1, get the block auto isshared = typeid(ti) is typeid(TypeInfo_Shared); auto bic = isshared ? null : __getBlkInfo((*p).ptr); -auto info = bic ? *bic : GC.query((*p).ptr); +auto info = bic ? *bic : GC.query(GC.addrOf((*p).ptr)); auto tinext = unqualify(ti.next); auto size = tinext.tsize; version (D_InlineAsm_X86) --
Re: 64bit linking on Windows without Visual Studio
On Monday, 20 April 2015 at 04:05:21 UTC, Jeremiah DeHaan wrote: Hey all, While browsing the other day I stumbled across a linker called polink (part of the Pelles C suite). After only a few tries I got a working 64bit Hello World executable to be produced using it. The terms of service is incredibly permissive, and it looks like we can use it how ever we want (though this would need confirmation). I'm wondering if this could be a possible replacement for needing to install Visual Studio along side the D compiler. Thoughts? There are three aspects of Visual Studio used for D's Win64 support: the Microsoft C compiler to compile a few C files in COFF64 format, the Microsoft COFF64 linker, and the Microsoft C library in COFF64 format. Replacing only one will not get you very far.
[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed
https://issues.dlang.org/show_bug.cgi?id=14431
--- Comment #5 from Martin Nowak c...@dawg.eu ---
(In reply to Martin Krejcirik from comment #4)
I'm not sure how relevant this is to the general compilation speed, but
anyway:
import std.regex;
auto RE_VARSET = regex(r(?!!\w+.*)!(\w+)\s*=\s*([\w!.-]+|`.+`| ~ `.*)[
\t]*`,i);
auto RE_CMD= regex(r!([A-Z_]+)\(([A-Za-z0-9_ .:;!,@{}/*-]*)\));
This spends most of it's time in CTFE interpretation.
I get a 5-10% speedup when compiling v2.067.0 on my machine vs. using the
released binary, most likely because of a newer gcc 4.9.2 vs. gcc 4.7.2 on the
debian build image.
--
Re: druntime unit test failures on FreeBSD
On Monday, 20 April 2015 at 03:21:10 UTC, Jonathan M Davis wrote: LOL. Well, I just switched to FreeBSD from Linux so that I could take proper advantage of ZFS, so I may be stuck looking random problems that pop up on FreeBSD - though this is consistent enough that I'd expect to see it on the autotester, so I'm quite confused. There was a random deadlock issue on FreeBSD a little while back, could be related to that: https://issues.dlang.org/show_bug.cgi?id=13416
Re: druntime unit test failures on FreeBSD
On Monday, April 20, 2015 04:36:35 Joakim via Digitalmars-d wrote: On Monday, 20 April 2015 at 03:21:10 UTC, Jonathan M Davis wrote: LOL. Well, I just switched to FreeBSD from Linux so that I could take proper advantage of ZFS, so I may be stuck looking random problems that pop up on FreeBSD - though this is consistent enough that I'd expect to see it on the autotester, so I'm quite confused. There was a random deadlock issue on FreeBSD a little while back, could be related to that: https://issues.dlang.org/show_bug.cgi?id=13416 Hmmm. Maybe it's core-related. I have 6 cores with hyperthreading on my machine - so, effectively 12 - which is more than the autotester has according to that bug report, though if you're running yours in VM, I would assume that it has fewer cores, and you're still seeing the problem. - Jonathan M Davis
[Issue 14467] arr.capacity sometimes erroneously returns 0
https://issues.dlang.org/show_bug.cgi?id=14467 --- Comment #3 from Ketmar Dark ket...@ketmar.no-ip.org --- ah, i see. somehow i was thinking that `capacity` is stored in the array struct. that's strange, 'cause i know that array struct consists of `ptr` and `length` only. thank you, and sorry for the noise. --
Re: GtkD 3.1.0 released, GTK+ with D.
On 04/19/2015 02:07 PM, Steve Teale wrote: On Thursday, 26 March 2015 at 22:41:01 UTC, Mike Wey wrote: GtkD is a D binding and OO wrapper of Gtk+ and is released on the LGPL license. Shortly after the last release, GtkD has been updated for GTK+ 3.16. GtkD 3.1.0 is now available on gtkd.org: http://gtkd.org/download.html Mike, Broadly speaking, how much work is involved in converting an app using GtkD 2.4? Thanks Steve Judging form the demos, the needed changes are minimal. -- Mike Wey
