geekosaur | (pipes are the only things I see that care) | 00:00 | |
MasterDuke | ah, now i get what you mean | ||
timotimo | why would you build a function that always returns false instead of just using a null pointer for that? | 00:02 | |
geekosaur | because you do that once at setup instead of having to test every time you want to use it | ||
which is to say, the same crash is prob ably lurking in other code paths that don't checl | 00:03 | ||
urgh, typing... | |||
00:04
travis-ci joined
|
|||
travis-ci | MoarVM build canceled. Samantha McVey 'Get travis to build fake i686 builds and build all branches' | 00:04 | |
travis-ci.org/samcv/MoarVM/builds/216151343 github.com/samcv/MoarVM/compare/0a...2c5f2074f5 | |||
00:04
travis-ci left
|
|||
geekosaur | ...in fact MVM_io_is_tty() has that same bug :) | 00:05 | |
MasterDuke | it looks to me like is_tty is only over called by MVM_io_is_tty | 00:06 | |
*ever | |||
geekosaur | oh wait, that is that function | 00:07 | |
ok, if it's only got the one entry point then you can change it there | |||
I do wonder why it's abstracted that way, but oh well | |||
geekosaur had to haul the ticket back up and ... oh right, it's talking about that | 00:08 | ||
in any case you either need the false-returning stub or you need to make sure is_tty is not NULL | |||
but you also need to verify that introspection is not NULL | |||
MasterDuke | running a rakudo spectest with the added is_tty NULL check | ||
in addition to the introspection check | 00:09 | ||
samcv | travis-ci why you cancel my builds :( | ||
MasterDuke | but somewhat relatedly, what about github.com/MoarVM/MoarVM/blob/mast...o/io.c#L53 | ||
i don't see native_descriptor in any of the introspections | 00:10 | ||
samcv | i would like a way to cross compile moarvm. maybe there is one already? would like to add that to our test matrix | ||
geekosaur | it's there, in the thing I quoted earlier it's mvm_fileno | 00:11 | |
MasterDuke | so how does native_descriptor map to mvm_fileno | ||
geekosaur | samcv, you hit the time limit on the build | 00:12 | |
MasterDuke, github.com/MoarVM/MoarVM/blob/mast...o/io.h#L98 | 00:13 | ||
MasterDuke | geekosaur++ | ||
geekosaur | had to dig it up on github, I've been tooling through my local checkout :) | ||
MasterDuke | yep, been switching back and forth myself | 00:16 | |
00:18
travis-ci joined
|
|||
travis-ci | MoarVM build canceled. Samantha McVey 'Get travis to build fake i686 builds and build all branches' | 00:18 | |
travis-ci.org/samcv/MoarVM/builds/216151343 github.com/samcv/MoarVM/compare/0a...2c5f2074f5 | |||
00:18
travis-ci left
|
|||
samcv | ahhh dammit | 00:19 | |
3 minutes and it cancels the build | |||
Geth | MoarVM: MasterDuke17++ created pull request #568: Add a check that introspection->is_tty is not NULL |
00:20 | |
MasterDuke | timotimo++, geekosaur++ | 00:21 | |
00:39
travis-ci joined
|
|||
travis-ci | MoarVM build passed. Samantha McVey 'Put back travis somewhat' | 00:39 | |
travis-ci.org/samcv/MoarVM/builds/216160202 github.com/samcv/MoarVM/compare/a5...d96482c5d4 | |||
00:39
travis-ci left
|
|||
samcv | i think this is the correct thing to do for this nursury compilier warning | 00:46 | |
github.com/samcv/MoarVM/commit/7b0...77dabb73dd | |||
if anybody wants to tell me otherwise. I think i have done the righ thing here. unless there's something I don't know about why that char * was added | |||
full explaination is in commit description | 00:47 | ||
geekosaur | many compilers won';t let you do ops on (void *) | 00:48 | |
and IIRC the C standard guarantees (char *) to have maximal alignment compatibility | 00:49 | ||
hm, actually I'm not sure it can do that because it still permits PDP10s where ... uh | 00:50 | ||
so, hm. this is a screw case of sorts but casting to (char *) is least incorrect here | |||
samcv | why can we not compare void *'s? | 00:51 | |
they have no forced alignment so are the least restrictive type | |||
geekosaur | actually it;s not the comparison /per se/, it's the subtraction that is illegal because pointer subtraction is by the size of the pointed-to thing and for (void *) that is 0 | ||
samcv | so casting as (char *) could theoretically change something on some machine somewhere | ||
geekosaur | and yes, casting to (char *) will break on PDP10s and the like because they need to use sub-word addressing (words are 36 bits. you don't want to know.) | 00:52 | |
but afaik the last PDP10 was shut down over a decade ago :) | 00:53 | ||
anyway some compilers will warn you and pretend (void *) is (char *) (on any hardware created since, uh, 1980 or so that is valid) if you add/subtract with a (void *), but others will throw errors | 00:56 | ||
so you;re trading one warning/possible error for another. you *can't* do this 100% portably --- and you probably shouldn't expect to, given it's a virtual machine implementation | |||
samcv | ok so we actually want to multiply the size of an int times a void * | 00:58 | |
geekosaur | (moarvm would need to rethink a number of of its implementation decisions, and probably take a significant performance hit, to be portable to machines like that. not worth it.) | ||
samcv | err subtract | 00:59 | |
MasterDuke | samcv: slight change in subject again, but have you seen this file raschipi linked over in #perl a while ago? www.cl.cam.ac.uk/~mgk25/ucs/example...8-test.txt | 01:02 | |
samcv | hmm. will look at in a sec brb | ||
geekosaur | like I said, you will get at least a warning either way. your version is an error in some compilers. the current one works on every machine anyone will care about, given that moarvm is not currently portable to machines on which it won't work anyway | ||
(in fact C on those machines has some odd behaviors, because the standard says sizeof (char) == 1 always and that's not compatible with DEC-style sub-word addressing.) | 01:03 | ||
...which is why that cast discussed earlier is necessary per the standard, in fact. pointers behave very differently on such architectures. | 01:05 | ||
timotimo | so will we just be using intptr (or is it intptr_t?) for this? | 01:06 | |
or what? | |||
geekosaur | hm. intptr_t is probably the most correct one | 01:07 | |
the advantage of the current code is it should fail compile on weird architectures. intptr_t will succeed and have weird behavior | |||
(or succeed and the "weird behavior" is your memory arena is 4x larger than you thought it would be, depending on how the C compiler implements (char *)) | 01:08 | ||
basically this is one of those places where the C standard shows cracks; its approach to old-style architectures is "we made it legal, but good luck doing something sane" | 01:10 | ||
so if all you care about is silence every warning, intptr_t is the way to go. but make sure you prevent building on any architecture that doesn't use 8-bit directly addressable bytes, because it will silently do the wrong thing because you shut off the warnings that there is no right thing. | 01:11 | ||
samcv | also would it be good to not have those be void *'s? the structs | ||
i mean they point to actual values yes? | |||
reading comments in threadcontext.h now | 01:12 | ||
geekosaur, in my tests i get the same result for subtracting numbers from void * as i do from (char *) void* | 01:17 | ||
geekosaur | yes, you will with gcc or clang. probably not with msvc, that is one that throws a compile error | 01:18 | |
samcv | but the right side is void *? so it can compare int * > void *? | ||
geekosaur | you won;'t get wrong results unless you happen to have a working 12/18/36-bit DEC in your basement | ||
samcv | or it's the subtraction riht? | 01:19 | |
not the > symbol? | |||
geekosaur | [29 00:51:55] <geekosaur> actually it;s not the comparison /per se/, it's the subtraction that is illegal because pointer subtraction is by the size of the pointed-to thing and for (void *) that is 0 | ||
[29 00:56:14] <geekosaur> anyway some compilers will warn you and pretend (void *) is (char *) (on any hardware created since, uh, 1980 or so that is valid) if you add/subtract with a (void *), but others will throw errors | |||
gcc and clang will let you get away with it (in gcc I think you need -Weverything for that warning); clang will likely always warn about it being non-standard-compliant to add/subtract from a (void *) | 01:20 | ||
samcv | kk thanks | ||
geekosaur, would you support simpifying it with less parens? github.com/samcv/MoarVM/commit/652...018da90ee3 | 01:22 | ||
geekosaur | I was thinking about that. I'd be fine with it but many people do get confused about the relative precedence of casts vs. member access | 01:25 | |
(that said, one of those two sets was clearly superstitious parens :) | 01:26 | ||
samcv | yeah | 01:27 | |
01:48
ilbot3 joined
02:39
benchable6 joined
03:29
committable6 joined
|
|||
samcv | geekosaur, there's always the Enterprise™ solution to supresing errors github.com/samcv/MoarVM/commit/dd9...adb8ece74e | 05:22 | |
not sure what/if the error code is in MSVC, but that's one option for errors we know are fine. obv the macros wouldn't be in that file. i have no opinion on using them or not | 05:23 | ||
06:05
domidumont joined,
brrt joined
06:11
domidumont joined
|
|||
brrt | .tell timotimo you can't do arithmetic with void pointers legally | 06:14 | |
yoleaux2 | brrt: I'll pass your message to timotimo. | ||
samcv | hey brrt :) | ||
brrt | hey samvc | ||
samcv | |||
samcv | brrt, is that because it could cross byte lines? | ||
brrt | no | ||
samcv | because void * is the least restrictive pointer type | 06:15 | |
geekosaur | because pointer arithmetic needs to know the size of the thing pointed to, and (void *) does not have a size | ||
brrt | it's because the C compiler spec likes to leave things undefined, and C compiler writers bounce on every opportunity to screw you | ||
geekosaur | 'p + 1' for some pointer p advances by sizeof *p, not by 1 byte | ||
brrt | or so the rust evangelism taskforce tells me | ||
samcv | ah kk geekosaur | ||
geekosaur | but what is the size of (void)? | 06:16 | |
samcv | very true | ||
brrt | Everything; and the monk was enlightened | ||
samcv | so a short pointer will advance how much? | ||
brrt | 2 bytes | ||
but it's not possible to have a pointer 'between' byte lines | 06:17 | ||
a byte is by definition the smallest addressable unit of storage | |||
geekosaur | so (void *) arithmetic is meaningless. as I mentioned earlier, some compilers will fudge this and assume (char *) behavior, but this is not blessed by the standard | ||
brrt | (a byte *doesn't* have to be 8 bits wide, though) | ||
samcv | yeah | ||
brrt | and some clang / llvm developer will use that as a 'gotcha' and screw you | 06:18 | |
samcv | :P | ||
geekosaur | actually that's not 100% true; the C standard has specific hacks in it so DEC minis and mainframes could do char addressing using subword addressing modes | ||
like, a 36-bit PDP10 word can be sub-addressed in multiples of 3 bits | 06:19 | ||
brrt | i had no idea | ||
how on earth | |||
samcv | magic | ||
that's actually interesting. but i'm sure there's some very real reason for it | |||
geekosaur | special addressing modes in the CPU | ||
so, when emulating IBM-style (that is, byte) addressibility, one specifies a 9-bit subword and thereby gets 4 addressable subwords from a 36-bit word. | 06:20 | ||
brrt | right | 06:21 | |
geekosaur | (if you've ever noticed the "tenex" command in FTP, it's about telling a remote PDP10 server to do that and then mask off the top bit to pretend to be octets. if you didn't do this, you got garbage from a file transfer because of the mismatch) | ||
samcv | so it's like this? `size_bar foo; foo + X` is really `foo + sizeof(size_bar) * X` | 06:23 | |
err and foo is a pointer | |||
should have said `size_bar *foo` | |||
geekosaur | foo + X = (char *) foo + X * sizeof *foo | 06:24 | |
roughly | |||
(also casting back, derp) | |||
so you can add 1 (or x++, or whatever) to get the next element of an array regardless of what the size of an array element is | |||
samcv | and it advances by sizeof for that thing | 06:25 | |
will nail that to my brain | |||
geekosaur | (and yes, moarvm has had a few bugs from forgetting that; I diagnosed one of them a few months ago :) | 06:26 | |
samcv | heh | ||
thinking of changing this size_t index to MVMStringIndex github.com/MoarVM/MoarVM/blame/mas...ops.c#L232 | 06:27 | ||
looks like 4 years ago that line was added (with the size_t) | |||
is there any reason it shouldn't be changed to MVMStringIndex (MVMuint32 btw) | 06:28 | ||
unless maybe it's faster to index++ in a loop? i'm not sure | 06:30 | ||
geekosaur | size_t suggests to me that something from libc is being invoked at some point | 06:31 | |
uhhhh | 06:34 | ||
so it's size_t in callers but MVMint64 in MVM_string_substrings_equal_nocheck | 06:35 | ||
samcv | yeah | ||
geekosaur | this seems problematic on non-64-bit | ||
samcv | i don't like it | ||
geekosaur | likewise the lack of casting when it uses memcmp() which will expect size_t | 06:36 | |
(this is also why MVMuint* is not the right answer) | |||
samcv | in MVM_string_substrings_equal_nocheck ? | 06:37 | |
geekosaur | yes | ||
samcv | ok. sorry did i link you to line 201 | ||
yeah that could be problematic. | |||
geekosaur | yes, I went digging further since that's where the index gets used | ||
samcv | I more want to change it here github.com/MoarVM/MoarVM/pull/565/...130f8cR658 because it doesn't use memcmp | 06:39 | |
06:40
brrt joined
|
|||
brrt | correct | 06:41 | |
samcv | MVM_string_equal_at_ignore_case gets a MVMint64 and i am thinking about casting that to a MVMStringIndex | ||
and then in the place i want to make sure it's inlined it already uses MVMStringINdex | |||
geekosaur | again, needs thought on 32-bit since MVMStringIndex is MVMuint32 | ||
this whole thing is rife with 32/64 bit confusion :( | 06:42 | ||
samcv | will MVMuint32 perform differently on 32bit? | ||
geekosaur | it'll be faster since a 32 bit CPU can't do 64 bit math directly | ||
samcv | yeah | 06:43 | |
so MVMStringIndex is fine then right? | |||
since it's 32bit uint | |||
geekosaur | but my worry is not speed, it's correctness. if something is declared 32-bit and then you use it with a 64-bit value, it could conceivably with large enough strings become negative | ||
samcv | it's a uint though so it can't get negative | ||
or do you mean when it gets casted? | 06:44 | ||
geekosaur | it can still be truncated though | ||
samcv | yes but a truncated 64bit number can never be negative for a uint32 | ||
geekosaur | sigh | ||
samcv | which is part of the reason uint32 seems apealing | ||
geekosaur | I should not have said negative, I should have just pointed out the truncation | ||
samcv | yeah | ||
geekosaur | the point is you do not get what you think, you can get something different | ||
samcv | what would you like to happen? | 06:45 | |
have a check for high values and have it throw or just return negatory? | |||
geekosaur | and if you do this on a big-endian CPU then it gets worse because something can use the wrong half of a 64-bit value as the 32-bit value | ||
samcv | i wasn't sure how to handle this | ||
ah very true | |||
geekosaur | I think string ops need to decide whether they are using 32 or 64 bit indexes, first off, and use them consistently. | 06:46 | |
samcv | i agree | ||
geekosaur | (I don't think 64 bit makes sense for a string offset on current hardware. But if everything consistently uses MVMStringIndex then changing it is just adjusting that typedef.) | ||
samcv | yeah | 06:47 | |
geekosaur | ...but then you have the library routines that want size_t, and if that's smaller than MVMStringIndex then you have problems again | ||
so either you provide your own versions of memset/memcpy/memcmp etc., or you fix MVMStringIndex to size_t | 06:48 | ||
samcv | and then check bounds? and assume we don't run on anything under 32bit? | ||
geekosaur | yes (and checking bounds has repeatedly been a problem...) | ||
I would not bother with <32 bit, I would be surprised if perl6 even worked on such systems | 06:49 | ||
unless someone wants to rewrite moar to use huge memory model in 16 bit mode --- uhhh, best just to declare such systems unsupported | 06:50 | ||
huge memory model = huge pain in the tuchis | |||
(and, er, not much in the way of actual memory protection, so bugs = corrupting someone *else's* memory) | 06:52 | ||
(80286 did have some memory protection, just nowhere near sufficient. 80386 introduced actual memory protection. non-Intel 16-bit CPUs generally didn't even have as much memory protection as the 80286 did; you could write to any memory at any time) | 06:54 | ||
samcv | intel chips today even have all kinds of modes like real mode and protected mode etc. very interesting how much really old modes the cpu can still be put in | 06:55 | |
geekosaur | high end xeons don't have the pre-80386 modes any more, iirc | ||
samcv | nice | 06:56 | |
geekosaur | that's part of what pushed industry support for UEFI boot, which can boot in 386+ mode unlike the old BIOS that had to boot in real mode | 06:57 | |
samcv | geekosaur, regarding MVM_STATIC_INLINE what return type should i return for optimum chance of getting inlined | ||
the most performance sensitive spot it's just in a while loop with if (myfunction) | |||
so how can i make sure it gets inlined on 32 bit as well as 64 | |||
or should i not bother and just keep it as MVMint64. it really only returns 1 or 0, so it's just a binary return value | 06:58 | ||
i would think it would be `int` type, but you probably know better than I do | |||
geekosaur | I'd use int for that. 64-bit return value on a 32-bit CPU probably won't inline since it's got to do hackery to return it (iirc it ends up passing a secret pointer to write the return value to) | 07:00 | |
samcv | it's my birthday today. | 07:12 | |
reminds me i need to back up my hard drive | |||
brrt | happy birthday! | 07:44 | |
(also, not seeing the relation with hard drive backups, but anyway) | |||
samcv | well it reminded me i haven't done it in a while | 07:48 | |
not sure why, but it did | 07:49 | ||
08:01
zakharyas joined
09:20
praisethemoon joined
|
|||
praisethemoon | hello | 09:20 | |
brrt | hi praisethemoon | 09:21 | |
what's up | |||
what can we help with :-) | |||
praisethemoon | oh wow ^^ thanks for the great welcome | ||
I would like to know if I can target moarvm from my yet to finish language | 09:22 | ||
nwc10 | "Yes", but I don't know how hard it would turn out to be, or if anyone else has done it yet. (I certainly haven't). I think that there are examples of starting PHP and Ruby as part of the course documentation for github.com/edumentab/rakudo-and-nq...als-course | 09:24 | |
one would need to write parts of the backend in NQP | 09:25 | ||
brrt | what nwc10 said | ||
nwc10 | and that is the limit of what I know. | ||
brrt | can i ask what kind of language you are writing and what features made you think of using MoarVM? | ||
praisethemoon | well, my language is more like java, statically typed, object oriented, but with more functional aspects | 09:26 | |
well I just heard of moarvm from reddit, www.reddit.com/r/Compilers/comment...e/dckwv1t/ | 09:27 | ||
And I thought I would investigate a little bit | 09:28 | ||
Honestly, I never wrote a perl line in my life :( | |||
but there seems to be a lot vms for it, parrot, and here is moarvm | |||
oh sorry, got wrong reddit permalink ^^ but it's the last comment on that thread | 09:32 | ||
reading through the docs, honestly, this seems to be a great project! | 09:34 | ||
You guys are doing an awesome job :) | |||
09:42
domidumont joined
09:46
domidumont1 joined
|
|||
brrt | sorry, was on lunch for the moment | 10:11 | |
so | |||
MoarVM can probably accomodate your language well enough | 10:12 | ||
… and if you'd write a more-or-less static language it could, probably, perform decently | 10:13 | ||
however, compared to the JVM or the CLR, it will not be fast | |||
praisethemoon | brrt, hope you had a good meal :3 | 10:16 | |
timotimo | yo | ||
yoleaux2 | 06:14Z <brrt> timotimo: you can't do arithmetic with void pointers legally | ||
praisethemoon | Why wouldn't it be fast? | ||
brrt | it's not nearly as mature as either of these platforms | ||
and it assumes a high degree of polymorphism, so it implements a bunch of safeguards | |||
timotimo | what safeguards is spesh unable to throw out? | 10:20 | |
jnthn | timotimo: Where to start... :-) | 10:31 | |
Though type checks of assignments into containers is probably the biggest one :) | |||
From a "Perl 6 impact" point of view | |||
timotimo | ah, mhm | 10:35 | |
last night while trying to fall asleep i thought "we should totally teach the fast path binder to invoke 'where' clauses from the signature" | |||
jnthn | There's surely other bits too :) | ||
It does? :) | |||
timotimo | that's cool | 10:36 | |
praisethemoon | ahh I see brrt, how I'm sure it does not consume as much memory as the JVM x) | 10:48 | |
brrt | that's possible, yes | 10:49 | |
timotimo | nqp doesn't use a lot of memory | ||
praisethemoon | frankly I don't want to target jvm neither clr, i want something different | ||
Zoffix | praisethemoon: IIRC you can set JVM to use a different gc method. By default it uses ram for speed or somesuch | 10:50 | |
timotimo | if you target nqp, you're getting jvm for free. and also javascript, partially | ||
praisethemoon | experimentation is innovation \o/ | ||
11:13
vendethiel joined
|
|||
Geth | MoarVM: b4a8919ccf | (Timo Paulssen)++ | src/6model/reprs/P6opaque.c mention debug_name in errors about uncomposed repr |
11:14 | |
11:34
domidumont joined
11:46
domidumont1 joined
11:49
praisethemoon joined
|
|||
praisethemoon | yo!* | 11:49 | |
brrt | hi again :-) | 11:50 | |
(or is that not what you meant? kind of difficult to tell on irc) | |||
praisethemoon | oh yes it is ^^ | 11:55 | |
Yo is like "hey" in japanese | 11:56 | ||
Zoffix | So all the rappers sing in Japanese? And here I thought... | 12:00 | |
praisethemoon | ahh xd | ||
Don't know about that :3 | |||
12:05
AlexDaniel joined
|
|||
praisethemoon | brrt, can I pm you? | 12:07 | |
brrt | well, you can, but i'm under no obligation to respond :-) | ||
why? | |||
or in other words, sure, go ahead | 12:08 | ||
timotimo | but there's also "ooooooi" in japanese | 12:23 | |
praisethemoon | timotimo, oh yes, a cute way to say hey | 12:33 | |
timotimo | last time i saw it was in breath of the wild :P | 12:34 | |
.. and before that in Wind Waker :D | |||
praisethemoon | ahh, yeah since zelda characters never talk x) | 12:37 | |
timotimo | breath of the wild has voiced cutscenes now | ||
praisethemoon | Really? | ||
brrt | (timotimo has Breath of the Wild? :-o) | 12:38 | |
praisethemoon | Brb | 12:39 | |
13:13
praisethemoon joined
14:08
AlexDaniel joined
14:36
AlexDaniel joined
14:46
brrt joined
15:10
brrt joined
15:33
praisethemoon joined
15:46
domidumont joined
17:52
praisethemoon joined
18:18
praisethemoon_ joined,
praisethemoon__ joined
|
|||
samcv | jnthn, how 2 crosscompile MVM for 32 bit on a 64bit machine? also dunno if you want to quickly check out the eqatic refactor, zhuomingliang has given me an approval after i made some changes, but you may want to check it quickly github.com/MoarVM/MoarVM/pull/565 | 18:46 | |
jnthn | samcv: Will be able to take a look soonish :) | 18:49 | |
(20 mins or so) | |||
samcv | kk :) | ||
jnthn | No idea about doing 32-bit build on 64-bit; I know with MSVC you just have a different toolchain set up in the environment | ||
But I suspect you mean on Linux :) | 18:50 | ||
samcv | yes | 18:53 | |
i tried using the Configure script but then at the end it gave me problems during linking | 18:54 | ||
well i also inserted `-m32` into the Makefile to make sure it made 32 bit builds | |||
Geth | MoarVM: samcv++ created pull request #569: Fix Various Compiler Warnings Explicitly cast as (const MVMuint*) in utf8_c8.c Fix another compiler warning in src/moar.c Make if statement in adjust_nursery() more readable Fix warning in VMArray.c Fix compiler warnings using PRIu64 for three more files Fix compiler warnings from moar.c and heapsnapshot.c (PRIu64) Use PRIu64 in fprintf's to fix compiler warning RE incorrect types |
18:57 | |
samcv | wow it put that all in the title. sad | ||
jnthn | Phew, now I can take a look :) | 19:14 | |
samcv | yay | 19:15 | |
Geth | MoarVM: d5621160ce | (Daniel Green)++ | src/io/io.c Add a check that introspection->is_tty is not NULL Since it is for pipes. Fixes MoarVM issue #561 |
19:21 | |
MoarVM: 5ee5dcc331 | (Jonathan Worthington)++ | src/io/io.c Merge pull request #568 from MasterDuke17/fix_SEGV_in_is_tty_check Add a check that introspection->is_tty is not NULL |
|||
jnthn | samcv++ | 19:24 | |
Done reviewing :) | |||
samcv | great. made indent change. after travis i'll merge it :-) | 19:25 | |
jnthn | :) | 19:26 | |
Thanks, nice improvement :) | |||
19:35
praisethemoon joined
|
|||
timotimo | travis isn't doing anything at the momend :< | 19:44 | |
"We stopped accepting new builds because of an issue with our logs DB." | |||
samcv | ah | 19:48 | |
rude | |||
timotimo | what does the db think it's doing? | 19:50 | |
samcv | 'emergency database maintainance' doesn't sound very reasuring | ||
timotimo | We are resuming build processing. New build logs should appear, but recent build logs may be unavailable until further notice. | 19:52 | |
so that's nice | |||
samcv | yay | ||
timotimo | you could probably stop #1895 as it's been quickly superceded by #1896? | 19:54 | |
samcv | so 1.5 hours of downtime = how many projects cpu hours and how much backlog | ||
timotimo | *all* of the backlog | ||
samcv | what is 1895. our PR numbers and issue numbers don't go up that high | 19:55 | |
oh build number? | |||
timotimo | it's the same PR | ||
travis-ci.org/MoarVM/MoarVM/pull_requests here | |||
samcv | kk will cancel outdated ones | 19:56 | |
samcv is jelous since rakudo's is building :| but ours isn't | 19:57 | ||
timotimo | pff, damn those rakudo folk | 19:58 | |
samcv | maybe travis jobs go in the order of the number of 🌟's your project has | 20:04 | |
timotimo | oh look, your compiler warning pr is building | 20:05 | |
samcv | yay | 20:06 | |
we need more stars to get higher on this list github.com/showcases/programming-l...es?s=stars | |||
timotimo | that crystal lang thing came out of absolutely nowhere from my perspective | 20:10 | |
and how the hell is python so far down on that list? | |||
samcv | idk. maybe it doesn't excite people very much | 20:20 | |
oh that's the repo for “cpython” not python | |||
or is that python. idk i'm not a python programmer | |||
timotimo | that's the reference implementation | 20:22 | |
almost everybody universally uses that | |||
Geth | MoarVM/update_libatomic_ops: 4b9f6da1be | (Timo Paulssen)++ | 40 files bring in latest libatomic_ops changes from ivmai/libatomic_ops b7014e65d87c407b69ce1cc372c05939fa99c188 |
20:47 | |
timotimo | when's the last time we updated our libuv submodule? | ||
samcv | is there a newer release? | 20:48 | |
looks like we have 2015.12.15, Version 1.8.0 (Stable) | |||
version 1.11 is out | 20:49 | ||
timotimo | sounds like we'll want to explore getting that pulled in | ||
or maybe 1.10? is that how they make stable releases? | |||
even/odd? | |||
samcv | i have 1.11 and have compiled with that before | ||
and it worked fine | |||
timotimo | we have like 2 weeks until release, right? | 20:50 | |
samcv | yep | ||
now is good as time as any | |||
timotimo | oh no ... | 20:51 | |
20:51
samcv left
20:53
samcv joined
|
|||
samcv | oops how did that happen | 20:53 | |
wonder if there's a way to make ZNC not actually leave a channel if it accidently closes the tab | |||
timotimo | znc has tabs? | 20:54 | |
samcv | no. my local client | ||
timotimo | ah | ||
write a little proxy that filters out /part | |||
samcv | there may be a plugin that just lets my client leave the room but then gives me the scrollback when i rejoin or whatever | 20:57 | |
timotimo | ah, perhaps | 20:58 | |
21:04
AlexDaniel joined
|
|||
timotimo | dinner time \o/ | 21:05 | |
samcv | yum | 21:08 | |
21:14
evalable6 joined,
mst joined
21:27
ZofBot joined
21:30
mst joined
|
|||
Geth | MoarVM/master: 8 commits pushed by (Samantha McVey)++
|
21:37 | |
21:52
mst joined
22:17
Voldenet joined
22:35
mst joined
22:44
mst joined
22:56
mst joined
|
|||
samcv | timotimo, github.com/MoarVM/MoarVM/commit/b4...df9c1R1150 | 23:01 | |
are you aware of this mistake in your commit | 23:02 | ||
Geth | MoarVM/master: 7 commits pushed by (Samantha McVey)++
|
23:04 | |
23:09
mst joined
23:17
mst joined
23:18
mst joined
23:22
mst joined
23:23
mst joined
23:25
Voldenet joined
23:26
Voldenet joined
|
|||
timotimo | uh oh | 23:33 | |
ouchies, good catch | |||
samcv | timotimo, how do i trigger those debug name errors | 23:34 | |
in perl 6 code i mean. | |||
timotimo | m: my $foo = Metamodel::ClassHOW.new_type(:name<Heyooo>); my $a = $foo.new; | 23:35 | |
camelia | No such method 'new' for invocant of type 'Heyooo' in block <unit> at <tmp> line 1 |
||
timotimo | m: my $foo = Metamodel::ClassHOW.new_type(:name<Heyooo>); my $a = nqp::create($foo); | ||
camelia | ===SORRY!=== Error while compiling <tmp> Could not find nqp::create, did you forget 'use nqp;' ? at <tmp>:1 ------> name<Heyooo>); my $a = nqp::create($foo)⏏; |
||
timotimo | m: use nqp; my $foo = Metamodel::ClassHOW.new_type(:name<Heyooo>); my $a = nqp::create($foo); | ||
camelia | Cannot assign a null value to a Perl 6 scalar in block <unit> at <tmp> line 1 |
||
timotimo | m: use nqp; my $foo = Metamodel::ClassHOW.new_type(:name<Heyooo>); $foo.add_parent(Any); my $a = nqp::create($foo); | 23:36 | |
camelia | No such method 'add_parent' for invocant of type 'Heyooo' in block <unit> at <tmp> line 1 |
||
timotimo | m: use nqp; my $foo = Metamodel::ClassHOW.new_type(:name<Heyooo>); $foo.^add_parent(Any); my $a = nqp::create($foo); | 23:37 | |
camelia | Cannot assign a null value to a Perl 6 scalar in block <unit> at <tmp> line 1 |
||
timotimo | hm | ||
m: use nqp; my $foo = Metamodel::ClassHOW.new_type(:name<Heyooo>); $foo.^add_parent(Any); $foo.^compose; my $a = nqp::create($foo); | 23:38 | ||
camelia | Cannot assign a null value to a Perl 6 scalar in block <unit> at <tmp> line 1 |
||
timotimo | oh | ||
m: use nqp; my Mu $foo := Metamodel::ClassHOW.new_type(:name<Heyooo>); $foo.^add_parent(Any); $foo.^compose; my $a = nqp::create($foo); | |||
camelia | ( no output ) | ||
timotimo | m: use nqp; my Mu $foo := Metamodel::ClassHOW.new_type(:name<Heyooo>); $foo.^add_parent(Any); my $a = nqp::create($foo); | ||
camelia | P6opaque: must compose before allocating in block <unit> at <tmp> line 1 |
||
timotimo | there we go | ||
see Metamodel/Naming.nqp to see how debug_name gets set |