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: I want change package name for dub , how to do it?

[Sönke Ludwig via Digitalmars-d]

Am 27.08.2018 um 12:25 schrieb Brian:

My team want change packages name:

hunt -> hunt-framework
entity -> hunt-entity
database -> hunt-database
cache -> hunt-cache

How to do it? Must delete package before add it again?


To avoid breaking dependencies, the best approach is this:

1. clone the repository
2. set the existing package to point to the cloned repository at 
code.dlang.org

3. change the name and create a new version tag
4. register the original repository again, picking up the new name

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:


DUB package:



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: ! No allerts ! code.dlang.org

[Sönke Ludwig via Digitalmars-d]

Am 07.05.2018 um 16:57 schrieb Martin Tschierschke:
I just want to send a big thank you to Martin Nowak and Sönke Ludwig and 
every one else running the infrastructure of DUB behind the scene!



This is the list of Weekly Reports from pingdom.com for code.dlang.org:


Pingdom Weekly Reports

2018-04-02 to 2018-04-08 (partly)
CHECKS WITH DOWNTIME
     UPTIME DOWNTIME OUTAGES RESPONSE TIME
Code 90.00% 2h 45m 00s 9 725 ms


2018-04-09 to 2018-04-15
CHECKS WITH DOWNTIME
     UPTIME DOWNTIME OUTAGES RESPONSE TIME
Code 94.49% 9h 15m 00s 43 694 ms

2018-04-16 to 2018-04-22
CHECKS WITH DOWNTIME
     UPTIME DOWNTIME OUTAGES RESPONSE TIME
Code 97.12% 4h 50m 00s 4 571 ms

2018-04-23 to 2018-04-29
OUTAGES: None

CHECKS WITHOUT DOWNTIME
     UPTIME DOWNTIME OUTAGES RESPONSE TIME
Code 100.00% 0h 00m 00s 0 564 ms
     ^^^

@Martin Nowak, please make a post about the new server infrastructure @ 
announce!


Hi Martin, just wanted to note that the registry currently still runs on 
a VPS of mine, although on a different one that has a lot more free 
resources (memory). Martin Nowak's setup is still work in progress, but 
at least we have something stable until then.

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

Re: DUB: Only fetch and cache packages in dub.json without running build

[Sönke Ludwig via Digitalmars-d]

Am 10.04.2018 um 15:50 schrieb Clinton:

Hi all,

I'm setting up a CircleCI config for my project. Right now I'm trying to 
cache dependencies before running builds. This way I can run "dub build 
--nodeps" immediately after the packages are cached to avoid extra 
network calls and speed it up.


I'm wondering if there's a way to isolate the part that downloads and 
caches all of the dependencies in dub.json without running the build.


Right now I have to run the build twice. First one, for the sake of 
downloading the dependencies and later for running if the cache exists. 
Having the build run the first time takes up a lot of time. I'm going 
for the "npm install" type of effect.


The reason the cache needs to be rebuilt each time is because CircleCI 
runs docker images. Once the deployment is finished, the image fs is 
destroyed so there's no way to hold onto the cache for future builds.


"dub upgrade --missing-only" should have the desired effect. It 
downloads everything and also resolved any possible missing version 
selections.

Re: Registering packages crashed DUB registry

[Sönke Ludwig via Digitalmars-d]

Am 07.04.2018 um 23:57 schrieb Sönke Ludwig:

Am 07.04.2018 um 21:49 schrieb 0xEAB:

Hello :)

Tried to add a new package, but after clicking on [Register package] I 
only get the following error:



502 Bad Gateway
nginx/1.6.2



Regards,
Elias



Bug report: https://github.com/dlang/dub/issues/1441
PR: https://github.com/dlang/dub-registry/pull/318


The fix is deployed on the server now, so registering packages should 
work correctly again now.

Re: Registering packages crashed DUB registry

[Sönke Ludwig via Digitalmars-d]

Am 07.04.2018 um 21:49 schrieb 0xEAB:

Hello :)

Tried to add a new package, but after clicking on [Register package] I 
only get the following error:



502 Bad Gateway
nginx/1.6.2



Regards,
Elias



Bug report: https://github.com/dlang/dub/issues/1441
PR: https://github.com/dlang/dub-registry/pull/318

