diff options
Diffstat (limited to 'doc/todo/bytes_in_privData__63__')
6 files changed, 115 insertions, 0 deletions
diff --git a/doc/todo/bytes_in_privData__63__/comment_1_42c107179b091f74ef55aff1fc240c5e._comment b/doc/todo/bytes_in_privData__63__/comment_1_42c107179b091f74ef55aff1fc240c5e._comment new file mode 100644 index 00000000..5c1508fd --- /dev/null +++ b/doc/todo/bytes_in_privData__63__/comment_1_42c107179b091f74ef55aff1fc240c5e._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2015-04-20T01:04:26Z" + content=""" +I imagine that adding `fileEncoding stdin` to setPrivData will fix +this crash, but I'd expect there are also other problems with encodings +for privdata that haskell doesn't like. Similar fixes would probably +be needed in several other places. + +Probably cleaner and better to convert +`PrivData` from a String to a ByteString, and so avoid encodings +being applied to it. I think this could be done without changing the +file format; the privdata file uses Read/Show for serialization, +and happily ByteString uses the same Read/Show format as String does. + +So, changing the type and following the compile errors should get you +there, I think! +"""]] diff --git a/doc/todo/bytes_in_privData__63__/comment_2_60f577b476adc6ee1e4f18e11843df90._comment b/doc/todo/bytes_in_privData__63__/comment_2_60f577b476adc6ee1e4f18e11843df90._comment new file mode 100644 index 00000000..10ff956a --- /dev/null +++ b/doc/todo/bytes_in_privData__63__/comment_2_60f577b476adc6ee1e4f18e11843df90._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="gueux" + subject="comment 2" + date="2015-04-21T12:59:42Z" + content=""" +Would you accept a patch converting PrivData from String to ByteString? +"""]] diff --git a/doc/todo/bytes_in_privData__63__/comment_3_55f34128de77b7947d32fac71071e033._comment b/doc/todo/bytes_in_privData__63__/comment_3_55f34128de77b7947d32fac71071e033._comment new file mode 100644 index 00000000..a1c7f62f --- /dev/null +++ b/doc/todo/bytes_in_privData__63__/comment_3_55f34128de77b7947d32fac71071e033._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2015-04-21T16:52:06Z" + content=""" +Absolutely. Thought that went w/o saying. ;) +"""]] diff --git a/doc/todo/bytes_in_privData__63__/comment_4_f34a8f82c7bce7224e4edc59410c741f._comment b/doc/todo/bytes_in_privData__63__/comment_4_f34a8f82c7bce7224e4edc59410c741f._comment new file mode 100644 index 00000000..bd7a0618 --- /dev/null +++ b/doc/todo/bytes_in_privData__63__/comment_4_f34a8f82c7bce7224e4edc59410c741f._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="gueux" + subject="comment 4" + date="2015-04-23T09:21:07Z" + content=""" +I tried to do the conversion, but then it started a kind of chain reaction... (PrivData=ByteString to writeFileProtected to Line=ByteString to ... to readProcess to ...) Should I use FilePath=String? ... To be honest, the patch became a lot bigger that what I am comfortable with. :-) + +I guess you should have a look at it... + +At least, I think there is a type bug in Propellor.Property.File: + + hasPrivContent' :: (IsContext c, IsPrivDataSource s) => (String -> FilePath -> IO ()) -> s -> FilePath -> c -> Property HasInfo + +but it should be + + hasPrivContent' :: (IsContext c, IsPrivDataSource s) => (FilePath -> String -> IO ()) -> s -> FilePath -> c -> Property HasInfo + +(it is hidden by FilePath = String) +"""]] diff --git a/doc/todo/bytes_in_privData__63__/comment_5_f4db6ffad054feb7eb299708fcd7d05c._comment b/doc/todo/bytes_in_privData__63__/comment_5_f4db6ffad054feb7eb299708fcd7d05c._comment new file mode 100644 index 00000000..45c97b97 --- /dev/null +++ b/doc/todo/bytes_in_privData__63__/comment_5_f4db6ffad054feb7eb299708fcd7d05c._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 5""" + date="2015-04-23T13:25:50Z" + content=""" +Can you put the patch up somewhere? I'll take a look. Might see a way to +short-curcuit the bytestring before everything becomes one.. + +One way might be: + + writeFileProtected :: FileContent content => FilePath -> content -> IO () + +Which would also at least partly avoid foot-shooting over which parameter is which. +(Fixed that type signature.) +"""]] diff --git a/doc/todo/bytes_in_privData__63__/comment_6_545e1c26a042b9f8347496a1bfb61548._comment b/doc/todo/bytes_in_privData__63__/comment_6_545e1c26a042b9f8347496a1bfb61548._comment new file mode 100644 index 00000000..29b07e5c --- /dev/null +++ b/doc/todo/bytes_in_privData__63__/comment_6_545e1c26a042b9f8347496a1bfb61548._comment @@ -0,0 +1,48 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 6""" + date="2015-04-28T19:24:12Z" + content=""" +I've followed the same path in the wip-bytestring-privdata branch. + +It needs to round trip through String anyway to handle Read/Show +serialization the same as before. I think this is doable without falling +over on invalid encodings, but it's certianly ugly. + +And yeah, changing Line to ByteString and all the other follow-on changes +just don't seem right. Everything that uses withPrivData would need to deal +with it being a ByteString, and would need to worry about encoding problems +when it needed to convert to a String, or Text, or whatever. + +So this feels like kicking the can down the road in the wrong direction... + +---- + +Maybe it would be better to handle this by adding a type to wrap up an +encoded ByteString in the PrivData. Could use base64 or something like +that for the encoding. Then only consumers of these ByteStrings would be a +little complicated by needing to unwrap it. + +Then it would be handly to give --set, --dump and --edit some +special handling of fields encoded like that. They could operate on raw +ByteStrings when handling such fields, and take care of the encoding +details. + +Add a new constructor to PrivDataField for binary files: + + | PrivBinaryFile FilePath + +And a function to get the encoder and decoder: + + type Encoder = ByteString -> PrivData + type Decoder = PrivData -> ByteString + + privDataEncoding :: PrivDataField -> Maybe (Encoder, Decoder) + +Then --set, --dump, and --edit could use that to encode and decode the +data. + +And finally, a `withBinaryPrivData` that uses ByteString. + +(Maybe this could be made more type safe though..) +"""]] |