Lmst

🚀 Simplified JRuby Gradle plugin 2.3.2 has been released!

Documentation: https://jruby-gradle.ysb33r.org

Release notes: https://jruby-gradle.ysb33r.org/jruby-simple/2.3.2/changelog.html

The Mocha test suite continues it's proud tradition of acting as an extra set of regression tests for JRuby - this time finding an obscure bug in keyword argument handling! 🎉

And, as always, I'm very appreciative of the work of @headius and the JRuby team! ❤️

https://github.com/jruby/jruby/issues/8976

#jruby #ruby #kwargs #testing

Ruby-Elf and collision detection improvements

While the main use of Ruby-Elf for me lately has been quite different – for instance with the advent of elfgrep or helping verifying LFS support – the original reason that brought me to write that parser was finding symbol collisions (that’s almost four years ago… wow!).

And symbol collisions are indeed still a problem, and as I wrote recently they don’t get very easy on the upstream developers’ eyes, as they are mostly an indication of possible aleatory problems in the future.

At any rate, the original script ran overnight, generated a huge amount of database, and then required more time to produce a readable output, all of which happened using an unbearable amount of RAM. Between the ability to run it on a much more powerful box, and the work done to refine it, it can currently scan Yamato’s host system in … 12 minutes.

The latest set of change that replaced the “one or two hours” execution time with the current “about ten minutes” (for the harvesting part, there are two more minutes required for the analysis) was part of my big rewrite of the script so that it used the same common class interfaces as the commands that are installed to be used with the gem as well. In this situation, albeit keeping the current single-threaded (more on that in a moment), each file analysed consists of three calls to the PostgreSQL backend, rather than being something in the ballpark of 5 plus one per symbol, and this makes it quite faster.

To achieve this I first of all limited the round-trips between Ruby and PostgreSQL when deciding whether a file (or a symbol) has been already added or not. In the previous iteration I was already optimising this a bit by using prepared statements (that seemed slightly faster than direct queries), but they didn’t allow me to embed the logic into them, so I had a number of select and insert statements depending on the results of those, which was bad not only because each selection would require converting data types twice (from PostgreSQL representation to C, then from that to Ruby), but also because it required to call into the database each time.

So I decided to bite the bullet and, even though I know it makes it a bunch of spaghetti code, I’ve moved part of the logic in PostgreSQL through stored procedures. Long live PL/SQL.

Also, to make it more solid in respect to parsing error on single object files, rather than queuing all the queries and then commit them in one big single transaction, I create single transactions to commit all the symbols of an object, as well as when creating the indexes. This allows me to skip over objects altogether if they are broken, without stopping the whole harvesting process.

Even after introducing the transaction on symbols harvesting, I found it much faster to run a single statement through PostgreSQL in a transaction, with all the symbols; since I cannot simply run a single INSERT INTO with multiple values (because I might hit an unique constrain, when the symbols are part of a “multiple implementations” object), at least I call the same stored procedure multiple times within the same statement. This had tremendous effect, even though the database is accessed through Unix sockets!

Since the harvest process now takes so little time to complete, compared to what it did before, I also dropped the split between harvest and analysis: analyse.rb is gone, merged into the harvest.rb script for which I have to write a man page, sooner or later, and get installed properly as an available tool rather than an external one.

Now, as I said before, this script is still single-threaded; on the other hand, all the other tools are “properly multithreaded”, in the sense that their code fires up a new Ruby thread per each file to analyse and the results are synchronised not to step on each other’s feet. You might know already that, at least for what concerns Ruby 1.8, threading is not really implemented and green threads are used instead, which means there is no real advantage in using them; that’s definitely true. On the other hand, on Ruby 1.9, even though the pure-Ruby nature of Ruby-Elf makes the GIL a main obstacle, threading would improve the situation by simply allowing threads to analyse more files while the pg backend gem would send the data over to PostgreSQL (which would probably also be helped by the “big” transactions sent right now). But what about the other tools that don’t use external extensions at all?

Well, threading elfgrep or cowstats is not really any advantage on the “usual” Ruby versions (MRI18 and 1.9), but it provides a huge advantage when running them with JRuby, as that implementation has real threads, it can scan multiple files at once (both when using asynchronous listing of input files with the standard input stream, and when providing all of them in one single sweep), and then only synchronise to output the results. This of course makes it a bit more tricky to be sure that everything is being executed properly, but in general makes the tools just the more sweet. Too bad that I can’t use JRuby right now for harvest.rb, as the pg gem I’m using is not available for JRuby, I’d have to rewrite the code to use JDBC instead.

