@ab-pm Right, I understand. However, a branch is always going to be necessary, and if the branch is truthy then I/O is going to be performed - further, really slow I/O (console output is horrendously slow).

My point was more, if you're really worried about the overall performance impact, sprinkling your code with permanent debug logs is not going to help you regardless of the library. Putting any sort of branch in a "hot" code path is going to cause a performance downgrade.

Another thing to consider is that it's not guaranteed a hot codepath is JIT'd, so therefore you're not going to get as much of a benefit from the CPU's pipelining and branch prediction than you would, say, a C/C++/Rust program. If I could, I would mark the branches for if (namespace_is_enabled) as "unlikely" (e.g. GCC's __builtin_expect(namespace_is_enabled, 0)) to inform the CPU that the branch probably won't hit, and to eat the extra cost of a mispredict in cases where namespaces are enabled (since debug is not a logging library, despite troves of people using it as such).

So even if it were JIT'd, I'm not sure you'd get a lot of benefit anyway - and further, since it's probably not JIT'd, the branches are going to be pretty equally expensive - and since there is an unavoidable branch here anyway, performance isn't really at the forefront of consideration to the extent that memory incorrectness/leaking is a justifiable tradeoff.

That was my line of thinking :)

@SarvagyaVaish Don't put pip versions in library requirements.txt files. You can enforce pip versions in CI by specifying the version on the command line just like you did in your requirements.txt:

commands:
  pip_upgrade:
    command: /opt/python/run/venv/bin/pip install --upgrade pip==19.1.1
    ignoreErrors: false

The reason being is that, for those that do not have a virtualenv, you'll be rolling back their global version of pip if they are on a newer version; pip does not no-op package installations if they're an older version than what's already available, so they'll instead uninstall the newer version first and rollback, which is sure to upset others who have to work with your codebase.

Consider adding a note to your build/usage instructions about the requirement of pip>=19.1.1 instead. Some people can't upgrade and thus might have to consider using another library instead of wasting a bunch of time rolling back pip due to a library mandating it.

@ab-pm You're exactly right. v5 is going to be a rewrite that will improve this a bit.

debug has always been a performance suck, though. Even if the debug namespace is disabled, the parameters are still evaluated going into it. In trivial cases this is fine, but I know for a fact many people are passing expressions to debug(). Further, Javascript engines do not have dead code removal advanced enough to be able to determine that pure expressions passed to a no-op function can be elided to safe on cycles.

As for whether or not it's a "performance regression", by this logic anything that adds an extra instruction to the overall code path is a "performance regression". The trade-off here is that debug was not correct and leaked memory.

The real fix here would be to overhaul the enabled namespaces system altogether, which would be a major breaking change and is thorougly discussed elsehwere on the issue tracker. As I mentioned before, it's slated for v5, whenever I get around to that.

TIL @gerrith3. Why the "ppc" abbreviation still then? Just for legacy/conventional reasons?

FWIW it's "PowerPC", not just "power". Maybe update the comments :)

which GCC version?

Not sure how often that's happened but yes, that's the kind of mindset that's important :)

FWIW hidden isn't really recommended to be used anymore. It's not "secret" and definitely not secure, so beyond any sort of usecase like that, it's probably best just not to use it. There is a reason why most emulators don't (correctly, or at all) support it - there's not a lot of practical use for it.

Sorry for the delay on this; this is turning out to be a really tricky comment to word correctly since the types are quite hairy. Hopefully you're still interested in helping @dragomirtitian 😅

Before continuing, let me define a term so that we're on the same page: while the string keys and their function values are just that - functions - I'll refer to the set of functions that share the same key among any of the objects in which that key is present as a "method".

const cat = {
    meow: async function *() {},
    walk: async function *() {}
};

const human = {
    speak: async function *() {},
    walk: async function *() {}
};

const result = scaly([human, cat]);

In the above, there are two layers - human and cat. Between the two layers are three methods - meow, walk and speak. Scaly is just a library that manages control flow between multiple functions that compose the overall method walk, in this case, since walk shares two layers.

Hence, walk has two functions, but is a single method.

Further, I'll refer to the async generator declarations as input methods and the single "aggregate" resulting method as the output method.

• The output method's return type is [boolean, T] where T is the input methods' return type if the first tuple boolean is true, or one of the various yield expr types if the first tuple boolean is false, with one exception...
• The input method's return type can also be undefined (whereas the only case where the output method's return type is void is if the overall method's return type is also void; otherwise, you'll never get undefined by calling the output method)
• The input method can yield expr, where expr is anything except for undefined. The type does not have any relation to the method's return type. This form of the yield expression never returns, either (we treat it as a throw expression, more or less).
• The input method can yield undefined (or just yield of course), which is a special case that might produce a value from another layer's input method implementation. The type of expression yield undefined is thus the same as the method's return type.

