Luerl - Lua in Erlang: Interface Definition - Erlang Programming

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Luerl - Lua in Erlang: Interface Definition
Received-SPF: pass (google.com: domain of erlang-questions-boun...@erlang.org designates 192.121.151.104 as permitted sender) client-ip=192.121.151.104;
Date: Wed, 22 Feb 2012 02:04:46 -0000 (GMT)
From: Robert Virding <robert.vird...@erlang-solutions.com>
To: Henning Diedrich <hd2...@eonblast.com>
Message-ID: <aeb64036-52d8-45a0-a0c5-1f736b497d14@knuth>
In-Reply-To: <4F430DFF.5030...@eonblast.com>
MIME-Version: 1.0
Cc: Lua mailing list <lu...@lists.lua.org>,
 Erlang Questions <erlang-questi...@erlang.org>
Subject: Re: [erlang-questions] Luerl - Lua in Erlang: Interface Definition
Precedence: list
Content-Type: multipart/mixed; boundary="===============7673780819250303123=="
Errors-To: erlang-questions-boun...@erlang.org
Sender: erlang-questions-boun...@erlang.org

--===============7673780819250303123==
Content-Type: multipart/alternative;
 boundary="=_f8036a44-a1c8-406d-bbd0-fccbd2fce7d3"

--=_f8036a44-a1c8-406d-bbd0-fccbd2fce7d3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi, 

Most of the difference is just in terminology and from which side you view =
it, from erlang or Lua. For example, for me loading means actually getting =
it into the sytem not just compiling it into a runnable form. And I view th=
ese functions from the erlang side. I will also admit that I am a bit hazy =
as to how the C-side functions work, it seems easier within the language. 

'eval' and 'do' work well for me, though I do wonder if we need 'evalfile' =
and 'dofile'. I prefer 'compile' instead of 'load' as this is what is does.=
 'call' is fine. What is the difference between 'call' and 'do'? For creati=
ng and destroying state I would prefer either 'new' / 'delete' or 'start' /=
 'stop' depending on whether you want to view the state as just data or as =
some form of concurrent activity, a separate process in Erlang. 

I would use 'encode' / 'decode' for converting between an Erlang representa=
tion and an internal luerl representation. So: 

luerl:encode(Erlang, State) -> {Luerl,State}. 
luerl:decode(Luerl, State) -> Erlang. 


Encoding will modify the state as tables only exist within that state. If i=
t not done this way then there is no need of these functions as the represe=
ntation is the same and this conversion will be done in the other interface=
 functions. So for example a Lua strings are Erlang binaries and tables wil=
l are a list of tuple pairs, 

Lua {['a']=3D97,['b']=3D98,10,20,30} <=3D=3D> Erlang [{1.0,10.0},{2.0,20.0}=
,{3.0,30.0},{<<"a">>,97.0},{<<"b">>,98.0}] 

Putting Lua tables into the state is also the only way to handle the differ=
ence in the meaning of equality between Lua and Erlang. 

For errors I have been thinking in the Erlang way. The only function to act=
ually return an error value would be 'compile' (or 'load') which would beco=
me 

luerl:compile(String) -> {ok,Chunk} | {error,Reason}. 

All errors during the Lua execution, unless they are caught internally, wou=
ld result in Erlang exceptions which would handled in the normal Erlang way=
, either by catching it or having the Erlang process die. 

The result returned from Lua and the arguments to a call would be a list of=
 Erlang values. If no values are returned the list is empty otherwise it wo=
uld contain same number of elements as in the 'return' statement. 

Those are my thoughts for the moment. Now I will go back and try and code t=
he idiosyncrasies of string.sub. 

Robert 

----- Original Message -----


Hi Robert, 

To allow for String|Chunk, the chunks returned from ps/1 would have to be w=
rapped to be distinguishable from the Strings. I think 'functiondef' could =
be the right choice. 

