WebService

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

WebService

Daniel Ventura de Oliveira

Is there a way to create a WebService in Lua to be consumed by a C# application?

Sorry if someone has asked this question before.

 

Daniel Ventura

 

Reply | Threaded
Open this post in threaded view
|

Re: WebService

Tomás Guisasola-2
Is there a way to create a WebService in Lua to be consumed by a C# application?
	Sure!  We have some in use by a couple of applications.
We used CGILua and LuaSOAP (which uses lxp).  I think there is an
example of a simple SOAP server in the distribution.  We added code
to create the discovery and wsdl automatically, but I am not sure it
was commited to the CVS repository at LuaForge.

	Regards,
		Tomás
Reply | Threaded
Open this post in threaded view
|

J2ME Implementation of Lua?

Jeremy Irish
Greetings,

Our new project at Wherigo.com implements Lua as part of our game engine. It currently runs on Pocket PC and on the Garmin Colorado. We have a small but growing list of authors creating real-world GPS-enabled games on the Wherigo platform.

We're at a crossroads. We're looking at porting Wherigo to Java since many mobile applications run Java. We dismissed the iPhone since they exclude any scripting languages as part of their accepted programs. Instead, we're looking at Android and phones like the Nokia N95 since they have GPS and support J2ME and don't have such restrictions.

The challenge is that Lua doesn't have a "real" port to Java. There have been some attempts at porting Lua to Java before (LuaJava, Kahlua, etc.) or at least attempts at providing an interop, but we're interested in a full port of Lua to Java. Is there any interest in the broader community to use Lua in a J2ME or Java environment?

Basically at this time I'm just gauging interest. If we can show a broader adoption of Lua in Java it would make sense to commit resources to doing a full port, especially if we can "pass on" the code to a strong community base to manage it once it is done. We'd also be looking to an advisory group to make sure that the code being generated has been adequately tested to ensure that the port implements Lua properly.

Thanks for your feedback! If you could also indicate what you would use the port for, if you have interest, it would help in the decision-making process.

Cheers,

Jeremy Irish
President & CEO, Groundspeak
http://www.groundspeak.com





Reply | Threaded
Open this post in threaded view
|

Re: J2ME Implementation of Lua?

Stefan Sandberg
Why port lua to java in the first place, and not just run lua itself, why bridge using another language?

lua should run without much fuss on symbians like n95, especially with the posix libraries..

Jeremy Irish wrote:
Greetings,

Our new project at Wherigo.com implements Lua as part of our game engine. It currently runs on Pocket PC and on the Garmin Colorado. We have a small but growing list of authors creating real-world GPS-enabled games on the Wherigo platform.

We're at a crossroads. We're looking at porting Wherigo to Java since many mobile applications run Java. We dismissed the iPhone since they exclude any scripting languages as part of their accepted programs. Instead, we're looking at Android and phones like the Nokia N95 since they have GPS and support J2ME and don't have such restrictions.

The challenge is that Lua doesn't have a "real" port to Java. There have been some attempts at porting Lua to Java before (LuaJava, Kahlua, etc.) or at least attempts at providing an interop, but we're interested in a full port of Lua to Java. Is there any interest in the broader community to use Lua in a J2ME or Java environment?

Basically at this time I'm just gauging interest. If we can show a broader adoption of Lua in Java it would make sense to commit resources to doing a full port, especially if we can "pass on" the code to a strong community base to manage it once it is done. We'd also be looking to an advisory group to make sure that the code being generated has been adequately tested to ensure that the port implements Lua properly.

Thanks for your feedback! If you could also indicate what you would use the port for, if you have interest, it would help in the decision-making process.

Cheers,

Jeremy Irish
President & CEO, Groundspeak
http://www.groundspeak.com






Reply | Threaded
Open this post in threaded view
|

RE: WebService

Daniel Ventura de Oliveira
In reply to this post by Tomás Guisasola-2

Daniel Ventura


> Is there a way to create a WebService in Lua to be consumed by a C# application?

