Update weave-kube installation instructions to leverage Launch Generator

Changelog:
The current Kubernetes YAML for weave-kube

is static, which forces people to manually edit the file in order to customise it, to add environment variables, etc. and
exists in two versions, one for Kubernetes v1.5, and one for v1.6 and above, which forces users to make choices about how they install weave-kube, hence increasing mental burden.

The latest version of the Launch Generator supports, among others:

passing additional options, arguments, and environment variables (weaveworks/launch-generator#66), which addresses 1. above;
passing the output of kubectl version to automatically extract Kubernetes' "server version" and return appropriate YAML configuration (weaveworks/launch-generator#79) without having users to care about it, which addresses 2. above.

Related work:

weaveworks/launch-generator#66
weaveworks/launch-generator#79
weaveworks/launch-generator#88
weaveworks/launch-generator#91

This PR and the above ones:

fix weaveworks/launch-generator#43
fix #2754

cc: @errordeveloper

Closing as not following naming conventions.


accuracy is much lower

when I convert the voc101 model to pytorch version , I test on VOC2012 val.txt, but the mean IoU is 79.6% , much lower than the author given which is 85.41%， is there any other details I ignored

Hi, @luhc15 , I'm also trying to use these codes in voc dataset, could you please share your test codes? Thanks a lot!

Hi guys. I've never evaluated my converted model. One thing I found is that mean values in demo.py are incorrect; slightly different from the ones given by the authors. For precise evaluation, please refer to the original Matlab code in the link below and the Section 5.3 "PASCAL VOC 2012" in the paper. Have you already tried multi scale testing?
https://github.com/hszhao/PSPNet/blob/master/evaluation/eval_all.m#L59


6.4.x fix for sample projects

This fixes the following bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1275167
https://issues.jboss.org/browse/DROOLS-1145
Also simplified user interface, and added ability to download a complete runtime from downloads.jboss.org

Reworking after discussions with Kris. Closing this PR, expect a new one shortly.


Random crashing

Hi, i just updated to the latest version (as of 17 hrs ago) and it randomly crashes FF for me. I tried with both textools and without and it crashes both instances
I attached the log when the error window popped out
XivAlexander_20211226_202848_231.log

The error looks like something about DirectX 11, which XivAlexander doesn't touch at all. Can you try disabling all other plugins, including Dalamud?

I will give it a try and get back to you :D

Hi would just like to update:
So far I let the game run for an hour, didnt crash even once, so it's probably something with Dalamud
Thank you for the assistance! I'll update again if it'll crash


migration of dimensions of NLM records

The NLM records contain dimensions without unit, we should migrate it but we must be clear on the unit that's used in the records first. @karmagongde do you know what unit is used in the dimensions field of the NLM records? is it cm or in?

The dimensions measured in NLM records are inches.

ok thanks


[Constructor]: missing possibility to set base values via contructor

I am missing the possibility to easily set up the main LCD settings via constructor, like:
// constructor with address, cols, rows
SerLCD lcd(0x72, 20, 4);
or
SerLCD lcd(0x72, 16, 2);
so this would be great to initialize the display directly with the main settings.

I don't fully understand what you are suggesting, The display width and lines are set at the factory (SparkFun) by the firmware that runs on the actual display, not by this library.
Passing the address in the constructor is fine, but we almost always pass it in the begin function along side the Wire port so I won't be breaking that standard on this library.

Hi,
ok that sounds fine I didn‘t catch that the cols and rows are set by the firmware.
Cool so my issue is obsolete 😀


Resource can't publish because of empty physical metadata block

This block of EML causes issues:
<physical>
    <objectName></objectName>
    <characterEncoding></characterEncoding>
    <dataFormat>
        <externallyDefinedFormat>
            <formatName></formatName>
        </externallyDefinedFormat>
    </dataFormat>
    <distribution>
        <online>
            <url function="download"></url>
        </online>
    </distribution>
</physical>

it fails publishing during EML validation

Happened to this resource https://cloud.gbif.org/uy/resource?r=listas_rojas_fauna_uy
reported by @leo-buitrago


Fix bad package names in generated documentation

Fixes incorrect qualified path name building for relative package imports,
Instead of doing the relative path in relation to the package we were in,
it did it based on the base of the program.
So for example instead of getting
"semver/version"
or an equiv
"semver/test/version/../../version"
You'd end up with
"semver/../../version"

Hi @SeanTAllen,
The changelog - fixed label was added to this pull request; all PRs with a changelog label need to have release notes included as part of the PR. If you haven't added release notes already, please do.
Release notes are added by creating a uniquely named file in the .release-notes directory. We suggest you call the file 3700.md to match the number of this pull request.
The basic format of the release notes (using markdown) should be:
## Title

End user description of changes, why it's important,
problems it solves etc.

If a breaking change, make sure to include 1 or more
examples what code would look like prior to this change
and how to update it to work after this change.

Thanks.

Hi @SeanTAllen,
The changelog - fixed label was added to this pull request; all PRs with a changelog label need to have release notes included as part of the PR. If you haven't added release notes already, please do.
Release notes are added by creating a uniquely named file in the .release-notes directory. We suggest you call the file 3700.md to match the number of this pull request.
The basic format of the release notes (using markdown) should be:
## Title

End user description of changes, why it's important,
problems it solves etc.

If a breaking change, make sure to include 1 or more
examples what code would look like prior to this change
and how to update it to work after this change.

Thanks.


set raft store capacity

set raft store capacity casue pd will stop to schedule when disk space is low

/run-all-tests


Feature/rewrite unit tests

Removed mockery and now all tests rely completely on PHPUnit, as per #8

No, wrong destination branch.


Openssl/vendored feature for perseus-cli

To be clear, does this solve the problem because there's some dependency that uses openssl, and adding a direct dependency on it with this feature causes everything to work out?

By default reqwest will use system-native transport layer, and the default for linux is openssl (as per reqwest). Features are additive so having this as an optional dependency will enable that feature for the crates that do use it. In my case, inside a docker container, the cargo install perseus-cli was not working because of openssl (I got the libssl-dev files, and set the enviroment variables), and with making it vendored it was working

Perfect, that's what I thought, just wanted toale sure I understand. Because it's a bit obscure for developers new to Rust, do you want to add a little comment explaining that?

The openssl vendored feature, make it build openssl from source like the scripts/build_openssh_musl.sh but correct way. Instead relying on libssl-dev package, when on xxxx-unknown-linux-gnu detected correctly, it more complicated on musl target.

@iRaiko did you want to add that explanatory comment?


Can we mutate userdata entry inside a JS invoked function?

@SkylerLipthay Hi! Is there a way to set userdata inside a JS invoked function. Thanks
fn set_name(inv: Invocation) -> Result<Value, DuccError>{
    let this = inv.this.as_object().unwrap();
    let engine = inv.ducc;

    engine.set_user_data("name", "Ducc Rocks!");
    //Compile error here: cannot borrow `*engine` as mutable, as it is behind a `&` reference

    return Ok(Value::Boolean(true));
}

Unfortunately it's necessary to keep the borrow rules as they are, but you can work around this by using interior mutability:
use std::cell::RefCell;
ducc.set_user_data("name", RefCell::new("abc123".to_string()));
// Later in a function:
inv.ducc.get_user_data("name").unwrap().replace_with(|string| string.push_str("def456"));

Do you think this pattern can work for you?

Thank you for the quick response, i tried it, i get the following error
cannot infer type for type parameter T declared on the associated function get_user_data
also would this be possible if the user data was a Hashmap too?

Oh, use get_user_data::<RefCell<String>>. Yes, you can use this pattern with any sort of data.
You can learn more about interior mutability from the Rust book, where they have a complex example of using a RefCell<Vec<String>>. Which is perhaps similar to your use case with the HashMap.

Thanks a ton! This works! :-)


add cors profile

This PR helps simplify CORS setup when running IPFS in Docker.
ipfs daemon --init-profile=cors

go-ipfs-config got merged into go-ipfs repo: https://github.com/ipfs/go-ipfs/tree/master/config
If you feel this PR is still relevant, please reopen as a PR against go-ipfs


Feature request: Environment variables for msys2 root in Windows environment with Windows path-syntax

Hi,
I am trying to make cmake find-modules find libraries installed in the mingw32/64 tree, and I would like to do it in a way that a cmake running directly under Windows can also find them. Them mingw32/bin, lib etc folders I presume can be relied upon as hardcoded path elements, but the msys root folder and Win-drive could be called almost anything, right? Wouldn't it be useful to have a Windows system env variable that returns the msys root path? Or is there somethink like that?

Having cmake pick up msys2 libraries and headers would not be wanted when building mingw?? software (and vice versa). Am I misunderstanding you?

Sorry, my question must be put confusing. I want cmake to (optionally) pick up libraries and headers stored in the mingw-tree (which is a subfolder of the msys2 root) in order to build another application alltogether. This app I would like to have the option to build outside of msys. So it's not msys libraries I want, but "native windows" ones stored in the mingw folders.
So to give a specific example: build an application called supercollider with cmake, that depends on libraries and headers from libsndfile, portaudio, fftw and readline. Using cmake I can build supercollider outside of msys (I think), but it would be helpful if I could address the locations of the libraries with variables returning specifics of a users msys2 install. One user might have the libsndfile-1.dll in G:\msys64\mingw32\bin, another one in C:\msys\mingw32\bin. That first part of the path I would like to read from an environment variable.

Our mingw-w64 compilers search in the /mingw??/lib and mingw??/include paths already and cmake queries gcc for those paths. The only use case for what you are asking for seems to be if you are using non-MSYS2 supplied mingw-w64 compilers but wanting to link to MSYS2's mingw-w64 libraries. This is a bad idea for various compatibility reasons so isn't something we should do anything to support .. Again if I'm still missing something here let me know.

cmake doesn't need to concern itself with msys2 paths since msys2 converts the paths to windows form before cmake sees them.. Usually!

As to your second statement: well, that's true if compiling from inside the msys environment. My wish would be to be able to use the mingw toolchain, and all packages stored inside the mingw tree to build from outside the msys environment. This could be cmake on the win-command line or Qt Creator running outside of msys, but using the mingw-toolchain provided by you.
So a use case that I think would make sense for my request: msys2, next to providing a unixish environment for unix build tools, and a Windows gcc-toolchain, also provides a package manager for native Windows apps that are build with that toolchain, right? In my case I need msys2 to build portaudio, because it cannot be built with cmake easily. But for the other dependencies it is enough for me to use mingw as a toolchain and libraries/packages repository... So I could actually build outside of msys, right? While the mingw-toolchain knows itself where it's libraries are, cmake doesn't automatically know where to find packages like libsndfile and portaudio. Am I overlooking something?

