Re: photon v0.7.0 with Windows support(!)

[Sönke Ludwig via Digitalmars-d-announce]

Am 21.04.2024 um 21:01 schrieb Dmitry Olshansky:
Photon is a minimalistic multi-threaded fiber scheduler and event loop 
that works transparently with traditional blocking I/O C/C++/D/Rust 
libraries w/o degrading performance.


It took somewhat longer than I wanted but I'm pleased to announce that 
Photon now supports Windows. In particular basic socket API that is used 
by the likes of std.socket is transparently converted to overlapped I/O 
with I/O completion port event loop. The last obstacle was, of course, 
accept syscall that is only blocking on Windows. Now that transparently 
goes to a dedicated Windows's native threadpool so as to not block our 
precious fibers.


Explore some basic examples here (not all examples can be run on 
Windows): https://github.com/DmitryOlshansky/photon/tree/master/tests


--
Dmitry Olshansky
CEO @ Glowlabs
https://olshansky.me


That's really nice! How would you judge supporting other kinds of 
handles, such as files or events, on Windows?


I guess that the Darwin support will be restricted to freely distributed 
macOS applications, as calling `__syscall` surely is a private API that 
cannot be used in any AppStore application, right? In that case it would 
inevitably put it in a non-consumer application niche, but certainly 
wouldn't make it any less interesting for more server oriented tasks.

Re: Beta 2.108.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 16.03.2024 um 11:31 schrieb Daniel N:

```d
union U
{
     float asFloat;
     uint asInt;
}

auto u0 = U(1.0); // this sets the `asFloat` field
auto u1 = U(asInt: 0x3F80); // formerly not possible
```

Wow, this is so cool, can't wait to try it out, thanks to everyone who 
made it happen!




Note that this has already been possible in places where the {} syntax 
can be used:


auto u1 = {asInt: 0x3F80};

Still great to see this officially implemented!

Re: Released vibe.d 0.10.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 19.02.2024 um 19:28 schrieb aberba:
On the tutorials section of the vibed.org site, the are links to 
tutorials on my website (aberba.com) however I recently rebuilt my 
website and the links will need adjustment. I can't however find where 
the make a PR for that.


The tutorials are listed here: 
https://github.com/vibe-d/vibed.org/blob/master/views/tutorials.dt

Re: Released vibe.d 0.9.8

[Sönke Ludwig via Digitalmars-d-announce]

Am 19.02.2024 um 00:48 schrieb aberba:

On Friday, 16 February 2024 at 17:17:35 UTC, Sönke Ludwig wrote:
Just a quick announcement for a new vibe.d release that, probably most 
notably, gets rid of most DIP1000 related... as well as requiring REST 
interfaces to be fully @safe.


How does this affect regular code? What are the implications?


Generally speaking, what has been a `pragma(msg)` based deprecation 
warning during the build for a long time already, now has become a hard 
error (`static assert(false)`). The error should come with the template 
instantiation chain and thus should make it simple to pinpoint the piece 
of code that is `@system`.


The concrete implications are that all interface methods passed to 
`registerRestInterface` must be annotated with `@safe`, as well as all 
functional attributes (`@before`/`@after`) and all serialized types that 
are part of the interface (e.g. the `toJson`/`fromJson` methods of a 
custom struct that gets returned from an interface function).

Released vibe.d 0.10.0

[Sönke Ludwig via Digitalmars-d-announce]

The next release of vibe.d (0.10.0) is expected to land sooner than 
usual and will contain a substantial restructuring of the package 
structure. All low level modules that are currently sub packages of 
"vibe-d" will be broken out to separate standalone packages, as well as 
the "vibe-d:http" package. This will pave the way for *finally* being 
able to work towards integrating the work on a HTTP/2 implementation 
that was carried out by Francesco Galla during SAoC 2018.


0.10.0 is now out and is identical to 0.9.8, apart from the new package 
structure: https://vibed.org/blog/posts/vibe-release-0.10.0


Compatibility with the old structure is still there, but will get 
deprecated in one of the next releases, so a dependency like 
"vibe-d:http" 0.9.x should eventually be adjusted to "vibe-http" 1.x.x.

Released vibe.d 0.9.8

[Sönke Ludwig via Digitalmars-d-announce]

Just a quick announcement for a new vibe.d release that, probably most 
notably, gets rid of most DIP1000 related deprecation warnings. It also 
brings two breaking changes in the form of deprecating 
vibe.utils.hashmap in favor of the new vibe-container package, as well 
as requiring REST interfaces to be fully @safe.


There is also a bunch of smaller additions and fixes, as listed in the 
change log: https://vibed.org/blog/posts/vibe-release-0.9.8


Although it follows a different version track, vibe-core has also 
received some notable changes during this time frame, such as heavily 
improved performance of ManualEvent, which is the basis for all 
synchronization primitives, a new performInWorker function, 
TaskSemaphore, Monitor!T, yieldUninterruptible and a dedicated thread 
pool for I/O operations.


The next release of vibe.d (0.10.0) is expected to land sooner than 
usual and will contain a substantial restructuring of the package 
structure. All low level modules that are currently sub packages of 
"vibe-d" will be broken out to separate standalone packages, as well as 
the "vibe-d:http" package. This will pave the way for *finally* being 
able to work towards integrating the work on a HTTP/2 implementation 
that was carried out by Francesco Galla during SAoC 2018.

Re: Blog post: How we are using D to develop Aspect from the ground up

[Sönke Ludwig via Digitalmars-d-announce]

Am 24.10.2023 um 03:10 schrieb Vladimir Marchevsky:

On Monday, 23 October 2023 at 19:02:46 UTC, Sönke Ludwig wrote:
Any suggestions of what might be especially interesting/impactful are 
of course welcome!


I'd vote for...

Vibe.d in particular allowed us to go with a very interesting approach 
for handling GUI and I/O, as well as computationally inexpensive 
concurrency, all seamlessly together within a single thread.


I'll keep that in mind, seems to fit well with the chronological order 
of events, too.

Re: New WIP DUB documentation

[Sönke Ludwig via Digitalmars-d-announce]

Am 18.08.2022 um 12:23 schrieb Bastiaan Veelo:

## Hacking on a local copy of a package

If your project depends on a package in which you have found a problem, 
or you would like to experiment with changes to it, you can force Dub to 
use a local copy of the package by following these steps:


1. Fork the git repository
2. Check out a local clone at `/path/to/the_package`
3. Let Dub know about it:
    `dub add-local /path/to/the_package`
4. Make Dub ignore any configured release tag, so you'll see the effect 
of current changes:

    `dub add-override the_package * /path/to/the_package`

Now you can go ahead and play. Once your PR has been merged and 
released, or you want to revert to upstream, undo your changes by


5. `dub remove-local /path/to/the_package`
6. `dub remove-override the_package *`


If have a branch checked out whose latest version tag matches the 
version selected by your main project, you can skip the `add-override` 
step, as dub will prefer a repository added with `add-local` over cached 
ones from the registry.


Also, using `add-path` on the parent directory allows you to clone and 
delete repositories at will, without having to use `add-local` and 
`remove-local` each time individually.

Re: New WIP DUB documentation

[Sönke Ludwig via Digitalmars-d-announce]

Looking good, having SDL+JSON on the same page is especially nice and 
something I've been wanting to fix for a while. Also definitely a good 
idea to use a static generator now that the documentation is separate.


One question, though - do you generate the CLI documentation from the 
DUB sources, or is that manual work?

Re: my d blog has idea of effect system to replace @nogc etc

[Sönke Ludwig via Digitalmars-d-announce]

Am 15.08.2022 um 17:08 schrieb Adam D Ruppe:
In my blog this week, I described an idea I've had percolating in my 
brain for a bit about a user-defined effect system that could 
potentially move nogc, safe, pure, etc to library aliases - which would 
let you combine them as a fun bonus - among other things:


http://dpldocs.info/this-week-in-d/Blog.Posted_2022_08_15.html

Like with other inferred attributes, the argument-dependent and virtual 
function caveats had to be mentioned, but since I talked about them in 
other posts not too long ago I didn't want to go over it all again.


That would be really nice to have. I also had a similar idea in my mind 
for a while, with lots of potential use cases that came up in the past.


The most prominent example would be something like vibe.d's `@blocking`, 
which currently just acts as documentation, but would be really useful 
if something like `@nonblocking` could actually be enforced at compile 
time - currently there is just a runtime solution for that.

Re: requests 2.0.0 release

[Sönke Ludwig via Digitalmars-d-announce]

Am 30.10.2020 um 14:40 schrieb Andre Pany:

On Friday, 30 October 2020 at 13:34:24 UTC, Jacob Carlborg wrote:

On Thursday, 29 October 2020 at 06:42:54 UTC, ikod wrote:

Hi,

requests 2.0.0 released with single change - support for vibe-d moved 
to separate subpackage.


The goal of this update is to prevent dub from downloading vibe-d 
packages for optional subConfiguration.


Another approach is to check if vibe.d is available using version 
conditions [1]. This is how the DDB [2] package supports both vibe.d 
sockets and Phobos sockets.


[1] 
https://github.com/pszturmaj/ddb/blob/97bc3652b05492e7917888c92e59f4576a69dfa8/source/ddb/postgres.d#L189-L216 


[2] https://code.dlang.org/packages/ddb

--
/Jacob Carlborg


The important point here is, fetching and building "requests" does no 
longer trigger downloads of vibe.d packages.
This is the case for ddb(?). Therefore I see the pattern "requests" is 
using, is also highly interesting for ddb.


Kind regards
Andre


ddb marks the vibe-d dependency as optional, so it *should* not trigger 
a download by itself.

Re: Computing the next SemVer for dlang packages with dsemver

[Sönke Ludwig via Digitalmars-d-announce]

Am 22.10.2020 um 17:50 schrieb Sönke Ludwig:
with the drawback that there is no supported means to still provide 
something like a distinction between breaking (x) and non-breaking (y) 
changes.
* with supported I mean that you can use `~>0.x.y` to restrict to a 
certain x, which would be less obvious for something like 1.0.0-alpha.x.y.

Re: Computing the next SemVer for dlang packages with dsemver

[Sönke Ludwig via Digitalmars-d-announce]

Am 22.10.2020 um 10:59 schrieb Robert burner Schadek:

On Wednesday, 21 October 2020 at 17:55:00 UTC, Sönke Ludwig wrote:

0.x.y vs. 1+.x.y is about the development process/state. Quite often a 
design is not yet fully fleshed out in the beginning and there are 
many incremental changes to the API. If 0.x.y didn't exist, that would 
simply mean that either the project gets more or less stuck with the 
initial (bad) design, or that it quickly increments major versions, 
effectively providing no more stability as in the 0.x.y case.


I think that is the one mistake SemVer does. 0.x.y is just one big 
loophole.
After the 1.x.y release an breaking api change requires a major version 
increment.

The way it should be. Stability or unstable is only mentioned in the 0.x.y
definitions.

You are not stuck on a bad design, break the api, improve the api, 
increment the major version number.

If you break the api in an 0.x.y version the hard part does not change.
In both instances the users have to update their usage.

In know in theory 0.x.y should be considered unstable. But by amount of 
0.x.y we have you pretty much can't get anything done in D if you only 
use stable packages.

The loophole has become the normal case.

So what can we do, I see two major options:
1. we can live on the edge and use unstable packages and have no meaning 
in the

    SemVer number
2. we can acknowledge that most of them are stable, put a 1. in front 
and ignore
    the 0.x.y part of the SemVer definition and have the SemVer mean 
something


dsemver does 2.

And true there might be cases where dsemver does not increment the 
number correctly, but you can always increment by hand.


Also if your api is not stable after your 1.x.y release and you break 
everything in 2.x.y, so what. Your users are also annoyed when you break 
your api from 0.1.x to 0.1.1. Only difference is they could have seen in 
coming by looking at the SemVer.


I should stop ranting now.



The real alternative to 0.x.y is 1.0.0-alpha.1+, though, with the 
drawback that there is no supported means to still provide something 
like a distinction between breaking (x) and non-breaking (y) changes.


There is also value in having some kind of indicator that the code has 
reached a certain level of maturity (1.0.0).

Re: Computing the next SemVer for dlang packages with dsemver

[Sönke Ludwig via Digitalmars-d-announce]

Am 21.10.2020 um 17:34 schrieb Robert burner Schadek:

On Wednesday, 21 October 2020 at 15:27:46 UTC, Sönke Ludwig wrote:

However, I definitely don't see this as a potential feature of the 
registry in the sense that it automatically creates new versions for 
all packages.


That is why I said in an ideal world and baby steps.


The thing is just that I don't think it is possible to find a set of 
rules that always work. There will always be something that should 
"obviously" be flagged as a breaking change and something that is 
extremely annoying to be detected as such (forcing a major version 
increment).


But as some kind of warning/hint and with some kind of integration into 
the version tagging process (maybe forcing a manual version release on 
the registry after warnings come up) it could definitely be really nice.




Also, dsemver does not call git yet to create the new tag.

Re: Computing the next SemVer for dlang packages with dsemver

[Sönke Ludwig via Digitalmars-d-announce]

Am 21.10.2020 um 17:41 schrieb Guillaume Piolat:

On Wednesday, 21 October 2020 at 14:47:14 UTC, Robert burner Schadek wrote:
Semantic versioning is useful, but 0.x.x versioning is a pointless 
loophole. When a piece of D software is published, and it is published 
if other people can find it on dub, it is released. And released means 
1.0.0 at least.


