search

agraef / pd-lua

Lua bindings for Pd, updated for Lua 5.3+
https://agraef.github.io/pd-lua/
GNU General Public License v2.0
47 stars 10 forks source link

documentation updates #12

Closed porres closed 1 year ago

porres commented 1 year ago

the documentation surely needs revision and I can work on it.

It used to include the old [import] file and missed a proper [declare]

closes https://github.com/agraef/pd-lua/issues/11

closes https://github.com/agraef/pd-lua/issues/13

closes https://github.com/agraef/pd-lua/issues/14

agraef commented 1 year ago

Rev. 6fd409c256339c40f7e2dad365691e494e21b77b also reverts rev. 437f279e3bb4cdfd318664e089ad4d1ebb223ed2 which I just committed today. I did this because since https://github.com/pure-data/pure-data/commit/9d785174584c57d7cbc875bd2a0633d24c7edbcd the m_pd.h in vanilla specifically advises to not use sys_vgui any more and use pdgui_vmess instead. I assumed that this means that sys_vgui is deprecated for some reason and that sys_vgui will go away soon. Do you know what this is all about? Is it safe to just keep to sys_vgui in spite of the warning in m_pd.h?

porres commented 1 year ago

Do you know what this is all about?

about big plans in the GUI rewrite, making it more portable so people can use other front-end GUIs and stuff

Is it safe to just keep to sys_vgui in spite of the warning in m_pd.h?

It is for now, there's still a long road ahead, but it should hurt to comply with the new changes

agraef commented 1 year ago

About all those logpost calls. Yeah, I don't know how these ended up in there, they must have come from upstream, and that part of the repo history seems to be lost for good unfortunately. I guess that I just assumed that post() was on the chopping block as well, when it was just error() that got removed from m_pd.h at some point (for good reasons I guess). Otherwise I probably would have removed them already.

agraef commented 1 year ago

but it should hurt to comply with the new changes

Do you mean it should hurt or that it shouldn't? ;-)

In the former case it's ok to revert the pdgui_vmess change, while we should probably keep it in if it's the latter.

agraef commented 1 year ago

Other than that the PR looks good to me. Thanks for taking the time to sift through all those examples!

porres commented 1 year ago

oops, that it shouldn't :)

agraef commented 1 year ago

Anyway, I'll just assume that we're still good with sys_vgui for now, and merge as is. We can always reapply rev. 437f279e3bb4cdfd318664e089ad4d1ebb223ed2 if the need arises in the future.

agraef commented 1 year ago

I shall also remove the silly comment in line 94+95 that crept in in rev. 82d22639899773dda8f89a13d12ddcf9ff1bbf10 (brain fart on my side, I mixed up post() and error() again).

agraef commented 1 year ago

Done. Shall we pull this over to plugdata right away, or are more changes on the way?

porres commented 1 year ago

I was under the impression he was using your repository as a submodule... in his PR to ELSE he added it as a submodule to me and I'm actually having a hard time as I wanted to update the submodule according to your merge but I couldn't :)

No more documentation updates from me right now, a proper revision will take me much more time, let's save it for next.

But I was wondering if I could also have some "#ifndef ELSE" so I can also print (distributed as part of ELSE) when loading the object. Other than this, it all looks good to go. Of course as I spend more time eploring this thing I'll have more ideas I guess...

porres commented 1 year ago

I was wondering if I could also have some "#ifndef ELSE"

I wouldn't know how to do this :) maybe @timothyschoen could help me... I assume I need to pass this to the file via the makefile or something, right?

agraef commented 1 year ago

Yes, something like make CPPFLAGS=-DELSE will do the trick, that make variable is empty by default and can thus be used to add any preprocessor options that you want/need.

And yes, we already have PLUGDATA as a defined symbol in there, a few more #ifdef ELSE can't hurt, as long as the source isn't riddled with them. :)

agraef commented 1 year ago

I was under the impression he was using your repository as a submodule...

Yes, but a submodule is always at a specific commit, so it doesn't update on its own. You have to explicitly update (git pull) the submodule in your working copy and then commit the new subhash in the parent project. You can watch me do it right now: https://github.com/plugdata-team/plugdata/pull/314

porres commented 1 year ago

Yes, something like make CPPFLAGS=-DELSE will do the trick,

awesome, it worked :) I guess we need to post the same message for plugdata as well, I'm sending a PR soon