The preprocessor is not the right place for this.

If you want to omit opening Lua unless it is needed, try simply
deleting the lua open call in the module initialization function. I
think everything will still work fine. Let me know if it doesn't.

There needs to be a separate Lua state for each thread in Csound, and
the existing code implements this. The existing code also does not
create Lua states until they are actually needed, except for this one
module initialization call.

Regards,
Mike

> What do you think?
>
> tito
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Wait a minute -- by "preprocessor" you mean the bin attribute in the
CsScore tag?

Wait again -- I think you mean look for a Lua file matching a score
file, and evaluate that.

In either case, the lua_opdef calls are necessary because the actual
Lua opcodes have to be bound to a C++ Lua opcode stub which is called
by Csound.

We should talk about this more, especially since Csound6 may change
how much of this kind of thing is done.

Regards,
Mike


On Tue, Apr 10, 2012 at 12:26 PM, Tito Latini  wrote:
> Ok, I'll try it, but it was really an idea/2. The other half:
>
> perhaps (not tested) the preprocessor is useful to write opcodes
> in Lua before the parsing. For example, with 'filename.csd', eval
> `filename.lua' if it exists. Then the parser recognizes the new
> opcodes defined in the lua file without `lua_*opcall'.
>
> tito
>
> On Tue, Apr 10, 2012 at 12:15:33PM -0400, Michael Gogins wrote:
>> The preprocessor is not the right place for this.
>>
>> If you want to omit opening Lua unless it is needed, try simply
>> deleting the lua open call in the module initialization function. I
>> think everything will still work fine. Let me know if it doesn't.
>>
>> There needs to be a separate Lua state for each thread in Csound, and
>> the existing code implements this. The existing code also does not
>> create Lua states until they are actually needed, except for this one
>> module initialization call.
>>
>> Regards,
>> Mike
>>
>> > What do you think?
>> >
>> > tito
>> >
>> > ------------------------------------------------------------------------------
>> > Better than sec? Nothing is better than sec when it comes to
>> > monitoring Big Data applications. Try Boundary one-second
>> > resolution app monitoring today. Free.
>> > http://p.sf.net/sfu/Boundary-dev2dev
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

What you suggest is that will we be able to use appendOpcode to
register Lua opcodes, instead of using the Lua opcode stub.

At the moment I don't believe this would be practical, because it
assumes that LuaJIT opcodes could support callbacks from Csound
efficiently. Currently LuaJIT can handle the callbacks, but I don't
think it could handle them efficiently enough. That is one reason I
took the approach I did. The opdef opcodes set up the bindings from
the opcall opcodes, which are C/C++ callbacks and quite efficient, to
the actual Lua functions in a more efficient way than LuaJIT callbacks
would be able to do.

What is your motive here? Why kind of musical things are you hoping to
accomplish that the current setup doesn't do for you? If I knew your
use cases I could think about this better.

Regards,
Mike

On Tue, Apr 10, 2012 at 1:33 PM, Tito Latini  wrote:
> On Tue, Apr 10, 2012 at 12:52:53PM -0400, Michael Gogins wrote:
>> Wait a minute -- by "preprocessor" you mean the bin attribute in the
>> CsScore tag?
>>
>> Wait again -- I think you mean look for a Lua file matching a score
>> file, and evaluate that.
>
> No score preprocessor but `csound_pre.lex'.
>
>> In either case, the lua_opdef calls are necessary because the actual
>> Lua opcodes have to be bound to a C++ Lua opcode stub which is called
>> by Csound.
>
> In general, I know how to work `LuaCsound.cpp'.
> The idea is filename.lua or `lua_include "..."' (perhaps it is better).
> The lua file contains the code for the new opcode. We can eval it
> during the orc-preprocessing and we have the csound instance
> for appendOpcode. I'll try in the next days when I will have time.
> It is only a starting point or simply a "it works" (or "I'm wrong").
>
>> We should talk about this more, especially since Csound6 may change
>> how much of this kind of thing is done.
>
> Of course; my msg is only a trigger, however I'm weak without a test.
>
> tito
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

One of the things I've contemplated is this kind of thing where
opcodes written in other languages could be kept sort of hidden, such
that users would not see lua code, just know that there is some opcode
called foo that could be C, Lua, Java, etc.  I prefer this to seeing
code directly mixed into Csound ORC code.  Tito: is this what you were
thinking?

On Tue, Apr 10, 2012 at 6:33 PM, Tito Latini  wrote:
> On Tue, Apr 10, 2012 at 12:52:53PM -0400, Michael Gogins wrote:
>> Wait a minute -- by "preprocessor" you mean the bin attribute in the
>> CsScore tag?
>>
>> Wait again -- I think you mean look for a Lua file matching a score
>> file, and evaluate that.
>
> No score preprocessor but `csound_pre.lex'.
>
>> In either case, the lua_opdef calls are necessary because the actual
>> Lua opcodes have to be bound to a C++ Lua opcode stub which is called
>> by Csound.
>
> In general, I know how to work `LuaCsound.cpp'.
> The idea is filename.lua or `lua_include "..."' (perhaps it is better).
> The lua file contains the code for the new opcode. We can eval it
> during the orc-preprocessing and we have the csound instance
> for appendOpcode. I'll try in the next days when I will have time.
> It is only a starting point or simply a "it works" (or "I'm wrong").
>
>> We should talk about this more, especially since Csound6 may change
>> how much of this kind of thing is done.
>
> Of course; my msg is only a trigger, however I'm weak without a test.
>
> tito
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

