Blog

  • next-type-safe-routes

    next-type-safe-routes

    next-type-safe-routes parses the /pages folder in your Next.js app and generates types for all the pages and API routes in the application. These types can then be used to ensure that you only link to pages (and only use API routes) that actually exists in your application.

    With the types generated, you can use the getRoute utility to retrieve links that are guaranteed to exist in your the application:

    Features

    • Automatic route listing. Avoid having to maintain a list of existing pages for your application
    • Compile time route validation. Avoid having to run your application to verify if links are correct, just use types
    • Unopinionated. Use our simple and composable utils or create your own abstraction

    Installation

    Install using yarn:

    yarn add next-type-safe-routes

    Or using npm:

    npm install next-type-safe-routes --save

    Usage

    For an example setup, see the /example folder

    The easiest way to use next-type-safe-routes, is with next-compose-plugins. With next-compose-plugins installed, you can add a next.config.js file with the following content:

    const withPlugins = require("next-compose-plugins");
    const nextTypeSafePages = require("next-type-safe-routes/plugin");
    
    module.exports = withPlugins([nextTypeSafePages]);

    When you start up your application, we will generate types for all of your pages and API routes and save them to the file @types/next-type-safe-routes/index.d.ts in the root of your project. The file will be updated whenever you add or remove pages and API routes.

    Note, you should commit this file as part of your project. And if you’re using a code formatter or linter, you may want to add this file to your ignore files. E.g. .eslintignore and .prettierignore files.

    You can now import the getRoute util from next-type-safe-routes and use it to retrieve a route that’s is guaranteed to exist in your application.

    import { getRoute } from "next-type-safe-routes";
    
    // for simple routes (e.g. the file `/pages/users.tsx`)
    getRoute("/users");
    // for dynamic routes (e.g. the file `/pages/users/[userId]/index.tsx`)
    getRoute({ route: "/users/[userId]", params: { userId: "1" } });
    // for catch all routes (e.g. the file `/pages/catch-all/[[...slug]].tsx`)
    getRoute({ route: "/catch-all", path: "/a/b/c" });

    Now you just need to decide how you want to integrate next-type-safe-routes in your project. If you want inspiration, we demonstrate how to create a simple abstraction for the Next.js Link and router in the example project.

    How it works

    Since the Next.js router is based (strictly) on the file-system, we can determine which pages and API routes exists in an application simply by parsing the /pages folder. And due to the strictness, we can also determine which parameters are needed for dynamic routes.

    As mentioned in the usage section, we generate a module declaration specific to your project when running your project. The output looks like this:

    declare module "next-type-safe-routes" {
      export type TypeSafePage = ... // all your pages
      export type TypeSafeApiRoute = ... // all your routes
      export const getPathname = ... // typed based on your routes
      export const getRoute = ... // typed based on your routes
    }

    See /example/src/@types/next-type-safe-routes/index.d.ts for a real example

    The trick here is, that we override the types for next-type-safe-routes. And we (re)define the args accepted by the getRoute and getPathname to match the types for your project.

    The declaration will be written to @types/next-type-safe-routes/index.d.ts in the root (determined by Next.js) of your project.

    API reference

    How you ensure that only links to existing pages is essentially up to you, but we do expose a few tiny util methods to help you do this.

    The getRoute method

    A simple method that converts a type-safe route to an “actual” route.

    Examples:

    import { getRoute } from "next-type-safe-routes";
    
    // For simple (non-dynamic) routes
    const route = getRoute("/users"); // => "/users"
    
    // With query params
    const route = getRoute({
      route: "/users",
      query: { "not-typed": "whatevs" },
    }); // => "/users?not-typed=whatevs"
    
    // For dynamic routes
    const route = getRoute({
      route: "/users/[userId]",
      params: { userId: 1234 },
    }); // => "/users/1234"
    
    // For catch all routes
    const route = getRoute({
      route: "/catch-all",
      path: "/can/be/anything",
    }); // => "/catch-all/can/be/anything"

    Optional catch all routes are also supported.

    The getPathname method

    The getPathname works similarly to the getRoute. It just returs a Next.js pathname. For instance:

    import { getPathname } from "next-type-safe-routes";
    
    const path = getPathname({
      route: "/users/[userId]",
      params: { userId: 1234 },
    }); // => `/users/[userId]`

    The TypeSafePage and TypeSafeApiRoute types

    These can be useful for making your own abstraction. For instance, if you want to make a tiny abstraction ontop of the next/router:

    import { TypeSafePage, getRoute } from "next-type-safe-routes";
    import { useRouter as useNextRouter } from "next/router";
    
    const useRouter = () => {
      const router = useNextRouter();
    
      // Say you only want to allow links to pages (and not API routes)
      const push = (typeSafeUrl: TypeSafePage) => {
        router.push(getRoute(typeSafeUrl));
      };
    
      return { ...router, push };
    };
    
    export default useRouter;

    For basic routes, the type can be of the type string or:

    {
      route: string,
      query?: { ... } // any key value pairs (not type-safe)
    }

    And for dynamic routes, the type is always:

    {
      route: string,
      params: { ... }, // based on the file name
      query?: { ... } // any key value pairs (not type-safe)
    }

    And for catch all routes, a (non-typed) path will also be required (or optional for optional catch all routes):

    {
      route: string,
      path: string,
      params: { ... }, // based on the file name
      query?: { ... } // any key value pairs (not type-safe)
    }

    Examples:

    type Query = { [key: string]: any };
    export type TypeSafePage =
      | "/users"
      | { route: "/users"; query?: Query }
      | {
          route: "/users/[userId]";
          params: { userId: string | number };
          query?: Query;
        }
      | {
          route: "/users/[userId]/catch-all-route";
          params: { userId: string | number };
          path="/catch/all/path"
          query?: Query;
        };

    Note, the TypeSafePage and TypeSafeApiRoute are kept separate even though they are essentially the same type. We do this, as you may potentially want to distinguish between them in your application.

    Motivation

    At my company, Proper, we like pages. Like…a lot! Our platform is a fairly large Next.js application consisting of ~70 pages. And we link between pages ~200 places in the application.

    We find that having pages make features easily discoverable by end-users and developers alike. And having pages (urls) for each of our features help us maintain a sane information architecture throughout our platform.

    The Next.js file-system based router help us stay consistent and organised around our pages. But we’ve had some incidents where our application was released with dead links.

    At one point, a file in the /pages folder was renamed and we simply overlooked (forgot to change) some of the links to that page. Another time, a bit of “clever” string concatenation caused an issue. In this case, we had moved a page, and failed to update all links to the page correctly due to the concatenated links.

    With the next-type-safe-routes, we’re trying to mitigate this issue. The plugin gives us confidence when refactoring as well as a top notch developer experience.

    We considered something like the next-routes approach, but we don’t want to manually have to maintain a list of routes in the application. We prefer conventions to be enforced when possible.

    Visit original content creator repository https://github.com/ckastbjerg/next-type-safe-routes
  • next-type-safe-routes

    next-type-safe-routes

    next-type-safe-routes parses the /pages folder in your Next.js app and generates types for all the pages and API routes in the application. These types can then be used to ensure that you only link to pages (and only use API routes) that actually exists in your application.

    With the types generated, you can use the getRoute utility to retrieve links that are guaranteed to exist in your the application:

    Features

    • Automatic route listing. Avoid having to maintain a list of existing pages for your application
    • Compile time route validation. Avoid having to run your application to verify if links are correct, just use types
    • Unopinionated. Use our simple and composable utils or create your own abstraction

    Installation

    Install using yarn:

    yarn add next-type-safe-routes

    Or using npm:

    npm install next-type-safe-routes --save

    Usage

    For an example setup, see the /example folder

    The easiest way to use next-type-safe-routes, is with next-compose-plugins. With next-compose-plugins installed, you can add a next.config.js file with the following content:

    const withPlugins = require("next-compose-plugins");
    const nextTypeSafePages = require("next-type-safe-routes/plugin");
    
    module.exports = withPlugins([nextTypeSafePages]);

    When you start up your application, we will generate types for all of your pages and API routes and save them to the file @types/next-type-safe-routes/index.d.ts in the root of your project. The file will be updated whenever you add or remove pages and API routes.

    Note, you should commit this file as part of your project. And if you’re using a code formatter or linter, you may want to add this file to your ignore files. E.g. .eslintignore and .prettierignore files.

    You can now import the getRoute util from next-type-safe-routes and use it to retrieve a route that’s is guaranteed to exist in your application.

    import { getRoute } from "next-type-safe-routes";
    
    // for simple routes (e.g. the file `/pages/users.tsx`)
    getRoute("/users");
    // for dynamic routes (e.g. the file `/pages/users/[userId]/index.tsx`)
    getRoute({ route: "/users/[userId]", params: { userId: "1" } });
    // for catch all routes (e.g. the file `/pages/catch-all/[[...slug]].tsx`)
    getRoute({ route: "/catch-all", path: "/a/b/c" });

    Now you just need to decide how you want to integrate next-type-safe-routes in your project. If you want inspiration, we demonstrate how to create a simple abstraction for the Next.js Link and router in the example project.

    How it works

    Since the Next.js router is based (strictly) on the file-system, we can determine which pages and API routes exists in an application simply by parsing the /pages folder. And due to the strictness, we can also determine which parameters are needed for dynamic routes.

    As mentioned in the usage section, we generate a module declaration specific to your project when running your project. The output looks like this:

    declare module "next-type-safe-routes" {
      export type TypeSafePage = ... // all your pages
      export type TypeSafeApiRoute = ... // all your routes
      export const getPathname = ... // typed based on your routes
      export const getRoute = ... // typed based on your routes
    }

    See /example/src/@types/next-type-safe-routes/index.d.ts for a real example

    The trick here is, that we override the types for next-type-safe-routes. And we (re)define the args accepted by the getRoute and getPathname to match the types for your project.

    The declaration will be written to @types/next-type-safe-routes/index.d.ts in the root (determined by Next.js) of your project.

    API reference

    How you ensure that only links to existing pages is essentially up to you, but we do expose a few tiny util methods to help you do this.

    The getRoute method

    A simple method that converts a type-safe route to an “actual” route.

    Examples:

    import { getRoute } from "next-type-safe-routes";
    
    // For simple (non-dynamic) routes
    const route = getRoute("/users"); // => "/users"
    
    // With query params
    const route = getRoute({
      route: "/users",
      query: { "not-typed": "whatevs" },
    }); // => "/users?not-typed=whatevs"
    
    // For dynamic routes
    const route = getRoute({
      route: "/users/[userId]",
      params: { userId: 1234 },
    }); // => "/users/1234"
    
    // For catch all routes
    const route = getRoute({
      route: "/catch-all",
      path: "/can/be/anything",
    }); // => "/catch-all/can/be/anything"

    Optional catch all routes are also supported.

    The getPathname method

    The getPathname works similarly to the getRoute. It just returs a Next.js pathname. For instance:

    import { getPathname } from "next-type-safe-routes";
    
    const path = getPathname({
      route: "/users/[userId]",
      params: { userId: 1234 },
    }); // => `/users/[userId]`

    The TypeSafePage and TypeSafeApiRoute types

    These can be useful for making your own abstraction. For instance, if you want to make a tiny abstraction ontop of the next/router:

    import { TypeSafePage, getRoute } from "next-type-safe-routes";
    import { useRouter as useNextRouter } from "next/router";
    
    const useRouter = () => {
      const router = useNextRouter();
    
      // Say you only want to allow links to pages (and not API routes)
      const push = (typeSafeUrl: TypeSafePage) => {
        router.push(getRoute(typeSafeUrl));
      };
    
      return { ...router, push };
    };
    
    export default useRouter;

    For basic routes, the type can be of the type string or:

    {
      route: string,
      query?: { ... } // any key value pairs (not type-safe)
    }

    And for dynamic routes, the type is always:

    {
      route: string,
      params: { ... }, // based on the file name
      query?: { ... } // any key value pairs (not type-safe)
    }

    And for catch all routes, a (non-typed) path will also be required (or optional for optional catch all routes):

    {
      route: string,
      path: string,
      params: { ... }, // based on the file name
      query?: { ... } // any key value pairs (not type-safe)
    }

    Examples:

    type Query = { [key: string]: any };
    export type TypeSafePage =
      | "/users"
      | { route: "/users"; query?: Query }
      | {
          route: "/users/[userId]";
          params: { userId: string | number };
          query?: Query;
        }
      | {
          route: "/users/[userId]/catch-all-route";
          params: { userId: string | number };
          path="/catch/all/path"
          query?: Query;
        };

    Note, the TypeSafePage and TypeSafeApiRoute are kept separate even though they are essentially the same type. We do this, as you may potentially want to distinguish between them in your application.

    Motivation

    At my company, Proper, we like pages. Like…a lot! Our platform is a fairly large Next.js application consisting of ~70 pages. And we link between pages ~200 places in the application.

    We find that having pages make features easily discoverable by end-users and developers alike. And having pages (urls) for each of our features help us maintain a sane information architecture throughout our platform.

    The Next.js file-system based router help us stay consistent and organised around our pages. But we’ve had some incidents where our application was released with dead links.

    At one point, a file in the /pages folder was renamed and we simply overlooked (forgot to change) some of the links to that page. Another time, a bit of “clever” string concatenation caused an issue. In this case, we had moved a page, and failed to update all links to the page correctly due to the concatenated links.

    With the next-type-safe-routes, we’re trying to mitigate this issue. The plugin gives us confidence when refactoring as well as a top notch developer experience.

    We considered something like the next-routes approach, but we don’t want to manually have to maintain a list of routes in the application. We prefer conventions to be enforced when possible.

    Visit original content creator repository https://github.com/ckastbjerg/next-type-safe-routes
  • LazyHDF5

    NIST Public Domain

    LazyHDF5: Python Macros for h5py… because I’m lazy

    LazyHDF5 is a small package for interacting with HDF5 files. The h5py library can do-it-all, but it’s not necessarily easy to use and often requires many lines of code to do routine tasks. This package facilitates easier use.

    Also, an HDF5 file viewer written in PyQt5 (optional, not required for installation) that displaces groups, datasets, and attributes.

    • Inspection
      • Get groups, datasets, file hierarchy, dataset attributes
    • Editing
      • Write/alter/re-write attributes
      • Repack datasets (coming soon)
      • Copy datasets and files
    • Basic file viewer

    Dependencies

    Note: These are the developmental system specs. Older versions of certain packages may work.

    • python >= 3.4
      • Tested with 3.4.6, 3.5.4, 3.6.3
    • numpy (1.9.3)
      • Tested with 1.12.1, 1.13.1, 1.13.3
    • h5py (>=2.6.0)

    Optional Dependencies

    The HDF file view is written in PyQt5; thus, it’s necessary if you want to that functionality. All of the other tools in this library are command-line.

    • PyQt5 (5.8)

    Note: PyQt5 only tested on Windows (via AppVeyor)

    Known Issues

    Installation

    Using pip (hard install)

    # Only Python 3.* installed
    pip install LazyHDF5
    
    # If you have both Python 2.* and 3.* you may need
    pip3 install LazyHDF5
    

    Using pip (soft install [can update with git])

    # Make new directory for LazyHDF5 and enter it
    # Clone from github
    git clone https://github.com/CCampJr/LazyHDF5
    
    # Only Python 3.* installed
    pip install -e .
    
    # If you have both Python 2.* and 3.* you may need instead
    pip3 install -e .
    
    # To update in the future
    git pull
    

    Using setuptools

    You will need to download the repository or clone the repository with git:

    # Make new directory for LazyHDF5 and enter it
    # Clone from github
    git clone https://github.com/CCampJr/LazyHDF5
    

    Perform the install:

    python setup.py install
    

    Usage Examples

    1. Getting a list of groups from an un-opened HDF5 file

    Note: when a filename is provided, the file is opened, queried, and then closed.

    from lazy5.inspect import get_groups
    
    filename = 'SomeFile.h5'
    grp_list = get_groups(filename)
    
    print('Groups:')
    for grp in grp_list:
        print(grp)
    1. Getting list of datasets from an open HDF5 file

    Note: when a file-id is provided, the file is queried and then left open.

    import h5py
    from lazy5.inspect import get_datasets
    
    filename = 'SomeFile.h5'
    fid = h5py.File(filename, 'r')
    
    dset_list = get_datasets(fid)
    
    print('Datasets:')
    for dset in dset_list:
        print(dset)
    
    fid.close()
    1. Getting the file hierarchy
    from lazy5.inspect import get_hierarchy
    
    filename = 'SomeFile.h5'
    
    hierarchy = get_hierarchy(filename)
    
    print('Hierarchy:')
    for k in hierarchy:
        print('{} : {}'.format(k, hierarchy[k]))
    1. Ordered dictionary of dataset attributes
    from lazy5.inspect import get_attrs_dset
    
    filename = 'SomeFile.h5'
    dsetname = '/Group/SomeDataset'
    
    attr_dict = get_attrs_dset(filename, dsetname)
    
    print('Dataset Attributes:')
    for k in attr_dict:
        print('{} : {}'.format(k, attr_dict[k]))
    1. PyQt5 HDF5 file viewer
    # From the command line
    python ./lazy5/ui/QtHdfLoad.py
    
    1. PyQt5 HDF5 file viewer (programmatically)
    import sys
    from PyQt5.QtWidgets import QApplication
    from lazy5.ui.QtHdfLoad import HdfLoad
    
    app = QApplication(sys.argv)
    
    result = HdfLoad.getFileDataSets(pth='.')
    print('Result: {}'.format(result))
    
    sys.exit()

    NONLICENSE

    This software was developed by employees of the National Institute of Standards and Technology (NIST), an agency of the Federal Government. Pursuant to title 17 United States Code Section 105, works of NIST employees are not subject to copyright protection in the United States and are considered to be in the public domain. Permission to freely use, copy, modify, and distribute this software and its documentation without fee is hereby granted, provided that this notice and disclaimer of warranty appears in all copies.

    THE SOFTWARE IS PROVIDED ‘AS IS’ WITHOUT ANY WARRANTY OF ANY KIND, EITHER EXPRESSED, IMPLIED, OR STATUTORY, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY THAT THE SOFTWARE WILL CONFORM TO SPECIFICATIONS, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND FREEDOM FROM INFRINGEMENT, AND ANY WARRANTY THAT THE DOCUMENTATION WILL CONFORM TO THE SOFTWARE, OR ANY WARRANTY THAT THE SOFTWARE WILL BE ERROR FREE. IN NO EVENT SHALL NIST BE LIABLE FOR ANY DAMAGES, INCLUDING, BUT NOT LIMITED TO, DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES, ARISING OUT OF, RESULTING FROM, OR IN ANY WAY CONNECTED WITH THIS SOFTWARE, WHETHER OR NOT BASED UPON WARRANTY, CONTRACT, TORT, OR OTHERWISE, WHETHER OR NOT INJURY WAS SUSTAINED BY PERSONS OR PROPERTY OR OTHERWISE, AND WHETHER OR NOT LOSS WAS SUSTAINED FROM, OR AROSE OUT OF THE RESULTS OF, OR USE OF, THE SOFTWARE OR SERVICES PROVIDED HEREUNDER.

    Contact

    Charles H Camp Jr: charles.camp@nist.gov

    Contributors

    Charles H Camp Jr

    Visit original content creator repository https://github.com/CCampJr/LazyHDF5
  • sdl2ui

    sdl2ui features

    SDL2UI can create window GUI applications with UI, buttons, mouse, touch, RFID etc.
    SDL2UI is based on SDL1.2 and later SDL2.0

    • The graphical renderer from SDL is used to show output on the display
    • Images are reponsive when you touch them. A dark background circle when you press them, which decreases fast when released.
    • No use of a big SDL_Surface, but each button is a seperate SDL_Surface, more flexible and easier to change to SDL2.0
    • 2D matrix of buttons is possible with soft scroll in verticle or horizontal direction.
    • After glow for each button, image, background in different shapes.
    • Play audio wave forms automatic
    • Background for several objects with rounded corners for any radius
    • Backgrounds can have single colour
    • Backgrounds can have a vertical change gradually from one to another colour
    • Backgrounds may have a pyramid change gradually from one to another colour
    • Backgrounds may be split in 2 colours, top half and bottom half have another colour
    • Backgrounds may cut a piece from a background picture, which requires a background image of your screen resolution.
    • Bar graphs are easy to display bar charts
    • Button response. Buttons become dark when you press them and slowly become light again when released.
    • Buttons with text and image may be created and displayed
    • Buttons have a border which is adjustable in width
    • Buttons may have a text inside
    • Buttons need to align the picture on 8 positions around the text
    • Text may be in all colours only 1 colour
    • Text can be in any font, font size for arabian and other font and other font size for chinese/japanese.
    • Text can have filtering for display or no filtering for printing
    • Text can be in a bitmap to do other things than display (e.g. print)
    • Text can have a shade
    • Buttons can be positioned every 8 pixels and have a width with a multiple of 8 pixels
    • Buttons can have a margin between buttons of any number of pixels
    • Button text can have a margin of any number of pixels from the edge of a button
    • Buttons can be moved to any location
    • Buttons can be visibile or invisible
    • Buttons may be dragged around the screen if enabled
    • Buttons can be in many languages, with an external accessor for languages and text
    • Buttons choose the optimal picture size with several pictures on the disk
    • Buttons have a background with all posibilities of a background
    • CtextButton is derived from button to show text
    • CtextButton can reduce the font size automatic until the text fits inside.
    • CmenuButton is derived from button to show a menu item
    • CbottomButton is derived from button to show a button on the bottom of the screen
    • CkeyboardButton is a derived from button to show a keyboard
    • CimageButton is derived from button to show an image inside the button
    • CheaderButton is derived from button to show a header title on each screen
    • CmatrixButton is derived from button and adjusted for 1D and 2D scrolling
    • CgraphButton is derived from button to show a graph
    • CiconButton is derived from button to show an icon
    • The handwriter can be used to input Chinese Japanese and others
    • The handwriter is derived from the open source project Zinnia
    • The handwriter works with Simplified and Original Chinese
    • The handwriter shows the 50 most look-a-like symbols in a swipe dialog
    • The handwriter has thick lines to show
    • The handwriter can be cleaned externally to start a new symbol
    • The handwriter can have any size on the screen
    • The handwriter paints itself for updates on screen
    • The handwriter searches for symbols every time the finger releases the touchscreen

    To be continued

    The archive is not filled yet with anything. I’m very busy, but want to make this project work… so be a little patience with me.

    Soon here will be following objects:

    • Buttons : Edit buttons, Text buttons, Keyboard buttons, Bottom buttons, Image buttons
    • Images : With backgrounds, rounded rectangles, adjustable gravity, labels
    • Sliders
    • Swype dialog going up/down or left/right
    • 2D swype dialog (matrix)
    • Drag and drop, also from swype list
    • Dialog solution
    • Messagebox solution
    • Edit text
    • Chinese input method (no, I am not a Chinese)

    Build

    Use Eclipse Oxygen to build all
    First install following for debian distributions:
    sudo apt-get install libzinnia-dev libsdl2-dev libsdl2-image-dev libsdl2-mixer-dev libsdl2-ttf-dev g++

    Visit original content creator repository
    https://github.com/barthoukes/sdl2ui

  • react-bootstrap-datetimepicker

    Visit original content creator repository
    https://github.com/Testlio/react-bootstrap-datetimepicker

  • CoDeNet

    CoDeNet

    CoDeNet: Efficient Deployment of Input-Adaptive Object Detection on Embedded FPGAs. (FPGA 2021 Oral)
    This is the official implementation for CoDeNet, including training/testing/quantization codes and model zoo.

    Introduction

    CoDeNet is an efficient object detection model on PyTorch, with SOTA performance on Pascal VOC and Microsoft COCO datasets under efficient settings.
    It is based on CenterNet with co-designed deformable convolution and an efficient network architecture. It can run 27fps on an Ultra96 (ZU3EG) FPGA with 55.1 AP50 on Pascal VOC.

    Main Results

    These are our main results on Pascal VOC dataset, taken from Table 3 in our paper.

    Detector Resolution DownSample W/A-bit Model Size MACs Framerate AP50
    Tiny-YOLO 416×416 MaxPool W32A32 60.5MB 3.49G NA 57.1
    CoDeNet1x(config a) 256×256 Stride4 W4A8 0.76MB 0.29G 32.2 51.1
    CoDeNet1x(config b) 256×256 S2+MaxPool W4A8 0.76MB 0.29G 26.9 55.1
    CoDeNet1x(config c) 512×512 Stride4 W4A8 0.76MB 1.14G 9.3 61.7
    CoDeNet1x(config d) 512×512 Stride4 W4A8 2.90MB 3.54G 5.2 67.1
    CoDeNet1x(config e) 512×512 S2+MaxPool W4A8 2.90MB 3.58G 4.6 69.7

    These are our main results on Microsoft COCO dataset, taken from Table 4 in our paper.

    Detector Weights Activations Model Size MACs AP AP50 AP75 APs APm APl
    CoDeNet1x 32bit 32bit 6.07 MB 1.24G 22.2 38.3 22.4 5.6 22.3 38.0
    CoDeNet1x 4bit 8bit 0.76 MB 1.24G 18.8 33.9 18.7 4.6 19.2 32.2
    CoDeNet2x 32bit 32bit 23.4 MB 4.41G 26.1 43.3 26.8 7.0 27.9 43.5
    CoDeNet2x 4bit 8bit 2.93 MB 4.41G 21.0 36.7 21.0 5.8 22.5 35.7

    Installation

    1. Make a directory for CoDeNet, clone this repo and rename it as src.

    mkdir CoDeNet
    cd CoDeNet
    git clone https://github.com/Zhen-Dong/CoDeNet.git
    mv CoDeNet src
    
    1. Build a new virtual environment with python3.6 and install the requirements.
    pip install -r requirements.txt
    
    1. Build the external library.

    cd lib/models/external
    make
    

    Note that whenever one moves to a new python environment or a new machine, the external lib should be rebuilt.

    1. Create directories for experiments, download our pretrained models from google drive and put them under corresponding directories. The directories should look like this.

    CoDeNet
    |-- src
    `-- exp
        `-- ctdet
            |-- pascal_shufflenetv2_config_a
            |   `-- model_last.pth
            |-- pascal_shufflenetv2_config_b
            |   `-- model_last.pth
            |-- pascal_shufflenetv2_config_c
            |   `-- model_last.pth
            |-- pascal_shufflenetv2_config_d
            |   `-- model_last.pth
            `-- pascal_shufflenetv2_config_e
                `-- model_last.pth
    
    1. Prepare data:
    • For COCO data, download the images (train 2017, test 2017, val 2017) and the annotation files (2017 train/val and test image info) from the MS COCO dataset.
    • For Pascal data, run the shell script tools/get_pascal_voc.sh. This includes downloading the images, downloading the annotations and merging the two annotation files into one json file.
    • Put the data directories under CoDeNet/data, and the structure should look like this.

    CoDeNet
    |-- src
    |-- exp
    `-- data
       |-- coco
       |   |-- annotations
       |   `-- images
       |       |-- test2017
       |       |-- train2017
       |       `-- val2017
       `-- voc
           |-- annotations
           |-- images
           `-- VOCdevkit
    

    Usage Guide

    For testing, use the pretrained models we provide for 5 configurations.
    To test with config a:

    python test.py ctdet --arch shufflenetv2 --exp_id pascal_shufflenetv2_config_a --dataset pascal --input_res 256 --resume --flip_test --gpu 0 --resume-quantize
    

    To test with config b:

    python test.py ctdet --arch shufflenetv2 --exp_id pascal_shufflenetv2_config_b --dataset pascal --input_res 256 --resume --flip_test --gpu 0 --maxpool --resume-quantize
    

    To test with config c:

    python test.py ctdet --arch shufflenetv2 --exp_id pascal_shufflenetv2_config_c --dataset pascal --input_res 512 --resume --flip_test --gpu 0 --resume-quantize
    

    To test with config d:

    python test.py ctdet --arch shufflenetv2 --exp_id pascal_shufflenetv2_config_d --dataset pascal --input_res 512 --resume --flip_test --gpu 0 --w2 --resume-quantize
    

    To test with config e:

    python test.py ctdet --arch shufflenetv2 --exp_id pascal_shufflenetv2_config_a --dataset pascal --input_res 512 --resume --flip_test --gpu 0 --w2 --maxpool --resume-quantize
    

    For training, we provide training/fine-tuning code for ordinary model (main.py) and quantized model (quant_main.py). For example, to train the ordinary model, run

    python main.py ctdet --arch shufflenetv2 --exp_id pascal_shufflenetv2_512_1 --dataset pascal --head_conv 64 --input_res 512 --num_epochs 90 --lr_step 50,70 --gpu 0
    

    and to train the quantized model from an ordinary pretrained model, run

    python quant_main.py ctdet --arch shufflenetv2 --exp_id pascal_shufflenetv2_512_1 --dataset pascal --head_conv 64 --input_res 512 --num_epochs 180 --lr_step 50,70 --gpu 0 --resume --resume-quantize --wt-percentile
    

    License

    THIS SOFTWARE WAS DEPOSITED IN THE BAIR OPEN RESEARCH COMMONS REPOSITORY ON FEB 1, 2023.

    CoDeNet is released under the MIT license.

    Visit original content creator repository
    https://github.com/Zhen-Dong/CoDeNet

  • go4th

    Go for The Hive


    Go for The Hive is a Golang port of TheHive4py. This is an API client to communicate with TheHive.

    Installation

    go get github.com/Xumeiquer/go4th
    

    Usage

    Go 4 TheHive exposes the whole API through an API object.

    package main
    
    import (
      "os"
    
      "github.com/Xumeiquer/go4th"
    )
    
    var (
      thehive = "https://127.0.0.1:9000"
      apiKey  = "apiKey"
      trustSSL = true
    )
    
    func main() {
      api := go4th.NewAPI(thehive, apiKey, trustSSL)
    
      alerts, err := api.GetAlerts()
      if err != nil {
        fmt.Println("error while getting alerts")
        os.Exit(1)
      }
    
      for _, alert := range alerts {
        fmt.Printf("Got Alert %s with title %s\n", alert.ID, alert.Title)
      }
    }

    API implementation

    Alert

    • List alerts
    • Find alerts
    • Update alerts in bulk
    • Compute stats on alerts
    • Create an alert
    • Get an alert
    • Update an alert
    • Delete an alert
    • Mark an alert as read
    • Mark an alert as unread
    • Create a case from an alert
    • Follow an alert
    • Unfollow an alert
    • Merge an alert in a case

    Case

    • List cases
    • Find cases
    • Update cases in bulk
    • Compute stats on cases
    • Create a case
    • Get a case
    • Update a case
    • Remove a case
    • Get list of cases linked to this case
    • Merge two cases

    Obervable

    • Find observables
    • Compute stats on observables
    • Create an observable
    • Get an observable
    • Remove an observable
    • Update an observable
    • Get list of similar observables
    • Update observables in bulk

    Task

    • Find tasks in a case (deprecated) – Will not be implemented
    • Find tasks
    • Compute stats on tasks
    • Get a task
    • Update a task
    • Create a task

    Log

    • Get logs of the task
    • Find logs in specified task
    • Find logs
    • Create a log
    • Update a log
    • Remove a log
    • Get a log

    User

    • Logout
    • User login
    • Get current user
    • Find user
    • Create a user
    • Get a user
    • Delete a user
    • Update user details
    • Set password
    • Change password

    ko-fi

    Visit original content creator repository https://github.com/Xumeiquer/go4th
  • go4th

    Go for The Hive


    Go for The Hive is a Golang port of TheHive4py. This is an API client to communicate with TheHive.

    Installation

    go get github.com/Xumeiquer/go4th
    

    Usage

    Go 4 TheHive exposes the whole API through an API object.

    package main
    
    import (
      "os"
    
      "github.com/Xumeiquer/go4th"
    )
    
    var (
      thehive = "https://127.0.0.1:9000"
      apiKey  = "apiKey"
      trustSSL = true
    )
    
    func main() {
      api := go4th.NewAPI(thehive, apiKey, trustSSL)
    
      alerts, err := api.GetAlerts()
      if err != nil {
        fmt.Println("error while getting alerts")
        os.Exit(1)
      }
    
      for _, alert := range alerts {
        fmt.Printf("Got Alert %s with title %s\n", alert.ID, alert.Title)
      }
    }

    API implementation

    Alert

    • List alerts
    • Find alerts
    • Update alerts in bulk
    • Compute stats on alerts
    • Create an alert
    • Get an alert
    • Update an alert
    • Delete an alert
    • Mark an alert as read
    • Mark an alert as unread
    • Create a case from an alert
    • Follow an alert
    • Unfollow an alert
    • Merge an alert in a case

    Case

    • List cases
    • Find cases
    • Update cases in bulk
    • Compute stats on cases
    • Create a case
    • Get a case
    • Update a case
    • Remove a case
    • Get list of cases linked to this case
    • Merge two cases

    Obervable

    • Find observables
    • Compute stats on observables
    • Create an observable
    • Get an observable
    • Remove an observable
    • Update an observable
    • Get list of similar observables
    • Update observables in bulk

    Task

    • Find tasks in a case (deprecated) – Will not be implemented
    • Find tasks
    • Compute stats on tasks
    • Get a task
    • Update a task
    • Create a task

    Log

    • Get logs of the task
    • Find logs in specified task
    • Find logs
    • Create a log
    • Update a log
    • Remove a log
    • Get a log

    User

    • Logout
    • User login
    • Get current user
    • Find user
    • Create a user
    • Get a user
    • Delete a user
    • Update user details
    • Set password
    • Change password

    ko-fi

    Visit original content creator repository https://github.com/Xumeiquer/go4th
  • fun-alphabet-reader

    Fun Alphabet Reader

    License: MIT
    Vite
    TailwindCSS
    TypeScript

    An engaging and interactive web app that helps users learn the alphabet in a fun way! Each letter corresponds to a word and is read aloud using the browser’s Speech Synthesis API.

    Live Demo

    Try the Fun Alphabet Reader

    Features

    • Interactive Buttons: Buttons for each letter of the alphabet.
    • Speech Synthesis: Reads the letter and its associated word aloud.
    • Voice Selection: Choose from available voices in your browser.
    • Modern Design: Styled with Tailwind CSS and SCSS for a sleek and responsive UI.

    Technologies Used

    • Vite: Fast and modern build tool.
    • TypeScript: Ensures type safety and code quality.
    • Tailwind CSS: Utility-first CSS framework for rapid styling.
    • SCSS: Provides enhanced styling capabilities.
    • Speech Synthesis API: Built-in browser feature for text-to-speech.

    Installation

    Follow these steps to set up the project locally:

    1. Clone the Repository:

      git clone https://github.com/justnixx/fun-alphabet-reader.git
      cd fun-alphabet-reader
    2. Install Dependencies:

      yarn
    3. Run the Development Server:

      yarn dev
    4. Build for Production:

      yarn build
    5. Preview the Production Build:

      yarn preview

    File Structure

    fun-alphabet-reader/
    ├── public/          # Static assets
    ├── src/             # Source code
    |   ├── app.ts       # Core app logic
    │   ├── main.ts      # Entry point
    │   ├── index.html   # HTML structure
    │   ├── index.scss   # Styling
    │   └── ...          # Other files
    ├── package.json     # Project configuration
    ├── vite.config.ts   # Vite configuration
    └── README.md        # Project documentation
    

    Usage

    1. Open the application in your browser.
    2. Select a voice from the dropdown menu.
    3. Click any letter button to hear the letter and its associated word read aloud.

    Customization

    • Modify the alphabet array in app.ts to include custom words for each letter.
    • Add or remove styles by editing the index.scss file.
    • Experiment with additional Speech Synthesis API features such as pitch and rate adjustments.

    Contribution

    Contributions are welcome! To contribute:

    1. Fork the repository.
    2. Create a new branch for your feature/bugfix.
    3. Commit your changes.
    4. Push to your fork and submit a pull request.

    License

    This project is licensed under the MIT License.

    Acknowledgments

    Visit original content creator repository https://github.com/justnixx/fun-alphabet-reader
  • MCUmisfits

    MCUmisfits

    What is this?

    Rowley Crossworks for ARM and SEGGER Embedded Studio are lacking support for assorted microcontrollers.

    This is a collection of unofficial CPU support packages for some such microcontrollers.

    Which microcontrollers does this project try to add support for?

    Nuvoton NUC121/125

    Nuvoton NUC126

    Nuvoton NUC505

    Cypress PSoC4

    Synwit SWM

    Microsemi SmartFusion2

    Installing a pre-built package (most likely option)

    Most users will likely just want to download the Rowley .hzq / SEGGER .emPackage files from the Releases tab near the top of this page.

    Installing a package manually in Rowley Crossworks for ARM is straightforward: Choose Tools -> Packages -> Manually Install Packages.. from the pull-down menus, and pick your .hzq file of choice.

    Installing a package manually in SEGGER Embedded Studio is also straightforward: Choose Tools -> Manually Install Packages.. from the pull-down menus, and pick your .emPackage file of choice.

    Building from source code (not necessary)

    The source code is also provided to show how custom CPU support packages can be done. Note that whilst Rowley Crossworks for ARM can generate packages for both tools, it appears that SEGGER Embedded Studio can only generate packages for itself. When generating Rowley .hzp packages, be sure to compile the Loader in the “Release” configuration before building the package.

    Visit original content creator repository
    https://github.com/majbthrd/MCUmisfits