I am following shadow-cljs Quick Start documentation on a minimal example of a project. Here is the link.
Initially, I had this shadow-cljs.edn file:
;; shadow-cljs configuration
{:source-paths
["src/dev"
"src/main"
"src/test"]
:dev-http {8080 "public"}
:dependencies
[]
:builds
{:frontend
{:target :browser
:modules {:main {:init-fn acme.frontend.app/init}}
}}}
In /Users/pedro/projects/acme-app/src/main/acme/frontend/app.cljs, I also have:
(ns acme.frontend.app)
(defn init []
(println "Hello World"))
I can build and watch it with the command:
$ npx shadow-cljs compile frontend
shadow-cljs - config: /Users/pedro/projects/acme-app/shadow-cljs.edn
shadow-cljs - updating dependencies
shadow-cljs - dependencies updated
[:frontend] Compiling ...
[:frontend] Build completed. (79 files, 0 compiled, 0 warnings, 4.88s)
I have been adding dependencies such as:
:dependencies [[day8.re-frame/re-frame-10x "1.2.1"]
[proto-repl "0.3.1"]
[re-frame "1.2.0"]
[com.degel/re-frame-firebase "0.9.6-SNAPSHOT"]
[bidi "2.1.5"]
[re-com "2.13.2-106-180ea1f-SNAPSHOT-TALLYFOR"]
[com.andrewmcveigh/cljs-time "0.5.2"]
[com.pupeno/free-form "0.6.0"]
[binaryage/dirac "RELEASE"]
[hickory "0.7.1"]
[cljs-hash "0.0.2"]
[medley "1.2.0"]]
But, the build does not change in terms of files, compiled, and warnings. Just the time changes a bit - time is probably somewhat random/stochastic (79 files, 0 compiled, 0 warnings, 5.59s).
Are the dependencies really been compiled? How do I know if the dependencies were compiled too?
If they are being compiled, why does the number of files stay the same?
Obs.: note that I am not invoking the function being used inside the dependencies - and I do not want to invoke them for debugging reasons.
Adding the :dependencies does very little, they'll not be compiled on their own. They are only made available on the classpath.
They will only be compiled and loaded once you add them the :require in the ns forms of your files, or dynamically require at the REPL. Without an explicit request (ie. :require) to load them, they are just passive resources that are unused.
Related
I have a pre-commit hook set up using jest and the --only-changed flag. However, sometimes my entire test suite will still run (800 tests!) even if I made a change in a single file.
I looked into some other jest flags like
--lastCommit Run all tests affected by file changes in
the last commit made. Behaves similarly to
`--onlyChanged`.
--findRelatedTests Find related tests for a list of source
files that were passed in as arguments.
Useful for pre-commit hook integration to
run the minimal amount of tests necessary.
--changedSince Runs tests related to the changes since the
provided branch. If the current branch has
diverged from the given branch, then only
changes made locally will be tested. Behaves
similarly to `--onlyChanged`. [string]
Yet they all have the same problem. When doing some digging, I learned that
under the hood "If the found file is a test file, Jest runs it, simple enough. If the found file is a source file, call it found-file.js, then any test files that import found-file.js and the test files that import any of the source files that themselves import found-file.js will be run."
I'm working on a project that's relatively new to me. I'm wondering if it's possible for me to get my pre-commit hook to ONLY run the edited test, not all affected tests, or if there is a way for me to track down this tree of "transitive inverse dependencies" and try to solve the problem with different imports or something.
Here is an example of some output from trying --find-related-tests
Test Suites: 2 failed, 309 passed, 311 total
Tests: 2 failed, 803 passed, 805 total
Snapshots: 308 passed, 308 total
Time: 102.366 s
Ran all test suites related to files matching /\/Users\/me\/repo\/project\/src\/modules\/dogs\/components\/spots\/SpotsSpotter.tsx/i.
> #dogsapp/project#1.0.0 test:staged
> jest --findRelatedTests --passWithNoTests "/Users/me/repo/project/src/modules/dogs/components/spots/SpotsSpotter.tsx"
ERROR: "husky:lint-staged" exited with 1.
husky - pre-commit hook exited with code 1 (error)
It's taking WAY too long when I just made a simple change in one file. Anyone know how I can track down why this is happening?
It seems like something similar was addressed here for the --watch flag: https://www.gitmemory.com/issue/facebook/jest/8276/483695303
Whenever I run "react-native run-ios" I'm getting the following build error
error: Cycle in dependencies between targets 'FBReactNativeSpec' and
'Yoga'; building could produce unreliable results. Cycle path:
FBReactNativeSpec → Folly → glog → YogaKit → Yoga → FBReactNativeSpec
Cycle details: → Target 'FBReactNativeSpec' has target dependency on
Target 'Folly' → Target 'Folly' has target dependency on Target 'glog'
→ Target 'glog' has compile command with input
'/Users/ajayhg/Myproj/ios/Pods/Target Support Files/glog/glog-dummy.m'
○ That command depends on command in Target 'YogaKit': script phase
“Copy generated compatibility header” → Target 'YogaKit' has target
dependency on Target 'Yoga' → Target 'Yoga' has compile command with
input '/Users/ajayhg/Myproj/ios/Pods/Target Support
Files/Yoga/Yoga-dummy.m'
how to resolve this?
I solved the problem by doing ⌘+Shift+K and rebuilding.
I have exact same problem on our app, but unfortunately no solution yet.
Known workaronds are:
Switch to legacy build system. It doesn't react on those "fake" cycles
Clean and rebuild usually helps. If not, then try to clean and reinstal cocoapods.
Relevant thread here.
It appears as though Firebase adds a script phase in an order that creates a dependency loop. You can fix it (laboriously, after every pod install) by going to XCode > Pods (in the left bar) > FBReactNativeSpec and moving [CP-User] Generate Specs up above the Headers script(s).
gitolite info didn't work, adding keys turned them into a no access key and did NOT create a corresponding entry in auth-keys file.
To fix this run gitolite setup on gitolite server
Question: what could have landed me in that mess?
And what does gitolite setup do when invoked for the n-th time (it's no longer setting things up, according to the docs it fixes hooks, but I wonder what the use case would be and which was mine)?
More details on gitolite info
gitolite info command is invoked like so:
> ssh git-user#ser-git
PTY allocation request failed on channel 0
hello git-admin, this is ...#... running gitolite3 3.6.7-2 (Debian) on git 2.17.1
R W some-repository
R W gitolite-admin
R W testing
Connection to ser-git closed.
Bad output is: FATAL: unknown git/gitolite command: 'info'
More details: keys without access.
gitolite sshkeys-lint was showing keys with (no access), now those keys have access as I set them (now meaning after gitolite setup).
ssh-keygen -lf /home/repo/.ssh/authorized_keys | wc -l (or without piped part, regardless) number of keys and their names indicated I didn't have the newest one added.
Similar question that did not work for me: keydir entries not propagating to authorized_keys
Docs pretty much had the answer once I dug deeper, I guess. Which is fairly nice of #sitaramc.
Without options, 'gitolite setup' is a general "fix up everything" command
(for example, if you brought in repos from outside, or someone messed
around with the hooks, or you made an rc file change that affects access
rules, etc.)
Symptoms keys stopped propagating and error FATAL: unknown git/gitolite command: 'info' on ssh git-user#ser-git. Fix was to run gitolite setup. So onto first question, the title one:
what does gitolite setup fix?
gitolite setup is implemented here
my Perl is rather weak, but there's a setup function in line 56. It calls args (which parses options, so here it had nothing to parse), then unless h_only (hooks only arg for setup), which wasn't used, so we skip compile and POST_COMPILE trigger and go for the hooks.
sub setup {
my ( $admin, $pubkey, $h_only, $message ) = args();
unless ($h_only) {
setup_glrc();
setup_gladmin( $admin, $pubkey, $message );
_system("gitolite compile");
_system("gitolite trigger POST_COMPILE");
}
hook_repos(); # all of them, just to be sure
}
package Gitolite::conf::store has hook_repos(), line 228: we change the dir to repo base dir (as per config file), and for each phy_repo we do hook_1(phy_repo). What is a phy_repo? a physical one.
same package, different method and line: hook_1($repo) in line 354.
Method hook_1($repo)
It's quite literally about fixing all the hooks.
Recreates dirs for common and admin hooks.
Rewrites update_hook (common) and post_update_hook (admin).
Sets 755 permissions for both common and admin hooks.
Then using ln_sf it symlinks the folders for common/admin hooks.
ln_sf is in common module, in line 162
I have an application that uses libnl. It can use either versions (1 or 3), and during configure it tries first to use ibnl3 and fallback to libnl-1 if libnl3 was not found.
My app uses another library that also uses libnl.
The problem is that I only have libnl1-dev on my machine so my app must use it.
But the library that I use uses libnl3 (was installed with yum i guess it's static linked)
so i have both version and my application crashes!!
here are some prints
ldd myapp.so|grep libnl
libnl.so.1 => /lib64/libnl.so.1 (0x00007fda33eb5000)
libnl-route-3.so.200 => /lib64/libnl-route-3.so.200 (0x00007fda32a3d000)
libnl-3.so.200 => /lib64/libnl-3.so.200 (0x00007fda3281b000)
yum list|grep libnl
libnl.x86_64 1.1.4-3.el7
libnl-devel.x86_64 1.1.4-3.el7
libnl3.x86_64 3.2.28-2.el7
libnl3-cli.x86_64 3.2.28-2.el7
libnl.i686 1.1.4-3.el7
libnl-devel.i686 1.1.4-3.el7
libnl3.i686 3.2.28-2.el7
libnl3-cli.i686 3.2.28-2.el7
if in install libnl3-dev it fixes the issue
is there another solution?
if I install libnl3-dev it fixes the issue is there another solution?
There are other solutions, but the bottom line is that you can only have libnl.so.1 or libnl-3.so.200, but not both.
Fixing this by "going all in on libnl-3" is the simplest solution.
The alternative is to "go all on on libnl-1", which means rebuilding anything that requires libnl-3 from source (against libnl-1). This is assuming that your other dependencies can be built against libnl-1 at all (which is by no means guaranteed).
Running chef-solo (Installing Chef Omnibus (12.3)) on centos6.6
My recipe has the following simple code:
package 'cloud-init' do
action :install
end
log 'rpm-qi' do
message `rpm -qi cloud-init`
level :warn
end
log 'yum list' do
message `yum list cloud-init`
level :warn
end
But it outputs the following:
- install version 0.7.5-10.el6.centos.2 of package cloud-init
* log[rpm-qi] action write[2015-07-16T16:46:35+00:00] WARN: package cloud-init is not installed
[2015-07-16T16:46:35+00:00] WARN: Loaded plugins: fastestmirror, presto
Available Packages
cloud-init.x86_64 0.7.5-10.el6.centos.2 extras
I am at a loss as to why rpm/yum and actually rpmquery don't see the package as installed.
EDIT: To clarify I am specifically looking for the following string post package install to then apply a change to the file (I understand this is not a very chef way to do something I am happy to accept suggestions):
rpmquery -l cloud-init | grep 'distros/__init__.py$'
I have found that by using the following:
install_report = shell_out('yum install -y cloud-init').stdout
cloudinit_source = shell_out("rpmquery -l cloud-init | grep 'distros/__init__.py$'").stdout
I can then get the file I am looking for and perform
Chef::Util::FileEdit.new(cloudinit_source.chomp(''))
The file moves based on the distribution but I need to edit that file specifically with in place changes.
Untested code, just to give the idea:
package 'cloud-init' do
action :install
notifies :run,"ruby_block[update_cloud_init]"
end
ruby_block 'update_cloud_init' do
block do
cloudinit_source = shell_out("rpmquery -l cloud-init | grep 'distros/__init__.py$'").stdout
rc = Chef::Util::FileEdit.new(cloudinit_source.chomp(''))
rc.search_file_replace_line(/^what to find$/,
"replacement datas for the line")
rc.write_file
end
end
ruby_block example taken and adapted from here
I would better go using a template to manage the whole file, what I don't understand is why you don't know where it will be at first...
Previous answer
I assume it's a compile vs converge problem. at the time the message is stored (and so your command is executed) the package is not already installed.
Chef run in two phase, compile then converge.
At compile time it build a collection of resources and at converge time it execute code for the resource to get them in the described state.
When your log resource is compiled, the ugly back-ticks are evaluated, at this time there's a package resource in the collection but the resource has not been executed, so the output is correct.
I don't understand what you want to achieve with those log resources at all.
If you want to test your node state after chef-run use a handler maybe calling ServerSpec as in Test-Kitchen.