I'm seeing the following, at the end of a "stack build foo":
Progress: 1/2
-- While building package foo-0.1.0.0 using:
[path-to-GHC] --builddir=[path-to-stack-work-area] build lib:foo
--ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
And I can't figure out how those options: -ddump-hi and -ddump-to-file, are getting into my stack build flow. I can't find them in:
stack.yaml,
foo.cabal, or
foo.hs
Does anyone know where they're coming from?
They're added by stack, the reason for it is so that stack can know about Template Haskell file dependencies, and so can know when recompilation is needed.
Related
I spent a good five or six hours the other day trying to parallelize some work in Luigi, based on the method used here: http://rjbaxley.com/posts/2016/03/13/parallel_jobs_in_luigi.html
The problem I was having was that I kept getting a luigi.task_register.TaskClassAmbigiousException which drove me crazy. Ultimately I threw luigi.auto_namespace(scope=name) at the top of my package and everything started working, but I don't know why. Roughly described, I had 3 tasks:
TaskA - required nothing
provided a txt file with paths
TaskB - requires only input parameters p1 and p2
provides a .csv file
TaskC - requires output from task A
yields one TaskB for each path pair from output A
is completed when all yielded TaskBs are completed.
If anyone can sketch how i should have done this correctly, instead of the hacked together nonsense I have now, I'd be so very grateful
Did you yield TaskB in your run() method, or in requires()? I ran into this issue when yielding in the run() method. It turned out that the task it was yielding was broken for other reasons, but Luigi wasn't very clear about propagating the full exception stack for tasks yielded in run().
To yelp debug, try calling luigi.build([TaskB]) and seeing if that throws an exception. If you can provide the full exception stack that would be helpful.
(ql:quickload "aserve") fails
I'm trying to install AllegroServe. According to http://quickdocs.org/portableaserve/ and to this SO thread the simplest way to get aserve would be to get it with quicklisp: (ql:quickload "aserve")
But (ql:quickload "aserve") fails yielding the following error in the debugger buffer:
COMPILE-FILE-ERROR while compiling
#<IRONCLAD-SOURCE-FILE "ironclad" "src" "digests" "digest">
[Condition of type UIOP/LISP-BUILD:COMPILE-FILE-ERROR]
Whereas in the REPL it says:
; Loading "aserve"
; caught ERROR: READ error during COMPILE-FILE: Symbol "BIGNUM-TYPE"
; not found in the SB-BIGNUM package. Line: 53, Column: 52,
; File-Position: 2151 Stream: #<SB-INT:FORM-TRACKING-STREAM for
; "file
; C:\\Users\\user\\AppData\\Roaming\\quicklisp\\dists\\quicklisp\\software\\ironclad_0.33.0\\src\\digests\\digest.lisp"
; {25AFCD91}>
What I've tried so far
Apparently ironclad is another package, a "cryptographic toolkit written in pure Common Lisp". I downloaded ironclad-v0.34 from http://quickdocs.org/ironclad/ and even found digest.lisp and digests.lisp in the ironclad folder which made me think that I am on the right track.
My problem is I don't no where to go from here. How and where do I "install" ironclad?
Quickdocs says
[ironclad] comes with an ASDF system definition, so (asdf:oos 'asdf:load-op
:ironclad) should be all that you need to get started. The testsuite
can be run by substituting asdf:test-op for asdf:load-op in the form
above.
but since I'm not familiar with asdf I don't know what to make of it.
Am I even on the right track? Is installing the ironclad package the right way to make the error COMPILE-FILE-ERROR while compiling #<IRONCLAD-SOURCE-FILE "ironclad" "src" "digests" "digest">go away? If so what do I do with the ironclad-v0.34 folder?
(I'm using sbcl on a windows 10 machine.)
Thanks to #jkiiski leading me down the right path I was able to install aserve. The problem was indeed an old version of ironclad which, as #jkiiski pointed out, was using SB-BIGNUM:BIGNUM-TYPE which had been removed from SBCL.
However, the way I updated ironclad is probably NOT(!) a good way because I did it all manually (error prone).
Not knowing how quicklisp works exactly I searched for every occurence of ironclad-0.33.0 and replaced it with ironclad-v0.34, which meant replacing
the .../dists/quicklisp/software/ironclad-0.33.0 folder with .../dists/quicklisp/software/ironclad-v0.34
the irconcladd-0.33.0 tgz in .../dists/quicklisp/archives/ with ironclad-v0.34.tgz
the entry dists/quicklisp/software/ironclad-0.33.0/ in .../dists/quicklisp/installed/releases/ironclad.txt with dists/quicklisp/software/ironclad-v0.34/.
I also updated ironclad.txt and ironclad-text.txt in .../dists/quicklisp/installed/systems/
Well, it worked, but I only did it this way because I don't know any better (but am sure there has to be a better way).
I am working on a PHP/Javascript project where I've nicely set up a build workflow. It involves testing, minifying, compressing into the final zip deliverable, and a whole lot of other nice stuff.
I want to build a task that fails when there are certain patterns in the source code. I would like to look for any print_r(), error_log(), var_dump(), etc functions, and halt the build process if there are any. Perhaps later I would like to check for things in Javascript or CSS so this is not only a PHP question.
I know it can be done with grunt-shell and grep but I'd like to know the following:
Are there any grunt plugins specific to this task? Ideally I would like to be able to specify a list of regexes per file type, and to set whether to continue or fail the build on pattern match.
How do others tackle the problem of double-checking the packaged source for the most common debug statements or other patterns?
Not a complete answer to my question, but I've recently come across this grunt plugin which is somewhat related. It removes console.log statements from JavaScript. Haven't tried it yet. Looks good. I still would like to know if there's something similar for PHP though.
http://grunt-tasks.com/grunt-remove-logging-calls/
Edit: Seeing as there's only tumbleweeds rolling in the wind here, I'm posting my workaround that's based on grunt-shell. However this is not what I was looking for. It's not perfect because it doesn't do proper syntax parsing:
shell: {
check_debug_prints: {
command: '(! (egrep -r "var_dump|print_r|error_log" --include=*.php src || egrep -r "console\.\w+|debugger;" --include=*.js src) ) || (echo "Debug prints in source - build aborted" && false )'
}
},
and
grunt.loadNpmTasks( 'grunt-shell' );
Edit 2: I finally found the exact grunt plugin I was looking for. It is grunt-search. There is a failOnMatch boolean option that lets you indicate if a particular regex pattern should cause the build to fail when found.
I'm writing am openembedded/bitbake recipe for openembedded-classic. My recipe RDEPENDS on keyutils, and everything seems to work, except one thing:
I want to append a single line to the /etc/request-key.conf file installed by the keyutils package. So I added the following to my recipe:
pkg_postinst_${PN} () {
echo 'create ... more stuff ..' >> ${sysconfdir}/request-key.conf
}
However, the intended added line is missing in my resulting image.
My recipe inherits update-rc.d if that makes any difference.
My main question is: How do i debug this? Currently I am constructing an entire rootfs image, and then poke-around in that to see, if the changes show up. Surely there is a better way?
UPDATE:
Changed recipe to:
pkg_postinst_${PN} () {
echo 'create ... more stuff ...' >> ${D}${sysconfdir}/request-key.conf
}
But still no luck.
As far as I know, postinst runs at rootfs creation, and only at first boot if rootfs fails.
So there is a easy way to execute something only first boot. Just check for $D, like this:
pkg_postinst_stuff() {
#!/bin/sh -e
if [ x"$D" = "x" ]; then
# do something at first boot here
else
exit 1
fi
}
postinst scripts are ran at roots time, so ${sysconfdir} is /etc on your host. Use $D${sysconfdir} to write to the file inside the rootfs being generated.
OE-Classic is pretty ancient so you really should update to oe-core.
That said, Do postinst's run at first boot? I'm not sure. Also look in the recipes work directory in the temp directory and read the log and run files to see if there are any clues there.
One more thing. If foo RDEPENDS on bar that just means "when foo is installed, bar is also installed". I'm not sure it makes assertions about what is installed during the install phase, when your postinst is running.
If using $D doesn't fix the problem try editing your postinst to copy the existing file you're trying to edit somewhere else, so you can verify that it exists in the first place. Its possible that you're appending to a file that doesn't exist yet, and the the package that installs the file replaces it.
It is difficult for me to catch with the eye a boundary between test runs.
Is it possible to clear console for each run of Testacular/Karma + Jasmine or at least put there something easily catched by the eye, for example a series of newlines?
Note
Currently it is an abandoned question because I am no longer trying to perform tasks described in it. Please do not ask for additional info. Write only if you know for sure what to do. It will help other people.
Write your own reporter, and do whatever you want with it.
Also, if you're on a Mac and use Growl, take a look at karma-growl-reporter
I am not sure to fully understand your need but karma-spec-reporter can give you a detailed review of your test execution. Output example from karma-spec-reporter-example:
array:
push:
PASSED - should add an element
PASSED - should remove an element
FAILED - should do magic (this test will fail) expected [] to include 'magic'
at /home/michael/development/codecentric/karma-spec-reporter-example/node_modules/chai/chai.js:401
...
PhantomJS 1.8.1 (Linux): Executed 3 of 3 (1 FAILED) (0.086 secs / NaN secs)
There's now a reporter available for this: https://github.com/arthurc/karma-clear-screen-reporter
It's working for me on OSX.