PHPUnit + Kohana: Undefined index: HTTP_HOST - kohana

Trying to run PHPUnit on my Kohana 2.3.4 install:
phpunit --colors --bootstrap=index.php ../../modules/phpunit/libraries/Tests.php
Getting an error at one of my modules:
<p><tt>modules/core/helpers/MY_url.php <strong>[118]:</strong></tt></p>
<p><code class="block">Undefined index: HTTP_HOST</code></p>
I realize this is happening since I'm going via command line so HTTP_HOST won't be set. Is there any way around this without rewriting HTTP_HOST in that module? I know I could rewrite it to be exec(hostname), but am trying to avoid rewriting every instance of HTTP_HOST in my code.
Any workaround you can think of?

Quick and dirty way to fix it would be to set the value in the bootstrap if you're in cli mode.
The "better" way would be to set it in the test's setUp method

Is this $_SERVER['HTTP_HOST']?
If so, have a look at adding an xml config file and setting it in there:
https://phpunit.de/manual/current/en/appendixes.configuration.html

We actually decided to use a different bootstrap, load in variables there, then require the Kohana index file.
Works like a charm. Thanks, Matt, for getting me started down that path.

Related

What's the normal procedure for finding the name of the necessary ESLint package based on the config name given in the error message?

I was just struggling with the error below in my IDE for a frustratingly-long time:
ESLint: Error: Failed to load config "#vue/typescript" to extend from.
After a lot of Googling and running commands I found online, I eventually found that what (seemed to) fix the problem was running this:
yarn add -D #vue/eslint-config-typescript
My question is: How was I supposed to figure that out? Is there some website or service or something where I could have searched for #vue/typescript and found out that the package I needed to install was #vue/eslint-config-typescript?
Ok, I figured it out: in the ESLint docs, it says that basically that the part after the forward-slash should be understood to always start with eslint-plugin:
They show the following examples:
"plugins": [
"jquery", // means eslint-plugin-jquery
"#jquery/jquery", // means #jquery/eslint-plugin-jquery
"#foobar" // means #foobar/eslint-plugin
]

cookie cutter: what's the easiest way to specify variables for the prompts

