www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dsq-1: open-source software synthesizer

reply "D. Martinez" <denis.martinez live.com> writes:
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
Mar 29 2015
next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
Mar 29 2015
parent reply "Foo" <Foo test.de> writes:
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;
Mar 29 2015
parent "Joakim" <dlang joakim.fea.st> writes:
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.
Mar 29 2015
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 29 Mar 2015 17:02:53 +0000, 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=20
conversions for numbers. it still using `to!` for other objects=20
(including floating point numbers, but this can be fixed). output strings=20
and integral numbers is enough for debug logs for me. althru it's not=20
"vanilla" D, it's still very easy to backport to D2 (actually, "sed" will=20
do). it is build on templates, so it infers attributes. most of the time=20
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 =3D 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=20
kill me! ;-)=
Mar 29 2015
prev sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Mar 29 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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=20
time to stop guiding people on every single detail, this is gone too far.=
Mar 29 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Mar 29 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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=
Mar 29 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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!
Mar 29 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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


=20
 Hey hey hey, context matters!


i'm speechless 'cause it's a great idea (let machine do it work!), but i'm=20
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! ;-)=
Mar 29 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Mar 29 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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! ;-)


=20
 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=20
it can be easily integrated in any D project (rdmd comes to mind first).=20
i don't want D building abilities, for example, but i really like to use=20
it's package management part (and get list of files and compiler flags=20
for that packages).

sure, i can do this by parsing dub jsons and execing dub itself to do=20
package management work, but libdub is better...

maybe someday i'll wrote such thing. ;-)=
Mar 29 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Mar 29 2015
parent reply =?windows-1252?Q?S=F6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
Am 30.03.2015 um 08:34 schrieb Rikki Cattermole:

 On 30/03/2015 7:26 p.m., ketmar wrote:

 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. ;-)




You can actually use DUB as a library without any issues (within the DUB 
eco system, just add it as a dependency, otherwise drop the app.d file 
when building). The API is still not ideal (missing some documentation 
and needs some cleanup), because it has grown by contribution from 
multiple people and a public API hasn't been a primary goal at the time.


 Yeah, the vibe.d/dub guys are amazing at getting stuff working. But
 horrible at abstraction's especially with library code.


Okay.
Apr 01 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 01 Apr 2015 11:28:12 +0200, S=C3=B6nke Ludwig wrote:


 You can actually use DUB as a library without any issues (within the DUB
 eco system, just add it as a dependency, otherwise drop the app.d file
 when building). The API is still not ideal (missing some documentation
 and needs some cleanup), because it has grown by contribution from
 multiple people and a public API hasn't been a primary goal at the time.


i have concerns about API stability, though. it's always better to have=20
"officially announced" library with some guarantees ("we will break API=20
on each release" is good too ;-).=
Apr 01 2015
parent =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
Am 01.04.2015 um 11:32 schrieb ketmar:

 On Wed, 01 Apr 2015 11:28:12 +0200, Sönke Ludwig wrote:


 You can actually use DUB as a library without any issues (within the DUB
 eco system, just add it as a dependency, otherwise drop the app.d file
 when building). The API is still not ideal (missing some documentation
 and needs some cleanup), because it has grown by contribution from
 multiple people and a public API hasn't been a primary goal at the time.


 i have concerns about API stability, though. it's always better to have
 "officially announced" library with some guarantees ("we will break API
 on each release" is good too ;-).


This will happen soon, when it's ready for the 1.0.0 release. It'll then 
be subject to the usual SemVer guarantees.
Apr 01 2015
prev sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 1/04/2015 10:28 p.m., Sönke Ludwig wrote:

 Am 30.03.2015 um 08:34 schrieb Rikki Cattermole:


snip


 Yeah, the vibe.d/dub guys are amazing at getting stuff working. But
 horrible at abstraction's especially with library code.


 Okay.


Nobody can be the best at everything. So it was a compliment :)
You've done an excellent job with them.
And by the looks of things, you are now splitting up e.g. vibe.d So 
again its mostly past tense observation on that front.

I'm kinda the opposite. Great at abstractions. Horrible at getting the 
damn thing working.
Apr 01 2015
parent reply =?windows-1252?Q?S=F6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
Am 01.04.2015 um 11:33 schrieb Rikki Cattermole:

 On 1/04/2015 10:28 p.m., Sönke Ludwig wrote:

 Am 30.03.2015 um 08:34 schrieb Rikki Cattermole:


 snip


 Yeah, the vibe.d/dub guys are amazing at getting stuff working. But
 horrible at abstraction's especially with library code.


 Okay.


 Nobody can be the best at everything. So it was a compliment :)
 You've done an excellent job with them.
 And by the looks of things, you are now splitting up e.g. vibe.d So
 again its mostly past tense observation on that front.

 I'm kinda the opposite. Great at abstractions. Horrible at getting the
 damn thing working.


