Last 30 days

• Dec 08, 2009

  r232 (added better name for LuaJavaInvoker) committed by kristofer.karlsson   -   added better name for LuaJavaInvoker

  added better name for LuaJavaInvoker
• Dec 07, 2009

  r231 (added support for listing java functions in the profiler) committed by kristofer.karlsson   -   added support for listing java functions in the profiler

  added support for listing java functions in the profiler
• Dec 07, 2009

  r230 (added more profiler classes) committed by kristofer.karlsson   -   added more profiler classes

  added more profiler classes
• Dec 06, 2009

  r229 (some more work on the profiler) committed by kristofer.karlsson   -   some more work on the profiler

  some more work on the profiler
• Dec 06, 2009

  r228 (added aggregated profiler) committed by kristofer.karlsson   -   added aggregated profiler

  added aggregated profiler
• Dec 06, 2009

  r227 (added start of profiler) committed by kristofer.karlsson   -   added start of profiler

  added start of profiler
• Dec 03, 2009

  r226 (simplified j2se-util by removing userdataproperties) committed by kristofer.karlsson   -   simplified j2se-util by removing userdataproperties

  simplified j2se-util by removing userdataproperties
• Dec 03, 2009

  r225 (added support for setting/getting metatables on plain java o...) committed by kristofer.karlsson   -   added support for setting/getting metatables on plain java objects

  added support for setting/getting metatables on plain java objects

Earlier this year

• Nov 23, 2009

  r224 (fixed bug with reusing return values) committed by kristofer.karlsson   -   fixed bug with reusing return values

  fixed bug with reusing return values
• Nov 23, 2009

  issue 18 (@LuaMethod with varargs) Status changed by kristofer.karlsson   -   Done!

  Status: Fixed

  Done!

  Status: Fixed
• Nov 23, 2009

  r223 (added support for varargs in jse-util) committed by kristofer.karlsson   -   added support for varargs in jse-util

  added support for varargs in jse-util
• Nov 18, 2009

  r222 (fixed minor bug in require) committed by kristofer.karlsson   -   fixed minor bug in require

  fixed minor bug in require
• Nov 17, 2009

  issue 19 (@LuaMethod with overloading) reported by kristofer.karlsson   -   Currently @LuaMethod does not support overloading. I want this to work: @LuaMethod public void foo(String s); @LuaMethod public void foo(int i); Kahlua should choose the correct one to call based on the input parameters. This can be done by detecting if overloading is necessary (i.e. atleast two methods wants to bind to the same name) and if so, create a proxy method that calls the real methods by iterating over them and picking the first one that matches with all arguments. Methods with more parameters should probably be prioritized in that list over methods with fewer parameters.

  Currently @LuaMethod does not support overloading. I want this to work: @LuaMethod public void foo(String s); @LuaMethod public void foo(int i); Kahlua should choose the correct one to call based on the input parameters. This can be done by detecting if overloading is necessary (i.e. atleast two methods wants to bind to the same name) and if so, create a proxy method that calls the real methods by iterating over them and picking the first one that matches with all arguments. Methods with more parameters should probably be prioritized in that list over methods with fewer parameters.
• Nov 17, 2009

  issue 18 (@LuaMethod with varargs) reported by kristofer.karlsson   -   @LuaMethod should support varargs like this: In lua: obj:foo(1, 2, 3, 4, 5) triggers in java: @LuaMethod public void foo(Object first, Object second, Object... rest); with first = 1, second = 2, rest = {3, 4, 5}

  @LuaMethod should support varargs like this: In lua: obj:foo(1, 2, 3, 4, 5) triggers in java: @LuaMethod public void foo(Object first, Object second, Object... rest); with first = 1, second = 2, rest = {3, 4, 5}
• Nov 04, 2009

  r221 (added a j2se-util for require, and fixed a minor bug in prin...) committed by kristofer.karlsson   -   added a j2se-util for require, and fixed a minor bug in print

  added a j2se-util for require, and fixed a minor bug in print
• Nov 03, 2009

  r220 (fixed minor bug in ThreadSafeLuaState and added VerifiedSing...) committed by kristofer.karlsson   -   fixed minor bug in ThreadSafeLuaState and added VerifiedSingleThreadLuaState

  fixed minor bug in ThreadSafeLuaState and added VerifiedSingleThreadLuaState
• Oct 16, 2009

  r219 (fixed an oops) committed by kristofer.karlsson   -   fixed an oops

  fixed an oops
