1658396411
Real-world software projects often involve combining many technologies. So, is modern Blazor powerful and flexible enough for your team's needs? In this demo-heavy talk, Steve will show how:
- Blazor WebAssembly/Server can seamlessly embed libraries and logic written in other languages such as Rust or C/C++
- Blazor WebAssembly/Server components can be used inside other SPA frameworks such as React or Angular (or vice-versa)
- Blazor components can be used not only for web projects, but also shared with native apps for macOS, iOS, Android, and Windows (including WPF and WinForms)
These capabilities should equip your team to take on the most ambitious projects with confidence.
We'll then look further into the future and consider how WebAssembly is moving beyond the browser and is pitched to become a foundational element of cloud-native server apps. You'll be among the first to see an experimental new approach to compiling .NET applications into WASI-compliant universal binaries that can run on any OS or processor, robustly sandboxed and with great performance.
#blazor #webassembly #wasm
1658212980
This is an experimental Javascript lexer, parser and interpreter written in Rust. Currently, it has support for some of the language.
Please, check the CONTRIBUTING.md file to know how to contribute in the project. You will need Rust installed and an editor. We have some configurations ready for VSCode.
Check debugging.md for more info on debugging.
This interpreter can be exposed to JavaScript! You can build the example locally with:
npm run build
In the console you can use window.evaluate
to pass JavaScript in. To develop on the web assembly side you can run:
npm run serve
then go to http://localhost:8080
.
cargo run -- test.js
where test.js
is an existing JS file with any JS valid code.USAGE:
boa [OPTIONS] [FILE]...
FLAGS:
-h, --help Prints help information
-V, --version Prints version information
OPTIONS:
-a, --dump-ast <FORMAT> Dump the abstract syntax tree (ast) to stdout with the given format [possible values: Debug, Json,
JsonPretty]
ARGS:
<FILE>... The JavaScript file(s) to be evaluated
https://boa-dev.github.io/boa/playground/
You can get more verbose errors when running from the command line.
You can check the internal development docs at https://boa-dev.github.io/boa/doc.
To know how much of the ECMAScript specification does Boa cover, you can check out results running the ECMASCript Test262 test suite here.
See Milestones.
See Benchmarks.
See Profiling.
See CHANGELOG.md.
Feel free to contact us on Discord.
Author: Boa-dev
Source Code: https://github.com/boa-dev/boa
License: MIT, Unlicense licenses found
1658114332
In this tutorial, Michael will discuss the approaches and latest progress of Wasm support of scripting languages, like JS, Python, and Ruby
Wasm was designed to run applications written in compiled languages such as C/C++, Rust, Swift, etc. However, as Wasm gains popularity, there are increasing demands to run Wasm applications in scripting languages such as JavaScript, Python and Ruby. Compared with native interpreters (or dynamic compilers), Wasm offers benefits to both devs and ops. Dev: Wasm is a polyglot environment that supports mixing high-performance compiled languages and easy-to-use scripting languages. For example, with Wasm, devs can safely wrap Rust functions in a JS API. Op: Wasm is a sandbox with OS access. It can be managed as a standalone container or be embedded in a host. Native scripting language VMs need to be wrapped in other runtimes (eg node) and Docker containers. Wasm can achieve significant savings in computing resources. In this talk, Michael will discuss the approaches and latest progress of Wasm support of scripting languages, like JS, Python, and Ruby. He will cover language interoperability, ecosystem (eg packages and modules) support, and performance characteristics. Finally, Michael will also briefly discuss Wasm support status for popular managed languages such as Java and .Net.
#javascript #python #ruby #webassembly #wasm
1657681270
Blazor: Flavors of State Management with Blazor WebAssembly
In this tutorial, I will cover the simple state management flavours with Blazor WebAssembly and then progress towards something more tasty like the Redux pattern.
Working with Blazor WebAssembly applications we often overlook the importance of appropriate state management. Without a good understanding and the right strategy, our applications can end up polluted with components that behave badly and we end up regretting the bad choices.
In this session, I will cover the simple state management flavours and then progress towards something more tasty like the Redux pattern. We will see what there is to like and dislike about each flavour. Next, we will take a step back and determine the appropriate seasoning of state management to pair with our application. You will leave this session having sampled all the wonderful flavours and be able to make great decisions to have the best development experience.
#blazor #webassembly #wasm #dotnet #redux
1656919170
Spin is a framework for building and running event-driven microservice applications with WebAssembly (Wasm) components. With Spin, we’re trying to make it easier to get started with using WebAssembly on the server so that we can all take advantage of the security, portability, and speed WebAssembly provides when it comes to running microservices.
spin.toml
) file which defines where your WebAssembly components live and what triggers them.Spin executes the component(s) as a result of events being generated by the trigger(s) defined in the spin.toml
file.
The following illustrates how to define an HTTP application.
This hello_world
function written in Rust defines a component that takes a Request
and returns a Result<Response>
.
#[http_component]
fn hello_world(_req: Request) -> Result<Response> {
Ok(http::Response::builder()
.status(200)
.body(Some("Hello, Fermyon!".into()))?)
}
Once the code is compiled to a WebAssembly component, it can be referenced in a spin.toml
file to create an HTTP application like below.
spin_version = "1"
name = "spin-hello-world"
trigger = { type = "http", base = "/" }
version = "1.0.0"
[[component]]
id = "hello"
source = "<path to compiled Wasm module>"
[component.trigger]
route = "/hello"
Running this application with the spin
CLI is as simple as using the spin up
command. Because a trigger type of http
is specified in the spin.toml
, spin up
will start a web server:
$ spin up
Serving HTTP on address http://127.0.0.1:3000
Available Routes:
hello: http://127.0.0.1:3000/hello
Any time a request is made on the /hello
route, it will invoke the hello_world
function. Adding another component is as simple as adding another [[component]]
stanza to the spin.toml
file.
Original article source at https://spin.fermyon.dev/
#spin #webapp #microservices #webassembly #wasm
1656919053
In this tutorial, you'll learn how to create fast, secure and portable Microservices with WebAssembly, Rust and Spin.
Spin is a framework for building and running event-driven microservice applications with WebAssembly (Wasm) components.
With Spin, we’re trying to make it easier to get started with using WebAssembly on the server so that we can all take advantage of the security, portability, and speed WebAssembly provides when it comes to running microservices.
In this session, we will introduce the WebAssembly component model, and how Fermyon uses it together with Rust to create fast, secure, and portable microservices.
#rust #webassembly #wasm #spin #microservice #webapp
1654467420
Rust smart contract library designed for Elrond's VM. Also provides a debugging mode with mocks.
For examples on how to use the Elrond WASM framework, see https://github.com/ElrondNetwork/elrond-wasm-rs/tree/master/contracts/examples
The framework is designed to be easiest to use with the Elrond IDE VSCode extension: https://marketplace.visualstudio.com/items?itemName=Elrond.vscode-elrond-ide
To build a smart contract without the IDE, run the following command in the contract crate:
./build-wasm.sh
In case this doesn't work, you might not have rustc configured properly. Try:
rustup toolchain install nightly
rustup default nightly
rustup target add wasm32-unknown-unknown
Step-by-step debugging of smart contracts is possible in VSCode. To do this, it is required to have a separate debug crate and to have tasks.json and launch.json in .vscode properly configured. See https://github.com/ElrondNetwork/elrond-wasm-rs/tree/master/contracts/examples for examples on how to set this up.
To debug macros:
cargo +nightly rustc --bin wasm -- -Z unstable-options --pretty=expanded > demacroed.rs
To check wasm size:
twiggy top -n 20 target/wasm32-unknown-unknown/release/wasm.wasm
Download Details:
Author: ElrondNetwork
Source Code: https://github.com/ElrondNetwork/elrond-wasm-rs
License: GPL-3.0 license
1654256280
go-canvas
go-canvas is a pure go+webassembly Library for efficiently drawing on a html5 canvas
element within the browser from go without requiring calls back to JS to utilise canvas drawing functions.
The library provides the following features:
requestAnimationFrame
callback from the browser.go-canvas takes an alternate approach to the current common methods for using canvas, allowing all drawing primitives to be done totally with go code, without calling JS.
In a standard WASM application for canvas, the go code must create a function that responds to requestAnimationFrame
callbacks and renders the frame within that call. It interacts with the canvas drawing primitives via the syscall/js functions and context switches. i.e.
laserCtx.Call("beginPath")
laserCtx.Call("arc", gs.laserX, gs.laserY, gs.laserSize, 0, math.Pi*2, false)
laserCtx.Call("fill")
laserCtx.Call("closePath")
Downsides of this approach (for me at least), are messy JS calls which can't easily be checked at compile time, forcing a full redraw every frame, even if nothing changed on that canvas, or changes being much slower than the requested frame rate.
go-canvas allows all drawing to be done natively using Go by creating an entirely separate image buffer which is drawn to using a 2D drawing library. I'm currently using one from https://github.com/llgcode/draw2d which provides most of the standard canvas primitives and more. This shadow Image buffer can be updated at whatever rate the developer deems appropriate, which may very well be slower than the browsers animation rate.
This shadow Image buffer is then copied over to the browser canvas buffer during each requestAnimationFrame
callback, at whatever rate the browser requests. The handling of the callback and copy is done automatically within the library.
Secondly, this also allows the option of drawing to the image buffer, outside of the requestAnimationFrame
callback if required. After some testing it appears that it is still best to do the drawing within the requestAnimationFrame
callback.
go-canvas provides several options to control all this, and take care of the browser/dom interactions
requestAnimationFrame
callback does nothing, just returns immediately, saving CPU cycles. (No point to copy buffers and redraw if nothing has changed) This allows the drawing to be adaptive to the rate of data changes.requestAnimationFrame
callback to only do redraws or image buffer copies to this max rate. Note it MAY be slower depending on the Render time, and the requirements of the browser doing other work. When a tab is hidden, the browser regularly reduces and may even stop call to the animation callback. No critical timing should be done in the render/draw routings.requestAnimationFrame
call.Drawing therefore, is pure go. i.e.
func Render(gc *draw2dimg.GraphicContext) bool {
// {some movement code removed for clarity, see the demo code for full function}
// draws red 🔴 laser
gc.SetFillColor(color.RGBA{0xff, 0x00, 0x00, 0xff})
gc.SetStrokeColor(color.RGBA{0xff, 0x00, 0x00, 0xff})
gc.BeginPath()
gc.ArcTo(gs.laserX, gs.laserY, gs.laserSize, gs.laserSize, 0, math.Pi*2)
gc.FillStroke()
gc.Close()
return true // Yes, we drew something, copy it over to the browser
If you do want to render outside the animation loop, a simple way to cause the code to draw the frame on schedule, independent from the browsers callbacks, is to use time.Tick
. An example is in the demo app below.
If however your image is only updated from user input or some network activity, then it would be straightforward to fire the redraw only when required from these inputs. This can be controlled within the Render function, by just returning FALSE at the start. Nothing is draw, nor copied (saving CPU time) and the previous frames data remains.
There is currently a likely race condition for long draw functions, where the requestAnimationFrame may get a partially completed image buffer. This is more likely the longer the user render operation takes. Currently think how best to handle this, ideally without locks. Turns out this is not an issue, due to the single threaded nature. Eventually if drawing is in a separate thread, this will have to be handled.
Demo
A simple demo can be found in: ./demo directory. This is a shameless rewrite of the 'Moving red Laser' demo by Martin Olsansky https://medium.freecodecamp.org/webassembly-with-golang-is-fun-b243c0e34f02
Compile with GOOS=js GOARCH=wasm go build -o main.wasm
Includes a Caddy configuration file to support WASM, so will serve by just running 'caddy' in the demo directory and opening browser to http://localhost:8080
Live Demo available at: https://markfarnan.github.io/go-canvas
Future
This library was written after a weekend of investigation and posted on request for the folks on #webassembly on Gophers Slack.
I intend to extend it further, time permitting, into fully fledged support package for all things go-canvas-wasm related, using this image frame method.
Several of the ideas I'm considering are:
Others ? Feedback, suggestions etc. welcome. I can be found on Gophers Slack, #Webassembly channel.
Mark Farnan, February 2020
Author: Markfarnan
Source Code: https://github.com/markfarnan/go-canvas
License: Apache-2.0 license
1653939720
This project contains the diadata Key/Value oracle written using wasm, can be deployed to supported substrate chains.
get : Gets the latest value of the asset symbol with timestamp
set : Sets latest value of asset, requires price and timestamp. Can be called only by the owner of contract
https://github.com/paritytech/cargo-contract
Network: Astar testnet (Shibuya) : YpfUaqH4zMcEo8Kw1egpPrjAGmBDWu1VVTLEEimXr2Kzevb
Set required environment variables
PRIVATE_KEY=
UNLOCK_PASSWORD=
CONTRACT_ADDRESS=
RPC_ADDRESS=
SYMBOLS=
after setting up environmnet variables run these command to start service
cd oracle
npm run build
npm run start
Download Details:
Author: diadata-org
Source Code: https://github.com/diadata-org/dia-wasm-oracle
License:
1653621860
The technology landscape for Wasm is growing every day. Join me for a tour of WebAssembly, where we will analyze areas of rapid growth for Wasm to predict the future of application development. Wasm is finding a home in every layer of the technical stack. When it comes to creating plugins and adding extensibility to projects, Wasm is rapidly becoming the de facto solution with excellent support for multiple languages. Another trend is serverless where we are seeing Wasm revolutionize application development via actor and event-driven architectures. Looking towards the future, it's not hard to imagine Wasm becoming the default runtime for the entire stack. Imagine applications compiled to Wasm, distributed and networked with a Wasm filter, admitted by a Wasm Open Policy Agent rule, versioned using a Wasm native package manager, Wasm clients that run on any device in the web or edge device, and the expressions used to operate on data are driven by Wasm.
#webassembly #wasm #programming
1653103528
Javascript has been around for over 20 years now. It's time for a change. WebAssembly was released in 2017, and is now supported by all major browsers. More and more people are starting to use it. Is a web revolution coming?
Google Maps is pretty cool, right? You can zoom in at any arbitrary point on the planet or peak at your neighbour’s terrace pool, which you always have been jealous of. All of these can be done right there in your browser. Have you ever wondered how it works?
Streaming an entire globe’s worth of images, data, 3D models so efficiently in your browser is a wonder by itself. How can Google achieve that when most of the websites have trouble even loading those annoying popups? Indeed, this wouldn’t be possible with plain old Javascript.
In a nutshell, the answer is WebAssembly! While most websites use Javascript, HTML, and some server-side framework to load and display data, Google Maps or Google Earth uses Web Assembly to run native binary code on the browser. Web Assembly is faster than any possible web framework or language out there, and in this article, we will dive into its know-how.
History of WebAssembly
Before we learn more about the working of WebAssembly, first let’s understand why it was created. It all started when a team of developers in Mozilla in 2015 worked to make Javascript more efficient to support heavy applications like Video Games on the web. In this process, they created WebAssembly, which was initially demonstrated to execute Unity’s Angry Bots game on the web.
So what is WebAssembly?
Let’s look at the description given on the official website of web assembly:
‘WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.’
In simpler terms, WebAssembly is a new type of code, which is written in .wasm format and is very close to Machine language. The Wasm file is converted into a binary instruction (file written in 0s and 1s) and then compiled and rendered on the webpage. Since the WebAssembly file is very similar to C or Machine Language, it is fast in execution, which makes it a powerful tool for running heavy applications like Video Games, Video Files, 3D models, Porting Desktop Applications, etc.,
This has a massive impact on the way websites made. WebAssembly allows you to run programs written in various languages like C++, Rust, Python, Java, etc., on the web with near-native speeds. Developers are no longer restricted to the usage of the Javascript language to make web applications.
WebAssembly is statically typed, uses linear memory, and is stored in binary format. All of these features allow wasm files to be rendered on the web at near-native speed, i.e., the speed you would get if you run the program on a command line. That’s amazing, right? What’s more impressive is that now you are not restricted to the usage of only JS based libraries. The ability to support existing tools and libraries to use in the browser and the associated potential support for speedup is the main features that make WebAssembly so enthralling.
JavaScript and WebAssembly
The above diagram shows how a typical JS code is parsed and rendered on the web. JavaScript is a dynamically typed language in which variable types don’t need to be mentioned upfront or compiled ahead. It does make JS really easy to use and write, but the obvious drawback is that the JS engine has to do a lot more work to make the code work. It has to parse, compile, and optimize the code as it’s being run. On the other hand, WebAssembly is a statically typed code, which means, unlike JS, the engine doesn’t need to speculate during compilation about what types the various variables have. Most of the optimization is also done during the compilation period before it even reaches the browser. Memory is managed manually, just like in languages C/C++. All of these give much better performance and reliability.
So, the question now emerges that is WebAssembly the perfect replacement for JavaScript?
Well, the answer is ‘not exactly.’ WebAssembly was never created to replace or compete with JavaScript. It was an additional tool which was designed to improve the web platform by making it more powerful. It is intended to complement JS language and allowing developers to take advantage of multiple languages.
It is also not necessarily true that JavaScript is slow in all cases.
“What?? But till now, you were telling WebAssembly is faster!”
Yes, I have, but let’s understand this in more detail.
In most cases, the total Web Assembly files are more extensive than JS files (without even considering that JS files can be mainly compressed). This means that if you have a slower internet connection, then JavaScript will run faster for you. The situation may change if you are working with an extensive application in which WebAssembly is faster.
Once the WebAssembly files are cached in the browser, they load faster than the corresponding JS code, but the gain is meagre. The reason for this low gain is that JavaScript code loads and starts very quickly. WebAssembly (compiled with full optimization) is not always faster than JavaScript during execution, and when WebAssembly is faster, the gain can be small.
There might be specific tasks for which you are searching libraries in JS but not might find one. But these libraries might be present in C/C++, Rust, etc. So, WebAssembly will help tap into the new language environment.
If you find a gap in the web platform that has been filled many times in another language but not on the web or not in JS, Web Assembly might be your saviour.
Both JS and WebAssembly have the same peak performance. They are equally fast. But, it is easier to stay on the fast path with WebAssembly than it is with JS. This is primarily because of the way the WebAssembly engine works.
That’s why WebAssembly is an additional tool to go alongside JavaScript rather than its replacement.
Let’s build our first WebAssembly App!
So, after reading about WebAssembly and learning about its know-how, let’s build a simple Todo List application using WebAssembly.
For this tutorial, I will use Blazor WebAssembly, a client-side library that uses the .NET framework to build interactive Web UIs with C# instead of JavaScript.
Requirements for this project: .NET 5.0 SDK or later installed on your OS.
First, we need to make a basic structure for our web assembly project. Fortunately, Blazor provides a straightforward way to do so.
Just move to the directory where you want to create your project and open a new command line terminal in that folder. In the command line, write the following code. (Make sure you have .NET 5.0 SDK or later installed in your system)
‘dotnet new blazorserver -o TodoList’
Here the preceding name ‘TodoList’ is the name of your root directory for the project. Change directories to the TodoList folder using the command,
cd TodoList
We want to create a new Razor component in the Pages folder (Razor is a markup syntax that lets you embed server-side code written in C# on web pages). Write the following command in your command line.
‘dotnet new razorcomponent -n Todo -o Pages’
This command will create a new Todo.razor file in the Pages folder of your project. Now let’s add our Todo component to our Navbar. Navigate to Shared/NavMenu.razor and open the NavMenu component file.
In the NavMenu.razor file, add the following block of code.
<li class="nav-item px-3">
<NavLink class="nav-link" href="todo">
<span class="oi oi-list-rich" aria-hidden="true"></span> Todo
</NavLink>
</li>
In the above code, we add a NavLink for our Todo Component. Save this file. Now try to build and run this basic structure initially. In your command line, go to the root directory of your project (TodoList in this case) and type the command:
dotnet watch run
It will open your web application on the route https://localhost:5001. To Navigate to Todo Component, click on the TodoList option on the sidebar. Your web application should look like this till now:
As you can see, the Todo page is empty because we haven’t yet added any TodoItem. So let’s create a file in our root directory (TodoList in this case) called TodoItem.cs. Type the following C# code for the TodoItem class:
public class TodoItem
{
public string Title { get; set; }
public bool IsDone { get; set; }
}
Return to the Todo component (Pages/Todo.razor). Then a field for the todo items in an ‘@code’ block. The Todo component uses this field to maintain the state of the todo list. After that add an unordered list markup and a foreach loop to render each todo item as a list item (<li>).
@page "/todo"
<h3>Todo</h3>
<ul>
@foreach (var todo in todos)
{
<li>@todo.Title</li>
}
</ul>
@code {
private IList<TodoItem> todos = new List<TodoItem>();
}
Our website will also require a UI element for adding the todo items to the list. So, add a text input and a button below the unordered list.
@page "/todo"
<h3>Todo</h3>
<ul>
@foreach (var todo in todos)
{
<li>@todo.Title</li>
}
</ul>
<!-- Input fields for adding new Todo Items -->
<input placeholder="Something todo" />
<button>Add todo</button>
Save the TodoItem.cs file and the updated Pages/Todo.razor file. As you can see in the command line, the web page automatically updates as you save any file in your project. The browser temporarily loses its connection to the app and then reloads the page when the connection is re-established.
As of now, the Add Todo button does nothing because we haven’t attached any event handler with the button. So, let’s do that.
Add an AddTodo method to the Todo component and register it for button selections using the @onclick attribute. The AddTodo C# method is called when the button is selected.
To get the new todo item’s title, add a newTodo string field at the top of the @code block and bind it to the text input value using the bind attribute in the <input> element.
Update the AddTodo method to add the TodoItem with the specified title to the list. Clear the value of the text input by setting newTodo to an empty string.
<input placeholder="Something todo" @bind="newTodo" />
<button @onclick="AddTodo">Add todo</button>
@code {
private IList<TodoItem> todos = new List<TodoItem>();
private string newTodo;
private void AddTodo()
{
if (!string.IsNullOrWhiteSpace(newTodo))
{
todos.Add(new TodoItem { Title = newTodo });
newTodo = string.Empty;
}
}
}
Now, if we suppose complete any task from our Todos list, we should have an option to delete them, right? So, let’s add that functionality. We will keep a checkbox to track whether the task is completed or not.
To do that, add a check box input for each todo item and bind its value to the IsDone property. Change @todo.Title to an <input> element bound to @todo.Title.
<ul>
@foreach (var todo in todos)
{
<li>
<input type="checkbox" @bind="todo.IsDone" />
<input @bind="todo.Title" />
</li>
}
</ul>
How would we check whether the above conditions work or not? A straightforward solution is to add an option alongside the heading, which shows the number of todo items that aren’t complete.
<h3>Todo (@todos.Count(todo => !todo.IsDone))</h3>
The completed Todo component (Pages/Todo.razor) will look something like this:
@page "/todo"
<h3>Todo (@todos.Count(todo => !todo.IsDone))</h3>
<ul>
@foreach (var todo in todos)
{
<li>
<input type="checkbox" @bind="todo.IsDone" />
<input @bind="todo.Title" />
</li>
}
</ul>
<input placeholder="Something todo" @bind="newTodo" />
<button @onclick="AddTodo">Add todo</button>
@code {
private IList<TodoItem> todos = new List<TodoItem>();
private string newTodo;
private void AddTodo()
{
if (!string.IsNullOrWhiteSpace(newTodo))
{
todos.Add(new TodoItem { Title = newTodo });
newTodo = string.Empty;
}
}
}
And the final Site looks like this:
Hurray!! You made your first Web Assembly project. See, that wasn’t hard, right? Okay, Now it is the end of the article but the start of your learning journey into this amazing and powerful technology that would revolutionize the way we use our web. Do check out the resources given below to learn more about Web Assembly.
#javascript #webassembly #wasm #webdev
1652063516
resvg-js is a high-performance SVG renderer and toolkit, powered by Rust based resvg and napi-rs.
v2
: Gets the width and height of the SVG and the generated PNG.v2
: Support for outputting simplified SVG strings, such as converting shapes(rect, circle, etc) to <path>
.v2
: Support WebAssembly..node
file has been compiled for you.npm i @resvg/resvg-js
<script src="https://unpkg.com/@resvg/resvg-wasm"></script>
This example will load Source Han Serif, and then render the SVG to PNG.
node example/index.js
Loaded 1 font faces in 0ms.
Font './example/SourceHanSerifCN-Light-subset.ttf':0 found in 0.006ms.
✨ Done in 55.65491008758545 ms
const { promises } = require('fs')
const { join } = require('path')
const { Resvg } = require('@resvg/resvg-js')
async function main() {
const svg = await promises.readFile(join(__dirname, './text.svg'))
const opts = {
background: 'rgba(238, 235, 230, .9)',
fitTo: {
mode: 'width',
value: 1200,
},
font: {
fontFiles: ['./example/SourceHanSerifCN-Light-subset.ttf'], // Load custom fonts.
loadSystemFonts: false, // It will be faster to disable loading system fonts.
defaultFontFamily: 'Source Han Serif CN Light',
},
}
const resvg = new Resvg(svg, opts)
const pngData = resvg.render()
const pngBuffer = pngData.asPng()
console.info('Original SVG Size:', `${resvg.width} x ${resvg.height}`)
console.info('Output PNG Size :', `${pngData.width} x ${pngData.height}`)
await promises.writeFile(join(__dirname, './text-out.png'), pngBuffer)
}
main()
Although we support the use of Wasm packages in Node.js, this is not recommended. The native addon performs better.
<script src="https://unpkg.com/@resvg/resvg-wasm"></script>
<script>
;(async function () {
// The Wasm must be initialized first
await resvg.initWasm(fetch('https://unpkg.com/@resvg/resvg-wasm/index_bg.wasm'))
const opts = {
fitTo: {
mode: 'width', // If you need to change the size
value: 800,
},
}
const svg = '<svg> ... </svg>' // Input SVG, String or Uint8Array
const resvgJS = new resvg.Resvg(svg, opts)
const pngData = resvgJS.render(svg, opts) // Output PNG data, Uint8Array
const pngBuffer = pngData.asPng()
const svgURL = URL.createObjectURL(new Blob([pngData], { type: 'image/png' }))
document.getElementById('output').src = svgURL
})()
</script>
See playground, it is also possible to call Wasm in Node.js, but there is a performance penalty and this is not recommended.
Running "resize width" suite...
resvg-js(Rust):
12 ops/s, ±22.66% | fastest 🚀
sharp:
9 ops/s, ±64.52% | 25% slower
skr-canvas(Rust):
7 ops/s, ±3.72% | 41.67% slower
svg2img(canvg and node-canvas):
6 ops/s, ±16.94% | slowest, 50% slower
node12 | node14 | node16 | npm | |
---|---|---|---|---|
Windows x64 | ✓ | ✓ | ✓ | |
Windows x32 | ✓ | ✓ | ✓ | |
Windows arm64 | ✓ | ✓ | ✓ | |
macOS x64 | ✓ | ✓ | ✓ | |
macOS arm64(M1) | ✓ | ✓ | ✓ | |
Linux x64 gnu | ✓ | ✓ | ✓ | |
Linux x64 musl | ✓ | ✓ | ✓ | |
Linux arm gnu | ✓ | ✓ | ✓ | |
Linux arm64 gnu | ✓ | ✓ | ✓ | |
Linux arm64 musl | ✓ | ✓ | ✓ | |
Android arm64 | ✓ | ✓ | ✓ | |
Android armv7 | ✓ | ✓ | ✓ | |
Rust
Node.js@10+
which fully supported Node-API
wasm-pack
curl https://rustwasm.github.io/wasm-pack/installer/init.sh -sSf | sh
npm i
npm run build
npm test
npm i
npm run build:wasm
npm run test:wasm
I will consider implementing the following features, if you happen to be interested, please feel free to discuss with me or submit a PR.
We use GitHub actions to automatically publish npm packages.
# 1.0.0 => 1.0.1
npm version patch
# or 1.0.0 => 1.1.0
npm version minor
Download Details:
Author: yisibl
Source Code: https://github.com/yisibl/resvg-js
License: MPL-2.0 license
#nodejs #svg #rust #wasm #node
1651734000
Lichen is a light-client-based, in-browser wallet for Substrate.
The Light UI is meant to be an intuitive interface for beginner users to easily interact with various Substrate chains. It is provided in two forms:
Both provide the same functionalities and use the same UI, feel free to choose the medium that suits you best.
A very alpha version of the browser extension can be found in the Github Releases page.
You can also check out the master
branch and build from source.
As of v0.3.0, the main functions are as follows:
And here is a rough roadmap of what's coming next (see the v0.4.0-MVP
milestone for details):
Make sure you have yarn >= 1.13.0 and nodejs >= 10.10.0. Then run
git clone https://github.com/paritytech/substrate-light-ui
cd ./substrate-light-ui
yarn install
yarn build:extension
Then install the extension:
chrome://extensions/
packages/extension-app/build
about:debugging#addons
packages/extension-app/build/manifest.json
For now, you need to bundle a Substrate node manually into the Electron app. To do so, first build a Substrate node for your platform (note: it can of course be a Polkadot/Kusama node, or any other Substrate node), and copy it as ./packages/electron-app/static/substrate
:
cp /path/to/polkadot ./packages/electron-app/static/substrate
Then run:
yarn build:electron
The building might take some time, but you should see an Electron application after a while.
Troubleshooting: If it hangs on a white screen in Electron even though it has compiled and has been syncing for a long time, then simply choose 'View > Reload' (CMD + R on macOS) from the Electron menu.
We welcome any and all contributions whether it is in the form of raising an issue, filing a PR, or participating in the discussions. Please read the Contributing Docs first.
If you would like to run this project with hot-reloading, use the following commands:
yarn start:ui
: If you would only like to modify the UI, run this command and visit http://localhost:3000yarn start:electron
: Run the Electron app with hot reloadingDownload Details:
Author: paritytech
Source Code: https://github.com/paritytech/substrate-light-ui
License: Apache-2.0 License
#blockchain #javascript #typescript #polkadot #smartcontract #substrate #wasm
1651715520
The LLVM Compiler Infrastructure
This directory and its sub-directories contain source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.
The README briefly describes how to get started with building LLVM. For more information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.
Taken from https://llvm.org/docs/GettingStarted.html.
Welcome to the LLVM project!
The LLVM project has multiple components. The core of the project is itself called "LLVM". This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer. It also contains basic regression tests.
C-like languages use the Clang front end. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
Other components include: the libc++ C++ standard library, the LLD linker, and more.
The LLVM Getting Started documentation may be out of date. The Clang Getting Started page might have more accurate information.
This is an example work-flow and configuration to get and build the LLVM source:
Checkout LLVM (including related sub-projects like Clang):
git clone https://github.com/llvm/llvm-project.git
Or, on windows, git clone --config core.autocrlf=false https://github.com/llvm/llvm-project.git
Configure and build LLVM and Clang:
cd llvm-project
cmake -S llvm -B build -G <generator> [options]
Some common build system generators are:
Ninja
--- for generating Ninja build files. Most llvm developers use Ninja.Unix Makefiles
--- for generating make-compatible parallel makefiles.Visual Studio
--- for generating Visual Studio projects and solutions.Xcode
--- for generating Xcode projects.-DLLVM_ENABLE_PROJECTS='...'
--- semicolon-separated list of the LLVM sub-projects you'd like to additionally build. Can include any of: clang, clang-tools-extra, libcxx, libcxxabi, libunwind, lldb, compiler-rt, lld, polly, or debuginfo-tests.
For example, to build LLVM, Clang, libcxx, and libcxxabi, use -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi"
.
-DCMAKE_INSTALL_PREFIX=directory
--- Specify for directory the full path name of where you want the LLVM tools and libraries to be installed (default /usr/local
).
-DCMAKE_BUILD_TYPE=type
--- Valid options for type are Debug, Release, RelWithDebInfo, and MinSizeRel. Default is Debug.
-DLLVM_ENABLE_ASSERTIONS=On
--- Compile with assertion checks enabled (default is Yes for Debug builds, No for all other build types).
cmake --build build [-- [options] <target>]
or your build system specified above directly.
The default target (i.e. ninja
or make
) will build all of LLVM.
The check-all
target (i.e. ninja check-all
) will run the regression tests to ensure everything is in working order.
CMake will generate targets for each tool and library, and most LLVM sub-projects generate their own check-<project>
target.
Running a serial build will be slow. To improve speed, try running a parallel build. That's done by default in Ninja; for make
, use the option -j NNN
, where NNN
is the number of parallel jobs, e.g. the number of CPUs you have.
For more information see CMake
Consult the Getting Started with LLVM page for detailed information on configuring and compiling LLVM. You can visit Directory Layout to learn about the layout of the source code tree.
Download Details:
Author: paritytech
Source Code: https://github.com/paritytech/llvm-wasm-codesize
License:
1651685940
A Rust library containing a collection of wasm module instrumentations and transformations mainly useful for wasm based block chains and smart contracts.
This is a non exhaustive list of provided functionality. Please check out the documentation for details.
Add gas metering to your platform by injecting the necessary code directly into the wasm module. This allows having a uniform gas metering implementation across different execution engines (interpreters, JIT compilers).
Neither the wasm standard nor any sufficiently complex execution engine specifies how many items on the wasm stack are supported before the execution aborts or malfunctions. Even the same execution engine on different operating systems or host architectures could support a different number of stack items and be well within its rights.
This is the kind of indeterminism that can lead to consensus failures when used in a blockchain context.
To address this issue we can inject some code that meters the stack height at runtime and aborts the execution when it reaches a predefined limit. Choosing this limit suffciently small so that it is smaller than what any reasonably parameterized execution engine would support solves the issue: All execution engines would reach the injected limit before hitting any implementation specific limitation.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in wasm-instrument
by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.
Download Details:
Author: paritytech
Source Code: https://github.com/paritytech/wasm-instrument
License: View license