Re: Beta 2.077.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/16/2017 06:45 PM, Martin Nowak wrote: > First beta for the 2.077.0 release. Second beta live now. This adds a missing core.sys.linux.netinet.in_ header which is used by vibe.d. Happy Testing - -Martin -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlnrHSIACgkQsnOBFhK7 GTlarA/5AQgG+A+QWTGx0BcokTjlS98N05qRailHUX27uL3lqeUrAWAoNa0iSS6a j/hmPXWWJpRUWg6eTMh+zGyHsDjaqjVVgnoodJdPqRh2qWC/X3DYHGOXI+Im3vsA XMjT/+AhKDebGnUIH+SCx06r/LjUvgIVqQnj2M89vh0NyACoDHLqYTngiaZnvvem L+b3xsArzThrold9h/pe2o6jk9vg914zxpIhu9R59VC8d30nzYWjW64RqNXrJn+B tC/ViI2/De4DQbUhty5QMtAK6hhbC4DksEhih1/kTGjobml4pFamE+sk9DDRBcjI cbPyCz+vX7n9U6OKuRB0jgGPoi7uUdL/ded2FwOshktTV6hD7YWS7n40EJ/Kug/w BYYfe4jepCVwEhBPmlziiPUmRKwflErSniSFwki6VD8Nyc7KGOrvaRC5+aRqfU0Z CUsNc+0WpB1HdKZ8jNzGuKgf28pheb/IHV/oCMeVqSIJE639KdQvunMV+0Zet3B3 BhZ1AwMyQnpGPjR1V1vlT+1oEiDPpyw71B15lk8Hve9VJhAeAd0L7xwL7Vm1czpY cFbW0Wq+zcUBRVvfTWsseqLH7LlSelBf/W48taxsHC7FpyKbibxyGM50wiWUxOXX WEgx2rLwS+EilIhWIaHGiMmxq1jkmFceWgVtbfr4WL0l6Hi6QD8= =/5x6 -END PGP SIGNATURE-
Re: iopipe alpha 0.0.1 version
On 10/19/2017 03:12 PM, Steven Schveighoffer wrote: > On 10/19/17 7:13 AM, Martin Nowak wrote: >> On 10/13/2017 08:39 PM, Steven Schveighoffer wrote: >>> What would be nice is a mechanism to detect this situation, since the >>> above is both un-@safe and incorrect code. >>> >>> Possibly you could instrument a window with a mechanism to check to see >>> if it's still correct on every access, to be used when compiled in >>> non-release mode for checking program correctness. >>> >>> But in terms of @safe code in release mode, I think the only option is >>> really to rely on the GC or reference counting to allow the window to >>> still exist. >> >> We should definitely find a @nogc solution to this, but it's a good >> litmus test for the RC compiler support I'll work on. >> Why do IOPipe have to hand over the window to the caller? >> They could just implement the RandomAccessRange interface themselves. >> >> Instead of >> ```d >> auto w = f.window(); >> f.extend(random()); >> w[0]; >> ``` >> you could only do >> ```d >> f[0]; >> f.extend(random()); >> f[0]; // bug, but no memory corruption >> ``` > > So the idea here (If I understand correctly) is to encapsulate the > window into the pipe, such that you don't need to access the buffer > separately? I'm not quite sure because of that last comment. If f[0] is > equivalent to previous code f.window[0], then the second f[0] is not a > bug, it's valid, and accessing the first element of the window (which > may have moved). The above sample with the window is a bug and memory corruption because of iterator/window invalidation by extend. If you didn't thought of the invalidation, then the latter example would still be a bug to you, but not a memory corruption. >> This problem seems to be very similar to the Range vs. Iterators >> difference, the former can perform bounds checks on indexing, the later >> are inherently unsafe (with expensive runtime debug checks e.g. in VC++). > > But ranges have this same problem. > > For instance: > const(char[])[] lines = stdin.byLine.array; > > Here, since byLine uses GC buffering, it's @safe (but wrong). If non-GC > buffers are used, then it's not @safe. > > I think as long as the windows are backed by GC data, it should be > @safe. In this sense, your choice of buffering scheme can make something > @safe or not @safe. I'm OK with that, as long as iopipes can be @safe in > some way (and that happens to be the default). > >> Similarly always accessing the buffer through IOPipe would allow cheap >> bounds checking, and sure you could still offer IOPipe.ptr for unsafe >> code. > > It's an interesting idea to simply make the iopipe the window, not just > for @safety reasons: > > 1. this means the iopipe itself *is* a random access range, allowing it > to automatically fit into existing algorithms. > 2. Existing random-access ranges can be easily shoehorned into being > ranges (I already did it with arrays, and it's not much harder with > popFrontN). Alternatively, code that uses iopipes can simply check for > the existence of iopipe-like methods, and use them if they are present. > 3. Less verbose usage, and more uniform access. For instance if an > iopipe defines opIndex, then iopipe.window[0] and iopipe[0] are possibly > different things, which would be confusing. > > Some downsides however: > > 1. iopipes can be complex and windows are not. They were a fixed view of > the current buffer. The idea that I can fetch a window of data from an > iopipe and then deal simply with that part of the data was attractive. You could still have a window internally and just forward to that. > 2. The iopipe is generally not copyable once usage begins. In other > words, the feature of ranges that you can copy them and they just work, > would be difficult to replicate in iopipe. That's a general problem. Unique ownership is really useful, but most phobos range methods don't care, and assume copying is implicit saving. Not too nice and I guess this will bite us again with RC/Unique/Weak. The current workaround for this is `refRange`. > A possible way forward could be: > > * iopipe is a random-access range (not necessarily a forward range). > * iopipe.window returns a non-extendable window of the buffer itself, > which is a forward/random-access range. If backed by the GC or some form > of RC, everything is @safe. > * Functions which now take iopipes could be adjusted to take > random-access ranges, and if they are also iopipes, could use the extend > features to get more data. > * iopipe.release(size_t) could be hooked by popFrontN. I don't like the > idea of supporting slicing on iopipes, for the non-forward aspect of > iopipe. Much better to have an internal hook that modifies the range > in-place. > > This would make iopipes fit right into the range hierarchy, and > therefore could be integrated easily into Phobos. I made an interesting experiment with buffered input ranges quite a while ago. https://gist.github.com/MartinNowak
Some tasks in D app
Hello. I have an app for multiplayer game website. I am Facing an issue about stacking terminal. Also the app does not save the logs which is supposed to. I need someone who can fix this. Will send the app to developer. in total The tasks are : 1) Fix stacking issue in the terminal, 2) Fix saving logs 3) Fix the reconnection issue (during the game if one of the opponent has left the game then another opponent sees the pop up window which says "please wait while your opponent reconnect". But the problem is server does not reconnects the disconnected user when he comes back. 4) The same username can be logged in the server. we need to prevent this case. if the user is already in the server, then it shouldnt be allowed him to login again. We have allocated budget for all these tasks. In total we are going to pay 250-300$. Please contact me by email if you are interested : a.mammad...@liverpool.ac.uk Regards
Re: DCompute target: Intel to Introduce New CPU-FPGA Hybrid Chip Supported by Acceleration Stack
On Friday, 20 October 2017 at 20:41:24 UTC, Nordlöw wrote: Ever since I first tried programming in VHDL and realized that it, at that time, was far too unproductive for my taste, I've been waiting for the software and FPGA programming models to unite... What kinds of simplifications (over OpenCL) can and will DCompute offer in this regard? I don't know. It is an interesting development, but I've got a feeling that you have to address the hardware very specifically to get worthwhile performance. My gut feeling is that abstractions would be a bad idea… So maybe this will be best suited for very narrow domains where you can rely on third party libraries (e.g. statistical signal processing and other fields) or narrow applications that can afford to tune very carefully to the underlying hardware.
Re: DCompute target: Intel to Introduce New CPU-FPGA Hybrid Chip Supported by Acceleration Stack
But I also get this feeling that Intel do this as an anti-competitive monopolistic. Basically preventing ARM and AMD from partnering with Altera. So it could be more hostile than friendly… The buy up might not make sense business wise in terms of new products. But it could make a lot of sense to keep other competing products off the table to keep the pricing of Xeons up… A pessimistic view, perhaps… but Intel has a history…
Re: DCompute target: Intel to Introduce New CPU-FPGA Hybrid Chip Supported by Acceleration Stack
On Friday, 20 October 2017 at 20:41:24 UTC, Nordlöw wrote: Ever since I first tried programming in VHDL and realized that it, at that time, was far too unproductive for my taste, I've been waiting for the software and FPGA programming models to unite... What kinds of simplifications (over OpenCL) can and will DCompute offer in this regard? Over OpenCL: Same benefits it does over standard C * a not completely insane interface * generality and parameterisation * reusability * ... As to how much of the total power of the FPGA you can use from D compared to VHDL remains to be seen, although it will be interesting to see how well this can cooperate with Luís' DHDL.
Re: Unit Testing in Action
On Friday, 20 October 2017 at 21:26:35 UTC, qznc wrote: * coverage is not sufficiently solved. The author suggests to reformat code so short-circuit evaluations become multiple lines? If you can use gdc or ldc, branch coverage should be supported out of the box. Other tools support regions to be marked as unreachable, e.g GCOVR_EXCL_START/GCOVR_EXCL_STOP. I'd also err on the side that unittests themselves should not be part of coverage, but an option in druntime and more metadata from dmd might solve this. Filed under https://issues.dlang.org/show_bug.cgi?id=17923.
Silicon Valley D Meetup - October 26, 2017 - "D Fibers" by Ali Çehreli
[We're at a very convenient location again this time: Downtown Mountain View.] https://www.meetup.com/D-Lang-Silicon-Valley/events/243120102/ D Fibers Ali will present a shorter version of his DConf 2016 talk: http://dconf.org/2016/talks/cehreli.html D's fibers (coroutines in other languages) are not a part of the language but a feature implemented by the D runtime. This talk should be fairly accessible to new programmers even without a CS background as it will explain the function call stack as well as context registers, concepts necessary to understand how fibers are useful at all. As always, bring all other D questions and comments... Ali Çehreli has been working with C, C++, and D in Silicon Valley since 1996. He is the author of the book "Programming in D", a board member of The D Language Foundation, and an organizer of DLang and ACCU meetup groups in Silicon Valley. Ali
Re: Unit Testing in Action
On Friday, 20 October 2017 at 21:26:35 UTC, qznc wrote:
* fluent-asserts is considered the best expectations library.
Syntax is `(x + y).should.equal(42).because("of test
reasons");` and it gives nice output with code snippets.
The code snippets were the prominent feature from the
announcement of fluent-asserts. But this feature was the reason
why I originally dismissed the library. In my opinion, the goal
is that the failure message describes the issue without the need
to look at the test implementation.
The diff of lengthy strings is, what I was always looking for.
Back then, I wrote a lightweight kind of diff for dunit. In
writing the blog post, I rechecked code.dlang.org. To my
surprise, Sönke Ludwig ported google-diff-match-patch to D in
2014. (The status is "build: error", but there is hope that it's
only corner cases that don't work.) Further investigation
revealed that fluent-asserts uses this port. So, it's this
"hidden feature" that currently makes fluent-asserts my favorite.
Re: Unit Testing in Action
On 10/21/2017 6:14 AM, Martin Nowak wrote: On Friday, 20 October 2017 at 21:26:35 UTC, qznc wrote: * coverage is not sufficiently solved. The author suggests to reformat code so short-circuit evaluations become multiple lines? If you can use gdc or ldc, branch coverage should be supported out of the box. Other tools support regions to be marked as unreachable, e.g GCOVR_EXCL_START/GCOVR_EXCL_STOP. I'd also err on the side that unittests themselves should not be part of coverage, but an option in druntime and more metadata from dmd might solve this. Filed under https://issues.dlang.org/show_bug.cgi?id=17923. Not sure what is meant by branch coverage. Consider: x = 2; if (x == 1 || x == 2) Coverage would give: 1|x = 2; 2|if (x == 1 || x == 2) I.e. the second line gets an execution count of 2. By contrast, 1|x = 1; 1|if (x == 1 || x == 2) What's happening here is each of the operands of || are considered to be separate statements as far as coverage analysis goes. It becomes clearer if it is reformatted as: 1|x = 2; 1|if (x == 1 || 1|x == 2) or: 3|x = 2; if (x == 1 || x == 2) It's usually possible to trivially suss out the coverage of the clauses by looking at the preceding and succeeding line counts. Putting the clauses on separate lines also works. If there's a better way to display the various counts, please add it to the bugzilla report.
Re: Silicon Valley D Meetup - October 26, 2017 - "D Fibers" by Ali Çehreli
On Saturday, 21 October 2017 at 18:20:13 UTC, Ali Çehreli wrote: [We're at a very convenient location again this time: Downtown Mountain View.] [...] allahiniz varsa kaydedersiniz. :)
Re: Silicon Valley D Meetup - October 26, 2017 - "D Fibers" by Ali Çehreli
On 10/21/2017 04:57 PM, Mengu wrote: > On Saturday, 21 October 2017 at 18:20:13 UTC, Ali Çehreli wrote: >> [We're at a very convenient location again this time: Downtown >> Mountain View.] >> >> [...] > > > allahiniz varsa kaydedersiniz. :) [Mengü is wishing that we will manage to record the meeting.] Related, we tried to use the very fancy equipment that's in the exact meeting room that we will be using. The audio was on and off, with about 50% success rate. We fixed it by powering down one of the fancy microphone thingies. To repeat, in my experience, recording meetings is not a solved problem yet. :) Ali