If you're using cmake from mingw??, it should be able to find everything.
Anyway, one problem with your proposition -- users can have multiple independent MSYS2 roots. Your build script/system should probably require users to specify the path to the sysroot manually (but in an easy-to-understand way).

If you're using cmake from mingw??, it should be able to find everything.

That's an interesting suggestion, thanks! I could define the library paths relative to the cmake binary location then (there is a cmake variable for this). But I see two problems: people trying their luck with cmake installed under Windows will run into trouble. And I'd have to add mingw??/bin to the system path, which seems like more hassle and problem prone than defining a sysroot manually.

users can have multiple independent MSYS2 roots.

Ah, true, but maybe a corner case? Each install could overwrite the old variable, so only the last one is automatic. Users that can handle multiple msys2 installs wouldn't be too challenged with the requirement to define the variable value manually, I think. I am more concerned of users that dare to enter the field of building since there now is a very convenient build system...

Rethinking the set the path requirement: maybe that's a strong reason not to encourage building from outside msys. So maybe not a good idea... ;) Should I close the issue?

Generally speaking, MSYS2 aims to work as well as possible without any requirement to add anything to your system's PATH variable.
However for us to have any chance of making this work (and in general for MSYS2 software to interoperate correctly), we need to modify various bits of software so that for example relative paths are used. Therefore using non-MSYS2 versions of software (for example cmake and qt creator) will never be something we make significant efforts to support. If said software is missing from MSYS2 then we'll add it or welcome contributions that do that, if it's software we already package then the user will be required to use our version unless they can strongly justify not doing so. I can't imagine any valid reason not to at present.
Having said that, launching MSYS2 software (both msys2 and mingw?? stuff) from outside msys2_shell.bat and mingw??_shell.bat is something we do support as much as is reasonable.
So for example you should be able to run our CMake from cmd.exe, generating mingw Makefiles and then be able to use mingw32_make.exe from the same cmd.exe to build the thing, both without modifying PATH. At that stage the user might need to identify a toolchain file to CMake but that's standard CMake usage procedure anyway.
Qt Creator is a little more tricky though because the qt concept of 'Kits' IMHO needs to include the ability to modify the build and run environments similarly to how the Project settings page does.

Thanks a lot for the well considered and friendly comments in this thread! A nice community!

Generally speaking, when I use MSYS2 stuff from within cmd.exe first I'll do:
set "PATH=C:\msys64\mingw64\bin;%PATH%"
.. then execute what I want.
That way, for example, cmake finds GCC without further prompting.

Yea, my last suggestion was to offer a shell that does that automatically, and add a env variable that allows to derive the mingw sysroot independently of the msys install location. That way one could write cmake find modules easily in a way that a user could configure/compile with cmake without having to specify any paths. So compiling would boil down to cmake .. and cmake --build . --config debug --target install, all of which is easy to memorize and makes sense. Writing a toolchain file or specifying 5 paths to libraries is very error prone and turns away people...
But it's not a big deal, I admit, and I understand that a msys centered project has more important things to do than make msys obsolete (no sarcasm meant!!) ;)

Just another word to confirm that @elieux is right and my assumption was wrong:
If you build in a Windows command line with cmake, using msys2-provided mingw-cmake, it does in fact back-convert the unix-style paths provided in find-modules to Windows paths (well, maybe it doesn't, but it finds modules at a path that is syntactically incorrect on a Windows command line). So as lang as we are willing to use mingw-cmake everything is fine. I have two versions of cmake installed on my system (using the Win one for VS) just separated by the order in the path :) So far I have not met any problem with this. Very nice!


store.Options does not expose its props, making StoreInterface challenging to implement

Steps for Reproduction
The docs suggest that the dev can use a custom store by implementing the StoreInterface. I'm working on a custom cache to use as part of the library's chain cache but one sticking point is the Set.  Here is its definition:
Set(ctx context.Context, key any, value any, options ...Option) error

Option is a function that takes and configures an Options object, both from the library package.  here is how the library passes it to my cache's setter: github
Within the library's cache implementations, the configured Options object is then read to discern, for example, the expiration date of the cache entry: example
The issue I face is that Options (declared here) makes all its properties private, so when I implement my own Set(), I have no way to read it to figure out when the cached entry should expire.
How is my custom StoreInterface implementation supposed to figure out the caching options used?
Expected behavior:
Custom struct implementing StoreInterface can be used in the chain cache
Actual behavior:
Unable to implement interface correctly because the Options object passed to my implementation does not expose the options in public properties
Platforms:
All
Versions:
v3.1.1

I cloned to open a PR and noticed that this has been fixed in the master branch.  However it hasn't been released yet (v3.1.2 has the same issue).  Is there a plan to release this change?

Feel free to close the issue unless you have something to add.  If upgrading to v4 is what I'll do.

Hi @RoxKilly,
Sorry about the delay but yes, the actual fix has been done into the v4 release.
If you really need it, I can add the fix in v3 and make a new patch release.
I close this issue for now but feel free to reopen and tag me if you need it.


When user clicks on column to sort and then different column to sort goes back to clicking original column should go back to sorting by the default option.

When user clicks on a column to sort and then a different column to sort and then goes back to the original column it should go back to sorting to the default option (as though it was the first click on the column: ascending) instead of desc (unless order-by-desc tag is used). Currently it doesn't
Not necessarily a bug; but an implementation that makes more sense.
Implementation should be changed to this:
https://streamable.com/sl349w

Implemented in commit: 691f82b4fd2d6817a59ef76288ee76074dc00d52


Less strict code of the TinylogLoggingProvider #168.

Description
Implementation of the changes discussed in issue #168.

Moved the writer generation code from ConfigurationParser into the non static, non final class TinylogLoggingConfiguration to allow other providers to use it.
Moved commonly useful methods like log entry handling from TinylogLoggingProvider into the non static, non final class TinylogLoggingConfiguration
Contrary to the initial suggestion did not change the static code of ConfigurationParser as it now just calls static methods of Configuration. So static is ok.
Some smaller methods are kept in TinylogLoggingProvider (like level calculation) as this will be used inside the logging write  itself and might affect the performance (all other changes are constructor only changes). Can be discussed but I think it is ok to keep it in its original place.
Added new unit tests to cover these changes
It could be discussed as idea (but I decided not to follow it for the moment) to put other access function to Configuration elements (e.g. filename) which is done by the writers constructors or support methods into ConfigurationParser  as the parser now more or less translates string elements of Configuration  into method getters. Similar functions might be getFilename()  and alike from the writers. I did not follow this up as it can also be argued that there is not so much common or usefull stuff to justify it and the writers know themself best what they are doing. So here just as possibility.

As result you can now more easily duplicate/write an own logging provider with similar functionality to TinylogLoggingProvider and use the helper functions from TinylogLoggingConfiguration. Much less code duplication is now needed.
Linked issue: #168
Definition of Done

[x] There are no TODOs left in the code
[x] Code style follows the tinylog standard
[x] All classes and methods have Javadoc
[x] Changes are covered by JUnit tests including corner cases, errors, and exception handling
[x] Maven build works including compiling, tests, and checks (mvn verify)
[x] Changes are committed by a verified email address that is assigned to the GitHub account (https://github.com/settings/emails)

Documentation
Additions or amendments for the public documentation:
No changed to documentation.

Agreements

[x] I agree that my changes will be published under the terms of the Apache License 2.0
[x] I agree that my GitHub user name will be published in the release notes

About the javadoc: <javadocExecutable>${java.home}/bin/javadoc</javadocExecutable>
Maybe you can leave it in the pom file commented out or mention it in the compilation instruction. If a build does not work with a user, it is much harder to find  what command to add than to delete a command.

We need WritingThead visibility to be public not package to allow providers to use it ouside tinylogs core package.

Btw since we have now 3 instead of 2 commits ... :-) I will make another pull request if all is ok.

About the javadoc: <javadocExecutable>${java.home}/bin/javadoc</javadocExecutable> Maybe you can leave it in the pom file commented out or mention it in the compilation instruction. If a build does not work with a user, it is much harder to find what command to add than to delete a command.

I fully agree!

Btw since we have now 3 instead of 2 commits ... :-) I will make another pull request if all is ok.

Multiple commits are really no problem. There can be an unlimited number of commits in a single pull request. Actually, I prefer multiple small commits instead of a single big one. You don't need to create another pull request as long as all commits are about the same topic.

@Git5000 Is this pull request ready for review?

Yes it is ready. It is mainly the same files as in the other open pull request but without the merge commit and I fixed the five or six review comments which you had. The last commit is the public/private as discussed above. Mainly please have another look at the indenting whether that is ok now.

Thank you! Looks perfect :)


Features in feature collection might have different properties names

https://github.com/gee-community/geemap/blob/d58a2424d385ad756c00e279e545e1c1024146d4/geemap/common.py#L9136-L9139
I suggest not to limit the columns of the dataframe to be the properties of the first feature only, but to allow to have each feature with its original properties names:
I suggest:
            data = ee_object.map(
                lambda f: ee.Feature(None, f.toDictionary(f.propertyNames().sort()))
            )

This is not a very common user case. If every feature has different properties, it will result in a bloated data frame with a lot of columns.


tailwindcss-react-aria-components missing enabled: modifier

Provide a general summary of the feature here
enabled: is provided by tailwind as the opposite of disabled:. tailwindcss-react-aria-components overrides disabled: but not enabled:
🤔 Expected Behavior?
enabled: modifier works with RAC
😯 Current Behavior
enabled: modifier does not work with RAC
💁 Possible Solution
No response
🔦 Context
I want to style a Tab differently only when it is not disabled:
💻 Examples
No response
🧢 Your Company/Team
No response
🕷 Tracking Issue
No response

Currently, all states in the plugin map to specific render props, and we don't have one for enabled. I think [&:not([data-disabled])]: should work for this case though. We could add an enabled to the plugin that maps to that if we are ok diverging from 1:1 mappings to render props though.


Update to Selenium 4.6/4.7 causes compilation failure, .NET version

See PR #136. The cause is that Selenium introduced a new class called SeleniumManager that causes a duplicated class declaration. Solution: change name of the Selema SeleniumManager

Rename SeleniumManager to SeleManager 81534d5352773e91f1a831ec5a84172864260dfa


Allow string literals as segmentation modes