Agree. Or we won't ever have a dependable ecosystem. Please provide 
guarantees.

Success of D is success of building upon the ecosystem of libraries.

Something that people must consider to avoid too much major version tags 
is:

- delay breaking changes and pack the breaking change at once
- **have a small (and agreeable) public API surface**, use private and 
package identifier that are allowed to change spec
- provide a changelog to go from a major to another major tag, no one 
want to read your git commits
- a system of option using `version` identifier to make something 
similar to DMDFE's -preview. Configuration to gain compat at the expense 
of simplicity (option count can grow wildly).


0.x.y vs. 1+.x.y is about the development process/state. Quite often a 
design is not yet fully fleshed out in the beginning and there are many 
incremental changes to the API. If 0.x.y didn't exist, that would simply 
mean that either the project gets more or less stuck with the initial 
(bad) design, or that it quickly increments major versions, effectively 
providing no more stability as in the 0.x.y case.


But otherwise I agree, there are definitely quite a few projects that 
are beyond this stage and should make the jump to 1.0.0 (a few of mine 
included).

Re: Computing the next SemVer for dlang packages with dsemver

[Sönke Ludwig via Digitalmars-d-announce]

Am 21.10.2020 um 16:47 schrieb Robert burner Schadek:

https://code.dlang.org/packages/dsemver

is a program that computes the next SemVer for your dlang package.

It uses a slightly modified SemVer definition.

It does this by using the -X flag for dmd to get a json file of the symbols
and then compares them to the most recent git tag that resembles a SemVer.

First release is 1.0.0.
If a symbol is removed or its signature changed the major version is 
increment

and the minor and the bugfix number reset to 0.
If a new symbol is added, the minor number is incremented and the bug fix
number is set to 0.
If all symbol stay the same the bugfix number is incremented.

In an ideal world the dub registry would use this to compute the SemVer 
for you,

but baby steps.

I hope to see many bug reports and PRs.


There are cases where a symbol change is not a breaking change in 
practice (maybe splitting up a function into two separate overloads) and 
where no symbol change is required to produce a real breaking change 
(e.g. a compile-time logic change within some template). In my 
experience it is often a judgement call where to draw the line, even 
sometimes deciding between a patch release and a major release.


Of course, theoretically *any* change that is not backed by a 
preexisting specification is a breaking change in one way or another, 
especially when D's introspection or runtime behavior come into play...


Anyway, I think this can be a very useful diagnostic tool to avoid 
accidental introduction of breaking changes at that level, and maybe 
also to actually generate new versions in certain contexts. However, I 
definitely don't see this as a potential feature of the registry in the 
sense that it automatically creates new versions for all packages.

Re: code.dlang.org reliability update

[Sönke Ludwig via Digitalmars-d-announce]

Am 04.03.2020 um 20:06 schrieb WebFreak001:

On Monday, 2 March 2020 at 19:17:59 UTC, Sönke Ludwig wrote:
As of yesterday, code.dlang.org now points to a more powerful 
dedicated server that can host the DUB registry without the danger of 
freezing due to excessive swapping - this is what happened on the 26th 
last month [1].


In addition to that, the server that previously hosted the registry is 
now used to run an official mirror, reachable at codemirror.dlang.org. 
This will be configured as a built-in fallback server starting with 
DMD 2.091.0/DUB 1.12.0 and, at least in theory, will lead to an uptime 
of virtually 100%.


To make use of the mirror today, it is also possible to configure it 
in DUB's settings.json as a custom registry:


{
   "registryUrls": ["https://codemirror.dlang.org/;]
}

settings.json is found/needs to be created in %APPDATA%\dub\ on 
Windows and in ~/.dub/ on all other systems. The custom entry should 
be removed once DUB 1.12.0 is used, to avoid redundant requests in 
certain situations.



[1]: https://forum.dlang.org/thread/ontwwoxuhnoczcoka...@forum.dlang.org


thank you very much for this Sönke! Is throwing so much more RAM (= 
money) and power (= more money) at it going to be a good solution in the 
long run though?


Is there maybe a plan for remaking the registry architecture like adding 
better supported mirrors and load balancing to it?


The server has a different main purpose, so this is just a nice benefit 
for the registry in that regard. The main issue is that there is some 
kind of GC related memory leak that is hard to debug with the basically 
non-existent tooling. Decoupling the package scanning from the web 
frontend into separate processes will play a major role in making that 
much less of an issue, though.


There is at least one fully supported mirror now and the cache based 
mirror by Sebastiaan could also be added as a reliable (albeit partial) 
fallback. So in that regard, at least the pressure for taking more 
involved steps has been mostly relieved now.


But making changes to the general architecture - be it in the form of 
adding load-balancing, or more deeply rooted, such as using GIT for 
storing and distributing the package index - is something that still is 
definitely desirable to push forward.

Re: code.dlang.org reliability update

[Sönke Ludwig via Digitalmars-d-announce]

Am 02.03.2020 um 23:50 schrieb MrSmith:

On Monday, 2 March 2020 at 19:17:59 UTC, Sönke Ludwig wrote:


settings.json is found/needs to be created in %APPDATA%\dub\ on Windows


I guess that should be %APPDATA%\Local\dub\


Nope, should be right. At least on my machines, %APPDATA% points to 
AppData\Roaming, which is the right base folder.

code.dlang.org reliability update

[Sönke Ludwig via Digitalmars-d-announce]

As of yesterday, code.dlang.org now points to a more powerful dedicated 
server that can host the DUB registry without the danger of freezing due 
to excessive swapping - this is what happened on the 26th last month [1].


In addition to that, the server that previously hosted the registry is 
now used to run an official mirror, reachable at codemirror.dlang.org. 
This will be configured as a built-in fallback server starting with DMD 
2.091.0/DUB 1.12.0 and, at least in theory, will lead to an uptime of 
virtually 100%.


To make use of the mirror today, it is also possible to configure it in 
DUB's settings.json as a custom registry:


{
   "registryUrls": ["https://codemirror.dlang.org/;]
}

settings.json is found/needs to be created in %APPDATA%\dub\ on Windows 
and in ~/.dub/ on all other systems. The custom entry should be removed 
once DUB 1.12.0 is used, to avoid redundant requests in certain situations.



[1]: https://forum.dlang.org/thread/ontwwoxuhnoczcoka...@forum.dlang.org

Re: ssll - simple shared library loader

[Sönke Ludwig via Digitalmars-d-announce]

Am 06.01.2020 um 00:23 schrieb Oleg B:

It's analog of bindbc, but without need write boilerplate code.
May be bindbc is designed for another cases, but I don't understand need 
writing triple definition for one function (pointer, loading, 
wrap-function).
ssll betterC compatible too, and tested on windows (x86) and linux (x86, 
ARM).


package: http://code.dlang.org/packages/ssll
github: https://github.com/deviator/ssll

Example usage:

Mosquitto binding and wrapper
https://github.com/deviator/mosquittod/blob/master/source/mosquittod/api/load.d 



libsystemd binding
https://github.com/deviator/sdutil/blob/master/source/systemd/daemon.d

I think somebody can find it handy.


Just throwing this in as a possible API alternative/addition - I've 
written something similar with the goal to make it work transparently 
with existing static bindings: https://code.dlang.org/packages/dynamic


It uses a mixin to specify the module(s) containing the declarations 
instead of a UDA:



mixin dynamicBinding!(somelib) _somelib;

void main()
{
_somelib.loadBinding(["somelib.so"]);

import somelib : foo;
foo();
}

Re: code.dlang.org downtime

[Sönke Ludwig via Digitalmars-d-announce]

Am 16.12.2019 um 12:23 schrieb WebFreak001:

On Monday, 16 December 2019 at 11:04:38 UTC, Sönke Ludwig wrote:
As you may have already noticed, the main registry server, 
code.dlang.org got unreachable yesterday. This was caused by an old 
VPS of mine getting terminated. The registry had already moved to a 
different server years ago, but, without me realizing it, the DNS 
entry still pointed to the old one, with a "temporary" HTTP proxy 
forwarding to the new server being set up.


By now the DNS entry has been corrected, an up-to-date TLS certificate 
is in place, and the registry is running stable. There are still 
reports of people not being able to access code.dlang.org, which is 
apparently caused by intermediate DNS servers still reporting the old 
IP address and should start working during the next few hours. A 
temporary workaround is to specify --registry=http://31.15.67.41/ on 
the dub command line.


Unfortunately both fallback servers have been down for a while now, so 
that this resulted in a total blackout. I plan to move the main 
registry to a powerful dedicated server in January, which will fix all 
memory resource related issues that sometimes show up, and could then 
keep the current VPS as a relatively reliable fallback server. Both 
together should guarantee virtually 100% uptime, although more 
fallback servers are of course highly desirable.


In addition to that, I plan to separate the repository polling process 
form the web and REST frontend, as the former appears to be the main 
cause for failures (a GC memory leak of some kind and a possibly 
codegen related crash when being compiled with DMD being the two known 
issues, which both need further investigation).


yay thanks for fixing this so soon.

In my experience having a background task fetching the whole time with 
vibe.d has nearly always been a bad idea in terms of memory for me. 
These days I started using cronjobs which run every so often instead and 
let the OS do all the memory freeing which works a lot better. This also 
scales a lot better because all workers just read/write to the database 
server and can be increased or decreased at any point.


Have you maybe also considered making the package zip downloads a 
separate server? It could be load balanced using nginx as well.


The zips are currently just redirects to GitHub/Bitbucket, but 
ultimately we should really cache them, if just to keep old versions of 
packages available in case they disappear from the original repository 
for whatever reason.


BTW, it looks like most of the CI failures that are usually attributed 
to the registry are in fact caused by GitHub, probably in combination 
with the borderline short timeout that is currently configured for 
dub/curl. I'd imagine that the timeout must be a frequent problem in 
particular for countries such as China, where the network latency adds a 
few hundred milliseconds on top of the server response time.

code.dlang.org downtime

[Sönke Ludwig via Digitalmars-d-announce]

As you may have already noticed, the main registry server, 
code.dlang.org got unreachable yesterday. This was caused by an old VPS 
of mine getting terminated. The registry had already moved to a 
different server years ago, but, without me realizing it, the DNS entry 
still pointed to the old one, with a "temporary" HTTP proxy forwarding 
to the new server being set up.


By now the DNS entry has been corrected, an up-to-date TLS certificate 
is in place, and the registry is running stable. There are still reports 
of people not being able to access code.dlang.org, which is apparently 
caused by intermediate DNS servers still reporting the old IP address 
and should start working during the next few hours. A temporary 
workaround is to specify --registry=http://31.15.67.41/ on the dub 
command line.


Unfortunately both fallback servers have been down for a while now, so 
that this resulted in a total blackout. I plan to move the main registry 
to a powerful dedicated server in January, which will fix all memory 
resource related issues that sometimes show up, and could then keep the 
current VPS as a relatively reliable fallback server. Both together 
should guarantee virtually 100% uptime, although more fallback servers 
are of course highly desirable.


In addition to that, I plan to separate the repository polling process 
form the web and REST frontend, as the former appears to be the main 
cause for failures (a GC memory leak of some kind and a possibly codegen 
related crash when being compiled with DMD being the two known issues, 
which both need further investigation).

Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64

[Sönke Ludwig via Digitalmars-d-announce]

Am 05.11.2019 um 10:48 schrieb Petar Kirov [ZombineDev]:

On Tuesday, 5 November 2019 at 02:16:28 UTC, Mathias Lang wrote:

[..]


That's great news! Thanks a lot for your hard work!

# Note: This will redownload your dependencies every time, which 
doesn't play well with docker


I have been meaning to add a docker and CI friendly command to dub that 
fetches all dependencies without building them.

In the Node.js world they have the `npm ci` [0] command.

[0]: https://docs.npmjs.com/cli/ci.html


Sounds like "dub upgrade --missing-only" will do that, as it implicitly 
downloads all dependencies in addition to filling the (non-existent in 
this case) gaps.

Re: An example of using D build pack for Heroku. Deploy your vibe-d app to Heroku in just one click!

[Sönke Ludwig via Digitalmars-d-announce]

Am 12.10.2019 um 00:41 schrieb Pablo De Nápoli:



I just wanted to let you know that I have creating an example of how to use
your build pack for deployment of D applications into Heroku (¡Many
thanks to Martin Nowak for creating that! I also have written to him 
about this).


The nice feature is that you just start by cloning my repository and then
deploy your application to Heroku in one click by pressing the Heroku 
button.


For new users, this will be much easier than follow the instructions at

https://tour.dlang.org/tour/en/vibed/deploy-on-heroku

so I suggest that you add a link there.

all the best
Pablo De Nápoli


I've added a link to https://vibed.org/tutorials

Re: SAOC - Looking for a mentor

[Sönke Ludwig via Digitalmars-d-announce]

Am 09.08.2019 um 07:50 schrieb Ionuț Mihalache:

Hi everyone,

I want to participate to Symmetry Autumn of Code 2019 with the project 
DUB: D's package manager, DEP5 (build system support for C/C++). I have 
here [1] my project proposal, could you give me some opinions about 
it(if it's ok, what should be changed or added, maybe removed).
Before sending the application I would like to find somenone to be my 
mentor, so if there is someone who would be interested in being my 
mentor for this project, please let me know as soon as possible.


[1] - 
https://drive.google.com/open?id=1JhX_r99YKMgRQ6tMHjMSJxJW4mc7j1iKLaAz_yavgrc 



Thanks,
Ionuț


Did you have a look at DEP5 [1]? It captures the coarse concept of the 
original vision for multi-language support.


Most likely, I won't be able to devote enough time to be a full mentor, 
but I can try to help "part-time", as time permits.


DEP5: https://github.com/dlang/dub/wiki/DEP5

Re: hunt-time library 1.0.0 beta1 released

[Sönke Ludwig via Digitalmars-d-announce]

Am 07.04.2019 um 09:09 schrieb bauss:

On Thursday, 4 April 2019 at 11:25:34 UTC, Andre Pany wrote:

On Thursday, 4 April 2019 at 10:49:46 UTC, zoujiaqing wrote:

Hunt time released the first beta version.

hunt-time is a time library and similar to Joda-time and Java.time api.

[...]


I am not sure but did you rewrote the java.time library (copyright of 
Oracle) from Java to D? I am not an expert but I have some fear using 
this library due to legal consequences. Did you contacted Oracle and 
asked wheter that is ok?


I honor your work, but if I want to develop commercial applications i 
have to think twice which libraries I use to avoid any legal issues.


Kind regards
Andre


It's only copyrighted by Oracle if you use Oracle's Java implementation 
but if you reference OpenJDK then there shouldn't be any problems.


But as explained above there aren't any in this case anyway since 
Oracle's implementation is based on something with a fine license.


Except that OpenJDK is L-GPL (AFAICS), so that it can't be changed to 
Apache in the process.

Re: taggedalgebraic 0.11.0 adds TaggedUnion

[Sönke Ludwig via Digitalmars-d-announce]

Am 23.02.2019 um 20:19 schrieb Paul Backus:

On Friday, 22 February 2019 at 17:09:41 UTC, Sönke Ludwig wrote:

 - Behaves like a POD if only POD fields exist, is non-copyable if any
   contained type is non-copyable etc.


In fact, if a contained type is non-copyable, it fails to compile 
altogether. (Example code below.)


Granted, so do Algebraic and SumType, so this isn't a knock against 
taggedalgebraic in particular. But it does indicate poor test coverage 
that you listed this feature without realizing it didn't work.


--- example.d
/+ dub.sdl:
dependency "taggedalgebraic" version="~>0.11.2"
+/
import taggedalgebraic;

struct NoCopy { @disable this(this); }
union U { NoCopy member; }
alias Test = TaggedUnion!U; // kaboom

void main() {}



You are right, I was actually aware of some places where the value is 
not moved/swapped properly, but I forgot about it when rushing the post 
before leaving. The test coverage is actually pretty good, though, even 
if it is hard to give a meaningful number for template-heavy code like that.

Re: taggedalgebraic 0.11.0 adds TaggedUnion

[Sönke Ludwig via Digitalmars-d-announce]

Am 23.02.2019 um 21:46 schrieb Sönke Ludwig:

Am 23.02.2019 um 20:19 schrieb Paul Backus:

On Friday, 22 February 2019 at 17:09:41 UTC, Sönke Ludwig wrote:

 - Behaves like a POD if only POD fields exist, is non-copyable if any
   contained type is non-copyable etc.


In fact, if a contained type is non-copyable, it fails to compile 
altogether. (Example code below.)


Granted, so do Algebraic and SumType, so this isn't a knock against 
taggedalgebraic in particular. But it does indicate poor test coverage 
that you listed this feature without realizing it didn't work.


--- example.d
/+ dub.sdl:
dependency "taggedalgebraic" version="~>0.11.2"
+/
import taggedalgebraic;

struct NoCopy { @disable this(this); }
union U { NoCopy member; }
alias Test = TaggedUnion!U; // kaboom

void main() {}



You are right, I was actually aware of some places where the value is 
not moved/swapped properly, but I forgot about it when rushing the post 
before leaving. The test coverage is actually pretty good, though, even 
if it is hard to give a meaningful number for template-heavy code like 
that.


https://github.com/s-ludwig/taggedalgebraic/pull/26

Re: taggedalgebraic 0.11.0 adds TaggedUnion

[Sönke Ludwig via Digitalmars-d-announce]

Am 23.02.2019 um 14:18 schrieb Sönke Ludwig:

Am 23.02.2019 um 09:51 schrieb Jacob Carlborg:

(...)

Why not using property syntax, i.e. `val.height = 10`?


The main reason is to distinguish the act of setting a new value from 
the one of modifying an existing value. In the former case it is okay if 
the currently stored kind/type differs, but in the latter case that 
would be a programming error.


To follow up on that, in the example above it would be possible to do this:

val.setHeight(10);
val.heightValue++;
assert(val.heightValue == 11);

//val.captionValue = "foo"; // throws an AssertError

Then there is also a generic variant of the above:

val.set!(Value.Kind.height)(10);
val.value!(Value.Kind.height)++;
val.value!int++;

Re: taggedalgebraic 0.11.0 adds TaggedUnion

[Sönke Ludwig via Digitalmars-d-announce]

Am 23.02.2019 um 09:51 schrieb Jacob Carlborg:

On 2019-02-22 18:09, Sönke Ludwig wrote:
TaggedUnion is the low level tagged union functionality separated out 
from TaggedAlgebraic. Because it doesn't support transparent access of 
methods and operators of the contained value, it is able to provide a 
number of convenience features. On top of that, visit and tryVisit is 
now supported for pattern matching, analogous to the version for 
std.variant.Algebraic. This is the basic usage:


 union U {
 string caption;
 int height;
 int width;
 }
 alias Value = TaggedUnion!U;

 auto val = Value.caption("foo");
 assert(val.kind == Value.Kind.caption);
 assert(val.value!(Value.Kind.caption) == "foo");

 // shorthand syntax:
 assert(val.isCaption);
 assert(val.captionValue == "foo");

 // set a different type/kind
 val.setHeight(10);


Why not using property syntax, i.e. `val.height = 10`?


The main reason is to distinguish the act of setting a new value from 
the one of modifying an existing value. In the former case it is okay if 
the currently stored kind/type differs, but in the latter case that 
would be a programming error.


This would have worked with a setter and an r-value getter, but that 
would have unnecessarily impeded performance for working with complex 
types, at least for the primary access syntax.


Following from the above, the raw name is used instead as a static 
property to enable a short construction syntax for a specific kind (e.g. 
`Value.width(10)`).




 val.visit!(
 (int i) { assert(i == 10); }
 (string s) { assert(false); }
 );


How does this handle the above case when there are two `int`? How do I 
know if it's the "width" or "height" that has been set?




I'm still thinking about a nice syntax for kind based pattern matching*, 
but for now this will call the same visitor for both, width and height. 
You'd have to query val.isWidth/val.kind to check the specific kind.



* really unfortunate that a template has to be instantiated first to be 
able to query the parameters of the contained function, otherwise 
`(@(Kind.width) i) { ... }` would be possible.

taggedalgebraic 0.11.0 adds TaggedUnion

[Sönke Ludwig via Digitalmars-d-announce]

TaggedUnion is the low level tagged union functionality separated out 
from TaggedAlgebraic. Because it doesn't support transparent access of 
methods and operators of the contained value, it is able to provide a 
number of convenience features. On top of that, visit and tryVisit is 
now supported for pattern matching, analogous to the version for 
std.variant.Algebraic. This is the basic usage:


union U {
string caption;
int height;
int width;
}
alias Value = TaggedUnion!U;

auto val = Value.caption("foo");
assert(val.kind == Value.Kind.caption);
assert(val.value!(Value.Kind.caption) == "foo");

// shorthand syntax:
assert(val.isCaption);
assert(val.captionValue == "foo");

// set a different type/kind
val.setHeight(10);
assert(val.isHeight && val.heightValue == 10);
assert(!val.isWidth);

assert(cast(short)val == 10);

val.visit!(
(int i) { assert(i == 10); }
(string s) { assert(false); }
);

assert(val.visit!((v) => v.to!string) == "10");


Another addition is a new placeholder "This" type to enable defining 
self-referential types without having to write additional boilerplate code:


union U {
bool boolean;
string text;
float number;
TaggedUnion!This[] array;
TaggedUnion!This[string] object;
}
alias JsonValue = TaggedUnion!U;


The general advantages of TaggedUnion/TaggedAlgebraic over Algebraic 
result from its use of a numeric type tag instead of relying on runtime 
TypeInfo:


 - Allows compiler checked handling of all possible types/kinds using
   "final switch"
 - Enables inlining and function attribute inference (@safe, nothrow,
   @nogc)
 - Allows to use the same type with multiple tags to avoid the overhead
   of defining separate wrapper types
 - Behaves like a POD if only POD fields exist, is non-copyable if any
   contained type is non-copyable etc.


DUB: https://code.dlang.org/packages/taggedalgebraic
GitHub: https://github.com/s-ludwig/taggedalgebraic

Re: hunt-markdown 1.0.0 released,

[Sönke Ludwig via Digitalmars-d-announce]

Am 19.02.2019 um 11:36 schrieb zoujiaqing:
hunt-markdown is powerfull markdown spec parsing and randering library 
for Dlang. It's fast and clean. Api design like java's commonmark library.


example code:
```import hunt.markdown.node.Node;
import hunt.markdown.parser.Parser;
import hunt.markdown.renderer.html.HtmlRenderer;

Parser parser = Parser.builder().build();
Node document = parser.parse("This is *New*");
HtmlRenderer renderer = HtmlRenderer.builder().build();
renderer.render(document);  // "This is New\n"
```

More markdown spec like this:
https://spec.commonmark.org/0.28/


Github reposirory:
https://github.com/huntlabs/hunt-markdown


Since the code appears to be a direct port from Atlassian's library, you 
should also include the BSD license file, including the original 
copyright notice 
(https://github.com/atlassian/commonmark-java/blob/master/LICENSE.txt). 
Not sure whether the Apache-2.0 license that is set in dub.sdl is 
compatible.


Personally, I would also always explicitly mention the source project 
when doing a fork like this, since it can help a lot in terms of 
communicating the exposed API, as well as the code stability to be 
expected. Also, should the project stop being maintained at some point, 
the original project may still continue to be supported, so backporting 
changes can be an option. Since we are talking about server 
applications, tracking inherited security issues can also be important, 
so documenting the version/commit on which the port is based is also a 
good idea (probably most important for hunt-http etc.).

Re: A brief survey of build tools, focused on D

[Sönke Ludwig via Digitalmars-d-announce]

Am 12.12.2018 um 15:53 schrieb Atila Neves:

On Wednesday, 12 December 2018 at 09:38:55 UTC, Sönke Ludwig wrote:

Am 11.12.2018 um 20:46 schrieb H. S. Teoh:
On Tue, Dec 11, 2018 at 11:26:45AM +0100, Sönke Ludwig via 
Digitalmars-d-announce wrote:

[...]


The main open point right now AFAICS is to make --parallel work with
the multiple-files-at-once build modes for machines that have enough
RAM. This is rather simple, but someone has to do it. But apart from
that, I think that the current state is relatively fine form a
performance point of view.


Wait, what does --parallel do if it doesn't compile multiple files at
once?


It currently only works when building with `--build-mode=singleFile`, 
so compiling individual files in parallel instead of compiling chunks 
of files in parallel, which would be the ideal.


If by "the ideal" you mean "compile the fastest", then you don't want to 
compile single files in parallel. I measured across multiple projects, 
and compiling per package (in the D sense, not the dub one) was fastest. 
Which is why it's the default with reggae.




The sentence was ambiguous, but that's what I meant!

Re: A brief survey of build tools, focused on D

[Sönke Ludwig via Digitalmars-d-announce]

Am 11.12.2018 um 20:46 schrieb H. S. Teoh:

On Tue, Dec 11, 2018 at 11:26:45AM +0100, Sönke Ludwig via 
Digitalmars-d-announce wrote:
[...]


The main open point right now AFAICS is to make --parallel work with
the multiple-files-at-once build modes for machines that have enough
RAM. This is rather simple, but someone has to do it. But apart from
that, I think that the current state is relatively fine form a
performance point of view.


Wait, what does --parallel do if it doesn't compile multiple files at
once?


It currently only works when building with `--build-mode=singleFile`, so 
compiling individual files in parallel instead of compiling chunks of 
files in parallel, which would be the ideal.

Then it requires a specific source layout, with incomplete /
non-existent configuration options for alternatives.  Which makes it
unusable for existing code bases.  Unacceptable.


You can define arbitrary import/source directories and list (or
delist) source files individually if you want. There are restrictions
on the naming of the output binary, though, is that what you mean?


Is this documented? I couldn't find any info on it the last time I
looked.


There are the three directives sourcePaths, sourceFiles and 
excludedSourceFiles (the latter two supporting wildcard expressions) to 
control the list of files. Once an explicit sourcePaths directive is 
given, the folder that is possibly detected by default ("source"/"src") 
is also skipped. They are documented in the package format specs ([1], [2]).




Also, you refer to "the output binary". Does that mean I cannot
generate multiple executables? 'cos that's a showstopper for me.


Compiling multiple executables currently either requires multiple 
invocations (e.g. with different configurations or sub packages 
specified), or a targetType "none" package that has one dependency per 
executable - the same configuration/architecture applies to all of them 
in that case. If they are actually build dependencies, a possible 
approach is to invoke dub recursively inside of a preBuildCommand.


But what I meant is that there is for example currently no way to 
customize the output binary base name ("targetName") and directory 
("targetPath") depending on the build type.



Worst of all, it does not support custom build actions, which is a
requirement for many of my projects.  It does not support polyglot
projects. It either does not support explicit control over exact
build commands, or any such support is so poorly documented it might
as well not exist.  This is not only unacceptable, it is a
show-stopper.


Do you mean modifying the compiler invocations that DUB generates or
adding custom commands (aka pre/post build/generate commands)?


Does dub support the following scenario?

- There's a bunch of .java files that have to be compiled with javac.
- But some of the .java files are generated by an external tool, that
  must be run first, before the .java files are compiled.
- There's a bunch of .d files in two directories.
- The second directory contains .d files that need to be compiled
  into multiple executables, and they must be compiled with a local
  (i.e., non-cross) compiler.
- Some of the resulting executables must be run first in order to
  generate a few .d files in the first directory (in addition to
  what's already there).
- After the .d files are generated, the first directory needs to be
  compiled TWICE: once with a cross-compiler (LDC, targetting
  Arm/Android), once with the local D compiler. The first compilation
  must link with cross-compilation Android runtime libraries, and the
  second compilation must link with local X11 libraries.
   - (And obviously, the build products must be put in separate
 subdirectories to prevent stomping over each other.)
- After the .java and .d files are compiled, a series of tools must be
   invoked to generate an .apk file, which also includes a bunch of
   non-code files in resource subdirectories.  Then, another tool must be
   run to align and sign the .apk file.

And here's a critical requirement: any time a file is changed (it can be
a .java file, a .d file, or one of the resources that they depend on),
all affected build products must be correctly updated. This must be done
as efficiently as possible, because it's part of my code-compile-test
cycle, and if it requires more than a few seconds or recompiling the
entire codebase, it's a no-go.

If dub can handle this, then I'm suitably impressed, and retract most of
my criticisms against it. ;-)


This will currently realistically require invoking an external tool such 
as make through a pre/post-build command (although it may actually be 
possible to hack this together using sub packages, build commands, and 
string import paths for the file dependencies). Most notably, there is a 
directive missing to specify arbitrar

Re: A brief survey of build tools, focused on D

[Sönke Ludwig via Digitalmars-d-announce]

Am 10.12.2018 um 22:01 schrieb H. S. Teoh:

(...)

Convenience and simplicity, sure.  But speed? I'm sorry to say, I tried
dub for 2 days and gave up in frustration because it was making my
builds *several times longer* than a custom SCons script.  I find that
completely unacceptable.

It also requires network access.  On *every* invocation, unless
explicitly turned off.  And even then, it performs time-consuming
dependency resolutions on every invocation, which doubles or triples
incremental build times.  Again, unacceptable.


The upgrade check has been disabled in one of the latest releases, so 
unless the dependencies haven't been resolved before, it will not access 
the network anymore. A notable exception are single-file packages, which 
don't have a dub.selections.json - we should probably do something about 
this, too, at some point.


I've also rewritten the dependency resolution a while ago and it usually 
is not noticeable anymore nowadays.


Then there was an issue where LDC was invoked far too frequently to 
determine whether it outputs COFF files or not, making it look like 
scanning the file system for changes took unacceptably long. This has 
also been fixed.


The main open point right now AFAICS is to make --parallel work with the 
multiple-files-at-once build modes for machines that have enough RAM. 
This is rather simple, but someone has to do it. But apart from that, I 
think that the current state is relatively fine form a performance point 
of view.




Then it requires a specific source layout, with incomplete /
non-existent configuration options for alternatives.  Which makes it
unusable for existing code bases.  Unacceptable.


You can define arbitrary import/source directories and list (or delist) 
source files individually if you want. There are restrictions on the 
naming of the output binary, though, is that what you mean?



Worst of all, it does not support custom build actions, which is a
requirement for many of my projects.  It does not support polyglot
projects. It either does not support explicit control over exact build
commands, or any such support is so poorly documented it might as well
not exist.  This is not only unacceptable, it is a show-stopper.


Do you mean modifying the compiler invocations that DUB generates or 
adding custom commands (aka pre/post build/generate commands)?

Re: RFC: initial release of dtoh

[Sönke Ludwig via Digitalmars-d-announce]

Am 22.08.2018 um 15:59 schrieb Sönke Ludwig:

Am 22.08.2018 um 14:32 schrieb Mihails:

On Wednesday, 22 August 2018 at 11:51:59 UTC, Seb wrote:
Yeah, the dub registry is "smart" enough to reject all tags from the 
dmd repository as they all don't conform with SemVer.
There has been a long discussion on this 
(https://forum.dlang.org/post/drcekmxvfszpwifbu...@forum.dlang.org), 
but sadly it seems that no consensus has been reached.


This is a bit sad, because that means no stable tool can be built to 
use DMD FE as a library as long as it want to be available via 
code.dlang.org (also afair branch dependencies are deprecated in dub 
itself now). For dtoh it is probably less of a problem as I intend to 
propose it for inclusion in dmd if it proves itself good enough in 
production, but it feels like a missed opportunity overall.


Can't we at least use something like "0.0.1-dmd-2.080.0" that is sure to 
not interfere with any official scheme that might be decided on later?


correction: "0.0.1+dmd-2.080.0"

Re: RFC: initial release of dtoh

[Sönke Ludwig via Digitalmars-d-announce]

Am 22.08.2018 um 14:32 schrieb Mihails:

On Wednesday, 22 August 2018 at 11:51:59 UTC, Seb wrote:
Yeah, the dub registry is "smart" enough to reject all tags from the 
dmd repository as they all don't conform with SemVer.
There has been a long discussion on this 
(https://forum.dlang.org/post/drcekmxvfszpwifbu...@forum.dlang.org), 
but sadly it seems that no consensus has been reached.


This is a bit sad, because that means no stable tool can be built to use 
DMD FE as a library as long as it want to be available via 
code.dlang.org (also afair branch dependencies are deprecated in dub 
itself now). For dtoh it is probably less of a problem as I intend to 
propose it for inclusion in dmd if it proves itself good enough in 
production, but it feels like a missed opportunity overall.


Can't we at least use something like "0.0.1-dmd-2.080.0" that is sure to 
not interfere with any official scheme that might be decided on later?

Re: vibe.d 0.7.33 maintenance release

[Sönke Ludwig via Digitalmars-d-announce]

Am 21.05.2018 um 17:34 schrieb Steven Schveighoffer:

On 5/20/18 8:07 AM, Sönke Ludwig wrote:

Another big improvement is the diet-ng library, which uses less 
compile-time memory and is a lot more flexible than the old 
`vibe.textfilter.diet` module.


Isn't diet-ng used by 0.7.x branch now? It seems to be selected when I'm 
using 0.7.x


-Steve


You are right, I misremembered that! The difference is just that in 
0.8.0 it is now mandatory, and the old implementation got dropped.

Re: vibe.d 0.7.33 maintenance release

[Sönke Ludwig via Digitalmars-d-announce]

Am 18.05.2018 um 16:00 schrieb Seb:

On Friday, 18 May 2018 at 13:46:45 UTC, Márcio Martins wrote:

On Wednesday, 16 May 2018 at 08:48:15 UTC, Sönke Ludwig wrote:
Being the final public release on the 0.7.x branch, this version on 
DMD 2.068.2 up to DMD 2.080.0 and LDC 1.9.0. It includes some major 
fixes and improvements backported from the 0.8.x branch. Since this 
marks the last 0.7.x release, all code depending on it should now be 
upgraded to 0.8.3 or later.


Change log:
<http://vibed.org/blog/posts/vibe-release-0.7.33>

DUB package:
<https://code.dlang.org/packages/vibe-d/0.7.32>


Comparing with 0.7.x, how production-ready would you say the 0.8.x 
branch is, and what are the main advantages?


Thank you for the awesome work!


I think I can try to answer this for you.
0.8.x has been in production use for almost a year now.

There have been tons of improvements in the API, performance and new 
functionality, so it's hard to boil down individual items. The full 
changelog is here:


http://vibed.org/blog/posts/vibe-release-0.8.0

The biggest change is probably that 0.8 now uses subpackages and the new 
vibe-core package is available for opt-in usage.
Vibe-core is a pure D replacement of the old libevent-based 
event-handling (that's simplified because the actual logic is done by 
eventcore and it contains more functionality too).
Anyhow, there have been a few regressions when vibe.d switched to use 
the new vibe-core in 0.8.3, but funnily it also fixed quite a few 
existing issues with libevent.
So tl;dr: it's safe to upgrade and if you run into any immediate 
troubles, stick to the old libevent for one or two releases (it can be 
selected via the vibe-core subconfiguration).


To add to this, when using the libevent driver, the major changes are 
mainly just type system related (`@safe` and `nothrow` support), so in 
terms of functionality and risk of regressions it is probably safe to 
say that it is not much different than a 0.7.x point release.


The new vibe-core module also runs fine in most contexts, but seems to 
amplify a GC memory consumption/leak issue (visible in the DUB registry) 
and there is still an unresolved report of performance issues in the 
HTTP client (which I couldn't reproduce so far). So this should still be 
used with care in production - on the other hand, any controlled 
real-world exposure is of course highly desirable in order to pinpoint 
any remaining issues.


As Sebastian pointed out, it does fix quite a number of existing, but 
rarely encountered, issues that exist in the libevent implementation, 
because it uses a much more robust approach to fiber scheduling. It also 
has the potential for much better performance, although that is 
currently still nullified by some implementation choices in the HTTP 
server code.


Another big improvement is the diet-ng library, which uses less 
compile-time memory and is a lot more flexible than the old 
`vibe.textfilter.diet` module.

vibe.d 0.7.33 maintenance release

[Sönke Ludwig via Digitalmars-d-announce]

Being the final public release on the 0.7.x branch, this version on DMD 
2.068.2 up to DMD 2.080.0 and LDC 1.9.0. It includes some major fixes 
and improvements backported from the 0.8.x branch. Since this marks the 
last 0.7.x release, all code depending on it should now be upgraded to 
0.8.3 or later.


Change log:


DUB package:

Re: sumtype 0.3.0

[Sönke Ludwig via Digitalmars-d-announce]

Another similar project: http://taggedalgebraic.dub.pm/

Re: 2.080.0-rc.1 [was: Beta 2.080.0]

[Sönke Ludwig via Digitalmars-d-announce]

Am 27.04.2018 um 19:38 schrieb Martin Nowak:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Release candidate available now.

http://dlang.org/changelog/2.080.0.html
http://dlang.org/download.html#dmd_beta

- -Martin
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlrjYAYACgkQsnOBFhK7
GTmNww//eLu1TR1n2p0GKt/vQJsfOrHLyXLWLtQatcUPh2MUS4aJ3j1lB8CnWkca
U+uwCY5aOoGXJw45o2TAS44yrnlFrykUjYCfPzQVu3ynT/P/DxRnESjZgrZr13Zn
z7giOWOEt2m26mAjd8yqClYRw4yEZFBgic0WvHeZCwtsYz/2iGvpOXGEOw9iuZcH
JvV9WgKXBJSbL4AlTj1Uy2y8WRhT6LzXDRQMF5tF80ZbEQXGvggB5UVuGl4Kwmbk
40dfaQsoXhBX4FoxiTTZ5sOjmHAnyXT7VFAYj8rQE6G+FhbQ3mHtZu101xC/qzx/
9Zd6CbgWEIoxBm4ADTQ7XsZBP1x1T1x9hGmF3LQG3lMDBSJH2Cj7/HSnrpCamM6J
HUU8y0a40k3Nx5TsWJuZ6T2Jdz8+UsWiO7vmLCzW861y5uNEQocTblNpwetEwcEL
Aa2TVQF30cdmDMKh+hytQGV4/OBH4RWZjJSH/WhNwbiRKDuES0qKwL9e93X55vRJ
IA7CtFHp+WLC+0DRvEs0GFtkVqFmIETPKhLMKEy5RsKUvfhuHIRpOdKT0vWQBQ1m
vm3QKJtnye8M/JL8wLfZzFLbMIuUMjiwij8TixEOUCAkDm7IxsyIaViXdI1L9dUt
pFhzCS/cheq/cgQ7S8h8U8KcBB7dr+PYM15fgJAepXqEolUH9Fw=
=haox
-END PGP SIGNATURE-



There is still an open regression:
https://issues.dlang.org/show_bug.cgi?id=18800

Released vibe.d 0.8.3

[Sönke Ludwig via Digitalmars-d-announce]

The deprecation phase of the legacy "vibe-d:core" module starts with 
this release by defaulting to the new "vibe-core" package. Additionally, 
DMD 2.079.0 is finally supported, and some notable improvements have 
been made to the HTTP implementation. URLRouter in particular has 
received memory optimizations (to avoid fragmentation) that can result 
in a heavy reduction of memory use.


See the change log for instructions to opt for the legacy vibe-d:core 
module in case of any issues with vibe-core.


Change log:
https://vibed.org/blog/posts/vibe-release-0.8.3

DUB package:
https://code.dlang.org/packages/vibe-d/0.8.3

Re: Release D 2.079.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 07.03.2018 um 17:01 schrieb Paolo Invernizzi:

On Wednesday, 7 March 2018 at 14:53:09 UTC, Sönke Ludwig wrote:

But why wouldn't it be possible to make a quick bugfix release with 
the current scheme? It has happened in the past. Granted, if a 
0.8.5-beta.1 is already tagged, then using 0.8.5 for a quick 
intermediate release would be bad, but at that point the beta could 
likely also be turned into a full release pretty quickly.


Well, I don't know why, but quick is more than 30 days right now using 
the current release procedure...


https://github.com/vibe-d/vibe.d/issues/2058
https://github.com/vibe-d/vibe.d/releases

Anyway, never mind!

/Paolo


What I mean are releases like these:

https://vibed.org/blog/posts/vibe-release-0.7.11 (3 days)
https://vibed.org/blog/posts/vibe-release-0.7.28 (16 days)

There are also releases such as 0.7.29 that actually got branched out 
and was stabilized while 0.7.30 was already pushed further along on master.


But such releases were only done if really necessary, because a release, 
despite many things being automated, always has quite some overhead, 
just like maintaining parallel branches has. Depending on the work force 
and the general development speed that may be okay, but currently 
development time unfortunately is a premium.

Re: Release D 2.079.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 07.03.2018 um 13:57 schrieb Paolo Invernizzi:

On Wednesday, 7 March 2018 at 10:13:29 UTC, Sönke Ludwig wrote:

Well, for all of the recent releases we made sure that there was no 
breakage for new compiler versions. This release was an exception, 
because I didn't manage to put out the fixed release in time. The plan 
is to have all future releases go back to the normal mode where the 
new compiler version always works.


Since std.experimental isn't involved from now on, it shouldn't even 
be necessary anymore to put out new vibe.d releases for new DMD 
versions, because DMD/Phobos already checks for regressions against 
vibe.d and all breaking changes should simply result in a deprecation 
warning.


That's fine, thanks.

As for the versioning scheme, currently almost all new releases have 
some small breaking change or deprecation. If I'd use the "minor" 
version for that, then there would be no way to signal that a release 
makes broad and more disruptive changes, such as the 0.8.0 release. 
But all of this will change, as the remaining parts get pushed to 
separate repositories one-by-one, with their own version starting at 
1.0.0.


I understand your reasoning, but there's value in being able to just 
rapidly fix something with a new release, or just port some master 
bug-fixes into a released version branch.


DMD is experiencing a very enjoyable release process of patch versions, 
thanks to Martin and the team.


It your concern is only related to the best way to inform the users 
about a broad and disruptive change in vibe-d, I suggest to simply use 
the usual channels for that, change logs and announce forum.


My impression is that there's a lot of value in using patch for patch, 
instead of using patch for development, also in a zero major, so I maybe 
you should consider that change, or at least, investigate a little about 
that opportunity.


/Paolo


But why wouldn't it be possible to make a quick bugfix release with the 
current scheme? It has happened in the past. Granted, if a 0.8.5-beta.1 
is already tagged, then using 0.8.5 for a quick intermediate release 
would be bad, but at that point the beta could likely also be turned 
into a full release pretty quickly.


But the point is that the development mode is currently still happening 
in a linear fashion. Starting to have (a) stable branch(es) with 
additional point releases would increase the overhead to a point where 
there wouldn't be any meaningful progress anymore, at least at this time.


Then there is the fact that 0.8.0 was developed in a parallel branch for 
quite a while. If the minor version would have been used to denote 
regular small updates, it would not have been possible to tag alpha/beta 
releases on the 0.8.x branch at all.

Re: mysql-native v2.1.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 06.03.2018 um 05:31 schrieb Nick Sabalausky (Abscissa):
(...) Also, AFAIK, 
vibe doesn't offer socket support like it does TCP, so vibe users would 
loose out on the automatic yield-on-io that's a cornerstone of vibe's 
concurrency design.


There currently appears to be something broken, but vibe-core does 
support UDS (by setting a UDS address in the connectTCP call; the legacy 
name of that function is going to get changed during the next releases). 
There is also an open PR for the legacy core module:


https://github.com/vibe-d/vibe.d/pull/2073

Re: Release D 2.079.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 07.03.2018 um 10:17 schrieb Paolo Invernizzi:

On Wednesday, 7 March 2018 at 04:02:18 UTC, Seb wrote:

On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote:

On 3/6/18 2:30 PM, Martin Nowak wrote:

On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:


But if needed, you could have your dub package depend on a prior 
version.


http://code.dlang.org/packages/stdx-allocator ;)



This is the answer, vibe.d should depend on stdx-allocator.

-Steve


Vibe.d (and a lot of other projects) do depend on this package, see e.g.

https://github.com/vibe-d/vibe.d/pull/1983

Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm 
and not released as the latest stable tag yet, which is the reason for 
Atila's justified complaint.


The point is just to persuade Sonke to do his development in the minor 
version and increase it during every vibe-d release, and keep the patch 
version for fast fixes of the latest released vibe-d when a new version 
of the compiler is being released.


The actual policy is just an ask for problems...

It's not a big deal to fix the breakage on the latest released vibe-d 
code, it's a fast process. But it's a problem in just coordinating the 
next release of vibe-d with the release of the compiler, if you need to 
do this, like in this case.


/Paolo



Well, for all of the recent releases we made sure that there was no 
breakage for new compiler versions. This release was an exception, 
because I didn't manage to put out the fixed release in time. The plan 
is to have all future releases go back to the normal mode where the new 
compiler version always works.


Since std.experimental isn't involved from now on, it shouldn't even be 
necessary anymore to put out new vibe.d releases for new DMD versions, 
because DMD/Phobos already checks for regressions against vibe.d and all 
breaking changes should simply result in a deprecation warning.


As for the versioning scheme, currently almost all new releases have 
some small breaking change or deprecation. If I'd use the "minor" 
version for that, then there would be no way to signal that a release 
makes broad and more disruptive changes, such as the 0.8.0 release. But 
all of this will change, as the remaining parts get pushed to separate 
repositories one-by-one, with their own version starting at 1.0.0.

Re: Release D 2.079.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 06.03.2018 um 00:40 schrieb Atila Neves:

(...)

This doesn't change the fact that right now, somebody trying D for the 
1st time with the latest official compiler will get an error if they try 
out the most popular dub package that I know of if they follow the 
instructions on code.dlang.org.


It also doesn't change that I can't upgrade dmd on our CI at work 
because it can't compile vibe unless I change dozens of dub.sdl files to 
use a beta version. This breaks semver!


I found out about this after removing a dependency on stdx.data.json 
since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed 
a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0.


I'd have a snowball's chance in hell convincing anyone at a "regular" 
company of adopting D if anyone there even imagined any of the above 
could happen.


We have to do better than this.

Atila



I tagged a RC today: 
https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/49899/


To avoid letting this sit broken I'll shorten the final testing phase, 
so that the release happens this Thursday. This is a bit unfortunate, 
because this release is a bit more disruptive than normal due to the 
switch to using vibe-core by default. So early testing with "dub upgrade 
--prerelease" in different projects is particularly valuable this time!


BTW, the problems with this release are a strong hint that we should 
rethink the inclusion approach with std.experimental. Since breaking 
changes are tied to the DMD version, it makes those modules almost 
unusable outside of toy code. Having them as a DUB package (or in 
essence, in a separate repository) on the other hand nicely decouples 
them from the compiler release and makes it possible to properly version 
them individually.

Re: Diamond Full-stack MVC / Template Engine - v2.5.4 Released!

[Sönke Ludwig via Digitalmars-d-announce]

Just a quick note that the information in the README about Diet 
templates is not up to date anymore. The diet-ng package [1] does not 
have any external dependencies except for Phobos and is implemented in 
terms of generic ranges.


[1] https://github.com/rejectedsoftware/diet-ng

Re: Released vibe.d 0.8.2

[Sönke Ludwig via Digitalmars-d-announce]

Am 17.12.2017 um 21:56 schrieb bauss:

On Sunday, 17 December 2017 at 20:55:15 UTC, bauss wrote:

    private Nullable!string _path;


Also does this really make sense?

Why not just have it:

private string _path;

Then instead of:
     string path() @safe {
     if (_path.isNull) {
     _path = urlDecode(requestPath.toString);
     }
     return _path.get;
     }

You could have:
     string path() @safe {
     if (!_path) {
     _path = urlDecode(requestPath.toString);
     }
     return _path;
     }


That would certainly be possible. Using a `Nullable` is mainly just more 
explicit.

Re: Released vibe.d 0.8.2

[Sönke Ludwig via Digitalmars-d-announce]

Am 17.12.2017 um 21:55 schrieb bauss:

On Sunday, 17 December 2017 at 19:13:44 UTC, Sönke Ludwig wrote:
But what do you mean with anything will break using `.path`? It 
follows the usual deprecation path - currently it's just documented as 
deprecated. In one or two releases, the `deprecated` attribute will be 
set and a few releases later it will finally be removed. By that time 
projects will have had quite some time to react on the deprecation.


HTTPServerRequest.path does not have the same definition as previously.

It has been changed from a field to a getter function.


True, this can be a breaking change, but setting this field looks like 
something that is outside of any sane use case. The field should ideally 
have been const/immutable before.




Tbh. it should just have been marked with deprecated instead of being 
removed, as you do specify is the normal deprecation process.


What do you mean with this? Keeping the field with a `deprecated` 
attribute, and at the same time add the getter property?




0.8.1:
     /** The _path part of the URL.

     Remarks: This field is only set if 
HTTPServerOption.parseURL is set.

     */
     string path;

0.8.2:
     /** Deprecated: The _path part of the URL.

     Note that this function contains the decoded version of the
     requested path, which can yield incorrect results if the path
     contains URL encoded path separators. Use `requestPath` 
instead to

     get an encoding-aware representation.
     */
     string path() @safe {
     if (_path.isNull) {
     _path = urlDecode(requestPath.toString);
     }
     return _path.get;
     }

     private Nullable!string _path;

There should still have been a setter property like:

void path(string newPath);

Which should be marked with deprecated until it could be safely removed.

Re: Released vibe.d 0.8.2

[Sönke Ludwig via Digitalmars-d-announce]

Am 17.12.2017 um 16:24 schrieb bauss:

On Sunday, 17 December 2017 at 14:13:05 UTC, WebFreak001 wrote:

On Sunday, 17 December 2017 at 12:52:57 UTC, bauss wrote:
This shouldn't have been released as 0.8.2, because it has a lot of 
breaking changes.


For an instance anything that relies on HTTPServerRequest.path will 
break.


I'm aware that there has been added the "requestPath" property, but 
it's still a breaking change to all existing code that relies on the 
old "path" property. Especially when it's used to manipulate the path 
you receive.


Diamond cannot currently be used with latest release of vibe.d, 
because of this and it was relying on vibe.d with following dependency:


"vibe-d": "~>0.8.1"

0.8.2 should not be a breaking change, assuming you follow semantic 
versioning.


https://semver.org/


4. Major version zero (0.y.z) is for initial development. Anything may 
change at any time. The public API should not be considered stable.


0.x.Y should always be compatible with 0.x.Z without breaking changes.

Since it's MAJOR.MINOR.PATCH

This is a patch release 0.8.1 to 0.8.2 which means:

"PATCH version when you make backwards-compatible bug fixes."

Even a minor version should be backward-compatible.

"MINOR version when you add functionality in a backwards-compatible 
manner, and"


I'm all for deprecating said features, but plain removing them in a 
release like this is a breaking change and should at the very least be a 
minor version upgrade, but definitely not a patch.


The above was actually a quote from the spec, so there is no doubt that 
any 0.x.y release may contain breaking changes. But apart from that, the 
development has always gone this way so far. I just made 0.8.0 a new 
"minor" version, because it is in many ways a much larger step than the 
previous releases and not all breaking changes could reasonably follow 
the usual deprecation paths.


However, as individual sub packages are separated out into their own 
repositories (such as diet-ng and vibe-core), their versioning will 
start as 1.0.0 and will follow the usual versioning rules for >= 1.x.y 
releases.


But what do you mean with anything will break using `.path`? It follows 
the usual deprecation path - currently it's just documented as 
deprecated. In one or two releases, the `deprecated` attribute will be 
set and a few releases later it will finally be removed. By that time 
projects will have had quite some time to react on the deprecation.

Re: Released vibe.d 0.8.2

[Sönke Ludwig via Digitalmars-d-announce]

Am 13.12.2017 um 01:24 schrieb Seb:
I think you should mention more prominently that for people who want to 
use OpenSSL 1.1, they can now use:


dub --override-config="vibe-d:tls/openssl-1.1"


This allows to use OpenSSL 1.1 _without_ needing to set the 
`VibeUseOpenSSL11` version in their dub.sdl


Thanks for the pointer, I completely forgot about that. It's now 
mentioned in the release announcement, as well as in the README and in 
the TLS section of the documentation:


https://vibed.org/blog/posts/vibe-release-0.8.2

Released vibe.d 0.8.2

[Sönke Ludwig via Digitalmars-d-announce]

The major changes in this release are HTTP forward proxy support, 
handling incoming HTTP requests on custom transports and a MongoDB based 
session store. On top of that, there are many smaller improvements in 
the HTTP server, web/REST generator, JSON/BSON support and the TLS sub 
system.


Change log:
https://vibed.org/blog/posts/vibe-release-0.8.2

DUB package:
https://code.dlang.org/packages/vibe-d/0.8.2

Release candidate vibe.d 0.8.2-rc.2

[Sönke Ludwig via Digitalmars-d-announce]

The second release candidate for 0.8.1 is out (the first one was not 
announced). 0.8.2 notably contains a HTTP forward proxy, handling 
incoming HTTP requests on custom transports and a MongoDB based session 
store. On top of that, there are many smaller improvements in the HTTP 
server, web/REST generator, JSON/BSON support and the TLS sub system.


Full change log:
https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md

0.8.2-rc.2 on code.dlang.org:
http://code.dlang.org/packages/vibe-d/0.8.2-rc.2

It also hopefully finally fixes the OpenSSL 1.1.x support on all 
systems. Add the following dependency + sub configuration to the package 
recipe for linking against OpenSSL 1.1.x instead of OpenSSL 1.0.x:


dub.sdl:
  dependency "vibe-d:tls" version="*"
  subConfiguration "vibe-d:tls" "openssl-1.1"

dub.json:
  "dependencies": {
  ...,
  "vibe-d:tls": "*"
  },
  "subConfigurations": {
  "vibe-d:tls": "openssl-1.1"
  }

The final release is scheduled for Monday 2017/12/11.

Re: DUB registry code.dlang.org server maintenance

[Sönke Ludwig via Digitalmars-d-announce]

Am 08.10.2017 um 12:38 schrieb Sönke Ludwig:
The server infrastructure is currently undergoing a scheduled 
maintenance, which is stated to take about 30 min. code.dlang.org will 
be unavailable during this time.


The system is back online.

Re: DUB registry code.dlang.org server maintenance

[Sönke Ludwig via Digitalmars-d-announce]

Am 08.10.2017 um 12:38 schrieb Sönke Ludwig:
The server infrastructure is currently undergoing a scheduled 
maintenance, which is stated to take about 30 min. code.dlang.org will 
be unavailable during this time.


Forgot to mention that it is possible to use

  --registry=https://code-mirror.dlang.io/

on the DUB command line to access the packages in the meantime.

DUB registry code.dlang.org server maintenance

[Sönke Ludwig via Digitalmars-d-announce]

The server infrastructure is currently undergoing a scheduled 
maintenance, which is stated to take about 30 min. code.dlang.org will 
be unavailable during this time.

Released vibe.d 0.8.1

[Sönke Ludwig via Digitalmars-d-announce]

Apart from removing the old vibe-d:diet package in favor of diet-ng, 
this release most notably contains a number of performance improvements 
in the HTTP server, as well as improvements and fixes in the WebSocket 
code. Furthermore, initial OpenSSL 1.1.x support has been added and a 
few @safe related issues introduced in 0.8.0 have been fixed.


Change log:
https://vibed.org/blog/posts/vibe-release-0.8.1

DUB package:
https://code.dlang.org/packages/vibe-d/0.8.1

Third release candidate vibe.d 0.8.1-rc.3

[Sönke Ludwig via Digitalmars-d-announce]

The latest RC fixes a build issue with the OpenSSL 1.1.0 compatibility 
code and adds Meson build files.

Second release candidate 0.8.1-rc.2

[Sönke Ludwig via Digitalmars-d-announce]

v0.8.1-rc.2 now supports setting a version "VibeUseOpenSSL11" in the 
package recipe to compile against the OpenSSL 1.1.0 API on systems that 
don't have 1.0.1 anymore.

Re: Release candidate vibe.d 0.8.1-rc.1

[Sönke Ludwig via Digitalmars-d-announce]

Am 12.08.2017 um 10:41 schrieb Andrew Benton:

On Saturday, 12 August 2017 at 07:55:14 UTC, Sönke Ludwig wrote:
The first release candidate for 0.8.1 is out, notably containing some 
API fixes (mostly missing @safe annotations), as well as a bunch of 
improvements in the HTTP sub system. Full change log:


https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md

0.8.1-rc.1 on code.dlang.org:
http://code.dlang.org/packages/vibe-d/0.8.1-rc.1

The release is scheduled for Monday the 28th. Some time after, there 
will also be a 0.7.x release, which has the fixes that went into 0.8.0 
and 0.8.1 backported, to keep the 0.7 branch alive for a bit longer.


Do you anticipate that support for OpenSSL 1.1 will be provided in the 
0.8.1 release?  Lack of support is blocking my compilation with vibe on 
Fedora 26.


Good point, I managed to forget about that. I'll at least include a 
manual solution that works with a version constant VibeUseOpenSSL11 or 
similar. Robert Schadek fortunately has a PR already open that just 
needs to be adjusted a bit.

Release candidate vibe.d 0.8.1-rc.1

[Sönke Ludwig via Digitalmars-d-announce]

The first release candidate for 0.8.1 is out, notably containing some 
API fixes (mostly missing @safe annotations), as well as a bunch of 
improvements in the HTTP sub system. Full change log:


https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md

0.8.1-rc.1 on code.dlang.org:
http://code.dlang.org/packages/vibe-d/0.8.1-rc.1

The release is scheduled for Monday the 28th. Some time after, there 
will also be a 0.7.x release, which has the fixes that went into 0.8.0 
and 0.8.1 backported, to keep the 0.7 branch alive for a bit longer.

Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept

[Sönke Ludwig via Digitalmars-d-announce]

Am 21.07.2017 um 09:40 schrieb Andrea Fontana:

It has a lot of potential. I always hope that someone will start a 3d
Printer firmware written in D for a 32bit microcontroller.


I've actually started to implement a GCode processor in D a while ago, 
because I was unsatisfied with the open source firmwares that exist. 
It's more tailored towards CNC routers, but since those are pretty 
similar that shouldn't be a big problem. The bad news is that I don't 
have time to work on it anymore and it was still at a relatively early 
stage.

Re: Released vibe-core 1.0.0 and vibe.d 0.8.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 16.07.2017 um 11:17 schrieb Sönke Ludwig:

(...)

However, I just noticed that this is still possible to exploit in the
Markdown processor. User defined HTML is filtered, but link targets are
passed to the rendered HTML as-is (just HTML encoded).


https://github.com/rejectedsoftware/vibe.d/pull/1846

Re: Released vibe-core 1.0.0 and vibe.d 0.8.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 15.07.2017 um 23:54 schrieb tetyys:

very nice!

one question about the https://github.com/rejectedsoftware/vibe.d/commit/e4a600f911218c49f9984734b8ba36f193e99c17


wouldn't this
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#Image_XSS_using_the_JavaScript_directive
pass normally?


If a user supplied image URL is passed to the "src" attribute unchecked, 
then yes. But this would work regardless of the JSON escape rules and 
really needs to be prevented by the application code.


However, I just noticed that this is still possible to exploit in the 
Markdown processor. User defined HTML is filtered, but link targets are 
passed to the rendered HTML as-is (just HTML encoded).

Re: Released vibe-core 1.0.0 and vibe.d 0.8.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 11.07.2017 um 15:13 schrieb Jack Applegame:

slightly reduced

/+ dub.json:
 {
 "name": "test",
 "versions": ["VibeManualMemoryManagement"],
 "dependencies": {
 "vibe-d": "~>0.8.0"
 }
 }
+/

module main;

import std.conv;
import std.stdio;
import vibe.http.client;

void main() {
 HTTPStatus status;
 requestHTTP("https://steamcommunity.com;, (scope request) {}, 
(scope response) {

 status = response.statusCode.to!HTTPStatus;
 response.dropBody();
 });
 writefln("status: %s", status);
}


Thanks! I've pushed a fix for 0.8.1: 
https://github.com/rejectedsoftware/vibe.d/commit/c0a5050088d41b726984e3beb71b9a976aaf2ba8

Re: Released vibe-core 1.0.0 and vibe.d 0.8.0

[Sönke Ludwig via Digitalmars-d-announce]

Note: Due to recent issues with OpenSSL, the way OpenSSL/Botan get 
selected as the TLS provider has changed. If you are using Botan, you'll 
have to explicitly select the "botan" configuration of the new 
"vibe-d:tls" package:


dependency "vibe-d:tls" version="~>0.8.0"
subConfiguration "vibe-d:tls" "botan"

or for dub.json:

"dependencies": {
...
"vibe-d:tls": "~>0.8.0"
},
"subConfigurations": {
...
"vibe-d:tls": "botan"
}

Re: Released vibe-core 1.0.0 and vibe.d 0.8.0

[Sönke Ludwig via Digitalmars-d-announce]

Am 10.07.2017 um 15:24 schrieb Steven Schveighoffer:

On 7/10/17 8:11 AM, Sönke Ludwig wrote:

BTW, @CyberShadow, I originally sent this using a NG client, but the 
thread never appeared on forum.dlang.org


Even this one isn't there... Should be here: 
http://forum.dlang.org/post/mmfrsonxrfxwltkfv...@forum.dlang.org


-Steve


Opened a ticket: https://github.com/CyberShadow/DFeed/issues/87

Released vibe-core 1.0.0 and vibe.d 0.8.0

[Sönke Ludwig via Digitalmars-d-announce]

After a long journey - it took over eight months - the new core package 
is finally ready. Along with it, version 0.8.0 of vibe.d is released. 
This marks a major milestone in vibe.d's development.


Apart from offering support for using the new core package, 0.8.0 now 
also employs @safe and nothrow where possible, making it possible to 
write fully @safe vibe.d applications. And of course, as always, there 
is also a long list of other improvements and bug fixes.


The core package can be considered as a complete rewrite of the original 
vibe-d:core package, retaining a mostly backwards compatible API from a 
library user's point of view. Lots of changes went into modernizing the 
code and removing inherent performance limits of the previous design*.


See the dedicated blog post for a basic explanation of the changes:
https://vibed.org/blog/posts/introducing-vibe-core

The change log for vibe.d 0.8.0 is listed here:
https://vibed.org/blog/posts/vibe-release-0.8.0

Finally, to make use of the vibe-core module, which is highly 
recommended outside of critical production systems, you'll have to 
manually enable it in the package recipe of your project:


- dub.sdl:
dependency "vibe-d:core" version="~>0.8.0"
subConfiguration "vibe-d:core" "vibe-core"

- dub.json:
{
...
"dependencies" : {
...
"vibe-d:core": "~>0.8.0"
},
"subConfigurations": {
...
"vibe-d:core": "vibe-core"
}
}

DUB packages:
https://code.dlang.org/packages/vibe-d/0.8.0
https://code.dlang.org/packages/vibe-core/1.0.0

* Note that no dedicated performance tuning has been done yet, so 
performance levels are expected to still be on a similar level.


(Note: this is the third try to get this in the forum, this time from a 
different IP)

Released vibe-core 1.0.0 and vibe.d 0.8.0

[Sönke Ludwig via Digitalmars-d-announce]

After a long journey - it took over eight months - the new core 
package is finally ready. Along with it, version 0.8.0 of vibe.d 
is released. This marks a major milestone in vibe.d's development.


Apart from offering support for using the new core package, 0.8.0 
now also employs @safe and nothrow where possible, making it 
possible to write fully @safe vibe.d applications. And of course, 
as always, there is also a long list of other improvements and 
bug fixes.


The core package can be considered as a complete rewrite of the 
original vibe-d:core package, retaining a mostly backwards 
compatible API from a library user's point of view. Lots of 
changes went into modernizing the code and removing inherent 
performance limits of the previous design*.


See the dedicated blog post for a basic explanation of the 
changes:

https://vibed.org/blog/posts/introducing-vibe-core

The change log for vibe.d 0.8.0 is listed here:
https://vibed.org/blog/posts/vibe-release-0.8.0

Finally, to make use of the vibe-core module, which is highly 
recommended outside of critical production systems, you'll have 
to manually enable it in the package recipe of your project:


- dub.sdl:
dependency "vibe-d:core" version="~>0.8.0"
subConfiguration "vibe-d:core" "vibe-core"

- dub.json:
{
...
"dependencies" : {
...
"vibe-d:core": "~>0.8.0"
},
"subConfigurations": {
...
"vibe-d:core": "vibe-core"
}
}

DUB packages:
https://code.dlang.org/packages/vibe-d/0.8.0
https://code.dlang.org/packages/vibe-core/1.0.0

* Note that no dedicated performance tuning has been done yet, so 
performance levels are expected to still be on a similar level.



BTW, @CyberShadow, I originally sent this using a NG client, but 
the thread never appeared on forum.dlang.org

Released vibe-core 1.0.0 and vibe.d 0.8.0

[Sönke Ludwig via Digitalmars-d-announce]

After a long journey - it took over eight months - the new core package 
is finally ready. Along with it, version 0.8.0 of vibe.d is released. 
This marks a major milestone in vibe.d's development.


Apart from offering support for using the new core package, 0.8.0 now 
also employs @safe and nothrow where possible, making it possible to 
write fully @safe vibe.d applications. And of course, as always, there 
is also a long list of other improvements and bug fixes.


The core package can be considered as a complete rewrite of the original 
vibe-d:core package, retaining a mostly backwards compatible API from a 
library user's point of view. Lots of changes went into modernizing the 
code and removing inherent performance limits of the previous design*.


See the dedicated blog post for a basic explanation of the changes:
https://vibed.org/blog/posts/introducing-vibe-core

The change log for vibe.d 0.8.0 is listed here:
https://vibed.org/blog/posts/vibe-release-0.8.0

Finally, to make use of the vibe-core module, which is highly 
recommended outside of critical production systems, you'll have to 
manually enable it in the package recipe of your project:


- dub.sdl:
dependency "vibe-d:core" version="~>0.8.0"
subConfiguration "vibe-d:core" "vibe-core"

- dub.json:
{
...
"dependencies" : {
...
"vibe-d:core": "~>0.8.0"
},
"subConfigurations": {
...
"vibe-d:core": "vibe-core"
}
}

DUB packages:
https://code.dlang.org/packages/vibe-d/0.8.0
https://code.dlang.org/packages/vibe-core/1.0.0

* Note that no dedicated performance tuning has been done yet, so 
performance levels are expected to still be on a similar level.

Re: Release candidates vibe.d 0.8.0-rc.6 and vibe-core 1.0.0-rc.4

[Sönke Ludwig via Digitalmars-d-announce]

There have been two more regression fixes:

- (De)serialization of self-referential types was broken (@safe related 
compile error)

- The .parentPath property of the new path types in vibe-core was broken

The release date is still scheduled for Monday.

Re: Release candidates vibe.d 0.8.0-rc.3 and vibe-core 1.0.0-rc.3

[Sönke Ludwig via Digitalmars-d-announce]

Am 01.07.2017 um 21:33 schrieb tetyys:
Are you planning/Did you consider to support wildcards in @path 
attribure when using registerWebInterface?


@path takes a string that is passed as-is to URLRouter, so it supports 
the limited trailing wildcard ("/foo/*"), as well as the path segment 
placeholders ("/foo/:bar/"). Arbitrary wildcards are definitely a 
natural generalization and should also be implemented one day.


Only the implementation is a little bit complicated, because they need 
to be transformed into the same DFA representation that is used to match 
placeholders, including mixtures of the two and the appropriate 
fallbacks if there are multiple partial matches on the way to a full match.


So in the end, because I didn't have a need for this so far and because 
of the relatively high implementation cost, I don't currently have this 
on the radar.

Release candidates vibe.d 0.8.0-rc.3 and vibe-core 1.0.0-rc.3

[Sönke Ludwig via Digitalmars-d-announce]

Building on DMD 2.075.0-b1, as well as 
https://github.com/rejectedsoftware/vibe.d/issues/1757 have been fixed 
and the third release candidate has been tagged. The new release date is 
Wednesday the 5th of July.

Release candidates vibe.d 0.8.0-rc.2 and vibe-core 1.0.0-rc.2

[Sönke Ludwig via Digitalmars-d-announce]

Am 22.06.2017 um 10:55 schrieb Sönke Ludwig:

After a last minute path type redesign, the state of the new vibe-core
package now finally feels ready for the first official release. The
library is in a pretty good shape, with the notable exception that
sockets are not yet implemented on Windows in the new eventcore
abstraction layer. This will be tackled ASAP, but is independent from
vibe-core itself in terms of code dependencies.

Change logs for vibe.d 0.8.0 (over 0.7.31) and vibe-core 1.0.0 (over
vibe-d:core) respectively can be reviewed on GitHub:

https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md
https://github.com/vibe-d/vibe-core/blob/master/CHANGELOG.md

Testing can be done by selecting the "vibe-core" configuration of the
":core" sub module:

// dub.sdl:
dependency "vibe-d:core" version="~>0.8.0-rc"
subConfiguration "vibe-d:core" "vibe-core"

// dub.json:
"dependencies": {
"vibe-d:core": "~>0.8.0-rc"
},
"subConfigurations": {
"vibe-d:core": "vibe-core"
}

The final release is scheduled for Monday unless any regressions come up
until them.


There have been some minor fixes and vibe.d 0.8.0-rc.2 and vibe-core 
1.0.0-rc.2 have been tagged. The final release is rescheduled for 
Monday, July the 3rd.

Re: DirectX bindings

[Sönke Ludwig via Digitalmars-d-announce]

Am 22.06.2017 um 11:09 schrieb evilrat:

On Sunday, 3 November 2013 at 05:27:24 UTC, evilrat wrote:


https://github.com/evilrat666/directx-d



I'm sorry to say that, but I have to quit the post of DirectX bindings 
maintainer. I haven't yet decided on what to do with dub package[1], but 
I'm in favor of completely deleting it so the next maintainer or D 
foundation can step in, that way there should be little to no code 
breakage occurs and most users won't even notice a change. My current 
estimate is to drop it till the end of month.
I will probably continue to maintain github repository for few months 
for my personal needs though.


[1] http://code.dlang.org/packages/directx-d


I don't know how much the package is currently in use (I still use my 
own partial bindings that I hacked together a while ago for example), 
but, at least if you'll continue to be able to react when a new 
maintainer steps up, I would suggest to simply keep the DUB package 
there in standby. Removing it without having a replacement ready will 
just potentially break code for no real benefit.

Re: Release candidates vibe.d 0.8.0-rc.1 and vibe-core 1.0.0-rc.1

[Sönke Ludwig via Digitalmars-d-announce]

Am 22.06.2017 um 20:52 schrieb aberba:

On Thursday, 22 June 2017 at 08:55:06 UTC, Sönke Ludwig wrote:
After a last minute path type redesign, the state of the new vibe-core 
package now finally feels ready for the first official release. The 
library is in a pretty good shape, with the notable exception that 
sockets are not yet implemented on Windows in the new eventcore 
abstraction layer. This will be tackled ASAP, but is independent from 
vibe-core itself in terms of code dependencies.


[...]


Thw Websocket api seem a little low-level (unclear) compared to the feel 
of http server. I'm not sure if its on purpose or could use some future 
api design/abstraction.


Vibe.d is really great.


Agreed, there are several places in there that can be improved or made 
more consistent. The HTTP package (including WebSockets) is the next big 
part that is up for a complete redesign, also (finally) including HTTP/2 
support. Since I'm really busy with another project I can't state a 
reliable schedule for this, but I'll try to start in the near future and 
will also to try to involve interested people in the design/development 
process as early as that makes sense.

Release candidates vibe.d 0.8.0-rc.1 and vibe-core 1.0.0-rc.1

[Sönke Ludwig via Digitalmars-d-announce]

After a last minute path type redesign, the state of the new vibe-core 
package now finally feels ready for the first official release. The 
library is in a pretty good shape, with the notable exception that 
sockets are not yet implemented on Windows in the new eventcore 
abstraction layer. This will be tackled ASAP, but is independent from 
vibe-core itself in terms of code dependencies.


Change logs for vibe.d 0.8.0 (over 0.7.31) and vibe-core 1.0.0 (over 
vibe-d:core) respectively can be reviewed on GitHub:


https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md
https://github.com/vibe-d/vibe-core/blob/master/CHANGELOG.md

Testing can be done by selecting the "vibe-core" configuration of the 
":core" sub module:


// dub.sdl:
dependency "vibe-d:core" version="~>0.8.0-rc"
subConfiguration "vibe-d:core" "vibe-core"

// dub.json:
"dependencies": {
"vibe-d:core": "~>0.8.0-rc"
},
"subConfigurations": {
"vibe-d:core": "vibe-core"
}

The final release is scheduled for Monday unless any regressions come up 
until them.

Re: derelict-git2: A dynamic binding to libgit2 library

[Sönke Ludwig via Digitalmars-d-announce]

Am 18.06.2017 um 16:09 schrieb Anton Fediushin:

I am happy to announce the derelict-git2.

derelict-git2 is a dynamic binding to libgit2 v0.25.1 (latest stable 
release) for the D programming language.


I created it because existing binding[1] is dead as well as high-level 
wrapper[2].
Dynamic bindings are much easier to use, although they are more complex 
in development.


Also, I could help if somebody wants to create a wrapper on top of 
derelict-git2.


Check out project page on dub: http://derelict-git2.dub.pm
And create an issue on GitHub: https://github.com/ohdatboi/derelict-git2

[1] http://code.dlang.org/packages/libgit2
[2] http://code.dlang.org/packages/dlibgit


I haven't done anything on the high level wrapper for a while, because I 
didn't have the need for it, but I wouldn't call it dead. Unfortunately, 
the two PRs to upgrade to 0.25.1 have slipped past me, though - the one 
changing the bindings is merged now.


But the thing with libgit2 is that it is extremely annoying how quickly 
they break the API, especially since many different versions have to be 
supported at the same time as long as using the system packaged version 
is supposed to be possible.

Re: Release vibe.d 0.7.31

[Sönke Ludwig via Digitalmars-d-announce]

Am 12.04.2017 um 12:03 schrieb Martin Nowak:

Thanks

On Monday, 10 April 2017 at 20:48:34 UTC, Sönke Ludwig wrote:

  - Compiles on the latest DMD version (2.068.x-2.072.0)


2.068.x-2.074.0, that is



True, thanks for the notice!

Re: Release vibe.d 0.7.31

[Sönke Ludwig via Digitalmars-d-announce]

Am 12.04.2017 um 20:29 schrieb Nick Sabalausky (Abscissa):

On 04/10/2017 04:48 PM, Sönke Ludwig wrote:

The 0.7.x branch will continue to be maintained for a short
while, but only bug fixes will be included from now on. Applications
should switch to the 0.8.x branch as soon as possible.



If a library depends on vibe, but wants to allow its users to use either
0.7.x or 0.8.x, is there a recommended way to do that?

Ie: https://github.com/mysql-d/mysql-native/issues/99



I use ">=0.7.31 <0.9.0" in one of my projects for that purpose. Some 
kind of union operator would be nicer (e.g. "~>0.7.31 | ~>0.8.0"), but 
for all practical purposes I think it should be fine.

Release vibe.d 0.7.31

[Sönke Ludwig via Digitalmars-d-announce]

This release is a backport release of the smaller changes that go into 
0.8.0. The 0.7.x branch will continue to be maintained for a short 
while, but only bug fixes will be included from now on. Applications 
should switch to the 0.8.x branch as soon as possible.


Main changes over 0.7.30:

  - Compiles on the latest DMD version (2.068.x-2.072.0)
  - Introduces a number of forward compatibility declarations for the
0.8.0 branch and vibe-core
  - The HTTP server received various improvements
  - All changes: https://vibed.org/blog/posts/vibe-release-0.7.31

DUB package:
https://code.dlang.org/packages/vibe-d/0.7.31

vibe.d 0.7.31-rc.3 release candidate

[Sönke Ludwig via Digitalmars-d-announce]

The third release candidate of 0.7.31 has been tagged (the two previous 
ones still had issues, so I skipped the announcement). Contrary to the 
initial plan, 0.7.31 will be released prior to 0.8.0, which still can 
use a little more time to mature.


If you plan to stay on the 0.7.x branch, please take the opportunity to 
test this (e.g. keep dependency to `~>0.7.30` and then do `dub upgrade 
--prerelease`). The final release is scheduled for next Monday (April 10th).


Change log:
https://github.com/rejectedsoftware/vibe.d/blob/0.7.x/CHANGELOG.md

DUB: https://code.dlang.org/packages/vibe-d/0.7.31-rc.3

Re: vibe.d 0.8.0 and 0.7.31 beta releases

[Sönke Ludwig via Digitalmars-d-announce]

Am 28.03.2017 um 15:46 schrieb John Colvin:

On Thursday, 9 February 2017 at 19:40:45 UTC, Sönke Ludwig wrote:

Am 09.02.2017 um 18:00 schrieb Kagamin:

On Wednesday, 8 February 2017 at 15:18:34 UTC, Sönke Ludwig wrote:

The problem is that there are two affected call stacks - the @system
API function that registers the @system callback, wrapping/casting it
as @trusted, and the event handler that later on actually calls the
callback. The latter place is where the hidden violation of the @safe
guarantees happens.


Hidden from whom? Since it's user, who supplies @system code to vibe, he
knows that the resulting program doesn't provide @safe guarantees.
It can be communicated at the API level:

int f(@safe void delegate() dg) @safe
{ code }
int f(@system void delegate() dg) @system
{ return f(cast(@safe void delegate())dg); }

So that unsafe overload would be only callable from unsafe code.


Hidden from the code that calls the callback. This may be an
acceptable trade off in this particular case, because this is crossing
a library border, but in general this is just misuse of the safety
system, since the effects of the cast leave the scope of
@system/@trusted.

I don't know, I don't really like this, but maybe I should just
postpone the `deprecated` attribute to be added for 0.8.1 to leave
more room for a final decision.


Just ran in to this trying to update a large project to 0.7.31-rc.2. The
change to HTTPServerRequestDelegate breaks code where we have @system
callbacks that it would not be sensible to make @trusted at the moment.
What can we do?


Are you sure that you didn't get 0.8.0-beta.x by accident? The 0.7.31 
release shouldn't contain any safety related changes. 0.8.0 is supposed 
to handle any @system-callbacks gracefully, though, can you post the 
line that fails, possibly along with the signature of the handler function?

Re: Introducing Diskuto - an embeddable comment system

[Sönke Ludwig via Digitalmars-d-announce]

Am 19.03.2017 um 12:13 schrieb MrSmith:

On Tuesday, 14 March 2017 at 11:17:57 UTC, Sönke Ludwig wrote:

Any comments suggestions and especially helping hands are highly
appreciated!


Would be nice to undo/change votes. I accidentally clicked -1 and can't
undo it.


Good point, I was a bit worried about this myself, and the fact that it 
directly occurred in practice suggests that this indeed needs to be 
improved.

Re: Introducing Diskuto - an embeddable comment system

[Sönke Ludwig via Digitalmars-d-announce]

Am 17.03.2017 um 18:30 schrieb Suliman:

On Friday, 17 March 2017 at 16:42:28 UTC, Sönke Ludwig wrote:

Am 17.03.2017 um 16:42 schrieb cym13:

On Wednesday, 15 March 2017 at 02:14:34 UTC, Sönke Ludwig wrote:

Am 14.03.2017 um 21:56 schrieb Daniel Kozak via Digitalmars-d-announce:

Dne 14.3.2017 v 21:24 Sönke Ludwig via Digitalmars-d-announce
napsal(a):


Did you delete the comments yourself? The time limit for
deletion/editing currently isn't enforced on the server (ticket
already open), so anyone can delete their own tickets currently at
any
time.

I've noted the other issues and will tackle those tomorrow.

I have deleted not only my comments, I can delete enyone comment


Okay, that was supposed to be implemented before 1.0.0, but then I
forgot about it:
https://github.com/rejectedsoftware/diskuto/blob/d8376f3e54a03574f69af13a0b41b5e994b6ce44/source/diskuto/web.d#L107




You'll also want a CSRF token for that, checking that the user is the
author isn't enough.


True, I have that and some other standard measures planned, but for
now I wanted to concentrate on getting the general functionality and
layout done. On the "security" side, simple moderation and registered
user support is now in but still needs some additions, and the spam
filter integration still needs a little work.

IMO, those are the most important things for the start, because
realistically nobody is going to implement a CSRF attack against this
in the foreseeable future, and even if, the impact would be extremely
limited (since only posts of the last 15 minutes can be changed anyways).


Please add oAuth with Google instead anti-spam. I really captcha end
other stupid system where computer make decision enough am I human or no.

Also auth with Telegram is very good thing. I think it would enough for
90% of users.


The idea is to allow anonymous comments, at least if a site wants to 
support it, because that can often reduce the initial entry barrier 
considerably, even compared against a convenient OAuth login.


But the idea is that all kinds of authentication mechanisms can be 
plugged in using the relatively trivial `DiskutoUserStore` interface. So 
anyone can use their favorite means. I'd of course accept pull requests 
to include a range of default options, but I'll probably not have the 
time to do that myself.

Re: Introducing Diskuto - an embeddable comment system

[Sönke Ludwig via Digitalmars-d-announce]

Am 17.03.2017 um 16:42 schrieb cym13:

On Wednesday, 15 March 2017 at 02:14:34 UTC, Sönke Ludwig wrote:

Am 14.03.2017 um 21:56 schrieb Daniel Kozak via Digitalmars-d-announce:

Dne 14.3.2017 v 21:24 Sönke Ludwig via Digitalmars-d-announce napsal(a):


Did you delete the comments yourself? The time limit for
deletion/editing currently isn't enforced on the server (ticket
already open), so anyone can delete their own tickets currently at any
time.

I've noted the other issues and will tackle those tomorrow.

I have deleted not only my comments, I can delete enyone comment


Okay, that was supposed to be implemented before 1.0.0, but then I
forgot about it:
https://github.com/rejectedsoftware/diskuto/blob/d8376f3e54a03574f69af13a0b41b5e994b6ce44/source/diskuto/web.d#L107



You'll also want a CSRF token for that, checking that the user is the
author isn't enough.


True, I have that and some other standard measures planned, but for now 
I wanted to concentrate on getting the general functionality and layout 
done. On the "security" side, simple moderation and registered user 
support is now in but still needs some additions, and the spam filter 
integration still needs a little work.


IMO, those are the most important things for the start, because 
realistically nobody is going to implement a CSRF attack against this in 
the foreseeable future, and even if, the impact would be extremely 
limited (since only posts of the last 15 minutes can be changed anyways).

Re: Introducing Diskuto - an embeddable comment system

[Sönke Ludwig via Digitalmars-d-announce]

Am 16.03.2017 um 08:30 schrieb Sönke Ludwig:

Am 15.03.2017 um 21:30 schrieb Nick Sabalausky (Abscissa):

Nice. The only example code uses diet templates though, how would one
embed this when not using diet?


I'll add two more examples - one using only JavaScript to embed the
comments, which also works for non-D applications, and one using
`compileDietHTMLFile`, writing the HTML directly to an output range.


The latest version now offers three embedding modes:
https://github.com/rejectedsoftware/diskuto/tree/master/examples

User accounts and simple moderation are also supported now. The 
embed-diet example shows how this can be plugged in.

Re: Introducing Diskuto - an embeddable comment system

[Sönke Ludwig via Digitalmars-d-announce]

Am 15.03.2017 um 21:30 schrieb Nick Sabalausky (Abscissa):

Nice. The only example code uses diet templates though, how would one
embed this when not using diet?


I'll add two more examples - one using only JavaScript to embed the 
comments, which also works for non-D applications, and one using 
`compileDietHTMLFile`, writing the HTML directly to an output range.

Re: Introducing Diskuto - an embeddable comment system

[Sönke Ludwig via Digitalmars-d-announce]

Just implemented a visual overhaul - the "reply" buttons are gone and 
are replaced by the comment text box itself. This results in a less 
noisy page and one less click to make a reply.


Any opinions on replacing Disqus with this on http://dlang.org/library/?

Re: Introducing Diskuto - an embeddable comment system

[Sönke Ludwig via Digitalmars-d-announce]

On Wednesday, 15 March 2017 at 10:40:31 UTC, aberba wrote:


The load balancer you were working on. Was it intended to 
handle DDoS attacks and what is the current status.


Being somewhat resistant to DDoS attacks is one of the secondary 
goals, but by the nature of it it would be very limited in what 
it can achieve there. A large scale cloud based approach is the 
only real solution.


The project is currently on hold. I'd still like to finish it, 
but I had to resort to other solutions for the time being (lack 
of time).

Re: Introducing Diskuto - an embeddable comment system

[Sönke Ludwig via Digitalmars-d-announce]

Improvements implemented by now:

- Authorization and time limit (5min client facing, 15min server facing) 
is now enforced for editing and deleting comments
- The page must be queried first before any action is allowed (prevents 
trivial command line batch "attacks", as well as trivial spam automation)
- The main comment form is minimized by default (only the text area, 
single-line height)

- Maximum height of comments limited (will show scroll bars if exceeded)
- Temporal boosting limited to hours instead of days
- E-mail and website length limited
- Message contents don't overflow the content area
- Displayed comment count corrected

Some changes may require Ctrl+F5 to refresh the cache.

Thanks to everyone who helped testing the boundaries so far! This 
definitely sped up the initial finalization phase by a large margin. 
There are still some open points, but this gets close to being a 
complete product:


- Implement moderation (!) and user registration to avoid identity 
spoofing (pluggable source user database)
- Additional heuristics to prevent batch operations from a single 
client, possibly just showing a CAPTCHA for IPs that show a high 
frequency of operations on the same topic(s)
- Work out how to best limit the visual or functional nesting level of 
comments

- Translations to more languages

Re: Introducing Diskuto - an embeddable comment system

[Sönke Ludwig via Digitalmars-d-announce]

Am 14.03.2017 um 20:09 schrieb aberba:

On Tuesday, 14 March 2017 at 11:17:57 UTC, Sönke Ludwig wrote:

So I was able to reserve the last two days to work on something new,
and one thing that is currently rather lacking in the D/vibe.d web
ecosystem is embedded commenting, be it for vibe.d's own blog engine
[1]/[2] or for the DDOX based standard library documentation [3]. So I
went ahead and created a little comment engine inspired by Disqus and
Isso:

[...]


How deep (levels) can it handle sub comments?


It's currently unlimited, but I guess that either a functional or a 
visual limit of some sort needs to be defined. I'd probably make that 
configurable, because the sweet spot depends on the intended purpose of 
the comment section - real discussions or mainly just answers+comments 
(StackOverflow) or comments+answers (blog).

Re: Introducing Diskuto - an embeddable comment system

[Sönke Ludwig via Digitalmars-d-announce]

Am 14.03.2017 um 21:56 schrieb Daniel Kozak via Digitalmars-d-announce:

Dne 14.3.2017 v 21:24 Sönke Ludwig via Digitalmars-d-announce napsal(a):


Did you delete the comments yourself? The time limit for
deletion/editing currently isn't enforced on the server (ticket
already open), so anyone can delete their own tickets currently at any
time.

I've noted the other issues and will tackle those tomorrow.

I have deleted not only my comments, I can delete enyone comment


Okay, that was supposed to be implemented before 1.0.0, but then I 
forgot about it:

https://github.com/rejectedsoftware/diskuto/blob/d8376f3e54a03574f69af13a0b41b5e994b6ce44/source/diskuto/web.d#L107

Re: Introducing Diskuto - an embeddable comment system

[Sönke Ludwig via Digitalmars-d-announce]

On Tuesday, 14 March 2017 at 20:02:08 UTC, Daniel Kozak wrote:



Dne 14.3.2017 v 20:54 Azbuka via Digitalmars-d-announce 
napsal(a):

On Tuesday, 14 March 2017 at 19:39:08 UTC, Daniel Kozak wrote:


Sorry but I do not see it. Which one?


Looks like it have been deleted. Okay, 2k upvotes is too much. 
I'll make it 100.


curl 'http://rejectedsoftware.com:10888/diskuto/delete' -H 
'Origin: http://rejectedsoftware.com:10888' -H 
'Accept-Encoding: gzip, deflate' -H 'Accept-Language: 
cs-CZ,cs;q=0.8' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 
Safari/537.36 OPR/43.0.2442.1144' -H 'Content-type: 
application/json' -H 'Accept: */*' -H 'Referer: 
http://rejectedsoftware.com:10888/' -H 'Cookie: 
vibe.session_id=QVwY1IGbGeELZw0v77w74RdDbQOKTheyQx8gi3HAQOWi6PTEQoRAxbUWUFmmLNq95FE5nyZ1Og47SCeu5v6oog' -H 'Connection: keep-alive' --data-binary '{"id":""}' --compressed


Did you delete the comments yourself? The time limit for 
deletion/editing currently isn't enforced on the server (ticket 
already open), so anyone can delete their own tickets currently 
at any time.


I've noted the other issues and will tackle those tomorrow.

Re: Introducing Diskuto - an embeddable comment system

[Sönke Ludwig via Digitalmars-d-announce]

Am 14.03.2017 um 14:48 schrieb Faux Amis:

Started a temporary instance for hands-on testing:
http://rejectedsoftware.com:10888/


Updated I see ;)


Yeah, still tweaking a few things here and there. Very helpful to have 
people try out weird things ;) I'm just not sure how well that will work 
after someone posts this to Reddit.

Re: Introducing Diskuto - an embeddable comment system

[Sönke Ludwig via Digitalmars-d-announce]

Am 14.03.2017 um 12:17 schrieb Sönke Ludwig:

So I was able to reserve the last two days to work on something new, and
one thing that is currently rather lacking in the D/vibe.d web ecosystem
is embedded commenting, be it for vibe.d's own blog engine [1]/[2] or
for the DDOX based standard library documentation [3]. So I went ahead
and created a little comment engine inspired by Disqus and Isso:

https://github.com/rejectedsoftware/diskuto (screenshot inside)
https://code.dlang.org/packages/diskuto

It has a similar tree based structure with user voting, doesn't require
registration and a basic set of functionality works without JavaScript
support.

Currently the only backend supported is MongoDB, but adding more is
rather simple. Using NNTP as the target, as was discussed a few times in
the past, is slightly tricky because editing and comment deletion needs
to be supported. However, there is a limited time frame for those
operations, so afterwards messages could be mirrored to a newsgroup
safely (the other way around would of course always work).

Any comments suggestions and especially helping hands are highly
appreciated!

[1]: https://github.com/rejectedsoftware/vibenews
[2]: https://vibed.org/blog/
[3]: https://dlang.org/library/


Started a temporary instance for hands-on testing:
http://rejectedsoftware.com:10888/

Introducing Diskuto - an embeddable comment system

[Sönke Ludwig via Digitalmars-d-announce]

So I was able to reserve the last two days to work on something new, and 
one thing that is currently rather lacking in the D/vibe.d web ecosystem 
is embedded commenting, be it for vibe.d's own blog engine [1]/[2] or 
for the DDOX based standard library documentation [3]. So I went ahead 
and created a little comment engine inspired by Disqus and Isso:


https://github.com/rejectedsoftware/diskuto (screenshot inside)
https://code.dlang.org/packages/diskuto

It has a similar tree based structure with user voting, doesn't require 
registration and a basic set of functionality works without JavaScript 
support.


Currently the only backend supported is MongoDB, but adding more is 
rather simple. Using NNTP as the target, as was discussed a few times in 
the past, is slightly tricky because editing and comment deletion needs 
to be supported. However, there is a limited time frame for those 
operations, so afterwards messages could be mirrored to a newsgroup 
safely (the other way around would of course always work).


Any comments suggestions and especially helping hands are highly 
appreciated!


[1]: https://github.com/rejectedsoftware/vibenews
[2]: https://vibed.org/blog/
[3]: https://dlang.org/library/

Re: Project Highlight: vibe.d

[Sönke Ludwig via Digitalmars-d-announce]

Am 01.03.2017 um 14:38 schrieb Mike Parker:

Most of us here are already familiar with vibe.d. In this post, Sönke
talks a bit about why he started it and why & how he's breaking it up
into independent packages.

Post:
https://dlang.org/blog/2017/03/01/project-highlight-vibe-d/

Reddit:
https://www.reddit.com/r/programming/comments/5wvs91/project_highlight_vibed_an_io_concurrency_and_web/



Thanks for doing the post Mike! That means I could at least get out some 
of the things that I intended to talk about at Dconf (didn't make it in 
time again, each year just seems to get worse w.r.t. to my time budget).