http://blog.gmane.org/gmane.comp.lang.lua.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.lua.general/91465 <pre>Would anyone like to comment on the behavior of this code? It prints "local x" and "nil", which is probably correct, but odd. I understand that "load()" compiles code in a global context, but when I have the output of string.dump() its not really being compiled again, is it? It's just packaged VM bytecodes. Given that, what happens to the upvalues? The ref manual for 5.2 simply says "with new upvalues" when a dumped function is loaded, but makes no mention of what this means, and of course in the code sample there ARE no upvalues to bind to the function anyway. x = "global x" do local x = "local x" function foo() print(x) end end foo() sf = string.dump(foo) f2 = load(sf, "", "bt", _ENV) f2() </pre> Tim Hill 2012-05-24T17:14:45 http://permalink.gmane.org/gmane.comp.lang.lua.general/91464 <pre> Yeah, thanks for the packaged releases. The GitHub people seem to think that it's ok to name tag tarballs using the SHA1 sum instead of the tag name. Thanks for all the work you've put into the library too. The API is a real pleasure to work with. </pre> Craig Barnes 2012-05-24T15:59:35 http://permalink.gmane.org/gmane.comp.lang.lua.general/91463 <pre> Time to contact these guys (bottom of the page) to update this: http://www.gtk.org/language-bindings.php Cheers </pre> Enrico Tassi 2012-05-24T15:59:07 http://permalink.gmane.org/gmane.comp.lang.lua.general/91462 <pre>Excuse me if this is a problem on my end, but I recently noticed that whenever I reply to a message on this list, the message gets delivered correctly but shortly after that, I get a mail from lua.to.typisch&lt; at &gt;xoxy.net with the subject "Undelivered Mail Returned to Sender". Part of the message follows: ~~~~~~~~~~~~~~~~~~~~ This is the mail system at host mx1.nonlin.de. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system &lt;+public/amavis&lt; at &gt;nonlin.de&gt;: host mx1.nonlin.de[/var/run/cyrus/socket/lmtp] said: 550-Mailbox unknown. Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown (in reply to RCPT TO command) Final-Recipient: rfc822; +public/amavis&lt; at &gt;nonlin.de Original-Recipient: rfc822;+public/amavis&lt; at &gt;nonlin.de Action: failed Status: 5.1.1 Remote-MTA: dns; mx1.nonlin.de Diagnostic-Code: smtp; 550-Mailbox unknown. Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown ~~~~~~~~~~~~~~~~~~~~ </pre> Ignacio Burgueño 2012-05-24T15:18:20 http://permalink.gmane.org/gmane.comp.lang.lua.general/91461 <pre>On Thu, May 24, 2012 at 11:27 AM, Roberto Ierusalimschy &lt;roberto&lt; at &gt;inf.puc-rio.br&gt; wrote: Ah, great. Will those kind of fixes be backported into Lua 5.1.x ? Regards, Ignacio </pre> Ignacio Burgueño 2012-05-24T15:10:22 http://permalink.gmane.org/gmane.comp.lang.lua.general/91460 <pre>Hi hello. I get some bug report for lua-openssl, I can't finger out the reason of the bugs, Please give me some advice. Issue at https://github.com/zhaozg/lua-openssl/issues/7#issuecomment-5894470 Code at https://github.com/zhaozg/lua-openssl I test it on centos5/centos6 32 bits, Windows 32bits, I works for me. But I don't have a OpenSuse box, I need someone's help. Here is a traceback,that make me trouble. ---------------------------------------------------------------------------------- $ lua a.lua lua: malloc.c:3096: sYSMALLOc: Assertion (old*top == (((mbinptr) (((char *) &amp;((av)-&gt;bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) &amp;&amp; old_size == 0) || ((unsigned long) (old_size) &gt;= (unsigned long)((((*_builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) &amp; ~((2 * (sizeof(size_t))) - 1))) &amp;&amp; ((old_top)-&gt;size &amp; 0x1) &amp;&amp; ((unsigned long)old_end &amp; pagemask) == 0)' failed. Aborted (core dumped) Stack trace: #0 0xb754e8c5 in raise () from /lib/libc.so.6 #1 &lt;https://github.com/zhaozg/lua-openssl/issues/1&gt; 0xb75501d5 in abort () from /lib/libc.so.6 #2 &lt;https://github.com/zhaozg/lua-openssl/issues/2&gt; 0xb758f294 in __malloc_assert () from /lib/libc.so.6 #3 &lt;https://github.com/zhaozg/lua-openssl/issues/3&gt; 0xb75921ec in _int_malloc () from /lib/libc.so.6 #4 &lt;https://github.com/zhaozg/lua-openssl/issues/4&gt; 0xb7593cdc in malloc () from /lib/libc.so.6 #5 &lt;https://github.com/zhaozg/lua-openssl/issues/5&gt; 0xb739b2bc in ?? () from /lib/libcrypto.so.1.0.0 #6 &lt;https://github.com/zhaozg/lua-openssl/issues/6&gt; 0xb739b94c in CRYPTO_malloc () from /lib/libcrypto.so.1.0.0 #7 &lt;https://github.com/zhaozg/lua-openssl/issues/7&gt; 0xb740d13c in lh_new () from /lib/libcrypto.so.1.0.0 #8 0xb739e99c in OBJ_NAME_init () from /lib/libcrypto.so.1.0.0 #9 0xb739ed05 in OBJ_NAME_add () from /lib/libcrypto.so.1.0.0 #10 0xb74177e8 in EVP_add_cipher () from /lib/libcrypto.so.1.0.0 #11 0xb741cb93 in OpenSSL_add_all_ciphers () from /lib/libcrypto.so.1.0.0 #12 0xb750f71d in luaopen_openssl () from ./openssl.so #13 0x0804f76e in luaD_precall () #14 0x0804fb38 in luaD_call () #15 0x0804d4d7 in lua_call () #16 0x08065a08 in ll_require () #17 0x0804f76e in luaD_precall () #18 0x08058605 in luaV_execute () #19 0x0804fb88 in luaD_call () #20 0x0804c0e0 in f_call () #21 0x0804eeb2 in luaD_rawrunprotected () #22 0x0804fd20 in luaD_pcall () #23 0x0804d572 in lua_pcall () #24 0x0804b5f6 in docall () #25 0x0804be8c in pmain () #26 0x0804f76e in luaD_precall () #27 0x0804fb38 in luaD_call () #28 0x0804c0a8 in f_Ccall () #29 0x0804eeb2 in luaD_rawrunprotected () #30 0x0804fd20 in luaD_pcall () #31 0x0804d601 in lua_cpcall () #32 0x0804b22c in main () -------------------------------------------------------------------------------------------------------------------- I hope this bugs can be fixed. Thanks </pre> zhiguo zhao 2012-05-24T14:49:08 http://permalink.gmane.org/gmane.comp.lang.lua.general/91459 <pre>On Thu, May 24, 2012 at 4:33 PM, Pavel Holejsovsky &lt;pavel.holejsovsky&lt; at &gt;gmail.com&gt; wrote: Thanks for shipping actual release tarballs and taking time for writing release notes. Alpine Linux package updated. (available from edge/testing repository) </pre> Natanael Copa 2012-05-24T14:48:32 http://permalink.gmane.org/gmane.comp.lang.lua.general/91458 <pre>Hello Lua hackers, lgi 0.6 (alpha series) was released. As usual, it is available either from its github homepage[1], [2], luarocks (by 'luarocks install lgi'), and newly it is also packaged in debian/unstable (lua-lgi and lua-lgi-dev packages). lgi is gobject-introspection based dynamic Lua binding to GObject libraries. It allows using GObject-based libraries directly from Lua. If it sounds gibberish to you, ten simly said it allows easy usage of GTK+ and similar libraries from Lua. The main improvement in this version is cairo drawing library support. With cairo support in place, lgi's support of GTK+ is now fairly complete. Other than that, there were a few fixes mainly for supporting of some 'exotic' architectures (s390x, mips). Any comments or other feedback will be greatly appreciated, use github issue tracker [3] for reporting bugs. Happy hacking! Pavel [1] http://github.com/pavouk/lgi [2] http://github.com/downloads/pavouk/lgi/lgi-0.6.tar.gz [3] http://github.com/pavouk/lgi/issues </pre> Pavel Holejsovsky 2012-05-24T14:33:12 http://permalink.gmane.org/gmane.comp.lang.lua.general/91457 <pre> Yes :-( (Well, for this particular case Lua 5.2 uses gmtime_r when possible. But some other C functions still have problems.) </pre> Roberto Ierusalimschy 2012-05-24T14:27:43 http://permalink.gmane.org/gmane.comp.lang.lua.general/91456 <pre>Just my 2 cts; Some things that would have made my life easier when learning Lua; 1) Layout of the Lua system (see http://lua-users.org/lists/lua-l/2012-04/msg00880.html for an example). Some diagrams on this topic would work wonders for starters to grasp how it all fits together. 2) some visual explanation of the stack concept, positive and negative indexes. Adding a few pictures would work wonders here as well. 3) more hard-core but still relevant judging by the number of questions on the list; some more attention to multi-threading and callbacks (info on the wiki is mostly ordered by solutions, not by use-case, which makes it hard) In general I just like diagrams to explain stuff, which the book is short of. Like I said, just my 2 cts. Thijs </pre> Thijs Schreijer 2012-05-24T12:43:44 http://permalink.gmane.org/gmane.comp.lang.lua.general/91455 <pre> FYI. I just hit an underlinking issue. (http://bugs.alpinelinux.org/issues/1174#note-3) /usr/bin/lua: symbol 'ber_free': can't resolve symbol in lib '/usr/lib/lua/5.1/lualdap.so'. /usr/bin/lua: error loading module 'lualdap' from file '/usr/lib/lua/5.1/lualdap.so': (null) The Makefile does not link with -llber as it should since it uses ber_free() symbol. It should be: OPENLDAP_LIB= -lldap -llber </pre> Natanael Copa 2012-05-24T11:23:20 http://permalink.gmane.org/gmane.comp.lang.lua.general/91454 <pre> Well, I had in mind more the selection of standard set of quality batteries, rather than a despotic sentence to death for uninteresting extensions. And this just means extra responsibility for their (consensual) authors, not extra fame. The point is that today you know Lua runs everywhere and it is well supported. What about the extensions? Are they portable? Will they be supported in the future? Will they be ported to Lua 5.2? These are real issues if you plan to use Lua as a general purpose language. Cheers </pre> Enrico Tassi 2012-05-24T08:56:35 http://permalink.gmane.org/gmane.comp.lang.lua.general/91453 <pre> It would be very useful if 'LuaForge vs 2' happened - currently it's a static archive of projects, and I don't think Yuri has much time to look after it. Currently Lua projects are scattered over Github, Google code, etc. Basically, something like the snippets site [1] except for projects (and it actually makes sense to integrate snippets and projects). We got bogged down in technology choices, but it was felt that a Lua solution was best. steve d. [1] http://snippets.luacode.org/ </pre> steve donovan 2012-05-24T08:22:25 http://permalink.gmane.org/gmane.comp.lang.lua.general/91452 <pre> Choosing the libraries can be controversial... Lot of people can feel annoyed to have not been mentioned. Lot of people will think their favorite library should have been mentioned instead of another. As said, mentioning the wiki is more useful: no choice from the author, regular updates (removal of dead links and such), and so on. Also worth mentioning this mailing list... </pre> Philippe Lhoste 2012-05-24T08:09:03 http://permalink.gmane.org/gmane.comp.lang.lua.general/91451 <pre>Thanks everybody for your comments, your feedback is welcome! Just added another link to the primary menu: Roadmap (http://ophal.org/roadmap). I'm aware that the ophal.org needs more love but my focus is on making Ophal a better product, so you will see more progress along with the project progress. Also, if you really want something to be improved/changed, join the project and help make it happen! - FPG PS: Hope your smartphones enjoy the Mobile detection feature deployed today at ophal.org </pre> Fernando Paredes García 2012-05-24T03:46:48 http://permalink.gmane.org/gmane.comp.lang.lua.general/91450 <pre>On Wed, May 23, 2012 at 10:42 AM, Roberto Ierusalimschy &lt;roberto&lt; at &gt;inf.puc-rio.br&gt; wrote: However, some functions from the C runtime do share mutable data. For instance, gmtime. Other than that, at work we have many multithreaded applications using multiple lua_States and they work just fine, and when there is some bug related to shared state, it's never related to Lua. </pre> Ignacio Burgueño 2012-05-23T22:47:46 http://permalink.gmane.org/gmane.comp.lang.lua.general/91449 <pre> Thats exactly what i was looking for, merci monsieur Philippe. </pre> Maha Akkari 2012-05-23T20:54:51 http://permalink.gmane.org/gmane.comp.lang.lua.general/91448 <pre>On Wed, May 23, 2012 at 2:00 PM, Roberto Ierusalimschy &lt;roberto&lt; at &gt;inf.puc-rio.br&gt; wrote: Including [1]. Thanks! [1] http://lua-users.org/lists/lua-l/2012-05/msg00400.html </pre> Patrick Donnelly 2012-05-23T18:23:56 http://permalink.gmane.org/gmane.comp.lang.lua.general/91447 <pre> Main changes: - "long" strings are not internalized - random seed for string hashes - hash for strings may use all characters (compilation option) - changes in the control of the incremental collector - bug fix: coroutine hooks were not collected together with coroutine - bug fix: wrong handling of 'nCcalls' in coroutines - bug fix: Finalizers may call functions from a dynamic library after the library has been unloaded - bug fix: Lexical gets confused with some combination of arithmetic operators and hexadecimal numbers - bug fix: 'Proto' objects on the stack - bug fix: avoid using IEEE trick for 64-bit integer types (lua_Integer on 64-bit machines) - other small improvements </pre> Roberto Ierusalimschy 2012-05-23T18:00:33 http://permalink.gmane.org/gmane.comp.lang.lua.general/91446 <pre>I think there is reference lua that can run on one SPU (SPE) chip on the PS3 - it's limited to 256kb mem, so it's reasonable there, but as Patrick said - people would prepare well for that :) - bytecode for example. On 5/23/2012 1:15 AM, Patrick Rapin wrote: </pre> Dimiter 'malkia' Stanev 2012-05-23T17:38:54 http://permalink.gmane.org/gmane.comp.lang.lua.general/91445 <pre> The only reason why I say "split" is the mutually exclusive schedule — it is hard to visit both workshops. Alexander. </pre> Alexander Gladysh 2012-05-23T17:38:03 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.lua.general