Let me annotate an example with inline comments explaining why the types are what they are.

import scaly from 'scaly';

/*
	Three output methods:
	    - async getName(string) : string
	    - async getLocation(string): [string, string]
	    - async setName(string) : string|null
*/

const gpsLayer = {
	async *getLocation(id: string) {
		try {
			const loc: [string, string] = await someGPSClient.find(id);
			return loc;
		} catch (err) {
			if (err.code == 'UNKNOWN_ID') {
				// "throw" a recoverable error by `yield`-ing a non-undefined value.
				// This form of `yield expr` never resumes (returns).
				// Note that we yield an `Error` object here, not a `string`.
				yield err; // yield expr (where typeof(expr) is anything except undefined)
			} else {
				// otherwise, throw a real exception.
				throw err; // not covered by typescript I don't think.
			}
		}
	}
};

const mongoLayer = {
	async *getName(id: string) {
		const name: string|undefined = await someMongoClient.find({id}, {name: 1});
		if (!name) yield 'unknown user ID'; // "throw" a recoverable error again
		return name;
	},

	async *setName(id: string, name: string) {
		const oldName: string|undefined = await someMongoClient.upsertAndGetOldValue({id}, {name});
		return oldName || null; // return the string if it's there, or `null` if it's falsey
	}
};

// This is where the use of `undefined` becomes important.
const redisLayer = {
	async *getName(id: string) {
		const name: string|undefined = await someRedisClient.get(`${id}:name`);

		// If it's a cache-hit, then simply return it
		if (name) {
			return name; // typeof(name) == string, same as mongoLayer's `getName()` method type
		} else {
			// Otherwise, produce the value from the next layer.
			// The result of a naked `yield` is never `undefined` because
			// Scaly will error if no result can be produced from any of the
			// subsequent layers.
			const newName: string = yield; // same as the method return type, never `undefined`.
			await someRedisClient.set(`${id}:name`, newName);

			// In this case, the return value can be `undefined` since Scaly
			// already has the result value. There is no need to `return newName`
			// again a second time.
			return undefined;
		}
	},

	async *getLocation(id: string) {
		const loc : [string, string]|undefined = await someRedisClient.get(`${id}:location`);

		if (loc) {
			return loc; // typeof(loc) == [string, string], same as gpsLayer's `getLocation()`
		} else {
			// Same thing here.
			const newLoc: [string, string] = yield;
			await someRedisClient.set(`${id}:location`, newLoc);
			return undefined;
		}
	},

	async *setName(id: string, name: string) {
		// This is the strange one; in our implementation here,
		// we just want to observe the calls to `setName()` without
		// producing a result and letting the later layers
		// have a chance at using the parameter, too.
		//
		// Even though we don't return a result in the implementation,
		// the return type should still be string|null|undefined since that's
		// what the other layers' inner method return types are (specifically,
		// mongoLayer.setName(string, string): string|null).
		//
		// Therefore, there are two ways we can write this
		// implementation:

		{
			// The first way is to handle it ourselves first,
			// then let the function return `undefined` to
			// indicate we don't care about the result
			// nor do we have a result or an error to produce,
			// and that the next layers, if any, should be invoked:
			await someRedisClient.set(`${id}:name`, name);
			return undefined;
		}

		{
			// Alternatively, we can let the deeper layers handle
			// the request first, and if there is no error result
			// produced, we can then handle it *after* the other
			// layers have handled it:
			yield; // discard the result (which would otherwise be type `string|null`)
			await someRedisClient.set(`${id}:name`, name);
			return undefined;
		}
	}
};

const DB = scaly([
	redisLayer,
	mongoLayer,
	gpsLayer
]);

/*
	typeof(DB) == {
		getName: async function (string): [true, string] | [false, string],
		setName: async function (string, string): [true, string|null] | [false, unknown],
		getLocation: async function (string): [true, [string, string]] | [false, Error]
	}
*/

The resulting object's function values' return types are a tuple of [boolean, T], as I mentioned before. The T depends on the value of boolean, though I don't know how expressable this is in Typescript. If the boolean is true, then the second tuple value's type is the method's return type. If it is false, then it's one of the yield expr types.

Hopefully this makes sense. I perfectly understand if this is something you're not interested in doing 😅 Scaly is definitely the most complicated libraries I've personally seen when it comes to type munging so I can understand not wanting to do it.