Is there anything that offers replay-type functionality, by pointing at a predefined prompt-answer file?
What works and what I'd like to achieve.
Let's take an example, using a cookiecutter to prep a Python package for pypi
cookiecutter https://github.com/audreyr/cookiecutter-pypackage.git
You've downloaded /Users/jluc/.cookiecutters/cookiecutter-pypackage before. Is it okay to delete and re-download it? [yes]:
full_name [Audrey Roy Greenfeld]: Spartacus πŸ‘ˆ constant for me/my organization
email [audreyr#example.com]: spartacus#example.com πŸ‘ˆ constant for me/my organization
...
project_name [Python Boilerplate]: GladiatorRevolt πŸ‘ˆ this will vary.
project_slug [q]: gladiator-revolt πŸ‘ˆ this too
...
OK, done.
Now, I can easily redo this, for this project, via:
cookiecutter https://github.com/audreyr/cookiecutter-pypackage.git --replay
This is great!
What I want:
Say I create another project, UnleashHell.
I want to prep a file somehow that has my developer-info and project level info for Unleash. And I want to be able to run it multiple times against this template, without having to deal with prompts. This particular pypi template gets regular updates, for example python 2.7 support has been dropped.
The problem:
A --replay will just inject the last run for this cookiecutter template. If it was run against a different pypi project, too bad.
I'm good with my developer-level info, but I need to vary all the project level info.
I tried copying the replay file via:
cp ~/.cookiecutter_replay/cookiecutter-pypackage.json unleash.json
Edit unleash.json to reflect necessary changes.
Then specify it via --config-file flag
cookiecutter https://github.com/audreyr/cookiecutter-pypackage.git --config-file unleash.json
I get an ugly error, it wants YAML, apparently.
cookiecutter.exceptions.InvalidConfiguration: Unable to parse YAML file .../000.packaging/unleash.json. Error: None of the known patterns match for {
"cookiecutter": {
"full_name": "Spartacus",
No problem, json2yaml to the rescue.
That doesn't work either.
cookiecutter.exceptions.InvalidConfiguration: Unable to parse YAML file ./cookie.yaml. Error: Unable to determine type for "
full_name: "Spartacus"
I also tried a < stdin redirect:
cookiecutter.prompts.txt:
yes
Spartacus
...
It doesn't seem to use it and just aborts.
cookiecutter https://github.com/audreyr/cookiecutter-pypackage.git < ./cookiecutter.prompts.txt
You've downloaded ~/.cookiecutters/cookiecutter-pypackage before. Is it okay to delete and re-download it? [yes]
: full_name [Audrey Roy Greenfeld]
: email [audreyr#example.com]
: Aborted
I suspect I am missing something obvious, not sure what. To start with, what is the intent and format expected for the --config file?
Debrief - how I got it working from accepted answer.
Took accepted answer, but adjusted it for ~/.cookiecutterrc usage. It works but the format is not super clear. Especially not on the rc which has to be yaml, though that's not always/often the case with rc files.
This ended up working:
file ~/.cookiecutterrc:
without nesting under default_context... tons of unhelpful yaml parse errors (on a valid yaml doc).
default_context:
#... cut out for privacy
add_pyup_badge: y
command_line_interface: "Click"
create_author_file: "y"
open_source_license: "MIT license"
# the names to use here are:
# full_name:
# email:
# github_username:
# project_name:
# project_slug:
# project_short_description:
# pypi_username:
# version:
# use_pytest:
# use_pypi_deployment_with_travis:
# add_pyup_badge:
# command_line_interface:
# create_author_file:
# open_source_license:
I still could not get a combination of ~/.cookiecutterrc and a project-specific config.yaml to work. Too bad that expected configuration format is so lightly documented.
So I will use the .rc but enter the project name, slug and description each time. Oh well, good enough for now.
You are near.
Try this cookiecutter https://github.com/audreyr/cookiecutter-pypackage.git --no-input --config-file config.yaml
The --no-input parameter will suppress the terminal user input, it is optional of course.
The config.yaml file could look like this:
default_context:
full_name: "Audrey Roy"
email: "audreyr#example.com"
github_username: "audreyr"
cookiecutters_dir: "/home/audreyr/my-custom-cookiecutters-dir/"
replay_dir: "/home/audreyr/my-custom-replay-dir/"
abbreviations:
pp: https://github.com/audreyr/cookiecutter-pypackage.git
gh: https://github.com/{0}.git
bb: https://bitbucket.org/{0}
Reference to this example file: https://cookiecutter.readthedocs.io/en/1.7.0/advanced/user_config.html
You probably just need the default_context block since that is where the user input goes.

Win10: ASDF can't load system (ASDF_OUTPUT_TRANSLATION error)

Update 2
I think #farΓ© is right, it's an output translation problem.
So I declared the evironment variable ASDF_OUTPUT_TRANSLATIONS and set it to E:/. Now (asdf:require-system "my-system") yields a different error: Uneven number of components in source to destination mapping: "E:/" which led me to this SO-topic.
Unfortunately, his solution doesn't work for me. So I tried the other answer and set ASDF_OUTPUT_TRANSLATIONS to (:output-translations (t "E:/")). Now I get yet another error:
Invalid source registry (:OUTPUT-TRANSLATIONS (T "E:/")).
One and only one of
:INHERIT-CONFIGURATION or
:IGNORE-INHERITED-CONFIGURATION
is required.
(will be skipped)
Original Posting
I have a simple system definition but can't get ASDF to load it.
(asdf-version 3.1.5, sbcl 1.3.12 (upgraded to 1.3.18 AMD64), slime 2.19, Windows 10)
What I have tried so far
Following the ASDF manual: "4.1 Configuring ASDF to find your systems"
There it says:
For Windows users, and starting with ASDF 3.1.5, start from your
%LOCALAPPDATA%, which is usually ~/AppData/Local/ (but you can ask in
a CMD.EXE terminal echo %LOCALAPPDATA% to make sure) and underneath
create a subpath config/common-lisp/source-registry.conf.d/
That's exactly what I did:
Echoing %LOCALAPPDATA% which evaluates to C:\Users\my-username\AppData\Local
Underneath I created the subfolders config\common-lisp\source-registry.conf.d\ (In total: C:\Users\my-username\AppData\Local\config\common-lisp\source-registry.conf.d\
The manual continues:
there create a file with any name of your choice but with the type conf, for instance 50-luser-lisp.conf; in this file, add the following line to tell ASDF to recursively scan all the subdirectories under /home/luser/lisp/ for .asd files: (:tree "/home/luser/lisp/")
That’s enough. You may replace /home/luser/lisp/ by wherever you want to install your source code.
In the source-registry.conf.d folder I created the file my.conf and put in it (:tree "C:/Users/my-username/my-systems/"). This folder contains a my-system.asd.
And here comes the weird part:
If I now type (asdf:require-system "my-system") in the REPL I get the following error:
Can't create directory C:\Users\my-username\AppData\Local\common-lisp\sbcl-1.3.12-win-x86\C\Users\my-username\my-systems\C:\
So the problem is not that ASDF doesn't find the file, it does -- but (whatever the reason) it tries to create a really weird subfolder hierarchy which ultimately fails because at the end it tries to create the folder C: but Windows doesn't allow foldernames containing a colon.
Another approach: (push path asdf:*central-registry*)
If I try
> (push #P"C:/Users/my-username/my-systems/" asdf:*central-registry*)
(#P"C:/Users/my-username/my-systems/"
#P"C:/Users/my-username/AppData/Roaming/quicklisp/quicklisp/")
> (asdf:require-system "my-system")
I get the exact same error.
I don't know what to do.
Update
Because of the nature of the weird path ASDF was trying to create I thought maybe I could bypass the problem by specifying a relative path instead of an absolute one.
So I tried
  (:tree "\\Users\\my-username\\my-systems")
in my conf file. Still the same error.
Ahem. It looks like an output-translations problem.
I don't have a Windows machine right now, but this all used to work last time I tried.
Can you setup some ad hoc output-translations for now that will make it work?

Can any one explain the usage of Shell::Source perl module or Shell::GetEnv module

I m a beginner in perl. I want to know how to use this module. I read somewhere about this module but not getting its usage.
Actually I've a file which contains some environment paths which needs to be set while running some test(say file name is SET_ENV_TOOL1.csh or SET_ENV_TOOL1.sh) with particular tools.(say TOOL1, TOOL2 etc)
SET_ENV_TOOL1.sh file conatins:
setenv UVM_HOME /u/tools/digital/uvm/uvm-1.1a
setenv VIPP_HOME /u/tools/digital/vipcat_11.30-s012-22-05-2012
setenv VIP_AXI_PATH ${VIPP_HOME}/vips/amba_axi/vr_axi/sv/ #etc.(almost 10-15 paths are need to be set like this)
Everytime while running test, tool might get changed and so environment paths also needs to set to run that tool.
I have to make a perl script which sets these paths before running test. That test will run a command and that command will use these environment paths.
Any help would be greatly appreciated. Thanks !!
Reading and changing environment variables is built-in to Perl, you do not need the modules you mentioned.
$ENV{UVM_HOME} = '/u/tools/digital/uvm/uvm-1.1a';
$ENV{VIPP_HOME} = '/u/tools/digital/vipcat_11.30-s012-22-05-2012';
$ENV{VIP_AXI_PATH} = "$ENV{VIPP_HOME}/vips/amba_axi/vr_axi/sv/";

PHP deprecated warnings on Drupal pages despite turning them off in php.ini

I have PHP deprecated errors flooding log files and Drupal status pages like this:
: Function ereg() is deprecated in mysite/includes/file.inc on line 893.
I should be able to turn off E_DEPRECATED errors in my php.ini, but it is having no effect despite being set to:
error_reporting = E_ALL & ~E_DEPRECATED
phpInfo() reports error_reporting master value and local value both 22527.
I did a
grep -R error_reporting
in my document root in the hopes of finding any hard coded error levels and no luck:
./includes/common.inc: // If the # error suppression operator was used, error_reporting will have
./includes/common.inc: if (error_reporting() == 0) {
./modules/system/system.module: 'page arguments' => array('system_error_reporting_settings'),
./modules/system/system.admin.inc:function system_error_reporting_settings() {
./modules/system/system.install: $err = error_reporting(0);
./modules/system/system.install: error_reporting($err);
Nothing that I can see that is supect except possibly the first line in system.install but if I'm right that should turn all errors OFF.
I'm not setting error_reporting in .htaccess, but doing that does not have any effect either.
I'm hoping that there is a solution that doesn't involve hard coding error levels in common.inc (which DOES work, I've tried - but obviously undesirable).
I know the deprecated errors are a result of upgrading to PHP 5.3, but downgrading PHP is not option (new sites are going live now on the same server that have been tested on 5.3, and the sites where these errors occur have 2 months to live). I also cannot upgrade to Drupal versions that play nicely with 5.3 as unfortunately the previous owner haxxed the core modules without documenting his changes.
Version stuff:
PHP 5.3.2-1, Ubuntu 10.04, Drupal 6.13 on one site, 6.5 (!!1!) on the other, Apache 2.2
Did you try editing index.php to be
error_reporting(E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED);
require_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
I have used this on my php.ini file and could hide those deprecated errors. Hope it helps you! =)
error_reporting = E_ALL & ~E_DEPRECATED & -E_WARNING
I don't know about disabling error reporting but you can replace all ereg functions by preg_match..!

Resources