For the names, I'd propose to maybe stay closer to the Lua language functio=
n names and its C interface [1]. 

But at any rate, to maybe decide for one of "do" and "eval" to 1) return ba=
re results 2) return {Result, State}. Rather than making this dependent on =
whether State was handed in or not as a parameter? 

Since Lua uses dofile() both in the Lua language and the C interface, (and =
since of course neither case returns state), the "do" functions look earmar=
ked for returning the simple, bare bones Result. However ... somehow "eval"=
 is a better fit for a function that is expected to return something. 

Lua's C interface uses "load" for parsing-only: load, loadfile, lua_load [2=
], lua_loadfile, lua_loadstring, lua_loadbuffer. 

This could be an alternative to wrapping the chunks: for load, in Lua "the =
string mode controls whether the chunk can be text or binary (that is, a pr=
ecompiled chunk). It may be the string "b" (only binary chunks), "t" (only =
text chunks), or "bt" (both binary and text). The default is "bt". [5] 

The type that the loads return is 'function': "If there are no syntactic er=
rors, returns the compiled chunk as a function; otherwise, returns nil plus=
 the error message." --- therefore, the right chunk wrapper could be { func=
tiondef, ... }, instead of compiled chunks being lists as outermost type. 

Execution of pre-parsed/compiled chunks is "call": pcall, xpcall, lua_call,=
 lua_pcall [3], and lua_pcallk. 

State is created and destroyed by lua_newstate and lua_close. 

There is no "eval" in Lua. 

So here's my proposal: 

luerl:eval(String|Chunk[, State]) -> Result. 
luerl:evalfile(PathString[, State]) -> Result. 

luerl:do(String|Chunk[, State]) -> {Result, NewState}. 
luerl:dofile(PathString[, State]) -> {Result, NewState}. 

luerl:newstate() -> State. 
luerl:close(State) -> ok. 

luerl:load(String) -> {ok, Chunk}. 
luerl:loadfile(PathString) -> {ok, Chunk}. 
luerl:call(Chunk[, State][, ErlParamList()]) -> {Result, NewState}. 

luerl:tolua(list()) -> LuerlTermsList(). 
luerl:toerlang(LuerlTermsList()) -> list(). 

This would be somewhat in keeping with Lua's naming. 

I am unclear about error state returns. Simply in the Result I guess? 

Relative to your proposal that is: 
luerl:eval(String|Chunk) -> Result. =3D> luerl:eval(String|Chunk[, State]) =
-> Result. 
luerl:dofile(String) -> Result. =3D> luerl:dofile(PathString[, State]) -> {=
Result,State}. 
luerl:new() -> State. (currently luerl:init() -> State.) =3D>luerl:newstate=
() -> State. 
luerl:eval(String|Chunk, State) -> {Result,NewState}. =3D> luerl:eval(Strin=
g|Chunk, State) -> {Result,NewState}. 
luerl:dofile(String, State) -> {Result,NewState}. =3D> same 
luerl:compile(String) -> {ok,Chunk}. =3D> luerl:load(String) -> {ok,Chunk}.=
 

Beyond that, I had thought with 'interface' you would be addressing the dir=
ect interchange of values between Erlang and Lua. I'd be all for making the=
 collection of tables in the Lua state accessible and writable, directly, s=
omehow navigating into it using a key structure. And if possible, vice vers=
a: giving Lua direct access to Erlang state. 

Best, 
Henning 


[1] http://www.lua.org/manual/5.2/manual.html#4.8 

[2] One note I like, in the description of the C function lua_load : "The s=
ource argument gives a name to the chunk, which is used for error messages =
and in debug information (see =C2=A74.9)." http://www.lua.org/manual/5.2/ma=
nual.html#lua_load - http://www.lua.org/manual/5.2/manual.html#2.3 

