There is an issue/bug/feature/whatever on Linux + NGinx + Kohana :
We have to make sure that we keep all our file names in lowercase only.
We can't have anything like "setUserServer.php". It simply doesn't work. No idea why.
If we give the name of the same file as "setuserserver.php", it runs.
This problem doesn't exist on Windows + Apache + Kohana.
If anyone has an idea how to solve this, please do chime in this thread.
Thanks.
Solution is sticking to the naming scheme of kohana: all files lower case
Windows by default is not case sensitive, and linux is. Can't "solve" that
You can use mixed case for a vendor libraries (loading by include or require), but original Kohana's autoloader will convert class names to lower case (as SpadXIII). So, possible solution is writing your own autoloader (or extend Kohana class) and use it instead/before standard.
PS. AFAIR, View class will work with files like PageTemplate.php
Related
After I uploaded my Typo3-Website onto a linux server and tryed to call the homepage, I get the error: "Could not load layout file. Tried following paths: "/Main.html", "/Main" "
I checked the correct spelling (uppercase) of my layout file: It seems to be correct and in the right place. Any ideas?
Thanks a lot. I have checked the file paths and noticed I had to delete the two slashes after the equal signs.
This works on a windows platform:
partialRootPath = /fileadmin/Private/Partials/
layoutRootPath = /fileadmin/Private/Layouts
But on a linux server it has to look this way:
partialRootPath = fileadmin/Private/Partials/
layoutRootPath = fileadmin/Private/Layouts
You seem to be using TYPO3 before 7 and the StandaloneView. In this case, identify in your code where you use this view and check the calls to setTemplatePathAndFilename or the templateRootPath. You are probably having an issue with the root path being set to something that does not exist.
This might be a situation of incompatible cAsiNg of the directory name. This is especially possible if you are testing locally on MacOS (case insensitive) and then uploading to Linux (case sensitive).
If this does not help, please provide us with more information about your scenario (code, settings, environment where it works, etc).
I have been working on a game for a while now and i tried to make this game as easy to understand as possible and easy to change as well by using one variable in a few places and not write the variables value in each place so that if i decide to change the value i wont have to change it every where, i will just have to change the value of the variable.
Two days ago i formatted my computer and saved in my external Hard Drive a .Jar file of the
game and the Eclipse(Coding environment) folder in where i THOUGHT the game source should be located at but it wasn't thus losing my source code.
I was very upset but then I remembered that you can decompile a jar file.
I searched for a decompiler and found the jd gui decompiler opened my jar file and i was happy
to see that its actually works but then... I noticed that the code is alliiiiitle bit different.
The compiler added tons of this. all the classes which doesn't matter to me.
Then i noticed that every where there was a double type number it added a .0 and a D
at the end of the number and even is some places where i had for example 0.7 i saw that there is 0.699999996 which again doesn't really matter, not a big deal.
But then i noticed that in all the places where i had a final variable it changed it to its value (Example : supposed to be : numRowsToDraw = Panel.WIDTH / tileHeight + 2;
what it is now : numRowsToDraw = 768 / tileHeight + 2;)
which ruined all the easy to change aspect of the program and i didn't want to change
the numbers back to the variable in all the places there should be a variable because it will take a lot of work.
So my question is : Is there a decompiler which doesn't change your code?
If there is can you tell me the name of it?
THANKS!
Oh and i forgot to mention that i tried afterwards the JAD decompiler which did the same thing...
No, there is not. Decompilation can never get back source level constructs like comments or the particular formatting of literals. But I'm sure there are automated source formatting tools out there that let you do stuff like remove Ds on double literals.
I have a very strange problem with the constructor of AptPkg::Cache object in the precise package of libapt-pkg-perl (v. 0.1.25).
The perl script is designed to download a debian package for three different architectures (i386, armel, armhf). For each architecture I do the following:
Configure AptPkg::Config '$_config' with the right parameters and package-lists for the desired architecture.
Create the cache object with AptPkg::Cache->new .
Call the method AptPkg::Cache->policy to create the AptPkg::Policy object.
Call the method AptPkg::Policy->candidate("program-name") .
Download the package for the selected architecture.
This works very well with Ubuntu Lucid, but with Ubuntu Precise I can only download the package for the first architecture defined. For the other two architectures there will be no installation candidate (method AptPkg::Policy->candidate("Package-Name") doesn't return an object).
I tried to build a workaround and I found one solution how the script works for all three architectures, without problems, in precise:
If I create the cache object (with AptPkg::Cache->new) twice in a row it works and the script downloads the debian package for all three architectures:
my $cache = AptPkg::Cache->new;
$cache = AptPkg::Cache->new;
I'm sure that the problem has something to do with the method AptPkg::Cache->new because I checked everything else, what could cause the problem, twice. All config-variables are set correctly and I even get a different Hash for AptPkg::Cache->new for each architecture, but it seems that I am overlooking something important.
I'm not very familiar with perl, so I am asking you guys if someone can explain why the script works with the workaround but not without it. Further it looks quite strange if you have the same line of code twice in your script.
Maybe you hit this bug - https://bugs.launchpad.net/ubuntu/+source/libapt-pkg-perl/+bug/994509
There is a script there to test if you're affected. If it's something else consider submitting a bug report.
edit: Just saw this is 11 months old :/
I am trying to get application data folder location under Linux using Qt's storageLocation function:
QDesktopServices::storageLocation(QDesktopServices::DataLocation)
But this function returns path with two slashes at the end:
/home/user/.local/share/data//
Two slashes at the end of path looks very strange for me. Is this normal? Or this is bug in Qt?
My Linux is Ubuntu.
Qt version is 4.8.1.
This is a bug in Qt (see bug report). However, it happens only if you didn't set your app's name and organization name. You should set them using QApplication::setApplicationName and QApplication::setOrganizationName.
The chop solution you've accepted earlier is bad for two reasons. The first, if this bug is fixed, your code could be broken. Who knows how many slashed will be here in the next version (maybe 0). I'd suggest to use the following to remove double slash:
QString s = QDesktopServices::storageLocation(QDesktopServices::DataLocation);
s = QDir(s).absolutePath();
But it's more important that the /home/user/.local/share/data/ location is still invalid. You need to set application and organization names if you want to get proper location. Simple removing trailing slash doesn't fix anything, it's just a dirty hack.
I know it's an old question but QDesktopService::dataLocation have the following structure <user data location>/<application name>/.
Under linux, the user data location is $HOME/.local/share/data/.
The application name is set via the QCoreApplication::setApplicationName() method, I guess you do not set it, which explains why you have two trailing slashes.
No its not only you its same on here. you just need to chop the last character
QString s = QDesktopServices::storageLocation(QDesktopServices::DataLocation);
s.chop(1);
I recently coded something where it wasn't known if the end code would reside in a subdomain (http://user.domain.com/) or in a subdomain (http://domain.com/user), and I was lost as to the best practice for these unknown scenarios. I could thinks of a couple:
Use absolute paths (/css/styles.css) and modrewrite if it ends up being /user
Have a settings file and declare a variable with the path (<? php echo $domain . "/css/styles" ?>)
Use relative paths (../css/styles.css).
What is the best way to handle this?
If there is any question about where something might be deployed, I would avoid absolute paths whenever possible, and if you must use them, make sure to construct them using the data in the $_SERVER superglobal. The value $_SERVER['PHP_SELF'] will contain the path and filename to the currently executing script, and you can then extract the path using something like:
$path = dirname($_SERVER['PHP_SELF']);
Likewise, the value $_SERVER['HTTP_HOST'] will contain the current host, and from those two together you can build the path to wherever you are. If you're using HTTPS you may also need to check the protocol in $_SERVER['HTTPS'].
With that said, it is still best to use relative paths and a simple file and directory structure whenever possible, since it makes everything more portable and easier to read. If, as in your example, you find yourself doing a lot of ../css/styles.css then you may want to reconsider how things are structured.
Mix of 2 and 3. Use paths relative to a set variable.