Side note: If RSpec provides me a line in the stack trace that _isn't_ in a spec file, rtest will call that out saying "ERROR HERE" so that it's really obvious where to go fix your bug.
I just happened to be testing things at the moment where that wasn't the case.
That 2 line stack trace in the 2nd one? Those are the only 2 relevant lines from a 53 line RSpec stack trace that just spews into your terminal. Also, it's intentionally less bright, because _most_ of the time you don't care. The brighter lines have everything you need.
I dunno about you, but this makes my life SO much easier at work.
ok I'm giving up for the day. Been sitting in this office chair way too long.
Good progress though i think. Squashed all bugs that I'm aware of, and now I handle a number of RSpec edge cases I wasn't aware of before.
Still some improvements that can be made but... here are a couple screenshots of the next version of rtest of output.
just added a ticket to rtest to have an option for test output that is specifically designed to be read by a screen reader.
I need help. I need a developer who regularly has terminal output read to them by a screen reader to confirm some assumptions. It'd be great if they were a ruby developer but I don't think it really matters.
If you know one who might be willing to help, please have them poke me here or @masukomi on twitter.
decided to use the aws ruby gems for testing test failures.
have discovered here-to-fore unknown failure expressions in rspec because there's a LOT of metaprogramming going on in there that blows up in interesting ways when you introduce problems.
Making rtest better, but omg, I'm just trying to take a damn screenshot of a simple failure case with a _normal_ presentation and am failing miserably.
I went looking for a new test suite to break. Forgot to run bundler first. rtest had my back. I love it when you write a cool helpful feature, forget all about it, and then have it kick in and be like "No worries. I got you fam."
the hard part about working on a RSpec based tool turns out to be finding a repo that uses RSpec, has good test coverage, & has good tests.
I just broke this thing 2 ways and 1 somehow countered the other and resulted in no failures despite an "1 == 2" kind of test assertion I've added to make it fail. 🤦♀️
... that made it instantly clear which one to avoid. I was already uncomfortable about doing something that might somehow profit their CEO anyway. So yeah, downloading Vivaldi again for my tests.
I kicked the tires of the Orion browser (chromium). Had issues with 1Password which made it an insta-fail for me BUT it was fast, & I wasn't sure if it was just that i was back on my M1 mac, or that Chromium has pulled ahead of Firefox again. So, I wanted to test. "🤔Brave or Vivaldi?" I pondered then i saw this on Brave's site
Holy 💩I just realized it's not JUST blind folks who have trouble with the mere act of _reading_ regular expressions (neve-rmind interpreting them) but dyslexic people, and there are A LOT of dyslexic programmers out there. Swapping a character in a regexp isn't a stumble, it's a full on code breakage/bug or mis-comprehension!
let's fix this problem!
step 0: FIND LIKE MINDED GEEKS
I think i can do a decent job of defining a human readable DSL to describe regular expressions, BUT i think WE can do an _excellent_ job of defining this DSL.
If you're a geek who cares about regular expressions, and a geek who cares about accessibility, let's talk.
It doesn't matter if you have no interest in implementing it in Fennell / Lua / whatever. The really _critical_ part is defining the DSL.
step 2 would be to embed it in packages for various languages (either lua embedded or via porting) so that folks could use it directly for _all_ regexp in their project.
step 3 would be to actually try and convince some languages to add this as a standard way of writing regexp.
From an implementation standpoint I'm thinking a lisp/scheme is going to be easiest.
I _was_ going to suggest one that compiled to C to be ultra-portable, but now i'm wondering if using Fennell isn't a better solution, because Fennel compiles to Lua, lua can be embedded in everything AND most editors support Lua modules directly, and all support them indirectly AFAIK.
So, this could be a pair of functions that your editor called out to.
I'm thinking it would be _most_ useful if it was a standalone tool that you could invoke from whatever editor you use.
It would assume PCRE (Perl Compatible Regular Expressions) because that's the standard most languages have implemented.
You pass it PCRE and it spits out something like SRE (Scheme Regular Expressions) and vice versa.
I don't think SRE is the "right" expression but i think the core idea is good. I think use that as a starting point...
Holy crap. I just realized how _effing brutal_ it must be for a blind developer to listen to regular expressions being read to them.
I've been wanting to write a tool that'd allow transformation to and from something human readable like Scheme Regular Expressions https://srfi.schemers.org/srfi-115/srfi-115.html
now I realize there's actually a _need_ for something like that.