Re: iopipe v0.2.0 - safe update
On Sunday, 28 June 2020 at 20:26:43 UTC, JN wrote: On Sunday, 28 June 2020 at 18:57:22 UTC, Steven Schveighoffer wrote: Just wanted to post that I finished my update of iopipe to be @safe. I still have some work to do with std.io so things are more usable (next on my list is to make standard handles accessible). In this update, I've made it so nearly all of iopipe can be used in @safe code. The one exception is the RingBuffer, which can leave dangling pointers, hence the unsafety. Inside iopipe is a RefCounted type that is @safe. It uses the GC for memory management, so while destruction is synchronous, the memory itself is left to the GC to clean up. -Steve https://code.dlang.org/packages/iopipe What's iopipe and what does it do? How does it compare with std.process? I my line of words, its what you'd use to stream large files and do processing on it. Like CSV, video??, Json, and the like. Its high performance cus it optimized to haven great performance even for large files. Designed to let you chain the processing pipeline using reusable functions...and you can compose one yourself. I'm curious myself how it differs from the NodeJs Stream API. Would you say iopipe is a Streaming API by definition?
Re: Talk by Herb Sutter: Bridge to NewThingia
On Monday, 29 June 2020 at 00:24:22 UTC, aberba wrote: On Sunday, 28 June 2020 at 21:00:09 UTC, Dibyendu Majumdar wrote: [...] * Community * Strong die hard advocate * Tutorials, learning resources Those are the stuff I personally think I can't contribute more. I meant opposite, jeez Those are the stuff I'm personally trying to push and contribute to for D primarily.
Re: Talk by Herb Sutter: Bridge to NewThingia
On Sunday, 28 June 2020 at 21:00:09 UTC, Dibyendu Majumdar wrote: On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu wrote: How to answer "why will yours succeed, when X, Y, and Z have failed?" https://www.youtube.com/watch?v=wIHfaH9Kffs Very insightful talk. To be honest the analysis doesn't quite stack up. Because compatibility is not the reason for the success of Go, or Rust. I would say the success of a language depends on many factors: * Luck * Timing - and a need to be filled * Sufficient commercial usage * Big name factor - Go authors tried a few times creating languages that did not succeed until they had Google backing. * Language offers something sufficiently different solution than existing solutions * Tooling * Quality of implementation * Community * Strong die hard advocate * Tutorials, learning resources Those are the stuff I personally think I can't contribute more.
Re: iopipe v0.2.0 - safe update
On 6/28/20 2:57 PM, Steven Schveighoffer wrote: Just wanted to post that I finished my update of iopipe to be @safe. I still have some work to do with std.io so things are more usable (next on my list is to make standard handles accessible). In this update, I've made it so nearly all of iopipe can be used in @safe code. The one exception is the RingBuffer, which can leave dangling pointers, hence the unsafety. I forgot to mention (and was kindly reminded by Jon Degenhardt), this is the first release where Martin's std.io library (https://github.com/MartinNowak/io) is optional. In the future, iopipe will remove this dependency. The only thing that depends on std.io is the deprecated `openDev` function. So if you were expecting iopipe to bring in that dependency, you will have to add it to your dub.json/dub.sdl file. -Steve
Re: Talk by Herb Sutter: Bridge to NewThingia
On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu wrote: How to answer "why will yours succeed, when X, Y, and Z have failed?" https://www.youtube.com/watch?v=wIHfaH9Kffs Very insightful talk. To be honest the analysis doesn't quite stack up. Because compatibility is not the reason for the success of Go, or Rust. I would say the success of a language depends on many factors: * Luck * Timing - and a need to be filled * Sufficient commercial usage * Big name factor - Go authors tried a few times creating languages that did not succeed until they had Google backing. * Language offers something sufficiently different solution than existing solutions * Tooling * Quality of implementation
Re: iopipe v0.2.0 - safe update
On Sunday, 28 June 2020 at 20:26:43 UTC, JN wrote: On Sunday, 28 June 2020 at 18:57:22 UTC, Steven Schveighoffer wrote: Just wanted to post that I finished my update of iopipe to be @safe. I still have some work to do with std.io so things are more usable (next on my list is to make standard handles accessible). In this update, I've made it so nearly all of iopipe can be used in @safe code. The one exception is the RingBuffer, which can leave dangling pointers, hence the unsafety. Inside iopipe is a RefCounted type that is @safe. It uses the GC for memory management, so while destruction is synchronous, the memory itself is left to the GC to clean up. -Steve https://code.dlang.org/packages/iopipe What's iopipe and what does it do? How does it compare with std.process? Here's a pertinent dconf presentation that might help you: https://www.youtube.com/watch?v=un-bZdyumog The abstract: http://dconf.org/2017/talks/schveighoffer.html
Re: iopipe v0.2.0 - safe update
On 6/28/20 4:26 PM, JN wrote:
What's iopipe and what does it do? How does it compare with std.process?
Yeah, I guess I should be more specific in such announcements, sorry!
iopipe is a performance-oriented input/output library for D, which uses
direct buffer access, and provides a similar experience to unix pipes,
but for buffered data instead.
For example:
import std.io; // https://github.com/MartinNowak/io
foreach(line; File("input.txt.gz")
.refCounted // std.io files are not copyable
.bufd // buffer it
.unzip // decompress it
.assumeText // assume it's text (char[] instead of ubyte[])
.byLineRange) // convert to a line-based range
-Steve
Re: iopipe v0.2.0 - safe update
On Sunday, 28 June 2020 at 18:57:22 UTC, Steven Schveighoffer wrote: Just wanted to post that I finished my update of iopipe to be @safe. I still have some work to do with std.io so things are more usable (next on my list is to make standard handles accessible). In this update, I've made it so nearly all of iopipe can be used in @safe code. The one exception is the RingBuffer, which can leave dangling pointers, hence the unsafety. Inside iopipe is a RefCounted type that is @safe. It uses the GC for memory management, so while destruction is synchronous, the memory itself is left to the GC to clean up. -Steve https://code.dlang.org/packages/iopipe What's iopipe and what does it do? How does it compare with std.process?
iopipe v0.2.0 - safe update
Just wanted to post that I finished my update of iopipe to be @safe. I still have some work to do with std.io so things are more usable (next on my list is to make standard handles accessible). In this update, I've made it so nearly all of iopipe can be used in @safe code. The one exception is the RingBuffer, which can leave dangling pointers, hence the unsafety. Inside iopipe is a RefCounted type that is @safe. It uses the GC for memory management, so while destruction is synchronous, the memory itself is left to the GC to clean up. -Steve https://code.dlang.org/packages/iopipe
Re: From the D Blog: A Pattern for Head-mutable Structures
On Sunday, 28 June 2020 at 16:31:35 UTC, Avrina wrote: On Sunday, 28 June 2020 at 02:52:03 UTC, Mike Parker wrote: If that's not good enough for you, then I have nothing else to say on the matter. Replies like this one and andrei are why. You are directing a community around a topic to an article about that topic. What do you think they are going to do? There's a reason why votes don't count when an article is linked directly. They didn't do it by mistake. No worries, I'll post the direct link for you in the future. I got you covered. I have a feature request to the forum engine, automatically delete all posts with hn deeplinks, problem solved.
Re: From the D Blog: A Pattern for Head-mutable Structures
On Sunday, 28 June 2020 at 02:52:03 UTC, Mike Parker wrote: On Saturday, 27 June 2020 at 17:58:50 UTC, Avrina wrote: They are actually going against their rules and are actively trying to game their algorithm by telling D's community to search for the article instead of providing. So actually, I'd they also wanted to follow tand respect the rules of another community, then they would be providing a direct link. What they are doing now is going against their rules by trying to bypass their algorithm for more fake internet points. I don't know why you're so worked up about this, but please scroll up and read what I wrote. Nowhere have I asked for anyone to upvote the post. I want people to know it's there so that those who would like to do so can head over and comment. Whether you upvote or not is up to you, but if you do so I would like it to count. I also don't want direct links harming our ranking. That gets more eyes on the post and helps us all in the long run. If that's not good enough for you, then I have nothing else to say on the matter. Replies like this one and andrei are why. You are directing a community around a topic to an article about that topic. What do you think they are going to do? There's a reason why votes don't count when an article is linked directly. They didn't do it by mistake. No worries, I'll post the direct link for you in the future. I got you covered.
Re: Talk by Herb Sutter: Bridge to NewThingia
On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu wrote: How to answer "why will yours succeed, when X, Y, and Z have failed?" https://www.youtube.com/watch?v=wIHfaH9Kffs Very insightful talk. He touches on, why we should have @safe by default and the importance of the C++ call support. The challenges in this community is that everyone has their own market they would like to see D displace. C, C++, web, .Net, gnome gui...
