espertus / blockly-lua Goto Github PK

In the file value_block.js the variable args[j][1] is cloned when it is a Blockly.FieldDropdown.
In my tests args[j][1].clone(); always retuned the error Uncaught TypeError: args[j][1].clone is not a function
Any attempts to clone it manually or via Json didn't worked.

In the android version there is a clone function which is missing in the javascript version. To bypass this a new object can be generated with the constructor var dd=new Blockly.FieldDropdown(args[j][1].menuGenerator_,args[j][1].changeHandler_);.

Is it possible for a block to have a drop down, that lets say says

• all
• other

and when other is selected they can drag a variable and connected it to the block, but when all is selected the default value is used...

I think if this is possible it could make turtle.drop, turtle.refuel, and turtle.transferTo a lot simpler to use for the newbies.

I feel that blockly-lua should not allow users to name variables and functions the same... I obviously know that there is no way to validate naming variables the same as you'd be unaware if they're wanting to assign a new number or create a new variable (maybe new blocks, one creates, one assigns?) but I definitely think you should have some validation to stop them doing this (FYI Lua allows it, especially since there is no type checking in Lua)

local foo = "bar"
local foo() -- the above variable no longer exists
  return "bar"
end

also having a blacklist of system functions that cannot have a variable or function with the same name as would be good, such as read

Note: I feel that if there were to be a change in the way variables worked, i.e. a block to create and assign a variable and a different block to reassign it later could also greatly help with #5 as you could also take into consideration things such as scope (which has the added bonus of teaching them about scope) for example if they tried this

local bar = " world"

local function foo()
  local bar = "hello"
  write(bar)
end

foo()
print(bar)

it would be allowed due to scope, however there could be a "warning" saying that they have a naming conflict and only the one inside the function will be used when in the function.
However in contrast if they tried this, it would obviously have to error telling them of a name conflict

local function foo()
  local bar = "hello"
  local bar = " world"
  local foo = "!" -- this is allowed though foo isn't defined when this function is compiled ;P
end

foo()

Some functions within Lua/ComputerCraft require variables in order to work (as I'm sure you know) and error when they are not provided... As such I think when the Lua button is pressed to generate code, any functions that specify they require arguments should light up red (?) and specify that they require these arguments before allowing the person to see generated code.

I feel this is a good direction to go in as it will eliminate those who may think that blockly-lua does this check and immediately release their program without testing (believe me, those n00bs do exist!)

A quick list of some turtle functions that need arguments and error without them

• turtle.select
• turtle.getItemCount
• turtle.getItemSpace
• turtle.compareTo
• turtle.transferTo

Lua is a weird language, it can actually return multiple values from functions as individual return values like so

local function foo()
  local bar = 5
  return bar, "hello", "world"
end

Which when called like so means that you only gain one of the values

local v1 = foo()

As such to pickup all values you must either do

local v = { foo() }

or

local v1, v2, v3 = foo()

I think adding the ability to do this in blockly-lua could be handy, especially when starting to build event sensitive programs.

This is probably the most complex of all my suggestions to implement, but here goes with the suggestion

I think that a complete overhaul of the generator would be handy in order to promote better coding habits, especially since this is a learning tool. The main coding habit that I'm referring to is localisation of variables and functions so as to not pollute the environment, also in Lua local variables are way more efficient due to being stored in registers, instead of the heap.

The main difficulty of implementing this is that local variables must be defined before they're referenced, for example

local output = "Hello world"

local function foo()
  bar() -- this will error, bar has not been defined
end

local function bar()
  print(output) -- this works, output is defined
end

foo() -- this works, foo is defined

would error the moment it tried to call bar within foo. this is because at compile time there is no local variable/name bar, so it is setup to look in the global space therefore never seeing the local bar function... it also causes a problem if there was a global variable or function named bar, as it would call that instead.

The code generator would need to know these rules and then be able to identify order and output. It would also get a little more complicated when they attempted recursion of cyclic recursion, as this would error

local function a()
  a() -- a isn't defined
end

a()

and so would this (due to the previous rule)

local function a()
  b() -- b isn't defined
end

local function b()
  a()
end

a()

the only way to solve these problems are like so

local a
function a()
  a()
end
a()

and this

local a, b

function a()
  b()
end

function b()
  a()
end

a()

hope all that made sense.

In regards to when specifying the return type of a block, for example

this.setOutput(true, 'Boolean')

is this enforced in anyway when it comes to Blockly-lua?

The main reason that I ask is because of turtle.getFuelLevel returning a number when fuel is enabled, but when fuel is disabled it will return "unlimited" which as you can see is a string.

Oh also while I'm here, this also relates to #2, most of the turtle functions now days in the latest few CC versions return 2 values, the first being success of operation, the second being the reason it failed (when it does).

Hi

I guess a "\n" is missing at end of repeat statement in generators/lua/loops.js:

var code = 'for ' + loopVar + '= 1, ' + repeats + ' do\n' + branch + 'end';
to replace by:
var code = 'for ' + loopVar + '= 1, ' + repeats + ' do\n' + branch + 'end\n';

Thx

Again this comes down to how odd Lua is, but with Lua a conditional can be anything, not just a boolean. false and nil both are resolved to false any other value resolves to true.

if "hello" then
  print("This line will always print")
else
  print("You'll never see this line")
end

As such any logic and loops may need to be updated to reflect this... Your thoughts are appreciated since this is primarily a "feature" to Lua and not general programming.

Oh also the ternary I would like to point out the following problem in Lua that you may want to allow for in some way... The ternary operator does not exist in Lua, they've provided us with the following logic [condition] and [value-if-true] or [value-if-false] however since this logic (which is the closest we can ever get to a ternary) falls under the rules of boolean logic it fails when the value-if-true is false or nil, basic example

print("hello" and false or "h")

the above code will print h because the true value was false.

In Lua it is possible to have vararg functions, I'm sure you should know what they are as they're in multiple languages, I think blockly-lua having support would be good.

examples

local args = {...} -- getting all the runtime args of the program

local function foo(...) -- vararg function
  local args = {...} -- varargs of the function
  print(...) -- print is a vararg function it will concat all these together and output them
end

-- calling vararg functions is not a static amount
foo("bar")
foo("bar", "hello", "world")