headers
Shmuel Zeigerman | 1 Oct 2008 11:00

Re: How to change io::f_seek to use 64 bit numbers

Todor Totev wrote:
> I'd like to use (platform specific) fseek with 64-bit file offsets 
> inside io lib f_seek function.
> But it gets the lua number with luaL_optlong which truncates it to long.
> What do you suggest me to fix it?

Either patch Lua with your platform-specific fseek, or write a library.

Use luaL_optnumber rather than luaL_optlong, cast it to whatever is a 
64-bit integer type on your platform, then you'll be able to get/set 
offsets up to 2^53 bytes (assuming lua_Number is double).

--

-- 
Shmuel
Permalink | Reply | 1 comment |
headers
Florian Weimer | 1 Oct 2008 19:36
Picon

Re: Lua licensing thoughts

* Rob Hoelz:

> So if all the story is scripted in Lua, and it's under a CC license, I
> can't run it on a GPL engine?

The FSF position with regard to some bytecode interpreters (Emacs, for
instance) is that the GPL extends to the bytecode.
Permalink | Reply | 10 comments |
headers
Florian Weimer | 1 Oct 2008 19:37
Picon

Re: Lua licensing thoughts

* Mildred Ki'Lya:

> Le Sun 28/09/2008 __ 12:14 Miles Bader __ __crit:
>> CC can be more problematic.  The CC license you [er, I mean, the
>> original poster] are using is incompatible with the GNU GPL.
>
> Not only that, but this licence is far from an open source/free
> software licence. If you care about this ideal, you might want to
> change it. To be clear, when it will be released, it won't be free
> software.

Exactly, and there will be some distributions that will not include such
software.
Permalink | Reply | 1 comment |
headers
Rob Hoelz | 2 Oct 2008 00:00
Gravatar

Re: Lua licensing thoughts

Florian Weimer <fw <at> deneb.enyo.de> wrote:

> * Mildred Ki'Lya:
> 
> > Le Sun 28/09/2008 __ 12:14 Miles Bader __ __crit:
> >> CC can be more problematic.  The CC license you [er, I mean, the
> >> original poster] are using is incompatible with the GNU GPL.
> >
> > Not only that, but this licence is far from an open source/free
> > software licence. If you care about this ideal, you might want to
> > change it. To be clear, when it will be released, it won't be free
> > software.
> 
> Exactly, and there will be some distributions that will not include
> such software.

Which is *kind of* fine.  For distribution, I plan to package the
engine and some kind of installer.  The installer will be run on first
execution of the program and will automatically download the media
packs.  This should be okay, yes?

Either way, I'll talk to the other members of the team and see if they
won't consider distributing their work under the GPL.

Thanks,
-Rob
Permalink | Reply | 0 comments |
headers
Chetan Singh | 2 Oct 2008 01:35
Picon
Favicon

JavaScript to Lua compiler

Hi,

I am new to Lua and looking to compile JavaScript code to Lua so I can execute my JavaScript code in Kahlua VM on
J2ME devices. I heard there is a compiler named Fusion or something which does exactly what I am looking for
but could not find any information on it. Is this tool available or is there other tool that I can use to
covert javascript to Lua.

Thanks
Chetan
Permalink | Reply | 8 comments |
headers
Benjamin Tolputt | 2 Oct 2008 01:54
Picon
Gravatar

Re: Lua licensing thoughts

Florian Weimer wrote:
> The FSF position with regard to some bytecode interpreters (Emacs, for
> instance) is that the GPL extends to the bytecode

The reason for this is "boiler-plate" which is embedded in the
byte-code. FSF maintains (and correctly so) that when the byte-code
contains GPL'ed boiler-plate code without which it would not work, it is
a derivative of the GPL'ed code. Note that this only applies to "some"
bytecode interpreters, and these are ones that originate under the GPL
*and* have substantial "boilerplate" code embedded by the compiler.

There are a couple of things to remember:

   1. Lua is not GPL-licensed. It's license is GPL compatible, and hence
      can be included in GPL applications, but the terms it's copyright
      terms are still MIT
   2. Lua "bytecode" can originate from non-GPL compilers (obviously,
      standard "luac" comes to mind), as such the bytecode is not
      covered by GPL as "derived" by a GPL-compiler
   3. Provided the game engine being worked on could accept alternate
      bytecode, graphics, audio, etc - the GPL'd application is an
      "engine" with the Lua bytecode, sound files, etc as "content" that
      can come packaged with the GPL application as an "amalgamated
      distribution" - in other words, the content need not be GPL to
      comply with the GPL license.

It is still my strong opinion (though I am not a lawyer), that
distributing Lua bytecode with a GPL application is covered by the
amalgamation terms of the GPL license and as such one could make a GPL
game engine with alternately licensed content.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Schröder | 2 Oct 2008 01:56
Picon

Re: Lua licensing thoughts

2008/10/1 Florian Weimer <fw <at> deneb.enyo.de>:
> * Rob Hoelz:
>
>> So if all the story is scripted in Lua, and it's under a CC license, I
>> can't run it on a GPL engine?
>
> The FSF position with regard to some bytecode interpreters (Emacs, for
> instance) is that the GPL extends to the bytecode.

The GPL FAQ differs:
http://www.fsf.org/licensing/licenses/gpl-faq.html#IfInterpreterIsGPL

Best
   Martin
Permalink | Reply | 7 comments |
headers
Aidin Abedi | 2 Oct 2008 14:37
Picon

I need your help! C++ exception in coroutine Crashes.

Hello

I've embedded lua and when I call a c++ function (that throws a c++
exception) inside a coroutine my app crashes badly. Windows just says:

"Runtime Error!
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information."

I do have a c++ exception-catch outside the pcall. There is no crash
if I call the same function (that throws a exception) from inside
lua's main-thread.

This issue must have been detected before. Please help me!
I appreciate any ideas. I thank you for your time.
Permalink | Reply | 6 comments |
headers
Tim Channon | 2 Oct 2008 15:10

Unexpected behaviour

Where does argument 3 go?

tagclass = {}
tagmetatable = {__index = tagclass}
function tagclass.new (kind, args, body)
  local self = {}
	self.kind=kind
	self.args=args
	self.body=body
  setmetatable(self,tagmetatable)
  return self
end

function tagclass:show()
	print("kind",self.kind)
	print("args",self.args)
	print("body",self.body)
end

xx=tagclass:new("kindp", "argp", "bodyp")

xx:show()

kind	table: 00887f48
args	kindp
body	argp
Permalink | Reply | 3 comments |
headers
Dirk Feytons | 2 Oct 2008 15:16
Picon

Re: Unexpected behaviour

On Thu, Oct 2, 2008 at 3:10 PM, Tim Channon <tc <at> gpsl.net> wrote:
> Where does argument 3 go?
>
>
> tagclass = {}
> tagmetatable = {__index = tagclass}
> function tagclass.new (kind, args, body)
>  local self = {}
>        self.kind=kind
>        self.args=args
>        self.body=body
>  setmetatable(self,tagmetatable)
>  return self
> end
>
> function tagclass:show()
>        print("kind",self.kind)
>        print("args",self.args)
>        print("body",self.body)
> end
>
> xx=tagclass:new("kindp", "argp", "bodyp")

This is syntactic sugar for

xx=tagclass.new(tagclass, "kindp", "argp", "bodyp")

You have to call your new() like a regular function:

xx=tagclass.new("kindp", "argp", "bodyp")
(Continue reading)

Permalink | Reply | 2 comments |

Gmane