[tor-bugs] #9204 [Tor Check]: Modularize check.torproject.org

[Tor Bug Tracker & Wiki]

#9204: Modularize check.torproject.org
-----------------------+----------------------------------------------------
 Reporter:  arma       |          Owner:     
     Type:  project    |         Status:  new
 Priority:  normal     |      Milestone:     
Component:  Tor Check  |        Version:     
 Keywords:             |         Parent:     
   Points:             |   Actualpoints:     
-----------------------+----------------------------------------------------

Comment(by dkm):

 Replying to [comment:19 cypherpunks]:
 > I’ve been working on `TorDNSEL` for two months.  I’ve just sent a set of
 > patches [1] that should allow you to build the program.  I haven’t
 > tested anything, so there are probably a lot of errors.
 >
 > tup, could you answer the following questions:

 Let me fill in for tup -- and he'll hopefully slap me if I'm off base
 here:

 > 1. Why did you wrap exceptions into `Dynamic`?

 Because at the time, it was the only way to add your own exception types
 [1]. What happened in the meantime is that the entire exception handling
 API switched to that same trick: from a closed to an open type.

 Consider the API in [1]. How would you add a new kind of exception?


 > 2. Why was it necessary to write `hGetLine` in such a low-level way?

 Consider the return type of this function. Since it takes its own message
 terminator, it must be possible for the handle buffer to contain more data
 than that. Where is this leftover?

 Then look at the hGetLineBufferedLoop helper. Oh, `writeIORef` you say?
 Yes, it's writing back the position the handle has been read to. This is
 the equivalent of using the handle as a global variable to store the
 leftover in -- through its private API.

 These days a proper solution for this is an iteratee pipeline.

 ( I'll be sitting here in the corner with a shotgun, waiting for the first
 person to try to fix it by doing `{-# NOINLINE #-} spill =
 (unsafePerformIO $ newIORef B.empty) :: IORef ByteString` ... )

 As to why does it contain a full-blown Knuth-Morris-Pratt matcher when it
 only ever gets called with "\r\n" and "\n", I'd say the author got carried
 away. I think it's actually pretty cool!

 The entire function is a truly masterful hack, but it needs to go away.


 > 3. Is is possible to contact you by email?  What address should be used?
 >
 > [1] https://lists.torproject.org/pipermail/tor-
 dev/2013-August/005318.html


 [1] http://hackage.haskell.org/packages/archive/base/3.0.3.2/doc/html
 /Control-Exception.html#10

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9204#comment:20>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online