My problem is that i wish to capture the text that is displayed in the
console of Xcode when an application is executed and display it in a
text box in my App.
If i override NSLog i can just capture the explicit NSLog commands
that are issued in the course of the program. However many statements
that are just inserted by the compiler are not captured.
Is there a way to read the Xcode Console buffer while the app is
running and display it in the app too ??
What you see in the log window of Xcode is a composite of the messages that would normally go to standard out and standard error file streams and to the system log. If you want to capture those streams, you need to close them and reopen them as pipes or files.
If you do this, the documentation says that if you redirect standard error from the default, NSLog will log to that as well as the console. Thus you don't need to override it.
Redirecting standard error and standard out is a fairly common thing to do in Unix. The basic technique to redirect to a file is to close the file descriptor using close(2) and then reopen it using open(2) or pipe(2).
The Xcode Console is just a window that reads errors and such from the Console logs. Try reading from there.
Related
I'm trying to pipe logs to fzf so that I'll be able to filter them live, as my program spits a lot of logs out.
However, I've noticed the long lines get truncated and I have no way to show the whole lines, except to press ENTER, at which point the line will be displayed in it's entirety but the logs will be deleted from the screen and the program will crash with the error failed printing to stdout: Broken pipe (os error 32)'
It seems fzf supports this feature, as it has a --no-hscroll: Disable horizontal scroll flag, implying horizontal scroll is available by default, but arrow keys don't work, at least not alone or with the usual modifiers.
I've also tried using less -S for this, but doesn't work on live logs as it doesn't resume following after the first interrupt and F command.
As an alternative, I've noticed fzf supports a preview window feature, it would be neat to have the whole line display there so that the logs are still visible and scrolling while following the lines.
I could append logs to a file and try working from there, but is that necessary? Or can these tools also work properly on live stdout logs?
I'm using Chrome to get the HTML of a webpage which is generated by javascript. The applescript which does all this needs to run every 2 minutes. Everything is working perfectly, except that I obviously need Chrome to do this completely in the background. My script contains the following uses of Chrome (as well as a block to set theTab, which doesn't seem to ever cause Chrome to come to the front):
set URL of theTab to theURL
set isLoading to (loading of theTab)
execute front window's active tab javascript javascriptLocation
set theSource to execute front window's active tab javascript "document.documentElement.outerHTML"
Putting this line:
tell application "Finder" to set visible of process "Google Chrome" to false
after each of the above lines either produces no hiding at all, or at best Chrome flashes onscreen and then goes away. I find this very distracting.
Is there any way to have an application run reliably and permanently in the backround? Or, failing this, is there an invisible way to get javascript executed server-side so an applescript can get hold of its generated source?
Chrome 66.0.3359.181 running on Mac OS 10.11.6, Applescript 2.5.
The following is not an answer to the question I posted, but it is an answer to the problem I was trying to solve which is why I posted the question.
As stated in my question, I need to get hold of the HTML which some javascript generates on a site (which is not under my control). I can't do a client-side scrape because of CORS restrictions on the site. I tried the cross-domain tools listed here and couldn't get them to work.
So I was using Chrome's applescript command, execute, to first execute the javascript (to produce the HTML), and then a second time to grab hold of the HTML with document.documentElement.outerHTML. But having Chrome flash onto the screen every 2 minutes throughout the day was doing my head in.
Turns out Chrome can also run in headless mode, from the command line, and just happens to have an option to run javascript and return the generated HTML!
So my code got a whole lot simpler and I don't have to have Chrome in my apps list all the time. Happy coder am I :-)
Here's the one line that gets me the HTML generated on the site I need:
set theSource to (do shell script ((quoted form of POSIX path of googlePath) & " --headless --dump-dom " & theURL))
Thanks, once again, #matt. I'd never heard of headless mode and would never have found this without your suggestion of PhantomJS!
I have a Windows program that has a GUI which also uses a command line interface (a cmd Window) as a debugging console. Basically, when it is double clicked, it launches a command line window and then the program creates all the GUI windows. Then you'd have two Windows: the main GUI and a debugging console.
I'm trying to port this pogram to OS X. Because OS X (and all Unix OSs for that matter) doesn't automatically launch a command line window when you run a command line application. So, I obviously need another way to port this application.
My initial thought was simply to import the source code into a XCode project, redirect standard input and output and then port the GUI. The GUI and console would run side by side just like in Windows. I don't think this is the most optimal solution since that would mean I'd essentially have to write a terminal emulator.
My other thought would be to port the application as a command line application which creates its GUI just like in Windows. The application would then have to be run from Terminal.app which could handle all the I/O. Unfortunately, I don't think you can use the Cocoa framework without using a NSApplication loop.
Any ideas how I could approach this?
You can of course create a run loop from a terminal-launched app. But that generally isn't what you want to do.
It sounds like on Windows, the CLI is just being used as a shortcut to creating a real debugging console window. So the simplest answer is to create a debugging console window. It's pretty easy to create a window which contains just a multi-line text or list view. (If you want something fancier, consider borrowing code from iTerm2 or other open source projects instead of trying to build a complete terminal.) If your debug information is being printed with some fancy macros, just change the macros to log to your list view.
If you're directly doing something like fprintf or syslog to do your logging, it might be simpler to create a wrapper app that launches the main app, and the wrapper creates the debugging console window and displays the main app's stdout and/or stderr. (This might be as simple as using popen.)
I am using AxWindowsMediaPlayer on VB.NET to preview MP3 files from the web so that the user can choose to download it if he likes it. It works. I just put a link in the URL property and after a while it begins playing.
... after a while, of course. Because it has to download the file first. Perhaps I realized that because of my slow connection XD.
But that made me think: how can I tell if the player is currently downloading a file? So that I can put a label saying "Please wait, preparing file..." or something.
Look at using the Buffering Event and the BufferingProgress Property. According to the MSDN Link:
Use this event to determine when buffering or downloading starts or stops. You can use the same event block for both cases and test IWMPNetwork.bufferingProgress and IWMPNetwork.downloadProgress to determine whether Windows Media Player is currently buffering or downloading content.
I'm writing a simple Cocoa Application, no core data or multiple document support. Running on a Mac Pro, OS X 10.6.6, Xcode 3.2.3.
I have reduced my application to the following code in my AppDelegate class:
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
NSOpenPanel *openPanel = [NSOpenPanel openPanel];
[openPanel runModal];
return;
}
From within the debugger, I will run my application. As expected a somewhat not-to-useful OpenPanel will appear. I will click Cancel and it will disappear. All this is as expected. When I click [Command + Q] to Quit the application, the UI will go away but the debugger will indicate that the application is still running (as does the console output).
Based upon all the information I'm reading, I should not have to do anything else in order for this to run right. I've downloaded several examples on the Open Panel's usage but most use the deprecated methods of opening modal giving additional information as parameters. FWIW, I tried those methods and am still seeing the same result.
One last item, when the Open dialog appears, just for an instant I see a message box asking me something to the extent if I want my application to receive incoming connections. The dialog quickly disappears. I don't know if that is part of my problem or not. [Update - this deals with my Firewall being turned on.]
Yes, I'm fairly new at Objective C but not at programming in general. Any words of wisdom is greatly appreciated!
2011.02.07 - Update:
I have walked the debugger line by line without incident. There is no indication of any program failure in the console window.
I say that the debugger is still active after [Command + Q] because the Stop Process toolbar button is still enabled as is the Break button. Further the console indicates that after I tell the application to terminate (either via the menu or key command) that it is still running. The following is the Complete console output from start of run to after I Quit the application.
Program loaded.
run
[Switching to process 62370]
Running...
The Activity Monitor (system tool) will show my application terminating (no longer shows up as a process) but the Debugger will still not transition to "edit" mode - if I tell Xcode to run the debugger again, it will ask me if it's OK to Stop the current debugging session. If I was in Windows I would start looking for background threads keeping the process alive but as far as I know, NSOpenPanel should not be doing something like that.
I have further simplified the program to nothing more than creating a brand new Cocoa application and inserting the code snippet above - no other additions to the template project or updates in any way.
And lastly, when the application is run under the Leaks Performance Tool, everything runs fine when the panel is created but never used. When created and actually used though, at the end of the run I will get the following message in the tool "insufficient task_for_pid privileges (leakagent64)". Googling this hurts. If I read it right, the debugger does not have sufficient permissions to fully kill the target process ??? Now that sounds stupid but ... It does not make sense!
Another update - I just downloaded and ran FunHouse, one of the SDK sample applications that also uses NSOpenPanel. Well don't I feel special. It exhibits the same exact behavior. So from this I conclude either Apple has a bug in their code, my machine is special and messed up, and finally, it is Not my code that is at fault. That being the best part. Tomorrow, I will use a friends Mac and see if the same behavior is exhibited on his box.
This is just too weird.
I rebooted my box, took it to work and found it worked like a charm! I will assume this is fixed and has nothing to do with any other connected devices at home as compared to at work.
If it re-exhibits at home, then it is a network/device issue. Thanks all for your inputs and suggestions! Very much appreciated.
What, specifically, does the debugger say? It's possible that your program crashed, so the debugger is showing you information about the crash.
What if you omit any attempt to run an Open panel?