Download page: Added options

This adds a new 'Options' section to the download page where plugins and Prism itself can be configured.

The basic idea here is that there are options which are a collection of option items. An option can require any number of components and is only enabled if all required components are enabled. Only options that are enabled will be visible.
Every option item translates to one label + one input element. An item is responsible for validating inputs. I added support for 3 types of inputs: boolean (-> input[type=checkbox]), number (-> input[type=number]), and string (-> input[type=text]). But right now, I don't use the number type.
The option will then be used to apply changes to the JS and CSS source code according to the values of its items.
The item values of all enabled options will be stored in the URL if the value differs from the default value.

I added 3 options:

A small general option to disable automatic highlighting.
The Custom Class prefix option. (#1055)
Options for Filter HighlightAll to set filterKnown and to add CSS selectors. (not enabled in the image)

To apply the prefix to the theme, I used Prism's CSS language to tokenize the CSS code and get all selectors and replaced all token names using a regular expression.

This is fantastic work @RunDevelopment! I haven't looked at the code very closely, but the functionality is sorely needed!

Thanks.
Looking at it again, the only thing I'm unhappy about is that download.js now contains plugin logic. I really should have made the getOptions function into its own file (this will also help the already quite large download.js).
And I need to revisit the Custom Class implementation. I used Prism to parse CSS because it was convenient but come on. I should do this the right way.

And I need to revisit the Custom Class implementation. I used Prism to parse CSS because it was convenient but come on. I should do this the right way.

I did that a few days ago 😊 (to parse JS though, not CSS)

Ok. No CSS parser. I wasn't able to find a good CSS parser that just works on the web and preserves spaces and comments. Prism-parsing it is then.
I also found another major pain point for the Custom class prefix option: To which classes do we add the prefix?
Right now, I add the prefix to all classes that are in the same component selector as a .token class. This works for all themes but breaks some plugins. It breaks the CSS of plugins in two ways:

Some component selectors of tokens don't have a .token class. I think that this is a problem of the plugin and should be fixed for each respective plugin. I know that Tree view has this problem. I haven't check for any other plugins yet.
Some plugins might all classes to tokens after the warp hook meaning that Custom Class can't add the prefix. The CSS will still get the prefix, so the style doesn't work (e.g. Match braces). How do we fix this? (Match braces is incompatible with Custom class right now anyway.)

Ok. No CSS parser. I wasn't able to find a good CSS parser that just works on the web and preserves spaces and comments. Prism-parsing it is then.

You can also just do regex replace on the fetched CSS, theme CSS is pretty simple, so that should work quite well.

I also found another major pain point for the Custom class prefix option: To which classes do we add the prefix?

Would not prefixing the token class itself alleviate any of these? I suspect it's not a very commonly used name...
Also, perhaps we need to bite the bullet and bake this functionality into the core instead of making custom classes a plugin. It seems like fairly important functionality…
(Aaand this is where I wish we had usage stats for plugins...)

Would not prefixing the token class itself alleviate any of these?

Not really. Most plugins search for specific tokens by their type. Given that Prism supports arbitrary prefixes and even remapping (via Custom Class), you could argue that the plugin (e.g. Match Braces) is at fault.
Right now, the only thing nobody modifies during the conversion from token stream to markup are attributes, so I could use marker attributes instead of marker classes to implement Match Braces. The plugin will then be implemented partly in warp and partly in complete. In wrap I'll add the marker attributes before Custom Class changes any classes and in complete I'll query by these attributes. Should work, I guess.
To make this more stable we could make a pre-wrap hook that isn't allowed to change data in the environment but it can append new data (of course, you can also read). I.e. you can't change any classes or attributes in pre-wrap but you can add new ones.

(Aaand this is where I wish we had usage stats for plugins...)

We don't have those? I always assumed that we did. I'm not very familiar with Google Analytics but if they also collect information on the hash of the URL of the download page, then we have these stats.


fix: add Swift 5.6 case in swiftVersion property to resolve compiler error

Issue #

Description of changes

smithy-swift (and thereby the AWSSwiftSDK) throw a compiler error when building with Swift 5.6
This is a quick fix that resolves the compiler error and doesn't break anything else based on manual testing.
Next step would be supporting Swift 5.6 language features, e.g. any P. That change should come in a subsequent feat PR so we can fix the existing issue quickly.
Side note: Swift 5.7 has been confirmed as the next major version. However If we want to keep this language version checking strategy going forward, it may make sense to switch to > existing version rather than >= potential next version.
Scope

[x] Bug fix (non-breaking change which fixes an issue)
[ ] ~New feature (non-breaking change which adds functionality)~

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

This is purely for grabbing the version number at runtime for the user agent String. No need for any follow on PR with language changes with this change. Also don't change to > because it's for the user agent String so that wouldn't make sense.


NEW Moving available methods for Register component into redux state

This allows more control over what can be registered by the components consuming the Register component. Required for #85

I've added some docs. Makes me realise we've been a bit lacking in the docs so far. I'll try to think about docs more in subsequent PRs 😅

Whoops. Fixed 😛

Merging with @robbieaverill's approval 🙂


goldmark-jupyter: support cell attachments in markdown cells

This PR adds a package with extensions for goldmark and nb that, together, add support cell attachments in markdown cells.
Some important remarks:

While nb aspires to work with different markdown renderers, not all of them have an extension API that's permissive enough to allow for a similar implementation. This package may serve as a POC / template for extensions that target other renderers.
Not publishing goldmark-jupyter as a standalone module (in a separate repo), because it is rather niche and wouldn't be of much use outside of nb "ecosystem".

🚧 BLOCKED BY #4

Codecov Report
Attention: 7 lines in your changes are missing coverage. Please review.

Comparison is base (b2b0928) 81.27% compared to head (394e1a0) 82.13%.

Files
Patch %
Lines

render/render.go
36.36%
5 Missing and 2 partials :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main       #5      +/-   ##
==========================================
+ Coverage   81.27%   82.13%   +0.86%
==========================================
  Files           7       11       +4
  Lines         534      571      +37
==========================================
+ Hits          434      469      +35
  Misses         81       81
- Partials       19       21       +2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


"poetry config" command does not create path to config.toml in 1.0.0a4

[x] I am on the latest Poetry version.
[x] I have searched the issues of this repo and believe that this is not a duplicate.
[x] If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

OS version and name: Ubuntu 18.04 w/ python3.7 (in docker container)
Poetry version: 1.0.0a4
Link of a Gist with the contents of your pyproject.toml file: N/A

Issue
The poetry config command does not auto create the path to the directory in latest preview version:
root@58ef10ebedba:/build# poetry --version
Poetry version 1.0.0a4
root@58ef10ebedba:/build# poetry config -vvv settings.virtualenvs.in-project true

[FileNotFoundError]
[Errno 2] No such file or directory: '/root/.config/pypoetry/config.toml'

Traceback (most recent call last):
  File "/usr/local/lib/python3.7/dist-packages/clikit/console_application.py", line 131, in run
    status_code = command.handle(parsed_args, io)
  File "/usr/local/lib/python3.7/dist-packages/clikit/api/command/command.py", line 112, in handle
    status_code = self._do_handle(args, io)
  File "/usr/local/lib/python3.7/dist-packages/clikit/api/command/command.py", line 160, in _do_handle
    return getattr(handler, handler_method)(args, io, self)
  File "/usr/local/lib/python3.7/dist-packages/cleo/commands/command.py", line 92, in wrap_handle
    return self.handle()
  File "/usr/local/lib/python3.7/dist-packages/poetry/console/commands/config.py", line 152, in handle
    setting_key, unique_config_values[setting_key], values
  File "/usr/local/lib/python3.7/dist-packages/poetry/console/commands/config.py", line 240, in _handle_single_value
    self._settings_config.add_property(key, normalizer(value))
  File "/usr/local/lib/python3.7/dist-packages/poetry/config.py", line 65, in add_property
    self.dump()
  File "/usr/local/lib/python3.7/dist-packages/poetry/config.py", line 101, in dump
    fd = os.open(str(self._file), os.O_WRONLY | os.O_CREAT, mode)

This works fine in latest stable version:
root@4575f7467c4c:/build# poetry --version
Poetry 0.12.16
root@4575f7467c4c:/build# ls /root/.config
ls: cannot access '/root/.config': No such file or directory
root@4575f7467c4c:/build# poetry config settings.virtualenvs.in-project true
root@4575f7467c4c:/build# ls /root/.config
pypoetry
root@4575f7467c4c:/build# ls /root/.config/pypoetry
auth.toml  config.toml
root@4575f7467c4c:/build# cat /root/.config/pypoetry/config.toml
[settings]
[settings.virtualenvs]
in-project = true

I've tracked this down to a change in cleo's internal API.  I'll attempt to submit a PR to fix this.

This duplicate #1248 and #840.
Should be fixed by #1272.

With 1.0.0a4, I just had to create ~/.config/pypoetry folder and the configuration was working.
With 1.0.0b1, I have to create the folder + create the file ~/.config/pypoetry/config.toml.

Can anyone confirm that #1324 fixed this?

I tested it, it is fixed! I am looking forward for the next pre-release.

Great!


Backup only works with DEBUG_MODE=TRUE in 3.5.2

Summary
The issue occurred after upgrading to the latest image 3.5.2. Reverting to 3.4.2 resolves the issue.
The following backups were run subsequently and resulted in these files being uploaded to S3 (see filesizes).
Without DEBUG_MODE=TRUE

With DEBUG_MODE=TRUE

Steps to reproduce

Run docker-compose (see environment)
Run backup

What is the expected correct behavior?
Actual backups being uploaded into S3 Bucket WITHOUT DEBUG_MODE=TRUE
Relevant logs and/or screenshots

Environment

# docker-compose.yml
version: "3"

services:
  db-backup:
    image: tiredofit/db-backup:3.5.2
    environment:
      - BACKUP_LOCATION=S3
      - S3_HOST=eu2.contabostorage.com
      - S3_REGION=eu2
      - S3_BUCKET=backups
      - S3_PATH=postgres
      - S3_KEY_ID=abc
      - S3_KEY_SECRET=abc
      - CHECKSUM=SHA1
      - COMPRESSION=ZSTD
      - SPLIT_DB=TRUE
      - CONTAINER_ENABLE_MONITORING=FALSE
      - DEBUG_MODE=TRUE
      - DB_DUMP_BEGIN=0315 # begin at 03:15 o'clock
      - DB_DUMP_FREQ=1440 # every 24 hours
      - DB_CLEANUP_TIME=8640 # cleanup backups older than 1 week
      - DB_TYPE=pgsql
      - DB_HOST=postgres
      - DB_NAME=ALL
      - DB_USER=postgres
      - DB_PASS=wonttell
      -
  postgres:
    image: postgres:14.5
    environment:
      POSTGRES_PASSWORD: wonttell

Image version / tag:  3.5.2
Host OS: Docker

Possible fixes
Revert to 3.4.2 (haven't checked if 3.5.0 works)

Can you share some of the DEBUG_MODE=TRUE output specifically a couple of the pg_dump -h command ? I'm also curious if instead of DEBUG_MODE=TRUE you turn that off and switch to SHOW_OUTPUT=TRUE or CONTAINER_LOG_LEVEL=DEBUG ..
I'm trying to see if I've done anything to silence the postgres backups since 3.4.2 but not coming up with anything.

Never mind, I see it now. Going to revert those changes.

Resolved in 3.5.3. building as we speak! https://github.com/tiredofit/docker-db-backup/commit/7e5e9d308dcc6b4d1019cd2994ae695ac89b06e7

Ahh, awesome 🥳
I just replicated the issue locally and can confirm that it is resolved with 3.5.3!
Thank you for your awesome work!

Great to hear! Thanks again.


[Select] disabled component looks strange

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
In my project, the Select component shows spurious elements when its 'disabled' property is set. The problem only arises when the 'multiple' attribute is also set. The spurious elements that are visible correspond to the selected values and should be invisible.
I'm using the latest mui version (mui-material 5.9.0, emotion 11.9.3) inside an electron application (chrome browser).
This is the select with 'disabled' not set

This is the select with 'disabled' set

Expected behavior 🤔
The  component should be disabled and no spurious elements should be visible. The disabled  should look like this:

The screenshot above was made from an online sandbox that works as expected: https://codesandbox.io/s/selectvariants-demo-material-ui-forked-yjetry?file=/demo.js
Steps to reproduce 🕹
Steps:

Checkout the provided sandbox link for the "good" example
Suggest why this example does not work in my setup. I re-installed the mui library multiple times without solving the problem.

Context 🔦
No response
Your environment 🌎
  System:
    OS: Windows 10 10.0.19044
  Binaries:
    Node: 14.18.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.1 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 8.14.0 - ~\.nrfconnect-apps\local\blt24-tester\node_modules\.bin\npm.CMD
  Browsers:
    Chrome: 103.0.5060.114
    Edge: Spartan (44.19041.1266.0), Chromium (103.0.1264.49)
  npmPackages:
    @emotion/react: ^11.9.3 => 11.9.3
    @emotion/styled: ^11.9.3 => 11.9.3
    @mui/base:  5.0.0-alpha.89
    @mui/icons-material: 5.3.0 => 5.3.0
    @mui/material: ^5.9.0 => 5.9.0
    @mui/private-theming:  5.9.0
    @mui/styled-engine:  5.8.7
    @mui/system:  5.9.0
    @mui/types:  7.1.4
    @mui/utils:  5.9.0
    @types/react: 17.0.38 => 17.0.38
    react: ^17.0.2 => 17.0.2
    react-dom: ^17.0.2 => 17.0.2
    typescript: 4.5.4 => 4.5.4

I couldn't reproduce it on the sandbox you shared 👎🏻 !

@raesche Forked your codesandbox and tried with disabled
You added screenshot which has multiple props true, and you shared the codesandbox link with single selection.
Please atleast share the codesandbox with same scenario which you want to explain.
However I tried and issue is not reproduced - Codesandbox

It doesn't look like this bug report has enough info for one of us to reproduce it.
Please provide a CodeSandbox (https://material-ui.com/r/issue-template-latest), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem.
Here are some tips for providing a minimal example: https://stackoverflow.com/help/mcve

I was unable to reproduce this issue on any sandbox, that's why I could not provide a sandbox link with the problem. However the problem still exists in my project (it's an electron application) and I was not able to resolve it (even when copying the sample code from the MUI website and updating to the latest version).
In the meantime I discovered that the spurious element is the  label that is somehow not properly hidden. My workaround inside my React component looks as follows:
const inputRef = useRef();
useEffect(() => {
        if (inputRef .current) {
            const inputElement = [...inputRef .current.children].find(node => node.nodeName === "INPUT");
            if (inputElement)
                inputElement.style.display = "none";
        }
    }, [inputRef ]);

...

<Select
  ref={inputRef}
....
>

Why don't you ignore setting the display style of the input and instead show the input element when needed using conditional rendering.
Example:
const [someState, setState] = useState(false);

return (
  <div>
    {someState && <input />}
  </div>
);

Dear Haneen
Thanks, but the issue is not related to a single <Input> that needs to be visible or hidden. The problematic <Input> is part of the <Select> component from MUI (see https://mui.com/material-ui/react-select/) that should be automatically hidden when the component is disabled. This works in every sandbox and every example that I've found, but for some reason not in my electron application.
Searching the problematic <Input> within the <Select> component and set it's display property to 'none' is just a workaround that fixed the issue in my project.

Thanks minh-le-jh for your reply. The project is already old and uses my workaround, but I will give it a try next time I'm working on on it.
Best regards


fix: everything involved pr link

Description
This PR fixes the Everything you're involved in link in the PR list. Before this change, clicking the link in the PR list would lead to the issues page instead. With this change, you stay in the PRs.
This does not change the functionality in the issues page.
Test URLs
https://github.com/refined-github/refined-github/pulls
(pretty much everywhere)
closes #7273

Thank you for the PR, but actually that issue was incorrect, I had misunderstood it. I thought that the link was pointing to the base /issues page without a search, not this.
All the links in that menu are static, they don't alter the current search/page like the dropdown filters on the right.
So this feature is working correctly, the /issues page also includes the PRs, because the filter is "Everything" that involves you.

@fregante no worries, it was still fun to take a dive into your codebase again 🙂


Re-implement route generation

With all of the changes surrounding routing and multiple routers in angular2 the generation of routes had been disabled.
We will start to re-implement this feature starting with this issue...
Generate a routing file
ng generate route
modulePath - argument which contains the relative path to a module file in your app to which this new routing file will be associated with
Given this app structure:
.root
+--src
  +--app
    +--feature1
      +--feature1.module.ts

Running this
ng generate route feature1/feature1.module.ts will yield
.root
+--src
  +--app
    +--feature1
      +--feature1.module.ts
      +--feature1.routing.ts

The other side effect will be the import of the new routing module into feature1.module.ts
import { RoutingModule } from './feature1.routing';
@NgModule({
  imports: [ ..., RoutingModule ]
})...

Alternatives to modulePath that will produce the same result (based upon the above example)

feature1/feature1.module (by auto-adding ts extension)
feature1 (by searching this directory for a single *.module.ts file

Note: specific route generation
This issue is to handle the creation of routing files, the generation of specific routes may be handled later, this is the first step toward that

Is there any estimation for release of new route generation?

@otabekgb at this point no... the CLI currently generates routing files (not specific routes) with new projects and with module generation.


ionic-cli 2.0.0: Plugins not remembered in package.json?

Hi,
beside I have some problems with plugins and ionic.native (https://github.com/driftyco/ionic-native/issues/438) which I hope it is somehow solved by the 2.0.0 version of the ionic-cli, I have problems when installing plugins.
Simple steps to reproduce in any project:
ionic state clear
ionic plugin add cordova-plugin-camera

cat package.json # no cordova-plugin-camera added

Looks the same as https://github.com/driftyco/ionic-cli/issues/1255

Yes it's the same, sorry for double posting. I'm closing this one.


"/**" works but "///" does not work

Self explanatory. When I type the string "/**" and press enter, the extension works properly and creates an empty comment block that looks like the following:
/**
 * @brief
 * @note
 * @retval None
 */

However, when I type "///" and press enter, nothing happens. I am editing C/C++ code.

Extension auto activates on c# (.cs) files to use "///" comments, because it is proper type of doc comments and works like in VS. Instead on .cpp and .c files where commonly used "/**" comments


Save/restore XMM reqs on WIN64.

I had to refactor the code a bit to keep it simple.
On WIN64 xmm regs are saved first to avoid dealing with alignment.
Non WIN64 code path only handles gp regs now, so the assert (i <= R15_HARD_REG) is gone. I can add it back if necessary.

Thank you for the patch.  I've merge it into the mainline.


"three.js inspector: no scene to inspect. Please export is as window.scene" error despite window.scene and scene existing as globals

An idea of what could be going wrong? Here is a screenshot of the output.

I'm using the latest version of the inspector installed as an unpacked extension from the github

I am having the same issue.
The inspector works with my dummy scene in the index.html,
but as soon as I replace the dummy scene with the one from my App.js the Inspector says there is no scene
https://gist.github.com/n3ssi3/2d297ba787e08765ee432c9c94051c07

I think the problem is, that the inspector attaches to the index html, before the scene is generated in you App.js.


Update to AtomsBase 0.5

I think this is all that is required.

Yep looks good, I'll tag a new version. Thanks!


[Feature request] Parse a boolean value represented by string logically

From https://github.com/colinhacks/zod/issues/1630#issuecomment-1824670600
Currently z.boolean() simply replesents Boolean() for coerce. So it handles string value as boolean along with the standard Boolean() specification.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Boolean#boolean_coercion
const b = z.coerce.boolean()
b.parse("true");    // true
b.parse("false");   // true
b.parse("True");    // true
b.parse("False");   // true
b.parse("1");       // true
b.parse("0");       // true
b.parse("");        // false
b.parse(undefined); // false
b.parse("others");  // true

However we often need to handle string as boolean, "false" or "0" as false, such as parsing environment valiables.
Current workaround is like
const b1 = z.string().toLowerCase().transform(JSON.parse).pipe(z.boolean());
b1.parse("true");   // true
b1.parse("false");  // false
b1.parse("True");   // true
b1.parse("False");  // false
b1.parse("tRue");   // true
b1.parse("fAlse");  // false
b1.parse("1");      // ZodError
b1.parse("0");      // ZodError
b1.parse("others"); // ZodError

My suggestion is a new string transformation: z.string().boolean()
The transforming specification in Go standard library's strconv.ParseBool() is good for it.
https://pkg.go.dev/strconv#ParseBool

ParseBool returns the boolean value represented by the string. It accepts 1, t, T, TRUE, true, True, 0, f, F, FALSE, false, False. Any other value returns an error.

// Suggestions
const b1 = z.string().boolean()
b1.parse("true");    // true
b1.parse("false");   // false
b1.parse("True");    // true
b1.parse("False");   // false
b1.parse("tRue");    // ZodError in boolean transformation
b1.parse("fAlse");   // ZodError in boolean transformation
b1.parse("1");       // true
b1.parse("0");       // false
b1.parse("");        // ZodError in boolean transformation
b1.parse(undefined); // ZodError by string() as required
b1.parse("others");  // ZodError in boolean transformation

// false by default
const b2 = z.string().boolean().default(false)
b2.parse(undefined); // false
b2.parse("others");  // ZodError in boolean transformation

// false by default and for invalid string value
const b3 = z.string().boolean().default(false).catch(false)
b3.parse("");        // false
b3.parse("others");  // false

I read the code and found that I cannot implement the above syntax only with the change in ZodString but it must be changed in ZodBoolean.
I think it is not so different with implementing strict boolean parsing mode for coerce (syntax is different, off cource)
To be the changes only in ZodString, the syntax will be like
// false by default
const b2 = z.string().boolean().default("false")
b2.parse(undefined); // false
b2.parse("others");  // ZodError in boolean transformation

// false by default and for invalid string value
const b3 = z.string().boolean({ catch: false }).default("false")
b3.parse("");        // false
b3.parse("others");  // false

default() arg value must be a string.
catch() arg value also must be a string but it is not abled to parse to a boolean in catch(). So a parse error might have to be handled in the transformation.

const b1 = z.string().toLowerCase().transform(JSON.parse).pipe(z.boolean());

If there is such a simple work around, then why should this be a part of zod core?

@JacobWeisenburger Thank you for your feedback.
My opinions are:

z.string().toLowerCase().transform(JSON.parse).pipe(z.boolean()) is not clear for users. As you can see #1630, many users are struggling to do this in different ways and sometimes mistake in their programs.
It is worth to be on the lineup of builtin string transformation and helps many users in the future.
It is gereral to set "1" or "0" as a boolean in environment variables for lot of tools or products but JSON.parse() does not works.
I think boolean is a last piece of zod advantage in the area of environment variables parsing.

const envSchema = z.object({
  SERVER_URL: z.string().min(5, {message: "Required"}),
  SOMETHING_VALUE: z.string(),
  EXPIRE_DAYS: z.coerce.number().default(30),
  SOMETHING_NUMERIC_CONFIG: z.coerce.number().min(1),
  DEBUG: z.string().boolean(),
  ENABLE_SOMETHING: z.string().boolean(),
});
const env = envSchema.parse(Deno.env.toObject());

I beleave that it is not much complex implementation. Sorry for my previous comment with lack of understaing of the zod architecutre. Now I am deepdiving zod codes.

This is a really good idea.  I lost a couple hours of debugging today trying to figure out why "false" provided as a string to a ZOD parse function was resulting in "true" for a z.boolean() value.  I know it is fault of Boolean('false') being truthy, but this is a foot gun.  No one reasonable expects "false" to be parsed as Boolean true.

Also I should add that this bug isn't present with Joi.  So when I converted over to Zod from Joi, this was a huge surprise.

A really quick heads up, rather than invoking the entire JSON.parse the transform can also be just
z.string().toLowerCase().transform((x) => x === 'true').pipe(z.boolean())

This issue is for a feature request and the implementation in PR #2989.
If you would like to discuss about workarounds, #1630 is a better place.

This is what is working for me:
z.enum(['true', 'false']).transform((value) => value === 'true')

I didn't find any working solutions for my use case (query params), but I modified one example from here
export const BooleanStringZod = z
  .string()
  .refine((value) => value === 'true')
  .transform((value) => value === 'true');

Now it does what I want. string "true" turns into boolean true, everything else is false.

See https://github.com/colinhacks/zod/pull/2989#issuecomment-2091965974

I'm going to leave a comment here in case anyone has the same problem as me and finds this same GitHub issue on Google.
I needed a schema that handles both boolean values and boolean strings such as "true" and "false", turning them into a true boolean.
The solution I found was to use z.preprocess:
const schemas = {
    foo: z.preprocess((val) => {
        if (typeof val === "string") {
            if (val.toLowerCase() === "true") return true;
            if (val.toLowerCase() === "false") return false;
        }
        return val;
    }, z.boolean()),
}

I'm going to leave a comment here in case anyone has the same problem as me and finds this same GitHub issue on Google.
I needed a schema that handles both boolean values and boolean strings such as "true" and "false", turning them into a true boolean. The solution I found was to use z.preprocess:
const schemas = {
    foo: z.preprocess((val) => {
        if (typeof val === "string") {
            if (val.toLowerCase() === "true") return true;
            if (val.toLowerCase() === "false") return false;
        }
        return val;
    }, z.boolean()),
}

Like a charm!
Thank you.

Workaround works with :
true, 'true', 'True', false, 'false', 'False', 0, 1, '0', '1':

const castStringToBool = z.preprocess((val) => {
  if (typeof val === "string") {
    if (['1', 'true'].includes(val.toLowerCase())) return true;
    if (['0', 'false'].includes(val.toLowerCase())) return false;
  }
  return val;
}, z.coerce.boolean());

perfect for env vars

castStringToBool

The thing is you can not really re-use this if you'd like to do:
castStringToBool.default(true)
Or make it strict and be able to apply nullish()


Expo 49 failing 'expo doctor' because of<EMAIL_ADDRESS>dependency

When using Expo 49 and installing react-native-health-connect the command expo-doctor fails because of the @expo/config-plugins dependency version.
This is the error:

To reproduce:

initialize a new Expo project with Expo 49
Install react-native-health-connect
Run expo-doctor

I'm guessing the dependency @expo/config-plugins could be moved to devDependencies - potentially supplemented with an peerDependency with a loose version?

Yeah, it makes sense. I will move it to peerDependencies.

Included in the release.

Thanks for the quick response and fix @matinzd :)


Excessive change log entries

netbox-reorder-rack version
v0.2.0
Feature type
Change to existing functionality
Proposed functionality
When moving a device to a new position, it should not make any changes to other devices in the rack.
Use case
When moving a device to a new position, this plugin creates 2 change log entries for every device in the rack.  First to set its position to null, and then to set it back to its original position.  This makes it difficult to use the change log in a meaningful way.
External dependencies
No response

Occurs in this code in SaveViewset()
`            serializer = ReorderRackSerializer(request.data)
with transaction.atomic():
for device in rack.devices.all():
device.position = None
device.clean()
device.save()
            for new in request.data["front"]:
                device = rack.devices.filter(pk=new["id"]).first()
                device.position = decimal.Decimal(new["y"])
                device.face = new["face"]
                device.clean()
                device.save()

            for new in request.data["rear"]:
                device = rack.devices.filter(pk=new["id"]).first()
                device.position = decimal.Decimal(new["y"])
                device.face = new["face"]
                device.clean()
                device.save()

            return Response(
                {"message": "POST request received", "data": serializer.data},
                status=status.HTTP_201_CREATED,
            )`

The question is why, vs comparing for a changed location or face and only saving those objects.


activate Reproducible Builds

see https://maven.apache.org/guides/mini/guide-reproducible-builds.html

Thanks @hboutemy - What is the practical difference of this PR?

what do you mean by "practical"?
the timestamp will be used to have a predictible timestamp for every jar file entry
and the removal of the current time in Build Time of META-INF/MANIFEST.MF removes one un-predictible value

see also: https://reproducible-builds.org/

I personally prefer using the git commit date via the git-commit-id-maven-plugin instead, the release plugin automatically updates the timestamp as well.  https://maven.apache.org/guides/mini/guide-reproducible-builds.html#FAQ
As far as I can tell you can have reproducibility right now by specifying the actual release date while rebuilding a version but I can see why this manual process is not desirable.


Add coloreful output like in jq

Colorful output is really missing.
This feature could be optional like in jq (-C colorize output, -M monochrome output). It's not vital, but would be a really nice to have.

#43 is attempting to add colorized JSON to jid.

@deniss-s
I got that feature's implementation. (colorize output & monochrome option)
https://github.com/simeji/jid/pull/51


Is this plugin compatible with Ember 2.0?

I'm getting this build error: Assertion Failed: Using {{view}} or any path based on it ('admin/templates/components/list-picker.hbs' @ L1:C0) has been removed in Ember 2.0

Not yet.

I'm using it with canary, it seems to work fine...

@fizz Thanks, that is good to know. I was a bit worried on what to do with 2.0.
Speaking of which, it would help things if I knew which version of the select-picker addon each of you is using.

@sukima I'm using 2.2.0

I'm currently using the ember default

@Chrissvo, I just reread your first comment and understood what's going on. I think your issue is solved by https://github.com/sukima/ember-cli-select-picker/commit/8c0cdb36813a1ead1017326e8280da9ce8857e17 so you might want to upgrade your version in package.json.
If you just ember install ember-cli-select-picker it'll upgrade you to 2.2.0 and the add-on will no longer be using a view.

Either that or use nativeMobile=false to skip the select view.

Thanks @fizz, just tested this and it works! Closing the issue


Converter should integrate (or reuse) online unit conversions (Bing or similar services) to increase category/unit coverage

Problem Statement
The proposed feature is to add more comprehensive coverage of categories and units for Converter through some form of integration with newly created or existing online systems.
Calculator provides unit conversions for 13 categories (Currency, Volume, Length, Weight/Mass, Temperature, Energy, Area, Speed, Time, Power, Data, Pressure, Angle) via the main Hamburger Menu. Length has for example selections for 11 units (Nanometer, Microns, Millimeters, Centimeters, Meters, Kilometers, Inches, Feed, Yards, Miles, Nautical Miles) and outputs additional "practical" units in the UI (Paperclips). While the current hard-coded list of conversions in calculator is reasonably extensive, the fixed set of units can quickly reach its limits, in particular when scientific or rare units are required (see evidence below).
Once a user hits a unit conversion limitation, they will likely turn to search engines which generally provide the requested conversions directly from the search box. This slows down the user trying to perform unit conversions (context switch to browser, copy-and-paste of converted results) overall diminishes the value of the unit conversion feature and Calculator in a cloud-connected world.
The goal for this feature is to make the Converter the one-stop-shop for unit conversions, in particular for scientific and educational settings.

Evidence or User Insights

Various gaps have been identified and documented in existing issues:
https://github.com/microsoft/calculator/issues/275 - month and ns for time
https://github.com/microsoft/calculator/issues/325 - light years for distance
A Bing query for a unit conversion (https://www.bing.com/search?q=20+F+in+C) shows a "Convert units" dialog with 17 categories (Length, Mass, Temperature, Speed, Volume, Area, Time, Frequency, Angle, Force, Pressure, Energy, Power, Electric Current, Voltage, Resistance, Digital storage, Fuel consumption) which is 4 more than calculator.
The Wikipedia page for Length https://en.wikipedia.org/wiki/Conversion_of_units#Length lists 77 distinct distance units, which is 66 more than calculator.
A Bing query can also support variable conversions such as currency conversions (https://www.bing.com/search?q=20+euro+in+dollar&FORM=AWRE) where the factor changes over time.
Proposal

The related work to modernize the unit conversion architecture:
https://github.com/microsoft/calculator/issues/379
should consider making Converter fully data driven, and integrate with an online data-source or service so Converter can provide more comprehensive (and daily updatable) conversion tables without binary updates to Calculator itself.
Assuming the existence of an online service which would aggregate and serve existing conversions from online sources (i.e. via an exposed search engine API or code-sharing), add currency services, scrape Wikipedia or other public sources, and allow for curation (to avoid errors), Converter could download and cache a conversion table that is much more comprehensive than the current version.
Goals

User can convert anything that works in a search engine such as "20 dollars into euro" or "1 ly into mm" with Converter.
Non-Goals

Design and implementation of the web-service that aggregates and serves conversion data.
Low-Fidelity Concept

[Online Conversion Sources] + [Curators]  ----web service ---> [Conversion Table Artifact] ---download/update---> [Calculator] ---cache/use---> [Converter UI]
Requested Assignment

I'm just suggesting this idea.  I don't want to implement it.

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.

conversion tables will not work for non-linear conversions, ie. for dB.

also note that some of the units on wikipedia aren't units, but prefixed units. Ie. mm is not a unit; just the second m is. The first m is a prefix.

conversion tables will not work for non-linear conversions, ie. for dB.
That is true - but the the converter engine could support non-linear conversions, either as symbolic formula or a mapping table (Example: https://www.rapidtables.com/electric/decibel.html - dB to ratio conversion table) that is interpolated. In fact, even simple temperature conversion need formulas as well as allowed value ranges. A dB conversion would also need a 2nd reference input to form the ratio.

note that some of the units on wikipedia aren't units, but prefixed units
Conversions between prefixes (i.e. km into mm) are conversions nevertheless; the conversion factor would be generally a multiple of 10. I don't see the point in limiting a conversion table to pure "unit conversions" such as F to C. One has also common conversions of counts which are have no (or arbitrary units) such as "1 gross == 144, 1 small gross == 10 dozen, etc."

The [Conversion Table Artifact] mentioned above would therefore need to support the following "features" to be specified:

linear conversion without offset, i.e. 1 Thermochemical Calorie = 4.184 J)
linear conversion with offset, i.e. Temperature in K = (Temperature in F - 32) / 1.8 + 273.15
non-linear conversions using arbitrary formulas with reference input, i.e. Gain in dB @ Power P_reference = 10 * log_10 (Power P_input / P_reference)
transparently handle common prefix units (i.e. prefix m = milli = 0.001, prefix k = kilo = 1000)
allow association of prefix units to base units (i.e. a "milli" prefix is applicable to "1 meter", but not to "1 dozen")

As an example here is a similar implementation: https://github.com/angularsen/UnitsNet (90 quantities with 800+ units), which uses JSON for definitions (https://github.com/angularsen/UnitsNet/tree/master/Common/UnitDefinitions) but skipped implementing non-linear conversions (3) citing difficulty and lack of use-cases (https://github.com/angularsen/UnitsNet/issues/21).

On Wikipedia, there is a nice table of unit data at https://en.wikipedia.org/wiki/Module:Convert/documentation/conversion_data which is used by the Convert template on there.

There have been a few issues discussing which units we should include (as well as what the source of truth should be for conversion values), so we think it would be good to define an overall strategy for making decisions for converters.
We could certainly leverage Bing to help decide which units should be included, but we are generally not in favor of taking a dependency on an online service at this time. We do not feel the complexity this introduces is warranted given how infrequently units change. I think we should consider other sources as well. For example, should we consider customary/regional units (e.g., Korean Pyeong via #382)?
To prevent scope creep, we’ll limit this feature to defining which converters and units to include, what we will use as the source of truth for conversion values, and a light framework for making future decisions regarding supported converters/units. I’ll open two new issues to address (a) improving unit selection UX to ensure that it is easy to select common units while also supporting, in some cases, large sets of units, and (b) exploring improvements to general unit converter navigation (e.g., perhaps converters would be more discoverable if we collapsed all converters into one mode).

/cc ferzkopp grochocki But we cannot expect our users to go online for a simple conversion, say a man's height from centimetres to inches. This would make the Calculator pretty useless if somehow the user is unable to connect to the internet.

But we cannot expect our users to go online for a simple conversion...

Agreed. Unit conversions need to work on a freshly-installed air-gapped device.
The proposal states that a "Converter could download and cache a conversion table..." the key being the mention of a "cache" (i.e. a local copy) of the conversion table. The base installation can ship with the built-in converter table (pre-cache) so conversions will always work. However, when the device is actually online, an improved conversion table could be automatically retrieved from the online source. This would mean, the Client side unit conversion system needs to have the following features around this topic:

built-in (cached) unit conversion table (i.e. file)
conversion table versioning (in table schema and UI display)
automatic (i.e. daily check when online) and on demand (user selection) update of table schema
cloud service endpoint to serve conversion table
security facilities to deliver only official table updates from official endpoints


How to change ViewConfiguration in my @Composable function?

Because I want to change the ViewConfiguration#doubleTapTimeoutMillis on my button.
Thanks for help!

+1. I also looking for a way to change the minimumTouchTargetSize.

Will this example help?

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Fix drag and drop + element placement in level 2 activity

Component library was in the wrong spot and drag and drop didn't work correctly. This was due to the img elements inside the component containers not having their own id attributes. Adding these also helped with validation, allowing us to check whether the component dragged into a box was correct/allowed by checking that the img id was correct. Also, changed the size of boxes on the circuit to make things look more connected to the wire.
Additionally: fixed behavior regarding circuit validation and lightbulb turning on. Pressing "Test Your Circuit" now turns on lightbulb if correct components are in correct spots.
Results:

Looks great!


Request to add Eva Logik ZWave Switches to ZwaveJS

Which device is missing?
Eva Logik ZW96 and ZW97
Note: they have other ZWave models
What are the IDs?
Manufacturer ID: 0x0312
Product type: 0xc007
Product ID: 0xc000
Shows as "Unknown Manufacturer 786" and "Product: 49152" with Product Code:  "Unknown product 49159"
Sample DeviceID if it helps and I didnt form the above properly: 0x0312-0xc007-0xc000
Did you check if we really don't have it?

[X] It is not in the configuration DB
[X] It was not merged recently or has a pending PR
[X] It is not in the TODO list

Do you have a link to the PDF manual?
ZW96: https://nie-tech.com/wp-content/uploads/2020/02/ZW96-manual-2019.12.24.pdf?x18039
ZW97: https://nie-tech.com/wp-content/uploads/2020/02/ZW97-manual-2019.12.24.pdf?x18039
Others: https://nie-tech.com/manual-download/
Note: On bottom of each pdf, includes all the commands.
GeneratedJSONfromZwaveJS2MQTT.txt
ZW96-manual-2019.12.24.pdf
ZW97-manual-2019.12.24.pdf
If so, it helps in creating the config file.

Sorry I did see in the ToDo List the addition from the certified zwave site. I failed to see this the first time, and feel a bit dumb.


Error not being triggered on failed WebSocket connection (apolloClient.subscribe)

When using a simple subscription
const observer = apolloClient.subscribe({query})
observer.subscribe({next: () => console.log('All good'), error: (e)=> console.error('All bad',e)})

The error is not triggered if there is an server connection error, e.g. 404. I'm working on an environment where WS may be not available, and if that fails use polling instead.
Using the default VueApollo implementation there's no access to the SubscriptionClient to add the onDisconnected callback
Versions
vue: 2.6.12
vue-apollo: 3.0.5
apollo-client: 2.6.10
Steps to reproduce

Use a bad endpoint in wsEndpoint like wss://fakeway.google.com/subscription
Add a query subscription
No error is triggered (Something that as dev I can use to tell the subscription failed)

You can access subscriptionClient through WebSocketLink. In your apollo setup script you can export it and then import it somewhere else (e.g. vue components) for further usage.
const wsLink = new WebSocketLink({
  uri: "ws://domain/subscriptions",
  options: {
    reconnect: true
  }
})

...

export const subscriptionClient = wsLink.subscriptionClient

Thanks @jpikora!
Although I don't use WebSocketLink, I'm using the plugin configuration by default, I now see you can extract it from the createApolloClient (In case it comes handy for someone)
import { createApolloClient } from 'vue-cli-plugin-apollo/graphql-client';

const defaultOptions = {
  httpEndpoint,
  link: authMiddleware,
  persisting: true,
  ssr: false,
  tokenName: AUTH_TOKEN,
  websocketsOnly: false,
  wsEndpoint: GATEWAY_WS,
};

const apolloClientService = createApolloClient(defaultOptions);

// Extract and export apollo clients
export const { apolloClient, wsClient } = apolloClientService;


Optimize gran_alloc() in mm_granalloc.c by using builtin ctz.

optimize gran_alloc() function by using __builtin_ctz().

We cannot accept any compiler dependent code  in the common code.
PLEASE DO NOT MERGE
I am on my cell phone now.  I will make some suggestions later.

You may not called GCC builtin's directly in main code.  That is forbidden by the coding standard.  Compiler-specific and architecture-specifc logic may never appear in common code.
You may, however, use libs/libc/strings/lib_ffs.c or lib_ffsl.c.  Those will isolate the use of CTZ out of common code.
[That logic at libs/libc/strings/ is also incorrect.  Those functions should be moved to libs/libc/machine.  That is where architecture-specific logic belongs.]
I am going to close this for now.  But if you want to update the PR using the correctrly isolated functions, it can be reopened.

include/nuttx/compiler.h is the standard place for hiding compiler-/architecgture-specific logic.
Another possibility could be to hide the architecture specific logic in a header file under arch/arm/include/ that is included by a another file under include/.  See, for example, limits.h and inttypes.h

I think another option could be to add and special case inline function to include/strings.h (strings.h, not string.h) like:
#include <nuttx/compiler.h>

#if defined(CONFIG_HAVE_BUILTIN_CTZ) && defined(CONFIG_HAVE_INLINE)
static inline int ffs(int j)
{
  if (j > 0)
    {
     /* Count trailing zeros function can be used to implement ffs. */

      return __builtin_ctz(j) + 1;
    }

  return 0;
}
#endif

Of course, you would also have to suppress the normal ffs() function in that case.

The are a couple of coding standard issues with using inline functions.  Let me know.  I can implement these for you.

I see.
I agree with your proposal to add these special case inline functions that can be used in the common code. I can modify my code by using these mechanism.


CliffordTableau stabilizers and destabilizers methods return list of DensePauliString

#2423

Please give me time to review these before merging. Some of the methods needed docstrings.

Please give me time to review these before merging. Some of the methods needed docstrings.

Sorry about that. PTAL at #2489

My fault: I should have caught it.


Results got worse after quadratic decimation and poisson

I always appreciate your kind answers and your great work
Running the codes (generate_scene.py) with the default setting, I found out that results get worse as time passes.
Here are the results for the living_room.json:
Fused frame until 200

Fused final

After poisson

*After qudratic decimation

Could you explain the reasons? What should I do to get the best results like in your paper?

Hi you can take a look at the discussion in #13 and try out those steps. If the ceiling looks like this after the first stage, the default parameters for completion are unable to inpaint it properly. That is, our camera sampling fills in some holes, but others remain. As a result, poisson surface reconstruction will create these smoothing artifacts to make the mesh watertight. Also der Fig9. in the paper for a discussion about this failure mode of the method.
The two solutions are:

fiddle with hparams for completion as discussed in #13 (or improve camera sampling all together to inpaint all holes).

only complete meshes who's ceilings are not degenerate like here

Hi you can take a look at the discussion in #13 and try out those steps. If the ceiling looks like this after the first stage, the default parameters for completion are unable to inpaint it properly. That is, our camera sampling fills in some holes, but others remain. As a result, poisson surface reconstruction will create these smoothing artifacts to make the mesh watertight. Also der Fig9. in the paper for a discussion about this failure mode of the method.
The two solutions are:

fiddle with hparams for completion as discussed in #13 (or improve camera sampling all together to inpaint all holes).

only complete meshes who's ceilings are not degenerate like here

Thank you! I will try that


Ubuntu PPA

Hey, thanks for this awesome piece of software! :+1:
I've created an Ubuntu PPA for it, is it ok to add it to the wiki?

This is great! Yes, of course, you should add it to the Wiki!


Implement turso db hints command

It's not always obvious where to replicate database when using edge functions. For example:
https://twitter.com/jokcylou/status/1643895796050575362
Let's implement a turso db hints command, which shows you what are the closest locations your database is accessed from so you know where to replicate.

Hi @penberg I would like to contribute on this. Could you let me know where to get started or take reference from.
PS: thanks

There was a conversation where alternative command names were proposed (hints is not very descriptive).  One option is db inspect traffic (while also moving the current db inspect to db inspect usage) . I anticipate there will be future growth in commands that report the current state of a database, so I think it's worthwhile to go ahead and plan the command structure for that.


Black bar at top of Android app

There is a large black horizontal bar at the top of the app when the Android app is installed on a Chromebook.  It appears that the app is not stretching to fill all of the way to the top.  The bar is constant no matter how the window is resized and limits the viewport, which is annoying to look at.

dupe of #2502


New rule: SomeApply

Some.apply may break typing in two ways: First, when it is used with a null value, creating an instance of Some(null) instead of the (usually) expected None, and; Second, when it causes type inference to infer Some[T] instead of the (usually) expected Option[T]. Use Option.apply instead, to cover both cases.
def someOfNull(foo: String) = {
  // Won't compile: Some.apply is disabled - use Option.apply instead
  val expectedSafeFoo: Option[String] = Some(foo) // If foo == null, Some(null)
  val actualSafeFoo: Option[String] = Option(foo) // If foo == null, None
}

def typeInference() = {
  // Won't compile: Some.apply is disabled - use Option.apply instead
  val maybeFoo = Some("bar") // maybeFoo has type Some[String], not Option[String]...

  // ...so the following code would not have compiled
  maybeFoo match {
    case Some(value) => // ...
    case None => // ...
  }
}

The null-coercing behavior of Option.apply is undesirable in some circumstances since it can mask problems due to initialization order and some other errors that ultimately become NullPointerExceptions.
Since Scala programs shouldn't be using null anyway (and there is a wart to prevent that) the only place where Option.apply is valuable over Some.apply is when wrapping a Java API that returns null, which for most applications is not the majority of the code (if any).

Thanks for the review, @ChrisNeveu. I respectfully disagree with your points.

The null-coercing behavior of Option.apply is undesirable in some circumstances since it can mask problems due to initialization order and some other errors that ultimately become NullPointerExceptions.

I agree it may do that, but we have other tools, including warnings coming out of scalac which warn about the sort of use cases you're referring to. If you're worried about that enough that it may cause an issue, you can opt to use the rule as a warning and/or disable it in specific cases.

Since Scala programs shouldn't be using null anyway (and there is a wart to prevent that) the only place where Option.apply is valuable over Some.apply is when wrapping a Java API that returns null, which for most applications is not the majority of the code (if any).

I completely agree with "Scala programs shouldn't be using null".
However, your two claims for when nulls come into play in Scala are false:

Only valid for non-Scala code: Not all native Scala APIs avoid null. I personally use Spark which has a native Scala implementation which uses nulls all over the place. It's a pain, having to wrap everything in Options.
Not enough use of Java interop in Scala code: One of the biggest selling points of Scala is that it's written to work on top of the JVM. One of the reasons for this is the ecosystem created around Java and the JVM over the past 21 years. Over the past 5 years, I've yet to work on a Scala codebase that did not have to interop with tools written in and/or for Java.

Sorry if my tone was a bit harsh in that last comment. I went through and re-edited it so many times... 😅

Hi @ChrisNeveu, I'd love to know whether my contribution will be accepted or rejected...

This is a rather busy time of year. I'll respond to your points when I get a chance.

Thanks for the update @ChrisNeveu. I appreciate you taking the time to respond to this. Looking forward to your input.

I've had time now to read your arguments and I'm afraid it doesn't change my opinion.

I agree it may do that, but we have other tools, including warnings coming out of scalac which warn about the sort of use cases you're referring to. If you're worried about that enough that it may cause an issue, you can opt to use the rule as a warning and/or disable it in specific cases.

I've had many initialization order problems in the past (thanks cake pattern) but can't recall ever receiving a warning from scalac for it. Wartremover's primary concern is preserving correctness so introducing a wart that can reduce correctness is a hard "no" from me.
Regarding your second point: we use a lot of Java libraries as well but we wrap them with Scala interfaces. I do use Apache Spark at work and it's interface is… unfortunate, but we're already using a separate Wartremover config with that more amenable to Spark's particularities. I would recommend you add SomeApply as a custom wart for that usecase.
I did investigate usage in the community to see whether always using the null-coercing Option constructor was a widespread trend but it seems that people tend to favor the regular constructors. Scalaz's some function does no null-coercing nor does its Maybe.just constructor (it does provide a Maybe.fromNullable constructor for special cases but it's obviously not the default). Likewise dogs provides Option.some which doesn't handle null and recommends that as the preferred constructor in its tutorial.
There are plenty of useful warts that don't make sense in Wartremover proper but this is why we have Wart.custom (at GMG we have a number of custom warts that are of limited applicability). I hope closing this PR doesn't discourage you from using or contributing to Wartremover in the future :)

Thanks, @ChrisNeveu. I appreciate your argument and am now even more encouraged to keep contributing :)
I would love to see a new community-driven repo for wartremover-contrib, where there would be a lower bar for adding new warts, when those that see high adoption or seem canonical could be migrated into wartremover proper.

sounds good to me.. oh, and stuff like https://github.com/danielnixon/playwarts might deserve to be linked from here, too.

I like the idea of a Wartremover-Contrib project. I'll look into creating a wartremover organization which we can move the repos to.

Hi @ChrisNeveu, would love to hear how you're coming along with wartremover-contrib. Excited to start contributing to it!

@omervk The project is at https://github.com/wartremover/wartremover-contrib and I'll cut a 1.0.0 release once it has a couple more warts in it.

Wonderful, thank you!


feat!: Token Registry V4

Summary
Updated use of Token-Registry V2 to V4
Changes
updated publishTransferableRecordJob, to use V4 methods
Issues
https://github.com/TradeTrust/document-creator-website/pull/235
https://github.com/TradeTrust/document-creator-website/pull/254
https://github.com/TradeTrust/tradetrust-website/pull/606
https://github.com/Open-Attestation/open-attestation-cli/pull/228

Also can check whats happening to the CI, the install packages are failing


How to Get create Username screen once I created one?

I wanted to format css code of landing page for first time user

Hey, your question is kind of hard to understand. Can you please rephrase it so I can help you better?


Use simpler form to specify torch CPU dependency

Checklist

[x] I've given this PR a concise, self-descriptive, and meaningful title
[ ] I've linked relevant issues in the PR body
[ ] I've applied the relevant labels to this PR
[ ] I've added relevant tests for my contribution
[ ] I've updated the documentation and/or added correct docstrings
[ ] I've assigned a reviewer
[ ] I've consulted ADS's internal developer documentation to ensure my contribution is in line with any relevant design decisions

Description

Using --extra-index-url instead of --find-links means there's no need to pin a torch version -- which means we can trust ivadomed to specify the version it needs instead.
Linked issues

Fixes(?) https://github.com/ivadomed/ivadomed/issues/861#issuecomment-885957932
Related: https://github.com/spinalcordtoolbox/spinalcordtoolbox/pull/3790

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 88.735%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
961

Relevant Lines:
1083

💛  - Coveralls

I tested it and as far as I know everything works as expected. On linux, it downloads the cpu build.
Collecting torch~=1.8.1
  Using cached https://download.pytorch.org/whl/cpu/torch-1.8.1%2Bcpu-cp38-cp38-linux_x86_64.whl (169.1 MB)
Collecting torchvision~=0.9.1
  Using cached https://download.pytorch.org/whl/cpu/torchvision-0.9.1%2Bcpu-cp38-cp38-linux_x86_64.whl (13.3 MB)

IIUC, to enable GPU support, you only need to change the --extra-index-url to https://download.pytorch.org/whl/cu113? When I try it, the linux torch-gpu big boy is downloaded:
Collecting torch~=1.8.1
  Downloading torch-1.8.1-cp38-cp38-manylinux1_x86_64.whl (804.1 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 804.1/804.1 MB 1.7 MB/s eta 0:00:00
Collecting torchvision~=0.9.1
  Downloading torchvision-0.9.1-cp38-cp38-manylinux1_x86_64.whl (17.4 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 17.4/17.4 MB 9.5 MB/s eta 0:00:00

Looks like everything works fine. (Weirdly enough, this GPU build looks faster than what I was used to on bireli... maybe I'm crazy). I understand that GPU support on windows will require https://download.pytorch.org/whl/cu102 as the --extra-index-url link, is that correct? Nonetheless, I don't recall a lot of situations where windows users needed GPU support.
From a first glance, it looks like this contribution solves the torch dependency problem for downstream packages, or at least makes it way easier to manage. Thank you @kousu and @kanishk16 for figuring this out.

IIUC, to enable GPU support, you only need to change the --extra-index-url to https://download.pytorch.org/whl/cu113? When I try it, the linux torch-gpu big boy is downloaded:
I understand that GPU support on windows will require https://download.pytorch.org/whl/cu102 as the --extra-index-url link, is that correct? Nonetheless, I don't recall a lot of situations where windows users needed GPU support.

I'm going to recommend that you just remove --extra-index-url entirely to enable GPU support.
torch has make a couple quirky decisions: the GPU builds come with CUDA (unlike tensorflow, which expects the sysadmin to install CUDA systemwide), and on Linux, GPU builds are the default, while on Windows, they're not. This is my theory why:

I think they must assume if you're using Linux you're hardcore and/or rich and/or using a data center, where you can afford to waste 700MB if you don't have GPUs, but if you do have GPUs then the time spent to remember how to add --extra-index-url .... costs more than just wasting the 700MB, while on the other hand and if you're using Windows you're probably a newbie and you need to be hand-held. torch is Facebook's project, designed for Facebook Research, and their researchers are probably using Windows or macOS locally, without GPUs, but deploying on their internal data centers, which have both GPUs and very fast internet connections.

The reason cu113 is in the air is that it's a corruption of cu111 which was because romane.neuro.polymtl.ca is too new: it has compute capability 8.6 but the torch on pypi comes with CUDA 10.2. which only goes up to compute capability 7.0.  But really romane is an outlier and we shouldn't have tried to solve that in our software; I've solved that a better way: its /etc/pip.conf now commands every python env on the system to use the CUDA 11 builds:
# romane:/etc/pip.conf
[install]
extra-index-url =
  https://download.pytorch.org/whl/cu116
  https://download.pytorch.org/whl/cu115
  https://download.pytorch.org/whl/cu114
  https://download.pytorch.org/whl/cu113
  https://download.pytorch.org/whl/cu112
  https://download.pytorch.org/whl/cu111
  https://download.pytorch.org/whl/cu110

It tells them to check all the sub-repos, to make sure to be backwards and forwards compatible with as many torch versions as possible. It's unfortunate they don't just have a single https://download.pytorch.org/whl/cuda or https://download.pytorch.org/whl/cu or https://download.pytorch.org/whl/gpu repo but :shrug:
So simply removing --extra-index-url maintains the assumption that "Linux has GPU support" everywhere.
And eventually torch will standardize on CUDA 11 as the default for Linux, and we can drop the workaround.
For Windows, you can actually use the same pip.conf! Because there's CUDA 11 builds for Windows too, e.g.

But Windows sysadmins could also meaningfully choose CUDA 10:
[install]
extra-index-url =
  https://download.pytorch.org/whl/cu102
  https://download.pytorch.org/whl/cu101
  https://download.pytorch.org/whl/cu100

since the Windows pypi.org builds don't have CUDA. It would also work for Linux, it's simply redundant since these repos contain identical *linux*.whl files as pypi.org
And either situation could also do
[install]
extra-index-url =
  https://download.pytorch.org/whl/cpu

to force using the smaller CPU builds.
In any case, I think assuming 99% of people will be satisfied with the defaults, and then maybe for the rare exceptions we can help sysadmins set up /etc/pip.conf (C:\ProgramData\pip\pip.ini on Windows). We should probably put this key trick in the wiki, but not the docs: I want to get ivadomed out of the business of trying to teach people about the sprawling CUDA stack and I think you shouldn't be in it either, they just want their analyses to work.

When I try it, the linux torch-gpu big boy is downloaded:
Collecting torch~=1.8.1
  Downloading torch-1.8.1-cp38-cp38-manylinux1_x86_64.whl (804.1 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 804.1/804.1 MB 1.7 MB/s eta 0:00:00
Collecting torchvision~=0.9.1
  Downloading torchvision-0.9.1-cp38-cp38-manylinux1_x86_64.whl (17.4 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 17.4/17.4 MB 9.5 MB/s eta 0:00:00

Looks like everything works fine. (Weirdly enough, this GPU build looks faster than what I was used to on bireli... maybe I'm crazy)

Oh interesting! That's because you're not using the cu113 build at all: there's no torch-1.8.1 in https://download.pytorch.org/whl/cu113/torch. Effectively, that was the same as removing --extra-index-url.
This is instead the pypi version with CUDA 10. You should be able to confirm this with:
(ads_venv) p115628@bireli:~/axondeepseg$ python -c 'import torch; print(torch.version.cuda)'
10.2

If for some reason you wanted to try the CUDA 11 build you would actually have to use --extra-index-url https://download.pytorch.org/whl/cu111.

From a first glance, it looks like this contribution solves the torch dependency problem for downstream packages, or at least makes it way easier to manage. Thank you @kousu and @kanishk16 for figuring this out.

Wonderful! Finally we can simplify this issue away.

On bireli, launching our quick integrity test with CUDA 11.1:
real    0m16.210s
user    0m52.484s
sys     0m3.251s

With CUDA 10.2:
real    0m9.065s
user    0m6.337s
sys     0m1.478s

!!!!!!

Crazy! That suddenly makes it very clear to me why cuda11 isn't the default yet. What about romane? Is that equally slow?

On romane with CUDA 11.1
real    0m8.021s
user    0m12.308s
sys     0m2.939s

so, no it's not as slow. I'm guessing this is because bireli's gpus are older. It seems a lot of people reported slower inference time with CUDA 11 in comparison with 10.2: https://github.com/pytorch/pytorch/issues/47908
CUDA 11.1 is shipped with cudnn 8 whereas CUDA 10.2 uses an older cudnn 7. It could be related to the cudnn version and if torch.backends.cudnn.benchmark == True, which seems to be the case for ivadomed, (e.g. here) according to this issue

It could be related to the cudnn version and if torch.backends.cudnn.benchmark == True, which seems to be the case for ivadomed, (e.g. here) according to this issue

This is some pretty solid research. Good job digging those up. Let's raise a follow up with ivadomed to ask them if they could disable benchmarking by default, but that's not a blocker.
It looks like the ivadomed patch underneath is ready to go.

On bireli, launching our quick integrity test with CUDA 11.1:
real    0m16.210s
user    0m52.484s
sys     0m3.251s

With CUDA 10.2:
real    0m9.065s
user    0m6.337s
sys     0m1.478s

!!!!!! (this test performs inference on an image) I think the time spent in the NVIDIA driver is halved

@hermancollin Is it possible for you to set torch.backends.cudnn.benchmark = False and then report the inference results?

CUDA 11.1 is shipped with cudnn 8 whereas CUDA 10.2 is used from an older cudnn 7. It could be related to the cudnn version and if torch.backends.cudnn.benchmark == True, which seems to be the case for ivadomed, (e.g. here) according to this issue

As per official docs and AFAIU (after referring to the official discussion forum) it may or may not hamper the time as per the situation. Since there are mixed opinions regarding the same, it would be great if could find the best tradeoff for us.
On a side note, we've already had discussions regarding exposing such parameters to the user https://github.com/ivadomed/ivadomed/issues/1092 and this would guide us in selecting the default parameters. But, this might be on a slightly low priority.

@kanishk16 I opened an issue to discuss this https://github.com/ivadomed/ivadomed/issues/1141
I tried setting benchmark to false but wasn't able to observe any difference.

Need to update the doc wrt. https://github.com/ivadomed/ivadomed/pull/1125

I'll try to move https://github.com/ivadomed/ivadomed/pull/1125 along, so that this PR can also be moved along.

For the record, this is me moving the docs along: https://github.com/ivadomed/ivadomed/pull/1184. But it seems like maybe it's a back-burner priority for them...
So I'm going to patch the docs for you too, and you should be able to merge that even without ivadomed getting time allocated. I'll going to remove the direct links to ivadomed so that those links can't break and instead explain in loose detail what people need to know as your users. Which isn't much. The whole point of this saga has been to streamline the situatuion so people don't need to overthink the installation.

Okay I've updated your docs: https://axondeepseg--642.org.readthedocs.build/en/642/documentation.html#installation
though apparently I don't know how to embed a code block inside a .. note::. Anyone know how to do that off the top of their heads?

though apparently I don't know how to embed a code block inside a .. note::. Anyone know how to do that off the top of their heads?

Done in 6430f85
RTD: https://axondeepseg.readthedocs.io/en/ng-unpin-torch/documentation.html#install-axondeepseg
Screenshot:

I'm testing this right now locally and on bireli, seems to be working fine so far, I'll merge if all goes well.

Thanks @mathieuboudreau. I was just writing up a final commit message myself. Here's my draft so far:

ivadomed now <https://github.com/ivadomed/ivadomed/pull/1129/> specifies torch
as a standard dependency, without giving special manual instructions for it.

This means there's finally no need to pin a torch version here in axondeepseg;
previously, we had to match their version in our environment.yml because it was
a manual step in their install instructions. But now the metadata makes pip handle it.

ivadomed gave special install instructions to try to handle the complicated mess that it
hardware (i.e. CPU vs GPU vs hyper modern CUDA-11-only GPUs) compatibility.
But now they're just leaning on the 80%-20% rule of thumb: >80% of people are covered
by the default torch builds. And we know how to handle the <20% cases of people with
CUDA-11-only GPUs or Windows machines with GPUs by having them install with
'--extra-index-url = https://download.pytorch.org/whl/<hardware-specific-build>'

axondeepseg was pushing the CPU version of torch on people, assuming that most users
would not own GPUs and that in the Linux case it would be very wasteful, maybe even
make ADS uninstallable for some users. We gave our own manual instructions that
duplicated ivadomed's for how to switch to the GPU version. That process meant double
the downloads and likely mismatched versions.

Instead, follow torch's defaults, like ivadomed now does. But since the users with
Linux and CPU-only hardware is fairly common and would be wasteful, highlight
--extra-index-url as an optional *pre*step, avoiding the double-download and
versioning mistakes.

Overall:

- Windows and macOS continue to have no GPU support
- Linux always has GPU support, even if it doesn't need it; this balloons the
  default install, but anyone using torch now has this same problem and the
  consensus seems to be just to pay for bigger disks that can tolerate the waste
- The relatively common case of Linux users without GPUs have an escape
  hatch to avoid the large download
- Windows users with GPUs have a way to use them
  (`--extra-index-url https://download.pytorch.org/whl/cu102`), but we don't
  document nor support this
- Linux/Windows users with super new CUDA-11-only GPUs also have a
  way to use them, which we we also don't document nor support directly

And no one gets distracted with too many questions.

Fixes https://github.com/ivadomed/ivadomed/issues/861#issuecomment-885957932

Related: https://github.com/spinalcordtoolbox/spinalcordtoolbox/pull/3790

In passing, remove the redundant parts of the `conda env create` line.

Co-authored-by: Nick Guenther<EMAIL_ADDRESS>Co-authored-by: Mathieu Boudreau, PhD<EMAIL_ADDRESS>Co-authored-by: Armand<EMAIL_ADDRESS>


[FEATURE] Processor Validations

TODO

[x] Ensure a user can validate by implementing validate
[ ] Ensure an error response is compliant with JSON-API
[ ] Better test coverage

ref #766

@lgebhardt Would like to get some feedback on this before I get going :)

Reviewing this I'm concerned you are missing some key details of how the system was designed to work. Not that that should surprise me as it's got a lot of layers, and isn't as clear as I'd like.
So could we step back and go over the goals you have for the validate method?

@lgebhardt Yep, we all due honesty I found the project a bit hefty to work with because:

TheDSL goes too far away from conventions, for example: the error objects don't inherit from StandardError or something similar, they are just POROs

Test scenarios manipulate globals - $test_user - which can get out of hand really quick

Some declared primitives here are already a part of Rails and are just duplicated, for example the lib/jsonapi/error_codes.rb vs http://apidock.com/rails/ActionController/StatusCodes

I've decided not to continue developing this PR but feel free to take over 😄
Things like managing errors will be something we'll manage through filters as previously suggested - thanks for the help anyways

Understood. I'm still interested in what your goals are for the validate method on the processor. So far I've been able to use the callbacks to handle any pre or post processing of operation data, including returning errors. The one limitation I've run into has been that it's hard to return a full set of errors if the request has multiple, with the exception of model validations where we are able to covert each validation error into a JSON API error.
To address your points:
The Errors are derived from RuntimeError which is derived from StandardError.
I agree the $test_user global feels hackish. I'm certainly open to better options.
error_codes.rb does share some overlap with the standard StatusCodes, but that's mostly incidental. JSON API provides for having a code in the error objects. The error_codes are used to provide a standard set of codes for errors which can either be presented as numeric codes or text. JSON API also has a status in the error objects. This is where the http://apidock.com/rails/ActionController/StatusCodes are used.

@lgebhardt the goal of validate is to give users an interface to populate a custom errors document, this could be handled at a model level or in a callback that takes over if need be 😄

Model validation errors are already supported. If you raise single errors in the existing callbacks they will result in an ErrorsOperationResult which I think is analogous to an errors document.
I don't see why you couldn't create new Error similar to ValidationErrors which would wrap multiple custom error types. You could do all your checks in the before_operation callback, collect all the custom errors and raise them at the end in your new Error. It would be very little work and should give you all of what I think you are trying to accomplish.


Add input date validation

Added date validation on user input - https://github.com/raghothams/grok-ergodicity/commit/0920aa99261d5ef19d34269b7b20086c1863351f


Using realtime features

Hi, me again! Just been reading through things, and I'd love to help/use this library but I have a few initial questions. Mostly, I only need the realtime portion of this. I wonder if it would be worth exporting more types from bevy_realtime, to facilitate folks who just need to react to Postgres changes? Alternatively, do you have a quick example (even rough) of using bevy_supabase to listen to table changes? I see it adds a RealtimePlugin, but I'm thinking maybe the API to talk to that might not be "cooked" yet?
Don't worry, not expecting miracles or lots of free work! But if I can maybe get a start, I could kick in with PRs as I work on my Bevy stuff :sunglasses:

In the meantime I'm just gonna straight rip the bevy-realtime crate and see if I can understand it.

Interesting. Yeah, so trying bevy-realtime, it seems to block on https://github.com/bytemunch/bevy-supabase/blob/main/crates/bevy-realtime/src/lib.rs#L59 and never either return a channel or an error. I imagine this is the sync/async struggle again, but sadly I wasn't up to the challenge of debugging it! Hopefully I can help out more once I'm a bit more familiar :pray:

Yeah you're right that none of it's cooked yet! 😅 I'm working on making an
authed todo app in bevy that should hit all code paths, I'm just a bit busy
and slow at the moment 😬 hope to be free on the back half of next week,
will push on 🤙
PRs welcome once you get a handle on the codebase ✌
On Sat, 11 May 2024, 06:58 Rich Churcher, @.***> wrote:

Interesting. Yeah, so trying bevy-realtime, it seems to block on
https://github.com/bytemunch/bevy-supabase/blob/main/crates/bevy-realtime/src/lib.rs#L59
and never either return a channel or an error. I imagine this is the
sync/async struggle again, but sadly I wasn't up to the challenge of
debugging it! Hopefully I can help out more once I'm a bit more familiar 🙏
—
Reply to this email directly, view it on GitHub
https://github.com/bytemunch/bevy-supabase/issues/1#issuecomment-2105580919,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKMCYI3AUNORTIEKZPKOWW3ZBWXR3AVCNFSM6AAAAABHONVOOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBVGU4DAOJRHE
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I completely get the time struggle! I'll see if I can divine anything further with my scary mixed-up codebase. I was interested to see that including the BuildChannel component was enough to completely stop the game window from rendering... just a black screen. Don't know how I managed that one 😅

I've been tinkering and I think I've cracked the issue, a tokio version mismatch between bevy-realtime and realtime-rs. I'd expect that there would be some feedback from the compiler but apparently it just silently fails. Doing a clean recompile and testing but think that it'll be back to working again in next commit

Awesome! I'll check this today hopefully.

Heh. Yeah, sadly after updating my local versions, I'm still getting a black screen lockup. This may entirely be user error, I note with haste! However the tokio dependency does seem to be a bit of a stumbling block, so if it's OK with you I'm curious what an implementation in "native Bevy" might look like, will investigate.

Closing (nokio branch works).


Setup component library in Figma

Definition of done

[x] A figure file Exists that contains the Material UI components
[x] These components can be used in other Figma project files

we had a bit by carry :D

@Carrie22022 @theblockstalk  new task: Upgrade to a paid account, move it into the tonomy domain


Configurable client

Description
With a recent release adding mempool.space support (#347), a few issues came to light, which this PR seeks to address.
Problems
Rate Limiting in mempool.space
The biggest one noticed in #364 was that recent rate limiting implemented on mempool.space's main production endpoint caused significant performance degradation. Throttling was already an issue with blockstream for which we added a delay to avoid hitting the rate limit, but this may not be enough.
Hard to change client
Unfortunately the way to change the client had to come from unchained-bitcoin, which is really inconvenient and probably not the right long term place for this.
Clumsy API
Every api call had to pass in the network and client info even though once the wallet is setup, this doesn't change. Would be nice to just get this from the store and be done.
Mempool not a perfect drop-in replacement
One of the api calls (getFeeEstimates) was not quite a drop-in b/w mempool and blockstream. So this might've been broken as well
Hard to make changes
If there are any changes in the future (immediate example: mempool is going to have a websocket option for using as a wallet backend), it's not easy to update the client without backwards incompatible changes.
Solution

This PR first moves all the client relevant code into their own module (c90211ddee4de7fce9e7bcdcea5628cd31bccabe).
Then it introduces a new BlockchainClient class (d3201c2), which once initialized with the connection details shares an api no matter what client you're connecting with
This class supports bitcoind, mempool, or blockstream. This moves the connection info from unchained-bitcoin. Longer term, I think this should exist in its own package to be maintained separately. An external package shouldn't dictate what the public client endpoint is, but it makes sense to have a unified (and well tested) package for communicating with the blockchain. The consumer (in this case the caravan coordinator) can decide which it wants to use when initialized and just go from there.
the UI is still very tightly coupled with redux, so this PR adds some code f591a0e to the store and actions to set the client and get the client (based on other client settings in the store) for components to use as needed.
TypeScript and tests. TS isn't as useful as it could be without many TS consumers but it's a start.
The class also has built-in, configurable support for throttling if necessary to avoid rate limiting in a way that should be easy to turn on and off
the update in clientActions shows how easy it should be to support multiple clients. It's one line now to change the default public b/w blockstream and mempool and eventually we should easily be able to support either and leave it up to the user.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Does this PR fix an open issue?

[x] Yes
[ ] No
Fixes #364

Is there an ETA of this getting merged into main?

Blockstream API broadcast accepts RAW not JSON. Am experiencing a CORS policy failure on preflight as well as the broadcast itself. Copying the HEX and posting it via CURL works successfully.
public async broadcastTransaction(rawTx: string): Promise<any> {
    try {
      if (this.type === ClientType.PRIVATE) {
        return bitcoindSendRawTransaction({
          hex: rawTx,
          ...this.bitcoindParams,
        });
      }
      return await this.Post(`/tx`, { tx: rawTx });
    } catch (error) {
      throw new Error(`Failed to broadcast transaction: ${error.message}`);
    }
  }

Added in the caravan monorepo now live as of d1d169


Golint errors

$ golint ./...
encoder.go:29:1: package comment should be of the form "Package ucl ..."
encoder.go:29:1: package comment should not have leading space
encoder.go:43:2: don't use underscores in Go names; const parent_map should be parentMap
encoder.go:44:2: don't use underscores in Go names; const parent_array should be parentArray
encoder.go:45:2: don't use underscores in Go names; const parent_anon should be parentAnon
parser.go:36:1: comment on exported const KeyOrder should be of the form "KeyOrder ..."
parser.go:40:1: comment on exported var UclExportKeyOrder should be of the form "UclExportKeyOrder ..."
parser.go:41:23: should omit type bool from declaration of var UclExportKeyOrder; it will be inferred from the right-hand side
parser.go:43:5: exported var Ucldebug should have comment or be unexported
parser.go:43:14: should omit type bool from declaration of var Ucldebug; it will be inferred from the right-hand side
parser.go:51:6: exported type Parser should have comment or be unexported
parser.go:63:1: exported function NewParser should have comment or be unexported
parser.go:221:10: if block ends with a return statement, so drop this else and outdent its block
parser.go:227:12: if block ends with a return statement, so drop this else and outdent its block
parser.go:265:3: don't use underscores in Go names; var korder_intf should be korderIntf
parser.go:375:1: exported method Parser.Ucl should have comment or be unexported
scanner.go:1:1: package comment should be of the form "Package ucl ..."
scanner.go:1:1: package comment should not have leading space
scanner.go:41:2: exported const WHITESPACE should have comment (or a comment on this block) or be unexported
scanner.go:62:2: don't use ALL_CAPS in Go names; use CamelCase
scanner.go:63:2: comment on exported const MAYBE_MLSTRING should be of the form "MAYBE_MLSTRING ..."
scanner.go:64:2: don't use ALL_CAPS in Go names; use CamelCase
scanner.go:65:2: don't use ALL_CAPS in Go names; use CamelCase
scanner.go:66:2: don't use ALL_CAPS in Go names; use CamelCase
scanner.go:67:2: don't use ALL_CAPS in Go names; use CamelCase
scanner.go:71:2: don't use underscores in Go names; const skip_white should be skipWhite
scanner.go:72:2: don't use underscores in Go names; const skip_sep should be skipSep
scanner.go:82:5: error var UnexpectedEOF should have name of the form ErrFoo
scanner.go:82:5: exported var UnexpectedEOF should have comment or be unexported
scanner.go:100:2: don't use underscores in Go names; struct field mlstring_tag should be mlstringTag
scanner.go:204:12: if block ends with a return statement, so drop this else and outdent its block
scanner.go:333:12: if block ends with a return statement, so drop this else and outdent its block
scanner.go:571:11: if block ends with a return statement, so drop this else and outdent its block
scanner.go:770:11: if block ends with a return statement, so drop this else and outdent its block
scanner.go:790:11: if block ends with a return statement, so drop this else and outdent its block

golint is officially deprecated.


feature parity with CanvasScroll

Resolves #2. Lays some groundwork for #1 if that is desired in the future.
A couple tweaks to the behavior to enable horizontal panning via mouse wheel, which would let this merge completely with the CanvasScroll module I was developing.

Formatted JS with Prettier (sorry if that's not the formatter you use, let me know what would work better)
Made Shift + Scroll pan horizontally in touchpad mode
Laid groundwork for allowing users to set their own keys desired
Changed default rotation key to Alt in touchpad mode, which now behaves how Ctrl behaves in non-touchpad mode

Turns out that event.ctrlKey is how OSX handles pinch zooming

Tested on Windows 10 Foundry Client (Mouse + Keyboard) and OSX Chrome (Macbook Pro 2018 Touchpad, Mouse + Keyboard)

While I think that it’s cool to have the option to assign our own keybindings, I don’t think we should change the default behavior so drastically. It was a very conscious decision to have keep shift+scroll for rotating and shift+ctrl+scroll for fine rotation, as this was the closest compromise with the default keybindings. Alt+scroll for zooming doesn’t work as good, as that would eliminate zooming by pinching on macOS (as you have noted).
All this can be achieved by allowing custom keybindings, and should be implemented without changing the defaults.

I'm alright with changing some keybindings, but it would be best if it was a setting. Either way, all possible actions should still be possible (panning, zooming, rotating at 45/15 degrees).
Another reason to allow keybindings without Alt is that Alt is used in Foundry for another purpose - to highlight tokens. If the user wants to highlight tokens while panning/pinching, I don't want this module to interfere with that.

Another reason to allow keybindings without Alt is that Alt is used in Foundry for another purpose - to highlight tokens. If the user wants to highlight tokens while panning/pinching, I don't want this module to interfere with that.

For me, panning or zooming with highlighted tokens comes with a considerable drop in performance (MacBook Pro 2020).

@akrigline After thinking about why you chose these keybindings, I thought that we may be using different use cases as the baseline. You keybindings make sense for mouse wheel users and users with touchpad that don’t support multidirectional gestures (i.e. users who have only access to deltaY), while @itamarcu and I focused on multidirectional touchpads. Is that right?
One solution could be to have three modes: Default Foundry, Mouse Wheel/Simple TouchPad Panning (basically the Roll20 mode), and Multidirectional TouchPad Panning (the way Zoom/Pan Options works now). That way, it’s easy for the users to determine what they need depending on their hardware, and it optimizes the keybindings to that use case.

I think there's some confusion about what keys do what in this PR. I'll try to explain better.
Without "Touchpad" mode
This module changes no keybindings from foundry default.
In "Touchpad" mode
Ctrl is Zoom. This keeps OSX pinch to zoom working and is a common enough pattern on windows that I believe it to be an OK default.
Alt does what Ctrl does without touchpad mode, which is to precisely rotate selected placeables. Alt + Shift rotates the selected placeable in large increments. This operation is expected to be used less often and by less users, so I believe that the overlap with "highlight all tokens" is acceptable, but we could shim an override (configurable?) to that behavior if we must.

After thinking about why you chose these key bindings, I thought that we may be using different use cases as the baseline.
@mrkwnzl I think you are correct. I created CanvasPan with the intention of allowing both scroll wheels and trackpads to use their hardware to navigate the canvas in foundry. After that was out and started, I was shown your guys' work and rather than try to merge your changes into my modue I figured I'd contribute to this and deprecate mine.

I don't really think that we need multiple modes but it is an option.

@akrigline Thanks for the clarification!
@itamarcu Maybe we should integrate the mouse rotation idea of yours into this after all 😄
But, let’s see what buttons we need (I’m a bit thinking out loud here, I hope that’s okay):

Shift + Scroll for horizontal canvas panning.
Ctrl + Scroll for zooming.

I think these make sense.
Then we have a conflict with rotating. I’m not sold on using Alt + Scroll for that, as we just shift the problem: We need Alt for highlighting tokens (I’d like not to dismiss this feature so easily–I use it regularly), and both highlighting and rotating at the same time sounds too confusing to me. But how about this:

Shift + Alt + Scroll for rotating in 45°
Crtl + Alt + Scroll for rotating in 15°

This way, Alt is literally that: It alternates between the two use cases of rotating tokens and canvas navigation, but keeps the general buttons close to the Foundry default. And we can make it a choice (i.e., flip the possibilities from above): Holding Alt is either for controlling the rotation (that would be the default for the module and work like outlined above), or for controlling the canvas navigation (then the Foundry default would work, and Shift/Ctrl + Alt + Scroll pans horizontally/zooms.
What do you think about that? I think it’s kind of elegant. It keeps close to the Foundry defaults and should be easily grasped by users.

@mrkwnzl - I think it's kind of inelegant, but it does solve the problem of someone holding Alt to highlight tokens while panning the canvas, so I think I'll go with that.
Either way, I don't expect people to rotate tokens with a touchpad too often, and I do like the idea of mouse-drag-to-direction rotation as a separate module (as we discussed on Discord a bit) which I think should appeal to everyone.
I'm going to merge these changes and add some additional changes on top of them.

@mrkwnzl @itamarcu Alt still highlights tokens in this change. It just also allows rotation since Ctrl is taken.

I'd encourage both of you to try this setup and then lets discuss further in #4


fixing environment setting to work with Ansible 2

bare vars aren't supported with Ansible 2 any longer this just changes how the postgresql_env is referenced.

I also commented out the Ubuntu-14.04 settings as it wasn't allowing me to set the postgresql_locale and postgresql_encoding otherwise


Initialize-ADSyncDomainJoinedComputerSync command used appears to fail if tenant has dishes '-'

When running Initialize-ADSyncDomainJoinedComputerSync command used in Step 1, it appears if you have any dashes in your tenant name it will fail with the message: Tenant (FQDN with Dashes removed here) not found.This may happen if there are no active subscriptions for the tenant. Check with your subscription administrator.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 72cdc251-618a-e84e-f40d-960b0ac69f99
Version Independent ID: 8cbaba3c-e883-2c71-28fb-f88db3fcaf7d
Content: How to configure hybrid Azure Active Directory joined devices
Content Source: articles/active-directory/device-management-hybrid-azuread-joined-devices-setup.md
Service: active-directory
GitHub Login: @MarkusVi
Microsoft Alias: markvi

@DJ-1701 Thanks for your feedback! We will investigate and update as appropriate.

Ok, bit of an odd one... ran it with another account and it worked correctly, no issue. The difference was, when I had the problem, I was using an administrator account with the onmicrosoft.com domain name, and the one that worked was an administrator account with our organisation's own FQDN.

@DJ-1701 It is good that you are unblocked. The documentation also states that "Enterprise admin credential is required to run this cmdlet"  and you need to open an elevated PowerShell prompt.


php-memcache-8.0.catalina.bottle.tar.gz bottle missing

==> Upgrading kabel/pecl/php-memcache <IP_ADDRESS> -> 8.0
==> Downloading https://kabel.jfrog.io/artifactory/bottles-pecl/php-memcache-8.0.catalina.bottle.tar.gz
#=#=-#  #
curl: (22) The requested URL returned error: 404 Not Found
Error: Failed to download resource "php-memcache"
Download failed: https://kabel.jfrog.io/artifactory/bottles-pecl/php-memcache-8.0.catalina.bottle.tar.gz

I guess it got lost in the shuffle off of bintray. Fixed at d6fe6a364c22c740e97cdb75ee957ce7ee71a45f

Can you tell why you sitched off bintray? why you chose jfrog? and how much does it cost for you to host them there?
I'm asking as I need to find a place to distribute .rpm/.deb/.apk package, and haven't found a suitable option yet.

Sure. Bintray is shutting down. I use their free, open-source tier. My bottles don't generate enough traffic to put me at risk for seeking a paid tier. The migration path to jfrog (Artifactory, also on free tier) was the easiest, so that's what I went with. Although an internet search will turn up dozens of free/cheap CDN options for all kinds of artifact styles.
I'm very pleased with jfrog's feature set in Artifactory, including their free tier of log analytics that help me better track bottle use.

I was confused with jfrog registration where they asked which cloud provider I am using.

Yeah, their on-boarding form could use some love. Cloud provider just means were they'll host your container. Interesting that they give you that option.
I keep finding new things to love about my analytics:

Oh, yeah, their registration still hasn't heard of UTF-8 or something. There is a world outside the US, really using wider charset than US-ASCII.

😲 my emoji password doesn't work?!

Now I got hit by an unexpected surprise from jfrog, my account was closed due to 'No activity'
I can not find any 'activity' clause in their pricing selection at all, in none of the choices:

https://jfrog.com/pricing/

and when I asked their assistant bot for additional help, when I got the first warning email, I was never reached back, and by now the account is closed and data inaccessible.


Unfolddentatetemplate patch

should be a quick fix for https://github.com/khanlab/hippunfold/issues/202

You may have to walk me through this first. Also how does this relate to #201 ? (does it replace that PR?)

The Matlab code finds the corner vertices and moves them to the outer bounds of the surface (ensuring that the corner vertices make a rectangle instead of a trapezoid). I accidentally made this branch off of #201 so yes it also includes that change!
Can go over it briefly in our weekly meeting too.

Re Friday meeting: instead of moving the corner vertices to make a rectangle, we could add another vertex there (changing the number of den-2mm_label-dentate vertices). Personally I don't think its worth it to change, but I wanted to make a note of it here so we don't forget

Yeah I agree now, isn't worth changing the surface to add a vertex as would break compatibility, and it's mostly for esthetic purposes (interpolation shouldn't be affected much)


Remove extraneous folders created for uploaded models

Upload unzips a file into a folder of the same name; if that zipfile also includes a folder structure, you can end up with another folder inside that one with the same name, and all the content inside there. We should collapse these so we don't produce extra weird tags.

Hi, I'm interested in taking a stab at this issue. Is there a way to reproduce the issue?

I think, if you zip a couple of STLs up together, it should work correctly and create a folder with the name of the archive with those STLs inside it. But, if you have those two STLs in a folder and compress THAT, you'll get a folder with the name of the archive, then the folder inside the zip file, then the STLs. The outermost folder won't be picked up as a model, and will be left lying around empty when you organize the model inside it. Does that make sense? I can try to make some sample files if you want.

Thanks, that makes sense! I'll try it out and see if I can make any progress.