A haskell toolbox for the Internet Computer


The Internet Computer Haskell Toolkit

This repository contains a bunch of Internet-Computer related code written to support the following use cases:

ic-ref: a IC reference implementation

The ic-ref binary is a partial implementation of the external interface of the Internet Computer, as specified in the Interface Spec.

The goals of the reference implementation are

  • It evolves in lock-step with the Interface Spec. Versioned releases of the Interface Spec should come with a complete implementation of ic-ref.

  • Supplement the prose and pseudo-code in the Interface Spec for additional and concrete clarity.

  • Ideally, relevant code pieces of ic-ref are as easy to understand as carefully written pseudo-code.

  • Increase weight of and confidence in the Interface Spec, by demonstrating implementability.

  • Aid in the development of the Interface Spec by uncovering omissions, inconsistencies or unexpected complexity.

  • Allow testing of external clients (like dfx) directly against the reference implementation.

  • Aid in the production implementation of the Internet Computer, by allowing to probe the reference implementation to better understand intended behaviour and by comparing the behaviour of the two.

  • Performance is good enough to run small examples.

  • The primary focus is describing the happy path execution, and not necessarily the precise error reporting behaviour upon bad usage (e.g. bad canisters, resource exhaustion, module validation).

Additionally, we want ic-ref to be a useful tool for Canister developers to run their canisters locally. This adds additional goals:

  • The state of ic-ref can be persisted and picked up later.

  • Debugging/logging/trace features that aid understanding the behaviour and/or help debug canisters.

Should these goals eventually conflict with the goals for a reference implementation, e.g. becauese they impose complexity that is not easy to contain in auxillary modules, a project split might be considered.

There are also explicit non-goals to keep in mind:

  • ic-ref does not need to support canisters that are large or very long-running.

  • No persistence across different versions of ic-ref.

  • It is explicitly not desirable to share code between reference and production implementation, to achieve the multi-version cross-checking effect. Not using Rust for ic-ref helps with that.

  • No guaranteed protection against bad effects from malicious interactions.

  • No duplication of commonly available functionality. In particular, the assumption is that the production implementation will use a mature Wasm embedder that implements Wasm validation correctly, so ic-ref does not itself implement validation.

Furthermore there are some stretch goals that would be nice to have, but not if requires compromising the main goals.

  • The reference implementation describes one possible execution, but not all possible behaviours of the Interface Spec. If this can be changed (e.g. using non-deterministic modeling of computation) without compromising readability and normal execution, then this would be nice.

  • It could serve as a starting point for applying formal verification to this part of the system, e.g. by converting the (non-plumbing) modules to Coq using hs-to-coq, or by implementing them in a theorem prover and extracting Haskell code from it.

To achieve these goals, the following design decisions are made:

  • ic-ref is implemented in Haskell, to optimize for development speed, type-checking safety, and readablity of carefully selected portions of the code.

  • As far as possible, a module either

    • corresponds closely to the spec, and is written with readability as a high priority, avoiding language features that obscure meaning. The rough goal is “executable pseudo-code”. The use of advanced langauge features or non-idiomatic code that help readability are encouraged.

      Examples: IC.Ref, IC.Canister.Impl, IC.HTTP.RequestId

    • is a plumbing module that handles some technical aspect, and pave the way for the simplicity in the previously mentioned modules. It is expected that reading such modules may require high level of familiarity with Haskell.

      Examples: IC.Wasm.Imports, IC.HTTP.CBOR.

    This is an ongoing refinement process, striving for a probably unattainable ideal as the goal.


The ic-ref program starts a webserver at that implements the Internet Computer interface, and can be used with dfx --client

If you point your browser to you get the evolution of the IC state as JSON. Recommended to use Firefox, as it provides a nice UI for browsing JSON.

If the --state-file FILE argument is given, ic-ref will persist its state in this file. Note that if that file cannot be read (e.g. because it is from an incompatible version of ic-ref), starting ic-ref will fail.

ic-ref-test: An acceptance test suite

As the dual to the reference implementation, the ic-ref-test program is a specification compliance acceptance test that can be run against an Internet Computer instance (e.g. ic-ref, the replica) and runs a large number of functional tests against it.


Pass --endpoint http://localhost:8080/ to run against a specific node.

With the -p pattern flag you can select individual tests; those whose names contain the pattern. See https://github.com/feuerbach/tasty#patterns for advanced use of this flag.

When passing --rerun, the test suite will remember which tests have failed, and only run those that failed last tests (or all again, if none have failed last run).

ic-ref-run: A sandboxed scripted IC

The ic-ref-run tool provides a simplified mock environment for testing Canisters that does not require networking. It takes scripted input to indicate which canisters to install, and which messages to execute.

This is used, for example, in the test suite of the Motoko compiler.

ic-request-id: Calculate the representation-independent hash

The ic-request-id tool takes a CBOR-request (stdin or via a file) and calculates its request id.

ic-hs: The library

The modules of the above tools can be used for other purposes. In that sense, the whole project is one big Haskell library that can be used in quick experiments, in the Haskell REPL, or as a libary to build other tools (e.g. a test framework for canisters as in the case of the Internet Identity).

To use the Haskell REPL to interact with the internet computer, follow this pattern:

~/dfinity/ic-hs $ cabal repl ic-ref-test
Ok, 27 modules loaded.
*Main> :m + *IC.Test.Spec
*IC.Test.Spec *Main> :set -XOverloadedStrings
*IC.Test.Spec *Main> R r <- connect "http://localhost:34677/"
Fetching endpoint status from "http://localhost:34677"...
Spec version tested:  0.14.0
Spec version claimed: 0.14.0
*IC.Test.Spec *Main> r $ install noop
*IC.Test.Spec *Main> cid1 <- r $ install noop
*IC.Test.Spec *Main> prettyBlob cid1
*IC.Test.Spec *Main> r $ call cid1 (setGlobal "Foo" >>> replyData "Hello")
*IC.Test.Spec *Main> r $ query cid1 (replyData getGlobal)

It’s necessary to wrap all lines with the r $ … for now; this sets the endpoint parameter.


NOTE: The following assumes access to a nix cache that has built the artifacts already. There is no publicly available nix cache yet, so “fastest way” may be a bit of an euphemism.

This is the fastest way to run ic-ref or ic-ref-test is to use the following commands in this directory:

nix run -f . -c ic-ref
nix run -f . -c ic-ref-test

You can also pass arguments, e.g.

nix run -f . -c ic-ref-test --endpoint -p 'WebAuthn'

Developing on ic-ref

Running nix-shell gives you an environment that allows you to build the project using cabal build. You can also run cabal run ic-ref etc. to run it directly from source.

One possible workflow is to run

ghcid -c 'cabal repl ic-ref' -T Main.main

which will run ic-ref and restart upon file changes. Similarly

For ic-ref-test, before running it, you make sure you have built the universal canister.

The symbolic link in test-data/universal_canister.wasm points to the build output produced by

cd universal_canister
nix-shell --command 'cargo build --target wasm32-unknown-unknown --release'

You can now run the test suite from the top-level directory with

cabal run ic-ref-test

The -p flag, i.e.

cabal run ic-ref-test -- -p upgrade

allows you can run tests selectively (i.e. only those whose name include “upgrade”).

Again, you can use ghcid to run the test suite upon file changes:

ghcid -c 'cabal repl ic-ref-test' -T Main.main

and you can flags with

ghcid -c 'cabal repl ic-ref-test' -T Main.main --setup ':set args --rerun -p "query call"'


This repository tags versions based on the version of the Interface Spec they implement, e.g. 0.18.0. Should older major released require additional commits (bugfixes, or additional minor releases) that cannot be created on master, a release-0.18 branch would be created.

Updating Haskell Packages

When the .cabal file of a Haskell package is changed you need to make sure the corresponding nix files nix/generated/ are kept in sync with it. These are automatically generate, run

nix-shell nix/generate.nix

to update.

Don't worry if you forget to update the default.nix file, the CI job check-generated checks if these files are in sync and fails with a diff if they aren't.

  • System API for ECDSA signing

    System API for ECDSA signing

    This PR Implements a corresponding part of the IC spec: https://github.com/dfinity/interface-spec/pull/6

    It also splits up IC.Test.Agent and IC.Test.Spec to reduce the excessive memory consumption of compiling those modules.

    opened by marcin-dziadus 16
  • ic-ref-test: Test stopping state

    ic-ref-test: Test stopping state

    This allows the test driver to withhold the response to a message, and control when they are released, in order to produce situations with outstanding call contexts.

    In an ideal world (from our pov), we could instrument and control the system's scheduler this way, but we can't. So instead, we use some tricks. Ideally, the details of this trick are irrelevant to the users of this function (yay, abstraction), and if we find better tricks, we can swap them out easily. We'll see if that holds water.

    One problem with this approach is that a test failure could mean that the system doesn't pass the test, but it could also mean that the system has a bug that prevents this trick from working, so take care.

    The current trick is: Create a canister (the "stopper"). Make it its own controller. Tell the canister to stop itself. This call will now hang, because a canister cannot stop itself. We can release the call (producing a reject) by starting the canister again.

    Some tests are added, and others are now using this mechanism.

    This has uncovered bugs in ic-ref related to the handling of stopped.

    opened by nomeata 10
  • Update system API for 128 bit cycles tests

    Update system API for 128 bit cycles tests

    Following up on our discussion regarding the multivalue target feature support, we have decided to update the experimental System Api and not rely on this feature anymore.

    This MR updates the tests according to the Public Spec.

    opened by AlexandraZapuc 10
  • Implement 64-bit stable memory APIs

    Implement 64-bit stable memory APIs

    We would like to implement the new 64-bit stable memory APIs in the reference implementation so that we can also make a new release of the Interface spec and have end users start using the extended stable memory.

    Looking into the code a bit I figured out that the main blocker right now is the Memory module exposed by Winter which supports 32-bit memories and thus cannot be used to support the 64 bit stable memory APIs.

    My idea on how this can be introduced in the least disruptive way is to provide a 64-bit Memory in Winter alongside the 32-bit one. Then the WinterMemory wrapper module can use this new 64-bit memory for either the old APIs (checking of course that the size is not bigger than allowed and casting 32 bit integers to 64 bit where necessary) or the new APIs. I think this would also be in line with future extensions of Winter (to support 64-bit wasm memories I assume you'd need a 64 bit memory implementation).

    If the above sounds like a reasonable plan on a high level, then the next question would be how to best achieve this in practice. Looking at the code, it seems that we could maybe make MemoryInst generic by the size of memory and save us from some ugly code duplication. This seems the most promising approach and one that should relatively minimize the amount of changes in general.

    I'm curious to see what others think and open to other ideas.

    opened by dsarlis 8
  • Provide x86_64-darwin builds again since dfinity/sdk depends on it

    Provide x86_64-darwin builds again since dfinity/sdk depends on it

    The DFINITY SDK team has notified us that they rely on ic-hs in their tests. In order for them to make a release for x86_64-darwin they need a build of ic-us for that platform.

    We recently removed support for x86_64-darwin (https://github.com/dfinity/ic-hs/pull/81) because we switched to building remotely on nixbuild.net which doesn't support that platform (yet). The reason we switched was the high-memory usage in building https://github.com/dfinity/ic-hs/pull/79 which required more memory (~ 18.2 GB) than what's available on GitHub runners (7 GB).

    So in order to support x86_64-darwin again we need to:

    • Enable x86_64-darwin builds again. For that platform we just build locally on GitHub runners.

    • Fix the high-memory usage. Some things we can do/try:

      • Split up IC.Test.Agent and IC.Test.Spec since compiling those modules requires massive RAM.
      • Switch to a more recent GHC with the hope that it fixes the memory issue. GHC-9.2 in particular as made improvements there. See: https://well-typed.com/blog/2021/03/memory-return/ To switch we probably need to upgrade to nixpkgs-22.05 (which we're doing in https://github.com/dfinity/ic-hs/pull/76).
      • Ideally we gain an understanding of why GHC suddenly requires so much memory to build IC.Test.Agent. Space profiling GHC could provide an answer here.
    opened by basvandijk 7
  • Cannot build Serialise.hs with GHC 8.10.4

    Cannot build Serialise.hs with GHC 8.10.4

    Using the latest nixpkgs-unstable and GHC 8.10.4, I get the following error during compilation:

    [49 of 57] Compiling IC.Serialise     ( src/IC/Serialise.hs, dist/build/IC/Serialise.o, dist/build/IC/Serialise.dyn_o )
    src/IC/Serialise.hs:25:1: error:
        Could not find module ‘System.Random.Internal’
        Use -v (or `:set -v` in ghci) to see a list of the files searched for.
    25 | import System.Random.Internal (StdGen(..))
       | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    Pinging @nomeata

    opened by jwiegley 6
  • Use nixbuild.net as a remote nix builder on CI

    Use nixbuild.net as a remote nix builder on CI

    GitHub Actions Runners only have 7GB of memory which is proving to be too small to built ic-hs. So instead of building nix derivations on a runner locally we configure the runner to build derivations remotely on nixbuild.net.

    The above requires access to a private SSH key, which is used to authenticate with nixbuild.net. This key is not accessible on PRs originating from forks because that would allow leaking the key. For those PRs we don't configure nixbuild.net as a remote builder and build locally instead.

    opened by basvandijk 3
  • Nix: Track haskell-upgrades

    Nix: Track haskell-upgrades

    in #30 we tracked a PR against nixpkgs, which isn't very stable (e.g. if it gets force-pushed to, it may break this repository). The changes we are trying to include are still not in nixpkgs master, but they are closer already, on the haskell-upgrades branch. So track that, until it is merged into master (via https://github.com/NixOS/nixpkgs/pull/138596)

    opened by nomeata 3
  • fix(#28): implement 64-bit stable memory support

    fix(#28): implement 64-bit stable memory support

    This change implements 64 bit stable memory API.

    ic0.stable64_size : () -> (page_count : i64);                               // *
    ic0.stable64_grow : (new_pages : i64) -> (old_page_count : i64);            // *
    ic0.stable64_write : (offset : i64, src : i64, size : i64) -> ();           // *
    ic0.stable64_read : (dst : i64, offset : i64, size : i64) -> ();            // *

    This change introduces a new representation of stable memory: we use size + history of writes instead of a flat byte buffer. This results in a pretty straightforward code and allows us to handle even huge heaps gracefully, which is crucial for testing interaction between 32 and 64 bit APIs.

    Fixes #28.

    opened by roman-kashitsyn 3
  • Enable mergify for this repo

    Enable mergify for this repo

    Mergify is a great tool that leaves merging to this bot, meaning less maual work for us.

    One great feature is that it supports squash merges that take the PR description as the commit message. So instead of a commit message like https://github.com/dfinity/ic-hs/commit/fb558eb58aed501a6b46768baf0a50ece6bedeaa we’d get something nicely curated like the PR description of https://github.com/dfinity/ic-hs/pull/30. You can achieve the same manually (as explained here), and that’s how I have been merging PRs in this repo so far, but it is tedious work, so won’t always work.

    There is more that we can do with mergify, e.g. auto-merge dependency bumps.

    We already have mergify enabled for the sister repository dfinity/motoko, so I see no problem doing it here too. Someone just has to enable it in https://github.com/organizations/dfinity/settings/installations/12369523, and I will prepare a PR with the configuration.

    @basvandijk, are you still doing this kind of infra work? Or who should I nudge?

    opened by nomeata 3
  • upgrade nixpkgs to release-22.05

    upgrade nixpkgs to release-22.05

    This gives us:

    • GHC-9.0.2

    • Building now uses less than half the memory as before: from > 12 GB on GHC-8.10.7 to < 6 GB on GHC-9.0.2.

    • All dependencies upgraded to their latest versions.

    • A working haskell-language-server which allows IDEs like VS Code to analyse ic-hs. For VS Code use the Nix Environment Selector plugin to load shell.nix and use the Haskell extension to get:

    Screenshot 2022-05-20 at 00 35 56
    opened by basvandijk 2
  • Remove duplicate compilation

    Remove duplicate compilation

    We're noticing that on https://github.com/dfinity/ic-hs/pull/79 GHC requires massive amounts of memory to build certain modules (IC.Test.Agent being the worst offender requiring more than 13GB while GitHub Runners only have 7GB causing OOM kills).

    What's worse is that multiple components in the cabal file require the same modules causing the same module to be build multiple times, often in parallel exacerbating the memory problem.

    This fixes the duplicate compilation issue by letting the components in the cabal file only depend on the ic-hs library.

    This might be deterimental to ghcid as mentioned in the cabal file. But the associated ticket has been closed so the problem is hopefully fixed in an upcoming GHC release.

    opened by basvandijk 9
  • ic-ref-run has no heartbeat functionality

    ic-ref-run has no heartbeat functionality

    drun triggers the heartbeat, but ic-ref-run appears not to, though ic-ref supports it. This means we can only test heartbeat functionality on drun for Motoko.

    opened by crusso 0
  • Cannot nix-build on BigSur

    Cannot nix-build on BigSur

    When building ic-ref-dist, I get the following error message:

    ~/ic-hs$ nix-build -A ic-ref-dist --max-jobs 1
    building '/nix/store/2m7aj49cw81kwajibhva97fb1ix01f66-git-ls-files.drv'...
    these derivations will be built:
    building '/nix/store/78d90xbxi22n83rwfcd3dnzr96gdgy54-ic-hs-0.0.1.drv'...
    Build with /nix/store/3x5z3qcpdpilx8wwqmpzi7xlzb4m89gy-ghc-8.10.7.
    unpacking sources
    unpacking source archive /nix/store/2slzdkdcjhcfgb5xwrxxsg7iqnmpm4vn-src
    source root is src
    patching sources
    setupCompileFlags: -package-db=/private/tmp/nix-build-ic-hs-0.0.1.drv-0/setup-package.conf.d -j8 -threaded -rtsopts
    [1 of 1] Compiling Main             ( /nix/store/4mdp8nhyfddh7bllbi7xszz7k9955n79-Setup.hs, /private/tmp/nix-build-ic-hs-0.0.1.drv-0/Main.o )
    libSystem.B.dylib does not exist. Try again
    Please specify now the directory where this library can be found (or write 'quit' to abort):
    libSystem.B.dylib does not exist. Try again
    Please specify now the directory where this library can be found (or write 'quit' to abort):
    libSystem.B.dylib does not exist. Try again
    Please specify now the directory where this library can be found (or write 'quit' to abort):
    libSystem.B.dylib does not exist. Try again
    Please specify now the directory where this library can be found (or write 'quit' to abort):

    I'm on macOS Big Sur 11.6, intel chip.

    opened by nmattia 3
  • Documentation for running with dfx is out-of-date

    Documentation for running with dfx is out-of-date

    The README.md states:

    The ic-ref program starts a webserver at that implements the Internet Computer interface, and can be used with dfx --client

    But dfx doesn't understand that command. I think at this point the correct way to do this is to use icx-proxy, right? We should update the docs to reflect that.

    opened by kritzcreek 1
The Internet Computer aims to reinvent the internet as a computer to host secure software and a new breed of open internet services.
Introduction to Computer Systems (II), Spring 2021.

Introduction to Computer Systems (II) Spring 2021, Fudan University.

null 26 Jun 15, 2022
哈尔滨工业大学(深圳)计算机专业课程攻略 | Guidance for courses in Department of Computer Science, Harbin Institute of Technology (Shenzhen)

哈工大(深圳)计算机专业课程攻略 受浙江大学相关项目和清华大学相关项目启发,创立了本项目。 若要下载单个文件夹,复制该文件夹的网址,粘贴入DownGit中,选择Download即可。 感谢对本项目贡献的同学:第二届院学生会学术部全体成员、hewei2001、chh13502、xyfJASON、ail

null 690 Aug 5, 2022
COMPUTER ENGINEERING - SEM 3-8 College Assignments and PPTs

Contributors ✨ Thanks goes to these wonderful people (emoji key): Subham Agrawal ?? ✅ Pritesh Kumar Tripathi ?? ✅ Sakshi Jain ?? ✅ Krithikha Bala ?? ✅

Subham Agrawal 29 Aug 3, 2022
University of Bergamo - C++ Dev Course (Computer Engineering) 2021/2022

University of Bergamo - 21012 Dev Course C++ 2021/2022 This git repository contains the source code in C++ language to support the lessons of the C++

Mauro Pelucchi 10 Feb 23, 2022
A project for Computer Programming (2) Course // C language

Fun-programming-project A project for Course : Computer Programming (2) “ CS181 ” presented to Dr. Abeer Alhujaylan Team work : Feda mousa leen mohamm

Feda Mousa 2 Feb 4, 2022
Internet Identity, a blockchain authentication system for the Internet Computer

Internet Identity Service See ./docs/internet-identity-spec.adoc for a details specification and technical documentation.

DFINITY 219 Jul 30, 2022
✔️The smallest header-only GUI library(4 KLOC) for all platforms

Welcome to GUI-lite The smallest header-only GUI library (4 KLOC) for all platforms. 中文 Lightweight ✂️ Small: 4,000+ lines of C++ code, zero dependenc

null 6.4k Aug 10, 2022
A Haskell library for fast decoding of JSON documents using the simdjson C++ library

hermes A Haskell interface over the simdjson C++ library for decoding JSON documents. Hermes, messenger of the gods, was the maternal great-grandfathe

Josh Miller 36 Jun 29, 2022
A c++ toolbox of locality-sensitive hashing (LSH), provides several popular LSH algorithms, also support python and matlab.

LSHBOX-0.9 A C++ Toolbox of Locality-Sensitive Hashing for Large Scale Image Retrieval, Also Support Python and MATLAB. Change Log 2015.07.04 A new LS

null 268 Aug 11, 2022
Toolbox that makes homebrewing the PS Vita easier

VitaDeploy Toolbox that makes homebrewing the Playstation Vita/TV easier Features file manager (VitaShell) sd2vita mount/format firmware updater/downg

null 126 Jul 31, 2022
A generic and robust calibration toolbox for multi-camera systems

MC-Calib Toolbox described in the paper "MultiCamCalib: A Generic Calibration Toolbox for Multi-Camera Systems". Installation Requirements: Ceres, Boo

null 150 Jul 27, 2022
Zero-Knowledge Proof Toolbox

Zkrypt是一个开源的C语言零知识证明算法库,旨在向用户提供简洁、高效的非交互式零知识证明协议接口,用户可以通过调用接口实现完整的零知识证明协议的流程,包括公共参数设置、证明生成和验证等步骤。 本项目由北京大学关志的密码学研究组开发维护。 特性 支持多种零知识证明协议(包括Groth16, Plo

Zhi Guan 12 Jun 16, 2022
Algorithmic Toolbox

Algorithmic Toolbox This online course covers basic algorithmic techniques and ideas for computational problems arising frequently in practical applic

Nourhan Elsherif 2 Jan 3, 2022
Apache Arrow is a multi-language toolbox for accelerated data interchange and in-memory processing

Apache Arrow Powering In-Memory Analytics Apache Arrow is a development platform for in-memory analytics. It contains a set of technologies that enabl

The Apache Software Foundation 10k Aug 7, 2022
BayesOpt: A toolbox for bayesian optimization, experimental design and stochastic bandits.

BayesOpt: A Bayesian optimization library BayesOpt is an efficient implementation of the Bayesian optimization methodology for nonlinear optimization,

Ruben Martinez-Cantin 323 Aug 9, 2022
Digital Signal Processing Library and Audio Toolbox for the Modern Synthesist.

Digital Signal Processing Library and Audio Toolbox for the Modern Synthesist. Attention This library is still under development! Read the docs and ch

everdrone 78 Jul 24, 2022
A long-read analysis toolbox for cancer genomics

Lorax: A long-read analysis toolbox for cancer genomics In cancer genomics, long-read de novo assembly approaches may not be applicable because of tum

Tobias Rausch 8 Apr 29, 2022
C-based/Cached/Core Computer Vision Library, A Modern Computer Vision Library

Build Status Travis CI VM: Linux x64: Raspberry Pi 3: Jetson TX2: Backstory I set to build ccv with a minimalism inspiration. That was back in 2010, o

Liu Liu 6.9k Aug 10, 2022
C-based/Cached/Core Computer Vision Library, A Modern Computer Vision Library

Build Status Travis CI VM: Linux x64: Raspberry Pi 3: Jetson TX2: Backstory I set to build ccv with a minimalism inspiration. That was back in 2010, o

Liu Liu 6.9k Aug 6, 2022
🌼 Homework of Computer Systems: A Programmer's Perspective (3rd Edition) and Autolab solutions of CMU 15-513: Intro to Computer Systems

Exercisebook of Computer Systems: A Programmer's Perspective, 3/E (CS:APP3e) CS:APP3e is written by Randal E. Bryant and David R. O'Hallaron, Carnegie

halfrost 28 Mar 10, 2022
This repository is used for storing sourcecode related to final project of Computer Graphics and Computer Vision

Computer Graphics and Computer Vision Description: This repository is used for storing sourcecode related to final project of Computer Graphics and Co

null 10 Jul 8, 2022
PLP Project Programming Language | Programming for projects and computer science and research on computer and programming.

PLPv2b PLP Project Programming Language Programming Language for projects and computer science and research on computer and programming. What is PLP L

PLP Language 5 Jun 23, 2022
CSC404: Computer Graphics [CG] & CSL402: Computer Graphics Lab [CG Lab]


AMEY THAKUR 7 Apr 28, 2022
Internet Key Exchange version 2 (IKEv2) daemon - portable version of OpenBSD iked

Portable OpenIKED This is a port of OpenBSD's OpenIKED to different Unix-like operating systems, including Linux, macOS and FreeBSD.

OpenIKED 26 May 23, 2022
Import of the DIY Dynamic Template v2, retrieved from the Internet Archive

Dynamic Templates This is a copy of the D*I*Y Planner Dynamic Template application that was posted to diyplanner.com/node/6210 back in 2009,

Trammell Hudson 20 Jun 16, 2022
A light and fast internet speed plugin(DDE).

lfxNet English | 简体中文 | 繁體中文 lfxNet 是一款轻量、快速的实时显示系统资源信息的应用程序。 目录 背景 编译 下载 作者 鸣谢 协议 背景 喜爱 DDE ,为 Deepin 爱好者、也是开发者之一。因习惯其它系统上有一个任务栏网速插件,但在 Deepin/UOS上没有

偕臧 54 Aug 12, 2022
Learn how to connect your Flexispot (LoctekMotion) desk to the internet. This repository contains a collection of scripts to get your started, combined with research and instructions.

(image source: Windows Central) Turn your LoctekMotion/FlexiSpot desk into a smart desk Recently I acquired a new standing desk from FlexiSpot. During

Mick Vleeshouwer 158 Jul 27, 2022
XMap is a fast network scanner designed for performing Internet-wide IPv6 & IPv4 network research scanning.

XMap is reimplemented and improved thoroughly from ZMap and is fully compatible with ZMap, armed with the "5 minutes" probing speed and novel scanning techniques. XMap is capable of scanning the 32-bits address space in under 45 minutes.

idealeer 175 Jul 17, 2022