Fixes #243
In addition to SplitMode objects SudachiPy will now accept A, B, C string literals as well (in all places).
Split mode also gets a constructor that accepts string literal in addition to class members
Bonus fix: tokenization now releases GIL

@mh-northlander fixed!


add membrane peptide dataset

fix #34

[x] include data downloader including checksums
[x] description
[x] added to sphinx docs
[x] tests

Work in progress – see checkboxes.

The tests fail because somehow pip is installing incompatible versions of pytest and the pytest-cov plugin (same for 2.7 and 3.6)
pluggy.PluginValidationError: Plugin 'pytest_cov' could not be loaded: (pytest 3.3.0 (/home/travis/virtualenv/python2.7.14/lib/python2.7/site-packages), Requirement.parse('pytest>=3.6'))!

I also tried trashing the pip cache but nothing changed.

Tests run (yay!) but coverage now seems broken.

coverage seems broken but tests pass so I am going ahead...


doc: Bluetooth: Add broadcast assistant sample to audio stack status …

…table
Mark the broadcast assistant as having a sample application since that was recently implemented.

The sample is in 3.6-rc1, we should get this doc merged for v3.6 release, right?

The sample is in 3.6-rc1, we should get this doc merged for v3.6 release, right?

If possible, yes


Vscode Intillesense stop working because of Ramda

I want to export a function as curried and no curried function to an index.
( because I don't want to have to put null on those variables that I will not use. Ex: Using curring fn: fn(2,null,null), whitout curring: fn(2) )
The thing is that when I export those two functions in index.js vscode Intellisense stops working.
Example to reproduce the bug:
Project directories:

index.js
function.js

// function.js

import R from 'ramda';

const remove = (a, b) => {
    {  . . .  }
};

export { remove };

const curriedRemove = R.curry(remove);

export { curriedRemove };

// index.js

export * from './function'

For some reason, that will cause intellisense not to work.
If I remove the export line in index.js. intellisense will work (restarting vscode).

What happens if you take out
export { remove }
and change the last line to
export { remove, curriedRemove }?

@Bradcomp
Nop, still a issue. Intellisense freezes,

I don't have the same issue.  Of course I'm using a two-year old version of VS Code, so maybe something's changed.  I also had to turn back on most of the Intellisense features, as I can't personally stand all the supposed helpful hints, and only bring it up with an intentional action (CMD/CTRL-space).  But when I did that, it worked with or without those features.
What version of VS Code are you using?


jitsi-keycloak-adapter acts as an open redirect, allowing for JWT theft

Describe the bug
It appears oidc-adapter.html acts as an open redirect, as it seems to allow any value to appear in the path query parameter.
This parameter is normally set in a redirect by oidc-redirect.html.
In a targetted attack, a malicious website could use this to redirect users to a legitimate jitsi-keycloak-adapter instance with a path query parameter pointing to a server under their control.
jitsi-keycloak-adapter would then perform a completely normal and legitimate OIDC flow with keycloak, and then redirect back out to the attacker's website with a valid JWT as a query parameter.
This JWT:

contains user identity information (context field) – leaking PII
allows access to any authorised Jitsi instance protected by that jitsi-keycloak-adapter instance in any room for up to JWT_EXP_SECOND seconds (default: 1 hour), because jitsi-keycloak-adapter also does not limit the scope of any tokens it issues: #21

Steps To Reproduce
Note: this is from static analysis, because I haven't gotten Jitsi running yet.

Attacker sends users a link to https://jitsi.example.com/oidc/auth?path=https%3A//attacker.example.net/fakecall
This simulates oidc-redirect.html.

User opens the link.

Legitimate jitsi-keycloak-adapter redirects the request to Keycloak, with a redirect_uri via itself and that path query parameter pointing to the attacker's service.

User is authenticated with legitimate Keycloak (this may also happen automatically, if they have an open seession)

Keycloak redirects back to /static/oidc-adapter.html with any query parameters still set.

oidc-adapter.html makes a fetch() request to /oidc/tokenize to get a JWT from jitsi-keycloak-adapter.

jitsi-keycloak-adapter makes a UserInfo request to Keycloak to get user information, generate a JWT, and return it to the client as a JSON-encoded string.

oidc-adapter.html redirects the browser to the path query parameter (https://attacker.example.net/fakecall) with the JWT passed in the jwt query parameter.

Attacker now has user info and a JWT to use with Jitsi.

An attacker could then redirect the user to an actual Jitsi call with their JWT in tact, and the user will be none the wiser.
Expected behavior
It should not be possible to steal JWTs 😉

This adapter actually only partly works with recent versions of Jitsi. Since early summer 2024, after one of the regular apt updates of Jitsi on Debian, it actually stopped redirecting unauthorized users to the IDP for login. However, if a user already has an active authorized session with his IDP prior to visiting Jitsi meet, then that authorization also works for Jitsi.
In general, I always felt that eather Jitsi or this particular adapter authorization logic is somewhat fragile 😊

@micolous, thank you so much for detailed analyze.
I think it is fixed now:
https://github.com/nordeck/jitsi-keycloak-adapter/commit/d8b694507712135954cf42339af2824cab21bda6
https://github.com/nordeck/jitsi-keycloak-adapter/commit/61a78175ac154bcb4f523f7bdd6e4c151ba4fe3b
https://github.com/nordeck/jitsi-keycloak-adapter/commit/261a88676ec0e072a6a366562498f142c392f4db


Test against minimum and maxium versions of mysql and postgres

Right now, phinx is tested only against mysql 5.7 and postgres 9.6. The latest versions of mysql is 8.0 and postgres is 12.2. It would be good for Phinx to define what versions of databases it supports and to also test against the minimum and maximum of that range, especially given things like #1759 which showed that phinx users are going to encounter a breaking change if they move their database from 5.7 to 8.0 and rely on column widths for integers in some way. It would also be good for as I continue working on the geometry stuff for mysql 8, it gets tested continuously and not just skipped.
Proposed changes would be to expand the Travis-CI configuration to specify those versions, and to use Docker to spin-up containers for the given version. For example, for the currently specified versions, the run commands would look something like:
docker run --env MYSQL_DATABASE=phinx_testing --env MYSQL_ALLOW_EMPTY_PASSWORD=yes -p 3306:3306 mysql:5.7 --default-authentication-plugin=mysql_native_password --default-authentication-plugin=mysql_native_password
docker run --env POSTGRES_DB=phinx_testing -p 5432:5432 postgres:9.6

mysql8 container in travis has shown to be very slow. I recommend just copying the mysql8 github action from cakephp/cakephp to setup a single test environment.

So make a single github workflow for just mysql 8 and leave everything the way it is (in Travis and appveyor)? I'm really not sure what you're asking for here and in https://github.com/cakephp/phinx/pull/1759#issuecomment-625575279. Rewrite all CI stuff to just use GitHub actions?

I recommend just copying the mysql8 github action from cakephp/cakephp to setup a single test environment.
Sure, which uses docker with a similar command as I put above. Either way you slice it, docker here is the way to do mysql 8 regardless of platform.

Rewrite all CI stuff to just use GitHub actions?

I said the opposite. Just create the test you need.

Just need to create a single mysql 8 environment - not rewrite every test.


Add support for Leaflet.markercluster

We should support Leaflet.markercluster.
Either by documenting a way to use the plugin (similar to Leaflet.draw documentation) or providing Vue components.

Hey, as we were talking about, I made this implementation using @vue-leaflet/vue-leaflet and leaflet package :
Step 1 : I made a plugin to define everything you need :
// plugins/leaflet.client.ts
import {YourComponent} from '@vue-leaflet/vue-leaflet';
import * as L from 'leaflet';
import 'leaflet/dist/leaflet.css';
import 'leaflet.markercluster';
import 'leaflet.markercluster/dist/MarkerCluster.css';
import 'leaflet.markercluster/dist/MarkerCluster.Default.css';

export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.vueApp.component('YourComponent', YourComponent);

  return {
    provide: {
      L,
    },
  };
});

I had to provide L aswell.
Step 2 : In my component.
Note that I wrapped it with <client-only> as I had issues with SSR (which is sad when I see how much markers I have to put on my map).
<template>
  <l-map
     ref="map"
     :center="leafletOptions.center"
     :max-zoom="leafletOptions.maxZoom"
     :min-zoom="leafletOptions.minZoom"
     :options="{ tap: false }"
     :use-global-leaflet="true"
     :zoom="leafletOptions.zoom"
     :zoom-animation="true"
     @ready="onLeafletReady"
     >
       <template v-if="leafletReady">
         <l-tile-layer :url="leafletOptions.url" />
       </template>
  </l-map>
</template>

<script lang="ts" setup>
import * as L from 'leaflet';
import {MarkerClusterGroup} from 'leaflet.markercluster';
import {LMap, LTileLayer} from '@vue-leaflet/vue-leaflet';
import {isClient} from '@vueuse/shared';

const leafletReady = ref(false);
const leafletObject = ref();
const map = ref();

// Using it to be sure that the map is correctly instanciated, maybe there's a better way ?
const onLeafletReady = async () => {
  await nextTick();
  leafletObject.value = map.value;
  leafletReady.value = true;
};

/**
* The magic goes here,
* but I got a Typescript issue with the new MarkerClusterGroup().
*/
const createMarkers = async () => {
  const markerCluster =  new MarkerClusterGroup();

  let markers: any[] = [];

  const markerIcon = L.divIcon({
    className: 'location-marker',
    html: '<img src="/icons/location.svg" alt="">'
  });

  locations.value.forEach((location: any) => {
    const options = {title: location.nom, clickable: true, draggable: false, data: location, icon: markerIcon};

    // Just a regex check to ensure that I don't create a broken marker
    // (as it completely break the behavior of the whole map)
    if (checkCoordinates(location.lat, location.long)) {

      const marker = L.marker([location.lat, location.long], options);

      ... // just a bit of logic for my own purpose

      // I had my marker to the marker array then I add them as layer
      markers.push(marker);
      markerCluster.addLayers(markers);
    }
  });

  // Then I add the whole cluster layer to the map
  map.value.leafletObject.addLayer(markerCluster);
};

// I watch for leafletReady to create markers after, but as I said maybe there's a better way to do.
watch(leafletReady, async () => {
  if (isClient) {
    await createMarkers();
   ...
  }
});
</script>

And the result is :

But thing is I have some client issues due to this solution, You have to put a placeholder before the map completely load.

Reported type issue with leaflet.markercluster here
https://github.com/DefinitelyTyped/DefinitelyTyped/discussions/69707

