Re: dsq-1: open-source software synthesizer
On 30/03/2015 7:26 p.m., ketmar wrote: On Mon, 30 Mar 2015 19:17:35 +1300, Rikki Cattermole wrote: On 30/03/2015 7:14 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote: On 30/03/2015 6:35 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote: Although I'm a little concerned because dub is meant to validate and tell you conflicts in licenses. O_O Hey hey hey, context matters! i'm speechless 'cause it's a great idea (let machine do it work!), but i'm not sure how this can be done with wide broad of licenses out here. and i definetely want to see "std.license.compare" in Phobos! ;-) I agree, I'm concerned about this as well. But hey, its one of the features the dub developers want to have. what i really want to have is "libdub". i.e. turning dub to library, so it can be easily integrated in any D project (rdmd comes to mind first). i don't want D building abilities, for example, but i really like to use it's package management part (and get list of files and compiler flags for that packages). sure, i can do this by parsing dub jsons and execing dub itself to do package management work, but libdub is better... maybe someday i'll wrote such thing. ;-) Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code.
Re: dsq-1: open-source software synthesizer
On Mon, 30 Mar 2015 19:17:35 +1300, Rikki Cattermole wrote: > On 30/03/2015 7:14 p.m., ketmar wrote: >> On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote: >> >>> On 30/03/2015 6:35 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote: > Although I'm a little concerned because dub is meant to validate and > tell you conflicts in licenses. O_O >>> >>> Hey hey hey, context matters! >> >> i'm speechless 'cause it's a great idea (let machine do it work!), but >> i'm not sure how this can be done with wide broad of licenses out here. >> >> and i definetely want to see "std.license.compare" in Phobos! ;-) > > I agree, I'm concerned about this as well. But hey, its one of the > features the dub developers want to have. what i really want to have is "libdub". i.e. turning dub to library, so it can be easily integrated in any D project (rdmd comes to mind first). i don't want D building abilities, for example, but i really like to use it's package management part (and get list of files and compiler flags for that packages). sure, i can do this by parsing dub jsons and execing dub itself to do package management work, but libdub is better... maybe someday i'll wrote such thing. ;-) signature.asc Description: PGP signature
Re: dsq-1: open-source software synthesizer
On 30/03/2015 7:14 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote: On 30/03/2015 6:35 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote: Although I'm a little concerned because dub is meant to validate and tell you conflicts in licenses. O_O Hey hey hey, context matters! i'm speechless 'cause it's a great idea (let machine do it work!), but i'm not sure how this can be done with wide broad of licenses out here. and i definetely want to see "std.license.compare" in Phobos! ;-) I agree, I'm concerned about this as well. But hey, its one of the features the dub developers want to have.
Re: dsq-1: open-source software synthesizer
On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote: > On 30/03/2015 6:35 p.m., ketmar wrote: >> On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote: >> >>> Although I'm a little concerned because dub is meant to validate and >>> tell you conflicts in licenses. >> >> O_O > > Hey hey hey, context matters! i'm speechless 'cause it's a great idea (let machine do it work!), but i'm not sure how this can be done with wide broad of licenses out here. and i definetely want to see "std.license.compare" in Phobos! ;-) signature.asc Description: PGP signature
Re: dsq-1: open-source software synthesizer
On 30/03/2015 6:35 p.m., ketmar wrote: On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote: Although I'm a little concerned because dub is meant to validate and tell you conflicts in licenses. O_O Hey hey hey, context matters!
Re: dsq-1: open-source software synthesizer
On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote: > Although I'm a little concerned because dub is meant to validate and > tell you conflicts in licenses. O_O signature.asc Description: PGP signature
Re: dsq-1: open-source software synthesizer
On 30/03/2015 6:18 p.m., ketmar wrote: On Mon, 30 Mar 2015 17:46:07 +1300, Rikki Cattermole wrote: That's a rather interesting license. Maybe add a TLDR into your readme? As I doubt most people here have seen it before. ah, 'cmon, one can google all the info in no time. i'd say it's probably time to stop guiding people on every single detail, this is gone too far. This is a primarily a french license. It took me a good while to understand that it was compatible with e.g. MIT. Although I'm a little concerned because dub is meant to validate and tell you conflicts in licenses. I don't know if it would be worth adding this one.
Re: dsq-1: open-source software synthesizer
On Mon, 30 Mar 2015 17:46:07 +1300, Rikki Cattermole wrote: > That's a rather interesting license. Maybe add a TLDR into your readme? > As I doubt most people here have seen it before. ah, 'cmon, one can google all the info in no time. i'd say it's probably time to stop guiding people on every single detail, this is gone too far. signature.asc Description: PGP signature
Re: dsq-1: open-source software synthesizer
On 30/03/2015 6:02 a.m., D. Martinez wrote: I am releasing today a first version of dsq-1: a software synthesizer modeled after some great 80's hybrid synths, Ensoniq ESQ-1 and SQ-80. The 'd' in the project's name stands for the author's first name, as well as, you know. ;) The source code for the project is currently located on github: https://github.com/martinez/dsq1 This project is a huge work in progress and is far for complete; the sound output is not very interesting in the current state and needs a lot of work. Most of the architecture is implemented according to reverse-engineered information, some done by me, but mostly from Rainer Buchty which has done an extensive amount of work on this machine (cf. his website). My progress is not going fast on this project, because I am currently busy with my Ph.D and other work. I share it because it will interest whoever wants to hack on this machine, because it implements the proprietary formats used (patch, waverom, etc..), or whoever wants to help on synthesis. I happily accept contributions. Working with D has been generally a joy (coming from a C++ background), but there have been a number of annoyances to me, be it bugs or lack of features. I have kept a list of observations, into the project's TODO file. Most importantly: 1. My main grief so far has been the compilers. LDC has failed on me with a stack trace and no other information. This is reproducible on the latest commit, when there exists a dependency to the "tkd" library. Last time I checked this bug was reported on the issue tracker but not fixed yet. On the other hand the dmd compiler however has been very stable for me. 2. The function attributes: @nogc nothrow. These relate to my realtime audio thread because I want neither of these things to occur; my thread runs unmanaged by the D runtime and I appreciate the static checking. But I don't use it: why? I use writefln a lot to debug my implementations, which is incompatible with either assumption. I wish it were possible to bypass @nogc nothrow in debug mode, only to emit a warning. To change dozens of functions to set @nogc on/off depending on usage context is not practical. I hope D can provide a better solution, than systematic use of sed scripts. :) --- About the project itself for the interested: See TODO.txt for a (non-exhaustive) list of things missing. It has many subprojects, organized as such: - synth: it implements the various parts of the softsynth (EG, OSC, LFO, ...) - jack: softsynth for Linux implemented as a jack client - synthui: user interface (nothing is done right now). not to be used directly, the process is instantiated by the softsynth and communicates via OSC protocol. - synthlib: components that relate to the internal proprietary structures: patches and waves. relevant if one is implementing a librarian for instance - liblo: binding to a OSC client/server library with C API - util: various stuff for implementing and testing. math routines, plotting, fixed point. The fixed-point implementation math.fp is intended as a drop-in replacement for float and is a template for various precisions on 32-bit ints (ie. 16/16, 24/8 etc). - fptest: a playground project for testing fixed-point math - esqtest: a playground project for independently testing internal components of the softsynth (wavetable synth, LFOs...) - banker: what could be a bank management (aka. "librarian") application in the future. it can current open and display banks stored on disk (sysex/mdx), but no write support. GUI is horrible. - to appear in the future: vstplug. a vst implementation, which should not be hard to do, possibly using the dplug library. I make this project in the hope to port it to embedded ARM, if it ever gets somewhere. I have some analog CEM VCF chips to use in this project from one of these dead units. The bad thing is that because the unit's dead I don't have a good basis for comparison. So I am aiming for good results, not 100% fidelity with the original. I am not myself very good in math nor DSP programming, so again I welcome the work of contributors. The porting to ARM, specifically STM32F4, will be hopefully an opportunity for me to extend on the work of others on embedded D. link for reference: http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22 That's a rather interesting license. Maybe add a TLDR into your readme? As I doubt most people here have seen it before.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sun, 29 Mar 2015 14:43:14 -0700, Walter Bright wrote: > On 3/28/2015 5:34 PM, ketmar wrote: >> on the other side of the spectrum was Chuck Moore, for example, who >> imagines modern computers filled with many cheap and average RISC >> processors, and using parallel multiprocessor execution to achieve >> great performance. > > Isn't that what a GPU is? yes, GPU is a good example of that. signature.asc Description: PGP signature
Re: dsq-1: open-source software synthesizer
On Sun, 29 Mar 2015 17:02:53 +, D. Martinez wrote:
> 2. The function attributes: @nogc nothrow. These relate to my realtime
> audio thread because I want neither of these things to occur; my thread
> runs unmanaged by the D runtime and I appreciate the static checking.
> But I don't use it: why?
> I use writefln a lot to debug my implementations, which is incompatible
> with either assumption.
that's why i wrote `iv.writer` with compile-time format strings and nogc
conversions for numbers. it still using `to!` for other objects
(including floating point numbers, but this can be fixed). output strings
and integral numbers is enough for debug logs for me. althru it's not
"vanilla" D, it's still very easy to backport to D2 (actually, "sed" will
do). it is build on templates, so it infers attributes. most of the time
this is "nothrow @nogc".
and, to stop talking about myself, here is some hackery for you:
import std.traits;
auto assumeNoTrowNoGC(T) (T t)
if (isFunctionPointer!T || isDelegate!T)
{
enum attrs = functionAttributes!T|
FunctionAttribute.nogc|
FunctionAttribute.nothrow_;
return cast(SetFunctionAttributes!(T, functionLinkage!T, attrs)) t;
}
void myFuncThatDoesGC () {
throw new Exception("hello!");
}
void anotherFunction () nothrow @nogc {
//myFuncThatDoesGC(); // alas, but
assumeNoTrowNoGC(() { myFuncThatDoesGC(); })(); // yay!
}
but don't tell anyone that you got this code from me, or Type Nazis will
kill me! ;-)
signature.asc
Description: PGP signature
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Monday, 30 March 2015 at 03:47:45 UTC, Joakim wrote: On Monday, 30 March 2015 at 00:20:11 UTC, Laeeth Isharc wrote: https://www.quora.com/Why-didnt-D-language-become-mainstream-comparing-to-Golang fwiw Nice, well-written answer, enjoyed reading it. Thank you.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Monday, 30 March 2015 at 00:20:11 UTC, Laeeth Isharc wrote: https://www.quora.com/Why-didnt-D-language-become-mainstream-comparing-to-Golang fwiw Nice, well-written answer, enjoyed reading it.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sunday, 29 March 2015 at 16:32:32 UTC, Idan Arye wrote: Computer science is all about tradeoffs. I used to love Ruby, but then a Rails project got out of hand... Nowadays I use it mainly as a bash replacement - Hundredfolds more expressive, only a tiny tiny bit syntax overhead, and for things that bash's safety would be enough Ruby's certainly suffices. This is pretty much the recurring story with ruby. The first 10 000 lines are a lot of fun, and then it gets out of hands.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sunday, 29 March 2015 at 21:43:21 UTC, Walter Bright wrote: On 3/28/2015 5:34 PM, ketmar wrote: on the other side of the spectrum was Chuck Moore, for example, who imagines modern computers filled with many cheap and average RISC processors, and using parallel multiprocessor execution to achieve great performance. Isn't that what a GPU is? This is exactly what a GPU is.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sunday, 29 March 2015 at 08:37:54 UTC, Idan Arye wrote: On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote: On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote: Personally, I'm not sure that much is gained in pitting Go against D precisely because they're so different that they're likely to appeal to completely different sets of people. I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby. How is Go a competitor to Ruby? I cannot think of a single parameter where Go and Ruby don't take the exact opposite approach!(other than the obvious ones like "both use require the programmer to write code") They appeal to programmer that prefers fashionable technology rather than technologies that solve problems.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Saturday, 28 March 2015 at 14:33:14 UTC, Russel Winder wrote: On Sat, 2015-03-28 at 12:52 +0100, Sönke Ludwig via Digitalmars-d-announce wrote: […] You can access TLS from an event callback just as easy as from a fiber. […] TLS is the evil here. Anyone working with TLS is either writing an operating system or doing it wrong. Or, you know, doing it safe. Unlike Go.
Re: This Week in D #11: new release, undocumented feature exposed, FAQ answered, DConf schedule posted.
On Monday, 30 March 2015 at 01:14:59 UTC, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/mar-29.html The big pieces have already been posted to Reddit, so idk if we want to post again, but if you want to, go ahead and just post the reddit link here too as this is a nice little roundup. I also took the opportunity to document the new ddoc `code` feature! I think reddit is starting to act unfriendly to frequent D posts now, this week in D maybe shouldn't be cross-posted there so much. Thanks for the update.
This Week in D #11: new release, undocumented feature exposed, FAQ answered, DConf schedule posted.
http://arsdnet.net/this-week-in-d/mar-29.html The big pieces have already been posted to Reddit, so idk if we want to post again, but if you want to, go ahead and just post the reddit link here too as this is a nice little roundup. I also took the opportunity to document the new ddoc `code` feature!
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Thursday, 26 March 2015 at 08:44:20 UTC, Gary Willoughby wrote: I wrote the article in a rush last night (girlfriend calling me to bed) and as a result it has a few spelling/grammar errors which I've hopefully corrected. The article is a total rant about Go after using it over the last month or so for a project. I honestly was getting so bored with Go and the article that I was literally falling asleep writing it. lol! Is started liking Go but after a while I found it increasing difficult trying to change me way of working to shoehorn solutions into such a simple language. I know it's a bit unfair in places and it's got a click bait title but who cares? I got my point across and I think people understand where i'm coming from. It seems to have got really popular and I've been swamped with mail, etc. I think it's the most read article i've ever written. ha! :o) https://www.quora.com/Why-didnt-D-language-become-mainstream-comparing-to-Golang fwiw
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On 3/29/2015 2:46 PM, cym13 wrote: On Sunday, 29 March 2015 at 21:45:23 UTC, Walter Bright wrote: On 3/29/2015 12:09 PM, Laeeth Isharc wrote: As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html Has someone reddit-ized it? It seems so: http://www.reddit.com/r/programming/comments/2tqiaj/d_is_like_native_python/?submit_url=http%3A%2F%2Fbitbashing.io%2F2015%2F01%2F26%2Fd-is-like-native-python.html&already_submitted=true Ah, thanks!
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
should we add a link to the wiki and ask author if we could mirror there ? This section on wiki looks like it could with a bit of fleshing out! http://wiki.dlang.org/Coming_From/Python I just seen what you did in the wiki, that's great! I don't have much time to invest tonight but I'll definitely do my part of the job in a day or two. Thank you for noticing. It's not very inspired, but I don't have much energy at the moment, and it is the best I can do with what I have. Better an acceptable start than trying to be perfect. The Ruby / Java / Eiffel / C# / and Basic sections also need starting.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sunday, 29 March 2015 at 21:06:28 UTC, Laeeth Isharc wrote: On Sunday, 29 March 2015 at 19:44:01 UTC, cym13 wrote: On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote: As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html I like this article very much. IMO python's generators and list comprehensions are the two things that are the most difficult to replace when switching to another language. Hence I would explicitely make a link with list comprehensions in the UFCS paragraph because it is not obvious. I would also add a little paragraph about ranges to make the link from generators (but maybe not with an example as it may be scarier than it really is). In the same way of making the parallel with python, many developers seem to use python for web serveurs nowadays. It would be great to include a link to vibe.d in the article. Something simple like "or web server developments with vibe.d" thrown in a sentence. Also, but this one would be a sensible addition, I'm sorry to see that nothing is said about purity or safety. I definitely think that it can be a good selling argument, even if it goes beyond the goal "Writting Python in D". Otherwise, I find the article very good. It emphasis the good points, even those that are often forgotten like dub (because pypi is so important in python). I'll try giving it to some friends to see what they think about it :) should we add a link to the wiki and ask author if we could mirror there ? This section on wiki looks like it could with a bit of fleshing out! http://wiki.dlang.org/Coming_From/Python I just seen what you did in the wiki, that's great! I don't have much time to invest tonight but I'll definitely do my part of the job in a day or two.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sunday, 29 March 2015 at 21:45:23 UTC, Walter Bright wrote: On 3/29/2015 12:09 PM, Laeeth Isharc wrote: As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html Has someone reddit-ized it? It seems so: http://www.reddit.com/r/programming/comments/2tqiaj/d_is_like_native_python/?submit_url=http%3A%2F%2Fbitbashing.io%2F2015%2F01%2F26%2Fd-is-like-native-python.html&already_submitted=true
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On 3/29/2015 12:09 PM, Laeeth Isharc wrote: As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html Has someone reddit-ized it?
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On 3/28/2015 5:34 PM, ketmar wrote: on the other side of the spectrum was Chuck Moore, for example, who imagines modern computers filled with many cheap and average RISC processors, and using parallel multiprocessor execution to achieve great performance. Isn't that what a GPU is?
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sunday, 29 March 2015 at 19:44:01 UTC, cym13 wrote: On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote: As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html I like this article very much. IMO python's generators and list comprehensions are the two things that are the most difficult to replace when switching to another language. Hence I would explicitely make a link with list comprehensions in the UFCS paragraph because it is not obvious. I would also add a little paragraph about ranges to make the link from generators (but maybe not with an example as it may be scarier than it really is). In the same way of making the parallel with python, many developers seem to use python for web serveurs nowadays. It would be great to include a link to vibe.d in the article. Something simple like "or web server developments with vibe.d" thrown in a sentence. Also, but this one would be a sensible addition, I'm sorry to see that nothing is said about purity or safety. I definitely think that it can be a good selling argument, even if it goes beyond the goal "Writting Python in D". Otherwise, I find the article very good. It emphasis the good points, even those that are often forgotten like dub (because pypi is so important in python). I'll try giving it to some friends to see what they think about it :) should we add a link to the wiki and ask author if we could mirror there ? This section on wiki looks like it could with a bit of fleshing out! http://wiki.dlang.org/Coming_From/Python
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote: On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote: Urr As an active Python developer, I find that one pretty harsh. It's not that we need to enforce good style, it's that we take good style as granted and choose to lighten it consequently. On the contrary I think that D has everything to attract a pythonista. Most new, trendy languages like Go or Rust are to down a level to easily suit a python's formated mind, and I guess that if most python developers come to switch language for performance issues (like myself) D's code safety system is definitely very appealing because python's safety is... well... ^^" Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it). UFCS FTW! As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html while it mentions concurrency/parallel, a quick example of showing how easy it is to do parallel operations in D would probably benefit considering python's current state of parallelism.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sunday, 29 March 2015 at 19:09:52 UTC, Laeeth Isharc wrote: As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html I like this article very much. IMO python's generators and list comprehensions are the two things that are the most difficult to replace when switching to another language. Hence I would explicitely make a link with list comprehensions in the UFCS paragraph because it is not obvious. I would also add a little paragraph about ranges to make the link from generators (but maybe not with an example as it may be scarier than it really is). In the same way of making the parallel with python, many developers seem to use python for web serveurs nowadays. It would be great to include a link to vibe.d in the article. Something simple like "or web server developments with vibe.d" thrown in a sentence. Also, but this one would be a sensible addition, I'm sorry to see that nothing is said about purity or safety. I definitely think that it can be a good selling argument, even if it goes beyond the goal "Writting Python in D". Otherwise, I find the article very good. It emphasis the good points, even those that are often forgotten like dub (because pypi is so important in python). I'll try giving it to some friends to see what they think about it :)
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote: Urr As an active Python developer, I find that one pretty harsh. It's not that we need to enforce good style, it's that we take good style as granted and choose to lighten it consequently. On the contrary I think that D has everything to attract a pythonista. Most new, trendy languages like Go or Rust are to down a level to easily suit a python's formated mind, and I guess that if most python developers come to switch language for performance issues (like myself) D's code safety system is definitely very appealing because python's safety is... well... ^^" Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it). UFCS FTW! As an active Python developer, what would you add to or change about the following: http://bitbashing.io/2015/01/26/d-is-like-native-python.html
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sunday, 29 March 2015 at 15:34:35 UTC, Ola Fosheim Grøstad wrote: Actually, there is quite a large overlap if you look beyond the syntax. Dart is completely unexciting, but I also find it very productive when used with the IDE. Glad to hear this - I haven't yet got very far with Dart, but it seems like a toss-up between Dart and Livescript for a passable language to run on the client (for my little use case). Anyway, my point was more that making Python a target means you have to compete with a large set of other languages in the same vein. In the system language area you only have C++/Rust so it is an easier target. Unfortunately C++ still has a lot of advantages over other languages for real world projects, so it will remain my system level language until a better language starts polishing their low level stuff... :-/ Peter Thiel is right. Competition is overrated, and it is much better to have a monopoly in a small domain and build out from there - one shouldn't think in terms of acquiring market share if one is not already one of the dominant players (and even then to do so is often counterproductive). D isn't a product marketed by Proctor and Gamble. So nobody is going to make Python a target, as best I can tell. But one can surely learn from what they do right, to the extent that it applies to new conditions of the future. The obvious things are documentation, libraries, and having a nice, easy-to-install, and low-friction set of choices in development stacks organised and available. Knuth is also right that people think in different ways, and it's an entirely natural thing to see a multiplicity of languages emerging that are adapted to these different ways (and of course the particular challenges people face are also different). That's why religious wars about these things have a bad name. That doesn't mean people shouldn't have a perspective and argue for it when such discussions are generative. D will continue to gather success if it keeps getting better and confronting the painful challenges of growth, as seems to me to be happening in my short time here. Naysayers are an asset if one doesn't get discouraged, because it is difficult to buy good criticism at any price.
Re: dsq-1: open-source software synthesizer
On Sunday, 29 March 2015 at 17:30:39 UTC, Foo wrote: On Sunday, 29 March 2015 at 17:24:53 UTC, Joakim wrote: Hmm, this sounds like it might be a bug or design flaw. "debug" is supposed to provide an escape hatch from even pure functions: I don't see why it wouldn't provide the same for @nogc and nothrow. At the very least, we should have a @nogc/nothrow alternative to writefln to allow such simple debugging. import core.stdc.stdio : printf; I'm aware of that option and thought of mentioning it, but it is inconvenient when dealing with D strings.
Re: dsq-1: open-source software synthesizer
On Sunday, 29 March 2015 at 17:24:53 UTC, Joakim wrote: On Sunday, 29 March 2015 at 17:02:54 UTC, D. Martinez wrote: 2. The function attributes: @nogc nothrow. These relate to my realtime audio thread because I want neither of these things to occur; my thread runs unmanaged by the D runtime and I appreciate the static checking. But I don't use it: why? I use writefln a lot to debug my implementations, which is incompatible with either assumption. I wish it were possible to bypass @nogc nothrow in debug mode, only to emit a warning. To change dozens of functions to set @nogc on/off depending on usage context is not practical. I hope D can provide a better solution, than systematic use of sed scripts. :) Hmm, this sounds like it might be a bug or design flaw. "debug" is supposed to provide an escape hatch from even pure functions: I don't see why it wouldn't provide the same for @nogc and nothrow. At the very least, we should have a @nogc/nothrow alternative to writefln to allow such simple debugging. import core.stdc.stdio : printf;
Re: dsq-1: open-source software synthesizer
On Sunday, 29 March 2015 at 17:02:54 UTC, D. Martinez wrote: 2. The function attributes: @nogc nothrow. These relate to my realtime audio thread because I want neither of these things to occur; my thread runs unmanaged by the D runtime and I appreciate the static checking. But I don't use it: why? I use writefln a lot to debug my implementations, which is incompatible with either assumption. I wish it were possible to bypass @nogc nothrow in debug mode, only to emit a warning. To change dozens of functions to set @nogc on/off depending on usage context is not practical. I hope D can provide a better solution, than systematic use of sed scripts. :) Hmm, this sounds like it might be a bug or design flaw. "debug" is supposed to provide an escape hatch from even pure functions: I don't see why it wouldn't provide the same for @nogc and nothrow. At the very least, we should have a @nogc/nothrow alternative to writefln to allow such simple debugging.
dsq-1: open-source software synthesizer
I am releasing today a first version of dsq-1: a software synthesizer modeled after some great 80's hybrid synths, Ensoniq ESQ-1 and SQ-80. The 'd' in the project's name stands for the author's first name, as well as, you know. ;) The source code for the project is currently located on github: https://github.com/martinez/dsq1 This project is a huge work in progress and is far for complete; the sound output is not very interesting in the current state and needs a lot of work. Most of the architecture is implemented according to reverse-engineered information, some done by me, but mostly from Rainer Buchty which has done an extensive amount of work on this machine (cf. his website). My progress is not going fast on this project, because I am currently busy with my Ph.D and other work. I share it because it will interest whoever wants to hack on this machine, because it implements the proprietary formats used (patch, waverom, etc..), or whoever wants to help on synthesis. I happily accept contributions. Working with D has been generally a joy (coming from a C++ background), but there have been a number of annoyances to me, be it bugs or lack of features. I have kept a list of observations, into the project's TODO file. Most importantly: 1. My main grief so far has been the compilers. LDC has failed on me with a stack trace and no other information. This is reproducible on the latest commit, when there exists a dependency to the "tkd" library. Last time I checked this bug was reported on the issue tracker but not fixed yet. On the other hand the dmd compiler however has been very stable for me. 2. The function attributes: @nogc nothrow. These relate to my realtime audio thread because I want neither of these things to occur; my thread runs unmanaged by the D runtime and I appreciate the static checking. But I don't use it: why? I use writefln a lot to debug my implementations, which is incompatible with either assumption. I wish it were possible to bypass @nogc nothrow in debug mode, only to emit a warning. To change dozens of functions to set @nogc on/off depending on usage context is not practical. I hope D can provide a better solution, than systematic use of sed scripts. :) --- About the project itself for the interested: See TODO.txt for a (non-exhaustive) list of things missing. It has many subprojects, organized as such: - synth: it implements the various parts of the softsynth (EG, OSC, LFO, ...) - jack: softsynth for Linux implemented as a jack client - synthui: user interface (nothing is done right now). not to be used directly, the process is instantiated by the softsynth and communicates via OSC protocol. - synthlib: components that relate to the internal proprietary structures: patches and waves. relevant if one is implementing a librarian for instance - liblo: binding to a OSC client/server library with C API - util: various stuff for implementing and testing. math routines, plotting, fixed point. The fixed-point implementation math.fp is intended as a drop-in replacement for float and is a template for various precisions on 32-bit ints (ie. 16/16, 24/8 etc). - fptest: a playground project for testing fixed-point math - esqtest: a playground project for independently testing internal components of the softsynth (wavetable synth, LFOs...) - banker: what could be a bank management (aka. "librarian") application in the future. it can current open and display banks stored on disk (sysex/mdx), but no write support. GUI is horrible. - to appear in the future: vstplug. a vst implementation, which should not be hard to do, possibly using the dplug library. I make this project in the hope to port it to embedded ARM, if it ever gets somewhere. I have some analog CEM VCF chips to use in this project from one of these dead units. The bad thing is that because the unit's dead I don't have a good basis for comparison. So I am aiming for good results, not 100% fidelity with the original. I am not myself very good in math nor DSP programming, so again I welcome the work of contributors. The porting to ARM, specifically STM32F4, will be hopefully an opportunity for me to extend on the work of others on embedded D. link for reference: http://wiki.dlang.org/Minimal_semihosted_ARM_Cortex-M_%22Hello_World%22
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sunday, 29 March 2015 at 15:57:18 UTC, Andrei Alexandrescu
wrote:
On 3/29/15 4:43 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
" wrote:
On Sunday, 29 March 2015 at 08:37:54 UTC, Idan Arye wrote:
On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright
wrote:
On 3/28/2015 3:20 AM, Jonathan M Davis via
Digitalmars-d-announce wrote:
Personally, I'm not sure that much is gained in pitting Go
against D
precisely because they're so different that they're likely
to appeal to
completely different sets of people.
I also do not regard Go as a competitor to D. It's more of a
competitor to Java and Ruby.
How is Go a competitor to Ruby? I cannot think of a single
parameter
where Go and Ruby don't take the exact opposite
approach!(other than
the obvious ones like "both use require the programmer to
write code")
I think it's more of a competitor to Rails. Ruby as a language
is as you
say very different from Go. Incidentally, it shows that it is
possible
to make a language simple without crippling it.
... but efficiency. Ruby is 50 times slower than all languages,
including itself.
Andrei
Not to mention orthogonal safety. Even for a dynamically typed
scripting language Ruby sacrifices a lot of safety. Not
memory-wise but orthogonality-wise - it's design is very hackish,
and you can remove an import("require") to foo.rb from bar.rb
thus causing a bug in baz.rb that was importing bar.rb and thus
indirectly importing qux.rb because foo.rb was importing it, and
qux.rb is monkey-patching class Qux to override some method to
return a different value. Have fun trying to debug this!
Computer science is all about tradeoffs. I used to love Ruby, but
then a Rails project got out of hand... Nowadays I use it mainly
as a bash replacement - Hundredfolds more expressive, only a tiny
tiny bit syntax overhead, and for things that bash's safety would
be enough Ruby's certainly suffices.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On 3/29/15 4:43 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= " wrote: On Sunday, 29 March 2015 at 08:37:54 UTC, Idan Arye wrote: On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote: On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote: Personally, I'm not sure that much is gained in pitting Go against D precisely because they're so different that they're likely to appeal to completely different sets of people. I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby. How is Go a competitor to Ruby? I cannot think of a single parameter where Go and Ruby don't take the exact opposite approach!(other than the obvious ones like "both use require the programmer to write code") I think it's more of a competitor to Rails. Ruby as a language is as you say very different from Go. Incidentally, it shows that it is possible to make a language simple without crippling it. ... but efficiency. Ruby is 50 times slower than all languages, including itself. Andrei
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sunday, 29 March 2015 at 12:50:38 UTC, cym13 wrote: Nim seems quite interesting indeed, even if I'm not sure how well it scales. It looks like a language that is prowd of a heavy use of macros and DSL definition à la lisp. Nim is also too young to know if it stays around. However, I can't see a pythonista being excited in Dart at all, at least not for what he finds in python. More restricted in any way, no clear functional orientation possible, a clear lack Actually, there is quite a large overlap if you look beyond the syntax. Dart is completely unexciting, but I also find it very productive when used with the IDE. I don't think any language without comprehensions can attract Python programmers for real, but the recent Dart 1.9 release also have compact Pythonesque generators (iterators/ranges) as you can see on the link above so I like the direction they are taking now. Anyway, my point was more that making Python a target means you have to compete with a large set of other languages in the same vein. In the system language area you only have C++/Rust so it is an easier target. Unfortunately C++ still has a lot of advantages over other languages for real world projects, so it will remain my system level language until a better language starts polishing their low level stuff... :-/
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sunday, 29 March 2015 at 12:21:01 UTC, Ola Fosheim Grøstad wrote: On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote: Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it). There are many alternatives to Python. Like Nim or Dart: https://www.dartlang.org/articles/beyond-async/ https://www.dartlang.org/articles/await-async/ Nim seems quite interesting indeed, even if I'm not sure how well it scales. It looks like a language that is prowd of a heavy use of macros and DSL definition à la lisp. I know lisp enough to know that it's not a problem in itself, but that it should be developed wisely. It may look at first as a better alternative than D for a pure python developer, but I'll stick with D. However, I can't see a pythonista being excited in Dart at all, at least not for what he finds in python. More restricted in any way, no clear functional orientation possible, a clear lack of expressiveness... D clearely has the advantage there.
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sunday, 29 March 2015 at 02:15:38 UTC, cym13 wrote: Moreover, it is possible to reach a good expressiveness (maybe not as good as python, but that's the whole goal of python so there's no shame in not matching it). There are many alternatives to Python. Like Nim or Dart: https://www.dartlang.org/articles/beyond-async/ https://www.dartlang.org/articles/await-async/
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Sunday, 29 March 2015 at 08:37:54 UTC, Idan Arye wrote: On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote: On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote: Personally, I'm not sure that much is gained in pitting Go against D precisely because they're so different that they're likely to appeal to completely different sets of people. I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby. How is Go a competitor to Ruby? I cannot think of a single parameter where Go and Ruby don't take the exact opposite approach!(other than the obvious ones like "both use require the programmer to write code") I think it's more of a competitor to Rails. Ruby as a language is as you say very different from Go. Incidentally, it shows that it is possible to make a language simple without crippling it.
Re: GtkD 3.1.0 released, GTK+ with D.
On 03/28/2015 08:31 PM, captaindet wrote: On 2015-03-27 16:47, Mike Wey wrote: On 03/27/2015 10:27 PM, captaindet wrote: On 2015-03-26 17:41, Mike Wey wrote: GtkD is a D binding and OO wrapper of Gtk+ and is released on the LGPL license. Shortly after the last release, GtkD has been updated for GTK+ 3.16. GtkD 3.1.0 is now available on gtkd.org: http://gtkd.org/download.html great news - thanks for your efforts! there is a name conflict though. folder \srcgstreamer\gstreamer\ contains GStreamer.d and gstreamer.d this is not supported on windows machines i don't think DMD supports differentiating between them either. /det Fixed in 3.1.1. thanks a bunch! i ran into something else concerning Builder.addFromString in the 1.x versions it was uint addFromString(string buffer, gsize length) (clumsy C style) in the 2.x versions it became uint addFromString(string buffer) (D-ified, made sense) with 3.x it reverted to uint addFromString(string buffer, size_t length) (back to clumsy C style) i don't really like to change my code again and make it incompatible with 2.x versions. and i don't like the clumsy C style either. i'd appreciate if you could add an overload for the D style 2.x version call. cheers, det That change wasn't intentional, the gir files are missing the array information for this function. Fixed in: https://github.com/gtkd-developers/GtkD/commit/4ecf0e17f0951920461ec2d277c9c97d09eab94f -- Mike Wey
Re: Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"
On Saturday, 28 March 2015 at 18:47:04 UTC, Walter Bright wrote: On 3/28/2015 3:20 AM, Jonathan M Davis via Digitalmars-d-announce wrote: Personally, I'm not sure that much is gained in pitting Go against D precisely because they're so different that they're likely to appeal to completely different sets of people. I also do not regard Go as a competitor to D. It's more of a competitor to Java and Ruby. How is Go a competitor to Ruby? I cannot think of a single parameter where Go and Ruby don't take the exact opposite approach!(other than the obvious ones like "both use require the programmer to write code")
Re: Release D 2.067.0
On Sun, 29 Mar 2015 00:24:12 -0700, Walter Bright wrote: > On 3/28/2015 11:03 AM, ketmar wrote: >> sure. main D developers shown that they have no respect for other's >> work (see Andrei calling H.S.Teoh's work of splitting std.algorithm >> "useless", >> or Walter blaming me that "the project is badly designed" when it >> wasn't even my project and i didn't wrote a single line there, and have >> no understanding of codebase at all), so why should i think that my >> time is less valuable than theirs? > > > You may interpret what others say as you see fit, but when using "" or > >, please ensure that the quote is accurately verbatim. ok. "isn't well modularized and encapsulated". that surely means "badly designed" for me. signature.asc Description: PGP signature
Re: Release D 2.067.0
On 3/28/2015 11:03 AM, ketmar wrote: sure. main D developers shown that they have no respect for other's work (see Andrei calling H.S.Teoh's work of splitting std.algorithm "useless", or Walter blaming me that "the project is badly designed" when it wasn't even my project and i didn't wrote a single line there, and have no understanding of codebase at all), so why should i think that my time is less valuable than theirs? You may interpret what others say as you see fit, but when using "" or >, please ensure that the quote is accurately verbatim.