Speaking about options passing, I’ve been removing some features I originally implemented; in the original implementation, the arguments parsing was asynchronous and incremental, without limits to recursion; this meant that you could provide a list of files preceded by the at-symbol as the standard input of the process, and each of that would be scanned for… the same content. This could have been bad already for the possible loops, but it also had a few more problems, among which there was the lack of a way to add a predefined list of targets if none was passed (which I needed for harvest.rb to behave more or less like before). I’ve since rewritten the targets’ parsing code to only work with a single-depth search, and relying on asynchronous arguments passing only through the standard input, which is only used when no arguments are given, either on command line or by default of the script. It’s also much faster this way.

For today I guess all these notes about Ruby-Elf would be enough; on the other hand, in the next days I hope to provide some more details about the information the script is providing me.. they aren’t exactly funny, and they aren’t exactly the kind of things you wanted to know about your system. But I guess this is a story for another day.

#Collisions #JRuby #Multithreading #PostgreSQL #Ruby #RubyELF

주간 개발 업데이트: JRuby, Hanami 개선 및 혁신적인 repo-sync 시스템 도입

JRuby 호환성 개선, Hanami 프레임워크 기능 확장 및 유지보수 업데이트가 활발히 진행되었습니다.

#hanami #jruby
https://ruby-news.kr/articles/continuations-202549-fit-of-procrastivity

Which JVM language fits your stack? #Kotlin for Android, #Scala for Spark, #Groovy for testing, #Clojure for concurrency, #JRuby & #Jython for scripts. Each solves different dev pains—fully JVM-compatible.

Mihaela Gheorghe-Roman shows the big picture: https://javapro.io/2025/10/09/the-rise-of-jvm-languages-kotlin-scala-groovy-and-more/

🚀 Simplified JRuby Gradle plugin 2.3.1 has been released!

Documentation: https://ysb33rorg.gitlab.io/gradle/simplified-jruby-gradle-plugin

Release notes: https://ysb33rorg.gitlab.io/gradle/simplified-jruby-gradle-plugin/jruby-simple/2.3.1/changelog.html

#gradle #gradlePlugins #jruby

리가와 루프탑에서 온 현장 보고서: 후원 캠페인 3주차 업데이트

발틱 루비 컨퍼런스에서 Hanami 프로젝트는 OSS 엑스포를 통해 커뮤니티 참여를 확대하고, JRuby 호환성 개선을 모색하며 기술적 진전을 이루었습니다.

#hanami #jruby
https://ruby-news.kr/articles/field-report-from-riga-and-the-rooftop

Warbler를 활용한 Ruby 앱 패키징: 단일 JAR 파일로 모든 종속성 포함하기

Warbler는 JRuby 환경에서 Ruby 애플리케이션과 모든 종속성을 단일 실행 가능한 JAR 또는 배포 가능한 WAR 파일로 패키징하는 도구입니다.

#jruby
https://ruby-news.kr/articles/packaging-ruby-apps-with-warbler-jar-files

🚀 Simplified JRuby Gradle plugin 2.3.0 has been released!

Documentation: https://ysb33rorg.gitlab.io/gradle/simplified-jruby-gradle-plugin

Release notes: https://ysb33rorg.gitlab.io/gradle/simplified-jruby-gradle-plugin/jruby-simple/2.3.0/changelog.html

#gradle #gradlePlugins #jruby

🚀 Simplified JRuby Gradle plugin 2.2.1 has been released!

Documentation: https://ysb33rorg.gitlab.io/gradle/simplified-jruby-gradle-plugin

Release notes: https://ysb33rorg.gitlab.io/gradle/simplified-jruby-gradle-plugin/jruby-simple/2.2.1/changelog.html

#gradle #gradlePlugins #jruby

@headius
I need to run this again to see what might have changed but there is a guide from earlier that I wrote:
https://notepad.onghu.com/2021/jruby-win-day2-creating-jar-files/

But I am delighted that some of the niggling issues might have now been resolved.

#JRuby #Ruby #Programming

Does anyone have a good example of integrating a dynamic language such as JS, Python, or similar (jruby, jgroovy...) into a running Java program as a customer-controlled extension? We are not talking about high-performance here, rather simple API use for a more sophisticated configuration than just XML or JSON data. Must be runtime, not build time. Thanks.

Java itself would be great, but it must be a rather secure approach because it will be hosted. #java #API #extensions #groovy #jruby