Re: data structure GUIs and bugs [was: Re: [PD-dev] BUG: namespace prefixes broken in 0.40]
On Nov 4, 2006, at 1:38 PM, Frank Barknecht wrote: Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote: I guess it's subjective but I think some of the GOP datastructure abstractions out there have amazing GUIs that work with vanilla Pd without requiring users to compile/install complicated externals. Want examples? Check out Frank's work. I'm only doing toys. A new toy is attached (requires 0.40): a simple slider made with DS. It has some redraw problems: moving the object will not move the GOP'ped data structures, until a redraw is forced externally or manually. Also [pd subpatches] seem to be broken somewhat if you enable the hide object name property, which doesn't get saved into the patch (if the subpatch name has a $0). That's nice, it would be great to have state-saving built-in too. But for some reason on Mac OS X, the slider part doesn't show up on the help patch. But it does if I open up the object itself. Oh, I see, its the annoying cross-platform size differences. That needs to be fixed so bad... hmm... I started on it, but didn't quite get there.. .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: opt-in usage statistics 'phone home' WAS: [PD-dev] BUG: namespace prefixes broken in 0.40
Incidentally, I also think this highlights the need for a poll of the Pd list at some point so we can get some idea of what users are using what externals, abstraction sets, libraries, etc. I would love to see the numbers, and it would probably be useful for Miller to see what is popular about Pd in a quantifiable scientific way. what about an opt-in usage statistics 'phone home'. initng does this for example.. firefox just does it without even asking.. Funny, I was just thinking about something like that. It would be cool to know how many people are using Pd. If you code it, I'll include it in Pd-extended. Then maybe it could make it into devel or MAIN. this doesn't add any useful functionality for the user and is using the means of adware/spyware/activation ... it will definitely not make it into devel as long i still have a write access to the cvs ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Relying on the government to protect your privacy is like asking a peeping tom to install your window blinds. John Perry Barlow signature.asc Description: This is a digitally signed message part ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] BUG: namespace prefixes broken in 0.40
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: I advocate use of consistent syntax all over pd. Consistency is more important than minimality. If pd's syntax is too minimal, it encourages small syntax hacks that aren't portable to the rest of the pd system, such as -y amp(0:100)(0:100). That is strange, I hadn't seen that before. I also have not seen gridflow before. I should say, then I am talking about things in common usage. There is definitely a lot of stuff shoe-horned into some of those draw and plot boxes. I wonder how to make that stuff work without the new syntax? (Optional) keyword arguments are a long-term wishlist item, because only having positional arguments is not very comfortable. It would be great to have a corresponding object or syntax to read out keyword arguments in abstractions. I think, Thomas Grill write somthing like that for the flext-syntax. From a qwertz-keyboard user's view I would prefer the -key syntax over flext's @key syntax. Gridflow's syntax looks quite interesting, though unusual. I need to think more about it. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] BUG: namespace prefixes broken in 0.40
Hi all, (Optional) keyword arguments are a long-term wishlist item, because only having positional arguments is not very comfortable. It would be great to have a corresponding object or syntax to read out keyword arguments in abstractions. I think, Thomas Grill write somthing like that for the flext-syntax. it's in the cvs in externals/grill/absattr From a qwertz-keyboard user's view I would prefer the -key syntax over flext's @key syntax. i only chose that because it's already known in the patcher world, due to Max/Jitter. I didn't want to introduce another standard, when there's no real reason to do that. greetings, Thomas -- Thomas Grill http://g.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] BUG: namespace prefixes broken in 0.40
On Wed, 1 Nov 2006, Hans-Christoph Steiner wrote: [declare -import (foo bar)] - GF-style nested lists [declare -import foo bar] - use dash-prefixed symbols as delimiters [declare, import foo bar] - use comma as delimiter One very important aspect of Pd is its very minimal syntax. It depends on which part of Pd you're looking at. Let's say that you're looking at everything that confirms your point; then you're not looking at datastructures. For example: [plot -y amp(0:100)(0:100) a 500 2 5 30] I advocate use of consistent syntax all over pd. Consistency is more important than minimality. If pd's syntax is too minimal, it encourages small syntax hacks that aren't portable to the rest of the pd system, such as -y amp(0:100)(0:100). I think its quite important to preserve that. Pd's syntax doesn't so much deserve to be called simple ... simplistic is more like it. Any non-recursive grammar is bound to get to a dead-end in which small syntax hacks proliferate. but I don't really like any of the above options. Pd is not Ruby, Tcl, C, UNIX, etc. and it shouldn't follow those conventions without really good reasons to break the current syntax. This is called Not Invented Here, the concept that one system should not borrow conventions from another system. It's an important concept that has been used for designing many systems, and ironically, one that many systems designers have borrowed from each other. (http://en.wikipedia.org/wiki/Not_Invented_Here) It's not possible to break the current syntax because there's no current syntax. Adding commas and () in object boxes is totally unprecedented GridFlow is a precedent for both initbang commas and nested lists, but it doesn't count because it was not designed by Miller. There is also precedent for @ keywords in the work of Thomas Grill and also of Joshua K Clayton but it doesn't count because it was not designed by Miller. There is also precedent for - keywords in the work of Krzysztof Czaja but it doesn't count because it was not designed by Miller. and I can't see any benefit. because it's not designed by Miller and because you're not thinking about any of the other object classes that could benefit from those syntax extensions. Even though [plot] would have needed it, [plot] introduces its own precedent which is sufficient justification by itself, because it was designed by Miller. I definitely agree we should have a standard way of doing this kind of thing, By reading you, I doubt that you mean that we should have a standard way of doing keyword arguments. Is it that you are only thinking about namespaces and nothing else? I'm not only thinking about namespaces. You're replying to a mail where more than just namespaces are considered. Perhaps this extended syntax is useful in other situations, but I think this situation could easily be taken care of using only current syntax: Right, we don't absolutely need keyword arguments, nested lists and initbang messages in objectboxes. I'm only talking about those things because a syntax similar to keyword arguments has been proposed and because I've seen similar patterns occur in the pd world, but I don't mean the pd world that has just Miller in it, I mean all externals, and not just the subset of pd-extended that agrees with Miller's practice (minus [plot]). I think it could make more sense to have the global settings controlled by messages. [;pd import foo bar( [;pd path foo bar( [import foo bar( | [s $0-canvas] [namecanvas $0-canvas] _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