>>Sure!  We have some in use by a couple of applications.
>>We used CGILua and LuaSOAP (which uses lxp).  I think there is an
>>example of a simple SOAP server in the distribution.  We added code

I've founded this http://lua-users.org/lists/lua-l/2006-02/msg00671.html
This email talks about gSOUP, but as I read, this only works for C/C++.
Do you know something for C#?

>>to create the discovery and wsdl automatically, but I am not sure it
>>Was commited to the CVS repository at LuaForge.

        Regards,
                Tomás


Reply | Threaded
Open this post in threaded view
|

RE: J2ME Implementation of Lua?

Paul Hudson-2
In reply to this post by Stefan Sandberg
[Paging David Jones, would Mr Jones please pick up the white courtesy phone?
:)]

One reason might be the signing/certification hoops you need to go through
to run native code.

There's also the Blackberry, on which applications can only be in Java.

-----Original Message-----
From: [hidden email]
[[hidden email]] On Behalf Of Stefan Sandberg
Sent: 08 April 2008 21:04
To: Lua list
Subject: Re: J2ME Implementation of Lua?

Why port lua to java in the first place, and not just run lua itself, 
why bridge using another language?

lua should run without much fuss on symbians like n95, especially with 
the posix libraries..

Jeremy Irish wrote:
> Greetings,
>
> Our new project at Wherigo.com implements Lua as part of our game engine.
It currently runs on Pocket PC and on the Garmin Colorado. We have a small
but growing list of authors creating real-world GPS-enabled games on the
Wherigo platform.
>
> We're at a crossroads. We're looking at porting Wherigo to Java since many
mobile applications run Java. We dismissed the iPhone since they exclude any
scripting languages as part of their accepted programs. Instead, we're
looking at Android and phones like the Nokia N95 since they have GPS and
support J2ME and don't have such restrictions.
>
> The challenge is that Lua doesn't have a "real" port to Java. There have
been some attempts at porting Lua to Java before (LuaJava, Kahlua, etc.) or
at least attempts at providing an interop, but we're interested in a full
port of Lua to Java. Is there any interest in the broader community to use
Lua in a J2ME or Java environment?
>
> Basically at this time I'm just gauging interest. If we can show a broader
adoption of Lua in Java it would make sense to commit resources to doing a
full port, especially if we can "pass on" the code to a strong community
base to manage it once it is done. We'd also be looking to an advisory group
to make sure that the code being generated has been adequately tested to
ensure that the port implements Lua properly.
>
> Thanks for your feedback! If you could also indicate what you would use
the port for, if you have interest, it would help in the decision-making
process.
>
> Cheers,
>
> Jeremy Irish
> President & CEO, Groundspeak
> http://www.groundspeak.com
>
>
>
>
>   



No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.519 / Virus Database: 269.22.9/1364 - Release Date: 07/04/2008
18:38
 

No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.519 / Virus Database: 269.22.9/1364 - Release Date: 07/04/2008
18:38
 


Reply | Threaded
Open this post in threaded view
|

Re: J2ME Implementation of Lua?

Kristofer Karlsson
In reply to this post by Jeremy Irish
Hi, I am the developer of Kahlua, so my post may be biased.

As far as I know, Kahlua is currently the only pure Java port of Lua.
JavaLua is really just a wrapper to interface with standard Lua, which
means it won't work on J2ME.
Recently, Kahlua got full support for coroutines which means it now
has complete support of the lua core.
The only things that are missing now is a compiler and some of the
basic libraries.

The reason that some are missing are obvious: io and os don't have the
same correspondence in J2ME.
Others are simply tricky to do - String pattern matching / formatting.
(Though work is being done there too.)

If you decide to go for a full port yourself, perhaps Kahlua would be
an adequate starting point - I would personally welcome all useful
additions to it!

I would however still argue that Kahlua is useful already as it is,
since you rarely need to (or want to, given the input system!) type
Lua code directly on the mobile phone which means that you don't
really need a compiler built in.

Cheers,
Kristofer

