Wondering how I can dynamically purge and replace a module loaded into Deno via import. In Node there's a global cache that I can just delete the value and reimport. All its dependencies continue operating with the updated value. I've found a few ways ie. deleting the reference and letting it be garbage collected but that's not a dependable way for my application.
Related
The following message appears everytime I attempt to use 'Gadfly', 'Bio', or several other packages (I'm using 'Bio' in the example):
julia> using Bio
INFO: Recompiling stale cache file C:\Users\CaitlinG\emacs251\.julia\lib\v0.5\Di
stributions.ji for module Distributions.
INFO: Recompiling stale cache file C:\Users\CaitlinG\emacs251\.julia\lib\v0.5\Bi
o.ji for module Bio.
Julia 0.5.1 (all packages updated)
Windows 10 (fully updated)
Emacs 25.1
This is inconvenient since I can only assume it is not a "typical" component of importing a package. Can the issue be resolved by deleting the .julia directory?
Thanks.
Moving my comment to an answer since that appears to have resolved the question:
Julia caches its precompiled output within the .julia/lib folder. If any of the files there are older than the original source, it'll recompile them. It seems like Julia was having trouble overwriting the cache for a few specific packages here, so it was persistently recompiling them. By deleting the lib folder, you clear out these caches. Julia will recompile all packages, but it should now write them with the correct permissions that will allow them to be overwritten in the future.
Deleting the entire .julia folder is a much more drastic step that risks losing edits you've made to packages, and you'd need to re-install all the packages you've added.
The messages about recompiling a stale cache file are not warnings, but rather for your information. It means that something changed on your system and the current cache file is no longer considered valid, so instead of providing you a potentially old cachefile, Julia automatically cleans up and recompiles the cache.
I use BerkeleyDb in a project.
I have some environments composed by several file. Sometimes, I need to remove some of these files.
When I remove file with the filesystem, opening the environment raise an error No such file or directory.
Do exists a way to safely removing a file in BerkeleyDb environment ?
To remove a database, you need to be absolutely certain that no references to the database exist in the environment. The most foolproof way to do this is as follows:
Use db->remove() to remove the database from inside your application.
Use dbenv->txn_checkpoint() to flush all changes, checkpoint the log, and then flush the log.
Use dbenv->txn_checkpoint() with the DB_FORCE flag to push one more checkpoint through, ensuring that when the environment is recovered that it doesn't attempt to recover databases that predated the last checkpoint.
Step 3 sounds insane, I know. And maybe it isn't needed any more. But it certainly was needed in the not-too-distant past. Certainly steps 1 and 2 are needed. You'll need to experiment to see if step 3 is necessary for your application.
I'm looking to remove the dependency on the filesystem for my symfony2 cache directory (app/cache/*) and I don't see a clear path to doing that by modifying services or anything of that nature.
Ultimately, I'm attempting to use Symfony on a filesystem that cannot be altered. In the past I've been able to re-map twig templates and intl files to the database, and in theory this should be possible with the cache (and it already is with the logs).
Is there a way I can make the framework use another service like Redis, a database, or even just keep it in RAM for the life of the script?
I've attempted to run a cache:warmup command also, however, writing to the filesystem still happens even with the cache pre-generated.
The parameter used by everything is defined in the framework as kernel.cache_dir
I am using less to manage a website and since I am the styling curator, these files remain hidden in the repository from the rest of the PCs since no one else needs to edit or modify them (as a security measure, since some proactive persons have edited the css files which gives me some headaches when I compile less without their changes ), since only I should edit and compile them.
But now I'll be needing to share and sync the less and css files with one other person in the newtork, and either my changes or his changes will have to be compiled and synced up: if I update a file, I need SVN to notify him that his version is old and needs to sync up, and viceversa if he's the one who makes changes.
So, since css files are compiled from less files and some of them have dependencies between them, I only need to share them with one coworkers via SVN, and since he is starting with less variables and such, I want to have the option to keep and review logs and preform reverts to previous versions, which effectively means to maintain less files invisible to everyone else in SVN, but one other PC.
Is it possible? If it is, how would that go?
SVN 1.8
You can't have IP-based ACLs (easy), you can get only username-based ACLs
This ACLs must be implemented on server-side (and path-based access control must be enabled prior to defining rules)
With Path-Based Authorization you can have enable|disable rules for individual files
After months using Drupal for my websites I noticed module uninstall tab in the modules list.
I've always uninstalled my modules by deleting their folders from filesystem (after disabling them). I was wondering if this is the wrong way to remove them.
Thanks
When you uninstall the module, rather then just disabling and removing, you let the module clean up after itself, including:
Delete tables it created
Delete system variables it used.
So uninstalling is a good clean, for the health of your database. Things will work fine not doing it, but why keep unused tables in your database?
Note:
It's up to the module creator to create the code needed to do the clean up, so not all modules do this very well.
I've always uninstalled my modules by deleting their folders from filesystem (after disabling them). I was wondering if this is the wrong way to remove them.
The files used from a module is not the only thing a module leaves on a Drupal site; there are database tables, Drupal variables, cached values that still need to be removed, when uninstalling a module. It's also possible that a module adds rows into a database table created from a different module.
Deleting the module files, you are not removing any reference to the module contained in the table system. This means that if you are copying back the same module after you deleted it, and you did delete its tables, the module is not going to re-create the database tables it needs.
I would definitively say it is the wrong way to uninstall a module.
Uninstalling is sometimes needed, as hook_install() won't fire if a module is just disabled. So if for example a module has some corrupted data, disabling and re enabling won't remove that.
You will probably be ok in your approach. However one thing to be weary of is doing the following.
Disable
Remove folder
At a later date put module back again (not the same version)
Uninstalling.
The reason for this is hook_install() and hook_uninstall() should be mirror images of each other. Update hooks are used to keep a module schema and settings up to date with what is provided in hook_install(), if you were to use an updated module to uninstall (without updating) it will be trying to uninstall a different set up to what is expected. The risk is slim that something would go badly wrong, but it is worth being careful.
The uninstall tab will remove anything in your database related to the module. This operation requires the module to still be present in your modules directory.
Simply deleting the files isn't 'wrong', but it will leave unneeded cruft in your database. The uninstall tab will not remove the module files for you, you need to do that yourself as you have been doing.
Drush makes the module uninstall process much more pleasant, with something like:
drush pm-disable [module] // or its shorthand drush dis [module]
drush pm-uninstall [module]
In fact, Drush makes just about everything more pleasant (downloading/installing modules, dealing with install profiles, creating DB backups, and my personal favorite, updating your entire code base). If you're not already using it, I highly recommend giving it a try.
You can check this link - modules may have some additional uninstall instructions for them, but it looks like majority of them don't - that's why you didn't have any issues :)