Config file management

(moderated summary by WG)
Context
Plan of Action
In-ecosystem resources

Common directories

app-dirs-rs
app-dirs2
directories

Read/write config

configure
config
twelf

keyring for storing passwords

External inspiration

cosmiconfig

Challenges

Cross platform paths in config files.  See also #10
Integrating information from environment, command line arguments, defaults, and cascading config files
Every existing applications is probably littered with special cases, migration schemes and special rules how settings are handled. I'm not sure it is possible to encode all this into an API without making it extremely hard to use.
Good error messages, see https://github.com/serde-rs/serde/issues/1184

@spacekookie's original poist
In the first meeting, we discussed the task of file management on different platforms (particularly configurations) and how it can be made better.
@Eijebong summarised it like this

If I need a config file, I don't want to know that it should be ${XDG_CONFIG:${XDG_HOME}/.config:/home/${user}/.config on linux, %AppDir%/App/ on windows and something else on osx [...]

There is a crate for "determing system configuration" (app-dirs-rs) but it seems unmaintained and not up to date

The configure crate by @withoutboats abstract about configuration in general (as the name suggests), but doesn't seem to have an adapter for configuration files right now (except for Cargo.toml, but that's not the use case we have in mind I guess).

I think it'd good to lay out some requirements for a crate(s) that would fill this gap:

Accepts a file name to either load/save
Abstracts away platform specific paths (i.e. as the application developer I only want to say, "myapp.conf" and have the crate handle where and how "myapp.conf" gets loaded/saved

I'd be OK with having multiple sub crates for various platforms, and then a "parent" crate that allows abstracting over the platform where all I do is specify a file name I want to load/save.

Bonus if the crate can allow me to search custom directories, or tweak the order (on platforms where applicable).

but doesn't seem to have an adapter for configuration files right now (except for Cargo.toml, but that's not the use case we have in mind I guess).

Nope, the configure crate's default "source" is definitely designed for use cases where the person configuring the application is also the author - such as network services. However, the intent is for libraries to use configure, so that the application author can have total control over the source of configuration.
A configuration source that integrates with configure and is designed for CLIs would be a great addition, and possibly one I'd be interested in upstreaming into configure proper.

I'm thinking this issue might be part of a bigger topic.

How do we store user-created configuration files cross-platform? (So far this issue has only touched on this one specifically. E.g. Linux $HOME/.config)
Where do we store temporary files cross-platform? (Does not need to persist between boots, e.g. Linux /tmp.).
How do we store essential user data files cross-platform? (Stuff like login tokens, usually generated by applications. E.g. $HOME/.local on Linux.)
How do we store non-essential data files cross-platform? (Needs to persist between boots, e.g. Linux $HOME/.cache.)

It's probably uncommon for a single application to use all of these, but one or more should be common enough. It feels like these questions are part of the same problem; perhaps it might be useful to consider all of these questions as part of this discussion?

For the question of temporary files there is already a crate which seems to do its job quite nicely (though I've only used it in limited scenarios so far, maybe it can be improved!)
As for the rest…I think it would be pretty cool if we could create (or find and improve existing) crates that mirror the same behaviour for other configuration, essential and non-essential data files as well.
It should be as simple as saying ConfigDir::new("my_app_name") and being able to write and read configurations from it.

Hi, @soc! The Rust CLI working group is talking about cross-platform configuration file management and your directories crate has come up. Looking at your Github profile, I see you have a Java directories package as well, so you seem have some expertise in this area. Wanna chime in here? :)

@killercup Sure, how can I help?

@soc awesome! We were currently doing some research about the status quo of crates that are useful when writing CLI tools, work cross-platform and are maintained. For example, we want to come up with a good story around how to easily configure a CLI tool—with config files, env vars, and CLI flags. This issue is focussing on the handling of config files. @kbknapp already listed some good requirements in https://github.com/rust-lang-nursery/cli-wg/issues/7#issuecomment-367085114.
Do you think directories is a good foundation here? What are your plans for it? Can we help you get it to 1.0? :)
(@spacekookie and @yoshuawuyts probably have more to say!)

For example, we want to come up with a good story around how to easily configure a CLI tool—with config files, env vars, and CLI flags.

directories is intentionally focused solely on dealing with operating system defaults.
The reasoning for this is not because I believe that other venues for configuration are not important, but to provide the most minimal, stable API I can get away with.
For instance when dealing with CLI flags, the first issue you have is that of style (-h and --help vs. -help etc.) There is potentially a lot of complexity involved when trying to provide an CLI interface that makes everyone happy.
I do think that the library is a good foundation for dealing with the operating system standards part of your goals.
I believe that dealing with CLI flags should probably be done in a separate library, or in a way more specific to the individual application's needs, because dealing with CLI flags is very application-specific.
In the end individual applications already need to have some custom code anyway to deal with migrating from storing their data directly in $HOME to following the platform standards. Dealing with CLI flags will probably be the same.
That's why directories does not get involved with creating directories itself, or checking for their existence etc. ... directories only tells developers which directories they should be using, because I know of the complexities involved of making (legacy) applications actually use them without breaking things for existing users.

What are your plans for it? Can we help you get it to 1.0? :)

My plan is to declare it as stable as fast as possible. I think the main blockers are

having more people use and test it, to make sure it works
a thorough review of the decisions made concerning the various paths chosen
a review of the Windows-specific code

I have created tickets for the remaining issues I mentioned: https://github.com/soc/directories-rs/issues/1

A more general note: There is a vast difference between selecting and standardizing on crates that provide certain functionality (like CLI parsing, config file parsing) and having one standardized way of handling application configuration:
With the former you probably get crates that do almost everything and allow configuration of almost everything.
With the latter, you want to be highly selective and make actual choices how things can be specified, and not allow a free for all in terms of configuration.

As you've noticed, I've opened some issues at directories-rs. I'd hold off on releasing a 1.0 before there are some consumers of the crate.

There is a vast difference between selecting and standardizing on crates that provide certain functionality (like CLI parsing, config file parsing) and having one standardized way of handling application configuration

Absolutely. We already have some great libraries for CLI args, and I'd love to have an equally as good story for dealing with config files. That is not one crate – it's several build on top of and complementing each other :)
(We'll hopefully see more concrete proposals for this in #6!)

I think the focus should be less on a config file format and more on an API to get to those files. As a developer I might still want to be able to chose a format, say json or toml or ini via whatever serde backend exists to read/ write my configuration files. But I don't want to have to worry about where to put it.
Not sure why you brought up CLI parsing. Although thinking about it now, I'm not sure how clap.rs handles windows arguments :sweat_smile:

Not sure why you brought up CLI parsing.

I brought it up, sorry :)
So, I've been thinking about what an all-around config solution might look like. We should not implement such a thing right now, but discuss what needs to happen to get there!

Here's a small proposal that integration ideas from clap (v3, this is future!) and configure to get the discussion going:
#[derive(Debug, Deserialize, Clap, Configure)]
#[config(prefix = "diesel")]
struct Args {
    #[clap(short = "q", long = "quiet")]
    quiet: bool,
    #[clap(long = "database-url")]
    database_url: bool,
    #[clap(subcommands)]
    command: DieselCliCommand, // an enum defining subcommands with their own fields and attributes
}

fn main() {
    let args = Args::configure()
        .read_from(configure::adaptors::config_file::toml("diesel_cli.toml")) // Invokes serde
        .read_from(configure::adaptors::env_file()) //  dotenv
        .read_from(configure::adaptors::env()) // std::env
        .read_from(configure::adaptors::clap_auto_init()); // Clap incl. early exit on `-h` and stuff like that
}

You can then:

pass --database-url=something.sqlite
execute the program with env DIESEL_DATABASE_URL=something.sqlite
Have a .env file with DIESEL_DATABASE_URL=something.sqlite
Have a ~/.config/diesel_cli.toml file

Is that approximately the direction in which you want to go? What needs to happen to get there?

I think the CLI/conf/env story should be in another issue.

Sure, that was just for inspiration and to set some context. (If you have other use cases/ideas, please tell us :))

