Re: DMD v2.066.0-b2
On Tuesday, 8 July 2014 at 10:38:52 UTC, Andrew Edwards wrote: The v2.066.0-b2 binaries are now available. The review period will run until 0700 UTC ( PDT) 14 July 2014. Your assistance in identifying and reporting bugs are greatly appreciated. Link to this post on dlang.org main page is broken.
Re: DMD v2.066.0-b2
Also the link on main page is broken. 2014-07-08 18:10 GMT+04:00 via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: On Tuesday, 8 July 2014 at 13:48:45 UTC, kdmult wrote: The download links are broken. They should have prefix http:// instead of ftp://. Hmm... they work for me.
Re: Awesome-D, and an invitation to you awesome guys
On Sunday, 10 August 2014 at 09:28:48 UTC, Puming wrote: Hi, I'm maintaining this awesome-d list similar to other awesome-stuff lists on github, for keeping a hook on interesting D related links. https://github.com/zhaopuming/awesome-d At first it was only for my personal use, but recently I got some ideas about it that could potentially contribute to the community, so here I am making this little announcement and invating all you awesome guys to help me :-) The ideas are: 1. Awesome-People list that made D awesome. 2. A relation network on github projects First one is about the awesome people, that is you guys. I've been lurking in this forum for many years (dating back to D1 days). But only recently, after watching the great dconf videos, have I realized that it is the awesome people that makes the language/ecosystem awesome. I want to know you. And I think the new comers of D would also like to know you, each one of you great guys who made a library/tool that make their programming life a better place. For lack of information and for the respect of privacy, currently I have only listed Walter and Andrei on the list, https://github.com/zhaopuming/awesome-d#people. But I'd really like to know about other people here, like kenji the great bug killing machie always in the shadow, or bearophile who studied an endless list of languages and exploded bugzilla, and many other. For privacy, I think it's best that only the descriptions provided by people themselves or really related people should be allowed, or at least a permission is acquired by the person. (Sorry Walter and Andrei, I haven't asked for your permissions. But you're the stars and public faces here :-), privacy for you is a past). I think people would be interesting to know who you are, what have you done, what do you think about D and it's future, what are you interesting, etc. Maybe an interview is a better option, but I don't know how to do that here. Do you guys have any ideas? For the second stuff, after I made the awesome-d list, the awesome-awesome list maintainer made a pull request to add mine to his list and connect. Then I found a list of awesome-c, awesome-clojure, and all other awesome lists: https://github.com/bayandin/awesome-awesomeness which is very interesting and a good way to find information. So the similar idea came to me: Why don't try to build a network about D stuff? D libs are scattered even in github--you don't have a good way to search for the libs you're interested in. Now we have code.dlang.org, but it is also a one way list. Ideally it would be two way: if a person bumped into one of the D projects, and in the project there is a link that says enlisted on code.dlang.org, then he can easily go to code.dlang.org and see what other interesting, related projects their are. This is very similar to what for me on github does, it makes a network. Of couse, what I want to have is also enlisted on awesome-d. Do you project maintainers think it's good? One last request for help: You might noticed that I'm not a native english speaker, so there are many grammar or style problems in the awesome-d list, if you find any, please help me fix it. Best Regards. Puming I like the idea to collect useful links, but more useful to collect all info on single portal. Integrate wiki, dlang, code.dlang.org, bugtracker, add some github integration via its api - dreams, the only dreams.
Re: DMD v2.066.0-rc2
On Friday, 8 August 2014 at 12:01:43 UTC, Andrew Edwards wrote: DMD v2.066.0-rc2 binaries are available for testing: http://wiki.dlang.org/Beta_Testing Found another bug with DList: https://issues.dlang.org/show_bug.cgi?id=13279
Daemonize v0.1 - simple way to create cross-platform daemons
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
// Setting associative map signal - callbacks
KeyValueList!(
// You can bind same delegate for several signals by
Composition template
// delegate can take additional argument to know which
signal is caught
Composition!(Signal.Terminate, Signal.Quit,
Signal.Shutdown, Signal.Stop), (logger, signal)
{
logger.logInfo(Exiting...);
return false; // returning false will terminate daemon
},
Signal.HangUp, (logger)
{
logger.logInfo(Hello World!);
return true; // continue execution
}
),
// Main function where your code is
(logger, shouldExit) {
// will stop the daemon in 5 minutes
auto time = Clock.currSystemTick +
cast(TickDuration)5.dur!minutes;
while(!shouldExit() time Clock.currSystemTick) { }
return 0;
}
);
int main()
{
return buildDaemon!daemon.run(new shared
StrictLogger(logfile.log));
}
```
At the moment daemonize has following features:
* Daemons for GNU/Linux, services for Windows
* Custom signals
* Signal composition
* Client for sending signals to defined daemons
* Auto installing and uninstalling for Windows services
* Usage of .pid and .lock files (GNU/Linux)
* Privileges lowing (GNU/Linux)
Daemonize operates well with vibe.d (example -
https://github.com/NCrashed/daemonize/tree/master/examples/03.Vibed)
P.S. At the moment library doesn't support Mac and other Posix
systems, the support is going to be added at next releases.
Re: Daemonize v0.1 - simple way to create cross-platform daemons
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 daemon,
or
doesn't care, whatever.
Yes, the name is used in windows service manager (you can
start/stop the daemon by control panel) and for default locations
of .pid and .lock files. Auto generated name will prevent sending
signals and could be ugly displayed in service manager. The
feature is useful for simple daemons, I will play around with
that idea to find out if it worth.
If I understand correctly, the Daemon template waits for a list
of (at
least one) Signal, then a delegate, then some more Signals,
another
delegate, and so on?
If that's so I think you could ditch KeyValueList (or build it
invisibly to the user) and let the user write only the signals
and
delegates:
alias daemon = Daemon!(
Signal.Terminate, Signal.Quit, Signal.Shutdown, Signal.Stop,
(logger, signal) {
...},
Signal.Hangup,
(logger) {
...}
...
);
Iterate the argument list, collecting Signals. When you hit a
delegate, create a Composition!( ... ) with the previous
signals, jump
above the delegate and so on.
I will add the approach in next release (it requires some more
additional templates to wrap all the mess) thanks to arguments
grammar has no ambiguities.
Is the idea that, if the delegate has two arguments, then the
second
is the signal that will be passed to it, and if it has only one
argument, only the logger will be passed?
Yes
What if the user does not want a logger? Is a daemon always
associated
to a log file in OSes?
It is a general rule as the stderr and stdout files are closed.
At next version I want to use duck typing for logger (or sink
approach same as toString uses) and add a feature to reopen
stderr/stdout to another file.
Is the main function always the last delegate?
Yes
Concerning the DaemonClient template, could you not ask for
Daemon to
generate it on demand? Or is DaemonClient always used in another
module?
DaemonClient is designed to be used in another module, you can
send signals with full Daemon template.
What happens when an unhandled signal is passed to a daemon?
The event is logged down and ignored.
Do you foresee any difficulty in adapting this to Mac?
All logic should be the same as for linux, I just don't have any
machine to test
all out. I hope virtual machine will help.
On Sunday, 31 August 2014 at 16:01:10 UTC, Philippe Sigaud via
Digitalmars-d-announce wrote:
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 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 care, whatever.
// Setting associative map signal - callbacks
KeyValueList!(
If I understand correctly, the Daemon template waits for a list
of (at
least one) Signal, then a delegate, then some more Signals,
another
delegate, and so on?
If that's so I think you could ditch KeyValueList (or build it
invisibly to the user) and let the user write only the signals
and
delegates:
alias daemon = Daemon!(
Signal.Terminate, Signal.Quit, Signal.Shutdown, Signal.Stop,
(logger, signal) {
...},
Signal.Hangup,
(logger) {
...}
...
);
Iterate the argument list, collecting Signals. When you hit a
delegate, create a Composition!( ... ) with the previous
signals, jump
above the delegate and so on.
Is the idea that, if the delegate has two arguments, then the
second
is the signal that will be passed to it, and if it has only one
argument, only the logger will be passed?
What if the user does not want a logger? Is a daemon always
associated
to a log file in OSes?
// Main function where your code is
(logger, shouldExit) {
// will stop the daemon in 5 minutes
auto time = Clock.currSystemTick +
cast(TickDuration)5.dur!minutes;
while(!shouldExit() time Clock.currSystemTick) {
}
return 0;
}
Is the main function always the last delegate?
Concerning the DaemonClient template, could you not ask for
Daemon to
generate it on demand? Or is DaemonClient always used in another
module?
Because, given a Daemon, extracting the simplified DaemonClient
can be
done, I think.
* 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
like this. Wow.
*
Re: Daemonize v0.1 - simple way to create cross-platform daemons
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 simply ignored (except termination ones).
You could have the daemon stopped, after logging the unhandled
signal.
Or you could also block compilation if a daemon does not handle
all signals...
Some signals could be sent without any reason: sighup or
interrogate in windows.
Ignoring most signals is a better strategy, the exception could
be done for terminating signals - their default handlers should
set `shouldExit` flag to true.
Or have a 'catch-all' delegate, as std.concurrency.receive,
which uses
a (Variant v) {...} delegate at the end.
See:
http://dlang.org/library/std/concurrency/receive.html
Good idea, it will be implemented.
(btw, signals could also be types and you could have a handling
syntax
similar to receive).
Ohh, that is much more complicated feature as it may seem.
Signaling in both OSes are very limited. We need an additional
channel to pass arbitrary memory between processes and also
restrict data to be serializable. If I continue to move in that
direction, the D will occasionally obtain a library for
distributed cluster computing (like Cloud Haskell) ;).
On Sunday, 31 August 2014 at 19:45:32 UTC, Philippe Sigaud via
Digitalmars-d-announce wrote:
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 care, whatever.
Yes, the name is used in windows service manager (you can
start/stop the
daemon by control panel) and for default locations of .pid and
.lock files.
OK.
Auto generated name will prevent sending signals and could be
ugly displayed
in service manager. The feature is useful for simple daemons,
I will play
around with that idea to find out if it worth.
Great.
I will add the approach in next release (it requires some more
additional
templates to wrap all the mess) thanks to arguments grammar
has no
ambiguities.
Yes, the grammar is simple, use it to simplify the life of your
users.
Is the idea that, if the delegate has two arguments, then the
second
is the signal that will be passed to it, and if it has only
one
argument, only the logger will be passed?
Yes
OK.
IIRC, I read in your code that composed signals means the next
delegate must have the (logger, signal) {...} form.
Why?
What if the user does not want a logger? Is a daemon always
associated
to a log file in OSes?
It is a general rule as the stderr and stdout files are
closed. At next
version I want to use duck typing for logger (or sink approach
same as
toString uses) and add a feature to reopen stderr/stdout to
another file.
OK.
Concerning the DaemonClient template, could you not ask for
Daemon to
generate it on demand? Or is DaemonClient always used in
another
module?
DaemonClient is designed to be used in another module, you can
send signals
with full Daemon template.
OK. I'd have thought that just having the name of the daemon
would be
enough to send it signals.
What happens when an unhandled signal is passed to a daemon?
The event is logged down and ignored.
Is that the standard behavior for daemons in OSes?
You could have the daemon stopped, after logging the unhandled
signal.
Or you could also block compilation if a daemon does not handle
all signals...
Or have a 'catch-all' delegate, as std.concurrency.receive,
which uses
a (Variant v) {...} delegate at the end.
See:
http://dlang.org/library/std/concurrency/receive.html
(btw, signals could also be types and you could have a handling
syntax
similar to receive).
Re: Daemonize v0.1 - simple way to create cross-platform daemons
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 completely missed this. Has it been reddited? -- Andrei It is a first public release, the code was roaming from one application to another until I found the strength to clean up, redesign an API and publish as a separate library.
Re: Release Candidate D 2.067.0-rc1
On Monday, 16 March 2015 at 21:38:22 UTC, Martin Nowak wrote:
Release Candidate for 2.067.0
http://downloads.dlang.org/pre-releases/2.x/2.067.0/
http://ftp.digitalmars.com/
You can get the binaries here until they are mirrored.
https://dlang.dawg.eu/downloads/dmd.2.067.0-rc1/
We fixed the few remaining issues.
https://github.com/D-Programming-Language/dmd/compare/v2.067.0-b4...v2.067.0-rc1
https://github.com/D-Programming-Language/phobos/compare/v2.067.0-b4...v2.067.0-rc1
Unless any new issue pops up, we'll make the release on friday.
-Martin
Seems a new regression with DList:
```
import std.container.dlist;
interface ITest {}
class Test : ITest {}
void main()
{
DList!ITest().insertBack(new Test());
}
```
Compiles successfully with 2.066.1
Re: Release Candidate D 2.067.0-rc1
On Tuesday, 17 March 2015 at 10:52:18 UTC, NCrashed wrote:
On Monday, 16 March 2015 at 21:38:22 UTC, Martin Nowak wrote:
Release Candidate for 2.067.0
http://downloads.dlang.org/pre-releases/2.x/2.067.0/
http://ftp.digitalmars.com/
You can get the binaries here until they are mirrored.
https://dlang.dawg.eu/downloads/dmd.2.067.0-rc1/
We fixed the few remaining issues.
https://github.com/D-Programming-Language/dmd/compare/v2.067.0-b4...v2.067.0-rc1
https://github.com/D-Programming-Language/phobos/compare/v2.067.0-b4...v2.067.0-rc1
Unless any new issue pops up, we'll make the release on friday.
-Martin
Seems a new regression with DList:
```
import std.container.dlist;
interface ITest {}
class Test : ITest {}
void main()
{
DList!ITest().insertBack(new Test());
}
```
Compiles successfully with 2.066.1
Forgot output of dmd for 2.067-rc1:
```
/usr/include/dmd/phobos/std/container/dlist.d(642): Error:
template std.container.dlist.DList!(ITest).DList.createNode
cannot deduce function from argument types !()(Test, BaseNode*,
BaseNode*), candidates are:
/usr/include/dmd/phobos/std/container/dlist.d(166):
std.container.dlist.DList!(ITest).DList.createNode()(ref T arg,
BaseNode* prev = null, BaseNode* next = null)
/usr/include/dmd/phobos/std/container/dlist.d(414): Error:
template instance
std.container.dlist.DList!(ITest).DList.insertBeforeNode!(Test)
error instantiating
source/app.d(9):instantiated from here: insertBack!(Test)
```
Re: Release Candidate D 2.067.0-rc1
On Tuesday, 17 March 2015 at 11:33:14 UTC, Max Klyga wrote: On 2015-03-17 11:18:10 +, Daniel Kozak said: On Monday, 16 March 2015 at 21:38:22 UTC, Martin Nowak wrote: Release Candidate for 2.067.0 http://downloads.dlang.org/pre-releases/2.x/2.067.0/ http://ftp.digitalmars.com/ You can get the binaries here until they are mirrored. https://dlang.dawg.eu/downloads/dmd.2.067.0-rc1/ We fixed the few remaining issues. https://github.com/D-Programming-Language/dmd/compare/v2.067.0-b4...v2.067.0-rc1 https://github.com/D-Programming-Language/phobos/compare/v2.067.0-b4...v2.067.0-rc1 Unless any new issue pops up, we'll make the release on friday. -Martin Does not work with my code base :( dmd: interpret.c:6724: void setValue(VarDeclaration*, Expression*): Assertion `(vd-storage_class (0x1000LL | 0x20LL)) ? isCtfeReferenceValid(newval) : isCtfeValueValid(newval)' failed. Exit code 134 Please concider submitting a bug request with minified test case created using dustmite (https://github.com/CyberShadow/DustMite) https://issues.dlang.org/show_bug.cgi?id=14300
Re: Release Candidate D 2.067.0-rc1
On Monday, 16 March 2015 at 21:38:22 UTC, Martin Nowak wrote: Release Candidate for 2.067.0 http://downloads.dlang.org/pre-releases/2.x/2.067.0/ http://ftp.digitalmars.com/ You can get the binaries here until they are mirrored. https://dlang.dawg.eu/downloads/dmd.2.067.0-rc1/ We fixed the few remaining issues. https://github.com/D-Programming-Language/dmd/compare/v2.067.0-b4...v2.067.0-rc1 https://github.com/D-Programming-Language/phobos/compare/v2.067.0-b4...v2.067.0-rc1 Unless any new issue pops up, we'll make the release on friday. -Martin Another regression: https://issues.dlang.org/show_bug.cgi?id=14301
Re: DDT 0.11.0 released
On Friday, 6 March 2015 at 17:37:51 UTC, Bruno Medeiros wrote: A new version of DDT is out. Improvements to the semantic engine, important fixes: https://github.com/bruno-medeiros/DDT/releases/tag/Release_0.11.0 There has also been some big internal changes lately, so these latest releases might be a bit more buggy than usual. (as exemplified by the regression where code folding and quick-outline were broken :s - and shame on me for taking so long to notice that) Thank you! DDT is actually the most convenient D IDE at the moment. P.S. Could I request a feature? a better support for dub subconfigurations (yep, I know, if I want something, then it's my fault that isn't implemented yet).
Re: vibe.d 0.7.23 has been released
On Wednesday, 25 March 2015 at 21:37:09 UTC, Sönke Ludwig wrote: This release adds support for the just released DMD 2.067.0 frontend. There are also some preparatory changes in vibe.core.sync (TaskMutex etc.) for planned nothrow related changes to D's mutexes and object monitors. These changes lead to a changed behavior when TaskMutex'es are mixed with the Task.interrupt() functionality. If your code uses both, please have a look at the change log for more details. Other notable changes: - Defining either of VibeDefaultMain or VibeCustomMain is now required. VibeCustomMain will be removed and made the default behavior in one of the future releases (instead of the current default, VibeDefaultMain). - The REST interface generator now accepts @queryParam and @bodyParam annotations to customize how parameters are mapped to the REST protocol. - The serialization framework now supports policy based customization. This allows to configure the serialized representation of a type without touching its definition. - The Diet template parser has received a number of fixes and now supports prepend/default mode for blocks, as well treating lines starting with as plaintext (for inline HTML lines) The full list of changes/fixes can be found at http://vibed.org/blog/posts/vibe-release-0.7.23 Homepage: http://vibed.org/ DUB package: http://code.dlang.org/packages/vibe-d GitHub: https://github.com/rejectedsoftware/vibe.d Thank you for amazing work!