[3] When you use xpcall or lua_pcall, you may give a message handler to be =
called in case of errors. This function is called with the original error m=
essage and returns a new error message. It is called before the error unwin=
ds the stack, so that it can gather more information about the error, for i=
nstance by inspecting the stack and creating a stack traceback. This messag=
e handler is still protected by the protected call; so, an error inside the=
 message handler will call the message handler again. If this loop goes on,=
 Lua breaks it and returns an appropriate message. - 
http://www.lua.org/manual/5.2/manual.html#2.3 

[4] In Lua (not the C interface), dofile does not run in protected mode. ht=
tp://www.lua.org/manual/5.2/manual.html#6.1 

[5] http://www.lua.org/manual/5.2/manual.html#6.1 



On 2/20/12 10:59 PM, Robert Virding wrote: 

<blockquote>

[snip] I had planned something along the lines of: 

luerl:eval(String|Chunk) -> Result. 
luerl:dofile(String) -> Result. 

Basic simple interface which initialises a state and evaluates the chunk St=
ring in it returning a list of return values (if any). For example luer:eva=
l("local t=3D{'a','b'} return t[1],t[2]") will return [<<"a">>,<<"b">>]. lu=
erl:dofile/1 is not really necessary. 

luerl:new() -> State. 
luerl:eval(String|Chunk, State) -> {Result,NewState}. 

luerl:dofile(String, State) -> {Result,NewState}. 
luerl:compile(String) -> {ok,Chunk}. 

A more complex interface. luerl:new/0 creates an initial state. luerl:eval/=
2 will evaluate a chunk in a state and return the values and the updated st=
ate. This state can be reused to evaluate new chunks. Again luerl:dofile/2 =
is not really necessary. luerl:compile(String) compiles the string into an =
internal form ready to run in eval/1/2. 

Result is always a list of return values which may be empty if the chunk do=
es not do a return with values. For data types: 

Lua strings are binaries 
Lua numbers are floats 
Lua tables are orddicts (property lists) of key-value tuples 
Lua true, false, nil are just the atoms true, false, nil 

Anyway something along those lines. It might be nice to have a function cal=
l wrapper which would allow you a more erlang like way of calling a luerl f=
unction. 

Robert 

----- Original Message -----

<blockquote>
Regarding interface function names: 

I wonder what logic Luerl's names of do and eval follow: 

dofile/1, like eval/1, returns a pragmatic Ret 

while do/2 returns {String, State} 

Since you are exporting ps/1, there should maybe be a dochunk/2? 

And /1, too? 

Or should it maybe be evalchunk/1, dochunk/2 (the /2s with State as second =
parameter)? 

Here are some relevant functions from Lua's C interface. 


<blockquote>
luaL_dofile 

[-0, +?, m] 
int luaL_dofile (lua_State *L, const char *filename); 
Loads and runs the given file. It is defined as the following macro: 

(luaL_loadfile(L, filename) || lua_pcall(L, 0, LUA_MULTRET, 0)) 
It returns false if there are no errors or true in case of errors. 

luaL_dostring 

[-0, +?, =E2=80=93] 
int luaL_dostring (lua_State *L, const char *str); 
Loads and runs the given string. It is defined as the following macro: 

(luaL_loadstring(L, str) || lua_pcall(L, 0, LUA_MULTRET, 0)) 
It returns false if there are no errors or true in case of errors. 

luaL_loadstring 

[-0, +1, =E2=80=93] 
int luaL_loadstring (lua_State *L, const char *s); 
Loads a string as a Lua chunk. This function uses lua_load to load the chun=
k in the zero-terminated string s. 

This function returns the same results as lua_load. 

Also as lua_load, this function only loads the chunk; it does not run it. 

luaL_newstate 

[-0, +0, =E2=80=93] 
lua_State *luaL_newstate (void); 
Creates a new Lua state. It calls lua_newstate with an allocator based on t=
he standard C realloc function and then sets a panic function (see =C2=A74.=
6) that prints an error message to the standard error output in case of fat=
al errors. 

