Re: CVS commit: src
On Wed, Dec 4, 2013 at 7:53 PM, Alexander Nasonov 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
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). > > 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? Alex
Re: CVS commit: src
On Wed, Dec 4, 2013 at 6:36 PM, Alexander Nasonov wrote:
> Lourival Vieira Neto wrote:
>> On Tue, Dec 3, 2013 at 9:26 PM, Alexander Nasonov 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
Lourival Vieira Neto wrote:
> On Tue, Dec 3, 2013 at 9:26 PM, Alexander Nasonov 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.
Recent discussion on lua-l about some tweak:
http://marc.info/?l=lua-l&m=138494227416821&w=1
> >> 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"? Are you talking about this change:
#define luai_numpow(a,b)lua_error(L, "")
?
It can't work because luai_numpow is used inside constfolding (defined
in lcode.c) where L is undefined.
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.
> 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.
Alex
Re: CVS commit: src
On 3 Dec 2013 22:16, "Lourival Vieira Neto" wrote: > > Hi Justin, > > On Tue, Dec 3, 2013 at 8:04 PM, Justin Cormack > wrote: > > > > On 3 Dec 2013 16:02, "Christos Zoulas" 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? > 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. We always have a 64 bit type as you need it to eg read a filesystem. It may be emulated by the compiler but it works.
Re: CVS commit: src
On 3 Dec 2013 16:02, "Christos Zoulas" 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. Justin
Re: CVS commit: src/sbin/mount_tmpfs
On Wed, Dec 04, 2013 at 02:09:02PM +, Mindaugas Rasiukevicius wrote: > I mean you have them other way round: Right, fixed! Martin
Re: CVS commit: src/sbin/mount_tmpfs
Martin Husemann wrote:
> On Wed, Dec 04, 2013 at 01:45:51PM +, Mindaugas Rasiukevicius wrote:
> > I think you confused err() with errx(). Also, why bother with the
> > fraction and the floating point?
>
> The err vs. errx may be debatable, but since this is usual called via
> other programs the name of the program (and thus the man page to look
> up details) may be usefull.
I mean you have them other way round:
+ len = sizeof(ram);
+ if (sysctlbyname("hw.physmem64", &ram, &len, NULL, 0))
+ err(EXIT_FAILURE, "can't get \"hw.physmem64\": %s",
strerror(errno));
err() already appends the error string for you, while in in ram_fract()
and ram_percent() you want errx().
--
Mindaugas
Re: CVS commit: src/sbin/mount_tmpfs
On Wed, Dec 04, 2013 at 01:45:51PM +, Mindaugas Rasiukevicius wrote: > I think you confused err() with errx(). Also, why bother with the fraction > and the floating point? The err vs. errx may be debatable, but since this is usual called via other programs the name of the program (and thus the man page to look up details) may be usefull. Martin
Re: CVS commit: src/sbin/mount_tmpfs
"Martin Husemann" wrote: > Module Name: src > Committed By: martin > Date: Wed Dec 4 13:30:35 UTC 2013 > > Modified Files: > src/sbin/mount_tmpfs: mount_tmpfs.8 mount_tmpfs.c > > Log Message: > Provide variants of the -s option to allow limiting the tmpfs dynamically > at mount time to 1/Nth or to N percent of the available ram. I think you confused err() with errx(). Also, why bother with the fraction and the floating point? -- Mindaugas
Re: CVS commit: src
> 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
Am 04.12.13 00:26, schrieb Alexander Nasonov: > 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 discussed Lua 5.3 with Roberto Ierusalimschy during the Lua Workshop 2013. He said it will very, very likely be published in the current (release candidate) form, they have no plans to change anything anymore for the final release. He encouraged my to use this version, skipping 5.2, which is what we plan to do.
