DipSwitch

# INSTALL INSTRUCTIONS: save as ~/.gdbinit
#
# DESCRIPTION: A user-friendly gdb configuration file.
#
# REVISION : 7.4 (22/05/2011)
#
# CONTRIBUTORS: mammon_, elaine, pusillus, mong, zhang le, l0kit,
#               truthix the cyberpunk, fG!, gln, dipswitch
#
# FEEDBACK: https://www.reverse-engineering.net

sbz

#include <sys/capability.h>
#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define nitems(x) (sizeof(x) / sizeof(x[0]))

int 
main(void) {

newyankeecodeshop

Background

Recently I noticed that Safari 10 for Mac/iOS had achieved 100% support for ES6. With that in mind, I began to look at the browser landscape and see how thorough the support in the other browsers. Also, how does that compare to Babel and its core-js runtime. According to an ES6 compatability table, Chrome, Firefox, and IE Edge have all surpassed what the Babel transpiler can generate in conjunction with runtime polyfills. The Babel/core-js combination achieves 71% support for ES6, which is quite a bit lower than the latest browsers provide.

It made me ask the question, "Do we need to run the babel es2015 preset anymore?", at least if our target audience is using Chrome, Firefox, or Safari.

It's clear that, for now, we can't create a site or application that only serves ES6. That will exclude users of Internet Explorer and various older browsers running on older iOS and Android devices. For example, Safari on iOS 9 has pretty mediocre ES6 support.

benoitdevos

package mycompany.myappp.config;

import org.apache.commons.io.IOUtils;
import org.springframework.context.annotation.Configuration;
import org.springframework.http.HttpInputMessage;
import org.springframework.http.HttpOutputMessage;
import org.springframework.http.MediaType;
import org.springframework.http.converter.AbstractHttpMessageConverter;
import org.springframework.http.converter.HttpMessageConverter;
import org.springframework.http.converter.HttpMessageNotReadableException;

probonopd

Think twice before abandoning Xorg. Wayland breaks everything!

Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better off avoiding Wayland.

Wayland solves no issues I have but breaks almost everything I need. Even the most basic, most simple things (like xkill) - in this case with no obvious replacement. And usually it stays broken, because the Wayland folks mostly seem to care about Automotive, Gnome, maybe KDE - and alienating everyone else (e.g., people using just an X11 window manager or something like GNUstep) in the process.

The Wayland project seems to operate like they were starting a greenfield project, whereas at the same time they try to position Wayland as "the X11 successor", which would clearly require a lot of thought about not breaking, or at least providing a smooth upgrade path for, existing software.

In fact, it is merely an incompatible alternative, and not e

GuillaumeDesforges

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Run server (dev)",
            "type": "node-terminal",
            "request": "launch",