Re: Blog Post: Beating std::visit Without Really Trying
On Sunday, 6 October 2019 at 19:58:04 UTC, Walter Bright wrote: On 10/6/2019 2:59 AM, Paolo Invernizzi wrote: Well, so there's hope that _very little_ improvements will be merged, in a way or another? I mean, there's some sort of policy for things like that: https://github.com/dlang/phobos/pull/6730 Frankly speaking, the actual situation it's a little discouraging... We want a much higher bar for merging things than historically. A smaller, higher quality library is preferable to a kitchen sink library. The pull request I've shown is pretty simple: - std.socket is ... well... not the best piece of code out there - the `receive` method is usually in the _hot_ code path - it's not marked @nogc, and actually it does not allocate So: - adding @nogc will break derived classes that redefines the method (I still regret that the language was not shifted towards "final by default", years ago, as clearly that would be a *great* mitigation over that kind of problems) - adding another method to a class, marked @nogc, and (maybe) deprecating the previous method is seen as 'annoying', also if it's a _clear_ improvement over the actual situation (you can write _better_ code with that in place compared to the actual situation, I mean) I'm on the same boat with you, regarding what you wrote, but ... I still don't understand the number printed on the bar level. There's a number of recurring patterns of simple things to fix like the one above, with the same kind of problem to address. I humbly suggest the core team to just forge a general recipe for some of them, and stick with it, so that the number of the bar is less blurred. That scales, and encourage contribution. So, what do you think about starting a first one bases on cases similar to the above?
Re: Blog Post: Beating std::visit Without Really Trying
On Monday, 7 October 2019 at 01:38:04 UTC, Paul Backus wrote: Just to clarify: SumType isn't, and was never intended to be, a drop-in replacement for Algebraic. Their interfaces are similar enough that porting code from Algebraic to SumType shouldn't be too difficult, but even within the common subset, there are incompatibilities. For example, here's a post from an old sumtype announcement thread where I discuss the differences between SumType's `match` and Algebraic's `visit`: https://forum.dlang.org/post/xipgrrfljdnyhrhnm...@forum.dlang.org I don't follow. The visit and match template signatures are identical, and from what you describe the SumType match implementation should support the same handler choices as visit, while allowing extra/more flexible choices. Where's the breaking change? Are there selections of handlers that work for visit and don't work with match?
Re: Blog Post: Beating std::visit Without Really Trying
On Monday, 7 October 2019 at 08:07:01 UTC, Joseph Rushton Wakeling wrote: Where's the breaking change? Are there selections of handlers that work for visit and don't work with match? Yes. https://run.dlang.io/is/UpaY2E
Re: Blog Post: Beating std::visit Without Really Trying
On Sunday, 6 October 2019 at 03:47:25 UTC, Seb wrote: Phobos is amazing and stable, but exactly because of these attributes there isn't much active development happening. I thought that the work on dip1000 and the current push for borrow semantics and other lifetime related issues that have certainly been receiving a lot of attention were partly motivated because Andrei could not write the containers library that he wanted to write, and that one of the first applications that those things would see is a proper containers library in Phobos.
Reloaded Vibes: Smart auto-reloading service and server for (web) development.
https://forum.dlang.org/post/nnwxjluqodqayihrd...@forum.dlang.org On Friday, 12 July 2019 at 16:23:35 UTC, 0xEAB wrote: On Thursday, 27 June 2019 at 15:50:43 UTC, BN26 wrote: Amazing work! I was looking for something like this. At the moment, I have to rerun dub after every change, it's a pain to develop with Vibe.d Hey, nice to hear it's useful to you :) Do you already have something similar in use? No, I literally killed the process and rerun dub again, how have this not been fixed yet? Iterative and incremental development is impossible with vibe.d.
Re: Reloaded Vibes: Smart auto-reloading service and server for (web) development.
On Mon, Oct 07, 2019 at 10:21:08PM +, beyar-123--- via Digitalmars-d-announce wrote: [...] > > On Thursday, 27 June 2019 at 15:50:43 UTC, BN26 wrote: > > > Amazing work! I was looking for something like this. > > > > > > At the moment, I have to rerun dub after every change, it's a pain > > > to develop with Vibe.d [...] > > > Do you already have something similar in use? > > No, I literally killed the process and rerun dub again, how have this > not been fixed yet? > Iterative and incremental development is impossible with vibe.d. Dub leaves a lot to be desired as a build system. I gave up using dub for my vibe.d project a long time ago. Instead, I create a fake empty dub project in a subdirectory whose sole purpose is to declare dependency on vibe.d, then I run dub only once in that subdirectory when I want to update vibe.d. The rest of the time, I use my own build system to do the actual build/link. My turnaround time was significantly improved by doing this. T -- People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard (1813-1855)
intel-intrinsics v1.2.0: Added GDC support, SSE3
`intel-intrinsics` is a DUB package for people interested in x86 performance that want a portable set of intrinsics which works with all D compilers. Available through DUB: http://code.dlang.org/packages/intel-intrinsics *** Changelog of v1.2.0 *** - SSE3 intrinsics were implemented. - Added GDC x86/x86_64 support See this table here to know in which case the intrinsics resort to a slow, emulated version: https://github.com/AuburnSounds/intel-intrinsics#supported-instructions-set
Re: intel-intrinsics v1.2.0: Added GDC support, SSE3
On Tue, 8 Oct 2019 at 02:30, Guillaume Piolat via Digitalmars-d-announce wrote: > > `intel-intrinsics` is a DUB package for people interested in x86 > performance that want a portable set of intrinsics which works > with all D compilers. > > Available through DUB: > http://code.dlang.org/packages/intel-intrinsics > > > *** Changelog of v1.2.0 *** > > - SSE3 intrinsics were implemented. > - Added GDC x86/x86_64 support > > > See this table here to know in which case the intrinsics resort > to a slow, emulated version: > https://github.com/AuburnSounds/intel-intrinsics#supported-instructions-set Thanks. -- Iain
