sblom

=LET(MakeAcc,LAMBDA(item1,item2,MAKEARRAY(2,1,LAMBDA(row,col,IF(row=1,item1,item2)))),
LAMBDA(arr,INDEX(REDUCE({0;-1},FILTER(arr,MAP(arr,LAMBDA(x,ISNUMBER(x))),{0}),LAMBDA(accum,time,
    LET(total,INDEX(accum,1),start,INDEX(accum,2),
    IF(start<>-1,
        MakeAcc(total+(time-start)*24,-1),
        MakeAcc(total,time)
    )
))),1)))

kunalspathak

Purpose

This report compares the startup performance of paint.net version 5.0.3 against dotnet version 8.0.0-preview.4.23259.5. The application was ran on Intel and Ampere machines. To make sure we are doing a comparable measurements, the application was started by affinitizing the number of cores. For x64, it was set to 0x5555 and for arm64, it was set to 0xFF. They both were ran using start /AFFINITY <mask> /WAIT dotnet.exe paintdotnet.dll. There are PaintDotnetTrace events that are logged. I used PerfView to profile the application and then studied the call stack between Started (first line of the Main() method) and Ready (all data-structures are initialized) events. The measurements are taken on Intel Cascade lake (x64) and Ampere (arm4) machine.

You will see lot of screenshots of callstack. In all of them, left side indicates x64 profile and right indicates arm64 profile.

Table of contents

• [TL

mattpodwysocki

Iterables, AsyncIterables, Observables, Oh My!

I know there is a lot of confusion around Observables, Iterables, AsyncIterables and AsyncObservables. Let's try to break this down and the reasons for each.

Pull versus Push Collections

When it comes to collections, you have two ways of thinking about collections, push versus pull. With pull, the consumer is in control of when you get the items, but with push, you get the values when the producer is ready.

Pull Based Collections

nicebyte

#pragma once

#define DYN_ARR_OF(type) struct  { \
  type *data; \
  type *endptr; \
  uint32_t capacity; \
}

#if !defined(__cplusplus)
#define decltype(x) void*

Avaq

const I  = x => x
const K  = x => y => x
const A  = f => x => f (x)
const T  = x => f => f (x)
const W  = f => x => f (x) (x)
const C  = f => y => x => f (x) (y)
const B  = f => g => x => f (g (x))
const S  = f => g => x => f (x) (g (x))
const S_ = f => g => x => f (g (x)) (x)
const S2 = f => g => h => x => f (g (x)) (h (x))

windytan

# Oona Räisänen 2013
# http://windytan.com

# ssh-keygen -l -f ~/.ssh/id_rsa.pub | perl emoji.pl

@emoji = qw( 🌀  🌂  🌅  🌈  🌙  🌞  🌟  🌠  🌰  🌱  🌲  🌳  🌴  🌵  🌷  🌸 
             🌹  🌺  🌻  🌼  🌽  🌾  🌿  🍀  🍁  🍂  🍃  🍄  🍅  🍆  🍇  🍈 
             🍉  🍊  🍋  🍌  🍍  🍎  🍏  🍐  🍑  🍒  🍓  🍔  🍕  🍖  🍗  🍘 
             🍜  🍝  🍞  🍟  🍠  🍡  🍢  🍣  🍤  🍥  🍦  🍧  🍨  🍩  🍪  🍫 
             🍬  🍭  🍮  🍯  🍰  🍱  🍲  🍳  🍴  🍵  🍶  🍷  🍸  🍹  🍺  🍻 

domenic

This article has been given a more permanent home on my blog. Also, since it was first written, the development of the Promises/A+ specification has made the original emphasis on Promises/A seem somewhat outdated.

You're Missing the Point of Promises

Promises are a software abstraction that makes working with asynchronous operations much more pleasant. In the most basic definition, your code will move from continuation-passing style:

getTweetsFor("domenic", function (err, results) {
 // the rest of your code goes here.

ckirkendall

The Objective

This language experiment was designed to show how parametric polymorphism and type classes are
implemented in different languages. The implementation languages where chosen out of personal
preference. I am well aware it's not complete and would love for you to help me with that.  If
you don't see your favorite language please add it as a comment.  I am also not an expert in all
of these languages but did try to make them as idiomatic as possible. If you believe there is a
better solution please leave a comment with the implementation.

The Code

piscisaureus

Locate the section for your github remote in the .git/config file. It looks like this:

[remote "origin"]
	fetch = +refs/heads/*:refs/remotes/origin/*
	url = git@github.com:joyent/node.git

Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:

kleinmatic

Open Conference Expectations

This document lays out some baseline expectations between conference speakers and conference presenters. It was prepared by three experienced conference speakers -- one of whom has also organized conferences -- and influenced by many others. Its goal is to let speakers know what they might reasonably expect from a conference, in exchange for the hours we expect them to spend researching, preparing, and rehearsing, and the time they will spend away from home and family.

We believe that all speakers should reasonably expect these things, not just speakers who are known to draw large crowds, because no one is a rockstar but more people should have the chance to be one. We believe that conferences are better -- and, dare we say, more diverse -- when the people speaking are not just the people who can afford to get themselves there, either because their company paid or they foot the bill themselves.

These expectations should serve as *a starting point for discussion between sp