I'm using Homebrew to manage both of them and they are up to date.
~ $ brew --version
Homebrew 1.8.4
Homebrew/homebrew-core (git revision a166; last commit 2018-12-08)
~ $ php --version
PHP 7.3.0 (cli) (built: Dec 7 2018 11:00:11) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.0-dev, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.0, Copyright (c) 1999-2018, by Zend Technologies
~ $ php-cs-fixer --version
PHP needs to be a minimum version of PHP 5.6.0 and maximum version of PHP 7.2.*.
~ $ brew upgrade php-cs-fixer
Error: php-cs-fixer 2.13.1 already installed
This happens when I try to use php-cs-fixer
~ $ php-cs-fixer fix file.php
PHP needs to be a minimum version of PHP 5.6.0 and maximum version of PHP 7.2.*.
So, I downloaded php#7.2 and php-cs-fixer.phar to test and it works that way.
~ $ /usr/local/Cellar/php#7.2/7.2.13/bin/php /Users/aaronk/php-cs-fixer.phar fix file.php
Loaded config default from "/Users/aaronk/.php_cs".
Using cache file ".php_cs.cache".
Paths from configuration file have been overridden by paths provided as command arguments.
1) file.php
Fixed all files in 0.014 seconds, 10.000 MB memory used
~ $
So my question is, how do I get homebrew's php-cs-fixer to work?
Is homebrew doing something wrong here?
(p.s. is there a tag for php7.3)
As said by godbout, PHP-CS-Fixer does not yes support PHP 7.3. You can track the GitHub issue [Meta] PHP 7.3 support #3697, to follow the evolution of the situation. According to this issue, the following changes in PHP 7.3 still need to be adressed:
Flexible Heredoc and Nowdoc Syntaxes
list() Reference Assignment
instanceof now allows literals as the first operand, in which case the result is always false.
Allow a trailing comma in function calls
hrtime function has been added
is_countable function shall be handled as all other native functions
The current version "friendsofphp/php-cs-fixer": "^2.14" now supports php 7.3. You could upgrade it and it should work fine.
Nothing to do with Homebrew. It's php-cs-fixer itself that doesn't support PHP7.3. You would get the same issue through composer, with unmet dependencies.
The mentioned issues isn't related to the PH PC Fixer code, rather to it's features. It's clear missuse of composer.json, where are dependencies, not features.
PHP CS Fixer works fine on PHP 7.3, see this PR.
This command allows you to install it on PHP 7.3:
composer update --ignore-platform-reqs
Let me know if you came across any troubles.
To clarify - PHP CS Fixer being run under PHP 7.3 may fix code written using syntax up to PHP 7.2. But if one would run tool on code written in 7.3, eg is_null($foo, ) (trailing comma), then behavior of fixer is not stable (producing null === $foo, - still, with trailing comma), which is an issue.
Related
I want to have charts in the admin panel,
I installed the django-admin-charts package,
Which said add these to settings.py
INSTALLED_APPS = (
'admin_tools_stats', # this must be BEFORE 'admin_tools' and 'django.contrib.admin'
'django_nvd3',
)
But after adding it, it gives this error:
ImportError: cannot import name 'smart_text' from 'django.utils.encoding' (E: \ test1 \ venv1 \ lib \ site-packages \ django \ utils \ encoding.py)
I searched but didn't find much about smart_text!
Maybe it has a problem with Django version 4 or Python version 3.10.3?
This is because django-admin-charts needs smart_text and in django 4 smart_text is removed from the utils/encoding so the better way to resolve this issue is to add this code in your settings.py file
import django
from django.utils.encoding import smart_str
django.utils.encoding.smart_text = smart_str
I digged around a little and the problem seems to be the Django version. smart_text function is not present in the django/utils/encoding.py file. I downgraded from 4.0.2 to 3.2.13, set PyMemcacheCache as the default cache in settings.py and it works. In my case downgrading is not acceptable as Django. 3.2.13 doesn't support redis cache, but it might help you. Let's hope that django-admin-charts will add suport for Django 4.0.
I got this error when we switched from Django 2.2 to Django 4 version.
There were a library which was not upgraded. I found this out by searching the usage of "django.utils.encoding import smart_text" statement under the project scope.
The issue resolved once I upgraded the django-wkhtmltopdf library from 3.3.0 to 3.4.0.
Check for any dependent libraries and upgrade as above to fix the issue.
I installed Phalcon PHP as described in https://docs.phalcon.io/3.4/en/webserver-wamp.
In this case the URL reads 3.4 because it applies alike for versions 4 and 5.
The WAMP server version is 3.2.6 configured with PHP 8.0.13
Everything was fine so far, so I continued installing the developer tools using composer as described in https://docs.phalcon.io/5.0/en/devtools.
Composer was installed globally and so were the developer tools, but when I type "phalcon" in the command window, the following error is shown:
C:\>phalcon
Fatal error: Uncaught Error: Class "Phalcon\Script" not found in C:\Users\Joachim\AppData\Roaming\Composer\vendor\phalcon\devtools\phalcon.php:38
Stack trace:
#0 {main}
thrown in C:\Users\Joachim\AppData\Roaming\Composer\vendor\phalcon\devtools\phalcon.php on line 38
C:\>
PSR and Phalcon extensions were successfully installed and I can see them in the WAMP Localhost page.
The Path environment variable contains the path to phalcon, composer, wamp, etc, nothing is missing as far as I can see.
Have anyone dealt with this error?
What could be the problem?
I'm a bit late answering this, but in case anyone else stumbles across it via Google the problem is that some namespaces have been altered between Phalcon4 and Phalcon5. I believe Phalcon\Config is one of those classes.
Until the devtools have been updated for Phalcon5, you'll either need to build the scaffolding manually, or copy an old Phalcon 3 or 4 project and update the namespaces.
The perils of using alpha/beta releases, unfortunately.
you didn't mention which phalcon version but since you are using php 8 the only version supporting php 8 is phalcon 5
your issue is most likely in your php.ini for the cli since wamp uses different files for apache and cli.
to fix the issue first remove the devtools package you installed globally then edit the cli php.ini in [wampDir]\bin\php\php8.0.13\php.ini and include psr and phalcon and install the devtools again using composer
you can also download the phar file here and test it in the cli
php phalcon.phar
I have a docker image with texlive installed (via apt not tlmgr). I have a pgfplot in my project which needs a newer pgfplot version. I'm searching for ways to update my pgplots because I can't update it with tlmgr because of base install via apt.
Initial error message if I try to compile with texlive 2014:
! Package pgfkeys Error: Choice '1.16' unknown in choice key '/pgfplots/compat/
anchors'. I am going to ignore this key.
See the pgfkeys package documentation for explanation.
Type H <return> for immediate help.
...
l.7 \pgfplotsset{compat=1.16}
?
! Emergency stop.
...
l.7 \pgfplotsset{compat=1.16}
I downloaded the pgfplots.tds and did the following steps like the manual said:
docker cp pgfplots.tds docker_container_name:/root/texmf/pgfplots
export TEXINPUTS=/root/texmf/pgfplots/tex//:
export TEXDOCS=/root/texmf/pgfplots/doc//:
export LUAINPUTS=/root/texmf/pgfplots//:
texhash
Of course the export and texhash were done inside the container and not on the host system.
After this, the error message is gone, but I have a new issue:
package pgfplots notification 'compat/show suggested version=true': you might b
enefit from \pgfplotsset{compat=1.18} (current compat level: 1.16).
! Illegal parameter number in definition of \pgfmaththisrow#.
<to be read again>
I searched online and got the response that this is because of a broken pgfplots installation. In many articles the fix was just to install the texlive new. But I can't do that.
The issue should also not be in the tex code itself. If I install texlive on my host system, which is the most recent Ubuntu distro, the tex compiles just fine.
Can somebody help me in fixing this or lead me to a better way of upgrading pgfplots?
Resolution:
The pgfplots package 1.18.1 and also 1.16 were to recent. It had conflicts with the pgf package. I tried to go further back and landed on \pgfplotsset{1.14} and version 1.14 of pgfplots.tds.
This works fine now. I was probably pretty lucky that my plot looks and functions the same with this version as in 1.18.
This approach probably won't work for you if your more bound to version 1.18.
I need to do the subject because I'm developing with the team on PHP 5.5, but my current Fedora version contains PHP 5.6.
I've found a Remi's repo contining PHP 5.5 for FC-21, installed it as described in "Install Howto" section. But I cannot run the Apache to use with PHP v.5.5. Please suggest what I can do to have desired?
you can try to downgrade your current installation using the packet manager by issuing the command yum downgrade php55 see downgrade or rollback updates, where you can also specify a specific version. Before that I suggest you to first verify your installation history about php if its is present.
Another way is to install the specific version you want see the answer here and then add a rule to block further updates in /etc/yum.conf see here for the blocking rule
I am generating a tags file for emacs for my Ruby on Rails project with the following command:
ctags -f TAGS --extra=-f --languages=-javascript --exclude=.git --exclude=log -e -R . $(rvm gemdir)/gems/
When I try to find tags (Using M-.) some tags are working fine, but with lots of other tags I get errors like:
tag-find-file-of-tag-noselect: File /Users/simao/Documents/sp/ofe/° ¡ not found
etags-goto-tag-location: Rerun etags: `^class Tools::FilteringSteps' not found in /Users/simao/Documents/sp/ofe/lib/geo_db.rb
How are you generating tags for your RoR projects with emacs? Did you ever see this problem before?
This is the output of ctags --version
Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert
Compiled: Mar 9 2012, 15:47:35
Addresses: <dhiebert#users.sourceforge.net>, http://ctags.sourceforge.net
Optional compiled features: +wildcards, +regex
My emacs version:
GNU Emacs 24.0.95.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2012-04-02
Yeah, yeah, yeah. ;-)
Why would you care about not using ctags in the first place? Ctags is a great project and it does support many (like 50) languages. But Ruby support is very weak, the parser is not in good condition and it has not been changed 4 years now.
Ctags doesn't deal with: module A::B
Ctags doesn't tag (at least some of) the operator methods like ==
Ctags doesn't support qualified tags, -type=+
Ctags doesn't output tags for constants or attributes.
Unfortunately all the others (I found 2) Ruby ctags generators are either outdated (no Ruby 1.9+ support) or very slow. But there is a solution! It is called ripper-tags. https://github.com/tmm1/ripper-tags
gem install ripper-tags
cd your_project/
ripper-tags -R # for vim
ripper-tags -R -f TAGS # for emacs
This project leverages built-in Ruby parser API called Ripper. It is fast and it works as expected. It is almost as fast as ctags, but giving the most accurate results. Warning: It does NOT support Ruby 1.8.
If you like ripper-tags and you want to have all tags generated automatically upon gem installation, you can check out my gem-ripper-tags which does that. Unfortunately it does not support Emacs at the moment (patch accepted - quite easy to do). More info at: https://github.com/lzap/gem-ripper-tags
This seems like it might be relevant:
http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-11/msg00079.html
http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-03/msg00550.html
Particularly note the comment in the second link, suggesting this bug has existed since Emacs 22.
Assuming you're not running Emacs 24, it sounds like you should apply that patch to etags.el (and byte-recompile).
(If you are using a version of Emacs 24 which contained this bug, you should obviously update to the latest pretest release.)
I use rtags. For me, it worked better with Ruby than ctags.
If you are using Git, I recommend you follow this setup from Effortless CTags to auto build your tag files when you perform git operations:
http://tbaggery.com/2011/08/08/effortless-ctags-with-git.html
Even if you are not using Git, you may be able to try his command for building the CTags:
ctags --tag-relative -Rf.git/tags.$$ --exclude=.git --languages=-javascript,sql
Also, I recommend you setup an alias for bundle install to specify a path so your gems get bundled into subdirectory of your project, such as:
alias bi='bundle install --path vendor'
(Note: be sure to .gitignore that directory). This will allow you to also jump directly into the source of each of your gems, and prevent your tag file from being bloated with all gems in your system.