<whyrusleeping>
haha, i didnt know that one was there yet
<whyrusleeping>
good find
<kallaballa>
:)
<whyrusleeping>
my issue with github issues for the faq is that the search functionality isnt as nice
<whyrusleeping>
we should srape the Q/A from there and move it somewhere else that looks nicer and is more searchable
<whyrusleeping>
not move, but mirror
grncdr has quit [Quit: Leaving.]
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
grncdr has joined #ipfs
<kallaballa>
how does "ipfs diag net" work? is it possible to somehow get a list of peers that have certain capabilities(/ipfs services)?
<whyrusleeping>
kallaballa: ipfs diag net is a recursive traversal of the network
<kallaballa>
whyrusleeping: starting with the bootstrap list?
<whyrusleeping>
we dont intend on keeping it around permanently, it just serves as a tool for us to debug things right now
<kallaballa>
ic
<whyrusleeping>
kallaballa: starting with any nodes you are connected to
<kallaballa>
ic. thx
<whyrusleeping>
yeep, no problem
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
ei-slackbot-ipfs has quit [Remote host closed the connection]
ei-slackbot-ipfs has joined #ipfs
<kallaballa>
i would like to tag peers in a swarm that run a certain service,. could i achieve that by pinning the same large value on each of them and use ipfs dht findprovs to find them?
<whyrusleeping>
kallaballa: you could do it that way, i'm just going to bed, but if youre around when i get up i can discuss other methods
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
<whyrusleeping>
findprovs wont always show all the peers for a given value
slothbag has joined #ipfs
<kallaballa>
whirusleeping: yeah. that would be awesome. thx
<cryptix>
gmorning
<whyrusleeping>
cryptix: you stayed up until 5:30am, kudos
<cryptix>
lol yea
<cryptix>
couldnt sleep
<whyrusleeping>
im feeling the same way right now... its nearly 4am here, laying in bed, trying to convince my brain that it needs sleep before the light comes again
<cryptix>
came home too fired up so i exhausted myself coding
<cryptix>
yea i know that one.. :)
<cryptix>
i wish you a decent amount of sleep anyhow :) need to catch some food
<cryptix>
oh and thanks for the pr reviews
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
grncdr has quit [Quit: Leaving.]
grncdr has joined #ipfs
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
grncdr has quit [Quit: Leaving.]
<ipfsbot>
[go-ipfs] cryptix pushed 1 new commit to refactor/coreResolve: http://git.io/vJujZ
<ipfsbot>
go-ipfs/refactor/coreResolve 4fb87c3 Henry: commands/object: remove objectData() and objectLinks() helpers
nickemery has joined #ipfs
nickemery is now known as ehmry
<ipfsbot>
[go-ipfs] cryptix force-pushed refactor/httpGateway from ce4f890 to 2a74b6a: http://git.io/vJujg
<wking>
so I get the "this is a convenient way to tunnel parameters across layers, because we don't have Python's **kwargs or similar mechanisms"
<wking>
But I'm still not sure where to draw the line after which you no longer need to use Contexts. Do we just use them in all our calls, and pass them down as far as we can to libraries we depend on?
Daboloskov has joined #ipfs
<wking>
It still seems like signals and handlers would be a way to interrupt overdue tasks, but probably not enough easier to be worth breaking from an idiomatic Go approach ;).
Daboloskov has quit [Client Quit]
Marklock has quit [Ping timeout: 246 seconds]
grncdr1 has joined #ipfs
grncdr has quit [Ping timeout: 244 seconds]
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
grncdr1 is now known as grncdr
<barnacs_>
wking: do you mean posix signals? how would you address a specific goroutine executing a task with those?
<barnacs_>
goroutines are multiplexed to os threads by the runtime n:m
torpor has joined #ipfs
Evermore is now known as nEvermore
nEvermore is now known as Evermore
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
inconshreveable has joined #ipfs
<wking>
barnacs_: yeah, you'd need a way to unwind that goroutine <-> thread mapping, but it still seems like an easier mechanism for signalling down the call stack than requiring every function to take a Context argument.
<wking>
especially since there are blocking calls in the stdlib that *don't* take Context arguments, and I don't see an alternative mechanism for interrupting those.
Marklock has joined #ipfs
<barnacs_>
wking: i guess you could just wrap those up so they can be cancelled in some way where it makes sense
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
torpor has quit [Quit: Leaving.]
<barnacs_>
i guess you may be able to close the underlying resource while the blocking call is in progress
<barnacs_>
or worst case, you let it finish and discard the result, but in the mean time you can return an error on cancellation and continue with the higher level task
torpor has joined #ipfs
anshukla has joined #ipfs
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
Daboloskov has joined #ipfs
Daboloskov has quit [Client Quit]
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
Marklock has quit [Ping timeout: 246 seconds]
<whyrusleeping>
wking: you do not want to use any sort of unix signals to control any sort of program flow
<whyrusleeping>
wayyy too slow, and also way too difficult to manage
<whyrusleeping>
hundreds of goroutines needing signal handlers at every level of the calls stack would be beyond messy
lgierth has joined #ipfs
G-Ray has joined #ipfs
Daboloskov has joined #ipfs
notduncansmith has joined #ipfs
G-Ray has quit [Quit: Konversation terminated!]
notduncansmith has quit [Read error: Connection reset by peer]
torpor has quit [Quit: Leaving.]
Daboloskov has quit [Client Quit]
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
G-Ray has joined #ipfs
Daboloskov has joined #ipfs
chriscool has joined #ipfs
<ipfsbot>
[go-ipfs] chriscool created improve_parse_test (+7 new commits): http://git.io/vJ2sS
<ipfsbot>
go-ipfs/improve_parse_test 2a5b2f2 Christian Couder: parse_test: move helper functions...
<ipfsbot>
go-ipfs/improve_parse_test 3e4a069 Christian Couder: parse_test: fix and test sameWords()...
<ipfsbot>
go-ipfs/improve_parse_test d0752a7 Christian Couder: parse_test: add tests for stdin enabled arg...
inconshreveable has quit [Ping timeout: 244 seconds]
chriscool has quit [Quit: Leaving.]
inconshr_ has quit [Ping timeout: 256 seconds]
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
<ipfsbot>
[go-ipfs] jbenet deleted godep/msgio at d368cb7: http://git.io/vJ2yr
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
inconshreveable has joined #ipfs
<whyrusleeping>
huh, i'm pretty sure the iptb test failures we're seeing are partly because daemon startup is so sketchy
<whyrusleeping>
if i have another program listening on port 5001 and start my daemon, i get the usual startup messages, and i'm pretty sure the gateway comes up before the daemon realizes that its port is already taken
Daboloskov has joined #ipfs
<whyrusleeping>
jbenet: o/
<whyrusleeping>
so im fine disabling those tests until we can rely on daemon startup
notduncansmith has quit [Read error: Connection reset by peer]
<whyrusleeping>
you should like, add that to ipfs for me
<whyrusleeping>
traffic on port 80 at this coffee shop is being filtered
<krl>
we need a good html->ipfs dump thing
<whyrusleeping>
tperson: was looking at writing one as a chrome extension
<wking>
whyrusleeping: I don't see why you'd need signal handlers at every level of the call stack. Just at the places that currently catch context errors and react to them. It looks like our only context-error handling is "bail out and return the error to my caller", which means you'd only need a handler for each goroutine-running thread. But it looks like the Go folks just really prefer explicitly passing around
<wking>
and manually checking these communications mechanisms (a Context, or a ‘done’ channel, https://blog.golang.org/pipelines), so using signals is probably just too foreign.
<whyrusleeping>
although i dont know why he stopped
<krl>
i would like standalone url -> ipfs
<whyrusleeping>
signals are also really expensive
<wking>
what fraction of requests are you canceling?
<whyrusleeping>
things get cancelled frequently
ei-slackbot-ipfs has quit [Remote host closed the connection]
ei-slackbot-ipfs has joined #ipfs
<wking>
explicitly coding checks for context/channel status costs programmer time ;)
<whyrusleeping>
barely, lol
<whyrusleeping>
writing context checks is less programmer time than signal handling
<wking>
but you can write the signal handler once for the whole stack, and need to sprinkle in context checks throughout the stack
<whyrusleeping>
quite a bit to do it right, also, you lose the ability to cancel a specific routine, sending a signal to a program triggers ALL handlers
<wking>
right, the handler would need to be able to associate the signal with the targetted goroutine (as barnacs_ pointed out). This isn't ideal, and is probably something that would be better if it were just built into goroutines (like pth_cancel_state). But this is probably too off-topic for IPFS ;)
<wking>
My main concern was that I didn't know where in the API we'd want Context arguments, and where we don't need them
<wking>
And it sounds like the answer is "everything in our public API should start with a Context argument"
<whyrusleeping>
yeah, any time we have the power to stop what we are doing and return early without leaking resources, we should have a context, for the most part
<wking>
^ that sounds like "all the time", no?
Tv` has joined #ipfs
<whyrusleeping>
not always, no. sometimes we have no choice but to wait for something to complete, i.e. "sort this list" doesnt need a context
<whyrusleeping>
the best rule of thumb i have is "could this thing hang indefinitely for some reason?"
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
<wking>
whyrusleeping: what if someone wants to cancel a long list sort?
<wking>
"blocked on CPU time" seems as reasonable as the usual "blocked on syscall"
<wking>
although I guess we don't actually handle "blocked on syscall" with explicit Context checks, so "blocked on CPU time" seems as reasonable as "blocked on laggy TCP conversation" or whatever it is we're currently using Contexts for
lgierth_ has joined #ipfs
lgierth has quit [Ping timeout: 244 seconds]
Daboloskov has joined #ipfs
G-Ray has quit [Quit: Konversation terminated!]
mildred has quit [Quit: Leaving.]
Daboloskov has quit [Client Quit]
philholden has quit [Ping timeout: 240 seconds]
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
pfraze has joined #ipfs
grncdr has quit [Quit: Leaving.]
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
pfraze has quit [Remote host closed the connection]
pfraze has joined #ipfs
pfraze has quit [Ping timeout: 256 seconds]
notduncansmith has joined #ipfs
notduncansmith has quit [Read error: Connection reset by peer]
Daboloskov has joined #ipfs
ganganesh has joined #ipfs
<ganganesh>
Hi everybody. Sorry for noob question, I get that IPFS has a lot features. In simplest case, how can I use it as alternative to BittorrentSync ?
<okket>
ganganesh: ipfs is still under heavy development and in no way a serious alternative to BT, for the time being I'd say try https://syncthing.net/
<okket>
ganganesh: ipfs is also more about public distribution than private sync, if the former is your main goal, ipfs might be for you, if the latter, syncthing
<ganganesh>
okket: Hi. I know that it is experimental at the moment, but in concept is it possible? "syncthing" ? Is this the one based on git?
<whyrusleeping>
thats not to say that we dont intend to support private syncm we just havent gotten to the point where people can effectively use ipfs for this usecase
<whyrusleeping>
we dont have encryption or ACLs written yet
<ganganesh>
whyrusleeping: Thanks. As far as I understand. You can configure that some folders would be downloaded from other nodes on demand, and other duplicated when added.
<okket>
in a very public way, yes
<ganganesh>
okket, whyrusleeping : Thanks, for you'r answers. I get the big idea behind IPFS (well I think I do), but you gotta start using somewhere.
<ganganesh>
Is the Ideas of IPFS are related to Joe Armstrongs Talk on reducing entropy of the Internet?
notduncansmith has joined #ipfs
<whyrusleeping>
i cant say ive watched that talk
notduncansmith has quit [Read error: Connection reset by peer]
<wking>
jbenet: how's the IPFS-object-bundle going? .dar? While poking around writing package docs I thought it might be an easier approach for assets than the current doc2go, which doesn't handle directory-recursion at the moment
<whyrusleeping>
anyone know how to update a single dependency in Godep?
<whyrusleeping>
i have a new commit on one of my dependencies i want to add
<whyrusleeping>
i have yet to understand how to do this cleanly
<okket>
ganganesh: well, everything seems to converge to hashes and blockchains these days, glad that joe is on the train also :)
<ganganesh>
okket, whyrusleeping: I'm more interested in using RDF and OWL (Semantic Web technologies) with IPFS, every object has unique URI, that's pretty much all you need to populate the ontology
<ganganesh>
And you can Inherit all the good stuff from IPFS.