headers
Ketmar Dark | 1 Nov 02:35
Picon
Favicon

Re: Lua is not skin deep

hello, "steve donovan" <steve.j.donovan <at> gmail.com>.

On Wed, 31 Oct 2007 15:31:51 +0200
"steve donovan" <steve.j.donovan <at> gmail.com> wrote:

> That is very cool - you are doing transforms on the AST
> representation, but the AST can be 'quoted'. I enjoyed Lisp in the
> 80s, but eventually got tired of writing programs virtually in raw
> AST.
and why you ever want to write anything in pure LISP? write your own
DSL and describe your task in this DSL...
Permalink | Reply | 1 comment |
headers
David Manura | 1 Nov 03:44
Favicon

Re: Lua is not skin deep

Asko Kauppi writes:
> The problem with the error messages is that what the eventual Lua  
> parser sees is not what the user saw.....
> ...[exp]	->	(select(exp,...))
> .....if there's something at runtime, Lua will report the function
> "select" to be involved.

We might restructure it so that the translated parts raise no, or only explicit,
errors.  Alternately, the translated code could inject extra debug information
into the source, somewhat like below.

Original:

  y = (function(x,...) print(x, ...[x]) end
      )(nil,2,3)

Translated:

  _G['ERROR: bad argument to ...[]'] = function(...) return select(...) end
  y = (function(x,...) print(x, _G['ERROR: bad argument to ...[]'](x,...)) end
      )(nil,2,3)

Result:

  $ lua test.lua
  lua: test.lua:1: bad argument #1 to 'select' (number expected, got nil)
  stack traceback:
          [C]: in function 'select'
          test.lua:1: in function 'ERROR: bad argument to ...[]'
          test.lua:2: in function <test.lua:2>
(Continue reading)

Permalink | Reply | 0 comments |
headers
steve donovan | 1 Nov 07:14
Picon

Re: Lua is not skin deep

On 11/1/07, Ketmar Dark <ketmar <at> ic.km.ua> wrote:
> and why you ever want to write anything in pure LISP? write your own
> DSL and describe your task in this DSL...
Well, I would truncate the question to  'why you ever want to write
anything in LISP?' and leave it at that ;)

Certainly Lua preprocessing (whether on the lexical or the syntax
level) is a very cool thing for DSL development, especially 'Domain
Limited Languages' where a user can't be dangerous. But I doubt that
DLL will take off as a new buzzword..

steve d.
Permalink | Reply | 0 comments |
headers
steve donovan | 1 Nov 07:41
Picon

Re: Lua is not skin deep

On 10/31/07, Asko Kauppi <askok <at> dnainternet.net> wrote:
> Let's say we have these "skins" (might be a very bad example):
>
> #...            ->      (select('#',...))
> ...[exp]        ->      (select(exp,...))

A generally tough problem. One of the less beautiful things about
generic template trickery in C++ is that the error messages reflect
the complexity of the implementation, which makes it very hard to hide
implementation details from the poor user.

This isn't very pretty, but it works:

function _call(f) return f() end

macro('pcall_assert', {'expr','msg'},
 @ _call(function()
  local result
  local res,err = pcall(function()
      result = expr
  end)
  if not res then error(msg) end
  return result
  end)  @
)

macro('fred',{'x'},@ pcall_assert(some_other_function(x),"fred failed") @)

function some_other_function(a)
	return a.x
(Continue reading)

Permalink | Reply | 4 comments |
headers
steve donovan | 1 Nov 09:28
Picon

Re: Lua is not skin deep

On 11/1/07, steve donovan <steve.j.donovan <at> gmail.com> wrote:
> This isn't very pretty, but it works:
> in particular, this method only allows one value to be returned from the
> expression.

Pardon me replying to myself! Pass #2

-- macro-defs.lua

macro('_quote',{'expr'},@function() return (expr) end@)

function _pcall_assert(callable,msg)
	local status,a1,a2,a3,a4 = pcall(callable)
	if not status then error(msg,2) end
	return a1,a2,a3,a4
end