On Tue, Apr 8, 2008 at 9:44 PM, Jeremy Irish <[hidden email]> wrote:
> Greetings,
>
>  Our new project at Wherigo.com implements Lua as part of our game engine. It currently runs on Pocket PC and on the Garmin Colorado. We have a small but growing list of authors creating real-world GPS-enabled games on the Wherigo platform.
>
>  We're at a crossroads. We're looking at porting Wherigo to Java since many mobile applications run Java. We dismissed the iPhone since they exclude any scripting languages as part of their accepted programs. Instead, we're looking at Android and phones like the Nokia N95 since they have GPS and support J2ME and don't have such restrictions.
>
>  The challenge is that Lua doesn't have a "real" port to Java. There have been some attempts at porting Lua to Java before (LuaJava, Kahlua, etc.) or at least attempts at providing an interop, but we're interested in a full port of Lua to Java. Is there any interest in the broader community to use Lua in a J2ME or Java environment?
>
>  Basically at this time I'm just gauging interest. If we can show a broader adoption of Lua in Java it would make sense to commit resources to doing a full port, especially if we can "pass on" the code to a strong community base to manage it once it is done. We'd also be looking to an advisory group to make sure that the code being generated has been adequately tested to ensure that the port implements Lua properly.
>
>  Thanks for your feedback! If you could also indicate what you would use the port for, if you have interest, it would help in the decision-making process.
>
>  Cheers,
>
>  Jeremy Irish
>  President & CEO, Groundspeak
>  http://www.groundspeak.com
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: J2ME Implementation of Lua?

David Given
In reply to this post by Jeremy Irish
Jeremy Irish wrote:
[...]
> The challenge is that Lua doesn't have a "real" port to Java. There have been some attempts at porting Lua to Java before (LuaJava, Kahlua, etc.) or at least attempts at providing an interop, but we're interested in a full port of Lua to Java. Is there any interest in the broader community to use Lua in a J2ME or Java environment?

Do you want it to run *on* Java (so the interpreter is written in Java),
or do you want it to run *with* Java (so the interpreter is written in C
with bridge methods to allow you to call it from Java)? It shouldn't
make a difference to the API either way.

Personally, I'd quite like something rather different: a Lua *compiler*
that generates Java source code. On a lot of the platforms I develop for
(GWT, Android) I'm basically stuck with Java, which while it does have
some nice features, doesn't really have the nice features I want...

-- 
ââââ ïïïïïïïïïïïïïï âââââ http://www.cowlark.com âââââ
â "I have always wished for my computer to be as easy to use as my
â telephone; my wish has come true because I can no longer figure out
â how to use my telephone." --- Bjarne Stroustrup

Attachment: signature.asc
Description: OpenPGP digital signature

Reply | Threaded
Open this post in threaded view
|

Re: J2ME Implementation of Lua?

Gerardo Horvilleur
What are the features you're looking for?

On Tue, Apr 8, 2008 at 4:44 PM, David Given <[hidden email]> wrote:
> Jeremy Irish wrote:
>  [...]
>  > The challenge is that Lua doesn't have a "real" port to Java. There have been some attempts at porting Lua to Java before (LuaJava, Kahlua, etc.) or at least attempts at providing an interop, but we're interested in a full port of Lua to Java. Is there any interest in the broader community to use Lua in a J2ME or Java environment?
>
>  Do you want it to run *on* Java (so the interpreter is written in Java),
>  or do you want it to run *with* Java (so the interpreter is written in C
>  with bridge methods to allow you to call it from Java)? It shouldn't
>  make a difference to the API either way.
>
>  Personally, I'd quite like something rather different: a Lua *compiler*
>  that generates Java source code. On a lot of the platforms I develop for
>  (GWT, Android) I'm basically stuck with Java, which while it does have
>  some nice features, doesn't really have the nice features I want...
>
>  --
>  ┌─── dg@cowlark.com ───── http://www.cowlark.com ─────
>  │ "I have always wished for my computer to be as easy to use as my
>  │ telephone; my wish has come true because I can no longer figure out
>  │ how to use my telephone." --- Bjarne Stroustrup
>
>



