LostCarPark Drupal Blog: Drupal Advent Calendar day 11 – Volunteer Coordination

Posted on by Michael G
Drupal Advent Calendar day 11 – Volunteer Coordination

james

Mon, 12/11/2023 – 07:00

LostCarPark Drupal Blog: Drupal Advent Calendar day 11 - Volunteer Coordination

Welcome back to day 11 of the Drupal Advent Calendar. Behind today’s door Surabhi Gokte (surabhi-gokte) talks about her journey as volunteer coordinator.

Seven years ago, if someone said I would travel out of my country and be a super active community contributor, I’d have laughed it off. But things changed, and it wasn’t an overnight transformation. It required time, energy, money, patience, belief, and much more.

My journey began with volunteering at Drupal Camp Delhi in 2016, my first step into understanding the Drupal Community. Back then, I didn’t even know non-code contribution was a thing…

Tags

Ruby 3.3.0-rc1 Released

Posted on by Michael G

We are pleased to announce the release of Ruby 3.3.0-rc1. Ruby 3.3 adds a new parser named Prism, uses Lrama as a parser generator, adds a new pure-Ruby JIT compiler named RJIT, and many performance improvements especially YJIT.

After the release of RC1, we will avoid introducing ABI incompatibilities wherever possible. If we need to do, we’ll announce it in the release note.

Prism

  • Introduced the Prism parser as a default gem
    • Prism is a portable, error tolerant, and maintainable recursive descent parser for the Ruby language
  • Prism is production ready and actively maintained, you can use it in place of Ripper
    • There is extensive documentation on how to use Prism
    • Prism is both a C library that will be used internally by CRuby and a Ruby gem that can be used by any tooling which needs to parse Ruby code
    • Notable methods in the Prism API are:
      • Prism.parse(source) which returns the AST as part of a ParseResult
      • Prism.dump(source, filepath) which returns the serialized AST as a String
      • Prism.parse_comments(source) which returns the comments
  • You can make pull requests or issues directly on the Prism repository if you are interested in contributing

Use Lrama instead of Bison

RJIT

  • Introduced a pure-Ruby JIT compiler RJIT and replaced MJIT.
    • RJIT supports only x86-64 architecture on Unix platforms.
    • Unlike MJIT, it doesn’t require a C compiler at runtime.
  • RJIT exists only for experimental purposes.
    • You should keep using YJIT in production.
  • If you are interested in developing JIT for Ruby, please check out k0kubun’s presentation on Day 3 of RubyKaigi.

YJIT

  • Major performance improvements over 3.2
    • Support for splat and rest arguments has been improved.
    • Registers are allocated for stack operations of the virtual machine.
    • More calls with optional arguments are compiled.
    • Exception handlers are also compiled.
    • Instance variables no longer exit to the interpreter
      with megamorphic object shapes.
    • Unsupported call types no longer exit to the interpreter.
    • Integer#!=, String#!=, Kernel#block_given?, Kernel#is_a?,
      Kernel#instance_of?, Module#=== are specially optimized.
    • Now more than 3x faster than the interpreter on optcarrot!
  • Significantly improved memory usage over 3.2
    • Metadata for compiled code uses a lot less memory.
    • Generate more compact code on ARM64
  • Compilation speed is now slightly faster than 3.2.
  • Add RubyVM::YJIT.enable that can enable YJIT at run-time
    • You can start YJIT without modifying command-line arguments or environment variables.
    • This can also be used to enable YJIT only once your application is
      done booting. --yjit-disable can be used if you want to use other
      YJIT options while disabling YJIT at boot.
  • Code GC is now disabled by default, and --yjit-exec-mem-size is treated
    as a hard limit where copilation of new code stops.

    • Better copy-on-write behavior on servers using unicorn and forking
    • No sudden drops in performance due to code GC.
    • You can still enable code GC if desired with --yjit-code-gc
  • ratio_in_yjit stat produced by --yjit-stats is now available in release builds,
    a special stats or dev build is no longer required to access most stats.
  • Exit tracing option now supports sampling
    • --trace-exits-sample-rate=N
  • --yjit-perf is added to facilitate profiling with Linux perf.
  • More thorough testing and multiple bug fixes