I'm mostly interested in base-level correctness - for example, if you can only express the resulting methods' return types as [boolean, result_types | error_types] as opposed to the [true, result_types] | [false, error_types] pseudocode I have above, that is just fine; just so that valid uses of Scaly pass any sort of Typescript type checking at the very least. Anything beyond that would be awesome but not necessary :)

As always, any information is helpful even if it's short of the full typings, haha. Though I think it's a fun puzzle for those interested in cryptic Typescript type definitions!

Thanks again for the response and the help on SO!

GitHub Actions CI supports color output. But chalk use black/white output there.

Seems like we have a false-negative detection at support-color.

I am fixing the problem with FORCE_COLOR=2 right now.

Yep, thanks for the reminder. Let me know if this isn't solved by upgrading.

I have this test code:

const info = require('debug')('app:info'); console.log('env NODE_ENV', process.env.NODE_ENV); console.log('env ANOTHER_VAR', process.env.ANOTHER_VAR); console.log('env DEBUG', process.env.DEBUG); info('Test info debug logging'); console.log('debug status:', info.enabled);

If I run the program in vscode using the debug mode, it doesn't enable debug using the environment variables. I have tried:

• setting the env variables in the launch parameters "env": { "NODE_ENV": "dev", "DEBUG": "app:*" },
• setting the variables in the .env file and setting the launch parameters to load the .env file "envFile": "${workspaceFolder}/.env", .env file:

NODE_ENV=dev DEBUG=app:info,-trace ANOTHER_VAR=WHatNow

The output is:

env NODE_ENV dev env ANOTHER_VAR undefined env DEBUG app:* // Missing line here, should contain "Test info debug logging" debug status: true

When I run the program in a bash window using this command, it shows the info output "Test info debug logging". This is the full output:

[nodemon] starting node demo.js env NODE_ENV dev env ANOTHER_VAR WhatNow env DEBUG app:debug,app:info app:info Test info debug logging +0ms debug status: true

I've tried setting info.enabled = true (as in ticket #774) - doesn't help. As you can see in the last line, it's already true. I've gone through a range of tickets, such as #696 and others, but can't find anything. When I trace the app, in the file common.js, debug.enabled is false so the debug function simply returns.

function createDebug(namespace) { let prevTime;

  function debug(...args) {
  	// Disabled?
  	if (!debug.enabled) {
  		return;
  	}

.....

Please assist. Thanks Brian

This has to do with VSCode, not debug - as you've seen with bash, debug is working fine. The conditional you mention at the bottom is to see if that instance's namespace is enabled given the environment variable, but since VSCode doesn't provide one to your program (for whatever reason) then of course debug.enabled will be false.

There's something else about your VSCode configuration that is wrong; I don't use VSCode so I can't really help, unfortunately. You might want to open an issue over on the VSCode repository.

Good luck!

Yeah the naming is exactly why I've not been accepting PRs for a long while. How to go about dealing with this problem is still a mystery to me.

The last thing I want is to dilute the API. Nobody is going to be able to read code and see "tintify" and know what it does.

I appreciate the PR and I'm sure it'll get accepted, just not right now. I still have to come up with a solution to this problem.

Node.js version: 14.13.1 Chalk version: 4.1.0

It's entirely possible that I am missing something obvious here, but I haven't been able to figure out what it is. I have a Node.js app that reads text strings from files and outputs them to a connected client. When I output hard-coded strings, Chalk's formatting makes it through to the client just fine, but when the exact same strings are read from the file system, the raw string (including Chalk's format syntax) is displayed instead.

I have reproduced the issue with a minimal repo here.

Here is a screenshot showing what I mean.

Except for any sort of interpolation support, yes. It accepts a single string that is parsed using the template parser.

It's one of those cases where "it's trivial to implement yourself" and "it's trivial to simply add to the library" are both valid and understandable.

Definitely trivial to implement yourself. Using chalk to format files is an edge case, and probably one of the few (if not only) cases where the above stub is really necessary.

Otherwise, using the chalk.red() set of functions directly is more performant when you have "static" strings, and using the tagged template literal syntax is easy to do.

We use .raw string literals, so you have to do a bit of juggling first. This is unlikely to change, but note that it's not officially supported. You're on your own with this :)

const chalk = require('chalk');
const chalkTemplate = msg => { const a = []; a.raw = [msg]; return chalk(a); };

console.log(chalkTemplate('{red hello}')); //-> '\x1b[31mhello\x1b[0m'

Expected behavior: No crash

Describe the bug: The tiny-warning dependency attempts to use process in the browser without checking to see if it exists first.

I would imagine it has gone unnnoticed for so long due to many packagers allowing process.env be replaced at build time - but that isn't a guarantee anyone should be relying on at the library level.

An npm ls tiny-warning showed me:

