Use open source GPG key pairs and Keyoxide to prove your identity on Mastodon. Read More at Enable Sysadmin
The post How to verify Mastodon users with cryptography appeared first on Linux.com.
Use open source GPG key pairs and Keyoxide to prove your identity on Mastodon. Read More at Enable Sysadmin
The post How to verify Mastodon users with cryptography appeared first on Linux.com.
Good evening 🙂 A quick note, tonight: I’ve long thought that
ephemerons
are primitive and can’t be implemented with mark functions and/or
finalizers, but today I think I have a counterexample.
For context, one of the goals of the GC implementation I have been
working on on is to replace
Guile‘s current use of the Boehm-Demers-Weiser (BDW) conservative
collector. Of course, changing a
garbage collector for a production language runtime is risky, and for Guile one of the mitigation
strategies for this work is that the new collector is behind an abstract API
whose implementation can be chosen at compile-time, without requiring
changes to user code. That way we can first switch to
BDW-implementing-the-new-GC-API, then switch the implementation behind
that API to something else.
Abstracting GC is a tricky problem to get right, and I thank the MMTk
project for showing that this is possible — you
have user-facing APIs that need to be implemented by concrete collectors,
but also extension points so that the user can provide some compile-time
configuration too, for example to provide field-tracing visitors that take into account how a user wants to lay out objects.
Anyway. As we discussed last time, ephemerons are usually have explicit
support from the GC, so we need an ephemeron abstraction as part of the
abstract GC API. The question is, can BDW-GC provide an implementation of
this API?
I think the answer is “yes, but it’s very gnarly and will kill
performance so bad that you won’t want to do it.”
the contenders
Consider that the primitives that you get with BDW-GC are custom mark
functions, run on objects when they are found to be live by the mark
workers; disappearing links, a kind of weak reference; and finalizers, which receive the object being finalized, can allocate, and indeed can resurrect the object.
BDW-GC’s finalizers are a powerful
primitive, but not one that is useful for implementing the “conjunction”
aspect of ephemerons, as they cannot constrain the marker’s idea of
graph connectivity: a finalizer can only prolong the life of an object subgraph,
not cut it short. So let’s put finalizers aside.
Weak references have a tantalizingly close kind of conjunction property:
if the weak reference itself is alive, and the referent is also
otherwise reachable, then the weak reference can be dereferenced.
However this primitive only involves the two objects E and K; there’s no
way to then condition traceability of a third object V to E and K.
We are left with mark functions. These are an extraordinarily powerful
interface in BDW-GC, but somewhat expensive also: not inlined, and going
against the grain of what BDW-GC is really about (heaps in which the
majority of all references are conservative). But, OK. They way they
work is, your program allocates a number of GC “kinds”, and associates
mark functions with those kinds. Then when you allocate objects, you
use those kinds. BDW-GC will call your mark functions when tracing an object of those kinds.
Let’s assume firstly that you have a kind for ephemerons; then when you
go to mark an ephemeron E, you mark the value V only if the key K has
been marked. Problem solved, right? Only halfway: you also have to
handle the case in which E is marked first, then K. So you publish E to
a global hash table, and… well. You would mark V when you mark a K for
which there is a published E. But, for that you need a hook into
marking V, and V can be any object…
So now we assume additionally that all objects are allocated with
user-provided custom mark functions, and that all mark functions check
if the marked object is in the published table of pending ephemerons,
and if so marks values. This is essentially what a proper ephemeron
implementation would do, though there are some optimizations one can do
to avoid checking the table for each object before the mark stack runs
empty for the first time. In this case, yes you can do it!
Additionally if you register disappearing links for the K field in each
E, you can know if an ephemeron E was marked dead in a previous
collection. Add a pre-mark hook (something BDW-GC provides) to clear
the pending ephemeron table, and you are in business.
yes, but no
So, it is possible to implement ephemerons with just custom mark
functions. I wouldn’t want to do it, though: missing the
mostly-avoid-pending-ephemeron-check optimization would be devastating,
and really what you want is support in the GC implementation. I think
that for the BDW-GC implementation in
whippet I’ll just implement
weak-key associations, in which the value is always marked strongly
unless the key was dead on a previous collection, using disappearing
links on the key field. That way a (possibly indirect) reference from a
value V to a key K can indeed keep K alive, but oh well: it’s a
conservative approximation of what should happen, and not worse than
what Guile has currently.
Good night and happy hacking!
We’ve just released WebStorm 2022.3, the third major update of the year for our JavaScript IDE. We hope that the new functionality, along with the other enhancements we’ve added to it, will make your coding experience with WebStorm more productive and enjoyable.
Here are the highlights:
Visit our website to learn more and start using WebStorm 2022.3 today.
#TikTok #PakistaniTikToker #ViralVideos #TikTokerHameedkhan #PunjabPolice #Lahore
Follow Us on Facebook: https://www.facebook.com/urdupoint.network/
Follow Us on Twitter: https://twitter.com/DailyUrduPoint
Follow Us on Instagram: https://www.instagram.com/urdupoint_com/
Visit Us on Web: https://www.urdupoint.com/
Hi everyone,
I am very proud to announce the latest release of Moodle LMS 4.1!
Our latest release builds on the user experience enhancements and features of Moodle LMS 4.0, giving more possibilities to build better learning experiences and for learners to find what they want when they need it. As a Long Term Support release, Moodle LMS 4.1 also ensures security support for three years – 18 months more than the standard edition.
A smoother experience with UX enhancements
In the latest release of Moodle LMS 4.1 UX improvements have been made to Database activity, including a useful start page, an improved Image gallery preset, plus three new presets: Journal, Proposals and Resources, which can be previewed. These four ready-made presets mean that you can use and adapt one of the four on offer to fit your needs, without having to build a layout from nothing. The presets can also be previewed before use so that you can be sure it is the layout you are looking for. These UX improvements have been supported by the Moodle Users Association.
Caption: Moodle LMS 4.1 comes with four presets to use as a starting point.
UX improvements have also been made to the Gradebook to make it easier to navigate. With Moodle LMS 4.1, a new ‘Grades summary’ page has been added to provide a summary of the grade averages for each course activity and can be filtered by activity. There is an improved ‘User report’ with a more modern design and collapsible categories, and a ‘Single view report’ with improved design and the ability to simply search by user, group or grade item, and more easily do bulk actions. This allows teachers and trainers to more easily analyse the success of formative and summative assessments and inform improvements to course design.
Caption: The new ‘Grades summary’ page provides a summary of the grade averages for each course activity.
Maximising the use of BigBlueButton
Moodle LMS 4.1 also includes improvements to BigBlueButton, the open source virtual classroom integrated into Moodle as a standard feature, including the ability to invite external guests to a BigBlueButton video conferencing session.
Improving the text editor
In Moodle LMS 4.1, TinyMCE 6 is included as an additional text editor, alongside the standard Atto editor. TinyMCE 6 is a modern and intuitive text editor that is accessible and offers an improved user experience.
Caption: TinyMCE 6 is included as an additional editor alongside the standard Atto editor.
Manage and collaborate with ease using the Moodle Question bank
Moodle LMS 4.1 features improvements to the Question bank features, making it easier for teachers and course creators to manage and collaborate on quiz questions. These improvements include inline editing of the question title, a new “Modified by” column to see who modified a question, and a new “Last used” column to see when a question was last attempted by a student.
More control over custom report settings
Custom reports now include a number of new useful report sources, including Badges, Comments, Notes, Course participants, Blogs, and Files. There is a new custom report settings page, allowing the admin to limit the number of reports and disable live editing.
Other key improvements
More helpful additions in the Moodle LMS 4.1 release include:
Find out more about Moodle LMS 4.1 and watch our short videos on Database activity, the Gradebook and Customer reports.
Enjoy!
Marie
I have been using the Drupal dependency injection system for a while now, even giving talks and writing articles on the subject. As the release of Drupal 10 is just around the corner I have been thinking more about how to override dependencies to plugin classes.
I wanted to share a trick to overriding dependency injection that will make your life easier. The Drupal codebase itself does not use this trick, but it seems that many contributed modules have started to use this trick to create plugin classes.
In this article I will go through how to add dependency injection to Drupal classes in two different patterns.
The first pattern will create problems and will require quite a bit more typing and repeating of code. The second pattern is much easier to use and will make life easier going forward.
The following block of code shows a very basic Drupal Block class that doesn’t do anything. This will be the basis of the rest of this article.
<?php namespace DrupalmymodulePluginBlock;
use DrupalCoreBlockBlockBase;
/**
* Provides a 'TEST' block.
*
* @Block(
* id = "mymodule_block",
* label = "A testing block",
* admin_label = @Translation("A testing block"),
* )
*/
class TestBlock extends BlockBase {
/**
* {@inheritdoc}
*/
public function build() {
$build = [];
return $build;
}
}
What I am going to do with this block is inject a service to perform route matching. In Drupal there are a couple of services to do this, but I will be using the current_route_match service to look for the service.