dalek | arVM: a7b842c | (Jimmy Zhuo)++ | src/6model/reprs/P6bigint.c: small cleanup |
03:15 | |
04:13
btyler joined
04:15
harrow joined
04:46
harrow joined
05:34
harrow joined
07:15
TimToady joined
07:19
mj41 joined
07:57
FROGGS joined
08:04
kjs_ joined
08:09
woolfy joined
08:10
woolfy left
08:16
rurban_ joined
08:40
dalek joined
08:47
zakharyas joined
09:01
brrt joined
09:02
zakharyas1 joined
09:09
kjs_ joined
|
|||
dalek | arVM/native-ref: 5aed474 | jnthn++ | / (6 files): Stub in native reference related ops. |
09:40 | |
09:54
btyler joined
10:16
avar joined
|
|||
dalek | arVM: c0bae2e | lizmat++ | / (6 files): Add readlink stub |
10:38 | |
jnthn | lol, the last two will be a merge conflict between them... :) | 10:39 | |
nwc10 | I was just thinking something equivalent when reading Liz's commit - it's a shame that there are massive diffs as a side effect of moving auto-generated things around | 10:40 | |
I'd not thought of conflicts | |||
lizmat | jnthn: sorry, but it should be easily fixed, no? Or do you want me to revert that last one until you merged ? | 10:52 | |
jnthn | lizmat: I teach advanced git courses, merge conflicts are the least of my problems. :) | 10:53 | |
lizmat | ok, *phew*, don't want to put more on your plate | ||
jnthn | Was just amused at the timing; changes to src/core/oplist are relatively rare, then two come along at once :) | 10:54 | |
brrt | jnthn - can you come by and teach $company at my $day-job even starting git techniques | 10:58 | |
they're all like 'whats a remote' over here | 10:59 | ||
arnsholt | My boss is still very suspicious of git. Doesn't want to fall prey to hype-chasing =) | 11:00 | |
brrt | lol | ||
jnthn | Hype-chasing? It's been almost 10 years... ;) | ||
arnsholt | Yeah, I know | ||
brrt lunch & | 11:01 | ||
arnsholt | So he's still on SVN | ||
Thankfully most of his repos I can just use git-svn on =D | |||
jnthn | API design is harder than merge conflicts. Hmmmm... | 11:02 | |
nwc10 | arnsholt: when it comes to doing the right thing to svn, I'm finding that techbase.kde.org/Projects/MoveToGi...ingSvn2Git is pretty damn good | 11:13 | |
(used git-svn for the previous humane termination of svn and it was not fab) | |||
and oh my, svn... | |||
it was 90 minutes to import a svnadmin dump of our 40,000 commit repo into a clean repo on my work desktop (Which has an SSD) | 11:15 | ||
and I think about 15 for svn2git to import the entire bloody thing into git | |||
one of these is the native tool | |||
one of these is not | |||
subversion.apache.org/roadmap.html - Release 1.9.0 - Q2 2014 (tentative) | |||
not as late as Xanudu, Duke Nukem Forever or Perl 6 | 11:16 | ||
11:16
kjs_ joined
|
|||
arnsholt | nwc10: And svn2git lets me interact with the SVN repo too? | 11:16 | |
nwc10 | I find it impossible to search for succesfully, but I know I once read a blog entry about how new svn committers get voted in once a year | ||
and they realised they were in a bad place when that year the list to vote on was empty | |||
arnsholt: "when it comes to doing the right thing to svn" => "when you are allowed to kill it" | 11:17 | ||
no, it doesn't | |||
but it looks to be better for a final conversion | |||
arnsholt | Yeah, that's what I thought | ||
nwc10 | svn was awseome. For a bit. | ||
Then better things arrived | |||
arnsholt | Getting rid of it is currently not an option | ||
The one I'm working with ATM, I might be able to get rid of | 11:18 | ||
nwc10 | but oh my, having had cause to look at the code of both recently the architecture of svn is "no obvious bugs" | ||
git is "obviously no bugs" | |||
and then you wonder why git is so fast | |||
because it's "the simplest thing that could possibly work", and almost no levels of abstraction | |||
(sorry if this sounds like a mix between a rant and a marketing spiel) | |||
arnsholt | The other one, ye olde repo of doom, with a pile of externals and 15 or 20 years of history, not so much | ||
nwc10 | but I'm finding so many little frustrations with the svn tooling | 11:19 | |
svnlook vs svn | |||
arnsholt | 25G logon/ | ||
nwc10 | repos vs checkouts | ||
arnsholt | On a 110G disk >.< | ||
Yeah, it's death by a thousand cuts | |||
nwc10 | no easy way to get some bits of data out | 11:20 | |
arnsholt | No one thing that really kills it, but the overall experience is just terrible | ||
nwc10 | although I realise now, it feels like svn is a library you code against in C | ||
git is a set of tools you glue together in shell | |||
(or maybe someone wrote something better than shell. any suggestions?) | |||
arnsholt | Heh | ||
nwc10 | and the latter is far better for both Manipulexity and Whipuptitude | 11:21 | |
arnsholt | The UI of git is pretty crazy, but the feature-set is awesome | ||
nwc10 | arnsholt: once you've proven a conversion works on the smaller repository | ||
can you chip away at the big one subtree by subtree? | 11:22 | ||
arnsholt | Might be possible | ||
Being the repo of doom, it really does want to be several smaller repos | |||
(And the bundled Java 1.4 or something like that *really* has to go) | |||
nwc10 | but Java is Java - surely the code can run on a newer JVM? :-) | 11:23 | |
arnsholt | Of course it does | 11:24 | |
But they had some kind of distribution pain at some point I think, and Java not being as widely available 15 years ago | |||
So they just bundled the whole damn thing | |||
And once it's in, it's not going out (obv) | |||
Oh, wait. It's Java 6, not 4 | 11:25 | ||
nwc10 | yay. | ||
arnsholt | But still messed up my NQP/JVM hacking, since the bundled "set things up" bashrc file *prepends* to $PATH | 11:26 | |
Did I mention that I don't like all of my boss's techincal decisions? =) | |||
nwc10 | so that would be the analagous problem to "I'd like to write code that uses features in v5.12, but /usr/bin/perl is only 5.8.8"? | ||
arnsholt | Sort of | ||
nwc10 | arnsholt: does your current boss like all of his previous self's choices? :-) | ||
arnsholt | He's the keeper of the repo, so it's perfectly tailored to his workflows | 11:27 | |
So he obviously doesn't see any problems with this approach =p | |||
lizmat | argh, I interpreted the sig wrong in the oplist :-( | 11:34 | |
dalek | arVM: c50bd77 | lizmat++ | / (3 files): Fix prototype on readlink stub |
11:37 | |
11:55
Ven joined
11:57
xiaomiao joined
11:59
ggoebel111111113 joined
12:02
arnsholt joined
12:04
lizmat_ joined
|
|||
FROGGS | how does readlink work? it just reads a reads and returns nothing? | 12:08 | |
lizmat: ^^ | 12:09 | ||
lizmat | well, no, it should return a string | ||
or fail, presumably | |||
FROGGS | +readlink w(str) r(str) then | ||
lizmat | so the w is for the input, and the r for the output? | 12:10 | |
FROGGS | w is writing == returning | ||
12:10
dalek joined
|
|||
FROGGS | like in: $w = readlink($r) | 12:10 | |
that's why the thing you return comes first | |||
12:10
moritz joined
|
|||
lizmat | ok | 12:11 | |
lizmat is learning | |||
(I hope) | |||
FROGGS | *g* | ||
12:12
[Coke]_ joined
12:13
sivoais joined
12:14
rurban__ joined
|
|||
dalek | arVM: c27b31d | lizmat++ | / (3 files): Hopefully got the readlink sig ok now |
12:14 | |
12:15
woolfy joined
|
|||
FROGGS | looks good to me | 12:17 | |
12:21
btyler joined,
japhb joined
|
|||
lizmat | so I need to return an MVMString from what appears to be a void *: | 12:46 | |
void* uv_fs_t.ptr | |||
Stores the result of uv_fs_readlink() and serves as an alias to statbuf. | |||
I'm not sure how to do that | |||
FROGGS jnthn suggestions? | |||
FROGGS | gimme a sec | 12:47 | |
lizmat | (MVMString *)req.ptr; # seems too succinct :-) | 12:48 | |
FROGGS | no, that's quite wrong :o) | ||
to check that uv_fs_t.ptr is a C string, I'd try to printf it first... like in: fprintf(stderr, "req.ptr = '%s'\n", (char *)req.ptr); | 12:50 | ||
okay, according to linux.die.net/man/2/readlink you get a C string, and I guess that libuv null-terminates the string from readlink(2) for us | 12:52 | ||
lizmat | so how do I convert a C string to a MVMString ? | 12:53 | |
FROGGS | * a result of the specified type. The type must have the MVMString REPR. */ | 12:54 | |
MVMString * MVM_string_ascii_decode_nt(MVMThreadContext *tc, MVMObject *result_type, const char *ascii) { | |||
err | |||
* Decodes a NULL-terminated ASCII string into an NFG string, creating | |||
* a result of the specified type. The type must have the MVMString REPR. */ | |||
MVMString * MVM_string_ascii_decode_nt(MVMThreadContext *tc, MVMObject *result_type, const char *ascii) { | |||
lizmat | Hmm... are we sure it's ASCII we get? | ||
I would assume UTF8, no? | 12:55 | ||
jnthn | I'd go with UTF8 for now | 12:56 | |
lizmat | MVM_string_utf8_encode_C_string then? | ||
jnthn | Mostly 'cus I think that's what happens elsewhere | ||
No, that's the wrong directly | |||
FROGGS | MVM_string_utf8_decode(tc, type_object, Cbuf, byte_length) | ||
jnthn | encode = MVMString => bytes (e.g. C string) | 12:57 | |
That's the one | |||
Just search for existing usages of it. | |||
FROGGS | lizmat: also note that creating an MVMString means that you are creating an object that our GC cares about | ||
creating (and therefore allocating) such a thing might directly trigger a GC run | 12:58 | ||
jnthn | Thankfully, it's probably also being done as the very last thing | ||
FROGGS | ... which will have nice side effects | ||
jnthn | So it's easy this time | ||
lizmat | yeah, the last thing | ||
jnthn | But yes, you do have to be very aware of the GC when working on Moar | ||
FROGGS | would just be nice to review a gist before committing | 12:59 | |
jnthn | I really should write a MoarVM hackers guide at some point | ||
lizmat | gist.github.com/lizmat/c68fda121ea7078e52cc | ||
only the "type_object" I'm not sure what to put ? | 13:00 | ||
and is the strlen ok? | |||
jnthn | Surely you're missing a return ? | ||
FROGGS | that's not perl :D | ||
jnthn | lizmat: tc->instance->VMString for type_object | ||
FROGGS | jnthn: I don't remember... do we free things we declare const? | 13:01 | |
jnthn | And yes, srlen | ||
FROGGS | srlen? | ||
jnthn | strlen :) | ||
lizmat | updated the gist | ||
jnthn | .oO( strlen steak ) |
||
.oO( I really should go shopping for lunch... ) |
13:02 | ||
lizmat | visitors, afk& | ||
jnthn | lizmat: Missing ; on end of last line, otherwise looks sane | ||
FROGGS | - if (uv_fs_readlink(tc->loop, &req, path_s, 0, NULL)) { | 13:03 | |
+ if (uv_fs_readlink(tc->loop, &req, path_s, NULL)) { | |||
I think | |||
lizmat | yeah, found that just now, FROGGS++ | 13:04 | |
and jnthn++ | |||
FROGGS | ohh, you have to care about readlink's return value | ||
jnthn | Ain't that what the if is doing? | ||
FROGGS | On success, readlink() returns the number of bytes placed in buf. On error, -1 is returned and errno is set to indicate the error. | ||
jnthn | Oh... | 13:05 | |
FROGGS | so, you have to record that and pass it off instead of strlen() | ||
lizmat | ah.... ok | ||
jnthn | So you can avoid the strlen | ||
Well, that refactor is also good in that you can get rid of the duplicate MVM_free(c_str); too | |||
By putting the result into a variable, do the free, then look at it. | |||
shopping & | 13:06 | ||
FROGGS | I guess we want to put the text of the possible error codes in an exception? | ||
linux.die.net/man/2/readlink | |||
but, that can be put in after it works | |||
lizmat | gist updated again | 13:10 | |
FROGGS | looks good | 13:11 | |
I guess an empty string will never happen? | 13:12 | ||
as the result of readlink I mean | |||
lizmat | then I guess we have a failure | 13:13 | |
FROGGS | probably | 13:14 | |
dalek | arVM: e98ea25 | lizmat++ | src/ (3 files): Hopefully final tweaks to get readlink working jnthn++ FROGGS++ for assistance |
13:24 | |
FROGGS | I always enjoy implementing ops in MoarVM | 13:27 | |
lizmat++ | |||
lizmat | $ ./nqp -e 'say(nqp::readlink("/tmp"))' | 13:28 | |
Failed to readlink file: Unknown system error | |||
:-( | |||
lunch& | |||
arnsholt | lizmat: That should probably fail with some kind of error though, unless your /tmp is a symlink | 13:31 | |
FROGGS | it should say "The named file is not a symbolic link. " | 13:32 | |
I guess we cannot use uv_strerror here | |||
nwc10 | if you want to test error messages, force a locale | 13:33 | |
else you get confused users and bug reports | |||
FROGGS | ohh, and also, it needs to be "if (pathlen >= 0) {" | 13:34 | |
13:55
zakharyas joined
|
|||
FROGGS | $ nqp-m -e 'say(nqp::readlink("/tmp"))' | 14:11 | |
Memory allocation failed; could not allocate 18446744073709551528 bytes | |||
jnthn | Whyever not? It's only 18 exabytes... | 14:14 | |
FROGGS | that's about a gazillion times Data's brane | 14:15 | |
In "The Measure of a Man", a Starfleet judge rules that Data is not Starfleet property. The episode establishes that Data has a storage capacity of 800 quadrillion bits, (88.81784197 PiB) and a total linear computational speed of 60 trillion operations per second. | 14:16 | ||
nwc10 | or -87 | ||
Peter_R | FROGGS, how do those op/s measure up to modern machines? | 14:31 | |
FROGGS | Peter_R: looks like an Intel Core i7 5960X does 336_000 operations per second | 14:35 | |
so, Data is quite good | |||
ohh, wait | 14:36 | ||
it is 336_000_000_000 instructions per second | |||
jnthn | Well, if you're doing a cycle = instruction approximation. :) | 14:37 | |
In reality, an instruction might take hundreds of cycles, or one cycle might process several instructions | |||
nwc10 | and the best video I've seen on that (so far) is www.infoq.com/presentations/click-c...n-hardware | 14:38 | |
FROGGS | the number I've shown is calculated using the Dhrystone benchmark | ||
we should ask Brent Spiner to do that too :o) | |||
lizmat | arnsholt: on OS X, /tmp is a symlink to /private/tmp | 14:41 | |
FROGGS | lizmat: I have a patch... | 14:49 | |
lizmat: can I commit or are you working on it? | |||
nwc10 | and a test for readlink on a known dir, known file, and nowknown missingnes? | 14:50 | |
lizmat | FROGGS: please patch :-) | ||
nwc10 | (am I being unhelpful?) | ||
FROGGS | nwc10: slightly | ||
lizmat | nwc10: well volunteered :-) | ||
FROGGS | because windows and filesystems and uff | ||
nwc10 | IIRC for Perl 5, readlink dies on systems that don't have the syscall | 14:51 | |
part of me is tempted to think that it's arguably also more logical for it just to return failure | |||
dalek | arVM: a910556 | FROGGS++ | src/io/fileops.c: fix readlink, the return value is just an error indicator |
||
nwc10 | (ie nothing is a symlink on an OS that doesn't support them, rather than it being an excepton to ask) | ||
but my brain can argue it both ways | |||
lizmat: there's another bunch of stuff in my stack that hopefully gets unblocked before that | 14:52 | ||
FROGGS | nwc10: I suspect we will return a Failure from P6 land, aye | ||
lizmat | FROGGS: I guess my original approach was best :-) | 14:59 | |
FROGGS | :o) | 15:01 | |
the problem is just that pathlen was 0 on success | |||
so it is not the ssize_t the readlink(2) returns | 15:02 | ||
libuv's documentation quite sucks here | |||
lizmat | $ ./nqp -e 'say(nqp::readlink("/tmp"))' | ||
private/tmp | |||
YEAH! | |||
ah, relative to the original path | 15:03 | ||
ok, I can live with that :-) | |||
FROGGS | me too :o) | ||
MoarVM$ nqp-m -e 'say(nqp::readlink("../p6-Text-CSV/Text/CSV.pm"))' | 15:04 | ||
../test-t.pl | |||
MoarVM$ nqp-m -e 'say(nqp::readlink("VERSION"))' | 15:05 | ||
Failed to readlink file: invalid argument | |||
MoarVM$ nqp-m -e 'say(nqp::readlink("foobarbaz"))' | |||
Failed to readlink file: no such file or directory | |||
I think that's okay | |||
15:07
kjs_ joined
|
|||
dalek | arVM: e0c9bb0 | (Jimmy Zhuo)++ | src/6model/reprs/P6bigint.c: fix comment style, FROGGS++ |
15:07 | |
15:30
Ven joined
|
|||
dalek | arVM/native-ref: 13a893c | jnthn++ | src/core/callsite. (2 files): Add some extra callsites. Will be needed by native fetch/store of the code pair container spec. |
15:53 | |
arVM/native-ref: db78722 | jnthn++ | src/6model/containers. (2 files): Extend container API for native handling. This also updates the code_pair container spec to match the extended API. |
|||
arVM: 4e79d84 | (Jimmy Zhuo)++ | src/io/fileops.c: free req.ptr in MVM_file_readlink |
16:04 | ||
jnthn | JimmyZ++ # nice catch | 16:06 | |
dalek | arVM/native-ref: 6b4f3fc | jnthn++ | src/ (3 files): Implement decont_[ins]. |
16:09 | |
JimmyZ | jnthn: raw.githubusercontent.com/rakudo/r...ontainer.c | 16:11 | |
jnthn: I didn't see any get_mu codes, Did I miss something? | |||
and get_nil() ... | |||
jnthn | JimmyZ: Urgh. But I think they're actually implemented in perl6_ops.c | 16:12 | |
Barely legal XXX C! | |||
It's exactly what we do in .h files, though. | |||
Declare "there's a function like this somewhere and you'll get it by link time" :) | 16:13 | ||
JimmyZ | yeah, the name make me thinks it's static :P | 16:14 | |
jnthn | Uh, yeah...we probalby should not have a non-static thing with an unprefux name... | ||
dalek | arVM/native-ref: 94dec40 | jnthn++ | src/ (3 files): Implement assign_[ins]. |
16:18 | |
16:52
synopsebot joined
17:01
sivoais joined
|
|||
TimToady | you guys do know that filenames are not guaranteed to be utf8? | 17:10 | |
TimToady overnighting in Medford, OR | |||
s/ing/ed/ | |||
jnthn | TimToady: Yes, but it's an OK first approximation for now, and it may be one of those places where NFG might help us (in so far as we can have a scheme where anything that ain't UTF-8 is handled as a synthetic when we make the thing a Str, so it round-trips) | 17:13 | |
And I'd rather the code consistently gets it not right so it's easy to grep all of those out. | |||
TimToady | I guess that's as good a story as any | ||
the alternative is to return either utf8 or blob8 and let the user deal with it, I suppose | 17:15 | ||
jnthn | I'm pretty sure the "make everyone use Buf for filenames" altnerative isn't going to fly with the majority of programmers out there... | ||
Since "filenames are strings" is pretty deeply embedded in developer culture everywhere... | 17:16 | ||
TimToady | well, synthetics composed of illegals is also a discontinuity, just elsewherely placed | 17:19 | |
but maybe the concept is useful generally | |||
17:26
FROGGS[mobile] joined
|
|||
arnsholt | jnthn: native-ref is towards fixing the $native++ problem, right? | 17:26 | |
17:26
FROGGS[mobile]2 joined
|
|||
jnthn | Yes, and is rw accessors for native attributes, and making native arrays work, and... :) | 17:27 | |
FROGGS | 'is rw' ftw! | ||
bbiab | |||
arnsholt | Indeed. Spiffy stuff going on these days! | ||
jnthn | .oO( Why solve one problem when you can solve 3 at once... ) |
||
arnsholt | Quite | ||
Both this and the parametric stuff is good for NativeCall too | |||
jnthn | Anyway, figured out how to do most of the pieces needed. | 17:28 | |
So at the moment working through implementing them. | |||
Though, I notice I'm rather hungry so maybe I should pause for dinner :) | |||
TimToady | do native refs know the limit of what they're refing? or are they always singular? | ||
jnthn | TimToady: Always singular at the moment, and naively they go via the same API as something doing a direct update of the thing would. | 17:30 | |
TimToady: However, I'm designing it so spesh will be able to "see through" that safety | |||
17:30
ingy1 joined
|
|||
jnthn | TimToady: Not to mention get rid of the taking/using of native references completely when inlining renders it uninteresting. | 17:31 | |
TimToady: For cases like $native-int++ I intend the static optimizer nail those. | |||
The dynamic case is more about when you inline an accessor method for a native attribute. | 17:32 | ||
TimToady | what about visiting a slice of an array? | 17:36 | |
thinking about Go's slice-refs here... | 17:37 | ||
jnthn | Example Perl 6 code that's use what you're thinking of? | 17:38 | |
(So I can make sure we're talking about the same thing... ) | |||
*that'd | 17:39 | ||
TimToady | can you ++ a native ref (not the thing referred to, but the pointer)? | ||
TimToady doesn't know what a native pointer looks like in Perl 6 yet... | 17:40 | ||
in Go I think you can ++ a slice and it'll do bounds checking for you | 17:41 | ||
jnthn | Ah | ||
No, don't have anything for that yet | |||
TimToady | it seems like an efficiency thing to have bounded pointers | ||
jnthn | But don't think the approach I'm taking will make it impossible to add that later. | ||
For now I'd like native arrays to work at all ;) | 17:42 | ||
Then we can get clever. | 17:43 | ||
TimToady | okay, just bear it in mind so you don't make it impossible later, thanks | ||
timotimo | jnthn: i'd like to hear how you imagined the "please compile an accessor method for me" thing to be implemented; i.e. which part does what where | 17:54 | |
17:59
lue joined
|
|||
jnthn | timotimo: OK...but dinner is ready, so after that :) | 18:03 | |
bbiab | |||
timotimo | OK | 18:04 | |
i think i want to get some food my own self | |||
18:10
tgt joined
19:22
kjs_ joined
|
|||
[Coke] | ugh, no food. :P | 19:32 | |
jnthn | Can't eat? :( | 19:34 | |
That's the wurst thing... | |||
dalek | arVM/native-ref: 3a55063 | jnthn++ | / (8 files): Start getting NativeRef REPR fleshed out. We put the kind of referenced thing and the primitive type as REPR data. This means there'll be a minor explosion of types for native references, but they align well with the way we'll want to do type specialization, so it's worth it. They'll also be invisible to most users (except those who go digging). |
19:39 | |
19:50
FROGGS joined
|
|||
[Coke] retroactively UGHS at jnthn++'s pun | 20:39 | ||
20:51
kjs_ joined
21:00
rurban__ joined
|
|||
dalek | arVM/native-ref: b268435 | jnthn++ | src/core/hll.c: Needn't NULL stuff with we calloc. |
21:00 | |
arVM/native-ref: b989127 | jnthn++ | src/core/hll. (2 files): Add HLLConfig entries for native ref types. |
|||
21:06
ingy joined
|
|||
dalek | arVM/native-ref: f951a73 | jnthn++ | src/ (3 files): Validate native references when adding to HLL. This means we can skip any checks later on and Just Use Them. |
21:25 | |
arVM/native-ref: f7b7985 | jnthn++ | src/6model/reprs/NativeRef.c: Serialization bits for NativeRef REPR data. |
|||
arVM/native-ref: c76e414 | jnthn++ | src/6model/containers.c: Stub native_ref container spec. |
21:40 | ||
22:04
FROGGS_ joined
22:27
colomon joined
22:29
colomon joined
22:37
woolfy left
22:45
nebuchadnezzar joined
23:15
colomon joined
23:34
colomon joined
|