The Rubinius Language Platform
MPL-2.0 License
Bot releases are hidden (Show)
Published by brixen almost 8 years ago
Version 3.68 (2016-11-10)
Published by brixen almost 8 years ago
Version 3.67 (2016-11-08)
Published by brixen almost 8 years ago
Version 3.66 (2016-11-07)
In Ruby, the Thread where a signal is processed isn't defined, but the
assumption is that the signal handler runs in Thread.main (as observed in Ruby
behavior).
Also undefined in Ruby is what ThreadGroup a Thread created in a signal
handler should be added to. Going with the assumption that the signal handler
proc is run in Thread.main, we assume the new Thread should be added to
Thread.main.group.
We now set the signal handler Thread's group to the same group as Thread.main,
so that threads created in a signal handler proc have a group and are added to
a group.
Unfortunately, splitting up the source location makes copy-pasting the path to
edit a source file very tedious.
Now, the source location is rendered as an unbroken sequence of characters but
starting on a new line if the total backtrace line exceeds the terminal width.
This preserves the readability of the receiver+method, while also preserving
the ability to copy-paste the source location.
Unfortunately, color is problematic due to the perception of colors and the
interaction of color with terminal colors, which something which Rubinius has
no control over.
The goal of readability in backtraces is an important one. There are two
primary pieces of information in each backtrace line: 1. receiver+method; and
2. source code location, file+line number.
The current rendering approach is to bold the receiver+method and separate the
source line on a new line when the total backtrace line exceeds the terminal
width. This provides contrast that improves scanning the backtrace on primary
information, the receiver+method, and easily selecting secondary information,
the source location, when necessary.
As such, this convention carries over without much question to rendering
backtraces. However, the context of consuming a backtrace requires different
conventions, but ones that are not foreign.
So, for rendering backtraces, the conventions are retained but the ordering is
changed slightly to improve processing the information. There are now four
basic components to a backtrace line (for an object-oriented method): 1. the
method name; 2. the instance/module indicator; 3. the fully-scoped receiver
name; and 4. the source code location.
The first thing that needs to be located and digested is the method name, so
the method names are right aligned allowing both easily reading the method
name and quick indexing for the second important piece of information, the
receiver name. The source location trails and may be on a new line if the
total backtrace line rendering exceeds the terminal width.
This rendering better orders information in the backtrace based on the
hierarchy of important information (method name > instance/module indicator >
receiver name > source location). It also balances the tensions between making
an individual line of a backtrace readable and making the whole thing
scannable and readable. When rendering the full method name as A::B::C#name,
the variability of the A::B::C component pushed many names too far to the
right, leaving a very jagged left edge that is more difficult to scan, as well
as burying the method name (the primary element) embedded in the middle of a
bunch of character noise.
Published by brixen almost 8 years ago
Version 3.65 (2016-11-01)
Published by brixen almost 8 years ago
Version 3.64 (2016-10-31)
Published by brixen almost 8 years ago
Version 3.63 (2016-10-28)
Published by brixen about 8 years ago
Version 3.62 (2016-10-14)
Published by brixen about 8 years ago
Version 3.61 (2016-10-13)
Published by brixen about 8 years ago
Version 3.60 (2016-09-21)
Private constants do not add any capability to Ruby. They merely restrict
programs that would otherwise run. For this reason, not supporting private
constants in Rubinius doesn't prohibit any code that would otherwise run in
Ruby, except for the fruitless class of code that soley relies on accessing a
private constant to raise an exception.
The exception that is raised is a NameError, which causes confusion between a
constant not being defined at all, and therefore able to be defined or
autoloaded, etc., and the constant being defined but private, and therefore
prohibiting defining the constant. To distinguish between these cases would
require parsing the exception text itself.
Despite being labeled private and superficially not accessible, it is easy to
actually access the constant. So no well-meaning code is actually inhibited by
labeling a constant private.
If code were presented that relied on private constants being private, in the
positive sense (ie added capability, not merely prohibited capability), we
can revisit support for private constants.
Published by brixen about 8 years ago
Version 3.59 (2016-09-12)
Published by brixen about 8 years ago
Version 3.58 (2016-09-02)
Published by brixen about 8 years ago
Version 3.57 (2016-08-30)
Published by brixen about 8 years ago
Version 3.56 (2016-08-19)
Published by brixen about 8 years ago
Version 3.55 (2016-08-17)
Published by brixen about 8 years ago
Version 3.54 (2016-08-16)
Published by brixen about 8 years ago
Version 3.53 (2016-08-15)
Published by brixen about 8 years ago
Version 3.52 (2016-08-13)
Instead of managing special code to parse this special syntax, we convert to
standard JSON for attributes and documentation, and explicit C++ source files
and C #include statements for code.
The interpreter executes the functions and moves the instruction pointer
(IP) to the next instruction, essentially operating as a loop (implemented by
tail calls) over the instruction (opcode) vector.
The naive JIT linearizes the sequence of function calls to the instructions
and introduces control flow directly (instead of it being an artifact of
iterating over the opcode vector).
Published by brixen about 8 years ago
Version 3.51 (2016-07-27)
This reverts commit 20938ee86dcb7396c4cf2d16bb89ffd9fcee9a9d.
Published by brixen about 8 years ago
Version 3.50 (2016-07-25)
We define MemoryFlags as a single machine word type instead of using a struct
of bitfields for the reasons given in the code comment.
Published by brixen about 8 years ago
Version 3.49 (2016-07-22)
ref: https://bugs.ruby-lang.org/issues/7499
ref: https://github.com/rubinius/rubinius/pull/3681#issuecomment-234644486
Unfortunately, down in the managed memory code, there was an explicit uint32_t
data type. What happens when 4294967328 == 0x100000020 bytes get put into
32bits? 0x100000020 & 0xffffffff == 32. Those 2**29 elements were being
crammed into 32 bytes. Computers may be magic, but even they can only take so
much.