Personal tools
You are here: Home community IRC Chat Logs dev@irc 05/3
Document Actions

dev@irc 05/3

by IOhannes m zmoelnig last modified 2005-04-11 03:52 PM

logfile of the 3rd dev-meeting @ IRC on 01.04.2005 as found on

Apr 01 11:57:06 <Miller> Hi all.
Apr 01 11:57:25 <IOhannes> hi
Apr 01 11:57:30 --> _hc ( has joined #dataflow
Apr 01 11:57:38 <IOhannes> alx1: i think so (though i am not quite sure)
Apr 01 11:57:47 <_hc> hello everyone
Apr 01 11:58:41 <-- _hc has quit (Client Quit)
Apr 01 11:59:27 --> _hc ( has joined #dataflow
Apr 01 11:59:39 <IOhannes> back again ;-)
Apr 01 12:00:25 <Miller> wow, Iohannes is simultaneously IRC-ing and sending messages to pd-announce...
Apr 01 12:00:55 <IOhannes> in case i am repeating myself: the mailing-lists are currently migrated
Apr 01 12:01:02 <IOhannes> miller knows already ;-)
Apr 01 12:01:23 <IOhannes> if you wait a bit, you will get the same message at pd-announce again (!)
Apr 01 12:01:31 <IOhannes> i first thought it didn't make it
Apr 01 12:02:10 <Miller> migration is such sweet sorrow...
Apr 01 12:02:26 --> vitriolix ( has joined #dataflow
Apr 01 12:02:53 <IOhannes> does anybody here knows any spanish ?
Apr 01 12:02:57 <IOhannes> Esta casilla ha expirado por falta de uso.
Apr 01 12:03:03 <vitriolix> hello pd freaks
Apr 01 12:03:05 <vitriolix> not me
Apr 01 12:03:17 <mamalala> IOhannes: solamente un pocito ......
Apr 01 12:03:18 <_hc> the internet knows spanish
Apr 01 12:03:45 <matju> IOhannes: chikun/punchik speaks spanish and catalan but he's not here at the moment
Apr 01 12:03:46 <_hc> "This square has expired by lack of use."
Apr 01 12:04:01 <IOhannes> but i don't dare to ask there: they will point me to google....
Apr 01 12:04:10 <IOhannes> hc: thanks
Apr 01 12:04:18 <IOhannes> whatever square means here
Apr 01 12:04:26 <matju> Miller: what do you think of my last local-symbol proposal ?
Apr 01 12:04:38 <_hc> yeah... the internet doesn't speak spanish so well ;)
Apr 01 12:04:39 <mamalala> IOhannes: maybe "place" or "account"
Apr 01 12:04:49 <IOhannes> i guess so
Apr 01 12:05:07 <IOhannes> malala: your email was undeliverable
Apr 01 12:05:14 <IOhannes> i mean, your address failed
Apr 01 12:05:27 <mamalala> IOhannes: hu ?
Apr 01 12:05:57 --> bbogart ( has joined #dataflow
Apr 01 12:06:05 <mamalala> IOhannes: right now i got the mail "Re: [PD] with -nogui" from Pall Thayer ....
Apr 01 12:06:17 <mamalala> IOhannes: so, my mail definitly works !
Apr 01 12:06:25 <IOhannes> mamalala: it was the pd-announce that bounced
Apr 01 12:06:35 <mamalala> IOhannes: hmmm ....
Apr 01 12:07:05 <IOhannes> is ck AT mamalala DOT de you ?
Apr 01 12:07:18 <mamalala> IOhannes: yeah, the last pd-announce mail i have is from 29.07.2004 ....
Apr 01 12:07:22 <mamalala> IOhannes: yes, that i am ....
Apr 01 12:07:42 --> dpro (~x@ has joined #dataflow
Apr 01 12:07:45 <Miller> matju: (sorry, was off getting more caffiene)... let me go back and reread it, I haven't thought carefully about it yet.
Apr 01 12:07:47 <IOhannes> so feel free to change your address if youfind the time...
Apr 01 12:08:07 <mamalala> IOhannes: ?
Apr 01 12:08:41 <IOhannes> i mean, is ck still valid ? or do you have another (more recent) address ?
Apr 01 12:08:52 <mamalala> IOhannes: yes, it is valid....
Apr 01 12:09:24 <IOhannes> weird...
Apr 01 12:09:34 <mamalala> IOhannes: in fact, thats my roiginal mail address, so i dont know what to change as you suggested ?
Apr 01 12:10:09 <mamalala> IOhannes: even worse, why do you get answers in spanish concerning my bouncing mail ? my mail is (physically)
Apr 01 12:10:26 <mamalala> IOhannes: and that is in austria, as you might know (from dpro)
Apr 01 12:12:04 <IOhannes> no, the spanish answer was something different
Apr 01 12:12:13 <mamalala> ah, ok ....
Apr 01 12:12:24 <IOhannes> anyhow, i don't want to fill the logs with talk about unroutable email-addresses....
Apr 01 12:12:30 <mamalala> right !
Apr 01 12:12:49 <IOhannes> i see that we have started 15 minutes ago
Apr 01 12:12:52 <Miller> Matju: maybe it's not the _symbols_ that should be localizable, but their _bindings_ (x->thing field).
Apr 01 12:13:32 <matju> Miller: it's what i'm saying in the proposal, actually.
Apr 01 12:13:53 <matju> Miller: the last one i mean, a few days ago, not the older one that made no sense.
Apr 01 12:14:24 <matju> Miller: the one that says we need to distinguish symbols from pointers-to-variables
Apr 01 12:14:34 <Miller> Oh... I'm probably reading the wrong e-mail... I've got "The new way I am now proposing (for the first time) would introduce a new
Apr 01 12:14:34 <Miller> atom type"...
Apr 01 12:14:54 <Miller> (?) was there a more verbose explanation elsewhere?
Apr 01 12:15:57 <Miller> I _think_ the way most languages deal with local symbol bindings os to maintain binding tables separately from the symbols themselves.
Apr 01 12:16:31 <matju> Miller: the mail is timestamped Date: Mon, 28 Mar 2005 00:15:42 -0500 (EST)
Apr 01 12:17:22 <Miller> So a particular context then has to have a hash table so that symbols can be looked up context-dependently.
Apr 01 12:17:43 --> gige ( has joined #dataflow
Apr 01 12:17:47 <Miller> (yep, March 28, subject re: symbol tables)
Apr 01 12:17:58 * IOhannes greets g?nter
Apr 01 12:17:59 <gige> hi
Apr 01 12:18:03 <matju> Miller: yeah, as i said long ago, the way pd does it right now was the way it was in 60's lisp, and then it changed completely during the 70's
Apr 01 12:18:24 <Miller> Matju: that sounds plausible!
Apr 01 12:18:30 <Miller> Guenter: hi!
Apr 01 12:19:53 <Miller> Now I'm trying to think of a way to do it without having to build hash lists everywhere.
Apr 01 12:20:40 <Miller> (after all there's a reason nobody tries to make real-time systems in Lisp...)
Apr 01 12:22:24 <gige> ah, I see we're in the symbol table discussion
Apr 01 12:22:33 <matju> Miller: what do you mean "hash lists"? is this the same as hash tables ?
Apr 01 12:23:01 <Miller> yeak. I think hash tables is the right term now (I studied computer science briefly in the 70s and gave up on it).
Apr 01 12:25:54 <matju> Miller: although hashtables have a bad worst-time, it takes either takes bad luck or bad coding to find those worst cases
Apr 01 12:26:36 <Miller> yeah. I specialize in the 'bad coding' fork :)
Apr 01 12:27:05 <matju> Miller: by bad coding i specifically mean nonbalanced hashfunctions
Apr 01 12:27:11 <Miller> ... but more seriously, I think the difficulty is in building them quickly.
Apr 01 12:27:39 <bbogart> I'm floating on #pd-doc if anyone is interested in continuing to discuss PD documentations, doc/ structure help menu and package structure.
Apr 01 12:27:44 <matju> Miller: when do you need to build a hashtable quickly?
Apr 01 12:28:10 <Miller> Hmm... maybe when Thomas Grill tries to load a patch while sound is coming out...
Apr 01 12:28:37 <Miller> If the symbol context is unique to a patch, perhaps this isn't a problem.
Apr 01 12:28:59 <matju> Miller: i think that's all called "premature optimisation" and Thomas's problem is elsewhere
Apr 01 12:29:55 <gige> who has actually problems with the symbol tables, and how do they show ?
Apr 01 12:30:32 <gige> I mean, I don't do big patches nowadays and I its hard to get to the limits of modern computers.
Apr 01 12:30:42 <tim> well, i think, allocating a hash table of maybe 1024 entries is not that slow ... there are externals, that allocate more memory when loading on the fly ... and adding symbols to an empty hash table shouldn't be a speed problem ...
Apr 01 12:30:59 <Miller> gige: I think people find it heavy to have to prepend $0 to everything so abstractios don't cross-talk.
Apr 01 12:31:02 <matju> Miller: besides, there's an O(1)-time way to have resizable hashtables.
Apr 01 12:31:29 <Miller> matju: really... and still with O(1) searching???
Apr 01 12:31:44 <Miller> (I think the only way to build it O(1) is to make a tree structure)
Apr 01 12:32:57 <tim> gige: i once did a benchmark for my performance patch ... 20000 symbols .... i think i had 3000 symbols just with pd and externals (without loading my performance patch)
Apr 01 12:32:59 <matju> Miller: yeah, O(1) searching. but it's more complicated. you have to spread a O(n)-job of resizing over time, slowly migrating the small hashtable to the bigger one... takes more RAM, etc
Apr 01 12:33:39 <Miller> On the other hand, maybe string-to-symbol lookup is already a time sink.
Apr 01 12:34:10 <matju> Miller: have you measured with a profiler ?
Apr 01 12:34:16 <Miller> I mean, if Tim has 20000 symbols, each of them must be getting looked up a few times.
Apr 01 12:34:18 <IOhannes> matju: whats _more_ RAM ? can this possibly be an issue ?
Apr 01 12:34:30 <Miller> (and no, last time I used a profiler was 10 years ago...)
Apr 01 12:35:02 <IOhannes> and i think bryan easily exceeds 20000 symbols
Apr 01 12:35:29 <gige> .. trying to understand where all these symbols come from
Apr 01 12:35:56 <gige> (well, unless you misuse ..)
Apr 01 12:36:08 <Miller> If gensym() is eating a lot of compute time in "real" patches, perhaps it's enough just to rebuild the symbol hash table when loading uge patches.
Apr 01 12:36:11 <IOhannes> just load pd and Gem and you should be by ~1000
Apr 01 12:36:27 <matju> IOhannes: not more than twice fortunately
Apr 01 12:36:28 <dpro> gige: I've done a couple of dynamic patches that I personally don't use that hardcore but it could easily be done (though I'd probably try a different approach then)
Apr 01 12:36:54 <IOhannes> matju: so i guess we can accept this
Apr 01 12:37:56 <IOhannes> dpro: when dealing with (e.g.) 1000 oscillators there are hardly options to using $1-variables to talk to those objects indpendently
Apr 01 12:38:04 <matju> but really, i don't like that kind of solution for symbols. i'd rather have pointers-to-vars and strings
Apr 01 12:38:17 <IOhannes> i mean, [route] will soon get you into clicks
Apr 01 12:38:25 <gige> maybe we should figure out why we have to create so many symbols, and if there is another solution to that problem, like the polyphony thing.
Apr 01 12:38:29 <matju> and there's a way to make pointers-to-vars not use symbols after creation, too
Apr 01 12:38:58 <dpro> iohannes: right
Apr 01 12:40:04 <gige> iohannes: and thats the problem, that there is no other option, IMO
Apr 01 12:40:39 <Miller> So maybe this is related to another problem in Pd, which is that it's inconvenient to have to send everything around in messages in some situations.
Apr 01 12:41:08 <Miller> For instance, if you want to get a return value from someone, you have to send it a message with a receive name (or something similar)
Apr 01 12:41:42 <Miller> ... and yes, perhaps a 'pointer' of some sort would be more apropriate.
Apr 01 12:41:51 <dpro> miller: still one can already use tables for that if you manage to pass tablenames around
Apr 01 12:42:25 <Miller> dpro: yes, the trouble is that this is what's making people use tens of thousands of symbols.
Apr 01 12:42:34 <Miller> (unless I'm mistaken!)
Apr 01 12:42:54 <IOhannes> but with tables you don't need 1000s of symbols (unlike [value])
Apr 01 12:43:20 <dpro> miller: yup or using large tables it feels a bit like coding assembly inside pd ;)
Apr 01 12:43:21 <IOhannes> but i don't want to keep anyone from inventing a better wheel
Apr 01 12:44:17 <Miller> Oh, I misunderstood. Yep, assembly programming it is.
Apr 01 12:44:58 <Miller> But on the other hand, what if you shared a huge 'struct' so you could use field names?
Apr 01 12:45:39 <Miller> You'd want to be able to attach an instance of a 'struct' to a symbol (using a 'datum' object parallel to 'table').
Apr 01 12:46:15 <Miller> Of course, that would mean everyone wanting to optimize a huge, deep patch would have to learn how to use 'structs' and 'pointers'...
Apr 01 12:47:30 <bbogart> I still have not gotten my head around them yet!
Apr 01 12:47:58 <Miller> Anyway, I think the 'pointer' object should be expanded to act more like Krzysztof's 'xeq'.
Apr 01 12:49:22 --> rdz ( has joined #dataflow
Apr 01 12:50:01 <matju> Miller: for return-values, gpointers seem appropriate, no?
Apr 01 12:50:27 <matju> Miller: (sorry, coffee time too)
Apr 01 12:50:37 <matju> Miller: what's supposed to be the pointee-type of a gpointer anyway? t_pd *, or t_gobj * ?
Apr 01 12:50:42 <Miller> matju: perhaps so...
Apr 01 12:50:53 * dpro pours himself another cup of tea
Apr 01 12:51:13 <Miller> I think it can point to any t_gobj *.
Apr 01 12:51:52 <Miller> (I've only used it for 'data' objects so far though. And I think that most of the things you can do with the 'pointer', etc., objects only work fr 'data'.
Apr 01 12:51:56 <Miller> )
Apr 01 12:52:55 <Miller> It's funny to think about writing a 'grab' object that somehow 'aliases' itself to a variable object.
Apr 01 12:53:03 <IOhannes> and then Gem is based on t_gpointer too
Apr 01 12:54:26 <matju> IOhannes: does it use t_gpointer for pointing to t_gobj's, or to point to something else?
Apr 01 12:54:27 <Miller> iohannes: wow, I didn't know that... i'd better not make any profound changes to it then.
Apr 01 12:55:16 <-- rdz has quit ("Leaving")
Apr 01 12:56:25 <IOhannes> matju: of course it points somewhere else
Apr 01 12:56:56 --> rdz ( has joined #dataflow
Apr 01 12:57:07 <IOhannes> miller: it is just used as a pointer to somewhere; so i guess not much harm can be done if the type would change
Apr 01 12:57:38 <IOhannes> i mean, it's a dirty recasting from (t_gpointer) to (...) (let me see)
Apr 01 12:57:41 <matju> IOhannes: ok... GridFlow 0.8 also does that nowadays, but i think i don't like the solution... because gpointers are not supposed to be any kind of pointer... but i still use them like that because it's "less worse" than using floats
Apr 01 12:58:13 <Miller> Oh, so now I gather that gpointers are getting popular!
Apr 01 12:58:27 <matju> Miller: yes, they are getting popular, but for the wrong reason.
Apr 01 12:58:50 * IOhannes has seen that (t_gpointer) is cast to (GemState*) and (GemChache*) [whatever this is)
Apr 01 12:59:02 <Miller> Yes, if indeed they're not pointing to at least a t_pd so people can check them.
Apr 01 12:59:08 --> timblech ( has joined #dataflow
Apr 01 12:59:19 <-- tim has quit ("Leaving")
Apr 01 12:59:24 <Miller> Also, if they're to be persistent, they'd better point to a t_gobj so the stale-pointer protection can work.
Apr 01 12:59:34 <Miller> Tim: hi.
Apr 01 12:59:53 <timblech> Miller, just switched to another machine ...
Apr 01 13:00:07 <matju> Miller: what's the stale-pointer protection ?
Apr 01 13:00:21 <IOhannes> yes, but i think there is an (obvious) need for a type that points somewhere (void*, but of course stale-pointer-protection is fine)
Apr 01 13:00:37 <IOhannes> at least what i think that spp is ....
Apr 01 13:01:01 <Miller> And oops. In answering Matju's question, I think I'm remembering that gpointers
Apr 01 13:01:15 <Miller> can't just point to any g_obj, but are paired with 'gstub' objects that do
Apr 01 13:01:18 <Miller> the actual pointing.
Apr 01 13:01:43 <Miller> The idea is that the 'gstub' maintains a cpoint of all the gpointer copies that point through it.
Apr 01 13:02:35 <matju> Miller: ... so that the gstub can erase all stalepointers when selfdestructing ?
Apr 01 13:02:41 <Miller> (sorry, a _count_.) Then when the thing pointed to goes away, its container
Apr 01 13:02:58 <Miller> (the canvas object for instance) invalidates the gstub.
Apr 01 13:03:34 <Miller> So the idea is, any canvas or other container maintains a gstub for pointing into objects in the container.
Apr 01 13:03:42 <matju> Miller: oh, just a count. this is called reference-counting, but for a moment i thought it was something else
Apr 01 13:04:14 <Miller> Yes, sorry, a refcount. The trick is the 'gpointer' has the actual pointer
Apr 01 13:04:46 <Miller> to the t_gobj, but it checkes the count in the gstub to make sure nothing in the container has gone stale.
Apr 01 13:05:10 <Miller> (So if ANY object in a canvas is deleted, all pointers to any other object in the canvas are marked stale.)
Apr 01 13:05:21 <matju> ouch
Apr 01 13:05:40 <Miller> Yep. That's why there's no 'delete' to go with the 'append' object!
Apr 01 13:06:15 <matju> why not do reference-counting like other languages (perl/python) do ?
Apr 01 13:06:40 <Miller> I'm still thinking about that... problem is, every gobj in the world would have to have a refcount.
Apr 01 13:06:59 <Miller> (Or else you'd have to make another hashtable setup.)
Apr 01 13:07:35 <matju> what's the problem with having every t_gobj have a refcount?
Apr 01 13:07:42 <matju> apart from binary compatibility...
Apr 01 13:07:46 <dpro> hmmm and most gc implementations aren't exactly rt friendly are they ?
Apr 01 13:08:07 <matju> dpro: most...
Apr 01 13:08:30 <Miller> I think that's the root problem... I'd have to design a real-time GC system.
Apr 01 13:08:41 <Miller> (And I stopped studying CS in the 70s.)
Apr 01 13:08:46 <dpro> hehe
Apr 01 13:09:10 <matju> Miller: why do you need a GC ? (i suppose by "GC" you mean marksweep)
Apr 01 13:09:50 <Miller> Hmm, maybe I don't really. I'd need something persistent for each t_gobj
Apr 01 13:10:02 <Miller> so that things can wait for refcounts to hit zero before vanishing.
Apr 01 13:10:27 <Miller> A t_gobj purgatory.
Apr 01 13:10:56 <matju> dpro: i think that to be rt-friendly, a GC has to be notified about every pointer-change, so that it can cut a gc-run in several pieces while keeping on working correctly
Apr 01 13:11:46 --> tigital ( has joined #dataflow
Apr 01 13:11:50 <matju> dpro: ... and if a refcount mechanism is already in place, then the INCREF part can be recycled as the change-notifier,
Apr 01 13:12:23 <matju> dpro: and DECREF too, I guess.
Apr 01 13:12:39 <matju> dpro: but i am not an expert in marksweep
Apr 01 13:12:45 <IOhannes> hi jamie
Apr 01 13:12:59 <tigital> hi IO
Apr 01 13:13:05 <matju> dpro: else i'd have rewritten Ruby's GC and published my own RT-Ruby already =)
Apr 01 13:13:49 <dpro> matju: neither am I but what you just said sounds good to me :)
Apr 01 13:14:41 <dpro> matju: drop me a line when you're finished - then I'll definitely give ruby another shot
Apr 01 13:15:03 <Miller> This is interesting, that making a real refcount mechanism and getting notified on data changes migt be the same thing.
Apr 01 13:15:25 <dpro> matju: but AFAIK even in supercollider the language/GC side isn't totally realtime friendly - it's fast but there are no guarantees
Apr 01 13:17:07 <gige> ah, finally theres something I can follow ...
Apr 01 13:17:27 <gige> the trick for supercollider is that it doesn't need to be realtime
Apr 01 13:18:25 <gige> the problem with the server/client approach is synchronization
Apr 01 13:18:49 <Miller> Sorry, we're up in the clouds, aren't we?
Apr 01 13:18:57 <gige> oh, sorry ...
Apr 01 13:19:01 <Miller> Anyhow, this might be related to another idea.
Apr 01 13:19:15 <IOhannes> raining back to earth: something very different:
Apr 01 13:19:34 <IOhannes> pd-cvs-admins: is it ok for you if i add jamie to the write-list of gem2pdp ?
Apr 01 13:19:50 <Miller> I've wanted for years to have a way that a patch could 'listen in' on data and get notified when things are changed.
Apr 01 13:19:54 <matju> dpro: my solution is to just wait a few more years, so that computers get faster, so that Ruby GC latency drops by a large %. it's by far the easiest way. and it's the consumer's way. but i repeat myself.
Apr 01 13:20:15 <Miller> (or even when they don't change, for instance, when you click on a datum in a patch.
Apr 01 13:20:57 <Miller> Matju: it's comic, that computers have got faster since the 70s but doing things with them always seems to take longer and longer.
Apr 01 13:21:14 <matju> Miller: in the IMPD paper i talked about the Observer/Observable pattern, which i never implemented.
Apr 01 13:21:31 <matju> Miller: speed of software halves every 18 months.
Apr 01 13:22:37 <gige> Im just running the python script for PDa, 1 gig is the recommended minimum for memory
Apr 01 13:22:53 <_hc> IO: you'll have to ask Yves on that one, its his code and he requested that ACl
Apr 01 13:22:57 <_hc> ACL
Apr 01 13:23:04 <Miller> Yeah. Anyway, I'll look at the Observer thing..
Apr 01 13:23:18 <IOhannes> _hc: i have talked to yves last week (he was in graz)
Apr 01 13:23:20 <matju> Miller: also, using symbols the way pd people do, back in the 70's, was something you could get shot for.
Apr 01 13:23:45 <Miller> yeah, the only reason I'm alive is that I stayed away from those folks.
Apr 01 13:23:59 <_hc> IOhannes: yeah, I have no problem with that
Apr 01 13:24:14 <_hc> IOhannes: its all yves
Apr 01 13:25:07 <IOhannes> _hc: fine, i'll do it then....
Apr 01 13:25:23 <matju> Miller: Observer is a really easy concept, it's just that it has to enter people's mind as a feature that is expected, whereas currently i only would get weird glances about it.
Apr 01 13:25:48 <tigital> _hc: the commit would require a change in building pd on the osx side (ie. loading modules/externals)
Apr 01 13:26:29 <IOhannes> tigital: ?
Apr 01 13:26:51 <Miller> matju: doesn't sound wierd to me at all. But then...
Apr 01 13:27:02 <matju> Miller: yeah, but staying away from those folks doesn't solve everyone's big glorified memory leaks.
Apr 01 13:27:37 <tigital> IOhannes: well, as it is now, on osx we can't use externals like pdp2gem/gem2pdp, because each external is loaded with a "private" namespace
Apr 01 13:27:51 <IOhannes> ah i see
Apr 01 13:27:55 <Miller> It's true. Say, maybe there's a theorem that you can either have O(1) behavior, or (leakless memory use) but never both in genreal.
Apr 01 13:28:19 <IOhannes> _hc: just before i do something stupid: can i have multiple lines of "avail" ?
Apr 01 13:28:20 <tigital> IO: this prevents externals from using code in other this case, pdp2gem needs to access the gempixutils color conversions
Apr 01 13:28:47 <tigital> IO: but there is a work around patch that I put up on cvs
Apr 01 13:29:35 <tigital> IO: however, it seems to require some externals to be built with -two_level_namespace instead of -flat_namespace
Apr 01 13:30:06 <IOhannes> _hc: i mean, like "unavail| | externals/gem2pdp,externals/pidip \n avail|sevyves|externals/gem2pdp,externals/pidip \n avail|tigital|externals/gem2pdp" ??
Apr 01 13:30:13 <_hc> tigital: the gem2pdp commit? do you mean just building that object, or the whole thing
Apr 01 13:30:14 <matju> Miller: i think there might be a theorem that you can have both O(1) and leakless memory use, but no-one bothers to prove it because they prefer to implement the damn system
Apr 01 13:30:20 <gige> tigital: which externals ?
Apr 01 13:30:20 <Miller> matju: so far, anyhow, I've thought since the 80s that the symbol table was a good place to have the inevitible memory leak.
Apr 01 13:30:30 <IOhannes> _hc: or will this break the ACL ?
Apr 01 13:30:40 <Miller> (that's a very wierd idea, I know.)
Apr 01 13:30:45 <_hc> IOhannes: I am not positive, but I know that the avail stuff is pretty basic, so I'd keep it on one long line
Apr 01 13:30:46 <tigital> _hc: I just explained
Apr 01 13:30:57 <IOhannes> gige: most probably Gem and gem2pdp
Apr 01 13:31:17 <_hc> tigital: ah, sorry
Apr 01 13:31:21 <tigital> gige: so far I've only had to change the compile for mixed externals
Apr 01 13:31:32 <matju> Miller: if there is a continuous leak in the symbol-table, and the symbol-table is not resized, then you don't have a O(1)-access symbol-table anymore, you have a O(n) instead (!)
Apr 01 13:31:43 <IOhannes> _hc: so i'll split it into a section for pidip&unauthorized and a section for gem2pdp
Apr 01 13:31:46 <Miller> matju: yes, and everyone I've heard claim they could do it were just a few months away from getting it to work in every case.
Apr 01 13:31:54 <matju> Miller: and so my conclusion is that the only way to get O(1) behaviour is to have a resizable symbol-table
Apr 01 13:31:55 <gige> tigital: you know why ?
Apr 01 13:32:16 <_hc> IOhannes: sounds like a lpan
Apr 01 13:32:26 <_hc> IOhannes: plan
Apr 01 13:32:27 <Miller> matju: That's probably right.
Apr 01 13:32:30 <tigital> gige: why I had to change the mixed namespace, or why this whole thing is necessary?
Apr 01 13:32:58 <gige> tigital: why it needs the recompile of some externals and others not, mainly
Apr 01 13:33:31 <tigital> gige: it seems that mixed has multiple externals that use the same named functions
Apr 01 13:33:51 <Miller> matju: so this is stupid, but why not just have a startup flag to set the size of the symbol hashtable?
Apr 01 13:34:03 <_hc> tigital: just changing that build flag seems pretty basic to me, do you know of any reprocussions?
Apr 01 13:34:17 <matju> Miller: ... but then, as i said earlier today, the way to get that O(1) to be a worst-case upper-bound (instead of the usual amortised O(1)) is somewhat contorted...
Apr 01 13:34:21 <gige> tigital: are these declared static ?
Apr 01 13:34:34 <tigital> gige: so by compiling with two_level_namespace, the functions are "hidden" inside the external
Apr 01 13:34:43 <tigital> gige: good question...I think so
Apr 01 13:34:46 <matju> Miller: how do you specify "infinite" as a size?
Apr 01 13:34:53 <matju> Miller: ;-)
Apr 01 13:35:20 <tigital> _hc: I haven't seen any repercussions yet, but i haven't recomplied everything
Apr 01 13:35:41 <Miller> matju: well, let's just double the size of the symbol hashtable every 18 months. That's the same thing as an infinitely large one.
Apr 01 13:35:56 <tigital> _hc: it may be that we just switch everything to -two_level_namespace, with the patch for s_loader.c, also
Apr 01 13:36:05 <gige> tigital: might be worth to check for the static thing, the compilation solution seems to be a bit dangerous
Apr 01 13:36:22 <matju> Miller: that's a very constructivist way to look at it...
Apr 01 13:36:50 <Miller> matju: aha, I was wondering if there was a name for that kind of attitude.
Apr 01 13:36:54 <matju> Miller: (if you happen to have heard about mathematical-constructivism)
Apr 01 13:37:04 <_hc> tigital: that sounds like a sweeping change, and it'd need to get well tested...
Apr 01 13:37:18 <Miller> matju: yeah. And in some ways it's a good thing.
Apr 01 13:37:47 <matju> Miller: in short it's, an infinite set is just a very big finite set that you grow when you need it.
Apr 01 13:38:03 <IOhannes> tigital: i hereby name you an official developer of gem2pdp
Apr 01 13:38:19 <tigital> IO: yippee!
Apr 01 13:38:26 <Miller> Yep, or to put it another way, nothing really matters until you're looking at it.
Apr 01 13:38:34 <matju> Miller: yeah, i tend to have seriously constructivist attitudes, and claim once in a while that "noncountable sets don't exist" and especially "the set of real numbers doesn't exist"
Apr 01 13:38:45 <IOhannes> tigital: which is 3? stempelmarken
Apr 01 13:39:12 <tigital> _hc: try it, then...-two_level_namespace is the default linking method on OSX
Apr 01 13:39:18 * dpro pats tigital's shoulder
Apr 01 13:39:22 <tigital> IO: ?
Apr 01 13:39:24 <dpro> tigital: congratulations
Apr 01 13:39:39 <tigital> dpro: thnx, for ...?
Apr 01 13:39:58 <_hc> tigital: I'll try it soon, I am planning on a big Pd coding session soon
Apr 01 13:40:16 <Miller> matju: correct. There's just the set of floating-point numbers, 32 or 64 bits.
Apr 01 13:40:18 <dpro> tigital: for your promotion
Apr 01 13:40:24 <IOhannes> tigital: stempelmarken are something very austrian; you have to pay for getting a sheet of paper that tells you that you have to pay more
Apr 01 13:40:28 <tigital> dpro: heheeh
Apr 01 13:40:32 <matju> Miller: "nothing really matters until you're looking at it" sounds also a lot like quantum mechanics theory (but not that much)
Apr 01 13:40:51 <tigital> IO: uh, IOU?
Apr 01 13:41:12 <Miller> Yeah. quantum theory is the opposite: "it might have been there, but gee, now that you're looking at it, that changed it."
Apr 01 13:41:24 <matju> Miller: even with variable-precision floats you can't reach all "real" numbers
Apr 01 13:41:33 <dpro> tigita: no official stamps you had to buy and stick on official papers otherwise the buerocrats won't stamp it
Apr 01 13:41:42 <matju> Miller: all you get is a lot of fractions with power-of-two denominators
Apr 01 13:41:45 <Miller> correct. But we digress...
Apr 01 13:41:50 <matju> Miller: yeah.
Apr 01 13:43:04 <Miller> BTW, I'm trying to finish up chapter 9 right now, then want to go back to working on the next "featurs" for Pd. Probably will want to do stuff that won't hurt anyone, like trying to improve the 'struct' system.
Apr 01 13:43:06 <bbogart> anyone done any thinking about the documentation/menu/external help search stuff?
Apr 01 13:43:57 <_hc> bbogart: I need to make a 'pitstop' then I'll be ready to chat about that, brb
Apr 01 13:44:19 <bbogart> hc:okie
Apr 01 13:45:08 <Miller> Ben: I haven't thought about it, but I think a good starting point is to make "help" searches parallel library searches better somehow.
Apr 01 13:45:13 <matju> Miller: what if i implement the changes i want in t_atom and i send all of that to you when it's done?... i mean pointers-to-vars and strings
Apr 01 13:45:40 <matju> Miller: btw, can a gpointer point to a table ? (is a table a t_gobj ?)
Apr 01 13:46:01 <Miller> matju: I'm afraid of adding types to 'atom' for compatibility reasons...
Apr 01 13:46:16 <matju> Miller: compatibility with what?
Apr 01 13:46:24 <bbogart> miller: ""help" searches parallel library searches better" huh?!
Apr 01 13:46:38 <Miller> matju: I think a gpointer can point to an element in a table, but not the table itself.
Apr 01 13:48:07 <matju> Miller: ok, so that means that anonymous tables are simply not possible? (i mean tables not in the symbol-table...)
Apr 01 13:48:35 <Miller> I mean, for instance (and I don't remember the details we discussed last time, sorry) that if people's externs, abstractions, etc., had help files in a simply related place to the objects themselves, it would be easy to find them all and organize the help facility.
Apr 01 13:49:08 <bbogart> Miller: ah yes, I think this is a good idea.
Apr 01 13:49:15 <Miller> matju: tables can either be 'named' ones (the table object, e.g.) or else they can be slots in a data structure somewhere.
Apr 01 13:49:33 <-- gige ( has left #dataflow ("Leaving")
Apr 01 13:49:41 <Miller> matju: (btw, I think a better name is 'arrays')
Apr 01 13:49:48 --> gige ( has joined #dataflow
Apr 01 13:50:14 <matju> Miller: what's wrong with "table" ?
Apr 01 13:50:15 <IOhannes> hi gige
Apr 01 13:50:19 <_hc> ok, I am back and ready to get to it
Apr 01 13:50:43 <IOhannes> to what ?
Apr 01 13:50:55 <bbogart> Hey HC: did you see Miller's message above? about help files being next to libs/externals/abstractions?
Apr 01 13:51:03 <Miller> matju: I can't remember but I think there was some confusion in the past abut that.
Apr 01 13:51:03 <gige> uh, oh, seems that I have to leave. I wanted to talk about other things like the bug tracker, ..
Apr 01 13:51:07 <matju> Miller: i get it, table is a french word. arrays are the freedom tables.
Apr 01 13:51:11 <_hc> "bbogart: anyone done any thinking about the documentation/menu/external help search stuff?"
Apr 01 13:51:27 <_hc> bbogart: yes
Apr 01 13:52:03 <Miller> gige: I don't visit it often enough but it's very useful!
Apr 01 13:52:08 <matju> Miller: the confusion i've witnessed is that there are two names for the same thing and that it's not obvious which one is GOP and which one is not.
Apr 01 13:53:27 <Miller> matju: I think that's it... 'table' maybe should be the object, which is one of THREE ways to instantiate an 'array' (the others being, 1. the kind you get from the menu, and 2. sticking one in a data structure.
Apr 01 13:53:47 <matju> Miller: i ask again, what are the compatibility reasons preventing the modification of t_atom ?
Apr 01 13:53:50 <_hc> miller: about the help files, that makes a lot of sense, did you have a specific idea of how to organize it?
Apr 01 13:53:58 <gige> .. well just wanted to remember that there is a bug tracker, would be good if we would all use it. Hope to meet you all again soon.
Apr 01 13:54:03 <gige> bye
Apr 01 13:54:04 <Miller> In some sense there are two terminal objects: a table, and a datum, which should be more parallel
Apr 01 13:54:13 <IOhannes> bye g?nther
Apr 01 13:54:31 <dpro> gige: cu
Apr 01 13:54:41 <_hc> gige: see ya, long live the bug tracker!
Apr 01 13:54:45 <Miller> Anyhow, what I worry about is everyone having to upgrade anything that looks through lists of atoms to add the new atom types.
Apr 01 13:54:49 <-- gige has quit ("Leaving")
Apr 01 13:55:04 <dpro> hc: then again we all wish we wouldn't need any such thing ;)
Apr 01 13:55:50 <matju> Miller: is there code looking directly at ->a_type ?
Apr 01 13:56:17 <dpro> miller: would that really be necessary ? like in a switch there's always the default: dont_do_anything() right ?
Apr 01 13:56:23 <IOhannes> matju: yes mine
Apr 01 13:56:45 <matju> IOhannes: actually gridflow/bridge/puredata.c does too =)
Apr 01 13:56:53 <matju> a better question:
Apr 01 13:56:55 <dpro> matju: hehe
Apr 01 13:57:00 <Miller> hc: I'm ignorant about the various ways Pd plays out in different distributions... source versus package and the three OSes...
Apr 01 13:57:15 <matju> Miller: is there code looking directly at ->a_type, AND supposing that if something is not a float nor a symbol, THEN it has to be a pointer ?
Apr 01 13:57:46 <Miller> matju: I don't think there is, but I have no way of knowing...
Apr 01 13:58:20 <IOhannes> i think if it does, then it should be a bug
Apr 01 13:58:40 <Miller> yep, but better a quiet bug than an explosive one.
Apr 01 13:58:54 <matju> Miller: well, nothing really matters until you look at it, so the trick is to not look at any code that does that kind of hack.
Apr 01 13:59:07 <IOhannes> i disagree; better an explosive bug than an unnoticed one
Apr 01 13:59:16 <Miller> matju: hehe...
Apr 01 13:59:17 <matju> Miller: seriously, i think it's safe to extend t_atom.
Apr 01 13:59:36 <Miller> matju: but how do we ever _stop_ extending it???
Apr 01 13:59:58 <matju> Miller: and even, it's safe to extend t_atom in a way that uses upper bits of a_type for special purposes, as long as those bits are zero for the already-existing types.
Apr 01 13:59:58 <Miller> e.g., if there's a string type, why shouldn't there be a YUV type, etc.
Apr 01 14:00:44 <Miller> So my attitude so far has been, either absolutely the most minimal type set, or the most horrendously extensible one.
Apr 01 14:00:53 <bbogart> HC & Miller Ideas about the functional grouping of "objects" (externals, internals, libs, abstractions) in the help menu?
Apr 01 14:01:07 <Miller> For instance, the float/int business in Max has been a 20-year-long nightmare.
Apr 01 14:02:01 <Miller> ben: right, I had forgotten that we were thinking about how best to figure out what externs/abstractions did in order to make it easy to search for them.
Apr 01 14:02:17 <_hc> Windows and Mac OS X dir structures are very similar for Pd's use, a base dir for Pd and evertthing in it
Apr 01 14:03:30 <Miller> hc: yes, but you can't browse inside the Mac ones.
Apr 01 14:03:56 <_hc> yes, sad but true, and annoying Apple addition to a find system by NeXT
Apr 01 14:04:01 <_hc> find=fine
Apr 01 14:04:26 <Miller> I honestly don't have any idea how you can make a manageable file tree as part of a software distro on a Mac.
Apr 01 14:04:41 <IOhannes> i thought the idea was rather to define a set of keywords (which somehow occur within the patch/external description) and organize the directory chaotically
Apr 01 14:04:46 <Miller> (without reverting to using some sort of evil 'installer' thing.)
Apr 01 14:04:47 <_hc> I think we need to think of it as a complete application that is not meant to be modified by the user
Apr 01 14:04:55 <_hc> user mods go in user folders
Apr 01 14:05:39 <IOhannes> but i'd prefer a rather modular system (not having to install the whole punch of everything)
Apr 01 14:06:06 <_hc> you can do that with the gg namespace and paths
Apr 01 14:06:21 <_hc> all the code's there, but not in use all the time
Apr 01 14:06:34 <Miller> hc: that sounds reasonable... and maybe the first time you hit 'help' Pd could offer to set that up for you.
Apr 01 14:06:49 <bbogart> Miller: I think we ended up with the idea of a "meta" comment in a patch that had a catagory name and a keyword searchable description of the function. How can I make a wiki on to start mapping this stuff out?
Apr 01 14:06:53 <_hc> set up the paths?
Apr 01 14:07:03 <bbogart> Miller: I think if the help menu is functional enough we would not need to browse the folder.
Apr 01 14:07:12 <_hc> definitely
Apr 01 14:07:21 <IOhannes> bbogart: "add new item"->"ZWikiPage"
Apr 01 14:07:34 <matju> Miller: why should we stop extending it?
Apr 01 14:07:51 <_hc> the current help menu was a half-finished effort, it can definitely be improved a lot
Apr 01 14:07:52 <Miller> But I think browsing is inherently a better way to do it (except that it seems impossible on Mac).
Apr 01 14:07:57 <tigital> matju: according to webster's, "table" is derived from the latin "tabula", and "array" comes from "Middle Latin" for "arredare" (put in order) where does the french come in?
Apr 01 14:08:17 <matju> tigital: it comes from american paranoia.
Apr 01 14:08:25 <tigital> hehe
Apr 01 14:08:48 <matju> tigital: (which doesn't have to make any sense whatsoever as long as there are americans who like to believe in it...)
Apr 01 14:09:19 <bbogart> Miller: you just create a "PD" folder that contains the Then has paths outside the .app
Apr 01 14:09:23 <dpro> matju: no this dates back to robin hood's days
Apr 01 14:09:39 <_hc> bbogart: the meta comment sounds good, but I don't think anyone has time to code that in the near future...
Apr 01 14:09:48 <IOhannes> miller: but browsing would mean that all developers/patches would have to agree on a tree-structure which most likely will not be fit for 50% of the objects that will go in there
Apr 01 14:09:51 <bbogart> IO: thanks, what do you mean organizae chaotically?
Apr 01 14:09:56 <tigital> dpro: and was perfected by p.k. dick!
Apr 01 14:10:26 <Miller> Iohannes: yes, but browsing is the best way to figure out, for instance, where your 'prepend' came from.
Apr 01 14:10:31 <matju> Miller: serious programming languages have a user-extensible type system.
Apr 01 14:10:48 <IOhannes> bbogart: well "as you like it"; i'll put "zexy" in zexy and Gem in "video/Gem" and "iemmatrix" into "iem/iemmatrix"
Apr 01 14:10:49 <Miller> Perhaps though, there's room for both a menu-driven and a browser-driven approach.
Apr 01 14:11:04 <bbogart> HC: hmmm, the only thing that would change would be how the database for the search would be read, so it would happen at the same time as the search thing. I'm thinking it would be a regular comment that starts with help: or some other reserved word.
Apr 01 14:11:07 <IOhannes> bbogart: and i don't have to care about which "class" zexy belongs to
Apr 01 14:11:20 <Miller> matju: yes, and at bottom it's all 0s and 1s, not extensible at all.
Apr 01 14:11:47 <IOhannes> miller: i think browser vs menu are not mutually exclusive
Apr 01 14:11:55 <Miller> matju: more seriously, I think extensibility is often an illusion.
Apr 01 14:12:06 <_hc> IOhannes: that system creates a lot of work for the package maintainers, and its shit work which no one enjoys doing, so I think we need to smooth the process out
Apr 01 14:12:15 <Miller> iohannes: correct. I think I was thinking fuzzily.
Apr 01 14:12:19 <bbogart> IO: indeed being a lib that spans multiple catagories any way you look at it. But the catagory is not what the end user cares about, they just want to find something that "drips"
Apr 01 14:12:34 <matju> Miller: btw, the float/int nightmare is coming back under the name "GridFlow"... because video dudes don't want to use floats in realtime video (well not in 2005)
Apr 01 14:12:37 <bbogart> eyesweb allows your to drag and rename all modules, it is a nightmare.
Apr 01 14:12:59 <Miller> ben: yes, so browsing is perhaps the right way to look at things by-where-they-came-from and the menu system should find things by-keyword or something.
Apr 01 14:13:20 <IOhannes> bbogart: yes exactly; so people could go and "browse" into (say) what zexy offers, but they could also search for "drops"
Apr 01 14:13:44 <IOhannes> miller: yep
Apr 01 14:13:57 <IOhannes> _hc: what is the big extra work ?
Apr 01 14:14:00 <bbogart> miller: I still think organizing by function is way better for users who are learning, otherwise they have to ask the list for a ____ that does ____. if they are browsing by lib-name or something
Apr 01 14:14:29 <Miller> matju: that's too bad. I'm thinking now that my favorite approach would be to have all video ops be in float, but to have _containers_ have variable types that you don't see outside them.
Apr 01 14:14:43 <IOhannes> _hc: i thought this would be simpler for maintainers; the chaotically driven directory tree would need no maintainance at all
Apr 01 14:14:46 <_hc> io: learning each dev's dir structure and build system, for example, debugging each dev's specific system, etc.
Apr 01 14:14:53 <IOhannes> (it just _is_ chaotically)
Apr 01 14:15:08 <IOhannes> _hc: if they all go into ./extra ?
Apr 01 14:15:22 <bbogart> IO: the search could cover the functionality of I-want-to-do-this but only if they keywords are concise and overlap with what the user's vocabulary is.
Apr 01 14:15:37 <Miller> matju: so for instance, when you wanted to start rotating an image, you'd put it in a container and then get it out rotated,
Apr 01 14:15:38 <IOhannes> bbogart: true by nature
Apr 01 14:15:38 <_hc> io: yes, that is the current system, it was a big pain in the butt for me to create a unified package
Apr 01 14:15:52 <Miller> and the container itself would convert on the way in and out.
Apr 01 14:16:09 <IOhannes> _hc: that is why i think that there should be some automated system
Apr 01 14:16:14 <IOhannes> additionally
Apr 01 14:16:15 <bbogart> Catagories could keep obvious things from clouding the keywords "audio" "video" "control" etc..
Apr 01 14:16:30 <matju> Miller: in and out of what? i'm not sure i follow you...
Apr 01 14:17:08 <IOhannes> this would mean: having a set of "standard" categories and additionally allowing the devs/patchers to define there own keywords
Apr 01 14:17:21 <IOhannes> and if someone chooses pd it is their own fault
Apr 01 14:17:29 <tigital> _hc & bbogart: I don't think I mentioned that I put up a compile of impd so that ya'll could see the class browser in osx?
Apr 01 14:17:32 <bbogart> I think the combination of "default" structure for navigation based on function AND a searching utility would be the best. I think sorting based on the arbitrary lib name is illogical.
Apr 01 14:17:34 <_hc> io: we should follow the example of other successful projects like this. From what I've seen, they all have standardized ways of doing things. that is tried-n-true. Having chaotic organization system is an interesting reserach topic that many people are working on, but its not currnely a functional system
Apr 01 14:17:49 <bbogart> tigital: no, whats the link??
Apr 01 14:18:01 <tigital>
Apr 01 14:18:02 <Miller> matju: not sure what I mean. But for example, anything requiring rearrangement of pixels requires storage somehow, I think.
Apr 01 14:18:08 <IOhannes> (i wouldn't choose "html" as a a keyword for my website)
Apr 01 14:18:28 <matju> Miller: like [@store] and [@remap_image] ?
Apr 01 14:18:40 <Miller> matju: I think so, yes.
Apr 01 14:18:42 <IOhannes> _hc: the problem i see is with getting all people work on the same structure
Apr 01 14:18:49 <IOhannes> _hc: this might well be impossible
Apr 01 14:19:00 <IOhannes> _hc: not because it is bad but because people are like they are
Apr 01 14:19:01 <_hc> io: many projects have succesfully done it before
Apr 01 14:19:06 <IOhannes> like ?
Apr 01 14:19:07 <Miller> matju: but I'm thinking (you'll hate this!) a "framebuffer" objects.
Apr 01 14:19:11 <_hc> and we are starting to, with the CVS for exmaple
Apr 01 14:19:23 <IOhannes> no we are not: the CVS is chaotically organized
Apr 01 14:19:32 <bbogart> IO: I agree, but not that it is impossible, its just structure that needs to be imposed. If catagories need to be added then they get added. But if they are well designed it will work.
Apr 01 14:19:34 <matju> Miller: why i'll hate this?
Apr 01 14:19:54 <Miller> matju: because it's inelegant, to the point of being intentionally so.
Apr 01 14:19:55 <_hc> but most of the Pd externals are now centralized in the SourceForge CVS, that's what I mean, before they were spread otu all over thte internet
Apr 01 14:19:55 <IOhannes> everything (every external) goes into CVSROOT/externals and thats it
Apr 01 14:20:28 <_hc> io: one step at a time...
Apr 01 14:20:38 <tigital> miller: do you think planar arrays are more elegant than interleaved arrays?
Apr 01 14:20:50 <_hc> io: we have a start build system now also...
Apr 01 14:20:51 <bbogart> The best catagorization system would be fuzzy, with externals belonging to a certain degree, but that is overkill for PD I think.
Apr 01 14:20:52 <IOhannes> _hc: and thus every external should by default install itself into (say) ./extra
Apr 01 14:21:06 <Miller> tigital: wow, I was just wondering what to do about interleaving recently.
Apr 01 14:21:23 <matju> Miller: [@store] is a framebuffer object class, except it's also a generic buffer, and a system for fetching parts of buffers and glue them together.
Apr 01 14:21:43 <_hc> io: that might work with a functional meta tagging system
Apr 01 14:21:44 <Miller> I think that, "interleaving' refers to the order in which data gets into and out of a frame buffer.
Apr 01 14:21:45 <tigital> miller: isn't that just what a "framebuffer" is?
Apr 01 14:21:57 <bbogart> IO: whether or not the externals go into extra/ has NO bearing on the way the documentation should be organized from the first-time-users perspective.
Apr 01 14:22:40 <tigital> miller: I suppose it's hardware dependent: "framebuffer" on cpu is different than it's representation at the end of the gpu pipeline...
Apr 01 14:22:43 <IOhannes> _hc: btw "one step at a time..." is exactly how i think it; leave the one (sub-optimal) system as it is and impose another (better?) one in parallel
Apr 01 14:22:47 <bbogart> I think its clear that everything should be an external and in /extra and each external should have its own helpfile, next to the lib or in a paralell folder.
Apr 01 14:23:19 <IOhannes> so what is then the talking about "help-directory-structure" (maybe i have missed the point)
Apr 01 14:24:15 <bbogart> IO: I'm talking about the user-experience of "browsing" documentaion. This is related to the menu, the search idea, and the directory structure but I think the latter is an implimetation detail that should be informed by the former points.
Apr 01 14:24:47 <_hc> indeed
Apr 01 14:25:09 <_hc> I think that we should focus on the interface first, then worry about the implementation
Apr 01 14:25:19 <bbogart> HC: yes! woohoo.
Apr 01 14:25:30 <IOhannes> well yes
Apr 01 14:25:50 <IOhannes> that's why i wanted the directory to be "chaotic" in the first place
Apr 01 14:26:08 <IOhannes> if we still can handle the documentation then we need not worry at all
Apr 01 14:26:08 <bbogart> ok, lets forget the directory for now and talk about the interface to documentation.
Apr 01 14:26:10 <matju> Miller: anyhow i'm not going to make gridflow do only float32... ever
Apr 01 14:26:30 <bbogart> IO: what do you mean?
Apr 01 14:26:32 <_hc> anyone know any good examples of help browsers?
Apr 01 14:26:58 <IOhannes> bb: hmmm
Apr 01 14:27:15 <_hc> the java web pages are good, but they don't have a functional aspect, like the Pd help patches
Apr 01 14:27:18 <bbogart> The apple one is cute because its consistant accross all apps, but the navigation is pretty ugly, while the search is good.
Apr 01 14:27:30 <mamalala> _hc: the kde help center maybe ....
Apr 01 14:27:39 <Miller> matju: and I think that in the case of gridflow that's appropriate, because it is fundamentally a more coherent structure that can manage more extensibility.
Apr 01 14:27:42 <bbogart> It is true that PD docs are somewhat special being both documentation and pointed examples.
Apr 01 14:27:57 <IOhannes> mamalala: i have to admit that i never use it (although i use kde)
Apr 01 14:28:02 <_hc> since there are getting to be so many objects, I think that search will be vital
Apr 01 14:28:09 <matju> _hc: class-browsers were first introduced in smalltalk-80, so generally speaking, smalltalk implementations are strong in that area.
Apr 01 14:28:16 <_hc> also, linking help files helps a lot
Apr 01 14:28:30 <_hc> are they fucntional also?
Apr 01 14:28:53 <mamalala> IOhannes: it handles the kde docu, the doc for extra apps, the unix man pages, etc .... so it can give an idea how a "common help place" for different stuff can look like ....
Apr 01 14:28:54 <bbogart> hc: as in a reference to another help patch in a current one?
Apr 01 14:29:26 <_hc> bbogart: exactly, like the PDDP patches, especially the all_about_ patches
Apr 01 14:29:33 <bbogart> actually I never mentioned that pixelTANGO has a pixelTANGO-help.pd that just lists all the objects in pixelTANGO. this is not very scalable, but its organized...
Apr 01 14:29:42 <IOhannes> mamalala: i thought so; but everytime i searched the help it was "to be written"
Apr 01 14:30:06 <mamalala> IOhannes: well, you know how developers are writing documentiation, right ? ;-)
Apr 01 14:30:23 <bbogart> hc: I agree it is nice to refer to other objects, I think this can be at the author's descretion.
Apr 01 14:30:25 <IOhannes> mamalala: no i don't ;-)
Apr 01 14:30:54 <IOhannes> bbogart: reminds me on the zexy help system which i started to abandon
Apr 01 14:30:55 <bbogart> IO: generate a help file on the fly from external code?
Apr 01 14:31:04 <_hc> bbogart: I think it should be part of the style guide that lilnks are code, like in PDDP
Apr 01 14:31:05 <mamalala> IOhannes: see, you ansered the question perfectly ;-D
Apr 01 14:31:15 <mamalala> +w
Apr 01 14:31:22 <_hc> bbogart: with "related_*" subpatches
Apr 01 14:31:25 <_hc> for example
Apr 01 14:31:42 <bbogart> I confess I've not looked at PDDP yet...
Apr 01 14:32:05 <tigital> bbogart: awww, ya need to
Apr 01 14:32:15 <_hc> if you use any of my builds, its included,
Apr 01 14:32:16 <IOhannes> bbogart: i rather thought of "registering some information" like the "class_addhelpsymbol()"
Apr 01 14:32:23 <Miller> I haven't looked at PDDP for a couple of years, is it active?
Apr 01 14:32:24 <_hc> PDDP has a lot of good stuff
Apr 01 14:32:37 <_hc> yes, I have been writing patches
Apr 01 14:32:43 <_hc> I might be the only one tho
Apr 01 14:32:58 <bbogart> PDDP link handy?
Apr 01 14:32:59 <_hc> they are all in CVS
Apr 01 14:33:08 <_hc> doc/pddp
Apr 01 14:33:12 <bbogart> ah!
Apr 01 14:33:43 <_hc> tigital: how do I open the class browser in impd?
Apr 01 14:33:46 <bbogart> I'll have to co on an other machine. I'm having trouble understanding the link and subpatch ideas.
Apr 01 14:34:30 <mamalala> IOhannes: the point i wanted to made with the doc writing is, many developers are just horrible at writing docu .... if they write any at all .... most of the time, a simple readme seems to be enough
Apr 01 14:34:45 <mamalala> IOhannes: for them .....
Apr 01 14:35:26 <bbogart> ck: indeed, because documentation is HARD!
Apr 01 14:35:53 <bbogart> lukily I'm just a user that pretends to develop once and a while.
Apr 01 14:35:54 <_hc> yeah, I have gotten into the habit of writing or editing a help patch whenever I learn a new object, it works pretty well
Apr 01 14:36:09 <bbogart> so it easier to put my head in the documentation mind-set and assume I don't know anything.
Apr 01 14:36:16 <_hc> I learn it better, and a help patch is produced as part of it
Apr 01 14:36:41 <bbogart> So we have these two ideas, catagorization and searching.
Apr 01 14:37:04 <_hc> categories work better for learning
Apr 01 14:37:06 <_hc> I think
Apr 01 14:37:11 <bbogart> I think they are complimentary. catagorization is harder to design perhaps, but easier to impliment than searching which is harder to impliment.
Apr 01 14:37:20 <mamalala> bbogart: i wouldnt say it is so because its "hard" ..... if you have written a program, you should know what it does andd how .... just the "translation" to documentation seems to be boring
Apr 01 14:37:43 <bbogart> HC: I agree and standard catagories help developers & users get a lay of functionality
Apr 01 14:37:56 <_hc> mamalala: I usually turn my test patches into help patches, that a way to make documentation less boring
Apr 01 14:38:36 <bbogart> ck: hehe, when it is as easy to read the source, I still find it hard to find the methods in gem source!
Apr 01 14:38:38 <mamalala> _hc: thats true ..... but then, i was talking about real written documentation, as in a book
Apr 01 14:38:43 <bbogart> hc: I've done the same exactly.
Apr 01 14:39:00 <_hc> mamalala: ah yes, that's different, and much harder
Apr 01 14:39:15 <_hc> I think now we are talking about help patches, and how to organize them
Apr 01 14:39:40 <bbogart> indeed a whole other thing, its the big picture.
Apr 01 14:39:55 <IOhannes> oh, i always thought that pd-documentation should stay help-patch-focused
Apr 01 14:40:16 <mamalala> why not just pass some "category" strings upon the first library loading ? like pd queries the library about a string, say const char *category = "dsp:fft" together with an one-line
Apr 01 14:40:17 <IOhannes> at least, all documentation should be done as pd-patches
Apr 01 14:40:40 <IOhannes> mamalala: thats what i meant with "registering"
Apr 01 14:40:45 <Miller> matju: is there a description of your pointer extention to t_atom handy? I want to see if 'gpointer' can be tricked into doing it.
Apr 01 14:40:48 <mamalala> help what it is ..... and then, the actual name of the real help can be contained in the lib as well, so that it just up to pd
Apr 01 14:40:56 <dpro> hc: I still fancy the idea of having this all neatly integrated in pd (like thomas did a fantastic job for wasp, or io's zexy is also very easy to find your way around)
Apr 01 14:41:00 <mamalala> to search some known help path definitions for that file .....
Apr 01 14:41:01 <IOhannes> you just do something like "class_addhelpcategory("fft")
Apr 01 14:41:12 <mamalala> IOhannes: yea, right ....
Apr 01 14:41:21 <bbogart> ck: what we're talking about is basically an entry in the PD help path that would conatain some of that data, in particular the catagory and keywords
Apr 01 14:41:54 <IOhannes> mamalala: and the same for abstractions [helpcategory fft convolution mother]
Apr 01 14:41:59 <mamalala> bbogart: but why spreading that info into seperate files, for me, that would belong into the library itself ....
Apr 01 14:42:17 <IOhannes> (which might be tricky to do)
Apr 01 14:42:19 <dpro> ben: [OT] could you stop calling mamalala ck I'm a ck too ;)
Apr 01 14:42:49 <_hc> "class_addhelpcategory("fft") + [helpcategory] sound good to me
Apr 01 14:42:58 <dpro> ben: but that's what I find so hard - defining precise categories isn't at all easy
Apr 01 14:43:16 <bbogart> dpro: ARG!!! sorry. sav'in strokes.
Apr 01 14:43:25 <_hc> loose ones are better than none
Apr 01 14:43:35 <IOhannes> then just skip the "category"-idea and concentrate on "keywords" first
Apr 01 14:43:46 <dpro> hc: and probably objects could be in more than one ?
Apr 01 14:43:53 <_hc> absolutely
Apr 01 14:43:54 <mamalala> bbogart: what client do you use ? try typing the first few letters of a nick and then press the tab-key .... it should expand to the next fittin nick then ....
Apr 01 14:44:00 <bbogart> hc: they would be loose for sure, since they would be the first point of contact, with the find utility filling in the details
Apr 01 14:44:07 <mamalala> bbogart: like i do "bb<tab>" to address you ;-)
Apr 01 14:44:27 <bbogart> mamalala, cute! thanks for the tip.
Apr 01 14:44:30 <_hc> mamalala: handy trick, thanks
Apr 01 14:44:38 <IOhannes> thanks too!
Apr 01 14:44:45 <bbogart> haha!
Apr 01 14:44:50 <mamalala> think about tab completition in the bash .... ;)
Apr 01 14:45:25 <bbogart> I think developers and learned users are fine with almost any documentation (my own machine has all the help broken actually).
Apr 01 14:45:30 <mamalala> or do you guys always type out all damn_extra_long_names.manually ?
Apr 01 14:45:34 <mamalala> ;)
Apr 01 14:45:36 <IOhannes> yes
Apr 01 14:45:38 <bbogart> the documentation is most critical to a new user
Apr 01 14:45:50 <_hc> bbogart: I disagree
Apr 01 14:46:06 <bbogart> hc: go on
Apr 01 14:46:13 <_hc> I cannot store all the niggling details in my brain, so use the help as a refernce constantly
Apr 01 14:46:31 <_hc> no matter what progamming language
Apr 01 14:46:51 <_hc> so I think we need to think of the help system as a reference and help
Apr 01 14:46:56 <matju> _hc: in Impd, the class browser is in the File menu; in devel_0_37 it's in the Help menu.
Apr 01 14:47:08 <bbogart> hc: I agree, but I mean its not make or break for one of us, as it is for the end user. When I need it to just do "file" open in pd.
Apr 01 14:47:22 <mamalala> IOhannes: then you should try the tab key in the middle of such a name when you type it the next time in the bash ;)
Apr 01 14:47:39 <IOhannes> ?
Apr 01 14:48:25 <IOhannes> oh, you were referring to damn_extra_long_names.manually as a filename ? of course i know commint
Apr 01 14:48:36 <bbogart> A new user downloads PD, the first thing they do is try some examples, how do they get to them?
Apr 01 14:48:37 <mamalala> IOhannes: ah ... ;)
Apr 01 14:48:47 <_hc> yeah, there is that too
Apr 01 14:48:53 <_hc> examples, tutorials, etc.
Apr 01 14:48:58 <bbogart> yeah.
Apr 01 14:49:37 <bbogart> My whole reason for putting a bunch of stuff in a folder in applications was to make it organized and navigable. PixelTANGO-Examples, Gem-Examples, Help etc...
Apr 01 14:50:02 <bbogart> I think its all part of the same problem, documentation, not just "help" patches.
Apr 01 14:50:15 <IOhannes> oh i see
Apr 01 14:50:26 <bbogart> My orginal proposal for the help menu contained examples as well.
Apr 01 14:50:32 <IOhannes> but this strikes me yawning (no matter how important it is)
Apr 01 14:50:44 <matju> Miller: the description is not complete enough for that, and i don't think gpointer can do the job, because my "vpointer" type holds both a symbol and an instance-number. the vpointer has an extra level of indirection compared to a gpointer. this is required for proper implementation of s/r-symbols, if i'm not mistaken.
Apr 01 14:51:32 <bbogart> I think the user access to all documentation should be somewhat unified, maybe not the html stuff since its quite different by nature. (how about one page of Miller's book next to the help patches for objects it refers to? blech!)
Apr 01 14:51:34 <_hc> I think there are 3 basic categories of docs: help patches, tutorials, and examples
Apr 01 14:52:17 <_hc> well, and manuals also
Apr 01 14:52:19 <bbogart> _hc, tutorials is something I had not thought about.
Apr 01 14:54:22 <bbogart> HC: I'm now thinking we need to define this problem to solve it, since all those things, the manual, tutorials, examples, help patches and even workshops are related.
Apr 01 14:54:31 <bbogart> :S
Apr 01 14:55:33 <_hc> yes
Apr 01 14:55:43 <_hc> workshops are basically tutorials, no?
Apr 01 14:56:55 <bbogart> yes... I think of tutorials as being smaller and more tight, "using tables in pd" using "gop" etc.. but I guess a workshop is then just a chain of tutorials that are related
Apr 01 14:56:59 <Miller> matju: Aha, so this is a mechanism for pointing to things without making global unique symbols if I understand corrrectly.
Apr 01 14:57:08 <dpro> hc: hmm I'd say a workshop is with someone acting as a tutor, a tutorial you can simply go through on your own wo a "study buddy"
Apr 01 14:57:56 <bbogart> hc, I think it would be great if workshops would be used by instructors and also could be used by the end user on thier own time.
Apr 01 14:59:10 <bbogart> problem is that a example could be a tutorial, or is the difference that a tutorial has to be made in small steps not all in one shot?
Apr 01 14:59:29 <rdz> i think we should concentrate on the help-patches. speaking as a 'end-user', i must say, that this is the first thing i am looking for after installing a new external.
Apr 01 14:59:34 <Miller> hc: and the distinction between tutorials and examples might not be black-and-white; for example, goes along with a book (not part of Pd).
Apr 01 15:01:11 <bbogart> miller: yeah... the reason why we're talking about it is a few of us PD teachers are talking about developing a standard workshop for PD.
Apr 01 15:01:34 <Miller> cool!
Apr 01 15:02:03 <_hc> dpro: but I think the patches for a tutorial and a workshop would be very similar, so similar that they fit in the same category
Apr 01 15:02:18 <bbogart> I think the first step is to define the problem: It is difficult for a new user to learn PD because...
Apr 01 15:02:48 <bbogart> miller: have you seen my pd-lecture its at and is used as a basis of a workshop they are doing in NYC pretty soon.
Apr 01 15:02:49 <_hc> bbogart: I'd say an example is more fleshed out than a tutorial, and is a fully working version, not created to illustrate a concept but to fulfill a fucntion
Apr 01 15:03:08 <bbogart> hc: that sounds like a good definition to me.
Apr 01 15:03:20 <dpro> hc: probably true
Apr 01 15:03:22 <Miller> bbogart: no, will check it out.
Apr 01 15:04:14 <bbogart> book: really big picture, tutorial: big picture, example: medium picture, help patch: close-up.
Apr 01 15:04:32 <bbogart> miller: very simple, and rolls pd/gem together but new users seem to really like it.
Apr 01 15:04:40 <dpro> hc: help = reference, example = illustrating possible application, tuturial = illustrate concepts, workshop = a series of tutorials ?
Apr 01 15:04:43 <_hc> I think example is kind of out side that
Apr 01 15:05:23 <_hc> bbogart: book= big, tutorial = medium, help patch = small
Apr 01 15:05:31 <_hc> bbogart: example = application
Apr 01 15:05:33 <matju> Miller: yes. i thought about using gpointers in that situation, but there are problems that would appear because of the missing extra level of indirection.
Apr 01 15:05:48 <_hc> dpro: sounds good to me
Apr 01 15:06:56 <bbogart> _hc, hmmmmm
Apr 01 15:07:19 <matju> Miller: i mean, the case of changing the pointee of a receive-symbol when a gpointer has already been created from a $0-hello.
Apr 01 15:07:20 <Miller> matju: even if the gpointer just points to the Pd object making the call?
Apr 01 15:07:25 <bbogart> _hc, would examples be included in tutorials?
Apr 01 15:07:40 <_hc> bbogart: I'd say separate
Apr 01 15:07:44 <matju> Miller: i don't understand
Apr 01 15:07:52 <matju> Miller: but i have to leave now, ttyl
Apr 01 15:08:07 <Miller> matju: me either. Will try to think about this.
Apr 01 15:08:14 <Miller> matju: bye...
Apr 01 15:08:29 <mamalala> c ya mamalala
Apr 01 15:08:33 <dpro> ben: on the teaching thing: is this effort coordinated anywhere ? I was thinking about taking up gem for 3d stuff a little and I could probably contribute and would volunteer for a .de translation
Apr 01 15:08:37 <tigital> matju: ciao
Apr 01 15:08:38 <mamalala> oh, matju that should be.....
Apr 01 15:08:47 <mamalala> damn tab key ;)
Apr 01 15:08:48 <bbogart> _hc, ok, lets take a concrete example, from my pd-lecture there is a page that is a fully functional example of a gem-patch. is this an example?
Apr 01 15:09:19 <dpro> ben: hehe no it's a fully functional example SCNR
Apr 01 15:09:31 <bbogart> dpro, we're just starting things up, so far HC, vade aka doktorp, and a guy in finland are interested.
Apr 01 15:09:32 <_hc> bbogart: would you perform with it?
Apr 01 15:09:43 <dpro> ben: count me in
Apr 01 15:09:52 <_hc> dpro: great, the more the merrier
Apr 01 15:10:06 <bbogart> _hc, I could, but it is so simple that it does not do much...
Apr 01 15:10:37 <bbogart> dpro: whats your addy, I'll send you the last message I sent that talked about workshop structure.
Apr 01 15:10:38 <_hc> bbogart: sounds to me more like part of a tutorial
Apr 01 15:10:49 <_hc> bbogart: but there could be simple examples also...
Apr 01 15:11:14 <bbogart> _hc, this is where I'm getting a little confused. since this one page could just be plunked in isolation as a "gem-chain" example...
Apr 01 15:11:29 <bbogart> this is what I think the tutorial would contain examples...
Apr 01 15:11:37 <_hc> bbogart: yeah, there will always be grey areas
Apr 01 15:11:41 <dpro> I also think a white make-me-green cube is a fully funcional gem patch but merely an example of the render chain, once you add bells and whistles it becomes more a tutorial sort of thing
Apr 01 15:11:46 <bbogart> maybe this is too much on semantics, I tend to do that.
Apr 01 15:11:49 <tigital> bbogart: did I miss a link to these examples or whatever they're called?
Apr 01 15:12:17 <bbogart> "PD-Lecture" link
Apr 01 15:12:19 <IOhannes> .... i have to leave too (becoming very tired)
Apr 01 15:12:33 <tigital> IO: nite, talk 2 ya soon
Apr 01 15:12:40 <bbogart> night IO
Apr 01 15:12:40 <mamalala> c ya IOhannes
Apr 01 15:12:42 <-- alejoo has quit ("Oops. This machine just fell asleep")
Apr 01 15:12:48 <tigital> IO: now that we have a topic to talk about :-)
Apr 01 15:12:57 <IOhannes> .... i hope someone will post me a link to their log so i can put it onto
Apr 01 15:13:08 <IOhannes> tigital: yes i am looking really forward to that
Apr 01 15:13:12 <IOhannes> good night
Apr 01 15:13:14 <IOhannes> everybody
Apr 01 15:13:16 <IOhannes> everywhere
Apr 01 15:13:20 <bbogart> I'm going to start some WIKIs on I guess one for workshops and one for pd-documentation?
Apr 01 15:13:31 <-- IOhannes ( has left #dataflow (".")
Apr 01 15:14:17 <_hc> what's the wiki for? ideas?
Apr 01 15:14:57 <tigital> bbogart: and one for the help/class browsing structuring stuff?
Apr 01 15:15:31 <dpro> guys I have to go ...
Apr 01 15:15:36 <bbogart> yeah, since I'm already having trouble holding all this in my head! one for workshops (structure, topics etc..) and one for how we access PD documenttion inside pd.
Apr 01 15:15:59 <bbogart> ok dpro: good to have your ideas on board, I'll forward you the last thread and we'll go from there.
Apr 01 15:16:07 <dpro> cu all
Apr 01 15:16:08 <bbogart> Can other people change my wiki page?
Apr 01 15:16:11 <dpro> ben: thx
Apr 01 15:16:30 <tigital> dpro: l8r
Apr 01 15:16:40 <-- dpro has quit (""I'm an april fool"")
Apr 01 15:17:25 <_hc> bbogart: what's the URL?
Apr 01 15:17:26 <Miller> Time for me to go too. Bye folks!
Apr 01 15:17:40 <bbogart> I don't know what to call the "pd documentaion from inside PD" Bye Miller!
Apr 01 15:17:43 <tigital> bye miller
Apr 01 15:17:45 <_hc> Miller: bye bye
Apr 01 15:18:06 <mamalala> bye Miller
Apr 01 15:18:16 <-- Miller has quit ("Leaving")
Apr 01 15:18:25 <bbogart>
Apr 01 15:19:36 <bbogart> should I call the other page "documentation structure"?
Apr 01 15:19:53 <_hc> sure
Apr 01 15:20:00 <_hc> I can write
Apr 01 15:20:07 <_hc> I have to go as well...
Apr 01 15:20:11 <_hc> bye all
Apr 01 15:20:15 <mamalala> c ya _hc
Apr 01 15:20:31 <_hc> let's bbogart let's start getting all this down on the wiki...
Apr 01 15:20:37 <_hc> oops
Apr 01 15:20:57 <bbogart> ps://
Apr 01 15:21:08 <_hc> ok
Apr 01 15:21:25 <_hc> how about posting these two to the pd-dev list, with a call for ideas?
Apr 01 15:21:43 <_hc> I'll start contributing ones I recover from my flood (next couple days)
Apr 01 15:21:53 <bbogart> I have to go pretty soon, I can transpose the last workshop email we talked about in the workshops one. Ok I'll post to pd-dev
Apr 01 15:22:33 <mamalala> _hc: flood ?
Apr 01 15:22:45 <_hc> mamalala: my room flooded
Apr 01 15:22:50 <_hc> bedroom
Apr 01 15:23:03 <mamalala> _hc: damn.... good recovery, of course !
Apr 01 15:23:19 <_hc> didn't loose much, I just have to deal with a big wet carpet now...
Apr 01 15:23:49 <_hc> anyway, time for some wet carpet fun!, ttyl
Apr 01 15:23:53 <-- _hc has quit ()
Apr 01 15:23:53 <mamalala> _hc: i hope no other damage id caused by that, like fungus or such ....
Apr 01 15:24:17 <tigital> wet carpet stinks
Apr 01 15:24:37 <mamalala> indeed .....
Apr 01 15:24:43 <mamalala> the older, the stinkier .....
Apr 01 15:25:32 * mamalala banned all carpets years ago ....
Apr 01 15:28:06 <bbogart> I gotta learn strucrured text.. ick!
Apr 01 15:28:29 <bbogart> how to make a heading, point list?
Apr 01 15:40:08 <timblech> bye
Apr 01 15:40:21 <mamalala> c ya tigital
Apr 01 15:40:25 <mamalala> aye, timblech
Apr 01 15:40:30 <-- timblech has quit ("Verlassend")
Apr 01 15:41:20 <tigital> l8r mamalala
Apr 01 15:41:35 <tigital> gotta go meself
Apr 01 15:41:39 <-- tigital has quit ()
Apr 01 15:45:06 <bbogart> ok, I'm off too. I'll add a bit to the wiki this weekend.
Apr 01 15:45:13 <-- bbogart has quit ("Leaving")
Apr 01 15:52:56 <-- normand has quit ("Leaving")
Apr 01 15:55:53 <-- vitriolix ( has left #dataflow
Apr 01 16:23:45 <rdz> bye

Powered by IEM Powered by Plone Section 508 WCAG Valid XHTML Valid CSS Usable in any browser