Re: CVS commit: src/sys

2014-07-21 Thread Lourival Vieira Neto
Hi Mindaugas,

On Sat, Jul 19, 2014 at 7:16 PM, Mindaugas Rasiukevicius
rm...@netbsd.org wrote:
 Alex,

 Alexander Nasonov al...@yandex.ru wrote:
 Lourival Pereira Vieira Neto wrote:
  Module Name:src
  Committed By:   lneto
  Date:   Sat Jul 19 17:13:22 UTC 2014
 
  Modified Files:
  src/sys/modules/lua: lua.c
  src/sys/sys: lua.h
 
  Log Message:
  lua(4): added support for running Lua scripts in intr context

 Please revert this. You can't make a mechanical change
 (s/kmem_/kmem_intr_/g and so on) to enable lua in softintr
 context. You need to design it.

 What if GC kicks-in in softintr? What if the code tries to
 load a chunk of new code in softintr? And there are other
 questions.

 I have explained to Lourival that softint context is a very constrained
 environment and he should seek for a better design, e.g. have per-CPU
 Lua state while keeping such Lua programs mostly stateless and sharing no
 global state.  Ideally, we should have deterministic behaviour and memory
 pre-allocation with such programs (whether it is Lua or not).

 This is tricky with Lua, but I think he understands the implications and
 issues.  The change is more of an initial step to (inefficiently) support
 the capability.  Meanwhile, those interested can research and experiment
 with NPF+Lua.  Such use of Lua is not really meant to be production-ready
 at this point.

Yes, I think that I do understand the implications of running Lua in
softint context. However, I don't think the best option is to have
stateless Lua because we would lose functionality and it wouldn't be
enough. For example, we could still have scripts performing infinite
loops. We are circumventing this issue limiting the number of
instructions executed by the Lua VM. Please also note that it is safe
to Lua to fail to allocate memory. Moreover, I really prefer to finish
its first use case and evaluate the issues before super-engineering it
and stating that it is inefficient. Anyway, I think that we can
continue discussing it and improving the design. I just don't think
this is the case of reverting (especially, before trying to understand
what is being done).

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src

2014-07-20 Thread Lourival Vieira Neto
On Sun, Jul 20, 2014 at 5:14 AM, Alan Barrett a...@cequrux.com wrote:
 On Sat, 19 Jul 2014, Lourival Vieira Neto wrote:
 Also, if this doesn't get reverted for being rushed, then please import
 it on a vendor branch as per the usual practice.

 Did you mean moving it from -current to a specific branch?

 No, I mean using cvs import the way we usually do it.  I'll explain
 in more detail in a private message.

I get it now. Thanks.

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src

2014-07-20 Thread Lourival Vieira Neto
Hi Christos,

On Sun, Jul 20, 2014 at 6:11 PM, Christos Zoulas chris...@astron.com wrote:
 In article c1e460e2-036b-4604-8226-70e04af1e...@msys.ch,
 Marc Balmer  m...@msys.ch wrote:

Am 19.07.2014 um 21:54 schrieb Alexander Nasonov al...@yandex.ru:


 That's not how we update 3rd-party code in the tree. We use cvs import
 and resolve conflicts afterwards.


Oh well..  Having recent Lua is more important than following a procedure
that is difficult to follow.

 The procedure is not complicated; it is important for everyone to
 follow otherwise we'll end up with an unmaintainable tree. The lua
 import needs to be corrected if it was not done on a vendor branch.
 Without a vendor branch we cannot effectively maintain diffs. The
 procedure is also documented in the developers guide: google cvs
 netbsd howto.

Alan has already sent me the procedure. I'll create the vendor branch.
Sorry for the inconvenience.

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src

2014-07-20 Thread Lourival Vieira Neto
Hi folks,

On Sun, Jul 20, 2014 at 9:40 PM, matthew green m...@eterna.com.au wrote:

  Also, if this doesn't get reverted for being rushed, then
  please import it on a vendor branch as per the usual practice.
 
  Did you mean moving it from -current to a specific branch?

 No, I mean using cvs import the way we usually do it.  I'll explain
 in more detail in a private message.

 it's not too late to perform the import so we have the original
 sources available as well via valid tags and branches.

I've done the import. Please let me know if there is something wrong.

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src/sys/modules/lua