Returns the new state, or NULL if there is a memory allocation error. 



Source: http://www.lua.org/manual/5.2/manual.html 

</blockquote>


</blockquote>


_______________________________________________ 
erlang-questions mailing list 
erlang-questi...@erlang.org 
http://erlang.org/mailman/listinfo/erlang-questions 

</blockquote>


--=_f8036a44-a1c8-406d-bbd0-fccbd2fce7d3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'=
><font size=3D"3">Hi,<br><br></font><font size=3D"3">Most of the difference=
 is just in terminology and from which side you view it, from erlang or Lua=
. For example, for me loading means actually getting it into the sytem not =
just compiling it into a runnable form. And I view these functions from the=
 erlang side. I will also admit that I am a bit hazy as to how the C-side f=
unctions work, it seems easier within the language.<br><br>'eval' and 'do' =
work well for me, though I do wonder if we need 'evalfile' and 'dofile'. I =
prefer 'compile' instead of 'load' as this is what is does. 'call' is fine.=
 What is the difference between 'call' and 'do'? For creating and destroyin=
g state I would prefer either 'new' / 'delete' or 'start' / 'stop' dependin=
g on whether you want to view the state as just data or as some form of con=
current activity, a separate process in Erlang.<br><br>I would use 'encode'=
 / 'decode' for converting between an Erlang representation and an internal=
 luerl representation. So:<br><br>luerl:encode(Erlang, State) -&gt; {Luerl,=
State}.<br>luerl:decode(Luerl, State) -&gt; Erlang.</font><br><br><div styl=
e=3D"text-align: left;">Encoding will modify the state as tables only exist=
 within that state. If it not done this way then there is no need of these =
functions as the representation is the same and this conversion will be don=
e in the other interface functions. So for example a Lua strings are Erlang=
 binaries and tables will are a list of tuple pairs,<br><br>Lua {['a']=3D97=
,['b']=3D98,10,20,30} &lt;=3D=3D&gt; Erlang [{1.0,10.0},{2.0,20.0},{3.0,30.=
0},{&lt;&lt;"a"&gt;&gt;,97.0},{&lt;&lt;"b"&gt;&gt;,98.0}]<br><br>Putting Lu=
a tables into the state is also the only way to handle the difference in th=
e meaning of equality between Lua and Erlang.<br><br>For errors I have been=
 thinking in the Erlang way. The only function to actually return an error =
value would be 'compile' (or 'load') which would become<br><br>luerl:compil=
e(String) -&gt; {ok,Chunk} | {error,Reason}.<br><br>All errors during the L=
ua execution, unless they are caught internally, would result in Erlang exc=
eptions which would handled in the normal Erlang way, either by catching it=
 or having the Erlang process die.<br><br>The result returned from Lua and =
the arguments to a call would be a list of Erlang values. If no values are =
returned the list is empty otherwise it would contain same number of elemen=
ts as in the 'return' statement.<br><br>Those are my thoughts for the momen=
t. Now I will go back and try and code the idiosyncrasies of string.sub.<br=
><br>Robert <br></div><br><hr id=3D"zwchr"><blockquote style=3D"border-left=
:2px solid rgb(16, 16, 255);margin-left:5px;padding-left:5px;color:#000;fon=
t-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetic=
a,Arial,sans-serif;font-size:12pt;">




    Hi Robert,<br>
    <br>
    To allow for String|Chunk, the chunks returned from ps/1 would have
    to be wrapped to be distinguishable from the Strings. I think
    'functiondef' could be the right choice.<br>
    <br>
    For the names, I'd propose to maybe stay closer to the Lua language
    function names and its C interface [1]. <br>
    <br>
    But at any rate, to maybe decide for one of "do" and "eval" to 1)
    return bare results 2) return {Result, State}. Rather than making
    this dependent on whether State was handed in or not as a parameter?<br=
