For some reason, not sure exactly since when (it wasn't always like this) but, when I want to write down NSDictionary, up to NSDi it is suggesting me NSDirectoryEnumerationSkipsSubdirectoryDescendants.
At what point designing the algorithm, which surely makes use of some NSDictionaries along the way, did the engineers at Apple think "Wow, this is really useful! I use NSDirectoryEnumerationSkipsSubdirectoryDescendants so often!"?
Is there some way to bring back some sanity to it?
You could give the Xcode Fuzzy Autocomplete plugin a whirl.
I recommend first installing Alcatraz, an Xcode package manager, which will allow you to easily enable and disable this plugin, not to mention discover other interesting ones.
Related
I want to clear the console
I tried using this, but it doesn't work for Windows
print!("\x1B[2J");
Is there an easy way to clear the console?
I think I need some clarification first, on what you're attempting to do. Regardless, this is my best attempt at answering your question <3
Preamble
Given that different terminals work differently and have different APIs, I think you probably will want to use a crate that provides this functionality in a cross-plaform manner.
I'm assuming from here on that you want cross-platform functionality and that you don't mind using external dependencies. If this is correct, you might be happy to know that the terminal interaction crates are actually really developed in the Rust ecosystem. I have heard only good things about them.
With that out of the way, let's move on.
Do you want to just perform actions on the terminal?
If you just want to perform some actions on the terminal, like "clearing", "scrolling", "moving the cursor" and whatnot, I think you will be satisfied with the terminal crate. It allows to perform many actions, like clearing, independently of the platform you're in. It also allows for using interactivity features like interacting with the Mouse and the Keyboard :3
Or do you want to write a GUI for the terminal?
If what you want to do is write a Console-based User Interface though, I think that what might work for you instead is the tui crate. It has all of what you need to build terminal GUIs, from clearing of the console up to graphical widgets. Tools like gitui are written with tui.
Did I answer your question? Feel free to follow up if I fell short :)
I've found a way to clear the console in rust
By using console crate, console.clear() method
I am trying to work with FranTK in order to make some examples to work for class. But cant go further the installation process (cabal install may be to mainstream).
I've gotten it from http://src.gnu-darwin.org/ports/x11-toolkits/hs-frantk/work/
in the readme a directory above it says i need to compile TclHaskellSrc, then FranSrc, then FranTkSrc. but i dont know how.
It also says it works with ghc-5, will it work with ghc-7?
has someone already use it successfully?
FRAN is outdated, bitrotted, and will almost certainly not compile under GHC 7. (See Conal Elliott's page for confirmation of this.) It was supposed to have been followed up with successors Reactive and FieldTrip, but, if I remember correctly, these projects hit a snag over OpenGL implementation issues.
If you're looking for good demos of FRP animation, then you'll be better off with one of the following:
elerea - it's simple, and has several good examples
sodium - also simple, and also has several good examples
reactive-banana - More complex than the other two, and more intended for GUI programming than for animation. Still worth a look, as it is well-documented and actively maintained.
The state of the art for FRP used to be Yampa, but I'd recommend against using either it or its recent fork Animas, not because they're bad in any way, but rather because they use Arrows, which tend to overcomplicate an already-difficult subject.
Hope this helps.
Old thread, I know, but Elm (elm-lang.org) has come along in the meantime. It compiles down the JavaScript, supports animations easily, and is under active development.
I started my career on Linux/Unix, and moved over to Windows and Visual Studio. XCode feels pretty alien to me. My feeling is that I'm not in control with XCode. It could be the case that I simply haven't understood how to use the IDE, I am new at developing for Apple OSs. One thing that kind of irks me, is that nobody seem to have found a clean way to compile for multiple platforms (iOS and Mac OS X), using the same sources. I've found two ways to "hack it", but the hacks sound fragile.
I've been pondering the idea of using simple make files instead of XCode (except for the occasional use of Interface Builder).
Is this a sane route to go? Has anyone done this? Are there any major drawbacks I need to be aware of before I take the leap, or should I just bite the bullet and wait for the enlightenment?
Use Xcode, use as many high-level tools as possible. The "loss of control" is replaced by more focus on the application, which IMHO is a great tradeoff.
It is kind of like the loss of control when I went from assembly code to "C", but it was worth it. We keep moving to higher level of abstraction and that allows us to accomplish more, focus on the big picture instead of the minor details.
You've just got to learn new ways of doing things. For example, in the situation you describe (building an OS X and iOS app with shared code), I'd put any shared code into a library/framework that is used by both projects, and create a workspace that contains all three projects.
The loss of control you speak of is offset by the fact that this can all be set up without knowing anything about compiler command-line options in around 10 minutes.
It's a different way of thinking, and it can be frustrating if you know how you would do it on a different platform, but there are advantages to both options. You may never have to think about the build process again!
I really love the look and feel of the new xcode (4). But, a friend and I wanted to see if there is any way we can do collaborative real-time editing (http://en.wikipedia.org/wiki/Collaborative_real-time_editor). Just like what you see when you use Google Docs to edit a word document with someone.
Also, could/is there (be) a plug in that should work with xcode for Real-time collaborative editing? Or anything of the like?
Thanks for the post back,
Throdne
As far as I know, there is no way to do this and since Xcode doesn't really support plugins, there is no way of live collaboration in Xcode. I would suggest to use Sub Etha Edit. As an editor for Objective C, it's obviously not as great as Xcode, but still, it does a pretty decent job and might serve you well in your setup.
I'm surprised no one has asked this yet. What's the best way (if any) to get a Vi experience in Xcode? I know about ViMate but TextMate doesn't come close to Xcode in terms of integration and code completion.
BTW, I am using Xcode 4.
You might want to try out xVim which seems to be an active project. The currently indicate that it works with XCode 4.2, Espresso and Chocolat. Presumably you could selectively enable it with other applications.
Here's another plugin which I made a few weeks ago.
http://programming.jugglershu.net/softwares/xvim.html
This is currently developed for personal (my) use. So you may feel bad with some lack of implementation. Give me a feed back(feature request) then. I'll add some keybinds if I have enough time.
The closest you'll get is http://www.corsofamily.net/jcorso/vi/, or configuring an external editor. This has been a long-standing deficiency with XCode. (If you ask any vi user that is..)
OSX and XCode in general favors Emacs key bindings.
More info on general key-binding strategy for OSX: http://hints.macworld.com/article.php?story=20060317045211408
Right now, I productively use XVim†. I'll probably try $20 ViCiOUS, which seems more polished; I like having source access to my tool-chain, but this is for Xcode, so c'mon me.
† Not xVim, which I just discovered, but apparently face down in the pool. In the [Xx][Vv]im namespace, Xvim (à la Xcode) would have made more sense to me. There, I said it.
Here's another choice: KeyRemap4MacBook.