<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 26, 2014 at 5:03 PM, Ivica Bukvic <span dir="ltr"><<a href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p dir="ltr">The reason why I believe combining all of these will not be feasible is because in one of my recent conversations with Miller (and Miller please correct me if I somehow misremember here) he expressed his belief any project that exceeds N lines of code which I believe in this case it was something like 10000, it becomes unmaintainable and dies. Supposedly current pd codebase is at about 60 percent of that. That same code also lacks a lot of basic facilities like infinite undo and other core tools necessary for any kind of basic editing (given the nature of pd's structure it needs to exist inside the engine itself that is also responsible for stacking order). Features that have been added in pd-l2ork have added at least a couple of thousand lines of code with the externals and everything else obviously going well beyond that.</p>
</blockquote><div><br></div><div><div>Refactoring usually <i>reduces</i> code length, but the key to staying in sync with vanilla (and all projects that use it) is to refactor in small chunks, keeping the modifications focused.</div>
<div><br></div><div>For instance, it seems like there are two main concerns floating around: </div><div><br></div><div>a) multiple instances of pd</div><div>b) separating GUI from core</div><div><br></div><div>There are other suggestions like platform-specific vectorization and multi-threaded support, but if you try to do these at the same time, you reduce the chance of ever getting the code back into vanilla. They can be taken on after.</div>
<div><br></div><div><div>IMO, the best thing to do going forward for a) would be to sync up with Miller and what he netted out with last time this was discussed ( see thread: <a href="http://lists.puredata.info/pipermail/pd-dev/2013-12/019702.html">http://lists.puredata.info/pipermail/pd-dev/2013-12/019702.html</a>). It seemed like he was proposing to take a hefty chunk of the work on, or maybe if he is confident in merely the approach, someone else can have a go at it.</div>
<div><br></div><div>For b) it seems like no one really knows fully what is entailed, maybe it is something that just needs to be tried as a throw away first, with say a minimal GUI in something other than tk as proof of concept.</div>
</div><div><br></div><div>Corollary about multi-instances and multi-thread support: while I agree thinking about them together can be useful, I think the former will only make the latter easier to take on afterwards. The smaller the changes, the easier it is to verify backwards compatibilty, and to accept into vanilla.</div>
<div><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p dir="ltr"> As a result even if we prune the code and make a libpd which again implies Miller is okay with that (as in abandoning his version and building a new GUI app that interfaces with libpd)</p>
</blockquote><div><br></div><div>I don't think anyone wants this, my understanding is that the goal is to make it where libpd does even less, by first isolating pd-core and its memory usage.</div><div><br></div><div>cheers,</div>
<div>Rich</div></div></div></div>