@museum/[email protected] /src/wavetilt/museum/packages/www
├─┬ [email protected]
│ └── [email protected]
└─┬ [email protected]
  ├─┬ [email protected]
  │ └── [email protected]  deduped
  ├─┬ [email protected]
  │ └── [email protected]  deduped
  ├─┬ [email protected]
  │ └── [email protected]  deduped
  ├─┬ [email protected]
  │ └── [email protected]  deduped
  └─┬ [email protected]
    └── [email protected]  deduped

I've already filed a bug report and a PR upstream.

Bug: alexreardon/tiny-warning#24 Upstream PR: alexreardon/tiny-warning#25

However, I seriously suggest ditching that dependency as was suggested in https://github.com/cssinjs/jss/issues/1313#issuecomment-620186271. It's not much more than an if statement in package form.

Versions (please complete the following information):

• jss: [email protected]
• Browser [e.g. chrome, safari]: Chrome
• OS [e.g. Windows, macOS]: Windows

Closes #24

Browsers do not have the process "global" so this adds a check prior to using it.

In index.ts, it's saying that process doesn't exist in the browser. There should be a check here to make sure typeof process !== 'undefined'.

The latest version in this repository is V4.3 while in npm V4.2 is still the latest version (npm debug).

Please publish this version to npm (if possible).

Please search the issues in the future.

https://github.com/visionmedia/debug/issues/785#issuecomment-699666241

As I understand it, className only accepts a string. Would it be possible to add an array form, too?

Currently, the problem is that, when a signal is used as one of multiple class names (especially when using CSS-in-JS, such as JXX), you usually have to write something like this:

const someSignal = S.value(false);
const C = css({ classname1: {...}, classname2: {...} });

<Foo className={`${C.classname1} {someSignal() && C.classname2}`} />

which, on top of being somewhat messy syntax, evaluates to classname1 false if the second signal is falsey, when ideally it'd be simply classname1.

Further, if there's a concern about maintaining parity with React's JSX, perhaps introduce an extended mode that includes Surplus-specific extensions that is imported with import * as Surplus from 'surplus/ex'?

On linux systems running in WSL, xdg doesn't exist. Instead, explorer.exe is patched through and works as it would on Windows. This is a backwards-compatible check to add support for WSL cases.

Short args can't be used with =. Is this intentional?

const arg = require('arg')

arg({
  '-a': String
})

node example.js -a=a

Results in:

                                        throw new TypeError(`Option requires argument (but was followed by another short argument): ${originalArgName}`);
                                        ^

TypeError: Option requires argument (but was followed by another short argument): -a
    at arg (<path>/node_modules/arg/index.js:97:12)
    at Object.<anonymous> (<path>/example.js:5:1)

A similar error happens for aliases:

const arg = require('arg')

arg({
  '--a': String,
  '-a': '--a'
})

Going to close this as I don't think there's anything actionable. Thank you for the input :)

Finally got around to this, thanks for pointing it out @rauschma. Also super weird coincidence, I just came back to this repo to look for something right after finding your openurl module and decided to take a look at this issue. Had to go back and check who the author was!

Anyway, FAQ in the readme now. :)

Would it make sense to support required arguments? For example:

const args = arg({
	'--help':    Boolean,
	'--port':    arg.req(Number),
	'--name':    String,
	'--tag':     arg.req([String]),
});

Alternatively:

const args = arg({
	'--help': Boolean,
	'--path': String,
});

const {
	'--help': printHelp = false,
	'--path': thePath = arg.required('--path', String),
} = args;

arg.required() would print an error message and exit Node.js. Downsides of this approach: Doesn’t handle aliases, redundancy.

If this is out of scope, it would be a good FAQ, because many shell argument parsing libraries support this feature.

Hi is it possible for debug module to log into VS code debugger console? Is there any need to add additional configuration to the tsconfig.json or the VS code debugger configuration to make it log into the console? Currently, it does not seem to work

I don't see anything that has to do with debug (for context, I'm here because you opened an issue at visionmedia/debug and then pinged me here).

I am not a collaborator on this package, nor do I have any control over any of the output you have shown here. I don't see any output from debug. I do not maintain 'all debug output' and thus have no idea how to help you with your problem.

Anything is possible, but it's not clear what you've tried and what isn't working.

command > file.txt isn't working?

Hello, It might be a configuration issue but I really cannot find the origin of it and already spent few days. Before I give up I wanted to double check it.

