geekosaur 2017-03-04 10:46:45
(it was like 2 weeks of discussion and tinkering on -cafe to get a "quick timing" to work, followed by someone collecting the result and making a package out of it. laziness is not the friend of timing)
AWizzArd 2017-03-04 10:47:23
(-:
AWizzArd 2017-03-04 10:47:38
https://tech.channable.com/posts/2017-02-24-how-we-secretly-introduced-haskell-and-got-away-with-it.html
contiver 2017-03-04 10:57:04
I´ve seen unsafePerformIO mentioned many times, but never had to deal with it till now.
contiver 2017-03-04 10:57:34
In the compress function here (at the bottom) https://github.com/ananthakumaran/hopfli/blob/master/src/Codec/Compression/Hopfli/Raw.hsc , would it be better to return IO Bytestring?
contiver 2017-03-04 10:58:36
I didn't write the code, but since I'm maintaining it, I thought I'd ask.
okeuday_bak 2017-03-04 10:58:57
is there a helper function in haskell somewhere that takes a single argument and doesn't do anything with it?
exio4 2017-03-04 10:59:50
okeuday_bak: const ()
exio4 2017-03-04 10:59:55
okeuday_bak: id?
exio4 2017-03-04 11:00:02
okeuday_bak: tell us the type signature you want :)
okeuday_bak 2017-03-04 11:00:44
exio4: yeah, good point, thanks
hpc 2017-03-04 11:02:15
contiver_: it's common for things that operate close to foreign imports to use unsafePerformIO
hpc 2017-03-04 11:02:27
contiver_: think of it as building a pure interface around impure code
Cale 2017-03-04 11:02:44
contiver: It's debateable. You'd sort of expect that compress is a pure function, so probably unsafePerformIO is okay there.
hpc 2017-03-04 11:02:51
there's a high bar to meet as far as ensuring that it is actually pure
okeuday_bak 2017-03-04 11:02:52
exio4: let f = (\x -> x) would be all I would want, just wondering if there is some standard definition somewhere, that should accept any type, right?
hpc 2017-03-04 11:02:57
but it might be worth the effort for something like this
jle` 2017-03-04 11:03:01
okeuday_bak: f is 'id'
jle` 2017-03-04 11:03:06
@src id
lambdabot 2017-03-04 11:03:06
id x = x
hpc 2017-03-04 11:03:07
people like being able to compress data at will ;)
okeuday_bak 2017-03-04 11:03:13
jle`: k, thanks
Cale 2017-03-04 11:03:27
Yeah, it's hard to know that the external libraries you're relying on really do produce a deterministic result.
Cale 2017-03-04 11:03:50
But if you can ensure that, it's nice to be able to let this be a function ByteString -> ByteString
geekosaur 2017-03-04 11:04:26
pedantry alert, you likely want unsafeLocalState (which skips some unnecessary cross-thread locking relative to unsafePerformIO)
contiver 2017-03-04 11:05:11
Cale, hpc: thanks for the answers, I think I'll leave it like that then.
contiver 2017-03-04 11:05:38
geekosaur, hadn't heard of that function, I'll keep it in mind :)
geekosaur 2017-03-04 11:05:57
the FFI spec defines it
hpc 2017-03-04 11:06:02
"It is expected that this operation will be replaced in a future revision of Haskell"
hpc 2017-03-04 11:06:26
unsafeLocalState = unsafeDupablePerformIO
hpc 2017-03-04 11:06:42
(in ghc)
contiver 2017-03-04 11:07:44
hpc: yeah, just read that. I guess it's deprecated (or will be)?
hpc 2017-03-04 11:08:33
deprecation warnings are red
hpc 2017-03-04 11:08:45
this seems more like a volatile api or something
Cale 2017-03-04 11:09:00
I'm not sure I'd use unsafeDupablePerformIO for that
Cale 2017-03-04 11:09:29
While it's probably safe if the IO gets duplicated, you're duplicating a potentially rather expensive operation.
ertes 2017-03-04 11:10:00
monochrom: BTW, i didn't have a satisfying experience with any of the proof systems i tried so far =/
ertes 2017-03-04 11:10:28
i saw one project to implement such a system in haskell, but it seemed abandoned
contiver 2017-03-04 11:10:52
If I may ask, what's the difference between the two? (unsafePerformIO and unsafeDupablePerformIO)
geekosaur 2017-03-04 11:11:16
unsafePerformIO adds locking to ensure two threads don;t run it at the same time
geekosaur 2017-03-04 11:11:44
which is necessary if you are working with the I/O manager, but not for most FFI calls
Cale 2017-03-04 11:11:46
With unsafeDupablePerformIO, there's a few cycles during which if more than one thread starts evaluating the same thunk, both may perform the entire evaluation.
Cale 2017-03-04 11:12:23
I would recommend just sticking with unsafePerformIO almost always.
geekosaur 2017-03-04 11:12:55
for pure code, if two threads hit an unevaluated thunk at the same time, we let both evaluate it even though they will duplicate work; the cost of locking to prevent it is almost always higher than just letting it hapen
Cale 2017-03-04 11:13:08
It really depends
geekosaur 2017-03-04 11:13:19
(that was tested in one ghc release and removed after it caused major slowdowns)
Cale 2017-03-04 11:13:55
If the IO action is doing something nontrivial, then the locking might be quite inexpensive.
geekosaur 2017-03-04 11:13:55
sometime in 6.6 or 6.8 series iirc
hpc 2017-03-04 11:14:13
yeah, compressing data is a big operation
geekosaur 2017-03-04 11:14:13
but for IO locking is done because the I/O manager isn;t 100% reentrant
hpc 2017-03-04 11:14:26
especially (as one often does) when compressing gigs of data
contiver 2017-03-04 11:14:53
so if I were to use unsafeDupablePerformIO, it would on average be faster, but from time to time the bytestring might be compressed by two threads?
Cale 2017-03-04 11:14:57
yeah
geekosaur 2017-03-04 11:15:23
and unsafePerformIO allows entry to the I/O manager without the normal checks. so it does extra locking, and unsafeDupablePerformIO avoids that when you don;t need to care about that (non)reentrancy
geekosaur 2017-03-04 11:16:14
contiver, I said with pure code. for calling into C to do compression, that's different and you do need to think about how long it will run and whether it's worth doing the extra locking or not
geekosaur 2017-03-04 11:16:36
but you asked what the difference between the two was
contiver 2017-03-04 11:18:41
geekosaur, and I appreciate your answer :) I guess I'll stick to unsafePerformIO, if you are using Zopfli to compress you probably don't care about a couple more seconds.
geekosaur 2017-03-04 11:18:53
it will rarely be that much
geekosaur 2017-03-04 11:19:03
maybe if you call it a million times it;d add up to that
