|
00:13
vendethiel joined
|
|||
| timotimo | so much bitrot in the moar-gdb.py | 02:13 | |
| (because gdb now runs that with python 3) | |||
| and there's just a bunch of annoying changes all over the place that make the code a bit worse sometimes | |||
| dalek | arVM/moar-gdb.py-python3: 6e5f50a | timotimo++ | tools/moar-gdb.py: a whole bunch of changes and debug spam for moar-gdb.py currently can't analyze the gen2 :( |
02:19 | |
| timotimo | but i'm really glad i finally started on this | ||
| it's been a bit overdue :) | |||
| the unbitrotting of that script, i mean | |||
| and now off towards bed | |||
|
02:48
ilbot3 joined
04:51
vendethiel joined
07:04
domidumont joined
07:09
domidumont joined
07:28
vendethiel joined
08:12
zakharyas joined
08:14
domidumont joined
08:38
sortiz joined
08:48
domidumont joined
09:37
vendethiel joined
|
|||
| sortiz | jnthn, Today I opened my first PR in MoarVM: Add serialize and deserialize to CPointer REPR. Your comments will be appreciated. | 10:30 | |
| jnthn | sortiz: I saw it. I worry just a little whether it'll be a foot gun (as in, people serialize pointers, which then of course point to total junk in most cases). :) | 10:33 | |
| So want to go look at the use-case that inspired the patch. | |||
| timotimo | the use case was to have a Pointer.new(-1) | 10:34 | |
| as a sentinel value | |||
| jnthn | o.O | 10:35 | |
| timotimo | that's what i thought, too | ||
| github.com/perl6/DBIish/commit/6f13c35d2e | |||
| jnthn | Given MoarVM bytecode files are architecture independent, I do worry a tad what's going to happen with that if you compile on a 32-bit platform and use the bytecode file on a 64-bit one :) | ||
| timotimo | yeah. ouch. | 10:36 | |
| sortiz | I totally aware of the traps to the unaware user. SQLite API uses that in a callback to mark a special case. | ||
| jnthn | Granted you're *meant* to use the thing as cache, but in reality folks are gonna fat pack. | ||
| And probably fat-pack bytecode | |||
| So if we end up with something JAR like some day...you can see the fun :-) | 10:37 | ||
| timotimo | well, if we fat-pack bytecode, might as well pack one for 32 and one for 64 | 10:38 | |
| sortiz | The actual patch uses all the architecture dependent tricks needed, thought. | ||
| jnthn | I just wonder if a simpler fix woulda been to s/constant/my/ :-) | 10:40 | |
| timotimo | probably, yeah | ||
| jnthn | Anyway, will look more closely at the patch | ||
| sortiz | I am clear that only works for such cases. Right now I avoid the constant, and construct it at runtime, no bit deal. | 10:41 | |
| But was nice that the constant works well until forced precomp and the P6 code looks great. :) | 10:43 | ||
| And in C that kind of markers "pointers" are common. | 10:44 | ||
| On the other side, if that can't work, rakudo should be aware and fail at compile time. | 10:47 | ||
| jnthn | The "cannot serialize" error *is* at the module's compile time, no? | 10:49 | |
| sortiz | Nop, the code compiles and runs. I detect the problem at panda install time. | 10:50 | |
| timotimo | so while you're testing it won't precompile at all? | 10:51 | |
| jnthn | I wonder if it's the silent "pre-comp failed, don't do it" thing | ||
| sortiz | Seems to me that at runtime, if precomp fails, nothing bad happen. | ||
| jnthn | Yeah...I think we should consider a warning in that case. | 10:52 | |
| sortiz | I detect the problem 'cus I try "panda --force install" and that 'force' forces the precomp | ||
| jnthn | "Could not precompile Foo::Bar; please either make the module precompilation-safe or mark it with `no precompilation`." | ||
| timotimo | and some way to get at the error message itself | 10:53 | |
| jnthn | *nod* | ||
| sortiz | My first workaround was to add 'no precompile;' to the module, but I continue digging until found my solution. | 10:55 | |
| jnthn | Yeah, worth it work DBIish | 10:56 | |
| s/work/for/ | |||
| sortiz | And the "no precompile" should be extended to module users, so I don't like that idea. | 10:57 | |
| jnthn | Well, my expectation is that the warning would be seen by module *developers* when they test | 10:58 | |
| And so clue them in that something is wrong, rather than not finding out until panda install. | |||
| sortiz | One unespected thing, to me, is that the --force given to panda propagates up to PR.precompile | 11:06 | |
| jnthn | I thought that we always precompiled on install? | 11:08 | |
| sortiz | The case was that I has an old DBIsh preinstalled, and never before try to install the new, panda refuses to reinstall it, so the --force. So I finally see the error. | 11:12 | |
|
11:26
vendethiel joined
|
|||
| sortiz | On other side, I doubt that can be arbitrary *instantiated* Pointers at compile time (unless the user want to shoot in the foot) and at runtime "Pointer[Foo].new(random).deref" can't be avoided ;-) | 11:29 | |
| *whats | 11:30 | ||
| *wants # Uff, I need to sleep. | 11:31 | ||
| nine_ | Actually if precompilation fails, we _should_ already get an error. | 11:43 | |
| sortiz | nine_, It's not what I saw. In fact panda (and travis-ci) were happy with the tests. Was until japhb++ reported issues at install time that my saga began. | 11:57 | |
| moritz | I guess our travis tests should run a "panda install ." in addition to running the tests | 12:00 | |
| sortiz | Agree | 12:02 | |
| nine_ | sortiz: is the error clearly a bug in your code? | 12:05 | |
| sortiz | Not a bug, was an attempt to make the code clear using constants. Imagine signal's SIG_IGN in perl6. | 12:07 | |
| nine_, The SQLite C API define a few constants to mark special cases in callbacks, so I try to emulate that in P6, and somewhat works. You can see the builds history of DBIish in travis. | 12:11 | ||
| nine_, In fact I was fixing a long standing SQLite bug, you can see github.com/perl6/DBIish/commit/bb1...cd3bef232b when the constant was introduced. | 12:19 | ||
| nine_ | The build was successful? | 12:20 | |
| Ah, because you removed the Pointer(-1) again | 12:21 | ||
| sortiz | That and the following. | ||
| I removed Pointer.new(-1) a few hours ago. See: travis-ci.org/perl6/DBIish/builds | 12:22 | ||
| The original commit was tested by travis's build #92, none has failed since. (The constant was removed for travis's build #97). So the precomp fails silently. | 12:37 | ||
|
12:44
vendethiel joined
|
|||
| sortiz | nine_, If needed I can do specific testing, with and without the offending code and report the results. | 12:49 | |
|
14:42
vendethiel joined
14:55
kjs_ joined
15:23
dalek joined
15:52
vendethiel joined
17:17
vendethiel joined
17:36
TimToady joined
17:38
kjs_ joined
18:16
kjs_ joined
18:19
vendethiel joined
18:20
kjs_ joined
18:55
domidumont joined
21:01
ggoebel16 joined
22:04
dalek joined
|
|||
| dalek | arVM: 7820317 | (Salvador Ortiz)++ | src/6model/reprs/CPointer.c: Add serialize and deserialize to CPointer REPR In C land sn common practice to use constant fixed pointers for special cases, for example signal's SIG_IGN. A naive "constant SQLITE_TRANSIENT = Pointer.new(-1);" in DBDish::SQLite::Native trigger the error at Panda's install time. This add the missing bits, pass all nqp, rakudo spectest and fix the issue. |
22:45 | |
| MoarVM: b41c30d | jnthn++ | src/6model/reprs/CPointer.c: | |||
| MoarVM: Merge pull request #341 from salortiz/cpointer-serialize | |||
| timotimo | aarrrggghhh, python's scoping rules caused my big WTF from yesterday | 22:56 | |
| jnthn | .oO( Its scoping apparently doesn't rule... ) |
||
| timotimo | i'm getting somewhere with moar-gdb.py again | 23:02 | |
| jnthn | timotimo++ | ||
| timotimo | just gotta find out why it's trying to dereference some obviously bogus pointers | ||
| flussence | .oO( "what are the scoping rules of an unladen python?" "python2 or python3?" "I don't know tha-AAAGH!" ) |
23:03 | |
| timotimo | and ... ugh, unicode in python3 | ||
| when will the pain end? :( | |||
| jnthn | I thought Python 3 was the one with gooderer Unicode? | 23:04 | |
| timotimo | ah | ||
| perhaps | |||
| i print((something something).encode('utf-8')) | |||
| and that just comes out as | |||
| b'dutraindutraien \x23\x49\x043 etc etc' | |||
| geekosaur | it's the one where it learned unicode, to everyone's regret | ||
| jnthn | It's something in bad French about trains? | 23:05 | |
| timotimo | yeah, i'm no longer supposed to encode it before printing | ||
| strings: | 23:06 | ||
| [================================================== 9 | |||
| assoc [====================================== 7 | |||
| QRegex [================================= 6 | |||
| NFA [=========================== 5 | |||
| 8D8EC6335AF518DA45550C209737037FBF219C57-1456680407.77609 [=========================== 5 | |||
| all those common strings! | |||
| jnthn | common strings...all those common strings...if you liked it shoulda put intern on it... | 23:08 | |
| diakopter | lolz | 23:10 | |
| timotimo | oh hey diakopter :) | ||
| diakopter | oh hey timotimotimo | 23:11 | |
| jnthn: I got vs2015 update 1 applied, woo. | 23:13 | ||
| time to torture it with rakmoar | |||
| timotimo | those strings are only a sample, btw | 23:15 | |
| timotimo turns up the extra samples | |||
| say, jnthn, do you remember during startup all those little 24 byte big arrays are being allocated to store REPRData (iirc) on p6opaques (or something); is that something the fixed size allocator could help us with? | 23:17 | ||
|
23:26
kjs_ joined
23:30
kjs_ joined
23:44
kjs_ joined
|
|||
| jnthn | diakopter: Nice...wonder if it'll lack the vs2015 JIT issue... | 23:54 | |
| timotimo: Yeah, we could FSA those | |||
| 'night, #moarvm | 23:59 | ||