-- 
Gerardo Horvilleur
[hidden email]
5813-0830

Reply | Threaded
Open this post in threaded view
|

Re: J2ME Implementation of Lua?

David Jones-2
In reply to this post by Paul Hudson-2

On 8 Apr 2008, at 21:17, Paul Hudson wrote:
[Paging David Jones, would Mr Jones please pick up the white courtesy phone?
:)]

Yeah yeah. :)

Ravenbrook were engaged by a now bust company to do essentially a complete port of Lua 5.1 to the J2ME MIDP 2.0 CLDC 1.1 platform. Compiler, coroutines, string matching, the works. We did it, they went bust, now the technology lies buried in some faceless company basement. *sigh*

Cheers,
 drj

Reply | Threaded
Open this post in threaded view
|

Re: J2ME Implementation of Lua?

Gerardo Horvilleur
Interesting. How large was it? (memory footprint/jar file size). Did
it fit on most J2ME enabled phones?

On Tue, Apr 8, 2008 at 5:09 PM, David Jones <[hidden email]> wrote:
>
>  On 8 Apr 2008, at 21:17, Paul Hudson wrote:
>
> > [Paging David Jones, would Mr Jones please pick up the white courtesy
> phone?
> > :)]
> >
>
>  Yeah yeah. :)
>
>  Ravenbrook were engaged by a now bust company to do essentially a complete
> port of Lua 5.1 to the J2ME MIDP 2.0 CLDC 1.1 platform.  Compiler,
> coroutines, string matching, the works.  We did it, they went bust, now the
> technology lies buried in some faceless company basement. *sigh*
>
>  Cheers,
>   drj
>



-- 
Gerardo Horvilleur
[hidden email]
5813-0830

Reply | Threaded
Open this post in threaded view
|

RE: J2ME Implementation of Lua?

Jeremy Irish
In reply to this post by David Given
We want it to run *on* Java. As noted by others we don't want to have to worry about whether our C based engine can port to any particular device. In some cases (and platforms) we only have access to our own little Java sandbox.

We have considered an alternative to a true port by using only a subset of Lua and supporting it instead. On the back-end we would merely "compile" each Wherigo cartridge into the supporting language on the platform whether it be J2ME or whatever.

Either direction seems reasonable at this point. We considered other languages like Python (and the hairy mess of converting existing games) but the footprint is way too large for some of the target platforms. I still think Lua is a viable solution in either scenario.

It's too bad there's a full port locked in a basement somewhere. Perhaps there's a fee to wake it from its slumber. We’re definitely open to applying our budget to unearth something that was already created.

Jeremy

-----Original Message-----
David Given says:

Do you want it to run *on* Java (so the interpreter is written in Java), or do you want it to run *with* Java (so the interpreter is written in C with bridge methods to allow you to call it from Java)? It shouldn't make a difference to the API either way.

Personally, I'd quite like something rather different: a Lua *compiler* that generates Java source code. On a lot of the platforms I develop for (GWT, Android) I'm basically stuck with Java, which while it does have some nice features, doesn't really have the nice features I want...

--
┌─── dg@cowlark.com ───── http://www.cowlark.com ───── │ "I have always wished for my computer to be as easy to use as my │ telephone; my wish has come true because I can no longer figure out │ how to use my telephone." --- Bjarne Stroustrup




Reply | Threaded
Open this post in threaded view
|

Re: J2ME Implementation of Lua?

David Given
Jeremy Irish wrote:
> We want it to run *on* Java. As noted by others we don't want to have to worry about whether our C based engine can port to any particular device. In some cases (and platforms) we only have access to our own little Java sandbox.

Well, as someone else noted, there's Kahlua, but I've never used it.

If you don't need the ability to *compile* Lua code on the device, you
may want to look at bytecode translation. This may involve less work
than a full port, as you're making use of the existing compiler, as well
as getting you a much faster result.

For example, I just found this:

http://www.lua.inf.puc-rio.br/luanet/lua2il_jucs.pdf

