Re: Better docs for D (WIP)
FYI, even now, I hesitate to change links in my Phobos fork because I kinda want to remain ddoc compatible... and I can never remember what macro it is. And I've been kinda deep in this the whole last week. Anyway, let's get into this: On Sunday, 3 January 2016 at 23:16:30 UTC, Andrei Alexandrescu wrote: Do the projected advantages of Adam's project do not include ease of contribution? If so, how? 1) a massively simplified build. Indeed, I'll make a web form so you don't even have to have dmd installed to make some docs. This got posted today: https://issues.dlang.org/show_bug.cgi?id=15516#c2 Two people whose names I recognize who have been with D for a long time didn't know how to add a page to the website. And what they did figure out was a multi step process. My system already runs a single file or an entire directory and just works. It will never forget a file because you didn't add it to mak/DOCS of win32.mak or anything else. I'll also make a web form to upload new pages and probably entire projects for automatic processing too. 2) My linking system already works better than ddoc allows. You can reference with a single macro: $(REF some.name). I also keep MREF, XREF, and a few others for legacy phobos+ddoc compatibility, but the user doesn't have to know a hundred obscure macros. (There's about a half-dozen simple ones instead, plus a few thin wrappers over HTML which I might kill but might not since they don't really bother me.) Combined with the ease of adding all new files, contributors can just link new articles they write to go in depth without worrying about process. 3) I'm also going to make a dynamic webpage once I declare this beta where viewers will be given random pages and asked to eyeball it for me. If they flag it as buggy - with a single click on the page, no bugzilla signups - it'll contact me and I'll work on the bug. If they want to contribute to content, I can pull up the existing comment source code and present it right there, again likely emailed to me for integration, or the source location can be opened in Phobos for a traditional pull request. This will encourage crowd sourcing doc bug fixes. 4) I'll never complain about spaces vs tabs, line length, or any other trivial nonsense. If I don't like that stuff, I'll just fix it myself instead of letting the PR wither and die while letting the contributor feel undervalued.
Re: Better docs for D (WIP)
On Sunday, 3 January 2016 at 23:16:30 UTC, Andrei Alexandrescu wrote: A few follow-up questions, all serious: Sorry, I just forgot an important thing. Somewhere in the beginning of this topic, you had advised Adam to put his efforts into another thing, right? So imagine this with: D vs C++ where someone comes to you and says: Andrei why are you doing this new language, instead, go back to C++ and put these ideas there. You know many see D as language that has the power/speed C++ but is simpler, right? Maybe the same thing is happening here. I think you should reflect about this. JohnCK.
Re: Better docs for D (WIP)
On Sunday, 3 January 2016 at 23:16:30 UTC, Andrei Alexandrescu wrote: A few follow-up questions, all serious: Fair enough... but most of the points you're asking they already have been discussed all over the forums, and some in this topic, like those exposed by Adam. Like I said currently I have free time and sometimes when I find small problems I just say to myself, look I could help on this... but then I remember all the friction. And again I'm just talking about small things like fixing wrong URLs or add more examples to the functions and so on but the current process isn't easy. You may think this is another whining but you know that while DDoc's is a great tool for a problem with docs that you had in the past, maybe need to be re-evaluated now. I'm not saying to stop using tomorrow, but finding ways to make things easy, that anyone could help easily with less friction. JohnCK.
Re: Better docs for D (WIP)
On Saturday, 2 January 2016 at 21:06:19 UTC, Adam D. Ruppe wrote: * cross-linking, including inherited members I got this working in simple cases... which happens to include Phobos' std.socket! http://dpldocs.info/experimental-docs-2/std.socket.UdpSocket.html I did a major refactoring of the code today to enable moving forward past the block I hit over the weekend. The code is still bad... but not embarrassingly so anymore, and it makes it a LOT easier to work with. I did step backward a few steps though (the var FIXME in the output is the result of that), but forward many more. ddox makes an attempt at inheritance linking, but I'm trying to go further. If I'm successful in my dream, it will list overridden methods in the docs nicely too. But that's still a ways away. First, I need to re-add the features I dropped in the refactoring (compare the above with this: http://dpldocs.info/experimental-docs/std.socket.UdpSocket.html )
Re: Writing a scalable chat room service in D
Am Mon, 04 Jan 2016 17:15:36 + schrieb Bubbasaur : > On Monday, 4 January 2016 at 17:02:01 UTC, Sönke Ludwig wrote: > > ...Maybe it's something specific to your OS/Chrome version? > > Well, I tried again on the same machine but using Firefox and it > worked, then I tried on my Tablet (Android/KitKat) using both > Chrome and Native Browser and worked too. > > So I think It's something going wrong with Chrome here! > > Bubba. IIRC the letsencrypt people said in their 32c3 talk* that there might still be some issues with chrome. (chrome is probably caching something it shouldn't cache. Try clearing all caches) [*] https://media.ccc.de/v/32c3-7528-let_s_encrypt_--_what_launching_a_free_ca_looks_like
Re: Writing a scalable chat room service in D
Am 04.01.2016 um 21:21 schrieb Sönke Ludwig: Am 04.01.2016 um 20:39 schrieb Meta: On Monday, 4 January 2016 at 10:19:52 UTC, Sönke Ludwig wrote: Finally published the article that I had prepared in autumn last year. It gives an overview of the basic functionality needed to implement a typical web application using vibe.d. The example uses Redis as a data store - using other storage solutions may be a good topic for a follow-up article. https://vibed.org/blog/posts/a-scalable-chat-room-service-in-d Reddit: https://www.reddit.com/r/programming/comments/3ze948/writing_a_scalable_chat_room_service_in_d/ This article seems what a lot of people on Hacker News would go for. Do you plan to submit it there as well? If it fits, I definitely wouldn't mind that. I just don't have an account there, so if someone who does could post it that'd be nice. Otherwise I can create one, too, of course. Has actually already been posted a few hours ago (at pos. 302. currently, though).
Re: Writing a scalable chat room service in D
Am 04.01.2016 um 20:39 schrieb Meta: On Monday, 4 January 2016 at 10:19:52 UTC, Sönke Ludwig wrote: Finally published the article that I had prepared in autumn last year. It gives an overview of the basic functionality needed to implement a typical web application using vibe.d. The example uses Redis as a data store - using other storage solutions may be a good topic for a follow-up article. https://vibed.org/blog/posts/a-scalable-chat-room-service-in-d Reddit: https://www.reddit.com/r/programming/comments/3ze948/writing_a_scalable_chat_room_service_in_d/ This article seems what a lot of people on Hacker News would go for. Do you plan to submit it there as well? If it fits, I definitely wouldn't mind that. I just don't have an account there, so if someone who does could post it that'd be nice. Otherwise I can create one, too, of course.
Re: Hash Tables in D
On 01/04/2016 09:06 AM, Bastiaan Veelo wrote: > > This would be a bug (segfault on my machine): > >> foreach (key; aa.byKey) >> aa.remove(key); > > Note that, in this example, there is no need to remove every element > separately, you can also just do Sorry my mistake, I never use aa.keys (instead of aa.byKey) b/c it allocates. So it's still sort of a bug to recommend people allocating an array ;).
Re: Writing a scalable chat room service in D
On Monday, 4 January 2016 at 10:19:52 UTC, Sönke Ludwig wrote: Finally published the article that I had prepared in autumn last year. It gives an overview of the basic functionality needed to implement a typical web application using vibe.d. The example uses Redis as a data store - using other storage solutions may be a good topic for a follow-up article. https://vibed.org/blog/posts/a-scalable-chat-room-service-in-d Reddit: https://www.reddit.com/r/programming/comments/3ze948/writing_a_scalable_chat_room_service_in_d/ This article seems what a lot of people on Hacker News would go for. Do you plan to submit it there as well?
Re: Beta D 2.070.0-b1
On 01/04/2016 04:29 PM, Joakim Brännström wrote: > Regression? > Found when compiling dub-package scriptlike (struct Path). Thanks for reporting. It's not acceptable to break code like that without a proper deprecation cycle. https://issues.dlang.org/show_bug.cgi?id=15515
Re: Better watch out! D runs on watchOS!
Joakim writes: > On Monday, 4 January 2016 at 09:26:39 UTC, Dan Olson wrote: >> Joakim writes: >> >>> On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote: [...] >>> >>> Sounds good, submit a PR and let's get it in. >> >> Was planning to get that PR going then got side tracked by a more >> difficult ARM exeption unwinding bug. It happens in std.random >> unittest at LDC -O2 or higher. Does this sound familiar Joakim? > > Yep, except tests were failing in three unittest blocks with -O1 too, > but I never looked into exactly why: > > https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3139 I must add, I don't think the optimizer or inliner are the cause of this unwinding bug. They are just good at making big functions. I think I could create the same bug at -O0.
Re: Writing a scalable chat room service in D
Am 04.01.2016 um 18:33 schrieb Jason Jeffory: bad links in tutorial: https://vibed.org/blog/posts/a-scalable-chat-room-service-in-d/vibe-web registerWebInterface is the entry point to vibe.d's high-level web application framework. It takes a class instance and registers each of its public methods as a route in the URLRouter. By default, the method names are mapped to Thanks, fixed now. I wonder if you could add a feature to vibe.d that checks for links that are out-dated? Maybe, ultimate, attempt to search for "feasible" substitutions instead of a 404 and present them to the user? Everyone hates 404's, right? That would be difficult to do in the general case. Here, the mistake was in the Markdown syntax ([application framework](vibe-web) instead of [application framework][vibe-web]). Something to detect this could indeed be nicely built into the blog engine, but as a generic vibe.d feature it would be rather difficult to integrate in a nice way.
Re: Better watch out! D runs on watchOS!
Joakim writes:
> On Monday, 4 January 2016 at 09:26:39 UTC, Dan Olson wrote:
>> Joakim writes:
>
>> The bug is a bad stack pointer which blows up when the last unittest
>> returns. This unittest has all the right conditions to generate
>> stack adjustments around some of the function calls that throw
>> exceptions. The exception landing pad does not fixup the stack
>> adjustment, thus a stack leak on each caught exception. The
>> unittest function epilog restores the stack by adding a fixed offset
>> to match the prolog, so the stack pointer stays wrong when the saved
>> registers and return address are popped.
>>
>> Really looks like LLVM is not doing the right thing with landing
>> pads. In the meantime I patched LLVM to generate epilog that always
>> uses frame pointer to restore the stack pointer. WatchOS requires a
>> frame pointer, so this isn't too bad. Now all unittests pass at -O3
>> for watchOS.
>
> Could be the same issue for me, not sure. If you put your fix online,
> I can try it and see.
It is this commit based on a 2 week old LLVM 3.8 trunk:
https://github.com/smolt/llvm/commit/91a4420615c6ec83b227b63d36054f12ccffb00f
A small change but took me a long time in debugger on an Apple Watch to
figure out. Something the x86 simulator can't show. It is tailored to
watchOS which uses thumb2 instructions. watchOS always has a frame,
hasFP() is always true. You will want to add Android to the hasFP() or
disable frame pointer elimination some other way. I noticed that
-disable-fp-elim for LDC with LLVM 3.7 and above is broken so can't use
that.
The pattern to look for if you have a suspect is this:
A function that throws an exception is codegened with stack adjustment
surrounding the call:
sub sp, #16
str r1, [sp]
mov r1, r2
movsr0, #66
movwr2, #2424
blx
__D3std9exception25__T7bailOutHTC9ExceptionZ7bailOutFNaNfAyakxAaZv
add sp, #16<--- This adjustment is missed on exception
Epilog without hack (llvm 3.8 git 0838b1f Add iOS TLS support for WatchOS)
i ne
addne.w sp, sp, #9984 <-- stack adjust matches prolog, but stack
is off by 16 bytes if
above throws
addne sp, #48
popne.w {r8, r10, r11}
popne {r4, r5, r6, r7, pc}
Epilog with hack (commit 91a4420)
i ne
subne.w r4, r7, #24 <-- stack set from frame pointer (r7)
movne sp, r4
popne.w {r8, r10, r11}
popne {r4, r5, r6, r7, pc}
--
Dan
Re: Writing a scalable chat room service in D
bad links in tutorial: https://vibed.org/blog/posts/a-scalable-chat-room-service-in-d/vibe-web registerWebInterface is the entry point to vibe.d's high-level web application framework. It takes a class instance and registers each of its public methods as a route in the URLRouter. By default, the method names are mapped to I wonder if you could add a feature to vibe.d that checks for links that are out-dated? Maybe, ultimate, attempt to search for "feasible" substitutions instead of a 404 and present them to the user? Everyone hates 404's, right?
Re: Writing a scalable chat room service in D
Am 04.01.2016 um 16:20 schrieb Charles: On Monday, 4 January 2016 at 10:19:52 UTC, Sönke Ludwig wrote: Finally published the article that I had prepared in autumn last year. It gives an overview of the basic functionality needed to implement a typical web application using vibe.d. The example uses Redis as a data store - using other storage solutions may be a good topic for a follow-up article. https://vibed.org/blog/posts/a-scalable-chat-room-service-in-d Reddit: https://www.reddit.com/r/programming/comments/3ze948/writing_a_scalable_chat_room_service_in_d/ Wish I knew this was being worked on. I had something similar over at: http://wiki.dlang.org/User:Csmith1991/Vibe.d_Documentation/websocket Oh, that indeed looks painfully similar. In any case, I'll link to it from the tutorials section. It uses the lower level APIs, so it's still interesting as an alternative implementation approach.
Re: Writing a scalable chat room service in D
On Monday, 4 January 2016 at 17:02:01 UTC, Sönke Ludwig wrote: ...Maybe it's something specific to your OS/Chrome version? Well, I tried again on the same machine but using Firefox and it worked, then I tried on my Tablet (Android/KitKat) using both Chrome and Native Browser and worked too. So I think It's something going wrong with Chrome here! Bubba.
Re: Writing a scalable chat room service in D
Am 04.01.2016 um 16:01 schrieb bachmeier: On Monday, 4 January 2016 at 10:19:52 UTC, Sönke Ludwig wrote: Finally published the article that I had prepared in autumn last year. It gives an overview of the basic functionality needed to implement a typical web application using vibe.d. The example uses Redis as a data store - using other storage solutions may be a good topic for a follow-up article. https://vibed.org/blog/posts/a-scalable-chat-room-service-in-d Reddit: https://www.reddit.com/r/programming/comments/3ze948/writing_a_scalable_chat_room_service_in_d/ This is nice work. You've done a good job of showing the power of vibe.d. Something that comes to mind is that there is a lot of demand for self-hosted chat servers. Is there a possibility to make this into an example that works out of the box? By that, I mean someone could install vibe.d on a DigitalOcean server, type "vibe chat start" at the command line, and have a running chat service. That would lead to a lot of vibe.d installs, and then when they want to change something, they could jump into your tutorial and see how easy it is to do. To my knowledge, there is nothing like this available. That would certainly work, I've uploaded each step of the tutorial to GitHub [1]. Something like "git clone https://github.com/rejectedsoftware/webchat-tutorial.git && dub --root=webchat-tutorial" should do it. However, there are a lot of details missing that would be desirable for a real-world application, such as adding time stamps, restricting history length, making a nicer UI and some kind of authentication or nickname stealing prevention. [1]: https://github.com/rejectedsoftware/webchat-tutorial/tree/master/tutorial
Re: Writing a scalable chat room service in D
Am 04.01.2016 um 17:33 schrieb Bubbasaur: On Monday, 4 January 2016 at 14:35:18 UTC, Sönke Ludwig wrote: Which browser did you use? It's a Let's Encrypt certificate, maybe that still has issues. "Chrome" - Like I said above "Chrome warns...". :) Oh sorry, missed that. However, my tests with Chrome on Windows and Chromium on Linux were both successful. Maybe it's something specific to your OS/Chrome version? I do get a certificate validation error on my Blackberry browser, though. It seems that it doesn't trust the IdenTrust root certificate (DST Root CA X3). Here is more info about the warning: " vibed.org normally uses encryption to protect your information. When Chrome tried to connect to vibed.org this time, the website sent back unusual and incorrect credentials. Either an attacker is trying to pretend to be vibed.org, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Chrome stopped the connection before any data was exchanged. You cannot visit vibed.org right now because the website sent scrambled credentials that Chrome cannot process. Network errors and attacks are usually temporary, so this page will probably work later. " Bubba.
Re: Writing a scalable chat room service in D
On Monday, 4 January 2016 at 14:35:18 UTC, Sönke Ludwig wrote: Which browser did you use? It's a Let's Encrypt certificate, maybe that still has issues. "Chrome" - Like I said above "Chrome warns...". :) Here is more info about the warning: " vibed.org normally uses encryption to protect your information. When Chrome tried to connect to vibed.org this time, the website sent back unusual and incorrect credentials. Either an attacker is trying to pretend to be vibed.org, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Chrome stopped the connection before any data was exchanged. You cannot visit vibed.org right now because the website sent scrambled credentials that Chrome cannot process. Network errors and attacks are usually temporary, so this page will probably work later. " Bubba.
Re: Beta D 2.070.0-b1
On Sunday, 3 January 2016 at 19:24:57 UTC, Martin Nowak wrote:
First beta for the 2.070.0 release.
Please report any bugs at https://issues.dlang.org
-Martin
Regression?
Found when compiling dub-package scriptlike (struct Path).
#!/usr/bin/env rdmd
struct S {
this(string r = ".") {
}
}
void main(string[] args) {
S s;
}
./foo.d(9): Error: variable foo.main.s default construction is
disabled for type S
Failed: ["dmd", "-v", "-o-", "./foo.d", "-I."]
It works with dmd 2.069.2.
I think this has been discussed and is intentional.
I would suggest clearly mentioning it in the changelog.
// Joakim
Re: Writing a scalable chat room service in D
On Monday, 4 January 2016 at 10:19:52 UTC, Sönke Ludwig wrote: Finally published the article that I had prepared in autumn last year. It gives an overview of the basic functionality needed to implement a typical web application using vibe.d. The example uses Redis as a data store - using other storage solutions may be a good topic for a follow-up article. https://vibed.org/blog/posts/a-scalable-chat-room-service-in-d Reddit: https://www.reddit.com/r/programming/comments/3ze948/writing_a_scalable_chat_room_service_in_d/ Wish I knew this was being worked on. I had something similar over at: http://wiki.dlang.org/User:Csmith1991/Vibe.d_Documentation/websocket
Re: Using D and std.ndslice as a Numpy Replacement
On Monday, 4 January 2016 at 02:01:05 UTC, Ilya wrote: Please add links to 1. Mir: http://code.dlang.org/packages/mir 2. Documentation: http://dlang.org/phobos-prerelease/std_experimental_ndslice.html 3. DlangScience example Thanks! -- Ilya Updated. I also changed the example slightly from the DlangScience example by increasing the array size because some people on HN were complaining that the size of the data wasn't large enough for the benchmark to be meaningful.
Re: Writing a scalable chat room service in D
On Monday, 4 January 2016 at 10:19:52 UTC, Sönke Ludwig wrote: Finally published the article that I had prepared in autumn last year. It gives an overview of the basic functionality needed to implement a typical web application using vibe.d. The example uses Redis as a data store - using other storage solutions may be a good topic for a follow-up article. https://vibed.org/blog/posts/a-scalable-chat-room-service-in-d Reddit: https://www.reddit.com/r/programming/comments/3ze948/writing_a_scalable_chat_room_service_in_d/ This is nice work. You've done a good job of showing the power of vibe.d. Something that comes to mind is that there is a lot of demand for self-hosted chat servers. Is there a possibility to make this into an example that works out of the box? By that, I mean someone could install vibe.d on a DigitalOcean server, type "vibe chat start" at the command line, and have a running chat service. That would lead to a lot of vibe.d installs, and then when they want to change something, they could jump into your tutorial and see how easy it is to do. To my knowledge, there is nothing like this available.
Re: Writing a scalable chat room service in D
Am 04.01.2016 um 15:05 schrieb Bubbasaur: On Monday, 4 January 2016 at 10:19:52 UTC, Sönke Ludwig wrote: Finally published the article that I had prepared in autumn last year... Neat but just one thing, when I click in the link on the Reddit, Chrome warns: " Your connection is not private Attackers might be trying to steal your information from vibed.org (for example, passwords, messages, or credit cards). NET::ERR_CERT_INVALID " So to proceed I had to take out the "s" from "http://"; You should look over this, because some users maybe be afraid to proceed. Bubba. Which browser did you use? It's a Let's Encrypt certificate, maybe that still has issues.
Re: Writing a scalable chat room service in D
On Monday, 4 January 2016 at 10:19:52 UTC, Sönke Ludwig wrote: Finally published the article that I had prepared in autumn last year... Neat but just one thing, when I click in the link on the Reddit, Chrome warns: " Your connection is not private Attackers might be trying to steal your information from vibed.org (for example, passwords, messages, or credit cards). NET::ERR_CERT_INVALID " So to proceed I had to take out the "s" from "http://"; You should look over this, because some users maybe be afraid to proceed. Bubba.
Re: Writing a scalable chat room service in D
Am 04.01.2016 um 12:15 schrieb Saurabh Das: On Monday, 4 January 2016 at 10:19:52 UTC, Sönke Ludwig wrote: Finally published the article that I had prepared in autumn last year. It gives an overview of the basic functionality needed to implement a typical web application using vibe.d. The example uses Redis as a data store - using other storage solutions may be a good topic for a follow-up article. https://vibed.org/blog/posts/a-scalable-chat-room-service-in-d Reddit: https://www.reddit.com/r/programming/comments/3ze948/writing_a_scalable_chat_room_service_in_d/ Love the new (light) look of vibed.org! :) Thanks! I felt that it was time to change it to something that better reflects the goals of the framework (fast, simple etc.). Still requires some tweaking for mobile phones and large screens, but it will get there.
Re: DLanguage IntelliJ plugin released
On Sun, 2016-01-03 at 23:46 +, Kingsley via Digitalmars-d-announce wrote: > […] > I'm still on IntelliJ 14 so haven't tried it with 15 personally - > but it should be fine. IT should work fine on windows as well - > although I'm an OSX user so have only ever tested it on OSX - > please raise any windows specific issues at the github project > https://github.com/kingsleyh/DLanguage/issues > > At the moment I've restricted the plugin to Intellij - so it > won't work on other jetbrains products - but It should not be > hard to get it working on CLion. I have just upgraded to IntelliJ IDEA 16 so I'll give it a try. All my JVM-language projects, I now do a Gradle build specification for and then let IntelliJ IDEA build a project based on that. CLion does the same with CMake. Given we can build D projects with CMake and IntelliJ IDEA plugins can (with a bit of fiddling) be used in CLion, I will try with CLion 1.5. I think D should focus on CLion not on IntelliJ IDEA. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Better watch out! D runs on watchOS!
On Monday, 4 January 2016 at 09:26:39 UTC, Dan Olson wrote: Joakim writes: On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote: [...] Sounds good, submit a PR and let's get it in. Was planning to get that PR going then got side tracked by a more difficult ARM exeption unwinding bug. It happens in std.random unittest at LDC -O2 or higher. Does this sound familiar Joakim? Yep, except tests were failing in three unittest blocks with -O1 too, but I never looked into exactly why: https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3139 The bug is a bad stack pointer which blows up when the last unittest returns. This unittest has all the right conditions to generate stack adjustments around some of the function calls that throw exceptions. The exception landing pad does not fixup the stack adjustment, thus a stack leak on each caught exception. The unittest function epilog restores the stack by adding a fixed offset to match the prolog, so the stack pointer stays wrong when the saved registers and return address are popped. Really looks like LLVM is not doing the right thing with landing pads. In the meantime I patched LLVM to generate epilog that always uses frame pointer to restore the stack pointer. WatchOS requires a frame pointer, so this isn't too bad. Now all unittests pass at -O3 for watchOS. Could be the same issue for me, not sure. If you put your fix online, I can try it and see. I am guessing iOS is not effected since it uses SjLj to restore the stack after an exception is thrown. I'll have to pursue this later. My mind is freed up for the original PR. That one is much simpler, let's get it in.
Re: Writing a scalable chat room service in D
On Monday, 4 January 2016 at 10:19:52 UTC, Sönke Ludwig wrote: Finally published the article that I had prepared in autumn last year. It gives an overview of the basic functionality needed to implement a typical web application using vibe.d. The example uses Redis as a data store - using other storage solutions may be a good topic for a follow-up article. https://vibed.org/blog/posts/a-scalable-chat-room-service-in-d Reddit: https://www.reddit.com/r/programming/comments/3ze948/writing_a_scalable_chat_room_service_in_d/ Love the new (light) look of vibed.org! :)
Writing a scalable chat room service in D
Finally published the article that I had prepared in autumn last year. It gives an overview of the basic functionality needed to implement a typical web application using vibe.d. The example uses Redis as a data store - using other storage solutions may be a good topic for a follow-up article. https://vibed.org/blog/posts/a-scalable-chat-room-service-in-d Reddit: https://www.reddit.com/r/programming/comments/3ze948/writing_a_scalable_chat_room_service_in_d/
Re: Better watch out! D runs on watchOS!
Joakim writes: > On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote: >> On Wednesday, 30 December 2015 at 23:11:06 UTC, Joakim wrote: >>> That sounds like this issue I ran into with ARM EH: >>> >>> https://github.com/ldc-developers/ldc/issues/489#issuecomment-143560075 >>> >>> I was able to work around it by disabling the mentioned llvm >>> optimization pass: >>> >>> https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a#file-android_tls-L42 >>> >>> https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3133 >> >> Yup, that's exactly it! The approach I took was to leave >> optimization on, removed the casts, and byte load the data into the >> uint vars. If the dwarf data is not guaranteed to be aligned to the >> data type, then I think this is the approach to take. > > Sounds good, submit a PR and let's get it in. Was planning to get that PR going then got side tracked by a more difficult ARM exeption unwinding bug. It happens in std.random unittest at LDC -O2 or higher. Does this sound familiar Joakim? The bug is a bad stack pointer which blows up when the last unittest returns. This unittest has all the right conditions to generate stack adjustments around some of the function calls that throw exceptions. The exception landing pad does not fixup the stack adjustment, thus a stack leak on each caught exception. The unittest function epilog restores the stack by adding a fixed offset to match the prolog, so the stack pointer stays wrong when the saved registers and return address are popped. Really looks like LLVM is not doing the right thing with landing pads. In the meantime I patched LLVM to generate epilog that always uses frame pointer to restore the stack pointer. WatchOS requires a frame pointer, so this isn't too bad. Now all unittests pass at -O3 for watchOS. I am guessing iOS is not effected since it uses SjLj to restore the stack after an exception is thrown. I'll have to pursue this later. My mind is freed up for the original PR. -- Dan
Re: Hash Tables in D
On Monday, 4 January 2016 at 07:09:30 UTC, Minas Mina wrote:
On Sunday, 3 January 2016 at 19:29:05 UTC, Martin Nowak wrote:
There is a bug.
You should never do this b/c of iterator/range invalidation.
foreach (key; aa.keys)
aa.remove(key);
The reference states that keys: "Returns dynamic array, the
elements of which are the keys in the associative array".
Isn't the array newly allocated?
Hi,
You are right:
void main()
{
import std.stdio;
int[int] aa;
foreach (i; 0..9)
aa[i] = i * 10;
writeln(aa); // [0:0, 6:60, 7:70, 2:20, 3:30, 1:10, 8:80,
5:50, 4:40]
foreach (key; aa.keys)
aa.remove(key);
writeln(aa); // []
}
This would be a bug (segfault on my machine):
foreach (key; aa.byKey)
aa.remove(key);
Note that, in this example, there is no need to remove every
element separately, you can also just do
void main()
{
import std.stdio;
int[int] aa;
foreach (i; 0..9)
aa[i] = i * 10;
writeln(aa); // [0:0, 6:60, 7:70, 2:20, 3:30, 1:10, 8:80,
5:50, 4:40]
aa = null;
writeln(aa); // []
}
Bastiaan.