M:N thread scheduler

  • M:N thread scheduler was introduced. [Feature #19842]
    • M Ruby threads are managed by N native threads (OS threads) so the thread creation and management cost are reduced.
    • It can break C-extension compatibility so that M:N thread scheduler is disabled on the main Ractor by default.
      • RUBY_MN_THREADS=1 environment variable enables M:N threads on the main Ractor.
      • M:N threads are enabled on non-main Ractors.
    • RUBY_MAX_CPU=n environment variable sets maximum number of N (maximum number of native threads). The default value is 8.
      • Since only one Ruby thread per Ractor can run at the same time, the number of native threads will be used, which is the smaller of the number specified in RUBY_MAX_CPU and the number of running Ractors. So that single Ractor applications (most of applications) will use 1 native thread.
      • To support blocking operations, more than N native threads can be used.

Other Notable New Features

Language

Performance improvements

  • defined?(@ivar) is optimized with Object Shapes.
  • Name resolution such as Socket.getaddrinfo can now be interrupted (in environments where pthreads are available). Feature #19965
    • For this purpose, a pthread is now created whenever calling getaddrinfo or getnameinfo. This incurs some overhead in name resolution (about 2.5x in our experiments). We do not expect the name resolution overhead to be a problem for most applications, but if you observe such, or if you see unexpected affects that you believe are due to this change, please report them.
  • Several performance improvements to the Garbage Collector
    • Young objects referenced by old objects are no longer immediately
      promoted to the old generation. This significantly reduces the frequency of
      major GC collections. [Feature #19678]
    • A new REMEMBERED_WB_UNPROTECTED_OBJECTS_LIMIT_RATIO tuning variable was
      introduced to control the number of unprotected objects cause a major GC
      collection to trigger. The default is set to 0.01 (1%). This significantly
      reduces the frequency of major GC collection. [Feature #19571]
    • Write Barriers were implemented for many core types that were missing them,
      notably Time, Enumerator, MatchData, Method, File::Stat, BigDecimal
      and several others. This significantly reduces minor GC collection time and major
      GC collection frequency.
    • Most core classes are now using Variable Width Allocation, notably Hash, Time,
      Thread::Backtrace, Thread::Backtrace::Location, File::Stat, Method.
      This makes these classes faster to allocate and free, use less memory and reduce
      heap fragmentation.
    • Support for weak references has been added to the garbage collector. [Feature #19783]

Other notable changes since 3.2

IRB

IRB has received several enhancements, including but not limited to:

  • Advanced irb:rdbg integration that provides an equivalent debugging experience to pry-byebug (doc).
  • Pager support for ls, show_source and show_cmds commands.
  • More accurate and helpful information provided by the ls and show_source commands.
  • Experimental autocompletion using type analysis (doc).
  • It is now possible to change the font color and font style in the completion dialog by a newly introduced class Reline::Face (doc)

In addition, IRB has also undergone extensive refactoring and received dozens of bug fixes to facilitate easier future enhancements.

Compatibility issues

Note: Excluding feature bug fixes.

  • it calls without arguments in a block with no ordinary parameters are
    deprecated. it will be a reference to the first block parameter in Ruby 3.4.
    Feature #18980

Removed constants

The following deprecated constants are removed.

Removed methods

The following deprecated methods are removed.

Removed environment variables

The following deprecated methods are removed.

  • Environment variable RUBY_GC_HEAP_INIT_SLOTS has been deprecated and is a no-op. Please use environment variables RUBY_GC_HEAP_{0,1,2,3,4}_INIT_SLOTS instead. Feature #19785

Stdlib compatibility issues

ext/readline is retired

  • We have reline that is pure Ruby implementation compatible with ext/readline API. We rely on reline in the future. If you need to use ext/readline, you can install ext/readline via rubygems.org with gem install readline-ext.
  • We no longer need to install libraries like libreadline or libedit.

C API updates

Updated C APIs

The following APIs are updated.

Removed C APIs

The following deprecated APIs are removed.

Standard library updates

RubyGems and Bundler warn if users require gem that is scheduled to become the bundled gems in the future version of Ruby.

Targeted libraries are:

  • abbrev
  • base64
  • bigdecimal
  • csv
  • drb
  • getoptlong
  • mutex_m
  • nkf
  • observer
  • racc
  • resolv-replace
  • rinda
  • syslog

The following default gem is added.

  • prism 0.15.1

The following default gems are updated.

  • RubyGems 3.5.0.dev
  • base64 0.2.0
  • benchmark 0.3.0
  • bigdecimal 3.1.5
  • bundler 2.5.0.dev
  • cgi 0.4.0
  • csv 3.2.8
  • date 3.3.4
  • delegate 0.3.1
  • drb 2.2.0
  • english 0.8.0
  • erb 4.0.3
  • etc 1.4.3.dev.1
  • fcntl 1.1.0
  • fiddle 1.1.2
  • fileutils 1.7.2
  • find 0.2.0
  • getoptlong 0.2.1
  • io-console 0.6.1.dev
  • irb 1.8.3
  • logger 1.6.0
  • mutex_m 0.2.0
  • net-http 0.4.0
  • net-protocol 0.2.2
  • nkf 0.1.3
  • observer 0.1.2
  • open-uri 0.4.0
  • open3 0.2.0
  • openssl 3.2.0
  • optparse 0.4.0
  • ostruct 0.6.0
  • pathname 0.3.0
  • pp 0.5.0
  • prettyprint 0.2.0
  • pstore 0.1.3
  • psych 5.1.1.1
  • rdoc 6.6.0
  • reline 0.3.9
  • rinda 0.2.0
  • securerandom 0.3.0
  • shellwords 0.2.0
  • singleton 0.2.0
  • stringio 3.0.9
  • strscan 3.0.7
  • syntax_suggest 1.1.0
  • tempfile 0.2.0
  • time 0.3.0
  • timeout 0.4.1
  • tmpdir 0.2.0
  • tsort 0.2.0
  • un 0.3.0
  • uri 0.13.0
  • weakref 0.1.3
  • win32ole 1.8.10
  • yaml 0.3.0
  • zlib 3.1.0

The following bundled gem is promoted from default gems.

  • racc 1.7.3

The following bundled gems are updated.

  • minitest 5.20.0
  • rake 13.1.0
  • test-unit 3.6.1
  • rexml 3.2.6
  • rss 0.3.0
  • net-imap 0.4.4
  • net-smtp 0.4.0
  • rbs 3.2.2
  • typeprof 0.21.8
  • debug 1.8.0

See GitHub releases like Logger or
changelog for details of the default gems or bundled gems.

See NEWS
or commit logs
for more details.

With those changes, 5414 files changed, 306141 insertions(+), 183575 deletions(-)
since Ruby 3.2.0!

Download

  • https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0-rc1.tar.gz

    SIZE: 21783575
SHA1: c75a860e06f27b7f69b874757417277c21d1d3f4
SHA256: c4ff82395a90ef76c7f906b7687026e0ab96b094dcf3a532d9ab97784a073222
SHA512: 265fb2ffe55af47d8349edffcebe749cc170291227cef55529fe4e67363e4e84b88daa34ffb5364a99c8a0e32110266a34c9a11d62f3bd6f6d47fa76eca641f4

  • https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0-rc1.tar.xz

    SIZE: 16163884
SHA1: 26503f9bdc7d0a05aaa9836f54d3aa9e74a9ead9
SHA256: 051815637f1fa75a1edf2c54b66d5d5b69563daad777da8dc39543b7754b5290
SHA512: 82f4acfaad1dc47db27ee3eb952481a95b3474a98059e9e9f5ceb035b690d1faabe99f2ec52371c4089ed1615eb10c395f029088418fec4d26399b65b4f259b9

  • https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.0-rc1.zip

    SIZE: 26735443
SHA1: 35583453a7734216b08829ef0ec9ea1bc0d4ae7f
SHA256: 56dd82e1dd714f2889ca975ae7befbe005675de08839c2cc4a484de2ae65201c
SHA512: 7fbe414c230aedc9f364512bcbc213038f8f6e4268929a559d2527e2f3e32a140b394e37098ab7e59161236eca8b89cc9e52d73a3be8d7bd44faa91681483f5d

What is Ruby

Ruby was first developed by Matz (Yukihiro Matsumoto) in 1993,
and is now developed as Open Source. It runs on multiple platforms
and is used all over the world especially for web development.

Posted by naruse on 11 Dec 2023

Python 3.11.7 is now available

Posted on by Michael G

  

This is the sixth maintenance release of Python 3.11

Python 3.11.7 is the newest major release of the Python programming language, and it contains many new features and optimizations. Get it here:

https://www.python.org/downloads/release/python-3117/

Major new features of the 3.11 series, compared to 3.10

Among the new major new features and changes so far:

  • PEP 657 – Include Fine-Grained Error Locations in Tracebacks
  • PEP 654 – Exception Groups and except*
  • PEP 673 – Self Type
  • PEP 646 – Variadic Generics
  • PEP 680 – tomllib: Support for Parsing TOML in the Standard Library
  • PEP 675 – Arbitrary Literal String Type
  • PEP 655 – Marking individual TypedDict items as required or potentially-missing
  • bpo-46752 – Introduce task groups to asyncio
  • PEP 681 – Data Class Transforms
  • bpo-433030– Atomic grouping ((?>…)) and possessive quantifiers (*+, ++, ?+, {m,n}+) are now supported in regular expressions.
  • The Faster Cpython Project is already yielding some exciting results. Python 3.11 is up to 10-60% faster than Python 3.10. On average, we measured a 1.22x speedup on the standard benchmark suite. See Faster CPython for details.

More resources

And now for something completely different

A pentaquark is a human-made subatomic particle, consisting of four quarks and one antiquark bound together; they are not known to occur naturally, or exist outside of experiments specifically carried out to create them.  

Quarks quarks have a baryon number of +1/3 and antiquarks of -1/3, the pentaquark would have a total baryon number of 1, and thus would be a baryon. Further, because it has five quarks instead of the usual three found in regular baryons (a.k.a. ‘triquarks’), it is classified as an exotic baryon. The name pentaquark was coined by Claude Gignoux and Harry J. Lipkin in 1987; however, the possibility of five-quark particles was identified as early as 1964 when Murray Gell-Mann first postulated the existence of quarks. Although predicted for decades, pentaquarks proved surprisingly difficult to discover and some physicists were beginning to suspect that an unknown law of nature prevented their production.

We hope you enjoy the new releases!

Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation.


https://www.python.org/psf/

Your friendly release team,
Ned Deily @nad 
Steve Dower @steve.dower 
Pablo Galindo Salgado @pablogsal

Andy Wingo: a simple hdr histogram

Posted on by Michael G

Good evening! This evening, a note on high-dynamic-range (HDR)
histograms.

problem

How should one record garbage collector pause times?

A few options present themselves: you could just record the total pause
time. Or, also record the total number of collections, which allows you
to compute the average. Maximum is easy enough, too. But then you
might also want the median or the p90 or the p99, and these percentile
values are more gnarly: you either need to record all the pause times,
which can itself become a memory leak, or you need to approximate via a
histogram.

Let’s assume that you decide on the histogram approach. How should you
compute the bins? It would be nice to have microsecond accuracy on the
small end, but if you bin by microsecond you could end up having
millions of bins, which is not what you want. On the other end you
might have multi-second GC pauses, and you definitely want to be able to
record those values.

Consider, though, that it’s not so important to have microsecond
precision for a 2-second pause. This points in a direction of wanting
bins that are relatively close to each other, but whose absolute
separation can vary depending on whether we are measuring microseconds
or milliseconds. You want approximately uniform precision over a high
dynamic range.

logarithmic binning

The basic observation is that you should be able to make a histogram
that gives you, say, 3 significant figures on measured values. Such a
histogram would count anything between 1230 and 1240 in the same bin,
and similarly for 12300 and 12400. The gap between bins increases as
the number of digits grows.

Of course computers prefer base-2 numbers over base-10, so let’s do
that. Say we are measuring nanoseconds, and the maximum number of
seconds we expect is 100 or so. There are about 230
nanoseconds in a second, and 100 is a little less than 27, so
that gives us a range of 37 bits. Let’s say we want a precision of 4
significant base-2 digits, or 4 bits; then we will have one set of
24 bins for 10-bit values, another for 11-bit values, and
so-on, for a total of 37 × 24 bins, or 592 bins. If we use a
32-bit integer count per bin, such a histogram would be 2.5kB or so,
which I think is acceptable.

Say you go to compute the bin for a value. Firstly, note that there are
some values that do not have 4 significant bits: if you record a
measurement of 1 nanosecond, presumably that is just 1 significant
figure. These are like the
denormals in
floating-point numbers. Let’s just say that recording a value val in
[0, 24-1] goes to bin val.

If val is 24 or more, then we compute the major and
minor components. The major component is the number of bits needed to
represent val, minus the 4 precision bits. We can define it like this
in C, assuming that val is a 64-bit value:

#define max_value_bits 37
#define precision 4
uint64_t major = 64ULL - __builtin_clzl(val) - precision;

The 64 - __builtin_clzl(val) gives us the ceiling of the base-2
logarithm of the value. And actually, to take into account the denormal
case, we do this instead:

uint64_t major = val < (1ULL << precision)
  ? 0ULL
  : 64ULL - __builtin_clzl(val) - precision;

Then to get the minor component, we right-shift val by major bits,
unless it is a denormal, in which case the minor component is the value
itself:

uint64_t minor = val < (1 << precision)
  ? val
  : (val >> (major - 1ULL)) & ((1ULL << precision) - 1ULL);

Then the histogram bucket for a given value can be computed directly:

uint64_t idx = (major << precision) | minor;

Of course, we would prefer to bound our storage, hence the consideration
about 37 total bits in 100 seconds of nanoseconds. So let’s do that,
and record any out-of-bounds value in the special last bucket,
indicating that we need to expand our histogram next time:

if (idx >= (max_value_bits << precision))
  idx = max_value_bits << precision;

The histogram itself can then be defined simply as having enough buckets
for all major and minor components in range, plus one for overflow:

struct histogram {
  uint32_t buckets[(max_value_bits << precision) + 1];
};

Getting back the lower bound for a bucket is similarly simple, again
with a case for denormals:

uint64_t major = idx >> precision;
uint64_t minor = idx & ((1ULL << precision) - 1ULL);
uint64_t min_val = major
  ? ((1ULL << precision) | minor) << (major - 1ULL)
  : minor;

y u no library

How many lines of code does something need to be before you will include
it as a library instead of re-implementing? If I am honest with myself,
there is no such limit, as far as code goes at least: only a limit of
time. I am happy to re-implement anything; time is my only enemy. But
strategically speaking, time too is the fulcrum: if I can save time by
re-implementing over integrating a library, I will certainly hack.

The canonical library in this domain is
HdrHistogram. But even
the C port is thousands of lines of code! A histogram should not take
that much code! Hence this blog post today. I think what we have above is sufficient. HdrHistogram’s documentation speaks
in terms of base-10 digits of precision, but that is easily translated
to base-2 digits: if you want 0.1% precision, then in base-2 you’ll need
10 bits; no problem.

I should of course mention that HdrHistogram includes an API that compensates for coordinated
omission, but I think such an API is straigtforward to build on
top of the basics.

My code, for what it is worth, and which may indeed be buggy, is over
here.
But don’t re-use it: write your own. It could be much nicer in C++ or
Rust, or any other language.

Finally, I would note that somehow this feels very basic; surely there
is prior art? I feel like in 2003, Google would have had a better
answer than today; alack. Pointers
appreciated to other references, and if you find them, do tell me more about your search strategy, because mine is inadequate. Until then, gram you later!

Faceless Love (2023) Episode 1 English Subbed

Posted on by Michael G

Video by via Dailymotion Source Episode 1 Plot:In this episode, viewers learn about Veekit’s past and the traumatic incident in his childhood that led to the development of prosopagnosia. Now, as a successful adult businessman, Veekit’s colleague Chanon is determined to find a new secretary who can assist him in navigating the challenges posed by…

Especialista analisa conflito territorial em Essequibo: “Maduro segue manual de Putin”

Posted on by Michael G

Video by via Dailymotion Source O programa Jornal da Manhã deste domingo (10) recebeu o professor de relações internacionais Gunther Rudzit para analisar o conflito territorial entre Venezuela e Guiana. Neste sábado (09), o presidente Lula conversou com Nicolás Maduro por telefone para mediar uma condução pacífica da tensão em Essequibo. Assista ao programa completo:…

Olacak O Kadar | Full Arşiv | İlaç Gibi Geldi…

Posted on by Michael G

Video by via Dailymotion Source Bölümün Tamamı Saat 19:00’da ‘Olacak O Kadar’ YouTube Kanalında! Olacak O Kadar YouTube Kanalına Abone olmak için http://wedia.link/OlacakOKadarAboneOl linke tıklayabilirsiniz. Levent Kırca ve ekibinin hazırlayıp sunduğu Olacak O Kadar, Levent Kırca’nın yarattığı ve oyuncu kadrosunun başında bulunduğu, 22 yıldır çeşitli Türk televizyon kanallarında yayınlanan ve halkın sorunlarını anlatan bir eleştirel…