It's a paper on bytecode translation of Lua onto CLR. If CLR can do it,
I don't see any reason why the JVM can't; the two are architecturally
very similar.

Of particular interest is the table on page 12 showing the relative
speeds of the different approaches; translated Lua turned out to be
about the same speed as interpreted Lua. (And about half the speed of
interpreted Python, slightly faster than translated Python, and about an
order of magnitude faster than interpreted Python where the interpreter
itself was running on CLR... take note, if you want to write a Lua
interpreter running on JVM.)

*rummage*

Aha, the CLR bytecode translator's still being developed:

http://www.lua.inf.puc-rio.br/luaclr

I particularly like the phrase 'Benchmarks show the compiler to already
outperform the Lua interpreter for common operations...'

-- 
ââââ ïïïïïïïïïïïïïï âââââ http://www.cowlark.com âââââ
â "I have always wished for my computer to be as easy to use as my
â telephone; my wish has come true because I can no longer figure out
â how to use my telephone." --- Bjarne Stroustrup

Attachment: signature.asc
Description: OpenPGP digital signature

Reply | Threaded
Open this post in threaded view
|

Re: J2ME Implementation of Lua?

Fabio Mascarenhas
On Tue, Apr 8, 2008 at 9:01 PM, David Given <[hidden email]> wrote:
> Jeremy Irish wrote:
>  For example, I just found this:
>
>  http://www.lua.inf.puc-rio.br/luanet/lua2il_jucs.pdf
>
>  It's a paper on bytecode translation of Lua onto CLR. If CLR can do it,
>  I don't see any reason why the JVM can't; the two are architecturally
>  very similar.
>
>  Of particular interest is the table on page 12 showing the relative
>  speeds of the different approaches; translated Lua turned out to be
>  about the same speed as interpreted Lua. (And about half the speed of
>  interpreted Python, slightly faster than translated Python, and about an
>  order of magnitude faster than interpreted Python where the interpreter
>  itself was running on CLR... take note, if you want to write a Lua
>  interpreter running on JVM.)

I am the author of the paper. :-) Notice that the CLR (and the desktop
JVMs) have good JIT compilers, and this is how one can get good
results by bytecode translation (or straigth compilation). J2ME is
interpreted AFAIK so there will be a big speed hit. I don't know
enough about CLDC hotspot to comment... I recommend translating some
microbenchmarks by hand and testing them against interpretation with
Kahlua to see if the gains are worth the trouble.

One big downside of compilation or translation is that you lose
lightweight coroutines, and have to implement them using Java threads
and synchronization; but here I the opposite will happen wrt desktop
and embeddd JVMs, with desktop JVMs faring worse than embedded ones,
as the former will be using system threads and the latter will be
using "green" threads.

Another downside is code size, it's several times bigger than the
corresponding Lua bytecode because of all the extra checks.

>  *rummage*
>
>  Aha, the CLR bytecode translator's still being developed:
>
>  http://www.lua.inf.puc-rio.br/luaclr
>
>  I particularly like the phrase 'Benchmarks show the compiler to already
>  outperform the Lua interpreter for common operations...'

It's a source-to-CIL compiler, now, and faster than Lua on the
Richards benchmark, and way faster on some of the sillier shootout
benchmarks. Again, this is highly dependent on the JIT and GC of the
target platform. I will try to validate the results with the Hotspot
JVM, but I expect similar results.

--
Fabio Mascarenhas

Reply | Threaded
Open this post in threaded view
|

Re: J2ME Implementation of Lua?

Gerardo Horvilleur
There are huge speed differences between J2ME implementations. I've
measured the times for some simple benchmarks in various phones and
I've seen ratios up to a 100 to 1 between different phones.
Sony Ericsson and Nokia phones have an excellent implementation of
Java. It is very fast (I'm sure they do have something similar to the
Hotspot compiler used in desktop and server JVM). On the other hand,
the Motorola and Samsung phones I've tested have a very poor
performance.

On Tue, Apr 8, 2008 at 9:47 PM, Fabio Mascarenhas <[hidden email]> wrote:
> On Tue, Apr 8, 2008 at 9:01 PM, David Given <[hidden email]> wrote:
>  > Jeremy Irish wrote:
>
> >  For example, I just found this:
>  >
>  >  http://www.lua.inf.puc-rio.br/luanet/lua2il_jucs.pdf
>  >
>  >  It's a paper on bytecode translation of Lua onto CLR. If CLR can do it,
>  >  I don't see any reason why the JVM can't; the two are architecturally
>  >  very similar.
>  >
>  >  Of particular interest is the table on page 12 showing the relative
>  >  speeds of the different approaches; translated Lua turned out to be
>  >  about the same speed as interpreted Lua. (And about half the speed of
>  >  interpreted Python, slightly faster than translated Python, and about an
>  >  order of magnitude faster than interpreted Python where the interpreter
>  >  itself was running on CLR... take note, if you want to write a Lua
>  >  interpreter running on JVM.)
>
>  I am the author of the paper. :-) Notice that the CLR (and the desktop
>  JVMs) have good JIT compilers, and this is how one can get good
>  results by bytecode translation (or straigth compilation). J2ME is
>  interpreted AFAIK so there will be a big speed hit. I don't know
>  enough about CLDC hotspot to comment... I recommend translating some
>  microbenchmarks by hand and testing them against interpretation with
>  Kahlua to see if the gains are worth the trouble.
>
>  One big downside of compilation or translation is that you lose
>  lightweight coroutines, and have to implement them using Java threads
>  and synchronization; but here I the opposite will happen wrt desktop
>  and embeddd JVMs, with desktop JVMs faring worse than embedded ones,
>  as the former will be using system threads and the latter will be
>  using "green" threads.
>
>  Another downside is code size, it's several times bigger than the
>  corresponding Lua bytecode because of all the extra checks.
>
>
>  >  *rummage*
>  >
>  >  Aha, the CLR bytecode translator's still being developed:
>  >
>  >  http://www.lua.inf.puc-rio.br/luaclr
>  >
>  >  I particularly like the phrase 'Benchmarks show the compiler to already
>  >  outperform the Lua interpreter for common operations...'
>
>  It's a source-to-CIL compiler, now, and faster than Lua on the
>  Richards benchmark, and way faster on some of the sillier shootout
>  benchmarks. Again, this is highly dependent on the JIT and GC of the
>  target platform. I will try to validate the results with the Hotspot
>  JVM, but I expect similar results.
>
>  --
>  Fabio Mascarenhas
>



-- 
Gerardo Horvilleur
[hidden email]
5813-0830

Reply | Threaded
Open this post in threaded view
|

Re: WebService

Robert Raschke
In reply to this post by Daniel Ventura de Oliveira
On 4/8/08, Daniel Ventura de Oliveira <[hidden email]> wrote:
> Is there a way to create a WebService in Lua to be consumed by a C#
> application?

I would recommend just using C# for the server, if that's going to be
your client. You're assured that they'll fit together.

Alternatively, investigate a RESTful interface, that's much much
easier. Obviously, that only works if you don't have any clients yet
that demand SOAP.

I never got anywhere with LuaSOAP. A simple client server in Lua
worked, but C# as a client did not. These days I write SOAP clients in
Lua using hand rolled marshalling. That is a little brittle, since
changes in the SOAP interface might break my code. But WSDL is just
too obscure for me. I've given up on ever writing a SOAP server, it
has too many inconsistencies and implementations, like everything else
in the web world. And my brain is too small for that.

Robby

Reply | Threaded
Open this post in threaded view
|

Re: J2ME Implementation of Lua?

David Jones-2
In reply to this post by Gerardo Horvilleur

On 8 Apr 2008, at 23:14, Gerardo Horvilleur wrote:
Interesting. How large was it? (memory footprint/jar file size). Did
it fit on most J2ME enabled phones?

100KB or so of JAR.

Since Lua strings were Java strings and Lua tables were java.util.Hashtable memory footprint was pretty typical for a Java program.

