[L2Ork-dev] Feedback on GSOC draft proposal

[Jonathan Wilkes]

Hm, wrt m_imp.h-- replace "internal implementation header file" with
"unstable private header file." (While that appears to be the original
intended meaning, it's unclear what that really means nowadays-- e.g.,
I don't think `struct _class` has ever changed much, if at all.)

-Jonathan

On Sun, Apr 11, 2021 at 3:23 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>
> On Sun, Apr 11, 2021 at 2:51 PM Tanmay Gujar <tanmaygujar999 at gmail.com> wrote:
> >
> > Hello and thanks for the feedback!
> > I'll make the changes to the draft so that the REPL would use a socket connection instead.
> >
> > As for the delete function I was working with the info presented here Pd Internal messages.
>
> Don't use that.
>
> First, skim this:
>
> https://git.purrdata.net/jwilkes/purr-data#core-pd-notes
>
> It has some helpful information about type and file prefixes.
>
> As for Pd's interface:
>
> m_pd.h: the *official* public interface (Purr Data's m_pd.h isn't in
> lockstep with Pd Vanilla's m_pd.h, but most things seem to load and
> work properly.)
>
> m_imp.h: the internal implementation header file
>
> g_canvas.h: stuff to do with visualizing canvases as well as glist bookkeeping
>
> g_all_guis.h: header for common (though quite complicated, esoteric,
> and confusing) interface for most of the core UI widgets
>
> s_stuff.h: misc
>
> I say "official" because libpd reaches into not only some of those
> private headers above, but also internal functions in order to give
> control of DSP scheduling over to the program that's linking to it.
>
> -Jonathan
>
> >
> > Best,
> > Tanmay
> >
> > On Sun, Apr 11, 2021 at 11:41 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
> >>
> >> On Sun, Apr 11, 2021 at 6:25 AM Tanmay Gujar <tanmaygujar999 at gmail.com> wrote:
> >> >
> >> > Hello!
> >> >
> >> > I have slightly changed my approach towards building the Terminal REPL. Majorly, I plan to build on top of libpd instead of working with a socket connection to pd.
> >>
> >> You can do that, but we don't currently ship libpd with Purr Data.
> >> (It's in the emscripten branch but even there most of the Web
> >> App<->Backend communication doesn't use it.)
> >>
> >> Furthermore, the socket connection would work for both for a "-nogui"
> >> console-based REPL *and* for opening up a REPL somewhere in the GUI
> >> (say, a chat window in the Pd Window, or possibly in a canvas window,
> >> too.)
> >>
> >> >
> >> > Over the past few days I have been working on a prototype of the same (available at https://github.com/tgujar/pd-REPL). It is by no means complete and I am still working on it. However, it has allowed me to work out some pd specific issues in implementing the REPL. I have documented these in the Inference section in the README.
> >>
> >> Interesting!
> >>
> >> I'm not sure what you mean by this: "No delete function in Pd Internal
> >> Messages." There is glist_delete for removing an object from a canvas
> >> and freeing it. Internally it uses gobj_delete which simply calls the
> >> class destructor. glist_delete is in g_canvas.h. So if you just add
> >> something like an x_repl.c and x_repl.h to the core you can easily
> >> access that function.
> >>
> >> -Jonathan
> >>
> >> >
> >> > Finally, apologies for being late, I have submitted my draft proposal and would love to have some feedback on it.
> >> >
> >> > Best,
> >> > Tanmay
> >> > _______________________________________________
> >> > L2Ork-dev mailing list
> >> > L2Ork-dev at disis.music.vt.edu
> >> > https://disis.music.vt.edu/listinfo/l2ork-dev
> >> _______________________________________________
> >> L2Ork-dev mailing list
> >> L2Ork-dev at disis.music.vt.edu
> >> https://disis.music.vt.edu/listinfo/l2ork-dev
> >
> > _______________________________________________
> > L2Ork-dev mailing list
> > L2Ork-dev at disis.music.vt.edu
> > https://disis.music.vt.edu/listinfo/l2ork-dev