Re: dmd codegen improvements
On 29-Aug-2015 01:05, Walter Bright wrote: On 8/28/2015 9:49 AM, Dmitry Olshansky wrote: Have you ever written a backend? What is the evidance? Consider that x86 x64 bit support was done in about one year and a half by Walter single-handedly that is without freezing the other activity on DMD, of course. Aside from emitting different sequences of instructions most IR-based optimizations stay the same. Doing an ARM back end wouldn't be that hard. It's much less complex than x86. Most of the work would be deleting about half of the x86 code generator :-) Yeah, I guess the things to provision for is register count + some peculiarities of allowed moves/stores etc. Doing the first 64-bit codegen was a difficult task, compared to doing another 32-bit one. -- Dmitry Olshansky
Re: Moving forward with work on the D language and foundation
On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: Hello everyone, Following an increasing desire to focus on working on the D language and foundation, I have recently made the difficult decision to part ways with Facebook, my employer of five years and nine months. I understand very well the difficulty of decisions of such kinds, that's why you have all my respect.
How to use Registry Windows ?
Hello,
I can't seem to use Registry, I tried to many attraction ways but
I have every time an error Value cannot be set.
Exemple code :
module main;
import std.stdio;
import std.windows.registry;
void main(string[] args)
{
version(Windows)
{
Key registryKey = Registry.localMachine()
.createKey(Software)
.createKey(Microsoft)
.createKey(Windows)
.createKey(CurrentVersion)
.createKey(Run);
registryKey.setValue(key, value);
}
}
[Issue 14929] [REG2.067] ICE: Assertion failure: 'ez-exp ez-exp-op == TOKconstruct' on line 302 in file 'escape.c'
https://issues.dlang.org/show_bug.cgi?id=14929 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/3e3fdfe12e49815f3a78659266b2a5aad737ec79 fix Issue 14929 - ICE: Assertion failure: 'ez-exp ez-exp-op == TOKconstruct' on line 302 in file 'escape.c' https://github.com/D-Programming-Language/dmd/commit/45c115bccd2e3fe64e607eb2cf40786fe1dc4412 Merge pull request #4950 from 9rnsr/fix14929 --
Re: dmd codegen improvements
On 8/29/2015 12:30 AM, Dmitry Olshansky wrote: Doing the first 64-bit codegen was a difficult task, compared to doing another 32-bit one. The main problem with the 64 bit x86 was the endlessly confusing non-orthogonality of it. The Win64 port was bad because of the bizarro calling convention they invented.
[Issue 13889] mscoff32 libs not available
https://issues.dlang.org/show_bug.cgi?id=13889 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13889] mscoff32 libs not available
https://issues.dlang.org/show_bug.cgi?id=13889 --- Comment #7 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/D-Programming-Language/installer https://github.com/D-Programming-Language/installer/commit/95ace32ecf6ef403b376eb9d7f11612110beea47 fix Issue 13889 - mscoff32 libs not available https://github.com/D-Programming-Language/installer/commit/d89c734cc27dafb982455038fd17dac6493b8d38 Merge pull request #142 from MartinNowak/m32mscoff fix Issue 13889 - mscoff32 libs not available --
Re: dmd codegen improvements
On 29 Aug 2015 12:10 am, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/28/2015 9:49 AM, Dmitry Olshansky wrote: Have you ever written a backend? What is the evidance? Consider that x86 x64 bit support was done in about one year and a half by Walter single-handedly that is without freezing the other activity on DMD, of course. Aside from emitting different sequences of instructions most IR-based optimizations stay the same. Doing an ARM back end wouldn't be that hard. It's much less complex than x86. Most of the work would be deleting about half of the x86 code generator :-) Don't forget you have about a 100_000_000 distinct ABIs, with about 100_000_000 distinct CPUs/Boards to target. ;-)
[Issue 14973] [REG2.068] compiler inference of contexts for nested map seems broken
https://issues.dlang.org/show_bug.cgi?id=14973 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e891688d80a398be2fc41366184cd26e8229406e fix Issue 14973 - compiler inference of contexts for nested map seems broken https://github.com/D-Programming-Language/dmd/commit/955eb73f73a31ef52cd3e619fc3b8b1b8bb0f19e Merge pull request #4971 from 9rnsr/fix14973 --
[Issue 14923] [REG2.067] ICE: Assertion failed: (tret-ty != Tvoid), function semantic3, file func.c, line 1736.
https://issues.dlang.org/show_bug.cgi?id=14923 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/bdd7d5bf7b5dd148ab0dd0087b2754b0b6867ce7 fix Issue 14923 - ICE: Assertion failed: (tret-ty != Tvoid), function semantic3, file func.c, line 1736. https://github.com/D-Programming-Language/dmd/commit/d780e3114333c17056e78f982012f37ca141e958 Merge pull request #4949 from 9rnsr/fix14923 --
[Issue 14951] Win64: Invalid C++ mangling for __gshared pointer variables
https://issues.dlang.org/show_bug.cgi?id=14951 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/d16e409431c6a73af8f4a92f512de1976f615b51 Merge pull request #4935 from rainers/issue14951 --
Re: dmd codegen improvements
On 8/28/2015 9:19 PM, deadalnix wrote: I bet none of you can implement SROA in DMD. I know it's supposed to be advanced technology, but it's pretty simple. Just look for aggregate instances which are only accessed on register boundaries, and don't have the address taken. Then slice them up into separate register-sized variables, and re-run the optimizer. Voila!
Re: How to use Registry Windows ?
On 29/08/15 9:14 PM, medhi558 wrote:
Hello,
I can't seem to use Registry, I tried to many attraction ways but I have
every time an error Value cannot be set.
Exemple code :
module main;
import std.stdio;
import std.windows.registry;
void main(string[] args)
{
version(Windows)
{
Key registryKey = Registry.localMachine()
.createKey(Software)
.createKey(Microsoft)
.createKey(Windows)
.createKey(CurrentVersion)
.createKey(Run);
registryKey.setValue(key, value);
}
}
Humm, try:
auto regKey = Registry.localMachine()
.getKey(Software)
.getKey(Microsoft)
.getKey(Windows)
.getKey(CurrentVersion)
.getKey(Run);
regKey.setValue(...);
Re: How to use Registry Windows ?
On Saturday, 29 August 2015 at 09:35:47 UTC, medhi558 wrote: It doesn't always work the same error. Is your program running with administrator rights? Unprivileged programs may not write to HKEY_LOCAL_MACHINE by default.
How to use Registry Windows ?
It doesn't always work the same error.
Re: D-Day for DMD is today!
On 29 Aug 2015 5:50 am, Daniel Murphy via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Luís Marques wrote in message news:ckyiqzpchfahzfjmm...@forum.dlang.org... What is the relation between the .h files that were left intact, and the backend, GDC, and LDC? When the backend is converted to D, will the DMD source drop the C++ header files, or will (some?) of those be left behind because GDC and LDC will always use some C++ interfaces in their glue code? The frontend header files will need to stay intact, and GDC/LDC will continue to use them. All the backend header files can be deleted once the backend has been converted. I'm planning to generate the C++ headers from the D source rather than maintain them by hand. You could use UDAs for that!
Re: dmd codegen improvements
On 8/28/2015 8:49 PM, jmh530 wrote: You should feel proud. There's something to be said for going forward regardless of what others say. I feel like I would have been fired years ago if I just disregarded what everyone said and did what I thought was right. If management won't back you up, you're working for the wrong outfit anyway.
Re: dmd codegen improvements
On Tuesday, 18 August 2015 at 10:45:49 UTC, Walter Bright wrote: I'm interested in ways to reduce that gap. There are 3 broad kinds of optimizations that compilers do: 1. source translations like rewriting x*2 into x1, and function inlining So if you're comparing code generated by dmd/gdc/ldc, and notice something that dmd could do better at (1, 2 or 3), please let me know. One low-hanging fruit coming right up: https://issues.dlang.org/show_bug.cgi?id=14840
[Issue 14621] [REG2.066] ICE: Assertion failure: 'global.gaggedErrors || global.errors' on line 752 in file 'statement.c'
https://issues.dlang.org/show_bug.cgi?id=14621 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/6fcef51018ab366fb8fd7ec011597e08bb65f9ec fix Issue 14621 - ICE: Assertion failure: 'global.gaggedErrors || global.errors' on line 752 in file 'statement.c' https://github.com/D-Programming-Language/dmd/commit/d99699301eb0f5d46b4f9240236ca7c1694bb39b Merge pull request #4948 from 9rnsr/fix14621 --
[Issue 14624] The array operator overloading fallback is not correct
https://issues.dlang.org/show_bug.cgi?id=14624 --- Comment #6 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/bfb7f8d2a116578a57be29d87da3db010b565bb1 fix Issue 14624 - The array operator overloading fallback is not correct https://github.com/D-Programming-Language/dmd/commit/d99699301eb0f5d46b4f9240236ca7c1694bb39b Merge pull request #4948 from 9rnsr/fix14621 --
[Issue 14625] opIndex() doesn't work on foreach container iteration
https://issues.dlang.org/show_bug.cgi?id=14625 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/248805a4ba23278622f6831a172779f3012b1b03 fix Issue 14625 - opIndex() doesn't work on foreach container iteration https://github.com/D-Programming-Language/dmd/commit/d99699301eb0f5d46b4f9240236ca7c1694bb39b Merge pull request #4948 from 9rnsr/fix14621 --
[Issue 14621] [REG2.066] ICE: Assertion failure: 'global.gaggedErrors || global.errors' on line 752 in file 'statement.c'
https://issues.dlang.org/show_bug.cgi?id=14621 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14621] [REG2.066] ICE: Assertion failure: 'global.gaggedErrors || global.errors' on line 752 in file 'statement.c'
https://issues.dlang.org/show_bug.cgi?id=14621 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/6fcef51018ab366fb8fd7ec011597e08bb65f9ec fix Issue 14621 - ICE: Assertion failure: 'global.gaggedErrors || global.errors' on line 752 in file 'statement.c' https://github.com/D-Programming-Language/dmd/commit/d99699301eb0f5d46b4f9240236ca7c1694bb39b Merge pull request #4948 from 9rnsr/fix14621 Issue 14621, 14624, 14625 - Fix bugs in array operator overloading semantics --
[Issue 14624] The array operator overloading fallback is not correct
https://issues.dlang.org/show_bug.cgi?id=14624 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/bfb7f8d2a116578a57be29d87da3db010b565bb1 fix Issue 14624 - The array operator overloading fallback is not correct https://github.com/D-Programming-Language/dmd/commit/d99699301eb0f5d46b4f9240236ca7c1694bb39b Merge pull request #4948 from 9rnsr/fix14621 Issue 14621, 14624, 14625 - Fix bugs in array operator overloading semantics --
[Issue 14624] The array operator overloading fallback is not correct
https://issues.dlang.org/show_bug.cgi?id=14624 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14625] opIndex() doesn't work on foreach container iteration
https://issues.dlang.org/show_bug.cgi?id=14625 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/248805a4ba23278622f6831a172779f3012b1b03 fix Issue 14625 - opIndex() doesn't work on foreach container iteration https://github.com/D-Programming-Language/dmd/commit/d99699301eb0f5d46b4f9240236ca7c1694bb39b Merge pull request #4948 from 9rnsr/fix14621 Issue 14621, 14624, 14625 - Fix bugs in array operator overloading semantics --
Re: dmd codegen improvements
On Friday, 28 August 2015 at 21:59:57 UTC, Walter Bright wrote: On 8/28/2015 4:18 AM, Temtaime wrote: Are you sure that ONE Walter can achieve what they done ? People told me I couldn't write a C compiler, then told me I couldn't write a C++ compiler. I'm still the only person who has ever implemented a complete C++ compiler (C++98). Then they all (100%) laughed at me for starting D, saying nobody would ever use it. My whole career is built on stepping over people who told me I couldn't do anything and wouldn't amount to anything. LLVM is a fine compiler, but there's nothing magical about it. Besides, we have a secret productivity enhancing weapon that LLVM doesn't have - D! Now, if I can only tear myself away from the internet for a while... I really like your attitude! That's, IMHO, one of the strongest selling point for D itself! --- Paolo
Re: D-Day for DMD is today!
Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote in message news:mailman.640.1440835567.13986.digitalmars-d-annou...@puremagic.com... I'm planning to generate the C++ headers from the D source rather than maintain them by hand. You could use UDAs for that! How?
Re: D-Day for DMD is today!
Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote in message news:mailman.647.1440844869.13986.digitalmars-d-annou...@puremagic.com... Just an idea to selectively @tag any classes or functions you want to export to C++, then let the conversion tool do the rest. This is as opposed to going back to some sort of magicport.json format maintained outside the normal sources. I'm just planning to implement this in dmd and have it dump out all extern(C++) declarations. (and structs and constants)
Benchmarking suite
Since issue 13487 [0] seems to rot away, I started something on my own. Made a benchmark script and inserted C/C++/D programs for comparison. However, various programs are broken, as you see in the example report [1]. The D code is at least 7 years old. I only fixed compile errors. The C/C++ programs were selected quite randomly. It should be easy to checkout the repo [2] and run the benchmarks yourself as long as you run on Linux: git clone g...@github.com:qznc/d-shootout.git cd d-shootout ./benchmark.d --quickly xdg-open index.html Maybe somebody has already fixed or improved benchmark programs? [0] https://issues.dlang.org/show_bug.cgi?id=13487 [1] https://qznc.github.io/d-shootout/ [2] https://github.com/qznc/d-shootout
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 13:14:26 UTC, ponce wrote:
This makes GC-called destructors mostly useless for non-memory
resource release. IIRC Andrei suggested once that destructors
shouldn't be called at all by the GC, something that I agree
with.
As such, some of us started providing a
release()/dispose()/close() method, and have the destructor
call it to support both scoped ownership and manual release.
I'm not sure it is the best way to do things... In Python for
example we have a GC that calls the default destructor (__del__
method). As a consequence, if you need some resource to be freed
you have to do it explicitely by writting a close()/whatever()
method. But nobody's linking the destructor to it because of the
separation of concerns principle: we release what has to be
released and only that: freeing the object is the realm of the
GC. This mixed style is something I have yet to encounter in D
where it could be way more powerful than in Python: free what you
must, not what you can.
But that introduce accidentally correct design when the
destructor is called by GC, and avoids a leak. This is arguably
worse than the initial problem.
I'd like to see a concrete example of this, it seems I'm missing
something...
void ensureNotInGC(string resourceName) nothrow
{
debug
{
import core.exception;
try
{
import core.memory;
void* p = GC.malloc(1); // not ideal since it
allocates
return;
}
catch(InvalidMemoryOperationError e)
{
import core.stdc.stdio;
fprintf(stderr, Error: clean-up of %s incorrectly
depends on destructors called by the GC.\n, resourceName.ptr);
assert(false); // crash
}
}
}
--
Looks ugly? Yes, but it makes the GC acts as a cheap leak
detector, giving accurate messages for still opened resources.
As I said before, I'm not sure preventing the GC from doing its
collection job is a good idea, but I find the concept of having
such a leak detector really interesting!
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 13:58:07 UTC, ponce wrote: Example 1: You forget to release Resource A. The GC happen to call A destructor that releases it. But GC destructors are not guaranteed to happen. See http://dlang.org/class.html (The garbage collector is not guaranteed to run the destructor for all unreferenced objects). This, ok, it is the common GC flaw that it shouldn't memleak but might. To me it isn't either an accidentally correct design nor an avoided leak but ok. If something _has_ to be freed then it should be done explicitely either way hence crashing the GC for that particular ressource, I follow you here. Example 2: Resource A depends on Resource B. You forget to release either. The GC happens to call A and B destructors in the right order, by chance. A new D release changes this order later. Here comes the accidentally correct design. Ok, I'm with you on that one. I think however that this should really be limited on ressources that _must_ be freed in time. It shouldn't become a standard way to deal with the GC.
Re: How to use Registry Windows ?
On Saturday, 29 August 2015 at 09:44:06 UTC, medhi558 wrote:
I just tried with administrator rights, but it doesn't work.
You need to use a REGSAM value (e.g. KEY_ALL_ACCESS) to open the
key with write access:
/// test.d ///
import std.windows.registry;
void main()
{
auto regKey = Registry.currentUser()
.getKey(Software)
.getKey(Microsoft)
.getKey(Windows)
.getKey(CurrentVersion)
.getKey(Run, REGSAM.KEY_ALL_ACCESS);
regKey.setValue(Calculator, calc.exe);
}
//
[Issue 13780] Empty ParameterIdentifierTuple for function literal
https://issues.dlang.org/show_bug.cgi?id=13780
Daniel wyr...@gmx.net changed:
What|Removed |Added
CC||wyr...@gmx.net
Hardware|x86_64 |All
OS|Windows |All
--- Comment #1 from Daniel wyr...@gmx.net ---
I was just hit by this bug as well.
It's possible to workaround with string parsing, but not pretty.
static if(is(FunctionTypeOf!T P == __parameters))
{
enum decl = P.stringof[1..$-1]; // hack, strip parenthesis
// parse decl
}
For a proper fix, __traits(identifier, ...) needs to work for function
literals.
--
Re: DCD v0.7.0-rc1
On Thursday, 27 August 2015 at 22:18:25 UTC, Brian Schott wrote: On Thursday, 27 August 2015 at 10:13:38 UTC, BBasile wrote: I've seen some activity on your allocator fork and on the DCD submodules yesterday, is it ok to release the DCD binaries based on the current state ? Is the problem fixed ? Or would you recommend more to distribute latest stable 0.6 (for example just after A.Neves fixed a regression) ? No. I'll tag 0.7.0 when it's ready. There are still a few bugs. (Just for fun, run a build from master in Valgrind) I think I've nailed down all the bugs in the allocators and the memory leaks in my own code. I just need to fix https://github.com/Hackerpilot/DCD/issues/251 and 0.7.0 will be done.
[Issue 14977] New: Struct initializer doesn't work inside AA initializer
https://issues.dlang.org/show_bug.cgi?id=14977
Issue ID: 14977
Summary: Struct initializer doesn't work inside AA initializer
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: jappleg...@gmail.com
struct Foo {
int a;
}
void main() {
// compiles
Foo[] arr = [
{a: 1},
{a: 2}
];
// compiles
Foo[int] aa1 = [
1: Foo(),
2: Foo()
];
// Error: not an associative array initializer
Foo[int] aa2 = [
1: {a: 1},
2: {a: 2}
];
}
--
GC-proof resource classes
As a library writer I've struggled a bit with to provide easy
resource clean-up despite using class objects.
Is there reasons to use class objects that hold resources in the
first place vs Unique!T or RefCounted!T structs?
I think yes:
- classes have reference semantics without naming or runtime
overhead: you read Resource and not RefCounted!Resource
- no need to disable the postblit or have a valid .init is
another thing
That's about it from the top of my head and it may not be good
reasons!
As you probably know GC-called destructors enjoy a variety of
limitations:
- can't allocate,
- can't access members,
- aren't guaranteed to happen at all.
This makes GC-called destructors mostly useless for non-memory
resource release. IIRC Andrei suggested once that destructors
shouldn't be called at all by the GC, something that I agree with.
As such, some of us started providing a
release()/dispose()/close() method, and have the destructor call
it to support both scoped ownership and manual release.
But that introduce accidentally correct design when the
destructor is called by GC, and avoids a leak. This is arguably
worse than the initial problem.
It turns out separating calls of ~this() that are called by the
GC from those that are called for a deterministic reason is
enough, and support all cases I can think of:
Unique!T/scoped!T/.destroy/RefCounted!T/manual/GC-called
It works like this:
class MyResource
{
void* handle;
this()
{
handle = create_handle();
}
~this()
{
if (handle != null) // must support repeated calls for
the case (called by .destroy + called by GC later)
{
ensureNotInGC(MyResource);
free_handle(handle);
}
}
}
ensureNotInGC() is implemented like this:
void ensureNotInGC(string resourceName) nothrow
{
debug
{
import core.exception;
try
{
import core.memory;
void* p = GC.malloc(1); // not ideal since it
allocates
return;
}
catch(InvalidMemoryOperationError e)
{
import core.stdc.stdio;
fprintf(stderr, Error: clean-up of %s incorrectly
depends on destructors called by the GC.\n, resourceName.ptr);
assert(false); // crash
}
}
}
--
Looks ugly? Yes, but it makes the GC acts as a cheap leak
detector, giving accurate messages for still opened resources.
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 13:43:33 UTC, cym13 wrote: But that introduce accidentally correct design when the destructor is called by GC, and avoids a leak. This is arguably worse than the initial problem. I'd like to see a concrete example of this, it seems I'm missing something... Example 1: You forget to release Resource A. The GC happen to call A destructor that releases it. But GC destructors are not guaranteed to happen. See http://dlang.org/class.html (The garbage collector is not guaranteed to run the destructor for all unreferenced objects). Example 2: Resource A depends on Resource B. You forget to release either. The GC happens to call A and B destructors in the right order, by chance. A new D release changes this order later.
Re: What is the D way to map a binary file to a structure?
29.08.2015 15:56, cym13 пишет:
Hi,
Let's say I have a simple binary file whose structure is well-known.
Here is
an example which stores points:
struct Point {
long x;
long y;
long z;
}
struct BinFile {
uintmagicNumber; // Some identifier
ulong pointsNumber;
Point[] points; // Array of pointsNumber points.
}
What is the best way to read some file and fill a structure with it? Would
reading the file into a void[] and then casting it to the struct work with
things like internal struct padding?
Try, for example, MessagePack https://github.com/msgpack/msgpack-d.git
Re: Programming in D – Tutorial and Reference
On Friday, 28 August 2015 at 22:42:00 UTC, sigod wrote: Actual link: https://news.ycombinator.com/item?id=10136882 I hope I didn't overstep any boundaries with the inevitable Rust discussion.
[Issue 13792] Segfault with a pointer of opaque enum type
https://issues.dlang.org/show_bug.cgi?id=13792 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13792] Segfault with a pointer of opaque enum type
https://issues.dlang.org/show_bug.cgi?id=13792 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/758a273ddae7a412e01e2414b1fc14219c4e5a2f fix Issue 13792 - Segfault with a pointer of opaque enum type https://github.com/D-Programming-Language/dmd/commit/e51b3979f9d5068cc1cf249c97b4aa2e97dd8eea Merge pull request #4847 from 9rnsr/fix13792 Issue 13792 - Segfault with a pointer of opaque enum type --
[Issue 14976] New: object file output is unstable/different
https://issues.dlang.org/show_bug.cgi?id=14976 Issue ID: 14976 Summary: object file output is unstable/different Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: c...@dawg.eu The order in which undefined symbols are emitted depend on the allocated address of symbols (which in turn change with ASLR). This is problematic for testing purposes but also prevents from caching linker steps. https://github.com/D-Programming-Language/dmd/blob/20771f89a16d9ab663b2964db8d49706cfa0e1dd/src/backend/cgen.c#L501 A solution would be to use a string table instead of AArray. --
Re: dmd codegen improvements
You misunderstood me. It can be definitely done. The question is about rationality and quality. Okay, you've done a C++ compiler. Nobody uses that compiler in real projects. It cannot even compile curl or another large project. You done x86 and x64 backends and plans to make an ARM one. Okee, but in benchmarks it will be always behind gcc/llvm, get over it. That's a reality.
Re: Benchmarking suite
On 29-Aug-2015 15:05, qznc wrote: Since issue 13487 [0] seems to rot away, I started something on my own. Made a benchmark script and inserted C/C++/D programs for comparison. However, various programs are broken, as you see in the example report [1]. The D code is at least 7 years old. I only fixed compile errors. The C/C++ programs were selected quite randomly. It should be easy to checkout the repo [2] and run the benchmarks yourself as long as you run on Linux: git clone g...@github.com:qznc/d-shootout.git cd d-shootout ./benchmark.d --quickly xdg-open index.html Maybe somebody has already fixed or improved benchmark programs? Well, here is the regex-dna one with 3 versions including C-T regex: https://github.com/DmitryOlshansky/FReD/blob/master/bench/regex-dna/d_dna.d Could be trivially parallelized with std.parallelism. -- Dmitry Olshansky
Re: DCD v0.7.0-rc1
On Saturday, 29 August 2015 at 10:38:39 UTC, Brian Schott wrote: On Thursday, 27 August 2015 at 22:18:25 UTC, Brian Schott wrote: On Thursday, 27 August 2015 at 10:13:38 UTC, BBasile wrote: I've seen some activity on your allocator fork and on the DCD submodules yesterday, is it ok to release the DCD binaries based on the current state ? Is the problem fixed ? Or would you recommend more to distribute latest stable 0.6 (for example just after A.Neves fixed a regression) ? No. I'll tag 0.7.0 when it's ready. There are still a few bugs. (Just for fun, run a build from master in Valgrind) I think I've nailed down all the bugs in the allocators and the memory leaks in my own code. I just need to fix https://github.com/Hackerpilot/DCD/issues/251 and 0.7.0 will be done. When do you plain to implement UFCS?
Re: D-Day for DMD is today!
On 29 August 2015 at 12:25, Daniel Murphy via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote in message news:mailman.640.1440835567.13986.digitalmars-d-annou...@puremagic.com... I'm planning to generate the C++ headers from the D source rather than maintain them by hand. You could use UDAs for that! How? Just an idea to selectively @tag any classes or functions you want to export to C++, then let the conversion tool do the rest. This is as opposed to going back to some sort of magicport.json format maintained outside the normal sources.
Re: dmd codegen improvements
On Saturday, 29 August 2015 at 12:59:59 UTC, Adam D. Ruppe wrote: I'm happy with the codegen the way it is, it is good enough for me, but let's not make mountains out of hills. But the fact is that many people are not. Even the core language team, who doesn't want their compiler to get 30% slower on the next release. — David
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 14:00:59 UTC, ponce wrote: On Saturday, 29 August 2015 at 13:43:33 UTC, cym13 wrote: But nobody's linking the destructor to it because of the separation of concerns principle: we release what has to be released and only that: freeing the object is the realm of the GC. I see what you mean, but Unique!T, RefCounted!T and scoped!T call the destructor, not the release() function you just defined. So separating concerns break those. Yes, and I think it is kind of cumbersome actually. Being able to pass a method to scoped!T for example would be really great (with the destructor as default of course).
Re: How to use Registry Windows ?
Thank you it works.
Re: dmd codegen improvements
On Saturday, 29 August 2015 at 12:38:45 UTC, Temtaime wrote: Okay, you've done a C++ compiler. Nobody uses that compiler in real projects. For about a decade, dmc was outcompeting the efforts of big companies in features, compile speed, code optimization, AND stability. Sure, it has fallen behind now, but only because Walter sat down for 15 years so they could catch up (time he used to get streets ahead by creating this thing called 'Mars', which again the big guys are trying to catch up to). I'm happy with the codegen the way it is, it is good enough for me, but let's not make mountains out of hills.
What is the D way to map a binary file to a structure?
Hi,
Let's say I have a simple binary file whose structure is
well-known. Here is
an example which stores points:
struct Point {
long x;
long y;
long z;
}
struct BinFile {
uintmagicNumber; // Some identifier
ulong pointsNumber;
Point[] points; // Array of pointsNumber points.
}
What is the best way to read some file and fill a structure with
it? Would
reading the file into a void[] and then casting it to the struct
work with
things like internal struct padding?
Re: dmd codegen improvements
On Saturday, 29 August 2015 at 12:59:59 UTC, Adam D. Ruppe wrote: On Saturday, 29 August 2015 at 12:38:45 UTC, Temtaime wrote: Okay, you've done a C++ compiler. Nobody uses that compiler in real projects. For about a decade, dmc was outcompeting the efforts of big companies in features, compile speed, code optimization, AND stability. Sure, it has fallen behind now, but only because Walter sat down for 15 years so they could catch up (time he used to get streets ahead by creating this thing called 'Mars', which again the big guys are trying to catch up to). I'm happy with the codegen the way it is, it is good enough for me, but let's not make mountains out of hills. I'm writing a 3D engine in D. There's many, many of math. In my benchmarks when it's compiled with DMD there's ~100 fps and with LDC fps raises to ~500. LDC vectorizes all operations with matrix, inlines, etc. If it's good to you, it's not so for others. Quality of codegen is not only performance, but also how many battery apps drain on portables.
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 13:43:33 UTC, cym13 wrote: But nobody's linking the destructor to it because of the separation of concerns principle: we release what has to be released and only that: freeing the object is the realm of the GC. I see what you mean, but Unique!T, RefCounted!T and scoped!T call the destructor, not the release() function you just defined. So separating concerns break those.
Re: What is the D way to map a binary file to a structure?
On Saturday, 29 August 2015 at 13:56:10 UTC, drug wrote: Try, for example, MessagePack https://github.com/msgpack/msgpack-d.git Thanks, but it isn't answering the question at all. I'm not looking for a serialization method, I'm looking for the best way to read a binary file.
Re: GC-proof resource classes
On 08/29/2015 04:20 PM, cym13 wrote: On Saturday, 29 August 2015 at 14:17:10 UTC, rsw0x wrote: On Saturday, 29 August 2015 at 13:14:26 UTC, ponce wrote: ... All of this could be fixed by not letting the GC call destructors. It's a bad, error-prone design to begin with and I guarantee any semi-large D program is probably abusing undefined behavior due to it. After reading all that, I too am convinced that the GC shouldn't call the destructor. But then classes with destructors shouldn't be allowed to be allocated on the GC heap in the first place, which is a PITA as well. (Note that classes/arrays can have destructors because some component structs have them; structs generally assume that their destructors will be called.)
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 14:32:27 UTC, Timon Gehr wrote: On 08/29/2015 04:20 PM, cym13 wrote: On Saturday, 29 August 2015 at 14:17:10 UTC, rsw0x wrote: On Saturday, 29 August 2015 at 13:14:26 UTC, ponce wrote: ... All of this could be fixed by not letting the GC call destructors. It's a bad, error-prone design to begin with and I guarantee any semi-large D program is probably abusing undefined behavior due to it. After reading all that, I too am convinced that the GC shouldn't call the destructor. But then classes with destructors shouldn't be allowed to be allocated on the GC heap in the first place, which is a PITA as well. (Note that classes/arrays can have destructors because some component structs have them; structs generally assume that their destructors will be called.) make classes with destructors(and structs allocated via new) have RC semantics.
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 14:17:10 UTC, rsw0x wrote: All of this could be fixed by not letting the GC call destructors. It's a bad, error-prone design to begin with and I guarantee any semi-large D program is probably abusing undefined behavior due to it. Indeed.
Re: What is the D way to map a binary file to a structure?
On Saturday, 29 August 2015 at 14:52:51 UTC, drug wrote: 29.08.2015 17:17, cym13 пишет: On Saturday, 29 August 2015 at 13:56:10 UTC, drug wrote: Try, for example, MessagePack https://github.com/msgpack/msgpack-d.git Thanks, but it isn't answering the question at all. I'm not looking for a serialization method, I'm looking for the best way to read a binary file. It depends on what is the best for you. But using MessagePack you can easily read the file and fill a structure with it. No, because messagepack is one format of binary file. That isn't going to be of any help for any other binary file format. It is not a way to read binary files. It is a serialization format.
Re: Class info on interfaces
On 2015-08-28 22:40, rumbu wrote:
The linkage check it's good as long you don't have an abomination like
this:
extern(C++) interface CPPInterface
{
extern(D) void foo();
}
Good point.
Anyway, the problem is the availability of such function. If the
interface doesn't contain any function, there is no way to detect the
type, except for COM Interfaces which are clearly implementing IUnknown.
But deriving a new interface and defining a sentinel function, it works:
import std.stdio;
import std.traits;
import core.sys.windows.com;
interface NativeInterface {}
interface COMInterface : IUnknown {}
extern(C++) interface CPPInterface {}
enum InterfaceKind { native, windows, cpp }
template interfaceKind(I) if (is(I == interface))
{
interface J : I { void __foo__(); }
static if (functionLinkage!(J.__foo__) == D)
enum interfaceKind = InterfaceKind.native;
else static if (functionLinkage!(J.__foo__) == Windows)
enum interfaceKind = InterfaceKind.windows;
else static if (functionLinkage!(J.__foo__) == C++)
enum interfaceKind = InterfaceKind.cpp;
else static assert(false, Unknown interface kind.);
}
int main(string[] argv)
{
static assert(interfaceKind!NativeInterface == InterfaceKind.native);
static assert(interfaceKind!COMInterface == InterfaceKind.windows);
static assert(interfaceKind!CPPInterface == InterfaceKind.cpp);
return 0;
}
That looks like a pretty good idea, thanks. I'm wondering if it's worth
implementing a trait for this in the compiler.
--
/Jacob Carlborg
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 14:32:27 UTC, Timon Gehr wrote: But then classes with destructors shouldn't be allowed to be allocated on the GC heap in the first place, which is a PITA as well. (Note that classes/arrays can have destructors because some component structs have them; structs generally assume that their destructors will be called.) I don't quite follow the reasonning here. If GC doesn't call the destructor then this same destructor is no more than a normal method (with restrictions... would those still stand?) that is the default destruction method to be called by things like scoped!T or destroy if explicit destruction is needed. I think there should be a separation of concerns that isn't possible right now. Freeing ressources and freeing memory isn't the same thing and they should be decoupled. I think a destructor is there to free ressources, and the GC is there to free memory. If the GC doesn't call the destructor then why should having a destructor have anything to do with the GC? Or do you fear for classes whose memory would be freed before freeing its ressources? That could be a problem... In that case I think the best option would be to allow them to be allocated by the GC but GC-ing it if the destructor hasn't been called should spawn an error (or something like that, haven't taken the time to think through it). Or maybe it shouldn't be marked as garbage if the destructor hasn't been called. I think of it as a simple switch hasDestructorBeenCalled that would be set to true if no destructor exists or if it has been called, and false otherwise, and would prevent GC-ing (or crash... I don't know what's best) of the object if false. That way simple classes stay simple, complex classes can live on the heap happily without fearing collection while being able to reliably free ressources.
Re: D-Day for DMD is today!
Jacob Carlborg wrote in message news:mrsigg$1574$1...@digitalmars.com... I'm pretty sure we already have a tool that generates C/C++ headers for D modules. Adam started one, I don't think it got to the point where it would work for this, and I don't agree that the json output is a good way to do it.
Re: D-Day for DMD is today!
On Saturday, 29 August 2015 at 16:07:37 UTC, Daniel Murphy wrote: Jacob Carlborg wrote in message news:mrsigg$1574$1...@digitalmars.com... I'm pretty sure we already have a tool that generates C/C++ headers for D modules. Adam started one, I don't think it got to the point where it would work for this, and I don't agree that the json output is a good way to do it. I guess he means dstep...
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 13:14:26 UTC, ponce wrote: ... All of this could be fixed by not letting the GC call destructors. It's a bad, error-prone design to begin with and I guarantee any semi-large D program is probably abusing undefined behavior due to it.
Re: What is the D way to map a binary file to a structure?
29.08.2015 17:17, cym13 пишет: On Saturday, 29 August 2015 at 13:56:10 UTC, drug wrote: Try, for example, MessagePack https://github.com/msgpack/msgpack-d.git Thanks, but it isn't answering the question at all. I'm not looking for a serialization method, I'm looking for the best way to read a binary file. It depends on what is the best for you. But using MessagePack you can easily read the file and fill a structure with it.
Re: dmd codegen improvements
On Sat, Aug 29, 2015 at 01:06:56PM +, David Nadlinger via Digitalmars-d wrote: On Saturday, 29 August 2015 at 12:59:59 UTC, Adam D. Ruppe wrote: I'm happy with the codegen the way it is, it is good enough for me, but let's not make mountains out of hills. But the fact is that many people are not. Even the core language team, who doesn't want their compiler to get 30% slower on the next release. [...] The good thing about switching to DDMD the next release is that (finally) we are forced to address codegen issues. I hope this will finally get Walter going on codegen improvements, which I'm quite sure he's well capable of, but just hasn't gotten around to it until now. Here's to hoping https://issues.dlang.org/show_bug.cgi?id=14943 will be fixed by next release... T -- No, John. I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex. -- Simon St. Laurent on xml-dev
Re: What is the D way to map a binary file to a structure?
On Saturday, 29 August 2015 at 16:47:23 UTC, Laeeth Isharc wrote: Align(1) ? That should do it, thanks :)
Re: dmd codegen improvements
On Saturday, 29 August 2015 at 13:06:58 UTC, David Nadlinger wrote: But the fact is that many people are not. Even the core language team, who doesn't want their compiler to get 30% slower on the next release. That's why your work on ldc and Iain's on gdc matters! I don't object to work on dmd's optimizations, but I'm ok with them staying the way they are too since ldc and gdc are fairly easy to use now.
Re: core.time.Duration.get depreciation time is up
On Saturday, 29 August 2015 at 00:05:21 UTC, Tofu Ninja wrote: http://dlang.org/phobos/core_time.html#.Duration.get Deprecated. Please use split instead. Too frequently, get or one of the individual unit getters is used when the function that gave the desired behavior was total. This should make it more explicit and help prevent bugs. This function will be removed in June 2015. June has come and passed... https://github.com/D-Programming-Language/druntime/pull/1368
Re: D-Day for DMD is today!
On 2015-08-29 12:44, Daniel Murphy wrote: I'm just planning to implement this in dmd and have it dump out all extern(C++) declarations. (and structs and constants) I'm pretty sure we already have a tool that generates C/C++ headers for D modules. -- /Jacob Carlborg
Re: Moving forward with work on the D language and foundation
On 08/28/2015 02:59 PM, bachmeier wrote: On Friday, 28 August 2015 at 17:52:43 UTC, Nhale wrote: good luck focusing on the D. downvote The D jokes almost make me miss the C++? You should be using A++! Durr hurr hurr jokes from non-programmers who thought they were being original and clever. Almost.
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 13:14:26 UTC, ponce wrote:
class MyResource
{
void* handle;
this()
{
handle = create_handle();
}
~this()
{
if (handle != null) // must support repeated calls for
the case (called by .destroy + called by GC later)
{
ensureNotInGC(MyResource);
free_handle(handle);
}
}
}
I don't think it is a good idea to call create_handle() in the
constructor. Why not just pass a handle into the Resource?
Re: GC-proof resource classes
On Saturday, 29 August 2015 at 14:17:10 UTC, rsw0x wrote: On Saturday, 29 August 2015 at 13:14:26 UTC, ponce wrote: ... All of this could be fixed by not letting the GC call destructors. It's a bad, error-prone design to begin with and I guarantee any semi-large D program is probably abusing undefined behavior due to it. After reading all that, I too am convinced that the GC shouldn't call the destructor.
Re: dmd codegen improvements
On Friday, 28 August 2015 at 21:59:57 UTC, Walter Bright wrote: On 8/28/2015 4:18 AM, Temtaime wrote: Are you sure that ONE Walter can achieve what they done ? People told me I couldn't write a C compiler, then told me I couldn't write a C++ compiler. I'm still the only person who has ever implemented a complete C++ compiler (C++98). Then they all (100%) laughed at me for starting D, saying nobody would ever use it. My whole career is built on stepping over people who told me I couldn't do anything and wouldn't amount to anything. LLVM is a fine compiler, but there's nothing magical about it. Besides, we have a secret productivity enhancing weapon that LLVM doesn't have - D! Now, if I can only tear myself away from the internet for a while... The problem is that you're pretty much the face of D along with Andrei. Andrei announcing he was quitting Facebook to work on D fulltime was one of the most popular articles on Reddit's programming subreddit in the past month. Someone picks up D, and realizes that out of the box it has a full stop the world 1960s-style garbage collector completely wrapped in a mutex, can't inline constructors/destructors, basically non-functioning RTTI, no safe way to manage resources, a type system with massive holes in it, type qualifiers being suggestions, the non-proprietary compilers that generate faster code lag a year+ behind. Even more than this, D has no real IDE integration like C++ or Java, and none is even being worked on as far as I'm aware. D is advertised as a system's language, but most of the built-in language features require the GC so you might as well just use C if you can't use the GC. There's other things I can't remember right now. Then they come to the forums and see the head people of D working on ... DMD codegen improvements. That inspires a lot of confidence that these issues will get fixed beyond fixing them yourself - because that's what everyone adopting a new language wants to do. Do you know what the most complaints about D in the reddit thread were? D's incredibly old garbage collector, a complete lack of a good IDE, and a lack of good manual memory management utilities. I'm not blaming you, I'm just not sure if you're aware of what this looks like. If you intend for D to be a hobby project, then continue on.
Re: What is the D way to map a binary file to a structure?
29.08.2015 18:05, cym13 пишет: On Saturday, 29 August 2015 at 14:52:51 UTC, drug wrote: 29.08.2015 17:17, cym13 пишет: On Saturday, 29 August 2015 at 13:56:10 UTC, drug wrote: Try, for example, MessagePack https://github.com/msgpack/msgpack-d.git Thanks, but it isn't answering the question at all. I'm not looking for a serialization method, I'm looking for the best way to read a binary file. It depends on what is the best for you. But using MessagePack you can easily read the file and fill a structure with it. No, because messagepack is one format of binary file. That isn't going to be of any help for any other binary file format. It is not a way to read binary files. It is a serialization format. I see.
Re: What is the D way to map a binary file to a structure?
On Saturday, 29 August 2015 at 12:56:08 UTC, cym13 wrote:
Hi,
Let's say I have a simple binary file whose structure is
well-known. Here is
an example which stores points:
struct Point {
long x;
long y;
long z;
}
struct BinFile {
uintmagicNumber; // Some identifier
ulong pointsNumber;
Point[] points; // Array of pointsNumber points.
}
What is the best way to read some file and fill a structure
with it? Would
reading the file into a void[] and then casting it to the
struct work with
things like internal struct padding?
Align(1) ?
Re: Benchmarking suite
On Saturday, 29 August 2015 at 12:35:14 UTC, Dmitry Olshansky wrote: Well, here is the regex-dna one with 3 versions including C-T regex: https://github.com/DmitryOlshansky/FReD/blob/master/bench/regex-dna/d_dna.d Thanks Dmitry! Which version should be used?
Re: linking external libs
On Thursday, 2 July 2015 at 12:10:52 UTC, Nicholas Wilson wrote: Also is there a binding to GMP somewhere? I just hacked one together. I could need the bindings to fix the pidigits benchmark. There is this 7y old code on dsource: http://www.dsource.org/projects/bindings/browser/trunk/gmp The readme says This is in alpha state. All functions that have been tried seem to work. (8 out of many), so not that confident.
Re: dmd codegen improvements
On Saturday, 29 August 2015 at 18:10:33 UTC, welkam wrote: On Saturday, 29 August 2015 at 14:44:01 UTC, Casual D user wrote: Then they come to the forums and see the head people of D working on ... DMD codegen improvements. That inspires a lot of confidence that these issues will get fixed beyond fixing them yourself - because that's what everyone adopting a new language wants to do. Do you know what the most complaints about D in the reddit thread were? D's incredibly old garbage collector, a complete lack of a good IDE, and a lack of good manual memory management utilities. I'm not blaming you, I'm just not sure if you're aware of what this looks like. If you intend for D to be a hobby project, then continue on. I just want to make sure that you understand that he was asking for low hanging optimization opportunities that could be implemented in few hours of work? All the more if he doesn't, that's the trick with impressions: they don't have to be true to have effects. If that's what it looks like to someone who comes, then it is a problem.
Re: Moving forward with work on the D language and foundation
On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: Hello everyone, Following an increasing desire to focus on working on the D language and foundation, I have recently made the difficult decision to part ways with Facebook, my employer of five years and nine months. Wow, I was really shocked to read this. It takes a lot of courage to do something like this. I wish you and your family all the best luck with this decision, and I'm sure it will be very positive for the D community.
[Issue 13159] std.socket.getAddress allocates once per DNS lookup hit
https://issues.dlang.org/show_bug.cgi?id=13159 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #4 from Vladimir Panteleev thecybersha...@gmail.com --- ??? A concatenation is not an allocation! The runtime will effectively increase arrays when they are appended to by powers of two until the GC block size (4096 bytes), because GC object bins have sizes of powers of two (16 to 2048). Furthermore, didn't recent benchmarks show that std.array.appender performed no better than built-in arrays for concatenation? --
[Issue 13159] std.socket.getAddress allocates once per DNS lookup hit
https://issues.dlang.org/show_bug.cgi?id=13159 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --
[Issue 13159] std.socket.getAddress allocates once per DNS lookup hit
https://issues.dlang.org/show_bug.cgi?id=13159 --- Comment #6 from Jakob Ovrum jakobov...@gmail.com --- (In reply to Vladimir Panteleev from comment #5) The getAddress patch is fine. The getAddressInfo patch seems pointless to me, it does not preallocate any memory (but could be made to if the linked list is traversed twice). Appender has gone through a lot of revision in recent years. Array appends might be better today. The difference is probably negligible; the getAddress patch was the main point. The ideal would be a lazy range version of getAddressInfo. With both `getAddress` and `getAddressInfo` taken, bikeshedding ahoy :) --
Re: Reading and converting binary file 2 bits at a time
On Saturday, 29 August 2015 at 20:15:53 UTC, Marc Schütz wrote:
Just cast to `Crumbs[]` directly:
import std.bitmanip;
import std.stdio;
import std.file;
struct Crumbs {
mixin(bitfields!(
ubyte, one, 2,
ubyte, two, 2,
ubyte, three, 2,
ubyte, four, 2
));
}
void main(string[] argv)
{
auto raw = read(binaryfile);
auto buffer = cast(Crumbs[]) raw;
foreach (cmb; buffer) {
writefln(Crumb one: %s, cmb.one);
writefln(Crumb two: %s, cmb.two);
writefln(Crumb three: %s, cmb.three);
writefln(Crumb four: %s, cmb.four);
}
}
I like that :-)
Re: What is the D way to map a binary file to a structure?
On Saturday, 29 August 2015 at 16:55:44 UTC, cym13 wrote: On Saturday, 29 August 2015 at 16:47:23 UTC, Laeeth Isharc wrote: Align(1) ? That should do it, thanks :) Do not forget to post code example, please, it's interesting to look at your solution...
Re: Moving forward with work on the D language and foundation
On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: Hello everyone, Following an increasing desire to focus on working on the D language and foundation, I have recently made the difficult decision to part ways with Facebook, my employer of five years and nine months. Facebook has impacted my career and life very positively, and I am grateful to have been a part of it for this long. The time has come for me, however, to fully focus on pushing D forward. As sorry I am for leaving a good and secure career behind, I am excited many times over about the great challenges and opportunities going forward. Next step with the D Language Foundation is a formal talk with the foundation's prospective attorney tomorrow. I hope to get the foundation in motion as soon as possible, though I'm told there are numerous steps to complete. I will keep this forum posted about progress. I'm also glad to announce that the D Language Foundation already has a donor - I have decided to contribute my books' royalties to it. I encourage others to respond in kind. Thanks, Andrei Hey, awesome news! I think D has a lot of potential. I really wish it got the attention it deserves. Just curious though, where do containers sit on your todo list? Is there a game-plan for this posted anywhere?
Re: GC-proof resource classes
On 08/29/2015 05:20 PM, cym13 wrote:
On Saturday, 29 August 2015 at 14:32:27 UTC, Timon Gehr wrote:
But then classes with destructors shouldn't be allowed to be allocated
on the GC heap in the first place, which is a PITA as well. (Note that
classes/arrays can have destructors because some component structs
have them; structs generally assume that their destructors will be
called.)
I don't quite follow the reasonning here. If GC doesn't call the
destructor then this same destructor is no more than a normal method
If it is no more than a normal method:
- Why have special syntax for it?
- Why should Object have it?
(with restrictions... would those still stand?) that is the default
destruction method to be called by things like scoped!T or destroy if
explicit destruction is needed.
...
If there is a destructor, this (usually) means that explicit destruction
is needed.
Again, note that if I have
import std.collection: Array;
class C{ Array arr; ... }
then now C implicitly has a destructor (that does nothing but call arr's
destructor which may in turn free memory on the C heap).
Constructor and destructor are supposed to frame the lifetime of an
instance. Destructors are in the language so that the language can help
with enforcing this. If there's a built-in and expected way to violate
this property, the syntactic similarity of constructors and destructors
is misleading, and the features are less useful.
I think there should be a separation of concerns that isn't possible
right now. Freeing ressources and freeing memory isn't the same thing
and they should be decoupled.
Memory is a resource, and not all memory is allocated by the GC. (c.f.
http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html)
I think a destructor is there to free
ressources, and the GC is there to free memory. If the GC doesn't call
the destructor then why should having a destructor have anything to do
with the GC?
Or do you fear for classes whose memory would be freed before freeing
its ressources?
For example. The general idea is that there is no point in having
language features to deal with complex issues if they actually don't.
That could be a problem... In that case I think the best
option would be to allow them to be allocated by the GC
I assume this means allow 'new Class()' even if Class has a destructor.
but GC-ing it if
the destructor hasn't been called should spawn an error (or something
like that, haven't taken the time to think through it).
Why is it sensible to have the same syntax for allocation if
deallocation/destruction needs to be handled differently?
Or maybe it shouldn't be marked as garbage if the destructor hasn't been called.
...
I.e. leak memory.
I think of it as a simple switch hasDestructorBeenCalled that would be
set to true if no destructor exists or if it has been called, and false
otherwise, and would prevent GC-ing (or crash... I don't know what's
best) of the object if false.
That way simple classes stay simple,
Simple classes get an additional hidden field. Even the monitor field is
too much.
complex classes can live on the
heap happily without fearing collection while being able to reliably
free ressources.
This does not make a lot of sense. If there is no live reference to a
class managing a resource and it would then need to fear collection,
this means that the resource has been leaked.
Re: Benchmarking suite
On 29-Aug-2015 21:14, qznc wrote: On Saturday, 29 August 2015 at 12:35:14 UTC, Dmitry Olshansky wrote: Well, here is the regex-dna one with 3 versions including C-T regex: https://github.com/DmitryOlshansky/FReD/blob/master/bench/regex-dna/d_dna.d Thanks Dmitry! Which version should be used? I'd try all of them, I think C-T was the fastest (as it should). -- Dmitry Olshansky
Re: dmd codegen improvements
On Saturday, 29 August 2015 at 14:44:01 UTC, Casual D user wrote: Someone picks up D, and realizes that out of the box it has a full stop the world 1960s-style garbage collector completely wrapped in a mutex, can't inline constructors/destructors, basically non-functioning RTTI, no safe way to manage resources, a type system with massive holes in it, type qualifiers being suggestions, the non-proprietary compilers that generate faster code lag a year+ behind. Seems a bit harsh. As a 'casual D user', you're criticizing Walter for not having dmd inline constructors and destructors at the same time as critizing him for working on codegen. And of course it seems like LDC and GDC do in-line them, so if it matters to you you can use them. Bear in mind that many people seem to be happy enough with languages that are significantly slower than dmd. Of course one will hear disproportionately from people who aren't happy (and fair enough) because if you're happy you let things be. It's not like LDC and GDC are unusable or missing some super critical features just because it takes some time for them to be kept up to date. And if that matters, then a little help for those teams might go a long way as they have a tough job to accomplish with limited resources. You might also be more rhetorically effective if you acknowledged the very real improvements that have taken place, just in the past year. Sending a rocket isn't always the best way to achieve one's ends. http://www.artofmanliness.com/2010/12/21/classical-rhetoric-101-the-three-means-of-persuasion/ Even more than this, D has no real IDE integration like C++ or Java One needs an IDE a bit less than for Java, I suppose. Since there are people working on IDEs and on IDE integration here, some constructive criticism of what you would like to see might again be more helpful rather than just pretending nobody is trying. is even being worked on as far as I'm aware. D is advertised as a system's language, but most of the built-in language features require the GC so you might as well just use C if you can't use the GC Strange then that people who don't depend on the GC seem to like D's features anyway. I wonder why that is. There's other things I can't remember right now. Do you know what the most complaints about D in the reddit thread were? D's incredibly old garbage collector, a complete lack of a good IDE, and a lack of good manual memory management utilities. One needs to pay some attention to critics, because good advice is hard to come by. But it's a mistake to take what they say too seriously, because quite often it's more of an excuse than the real reason. In my experience you can deliver everything people say they want, and then find it isn't that at all. And the lessons of the Innovator's Dilemma by Christensen is that it may be better to develop what one does really well than to focus all one's energy on fixing perceived' weaknesses. It's not like what the crowd says on reddit must be taken as gospel truth, really.
Re: Moving forward with work on the D language and foundation
I'm a bit late to reply to this announcement, but I would like to say that I am quite surprised by it. I really respect your decision to leave what must have been a very lucrative job to double down on D. I have loved D since I picked it up years ago, and TDPL was my first real introduction to the language. You have really done a lot to contribute to a great language, and you are one of the software professionals I most respect. I'm looking forward to seeing what you can accomplish as a full time D overlord in the future.
Re: dmd codegen improvements
On Saturday, 29 August 2015 at 20:13:57 UTC, Ola Fosheim Grostad wrote: On Saturday, 29 August 2015 at 19:37:33 UTC, Laeeth Isharc wrote: it takes some time for them to be kept up to date. And if that matters, then a little help for those teams might go a long way as they have a tough job to accomplish with limited resources. If it is a toy language with a hobby development process then it does not warrant more resources. Walter is entitled to do what is fun and rewarding to him, obviously. If working on his propriatory backend is important to him, then he should do so. Nobody has a right to question that. But the net effect of maintaining 3 different backends is sending signals that the project lacks direction and priorities. Why would anyone commit resources to a project that lacks direction? We are all entitled to our opinion. It's my experience that people tend to listen more to those who show themselves to be generally friendly and encouraging than those in whose eyes one doesn't seem to be able to do anything right. D doesn't strike me as a language, project or community lacking in direction, particularly given recent developments. I suspect resources of all sorts will come in time. Toy languages aren't used by the sorts of people that have built their businesses around D. I don't think you do yourself any favours by adopting the tone you do. It's disrespectful and unconstructive. In any case, I don't wish to divert attention from what's important, so I won't say anything more on this topic.
Re: dmd codegen improvements
On Saturday, 29 August 2015 at 14:44:01 UTC, Casual D user wrote: Then they come to the forums and see the head people of D working on ... DMD codegen improvements. That inspires a lot of confidence that these issues will get fixed beyond fixing them yourself - because that's what everyone adopting a new language wants to do. Do you know what the most complaints about D in the reddit thread were? D's incredibly old garbage collector, a complete lack of a good IDE, and a lack of good manual memory management utilities. I'm not blaming you, I'm just not sure if you're aware of what this looks like. If you intend for D to be a hobby project, then continue on. I just want to make sure that you understand that he was asking for low hanging optimization opportunities that could be implemented in few hours of work?
Re: dmd codegen improvements
On Saturday, 29 August 2015 at 19:37:33 UTC, Laeeth Isharc wrote: it takes some time for them to be kept up to date. And if that matters, then a little help for those teams might go a long way as they have a tough job to accomplish with limited resources. If it is a toy language with a hobby development process then it does not warrant more resources. Walter is entitled to do what is fun and rewarding to him, obviously. If working on his propriatory backend is important to him, then he should do so. Nobody has a right to question that. But the net effect of maintaining 3 different backends is sending signals that the project lacks direction and priorities. Why would anyone commit resources to a project that lacks direction?
Re: Reading and converting binary file 2 bits at a time
Just cast to `Crumbs[]` directly:
import std.bitmanip;
import std.stdio;
import std.file;
struct Crumbs {
mixin(bitfields!(
ubyte, one, 2,
ubyte, two, 2,
ubyte, three, 2,
ubyte, four, 2
));
}
void main(string[] argv)
{
auto raw = read(binaryfile);
auto buffer = cast(Crumbs[]) raw;
foreach (cmb; buffer) {
writefln(Crumb one: %s, cmb.one);
writefln(Crumb two: %s, cmb.two);
writefln(Crumb three: %s, cmb.three);
writefln(Crumb four: %s, cmb.four);
}
}
[Issue 14979] [REG2.068] Wrong tempCString result on x64 with ternary operator
https://issues.dlang.org/show_bug.cgi?id=14979 --- Comment #1 from Kenji Hara k.hara...@gmail.com --- Perhaps the root is issue 14696. --
[Issue 14743] ICE in TemplateInstance::needsTypeInference() with template forward reference
https://issues.dlang.org/show_bug.cgi?id=14743 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/453a1d6ecc68c03a23079ddbf58684b8aae8d5d5 fix Issue 14743 - ICE in TemplateInstance::needsTypeInference() with template forward reference https://github.com/D-Programming-Language/dmd/commit/f18fe224da8357ec28c9693215c73830830e2965 Merge pull request #4792 from 9rnsr/fix14743 Issue 14743 - ICE in TemplateInstance::needsTypeInference() with template forward reference --
Re: dmd codegen improvements
On Sunday, 30 August 2015 at 03:04:28 UTC, Adam D. Ruppe wrote: On Sunday, 30 August 2015 at 02:34:46 UTC, Ola Fosheim Grostad wrote: Then why are they trailing the main compiler if they represent an insignificant effort? In some areas, they are ahead. gdc is directly responsible for the D debugging experience on Linux, for example. But they also have fewer than 10% of the contributors. Number of contributors does not say all that much. It is competence and tine that matters. For a project that is in perpetual beta leaders need to show their priorities. Here is a good list: 1. Complete the language specification (define semantics). 2. Implement and polish semantics. 3. Clean up syntax. 4. Tooling. 5. Performance. As a leader you should create a frame for others to fill in. That means you cannot afford to focus you effort on point 5, it essentially means you resign the role as a project lead. Enabling others to work at point 5 would be completely ok...
Re: dmd codegen improvements
On Saturday, 29 August 2015 at 20:36:33 UTC, Laeeth Isharc wrote: doesn't seem to be able to do anything right. D doesn't strike me as a language, project or community lacking in direction, particularly given recent developments. I suspect resources of all sorts will come in time. When people work on FOUR compilers then you cannot complain about lack of resources. You then need to see if you can do something to unite efforts. Toy languages aren't used by the sorts of people that have built their businesses around D. I don't think you do yourself any favours by adopting the tone you do. It's disrespectful and unconstructive. I am not calling D a toy language, other people do and you have to come to terms with that. D has rough edges and is in an incomplete state, this has to be acknowledged rather than glossed over, it is dishonest and give developers too high expectations. That is disrespectful to potential adopters. And that is why these complaints resurface with a high pitched delivery. In any case, I don't wish to divert attention from what's important, so I won't say anything more on this topic. Having a propietary in the core product is a liability in terms of creating a foundation. That actually is important. It actually would be better to reimplement a new D backend from scratch.
Re: observation: D getting a bit complex
Hi! I completely agree. D1 is much better :-) I removed a threading support from my variant because program don't start if OS don't have a POSIX threading (LInux 2.4.37 for example). A garbage colllector can be disabled (as I understand). May be a compiler support (warnings) is needed if gc will be used (needed) in the code With such changes D1 can be used for Linux kernel modules. But I don't done this yet. I nice stuff: libc written in D (a small part of the uCLibc, not finished) PS: trying to understand a D backend I removed all stuff related to the C++ and win32 PPS: what is the rigth way to connect a backed to the frontend? I studied only d-to-js, d-to-c, d-to-c#, tdc and some version of the D0 compiler with custom asm generator (GDC and LDC are not studied) 2015-08-30 5:42 GMT+03:00, Spacen Jasset via Digitalmars-d-learn digitalmars-d-learn@puremagic.com: The following reminds me of the good old C++ template errors the C++ compiler spits out. Whilst D has fixed that problem, some things have gotten more complex. I just wanted to find a replacement for D1 path join, and found this, but it doesn't seem very easy to wade though this stuff. immutable(ElementEncodingType!(ElementType!Range))[] buildPath(Range)(Range segments) if (isInputRange!Range isSomeString!(ElementType!Range)); pure nothrow @safe immutable(C)[] buildPath(C)(const(C)[][] paths...) if (isSomeChar!C); http://dlang.org/phobos/std_path.html It would take me a lot of time to appeciate what that all means, although I can imagine what it is for. ...just and observation. The complexity is building.
[Issue 14979] New: [REG2.068] Wrong tempCString result on x64 with ternary operator
https://issues.dlang.org/show_bug.cgi?id=14979
Issue ID: 14979
Summary: [REG2.068] Wrong tempCString result on x64 with
ternary operator
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: thecybersha...@gmail.com
// test.d /
enum testStr = Hello, beautiful world!;
void funA(const char* node)
{
import core.stdc.string;
assert(strcmp(node, testStr)==0);
}
unittest
{
string node = testStr;
import std.internal.cstring;
funA(node is null ? null : node.tempCString());
}
///
Introduced in https://github.com/D-Programming-Language/phobos/pull/3415/files
Happens only on x64, perhaps this is a codegen bug?
--
