Andy Nutter-Upham, I just realized I didn't answer this exact question by
you in full details (I read the original message on the phone while being
quite busy with something a couple of weeks ago, and I somehow missed some
of intricacies of your question):
"If I missed the documentation and someone knows where it is, I'd love to
read it. I think though that since this is a wrapper library there is
instead reference to the underlying documentation (whose method names are a
bit different, and whose arguments are a bit different) and I find that
translation very challenging; especially since glimmer-dsl-libui is not yet
complete, so your run into ineffective keywords if you rely on the
underlying glimmer docs."
Glimmer DSL for LibUI actually does have full documentation for the Ruby
API:
https://github.com/AndyObtiva/glimmer-dsl-libui#supported-keywords
Someone asked me to add the documentation early on when the project was
new, and I added it to that person's satisfaction. I hope it's helpful to
you too.
By the way, I also do mention under the "Original API" section that you
could use the LibUI Go documentation as a reference:
https://pkg.go.dev/github.com/andlabs/ui
But, the most complete reference is the actual C headers:
https://github.com/andlabs/libui/blob/master/ui.h
And, the C headers are exposed as low-level FFI functions in Ruby as per
the Original API (but it's not recommended that you use these method
directly of course):
https://github.com/AndyObtiva/glimmer-dsl-libui#original-api
To give you an example of how the mapping from the C API to Ruby happens,
suppose we have this C function:
uiWindowSetTitle('My Application')
The word before the "Set" or "Get" operation is the control object (e.g.
window), and the word after it is the attribute (e.g. title).
So, the equivalent of that in the Glimmer GUI DSL:
window {
title 'My Application'
}
Basically, we are declaring a window control with one nested attribute of
title having the value 'My Application'
The C API is procedural and imperative whereas the Glimmer GUI DSL is
object-oriented and declarative, better mapping to the way we think of
concepts visually while looking at a screen given that you could nest
controls (widgets) within each other.
If you need further help, do not hesitate to ask further questions at the
Glimmer Gitter chat:
https://app.gitter.im/#/room/#AndyObtiva_glimmer:gitter.im
You shouldn't really get bogged down unless you are missing foundational
grounding in software engineering concepts relating to desktop development
in general, like MVC (Model View Controller). I've done GUI development
professionally in older technologies like Java Swing in the past, and by
comparison, Glimmer lets me leapfrog past productivity by 4x at least,
sometimes 10x or even more (and it's that much faster in productivity than
web development too, so it's great for building quick local apps or tools
that don't need the web as it's much simpler, demanding a tiny fraction of
web code only). But, it does assume you know MVC (Model View Controller)
very well, and it benefits from also knowing MVP (Model View Presenter).
Once you get the main ideas behind Glimmer, everything clicks, and things
like exact APIs or detailed documentation wouldn't matter much anymore
because the way you think with MVC/MVP is you start with the View layer
from a GUI mockup to support a specific user workflow, and you either use
native controls (like text and button, by looking them up in examples or
the docs mentioned above) or you invent your own custom controls (both
options are available in Glimmer DSL for LibUI). Of course, the native
controls are only as complete as what is implemented by the underlying
LibUI library. I know the authors of it are working on adding many new
features, like a Tree control, Table sorting listeners, and some other
missing features. They will all be added to Glimmer DSL for LibUI in due
time when they get released in C LibUI. But, that shouldn't stop someone
from learning the library and using whatever is available in it for now, or
at least mastering the current features until more features are added in
the future (especially given that you could always temporarily polyfill
missing features by building your own custom controls if really needed).
Cheers,
Andy Maleh
On Tue, Feb 14, 2023 at 9:27 PM grigoris charam <xargrigoris(a)gmail.com>
wrote:
> Stop reply all
>
> On Feb 15, 2023, at 03:05, Andy Maleh via ruby-talk <
> ruby-talk(a)ml.ruby-lang.org> wrote:
>
>
> The Glimmer Gitter Chat:
>
> https://app.gitter.im/#/room/#AndyObtiva_glimmer:gitter.im
>
> If you create any Glimmer related projects, libraries, or tools, you could
> alert of us of them in the Gitter Chat.
>
> And, you can open issues or pull requests on any of the Glimmer projects
> if needed:
> <glimmer.png>
> AndyObtiva/glimmer: DSL Framework consisting of a DSL Engine and a
> Data-Binding Library used in Glimmer DSL for SWT (JRuby Desktop Development
> GUI Framework), Glimmer DSL for Opal (Pure Ruby Web GUI), Glimmer DSL for
> LibUI (Prerequisite-Free Ruby Desktop Development GUI Library), Glimmer DSL
> for Tk (Ruby Tk Desktop Development GUI Library), Glimmer DSL for GTK
> (Ruby-GNOME Desktop Development GUI Library), Glimmer DSL for XML (& HTML),
> and Glimmer DSL for CSS <https://github.com/AndyObtiva/glimmer>
> github.com <https://github.com/AndyObtiva/glimmer>
> <https://github.com/AndyObtiva/glimmer>
>
>
> Andy Maleh
>
>
> LinkedIn: https://www.linkedin.com/in/andymaleh
> <https://www.linkedin.com/in/andymaleh>
> Blog: https://andymaleh.blogspot.com
> GitHub: https://github.com/AndyObtiva
> Twitter: https://www.twitter.com/AndyObtiva
>
> On Feb 14, 2023, at 7:51 PM, Fellipe Fingoli via ruby-talk <
> ruby-talk(a)ml.ruby-lang.org> wrote:
>
>
> really good content! I want to help to develop this ecosystem. Does
> anybody know where I can reach the community?
>
> Em ter., 7 de fev. de 2023 às 18:29, Andy Maleh via ruby-talk <
> ruby-talk(a)ml.ruby-lang.org> escreveu:
>
>> My RubyConf 2022 talk video on "Building Native GUI Apps in Ruby" using
>> the Fukuoka Award Winning Glimmer DSL for LibUI has just been released!
>>
>> https://youtu.be/1Bh4CnJqHyY
>>
>> Andy Maleh
>>
>> LinkedIn: https://www.linkedin.com/in/andymaleh
>> <https://www.linkedin.com/in/andymaleh>
>> Blog: http://andymaleh.blogspot.com
>> GitHub: http://www.github.com/AndyObtiva
>> Twitter: @AndyObtiva <https://twitter.com/AndyObtiva>
>>
>> ______________________________________________
>> ruby-talk mailing list -- ruby-talk(a)ml.ruby-lang.org
>> To unsubscribe send an email to ruby-talk-leave(a)ml.ruby-lang.org
>> ruby-talk info --
>> https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-talk.ml.ruby-lang.or…
>
>
>
> --
> Fellipe Fingoli
> ______________________________________________
> ruby-talk mailing list -- ruby-talk(a)ml.ruby-lang.org
> To unsubscribe send an email to ruby-talk-leave(a)ml.ruby-lang.org
> ruby-talk info --
> https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-talk.ml.ruby-lang.or…
>
> ______________________________________________
> ruby-talk mailing list -- ruby-talk(a)ml.ruby-lang.org
> To unsubscribe send an email to ruby-talk-leave(a)ml.ruby-lang.org
> ruby-talk info --
> https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-talk.ml.ruby-lang.or…
>
>
--
Andy Maleh
LinkedIn: https://www.linkedin.com/in/andymaleh
<https://www.linkedin.com/in/andymaleh>
Blog: http://andymaleh.blogspot.com
GitHub: http://www.github.com/AndyObtiva
Twitter: @AndyObtiva <https://twitter.com/AndyObtiva>
oedipus_lex version 2.6.1 has been released!
* home: <http://github.com/seattlerb/oedipus_lex>
* rdoc: <http://docs.seattlerb.org/oedipus_lex>
Oedipus Lex is a lexer generator in the same family as Rexical and
Rex. Oedipus Lex is my independent lexer fork of Rexical. Rexical was
in turn a fork of Rex. We've been unable to contact the author of rex
in order to take it over, fix it up, extend it, and relicense it to
MIT. So, Oedipus was written clean-room in order to bypass licensing
constraints (and because bootstrapping is fun).
Oedipus brings a lot of extras to the table and at this point is only
historically related to rexical. The syntax has changed enough that
any rexical lexer will have to be tweaked to work inside of oedipus.
At the very least, you need to add slashes to all your regexps.
Oedipus, like rexical, is based primarily on generating code much like
you would a hand-written lexer. It is _not_ a table or hash driven
lexer. It uses StrScanner within a multi-level case statement. As such,
Oedipus matches on the _first_ match, not the longest (like lex and
its ilk).
This documentation is not meant to bypass any prerequisite knowledge
on lexing or parsing. If you'd like to study the subject in further
detail, please try [TIN321] or the [LLVM Tutorial] or some other good
resource for CS learning. Books... books are good. I like books.
Changes:
### 2.6.1 / 2023-05-31
* 1 bug fix:
* Bumped minimum supported version of ruby to 2.7
Thanks for the input but I have not been able to improve the performance of
the generation by that much. The output did contain repeated sections that
I have cached to speed things up but the variability of the runtime is
quite insane. The average is 9.729 seconds which itself is not good but
there isn't even consistency in repeated calls with the same data
So perhaps there is another issue
Thanks for your help, it has been an interesting rabbit hole
On Thu, 18 May 2023 at 13:35, Ruby users (Avocadostore) <
support(a)avocadostore.zendesk.com> wrote:
> ##- Bitte geben Sie Ihre Antwort über dieser Zeile ein. -##
>
> Sie sind in dieser Supportanfrage (2001706) auf CC gesetzt. Antworten Sie
> auf diese E-Mail, um Kommentare zur Anfrage hinzuzufügen.
>
> *Ruby users*
>
> 18. Mai 2023, 14:35 MESZ
>
> For posterity, I've put the benchmark code and results from my previous
> email here:
>
> https://gist.github.com/flavorjones/4875b772b7517185913bded8e18b1ed5
>
> In case I didn't make it clear, using Nokogiri's Document API is faster
> than Builder and (unless you have benchmarks showing something else) I
> still recommend using it over rolling your own templating solution.
>
> On Thu, May 18, 2023 at 8:24 AM Peter Hickman via ruby-talk <
> ruby-talk(a)ml.ruby-lang.org> wrote:
>
> So far building it by hand is no faster than using builder. Which I'm
> going to see as a plus for builder because it sure is easier to read
>
> I think that the real issue is building a big string piecemeal is where
> the time is being spent
>
> -K0GVP]
>
> ______________________________________________
> ruby-talk mailing list -- ruby-talk(a)ml.ruby-lang.org
> To unsubscribe send an email to ruby-talk-leave(a)ml.ruby-lang.org
> ruby-talk info --
> https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-talk.ml.ruby-lang.or…
>
> *Peter Hickman*
>
> 18. Mai 2023, 14:24 MESZ
>
> So far building it by hand is no faster than using builder. Which I'm
> going to see as a plus for builder because it sure is easier to read
>
> I think that the real issue is building a big string piecemeal is where
> the time is being spent
>
> -K0GVP]
>
> *Ruby users*
>
> 18. Mai 2023, 14:18 MESZ
>
> If you want to optimize for speed, I'd recommend using Nokogiri, but not
> the Nokogiri::XML::Builder which will perform about as well as the Builder
> gem. Instead, use the lower-level Document and Node APIs.
>
> Here's some code showing equivalent document construction for Builder,
> Nokogiri::XML::Builder, and Nokogiri::XML::Document ... and a benchmark if
> it's helpful (higher numbers are better, it's iterations per second):
>
> ```ruby
> #! /usr/bin/env ruby
>
> require "bundler/inline"
>
> gemfile do
> source "https://rubygems.org"
> gem "builder"
> gem "nokogiri"
> gem "benchmark-ips"
> end
>
> require "builder"
> require "nokogiri"
> require "benchmark/ips"
>
> N = 100
>
> # using Builder::XmlMarkup, build an XML document representing attributes
> of a person
> def builder_person
> xml = Builder::XmlMarkup.new
> xml.people do |p|
> N.times do
> xml.person do |p|
> p.name "John Doe"
> p.age 42
> p.address do |a|
> a.street "123 Main Street"
> a.city "Anytown"
> end
> end
> end
> end
> end
>
> # using Nokogiri::XML::Builder, build an XML document representing
> attributes of a person
> def nokogiri_person
> Nokogiri::XML::Builder.new do |xml|
> xml.people do
> N.times do
> xml.person do |p|
> p.name "John Doe"
> p.age 42
> p.address do |a|
> a.street "123 Main Street"
> a.city "Anytown"
> end
> end
> end
> end
> end.to_xml
> end
>
> # use Nokogiri's bare API to build an XML document representing attributes
> of a person
> def nokogiri_raw_person
> xml = Nokogiri::XML::Document.new
> xml.root = xml.create_element("people")
> N.times do
> xml.root.add_child(xml.create_element("person")).tap do |p|
> p.add_child(xml.create_element("name", "John Doe"))
> p.add_child(xml.create_element("age", 42))
> p.add_child(xml.create_element("address")).tap do |a|
> a.add_child(xml.create_element("street", "123 Main Street"))
> a.add_child(xml.create_element("city", "Anytown"))
> end
> end
> end
> xml.to_xml
> end
>
> puts RUBY_DESCRIPTION
> # pp builder_person
> # pp nokogiri_person
> # pp nokogiri_raw_person
>
> Benchmark.ips do |x|
> x.report("builder") { builder_person }
> x.report("nokogiri") { nokogiri_person }
> x.report("nokogiri raw") { nokogiri_raw_person }
> x.compare!
> end
> ```
>
> ```
> ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]
> Warming up --------------------------------------
> builder 58.000 i/100ms
> nokogiri 49.000 i/100ms
> nokogiri raw 61.000 i/100ms
> Calculating -------------------------------------
> builder 541.580 (± 6.5%) i/s - 2.726k in 5.054535s
> nokogiri 451.127 (± 7.5%) i/s - 2.254k in 5.027192s
> nokogiri raw 681.437 (± 9.1%) i/s - 3.416k in 5.061582s
>
> Comparison:
> nokogiri raw: 681.4 i/s
> builder: 541.6 i/s - 1.26x slower
> nokogiri: 451.1 i/s - 1.51x slower
> ```
>
> On Thu, May 18, 2023 at 8:02 AM Austin Ziegler via ruby-talk <
> ruby-talk(a)ml.ruby-lang.org> wrote:
>
> I have never used the Rails builder interface for JSON or XML generation.
> It’s nice because it’s DSL-ish, but it needs to be executed.
>
> If your data can be templated, using ERB will be better. If it is more
> complex with attributes, look into restructuring it so that you can use
> Nokogiri. I’m not sure if Ox generates as well as parses, but it may also
> be an option.
>
> -a
>
> > On May 18, 2023, at 04:25, Peter Hickman via ruby-talk <
> ruby-talk(a)ml.ruby-lang.org> wrote:
> >
> >
> > I'm profiling some code to try and squeeze out performance. It takes a
> user query, reads data from the database and returned the result as XML
> >
> > I have tuned the code and database (checking the indexes, caching
> repeated calls etc) and what I am left with is that 95% of the call's
> runtime is building the XML. We are using builder because it is the
> standard / default for Ruby
> >
> > Using Ruby 3.0.2p107 as it is the default for Ubuntu 22.04
> >
> > Is there another, faster library for XML generation or will I be
> building this by hand?
> >
> > Any suggestions
> >
> > ______________________________________________
> > ruby-talk mailing list -- ruby-talk(a)ml.ruby-lang.org
> > To unsubscribe send an email to ruby-talk-leave(a)ml.ruby-lang.org
> > ruby-talk info --
> https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-talk.ml.ruby-lang.or…
> ______________________________________________
> ruby-talk mailing list -- ruby-talk(a)ml.ruby-lang.org
> To unsubscribe send an email to ruby-talk-leave(a)ml.ruby-lang.org
> ruby-talk info --
> https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-talk.ml.ruby-lang.or…
>
> *Ruby users*
>
> 18. Mai 2023, 14:02 MESZ
>
> I have never used the Rails builder interface for JSON or XML generation.
> It’s nice because it’s DSL-ish, but it needs to be executed.
>
> If your data can be templated, using ERB will be better. If it is more
> complex with attributes, look into restructuring it so that you can use
> Nokogiri. I’m not sure if Ox generates as well as parses, but it may also
> be an option.
>
> -a
>
> > On May 18, 2023, at 04:25, Peter Hickman via ruby-talk <
> ruby-talk(a)ml.ruby-lang.org> wrote:
> >
> >
> > I'm profiling some code to try and squeeze out performance. It takes a
> user query, reads data from the database and returned the result as XML
> >
> > I have tuned the code and database (checking the indexes, caching
> repeated calls etc) and what I am left with is that 95% of the call's
> runtime is building the XML. We are using builder because it is the
> standard / default for Ruby
> >
> > Using Ruby 3.0.2p107 as it is the default for Ubuntu 22.04
> >
> > Is there another, faster library for XML generation or will I be
> building this by hand?
> >
> > Any suggestions
> >
> > ______________________________________________
> > ruby-talk mailing list -- ruby-talk(a)ml.ruby-lang.org
> > To unsubscribe send an email to ruby-talk-leave(a)ml.ruby-lang.org
> > ruby-talk info --
> https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-talk.ml.ruby-lang.or…
> ______________________________________________
> ruby-talk mailing list -- ruby-talk(a)ml.ruby-lang.org
> To unsubscribe send an email to ruby-talk-leave(a)ml.ruby-lang.org
> ruby-talk info --
> https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-talk.ml.ruby-lang.or…
>
> *Ruby users*
>
> 18. Mai 2023, 10:25 MESZ
>
> I'm profiling some code to try and squeeze out performance. It takes a
> user query, reads data from the database and returned the result as XML
>
> I have tuned the code and database (checking the indexes, caching repeated
> calls etc) and what I am left with is that 95% of the call's runtime is
> building the XML. We are using builder because it is the standard / default
> for Ruby
>
> Using Ruby 3.0.2p107 as it is the default for Ubuntu 22.04
>
> Is there another, faster library for XML generation or will I be building
> this by hand?
>
> Any suggestions
> Avocado Store GmbH
> Cremon 32, 20457 Hamburg
> avocadostore.de <https://www.avocadostore.de> - Eco Fashion & Green
> Lifestyle
> [image: Instagram] <https://www.instagram.com/avocadostore.de>
> [image: Facebook] <https://de-de.facebook.com/avocadostore>
> [image: Pinterest] <https://pinterest.com/avocadostore>
> [image: TikTok] <https://www.tiktok.com/@avocadostore.de>
> [image: LinkedIn] <https://www.linkedin.com/company/avocadostore>
>
> Eine E-Mail verursacht durchschnittlich 4 g CO2, mit Anhang bis zu 50 g.
> Jährlich bedeutet das 135 kg CO2-Emissionen pro Kopf. Verringere deine
> Emissionen, indem du nur notwendige E-Mails verschickst und regelmäßig
> E-Mails löschst.
> Registergericht: Amtsgericht Hamburg, HRB 113545
> Umsatzsteuer-Identifikationsnummer: DE270706065
> Geschäftsführung: Mimi Sewalski & Till Junkermann
> [QWV9ZW-K0GVP]
>
I'm profiling some code to try and squeeze out performance. It takes a user
query, reads data from the database and returned the result as XML
I have tuned the code and database (checking the indexes, caching repeated
calls etc) and what I am left with is that 95% of the call's runtime is
building the XML. We are using builder because it is the standard / default
for Ruby
Using Ruby 3.0.2p107 as it is the default for Ubuntu 22.04
Is there another, faster library for XML generation or will I be building
this by hand?
Any suggestions
The first version of tobox (v0.4.0) has been released.
tobox implements the consumer side of the transactional outbox pattern,
providing a simple way to configure your event handlers.
* https://gitlab.com/honeyryderchuck/tobox
* https://microservices.io/patterns/data/transactional-outbox.html
tobox executes your handlers in a worker pool. The worker pool can be
thread-based (default) or fiber-based.
It uses the “SKIP LOCKED” SQL dialect to support concurrent polling for
events from the database outbox table.
It ships with plugins for sentry, datadog and zeitwerk. The plugin system
is itself very simple, so you can add your own custom logic around event
processing.
It can be used as a background job processor, although it’s best used in
tandem with an existing framework.
Here are the updates since the last release:
## [0.4.0] - 2023-05-19
### Features
#### `:stats` plugin
The `:stats` plugin collects statistics related with the outbox table
periodically, and exposes them to app code (which can then relay them to a
statsD collector, or similar tool).
```ruby
plugin(:stats)
on_stats(5) do |stats_collector| # every 5 seconds
stats = stats_collector.collect
StatsD.gauge('outbox_pending_backlog', stats[:pending_count])
end
```
Read more about it in [the project README](
https://gitlab.com/os85/tobox#stats).
#### on_start/on_stop callbacks
The `on_start` and `on_stop` callbacks can now be defined in `tobox`
configuration:
```ruby
# tobox.rb
on_start do
puts "tobox is starting..."
end
on_stop do
puts "tobox is stopping..."
end
```
### Bugfixes
* tobox configuration file is now only loaded after everything else, so
access to application code is guaranteed.
## [0.3.2] - 2023-03-06
### Bugfixes
* allow sentry error capture if `report_after_retries` option is turned off.
## [0.3.1] - 2023-03-03
### Bugfixes
In Sentry plugin, exception capturing is no longer dependent on transaction
monitoring being enabled (if `traces_sampling_rate` would be set to 0,
exceptions wouldn't be capture; now they are).
debride version 1.12.0 has been released!
* home: <https://github.com/seattlerb/debride>
* rdoc: <http://docs.seattlerb.org/debride>
Analyze code for potentially uncalled / dead methods, now with auto-removal.
Changes:
### 1.12.0 / 2023-05-18
* 1 major enhancement:
* Massive overhaul of bin/debride_rm: faster, cleaner, can run a command between each deletion.
* 2 minor enhancements:
* Added alias_method and alias as pseudo-calls to source method.
* Whitelist extended/included/prepended etc by default.
* 6 bug fixes:
* Added missing rails validation.
* Bumped sexp_processor and ruby_parser dependencies.
* Fix --exclude <dir> to properly exclude whole tree.
* Fixed --exclude option to make it repeatable.
* Fixed bug on anonymous block forwarding (eg fn(&)). (afuno)
* Use RubyParser.new instead of RubyParser.for_current_ruby.
People,
I am looking at this idea again to solve a specific problem with a
Chrome Extension. The history of this is:
Text-based ToDo lists on DOS =>
yada yada for four decades . .
Tab Management on Chromium-based Browsers.
When the developer of “Tabs Outliner” became unresponsive I switched to
“TabFern” which has been really nice and the developer is helpful but
does not have much time leftover for my suggested enhancements. So, it
would be nice if could develop a WASM replacement with Ruby.
I attach a screenshot of a TabFern window (project) with the Ruby and
WASM tabs I am currently looking at so you get the general idea of what
I want.
Suggestions about how to produce this (assuming it is a sensible and
viable thing to do) are appreciated!
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil(a)pricom.com.au
So far building it by hand is no faster than using builder. Which I'm going
to see as a plus for builder because it sure is easier to read
I think that the real issue is building a big string piecemeal is where the
time is being spent
> -K0GVP]
>
ruby_parser version 3.20.1 has been released!
* home: <https://github.com/seattlerb/ruby_parser>
* bugs: <https://github.com/seattlerb/ruby_parser/issues>
* rdoc: <http://docs.seattlerb.org/ruby_parser>
ruby_parser (RP) is a ruby parser written in pure ruby (utilizing
racc--which does by default use a C extension). It outputs
s-expressions which can be manipulated and converted back to ruby via
the ruby2ruby gem.
As an example:
def conditional1 arg1
return 1 if arg1 == 0
return 0
end
becomes:
s(:defn, :conditional1, s(:args, :arg1),
s(:if,
s(:call, s(:lvar, :arg1), :==, s(:lit, 0)),
s(:return, s(:lit, 1)),
nil),
s(:return, s(:lit, 0)))
Tested against 801,039 files from the latest of all rubygems (as of 2013-05):
* 1.8 parser is at 99.9739% accuracy, 3.651 sigma
* 1.9 parser is at 99.9940% accuracy, 4.013 sigma
* 2.0 parser is at 99.9939% accuracy, 4.008 sigma
* 2.6 parser is at 99.9972% accuracy, 4.191 sigma
* 3.0 parser has a 100% parse rate.
* Tested against 2,672,412 unique ruby files across 167k gems.
* As do all the others now, basically.
Changes:
### 3.20.1 / 2023-05-16
* 1 minor enhancement:
* Fixes Sexp#line_max in parser for many constructs: paren_args, arrays of various sorts, calls, classes, modules, etc.
