Site Overview

Posted on by Michael G
Have you ever thought of a new way to share your content online?

Look around you.. …. regular content sharing platforms has become so overcrowded …..such that it has now become hard for new content creators to find a space in the online world…

How do I grow as a content creator in today’s world??

Be part of a community that’ll change how people share content online, ….

be part of a community where we grow together, …..
be part of a community where you’re free to express yourself ..and at the same time,, be seen by Google…within a very short period of time………………….

So what’s this site all about????

It’s an online community where you get to make and chat with new friends, …..

publish content that gets indexed by Google in less than 48 hours, …….

Free Guest posting services………

making money with affiliate marketing,….

You also get to watch Breaking news live from around the world non-stop

With this site,,,,, you can also Create separate groups of different interest for free……

So what are you waiting for………… Visit https://universalfamily.com.ng/ to Sign up for an account now..

Nextide Blog: Oxford’s Mathematical Institute: Streamlining Academic Visitor Applications with Maestro

Posted on by Michael G

In the dynamic world of academia, managing academic visitor applications efficiently is crucial. The University of Oxford Mathematical Institute has embraced the power of Drupal  and the Maestro module to streamline and enhance their academic visitor application process. Let’s delve into the seamless workflow that facilitates this crucial task.

 

The General Design

Initiation: Academics or their assistants initiate the process by filling in a comprehensive multi-page webform tailored to their needs.

Confirmation and Workflow Trigger: Upon submission, a confirmation email is sent to the initiator by the webform email handler, and the workflow is triggered.

Andy Wingo: v8’s precise field-logging remembered set

Posted on by Michael G

A remembered set is used by a garbage collector to identify graph
edges between partitioned sub-spaces of a heap. The canonical example
is in generational collection, where you allocate new objects in
newspace, and eventually promote survivor objects to oldspace. If
most objects die young, we can focus GC effort on newspace, to avoid
traversing all of oldspace all the time.

Collecting a subspace instead of the whole heap is sound if and only if
we can identify all live objects in the subspace. We start with some
set of roots that point into the subspace from outside, and then
traverse all links in those objects, but only to other objects within
the subspace.

The roots are, like, global variables, and the stack, and registers; and
in the case of a partial collection in which we identify live objects
only within newspace, also any link into newspace from other spaces
(oldspace, in our case). This set of inbound links is a remembered
set.

There are a few strategies for maintaining a remembered set. Generally
speaking, you start by implementing a write barrier that intercepts all
stores in a program. Instead of:

obj[slot] := val;

You might abstract this away:

write_slot(obj, sizeof obj, &obj[slot], val);

As you can see, it’s quite an annoying transformation to do by hand;
typically you will want some sort of language-level abstraction that
lets you keep the more natural syntax. C++ can do this pretty well, or
if you are implementing a compiler, you just add this logic to the
code generator.

Then the actual write barrier… well its implementation is twingled up
with implementation of the remembered set. The simplest variant is a
card-marking scheme, whereby the heap is divided into equal-sized
power-of-two-sized cards, and each card has a bit. If the heap is
also divided into blocks (say, 2 MB in size), then you might divide
those blocks into 256-byte cards, yielding 8192 cards per block. A
barrier might look like this:

void write_slot(ObjRef obj, size_t size,
                SlotAddr slot, ObjRef val) {
  obj[slot] := val; // Start with the store.

  uintptr_t block_size = 1<<21;
  uintptr_t card_size = 1<<8;
  uintptr_t cards_per_block = block_size / card_size;

  uintptr_t obj_addr = obj;
  uintptr_t card_idx = (obj_addr / card_size) % cards_per_block;

  // Assume remset allocated at block start.
  void *block_start = obj_addr & ~(block_size-1);
  uint32_t *cards = block_start;

  // Set the bit.
  cards[card_idx / 32] |= 1 << (card_idx % 32);
}

Then when marking the new generation, you visit all cards, and for all
marked cards, trace all outbound links in all live objects that begin on
the card.

Card-marking is simple to implement and simple to statically allocate as
part of the heap. Finding marked cards takes time proportional to the
size of the heap, but you hope that the constant factors and SIMD
minimize this cost. However iterating over objects within a card can be
costly. You hope that there are few old-to-new links but what do you
know?

In Whippet I have been struggling a
bit with sticky-mark-bit generational
marking,
in which new and old objects are not spatially partitioned. Sometimes
generational collection is a win, but in benchmarking I find that often
it isn’t, and I think Whippet’s card-marking
barrier
is at fault: it is simply too imprecise. Consider firstly that our
write barrier applies to stores to slots in all objects, not just those
in oldspace; a store to a new object will mark a card, but that card may
contain old objects which would then be re-scanned. Or consider a store
to an old object in a more dense part of oldspace; scanning the card may
incur more work than needed. It could also be that Whippet is being too
aggressive at re-using blocks for new allocations, where it should be
limiting itself to blocks that are very sparsely populated with old
objects.

what v8 does

There is a tradeoff in write barriers between the overhead imposed on
stores, the size of the remembered set, and the precision of the
remembered set. Card-marking is relatively low-overhead and usually
small as a fraction of the heap, but not very precise. It would be
better if a remembered set recorded objects, not cards. And it would be
even better if it recorded slots in objects, not just objects.

V8 takes this latter strategy: it has per-block remembered sets which
record slots containing “interesting” links. All of the above words
were to get here, to take a brief look at its remembered set.

