These are chat archives for vu3rdd/functorrent

16th
Nov 2015
Ramakrishnan Muthukrishnan
@vu3rdd
Nov 16 2015 07:39
@jaseemabid read through part of the code. Looks ok. How are you testing it?
@jaseemabid I wouldn't worry too much about performance at this point. If open/close is the simplest, then do that. We can always fix such things later.
also I didn't totally get why killing safely is super important. Sure, we should give back all the resources. But as far as torrent download is concerned, we will get a hash sum mismatch next time and we will download that those pieces again. That simplifies a lot of things. For upload, I think it does not matter much. It is upto the connected peers to handle it just like the way we handle network drops.
Ramakrishnan Muthukrishnan
@vu3rdd
Nov 16 2015 07:44
The nice thing about BitTorrent protocol is that we can do partial downloads and do not need to write any state of each piece. All we need to do is to rebuild the state every time we startup, by reading the disk file and verifying the hash.
Jaseem Abid
@jaseemabid
Nov 16 2015 08:34
@vu3rdd Fixed the open close thing.
@vu3rdd Was basically making a supervisd hierarchy of threads. Killing parent should ideally clean up its children as well.
I updated the PR recently. Added a FuncTorrent.Core module with shared types, annotated all channels and things look redable now
The commit list showed by GH is messed up. Its not handling force updated topic branches well
@vu3rdd I can only do manual testing now.
./ft foo.torrent should give you a log, which sort of tells you how things went
Jaseem Abid
@jaseemabid
Nov 16 2015 08:39
Not sure how to handle the logs. A reader monad which carries the log object might do the job, but i have to read up on that.
@k4rtik Hello!
Divam
@dfordivam
Nov 16 2015 10:01
@jaseemabid #44 looks fine... we can merge in master
Jaseem Abid
@jaseemabid
Nov 16 2015 10:02
@dfordivam Look harder! find problems :)
Divam
@dfordivam
Nov 16 2015 10:02
@jaseemabid I want tests which find the problems !
Jaseem Abid
@jaseemabid
Nov 16 2015 10:03
True that. Need a sane way to stub responses to write tests.
Preferably without cpp
Divam
@dfordivam
Nov 16 2015 10:04
I find usage of cpp pragmas quite ok. I am even thinking of using #include to divide the module's code in an very large AST
Jaseem Abid
@jaseemabid
Nov 16 2015 10:04
I want to merge the concurrency bits, ramki’s protocol, and integrate it all. Once we have that, we could clean up the code as a whole, take some time to simplyfy things and also write coverage tests
Now for example, writer works on an optimistic model. We assume things that went into that Q will eventually get written to disk.
Things like that need thinking
Also, we cant close channels. The default implementation doesnt allow a shutdown
Divam
@dfordivam
Nov 16 2015 10:08
Of course there is no thing as closing a channel. If the program need to exit, then I agree with ramki that we can let data get corrupt. But later if we just want to stop download, then this need proper shutdown.
Jaseem Abid
@jaseemabid
Nov 16 2015 10:09
I’m very close to proper shutdown. Some more effort and we have it!
Jaseem Abid
@jaseemabid
Nov 16 2015 10:15
@dfordivam Conceptually i should be able to say this worker is going down, dont send anymore work to me
@vu3rdd Meetup? When are you free?
3 of us
Kartik Singhal
@k4rtik
Nov 16 2015 14:17
@jaseemabid Hello (everyone!)
Kartik Singhal
@k4rtik
Nov 16 2015 16:07
A question before I try to dive in the source: there are two repos for functorrent, what's the difference?
Jaseem Abid
@jaseemabid
Nov 16 2015 19:40
@k4rtik Oh. jumping into source for next couple of days will be a bit hard. Big changes
The canonical repo (blr haskell one) is the primary one
@dfordivam Worked on an experimental concurrency model and landed that on the main repo, but we never really completed the nuts and bolts of it. Divam and I were working on and off on the concurency bits.
I ended up rewriting most of it using channels. The rational and code can be seen at pull#44.
Meanwhile, @vu3rdd was working on the actual protocol and made some progress without looking into the concurrency bits. And that can be seen at the vu3rdd repo.
Hoping to merge it all in next couple of days
Once we have all code in place, we’ll have to do some cleanup, improve docs etc.
Moving to stack and setting up stack based test/builds on travis is high priority.
I’m hoping @vu3rdd will be able to cherry pick important bits into topic branches and raise several pull requests in the coming days. I dont really know how much progress he made
Jaseem Abid
@jaseemabid
Nov 16 2015 20:05
@k4rtik To start, install stack. No need of even ghc. $ stack build, and follow the instructions. I’m sure you will get the rest right with no trouble.
writer.hs is independent enough to understand and a quick intro to haskell channels. See if you can run a thread, send blocks to it and see it written to disk.