I have a couple of request in the structopt issues about that (no ideas, but persons wanting something like https://github.com/rust-lang-nursery/cli-wg/issues/7#issuecomment-367673115)

Like @spacekookie said, I think it should focus on abstracting over platform specific issues and not on the format, or providing "key->value" style API.
As the application writer, I want to just specify a file name, and let this crate handle where to store it.
Then later on  someone could write a generic crate to abstract over this configure crate, using something like serde to give a key->value style API.
Here's how I see the crate structure playing out (note, the crate names are just generic and not referring to anything existing right now).

At a former employer, I wrote a config file management library (in Python) that turned out to be popular with my fellow developers (because it was easy to add to an existing project) and with our operations staff (because all our tools worked the same way, and the configuration was flexible enough for most of our use-cases). It worked like this:

an application would include a configuration file containing all the generic defaults, in the Python ConfigParser format (basically, an INI file)
the application calls into the library, passing the application name and the defaults file
the library reads the defaults
the library reads /etc/xdg/$appname/config.cfg (the standard XDG system-wide config directory, if it exists) and overlays those settings on top of the defaults
the library reads ~/.config/$appname/config.cfg (the standard XDG per-user config directory, if it exists` and overlays those settings on top of the defaults
For each section and key in the combined configuration, the library would build a string like $appname_$section_$key and upper-case it. If an environment variable with that name existed, its value would replace the value loaded from the config files
the library returns the fully-populated configuration data to the application

Pros:

The application only needs to call a single function.
The defaults file can contain all the possible config settings, example values and even documentation for them

maybe not the best possible location for such things, but still better than "scattered across the application in each bit of code that reads a config variable"

System-wide configuration is useful for provisioning tools like Ansible/Puppet/Chef/etc. that deploy the tool to automatically configure it to work on that host (for example, setting a default HTTP proxy, or picking a geographically close rendezvous server)
Per-user configuration means users can set things up the way they like them
Environment variable configuration means one tool can launch another tool and force some configuration option it needs (like output format, or log file name)
At each stage, you can override some defaults without replacing all of them

for example, you can use Ansible/Puppet/Chef/etc. to change the "default HTTP proxy" in the system-wide config without worrying about users who have created their own config missing out

Because the INI format is limited, overlaying configuration files is simple, with predictable results

Cons:

It can be difficult to fit an application's configuration needs into the limited vocabulary of INI files
With no configuration schema, the application has to do all the deserialization/validation work itself
If a config section foo has key bar_baz, and section foo_bar has key baz, both will be mapped to the environment variable $appname_FOO_BAR_BAZ and there isn't really any way around that.
There's no good way to extend this to CLI parsing, not least because it would be impossible to generate decent --help output from the limited information we have

If I were to attempt something similar in Rust:

I'd try to find a way to build it around a configuration schema object (following the model of serde and structopt) instead of tossing around raw config files
I'd probably leave the environment-variable config the same; it's clunky but we didn't need it very often, so it wasn't a problem in practice
I'd absolutely 100% require the ability to overlay config files for different sources, though—I don't know how that would work exactly with richer data formats than INI, but I'd have to find a way

I think the focus should be less on a config file format and more on an API to get to those files.

One reason to consider a standard config file format, or at least a standard config data model: on Windows, perhaps the standard configuration source could/should be the Registry, rather than the filesystem?

After some research on that, it seems that most developers recommend and prefer files over the registry:

https://softwareengineering.stackexchange.com/questions/144238/ini-files-or-registry-or-personal-files
https://blog.codinghorror.com/was-the-windows-registry-a-good-idea/

Since this thread is about the location of config files rather than their contents this may be a bit off topic, but here goes anyway:
Similar to how structopt works, I'd love to do
#[derive(Structconfig)]
pub struct Config {
    timeout: u8
    #[structconfig(name="retries", default=3)]
    no_of_retries: u8,
    files: Vec<PathBuf>,
}

and have all the config stuff taken care of for me!

@Screwtapello
How did your code deal with first run, if there wasn't a config file? Did it assume you wanted to use the defaults, or did it exit and prompt you to create a config file? (or did it walk you through creating the config file interactively?)

@derekdreery
At first run, it would use the defaults. For the various tools we created, every config option always had a sensible out-of-the-box default. Things the program absolutely could not know without asking would generally be command-line arguments, not config options.
It's a big world, and I'm sure there's some potential config options that cannot possibly have a sensible default, but I can't think of one right now. If anyone has an example, I'd love to hear it.

Another aspect of config management to consider is passwords.  Looks like there is a keyring crate that could use some polish and advertising.

Hey everyone. I'm the current dev lead of conda, which is a cross-platform, system-level package manager.  Currently written in python--but we're in the initial stages of considering transitioning key pieces to rust.
Just wanted to add to this discussion how we do configuration, because it's been powerful and has worked out very well.  It's also very similar to what @Screwtapello described.
For each invocation of our executable, we build up a configuration context object from four sources of configuration information:

hard-coded default values
(potentially multiple) configuration files, including support for files in ".d" directories
environment variables
command line flags

These are linearized in a way that the configuration sources conceptually closest to the process invocation take precedence.  That is, if a configuration parameter is provided as a CLI flag, but also provided in a configuration file, the CLI-provided value would win.  I guess the insight here is that most CLI applications deal with at least one configuration file, environment variables, and CLI flags anyway, and we've just realized that they all represent basically the same type of information, and can be generalized and unified.
One capability that was especially important for us to add was the ability for sysadmins to lock down configuration for the entire system in "lower-level" read-only files.  As we merge the sources of configuration information, we provide a flag sort of like the css !important that lets the lower-level value be the final value.
I don't want to go into too much detail here.  There's a blog post with more details, including how we deal with merging sequence and map-type configuration parameters.  I did want to point all this out though as support for the usefulness of what @Screwtapello described.

As we merge the sources of configuration information, we provide a flag sort of like the css !important that lets the lower-level value be the final value.

An alternative model that achieves the same goal is to have separate "config" and "override" files:

system-wide config

per-user config

environment variables and command-line flags

per-user overrides

system-wide overrides

The advantage over an !important flag is that you don't need special syntax in your config-file format (and therefore serde, etc.) while the disadvantage is that you have nearly twice as many config locations to document, and for users to check when diagnosing surprising behaviour.

the disadvantage is that you have nearly twice as many config locations to document, and for users to check when diagnosing surprising behaviour

@Screwtapello you could mitigate this by being able to generate something like the following
# Configs - some config option
 1. There was no value at system-wide level. *value = default*
 2. Found value *newvalue* at user level *value = newvalue*
 3. There was no value at env/cli level *value = newvalue*
 4. There was no value at user override level *value = newvalue*
 5. Found value *newvalue2* at system override level *value = newvalue2*
 6. Final value for *config option* is *newvalue2*

the disadvantage is that you have nearly twice as many config locations to document, and for users to check when diagnosing surprising behaviour

@Screwtapello you could mitigate this by being able to generate something like the following
# Configs - some config option
 1. There was no value at system-wide level. *value = default*
 2. Found value *newvalue* at user level *value = newvalue*
 3. There was no value at env/cli level *value = newvalue*
 4. There was no value at user override level *value = newvalue*
 5. Found value *newvalue2* at system override level *value = newvalue2*
 6. Final value for *config option* is *newvalue2*

One option would be to have an API like
Config::from(system_overrides, commandline, environment, config_file, legacy_config_file, system)

Where people describe the order of settings they want to have and the library resolves settings in that order until a value is found.
I think an additional bit that's important to get right is to track the origin of each setting, so that people don't end up with some_setting = "value", but some_setting = ("value", source) I think this would make it way more transparent to understand and debug where settings come from.

I believe having some hard-coded, common-sense lookup scheme would be nice, but I fear that many applications would not fit well into it.

Do you have particular examples of applications that would not fit well? This lookup scheme is a superset of the lookup schemes of POSIX-tradition applications I can think of offhand, and resembles what I know of other platforms (macOS has system-wide /Library versus per-user ~/Library, Windows has HKEY_LOCAL_MACHINE\Software versus HKEY_CURRENT_USER\Software. Sure, not every existing piece of software follows exactly that scheme, but I imagine that's largely because they had to implement it themselves from scratch; if I could get that scheme for free from a library, I certainly would.

I think an additional bit that's important to get right is to track the origin of each setting, so that people don't end up with some_setting = "value", but some_setting = ("value", source)

I would love a library that provided a citation for every config setting (or every piece of input data in general), but as far as I know serde likes to throw away all that information once the deserialization is done. An alternative would be to make an opinionated library that supports only a single config file format, but tracks citations... which is doable, but would certainly be less popular.

My concern is that every existing applications is probably littered with special cases, migration schemes and special rules how settings are handled. I'm not sure it is possible to encode all this into an API without making it extremely hard to use.

There is a crate for "determing system configuration" (app-dirs-rs) but it seems unmaintained and not up to date

I've used app-dirs in a few projects and it was very close to what I want. It's unfortunate that it's unmaintained, but we should crib ideas from it for a replacement, if nothing else!

@luser Is there anything in app-dirs that you feel is missing in directories or is done better?

@soc I think building a comprehensive API that handles config files in the (what's considered for that platform to be) "best practise" is the exact way you fix those corner cases though. A lot of people always assume they know it better or want to have configs somewhere else because…. Making it easier to follow the de facto standard way will reduce the amount of applications that don't do it that way, essentially getting rid of the problem :wink:

@spacekookie I totally agree on making it easier to follow the standard!
My concern is that if you build an API that deals with all the corner cases you are pretty much making the API worse for the "good citizens" of the ecosystem, e. g. an API that says

ok, here is where the config dir should be, except when we have a legacy dir over here, or some custom settings over there etc.

is very different from an API that says

give me the name of your app, and I'll tell you the paths where you should store things

I can totally imagine that the just-give-me-a-config crate that internally uses all the best practices and handle common stuff is just a bunch of foundational crates used in a specific way. So, if you wanted to customize it, you should be able to do what the JGMAC crate (need to work on an abbreviation) does (by doing a good amount of copy-pasta). Maybe we can even write the JGMAC crate in a style that makes "ejecting" easy.
This is an easier to maintain system than trying to do provide a super customizable API. You can think of it like a quicli for configs.

Am 19.03.2018 um 12:43 schrieb soc<EMAIL_ADDRESS>@spacekookie I totally agree on making it easier to follow the standard!
My concern is that if you build an API that deals with all the corner cases you are pretty much making the API worse for the "good citizens" of the ecosystem, e. g. an API that says
ok, here is where the config dir should be, except when we have a legacy dir over here, or some custom settings over there etc.
is very different from an API that says
give me the name of your app, and I'll tell you the paths where you should store things
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

IMO the Javascript CLI ecosystem really get's this right.  See https://github.com/davidtheclark/cosmiconfig

@luser Is there anything in app-dirs that you feel is missing in directories or is done better?

directories seems very sensible and looks like it has roughly everything I would want. My only quibble would be that it does not ensure the directories exist, but that's not a deal-breaker. Getting directories to a 1.0 release would be a good thing for this working group to push on.

Yes, that was an explicit design decision, because the decision to do when something doesn't exist is extremely application-specific.
For instance, if you run an application for the first time, the directory doesn't exist, and you absolutely want the application to create it.
But for instance if you have an application that uses a legacy .app folder instead of following XDG, you probably want to keep using that old folder as-is and not create the new directories.

I've been using structopt in a few projects lately and I'd love to see a config file solution that works as nicely as it does. Maybe building on withoutboats' configure crate, something like:
#[derive(Deserialize, Configure, Default)]
struct Config {
 //...
}

fn work() -> Result<(), Error> {
  let config: Config = read_config()?;
}

Where read_config would use directories or something under the hood to locate an appropriate config file, and if not present use Default::default().
Some other things it'd be nice to consider:

Good error messages for malformed config files. I know @geal has been looking into this recently: https://github.com/serde-rs/serde/issues/1184
Potentially having a way to generate a config file containing defaults would be nice.

Just butting in with my uninformed opinion:
Not only in .cfg files but even in scripts and custom cli environments (dosbox for example) programmers will try to get the user to insert Paths in user readable and writable format. As soon as users try to write this to file, this will never work portably without major sacrifices to correctness, which leads to 'oh you want a portable app with data pre-configured? You can do that, but you have to edit the .cfg/script to change the path separator'.
relative_from_cfg(path: &str) -> PathBuff
For my preferred 'major sacrifice to correctness' I'd like a method to read a relative path that assumes a single and only path separator for all platforms (/ because it's a forbidden filename character in both windows and unix) and return Mone if it has even the possibility of not being relative (start with /. \ or [A-z]+: etc). I
'm aware that unix relative paths can start with c: , but if you want to bring sanity to the 'user made portable paths' you can't accept everything possible. Document that it's clearly for user made paths and leave it at that.

@i30817 is your concern with reading/writing a config file on the same system or sharing config files across systems?
If sharing across systems, can you give more concrete details so we can flesh out what the requirements are for this?

sharing across systems. Common usecase is placing files which contain relative paths to some config dir (of a portable app or app that can be made portable like firefox, or dolphin or retroarch).
Supposedly users can use 'a/relative/path' syntax in windows. In practice, nearly all C and C++ programs blow up with this kind of relative path because they only ifdef _WIN32 '\\' else '/' etc.
There is the complication that a 'c:/a/relative/path' is valid unix syntax for a relative path, but on windows it's a absolute legal path (and maybe illegal if you try to join it to another absolute path), so such a reader function should validate input to see if the user really put in something portable.

We have opened a "RFC-lite" on confy with reference to this. Do leave your feedback.

The directories crate has been mentioned a few times in this ticket. I have recently started to use it in one of my command-line tools and now this issue came up: https://github.com/sharkdp/bat/issues/151. Do people here have any opinion on this? Should command-line tools on macOS use ~/Library/Preferences or ~/.config?

@i30817 Interesting, I played with exactly this idea a few weeks ago:

Have one standard serialization format used to read/write paths from/to config riles
Rule out "dangerous" characters in paths
Provide absolute path placeholders (e. g. you can say "this is an absolute path starting from e. g. the OS' config directory" and have it return the appropriate absolute directory for each platform) so that one can share config files with paths across operating systems.

Yeah, well i reconsidered point 2 myself. I don't mind it being a warning during development, but i don't think it should be forced. Especially since most cli config paths are not controlled by devs but by the user and sometimes they themselves don't control what another tool/user named the files (imagine a file database that is using utf-8).

Yeah ... my approach comes with the expectation that developers are in control of their config file names. I think that's a reasonable assumption in 90% of the cases.
In general, I think there is no having the cake and eating it: either you rule out the various OS' filesystem craziness, or you allow it and have the complexity go through the roof.
I think there is value in having some crate that says "if you don't depend on the crazy parts of Windows path handling, this crate makes your life way easier".

It's true that is a concern more of files that interact more with user paths that the typical config file (though 'last used recent path' is a frequent exception), but i'm thinking that point 1 and 3 are sufficiently valuable that you want to give the ability for them to be used in those paths.

@sharkdp It would be more correct to use Apple's plist format if you write configuration to ~/Library/Preferences, but that's why the API avoids making any judgement on what you do with the paths directories gives you.
If I have some time in the future, I'd love to propose some RFC for Redox that overhauls config handling there and extend  directories to support it.

https://crates.io/crates/dirs looks like a good choice for me even with it's limited features but the API is a lot simpler compared to https://crates.io/crates/directories.

Yes, that's intentional, dirs just exposes individual functions, but if you want to derive paths for applications then you should absolutely use directories' ProjectDirs instead.

Should command-line tools on macOS use ~/Library/Preferences or ~/.config?

I would strongly expect any command line tool to use XDG standard location for config. There is no command line tool I know of that stores its config in ~/Library/Preferences. I know I'm not alone in source-controlling my dotfiles in ~/.config -- while not source-controlling anything in ~/Library/Preferences -- so storing config in ~/Library/Preferences makes that less convenient.
Besides the lack of consistency in storing things in one location on Linux and another on Mac, if Rust utilities alone start storing things in ~/Library/Preferences it's going to be a Java Swing-style uncanny-valley sign of "this is a Rust app".

@kbd As a bit of data: dirs and directories have been out for a while, and I have received no complaints about those libraries adhering to macOS conventions, at all.

I would like to second @kbd. Command line tools are often cross-platform for *nix and as a result the config files are stored similarly to the way they do on Linux, at ~/.config. It doesn't make much sense to store them in a harder to reach and less *nix-y place like ~/Library/Preferences.

I can only confirm what @kbd and @lavifb are saying. I have yet to see a CLI tool which uses ~/Library/Preferences for configuration files.

Just wanted to chime in with my two cents here as well, this actually caught me off guard recently with a tool I was using, llvmenv, which I was making some changes to. It instructed me (and I would've expected no different) to put files in $XDG_CONFIG_HOME/llvmenv, and that a variety of other associated files (cache, data) would be put in other XDG directories accordingly. I did so, but the tool wasn't picking up my config, and I assumed it was a bug of some kind. It was only after I dug through llvmenv, traced through to dirs, that I realized what was going on. It is highly unusual in my experience to find command line tooling with support for XDG that does not honor it on macOS - so unusual that I don't think the author of that tool even realized this was happening on macOS.
If the default directories end up in ~/Library or wherever, then I think it should be a convention that if the XDG_* env vars are set, that those directories are used instead. If they are set, that is a strong indication that the user expects those paths to be used in place of whatever other conventions the OS uses.
I basically never assume configs or other data associated with my shell environment are going to end up anywhere other than in the XDG base directories I have set, or in the worst case, my home directory - but I would never even think to look in ~/Library/Preferences for that kind of thing.
For tooling I build, I certainly will be overriding this behaviour in dirs or any other such library I use so that XDG is always honored first.

I closed https://github.com/soc/directories-rs/issues/47, please have a look at the explanation in https://github.com/soc/directories-rs/issues/47#issuecomment-478337412 for details.

@soc I understand that you do not want to include this in directories-rs, which probably also targets other (GUI) applications.
However, as we have heard from multiple people in this thread (and multiple people in bats issue tracker), the official standard (~/Library/Preferences) on MacOS does not seem to be followed by any command line applications, whereas the XDG-standard seems to be used quite a lot. In this case, I'd rather listen to the actual users and follow what other command-line options do, instead of following the "official standard".

Also I'm not sure I understand the cache problem. Is it a big problem that cached files for CLI apps might be backed up? CLI caches do not tend to be that big in my experience.
But even if it were a big problem, this is not a reason config files can't be placed in ~/.config. People don't manually look at or edit caches very often. Config files, on the other hand, are very important especially in CLI applications. There is often no other way to configure these apps. Placing these files in a convenient and generally agreed upon location for users shouldn't be dismissed out of hand.

@sharkdp

However, as we have heard from multiple people in this thread (and multiple people in bats issue tracker), the official standard (~/Library/Preferences) on MacOS does not seem to be followed by any command line applications, whereas the XDG-standard seems to be used quite a lot. In this case, I'd rather listen to the actual users and follow what other command-line applications do, instead of following the "official standard".

The difference between Linux and macOS is that Linux is a system written by developers, for developers.
On the other hand., macOS is built by Apple, owned by Apple and controlled by Apple. The opinions of developers frankly doesn't matter on macOS – they are not calling the shots. If Apple ever decides to clamp down on applications not following their rules, I'm not going to take responsibility for the ensuing breakage.
Just as a reminder,

does not seem to be followed by any command line applications

is an excuse I heard more often than I care to count on Linux, too. directories-rs does exactly what it says on the tin: it follows the platforms standards.

@lavifb

Is it a big problem that cached files for CLI apps might be backed up? CLI caches do not tend to be that big in my experience.

Pretty much every dependency manager on this planet is a CLI. Have a look at the cached stuff of Maven, npm or cargo. The cache directories are huge.

@lavifb

Is it a big problem that cached files for CLI apps might be backed up? CLI caches do not tend to be that big in my experience.

Pretty much every dependency manager on this planet is a CLI app. Have a look at the caches of Maven, npm or cargo. The cache directories are huge.

But all of those store cache in the home dir on MacOS:

~/.npm/
~/.cargo/
~/.m2/

More importantly, their config files are not buried somewhere deep in preferences but are all easily accessible in the home dir.

Yes, I hope you now understand the issue with that (on both Linux and macOS).

@soc
I think we just have different philosophies for this kind of library. Thanks for explaining your reasoning
@sharkdp

This is why I feel that there is a need for a directories-rs-like library that uses the XDG-standard on both Linux/MacOS and the "Known Folders" on Windows.

I do, however, think there is room for another crate that makes a different tradeoff here.

This is why I feel that there is a need for a directories-rs-like library that uses the XDG-standard on both Linux/MacOS and the "Known Folders" on Windows.

I do, however, think there is room for another crate that makes a different tradeoff here.

Absolutely. That's why I said that I completely understand that @soc does not want to change directories-rs.

Alternatively we could encourage developers to write applications which are well-behaved citizens of the platform they run on.
In the beginning of medicine people also thought there was room for not washing hands before a procedure. Thankfully, washing hands became non-optional, even though many considered it to be surprising and unexpected at that time.
I'm optimistic that – with an effort to educate developers – a similar success story can be achieved here.

Counterpoint: the reason we disagree isn't because we need to be "educated" that we're "share-croppers" who need to learn to be "well-behaved", but because we view the platform differently.
Many use macOS because it's the best way to get a unix with a good gui. Remember, with the command line on Mac we're talking about an open-source unix that effectively shares a userspace with Linux.
That shared GNU/Linux/POSIX userspace is what we think of when we use the command line on Mac. It's why we'd prefer to share system conventions with it when it makes sense to.

This topic isn't being very productive, and I don't think it should be discussed further on this issue. We'd be better served by working towards one of other the aspects of configuration file management we've yet to address, rather than circling around a difference in opinion.

While this may not be satisfactory for a number of reasons, I'd like to say that ripgrep's approach to configuration files has generally side-stepped all of the issues mentioned here, and generally has received zero complaints from users. The trick is to opt out of encoding knowledge about xdg (or similar) at all in the first place. Namely, ripgrep requires users to set an environment variable that points to the location of the config file.
That location can be anywhere. The user can choose any arbitrary location. People like me who gave up caring about the cleanliness of their home directory can plop it at $HOME/.ripgreprc, while macOS users rebelling against their overlords can drop it into an xdg compatible location if it suits them.
As I said initially, this is not satisfactory for a number of reasons. One such example is that this really only applies to configuration. If your application needs to make use of cache directories, for example, then forcing the user to set an environment variable is probably bad UX and not something they'd expect. My approach also only works if the configuration file is entirely optional (which is honestly probably a generally good idea anyway).
Anywho, I don't mean to propose this as a panacea, but it's something that can work well in a specific circumstance for maintainers that don't want to be on the wrong side of an hord of users because your program put the config file in the wrong place.

I just published my first rust library on crates.io which is a config library that I plan to use in another application I'm developing. It's currently lacking quite a bit in documentation (but there is some), but it provides configuration (either configured by the application, or by convention) from multiple places (user folders, application folders, environment variables and cli arguments). Binding to structs is still not available though (but should be reasonably straight forward).
Sample usage looks like this:
#[derive(ClapConfig)]
pub struct Server {
  #[preftool_clap(help = "Server host")]
  host: String,

  #[preftool_clap(help = "Server port")]
  port: usize,

  #[preftool_clap(help = "Server certificate (enables TLS)")]
  cert: Option<String>,
}

fn main() -> std::io::Result<()> {
  let mut builder = TerminalLoggerBuilder::new();
  builder.level(Severity::Debug);
  builder.destination(Destination::Stdout);
  let log = builder.build().unwrap();

  let config = AppConfigBuilder::new("preftool-app-config-simple", Some(log))?
    .with_args::<Server>()
    .configure(|app| app.version("0.0.1"))
    .add_format(TomlConfigFormat)
    .build()?;

  println!("{:#?}", config);
  Ok(())
}

This will read config from toml files, environment variables, and application arguments.

@Alxandr Very interesting library!
One note, please do not use dirs-sys directly – I updated the README to that effect: https://github.com/soc/dirs-sys-rs#compatibility

@soc issue is that neither one of those two provides me the information that I need though. I will probably have to go back to just having the functions embedded instead. I switched to dirs-sys to get away from having to do conditional dependencies based on OS. The only thing I use home_dir, is_absolute_path and 2 of the windows dirs.

Feel free to use it at your own risk. I just wanted to make sure that the level of non-guarantees has been communicated. :-)

Fair enough. I would love a stable API with the low-level primitives I though ;-).

I just made/published platform-dirs which provides a simple API for retrieving platform dependent application directories and user directories. It also allows for specifying if an application is CLI based and uses the XDG specified application directories on macOS if so. There's some other differences relative to dirs-rs and directories-rs at the bottom of the readme too. It's still beta-level so the API may change and it may have bugs FYI. Any and all suggestions welcome!

From Discord @mike7c2
It's pretty neat at the user end, I didn't have to do much at all to get it running, it does layering off cli args, config file args and environment args, it has some tools for other layers too but I didn't look at them

I really liked being able to define my config as a structure - that was easy and natural, really bolstered by the fact it populates comments from the struct into the CLI arg definitions and stuff. I do wonder if I should be going a step further and using a yaml/dhall schema to define my arguments but at the same time I don't think that added level of descriptiveness will get me anything

I didnt check in detail but it definitly pulled in quite a bit of stuff, exe size got big adding it but that isn't a real issue for me

The thing that bugged me most about it was not being able to make nested config fields, it needs to work with a flat structure so to work with it you need to flatten any nested keys

Overall I'm just trying to find something which works good enough I can build into a template I will build some GRPC services on top of

Reformatted for your reading pleasure:

It's pretty neat at the user end, I didn't have to do much at all to get it running, it does layering off cli args, config file args and environment args, it has some tools for other layers too but I didn't look at them
I really liked being able to define my config as a structure - that was easy and natural, really bolstered by the fact it populates comments from the struct into the CLI arg definitions and stuff. I do wonder if I should be going a step further and using a yaml/dhall schema to define my arguments but at the same time I don't think that added level of descriptiveness will get me anything
I didnt check in detail but it definitly pulled in quite a bit of stuff, exe size got big adding it but that isn't a real issue for me
The thing that bugged me most about it was not being able to make nested config fields, it needs to work with a flat structure so to work with it you need to flatten any nested keys
Overall I'm just trying to find something which works good enough I can build into a template I will build some GRPC services on top of


RecursionError: maximum recursion depth exceeded while calling a Python object

when i process a folder with 11316 images,get the RecursionError from phasher.find_duplicates(encoding_map=encodings) ,whether the num of images which can be processed is limited?

already have similar question,so i closed this issue


Unable to set any other color other than white to denote a 0 value in a heatmap

I wish to have a heatmap with a 0 value corresponding to red and a 1 value corresponding to white in the Clustergrammer JS Module. However this seems unachievable by any parametric changes. The only option provided in Clustergrammer JS is changing the color of the positive and the negative end.
This Feature is especially needed for P-Value heat maps where a lower value denotes higher significance, hence a darker color corresponding to the 0 is preferred.

Thanks for the suggestion @cornhundred . It helped me indeed.
This issue is not pertaining to this repository. Hence I'm closing this issue here and would reopen it in the clustergrammer JS repository belonging to the MaayanLab.
Apologies.


Fix the alignment of items on the Navbar. Increase Spaces

Hey! please assign this issue to me. I am confident that I'll be able to resolve the issue.

Hey, I have solve this issue please look into it if there is something which needs to be done do tell

hey @SauravMukherjee44  can you assign it to me as well, I'll do my best to fix this

@agarwalrashika00 @pragyaSingh13 Create a PR! No need of Assignment

@harshita214 Host your repository and share the link in the comment.

https://github.com/harshita214/Aec-Library-Website

is this the link you are talking about?


Ingress not functional in GKE imported cluster (HTTP Loadbalancing enabled)

Rancher versions:
rancher/server or rancher/rancher: v2.1.0-rc8
GKE cluster version: 1.10.7-gke.2
Issue also seen in v2.0.8 with the same GKE cluster version
Steps to Reproduce:

Create a GKE cluster in GCE with the config below.

Note: HTTP Loadbalancing is enabled
This is the same config that is used when a GKE cluster gets created through rancher UI
2. Create an ingress(xip.io or with ingress specifying a host name)
3. The public end points do not get populated. Ingress is not functional
Note: Ingress created on a GKE cluster(with the same config as above) created through rancher is functional

This is also present in v2.0.8, so it isnt a regression, so moving it out of v2.1


re-generate

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

15 of 45 (33.33%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-2.2%) to 55.906%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

generated.go
15
45
33.33%

Totals

Change from base Build<PHONE_NUMBER>:
-2.2%

Covered Lines:
284

Relevant Lines:
508

💛  - Coveralls


Does the Azure portal Require JavaScript to be enabled?

Listing the supported browser is nice, but there should also answer other requirements like: Does the Azure portal Require JavaScript to be enabled?

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

ID: 225d8386-c24d-7202-4eb0-61e2f8249e3e
Version Independent ID: 83f151c6-4870-58b1-b44e-56e3bd42bb25
Content: Supported browsers and devices for Azure portal
Content Source: articles/azure-portal/azure-portal-supported-browsers-devices.md
Service: azure-portal
GitHub Login: @adamabmsft
Microsoft Alias: mblythe

@jwilleke Thank you for the feedback. We are actively investigating and will get back to you soon.

Assigning content owner @adamabmsft for visibility, review and document enhancement consideration as appropriate and/or to provide related insights if any.

I'll this requirement to the docs, FYI @adamabmsft

Update will go live today.

#please-close


Remove cassandra full tests data loader and caches

Removed:

Cassandra
full_test.go
Data loader / caches

Add:

Run new acceptance tests
Add code to track coverage

Merged although a test fails. Want to remove some endpoints first, will then fix these tests.


VimTex Deprecated setting

nvim --version: 0.8
terminal emulator and version: Nvy.exe
Operating system/version: Windows
Have you read and followed all steps in the doc: Yes
Output of command set runtimepath:

Describe the bug
Opening any .tex file will generate the below warning:

Steps to reproduce the issue:

Open any .tex file

Expected behavior
Not to see any warnings

can you reproduce with 0.7? Only stable version is supported.

Yes. I get the same error :(


feat: tree shake

Description
Make string-ts output easier to tree shake with webpack, rollup, etc
Details
tsup tree shake docs
I was playing around locally with the following:
sibling-folder/src/index.ts
import {toLowerCase} from '../../string-ts/dist/index.js';

const result = toLowerCase('A.B.C');
console.log(result)

sibling-folder/webpack.config.js
import path from 'path';
import {fileURLToPath} from 'url';

const __dirname = fileURLToPath(new URL('.', import.meta.url));

export default {
  entry: './build/index.js',
  output: {
    filename: 'index.js',
    path: path.resolve(__dirname, 'dist'),
  },
  mode: 'production',
  // mode: 'development',
  // optimization: {
  //   usedExports: true,
  //   innerGraph: true,
  //   sideEffects: true,
  // },
};

When I added --treeshake to the build command in string-ts, It decreased the output from 252 lines (containing the full lib) to 30 lines (just my custom code and the required function from string-ts.
Note: the output from webpack was uglified, so I ran prettier on the output in order to do the output comparison and line counts.
This seems to have worked well with webpack, but I'll see if this has the same effect when using rollup.

@jly36963 this is a way easier PR that mine :) but actually, this got me wonder - is there any thing to do at all? from what I can see - the library (v1.2) is already tree shakable:

this is what agadoo is saying
I tried to bundle a small react app with vite - and the string-ts import was tree shaked

so actually I am not sure there is anything to do at all? (ping @gustavoguichard)

@p9f I'm no webpack expert, but neither the prod or dev (commented out) webpack config yielded a tree-shaken result until I added the --treeshake option. I want to see if I have similar results when testing rollup (and any additional build tool suggestions).

@jly36963  I tested vite (rollup) and bun - both worked fine out of the box. But I did not tested webpack so that makes sense

Awesome guys! So let's just go with this option, write something on the readme and add sideEffects: false to package.json.
That should help all the bundlers.

write something on the readme and add sideEffects: false to package.json

@gustavoguichard will do this after work today (ie: in a few hours)


Editorial check: all tables/figures/equations/annexes need to be referenced at least once

From @stuartgalt

https://github.com/orgs/metanorma/discussions/10

ISO style checks should make sure that all tables, figures, equations are referenced somewhere in the document.
@ronaldtse
This is an ISO DIR or House Style requirement. All these items and the Annexes need to be referenced at least once.

That is not how I read  the ISO House Style at all, but I will implement this: all numbered tables, figures, formulae, annexes. Presumably not examples, notes, admonitions, lists.

Providing references as requested by @opoudjis :
ISO DIR 2:
Annexes

Formulas

Figures

Tables

I am seeking clarification from ISO on whether:

subfigures need references
unnumbered formulas need references

I continue not to interpret ISO/IEC DIR 2 that way (the examples are more about making sure the examples are not implicitly referenced, e.g. as "see the following example") In any case, done.

We received the following clarification from ISO:

the current wording that says “xxx shall be explicitly referred to within the text” means “xxx must be referred within the text at least once” (this is my understanding).

=> Yes. “shall” expresses a requirement.

a formula can unnumbered, and in this case it does not need to be referenced inside the text? According to Directives, Part 2, 27.4, a formula should be referenced if it is numbered.

=> “Should” expresses a recommendation, so it’s not required to reference a formula, but it’s good practice to do so.

a subfigure must have an internal reference from the text? The requirement to reference figures only applies to top-level figures.

=> Subfigures can be referenced in the text but this is not obligatory.

2 would mean that the warning about formulas not being referenced is downgraded, from 1 to 2.


add support for zellij

Hey @ojroques!
First of all thank you for creating this plugin. I would love to make use of it in my configuration.
I'm using Zellij as my terminal multiplexer though and it seems to need a different sequence than e.g. tmux. Would you be able to look into this and add support for it?
Here is a sequence I found in their repository: https://github.com/zellij-org/zellij/blob/67d2673cae60954e8287c2a1f58a21a56e066afb/zellij-server/src/tab/clipboard.rs#L34
Unfortunately I don't know how to read and implement this sequence exactly myself.
Best Regards!

Hello!
I read that in the config of Zelliji:
# Provide a command to execute when copying text. The text will be piped to
# the stdin of the program to perform the copy. This can be used with
# terminal emulators which do not support the OSC 52 ANSI control sequence
# that will be used by default if this option is not set.

(source)
So first does OSC52 work outside of Vim when you copy text in Zelliji? And what terminal emulator do you use?

Thank you for your quick response!
I'm on Windows and use Windows Terminal, mainly using a wsl distribution. This is how I'm copying text from Zellij so far:

Select text via mouse
On release of the button the message "Text copied to clipboard" gets printed
I can paste the copied text in Windows

I didn't set any copy command in the configuration so I think OSC52 is used and working.

So I've tried using the sequence from your link but it does not work. I suspect that Zelliji does not forward escape sequence from applications yet. There is a related issue already https://github.com/zellij-org/zellij/issues/1199.

Ah, I see. I didn't know about this. Thanks for pointing it out.
Should this issue stay open then? Are there possible changes you need to make once Zellij supports forwarding?

Yes it can stay open. I don't think any change will be necessary but we'll see.

After https://github.com/zellij-org/zellij/pull/1644 this have been solved, I think this issue can be closed and shouldn't be opened in the first place :-(

Great!


manual clear cache using github.com/devopsfaith/krakend-httpcache

How can I manual clear cache data?
Used github.com/devopsfaith/krakend-httpcache for cache

you can't. the cache component honors the cache header from the response and keeps it in memory until it expires


Merge "labelled" & "not-labelled" metric classes

💻 How to review this PR?
This PR was created with the idea of being reviewed commit by commit. Each commit contains an incremental change that makes it easier to review. Also some of the commits contain additional information in their description to help understand why the change was made.
I also recommend checking "Hide whitespace" when reviewing this PR!

🚀 What's included in this PR?
This PR merges the "labelled" and "no-labelled" metric classes. This can be done in an almost source-compatible way since we can represent a non-metric labelled as a labelled one with no labels and Unit as the label type.
We'll need to add a Scala Steward artifact migration for changes like Counter[F, A] to Counter[F, A, Unit]

Nice 😎


PR: Add broken icon in the plots if the figure is corrupted

Description of Changes

[ ] Wrote at least one-line docstrings (for any new functions)
[ ] Added unit test(s) covering the changes (if testable)

[ ] Included a screenshot or animation (if affecting the UI, see Licecap)

Add a broken icon in the plots if the figure loaded is corrupted

(Hardcoded a division by 0 for getting the screenshot)
Issue(s) Resolved

Fixes #12253
Affirmation
By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.

I certify the above statement is true and correct: Steff456

Hello @steff456! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file spyder/utils/icon_manager.py:

Line 339:80: E501 line too long (89 > 79 characters)

Tooltip with the error message

@steff456, please also rebase this PR to avoid the error in our tests I fixed yesterday.


New Diode2 model's HeatPort does not work

Reported by stefanv on 6 Nov 2015 13:54 UTC
Unlike the other Electrical.Analog components, the HeatPort in the new Diode2 model doesn't do anything. Instead, the effect of heat is modelled indirectly (and in a non-varying way) via the Vt parameter. Changing the model to activate the HeatPort is trivial (see // <--- lines in code below):
model Diode2 "Improved diode model"
    extends Modelica.Electrical.Analog.Interfaces.OnePort;
    extends Modelica.Electrical.Analog.Interfaces.ConditionalHeatPort(T=293.15);
    parameter SIunits.Voltage Vf = 0.7 "Forward voltage";
    parameter SIunits.Current Ids = 1.e-13 "Reverse saturation current";
    parameter SIunits.Resistance Rs = 16 "Ohmic resistance";
    parameter SIunits.Voltage Vt = Modelica.Constants.R * T
				 / Modelica.Constants.F
	"Thermal voltage (kT/q) when useHeatPort=false, 0.026 at normal conditions (around 20 degC)";
    parameter Real N = 1 "Emission coefficient";
    parameter SIunits.Voltage Bv = 100 "Reverse breakdown voltage";
    parameter SIunits.Conductance Gp = 1e-6
	"Parallel conductance for numerical stability";
    SIunits.Voltage vd "Voltage across pure diode part";
    SIunits.Current id "diode current";
    SIunits.Voltage VdMax "Linear continuation threshold";  // <--- These are now variables
    SIunits.Current iVdMax "Current at threshold";          // <---
    SIunits.Conductance diVdMax "Conductance at threshold"; // <---
    SIunits.Voltage VtUse;                                  // <---
equation
    /* Parameters which depend on a possibly variable temperature. */
    VtUse = if useHeatPort // <---
	    then Modelica.Constants.R * T_heatPort / Modelica.Constants.F // <---
	    else Vt; // <---
    VdMax = Vf + (N*VtUse); // <--- All uses of Vt after here changed to VtUse
    iVdMax = Ids * (exp(VdMax/(N*VtUse)) - 1); // <---
    diVdMax = Ids * exp(VdMax/(N*VtUse))/(N*VtUse); // <---

    id = smooth(1,
      if vd < -Bv / 2 then
	  /* Lower half of reverse biased region including breakdown. */
	  -Ids * (exp(-(vd+Bv)/(N*VtUse)) + 1 - 2*exp(-Bv/(2*N*VtUse)))
      elseif vd < VdMax then
	  /* Upper half of reverse biased region, and forward biased region
	     before conduction. */
	  Ids * (exp(vd/(N*VtUse)) - 1)
      else
	  /* Forward biased region after conduction. */
	  iVdMax + (vd - VdMax) * diVdMax);

    v = vd + id * Rs;
    i = id + v * Gp;
    LossPower = i * v;

    assert(Bv>0, "Bv must be greater than zero", AssertionLevel.error);
    assert(Vf>0, "Vf must be greater than zero", AssertionLevel.error);
    assert(Vt>0, "Vt must be greater than zero", AssertionLevel.error);
    annotation (...);
end Diode2;

Migrated-From: https://trac.modelica.org/Modelica/ticket/1823

Comment by majetta on 10 Dec 2015 14:21 UTC
changes as described in that ticket added to Modelica.Electrical.Analog.Semiconductors.Diode2 in 0f2a789f6e6701eebcf736afdb8574e23f189876

Changelog modified by majetta on 10 Dec 2015 14:21 UTC
temperature dependency added to Modelica.Electrical.Analog.Semiconductors.Diode2

Comment by dietmarw on 10 Dec 2015 14:27 UTC
Please remove the uses annotation from your commit.

Comment by majetta on 10 Dec 2015 15:09 UTC
uses-annotation and -tag removed in eb32e1257b5d7ae73036c9c9da40b60e71c29bed

Comment by dietmarw on 11 Dec 2015 06:56 UTC
A student of mine noticed that also the Modelica.Electrical.Analog.Semiconductors.ZDiode model has a heatport but the behaviour of the z-diode is no influenced by the temperature. Are there any plans to introduce this?

Changelog modified by dietmarw on 11 Dec 2015 06:56 UTC
Temperature dependency added to Modelica.Electrical.Analog.Semiconductors.Diode2

Comment by dietmarw on 11 Dec 2015 07:18 UTC

Moved Diode2 up below Diode in e1c90ae2bc86982d179c1ff30bd6638e9d6bac8b
Replaced * in the documentation equation by the more accurate · symbol in 4faff469235476539755a498281eb7d9a45083a9.
Fixed number format of a parameter in 91e150035aafb69fc04c15582f8c893e02db757c

Modified by dietmarw on 11 Dec 2015 16:07 UTC


chore: update README and docs to include brew install

#161  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @jakim929 and the rest of your teammates on  Graphite


Setting Asynchttpclient Cipher

Hi there,
I'm currently using android-async-http in a project and it's been great so far until I started using cloudflare. It's:
error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error (external/openssl/ssl/s23_clnt.c:744 0xabbdbd74:0x00000000)
I've been researching this and narrowed it down to the use of the wrong SSL cipher setting. Is there a way within android-async-http to easily change this? Or am I completely missing the mark?

This is problem of underlying LibSSL implementation, where you're trying to connect with unsupported version of SSL/TLS (eg. using TLSv1 on SSL3 only server)
You can test the backend using ssllabs.com/ssltest/analyze.html testing suite, which should show if the backend has problem with ciphering setting.
Library does not use different than system SSLSocketFactory (which is the cause), only if you use (true, 80, 443) constructor of AsyncHttpClient, it will try to enforce TLS, see code for reference
public class MySSLSocketFactory extends SSLSocketFactory {
    final SSLContext sslContext = SSLContext.getInstance("TLS");

Otherwise it's using system default SSL settings.
You can provide your own SchemeRegistry instance to constructor of library, to provide different SSLSocketFactory with different SSL security settings.


Documentation: Front-matter misidentified

Under Creating Pages there this text:

IMPORTANT: The AsciiDoc file must have a Markdown-style front matter header or else it won't be recognized as a page.

The front-matter is YAML, not Markdown.

There is open PR #24, about plugin documentation changes.
I can also update front-matter section, if @mojavelinux and @paulrayner are OK with it.

Sounds good to me.

Pushed fix to PR #24, as soon as PR will be merged this issue should be auto resolved.

@jcsalomon, thanks for pointing out that a clarification is needed here. And thanks @eshepelyuk for incorporating this change.
When I originally wrote "Markdown-style front matter", what I meant was "YAML front matter commonly found in Markdown files". Perhaps we can word it in that way.
Even better would be to link the words "YAML front matter" to the Jekyll documentation on the subject: http://jekyllrb.com/docs/frontmatter/

Added link to Jekyll site to PR #24

:+1:


Why do there are manual delays in js script?

Do they have any work there i cannot understand it? Do anybody knows about it?

Out of respect to their servers. Same reason it's not parallel at the moment either.
https://github.com/nadimkobeissi/mkbsd/pull/2#issuecomment-2372671683


Use client variable to make api calls to k8s cluster

Use the client.Client property of the reconciler object to make client calls instead of using the reconciler object directly.
BZ: https://bugzilla.redhat.com/show_bug.cgi?id=2231076

@iamniting @umangachapagain PTAL.

Should we take it for previous versions as well? If so, all of them?

Should we take it for previous versions as well? If so, all of them?

Nikhil, I don't think that this fix will fix the issue we want to fix here after looking at the logs provided by you. Maybe we should use a new client in the setup with the manager instead of using the existing cache client.


Heap Sort in Java

I want to implement heap sort using java.
/assign

/assign

Already implemented


Replace inference outputs

I think it could be helpful to replace the output of inference (which is currently a tuple) by a dictionnary.
That way it would be easier to use other models (that do not necessarily have the exact same outputs) with Posterior. It would maybe also help gain in clarity.
What do you think?

@PierreBoyeau who's that question for?
Seems like a good idea to me. :)
Will you submit a PR?

To the community :house: !
Sure I'm on it


a bug for MNLI eval result?

Hi there @madlag,
Thanks for your great work!
It seems there is a problem for MNLI
if we update text_classification/parameters.json with do_train: 0
and run following,
mkdir result
export CUDA_VISIBLE_DEVICES=0; python command_line.py finetune --json-path  text_classification/parameters.json mnli result

we get the result
"eval_results_mnli.json"
{
    "eval_accuracy": 0.06622516556291391,
    "eval_loss": 15.527382850646973
}

I would really appreciate if you could double-check the code and there could be a bug? Or I must miss something.

@madlag  it looks like  the prediction mapping is wrong? [1,2,0], ==>-1[2,0,1]: if you go to https://github.com/huggingface/nn_pruning/blob/main/examples/text_classification/glue_xp.py#L332  and and update the prediction                                                                               new_preds = [] #[1,2,0], ==>-1[2,0,1]              for x in preds:                 if x ==2:                     new_preds.append(1)                 if x ==1:                     new_preds.append(0)                 if x==0:                     new_preds.append(2)
we get the result
"eval_results_mnli.json"
{
"eval_accuracy": 0.8469689251146205,
"eval_loss": 15.527382850646973
}


[question] How i compile raylib with msvc

so, i was triying to compile raylib with visual studio 2019, and it have me some external linking errors, some one have a clue how to fix this?

The problem seems to be in raylib.lib.
Have you looked in the raylib\projects\VS2022\ folder for Visual Studio solutions and examples?  Those should work with VS2019.  If you get one of those to compile and run, you should be able to scavenge from one of the examples to build your own project.
PS: Use one of the release sources available on GitHub.  These should be more stable and suitable for getting started.

@susyboy23 provided VS2022 preconfigured project should work ok.


Added Code for Intersection of linked list in C,Java and Python

🛠 Issue (Number)

Issue no #1404
👨💻 Changes proposed

✔ Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

📄 Note to reviewers

📷 Screenshots

Please Review

@Arun9739 Please approve

The requsted changes have been made, please check now.


Draft: UNDEFFUNC & UNDEFGLOBALDEFINE & UNLOADDIC

This is just a draft implementation. That's the general idea
I don't know whether making a function nameless can prevent other functions from calling. If some functions call a function that has been undefined, how to report an error and how the return value is all a problem

In my plan, there will also be a DEFFUNC function to provide fast function definition. Like lambda in other languages, DEFFUNC('func',"{%(_varname)++}") will create a function called func, each call will add 1 to the variable referred to by _varname
But my understanding of the internal structure of Yaya makes it difficult for me to achieve these things
Of course, it may just be an excuse for laziness

I think that's all I can do

Implemented.
Note : UNDEFGLOBALDEFINE can't specify name straightforward, because globaldefine replaces all texts even though they are surrounded by quotation marks.


Column 'Log' in 'Monitor activity runs'

Under 'Monitor activity runs' yo list the columns available like 'Activity name', 'Activity status', Activity type', 'Run Start', etc...
But currently (2023-08-11' I see what I belive is a new column called Log .
Can you explain how push information in this column Log please

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

ID: 1667bd5c-cfec-f8d8-f455-285fe51b97c4
Version Independent ID: e1426374-a7b8-25a1-dd8a-0fd60ff2738b
Content: Visually monitor Azure Data Factory - Azure Data Factory
Content Source: articles/data-factory/monitor-visually.md
Service: data-factory
Sub-service: monitoring
GitHub Login: @nabhishek
Microsoft Alias: abnarain

@vharcq
Thanks for your feedback! We will investigate and update as appropriate.

Hi @vharcq
The "Log" column you are seeing may be a custom column that was added to the monitoring interface by your organization or by a third-party tool. It is possible to add custom columns to the monitoring interface using Azure Monitor logs or other monitoring tools. To push information into a custom column like "Log", you would need to configure your monitoring tool to collect the desired information and display it in the custom column. The specific steps for doing this will depend on the monitoring tool you are using.
If there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.

@vharcq
We are going to close this thread, if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.
#Please-close


Feature/231 create dataset boilerplate

What this PR does / why we need it:
Creates basic framework in order to continue development on the "Create Dataset" feature page
Which issue(s) this PR closes:

Closes #231

Special notes for your reviewer:
Please harass me if there are changes I should be making to my development. Including tests.
Suggestions on how to test this:

Navigate to http://localhost:8000/spa/datasets/create
Enter Title
Click Submit

Does this PR introduce a user interface change? If mockups are available, please link/include them here:
Issue Comment
Is there a release notes update needed for this change?:
N/A
Additional documentation:

coverage: 98.291% (+0.001%) from 98.29%
when pulling 6a9cdcebbd249a3220b5f2c004c996c7288a05e1 on feature/231-create-dataset-boilerplate
into 1acebdf114bceca24f84c28a18028568f92055e3 on develop.

@M27Mangan, when you are done with the requested changes, please remember to reassign the PR to me and unassign yourself. This way, I will be aware that I can review it again

@MellyGray and @GPortas I plan on making some small adjustments to the project structure over the weekend that both of you had pointed out in this issue by moving some contents in 'src/sections'. I will open another PR by Monday for your review.

@MellyGray - If you would like to take this branch to finish while staff are on break or change it to resemble your current workflows, please feel free to do so and I can check out your changes when we get back. Thanks!

@M27Mangan I'll be on break from today until Jan 8th. Since this feature is not currently a priority, you can take you time to address the requested changes once you can back from your break
As I mentioned, you can use the Dataset.tsx page component as a reference for structuring the CreateDataset.tsx page
Thanks! Happy holidays!

Some aspects of this feature are dependent on https://github.com/IQSS/dataverse-client-javascript/issues/110 and the Create Dataset use case

Can you solve the merge conflicts?

Changes for review @MellyGray

Last round of changes (hopefully). If there's anything I missed from the most recent updates, please send them in Slack and I will take care of them first thing on Monday, thank you!

Overall this looks very good!
Two things I noticed:

The TopbarProgressIndicator never goes away - I think because isLoading is never set to false.

For this I think you need to set isLoading in a similar way to the view Dataset page.  Except for this page, we don't have to wait for the dataset to load, so useCreateDatasetForm could have isLoading set to false.

2. The Cancel button currently seems to be triggering a submission, so it shows validation errors. Can we change this to have a separate handler?

looks good!


Fix session module

This is a tiny fix i noticed when using the new session-module sign_in. This hasn't been up on pypi yet, so no one should have been affected by it.

@etpinard , quick +1 ?
//cc @bpostlethwaite

:dancer:

thx!


Bump uv version

Why?

Minimum versions are constraints, ideally defining the lowest version providing support for the features used within a package (tox-uv).
Unless tox-uv makes exclusive use of new features provided in these newer versions (which aren't included in this PR), this isn't a good PR, only restricting further what versions of the tool are supported.

@Stealthii you are right. This was just a quick PR to use the latest supported uv which can bring significant improvement in performance.

Thing is you don't need this PR for that, if you reinstall the tool it will automatically pull it in.

@gaborbernat what is the purpose of uv dependency restriction in pyproject.toml then?

it's lower restricted, meaning we need at least this version.


document.write!! and goog.require() problem

in targeted browser environment goog.require after document.load is not allowed because google closure use writeScriptTag which is violent and it wipe out the page and throw error 'Cannot write "' + src + '" after document load'.
// line 1232 of base.js
  goog.writeScriptTag_ = function(src, opt_sourceText) {
    if (goog.inHtmlDocument_()) {
      /** @type {!HTMLDocument} */
      var doc = goog.global.document;

      // If the user tries to require a new symbol after document load,
      // something has gone terribly wrong. Doing a document.write would
      // wipe out the page. This does not apply to the CSP-compliant method
      // of writing script tags.
      if (!goog.ENABLE_CHROME_APP_SAFE_SCRIPT_LOADING &&
          doc.readyState == 'complete') {
        // Certain test frameworks load base.js multiple times, which tries
        // to write deps.js each time. If that happens, just fail silently.
        // These frameworks wipe the page between each load of base.js, so this
        // is OK.
        var isDeps = /\bdeps.js$/.test(src);
        if (isDeps) {
          return false;
        } else {
          throw Error('Cannot write "' + src + '" after document load');
        }
      }
...

we asume that dependency graph is not changes after page load, and it had been done compiled at the first build step, then evaluated all the way down
but in dynamic environment and interactive development ... dependencies are changes a lot.. and we communicate with goog.require to pull out new dependencies..
this is not posible because goog.require use document.write('<script url>'), we need to find better way to bring js into evaluated environment without document.write
for example:
function loadScript(sScriptSrc,callbackfunction) {
    var oHead = document.getElementsByTagName('head')[0];
    var oScript = document.createElement('script');
    oScript.setAttribute('src',sScriptSrc);
    oScript.setAttribute('type','text/javascript');
    var loadFunction = function() {
      if (this.readyState == 'complete' || this.readyState == 'loaded') {
        callbackfunction();
      }
    };
    oScript.onreadystatechange = loadFunction;
    oScript.onload = callbackfunction;
    oHead.appendChild(oScript);
  }

loadScript(host + ":" + port + "/socket.io/socket.io.js", init);

what was evaluated may need changes, using chrome console repl and call goog.require to pull dependencies and being able to evaluate things after page load, for me it is huge impact on productivity,
our goog.require should be able to load after page loaded, what do you think? :+1:

@jplaisted is working on revamping our debug loader to work with ES6 modules, and part of that involves making it more asynchronous.  I believe this will come for free when that rolls out, though I can't say for sure.

Things would be more asynchronous but not necessarily dynamic. I don't think we really want to support dynamic loading post document load. Even with a new debug loader for ES6 modules you'd still have to hack things. We can't resolve relative paths post script evaluation. So you'd have to use absolute paths or symbols/namespaces. Later is fine but the former breaks the conventions we're adding (granted azizzaeny is doing in his example, so maybe users are fine with it, but it'd be confusing, imo). Also the debug loader doesn't get loaded in compiled or bundled environments, meaning you can't dynamic load there.
Back over to @shicks to decide if this something we want to support in the future. But the new debug loader I'm writing for ES6 modules will not add this; we'd have to address the above concerns and then probably some more.

I guess I misunderstood the request.  We are looking into the possibility of building a late-loader into Closure, but it's unclear what its mechanism will be, and it's a lot less certain to happen.  As @jplaisted points out, it's unlikely we'll want to tie it to the same symbols used by goog.require (especially since these are increasingly dinosaurs in our ES6 world).  So I'd say stay tuned and please chime in on a separate issue if you have thoughts about late loading, but this particular issue is WAI.

Just to be clear, we consider late loading an orthogonal issue to goog.require and to the ES6 module loading issue, and it's honestly somewhat low priority.
In particular is that we're primarily concerned with late-loading production (compiled) code, and it's pretty unclear how this would fit into Closure Library.  It's not impossible that we'd work on it, but I wouldn't hold me breath on it.

the hack was using goog.net.loadMany
goog.provide = goog.exportPath_
goog.lobal.CLOSURE_IMPORT_SCRIPT = function(file){
 if(goog.inHtmlDocument_){  // loaded
    goog.net.jsloader.load(file)
  }
}

use somewhere goog.net.jsloader.loadMany()`, will pull dependencies
but now its deprecated, @shicks and @jplaisted do you know any alternative to goog.net.jsloader ?
the examples above are just plain, rough and doesn't enough solution but the idea is there..
we can actually call goog.require after page loaded it will produce null
with requirement the first goog.addDependencies graph is introduced and the first goog.require call is evaluated
but when the first goog.require not yet evaluated then the problem is there..
to reproduce my issue add goog/base and goog/deps.js to html
<script src="public/main.out/goog/base.js"></script>
<script src="public/main.out/goog/deps.js"></script>

then you eval in REPL goog.require('somens.foo') to invoke document.write at document.body it wil refuse because first goog.require must introduced before document.ready
when you add at require before document.ready
<script src="public/main.out/goog/base.js"></script>
<script src="public/main.out/goog/deps.js"></script>
<!-- others js -->
<script>goog.require("somens.foo");</script>

then you eval then you eval in REPL `goog.require('somens.bar') it will ok and output null and the dependencies scripts is not there meaning not loaded
namespaces to path ns->path foo.bar mean foo/bar.js right?
based relative to base.js  http://<<server>>/goog/base.js
goog.require('foo.bar') => eval load_script("foo/bar.js") =>  http://<<server>>/foo/bar.js
the idea of goog.require is to ensure dependencies is there
i come along this issue when using clojurescript
i cannot use goog.module because cljs generated google-closure
in cljs when you declare namespaces (ns foo.bar) it would produce
goog.provide('foo.bar')   -> produce global code
goog.require('cljs.core') -> ensure core loaded
in es6
goog.module --> ensure loaded as module es6 -> translated into goog.loadModule((exports)=> )
i think the issue was seperate each other, es6 has its own mechanism of async code loading and plain es5 must have its own instead document.write
and hopefully there is no dinosours in goog.require ;-)

Although all of this are not necessarily
when compilation bundle is advanced.
this is to support other user that develop code incrementally
lets define whats is interactive and dynamic development (not dynamic loading, i think we had already dynamic loading)

interactive mean incrementall evaluation
dynamic mean reintroduce new code in runtime without long compiling code again

what i do was just connect to browser REPL with editor and then start evaluating code there (changing things and live patching there)
interactive mean we evaluate code from repl and sends it through the evaluation envionment [browser/nodejs]
when you have ES6 REPL it mean you [type ES6 code] --> [transform to es5] --> [browser understand es5 then evaluate it ]
when you have cljs repl [write cljs code] --> [transform to es5] -> [browser understand that] -> [evaluate inside the browser]
long compilation can be skipped by just translating what necesarly to load in browser or in nodejs
yes future is must asynchronously and also future development should be supported
future development is when you connected to your creations and changes things inside but to do that at the compensate you must build it onces, once it compiled load it in evironment
connected:
[compile] -> [evaluated dynamicly]
common approach:
[compile es6] -> [changes] -> [reload] -> [compile again] -> [reload]
goog.require need its own asynchronous loading not necesarly like es6 debug loader (nb: i think this is theissue too in es6 world when the code must be compiled to understand it)
we just dont do document.write!! maybe replace it by head.write!! or xhr.eval in dev-mode google-compiler
if we call in cljs (require '[cljsjs.react]) => it will translated and function call (loadScirpt "cljsjs/react.js")
when we call it again and again incrementally  (require '[cljsjs.react]) (require '[cljsjs.react]) => loadScript is skipped because its already there
but when you have document.write it will have side effects that it will keep adding to the document.body
we can actually make it pure by remove previous same script.src and add again with document.parrent.removeChild
the issue is small and tiny fix, replace document.write with somethings else in dev mode , in production advanced compilation they all bundled
can we reopen the case maybe others will have same issue and have difference perspective?

It sounds like you're saying you're not actually interested in late loading, per se, but that for some reason you still need to do your initial code loading after document.ready.
I agree that we want to support the case of loading uncompiled code directly in the browser without a long compilation step.  Where you're losing me is that I don't understand why this doesn't work for you.  I think you're saying it has to do with wanting to use goog.require for "live patching", i.e. replacing (a subset of) JS implementation in place without reloading the entire HTML.
I understand that there are Chrome developer tools to do this, but have never looked into how they work.  I'm not sure that goog.require is appropriate for this - for example, and already-existing instances of old classes will no longer be instanceof the new replaced version of the same class - you need some deep browser integration to make that work right.
Or am I still misunderstanding what you're trying to do?
I don't know the complete history, but my understanding is that we use document.write for a reason - specifically, we need to work in CSP contexts where eval is not allowed.  So simply replacing one for the other is a non-starter.  Maybe there's a way for you to switch into the eval mode using the already existing infrastructure?

I also meet the similar issue. My application FOO is post loading another script (BAR.js) which uses goog.require() to acquire all its dependencies. The BAR.js is unknown before FOO's onload event. Since goog.require() is using document.write after pageload, it wipes out the entire DOM.
I'm looking for a way to avoid this. Maybe some parameter for goog.require() to append dependencies as

TL;DR: I think you might be able to get what you need by bootstrapping the following before loading base.js:
var CLOSURE_DEFINES = {'goog.ENABLE_CHROME_APP_SAFE_SCRIPT_LOADING': true};

Would you mind trying that out?
Longer story:
I find the following in base.js:
/**
 * @define {boolean} Whether to use a Chrome app CSP-compliant method for
 *     loading scripts via goog.require. @see appendScriptSrcNode_.
 */
goog.define('goog.ENABLE_CHROME_APP_SAFE_SCRIPT_LOADING', false);

  /**
   * Appends a new script node to the DOM using a CSP-compliant mechanism. This
   * method exists as a fallback for document.write (which is not allowed in a
   * strict CSP context, e.g., Chrome apps).
   *
   * NOTE: This method is not analogous to using document.write to insert a
   * <script> tag; specifically, the user agent will execute a script added by
   * document.write immediately after the current script block finishes
   * executing, whereas the DOM-appended script node will not be executed until
   * the entire document is parsed and executed. That is to say, this script is
   * added to the end of the script execution queue.
   *
   * The page must not attempt to call goog.required entities until after the
   * document has loaded, e.g., in or after the window.onload callback.
   *
   * @param {string} src The script URL.
   * @private
   */
goog.appendScriptSrcNode_ = function(src) {
    /** @type {Document} */
    var doc = goog.global.document;
    var scriptEl =
        /** @type {HTMLScriptElement} */ (doc.createElement('script'));
    scriptEl.type = 'text/javascript';
    scriptEl.src = src;
    scriptEl.defer = false;
    scriptEl.async = false;
    doc.head.appendChild(scriptEl);
  };

  /**
   * The default implementation of the import function. Writes a script tag to
   * import the script.
   *
   * @param {string} src The script url.
   * @param {string=} opt_sourceText The optionally source text to evaluate
   * @return {boolean} True if the script was imported, false otherwise.
   * @private
   */
  goog.writeScriptTag_ = function(src, opt_sourceText) {
    if (goog.inHtmlDocument_()) {
      /** @type {!HTMLDocument} */
      var doc = goog.global.document;

      // If the user tries to require a new symbol after document load,
      // something has gone terribly wrong. Doing a document.write would
      // wipe out the page. This does not apply to the CSP-compliant method
      // of writing script tags.
      if (!goog.ENABLE_CHROME_APP_SAFE_SCRIPT_LOADING &&
          doc.readyState == 'complete') {
        // Certain test frameworks load base.js multiple times, which tries
        // to write deps.js each time. If that happens, just fail silently.
        // These frameworks wipe the page between each load of base.js, so this
        // is OK.
        var isDeps = /\bdeps.js$/.test(src);
        if (isDeps) {
          return false;
        } else {
          throw new Error('Cannot write "' + src + '" after document load');
        }
      }

      if (opt_sourceText === undefined) {
        if (!goog.IS_OLD_IE_) {
          if (goog.ENABLE_CHROME_APP_SAFE_SCRIPT_LOADING) {
            goog.appendScriptSrcNode_(src); // uses document.appendChild
          } else {
            goog.writeScriptSrcNode_(src); // uses document.write
          }
        } else {
          // ... old IE code here ...
        }
      } else {
        doc.write(
            '<script type="text/javascript">' +
            goog.protectScriptTag_(opt_sourceText) + '</' +
            'script>');
      }
      return true;
    } else {
      return false;
    }
  };

So from this it looks to me that enabling this define should switch you to the codepath you need.  Potentially it's still missing some way to hook into a callback once it's loaded (though that can be worked around in your loaded script if necessary)?

@shicks Yes. It works! Thank you!

Marking this as closed.


"nm" field in test entry

Hi
as for the test entry I see the following fields:
    "nm": {
      "description": "NAA Test Name",
      "type": "string"
    },
    "ma": {
      "description": "RAT Test name and manufacturer",
      "$ref": "#/$defs/test-manf"
    }

The Annex reports this fields as following:
(e) test name (optional for NAAT test);
(f) test manufacturer (optional for NAAT test);
From my understanding, the NAA Test are always considered valid for generating a DGC.
So is the "nm" field really necessary?

Hi,
not sure if I understand your question, so let me summarize the position with respect to NAAT and see if that helps / answers your question. If not, please feel to clarify.
Correct that test name, test manufacturer are optional for NAAT test, as per Annex in https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52021PC0130
So for NAAT, you are not required to provide them.
In DGC.Types.schema.json we have:
    "test_entry": {
      "description": "Test Entry",
      "required": [
        "tg",
        "tt",
        "sc",
        "tr",
        "tc",
        "co",
        "is",
        "ci"
      ],

Where [nm, ma] are not required st JSON schema level, precisely for this reason.
Conversely, they are required for non-NAAT.
These kinds of things are difficult to model in a JSON schema (although I guess never impossible...). This is where the processing stage for business rules comes in very useful, since "test name / test manf not required for NAAT" is essentially a business rule for generation / issuance as well as for verification. These kinds of rules can be easily incorporated into code in the business rules processing stage see e.g. https://github.com/ehn-digital-green-development/ehn-dgc-schema/wiki/FAQ#what-do-the-typical-processing-stages-look-like-for

Hi
I will try to clarify a bit on my question.
The "nm" field is not associated with a value set in the current stable schema version and it is optional, as stated in the Annex.
So for now we decide to not include the nm field value in the DGC JSON data.
But since the field is still included (although optional) in the JSON schema, I am wondering if this choice will result in possible issues when MS business rules will be in place in order to validate DGC.

Since "nm" and "ma" are required for non-NAAT tests, somebody should add those fields to the test RAT example.
https://github.com/ehn-digital-green-development/ehn-dgc-schema/blob/main/examples/test-rat.json

Since "nm" is required for non-NAAT tests, somebody should add nm to the test RAT example.

#58

Hi
I will try to clarify a bit on my question.
The "nm" field is not associated with a value set in the current stable schema version and it is optional, as stated in the Annex.
So for now we decide to not include the nm field value in the DGC JSON data.
But since the field is still included (although optional) in the JSON schema, I am wondering if this choice will result in possible issues when MS business rules will be in place in order to validate DGC.

Thanks for the clarification to your question.

Issuance:

If all you are using are NAAT tests, you do not need to complete nm, ma fields (but can, if you wish to - they are optional)
if you have tests other than NAAT, you are required to complete nm, ma fields

Verification

if the test is NAAT you do not need to validate nm, ma fields (but can, if you wish to - they are optional)
if the test is not NAAT, then the fields nm, ma shall be present

HTH

Ok I see now maybe was my misunderstanding about this part:
"nm": {
"description": "NAA Test Name",
"type": "string"
},
My interpretation of description was that "nm" field was only for NAA test.
From my point of view this should be corrected into
"nm": {
"description": " Test name, optional for NAA Test",
"type": "string"
},
I think it is a minor issue but I am writing this down just to make sure my interpretation is correct.

From my point of view this should be corrected into
"nm": {
"description": " Test name, optional for NAA Test",
"type": "string"
},
I think it is a minor issue but I am writing this down just to make sure my interpretation is correct.

Ah, I see - and yes I agree with you, I will clarify the text - nice suggestion, thanks.

Debate still on-going on this one!
I think we can simplify things a lot for implementers by just having one key-value reference in the DCC, and then all the other text outside of that in the valueset. I will suggest this - and hopefully resolve this (at least for the implementers side of things) once and for all

See also: https://github.com/ehn-dcc-development/ehn-dcc-schema/pull/93#issuecomment-856283620

Closing this one as test manf / name clarified in the up-coming v1.3.0


iOS 7

Hey folks, thanks a bunch for this its been super useful.
Just wondering what I need to do to get this working with iOS 7?
After SSPullToRefresh finishes loading it seems to mess with (reduces?) the height of the scrollView.

@nickynick I see the issue @mariussoutier mentioned still exists even after I use it in -viewDidLayoutSubViews Any solution for this?


performance not available

The performance is not always available, such as in the Next.js environment. I created a fix to only use it when necessary.
https://github.com/belladoreai/llama-tokenizer-js/pull/7

Thank you for spotting the issue and thank you for writing the fix!

Your fix is now released in v1.1.2


Figure out the diff of the code between the code on the repo and the code on the vehicle

Figure out this diff
Check out whether we have lost any changes.
Get the repo to the latest Repo HEAD on the default branch.

Find the diff at https://github.com/auviitkgp/kraken_3.0/compare/indigo-devel...icyflame:niot-march !
Closing issue.


--disable-netbeans prevents signs from being overwritten

When built with --disable-netbeans (via ./configure) the following will not update the first sign:
sign define neomake_file_err texthl=NeomakeErrorSign text=✖
sign define neomake_project_info texthl=NeomakeInfoSign text=ℹ

sign place 5001 line=1 name=neomake_file_err buffer=1
sign place 5000 line=1 name=neomake_project_info buffer=1

It is listed in sign place, but the order is different from when not using --disable-netbeans.

That happens because if FEAT_NETBEANS_INTG is not defined, than the signlist struct does not have a previous pointer, so the re-ordering of signs done in insert_sign is not performed. (Also have a look at the comments there).
Also I wonder why id can be negative if FEAT_NETBEANS_INTG is not defined.
Perhaps we could simplify the code a bit and remove some of those ifdefs:
diff --git a/src/buffer.c b/src/buffer.c
index 0bf6aa912..fb85c2d26 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -5856,11 +5856,9 @@ insert_sign(
        newsign->lnum = lnum;
        newsign->typenr = typenr;
        newsign->next = next;
-#ifdef FEAT_NETBEANS_INTG
        newsign->prev = prev;
        if (next != NULL)
            next->prev = newsign;
-#endif

        if (prev == NULL)
        {
@@ -5905,38 +5903,25 @@ buf_addsign(
            sign->typenr = typenr;
            return;
        }
-       else if (
-#ifndef FEAT_NETBEANS_INTG  /* keep signs sorted by lnum */
-                  id < 0 &&
-#endif
-                            lnum < sign->lnum)
+       else if (lnum < sign->lnum)
        {
-#ifdef FEAT_NETBEANS_INTG /* insert new sign at head of list for this lnum */
-           /* XXX - GRP: Is this because of sign slide problem? Or is it
-            * really needed? Or is it because we allow multiple signs per
-            * line? If so, should I add that feature to FEAT_SIGNS?
-            */
            while (prev != NULL && prev->lnum == lnum)
                prev = prev->prev;
            if (prev == NULL)
                sign = buf->b_signlist;
            else
                sign = prev->next;
-#endif
            insert_sign(buf, prev, sign, id, lnum, typenr);
            return;
        }
        prev = sign;
     }
-#ifdef FEAT_NETBEANS_INTG /* insert new sign at head of list for this lnum */
-    /* XXX - GRP: See previous comment */
     while (prev != NULL && prev->lnum == lnum)
        prev = prev->prev;
     if (prev == NULL)
        sign = buf->b_signlist;
     else
        sign = prev->next;
-#endif
     insert_sign(buf, prev, sign, id, lnum, typenr);

     return;
@@ -6008,10 +5993,8 @@ buf_delsign(
        if (sign->id == id)
        {
            *lastp = next;
-#ifdef FEAT_NETBEANS_INTG
            if (next != NULL)
                next->prev = sign->prev;
-#endif
            lnum = sign->lnum;
            vim_free(sign);
            break;
diff --git a/src/structs.h b/src/structs.h
index f978f61b7..3c2bf3f1b 100644
--- a/src/structs.h
+++ b/src/structs.h
@@ -704,9 +704,7 @@ struct signlist
     linenr_T   lnum;           /* line number which has this sign */
     int                typenr;         /* typenr of sign */
     signlist_T *next;          /* next signlist entry */
-# ifdef FEAT_NETBEANS_INTG
     signlist_T  *prev;         /* previous entry -- for easy reordering */
-# endif
 };

 /* type argument for buf_getsigntype() */

Fixed in https://github.com/vim/vim/commit/8aeb504fc.