> This shows Rubyterm running on my Ruby based WM, running Rubyterm with a text-based-backend that renders a a terminal to text (so it can run in any terminal), running my editor Re editing the Rubyterm example. The text is rendered using the pure-Ruby TrueType font renderer Skrift, and connected to my X11 server using the Pure-X11 Ruby X11 bindings
Thanks. I just re-targeted my editor to use this code to render using the text-based-backend or optionally using the X11 backend, so now I can layer the same renderer even more times...
Languages evolve. Nobody I know goes around bothering saying "terminal emulator". The last time I touched an X terminal was 30 years ago - I have no intention of bothering with the distinction.
Yeah, it's languished for years. I did a stint last autumn to get it to start passing more of Rubyspec, but haven't had time to take it further.
github.com/vidarh/writing-a-compiler-in-ruby
It's self-hosting apart from the GC (which is a sore spot - I really want to rewrite the GC in Ruby too), glibc for a handful of functions and syscalls, and using gas/ld to assemble and link.
No worries. My impression was, the premise of your articles was not (at least not initially) a compiler for a fullest Ruby with all of its intricacies, but rather showing a great technique how to tackle a problem. For me and few of my pals it was an inspiring eye-opener. We were coming from the 8bit era and had our hands dirty in assembly before, yet your approach showed we can do a lot of low-level stuff in a modern Unix setup.
Kudos for your work - and I guess you've had a lot of fun as well
Appreciate it. Yeah, you're right - when I started I didn't even plan on doing a Ruby compiler at all, just a compiler in Ruby. But I was also obsessing over the difficulty of compiling Ruby, and so was tempted to see how far it would get.
I'd really like to find time to pick it up again and clean it up and I'm toying with dynamic workflows in Claude now and might just have it set up one to "burn down" rubyspecs, as it did fairly well last autumn at fixing things, including adding bignum and beginnings of Regexp support.
Getting from working to usable and fast, though, would be a lot of work.
I find I have to specify this for some of these projects, because rewriting basic stuff like this often has a lot of people asking what the point is...
But I love small rewrites (this is <3k lines of code for the terminal itself; the font renderer is 600-700 lines or so; the X11 bindings a bit larger) as a means to explore what is really actually needed for the things I do...
> This shows Rubyterm running on my Ruby based WM, running Rubyterm with a text-based-backend that renders a a terminal to text (so it can run in any terminal), running my editor Re editing the Rubyterm example. The text is rendered using the pure-Ruby TrueType font renderer Skrift, and connected to my X11 server using the Pure-X11 Ruby X11 bindings
Cool
Thanks. I just re-targeted my editor to use this code to render using the text-based-backend or optionally using the X11 backend, so now I can layer the same renderer even more times...
https://en.wikipedia.org/wiki/Terminal_emulator, not https://en.wikipedia.org/wiki/X_terminal
Languages evolve. Nobody I know goes around bothering saying "terminal emulator". The last time I touched an X terminal was 30 years ago - I have no intention of bothering with the distinction.
I just connected the dots. You're the guy who constructed a direct Ruby-to-assembly compiler some time ago, right?
Yeah, it's languished for years. I did a stint last autumn to get it to start passing more of Rubyspec, but haven't had time to take it further.
github.com/vidarh/writing-a-compiler-in-ruby
It's self-hosting apart from the GC (which is a sore spot - I really want to rewrite the GC in Ruby too), glibc for a handful of functions and syscalls, and using gas/ld to assemble and link.
No worries. My impression was, the premise of your articles was not (at least not initially) a compiler for a fullest Ruby with all of its intricacies, but rather showing a great technique how to tackle a problem. For me and few of my pals it was an inspiring eye-opener. We were coming from the 8bit era and had our hands dirty in assembly before, yet your approach showed we can do a lot of low-level stuff in a modern Unix setup.
Kudos for your work - and I guess you've had a lot of fun as well
Appreciate it. Yeah, you're right - when I started I didn't even plan on doing a Ruby compiler at all, just a compiler in Ruby. But I was also obsessing over the difficulty of compiling Ruby, and so was tempted to see how far it would get.
I'd really like to find time to pick it up again and clean it up and I'm toying with dynamic workflows in Claude now and might just have it set up one to "burn down" rubyspecs, as it did fairly well last autumn at fixing things, including adding bignum and beginnings of Regexp support.
Getting from working to usable and fast, though, would be a lot of work.
> Why? Because I can.
Always the best reason.
I find I have to specify this for some of these projects, because rewriting basic stuff like this often has a lot of people asking what the point is...
But I love small rewrites (this is <3k lines of code for the terminal itself; the font renderer is 600-700 lines or so; the X11 bindings a bit larger) as a means to explore what is really actually needed for the things I do...
[dead]