On 05/26/2010 12:39 PM, torbenh wrote:
> On Tue, May 25, 2010 at 09:09:57PM +0200, Arnout Engelen wrote:
>> On Tue, May 25, 2010 at 07:24:20AM +0200, torbenh wrote:
This IDE with all this syntax checking and refactoring tools (and I might
call
them bells and whistles sometimes..) pr
On Tue, May 25, 2010 at 09:09:57PM +0200, Arnout Engelen wrote:
> On Tue, May 25, 2010 at 07:24:20AM +0200, torbenh wrote:
> > > This IDE with all this syntax checking and refactoring tools (and I might
> > > call
> > > them bells and whistles sometimes..) produces a real "added value".
> > >
> >
On Tue, May 25, 2010 at 07:24:20AM +0200, torbenh wrote:
> > This IDE with all this syntax checking and refactoring tools (and I might
> > call
> > them bells and whistles sometimes..) produces a real "added value".
> >
> > That makes me think that the development environment can really completel
On 05/25/2010 07:24 AM, torbenh wrote:
> On Mon, May 24, 2010 at 11:37:32PM +0200, Olivier Guilyardi wrote:
[...]
>> That makes me think that the development environment can really completely
>> change the way you perceive a language or framework. There must be something
>> to
>> do for C lovers
On Tue, May 25, 2010 at 02:04:57AM +0200, Jens M Andreasen wrote:
>
> On Sun, 2010-05-23 at 18:58 -0400, Paul Davis wrote:
> ...
> >
> > i am glad to hear, however, that you've never used longjmp/setjmp in your
> > code ,,
>
> Ah! But this would otherwise have been the perfect cue for establish
On Mon, May 24, 2010 at 11:37:32PM +0200, Olivier Guilyardi wrote:
> On 05/24/2010 08:47 PM, torbenh wrote:
> > On Mon, May 24, 2010 at 06:00:05PM +0200, Olivier Guilyardi wrote:
> >> On 05/24/2010 01:47 PM, torbenh wrote:
> >>> On Mon, May 24, 2010 at 12:36:43PM +0200, Olivier Guilyardi wrote:
>
On Sun, 2010-05-23 at 18:58 -0400, Paul Davis wrote:
...
>
> i am glad to hear, however, that you've never used longjmp/setjmp in your
> code ,,
Ah! But this would otherwise have been the perfect cue for establishing
that plain C isn't that plain and straightforwarded either. Without even
tryin
On 05/24/2010 08:47 PM, torbenh wrote:
> On Mon, May 24, 2010 at 06:00:05PM +0200, Olivier Guilyardi wrote:
>> On 05/24/2010 01:47 PM, torbenh wrote:
>>> On Mon, May 24, 2010 at 12:36:43PM +0200, Olivier Guilyardi wrote:
[...]
I agree with most of what was above.
>> I think that some day I n
On Mon, May 24, 2010 at 06:00:05PM +0200, Olivier Guilyardi wrote:
> On 05/24/2010 01:47 PM, torbenh wrote:
> > On Mon, May 24, 2010 at 12:36:43PM +0200, Olivier Guilyardi wrote:
> But maybe that, with experience and methodology, one can get as
> productive in C
> as in C++? I supp
On 05/24/2010 06:00 PM, Olivier Guilyardi wrote:
> http://insenvim.sourceforge.net/
Forget about this one, I googled too fast, it's an old and windows-only thing.
But there seem to be good stuff around:
http://www.google.fr/search?q=vim+omnicomplete
--
Olivier
On 05/24/2010 01:47 PM, torbenh wrote:
> On Mon, May 24, 2010 at 12:36:43PM +0200, Olivier Guilyardi wrote:
>
>>> then you need to manage most memory yourself again
>> Which may results in choosing a simplified memory model, and thus
>> optimization.
>>
>>> could you explain your reasons a bi
On Mon, May 24, 2010 at 02:28:03PM +0100, Chris Cannam wrote:
> On Mon, May 24, 2010 at 2:05 PM, torbenh wrote:
> > dunno. but wikipedia calls this particular style modern c++
> > http://en.wikipedia.org/wiki/Modern_C%2B%2B_Design
>
> Ah, I see. A neat trick, to give a still relatively esoteric
On Mon, May 24, 2010 at 2:05 PM, torbenh wrote:
> dunno. but wikipedia calls this particular style modern c++
> http://en.wikipedia.org/wiki/Modern_C%2B%2B_Design
Ah, I see. A neat trick, to give a still relatively esoteric idiom
such a progressive name. One can hardly say "oh no, I don't like
On Mon, May 24, 2010 at 08:28:14AM -0400, Paul Davis wrote:
> On Mon, May 24, 2010 at 5:24 AM, Chris Cannam
> wrote:
>
> >
> >
> > Reading a language is (for most projects) more important than writing
> > it. You yourself took the jackdmp code (in C++) and ported it back to
> > good old C because
On Mon, May 24, 2010 at 01:27:42PM +0100, Chris Cannam wrote:
> On Mon, May 24, 2010 at 12:18 PM, torbenh wrote:
> > classic C++ and "modern c++" are two pairs of shoes.
> > if your afraid of writing templates. modern c++ is not for you.
>
> I'm puzzled as to why templates should be considered "m
On Mon, May 24, 2010 at 5:24 AM, Chris Cannam
wrote:
>
>
> Reading a language is (for most projects) more important than writing
> it. You yourself took the jackdmp code (in C++) and ported it back to
> good old C because it was written "from the wrong school of C++" and
> you found C easier to w
On Mon, May 24, 2010 at 12:18 PM, torbenh wrote:
> classic C++ and "modern c++" are two pairs of shoes.
> if your afraid of writing templates. modern c++ is not for you.
I'm puzzled as to why templates should be considered "modern" these
days, but never mind.
My very mundane point is just that (
On Mon, May 24, 2010 at 5:12 AM, wrote:
> When they are promoting these sort of idioms, computer
> scientists often look like the proverbial 'man with a
> hammer'.
>
> These things come and go, every year has its new crop.
> After the hype has settled down, they are usually
> forgotten.
>
it see
On Sun, May 23, 2010 at 10:03:20PM -0400, Joshua D. Boyd wrote:
> On 05/23/10 16:22, Chris Cannam wrote:
> >On Sun, May 23, 2010 at 8:44 PM, Chris Cannam
> > On Sun, May 23, 2010 at 9:41 AM, torbenh wrote:
> >> but i find the equivalent c++ easier to read.
> >> assuming we have a proper modern c++
On Sun, May 23, 2010 at 10:03:20PM -0400, Joshua D. Boyd wrote:
> I think it isn't difficult to read because it is C++ or Boost. It
> is difficult to read because it involves concepts like promises and
> futures, which are advanced topics that a lot of people (myself
> included) aren't adequately
On Sun, May 23, 2010 at 06:58:42PM -0400, Paul Davis wrote:
> clearly, you've not used shared_ptr.
I'm not using them, for various reasons:
1. Looked at the documentation and decided I didn't want
this. Have you counted the number of caveats ? Just using
an unnamed shared_ptr as function argumen
On Sun, May 23, 2010 at 08:44:42PM +0100, Chris Cannam wrote:
> On Sun, May 23, 2010 at 9:41 AM, torbenh wrote:
> > but i find the equivalen c++ easier to read.
> > assuming we have a proper modern c++ osc lib:
> >
> > boost::unique_future
> > osc_recv (OscPeer peer, std::string path)
> > {
> >
On Mon, May 24, 2010 at 12:36:43PM +0200, Olivier Guilyardi wrote:
> > then you need to manage most memory yourself again
>
> Which may results in choosing a simplified memory model, and thus
> optimization.
>
> > could you explain your reasons a bit more ?
>
> First, it's not all about re
On Sun, May 23, 2010 at 10:55:48PM +0200, f...@kokkinizita.net wrote:
> On Sun, May 23, 2010 at 08:44:42PM +0100, Chris Cannam wrote:
>
> > On Sun, May 23, 2010 at 9:41 AM, torbenh wrote:
> > > but i find the equivalen c++ easier to read.
> > > assuming we have a proper modern c++ osc lib:
> > >
On 05/24/2010 10:24 AM, torbenh wrote:
> On Sun, May 23, 2010 at 11:07:27PM +0200, Olivier Guilyardi wrote:
[...]
>> I once read a great (and funny) article arguing that you simple can't assume
>> anything about what the following means in C++:
>>
>> a = b + c
>>
>> Nothing
>
> yeah. but if that
On Mon, May 24, 2010 at 10:24:17AM +0100, Chris Cannam wrote:
> On Mon, May 24, 2010 at 8:58 AM, torbenh wrote:
> > well... for me, saying c++, is saying boost. boost and modern c++ is what
> > makes c++ better than java.
> > java is a pretty great language nowadays (with generics and annotators
>
On Sun, May 23, 2010 at 11:12:22PM -0700, Niels Mayer wrote:
> On Sun, May 23, 2010 at 1:55 PM, wrote:
> >
> > I find this sort of thing absolutely beyond comprehension.
> >
> > It's impossible to understand without knowing the boost::
> > abstractions, templates and god knows what else.
> >
> > I
On Sun, May 23, 2010 at 08:44:42PM +0100, Chris Cannam wrote:
> On Sun, May 23, 2010 at 9:41 AM, torbenh wrote:
> > but i find the equivalen c++ easier to read.
> > assuming we have a proper modern c++ osc lib:
> >
> > boost::unique_future
> > osc_recv (OscPeer peer, std::string path)
> > {
> >
On Sun, May 23, 2010 at 10:53:59PM -0400, Paul Davis wrote:
> On Sun, May 23, 2010 at 10:03 PM, Joshua D. Boyd wrote:
>
> >
> > I think it isn't difficult to read because it is C++ or Boost. It is
> > difficult to read because it involves concepts like promises and futures,
> > which are advance
On Mon, May 24, 2010 at 8:58 AM, torbenh wrote:
> well... for me, saying c++, is saying boost. boost and modern c++ is what
> makes c++ better than java.
> java is a pretty great language nowadays (with generics and annotators
> and stuff). my big problem with java is that its stdlib is really a b
On Mon, May 24, 2010 at 9:30 AM, torbenh wrote:
> std::map m = { { "a", 1 }, { "b", 2 } };
Hard to resist that one, certainly.
Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio
On Mon, May 24, 2010 at 3:03 AM, Joshua D. Boyd wrote:
> I think it isn't difficult to read because it is C++ or Boost. It is
> difficult to read because it involves concepts like promises and futures,
> which are advanced topics that a lot of people (myself included) aren't
> adequately familiar
On Sun, May 23, 2010 at 11:07:27PM +0200, Olivier Guilyardi wrote:
> On 05/23/2010 10:22 PM, Chris Cannam wrote:
>
> [...]
>
> > ... by which I don't mean to imply that I can't understand it
> > (although, with C++, there is always the possibility that I _think_ I
> > can understand it but am sad
On Sun, May 23, 2010 at 1:55 PM, wrote:
>
> I find this sort of thing absolutely beyond comprehension.
>
> It's impossible to understand without knowing the boost::
> abstractions, templates and god knows what else.
>
> IMNSHO, the way any software works should be understandable by
> a) knowing th
On Sun, May 23, 2010 at 10:03 PM, Joshua D. Boyd wrote:
>
> I think it isn't difficult to read because it is C++ or Boost. It is
> difficult to read because it involves concepts like promises and futures,
> which are advanced topics that a lot of people (myself included) aren't
> adequately fami
On 05/23/10 17:14, Olivier Guilyardi wrote:
On 05/23/2010 10:22 PM, Chris Cannam wrote:
[...]
... by which I don't mean to imply that I can't understand it
(although, with C++, there is always the possibility that I _think_ I
can understand it but am sadly mistaken because of some weird shit
h
On 05/23/10 16:22, Chris Cannam wrote:
On Sun, May 23, 2010 at 8:44 PM, Chris Cannam
> On Sun, May 23, 2010 at 9:41 AM, torbenh wrote:
>> but i find the equivalent c++ easier to read.
>> assuming we have a proper modern c++ osc lib:
>>
>> boost::unique_future
>> osc_recv (OscPeer peer, std::str
On Sun, May 23, 2010 at 4:55 PM, wrote:
>
> IMNSHO, the way any software works should be understandable by
> a) knowing the language, b) reading the code, at least up to the
> point that the reader can have an good idea of the big picture,
> of data structures and control flow, only excluding app
On 05/23/2010 10:22 PM, Chris Cannam wrote:
[...]
> ... by which I don't mean to imply that I can't understand it
> (although, with C++, there is always the possibility that I _think_ I
> can understand it but am sadly mistaken because of some weird shit
> happening behind the scenes). I just me
On Sun, May 23, 2010 at 08:44:42PM +0100, Chris Cannam wrote:
> On Sun, May 23, 2010 at 9:41 AM, torbenh wrote:
> > but i find the equivalen c++ easier to read.
> > assuming we have a proper modern c++ osc lib:
> >
> > boost::unique_future
> > osc_recv (OscPeer peer, std::string path)
> > {
> >
On Sat, May 22, 2010 at 11:59 PM, Niels Mayer wrote:
> results so far... using a combination of
> vamp-plugins, groovy&apache-velocity&javascript&flash via xwiki java-based
> platform http://nielsmayer.com/ts-episode-timeline.png http://nielsmayer.com/ts-episode-evnt-anls.png
You sent me email
On Sun, May 23, 2010 at 8:44 PM, Chris Cannam
wrote:
> I have to say this combination of Boost plus Weird Stuff From The
> Future is no more readable to me (as a long-time C++ programmer) than
> the Clojure example.
... by which I don't mean to imply that I can't understand it
(although, with C++
On Sun, May 23, 2010 at 9:41 AM, torbenh wrote:
> but i find the equivalen c++ easier to read.
> assuming we have a proper modern c++ osc lib:
>
> boost::unique_future
> osc_recv (OscPeer peer, std::string path)
> {
> boost::shared_ptr< boost::promise > spromise( new
> boost::promise )
>
On Fri, May 21, 2010 at 11:42:13AM -0700, Niels Mayer wrote:
> On Fri, May 21, 2010 at 8:33 AM, torbenh wrote:
>
> and i really find bigger programs pretty confusing in dynamic languages
> > where variables arent annotated with types.
> >
>
> That's just because the programmer wasn't fastidious
On Fri, May 21, 2010 at 11:53 AM, Chris Cannam
wrote:
> I don't understand. What answers the question?
>
> Actually I'm not sure I understand the question either -- do you mean
> to ask why the block diagram algebra (which I guess was something from
> the presentation?) is being talked about when
On Fri, May 21, 2010 at 11:01:44PM +0200, Arnout Engelen wrote:
> On Fri, May 21, 2010 at 11:42:13AM -0700, Niels Mayer wrote:
> > On Fri, May 21, 2010 at 8:33 AM, torbenh wrote:
> > > On Thu, May 20, 2010 at 10:37:30AM -0700, Niels Mayer wrote:
> > > > "hard realtime" often precludes the use of G
On Fri, May 21, 2010 at 11:42:13AM -0700, Niels Mayer wrote:
> On Fri, May 21, 2010 at 8:33 AM, torbenh wrote:
> > On Thu, May 20, 2010 at 10:37:30AM -0700, Niels Mayer wrote:
> > > "hard realtime" often precludes the use of Garbage collectors. Of
> > > course Java has RT garbage collectors avail
On Fri, May 21, 2010 at 10:52 AM, Olivier Guilyardi wrote:
> On 05/20/2010 10:12 PM, Chris Cannam wrote:
>> Being a long time Vim user is probably _why_ you found it to be so efficient
>> ...
>>
>> ... now if you were an Emacs user, that'd be another matter ...
>
> Well, intellisense in QtCreator
On Fri, May 21, 2010 at 7:42 PM, Niels Mayer wrote:
> Actually, my thoughts during the faust presentation @LAC2010 indicates we
> seem to inhabit different islands each with it's own cargo-cult...
>>
>> (07:59:14 AM) npm: Q: what's the difference or motivation for this Block
>> diagram algebra and
On Fri, May 21, 2010 at 8:33 AM, torbenh wrote:
> On Thu, May 20, 2010 at 10:37:30AM -0700, Niels Mayer wrote:
> > I agree with the Qt option, as it clearly produces some nice & performant
> > music applications. But you're still programming in C++ which is tedious
> > because of memory managemen
On Thu, May 20, 2010 at 10:37:30AM -0700, Niels Mayer wrote:
> I agree with the Qt option, as it clearly produces some nice & performant
> music applications. But you're still programming in C++ which is tedious
> because of memory management; also "hard realtime" often precludes the use
> of Garba
On 05/20/2010 10:12 PM, Chris Cannam wrote:
> On Thu, May 20, 2010 at 5:30 PM, Olivier Guilyardi wrote:
>> Qt is really great. I also highly recommend that you look at Qt Creator
>> which is
>> included in the SDK. Although I'm a long time Vim user, I really found this
>> IDE
>> to be extremely
On Thu, May 20, 2010 at 06:46:16PM -0400, Paul Davis wrote:
> On Thu, May 20, 2010 at 6:18 PM, Niels Mayer wrote:
>
> > I forgot to mention one of my main finds regarding clojure -- a nice Qt
> > interface, and working well w/ multithreaded...
> >
> > http://tealeg.blogspot.com/2008/11/on-clojure
Niels was all like:
> Any dev's here implement a loosely decoupled frontend/backed like this
> before and run into issues i with it?
>
Implemented a GUI / Engine style program with OSC inbetween: Yup. C++ &
LibLO & GTKmm
Run into issues with it: Nope.
There have been some minor OSC issues, but
On Thu, May 20, 2010 at 6:18 PM, Niels Mayer wrote:
> I forgot to mention one of my main finds regarding clojure -- a nice Qt
> interface, and working well w/ multithreaded...
>
> http://tealeg.blogspot.com/2008/11/on-clojure-part-3-designer-uis-and.html
> http://briancarper.net/blog/clojure-qt4-
I forgot to mention one of my main finds regarding clojure -- a nice Qt
interface, and working well w/ multithreaded...
http://tealeg.blogspot.com/2008/11/on-clojure-part-3-designer-uis-and.html
http://briancarper.net/blog/clojure-qt4-system-tray-mail-checker
As you'd expect from Clojure, the con
On Thu, May 20, 2010 at 5:30 PM, Olivier Guilyardi wrote:
> Qt is really great. I also highly recommend that you look at Qt Creator which
> is
> included in the SDK. Although I'm a long time Vim user, I really found this
> IDE
> to be extremely simple and efficient.
Being a long time Vim user i
On Thu, 20 May 2010, Chris Cannam wrote:
When I released the Composite Sampler, I had to solve two tricky bugs:
Hang on -- I've never actually looked at Composite (sorry!) but does
this mean that it has a Qt GUI that loads in-process in GTK-based LV2
hosts?
Not yet. It doesn't have an LV2
On Thu, May 20, 2010 at 6:26 PM, Gabriel M. Beddingfield
wrote:
> On Thu, 20 May 2010, Charles Fleche wrote:
>
>>> well (e.g. if you write LV2 plugins based on Qt, as I have, you may
>>> uncover some strange bugs).
>>
>> Really ? What happened ?
>
> When I released the Composite Sampler, I had to
On 05/20/2010 08:39 PM, Nathanael Anderson wrote:
>Cons: Uses a pre-compiler for generating "signal/slot" connections,
> Several of the core classes (like QString) will spread virally through
> your code. Because it's a full framework, it sometimes doesn't mix
> well (e.g. if y
>
> Cons: Uses a pre-compiler for generating "signal/slot" connections,
> Several of the core classes (like QString) will spread virally through
> your code. Because it's a full framework, it sometimes doesn't mix
> well (e.g. if you write LV2 plugins based on Qt, as I have, you may
> uncover so
I agree with the Qt option, as it clearly produces some nice & performant
music applications. But you're still programming in C++ which is tedious
because of memory management; also "hard realtime" often precludes the use
of Garbage collectors. Of course Java has RT garbage collectors available:
ht
On Thu, 20 May 2010, Charles Fleche wrote:
well (e.g. if you write LV2 plugins based on Qt, as I have, you may
uncover some strange bugs).
Really ? What happened ?
When I released the Composite Sampler, I had to solve two
tricky bugs:
1. zynjacku's UI would freeze when loading it.
Hi Nathanael,
On 05/20/2010 01:35 PM, Nathanael Anderson wrote:
> I've written some small c/c++ programs for my own use that were alsa
> midi based. I found a very low entry barrier to getting started writing
> console apps with alsa midi. I'd like to work on something a little
> larger scale, and
> What choices do I have for tools to use, and what pro's/con's are attached
> to them. From what i've read so far qt seems like it might be a good choice,
> aside from the high entry barrier of learning how to do everything the qt
> way.
>
> I'm looking for information on any of the above.
>
>
Hey
well (e.g. if you write LV2 plugins based on Qt, as I have, you may
uncover some strange bugs).
Really ? What happened ?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Excerpts from Arnout Engelen's message of 2010-05-20 16:19:01 +0200:
> On Thu, May 20, 2010 at 08:37:07AM -0500, Gabriel Beddingfield wrote:
> > Another option is to use a scripting language (like Tcl/Tk, PyGtk, or
> > PyQt) for the GUI parts. However, when you're mixing it with your
> > core C/C+
On Thu, May 20, 2010 at 08:37:07AM -0500, Gabriel Beddingfield wrote:
> Another option is to use a scripting language (like Tcl/Tk, PyGtk, or
> PyQt) for the GUI parts. However, when you're mixing it with your
> core C/C++ parts, I find it really hard to debug these programs.
While working on jac
On Thu, May 20, 2010 at 6:35 AM, Nathanael Anderson
wrote:
> What choices do I have for tools to use, and what pro's/con's are attached
> to them. From what i've read so far qt seems like it might be a good choice,
> aside from the high entry barrier of learning how to do everything the qt
> way.
I've written some small c/c++ programs for my own use that were alsa midi
based. I found a very low entry barrier to getting started writing console
apps with alsa midi. I'd like to work on something a little larger scale,
and include jack midi with a gui to configure options, but have no idea
wher
70 matches
Mail list logo
