Re: Interesting article from JVM world - Conservative GC: Is It Really That Bad?
On Monday, 5 March 2018 at 05:43:36 UTC, Ali wrote: Link to said article please. i think he means this article https://www.excelsiorjet.com/blog/articles/conservative-gc-is-it-really-that-bad/ https://news.ycombinator.com/item?id=16436574 Oops my mistake Yes, thanks it is exactly this article!
Interesting article from JVM world - Conservative GC: Is It Really That Bad?
These guys have independent JVM implementation and used Conservative GC for many years. As I can see it it is very similar to d-runtime GC. But their conclusion is: "sooner or later the absence of knowledge about the liveness of local variables will lead to problems in production that just cannot be handled" BTW Have we any progress or scheduled for GC improvements (e.g. process fork for parallel GC, thread-local GC)?
Re: NetBSD amd64: which way is the best for supporting 80 bits real/double?
On Thursday, 11 May 2017 at 11:10:50 UTC, Joakim wrote: Well, if you don't like what's available and NetBSD doesn't provide them... up to you to decide where that leads. In any case it was not my decision. LDC does not use x87 for math functions on other OS's.
Re: NetBSD amd64: which way is the best for supporting 80 bits real/double?
What is long double on NetBSD/amd64, 64-bit or full 80-bit? 80 bit but function set is not full e.g. acos supports long double http://netbsd.gw.com/cgi-bin/man-cgi?acos+3+NetBSD-7.0 cos does not support long double http://netbsd.gw.com/cgi-bin/man-cgi?cos+3+NetBSD-7.0 On Thursday, 11 May 2017 at 10:07:32 UTC, Joakim wrote: Dmd uses compiler intrinsics for those trig functions, and I notice that they seem to just call the native x86 asm instructions: https://github.com/dlang/dmd/blob/master/src/ddmd/root/longdouble.c#L428 As I know native x87 implementation of many math functions is terrible, and it is rarely used in real world.
NetBSD amd64: which way is the best for supporting 80 bits real/double?
I am porting LDC to NetBSD amd64, and I ask advice how to handle real type. NetBSD has limited support for this type. This type exists, but standard library does not provide full set of math functions for it (e.g. sinus, cosinus, and etc). Currently I just forward all function calls to 64 bits version counterparts, but in this case a set of unit tests are failing. I see following approaches to handle this issue: - Totally remove 80 bit real type from NetBSD port (make real==double) - Change tests and skip asserts for NetBSD There is one additional approach: implement these functions in druntime, but it is too big/massive work for me.
Re: D, ZeroMQ, Nanomsg
On Wednesday, 28 September 2016 at 11:53:05 UTC, Russel Winder wrote: Has anyone wrapped Nanomsg? Be aware - Nanomsg project is mostly dead now. See http://sealedabstract.com/rants/nanomsg-postmortem-and-other-stories/
Re: Required DMD changes for Mir and few thoughts about D future
On Monday, 26 September 2016 at 18:43:38 UTC, Ilya Yaroshenko wrote: 5. LDC compiler support for ARM, MIPS, MIPS64, Alpha Alpha CPU nowadays? I supposed it is died forever, except small amount of old hardware.
Re: GSoC 2016 - std.experimental.xml after a month
On Thursday, 23 June 2016 at 20:04:26 UTC, Lodovico Giaretta wrote: -- Brace yourself: a very long post is coming -- What is planned for the near future? - When the DOM classes will be usable (even if not 100% complete) I will start working on a DOM parser to build them from the source; - DTD check and entity substitution have to be implemented, and they will (I hope) fit nicely as pluggable components for the validating cursor; DOM - Any plans for Xpath? DTD check - What about XSD? XSD is more popular now. Also it would be nice to have something like JAXB (automatically bind and map DLang struct/classes to/from XML). But it may be part of next iteration or project. PS I find https://github.com/lodo1995/experimental.xml/issues/11 so actually you already answer to my questions about XSD & XPath.
Re: Fibers under the hood
On Thursday, 9 June 2016 at 04:57:30 UTC, Jonathan Marler wrote: I've googled and searched through the forums but haven't found too much on how fibers are implemented. How does yield return execution to the caller but then resume execution in the same place on the next call? Also some information on how the fiber call stack works would be nice. I'm assuming it allocates the stack on the GC heap. If so, what is the default size and is that configurable? Any information or pointers to resources that provide this information would be helpful. Thanks. See "Documentation of Fiber internals" inside https://github.com/dlang/druntime/blob/master/src/core/thread.d
Re: Small-Size-Optimized Array
On Monday, 16 May 2016 at 11:05:40 UTC, Nordlöw wrote: Does Phobos contain any standard small-size-optimized (SSO) array that starts with a stack array and union-converts into a standard builtin D-array when grown beyond the size of the stack array? If not has anybody put together one? You can look to my experement (see iarray.d): https://bitbucket.org/sibnick/inplacearray.git
Re: questions about NetBSD port
On Thursday, 4 February 2016 at 05:19:06 UTC, Joakim wrote: On Wednesday, 3 February 2016 at 17:36:36 UTC, Nikolay wrote: I decided try to repeat LDC team forkflow and cherry-pick my commit to ldc branch (druntime). There are a couple simple conflicts in src/core/stdc/locale.d & src/core/sys/posix/signal.d, and one absent (in master) file: src/rt/sections_ldc.d I successfully build and run druntime unittests on NetBSD after resolving conflicts. PS I created new pull request to druntime: https://github.com/D-Programming-Language/druntime/pull/1492 So you built this druntime with dmd on NetBSD? No I use ldc master for building druntime/phobos on NetBSD
Re: questions about NetBSD port
On Wednesday, 3 February 2016 at 06:25:49 UTC, Joakim wrote: On Tuesday, 2 February 2016 at 18:45:20 UTC, Nikolay wrote: You're probably better off porting dmd 2.068 first (as it's the last dmd written wholly in C++), using it to compile dmd git master on NetBSD, then porting druntime and phobos master. Porting dmd to NetBSD/x86 is likely easy: simply follow what the other BSDs have done, as you did for ldc. Is it possible to compile dmd with ldc? There are some additional changes in druntime for dmd comparing with ldc. So even working NetBSD dmd compiler is not full solution. I think new platforms will have troubles until we have separate branches for druntime/phobos in LDC/GDC and patch direction master -> LDC/GDC.
Re: questions about NetBSD port
On Wednesday, 3 February 2016 at 10:36:31 UTC, Iain Buclaw wrote: On 3 February 2016 at 10:25, Nikolay via Digitalmars-d < digitalmars-d@puremagic.com> wrote: That is a relatively recent change with respect to the age of NetBSD. :-) I guess that in LDC the intrinsic for std.math.sin is forwarded to NetBSD libm.sinl? Yes but https://www.netbsd.org/changes/changes-7.0.html#libm : Most transcendent functions are stubbed out
Re: questions about NetBSD port
On Wednesday, 3 February 2016 at 07:45:23 UTC, Iain Buclaw wrote: On 2 Feb 2016 7:50 pm, "Nikolay via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: Is NetBSD similar to FreeBSD in that you have 80-bit reals but only the first 53 bits of the mantissa are used? I don't know how accurate LDC is when it sets up compile time float properties. But what do you get when: pragma (msg, real.sizeof); pragma (msg, real.mant_dig); Alternatively, use a C program with printfs for: sizeof(long double) LDBL_MANT_DIG To make sure both ldc and gcc are agreeable. Have a look at rt/dmain2.d (look for fldcw) if the problem is because of what I describe above. I suppose it is not similar FreeBSD ( according https://www.netbsd.org/changes/changes-7.0.html#x86 )
Re: questions about NetBSD port
On Wednesday, 3 February 2016 at 06:25:49 UTC, Joakim wrote: On Tuesday, 2 February 2016 at 18:45:20 UTC, Nikolay wrote: You're probably better off porting dmd 2.068 first (as it's the last dmd written wholly in C++), using it to compile dmd git master on NetBSD, then porting druntime and phobos master. Porting dmd to NetBSD/x86 is likely easy: simply follow what the other BSDs have done, as you did for ldc. I decided try to repeat LDC team forkflow and cherry-pick my commit to ldc branch (druntime). There are a couple simple conflicts in src/core/stdc/locale.d & src/core/sys/posix/signal.d, and one absent (in master) file: src/rt/sections_ldc.d I successfully build and run druntime unittests on NetBSD after resolving conflicts. PS I created new pull request to druntime: https://github.com/D-Programming-Language/druntime/pull/1492
questions about NetBSD port
I am porting LDC/phobos/druntime to NetBSD. Currently my patch is merged into LDC master. I have several questions about phobos/druntime and general workflow. As I can understand I should prepare pull requests for phobos/druntime master branches. LDC team will merge/cherry-pick changes into ldc branch from master later. Is it correct workflow? Because it means that I can’t check my patch: there is no dmd compiler for NetBSD + phobos/druntime master branches. Also I have a set of issues with real (long double) type. Several functions absent in NetBSD for real type (more specific - they are just aliases for functions with double). Other functions return less accurate values. I have to disable a couple unit tests for NetBSD. E.g. std/conv.d:2835 assert(to!string(r) == to!string(real.min_normal)) see related question: http://stackoverflow.com/questions/35090322/netbsd-long-double-trouble But also there are a set of unit tests where I have to reduce accuracy. This problem affects std/internal/math/gammafunction.d, std/math.d, std/numeric.d, std/complex.d E.g. std/complex.d:792 assert(sin(complex(2.0L, 0)) == std.math.sin(2.0L)); I replace with: assert(feqrel(sin(complex(2.0L, 0)).re, std.math.sin(2.0L)) > real.mant_dig-10); My question is: should I wrap such changes with version(NetBSD) statement or it is acceptable reduce accuracy for all platforms? PS You can look to my code here (netbsd_patch branch): https://github.com/nrTQgc/druntime https://github.com/nrTQgc/phobos
Re: vibe.d benchmarks
On Friday, 8 January 2016 at 04:02:39 UTC, Etienne Cimon wrote: It's possible that those cache misses will be irrelevant when the requests actually do something, is it not? When a lot of different requests are competing for cache lines, I'd assume it's shuffling it enough to change these readings I believe cache-misses problem is related to old vibed version. There was to many context switch. Now vibed uses SO_REUSEPORT socket option. It reduces context switch count radically.
Re: vibe.d benchmarks
On Tuesday, 5 January 2016 at 14:15:18 UTC, rsw0x wrote: Have you used perf(or similar) to attempt to find bottlenecks yet? I used perf and wrote my result here: http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/1670/?page=2 As Sönke Ludwig said direct epoll usage can give more then 200% improvements over libevent.
vibed and thrift client
I am using thrift client inside vibe.d application. Currently thrift uses standard blocking IO calls. So I use async thrift client inside vibed. Some other libraries (e.g. ddb postgres drive) have special build option for using vibe.d IO library (fiber friendly). I created request in Jira https://issues.apache.org/jira/browse/THRIFT-3459 for integration thrift with vibed async IO. Jens Geyer (member of thrift team) wrote: As long as we don't add any dependencies that are not optional, that's fine. If this is going to add a hard dependency to whatever library and this is by no means convertible into something that can be added optionally, I'm not so sure if we really want this. Speaking about Thrift in general, we try to keep it free from hard dependencies. If this can be made optional in some way, either by just optionally adding it to the current D project, or (in the case where Thrift compiler support is needed) to bind this additional dependency to an compiler parameter (like thrift -gen d:add_support_for_XYZ) and some majority of users wants this, e.g. because XYZ is state of the art, that's a different thing. Could you please elaborate somewhat more about why you think this is a good addition? @other D users: Your opinion is also important here. -- What do you think about integration vibe.d with thrift? Is vibed important enough for this request?
Re: vibed and thrift client
On Wednesday, 2 December 2015 at 04:40:41 UTC, Chris Wright wrote: You would need to create vibe-aware alternatives to TSSLSocket and TSocket. You would need a server that can assign requests to new fibers. That's about it. You could easily make this its own library. No need to modify thrift. Ok this looks as right solution. I was on wrong way. Thanks
National charsets support
I am quite happy with UTF support in phobos, but support for national codepages is very limited in phobos. Also it is not conform with ranges. So I decide share my project for supporting national charsets: https://bitbucket.org/sibnick/national-encoding.git Sample code: import national.charsets, std.array; dstring s = "123Я"; auto cp1251 = Windows1251.encode(s).array; auto utf32 = Windows1251.decode(cp1251).array; ubyte[] cp866 = CHARSETS["cp866"].encode(s).array; utf32 = CHARSETS["cp866"].decode(cp866).array; Every codec accepts range of some chars and returns range of ubytes. Every decoder accepts range of ubytes and returns range of dchars. This library is not cover UTF codecs, and multibytes national code pages.
Re: opDispatch and compile time parameters
On Monday, 19 October 2015 at 18:16:15 UTC, Andrei Alexandrescu wrote: Tangentially related: since when we allow field initialization with new? I was surprised to see that this works: Thanks for this notice. I edited question on SO and I removed field initialization with new (replace class with struct). It is not related to my question and actually I wrote this code occasionally when I tried to reduce code to minimum working sample.
Re: opDispatch and compile time parameters
On Monday, 19 October 2015 at 08:41:46 UTC, Jack Applegame wrote: D template system is very powerful. This is more generic solution: http://dpaste.dzfl.pl/791c65d0e4ee Wow! I can't believe that it is possible and there is so straightforward way. You should post this answer to SO Thanks!
opDispatch and compile time parameters
I asked on SO question about opDispatch and compile time
parameters:
http://stackoverflow.com/questions/32998781/opdispatch-and-compile-time-parameters
Currently it looks like it is not possible to use opDispatch for
non trivial template functions. I think opDispatch should get
function name plus evaluated compile time arguments as first
compile time parameter. E.g not just function name "b", but
"b.p2!(int, 10)" See example from SO question:
import std.stdio;
class B{
auto p1(T)(T arg) {
writeln( "p1: ", arg );
}
auto p2(T, int C)(T s) {
writeln( "p2: ", s, " / ", C);
}
}
class C(T) {
T b = new T;
auto opDispatch(string s, Args...)(Args args) {
mixin("b."~s)(args);
}
}
void main() {
auto b = new C!(B)();
//fine: compiler is smart enough
b.p1("abc");
//oops: "no property 'p2' for type ..."
b.p2!(int, 10)(5);
auto origB = new B;
//fine:
origB.p2!(int, 10)(5);
}
Is it good idea for opDispatch improvement or may there is some
other approach?
Re: A new article about working with files in D
On Monday, 28 September 2015 at 11:41:37 UTC, Gary Willoughby
wrote:
Article:
http://nomad.so/2015/09/working-with-files-in-the-d-programming-language/
Reddit link:
https://www.reddit.com/r/programming/comments/3mosw7/working_with_files_in_the_d_programming_language/
A little criticism:
write(file, read(file, size));
truncate by reading/writing is not good sample at least for
official docs. It is not efficient. You can use POSIX truncate or
_chsize Windows system calls for truncation to specific length.
For zero it is simpler: open("file", "w+");
std.outbuffer;
In Java world you can write OutputStream out = new
BufferedOutputStream(new FileOutputStream(fileName), BUF_SIZE);
It is not clear how to combine OutBuffer and write in such way.
Re: Thrift
On Wednesday, 16 September 2015 at 16:57:39 UTC, ddos wrote: please help if you know how to get a simple example with d & thrift running thx, dominik Some time ago I could use facebook brunch with dlang: https://github.com/facebook/fbthrift
Re: Looking for GC intensive D programs
On Sunday, 28 June 2015 at 01:41:53 UTC, rsw0x wrote: Does anyone know of any GC intensive D programs that can preferably be ran with little to no setup? I think you can use big text file and Word Count sample from official site: http://dlang.org/wc.html
Re: Future(s) for D.
On Sunday, 21 June 2015 at 23:43:16 UTC, Nick Sabalausky wrote: Curiosity, what libraries do you feel a lack of? XML/Webservice - I know about JSON/REST, but often I have no choice Poor database support - a lot of libraries/drivers, but they can't win competition against Java JDBC.
Re: Good examples of value types
java.lang.String It is big problem in java. You have pointer to String object with fields: hashCode and chars array (UTF-16). But every array is object itself. So it is pointer to object again. There is pointer compression option in x64 JVM (it uses 32 bits per pointer), but in any way it is too many indirection and additional overhead for object headers. FYI It is possible that Java 9 will have value types (google: IBM Java PackedObjects)
Re: The amazing template which does nothing
On Tuesday, 28 April 2015 at 02:36:38 UTC, Vladimir Panteleev
wrote:
http://blog.thecybershadow.net/2015/04/28/the-amazing-template-which-does-nothing/
Thanks for good article
little mistake: return from void function:
/// Search a website for something, and parse the
/// first search result's webpage.
void getItemInfo(string itemName)
{
// Let's go! First, construct the URL.
return (http://www.example.com/search?q=; ~
encodeComponent(itemName))
...
Inplace array - reduce GC usage
I wrote simple proof of concept library. The main aim is to reduce GC usage and improve data locality by replacing dynamic array for small immutable arrays. You can find more info here: * wiki - https://bitbucket.org/sibnick/inplacearray/wiki/Home * source code - https://bitbucket.org/sibnick/inplacearray/src I include small demo - word counter. This program builds AA array (word = counter) for given text file in UTF-8. It is possible switch between builtin array/string and inplace array by changing one line code. I used: - unpacked List of all page titles - https://dumps.wikimedia.org/enwiki/20150304/enwiki-20150304-all-titles.gz as test sample. - Ubuntu 14.04 x64 - dmd 2.67.0 - dub build -b release - ./inplace_array --DRT-gcopt=profile:1 test_big.txt Here results. Buildin string: GC summary: 1355 MB, 12 GC 5659 ms, Pauses 3116 ms 1436 ms Inplace array: GC summary: 715 MB, 22 GC 5281 ms, Pauses 4207 ms 938 ms As you can see it is possible noticable reduce memory allocation (1355Mb - 715Mb) and max pause time (1436ms - 938ms). So it is possible improve situation with GC from new side.
Re: Inplace array - reduce GC usage
This reminds me of another useful library here: https://bitbucket.org/infognition/dstuff/src/ See gcarena.d Thanks for link. The main difference is that I want elimanate pair pointer+data at all. It is more effective to store small array as value type.
Re: Access Violation Tracking
i also developed a habit of writing assert()s before dereferencing pointers first time (including class refs) in appropriate places, so i'll got that stack trace for free. ;-) and i never turning off that asserts in release builds. If we can't rely on system level may be we should have internal check for null deref like for array bounds?
Re: Access Violation Tracking
i also developed a habit of writing assert()s before dereferencing pointers first time (including class refs) in appropriate places, so i'll got that stack trace for free. ;-) and i never turning off that asserts in release builds. About null pointer deref core dump I think, it is problem. Dland on windows gives stacktrace without any problem. In general it is expected behavior for many people from different languages (Java, C#). So from my point of view it is bad idea has core dump for null deref in linux by default. As I remember current linux handler is dirty hack, and it is main reason why it is disabled by default.
simple question about function call syntax
I found this code sample in vibe:
void connect(NetworkAddress addr)
{
enforce(.connect(m_ctx.socketfd, addr.sockAddr,
addr.sockAddrLen) == 0, Failed to connect UDP
socket.~to!string(getLastSocketError()));
}
What does mean .connect? Where I can find description of this
syntax (dot + function name)?
Re: simple question about function call syntax
right here: http://dlang.org/expression.html#PrimaryExpression language documentation rulez! ;-) Yes I found it. Correct link: Module Scope Operator http://dlang.org/module.html
Re: Deploying Vibe.d applications to OpenShift
Please let me know how you did it, because I know it's possible with the DIY-cartridge they provide you(atleast it should be). I tried it some time ago. It is possible but: - vibe.d requires a lot of memory for project compilation - it is hard to install additional libraries (it is not usual Linux distrib)
