Using malloc does not invoke T's constructor, nor were were invoking T's
constructor ourselves. Accessing T without invoking its constructor is
undefined behavior.
Without `-y`, to show the current full year you'd have to specify which
one: `cal 2023`. Adding `-y` makes it possible to see the full current
year without remembering what year we are in.
This option is also stolen from FreeBSD :^)
Additionally, validate args: prevent passing both -3 and -y at the
same time. Passing both `--three-month-mode` and `--year` to `cal`
doesn't make sense. You'd either want the one or the other.
Making it configurable in system settings :^)
The --start-day option can still overwrite this global default.
This change makes it no longer possible to use unveil: as we have
to load the Calendar config file, which might be in a dynamic location.
It's also neccessary to add `cpath` to the pledge, as opening a
nonexistent config file with Core::ConfigFile::open_for_app creates it.
Making all the other parts of the world happier :^)
Add a `--starting-day` (`-s`) option to be compatible with GNU cal,
which has a similar option. The GNU option takes allows passing either
an int or a day name. Let's do something similar using weekdays we
already have in AK/DateConstants.h.
Also add myself to the copyright header, as by now I've modified most of
the lines in this file.
...instead of putting a star `*` next to it. This makes `cal`s output
much prettier, and gets rid of one FIXME. :^)
Don't use the escape sequence from the deleted FIXME - \e[30;47m would
set the background to white and foreground to black - which presumably
wouldn't do much on a light-theme terminal. Instead use \e[7m which sets
the color as "inverted".
This fixes cal not highlighting the current day.
After this commit `cal` will show something like this among its output
for the 23rd day of the month
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23*24 25
26 27 28
Every other cal implementation just highlights the current day instead
of letting you specify a custom one to highlight. It doesn't seem to be
that useful, and is currently broken - no day gets highlighted at all,
because the `target_day` global is never written to.
Moreover, this complicates parsing the arguments. This commit also fixes
parsing a case where just a year is provided to `cal` - for example `cal
2023`.
This brings the function name in line with how we usually name those
functions, which is with a `read_` or `write_` prefix depending on what
they do.
While at it, make the internal `_impl` function private and not-virtual,
since there is no good reason to ever override that function.
- Rename to make it clear it's not just for promotion
- Understand 'p' for pawns
- Take a char parameter instead of StringView since it's always 1 char
Previously, the initial position would look like this:
rnbqkbnr//8/8/8/8//RNBQKBNR w KQkq - 0 1
Now, we correctly give pawns the P/p character in FEN output:
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
Also, we only ever have 1 or 0 characters for a piece, so let's return
`Optional<char>` instead of `StringView` from `char_for_piece()`.
This removes this slightly silly pattern:
`make<FooCommand>(FooCommand::from_string(s))`
Also, let's propagate OOM here, even if nobody reacts to it yet.
`Core::DeprecatedFile::absolute_path` uses `stat` to determine whether a
file exists, which will always fail after the first `unveil` call
`aplay` does. Reorder things so we don't get a stack trace thrown at us
for each file being played.
This is done mainly by implementing safe locking on the data structure
keeping the pointers to the PerContextState objects. Therefore, this now
eliminates the need for using LockRefPtr, as SpinlockProtected is enough
for the whole list.
The usage of HashMap in this class was questionable, and according to
Sahan Fernando (the original contributor to the VirGL work also known as
ccapitalK) there was no deep research on which data structure to use for
keeping all pointers to PerContextState objects.
Therefore, this structure is changed to IntrusiveList as the main reason
and advantage to use it is that handling OOM conditions is much more
simple, because if we succeeded to create a PerContextState object, we
can be sure now that inserting it to the list will not cause OOM error
condition.
This is quite useful for userspace applications that can't cope with the
restriction, but it's still useful to impose other non-configurable
restrictions by using jails.