2014-07-19 Thread Lourival Vieira Neto
Hi Alexander,

On Sat, Jul 19, 2014 at 4:15 PM, Alexander Nasonov al...@yandex.ru wrote:
 Lourival Pereira Vieira Neto wrote:
 ...
 Index: src/sys/modules/lua/stdlib.h
 diff -u src/sys/modules/lua/stdlib.h:1.1 src/sys/modules/lua/stdlib.h:1.2
 --- src/sys/modules/lua/stdlib.h:1.1  Wed Oct 16 19:44:57 2013
 +++ src/sys/modules/lua/stdlib.h  Sat Jul 19 17:10:02 2014
 @@ -1,7 +1,7 @@
  /*   $NetBSD */

  /*
 - * Copyright (c) 2011, Lourival Neto ln...@netbsd.org.
 + * Copyright (c) 2011-2014, Lourival Neto ln...@netbsd.org.
   * All rights reserved.
   *
   * Redistribution and use in source and binary forms, with or without
 @@ -36,11 +36,8 @@
  #include sys/param.h
  #include sys/kmem.h

 -#ifndef _LUA_INCLUDE_STDLIB
 -#define _LUA_INCLUDE_STDLIB
 -
 -#define realloc(ptr, nsize)  kmem_alloc(nsize, KM_SLEEP)
 -#define free(ptr)kmem_free(ptr, osize)
 +#ifndef _LUA_INCLUDE_STDLIB_
 +#define _LUA_INCLUDE_STDLIB_

  #define exit(EXIT_FAILURE)   return

 Infamous hack is still in the tree.

You can always provide a better hack.

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src/sys

2014-07-19 Thread Lourival Vieira Neto
Hi Alexander,

On Sat, Jul 19, 2014 at 4:39 PM, Alexander Nasonov al...@yandex.ru wrote:
 Lourival Pereira Vieira Neto wrote:
 Module Name:  src
 Committed By: lneto
 Date: Sat Jul 19 17:13:22 UTC 2014

 Modified Files:
   src/sys/modules/lua: lua.c
   src/sys/sys: lua.h

 Log Message:
 lua(4): added support for running Lua scripts in intr context

 Please revert this.

Sure; if other developers want it too, I can revert this.

BTW, rmind@ and mbalmer@ have OKed this.

 You can't make a mechanical change
 (s/kmem_/kmem_intr_/g and so on) to enable lua in softintr
 context. You need to design it.

IMO, it is not a mechanical change. It is an incremental one.

 What if GC kicks-in in softintr?

It will call kmem_intr_free(9).

 What if the code tries to
 load a chunk of new code in softintr?

What if? Have you tried that already?

 And there are other
 questions.

You can formulate these questions and help to improve this work.

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src

2014-07-19 Thread Lourival Vieira Neto
On Sat, Jul 19, 2014 at 4:54 PM, Alexander Nasonov al...@yandex.ru wrote:
 Lourival Pereira Vieira Neto wrote:
 Module Name:  src
 Committed By: lneto
 Date: Sat Jul 19 18:38:35 UTC 2014

 Modified Files:
   src/distrib/sets/lists/base: ad.arm ad.mips ad.powerpc md.amd64
   md.sparc64 mi shl.mi
   src/distrib/sets/lists/debug: ad.arm ad.mips ad.powerpc md.amd64
   md.sparc64 shl.mi
   src/doc: CHANGES RESPONSIBLE
   src/etc/mtree: NetBSD.dist.base NetBSD.dist.earm NetBSD.dist.mips64eb
   NetBSD.dist.mips64el NetBSD.dist.powerpc64 NetBSD.dist.sparc64
   NetBSD.dist.x86_64
   src/external/mit/lua/dist: Makefile README
   src/external/mit/lua/dist/doc: contents.html lua.1 lua.css luac.1
   manual.css manual.html readme.html
   src/external/mit/lua/dist/src: Makefile lapi.c lapi.h lauxlib.c
   lauxlib.h lbaselib.c lcode.c lcode.h ldblib.c ldebug.c ldebug.h
   ldo.c ldo.h ldump.c lfunc.c lfunc.h lgc.c lgc.h linit.c liolib.c
   llex.c llex.h llimits.h lmathlib.c lmem.c lmem.h loadlib.c
   lobject.c lobject.h lopcodes.c lopcodes.h loslib.c lparser.c
   lparser.h lstate.c lstate.h lstring.c lstring.h lstrlib.c ltable.c
   ltable.h ltablib.c ltm.c ltm.h lua.c lua.h luac.c luaconf.h
   lualib.h lundump.c lundump.h lvm.c lvm.h lzio.c lzio.h
   src/external/mit/lua/lib/liblua: Makefile shlib_version
   src/external/mit/lua/usr.bin/luac: Makefile
   src/lib/lua/gpio: gpio.c
   src/lib/lua/sqlite: sqlite.c
   src/libexec/httpd: lua-bozo.c
   src/share/examples/lua: gpio.lua sqlite.lua
   src/share/mk: bsd.lua.mk
   src/sys/external/bsd/acpica/dist/include/platform: acnetbsd.h
   src/sys/lib/libkern: Makefile.libkern libkern.h
   src/sys/modules/lua: Makefile lua.c test.lua
   src/sys/modules/luapmf: Makefile luapmf.c
   src/sys/modules/luasystm: Makefile luasystm.c test.lua
 Added Files:
   src/common/lib/libc/string: strcspn.c strpbrk.c strspn.c
   src/external/mit/lua/dist/doc: alert.png osi-certified-72x60.png
   src/external/mit/lua/dist/src: lbitlib.c lcorolib.c lctype.c lctype.h
   lua.hpp lutf8lib.c
 Removed Files:
   src/external/mit/lua/dist: COPYRIGHT HISTORY INSTALL
   src/external/mit/lua/dist/doc: cover.png lua.html luac.html
   src/external/mit/lua/dist/etc: Makefile README all.c lua.hpp lua.ico
   lua.pc luavs.bat min.c noparser.c strict.lua
   src/external/mit/lua/dist/src: print.c
   src/external/mit/lua/dist/test: README bisect.lua cf.lua echo.lua
   env.lua factorial.lua fib.lua fibfor.lua globals.lua hello.lua
   life.lua luac.lua printf.lua readonly.lua sieve.lua sort.lua
   table.lua trace-calls.lua trace-globals.lua xd.lua
   src/lib/libc/string: strcspn.c strpbrk.c strspn.c
   src/sys/modules/lua: assert.h ctype.h errno.h inttypes.h limits.h
   locale.h math.h setjmp.h signal.h stdarg.h stddef.h stdio.h
   stdlib.h string.h

 Log Message:
 lua: updated from 5.1 to 5.3 work3

 That's not how we update 3rd-party code in the tree. We use cvs import
 and resolve conflicts afterwards.

Are there some guide or policy available?

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src

2014-07-19 Thread Lourival Vieira Neto
Hi Alan,

On Sat, Jul 19, 2014 at 5:43 PM, Alan Barrett a...@cequrux.com wrote:
 On Sat, 19 Jul 2014, Lourival Pereira Vieira Neto wrote:

 lua: updated from 5.1 to 5.3 work3

 Is this a well-planned and well-tested update, or does it feel rushed
 to get it done before the netbsd-7 branch?

I think this was as planned and as tested as Lua 5.1 import. However,
maybe, I'm missing something.

 I don't see any recent
 discussion in public mailing lists.

It was discussed on tech-kern [1] and also on icb/irc.

[1] http://mail-index.netbsd.org/tech-kern/2014/07/12/msg017341.html

 Also, if this doesn't get reverted for being rushed, then please
 import it on a vendor branch as per the usual practice.

Did you mean moving it from -current to a specific branch?

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src/sys

2014-07-19 Thread Lourival Vieira Neto
On Sat, Jul 19, 2014 at 5:45 PM, Alexander Nasonov al...@yandex.ru wrote:
 Lourival Vieira Neto wrote:
 Hi Alexander,

 On Sat, Jul 19, 2014 at 4:39 PM, Alexander Nasonov al...@yandex.ru wrote:
 ...
  What if GC kicks-in in softintr?

 It will call kmem_intr_free(9).
 How many times?

It depends on your script.

  What if the code tries to
  load a chunk of new code in softintr?

 What if? Have you tried that already?

 Do I have to? See also my point below about documentation.

No, you don't.

 You can formulate these questions and help to improve this work.

 Please document softintr interface in Lua (and other bits) so that
 I can write my first module and formulate my questions and report
 any problems.

Sure, at the appropriate time I will.

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src/sys

2014-07-19 Thread Lourival Vieira Neto
On Sat, Jul 19, 2014 at 6:34 PM, Alexander Nasonov al...@yandex.ru wrote:
 Lourival Vieira Neto wrote:
 On Sat, Jul 19, 2014 at 5:45 PM, Alexander Nasonov al...@yandex.ru wrote:
   What if GC kicks-in in softintr?
 
  It will call kmem_intr_free(9).
  How many times?

 It depends on your script.

 Ok, let me ask a more general question. Do you mix softintr Lua code and
 regular Lua kernel code in one Lua state?

Yes, I do.

 If you do, are you aware that
 GC running in softintr context can collect objects you created outside
 of softintr context?

Yes, I am.

 Have you thought of that?

Yes, I have.

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src/sys/sys

2014-07-17 Thread Lourival Vieira Neto
On Thu, Jul 17, 2014 at 3:14 PM, Marc Balmer m...@msys.ch wrote:

 Am 17.07.2014 um 16:55 schrieb Taylor R Campbell riastr...@netbsd.org:

 Module Name:  src
 Committed By: riastradh
 Date: Thu Jul 17 14:55:32 UTC 2014

 Modified Files:
   src/sys/sys: systm.h

 Log Message:
 Expand null macros to `do {} while (0)', not to nothing.



 Not that I object, but out of curiosity, what is this good for, or, why is 
 this need/a good thing?

 Index: src/sys/sys/systm.h
 diff -u src/sys/sys/systm.h:1.263 src/sys/sys/systm.h:1.264
 --- src/sys/sys/systm.h:1.263 Thu Apr  3 15:22:57 2014
 +++ src/sys/sys/systm.h   Thu Jul 17 14:55:32 2014
 @@ -1,4 +1,4 @@
 -/*   $NetBSD: systm.h,v 1.263 2014/04/03 15:22:57 christos Exp $ */
 +/*   $NetBSD: systm.h,v 1.264 2014/07/17 14:55:32 riastradh Exp $*/

 /*-
  * Copyright (c) 1982, 1988, 1991, 1993
 @@ -527,7 +527,7 @@ void assert_sleepable(void);
 #if defined(DEBUG)
 #define   ASSERT_SLEEPABLE()  assert_sleepable()
 #else /* defined(DEBUG) */
 -#define  ASSERT_SLEEPABLE()  /* nothing */
 +#define  ASSERT_SLEEPABLE()  do {} while (0)
 #endif /* defined(DEBUG) */

 vaddr_t calc_cache_size(vsize_t , int, int);


