andrewloux

So here's the problem.

I use this helper function to retrieve a possibly rearranged list in its new order. This happens here:

Template.list.get_list = function(param){
  var ret = [];
  $( "li.list_element" ).each(function() {
    if($(this).is(':visible')){
        ret.push(   Links.findOne({_id:$(this).attr('id')})   );

andrewloux

A link to the page where it is deployed

After attempting to control using Session, the YouTube embedded player stops being responsive.

Here is the setting up of the YouTube API temporarily placed in the HTML file:

mixtape.html

<script>

andrewloux

# 238  R: 13.285000 usecs RT: 12440791.662667 usecs
Digraph G {
6359376964500652.6359376964501320 [label="e10__t3__NFS3_WRITE_CALL_TYPE\nDEFAULT"]
6359376964500652.6359376964518840 [label="e10__t3__NFS_CACHE_BLOCK_OP_TYPE\nNFSCACHE_WRITE"]
6359376964500652.6359376964541175 [label="e10__t3__NFS3_WRITE_REPLY_TYPE\nDEFAULT"]
6359376964500652.6359376964501320 -> 6359376964500652.6359376964518840 [label="R: 5.840000 us"]
6359376964500652.6359376964518840 -> 6359376964500652.6359376964541175 [label="R: 7.445000 us"]
}

andrewloux

# 238  R: 13.285000 usecs RT: 12440791.662667 usecs
Digraph G {
6359376964500652.6359376964501320 [label="A"]
6359376964500652.6359376964518840 [label="B"]
6359376964500652.6359376964541175 [label="C"]
6359376964500652.6359376964501320 -> 6359376964500652.6359376964518840 [label="R: 5.840000 us"]
6359376964500652.6359376964518840 -> 6359376964500652.6359376964541175 [label="R: 7.445000 us"]
}

andrewloux

Waterloo Computer Science

• AF: 78
• C+V: 85
• Eng: 85
• Random Elective: 90
• CompSci: 85
• Religion: 95

Current Timetable

• C+V

andrewloux

obj-m += chardev.o
all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

andrewloux

How are partitions assigned in a consumer group?

This is based on the partition assignment strategy configuration, an important note here is that this is a topic-specific configuration. It can only be used to describe the strategy used to assign partitions to a specific consumer group.

The default strategy is called the RangeAssignor strategy. In this strategy, we divide the number of partitions over the number of consumer instances, and assign one by one. If the division does not result in a nice round number, the first few consumer instances are assigned more partitions.

Example

Suppose there are two consumers C₀ and C₁, two topics t₀ and t₁, and each topic has 3 partitions, resulting in the following partitions: t₀p₀, t₀p₁, t₀p₂, t₁p₀, t₁p₁, and t₁p₂

andrewloux

Historically, all memory on x86 architectures were equally accessibly by all CPUs on the system. This is an effective implementation, but there's increased bandwidth on the bus, and the more CPUs you have, the further away from the memory it is. This layout is called Uniform Memory Access.

Modern x86 architectures introuduce the concept of memory nodes (also referred to elsewhere as zones or cells), where new writes are associated with a CPU's memory node. The nodes are connected by a bus, so all the memory is still accessible via any CPU, but of course, we have faster memory access time for CPUs accessing local nodes.

When you have a virtualization layer on top, and you are scheduling workloads, you can take advantage of this by pinning processes to specific CPUs.

andrewloux

type WorkflowRun interface {
	client.WorkflowRun
}

type customWorkflowRun struct {
	client.WorkflowRun
	cancelWorkflowFunc context.CancelFunc
}

type Client interface {

andrewloux

#!/bin/bash

set -e
set -o pipefail

# This is a simple wrapper script for the "hasura" command that enforces the version
# and bails out if the hasura version is incorrect.

# Replace "hasura" with the actual path to the hasura binary, if necessary.
HASURA_BINARY="hasura"