Re: Beta D 2.070.0-b1
On Sunday, 10 January 2016 at 23:58:38 UTC, Martin Nowak wrote: In case you don't already use Travis-CI or something similar, you should start doing so. Testing the latest beta in Travis-CI is as simple as adding dmd-2.070.0-b1 to your .travis.yml [³] (and we'll soon make it even easier adding support for dmd-beta and dmd-nightly). I fear there are more regressions that people can test for. Currently we can't "dub test" release builds trough DUB. If you do: dub test mypackage it builds with flags -g -unittest -w -debug. (like a -b debug build + the -unittest flag) But if you do: dub test mypackage -b release it builds with flags -release -inline -O -w BUT NOT -unittest Currently we can only "dub test" debug builds without anything dangerous. Since a number of regressions are in the backend, that could be useful if DUB would let us test release builds in Travis-CI.
Re: Please vote for the DConf logo
On Wednesday, 4 November 2015 at 15:22:41 UTC, Wyatt wrote: On that note, I like how 1.2 incorporates the colours of the German flag and evokes the moons at the same time, but it ends up being too busy and doesn't draw the eye well, IMO. Hard edges are fine, but the angles don't give me a good feeling. (Also, the zero in the year seems strangely wide.) I have this problem that I like fairly crowded logos https://github.com/p0nce/dplug/blob/master/logo.svg :)
Re: Please vote for the DConf logo
On Wednesday, 4 November 2015 at 09:45:08 UTC, ponce wrote: 3 but not with this font! On second thought, I had looked at the SVG not PNG. The font is OK. Don't look at the SVG if you don't have the same font installed.
Re: Please vote for the DConf logo
On Wednesday, 4 November 2015 at 09:30:30 UTC, Andrei Alexandrescu wrote: Reply to this with 1.1, 1.2, 2, or 3: 1) by ponce: Variant 1: https://github.com/p0nce/dconf.org/blob/master/2016/images/logo-sample.png Variant 2: https://raw.githubusercontent.com/p0nce/dconf.org/4f0f2b5be8ec2b06e3feb01d6472ec13a7be4e7c/2016/images/logo2-sample.png 2) by Jonas Drewsen: https://dl.dropboxusercontent.com/u/188292/g4421.png 3) by anonymous: PNG: http://imgur.com/GX0HUFI SVG: https://gist.github.com/anonymous/4ef7282dfec9ab327084 Thanks, Andrei 3 but not with this font!
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Sunday, 1 November 2015 at 02:41:37 UTC, Andrei Alexandrescu wrote: There's been considerable back and forth between Sociomantic and ourselves before choosing this path. One concern was that corporate intervention risks to stifle individual contributions such as Jonas' and ponce's. We concluded that we've been roughing it long enough so a bit of structured help is welcome. Thanks, Andrei Hey, no problem. The site wasn't quite good enough anyway and it's good to see Sociomantic endorsing D to that extent.
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Wednesday, 28 October 2015 at 23:02:59 UTC, Walter Bright wrote: On 10/28/2015 11:57 AM, ponce wrote: On Wednesday, 28 October 2015 at 18:10:04 UTC, Andrei Alexandrescu wrote: What needs to be written next to it? Looks interesting but I fail to see "DConf". The text should read "DConf 2016/May 4-6/Berlin, Germany" -- Andrei That would give something like: https://github.com/p0nce/dconf.org/blob/master/2016/images/logo-sample.png The logo looks nice, but it doesn't seem to be evocative of D. I think there needs to be a theme to it, like "D saves the world", "D is cool tech", "D makes money for business", "D is the choice of cutting edge programmers", "D is the latest technology", etc. Something like that. Made a 2nd attempt here: https://raw.githubusercontent.com/p0nce/dconf.org/4f0f2b5be8ec2b06e3feb01d6472ec13a7be4e7c/2016/images/logo2-sample.png
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Thursday, 29 October 2015 at 10:41:42 UTC, Iain Buclaw wrote: Not saying you should re-use this design, but notice how the 'DConf' logo is the most unremarkable part of it. :-) I'm aware my proposal is too over-the-top, detracts from the point being made (what? where? when?). It will get patched.
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Thursday, 29 October 2015 at 11:19:16 UTC, Rory McGuire wrote: Most, if not all the logos that have stood the test of time are simple, clean and are easily recognizable in almost any size. The base of the current D logo fits these specs I think. Unless I'm misunderstanding, DConf logo aren't intended to be reused over years. They don't need to stand the test of time like the D logo (which is a topic already discussed at length, let's not derail), so it was my understanding it could be a bit more "unsafe".
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Thursday, 29 October 2015 at 08:41:53 UTC, Iain Buclaw wrote: I think simplicity works better for a logo, moving any small details into the background. Using this kind of tactic I think works well - for instance, a lot of people still wear their DConf 2012 shirts on a weekly basis. What do these shirts look like?
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Thursday, 29 October 2015 at 06:43:25 UTC, Walter Bright wrote: Please don't be discouraged over what I wrote. You've got talent for this. No worries, I'll get back to it :) geod24 on IRC had an interesting idea.
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Wednesday, 28 October 2015 at 23:02:59 UTC, Walter Bright wrote: On 10/28/2015 11:57 AM, ponce wrote: On Wednesday, 28 October 2015 at 18:10:04 UTC, Andrei Alexandrescu wrote: What needs to be written next to it? Looks interesting but I fail to see "DConf". The text should read "DConf 2016/May 4-6/Berlin, Germany" -- Andrei That would give something like: https://github.com/p0nce/dconf.org/blob/master/2016/images/logo-sample.png The logo looks nice, but it doesn't seem to be evocative of D. I think there needs to be a theme to it, like "D saves the world", "D is cool tech", "D makes money for business", "D is the choice of cutting edge programmers", "D is the latest technology", etc. Something like that. There is a D right there in the logo. It think I'll let others step up with other designs.
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Wednesday, 28 October 2015 at 19:24:13 UTC, Andrei Alexandrescu wrote: On 10/28/2015 02:57 PM, ponce wrote: On Wednesday, 28 October 2015 at 18:10:04 UTC, Andrei Alexandrescu wrote: What needs to be written next to it? Looks interesting but I fail to see "DConf". The text should read "DConf 2016/May 4-6/Berlin, Germany" -- Andrei That would give something like: https://github.com/p0nce/dconf.org/blob/master/2016/images/logo-sample.png Nice, thanks. What is the meaning of the "E" or "m"? -- Andrei It is supposed to refer to the Bundestag like in http://www.catherinefeff-studio.com/references/39636641Berlin_logo.gif But I guess this part isn't working too well.
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Wednesday, 28 October 2015 at 18:10:04 UTC, Andrei Alexandrescu wrote: What needs to be written next to it? Looks interesting but I fail to see "DConf". The text should read "DConf 2016/May 4-6/Berlin, Germany" -- Andrei That would give something like: https://github.com/p0nce/dconf.org/blob/master/2016/images/logo-sample.png
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Monday, 26 October 2015 at 10:12:30 UTC, ponce wrote: On Sunday, 25 October 2015 at 23:59:16 UTC, Andrei Alexandrescu wrote: Yes please! Forgot to mention that. Many thanks!! -- Andrei Added to my TODO list :) So I've made a logo here: https://github.com/p0nce/dconf.org/blob/master/2016/images/logo.svg If you like it tell and I'll make the usual dconf.org integration. What needs to be written next to it?
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Sunday, 25 October 2015 at 23:59:16 UTC, Andrei Alexandrescu wrote: Yes please! Forgot to mention that. Many thanks!! -- Andrei Added to my TODO list :)
Re: DConf 2016, Berlin: Call for Submissions is now open!
On Friday, 23 October 2015 at 16:37:20 UTC, Andrei Alexandrescu wrote: http://dconf.org/2016/index.html Do you need a new logo this year? I would be happy to make another, better one.
Re: Beta D 2.069.0-b2
On Wednesday, 14 October 2015 at 13:53:17 UTC, Martin Nowak wrote: Second beta for the 2.069.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.0.html Please report any bugs at https://issues.dlang.org -Martin Apart from https://issues.dlang.org/show_bug.cgi?id=15207, I'm seeing a huge +170% speed-up in 32-bit mode for optimized builds vs 2.068, something that is well appreciated :) 64-bit performance is mostly the same. What changed in the backend?
Re: Beta D 2.069.0-b1
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote: First beta for the 2.069.0 release. Weren't there codegen improvements in DMD?
Re: Beta D 2.069.0-b1
On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote: On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote: First beta for the 2.069.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.0.html Please report any bugs at https://issues.dlang.org -Martin `The -property switch has been deprecated.` Does that mean @property has no effect anymore ? --Stephan Now it would be great if @property was removed. It is just one more attribute that brings nothing to the table and take valuable space on the screen.
Re: Announcing dplug, a toolkit for making audio plugins with D
On Wednesday, 9 September 2015 at 07:51:19 UTC, ponce wrote: - Mac VST support for 64-bit is there, with the exception of a weird scanning bug in Reaper and Studio One (#62). The interface use Cocoa through DerelictCocoa. 32-bit plugins would require a Carbon UI and I don't think it's clever to focus time on it. More dplug news: 32-bit Mac OS X VST support is complete with the help of an ad-hoc, Derelict-style Carbon binding. Actually it was way easier than binding to Cocoa. Using DMD one can target as low as OS X 10.6, if ever needed ;) https://github.com/p0nce/dplug https://github.com/p0nce/DerelictCarbon
Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments
On Tuesday, 29 September 2015 at 16:22:43 UTC, Adam D. Ruppe
wrote:
But, how do you express the half-dependency of
characterencodings in a dub.json dependencies list?
optional dependencies + version tags produced by DUB in the form
of
version (Have_packagename)
{
}
(never tried)
Re: Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments
On Tuesday, 29 September 2015 at 16:22:43 UTC, Adam D. Ruppe wrote: I copy/pasted your arsd/dom.d code in a couple of projects. But none of them will receive updates unless I do 'm manually. That means you don't have to put up with me randomly breaking your code! You don't have to wait for me to publish a bug fix. You aren't locked in to the way I did things and are free to customize it as you wish. But this encourage to create tiny little forks everywhere. So everyone is getting less bugfixes: if I have my local copy, nothing encourages me to contribute the fix. This is the strength of versionned dependencies: - one master tree - get bugfixes automatically before you are aware they even exist - do not close the door to breaking changes in the form of a major version bump. - open/closed principle for packages: if you use devisualization:window, the X11 package is pulled and linked without anymore work. This sub-dependency doesn't leak into your project, it's only a property of the primary dependency you used. So I'd DUB strive to make dependencies composable, where they were previously a leaky abstraction. It's like calling a function and not having to know what it does inside. Of course this implies there is no bad-fixes or SemVer misuse :) But I've found this to work reasonably well in practice.
Re: A new article about working with files in D
On Monday, 28 September 2015 at 11:41:37 UTC, Gary Willoughby wrote: Article: http://nomad.so/2015/09/working-with-files-in-the-d-programming-language/ Reddit link: https://www.reddit.com/r/programming/comments/3mosw7/working_with_files_in_the_d_programming_language/ Great article, I can see this become a reference link whenever one need a quick answer about files. I also like how readable your blog is.
Re: LDC 0.16.0 alpha3 is out! Get it, test it, give feedback!
On Thursday, 17 September 2015 at 14:51:32 UTC, Jack Stouffer wrote: On Wednesday, 16 September 2015 at 20:03:15 UTC, Kai Nacke wrote: Hi everyone, LDC 0.16.0 alpha3, the LLVM-based D compiler, is available for download! Is there anyway to get dub to use this as a compiler so I can test this out? Put the compiler in your PATH, and use the --compiler=ldc2 flag in DUB
Re: Beta D 2.068.2-b1
On Thursday, 10 September 2015 at 03:38:31 UTC, Martin Nowak wrote: Please test any of your code against this beta to help finding bugs. All green here.
Re: Announcing dplug, a toolkit for making audio plugins with D
On Saturday, 13 June 2015 at 14:18:31 UTC, ponce wrote: dplug is a library for audio plugin development. https://github.com/p0nce/dplug http://code.dlang.org/packages/dplug It's aim is to be a lean alternative to JUCE and IPlug, the most used C++ libraries in this space. It is currently less useful since supporting only VST 2.x on Windows. The plan is to gradually add more formats and OS support (VST Mac and AudioUnit should be first). A bit of update about dplug: - Mac VST support for 64-bit is there, with the exception of a weird scanning bug in Reaper and Studio One (#62). The interface use Cocoa through DerelictCocoa. 32-bit plugins would require a Carbon UI and I don't think it's clever to focus time on it. I should do AudioUnit next but it requires inheriting from C++ classes so it's not sure it can work. - The GUI now use a simplified physically-based model for rendering, a bit over-the-top but always nice to use. - Linux windowing is started, but stalled A big surprise was that DMD can also make plugins on OS X, despite not supporting shared libraries theorically. I don't know why it works. Please note however that dplug does not respect SemVer yet and stuff will break without notice or insurance.
Re: Moving forward with work on the D language and foundation
On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: Hello everyone, Following an increasing desire to focus on working on the D language and foundation, I have recently made the difficult decision to part ways with Facebook, my employer of five years and nine months. Facebook has impacted my career and life very positively, and I am grateful to have been a part of it for this long. The time has come for me, however, to fully focus on pushing D forward. As sorry I am for leaving a good and secure career behind, I am excited many times over about the great challenges and opportunities going forward. Great news!
Re: DerelictCocoa
On Friday, 14 August 2015 at 14:44:13 UTC, Jacob Carlborg wrote: On 2015-08-14 14:39, ponce wrote: I see. I've indeed started to cast but only to get the right return type, and left the vararg list. That may be the problem. The signature of the objc_msgSend function is mostly irrelevant. The function needs to be casted because it will jump to the implementation of the method so the arguments to the objc_msgSend call needs to be setup as the implementation of the method expects. Thanks. I've solved my problem which was about D callbacks signatures instead of objc_msgSend trampolines. Oddly enough, variadic calls seem to work for now.
Re: DerelictCocoa
On Friday, 14 August 2015 at 12:31:15 UTC, Jacob Carlborg wrote: On 2015-08-14 13:19, ponce wrote: How best to contact you? I guess it depends on the time zones, I'm living in UTC+2. I'm in the UTC+1 zone. Yeah, here comes the tricky part. All methods returning a struct must use the objc_msgSend_stret, EXCEPT if the struct is so small it will fit in registers, then it must use the regular objc_msgSend function. Also, you always need to cast the objc_msgSend_* function to the correct signature, the signature of the target method. I see. I've indeed started to cast but only to get the right return type, and left the vararg list. That may be the problem.
Re: DerelictCocoa
On Thursday, 30 July 2015 at 18:21:00 UTC, Jacob Carlborg wrote: I had a quick look at the implementation. You're not using the objc_msgSend_* family of functions correctly. That's one of the main reasons why extern(Objective-C) was implemented. I strongly recommend you adapting extern(Objective-C) instead. At least read the commit message [1] for the commit which implements extern(Objective-C). It explains how objc_msgSend_* works. I can provide more detail if necessary. Hi Jacob, I'd be interested by an email or IRC conversation about this. How best to contact you? I managed to create a NSView subclass classes at runtime and override methods (that involved instance variables for the this pointer). However a painful thing is for those function returning NSPoint. Some guidance would be welcome!
Re: vibe.d 0.7.24 released
On Tuesday, 11 August 2015 at 16:11:29 UTC, Sönke Ludwig wrote: Did you try to run "dub upgrade" again after the clean-caches? This is necessary, because dub.selections.json is supposed to be able to manually override dependency specifications in dub.json. I have a script called dubrenew.sh --8<- #!/bin/bash rm dub.selections.json dub clean-caches --8<- Works every time (dub upgrade can be used alternatively to deleting dub.selections.json)
Re: vibe.d 0.7.24 released
On Wednesday, 12 August 2015 at 09:42:20 UTC, ponce wrote: I have a script called dubrenew.sh --8<- #!/bin/bash rm dub.selections.json dub clean-caches --8<- Works every time (dub upgrade can be used alternatively to deleting dub.selections.json) Maybe dub upgrade should call dub clean-caches.
Re: Visual D 0.3.42 released
On Thursday, 6 August 2015 at 17:10:18 UTC, ZombineDev wrote: On Thursday, 6 August 2015 at 14:39:45 UTC, akaDemik wrote: On Wednesday, 5 August 2015 at 21:03:51 UTC, Rainer Schuetze wrote: there is a new version of Visual D available It will support the dub in the future? If you have a dub project that you want to open in VisualD, go to project root (where dub.json or dub.sdl is located) and execute this command: dub generate visuald This will generate a .sln file that you can open in Visual Studio if you have the VisualD extension installed. For each change of architecture, build type, configuration, or compiler will need to redo that command.
Re: DerelictCocoa
On Friday, 31 July 2015 at 19:10:05 UTC, Jacob Carlborg wrote: On 31/07/15 01:21, ponce wrote: Unfortunately I'm stuck because OS X shared libraries are not implemented in DMD so it may be quite a long time before I can use a 2.068 front-end for all this. My target is the currently available 2.066/2.067. I see, you're using LDC? Then I recommend you have a look at the Objective-C bridge [1] I created. It has not been updated in a very long time but I think you can use it as a base. Perhaps just update it for D2. It looks very interesting indeed. Another gem from the D1 days (Cocoa in 2008?). That said, I don't promise anything because of time scarcity.
Re: DerelictCocoa
On Thursday, 30 July 2015 at 18:21:00 UTC, Jacob Carlborg wrote: On 2015-07-30 12:19, ponce wrote: Based on prior Jacob Carlborg'work (AFAIK) and inspired by DerelictCF (https://github.com/Extrawurst/DerelictCF), DerelictCocoa is an elaborated hack to be able to use Cocoa without Xcode (tm). It does _not_ rely on the recent extern(Objective-C) additions so I'm a bit unsure how far the compatibility will go in the OS X lineage. https://github.com/p0nce/DerelictCocoa This is an unofficial Derelict package, so use at your own risk. I had a quick look at the implementation. You're not using the objc_msgSend_* family of functions correctly. That's one of the main reasons why extern(Objective-C) was implemented. Indeed there are things I don't know why it works when it shouldn't considering the calling convention. This is more like a 80% solution until something better can be done. I strongly recommend you adapting extern(Objective-C) instead. At least read the commit message [1] for the commit which implements extern(Objective-C). It explains how objc_msgSend_* works. Unfortunately I'm stuck because OS X shared libraries are not implemented in DMD so it may be quite a long time before I can use a 2.068 front-end for all this. My target is the currently available 2.066/2.067. I can provide more detail if necessary. Thanks for the feedback. I'll start by reading by reading the commit in more detail. Actually I've skimmed it before and failed to understand if it allows to subclass ObjC objects. If it doesn't then calling the runtime might still be necessary. Not really a problem since class functions do not seem tricky like objc_msgSend_*. I was also unsure if extern(Objective-C) helps with the runtime functions themselves, or rather only dispatch to the right runtime function obj_msgSend_*. Or both.
Re: DerelictCocoa
On Thursday, 30 July 2015 at 18:23:21 UTC, Jacob Carlborg wrote: On 2015-07-30 12:19, ponce wrote: Based on prior Jacob Carlborg'work (AFAIK) and inspired by DerelictCF (https://github.com/Extrawurst/DerelictCF), DerelictCocoa is an elaborated hack to be able to use Cocoa without Xcode (tm). Also, why using the Derelict approach and load the library at runtime? The library will always be available and the correct version. I guess it's because I based DerelictCocoa on the old DerelictSDL code you wrote, which was using dynamic binding. It never occurred to me it could also work statically.
DerelictCocoa
Based on prior Jacob Carlborg'work (AFAIK) and inspired by DerelictCF (https://github.com/Extrawurst/DerelictCF), DerelictCocoa is an elaborated hack to be able to use Cocoa without Xcode (tm). It does _not_ rely on the recent extern(Objective-C) additions so I'm a bit unsure how far the compatibility will go in the OS X lineage. https://github.com/p0nce/DerelictCocoa This is an unofficial Derelict package, so use at your own risk.
Re: Voting for std.experimental.allocator
On Wednesday, 8 July 2015 at 11:33:03 UTC, Dicebot wrote: Please respond to this post with a comment starting with a single "Yes"/"No" and optional explanation after that. Criteria you are expected to evaluate as part of "Yes": Yes.
Re: Announcing dplug, a toolkit for making audio plugins with D
On Wednesday, 17 June 2015 at 07:44:03 UTC, Ola Fosheim Grøstad wrote: On Monday, 15 June 2015 at 09:30:11 UTC, ponce wrote: On Sunday, 14 June 2015 at 21:37:14 UTC, Ola Fosheim Grøstad wrote: On Sunday, 14 June 2015 at 21:20:36 UTC, Ola Fosheim Grøstad wrote: Not sure how Audacity plugins are written (on OSX it can use AudioUnits also I believe), but might be worth looking into. Might attract some GNU/Linux people. The wiki said that Audacity ships with Vamp: http://www.vamp-plugins.org/develop.html I was under the impression that LV2 was the Linux standard. But since Bitwig Studio has been released for Linux, VST is the most serious contender in this space. http://www.vamp-plugins.org/rationale.html http://bugzilla.audacityteam.org/buglist.cgi?quicksearch=LV2 http://wiki.audacityteam.org/wiki/Plug-ins http://wiki.audacityteam.org/wiki/Creating_your_own_Plug-in VAMP does look like a very interesting format, however immediate goal is survival in the commercial space, where AAX, Mac and AudioUnit are much more important :) It isn't even sure I will continue with D but for now there is not much absolute blockers. Lack of OSX shared libraries could be one though. VAMP roughly fits dplug (apart from non-changing parameters), but then it would be a subset of possible VAMP plugins if implemented.
Re: Announcing dplug, a toolkit for making audio plugins with D
On Sunday, 14 June 2015 at 21:37:14 UTC, Ola Fosheim Grøstad wrote: On Sunday, 14 June 2015 at 21:20:36 UTC, Ola Fosheim Grøstad wrote: Not sure how Audacity plugins are written (on OSX it can use AudioUnits also I believe), but might be worth looking into. Might attract some GNU/Linux people. The wiki said that Audacity ships with Vamp: http://www.vamp-plugins.org/develop.html I was under the impression that LV2 was the Linux standard. But since Bitwig Studio has been released for Linux, VST is the most serious contender in this space.
Re: Announcing dplug, a toolkit for making audio plugins with D
On Sunday, 14 June 2015 at 18:57:38 UTC, Jim Hewes wrote: This is a nice announcement to me since I'm a user of JUCE. Is this meant to by only for creating plug-ins or can the audio interface be used outside of a plug-in? Thanks. It is meant only for creating plug-ins. Actually dplug doesn't offer an audio interface. A cross-platform MIDI library would also be a cool thing. Pardon my ignorance if there already is one for D I wasn't aware of. I don't think there is one.
Re: Announcing dplug, a toolkit for making audio plugins with D
On Saturday, 13 June 2015 at 21:49:18 UTC, nhk8 wrote: Nice, however you could announce it too on Kvr because audio DSP is such a 'niche' that i doubt anyone will be interested here. I will when there is a bit more features.
Re: Announcing dplug, a toolkit for making audio plugins with D
On Saturday, 13 June 2015 at 15:28:09 UTC, tired_eyes wrote: On Saturday, 13 June 2015 at 14:18:31 UTC, ponce wrote: dplug is a library for audio plugin development. https://github.com/p0nce/dplug http://code.dlang.org/packages/dplug It's aim is to be a lean alternative to JUCE and IPlug, the most used C++ libraries in this space. It is currently less useful since supporting only VST 2.x on Windows. The plan is to gradually add more formats and OS support (VST Mac and AudioUnit should be first). Because of the particular need of audio plugins (lazy screen updates, message dispatch made by host, threading, child window...), dplug has its own windowing. It then use a deffered software renderer to have a nice procedural UI and keep installer sizes low. No linux support? Linux VST, LV2? Not yet but no reason it couldn't fit. To have Linux support the only thing to do is implement: https://github.com/p0nce/dplug/blob/master/gui/dplug/gui/window.d Windows support is about 500 lines, I guess Linux would be approx. the same.
Announcing dplug, a toolkit for making audio plugins with D
dplug is a library for audio plugin development. https://github.com/p0nce/dplug http://code.dlang.org/packages/dplug It's aim is to be a lean alternative to JUCE and IPlug, the most used C++ libraries in this space. It is currently less useful since supporting only VST 2.x on Windows. The plan is to gradually add more formats and OS support (VST Mac and AudioUnit should be first). Because of the particular need of audio plugins (lazy screen updates, message dispatch made by host, threading, child window...), dplug has its own windowing. It then use a deffered software renderer to have a nice procedural UI and keep installer sizes low.
Re: forum.dlang.org, version 2 (BETA)
On Thursday, 4 June 2015 at 15:04:05 UTC, Vladimir Panteleev wrote: http://beta.forum.dlang.org/ Many major and minor improvements. Some major ones: - dlang.org theme, fully responsive and mobile-friendly - keyboard navigation in all views - automatically saved post drafts - get notified of new posts and replies with subscriptions - full text search - by persistent request, a new view mode (vertical-split) - post to mailing lists - even faster, believe it or not. This update is the sum of 256 commits over 34 days of development. Fantastic. And this is crazy fast.
Re: DerelictMantle - unofficial, experimental, reverse-engineered
On Wednesday, 27 May 2015 at 12:06:20 UTC, ParticlePeter wrote: http://code.dlang.org/packages/derelict_extras-mantle/~master Currently Windows only. Don't know if this will ever change. AMD: "The initial iteration of Mantle is intended specifically for Windows on PCs." Please let me know if you get the triangle drawn or displayed. Cheers, ParticlePeter Probably a good basis for the future DerelictVulkan :)
Re: D needs...
On Monday, 11 May 2015 at 11:59:02 UTC, Namespace wrote: Inspired by ponce idioms list for D I've set up something similar. There are some themes in D which come up regulary and are discussed to the vomit. If something is agreed, it gets forgotten sometimes and the theme disappears into oblivion (for a few months :P). To prevent this, I've collected some hot-discussed themes, their history and their current state. I hope this helps to avoid unnecessary discussions in the future and finally cut off these issues (either with an official decision "Nope, keep as it is" or with an implementation). I've tried to stay as objective as possible, but if something seems to be too subjective, please let me know, so I can fix it. http://dgame.github.io/dneeds/ Nice! Especially the discussion links. Would be good to see a "final-by-default" summary too.
Re: Beta D 2.067.1-b1
On Wednesday, 22 April 2015 at 01:32:47 UTC, Martin Nowak wrote: Also available on Travis-CI as dmd-2.067.1-b1. OT: How to know the list of D compilers available on Travis CI?
Re: This Week in D #9 - marketing discussion, final beta, special interview with Sönke
On Monday, 16 March 2015 at 13:11:56 UTC, weaselcat wrote:
An example of a simple but fundamental issue are the defaults
of the built-in attributes. I think some of them, for
historical or compatibility reasons, are currently simply the
wrong way around (pure, @safe, final and scope should really
all be enabled by default, with scope providing recursive
guarantees) and using them properly completely destroys the
initial idea of having a clean language syntax. It's sometimes
really sad to see modern idiomatic D code degrading into a
mess of attributes and contract syntax noise. After all, a
clean syntax used to be one of the key selling points.
+1 for this entire paragraph, sometimes D looks simple and
elegant, other times it looks like someone puked attributes.
Rust code is safe by default and it is littered with unsafe{ }
blocks.
It is also immutable by default and it is littered with the 'mut'
keyword.
I think D absolutely choose the good defaults everytime but some
attribute don't buy enough compared to the line-noise they
generate.
For these reasons I mostly ignore pure, nothrow, @safe, immutable
etc... in routine code and only put them when the code is
especially reusable and somehow won't change much.
Since D1 I really value the ability to make bad code quickly in
time-contrained situations.
Re: This Week in D #8: ddmd progressing, moving toward release.
On Tuesday, 10 March 2015 at 09:24:54 UTC, wobbles wrote: On Tuesday, 10 March 2015 at 08:06:18 UTC, ponce wrote: On Monday, 9 March 2015 at 22:29:42 UTC, amber wrote: There are a bunch of good tips here: http://p0nce.github.io/d-idioms/ If the author(s) are OK with the idea you could use this as a source of tips for a few weeks. bye, amber Course I'm ok with it. This must have been been updated since I last read it. The first GC paragraph is very good! :) Thanks! You are welcome to suggest new idioms and tips.
Re: This Week in D #8: ddmd progressing, moving toward release.
On Monday, 9 March 2015 at 22:29:42 UTC, amber wrote: On Monday, 9 March 2015 at 13:33:16 UTC, Adam D. Ruppe wrote: On Monday, 9 March 2015 at 07:08:42 UTC, Dominikus Dittes Scherkl wrote: Nice, but I'm missing the tip of the week (also with issue #7). Already out of ideas? I ran out of my backlog and haven't had the time to write up new ones the last couple weeks because of other obligations eating up all my time (this week, I had to travel for a work thing... then got trapped mid way by that winter storm hitting Baltimore and Philadelphia), so I try to release this with something rather than nothing when that happens. When I have a few extra hours, I'll write up tip or project spotlights for the next month including the UTF decoding in foreach and phobos, moving forward with the little game using my libraries, and whatever else pops up in the chat or something that I feel like talking about. There are a bunch of good tips here: http://p0nce.github.io/d-idioms/ If the author(s) are OK with the idea you could use this as a source of tips for a few weeks. bye, amber Course I'm ok with it.
Re: let (x,y) = ...
On Thursday, 19 February 2015 at 04:38:32 UTC, thedeemon wrote:
Creating tuples and returning them from functions is trivial in
D:
auto getTuple() { return tuple("Bob", 42); }
but using them afterwards can be confusing and error prone
auto t = getTuple();
writeln("name is ", t[0], " age is ", t[1]);
I really missed the ML syntax to write
let (name, age) = getTuple();
Turns out this is ridiculously easy to implement in D, so
here's my very tiny module for this:
https://bitbucket.org/infognition/dstuff/src (scroll down to
letassign.d)
It allows you to write:
int x, y, z, age;
string name;
let (name, age) = getTuple(); // tuple
let (x,y,z) = argv[1..4].map!(to!int); // lazy range
let (x,y,z) = [1,2,3]; // array
SomeStruct s;
let (s.a, s.b) = tuple(3, "piggies");
If a range or array doesn't have enough elements, this thing
will throw, and if it's not desired there's
let (x,y,z)[] = ...
variant that uses just the available data and keeps the rest
variables unchanged.
That's pretty neat! May I turn this code into a d-idioms? Name
and link will be kept of course.
Re: DDocs.org: auto-generated documentation for all DUB projects (WIP)
On Tuesday, 10 February 2015 at 22:40:18 UTC, Kiith-Sa wrote: DDocs.org (http://ddocs.org) is a repository of documentation for DUB projects that automatically re-generates docs as new projects/releases/branch changes are added. The idea is to make documenting D projects as simple as possible, to the point where you don't need to do any work to get documentation for your project other than adding it to the DUB registry. Also, users can now browse documentation for DUB projects even if the author was too lazy to generate it themselves (assuming thy did include some documentation comments). Note that this is still in a very early stage, it was put together in a very quick-and-dirty style by a person with little webdev experience. Currently it just scans `code.dlang.org`, looking for changes (yes, I know, this will break as soon as code.dlang.org changes, I plan to raise issue/s (PRs?) to the dub registry project so it can have a full/stable API, but I wanted to get something to work *right now*. Code is here: * ddocs.org: https://github.com/kiith-sa/ddocs.org * hmod-dub: https://github.com/kiith-sa/hmod-dub * harbored-mod: https://github.com/kiith-sa/harbored-mod Background: When optimizing harbored-mod by testing it on big D projects (gtk-d, tango, vibe.d, etc.), I wrote a simple tool to fetch/generate docs for any DUB project; I got carried away and used that as base for a tool that checks for changes in the DUB registry and generates docs for all projects. I've waited eagerly for someone to do this! Thank you.
Re: This Week in D, issue 2
On Monday, 19 January 2015 at 17:05:54 UTC, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jan-18.html http://www.reddit.com/r/programming/comments/2sy7lg/this_week_in_d_january_18_2015/ For those of you who saw the draft earlier, hit refresh to ensure you aren't seeing a cached version. RSS feed: http://arsdnet.net/this-week-in-d/twid.rss This week, we got new web style thanks to the folks in the other forum. Tech speaking, it now serves gzipped files as a test of what I want to see about putting on dlang.org too. Email list will be coming next week and hopefully a move to dlang.org too. Fixed a few bugs in my stats gathering too, hopefully we'll have all the kinks worked out and on-time release next week! Very nice and informative. I think you could remind everyone that there has been *zero* breaking changes this week. And if there is, well, we'd better know about it!
Re: D idioms list
On Thursday, 15 January 2015 at 06:02:13 UTC, Vlad Levenfeld wrote: For optimal AA lookup, this idiom is also nice if you only need the result for one line: if (auto found = key in AA) do_stuff (found); Having a declaration in an "if" could be another entry together with: if (auto inst = cast(SubClass)myObject) do_stuff(inst); How to do "instanceof" is quite a common question on IRC.
Re: This Week in D, issue 1
On Tuesday, 13 January 2015 at 14:08:58 UTC, Adam D. Ruppe wrote: I've started writing a weekly D newsletter. Here's the first issue, any feedback welcome! http://arsdnet.net/this-week-in-d/jan-12.html In the future, I intend to have it written by Saturday for a weekend release, so if you want something to appear this week, please try to get it to by before then. Very nice! I don't have enough time to keep track of all interesting discussions or interesting language change so this is much appreciated. However, to make it sustainable I would also suggest to make it "This month in D", the content would feel more curated and dense, also less work to do.
Re: D idioms list
On Friday, 9 January 2015 at 05:58:09 UTC, ketmar via Digitalmars-d-announce wrote: p.p.s. maybe it's worth adding Artur's code sample[1] too, to show that "extended" structure can be passed to functions which requires original one? it's not obvious, at least for me. ;-) [1] http://forum.dlang.org/post/mailman.4332.1420752329.9932.digitalmars-d-annou...@puremagic.com I didn't knew alias this does object slicing. Will add it.
Re: D idioms list
On Thursday, 8 January 2015 at 21:28:56 UTC, Foo wrote: On Thursday, 8 January 2015 at 20:00:11 UTC, Foo wrote: On Thursday, 8 January 2015 at 10:21:26 UTC, ponce wrote: I've started a list of curated D tips and tricks here: http://p0nce.github.io/d-idioms/ Anything that you wished you learned earlier at one point in the D world is welcome to be added or suggested. I think the focus should be on "stuff that could make you more productive, or is just funky" but that is up to debate. Of course the D Cookbook still stays irreplaceable for a consistent, in-depth discussion of being D-enabled. Thoughts? "Struct inheritance with alias this" You are using a class ;) And the public label is redundant. Corrected. Never realized public: was implied.
Re: D idioms list
On Thursday, 8 January 2015 at 20:23:11 UTC, ketmar via Digitalmars-d-announce wrote: i'm not sure, but maybe it worth renaming "struct inheritance" to "extending a struct"? or even something completely different. what it does is actually extending/augmenting the struct, but not OO-inheritance, as one cannot pass "augmented" struct to the function which expects original struct. at least without hackery. Renamed, thanks!
Re: D idioms list
On Thursday, 8 January 2015 at 20:16:24 UTC, Adam D. Ruppe wrote: Another thing too, I'm starting work on a "This week in D" thing and tips like these are one of the things I'd like to put in it. I guess I don't have anything else to say about it right now, I still have some more prep work to do, but if any of you have idioms or tricks, we should compile a list for reference and perhaps slightly longer articles about their use we can stick in the newsletter. (I'm thinking the length should only be 2-5 paragraphs.) Feel free to take and extend :)
Re: D idioms list
On Thursday, 8 January 2015 at 11:41:43 UTC, Szymon Gatner wrote:
Question:
Where did this syntax came from? It is not documented for
'import' keyword.(first time I see that D has built-in
resource compiler):
ubyte[] sdlBytes = cast(ubyte[]) import("SDL2.dll");
it is documented:
http://dlang.org/expression.html#ImportExpression
it's a nice D habit of overloading keywords.
Ah, thanks. Follow up then: can such imported string be used
for mixin?
Yes.
Re: D idioms list
On Thursday, 8 January 2015 at 10:56:00 UTC, bearophile wrote: ponce: I'm not familiar with the terse, range-heavy, UFCS style that has emerged from Phobos In Rosettacode I have inserted tons of examples of that coding style. An example, given a tuple of arbitrary length, with items all of the same type, how do you compute the total of its items? The last way I've invented is: myTuple[].only.sum It's also @nogc. But it causes a little of template bloat. Bye, bearophile Cool. I will link to the Rosettacode D pages since I've used them in the past when time-constrained, especially all things regarding text files.
Re: D idioms list
On Thursday, 8 January 2015 at 10:30:38 UTC, uri wrote: This is great, thanks. Something I personally would find useful is a comparison between the C++ way and idiomatic D with Phobos. I finding coming from C/C++ to D very easy but I'm always wondering if I'm doing things the "D" way. Cheers, uri I'm not familiar with the terse, range-heavy, UFCS style that has emerged from Phobos so I'm not sure if I can write that. What could help is a list of tasks for which you asked yourself what the "D" way was. Is there one?
D idioms list
I've started a list of curated D tips and tricks here: http://p0nce.github.io/d-idioms/ Anything that you wished you learned earlier at one point in the D world is welcome to be added or suggested. I think the focus should be on "stuff that could make you more productive, or is just funky" but that is up to debate. Of course the D Cookbook still stays irreplaceable for a consistent, in-depth discussion of being D-enabled. Thoughts?
Re: ATTN Derelict Users and Package Maintainers
On Wednesday, 31 December 2014 at 11:20:09 UTC, Mike Parker wrote: On Wednesday, 31 December 2014 at 10:26:18 UTC, OlaOst wrote: Works fine for me on windows, after running 'dub upgrade'. I tested the SharedLibVersion with a 2.0.1 and a 2.0.3 SDL dll. With the 2.0.3 dll, I could call functions added in SDL 2.0.2 even when using SharedLibVersion(2, 0, 0) - is this intended behaviour? Yes. I guess I wasn't clear about this in my blog post. This isn't telling Derelict to "only load 2.0.0 functions and ignore the rest." It's instead saying, "Don't throw any exceptions if functions from 2.0.1 and 2.0.2 are missing." If you give it a 2.0.1 DLL, it will load 2.0.1 functions. Give it a 2.0.2 DLL and it will load 2.0.2 functions, regardless of what you pass in SharedLibVersion. But now you can happily load 2.0.0 and not worry about SymbolLoadExceptions. See below for the big caveat. I can see this being useful for DerelictENet since ENet can be often packaged with older versions in various distros.
Re: Concise Binary Object Representation (CBOR) binary serialization library.
On Friday, 19 December 2014 at 22:33:57 UTC, BBaz wrote: On Friday, 19 December 2014 at 18:26:26 UTC, MrSmith wrote: The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. When implementing CBOR serialization/parsing I got the impression that it was remarkably similar to MessagePack except late. Dis you spot anything different?
Re: Online documentation for DSFML exists!
On Friday, 19 December 2014 at 00:58:57 UTC, Jeremy DeHaan wrote: It's not the best, but it's a start. Check it out here: http://dsfml.com/doc.html I would love some feed back on this. I already have a few things I would like to change, namely the layout and adding some examples, but I would like to hear what everyone thinks on what I have up. Just a note about the rest of the site though, it is currently under construction so don't expect too much. Beware when including an URL in DDoc http://dsfml.com/dsfml/graphics/circleshape.html
Re: ArrayFire, a GPU library, is now open source
Hi, I'm kind of embarrassed by my bitter post, must have been a bad day :). On Tuesday, 16 December 2014 at 19:49:37 UTC, Shehzan wrote: We also support CPU and OpenCL backends along with CUDA. This way, you can use the same ArrayFire code to run across any of those technologies without changes. All you need to do is link the correct library. Cool, this was reason enough to avoid using NPP until now. I've certainly found desirable to be able to target OpenCL, CPU or CUDA indifferently from the same codebase. What I'd like more than a library of functions though is an abstracted compute API. This would be a compiler from your own compute language to OpenCL C or CUDA C++ also an API wrapper. That would probably mean to leave some features behind to have the intersection. Similar to bgfx but for compute APIs, which has a shader compiler to many targets. We used a BSD 3-Clause license to make it easy for everyone to use in their own projects. Here is a blog I made about implementing Conway's Game of Life using ArrayFire http://arrayfire.com/conways-game-of-life-using-arrayfire/. It demonstrates how easy it is to use ArrayFire. Our goal is to make it easy for people to get started with GPU programming and break down the barrier for non-programmers to use the hardware efficiently. I agree that complex algorithms require more custom solutions, but once you get started, things become much easier. Your example is indeed very simple, so I guess it has its uses.
Re: Travis-CI support for D
On Thursday, 11 December 2014 at 04:50:42 UTC, Martin Nowak wrote: Glad to announce that D support on Travis-CI was launched today. http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/ This is great! Thanks a lot.
Re: dsource.org moved
On Wednesday, 3 December 2014 at 21:32:27 UTC, ketmar via Digitalmars-d-announce wrote: i think that the whole dsource site must be shut down and replaced with a stub (except planetD) to stop this disease. that site was great, but now it does more harm than good. Alternatively: use robots.txt and don't let Google index that.
Re: Coedit alpha 8 released
On Friday, 28 November 2014 at 16:39:38 UTC, Basile Burg wrote: Hello, a new release of Coedit[MainPage], the small open-source D IDE for Windows and Linux, is released. Here is a paste of the release log. Messages: = - redesigned the widget: a toolbar at the top allows to filter the messages according to a category, either all, editor (focused editor messages), project, misc (messages from the custom tools) or application (Coedit warnings or exceptions). - custom tools messages are redirected if poUsePipes is defined in the tool options. - errors messages are not split anymore (e.g: instantiated from here...) thus less confusing. Miscellaneous: == - non D files syntax highlighter: txt, md, etc. Automatically set when opening a file. - the project inspector displays the items from the project "Path" options (-I, -J, additional sources). - Zoom in,out editor with Ctrl++, Ctrl+-, restore with Ctrl+. - The static explorer widget scans in background, "refresh on change", "refresh on focus" does not freeze the GUI anymore. - various bug fixed and small improvements. - pre-build binaries include an up-to-date DCD build. - refer to the wiki[WikiPage] for more information about the changes and the new features. Pre-build binaries are available from the [ReleasePage]. - [MainPage]: https://github.com/BBasile/Coedit [ReleasePage]: https://github.com/BBasile/Coedit/releases [WikiPage]:https://github.com/BBasile/Coedit/wiki - Baz. Looks pretty cool but why not support DUB projects directly instead of your own format?
Re: DerelictSASS
On Sunday, 23 November 2014 at 19:36:16 UTC, Jacob Carlborg wrote: On 2014-11-23 01:26, Mike Parker wrote: Some people may prefer the bindings to include more D features, but IMO if you're going to put something out there for everyone and anyone to use, particularly if you want to be consistent with other Derelict bindings, it's better to avoid them. For more D features I would add a thin layer on top of the raw bindings. Like creating wrappers for functions accepting C strings and have them accept D strings instead. In this particular case I would probably have created the enum as one would do in D and the alias the enum members to make them accessible at module scope. While I like language-friendly wrappers, they do tend to make some choices. They require additional documentation since new names and usage are introduced. Sticking to the C API is choice-agnostic, existing documentation can be reused.
Re: DerelictSASS
A tip to keep in mind when translating C/C++ headers:
---
enum Sass_Tag {
SASS_BOOLEAN,
SASS_NUMBER,
SASS_COLOR
};
---
is best translated as
---
alias Sass_Tag = int;
enum : Sass_Tag {
SASS_BOOLEAN,
SASS_NUMBER,
SASS_COLOR
}
---
That way your enum isn't namespaced.
On Saturday, 22 November 2014 at 13:15:47 UTC, Mike Parker wrote:
However, I do recommend
you combine all the files into one -- sass.d. When I first
started Derelict, I separated everything out into multiple
modules for every binding. Over time, I found it makes
maintenance easier to implement a binding in one module if it is
feasible.
Going to keep that in mind.
Re: Devisualization.Image
On Tuesday, 18 November 2014 at 10:04:15 UTC, Rikki Cattermole wrote: However by the looks of things, you definitely have better quality code. At the very least some way to convert between the two e.g. SuperImage and my Image would be worth it. Please consider the abstraction in ae-graphics. http://code.dlang.org/packages/ae-graphics CyberShadow has presented his image abstraction here: http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/ It seems to be the best we have in D ecosystem and in the same spirit of Phobos. If using it we could have loader/exporters, resizing, and various processing in separate libraries with a lot of reusability, instead of each one having an incompatible image abstraction.
Re: ArrayFire, a GPU library, is now open source
On Thursday, 13 November 2014 at 02:06:03 UTC, bachmeier wrote: ArrayFire is open source, as announced on Hacker News and Reddit https://github.com/arrayfire/arrayfire Overview here: http://www.arrayfire.com/docs/index.htm There is a C API so it is easy to call from D. This should help the situation for numerical programming with D. Am I the only one to be left completely cold with the new wave of C++ to GPU libraries (Bolt/ArrayFire/OpenACC) which take back the control compute APIs give? For example this one removes double precision and multiple devices, something that is builtin with OpenCL. These libraries build on the myth that GPU's power can be harnessed without pain, but at one point you have to expose the multiple levels of parallelism that GPU have, use spatial cache locality, etc. This is like, a 60% solution.
Re: Devisualization and DWC
Nice work, it's basically the SDL replacement I wished for! I like that its scope is well defined. I don't get why it depends on DerelictGL. AFAIK SDL, GLFW and friends do not depend on GL function loaders.
Re: CUDA bindings
On Sunday, 26 October 2014 at 08:18:11 UTC, Tofu Ninja wrote: On Sunday, 26 October 2014 at 05:31:52 UTC, Dmitri Nesteruk wrote: This is great! I know that C++ uses <<< and >>> to enclose kernel calls and thus create the link between CPU and GPU code when NVCC rips things apart. How is this done in your bindings? It's just the driver api, its not CUDA code in D. Also I think you are mistaking where the <<< >>> are actually used. The <<< >>> are used in CUDA code, not in C++ code. While CUDA is a variation on C++, it is still not C++ and has to pass through a special parser that splits out the host code and the gpu code to be compiled. Yeah even in C++ it isn't that desirable, apart from prototyping.
Re: CUDA bindings
On Sunday, 26 October 2014 at 05:31:52 UTC, Dmitri Nesteruk wrote: On Tuesday, 21 October 2014 at 08:31:03 UTC, ponce wrote: On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote: Dear D users, I'd like to announce DerelictCUDA, dynamic bindings to the CUDA library. https://github.com/derelictorg/derelictcuda For now, only the CUDA Driver API is exposed, providing most of the warp control. For a visual explanation of the different APIs in CUDA, see http://stackoverflow.com/questions/242894/cuda-driver-api-vs-cuda-runtime More APIs could be implemented if the interest happens to be non-null. CUDA Runtime API added. This is great! I know that C++ uses <<< and >>> to enclose kernel calls and thus create the link between CPU and GPU code when NVCC rips things apart. How is this done in your bindings? The kernel launch syntax can only be used in CUDA when compiling for both device and host through nvcc. This isn't possible to have such with D code since nvcc won't take it. You have to compile the kernels separately, load them, and then use cudaLaunch or cuKernelLaunch instead (I suggest using string imports with PTX outputs or fatbin). This makes CUDA programming arguably less practical than with C++, but combined host+device code tend to complicate build
Re: CUDA bindings
On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote: Dear D users, I'd like to announce DerelictCUDA, dynamic bindings to the CUDA library. https://github.com/derelictorg/derelictcuda For now, only the CUDA Driver API is exposed, providing most of the warp control. For a visual explanation of the different APIs in CUDA, see http://stackoverflow.com/questions/242894/cuda-driver-api-vs-cuda-runtime More APIs could be implemented if the interest happens to be non-null. CUDA Runtime API added.
Re: CUDA bindings
On Friday, 17 October 2014 at 17:19:00 UTC, bachmeier wrote: On Thursday, 16 October 2014 at 21:18:15 UTC, ponce wrote: Dear D users, I'd like to announce DerelictCUDA, dynamic bindings to the CUDA library. https://github.com/derelictorg/derelictcuda For now, only the CUDA Driver API is exposed, providing most of the warp control. For a visual explanation of the different APIs in CUDA, see http://stackoverflow.com/questions/242894/cuda-driver-api-vs-cuda-runtime More APIs could be implemented if the interest happens to be non-null. Any chance of getting some math libraries like MAGMA? These APIs rely on the Runtime API, I need to see if this API can be implemente first. https://developer.nvidia.com/gpu-accelerated-libraries By the way, this is awesome work. Thanks, but honestly it is incomplete and wasn't much effort. I think we need some place (could be just a NG thread?) to express users needs for library/bindings. Else we don't really know what is missing.
CUDA bindings
Dear D users, I'd like to announce DerelictCUDA, dynamic bindings to the CUDA library. https://github.com/derelictorg/derelictcuda For now, only the CUDA Driver API is exposed, providing most of the warp control. For a visual explanation of the different APIs in CUDA, see http://stackoverflow.com/questions/242894/cuda-driver-api-vs-cuda-runtime More APIs could be implemented if the interest happens to be non-null.
Re: DUB 0.9.22 released
On Monday, 22 September 2014 at 09:33:52 UTC, Sönke Ludwig wrote: But even more important, I'm pleased to announce that DUB is now officially developed as part of the D language ecosystem! Based on the decision back during this year's DConf, the repository has been migrated to the D-Programming-Language organization on GitHub [1], and we are now working towards a 1.0.0 milestone [2] that is supposed to be ready for inclusion into the official DMD installation package. Yay! Thanks for all the work on DUB. Integrating third-party libraries has become so easy and practical with it, it encourages more code reuse.
[OT] Re: libcerf (D sources)
On Sunday, 21 September 2014 at 16:12:08 UTC, Ilya Yaroshenko wrote: Self-contained numeric library that provides an efficient and accurate implementation of complex error functions, along with Dawson, Faddeeva, and Voigt functions. https://github.com/9il/libcerf The error function is used for Gaussian integrals, where should we use the Dawson, Faddeeva, and Voigt functions? Just curious.
Re: Multiple alias this is coming.
On Thursday, 18 September 2014 at 13:44:10 UTC, Marc Schütz wrote: On Thursday, 18 September 2014 at 12:51:48 UTC, Rikki Cattermole wrote: On 18/09/2014 11:20 p.m., IgorStepanov wrote: I've created pull request, which introduces multiple alias this. https://github.com/D-Programming-Language/dmd/pull/3998 Please see the additional tests and comment it. Awesome was waiting for something like this! Also did we ever consider alias this = ...; syntax? It clashes with (not yet supported) aliasing of constructors. Call me unimaginative, but I'm struggling to see any use case for multiple alias this, and I struggle even more for such constructors aliasing.
Re: 438-byte "Hello, world" Win32 EXE in D
On Sunday, 7 September 2014 at 21:03:17 UTC, Vladimir Panteleev wrote: The 438-byte "Hello, world" program is achieved using Crinkler, which is a COFF linker with aggressive compression and header optimization. It was created for compressing 4K demos. Pretty cool! Up to now D had little chance to compete in 4k and 64k demo competitions because of the inability to use Crinkler.
Re: Mago Debugger changes hands
On Sunday, 10 August 2014 at 03:33:11 UTC, Aldo Nunez wrote: Greetings to all Mago Debugger, Visual D, and interested D users. After 5 years, I can no longer continue development of Mago Debugger. The project requires too much attention for me to keep working on it while keeping my family happy. I learned a ton, and feel satisfied to have contributed to the D Programming Language. I'm handing off the project to Rainer Schuetze. He has forked it at github (https://github.com/rainers/mago). If you're interested in contributing to it, please contact him. Thanks for your work, it made my D-life way better. Switching to Mago debugger is the first thing I do right after "dub generate visuald".
Re: Coloring terminal output.
On Thursday, 31 July 2014 at 12:09:41 UTC, Suliman wrote: On Thursday, 31 July 2014 at 09:37:25 UTC, ponce wrote: On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote: I've made a simple port of ruby's colorize library for D. I'd greatly appreciate any feedback. Windows isn't supported, yet. Cool! Would it be hard to add windows support? Windows support added. It relies on a partial ANSI/VT100 interpreter to allow colors to stay in the string. I tried to build on Windows example and get on console next: D:\code\d>appcolor.exe ←[34mThis is blue←[0m You have to use cwrite/cwritef/cwriteln/cwritefln, and it's not yet in the examples.
Re: Coloring terminal output.
On Monday, 14 July 2014 at 19:57:32 UTC, Suliman wrote: I've made a simple port of ruby's colorize library for D. I'd greatly appreciate any feedback. Windows isn't supported, yet. Cool! Would it be hard to add windows support? Windows support added. It relies on a partial ANSI/VT100 interpreter to allow colors to stay in the string.
Re: dstats reborn
On Thursday, 17 July 2014 at 15:20:20 UTC, John Colvin wrote: David Simcha's stats library is full of useful code and it was a shame to let it rot. I've patched it up to work with modern D compilers and added dub support. https://github.com/John-Colvin/dstats http://code.dlang.org/packages/dstats I have also made a pull request to David's repository to integrate these changes. If they are merged there then I'll redirect the dub respository and add a link in the readme on my github fork. Great! dstats is useful for A/B performance measurements, with its various statistical tests.
Re: DConf 2014 Day 2 Talk 3: Designing an Aurora: A Glimpse at the Graphical Future of D by Adam Wilson
On Thursday, 10 July 2014 at 00:22:39 UTC, Tofu Ninja wrote: I think its a fine abstraction level, buffers and shaders are not hard concepts at all. All api's that Aurora is going to be based on offers them as well as all modern gpu's support them. If shaders were written in a DLS then in the case where Aurora needs to fall back to software rendering then they can be translated to D code and mixed right in. When they need to be turned into some api specific shader then they could be translated at compile time(the differences should mostly just be syntax). If the DSL was a subset of D then that would simplify it even further as well as make the learning curve much smaller. Its a perfectly fine level of abstraction for any sort of graphics that also happens to be supported very well by modern GPU's. I don't see the problem. You might want to look at what bgfx does: https://github.com/bkaradzic/bgfx It provides a shader compiler to various supported backends. Abstracting shaders more or less mandates having a shader compiler from your language to graphics API out there. It does make an additional build step. Compiling such a shader abstraction language at compile-time seems a bit optimistic to me.
bgfx bindings
Hi, I'd like to announce DerelictBgfx, a dynamic bindings to the bgfx library. https://github.com/derelictorg/derelictbgfx bgfx is a library which abstract the accelerated graphics API through a common denominator. DX9, DX11, Desktop OpenGL and OpenGL ES can be used from the same abstraction. I believe it to be useful and risk-mitigating for games. To allows this feat, a shader language and compiler is included in the original library there: https://github.com/bkaradzic/bgfx Using the derelict-bgfx package, you would have to build bgfx as a dynamic library and the associated shader compiler. bgfx is decoupled from the windowing library. It can be used through the likes of SDL and GLFW, provided a OS-dependent window handle is given.
Re: Article: Functional image processing in D
On Friday, 21 March 2014 at 11:04:58 UTC, Vladimir Panteleev wrote: http://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/ Some highlights from a recent overhaul of the graphics package from my D library. It makes use of a number of D-specific language features, so I've tried to make the article accessible to people new to D as well. The graphics package described in Vladimir's post has been separated in a stand-alone DUB package here: https://github.com/p0nce/ae-graphics
Re: OpenGL Examples in D and a birth of a New Initiative
On Monday, 19 May 2014 at 21:00:37 UTC, Colden Cullen wrote: As far as bullet goes, that would be amazing, but definitely no small undertaking. We talked about it internally, but decided it wasn't worth the time for just trying to get Dash off the ground. You should know, though, that if you do it, you'll have at least one user :) This might be of interest then: https://github.com/MeinMein/BulletD
Re: 10 Years of Derelict
On Thursday, 15 May 2014 at 15:02:33 UTC, Mike Parker wrote: I managed to let this little anniversary slip by me. My first post in the old Derelict forum at DSource[1] is dated May 6, 2004, my initial commit to svn[2] was May 7, and my announcement in the newsgroup[3] was on May 8. My attention to the project has waxed and waned, but I'm still puttering along. I expect to continue for the forseeable future. There have been a number of contributors over the years who have helped out in porting to Linux and Mac, fixing bugs, and keeping the bindings up to date. It's been very much a community project, which has made it more enjoyable to work on. It helps that it isn't difficult to maintain :) Maybe before the next decade goes by I'll actually finish a game in D, which is the reason I started Derelict in the first place. For those who don't know, the current iteration of Derelict can be found at the DerelictOrg group at github[4]. I've still got work to do on it (ahem, documentation), but it's coming along. [1] http://www.dsource.org/forums/viewtopic.php?t=105 [2] http://www.dsource.org/projects/derelict/changeset/5/ [3] http://forum.dlang.org/thread/c7hl51$2k4u$1...@digitaldaemon.com [4] https://github.com/DerelictOrg Thanks for that long dedication! Using it since 7 years :) I probably wouldn't have stucked with D if it weren't for Derelict, and I know other people who wouldn't have either.
Re: Livestreaming DConf?
On Friday, 9 May 2014 at 19:48:20 UTC, Andrei Alexandrescu wrote: Hi folks, We at Facebook are very excited about the upcoming DConf 2014. In fact, so excited we're considering livestreaming the event for the benefit of the many of us who can't make it to Menlo Park, CA. Livestreaming entails additional costs so we're trying to assess the size of the online audience. Please follow up here and on twitter: https://twitter.com/D_Programming/status/464854296001933312 Thanks, Andrei Yes please! I'll be up all night :p
Re: New libraries wave-d and y4m-d
On Wednesday, 30 April 2014 at 13:39:41 UTC, Chris wrote: On Wednesday, 30 April 2014 at 12:24:14 UTC, ponce wrote: On Wednesday, 30 April 2014 at 08:34:42 UTC, Chris wrote: That's great! At the moment I'm using PortAudio and libsndfile, it would be nice to have a D sound library one day. What are you missing in the current offering? Current offering of what, waved or portaudio/libsndfile? "Current offering" as in the set of libraries available from D. libsndfile and portaudio can be used through bindings. But maybe you were thinking about eventually not using them?
Re: New libraries wave-d and y4m-d
On Wednesday, 30 April 2014 at 08:34:42 UTC, Chris wrote: That's great! At the moment I'm using PortAudio and libsndfile, it would be nice to have a D sound library one day. What are you missing in the current offering?
Re: New libraries wave-d and y4m-d
On Wednesday, 30 April 2014 at 02:47:38 UTC, Rikki Cattermole wrote: I checked out y4m-d when it went up on the dub repository. Looks interesting. I do have to ask, are you interested in creating a unified library for multimedia with a importers/exporters a bit like ASIMPP? Because I think that could be rather useful and not too much work on top of the given types already had. Not really especially for video. Muxed video requires superior abstractions that I won't get right. Real streams may contains dynamic "type-change" and time flows continuously. So the generic "streal" abstraction when opening multimedia will be much more involved than in y4m, and this hard work has already been done in ffmpeg/libav.
Re: New libraries wave-d and y4m-d
There was a typo error: https://github.com/p0nce/y4m-d On Tuesday, 29 April 2014 at 18:46:51 UTC, ponce wrote: y4m-d is a library for reading and writing Y4M files. https://github.com/p0nce/wave-d
New libraries wave-d and y4m-d
wave-d is a library for reading and writing WAV format (range-based). https://github.com/p0nce/wave-d --- y4m-d is a library for reading and writing Y4M files. https://github.com/p0nce/wave-d Y4M is one of the simplest uncompressed video format, it's designed to provide a bit of meta-data over raw YUV files.
