I was recently messing around with the AppleScripts aspect of the Messages app on macOS Sierra and found the Mixed Message Case.applescript file, and changed the the appropriate handler in the Messages preferences.
Nothing seemed to happen when it should have (on a message received, change the text to mixed case, e.g. "hello" -> "HeLlO"). I checked the functionality of the script with some display dialog debug statements and it seems fine, though the message contents aren't being changed.
This begs the question: how does one change incoming or outgoing messages with AppleScript?
Related
During 10.8 times I created macro in Keyboard Maestro for adding web pages to Reminders list to read them later.
In Mountain Lion and Maverics it worked fine but in Yosemite something wrong is going on resulting very slow executions.
Previously execution time was about 1-2 seconds now its over 40 seconds or even one minute!
Apple team provided me with wrong solution ordered to "code sign" my script, but there is no "file" to codesign and applescripts can be executed in command line. So IMO they messed up something in osascript and still couldn't fix it till 10.10.4. But I need someone to confirm or to advice me how to debug problem, because I cannot find in system console log lines relevant to problem.
UPDATE:
On El Capitan 10.11.1 problem still persist.
Macro
Could anyone test and confirm this? I provided link to macro.
It is bind currently to F1 - change as you like. Before execution create "2Read" list in Reminders on OSX.
I've tried it and it's done in about 1-2 seconds on my machine. So I do not experience the same problem as you.
I'm running OS X 10.10.4 on a late 2013 MBP Retina.
Maybe your "2Read" list is too long?
Another tip:
I used to have a problem with long lists in Applescript, too. Sometimes it would take minutes to run through a list, but after using some if these tips the time for the lists was brought back to only seconds.
From your pastebin link (yeah, I did warn you it'd look like mince):
Keyboard Maestro event logs
(1) KM sends an 'open' event ('aevt/odoc') to Growl, telling it to open a temp file (presumably to make Growl display a message)
(2) Bartender sends a 'get scripting terminology' event ('ascr/gdut') to KM
(3) Bartender sends a 'BTDR/Load' event to KM, which looks like Bt telling KM to load a plugin named "BartenderHelperNinetyOne.bbundle"
(4) KM send a 'KeyC/KeyB' event to something (it doesn't give the name of the process, only its Process Serial Number, which is the classic MacOS equivalent to a Unix process ID). Probably easiest just to ask the KM devs about that one.
(5,6,7) KM then sends three 'application died' events ('aevt/obit') to Keyboard Maestro Engine (I'm guessing that's a faceless helper app that runs constantly in the background), informing it that three osascript processes (PSNs 312312, 315315, 316316) have terminated. This doesn't necessarily mean that osascript has crashed as those events contain an error number ('errn') parameter with value 0, and command-line processes normally return error code 0 to indicate they've completed successfully. It's quite likely these are normal internal notifications sent between KM and KME to indicate when a task is completed. The first of those osascript processes (PSN 312312) is related to the Reminders activity below; the other two I'm guessing are you running other AppleScript macros and probably not relevant here.
Reminders event logs
(1,2,3) The 'osascript' process with PSN 312312 sends Reminders a 'make' ('core/crel') event and two 'set' ('core/setd') events, which is obviously your AppleScript being run.
(4) The Dock sends it a 'reopen' ('aevt/rapp') event, which is probably just you clicking on Reminders' dock icon to bring it to the front.
The main problem, of course, is that without timestamps I can't tell you where your 40-second delay is occurring. You'd really need to do it again, this time manually noting the time at which each message is logged. And if you see a single 40-second delay somewhere in the middle, it should easy enough to determine which events it's occurring inbetween, which should start to point towards a cause. At which point, you're probably best contacting the KM vendor to discuss it with them.
HTH
I'm investigating whether I can get better performance from asl_log than NSLog on iPhone/iOS (probably...) but I'm stuck at a point where it doesn't seem that asl's log output will show up in the System Console (as viewable by a number of apps like System Console, iConsole, etc). I know that I'm setting it up right since I open with ASL_OPT_STDERR, and I see the log entries in XCode when the device is tethered.
I've explored lots of interesting stuff online (e.g. http://boredzo.org/blog/archives/2008-01-20/asl-logging, https://github.com/robbiehanson/CocoaLumberjack) and the best hope seemed to be asl_open() with Facility of "com.apple.console" but alas, the output still doesn't show up in Console. Is NSLog the only option?
Add STDERR to ASL and then it shows up in the console
asl_add_log_file(NULL, STDERR_FILENO);
You need to set read privileges on the message, using either ReadUID or ReadGID. Setting either to -1 will allow any user/group to view the message according to the header file documentation.
aslmsg msg = asl_new(ASL_TYPE_MSG);
asl_set(msg, ASL_KEY_READ_UID, "-1");
asl_log(NULL, msg, ASL_LEVEL_NOTICE, "Hello, world!");
asl_free(msg);
Part 1: Expected behaviour?
I'm seeing some inconsistent browser behaviour between Firefox and Chrome in relation to the onclose handler being called.
It seems that Chrome does not trigger an onclose if it was caused by a user page navigation/refresh. However, Firefox does trigger the onclose.
It seems to me that Firefox may be behaving correctly here:
When the WebSocket connection is closed, possibly cleanly, the user agent must create an event that uses the CloseEvent interface, with the event name close, which does not bubble, is not cancelable, has no default action, whose wasClean attribute is set to true if the connection closed cleanly and false otherwise, whose code attribute is set to the WebSocket connection close code, and whose reason attribute is set to the WebSocket connection close reason; and queue a task to first change the readyState attribute's value to CLOSED (3), and then dispatch the event at the WebSocket object.
Source: http://www.w3.org/TR/2011/WD-websockets-20110419/#closeWebSocket
Even though it can lead to some sneaky code/unexpected behaviour.
Can anybody confirm the expected behaviour?
Part 2: How to implement auto-reconnect?
If you have a library that auto-reconnects for the user how do you know if you should try to reconnect? Do you check the CloseEvent.wasClean property? I'm having to assume that 'clean' means that the close was supposed to happen through either an API call to WebSocket.close() or the server sending a close frame? If a network error causes the close I'm guessing the wasClean would be false?
In the Pusher JavaScript library we assumed (onclose -> waiting -> connecting) that a close should trigger a reconnect unless we are in a closing state - the developer has chosen to close the connection. It would appear that the socket.io client library makes the same assumption.
Based on this the Firefox onclose event caused by user navigation/refresh triggers an unwanted reconnection because neither library check the CloseEvent.wasClean property.
Example and Video
Here's an example that you can use to demonstrate the inconsistency:
http://jsbin.com/awonod/7
Here's a video of me demonstrating the problem:
http://www.screenr.com/vHn8
(it's late, ignore the couple of slip-ups :))
One point to note is that my hitting the Escape key could also be causing the WebSocket connection to close. However, if you watch closely or try for yourself you will see the close event being logged just before the page refreshes.
The unexpected behavior is due to the way in which Firefox and Chrome handle the closing of a Websocket. When the page is refreshed, both browsers close the connection, however, Firefox will execute your onclose code, while chrome closes the connection and skips straight to re-loading the new page. So yes, I confirm this strange behavior.
Even stranger is the fact that, from my observations, calling websocket.close() in chrome will immediately close the connection and call the onclose function, while Firefox waits for a close message back from the server.
The wasClean property will be true if a close message was received from the server
If your library is auto-reconnecting without checking the wasClean property then this could cause a problem, as it tries to re-establish the connection as the page refreshes. You should consider not using the library for this and doing it manually, it should'nt be very hard, just call connect in the onclose function with an if statement making sure the onclean property is true. Or to be even more safe set a variable in onbeforeunload that prevents any new connection.
hope this helps!
This is amazingly still the current behavior in 2022. You can demonstrate this trivially by adding a console log in an onclose handler for a websocket, and click a link in Firefox vs in Chrome while watching the console (ensuring you preserve the console between webpages):
ws.onclose = function(e) {
printMsg('CLOSE')
// ... my other code ...
}
Firefox will show you a 'CLOSE' and Chrome will not.
I am trying to create a very simple (text based for now) email app for receiving emails. So far i have used this code :
http://www.javaer.org/j2ee/3-javamail/8-javamail-connecting-gmail-using-pop3-with-ssl
The problem is that i when i run this code i am able to get the new emails, only for once. For example if i have a new message in inbox the first time i will this code it will show it but then it wont. Also it seems that i cant see the body contents of the emails which is strange. I was told that it should be better to use imap protocol but i am not entirely sure how.
Specified example really starts once and scans folder and exits (and see answer on POP that removes mail). From description you need some loop that periodically checks catalog and extracts new mails. Look at some swing examples in your JDK how to write window-based program with event loop. You can start dedicated thread that once per minute checks POP server catalog
The following message keeps getting logged to the console:
-[__NSCFSet minusSet:]: This app appears to be calling this method with
a non-set parameter. Please wait while the system corrects this...
I don't know what I did to this appear. I never call this function and don't know what things call this.
For me, this appear when a touch anything in my UIWebView. This can be a touch in text box, or just a simple touch in any area of the page. Any new touch will produce it.
Anyone have an idea how to solve it?
You should be able to find out whether your code is causing the log message or not. You can do this by interrupting the app when the message is logged and looking at the stack backtrace of the logging thread. Then, investigate what code created the object that is prompting the log message using malloc history or Instruments.
To start with, you can try adding a symbolic breakpoint on -[__NSCFSet minusSet:]. You could narrow it down to the actual code doing the logging if you looked at the disassembly for a call to NSLog and placed the breakpoint there.
Once you've ruled out your code, it's not your fault: it's time to file a bug report and move on. If the log messages are swamping more interesting log messages, you might try patching the binary so it doesn't log, but just living with it is likely to be easier (though much less fun).