[Issue 14570] New: Compiler crash relating to extern(C++)
https://issues.dlang.org/show_bug.cgi?id=14570
Issue ID: 14570
Summary: Compiler crash relating to extern(C++)
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: turkey...@gmail.com
extern(C++):
struct X
{
__gshared immutable(int)[4] s;
}
Emits the error:
2Error: Internal Compiler Error: shared or immutable types can not be mapped
to C++ (immutable(int[5]))
2Assertion failure: '0' on line 947 in file 'cppmangle.c'
And then crashes with popup abnormal program termination
Error is reasonable, but shouldn't crash.
--
Re: Sneak preview into std.allocator's porcelain
On Thursday, 7 May 2015 at 18:26:47 UTC, Andrei Alexandrescu wrote: https://git-scm.com/book/tr/v2/Git-Internals-Plumbing-and-Porcelain Made perfect sense the second I first saw it. -- Andrei I always thought that it was a bit vulgar, myself, but git has made the term at least somewhat common in this context. - Jonathan M Davis
[Issue 14539] +508KB (684KB - 1191KB) filesize increase Hello, world binary
https://issues.dlang.org/show_bug.cgi?id=14539 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com --- Hmm, when are we going to insert a test in the autotester test suite for file size? --
Re: Sneak preview into std.allocator's porcelain
On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote: http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html On the face of it, it's doing roughly what I expected, though the devil's in the details, and it's likely taking care of quite a few things that I hadn't thought of. I was surprised to see that arrays didn't just use make, but on further inspection, I would guess that it was just easier to have a separate makeArray due to differences in arguments, since otherwise, you'd need to muck around with make's auto ref parameters to make sure that they lined up with the parameters that makeArray currently expects when make was instantiated with an array and give an error otherwise, and makeArray makes the parameters clear in the signature. - Jonathan M Davis
Re: mscoff x86 invalid pointers
On Sunday, 10 May 2015 at 12:20:39 UTC, Etienne Cimon wrote: On 2015-05-10 03:54, Baz wrote: On Sunday, 10 May 2015 at 04:16:45 UTC, Etienne Cimon wrote: On 2015-05-09 05:44, Baz wrote: On Saturday, 9 May 2015 at 06:21:11 UTC, extrawurst wrote: On Saturday, 9 May 2015 at 00:16:28 UTC, Etienne wrote: I'm trying to compile a library that I think used to work with -m32mscoff flag before I reset my machine configurations. https://github.com/etcimon/memutils Whenever I run `dub test --config=32mscoff` it gives me an assertion failure, which is a global variable that already has a pointer value for some reason.. I'm wondering if someone here could test this out on their machine with v2.067.1? There's no reason why this shouldn't work, it runs fine in DMD32/optlink and DMD64/mscoff, just not in DMD32/mscoff. Thanks! you can always use travis-ci to do such a job for you ;) doesn't -m32mscoff recquire phobos to be compiled as COFF too ? I think that travis uses the official releases (win32 releases have phobos as OMF) so he can't run the unittests like that... The dark side of the story is that you have to recompile phobos by hand with -m32mscoff...I'm not even sure that there is a option for this in the win32.mak... Meh, I ended up upgrading to 2.068 and everything went well. I clearly remember 2.067.1 working but spent a whole day recompiling druntime/phobos COFF versions in every configuration possible and never got it working again Could you tell me the way to compile druntime phobos 32bit COFF ? Would you have some custom win32.mak to share ? Thx. I edited win64.mak, you need to change it to MODEL=32mscoff and remove all occurence of amd64/ in the file (there are 3), for both druntime and phobos. Save this to win32mscoff.mak You need to place the phobos32mscoff.lib into dmd2/windows/lib32mscoff/ (the folder doesn't exist) Obviously there is no config for gcc-cpp...thx anyway for the tips.
Re: DOtherSide: QML bindings for both D and Nim
Could you add examples of usage this binding on Windows please.
[Issue 14568] New: gaggederrors ICE
https://issues.dlang.org/show_bug.cgi?id=14568
Issue ID: 14568
Summary: gaggederrors ICE
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: vlevenf...@gmail.com
this is an invalid program, but instead of an error message gives this:
dmd: statement.c:752: ErrorStatement::ErrorStatement(): Assertion
`global.gaggedErrors || global.errors' failed.
program:
struct Interval ()
{
auto left = INVALID;
auto opAssign ()(Interval){left;}
}
auto interval (T)(T point)
{
Interval!();
}
alias Instantiate (alias symbol, Args...) = symbol!Args;
template Match (patterns...)
{
static if (__traits(compiles, Instantiate!(patterns[0])))
alias Match = patterns[0];
else static if (patterns.length == 1)
{}
}
template SubOps (Args...)
{
auto opIndex ()
{
template IntervalType (T...)
{
alias Point () = typeof(T.interval);
alias IntervalType = Match!(Point);
}
alias Subspace = IntervalType!(Args);
}
}
struct Nat {mixin SubOps!(null);}
--
Just Submitted my proposal for Strange Loop 2015
https://thestrangeloop.com/sessions-page/call-for-presentations Pretty much everyone who has presented or submitted a proposal for DConf should also make a submission to Strange Loop. The deadline is May 15.
[Issue 14569] New: BigInt is not compatible with the type of immutable (char) and has a problem when converting from a type immutable(char)
https://issues.dlang.org/show_bug.cgi?id=14569
Issue ID: 14569
Summary: BigInt is not compatible with the type of immutable
(char) and has a problem when converting from a type
immutable(char)
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: dennis.m.ritc...@mail.ru
In my opinion, this should be corrected:
import std.stdio : writeln;
import std.conv : to, text;
import std.bigint : BigInt;
void main() {
BigInt twoInThousand = 2.to!BigInt ^^ 1000;
string s = twoInThousand.text;
BigInt sum1, sum2, sum3, sum4;
foreach (e; s) {
// sum1 += e.to!BigInt; // Error: template instance
// std.conv.to!(BigInt).to!(immutable(char)) error instantiating
sum2 += e.to!int; // wrong
sum3 += e.to!uint; // wrong
sum4 += e.text.to!BigInt; // OK
}
writeln(sum2); // 15862 // wrong
writeln(sum3); // 15862 // wrong
writeln(sum4); // 1366 // OK
}
--
[Issue 14569] BigInt is not compatible with the type of immutable (char) and has a problem when converting from a type immutable(char)
https://issues.dlang.org/show_bug.cgi?id=14569 dennis.m.ritc...@mail.ru changed: What|Removed |Added CC||dennis.m.ritc...@mail.ru --
Re: DLL symbol identity
Well choice between two presented options seems obvious so I suspect a catch :)
Re: Breaking changes in Visual C++ 2015
On Sunday, 10 May 2015 at 12:54:02 UTC, Timon Gehr wrote: On 05/10/2015 07:39 AM, H. S. Teoh via Digitalmars-d wrote: I also just realized that on Posix the profiling code apparently relies on the rdtsc instruction, which counts CPU cycles in a 64-bit counter -- given the high frequencies of modern CPUs, moderately long-running CPU-intensive processes easily overflow this counter, leading to wrapped-around timing values and completely garbled output. gprof, for all of its flaws, does not suffer from this problem. http://www.wolframalpha.com/input/?i=2^64%2F%289+GHz%29 What am I missing? http://www.wolframalpha.com/input/?i=2^32%2F%289+GHz%29 It doesn't look at good that way, especially if you have some tight loops.
Re: DLL symbol identity
Am 10.05.2015 um 21:51 schrieb Dicebot: On Friday, 8 May 2015 at 05:26:01 UTC, Benjamin Thaut wrote: Pro: - Its the plain windows shared library mechanism in all its uglyness. I wonder if anyone can provide more Pro input :) I described both implementations of shared libaries. From the description alone you should be able to find any other pro arguments for the windows approach. The only one I could find was, that its faster at program startup time, compared to the linux one, but is inferrior in all other points.
[Issue 13996] Function for returning a temporary file with a randomly generated name where the name can be accessed
https://issues.dlang.org/show_bug.cgi?id=13996 --- Comment #11 from github-bugzi...@puremagic.com --- Commit pushed to revert-2956-tempFile at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/8087f354414ed39f23eec94049a1a154fcbb412c Revert Implement issue# 13996. Add File.tempFile. --
[Issue 14539] +508KB (684KB - 1191KB) filesize increase Hello, world binary
https://issues.dlang.org/show_bug.cgi?id=14539 --- Comment #2 from Walter Bright bugzi...@digitalmars.com --- https://github.com/D-Programming-Language/phobos/pull/3273 --
Re: Sneak preview into std.allocator's porcelain
On Sunday, 10 May 2015 at 16:56:27 UTC, Jacob Carlborg wrote: On 2015-05-08 21:55, Andrei Alexandrescu wrote: a few measurements would be in order. -- Andrei Be sure you do that on more than one platform. For example, the emulate TLS on OS X can be quite slow, I've heard. I was trying to come up with a good benchmark for TLS, but it is remarkably difficult. Usually, you have one TLS segment per linker module (meaning one for your app + one per shared object). You have once segment that is kept around by the compiler to be used. Once you access TLS in your code, things goes as follow: 1/ The compiler know you have the right segment around and so segment lookup needs to take place. 2/ The compiler don't know it, but you have the right segment. In which case you do a round trip in the runtime, but take the fast path. 3/ You have the wrong segment, in which case the runtime have to figure out what is the right segment, and that is slow and often imply locks, and even, in worst case scenarii, round trip to the OS. A good benchmark must have TLS accessed from the application and from some shared object, be big enough so the compiler do not see through all these access (or is will simply keep both segment around which it won't do by default, but will if necessity is apparent), and have a realistic access pattern (it is fairly easy to trash the perfs by doing ping pong between the 2 TLS segment, but it is probably not very realistic). Long story short, I'm worried by this TLS issue, but I'd welcome more data.
This Week in D 16: microcontroller, andoid, std.allocator, lazy import trick
http://arsdnet.net/this-week-in-d/may-10.html https://twitter.com/adamdruppe/status/597598994227924992 The tip could probably use a rewrite in editing, but I'm out of time again tonight and I hope I got the point across anyway. As someone who really likes distributing single-file libraries when possible, the lazy import has given me some cool interop things without compromising my preferred distribution strategy.
Re: Tuple assignment
On 5/10/2015 1:18 AM, Russel Winder via Digitalmars-d wrote: Using LDC, the tuple version generates more code unoptimized, but with optimization, the exact same assembly language code is generated for the two cases. Win. This is what makes D's ranges+algorithms so attractive. They are easier to write correct code in, and when optimized produce the same code.
Re: Object.factory fails for nested classes ?!
On Sunday, 10 May 2015 at 13:38:22 UTC, extrawurst wrote: Is it a bug or just missing specification that using Object.factory(fullyQualifiedNameToNestedClass) fails ? See repro here: http://dpaste.dzfl.pl/d789237b0f46 Regards, Stephan Ok real nested classes (class with outer pointer) wont work (why does it fail inside a struct then?) That still leaves the question why a simple class declared in a unittest scope wont work either (even declared as a static class): http://dpaste.dzfl.pl/33ee48536ecb ideas anyone ?
[Issue 14560] Strange -inline behavior
https://issues.dlang.org/show_bug.cgi?id=14560 Martin Krejcirik m...@krej.cz changed: What|Removed |Added CC||m...@krej.cz --
[Issue 14560] Strange -inline behavior
https://issues.dlang.org/show_bug.cgi?id=14560 --- Comment #2 from Martin Krejcirik m...@krej.cz --- What is the expected error here ? I don't get any output or compilation error. --
[Issue 14564] [REG2.067] dmd -property -unittest combination causes compiler error
https://issues.dlang.org/show_bug.cgi?id=14564 Martin Krejcirik m...@krej.cz changed: What|Removed |Added Summary|dmd -property -unittest |[REG2.067] dmd -property |combination causes compiler |-unittest combination |error |causes compiler error --
[Issue 14560] [REG2.066] Strange -inline behavior
https://issues.dlang.org/show_bug.cgi?id=14560 Martin Krejcirik m...@krej.cz changed: What|Removed |Added Hardware|x86_64 |All Summary|Strange -inline behavior|[REG2.066] Strange -inline ||behavior --
[Issue 14560] [REG2.066] Strange -inline behavior
https://issues.dlang.org/show_bug.cgi?id=14560 --- Comment #4 from Martin Krejcirik m...@krej.cz --- Fails since 2.058 on x86 and since 2.066 on x86_64, marked reg 2.066 for now. --
Re: Breaking changes in Visual C++ 2015
On 05/10/2015 07:39 AM, H. S. Teoh via Digitalmars-d wrote: I also just realized that on Posix the profiling code apparently relies on the rdtsc instruction, which counts CPU cycles in a 64-bit counter -- given the high frequencies of modern CPUs, moderately long-running CPU-intensive processes easily overflow this counter, leading to wrapped-around timing values and completely garbled output. gprof, for all of its flaws, does not suffer from this problem. http://www.wolframalpha.com/input/?i=2^64%2F%289+GHz%29 What am I missing?
Re: A few thoughts on std.allocator
On 05/10/2015 11:50 AM, Andrei Alexandrescu wrote: In C, C++, and D people have allocated memory for a long time in the following manner: ... Long story short, arrays should sit on a different heap than objects. ... Unless this has been fixed in the interim, I believe DMD lowers new S(args) to [S(args)].ptr for struct S. It should be ensured that the global allocator will not be misinformed about the kind of allocation that takes place, by removing this lowering. 3. Thread-local vs. shared objects Currently in D it's legal to allocate memory in one thread and deallocate it in another. (One simple way to look at it is casting to shared.) This has a large performance cost that only benefits very few actual cases. It follows that we need to change the notion that you first allocate memory and then brand it as shared. The will be shared knowledge must be present during allocation, and use different methods of allocation for the two cases. ... 6. Immutable vs. mutable I'm not sure how this can be practically exploited. There must be something in the notion that, save for a brief write period after allocation, the memory will stay unmodified. Still thinking. ... Keep in mind that currently, entire regions of memory can change from mutable to immutable implicitly when returned from pure functions. Furthermore, as Michel points out, the ways 'immutable' can be leveraged is constrained by the fact that it implies 'shared'.
[Issue 14560] Strange -inline behavior
https://issues.dlang.org/show_bug.cgi?id=14560 --- Comment #3 from Vladimir Panteleev thecybersha...@gmail.com --- Non-zero exit code --
Re: New adapter: std.allocator.quantizer
On 05/10/2015 05:29 AM, Andrei Alexandrescu wrote: On 5/9/15 3:38 PM, Timon Gehr wrote: Thanks! Looks good, except: 106| if (!parent.expand(b, goodAllocSize(needed) - b.length)) Let's see, this is a tad tricky. needed is the needed size, i.e. b.length + delta. We want to expand to a final size of goodAllocSize(needed). So we need to pass the appropriate delta to expand, i.e. goodAllocSize(needed) - b.length. (recall that expand() takes the delta, not the new size) ... Yes, but 'expand' expects a _full_ block that was allocated by that allocator: bool expand(ref void[] b, size_t delta); Post: !result || b.length == old(b).length + delta Expands b by delta bytes. If delta == 0, succeeds without changing b. If b is null, the call evaluates b = allocate(delta) and returns b !is null. Otherwise, *b must be a buffer previously allocated with the same allocator*. If expansion was successful, expand changes b's length to b.length + delta and returns true. Upon failure, the call effects no change upon the allocator object, leaves b unchanged, and returns false. 142| return parent.reallocate(b, gs); gs is precomputed at the top of the function to be goodAllocSize(s), so this seems to be in good shape. 172| return parent.alignedReallocate(b, gs, a); Same here, the intent is to reallocate to goodAllocSize(s), which is precomputed in gs. ... I think there has been a misunderstanding here, probably I wasn't specific enough. 'b' is a slice of the block that was allocated by the parent allocator. Its size will generally be smaller than what the parent allocator expects.
Re: New adapter: std.allocator.quantizer
On 05/10/2015 05:32 AM, Andrei Alexandrescu wrote: On 5/9/15 3:41 PM, Timon Gehr wrote: On 05/10/2015 12:38 AM, Timon Gehr wrote: 142| return parent.reallocate(b, gs); 172| return parent.alignedReallocate(b, gs, a); (Note that those code snippets also occur in their documentation.) Can't find gs in the doc comments, is it there? -- Andrei (They don't appear verbatim, but they call the parent functions with the plain 'b' in the documentation as well.)
Re: New adapter: std.allocator.quantizer
On 05/10/2015 05:38 AM, Andrei Alexandrescu wrote:
On 5/9/15 3:54 PM, Timon Gehr wrote:
On 05/10/2015 12:38 AM, Timon Gehr wrote:
monotone increasing and piecewise constant with one fixed point per
piece.
(Note that monotone increasing is implied by piecewise constant with one
fixed point per piece, so it does not necessarily need to be documented
separately.)
I think the only requirements are (a) roundingFunction is pure, (b)
roundingFunction(n) = n. E.g. the identity function works, although
it's not terribly useful.
These could be enforced by Quantizer, but it doesn't feel right. A
designer who is at the same time sophisticated enough to need Quantizer
yet naïve enough to choose a lousy one is quite unlikely. On the other
hand, I can imagine stuff like this could be useful to some:
__gshared uint SMALL_ALLOC = 64;
... configure it via an application-level flag...
alias MyAlloc = Quantizer!(
FreeTree!GCAllocator,
n = n.roundUpToMultipleOf(n = SMALL_ALLOC ? 64 : 4096));
That's technically not pure but works, and might be appreciated.
Andrei
size_t brokenRoundingFunction(size_t siz){
if(siz==10) return 40;
if(siz==20) return 30;
return siz;
}
alias BrokenAlloc = Quantizer!(
SomeAllocatorThatReliesOnProvidedBlockSize,
brokenRoundingFunction
);
void main(){
BrokenAlloc borked;
// allocate buffer of size 40, slice 10 bytes off it:
auto b=borked.allocate(10);
// awesome, can expand in-place since 20 = 40:
borked.expand(a,10);
// oops, now we try to deallocate a block of size 30
// from the parent, even though the allocated size
// is 40:
borked.deallocate(a);
}
(Untested, but it should wreak some havoc.)
Re: New adapter: std.allocator.quantizer
On 05/10/2015 01:48 PM, Timon Gehr wrote: bool expand(ref void[] b, size_t delta); Post: !result || b.length == old(b).length + delta Expands b by delta bytes. If delta == 0, succeeds without changing b. If b is null, the call evaluates b = allocate(delta) and returns b !is null. Otherwise, *b must be a buffer previously allocated with the same allocator*. If expansion was successful, expand changes b's length to b.length + delta and returns true. Upon failure, the call effects no change upon the allocator object, leaves b unchanged, and returns false. Actually, reading that snippet of the documentation, I notice more problems in the implementation of expand/the documentation of the rounding function. If the rounding function returns a non-zero result for a zero argument, expand can return invalid memory (starting from address 0) if given an empty block 'b'.
[Issue 14558] Attempts to link with DMD when using MSVC LDC under VisualD
https://issues.dlang.org/show_bug.cgi?id=14558 --- Comment #4 from Manu turkey...@gmail.com --- Oh okay. Will adding it to the Executable Paths cause it to take precedence over other paths already in $PATH? MinGW LDC is probably of fairly limited use... I imagine more MinGW users would want to use GDC? Seems more conventional to me. --
Re: mscoff x86 invalid pointers
On 2015-05-10 03:54, Baz wrote: On Sunday, 10 May 2015 at 04:16:45 UTC, Etienne Cimon wrote: On 2015-05-09 05:44, Baz wrote: On Saturday, 9 May 2015 at 06:21:11 UTC, extrawurst wrote: On Saturday, 9 May 2015 at 00:16:28 UTC, Etienne wrote: I'm trying to compile a library that I think used to work with -m32mscoff flag before I reset my machine configurations. https://github.com/etcimon/memutils Whenever I run `dub test --config=32mscoff` it gives me an assertion failure, which is a global variable that already has a pointer value for some reason.. I'm wondering if someone here could test this out on their machine with v2.067.1? There's no reason why this shouldn't work, it runs fine in DMD32/optlink and DMD64/mscoff, just not in DMD32/mscoff. Thanks! you can always use travis-ci to do such a job for you ;) doesn't -m32mscoff recquire phobos to be compiled as COFF too ? I think that travis uses the official releases (win32 releases have phobos as OMF) so he can't run the unittests like that... The dark side of the story is that you have to recompile phobos by hand with -m32mscoff...I'm not even sure that there is a option for this in the win32.mak... Meh, I ended up upgrading to 2.068 and everything went well. I clearly remember 2.067.1 working but spent a whole day recompiling druntime/phobos COFF versions in every configuration possible and never got it working again Could you tell me the way to compile druntime phobos 32bit COFF ? Would you have some custom win32.mak to share ? Thx. I edited win64.mak, you need to change it to MODEL=32mscoff and remove all occurence of amd64/ in the file (there are 3), for both druntime and phobos. Save this to win32mscoff.mak You need to place the phobos32mscoff.lib into dmd2/windows/lib32mscoff/ (the folder doesn't exist)
Re: Dare I ... another volatile discussion ?
On Saturday, 9 May 2015 at 16:59:35 UTC, Jens Bauer wrote: ... System calls will need to access the peripherals in some way, in order to send data to for instance a printer or harddisk. If the way it's done is using a memory location, then it's necessary to tell the compiler that this is not ordinary memory, but I/O-memory AKA hardware address space. Userland code still uses system calls and not global variables, whatever is expressed in read(2) signature tells the compiler enough to pass data via buffer. Shared is supposed to prevent the programmer from accidentally putting unshared data in a shared context. Expectedly people wanted it to be a silver bullet for concurrency, instead std.concurrency provides high-level concurrency safety. In other words, it's the oposite of 'static' ? Whether data is shared or not is not tied to its storage class, that's why its shared nature is expressed in its type and storage class can be anything; for the same reason shared type qualifier is transitive.
Re: std.xml2 (collecting features)
On Sunday, 10 May 2015 at 08:54:09 UTC, Joakim wrote: It's worse than shabby, it's a horrible, horrible choice. Not just for data formats, but for _anything_. XML should not be used. I feel the same way about XML, and I also think that having strong aesthetic internal emotional responses is often necessary to achieve excellence in engineering. But why do we often end up dealing with these two? Familiarity, that is the only reason. XML seems familiar to anybody who's written some HTML, and JSON became familiar to web developers initially. Starting from those two large niches, they've expanded out to become the two most popular data interchange formats, despite XML being a horrible mess and JSON being too simple for many uses. Sometimes you get to pick, but often not. I can hardly tell the UK Debt Management Office to give up XML and switch to msgpack structs (well, I can, but I am not sure they would listen). So at the moment for some data series I use a python library via PyD to convert xml files to JSON. But it would be nice to do it all in D. I am not sure XML is going away very soon since new protocols keep being created using it. (Most recent one I heard of is one for allowing hedge funds to achieve full transparency of their portfolio to end investors - not necessarily something that will achieve what people think it will, but one in tune with the times). Laeeth.
Comparing variants
Comparing integer signed and unsigned variants will result in
error:
import std.variant;
void main()
{
auto a = 11;
auto b = 10u;
assert(a b);
Variant va = 11;
Variant vb = 10u;
assert(va vb); //error
}
std.variant.VariantException@std/variant.d(1309): Variant:
attempting to use incompatible types int and uint
Is this intended behaviour? I'm asking because the rest of
arithmetic/equality operations are working as expected, only
opCmp throws.
Re: Tuple assignment
On Sat, 2015-05-09 at 13:07 -0700, Walter Bright via Digitalmars-d wrote: On 5/9/2015 10:16 AM, Russel Winder via Digitalmars-d wrote: Python has tuple assignment so you see things like: previous, current = current, previous + current especially if you are doing silly things like calculating Fibonacci Sequence values. Translating this to D, you end up with: TypeTuple!(current, next) = tuple(next , current +next); I am assuming this is horrendously inefficient at run time compared to having the intermediate value explicit: auto t = next; next = current + next; current = t; or is it? It probably depends on the compiler. The way to find out is to look at the generated assembler. Using LDC, the tuple version generates more code unoptimized, but with optimization, the exact same assembly language code is generated for the two cases. Win. Albeit the D syntax is not as nice as the Python syntax. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: std.xml2 (collecting features)
On Sunday, 10 May 2015 at 07:01:58 UTC, Marco Leise wrote: Am Sat, 09 May 2015 10:28:52 + schrieb Joakim dl...@joakim.fea.st: On Monday, 4 May 2015 at 18:50:43 UTC, Marco Leise wrote: Remember that while JSON is simpler, XML is not just a structured container for bool, Number and String data. It comes with many official side kicks covering a broad range of use cases: XPath: … XSL and XSLT … XSL-FO (XSL formatting objects): … XML Schema Definition (XSD): … These are all incredibly dumb ideas. I don't deny that many people may use these things, but then people use hammers for all kinds of things they shouldn't use them for too. :) :) One can't really answer this one. But with many hundreds of published data exchange formats built on XML, it can't have been too shabby all along. It's worse than shabby, it's a horrible, horrible choice. Not just for data formats, but for _anything_. XML should not be used. And sometimes small things matter, like being able to add comments along with the payload. JSON doesn't have that. Or knowing that both sender and receiver will validate the XML the same way through XSD. So if it doesn't blow up on your end, it will pass validation on the other end, too. One can do all these things with better formats than either XML or JSON. But why do we often end up dealing with these two? Familiarity, that is the only reason. XML seems familiar to anybody who's written some HTML, and JSON became familiar to web developers initially. Starting from those two large niches, they've expanded out to become the two most popular data interchange formats, despite XML being a horrible mess and JSON being too simple for many uses. I'd like to see a move back to binary formats, which is why I mentioned that to Robert. D would be an ideal language in which to show the superiority of binary to text formats, given its emphasis on efficiency. Many devs have learned the wrong lessons from past closed binary formats, when open binary formats wouldn't have many of those deficiencies. There have been some interesting moves back to open binary formats/protocols in recent years, like Hessian (http://hessian.caucho.com/), Thrift (https://thrift.apache.org/), MessagePack (http://msgpack.org/), and Cap'n Proto (from the protobufs guy after he left google - https://capnproto.org/). I'd rather see phobos support these, which are the future, rather than flash-in-the-pan text formats like XML or JSON.
Re: Tuple assignment
On Sun, 2015-05-10 at 08:47 +, Oren Tirosh via Digitalmars-d wrote: […] tuple(current, next) = tuple(next , current +next); […] Works for me. If this is version or compiler dependent this definitely needs investigation. It does not for me using rdmd 2.067. My implementation of nth Fibonacci Number leads to success for my version but not for yours. Maybe we should exchange codes offlist? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
[Issue 14566] New: [2.067] core.demangle: New Nj attribute not handled
https://issues.dlang.org/show_bug.cgi?id=14566
Issue ID: 14566
Summary: [2.067] core.demangle: New Nj attribute not handled
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: ibuc...@gdcproject.org
With this code:
---
module demangle
struct test { this(this) { } }
---
In 2.066, the frontend mangling ABI would emit an opAssign as follows:
_D8demangle4test8opAssignMFNcS8demangle4testZS8demangle4test
In 2.067, the frontend now pushes out the following mangled symbol:
_D8demangle4test8opAssignMFNaNbNcNiNjNfS8demangle4testZS8demangle4test
Which, due to the introduction of Nj for the STCreturn storage (which is for
internal purposes only as far as I can tell), core.demangle is no longer able
to demangle it.
--
Re: Memory usage tracking
On Sunday, 10 May 2015 at 09:44:42 UTC, tcak wrote: I am testing my web server right now. I started 5 separate consoles and continuously sending request by using curl to it. It uses shared memory as well, thought from `ipcs -a`, I don't see more than necessary amount of allocation. At the moment, server received about 1.5M requests, and memory usage has reached to 128MB according to System Monitor of Ubuntu. (top gives a similar value as well). I saw now on `top` command that about 650KB shared memory is used only. Is there any way to find out what is using that big space in memory? Would `-profile` do that? Problem is that if I was to be using `-profile` flag, server would slow down, and I wouldn't be able to test it correctly already. Hmm. Server was compiled in debug mode. Right now, it is 2.2M requests, and 174MB memory is in use.
[Issue 14558] Attempts to link with DMD when using MSVC LDC under VisualD
https://issues.dlang.org/show_bug.cgi?id=14558 --- Comment #3 from Rainer Schuetze r.sagita...@gmx.de --- It's LDC that is calling lib.exe, so probably the best Visual D can do is to add the path to the VC bin folder to the Executable Paths by default. For the mingw version of LDC, it cannot guess the path to the respective bin folder, though. --
Cannot find -lphobos
I works just fine on Windows, but I am having difficulty figuring out what the trouble is on my Bodhi 1.4 Virtual Box. I've followed the instruction on the Codeblocks Wiki and set the parameters, but when I try to compile, it complains that it can't find Phobos. /usr/bin/ld: cannot find -lphobos2 I've checked the search directories and the library directories are where it says they would be. I am not particularly familiar with Linux so I am not sure how to proceed from here. Any advice?
Re: Tuple assignment
On Sun, 2015-05-10 at 08:14 +, Oren Tirosh via Digitalmars-d wrote: On Saturday, 9 May 2015 at 17:16:58 UTC, Russel Winder wrote: […] TypeTuple!(current, next) = tuple(next , current +next); This works. This works right now and is quite aesthetically pleasing: tuple(current, next) = tuple(next , current +next); This does not. At least the tests fail with this where they do not with the previous. […] -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: std.xml2 (collecting features)
Am Sat, 09 May 2015 10:28:52 + schrieb Joakim dl...@joakim.fea.st: On Monday, 4 May 2015 at 18:50:43 UTC, Marco Leise wrote: You two are terrible at motivating people. Better D doesn't support it well and JSON is superior through-and-through is overly dismissive. … You seem to have missed the point of my post, which was to discourage him from working on an XML module for phobos. As for motivating him, I suggested better alternatives. And I never said JSON was great, but it's certainly _much_ more readable than XML, which is one of the basic goals of a text format. Well, I was mostly answering to w0rp here. JSON is both readable and easy to parse, no question. Remember that while JSON is simpler, XML is not just a structured container for bool, Number and String data. It comes with many official side kicks covering a broad range of use cases: XPath: … XSL and XSLT … XSL-FO (XSL formatting objects): … XML Schema Definition (XSD): … These are all incredibly dumb ideas. I don't deny that many people may use these things, but then people use hammers for all kinds of things they shouldn't use them for too. :) :) One can't really answer this one. But with many hundreds of published data exchange formats built on XML, it can't have been too shabby all along. And sometimes small things matter, like being able to add comments along with the payload. JSON doesn't have that. Or knowing that both sender and receiver will validate the XML the same way through XSD. So if it doesn't blow up on your end, it will pass validation on the other end, too. Am Sat, 09 May 2015 13:04:57 + schrieb Craig Dillabaugh craig.dillaba...@gmail.com: I have to agree with Joakim on this. Having spent much of this past week trying to get XML generated by gSOAP (project has some legacy code) to work with JAXB (Java) has reinforced my dislike for XML. I've used things like XPath and XLST in the past, so I can appreciate their power, but think the 'jobs' they perform would be better supported elsewhere (ie. language specific XML frameworks). In trying to pass data between applications I just want a simple way of packaging up the data and ideally making serialization/deserialization easy for me. At some point the programmer working on these needs to understand and validate the data anyway. Sure you can use DTD/XML Schema to handle the validation part, but it is just easier to deal with that within you own code - without having to learn a 'whole new language', that is likely harder to grok than the tools you would have at your disposal in your language of choice. You see, the thing is that XSD is _not_ a whole new language, it is written in XML as well, probably specifically to make it so. Try to switch the perspective: With XSD (if it is sufficient for your validation needs) _one_ person needs to learn and write it and other programmers (inside or outside the company) just use the XML library of choice to handle validation via that schema. Once the schema is loaded it is usually no more than doc.validate(); (There is also good GUI tools to assist in writing XSD.) What you propose on the other hand is that everyone involved in the data exchange writes their own validation code in their language of choice, with either no access to existing sources or functionality that doesn't translate to their language! -- Marco
[Issue 14565] dmd -profile produces garbled output for long-running CPU-intensive processes
https://issues.dlang.org/show_bug.cgi?id=14565 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Component|DMD |druntime --- Comment #1 from Walter Bright bugzi...@digitalmars.com --- https://github.com/D-Programming-Language/druntime/pull/1261 --
Re: Tuple assignment
On Sat, 2015-05-09 at 13:07 -0700, Walter Bright via Digitalmars-d wrote: […] It probably depends on the compiler. The way to find out is to look at the generated assembler. pedant-modeassembly language file, not assembler (which is the program to do the transformation)/pedant-mode ldc2 and gdc have options to write the assembly language file, maybe I am missing it but dmd appears not to advertise such an option. Tuples are implemented as structs. I know that ldc is capable of slicing structs into register-sized pieces and optimizing them independently, dmd does not. So ldc would very possibly generate the kind of code for that that you'd like. I shall investigate with gdc as well as ldc. Though, sadly, whilst gdc is in Debian it is not in Fedora. :-( -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Breaking changes in Visual C++ 2015
On Saturday, 9 May 2015 at 00:24:45 UTC, Andrei Alexandrescu
wrote:
The issues with unittests are legit, albeit fixable. It's goofy
to run the program after unittests, and unittests should have
names that can be introspected, selected etc. I couldn't find
much merit with the rest of the list. -- Andrei
Those are really the only ones that I've ever thought made sense,
and in several cases, the things that folks want are things that
I very much _don't_ want (e.g. continuing to execute a unittest
block after an assertion failure). However, while it _is_ a bit
goofy that the unit tests run just prior to the program running,
it's easy enough to work around that I've never considered it a
big deal. Maybe the solution would be to simply make it so that
main gets replaced when you compile with -unittest rather than
forcing you to do something like
version(unittest) void main() {}
else void main()
{
...
}
It's the lack of unit test names that poses a potentially big
problem for large projects. But even that shouldn't be hard to
fix - especially when unittest blocks are already functions with
names to begin with; it's just that you can't name them yourself.
But at least their names have their line number in them now. That
didn't used to be the case, which was even worse - though I'm
willing to bet that most folks don't realize that the unittest
block's line number is in its function name.
- Jonathan M Davis
Re: New adapter: std.allocator.quantizer
On 5/10/15 12:52 AM, Marco Leise wrote: * zeroesAllocations I called it elementsAreInited and as the name suggests, it tells whether new elements receive their T.init automatically. Now std.allocator deals mostly with raw memory, so zeroing is the only option, but I can see some friction coming up when typed allocators are built on those. Typed allocators backed by a zeroesAllocations allocator could overwrite the memory 3 times: zeroing, T.init, ctor assignments. a) Could the parent allocator be informed that it does not need to zero initialize because we will blit T.init over the memory anyways? b) If we get zeroed memory, can the typed allocator know at compile-time that T.init is all zeroes and elide the blit? Yah, about that... I introduced this property as an OS interface courtesy - there are functions that already zero memory so it's wasteful to zero it again if that's all that's needed. Sadly I found little if any interesting properties of this, and for anything that's not zero there's no gain - either the allocator does it or emplace() etc. does. Long story short is I'm considering just dropping that. * roundingFunction This is like a growth function, right? I often have some default lying around, but it is sure good to be able to provide your own. My default is: n' = n + (n 1) + 4 One thing that could go wrong is that on 32-bit you pick a new size like n'=2*n and you just don't find enough contiguous virtual memory. a) On allocation failure the growth function is ignored and the minimal required size used. b) The growth function needs to be designed more carefully, putting the effort on the user. This is not growth. Growth is I have an array of size n and plan to append an unspecified number of elements to it, what's a good function that takes n and gives me a larger number? Quantization is different. What's happening here is you're reducing a large set of integer to a smaller number of quantas. That way you are overallocating (so indeed growth properties are nicer) but also reducing the total set of distinct sizes that the allocator needs to deal with. Andrei
Memory usage tracking
I am testing my web server right now. I started 5 separate consoles and continuously sending request by using curl to it. It uses shared memory as well, thought from `ipcs -a`, I don't see more than necessary amount of allocation. At the moment, server received about 1.5M requests, and memory usage has reached to 128MB according to System Monitor of Ubuntu. (top gives a similar value as well). I saw now on `top` command that about 650KB shared memory is used only. Is there any way to find out what is using that big space in memory? Would `-profile` do that? Problem is that if I was to be using `-profile` flag, server would slow down, and I wouldn't be able to test it correctly already.
[Issue 14564] dmd -property -unittest combination causes compiler error
https://issues.dlang.org/show_bug.cgi?id=14564 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com Severity|normal |regression --- Comment #2 from ag0ae...@gmail.com --- (In reply to Lucas Burson from comment #1) I forgot to note that the arg combination compiles using the previous version of dmd v2.066.1, and failure in v2.067.1. Making this a regression. --
[Issue 14552] [REG2.066] SIGSEGV with compile construction nested class in predicate
https://issues.dlang.org/show_bug.cgi?id=14552 Martin Krejcirik m...@krej.cz changed: What|Removed |Added Hardware|x86_64 |All --
Re: Memory usage tracking
On Sunday, 10 May 2015 at 10:43:37 UTC, tcak wrote: On Sunday, 10 May 2015 at 09:44:42 UTC, tcak wrote: I am testing my web server right now. I started 5 separate consoles and continuously sending request by using curl to it. It uses shared memory as well, thought from `ipcs -a`, I don't see more than necessary amount of allocation. At the moment, server received about 1.5M requests, and memory usage has reached to 128MB according to System Monitor of Ubuntu. (top gives a similar value as well). I saw now on `top` command that about 650KB shared memory is used only. Is there any way to find out what is using that big space in memory? Would `-profile` do that? Problem is that if I was to be using `-profile` flag, server would slow down, and I wouldn't be able to test it correctly already. Hmm. Server was compiled in debug mode. Right now, it is 2.2M requests, and 174MB memory is in use. Which compiler are you using? Also, debug mode might have linked against debug phobos - do a ldd on your executable.
Re: A few thoughts on std.allocator
On 2015-05-10 09:50:00 +, Andrei Alexandrescu seewebsiteforem...@erdani.org said: 3. Thread-local vs. shared objects Currently in D it's legal to allocate memory in one thread and deallocate it in another. (One simple way to look at it is casting to shared.) This has a large performance cost that only benefits very few actual cases. It follows that we need to change the notion that you first allocate memory and then brand it as shared. The will be shared knowledge must be present during allocation, and use different methods of allocation for the two cases. Shared is implicit in the case of immutable. Think carefully: if you implement this and it has any efficiency benefit for non-shared allocations, const-allocated objects and arrays will become more performant than immutable-allocated ones. People will thus have an incentive to stay away from immutable. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: Memory usage tracking
On Sunday, 10 May 2015 at 10:50:40 UTC, weaselcat wrote: On Sunday, 10 May 2015 at 10:43:37 UTC, tcak wrote: On Sunday, 10 May 2015 at 09:44:42 UTC, tcak wrote: I am testing my web server right now. I started 5 separate consoles and continuously sending request by using curl to it. It uses shared memory as well, thought from `ipcs -a`, I don't see more than necessary amount of allocation. At the moment, server received about 1.5M requests, and memory usage has reached to 128MB according to System Monitor of Ubuntu. (top gives a similar value as well). I saw now on `top` command that about 650KB shared memory is used only. Is there any way to find out what is using that big space in memory? Would `-profile` do that? Problem is that if I was to be using `-profile` flag, server would slow down, and I wouldn't be able to test it correctly already. Hmm. Server was compiled in debug mode. Right now, it is 2.2M requests, and 174MB memory is in use. Which compiler are you using? Also, debug mode might have linked against debug phobos - do a ldd on your executable. I am using DMD. Web server is running as daemon, but web application is being debugged with gdb. For a while, gdb has started using 100% of CPU, and request-response slowed down greatly. 2.22M requests it has reached. It should end at 2.5M requests. Then I will check whether memory usage will go down by itself. ldd result is this. linux-vdso.so.1 = (0x7ffc6192c000) libmysqlclient.so.18 = /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18 (0x7ff6ecde4000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7ff6ecbc6000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7ff6ec9bd000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7ff6ec5f8000) /lib64/ld-linux-x86-64.so.2 (0x7ff6ed346000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7ff6ec3df000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7ff6ec1da000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7ff6ebed4000) I am guessing a request object is having a instance copy somewhere, and GC is not destroying it, but I am not sure. Would I be able to find out about very long alive objects?
[Issue 14554] [REG2.066] dmd generate wrong error message for multiple template with same name
https://issues.dlang.org/show_bug.cgi?id=14554 Martin Krejcirik m...@krej.cz changed: What|Removed |Added Summary|dmd generate wrong error|[REG2.066] dmd generate |message for multiple|wrong error message for |template with same name |multiple template with same ||name --
[Issue 14566] [2.067] core.demangle: New Nj attribute not handled
https://issues.dlang.org/show_bug.cgi?id=14566 Iain Buclaw ibuc...@gdcproject.org changed: What|Removed |Added Component|DMD |druntime --
[Issue 14567] New: [2.067] core.demangle: New Nk attribute not handled
https://issues.dlang.org/show_bug.cgi?id=14567 Issue ID: 14567 Summary: [2.067] core.demangle: New Nk attribute not handled Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: ibuc...@gdcproject.org Same as in #14566 - but this is for the Nk attribute, which is for when return is used as a property. --
Re: New adapter: std.allocator.quantizer
Am Thu, 07 May 2015 14:12:40 -0700 schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: Helps an allocator without good reallocation capabilities: http://erdani.com/d/phobos-prerelease/std_experimental_allocator_quantizer.html Destruction welcome. Andrei I haven't tested it, but it seems useful for the cases you listed in the documentation. While writing dynamic arrays I remember I had some thoughts about features you used as well: * zeroesAllocations I called it elementsAreInited and as the name suggests, it tells whether new elements receive their T.init automatically. Now std.allocator deals mostly with raw memory, so zeroing is the only option, but I can see some friction coming up when typed allocators are built on those. Typed allocators backed by a zeroesAllocations allocator could overwrite the memory 3 times: zeroing, T.init, ctor assignments. a) Could the parent allocator be informed that it does not need to zero initialize because we will blit T.init over the memory anyways? b) If we get zeroed memory, can the typed allocator know at compile-time that T.init is all zeroes and elide the blit? * roundingFunction This is like a growth function, right? I often have some default lying around, but it is sure good to be able to provide your own. My default is: n' = n + (n 1) + 4 One thing that could go wrong is that on 32-bit you pick a new size like n'=2*n and you just don't find enough contiguous virtual memory. a) On allocation failure the growth function is ignored and the minimal required size used. b) The growth function needs to be designed more carefully, putting the effort on the user. -- Marco
Re: mscoff x86 invalid pointers
On Sunday, 10 May 2015 at 04:16:45 UTC, Etienne Cimon wrote: On 2015-05-09 05:44, Baz wrote: On Saturday, 9 May 2015 at 06:21:11 UTC, extrawurst wrote: On Saturday, 9 May 2015 at 00:16:28 UTC, Etienne wrote: I'm trying to compile a library that I think used to work with -m32mscoff flag before I reset my machine configurations. https://github.com/etcimon/memutils Whenever I run `dub test --config=32mscoff` it gives me an assertion failure, which is a global variable that already has a pointer value for some reason.. I'm wondering if someone here could test this out on their machine with v2.067.1? There's no reason why this shouldn't work, it runs fine in DMD32/optlink and DMD64/mscoff, just not in DMD32/mscoff. Thanks! you can always use travis-ci to do such a job for you ;) doesn't -m32mscoff recquire phobos to be compiled as COFF too ? I think that travis uses the official releases (win32 releases have phobos as OMF) so he can't run the unittests like that... The dark side of the story is that you have to recompile phobos by hand with -m32mscoff...I'm not even sure that there is a option for this in the win32.mak... Meh, I ended up upgrading to 2.068 and everything went well. I clearly remember 2.067.1 working but spent a whole day recompiling druntime/phobos COFF versions in every configuration possible and never got it working again Could you tell me the way to compile druntime phobos 32bit COFF ? Would you have some custom win32.mak to share ? Thx.
Re: Tuple assignment
On Saturday, 9 May 2015 at 20:07:00 UTC, Walter Bright wrote: It probably depends on the compiler. The way to find out is to look at the generated assembler. fwiw, I tried to look at this earlier and found out a single tuple generates too much assembly for asm.dlang.org to display ;)
Re: Spawning a console in Windows (similar to forkpty on linux)
On Saturday, 9 May 2015 at 13:00:01 UTC, wobbles wrote: Just as an example of running cmd through std.process, running this on my system: auto pipes = pipeShell(cmd.exe); write(pipes.stdout.readln); write(pipes.stdout.readln); write(pipes.stdout.readln); return; will print ` Microsoft Windows [Version 6.3.9600] (c) 2013 Microsoft Corporation. All rights reserved. ` and then exits. However, adding another write line before the return; will cause the program to hang there, waiting for the cmd.exe process to flush it's next line. I guess, the last (prompt) line is properly flushed, it just doesn't have EOL, that's why readln won't return it. See if stdout has a method to read/peek whatever data it has without waiting for EOL.
Re: Tuple assignment
On Saturday, 9 May 2015 at 17:16:58 UTC, Russel Winder wrote: Python has tuple assignment so you see things like: previous, current = current, previous + current especially if you are doing silly things like calculating Fibonacci Sequence values. Translating this to D, you end up with: TypeTuple!(current, next) = tuple(next , current +next); This works right now and is quite aesthetically pleasing: tuple(current, next) = tuple(next , current +next); Note, however, that this is not a tuple assignment. It is assignment of a misleadingly-named anonymous struct type that is implemented in the standard library. This is an actual tuple assignment as supported by the compiler: a.tupleof = b.tupleof; I think it should work for any two structs as long their fields are public and individually assignment-compatible. I believe it is as efficient as individual assignments on all D implementations. A lot of people seem to want better sugar for tuple or tuple-like things in D and do not consider std.typecons sufficient (or at least find the names it uses confusing). Such a feature would work very nicely with D's auto types, return and lambda argument type inference, etc. See LINQ.
Re: Header Files
Am Sat, 09 May 2015 10:01:25 -0400 schrieb bitwise bitwise@gmail.com: ./main.d ./pack/foo.d ./pack/sub/bar.d dmd main.d pack/foo.d pack/sub/bar.d -ofTest -H This dumps all the *.di files into the output directory ignoring the directory structure. Is there some rational for it being this way? Wouldn't it be much more useful if directories were preserved? Bit I agree, D modules are hierarchical and sometimes share the same base name. Header files are very important to short circuit the transitive import chain. We've already seen it in Phobos. Many modules ends up pulling in most of Phobos, and those are library modules. Now imagine there was an operating system like Linux/GNU with all libraries written in D and no .di files: The program entry point in a project the size of OpenOffice would pull in so many imports that no super computer in the world could compile it given CTFE memory use: all of the project files, font library, math library, image library, entire GUI toolkit, Java binding, accessibility library, RPC library, configuration library, OpenGL, audio, GhostScript and PDF, Python, XML, MS Office file type readers, ICU, SSL, Phobos, X11 or similar, color management, printing, zip, databases, ... We often shun .di files, thinking of them as C++ relics, but the big difference is that we don't write them. The compiler generates them and they are still a key to a successful eco-system with huge projects, just the way they are in C/C++. One thing I'm missing is a way to tell the compiler or a build tool which symbols or modules are part of the library API. There is no sense in generating an internal.di and similar files that are never supposed to be used by the outside. (They'd also be listed unnecessarily in import auto-completions of Mono-D and similar IDEs.) -- Marco
Re: Spawning a console in Windows (similar to forkpty on linux)
On Saturday, 9 May 2015 at 13:00:01 UTC, wobbles wrote: My windows knowledge isnt marvelous, but I believe I'll need the interpreter attached. If you only need the interpreter, pipeProcess should be fine, it's a normal program like anything else, just interactive.
Re: Tuple assignment
On Sunday, 10 May 2015 at 08:28:24 UTC, Russel Winder wrote: On Sun, 2015-05-10 at 08:14 +, Oren Tirosh via Digitalmars-d wrote: On Saturday, 9 May 2015 at 17:16:58 UTC, Russel Winder wrote: […] TypeTuple!(current, next) = tuple(next , current +next); This works. I did not mean imply that it doesn't, just that what I wrote is not some proposed syntax for tuple assignment but something that actually works now. This works right now and is quite aesthetically pleasing: tuple(current, next) = tuple(next , current +next); This does not. At least the tests fail with this where they do not with the previous. Works for me. If this is version or compiler dependent this definitely needs investigation.
A few thoughts on std.allocator
In C, C++, and D people have allocated memory for a long time in the following manner: 1. Allocate as many bytes as needed (e.g. by using malloc); 2. Mess with the memory allocated. (C++ took this one step further by defining class-specific allocators, feature that D copied. That turned out to be little else than a lateral step. C++ also offers distinct allocation for arrays vs. anything else, but because it lacks typed reallocation primitives, it effectively hamstrung that feature's capabilities. Also the STL introduced allocators, which turned out to not do much of anything useful except being an immense time sink for everyone involved with them in any capacity. I call these cumulatively The Big Distraction.) I've just had a mini-epiphany that's been buzzing around my head for a while. Finally it got to a form expressible in words: Type should inform allocation. I.e. you shouldn't first allocate and then brand the memory with a type. Instead, you should make the type known _during_ the allocation process. This is not new and on the face of it not even all that noteworthy: (a) some high-level languages did this for years, (b) it's unclear which exact properties of a type should be relevant to the allocation. Within the context of D, there are some interesting aspects of a type that a complex modular allocator could use to great effect. Consider: 1. Individual objects (i.e. not arrays) When allocating an individual object, there is virtually zero chance that object will ever need to be resized. (There are exceptions such as the struct hack but those would be handled together with arrays.) There are two important consequences of this: (a) Individual object sizes are already quantized, i.e. there is a relatively small set of distinct sizes compared to the number of objects being allocated. (b) Individual objects can be placed in an allocator that's arbitrarily adverse to reallocation (i.e. has no in-place expansion ability and no clever reallocation primitives). It seems like FreeTree (file:///Users/aalexandre/code/d/dlang.org/web/phobos-prerelease/std_experimental_allocator_free_tree.html) would be an excellent fit for allocating individual objects. HeapBlock also comes to mind. 2. Arrays The range of sizes allocated for arrays is quite a bit larger and more arbitrary than for individual objects. Arrays still grow in quanta (e.g. T.sizeof hops) but the set of distinct sizes is much larger and much less predictable. One other interesting thing is that arrays offer concatenation and resizing as primitive operations, so it follows that their underlying allocator should be friendly to such. This leads to an allocator design for arrays that's radically different from the allocator design for individual objects. Long story short, arrays should sit on a different heap than objects. 3. Thread-local vs. shared objects Currently in D it's legal to allocate memory in one thread and deallocate it in another. (One simple way to look at it is casting to shared.) This has a large performance cost that only benefits very few actual cases. It follows that we need to change the notion that you first allocate memory and then brand it as shared. The will be shared knowledge must be present during allocation, and use different methods of allocation for the two cases. 4. Has pointers vs. has no pointers When collecting a specific object, it's important to know whether its type embeds pointers. If it does, more scanning is necessary. Otherwise, the object is a leaf leading to no others. It seems to me we stand to gain by physically and conceptually separating memory that stores leaf objects from that dedicated to non-leaf objects. Making the scan-heavy memory more compact leads to better cache friendliness. Currently D's allocator allows choosing at runtime for each allocated block whether is should be scanned. The new design would require making the choice upfront. There would be, of course, the anything goes heap that still allows that level of dynamism. 5. Plan to deallocate vs. plan to let the GC mind this Objects that will be deallocated manually deserve different placement compared to those that will only be deallocated during a GC cycle. 6. Immutable vs. mutable I'm not sure how this can be practically exploited. There must be something in the notion that, save for a brief write period after allocation, the memory will stay unmodified. Still thinking. 7. Strings On the face of it strings are immutable arrays, so they've been already discussed. However, they have some interesting characteristics: (a) small alignment, e.g. 1 byte (b) often extremely short, e.g. 1-8 bytes (c) concatenation intensive (including append) (d) perhaps other unique properties and patterns that elude me So... types should inform allocation. Please chime in! Andrei
Re: A few thoughts on std.allocator
On Sunday, 10 May 2015 at 09:50:00 UTC, Andrei Alexandrescu wrote: (file:///Users/aalexandre/code/d/dlang.org/web/phobos-prerelease/std_experimental_allocator_free_tree.html) bad link
[Issue 14552] [REG2.066] SIGSEGV with compile construction nested class in predicate
https://issues.dlang.org/show_bug.cgi?id=14552 Martin Krejcirik m...@krej.cz changed: What|Removed |Added Summary|SIGSEGV with compile|[REG2.066] SIGSEGV with |construction nested class |compile construction nested |in predicate|class in predicate --
[Issue 14566] [2.067] core.demangle: New Nj attribute not handled
https://issues.dlang.org/show_bug.cgi?id=14566 Iain Buclaw ibuc...@gdcproject.org changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #1 from Iain Buclaw ibuc...@gdcproject.org --- Ah, my bad, it's new for the -dip25 switch. Still, it needs to be handled. --
Re: A few thoughts on std.allocator
On Sunday, 10 May 2015 at 10:51:54 UTC, Michel Fortin wrote: On 2015-05-10 09:50:00 +, Andrei Alexandrescu seewebsiteforem...@erdani.org said: 3. Thread-local vs. shared objects Currently in D it's legal to allocate memory in one thread and deallocate it in another. (One simple way to look at it is casting to shared.) This has a large performance cost that only benefits very few actual cases. It follows that we need to change the notion that you first allocate memory and then brand it as shared. The will be shared knowledge must be present during allocation, and use different methods of allocation for the two cases. Shared is implicit in the case of immutable. Think carefully: if you implement this and it has any efficiency benefit for non-shared allocations, const-allocated objects and arrays will become more performant than immutable-allocated ones. People will thus have an incentive to stay away from immutable. If immutable does not pull its weight in other ways, it's just not worth it.
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
On Sunday, 10 May 2015 at 01:55:53 UTC, Mike wrote: On Thursday, 7 May 2015 at 14:48:08 UTC, Jens Bauer wrote: I already have supplied those options in my toolchain. But does anyone know if this is advisable when using FreeRTOS (or any other RTOS for that matter) ? -I'm asking, because I'm not using any RTOS myself, but there are loads of people who do. In order to make the full stack in D, I think we eventually will need to make 2 toolchains: a bare-metal kernel toolchain, and an application programming toolchain. That does not sound too appealing, because as far as I know, you have your bare-metal arm-none-eabi toolchain with C and C++, which can build RTOS. Then you'll need another arm-rtos-eabi, which can build RTOS, but cannot build bare-metal. I think people will not like this, because they don't want to switch toolchains when they work on different projects. The arm-linux-eabi toolchain will be a third toolchain, because RTOS is not Linux, though Linux may be some kind of RTOS. ;) The bare-metal kernel toolchain would not have some of the high-level features of D, like threading and synchronization, as that has yet to be built. However, once a D RTOS is created with all necessary features for theading and synchronization, then the application programming toolchain can be made with a druntime ported the D RTOS's API. Another (annoying) input: If I decide to write a context-switcher in assembly language, I suddenly have threads, which I'd of course like to be able to use with my bare-metal toolchain. I've also considered another interesting approach. It seems possible to port all features of D right to the metal, essentially embedding the RTOS directly into the runtime. Then D is your RTOS :-) I do like this approach better, and that resembles the way I've been thinking until now. Yes, it might require more work, but strongly I think it's worth it. I believe this would also give the user the most convenient D-compiler (and toolchain).
[Issue 14565] dmd -profile produces garbled output for long-running CPU-intensive processes
https://issues.dlang.org/show_bug.cgi?id=14565 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com Hardware|x86_64 |All OS|Linux |All Severity|enhancement |normal --
Re: Bug or feature?
On 05/10/2015 10:18 AM, Jack Applegame wrote:
code:
class A {
void test(int) {}
}
class B : A {
void test() {
super.test(1); // compiles
test(10); // error
}
}
Error: function B.test () is not callable using argument types (int)
It is a concept called name hiding. It is intentional to prevent at
least function hijacking.
Ali
Re: Bug or feature?
On Sunday, May 10, 2015 10:48:33 Ali Çehreli via Digitalmars-d-learn wrote:
On 05/10/2015 10:18 AM, Jack Applegame wrote:
code:
class A {
void test(int) {}
}
class B : A {
void test() {
super.test(1); // compiles
test(10); // error
}
}
Error: function B.test () is not callable using argument types (int)
It is a concept called name hiding. It is intentional to prevent at
least function hijacking.
Yeah. You have to alias A's overloads inside of B or explicitly declare them
as overrides and call the A versions from inside them. So, something like
alias A.test test;
or
alias test = A.test;
inside of B should work (though I haven't done it recently, so the syntax
might be slightly off), or you can just do
override void test(int i) { super.test(i); }
- Jonathan M Davis
Re: Bug or feature?
Jack Applegame wrote:
test(10); // error
One can import the declaration by using an alias:
class A {
void test(int) {}
}
class B : A {
alias test= super.test;
void test() {
super.test(1); // compiles
test(10); // compiles
}
}
-manfred
[Issue 14558] Attempts to link with DMD when using MSVC LDC under VisualD
https://issues.dlang.org/show_bug.cgi?id=14558 --- Comment #7 from Rainer Schuetze r.sagita...@gmx.de --- I can't imagine a situation where I don't care about the runtime in my work :/ If you don't build a large application, but just a small command line tool that you don't want to distribute, why bother? But sure, in the cases where you want to use MinGW, would you typically reach for GDC or LDC though? GDC seems more natural, but LDC appears to be more up-to-date with latest dmd. Actually, I don't like all the dependencies that you get with MinGW. Every program seems to need a different version... --
Re: A few thoughts on std.allocator
On 5/10/15 3:15 AM, anonymous wrote: On Sunday, 10 May 2015 at 09:50:00 UTC, Andrei Alexandrescu wrote: (file:///Users/aalexandre/code/d/dlang.org/web/phobos-prerelease/std_experimental_allocator_free_tree.html) bad link Pardon: erdani.com/d/phobos-prerelease/std_experimental_allocator_free_tree.html -- Andrei
Re: A few thoughts on std.allocator
On 5/10/15 3:51 AM, Michel Fortin wrote: Shared is implicit in the case of immutable. Think carefully: if you implement this and it has any efficiency benefit for non-shared allocations, const-allocated objects and arrays will become more performant than immutable-allocated ones. People will thus have an incentive to stay away from immutable. Good point. Well I'd say if things turn out that way, we shouldn't pessimize one case just to keep it aligned with another. There might be optimization opportunities particular to immutable data. -- Andrei
Re: New adapter: std.allocator.quantizer
On 5/10/15 4:48 AM, Timon Gehr wrote: Yes, but 'expand' expects a _full_ block that was allocated by that allocator: Ah, now I understand. Thanks, will fix! -- Andrei
Re: DOtherSide: QML bindings for both D and Nim
Hi everyone, just a quick update Today i've just released the version 0.4.1 that add a nicer syntax for generating the boilerplate code for handling signals and slots. For sure there're thousand of bugs but i you wanna git it i try i'll be glad :D Given that, the new features i add since the last update are: - Handling of QAbstractListModel - Nicer syntax Have a nice day, F.
Re: New adapter: std.allocator.quantizer
On 5/10/15 5:02 AM, Timon Gehr wrote:
size_t brokenRoundingFunction(size_t siz){
if(siz==10) return 40;
if(siz==20) return 30;
return siz;
}
Say no more, got it. I'll change the docs. -- Andrei
Re: Sneak preview into std.allocator's porcelain
On 2015-05-08 21:55, Andrei Alexandrescu wrote: a few measurements would be in order. -- Andrei Be sure you do that on more than one platform. For example, the emulate TLS on OS X can be quite slow, I've heard. -- /Jacob Carlborg
Re: New adapter: std.allocator.quantizer
On 5/10/15 5:08 AM, Timon Gehr wrote: On 05/10/2015 01:48 PM, Timon Gehr wrote: bool expand(ref void[] b, size_t delta); Post: !result || b.length == old(b).length + delta Expands b by delta bytes. If delta == 0, succeeds without changing b. If b is null, the call evaluates b = allocate(delta) and returns b !is null. Otherwise, *b must be a buffer previously allocated with the same allocator*. If expansion was successful, expand changes b's length to b.length + delta and returns true. Upon failure, the call effects no change upon the allocator object, leaves b unchanged, and returns false. Actually, reading that snippet of the documentation, I notice more problems in the implementation of expand/the documentation of the rounding function. If the rounding function returns a non-zero result for a zero argument, expand can return invalid memory (starting from address 0) if given an empty block 'b'. Will fix. -- Andrei
Bug or feature?
code:
class A {
void test(int) {}
}
class B : A {
void test() {
super.test(1); // compiles
test(10); // error
}
}
Error: function B.test () is not callable using argument types
(int)
[Issue 14561] Large enums cannot be parsed due to too many recursive template expansions
https://issues.dlang.org/show_bug.cgi?id=14561 Simen Kjaeraas simen.kja...@gmail.com changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #2 from Simen Kjaeraas simen.kja...@gmail.com --- (In reply to yebblies from comment #1) I've hit this same issue, and considered posting about it on that pull request. But I'm pretty sure the real problem here is that EnumMembers instantiates with the list[1..$] pattern when it has other options. EnumMembers is one problem, and is easily solved with divide-and-conquer, as used in staticMap, allSatisfy and a few other functions in std.typetuple. The problem is NoDuplicates. EraseAll (called by NoDuplicates) can also be divided and conquered, but I see no way to make NoDuplicates anything other than O(N). It could test for the first ten elements instead of just the first one, thus effectively increasing the max list size by a factor of 10, but then people will come asking why we don't support enums of 5000+ elements. --
Re: Cannot find -lphobos
On 05/10/2015 12:45 AM, Marko Grdinic wrote: I works just fine on Windows, but I am having difficulty figuring out what the trouble is on my Bodhi 1.4 Virtual Box. I've followed the instruction on the Codeblocks Wiki and set the parameters, but when I try to compile, it complains that it can't find Phobos. /usr/bin/ld: cannot find -lphobos2 I've checked the search directories and the library directories are where it says they would be. I am not particularly familiar with Linux so I am not sure how to proceed from here. Any advice? dmd's -v flag may give some clues: $ dmd foo.d -v dmd outputs the config file that it uses and the linker flags that it passes. Ali
[Issue 14558] Attempts to link with DMD when using MSVC LDC under VisualD
https://issues.dlang.org/show_bug.cgi?id=14558 --- Comment #5 from Rainer Schuetze r.sagita...@gmx.de --- Oh okay. Will adding it to the Executable Paths cause it to take precedence over other paths already in $PATH? Yes, it is prepended to PATH. MinGW LDC is probably of fairly limited use... I imagine more MinGW users would want to use GDC? Seems more conventional to me. If you don't care about the runtime, MinGW seems your best bet on Win32. --
Re: Cannot find -lphobos
On Sunday, 10 May 2015 at 14:41:17 UTC, Ali Çehreli wrote: On 05/10/2015 12:45 AM, Marko Grdinic wrote: I works just fine on Windows, but I am having difficulty figuring out what the trouble is on my Bodhi 1.4 Virtual Box. I've followed the instruction on the Codeblocks Wiki and set the parameters, but when I try to compile, it complains that it can't find Phobos. /usr/bin/ld: cannot find -lphobos2 I've checked the search directories and the library directories are where it says they would be. I am not particularly familiar with Linux so I am not sure how to proceed from here. Any advice? dmd's -v flag may give some clues: $ dmd foo.d -v dmd outputs the config file that it uses and the linker flags that it passes. Ali additionally if not using dmd it may have the libraries named differently. a quick google says Bodhi linux is based on Ubuntu which doesn't ship dmd due to licensing issues AFAIK.
DWT 64bit support
I would like to announce that DWT recently got support for 64bit, both on Linux and Windows. Compiling for 32bit COFF should also work on Windows. All this work was done by kntroh and Jesse Phillips, thank you very much. -- /Jacob Carlborg
Re: Header Files
On Sunday, 10 May 2015 at 01:00:31 UTC, bitwise wrote: Is there really no way to preserve the directory structure when creating .di files? Bit Why hello, Bitwise! I believe the '-op' flag is what you're looking for! Bitwiser
Object.factory fails for nested classes ?!
Is it a bug or just missing specification that using Object.factory(fullyQualifiedNameToNestedClass) fails ? See repro here: http://dpaste.dzfl.pl/d789237b0f46 Regards, Stephan
Re: Header Files
On Sun, 10 May 2015 04:20:45 -0400, Marco Leise marco.le...@gmx.de wrote: I agree, D modules are hierarchical and sometimes share the same base name. Header files are very important to short circuit the transitive import chain. We've already seen it in Phobos. Many modules ends up pulling in most of Phobos, and those are library modules. Now imagine there was an operating system like Linux/GNU with all libraries written in D and no .di files: The program entry point in a project the size of OpenOffice would pull in so many imports that no super computer in the world could compile it given CTFE memory use: all of the project files, font library, math library, image library, entire GUI toolkit, Java binding, accessibility library, RPC library, configuration library, OpenGL, audio, GhostScript and PDF, Python, XML, MS Office file type readers, ICU, SSL, Phobos, X11 or similar, color management, printing, zip, databases, ... We often shun .di files, thinking of them as C++ relics, but the big difference is that we don't write them. The compiler generates them and they are still a key to a successful eco-system with huge projects, just the way they are in C/C++. One thing I'm missing is a way to tell the compiler or a build tool which symbols or modules are part of the library API. There is no sense in generating an internal.di and similar files that are never supposed to be used by the outside. (They'd also be listed unnecessarily in import auto-completions of Mono-D and similar IDEs.) I'm not sure I understand what you're trying to say. Bit
Re: std.xml2 (collecting features)
On Sunday, 10 May 2015 at 07:01:58 UTC, Marco Leise wrote: Well, I was mostly answering to w0rp here. JSON is both readable and easy to parse, no question. JSON is just javascript literals with some silly constraints. As crappy a format as it gets. Even pure Lisp would have been better. And much more powerful! :) One can't really answer this one. But with many hundreds of published data exchange formats built on XML, it can't have been too shabby all along. And sometimes small things matter, like being able to add comments along with the payload. XML is actually great for what it is: eXtensible. It means you can build forward compatible formats and annotate existing formats with metadata without breaking existing (compliant) applications etc... It also means you can datamine files whithout knowing the full format. Or knowing that both sender and receiver will validate the XML the same way through XSD. Right, or build a database/archival service that is generic. XML is not going away until there is something better, and that won't happen anytime soon. It is also one of the few formats that I actually need library and _good_ DOM support for. (JSON can be done in an afternoon, so I don't care if it is supported or not...)
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #11 from Rainer Schuetze r.sagita...@gmx.de --- Oh yeah, and the other thing was that every time I hit Compile and Disassemble, it prompts me if I want to reload the file. That's a bit annoying. Yeah, I noticed that, too, though it does not seem to happen every time. I'll have to figure out how to avoid that... I think I've solved this, see https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.41-beta4 --
Re: OS X support
On 2015-05-08 22:37, FreeSlave wrote: OS X support added. It dynamically loads some Carbon functions. But path to the framework is hardcoded as /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore I'm not sure that it's ok, need advice from OS X programmers. The documentation [1] recommends using URLsForDirectory:inDomains:, but that is an Objective-C method. [1] https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/AccessingFilesandDirectories/AccessingFilesandDirectories.html#//apple_ref/doc/uid/TP40010672-CH3-SW1 -- /Jacob Carlborg
[Issue 14558] Attempts to link with DMD when using MSVC LDC under VisualD
https://issues.dlang.org/show_bug.cgi?id=14558 --- Comment #6 from Manu turkey...@gmail.com --- I can't imagine a situation where I don't care about the runtime in my work :/ But sure, in the cases where you want to use MinGW, would you typically reach for GDC or LDC though? --
Re: Header Files
On 05/10/2015 09:11 AM, bitwise wrote: On Sunday, 10 May 2015 at 01:00:31 UTC, bitwise wrote: Is there really no way to preserve the directory structure when creating .di files? Bit Why hello, Bitwise! I believe the '-op' flag is what you're looking for! Bitwiser Wow! Walter has already implemented it by going back in time. :) Ali
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #12 from Manu turkey...@gmail.com --- Confirm fixed. This is awesome :) --
Re: Cannot find -lphobos
Your advice worked, thanks. It turns out that from the command line it compiles and links just fine. Codeblocks is the thing that is giving me trouble. It might have something to do that I am using the old Codeblocks 8.0 version. I would like to get the newest version but the Virtual Box OS is outdated and the package manager won't let me get anything newer. I downloaded the Codeblocks 13 tar manually and unpacked it, but Gdebi can't resolve the missing dependencies (even though they are right there in the directory.) It worked fine for Dmd. Any advice for this? On Sunday, 10 May 2015 at 15:33:24 UTC, weaselcat wrote: On Sunday, 10 May 2015 at 14:41:17 UTC, Ali Çehreli wrote: On 05/10/2015 12:45 AM, Marko Grdinic wrote: I works just fine on Windows, but I am having difficulty figuring out what the trouble is on my Bodhi 1.4 Virtual Box. I've followed the instruction on the Codeblocks Wiki and set the parameters, but when I try to compile, it complains that it can't find Phobos. /usr/bin/ld: cannot find -lphobos2 I've checked the search directories and the library directories are where it says they would be. I am not particularly familiar with Linux so I am not sure how to proceed from here. Any advice? dmd's -v flag may give some clues: $ dmd foo.d -v dmd outputs the config file that it uses and the linker flags that it passes. Ali additionally if not using dmd it may have the libraries named differently. a quick google says Bodhi linux is based on Ubuntu which doesn't ship dmd due to licensing issues AFAIK.
