I was using plovr as closure compiler for the latest google closure library, but it think it plays nicely. Why is this so?
Link=http://plovr.com/docs.html
Thanks in advance for the help,
Kiran
Generally speaking, if you update the library, you would also need to update the compiler, as they're designed to work together. Getting a new compiler release to work with Plovr is non-trivial since it makes use of its internals and thus Plovr itself must be recompiled. While Plovr supports pointing to a custom Closure Library checkout, there have been enough changes (e.g. dependency, type system, module declarations) in Closure to make Plovr's stale compiler incompatible with recent library releases.
Here are a couple blocking issues in supporting more recent editions of the Library:
#162: Dependency analysis is outdated
#160: Generation logic of deps.js is outdated
This is particularly striking as new namespaces in the Library make use of the goog.module-style declaration.
I would like to add that I have contributed to Plovr last week to be able to support the latest version. However, since medium took over the NPM package I created a fork that I like to keep updated. Google Closure Compiler and Google Closure Library are both excellent tools. Plovr is also.
Please take a look over at: https://github.com/Plovr/Plovr-build/packages/36644 which is the npm package hosted at github packages. I plan to add this later to npm too. It works with the current latest release of closure (v20190929, released 14 days ago as of writing this post)
Related
Julia has a package for binary decision diagrams called CUDD_jll available from JuliaHub. The package is able to install and compile on the Apple M1 architecture. It does appear to install and compile on macOS v13 running Julia v1.82. But the user interface from an older package CUDD does not appear to be compatible with CUDD_jll.
What is needed is a test or examples revealing user commands for initializing cudd, defining logical variables, and the basic operations of AND, OR, NOT.
Does anyone have such information they will share?
_jll packages are generally not meant to be used directly, they're backend dependencies that will be automatically installed when you add a package that uses them.
In this case, CUDD.jl is the package you want to install and work with. That will automatically install CUDD_jll as a dependency and use it. Actually, the current CUDD.jl doesn't yet use CUDD_jll as a backend. It instead does its own download of the CUDD library, from a source that doesn't provide M1-compatible binaries. CUDD_jll is a recent effort to change that. It does provide binaries for the M1 architecture, but is yet to be merged in as a backend.
In the meantime, you can try ] add CUDD#update-to-yggdrasil to directly add the branch that uses CUDA_jll as the backend, and see if that works for you. (Once the PR gets merged, you can remove this branch-specific dependency and ] add CUDD like before.)
The Apple M1 system is not compatible with CUDD. My mistake, sorry.
I have an question regarding updates to the framework of a Laravel application.
Normally I run the composer update command to update all of its dependencies. For the laravel framework the package laravel/framework is used.
But they made some changes in this package which require you to make changes in the core application (not in composer). The core application is the package laravel/laravel.
For example, in this commit they have made a function called confirmPassword() which refers to a file ConfirmPasswordController.php in the package laravel/laravel.
But this file didn't exists on my application because my application is not up-to-date.
My question
How do i keep my core application up to date?
Errors
See a typical example of updating the dependencies but not the application here.
First of all... This is not an easy question and IMO there are MANY possible scenarios... Depending on the code you developed, the packages you're using, the version you want to use, and so on...
Anyway This is what I would do in this situation:
Let's say for example I want to upgrade from version X to version Z where Z is two major / minor releases ahead of X
Step 1
Follow the next steps for one major / minor realease at time. Once I've tried to upgrade an application from Laravel 5.4 to 5.6 and it was completely broken. So I decided to upgrade to 5.5 and test the everything was working and, in case, block at that release. Luckily when I've upgraded from 5.5 to 5.6 (after code fix) I've managed to make everything work as it should.
Step 2
Upgrade the core framework and the plugins, check for errors during the upgrade and ofc, check the official documentation for any kind of compatibility problem
Step 3
Laravel has it's own upgrade guide that should be followed step by step. A good chunk of errors can be solved simply following that guide. There may be some plugins that doesn't provide it but usually the problems are releated to new features... It's hard that a method, class or trait has completely changed from one version to another.
Step 4
This step can be omitted, but from the example you've provided maybe it's better to add it. When there is a new feature that requires a specific class or trait or whatsoever, the simplest way to check if the error is thrown because of a file missing (and that is part of the "boilerplate") or has a different nature, is to create an empty project with that specific version and make a comparison with the "default" files.
For example, if you made no changes to the LoginController, checking if the new version has any kind of updates, may be the solution.
You can do this manually, following the upgrade guide for the version you're upgrading from/to, for example this one.
Alternatively, Laravel Shift is a paid but fairly inexpensive tool that will do it for you automatically. Since it's making changes to your project, you should carefully review everything it's done.
I am from node.js ecosystem.
Golang has released its module system finally and I have read some articles about it:
https://blog.golang.org/using-go-modules
https://github.com/golang/go/wiki/Modules
But, after that, I still didn't find a place like npmjs.com where I can find available go modules.
There is no central repository yet, but note that the module support is still experimental in Go 1.12. It will be enabled by default in Go 1.13 (scheduled for August 2019).
Check out The Go Blog: Go Modules in 2019.
For publicly-available modules, we intend to run a service we call a notary that follows the module index log, downloads new modules, and cryptographically signs statements of the form “module M at version V has file tree hash H.” The notary service will publish all these notarized hashes in a queryable, Certificate Transparency-style tamper-proof log, so that anyone can verify that the notary is behaving correctly. This log will serve as a public, global go.sum file that go get can use to authenticate modules when adding or updating dependencies.
We are aiming to have the go command check notarized hashes for publicly-available modules not already in go.sum starting in Go 1.13.
and
Module Discovery
Finally, we mentioned earlier that the module index will make it easier to build sites like godoc.org. Part of our work in 2019 will be a major revamp of godoc.org to make it more useful for developers who need to discover available modules and then decide whether to rely on a given module or not.
Big Picture
This diagram shows how module source code moves through the design in this post.
There is no central repository for Go modules. As long as you follow the conventions for publishing Go packages (see PackagePublishing), the go tools will be able to fetch your package/module, no matter where you published it.
In order to discover what is already out there in the Go universe, a good starting point is Awesome Go, a curated list of awesome Go packages/modules.
https://search.gocenter.io can be used to search for Go modules, know more about popularity of a module version and even help module authors connect with their consumers. This is GA since end of January 2019 and globally available.
I had the same question. If you start off with the built-in packages (https://golang.org/pkg/), and you follow some non-obvious links, you eventually end up here:
https://pkg.go.dev/
aws documentation indicate that aws-sdk comes by default on all lambda runtimes (obviously) ... also, many post indicates that ImageMagick is also pre-built and ready to use, but this do not appears on the official documentation (or I didn't found it)
I was searching a lot but didn't found a list off all libraries /modules or extra functionalities included by dafault on Lambda so I do not need to build it by myself. do you know where i can find it?
Updated Answer:
ImageMagick (the static binaries) indeed seems to be available on Lambda. I guess image resizing is a very common use case such that they decided to include it on Lambda. They should update that doc page to make it official.
You still have to include the node.js package for interfacing with ImageMagick in your package.json though.
Original Answer:
When in doubt, always use Amazon's official documentation.
Lambda Execution Environment and Available Libraries
I don't think ImageMagick is included by default.
Hi I want to import a 3rd party library to GO playground, I saw an answer for this question: https://stackoverflow.com/a/27813778/6638204 but it said that this can not be done, but the xiam/go-playground library on github states that it can do this. I tried using it but I did not understand what should I exactly do. I successfully installed the library and used it to run programs that do not need third party libraries. but I did not get how can I import a third party library. ps: I have docker installed in my machine
The answer is still the same: you can't do that on the "official" Go Playground (at https://play.golang.org/).
If you or someone else runs a custom, modified version of the Go Playground: then the answer is you can do there whatever is allowed, which may include the usage of external libraries which the custom engine may go get prior to compilation and execution.
Also see related question: Which packages may be imported in the go playground?
You might be able to do it since May 14th, 2019
See this tweet (from Brad Fitzpatrick)!
The #golang playground now supports third-party imports, pulling them in via https://proxy.golang.org/
Example: https://play.golang.org/p/eqEo7mqdS9l 🎉
Multi-file support & few other things up next.
Report bugs at golang/go issue 31944, or here on the tweeters.
But that means you have published your package deliverable in such a way it is reference by the Go proxy.