Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-11 Thread zmoelnig
Quoting Mathieu Bouchard <[EMAIL PROTECTED]>: > On Fri, 11 Jan 2008, IOhannes m zmoelnig wrote: > >> the only thing i can find is you demanding parent and child >> objectclasses sharing the same $0. > > no, i asked that objects share the same $0. objectclasses themselves > don't have a $0. ind

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-11 Thread Mathieu Bouchard
On Fri, 11 Jan 2008, IOhannes m zmoelnig wrote: the only thing i can find is you demanding parent and child objectclasses sharing the same $0. no, i asked that objects share the same $0. objectclasses themselves don't have a $0. i don't understand how this relates to inheritance of classes

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-11 Thread IOhannes m zmoelnig
Mathieu Bouchard wrote: > On Fri, 11 Jan 2008, IOhannes m zmoelnig wrote: > >> and i would be interested to hear ideas on how to get OOP into a >> patcher-like languages. > > Are you? then search the archives. the only thing i can find is you demanding parent and child objectclasses sharing th

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-11 Thread Mathieu Bouchard
On Fri, 11 Jan 2008, Damian Stewart wrote: and why would i want that? That's where I use macros instead. Nowadays, I even pass macros as arguments to macros. omg. bags not maintaining /your/ code ;-P go on, flame to the wall... _ _ __ ___ _ _ _

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-11 Thread Damian Stewart
teh offtopic! it veers! Mathieu Bouchard wrote: > The only kind of reason you'd use macros, is because C++ doesn't handle > function calls well. Oh, most of the time it does; but it refuses to > consider data types as being values. and why would i want that? > That's where I use macros instea

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-11 Thread Mathieu Bouchard
On Fri, 11 Jan 2008, IOhannes m zmoelnig wrote: and i would be interested to hear ideas on how to get OOP into a patcher-like languages. Are you? then search the archives. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-11 Thread Mathieu Bouchard
On Fri, 11 Jan 2008, matteo sisti sette wrote: You can convert just SOME of your functions to macros - I'm no C++ expert but I guess you can do that with very "small" functions. You'll do it in a few special cases to optimize very critical portions of code, you can't adopt it as a general progra

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-11 Thread Mathieu Bouchard
On Thu, 10 Jan 2008, Thomas Grill wrote: this is because PD maintains it's internal structures using linked lists which gives a very bad behavior with many structure items. I don't think that the use of linked lists so far has caused any significant problem. The problem lies more in things li

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-11 Thread IOhannes m zmoelnig
hi again. Chris McCormick wrote: > >>> * No strings. >> you mean, like C? > > In C I can dynamically allocate an array of chars terminated by a \0 > *with spaces* as easily as: > > char *mystring = "pants pants pants."; as you have shown, there is no string type in C. you (ab)use arrays of byt

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-11 Thread matteo sisti sette
>> Would you ever say to someone writing an application in C++: >> >> "Think about converting some of your functions to macros"??? >> >> That is just not an option. >hmm, since when are macros bad? >especially in C (not so much in C++) i could imagine situations where >i would tell somebody to "co

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-11 Thread matteo sisti sette
> It's great to use Pd for what it totally rocks at: making interesting > graphics and music, but I wouldn't encourage it to be used as a general > purpose programming language, because it simply isn't good enough at > that job. I never talked about using PD as a "general purpose" programming lang

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-11 Thread Frank Barknecht
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote: > On Fri, Jan 11, 2008 at 09:57:03AM +0100, IOhannes m zmoelnig wrote: > > Chris McCormick wrote: > > >Here are some other reasons why you might not want to use Pd to develop > > >a large scale application (and why I won't call Pd a 'pro

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-11 Thread Chris McCormick
On Fri, Jan 11, 2008 at 09:57:03AM +0100, IOhannes m zmoelnig wrote: > Chris McCormick wrote: > >Here are some other reasons why you might not want to use Pd to develop > >a large scale application (and why I won't call Pd a 'programming > >language'): > > > >* No hash/map/table type, or array type

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-11 Thread IOhannes m zmoelnig
Chris McCormick wrote: > Here are some other reasons why you might not want to use Pd to develop > a large scale application (and why I won't call Pd a 'programming > language'): > > * No hash/map/table type, or array type that holds anything except floats. data structures? > * No strings. you

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-10 Thread Chris McCormick
On Thu, Jan 10, 2008 at 02:42:12PM +0100, matteo sisti sette wrote: > Yes of course. I didn't mean to criticize your suggestion: I meant to > "criticize PD" that makes that suggestion necessary. > > Of course that IS a valid workaround in a lot of situations where the > use of abstractions is not

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-10 Thread zmoelnig
Quoting matteo sisti sette <[EMAIL PROTECTED]>: >> Otherwise, think about converting some of the abstractions to subpatches > > > Please don't interprete what I'm gonna say as sarchastic or offensive > to whom wrote the above sentence (which however has been suggested by > more than one person). J

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-10 Thread zmoelnig
Quoting matteo sisti sette <[EMAIL PROTECTED]>: > memory corruption or something: nonsense error messages such as > ".x8972383 no such object" (or something like that: can't remember > exactly), this is definitely not a "nonsense message". it tells us that there is a corruption in the communicatio

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-10 Thread Patrice Colet
I usually open the abstraction with 'help' rather than 'open', pd crashes less often when saving. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-10 Thread matteo sisti sette
> > Please don't interprete what I'm gonna say as sarchastic or offensive > > to whom wrote the above sentence (which however has been suggested by > > more than one person). Just take it as a general and (hopefully) > > constructive discussion about PD issues... > > No offense taken. But since I h

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-10 Thread Frank Barknecht
Hallo, matteo sisti sette hat gesagt: // matteo sisti sette wrote: > Using and reusing a great number of abstractions with many many levels > of nesting is the only reasonable way (I can think of) of developing a > large, complex, scalable, reusable "application" in PD. I do agree with that, but

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-10 Thread Derek Holzer
Hi Matteo, matteo sisti sette wrote: >> Otherwise, think about converting some of the abstractions to subpatches > > > Please don't interprete what I'm gonna say as sarchastic or offensive > to whom wrote the above sentence (which however has been suggested by > more than one person). Just take

[PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-10 Thread matteo sisti sette
> Otherwise, think about converting some of the abstractions to subpatches Please don't interprete what I'm gonna say as sarchastic or offensive to whom wrote the above sentence (which however has been suggested by more than one person). Just take it as a general and (hopefully) constructive disc

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-10 Thread Derek Holzer
Yes, I've had that as well. The thing to do in this situation is to make sure that all the abstractions or subpatches inside the one you are saving are closed. Having to refresh these open subpatches or sub-abstractions along with the main abstraction exponentially increases the load on PD, and

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-10 Thread matteo sisti sette
> in some patches i need to have hundreds of copies of the same > abstraction. to save just one copy of the abstraction would only take > a fraction of a second, but when i have many hundreds of copies, pd is > really stumbling to get these abstractions all renewed to the new > saved version. it

Re: [PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-10 Thread Thomas Grill
Hi, this is because PD maintains it's internal structures using linked lists which gives a very bad behavior with many structure items. It has been discussed on the list a couple of times, but there's no solution at hand. You could try to arrange your load of abstractions in subpatchers, with on

[PD] poor performance when saving an abstraction when many copies are loaded in a patch

2008-01-10 Thread hard off
something that is really slowing down my work recently: in some patches i need to have hundreds of copies of the same abstraction. to save just one copy of the abstraction would only take a fraction of a second, but when i have many hundreds of copies, pd is really stumbling to get these abstract