AppleScript contains some amazingly powerful APIs, but is nearly impossible to write. Having a Javascript (successor?) implementation is going to unleash its full potential. I could see it becoming much more widely used and supported by third party apps. This is wonderful.
In the same cycle that they release a brand new language, they begin the deprecation process for their (only?) other proprietary programming language in favor of an existing language. Pretty cool.
AppleScript was originally conceived to be easy enough for non-professional programmers to read and write, with the history of Hypercard behind it. This is for those rare occasions when they needed to automate something that they do with multiple applications manually. At one point, you were able to hit "Record", do the things that you needed to be automated and boom you get a script that you can begin to massage into something reusable. You didn't need to be a programmer to read this recorded script and you didn't need to know English to read/write it either (it was available in other languages). It looks like Apple realized that automation is the core problem they need to solve and made .. Automator instead, which is based on the same underlying piping - OSA.
edit: Back in 1998/99, I even wrote a web server entirely in AppleScript - it was a platform for our research lab to share, debate and record ideas.
As braindead as the language was, the real problem with AppleScript was the bizarre object model, so the Object help doc was full of nonsense methods that did nothing useful. Finding the one method doExactlyOneSpecificThing that matched what you need was always a low-probability event. The opposite of the UNIX philosophy and modular design.
Applescript was only a front end for OSA, for instance there is/was a working perl front end for OSA. The reason it never really took off is mostly due to OSA itself, and not the scripting language I think.
For instance most of the Adobe product don't care about OSA and offer a Lua extension mechanism instead (even there, I feel they only cared avout filters and publishing modules). Or even iPhoto had severe limitations on what could be done through the scripting interface.
The Finder has perhaps the most useful interface, but anything done there can also be done in the shell IMO. There must be other apps exposing very useful functionalities to OSA, but I haven't see many.
Others have touched on this farther down, but this always sets me off: AppleScript is not confusing because of its native syntax. It's confusing because of the inconsistent, often contradictory, incomplete, and sometimes just insane dictionaries provided by the various apps you access with AppleScript.
Switching to JavaScript will do exactly zero to fix that. However, there appears to be new functionality inherent in the implementation, including better integration of native code (oddly, the examples are in ObjC instead of Swift), and I assume this will be faster than AppleScript. If this increases the popularity of writing scripts, then perhaps app-writers will improve their dictionaries.
I love AppleScript because whenever somebody asks, "Why don't they make programming languages more like English?" all you need to do is show them AppleScript.
The functionality exposed by OSX apps via AppleScript is often incredible, but the language itself is annoying.
The question is whether or not applications will support it. With the emphasis shifting away from OSX desktop applications to cross-platform and cloud apps, will OSX app developers still take the time to expose scripting functionality?
> I love AppleScript because whenever somebody asks, "Why don't they make programming languages more like English?" all you need to do is show them AppleScript.
AppleScript is not a solid argument against natural language derived programming languages in general. AppleScript's problems have more to do with the fact that it looks like it should be flexible and powerful but in reality it is fairly limited and inflexible (and its documentation and error reporting are terrible, compounding its problems).
If anyone wants to do stuff similar to this on earlier versions of OS X (but arguably even more generally) or on iOS they should look at one of my projects, Cycript, an Objective-C/JavaScript hybrid with a highly-bridged Foundation/JavaScriptCore object model that can inject code into running applications.
(I expect to have the ability to introspect and manipulate Swift objects in the near future as well, and have a talk on preliminary research of low-level Swift object runtime metadata at #AltConf a couple days ago. The console will also support some of Swift's syntax, such as the named-argument-style method calls.)
Oh Javascript. This has been said so many times before, but why, oh why, has the world converged on this particular language?
Why aren't there saner alternatives to Javascript in browsers? We have so many languages at our disposal, why choose Javascript? Why don't people realize that web programming is not great because of Javascript but despite Javascript?
We are bound to Javascript on the web because browsers, for whatever reason, don't support anything else. But we don't have to make matters worse by dragging this weirdo language unto the rest of the programming world.
But who am I kidding, AppleScript may be one of the few languages actually worse than Javascript.
"Because JavaScript is the language of the web browser, and because the web browser has become the dominant application delivery system, and because JavaScript isn't too bad, JavaScript has become the World's Most Popular Programming Language. Its popularity is growing. It is now being embedded in other applications and contexts. JavaScript has become important.
A lot of people in this thread have misconceptions about what AppleScript is and what it means for JavaScript to be an alternative. I recommend watching the WWDC session [1] if you can, and skip to 16 minutes in (through minute 20) for a quick explanation of what this actually is.
TL;DR shell scripting for the GUI, not a way to build Mac applications (which you can already do with JS).
Edit: video link
Double edit: Looks like I'm slightly wrong about using JS to build apps this way. You can bundle scripts as applications, and OSA can create windows and controls, so you could hypothetically build whole apps this way. But I'm not sure I would want to.
Given Apple's well-known antipathy to the idea of browser engines other than WebKit and scripting languages other than JavaScript on iOS (yes, yes, I know you can find Python/Lua/Lisp/whatever apps on iOS; I mean as a general rule and for inter-app automation), could this be a prelude to allowing some sort of sandboxed-app automation interface on iOS? That is, allow a JavaScript implementation running on iOS to "drive" apps via this object model?
(Genuine question here. I have no idea whether I'm blowing smoke or whether this is a plausible long-term direction for Apple to take iOS.)
Genuine answer here. There's no need to apologize for not constantly immersing yourself in the workings of Apple platforms. :-)
JavaScript is just another interface to Apple's "Open Scripting Architecture (OSA)." Previously, AppleScript was the only way to use it. The fact that they added another language indicates nothing about whether OSA will ever come to iOS. My guess is it won't; the new extensions APIs will likely handle any inter-app communication Apple wants to allow, because they are designed with iOS's sandbox model in mind already.
Put another way, Javascript is to AppleScript with respect to OS X automation, as Scala is to Java on the JVM. The existence of Scala does not indicate that the JVM will be ported to the Haiku OS. (There may be a better analogy but that's what I came up with.)
Javascript in this case has nothing to do with web browsers. It is simply a scripting language used to manipulate OSA (Apple's cross-application automation API in Mac OS X). Since OSA is not part of iOS, this likely won't affect iOS at all.
You actually can use Javascript to automate iOS apps running in Instruments (one of Apple's developer tools). This is used for automated UI testing in the iOS simulator or while your iOS device is tethered to a Mac. This has been around for a couple years and there's no indication that it will ever be permitted in released applications. There's actually no reason to enable it – it's only useful for snooping on apps (good for developers, bad for users).
For developers, I think you can write ui automation tests in javascript for your own app during debugging/testing.
In the general case, for published apps, I'm not seeing it happen. Apple seems to be super focused on sandboxing and separating components on iOS. Even with the new iOS8 extensions, everything needs to be user triggered and even then, extensions live on separate islands.
It's doubtful they'll change that model since it would defeat the "you can't break your idevice even if you tried" feeling for end users and the app store.
so, I'm a little confused here - more than a year ago, the Gnome Project picked Javascript as its primary dev language and it was linked here on HN (https://news.ycombinator.com/item?id=5169599)
That entire thread is around how Javascript is a bad paradigm for desktop. But, this entire thread is how amazing javascript is going to be for OSX.
Let me add that the JS programming model of Gnome is what powers http://extensions.gnome.org - and I have my own extensions in there. Also (and correct me if I'm wrong) the "GObject Introspection" mechanism is fairly analogous to OSA.
So, is there a underlying technical or implementation issue that makes it good on OSX and bad on Gnome ? use case? technology ? OSA ?
Applescript is used for automation of already existing applications which will still be written in C++ or Objective C. Applescript, a proprietary language with no other uses, is just being replaced by a much more common language in Javascript so people won't need to learn a new one to automate apps. People don't generally write applications using Applescript and they probably won't be using Javascript, so there's little overlap.
In GNOME Javascript is being used to write the applications in the first place. There is total overlap between Javascript and C/C++.
People see the GNOME choice as both redundant and reducing performance of desktop apps while people see the Apple choice as simply using a common language instead of a proprietary one for scripting.
The thing i'm not totally sold on is that for arg-free alloc/inits, you can forego 'calling' those methods at all so you get code like `task = $.NSTask.alloc.init;` but sometimes you have code like `ObjC.super(this).init;`. So although you're actually initializing a new object, casually glancing through the code makes it seem that you're actually just accessing a property on NSClassName. Jstalk/cocoascript i think get this right with `NSWhatever.alloc().init()`.
Still, it's a bit weird and it makes me think that the poor folks working on this didn't know what the swift folks were doing because if they had, i suspect that the cocoa-bridged syntax would feel even more natively javascripty than it does right now rather than what's here. For comparison
// in swift
var color = UIColor(red: 0.61, green: .71, blue: .23, alpha: .8)
// in js for automation
var color = $.UIColor.colorWithRedGreenBlueAlpha(.61, .71, .23, .8);
// but why not use objs for named args?
var color = $.UIColor({red: 0.61, green: .71, blue: .23, alpha: .8})
Of the two, the swift feels the most js-native to me because you can easily hallucinate the {}s from the third example. But even if you're creating a js bridge and you're apple, why even force people to deal with alloc/init anymore? Even the registerSubclass syntax feels like a concession
Don't get me wrong, I think it's great that we're getting better applescript support via js, but it's definitely an area where the implementation feels like a step back from cocoascript and jstalk, at least with both of those the syntax highlighted when you were engaging in nonidiomatic behavior but at least both tried their best to paper over it.
What should have been a lightweight approach actually feels more heavyweight than writing equivalent code in swift instead, which makes me sad because i like js and i would have really liked for this to have been more approachable.
Because then there is no way of conveying the order of the parameters. In this case, it's ambiguous whether the method we are calling is colorWithRedGreenBlueAlpha, colorWithGreenBlueRedAlpha, etc.
I'm going to miss AppleScript - in both obvious senses of the word. It was a language I used to swear by, and at. I spent hours getting scripts to work, so I've became used to the language's infelicities, but was always frustrated by the lack of tools. Here, for example, is how I gather you're supposed to change the case of a string:
on change_case(this_text, this_case)
if this_case is 0 then
set the comparison_string to "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
set the source_string to "abcdefghijklmnopqrstuvwxyz"
else
set the comparison_string to "abcdefghijklmnopqrstuvwxyz"
set the source_string to "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
end if
set the new_text to ""
repeat with this_char in this_text
set x to the offset of this_char in the comparison_string
if x is not 0 then
set the new_text to (the new_text & character x of the source_string) as string
else
set the new_text to (the new_text & this_char) as string
end if
end repeat
return the new_text
end change_case
I'm assuming that this will be easier using JavaScript... :)
There has been no statement that AppleScript is going away or being replaced by JavaScript for Automation. This is simply a case of offering users more choices.
AppleScript’s primary target audience is first-time and casual programmers. (Of course, there are professional programmers writing applications and utilities in AppleScript, too.)
You know what's pretty cool? This potentially allows native MacOS applications to be written in JavaScript... Not that I can see any reason to do that.
You can build double-clickable "applets" in AppleScript and JavaScript, but the OSA interface isn't really made for app development, just automation.
However, they do expose all Cocoa and Obj-C APIs to JavaScript, so anything is possible! They even do a demo of a standalone temperature converter at the end of the WWDC session.
As an aside: if you want to use JS /today/ as an OSX Window Manager (hotkeys, resizing, switch screen etc), you should check out:
https://github.com/sdegutis/Phoenix
I've been using it for a couple of months now, and it's been glorious! So being able to do more things in JS makes me very excited.
The problem with AppleScript isn't so much the language as much as the OSA[1] itself which is really hit-or-miss depending upon how much functionality any particular app chooses to make scriptable, much less actually document in its dictionary.
As to AppleScript's deficiencies, in the past I've used py-appscript[2], though apparently it's no longer developed.
> Scripting additions (plugins for scripts) can be used to enhance the functionality of applications. The OS has a set of standard scripting additions available. These offer things like speaking text and user interaction dialogs.
I was watching the talk and thinking all the time, Apple just discovered OLE Automation.
Yes, I know that Open Scripting Architecture is also quite old, but having now JavaScript bindings and the types of demos they made, just reminded me of it.
Does this mean AppleScript will actually be documented now? The problem historically has been code is written from random examples, without actual reference docs that make it possible to discover what's available.
Not sure why people would still want to use JavaScript to interoperate with Cocoa interfaces, Swift is easy enough to be used as a scripting language and it was designed to work nicely with Cocoa.
To me it makes more sense to either go completely native with Swift and Cocoa / Cocoa Touch or use hybrid model where HTML 5 content is embedded with the new WKWebView API (aka WebKit 2).
WebKit 2 framework will become public in iOS 8 and OS X 10.10 which means hybrid HTML5/Native apps will be able to run with full speed thanks to JIT, split process model and other optimisations.
The one thing I still like about AppleScript is the GUI scripting. I don't know of any other way to control the mouse position, clicking, and keyboard input using a programming language.
One time I had to fill out a few thousand pdf files and print only select pages from them (like pages 2-4 and 14-22) for a client. I used applescripting because it was easy to write (took about half an hour) and worked consistently. Are there any other ways to do GUI scripting in OSX?
If I were a Mac user I could really get behind this if only for the fact that it means support for any language that can compile to Javascript (particularly Clojure)
[+] [-] mbauman|11 years ago|reply
In the same cycle that they release a brand new language, they begin the deprecation process for their (only?) other proprietary programming language in favor of an existing language. Pretty cool.
[+] [-] sriku|11 years ago|reply
edit: Back in 1998/99, I even wrote a web server entirely in AppleScript - it was a platform for our research lab to share, debate and record ideas.
[+] [-] judk|11 years ago|reply
[+] [-] hrktb|11 years ago|reply
For instance most of the Adobe product don't care about OSA and offer a Lua extension mechanism instead (even there, I feel they only cared avout filters and publishing modules). Or even iPhoto had severe limitations on what could be done through the scripting interface.
The Finder has perhaps the most useful interface, but anything done there can also be done in the shell IMO. There must be other apps exposing very useful functionalities to OSA, but I haven't see many.
[+] [-] gcanyon|11 years ago|reply
Switching to JavaScript will do exactly zero to fix that. However, there appears to be new functionality inherent in the implementation, including better integration of native code (oddly, the examples are in ObjC instead of Swift), and I assume this will be faster than AppleScript. If this increases the popularity of writing scripts, then perhaps app-writers will improve their dictionaries.
[+] [-] JohnBooty|11 years ago|reply
The functionality exposed by OSX apps via AppleScript is often incredible, but the language itself is annoying.
The question is whether or not applications will support it. With the emphasis shifting away from OSX desktop applications to cross-platform and cloud apps, will OSX app developers still take the time to expose scripting functionality?
[+] [-] bla2|11 years ago|reply
Yup :-) AppleScript has an interesting history, it used to support multiple "natural languages" (such as French, ...) in addition to English: http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf
(This is probably why many AppleScript Guides still say "English Dialect" on the first page, e.g. http://download.info.apple.com/Apple_Support_Area/Manuals/se... )
Here's a Dijkstra rant from '77 against natural language programming: http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667....
[+] [-] gilgoomesh|11 years ago|reply
[+] [-] Camillo|11 years ago|reply
[+] [-] coderzach|11 years ago|reply
[+] [-] saurik|11 years ago|reply
http://www.cycript.org/
(I expect to have the ability to introspect and manipulate Swift objects in the near future as well, and have a talk on preliminary research of low-level Swift object runtime metadata at #AltConf a couple days ago. The console will also support some of Swift's syntax, such as the named-argument-style method calls.)
https://www.youtube.com/watch?v=Ii-02vhsdVk
[+] [-] jevinskie|11 years ago|reply
Will Cycript work on 10.10 or are you just saying that you'll have two JS choices now (Cycript and JS Automation)?
I use Substrate all the time, I really need to look into Cycript! =)
[+] [-] Derbasti|11 years ago|reply
Why aren't there saner alternatives to Javascript in browsers? We have so many languages at our disposal, why choose Javascript? Why don't people realize that web programming is not great because of Javascript but despite Javascript?
We are bound to Javascript on the web because browsers, for whatever reason, don't support anything else. But we don't have to make matters worse by dragging this weirdo language unto the rest of the programming world.
But who am I kidding, AppleScript may be one of the few languages actually worse than Javascript.
[+] [-] yoklov|11 years ago|reply
Honestly, I find web programming to be generally terrible. JavaScript is actually one of the better parts of it.
Most of the time I work in C++ these days though.
[+] [-] facepalm|11 years ago|reply
Which language would be preferable? Perhaps Lua? Not much else with comparable simplicity comes to mind.
[+] [-] pixelmonkey|11 years ago|reply
It is better to be lucky than smart."
- Douglas Crockford, 2008
[+] [-] gvargh|11 years ago|reply
[+] [-] stevejohnson|11 years ago|reply
TL;DR shell scripting for the GUI, not a way to build Mac applications (which you can already do with JS).
Edit: video link
Double edit: Looks like I'm slightly wrong about using JS to build apps this way. You can bundle scripts as applications, and OSA can create windows and controls, so you could hypothetically build whole apps this way. But I'm not sure I would want to.
[1]: https://developer.apple.com/videos/wwdc/2014/#306
[+] [-] eknkc|11 years ago|reply
[+] [-] cstross|11 years ago|reply
Given Apple's well-known antipathy to the idea of browser engines other than WebKit and scripting languages other than JavaScript on iOS (yes, yes, I know you can find Python/Lua/Lisp/whatever apps on iOS; I mean as a general rule and for inter-app automation), could this be a prelude to allowing some sort of sandboxed-app automation interface on iOS? That is, allow a JavaScript implementation running on iOS to "drive" apps via this object model?
(Genuine question here. I have no idea whether I'm blowing smoke or whether this is a plausible long-term direction for Apple to take iOS.)
[+] [-] stevejohnson|11 years ago|reply
JavaScript is just another interface to Apple's "Open Scripting Architecture (OSA)." Previously, AppleScript was the only way to use it. The fact that they added another language indicates nothing about whether OSA will ever come to iOS. My guess is it won't; the new extensions APIs will likely handle any inter-app communication Apple wants to allow, because they are designed with iOS's sandbox model in mind already.
Put another way, Javascript is to AppleScript with respect to OS X automation, as Scala is to Java on the JVM. The existence of Scala does not indicate that the JVM will be ported to the Haiku OS. (There may be a better analogy but that's what I came up with.)
[+] [-] nexuist|11 years ago|reply
[+] [-] gilgoomesh|11 years ago|reply
You actually can use Javascript to automate iOS apps running in Instruments (one of Apple's developer tools). This is used for automated UI testing in the iOS simulator or while your iOS device is tethered to a Mac. This has been around for a couple years and there's no indication that it will ever be permitted in released applications. There's actually no reason to enable it – it's only useful for snooping on apps (good for developers, bad for users).
[+] [-] 0x0|11 years ago|reply
In the general case, for published apps, I'm not seeing it happen. Apple seems to be super focused on sandboxing and separating components on iOS. Even with the new iOS8 extensions, everything needs to be user triggered and even then, extensions live on separate islands.
It's doubtful they'll change that model since it would defeat the "you can't break your idevice even if you tried" feeling for end users and the app store.
[+] [-] sandGorgon|11 years ago|reply
That entire thread is around how Javascript is a bad paradigm for desktop. But, this entire thread is how amazing javascript is going to be for OSX.
Let me add that the JS programming model of Gnome is what powers http://extensions.gnome.org - and I have my own extensions in there. Also (and correct me if I'm wrong) the "GObject Introspection" mechanism is fairly analogous to OSA.
So, is there a underlying technical or implementation issue that makes it good on OSX and bad on Gnome ? use case? technology ? OSA ?
[+] [-] belandrew|11 years ago|reply
Applescript is used for automation of already existing applications which will still be written in C++ or Objective C. Applescript, a proprietary language with no other uses, is just being replaced by a much more common language in Javascript so people won't need to learn a new one to automate apps. People don't generally write applications using Applescript and they probably won't be using Javascript, so there's little overlap.
In GNOME Javascript is being used to write the applications in the first place. There is total overlap between Javascript and C/C++.
People see the GNOME choice as both redundant and reducing performance of desktop apps while people see the Apple choice as simply using a common language instead of a proprietary one for scripting.
[+] [-] nsfmc|11 years ago|reply
Still, it's a bit weird and it makes me think that the poor folks working on this didn't know what the swift folks were doing because if they had, i suspect that the cocoa-bridged syntax would feel even more natively javascripty than it does right now rather than what's here. For comparison
Of the two, the swift feels the most js-native to me because you can easily hallucinate the {}s from the third example. But even if you're creating a js bridge and you're apple, why even force people to deal with alloc/init anymore? Even the registerSubclass syntax feels like a concessionDon't get me wrong, I think it's great that we're getting better applescript support via js, but it's definitely an area where the implementation feels like a step back from cocoascript and jstalk, at least with both of those the syntax highlighted when you were engaging in nonidiomatic behavior but at least both tried their best to paper over it.
What should have been a lightweight approach actually feels more heavyweight than writing equivalent code in swift instead, which makes me sad because i like js and i would have really liked for this to have been more approachable.
[+] [-] bobbyi_settv|11 years ago|reply
Because then there is no way of conveying the order of the parameters. In this case, it's ambiguous whether the method we are calling is colorWithRedGreenBlueAlpha, colorWithGreenBlueRedAlpha, etc.
[+] [-] cormullion|11 years ago|reply
on change_case(this_text, this_case) if this_case is 0 then set the comparison_string to "ABCDEFGHIJKLMNOPQRSTUVWXYZ" set the source_string to "abcdefghijklmnopqrstuvwxyz" else set the comparison_string to "abcdefghijklmnopqrstuvwxyz" set the source_string to "ABCDEFGHIJKLMNOPQRSTUVWXYZ" end if set the new_text to "" repeat with this_char in this_text set x to the offset of this_char in the comparison_string if x is not 0 then set the new_text to (the new_text & character x of the source_string) as string else set the new_text to (the new_text & this_char) as string end if end repeat return the new_text end change_case
I'm assuming that this will be easier using JavaScript... :)
[+] [-] turingcar|11 years ago|reply
AppleScript’s primary target audience is first-time and casual programmers. (Of course, there are professional programmers writing applications and utilities in AppleScript, too.)
[+] [-] matthewmacleod|11 years ago|reply
[+] [-] stevejohnson|11 years ago|reply
While you're correct that JS can now be used to write Mac applications without an Obj-C wrapper, that's not really the point of this.
Anyway, you can already write Mac applications in JavaScript. And iOS applications! This has been true since iOS 7 and Mavericks. http://strongloop.com/strongblog/apples-ios7-native-javascri...
You can build double-clickable "applets" in AppleScript and JavaScript, but the OSA interface isn't really made for app development, just automation.
However, they do expose all Cocoa and Obj-C APIs to JavaScript, so anything is possible! They even do a demo of a standalone temperature converter at the end of the WWDC session.
https://developer.apple.com/videos/wwdc/2014/#306
[+] [-] Nemcue|11 years ago|reply
I've been using it for a couple of months now, and it's been glorious! So being able to do more things in JS makes me very excited.
[+] [-] js2|11 years ago|reply
As to AppleScript's deficiencies, in the past I've used py-appscript[2], though apparently it's no longer developed.
1. https://developer.apple.com/library/mac/documentation/apples...
2. http://appscript.sourceforge.net/py-appscript/index.html
[+] [-] ChrisAntaki|11 years ago|reply
app.say('This is exciting')
[+] [-] radio4fan|11 years ago|reply
I used work for a living in AppleScript nearly 20 years ago. Heavy drinking helps block out the memories.
[+] [-] pjmlp|11 years ago|reply
Yes, I know that Open Scripting Architecture is also quite old, but having now JavaScript bindings and the types of demos they made, just reminded me of it.
[+] [-] tedchs|11 years ago|reply
[+] [-] jarek-foksa|11 years ago|reply
To me it makes more sense to either go completely native with Swift and Cocoa / Cocoa Touch or use hybrid model where HTML 5 content is embedded with the new WKWebView API (aka WebKit 2).
WebKit 2 framework will become public in iOS 8 and OS X 10.10 which means hybrid HTML5/Native apps will be able to run with full speed thanks to JIT, split process model and other optimisations.
[+] [-] vinalia|11 years ago|reply
One time I had to fill out a few thousand pdf files and print only select pages from them (like pages 2-4 and 14-22) for a client. I used applescripting because it was easy to write (took about half an hour) and worked consistently. Are there any other ways to do GUI scripting in OSX?
[+] [-] willismichael|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]