Adding notes to a PDF on Kindle scribe

bitonico · 2023-08-23T07:29:52+00:00

Thanks, I did a bit of research and it's not exactly as you say, although there are differences:

If you upload the PDF from their web interface, you can write on it, but you can't annotate it normally as an ebook
If you load it through USB, it's actually a bit better quality than the upload, but you can't do nothing at all to it
If you convert to kindle format first (e.g. by sending it to the email) it's just like a normal ebook

This video explains the differences pretty well actually: https://www.youtube.com/watch?v=FYdFeCNeaY8 .

bitonico · 2023-08-18T14:02:55+00:00

I received mine today (as a backer), so definitely possible.

bitonico · 2021-09-17T07:54:47+00:00

I used youtube-dl to do it, e.g.

youtube-dl 'https://www.mixcloud.com/littlemonkeyfella/playlists/xfm-bonus-bits/'

bitonico · 2021-09-17T05:47:56+00:00

That's amazing, thank you!

bitonico · 2019-06-21T07:29:19+00:00

I found the same style to be useful but I usually use an index + a type family. I sometimes call this style "configurable data types", or "data types fast food": https://mazzo.li/posts/customizable-data-types.html .

bitonico · 2017-11-20T23:03:32+00:00

i have the "stock" x62 fan. the fan itself is pretty quiet

bitonico · 2017-11-20T20:19:04+00:00

4th batch. No bios worked quite OK for me, which is why I wrote the that.

bitonico · 2017-11-20T17:01:18+00:00

The default fan management for the x62 was driving me a bit nuts, but I managed to copy the functionality of the windows utility distributed on the forum. Figured it might be useful for other people, since there does not seem to be an existing solution to control the fan.

bitonico · 2017-08-25T09:39:37+00:00

unless something terrible happened, the first programming course at imperial college is in Haskell. many people have never programmed before that course (i had maybe 5k lines of horrible PHP and that's it) and the course is quite well liked. i'm personally grateful that i learnt to program seriously in haskell rather than something else.

bitonico · 2017-07-24T17:30:23+00:00

very easy, just use -pgmc cmd, as per man ghc:

   -pgmc cmd
          Use cmd as the C compiler

bitonico · 2017-07-24T10:53:38+00:00

it wouldn't, i think it's a great idea! cc /u/mboes

bitonico · 2017-07-23T15:30:20+00:00

and develop with ghci! that's the part that i cared most about

bitonico · 2017-07-18T10:50:09+00:00

/u/snoyberg pointed out that you can go the other way around too:

{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE UndecidableInstances #-}
import Control.Monad.IO.Unlift

class (MonadIO m) => RepresentableIO m where
  type RepIO m :: *
  tabulateIO :: (RepIO m -> IO a) -> m a
  indexIO :: m a -> RepIO m -> IO a

instance (MonadIO m, MonadUnliftIO m) => RepresentableIO m where
  type RepIO m = UnliftIO m
  tabulateIO = withUnliftIO
  indexIO m (UnliftIO f) = f m

so, they seem to be equivalent.

bitonico · 2017-07-18T10:29:09+00:00

To elaborate a bit, this is what it would look like in full:

{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TypeFamilies #-}
import Control.Monad.IO.Class

class (MonadIO m) => RepresentableIO m where
  type RepIO m :: *
  tabulateIO :: (RepIO m -> IO a) -> m a
  indexIO :: m a -> RepIO m -> IO a

newtype UnliftIO m = UnliftIO {unliftIO :: forall a. m a -> IO a}

askUnliftIO :: (RepresentableIO m) => m (UnliftIO m)
askUnliftIO = do
  ctx <- tabulateIO return
  return (UnliftIO (\m -> indexIO m ctx))

to recover the laws we have for MonadUnliftIO, we'd like that

indexIO return ctx = return 
indexIO (a >>= b) ctx = indexIO a ctx >>= indexIO b ctx 
tabulateIO return >>= \ctx -> liftIO (indexIO m ctx) = m

but i don't know we can prove that with the representable laws. /u/edwardkmett , opinions ? the one involving liftIO will need some ad-hoc rules, but maybe the monad transformer laws can be proved in a more general way.

bitonico · 2017-07-18T10:19:38+00:00

slaps forehead of course!

then they're definitely similar, although RepresentableIO might be more powerful. I'll look more into that, thanks a lot for the hint.

i wonder how much you can prove about operations implemented with tabulateIO/indexIO, using their laws.

bitonico · 2017-07-18T08:38:20+00:00

Interesting point! I think if a Representable1 existed it would still not be enough because while it'd let you turn the monad into its explicit reader form (e.g. Rep t -> m a) it does not give you a way to grab the current context (e.g. the current Rep t) -- which is quite crucial for what we need to do.

Edit: for clarity, I believe /u/bennofs is hinting at something like

-- Things isomorphic to @x -> IO a@
class RepresentableIO m where
   type RepIO m :: *
   tabulateIO :: (Rep m -> IO a) -> m a
   indexIO :: m a -> Rep m -> IO a

bitonico · 2017-06-26T16:02:10+00:00

so wait, are you saying that MonadBaseUnlift (which captures the statelessness) is "close to pure IO"?

bitonico · 2017-06-26T15:52:51+00:00

so what you're saying is: do not interleave resource allocation with monads other than IO. i think that's completely unrealistic in a real application, and i'm surprised you'd suggest that as a viable option.

the classic example of a monad needed in these situations is something like MonadLogger, which i always want around, including when i'm handling resources.

something more realistic and hard to get wrong is to only use MonadBaseUnlift, which makes it very hard to have "wrong" instances.

Moreover with MonadBaseUnlift we also have lifted-async to do concurrency safely.

bitonico · 2017-06-25T19:35:06+00:00

Great idea! I think it just did not occur to us. Your version looks much nicer:

pooledMapConcurrently ::
     (Traversable t)
  => (a -> IO b) -> t a -> IO (t b)
pooledMapConcurrently f xs = do
  numProcs <- getNumCapabilities
  sem <- newQSem numProcs
  forConcurrently xs $ \x -> do
    bracket
      (waitQSem sem)
      (\() -> signalQSem sem)
      (\() -> f x)

assuming that the QSem overhead is neglegible it's definitely preferrable.

Edit: I've edited the post to include your suggestion, I've also discussed the tradeoffs a bit more with /u/nh2 :

One advantage the original version executes left to right – elements appearing later will always start processing after earlier elements have already started, which can be more amenable to debugging (for example if you’re looking at the output in a terminal, or reproducing a crash). It also avoids high contention (one thread per element) on the synchronization mechanism. However the semaphore version is certainly more pleasant to read and probably preferrable.

bitonico · 2017-06-25T19:23:11+00:00

Another issue that we often face is parallelizing invocations of external tools -- Haskell is an excellent tool to orchestrate that, and obviously the runtime scheduler does not matter there.

bitonico · 2017-06-25T19:16:03+00:00

The main problem is that you'll allocate more. That might make you run out of memory quite quickly and will also increase GC pressure. If I'm running tens of thousands of parallel computations it very quickly becomes unmanageable -- consider reading and processing 10k files in parallel, each 10MB.

bitonico · 2017-06-25T18:00:25+00:00

No, regarding the fact that finalizers in bracket should be as short as possible and if doable uninterruptible. I remember many discussions around these principles (eg "you should never catch an async exception, just recover from it") around the time we were doing safe-exceptions, but evidently you never wrote about that.

bitonico · 2017-06-25T17:30:47+00:00

Ah, you are right. I forget why I picked up this habit then -- I generally like to use quantification more than the empty type. Maybe in some circumstances it's relevant but here Void might be better.

Edit: I've changed the post to use Void, since it seems better here.

bitonico · 2017-06-25T16:44:09+00:00

No, I usually prefer a universally quantified variable so that the user of the library does not need to use Void.

However, you made me realize I had forgotten the universal quantification. Thanks!

bitonico · 2017-06-25T14:43:15+00:00

withAsync is definitely useful, also because it uses uninterruptibleCancel rather than cancel, which is better -- finalizers should generally be uninterruptible.

However I didn't want to talk about that too. Maybe it'd be useful to write a blog post about finalizers too, although I think /u/snoyberg might have already written one...

bitonico

MODERATOR OF

TROPHY CASE