Wouldn't be '((void)0)' better?
Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src

2013-12-04 Thread Lourival Vieira Neto
 If the Lua int type was 128 bit uint64_t would convert differently. More
 correctly even as it would remain unsigned rather than wrapping to signed.
 This means code will break as the kernel uses uint64_t.

How would it break? Are you saying that the following code should break?

lua_pushnumber(L, INTMAX_MAX);
uint64_t x = (uint64_t) lua_tonumber(L, -1);

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src

2013-12-04 Thread Lourival Vieira Neto
On Wed, Dec 4, 2013 at 6:36 PM, Alexander Nasonov al...@yandex.ru wrote:
 Lourival Vieira Neto wrote:
 On Tue, Dec 3, 2013 at 9:26 PM, Alexander Nasonov al...@yandex.ru wrote:
  Do you have a test to prove that 'return 2^3' doesn't break in the
  kernel?

 Yes; you can just load the script you've mentioned. There is no reason
 to break anything. It is just defined as the multiplication operator.

 Well, you can certainly do this or tweak something else in the language
 but you should stop calling your thing Lua. Because it's not Lua anymore.

Are you aware that we have already changed the language number type?
Thus, we have already changed the language itself? If you insist, we
can call that Lua', kernel Lua, or whatever you like.

  Is there an issue with lua_error?
 
  I don't think that lua_error would work because lua_State isn't passed
  to luai_numpow(a,b). I wanted to say that you need a stub that breaks
  in a very noticeable way.

 I really miss your point here. Why lua_State should be passed to
 luai_numpow()? Anyway, I just checked and lua_error is working fine.

 What do you mean by working fine?

By that I mean lua_error() function is working properly, AFAIK.

 Are you talking about this change:

 #define luai_numpow(a,b)lua_error(L, )

 ?

No. Why I should? I really don't understand why you want to do that.

 It can't work because luai_numpow is used inside constfolding (defined
 in lcode.c) where L is undefined.

Yes. It wasn't designed to work in that way.

 Since you can't use lua_error, you may consider this

 #define luai_numpow(a,b) \
 panic(I take this opportunity to say that I need 
   a volunteer to implement luai_numpow in the kernel. )

 ;-)

 But seriously, you can easily implement it. It doesn't even have to be
 in a Lua core file. You can create a new file in you lua module directory.

Yes, we can (how Obama says =). However, I don't see this as a priority.

 Do you have an example that breaks it? If you want a verbose output,
 just push your error message (like, lua_pushstring(L, my error)) and
 call lua_error(L). If kern.lua.verbose is set, you will get my error
 printed.

 You guys keep adding sysctls. Why do you need kern.lua.verbose? I assume
 that all kernel Lua code should have a protected call at top-level. If
 they don't, you definitely want to see an error printed to the console.

I didn't add any sysctl. Anyway, it can be discussed in tech-kern@.

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src

2013-12-04 Thread Lourival Vieira Neto
On Wed, Dec 4, 2013 at 7:53 PM, Alexander Nasonov al...@yandex.ru wrote:
 Lourival Vieira Neto wrote:
 Are you aware that we have already changed the language number type?
 Thus, we have already changed the language itself? If you insist, we
 can call that Lua', kernel Lua, or whatever you like.

 It's documented:

 http://www.lua.org/manual/5.2/manual.html#lua_Number

 typedef double lua_Number;

 The type of numbers in Lua. By default, it is double, but that can be
 changed in luaconf.h. Through this configuration file you can change Lua
 to operate with another type for numbers (e.g., float or long).

Yes, and so do the arithmetic operations. And yes it does change the
language itself. Lua language ~= Lua interpreter.

  But seriously, you can easily implement it. It doesn't even have to be
  in a Lua core file. You can create a new file in you lua module directory.

 Yes, we can (how Obama says =). However, I don't see this as a priority.

 When I see something like this at work, I may set a reminder to follow-up
 after 6 months. I don't think mutt has this feature. Should I submit a PR
 instead?

Really don't know how you should proceed. As you are also a dev, you
could just implement this if you really miss exponentiation in kernel
Lua.

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src

2013-12-03 Thread Lourival Vieira Neto
Hi Martin,

On Tue, Dec 3, 2013 at 6:26 AM, Martin Husemann mar...@duskware.de wrote:
 On Mon, Dec 02, 2013 at 10:33:05PM -0200, Lourival Vieira Neto wrote:
 I also have no problem to step back and use 'long long', if _we_
 choose to reconsider that. IMHO, the fact that Lua 5.3 is using 'long
 long' is a good argument for that. I do prefer explicit width type,
 but my main argument is that 'long long' width could be lesser than 64
 bit.

 Using long long is as arbitrary as using int64_t.

I don't think so. If int64_t is defined, its width is 64 bit.

 The only reasonable other choice would be intmax_t (and I'm suprised
 Lua did not pick that).

Maybe we should move to intmax_t. My argument to use int64_t instead
of intmax_t was the Lua 5.3 manual (which states that integers have 64
bit width). However, the implementation uses 'long long' by default. I
see no reason to do not use intmax_t anymore (even preferring fixed
width, intmax_t looks like a better option).

 However, none of these make a difference with any of the currently
 supported architectures, so this argument is of cosmetic nature.

I agree. However, I think we should choose the more coherent type,
even that these types are the same in practice.

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src

2013-12-03 Thread Lourival Vieira Neto
Hi Valery,

On Tue, Dec 3, 2013 at 11:58 AM, Valery Ushakov u...@stderr.spb.ru wrote:
 On Tue, Dec 03, 2013 at 11:45:15 -0200, Lourival Vieira Neto wrote:

 Also, moving to intmax_t, would help in string library. It needs a
 length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no
 length modifier defined for int64_t. Using intmax_t we could just use
 j.

 There is: PRId64 c.

I think PRI/SCNd64 are conversion specifiers. In practice, I think
they will always expand to the same thing. But the standard
differentiates these two kind of specifiers. Doesn't it?

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src

2013-12-03 Thread Lourival Vieira Neto
Hi Justin,

On Tue, Dec 3, 2013 at 8:04 PM, Justin Cormack
jus...@specialbusservice.com wrote:

 On 3 Dec 2013 16:02, Christos Zoulas chris...@zoulas.com wrote:

 On Dec 3, 11:45am, ln...@netbsd.org (Lourival Vieira Neto) wrote:
 -- Subject: Re: CVS commit: src

 | Also, moving to intmax_t, would help in string library. It needs a
 | length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no
 | length modifier defined for int64_t. Using intmax_t we could just use
 | j.

 Yes, the other good side effect of intmax_t is that this is the best
 the machine can do in terms of integer range.


 No that is a bad side effect. It must always be 64 bits. In the kernel you
 have to deal with uint64_t which will behave differently if intmax_t is ever
 bigger than 64 bits, so code will break. So either use int64_t or what Lua
 uses and assert that that is 64 bits.

What side effect? Why it must always be 64 bit? Also, I don't get the
unsigned problem. What it will break? Moreover, if we don't have a
64-bit int type, what we should do? Disable Lua?

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src

2013-12-03 Thread Lourival Vieira Neto
On Tue, Dec 3, 2013 at 8:15 PM, Lourival Vieira Neto ln...@netbsd.org wrote:
 Hi Justin,

 On Tue, Dec 3, 2013 at 8:04 PM, Justin Cormack
 jus...@specialbusservice.com wrote:

 On 3 Dec 2013 16:02, Christos Zoulas chris...@zoulas.com wrote:

 On Dec 3, 11:45am, ln...@netbsd.org (Lourival Vieira Neto) wrote:
 -- Subject: Re: CVS commit: src

 | Also, moving to intmax_t, would help in string library. It needs a
 | length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no
 | length modifier defined for int64_t. Using intmax_t we could just use
 | j.

 Yes, the other good side effect of intmax_t is that this is the best
 the machine can do in terms of integer range.


 No that is a bad side effect. It must always be 64 bits. In the kernel you
 have to deal with uint64_t which will behave differently if intmax_t is ever
 bigger than 64 bits, so code will break. So either use int64_t or what Lua
 uses and assert that that is 64 bits.

 What side effect? Why it must always be 64 bit? Also, I don't get the
 unsigned problem. What it will break? Moreover, if we don't have a
 64-bit int type, what we should do? Disable Lua?

just got the 'side effect' part.. =)
-- 
Lourival Vieira Neto


Re: CVS commit: src

2013-12-03 Thread Lourival Vieira Neto
On Tue, Dec 3, 2013 at 9:26 PM, Alexander Nasonov al...@yandex.ru wrote:
 Lourival Vieira Neto wrote:
 I wasn't in that thread at that time. However, I'll carefully read it.

 If you haven't done so yet, it's a good idea to subscribe to
 source-changes-d@.

Yes, I subscribed already =). I just hadn't at that time.

 Anyway, I think that the missing implementation of luai_numpow()
 doesn't break anything.

 Do you have a test to prove that 'return 2^3' doesn't break in the
 kernel?

Yes; you can just load the script you've mentioned. There is no reason
to break anything. It is just defined as the multiplication operator.

 Is there an issue with lua_error?

 I don't think that lua_error would work because lua_State isn't passed
 to luai_numpow(a,b). I wanted to say that you need a stub that breaks
 in a very noticeable way.

I really miss your point here. Why lua_State should be passed to
luai_numpow()? Anyway, I just checked and lua_error is working fine.
Do you have an example that breaks it? If you want a verbose output,
just push your error message (like, lua_pushstring(L, my error)) and
call lua_error(L). If kern.lua.verbose is set, you will get my error
printed.

 I don't think I've created a problem to myself. We discussed it on the
 list and _we_ come to a conclusion. Note, I don't think that this
 overflow is a huge problem. The worst that could happen is to have a
 truncation of a greater number instead of 0. Anyway, I think it must
 be fixed and that any of the two presented solutions is fine. However,
 I also have no problem to step back and use 'long long', if _we_
 choose to reconsider that. IMHO, the fact that Lua 5.3 is using 'long
 long' is a good argument for that. I do prefer explicit width type,
 but my main argument is that 'long long' width could be lesser than 64
 bit.

 Lua is external software and we should keep our copy close to the
 original. If this sense long long is the best choice. However, Lua
 5.3 isn't released yet and Lua team may change their minds. They will
 have to go through similar problem with strtoll replacement, though.

I agree, we should keep the implementation close to the original.
However, the whole point about luaconf.h is to adapt Lua without
changing its implementation. IMO, we should choose the best LUA_NUMBER
type for us. In this case, I think it is intmax_t (as already stated
by Christos), if we won't use a fixed width type.

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src

2013-12-02 Thread Lourival Vieira Neto
Hi Alan,

 Log Message:
 changed lua_Number to int64_t

 This was actually two logical changes:

 * move strtoimax from the userland-only part of libc to the common part 
 that's also
 usable by the kernel.

 * change lua_Number to int64_t for the kernel Lua implementation.

 I would have preferred to see two separate commits.  Even with only
 one commit, the log message should have described both changes.

Sorry for that. I posted the patch on tech-kern, and I thought that it
was OK for single committing. Next time I'll separate it better.

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src/common/lib/libc/stdlib

2013-12-02 Thread Lourival Vieira Neto
 Module Name:src
 Committed By:   joerg
 Date:   Mon Dec  2 12:20:44 UTC 2013

 Modified Files:
src/common/lib/libc/stdlib: strtoimax.c

 Log Message:
 Fix aliases.

Sorry about that.. my bad!

Regards,
-- 
Lourival Vieira Neto


Re: CVS commit: src

2013-12-02 Thread Lourival Vieira Neto
Hi Alexander,

On Mon, Dec 2, 2013 at 8:38 PM, Alexander Nasonov al...@yandex.ru wrote:
 Lourival Vieira Neto wrote:
 Yes, it isn't. But, please note, I didn't change that now. I just
 merged it in one single file. Though I think we need implement integer
 exponentiation, I think that is not a priority. IMO, it is a TODO.

 Well, I assume that any raised issues should be resolved before moving
 broken stuff around. See the link to my review below.

I wasn't in that thread at that time. However, I'll carefully read it.
Anyway, I think that the missing implementation of luai_numpow()
doesn't break anything. Yes, of course, a*b != pow(a,b); but, it was
left in that way just for convenience. I don't see this as a main
issue anyhow.

 If you wanted to keep this item in TODO list, you'd better picked
 lua_error rather than lua_mul ;-)

Is there an issue with lua_error? Anyway, having two different
luaconf.h was a real issue. I have problems including the wrong header
with a little more complex Lua kmods (such as luadata). In fact, all
Lua kmods were including the wrong luaconf.h file, because of the
order of inclusion (-I's on Makefile). It didn't explode because they
weren't using lua_Number, but I had a real hard time trying to debug
this on luadata, once that compiling a kmod that uses a double type
isn't raising an error on amd64 (don't know why).

  2. If intmax_t is a greater type than int64_t, the below doesn't
  handle overflow:
  #define lua_str2number(s,p)((int64_t) strtoimax((s), (p), 10))

 I'm considering two approaches:

 1) creating an auxiliary function based on strtoimax():
 ...
 2) creating an auxiliary function based on strtol template

 I think you created some problems for yourself by using int64_t. I was
 going to tell you that Lua 5.3 uses long long for 64bit integers but I
 saw your question on lua-l about it.

 I didn't mind using long long in the kernel when we discussed that topic
 but some other people convinced you to use explicit width type ;-)

I don't think I've created a problem to myself. We discussed it on the
list and _we_ come to a conclusion. Note, I don't think that this
overflow is a huge problem. The worst that could happen is to have a
truncation of a greater number instead of 0. Anyway, I think it must
be fixed and that any of the two presented solutions is fine. However,
I also have no problem to step back and use 'long long', if _we_
choose to reconsider that. IMHO, the fact that Lua 5.3 is using 'long
long' is a good argument for that. I do prefer explicit width type,
but my main argument is that 'long long' width could be lesser than 64
bit.

Regards,
-- 
Lourival Vieira Neto