On Tue, Dec 3, 2013 at 9:26 PM, Alexander Nasonov 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 tha
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@.
> Anyway, I think that the missing implementation of luai_numpow()
> doesn't break anything.
Do you have a test to
On Dec 3, 10:04pm, jus...@specialbusservice.com (Justin Cormack) wrote:
-- Subject: Re: CVS commit: src
| 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 br
On Tue, Dec 3, 2013 at 8:15 PM, 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
>
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
On Tue, Dec 03, 2013 at 08:51:00PM +, Manuel Bouyer wrote:
> Module Name: src
> Committed By: bouyer
> Date: Tue Dec 3 20:51:00 UTC 2013
>
> Modified Files:
> src/sys/arch/xen/xen: evtchn.c
>
> Log Message:
> Remove the "evtchn_do_event: handler %p didn't lower ipl %d %d\n" pr
On 12/3/13 12:51 PM, Manuel Bouyer wrote:
Module Name:src
Committed By: bouyer
Date: Tue Dec 3 20:51:00 UTC 2013
Modified Files:
src/sys/arch/xen/xen: evtchn.c
Log Message:
Remove the "evtchn_do_event: handler %p didn't lower ipl %d %d\n" printf.
With help from Robert E
On Tue, Dec 3, 2013 at 2:05 PM, Christos Zoulas wrote:
> In article
> ,
> Lourival Vieira Neto wrote:
>>Hi Valery,
>>
>>On Tue, Dec 3, 2013 at 11:58 AM, Valery Ushakov wrote:
>>> On Tue, Dec 03, 2013 at 11:45:15 -0200, Lourival Vieira Neto wrote:
>>>
Also, moving to intmax_t, would help i
In article ,
Lourival Vieira Neto wrote:
>Hi Valery,
>
>On Tue, Dec 3, 2013 at 11:58 AM, Valery Ushakov 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 (L
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 co
Hi Valery,
On Tue, Dec 3, 2013 at 11:58 AM, Valery Ushakov 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 modifi
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:
Hi Christos,
On Tue, Dec 3, 2013 at 11:22 AM, Christos Zoulas wrote:
> In article <20131203082610.ga21...@mail.duskware.de>,
> Martin Husemann 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_
>>>
Hi Martin,
On Tue, Dec 3, 2013 at 6:26 AM, Martin Husemann 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
In article <20131203082610.ga21...@mail.duskware.de>,
Martin Husemann 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'
On Mon, Dec 02, 2013 at 11:10:43PM -0800, Matt Thomas wrote:
>
> On Dec 2, 2013, at 6:28 PM, Joerg Sonnenberger wrote:
>
> > Module Name:src
> > Committed By: joerg
> > Date: Tue Dec 3 02:28:51 UTC 2013
> >
> > Modified Files:
> > src/lib/libc/compiler_rt: Makef
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 argume
17 matches
Mail list logo