Munich D Meetup December 2017
On December 20th, with the title "D School" we will have our next Munich meetup. Come as beginner and we assist you during a self-guided course. Come as advanced and we review your library or polish your PR. Please RSVP on: https://www.meetup.com/de-DE/Munich-D-Programmers/events/245624091/ Thanks, Dragos
Re: D User Survey
On Friday, 1 December 2017 at 18:56:50 UTC, WebFreak001 wrote: Hi everyone, I made a public survey (everyone can look at the responses) and it would be great if you took some time and answered it. I think it will greatly benefit D as a whole if we had more anonymous data on users. I'm also open for changing some questions if there is confusion. https://docs.google.com/forms/d/e/1FAIpQLSdPFx9ebHJ05QSW1VypBsQPw-1RbZ1v8FMgo1su6NvN6VErBw/viewform How to see the results if you have already filled it?
Re: Visual D 0.46.0 released - more VS2017 and LDC integration
On Saturday, 2 December 2017 at 16:31:00 UTC, Rainer Schuetze wrote: Hi, I have just released version 0.46 of Visual D, see http://rainers.github.io/visuald/visuald/StartPage.html This release doesn't come with major new features, but a list of bug fixes and incremental improvements, those with the largest impact: * improved VS 2017 integration * improved LDC support * support for new symbol mangling and parsing 'static foreach' See http://rainers.github.io/visuald/visuald/VersionHistory.html for the full version history. Visual D is a Visual Studio extension that adds D language support to VS2008-2017. It is written in D, its source code can be found on github: https://github.com/D-Programming-Language/visuald, pull requests welcome. Happy coding, Rainer Thanks, your work is much appreciated!
Re: D User Survey
On Friday, 1 December 2017 at 18:56:50 UTC, WebFreak001 wrote: Hi everyone, I made a public survey (everyone can look at the responses) and it would be great if you took some time and answered it. I think it will greatly benefit D as a whole if we had more anonymous data on users. I'm also open for changing some questions if there is confusion. https://docs.google.com/forms/d/e/1FAIpQLSdPFx9ebHJ05QSW1VypBsQPw-1RbZ1v8FMgo1su6NvN6VErBw/viewform The age results look interesting. It seems that the D community is relatively old. Tried to find a comparison, but the Rust survey seems to not ask for the age.
Re: LDC 1.6.0
On Monday, 4 December 2017 at 12:47:35 UTC, data pulverizer wrote: where `newFunction()` is constructed at dynamic compile-time (during runtime) and its return type as well as the return type of `myDynamicFunction()` is only known once the dynamic compilation is done? So could I call `myDynamicFunction()` and potentially return different types each time it is called? This is not possible with current design. All high level language processing is still done during compile time and only low-level llvm ir is saved to be optimized and codegened later. Jit runtime knows nothing about language, it only have llvm optimizer and backend. Implementing high level D code processing during runtime will require pulling D frontend which isn't very well suited to be used as library.
Re: LDC 1.6.0
On Sunday, 3 December 2017 at 12:50:26 UTC, kinke wrote:
Hi everyone,
on behalf of the LDC team, I'm glad to announce LDC 1.6. The
highlights of this version in a nutshell:
* Based on D 2.076.1.
* Experimental support for dynamic codegen at runtime ('manual
JIT').
* Many std.math functions are now CTFE-able.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.6.0
Thanks to all contributors!
[LDC master is at v2.077.1.]
This is awesome news and sound very interesting - my question is
will dynamic codegen allow you to do things like this:
```
@dynamicCompile auto myDynamicFunction(immutable string myParam)
{
@dynamicCompile mixin(makeFun!(myParam));
return newFunction();
}
```
where `newFunction()` is constructed at dynamic compile-time
(during runtime) and its return type as well as the return type
of `myDynamicFunction()` is only known once the dynamic
compilation is done? So could I call `myDynamicFunction()` and
potentially return different types each time it is called?
mysql-native v1.1.4: Introduced auto-purge to fix a few problems
An all-D MySQL/MariaDB client library: https://github.com/mysql-d/mysql-native In v1.1.4: Introduced auto-purge to fix a few problems. - Fixed: #117: ResultRange cannot be copied. (@Abscissa) - Fixed: #119: Is a defensive Connection.purgeResult call necessary before executing another statement? (As of this release, the answer changed from "sometimes" to "no") (@Abscissa) - Fixed: #139: Server packet out of order when Prepared is destroyed too early. (@Abscissa) - Change: MySQLDataPendingException (aka, MYXDataPending) is no longer necessary, and no longer thrown. When issuing a command that communicates with the server while a ResultRange still has data pending, instead of throwing, mysql-native now automatically purges the range and safely marks it as invalid and no longer usable. This was changed in order to fix #117, #119, and #139. This change should neither break user code nor require any changes. (@Abscissa) - Change: Manually releasing a prepared statement is no longer guaranteed to notify the server immediately. In order to facilitate the above fixes, and avoid any nasty surprise with struct dtors triggering results purges implicitly, any release of prepared statements from the server is now queued until mysql-native can be certain no data is already pending. This change should neither break user code nor require any changes. (@Abscissa) - Change: Prepared statements are no longer released automatically, due to the fix for #117. However, prepared statements and their lifetimes are tied to individual connections, and thus will die along with their connection, so manual release is not strictly necessary either. Accordingly, this change should neither break user code nor require any changes. (@Abscissa) - Fixed: #143: Keep travis-ci build times under control by limiting the number of compiler versions tested on OSX. (@SingingBush) Tentative plans for the next release (probably v1.2.0) include, among other things, removing the old deprecated APIs from pre-1.0, deprecating a few no-longer-needed things and some misc doc improvements. Aside from those housekeeping details, my other next big priority is to finally tackle the awkwardness of combining prepared statements with connection pools. MySQL itself ties prepared statements to the individual connection that created them, and that's caused difficulties for connection pool users. So I'm thinking a connection-independent abstraction is warranted for prepared statements. Mysql-native is made for its users, so if an issue is particularly pressing for you that you feel has been neglected, vote for your biggest bug-a-boo by pinging it: https://github.com/mysql-d/mysql-native/issues (Or better yet, contribute!)