But I don't want to hide things. I want to see them. I am serious
about this. One of the major pains in my life has been pieces that
used to work that don't work any more, and it's always some stuff in
some other file that has gone missing, or is now in a different
directory, or the protocol has changed, or something. I want
everything in one file for one piece.

Regards,
Mike

On Tue, Apr 10, 2012 at 2:03 PM, Steven Yi  wrote:
> One of the things I've contemplated is this kind of thing where
> opcodes written in other languages could be kept sort of hidden, such
> that users would not see lua code, just know that there is some opcode
> called foo that could be C, Lua, Java, etc.  I prefer this to seeing
> code directly mixed into Csound ORC code.  Tito: is this what you were
> thinking?
>
> On Tue, Apr 10, 2012 at 6:33 PM, Tito Latini  wrote:
>> On Tue, Apr 10, 2012 at 12:52:53PM -0400, Michael Gogins wrote:
>>> Wait a minute -- by "preprocessor" you mean the bin attribute in the
>>> CsScore tag?
>>>
>>> Wait again -- I think you mean look for a Lua file matching a score
>>> file, and evaluate that.
>>
>> No score preprocessor but `csound_pre.lex'.
>>
>>> In either case, the lua_opdef calls are necessary because the actual
>>> Lua opcodes have to be bound to a C++ Lua opcode stub which is called
>>> by Csound.
>>
>> In general, I know how to work `LuaCsound.cpp'.
>> The idea is filename.lua or `lua_include "..."' (perhaps it is better).
>> The lua file contains the code for the new opcode. We can eval it
>> during the orc-preprocessing and we have the csound instance
>> for appendOpcode. I'll try in the next days when I will have time.
>> It is only a starting point or simply a "it works" (or "I'm wrong").
>>
>>> We should talk about this more, especially since Csound6 may change
>>> how much of this kind of thing is done.
>>
>> Of course; my msg is only a trigger, however I'm weak without a test.
>>
>> tito
>>
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I never thought you would remove anyone's code! I'm sorry if I sounded
defensive.

I am just curious about what it is you are trying to do. So again,
what is the possibility that you see?

Regards,
Mike

On Tue, Apr 10, 2012 at 5:51 PM, Tito Latini  wrote:
> Michael Gogins wrote:
>> What is your motive here? Why kind of musical things are you hoping to
>> accomplish that the current setup doesn't do for you? If I knew your
>> use cases I could think about this better.
>
> I don't have problems because I can write external opcodes in C code.
> When I see a possibility, I propose an idea. Stop.
>
>> But I don't want to hide things. I want to see them. I am serious
>> about this. One of the major pains in my life has been pieces that
>> used to work that don't work any more, and it's always some stuff in
>> some other file that has gone missing, or is now in a different
>> directory, or the protocol has changed, or something. I want
>> everything in one file for one piece.
>
> I have never proposed an incompatible change with the old csd files.
> The idea is to add a feature and not remove your code. I appreciate
> and respect your work.
>
> Steven Yi wrote:
>> One of the things I've contemplated is this kind of thing where
>> opcodes written in other languages could be kept sort of hidden, such
>> that users would not see lua code, just know that there is some opcode
>> called foo that could be C, Lua, Java, etc.  I prefer this to seeing
>> code directly mixed into Csound ORC code.  Tito: is this what you were
>> thinking?
>
> Yes, it is the point. Perhaps a `somelang_include' and/or an init.langext
> file in INCDIR etc.
>
> tito
>
> ABEND
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net