The main operation is
RememberedSet::Insert.
It takes the MemoryChunk (a block, in our language from above) and the
address of a slot in the block. Each block has a remembered set; in
fact, six remembered
sets
for some reason. The remembered set itself is a
SlotSet,
whose interesting operations come from
BasicSlotSet.

The structure of a slot set is a bitvector partitioned into
equal-sized, possibly-empty
buckets.
There is one bit per slot in the block, so in the limit the size
overhead for the remembered set may be 3% (1/32, assuming compressed
pointers). Currently each bucket is 1024 bits (128
bytes),
plus the 4 bytes for the bucket pointer itself.

Inserting into the slot
set
will first allocate a bucket (using C++ new) if needed, then load the
“cell” (32-bit
integer)
containing the slot. There is a template parameter declaring whether
this is an atomic or normal load. Finally, if the slot bit in the cell
is not yet set, V8 will set the bit, possibly using atomic
compare-and-swap.

In the language of Blackburn’s Design and analysis of field-logging
write
barriers,
I believe this is a field-logging barrier, rather than the bit-stealing
slot barrier described by Yang et al in the 2012 Barriers
Reconsidered, Friendlier
Still!.
Unlike Blackburn’s field-logging barrier, however, this remembered set
is implemented completely on the side: there is no in-object remembered
bit, nor remembered bits for the fields.

On the one hand, V8’s remembered sets are precise. There are some
tradeoffs, though: they require off-managed-heap dynamic allocation for
the buckets, and traversing the remembered
sets
takes time proportional to the whole heap size. And, should V8 ever
switch its minor mark-sweep generational
collector
to use sticky mark bits, the lack of a spatial partition could lead to
similar problems as I am seeing in Whippet. I will be interested to see
what they come up with in this regard.

Well, that’s all for today. Happy hacking in the new year!

New year, new gallery app and NewPipe news

Posted on by Michael G

TWIF generated on Thursday, 04 Jan 2024, Week 1

Community News

@Licaon_Kter brings news from suite lands:

As last years TWIF49 covered, the beloved Simple Mobile Tools suite of apps have an unclear future, FOSS wise at least. This week we have 2 pieces of news about that.

The bad one, it was discovered (thanks to our long time contributor @Izzy) that Simple Gallery Pro was containing a library that while itself being FOSS depends on some Google proprietary ones, so all affected versions, basically all, were removed.

When a piece of FOSS software has issues in development, or certain people think as much, the one solution universally praised is “forking”, meaning it will find a new home, name and people that care to carry it further. There’s a whole discussion about where exactly those people willing to help were for Simple Mobile Tools before the actual sale, but we won’t have it here now. What we can say is that at least @naveensingh and others have rallied under the Fossify organization and try to continue the Simple apps legacy.

Hence the good news, Fossify Gallery is their first app to be included in F-Droid. Yes, it’s build reproducible, yes it’s not orange but more green, and yes it will miss the Panoramic view that depends on Google proprietary libs, but it’s fully FOSS. More too come next…

SimpleX Chat was updated to 5.4.2 but only the armv7 flavour. arm64 should come in the next cycle.

@linsui tells us that:

Both Arcticons and Arcticons Black were updated to 8.3.1 and are now build reproducible, meaning that if you had them installed please uninstall and reinstall the new versions so you get future updates too.

Screenshot sharer was removed only to be replaced with the newly included and reproducible QuickShot: Share Screenshot, hence do lookup the new app and uninstall the old one.

Tux Paint was updated to 0.9.31, while being an app for children it might “scare” their parents as in this update “stamps are now integrated into the app, raising the app size to almost 250Mb”. So be sure to update on Wi-Fi instead.

NewPipe’s very own Tobias Groza dropped by to inform us that:

NewPipe published two new versions 0.26.0 and 0.26.1 adding support for more content from channels (playlists, shorts, about, …) and higher image quality in the last two weeks.

We have also written a blog post summarizing the important things from 2023 (e.g. implemented features, the newly founded NewPipe e.V., temporary removal of our homepage from Google search) and taking a look at the plans for 2024 (adding support for better search filters and starting the modernization of the app).

We also announce some maintainer changes: I will leave the project due to not having much spare time, Stypox and AudricV are taking more responsibilities, and the project is looking for new additional maintainers to fill the gap and be able to implement the plans for 2024.

NOTE: These NewPipe updates are delayed in F-Droid currently and the team is investigating why.

Newly Added Apps

2 more apps were newly added
  • Cuscon – An icon pack with varied shapes.
  • Onyx – Your new app to guide you around La Doua Campus.

Updated Apps

138 more apps were updated

Thank you for reading this week’s TWIF 🙂
Please subscribe to the RSS feed in your favourite RSS application to be updated of new TWIFs when they come up.

You are welcome to join the TWIF forum thread if you have any news from around the community, maybe it will be featured next week 😉

The world’s smallest PNG

Posted on by Michael G
The smallest PNG file is 67 bytes. It’s a single black pixel. Here’s what it looks like, zoomed in 200×: The rest of this post describes this file in more detail and tries to explain how PNGs work along the way. There’s a big twist at the end, if that excites you. But I hope you’re just excited to learn about PNGs. ↫ Evan Hahn I know way too much about PNGs now, information I won’t ever need but am glad to have.