Re: Documentation repository for Hunt Framework !
On Tuesday, 30 June 2020 at 15:40:14 UTC, zoujiaqing wrote: I'm glad we've released the first set of Hunt Framework today. Make it easier for you to use Hunt Framework. Hope more people can work with us to improve the content of the document. https://github.com/huntlabs/hunt-framework-docs The api looks so clean and the docs is great too. Impressive.
Re: Documentation repository for Hunt Framework !
On Tuesday, 30 June 2020 at 15:40:14 UTC, zoujiaqing wrote: I'm glad we've released the first set of Hunt Framework today. Make it easier for you to use Hunt Framework. Hope more people can work with us to improve the content of the document. https://github.com/huntlabs/hunt-framework-docs This is awesome! It must have been tone of work.
Documentation repository for Hunt Framework !
I'm glad we've released the first set of Hunt Framework today. Make it easier for you to use Hunt Framework. Hope more people can work with us to improve the content of the document. https://github.com/huntlabs/hunt-framework-docs
Re: iopipe v0.2.0 - safe update
On 6/30/20 6:41 AM, Joseph Rushton Wakeling 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). Cool, and congratulations :-) 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. One concern here -- this means that one cannot control when an app using this might block for GC, right? Any thoughts on how a user could get more deterministic control on when the memory would be released? Ref counting is only used internally when I need automatic cleanup. I should be able to make it possible to specify an alternate ref-counting scheme (i.e. allow using std.typecons.refCounted instead). Certainly, you don't need to use it for most things. The current places where it's automatically used are for output (in the case of auto-flush, if you don't want auto-flush, then it does not refcount the pipe), and in the zip/unzip pipes, which depend on zlib, and zlib uses some self-referencing pointers I think inside its struct. It is already possible to use an alternative allocator for buffering. -Steve
Re: iopipe v0.2.0 - safe update
On 6/30/20 5:05 AM, aberba wrote: On Monday, 29 June 2020 at 11:58:10 UTC, Steven Schveighoffer wrote: and all you have to do is compose the pieces to get it to be a text iopipe (an iopipe where the window type is a string type). No sure I understand this statement. What I mean is, no matter where your data comes from, you compose iopipes together to get it to be a text iopipe (one that is comprised of UTF code points), and then the json parser can handle it. For instance, it could be zipped data on a network socket, it could be data that comes from a segment of a file that you loaded into a local buffer. It could even be data that is generated. As long as it provides a mechanism to be read into a buffer (or is already in a buffer), jsoniopipe can handle it. This is one thing I think makes iopipe so useful -- you can compose them together like you can compose ranges, and the end result is fully optimized on all layers. I'm not familiar with NodeJs in general so I can't comment on that. I would say iopipe is focused on making streaming more like dealing with arrays, with as high performance as possible. One thing I've always disliked about most streaming libraries is that they hide the buffer as an implementation detail, but it should be the focus. How well does iopipe work in a multi-threaded environment? I'm assuming you mean multiple threads using the same iopipe? It does not have any implementation to handle something like that. You would have to handle the locking yourself. I plan at some point to write a full replacement for writeln and friends using iopipe, which would necessarily have to deal with multiple threads. I'm not sure whether the multithreading constructs would be put into iopipe, or something else, I haven't thought enough about it. Let me know if there's any other questions you have, either here or on the github issues. -Steve
Re: Talk by Herb Sutter: Bridge to NewThingia
On Monday, 29 June 2020 at 21:29:31 UTC, Ali Çehreli wrote: On 6/29/20 8:45 AM, Dagmar wrote: > If I shouldn't use > const, how should I emphasize the intention to pass a pointer only for > reading? How can I be sure that my class invariant is not compromised? > Also, there is the shared attribute, but it isn't designed nor > implemented well. Lots of questions, no solutions. D is intended to be a > C++ replacement, but it doesn't explain to C++ programmers how to change > their way of thinking. There is this dated document: https://dlang.org/articles/cpptod.html Ali, how you answered the questions is how I think one would want to find a document for C++ folks moving to D. The outdated doc I believed focused mostly on the syntactic differences which I agree we now need someone to help get it up to date with more coverage. But a document with answers to common practical questions like just liked the above... const, shared, GC, etc doesn't seem to fit in the that doc. I believe you've pretty much said some things that we can work on to get things documented. I'm sure there's more similar questions. So a D-idioms-like kind of doc/wiki might do. Of course, in addition to the cpptod.html one. https://p0nce.github.io/d-idioms/
Re: Talk by Herb Sutter: Bridge to NewThingia
On Monday, 29 June 2020 at 15:45:48 UTC, Dagmar wrote: Sometimes there is only one way to find out why it behaves like it does: to ask in this forum. And you may not like the answers. D has transitive const, but what if I should lazy evaluate/cache a value or use a mutex? If I shouldn't use const, how should I emphasize the intention to pass a pointer only for reading? How can I be sure that my class invariant is not compromised? Also, there is the shared attribute, but it isn't designed nor implemented well. Lots of questions, no solutions. D is intended to be a C++ replacement, but it doesn't explain to C++ programmers how to change their way of thinking. I'd appreciate if there was a document that explains typical tasks and ways to get them done in D for the C++ dummies, like me. This calls for a D-idioms for C++ folks. Its overlooked but I believe its very important to have. Folks who know the language might overlook this but can be of great help for new recruits. Considering that's the goal...at least my goal :) It requires someone with C++ knowledge to start, then we'll take care of driving in more idioms. Like a GitHub wiki or something. The D wiki more appropriately for centralization. Anyone up for it?
Re: Talk by Herb Sutter: Bridge to NewThingia
On Monday, 29 June 2020 at 15:54:36 UTC, Adam D. Ruppe wrote: On Monday, 29 June 2020 at 15:45:48 UTC, Dagmar wrote: D has a GC. If you turn it off you lose dynamic/associative arrays, classes, probably something else. You just have to construct them with a function instead of with the built-in `new` operator. (Well, associative array will need a library solution picked too, but the rest work build in if you construct them differently.) It is very easy to do, just perhaps not well documented. Ditto. Hence the need for documenting them.
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). Cool, and congratulations :-) 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. One concern here -- this means that one cannot control when an app using this might block for GC, right? Any thoughts on how a user could get more deterministic control on when the memory would be released?
Re: Talk by Herb Sutter: Bridge to NewThingia
On Monday, 29 June 2020 at 12:17:57 UTC, Russel Winder wrote: On Mon, 2020-06-29 at 10:31 +, IGotD- via Digitalmars-d-announce wrote: On the other hand people are stopping using C++ in favour of Go, Rust, Python, but it seems not D. This isn't a fact by the way, there are many people using D, including folks I never expected. We could use more PR though. In D's case, its PR, its what I'm looking to do something about.
Re: iopipe v0.2.0 - safe update
On Monday, 29 June 2020 at 11:58:10 UTC, Steven Schveighoffer wrote: On 6/28/20 8:37 PM, aberba wrote: On Sunday, 28 June 2020 at 20:26:43 UTC, JN wrote: 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. Yes, the emphasis is on being able to handle large sets of data similarly to how you would handle an array, but not having to load the whole thing into an array. It uses buffering to present an array-like interface. The only difference between it and arrays is you have to tell it how much data is important to you at the moment. There is also a focus on composability -- I want you to be able to build any type of harness to take what you have and turn it into something you can feed into a parser/handler. Thanks for the expansion. I could really use this for an article. Added to my to-do list. Take for example, jsoniopipe [1], which is a library that uses iopipe to parse JSON. You can feed it any source -- a string, a zipped file, a network socket, and all you have to do is compose the pieces to get it to be a text iopipe (an iopipe where the window type is a string type). Then the json library will parse it and provide you with a stream of JSON data. Because everything is available to the compiler, it can optimize/inline across all the layers, and provide the best performance possible (see my presentation at dconf 2017 [2] for how this works out, also linked by Clarice). Will looking into that library more. and all you have to do is compose the pieces to get it to be a text iopipe (an iopipe where the window type is a string type). No sure I understand this statement. I'm curious myself how it differs from the NodeJs Stream API. Would you say iopipe is a Streaming API by definition? I'm not familiar with NodeJs in general so I can't comment on that. I would say iopipe is focused on making streaming more like dealing with arrays, with as high performance as possible. One thing I've always disliked about most streaming libraries is that they hide the buffer as an implementation detail, but it should be the focus. How well does iopipe work in a multi-threaded environment? -Steve [1] https://code.dlang.org/packages/jsoniopipe [2] https://www.youtube.com/watch?v=un-bZdyumog I'll probably re-watch it before writing the article.
Re: News on the D Blog: SAOC 2020 and More
On Tuesday, 23 June 2020 at 14:13:44 UTC, Adam D. Ruppe wrote: On Tuesday, 23 June 2020 at 12:00:06 UTC, Mike Parker wrote: D Language Foundation finance updates [...] Really, the best thing to do is probably offering the documents directly on the official website. Then if someone does formally request it you can just point back to dlang.org/foundation or whatever. Yes please, more transparency => more donations!
