davean 2017-02-27 09:03:38
(Its not like there were options for its ISA)
davean 2017-02-27 09:03:47
(Its not armv8/aarch64)
kubunto 2017-02-27 09:03:50
davean: because there is a difference between the pis in terms of cpu power
davean 2017-02-27 09:03:55
kubunto: meaningless
davean 2017-02-27 09:04:00
I didn't say I knew its speed
ertes 2017-02-27 09:04:09
davean: they might have etched the CPU out and soldered a new one onto it
kubunto 2017-02-27 09:04:28
or they may have also changed the arch to help improve things
davean 2017-02-27 09:04:30
ertes: all pin compatible CPUs are armv7 at least
davean 2017-02-27 09:04:40
kubunto: nope, they can't do that
davean 2017-02-27 09:04:46
kubunto: tehy can't change the arch
davean 2017-02-27 09:04:51
thats not really an optoin
ertes 2017-02-27 09:05:09
they might have rewired the CPU before soldering
davean 2017-02-27 09:05:22
ertes: That would be rather a project ;)
kubunto 2017-02-27 09:05:24
davean: why not?
davean 2017-02-27 09:05:33
kubunto: because of how CPUs work
ertes 2017-02-27 09:05:40
sure, but you know those hackers =)
kubunto 2017-02-27 09:06:15
davean: compatibility would be broken between pis but so what
ertes 2017-02-27 09:06:26
don't underestimate a curious mind =)
davean 2017-02-27 09:06:30
kubunto: its worse then that
davean 2017-02-27 09:06:47
kubunto: consider which ISAs are available for ARMs
kubunto 2017-02-27 09:06:55
davean: ISA?
davean 2017-02-27 09:06:57
theres really only two, armv7 and armv8
davean 2017-02-27 09:07:03
kubunto: instruction set archnitecture
davean 2017-02-27 09:07:14
kubunto: There exist other arm ISAs but they're obsolute
kubunto 2017-02-27 09:07:26
like sub and str?
davean 2017-02-27 09:07:29
armv7 and armv8 are radically different
flxw 2017-02-27 09:07:48
After having backtracking out of the way, my other thought was to feed the attoparsec based parser incrementally. But since it is a simple project, I'd rather not use a serious solution like Conduit or Pipes. (attoparsec uses strict Text). My idea was to run the parser using parseWith together with something simple, based on e.g. take 32K lazy_lazy_Text_input. Does this sound like a very bad idea, or just bad?
flxw 2017-02-27 09:08:41
s/lazy_//
davean 2017-02-27 09:08:57
flxw: feeding chunks with parseWith is basicly what pipes or conduit, or machines would do
davean 2017-02-27 09:09:13
You're just doing it manually
davean 2017-02-27 09:09:23
(I'm not entirely clear on why, but if it works well for your code, do it?)
davean 2017-02-27 09:09:47
kubunto: sub and str?
davean 2017-02-27 09:09:52
kubunto: what are you talking about?
flxw 2017-02-27 09:09:59
oh, it just, I haven't used Pipes yet, and the types frighten me a little.
ertes 2017-02-27 09:10:12
flxw: https://hackage.haskell.org/package/attoparsec-0.13.1.0/docs/Data-Attoparsec-ByteString.html#g:2
davean 2017-02-27 09:10:14
flxw: they shouldn't, and thats fine, don't use them
davean 2017-02-27 09:10:37
kubunto: do you mean the assembly instructions?
kubunto 2017-02-27 09:10:54
yea
kubunto 2017-02-27 09:11:02
or are they different things
davean 2017-02-27 09:11:12
ertes: so I've spent a bit thinking about what one would have to do to wire an aarch64 into an rpi, and its kinda amazing how difficult that might be
davean 2017-02-27 09:11:37
kubunto: those are the names of instructions, at the assembly level, but the semantics and how they're actually encoded on the machine are different
davean 2017-02-27 09:11:58
kubunto: both ISAs will have those instructions, though not all the same instructions, and armv8's are 64 bits not 32bits
ertes 2017-02-27 09:12:04
davean: of course… i was just joking =)
davean 2017-02-27 09:12:25
kubunto: but such instructions do for a *small* part of the ISA
davean 2017-02-27 09:13:16
ertes: I understand, but I considered it seriously
davean 2017-02-27 09:13:19
ertes: its doable of course ...
davean 2017-02-27 09:13:42
well, I say of course, I'm a touch worried about the timing issues
flxw 2017-02-27 09:13:56
thank you all for the nice input. I'll log off.
ertes 2017-02-27 09:14:44
although i'm pretty sure someone from the folks who visit conventions like defcon or chaos communication congress has figured it out already
davean 2017-02-27 09:16:35
kubunto: anyway, the only archs of arm one really can get their hands on these days are armv7 or armv8, there are a few armv7 variants - hard and soft float, which endian it is running in
davean 2017-02-27 09:17:18
so I can tell you your endian because you're running linux on it
kubunto 2017-02-27 09:17:18
davean: yea i am not that deep into the hardware
ertes 2017-02-27 09:17:18
linux can't run on big endian?
davean 2017-02-27 09:17:18
I can tell you which version you are because none of the armv8 options would remotely fit that board - they're primarily server chips ATM
MarcelineVQ 2017-02-27 09:17:52
kubunto: :>
ertes 2017-02-27 09:17:57
little endian is far more widespread, and intuitively it also makes more sense to me, because it's not sensitive to word widths
davean 2017-02-27 09:17:59
ertes: I mean, to some degree the answer is "big endian is what everone used, and its more linear so the network layer got defined in it"
ertes 2017-02-27 09:18:25
need a longer word? just append a bunch of zeroes
davean 2017-02-27 09:19:02
ertes: you think little endian is more widespread? Hum, thats an interesting question
davean 2017-02-27 09:19:13
I mean, clearly biendian is the most widespread
ertes 2017-02-27 09:19:13
well, to be fair, i don't know much about embedded hardware… i might be wrong
davean 2017-02-27 09:19:13
the only non-biendian CPU of any scale (leaving asside AVR and the like) I can think of is x86 based
davean 2017-02-27 09:20:59
POWER, arm, mips, all biendian
davean 2017-02-27 09:23:29
I'm not sure which mode most MIPS are run in
davean 2017-02-27 09:23:29
arm varies by application of course
davean 2017-02-27 09:23:29
Really, the only little-endian systems are x86/amd64
davean 2017-02-27 09:23:29
ertes: I mean, everything starts big endian?
davean 2017-02-27 09:23:29
ertes: so you end up little endian if you grow but don't change
ertes 2017-02-27 09:23:56
the reason i think little endian is genuinely superior is that digits retain their relative positions in the word, regardless of word size, so conversion can be cheap or even free
monochrom 2017-02-27 09:24:00
I understand.
ertes 2017-02-27 09:24:00
with big endian it's never free
davean 2017-02-27 09:24:07
ertes: Not really!
davean 2017-02-27 09:24:22
ertes: the BYTES retain their possition
davean 2017-02-27 09:24:25
ertes: the bits don't
dolio 2017-02-27 09:25:26
Relative positions don't change either way, no? It's just a question of where the padding goes.
ertes 2017-02-27 09:25:34
yeah, exactly
ertes 2017-02-27 09:25:45
the bit positions are only relative to the byte
davean 2017-02-27 09:25:56
dolio: no, the bits in a byte are the oposite order usually
davean 2017-02-27 09:26:05
ertes: They're relivent though because of things like carry operations
ertes 2017-02-27 09:26:12
davean: that's an implementation detail
davean 2017-02-27 09:26:25
ertes: its litterly the part that matters
dolio 2017-02-27 09:26:48
davean: But if you promote to a larger integer type, you don't need to shuffle the bits around. Or reorder the bytes.
ertes 2017-02-27 09:26:49
the way bits are ordered within a byte shouldn't even be visible to the user, unless there are special instructions that are order-sensitive
davean 2017-02-27 09:27:00
dolio: shift vs. shuffle
ertes 2017-02-27 09:27:40
memory is byte-addressed after all, and you can only ever fetch/write a whole byte
davean 2017-02-27 09:28:19
Your memory is byte addressed :)
monochrom 2017-02-27 09:28:36
How do I use software to observe bit order?
ertes 2017-02-27 09:29:02
davean: let's assume that bit order matters… then in a LS-ordered arch the LSB should be the one with index 0… then again conversion can be free
ertes 2017-02-27 09:29:19
with MSB ordering it's never free
ertes 2017-02-27 09:29:26
you always need at least a shift
davean 2017-02-27 09:29:39
Not if you're a L/S arch
davean 2017-02-27 09:29:48
then its always a store and you just pick where you store
davean 2017-02-27 09:29:53
(most arch are load/store)
ski 2017-02-27 09:41:29
max3 : presumably #haskell-stack ?
riddle_ 2017-02-27 09:41:32
okey, got it, thanks :)
ertes 2017-02-27 09:41:38
of course if you're a haskell programmer, you can benefit a lot from using xmonad
max3 2017-02-27 09:41:38
if i'm stopped at an exception in ghci how do i see what the exception message is?
max3 2017-02-27 09:41:53
whoops i meant slack
max3 2017-02-27 09:41:54
not stack
monochrom 2017-02-27 09:41:59
I don't use xmonad. I am not sold on tiling.
Sornaensis 2017-02-27 09:42:12
tiling is great
Sornaensis 2017-02-27 09:43:23
xmonad is not
Clint 2017-02-27 09:43:28
they are both pretty great
monochrom 2017-02-27 09:43:43
Actually I am not sold on being less lazy than I am.
Sornaensis 2017-02-27 09:43:54
auto tiling kind of defeats the strength of tiling
Sornaensis 2017-02-27 09:43:54
imo
ertes 2017-02-27 09:43:54
monochrom: xmonad actually does support overlapping, if that's what you prefer, but it's underdeveloped
max3 2017-02-27 09:43:54
monochrom, try quicktile
monochrom 2017-02-27 09:43:54
No, ubuntu defaults work fine for me, I am not less lazy than I am.
Tuplanolla 2017-02-27 09:43:54
I tried Xmonad once and it was not a good experience.
max3 2017-02-27 09:43:54
it's not a window maanger
Sornaensis 2017-02-27 09:43:54
i3 imo is excellent for general purpose workstation needs
monochrom 2017-02-27 09:43:54
Yes yes I know that ubuntu works me alone, it breaks for all of you.
ertes 2017-02-27 09:44:03
i don't like xmonad, but i use it mainly because i'm too lazy to see which of the other WMs support my workflows
Tuplanolla 2017-02-27 09:44:19
http://tuplanolla.no-ip.org/tmp/hello-xmonad.png
vlnts 2017-02-27 09:45:11
I love tiling(awesome) but uses tmux over multiple terminals. Can't get my head around the idea of terminal inside neovim
monochrom 2017-02-27 09:45:11
OTOH I am not lazy enough to "apt-get install ghc". I go over to Haskell Platform.
Tuplanolla 2017-02-27 09:45:11
It also flickered, but you can't see that in the image.
Sornaensis 2017-02-27 09:45:11
vim is not supposed to be emacs :p
monochrom 2017-02-27 09:45:34
Some people use C-x C-2 for window manager :)
max3 2017-02-27 09:45:39
i swear i'm going to shoot myself over this Paths_ nonsense
ertes 2017-02-27 09:45:53
monochrom: C-x 2
monochrom 2017-02-27 09:46:00
Oh oops :)
ski 2017-02-27 09:46:13
Tuplanolla : Luvely Jubly
riddle_ 2017-02-27 09:46:22
not trying to divert the topic from haskell, but talking about WMs, is there any good non-tiling (stacking I think) ligthweight WM? Been using Openbox for a year, but thinking trying something different
lispy 2017-02-27 09:46:45
max3: what is your Paths_ problem?
monochrom 2017-02-27 09:46:54
Knuth uses fvwm.
Sornaensis 2017-02-27 09:47:02
riddle_: enlightenment is alright and fairly lightweight
ski 2017-02-27 09:47:11
lispy : long story in backlog
riddle_ 2017-02-27 09:47:19
I mean I know there is, but just haven't talked to anyone about it since mostly people around me stick to Ubuntu
riddle_ 2017-02-27 09:47:24
and its defaults
monochrom 2017-02-27 09:47:46
lispy: Also old nickname was Guest82102
ertes 2017-02-27 09:47:53
if it wasn't for xmonad i would still be using compiz
lispy 2017-02-27 09:49:06
when I use a wm in linux these days, I tend to just use xfce beacuse it's easy and I'm going to use a fullscreen terminal with tmux and like a browser and that's probably it.
lispy 2017-02-27 09:56:52
Has anyone here worked through Harrison's Handbook of Practical Logic in Haskell or otherwise?
lispy 2017-02-27 09:58:16
I've just read the first chapter and skimmed the later ones to see what topics they cover. It seems like a really good introduction to applied logics.
riddle_ 2017-02-27 09:58:32
(BTW) thanks for responses guys!
monochrom 2017-02-27 10:02:05
lispy: I did not, but I googled and found https://github.com/andre-artus/handbook-of-practical-logic-and-automated-reasoning-haskell
Guest34608 2017-02-27 10:02:49
dumb question - when asked to express `foldl` using `foldr` why not just do something like `foldl f e = foldr (flip f) e . reverse`?
monochrom 2017-02-27 10:04:38
Can you make it work for infinite lists too?
lispy 2017-02-27 10:14:11
Well, if you can make it work the trick will be to give the passed in function control before the recursive call to foldl
ertes 2017-02-27 10:14:23
lispy: you can write foldl and foldl' in terms of foldr though… perhaps you thought of that?
ski 2017-02-27 10:14:58
that's what Guest34608 was asking about
vlnts 2017-02-27 10:19:03
I am not really convinced haskell-vim-now is what I want. It blasts my current vimrc and replaces it with a new one under a different git repo than my current dot-files ?
maerwald 2017-02-27 10:19:23
yeah, it's crap... just take a look at the plugins it installs and do things properly
lyxia 2017-02-27 10:22:32
Say I have a profunctor P, which is also an applicative (meaning there is an instance Applicative (P x)), obeys the law and all. Does parametricity give us: lmap f (a <*> b) = lmap f a <*> lmap f b?
ertes 2017-02-27 10:31:04
merijn: or a TVar Bool, but an MVar is probably much faster
lyxia 2017-02-27 10:31:09
dolio: Great thanks! Now I'm thinking maybe it doesn't matter that I have an Applicative, and parametricity of (<*>) is sufficient.
kyclark 2017-02-27 10:31:36
I have two questions re: stack. How can I change the build directory from my $HOME? How can I change stack to use 8.0.2 by default when I do "stack ghci"? Sorry, but I can't find the answers online.
merijn 2017-02-27 10:31:57
And I don't suppose in the past weeks where I didn't look someone patched criterion to allow per-benchmark setup/cleanup?
sm 2017-02-27 10:32:10
kyclark: for the second, set resolver: lts-8.2 in ~/.stack/global/stack.yaml
sm 2017-02-27 10:32:25
or 8.3, even
sm 2017-02-27 10:32:45
for the first, what do you mean ?
dolio 2017-02-27 10:32:52
lyxia: Yeah, it has nothing to do with Applicative.
ertes 2017-02-27 10:33:13
merijn: you mean per-iteration?
merijn 2017-02-27 10:33:19
ertes: Yeah
ertes 2017-02-27 10:33:28
i don't think that's possible with criterion
merijn 2017-02-27 10:33:40
ertes: Well, not yet :p
kyclark 2017-02-27 10:33:49
On an HPC machine, I'm running out of disk in my $HOME when I try to build the latest GHC, so I want to tell stack to build out of the /scratch dir.
merijn 2017-02-27 10:33:54
It didn't look particularly complex to write, but I was hoping to not have too xD
ertes 2017-02-27 10:34:25
merijn: if it literally uses linear regression on time, then it might be a bit more complicated than it sounds =)
merijn 2017-02-27 10:35:22
ertes: I looked at the implementation and the main reason it's not there appears to be "we didn't need it and wanted to avoid the potential overhead"
merijn 2017-02-27 10:39:31
ertes: hmmm, actually, you might be right
merijn 2017-02-27 10:39:33
rats...
merijn 2017-02-27 10:41:52
That's kinda annoying...
merijn 2017-02-27 10:42:05
So, any alternatives to criterion for benchmarking?
ertes 2017-02-27 10:43:00
merijn: you could add virtual time to criterion
merijn 2017-02-27 10:43:18
virtual time?
ertes 2017-02-27 10:43:18
it doesn't seem to insist on a particular notion of time
ertes 2017-02-27 10:43:30
yeah, like real time, but with initialisation time subtracted
merijn 2017-02-27 10:44:21
that's rather messy, because then I need to intersperse timings within that total timer and somehow track them
dolio 2017-02-27 10:44:34
lyxia: The way you can tell is...
dolio 2017-02-27 10:44:41
@free ap :: F x -> F x -> F x
lambdabot 2017-02-27 10:44:41
$map_F f . ap x = ap ($map_F f x) . $map_F f
ertes 2017-02-27 10:44:44
that would also let you performGC between iterations without counting the overhead (performGC is pretty expensive)
