So I agree this is good:

-lib lua [import lua]

Then it seems that it would be nice if the projects were either:

pdlua pdtcl pdhaskell

or:

luapd tclpd haskellpd

How about the first one?

.hc

On Mar 13, 2008, at 2:39 PM, Claude Heiland-Allen wrote:

Hans-Christoph Steiner wrote:

...

XXX

lua.pd_linux

^^ this is what I use. The project as a whole is called 'pdlua' but the external for Pd is called 'lua', like '-lib lua' and [lua].

...

tcl.pd_linux haskell.pd_linux

^^ this is probably what I will use if I ever resume work on my Haskell external, or maybe 'ghc.pd_linux' if it depends on that Haskell implementation.

The extra 'pd' in the other alternative are redundant.

...

Any perferred name? I don't think I have a strong preference of any name, but I do think there should be a simple, standard naming scheme.

Remove redundant 'pd's.

Claude

------------------------------------------------------------------------ ----

Access to computers should be unlimited and total. - the hacker ethic

On Mar 13, 2008, at 3:07 PM, mescalinum@gmail.com wrote:

Hans-Christoph Steiner ha scritto:

...

Hey,

Now that we have a number of loaders, I'd like to figure out a standard way of naming the libraries so that they are easy to organize and load. Currently, there are these arrangments:

pdXXX

pdlua.pd_linux pdtcl.pd_linux pdhaskell.pd_linux [import pdtcl]

XXXpd

luapd.pd_linux tclpd.pd_linux haskellpd.pd_linux [import tclpd]

XXX

lua.pd_linux tcl.pd_linux haskell.pd_linux [import tcl]

for me it's ok either "tclpd" or "pdtcl". I believe calling it just "tcl" would lead to confusion, since Tcl is already a library used by Pd.

if you happen to rename tclpd to pdtcl, please rename also the occurrences of tclpd inside the source code to pdtcl.

-- Federico Ferri

Using the "pd" afterwards means that they will sort alphabetically nicely. So how about this for the standard:

lua.pd_linux [import lua] project name: luapd

tcl.pd_linux [import tcl] project name: tclpd

Also, what about having a 'loaders' section of SVN? Either 'trunk/ loaders' or 'trunk/externals/loaders'? Then perhaps we don't need the 'pd' in the folder name:

trunk/loaders/clr trunk/loaders/hex trunk/loaders/libdir trunk/loaders/lua trunk/loaders/pd trunk/loaders/tcl

.hc

------------------------------------------------------------------------ ----

¡El pueblo unido jamás será vencido!

what exactly *is* the lua loader? is it a wrapper? or a library? I was confused in the beginning bcause I thought the "thing" was named pdlua, but the "thing" was loaded with lib- lua (so I thought it *is* a library, but named like lua, the language itself? hmm..) marius.

Frank Barknecht wrote:

Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

...

Any perferred name? I don't think I have a strong preference of any name, but I do think there should be a simple, standard naming scheme.

May I throw in another one: As loaders are a bit different than externals, maybe a "loader" pre- or suffix would be good, like lua_loader.pd_linux or loader_lua.pd_linux. That way, [lua] would still be possible.

I also don't have a strong preference for any of the suggestions, but I agree that consistent naming can be useful.

Ciao

Albert Graef wrote:

Frank Barknecht wrote:

...

May I throw in another one: As loaders are a bit different than externals,

Uhm, did I miss anything? In which way is a "loader" different from an external?

A loader-external adds a hook into Pd's loader (the bit that searches for files to load when an object of unknown class is instantiated). This hook can do anything, but most commonly it adds support for classes written in languages other than (already compiled) C or .pd text patches.

A "loader" is a subset of an external, any compiled code loaded by Pd is an external, but some externals can use the loader API.

In that it loads another interpreter? Is there a special new API for this kind of things?

Yes, a simple one: there is a function typedef (for the loader hook functionality) and a function to add a hook to the list. I forget the exact names, they're in m_pd.h if you have a new enough Pd.

I just want to know as I'm maintaining the Pd-Faust and -Q interfaces, and I'm always looking for ways to make them work better...

In my experience trying to use Haskell in Pd didn't work so well, partly because it was compiled. Lua, being interpreted, worked much better.

Albert

Hope this helps,

Claude

Hallo, Albert Graef hat gesagt: // Albert Graef wrote:

Claude Heiland-Allen wrote:

...

Yes, a simple one: there is a function typedef (for the loader hook functionality) and a function to add a hook to the list. I forget the exact names, they're in m_pd.h if you have a new enough Pd.

You mean this? (From your Lua external.)

/* defined in pd/src/s_loader.c but not in any header file... */ typedef int (*loader_t)(t_canvas *, char *); void sys_register_loader(loader_t loader);

This looks like it may be useful for Pd/Q, too. I guess I'll have to dive into the sources to see how it works, or is it documented somewhere?

...

In my experience trying to use Haskell in Pd didn't work so well, partly because it was compiled. Lua, being interpreted, worked much better.

Yeah, the nice thing about interpreted languages is that they allow you to change the code on the fly which is great for live coding.

This point however is a bit tricky with loaders, see the difference between the loader functionality in pdlua and the "luax" objectclass.

Ciao

On Fri, 14 Mar 2008, Albert Graef wrote:

In Pd/Q this is done differently; there's only one main script which defines all the Q objects in a patch (which are in fact just Q functions), but this script can be reloaded dynamically through a special "q" receiver. This operation is a bit on the heavy side, but in Q you can also create new functions at runtime, so with a little preparation you can also change the behaviour of objects written in Q by just sending them Pd messages encoding Q functions, for instance.

Sounds a lot like GridFlow and the loading of ~/.gridflow_startup.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada