May 2023 - ruby-talk - ml.ruby-lang.org

[ruby-talk:444143] Re: RubyConf 2022 Talk Video for Building Native GUI Apps in Ruby
by Andy Maleh 19 Nov '23

19 Nov '23

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>

3 2

[ruby-talk:444240] [ANN] oedipus_lex 2.6.1 Released
by Ryan Davis 05 Jun '23

05 Jun '23

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

2 1

[ruby-talk:444239] [ANN] wxRuby3 0.9.0.beta-11 released
by martin＠corino.nl 25 May '23

25 May '23

A new public beta of the newly revived wxRuby3 has been released. If you are interested check this out: Release info: https://github.com/mcorino/wxRuby3/releases/tag/v0.9.0-beta.11 Github: https://github.com/mcorino/wxruby3 Rubygems: https://rubygems.org/gems/wxruby3

1 0

[ruby-talk:444228] Re: Generating XML
by Peter Hickman 24 May '23

24 May '23

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] >

3 2

[ruby-talk:444222] Generating XML
by Peter Hickman 24 May '23

24 May '23

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

6 5

[ruby-talk:444230] [ANN] tobox 0.4.0 released
by Tiago Cardoso 21 May '23

21 May '23

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).

2 1

[ruby-talk:444227] [ANN] debride 1.12.0 Released
by Ryan Davis 18 May '23

18 May '23

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.

1 0

[ruby-talk:444229] Ruby2WASM Again: My first use case
by Philip Rhoades 18 May '23

18 May '23

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

1 0

[ruby-talk:444225] Re: Generating XML
by Peter Hickman 18 May '23

18 May '23

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] >

2 1

[ruby-talk:444221] [ANN] ruby_parser 3.20.1 Released
by Ryan Davis 17 May '23

17 May '23

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.

1 0