macro('fred',{'x'},@
_pcall_assert(_quote(some_other_function(x)),"fred failed") @)

function some_other_function(a)
	return a.x
end

-- test-fred.lua
a = {x = 2}
print(fred(a))
print(fred(nil))

$ lua -lmacro -lmacro-defs test-fred.lua
(Continue reading)

Permalink | Reply | 0 comments |
headers
Niklas Frykholm | 1 Nov 13:52
Picon

Yieldable for patch locaction?

I asked this in a different thread, but did't get any answer so I'll try 
again here.

Does anyone have an alternative download address (or perhaps their own 
copy) of the yieldable for patch mentioned here:

	http://lua-users.org/wiki/YieldableForLoops

The link from the Wiki

	http://primero.ricilake.net/lua/lua-5.1.2-for.patch

isn't responding.

// Niklas
Permalink | Reply | 1 comment |
headers
Jose Marin | 1 Nov 17:59
Picon
Favicon

[tolua] How to pass or return float* ?

Hi!

I need to bind a function (using tolua, not tolua++) that has a float* as a parameter, and another that
returns a float* .

void glMultMatrixf (float *m);
float* CalcRotation(const float r);

In both cases, tolua creates float vars, and not float*, because it understand that, on the first case, 'm'
will be a value returned when calling the function in Lua. I don´t know what happes on the second case.

Using void glMultMatrixf (float m[]) doesn´t work, also.

I could use void glMultMatrixf (float m[16]), but in some functions I don´t know the size of the array. 

Any tip?

Thanks!

Jose

      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/
Permalink | Reply | 1 comment |
headers
G.H. | 2 Nov 14:13
Picon
Gravatar

Bug candidate in Lua 5.1.2 ?

Hello everyone.

I am pretty curious about this because it looks weird.
You'll see, it appears to be that table.remove() isn't
working properly in Lua 5.1.2 or, at least, it has
unpleasant "secondary effects" when modifying values
previously assigned from _different variables_ :

a = {3,7,8}
return #a
3
b = a
return #b
3
table.remove(b, 1)
return #b
2
return #a
2

I have tried in two different computers obtaining the
same results. Any ideas or teachings about this?
I hope it'd be my imagination...

Thank you in advance -- Mario
Permalink | Reply | 4 comments |
headers
Asko Kauppi | 2 Nov 14:19
Gravatar

Re: Bug candidate in Lua 5.1.2 ?


Simple.  Tables are reference type in Lua, so it's the same table, no  
matter how many names you give.

To make a copy, you need to do that yourself. And decide whether to  
do "shallow copy", "deep copy" or something in between.

-asko

G.H. kirjoitti 2.11.2007 kello 15:13:

> Hello everyone.
>
> I am pretty curious about this because it looks weird.
> You'll see, it appears to be that table.remove() isn't
> working properly in Lua 5.1.2 or, at least, it has
> unpleasant "secondary effects" when modifying values
> previously assigned from _different variables_ :
>
> a = {3,7,8}
> return #a
> 3
> b = a
> return #b
> 3
> table.remove(b, 1)
> return #b
> 2
> return #a
> 2
(Continue reading)

Permalink | Reply | 1 comment |
headers
steve donovan | 2 Nov 14:19
Picon

Re: Bug candidate in Lua 5.1.2 ?

Ah, but b and a are references to the _same table_!

Assignment merely copies references; if you want a copy, you have to
do it yourself.

steve d.

On 11/2/07, G.H. <code933k <at> gmail.com> wrote:
> Hello everyone.
>
> I am pretty curious about this because it looks weird.
> You'll see, it appears to be that table.remove() isn't
> working properly in Lua 5.1.2 or, at least, it has
> unpleasant "secondary effects" when modifying values
> previously assigned from _different variables_ :
>
> a = {3,7,8}
> return #a
> 3
> b = a
> return #b
> 3
> table.remove(b, 1)
> return #b
> 2
> return #a
> 2
>
> I have tried in two different computers obtaining the
> same results. Any ideas or teachings about this?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane