[Issue 14533] Error 43: Not a Valid Library File
https://issues.dlang.org/show_bug.cgi?id=14533 --- Comment #2 from donglei do...@putao.com --- (In reply to Richard Cattermole from comment #1) Just to confirm this is for 64bit builds on Windows? And not the default of 32bit? Windows system is 64bit, but dmd is 32bit! It maybe cased by COFF format, I want to convert it to OMF format, but not found coffimplib in DMC website. Could you konw where i can find coffimplib. or where can I download libmysql.lib for dlang Thanks! --
[Issue 14533] Error 43: Not a Valid Library File
https://issues.dlang.org/show_bug.cgi?id=14533 --- Comment #3 from Richard Cattermole alphaglosi...@gmail.com --- (In reply to donglei from comment #2) (In reply to Richard Cattermole from comment #1) Just to confirm this is for 64bit builds on Windows? And not the default of 32bit? Windows system is 64bit, but dmd is 32bit! It maybe cased by COFF format, I want to convert it to OMF format, but not found coffimplib in DMC website. Could you konw where i can find coffimplib. or where can I download libmysql.lib for dlang Thanks! Assuming you are building for 32bit on Windows then you will be using OMF. coffimplib is available at http://ftp.digitalmars.com/coffimplib.zip --
[Issue 14543] New: std.algorithm.searching.until does not handle range sentinels nicely
https://issues.dlang.org/show_bug.cgi?id=14543
Issue ID: 14543
Summary: std.algorithm.searching.until does not handle range
sentinels nicely
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: jakobov...@gmail.com
Current behaviour:
void main()
{
import std.algorithm;
assert(one two three.until(two, OpenRight.no).equal(one t));
}
It's probably safe to say the user expected the result to be equal one two.
Range sentinel values aren't in the tests, so it's probably safe to say `until`
was not designed with range sentinels in mind.
--
[Issue 14508] [REG2.067.0] compiling with -unittest instantiates templates in non-root modules
https://issues.dlang.org/show_bug.cgi?id=14508 Martin Krejcirik m...@krej.cz changed: What|Removed |Added Summary|compiling with -unittest|[REG2.067.0] compiling with |instantiates templates in |-unittest instantiates |non-root modules|templates in non-root ||modules --
[Issue 14544] New: isForwardRange failed to recognise valid forward range
https://issues.dlang.org/show_bug.cgi?id=14544
Issue ID: 14544
Summary: isForwardRange failed to recognise valid forward range
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: ket...@ketmar.no-ip.org
this code fails static assertion:
struct Input {
auto opSlice (size_t start, size_t end) {
static struct InputSlice {
@property bool empty () { return false; }
@property char front () { return 0; }
void popFront () {}
InputSlice save () { return this; }
}
import std.range.primitives;
static assert(isForwardRange!InputSlice);
return InputSlice();
}
}
fixing code like this tames `isForwardRange`:
template isForwardRange(R)
{
enum bool isForwardRange = isInputRange!R is(typeof(
(inout int = 0)
{
R r1 = R.init;
//old: static assert (is(typeof(r1.save) == R));
auto s1 = r1.save;
static assert (is(typeof(s1) == R));
}));
}
i wonder if some other checking primitives has similar bug.
--
[Issue 14534] Front-end should lower all non-scalar condition expressions
https://issues.dlang.org/show_bug.cgi?id=14534 Iain Buclaw ibuc...@gdcproject.org changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #3 from Iain Buclaw ibuc...@gdcproject.org --- (In reply to yebblies from comment #2) The way to make this precisely defined is to put it in the spec and test suite, not to move the lowering into the frontend. Lowering early is not without downsides. In some cases, yes. But in this instance, I don't think so. After we've verified condition-toBoolean() the only other time semantic analysis is done on the condition is for optimizations. And I seriously doubt that we are likely going to get any meaningful constant literal optimized out from any of these types. --
[Issue 14534] Front-end should lower all non-scalar condition expressions
https://issues.dlang.org/show_bug.cgi?id=14534 --- Comment #4 from yebblies yebbl...@gmail.com --- (In reply to Iain Buclaw from comment #3) In some cases, yes. But in this instance, I don't think so. After we've verified condition-toBoolean() the only other time semantic analysis is done on the condition is for optimizations. And I seriously doubt that we are likely going to get any meaningful constant literal optimized out from any of these types. One example is error messages - I would much rather see if (dg) than if ((auto tmp = dg, tmp.funcptr != null tmp.ptr != null)) Lowering to if (cast(bool)dg) would be acceptable, but the lowering would still be in the backend. Maybe this is done late enough that it wouldn't affect error messages anyway? --
[Issue 14544] isForwardRange failed to recognise valid forward range
https://issues.dlang.org/show_bug.cgi?id=14544 Jonathan M Davis issues.dl...@jmdavisprog.com changed: What|Removed |Added Status|NEW |RESOLVED CC||issues.dl...@jmdavisprog.co ||m Resolution|--- |INVALID --- Comment #1 from Jonathan M Davis issues.dl...@jmdavisprog.com --- You failed to put @property on save. That's why it won't compile. --
[Issue 14544] isForwardRange failed to recognise valid forward range
https://issues.dlang.org/show_bug.cgi?id=14544 --- Comment #2 from Ketmar Dark ket...@ketmar.no-ip.org --- wow, it's fun. it specified nowhere in the docs. what i see is with the save primitive, which clearly not necessary a property. it also contradics my common sense too. with the fix i proposed it doesn't matter if `save` is property or not. oh, well, let it be another D wart that meant to make programmer feel stupid. D full of that anyway. --
[Issue 14545] New: can't deprecate default construction
https://issues.dlang.org/show_bug.cgi?id=14545
Issue ID: 14545
Summary: can't deprecate default construction
Product: D
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
cat enh.d CODE
struct Foo
{
deprecated(use foo() instead)
this();
}
CODE
dmd -c enh
Error: constructor enh.Foo.this default constructor for structs only allowed
with @disable and no body
There is no mean to deprecate default construction of a struct before finally
disabling it.
We should enhance the compiler so that the above declaration is valid and using
`Foo foo;` would emit a deprecation warning.
--
[Issue 14544] isForwardRange failed to recognise valid forward range
https://issues.dlang.org/show_bug.cgi?id=14544 --- Comment #3 from Jonathan M Davis issues.dl...@jmdavisprog.com --- Oh, it's stupid that save is required to be a property, since it's not at all an abstraction for a variable, but I don't think that Andrei really understands the idea behind properties (certainly, he didn't when he made save a property, and I also think that that's why he's generally been unhappy with @property when it's come up). The problem is though that once it's required to be a property, changing it later risks breaking code. Given how poorly properties are checked by the compiler, we _might_ be able to make the change, but we'd have to be careful about it. Regardless, the fact that isForwardRange is the way it is and requires that save be a property is very much on purpose. --
Re: This Week in D #15: hackathon, mem management, ARM, tip for C coders
On Monday, 4 May 2015 at 03:23:08 UTC, Adam D. Ruppe wrote: I covered two weeks this time, as I missed last week. A switch was added to git to start profiling the GC itself, as part of a general push toward better memory management in D. That should read: A switch was added to *DMD*
Re: Digger 2.1
On 2015-05-03 13:49:33 +, Vladimir Panteleev said: Digger v2.1 (2015-05-03) Hi, I just updated my binary and tried digger build and got this: mac-pro:Digger robby$ ./digger build digger: Building spec: master digger: Adding /Volumes/Daten/Windows/d/develop/d-language/Digger/dl/gitinstaller/cmd to PATH. digger: Updating repo... Fetching origin digger: Starting at meta repository commit 66a9c729588d7a4f4add369ecd8fe10aa16e7085 digger: Building components dmd, druntime, phobos-includes, phobos, rdmd digger: needInstalled: dmd-b9dee9e4d845b6ee30b4ac63886531dae200a760-b7a24e8234f0f1d5885c4284f67299eb digger: Cache hit! Fatal error: dmd-b9dee9e4d845b6ee30b4ac63886531dae200a760-b7a24e8234f0f1d5885c4284f67299eb was cached as unbuildable So, it looks I'm missing something that needs to be installed. But I don't have a clue how to find out what's missing. Any idea? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: This Week in D #15: hackathon, mem management, ARM, tip for C coders
On 05/03/2015 11:23 PM, Adam D. Ruppe wrote: I covered two weeks this time, as I missed last week. http://arsdnet.net/this-week-in-d/may-03.html The tip this week might be a bit controversial but I actually feel kinda strongly about this. So many times, I see people asking questions about how to do task X in D. Actually, I came over to this forum thread just now specifically to say that I liked that tip quite a lot. It's a very good (and well-written) point that perhaps doesn't always get communicated as well as it should.
Re: [Hackathon] ARM Cortex-M LCD Demo
Jeremiah DeHaan dehaan.jerem...@gmail.com writes: On Friday, 1 May 2015 at 15:37:09 UTC, ketmar wrote: On Fri, 01 May 2015 15:30:21 +, Mike wrote: I know, random rectangles on a screen is not all that remarkable, they ARE remarkable! I agree. This is fantastic work! I am so excited to see this. Me too! True embedded work should be a sweet spot for D. Too bad we can't grab 2-3 developers and give them 3-months budget and time to hack out all the necessary parts for an embedded toolchain,libs,and methodolgy based entirely on D. Anybody thought of porting relavant parts of say newlib to D? -- Dan Olson
Re: Digger 2.1
On Monday, 4 May 2015 at 10:33:14 UTC, Robert M. Münch wrote: So, it looks I'm missing something that needs to be installed. But I don't have a clue how to find out what's missing. Any idea? Turn off or delete the cache to get a meaningful error message.
Re: Digger 2.1
On 2015-05-04 16:45:23 +, Vladimir Panteleev said: Turn off or delete the cache to get a meaningful error message. The problem was that this reference: ./Digger/dl/dmd-2.066.1/dmd2/osx/bin/dmd had wrong permissions (644) instead of (755) I guess. Not sure how this can happen. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: This Week in D #15: hackathon, mem management, ARM, tip for C coders
On 5/3/15 8:23 PM, Adam D. Ruppe wrote: I covered two weeks this time, as I missed last week. http://arsdnet.net/this-week-in-d/may-03.html http://www.reddit.com/r/programming/comments/34uji5/d_hackathon_roundup_and_tip_of_the_week_dont_be/ https://twitter.com/D_Programming/status/595287061990506497 https://www.facebook.com/dlang.org/posts/1062292857117728 Andrei
Re: Silicon Valley D Meetup April 23, 2015
On 04/17/2015 03:39 PM, Ali Çehreli wrote: http://www.meetup.com/D-Lang-Silicon-Valley/events/221371799/ Shammah Chancellor's slides are up as well. Ali
Re: This Week in D #15: hackathon, mem management, ARM, tip for C coders
On Monday, 4 May 2015 at 03:50:57 UTC, Rikki Cattermole wrote: A pet peeve from the community section might be a great idea! If you ever want to rant, type it up and email it to me, I'll work it in! BTW I also have a window open on my browser somewhere to chat with you about audio stuff. Been pretty busy lately but want you to know that I haven't forgotten!
Re: This Week in D #15: hackathon, mem management, ARM, tip for C coders
On Monday, 4 May 2015 at 09:01:31 UTC, Gary Willoughby wrote: That should read: A switch was added to *DMD* ah right, I made it to dmd git; what I meant was the git version but it can always be clearer.
What wrong?
Simple code: http://pastebin.com/raw.php?i=7jVeMFXQ This code works compiled by DMD v2.066.1 and LDC2 (0.15.1) based on DMD v2.066.1 and LLVM 3.5.0. $ ./z TUQLUE 42 11 Compiled by DMD v2.067.1 the program crashes: $ ./aa TUQLUE Segmentation fault What I'm doing wrong?
Re: What wrong?
On Mon, 04 May 2015 08:48:45 + Fyodor Ustinov via Digitalmars-d digitalmars-d@puremagic.com wrote: Simple code: http://pastebin.com/raw.php?i=7jVeMFXQ This code works compiled by DMD v2.066.1 and LDC2 (0.15.1) based on DMD v2.066.1 and LLVM 3.5.0. $ ./z TUQLUE 42 11 Compiled by DMD v2.067.1 the program crashes: $ ./aa TUQLUE Segmentation fault What I'm doing wrong? I think it is releted with this chage: http://dlang.org/changelog.html#heap-struct-destructors So your code has been probably wrong before, but accidentally works
Re: std.xml2 (collecting features)
On Sunday, 3 May 2015 at 23:32:28 UTC, Michel Fortin wrote: This isn't a feature request (sorry?), but I just want to point out that you should feel free to borrow code from https://github.com/michelf/mfr-xml-d There's probably a lot you can reuse in there. nice, thank you
Re: std.xml2 (collecting features)
On Sunday, 3 May 2015 at 22:02:13 UTC, Walter Bright wrote: On 5/3/2015 2:31 PM, Ilya Yaroshenko wrote: Can it lazily reads huge files (files greater than memory)? If a range interface is used, it doesn't need to be aware of where the data is coming from. In fact, the xml package should NOT be doing I/O. Wouldn't D-ranges make it impossible to use SIMD optimizations when scanning? However, it would make a lot of sense to just convert an existing XML solution with Boost license. I don't know which ones are any good, but RapidXML is at least Boost.
isForwardRange failed to recognise valid forward range
here is some code for your amusement:
struct Input {
auto opSlice (size_t start, size_t end) {
static struct InputSlice {
@property bool empty () { return false; }
@property char front () { return 0; }
void popFront () {}
InputSlice save () { return this; }
}
import std.range.primitives;
static assert(isForwardRange!InputSlice);
return InputSlice();
}
}
fixing code like this tames `isForwardRange`:
template isForwardRange(R)
{
enum bool isForwardRange = isInputRange!R is(typeof(
(inout int = 0)
{
R r1 = R.init;
//old: static assert (is(typeof(r1.save) == R));
auto s1 = r1.save;
static assert (is(typeof(s1) == R));
}));
}
i wonder if some other checking primitives has similar bug.
signature.asc
Description: PGP signature
Re: if(arr) now a warning
On Friday, 10 April 2015 at 10:14:43 UTC, Martin Nowak wrote: if (arr) - if (!arr.empty) It's much clearer and also what you need to write when you work with ranges. Maybe rename it opEmpty then. Try to keep language protocols and library conventions separate.
Re: isForwardRange failed to recognise valid forward range
On Mon, 04 May 2015 10:25:23 +, ketmar wrote: https://issues.dlang.org/show_bug.cgi?id=14544 signature.asc Description: PGP signature
Re: if(arr) now a warning
On Mon, 04 May 2015 10:27:47 +, Ola Fosheim Grøstad wrote: On Friday, 10 April 2015 at 10:14:43 UTC, Martin Nowak wrote: if (arr) - if (!arr.empty) It's much clearer and also what you need to write when you work with ranges. Maybe rename it opEmpty then. Try to keep language protocols and library conventions separate. or at least move it to object.d, so i don't have to import std.range to get this check working. signature.asc Description: PGP signature
Re: dmd -profile=gc
On Sunday, 3 May 2015 at 21:11:58 UTC, Walter Bright wrote: Just merged in is a new compiler switch that instruments generated code to collect statistics on memory allocation usage and generates a report upon program termination. (Much like how -profile works.) This was based on a prototype Andrei had written earlier. Andrei and I suspect it can be of great use in figuring out why a program may be excessively slow or consume excessive memory. I encourage giving it a try on some non-trivial project, and see if it gives useful information. Nice! I bet this can be used to improve Phobos in tandem with @nogc.
Re: What wrong?
On Monday, 4 May 2015 at 08:48:47 UTC, Fyodor Ustinov wrote:
Simple code:
http://pastebin.com/raw.php?i=7jVeMFXQ
This code works compiled by DMD v2.066.1 and LDC2 (0.15.1) based
on DMD v2.066.1 and LLVM 3.5.0.
$ ./z
TUQLUE
42
11
Compiled by DMD v2.067.1 the program crashes:
$ ./aa
TUQLUE
Segmentation fault
What I'm doing wrong?
Reduced it a little:
module z;
import std.stdio;
import std.concurrency;
import core.thread;
struct Variant {
void function() fptr = handler;
static void handler() {}
~this() {
fptr();
}
}
void _get(Tid id) {
id.send(Variant());
}
void supervisor() {
receive(_get);
}
void main() {
Tid supervisorTid = spawn(supervisor);
supervisorTid.send(thisTid);
writeln(TUQLUE);
receive(
(Variant a) {}
);
writeln(42);
thread_joinAll();
}
Re: dmd -profile=gc
Can be -profile and -profile=gc mixed together? On Sunday, 3 May 2015 at 21:11:58 UTC, Walter Bright wrote: Just merged in is a new compiler switch that instruments generated code to collect statistics on memory allocation usage and generates a report upon program termination. (Much like how -profile works.) This was based on a prototype Andrei had written earlier. Andrei and I suspect it can be of great use in figuring out why a program may be excessively slow or consume excessive memory. I encourage giving it a try on some non-trivial project, and see if it gives useful information.
Phobos master broken ?
I can't seem to build phobos master on linux, unless I revert pull #3014 unittests DMD v2.067-devel-b9dee9e DEBUG std/math.d(2702): Error: number '0x1p-1024' is not representable std/math.d(2705): Error: number '0x1p-1024' is not representable std/math.d(2708): Error: number '0x1p-1024' is not representable std/math.d(2713): Error: number '0x1p-128f' is not representable std/math.d(2716): Error: number '0x1p-128f' is not representable std/math.d(2719): Error: number '0x1p-128f' is not representable make: *** [generated/linux/release/32/libphobos2.a] Error 1 Since it lasts about a month, I wonder if I am the only one having this problem ?
Re: isForwardRange failed to recognise valid forward range
On Monday, 4 May 2015 at 10:25:23 UTC, ketmar wrote:
here is some code for your amusement:
struct Input {
auto opSlice (size_t start, size_t end) {
static struct InputSlice {
@property bool empty () { return false; }
@property char front () { return 0; }
void popFront () {}
InputSlice save () { return this; }
}
import std.range.primitives;
static assert(isForwardRange!InputSlice);
return InputSlice();
}
}
fixing code like this tames `isForwardRange`:
template isForwardRange(R)
{
enum bool isForwardRange = isInputRange!R is(typeof(
(inout int = 0)
{
R r1 = R.init;
//old: static assert (is(typeof(r1.save) == R));
auto s1 = r1.save;
static assert (is(typeof(s1) == R));
}));
}
i wonder if some other checking primitives has similar bug.
Add @property to save.
error with std.range.put - readN
the following program fails because of the `put` function :
---
import std.stdio;
import std.range;
size_t readN(T, Range)(ref Range src, ref Range dst, size_t n)
if (isInputRange!Range isOutputRange!(Range, T))
{
size_t result;
while(1)
{
if (src.empty || result == n)
break;
put(dst, src.front()); // here
src.popFront;
++result;
}
return result;
}
void main(string[] args)
{
int[] src = [1,2,3];
int[] dst = [0];
auto n = readN!int(src, dst, 2);
writeln(dst);
}
---
If i replace `put` by a cat op (`~`) it works, however the cat op
only works here because i test the template with two int[].
What's wrong ?
Re: isForwardRange failed to recognise valid forward range
On Mon, 04 May 2015 14:33:11 +, Alex Parrill wrote: Add @property to save. another arcane knowledge. i'm seriously thinking about going back to C++, as i know that C++ is insane and full of such warts. and with C++ i have full access to all C and C++ libraries. consistency issues tend to be ignored in D, dunno why. C++ become popular not due to it's weirdness, and make D weird and unintuitive will not automatically made it popular. i'd say the opposite. isForwardRange Tests if something is a forward range, defined to be an input range with the additional capability that one can save one's current position with the save primitive... ok, i have save primitive here. it's not working. yet it's not a bug, ok. just another meaningless limitation that has no useful purpose. signature.asc Description: PGP signature
Re: Adding a read primitive to ranges
On Monday, 4 May 2015 at 00:07:27 UTC, Freddy wrote:
Would it be a bad idea to add a read primitive to ranges for
streaming?
struct ReadRange(T){
size_t read(T[] buffer);
//and | or
T[] read(size_t request);
/+ empty,front,popFront,etc +/
}
IT seems redundant to me. It's semantically no different than
iterating through the range normally with front/popFront. For
objects where reading large amounts of data is more efficient
than reading one-at-a-time, you can implement a byChunks function
like stdio.File.
Re: [your code here] Rounding real numbers
Arrrg, formatting got torn up. Here's a Dpaste: http://dpaste.dzfl.pl/ca190950f199
Re: What wrong?
On Monday, 4 May 2015 at 12:19:27 UTC, anonymous wrote:
On Monday, 4 May 2015 at 08:48:47 UTC, Fyodor Ustinov wrote:
Simple code:
http://pastebin.com/raw.php?i=7jVeMFXQ
This code works compiled by DMD v2.066.1 and LDC2 (0.15.1)
based
on DMD v2.066.1 and LLVM 3.5.0.
$ ./z
TUQLUE
42
11
Compiled by DMD v2.067.1 the program crashes:
$ ./aa
TUQLUE
Segmentation fault
What I'm doing wrong?
~this() {
fptr();
}
~this() {
writeln(fptr);
fptr();
}
$ ./aa
TUQLUE
464E70
464E70
464E70
464E70
464E70
464E70
464E70
464E70
464E70
464E70
464E70
6C2AD0
Segmentation fault
OMG.
Re: error with std.range.put - readN
On Monday, 4 May 2015 at 14:33:23 UTC, Baz wrote:
the following program fails because of the `put` function :
---
import std.stdio;
import std.range;
size_t readN(T, Range)(ref Range src, ref Range dst, size_t n)
if (isInputRange!Range isOutputRange!(Range, T))
{
size_t result;
while(1)
{
if (src.empty || result == n)
break;
put(dst, src.front()); // here
src.popFront;
++result;
}
return result;
}
void main(string[] args)
{
int[] src = [1,2,3];
int[] dst = [0];
auto n = readN!int(src, dst, 2);
writeln(dst);
}
---
If i replace `put` by a cat op (`~`) it works, however the cat
op only works here because i test the template with two int[].
What's wrong ?
I believe the put(R,E) calls the doPut(R, E)
private void doPut(R, E)(ref R r, auto ref E e)
{
//...
else static if (isInputRange!R)
{
static assert(is(typeof(r.front = e)),
Cannot nativaly put a ~ E.stringof ~ into a ~
R.stringof ~ .);
r.front = e;
r.popFront();
}
//...
}
So basically you put elements into the list until it is empty.
import std.stdio;
import std.range;
void main()
{
int [] list = new int [10];
writeln(list);//10 zeros
list.front = 5; //1 five and 9 zeroes
writeln(list);
list.popFront(); //9 zeroes left.
writeln(list);
}
Re: The most awesome forward to member solution?
Will allocator ever be added to phobos as maybe std.experimental.allocator for a first time ?
Re: Phobos master broken ?
On Monday, 4 May 2015 at 14:32:16 UTC, Martin Krejcirik wrote: I can't seem to build phobos master on linux, unless I revert pull #3014 unittests DMD v2.067-devel-b9dee9e DEBUG std/math.d(2702): Error: number '0x1p-1024' is not representable std/math.d(2705): Error: number '0x1p-1024' is not representable std/math.d(2708): Error: number '0x1p-1024' is not representable std/math.d(2713): Error: number '0x1p-128f' is not representable std/math.d(2716): Error: number '0x1p-128f' is not representable std/math.d(2719): Error: number '0x1p-128f' is not representable make: *** [generated/linux/release/32/libphobos2.a] Error 1 Since it lasts about a month, I wonder if I am the only one having this problem ? The autotester doesn't show any such problems: https://auto-tester.puremagic.com/ The only failure I see right now is what looks like a random test failure on 32-bit linux in druntime. You list DMD v2.067-devel-b9dee9e DEBUG. Does that mean that you're not using the latest dmd? Make sure that you're using dmd master and druntime master when building phobos master. Also make sure that all three repos are clean and up-to-date without any local changes. - Jonathan M Davis
Re: error with std.range.put - readN
On Monday, 4 May 2015 at 14:33:23 UTC, Baz wrote:
the following program fails because of the `put` function :
---
import std.stdio;
import std.range;
size_t readN(T, Range)(ref Range src, ref Range dst, size_t n)
if (isInputRange!Range isOutputRange!(Range, T))
{
size_t result;
while(1)
{
if (src.empty || result == n)
break;
put(dst, src.front()); // here
src.popFront;
++result;
}
return result;
}
void main(string[] args)
{
int[] src = [1,2,3];
int[] dst = [0];
auto n = readN!int(src, dst, 2);
writeln(dst);
}
---
If i replace `put` by a cat op (`~`) it works, however the cat
op only works here because i test the template with two int[].
What's wrong ?
Your destination is too small. When arrays are treated as output
ranges, they get written to like a buffer. They don't get
appended to. If you want to append to them, then use Appender for
the output range.
On a side note, it's very backwards that you're calling front
with parens and popFront without. front is usually a property
function (in which case, if @property ever gets sorted out
properly, front() wouldn't compile), and popFront is never a
property function (so you _can_ call it without parens, but it's
kind of weird to do so).
- Jonathan M Davis
Re: Phobos master broken ?
You list DMD v2.067-devel-b9dee9e DEBUG. Does that mean that you're not using the latest dmd? Make sure that you're using I've tried making a fresh clone of dmd, druntime, phobos on a different computer, compiling: make -f posix.mak MODEL=32 Still the same error. I've no problem compiling stable or whatever older version before the above mentioned pull request. I'm on Debian wheezy for reference.
Re: Phobos master broken ?
On Monday, 4 May 2015 at 17:15:11 UTC, Martin Krejcirik wrote: You list DMD v2.067-devel-b9dee9e DEBUG. Does that mean that you're not using the latest dmd? Make sure that you're using I've tried making a fresh clone of dmd, druntime, phobos on a different computer, compiling: make -f posix.mak MODEL=32 Still the same error. I've no problem compiling stable or whatever older version before the above mentioned pull request. I'm on Debian wheezy for reference. You might need to put DMD=path/to/dmd in front of make and give it the path to the dmd from master so that it uses that rather than the one installed on your system. - Jonathan M Davis
Re: The most awesome forward to member solution?
On 5/4/15 9:31 AM, Temtaime wrote: Will allocator ever be added to phobos as maybe std.experimental.allocator for a first time ? Affirmative. Getting Real Close Now. -- Andrei
Re: Phobos master broken ?
You might need to put DMD=path/to/dmd in front of make and give it the path to the dmd from master so that it uses that rather than the one installed on your system. It picks up dmd from ../dmd/src by default, making it explicit makes no difference. I've tried 2.067.1 binary too.
FreeTree eviction strategy
So I'm toying around with a promising structure that I call free tree for std.allocator. There's some detail with code and docs here: http://forum.dlang.org/thread/mi1qph$cgr$1...@digitalmars.com. A free tree allocator is akin to a free list. Instead of just a singly linked list, it also maintains a binary search tree sorted by size. So each free chunk contains the size, the next node, and left/right children. Insertion in the free tree is done to the root, i.e. the newly inserted block becomes the root. Just like the free list. So we got nice locality etc. and no need to worry about rebalancing. Code came in really small and clean, textbook-like. All in all free tree is like an adaptive battery of freelists - it just adapts to whichever sizes you allocate the most. And herein lies the danger. As allocation patterns come and go, chunks of less-frequently-used lengths get pushed toward the leaves of the tree and there's nothing to limit growth. So we have fragmentation because the free tree is holding onto all those old chunks etc. What's needed is a good eviction strategy that's cheap (e.g. doesn't require me to hold age info or run complex algos) and effective. One hamfisted solution is to just blow away the tree once in a while (e.g. when it gets to a specific size or after some time/number of allocations) but I feel there's something more principled out there. I'd love to hear your thoughts. Thanks, Andrei
Re: [your code here] Rounding real numbers
On Sunday, 3 May 2015 at 04:14:40 UTC, Andrei Alexandrescu wrote: On 5/2/15 7:48 PM, Vladimir Panteleev wrote: On Saturday, 2 May 2015 at 22:23:01 UTC, Andrei Alexandrescu wrote: On Friday, 1 May 2015 at 17:17:09 UTC, Justin Whear wrote: A process for rounding numbers. Thanks Justin. Could someone take this? We don't have PHP code for rotating examples randomly yet. -- Andrei Doesn't need to be PHP, just show one example statically and switch it with a random one with JS. That'd work. I gather you just volunteered :o). -- Andrei https://github.com/D-Programming-Language/dlang.org/pull/988
Re: error with std.range.put - readN
On 05/04/2015 07:33 AM, Baz wrote: int[] src = [1,2,3]; int[] dst = [0]; In addition to what others said, even if dst had room for two elements, it would lose the newly added element due to a popFront() called implicitly during put()'ting. int[] dst = [0, 0];// -- Has room now auto n = readN!int(src, dst, 2); writeln(dst); // -- Prints [] WAT? One solution is to introduce another slice that would not be popFront'ed: int[] dst = [0, 0]; int[] dst2 = dst;// -- This auto n = readN!int(src, dst, 2); writeln(dst2); // -- prints [1, 2] However, Appender is a better solution. Ali
Re: std.xml2 (collecting features)
On Sunday, 3 May 2015 at 17:47:15 UTC, Joakim wrote: My request: just skip it. XML is a horrible waste of space for a standard, better D doesn't support it well, anything to discourage it's use. I'd rather see you spend your time on something worthwhile. If data formats are your thing, you could help get Ludwig's JSON stuff in, or better yet, enable some nice binary data format. Am Sun, 03 May 2015 18:44:11 + schrieb w0rp devw...@gmail.com: I agree that JSON is superior through-and-through, but legacy support matters, and XML is in many places. It's good to have a quality XML parsing library. You two are terrible at motivating people. Better D doesn't support it well and JSON is superior through-and-through is overly dismissive. To me it sounds like someone saying replace C++ with JavaScript, because C++ is a horrible standard and JavaScript is so much superior. Honestly. 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: * allows you to use XML files like a textual database * complex enough to allow for almost any imaginable query * many tools emerged to test XPath expressions against XML documents * also powers XSLT (http://www.liquid-technologies.com/xpath-tutorial.aspx) XSL (Extensible Stylesheet Language) and XSLT (XSL Transformations): * written as XML documents * standard way to transform XML from one structure into another * convert or compile data to XHTML or SVG for display in a browser * output to XSL-FO XSL-FO (XSL formatting objects): * written as XSL * type-setting for XML; a XSL-FO processor is similar to a LaTex processor * reads an XML document (a Format document) and outputs to a PDF, RTF or similar format XML Schema Definition (XSD): * written as XML * linked in by an XML file * defines structure and validates content to some extent * can set constraints on how often an element can occur in a list * can validate data type of values (length, regex, positive, etc.) * database like unique IDs and references I think XML is the most eat-your-own-dog-food language ever and nicely covers a wide range of use cases. In any case there are many XML based file formats that we might want to parse. Amongst them SVG, OpenDocument (Open/LibreOffics), RSS feeds, several US Offices, XMP and other meta data formats. When it comes to which features to support, I personally used XSD more than XPath and the tech using it. But quite frankly both would be expected by users. Based on XPath, XSL transformations can be added any time then. Anything beyond that doesn't feel quite core enough to be in a XML module. -- Marco
Re: std.xml2 (collecting features)
Am Sun, 03 May 2015 14:00:11 -0700 schrieb Walter Bright newshou...@digitalmars.com: On 5/3/2015 10:39 AM, Robert burner Schadek wrote: - CTS for encoding (ubyte(ASCII), char(utf8), ... ) Encoding schemes should be handled by adapter algorithms, not in the XML parser itself, which should only handle UTF8. Unlike JSON, XML actually declares the encoding in the prolog, e.g.: ?xml version=1.0 encoding=Windows-1252? -- Marco
Re: std.xml2 (collecting features)
On Sunday, 3 May 2015 at 17:39:48 UTC, Robert burner Schadek wrote: std.xml has been considered not up to specs nearly 3 years now. Time to build a successor. I currently plan the following featues for it: - SAX and DOM parser - in-situ / slicing parsing when possible (forward range?) - compile time switch (CTS) for lazy attribute parsing - CTS for encoding (ubyte(ASCII), char(utf8), ... ) - CTS for input validating - performance Not much code yet, I'm currently building the performance test suite https://github.com/burner/std.xml2 Please post you feature requests, and please keep the posts DRY and on topic. If I were doing it, I'd do three types of parsers: 1. A parser that was pretty much as low level as you can get, where you basically a range of XML atributes or tags. Exactly how to build that could be a bit entertaining, since it would have to be hierarchical, and ranges aren't, but something like a range of tags where you can get a range of its attributes and sub-tags from it so that the whole document can be processed without actually getting to the level of even a SAX parser. That parser could then be used to build the other parsers, and anyone who needed insanely fast speeds could use it rather than the SAX or DOM parser so long as they were willing to pay the inevitable loss in user-friendliness. 2. SAX parser built on the low level parser. 3. DOM parser built either on the low level parser or the SAX parser (whichever made more sense). I doubt that I'm really explaining the low level parser well enough or have even though through it enough, but I really think that even a SAX parser is too high level for the base parser and that something that slightly higher than a lexer (high enough to actually be processing XML rather than individual tokens but pretty much only as high as is required to do that) would be a far better choice. IIRC, Michel Fortin's work went in that direction, and he linked to his code in another post, so I'd suggest at least looking at that for ideas. Regardless, by building layers of XML parsers rather than just the standard ones, it should be possible to get higher performance while still having the more standard, user-friendly ones for those that don't need the full performance and do need the user-friendliness (though of course, we do want the SAX and DOM parsers to be efficient as well). - Jonathan M Davis
Re: error with std.range.put - readN
On Monday, 4 May 2015 at 18:50:45 UTC, Ali Çehreli wrote: On 05/04/2015 07:33 AM, Baz wrote: int[] src = [1,2,3]; int[] dst = [0]; In addition to what others said, even if dst had room for two elements, it would lose the newly added element due to a popFront() called implicitly during put()'ting. int[] dst = [0, 0];// -- Has room now auto n = readN!int(src, dst, 2); writeln(dst); // -- Prints [] WAT? One solution is to introduce another slice that would not be popFront'ed: int[] dst = [0, 0]; int[] dst2 = dst;// -- This auto n = readN!int(src, dst, 2); writeln(dst2); // -- prints [1, 2] However, Appender is a better solution. I really think that output ranges need to be rethought through. In most cases, lazy input ranges should be used instead, but they do have their uses. The problem is that they're not designed well enough or thoroughly enough to be very useful outside of Appender. Using arrays as output ranges is particularly bad, but the fact that there is no way to know whether an output range even has room to put a new element or range of elements onto its end makes output ranges unusable in many cases IMHO. - Jonathan M Davis
Re: The most awesome forward to member solution?
On 2015-05-04 07:28, Andrei Alexandrescu wrote: But then the opDispatch solution is more structured and restricted in a good way. I think we need a bit more experience with both to figure out which is the best way to go. I would guess the opDispatch solution doesn't integrate so well with an already present opDispatch (if there's such a use case). -- /Jacob Carlborg
Re: Adding a read primitive to ranges
On Monday, 4 May 2015 at 15:16:25 UTC, Alex Parrill wrote: IT seems redundant to me. It's semantically no different than iterating through the range normally with front/popFront. For objects where reading large amounts of data is more efficient than reading one-at-a-time, you can implement a byChunks function like stdio.File. The ploblem is that all the functions in std.range,std.algorithm and many other wrappers would ignore byChucks and produce much slower code.
Re: dmd -profile=gc
On 5/4/2015 6:06 AM, Andrea Fontana wrote: Can be -profile and -profile=gc mixed together? Yes, and you'll get two reports.
Re: std.xml2 (collecting features)
On 2015-05-03 19:39, Robert burner Schadek wrote: Not much code yet, I'm currently building the performance test suite https://github.com/burner/std.xml2 I recommend benchmarking against the Tango pull parser. -- /Jacob Carlborg
Re: std.xml2 (collecting features)
On 2015-05-04 21:14, Jonathan M Davis wrote: If I were doing it, I'd do three types of parsers: 1. A parser that was pretty much as low level as you can get, where you basically a range of XML atributes or tags. Exactly how to build that could be a bit entertaining, since it would have to be hierarchical, and ranges aren't, but something like a range of tags where you can get a range of its attributes and sub-tags from it so that the whole document can be processed without actually getting to the level of even a SAX parser. That parser could then be used to build the other parsers, and anyone who needed insanely fast speeds could use it rather than the SAX or DOM parser so long as they were willing to pay the inevitable loss in user-friendliness. 2. SAX parser built on the low level parser. 3. DOM parser built either on the low level parser or the SAX parser (whichever made more sense). I doubt that I'm really explaining the low level parser well enough or have even though through it enough, but I really think that even a SAX parser is too high level for the base parser and that something that slightly higher than a lexer (high enough to actually be processing XML rather than individual tokens but pretty much only as high as is required to do that) would be a far better choice. IIRC, Michel Fortin's work went in that direction, and he linked to his code in another post, so I'd suggest at least looking at that for ideas. This way the XML parser is structured in Tango. A pull parser at the lowest level, a SAX parser on top of that and I think the DOM parser builds on top of the pull parser. The Tango pull parser can give you the following tokens: * start element * attribute * end element * end empty element * data * comment * cdata * doctype * pi -- /Jacob Carlborg
Re: std.xml2 (collecting features)
On Sunday, 3 May 2015 at 22:02:13 UTC, Walter Bright wrote: On 5/3/2015 2:31 PM, Ilya Yaroshenko wrote: Can it lazily reads huge files (files greater than memory)? If a range interface is used, it doesn't need to be aware of where the data is coming from. In fact, the xml package should NOT be doing I/O. Indeed. It should operate on ranges without caring where they came from (though it may end up supporting both input ranges and random-access ranges with the idea that it can support reading of a socket with a range in a less efficient manner or operating on a whole file at once as via a random-access range for more efficient parsing). But if I/O is a big concern, I'd suggest just using std.mmfile to do the trick, since then you can still operate on the whole file as a single array without having to actually have the whole thing in memory. - Jonathan M Davis
Re: std.xml2 (collecting features)
On Monday, 4 May 2015 at 09:35:55 UTC, Ola Fosheim Grøstad wrote: However, it would make a lot of sense to just convert an existing XML solution with Boost license. I don't know which ones are any good, but RapidXML is at least Boost. Given how D's arrays work, we have the opportunity to have an _extremely_ fast XML parser thanks to slices. It's highly unlikely that any C or C++ solution is going to be able to compete, and if it can, it's likely to be far more complex than necessary. Parsing is an area where we definitely should write our own stuff rather than porting existing code from other languages or use existing libraries in other languages via C bindings. Fast parsing is definitely a killer feature of D and the fact that std.xml botches that so badly is just embarrassing. - Jonathan M Davis
Re: A slice can lose capacity simply by calling a function
On 05/03/2015 06:06 PM, Jonathan M Davis via Digitalmars-d-learn wrote: On Sunday, May 03, 2015 15:21:15 Andrew Godfrey via Digitalmars-d-learn wrote: I really don't think that it's an issue in general, but if you do want to guarantee that nothing affects the capacity of your array, then you're going to need to either wrap all access to it I agree with everything Jonathan said in both threads EXCEPT that this is not an issue. The syntax slice.capacity gives the impression that 'capacity' is a property of the slice. Such lack of consistency is a SERIOUS issue for D, especially when it occurs in something as basic as an array. I really don't see the problem. It's a natural side effect of how dynamic arrays work in D. The problem is described in those two sentences of yours: The behavior of a language construct depends on the implementation detail. Unfortunately, it is backward. Normally, the semantics would be layed out and then those semantics would be implemented. It is not the case with D's dynamic arrays. (Aside: Heck, we (at least you and I) can't even decide whether dynamic arrays and slices are the same thing. (For the record, yes, they are the same thing from every vantage point: They have the same semantics and they are implemented in the same way.)) Saying that there is no problem would be contradicting yourself. These are your quotes from the following thread: http://forum.dlang.org/thread/mhtu1k$2it8$1...@digitalmars.com#post-mailman.597.1430448607.4581.digitalmars-d-learn:40puremagic.com - it seems like so few people understand it - pretty much everyone has trouble with them initially - I _still_ occasionally end up \Aha!\ moments So, yes, this is a problem. The problem is even worse because we can't come up with a consistent way of describing the semantics after the fact (after how they are implemented). The following are some of my attempts: sharing may terminate when the length of the slice increases capacity is first-come first served However, they are only mostly correct, not always. And that's the part that is frustrating the most: There is no way of understanding the semantics so that one can explain them to at least to one's self. The only thing I can see that could be changed without Please note that at least I am not interested in changing anything: I am interested in a way of explaining the semantics. I could not find that way yet. (I am eagerly waiting for your DConf talk to see how you make sense of it all.) You'd still have to understand how D's dynamic arrays work to understand how the capacity for a dynamic array works. I am happy that I do my part by opening threads like this one to shine more light on what array capacity is not. And most code really doesn't care about the capacity of an array. If you profile and find that appending to an array is a hot spot in your program, then you dig in and use reserve or Appender or use something other than a naked array, and you figure out what works best for your particular use case, but for most code, it just works to use ~=. And if you're concerned about reallocations even before profiling, then it's trivial to just call reserve first or to use Appender. And unless you're doing something like constantly slicing and appending to each slice (which I expect to be a rare thing to do), you're really not going to run into problems. I am sorry but that is missing the point. This issue is not only about performance. Note that I may not be the only programmer who writes the entire application. Imagine that I write a function inside a library. Do I have the *right* to append to my parameter slice? Do I have the right to disturb my caller's slice? The answer is a resounding NO, in capital letters. If I lose my caller's potentially precious and carefully crafter capacity, perhaps after a call to reserve(), then I am a bad library function. As a programmer, I need guidelines. Here is what I have at this point: Never append to a parameter slice. Sure, the semantics of D's dynamic arrays take some getting used to - Yes, they do: I started learning D about 6 years ago. How many years more do you reckon until I get them? especially if you want to understand all of their ins and outs. Yes I do. But I really don't see why it's a big problem. I said it before why it's a big problem: The elements are const, the slice is passed by value, but the [slice is affected]. The loss of capacity itself is not a big deal. However, this behavior conflicts with other parts of the language (as well as at least C and C++). For the most part, D's dynamic arrays just work. I know you are not trolling but I can't take your brushing off this issue with phares like for the most part. That's the frigging problem! For the most part is not sufficient. Unless somebody explains the semantics in a consistent way, I will continue to try to do it myself.
Re: dub building is extremely slow
On Thursday, 30 April 2015 at 12:31:54 UTC, wobbles wrote: On Thursday, 30 April 2015 at 03:00:36 UTC, zhmt wrote: On Thursday, 30 April 2015 at 02:02:50 UTC, zhmt wrote: dub build is running on centos7. It works well until today, It becomes very slow suddenly. It will take minuties per compilation, there is 10 files in project. Has anyone experienced this? It is because: The dub will connect to some website to check version of packages,but the destination website is limited by my gov,so... the compilation is slowed. solution: shutdown the network of pc. Try running with --nodeps (or --no-deps on phone so cant check). It will make dub stop contacting the network. Thanks very much, this option works fine.
Error: conflicting Ddoc and obj generation options
mono-d is running on centos7 with options below:
first:
{
name: ezsock,
targetType: executable,
description: A minimal D application.,
copyright: Copyright © 2015, zhmt,
authors: [zhmt],
mainSourceFile: source/app.d,
dependencies: {
gamelibd: {path:../gamelibd}
},
lflags:[-L../bin],
workingDirectory:../bin,
targetPath:../bin,
}
second:
{
name: gamelibd,
targetType: sourceLibrary,
description: A minimal D application.,
copyright: Copyright © 2015, zhmt,
authors: [zhmt],
lflags:[-L../bin],
workingDirectory:../bin,
targetPath:../bin,
}
The compilation complains that:
Compiling using dmd...
Error: conflicting Ddoc and obj generation options
FAIL
.dub/build/application-debug-linux.posix-x86_64-dmd_2067-3E65324D543ED19695028F22620736D3/
ezsock executable
Error executing command build:
dmd failed with exit code 1.
Exit code 2
I cant figure out whats wrong with it. The almost same program
compiles and runs
well on mac osx.
I was stuck for almost a day, Thanks for your help in advance!
Re: CTFE template predicates
On 2015-05-04 03:52:21 +, Rikki Cattermole said: Have you looked at my book? https://leanpub.com/ctfe No, thanks for the hint. You will have one more reader ;-) -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: CTFE template predicates
On 2015-05-03 23:28:00 +, anonymous said:
Here T would have to be a type. But you want to accept a string. So:
template startsNotWith(string s,char c){
enum startsNotWith = s.length == 0 || s[0] != c;
}
Hi, ok, just to better understand this (I have a C++ background (even
quite old)): When I want to use some functions I need to specify the
type? It's not possible to use T.length() which would compile if T is a
string? I thought that it's just generic and I can throw in T.
1. How do predicates get their argument(s)? I saw code where only the
predicate was mentioned but no arguments. So, I assume there is some
behind-the-curtain-magic going on. I read about things like a == b
where I can reference 'a and 'b in a string.
Predicates are called/instantiated by the thing to which you pass them.
StaticFilter instantiates pred for each element of the T tuple it's
given. If some documentation doesn't say how the predicate will be
called/instantiated, then it's probably assumed to be obvious.
Well, and often it's obvious that it's not obvious ;-)
String predicates are turned into functions behind the curtains. The
thing you instantiate with a == b turns it into `(a, b) {return a ==
b;}` and uses that. I think we don't do string predicates for templates
like StaticFilter, though.
Ok, that helps to better understand how this works.
Thanks for the feedback.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: CTFE template predicates
On 2015-05-03 23:28:00 +, anonymous said:
You need to turn T into a parameter, so that StaticFilter can set it.
(And it's really a string again, so I'm renaming to s.)
template startsNotWithp(string s)
{
enum startsNotWithp = startsNotWith!(s, 'p');
}
/* Shorthand syntax: enum startsNotWithp(string s) = startsNotWith!(s, 'p'); */
alias rules = StaticFilter!(startsNotWithp, org_rules);
Hi, I have one more questions: Is it possible to write something like this?
alias rules = StaticFilter!(startsNotWith(?, 'p'), org_rules);
The ? should be used for every memember of org_rules.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: CTFE template predicates
On Monday, 4 May 2015 at 11:22:16 UTC, Robert M. Münch wrote:
Hi, ok, just to better understand this (I have a C++ background
(even quite old)): When I want to use some functions I need to
specify the type? It's not possible to use T.length() which
would compile if T is a string? I thought that it's just
generic and I can throw in T.
In template parameter lists, a solitary identifier is a type
parameter. You can only pass types in those.
In function (pointer) declarations, a solitary identifier is the
type of the parameter.
In function/delegate literals, a solitary identifier is the name
of the parameter and the type is inferred. I guess this is what
you were thinking of.
void main()
{
template t(T) {} /* T is a template type parameter. */
alias i = t!int; /* It can be instantiated with the type int,
for example, */
static assert(!__traits(compiles, t!123)); /* but not with a
value. */
void function(int) fp; /* int is the type of the parameter. */
fp = (x) {}; /* x is the name of the parameter whose type is
inferred from above. */
}
Re: CTFE template predicates
On 4/05/2015 11:15 p.m., Robert M. Münch wrote: On 2015-05-04 03:52:21 +, Rikki Cattermole said: Have you looked at my book? https://leanpub.com/ctfe No, thanks for the hint. You will have one more reader ;-) I'm currently live streaming, feel free to jump on and ask any questions! https://www.livecoding.tv/alphaglosined/
Re: CTFE template predicates
On Monday, 4 May 2015 at 11:41:23 UTC, Robert M. Münch wrote: Hi, I have one more questions: Is it possible to write something like this? alias rules = StaticFilter!(startsNotWith(?, 'p'), org_rules); The ? should be used for every memember of org_rules. No, we don't have template literals.
Re: Is this expected? default to public members in private class
ketmar ket...@ketmar.no-ip.org writes: On Sun, 03 May 2015 18:07:20 -0700, Dan Olson wrote: It seems a private class or struct defaults to public members. Just curious if this is intended. I would have expected private all the way down unless overriden. i bet it is intended. protection of struct/class members is independed of protection of struct/class itself. this is good for code consistency: no changing of outer protection flags can alter struct/class inner machinery. so if you changed your mind about protection level of some global things, you shouldn't unnecessary fix your code in completely unrelated places. Thanks ketmar, that makes sense. I am in midst of adding an option to have dscanner skip private/package declarations when emitting etags (new --etags option) and I want to match what the D lang spec would say is private (if it did say). For now I have to reverse engineer based on compiler and forums, but don't want to mimic a compiler bug.
Re: Converting (casting?) a dynamic array to a fixed array?
Many thanks. Just to recap, I got the code working with: glBufferData(GL_ARRAY_BUFFER, (verts.sizeof * verts.length), verts.ptr, GL_STATIC_DRAW); sizeof on a slice doesn't do what you think it does, it returns the size of the actual slice object I believe. I have to admit that I didn't understand the above sentence until I did the following. Since this is a learning forum, I'll post all the details for other learners. GLfloat[6] staticVerts = [ 0.0, 1.0, -1.0, -1.0, 1.0, -1.0 ]; GLfloat[] dynamicVerts = [ 0.0, 1.0, -1.0, -1.0, 1.0, -1.0 ]; staticVerts.length (num elements) = 6 staticVerts.sizeof (num bytes) = 24 before glBufferData Press any key to continue . . . dynamicVerts.length (num elements) = 6 dynamicVerts.sizeof (num bytes) = 8 before glBufferData Press any key to continue . . . I see on the site under Array Properties Static array properties are: .sizeof Returns the array length multiplied by the number of bytes per array element. Dynamic array properties are: .sizeof Returns the size of the dynamic array reference, which is 8 in 32-bit builds and 16 on 64-bit builds. So that was my mistake. But just for arguments sake, wouldn't it have been better to define in dynamic array properties a .sizeofref and a .sizeof (which behaves like the static array.sizeof)?
CTFE enums static assert
I find this a bit strange: // get all rules that start with p... enum BolRules = StaticFilter!(beginsWithP, __traits(allMembers,BolSource)); static assert(is(BolRules == enum)); Compiling using dmd... source/app.d(114): Error: static assert (is(BolRules == enum)) is false I'm trying to construct an enum that can be used in a final switch to check if all cases were handled. But so far it's not working, because I can't get the enum constructed. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: CTFE enums static assert
On Mon, 04 May 2015 18:21:59 +0200, Robert M. Münch wrote:
I find this a bit strange:
// get all rules that start with p...
enum BolRules = StaticFilter!(beginsWithP,
__traits(allMembers,BolSource));
static assert(is(BolRules == enum));
Compiling using dmd...
source/app.d(114): Error: static assert (is(BolRules == enum)) is false
I'm trying to construct an enum that can be used in a final switch to
check if all cases were handled. But so far it's not working, because I
can't get the enum constructed.
that's due to `enum` keyword abusing. enum type is something like this:
enum MyEnum { A, B }
and
enum val = false;
is a compile-time boolean constant, which will be inlined on using. i.e.
compiler will inline such enum constants, and that constants has the
corresponding type, they aren't enums.
signature.asc
Description: PGP signature
Re: A slice can lose capacity simply by calling a function
On Monday, 4 May 2015 at 06:23:42 UTC, Ali Çehreli wrote: On 05/03/2015 06:06 PM, Jonathan M Davis via Digitalmars-d-learn wrote: (I am eagerly waiting for your DConf talk to see how you make sense of it all.) Well, we'll see how much I'm able to cover about arrays. The focus of the talk is on ranges, not arrays, so I don't know if talking much about non-range stuff like array capacity is going to fit in with everything else that needs to be discussed that _is_ specific to ranges. I'd like to discuss it though. Regardless, I keep meaning to write an article on ranges, and I'm increasingly convinced that I should take a crack at writing one on arrays, since while Steven's article is quite enlightening, I think that it approaches things the wrong way (e.g. it focuses on the memory buffers that the runtime manages rather than the dynamic arrays themselves) and uses the wrong terminology (e.g. talking about the memory buffers that the runtime manages as being dynamic arrays, when according to the language spec T[] is a dynamic array, and what it refers to really doesn't matter with regards to whether it's a dynamic array or not). So, I'll probably turn some portion of my talk into an article or two, and there won't be the same time pressures there. At this point, I feel like I have how dynamic arrays work well ironed out in my head and that it's actually pretty straightforward, but in general, we seem to do a poor job of explaining it in a straightforward manner, which results in far more confusion on the topic than I think there should be. For the most part, D's dynamic arrays just work. I know you are not trolling but I can't take your brushing off this issue with phares like for the most part. That's the frigging problem! For the most part is not sufficient. Unless somebody explains the semantics in a consistent way, I will continue to try to do it myself. (Remember: Never append to a parameter slice. Good function, good!) Aside from performance considerations, you can pretty much ignore the capacity issue. The only other concern that it raises is whether two dynamic arrays still refer to the same memory block, and once you append to either of them, you can't assume that they do, and you can't assume that they don't (though it's easy enough to check via their ptr properties). That can be managed on some level by checking the capacity ahead of time, but really, once you start appending, you have to treat each slice as possibly separate, and if you want to guarantee it, you really need to use dup or idup. But most code just doesn't need to care about capacity. And if you really do need to care, odds are that you can either fix the problem with a reserve call or by using Appender, or you should just not use dynamic arrays directly. In general, I'd consider code that was worrying much about the capacity of dynamic arrays to be error-prone - or at least that it's not going about things in the best way. By its very nature, it's likely to end up being inefficient and is too likely to care about whether two dynamic arrays refer to the same memory or not. Dynamic arrays are badly designed for situations where you can have random stuff appending to your array. They just are. Because there's no ownership, and they're not full reference types, making it trivial to end up with something appended to one dynamic array but not actually end up on the one you want it on. As such, I'd argue that anything that's doing a lot of random appending to arrays shouldn't be using dynamic arrays (at least, not without wrapping them so that there's clear ownership of the memory). So, ultimately, I see array capacity as being pretty much a non-issue, because most code that would care much about is going about things in the wrong way. But maybe what we need is a clear set of guidelines about how dynamic array slices should be managed so that they're generally used efficiently and without risking weird behavior due to expecting two dynamic arrays to refer to the same array when they don't. In general though, I'd argue that code should be constructing arrays up front and then processing them as ranges and not doing a lot of appending to them later. In particular, if you do a lot of appending and removals as you go along, it's going to be a performance hit, and you seriously risk having trouble due to having operated on a slice of the dynamic array you actually wanted to operate on. - Jonathan M Davis
Re: CTFE enums static assert
On 2015-05-04 17:21:34 +, ketmar said:
that's due to `enum` keyword abusing. enum type is something like this:
enum MyEnum { A, B }
and
enum val = false;
is a compile-time boolean constant, which will be inlined on using. i.e.
compiler will inline such enum constants, and that constants has the
corresponding type, they aren't enums.
Hmm... Ok, I understand that these seems to be two different things.
Not sure if I now understand this correct then:
enum A {a, b, c};
enum members1 = __traits(allMembers, A);
auto members2 = __traits(allMembers, A);
pragma(msg, typeof(members1));
pragma(msg, typeid(members1));
pragma(msg, typeof(members2));
pragma(msg, typeid(members2));
Gives this:
(string, string, string)
playground.d(9): Error: no type for typeid(members1)
playground.d(9):while evaluating pragma(msg, typeid(members1))
(string, string, string)
playground.d(12): Error: no type for typeid(members2)
playground.d(12):while evaluating pragma(msg, typeid(members2))
1. So the (string, string, string) output is based on the expression of
members1? Meaning, the right-hand-side.
2. I'm wondering why members1 doesn't has a type at all. So, we don't
have a compile-time boolean?
3. For members2, where auto is used, I would expect that the return
type of allMembers is used. Which would be a tuple. But again, no
type for members2. Which I find quite strange.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: Converting (casting?) a dynamic array to a fixed array?
On 05/04/2015 08:36 AM, WhatMeWorry wrote: But just for arguments sake, wouldn't it have been better to define in dynamic array properties a .sizeofref and a .sizeof (which behaves like the static array.sizeof)? It would not work because 1) .sizeof means the size of the variable that a piece of code is dealing with, regardless of the size of data that it may own or manage. 2) It is and must be a compile-time property used in templates. Ali
Re: CTFE template predicates
On 2015-05-04 03:52:21 +, Rikki Cattermole said: Have you looked at my book? https://leanpub.com/ctfe I bought it. Will it be updated? It's very generic with respect the concept and I'm missing code examples for all the user-cases. Especially the generator part is IMO very interesting. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: CTFE enums static assert
On 05/04/2015 11:07 AM, Robert M. Münch wrote:
enum A {a, b, c};
enum members1 = __traits(allMembers, A);
auto members2 = __traits(allMembers, A);
1. So the (string, string, string) output is based on the expression of
members1? Meaning, the right-hand-side.
There are many different kinds of tuples in D, only two of which I can
handle:
1) Tuple from std.typecons, which are ordinarily created at run time
2) TypeTuple from std.typetuple, which are compile-time entities
The documentation is not clear that __traits(allMembers) returns a
TypeTuple, which additionally has a bad name.
TypeTuple is great because it enables compile-time foreach
(unfortunately, implicitly):
foreach (m; __traits(allMembers, A)) {
// This body is repeated for each member at compile time
}
It is also possible to expand members of a TypeTuple just by putting it
inside an array:
[ __traits(allMembers, A) ]On 05/04/2015 11:07 AM, Robert M. Münch wrote:
enum A {a, b, c};
enum members1 = __traits(allMembers, A);
auto members2 = __traits(allMembers, A);
1. So the (string, string, string) output is based on the expression of
members1? Meaning, the right-hand-side.
There are many differents kinds of tuples in D, only two of which I can
handle:
1) Tuple from std.typecons, which are ordinarily created at run time
2) TypeTuple from std.typetuple, which are compile-time entities
The documentation is not clear that __traits(allMembers) returns a
TypeTuple, which additionally has a bad name.
TypeTuple is great because it enables compile-time foreach
(unfortunately, implicitly):
foreach (m; __traits(allMembers, A)) {
// This body is repeated for each member at compile time
}
It is also possible to expand members of a TypeTuple just by putting it
inside an array:
[ __traits(allMembers, A) ]
However, it should be obvious that all members must have a common type
to be members of the same array. (True to its name, TypeTuple can have
types themselves as well.)
Powerful stuff. :)
2. I'm wondering why members1 doesn't has a type at all.
Because it is a TypeTuple of values of various types and even types
themselves.
So, we don't
have a compile-time boolean?
I don't understand that one. :(
Ali
However, it should be obvious that all members must have a common type
to be members of the same array. (True to its name, TypeTuple can have
types themselves as well.)
Powerful stuff. :)
2. I'm wondering why members1 doesn't has a type at all.
Because it is a TypeTuple of values of various types and even types
themselves.
So, we don't
have a compile-time boolean?
I don't understand that one. :(
Ali
Re: type switch
On Monday, 4 May 2015 at 22:48:37 UTC, Dennis Ritchie wrote: Why not put in Phobos shorter design type switch: *More precisely, not in Phobos and DMD.
Re: CTFE template predicates
On 5/05/2015 6:24 a.m., Robert M. Münch wrote: On 2015-05-04 03:52:21 +, Rikki Cattermole said: Have you looked at my book? https://leanpub.com/ctfe I bought it. Will it be updated? It's very generic with respect the concept and I'm missing code examples for all the user-cases. Especially the generator part is IMO very interesting. It's due for an update. Basically I just need to be told what people want. Otherwise I'll be doing it blind!
Re: FreeTree eviction strategy
On 5/05/2015 5:56 a.m., Andrei Alexandrescu wrote:
So I'm toying around with a promising structure that I call free tree
for std.allocator. There's some detail with code and docs here:
http://forum.dlang.org/thread/mi1qph$cgr$1...@digitalmars.com.
A free tree allocator is akin to a free list. Instead of just a singly
linked list, it also maintains a binary search tree sorted by size. So
each free chunk contains the size, the next node, and left/right
children.
Insertion in the free tree is done to the root, i.e. the newly inserted
block becomes the root. Just like the free list. So we got nice locality
etc. and no need to worry about rebalancing. Code came in really small
and clean, textbook-like.
All in all free tree is like an adaptive battery of freelists - it just
adapts to whichever sizes you allocate the most.
And herein lies the danger. As allocation patterns come and go, chunks
of less-frequently-used lengths get pushed toward the leaves of the tree
and there's nothing to limit growth. So we have fragmentation because
the free tree is holding onto all those old chunks etc.
What's needed is a good eviction strategy that's cheap (e.g. doesn't
require me to hold age info or run complex algos) and effective. One
hamfisted solution is to just blow away the tree once in a while (e.g.
when it gets to a specific size or after some time/number of
allocations) but I feel there's something more principled out there.
I'd love to hear your thoughts.
Thanks,
Andrei
This may sound crazy BUT:
struct MyPointer {
void* ptr;
alias ptr this;
}
void* allocate() {
// do the actual allocation
MyPointer* ret = new MyPointer(thePtr);// something better?
// store ret
return ret;
}
void cleaner() {
MyPointer*[] toMerge;
foreach(pointer; pointers) {
// detect small but mergable items
}
foreach(toM; toMerge) {
// re assign the ptr
}
}
In essence make small allocations big by reallocating them to be bigger.
Re: std.xml2 (collecting features)
On 5/05/2015 10:45 a.m., Liam McSherry wrote: On Sunday, 3 May 2015 at 17:39:48 UTC, Robert burner Schadek wrote: std.xml has been considered not up to specs nearly 3 years now. Time to build a successor. I currently plan the following featues for it: - SAX and DOM parser - in-situ / slicing parsing when possible (forward range?) - compile time switch (CTS) for lazy attribute parsing - CTS for encoding (ubyte(ASCII), char(utf8), ... ) - CTS for input validating - performance Not much code yet, I'm currently building the performance test suite https://github.com/burner/std.xml2 Please post you feature requests, and please keep the posts DRY and on topic. Not a feature, but if `std.data.json` [1] gets accepted in to Phobos, it may be something to consider naming this `std.data.xml` (although that might not as effectively differentiate it from `std.xml`). [1]: http://wiki.dlang.org/Review_Queue It really should be std.data.xml. To keep with the new structuring. Plus it'll make transitioning a little easier.
Re: Adding a read primitive to ranges
On Monday, 4 May 2015 at 00:07:27 UTC, Freddy wrote:
Would it be a bad idea to add a read primitive to ranges for
streaming?
struct ReadRange(T){
size_t read(T[] buffer);
//and | or
T[] read(size_t request);
/+ empty,front,popFront,etc +/
}
Also if so, What about adding a default read for input ranges.
Something like
typeof(range.front)[] read(R)(ref R range,size_t amount){
auto data=new typeof(range.front)[amount];
/+... read into data ...+/
return data[0..actual_amount];
}
Re: Efficiently passing structs
On Mon, 04 May 2015 00:16:03 -0400, Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: D will move the argument if it can rather than copying it (e.g. if a temporary is being passed in), which reduces the need for worrying about copying like you tend to have to do in C++98, and I think that a lot of D code just doesn't worry about the cost of copying structs. How exactly would you move a struct? Just a memcpy without the postblit? However, if you have a large object that you know is going to be expensive to copy, you're either going to have to use const ref (and thus probably duplicate the function to allow rvalues), or you're going to need to make it a reference type rather than having all of its data live on the stack (either by making it so that the struct contains a pointer to its data or by making it a class). In general, if you're dealing with a type that is going to be expensive to copy, I'd advise making it a reference type over relying on const ref simply because it's less error-prone that way. It's trivial to forget to use ref on a parameter, and generic code won't use it, so it'll generally work better to just make it a reference type. - Jonathan M Davis Something like a Matrix4x4 lives in an awkward place between a class and a struct. Because of the fact that a graphics engine may have to deal with thousands of them per frame, both copying them at function calls, and allocating/collecting thousands of them per frame, are both unacceptable. I was reading up(DIP36, pull requests, forum) and it seems like auto ref was supposed to do something like this. Is there a reason you didn't mention it? Why not just add rvref to D? rvref would be the same as ref, but would accept an lvalue or an rvalue without copying. You could make it const, scope, or whatever you want. It would be unsafe if used incorrectly, but thats what regular ref is for. I suppose additional security could be added though, like making rvref escape-proof by default. This would introduce no breaking changes and facilitate efficient passing of structs. Bit
Re: Adding a read primitive to ranges
On Monday, 4 May 2015 at 23:20:57 UTC, Alex Parrill wrote:
On Monday, 4 May 2015 at 19:23:08 UTC, Freddy wrote:
On Monday, 4 May 2015 at 15:16:25 UTC, Alex Parrill wrote:
The ploblem is that all the functions in
std.range,std.algorithm and many other wrappers would ignore
byChucks and produce much slower code.
How so? `file.byChunks(4096).joiner` is a range that acts as if
you read each byte out of the file one at a time, but actually
reads them in 4096-byte buffers. It's still compatible with all
of the range and algorithm functions.
Reading an arbitrary number of data after being wrapped.
For example
void func(R)(R range){//expects range of strings
string[] elms=range.read(5);
string[] elms2=range.read(9);
/++..++/
}
void caller(){
auto file=...;//unbuffered file
file.map!(a=a.to!string).func();
}
Using byChucks would cause much more reallocation.
Re: This Week in D #15: hackathon, mem management, ARM, tip for C coders
On 5/05/2015 7:01 a.m., Adam D. Ruppe wrote: On Monday, 4 May 2015 at 03:50:57 UTC, Rikki Cattermole wrote: A pet peeve from the community section might be a great idea! If you ever want to rant, type it up and email it to me, I'll work it in! BTW I also have a window open on my browser somewhere to chat with you about audio stuff. Been pretty busy lately but want you to know that I haven't forgotten! Awesome sweet!
Re: std.xml2 (collecting features)
On Sunday, 3 May 2015 at 17:39:48 UTC, Robert burner Schadek wrote: std.xml has been considered not up to specs nearly 3 years now. Time to build a successor. I currently plan the following featues for it: - SAX and DOM parser - in-situ / slicing parsing when possible (forward range?) - compile time switch (CTS) for lazy attribute parsing - CTS for encoding (ubyte(ASCII), char(utf8), ... ) - CTS for input validating - performance Not much code yet, I'm currently building the performance test suite https://github.com/burner/std.xml2 Please post you feature requests, and please keep the posts DRY and on topic. maybe off-topic, but it would be nice if the standard json,xml, etc etc all had identical interfaces(except for implementation-specific quirks.) This might be something worth discussing if it wasn't already agreed upon.
RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
Read on GitHub: https://github.com/JinShil/minimal_druntime_experiment There was recently a discussion about how we could create a portable, pay-as-you-go, D runtime to help bring the promise of D to free-standing platforms and devices with tight resource constraints (e.g. microcontrollers). Thread started here: http://forum.dlang.org/post/mhrs4p$31id$1...@digitalmars.com The primary motivation is to create an arm-none-eabi GDC cross-compiler toolchain for programming ARM Cortex-M microcontrollers in D, but I think there's a way to achieve broader platform support by delegating implementation details down the supply chain. I hope to articulate that strategy in this post. To prove the concept, provide a place to start, and discuss ideas, I created the most minimal D runtime I could: https://github.com/JinShil/minimal_druntime_experiment. I've also included Phobos, so we could still have `std.stdio.write` and `std.stdio.writeln` for console output, as every device needs a console for development. Overview ** d ├── phobos │ └── std └── runtime └── rt └── typeinfo ports ├── arm │ └── cortexm4 │ ├── phobosWe │ │ └── phobosPort.d │ └── runtime │ └── runtimePort.d ├── posix │ └── linux │ ├── phobos │ │ └── phobosPort.d │ └── runtime │ ├── c_types.d │ └── runtimePort.d There are two main folders: d and ports. d provides the patform-agnostic code, or code that is relevant to a large number of platforms. The ports directory provides the platform-specific implementation. Building simply requires importing d/runtime, d/phobos, and your platform's hierarchy in the ports folder. At the moment, I've only implemented a Linux 64-bit port and an ARM Cortex-M4 port to illustrate the concept. This is roughly how I wish the official runtime could be structured in the spirit of Issue 11666. The official runtime includes platform-specific bindings in `core.sys` and `stdc`, but I think that is a design anomaly. While a port may find it convenient to use those bindings, they should not be part of the D language's public API. Rather, they should be deported to Deimos, and if needed, imported privately by a platform's port. For the Linux port, I chose to write the platform's system calls in assembly to illustrate that it is not even necessary to use those bindings if one wants to do the due diligence in D. Porting to a New Platform ** The platform-agnostic code in d delgates implementation details to the platform-specific code using `extern(C) extern _d_sys_name` system calls (for lack of a better term). This is how the newlib C library delegates platform-specific implementations: See http://wiki.osdev.org/Porting_Newlib#newlib.2Flibc.2Fsys.2Fmyos.2Fsyscalls.c At the moment, for the sake of demonstration, only 2 system calls have been defined: * `__d_sys_write` - Equivalent to C's `write` system call * `__d_sys_exit` - Equivalent to C's `exit` system call These two system calls allow us to create a simple Hello World. runtimePort.d implements `__d_sys_exit` and phobosPort.d implements the `__d_sys_write`. Putting it all Together Users are not expected to use this code directly. Rather, I envision toolchain, silicon, and board vendors will use this code as a small, but essential part of, their platform's D programming package. For example, a package for the ARM Cortex-M family of MCUs might contain the following: * arm-none-eabi GDC cross-compiler * a library containing compiled code for the d folder in this repository * a library containing the compiled code for the ports/arm/cortexm folders in this repository * cortex-m core startup files * the newlib C library * the C library bindings from Deimos * multilibs from the GNU toolchain. A silicon vendor like ST, may then take that package and add more platform-specific for their family of products: * startup files with interrupt vectors for their peripherals * linker scripts for each of their MCUs * flash memory programmer * library for on-dye peripherals * etc.. A board vendor may choose to create yet another layer on top of the silicon vendor's package. * library for peripherals external to the MCU (external RAM, IO expanders, gyroscope, LCD, etc...) In short, this repository just provides just the foundation to get D working, and delegates to toolchain, silicon, and board vendors to fill in the details for their products. RFC * For those who have stake in this code base (kernel developers, embedded developers, toolchain and package maintainers, etc...) your constructive criticism and ideas are most welcome. I am unsure yet how this will play out, and what roles players will assume, but let's give it a try. Plea to Compiler Implementers *** We need better control over codegen. TypeInfo and
Re: Adding a read primitive to ranges
On Tuesday, 5 May 2015 at 00:50:44 UTC, Freddy wrote:
void func(R)(R range){//expects range of strings
string[] elms=range.read(5);
string[] elms2=range.read(9);
/++..++/
}
void caller(){
auto file=...;//unbuffered file
file.map!(a=a.to!string).func();
}
Wait, Bad example,
void func(R)(R range){//expects range of ubyte
ubyte[] data=range.read(VERY_BIG_NUMBER);
ubyte[] other_data=range.read(OTHER_VERY_BIG_NUMBER);
}
which would be more optimal for a file but still works for other
ranges, compared to looping though the ranges read appending to
data.
opEquals optimized away?
class C{
override bool opEquals( Object o){
return true;
}
}
unittest{
auto c= new C;
assert( c == c);
}
`rdmd --main -unittest -cov' shows, that opEquals is not
executed. Why?
-manfred
Re: Efficiently passing structs
On Tuesday, 5 May 2015 at 02:47:03 UTC, bitwise wrote:
On Mon, 04 May 2015 00:16:03 -0400, Jonathan M Davis via
Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
D will move the argument if it can rather than copying it
(e.g. if a
temporary is being passed in), which reduces the need for
worrying about
copying like you tend to have to do in C++98, and I think that
a lot of D
code just doesn't worry about the cost of copying structs.
How exactly would you move a struct? Just a memcpy without the
postblit?
However, if you have a large object that you know is going to
be
expensive to copy, you're either going to have to use const ref
(and thus probably duplicate the function to allow rvalues), or
you're going to need to make it a reference type rather than
having all of its data live on the stack (either by making
it so that the struct contains a pointer to its data or by
making it a
class).
In general, if you're dealing with a type that is going to be
expensive to copy, I'd advise making it a reference type over
relying on
const ref simply because it's less error-prone that way. It's
trivial to
forget to use ref on a parameter, and generic code won't use
it, so it'll
generally work better to just make it a reference type.
- Jonathan M Davis
Something like a Matrix4x4 lives in an awkward place between a
class and a struct. Because of the fact that a graphics engine
may have to deal with thousands of them per frame, both copying
them at function calls, and allocating/collecting thousands of
them per frame, are both unacceptable.
I was reading up(DIP36, pull requests, forum) and it seems like
auto ref was supposed to do something like this. Is there a
reason you didn't mention it?
it does, auto ref can bind to both lvalues and rvalues. Create
the function with an empty template like so,
import std.stdio;
struct S{
}
void Foo()(auto ref S s){
}
void main(){
S s;
Foo(s);
Foo(S());
}
There might be other ways that I'm unaware of.
Why not just add rvref to D?
D is already bloated.
Re: opEquals optimized away?
On Tuesday, 5 May 2015 at 04:09:03 UTC, Manfred Nowak wrote:
class C{
override bool opEquals( Object o){
return true;
}
}
unittest{
auto c= new C;
assert( c == c);
}
`rdmd --main -unittest -cov' shows, that opEquals is not
executed. Why?
-manfred
because `c is c`
https://github.com/D-Programming-Language/druntime/blob/0ac255d7276b9b825eb6f1e677e9ee4f5ad49ca2/src/object.di#L61
Re: std.xml2 (collecting features)
On 5/4/2015 2:35 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: Wouldn't D-ranges make it impossible to use SIMD optimizations when scanning? Not at all. Algorithms can be specialized for various forms of input ranges, including ones where SIMD optimizations can be used. Specialization is one of the very cool things about D algorithms.
Re: std.xml2 (collecting features)
On 5/4/2015 12:28 PM, Jacob Carlborg wrote: On 2015-05-03 19:39, Robert burner Schadek wrote: Not much code yet, I'm currently building the performance test suite https://github.com/burner/std.xml2 I recommend benchmarking against the Tango pull parser. I agree. The Tango XML parser has set the performance bar. If any new solution can't match that, throw it out and try again.
asm.dlang.org updated
Hi, I've updated asm.dlang.org site. Apart from rebasing upstream fixes, the only notable difference is that I've added in DMD 2.067.1 to the list of compilers. That's all really. Regards Iain.
type switch
Good day to all!
I've been thinking. In D you can write a similar design to the
generic functions or somewhere, use static if:
// -
static if (is(T == short) || is(T == int) || is(T == long)) {
// do anything
} else static if (is(T == real)) {
// ...
} else static if (is(T == char)) {
// ...
} else static if (is(T == string)) {
// ...
} else static if (is(T == int[])) {
// ...
} else {
// ...
}
Why not put in Phobos shorter design type switch:
// -
type switch (T) {
case short, int, long:
// do anything
case real:
// ...
case char:
// ...
case string:
// ...
case int[]:
// ...
default:
// ...
}
This design has been implemented, for example, in Common Lisp
(typecase):
http://www.lispworks.com/documentation/lw51/CLHS/Body/m_tpcase.htm
What do you think about this?
DMD phobos built with contracts check for win?
I have to compile it myself from sources or is it available somewhere? Was playing with fibers using VisualD + DMD and lack of contract checking (for example call() on fiber in state TERM) leads to bizarre crashes :(
Re: Adding a read primitive to ranges
On Monday, 4 May 2015 at 19:23:08 UTC, Freddy wrote: On Monday, 4 May 2015 at 15:16:25 UTC, Alex Parrill wrote: The ploblem is that all the functions in std.range,std.algorithm and many other wrappers would ignore byChucks and produce much slower code. How so? `file.byChunks(4096).joiner` is a range that acts as if you read each byte out of the file one at a time, but actually reads them in 4096-byte buffers. It's still compatible with all of the range and algorithm functions.
Re: CTFE enums static assert
On Mon, 04 May 2015 20:07:27 +0200, Robert M. Münch wrote: Gives this: (string, string, string) playground.d(9): Error: no type for typeid(members1) playground.d(9):while evaluating pragma(msg, typeid(members1)) `typeid` is runtime thing, you can't use it in compile-time. besides, as Ali said, `allMembers` returns tuple, which is very special thing that exists only in compile-time. 1. So the (string, string, string) output is based on the expression of members1? Meaning, the right-hand-side. that's three field names for `enum A`. and field name is a string. 2. I'm wondering why members1 doesn't has a type at all. So, we don't have a compile-time boolean? it's a tuple. actually, `(string, string, string)` is a special type. 3. For members2, where auto is used, I would expect that the return type of allMembers is used. it is. ;-) Which would be a tuple. But again, no type for members2. Which I find quite strange. as i said, `typeid` is runtime feature, so you can't print it with pragma. and tuples aren't exist in runtime, it's compile-time only. i think you are even more confused now. ;-) sorry. signature.asc Description: PGP signature
