[#112457] [Ruby master Feature#19443] Cache `Process.pid` — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>
Issue #19443 has been reported by byroot (Jean Boussier).
16 messages
2023/02/16
[#112584] [Ruby master Feature#19465] [PATCH] reuse open(2) from rb_file_load_ok on POSIX-like system — "normalperson (Eric Wong) via ruby-core" <ruby-core@...>
Issue #19465 has been reported by normalperson (Eric Wong).
9 messages
2023/02/25
[#112595] [Ruby master Feature#19465] [PATCH] reuse open(2) from rb_file_load_ok on POSIX-like system
— "nobu (Nobuyoshi Nakada) via ruby-core" <ruby-core@...>
2023/02/25
SXNzdWUgIzE5NDY1IGhhcyBiZWVuIHVwZGF0ZWQgYnkgbm9idSAoTm9idXlvc2hpIE5ha2FkYSku
[#112613] Re: [Ruby master Feature#19465] [PATCH] reuse open(2) from rb_file_load_ok on POSIX-like system
— Eric Wong via ruby-core <ruby-core@...>
2023/02/26
"nobu (Nobuyoshi Nakada) via ruby-core" <ruby-core@ml.ruby-lang.org> wrote:
[#112615] Re: [Ruby master Feature#19465] [PATCH] reuse open(2) from rb_file_load_ok on POSIX-like system
— SHIBATA Hiroshi via ruby-core <ruby-core@...>
2023/02/27
MzUxMzZlMWU5YzIzMmFkN2EwMzQwN2I5OTJiMmU4NmI2ZGY0M2Y2MyBpcyBicm9rZW4gd2l0aCBg
[#112626] Re: [Ruby master Feature#19465] [PATCH] reuse open(2) from rb_file_load_ok on POSIX-like system
— Eric Wong via ruby-core <ruby-core@...>
2023/02/28
```
[ruby-core:112274] [Ruby master Misc#19421] Distribution documentation
From:
duerst via ruby-core <ruby-core@...>
Date:
2023-02-08 05:48:10 UTC
List:
ruby-core #112274
Issue #19421 has been updated by duerst (Martin D=FCrst). vo.x (Vit Ondruch) wrote in #note-8: > hsbt (Hiroshi SHIBATA) wrote in #note-2: > > See https://github.com/ruby/ruby/blob/master/doc/contributing/building_= ruby.md >=20 > Unfortunately, these documents are kind of useless. They explain what is = needed but don't explain why and that is the problem. E.g. > * Why gperf? I am not aware I'd need this for anything creating the tarba= ll via make-snapshot or using the tarball directly. That's used for creating 'enc/unicode/15.0.0/name2ctype.h' (15.0.0 is diffe= rent for different Unicode versions). The generation happens maybe once a year, usually by myself. The generated = file is then committed, so usually neither compilation from the tarball nor= compilation from github is affected. [There may be other uses of gperf, but I doubt it.] > * Are these dependencies supposed to cover also execution of test suite? Some of the Unicode-related tests aren't executed if the necessary data fil= es are not available. That's done to avoid downloading lots of files from t= he unicode.org website repeatedly. > Also, if there is any piece of pregenerated code included either in the r= epository or in the tarball I would appreciated: >=20 > * If it is documented that there is actually this code. > * If there is described way to regenerate that code. Yes. In addition to 'enc/unicode/15.0.0/name2ctype.h', the 'enc/unicode/15.= 0.0/casefold.h' and 'lib/unicode_normalize/tables.rb' are pregenerated file= s related to internationalization/Unicode.=20 ---------------------------------------- Misc #19421: Distribution documentation https://bugs.ruby-lang.org/issues/19421#change-101704 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- I use Ruby a lot, on a lot of different systems, and help people and compan= ies use it, including developers who install it on their systems. Over time, I found that installing Ruby isn't always easy. Part of this is = due to package management. There are many systems, and Ruby has had some tr= icky migrations (e.g. OpenSSL is probably one of the most painful ones that= lots of developers have trouble with). Arch Linux has been stuck on Ruby 3.0 for a long time, which could be consi= dered surprising given that Arch Linux is often on the bleeding edge of rel= eases. I personally use Arch too. So I decided to ask, what is holding them= up from making a release? I found out they had many questions about how to distribute Ruby correctly.= When I listened to those questions I felt that there are many ambiguities = in how we build and package Ruby for operating system packages. This isn't = to say that there isn't a good way to do it, just that we as a core team mi= ght be able to improve our communication about how Ruby is evolving and the= implications for package managers (if any). I've introduced `doc/distribution.md` as an effort to start having better d= ocumentation for people distributing Ruby. There are many ways which people= distribute Ruby, and many "partial" documentation or assumptions being mad= e about how to distribute Ruby and I'd like to provide a convenient standar= d location that can help people build package for Ruby distribution. Ultima= tely this makes my job easier because the latest versions of Ruby will be e= asier to install, so that's what I care about, but I don't care about what = specifically is in the document, except that I think we should listen to th= e kinds of questions being asked and, in the best interest of Ruby, provide= guidance. There was a lot of good discussion on the PR, but my goal is not to make a = finished document, but instead plant the seed so it can grow. https://github.com/ruby/ruby/pull/6856 Some follow up discussion is required: - What is the best practice for building source packages. The documentation= I wrote from this was removed as "out of scope" but I disagree with that (= https://github.com/ruby/ruby/commit/c35ebed895e1a3f7bced3db50ea0db8f284744e= 8). I don't have a strong opinion about what it should look like, but I thi= nk we should give a clear example of how to build source packages like what= I wrote. - Related to the above, what is the official location for source tarballs? - What optional dependencies are required for building vs distributing Ruby= . Arch Linux currently lists: `doxygen gdbm graphviz libffi libyaml openssl= ttf-dejavu tk` as dependencies but it's not clear if this list is up to da= te, or what the expectations are. When someone installs Ruby (e.g. `apt-get= install ruby`) what dependencies should be installed? I think it would be = helpful to list expected dependencies (from a system package POV), etc. - Is Ruby needed for building Ruby? Should source packages install Ruby bef= ore building from source? If so, what versions are supported? - Clear guidance on gems that are distributed an alongside Ruby, and how se= curity changes to gems are managed. Even if we have more detailed documentation elsewhere, let's summarise it a= nd then cross-reference it. People who build packages to distribute and ins= tall Ruby should feel supported, they are very important to our community. = To this end, I established `#distribution` channel on Slack for discussion.= We should listen to the questions being asked and use those questions to d= rive improvements to documentation. --=20 https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-c= ore.ml.ruby-lang.org/