pantsbuild #development

Channels

welcome

github-notifications

development

rough-minister-58256

06/13/2018, 5:56 AM

not bad

rough-minister-58256

06/13/2018, 6:00 AM

@rough-minister-58256 uploaded a file:

image.png▾

rough-minister-58256

06/13/2018, 6:00 AM

seems like this info at your fingertips would make it significantly easier to reason about rust code

rough-minister-58256

06/13/2018, 6:05 AM

hm, kinda weird that it interferes with typing

rough-minister-58256

06/13/2018, 6:51 AM

solved the above issue by making the method itself static and not using

self

rough-minister-58256

06/13/2018, 6:56 AM

got a tight cargo test loop via hotkey in intellij - type info, auto complete. much nicer than sublime w/ highlight only + alt-tab to terminal

average-vr-56795

06/13/2018, 8:24 AM

Yeah, intellij is pretty handy for rust! (It was much less good 3 months ago)

average-vr-56795

06/13/2018, 8:25 AM

As for the `self`/static thing: The problem there is that because the

and_then

block will be run off-thread, there are no guarantees that the object referred to as

self

actually exists which that callback in scheduled.

average-vr-56795

06/13/2018, 8:26 AM

Changing it from

&self

(reference to thing which must exist) to

self

(single owned reference of thing, which I can continue to own, move around on the stack, and guarantee exists when the closure runs) fixes the problem, but means that that

CommandRunner

can’t be used by anyone else after that call

average-vr-56795

06/13/2018, 8:27 AM

If the method is actually static, then making it static is a good solution. If you did need a

self

reference, the way to do that would’ve been, before the

and_then

call, to write

let runner2 = self.clone();

which gives you a new instance of

CommandRunner

which you can then move into the closure, and use

runner2

any time you want to use

self

in that closure

rough-minister-58256

06/13/2018, 8:27 AM

makes sense - the self reference in

and_then

dawned on me late

rough-minister-58256

06/13/2018, 8:28 AM

ah nice

average-vr-56795

06/13/2018, 8:28 AM

The error message is pretty awful. In general, if it’s not

self

that you’re leaking, the error message at least includes the name of the type of the thing you’re leaking (and sometimes even a pointer at the variable), but for some reason the error is much worse if it’s

self

average-vr-56795

06/13/2018, 8:28 AM

So if you see that and it’s not clear what to do, look for

self

references 🙂

rough-minister-58256

06/13/2018, 8:29 AM

heh nice

average-vr-56795

06/13/2018, 8:29 AM

Also, awesome work on that PR 🙂 It looks great, and rust futures take some getting to grips with!

👖 1

rough-minister-58256

06/13/2018, 8:31 AM

right on, really appreciate the pointers. definitely all starting to click now

rough-minister-58256

06/13/2018, 8:33 AM

off to bed - have a good one! 🙂

average-vr-56795

06/13/2018, 8:33 AM

Catch you soon!

aloof-angle-91616

06/13/2018, 5:39 PM

thinking of merging https://github.com/pantsbuild/pants/pull/5936 since ci is green

aloof-angle-91616

06/13/2018, 5:40 PM

(is that generally an ok action if review and ci are green?)

rough-minister-58256

06/13/2018, 5:40 PM

yep 🙂

👌 1

witty-crayon-22786

06/13/2018, 7:32 PM

blargh... so http://github.com/pantsbuild/pants/pull/5846 moved all substantive work off the main thread, and thus made it invisible to cProfile.

✨ 1

witty-crayon-22786

06/13/2018, 7:33 PM

before i start googling... what should i be using again?

witty-crayon-22786

06/13/2018, 7:33 PM

(...yappi i think)

witty-crayon-22786

06/13/2018, 7:33 PM

oh, hooray. google+Kris: https://github.com/pantsbuild/pants/wiki/Debugging-Tips:-multi-threaded-profiling-with-yappi

🔥 1

rough-minister-58256

06/13/2018, 7:40 PM

👍

aloof-angle-91616

06/13/2018, 9:58 PM

i'm testing the glibc binary against the pr that adds it to run the native backend tests and was able to reproduce more of the behavior we're seeing in travis (where it needs `crti.o`/etc). it's clear we're going to need to make some edits to the glibc release sources and makefiles before compiling them. we can do this with

sed

now, but i was wondering if it would make more sense to maintain a github fork of the glibc git and key into the SHA of that repo, because the automated edits may break in future releases.

aloof-angle-91616

06/13/2018, 9:59 PM

just gonna do that now because it's looking more difficult to automate

rough-minister-58256

06/13/2018, 10:58 PM

any reason we need to explicitly provide glibc for any build case vs consuming whatever glibc is on the system?