I've tried doing this:
sudo ln -s "/Applications/WebStorm.app/Contents/MacOS/webide" /bin/webstorm
and then if I run it, it throws
013-10-26 15:40:56.191 webstorm[12210:1f03] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFString hasPrefix:]: nil argument'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff895cc41c __exceptionPreprocess + 172
1 libobjc.A.dylib 0x00007fff863eae75 objc_exception_throw + 43
2 CoreFoundation 0x00007fff895cc2cc +[NSException raise:format:] + 204
3 CoreFoundation 0x00007fff894e572a -[__NSCFString hasPrefix:] + 90
4 webstorm 0x0000000100001f03 satisfies + 435
5 webstorm 0x000000010000245d findMatchingVm + 1213
6 webstorm 0x0000000100003832 -[Launcher launch] + 98
7 Foundation 0x00007fff8fdf170b __NSThread__main__ + 1318
8 libsystem_pthread.dylib 0x00007fff847bd899 _pthread_body + 138
9 libsystem_pthread.dylib 0x00007fff847bd72a _pthread_struct_init + 0
10 libsystem_pthread.dylib 0x00007fff847c1fc9 thread_start + 13
)
libc++abi.dylib: terminating with uncaught exception of type NSException
So, how do I start webstorm from the terminal?
ps. interestingly if I run it directly it runs
"/Applications/WebStorm.app/Contents/MacOS/webide"
but I prefer something shorter than that
Oh... I was doing it wrong... There's an option in Webstorm... "Tools -> Create command line launcher"
it works great. I love this IDE. "JetBrains" - you guys are awesome!
The code is not expecting to be run from a symlink. Kind of a bug, but an obscure one I guess. You can instead put it on your PATH (or add an alias, but that's not the normal way to solve this problem). Here is how to put it on your PATH -
export PATH=$PATH:/Applications/WebStorm.app/Contents/MacOS/
although this might still hit the same bug, I guess. So try it first - if it works, add it to your $HOME/.bashrc file.
Related
I hope somebody can help me .. I try to open a new entry in a joomla menu and get the following error output:
0 Cannot use object of type stdClass as array
/mnt/web208/e2/01/56797301/htdocs/plugins/system/helix3/helix3.php:55
error output
Function Location 1 () JROOT/plugins/system/helix3/helix3.php:55 2 plgSystemHelix3->onContentPrepareForm() JROOT/libraries/joomla/event/event.php:70
3 JEvent->update() JROOT/libraries/joomla/event/dispatcher.php:160
4 JEventDispatcher->trigger() JROOT/libraries/src/MVC/Model/FormModel.php:321
5 Joomla\CMS\MVC\Model\FormModel->preprocessForm() JROOT/administrator/components/com_menus/models/item.php:1254
6 MenusModelItem->preprocessForm() JROOT/libraries/src/MVC/Model/FormModel.php:242
7 Joomla\CMS\MVC\Model\FormModel->loadForm() JROOT/administrator/components/com_menus/models/item.php:552
8 MenusModelItem->getForm() JROOT/libraries/src/MVC/View/HtmlView.php:423
9 Joomla\CMS\MVC\View\HtmlView->get() JROOT/administrator/components/com_menus/views/item/view.html.php:58
10 MenusViewItem->display() JROOT/libraries/src/MVC/Controller/BaseController.php:672
11 Joomla\CMS\MVC\Controller\BaseController->display() JROOT/administrator/components/com_menus/controller.php:75 12 MenusController->display() JROOT/libraries/src/MVC/Controller/BaseController.php:710
13 Joomla\CMS\MVC\Controller\BaseController->execute() JROOT/administrator/components/com_menus/menus.php:18
14 require_once() JROOT/libraries/src/Component/ComponentHelper.php:382
15 Joomla\CMS\Component\ComponentHelper::executeComponent() JROOT/libraries/src/Component/ComponentHelper.php:357
16 Joomla\CMS\Component\ComponentHelper::renderComponent() JROOT/libraries/src/Application/AdministratorApplication.php:101
17 Joomla\CMS\Application\AdministratorApplication->dispatch() JROOT/libraries/src/Application/AdministratorApplication.php:159
18 Joomla\CMS\Application\AdministratorApplication->doExecute() JROOT/libraries/src/Application/CMSApplication.php:195
19 Joomla\CMS\Application\CMSApplication->execute() JROOT/administrator/index.php:51
The error occurred in the file helix3.php on line 55. Plugging the displayed notation ("helix3.php:55", with the quotes) into Google yields this page as first result:
https://www.joomshaper.com/forums/helix3-plugins-causing-joomal-menu-to-not-work-0-cannot-use-object-of-type-stdclass-as-array
This site states it's a known bug and an update will be released soon. Try to update the plugin, or modify the helix3.php file as explained.
And please use Google (or another search engine of your liking) before posting a question. Filenames + Line numbers as well as paths and the first sentence of error messages make for great search terms.
PS: Welcome on StackOverflow!
One of my apps (release version) was unresponsive, so I had to force-quit it.
OS X presented a Hang report (no crash report), which I copied to a *.crash file.
I'm aware of I can use services such as HockeyApp or atos directly to symbolicate Crash Reports, but how can I symbolicate Hang reports for OS X apps?
After some time, I found out how to handle the Hang reports, which are slightly different from normal crash reports. Here's what I did:
In Xcode look up the corresponding archive of the app that crashed in the Organizer and reveal it in Finder (right-click).
Right-click the archive and choose Show Package Contents.
Copy the *.app from Products and the corresponding *.dSYM file from the dSYMs directory into a new folder, e.g., on your Desktop. You will have a MyApp.app and a MyApp.app.dSYM in the new folder. The naming of the files is important.
ls into the new folder via the Terminal.
Now to use the atos tool ('convert numeric addresses to symbols of binary images or processes'), we need to first determine the load address of your app at runtime, and the address of the stack frame while the app was hanging.
Open the Hang report, and find a line which says Binary Images: somewhere below the Heaviest stack for ... line. In my case this looks similar to:
Binary Images:
**0x107b0f000** - 0x108b59fff com.company.MyApp 1.1.0 (2) <6080DCE1-9086-311C-899F-CC22B32D694D> /Applications/MyApp.app/Contents/MacOS/MyApp
0x7fff89c7e000 - 0x7fff89c87fff libsystem_pthread.dylib (105.10.1) <3103AA7F-3BAE-3673-9649-47FFD7E15C97> /usr/lib/system/libsystem_pthread.dylib
0x7fff8b0bf000 - 0x7fff8bc06fff com.apple.AppKit 6.9 (1344.36) <D94A7D32-A789-37EA-A85C-BEFA7DE716E6> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x7fff8bd6e000 - 0x7fff8c09cfff com.apple.Foundation 6.9 (1152.12) <C0EE9DA6-C111-358A-8874-DA175BB797D6> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
The address 0x107b0f000 surrounded by ** is our load-address, which you should copy.
Next, we need to find the addresses we want to find symbol information for, that is, get the actual method signatures and the code lines, which led to the hang. Therefore, look up your app's name in the stack at the beginning of the Hang report, below 'Heaviest stack':
Heaviest stack for the main thread of the target process:
10 start + 1 (libdyld.dylib + 13769) [0x7fff91df35c9]
10 NSApplicationMain + 1832 (AppKit + 10612) [0x7fff8b0c1974]
10 -[NSApplication run] + 594 (AppKit + 95459) [0x7fff8b0d64e3]
10 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 194 (AppKit + 145072) [0x7fff8b0e26b0]
10 _DPSNextEvent + 964 (AppKit + 147201) [0x7fff8b0e2f01]
10 _BlockUntilNextEventMatchingListInModeWithFilter + 71 (HIToolbox + 190347) [0x7fff96ae378b]
10 ReceiveNextEventCommon + 431 (HIToolbox + 190794) [0x7fff96ae394a]
10 RunCurrentEventLoopInMode + 235 (HIToolbox + 191439) [0x7fff96ae3bcf]
10 CFRunLoopRunSpecific + 296 (CoreFoundation + 464984) [0x7fff901f1858]
10 __CFRunLoopRun + 927 (CoreFoundation + 466495) [0x7fff901f1e3f]
10 __CFRunLoopDoSources0 + 269 (CoreFoundation + 469005) [0x7fff901f280d]
10 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 525953) [0x7fff90200681]
10 __NSThreadPerformPerform + 293 (Foundation + 416988) [0x7fff8bdd3cdc]
10 ??? (MyApp + 62967) [0x108b1e5f7]
8 ??? (MyApp + 48600) [0x108b1add8]
8 -[IKImageBrowserView(ImageBrowserLayout) itemFrameAtIndex:] + 63 (ImageKit + 400983) [0x7fff91140e57]
[...]
At the end of this example stack trace, you find MyApp listed twice. Copy both addresses, 0x108b1e5f7, 0x108b1add8, and close the report.
Now we are ready to use atos. In the Terminal enter the following and press Return:
atos -o MyApp.app/Contents/MacOS/MyApp -arch x86_64 -l 0x107b0f000 0x108b1e5f7 0x108b1add8
atos will symbolicate the addressess using the *.dSYM file within the same directory and hopefully output something like:
-[MainWindowController loadDidFinish:] (in MyApp) (MainWindowController.m:127)
-[MainWindowController view:stringForToolTip:point:userData:] (in MyApp) (MainWindowController.m:231)
Yay, that looks promising!
If atos outputs the same addresses you've put it, instead of code lines, something went wrong. The top source for errors here are probably wrong memory addresses, so make sure, you've chosen the right ones.
Let me know if you have further questions (#raffael_me).
I have a stack trace from my Mac App Store app, that I'd like to read to help diagnose a problem the user is experiencing. I have the dSYM file and original archived build, but I do not have a full crash report. All I would like to know is the name of the methods in the stack trace (you can see two of them for MyAppName, below). I have not been able to get lldb or atos to give me this information. This is what the stack trace looks like:
0 CoreFoundation 0x00007fff92fdd25c __exceptionPreprocess + 172
1 libobjc.A.dylib 0x00007fff918dbe75 objc_exception_throw + 43
2 CoreFoundation 0x00007fff92ebb4f5 -[__NSArrayM objectAtIndex:] + 245
3 MyAppName 0x0000000108e91c6b MyAppName + 126059
4 MyAppName 0x0000000108e7556f MyAppName + 9583
5 AppKit 0x00007fff8d883099 -[NSToolbarButton sendAction:to:] + 75
6 AppKit 0x00007fff8d8830e8 -[NSToolbarButton sendAction] + 65
7 AppKit 0x00007fff8d436f0c -[NSToolbarItemViewer mouseDown:] + 4897
8 AppKit 0x00007fff8d352a58 -[NSWindow sendEvent:] + 11296
9 AppKit 0x00007fff8d2f15d4 -[NSApplication sendEvent:] + 2021
10 AppKit 0x00007fff8d1419f9 -[NSApplication run] + 646
11 AppKit 0x00007fff8d12c783 NSApplicationMain + 940
12 libdyld.dylib 0x00007fff87df35fd start + 1
13 ??? 0x0000000000000001 0x0 + 1
To get a symbol (say, for level 3 above), what command can I use? When I was calling lldb, it wasn't even clear if I should be using the hex address or the offset, if that's what the 126059 is on level 3.
Update
According to the atos documentation, it looks like I should invoke it like so:
xcrun atos -arch x86_64 -o MyAppName.app/Contents/MacOS/MyAppName -l <LOADED ADDRESS> 0x0000000108e91c6b
What would I use as the loaded address, though? All I have is what I pasted above. Whether I use 0x0000000000000001, 0x00007fff87df35fd, or leave out -l entirely, I get 0x0000000108e91c6b (the address I specified) printed back to standard out.
In most tools that dump stack traces (particularly CrashReporter) there's a section at the bottom of the report with all the images currently loaded in the program, their UUID's and their load addresses. You should always make sure to get that info along with the stack trace since that's what tells you the load address of the binary, and also will ensure that you have the right version of the debug information, since you can match the UUID against the UUID in the dSYM or binary.
You might be able to use the "Symbol Name + offset" part of the trace to figure out the load address, however. Generally, this last column is the offset of the address in the backtrace from the closest unstripped symbol in that binary. So you just find the address of that symbol in your stored binary, add the offset to that address, and subtract that from the address listed in the third column above. In lldb, you can find the address of a symbol using:
(lldb) image lookup -n <SymbolName>
That calculation will give you the "slide" of the binary from its default load address. Then run lldb on your binary and do:
(lldb) image load -f MyAppName -s <Calculated Slide>
Now you can look up the addresses from MyAppName in the stack trace using:
(lldb) image lookup -va <ADDRESS>
However, main executables are usually totally stripped - since they generally don't provide symbols for use by any other component of the system, so there aren't any symbols left. In that case, I would guess MyAppName in the listing above is just the __TEXT.__text section of the binary, though I'm not 100% sure about that. Anyway if that is right, you can find the default load address of that section by loading the binary in lldb and doing:
(lldb) image dump sections MyAppName
Then do the same calculation listed above.
Need to recruit the help of any budding bioinformaticians that are lurking in the shadows here.
I am currently in the process of formatting some .fasta files for use in a set of grouping programs but I cannot for the life of me get them to work. First things first, all the files have to have a 3 or 4 character name such as the following:
PP41.fasta
PP59.fasta
PPBD.fasta
...etc...
The files must have headers for each gene sequence that look like so: >xxxx|yyyyyyyyyy where xxxx is the same 3 or 4 letter 'taxon' identifier as the file names I put above and yyyyyyy is a numerical identifier for each of the proteins within each of the taxons (the pipe symbol can also be replaced with an _ as below). I then cat all of these in to one file which has a header that looks correct like so:
>PP49_00001
MIENFNENNDMSDMFWEVEKGTGEVINLVPNTSNTVQPVVLMRLGLFVPTLKSTKRGHQG
EMSSMDATAELRQLAIVKTEGYENIHITGARLDMDNDFKTWVGIIHSFAKHKVIGDAVTL
SFVDFIKLCGIPSSRSSKRLRERLGASLRRIATNTLSFSSQNKSYHTHLVQSAYYDMVKD
TVTIQADPKIFELYQFDRKVLLQLRAINELGRKESAQALYTYIESLPPSPAPISLARLRA
RLNLRSRVTTQNAIVRKAMEQLKGIGYLDYTEIKRGSSVYFIVHARRPKLKALKSSKSSF
KRKKETQEESILTELTREELELLEIIRAEKIIKVTRNHRRKKQTLLTFAEDESQ*
>PP49_00002
MQNDIILPINKLHGLKLLNSLELSDIELGELLSLEGDIKQVSTGNNGIVVHRIDMSEIGS
FLIIDSGESRFVIKAS*
Next step is to construct a blast database which I do as follows, using the formatdb tool of NCBI Blast:
formatdb -i allproteins.fasta -p T -o T
This produces a set of files for the database. Next I conduct an all-vs-all BLAST of the concatenated proteins against the database that I made of them like so, which outputs a tabular file which I suspect is where my issues are beginning to arise:
blastall -p blastp -d allproteins.fasta -i allproteins.fasta -a 6 -F '0 S' -v 100000 -b 100000 -e 1e-5 -m 8 -o plasmid_allvall_blastout
These files have 12 columns and look like the below. It appears correct to me, but my supervisor suspects the error is in the blast file - I don't know what I'm doing wrong however.
PP49_00001 PP51_00025 100.00 354 0 0 1 354 1 354 0.0 552
PP49_00001 PP49_00001 100.00 354 0 0 1 354 1 354 0.0 552
PP49_00001 PPTI_00026 90.28 288 28 0 1 288 1 288 3e-172 476
PP49_00001 PPNP_00026 90.28 288 28 0 1 288 1 288 3e-172 476
PP49_00001 PPKC_00016 89.93 288 29 0 1 288 1 288 2e-170 472
PP49_00001 PPBD_00021 89.93 288 29 0 1 288 1 288 2e-170 472
PP49_00001 PPJN_00003 91.14 79 7 0 145 223 2 80 8e-47 147
PP49_00002 PPTI_00024 100.00 76 0 0 1 76 1 76 3e-50 146
PP49_00002 PPNP_00024 100.00 76 0 0 1 76 1 76 3e-50 146
PP49_00002 PPKC_00018 100.00 76 0 0 1 76 1 76 3e-50 146
SO, this is where the problems really begin. I now pass the above file to a program called orthAgogue which analyses the paired sequences I have above using parameters laid out in the manual (still no idea if I'm doing anything wrong) - all I know is the several output files that are produced are all just nonsense/empty.
Command looks like so:
orthAgogue -i plasmid_allvsall_blastout -t 0 -p 1 -e 5 -O .
Any and all ideas welcome! (Hope I've covered everything - sorry about the long post!)
EDIT Never did manage to find a solution to this. Had to use an alternative piece of software. If admins wish to close this please do, unless it is worth having open for someone else (though I suspect its a pretty niche issue).
Discovered this issue (of orthAgogue) first today:
though my reply may be old, I hope it may help future users;
issue is due to a missing parameter: seems like you forgot to specify the separator: -s '_', ie, the following set of command-line parameters should do the trick*:
orthAgogue -i plasmid_allvsall_blastout -t 0 -p 1 -e 5 -O -s '_'
(* Under the assumption that your input-file is a tabular-seperated file of columns.)
A brief update after comment made by Joe:
In brief, the problem described in the intiail error report (by Joe) is (in most cases) not a bug. Instead it is one of the core properties of the Inparanoid algorithm which orthAgogue implements: if your ortholog-result-file is empty (though constructed), this (in most cases) implies that there are no reciprocal best match between a protein-pair from two different taxa/species.
One (of many) explanations for this could be that your blastp-scores are too similar, a case where I would suggest a combined tree-based/homology clustering as in TREEFAM.
Therefore, when I receive your data, I'll send it to one of the biologists I'm working with, with goal of identifying the tool proper for your data: hope my last comment makes your day ;)
Ole Kristian Ekseth, developer of orthAgogue
I am trying to compile and run a simple SDL program on OSX 10.8.2, SDL 1.2.15, GHC 7.4.2, haskell SDL bindings 0.6.4:
import Graphics.UI.SDL as SDL
main :: IO ()
main = do
screen <- setVideoMode 640 480 32 [SWSurface]
hello <- loadBMP "hello.bmp"
blitSurface hello Nothing screen Nothing
SDL.flip screen
delay 2000
It compiles (ghc test.hs) without erros, but when I try to run it, I get the following exception:
$ ./test
2012-11-30 12:37:29.453 test[8995:707] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1000) creating CGSWindow on line 259'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff8cf060a6 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff88e813f0 objc_exception_throw + 43
2 CoreFoundation 0x00007fff8cf05e7c +[NSException raise:format:] + 204
3 AppKit 0x00007fff87e41c29 _NSCreateWindowWithOpaqueShape2 + 655
4 AppKit 0x00007fff87e40420 -[NSWindow _commonAwake] + 2002
5 AppKit 0x00007fff87dfee62 -[NSWindow _commonInitFrame:styleMask:backing:defer:] + 1763
6 AppKit 0x00007fff87dfdfaf -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1568
7 AppKit 0x00007fff87dfd97f -[NSWindow initWithContentRect:styleMask:backing:defer:] + 45
8 libSDL-1.2.0.dylib 0x0000000101dc6bf6 -[SDL_QuartzWindow initWithContentRect:styleMask:backing:defer:] + 279
9 libSDL-1.2.0.dylib 0x0000000101dc4ac9 QZ_SetVideoMode + 2629
10 libSDL-1.2.0.dylib 0x0000000101dbb903 SDL_SetVideoMode + 886
11 test 0x0000000101b9d6b2 smJx_info + 50
)
libc++abi.dylib: terminate called throwing an exception
As far as I understand, this has something to do with main()-replacement trickery SDL performs. I looked at several other SDL-using Haskell apps; the ones that I managed to compile show the same behavior (which may point to some problem with my particular configuration). One exception is Eternal10Seconds which uses -no-hs-main ghc option and some .c/.h magic. Is this necessary, or there is more clear way to make things work?
Sorry for the informational noise, but I managed to solve it myself. It seems that .c magic is inevitable, but it requires certain efforts to make it working with cabal. Based on the example from haskell-SDL repo and TimePiece, I put together a template. I am planning to extend it a bit to make it truly cross-platform (because I need it myself anyway).