>
    <br>
    Since Lua uses dofile() both in the Lua language and the C
    interface, (and since of course neither case returns state), the
    "do" functions look earmarked for returning the simple, bare bones
    Result. However ... somehow "eval" is a better fit for a function
    that is expected to return something.<br>
    <br>
    Lua's C interface uses "load" for parsing-only: load, loadfile,
    lua_load [2], lua_loadfile, lua_loadstring, lua_loadbuffer.<br>
    <br>
    This could be an alternative to wrapping the chunks: for load, in
    Lua <i>"the string mode controls whether the chunk can be text or
      binary (that is, a precompiled chunk). It may be the string "b"
      (only binary chunks), "t" (only text chunks), or "bt" (both binary
      and text). The default is "bt". </i>[5]<br>
    <br>
    The type that the loads return is 'function': <i>"If there are no
      syntactic errors, returns the compiled chunk as a function;
      otherwise, returns nil plus the error message." --- </i>therefore,
    the right chunk wrapper could be { functiondef, ... }, instead of
    compiled chunks being lists as outermost type.<br>
    <br>
    Execution of pre-parsed/compiled chunks is "call": pcall, xpcall,
    lua_call, lua_pcall [3],&nbsp; and lua_pcallk. <br>
    <br>
    State is created and destroyed by lua_newstate and lua_close.<br>
    <br>
    There is no "eval" in Lua. <br>
    <br>
    So here's my proposal:<br>
    <br>
    luerl:eval(String|Chunk[, State]) -&gt; Result.<br>
    luerl:evalfile(PathString[, State]) -&gt; Result.<br>
    <br>
    luerl:do(String|Chunk[, State]) -&gt; {Result, NewState}.<br>
    luerl:dofile(PathString[, State]) -&gt; {Result, NewState}.<br>
    <br>
    luerl:newstate() -&gt; State.<br>
    luerl:close(State) -&gt; ok.<br>
    <br>
    luerl:load(String) -&gt; {ok, Chunk}.<br>
    luerl:loadfile(PathString) -&gt; {ok, Chunk}.<br>
    luerl:call(Chunk[, State][, ErlParamList()]) -&gt; {Result,
    NewState}.<br>
    <br>
    luerl:tolua(list()) -&gt; LuerlTermsList().<br>
    luerl:toerlang(LuerlTermsList()) -&gt; list().<br>
    <br>
    This would be somewhat in keeping with Lua's naming.<br>
    <br>
    I am unclear about error state returns. Simply in the Result I
    guess?<br>
    <br>
    Relative to your proposal that is:<br>
    luerl:eval(String|Chunk) -&gt; Result. =3D&gt;
    luerl:eval(String|Chunk[, State]) -&gt; Result.<br>
    luerl:dofile(String) -&gt; Result. =3D&gt; luerl:dofile(PathString[,
    State]) -&gt; {Result,State}.<br>
    luerl:new() -&gt; State. (currently luerl:init() -&gt; State.)
    =3D&gt;luerl:newstate() -&gt; State.<br>
    luerl:eval(String|Chunk, State) -&gt; {Result,NewState}. =3D&gt;
    luerl:eval(String|Chunk, State) -&gt; {Result,NewState}.
    <div style=3D"text-align: left;">luerl:dofile(String, State) -&gt;
      {Result,NewState}. =3D&gt; same<br>
    </div>
    luerl:compile(String) -&gt; {ok,Chunk}. =3D&gt; luerl:load(String)
    -&gt; {ok,Chunk}.<br>
    <br>
    Beyond that, I had thought with 'interface' you would be addressing
    the direct interchange of values between Erlang and Lua. I'd be all
    for making the collection of tables in the Lua state accessible and
    writable, directly, somehow navigating into it using a key
    structure. And if possible, vice versa: giving Lua direct access to
    Erlang state.<br>
    <br>
    Best,<br>
    Henning<br>
    <br>
    <br>
    [1] <a class=3D"moz-txt-link-freetext" href=3D"http://www.lua.org/manua=
