|
01:00
tokuhirom_h joined
01:23
ilbot3 joined
01:41
tokuhirom joined
02:47
ilbot3 joined
02:54
vendethiel joined
03:43
tokuhirom joined
05:43
tokuhirom joined
06:25
tokuhirom joined
08:02
FROGGS joined
08:25
tokuhirom joined
09:44
mj41 joined
09:51
vendethiel joined
10:08
kjs_ joined
10:35
ShimmerFairy joined
10:39
leont joined
11:34
FROGGS_ joined
12:27
tokuhirom joined
13:20
kjs_ joined
14:28
tokuhirom joined
15:21
kjs_ joined
16:04
vendethiel joined
16:24
tokuhirom joined
16:42
BinGOs joined
17:29
TimToady joined
18:04
vendethiel joined
18:12
kjs_ joined
18:27
tokuhirom joined
|
|||
| dalek | arVM/even-moar-jit: 44b9a55 | brrt++ | 3rdparty/dynasm: Update dynasm to bugfixed version |
18:49 | |
| arVM/even-moar-jit: 183e63a | brrt++ | src/jit/core.expr: Add getf and setf expression macros Names are shamelessly taken from LISP. Doesn't seem to introduce new errors, which is something at least. Simplifies many templates tremendously. |
|||
|
19:01
tokuhirom_h joined
19:54
vendethiel joined
20:04
kjs_ joined
|
|||
| nwc10 | jnthn: IIRC you said that one of the advantages of updating the bytecode to be able to store literal strings as either UTF-8 or ISO-8859-1, was that for the latter one knows it has to be NFG already, so no need to process it | 20:50 | |
| that's no longer true now is it, for any string containing "\r\n" ? | 20:51 | ||
| if so, would the simplest fix be for the serialiser to always serialise strings containing \r\n as UTF-8, so that they go through the NFG input routines, even if the string is in the ISO-8859-1 range | |||
|
21:47
kjs_ joined
22:26
zakharyas joined
22:29
tokuhirom joined
22:45
kjs_ joined
|
|||