Issue was closed to the branch being merged, but the feature isn't correctly working yet.
The following composable doesn't work in production :
import type { MarkerOptions, Map } from 'leaflet';

interface MarkerProps {
  name?: string;
  lat: number;
  lng: number;
  options?: MarkerOptions;
}

interface Props {
  leafletObject: Map;
  markers: MarkerProps[];
}

export const useMarkerCluster = async (props: Props) => {
  // Get Leaflet from the window object
  const L = window.L;

  // Lazy-load leaflet.markercluster
  // Importing it at the top level will cause errors because it could be loaded before the Leaflet library
  const { MarkerClusterGroup } = await import('leaflet.markercluster');

  // Initialize marker cluster
  const markerCluster =  new MarkerClusterGroup();

  // For each marker in props
  props.markers.forEach((location: any) => {
    // Create a Leaflet marker
    const marker = L.marker([location.lat, location.lng], {
      title: location.name,
      ...location.options,
    });

    // Add the marker to the cluster
    markerCluster.addLayer(marker);
  });

  // Add the marker cluster to the map
  props.leafletObject.addLayer(markerCluster);
}

For now, it shows TypeError: Cannot add property MarkerClusterGroup, object is not extensible in the browser console after accessing the map in production build.

Released in https://github.com/nuxt-modules/leaflet/releases/tag/1.1.0


Include proxychains in the image

https://github.com/haad/proxychains would be useful for forcing connections from tools that don't have http/socks proxy support built in to go via Tailscale. Golang's crypto/ssh library for one, as shown in #9.

Looks like proxychains-ng is the one to include https://github.com/rofl0r/proxychains-ng


FAQ: [Google/Android]: Error when communicating with Google API (39508) - update needed?

Where to find the issue
https://www.coronawarn.app/en/faq/#API39508
[Google/Android]: Error when communicating with Google API (39508)
Describe the issue
The app no longer outputs the error code 39508 any more. It puts out a text error instead:

"Limit already reached"

"No more exposure checks possible today, as you have reached the maximum number of checks per day defined by your operating system. Please check your risk status again tomorrow."
The whole exposure checking went through a major update with the release of 1.9.1 according to the blog post https://www.coronawarn.app/en/blog/2020-12-16-corona-warn-app-version-1-9/ from Dec 16, 2020.
There haven't been any more comments made to the issue https://github.com/corona-warn-app/cwa-app-android/issues/1459 for over 5 weeks.
Suggested change
Possibly change the FAQ to say fixed with 1.9.1 and close https://github.com/corona-warn-app/cwa-app-android/issues/1459.

Suggestion:
"
[Google/Android]: Limit already reached (Previously: Error when communicating with Google API (39508))
UPDATE 16.01.2021:
The notification reads now:
'Limit already reached
No more exposure checks possible today, as you have reached the maximum number of checks per day defined by your operating system. Please check your risk status again tomorrow.'
The whole exposure checking went through a major update with the release of 1.9.1, see also the blog post https://www.coronawarn.app/en/blog/2020-12-16-corona-warn-app-version-1-9/ from Dec 16, 2020, and since the release 1.9.1 no more reports on this issue have been submitted.
However, should you experience an issue related to this error notification, please submit your report here: corona-warn-app/cwa-app-android#1459.

... the remainder of the original FAQ entry
"

Suggestion:
"
[Google/Android]: Limit already reached (Previously: Error when communicating with Google API (39508))
UPDATE 16.01.2021:
The notification reads now:
'Limit already reached
No more exposure checks possible today, as you have reached the maximum number of checks per day defined by your operating system. Please check your risk status again tomorrow.'
The whole exposure checking went through a major update with the release of 1.9.1, see also the blog post https://www.coronawarn.app/en/blog/2020-12-16-corona-warn-app-version-1-9/ from Dec 16, 2020, and since the release 1.9.1 no more reports on this issue have been submitted.
However, should you experience an issue related to this error notification, please submit your report here: corona-warn-app/cwa-app-android#1459.

... the remainder of the original FAQ entry
"

@dsarkar
Since the error message has changed, maybe the title of issue https://github.com/corona-warn-app/cwa-app-android/issues/1459 needs to be changed as well, if the old errors, and any new errors are to be captured in the same issue? The title is currently:
"🔥 Error 39508 after updating to 1.5 or later"

Since it is not a hot issue any more, the hot issue icon should be removed from the title of https://github.com/corona-warn-app/cwa-app-android/issues/1459. It hasn't been using the hot issue label (as opposed to hot issue icon in the label) for a long time.
Change the title of https://github.com/corona-warn-app/cwa-app-android/issues/1459 to "Error 39508 / Limit already reached" or
Open a new placeholder issue for any new issues with the new error message "Limit already reached" and then link to the new issue.

@dsarkar
Since the error message has changed, maybe the title of issue https://github.com/corona-warn-app/cwa-app-android/issues/1459 needs to be changed as well, if the old errors, and any new errors are to be captured in the same issue? The title is currently:
"🔥 Error 39508 after updating to 1.5 or later"

Since it is not a hot issue any more, the hot issue icon should be removed from the title of https://github.com/corona-warn-app/cwa-app-android/issues/1459. It hasn't been using the hot issue label (as opposed to hot issue icon in the label) for a long time.
Change the title of https://github.com/corona-warn-app/cwa-app-android/issues/1459 to "Error 39508 / Limit already reached" or
Open a new placeholder issue for any new issues with the new error message "Limit already reached" and then link to the new issue.

@dsarkar
This issue has become a little up in the air.
https://www.coronawarn.app/en/faq/#API39508
[Google/Android]: Error when communicating with Google API (39508)
still says
"If you are still receiving the error after updating to 1.5 and waiting 24 hours, please report it in the associated GitHub issue".
However, the issue "Error 39508 / Limit already reached" https://github.com/corona-warn-app/cwa-app-android/issues/1459 has now been closed.

@MikeMcC399 Yes, indeed. I Will definitively try to clean up the website project board these days.

This issue was resolved by #895.


Should read $KUBECONFIG

While it provides an option for choosing the config file from the command line, I think it should support the same environment variable that kubectl does.

Same here.
I can't use it with my KUBECONFIG=.kubeconfig:${HOME}/.kube/config (use current project dir first, fall back to $HOME/.kube).


Assert that prepareCache returns a cache

I inadvertently changed the return value of prepareCache and no test caught the error.

We can add the assertion here: https://github.com/mozilla/oghliner/blob/a7d4c80684ecd8241f90dac5f52073105107057d/test/service-worker/testCacheSetup.js#L30


undocumented

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 77.56%. Comparing base (f9c1a38) to head (1974dcf).

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #89   +/-   ##
=======================================
  Coverage   77.56%   77.56%
=======================================
  Files          75       75
  Lines        8063     8063
=======================================
  Hits         6254     6254
  Misses       1809     1809

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


Gogs: init at 20160304-d57a2b9

