CHDKPTP: Send command to cam and get a table of results, is that possible?

  • 6 Replies
  • 1238 Views
Advertisements
Hello, I digged into LUA during the last days and was impressed how open the language is. The possibility to have a function return multiple results is very convenient.

Now I wonder if it is possible to send multiple "return cmdxyz()" via CHDKPTP to the cams and get multiple results back?

Like this:

local results = con:execwait('return get_config_value(102) get_config_value(103))

Is there a way to do that?

Thanks! Martin


Okay, sorry, already found out how!

It is not returned as table but as single values, absolutely normal, i am the geek!

Code: [Select]
status,val1,val2=lcon:execwait([[return get_config_value(1), get_config_value(2]])   

*

Offline reyalp

  • ******
  • 11335
If you want a Lua table you can just throw a table around your values like:
Code: [Select]
status,val=lcon:execwait([[return {get_config_value(1), get_config_value(2)}]])

Or use the rets option to execwait (see chdku.lua)
Code: [Select]
con 4> !t={};status=con:execwait([[return get_config_value(1), get_config_value(2)]],{rets=t}) ; return t
={
 [1]={
  value=1,
  type="return",
  script_id=5,
  subtype="integer",
 },
 [2]={
  value=1,
  type="return",
  script_id=5,
  subtype="integer",
 },
}
Note that the returns are the entire message, so if the value isn't a simple type you'd need to unserialize it. You can also pass a function to rets.
Code: [Select]
con 7> !t={};status=con:execwait([[return get_config_value(1), get_config_value(2)]],{rets=function(msg) table.insert(t,
util.unserialize(msg.value)) return true end }) ; return t
={
 [1]=1,
 [2]=1,
}

The final (chdkptp side local) return t in the above examples are just to display value.
Don't forget what the H stands for.

Wow! Lua is a really amazing script language. And the possibility to use it more or less as if the camera was a part of the CPU, that is so really crazy.

Now that I got a glimpse at LUA I really have to say that I also get a glimpse of what can NOT be done when sticking to BASIC. I don't know BASIC for CHDK, but I know as Visual Basic and some other derivates. So I can't imagine it will be completely different for CHDK.

I must say that LUA really is a very neat thing, although I had several time I had some typos which were hard to find because there is no compiler that detects such. And the fact that one has not to declare the variables in any way is also a big error potential.

But it is that fast to develop with that. I suppose it is also capable of executing self-generated code, right?


Now that I got a glimpse at LUA I really have to say that I also get a glimpse of what can NOT be done when sticking to BASIC. I don't know BASIC for CHDK, but I know as Visual Basic and some other derivates. So I can't imagine it will be completely different for CHDK.
uBASIC is closer to the BASIC language from the early 1980's.   Visual Basic actually contains some nice obect oriented type features where visual objects can have properties and methods attached to them.  uBASIC is just a very simple scripting language - the single character variable names alone should have shown you that.

Quote
I must say that LUA really is a very neat thing, although I had several time I had some typos which were hard to find because there is no compiler that detects such. And the fact that one has not to declare the variables in any way is also a big error potential.
As I understand it, there is actually a compiler (of sorts) that converts your code into an intermediate "p-code" type format.  It does a far amount of error detection although its far from perfect.   Just try writing anything complicated in uBASIC by comparison. 

The discussion about static vs dynamic types in software and the value of strict explicit definition has been going on a long as there have been computer languages.  Your preference (and mine) are duly noted but I'm sure others might disagree. To be noted,  Lua does seem to do type checking once a variable has been instantiated.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 11335
I must say that LUA really is a very neat thing, although I had several time I had some typos which were hard to find because there is no compiler that detects such.
Lua is compiled, so some classes of errors are detected at compile time. For example, if you do

=foo(

You will get a compile error, because the ( is unclosed.

If you do

=foo()

you get a runtime error, because foo hasn't been defined and is therefor nil rather than a function.
Quote
And the fact that one has not to declare the variables in any way is also a big error potential.
Yes, this is a major source of runtime errors, and questionable choice in the language design. It is possible to use metamethods to enforce declaring variable before use, but that would require you to run all your code with an additional lua module and have some runtime performance impact. I have some code for this I should port to CHDK and chdkptp some day...
Don't forget what the H stands for.

It is possible to use metamethods to enforce declaring variable before use, but that would require you to run all your code with an additional lua module and have some runtime performance impact. I have some code for this I should port to CHDK and chdkptp some day...
Sounds like that would be really handy during development as long as there is a way to untangle things on a "released" script.    Now what constitutes a "released" script is another question ......
Ported :   A1200    SD940   G10    Powershot N    G16

 

Related Topics