Re: Space before parens in all function definitions

[Sönke Ludwig via Digitalmars-d]

Am 07.04.2018 um 04:23 schrieb Andrei Alexandrescu:

Why is there a space before "(" in our /library/ docs?

https://dlang.org/library/std/stdio/file.tmpfile.html

The paren here has role similar to that in mathematics, not literary.


Thanks,

Andrei


Has been a regression during the diet-ng transition. Fix in DDOX:

https://github.com/rejectedsoftware/ddox/pull/203

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: I didn't succeed in creating an empty project for a long time

[Sönke Ludwig via Digitalmars-d]

Am 08.03.2018 um 10:15 schrieb Sueko:

On Monday, 15 January 2018 at 11:15:41 UTC, Brian wrote:

zoujiaqing@Brian-XPS MINGW64 /d/Projects
$ dub init serializable -v
Using dub registry url 'https://code.dlang.org/'
Refreshing local packages (refresh existing: true)...
Looking for local package map at 
C:\ProgramData\dub\packages\local-packages.json
Looking for local package map at 
C:\Users\Brian\AppData\Roaming\dub\packages\local-packages.json

No package found in current working directory.


After a bit waiting the message will appear

Invalid format, "$ dub init projectName -t vibe.d -v", enter either 
"sdl" or "json".


Then you have to enter sdl or json in the cmd line, after all it works.
-Cheers


I just had a similar report from a computer that I may get direct access 
to, so that I can try to take the opportunity and debug it there. I 
could never reproduce it locally so far.


For reference: https://github.com/dlang/dub/issues/874

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: How to represent multiple files in a forum post?

[Sönke Ludwig via Digitalmars-d]

Am 14.02.2018 um 19:33 schrieb Jonathan Marler:

@timotheecour and I came up with a solution to a common problem:

How to represent multiple files in a forum post?



Why not multipart/mixed? Since this is NNTP based, wouldn't that be the 
natural choice? That it, assuming that forum.dlang.org is the target for 
this, of course.

Re: OT: Photo of a single atom by David Nadlinger wins top prize

[Sönke Ludwig via Digitalmars-d]

Am 14.02.2018 um 02:11 schrieb David Nadlinger:

On Tuesday, 13 February 2018 at 23:09:07 UTC, Ali Çehreli wrote:

David (aka klickverbot) is a longtime D contributor […]


… who is slightly surprised at the amount of media interest this has 
attracted. ;)


  — David


Also saw it cited by several independent people, pretty cool!

Re: Vibe-d issue with timer in separate thread on debug builds

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

Am 10.01.2018 um 15:40 schrieb Andres Clari:
Hi, I have an app that uses vibe tasks, fibers and timers extensively, 
and I found an issue only for debug builds, when canceling a timer. 
However the code in question works just fine in the release build.


But having this here makes testing certain things in my program a pain, 
since it'll crash on the assert in question:


vibe-d-0.8.2/vibe-d/core/vibe/core/drivers/libevent2.d:474
debug assert(m_ownerThread is () @trusted { return Thread.getThis(); } ());


Also, not sure I understand that assert properly... Is it checking the 
stop timer call is fired from the main thread the event loop is running? 
That would be bad, since basically that timer run from a child thread.


The basic requirement for almost all vibe.d primitives is that they may 
only be used within the same thread in which they were created. Anything 
else requires message passing (e.g. using std.concurrency) to issue the 
operation in the owner thread.


There incidentally is a recent thread on the vibe.d forum on this topic: 
https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/48663/

Re: need help with vibe.d receive()

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

Am 10.01.2018 um 15:39 schrieb crimaniak:

Hi!

I make multi-task event bus, but there is a problem with the task stops.
Please see end of file
https://github.com/crimaniak/d-vision/blob/master/src/vision/eventbus.d

Expected behavior: After sending the StopEvent message in line 244 it is 
must be detected in listeners (line 147), so all listeners must set exit 
flag to 'true' and quit immediately.
De-facto behavior: StopEvent() message is not detected by the first 
delegate in line 147 (logger task logs this message by the handler in 
line 185), so subscribed tasks never exit and test stops on line 248.


