I am not seeing mysql as one module when i do php -m. I visited various other questions and checked php.ini but I don't see this line extension=php_mysql.dll
Do i need to add this line? if yes, where it should go. please clarify.
Yes, unless MySQL's module is compiled directly into PHP (in which case it'd be always available), you have to explicitly state you want the external .dll loaded.
As for where it should go, it depends. PHP has usually has at least 2 main .ini files, one for webserver-embedded operations, and one for command line operations. You'll have to add the line to whichever is applicable for your case. It doesn't hurt to add it to both, unless you want a "stripped down" PHP with as few modules loaded as possible.
Related
When two PHP files are on the same namespace, adding a "use" to them for the other one is not necessary, but possible. However, PhpStorm inspection marks the unnecessary uses on PHP files as errors, warns about using them, and does not autocreate them when typing the class name on the file.
The thing is, I like having them on the file even that they are not necessary. That makes me easier to check the file dependencies, and to search-replace the namespaces when I move classes around. I know about the refactoring features of PhpStorm, but they are not always available for me and my co-workers.
So, is there a way of telling PhpStorm to behave with unnecessary uses as it does with regular ones? Not marking them as errors, autocompleting, etc.
Assume I have /foo/X.a and /foo/X.dylib, and LDFLAGS=-L/foo. What will AC_CHECK_LIB do? Is .dylib guaranteed to take precedence over .a? Vice versa? Random?
Assume I have /foo/Y.a and /bar/Y.a, and LDFLAGS=-L/foo:/bar? What will happen then?
Is there some way to manually establish precedence?
This problem is not addressed by autoconf. In the case that you have both /foo/X.a and /foo/X.dylib, the configure script will simply attempt to link with libX and will do whatever your toolchain does. If your linker uses X.a, then the configure script will do its tests using X.a. If your linker uses X.dylib, then the configure script will use that. The way to establish precedence will therefore depend on your toolchain (e.g. perhaps you can add -Bstatic to LDFLAGS).
Is there some way to manually establish precedence?
You are manually establishing precedence of library search by using the -L option.
Also what if I have /foo/Y.a and /bar/Y.a, and LDFLAGS=-L/foo:/bar
What will happen then?
It will look in the directory /foo:/bar before the default library paths. It's not clear from your question if Y.a is actually supposed to be linked to anything.
What will AC_CHECK_LIB do? Is .dylib guaranteed to take precedence over .a? Vice versa? Random?
It won't be random, but will be influenced by other options given to configure (e.g. LDFLAGS, --disable-shared, etc.). All AC_CHECK_LIB does is plop in the name of the selected function into a main function (with appropriate libraries added) and see if it links.
Why is changing lines in configuration file considered an anti-pattern in Chef or Puppet?
It's something like bad habit, as I understood. I assume that this file-editing is done in some idempotent way and with advanced tools (augeas for example).
Why is deploying the whole files, with ERB templates, considered a preferred method?
You can find a lot of examples where dev-ops are suggesting usage of templates instead of file-editing. For example here, here, here, etc.
Actually there is a large part of the DevOps community that sees accepting system/package defaults for config files and only modifying what you need through augeas as the preferred method, Github devops would be one of them(if you happened to catch them at Puppet Conf 2012).
I think having a default pattern of always using templates creates too high of a maintenance load and almost always requires you lock in specific versions for everything across your stack or you risk having an incompatible template against a newer version of that resource.
There's use cases for both options but in general I favor the "own as little as possible" practice vs the "own everything even if you don't have to" practice.
In terms of setting the your system to a known state, deploying whole files is better than editing, because you are sure the file is exactly as intended when you are done.
If you are tinkering around finding potential solutions to a problem and hand edit some configuration file, you don't have to worry about the hand edit you made staying around as an uncontrolled part of your environment. The next time you run chef-client, you know that the state will be exactly as specified in the Chef recipe, and won't include your edit.
Also, it is just in general harder and more complicated to robustly edit a file than it is to just generate one. You might write something that is idempotent in the basic case, but if the file contains a syntax error or something invalid, than your editing no longer works.
As always though, sometimes you don't have a choice, and editing is the only way to go.
I've been looking at some Lua source code, and I often see things like this at the beginning of the file:
local setmetatable, getmetatable, etc.. = setmetatable, getmetatable, etc..
Do they only make the functions local to let Lua access them faster when often used?
Local data are on the stack, and therefore they do access them faster. However, I seriously doubt that the function call time to setmetatable is actually a significant issue for some program.
Here are the possible explanations for this:
Prevention from polluting the global environment. Modern Lua convention for modules is to not have them register themselves directly into the global table. They should build a local table of functions and return them. Thus, the only way to access them is with a local variable. This forces a number of things:
One module cannot accidentally overwrite another module's functions.
If a module does accidentally do this, the original functions in the table returned by the module will still be accessible. Only by using local modname = require "modname" will you be guaranteed to get exactly and only what that module exposed.
Modules that include other modules can't interfere with one another. The table you get back from require is always what the module stores.
A premature optimization by someone who read "local variables are accessed faster" and then decided to make everything local.
In general, this is good practice. Well, unless it's because of #2.
In addition to Nicol Bolas's answer, I'd add on to the 3rd point:
It allows your code to be run from within a sandbox after it's been loaded.
If the functions have been excluded from the sandbox and the code is loaded from within the sandbox, then it won't work. But if the code is loaded first, the sandbox can then call the loaded code and be able to exclude setmetatable, etc, from the sandbox.
I do it because it allows me to see the functions used by each of my modules
Additionally it protects you from others changing the functions in global environment.
That it is a free (premature) optimisation is a bonus.
Another subtle benefit: It clearly documents which variables (functions, modules) are imported by the module. And if you are using the module statement, it enforces such declarations, because the global environment is replaced (so globals are not available).
I've read many times and agree with avoiding the use of globals to keep code orthogonal. Does the use of the config file to keep read only information that your program uses similar to using Globals?
If you're using config files in place of globals, then yes, they are similar.
Config files should only be used in cases where the end-user (presumably a computer-savvy user, like a developer) needs to declare settings for an application or piece of code, while keeping their hands out of the code itself.
My first reaction would be that it is not the same. I think the problem with globals is the read+write scenario. Config-files are readonly (at least in terms of execution).
In the same way constants are not considered bad programming behaviour. Config-files, at least in the way I use them, are just easy-changable constants.
Well, since a config file and a global variable can both have the effect of propagating changes throughout a system - they are roughly similar.
But... in the case of a configuration file that change is usually going to take place in a single, highly-visible (to the developer) location, and global variables can affect change in very sneaky and hard to track down ways -- so in this way the two concepts are not similar.
Having a configuration file ususally helps with DRY concepts, and it shouldn't hurt the orthogonality of the system, either.
Bonus points for using the $25 word 'orthogonal'. I had to look that one up in Wikipedia to find out the non-Euclidean definition.
Configuration files are really meant to be easily editable by the end user as a way of telling the program how to run.
A more specialized form of configuration files, user preferences, are used to remember things between program executions.
Global is related to a unique instance for an object which will never change, whereas config file is used as container for reference values, for objects within the application that can change.
One "global" object will never change during runtime, the other object is initialized through config file, but can change later on.
Actually, those objects not only can change during the lifetime of the application, they can also monitor the config file in order to realize "hot-change" (modification of their value without stopping/restarting the application), if that config file is modified.
They are absolutely not the same or replacements for eachother. A config file, or object can be used non-globally, ie passed explicitly.
You can of course have a global variable that refers to a config object, and that would be defeating the purpose.