l/5.2/manual.html#4.8" target=3D"_blank">http://www.lua.org/manual/5.2/manu=
al.html#4.8</a><br>
    <br>
    [2] <i>One note I like, in the description of the C function
      lua_load : "The source argument gives a name to the chunk, which
      is used for error messages and in debug information (see =C2=A74.9)."=
 </i><a class=3D"moz-txt-link-freetext" href=3D"http://www.lua.org/manual/5=
.2/manual.html#lua_load" target=3D"_blank">http://www.lua.org/manual/5.2/ma=
nual.html#lua_load</a>
    - <a class=3D"moz-txt-link-freetext" href=3D"http://www.lua.org/manual/=
5.2/manual.html#2.3" target=3D"_blank">http://www.lua.org/manual/5.2/manual=
.html#2.3</a><br>
    <br>
    [3] <i>When you use xpcall or lua_pcall, you may give a message
      handler to be called in case of errors. This function is called
      with the original error message and returns a new error message.
      It is called before the error unwinds the stack, so that it can
      gather more information about the error, for instance by
      inspecting the stack and creating a stack traceback. This message
      handler is still protected by the protected call; so, an error
      inside the message handler will call the message handler again. If
      this loop goes on, Lua breaks it and returns an appropriate
      message.</i> - <br>
    <a class=3D"moz-txt-link-freetext" href=3D"http://www.lua.org/manual/5.=
2/manual.html#2.3" target=3D"_blank">http://www.lua.org/manual/5.2/manual.h=
tml#2.3</a><br>
    <br>
    [4] In Lua (not the C interface), dofile does not run in protected
    mode. <a class=3D"moz-txt-link-freetext" href=3D"http://www.lua.org/man=
ual/5.2/manual.html#6.1" target=3D"_blank">http://www.lua.org/manual/5.2/ma=
nual.html#6.1</a><br>
    <br>
    [5] <a class=3D"moz-txt-link-freetext" href=3D"http://www.lua.org/manua=
