44 replies to this topic

[martin509]

Lua is not the most flexible of languages when it comes to low-level stuff. So, CC coders, how about you tell the world about how you optimize your programs to run cleanly and efficiently?
I'll start:
I made an arcade conversion of Hurdles, and in order for it to restart, when the game exited its final line was os.reboot().
Then, I made a startup program to run hurdles again on the monitor. I thus worked around having the program directly use the monitor in its code, and saved a ton of hassles.
So anyway post your Lua tricks here!

[Cloudy]

Uh... if you think Lua isn't flexible you're doing it wrong. Look into metatables.

[SuicidalSTDz]

martin509, on 25 March 2013 - 11:35 AM, said:

when the game exited its final line was os.reboot().

That is a horrible trick. os.reboot() should not be used to restart a program since it forces all tasks to stop suddenly.. Use a while loop or something else.

[Sammich Lord]

SuicidalSTDz, on 25 March 2013 - 01:26 PM, said:

martin509, on 25 March 2013 - 11:35 AM, said:

when the game exited its final line was os.reboot().

That is a horrible trick. os.reboot() should not be used to restart a program since it forces all tasks to stop suddenly.. Use a while loop or something else.

Or have everything you want in a function then just call the function when you need to.

[SuicidalSTDz]

Sammich Lord, on 25 March 2013 - 02:06 PM, said:

SuicidalSTDz, on 25 March 2013 - 01:26 PM, said:

martin509, on 25 March 2013 - 11:35 AM, said:

when the game exited its final line was os.reboot().

That is a horrible trick. os.reboot() should not be used to restart a program since it forces all tasks to stop suddenly.. Use a while loop or something else.

Or have everything you want in a function then just call the function when you need to.

P'much. Restarting a computer to loop a program is the WORST thing you can do. Alas, we all make mistakes.

[Bubba]

I think one of my favorite Lua idioms is the following bit of code:

for item=1,15 do
  local condition = item<=10 and "Less than or equal to 10" or item==11 and "Equal to 11" or "Greater than 11"
  print(condition)
end

I've only ever seen condition statements like this in Java, and even there it's not as simple or powerful as what Lua has (unless I'm missing something pretty huge from Java).

Edit: Oh and also this thread has most of the lua tricks that I find useful, although metatables are missing.

[theoriginalbit]

Bubba, on 25 March 2013 - 09:50 PM, said:

I've only ever seen condition statements like this in Java

The ternary operator is in many languages.

Bubba, on 25 March 2013 - 09:50 PM, said:

and even there it's not as simple or powerful as what Lua has (unless I'm missing something pretty huge from Java).

it is just as powerful, the only restriction they put on it (that Lua does not) is that it must be used in an assignment statement, as opposed to Lua where it can be used in any way, however I have never used it in any way other than assignment statements in Lua.

[Bubba]

I guess I'd never seen that in C++ or PHP That was years ago though and I didn't get too far into those so I might just have forgotten about it. Nothing like making noob programming statements on a forum devoted to programming

[theoriginalbit]

Bubba, on 26 March 2013 - 05:43 AM, said:

I guess I'd never seen that in C++ or PHP

I know for a fact that C++ has the ternary operator... pretty sure php has it..... *googles* ........................ yep PHP has the ternary operator too link

[faubiguy]

One little trick I found for ComputerCraft is that os.pullEvent (or os.pullEventRaw) can be used as an iterator function in for loops. So for any code that loops for each event, you can use the code

for event, p1, p2 in os.pullEvent do -- Add other parameter variables as needed
  -- Do stuff with event/params
end

There's not much difference from a while true do loop that calls os.pullEvent each time, but I think this looks a bit nicer.

[Kingdaro]

That's actually really neat.

[theoriginalbit]

Here is a nice bit of code that I have that replaces this statement
Old long way:

if not someVariable then
  error( 'You did not give me the parameter I wanted', 2)
end

New way:

assert( someVariable, 'You did not give me the parameter I wanted', 2)

Code that does this:

_G.assert = function(condition, errMsg, level)
  if not condition then
	error(errMsg, (tonumber(level) or 1) + 1)
  end
  return condition
end

A usage example:

views = {}
function registerKey(screen, key, text, xPos, yPos)
  -- validate the parameters
  assert(views[screen], 'A screen with the key \''..screen..'\' does not exist', 2)
  assert(not views[screen][key], 'A key with the key \''..screen..'\' already exists', 2)
  assert(type(text) == 'string', 'Invalid parameter: expected text to be a string, got '..type(text), 2)
  assert(type(xPos) == 'number', 'Invalid parameter: expected xPos to be a number, got '..type(xPos), 2)

  -- do stuff here
end

The example using the old way

