-
Notifications
You must be signed in to change notification settings - Fork 18
/
Notes.txt
148 lines (97 loc) · 6.12 KB
/
Notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
BUGS:
[ ] demo/Main.hs segfaults on subsequent compilations when evaluating Green.green.
http://hackage.haskell.org/package/optparse-generic
TODO:
[ ] Should be able to use SubHalive to slim down Halive.hs even further by
using a SubHalive thread, printing exceptions, and running successful HValues
as IO () actions on the main thread (rather than using runStmt)
[ ] New async typechecking context would form a nice basis for a runtime query system
(run over TCP, with Halive passing the port via an environment variable to Halive.Utils)
[ ] Think if -fdefer-type-errors gives us anything interesting
[ ] Flag handling update:
The three below would be subsumed by just using the parseStaticFlags/parseDynamicFlags
functions to set up DynFlags, and then parsing out the included paths from there. That way we
act nearly identically to 'ghc'/'ghci'/'runhaskell'.
[ ] Add -Wall support
https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc/DynFlags.html#t:Settings
[ ] Add general GHC flag support, which should be easy enough
[ ] Watch all included path trees rather than the current directory.
[ ] Create a dotfile for configuration (as an alternative to command line arguments)
[ ] Bug: halive crashes if multiple files are saved/added at once
[ ] Sort-of-bug: some editors do a delete/replace instead of a modify on files, so we don't see the change. Only watching for modify makes sense since creations and deletions can't affect running code until something is modified, and watching for them might unnecessarily halt your program while you're working on creating a file. So possibly make this optional.
[ ] Improve Control-C handling
http://neilmitchell.blogspot.fr/2015/05/handling-control-c-in-haskell.html
http://stackoverflow.com/questions/2349233/catching-control-c-exception-in-ghc-haskell
[ ] Try integrating different debugging workflows.
putStrLn/trace debugging is already a lot nicer with Halive since you can
toggle them on and off while the program is running. Expand on this
to begin subsuming some of the functionality of a typical debugger,
except with just plain old code.
E.g., a breakpoint can just be an STM transaction that 'retry's
on a global boolean TVar when it's false
Re-add a REPL that can be used to query program information.
Add tools to place and record state history into global variables that can be
queried by the REPL.
Be sure to compare these with ekg, GHC's eventlog.
[ ] Check if we need foreign-store at all; it seems like global MVars would do the trick just as well.
(note: I think I tried this and MVars are in fact cleared upon recompilations)
[ ] Can fix Halive breaking with .o files present
http://stackoverflow.com/questions/12790341/haskell-ghc-dynamic-compliation-only-works-on-first-compile
target <- guessTarget "*Test.hs" Nothing
addTarget target
DONE
[x] Async typechecking, and only restarting programs when they typecheck
[x] Figure out how to make Halive work on windows
[x] Add helpers for restarting user threads
http://stackoverflow.com/questions/24999636/is-there-a-way-to-kill-all-forked-threads-in-a-ghci-session-without-restarting-i
[x] Add program command line argument support.
I'm guessing that programs run under Halive will currently get Halive's own command line args.
We could use the -- convention to separate halive arguments from program arguments,
and call withArgs before running the program's "main".
Once we've got this, we should be able to live edit Halive's source with Halive which should
be a fun demo.
(done thanks to Jonathan Geddes @jargv !)
[x] Configurable watched filetypes (with flags)
NOTES:
I couldn't make halive as a library due to an oddity with
ghc @rpaths suddently not resolving.
Should you base things off the code, be aware that executables
must be built with the -dynamic flag for ghc or else strange errors
may occur when interfacing with external libraries like CoreFoundation
(GHCi uses this flag for its executable as well).
Tried to generate the Hackage description with:
pandoc -f markdown_github -t haddock README.md
but it didn't seem to be quite the right format. Punted to redirecting to github for now.
Reference links:
GHC API Tutorial
http://www.covariant.me/notes/ghcapi.html
Thomas Schilling - The "new" GHC API
http://sneezy.cs.nott.ac.uk/fplunch/weblog/wp-content/uploads/2008/12/ghc-api-slidesnotes.pdf
https://wiki.haskell.org/GHC/As_a_library
https://parenz.wordpress.com/2013/08/17/ghc-api-interpreted-compiled-and-package-modules/
https://parenz.wordpress.com/2013/07/29/ghc-packagedb/
"How to reload module that package has linked in memory?" by Andy Stewart
https://mail.haskell.org/pipermail/haskell-cafe/2010-December/087684.html
"Dynamically loading and unloading (C) object files" by Edsko de Vries
Talks about using linkObj and unlinkObj to compile and load C code into a running program.
https://mail.haskell.org/pipermail/ghc-devs/2013-November/003170.html
http://bluishcoder.co.nz/2008/11/25/dynamic-compilation-and-loading-of.html
See if these help with Windows
"Loading of shared libraries is problematic in ghc 7.10.1"
https://ghc.haskell.org/trac/ghc/ticket/10442
"Need option to use system gcc and binutils on Windows/msys2"
https://ghc.haskell.org/trac/ghc/ticket/9101
-- Works around a yet-unidentified segfault when loading
-- 5/1/2016: I've implemented this in a different way,
-- (by just passing in a file to compile that will trigger
-- loads of all its dependencies)
-- but this is still a viable approach... not quite as convenient though!
--let gscPreloadPackagesForModules = ["Sound.Pd"]
--preloadPackageKeys <- forM gscPreloadPackagesForModules $ \modName ->
-- modulePackageKey <$> findModule (mkModuleName modName) Nothing
--let finalPackageIDs = preloadPackageKeys ++ packageIDs
-- This brings all top-level definitions into scope (whether exported or not),
-- but only works on interpreted modules
--setContext (IIModule . ms_mod_name <$> graph)
-- Use GHC.dynamicGhc to detect dynamicity of executable and respond appropriately or error out
https://github.com/mvdan/hint/pull/18/files