Re: sample collaborative notepad implementation
Mengu wrote: dude, didn't know you were sitting on a gold mine (iv). thanks for sharing! you're welcome. if you need something other than GPL on some modules, this is usually negotiable (for free ;-).
Re: sample collaborative notepad implementation
On Thursday, 12 October 2017 at 01:43:00 UTC, ketmar wrote: in the wootedit repo[0] you can find a very simple (but working) collaborative notepad implementation, based on WOOT algorithm[1][2]. if you ever wanted to know how all those collaborative editors were done... look no further! ;-) wootedit is simple, but complete implementation of such editor, with UDP-based network communication. currently, it was tested under GNU/Linux only, but there are no platform-specific code (except some socket API), so porting it to another OS should be trivial. you will need IV[3] and ARSD[4] libraries to build wootedit. [0] http://repo.or.cz/wootedit.git [1] http://hal.inria.fr/inria-00071240/ [2] https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type [3] http://repo.or.cz/iv.d.git [4] https://github.com/adamdruppe/arsd dude, didn't know you were sitting on a gold mine (iv). thanks for sharing!
Books Suggest
http://www.kcedventures.com/blog/finding-free-kids-books-online-books-for-kids https://bestbooks-ofalltime.blogspot.ca/2017/08/best-novels-2016.html https://www.goodreads.com/genres/horror
Re: iopipe alpha 0.0.1 version
On 10/13/17 11:59 AM, Martin Nowak wrote: On Thursday, 12 October 2017 at 04:22:01 UTC, Steven Schveighoffer wrote: I added a tag for iopipe and added it to the dub registry so people can try it out. I didn't want to add it until I had fully documented and unittested it. http://code.dlang.org/packages/iopipe https://github.com/schveiguy/iopipe Great news to see continued work on this. I'll just use this thread to get started on design discussions. If there is there a better place for that, let me know ;). This is as good a place as any :) I may create some issue reports on github to track things better. Questions/Ideas - You can move docs out of the repo to fix search, e.g. by pushing them to a `gh-pages` branch of your repo. When I tried the search it seemed to work... See https://github.com/MartinNowak/bloom/blob/736dc7a7ffcd2bbca7997f273a09e272e0484596/travis.sh#L13 for an automated setup using Travis-CI and ddox/scod. I admit complete ignorance on this, I need to look into it, but at the moment, I'm OK with committing the generated docs directly as an ugly extra step. When I looked at the options under adding a "pages" piece for the project that if I put things under "docs" directory, it could use that, so that's what I went with. - Standard device implementation? You library already has the notion of devices as thin abstractions over file/socket handles. Should we start with such an unbuffered IO library as foundation including support hooks for Fiber based event loops. Something along the lines of https://code.dlang.org/packages/io? Without a standard device lib, IOPipe could not be used in APIs. I absolutely think this would be a great idea. In fact, you could use Jason White's io package with iopipes directly, as his low-level types have the necessary read function: https://github.com/jasonwhite/io/blob/master/source/io/file/stream.d#L335 Perhaps we could coax the basic types out of that library to provide a base for both iopipe and his high-level stuff. The stream portion of my library is really just a throwaway piece that is not a focus of the library. Indeed, I created it because unbuffered stream types didn't exist anywhere (the IODev type predates iopipe, as it was part of my original attempt to rewrite Phobos io). - What's the plan for @safe buffer/window invalidation, right now you're handing out raw access to internal buffers with an inherent memory safety problem. I don't plan to put any restrictions on this. In fact the core purpose of iopipe is to give raw buffer access to aid in writing higher-level routines around it. As I said here: https://github.com/schveiguy/iopipe/blob/master/source/iopipe/buffer.d#L217 If the Allocator supports deallocation I call it, but it may not be the correct thing to do. There is a sticky point in std.experiemental.allocator: the GC allocator defines deallocate, because it's available, but the *presence* of that member may be taken to mean you have to call it to deallocate. There is no member saying whether deallocation is optional. In my wrapper GCNoPointerAllocator (which I needed to support allocating ubyte buffers without having to scan them), I leave out the deallocate function, so technically it's @safe with that allocator. I will say though, at some point, I'm going to focus on making @safe as much as possible in iopipe. That may require using the GC for buffering. ```d auto w = f.window(); f.extend(random()); w[0]; // ⚡ dangling pointer ⚡ ``` I can see how the compiler could catch that if we'd go with compile-time enforced safety for RC and friends. But that's still unclear atm. and we might end up with a runtime RC/weak ptr mechanism instead, which wouldn't be too good a fit for that window mechanism. 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. - What about the principle that the caller should choose allocation/ownership? It can, BufferManager takes an Allocator compile-time option. It's also possible to create your own ownership or allocation scheme as long as you implement the required iopipe methods. Having an extend methods means the IOPipe is responsible for growing/allocating buffers, so you'll end up with IOPipeMalloc, IOPipeGC, IOPipeAllocatorGrowExp (or their template alternatives), not very nice for APIs. extend is a core part of the iopipe system. The point of the library is that you don't have to manage the buffering or allocation of your higher-level code in terms of memory ownership or
Re: iopipe alpha 0.0.1 version
On 10/13/17 12:49 PM, Martin Nowak wrote: On Thursday, 12 October 2017 at 18:08:11 UTC, Steven Schveighoffer wrote: Release 0.0.2 has fixes for the ddoc that I didn't notice before, there are no actual changes in the code. May I recommend scod? It's just a ddox theme. https://github.com/MartinNowak/scod I keep https://github.com/MartinNowak/bloom also as example/scaffold repo, it's using an automated docs setup with gh-branches. Just create a doc deployment token (https://github.com/settings/tokens) with public_repo access and store that encrypted in your .travis-ci.yml. Martin, I would appreciate and I think many people would, a blog/tutorial on how to do this. I'll look into your suggestions on the docs, thanks! -Steve
Re: iopipe alpha 0.0.1 version
On Thursday, 12 October 2017 at 18:08:11 UTC, Steven Schveighoffer wrote: Release 0.0.2 has fixes for the ddoc that I didn't notice before, there are no actual changes in the code. May I recommend scod? It's just a ddox theme. https://github.com/MartinNowak/scod I keep https://github.com/MartinNowak/bloom also as example/scaffold repo, it's using an automated docs setup with gh-branches. Just create a doc deployment token (https://github.com/settings/tokens) with public_repo access and store that encrypted in your .travis-ci.yml.
Re: iopipe alpha 0.0.1 version
On Thursday, 12 October 2017 at 04:22:01 UTC, Steven Schveighoffer wrote: I added a tag for iopipe and added it to the dub registry so people can try it out. I didn't want to add it until I had fully documented and unittested it. http://code.dlang.org/packages/iopipe https://github.com/schveiguy/iopipe Great news to see continued work on this. I'll just use this thread to get started on design discussions. If there is there a better place for that, let me know ;). Questions/Ideas - You can move docs out of the repo to fix search, e.g. by pushing them to a `gh-pages` branch of your repo. See https://github.com/MartinNowak/bloom/blob/736dc7a7ffcd2bbca7997f273a09e272e0484596/travis.sh#L13 for an automated setup using Travis-CI and ddox/scod. - Standard device implementation? You library already has the notion of devices as thin abstractions over file/socket handles. Should we start with such an unbuffered IO library as foundation including support hooks for Fiber based event loops. Something along the lines of https://code.dlang.org/packages/io? Without a standard device lib, IOPipe could not be used in APIs. Easy enough to write, could be written over a weekend. - What's the plan for @safe buffer/window invalidation, right now you're handing out raw access to internal buffers with an inherent memory safety problem. ```d auto w = f.window(); f.extend(random()); w[0]; // ⚡ dangling pointer ⚡ ``` I can see how the compiler could catch that if we'd go with compile-time enforced safety for RC and friends. But that's still unclear atm. and we might end up with a runtime RC/weak ptr mechanism instead, which wouldn't be too good a fit for that window mechanism. - What about the principle that the caller should choose allocation/ownership? Having an extend methods means the IOPipe is responsible for growing/allocating buffers, so you'll end up with IOPipeMalloc, IOPipeGC, IOPipeAllocatorGrowExp (or their template alternatives), not very nice for APIs. - Why continuous memory? The current implementations reallocs and even weirder memmoves data in extend. https://github.com/schveiguy/iopipe/blob/3589a4c9fc72b844eb4efd3ae718773faf9ab9ed/source/iopipe/buffer.d#L171 Shouldn't a modern IO library be as zero-copy as possible? The docs say random access, that should be supported by ringbuffers or lists/arrays of buffers. Any plans towards that direction?
Re: Diamond MVC / Template Engine - v2.0.4 Released
On Friday, 13 October 2017 at 07:23:03 UTC, bauss wrote: On Friday, 13 October 2017 at 07:16:14 UTC, bauss wrote: So I finally got around having time in my life to work with Diamond, which also meant fixing a few things in it, such as making it compatible with the latest version of DMD. Version 2.0.4 includes the following additions: I apologize; it's supposed to be version 0.2.4 I noticed a mistake again that I did with previous version "0.2.32" of course it wouldn't make "0.2.4" latest version, because 32 is above 4. So I have updated the version to 0.3.0, which I probably should have made it originally.
Re: Diamond MVC / Template Engine - v2.0.4 Released
On Friday, 13 October 2017 at 07:16:14 UTC, bauss wrote: So I finally got around having time in my life to work with Diamond, which also meant fixing a few things in it, such as making it compatible with the latest version of DMD. Version 2.0.4 includes the following additions: I apologize; it's supposed to be version 0.2.4
Diamond MVC / Template Engine - v2.0.4 Released
So I finally got around having time in my life to work with Diamond, which also meant fixing a few things in it, such as making it compatible with the latest version of DMD. Version 2.0.4 includes the following additions: * Support for escaped expressions using @$=expression; * Compiles with latest version of DMD (Fixed an issue with compile-time AA's) * New view functionality for rendering (View the wiki for more information.) * Redirection functionality for controllers (View the wiki for more information.) Github: https://github.com/bausshf/Diamond Dub: https://code.dlang.org/packages/diamond (Currently waiting for the registry to update, so manual fetches from Github are required until the registry updates to 2.0.4 -- been waiting the past 2 hours or so and it seems like the registry has some issues atm. so hopefully that's fixed soon.) Previous releases can be found here: https://github.com/bausshf/Diamond/releases -- To people who hasn't seen this project before -- What is Diamond? Diamond is a MVC / Template library written in Diamond. It was written originally as an alternative to the Diet templates in vibe.d, but now its functonality and capabilities are far beyond templating only. What does Diamond depend on? Diamond can be used stand-alone without depending on any third-party libraries, other than the standard library Phobos. It has 3 types of usage, websites and webservices, where it's used on-top of vibe.d and as a stand-alone mvc/template library. What is the dependency to vibe.d? Diamond was originally written to be used in a hobby project as an alternative syntax to the "standard" diet templates. Thus it was originally build on-top vibe.d as a pure website template. It has now evolved to be able to run stand-alone however. What syntax does Diamond use? Diamond is heavily inspired by the ASP.NET razor syntax, but still differs a lot from it. You can read more about that in the wiki under Syntax Reference or the comparison with ASP.NET Razor What advantages does Diamond have over Diet? It let's you control the markup entirely, can be integrated with any-type of D code, not limited to vibe.d and can be used as standard template library for any type of project such as email templates etc. It also allows for special rendering, easy controller implementations and management of request data, response etc.
