This is a fantastic write-up of a truly monumental effort. I have huge respect for the author's persistence. The line "Like gardening, but with more segfaults" really resonates. It’s this kind of deep-dive hobby project where you learn the most.
The experience with `c2rust` is particularly interesting. It reminds me of a similar shift I saw years ago with automatic code translators between other languages. They're incredible for getting a project off the ground and proving feasibility, just as the author found, but you often end up with code that's completely "un-idiomatic" for the target language. The decision to throw it all away and do a manual port, while surely gut-wrenching, was the right call. You just can't automatically translate the intent of the original C code into safe, idiomatic Rust.
The "Interesting Bugs" section gave me flashbacks. Bug #2, with the mismatched struct layout due to a missing `*`, is a classic FFI (Foreign Function Interface) nightmare. I once spent the better part of a week debugging a similar issue between C++ and C# where a single change in struct packing alignment was silently corrupting data downstream in very subtle ways. It's one of those bugs that makes you question your sanity. Finding that requires some serious debugging grit, so kudos to the author.
This project is a great case study in the real-world challenges of modernizing critical infrastructure code. The author mentions the next big goal is to convert the codebase from `unsafe` to safe Rust. I'm really curious about the strategy for that.
Refactoring away the raw pointers and complex control flow (like the `goto` patterns) into safe, idiomatic Rust without breaking everything seems like it would be even more challenging than the initial port. Will the approach be to introduce lifetimes and the borrow checker module-by-module? And what's the plan for the intrusive data structures? Replacing them with standard library collections like `BTreeMap` is the obvious choice, but I wonder if that will have performance implications that the original intrusive design was meant to avoid.
In any case, amazing work. Thanks for sharing the journey in such detail. I'll be following this project on GitHub for sure.
I'm sorry chickenzzzzu, I'm afraid I can't do that.
Please enter new payment information
I've seen things you people wouldn't believe
This person built a really cool project and documented how and you're throwing negative predictions about it for no reason. No one is down voting your opinions on OpenBSD
You’re probably being downvoted because the author ended up not using c2rust.
This announcement has my attention.
I've been working on a Rust-based tmux session manager called rmuxinator (i.e. tmuxinator clone) for a few years now. It (mostly) works and been slow going because ... life but I've recently picked it back up to fix some bugs. One of the last new features I'd added was the ability to use rmuxinator as a library in other Rust programs. I'd like to try forking tmux-rs, adding rmuxinator as a dependency and seeing if it would ... just work as a way to start sessions using per-project config files. I'm definitely not advocating for adding rmuxinator upstream but it would be very nice to have this sort of session templating baked into the "terminal multiplexer" itself.
The other interesting possibility I could foresee is doing things the other way around and having rmuxinator use tmux-rs as a library in order to setup and manage sessions instead of just dumping out shell commands -- which is fraught with edge cases. (Not sure if this is currently possible with tmux-rs, though.)
Once I wrap up the bugfixes I'm currently working on, I may fork this project and give one or both of the above a try.
Regardless, nice work by richardscollin!
> You might be asking: why did you rewrite tmux in Rust? And yeah, I don’t really have a good reason. It’s a hobby project. Like gardening, but with more segfaults.
I love this attitude. We don’t necessarily need a reason to build new things. Who knows what will come out of a hobby project. Thanks to the author for the great write up!
Also, my gardening is full of segfaults, coding a new project is definitely safer to my yard.
Completely agree. Not every project has to be out there to change the world.
I recently rewrote `fzf` [1] in Rust. Did I have any particular reason to do so? No, not really, regular `fzf` is fine, but I thought it would be a fun excuse to learn how fuzzy search algorithms work and how to exploit the channels in Rust. It was fun. There's no question that regular fzf is better but that wasn't the point, the point was to play with stuff and learn.
[1] https://github.com/Tombert/rs-fzf-clone
Nice, I do think fzf is a really good candidate for something that could be better if written in Rust. The fzy[1] C-rewrite is really fast, but I couldn't get it to give me as useful results when searching bash history.
[1] jhawthorn/fzy: :mag: A simple, fast fuzzy finder for the terminal https://share.google/TBp3pVaFngBTfaFyO
"Gardening is the handiest excuse for being a philosopher."
- Ray Bradbury, Dandelion Wine
Honestly, I often hate how people ask "why?", and don't understand how "for fun" is a legitimate answer. I get it for work or other things, but hobbies? We do lots of things for fun! Humans were born to play, just like every other animal. It's how we learn and explore the world around us.
And frankly, to quote Knuth
> In fact what I would like to see is thousands of computer scientists let loose to do whatever they want. That's what really advances the field.
This is true for any field, or any project. We're creative creatures. We dream and explore. Major changes almost never come from doing things the way they've always been done. A lot of times "just because" gives you the freedom to try new things and challenge those paradigms. Weirdly, if you always have to justify everything you slow down progress.
I still believe that my #1 think that stunted my growth as a junior SWE was overthinking my personal projects and languages to use for them, instead of just building whatever I felt it's interesting or intriguing to build.
Asking “why” can still be a legitimate question, and “for fun” can also be a legitimate answer.
I treat projects differently if they want to launch a product, they want to replace an established open source tool, done for fun for themselves, or if it’s a hobby project.
I suspect they do understand that "for fun" is a reasonable answer. The disconnect is probably that they don't see how your hobby could be fun.
There is more than 1 way to have fun. Some ways of having fun will produce more value to other people than others.
> Like gardening, but with more segfaults.
interesting, I'm new to rust. what are you doing that necessitates using unsafe?
A lot of things that C will let you do (even if you enter the realm of undefined behaviour) will simply not compile to C. As the author states, there are semantic differences between pointers and Rust's references.
C pointers can have as many owners as you want, may be subjected to mathematical operations, and can be cast to any type without even an error message. The compiler will just assume you know what you're doing. If you enable enough compiler warnings, it might warn you, but C compilers don't generate a lot of those by default.
Rust will let you only generate one mutable (exclusive) reference at a time. This means straight C to Rust ports simply don't compile.
By switching to pointers, which work pretty much like their C equivalent, you can port the code much easier, but you do of course lose the benefits of Rust's safety mechanisms, because most pointer operations throw away all the safety guarantee that Rust provides.
I suspect it's vastly easier to port C to unsafe Rust than to safe Rust.
I was about to post a snarky comment because I have a knee jerk reaction whenever someone implies a rust application is intrinsically better than C. Sometimes I forget people do things for fun.
I found out that quite funny, I wonder how many hours he spent on this. It seems extremely monotonous haha
Sometimes that's exactly what one needs. As long as there's not forced schedule for the work and you can do it when you want and at the pace that you want, it can feel good.
I think knitting looks monotonous, but I can see the appeal.
[deleted]
"We don't necessarily need a reason to build new things."
But tmux isn't new
Is a reason necessarily needed to rewrite software in other languages
GNU screen would like a word.
Maybe my understanding of one or more concepts involves is wrong, but that "more segfaults" bit confuses me. Shouldn't the rust compiler prevent code that can segfault from compiling? Unless there was a lot of unsafe blocks involved.
Edit: apparently it did turn out to be a lot of unsafe code
It's a transliteration. He's basically implemented a C program in Rust. He says in the conclusion the next goal is converting it to safe Rust.
In the second sentence he mentions:
> the code base is now 100% (unsafe) Rust
I didn't interpret that it's 100% unsafe, but I do expect that to mean there is probably a lot of unsafe blocks used. A good amount of the example code in the post alone is unsafe blocks as well.
My understanding is that, even though tmux-rs is written in a safer language, it still can't beat the stability of an old battle-tested well-maintained project written by a group of highly competent developers.
Every new project is bound to have bugs that need to be ironed out during the time.
Intuition and logic are the two halfs of reason (logos). We sometimes have a reason that we can't put into words (logos) but we know intuitively.
[deleted]
Looking forward to the tmux-c re-rewrite next
Not every code project needs to turn out to be world changing. Experiments like this sometimes produce excellent results.
[deleted]
> new things
Or copies of old things apparently.
I love this. I also want to dabble into loving things to rust!
Here I want to call out zellij. Zellij is rust based terminal multiplexer.
I am user not creator. I love everything rust and finding and migrating to rust based solutions where feasible.
Just curious. I'm a Rust developer. But I don't see myself discriminating between tools written in C, C++, Rust, Zig, etc. They all seem easy to install and use, as long as they're reasonably bugfree. Scripting languages are slightly different as they require me to maintain their respective interpreters and tools on my system. What difference do you see between applications written in Rust and those written in other compiled languages?
Very much a side note, but:
> my feeling is that I’d still reach for it if my hands are really physically hurting, and I need to keep working. Usually once I reach the point where I’ve got blisters on my fingers I think it’s better to just take a break
I'm dumbfounded, and impressed in an unhealthy way. Do some of you regularly type so much that you develop blisters?
Ever seen somebody type on a keyboard that learned on a typewriter?
I love the attitude on this project and most of the comments are supportive. While rewriting a mature application to another language always sounds like a bad idea, there are so many learnings along the way. It's not about the end it's about the process.
Given the traction you got here and the advancements in AI, I'm sure this can become a very attractive hobby project for Rust beginners, there's probably a lot of easy bugs to fix. Fixing bugs, adding new features, and optimizing the code is all you need.
Here's an idea to get the ball rolling: Create a scratch buffer for Gemini CLI (or your favorite LLM) and enable it to interact with the various windows and panes of the tmux session.
Here's my use case, I use synchronized panes to send the commands into multiple servers, but some commands sometimes fail for various reasons. What if I can just ask the AI to send a series of commands and react based on the output and adjust along the way. It's like a dynamically generated custom shell script on the fly.
I'm all for people doing whatever hobby project they want to do for learning and entertainment purposes. But I don't really understand the appeal of straight porting something from one language to another.
For example, I'm a daily gvim user. If I were going to do a hobby project text editor, I would emphatically not make a clone of gvim, I'd make a text editor with exactly the features I want that behaves exactly how I want. If you're going to invest that much time in a project, why not do something creative and unique?
Coincidentally I was just watching this, "Oxidise Your Command Line"
https://www.youtube.com/watch?v=rWMQ-g2QDsI
Some of that video is about stuff you have no use for if you're not a Rust developer, but, some of it is things that would be just as useful to anybody who is comfortable with, as it says, a command line interface.
I just ported tmux to Fil-C in less than an hour (that included porting libevent and gettings its test suite to pass).
Works great and it's totally memory safe
Would you mind porting graphviz to Fil-C ?
It's probably foolish, but I have the idée fixe that there's really no solid alternative for graphviz and dot (yes, there are UI versions, and mermaid and whatnot, but nothing that works on really big graphs and has the same expressivity), and I suspect that soon all the people that wrote graphviz will die off or retire. I like to see a port to a newer language as well, so ongoing maintenance will bercome easier.
Again, probably an idée fixe, and all is really well.
[deleted]
Did you experience a noticable performance degradation?
Surely improvements be made to c2rust to reduce the cited information loss with constant naming, to reduce the initial conversion burden?
Yeah, this seems like a huge missing feature for C2Rust. IIUC the main idea is to serve as a base for then porting to idiomatic Rust. But if you lose all of the constants that is a huge productivity loss.
> the code base is now 100% (unsafe) Rust
So the primary (or rather: only) reason for using Rust over C (memory safety) is out the window.
> I’d like to share the process of porting the original codebase from ~67,000 lines of C code to ~81,000 lines of Rust
And the codebase got bigger.
So yeah, as the author explains, hobby project, and kudos to that, but nothing that I will install on any box of mine any time soon.
Besides, applications like tmux would much rather be prime candidates for a rewrite in a garbage collected systems language (aka.; Go) than in Rust. tmux spends 99% of its time waiting for the user to hit a key, there is nothing performance critical in such an app that wouldn't be 100% adequately served by Go.
This is such a strange mindset. First of all, unsafe Rust is not comparable to C. It still has a lot of checks and balanced that C does not have. The author is also planning to make it more safe. And what do you mean "the primary reason"? The primary reason for this was to have fun. Let the man have fun.
> but nothing that I will install on any box of mine any time soon
Well, no one asked? I will never understand you chronically negative people that have to come in and whine about things that don't matter every time someone posts their fun little personal project that they made for fun. Have you tried being a little more positive? It makes life more enjoyable.
Just appalling. Someone publishes a post about their WIP project reaching an important milestone, and here comes the naysayers whining about the fact it's not finished yet.
Did you even the article? He clearly states his aims to convert it to safe rust. And for the code size, he clearly hasn't needed to optimize it yet and I don't think you necessarily want to code golf codebase like this.
> but nothing that I will install on any box of mine any time soon.
A little harsh. Rome wasn't built in a day.
This seems like an excellent future use case for a fully automated process by a large language model that translates a non-trivial C codebase to Safe Rust in under an hour with high accuracy. However, as the author noted, even after some attempts with Cursor at the end of development, the tool wasn't able to accelerate the translation effectively (in mid-2025). So while the potential is promising, it appears we're still some way off.
> This seems like an excellent future use case for a fully automated process by a large language model that translates a non-trivial C codebase to Safe Rust in under an hour with high accuracy.
That’s specific.
Nice, hope it will become cleaner code in time. I tried zellij multiple times but despite years of development it still misses many things tmux provides. Inability to show/hide status bar[1] is the most annoying.
[1] https://github.com/zellij-org/zellij/issues/694
You can't rebind key maps to its session manager plugin, making it a no-go since I bind the same key that the plugin uses to select a directory or something. Thus, I can't create new sessions through it, have to do it from the command line.
Nice, I like tmux, I use it daily, I live in it. I hope this version makes it easier to just scroll with the scroll wheel or ctrl-page-up/down, or ctrl tab through your panes, or just show the whole unconcatenated title in the bottom left ;)
Sorry I know this is not the place to complain, but it would be so nice!
I use byobu which is basically an opinionated distribution of tmux. Scroll wheel works fine, as does Alt-PgUp/PgDn.
Ctrl-Tab probably won't work because terminals tend not to recognize it as different from Tab. But you might be able to bind Alt-Tab or some other such combo to cycle through panes in the tmux config. It should just be a one-liner.
For me scroll wheel just works. The other stuff wouldn't be hard to configure with `bind-key`. I use ctrl-space to cycle through panes in a window:
bind-key -n C-Space select-pane -t +1
You might like zellij more than tmux.
Just launched StrangerMeet, a simple platform to chat anonymously with strangers via text — no signup needed. Inspired by the old-school internet randomness (think Omegle, but cleaner and focused on meaningful or just fun conversations). Would love your feedback — especially on performance, UX, and privacy concerns. It's super new (just 8 days live), so things might be a bit rough, but I'm improving it daily!
tmux has been used a lot of memory on my system, especially when scrolling buffer is large enough (I often have > 10k lines of things ).
I have often executed `pkill -9 tmux` and saved my day. I hope the rust version can help a bit here?
Tmux has configurable scrollback buffer size, maybe set-option -g history-limit something-smaller in your config?
How much is a lot? Even 10,000 lines of text should be on the order of megabytes, right?
I am using tmux with a 200,000 line history and have no issues.
Also, in 2017-2018 I contributed a few fixes for memory leaks related to buffer history, so make sure you are using a recent version.
> the code base is now 100% (unsafe) Rust
> ... It’s a hobby project. Like gardening, but with more segfaults.
From now on, it's like gardening, but in hell :-)
In "Interesting bugs / Bug 1",
I walked through the code again. Inside of the Rust function (*c).bar has a valid address, like 0x60302764, but out the function, the value received from the calling C code was 0x2764.
...
That’s right, the C code was using the implicit declaration which is:
int get_addr();
That explains why the value was incorrect! The C compiler was thinking a 4 byte int was returned not an 8 byte pointer. So the top 4 bytes were being truncated or ignored.
That's weird as an explanation. 0x60302764 is
4 bytes and 0x2764 is
2 bytes. Why would an address get truncated to 2 bytes? Is int 2-bytes according to any intermediate compilation stage? (Been at least 25 years since I saw int be 2 bytes, if ever).
Tmux is a gamechanger for me. Being able to start a dozen different projects with one line (using tmuxinator): the server, tailing logfiles, activating venvs, running the docker container, all within one line of code: Awesome. Hadn’t worked with it for years, just started again two days ago as I migrated from iTerm to Ghostty. And am loving the setup. Plus nvim. Pure awesomeness.
Looking forward to check out tmux-rs.
Surprised to hear you migrated from iTerm. It actually has a tmux integration mode (using -CC) that's awesome. You then don't have to remember any tmux specific shortcuts. Switching window is just Cmd+` just like everywhere else.
I entirely stopped using tmux when I couldn't use iTerm.
> I don’t really have a good reason. It’s a hobby project. Like gardening, but with more segfaults.
Love it. You definitively deserve your +350 points!
It's not my project, I saw that line and read the rest and thought it was interesting so I submitted it.
The author described the port as "100% unsafe rust". What would you expect?
> I’d like to share the process of porting the original codebase from ~67,000 lines of C
I was surprised to learn tmux had such a "large" codebase, where does the complexity come from?
Wonder if anyone has tried these over flourishing AI code assist tools to supercharge the speed these porting projects? If so, what's the experience has been?
OP said they tried cursor and didn't experience a speedup over their vi macros.
The author doesn't claim it, but worth stating explicitly: tmux is a security-critical piece of software that doesn't get the attention it deserves.
I don't understand mouse support in tmux. tmux works great, then when you need to enable mouse support, it takes over everything works horribly.
Slightly OT: it didn’t dawn on me until recently that terminal multiplier (like tmux) is a terminal itself.
And as a result, you could be running the greatest / fastest / most feature rich desktop terminal … but if your multiplier doesn’t support something - it hinders your fancy desktop terminal.
Short 3 min video explained by Ghostty creator
https://youtu.be/o-qtso47ECk
"Despite the generated code working, it was basically unmaintainable and 3x larger than the original C."
Which makes C2Rust seem pretty useless?
"I’ve recently reached a big milestone: the code base is now 100% (unsafe) Rust. I’d like to share the process of porting the original codebase from ~67,000 lines of C code to ~81,000 lines of Rust (excluding comments and empty lines)."
And yet somehow a hand-ported (and still unsafe) rewrite of a C program in Rust is still almost 20% larger?
If I recall, the Go gc compiler was automatically converted from 80K lines of C to 80K lines of Go. A hand-ported version would have been much smaller.
> Which makes C2Rust seem pretty useless?
It does what took him 6 months in seconds. Of course it isn't perfect, failing to keep the name of constants being an obvious flaw. But presumably with a few improvements you could then spend some of that 6 months cleaning up the code and still save time. Sounds like C2Rust is almost there, but not quite yet.
> And yet somehow a hand-ported (and still unsafe) rewrite of a C program in Rust is still almost 20% larger?
Size is not a very useful metric. But the port is still half-done. He has got it working in Rust, so now he is ready to do the "hard" part of the port and actually rewrite the "basically C" code into idiomatic Rust. That is where you expect to get safety improvements and hopefully more readable code.
I was searching the other day for a Tmux/Screen replacement in python, anyone?
Tmux is only 67k lines of C? That's surprisingly small.
How do people feel about tmux vs zellij?
Zellij has interesting ideas, but it has a ways to go. You can arbitrarily rebind the base modes and their actions, but you're F'd if those conflict with a plugin's, which seem to all have hardcoded key binds.
Great way to learn a new language!
the one thing i wish tmux supported was remote connections to several backend instances.
I started working on this feature about a month ago: https://github.com/snizovtsev/tmux (it's in early experiments, not ready for a try).
Luckily tmux has a well-established "control mode" protocol designed for iTerm2 that can serialize internal state updates into a stream of text messages. So I do write client-side of this feature right inside tmux.
When it's ready, you will able to embed remote sessions inside local tmux instance by calling something like "ssh example.com tmux -CC attach". It will auto-detect "control mode" escape sequence and create special "remote session" you can switch into.
If you are interested, connect with me (snizovtsev@gmail.com) so I will notify when feature is ready and ask for early testing before making upstream proposal.
Use tmuxinator to start multiple ssh/mosh connections.
You weren't really lying when you said "100% (unsafe) Rust" eh..
Next step slowly porting unsafe code to safe rust? lol
why is that funny? I’ve done exactly this (in a processional setting): c2rust to get something functional and then incrementally rewrote the code while producing unit tests (approval tests via insta are particularly handy). The end result was a codebase which was much easier to maintain, with much better tooling and tests.
> Usually once I reach the point where I’ve got blisters on my fingers I think it’s better to just take a break.
What a legend.
I like the initiative, but all this effort for ... unsafe Rust?
I know it's a hot topic, and I hope the end goal is to have a memory-safe (and faster) tmux. I just hope the author doesn't stop here :)
Edit: As pointed out below, I'm stupid, it's stated in the article and I didn't read that part
It's the first step in a two-step process:
1. Rewrite in (unsafe) Rust.
2. Update the code over time, moving towards safe Rust.
It's the old, "get it working
then fix it" process. In business that's normally a bad idea because you end up wasting more time than if you'd just done things correctly from the start
but for a hobby project it's fine. Because then you're more likely to learn something and possibly—ultimately—end up with a better end product.
To a business, time your developers spend learning things (the hard way) is wasted.
To a hobbyist, taking the time to learn things is time well-spent.
At the end of the article he states that the next step is to work toward safe Rust.
It's not exactly a stupid thought. My immediate reaction was: 1) 25% more LOC, 2) in unsafe Rust, 3) for a tool that already has great maintainence.
The only reason this is at the top of HN is because of where Rust is on the Gartner Hype Cycle right now.
It's neat, but I wouldn't say useful.
[deleted]
I like this post, one can learn a lot.
It seems automatically translating Rust to C is not a very good idea: "I threw away all of the C2Rust output and decided I would translate all of the files into Rust manually from C.". Neither seems doing it manually: "I introduced many bugs while translating the code. I’d like to share the process of discovering and fixing a couple." Or using AI: "That’s because when using cursor to translate the code it would still occasionally insert bugs, just like me. So, I spent as much time reviewing the generated code as it would have taken me to write it myself."
As a hobby project, all power to you. But otherwise, maybe better not rewrite working code....
> But otherwise, maybe better not rewrite working code....
Except that the eventual result allows for extension and improvements in a memory-safe language.
[deleted]
I'll take a rust tmux if it runs on Windows. I'm currently kind of stuck on Windows and I didn't realize how much tmux means to me until Bill took it away :(
Why are you stuck on Windows?
what is it with these re-implementations by different authors pinching the name of the original project?
you want to re-implement a well known project, fine
call it something else
That ship sailed right at the birth of open source. Just look at the number of different reimplementations of coreutils.
No I like the idea of appending "-rs", because it makes it much easier to filter out.
D.mn!
I was hoping for the announcement of a brand new bulletproof tmux-resurrect.
But no, it is (just) tmux-(recodedIn)rust.
rewriting old code in new language is the killer application for AI. should have used that instead of transpiler.
I love this, but the examples they show of their snippets are really, really not rust idiomatic.
Like they’ve basically thrown away all the rust patterns and just wrote a c program in rust (eg all the raw pointers)
LLM's are really good at translating one programming language into another.
In fact, I sometimes port code to another language and back just as a way to do code cleanup (or at least give ideas for things that could be cleaned up)
I wonder why OP didn't start from that as a starting point?
This is discussed in the article? They tried cursor, but the bug rate was no better than their manual effort, so at least in this context, it did not work out.
Because he didn't want to? He mentioned that for him, this is like a "gardening" project, so why take away the joy of programming just to become an AI operator?
I wonder if the tmux maintainers would be interested in switching to this?
Transitioning more software from C to Rust is a great idea.
My understanding is that tmux is primarily an OpenBSD project, and rust isn't a good fit for them (for reasons that summarize to portability problems), so it is extremely unlikely. Also, this is a hobby project that currently is all unsafe, so there's not even any particular point. (EDIT: Of course, as it gets rewritten the latter point is likely to diminish)
Seems like a bit entitled to expect being able to go around rewriting stuff and then have the old maintainers maintain it.
Taking a look at the source earlier, I'd guess probably not.
If you're going to move a project to rust, you'd want to actually make it look like rust. Currently it looks like C written in rust. That doesn't make anyone happy really.
(Obv. not a slight on the maintainer here, it's a personal project with a specific approach)
Interesting, this article and the comments make no mention of LLMs for the initial translation. Really surprising given that would be the first thing I'd reach for for a translation/porting task (though verification could get tricky).
Now I really wonder how a good model like Sonnet 4 would have performed.
Check the bottom :)
> I did start trying out Cursor towards the end of the development process. I ended up stopping using it though because I felt like it didn’t actually increase my speed. It only saved me from finger pain. That’s because when using cursor to translate the code it would still occasionally insert bugs, just like me. So, I spent as much time reviewing the generated code as it would have taken me to write it myself. The only thing it saved was my hands. Doing this large amount of refactoring is really hard on your fingers.
The people demand the AI angle.
It wouldnt have gotten 2% finishd. It wouldn't have compiled. Its a waste of time to even consider.
