Re: Mac Apps That Use Garbage Collection Must Move to ARC
On Tuesday, 3 March 2015 at 02:05:08 UTC, Walter Bright wrote: On 3/2/2015 11:38 AM, Martin Nowak wrote: Compacting is indeed easy once we have a precise GC, and can be done partially, i.e. objects pointed to by the stack/register are pinned. Also unions. Compacting doesn't solve the inherent performance problem of a conservative GC though. It's the capability to run small incremental collections that make modern GCs fast. With a conservative GC you always have to mark the complete heap to even free a single object. Shoveling a 1GB heap from main memory through your CPU already takes 250ms, and on top of that comes memory latency for non-sequential traversing and the actual marking.
D 2.067.0-b3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Glad to announce the third 2.067.0 beta, this time with installers and documentation. https://dlang.dawg.eu/downloads/dmd.2.067.0-b3/ Soon to be mirrored and available on Travis-CI. http://downloads.dlang.org/pre-releases/2.x/2.067.0/ http://ftp.digitalmars.com/ This beta comes with 7 dmd and 2 phobos fixes on top of 2.067.0-b2. https://github.com/D-Programming-Language/dmd/compare/v2.067.0-b2...v2.067.0-b3 https://github.com/D-Programming-Language/phobos/compare/v2.067.0-b2...v2.067.0-b3 - -Martin - -- To check the *.asc signatures, you can import https://dlang.dawg.eu/downloads/d-keyring.gpg or compare them with this key. pub 4096R/0xAB8FE924C2F7E724 2014-09-01 [expires: 2018-03-03] Key fingerprint = AFC7 DB45 693D 62BB 472B F27B AB8F E924 C2F7 E724 uidMartin Nowak (dawg) m...@dawg.eu uidMartin Nowak martin.no...@plugintheworld.com uidMartin Nowak c...@dawg.eu sub 4096R/0xA78068C444E12E4D 2014-09-01 [expires: 2018-03-03] Key fingerprint = 0D91 720A 3DA5 F106 CEB0 7070 A780 68C4 44E1 2E4D sub 4096R/0xB273811612BB1939 2015-02-27 [expires: 2018-03-03] Key fingerprint = A734 4DAD 3C34 1EA1 2D13 C4E6 B273 8116 12BB 1939 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU9lZoAAoJELJzgRYSuxk5mQ8P/2GNHW7aNV3wD2uHpzAKWW52 l6XM47EeJS/jnaUsOI77lz3dgW/LjJZ40zL1wT9jXGDAPxPEbnkElubeIbdVVf8I MeG2F+Um3LXRYaJnOHePLceOjDqhu9oVlo+hrSDdvDKJPJVrE4s/MZEdIMql0Lz9 97UW4MBycnUKFY0ZQ4MWSrHTqaQeLhZqcXIXqIHBE/mEG6OhYFTf6p1lucPwvLLo koKA+4XZHqI8ak5xEwrNRqkFR69dYfqLVxD/h7RW7lZ7WsMq0p8IHMW9lPseFm2/ l1t0xo5nFTOMDys20Iwzc+zXhP2JwDmj2nFzLGb/L/nmQz3Uv+pEU3G63ZF4/Llv uy12np2M8bSkUVviaxi+ydS4tYMjo214nY436+GSfRDtbPdoWibz0JcyJcCko1kJ IXKSG0hEgojFTOVtxflKc0XwtJ9+w15I9FIUYmQbKacYu7Jy60wvPYiVSS3v9oFp yXIqNo0iWWE8ESiYtLbqiIo9qcnQ5hNNoIim5eP64ZpCoDt+4ivCqngvhvMoJ1uE liEx/YI8YHl3alBWPS4wEBTIUYrBiSoX7Igw6YYJdD755mIaJleoM1yOKNO7pINd TvK4GpKVBV7nhpifuevOjdDYgB97CjXXU9g++aYzIzO/33YxNxfJ7J4t5P6lBuJq BT59SrlASZy40gG1zgh7 =SeZ9 -END PGP SIGNATURE-
Re: LLVM 3.6 released - LDC master branch/0.15.1 is ready to use it!
On Friday, 27 February 2015 at 19:44:01 UTC, Kai Nacke wrote: This is the 6th time that LDC and D are mentioned in the LLVM release notes! Thanks and keep up the good work.
Re: DConf 2015 discounted hotel rooms now available
On 01/16/2015 11:17 PM, Steven Schveighoffer wrote: Monday is Memorial Day in the US, just about everyone has it off. Last year's memorial day I was standing at caltrain station, 5 AM, realizing the train wouldn't come.
Re: GSoC 2015 - Application Rejected
On 03/03/2015 01:42 AM, Andrei Alexandrescu wrote: We've done well, I think, in 2011 and 2012 (except for the one student who failed to deliver) so something about our reporting might have failed GSoC's expectations. Are there some documents/emails available. Will get back to you after the IRC, maybe we can find out more.
Re: This Week in D #7 - summary of reference counting discussion
On 03/02/2015 05:19 AM, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/mar-01.html https://twitter.com/adamdruppe/status/572249079352299520 Thanks a lot Adam, this newsletter is really nice to keep up with the important stuff. And there is a RSS feed as well :).
Re: GSoC 2015 - Application Rejected
On 03/03/2015 01:45 AM, Andrei Alexandrescu wrote: Comparing our application with that of the accepted language projects might yield some insight. I ran a cursory read of Clojure's idea page and on first sight it seems comparable to ours'. -- Andrei Indeed, this year our ideas page and the mentors list were much better. http://wiki.dlang.org/GSOC_2015_Ideas http://scala-lang.org/gsoc/2015.html
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On 02/26/2015 05:08 AM, Walter Bright wrote: A lot of benefit simply came from compacting all the remaining used allocations together, essentially defragging the memory. Compacting is indeed easy once we have a precise GC, and can be done partially, i.e. objects pointed to by the stack/register are pinned.
Re: Mac Apps That Use Garbage Collection Must Move to ARC
On 02/25/2015 10:50 PM, deadalnix wrote: I don't think it make sens to completely discard the idea of barriers, especially when it come to write barrier on the immutable heap. At least that should certainly pay off. Before the argument gets lost. http://forum.dlang.org/post/mcqr3s$cmf$1...@digitalmars.com Write barriers would cost a low single digit, e.g. 3-4%. While searching for ways to avoid the cost I found an interesting alternative to generational GCs. https://github.com/D-Programming-Language/druntime/pull/1081#issuecomment-69151660
Re: GSoC 2015 - Application Rejected
On 03/02/2015 08:08 PM, CraigDillabaugh wrote: Unfortunately our organizational proposal for the 2015 Google Summer of Code was rejected. Thanks to everyone who helped out on this, especially to those who volunteered to mentor. Just read that as well, it's a pity. Thanks for all the good work Craig. I've asked Google to provide me with feedback, and I will post that here once/if I get something from them. You sent them a mail? Let's hope we get some qualified feedback. I'll try to attend the IRC feedback meeting as well. -Martin
Re: phobos regressions
On 02/28/2015 11:35 PM, Walter Bright wrote: Can you please fix your newsreader submitter to not post these? They're fine for email, but out of place in the n.g. done
Re: Berlin D Meetup Feb 2015
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/2015 03:04 PM, Ben Palmer wrote: Wrapping the RNGs can cause problems as structs are passed by value. This means that if the same RNG is used in subsequent calls to say randomCover then the same sequence of random numbers will be produced by each range. A simple solution to this would be make random ranges classes. This can also cause problems but with memory management (we want to avoid lots of small alloc and free events). It also does not address problems with functions that make bad assumptions about their arguments. If we can solve these problems then there are several different avenues to push forward with new RNG wrapper functionality. There are also other opportunities for looking at random number generation. I actually had an idea how to solve this. https://issues.dlang.org/show_bug.cgi?id=7067#c19 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8i+vAAoJELJzgRYSuxk5u/8P/3znsvHfZ3+hiG4MfLUakBfA PASqYeesud4EBOYf7ztgYqCNziSZ5Zd4/fe9PyzgC1TMRzVfseckhpU9WNaVvtMd Ej5SnY6ylGma3lr9Bfl2EZWU6NgLvwgB/ZIYlJb6WjLyGaQy03niIcOlqEg4rHo/ vLr7qcCqBGGgUB3K+riQRP9ZDrub2JF5F2yad+fZB+bAObgqujENqLd+YiVNvW8p VeuDOacnb7S+tAakIUXOLJ8+peMEgtkhIKiRUjsXR7Q/QjwNLNMwBdTnrPKlyCNH Vt5f8vtzHRadFypHWvYvinNW4d2Eg62IZjYutzLia1AsHfrnCpt5l476gwaQnUa9 Zti22d0m8usKFR/MqUbhZ3c7xqBVcS9ib9JpnGVxnzWmI4zp7/PP8363IEZb84Yg U15vynIpIxMXsL2c8/qTGhL6wYSRX6+7sP+a+ZoBughAGAqSVmfbLhrAzJYg5SMq jEvB49jaWVS8VH/KS/OBHLedUoTad7BpFeMJk+GiGcd3vdhQJPsIv1ji7fCBQtBU 8hFjJsb/GYmihrfa8ds018DhmvV4OgOW1+a8xzYs3oKOQ5cq251U1oq+oh4lKoWO DMjUiPoa0zAMvrFRBirGs3tBO0361/et/hCwxLrKhhoR1mVTdm5kHEIv16SIjQiF W1meFORZw8QGBkvwz5Lm =OjGb -END PGP SIGNATURE-
phobos regressions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Quite a lot of the open regressions concern phobos. Maybe some people not reading the dmd-beta list may help with that? https://issues.dlang.org/buglist.cgi?bug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDlist_id=198782query_format=advanced -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8jc6AAoJELJzgRYSuxk5NIAP/3sqCuwjoW7BfityRPZZLzK3 vc6+ye8D7/K40rOvhGng/96UqtfHD7AWmV3SCRde01TEA6OpOHc7pzMAwLcsA/qM z7nJ1C905zUos4QpkpaF15Ujbkd7f0WoOQl25pkzJjiurJVmPe3SMOwkVdBqly8/ PNmPNtwvtBPszDa/o2d+YihZaz/KQgr93IvnuebtfAhRB2vBjT49vF5X3gxQMGtM bDptsFlL5tLz+TYlf6jo3KyrKYPIssSDf6R2ghOLCjg/35+xVnN8LBAr1/v92JF7 M3JfTG9eEcSBvBbFj3j4LHwVwe94GIwifrzviJHmz8EspKJn60jM8v9gdICkxo3R U2NwDt2y4+Jh6LGbk2AbkhgBmMIed7ucJjSJDLV1+IDY+hISmU9dBRL9VWHYoJtg yhN7uxjKRW05ca1+HUlMUN3U37Nxpn9W/YSAGi5qaDyctSv3vCsXx9DJQFTBpy7l 4AorARYuSUd3sHNqUsROrPNWDc6izy2iO3gBoTQIbztpJacAneIEA/7AZsrxggwW 2MQOgx1HLLBDdtKe4sjNYgQy6+sMEGutxDdOx1QZZwWTU1OP/EmL68raSzU/gMgI wIdGITzWilyJ73d/DaRCe6c83rOJ7vhgnUsO4P3AV8hDj39HCCB0wE5U4utFo42d UhILF18brJ273QT1YTId =auwt -END PGP SIGNATURE-
Re: GC deadlocks on linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2015 09:27 PM, Byron Heads wrote: I have a medium size daemon application that uses several threads, libasync, and daemonize. On windows it runs correctly with GC enabled, but on linux the GC causes a deadlock while allocating memory. Have you been able to resolve the issue? There were a number of suggestions in the thread, but we never heard back from you. Meanwhile the author of daemonized came up with another idea, using exec instead of fork. https://github.com/NCrashed/daemonize/issues/2 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8U14AAoJELJzgRYSuxk5wnEP/R6nFZECdFsNSFK/Bmsys5WI RmYt8FyS5WJt/2tM/jKgN6k5WJLP+ZniSHPTMdWO4pGxJTaK6zGvMXVYEHPFgIDp RPcJhZ/J1KXyfOyR3by/23opvGaWqAJXIx3yBfYBhvjNNpjQrGxqQEwdT4sbDvz1 AtUZ+Tc1CoBo+3hRNESyk9FNa3c58adu5SWkpErJezrg4TFzYg7sKytbZEtb5T6U OWLVlMqY8Q6AyskbEUqxfQt8lba9fM5Eeg8gbzf7ShCZwrzviBkrhdTWrodv8kHo HeMZmRIBKmz/L0Ce/7NSV+U0htEB+DAB2LSYRKhy/qYwoLHi8UNruqv3pf4PU7Ly 4atq5XTcFNS/ywL8qkP8OMmcdBN0pBQNsDfmG2w1DsWANtK/cLqwS50O8TXCxpv1 hlQ/CgRD6jJWujleaDOhuOZWYzJ0Xwk1a5BGjoO5MkQaHeRZgalSN4rkmoPZQz1t H2kA03JMTVkEx2AllPKHdQCcNEV0wpI7sJNRWh9kewtdzW0SQtlV2NYM9U2gXPJe u+zYuWRLGpWOrqItzZGt+Z+NSrNziV0cO/IpogQRjMPtLXsRgaFofzaOO81l7OWk SWnE3bT2PO2sdZ0Z3uf/c+KAosDJ+5AhD9FXmuEemIc4S4/1yKJSVj7BtsomBxE+ hGfLvRuNjUDQil+WjC0t =MNgH -END PGP SIGNATURE-
D support in syntax highlighters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It would be nice to get up-to-date syntax highlighting support for D in the commonly used libraries. Those libraries are used by many other tools and it's important for D's visibility that it's present in any list of programming languages. - - https://highlightjs.org/ - - http://pygments.org/ - - https://code.google.com/p/google-code-prettify/ - - http://prismjs.com/extending.html#language-definitions - - https://github.com/jneen/rouge - - https://github.com/rumpelsepp/rugments As usual go is already supported by all of them. Updating the existing support in pygments and highlight.js might be a good starting point. https://bitbucket.org/birkenfeld/pygments-main/src/943cb8da8444b832804f6cebf9679305b22f8b15/pygments/lexers/d.py https://github.com/isagalaev/highlight.js/blob/master/src/languages/d.js -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8NEyAAoJELJzgRYSuxk57k4QALXFMY2RFECltWV9kq2gCi0v 8VicmWM/nSfKJCMrxduIP/Hu3vZ5jzFtKRgKPHtxKdKjRfpDOWc79EcnyxMC2T/u 2GdWZJl6q9nWWVQcFCr/ejxdLUt4Eew8hnN5hTGb8UHF7HfOxpQv0Ch+2RfV5KhA xDGfoRGK6B8MspCO3xP+5lgXt9CUp9GRHo8gq6UgObO8fepj4j3ut1oilVJQBD0K WvRE4T7cls3ZuuW0jaabTpbHR8MoS6C2UR64fCAnSAFPN6t5hX4url0xu5h08Ffh ztE+fxEiWcUoI2X/qLAcIGkR0YIUjng8o9yqCagOoMjjhWqOeikSOmtCH4dkBDPS Ldpzp29MFnjeUNy5VBWTiEVcoV7G1/+B3S/T3ZYVzfIe9lOWEeN9Y1gfJ3g02zMd 7yBLOeKMZ8c8ORZLXiNzvBtkV79xJ5JWAbjG22mykSlqRMvPSFzRQx1NE0sEeKMs VC6LYY71xB76h41spSzGpn82s2NauK79o3kwaLhALM6LukQqrkQGeuxrLxYlgWRq mEUGUwq0Nv//pajIx0DDcsN9cD7yKXlI8rQrH5yS5clRExKRsT+vcQ4HzBT2d6Gy AA44GkHWEtKUrMMCjgpvKrJuC+rMBoMrs2biVjRjqyxVy9zYp2Gf/Ua01YTiJlHL zu/+/GDJsrN8j4uRrVbt =24UH -END PGP SIGNATURE-
Re: Mac Apps That Use Garbage Collection Must Move to ARC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2015 03:23 AM, Walter Bright wrote: - RC is slower overall This claim isn't true for almost all applications when using a conservative GC, except for programs that produce a lot of garbage and have very few long-lived objects. The memory bandwidth consumed to mark long-lived objects during every collection dominates the GC cost even for small heaps (say 100MB). -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8Nu9AAoJELJzgRYSuxk5ONwP/0vfyS4UH4OuyXASpyTRdEYQ PsAi68S1oSqJaZXGkjVYSsPBASA3qn8Vf/n2002c4NKjGnEbywVyUGijmzyEx94q Ja8TKtIvw4HJ8xCQEd3NvKwttJhY+K868hAH2YWEiOknad0x7MV3N0GXb7yyEFbt b5AMJmr5Qs+6wTvOYcwgdJevznaE4LjxtI/iURsjQ7X3tfg6igb3W96Ehx/5URFB upP5lCswBJ5agz8TbOSVeqk1AjR7dYYgtSDhF+IhkH9Ig5lJ68SECWNG7Ru9ixmK JqUhyGJXWpK5UWkDE9zggUQ2M1QVXTnX/QzzUGcvnbqC1SgHbd79gTwQWOLSOy8i 5e464zCVe1QcMmDK5vUxcuNCr9XiATV/k9M+SHtkXu2AZvx0mQdWBKPVnQmTzizQ Tf+yKT84zKz4kZK6cfoP9KsrDlWLcU+L6vmghkqFfkk0mpvkoXEF7mNsPlWw+bvn GAEJvj+xItFkulaE9X+HWbvRs5YeFOSuV7qXRKoTGRvhnr49XaDLi2jANLBt2SLu Ku/pjkwl20rHUB3Q8+7qfoqjm/iunujZxqVw+vXzRvp3hrvbMiFW2b6jHzl8WN7n LceLniG/sk4/hLILlu4CKgiLQRk3PxQEBJHqUaSqNZZS7Wrp/g6b3nKaGzqv2ehM 2RRjU57Ptw6AQsw+QT9E =ANkN -END PGP SIGNATURE-
Re: Mac Apps That Use Garbage Collection Must Move to ARC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2015 01:43 AM, Manu via Digitalmars-d wrote: D's GC is terrible, and after 6 years hanging out in this place, I have seen precisely zero development on the GC front. Nobody can even imagine, let alone successfully implement a GC that covers realtime use requirements. We have achieved quite some speedup on the GC front (up to 50% faster allocations) and we work on a few more improvements for the next release (good for at least another 20% speedup). There is even a useful idea how to implement an incremental GC. I might give a talk about the current state at DConf. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8N0MAAoJELJzgRYSuxk5/4IP/AzBOzt3jc77vwovtV+J9C5E D6jE/y1pCkmlQ9Wjb7yl5F0Ul0bQiDXhGH55rkzYO/AHrCZLGZ2TSr+CchCeDR64 7dVmDCLxDN+Tipo3iOZVZzrosDKISRv0H3o82NUqmWF2jqoXdRZJthSigdiKENAW 4wIIfScBqRdATHtFCw2heSScYMxE480WeEQx2rIjLLuDMD2S0uua0cKDBOlMVV+v t32AnCOyeTL2TGwtO1TTCZVbRH7c4ob1F1dTH6G/nu9K+vTbMJ9FNhBmnwVnYu12 V+RK+WDgogxN9I4hTE/kUKTxbhA6k9u3sG09tql0mIBbLBkVoSsC3ib9WHSOS/ki KcHDNJAvy3pOR5gBTlR/x24r3G1RGkJcjiFTPaCan4oqrsveY4wQ63wImQqoejXj 8iOvJ88ssYTWkol0nSR4QntOeGNK+ni37U2MpBizKdflaVMN75GhDkGlZ55Rt1BA L1SpKUC5c9Kyz43Wvf0QZjWoSvB4LZJc9daU1sMIkCn20nKM6G8rY9PtONE9xoQE 2hYW9S5ufrm9YRuKy2qJmsfEw0Ou2S5MiH6brgHhqnmgWpU9mK3AKN0o1JfwxTAK nHQxrudAB0egpAePUs2wW8jHWXbdtP2GSM575AKr8JMYZkf/K8UoXsibTGPSKb5W VLL35ZKr8y0oVctWnUEd =UARS -END PGP SIGNATURE-
Re: Mac Apps That Use Garbage Collection Must Move to ARC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/26/2015 01:50 AM, H. S. Teoh via Digitalmars-d wrote: I don't know how typical this is, but in my own D code I tend to use arrays a lot, and they do tend to add significant GC load. A recent performance improvement attempt in one of my projects found that collection cycles take up to 40% of total running time (it's a CPU-bound process). Is this project public? I'd like to benchmark it with the new GC growth strategy. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8PAQAAoJELJzgRYSuxk5yCcP/0lsmrM66SjwyxPfYzJmAsIA mSCBogIoWpvL7R4uaZNvnYFBg50O1ddiLIIYaon4tX/b40UC6R36bFjx4A6j9WSr PepNp0RFp8lFfXmeozPkJfEL3cVBFR70rrOySk2DNnFK/5heHXcR6gCyZ4xZaggi gT5HtwhI/lZ5MKxpGk8sZpFDjaLHcGTHebjRV/sL+ItHAULcU8qgEm29yzlekgUY v96EN0w83bwhjf2KZ97oKCWF6wW4tFKH+AXi2WoKjt/54xYyBS4tyXgtkMY9YmJ2 U8OQ03ASIP+tLlqJfexCwWxgHd8U9oUiHJoM9kCRw3XxwnlLIV1h/R9TBPrRcQFu 8DVQgniHiGab0tvhX9pD9q7blILsEPArSIIXFCTEU534dhjSplYu4Fu3Os7dGR5+ /ughG/ZyzLOJWI2iaI7H0hL2UVcO69pnTToOZYEHlZhFGHTxjPuesDsJUIv7ZjDN iOWYgLVk3pFHDctIhhFJoqyHSz4pbadmU2bCksrT3S1feHyadmitE2eA5OwCpz9Z Iz5jCGpN4QxF38PTg9OT3h5xRZvS2S3NvfzKdRzCfEzFBq7dUy1q34ir86Cw4OmE 4vRRxIjNCwpeju17FWOnR11WLXIvNJYQqznXwKyPEZX9HvPK01GmgsfutBOHKOez YvgGhDqNJIi5VGGZZAju =1GfD -END PGP SIGNATURE-
Re: Mac Apps That Use Garbage Collection Must Move to ARC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/26/2015 09:29 PM, deadalnix wrote: Page fault ARE write barrier. If done at kernel mode, it's too expensive anyhow. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8PBSAAoJELJzgRYSuxk58EgP/1ZJMTJ4srl8A+67dr1jpKwv vqZlsKvbZ0ZpPZwO754TnWoaekgqPumvqmdjjHpOiV5fyu8mHBq81Jg9tJB9K3Yc fedTM/xQtj+MTuARedyAqDAlzS7WBhc0Emx9QCBJJWwIuXu6aMvLZ9UO25eG0S/I qXJ+/gIF6pfzmvn1/vsMzEkIeK75PslR8FQA9lGw30R9cN8vIeR5ZrOdyLv3w/Az BbvjKg1086e7a9Gyxfo9ZXGmaoippxzx3jIAaqS9Gy6KZwNIrWqBX3fww+P3qqxZ DstYPPp5b57xGjEt+e1vRDydW4OEHcQ1wEw7Ozfi/s6qCTRBj5xD9l+8idffyYYp d76PcJGq3rByyP9ag1AxurEBVyIpPIPQNCy2/kwYET6s8aLc4FQsWtuI2oOp8fRs m0k4pp9F8n62/PHjkbkUaHgFZOKedFeXfunT/21Be+pUhdFBwg438C70WerQt2Uy UtiERO/2BhCCyq3+SFFtsfbCAFxPTNWCPbCnDhlPscrwl2YPCzYH1XvrdV0lWAG/ cI32lj7IdXWbO5otuO1qOPwbDVgLMTnpx2/wXrCriubTvBQTCeasJDlAcZYBAVyb yQ1PZtbIN6Woa/6DJmR67YsuW3ag998oEXXP/LBo76rxE969OvcDi6Kh01MzweGb i+QKVhgLT57Yw1urIwlY =gVgL -END PGP SIGNATURE-
Re: Mac Apps That Use Garbage Collection Must Move to ARC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/24/2015 10:53 AM, Walter Bright wrote: Even 10% makes it a no-go. Even 1%. Write barriers would cost a low single digit, e.g. 3-4%. While searching for ways to avoid the cost I found an interesting alternative to generational GCs. https://github.com/D-Programming-Language/druntime/pull/1081#issuecomment-69151660 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJU8O+kAAoJELJzgRYSuxk5dbIP/2+BWeTD8nWzxFwoUugwD7k3 +JqfKi3BFOpY+bQbg/ct+hlDcVcVMUvz/pqyMqll1v/axZasWjtNd/wydepRovv+ FU9xHyS5dSJHb/5TU6OJDHYsFBDg3a+CS1OfGXpIdpWyVAWE5ZojU916DhddxOfB Mb4cxoLUe7spRHVQ+eiXttYG97O7vVmmy7zY1/h5CUxgWLAoJe9DD4HpbgR4BaDS zmIsNMJf8rooZhIxbWiy0WJu6YFesSR8amVqiw3+Zd1ijeOyT6Pe5EC4gyvjXhoC BwvfnM0s0c3VlbWxtXdHqnJ0A8V1/XJCQ3DXSUD2D4AY2rhwkC5bLIPPyrpm86xg oGhXWwYJax9lVJCSEjJnL4p1lj+MoUpjrUMS/vEqk37p4VHcWGj6jspkq0MEVWJE wSUD/hrihzzpOHRjBxQLZWUo+JnvS+xZL/PN2sK7T1dhsZujGYIUZodmS+3915dQ kjsXXSAT0/vL+kM1WgTlDe/vxZ+toS/tuOVrRLHGktvXAKEJWUpulNKKj/bvaNUZ HNG41R+LLcOyGM0QP4TH0opUtro09EWQoT+1wIuKtZA1Ect9vCJfFmz2a8YE3MWu Q4DzY7WTQ6mCG4Kh63Ya1uJA+DKS4Abyfsu0TGfbR0GpKHer8f5Ni+kZTKM69IZn NLB9QRBtFxFSNZhZH10Y =aDb/ -END PGP SIGNATURE-
Re: curl password issue
On Monday, 23 February 2015 at 16:10:42 UTC, Andre wrote: Curl has some issues with passwords containing special characters like the hash key (#). I don't found any reference for this issue in curl and the D wrapper hardly adds anything. You're sure it isn't an issue with your program or how you pass the password?
Re: Is this a bug in dmd 2.067 for struct initializers?
On Thursday, 19 February 2015 at 22:07:55 UTC, stewarth wrote: I've gone with static this() approach and it works. You should use shared static this to initialize immutable variables.
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 20:27:08 UTC, Byron Heads wrote: Adding core.memory.GC.disable; to main causes the application to work correctly (and quickly till it runs out of memory :D ) GC.disable shouldn't run OOM, BTW. http://dlang.org/phobos/core_memory.html#.GC.disable
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 20:41:12 UTC, Dicebot wrote: Any chance you are using gdm-3.12.x? I was so mad when I have encountered this: https://issues.dlang.org/show_bug.cgi?id=4890 Indeed, maybe http://dlang.org/phobos-prerelease/core_thread.html#.thread_setGCSignals might help. We should probably try to improve druntime to only use a single signal for suspending and resuming.
Re: GC deadlocks on linux
On Wednesday, 18 February 2015 at 20:27:08 UTC, Byron Heads wrote: I have a medium size daemon application that uses several threads, libasync, and daemonize. On windows it runs correctly with GC enabled, but on linux the GC causes a deadlock while allocating memory. Can you reliably reproduce the deadlock? If so please attach a gdb to the deadlocked process and provide us back traces of all threads? If you can share the code (maybe privately), that would help as well.
Re: Reloaded for dub
On 02/20/2015 03:00 PM, Kingsley wrote: I use for developing with vibe.d and other dub D project that have an executable binary. The code is here: https://github.com/kingsleyh/reloaded Nice, want to contribute? https://github.com/D-Programming-Language/dub/issues/446
Re: GC deadlocks on linux
On 02/18/2015 09:35 PM, Byron Heads wrote: I am in the daemonize library https://github.com/NCrashed/daemonize Might want to try using libasync without multiple threads. http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them
Re: We are Beta (2.067.0-b2)
On 02/19/2015 11:06 PM, Brian Schott wrote: Many of the beta-2 files are missing from downloads.dlang.org, and all of them are missing from ftp.digitalmars.com. This makes testing the Debian packages or using DVM impossible. Quote from the dmd-beta post. We had some troubles with the documentation generation. In order to not delay the beta even further the zip files don't contain documentation, the dman tool is missing and there are no installers. We'll try to deliver those subsequently or with the next beta.
Re: Google Summer of Code - Again
On Thursday, 19 February 2015 at 19:19:51 UTC, Martin Nowak wrote: dawg BTW, please mail me for urgent stuff 'code dawg eu'.
Re: Google Summer of Code - Again
On Thursday, 19 February 2015 at 18:31:53 UTC, CraigDillabaugh wrote: Can I get your Username? dawg
Re: let (x,y) = ...
On 02/19/2015 11:04 AM, thedeemon wrote: SML, OCaml, Haskell, F#, ATS, Rust, Swift and others have it as let keyword, so personally I'd prefer continuing that tradition. It's semantically different though because it doesn't declare the variables.
Re: let (x,y) = ...
On 02/19/2015 12:59 PM, bearophile wrote: It's also a great way to show what's missing in D syntax. True that.
Re: Google Summer of Code - Again
On Friday, 13 February 2015 at 22:59:32 UTC, CraigDillabaugh wrote: Also, Martin have you created a profile yet on Melange? I logged into it, what do I need to do?
Re: Google Summer of Code - Again
On Thursday, 19 February 2015 at 18:00:22 UTC, Martin Nowak wrote: I logged into it, what do I need to do? OK, I have a profile with MartinNowak as public name. How do I connect with dlang?
Re: Botan Crypto and TLS for D
On 02/18/2015 02:14 AM, Etienne Cimon wrote: I'll be working on HTTP/2 with websocket-style full duplex communications Glad to hear that.
We are Beta (2.067.0-b2)
Find more information on the dmd-beta mailing list. http://forum.dlang.org/thread/54e41ca2.4060...@dawg.eu
Re: Bugzilla email queue jammed?
On 02/19/2015 12:51 AM, Brad Roberts via Digitalmars-d wrote: I just looked and there's a little shy of 1000 messages queued up to go out. That was apparently cause by me updating the 2.067 branches. I probably should have deleted and recreated it instead, but I didn't knew how the mails are generated. You have some sort of github hook that gets called for each added commit?
Re: MAP_ANON
On Sunday, 15 February 2015 at 21:38:17 UTC, Vladimir Panteleev wrote: I'm not sure if, for the case of extensions adopted by multiple platforms, it makes sense to force users to import each platform's module. Was creating a separate module with shared POSIX extensions considered? I'm not sure either. We try to be strict to avoid inadvertent porting issues, but MAP_ANON is supported on so many platforms that we might just leave it in posix.
Re: MAP_ANON
On Tuesday, 17 February 2015 at 08:59:48 UTC, Martin Nowak wrote: I'm not sure either. We try to be strict to avoid inadvertent porting issues, but MAP_ANON is supported on so many platforms that we might just leave it in posix. https://github.com/D-Programming-Language/druntime/pull/1176
Re: Time for 2.067
On Saturday, 31 January 2015 at 02:22:59 UTC, Vladimir Panteleev wrote: I don't know how the .html files that are included in dmd.zip are generated. Please try and see if it works for you. If not, I can look into it if you open-source your process. https://github.com/D-Programming-Language/installer/blob/4d57e861a2b15767f5e004b74a4578205dc03e3e/create_dmd_release/create_dmd_release.d#L784 Not sure if anyone is actually using those HTML files.
Re: Git, the D package manager
On 02/02/2015 09:09 AM, Vladimir Panteleev wrote: Change my view. Most important point for dub, there is central registry that enables the http://en.wikipedia.org/wiki/Network_effect.
Re: Google Summer of Code - Again
On 02/09/2015 02:47 PM, CraigDillabaugh wrote: Google Summer of Code organizational proposals start today. I will submit our proposal in the next day or two. The evaluation process starts on Feb 23rd, so I imagine we should still be able to make updates to the Ideas/Mentors pages until that time without trouble. But anyone who wants to comment on the proposal should do so soon: https://github.com/craig-dillabaugh/dlang-gsoc2015 Anything out yet? Just made a pull request myself.
Re: Google Summer of Code - Again
On 02/13/2015 07:56 PM, Martin Nowak wrote: Anything out yet? Just made a pull request myself. Also uploaded a rendered pdf (with the links fixed). https://dlang.dawg.eu/dlang-gsoc2015.pdf
Re: Google Summer of Code - Again
On 02/13/2015 08:58 PM, Rikki Cattermole wrote: s/CSmed/Cmsed/ https://github.com/craig-dillabaugh/dlang-gsoc2015/pull/3
Re: D Meetup in Berlin
On Thursday, 29 January 2015 at 11:47:26 UTC, Ben wrote: Good news everyone! We have a date and location for the 2nd D meetup. The meetup will take place on Friday the 20th of February at 19:30. The new location is the 3rd floor of the Co Op Berlin building (http://co-up.de/). This meeting will involve a presentation and I will post again when the presenter and topic are confirmed. Thanks Ben for organizing this, will try to be there.
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 18:00:19 UTC, Jacob Carlborg wrote: On 2015-02-03 23:29, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. This is affected by the -inline flag? Interesting question. I'd say without -inline we don't perform an inline pass so nothing gets inline.
Re: DIP56 - inlining
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP56 There's been enough discussion, time to make a decision and move on. Great, gets the job done and you even thought of on/off/default to apply this to multiple functions. It provides the common inline hint semantics, so it should be easy to support across all compilers.
Re: DIP56 - inlining
On Wednesday, 4 February 2015 at 09:39:56 UTC, ponce wrote: Would pragma(inline, bool-expr) be supported though? This would allow to pass inlining as a template parameter (can be useful to force recursive inlining, or to force inlining depending on the call point). Nice idea.
Creating named tempfiles
As you might have noticed already, this functionality is currently missing in phobos leading people to write buggy or platform specific code. We just fixed this in dub. https://github.com/D-Programming-Language/dub/pull/497 Time to finally add this to phobos, what's missing is someone to implement it ;). https://issues.dlang.org/show_bug.cgi?id=13996
Re: Git, the D package manager
On 02/02/2015 10:44 AM, Andrej Mitrovic wrote: What's worse, I have to wait 15-20 minutes for the latest tagged version of a dependency to finally show up on code.dlang.org. Filed as https://github.com/D-Programming-Language/dub-registry/issues/92. Please comment if you have any other ideas to improve this.
Re: Git, the D package manager
On 02/03/2015 09:51 AM, ketmar wrote: 'cause it really sux as a build tool. Not getting into any of the lengthy discussions of yours, but 'it sux' isn't really helping anyone to improve it.
Re: Git, the D package manager
On 02/02/2015 12:00 PM, Manu via Digitalmars-d wrote: If my D project depends on a C lib, then what am I supposed to do to make dub useful for me? This is a simple problem to solve. All package tools support a way to build native extensions, mostly by scripting the builds. You can already add preBuildCommands and use whatever you like, e.g. a D script to build your C library. It wouldn't be too hard to compile just a few C files, but if you already need this, chances are you need more flexibility anyhow.
Re: Git, the D package manager
On 02/03/2015 04:20 AM, Martin Nowak wrote: On Tuesday, 3 February 2015 at 02:39:56 UTC, Vladimir Panteleev wrote: I might revisit Dub again once some of the fixable issues mentioned here are fixed. Another very important argument is consistency in using packages. I recently tried digger which is a really great tool, but it took me about 5 min to get it running. Just used Digger again and I'm going to copy my console output here, because it nicely illustrates my point. ➜ ~ cd Build/Digger/ ➜ Digger git:(master) ls ae/ bisect.ini cache.d common.d custom.d digger.d digger-web.d repo/ result/ win32/ bisect.d bisect.ini.sample CHANGELOG.md current/ digger* digger.ini.sample README.md repo.d web/ ➜ Digger git:(master) git pull rdremote: Counting objects: 25, done. remote: Compressing objects: 100% (25/25), done. remote: Total 25 (delta 11), reused 0 (delta 0) Unpacking objects: 100% (25/25), done. From https://github.com/CyberShadow/Digger 8f33627..b6d06be master - origin/master Fetching submodule ae md --buiFirst, rewinding head to replay your work on top of it... Fast-forwarded master to b6d06be2346986a74937c918ed1d4ac121a9819f. ➜ Digger git:(master) ✗ rdmd --build-only digger digger.d(12): Error: module main is in file 'ae/utils/main.d' which cannot be read import path[0] = . import path[1] = /usr/include/dmd/phobos import path[2] = /usr/include/dmd/druntime/import Failed: [dmd, -v, -o-, digger.d, -I.] ➜ Digger git:(master) ✗ ls ae/ bisect.ini cache.d common.d current/ digger* digger.ini.sample README.md repo.d web/ bisect.d bisect.ini.sample CHANGELOG.md config.d custom.d digger.d digger-web.d repo/ result/ win32/ ➜ Digger git:(master) ✗ git submodule update fatal: reference is not a tree: 318ccc76669e9840f43b88e63bcfb1e461ce6d61 Unable to checkout '318ccc76669e9840f43b88e63bcfb1e461ce6d61' in submodule path 'ae' ➜ Digger git:(master) ✗ git submodule fetch usage: git submodule [--quiet] add [-b branch] [-f|--force] [--name name] [--reference repository] [--] repository [path] or: git submodule [--quiet] status [--cached] [--recursive] [--] [path...] or: git submodule [--quiet] init [--] [path...] or: git submodule [--quiet] deinit [-f|--force] [--] path... or: git submodule [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--checkout|--merge|--rebase] [--reference repository] [--recursive] [--] [path...] or: git submodule [--quiet] summary [--cached|--files] [--summary-limit n] [commit] [--] [path...] or: git submodule [--quiet] foreach [--recursive] command or: git submodule [--quiet] sync [--recursive] [--] [path...] ➜ Digger git:(master) ✗ git submodule status +c58d5b75242fcab15872acc5d922e103d3ae9423 ae (remotes/upstream/HEAD) 7a476ca6139869e89943bcf21e0b27904bdf9491 win32 (heads/master) ➜ Digger git:(master) ✗ gitk ➜ Digger git:(master) ✗ git gui ➜ Digger git:(master) ✗ git reset --hard HEAD is now at b6d06be Detect absence of ae library ➜ Digger git:(master) ✗ git diff diff --git a/ae b/ae index 318ccc7..c58d5b7 16 --- a/ae +++ b/ae @@ -1 +1 @@ -Subproject commit 318ccc76669e9840f43b88e63bcfb1e461ce6d61 +Subproject commit c58d5b75242fcab15872acc5d922e103d3ae9423 ➜ Digger git:(master) ✗ git reset --hard HEAD is now at b6d06be Detect absence of ae library ➜ Digger git:(master) ✗ rdmd --build-only digger digger.d(12): Error: module main is in file 'ae/utils/main.d' which cannot be read import path[0] = . import path[1] = /usr/include/dmd/phobos import path[2] = /usr/include/dmd/druntime/import Failed: [dmd, -v, -o-, digger.d, -I.] ➜ Digger git:(master) ✗ cd ae ➜ ae gitk ➜ ae cd .. ➜ Digger git:(master) ✗ git submodule sync Synchronizing submodule url for 'ae' Synchronizing submodule url for 'win32' ➜ Digger git:(master) ✗ cat .gitmodules [submodule ae] path = ae url = git://github.com/CyberShadow/ae.git [submodule win32] path = win32 url = https://github.com/CS-svnmirror/dsource-bindings-win32 ➜ Digger git:(master) ✗ cat .git .git/ .gitignore .gitmodules ➜ Digger git:(master) ✗ rdmd --build-only digger digger.d(12): Error: module main is in file 'ae/utils/main.d' which cannot be read import path[0] = . import path[1] = /usr/include/dmd/phobos import path[2] = /usr/include/dmd/druntime/import Failed: [dmd, -v, -o-, digger.d, -I.] ➜ Digger git:(master) ✗ git submodule update remote: Counting objects: 8, done. remote: Compressing objects: 100% (7/7), done. remote: Total 8 (delta 5), reused 4 (delta 1) Unpacking objects: 100% (8/8), done. From git://github.com/CyberShadow/ae 217b080..66502df master - origin/master e8d867c..0b1cfc0 new-net- origin/new-net * [new branch] old-net- origin/old-net Submodule path 'ae': checked out '318ccc76669e9840f43b88e63bcfb1e461ce6d61' ➜ Digger git:(master) rdmd --build-only digger ➜ Digger git:(master) No idea why git submodule update worked
Re: Git, the D package manager
On 02/03/2015 10:02 PM, H. S. Teoh via Digitalmars-d wrote: Rather than scan the whole source tree every time, it takes the changeset as input -- either from the OS, or from some other source of information. Indeed a good idea, although according to his graphs, this only starts to matter for +1000 files.
Re: Git, the D package manager
- restructure the directory layout of my library (breaking change) That's likely solveable. Haven't seen anyone putting sources in the root dir for ages though, mostly because it contains readmes and configs. - update all projects which use this library to use Dub instead If we can solve the root Dir issue, then you can use both in parallel. - give up quick syntax checking What keeps you from calling DMD? - give up commit-granularity versioning You should be careful with breaking changes, then the granularity isn't needed. - begin maintaining JSON configuration files It's not zero configuration, but we recently pimped the init command to take dependencies. And there is going to be SDL as alternative to JSON. - begin versioning libraries by hand Semantic versioning is a good thing, because it allows sensible dependency updates. You also need library versions for your changlog and issues. - install Dub on all my computers, servers, and virtual machines We'll distribute it with DMD soon. No thanks. I could invest time in improving Dub to fix or ameliorate some of the above points, but I don't see a compelling reason to. In fact, I think we should integrate rdmd into dmd - dmd clearly already knows which source files participate in compilation, as all rdmd does is basically take dmd's output and feed it back to it. This will greatly speed up compilation, too. We could also add a lot of the rdmd workflow to dub. https://github.com/D-Programming-Language/dub/issues/103 There seems to be a general scepticism against dub and I wonder what the reasons are. A lack of good documentation and guides is clearly the main hurdle for starters, but there seems to be more, so I'm glad that you shared this.
Re: Git, the D package manager
On Tuesday, 3 February 2015 at 02:39:56 UTC, Vladimir Panteleev wrote: I might revisit Dub again once some of the fixable issues mentioned here are fixed. Another very important argument is consistency in using packages. I recently tried digger which is a really great tool, but it took me about 5 min to get it running. - make temp folder - copy URL from github clone cd digger - search build instructions README/INSTALL/wiki/main.d - rdmd --build-only digger = linker error - Wondering, if I really have time for this? - ah, need to clone all submodules - rdmd digger --help With dub you do this instead. dub fetch digger dub run digger -- --help That works in whatever folder you are, builds a stable version of the tool and even links against already installed and build dependencies.
Re: Git, the D package manager
Lot's of weird attitude in this thread BTW, instead of complaining about every single flaw we could really make use of a few helping hands. I'm often literally baffled that people don't even try to fix obviously trivial bugs. https://github.com/D-Programming-Language/dub/pull/354
Re: Git, the D package manager
On Monday, 2 February 2015 at 09:44:18 UTC, Andrej Mitrovic wrote: - Dub installs everything in ~/ (home, which on Windows is an awful location anywho). It's a pain in the ass for browsing dependencies in your editor. If it's just a submodule you can easily view it in the source tree (e.g. just open ./submodules/). It has the benefit of not reusing code and libraries across multiple projects. - By default dub emits internal stack traces. This is an insane amount of visual noise that I don't want to read. Definitely guilty of bad exception usage. - If I want to try a new version of a dependency, I have to change the damn .json package file instead of doing a simple 'git checkout ...'. What's worse, I have to wait 15-20 minutes for the latest tagged version of a dependency to finally show up on code.dlang.org. I could use add-local, but it's broken[1]. Never had a problem with add-local, but I didn't use it with sub packages yet. In fact sub-packages are overused and fairly complex. Configurations can handle most of the tasks much simpler. - Shit breaks every N releases (where N is arbitrary). It's still beta and a fast moving project, but we're stabilizing.
Re: H1 2015 Priorities and Bare-Metal Programming
Just go with __gshared. Or even better, avoid globals ;).
Re: Arrays, garbage collection
Thanks for this code, it's a lot nicer and simpler than mine. -- Andrei So, pull request for std.array and reverting the dollar thingie? Problem solved?
Re: Time for 2.067
Can we commit to having stuff done by Feb 15 for a release on Mar 1? -- Andrei Sounds good, work on regressions should start soon and we should no longer add features.
Re: Google Summer of Code - Again
On Friday, 30 January 2015 at 14:11:27 UTC, CraigDillabaugh wrote: http://en.flossmanuals.net/GSoCMentoring/managing-the-mentors/ Sounds good, count me in.
Re: Speeding up LDC with Make jobs
It seems completely unrelated to the -j flag, just related to per-file compilation. Look at the linker map file, maybe one build results in a better layout, though the effect should be marginal.
Re: dlang.org redesign -- the state of documentation and learning resources [part 2]
On Friday, 23 January 2015 at 18:37:07 UTC, Martin Drašar wrote: Dne 23.1.2015 v 19:16 Andrei Alexandrescu via Digitalmars-d napsal(a): Both are nice: http://tour.golang.org/welcome/1 http://rustbyexample.com/ Or something along the lines of https://tryhaskell.org With possible integration with D REPL. That's actually where I want to go with D REPL. Even more interesting would be user editable tutorials. As usual lacking the time for this right now.
Re: [website redesign] PR for the one with the big red menu bar
On Friday, 30 January 2015 at 20:21:01 UTC, Steven Schveighoffer wrote: Those aren't clouds, they are moons :) Phobos and Deimos to be precise.
Re: Problem with coupling shared object symbol visibility with protection
On Saturday, 31 January 2015 at 09:25:10 UTC, Benjamin Thaut
wrote:
Well, export is going to remain transitive. So the first
approach is still going to work. The only difference is going
to be that you can force export private declarations. So for
most modules it is hopefully going to be enough to put export
{ } around the public part of the module and force export
some of the needed private declarations. For a module without
templates a single export { } should be enough.
That's probably how it should behave, though an attribute
applying only to public members unless explicitly added is
unprecedented. Still seems like the right choice here, but might
require some additional compiler logic.
Re: Problem with coupling shared object symbol visibility with protection
On Tuesday, 20 January 2015 at 12:23:32 UTC, Benjamin Thaut wrote:
2) Make export an attribute. If export is no longer an
protection level but instead an attribute this issue can easily
be solved by doing.
export public void templateFunc(T)()
{
someHelperFunc();
}
export private void someHelperFunc()
{
}
Clearly the better solution.
Export and protection have something in common but are not
identical.
Re: DMD 2.066.1 is missing in the Digitalmars FTP
On Friday, 30 January 2015 at 20:47:33 UTC, Andrei Alexandrescu wrote: On 1/30/15 12:45 PM, Brad Roberts via Digitalmars-d wrote: On 1/30/2015 12:39 PM, Jacob Carlborg via Digitalmars-d wrote: On 2015-01-30 15:59, Andrei Alexandrescu wrote: That would be nice. -- Andrei I agree. I wouldn't need to screen scrape dlang.org in DVM. I'd be much more inclined to keep a file called LATEST with the version number in it than having to maintain a ton of redirects each time. (not present yet, but for example) http://downloads.dlang.org/releases/LATEST containing one line: 2.066.1 That would do the trick. That's already available by scanning the dmd tags in github. We do that in dlang.org/posix.mak: Can't use that because we tag a new version before releasing it, so for a few days services couldn't use LATEST.
Re: Time for 2.067
On Friday, 30 January 2015 at 22:06:34 UTC, Walter Bright wrote: Time to button this up and release it. Remaining regressions: https://issues.dlang.org/buglist.cgi?bug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDlist_id=192294query_format=advanced Please let's finish the GC work for 2.067, will take about 1-1.5 week.
Re: Compile time iota
On Friday, 30 January 2015 at 14:58:14 UTC, Andrei Alexandrescu wrote: I think we need to promote the best of the breed into the standard library. -- Andrei True that for anything not too subjective (XML, json, streams), but for frameworks it might be healthier to leave decisions open. And we shouldn't hurry with choosing libraries. Some real-world testing and some alternative implementations are good for natural selection.
Re: DMD 2.066.1 is missing in the Digitalmars FTP
On 01/28/2015 03:41 AM, Brad Roberts via Digitalmars-d wrote: I hope that makes you guys a little happier.. Thanks a lot, hope it's easy for you to maintain the redirects. Would it also be possible to add a LATEST version? http://downloads.dlang.org/releases/2.x/LATEST/dmd.LATEST.linux.zip
Re: DMD 2.066.1 is missing in the Digitalmars FTP
On 01/29/2015 03:58 PM, Andrei Alexandrescu wrote: Travis set the User agent this way: $ CURL_USER_AGENT=Travis-CI $(curl --version | head -n 1) Thanks! -- Andrei Yes, I added that so you can keep track of the download numbers. I'd be interested to know the travis-ci numbers, would also help to argue for download caching on travis-ci side.
Re: DMD 2.066.1 is missing in the Digitalmars FTP
On 01/28/2015 03:41 AM, Brad Roberts via Digitalmars-d wrote: I spent the time today to read up on how to use s3 website redirects, since s3 doesn't support symlinks. The only new requirement is for the http client to follow a 301 redirect, which most do. Can you please also add cache-control headers? Should be 'Cache-Control: public, max-age=31557600' http://stackoverflow.com/questions/22501465/how-to-add-cache-control-in-aws-s3 http://forum.dlang.org/post/swifmqthxwiouxkwq...@forum.dlang.org
Re: DMD 2.066.1 is missing in the Digitalmars FTP
On 12/02/2014 06:10 PM, Jacob Carlborg wrote: DMD 2.066.1 is missing in the Digitalmars FTP. The release candidates are present but the final release is missing. This breaks DVM. By the way dmd.2.066.1.linux.zip is still missing :(. http://ftp.digitalmars.com/dmd.2.066.1.linux.zip http://downloads.dlang.org/releases/2.x/2.066.1/
Re: DMD 2.066.1 is missing in the Digitalmars FTP
On 12/02/2014 06:10 PM, Jacob Carlborg wrote: DMD 2.066.1 is missing in the Digitalmars FTP. The release candidates are present but the final release is missing. This breaks DVM. By the way dmd.2.066.1.linux.zip is still missing :(. http://ftp.digitalmars.com/dmd.2.066.1.linux.zip http://downloads.dlang.org/releases/2.x/2.066.1/
Re: Problem with coupling shared object symbol visibility with protection
On Thursday, 29 January 2015 at 13:24:36 UTC, Benjamin Thaut wrote: module c: SomeTemplate!uint var3; // will this use instaction from b? Or instanciate itself? That's the first instantiation with uint. If you mean float, then it will instatiate the template when compiled individually and use b's instantiation when b and c are compiled together.
Re: Compile time iota
On 01/22/2015 10:21 PM, Andrei Alexandrescu wrote: While working on the new site menus I was copying std modules by hand - and boy, there's just so much work to be done. Streams, json, encoding, mmfile, outbuffer, signals, socket, socketstream, xml, zip - all that stuff, maybe a third of the standard library packages, are /known/ to be in need of a good revamp (ranging from better documenting to refactoring to improving to completely rewriting) yet recently a lot of work has been spent on renaming, splitting, ... - shuffling the rubble in the garden, especially parts that are already good: container, algorithm, range, typecons. Moreover, there's a ton of brand new work to be done! We don't have standard decent wrappers for libevent or libarchive, networking protocols, web servers, databases, and just a ton of other things. Leave the better part of this to freestanding libraries, they prosper much better. 14 database drivers http://code.dlang.org/?sort=updatedcategory=library.database 24 networking libraries http://code.dlang.org/?sort=updatedcategory=library.network 5 JSON libraries http://code.dlang.org/search?q=json A lot of them are quite good and it has become really simple to write a nice library that is well tested and documented. I try to maintain this library as state-of-the-art D project with dub, ddox, travis-ci and doveralls integration. https://github.com/MartinNowak/bloom
Re: dll-linux page not in the menu on dlang.org?
On 01/24/2015 12:38 PM, Benjamin Thaut wrote: Why do we need a high-level wrapper? Because it means the support if finished and stable, unlike the Window DLL documentation which tells people what internal runtime functions to use to make an incomplete DLL support work a little. (P.S. didn't you get my mails?) Just been busy.
Re: Google Summer of Code - Again
On 01/30/2015 05:32 AM, Craig Dillabaugh wrote: It seems like its been too long since I posted asking for GSOC help. I was just about to ask how things are going :). Thanks a lot, the page looks much better than in recent years. http://wiki.dlang.org/GSOC_2015_Ideas 1) I need a volunteer for 'backup' administrator. This is a requirement, so I really need someone to volunteer for this position, which with a little luck will require exactly 0 work, and will bring you great honour and prestige. What administration tasks? I might be able to do this. 2) DigitalMars is listed as the mentoring orgnaization. Should we register rather as dlang.org? There has been some discussion about a D foundation a few month ago. As far as I remember people where shying away from the legal complications, so that won't change any time soon.
Re: D garbage collector and real-time systems
On 01/28/2015 09:12 AM, Mike wrote: Note that D has 3 built-in types: exceptions, dynamic arrays, and associative arrays, that may be difficult to use without the GC: http://dlang.org/builtin.html. 4 actually, if you count delegate closures. http://dlang.org/function.html#closures
Re: I'll be presenting at NWCPP on Jan 21 at Microsoft
On 01/23/2015 06:54 AM, Walter Bright wrote: On 1/22/2015 12:52 PM, Gary Willoughby wrote: Me too, is there any video available? https://www.youtube.com/watch?v=IkwaV6k6BmM I can't bear to watch it, you'll have to do it for me! Great topic, I wasn't aware of how much C++ we support by now. Can we get a summary of all the improvements in 2.066/2.067 for the changelog? https://github.com/D-Programming-Language/dlang.org/blob/master/changelog.dd Also it would be nice to fill the documentation with a few more details and examples from your talk. http://dlang.org/cpp_interface.html
Re: dll-linux page not in the menu on dlang.org?
On 01/24/2015 11:47 AM, Benjamin Thaut wrote: I tried really hard but I'm not able to find a link in the menu that leads to the following page: http://dlang.org/dll-linux.html Is that intentional? In my opinion this is a pretty central topic which should appear in the sub-menu D Reference. Kind Regards Benjamin Thaut Oh, that needs some overhaul, but I don't think we should release it before we have the high-level wrapper. https://github.com/D-Programming-Language/druntime/pull/617
Re: What happened to dmd usage pages?
On 01/12/2015 09:55 PM, Steven Schveighoffer wrote: e.g. http://dlang.org/dmd-osx.html I can get to this page by searching google, but the menu on the left has eliminated it. See here: http://dlang.org/download.html Why? Accidentally, because of too much macro magic. https://github.com/D-Programming-Language/dlang.org/pull/764
Re: What is the D plan's to become a used language?
On Friday, 19 December 2014 at 16:45:40 UTC, Ola Fosheim Grøstad wrote: Yes, but it would be easy to define some focused goals for each release and refuse to touch stuff that belongs to a later release. E.g. http://wiki.dlang.org/Agenda
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 00:51:25 UTC, Walter Bright wrote: On 1/11/2015 5:06 AM, Dicebot wrote: What is your opinion of approach advertised by various functional languages and now also Rust? Where you return error code packed with actual data and can't access data without visiting error code too, compiler simply won't allow it. It's a great question. I have a lot of experience with error codes, and with exceptions. I have zero with the packed scheme, though that doesn't stop me from having an opinion :-) Perhaps I misunderstand, but given A calls B calls C, A = B = C The general solution in functional programming is error chaining. An example, C is a function that reads in lines of a program and B is a function that takes all those lines and counts words. C will either return an error or lines and B will either immediately return that error to A or convert the lines to word counts. This works especially well with function chaining, because you can hide the error propagation in a generic chaining method (called map). http://danielwestheide.com/blog/2012/12/26/the-neophytes-guide-to-scala-part-6-error-handling-with-try.html
Re: Is anyone working on a D source code formatting tool?
On Monday, 12 January 2015 at 01:53:20 UTC, Brian Schott wrote: On Saturday, 10 January 2015 at 20:18:03 UTC, Walter Bright wrote: Has someone made a dfmt, like http://gofmt.com/ ? https://github.com/Hackerpilot/dfmt The above is the work of one afternoon and not well tested. Thanks Brian, looks promising.
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 21:11:44 UTC, Walter Bright wrote: On 1/12/2015 6:57 AM, Martin Nowak wrote: The general solution in functional programming is error chaining. An example, C is a function that reads in lines of a program and B is a function that takes all those lines and counts words. C will either return an error or lines and B will either immediately return that error to A or convert the lines to word counts. This works especially well with function chaining, because you can hide the error propagation in a generic chaining method (called map). http://danielwestheide.com/blog/2012/12/26/the-neophytes-guide-to-scala-part-6-error-handling-with-try.html Yes, it still appears to be just a wrapper around returning two values, and that has to be done for everything. Yes, you wrap the return values, but it doesn't require to deal with errors in B. There's another downside to returning two values - extra code is generated, and it consumes another register. It allocates very scarce resources to rare cases - not a recipe for high performance. To defend that argument we'd first have to fix our own codegen. https://issues.dlang.org/show_bug.cgi?id=12442 It doesn't really consume the register, because the error value is only needed directly after the call for a possible early return. But of course returning tuples can be less efficient. OT!! Reminds me of Manu's request for more efficient register return. www.digitalmars.com/d/archives/digitalmars/D/Multiple_return_values..._160353.html
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 21:41:48 UTC, Andrei Alexandrescu wrote: I can't believe I agree with everything bearophile just said :o). -- Andrei But we knew that already. channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C stackoverflow.com/questions/14923346/how-would-you-use-alexandrescus-expectedt-with-void-functions
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 22:17:57 UTC, Walter Bright wrote: To defend that argument we'd first have to fix our own codegen. https://issues.dlang.org/show_bug.cgi?id=12442 That issue has nothing to do with exception handling vs error codes. If you start to discuss register allocation than the actual cost of zero-cost EH has quite a lot to do with it.
Re: Why exceptions for error handling is so important
On Monday, 12 January 2015 at 22:54:08 UTC, Dicebot wrote: Which is equivalent to don't use exceptions on servers :) Yes, I know, this is why any alternative approach is worth interest. I think error handling chains like Maybe!(Result) or Either!(Error, Result) could be nicely implemented in a library. I thought about using something like that for error handling in the dub-registey.
Re: CTFE pow()
https://issues.dlang.org/show_bug.cgi?id=3749
Re: CTFE pow()
On Thursday, 1 January 2015 at 16:56:24 UTC, Manu via Digitalmars-d wrote: Does anyone know how to fix this? Can we please do so? It's been a problem for like 5 years it seems. It's a bit insane that we can't resolve any non-linear functions at compile time. Oh, we got yl2x recently [1]. So, your code here - https://github.com/D-Programming-Language/dmd/blob/6fe4b48891ff5d7d171f718b2a4af6ddbb6714ec/src/builtin.c#L183 [1]: https://github.com/D-Programming-Language/dmd/pull/4012
Re: ddox question
On 01/11/2015 06:28 PM, Andrei Alexandrescu wrote: I don't think the CSS would be enough. The title is Module xxx.yyy. I only need to format xxx.yyy in code font. How do I do that? -- Andrei Here is the right place. https://github.com/D-Programming-Language/dlang.org/blame/dbcdbe39cdb0c0eb938c6e0a70198af72dd7b784/dpl-docs/views/layout.dt#L117
Re: Is it possible to collect object usage information during compilation?
On 01/10/2015 01:36 PM, Martin Nowak wrote: The idea isn't bad, but the performance will suck. This is generally known as N+1 query, only that this is even worse, as each field is queried individually. Here is a sketch for an optimal solution. I'm actually eagerly waiting that someone finally implements it. http://dpaste.dzfl.pl/cd375ac594cf I also added a where clause, with a very simple expression template capture. http://dpaste.dzfl.pl/cd375ac594cf#line-140
Re: NaCl/Emscripten
On 01/09/2015 10:28 AM, Manu via Digitalmars-d wrote: I'm looking at another potential opportunity to get D into the office, but the target's for this particular project are NaCL and/or Emscripten. I was gonna start hacking around to see what the limitations are with Emscripten on D code tonight. Has anyone done any serious investigation here? NaCl is a more useful target, but I think that will rely on a special build of LDC... has there been discussion about that before? Can any of the LDC guys chime in on the possibility? It would require some druntime work for the libc differences (newlib vs. glibc). That's similar to the ongoing Android/X86 work https://github.com/D-Programming-Language/druntime/pull/1069.
Re: Is it possible to collect object usage information during compilation?
On 01/10/2015 11:20 AM, Jacob Carlborg wrote:
On 2015-01-10 07:46, DaveG wrote:
I might be crazy, but it seems like the compiler has all the information
necessary to figure this out and it would make user code simpler, less
error prone, and more efficient. So does anybody have any idea on how to
actually achieve this?
I'm not exactly sure if this is what you want but you can implement the
opDispatch [1] method in a class or struct. This method will be called
if no other method exists with the same name. There's also something
called alias this [2] that allows you to do something similar.
class Foo
{
void foo () {}
void opDispatch (string name)() {}
}
auto f = new Foo;
f.foo(); // will call foo
f.bar(); // will be lowered to f.opDispatch!(bar)();
If you're implementing an ORM I would recommend executing queries
lazily. You can do something like this:
class Person : ORM.Base
{
String name;
Int age;
// this method returns a range/proxy that implements the range api [3]
static ORM.Range!(Person) all () {}
}
String would look something like this:
struct String
{
alias get this;
// this method will fetch the data from the database
private string get ();
}
Using the interface would look something like this:
auto p = Person.all(); // no database query has been performed yet
// the range interface makes it possible to use a foreach
// when starting the foreach loop is when the first query will happen
foreach (e ; p)
{
// this call will trigger a call to the get method in String
// via the alias this
string name = e.name;
writeln(name);
}
The idea isn't bad, but the performance will suck. This is generally
known as N+1 query, only that this is even worse, as each field is
queried individually.
Here is a sketch for an optimal solution. I'm actually eagerly waiting
that someone finally implements it.
http://dpaste.dzfl.pl/cd375ac594cf
Re: Is it possible to collect object usage information during compilation?
On 01/10/2015 01:52 PM, Jacob Carlborg wrote: On 2015-01-10 13:36, Martin Nowak wrote: The idea isn't bad, but the performance will suck. This is generally known as N+1 query, only that this is even worse, as each field is queried individually. Since the all method was called I would assume all rows in the person table are fetched in one single query. Although I don't know if that will work if not the whole row should be loaded. For row or document oriented databases you want to query all fields in parallel. For columnar stores it might be possible to efficiently query specific fields for many documents. Here is a sketch for an optimal solution. I'm actually eagerly waiting that someone finally implements it. http://dpaste.dzfl.pl/cd375ac594cf How would you handled fetching multiple rows and a foreach loop, i.e. my example? I'd simple produce multiple rows, the principle remains the same. Perhaps a detail but using a wrapped type instead of the raw types in Person you could handle things like null in the database. The example already uses Variant.
Re: Ready to make page-per-item ddocs the default?
On Wednesday, 7 January 2015 at 08:46:41 UTC, Vladimir Panteleev wrote: * I still have reservations about using Disqus. I'm quite happy with the self hosted isso comments on my blog. https://code.dawg.eu/reducing-vibed-turnaround-time-part-2-less-compiling.html#isso-thread
Re: Ready to make page-per-item ddocs the default?
On Thursday, 8 January 2015 at 12:18:37 UTC, Steven Schveighoffer wrote: One thing that may be misleading about this -- our headers don't include *everything* from C-land. What's missing? They should just match their C counterparts.
Re: Ready to make page-per-item ddocs the default?
On 01/09/2015 07:35 PM, Andrei Alexandrescu wrote: Maybe Calypso could be used for that? -- Andrei What's calypso, can't find anything.