• Oct 16, 2009

  r218 (added a testcase for a bug) committed by kristofer.karlsson   -   added a testcase for a bug

  added a testcase for a bug
• Oct 16, 2009

  r217 (fixed a bug concerning not clearing a closures stack) committed by kristofer.karlsson   -   fixed a bug concerning not clearing a closures stack

  fixed a bug concerning not clearing a closures stack
• Oct 11, 2009

  r216 (added support in j2se-util annotation for nested classes) committed by kristofer.karlsson   -   added support in j2se-util annotation for nested classes

  added support in j2se-util annotation for nested classes
• Sep 22, 2009

  issue 17 (Not an Issue, just a Question: can we implement the Lua engi...) Status changed by kristofer.karlsson   -   Sure, go ahead. It would just be a big search and replace refactoring.

  Status: Invalid

  Sure, go ahead. It would just be a big search and replace refactoring.

  Status: Invalid
• Sep 22, 2009

  issue 17 (Not an Issue, just a Question: can we implement the Lua engi...) reported by charleybin   -   in order to reduce the memory consuming. can we do that ? or is it possible to migrates all double based data structure to float ?

  in order to reduce the memory consuming. can we do that ? or is it possible to migrates all double based data structure to float ?
• Sep 15, 2009

  r215 (simplified the getter slightly... again) committed by kristofer.karlsson   -   simplified the getter slightly... again

  simplified the getter slightly... again
• Sep 15, 2009

  r214 (simplified the getter slightly) committed by kristofer.karlsson   -   simplified the getter slightly

  simplified the getter slightly