The default.nix is generated using go2nix and applying a couple of patches to make the SQLite support configurable and wrapping the program.
Gogs behavior is a bit modified by the wrapper program because original Gogs is impure (it expects to be run only in its source Git repository and needs to be able to write files inside. To avoid this, I define the GOGS_WORK_DIR to be the CWD if not defined, and cd inside this directory before executing Gogs (if Gogs is not run from inside the GOGS_WORK_DIR, some parts still rely on the CWD to be the work directory).
Also the public and templates directories from the Go package directory are symlinked inside the work directory since Gogs expect them to be here.
This PR comes with a maintenance script, update-gogs-definition, that is basically doing an impure go get of chosen Gogs revision and its dependencies, and runs go2nix over this tree (plus some specific patches).
For information, I also have a WIP NixOS module integration for Gogs but I'll add it later, or in another PR, once I'm done with it.
Dependencies
I'm not sure about the way dependencies are handled here. It's plain go2nix but it's not making those dependencies shareable... but it would be a huge work to go through those 46 dependencies, and convert them in nixpkgs.goPackages format, see if they exist already and in a compatible version or add the definition, and requiring to manually recreate the dependency graph.
I'd really like some input about the manner to handle this.
Things done:

[x] Tested using sandboxing (nix-build --option build-use-chroot true or nix.useChroot on NixOS)
[x] Built on platform(s): NixOS

Builds on OSX but the update-gogs-definition script does not work because go get  on OSX in unable to verify the certificates of gopkg.in and I couldn't find a way to fix this.

[x] Tested execution of all binary files (usually in ./result/bin/)

Please properly name commit to follow our rules in CONTRIBUTING.md.

@jagajaga Thanks, updated.

I'm not too familiar with the go stuff, but why isn't this part of goPackages?
Also, the correct commit message would be gogs: init at 20160227

Oh sorry I didn't get it for the commit message. Updated.
About the goPackages, that's the doubt/question I have in the Dependencies part of my PR message; I used go2nix to generate this derivation but it makes a single derivation for the Gogs package and all its dependencies at an exact version merged together, instead of a shared dependencies tree like in goPackages. I'm aware of no tooling to do this yet, and doing it manually would take much time, both now and eveytime we update Gogs (compared to the current fully automated update-gogs-definition script).

Looks like a legit build failure:
# github.com/gogits/gogs/models
go/src/github.com/gogits/gogs/models/repo.go:374: cannot use true (type bool) as type git.PullRemoteOptions in argument to git.Pull
builder for ‘/nix/store/7bbw82k9zd4fibzgz7g9z22dy40ilxl1-go1.5-gogs-20160227-d320915.drv’ failed with exit code 44
error: build of ‘/nix/store/7bbw82k9zd4fibzgz7g9z22dy40ilxl1-go1.5-gogs-20160227-d320915.drv’ failed
The invocation of "nix-build -A gogs /home/travis/.nox/nixpkgs" failed

Oops right, thanks, related to https://github.com/gogits/gogs/issues/2728, I just updated Gogs and its dependencies.

Quick update of gogs-derivation.nix to remove usage of my fork of go2nix since #13741, #13564, and #13533 are merged.

@valeriangalliat see new go2nix from master and how i rework goPackages in https://github.com/NixOS/nixpkgs/pull/16017

@valeriangalliat ping

Thanks a lot @kamilchm, I updated the PR to use new go2nix generated default.nix and deps.json.
I can't build it though:
stripping (with flags -S) in /nix/store/wca3v40cfbrman7xxnmaww7i925ha6qy-go1.6-gogs-20160728-ad7ea88-bin/bin
strip: can't process non-object and non-archive file: /nix/store/wca3v40cfbrman7xxnmaww7i925ha6qy-go1.6-gogs-20160728-ad7ea88-bin/bin/gogs
patching script interpreter paths in /nix/store/wca3v40cfbrman7xxnmaww7i925ha6qy-go1.6-gogs-20160728-ad7ea88-bin
cycle detected in the references of ‘/nix/store/3kqbi3as85hshj1kxifhqsdmlprqnad7-go1.6-gogs-20160728-ad7ea88’
error: build of ‘/nix/store/hhr8wdwfyxiz2ccwny9jbalg4gqwwvxw-go1.6-gogs-20160728-ad7ea88.drv’ failed

Maybe something doesn't like the fact that because of wrapProgram, the Gogs wrapper shell script references the Gogs package to actually access the binary?

What about last line with ln in postInstall. It looks like it could generate a cycle?

I removed whole postInstall and still have the same problem, not sure how to investigate on this.
grep -R /nix/store/ipgqsf1myv4fk5dd9r5pv0lgpkf5kps9-go1.6-gogs-20160728-ad7ea88 /nix/store/zmama6l4ai64adzix0bfc8lwkc81bnz9-go1.6-gogs-20160728-ad7ea88-bin
Binary file /nix/store/zmama6l4ai64adzix0bfc8lwkc81bnz9-go1.6-gogs-20160728-ad7ea88-bin/bin/gogs matches
Binary file /nix/store/zmama6l4ai64adzix0bfc8lwkc81bnz9-go1.6-gogs-20160728-ad7ea88-bin/bin/gogs-ad7ea88 matches

Not sure if this is OK or if this is the problem?

I think it's related to https://github.com/NixOS/nix/issues/494
It could be a lot easier to debug with https://github.com/NixOS/nix/pull/925
It builds for me fine when I remove the ln so I suspect that you can't do wrapProgram in $bin output when the wrapper needs anything from $out output.
I would try to install data files into a separate output and link it then from $bin

It works fine when I do https://github.com/kamilchm/nixpkgs/commit/c49147407d92a3bf8bce0003a9fdcb2a979e5fec
But I wonder if there could be a better way use templates and public than linking it in PWD?
PS. Don't forget to add metadata https://nixos.org/nixpkgs/manual/#sec-standard-meta-attributes ;)

Oh thanks, I'll use this then, I'll update the PR this week-end.
Other than modifying Gogs source code, last time I checked, I could think of any other way than linking templates in GOGS_WORK_DIR and also running the program from GOGS_WORK_DIR.
Because Gogs expects to be run from its Go repository, they import / read some paths relative to CWD, and some others from GOGS_WORK_DIR.

@valeriangalliat what's the status of this?

Forgot about it, sorry, just pulled @kamilchm patch, hopefully the tests will pass.

Don't pay too much attention to the tests  #6652

In this care the error on OSX is legit.

This pull request is superseded by  #19361

Closing in favor of #19361. Thanks for your contribution!


Feature request: Provide a fluent method to validate current URL with an expected one before doing any operations on that page.

Feature request
A generic approach to do fluent method chaining is to call the next Page class from the current class. To give an example,
In login page after user has given username, password and clicked on login button, we would add a method as below to demonstrate that the Home page should have happened and any other operation that we want to do can be now done from the home page instance.
public HomePage redirectToHomePage(){
    return new HomePage();
}

One problem with the above method is, it assumes that the HomePage() would be ready and available to do next steps. What if the password was wrong or another error stopped the login process to complete and thus never navigates to the page to Home page.
I would like to assert that "after click" the url() indeed changed to the desired home-page-url before doing any more actions on the methods of HomePage class itself.
One way, I can do this is:
public HomePage redirectToHomePage(){
    assertEquals(config.get("HOME_PAGE_URL"), url());
    return new HomePage();
}

OR
public HomePage redirectToHomePage(){
    assertTrue(url().contains(config.get("HOME_PAGE_URL"));
    return new HomePage();
}

Problem with first approach is, its not fluent and with all other fluent assertions in Selenide this sticks out badly and breaks the readability. Only good thing is if there are any mismatches, it would clearly show what the expected URL was and what the actual URL is.
Problem with second assertion is also the same that it is not a fluent assertion as other selenide assertions (although reads a little better than the first one. The bigger problem is in case of mismatches, it would only show comparison failure as below, which is not too useful.
org.opentest4j.AssertionFailedError:
Expected :false
Actual   :true

Proposed Solution
Since we already have Junit5 dependency in Selenide, could it be an option to create a method named
urlShouldBe(String expectedUrl);
which compares the actual url() value with this expectedUrl and in case of failure give a descriptive error.
In terms of usage, this would read as below.
public HomePage redirectToHomePage(){
    urlShouldBe(config.get("HOME_PAGE_URL"));
    return new HomePage();
}

Tell us about your environment
Environment is NA - since this is a new feature request.
Code To Reproduce Issue [ Good To Have ]
Please remember that with sample code it's easier to reproduce the bug.
Not a bug but a feature request.
Note: If you find it okay, I can create a pull request to create this method? If there is another way in which the same can be done, I will be happy to hear.

@PramodKumarYadav we already have such asserts:
import static com.codeborne.selenide.Selenide.open;
import static com.codeborne.selenide.Selenide.webdriver;
import static com.codeborne.selenide.WebDriverConditions.url;

    @Test
void foo() {
    open("https://github.com/");
    webdriver().shouldHave(url("https://gitlab.com/"));
}

with a good error message:
webdriver should have url https://gitlab.com/
Actual value: https://github.com/
Screenshot: file:/C:/Users/bo/IdeaProjects/demo/build/reports/tests/1670145807143.0.png
Page source: file:/C:/Users/bo/IdeaProjects/demo/build/reports/tests/1670145807143.0.html
Timeout: 4 s.

can you try?

Thanks for the information @BorisOsipov. This is exactly what I need 😊. This request can be closed. Cheers!


1.7 kick from server

If you join on 1,7 to the server, after some movement and couple seconds it will kick you from the server: https://pastebin.com/raw/SchRwvsm

Update viarewind https://ci.viaversion.com/view/ViaRewind/job/ViaRewind-DEV/


Use Netty5 Alpha6-SNAPSHOT in order to avoid slf4j conflicts.

Motivation:
This project is currently depending on Netty 5.0.0-Alpha5.
Let's depend on Netty Alpha6-SNAPSHOT, this seems to avoid dependency conflicts while adapting ReactorNetty to latest Netty Alpha6-SNAPSHOT.
Modification:
Modified the pom.xml in order to depend on 5.0.0.Alpha6-SNAPSHOT instead of 5.0.0.Alpha5
Use SLF4J API instead of InternalLogger.
Result:
This allows to avoid some dependency conflicts while adapting ReactorNetty to the latest Netty Alpha6-SNAPSHOT

@normanmaurer , thanks for the merge !


can it play youtube videos

i just want to ask quick question can i give youtube video url and play that ?

No, you cannot use YouTube web link.
You need to integrate youtube api to get m3u8 or mp4 and provide it to react native video.
If you just have a youtube web link, you can use react-native-youtube.

No, I don't have any better solution...


Reviewer 1: Comment 5: Less Marketing Talk

IB Motivation, 1st §: please provide scientific grounds for the claims in the first paragraph. Virtually all simulators developed by authoritative labs/companies do have the possibility to compare various nuclear energy system options with varying innovative technologies as part of these systems. The main question is how simulators can address the flurry of questions being addressed by users. The sentence "lower the barrier ... without those innovative concepts" is more 'marketing-talk than truly a scientific analysis as such. None of the simulators today, neither CYCLUS, can address the variety of questions to be addressed by such simulators and especially in industrial context, these simulators need increasingly detailed capabilities and validation to remain thrustworthy in their application.

[ ] Using our various motivating documents (such as the Next Gen Fuel Cycle Simulator Functions and Requirements doc) provide the scientific grounds for the clains.
[ ] Capture the sentiment in the "lower the barrier... without those innovative concepts" sentence in a more scientific way (see moose team paper for an example of noting the importance of usability)
[ ] Consider citing reproducibility/open-science/transparency papers in a concise way in order to bolster the message captured by these statements.
[ ] Emphasize multiple fidelities capability in cyclus. This capability clearly has not been successfully communicated to Reviewer 1, who seems to believe "None of the simulators today, neither CYCLUS, can address the variety of questions to be addressed by such simulators"

Two primary comments:

I absolutely think we should be highlighting the repoducibility of analysis results as a major issue with other codes as well as a lack of transparency of their internal methods/algorithms/etc.
I would actually say that, as it stands, Cyclus (with Cycamore) can not address many of "the variety of questions to be addressed by such simulators". Yet. What Cyclus enables is a platform for quickly developing the capability needed to answer these questions. I think we want to highlight the "fast development iteration" rather than claiming (without backing up) that we can answer certain questions.

I agree with @gidden.  And on his 2nd point - I wrote a fleet-based
continuous material flow reactor archetype in 1 day! - and it can be
swapped in/out with other archetypes trivially.
On Mon, May 11, 2015 at 4:42 PM, Matthew Gidden<EMAIL_ADDRESS>wrote:

Two primary comments:

I absolutely think we should be highlighting the repoducibility of
analysis results as a major issue with other codes as well as a lack of
transparency of their internal methods/algorithms/etc.
2. I would actually say that, as it stands, Cyclus (with Cycamore)
can not address many of "the variety of questions to be addressed by such
simulators". Yet. What Cyclus enables is a platform for quickly developing
the capability needed to answer these questions. I think we want to
highlight the "fast development iteration" rather than claiming (without
backing up) that we can answer certain questions.

—
Reply to this email directly or view it on GitHub
https://github.com/cyclus/fundamentals-paper/issues/118#issuecomment-101068230
.

I'm not sure how to state it in a way that is objective/citable, but I think one of the outcomes of poor cross-tool reproducibility is a credibility gap: consumers of the output can easily believe that if they just wait for the next tool, they'll get a different answer.  (Maybe this is not helpful....)

@gonuke @gidden @rwcarlsen I agree with all of you!

I made an attempt toward these, but have decided to handle the following two parts of this to other issues (where they are also mentioned):

Consider citing reproducibility/open-science/transparency papers in a concise way in order to bolster the message captured by these statements.
-Using our various motivating documents (such as the Next Gen Fuel Cycle Simulator Functions and Requirements doc) provide the scientific grounds for the claims.


test(e2e): finding element by xpath

Closes: #2264

:tada: This PR is included in version 5.0.0-beta.17 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.17.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


conv checker

Purpose
Remove convergence checker from select simulations, since we set max_iters = 1 or 2 anyways
To-do
Content
I kept the convergence checker in the following:
./experiments/standalone/Soil/richards_comparison.jl [more accurate better for comparison?]
./experiments/standalone/Soil/water_conservation.jl [testing limit of performance of jacobian approx]
./experiments/integrated/performance/conservation/ozark_conservation_setup.jl [perhaps for conservation we want convergence]
./docs/tutorials/standalone/Soil/layered_soil.jl [not sure, but this had a very high number of max_iters, so the convergence checker may matter]
I removed it from all global runs, though

[ ] I have read and checked the items on the review checklist.

This looks good! There are still some more places we use convergence_checker (docs/layered_soil.jl, ozark_conservation_setup.jl, richards_comparison.jl, water_conservation.jl). Do we want to remove it from all of these places for consistency?

I think in water_conservation.jl, richards_comparison.jl, and ozark_conservation.jl I want to keep it, because there having a more accurate solution (to check conservation, compare to Bonan, etc) is more important. Ill try without it in the layered soil case, I had kept it for now because max_iters=50 for that sim (so we actually probably use the norm convergence checker. But im not sure we need that)


API to call out shell scripts & functions from within Golang

Summary
Write an API to enable calling out shell scripts or functions from within hack or test Golang code.
Why?
We would like to write more code in Golang, that now written in shell scripts. That involves environment orchestration, test frameworks, build tools and hacks. To make that happen we need a bridge solution which let us call out working shell scripts, and not force us to rewrite everything at once.
Such proposals were previously discussed on Productivity WG https://github.com/knative/test-infra/issues/2418
There are, also other use cases that can benefit from this. Like, new upgrade test framework in which we would like to install either latest stable release or current git HEAD version. Those are now written as Bash shell functions. Such shell call outs can be seen implemented in knative/eventing#4519 test/upgrade/installation/git_head.go L25-L37 Implementing that in knative/pkg is better idea then doing that for eventing, serving, contrib... etc.
How?
We should write an API that will enable us to simple call out shell scripts or just ad-hoc shell functions. It should have a logic to easily let users call out shell files relative to a given Golang source file, so they can invoke project or vendored scripts.
Invoking that script should result in STDOUT and STDERR streamed to Golang process os.Stdout and os.Stderr.
It would be nice to prefix those streams with some labels to make that output more readable.

shouldn't put any Go code in hack, defeats the purpose of having created it in the first place

This was discussed at productivity WG. We intend to have this ONLY as a bridge solution, until it is required.


Upgrade docker-py to v1.7.2

@ami-kumar - review
@nwarabak - FYI
Fixes issue when docker’s config.json is present: https://github.com/docker/docker-py/issues/927
Upgrading to 1.7.1 introduced a new issue: https://github.com/docker/docker-py/issues/949
So I ended up going with 1.7.2
I tested a few dusty commands with this change and they seemed to work well. My plan would be to cut a release candidate, have us three and whoever else runs into issues try that out in a cut a new release once we're confident things are working.

Going to go ahead and merge this. Not much to review really...

🤞🏽 let me know if you need any help testing this


Added attribute toDo in move() function

What’s is the purpose of toDo?

The idea was to create a way to predict the consequences of a move. The fastest way I found is adding this parameter(toDo) but the best one would probably be adding a completely new function.
I'm writing a chess application and I want to know what would be the san of the move(a to b) if the player did this move. The way I did it is duplicating the game and doing the move(also possible doing the move and then come back) but it's not very efficient.
I hope I was clear.


Component render 4 times

Version
2.3.4
Reproduction link
https://jsfiddle.net/chrisvfritz/50wL7mdz/
Steps to reproduce
When I try to load a component it load 4 times before it shows.
What is expected?
Expect to render/load the component only one time
What is actually happening?
The component actually loads 4 times

Where do see a component in the fiddle?

How do you know this is loading 4 times?

Hi!
Please make sure to follow the Issue Reporting Guidelines before opening an issue.
Thanks!


Import styles and images from the documentation repository

This PR updates submodules and imports styles and images from the documentation repository.
Also, styles and images that are now in the documentation repository were removed from this site.

@armiol PTAL.


[firebase_auth_web] Add noop Android implementation.

Description
This is a mitigation for certain build paths that expect an android/ directory on every plugin (regardless of the platform)
Related Issues
flutter/flutter#46898
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] If the pull request affects only one plugin, the PR title starts with the name of the plugin in brackets (e.g. [cloud_firestore])
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (flutter analyze) does not report any problems on my PR.
[x] I read and followed the Flutter Style Guide.
[x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
[x] I updated CHANGELOG.md to add a description of the change.
[x] I signed the CLA.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[x] No, this is not a breaking change.

Thanks, we've figured we need to make sure the no-op implementation does not reference AndroidX, left a few comments about that.

Done!

Waiting for build-ipas checks to pass.

For what it's worth I think in this case it would be okay to merge before the build-ipas tasks specifically finish. They're time consuming, this is a high priority issue, and nothing in this PR should theoretically affect iOS builds in any way.

For what it's worth I think in this case it would be okay to merge before the build-ipas tasks specifically finish. They're time consuming, this is a high priority issue, and nothing in this PR should theoretically affect iOS builds in any way.

@mklim do hit "Squash and merge" if you feel it's OK to go!

Thanks @mklim!


Oauth 2

Is there any plans in the near future to make an oauth 2.0 plugin? Twitter and others are moving to it and would be nice to continue to use guzzle.

@bojanz  Where does the guzzle-oauth2-plugin store the access and refresh token?


[Bicep in VS] The Format Document option is missing in the advanced menu from Visual Studio 2022 for a bicep file

Visual Studio 2022 version
Microsoft Visual Studio Community 2022
Version 17.10.0
VisualStudio.17.Release/17.10.0+34916.146
Microsoft .NET Framework
Version 4.8.09032

Installed Version: Community

Visual C++ 2022   00482-90000-00000-AA773
Microsoft Visual C++ 2022

ADL Tools Service Provider   1.0
This package contains services used by Data Lake tools

ASA Service Provider   1.0

ASP.NET and Web Tools   17.10.338.1105
ASP.NET and Web Tools

ASP.NET Web Frameworks and Tools 2012   17.10.338.1105
For additional information, visit https://www.asp.net/

Azure App Service Tools v3.0.0   17.10.338.1105
Azure App Service Tools v3.0.0

Azure Data Lake Tools for Visual Studio   2.6.5000.0
Microsoft Azure Data Lake Tools for Visual Studio

Azure Functions and Web Jobs Tools   17.10.338.1105
Azure Functions and Web Jobs Tools

Azure Stream Analytics Tools for Visual Studio   2.6.5000.0
Microsoft Azure Stream Analytics Tools for Visual Studio

C# Tools   4.10.0-3.24265.4+91c77369a0242946f66e16a04587e2860357beef
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Common Azure Tools   1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Extensibility Message Bus   1.4.39 (main@e8108eb)
Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration.

GitHub Copilot   0.2.889.30432
GitHub Copilot is an AI pair programmer that helps you write code faster and with less work.

Markdown Editor v2   2.0.164
A full featured Markdown editor with live preview and syntax highlighting. Supports GitHub flavored Markdown.

Microsoft Azure Hive Query Language Service   2.6.5000.0
Language service for Hive query

Microsoft Azure Stream Analytics Language Service   2.6.5000.0
Language service for Azure Stream Analytics

Microsoft Azure Tools for Visual Studio   2.9
Support for Azure Cloud Services projects

Microsoft JVM Debugger   1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

Mono Debugging for Visual Studio   17.10.8 (a565b86)
Support for debugging Mono processes with Visual Studio.

Node.js Tools   1.5.60329.1 Commit Hash:15fce86a17f9f33e5bd7ca7ccb9b216aff149252
Adds support for developing and debugging Node.js apps in Visual Studio

NuGet Package Manager   6.10.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/

Razor (ASP.NET Core)   <IP_ADDRESS>0403+bb51c9aed4e1001def084176c9ec95e1ef6792eb
Provides languages services for ASP.NET Core Razor.

SQL Server Data Tools   <IP_ADDRESS>
Microsoft SQL Server Data Tools

ToolWindowHostedEditor   1.0
Hosting json editor into a tool window

TypeScript Tools   17.0.30327.2001
TypeScript Tools for Microsoft Visual Studio

Visual Basic Tools   4.10.0-3.24265.4+91c77369a0242946f66e16a04587e2860357beef
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual F# Tools   17.10.0-beta.24228.1+dd749058c91585e9b5dae62b0f8df892429ee28f
Microsoft Visual F# Tools

Visual Studio IntelliCode   2.2
AI-assisted development for Visual Studio.

VisualStudio.DeviceLog   1.0
Information about my package

VisualStudio.Mac   1.0
Mac Extension for Visual Studio

VSColorOutput64   2023.4
Color output for build and debug windows - https://mike-ward.net/vscoloroutput

VSPackage Extension   1.0
VSPackage Visual Studio Extension Detailed Info

WiX Toolset Visual Studio Extension   <IP_ADDRESS>
WiX Toolset Visual Studio Extension version <IP_ADDRESS>
Copyright (c) .NET Foundation and contributors. All rights reserved.

Xamarin   <IP_ADDRESS> (main@cf2e960)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer   <IP_ADDRESS> (remotes/origin/d17-10@3beef58f89)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin Templates   17.9.0 (38e87ba)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.

Xamarin.Android SDK   <IP_ADDRESS> (d17-5/45b0e14)
Xamarin.Android Reference Assemblies and MSBuild support.
    Mono: d9a6e87
    Java.Interop: xamarin/java.interop/d17-5@149d70fe
    SQLite: xamarin/sqlite/3.40.1@68c69d8
    Xamarin.Android Tools: xamarin/xamarin-android-tools/d17-5@ca1552d

Xamarin.iOS and Xamarin.Mac SDK   <IP_ADDRESS> (9defd91b3)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.

Describe the bug
The Format Document option is missing in the advanced menu from Visual Studio 2022 for a bicep file
To Reproduce
Create a .bicep file and open the "Edit" --> "Advanced" menu
See:

@StephenWeatherford can you look into this? Is it a VS Code issue?

This is Bicep in VS.  Related to #14316?
@StefH Did this used to work?

I tested on another system with Visual Studio version 17.9.2 and this still works (using the same version = latest from the bicep extension).
-->


Facing the same issue as Failed to bind luis prediction resource to luis applications.

Facing the same issue as Failed to bind luis prediction resource to luis applications.

Here is my publishing profile

Originally posted by @gaurav25dec in https://github.com/microsoft/BotFramework-Composer/issues/6763#issuecomment-906086433

Still stuck in the mentioned issue. Please let me know if I can help with anything else in identifying the issue.

From where we can get the deployment logs over Bot Framework Composer 2.1.0

Please Help

Please Help

hi @gaurav25dec We are still investigating this internally. We will update with an answer or solution as soon as possible.

Closing as a duplicate of https://github.com/microsoft/BotFramework-Composer/issues/8379
Please monitor progress there.


Stormblessed: Blacklist apotik

Stormblessed requests the blacklist of the keyword apotik. See the MS search here and the Stack Exchange search here.

apotik has been seen in 28 true positives, 0 false positives, and 0 NAAs.

Approved by Shree in Charcoal HQ


First pass at implementing 'trait_missing.ron'

Closes #73
I was referencing the struct_missing.ron file, and in there there's a struct_type @output @tag line in the query that doesn't exist in the enum lint. Curious what this is for.
TODOs

[ ] Add trait_missing.ron query file
[ ] Add trait_missing.rs file
[ ] Add test case(s)
[ ] Add the outputs you expect your query to produce over your test case in a new file: src/test_data/<query_name>.output.run.
[ ] Add <query_name> to the list of queries tested by the query_execution_tests!() macro near the bottom of src/adapter.rs.
[ ] Re-run ./scripts/regenerate_test_rustdocs.sh to generate the new rustdoc JSON file.
[ ] Run cargo test and ensure your new test appears in the test list and runs correctly.
[ ] Add an include_str!("queries/<query_name>.ron"), line to SemverQuery::all_queries() in the src/query.rs file, to ensure your query is enabled for use in query runs.

there's a struct_type @output @tag line in the query that doesn't exist in the enum lint. Curious what this is for.

This is because Rust has three different kinds of structs: unit structs Foo, tuple structs Bar(u32) and "regular" structs
struct Baz {
    x: u32,
    y: u32,
}

But you raise an interesting question — perhaps that @tag and @filter shouldn't be there after all. By trying to match a struct's kind between the baseline and current JSON, we'd report a struct as "missing / renamed / moved" if it merely changed from one kind to another. This isn't the most helpful outcome since the error message would be somewhat misleading. We'd be better off reporting that in a check specific to that error.
There's already a check that checks part of this (unit_struct_changed_kind), but we need to check more cases there, as this post describes: https://github.com/rust-lang/cargo/pull/10871#issuecomment-1217103363
You're welcome to take on those checks as well, if you'd like. I'm happy to mentor as well, if you'd like.

In #117 I added one line to unblock this PR, so you don't have to debug "why are traits never found as items" and then edit the data bindings (Trustfall impl Adapter) code. If you're interested in continuing to contribute after this PR, I'm happy to guide you into that code as well — there's no shortage of opportunities here.

No rush at all, just checking in to see how you're doing. Any questions? Anything I can do to help?

Hi, I'm traveling out of the country currently, so I won't probably won't get around to working on this until the week of the 19th.

Hi, I'm traveling out of the country currently, so I won't probably won't get around to working on this until the week of the 19th.

Hi, I'm traveling out of the country currently, so I won't probably won't get around to working on this until the week of the 19th.

No worries at all, no rush. Enjoy your travel! I just wanted to make sure you aren't blocked on me.

Hi! We recently merged a significant revamp of the directory structure and how the tests are organized, and if you're interested in continuing with this PR either now or in January, I wanted to let you know that I'd be happy to help.
If you've moved on to other projects, that's totally fine — no worries! Just let me know so I can reassign this lint to someone else.
If I don't hear back by Jan 15, I'll assume you've moved on to other things and I'll close this PR.

Hi, thanks for following up on this. Yes, you can assign this to someone else. Sorry for the long radio silence.

No worries, thanks for the heads-up!


user-editable name fields for cards

since exploration, discovery, and 'playing to find out' are a big part of the game, i think it'd be on-theme to have some way of setting the name of the npc/creature/ship/planet cards after they've been generated. this would also make it easier to locate them in the chat log using discord's search function, too, rather than approaching the search 'sideways' by trying to remember the contents of the fields or something. as well as covering those situations where there's a typo or maybe interference from autocorrect, haha.
✏ :pencil2: is a pretty common metaphor for this sort of thing, so i think it'd be a solid choice for a react. i figure using that react could trigger the kind of text-based interaction currently used in Delve Site posts?
the 'dream'/expanded version of this feature would be being able to set/remove any field after the fact, but that's probably a separate feature request.

I'm closing this as "Will not fix", but only because I think this will all be implemented with the upcoming "inline reply edit" commands or is already partially implemented with the !EditField command

I'm closing this as "Will not fix", but only because I think this will all be implemented with the upcoming "inline reply edit" commands or is already partially implemented with the !EditField command


Allow CONFIG_POSIX_API on CONFIG_ARCH_POSIX

Is your enhancement proposal related to a problem? Please describe.
Problem:

CONFIG_ARCH_POSIX and CONFIG_POSIX_API should not be mutually exclusive
the POSIX arch should provide a scalable, portable, and maintainable abstraction layer

Intent:
With the POSIX arch, we want to abstract away the host OS system calls (and parts of the system C library) in order to

efficiently test Zephyr code paths in CI
provide devs with a native environment for prototyping and debugging new features that use Zephyr code paths

For further details on intent see the docs
Clarification on CONFIG_POSIX_API:

This is the implementation of a subset of the POSIX API to support Zephyr's needs
i. not strictly adhering the the embedded POSIX profile
The Zephyr application should interface with the Zephyr-provided implementation (with suitable platform-level abstractions)
In the case of CONFIG_ARCH_POSIX, The Zephyr application should not  interface directly to the host OS system calls / or libc implementations

The native_posix port used to rely on posix_cheats.h to perform some questionable preprocessor redefinitions of standard function names in order to avoid conflicts in the C global symbol namespace. This was obviously not portable and somewhat fragile.
After some time, it was decided that CONFIG_ARCH_POSIX and CONFIG_POSIX_API were mutually exclusive options (see #13054, #13540).
This proposal is intended to show that CONFIG_ARCH_POSIX and CONFIG_POSIX_API do not need to be (and really should not be) mutually exclusive, and that functionality can be achieved with conventional OOP methods and very mature, standard APIs.
Moreover, the proposed solution is completely scalable, maintainable, and portable to any OS (likely even including non-POSIX operating systems).
Describe the solution you'd like

Provide a formal definition of abstractions required today to support native_posix
i. for now this can be limited to C function & symbol definitions
An abstraction that works for Linux (and most any other OS) that uses
i. portable and standard C
i. standard POSIX APIs (e.g. dlopen(), dlsym(), can be extended to e.g. Windows API)
i. conventional OOP methods (encapsulation / abstraction)
An (optional) secure method for loading host libc symbols
i. leverage Kconfig to (optionally) provide the name or path of the host libc
ii. leverage Kconfig to (optionally) require a strong checksum for the host libc

W.r.t. host libc name, on GNU systems, the default fault is obtainable programmatically with #include <gnu/lib-names.h> and LIBC_SO. However, it should be possible to link to other libc's as well.
It would probably make sense to encapsulate this abstraction on a per-OS bases by having separate compilation units (e.g. posix-arch-if-linux.c, posix-arch-macos.c).
Describe alternatives you've considered
Proposal in #24685

both dynamic and static proposals rely on visibility attribute (ELF-specific)
requiring a non-standardized feature increases technical debt
immediately precludes macOS support for native_posix
AMP is thrown into the mix (somewhat conflates intent)

There may be other RFCs on this subject
Additional context
This enhancement is a requirement / blocks #43987 which

drastically simplifies using POSIX calls within Zephyr
already demonstrates that CONFIG_POSIX_API and CONFIG_ARCH_POSIX are not mutually exclusive
makes Zephyr more compatible for 3rd-party library code
already has support from HAL / modules / networking
provides a clear path forward for zephyr-namespaced implementations / POSIX wrappers

PR on its way

For background, this topic was discussed, between others, here: #13054, and the PR that disabled the combination was #13540
About the purposes of native_posix: those are listed in the documentation. The "run Zephyr inside of a POSIX process in a production system (†)" is not one, and I very strongly discourage it for several reasons. @cfriedt, please, remove that from the description as that may mislead those who read it.
Please note that there is a (very common) misconception in the description that would be good fixing: "native_posix" is a target board, which is not the same (although it uses) the "posix architecture". It would be nice if you corrected it.
This matter does in any case not block the other PR you refer to, as you can simply leave the combination of POSIX ARCH and POSIX API shim disabled.
"already demonstrates that CONFIG_POSIX_API and CONFIG_ARCH_POSIX are not mutually exclusive" this was demonstrated long ago by the fact that it was enabled on tree for a long while. Please refer to the linked RFC for the motivation for disabling it.
About the "both dynamic and static proposals rely on visibility attribute (ELF-specific)", I did explain that this is not the case for the static library version proposal, but you seem to reiterate on it being so, so I would hope you can either back your statement or remove it. Regarding your other listed concerns, I do not agree with them: The 2nd line is not pointing at anything in particular. About the 3rd point , I do not see why the static library version would have per se any problem with macOS, but maybe you'd be so kind as to elaborate. Regarding AMP on simulated targets, that is something that some people have interest on, and that is enabled/made easier by that proposal; you may not have no interest in it, but I hope it does not prevent from understanding the proposal in itself, which can be applied fully ignoring the AMP use case.

CC @pfalcon @daor-oti

For background, this topic was discussed, between others, here: #13054, and the PR that disabled the combination was #13540

@aescolar Thanks for the links - I'll add them to the summary.

About the purposes of native_posix: those are listed in the documentation. The "run Zephyr inside of a POSIX process in a production system (†)" is not one, and I very strongly discourage it for several reasons.

I strongly discourage it as well. It has been suggested verbally in the past, which is why I mentioned it as a hypothetical.

@cfriedt, please, remove that from the description as that may mislead those who read it.

Done.

This matter does in any case not block the other PR you refer to, as you can simply leave the combination of POSIX ARCH and POSIX API shim disabled.

I'll consider it. I would rather just solve this issue here and then allow the other PR to move forward.

About the "both dynamic and static proposals rely on visibility attribute (ELF-specific)", I did explain that this is not the case for the static library version proposal, but you seem to

I re-reviewed the static proposal and it still mentions "localizing hidden symbols (those not declared with default visibility". Symbol locality, prelinking, objdump capabilities. A lot of that is ELF-specific.

anything in particular. About the 3rd point , I do not see why the static library version would have per se any problem with macOS, but

For the reasons mentioned above.

About the "both dynamic and static proposals rely on visibility attribute (ELF-specific)", I did explain that this is not the case for the static library version proposal, but you seem to
I re-reviewed the static proposal and it still mentions "localizing hidden symbols (those not declared with default visibility)". Symbol locality, prelinking, objdump capabilities. A lot of that is ELF-specific.

In the static case the output of the "pre-link" stage is an object file. Local symbols are just not global symbols, meaning static int a; in translation unit scope is a "local" symbol. The idea of that proposal is that the {Zephyr OS + embOS + app + possible embedded libC} (without the native_posix + SOC + arch) are pre-linked together, (calls to the arch, soc and board are left as unresolved, everything else that is internal to those is already resolved in that link stage), then all global symbols (which were not otherwise marked to be kept as global) are made local local so they don't conflict with further linking steps. The {native_posix + SOC + arch} are pre-linked together, and then linked to the previous pre-linked "embedded" code.

I re-reviewed the static proposal and it still mentions "localizing hidden symbols (those not declared with default visibility)". Symbol locality, prelinking, objdump capabilities. A lot of that is ELF-specific.

In the static case the output of the "pre-link" stage is an object file. Local symbols are just not global symbols,

By default, symbols are global unless declared static, in terms of plain-old C. Symbol "visibility" (at the compiler level) is an ELF construct (it is not available for Mach-O targets, iirc).
However, Mach-O does support tooling to categorize symbols as "exported" and "unexported" and the object format also supports differentiating between global and local.
#define	N_GSYM	0x20
#define	N_LSYM	0x80

https://opensource.apple.com/source/xnu/xnu-2050.18.24/EXTERNAL_HEADERS/mach-o/stab.h

meaning static int a; in translation unit scope is a "local" symbol. The idea of that proposal is that the {Zephyr OS + embOS + app + possible embedded libC} (without the native_posix + SOC + arch) are pre-linked together, (calls to the arch, soc and board are left as unresolved, everything else that is internal to those is already resolved in that link stage), then all global symbols (which were not otherwise marked to be kept as global) are made local so they don't conflict with further linking steps. The {native_posix + SOC + arch} are pre-linked together, and then linked to the previous pre-linked "embedded" code.

The rest of this does sound very application-specific. A similar concept that went in recently (or will be going in recently) is that of multi-target images - building a firmware image that includes e.g. application core, radio, or coprocessor firmware, all in one output file.
The AMP aspect of what you've proposed sounds very similar to that.
I think for the purposes of this issue, I would prefer to focus on just the Zephyr aspect of running CONFIG_POSIX_ARCH and CONFIG_POSIX_API in the same C namespace.

@aescolar @cfriedt should we close this now that native sim is merged?

@carlescufi yep.

Does that mean we can test POSIX_API on ARCH_POSIX?

@aescolar - amazing!! Thank you!

Reopening, because this does not seem to be finished yet.

Sorry -for clarification, this works, but with not with native_posix and friends just with native_sim and friends.


Fix TypeError when CONDA_PREFIX is not set

I ran a build with the mode set to conda by accident and did not
have the CONDA_PREFIX env var set. In that case, os.getenv returns
None, and passing None to create an os.Path is not valid. It
will raise a TypeError.

TypeError: expected str, bytes or os.PathLike object, not NoneType

Signed-off-by: Russell Bryant<EMAIL_ADDRESS>

Thanks for the PR! We have merged a more comprehensive fix w/ CONDA_PREFIX for build and configure https://github.com/meta-llama/llama-stack/pull/144. Love to hear your feedback!

Thanks for the PR! We have merged a more comprehensive fix w/ CONDA_PREFIX for build and configure #144. Love to hear your feedback!

@yanxi0830 thanks! That's better. :-)


Update coordinates

To be:

Simpler for flatten-tool
To support 1 item MultiPoint and Polygons, which are permitted by
geoJSON.

Also updates the versioned release schema patch appropriately.
I've also discussed this change with @kindly

Ok. If you are comfortable that this is valid for GeoJSON spec, then I'm happy to merge this in.


DF Chat Enhancement: Console Error

Module
DF Chat Enhancement
Describe the issue

To Reproduce
Steps to reproduce the behavior:
not clear what causes it at this point
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots (Optional)
If applicable, add screenshots to help explain your problem. If you hit the [F12] key while in Foundry, you will see a window appear. Open the "Console" tab (if it's not already open). If you scroll through this, it is a log for the page. Anything that appears in RED are errors. You can screenshot those errors and add them to this ticket.

Might relate to #231

Duplicate of #231


Allow to push events to LOGBack

Enable the ability to push events to a specific LOGBack logger, so that additional appenders can be configured to offload the data out of Jenkins using different protocols.

Coverage increased (+10.3%) to 54.597% when pulling ed9fe69f0d2d1d7685659bf302aaf3d7456ef0a7 on GerritForge:logback-info into a7c7172fe6b76a26e0918bedde211bfd7515e700 on jenkinsci:master.

@alexgandy what do you think?

Abandoning this PR, going to squash them with the other related to NATS


Note on use of tpcp.Algorithm classes

I saw that at least in one of the algorithms implemented here (https://github.com/mad-lab-fau/eargait/blob/ffd83365ae3cd4351c53ff7b93d92da9a33ffb7e/eargait/gait_sequence_detection/gait_sequence_detector.py#L93), have a bunch of loading in the __init__. This is discuraged in the context of tpcp/sklearn and similar frameworks, as the idea is that parameters can be modified even after the init (using set_params) and the assumption is that creating an instance is "cheap" and it is hence done under the hood often (e.g. via .clone).
All logic should be put where it is first needed (aka in detect or train method)

Here as well: https://github.com/mad-lab-fau/eargait/blob/ffd83365ae3cd4351c53ff7b93d92da9a33ffb7e/eargait/event_detection/mixed_event_detection.py#L78


Write a JavaScript program to convert meters to miles

Description
Write a JavaScript program to convert meters to miles
1 mile = 1609 meters
Input  : 8046.72
Output : 5

How to contribute

Save the solution in ConvertMetersToMiles.js file
Add ConvertMetersToMiles.js file in convert-meters-to-miles folder

i would like to contribute to that  @harshraj8843

i would like to contribute to that @harshraj8843

Hey @amitanshusahu
Sorry, but @MusabMuhie already raise a PR for this. It will take some time to follow the workflow get assigned -> raise PR.
Please contribute to other good first issue
Thanks 🤗


Update CoreSDK 1.0.5 dependency

Do we need to update also the CoreSDK in Package.swift?

When the CI does this, there's more files there. Should those be here too? For example as Egor said, the Package.swift, also the static version that is set in a Swift file, etc.

Static version in swift file changes when CI increments WidgetsSDK version, not CoreSDK

Core SDK version incrementation happens in this pr - https://github.com/salemove/ios-sdk-widgets/pull/692


Fixed Issue #1: add _check function

Greetings:

This pull request is addressing Issue #1
These changes remove repetitive code which validates that the argument types to the .add, .subtract, .multiply, and .divide functions are numbers
The validation function has been implemented as .check and invoked within .add, .subtract, .multiply, and .divide to DRY up the code

Thank you for reviewing this pull request, I look forward to your feedback.

Thank you for your review and for the excellent guidance,  @danthareja .


Live markdown -Suggestion list does not appear above @ line when there is inline image preview

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.42-0
Reproducible in staging?: Y
Reproducible in production?: N/A - new feature, doesn't exist in prod
Issue was found when executing this PR: https://github.com/Expensify/App/pull/49250
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Issue reported by: Applause Internal Team
Action Performed:

Go to staging.new.expensify.com
Go to DM.
Paste the following text

test test

Enter @ and add a few characters.

Expected Result:
The suggestion list will appear above the @ line.
Actual Result:
The suggestion list appears away from the @ line.
The issue is way worse when repeating the steps above in edit mode.
Workaround:
Unknown
Platforms:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
https://github.com/user-attachments/assets/453f0f1d-b2ef-44c9-909b-24235d1d2a20
https://github.com/user-attachments/assets/f6cadda9-0e03-4a0f-b2ec-70f8139aa8df

View all open jobs on GitHub

We think that this bug might be related to Live Markdown

cc @Skalakid, this came from our previous PR that bumped live-markdown version. Can you take a look 👀


Refactor tizen surface

Add TizenNativeWindow, TizenNativeEGLWindow, TizenWl2Display
Add TizenEGLContext, TizenEGLSurface, TizenEGLSurface
TizenEmbedderEngine has TizenNativeWindow as a public member
Release EGLSurface, EGLDisplay, EGLContext

Signed-off-by: Boram Bae<EMAIL_ADDRESS>

I am trying to fix bugs related to releasing resources. I am also trying to re-implement a rotation(or OnTizenSurfaceResize).
As far as I know, for the input panel(software keyboard) to be positioned properly according to the device orientation, the native window must be rotated by itself.
Anyone who knows about this, please let me know(I am not familiar with this field.)

This PR should be merged after #12 is merged.


Prioritize plugin properties over system properties

Resolves #213.
In template.zip, only build-parent/pom-plugin.xml changed:
@@ -16,6 +16,11 @@
     <version>1.0-SNAPSHOT</version>
     <packaging>pom</packaging>

+    <properties>
+        <!-- see comment in plugin config -->
+        <gib.baseBranch>refs/heads/feature/1</gib.baseBranch>
+    </properties>
+
     <build>
         <plugins>
             <plugin>
@@ -24,10 +29,12 @@
                 <version>${gibVersion}</version>
                 <extensions>true</extensions>
                 <configuration>
-                    <enabled>true</enabled>
                     <uncommited>false</uncommited>
                     <referenceBranch>refs/heads/develop</referenceBranch>
-                    <baseBranch>refs/heads/feature/1</baseBranch>
+                    <!-- Must be overridable via -D which won't work if it is fixed to a value here. -->
+                    <!-- This element could be dropped for that (project property is sufficient),
+                         but this way property expansion (by Maven) is tested as well. -->
+                    <baseBranch>${gib.baseBranch}</baseBranch>
                 </configuration>
             </plugin>
         </plugins>

/cc @mickroll

Besides the adjusted PropertyTest, the following also failed for the plugin flavour:
https://github.com/vackosar/gitflow-incremental-builder/blob/master/src/test/java/com/vackosar/gitflowincrementalbuild/integration/MavenIntegrationTestBase.java#L196
which is why I am confident that we now have a consistent solution.
This test failure also required that change in template.zip.