Rupert  Beatty

Rupert Beatty

1666946040

Render: UIKit A-là SwiftUI.framework [min Deployment Target iOS10]

Render

CoreRender is a SwiftUI inspired API for UIKit (that is compatible with iOS 10+ and ObjC).

Introduction

  • Declarative: CoreRender uses a declarative API to define UI components. You simply describe the layout for your UI based on a set of inputs and the framework takes care of the rest (diff and reconciliation from virtual view hierarchy to the actual one under the hood).
  • Flexbox layout: CoreRender includes the robust and battle-tested Facebook's Yoga as default layout engine.
  • Fine-grained recycling: Any component such as a text or image can be recycled and reused anywhere in the UI.

TL;DR

Let's build the classic Counter-Example.

The DSL to define the vdom representation is similiar to SwiftUI.

func makeCounterBodyFragment(context: Context, coordinator: CounterCoordinator) -> OpaqueNodeBuilder {
  Component<CounterCoordinator>(context: context) { context, coordinator in
    VStackNode {
      LabelNode(text: "\(coordinator.count)")
        .textColor(.darkText)
        .background(.secondarySystemBackground)
        .width(Const.size + 8 * CGFloat(coordinator.count))
        .height(Const.size)
        .margin(Const.margin)
        .cornerRadius(Const.cornerRadius)
      HStackNode {
        ButtonNode()
          .text("TAP HERE TO INCREASE COUNT")
          .setTarget(coordinator, action: #selector(CounterCoordinator.increase), for: .touchUpInside)
          .background(.systemTeal)
          .padding(Const.margin * 2)
          .cornerRadius(Const.cornerRadius)
      }
    }
    .alignItems(.center)
    .matchHostingViewWidth(withMargin: 0)
  }
}

screen

Label and Button are just specialized versions of the Node<V: UIView> pure function. That means you could wrap any UIView subclass in a vdom node. e.g.


Node(UIScrollView.self) {
  Node(UILabel.self).withLayoutSpec { spec in 
    // This is where you can have all sort of custom view configuration.
  }
  Node(UISwitch.self)
}

The withLayoutSpec modifier allows to specify a custom configuration closure for your view.

Coordinators are the only non-transient objects in CoreRender. They yeld the view internal state and they are able to manually access to the concrete view hierarchy (if one desires to do so).

By calling setNeedsReconcile the vdom is being recomputed and reconciled against the concrete view hiearchy.

class CounterCoordinator: Coordinator{
  var count: UInt = 0

  func incrementCounter() {
    self.count += 1                      // Update the state.
    setNeedsReconcile()                  // Trigger the reconciliation algorithm on the view hiearchy associated to this coordinator.
  }
}

Finally, Components are yet again transient value types that bind together a body fragment with a given coordinator.

class CounterViewCoordinator: UIViewController {
  var hostingView: HostingView!
  let context = Context()

  override func loadView() {
    hostingView = HostingView(context: context, with: [.useSafeAreaInsets]) { context in
      makeCounterBodyFragment(context: context, coordinator: coordinator)
    }
    self.view = hostingView
  }
    
  override func viewDidLayoutSubviews() {
    hostingView.setNeedsLayout()
  }
}

Components can be nested in the node hierarchy.


func makeFragment(context: Context) {
  Component<FooCoordinator>(context: context) { context, coordinator in
    VStackNode {
      LabelNode(text: "Foo")
      Component<BarCoordinator>(context: context) { context, coordinator in
        HStackNode {
          LabelNode(text: "Bar")
          LabelNode(text: "Baz")
        }
      }
    }
  }
}

Use it with SwiftUI

Render nodes can be nested inside SwiftUI bodies by using CoreRenderBridgeView:


struct ContentView: View {
  var body: some View {
    VStack {
      Text("Hello From SwiftUI")
      CoreRenderBridgeView { context in
        VStackNode {
          LabelNode(text: "Hello")
          LabelNode(text: "From")
          LabelNode(text: "CoreRender")
        }
          .alignItems(.center)
          .background(UIColor.systemGroupedBackground)
          .matchHostingViewWidth(withMargin: 0)
      }
      Text("Back to SwiftUI")
    }
  }
}

struct ContentView_Previews: PreviewProvider {
  static var previews: some View {
    ContentView()
  }
}

Credits:

Layout engine:

Download Details:

Author: Alexdrone
Source Code: https://github.com/alexdrone/Render 

#swift #virtual #ios 

Render: UIKit A-là SwiftUI.framework [min Deployment Target iOS10]

PaddedViews.jl: Add Virtual Padding to The Edges Of an Array

PaddedViews

Summary

PaddedViews provides a simple wrapper type, PaddedView, to add "virtual" padding to any array without copying data. Edge values not specified by the array are assigned a fillvalue. Multiple arrays may be "promoted" to have common indices using the paddedviews function.

PaddedView arrays are read-only, meaning that you cannot assign values to them. The original array may be extracted using A = parent(P), where P is a PaddedView.

Examples

For padding a single array:

julia> a = collect(reshape(1:9, 3, 3))
3×3 Array{Int64,2}:
 1  4  7
 2  5  8
 3  6  9

julia> PaddedView(-1, a, (4, 5))
4×5 PaddedView(-1, ::Array{Int64,2}, (Base.OneTo(4), Base.OneTo(5))) with eltype Int64:
  1   4   7  -1  -1
  2   5   8  -1  -1
  3   6   9  -1  -1
 -1  -1  -1  -1  -1

 julia> PaddedView(-1, a, (1:5,1:5), (2:4,2:4))
 5×5 PaddedView(-1, OffsetArray(::Array{Int64,2}, 2:4, 2:4), (1:5, 1:5)) with eltype Int64 with indices 1:5×1:5:
 -1  -1  -1  -1  -1
 -1   1   4   7  -1
 -1   2   5   8  -1
 -1   3   6   9  -1
 -1  -1  -1  -1  -1

 julia> PaddedView(-1, a, (0:4, 0:4))
 5×5 PaddedView(-1, ::Array{Int64,2}, (0:4, 0:4)) with eltype Int64 with indices 0:4×0:4:
  -1  -1  -1  -1  -1
  -1   1   4   7  -1
  -1   2   5   8  -1
  -1   3   6   9  -1
  -1  -1  -1  -1  -1

julia> PaddedView(-1, a, (5,5), (2,2))
5×5 PaddedView(-1, OffsetArray(::Array{Int64,2}, 2:4, 2:4), (Base.OneTo(5), Base.OneTo(5))) with eltype Int64:
 -1  -1  -1  -1  -1
 -1   1   4   7  -1
 -1   2   5   8  -1
 -1   3   6   9  -1
 -1  -1  -1  -1  -1

For padding multiple arrays to have common indices:

julia> a1 = reshape([1, 2, 3], 3, 1)
3×1 Array{Int64,2}:
 1
 2
 3

julia> a2 = [4 5 6]
1×3 Array{Int64,2}:
 4  5  6

julia> a1p, a2p = paddedviews(-1, a1, a2);

julia> a1p
3×3 PaddedView(-1, ::Array{Int64,2}, (Base.OneTo(3), Base.OneTo(3))) with eltype Int64:
 1  -1  -1
 2  -1  -1
 3  -1  -1

julia> a2p
3×3 PaddedView(-1, ::Array{Int64,2}, (Base.OneTo(3), Base.OneTo(3))) with eltype Int64:
  4   5   6
 -1  -1  -1
 -1  -1  -1

If you want original arrays in the center of padded results:

julia> a1 = reshape([1, 2, 3], 3, 1)
3×1 Array{Int64,2}:
 1
 2
 3

julia> a2 = [4 5 6]
1×3 Array{Int64,2}:
 4  5  6

julia> a1p, a2p = sym_paddedviews(-1, a1, a2);

julia> a1p
3×3 PaddedView(-1, ::Array{Int64,2}, (1:3, 0:2)) with eltype Int64 with indices 1:3×0:2:
 -1  1  -1
 -1  2  -1
 -1  3  -1

julia> a2p
3×3 PaddedView(-1, ::Array{Int64,2}, (0:2, 1:3)) with eltype Int64 with indices 0:2×1:3:
 -1  -1  -1
  4   5   6
 -1  -1  -1

We can use dims keyword to specify the direction of padding for the output arrays as shown above. They can be integers or tuple of integers.

julia> a1p, a2p = paddedviews(-1, a1, a2; dims=1);

julia> a1p
3×1 PaddedView(-1, ::Matrix{Int64}, (Base.OneTo(3), Base.OneTo(1))) with eltype Int64:
 1
 2
 3

julia> a2p
3×3 PaddedView(-1, ::Matrix{Int64}, (Base.OneTo(3), Base.OneTo(3))) with eltype Int64:
  4   5   6
 -1  -1  -1
 -1  -1  -1

julia> a1p, a2p = sym_paddedviews(-1, a1, a2; dims=2);

julia> a1p
3×3 PaddedView(-1, ::Matrix{Int64}, (1:3, 0:2)) with eltype Int64 with indices 1:3×0:2:
 -1  1  -1
 -1  2  -1
 -1  3  -1

julia> a2p
1×3 PaddedView(-1, ::Matrix{Int64}, (1:1, 1:3)) with eltype Int64 with indices 1:1×1:3:
 4  5  6

Download Details:

Author: 
Source Code: https://github.com/JuliaArrays/PaddedViews.jl   
License: 

#julia #virtual #views 

PaddedViews.jl: Add Virtual Padding to The Edges Of an Array
Dexter  Goodwin

Dexter Goodwin

1661973360

V86: X86 Virtualization in Your Browser, Recompiling X86 to WASM

v86 emulates an x86-compatible CPU and hardware. Machine code is translated to WebAssembly modules at runtime in order to achieve decent performance. Here's a list of emulated hardware:

  • An x86-compatible CPU. The instruction set is around Pentium III level, including full SSE2 support. Some features are missing, in particular:
    • Task gates, far calls in protected mode
    • Some 16 bit protected mode features
    • Single stepping (trap flag, debug registers)
    • Some exceptions, especially floating point and SSE
    • Multicore
    • 64-bit extensions
  • A floating point unit (FPU). Calculations are done using the Berkeley SoftFloat library and therefore should be precise (but slow). Trigonometric and log functions are emulated using 64-bit floats and may be less precise. Not all FPU exceptions are supported.
  • A floppy disk controller (8272A).
  • An 8042 Keyboard Controller, PS2. With mouse support.
  • An 8254 Programmable Interval Timer (PIT).
  • An 8259 Programmable Interrupt Controller (PIC).
  • Partial APIC support.
  • A CMOS Real Time Clock (RTC).
  • A generic VGA card with SVGA support and Bochs VBE Extensions.
  • A PCI bus. This one is partly incomplete and not used by every device.
  • An IDE disk controller.
  • An NE2000 (8390) PCI network card.
  • A virtio filesystem.
  • A SoundBlaster 16 sound card.

Demos

Arch LinuxDamn Small LinuxBuildroot LinuxReactOSWindows 2000Windows 98Windows 95Windows 1.01MS-DOSFreeDOSFreeBSDOpenBSD9frontHaikuOberonKolibriOSQNX

Compatibility

Here's an overview of the operating systems supported in v86:

  • Linux works pretty well. 64-bit kernels are not supported.
  • ReactOS works.
  • FreeDOS, Windows 1.01 and MS-DOS run very well.
  • KolibriOS works.
  • Haiku works.
  • Android x86 1.6-r2 works if one selects VESA mode at the boot prompt. Newer versions may work if compiled without SSE3. See #224.
  • Windows 1, 3.0, 95, 98, ME and 2000 work. Other versions currently don't (see #86, #208).
    • In Windows 2000 and higher the PC type has to be changed from ACPI PC to Standard PC
  • Many hobby operating systems work.
  • 9front works.
  • Plan 9 doesn't work.
  • QNX works.
  • OS/2 doesn't work.
  • FreeBSD works.
  • OpenBSD works with a specific boot configuration. At the boot> prompt type boot -c, then at the UKC> prompt disable mpbios and exit.
  • NetBSD works only with a custom kernel, see #350.
  • Older versions of SerenityOS work (1.0.gc460f4a is a known working version).

You can get some infos on the disk images here: https://github.com/copy/images.

How to build, run and embed?

You need:

  • make
  • Rust with the wasm32-unknown-unknown target
  • A version of clang compatible with Rust
  • java (for Closure Compiler, not necessary when using debug.html)
  • nodejs (a recent version is required, v16.11.1 is known to be working)
  • To run tests: nasm, gdb, qemu-system, gcc, libc-i386 and rustfmt

See tools/docker/test-image/Dockerfile for a full setup on Debian or WSL.

  • Run make to build the debug build (at debug.html).
  • Run make all to build the optimized build (at index.html).
  • ROM and disk images are loaded via XHR, so if you want to try out index.html locally, make sure to serve it from a local webserver. You can use make run to serve the files using Python's http module.
  • If you only want to embed v86 in a webpage you can use libv86.js. For usage, check out the examples. You can download it from the release section.

Alternatively, to build using docker

  • If you have docker installed, you can run the whole system inside a container.
  • See tools/docker/exec to find Dockerfile required for this.
  • You can run docker build -f tools/docker/exec/Dockerfile -t v86:alpine-3.14 . from the root directory to generate docker image.
  • Then you can simply run docker run -it -p 8000:8000 v86:alpine-3.14 to start the server.
  • Check localhost:8000 for hosted server.

Testing

The disk images for testing are not included in this repository. You can download them directly from the website using:

wget -P images/ https://k.copy.sh/{linux.iso,linux4.iso,buildroot-bzimage.bin,openbsd-floppy.img,kolibri.img,windows101.img,os8.img,freedos722.img}

Run all tests: make jshint rustfmt kvm-unit-test nasmtests nasmtests-force-jit expect-tests jitpagingtests qemutests rust-test tests

See tests/Readme.md for more infos.

API examples

Using v86 for your own purposes is as easy as:

var emulator = new V86Starter({
    screen_container: document.getElementById("screen_container"),
    bios: {
        url: "../../bios/seabios.bin",
    },
    vga_bios: {
        url: "../../bios/vgabios.bin",
    },
    cdrom: {
        url: "../../images/linux.iso",
    },
    autostart: true,
});

See starter.js.

Credits

More questions?

Shoot me an email to copy@copy.sh. Please report bugs on GitHub.

Download Details:

Author: copy
Source Code: https://github.com/copy/v86 
License: BSD-2-Clause license

#javascript #virtual #wasm 

V86: X86 Virtualization in Your Browser, Recompiling X86 to WASM
Dexter  Goodwin

Dexter Goodwin

1661247720

Neo: The Application Worker Driven Frontend Framework

Welcome to neo.mjs!

neo.mjs enables you to create scalable & high performant Apps using more than just one CPU. No need to take care of a workers setup, and the cross channel communication on your own.

Version 4 release announcement

1. Slack Channel for questions & feedback

Join our community: Slack Channel Invite Link

2. Scalable frontend architectures

Most frontends today still look like this. Everything happens inside the main thread (browser window), leading to a poor rendering performance. The business logic happens inside main as well, which can slow down DOM updates and animations. The worst case would be a complete UI freeze.

To solve this performance problem, it is not enough to just move expensive tasks into a worker. Instead, an application worker needs to be the main actor. neo.mjs offers two different setups which follow the exact same API. You can switch between dedicated and shared workers at any point.

The dedicated workers setup uses 3-6 threads (CPUs). Most parts of the frameworks as well as your apps and components live within the app worker. Main threads are as small and idle as possible (42KB) plus optional main thread addons.

In case you want to e.g. create a web based IDE or a multi window banking / trading app, the shared worker setup using 5+ threads (CPUs) is the perfect solution.

All main threads share the same data, resulting in less API calls. You can move entire component trees across windows, while even keeping the same JS instances. Cross window state management, cross window drag&drop and cross window delta CSS updates are available.

3. Multi Browser Window COVID19 IN NUMBERS Demo App

The most compelling way to introduce a new framework might simply be to show what you can do with it.

Blog post: Expanding Single Page Apps into multiple Browser Windows

Live Demo: COIN App (Multi Window)
Chrome (v83+), Edge, Firefox (Safari does not support SharedWorkers yet).
Desktop only.

You can find the code of the multi window covid app here.

4. COVID19 IN NUMBERS Demo App

Live Demo: COIN App dist/production
Desktop only => support for mobile devices is on the roadmap.

You can find the code of the covid app here.

5. Short overview of the concept & design goals

 What if ...Benefit
1.... a framework & all the apps you build are running inside a separate thread (web worker)?You get extreme Performance
2.... the main thread would be mostly idle, only applying the real dom manipulations, so there are no background tasks slowing it down?You get extreme UI responsiveness
3.... a framework was fully built on top of ES8, but can run inside multiple workers without any Javascript builds?Your development speed will increase
4.... you don’t need source-maps to debug your code, since you do get the real code 1:1?You get a smoother Debugging Experience
5.... you don’t have to use string based pseudo XML templates ever again?You get unreached simplicity, no more scoping nightmares
6.... you don’t have to use any sort of templates at all, ever again?You gain full control!
7.... you can use persistent JSON structures instead?You gain more simplicity
8.... there is a custom virtual dom engine in place, which is so fast, that it will change your mind about the performance of web based user interfaces?You get extreme performance
9.... the ES8 class system gets enhanced with a custom config system, making it easier to extend and work with config driven design patterns?Extensibility, a robust base for solid UI architectures
10.... your user interfaces can truly scale?You get extreme Performance

6. Want to learn more?

neo.mjs Concepts

7. Online Examples

You can find a full list of (desktop based) online examples here:
Online Examples

You can pick between the 3 modes (development, dist/development, dist/production) for each one.

8. Online Docs

The Online Docs are also included inside the Online Examples.

dist/production does not support lazy loading the examples yet, but works in every browser:
Online Docs (dist/production)

The development mode only works in Chrome and Safari Technology Preview, but does lazy load the example apps:
Online Docs (dev mode)

Hint: As soon as you create your own apps, you want to use the docs app locally,
since this will include documentation views for your own apps.

9. Command-Line Interface

You can run several build programs inside your terminal.
Please take a look at the Command-Line Interface Guide.

10. Ready to get started?

There are 3 different ways on how you can get the basics running locally.
Please take a look at the Getting Started Guide.

Here is an in depth tutorial on how to build your first neo.mjs app:
https://itnext.io/define-a-web-4-0-app-to-be-multi-threaded-9c495c0d0ef9?source=friends_link&sk=4d143ace05f0e9bbe82babd9433cc822 

11. Story & Vision

Although neo.mjs is ready to craft beautiful & blazing fast UIs,
the current state is just a fraction of a bigger picture.

Take a look at the Project Story and Vision.

12. neo.mjs is in need for more contributors!

Another way to fasten up the neo.mjs development speed is to actively jump in.
As the shiny "PRs welcome" badge suggests: open source is intended to be improved by anyone who is up for the challenge.

You can also write a guide in case you learned something new while using neo.mjs or just help to get more eyes on this project.

Either way, here are more infos: Contributing

13. neo.mjs is in need for sponsors!

neo.mjs is an MIT-licensed open source project with an ongoing development.
So far the development was made possible with burning my (tobiu's) personal savings.
 

This is obviously not sustainable. To enable me keep pushing like this, please support it.
The benefit of doing so is getting results delivered faster.

Sponsor tobiu

More infos: Sponsors & Backers

14. Jobs

Accenture is hiring multiple neo.mjs developers for the new Cloud Technology Studio in Kaiserslauern (Germany): Senior neo.mjs Frontend Developer /Architect (all genders)

These full-time roles are based on German contracts, so they require living in (or relocating to) Germany. Ping us on LinkedIn or Slack for details.

Logo contributed by Torsten Dinkheller.

Build with ❤️ in Germany.

Copyright (c) 2015 - today, Tobias Uhlig & Rich Waters

Download Details:

Author: Neomjs
Source Code: https://github.com/neomjs/neo 
License: MIT license

#javascript #virtual #dom #json #frontend 

Neo: The Application Worker Driven Frontend Framework

Preact: Fast 3kB React Alternative with The Same Modern API

Fast 3kB alternative to React with the same modern API.

All the power of Virtual DOM components, without the overhead:

  • Familiar React API & patterns: ES6 Class, hooks, and Functional Components
  • Extensive React compatibility via a simple preact/compat alias
  • Everything you need: JSX, VDOM, DevTools, HMR, SSR.
  • Highly optimized diff algorithm and seamless hydration from Server Side Rendering
  • Supports all modern browsers and IE11
  • Transparent asynchronous rendering with a pluggable scheduler
  • Instant production-grade app setup with Preact CLI

Getting Started

💁 Note: You don't need ES2015 to use Preact... but give it a try!

The easiest way to get started with Preact is to use Preact CLI. This simple command-line tool wraps up the best possible tooling for you, and even keeps things like Webpack and Babel up-to-date as they change. Best of all, it's easy to understand! Start a project or compile for production in a single command (preact build), with no configuration needed and best practices baked in! 🙌

Tutorial: Building UI with Preact

With Preact, you create user interfaces by assembling trees of components and elements. Components are functions or classes that return a description of what their tree should output. These descriptions are typically written in JSX (shown underneath), or HTM which leverages standard JavaScript Tagged Templates. Both syntaxes can express trees of elements with "props" (similar to HTML attributes) and children.

To get started using Preact, first look at the render() function. This function accepts a tree description and creates the structure described. Next, it appends this structure to a parent DOM element provided as the second argument. Future calls to render() will reuse the existing tree and update it in-place in the DOM. Internally, render() will calculate the difference from previous outputted structures in an attempt to perform as few DOM operations as possible.

import { h, render } from 'preact';
// Tells babel to use h for JSX. It's better to configure this globally.
// See https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#usage
// In tsconfig you can specify this with the jsxFactory
/** @jsx h */

// create our tree and append it to document.body:
render(<main><h1>Hello</h1></main>, document.body);

// update the tree in-place:
render(<main><h1>Hello World!</h1></main>, document.body);
// ^ this second invocation of render(...) will use a single DOM call to update the text of the <h1>

Hooray! render() has taken our structure and output a User Interface! This approach demonstrates a simple case, but would be difficult to use as an application grows in complexity. Each change would be forced to calculate the difference between the current and updated structure for the entire application. Components can help here – by dividing the User Interface into nested Components each can calculate their difference from their mounted point. Here's an example:

import { render, h } from 'preact';
import { useState } from 'preact/hooks';

/** @jsx h */

const App = () => {
    const [input, setInput] = useState('');

    return (
        <div>
            <p>Do you agree to the statement: "Preact is awesome"?</p>
            <input value={input} onInput={e => setInput(e.target.value)} />
        </div>
    )
}

render(<App />, document.body);

💁 More information at the Preact Website ➞

npm Preact Slack Community OpenCollective Backers OpenCollective Sponsors

coveralls gzip size brotli size

You can find some awesome libraries in the awesome-preact list 😎


Author: Preactjs
Source Code: https://github.com/preactjs/preact 
License: MIT license

#react #javascript #typescript #virtual #dom 

Preact: Fast 3kB React Alternative with The Same Modern API

Awesome Python: Tools and Libraries for Virtual Networking and SDN

Network Virtualization

Tools and libraries for Virtual Networking and SDN (Software Defined Networking).

  • mininet - A popular network emulator and API written in Python.
  • napalm - Cross-vendor API to manipulate network devices.
  • pox - A Python-based SDN control applications, such as OpenFlow SDN controllers.

Author: vinta
Source Code: https://github.com/vinta/awesome-python
License: View license

#python #virtual 

Awesome Python: Tools and Libraries for Virtual Networking and SDN

Bobril: Component Oriented Framework with Virtual Dom

 Bobril 

Component oriented framework inspired by ReactJs (Virtual DOM, components with state) and Mithril (small size, more complete framework). Compared to ReactJS Added speeeed, autoprefixer, CSS in JS, router, additional livecycle methods, only rAF based repaint. Bobril ignores Isomorphic JavaScript, because it would increase size and is not needed for SEO anyway (Google bot supports JavaScript). Client applications are expected to be written in TypeScript. Because it is heavily used in production, backward compatibility is king. Any new feature must be optional or its perceived value to minified size ratio must be high enough.

It is intended to be used with bobril-build.

Features:

  • Small - whole sample applications fits into 17kb gzipped.
  • No additional dependencies
  • Fast Virtual DOM diffing
  • Interesting component lifecycle callbacks
  • Components remember state in VDom cache
  • Components does not need to be HTML Elements - where is component(0-1) to HTMLNode(0-n) mapping
  • Support for partial invalidates for even faster redraws
  • Normalization of Events
  • support for evergreen browsers
  • batching of redrawing
  • any html element could be root
  • automatic passing of global configuration/context to children
  • automatic adding of "px" to length like inline style
  • reference to children nodes ala React
  • style as function which behaves like mini component with its own context
  • OnChange event and value attribute normalization
  • Key events
  • Mouse, Touch Events
  • SVG helpers
  • Router inspired by https://github.com/rackt/react-router/
  • Media detection
  • Focus, Blur, FocusIn, FocusOut events
  • Transparently add vendor prefixes for inline styles
  • Asap (setImmediate)
  • Scroll notification
  • Drag and Drop - multi touch, allows animating drag, state of the art as usual
  • Style - create css dynamically for even faster speed, allow recomputing styles for theming
  • PNG Sprites with dynamic change of color

Optional addins - separate npm modules:

bobril-g11n

  • Globalization - behind uses moment.js, bobril-build extracts texts for localization from TypeScript source.

bobx

  • Mobx like state management with deep integration with Bobril.

bobflux

  • Flux implementation for Bobril (Though BobX is preferred way)

bobril-m-icons

  • Bobril Material Icons

Whole simple applications including Bobril could fit into 17kb gzipped. Bobril-build does dead-code elimination and module flattening.

Uses NodeJs, NPM, TypeScript, Jasmine

MIT Licensed

How to develop

Install npm i bobril-build -g.

And then just start bb (bobril-build).

For helping writing TypeScript you can use VSCode.

If you want to work on something create bug with description, so work is not duplicated.

Main site bobril.com

Changelog of npm version: https://github.com/Bobris/Bobril/blob/master/CHANGELOG.md

Old Examples: http://bobris.github.io/Bobril/

For modern code look at Bobril Material: https://github.com/Bobril/Bobril-m

Tutorial videos [cz][en sub]:

Bobril tutorial

See it in vdom-benchmarks: http://vdom-benchmark.github.io/vdom-benchmark/

Chrome plugin to help you to inspect running Bobril application: https://chrome.google.com/webstore/detail/clouseau/npfemnefhbkiahihigplihehpbgkbhbj (Github source for it is here: https://github.com/klesta490/bobril-clouseau)

Author: Bobris
Source Code: https://github.com/Bobris/Bobril 
License: MIT License

#typescript #virtual #dom 

Bobril: Component Oriented Framework with Virtual Dom
Awesome  Rust

Awesome Rust

1648706040

Vagga: A Containerization tool without Daemons Written in Rust

Vagga

Vagga is a fully-userspace container engine inspired by Vagrant and Docker, specialized for development environments.

Note version 0.2 changed format of vagga.yaml see Release Notes and Upgrading for more info.

Major Features Are:

  • Running programs in linux containers (not a full virtualization like Vagrant)
  • Fully userspace containers, no need for elevated privileges like for Docker
  • Runs containerized process as a child of current shell, no attach/detach hell
  • Images are automatically rebuilt and versioned
  • Vagga has tools to manage trees of processes (so you run your redis-python-nginx server with one command)
  • Compatibility with Vagrant-LXC and Docker

More deep feature description in docs

Disclaimer: This is beta quality software. But since it's only used for development environments it's safe to use for most projects. Some incompatible changes in configuration file might be introduced until release of vagga 1.0, but it will never affect your production servers.

Documentation

Download Details:
Author: tailhook
Source Code: https://github.com/tailhook/vagga
License: MIT License

#rust  #virtual 

Vagga: A Containerization tool without Daemons Written in Rust
Awesome  Rust

Awesome Rust

1648698720

Firecracker: Secure and Fast MicroVMs for Serverless Computing

Our mission is to enable secure, multi-tenant, minimal-overhead execution of container and function workloads.

Read more about the Firecracker Charter here.

What is Firecracker?

Firecracker is an open source virtualization technology that is purpose-built for creating and managing secure, multi-tenant container and function-based services that provide serverless operational models. Firecracker runs workloads in lightweight virtual machines, called microVMs, which combine the security and isolation properties provided by hardware virtualization technology with the speed and flexibility of containers.

Overview

The main component of Firecracker is a virtual machine monitor (VMM) that uses the Linux Kernel Virtual Machine (KVM) to create and run microVMs. Firecracker has a minimalist design. It excludes unnecessary devices and guest-facing functionality to reduce the memory footprint and attack surface area of each microVM. This improves security, decreases the startup time, and increases hardware utilization. Firecracker has also been integrated in container runtimes, for example Kata Containers and Weaveworks Ignite.

Firecracker was developed at Amazon Web Services to accelerate the speed and efficiency of services like AWS Lambda and AWS Fargate. Firecracker is open sourced under Apache version 2.0.

To read more about Firecracker, check out firecracker-microvm.io.

Getting Started

To get started with Firecracker, download the latest release binaries or build it from source.

You can build Firecracker on any Unix/Linux system that has Docker running (we use a development container) and bash installed, as follows:

git clone https://github.com/firecracker-microvm/firecracker
cd firecracker
tools/devtool build
toolchain="$(uname -m)-unknown-linux-musl"

The Firecracker binary will be placed at build/cargo_target/${toolchain}/debug/firecracker. For more information on building, testing, and running Firecracker, go to the quickstart guide.

The overall security of Firecracker microVMs, including the ability to meet the criteria for safe multi-tenant computing, depends on a well configured Linux host operating system. A configuration that we believe meets this bar is included in the production host setup document.

Contributing

Firecracker is already running production workloads within AWS, but it's still Day 1 on the journey guided by our mission. There's a lot more to build and we welcome all contributions.

To contribute to Firecracker, check out the development setup section in the getting started guide and then the Firecracker contribution guidelines.

Releases

New Firecracker versions are released via the GitHub repository releases page, typically every two or three months. A history of changes is recorded in our changelog.

The Firecracker release policy is detailed here.

Design

Firecracker's overall architecture is described in the design document.

Features & Capabilities

Firecracker consists of a single micro Virtual Machine Manager process that exposes an API endpoint to the host once started. The API is specified in OpenAPI format. Read more about it in the API docs.

The API endpoint can be used to:

  • Configure the microvm by:
    • Setting the number of vCPUs (the default is 1).
    • Setting the memory size (the default is 128 MiB).
    • [x86_64 only] Choosing a CPU template (currently, C3 and T2 are available).
  • Add one or more network interfaces to the microVM.
  • Add one or more read-write or read-only disks to the microVM, each represented by a file-backed block device.
  • Trigger a block device re-scan while the guest is running. This enables the guest OS to pick up size changes to the block device's backing file.
  • Change the backing file for a block device, before or after the guest boots.
  • Configure rate limiters for virtio devices which can limit the bandwidth, operations per second, or both.
  • Configure the logging and metric system.
  • [BETA] Configure the data tree of the guest-facing metadata service. The service is only available to the guest if this resource is configured.
  • Add a vsock socket to the microVM.
  • Start the microVM using a given kernel image, root file system, and boot arguments.
  • [x86_64 only] Stop the microVM.

Built-in Capabilities:

  • Demand fault paging and CPU oversubscription enabled by default.
  • Advanced, thread-specific seccomp filters for enhanced security.
  • Jailer process for starting Firecracker in production scenarios; applies a cgroup/namespace isolation barrier and then drops privileges.

Supported platforms

We continuously test Firecracker on machines with the following CPUs micro-architectures: Intel Skylake, Intel Cascade Lake, AMD Zen2 and ARM64 Neoverse N1.

Firecracker is generally available on Intel x86_64, AMD x86_64 and ARM64 CPUs (starting from release v0.24) that offer hardware virtualization support, and that are released starting with 2015. All production use cases should follow these production host setup instructions.

Firecracker may work on other x86 and Arm 64-bit CPUs with support for hardware virtualization, but any such platform is currently not supported and not fit for production. If you want to run Firecracker on such platforms, please open a feature request.

Firecracker currently only supports little-endian platforms. Firecracker will not compile for big-endian architectures, and will not work correctly with big-endian configured guests.

Supported kernels

For a list of supported host/guest kernels and future kernel related plans, check out our kernel support policy.

Known issues and Limitations

  • The SendCtrlAltDel API request is not supported for aarch64 enabled microVMs.
  • Configuring CPU templates is only supported for Intel enabled microVMs.
  • The pl031 RTC device on aarch64 does not support interrupts, so guest programs which use an RTC alarm (e.g. hwclock) will not work.

Performance

Firecracker's performance characteristics are listed as part of the specification documentation. All specifications are a part of our commitment to supporting container and function workloads in serverless operational models, and are therefore enforced via continuous integration testing.

Policy for Security Disclosures

The security of Firecracker is our top priority. If you suspect you have uncovered a vulnerability, contact us privately, as outlined in our security policy document; we will immediately prioritize your disclosure.

Download Details:
Author: firecracker-microvm/
Source Code: https://github.com/firecracker-microvm/firecracker
License: Apache-2.0 License

#rust  #virtual 

Firecracker: Secure and Fast MicroVMs for Serverless Computing
Awesome  Rust

Awesome Rust

1648691400

Youki: A Container Runtime Written in Rust

youki is an implementation of the OCI runtime-spec in Rust, similar to runc.
Your ideas are welcome here.

About the name

youki is pronounced as /joʊki/ or yoh-key. youki is named after the Japanese word 'youki', which means 'a container'. In Japanese language, youki also means 'cheerful', 'merry', or 'hilarious'.

Motivation

Here is why we are writing a new container runtime in Rust.

  • Rust is one of the best languages to implement the oci-runtime spec. Many very nice container tools are currently written in Go. However, the container runtime requires the use of system calls, which requires a bit of special handling when implemented in Go. This is too tricky (e.g. namespaces(7), fork(2)); with Rust, it's not that tricky. And, unlike in C, Rust provides the benefit of memory safety. While Rust is not yet a major player in the container field, it has the potential to contribute a lot: something this project attempts to exemplify.
  • youki has the potential to be faster and use less memory than runc, and therefore work in environments with tight memory usage requirements. Here is a simple benchmark of a container from creation to deletion.
RuntimeTime (mean ± σ)Range (min … max)
youki198.4 ms ± 52.1 ms97.2 ms … 296.1 ms
runc352.3 ms ± 53.3 ms248.3 ms … 772.2 ms
crun153.5 ms ± 21.6 ms80.9 ms … 196.6 ms

Details about the benchmark

  • A command used for the benchmark
$ hyperfine --prepare 'sudo sync; echo 3 | sudo tee /proc/sys/vm/drop_caches' --warmup 10 --min-runs 100 'sudo ./youki create -b tutorial a && sudo ./youki start a && sudo ./youki delete -f a'
  • Environment console $ ./youki info Version 0.0.1 Kernel-Release 5.11.0-41-generic Kernel-Version #45-Ubuntu SMP Fri Nov 5 11:37:01 UTC 2021 Architecture x86_64 Operating System Ubuntu 21.04 Cores 12 Total Memory 32025 Cgroup setup hybrid Cgroup mounts blkio /sys/fs/cgroup/blkio cpu /sys/fs/cgroup/cpu,cpuacct cpuacct /sys/fs/cgroup/cpu,cpuacct cpuset /sys/fs/cgroup/cpuset devices /sys/fs/cgroup/devices freezer /sys/fs/cgroup/freezer hugetlb /sys/fs/cgroup/hugetlb memory /sys/fs/cgroup/memory net_cls /sys/fs/cgroup/net_cls,net_prio net_prio /sys/fs/cgroup/net_cls,net_prio perf_event /sys/fs/cgroup/perf_event pids /sys/fs/cgroup/pids unified /sys/fs/cgroup/unified CGroup v2 controllers cpu detached cpuset detached hugetlb detached io detached memory detached pids detached device attached Namespaces enabled mount enabled uts enabled ipc enabled user enabled pid enabled network enabled cgroup enabled $ ./youki --version youki version 0.0.1 commit: 0.0.1-0-0be33bf $ runc -v runc version 1.0.0-rc93 commit: 12644e614e25b05da6fd08a38ffa0cfe1903fdec spec: 1.0.2-dev go: go1.13.15 libseccomp: 2.5.1 $ crun --version crun version 0.19.1.45-4cc7 commit: 4cc7fa1124cce75dc26e12186d9cbeabded2b710 spec: 1.0.0 +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  • The development of railcar has been suspended. This project was very nice but is no longer being developed. This project is inspired by it.
  • I have fun implementing this. In fact, this may be the most important.

Related project

Status of youki

youki is not at the practical stage yet. However, it is getting closer to practical use, running with docker and passing all the default tests provided by opencontainers/runtime-tools. youki demo

FeatureDescriptionState
DockerRunning via Docker
PodmanRunning via Podman
pivot_rootChange the root directory
MountsMount files and directories to container
NamespacesIsolation of various resources
CapabilitiesLimiting root privileges
Cgroups v1Resource limitations, etc
Cgroups v2Improved version of v1Support is complete except for devices. WIP on #78
Systemd cgroup driverSetting up a cgroup using systemd
SeccompFiltering system calls
HooksAdd custom processing during container creation
RootlessRunning a container without root privileges
OCI ComplianceCompliance with OCI Runtime Spec✅ 50 out of 50 test cases passing
CRIU IntegrationFunctionality to checkpoint/restore containersInitial checkpoint support as described in #641

Design and implementation of youki

The User and Developer Documentation for youki is hosted at https://containers.github.io/youki/

Architecture

Getting Started

Local build is only supported on Linux. For other platforms, please use the Vagrantfile that we have prepared. You can also spin up a fully preconfigured development environment in the cloud with gitpod.

Requires

  • Rust(See here), edition 2021
  • Docker(See here)

Dependencies

Debian, Ubuntu and related distributions

$ sudo apt-get install   \
      pkg-config         \
      libsystemd-dev     \
      libdbus-glib-1-dev \
      build-essential    \
      libelf-dev \
      libseccomp-dev

Fedora, Centos, RHEL and related distributions

$ sudo dnf install   \
      pkg-config     \
      systemd-devel  \
      dbus-devel     \
      elfutils-libelf-devel \
      libseccomp-devel

Build

$ git clone git@github.com:containers/youki.git
$ make build # or release-build
$ ./youki -h # you can get information about youki command

Tutorial

Create and run a container

Let's try to run a container that executes sleep 30 with youki. This tutorial may need root permission.

$ git clone git@github.com:containers/youki.git
$ make build # or release-build

$ mkdir -p tutorial/rootfs
$ cd tutorial
# use docker to export busybox into the rootfs directory
$ docker export $(docker create busybox) | tar -C rootfs -xvf -

Then, we need to prepare a configuration file. This file contains metadata and specs for a container, such as the process to run, environment variables to inject, sandboxing features to use, etc.

$ ../youki spec  # will generate a spec file named config.json

We can edit the config.json to add customized behaviors for container. Here, we modify the process field to run sleep 30.

  "process": {
    ...
    "args": [
      "sleep", "30"
    ],

  ...
  }

Then we can explore the lifecycle of a container:

$ cd ..                                                # go back to the repository root
$ sudo ./youki create -b tutorial tutorial_container   # create a container with name `tutorial_container`
$ sudo ./youki state tutorial_container                # you can see the state the container is `created`
$ sudo ./youki start tutorial_container                # start the container
$ sudo ./youki list                                    # will show the list of containers, the container is `running`
$ sudo ./youki delete tutorial_container               # delete the container

Change the command to be executed in config.json and try something other than sleep 30.

Rootless container

youki provides the ability to run containers as non-root user(rootless mode). To run a container in rootless mode, we need to add some extra options in config.json, other steps are same with above:

$ mkdir -p tutorial/rootfs
$ cd tutorial
# use docker to export busybox into the rootfs directory
$ docker export $(docker create busybox) | tar -C rootfs -xvf -

$ ../youki spec --rootless          # will generate a spec file named config.json with rootless mode
## Modify the `args` field as you like

$ ../youki run rootless-container   # will create and run a container with rootless mode

Usage

Start the docker daemon.

$ dockerd --experimental --add-runtime="youki=$(pwd)/target/x86_64-unknown-linux-gnu/debug/youki"

If you get an error like the below, that means your normal Docker daemon is running, and it needs to be stopped. Do that with your init system (i.e., with systemd, run systemctl stop docker, as root if necessary).

failed to start daemon: pid file found, ensure docker is not running or delete /var/run/docker.pid

Now repeat the command, which should start the docker daemon.

You can use youki in a different terminal to start the container.

$ docker run -it --rm --runtime youki busybox

Afterwards, you can close the docker daemon process in other the other terminal. To restart normal docker daemon (if you had stopped it before), run:

$ systemctl start docker # might need root permission

Integration Tests

Go and node-tap are required to run integration tests. See the opencontainers/runtime-tools README for details.

$ git submodule update --init --recursive
$ make oci-integration-test

Setting up Vagrant

You can try youki on platforms other than Linux by using the Vagrantfile we have prepared. We have prepared two environments for vagrant, namely rootless mode and rootful mode

$ git clone git@github.com:containers/youki.git
$ cd youki

# If you want to develop in rootless mode, and this is the default mode
$ vagrant up
$ vagrant ssh

# or if you want to develop in rootful mode
$ VAGRANT_VAGRANTFILE=Vagrantfile.root vagrant up
$ VAGRANT_VAGRANTFILE=Vagrantfile.root vagrant ssh

# in virtual machine
$ cd youki
$ make build # or release-build

Download Details:
Author: containers
Source Code: https://github.com/containers/youki
License: Apache-2.0 License

#rust  #virtual 

Youki: A Container Runtime Written in Rust
Zac Efron

Zac Efron

1646652941

Hiring a Team of Virtual Developers With Seven Bits

Hiring a team of developers is a time-consuming and challenging task. Having access to a dedicated manager is imperative for ensuring proper workflow, agility, and coordination. Moreover, you will not have to spend extra time managing your project. For this reason, hiring a team of dedicated virtual developers is a smart move. In addition, Seven Bits will help you create a transparent project execution process. You can easily hire and manage top talent from the platform.

Unlike traditional staffing companies, a team of remote developers can bring the same level of expertise that you do. The main advantages of hiring developers this way are their skill set and experience, as well as the flexibility to work around your schedule. Besides, you will be able to test the work ethic and culture of your new hire before allowing them to begin working on your project. A team of developers from the same location will make your project much more seamless and efficient.

Hiring a team of dedicated developers provides you with several benefits, including full control, speed, and task focus. However, the downside of hiring freelancers is that you are unlikely to get a dedicated team dedicated to your project. In addition, a team of professionals from a single company will not provide you with the same level of support as a dedicated team of people. Therefore, it is important to find a developer with the right skills and experience.

As a result, hiring a team of remote developers is an increasingly popular way to save money and get top IT talent. Using remote development teams is a great way to access the best IT talent from around the world, and it is also a great way to ensure that your project will succeed. While it can be difficult to find the right person to join your team, it can be worth the effort. If you want to keep your costs to a minimum, a virtual developer with a larger budget is a wise choice.

You may be concerned about the cost of hiring a virtual developer. You must pay them a competitive rate. The cost of a virtual developer's services depends on the type of programming skills they possess. You should always pay them a reasonable amount, as you don't want to waste money on the wrong services. This way, you'll be able to hire the best virtual developers for your project. There are no limits when it comes to hiring a developer.

If you're hiring a virtual developer, you should consider the cost of hiring a developer. You don't have to hire a developer who's the same age as you are. In fact, many remote workers are more than happy to work for free. A developer with a lower salary can be an excellent choice for your company. A developer with a higher rate is likely to have better quality. If you're looking for a developer, you can't go wrong.

While hiring a developer is an ideal way to save money, it can also be difficult to screen prospective candidates. You can't always tell their skills from their experience. Aside from their credentials, it's also important to check the developer's background and work ethic. The right remote developer will be able to provide a quality product. When you hire a virtual developer, you don't have to worry about a candidate's work ethic.

Hiring a remote developer is an excellent way to increase your productivity and reduce costs. The right developer can help you build a website that will convert visitors into customers. If you're not a fan of hiring a developer on your own, try out a virtual developer service. It's not just convenient, it's also cost-effective. It's also easier to find and retain a remote development team than you might think.

A remote developer can be hired to work on projects of any size. There are a number of benefits to hiring a remote developer. First, you can save on the cost of hiring a developer. You can hire a virtual developer who's based in another country. This way, you can avoid having to pay travel expenses. You can easily pay your virtual programmer for the work you have already completed. It will only take a few minutes to complete the project.

#virtual #web-development #developer #game-development #software-development #development #web #web-service #digitalmarketing 

Hiring a Team of Virtual Developers With Seven Bits
山岸  英樹

山岸 英樹

1639221840

Azure ExpressRoute仮想ネットワークゲートウェイの構成

AzureからカスタマーエンドへのExpressRoute接続には2つのタイプがあります。1つはExpressRouteCircuitで、もう1つはExpressRouteの仮想ネットワークゲートウェイです。この記事では、AzureExpressRouteゲートウェイを構成する方法を学習します。ゲートウェイを構成する必要がある場合は、ピア回線のURLと認証キーが必要です。回線所有者は、ExpressRoute回線から認証キーとピア回線URLを作成し、認証は1つの接続に対してのみ有効です。さらに接続する必要がある場合は、接続ごとに個別の認証キーが必要です。

ステップ1

ExpressRouteの仮想ネットワークゲートウェイを作成するリソースグループを選択し、Azureポータルで[+作成]をクリックします。

AzureExpressRoute仮想ネットワークゲートウェイの構成

ステップ2

[作成]をクリックして、展開を開始します。

ステップ3

[仮想ネットワークゲートウェイの作成]ページで、ゲートウェイを作成するために次の詳細を入力する必要があります。 

  • ExpressRouteゲートウェイの名前。
  • 正しい地域を選択してください。
  • ExpressRouteとしてゲートウェイタイプを選択します。
  • SKUを標準として選択します。
  • 仮想ネットワークを選択すると、GatewaySubnetが自動的に選択されます。
  • 新しいパブリックIPアドレスを作成し、[作成]ボタンをクリックします。

ステップ4

ExpressRouteゲートウェイを作成した後、ゲートウェイタイプとSKUを確認できます。

AzureExpressRoute仮想ネットワークゲートウェイの構成

ステップ5

ExpressRouteゲートウェイで、[設定]の下の[接続]を選択し、[+追加]をクリックします。

ステップ6

[接続の追加]ページで、接続タイプとしてExpressRouteを選択し、[承認の引き換え]チェックボックスをクリックします。

ステップ7

[認証の利用]チェックボックスを選択すると、[認証キーとピア回路URI]テキストボックスが表示され、そのテキストボックスから認証キーとピア回路URIを終了して、[OK]をクリックします。接続を作成すると、オンプレミスデバイスはクラウド環境にアクセスできるようになります。

概要

この記事では、ExpressRoute用の仮想ネットワークゲートウェイを作成する方法を学びました。ご不明な点がございましたら、コメント欄にコメントを残してください。

リンク: https://www.c-sharpcorner.com/article/configuring-azure-expressroute-virtual-network-gateway/

#azure #virtual 

Azure ExpressRoute仮想ネットワークゲートウェイの構成

How To Enable Virtualization in BIOS (VT-X / AMD-V) Windows 10

How to Enable Virtualization in BIOS will show you how to boot into your BIOS and enable VT-X / AMD-V Virtualization support. This is necessary to run Virtual Machines on Windows 10 or any operating system. Access to BIOS can range depending on your system. This shows UEFI BIOS but the same principle applies to MBR (Legacy). Enable Virtualization today and start using a virtual machine on your computer.

The process is mainly you get an error like VT-x / AMD-v needs to be enabled. You boot into BIOS find the SVM / VT-x / AMD-v option and enable it. Following that save and exit and your ready to use your new virtual machines.
 

#windows   #virtual 

How To Enable Virtualization in BIOS (VT-X / AMD-V) Windows 10
Jaden  Haag

Jaden Haag

1635656400

Infinite Scrolling Component using Blazor

Infinite Scrolling (Component Virtualization) using Blazor with short Example.
Infinite scrolling is a way to automatically loads data when you reach the end of the page.
 

 #virtual  #blazor 

 Infinite Scrolling Component  using Blazor
Antwan  Larson

Antwan Larson

1634345880

How to Develop an Application That Allows 360° Videos in VR with Unity

Unity 3D is a versatile cross-platform development engine that we’ve used many times in the past for game development and augmented/virtual reality apps.

In this session, we’ll develop a Unity application that lets us bring any 360-degree video natively into our virtual environment with 3D scrollability. With the help of the Google Cardboard plugin, we’ll make our VR experience fully stereoscopic and hands-free, ready to be ported into any headset.

#unity #virtual 

How to Develop an Application That Allows 360° Videos in VR with Unity