On 9/27/14, 2:23 AM, NCrashed wrote:
On Saturday, 27 September 2014 at 03:49:31 UTC, Andrei Alexandrescu wrote:
On 8/31/14, 4:27 AM, NCrashed wrote:
Finally I've finished library for wrapping applications into daemons or
services (Windows). The library hides platform-specific boilerplate
behind
On Saturday, 27 September 2014 at 03:49:31 UTC, Andrei
Alexandrescu wrote:
On 8/31/14, 4:27 AM, NCrashed wrote:
Finally I've finished library for wrapping applications into
daemons or
services (Windows). The library hides platform-specific
boilerplate
behind compile-time API:
[snip]
I comple
On 8/31/14, 4:27 AM, NCrashed wrote:
Finally I've finished library for wrapping applications into daemons or
services (Windows). The library hides platform-specific boilerplate
behind compile-time API:
[snip]
I completely missed this. Has it been reddited? -- Andrei
Excellent library, thank you very much for sharing it. I was
about to start my own when I ran into it :)
> I can (not must) have the form, the delegate params are tested independently
> from signal composition.
OK, good.
>> Is that the standard behavior for daemons in OSes?
>
> Most signals are simply ignored (except termination ones).
I see.
> Some signals could be sent without any reason: sighup
On Sun, Aug 31, 2014 at 11:36 PM, Meta via Digitalmars-d-announce
wrote:
>> I didn't know you could have an enum and extend it with a cast like this.
>
> This is not a good thing. Enums are supposed to denote a *closed*,
> enumerated set of items.
I agree.
> It's fine here (but IMO bad style) be
On Sunday, 31 August 2014 at 16:01:10 UTC, Philippe Sigaud via
Digitalmars-d-announce wrote:
* Custom signals
enum Signal : string
{ ... }
@nogc Signal customSignal(string name) @safe pure nothrow
{
return cast(Signal)name;
}
I didn't know you could have an enum and extend it with a cast
IIRC, I read in your code that composed signals means the next
delegate must have the (logger, signal) {...} form.
Why?
I can (not must) have the form, the delegate params are tested
independently from signal composition.
Is that the standard behavior for daemons in OSes?
Most signals are sim
>> Does the user sees/uses this name in any way afterwards? Because I
>> think you could also produce a unique string at compile-time (by using
>> __FILE__ and __LINE__, unless someone has a better idea), if the user
>> does not provide one. Maybe he just wants an anonymous daemon, or
>> doesn't ca
Thanks a lot for the respond!
Does the user sees/uses this name in any way afterwards?
Because I
think you could also produce a unique string at compile-time
(by using
__FILE__ and __LINE__, unless someone has a better idea), if
the user
does not provide one. Maybe he just wants an anonymous d
Nice!
I have a few questions/remarks, mainly to simplify the API somewhat.
Please bear with me :-)
> // First you need to describe your daemon via template
> alias daemon = Daemon!(
> "DaemonizeExample1", // unique name
Does the user sees/uses this name in any way afterwards? Because I
think
On Sun, 31 Aug 2014 11:27:41 +
NCrashed via Digitalmars-d-announce
wrote:
looks very interesting, thank you.
signature.asc
Description: PGP signature
Finally I've finished library for wrapping applications into
daemons or services (Windows). The library hides
platform-specific boilerplate behind compile-time API:
```
// First you need to describe your daemon via template
alias daemon = Daemon!(
"DaemonizeExample1", // unique name
//
13 matches
Mail list logo
