sorry, gotta go now for the announcement at https://twitter.com/LIGO… will be back later. thanks for your help so foar!
Nick Tchayka
@NickSeagull
Great! Thanks to you for giving this valuable feedback!
Good luck there :)
Marco Z
@ocramz
@NickSeagull if you have time you should consider submitting a paragraph or two on Haskell.do to the HCAR
the first deadline's closed now but Mihai gave all the authors 4 more days for proofreading the draft
Nick Tchayka
@NickSeagull
Great! Thanks @ocramz ! 😁
Marco Z
@ocramz
Hi all
I've started tinkering with the code, with a mind to write a miso-based frontend
but I have some doubts regarding the overall design and I figured this would be the place to discuss
so on one hand we have typical cabal/stack projects: multiple files in multiple directories, with dependencies forming a DAG
on the other, the notebook-style interaction: evaluate a cell, show results, evaluate another cell etc.
Marco Z
@ocramz
is the "cell view" just a split view of a single source file, and every time we modify one cell a stack build is issued? or something equivalent to a stack build --file-watch is constantly running?
Marco Z
@ocramz
something else confuses me
in miso, where do startApp and the App type come from? they are seemingly not exported by the library
Nick Tchayka
@NickSeagull
Hi @ocramz , right now there is no cell view, its just a whole document that uses the inliterate preprocessor
Basically a stack build is issued each time
And also, Miso is quite weird, because those functions are only exported in the GHCJS version of it, not on the regular GHC one
So we would have to separate completely the backend from the frontend
Shoudlnt be that hard tho
Marco Z
@ocramz
ha, what I suspected
now I'm trying to write a bare-bones project to figure out what goes where
_
I do like miso because M-V-C are well separated
though I'm completely ignorant re. frontend development
Marco Z
@ocramz
I feel miso is a very good choice to refurbish the project
Nick Tchayka
@NickSeagull
Indeed it is @ocramz . Another thing that I was thinking of was to completely rewrite the backend and make it a RESTful API using some other framework like wai or yesod which are much more used in the Haskell community
Marco Z
@ocramz
@NickSeagull what functionality would you put in the backend? the filesystem browser?
I'm having a good experience with miso but I don't get why certain IO doesn't work, for example listing a directory
so I wonder if it's a good idea to move that to a pure GHC backend
once I figure this out I'm ready to help with the haskell-do refactor
Kevin C
@dataopt
I was trying to figure out what miso is without digging into the code. What is it supposed to do?
Marco Z
@ocramz
@dataopt it lets you write both the visible part and the behaviour of a single-page application
in the "model-view-controller" style, i.e. a finite state machine
the model is the state, buttons and whatever inputs are the controller and view is the visible part of this
Kevin C
@dataopt
ic
Nick Tchayka
@NickSeagull
@ocramz I would basically put the filesystem browser, compilation, save file, etc...
Tony Day
@tonyday567
@ocramz would be interested in what you might have in mind.
I've been thinking to put a websocket in chart-unit for a while now, then luna came along, and now I want to try something like that out.
I imagine it's beyond svg, so would have to learn about front-end and canvas, and miso might wrap it all up nicely.
Tim Pierson
@o1lo01ol1o
@tonyday567 you might check the transient gitter for some of @agocorona 's latest notes on that.
Marco Z
@ocramz
@tonyday567 you're thinking of reactive/interactive graphics? I'm afraid I don't have any experience with those. Javascript callbacks into Haskell sound gnarly, but I'm the least qualified here to say this