l/5.2/manual.html#6.1" target=3D"_blank">http://www.lua.org/manual/5.2/manu=
al.html#6.1</a><br>
    <br>
    <br>
    <br>
    On 2/20/12 10:59 PM, Robert Virding wrote:<br>
    <blockquote cite=3D"mid:a6f24fc1-9075-4a31-bebd-5bc8812ac444@knuth">
      <div style=3D"font-family: Times New Roman; font-size: 12pt; color:
        #000000">[snip] I had planned something along the lines of:<br>
        <br>
        luerl:eval(String|Chunk) -&gt; Result.<br>
        luerl:dofile(String) -&gt; Result.<br>
        <br>
        Basic simple interface which initialises a state and evaluates
        the chunk String in it returning a list of return values (if
        any). For example luer:eval("local t=3D{'a','b'} return
        t[1],t[2]") will return
        [&lt;&lt;"a"&gt;&gt;,&lt;&lt;"b"&gt;&gt;]. luerl:dofile/1 is not
        really necessary.<br>
        <br>
        luerl:new() -&gt; State.<br>
        luerl:eval(String|Chunk, State) -&gt; {Result,NewState}.<br>
        <div style=3D"text-align: left;">luerl:dofile(String, State) -&gt;
          {Result,NewState}.<br>
        </div>
        luerl:compile(String) -&gt; {ok,Chunk}.<br>
        <br>
        A more complex interface. luerl:new/0 creates an initial state.
        luerl:eval/2 will evaluate a chunk in a state and return the
        values and the updated state. This state can be reused to
        evaluate new chunks. Again luerl:dofile/2 is not really
        necessary. luerl:compile(String) compiles the string into an
        internal form ready to run in eval/1/2.<br>
        <br>
        Result is always a list of return values which may be empty if
        the chunk does not do a return with values. For data types:<br>
        <br>
        Lua strings are binaries<br>
        Lua numbers are floats<br>
        Lua tables are orddicts (property lists) of key-value tuples<br>
        Lua true, false, nil are just the atoms true, false, nil<br>
        <br>
        Anyway something along those lines. It might be nice to have a
        function call wrapper which would allow you a more erlang like
        way of calling a luerl function.<br>
        <br>
        Robert<br>
        <br>
        <hr id=3D"zwchr">
        <blockquote style=3D"border-left:2px solid rgb(16, 16,
255);margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-st=
yle:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font=
-size:12pt;">
          Regarding interface function names:<br>
          <br>
          I wonder what logic Luerl's names of do and eval follow:<br>
          <br>
          dofile/1, like eval/1, returns a pragmatic Ret <br>
          <br>
          while do/2 returns {String, State}<br>
          <br>
          Since you are exporting ps/1, there should maybe be a
          dochunk/2? <br>
          <br>
          And /1, too? <br>
          <br>
          Or should it maybe be evalchunk/1, dochunk/2 (the /2s with
          State as second parameter)?<br>
          <br>
          Here are some relevant functions from Lua's C interface.<br>
          <br>
          <blockquote><b>luaL_dofile</b><br>
            <br>
            [-0, +?, m]<br>
            int luaL_dofile (lua_State *L, const char *filename);<br>
            Loads and runs the given file. It is defined as the
            following macro:<br>
            <br>
            &nbsp;&nbsp;&nbsp;&nbsp; (luaL_loadfile(L, filename) || lua_pca=
ll(L, 0,
            LUA_MULTRET, 0))<br>
            It returns false if there are no errors or true in case of
            errors.<br>
            <br>
            <b>luaL_dostring</b><br>
            <br>
            [-0, +?, =E2=80=93]<br>
            int luaL_dostring (lua_State *L, const char *str);<br>
            Loads and runs the given string. It is defined as the
            following macro:<br>
            <br>
            &nbsp;&nbsp;&nbsp;&nbsp; (luaL_loadstring(L, str) || lua_pcall(=
L, 0,
            LUA_MULTRET, 0))<br>
            It returns false if there are no errors or true in case of
            errors.<br>
            <br>
            <b>luaL_loadstring</b><br>
            <br>
            [-0, +1, =E2=80=93]<br>
            int luaL_loadstring (lua_State *L, const char *s);<br>
            Loads a string as a Lua chunk. This function uses lua_load
            to load the chunk in the zero-terminated string s.<br>
            <br>
            This function returns the same results as lua_load.<br>
            <br>
            Also as lua_load, this function only loads the chunk; it
            does not run it.<br>
            <br>
            <b>luaL_newstate</b><br>
            <br>
            [-0, +0, =E2=80=93]<br>
            lua_State *luaL_newstate (void);<br>
            Creates a new Lua state. It calls lua_newstate with an
            allocator based on the standard C realloc function and then
            sets a panic function (see =C2=A74.6) that prints an error
            message to the standard error output in case of fatal
            errors.<br>
            <br>
            Returns the new state, or NULL if there is a memory
            allocation error.<br>
          </blockquote>
          <br>
          Source: <a class=3D"moz-txt-link-freetext" href=3D"http://www.lua=
.org/manual/5.2/manual.html" target=3D"_blank">http://www.lua.org/manual/5.=
2/manual.html</a><br>
        </blockquote>
        <br>
      </div>
    </blockquote>
    <br>


<br>_______________________________________________<br>erlang-questions mai=
ling list<br>erlang-questi...@erlang.org<br>http://erlang.org/mailman/listi=
nfo/erlang-questions<br></blockquote><br></div></body></html>
--=_f8036a44-a1c8-406d-bbd0-fccbd2fce7d3--

--===============7673780819250303123==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

--===============7673780819250303123==--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
