Re: yet another event loop
On Wednesday, 24 August 2016 at 18:03:39 UTC, Eugene Wissner wrote: https://github.com/caraus-ecms/tanya Ok there are not so many event loops in D and here an another one and its name is "tanya". ... Nice works, thanks.
Silicon Valley D Meetup August 25, 2016 - Fireside Chat with Andrei Alexandrescu
We will post a Google Hangouts link here at the start at 19:00 (7pm) Pacific time: http://www.meetup.com/D-Lang-Silicon-Valley/events/232970396/ Please try to come in person for free food and maybe a free copy of the book "Programming in D". The venue: Innowest 764 San Aleso Ave, Sunnyvale, CA Ali
yet another event loop
https://github.com/caraus-ecms/tanya Ok there are not so many event loops in D and here an another one and its name is "tanya". I want it to become not an event loop only but a general purpose library that has an event loop. What once started as a libev rewrite, hasn't much common with libev now except some general concepts like watchers. Regarding libev: 1) tanya is very, very basic and it hasn't a lot of important features yet like signals, UDP, threads and so on. I had to begin somewhere and stripped out everything that isn't relevant for a basic event loop. Features will be added with the time. 2) Only epoll is currently supported. But I tried to create an API that can be easily extended, so you have to extend one class and implement a few methods to add other backends. 3) In another thread chmike (many thanks again!) pointed me to Windows IOCP. I'm not completely sure I understand how the completion ports work, but I implemented the loop in the way that you haven't to care about file descriptors and sockets but get notified if the data are really available. And you write aswell not to a socket but into a buffer, and the event loop takes care of passing it then to the socket. I hope it can make the work with the loop more pleasant and can make it possible to create a performant Windows implementation. Other points: 1) The library is 100% @nogc. I know there were some discussions that this @nogc is pure marketing thing, but I find it helpful that the compiler can say if you allocate somewhere in a language where GC allocations can happen behind the scenes. 2) The loop throws a few exceptions that should be freed, but I'm thinking to switch to some data type "either exception or return value" and make the loop nothrow. It has nothing to do with @nogc. It is just kind of not very cool if an exception can kill the event loop if something goes wrong. 3) The library isn't thread safe. I will work on it later. 4) libev wasn't the only source of inspiration. tanya is a mix of libev and asyncio and asynchronous. I took over the concept of protocols and transports from asyncio/asynchronous since I believe they make the writing of applications really pleasant. The difference is that they aren't a kind of "wrapper" around the actual event loop, but are first-class citizens. It could make it difficult to write such wrappers like that ones that exist for libasync, but on the other side it kills some unneeded abstractions and makes the code structure simplier, that could also give some additional performance. 5) I tried to write unittests and short descriptions everywhere, so there is some documentation and examples. For an usage example skip the crap I'm writing here and look at the end of this message. There are already some "extras": tanya.memory: has a simple allocator (Ullocator) that uses mmap/munmap (tested on Linux, will theoretically work on other platforms aswell). "allocator" package has some functions like "finalize" that can be used in @nogc code instead of dispose or "resizeArray" that is similar to shrinkArray/expandArray from std.experimental.allocator, but doesn't take a delta as argument but just the length, that the array should have. The allocator was the most difficult part of the library for me, but very interesting. I had to rewrite it 3 times till I got something working. I just advice everyone to write their own malloc/free implementaion, it is a frustrating, but awsome experience! tanya.container: Queue, Singly-linked list and In-/Output Buffer (useful in C-style functions that take a void pointer and the length as argument and return bytes read/written). I wrote them for the event loop, not sure they are good as general-purpose containers, but I would be anyway interested to make them suitable for other use-cases. They are also differently concepted than phobos containers. Phobos containers as far as I've seen are containers that implement ranges functionality in substructs/subclasses. tanya's containers are a mix of containers and ranges. tanya.math: has "pow" function that calculates x**y mod z. The algorithm is similar to the one used by phobos. The return type and arguments are currently ulong but it will change, I will need larger numbers probably. tanya.random: has an "Entropy" class that can generate 64-byte blocks of random data (uses getrandom syscall). The generic logic is stolen from mbedtls. tanya.crypto.padding: implements some algorithms to pad 128/192/258-byte blocks of data. But you cannot remove the padding :) Sorry, it will be added soon. Just started. I made some tests with an echo-client written in Go (just found one benchmarking one-page Go echo-client in the internet). Here is an usage example, just to give some feeling how the library works (Examples and description will be added to the repository soon): import tanya.memory; import tanya.event.loop; import
Re: On the future of DIP1000
On Tuesday, 23 August 2016 at 18:37:46 UTC, Dicebot wrote: By its design definition DIP process is for approving communitty proposals by Walter/Andrei thus there is no point in pretending they can't ignore the feedback. Only reason it is even processed in the same queue is so that developers can track all major proposed changes in one place. Well the fact that we have a public review and can criticize the proposal is as much as you can get from a peer reviewed process. If you have valid and important arguments they won't just get ignored. In fact [DIP74](http://wiki.dlang.org/DIP74) faced a lot of criticism for not properly addressing escape checking first, that's one of the main reasons why we have DIP1000 now. The overall goal is also clear and has been stated ([Vision/2016H2 - D Wiki](https://wiki.dlang.org/Vision/2016H2#H2_2016_Priorities)), we want memory safe code w/o the GC. -Martin
Re: Minor updates: gen-package-version v1.0.4 and sdlang-d v0.9.6
On Tuesday, 23 August 2016 at 16:19:12 UTC, Nick Sabalausky wrote: Couple very minor updates: gen-package-version v1.0.4: - Updated docs to include dub.sdl samples, not just dub.json. https://github.com/Abscissa/gen-package-version Great to see that it now works with ~/.dub/packages. What's your stance on including that functionality into dub?
Re: Simple GEdit .lang & github color scheme
Dead link (dlang gedit color highlighting) http://reign-studios.com/d-downloads/d.lang.tar.gz Would you mind uploading on github for instance ?
Re: [GSoC] std.experimental.xml is now a PR!
On Wed, 24 Aug 2016 12:00:43 +, Suliman wrote: > On Wednesday, 24 August 2016 at 10:26:53 UTC, Lodovico Giaretta wrote: >> On Wednesday, 24 August 2016 at 10:22:04 UTC, Suliman wrote: >>> Add more examples of usage please. >> >> Thank you very much for having a look. Did you see the examples at [1]? >> I don't want to add other examples to that page, it would become too >> long, but maybe I could add specific examples in the pages of the >> various modules. What do you think? >> >> [1] >> https://lodo1995.github.io/experimental.xml/std/experimental/xml.html > > IMHO is much better to attend every function with short example of it's > usage. For example: > https://lodo1995.github.io/experimental.xml/std/experimental/xml/ parser.html > it's hard to understand what it's doing. > > Not every D-people are good programmers. I'd rather say, not everyone using D learns best from specifications plus lengthy examples. Short, pithy examples work better for some. It's also easier to ensure that you have good coverage that way. For my part, I best learn the essentials from *short* examples and the details from prose. I can learn general usage from prose, but it takes me a fair bit longer for non-trivial things (especially when it makes heavy use of templates). I can learn details from examples, but it's much slower. This isn't a lack of programming skill on my part. It's just, I'm a human, so I'm good at pattern matching.
Re: [GSoC] std.experimental.xml is now a PR!
On Wednesday, 24 August 2016 at 12:00:43 UTC, Suliman wrote: On Wednesday, 24 August 2016 at 10:26:53 UTC, Lodovico Giaretta wrote: [...] IMHO is much better to attend every function with short example of it's usage. For example: https://lodo1995.github.io/experimental.xml/std/experimental/xml/parser.html it's hard to understand what it's doing. Not every D-people are good programmers. A lot of people prefer to look at example to understand what function is doing. And if it's good just copy-past ready to use code. Understood, you are right. I'll work on this. Thank you.
Re: [GSoC] std.experimental.xml is now a PR!
On Wednesday, 24 August 2016 at 10:26:53 UTC, Lodovico Giaretta wrote: On Wednesday, 24 August 2016 at 10:22:04 UTC, Suliman wrote: Add more examples of usage please. Thank you very much for having a look. Did you see the examples at [1]? I don't want to add other examples to that page, it would become too long, but maybe I could add specific examples in the pages of the various modules. What do you think? [1] https://lodo1995.github.io/experimental.xml/std/experimental/xml.html IMHO is much better to attend every function with short example of it's usage. For example: https://lodo1995.github.io/experimental.xml/std/experimental/xml/parser.html it's hard to understand what it's doing. Not every D-people are good programmers. A lot of people prefer to look at example to understand what function is doing. And if it's good just copy-past ready to use code.
Re: [GSoC] std.experimental.xml is now a PR!
On Wednesday, 24 August 2016 at 10:22:04 UTC, Suliman wrote: Add more examples of usage please. Thank you very much for having a look. Did you see the examples at [1]? I don't want to add other examples to that page, it would become too long, but maybe I could add specific examples in the pages of the various modules. What do you think? [1] https://lodo1995.github.io/experimental.xml/std/experimental/xml.html
Re: [GSoC] std.experimental.xml is now a PR!
Add more examples of usage please.
[GSoC] std.experimental.xml is now a PR!
Hi! I'm pleased to announce that my GSoC project, a replacement for the outdated std.xml, is now a Phobos PR! [1] It is an (almost complete) mirror of my repository [2], which is also available on DUB [3]. I would like to thank my mentor Robert burner Schadek for his great support and everybody who already gave some feedback during these months. The PR is not meant for immediate merging. Some things still need improvement (docs/unittests/...) while others will come in a second iteration (advanced DTD handling). It is meant to for some reviews, focusing mainly on the design and usability of the library. In the PR description you will find all the details, including a nice "wishlist" of things that I found missing in D during the development and some open questions. So, if you have any consideration/suggestion, drop a line here or on the PR, and if you find bugs, don't hesitate to file an issue on the issue tracker of my repository. Thank you very much! [1] https://github.com/dlang/phobos/pull/4741 [2] https://github.com/lodo1995/experimental.xml [3] https://code.dlang.org/packages/std-experimental-xml
