Re: New Article: My Experience Porting Python Dateutil's Date Parser to D
On Wednesday, 9 March 2016 at 22:12:42 UTC, Walter Bright wrote: I haven't read the article yet, but you'll get more interest by putting a summary as the first comment on reddit. Thanks for the advice, I think it caused more people to read it. Also, I forgot to mention in the article that the unit tests with coverage reports enabled run in 110ms. I love fast tests :)
Re: New Article: My Experience Porting Python Dateutil's Date Parser to D
On Thursday, 10 March 2016 at 17:59:21 UTC, Chris Wright wrote: It's a little easier to write iterators in the Python style: you don't have to cache the current value, and you don't have to have a separate check for end-of-iteration. It's a little easier to use them in the D style: you get more flexibility, can check for emptiness without popping an item, and can grab the first item several times. I don't have any firm opinions on this, but escaping out of the loop with an exception means you don't have to check for emptiness. So I am not sure why D range-iterators should be considered easier. You can convert one to the other, so there's no theoretical difference in what you can accomplish with them. It's mainly annoying. A small efficiency concern, because throwing exceptions is a little slow. Efficiency of exceptions in Python is an implementation issue, though. But I agree that the difference isn't all that interesting. The largest practical difference comes when multiple functions are interested in viewing the first item in the same range. LL(1) parsers need to do this. Iterators and generators in Python are mostly for for-loops and comprehensions. In the rare case where you want lookahead you can just write your own or use an adapter. Of course, that's just looking at input ranges versus iterators. If you look at other types of ranges, there's a lot there that Python is missing. Is there any work done on range-iterators and streams?
Re: Hotfix release vibe.d 0.7.28
On Monday, 29 February 2016 at 07:54:09 UTC, Sönke Ludwig wrote: Am 29.02.2016 um 00:47 schrieb sigod: On Saturday, 27 February 2016 at 16:21:05 UTC, Sönke Ludwig wrote: This is a small bugfix release that mainly fixes two critical regressions: - FreeListRef!T, which is used heavily in the HTTP server code, stored its reference count in an unallocated memory region, leading to possible memory leaks or memory corruption - A TCP connection with a non-empty write buffer that got closed by the remote peer and locally at the same time could result in the calling task to starve (i.e. it got never resumed after yielding execution). In particular, this could happen when accessing HTTPS servers with the HTTP client in conjunction with "Connection: close". http://vibed.org/blog/posts/vibe-release-0.7.28 You forgot to update site header. Thanks, also forgot the documentation (even if nothing has changed). Is there any plans on when big split will happen? It will be a step-by-step process. I'm currently working on a new version of the `vibe.core` package that contains some large changes under the hood. Once that is in a functional state, I'll look into how to enable optional replacement of the existing vibe:core package by this new, separately hosted vibe-core package. vibe:core, at that point, will only receive bug fixes and continues to live for a while (let's say a year or one and a half). The same procedure will then happen for vibe:http (the new package will include HTTP/2 support) and the other sub packages. All of the new packages will get a version number of 1.0.0, once they can be considered reasonably stable. One unfortunate aspect of my current work on vibe-core is that I'm building on a new event loop abstraction that I built as a prototype to see where the performance bottlenecks of the current system are. libasync was too slow and it had a too complicated structure to make quick tests for improving performance. Now I'm leaning towards finalizing the new prototype library and proposing it for Phobos inclusion at some point. Sönke, is your current work on core available somewhere? Since my vibe.d related work isn't stable it wouldn't a problem to use unstable core-component. It is better than rewriting later if a lot of things change.
Re: unit-threaded v0.6.5 - Type-parametrized tests
On Thursday, 10 March 2016 at 16:06:38 UTC, Meta wrote: On Wednesday, 9 March 2016 at 18:01:49 UTC, Atila Neves wrote: The forum must be sick of hearing from me... :P I'm always excited for a new release of unit-threaded Thanks for the kind words! Atila
Re: Event Dispatcher
On Thursday, 10 March 2016 at 18:15:21 UTC, Adam D. Ruppe wrote: On Thursday, 10 March 2016 at 18:08:15 UTC, Eugene Wissner wrote: I haven't used vibe.d myself but I did write CGI and SCGI (and fastcgi with the help of a C lib, and an embedded http server) in my cgi.d file: https://github.com/adamdruppe/arsd/blob/master/cgi.d some dox: http://dpldocs.info/experimental-docs/arsd.cgi.html It is written in a traditional manner - no vibe, no fibers, no async. This makes a lot of things easier but it isn't as sexy. Yes, I'm aware of your code, Adam. I'm using it for reference and looking if I don't how to implement something better. Thank you for this work!
Re: Event Dispatcher
On Thursday, 10 March 2016 at 18:08:15 UTC, Eugene Wissner wrote: In the last week I looked a lot into the vibe.d and I moved to its core for handling the requests instead of my own CGI-handling. I'm currently working on implementing SCGI based on vibe.d IO I haven't used vibe.d myself but I did write CGI and SCGI (and fastcgi with the help of a C lib, and an embedded http server) in my cgi.d file: https://github.com/adamdruppe/arsd/blob/master/cgi.d some dox: http://dpldocs.info/experimental-docs/arsd.cgi.html It is written in a traditional manner - no vibe, no fibers, no async. This makes a lot of things easier but it isn't as sexy.
Event Dispatcher
Hey,
I wrote some time ago I'm working on the rewriting some parts of
Symfony web framework from PHP to D. One component is pretty
small and is already ready. It is an Event Dispatcher:
https://github.com/caraus-ecms/caraus (submodule
caraus:eventdispatcher).
Event dispatchers make it possible to write extensible
applications. You can register events in different places of your
application and attach callbacks to them. It is similar to
signals, but you have a central instance aware of all events and
callbacks (Mediator pattern:
https://en.wikipedia.org/wiki/Mediator_pattern).
It isn't very useful on its own, since the event dispatcher
should be passed everywhere but it can be used, for example,
with a DI container like poodinis. Since frameworks like
https://github.com/Skadi-d/Skadi.d had "Event Dispatcher" in its
TODO, I decided to write this Announce if something finds it
useful.
In the following lines I will only describe how it works and what
is for. You can find the example I describe here:
https://github.com/caraus-ecms/caraus/blob/master/examples/eventdispatcher/source/app.d
We want to extend a hello world program:
import std.stdio;
class HelloWorld
{
void hello()
{
writeln("Hello world!");
}
}
void main()
{
auto helloWorld = new HelloWorld;
helloWorld.hello();
}
We want that people can attach their own messages before "Hello
world!" or after it. We initialize the EventDispatcher in the
class using it:
dispatcher = new EventDispatcher;
and then attach events like this:
dispatcher.dispatch("postHello");
The last step is to register callbacks to this event:
dispatcher.addListener("postHello", delegate(Event e, string
eventName, EventDispatcher dispatcher) {
writeln("Bye!");
});
Everything together:
import caraus.eventdispatcher.dispatcher;
import caraus.eventdispatcher.event;
import std.functional;
import std.stdio;
class HelloWorld
{
EventDispatcher dispatcher;
this()
{
dispatcher = new EventDispatcher;
}
void hello()
{
writeln("Hello world!");
dispatcher.dispatch("postHello");
}
}
void main()
{
auto helloWorld = new HelloWorld;
helloWorld.dispatcher.addListener("postHello", delegate(Event e,
string eventName, EventDispatcher dispatcher) {
writeln("Bye!");
});
helloWorld.hello();
}
Now you should get:
Hello world!
Bye!
Why not just extend the HelloWorld class and override the
hello()? Imagine you write an apllication that should support
plugins. And two independent plugins extend the HelloWorld. One
plugin would conflict with the another. EventDispatcher make it
possible to register the events that can be used by application
plugins.
Note: If someone wonder about the whole web framework I
mentioned. In the last week I looked a lot into the vibe.d and I
moved to its core for handling the requests instead of my own
CGI-handling. I'm currently working on implementing SCGI based on
vibe.d IO. And I already have a simple web page of a customer
running on it (ok, it is a single page website, but it is already
something :))
Enjoy. Or like people say on this forum: Destroy.
Re: New Article: My Experience Porting Python Dateutil's Date Parser to D
On Thu, 10 Mar 2016 08:22:58 +, Ola Fosheim Grøstad wrote: > On Thursday, 10 March 2016 at 00:29:46 UTC, Jack Stouffer wrote: >>> It's a pretty straight forward standard iterator design and quite >>> different from the table pointers C++ uses. >> >> I explain my grievances in the article. > > They didn't make all that much sense to me, so I wondered what Theo's > issues were. As in: real issues that have empirical significance. It's a little easier to write iterators in the Python style: you don't have to cache the current value, and you don't have to have a separate check for end-of-iteration. It's a little easier to use them in the D style: you get more flexibility, can check for emptiness without popping an item, and can grab the first item several times. You can convert one to the other, so there's no theoretical difference in what you can accomplish with them. It's mainly annoying. A small efficiency concern, because throwing exceptions is a little slow. The largest practical difference comes when multiple functions are interested in viewing the first item in the same range. LL(1) parsers need to do this. Of course, that's just looking at input ranges versus iterators. If you look at other types of ranges, there's a lot there that Python is missing.
Re: unit-threaded v0.6.5 - Type-parametrized tests
On Wednesday, 9 March 2016 at 18:01:49 UTC, Atila Neves wrote: The forum must be sick of hearing from me... :P I'm always excited for a new release of unit-threaded
Re: code-debug 0.6.0 released (GDB & LLDB for vscode)
On Tuesday, 8 March 2016 at 00:23:55 UTC, Manu wrote: I've tried out code-d, but it only seems to do anything useful with dub. None of my projects use dub. Every project I have combines C/C++/D, and dub is an insufficient build system. I can configure vscode projects to invoke my builds, but code-d doesn't have any project metadata to work with in that context. Can you work code-d to get its necessary working state from explicit variables in the vscode project file? If you use some other common build system you can include it into workspace-d as alternative backend and code-d will be able to use it by just changing a few lines Otherwise just do what the others said and add pre/postLaunchScripts Might aswell add a custom format just for the IDE containing just the file informations or implement visualD, monoD and all those other IDE formats
Re: Argon: an alternative parser for command-line arguments
On Wednesday, 9 March 2016 at 18:56:10 UTC, Markus Laker wrote: On Saturday, 5 March 2016 at 16:28:25 UTC, karabuta wrote: I think he meant: [git status --help], where you have three attributes with the last one being the flag. So in addition to: [status --help] by default, you also have: [git status --help] to get help on status only. Argon doesn't directly support subcommands. That probably stems from a bias of mine: that subcommands make it harder for the author to parse the command and to generate good error messages, and also that they make it harder for users to use unfamiliar commands, because users must read a man page that documents eleven things they have no interest in doing just to get to the one thing that they need to do in order to get on with their day. At work, where I have written and I still maintain many hundreds of commands, I've moved away from subcommands completely: every operation gets a command of its own. But I know that not everyone agrees with me, and that's OK. If we want to debate this topic further, we should probably move the discussion from Announce to General. .. It shouldn't be hard to write some reusable code to do this, if it were a common requirement. I don't like subcommands myself. That's why Linux is such as mess with so much inconsistencies.
Re: unit-threaded v0.6.5 - Type-parametrized tests
On Thursday, 10 March 2016 at 08:09:40 UTC, Jacob Carlborg wrote:
On 2016-03-09 19:01, Atila Neves wrote:
The forum must be sick of hearing from me... :P For those not
in the
know, unit-threaded is an advanced unit testing library for D:
http://code.dlang.org/packages/unit-threaded
The v0.6.3 release had tests parametrized by value; this
v0.6.5 release
brings with it the possibility of parametrizing tests by type,
like so:
@Types!(int, byte)
void testInit(T)() {
assert(T.init == 0);
}
This will run the testInit code twice, once for each type, and
report
them as separate tests:
tests.pass.attributes.testInit.int:
tests.pass.attributes.testInit.byte:
I've literally only written that silly testInit example yet.
But imagine
how easy it'd be to test, say, different input ranges.
I'm thinking of ways of getting the parametrized tests to work
with the
built-in unittest blocks. I assume it'll be hacky. Right now
it's the
only thing that requires non-standard test functions and I'm
trying to
augment the existing unit testing features of D instead of
replacing them.
Do you have a slightly more extended example that shows how
this is used?
No, sorry. I haven't needed it yet. Something like this?
@Types!(int, string)
void testArray(T)() {
import std.container;
auto arr = Array!T();
arr.empty.shouldBeTrue;
arr.insertBack(T.init);
arr.empty.shouldBeFalse;
auto l = arr.length;
l.shouldEqual(1);
}
Atila
Re: unit-threaded v0.6.5 - Type-parametrized tests
On Thursday, 10 March 2016 at 09:33:39 UTC, Iakh wrote:
On Wednesday, 9 March 2016 at 18:01:49 UTC, Atila Neves wrote:
@Types!(int, byte)
void testInit(T)() {
assert(T.init == 0);
}
Atila
It is not clear that this UDA is about unittesting
Even when attached to a test function?
Atila
Re: unit-threaded v0.6.5 - Type-parametrized tests
On Wednesday, 9 March 2016 at 18:01:49 UTC, Atila Neves wrote:
@Types!(int, byte)
void testInit(T)() {
assert(T.init == 0);
}
Atila
It is not clear that this UDA is about unittesting
Re: New Article: My Experience Porting Python Dateutil's Date Parser to D
Just pointing out the obvious: For the simple iterators/generators that run on a non-changing source you can basically break it up into: 1. iterators without lookahead 2. iterators with lookahead Which is basically the same issues you deal with when implementing a lexer. Python-style iterators/generators is basically the former. That comes with one set of advantages, but no lookahead. But lookahead frequently have cost penalties. There are many tradeoffs. And those tradeoffs become rather clear when you consider factors like: 1. mutating iterators 2. the size of the object 3. copyable iterators 4. concurrency/thread safety 5. progress with high computational cost 6. high computational cost for the value 7. sources with latency 8. skip functionality 7. non-inlineable situations 8. exceptions 9. complex iterators (e.g. interpolation) etc There are massive tradeoffs even when writing iterators for really simple data-structures like the linked list. It all depends on what functionality one are looking for. There is no best solution. It all depends on the application.
Re: New Article: My Experience Porting Python Dateutil's Date Parser to D
On Thursday, 10 March 2016 at 00:29:46 UTC, Jack Stouffer wrote: It's a pretty straight forward standard iterator design and quite different from the table pointers C++ uses. I explain my grievances in the article. They didn't make all that much sense to me, so I wondered what Theo's issues were. As in: real issues that have empirical significance. D ranges and Python's are regular iterators, nothing special. The oddball are C++ "iterators" that are pairs of pointers. Efficiency and semantic issues when it comes to iterator-implementation go both ways all depending on the application area. This is nothing new. People have known this for ages, as in decades. If you want fast you have to use a "next" iterator-implementation writing multiple elements directly to the buffer. This is what you do in signal processing.
Re: unit-threaded v0.6.5 - Type-parametrized tests
On 2016-03-09 19:01, Atila Neves wrote:
The forum must be sick of hearing from me... :P For those not in the
know, unit-threaded is an advanced unit testing library for D:
http://code.dlang.org/packages/unit-threaded
The v0.6.3 release had tests parametrized by value; this v0.6.5 release
brings with it the possibility of parametrizing tests by type, like so:
@Types!(int, byte)
void testInit(T)() {
assert(T.init == 0);
}
This will run the testInit code twice, once for each type, and report
them as separate tests:
tests.pass.attributes.testInit.int:
tests.pass.attributes.testInit.byte:
I've literally only written that silly testInit example yet. But imagine
how easy it'd be to test, say, different input ranges.
I'm thinking of ways of getting the parametrized tests to work with the
built-in unittest blocks. I assume it'll be hacky. Right now it's the
only thing that requires non-standard test functions and I'm trying to
augment the existing unit testing features of D instead of replacing them.
Do you have a slightly more extended example that shows how this is used?
--
/Jacob Carlborg