those are the plugins I'm using

 const plugins = [
      typescript({
        check: true,
        tsconfig: options.tsConfig,
        tsconfigOverride: {
          compilerOptions: {
            rootDir: options.entryRoot,
            allowJs: false,
            declaration: true,
            paths: compilerOptionPaths,
            target: config.format === 'esm' ? undefined : 'es5',
          },
        },
      }),
      resolve({
        preferBuiltins: true,
        extensions: fileExtensions,
      }),
      getBabelInputPlugin({
        cwd: join(context.workspaceRoot, sourceRoot),
        rootMode: 'upward',
        babelrc: true,
        extensions: fileExtensions,
        babelHelpers: 'bundled',
       exclude: /node_modules\/(?![debug])/
      }),
      commonjs()
     ];

and in my code I import debug import Debug from 'debug';

the build passes but I get a runtime error because it export the debug with module.exports which is not available in the browser.

Looking for previous issues on that matter brings #468 but setting alias doesn't seem to work.

If this is not the right place to seek for help for this issue feel free to close the issue.

Thanks! Eran

Adding a build step to debug doesn't fix your issue, though - you'd still get a commonjs module coming from the package manager. You might need to ask the rollup community why this isn't working as bundling debug works for most people and thus there isn't anything for us to do here.

@Agwebberley Great, then wait for this PR to land. There's no need to comment.

Because debug is not a UMD module, it's a CJS module. I'm not sure what you expect to be done here - until debug switches to ESM (which won't be any time before the v5 release at least) then you can't expect all modules to be compatible with whichever module scheme you expect.

Just don't enable those namespaces in DEBUG.

There are two issues here, neither of which are chalk's fault:

• The issue in the OP describes a case where the terminal emulator is not honoring escape sequences. Git bash is notorious for this; I recommend using the Windows Terminal downloadable from the windows store.
• The issue some of the responses are facing are codes not being emitted at all, which is due to the stdio not being inherited properly.

Chalk doesn't concern itself with how stdio is linked up so this is an issue to investigate yourself - we can't provide support here since it's not directly related to chalk.

environment

Edition - Windows 10 Pro Version - 1909 OS build - 18363.535

Using Git Bash

details

so I am creating a library to push code to git using some helpful prompts. Those prompts contains some colors too.

Every thing is working perfectly & colors are showing up as they should until I used a child process (with {stdio: "inherit"}). Child process works perfectly while logging to my stdout.

The actual issue comes after this, no colors are shown & their corresponding codes are displayed now.

check the last line in the above push-code commit control flow. Rather than green color for Successfully commit to git , it is printing its code.

Here is my source-code for debugging (not included the bin entry point since it is not relevant & only tranferring control flow to this file) -

const prompts = require("prompts");
const chalk = require("chalk");
const spawn = require('await-spawn');

/**
 * default commit flow
 * @return {Promise<{}>}
 */
module.exports = async function () {

    // to make sure you wish to commit
    let response = await prompts({
        type: "confirm",
        name: "confirm",
        message: "Sure you wish to commit ?",
    });

    if (response.confirm) {

        const commit = {};

        // select type of commit
        response = await prompts({
            type: "select",
            name: "type",
            message: "Type of commit ?",
            choices: [
                {title: "Improvements", value: "Code Improvements"},
                {title: "Bug Fixes", value: "Bug Fixes"},
                {title: "New Code", value: "New Code"}
            ],
            initial: 0
        });

        commit.type = response.type;

        // ask user for commit message & description
        try {

			// don't worry about message & describe
			// they are working perfectly & returning string
			// not including them to make this code concise
            commit.message = await message();
            commit.describe = await description();


            // running commands
            console.log("\n\n" + chalk.blue("Adding files to git ..."));
            await spawnIO('git', 'add', '.');
            console.log(chalk.green("Successfully added files to git"));

            // committing files
            console.log("\n\n" + chalk.blue("Committing to git ..."));
            await spawnIO('git', 'commit', '-S', '-m', `${commit.type} : ${commit.message}`, '-m', `${commit.describe}`, '--no-verify');
            console.log(chalk.green("Successfully committed to git"));

            return true;

        } catch (e) {
            return Promise.reject(e)
        }

    } else {
        return Promise.reject("Commit cancelled by user")
    }
};

/**
 * spawn a new process with inherited stdio
 * @return {Promise<boolean>}
 */
async function spawnIO(...args) {
    const cmd = args[0];
    args.shift();

    try {
        await spawn(cmd, args, {stdio: 'inherit'});
        return true;
    } catch (e) {
        return Promise.reject("failed to execute the command")
    }
};

note that if I include more flow after the commit step , then no lines are showing the color anymore after this (only their corresponding codes)

weird thing

if the child-process doesn't write to stdout then then next line properly show the the chalk colors like in git add . command in above code & image.

more weird thing

everything is completely working perfectly when using VS-code inbuilt terminal with bash support.

I'll close this when it's resolved in the new version. :)

