**** BEGIN LOGGING AT Thu May 16 03:00:30 2019 **** BEGIN LOGGING AT Thu May 16 06:53:55 2019 May 16 08:02:05 jow could you please add a file to the download server cotaining the latest release? Like https://downloads.openwrt.org/latest May 16 10:05:00 hm, is it possible to have SOB/From in utf-8, like for example `Signed-off-by: 练亮斌 ` ? May 16 10:45:14 ynezz: git supports unicode, but in general it is preferrable to have the name written in a script everyone can (mostly) read May 16 10:49:08 is non unicode (slash utf-8 in practice) still a problem for someone? May 16 10:52:06 olmari: never head of slash utf-8, and google fails me May 16 10:52:27 slash... == /, quite literally May 16 10:52:33 unicode/utf-8 May 16 10:54:06 well, I think, that the scripts would have a problems already, as for example `Author: Bjørn Mork ` or even my name is not ascii May 16 10:58:16 not sure if this was meant as a reply to me, but what I meant is having the name in a form/character set that everyone can understand, and not just ugh .. "see" May 16 10:58:17 ynezz: I meant script as in alphabet/writing system, not ugh an executable file May 16 10:59:46 ok, got it May 16 11:01:07 patchwork (IIRC) used to have issues with unicode, but that is fixed since a few years (I remember rmilecki having "fun" with that ;) May 16 11:05:55 * karlp muses that if we expect eastern companies and devs to upstream, we're going to have to accept their names too... May 16 11:06:42 of crouse, that's a two way street as well. May 16 11:08:38 personally I see no issues with accepting non-ascii / non-latin-ish Sob / Author fields May 16 11:08:56 well, considering source code usually uses latin characters... May 16 11:09:31 karlp: doesn't look that east to me :) Signed-off-by: Toke Høiland-Jørgensen May 16 11:09:41 I don't have any voice here though May 16 11:10:12 this is more about Git (authorship) then about source code May 16 11:10:47 练亮斌 hardly translates to Liangbin Lian or does it? May 16 11:10:52 I see no issues with utf-8 in source code either. It should be perfectly acceptable to have unicode characters in comments, string literals etc. May 16 11:10:56 gch981213: ^ May 16 11:11:01 ack May 16 11:11:41 unless explicitly checking, IMHO I'd have a hard time knowing Liangbin Lian and 练亮斌 refer to the same person May 16 11:12:45 ynezz: btw, I am slightly unsure about the Lua 64bit number format May 16 11:13:18 ynezz: it could break some odd usecases in scripts May 16 11:13:27 jow: me neither, I didn't finished the testing yet May 16 11:14:22 jow: well, then the scripts should be fixed, shouldn't they? May 16 11:15:22 do you've some example in mind? May 16 11:16:03 I'm also unsure how it's going to affect the generated bytecode as well May 16 11:16:42 it will make the generated bytecode non-portable May 16 11:17:10 defeating the entire purpose of 030-archindependent-bytecode.patch May 16 11:17:40 at least you cannot precompile Lua code on the host from 64 to 32 bit or vice versa anymore May 16 11:18:33 hm, this 64-bit support should be enabled only for target May 16 11:18:55 LuCI supports precompiling *.lua files using luac on the build system for use on the target system May 16 11:19:09 for this the x86/host bytecode format has to match the target bytecode format May 16 11:19:31 I am not sure if and what other packages also rely on bytecode precompilation May 16 11:19:53 but I think at least some commercial offerings used that to slightly obfuscate their code May 16 11:21:06 maybe we could introduce a lua64 host build which is used when cross-compiling bytecode for a 64bit target May 16 11:22:13 or drop this patches http://lua-users.org/lists/lua-l/2013-11/msg00319.html May 16 11:24:32 original post describing the issues http://lua-users.org/lists/lua-l/2013-11/msg00118.html May 16 11:27:57 I could live with dropping lnum when a bit of performance benchmarking on 32bit mips yields no significant performance decrease May 16 11:28:37 at least for LuCI, the majority of the code operations are string oriented and everything computation intensive happens in custom C extensions anyway May 16 11:29:36 on the other hand it does not feel well that *any* numeric operation in Lua will be handled by emulated soft floating code May 16 11:30:24 maybe we could simply drop this patches for 64bit archs? May 16 11:31:05 then we need to introduce a 2nd host build of lua (lua64) which is then used to cross-compile bytecode May 16 11:32:22 sounds like a plan May 16 11:33:06 I cna take care of the LuCI mechanics May 16 11:46:49 ok, I've reopened the PR May 16 11:48:48 where's this lua patch you're talking about? May 16 11:49:04 I've had much pain over the years with our lnum patch vs "normal" 5.1... May 16 11:52:15 is this https://github.com/openwrt/openwrt/pull/2064 ? May 16 11:53:11 I'm somewhaht concerned abotu the _quite_ different semantics of lnum/no-lnum between different archs that this would imply May 16 11:54:12 I guess it might not really matter, as I'll still have to keep all teh lnum workarounds, and they'l just become "irrelevant ops" on "normal" lua May 16 11:54:16 ynezz, I just noticed two typos in my commit message for the HDRM200. I see that I refer to the old names of the gpios (from when I used gpio-export), and not gpio0/gpio21. Shall I submit a new patch? May 16 12:01:56 karlp: my concern is with code expecting certain integer wrap around semantics May 16 12:02:07 well, that too :) May 16 12:05:32 KanjiMonster: ynezz: old patchwork releases didn't support UTF/unicode properly, it's fixed for a very long time now May 16 12:21:20 kristrev: I didn't pushed it yet, so just pastebin the diff based on top of my staging tree and I'll apply it May 16 12:43:45 something like this? https://pastebin.com/S1zv0JKd May 16 12:48:36 kristrev: hard to spot the difference http://paste.ubuntu.com/p/yFqJt39Trf/ is that correct? May 16 12:50:34 kristrev: https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=20d4dd9a63ea421ebb675a18246d9227b3a9e07d May 16 12:51:21 ynezz: Yes, that looks correct. Sorry, I was not thinking straight and should have used the normal diff tool and then pasted. Thanks for fixing it May 16 12:51:59 One small thing in the commit. gpi0 should be gpio0 May 16 12:52:46 https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=5d9c6d0aa93270e45bca44c834a60dfe9e733360 May 16 12:53:14 Looks good, thanks May 16 12:53:23 Sorry about the mess, will try to proof-read better next time :) May 16 13:04:37 no problem, it happens to me all the time May 16 13:49:00 jow: fyi, that problem is not related to 64bit only I get -2147483648 with `lua -e 'print(0x80000000)'` on ath79 as well May 16 13:50:28 jow: while `lua -e 'print(0x80000000000)'` outputs correct 8796093022208 result May 16 15:45:06 ynezz: probably because the higher numbers force the use of doubles May 16 15:51:27 jow: indeed, any problem with this fix? May 16 15:53:43 ynezz: "this"? May 16 15:56:30 it's bug in lnum, isn't it? if it can handle 0x80000000000 then why it has problem with 0x80000000 ? May 16 15:58:54 ynezz: AFAICT the issue is in this function https://github.com/openwrt/openwrt/blob/master/package/utils/lua/patches/010-lua-5.1.3-lnum-full-260308.patch#L1504 - the wrong behaviour is even "documented" May 16 16:02:03 it probably needs to also reject if the resulting number is negative, not just if out of range, when retrying as hex May 16 16:03:22 or just return it as TK_NUMBER ? May 16 16:03:27 yes, it uses strtoul() to convert the numeric literal and falls back to double storage if strtoul() fails with erange May 16 16:03:43 problem is that cast from unsigned to signed when parsing from a hex literal May 16 16:05:14 right May 16 16:05:14 ynezz: Ah..That isn't an exact translation, because it represents the pronunciation only. But I think that's enough for an identification and will be way easier for people who don't know about Chinese to distinguish between names :D May 16 16:08:12 jow: a bit below it checks non-hex numbers for > LUA_INTEGER_MAX (which is signed max, not unsigned) to avoid that there, so adding the same check to the hex-case could be enough May 16 16:08:28 https://pastebin.com/raw/ySD3CB0t May 16 16:09:14 ynezz: I think > instead of >= May 16 16:09:24 LUA_INTEGER_MAX is 0x7fffffff May 16 16:10:01 apart from that it might work May 16 16:11:19 there is one more issue, this works only with musl libc May 16 16:11:42 why? May 16 16:14:19 well, might be something else May 16 16:14:42 lua -e 'print(0x800000000)' returns here 0 (gcc-8, glibc, x86/64) May 16 16:15:26 returns 34359738368 (gcc-7, muslibc, ath79) May 16 16:16:24 gch981213: ok, thanks for the explanation :) May 16 16:41:15 well that 0 is returned from strtoul in glibc instead of ERANGE May 16 16:44:25 errno is also 0, strange May 16 17:56:20 jow: do you know why we have `cc_version = lt 7.0` ? May 16 17:56:24 in buildbot May 16 19:19:13 we should probably consider increasing that May 16 19:27:23 win 21 May 16 19:27:29 -efail May 16 19:32:04 :) May 16 21:14:02 ynezz: yeah, shit like the difference in handling for decimal vs hex literals is one of hte lnum pain points. May 16 21:28:33 karlp: care to try https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=f51a36c23d720e4a0834016f5c6586cb46dbdf7f ? May 16 21:29:43 do you've some other failing test cases? May 16 21:29:51 I'm not trying anything now, I'm in a summer house til sunday, but I just want this sort of thing to be taken carefully, not just thrown in May 16 21:30:02 you also need to test with the decimal representations, not jsut the hex ones. May 16 21:30:06 you'll get different behaviour May 16 21:30:16 I don't even have access to my test systems from here sorry. May 16 21:31:03 I agree that the x64 stuff looks even worse than the normal ath79 style failures though :) May 16 21:32:09 I'm using hex representations as they exhibit more issues May 16 21:32:21 they exhibit _different_ issues :) May 16 21:32:25 or both so to speak May 16 21:33:21 anyway, I can't look at any of this in concrete til monday back in the office. May 16 21:33:32 I'll keep it in my staging repo for some time, so take your time, no problem May 16 21:33:43 thanks for even looking at it :) May 16 21:34:06 down the road though, it migh tbe nice to restore the versioned paths to th elua install, May 16 21:34:25 opens up for making it sane for having two parallel installs May 16 21:34:57 5.1 is good enough :) May 16 21:36:07 even just making it easier to try 5.1 and 5.1+lnum together perhaps :) May 16 21:38:33 I've got things like "local bitnative, err = loadstring("if 2 & 1<<1 then return true end")" to try and work out whether we have lua 5.3 or 5.1 May 16 21:41:05 yeah, bitwise ops is the only thing I probably miss in 5.1, but there's bitwise ops patch for 5.1 May 16 21:41:29 which one? :) May 16 21:41:42 there's bitop, which then _doesn't_ exist for 5.3, so you have to wrap it, May 16 21:41:47 5.2 has different ones, May 16 21:41:55 https://github.com/kraj/meta-openwrt/blob/master/recipes-support/lua/lua5.1/bitwise_operators.patch May 16 21:42:10 and then there's nixio which doesn't exist properly in normal host land May 16 21:42:32 ynezz: so, a patch you have to build your own lua with? the goal (for me at least) is having code that I can on on my desktop _and_ on openwrt. May 16 21:42:50 being able to use distro lua5.1 and plain luarocks without having to patch stuff is very appealing May 16 21:43:28 liek that patch is interesting, but it takes you into that realm of "we used lua as a base for our own private thing" May 16 21:44:15 yes, mostly Lua embedded in applications May 16 21:47:36 totally interesting and valid, but I feel rather out of scope for offering lua as an available interpreter in openwrt :) May 16 21:49:10 in other news, in this summerhouse, I got everything routed ipv6 May 16 21:49:28 which... meant half the internet was crap and/or unavailable until I turned off ipv6. :( May 16 21:53:50 I'll skip v6, I'll join the party with v8 :) May 16 21:54:21 heh May 16 21:54:31 I prefer 6L May 16 21:55:10 6L? May 16 21:55:50 Karlp: how or why? I mean having ipv6 shouldn't make stuff worse May 16 21:56:26 Also 6 line engine, not V, i think ;) May 16 21:57:01 I don't know, I just know that about half the internet was either non-responsive or slow and just turning off v6 on the wifi connection to this 4g router made everything instantly better. May 16 21:57:46 Makes no sense, while oddball rogue configs do exist May 16 21:58:27 all I ever hear is that v6 is the ghetto of busted configs on servers and lower priority routings, this is just another anecdote May 16 21:58:41 I wsa excited at first, but not so excited now... May 16 21:59:01 olmari: yeah that ;) May 16 22:00:22 I haven't had any problems with ipv6 after i got one.. in general May 16 22:01:44 ISP issues, networking, server.. and so on, but generally ip version has no play in those **** ENDING LOGGING AT Fri May 17 02:59:57 2019