|
01:47
ilbot3 joined
02:04
TimToady joined
02:07
stmuk_ joined
02:57
stmuk joined
07:12
zakharyas joined
07:22
zakharyas joined
08:18
domidumont joined
08:23
domidumont joined
15:58
zakharyas joined
16:38
zakharyas joined
16:43
domidumont joined
17:13
brrt joined
|
|||
| brrt | good * #moarvm | 17:14 | |
| i'm moving the tile list editing code to the tile list | 17:18 | ||
| and i'm going to exploit the fact that free(NULL) and realloc(NULL, size) are dwimmy | 17:19 | ||
| geekosaur | be careful with that... they're only dwimmy in some implementations | 17:23 | |
| brrt | then we conditionally compile a check for others | 17:24 | |
| nwc10 | I forget whether I knew whether any implementations where not C89 conformat for free() or realloc() | 17:27 | |
| (that might sound like it has too many negatives, but I can't think of a terser way to be accurate. What I meant was "as long as you don't assume anything that breaches what C89 says can be relied on, I *think* that you're fine. Because I think after 27 years implementations have got *most* things right) | 17:28 | ||
| fflush(NULL) - not so sure on that one | 17:29 | ||
|
17:30
Ven joined
|
|||
| brrt | i'd hope so :-) | 17:32 | |
| timotimo | we can just install a multi dispatch candidate for free(NULL) and realloc(NULL, size) | 17:34 | |
| ilmari | anything that doesn't handle free(NULL) ain't C, IMO | ||
| geekosaur | the most portable and reliable codebases avoid many of those assumptions though. because it may be right for "most" configurations and then blow up in your face in one key circumstance. :( | 17:35 | |
| ilmari | that's almost in the same territory as sizeof(char) == 1 | ||
| brrt | geekosaur: we already wrap free and friends in mvm versions | ||
| so that is what i meant by conditionally compiling a check :-) | 17:36 | ||
| in the category of bikeshedding, i'm going to rename MVM_DYNAR_* to MVM_VECTOR_* because that is slightly more common terminolgy today | 17:39 | ||
|
17:48
brrt2 joined
17:50
Ven joined
17:52
vendethiel joined
17:53
Ven joined
17:55
Ven joined
|
|||
| jnthn | Yeah, if you wanted to handle platforms that didn't do NULL frees correctly, I'd say just probe for 'em and define MVM_free and friends differently. That's one of the reasons we have 'em. :) | 18:03 | |
|
18:07
Ven joined
|
|||
| brrt2 | well, i have two-hour commutes for tbe forseeable future in which to implement all this | 18:07 | |
| :-) | 18:08 | ||
| jnthn | Every day? | 18:10 | |
| brrt2 | yep.... | 18:11 | |
| jnthn | 2 hours all told, or per direction? o.O | ||
| brrt2 | currently per direction. after relocating, in total | 18:12 | |
| jnthn | Wowser. 4 hours JIT hacking a day! | ||
| Hope it won't be too tiresome doing the commute though | |||
| brrt2 | hahaha yep :-D | ||
| hacking isn't really tiresome though | 18:13 | ||
| jnthn | Relocation soon? | ||
| brrt2 | hopefully | ||
| jnthn | No, but...travel sure as heck can be. | ||
| brrt2 | true | ||
| jnthn | *sigh* what on earth is with my connection... | 18:14 | |
| 1 97 ms 30 ms 27 ms 192.168.0.1 | 18:15 | ||
| ...97ms to the wifi router sat 2 meters away... | |||
| brrt2 | that is longish | 18:16 | |
| jnthn | Hm, and on next trace gets it in 1ms...but then hugely variable beyond that. wat. | ||
| nwc10 | jnthn: have you got some sort of newfangled IOT fridge, and it and the router are now best mates and having a private party (with your beer) to which you were not invited? | 18:36 | |
| because the numbers do seem rather drunk | 18:37 | ||
| brrt2 | can i find easily if the last use of a value is within a given basic block? | ||
| jnthn | Hm, a DU chain may help figuring that out, if you're computed them | 18:38 | |
| nwc10: Nope...tried restartign the router to see if that might help | 18:39 | ||
| brrt2 | i'd like to know if i can prove not having to store thinga :-) | ||
| and i kind of assumed that i could | |||
| jnthn | "last" is a little interseting to define when there's loops? :) | 18:40 | |
| arnsholt | jnthn: Too many neighbours on the same/adjacent WiFi channels, perhaps? | ||
| jnthn | Maybe, but more likely the thing just isn't really built to run for months on end | 18:41 | |
| lizmat | jnthn: DNS ? | ||
| jnthn | lizmat: That was was slow as everything else :) | ||
| It seems much better now | |||
| lizmat | did you do the traceroute -n | ||
| ok | |||
| arnsholt | Yeah, that's usually the case for home appliances | ||
| brrt2 | not-live-after is what i'm really after | 18:42 | |
| jnthn | I suspect it's been up a couple of months, so... :) | ||
| brrt2 decommute & | |||
| timotimo | i strongly advise against getting anything "internet of things" or "smart home" in the next ~200 years | ||
| everybody in that business right now has NO BUSINESS selling electronics that decide upon the physical world to people | 18:43 | ||
| there is so much utterly ridiculous crap out there in that sector | |||
| jnthn | You mean I shouldn't buy that toaster that prints reminder notes on my toast? | 18:45 | |
| cdn1.vox-cdn.com/thumbor/WkWHZTpCA...inal.0.png | |||
| timotimo | that one might be fine | 18:46 | |
| just don't get a "smart doorlock" that transmits its password unencrypted over bluetooth whenever you open or close it :) | 18:47 | ||
| jnthn | I...what... :P | ||
| timotimo | or one that won't let you back in when you were outside during an automatic firmware update | ||
| lizmat | jnthn: re ObjAt, how about making it a list_s rather than a str | ||
| and then have the appropriate infix:<eq> for faster comparisons ? | 18:48 | ||
| jnthn | lizmat: It's more likely to become an integer + a reference... | ||
| timotimo | or a wifi remote controllable electric outlet that makes itself reachable from outside your LAN by tunneling through a server in china, and also that server will let anybody control your outlet who knows or guesses your outlet's manufacturer-assigned ID ... and can't connect to WPA secured wifi networks | ||
| timotimo takes a deep breath | |||
| jnthn | The integer being the hash code and the reference being for comparison | ||
| lizmat | ok, if you have ideas about that, I'll ditch mine :-) | ||
| jnthn: that would also work for value types, I assume ? | 18:49 | ||
| jnthn | The point of ObjAt is primiarly value types, no? :) | ||
| nwc10 | timotimo: the "won't let you back in if it automatically upgrades" sounds like the sort of flaw that doesn't require you to explain software engineering to anyone to explain why it isn't fit for purpose. So how come that stuff is even on shelves? | 18:50 | |
| jnthn | lizmat: The key thing is to get rid of all the stringification though | ||
| nwc10 | I'm not quite explaining it well - it's like the nest fiasco - it's going to break in normal service. Not when the folks from Defcon start prodding. | ||
| lizmat | well, if you can quickly produce a hash of an object | 18:51 | |
| as in a SHA type of thing | |||
| jnthn | Quickly producing a hash is best done with integers | ||
| The problem we have now, though...is that we don't have a way of checking "did we get the right thing" back in Perl 6 space | |||
| Which is why our current ObjAt has to contain an exact specification of everything in the object | 18:52 | ||
| lizmat | especially since we don't have true object hashes yet | ||
| but I guess that's the same issue really | |||
| jnthn | Indeed. :) | ||
| Anyway, moar's hashes need...attention for at least 3 other reasons I can think of. | 18:53 | ||
| lizmat | ok... | ||
| then I won't worry about them in the short term :-) | |||
|
18:53
Ven joined
|
|||
| jnthn | (Among them, we have to turn all strings into flat Grampheme32 arrays to use them in the hash) | 18:54 | |
|
18:57
domidumont joined
|
|||
| lizmat | anyways, re RT #128931 | 18:57 | |
| synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128931 | ||
| lizmat | $ 6 '.WHICH.say for ({my class A {}}(), {my class A {}}())' | ||
| A|140523652015040 | |||
| A|140523652015064 | |||
| jnthn: does that look like a plan for now? ^^^ | 18:58 | ||
| timotimo | ah, i thought we finally had hash codes based on the iterator ... | ||
| jnthn | lizmat: Where did you grab the number from? | 18:59 | |
| lizmat | nqp::objectid | ||
| jnthn | Of...the type object? | 19:00 | |
| lizmat | jnthn: I basically removed the Mu:U candidate for .WHICH | ||
| jnthn: yup | |||
| jnthn | And there's still a Mu one, unconstrained? | ||
| lizmat | yup | 19:01 | |
| jnthn | That seems fine enough | ||
| lizmat likes fixing bugs by removing code | |||
| lemme run a spectest to be sure this doesn't break anything | |||
| Ah, all of the .WHICH tests fail now | 19:02 | ||
| well, one in 4 | |||
| maybe I should just change those tests to make sure the values are unique | 19:03 | ||
| rather than checking for a specific value | |||
| jnthn | ...they checked for a specific value? | 19:08 | |
| D'oh :) | |||
| Yeah, that's not so robust :) | |||
| I thought they just checked what .WHICH actually worked... | 19:09 | ||
| I guess easy way to check they're all unique is set(@a) == @a :) | |||
| Since the set is constructed on WHICH values :) | 19:10 | ||
| lizmat | jnthn: that's using an implementation detail of set to test :-) | 19:12 | |
| jnthn | I don't think so :) | 19:17 | |
| WHICH is now user-space value types implement identity for object hashes, etc. | 19:18 | ||
| *is how | |||
| hoelzro | o/ #moarvm | 21:20 | |
| saw this post a few days back, thought it would be interesting for the Moar crowd: medium.com/@MartinCracauer/generat....nf0a6b5jw | |||
|
21:37
kjs_ joined
|
|||
| jnthn | Indeed, thanks :) | 21:56 | |
| The Moar scheme, fwiw, is a read-test-call scheme fwiw | 21:57 | ||
| Which has its own bunch of trade-offs | |||
| The branch isn't so good, which is the bad news. However, the bit is in the object header, so it's most likely already in the L1 since you're already talking about the object. Each thread has its own remembered set so there's not contention around that. There is contention once on setting the bit, but after that it's read-only. But the other win is we have precise information on what objects have inter-gen refs, which makes GC times a little sho | 21:59 | ||
| The big downside of the Moar scheme is if you were to fork. | 22:02 | ||
| However...uh...fork + threads = pretty bad idea | |||
| timotimo | in general, yeah | ||
| if we give the user exact control over the underlying APIs, we can say "you can fork, but you'll have to handle the threads properly. haa-haa!" | 22:03 | ||
| jnthn | Well, if we want to get it right we should pubs.opengroup.org/onlinepubs/00969...tfork.html | ||
| timotimo | oh, there's a thing for that. nice. | ||
| jnthn | It's probably going to be a good bit of fun to make it work out though | 22:05 | |
| Probably the best way is to stop the world (as if we were going to do a GC) | |||
| Even then it's still a headache :) | 22:06 | ||