<!-- Provide a concise summary of the issue in the title above. -->

What is the issue you have?

The following program...

#include "./json.hpp"

#include <iostream>

nlohmann::json makeobj() {
        return {
                {"type", "Foo"},
                {"location", {10, 20}}
        };
}

int main() {
        std::cout << makeobj().dump() << std::endl;
        return 0;
}

... compiled with the following flags ...

$ c++ -Wall -Wextra -Werror -std=c++11 -Wshadow -pedantic-errors -fno-elide-constructors -Winit-self -Wold-style-cast -Woverloaded-virtual -Wuninitialized -Wmissing-declarations -fvisibility=hidde
n -Wunused -g3 -O0 -otest-json test-json.cc

... produces the following output:

[[null,null],[null,[null,null]]]

Omitting the -fno-elide-constructors flag, we get the following (correct) output:

{"location":[10,20],"type":"Foo"}

I've since removed the -fno-elide-constructors from the build script as it was leftover from another project and isn't necessary (or really a good idea) for this project. I just figured you might want to know about it.

I don't fully understand the nuances of the flag but I would imagine it's not a flag that'd be "compatible" with this library (understandably so). At the very least, some documentation in the Notes section in the readme might be a worthwhile PR as it was the first place I looked for an explanation of the null output. Caused a 15 minute headache tracking it down - not terrible, but just annoying enough to open this issue :)

Thanks for the great library!

Which compiler and operating system are you using?

<!-- Include as many relevant details about the environment you experienced the bug in. --> <!-- Make sure you use a supported compiler, see https://github.com/nlohmann/json#supported-compilers. -->

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS"

$ c++ --version
Ubuntu clang version 12.0.0-++20200829052612+bf21ce7b908-1~exp1~20200829153238.148
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin

Which version of the library did you use?

Commit 1bcabd9e83ebc2d04b5767c7f51bf385e80398d6; single include header vendored into project.

Ugh I hate this bot, don't bother. I'll close it for you.

I'm quite certain they meant they wanted to confirm the work that needs to be done, not that they don't know how to make a PR.

I've been neglecting this repo for a while now due to some pandemic-related stresses. I apologize.

I'm quite hesitant on changing anything at the present moment because of what the v5 release might look like. If we are to change the programmatic nature of things, I think we'll keep .enable and .disable as-is but deprecated in a minor release. Then, we'll introduce .configure() (better name suggestions are appreciated).

I need to think a bit more about the best way to go about this given that v5 is going to be more or less a large rewrite. I also need to discuss some ownership matters with the other maintainers before I can say anything definitively.

Released as 3.1.3, thanks again for the report and apologies for how long it took to address.

Hello,

When I parse hex values with alpha #000000aa I get { model: 'rgb', color: [ 0, 0, 0 ], valpha: 0.67 } The same valpha value is calculated for #000000ab

This is probably due to the rounding when converting from 255 base to 1 base. Is there a way to access the intermediate 255 base value?

I understand the difference isn't much between both values, but the problem is that I can't retrieve the original hex value from the object... both giving #000000aa

Any idea?

Okay so digging deep into color-string's history, this was a bug that was introduced as a solution to another bug.

