I compiled and installed haddock-2.4.2 from the tarball source.
Adding a few simple comments to the code here:
https://dl.getdropbox.com/u/143480/doc/DualMap.hs
and running haddock
$ haddock -h -o doc Data/DualMap.hs
Warning: Data.DualMap: could not find link destinations for:
Data.Typeable.Typeable2 GHC.Base.Eq GHC.Show.Show GHC.Base.Ord GHC.Base.Bool Data.Set.Set
yields:
https://dl.getdropbox.com/u/143480/doc/Data-DualMap.html
Things look good. (Note that this module only depends on libs that ship with GHC and no other source modules.)
However, when I try to add sections (a la http://www.haskell.org/haddock/doc/html/ch03s04.html#id289234 ) in the comments with "-- * test" I get:
$ haddock -h -o doc Data/DualMap.hs
Data/DualMap.hs:20:0: parse error on input `-- * test'
haddock: Failed to create dependency graph
I have no idea where to begin getting this to work since this error message only tells me that Haddock.Interface.depanal returned Nothing (according to a grep of the haddock sources) but not how to stop the dependency analysis from failing. Perhaps I need some more command line arguments or references to missing link destinations in GHC/base/containers documentation or some haddock config file?
Searching Google yielded plenty of cabal build errors of the same ilk for packages on hackage but nothing about how to fix them.
How do I add sections (with asterisks) and get Haddock to generate my docs? What (probably simple thing) am I missing?
Simple fix (terrible error message):
Move the ( up to the line with the module name. Previous bad code:
module Data.DualMap
-- * The #DualMap# abstract type
( DualMap ()
-- * (?) internal? -- exposed for testing purposes, for now...
, dmFlip
-- * converting to and from DualMap
, toList, fromList, map
-- * constructing a DualMap
, empty, null, insert, union
Happy code looks like this:
module Data.DualMap (
-- * The #DualMap# abstract type
DualMap ()
-- * (?) internal? -- exposed for testing purposes, for now...
, dmFlip
-- * converting to and from DualMap
, toList, fromList, map
-- * constructing a DualMap
, empty, null, insert, union
Simple enough. I found this out by downloading DList from hacakge and gutting it and replacing the code with my own code. When DList worked with 'cabal haddock' and mine didn't (when I tried to add some asterisks), I looked at the difference between the files and sure enough my parenthesis was on the wrong line.
BTW I highly recommend DList as a starting place for a new Haskell project instead of hnop.
Related
Loading a module (ABC) with require works in one module of a distribution while it fails in another module of the distribution.
What could be the reason that loading ABC with require fails in one place?
require Name::ABC;
my $new = Name::ABC.new(); # dies: You cannot create an instance of this type (ABC)
perl6 -v
This is Rakudo Star version 2019.03.1 built on MoarVM version 2019.03
implementing Perl 6.d.
The the required module: App::DBBrowser::Subqueries
App::DBBrowser::Union, line 80: OK *
App::DBBrowser::Join, lines 66 and 191: OK *
App::DBBrowser::Table::Extensions, line 49: OK *
App::DBBrowser, line 690: You cannot create an instance of this type (Subqueries) *
App::DBBrowser::CreateTable, line 112: You cannot create an instance of this type (Subqueries) *
* version 0.0.1
$ cat XXX.pm6
unit class XXX;
$ cat ZZZ.pm6
module ZZZ {
require XXX;
XXX.new;
say "OK";
}
$ perl6 -I. -e 'use ZZZ;'
===SORRY!===
You cannot create an instance of this type (XXX)
From the documentation:
require loads a compunit and imports definite symbols at runtime.
You are doing a runtime load of a module while also expecting the symbols for that module to exist at compile time. Instead you should use indirect name lookup (as shown at the bottom of the documentation page linked earlier):
$ cat XXX.pm6
unit class XXX;
$ cat ZZZ.pm6
module ZZZ {
require XXX;
::("XXX").new;
say "OK";
}
$ perl6 -I. -e 'use ZZZ;'
OK
I think it's because require is a runtime load whereas use is compile time.
Generally I'd use use unless I have a need for dynamic module loading at runtime.
use loads and imports a module at compile-time while require only loads a module at runtime.
Since the namespace is checked at compile-time, you can't just access it as you would a module that is loaded and imported with use.
You can get around that by symbolic references, but you can also capture the namespace into a variable.
(Assuming there is only a single namespace in the module, and it is the same as the name used to load it)
Foo.pm6:
unit module Foo;
sub fubar () { say 'fubar' }
my \Foo = do require Foo;
Foo::fubar(); # fubar
(Note that the name of the variable doesn't have to be the same.)
I have a suffix handler to hack some source during build. It works fine and generates correct result.
But when I ran stack haddock, it generated docs against original source. Checking out the .hs in .stack-work/ folder, my handler was not involved.
So I checked the UserHook arg passed to haddockHook, it seemed containing my handler. So I am confused. What should I do?
PS: My Setup.hs
main =
defaultMainWithHooks simpleUserHooks
{ hookedPreProcessors = [ ("hs", \bi lbi clbi ->
PreProcessor False $ \(iD, iF) (oD, oF) verbosity -> myHandler) ]}
Update 2
I think #faré is right, it's an output translation problem.
So I declared the evironment variable ASDF_OUTPUT_TRANSLATIONS and set it to E:/. Now (asdf:require-system "my-system") yields a different error: Uneven number of components in source to destination mapping: "E:/" which led me to this SO-topic.
Unfortunately, his solution doesn't work for me. So I tried the other answer and set ASDF_OUTPUT_TRANSLATIONS to (:output-translations (t "E:/")). Now I get yet another error:
Invalid source registry (:OUTPUT-TRANSLATIONS (T "E:/")).
One and only one of
:INHERIT-CONFIGURATION or
:IGNORE-INHERITED-CONFIGURATION
is required.
(will be skipped)
Original Posting
I have a simple system definition but can't get ASDF to load it.
(asdf-version 3.1.5, sbcl 1.3.12 (upgraded to 1.3.18 AMD64), slime 2.19, Windows 10)
What I have tried so far
Following the ASDF manual: "4.1 Configuring ASDF to find your systems"
There it says:
For Windows users, and starting with ASDF 3.1.5, start from your
%LOCALAPPDATA%, which is usually ~/AppData/Local/ (but you can ask in
a CMD.EXE terminal echo %LOCALAPPDATA% to make sure) and underneath
create a subpath config/common-lisp/source-registry.conf.d/
That's exactly what I did:
Echoing %LOCALAPPDATA% which evaluates to C:\Users\my-username\AppData\Local
Underneath I created the subfolders config\common-lisp\source-registry.conf.d\ (In total: C:\Users\my-username\AppData\Local\config\common-lisp\source-registry.conf.d\
The manual continues:
there create a file with any name of your choice but with the type conf, for instance 50-luser-lisp.conf; in this file, add the following line to tell ASDF to recursively scan all the subdirectories under /home/luser/lisp/ for .asd files: (:tree "/home/luser/lisp/")
That’s enough. You may replace /home/luser/lisp/ by wherever you want to install your source code.
In the source-registry.conf.d folder I created the file my.conf and put in it (:tree "C:/Users/my-username/my-systems/"). This folder contains a my-system.asd.
And here comes the weird part:
If I now type (asdf:require-system "my-system") in the REPL I get the following error:
Can't create directory C:\Users\my-username\AppData\Local\common-lisp\sbcl-1.3.12-win-x86\C\Users\my-username\my-systems\C:\
So the problem is not that ASDF doesn't find the file, it does -- but (whatever the reason) it tries to create a really weird subfolder hierarchy which ultimately fails because at the end it tries to create the folder C: but Windows doesn't allow foldernames containing a colon.
Another approach: (push path asdf:*central-registry*)
If I try
> (push #P"C:/Users/my-username/my-systems/" asdf:*central-registry*)
(#P"C:/Users/my-username/my-systems/"
#P"C:/Users/my-username/AppData/Roaming/quicklisp/quicklisp/")
> (asdf:require-system "my-system")
I get the exact same error.
I don't know what to do.
Update
Because of the nature of the weird path ASDF was trying to create I thought maybe I could bypass the problem by specifying a relative path instead of an absolute one.
So I tried
(:tree "\\Users\\my-username\\my-systems")
in my conf file. Still the same error.
Ahem. It looks like an output-translations problem.
I don't have a Windows machine right now, but this all used to work last time I tried.
Can you setup some ad hoc output-translations for now that will make it work?
I have a autoconf/automake system that has a stand-alone target called stand. I don't want stand to be normally built, so I have this in my Makefile.am:
bin_PROGRAMS = grace
extra_PROGRAMS = stand
...
stand_SOURCES = stand.cpp barry.cpp ...
This has worked for a while, but automake just got updated on my system and I'm now getting this error:
src/Makefile.am:4: error: 'extra_PROGRAMS' is used but 'extradir' is undefined
src/Makefile.am:66: warning: variable 'stand_SOURCES' is defined but no program or
src/Makefile.am:66: library has 'stand' as canonical name (possible typo)
So I added this:
extradir = .
But that has caused problems.
I don't want the stand program installed. It's just a test program for me. But it's not part of a formal test suite, it's just for my own purposes. What should I do?
We found the bug! It turns out that extra needs to be capitalized, like this:
bin_PROGRAMS = grace
EXTRA_PROGRAMS = stand
...
stand_SOURCES = stand.cpp barry.cpp ...
You could try conditionally building it:
noinst_PROGRAMS=
if BUILD_STAND
noinst_PROGRAMS += stand
endif
stand_SOURCES = stand.cpp barry.cpp ...
This will not install it since it's in noinst_PROGRAMS and others will normally not build it since BUILD_STAND will normally not be defined for them.
Is it possible to get SCons to remind me to perform a manual step using it's dependancy tracking?
My build uses the .swc output from a .fla, which you can't do using a command-line.
I tried something like:
env.Command(target, sources + SHARED_SOURCES,
Action(lambda target, source, env: 1, "Out of date: $TARGET"))
But with that method, I have to use Decider('make') or I get:
$ scons --debug=explain
scons: rebuilding `view_bin\RoleplaySkin.swc' because `view_src\RoleplaySkin.fla' changed
Out of date: view_bin\RoleplaySkin.swc
scons: *** [view_bin\RoleplaySkin.swc] Error 1
And, more importantly, SCons never realizes it's cache is out of date, so any change in the Environment or sources since it wrote the signature in .sconsign.dblite means it will allways try to rebuild (and therefore, always fail).
What about using the Precious method to protect the *.swc output before converting it into a *.fla?
How about creating your own RemindMe builder which reminds you and fails to build the target?
It would look something like this:
def remind_me(target, source, env):
os.remove(target.abspath) #we do not build, we destroy
print ("This is a friendly reminder, your $SOURCE is out of date, run manual build step")
return None
reminder = Builder(action = remind_me,
suffix = '.swc',
src_suffix = '.fla')
env = Environment(BUILDERS = {'RemindMe' : reminder})
#Run builder like this
swc_file = env.RemindMe('some_fla_file')
final_target = env.BuildWithSWC(some_other_target,swc_file)
This is however only a theory, I have never tried actually deleting the target instead of creating it. It might be worth a try at least.