I am trying to launch R from sublimetext2 via sublimeREPL. Until I installed the new OS everything worked, now not anymore since the directory is not found apparently. I tried all variations but I cannot make it work. Here are my SublimeREPL User settings:
{
"default_extend_env": {"PATH": "{PATH}:/Applications/R"},
"default_extend_env":{"COLUMNS": "500"},
"wrap_width": 200,
"word_wrap": false,
"pep8_ignore":["E251","E501","W191","E303"]
}
Any idea what this might be about?
I solved it: After installing "el capitan", the permissions to access for sublime seemed to be deleted. I reeinstalled R and all worked.
Related
I moved from using Docksal to Acquia ADS (Lando) which automatically upgraded my Drush from 8 to 9. My local site works fine but I can't get Drush 9 to "see" my Drupal 8 site. The aliases seem to have been created and added to the drush/sites folder and running drush site:alias does show them. However running drush status shows my Drupal root as /app. My Drupal root is /app/docroot. My alias files do have this as their root (for local). I'm not sure why Drush doesn't use the alias files it knows about. I've tried:
drush #self(or #local) list and I get some commands and this statement at the end:
[NOTE] Drupal root not found. Pass --root or a #siteAlias in order to see Drupal-specific commands.
Doing drush #local(or #self) cr returns:
In BootstrapHook.php line 32: Bootstrap failed. Run your command
with -vvv for more information.
With -vvv:
Exception trace: at
/app/vendor/drush/drush/src/Boot/BootstrapHook.php:32
Drush\Boot\BootstrapHook->initialize() at
/app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:34
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->callInitializeHook()
at
/app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:27
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->initialize()
at
/app/vendor/consolidation/annotated-command/src/CommandProcessor.php:145
Consolidation\AnnotatedCommand\CommandProcessor->initializeHook() at
/app/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:289
Consolidation\AnnotatedCommand\AnnotatedCommand->initialize() at
/app/vendor/symfony/console/Command/Command.php:221
Symfony\Component\Console\Command\Command->run() at
/app/vendor/symfony/console/Application.php:1005
Symfony\Component\Console\Application->doRunCommand() at
/app/vendor/symfony/console/Application.php:255
Symfony\Component\Console\Application->doRun() at
/app/vendor/symfony/console/Application.php:148
Symfony\Component\Console\Application->run() at
/app/vendor/drush/drush/src/Runtime/Runtime.php:118
Drush\Runtime\Runtime->doRun() at
/app/vendor/drush/drush/src/Runtime/Runtime.php:49
Drush\Runtime\Runtime->run() at /app/vendor/drush/drush/drush.php:72
require() at /app/vendor/drush/drush/drush:4
drush status:
PHP binary : /usr/local/bin/php
PHP config :
PHP OS : Linux
Drush script : /app/vendor/drush/drush/drush
Drush version : 10.2.2 <-- Had 9.0.0 but currently trying 10, same issue
Drush temp : /tmp
Drush configs : /root/.drush/drush.yml
/app/vendor/drush/drush/drush.yml
/app/drush/drush.yml
Drupal root : /app
self.site.yml:
local:
root: /app/docroot
uri: example.lndo.site
Can someone please point me in the right direction?
Figured it out. No matter how many ways you try to tell Drush where to look to find your Drupal root, none of it will matter until you edit your composer.json file. Turns out the key to making Drush 9+ work is changing the name in composer.
My composer.json file name went from:
"name": "drupal/drupal",
to:
"name": "drupal-composer/drupal-project",
I don't think this feature was documented anywhere so I'm posting it here in response to my own question in case this helps anyone else.
I realize that this is an older question, however with Drupal 8 recently reaching end of life, and the high probability of many people (like myself) scrambling to upgrade now that clients have realized the risks of using EOL software, I want to take a moment to explain why #r00t's answer works.
r00t is correct that changing the "name" value in composer.json fixed the issue, however, the value that is set is not limited to drupal-composer/drupal-project. This seems to stem from the package webflo/drupal-finder and the way it works.
webflow/drupal-finder is a requirement of drush/drush, so it's going to be included even if you haven't added it manually. It's also a requirement of a couple of others that you may or may not have installed, like palantirnet/drupal-rector (which as a side note, is really helpful for this upgrade).
Within the code for drupal-finder is a method that looks for the install path of Drupal core based on a few items within your composer.json file.
Here is the code from DrupalFinder::isValidRoot()
foreach ($json['extra']['installer-paths'] as $install_path => $items) {
if (in_array('type:drupal-core', $items) ||
in_array('drupal/core', $items) ||
in_array('drupal/drupal', $items)) {
$this->composerRoot = $path;
// #todo: Remove this magic and detect the major version instead.
if (($install_path == 'core') || ((isset($json['name'])) && ($json['name'] == 'drupal/drupal'))) {
$install_path = '';
} elseif (substr($install_path, -5) == '/core') {
$install_path = substr($install_path, 0, -5);
}
....
Which is telling drupal-finder that if the "name" value is drupal/drupal then the install path of the site is at the base of the project, however if it is not drupal/drupal then use a value from extra.installer-paths to find the site install.
I'm still not aware if this is documented anywhere on either webflo/drupal-finder or in drush/drush, but understanding why it was an issue helped me out tremendously.
TL;DR:
If your site's docroot lives next to your vendor folder, change the name in composer.json to anything that isn't drupal/drupal. If your vendor folder lives inside your docroot, drupal/drupal will work for you.
When I try to access several options of the backend of prestashop 1.7.4.3 it gives me this error. I have installed four languages and the main one is Spanish. How can this error be solved?
Error 500 - The "zip" translation loader is not registered.
It seems you have a zip file in your translations folder. Perhaps it was left there when you installed a new locale. Try removing it.
After adding Content module to a page, I just get a round blue icon with white glasses. Clicking on it produces an error in the console:
ReferenceError: $2sxc is not defined 1 ui.html:20:5
<anonymous> http://localhost/DotNetNuke/desktopmodules/tosic_sexycontent/dist/ng/ui.html:20:5
Clicking 'Change Template / Layout' in pencil menu also does nothing. This happened after upgrading from 2sxc 8.12 to 9.02. I checked the file and of course could not see $2sxc defined anywhere. I have installed on other sites and not had this problem, but it is failing on my localhost installation. DNN 9.1.1 I have tried uninstalling 2sxc and deleting all the Tosic... files I can find, then reinstalling, but I get the same results.
Similar to: Having some issues with 2sxc version 9.x: unable to select App/Content layout
Does anyone know how to fix this? Thx.
I fixed this after a little debugging and following the code. The problem happens on localhost implementations. There is a file: DesktopModules\ToSIC_SexyContent\dist\ng\ui.html
that contains the code in a script container:
var
path = window.location.pathname,
isDevMode = window.location.hostname === 'localhost',
apiUrl;
The problem is that it thinks it is in 'DevMode' when it is on localhost and therefore sets:
devPath = 'http://2sxc.dev/desktopmodules/tosic_sexycontent/dist/a4/';
which is certainly not a valid URL on my system, and apparently not on the web either. So the solution is to have it avoid 'DevMode' and everything works as it should. I did this by modifying the 'localhost' to be 'xlocalhost' and it worked like a charm. You could also just set it to false.
So this was a bug in that version, it's fixed now.
I'm currently using the Qt-Installer-Framework to create a setup for my application. Everything works fine for now except one thing:
If I install it to any location but C:\Program Files\MyApp, the installer won't create the registry entry for Programs and Features!
Is there a way to tell the installer to always do this?
Edit:
After trying out vairous different combinations, I do know now where the problem comes from:
If I try to install as current user only (set the AllUsers variable to false), it will always work and create an entry in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID}.
If I install for all users, however, it will try to create a key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID}. This will only work, if the installer has to elevate it's operations during installation (because I chose a directory I need admin rights for).
So, the error is: The installer won't elevate itself to create the "global" registry entry and thus fails to create it. Any ideas on how to fix it?
Here the link which has answer to this question.
Add the following line to your component's package xml file:
#<RequiresAdminRights>true</RequiresAdminRights>#
And use this line in your script file:
#component.addElevatedOperation("Execute", "someCommand");#
instead of
#component.addOperation("Execute", "someCommand");#
There is boolean installer.gainAdminRights() to gain elevated privileges during runtime but you will have to add it to an installer script (in packages meta directory) something alike
function Component()
{
if (!installer.isInstaller())
{
if (allUsers && installer.gainAdminRights())
{
//Set registry global
} else {
//Set registry local
}
}
}
My current project is at https://github.com/jimmack1963/localPackages.git.
I am trying to get this code to work:
console.log("You pressed the button, " + MyName);
where MyName comes from a package called simple, that is JUST LOCAL. Per 6.5, am exporting via
Package.on_use(function (api, where) {
api.add_files(['constant.js'], 'client');
//below added per possible suggestion from Nathan, had no effect.
api.use('constant.js', 'client');
if (api.export)
api.export('MyName');
});
Am trying to factor my code out to local packages. This is not about publishing packages, but about using local ones, which is referred to in many places. My package is simply trying to publish a string, MyName. But the project wants none of it. "MyName is not defined."
I copy the technique in 'Discover Meteor,' but it doesn't work for me, and I try other things. Have had a lot of success in Meteor in general.
This spec seems to be changing. I get the 6.5 export requirement, but easily find contradictory advise about the base project's need to add that project in smart.json (not the one in the package). Most references don't list that as a requirement at all.
I've tried
{
"packages": {
"simple" : {
"path": "packages/simple"
}
}
}
and putting it into git and trying from a different project:
{
"packages": {
"simple" : {
"git": "https://github.com/jimmack1963/localPackages.git"
}
}
}
For the latter, pleasingly, the installer was smart enough to burrow down and extract the package itself, ignoring the project wrapping it in the git project. Nice! So, I have the same problem when I install the package directly from git, still not published to the world.
Ubuntu 13.04
Meteorite version 0.6.11
Meteor Release 0.6.5.1
I had the same issue after migrating to 0.6.5 -
You only get 'exported' variables from packages you explicitly "use"; Packages "use" other packages by calling .use inside Package.on_use, projects "use" packages by adding them to .meteor/packages
Additionally, it seems to be quite picky about exporting variables, and wont currently export ones preceded with this.