I have added a library into my project and now I am getting this error
clojurescript undeclared Var goog.structs/Map
This is the library : https://github.com/ptaoussanis/tempura/blob/master/src/taoensso/
It's a known issue, to be fixed at some point, but can be safely ignored:
https://github.com/ptaoussanis/timbre/issues/305
If you don't want to ignore it, add the newest version of the underlying com.taoensso/encore library to your dependencies; either:
as [com.taoensso/encore "2.117.0"] into project.clj if you're using leiningen, or
as {com.taoensso/encore {:mvn/version "2.117.0"} if you're using tools.deps.
This will force the encore version to resolve to the newest one, and ignore the version the tempura library has declared.
https://github.com/ptaoussanis/tempura/issues/29#issuecomment-557178091
Related
When I am writing this, the MDN shows that HTMLDialogElement is supported in all browser except Internet Explorer.
But weirdly enough, while using it, there is a warning which says it's not supported in most of the browsers and marks it depreceted. That was not the problem, until I found that calling showModal() is giving me error:
Property 'showModal' does not exist on type HTMLDialogElement
Am I missing something?
Here is my code:
let elem: HTMLDialogElement = document.getElementById("dlg") as HTMLDialogElement;
elem.showModal(); // this line gives error
According to the type definitions (lib.dom.d.ts) for HTMLDialogElement there is no method showModal(). You could cast elem to any to make the TypeScript Transpiler accept it:
(elem as any).showModal()
However, you should not use deprecated APIs. If you are using Material with Angular you could use the MatDialog service instead.
HTMLDialogElement.showModal is available as of TypeScript 4.8.3.
Run npm install --save-dev typescript#4.8.3.
I'm building a package tested for CUDA 9,10 from source, trying to compile it for CUDA11.
I've already changed gencode=arch=compute_70 (was set on 30), and added
target_link_libraries(tsnecuda ${CUDA_cusparse_LIBRARY})
Unfortunately, I still get
tsne-cuda/src/util/math_utils.cu(153): error: identifier "cusparseScsr2csc" is undefined
tsne-cuda/src/util/math_utils.cu(165): error: identifier "cusparseXcsrgeamNnz" is undefined
tsne-cuda/src/util/math_utils.cu(195): error: identifier "cusparseScsrgeam" is undefined
3 errors detected in the compilation of "tsne-cuda/src/util/math_utils.cu".
CMake Error at tsnecuda_generated_math_utils.cu.o.cmake:276 (message):
Error generating file
tsne-cuda/build/CMakeFiles/tsnecuda.dir/src/util/./tsnecuda_generated_math_utils.cu.o
Is there a chance the build process somehow ignores my target_link_libraries? Should I add something else?
Undefined identifier is a compilation issue, not a linking issue.
At least part of the problem here is that CUDA deprecated and removed some functionality from cusparse, including cusparse<t>csr2csc(). The code would need to be rewritten to compile correctly under the latest versions of CUDA 11.x.
For example, for csr2csc, the call to cusparseScsr2csc might be refactored to use this function instead.
One example of deprecation/removal notice for cusparse<t>csr2csc is given here.
In my ClojureScript code I am requiring a JavaScript module called seedrandom which is in the node_modules folder, like this:
(ns something.core
(:require ["seedrandom" :as rnd]))
(js/console.log (.quick (rnd "x")))
According to the seedrandom documentation it is intended for both nodejs and the browser, and I've previously included and used it successfully in ClojureScript code via a <script> tag, confirming it works in the browser.
Running this cljs file in lumo on the command line works well and outputs a deterministically random number.
When I try to use this same cljs file in my Reagent frontend project I see the following error:
Compiling build :app to "public/js/app.js" from ["src" "env/dev/cljs"]...
events.js:183
throw er; // Unhandled 'error' event
^
Error: module not found: "crypto" from file /home/chrism/dev/something/node_modules/seedrandom/seedrandom.js
at onresolve (/home/chrism/dev/something/node_modules/#cljs-oss/module-deps/index.js:181:30)
...
Inside seedrandom.js we see the following:
// When in node.js, try using crypto package for autoseeding.
try {
nodecrypto = require('crypto');
} catch (ex) {}
Clearly this code is intended to ignore the built-in nodejs crypto module when running in the browser. The problem, as far as I can tell, is that the ClojureScript compiler does not know that - it sees that require('crypto') and tries to pull it into the compilation phase, but can't find it because it's a nodejs built-in.
Is there some way I can tell the compiler to ignore that particular require? Or can I shim the 'crypto' module somehow? What is the cleanest way to solve this?
Note: I have previously experienced this same issue with JavaScript modules which check for the fs node module. Hope we can find a general solution to use again in future. Thanks!
Relevant versions: [org.clojure/clojurescript "1.10.520"] and [reagent "0.8.1"].
This answer is related, asking a similar question from the perspective of Google Closure, which ClojureScript uses, but I'm looking for an answer I can use specifically with cljs.
I have a Clojurescript program running in the browser.
It imports a number of libraries, and then I want to allow the user to enter some small clojurescript "glue-code" that calls those libraries.
I can see (from https://cljs.github.io/api/cljs.js/eval) that you call eval with four arguments, the first being the state of the environment, which is an atom. But can I actually turn my current environment with all the functions I've required from elsewhere, into an appropriate argument to eval?
Update :
I thought that maybe I could set the namesspace for the eval using the :ns option of the third, opts-map, argument. I set it to the namespace of my application :
:ns "fig-pat.core"
But no difference.
Looking at the console, it's definitely the case that it's trying to do the evaluation, but it's complaining that names referenced in the eval-ed code are NOT recognised :
WARNING: Use of undeclared Var /square
for example. (square is a function I'm requiring. It's visible in the application itself ie. the fig-pat.core namespace)
I then get :
SyntaxError: expected expression, got '.'[Learn More]
Which I'm assuming this the failure of eval-ed expression as a whole.
Update 2 :
I'm guessing this problem might actually be related to : How can I get the Clojurescript namespace I am in from within a clojurescript program?
(println *ns*)
is just printing nil. So maybe Clojurescript can't see its own namespace.
And therefore the :ns in eval doesn't work?
Calling eval inside a clojurescript program is part of what is called "self-hosted clojurescript".
In self-hosted clojurescript, namespaces are not available unless you implement a resolve policy. It means that have to let the browser know how to resolve the namespace e.g. loads a cljs file from a cdn.
It's not so trivial to implement namespace resolving properly.
This is explained in a cryptic way in the docstring of load-fn from cljs.js namespace.
Several tools support namespaces resolving in self-host cljs running in the browser e.g Klipse and crepl
I am trying to compile NPAPI plugin under Win-XP and VS 2008.
Its giving me error as nsScriptablePeer.obj : error LNK2019: unresolved external symbol _NPN_Evaluate referenced in function when I try to use NPN_Evaluate to call javascript function . I have added all libraries from xulrunner-sdk/lib and xullrunner-sdk/sdk/lib in additional library directories. Is there any other library needs to be included to use NPN_Evaluate function ?
The functions beginning with NPN_ are only accessible through the pointer passed during the initialization NP_Initialize phase. I've been caught by this situation and I decided to document a bit here.
In other words, you don't have to link a library but you have to catch the pointer to the NPN browser functions during the NP_Initialize call to your plugin.
You can find a brief rundown of npapi plugins in general here:
http://colonelpanic.net/2009/03/building-a-firefox-plugin-part-one/
it's a little disjointed, but my goal was to answer some of the not-well-explained parts of NPAPI, like the one you ran into here =]
Incidently, if you're using nsScriptablePeer, you're using an outdated example that still uses XPCOM instead of NPObjects. XPCOM will no longer be supported in future versions of firefox (starting 3.6, I believe)
A little more about that here: http://colonelpanic.net/2009/08/building-a-firefox-plugin-%E2%80%93-part-three/