local views = {}
function registerKey(screen, key, text, xPos, yPos)
  -- validate the parameters
  if not views[screen] then
	error( 'A screen with the key \''..screen..'\' does not exist', 2)
  end
  if views[screen][key] then
	error('A key with the key \''..screen..'\' already exists', 2)
  end
  if type(text) ~= 'string' then
	error('Invalid parameter: expected text to be a string, got '..type(text), 2)
  end
  if type(xPos) ~= 'number' then
	error('Invalid parameter: expected xPos to be a number, got '..type(xPos), 2)
  end

  -- do stuff here
end

[Kingdaro]

Honestly, I've only seen people here who did it the "old" way, haha.

[faubiguy]

Not everyone here does it the "old" way
Snippet from my menu code:

function menu.addOption(menuTable, name, func)
  assert(type(menuTable) == "table", "menu.addOption: menu argument must be table")
  assert(type(name) == "string", "menu.addOption: name argument must be string")
  assert(type(func) == "function", "menu.addOption: function argument must be function")
  assert(#menuTable == 3, "menu.addOption: menu argument must be of form {string, table, table}")
  assert(type(menuTable[1]) == "string", "menu.addOption: menu argument must be of form {string, table, table}")
  assert(type(menuTable[2]) == "table", "menu.addOption: menu argument must be of form {string, table, table}")
  assert(type(menuTable[3]) == "table", "menu.addOption: menu argument must be of form {string, table, table}")
  menuTable[2][#menuTable[2] + 1] = name
  menuTable[3][#menuTable[3] + 1] = func
  return menuTable
end

Edit: This is default by the way, no extra code used to add assert.

[remiX]

Bubba, on 25 March 2013 - 09:50 PM, said:

I think one of my favorite Lua idioms is the following bit of code:

for item=1,15 do
  local condition = item<=10 and "Less than or equal to 10" or item==11 and "Equal to 11" or "Greater than 11"
  print(condition)
end

I've only ever seen condition statements like this in Java, and even there it's not as simple or powerful as what Lua has (unless I'm missing something pretty huge from Java).

Edit: Oh and also this thread has most of the lua tricks that I find useful, although metatables are missing.

PHP way:

<?php
	for ($i=1; $i <= 15; $i++) {
   		echo $i.' - '.($i < 11 ? 'Less than or equal to 10' : ($i == 11 ? 'Equal to 11' : 'Greater than 11')).'<br>';
	}
?>

[Bubba]

remiX, on 27 March 2013 - 12:39 AM, said:

Bubba, on 25 March 2013 - 09:50 PM, said:

I think one of my favorite Lua idioms is the following bit of code:

for item=1,15 do
  local condition = item<=10 and "Less than or equal to 10" or item==11 and "Equal to 11" or "Greater than 11"
  print(condition)
end

I've only ever seen condition statements like this in Java, and even there it's not as simple or powerful as what Lua has (unless I'm missing something pretty huge from Java).

Edit: Oh and also this thread has most of the lua tricks that I find useful, although metatables are missing.

PHP way:

<?php
	for ($i=1; $i <= 15; $i++) {
   		echo $i.' - '.($i < 11 ? 'Less than or equal to 10' : ($i == 11 ? 'Equal to 11' : 'Greater than 11')).'<br>';
	}
?>

Yup. TOB already corrected my unfortunate lack of knowledge there

[theoriginalbit]

faubiguy, on 26 March 2013 - 07:44 PM, said:

Not everyone here does it the "old" way />
Snippet from my menu code:

function menu.addOption(menuTable, name, func)
  assert(type(menuTable) == "table", "menu.addOption: menu argument must be table")
  assert(type(name) == "string", "menu.addOption: name argument must be string")
  assert(type(func) == "function", "menu.addOption: function argument must be function")
  assert(#menuTable == 3, "menu.addOption: menu argument must be of form {string, table, table}")
  assert(type(menuTable[1]) == "string", "menu.addOption: menu argument must be of form {string, table, table}")
  assert(type(menuTable[2]) == "table", "menu.addOption: menu argument must be of form {string, table, table}")
  assert(type(menuTable[3]) == "table", "menu.addOption: menu argument must be of form {string, table, table}")
  menuTable[2][#menuTable[2] + 1] = name
  menuTable[3][#menuTable[3] + 1] = func
  return menuTable
end

Edit: This is default by the way, no extra code used to add assert.

Only problem with this way is if they call your function wrong then the problem will be shown in your code and they blame you. With my function to override assert the throw back (level) means you can blame them not your code.

[theoriginalbit]

Kingdaro, on 26 March 2013 - 07:13 PM, said:

Honestly, I've only seen people here who did it the "old" way, haha.

And that's why I posted this trick to improve their code

[MudkipTheEpic]

Lol, I've never thought of erroring as blaming. XD

[theoriginalbit]

MudkipTheEpic, on 27 March 2013 - 03:19 AM, said:

Lol, I've never thought of erroring as blaming. XD

How many times have you seen people posting on people's programs saying they are getting an error from the code, but in fact the problem was caused by them not using the code right. I have seen it heaps. To me that is blaming.