• Sep 15, 2009

  r213 (Refactored again. This time LuaReturn (and it's subclasses) ...) committed by per.malmen   -   Refactored again. This time LuaReturn (and it's subclasses) behaves like a List again

  Refactored again. This time LuaReturn (and it's subclasses) behaves like a List again
• Sep 15, 2009

  r212 (LuaReturn no longer inherits AbstractList since it never was...) committed by per.malmen   -   LuaReturn no longer inherits AbstractList since it never was a list. Instead you can ask for a list view of it

  LuaReturn no longer inherits AbstractList since it never was a list. Instead you can ask for a list view of it
• Sep 15, 2009

  r211 (LuaReturn now extends AbstractList) committed by per.malmen   -   LuaReturn now extends AbstractList

  LuaReturn now extends AbstractList
• Sep 15, 2009

  r210 (added more utility functions to luareturn) committed by kristofer.karlsson   -   added more utility functions to luareturn

  added more utility functions to luareturn
• Sep 14, 2009

  r209 (The methods in LuaReturn are now public) committed by per.malmen   -   The methods in LuaReturn are now public

  The methods in LuaReturn are now public
• Sep 14, 2009

  r208 (fixed broken tests) committed by kristofer.karlsson   -   fixed broken tests

  fixed broken tests
• Sep 14, 2009

  r207 (added error checking, changed file encoding) committed by kristofer.karlsson   -   added error checking, changed file encoding

  added error checking, changed file encoding
• Sep 14, 2009

  r206 (Added a wrapper class for the returned object array from pca...) committed by per.malmen   -   Added a wrapper class for the returned object array from pcalls

  Added a wrapper class for the returned object array from pcalls
• Aug 03, 2009

  issue 16 (LuaTableImpl.len() doesn't work properly on non-numerically-...) Status changed by kristofer.karlsson   -   Not a bug, this is the expected behavior of tables in Lua.

  Status: Invalid

  Not a bug, this is the expected behavior of tables in Lua.

  Status: Invalid
• Aug 03, 2009

  issue 16 (LuaTableImpl.len() doesn't work properly on non-numerically-...) reported by m...@j0t.it   -   Test.java is in directory src/se/krka/kahlua/vm: package se.krka.kahlua.vm; public class Test { public static void main(String a[]) { LuaTable lt = new LuaTableImpl(); lt.rawset("a", "b"); lt.rawset("c", "d"); System.out.println(lt.len()); } } Then I compile it: mbp:src idave$ javac se/krka/kahlua/vm/Test.java Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. And I run it: mbp:src idave$ java se/krka/kahlua/vm/Test 0

  Test.java is in directory src/se/krka/kahlua/vm: package se.krka.kahlua.vm; public class Test { public static void main(String a[]) { LuaTable lt = new LuaTableImpl(); lt.rawset("a", "b"); lt.rawset("c", "d"); System.out.println(lt.len()); } } Then I compile it: mbp:src idave$ javac se/krka/kahlua/vm/Test.java Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. And I run it: mbp:src idave$ java se/krka/kahlua/vm/Test 0
• Jul 06, 2009

  issue 14 (Suspect stack issue) Status changed by kristofer.karlsson   -   The optimized LuaArray type is now commited into subversion. It can be used instead of tables for pure array purposes. It only allows setting when the keys are integers in the range [1..n] See luaarray.lua in testsuite/lua for examples on how to use.

  Status: Fixed

  The optimized LuaArray type is now commited into subversion. It can be used instead of tables for pure array purposes. It only allows setting when the keys are integers in the range [1..n] See luaarray.lua in testsuite/lua for examples on how to use.

  Status: Fixed
• Jul 06, 2009

  r205 (fixed bug with lua array) committed by kristofer.karlsson   -   fixed bug with lua array

  fixed bug with lua array
• Jul 06, 2009

  issue 15 (string.gsub function/table replacing is broken when no captu...) Status changed by kristofer.karlsson   -   Fixed in subversion.

  Status: Fixed

  Fixed in subversion.

  Status: Fixed
• Jul 06, 2009

  r204 (added an optimized array type, preliminary script engine sup...) committed by kristofer.karlsson   -   added an optimized array type, preliminary script engine support, fixed gsub bug

  added an optimized array type, preliminary script engine support, fixed gsub bug
• Jul 02, 2009

  issue 15 (string.gsub function/table replacing is broken when no captu...) Status changed by kristofer.karlsson   -   Confirmed. I am not quite ready to commit my changes, but here is my proposed fix: --- a/src/se/krka/kahlua/stdlib/StringLib.java +++ b/src/se/krka/kahlua/stdlib/StringLib.java @@ -809,6 +809,9 @@ public final class StringLib implements JavaFunction { } public Object[] getCaptures() { + if (level <= 0) { + return null; + } Object[] caps = new String[level]; for (int i = 0; i < level; i++) { if (capture[i].len == CAP_POSITION) { @@ -1432,12 +1435,22 @@ public final class StringLib implements JavaFunction { String type = BaseLib.type(repl); if (type == BaseLib.TYPE_NUMBER || type == BaseLib.TYPE_STRING) { b.append(addString (ms, repl, src, e)); - } else if (type == BaseLib.TYPE_FUNCTION) { - Object res = ms.callFrame.thread.state.call(repl,ms.getCaptures()); - b.append(res); - } else if (type == BaseLib.TYPE_TABLE) { - Object cap = ms.getCaptures()[0]; - b.append(((LuaTable)repl).rawget(cap)); + } else { + String match = src.getString().substring(0, e.getIndex() - src.getIndex()); + Object[] captures = ms.getCaptures(); + if (captures != null) { + match = BaseLib.rawTostring(captures[0]); + } + Object res = null; + if (type == BaseLib.TYPE_FUNCTION) { + res = ms.callFrame.thread.state.call(repl, match, null, null); + } else if (type == BaseLib.TYPE_TABLE) { + res = ((LuaTable)repl).rawget(match); + } + if (res == null) { + res = match; + } + b.append(BaseLib.rawTostring(res)); } }

  Status: Started

  Confirmed. I am not quite ready to commit my changes, but here is my proposed fix: --- a/src/se/krka/kahlua/stdlib/StringLib.java +++ b/src/se/krka/kahlua/stdlib/StringLib.java @@ -809,6 +809,9 @@ public final class StringLib implements JavaFunction { } public Object[] getCaptures() { + if (level <= 0) { + return null; + } Object[] caps = new String[level]; for (int i = 0; i < level; i++) { if (capture[i].len == CAP_POSITION) { @@ -1432,12 +1435,22 @@ public final class StringLib implements JavaFunction { String type = BaseLib.type(repl); if (type == BaseLib.TYPE_NUMBER || type == BaseLib.TYPE_STRING) { b.append(addString (ms, repl, src, e)); - } else if (type == BaseLib.TYPE_FUNCTION) { - Object res = ms.callFrame.thread.state.call(repl,ms.getCaptures()); - b.append(res); - } else if (type == BaseLib.TYPE_TABLE) { - Object cap = ms.getCaptures()[0]; - b.append(((LuaTable)repl).rawget(cap)); + } else { + String match = src.getString().substring(0, e.getIndex() - src.getIndex()); + Object[] captures = ms.getCaptures(); + if (captures != null) { + match = BaseLib.rawTostring(captures[0]); + } + Object res = null; + if (type == BaseLib.TYPE_FUNCTION) { + res = ms.callFrame.thread.state.call(repl, match, null, null); + } else if (type == BaseLib.TYPE_TABLE) { + res = ((LuaTable)repl).rawget(match); + } + if (res == null) { + res = match; + } + b.append(BaseLib.rawTostring(res)); } }

  Status: Started
• Jun 30, 2009

  issue 15 (string.gsub function/table replacing is broken when no captu...) commented on by matejcik   -   and the patch is even better now that i discovered BaseLib.rawTostring ;e)

  and the patch is even better now that i discovered BaseLib.rawTostring ;e)
• Jun 29, 2009

  issue 15 (string.gsub function/table replacing is broken when no captu...) reported by matejcik   -   from lua reference: """ If repl is a table, then the table is queried for every match, using the first capture as the key; *if the pattern specifies no captures, then the whole match is used as the key.* If repl is a function, then this function is called every time a match occurs, with all captured substrings passed as arguments, in order; *if the pattern specifies no captures, then the whole match is passed as a sole argument.* If the value returned by the table query or by the function call is a string or a number, then it is used as the replacement string; *otherwise, if it is false or nil, then there is no replacement (that is, the original match is kept in the string).* """ this was not true in kahlua. the attached patch fixes this. also, the Lua throws error if something else than string/number/false/nil is found for replacement. the patch doesn't copy this behavior and instead assumes that everything that is not string/number means false.

  from lua reference: """ If repl is a table, then the table is queried for every match, using the first capture as the key; *if the pattern specifies no captures, then the whole match is used as the key.* If repl is a function, then this function is called every time a match occurs, with all captured substrings passed as arguments, in order; *if the pattern specifies no captures, then the whole match is passed as a sole argument.* If the value returned by the table query or by the function call is a string or a number, then it is used as the replacement string; *otherwise, if it is false or nil, then there is no replacement (that is, the original match is kept in the string).* """ this was not true in kahlua. the attached patch fixes this. also, the Lua throws error if something else than string/number/false/nil is found for replacement. the patch doesn't copy this behavior and instead assumes that everything that is not string/number means false.
• Jun 17, 2009

  issue 14 (Suspect stack issue) commented on by m...@j0t.it   -   >With the current prototype (not yet checked in), running quicksort is about 4-5 times >faster in Kahlua than in Minijoe. I'm glad to hear that. Thank you for the exhaustive explanation.

  >With the current prototype (not yet checked in), running quicksort is about 4-5 times >faster in Kahlua than in Minijoe. I'm glad to hear that. Thank you for the exhaustive explanation.
• Jun 17, 2009

  issue 14 (Suspect stack issue) commented on by kristofer.karlsson   -   Yes, it's a performance problem. Kahlua is currently not optimized at all for dealing with numeric arrays. There are two major reasons why Minijoe is faster than Kahlua for quicksort. 1) Minijoe has both an array-implementation and a map-implementation. Kahlua only has a map implementation which makes array access slower. 2) Minijoe distinguishes objects and numbers, which means that it allocates a lot fewer Double objects. Point 2 is probably a minor issue. I considered doing something similar for Kahlua mostly to avoid all the memory allocations when doing arithmetic operations but haven't gotten around to it yet. I may try implementing it and measure how much better it gets (if at all) I also have plans on releasing a pure array type in the Kahlua core, which will dramatically speed up array operations. With the current prototype (not yet checked in), running quicksort is about 4-5 times faster in Kahlua than in Minijoe. Here are my current benchmarks: Kahlua : 91 ms minijoe : 178 ms Kahlua : 232 ms minijoe : 236 ms Kahlua : 64 ms minijoe : 62 ms Kahlua : 7 ms minijoe : 180 ms Kahlua : 6 ms minijoe : 178 ms Kahlua : 34 ms minijoe : 117 ms Kahlua : 6 ms minijoe : 83 ms Kahlua : 5 ms minijoe : 19 ms Kahlua : 5 ms minijoe : 17 ms Kahlua : 5 ms minijoe : 41 ms Kahlua : 35 ms minijoe : 56 ms Kahlua : 6 ms minijoe : 17 ms Kahlua : 5 ms minijoe : 17 ms Kahlua : 4 ms minijoe : 17 ms Kahlua : 6 ms minijoe : 18 ms Kahlua : 5 ms minijoe : 17 ms Kahlua : 4 ms minijoe : 17 ms Kahlua : 4 ms minijoe : 18 ms Kahlua : 5 ms minijoe : 17 ms Kahlua : 4 ms minijoe : 17 ms

  Yes, it's a performance problem. Kahlua is currently not optimized at all for dealing with numeric arrays. There are two major reasons why Minijoe is faster than Kahlua for quicksort. 1) Minijoe has both an array-implementation and a map-implementation. Kahlua only has a map implementation which makes array access slower. 2) Minijoe distinguishes objects and numbers, which means that it allocates a lot fewer Double objects. Point 2 is probably a minor issue. I considered doing something similar for Kahlua mostly to avoid all the memory allocations when doing arithmetic operations but haven't gotten around to it yet. I may try implementing it and measure how much better it gets (if at all) I also have plans on releasing a pure array type in the Kahlua core, which will dramatically speed up array operations. With the current prototype (not yet checked in), running quicksort is about 4-5 times faster in Kahlua than in Minijoe. Here are my current benchmarks: Kahlua : 91 ms minijoe : 178 ms Kahlua : 232 ms minijoe : 236 ms Kahlua : 64 ms minijoe : 62 ms Kahlua : 7 ms minijoe : 180 ms Kahlua : 6 ms minijoe : 178 ms Kahlua : 34 ms minijoe : 117 ms Kahlua : 6 ms minijoe : 83 ms Kahlua : 5 ms minijoe : 19 ms Kahlua : 5 ms minijoe : 17 ms Kahlua : 5 ms minijoe : 41 ms Kahlua : 35 ms minijoe : 56 ms Kahlua : 6 ms minijoe : 17 ms Kahlua : 5 ms minijoe : 17 ms Kahlua : 4 ms minijoe : 17 ms Kahlua : 6 ms minijoe : 18 ms Kahlua : 5 ms minijoe : 17 ms Kahlua : 4 ms minijoe : 17 ms Kahlua : 4 ms minijoe : 18 ms Kahlua : 5 ms minijoe : 17 ms Kahlua : 4 ms minijoe : 17 ms
• Jun 16, 2009

  issue 14 (Suspect stack issue) commented on by m...@j0t.it   -   You'll admit, though, that 143 secs to run that script is way too much, and I'm still struggling to find an explanation for that. I don't think the JVM on the phone is slow: that same script, translated in javascript and run with minijoe (www.minijoe.com) on the phone takes only 7 seconds. There MUST be something wrong somewhere, it'd be nice to point it out. The script is fine (it's almost the same as the sort function in lua's stdlib), the JVM is ok (the same code runs fine on minijoe), so there must be something wrong with kahlua... As a matter of fact, kahlua on a plain J2SE takes 830 millisecs to run that quicksort script. Minijoe, on the other hand, on the same J2SE, takes 40 millisecs to run the translated quicksort... That's 20 times faster! How do you explain that? (7s x 20 = 140 s, and 40ms x 20 = 800ms, it's the same 20x increase in running time, on both JVMs!) It's no surprise performance is better on plain J2SE. Computers run programs at lightning speed, so a 20-fold difference can go unnoticed if the overall running time is less than 1 second. But even the PC JVM shows the same symptoms as the phone JVM, and I think that clearly shows there's something wrong in kahlua...

  You'll admit, though, that 143 secs to run that script is way too much, and I'm still struggling to find an explanation for that. I don't think the JVM on the phone is slow: that same script, translated in javascript and run with minijoe (www.minijoe.com) on the phone takes only 7 seconds. There MUST be something wrong somewhere, it'd be nice to point it out. The script is fine (it's almost the same as the sort function in lua's stdlib), the JVM is ok (the same code runs fine on minijoe), so there must be something wrong with kahlua... As a matter of fact, kahlua on a plain J2SE takes 830 millisecs to run that quicksort script. Minijoe, on the other hand, on the same J2SE, takes 40 millisecs to run the translated quicksort... That's 20 times faster! How do you explain that? (7s x 20 = 140 s, and 40ms x 20 = 800ms, it's the same 20x increase in running time, on both JVMs!) It's no surprise performance is better on plain J2SE. Computers run programs at lightning speed, so a 20-fold difference can go unnoticed if the overall running time is less than 1 second. But even the PC JVM shows the same symptoms as the phone JVM, and I think that clearly shows there's something wrong in kahlua...
• Jun 16, 2009

  issue 14 (Suspect stack issue) Status changed by kristofer.karlsson   -   I tested this, and various other code snippets and there is no bug. All I could determine is that the performance is much better when running in a plain J2SE environment than on an emulator or on an actual phone. So, it's not a bug, but there is always room for optimizations. I might spend some time later to work on improving the performance of Kahlua, but I can't promise anything. If you find any good optimizations, feel free to send a patch or a report, and I'll try to implement in the Kahlua trunk. In the mean time, I think the proper solution is to implement sorting and other computationally intensive operations in plain Java instead of Lua.

  Status: Invalid

  I tested this, and various other code snippets and there is no bug. All I could determine is that the performance is much better when running in a plain J2SE environment than on an emulator or on an actual phone. So, it's not a bug, but there is always room for optimizations. I might spend some time later to work on improving the performance of Kahlua, but I can't promise anything. If you find any good optimizations, feel free to send a patch or a report, and I'll try to implement in the Kahlua trunk. In the mean time, I think the proper solution is to implement sorting and other computationally intensive operations in plain Java instead of Lua.

  Status: Invalid
• Jun 16, 2009

  issue 14 (Suspect stack issue) commented on by m...@j0t.it   -   whoops, html glitch :)

  whoops, html glitch :)
• Jun 16, 2009

  issue 14 (Suspect stack issue) reported by m...@j0t.it   -   I'm having some performance issues with kahlua, and I *strongly* suspect that this is the result of some bug in the interpreter. Basically, if I build a MIDlet including the vanilla kahlua interpreter and I run the attached lua script, it takes around 140 seconds to run on a Nokia 6212 NFC, which is way too long. The lua code seems ok, as it is almost the same as the sort function in the stdlib, so the bug must be in the interpreter. The script is run as follows: LuaState state = new LuaState(System.out); LuaClosure callback = state.loadByteCodeFromResource("/qsort", state.getEnvironment()); state.call(callback, null, null, null); I compiled the bytecode using luaj-0.97. What version of the product are you using? On what operating system? 2009-04-26 on Nokia 6212 NFC. Couldn't try with 2009-06-11 as I'm working at home at the moment and I don't have a phone to try it on. On the <a href="http://www.forum.nokia.com/Tools_Docs_and_Code/Tools/Plug- ins/Enablers/Series_40_Nokia_6212_NFC_SDK/" alt="Nokia Emulator">Nokia 6212 NFC Emulator</a> the bug is still reproducible with kahlua version 2009-06-11. I'm using Eclipse Pulsar Galileo RC1 to compile the code and package the jar.

  I'm having some performance issues with kahlua, and I *strongly* suspect that this is the result of some bug in the interpreter. Basically, if I build a MIDlet including the vanilla kahlua interpreter and I run the attached lua script, it takes around 140 seconds to run on a Nokia 6212 NFC, which is way too long. The lua code seems ok, as it is almost the same as the sort function in the stdlib, so the bug must be in the interpreter. The script is run as follows: LuaState state = new LuaState(System.out); LuaClosure callback = state.loadByteCodeFromResource("/qsort", state.getEnvironment()); state.call(callback, null, null, null); I compiled the bytecode using luaj-0.97. What version of the product are you using? On what operating system? 2009-04-26 on Nokia 6212 NFC. Couldn't try with 2009-06-11 as I'm working at home at the moment and I don't have a phone to try it on. On the <a href="http://www.forum.nokia.com/Tools_Docs_and_Code/Tools/Plug- ins/Enablers/Series_40_Nokia_6212_NFC_SDK/" alt="Nokia Emulator">Nokia 6212 NFC Emulator</a> the bug is still reproducible with kahlua version 2009-06-11. I'm using Eclipse Pulsar Galileo RC1 to compile the code and package the jar.
• Jun 11, 2009

  kahlua-j2se-util.jar (Kahlua-j2se-util jar binary for release 20090611) file uploaded by kristofer.karlsson   -  

  Labels: Featured Type-Archive OpSys-All

  Labels: Featured Type-Archive OpSys-All
• Jun 11, 2009

  kahlua.jar (Kahlua jar binary) file uploaded by kristofer.karlsson   -  

  Labels: Featured OpSys-All Type-Archive

  Labels: Featured OpSys-All Type-Archive
• Jun 11, 2009

  kahlua-release-20090611.zip (Kahlua release 20090611) file uploaded by kristofer.karlsson   -  

  Labels: Featured Type-Source OpSys-All

  Labels: Featured Type-Source OpSys-All