I think the point was simply that Miller deserves credit for his essential contributions to pd. I don't think this is the place to discuss your problems with SLOC and COCOMO.
Ben Baker-Smith
I have no idea. I just meant that if anyone deserves to be cooked meals
because of Pd related things, then it's Miller. That is a lot of lines of source code (only 25,000 of them are portaudio/portmidi).
First of all, if you consider portaudio and portmidi like the separate projects that they are and that Miller didn't write and that is not really part of Pd in any way, the total SLOC drops to 68000.
Next, Miller is not completely alone in writing Pd. You probably know that already. It's not even a very small or neglectible amount. In SLOC count, Thomas Musil contributed 10% of the source code alone, as the original author of the IEMGUI library.
Then you probably know what is copy-paste. IIRC, about 1300 lines of code of IEMGUI can be explained by a one-liner sed | diff | wc command. Then there is other copy-paste in places like d_math.c and x_arithmetic.c for which I made the demonstration that they can be shrunk to less than 20% of their size using macros *while* keeping all optimisations in. (not sure I posted on the lists about it, though).
Then the "basic COCOMO model" does not take copy-paste into account, therefore it's na?ve at best, a fraud at worst. It's also highly dependent on many other things it shouldn't be dependent on, thus it's most certainly unlikely to be accurate at all.
Braces change the SLOC. The 72-character maximum that comes from IBM punchcards) changes the SLOC. Statement size changes the SLOC (say something short as two statements, you have two lines, but say it as one, you have one line). Think about it, you even charge for the blank lines and all the lines that say /********/ , no matter how many a given programmer decides to put.
All the Basic COCOMO model ever does correctly is punish any people who try to save on the number of lines of code.
On Tue, 6 Jul 2010, Ben Baker-Smith wrote:
I think the point was simply that Miller deserves credit for his essential contributions to pd. I don't think this is the place to discuss your problems with SLOC and COCOMO.
A point worth making, is a point worth making with a good support. If the point is being supported by SLOC and COCOMO, then SLOC and COCOMO become as on-topic as anything else used to support an argument about something on-topic.
I agree with the point as much as anyone else, but I disagree with the means to support it. I'd rather put no figures at all, than figures that are not meaningful.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
The funny thing is that I started this thread a couple of days ago and these last posts about "SLOC" and "COCOMO" are totally cryptic to me!!! My original question was: how to build graphical user interfaces for pd patches that would look more like standard software and be less "disturbing" to non-pd devellopers (especially meaningfull when building a virtual lighting board for instance, like this guy I met in Avignon, France the other day with a max patch, he had even found a way to remotely control it with his Iphone... very impressive). The other part of the question was : how to bundle the no-gui pd patch with the new interface and all the pd install files so the patch could be distributed as a standard application on any... say... windows computer... or else). A couple of people have mentioned the processing environement; If anyone has new tips to bring up, I'd be more than happy to know: would visual basic, python or Qt do the job?
Thank you all for your involvement!
People who want to continue to discuss "SLOCOMO" issues (whatever it is...) are, of course, very welcome to do so, but it might be a good idea to start a new, dedicated thread for this highly technical subject.
I hope I did not offense anyone, it really isn't my point: I love all Pd related questions.
David Schaffer
I think the point was simply that Miller deserves credit for his essential contributions to pd. I don't think this is the place to discuss your problems with SLOC and COCOMO.
A point worth making, is a point worth making with a good support. If the point is being supported by SLOC and COCOMO, then SLOC and COCOMO become as on-topic as anything else used to support an argument about something on-topic.
I agree with the point as much as anyone else, but I disagree with the means to support it. I'd rather put no figures at all, than figures that are not meaningful.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969
On Tue, 6 Jul 2010, David Schaffer wrote:
My original question was: how to build graphical user interfaces for pd patches that would look more like standard software
Here's an example for you. Here is the serveur.pd patch, which you will start first :
#N canvas 0 0 450 300 10; #X obj 7 5 netreceive 23456; #X obj 7 24 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X connect 0 0 1 0;
and here is piton.tcl, which you will then run, using the "wish" command :
set tibas [socket localhost 23456] fconfigure $tibas -buffering line button .b -text "hello, how are you?" -command {puts $tibas "bang;"} pack .b -padx 10 -pady 10
and then you click on the button of the latter programme and it will activate the bang button in the former programme (patch).
you can replace "localhost" by any recognised hostname that the server patch may be running on, and change the port number to whatever agreed upon by both programmes.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Tue, Jul 6, 2010 at 11:10 AM, Mathieu Bouchard matju@artengine.cawrote:
On Tue, 6 Jul 2010, Ben Baker-Smith wrote:
I think the point was simply that Miller deserves credit for his essential
contributions to pd. I don't think this is the place to discuss your problems with SLOC and COCOMO.
A point worth making, is a point worth making with a good support. If the point is being supported by SLOC and COCOMO, then SLOC and COCOMO become as on-topic as anything else used to support an argument about something on-topic.
Agreed, but why argue the point at all?
Ben Baker-Smith
-
Ben Baker-Smith -
David Schaffer -
Mathieu Bouchard