Re: Error Ocuured while building DWT
Maybe i need to reformat the error i posted, couldnt find a post edit button anywhere so.. [pre] (in C:\Users\kolawole\Desktop\codetmp\dwt) Building dwt-base workdir=C:\Users\kolawole\Desktop\codetmp\dwt\base\src dmd.exe @C:\Users\kolawole\Desktop\codetmp\dwt\rsp java\nonstandard\sync\condition.d(85): Error: java.nonstandard.sync.exception.SyncException at java\nonstandard\sync\exception.d(26) conflicts with core.sync.exception.SyncException at C:\dmd\src\druntime\import\core\sync\exception.di(3) java\nonstandard\sync\condition.d(90): Error: java.nonstandard.sync.exception.SyncException at java\nonstandard\sync\exception.d(26) conflicts with core.sync.exception.SyncException at C:\dmd\src\druntime\import\core\sync\exception.di(3) object.Exception@build.d(251): compile error 0x004049F6 0x00405AC5 0x00403C05 0x004165BA 0x0041658F 0x004164A5 0x0040FE77 0x772F3833 in BaseThreadInitThunk 0x778DA9BD in LdrInitializeThunk [/pre]
Error Ocuured while building DWT
Hi guys(and ladies), i cloned the dwt repository this morning at about 7:45am and after cloning completed, i tried to build the dwt library with the $ rdmd build base swt command provided in the dwt github page's readme. Here and right in my face i got this pool horror...error [pre] (in C:\Users\kolawole\Desktop\codetmp\dwt) Building dwt-base workdir=C:\Users\kolawole\Desktop\codetmp\dwt\base\src dmd.exe @C:\Users\kolawole\Desktop\codetmp\dwt\rsp java\nonstandard\sync\condition.d(85): Error: java.nonstandard.sync.exception.SyncException at java\nonst andard\sync\exception.d(26) conflicts with core.sync.exception.SyncException at C:\dmd\src\druntime\impor t\core\sync\exception.di(3) java\nonstandard\sync\condition.d(90): Error: java.nonstandard.sync.exception.SyncException at java\nonst andard\sync\exception.d(26) conflicts with core.sync.exception.SyncException at C:\dmd\src\druntime\impor t\core\sync\exception.di(3) object.Exception@build.d(251): compile error 0x004049F6 0x00405AC5 0x00403C05 0x004165BA 0x0041658F 0x004164A5 0x0040FE77 0x772F3833 in BaseThreadInitThunk 0x778DA9BD in LdrInitializeThunk [/pre] i dont know what happened nor do i know how to fix this. I use a windows vista ultimate. Your quick response(preferably help) will be really appreciated guys..Thanks a lot
[Issue 14327] Unhandled exception from writeln() in C++/D application
https://issues.dlang.org/show_bug.cgi?id=14327 --- Comment #10 from Szymon Gatner szymon.gat...@gmail.com --- Did it help to reproduce? --
[Issue 14429] New: Linker error caused by a combination of multiple factors (static library, inlining, lambda alias and ref parameters)
https://issues.dlang.org/show_bug.cgi?id=14429
Issue ID: 14429
Summary: Linker error caused by a combination of multiple
factors (static library, inlining, lambda alias and
ref parameters)
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: link-failure
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: slud...@outerproduct.org
The conditions for triggering this look somewhat complex. The following targets
need to be compiled with -inline:
lib.d
---
void foo(alias F = () = true)()
{
}
void bar()
{
int _value;
unescapeStringLiteral(_value);
}
void unescapeStringLiteral(alias F = () = true)(ref int)
{
// force no-inline, using exceptions or asm { nop; } has the same effect
static bool x;
}
---
app.d
---
import lib;
void main()
{
foo();
bar();
}
---
Building with:
dmd -lib -inline -oflib.a lib.d
dmd -inline app.d lib.a
Results in:
app.o: In Funktion `_Dmain':
app.d:(.text._Dmain+0x12): Nicht definierter Verweis auf
`_D3lib58__T21unescapeStringLiteralS28_D3lib9__lambda6MFNaNbNiNfZbZ21unescapeStringLiteralFNaNbNiNfKiZv'
collect2: error: ld returned 1 exit status
--- errorlevel 1
--
[Issue 14428] Link all book formats available from dlang.org
https://issues.dlang.org/show_bug.cgi?id=14428 David Eagen da...@eagen.com changed: What|Removed |Added CC||da...@eagen.com --- Comment #1 from David Eagen da...@eagen.com --- The web site links to the wiki for the language spec. I updated the wiki to add the links to d-apt.sourceforce.net for the CHM, epub, and mobi formats. Does this resolve the issue acceptably or should the language specs be hosted directly on dlang.org? --
[Issue 3193] Support Windows-1251 as a source encoding
https://issues.dlang.org/show_bug.cgi?id=3193 Tomáš Chaloupka chalu...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED CC||chalu...@gmail.com Resolution|--- |WONTFIX --- Comment #23 from Tomáš Chaloupka chalu...@gmail.com --- I came across this and think, that this can be closed already. Unicode source files works, I don't think other encodings for source files are required anymore. Console output is another story - discussed elsewhere --
[Issue 14430] Null parameter is detected as non-null.
https://issues.dlang.org/show_bug.cgi?id=14430
--- Comment #3 from ag0ae...@gmail.com ---
(In reply to ag0aep6g from comment #2)
void setCookie(long x = 1L 32L, string y = null){
assert(b.ptr is null);
Woops, b.ptr should be y.ptr of course.
Full proper test case:
void setCookie(long x = 1L 32L, string y = null){
assert(y.ptr is null);
}
void main(){
setCookie();
}
--
[Issue 14422] std.process: Pipes do not append to files on Win64
https://issues.dlang.org/show_bug.cgi?id=14422 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/b28eb9fab8d27a7134daabf33544198bb4fbd02b fix Issue 14422 - std.process: Pipes do not append to files on Win64 https://github.com/D-Programming-Language/phobos/commit/eecc989b2c7901d1dce40c761329920b690da0c0 Merge pull request #3160 from CyberShadow/pull-20150407-122150 fix Issue 14422 - std.process: Pipes do not append to files on Win64 --
[Issue 14430] New: Null parameter is detected as non-null.
https://issues.dlang.org/show_bug.cgi?id=14430 Issue ID: 14430 Summary: Null parameter is detected as non-null. Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: major Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: 14crgg+ekargo2d7q...@sharklasers.com What: I defined a class with a single method in it. Method has 6 parameters. Other than first parameter, all others has default value. 3rd, 4th, and 5th parameters are string and their default value is null. I create an instance of that class, and call that method 2 times with only first parameter. Expected: Parameters those have null value by default should be null always. Result: In the first call, it works correctly. In the second and later calls, assert doesn't pass, and it says those parameters are not null. Test: Tested on both DMD64 D Compiler v2.066 and v2.070 on Archlinux and DMD64 D Compiler v2.070 on Ubuntu 14.04. Results are same. rdmd test.d One person reported it works correctly on LDC and rdmd test.d on Archlinux. But says that with dmd -O, and dmd -release, it works wrong as well. This problem can be generated repeatedly. --
[Issue 14430] Null parameter is detected as non-null.
https://issues.dlang.org/show_bug.cgi?id=14430 --- Comment #1 from tcak2 14crgg+ekargo2d7q...@sharklasers.com --- Created attachment 1511 -- https://issues.dlang.org/attachment.cgi?id=1511action=edit Test code that generates the problem. --
[Issue 4733] Possible bugs caused by dynamic arrays in boolean evaluation context
https://issues.dlang.org/show_bug.cgi?id=4733 --- Comment #30 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/baa98b725ac75356a29405c164743f7cea7d502d Add changelog entry for issue4733 https://github.com/D-Programming-Language/dlang.org/commit/5432fb77472a0f11078fb407a3ccc256189ec4db Merge pull request #964 from yebblies/changelog4733 Add changelog entry for issue4733 --
[Issue 14430] Null parameter is detected as non-null.
https://issues.dlang.org/show_bug.cgi?id=14430
ag0ae...@gmail.com changed:
What|Removed |Added
Keywords||wrong-code
CC||ag0ae...@gmail.com
Severity|major |regression
--- Comment #2 from ag0ae...@gmail.com ---
Reduced:
void setCookie(long x = 1L 32L, string y = null){
assert(b.ptr is null);
}
void main(){
setCookie();
}
Fails when x's default value has all zero lower 32 bits, but not all zero
higher 32 bits. y.ptr then has the value of x.
Works correctly with v2.059. Fails since v2.060.
--
[Issue 14408] std.process: Can't start interactive process from Windows GUI application
https://issues.dlang.org/show_bug.cgi?id=14408 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/237a1c14776f67c14f7e14917198bbc41428fa28 fix Issue 14408 - std.process: Can't start interactive process from Windows GUI application https://github.com/D-Programming-Language/phobos/commit/cdd73be74cdb5a2e313e17dac78470c91a54949a Merge pull request #3148 from CyberShadow/pull-20150405-052650-process-14408 fix Issue 14408 - std.process: Can't start interactive process from Wind... --
Re: Wanted: Review manager for std.data.json
On Thursday, 9 April 2015 at 12:16:43 UTC, Martin Nowak wrote: On 04/09/2015 02:10 PM, John Colvin wrote: Still getting trounced across the board by rapidjson. Yep, anyone knows why? They don't even use a lazy parser. simd optimized scanning and format-optimized inlined conversion
Re: DMD compilation speed
On Monday, 30 March 2015 at 00:12:09 UTC, Walter Bright wrote: On 3/29/2015 4:14 PM, Martin Krejcirik wrote: It seems like every DMD release makes compilation slower. This time I see 10.8s vs 7.8s on my little project. I know this is generally least of concern, and D1's lighting-fast times are long gone, but since Walter often claims D's superior compilation speeds, maybe some profiling is in order ? Sigh. Two things happen constantly: 1. object file sizes creep up 2. compilation speed slows down It's like rust on your car. Fixing it requires constant vigilance. I just did some profiling of building phobos. I noticed ~20% of the runtime and ~40% of the L2 cache misses were in slist_reset. Is this expected?
Re: Adjustor thunks and variadic arguments.
On 9 April 2015 at 14:38, Iain Buclaw ibuc...@gdcproject.org wrote: On 9 April 2015 at 13:20, Daniel Murphy via Digitalmars-d digitalmars-d@puremagic.com wrote: Iain Buclaw via Digitalmars-d wrote in message news:mailman.1364.1428563414.3111.digitalmar...@puremagic.com... If under the same object file, you can happily emit: suboffset, %thisreg jmpmethod But if doing separate compilation, many targets to not support doing such operations across section boundaries. So a more general/agnostic way to go about it is by copying all arguments, adjusting the 'this' pointer and calling target method at the codegen level. This works so long as you are not dealing with a variadic method (ie: std.stream.Stream.printf) They don't support jumping across section boundaries? But they do support calling? Anyway it sounds like sub offset, %thisreg call method ret would do it That's not copying arguments. :-) Iain. What is currently happening in GDC (Generic thunks don't support varargs though). https://github.com/D-Programming-GDC/GDC/pull/97#issuecomment-90275901
Re: Wanted: Review manager for std.data.json
Am 09.04.2015 um 21:40 schrieb Sönke Ludwig: Am 09.04.2015 um 21:37 schrieb weaselcat: On Thursday, 9 April 2015 at 19:35:24 UTC, Sönke Ludwig wrote: Am 09.04.2015 um 21:26 schrieb weaselcat: On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote: Not sure, but that may also have been my recent optimizations. Just tried it with your recent optimizations and it doesn't build with LDC 0.15.1. Should work now. I just tested LDC with -singleobj and it's faster than RapidJSON! Now the DOM parser gets interesting. What flags are you using? RapidJSON is still a lot faster for me. also, I just realized the build script has the wrong inline flag for LDC(it's using -enable-inlining instead of -inline) I'll have to test with that exact version, because I've used my own main() function for the test. The flags were: -singleobj -release -O5 -enable-inlining -disable-bondscheck (-disable-boundscheck is only a little faster). One thing about the D benchmark is that it uses readText(). To be a fair comparison with Rapid it would have to use cast(string)read() instead.
Re: Understanding the D memory model re: Voldemort types
On Thu, Apr 09, 2015 at 06:08:17PM +, Matt Kline via Digitalmars-d wrote:
[...]
auto foo()
{
import std.random;
import std.conv;
auto i = dice(0.5, 0.5);
string s = Hello, scopes;
class Bar {
string what() { return s ~ ~ i.to!string; }
}
return new Bar;
}
void main()
{
import std.stdio;
auto b = foo();
writeln(b.what());
}
I was under the impression that nested classes captured their context
via a pointer to the current stack frame. But if that were the case,
reading i and s when b.what() is called would cause invalid reads
below the current stack pointer, and this data could be thrashed by
inserting any calls between the call to foo() and the call to
b.what(). Running the above program through valgrind also indicates no
foul play.
So what is actually going on here? Do nested classes capture their
context some other way? Does the compiler do semantic analysis and
capture local variables by value if an instance of the Voldemort type
is going to get returned out of the function?
The compiler detects when a variable is being closed over by a nested
function, and allocates them on the heap instead of the stack.
T
--
Computerese Irregular Verb Conjugation: I have preferences. You have biases.
He/She has prejudices. -- Gene Wirchenko
Re: Adjustor thunks and variadic arguments.
On 9 April 2015 at 13:20, Daniel Murphy via Digitalmars-d digitalmars-d@puremagic.com wrote: Iain Buclaw via Digitalmars-d wrote in message news:mailman.1364.1428563414.3111.digitalmar...@puremagic.com... If under the same object file, you can happily emit: suboffset, %thisreg jmpmethod But if doing separate compilation, many targets to not support doing such operations across section boundaries. So a more general/agnostic way to go about it is by copying all arguments, adjusting the 'this' pointer and calling target method at the codegen level. This works so long as you are not dealing with a variadic method (ie: std.stream.Stream.printf) They don't support jumping across section boundaries? But they do support calling? Anyway it sounds like sub offset, %thisreg call method ret would do it That's not copying arguments. :-) Iain.
Re: Fun project - faster associative array algorithm
On 4/9/15 8:07 AM, Daniel Murphy wrote: Steven Schveighoffer wrote in message news:mg5pf0$1g51$1...@digitalmars.com... I really am surprised that these would be difficult at all. The lowering is pretty easy: a) T[U] = AssociativeArray!(U,T) b) [a:b, c:d] = AssociativeArray!(typeof(true ? a : c), typeof(true ? b : d)).literal(a, b, c, d); Working out what to lower to is easy, working out when to lower it is hard. Wouldn't it be whenever AA was previously invoked? I'm surprised there are any unknowns here. -Steve
Re: Wanted: Review manager for std.data.json
On Thursday, 9 April 2015 at 11:49:00 UTC, Martin Nowak wrote: On 04/08/2015 08:32 PM, tcha wrote: Now with release numbers. D new - debug - 14.98s, 1782.0Mb 8.53s, 1786.8Mb D new Gdc - debug - 29.08s, 1663.9Mb GDC still misses @nogc support. D new Ldc - 16.99s, 1663.0Mb 18.76s, 1664.1Mb D new lazy - debug - 11.50s, 213.2Mb 4.57s, 206Mb D new lazy Gdc - 13.66s, 206.1Mb Can't compile stdx.data.json with gdc-4.9.0 which doesn't yet support @nogc. D new lazy Ldc - 3.59s, 205.4Mb 4.0s, 205.4Mb LDC doesn't yet have the GC improvements, therefor is much slower for the DOM parsing benchmarks. ldc -singleobj flag speeds it up dramatically ldc2 -ofjson_d_new_lazy_ldc -O5 -release -enable-inlining -w -oq -Istd_data_json/source/ std_data_json/source/stdx/data/json/*.d test_new_lazy.d ./json_d_new_lazy_ldc 2.79s user 0.08s system 99% cpu 2.868 total ldc2 -singleobj -ofjson_d_new_lazy_ldc -O5 -release -enable-inlining -w -oq -Istd_data_json/source/ std_data_json/source/stdx/data/json/*.d test_new_lazy.d ./json_d_new_lazy_ldc 1.78s user 0.08s system 99% cpu 1.869 total for comparison: ./json_rapid_cpp 0.80s user 0.30s system 99% cpu 1.106 total Bye.
Re: Which D IDE do you use?(survey)
On 2015-04-09 11:34, Jens Bauer wrote: Xcode 2.5 is the best Xcode. There's only one IDE from Apple which is better: Project Builder! The rest of them are too broken for me. Xcode 3.x keeps spamming my console. Even if I could run Xcode 7254.9, I double they would have fixed the unicode problem and the other things they broke when they made Project Bulider fancy: I think Xcode 4 was a major improvement, it's a complete redesign. The later versions are smaller improvements on top of that. -- /Jacob Carlborg
Re: Which D IDE do you use?(survey)
On Wednesday, 8 April 2015 at 22:53:17 UTC, Idan Arye wrote: On Wednesday, 8 April 2015 at 16:02:20 UTC, eyveer wrote: On Tuesday, 7 April 2015 at 22:58:44 UTC, weaselcat wrote: Hi, I hope nobody minds but I'm just curious as to the popularity amongst D IDEs for a blog post. Sorry if I forgot your favorite $editor. http://goo.gl/forms/MmsuInzDL0 thanks : ) question to vim users - how did you configure autocomplete? https://github.com/idanarye/vim-dutyl +1
Re: DIP77 - Fix unsafe RC pass by 'ref'
On 2015-04-08 23:10:37 +, Walter Bright newshou...@digitalmars.com said:
http://wiki.dlang.org/DIP77
In the definition of a Reference Counted Object:
An object is assumed to be reference counted if it has a postblit and a
destructor, and does not have an opAssign marked @system.
Why should it not have an opAssign marked @system?
And what happens if the struct has a postblit but it is @disabled? Will
the compiler forbid you from passing it by ref in cases where it'd need
to make a copy, or will it just not be a RCO?
More generally, is it right to add implicit copying just because a
struct has a postblit and a destructor? If someone implemented a
by-value container in D (such as those found in C++), this behaviour of
the compiler would trash the performance by silently doing useless
unnecessary copies. You won't even get memory-safety as a benefit: if
the container allocates from the GC it's safe anyway, otherwise you're
referencing deallocated memory with your ref parameter (copying the
struct would just make a copy elsewhere, not retain the memory of the
original).
I think you're assuming too much from the presence of a postblit and a
destructor. This implicit copy behaviour should not be trigged by
seemingly unrelated clues. Instead of doing that:
auto tmp = rc;
the compiler should insert this:
auto tmp = rc.opPin();
RCArray can implement opPin by returning a copy of itself. A by-value
container can implement opPin by returning a dummy struct that retains
the container's memory until the dummy struct's destructor is called.
Alternatively someone could make a dummy void opPin() @system {} to
signal it isn't safe to pass internal references around (only in system
code would the implicit call to opPin compile). If you were writing a
layout-compatible D version of std::vector, you'd likely have to use a
@system opPin because there's no way you can pin that memory and
guaranty memory-safety when passing references around.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
Re: Fun project - faster associative array algorithm
On 4/9/15 11:25 AM, Daniel Murphy wrote: Steven Schveighoffer wrote in message news:mg61gn$1o09$1...@digitalmars.com... Wouldn't it be whenever AA was previously invoked? I'm surprised there are any unknowns here. It has to be done before some parts of semantic, but after others. Eg error messages and template matching still needs to be done on the AA type, but other parts need the actual template type. I think a reasonable path is to lower as early as possible, have everything show up as the template type in error messages, and then work on updating the messages over time to reflect the builtin syntax. In any case, I didn't think about template matching, those are handled specially for AA. Perhaps we can make that more generic. -Steve
Re: D Hackathon: April 25 - May 1
On Thursday, 9 April 2015 at 02:44:30 UTC, Andrei Alexandrescu wrote: Pencil the dates in your calendar! Andrei I think this is a great idea and I marked it in my calendar. Also as a suggestion, the Python community usually runs Sprints on every major conference. Basically after the main conference for 1-2 days people stay and get into a room and hack on projects. I really like that format. I am not sure what the room situation for Dconf is, but if we can have a room +1 day, I'd love to stay around for a one day more and sprint. - David
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Thursday, 9 April 2015 at 18:44:10 UTC, Walter Bright wrote: On 4/9/2015 5:05 AM, Michel Fortin wrote: Why should it not have an opAssign marked @system? Andrei's idea was to not do the copy for @system opAssign's, thus providing C++ equivalence for those folks that need it and don't care about guaranteed memory safety. Why not bind this behavior to extern(C++) ? The only real purpose to a postblit is to support ref counting. Why would a by-value container use a postblit and not ref count? In C++, the only real purpose of template were generic containers, and that didn't ended up well. It is dangerous, at language level, to reason from usage instead of first principle (not that usage do not matter, usage should serve as a guideline for the principles) or thing like C++ templates happens. My first impression is that's too complicated for the user to get right. Yeah, I don't think opPin is a the right way to go. It is always easy and tempting to add new stuff to make X or Y work, but at the end, it only create language complexity explosion. There are some inefficiencies involved here, but I trust the compiler to be able to optimize it away for the most part, and we have a backdoor for thoses who want to bypass safety. More generally, this is why I oppose the return attribute + adding op on reference type in favor of a principle scope proposal. The first one is 2 language features for a less general end result.
Re: Wanted: Review manager for std.data.json
Am 09.04.2015 um 21:37 schrieb weaselcat: On Thursday, 9 April 2015 at 19:35:24 UTC, Sönke Ludwig wrote: Am 09.04.2015 um 21:26 schrieb weaselcat: On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote: Not sure, but that may also have been my recent optimizations. Just tried it with your recent optimizations and it doesn't build with LDC 0.15.1. Should work now. I just tested LDC with -singleobj and it's faster than RapidJSON! Now the DOM parser gets interesting. What flags are you using? RapidJSON is still a lot faster for me. also, I just realized the build script has the wrong inline flag for LDC(it's using -enable-inlining instead of -inline) I'll have to test with that exact version, because I've used my own main() function for the test. The flags were: -singleobj -release -O5 -enable-inlining -disable-bondscheck (-disable-boundscheck is only a little faster).
Re: DIP77 - Fix unsafe RC pass by 'ref'
On 4/9/2015 11:53 AM, w0rp wrote: On Thursday, 9 April 2015 at 18:44:10 UTC, Walter Bright wrote: The only real purpose to a postblit is to support ref counting. Why would a by-value container use a postblit and not ref count? A struct could have a postblit defined if you are implementing something like std::vector, where you you copy the memory when the struct is copied. I'm not sure why you would want to do such a thing in D, though. I'm not sure why you'd do that, either. Just make the memory part ref counted, then when modifying it, make the copy then if your ref count 1. If you want to interface with std::vector, make opAssign @system, after all, you're dealing with C++ :-)
Re: Adjustor thunks and variadic arguments.
Iain Buclaw via Digitalmars-d wrote in message news:mailman.1364.1428563414.3111.digitalmar...@puremagic.com... If under the same object file, you can happily emit: suboffset, %thisreg jmpmethod But if doing separate compilation, many targets to not support doing such operations across section boundaries. So a more general/agnostic way to go about it is by copying all arguments, adjusting the 'this' pointer and calling target method at the codegen level. This works so long as you are not dealing with a variadic method (ie: std.stream.Stream.printf) They don't support jumping across section boundaries? But they do support calling? Anyway it sounds like sub offset, %thisreg call method ret would do it
UDAs and no complaints about need 'this'
struct BigLongStructName
{
int evenLongerMemberName;
}
struct QN{}
unittest
{
BigLongStructName bigLongStructName;
@(bigLongStructName.evenLongerMemberName)
QN quickName;
__traits(getAttributes, quickName)[0]++;
}
Is it just me or is it weird that this works? Once you pull the
UDA out from being a storage class and attempt to alias it, you
get the usual need 'this' for 'evenLongerMemberName' of type
'int' error messages on use.
Why are UDAs so special? I don't believe there's any other way to
achieve this sort of effective renaming.
Re: UDAs and no complaints about need 'this'
On Thursday, 9 April 2015 at 09:53:15 UTC, John Colvin wrote:
struct BigLongStructName
{
int evenLongerMemberName;
}
struct QN{}
unittest
{
BigLongStructName bigLongStructName;
@(bigLongStructName.evenLongerMemberName)
QN quickName;
__traits(getAttributes, quickName)[0]++;
}
Is it just me or is it weird that this works? Once you pull the
UDA out from being a storage class and attempt to alias it, you
get the usual need 'this' for 'evenLongerMemberName' of type
'int' error messages on use.
Why are UDAs so special? I don't believe there's any other way
to achieve this sort of effective renaming.
I think it's an error. When the attribute is a struct, it looks
like the member is processed as a static variable. But the
equivalent with a class raises an AV:
---
class BigLongStructName
{
int evenLongerMemberName;
}
struct QN{}
unittest
{
import std.stdio;
BigLongStructName bigLongStructName;
@(bigLongStructName.evenLongerMemberName)
QN quickName;
__traits(getAttributes, quickName)[0]++;
}
---
which is a totally expected behaviour.
Re: Wanted: Review manager for std.data.json
On 04/09/2015 10:59 AM, Sönke Ludwig wrote: As far as the profiler results can be trusted, a good chunk of the time gets spent for reading individual bytes from memory, but there must be something else low-level going on that make things this bad. However, there is nothing fundamental in the structure/design that would cause this, so I think spending more time with the profiler is the only logical step now. Unfortunately my VTune license has expired and perf on Linux makes the task quite a bit more involved. I didn't found too many issues. Most of the time is spent in parseJSONValue (looks like there are some expansive struct copies) https://github.com/s-ludwig/std_data_json/blob/1da3f828ae6c4fd7cac7f7e13ae9e51ec93e6f02/source/stdx/data/json/parser.d#L148 and skipWhitespace. This function could really take some optimization, e.g. avoid UTF decoding. https://github.com/s-ludwig/std_data_json/blob/1da3f828ae6c4fd7cac7f7e13ae9e51ec93e6f02/source/stdx/data/json/lexer.d#L345 Libdparse has some optimized ASM function, might be useful. https://github.com/Hackerpilot/libdparse/blob/51b7d9d321aac0fcc4a9be99bbbed5db3158326c/src/std/d/lexer.d#L2233
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Thursday, 9 April 2015 at 18:31:24 UTC, deadalnix wrote: On Thursday, 9 April 2015 at 09:05:10 UTC, Ola Fosheim Grøstad wrote: 2. How will this work with yield? You yield both caller and callee, so you'll get caller's boxing in the yield. But the coroutine stack and everything on it will be intact when it yields, including references to array elements...? Why not just implement the more generic solution (shared pointers with move/borrow or WPO) ? I don't think this is possible. It should be possible with pointer analysis, but the easier approach is just to ban non-const ref parameters (c++ style) for rc-pointer-objects, so maybe D should provide head const after all...
Understanding the D memory model re: Voldemort types
I have a bit of confusion about the D memory model when it comes
to returning nested classes (i.e. Voldemort types) and am
hoping someone can take a minute to clear it up. Consider the
following short program:
auto foo()
{
import std.random;
import std.conv;
auto i = dice(0.5, 0.5);
string s = Hello, scopes;
class Bar {
string what() { return s ~ ~ i.to!string; }
}
return new Bar;
}
void main()
{
import std.stdio;
auto b = foo();
writeln(b.what());
}
I was under the impression that nested classes captured their
context via a pointer to the current stack frame. But if that
were the case, reading i and s when b.what() is called would
cause invalid reads below the current stack pointer, and this
data could be thrashed by inserting any calls between the call to
foo() and the call to b.what(). Running the above program through
valgrind also indicates no foul play.
So what is actually going on here? Do nested classes capture
their context some other way? Does the compiler do semantic
analysis and capture local variables by value if an instance of
the Voldemort type is going to get returned out of the function?
Re: Wanted: Review manager for std.data.json
On 4/9/15 5:10 AM, John Colvin wrote: On Thursday, 9 April 2015 at 11:49:00 UTC, Martin Nowak wrote: On 04/08/2015 08:32 PM, tcha wrote: Now with release numbers. D new - debug - 14.98s, 1782.0Mb 8.53s, 1786.8Mb D new Gdc - debug - 29.08s, 1663.9Mb GDC still misses @nogc support. D new Ldc - 16.99s, 1663.0Mb 18.76s, 1664.1Mb D new lazy - debug - 11.50s, 213.2Mb 4.57s, 206Mb D new lazy Gdc - 13.66s, 206.1Mb Can't compile stdx.data.json with gdc-4.9.0 which doesn't yet support @nogc. D new lazy Ldc - 3.59s, 205.4Mb 4.0s, 205.4Mb LDC doesn't yet have the GC improvements, therefor is much slower for the DOM parsing benchmarks. Still getting trounced across the board by rapidjson. Agreed. Rapidjson is the most important baseline. -- Andrei
Re: Language spec in free e-book format
El 08/04/15 a les 23:29, Nick via Digitalmars-d ha escrit: Hi, Could you make the language reference available for download in a free e-book format, such as EPUB or FB2? Some people just don't have any app that reads MOBI or Kindle format; they are not very common outside some particular devices. Thanks. -- There are several formats of D Programming Language Specifications at http://d-apt.sourceforge.net/ dlangspec-2.067.0.chm - Microsoft Compiled HTML Help dlangspec-2.067.0.epub - Electronic Publication for e-book readers dlangspec-2.067.0.mobi - Mobipocket e-book for Kindle dlangspec-2.067.0.pdf - Portable Document Format
Re: Why I'm Excited about D
On Thursday, 9 April 2015 at 01:28:05 UTC, Andrei Alexandrescu wrote: On 4/8/15 4:15 PM, Idan Arye wrote: On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu wrote: On 4/8/15 2:24 AM, Idan Arye wrote: At the very least, put () after the writelne: No. -- Andrei Why not? The property syntax's purpose is to create... well... properties. Give you the illusion that you are reading and writing member fields when you are actually calling functions. It seems to be a difference without a distinction. One day I got tired of writing r.empty and r.front but r.popFront(). Furthermore I got tired to spend time thinking where I should insert parens vs. where I shouldn't. So I dropped parens from that. And then from other places. Apparently I didn't get struck by lightning where I stood. Andrei This is not about being struck by lightning. This is about being struck by the next developer who has to read your code.
Re: Why I'm Excited about D
On 4/8/15 11:45 PM, Dicebot wrote: It took almost an hour to bisect all changed to trace the failure to this specifc line and realize that `parser.node` wasn't just trivial getter but method which actually advanced internal iterator to next node while returning current one. Thanks. The matter seems like a C++ false friend. -- Andrei
Re: [OT] Regarding most used operating system among devs
On Wednesday, 8 April 2015 at 16:19:44 UTC, weaselcat wrote: Poll has a windows bias due to stackoverflows focus on .NET, which is extremely overrepresented on SO(see: redmonk) Even if there is a bias how large can it be? It is not few % difference in the poll results.
Re: Silicon Valley D Meetup needs blood
On 4/9/2015 12:03 PM, Ali Çehreli wrote: Fresh or otherwise... :) We need speakers, topics, ideas, and anything else that you can think of to have a useful group. A paragraph of whining follows... We had a great start in January with one full length presentation by Andrei and two lightning talks by deadalnix and another member. Unfortunately, we could not have much success since then. I gave a presentation in February, which was appreciated by a small number of newcomers but we had to cancel the March meetup. :( We are in April now and not only there is no speaker yet, nobody even participates the discussions at the Meetup page: http://www.meetup.com/D-Lang-Silicon-Valley/ This is a perennial problem with any monthly thing. A couple suggestions: 1. Couple it with an excursion to the local watering hole afterwards for beers. This works for us at the nwcpp.org monthly meetings. 2. Invite speakers from companies that may not be involved with D, but produce a product of interest to D programmers, such as NVidia which wants people to make tools for programming GPUs. 3. Invite speakers from, say, Stanford, to talk on general CS programming topics. Please let me know if you can participate in any way. Otherwise, I am (and certainly Shammah is) happy to fill every single month with introductions, tutorials, or other cool stuff but we would like to have a more lively atmosphere; not a one-man or two-men show. Actually, that can be pretty good. If you do a tutorial style each month, and video them, you can build up a library of such instructional D videos that we can promote separately. Instead of the Khan Academy we can have the Ali Academy :-)
Adjustor thunks and variadic arguments.
Hi,
How does LDC handle emitting thunks to external modules that accept
variadic parameters?
If under the same object file, you can happily emit:
suboffset, %thisreg
jmpmethod
But if doing separate compilation, many targets to not support doing
such operations across section boundaries. So a more general/agnostic
way to go about it is by copying all arguments, adjusting the 'this'
pointer and calling target method at the codegen level. This works so
long as you are not dealing with a variadic method (ie:
std.stream.Stream.printf)
Example code below:
A.d
---
module A;
interface I_A
{
bool a(...);
}
class C_A : I_A
{
bool a(...) { return false; }
}
B.d
---
module B;
import A;
interface I_B : I_A
{
void b();
}
abstract class C_B : C_A, I_B
{
abstract void b();
}
void main() { }
Re: Wanted: Review manager for std.data.json
Am 08.04.2015 um 20:55 schrieb Iain Buclaw via Digitalmars-d: On 8 April 2015 at 20:32, tcha via Digitalmars-d digitalmars-d@puremagic.com wrote: (...) Also tried to dustmite the minimal failing version and here is a result: http://pastebin.com/YjdvT3G4 It's my first use of it so I hope it can help to solve this problem. It outputs less errors, but also compiles fine in debug and fails to link in release. I've filed two tickets for linker errors (and added a workaround for the first one): https://issues.dlang.org/show_bug.cgi?id=14425 https://issues.dlang.org/show_bug.cgi?id=14429 I'll try to reduce the pastebin reduced sample further, too, as it looks like it has yet another root cause. Frankly, if we are not as fast (or elegant) as Python's json library, it should be thrown out back to the drawing board. Iain. As far as the profiler results can be trusted, a good chunk of the time gets spent for reading individual bytes from memory, but there must be something else low-level going on that make things this bad. However, there is nothing fundamental in the structure/design that would cause this, so I think spending more time with the profiler is the only logical step now. Unfortunately my VTune license has expired and perf on Linux makes the task quite a bit more involved. If we want to be really fast, though, we need to add optimized SIMD paths, but this is currently outside of the possibilities of my time budget.
Re: DMD compilation speed
On Monday, 30 March 2015 at 00:12:09 UTC, Walter Bright wrote: On 3/29/2015 4:14 PM, Martin Krejcirik wrote: It seems like every DMD release makes compilation slower. This time I see 10.8s vs 7.8s on my little project. I know this is generally least of concern, and D1's lighting-fast times are long gone, but since Walter often claims D's superior compilation speeds, maybe some profiling is in order ? Sigh. Two things happen constantly: 1. object file sizes creep up 2. compilation speed slows down It's like rust on your car. Fixing it requires constant vigilance. Are there any plans to fix this up in a point release? The compile times have really taken a nose dive in v2.067. It's really taken the fun out of the language.
Re: Adjustor thunks and variadic arguments.
On 9 April 2015 at 15:39, Daniel Murphy via Digitalmars-d digitalmars-d@puremagic.com wrote: Iain Buclaw via Digitalmars-d wrote in message news:mailman.1372.1428583102.3111.digitalmar...@puremagic.com... That's not copying arguments. :-) True, but why doesn't jump work? Many targets do not support thunks (PPC, IA64, MIPS) - even i386 has it's limitations (if there are no free registers, it's tilt game over!). From conversations I've been having with GCC folks, jmp won't work across shared libraries either it seems.
Re: Wanted: Review manager for std.data.json
On Thursday, 9 April 2015 at 20:00:28 UTC, John Colvin wrote: I can't remember which -O level inlining is enabled, but there's definitely no need to explicitly ask for it at -O5. -enable-inlining(enabled at -O2) and -inline do different things and -inline isn't automatically enabled.
Re: Fun project - faster associative array algorithm
Steven Schveighoffer wrote in message news:mg5pf0$1g51$1...@digitalmars.com... I really am surprised that these would be difficult at all. The lowering is pretty easy: a) T[U] = AssociativeArray!(U,T) b) [a:b, c:d] = AssociativeArray!(typeof(true ? a : c), typeof(true ? b : d)).literal(a, b, c, d); Working out what to lower to is easy, working out when to lower it is hard.
Re: Wanted: Review manager for std.data.json
On 04/08/2015 03:56 PM, Sönke Ludwig wrote: The problem is that even the pull parser alone is relatively slow. Also, for some reason the linker reports unresolved symbols as soon as I build without the -debug flag... The review hasn't yet started and I'm already against the stream parser, because it hardly deserves the names parser, it's more like a lexer. Because the benchmark code by tcha was a very specific hack for the used data structure, I tried to write a proper stream parser to have a fair comparison. This is where I stopped (it doesn't work). http://dpaste.dzfl.pl/8282d70a1254 The biggest problem with that interface is, that you have to count matching start/end markers for objects and arrays in order to skip an entry, not much fun and definitely needs a dedicated skip value function. There are 2 very nice alternative approaches in the benchmark repo. https://github.com/kostya/benchmarks/blob/master/json/test_pull.cr https://github.com/kostya/benchmarks/blob/master/json/test_schema.cr
Re: Understanding the D memory model re: Voldemort types
On Thursday, 9 April 2015 at 18:15:16 UTC, H. S. Teoh wrote: The compiler detects when a variable is being closed over by a nested function, and allocates them on the heap instead of the stack. Is there somewhere I can read more about this (besides the compiler source code)? What ramifications are there for local variables being closed over that have destructors? Does the Voldemort object then get implicit destructor code that destroys the closed-over variables when it falls out of scope?
Re: Adjustor thunks and variadic arguments.
Iain Buclaw via Digitalmars-d wrote in message news:mailman.1372.1428583102.3111.digitalmar...@puremagic.com... That's not copying arguments. :-) True, but why doesn't jump work?
Re: Wanted: Review manager for std.data.json
On Thursday, 9 April 2015 at 19:40:31 UTC, Sönke Ludwig wrote: Am 09.04.2015 um 21:37 schrieb weaselcat: On Thursday, 9 April 2015 at 19:35:24 UTC, Sönke Ludwig wrote: Am 09.04.2015 um 21:26 schrieb weaselcat: On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote: Not sure, but that may also have been my recent optimizations. Just tried it with your recent optimizations and it doesn't build with LDC 0.15.1. Should work now. I just tested LDC with -singleobj and it's faster than RapidJSON! Now the DOM parser gets interesting. What flags are you using? RapidJSON is still a lot faster for me. also, I just realized the build script has the wrong inline flag for LDC(it's using -enable-inlining instead of -inline) I'll have to test with that exact version, because I've used my own main() function for the test. The flags were: -singleobj -release -O5 -enable-inlining -disable-bondscheck (-disable-boundscheck is only a little faster). I can't remember which -O level inlining is enabled, but there's definitely no need to explicitly ask for it at -O5.
if(arr) now a warning
A confusing and dangerous feature of D was to treat the expression if(arr) as meaning if(arr.ptr). Anyone coming from any number of other languages may think that if(arr) means if arr has any elements. Typically one cares what is inside an array, not where it lives. However, while checking to see if an array has elements is very similar to checking for a null pointer (obviously, a null pointer array should have no elements), it's not equivalent. Therefore, when attempting to fix this confusion, we had to disable the if(arr) check altogether. You must now specify what part of the array you care about, if(arr.ptr) or if(arr.length). As usual with changes of this nature, there are differing opinions, and differing styles. I personally never use null as a special value for an array, but others do. They use if(arr) to actually mean if(arr.ptr). For these cases, the update will cause some amount of busywork changing these checks. But when updating Phobos to comply with this change, we found several actual incorrect usages. So I think the change is worth it, and not much busywork. YMMV. What do you think? references: https://issues.dlang.org/show_bug.cgi?id=4733 https://github.com/D-Programming-Language/dmd/pull/2885 https://github.com/D-Programming-Language/tools/pull/166 -Steve
Re: Why I'm Excited about D
On 4/9/2015 9:12 AM, Araq wrote: Because trivial accessors are everywhere in Java one usually has to assume it has no side-effects. I fail to see the relevance of the missing () in your example; () doesn't scream side-effect in C++/Java/C#/C. The real issue here is that 'node' or 'getNode' is simply poorly named suggesting it has no side-effects. 'nextNode' for instance doesn't have this problem. I agree, it seems the method is poorly named as a simple noun that implies a static computation, rather than as a verb that implies some sort of action.
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP77 I've only skimmed this, but: 1. I don't think Objective-C uses autorelease pools for any other reason than to make manual ref counting easier. See also John McCall's reflections on ARC: http://forum.dlang.org/thread/mcqcor$aa$1...@digitalmars.com?page=2#post-hgmhgirfervrsvcghchw:40forum.dlang.org 2. How will this work with yield? Why not just implement the more generic solution (shared pointers with move/borrow or WPO) ?
Re: [OT] Regarding most used operating system among devs
On Wednesday, 8 April 2015 at 16:13:22 UTC, Adam D. Ruppe wrote: On Wednesday, 8 April 2015 at 16:08:44 UTC, Dicebot wrote: So who is going to do the pull request? One of those Linux developers I presume? :) I actually came close to it, but it ended up being a bit of a pain. The easiest thing would be to just shove the win32.* packages in the zip, but then you ahve the hassle of HANDLE being different in core.sys.windows.windows and win32... and I wanted to merge them but it wasn't as easy as it should be, then other stuff came up. But maybe the path of least resistance is worth doing. Or perhaps the core.sys.windows could simply import win32 instead of adapting them hmmm. That's tempting. tho then I hit the problem of me having three jobs already and don't have a lot of time I'm of the opposite end, where I have the time; however, I don't understand exactly what needs done. I've been meaning to get more familiar with the Win32 API anyhow. Perhaps we could tag team this? Feel free to get a hold of me if you're interested.
Re: ARMv7 vs x86-64: Pathfinding benchmark of C++, D, Go, Nim, Ocaml, and more.
On Thursday, 9 April 2015 at 04:30:18 UTC, Dicebot wrote: On Wednesday, 1 April 2015 at 20:59:07 UTC, Dicebot wrote: On Wednesday, 1 April 2015 at 20:40:02 UTC, Laeeth Isharc wrote: Experimenting on my oneplusone phone running arch (geekbench3 2.9k) and will be back in range in a week. How much RAM do you think you need? If it is just a PKGBUILD issue - any amount will do. If building ldc itself will be necessary.. well, it can be a bit more demanding :) I hope for the former. Mathias Lang has kindly provided me shell access to one Raspberry, investigating the issue. Seems to work for me now with ldc / liblphobos packages 0.15.1-6 Actual issue was so embarassing that I'd better be silent about it :P
Silicon Valley D Meetup needs blood
Fresh or otherwise... :) We need speakers, topics, ideas, and anything else that you can think of to have a useful group. A paragraph of whining follows... We had a great start in January with one full length presentation by Andrei and two lightning talks by deadalnix and another member. Unfortunately, we could not have much success since then. I gave a presentation in February, which was appreciated by a small number of newcomers but we had to cancel the March meetup. :( We are in April now and not only there is no speaker yet, nobody even participates the discussions at the Meetup page: http://www.meetup.com/D-Lang-Silicon-Valley/ Please let me know if you can participate in any way. Otherwise, I am (and certainly Shammah is) happy to fill every single month with introductions, tutorials, or other cool stuff but we would like to have a more lively atmosphere; not a one-man or two-men show. You can post on the Meetup page or write to me directly at acehr...@yahoo.com Thank you, Ali
Re: Silicon Valley D Meetup needs blood
nwcpp.org also usually offers pizza as well. A sponsor will bring in pizza, and in exchange they spend a few moments pushing their agenda (which is usually recruiting).
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Thursday, 9 April 2015 at 01:35:54 UTC, Walter Bright wrote: The same as that of a tmp being returned from a function - to the end of the expression. But how will this work with anything that makes RCArrays reachable through indirections...? Is the compiler going to do a recursive scan and create temporaries of all RC-pointers that are reachable? (e.g. RCArrays of RCArrays)
Re: Wanted: Review manager for std.data.json
On Thursday, 9 April 2015 at 11:49:00 UTC, Martin Nowak wrote: On 04/08/2015 08:32 PM, tcha wrote: Now with release numbers. D new - debug - 14.98s, 1782.0Mb 8.53s, 1786.8Mb D new Gdc - debug - 29.08s, 1663.9Mb GDC still misses @nogc support. D new Ldc - 16.99s, 1663.0Mb 18.76s, 1664.1Mb D new lazy - debug - 11.50s, 213.2Mb 4.57s, 206Mb D new lazy Gdc - 13.66s, 206.1Mb Can't compile stdx.data.json with gdc-4.9.0 which doesn't yet support @nogc. D new lazy Ldc - 3.59s, 205.4Mb 4.0s, 205.4Mb LDC doesn't yet have the GC improvements, therefor is much slower for the DOM parsing benchmarks. Still getting trounced across the board by rapidjson.
Re: Wanted: Review manager for std.data.json
On Thursday, 9 April 2015 at 19:44:57 UTC, weaselcat wrote: I saw that commit to the benchmark and changed it locally. They're about the same performance now comparing clang to LDC, with -inline -boundscheck=off -singleobj flags Nice. Also, since an LDC dev might read this - is there a reason -singleobj isn't on by default when creating an executable?
Re: Why I'm Excited about D
On Thursday, 9 April 2015 at 16:12:17 UTC, Araq wrote: side-effect in C++/Java/C#/C. The real issue here is that 'node' or 'getNode' is simply poorly named suggesting it has no side-effects. 'nextNode' for instance doesn't have this problem. next is a common name for next-pointers. You need to pick a verb that cannot be mistaken for an adjective. E.g. moveToNextNode. Anyway, being explicit is important for maintainability. Some language designers are very much against even overloading for this reason. There's a convenience-maintenance trade off between weakly typed implicit languages and statically/strictly/strongly typed explicit code (suitable for large vocabulary, large source base, long running). Here's the semiotics I tend to go by: - Dot-notation indicates an accessor/interface provided by the object, e.g. penetrating an encapsulation. - A parametric accessor (() is empty) indicates work being done using reference semantics. - Free form functions indicates value-semantics with results derived from values/objects. Consistent mapping from syntax to semantics makes for more readable and, more importantly, more easily maintainable code.
Re: Wanted: Review manager for std.data.json
On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote: Not sure, but that may also have been my recent optimizations. Just tried it with your recent optimizations and it doesn't build with LDC 0.15.1.
Re: Wanted: Review manager for std.data.json
Am 08.04.2015 um 20:32 schrieb tcha: On Wednesday, 8 April 2015 at 13:56:55 UTC, Sönke Ludwig wrote: The problem is that even the pull parser alone is relatively slow. Also, for some reason the linker reports unresolved symbols as soon as I build without the -debug flag... Unfortunatelly I overlooked that I tested it with std_data_json v 0.12.0 yesterday. So tested it again today on master: dmd and gdc failed to build in release ldc2 works I tried it also with ParseJSONStream and made fork from original benchmark with added tests (https://github.com/chalucha/benchmarks) so anyone can look (and PR) Some results: Ruby - 6.74s, 2106.2Mb Go - 5.92s, 420.9Mb D - 10.26s, 1322.5Mb D Gdc - 24.76s, 926.1Mb D Ldc - 26.31s, 925.0Mb D new - debug - 14.98s, 1782.0Mb D new Gdc - debug - 29.08s, 1663.9Mb D new Ldc - 16.99s, 1663.0Mb D new lazy - debug - 11.50s, 213.2Mb D new lazy Gdc - debug - 13.66s, 206.1Mb D new lazy Ldc - 3.59s, 205.4Mb Python - 5.89s, 1063.4Mb C++ Boost - 14.60s, 2884.8Mb C++ Rapid - 0.80s, 678.9Mb Also tried to dustmite the minimal failing version and here is a result: http://pastebin.com/YjdvT3G4 It's my first use of it so I hope it can help to solve this problem. It outputs less errors, but also compiles fine in debug and fails to link in release. I got the latest version using the pull parser down to the Crystal Pull parser speed*. This is about twice as slow as Rapid JSON. * Using DMD to compile. LDC is for some reason much slower, but I didn't try the -singleobj switch yet.
Re: [OT] Regarding most used operating system among devs
On Wednesday, 8 April 2015 at 16:19:44 UTC, weaselcat wrote: On Wednesday, 8 April 2015 at 08:59:04 UTC, Szymon Gatner wrote: From StackOverflow's 2015 Developer Survey [1]: For the third year in a row, we asked respondents which operating system they use the most. Windows maintains the lion's share of the developer operating system market, while Mac appears to have overtaken the Linuxes among active Stack Overflow devs. Linux may be a small player on the consumer market, with just 1.5% of global desktop operating system share, but it's a go-to OS for developers. Interestingly, from the Text editor question we learn that most used ones are NotePad++ and Sublime Text (and not Visual Studio) which I know are favs among webdevelopers that are not used to IDEs (as debugging happens in web browsers). This correlates with with Most popular technologies results too. To sum up: Please give more attention to Windows developers like myself ;) [1]http://stackoverflow.com/research/developer-survey-2015 Poll has a windows bias due to stackoverflows focus on .NET, which is extremely overrepresented on SO(see: redmonk) Most of the enterprise developers are on Windows, even when targeting UNIX, it is not only .NET. Unless one is doing plain C or C++ with their bare bones runtime libraries, there are plenty of languages that allow for such workflow. -- Paulo
Re: [OT] Regarding most used operating system among devs
Am Wed, 08 Apr 2015 13:05:01 + schrieb Szymon Gatner noem...@gmail.com: On Wednesday, 8 April 2015 at 12:34:06 UTC, Paulo Pinto wrote: Since then, I always favor spaces over tabs. One space is always one space. Not to start a war but agreed ;) 2 spaces (specifically) FTW! You see, there's the reason why we tab users use tabs. -- Marco
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Thursday, 9 April 2015 at 18:44:10 UTC, Walter Bright wrote: The only real purpose to a postblit is to support ref counting. Why would a by-value container use a postblit and not ref count? A struct could have a postblit defined if you are implementing something like std::vector, where you you copy the memory when the struct is copied. I'm not sure why you would want to do such a thing in D, though. If allocating memory is your concern, you probably don't want any allocation, including malloc.
Re: Which D IDE do you use?(survey)
On Wednesday, 8 April 2015 at 13:20:18 UTC, Jacob Carlborg wrote: Xcode 2.5?? You're a bit behind. Xcode 2.5 is the best Xcode. There's only one IDE from Apple which is better: Project Builder! The rest of them are too broken for me. Xcode 3.x keeps spamming my console. Even if I could run Xcode 7254.9, I double they would have fixed the unicode problem and the other things they broke when they made Project Bulider fancy:
Re: Which D IDE do you use?(survey)
On Tuesday, 7 April 2015 at 22:58:44 UTC, weaselcat wrote: Hi, I hope nobody minds but I'm just curious as to the popularity amongst D IDEs for a blog post. Sorry if I forgot your favorite $editor. http://goo.gl/forms/MmsuInzDL0 thanks : ) I use Kate. Although it's not IDE but text editor, it has bunch of useful plugins like Lumen (autocompletion using DCD), gdb frontend, terminal tool view, file system browser and more.
Re: Wanted: Review manager for std.data.json
On 9 April 2015 at 13:48, Martin Nowak via Digitalmars-d digitalmars-d@puremagic.com wrote: On 04/08/2015 08:32 PM, tcha wrote: Now with release numbers. D new - debug - 14.98s, 1782.0Mb 8.53s, 1786.8Mb D new Gdc - debug - 29.08s, 1663.9Mb GDC still misses @nogc support. Wasn't @nogc introduced in 2.066 ? https://github.com/D-Programming-GDC/GDC/blob/master/gcc/d/VERSION
Re: Which D IDE do you use?(survey)
On Wed, 08 Apr 2015 21:37:37 + bioinfornatics via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 7 April 2015 at 22:58:44 UTC, weaselcat wrote: Hi, I hope nobody minds but I'm just curious as to the popularity amongst D IDEs for a blog post. Sorry if I forgot your favorite $editor. http://goo.gl/forms/MmsuInzDL0 thanks : ) It seem now intellij support D lang. I use it for some java project is a good IDE. Do you mean this project: https://github.com/kingsleyh/DLanguage Or anything else?
Re: Silicon Valley D Meetup needs blood
On 04/09/2015 12:57 PM, Walter Bright wrote: nwcpp.org also usually offers pizza as well. A sponsor will bring in pizza, and in exchange they spend a few moments pushing their agenda (which is usually recruiting). We have been offering pizza and beer as well. Perhaps that's what we should be marketing. :) Ali
Re: Wanted: Review manager for std.data.json
On Thursday, 9 April 2015 at 19:43:13 UTC, Sönke Ludwig wrote: Am 09.04.2015 um 21:40 schrieb Sönke Ludwig: Am 09.04.2015 um 21:37 schrieb weaselcat: On Thursday, 9 April 2015 at 19:35:24 UTC, Sönke Ludwig wrote: Am 09.04.2015 um 21:26 schrieb weaselcat: On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote: Not sure, but that may also have been my recent optimizations. Just tried it with your recent optimizations and it doesn't build with LDC 0.15.1. Should work now. I just tested LDC with -singleobj and it's faster than RapidJSON! Now the DOM parser gets interesting. What flags are you using? RapidJSON is still a lot faster for me. also, I just realized the build script has the wrong inline flag for LDC(it's using -enable-inlining instead of -inline) I'll have to test with that exact version, because I've used my own main() function for the test. The flags were: -singleobj -release -O5 -enable-inlining -disable-bondscheck (-disable-boundscheck is only a little faster). One thing about the D benchmark is that it uses readText(). To be a fair comparison with Rapid it would have to use cast(string)read() instead. I saw that commit to the benchmark and changed it locally. They're about the same performance now comparing clang to LDC, with -inline -boundscheck=off -singleobj flags Nice.
Re: Why I'm Excited about D
So, to be more specific, here is one of cases where it actually
caused trouble in practice. Someone has originally written code
that looked roughly like this:
while (something)
{
// ...
auto str = format(%s, parser.node);
}
Long time later I have been adding trace logs to that module
and this has become akin to
while (something)
{
log(parser.node);
// ...
auto str = format(%s, parser.node);
}
Which resulted in broken application. It took almost an hour to
bisect all changed to trace the failure to this specifc line
and realize that `parser.node` wasn't just trivial getter but
method which actually advanced internal iterator to next node
while returning current one.
In Java many people would have done this instead:
while (something)
{
log(parser.getNode());
// ...
String str = format(%s, parser.getNode());
}
Because trivial accessors are everywhere in Java one usually has
to assume it has no side-effects. I fail to see the relevance of
the missing () in your example; () doesn't scream side-effect in
C++/Java/C#/C. The real issue here is that 'node' or 'getNode' is
simply poorly named suggesting it has no side-effects. 'nextNode'
for instance doesn't have this problem.
Re: Wanted: Review manager for std.data.json
Am 09.04.2015 um 21:35 schrieb Sönke Ludwig: Am 09.04.2015 um 21:26 schrieb weaselcat: On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote: Not sure, but that may also have been my recent optimizations. Just tried it with your recent optimizations and it doesn't build with LDC 0.15.1. Should work now. I just tested LDC with -singleobj and it's faster than RapidJSON! Now the DOM parser gets interesting. Okay let's say about the same speed, the numbers fluctuate quite a bit.
Re: Wanted: Review manager for std.data.json
Am 09.04.2015 um 21:26 schrieb weaselcat: On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote: Not sure, but that may also have been my recent optimizations. Just tried it with your recent optimizations and it doesn't build with LDC 0.15.1. Should work now. I just tested LDC with -singleobj and it's faster than RapidJSON! Now the DOM parser gets interesting.
Re: Wanted: Review manager for std.data.json
On Thursday, 9 April 2015 at 19:35:24 UTC, Sönke Ludwig wrote: Am 09.04.2015 um 21:26 schrieb weaselcat: On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote: Not sure, but that may also have been my recent optimizations. Just tried it with your recent optimizations and it doesn't build with LDC 0.15.1. Should work now. I just tested LDC with -singleobj and it's faster than RapidJSON! Now the DOM parser gets interesting. What flags are you using? RapidJSON is still a lot faster for me. also, I just realized the build script has the wrong inline flag for LDC(it's using -enable-inlining instead of -inline)
Re: UDAs and no complaints about need 'this'
On Thursday, 9 April 2015 at 09:53:15 UTC, John Colvin wrote:
struct BigLongStructName
{
int evenLongerMemberName;
}
struct QN{}
unittest
{
BigLongStructName bigLongStructName;
@(bigLongStructName.evenLongerMemberName)
QN quickName;
__traits(getAttributes, quickName)[0]++;
}
Is it just me or is it weird that this works? Once you pull the
UDA out from being a storage class and attempt to alias it, you
get the usual need 'this' for 'evenLongerMemberName' of type
'int' error messages on use.
Why are UDAs so special? I don't believe there's any other way
to achieve this sort of effective renaming.
For me it seems to fit into D type system (which is not
necessarily is a good idea).
struct S
{
int i;
}
alias S.i si;
void main(){ /*si++;*/}
Behavior of D depends sometimes on it internals, not on
programmers' expectations. Since D has never been stabilized, the
boundary between WAT and bugs is partially undefined.
Re: DIP77 - Fix unsafe RC pass by 'ref'
On 4/9/2015 5:05 AM, Michel Fortin wrote:
Why should it not have an opAssign marked @system?
Andrei's idea was to not do the copy for @system opAssign's, thus providing C++
equivalence for those folks that need it and don't care about guaranteed memory
safety.
And what happens if the struct has a postblit but it is @disabled? Will the
compiler forbid you from passing it by ref in cases where it'd need to make a
copy, or will it just not be a RCO?
It wouldn't be an RCO.
More generally, is it right to add implicit copying just because a struct has a
postblit and a destructor? If someone implemented a by-value container in D
(such as those found in C++), this behaviour of the compiler would trash the
performance by silently doing useless unnecessary copies. You won't even get
memory-safety as a benefit: if the container allocates from the GC it's safe
anyway, otherwise you're referencing deallocated memory with your ref parameter
(copying the struct would just make a copy elsewhere, not retain the memory of
the original).
The only real purpose to a postblit is to support ref counting. Why would a
by-value container use a postblit and not ref count?
I think you're assuming too much from the presence of a postblit and a
destructor. This implicit copy behaviour should not be trigged by seemingly
unrelated clues. Instead of doing that:
auto tmp = rc;
the compiler should insert this:
auto tmp = rc.opPin();
RCArray can implement opPin by returning a copy of itself. A by-value container
can implement opPin by returning a dummy struct that retains the container's
memory until the dummy struct's destructor is called. Alternatively someone
could make a dummy void opPin() @system {} to signal it isn't safe to pass
internal references around (only in system code would the implicit call to opPin
compile). If you were writing a layout-compatible D version of std::vector,
you'd likely have to use a @system opPin because there's no way you can pin
that memory and guaranty memory-safety when passing references around.
My first impression is that's too complicated for the user to get right.
Re: Understanding the D memory model re: Voldemort types
On 4/9/15 2:23 PM, Matt Kline wrote: On Thursday, 9 April 2015 at 18:15:16 UTC, H. S. Teoh wrote: The compiler detects when a variable is being closed over by a nested function, and allocates them on the heap instead of the stack. Is there somewhere I can read more about this (besides the compiler source code)? What ramifications are there for local variables being closed over that have destructors? Does the Voldemort object then get implicit destructor code that destroys the closed-over variables when it falls out of scope? It's called a closure. It's not specific to voldemort types, it's done whenever you take a delegate that needs the context pointer to the stack. I believe destruction is performed on the stack frame data when the GC collects the stack frame. See here: http://dlang.org/function.html#closures In regards to voldemort types triggering a heap allocation of the stack frame, I can't find specific documentation on this, probably a good idea to add it. -Steve
Re: Wanted: Review manager for std.data.json
Am 09.04.2015 um 21:06 schrieb weaselcat: On Thursday, 9 April 2015 at 11:49:00 UTC, Martin Nowak wrote: On 04/08/2015 08:32 PM, tcha wrote: Now with release numbers. D new - debug - 14.98s, 1782.0Mb 8.53s, 1786.8Mb D new Gdc - debug - 29.08s, 1663.9Mb GDC still misses @nogc support. D new Ldc - 16.99s, 1663.0Mb 18.76s, 1664.1Mb D new lazy - debug - 11.50s, 213.2Mb 4.57s, 206Mb D new lazy Gdc - 13.66s, 206.1Mb Can't compile stdx.data.json with gdc-4.9.0 which doesn't yet support @nogc. D new lazy Ldc - 3.59s, 205.4Mb 4.0s, 205.4Mb LDC doesn't yet have the GC improvements, therefor is much slower for the DOM parsing benchmarks. ldc -singleobj flag speeds it up dramatically ldc2 -ofjson_d_new_lazy_ldc -O5 -release -enable-inlining -w -oq -Istd_data_json/source/ std_data_json/source/stdx/data/json/*.d test_new_lazy.d ./json_d_new_lazy_ldc 2.79s user 0.08s system 99% cpu 2.868 total ldc2 -singleobj -ofjson_d_new_lazy_ldc -O5 -release -enable-inlining -w -oq -Istd_data_json/source/ std_data_json/source/stdx/data/json/*.d test_new_lazy.d ./json_d_new_lazy_ldc 1.78s user 0.08s system 99% cpu 1.869 total for comparison: ./json_rapid_cpp 0.80s user 0.30s system 99% cpu 1.106 total Bye. Not sure, but that may also have been my recent optimizations.
Re: Why I'm Excited about D
On 4/9/15 10:31 AM, Idan Arye wrote: On Thursday, 9 April 2015 at 01:28:05 UTC, Andrei Alexandrescu wrote: On 4/8/15 4:15 PM, Idan Arye wrote: On Wednesday, 8 April 2015 at 16:47:10 UTC, Andrei Alexandrescu wrote: On 4/8/15 2:24 AM, Idan Arye wrote: At the very least, put () after the writelne: No. -- Andrei Why not? The property syntax's purpose is to create... well... properties. Give you the illusion that you are reading and writing member fields when you are actually calling functions. It seems to be a difference without a distinction. One day I got tired of writing r.empty and r.front but r.popFront(). Furthermore I got tired to spend time thinking where I should insert parens vs. where I shouldn't. So I dropped parens from that. And then from other places. Apparently I didn't get struck by lightning where I stood. Andrei This is not about being struck by lightning. This is about being struck by the next developer who has to read your code. Apparently they didn't either. -- Andrei
Re: DIP77 - Fix unsafe RC pass by 'ref'
On Thursday, 9 April 2015 at 09:05:10 UTC, Ola Fosheim Grøstad wrote: 2. How will this work with yield? You yield both caller and callee, so you'll get caller's boxing in the yield. Why not just implement the more generic solution (shared pointers with move/borrow or WPO) ? I don't think this is possible.
Re: DMD compilation speed
On Wednesday, 1 April 2015 at 02:25:44 UTC, Random D-user wrote: I've used D's GC with DDMD. It works*, but you're trading better memory usage for worse allocation speed. It's quite possible we could add a switch to ddmd to enable the GC. As a random d-user (who cares about perf/speed and just happened to read this) a switch sounds VERY good to me. I don't want to pay the price of GC because of some low-end machines. Memory is really cheap these days and pretty much every machine is 64-bits (even phones are trasitioning fast to 64-bits). Also, I wanted to add that freeing (at least to the OS (does this apply to GC?)) isn't exactly free either. Infact it can be more costly than mallocing. Here's enlightening article: https://randomascii.wordpress.com/2014/12/10/hidden-costs-of-memory-allocation/ I think a switch would be good. My main reason for asking for such a thing isn't for performance (not directly), it's for being able to compile some D programs on computers with less memory. I've had machines with 1 or 2 GB of memory on them, wanted to compile a D program, DMD ran out of memory, and the compiler crashed. You can maybe start swapping on disk, but that won't be too great.
Re: Wanted: Review manager for std.data.json
Am 09.04.2015 um 15:20 schrieb Martin Nowak: On 04/09/2015 10:59 AM, Sönke Ludwig wrote: As far as the profiler results can be trusted, a good chunk of the time gets spent for reading individual bytes from memory, but there must be something else low-level going on that make things this bad. However, there is nothing fundamental in the structure/design that would cause this, so I think spending more time with the profiler is the only logical step now. Unfortunately my VTune license has expired and perf on Linux makes the task quite a bit more involved. I didn't found too many issues. Most of the time is spent in parseJSONValue (looks like there are some expansive struct copies) https://github.com/s-ludwig/std_data_json/blob/1da3f828ae6c4fd7cac7f7e13ae9e51ec93e6f02/source/stdx/data/json/parser.d#L148 I'll have a look at the DOM part later. At the moment I'm looking at low level issues of the lexer. There is a lot of potential there, but it's a lot of detail work. and skipWhitespace. This function could really take some optimization, e.g. avoid UTF decoding. All of the lexing work happens on str.representation instead of the string directly, so no decoding should happen there. https://github.com/s-ludwig/std_data_json/blob/1da3f828ae6c4fd7cac7f7e13ae9e51ec93e6f02/source/stdx/data/json/lexer.d#L345 Libdparse has some optimized ASM function, might be useful. https://github.com/Hackerpilot/libdparse/blob/51b7d9d321aac0fcc4a9be99bbbed5db3158326c/src/std/d/lexer.d#L2233
Re: Fun project - faster associative array algorithm
Steven Schveighoffer wrote in message news:mg61gn$1o09$1...@digitalmars.com... Wouldn't it be whenever AA was previously invoked? I'm surprised there are any unknowns here. It has to be done before some parts of semantic, but after others. Eg error messages and template matching still needs to be done on the AA type, but other parts need the actual template type.
Re: if(arr) now a warning
Steven Schveighoffer: What do you think? I asked for this fix almost five years ago, so I think it's about time :-) Bye, bearophile
Re: Which D IDE do you use?(survey)
On Tuesday, 7 April 2015 at 22:58:44 UTC, weaselcat wrote: Hi, I hope nobody minds but I'm just curious as to the popularity amongst D IDEs for a blog post. Sorry if I forgot your favorite $editor. http://goo.gl/forms/MmsuInzDL0 thanks : ) Where is results? Or do we see 'em after several days?
Re: Which D IDE do you use?(survey)
On Wed, 08 Apr 2015 21:37:37 + bioinfornatics via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 7 April 2015 at 22:58:44 UTC, weaselcat wrote: Hi, I hope nobody minds but I'm just curious as to the popularity amongst D IDEs for a blog post. Sorry if I forgot your favorite $editor. http://goo.gl/forms/MmsuInzDL0 thanks : ) It seem now intellij support D lang. I use it for some java project is a good IDE. Do you mean this project: https://github.com/kingsleyh/DLanguage Or anything else?
Re: Which D IDE do you use?(survey)
On Tuesday, 7 April 2015 at 22:58:44 UTC, weaselcat wrote: Hi, I hope nobody minds but I'm just curious as to the popularity amongst D IDEs for a blog post. Sorry if I forgot your favorite $editor. http://goo.gl/forms/MmsuInzDL0 thanks : ) Sublime on smaller screen and when not debugging (I like the distraction-free mode very much). On larger screens and when debugging, VisualD with Mago. Tried to make my own IDE but it kinda sucks and no real time for this :) https://github.com/p0nce/dido
Re: Wanted: Review manager for std.data.json
Am 09.04.2015 um 10:59 schrieb Sönke Ludwig: Am 08.04.2015 um 20:55 schrieb Iain Buclaw via Digitalmars-d: On 8 April 2015 at 20:32, tcha via Digitalmars-d digitalmars-d@puremagic.com wrote: (...) Also tried to dustmite the minimal failing version and here is a result: http://pastebin.com/YjdvT3G4 It's my first use of it so I hope it can help to solve this problem. It outputs less errors, but also compiles fine in debug and fails to link in release. I've filed two tickets for linker errors (and added a workaround for the first one): https://issues.dlang.org/show_bug.cgi?id=14425 https://issues.dlang.org/show_bug.cgi?id=14429 I'll try to reduce the pastebin reduced sample further, too, as it looks like it has yet another root cause. Actually it seems to be the first issue (14425). I've already added a workaround for that on GIT master.
Re: Why I'm Excited about D
On Wednesday, 8 April 2015 at 18:08:36 UTC, Andrei Alexandrescu
wrote:
On 4/8/15 10:04 AM, Dicebot wrote:
On Wednesday, 8 April 2015 at 16:56:12 UTC, Andrei
Alexandrescu wrote:
Considering I am far from the only person having problems
with it in our team and such style is extremely common
because of being
easy - this can easily be one of most damaging language
features in D in
terms of wasted developer time.
Again trying with ad populum. Not buying it.
I don't even slightly care about your opinion here. It is just
another
annoying custom style rule I have to deal with. Casual
necessity for
actually getting work done with D.
I guess I deserve this for making my point as a jerk. I
shouldn't engage in brief bickering when I don't have time. My
point was: you'd need some detail to back up your claim about
those wasted hours because I also work on a large D project at
work with others and that hasn't been an issue, like, ever. We
ended up just not adding the pesky ()s simply because sitting
down and deciding which deserves and which doesn't was a waste
of time. E.g. front and empty shouldn't, but popFront should.
Really no reason for it.
So, to be more specific, here is one of cases where it actually
caused trouble in practice. Someone has originally written code
that looked roughly like this:
while (something)
{
// ...
auto str = format(%s, parser.node);
}
Long time later I have been adding trace logs to that module and
this has become akin to
while (something)
{
log(parser.node);
// ...
auto str = format(%s, parser.node);
}
Which resulted in broken application. It took almost an hour to
bisect all changed to trace the failure to this specifc line and
realize that `parser.node` wasn't just trivial getter but method
which actually advanced internal iterator to next node while
returning current one.
Yes, this does seem to bother only some people and others
actually enjoy omitting parens everywhere. But it comes up often
enough to cause actual damage which makes aesthetical point much
less convincing. I don't have any good statistics for how often
it strikes or what kind of workflow is more likely to clash with
such style - all I know that such cases happen, and happen often
enough to not be dismissed as purely accidental.
Considering that following more permissive coding style does not
actually give you any benefits than saving at most one pair of ()
per line, choice feels obvious. We don't currently have any
strict style rules about this but general direction seems to be
mandatory () for last call in a call chain with an exception
for side-effect free trivial getters.
tl; dr: I can commonly be wrong in identifying the problem,
evalutating its importance or proposing solutions but it feels
offending when you suggest I don't actually have a problem at
all. Those are not the droids you are looking for style ;)
Re: Which D IDE do you use?(survey)
On Tuesday, 7 April 2015 at 22:58:44 UTC, weaselcat wrote: Hi, I hope nobody minds but I'm just curious as to the popularity amongst D IDEs for a blog post. Sorry if I forgot your favorite $editor. http://goo.gl/forms/MmsuInzDL0 thanks : ) Visual D for the overall experience (code editing and debugging, integrated C++ conversion, integrated profiling). Mono-D does a better job at syntax highlighting and code completion.
Re: Wanted: Review manager for std.data.json
On Thursday, 9 April 2015 at 20:11:07 UTC, weaselcat wrote: On Thursday, 9 April 2015 at 20:00:28 UTC, John Colvin wrote: I can't remember which -O level inlining is enabled, but there's definitely no need to explicitly ask for it at -O5. -enable-inlining(enabled at -O2) and -inline do different things and -inline isn't automatically enabled. Sorry Sönke for polluting your thread, but I did some reading of the LLVM manual - -inline is a specific LLVM pass and not a frontend flag. Using the -partial-inliner pass instead it(the benchmark) becomes faster than rapidJSON. Bye.
Re: Wanted: Review manager for std.data.json
Am 09.04.2015 um 15:11 schrieb Sönke Ludwig: Am 09.04.2015 um 14:25 schrieb Martin Nowak: (...) There are 2 very nice alternative approaches in the benchmark repo. https://github.com/kostya/benchmarks/blob/master/json/test_pull.cr https://github.com/kostya/benchmarks/blob/master/json/test_schema.cr That would be a nice intermediate level parser. However, the range based parser as it is now is also useful for things like automated deserialization (which I don't want to include at this point) where you don't know in which order fields come in and where you have to use that style of filtering through the data anyway. But if inlining works properly, it should be no problem to implement other APIs on top of it. https://github.com/s-ludwig/benchmarks/blob/master/json/test_new_lazy.d
Re: Fun project - faster associative array algorithm
On 4/8/15 5:11 AM, Martin Nowak wrote: On Tuesday, 7 April 2015 at 22:33:52 UTC, Steven Schveighoffer wrote: Until that point, all these discussions on AA updates are useless. I really don't that all or nothing attitude, it condemns an important step, just because something better might be possible. It's also very comfortable, because this way nobody will ever have to do anything. I'm not suggesting nobody ever do anything out of comfort. What I'm suggesting is that it's not worth improving something that will be discarded anyway. Let's fix the problem hampering people from understanding how the AA works so they can work on improving the AA. Namely, the discarding of all compile-time info during implementation. Improving the AA implementation has a big immediate effect, and will also help anyone writing a library implementation, because any candidate up to this date was still based on that crappy bucket list implementation. The crappy bucket list implementation is also the simplest. When the focus should be on fixing the AA interface with the compiler and library, I think having a simple understandable implementation is fine. Let me remind you of your attitude when I brought up the fact that AA's load factor was 4 (just fixing this one number could improve performance, even for the bucket list implementation): We'll throw the current implementation away and implement an open addressing AA once we get to it. So don't worry about the load factor right now. In other words, don't bother fixing the constant 4 in the code, it's going to be thrown away anyways. The biggest problems in writing an AA library implementation sorted by difficulty are: - deprecation of all magic AA behaviors (attributes, as[i][j]++) - get the lowering right I really am surprised that these would be difficult at all. The lowering is pretty easy: a) T[U] = AssociativeArray!(U,T) b) [a:b, c:d] = AssociativeArray!(typeof(true ? a : c), typeof(true ? b : d)).literal(a, b, c, d); Basically, bikeshed the name literal is the difficult part. And deprecating the magic AA behaviors, isn't this just removing a whole lot of code from the compiler? Once the lowering is working, I don't see how removing special cases would be difficult. The part where we may have issues I see is CTFE support. But I would defer to those who have already tried this exercise, perhaps they can share what broke their solutions. -Steve
Re: Wanted: Review manager for std.data.json
Am 09.04.2015 um 14:25 schrieb Martin Nowak: On 04/08/2015 03:56 PM, Sönke Ludwig wrote: The problem is that even the pull parser alone is relatively slow. Also, for some reason the linker reports unresolved symbols as soon as I build without the -debug flag... The review hasn't yet started and I'm already against the stream parser, because it hardly deserves the names parser, it's more like a lexer. Because the benchmark code by tcha was a very specific hack for the used data structure, I tried to write a proper stream parser to have a fair comparison. This is where I stopped (it doesn't work). http://dpaste.dzfl.pl/8282d70a1254 The biggest problem with that interface is, that you have to count matching start/end markers for objects and arrays in order to skip an entry, not much fun and definitely needs a dedicated skip value function. There are 2 very nice alternative approaches in the benchmark repo. https://github.com/kostya/benchmarks/blob/master/json/test_pull.cr https://github.com/kostya/benchmarks/blob/master/json/test_schema.cr That would be a nice intermediate level parser. However, the range based parser as it is now is also useful for things like automated deserialization (which I don't want to include at this point) where you don't know in which order fields come in and where you have to use that style of filtering through the data anyway. But if inlining works properly, it should be no problem to implement other APIs on top of it.
Re: Wanted: Review manager for std.data.json
On 04/09/2015 02:10 PM, John Colvin wrote: Still getting trounced across the board by rapidjson. Yep, anyone knows why? They don't even use a lazy parser.
Re: Wanted: Review manager for std.data.json
On 04/08/2015 08:32 PM, tcha wrote: Now with release numbers. D new - debug - 14.98s, 1782.0Mb 8.53s, 1786.8Mb D new Gdc - debug - 29.08s, 1663.9Mb GDC still misses @nogc support. D new Ldc - 16.99s, 1663.0Mb 18.76s, 1664.1Mb D new lazy - debug - 11.50s, 213.2Mb 4.57s, 206Mb D new lazy Gdc - 13.66s, 206.1Mb Can't compile stdx.data.json with gdc-4.9.0 which doesn't yet support @nogc. D new lazy Ldc - 3.59s, 205.4Mb 4.0s, 205.4Mb LDC doesn't yet have the GC improvements, therefor is much slower for the DOM parsing benchmarks.
Re: Vibe.Dav
On Wednesday, 8 April 2015 at 17:38:28 UTC, Sönke Ludwig wrote: Am 07.04.2015 um 22:46 schrieb Bogdan: Hi, Here is a library that adds web dav support to vibe.d: https://github.com/gedaiu/vibe.dav Right now it has good file dav support and some basic support for cal dav Any help, improvements ideas or constructive criticism is welcome. Thanks, Bogdan Nice! I'll give it a try when I get some time to set up a little private FileDAV server. Great! Just contact me if you have any problems with the setup. Bogdan