I tried to play with yield() and sleep(), with 'shared' attributes and 
so on, but without result. Can you say please what I am doing wrong here?


'dub test' can be used to play with tests.


The problem is with the `immutable struct StopEvent {}` declaration and 
the use of `shared(Unqual!StopEvent)` - `shared(StopEvent)` is actually 
reduced to just `StopEvent`, which internally is expanded to 
`immutable(StopEvent)` and `immutable` already implies `shared`.


However, `Unqual!StopEvent` actually removes the implicit `immutable` 
from the type, so that `shared(Unqual!StopEvent)` is really just 
`shared(StopEvent)` and consequently treated as a different type by 
`receive`.


So, removing the `immutable` from the declaration solved the issue for 
me, but if possible I'd rather remove the `cast(shared 
Unqual!EventType)` from `emit`, and pass `shared`/`immutable` events to 
it from the outside (or plain events with no unshared indirections).

Re: Module bug?

[Sönke Ludwig via Digitalmars-d]

Am 18.12.2017 um 13:14 schrieb Luís Marques:

Is this a bug?

foo/bar/baz.d:
     module foo.bar.baz;
     alias thisModule = foo.bar.baz;

$ dmd -main -I. foo/bar/baz.d
OK

foo/bar/baz.d:
     module foo.bar.baz;
     alias thisModule = foo.bar.baz;
     import foo;

foo/package.d:
     module foo;

$ dmd -main -I. foo/bar/baz.d
foo/bar/baz.d(2): Error: undefined identifier bar in module foo



https://issues.dlang.org/show_bug.cgi?id=11847
https://github.com/dlang/dmd/pull/7218

(had some trouble finding it due to the changed title)

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

Re: Adding Markdown to Ddoc

[Sönke Ludwig via Digitalmars-d]

Am 06.12.2017 um 12:34 schrieb Walter Bright:

On 12/6/2017 1:33 AM, Sönke Ludwig wrote:
This is great news! While I don't have the time to work on this 
directly, I can offer vibe.d's Markdown module* (re-licensing as 
necessary): 
https://github.com/vibe-d/vibe.d/blob/master/textfilter/vibe/textfilter/markdown.d 



Markdown is a strange thing to parse in the classical way due to its 
original regex-cascade style of implementation/design, so it was kind 
of difficult to find representations that allow reasonably efficient 
and comprehensible processing.


* There is also "dmarkdown", which is just a fork of the vibe.d code


Thanks! It's always great to be able to leverage existing code. But 
you'll need to Boost license it!


No problem!

Re: Adding Markdown to Ddoc

[Sönke Ludwig via Digitalmars-d]

Am 06.12.2017 um 05:11 schrieb Walter Bright:

https://help.github.com/articles/basic-writing-and-formatting-syntax/

Anyone interested in picking up the flag?

(I know this has come up before, and I've been opposed to it, but I've 
changed my mind.)


This is great news! While I don't have the time to work on this 
directly, I can offer vibe.d's Markdown module* (re-licensing as 
necessary): 
https://github.com/vibe-d/vibe.d/blob/master/textfilter/vibe/textfilter/markdown.d


Markdown is a strange thing to parse in the classical way due to its 
original regex-cascade style of implementation/design, so it was kind of 
difficult to find representations that allow reasonably efficient and 
comprehensible processing.


* There is also "dmarkdown", which is just a fork of the vibe.d code

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: Actor model & D

[Sönke Ludwig via Digitalmars-d]

Am 11.11.2017 um 13:28 schrieb Nordlöw:

On Friday, 8 November 2013 at 08:22:56 UTC, Bienlein wrote:
It seems like a pretty simple change so far, though I guess we'll see 
today. As >a demo, I'm creating both a ThreadMultiplexer and a 
FiberMultiplexer.


That would be awesome. Something similar to lightweight threads
as in Go or Rust and I'm all happy with D ;-).


Has someone implemented this?


I have a PR open for vibe.d to add Go style channels:
https://github.com/vibe-d/vibe-core/pull/25

It's just a quick draft so far and there are a few design questions in 
the comments at the top.

Re: Back to SDL question

[Sönke Ludwig via Digitalmars-d]

Am 19.10.2017 um 20:39 schrieb jmh530:

On Thursday, 19 October 2017 at 18:16:12 UTC, Sönke Ludwig wrote:


I wouldn't want to change the default back at this point, as the 
landscape of opinions on this matter is far too heterogeneous. But if 
at some point it should turn out that there is a clear majority for 
SDLang, then it could make sense to re-open the discussion.


By clear majority, it probably makes more sense to consider the revealed 
preferences from the most popular 10%-20% packages on code.dlang.org, 
rather than a majority on the forum...


Agreed

Re: Back to SDL question

[Sönke Ludwig via Digitalmars-d]

Am 19.10.2017 um 15:40 schrieb rikki cattermole:

On 19/10/2017 2:34 PM, Suliman wrote:
First of all I would like to say sorry for Ludwig, that 2 years ago I 
was initiator to making JSON back by default for dub config. It was 
really my mistake.

Only some time later I understand that it was big error.

So I would like to ask community about if all agree to make .sdl 
format to dub by default?


My mind hasn't wavered. I am still against SDL.


I really don't want to invest more energy for this topic at this point, 
but the gist of my view is covered in this earlier comment on reddit: 
https://www.reddit.com/r/programming/comments/6qwl5n/using_dub_the_d_build_tool_package_manager_to/dl2wzqs/


Of course, taste and habit plays a role in this, so it's hard to find a 
definitive conclusion. I would have definitely preferred to support only 
SDLang (as was planned before making DUB official), but at this point 
it's pretty clear that we'll simply have to keep supporting both options.


I wouldn't want to change the default back at this point, as the 
landscape of opinions on this matter is far too heterogeneous. But if at 
some point it should turn out that there is a clear majority for SDLang, 
then it could make sense to re-open the discussion.

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.

Re: Simple web server benchmark - vibe.d is slower than node.js and Go?

[Sönke Ludwig via Digitalmars-d]

Am 24.09.2017 um 20:36 schrieb Vadim Lopatin:

On Friday, 22 September 2017 at 09:40:00 UTC, Sönke Ludwig wrote:
What's was the last status? Could you observe any meaningful thread 
scaling?

It works for me - multithreading improves performance on my PC.


So far, test results on https://github.com/nuald/simple-web-benchmark
show that D is 2-3 times slower than any other language including node.js


The response times look very strange for the kind of load that appears 
to be generated. Unfortunately the testing methodology is so simple that 
it's difficult so judge anything without running it again locally.


Having said that, the Windows implementation does have performance 
issues and needs to be looked at. It has rather low priority for me 
though, because I neither run any servers with Windows, nor did I hear 
that from anyone else who uses vibe.d.




nuald reverted change which enables multithreading since it's "unfair".


How on earth can that be unfair when the Go, node.js and Scala versions 
appear to use multi-threading, too?

Re: Simple web server benchmark - vibe.d is slower than node.js and Go?

[Sönke Ludwig via Digitalmars-d]

Am 21.09.2017 um 20:49 schrieb bitwise:


Doesn't vibe-d use Fibers?

I tried to build a simple web server with a fiber-based approach once - 
it was horribly slow.


I hope C# (and soon C++) style stackless resumable functions will 
eventually come to D.


It uses them and the overhead actually diminishes once the application 
does anything meaningful. To test this, I created two low-level tests 
for eventcore that mimic a minimal HTTP server. AFAIR, I got around 
300kreq/s on a single core without fibers and around 290kreq/s with 
fibers, which amounts to an overhead of about 0.1µs per request.


https://github.com/vibe-d/eventcore/tree/master/examples

Stackless fibers would be really nice to have because of the merged 
stacks and the lower amount of reserved memory required (even though 
this is not a really big issue on 64-bit systems), but for pure 
performance I don't think they would be a critical addition.

Re: Simple web server benchmark - vibe.d is slower than node.js and Go?

[Sönke Ludwig via Digitalmars-d]

Am 22.09.2017 um 09:45 schrieb Vadim Lopatin:

On Thursday, 21 September 2017 at 19:40:48 UTC, bitwise wrote:

On Thursday, 21 September 2017 at 18:55:04 UTC, Vadim Lopatin

It does. But Golang uses them, too. Goroutines.


Indeed. I'm reading about them right now, and they seem to be 
"multiplexed". I wonder if Vibe.d does something similar.


The fact that you've observed lower CPU usage by the D version makes 
me think some kind of scheduling or thread-priority issue is the cause.


Fibers are being switched by waiting for signals/events.
Waiting blocks thread.
Timer should affect only non-blocked threads switching IMHO.


What's was the last status? Could you observe any meaningful thread scaling?

I tested on a 32-core machine a while back and could observe the 
performance rising almost linearly when increasing the number of cores 
(as it should). The effect is obviously smaller on a dual-core system 
where the benchmark application runs on the same system, but even there 
it was well visible.


If the multi-threaded version doesn't show 100% CPU usage, that would 
mean that some kind of thread-blocking is happening - GC collections or 
lock contention would be the likely candidates for that. The latter 
shouldn't happen anymore, as everything except for the logger should be 
thread-local in the latest version.


BTW, I ran Daniel's version on my dual-core notebook against wrk (Linux) 
and got 75kreq/s when using runWorkerTask and ~56kreq/s when using just 
a single thread, which is about what I would expect, considering that 
wrk ran on the same machine.

Re: Simple web server benchmark - vibe.d is slower than node.js and Go?

[Sönke Ludwig via Digitalmars-d]

Am 21.09.2017 um 14:41 schrieb Vadim Lopatin:

On Thursday, 21 September 2017 at 10:21:17 UTC, Sönke Ludwig wrote:

 shared static this()
 {
 (...)
 }


BTW, I'd recommend using

    void main()
    {
    (...)
    runApplication();
    }

instead and dropping the VibeDefaultMain version in the package 
recipe. The old approach is planned to be faded out slowly, because it 
requires some special DUB support that would be nice to see gone at 
some point.


Thank you!
Trying to use multithreaded mode.

Under windows, best Vibe.d results are equal to results of Go server.
Under linux, Vibe.d is still slower even if there are 4 threads listening.

Results:

OS   lang:config   req/s    comments
===  ==    ===  ==
Linux    go    53K
Linux    D:default 48K  1 thread
Linux    D:libevent    48K  1 thread
Linux    D:libasync    46.5K    4 threads

Windows  go    12K
Windows  D:default 12K  4 threads
Windows  D:libevent    12K  4 threads
Windows  D:libasync    7K   4 threads

Under Linux in default and libevent configurations, I see error messages 
from 3 of 4 threads - looks like only one thread can process connections.


Failed to listen on 0.0.0.0:3000
Task terminated with uncaught exception: Failed to listen for incoming 
HTTP connections on any of the supplied interfaces.





Oh, sorry, I forgot the reusePort option, so that multiple sockets can 
listen on the same port:


auto settings = new HTTPServerSettings("0.0.0.0:3000");
settings.options |= HTTPServerOption.reusePort;
listenHTTP(settings, );

Re: Simple web server benchmark - vibe.d is slower than node.js and Go?

[Sönke Ludwig via Digitalmars-d]

     shared static this()
     {
     (...)
     }


BTW, I'd recommend using

void main()
{
(...)
runApplication();
}

instead and dropping the VibeDefaultMain version in the package recipe. 
The old approach is planned to be faded out slowly, because it requires 
some special DUB support that would be nice to see gone at some point.

Re: Simple web server benchmark - vibe.d is slower than node.js and Go?

[Sönke Ludwig via Digitalmars-d]

Am 21.09.2017 um 10:01 schrieb Vadim Lopatin:
There is a simple set of simple web server apps written in several 
languages (Go, Rust, Scala, Node-js):


https://github.com/nuald/simple-web-benchmark

I've sent PR to include D benchmark (vibe.d).

I was hoping it could show performance at least not worse than other 
languages.

But it appears to be slower than Go and even Node.js

Are there any tips to achieve better performance in this test?

Under windows, I can get vibe.d configured to use libevent to show 
results comparable with Go. With other configurations, it works two 
times slower.


Under linux, vibe.d shows 45K requests/seconds, and Go - 50K. The only 
advantage of D here is CPU load - 90% vs 120% in Go.


I'm using DMD. Probably, ldc could speed up it a bit.

Probably, it's caused by single threaded async implementation while 
other languages are using parallel handling of requests?


Multi-threading (or multi-process processing) is probably the main 
reason. The following initialization code should get this on par:


shared static this()
{
runWorkerTaskDist({
listenHTTP("0.0.0.0:3000", );
});
}

The other part is that currently the HTTP server code works rather 
inefficiently with the new vibe-core implementation, ironically due to 
the main feature that is meant to speed up vibe-core over the previous 
implementation: using statically typed structs instead of dynamic 
interfaces for streams. This currently requires using proxy objects in 
the HTTP server, which perform their own type of dynamic dispatch, with 
a higher overhead than using classes/interfaces directly.


But there is a pending redesign of the whole HTTP implementation, which 
will, among other things, get rid of this and will use statically typed 
streams throughout the code. It should then be considerably faster than 
the current code path that uses classes/interfaces.


Finally, there is also a considerable performance bug in vibe-core 
currently, which I can't fix due to an unresolved Optlink bug: 
https://github.com/vibe-d/vibe-core/pull/27 (I tried to reduce this with 
dustmite, took about a week, but of course it reduced to a piece of code 
that was actually broken - I'll have to redo this with using the MS 
linker in parallel as a counter test)

Re: vibed services stop response after several days of work

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

Am 01.09.2017 um 12:31 schrieb Suliman:

On Friday, 1 September 2017 at 08:01:24 UTC, Suliman wrote:

I got same problem on Windows Server 2016 and on Linux Debian 8.5.
I have few very simple backend based on vibed 0.8.1, compiler dmd 
2.075.1.


nginx servise is do port forwarding. Nothing more is used.

After several days of working I am begining to get "502 Bad Gateway" 
error. The service is not down, it's continue to working, but on 
Windows task manager I seen very low memory usage (0.4MB) and on Linux 
I see next: https://snag.gy/ban3jX.jpg (i am not familiar with Linux 
and do not sure if process is alive or not because htop do not show it)


The code is *very* simple https://github.com/bubnenkoff/dlang.ru

Is there any ideas how to diagnostic the problem?


I got error https://paste.ofcode.org/exCL5S2vbp6qhYBqj7v6ez

Is it's issue with libevent?

Does even-loop depend on used OS?




The dpaste shown doesn't seem to match the code in the repository. There 
is a reference to vibe.web.rest and the mysql-native driver, which I 
couldn't find in the dlang.ru source code.


The error is most likely caused by issuing two requests to the MySQL 
server from two different tasks on the same connection. Usually, 
mysql-native uses a connection pool to avoid this, but that could have 
been circumvented by accident.

Re: DUB and LTO?

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

Am 24.01.2017 um 17:02 schrieb Las:

How do I enable LTO in DUB in a sane way?
I could add it to dflags, but I only want it on release builds.



You can put a "buildTypes" section in your package recipe and override 
default dflags or lflags there just for the "release" build type. See 
https://code.dlang.org/package-format?lang=json#build-types

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

Re: Community Rant

[Sönke Ludwig via Digitalmars-d]

Am 22.08.2017 um 17:14 schrieb Jonathan Shamir:
The DUB package repository is horrible! More often than not, the 
packages are so poorly written I end up just writing my own 
implementation. Adding the ability to "rate" packages would go a long 
way in improving the situation.


We are working on this point. There will be some form of popularity and 
quality measures, as well as top lists to discover notable projects.

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.

Re: jai-like CTFE string formating

[Sönke Ludwig via Digitalmars-d]

Am 13.08.2017 um 20:25 schrieb Stefan Koch:

On Sunday, 13 August 2017 at 18:20:15 UTC, Sönke Ludwig wrote:
I was a bit shocked by this number and performed a little test with 
multiple calls to format. Fortunately only the first one takes that 
long to compile. For 500 different calls I got about 2ms per call on 
Windows (which might get slowed down somewhat by the slow terminal 
output):


import std.format;
template T(size_t i) {
  static if (i > 0) {
pragma(msg, format("Bye %s %s %s %s %s %s %s %s %s %s",
  i, " I ",  "just", " have", " to", " concat",  " a lot",
  " of", " strings ...", 9));
enum T = T!(i-1);
  } else enum T = 0;
}
enum test = T!500;


Wouldn't you say that 2ms is still a pretty long time for a function call ?



For this particular function call, yes, but still a lot less scary ;) To 
get some better numbers, can you do a side by side comparison of your 
two versions both executed a few hundred times? If the simplified 
version still turns out considerably faster then there may be some low 
hanging fruits in vibe.d's web/REST modules.

Re: jai-like CTFE string formating

[Sönke Ludwig via Digitalmars-d]

Am 12.08.2017 um 13:47 schrieb Stefan Koch:

Hi Guys,

I've just implemented a subset of the std.format functionality.
In the same style that Johnathan Blow uses for JAI.

It's about 10x faster then using std.format and uses much less memory :)

the follwing code takes over 250 ms to compile :
{
 import std.format;
 pragma(msg, format("Hello %s %s %s %s %s %s %s %s %s", " I ", 
  "just", " have", " to", " concat",  " a lot", " of", " strings ...", 9));

}
Whereas the following alternative takes 20 ms :
{
 import ctfe_utils;
 pragma(msg, format_jai("Hello % % % % % % % % %", " I ", " just", " 
have" , " to", " concat", " a lot", " of", " strings ...", 9));

}

see for yourself:
https://www.youtube.com/watch?v=T0BJxdt61RY


I was a bit shocked by this number and performed a little test with 
multiple calls to format. Fortunately only the first one takes that long 
to compile. For 500 different calls I got about 2ms per call on Windows 
(which might get slowed down somewhat by the slow terminal output):


import std.format;
template T(size_t i) {
  static if (i > 0) {
pragma(msg, format("Bye %s %s %s %s %s %s %s %s %s %s",
  i, " I ",  "just", " have", " to", " concat",  " a lot",
  " of", " strings ...", 9));
enum T = T!(i-1);
  } else enum T = 0;
}
enum test = T!500;

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: Is there a way to use x86 and x86_mscoff with dub simultaneously.

[Sönke Ludwig via Digitalmars-d]

Am 25.07.2017 um 20:47 schrieb ciechowoj:

As Jacob Carlborg said it's for the dstep.

On Tuesday, 25 July 2017 at 15:18:04 UTC, Mike Parker wrote:

On Tuesday, 25 July 2017 at 14:17:54 UTC, ciechowoj wrote:
What's wrong with the current error message? Doesn't it do that?


Nope, this message looks like intended for the library author rather
than for a library user.

What I want is a message that signals that the compilation isn't
possible with the default x86 arch and the user has to use x86_mscoff arch.


That's precisely what --arch (or simply -a) is for. But you can avoid
passing it explicitly by setting the $DUB_ARCH environment variable
(as per the dub documentation).


To disable the warning I mentioned in the first post I needed to remove
the `-m32mscoff` flag. Now the library can be compiled only with
explicit specification of the architecture.

However the default arch is what the library's end user will select most
likely.
And then they will receive unhelpful message about OPTLINK being unable
to parse the VS linker command line.

Ideally I would like to be able to suppress m32mscoff warning and build
for x86_mscoff by default (or amd64).

Setting $DUB_ARCH is unacceptable as well.




What you can do is to create a configuration that only works for x86_64:

name "myproject"

configuration "library" {
platforms "x86_64"
targetType "library"
// ...
}

This will cause the configuration resolution to fail if the wrong 
architecture is selected. The downside is that I think the error message 
will not be very helpful currently (something like "could not resolve 
configuration for myproject"), but that should be fixable.

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: Vibe.d - very low performance

[Sönke Ludwig via Digitalmars-d]

Am 14.07.2017 um 11:55 schrieb Marek:

On Friday, 7 July 2017 at 19:03:52 UTC, Jacob Carlborg wrote:
I think that vibe.d didn't take full advantage of multi core, even 
when enabling threading support. Ruby, or rather Rails, applications 
are usually run using multiple processes, which allows to scale on a 
multi core CPU. You can do the same with vibe.d as well.


So why Ruby or Python frameworks are much faster in this benchmark?


- The vibe.d benchmark didn't scale across cores plus overhead
- The Ruby/Python benchmarks scaled >= 40x using multiple processes

You could do the same for the vibe.d benchmark, too (and it's generally 
a good idea). The current version should have the in-process scalability 
issue fixed, though, so presumably that will also work correctly now.

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)