I'm having a lot of problems with ZeroBraneStudio!
I enjoyed using it to write my first application on Windows, but now I fail to make it working on MacBook Air and even on WIndows after reinstalling Solar2D and ZeroBrane!
If I launch my app opening Corona Simulator everythings works well, but ZeroBrane doesn't work. The errors on MacBook and on Windows are similar.
On MacBook:
Program starting as '"/Applications/Corona-3664/Native/Corona/mac/bin/lua" -e "io.stdout:setvbuf('no')" "/var/folders/4w/hn6pxl5s20v31f0q2n9msjs40000gn/T/.bO0D1R"'.
Program 'lua' started in '/Applications/Corona-3664' (pid: 1638).
Debugging session started in '/Applications/Corona-3664/'.
SampleCode/Interface/Composer/main.lua:18: module 'composer' not found:
no field package.preload['composer']
no file './composer.lua'
no file '/usr/local/share/lua/5.1/composer.lua'
no file '/usr/local/share/lua/5.1/composer/init.lua'
no file '/usr/local/lib/lua/5.1/composer.lua'
no file '/usr/local/lib/lua/5.1/composer/init.lua'
no file './composer.lua'
no file './composer/init.lua'
no file './lua/composer.lua'
no file './lua/composer/init.lua'
no file '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/lualibs/composer/composer.lua'
no file '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/lualibs/composer.lua'
no file '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/lualibs/composer/composer/init.lua'
no file '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/lualibs/composer/init.lua'
no file './composer.so'
no file '/usr/local/lib/lua/5.1/composer.so'
no file '/usr/local/lib/lua/5.1/loadall.so'
no file '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs/composer.dylib'
no file '/Applications/ZeroBraneStudio.app/Contents/ZeroBraneStudio/bin/clibs/libcomposer.dylib'
stack traceback:
[C]: in function 'require'
SampleCode/Interface/Composer/main.lua:18: in ma etc.
Please help me to understand what is going wrong!
Thanks
It looks like your project points to /Applications/Corona-3664/ folder, but it needs to point to the location of your project files, such that the require statement for your project modules work from that location (or you need to adjust package.path values so that Lua interpreter can find the modules you are loading).
In this particular case it looks like the application expects the composer.lua to be in the same folder as main.lua, so try setting your project folder to /Applications/Corona-3664/SampleCode/Interface/Composer/ (although it's better to keep it outside of Applications/ folder).
As topic states, I have a problem while trying to install search-guard plugin for my ELK stack:
[XXX#XXXX bin]$ ./elasticsearch-plugin install -b file:///home/xxxx/search-guard-6-6.2.1-21.0.zip
-> Downloading file:///home/xxxx/search-guard-6-6.2.1-21.0.zip
[=================================================] 100%Â Â
ERROR: `elasticsearch` directory is missing in the plugin zip
I tried to do it from custom directory, then, following this answer from home, but it did not help. When I unzip the archive, I can see that there is a directory called "elasticsearch" there:
Does anyone have any suggestions how to proceed with that?
The error comes from InstallPluginCommand.class within the lib\plugin-cli-x.x.x.jar and is exactly what is says. Here's a clipped portion of the code as it's reading thru the entries in the zip file:
ZipInputStream zipInput = new ZipInputStream(Files.newInputStream(zip));
try {
ZipEntry entry;
while((entry = zipInput.getNextEntry()) != null) {
if (entry.getName().startsWith("elasticsearch/")) {
hasEsDir = true;
...
}
}
if (!hasEsDir) {
throw new UserException(2, "`elasticsearch` directory is missing in the plugin zip");
}
I realize that doesn't help you much, but as a last ditch effort, if you can't get to the root cause of the issue, 1 thing I did to get me over the hurdle was to just copy the files from the zip file into the es plugins directory (/usr/share/elasticsearch/plugins in our case). They go within /plugins, but under a directory, which is the name that Elasticsearch knows the plugin by.
The only 2 gotchas are:
You need to know the directory name to create under /plugins.
You need to know the replacement values for the plugin-descriptor.properties file.
If you can get that far, you can start ES and it should load everything fine.
me again!!
I have a question based around the download of a file. I was helped with setting up a Firefox profile to set a download to save a file directly without a pop up window. Now I need to tell Selenium to confirm that the said downloaded file is in my downloads folder on C drive to complete the test. Is there a way to do this? I've trawled for answers and have gotten nothing.
I first tried by setting a path like so on my env.rb file but didn't get very far with it:
$download_location = 'C:/Users/User/Downloads'
def download_location(path)
$download_location + path
end
Then telling cucumber to visit this location and confirm the name of the file.
Any help on pointing selenium to the location and confirming the name of a csv file would be hugely appreciated
Thanks
If you want to use ruby instead of selenium, you can use the exists? method to check the downloads directory for a given file, and it will return a Boolean result. For example:
File.exists?('C:\Users\User\Downloads\foo.txt')
I have found a solution that worked for me:
puts Dir["C:/Users/OSAT TESTING/Downloads/**/fleet_#{export}_export_all_*.csv"]
This confirmed the download of the file by looking in my downloads folder and returning the file path + name of any file that contained "fleet_#{export}_export_all_*.csv" in cmd prompt.
Thank you all for your help
:-)
I've trying to package up and old MVC 3 project to send it out but I keep getting a strange error where it telling me
'The file '/Views/Shared/print.Master' does not exist. /Views/Questionnaire/View.aspx'
But I can clearly see the file and have renamed it to try and fix it but no luck, then I tried changing the package settings to include everything but that too didn't fix it so does anybody have any idea why this could be happening? (btw it's a 2nd master file)
Any ideas or help would be much appreciated.
Solution was to check file Properties and set 'Build Action' to 'Content'.
I am completely baffled by this. I packaged up an extension and manually installed it on a fresh Magento instance. (Both the packaging and installing machine were running Magento 1.7). The installation went smoothly, except every single file I installed was turned into a folder, named after the file. Every single file. Has anyone run into this? Could it be a Magento bug?
I used to see this problem when I manually created a tar archive to use as a Magento Connect archive. Unfortunately, I don't have a solution, but here's what I understand about the problem.
While Magento Connect tgz packages are technically gzip compressed tar archives — the code that creates and extracts these archives in not the standard *nix tar tool. Instead, Magento implemented its own packing and unpacking tar code for Magento Connect
downloader/lib/Mage/Archive/Tar.php
Unfortunately, this packing and unpacking code hasn't been robustly tested across operating systems or against tar archives created with standard *nix tools. My problem with this code was archives created on my Mac OS system via tar wouldn't unpack correctly with Magento Connect's code on a system running linux.
Hard to track down, hard to report, hard to reproduce means hard to fix.
These directories are being created when Magento Connect unpacks the tgz file. I'm be 99% sure your directories are being created by this bit of code
#File: downloader/lib/Mage/Archive/Tar.php
if (in_array($header['type'], array("0",chr(0), ''))) {
if(!file_exists($dirname)) {
$mkdirResult = #mkdir($dirname, 0777, true);
if (false === $mkdirResult) {
throw new Mage_Exception('Failed to create directory ' . $dirname);
}
}
$this->_extractAndWriteFile($header, $currentFile);
$list[] = $currentFile;
} elseif ($header['type'] == '5') {
if(!file_exists($dirname)) {
$mkdirResult = #mkdir($currentFile, $header['mode'], true);
if (false === $mkdirResult) {
throw new Mage_Exception('Failed to create directory ' . $currentFile);
}
}
$list[] = $currentFile . DS;
These are the two locations where Magento unpacks the archives and creates a folder. For some reason, there's a certain condition on your two systems where the data is being packed, or unpacked, incorrectly in/out of the archive file. Try un-archiving the tgz file manually with a command line tool or your operating system's built in un-archive program. If weird things happen then at least you know it's the packing code that's the problem.
It's definitely a bug, and while I'd report it, the only "solution" would be to not create your archive on your local machine (which I realize is an awful solution, but Ours is not to question why and all that)
This is a bug that has been present since 1.7, due to an if comparison never evaluating to false when reading the #././LongLink header. I answered it more on this question:
https://magento.stackexchange.com/questions/5585/long-file-names-and-magento-connect-extension-packager/45187#45187
I found that issue happening when packing a Magento Extension on OS X that is linked (modman) into magento folders. Folder creation only occured on Windows systems.
Might that happen here too?
Rico
I encountered it, when for some reason my plugin file was set with suffix .gz
so it was plugin.tgz.gz
unzip it to plugin.tgz solved my issue
I think the issue is because of PHP version. I faced the same issue while installing extension on Magento 1.8.1 , but I found a fix by changing _getFormatParseHeader() function in /downloader/lib/Mage/Archive/Tar.php file.
Originally the function was :
protected static final function _getFormatParseHeader()
{
return 'a100name/a8mode/a8uid/a8gid/a12size/a12mtime/a8checksum/a1type/a100symlink/a6magic/a2version/'
. 'a32uname/a32gname/a8devmajor/a8devminor/a155prefix/a12closer';
}
I changed it to :
protected static final function _getFormatParseHeader()
{
if (version_compare(phpversion(), '5.5.0', '<') === true) {
return 'a100name/a8mode/a8uid/a8gid/a12size/a12mtime/a8checksum/a1type/a100symlink/a6magic/a2version/'
. 'a32uname/a32gname/a8devmajor/a8devminor/a155prefix/a12closer';
}
return 'Z100name/Z8mode/Z8uid/Z8gid/Z12size/Z12mtime/Z8checksum/Z1type/Z100symlink/Z6magic/Z2version/'
. 'Z32uname/Z32gname/Z8devmajor/Z8devminor/Z155prefix/Z12closer';
}
Really nasty bug.
For me it renaming my manually packed file from *.tar.gz to *.tgz solved it.
At least it worked on my ubuntu 15.04
Tested with magento 1.8
it's more likely that you choose the wrong path when adding content to your extension.
For me the bug happened when I added (non existing) files from layout/base instead from layout/base/default.