I fitted on the 'phone I used to implement it. Most serious 'phones either had no limit of JAR file size or had 128KB. I think the Nokia 6230i has a 128KB jar file limit and we were under that.

drj

Reply | Threaded
Open this post in threaded view
|

Re: J2ME Implementation of Lua?

Kristofer Karlsson
For reference, an obfuscated jar of the Kahlua runtime is currently at 24 KB.
Using Hashtable wasn't an option due to semantic reasons -
implementing next would get tricky. Instead a custom hashtable was
implemented, trying to mimic the standard lua implementation.

(As a note, I have written apps for J2ME that had to fit in 64 KB.
Those were painful times.)

On Wed, Apr 9, 2008 at 10:42 AM, David Jones <[hidden email]> wrote:
>
>  On 8 Apr 2008, at 23:14, Gerardo Horvilleur wrote:
>
> > Interesting. How large was it? (memory footprint/jar file size). Did
> > it fit on most J2ME enabled phones?
> >
>
>  100KB or so of JAR.
>
>  Since Lua strings were Java strings and Lua tables were java.util.Hashtable
> memory footprint was pretty typical for a Java program.
>
>  I fitted on the 'phone I used to implement it.  Most serious 'phones either
> had no limit of JAR file size or had 128KB.  I think the Nokia 6230i has a
> 128KB jar file limit and we were under that.
>
>  drj
>

Reply | Threaded
Open this post in threaded view
|

RE: J2ME Implementation of Lua?

John D. Ramsdell-2
In reply to this post by Jeremy Irish
> David Given <[hidden email]> wrote:

> It's a paper on bytecode translation of Lua onto CLR. If CLR can do
> it, I don't see any reason why the JVM can't; the two are
> architecturally very similar.

The CLR was designed to support a diverse set of languages while the
JVM is very Java specific.  In particular, it's a pain to generate
Java bytecodes for languages that promise to implement some function
calls as tail calls, such as Lua and Scheme.  The CLR has an
instruction just for this purpose.  So just because the CLR can do it,
you should not assume the JVM can.

Quite a while ago, Jeff Siskind and friends translated a large Scheme
program that implemented a early silicon compiler into the native
language of the Symbolics Lisp Machine.  This dialect of Lisp was not
tail recursive, and the result was huge runtime stacks.  Besides being
a performance hit, it turned out the large stacks tickled a GC bug
that mysteriously crashed our machines.  Imagine the fun we had
debugging that problem!

When translating Lua to Java bytecode, keep in mind the programmers
that take care to ensure some calls will be recognized as tail calls
by the Lua interpreter.  Good performance of those programs may depend
on a faithful translation.

John

Reply | Threaded
Open this post in threaded view
|

Re: WebService

Stefan Sandberg
In reply to this post by Robert Raschke
Keep in mind that C# serverside demands either mono or .net, and mono wasn't on par with my expectations last time I tried to use it (even for trivial 'register user to db' -type apps, but might have changed now..

If you're on a non-win platform, I'd take luasoap over C# under mono any day, but if you're on window server, nothing beats wcf, it's very well done.. I highly recommend this book for that, http://www.oreilly.com/catalog/9780596101626/

Robert Raschke wrote:
On 4/8/08, Daniel Ventura de Oliveira <[hidden email]> wrote:
Is there a way to create a WebService in Lua to be consumed by a C#
application?

I would recommend just using C# for the server, if that's going to be
your client. You're assured that they'll fit together.

Alternatively, investigate a RESTful interface, that's much much
easier. Obviously, that only works if you don't have any clients yet
that demand SOAP.

I never got anywhere with LuaSOAP. A simple client server in Lua
worked, but C# as a client did not. These days I write SOAP clients in
Lua using hand rolled marshalling. That is a little brittle, since
changes in the SOAP interface might break my code. But WSDL is just
too obscure for me. I've given up on ever writing a SOAP server, it
has too many inconsistencies and implementations, like everything else
in the web world. And my brain is too small for that.

Robby



12