• Hex support wasn't added until Qix-/color-string#33
• A bug was uncaught there that rounded the alpha to either 0 or 1, which was "fixed" in https://github.com/Qix-/color-string/commit/eb857c2e5f421373a00057d08afb34f45b1095e1
• However, the real fix should have been simply to remove the Math.round. Not sure what the rationale was to lock it to two digit precision (perhaps for aesthetic? which I'm over now). But there was no technical reason for it that I can find, and the other string parsers do not make the same guarantee.

I'll fix this in color-string and release shortly. Apologies for the delay, the pandemic made life a lot harder.

Wow, this is definitely a bug.

Apologies for the delay - if you're still using this library, or interested, could you provide some more information?

Under normal circumstances I'm opposed to supporting individual color spaces because they are entirely arbitrary (as opposed to color models, which are not). If there's substantial reasoning for including it under the guise of a color model then I'd be willing to include it.

Hello, I came across this error today. It looks like #00ff00 works but 00ff00 does not (missing # prefix. I'm doing this as a workaround. Any chance of supporting hex strings with an optional octothorp?

  try {
    return Color(input)
  } catch(originalError) {
    try {
      // Is this a 'Unable to parse color from string' error?      
      return Color('#' + input);
    } catch(_) {
      throw originalError;
    }
  }
}```

Inversion can be a complimentary color huge shift or a color channel negation (1-c) - "invert" isn't really specified here. What is the "opposite color" in this case?

That's my point. :)

For complimentary colors, simply rotate the hue by 180 degrees: color.rotate(180).

For one-minus inversion, just call color.negate(). Other forms of inversion aren't common and thus don't really warrant their own functions.

In the future when making bug tickets, please specify the environment and version within which you're using the library.

Node.js:

• If you are using Node.js < 8.3.0, upgrade to at least 8.3.0 (preferably, at least 10.0.0)
• If you are using Node.js >= 8.3.0 < 10.0.0, pass the --harmony flag to your node process.
• This should be working on Node >= 10.0.0

Browser:

• Does not work in any version of IE (note that Edge is not IE)
• To view browser support, look for your target browser's version support for "Unicode Escapes" on the MDN Regular Expression compatibility page

[4/11] Building CXX object CMakeFiles/thread_pool_test.dir/test/thread_pool_test.cpp.o
In file included from ../test/thread_pool_test.cpp:3:
In file included from ../include/thread_pool/thread_pool.hpp:19:
../include/thread_pool/semaphore.hpp:21:3: warning: explicitly defaulted move constructor is implicitly deleted [-Wdefaulted-function-deleted]
  Semaphore(Semaphore&&) = default;
  ^
../include/thread_pool/semaphore.hpp:40:14: note: move constructor of 'Semaphore' is implicitly deleted because field 'mutex_' has a deleted move constructor
  std::mutex mutex_;
             ^
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_mutex.h:94:5: note: 'mutex' has been explicitly marked deleted here
    mutex(const mutex&) = delete;
    ^
In file included from ../test/thread_pool_test.cpp:3:
In file included from ../include/thread_pool/thread_pool.hpp:19:
../include/thread_pool/semaphore.hpp:22:14: warning: explicitly defaulted move assignment operator is implicitly deleted [-Wdefaulted-function-deleted]
  Semaphore& operator=(Semaphore&&) = default;
             ^
../include/thread_pool/semaphore.hpp:40:14: note: move assignment operator of 'Semaphore' is implicitly deleted because field 'mutex_' has a deleted move assignment operator
  std::mutex mutex_;
             ^
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_mutex.h:95:12: note: 'operator=' has been explicitly marked deleted here
    mutex& operator=(const mutex&) = delete;
           ^
In file included from ../test/thread_pool_test.cpp:3:
../include/thread_pool/thread_pool.hpp:42:3: warning: explicitly defaulted move constructor is implicitly deleted [-Wdefaulted-function-deleted]
  ThreadPool(ThreadPool&&) = default;
  ^
../include/thread_pool/thread_pool.hpp:105:13: note: move constructor of 'ThreadPool' is implicitly deleted because field 'thread_semaphore_' has a deleted move constructor
  Semaphore thread_semaphore_;
            ^
../include/thread_pool/semaphore.hpp:18:3: note: 'Semaphore' has been explicitly marked deleted here
  Semaphore(const Semaphore&) = delete;
  ^
In file included from ../test/thread_pool_test.cpp:3:
../include/thread_pool/thread_pool.hpp:43:15: warning: explicitly defaulted move assignment operator is implicitly deleted [-Wdefaulted-function-deleted]
  ThreadPool& operator=(ThreadPool&&) = default;
              ^
../include/thread_pool/thread_pool.hpp:105:13: note: move assignment operator of 'ThreadPool' is implicitly deleted because field 'thread_semaphore_' has a deleted move assignment operator
  Semaphore thread_semaphore_;
            ^
../include/thread_pool/semaphore.hpp:19:14: note: 'operator=' has been explicitly marked deleted here
  Semaphore& operator=(const Semaphore&) = delete;
             ^
4 warnings generated.
[11/11] Linking CXX executable bin/thread_pool_test

Compiler is clang:

Ubuntu clang version 12.0.0-++20200928064922+37ef2255b64-1~exp1~20200928165602.178
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin

Nope, I'm using this repo directly :) Thank you so much!

Like I said, they're useful for development.

@N00byEdge Yep, that installs the bootloader to a pre-existing device or raw image format. It doesn't say anything about generating a standalone rescue ISO given a configuration file and a binary image.

During development, grub-mkrescue is pretty essential for building quick ISO images for testing in e.g. VMware or Qemu (via -cdrom).

Would it be possible to supply a limine-mkrescue utility that does something similar?

In our case, yes - we have -Wall enabled.

It's not supported natively, so a build step would be required. Unfortunately, package management for the different types of modules still is pretty terrible. This is why most large modules are still CJS exported.

[4/11] Building CXX object CMakeFiles/thread_pool_test.dir/test/thread_pool_test.cpp.o
In file included from ../test/thread_pool_test.cpp:3:
In file included from ../include/thread_pool/thread_pool.hpp:19:
../include/thread_pool/semaphore.hpp:21:3: warning: explicitly defaulted move constructor is implicitly deleted [-Wdefaulted-function-deleted]
  Semaphore(Semaphore&&) = default;
  ^
../include/thread_pool/semaphore.hpp:40:14: note: move constructor of 'Semaphore' is implicitly deleted because field 'mutex_' has a deleted move constructor
  std::mutex mutex_;
             ^
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_mutex.h:94:5: note: 'mutex' has been explicitly marked deleted here
    mutex(const mutex&) = delete;
    ^
In file included from ../test/thread_pool_test.cpp:3:
In file included from ../include/thread_pool/thread_pool.hpp:19:
../include/thread_pool/semaphore.hpp:22:14: warning: explicitly defaulted move assignment operator is implicitly deleted [-Wdefaulted-function-deleted]
  Semaphore& operator=(Semaphore&&) = default;
             ^
../include/thread_pool/semaphore.hpp:40:14: note: move assignment operator of 'Semaphore' is implicitly deleted because field 'mutex_' has a deleted move assignment operator
  std::mutex mutex_;
             ^
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_mutex.h:95:12: note: 'operator=' has been explicitly marked deleted here
    mutex& operator=(const mutex&) = delete;
           ^
In file included from ../test/thread_pool_test.cpp:3:
../include/thread_pool/thread_pool.hpp:42:3: warning: explicitly defaulted move constructor is implicitly deleted [-Wdefaulted-function-deleted]
  ThreadPool(ThreadPool&&) = default;
  ^
../include/thread_pool/thread_pool.hpp:105:13: note: move constructor of 'ThreadPool' is implicitly deleted because field 'thread_semaphore_' has a deleted move constructor
  Semaphore thread_semaphore_;
            ^
../include/thread_pool/semaphore.hpp:18:3: note: 'Semaphore' has been explicitly marked deleted here
  Semaphore(const Semaphore&) = delete;
  ^
In file included from ../test/thread_pool_test.cpp:3:
../include/thread_pool/thread_pool.hpp:43:15: warning: explicitly defaulted move assignment operator is implicitly deleted [-Wdefaulted-function-deleted]
  ThreadPool& operator=(ThreadPool&&) = default;
              ^
../include/thread_pool/thread_pool.hpp:105:13: note: move assignment operator of 'ThreadPool' is implicitly deleted because field 'thread_semaphore_' has a deleted move assignment operator
  Semaphore thread_semaphore_;
            ^
../include/thread_pool/semaphore.hpp:19:14: note: 'operator=' has been explicitly marked deleted here
  Semaphore& operator=(const Semaphore&) = delete;
             ^
4 warnings generated.
[11/11] Linking CXX executable bin/thread_pool_test

Compiler is clang:

Ubuntu clang version 12.0.0-++20200928064922+37ef2255b64-1~exp1~20200928165602.178
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin

Assertion in debug mode on Visual Studio 2019 if ini files contains BOM like EF BB BF at the beginning (function ltrim). Works if BOM is removed manually.

Calling code:

std::ifstream file{ "hello.ini" };
tortellini::ini dict;
file >> dict;

https://en.wikipedia.org/wiki/Byte_order_mark

With a file containing:

v = hello

and extracting a bool from that using

const auto b = ini[""]["v"] | true;

I would expect the fallback to be the result, but there returned value is false. In tortellini.hh

inline bool operator |(bool fallback) const {
	return _value.empty()
		? fallback
		: (
			   case_insensitive::compare(_value, "1")
			|| case_insensitive::compare(_value, "true")
			|| case_insensitive::compare(_value, "yes")
		);
}

This function only uses the fallback if the _value is empty, and not if the string isn't one of the valid [1|true|yes] options. This can be seen in #5 test.cc line 248.

The makefile uses g++ and -std=c++11 for example, along with the other -x flags - none of which work on MSVC.

Thanks again, though I think I might switch to CMake so that we're not relying upon compiler-specific flags and that tests can be run on Windows.

Removed the local copy of catch2 and gets it as needed, also allows the bool test to pass based on clarification in #7 . The floating point string formatting now works for all but the long double, this test fails, so a separate PR will be submitted against the actual tortellini.hh file for this as requested.

All tests now run on push on GitHub Actions on 3 architectures with a time out of 3 minutes - this will fail when it runs because of the long double stuff.

Nevermind, my last comment made no sense. Been a minute since I've looked at this repo, apologies.

Can you add back catch2? I don't have a problem with the vendored test suite, and I certainly do not like build scripts pulling files from the internet.

Nevermind, there was no build system. My last comment made no sense. Changes look OK, thank you again for all the work you've done :)