I personally usually stay away from using overly strong terms like 
"horrible" for online conversations, because it's just far too likely 
that someone gets offended (I'm usually a fan of good irony for example, 
but almost never use it online).

On topic, I don't think that splitting up the library or not does 
necessarily have anything to do with abstraction. The library is built 
in a modular way, so that splitting it up mainly just becomes an issue 
of the build configuration. If you have other examples of where you 
think the abstractions are lacking, I'd be interested to know of course.

I generally value good abstraction as important, but that doesn't always 
mean that the most extreme abstraction is the best one. Abstraction 
comes at the cost of added complexity (on the library side, but more 
importantly on the user side) and sometimes at the cost of performance, 
so it's always a trade-off.
Apr 01 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 1/04/2015 11:07 p.m., Sönke Ludwig wrote:

 Am 01.04.2015 um 11:33 schrieb Rikki Cattermole:

 On 1/04/2015 10:28 p.m., Sönke Ludwig wrote:

 Am 30.03.2015 um 08:34 schrieb Rikki Cattermole:


 snip


 Yeah, the vibe.d/dub guys are amazing at getting stuff working. But
 horrible at abstraction's especially with library code.


 Okay.


 Nobody can be the best at everything. So it was a compliment :)
 You've done an excellent job with them.
 And by the looks of things, you are now splitting up e.g. vibe.d So
 again its mostly past tense observation on that front.

 I'm kinda the opposite. Great at abstractions. Horrible at getting the
 damn thing working.


 I personally usually stay away from using overly strong terms like
 "horrible" for online conversations, because it's just far too likely
 that someone gets offended (I'm usually a fan of good irony for example,
 but almost never use it online).


I agree, I was quite extreme. In reality we're only talking in shades of 
grey with a difference of maybe 5 (0 .. 255).

There is a reason why most people IRL think I'm a jerk. Always take 
stuff like this with a grain of salt. It's only meant to make people 
think about the subject, not as a factoid.


 On topic, I don't think that splitting up the library or not does
 necessarily have anything to do with abstraction. The library is built
 in a modular way, so that splitting it up mainly just becomes an issue
 of the build configuration. If you have other examples of where you
 think the abstractions are lacking, I'd be interested to know of course.


If I was to start doing it, Vibe.d would be next to useless. No you guys 
are doing a wonderful job. I really can't stress that enough.


 I generally value good abstraction as important, but that doesn't always
 mean that the most extreme abstraction is the best one. Abstraction
 comes at the cost of added complexity (on the library side, but more
 importantly on the user side) and sometimes at the cost of performance,
 so it's always a trade-off.


There are more types of abstractions than just classes vs interfaces. 
What goes into a module for example is a prime example of an 
abstraction. A purpose.
Apr 01 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 02 Apr 2015 00:54:52 +1300, Rikki Cattermole wrote:


 There are more types of abstractions than just classes vs interfaces.
 What goes into a module for example is a prime example of an
 abstraction. A purpose.


it's even harder, as i sometimes has troubles deciding what should go=20
into a function...=
Apr 01 2015
prev sibling parent Mathias Lang via Digitalmars-d-announce writes:
2015-04-01 13:54 GMT+02:00 Rikki Cattermole via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com>:


 There are more types of abstractions than just classes vs interfaces. What
 goes into a module for example is a prime example of an abstraction. A
 purpose.


Which also have it's problem. For example, most symbols in vibe.internal
are public. That's because we didn't have `package(identifier)` (and we
still don't have, since we're supporting 2.065).
Apr 01 2015
prev sibling parent "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Monday, 30 March 2015 at 06:26:00 UTC, 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. ;-)


+1

E.g. using libdub in my project DlangIDE would be much easy than 
command line interface.
Mar 30 2015
prev sibling parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Monday, 30 March 2015 at 05:23:18 UTC, Rikki Cattermole wrote:

 This is a primarily a french license. It took me a good while 
 to understand that it was compatible with e.g. MIT.


Compatible in what way? Isn't CeCILL a copyleft license? (It's 
not 100% obvious to me whether strong or weak copyleft is 
implied, because their definition of an 'External Module' is 
unclear: I'm not sure if something is rendered non-external by 
linking, or merely by static linking, or something else again.)
Apr 01 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 2/04/2015 8:42 a.m., Joseph Rushton Wakeling wrote:

 On Monday, 30 March 2015 at 05:23:18 UTC, Rikki Cattermole wrote:

 This is a primarily a french license. It took me a good while to
 understand that it was compatible with e.g. MIT.


 Compatible in what way? Isn't CeCILL a copyleft license? (It's not 100%
 obvious to me whether strong or weak copyleft is implied, because their
 definition of an 'External Module' is unclear: I'm not sure if something
 is rendered non-external by linking, or merely by static linking, or
 something else again.)


As far as I remember, it should just be ok. The only real issue is with 
lgpl ext.

But again, you can see why I want this clarified.
Apr 01 2015