Data brekapoints: support setting conditions and hit conditions

This should behave just like the function breakpoints.
I would add this if there are debug adapters that would profit from this. So please comment if you are interested in this and what debugger you are using.

Hi
I am currently working on a debug adapter which uses GDB.
For this specific debugger, DataBreakpoints (or watchpoint) can have multiple attributes, such as

Hardware (-h)
Temporary (-t)
condition (-c)
Ignore Count (-i)...
(for reference: https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Breakpoint-Commands.html)

For the two first ones, it does not match DAP, so it is not really a concern.
For the two last ones, I think it can be useful to customize this arguments the same way as FunctionBreakpoint.
Thanks in advance @isidorn !

Hi
I am currently working on a debug adapter which uses GDB.
For this specific debugger, DataBreakpoints (or watchpoint) can have multiple attributes, such as

Hardware (-h)
Temporary (-t)
condition (-c)
Ignore Count (-i)...
(for reference: https://sourceware.org/gdb/current/onlinedocs/gdb/GDB_002fMI-Breakpoint-Commands.html)

For the two first ones, it does not match DAP, so it is not really a concern.
For the two last ones, I think it can be useful to customize this arguments the same way as FunctionBreakpoint.
Thanks in advance @isidorn !

Hi,
Do you think it will be adequate to add the possibility to update a Data Breakpoint accessType on this feature request ?

@yannickowow I think it should be better to have that as a seperate feature request. My personal preference is to have smaller specific feature requests

This should work now, thus closing


Ignore subsequent iCCP chunks to match libpng behavior.

PTAL?
This fixes https://github.com/image-rs/image/issues/1825
Question: once/if this gets merged, should I also add a separate test to the image crate?  Having image-level test coverage seems desirable if it ever decides to switch to a different PNG decoder (e.g. see https://github.com/image-rs/image/issues/1852).

Don't worry about adding the same test to image. If we do switch to a different decoding backend (which is now much less likely given significant perf improvements image-png since that issue was created), we'll certainly want to double check all the test cases from this repository. But adding every test case from every backend to the main image crate would needlessly bloat those tests, and it would largely be wasted because the relevant code was already checked.


Add Anderson acceleration and fixed point/Picard options

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#4480
@jandrej
@tzanio
@kmittal2 + @cjvogl
9/6/24
9/23/24
⌛due 9/27/24

PR Checklist

[ ] Code builds.
[ ] Code passes make style.
[ ] Update CHANGELOG:

[ ] Is this a new feature users need to be aware of? New or updated example or miniapp?
[ ] Does it make sense to create a new section in the CHANGELOG to group with other related features?

[ ] Update INSTALL:

[ ] Had a new optional library been added? If so, what range of versions of this library are required? (Make sure the external library is compatible with our BSD license, e.g. it is not licensed under GPL!)
[ ] Have the version ranges for any required or optional libraries changed?
[ ] Does make or cmake have a new target?
[ ] Did the requirements or the installation process change? (rare)

[ ] Update continuous integration server configurations if necessary (e.g. with new version requirements for each of MFEM's dependencies)

[ ] .github
[ ] .appveyor.yml

[ ] Update .gitignore:

[ ] Check if make distclean; git status shows any files that were generated from the source by the project (not an IDE) but we don't want to track in the repository.
[ ] Add new patterns (just for the new files above) and re-run the above test.

[ ] New examples:

[ ] All sample runs at the top of the example source file work.
[ ] Update examples/makefile:

[ ] Add the example code to the appropriate SEQ_EXAMPLES and PAR_EXAMPLES variables.
[ ] Add any files generated by it to the clean target.
[ ] Add the example binary and any files generated by it to the top-level .gitignore file.

[ ] Update examples/CMakeLists.txt:

[ ] Add the example code to the ALL_EXE_SRCS variable.
[ ] Make sure THIS_TEST_OPTIONS is set correctly for the new example.

[ ] List the new example in doc/CodeDocumentation.dox.
[ ] If new examples directory (e.g.examples/pumi), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add example-specific documentation, see e.g. the src/examples.md.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] In examples.md, list the example under the appropriate categories, add new categories if necessary.
[ ] Add a short description of the example in the "Extensive Examples" section of features.md.

[ ] New miniapps:

[ ] All sample runs at the top of the miniapp source file work.
[ ] Update top-level makefile and makefile in corresponding miniapp directory.
[ ] Add the miniapp binary and any files generated by it to the top-level .gitignore file.
[ ] Update CMake build system:

[ ] Update the CMakeLists.txt file in the miniapps directory, if the new miniapp is in a new directory.
[ ] Add/update the CMakeLists.txt file in the new miniapp directory.
[ ] Consider adding a new test for the new miniapp.

[ ] List the new miniapp in doc/CodeDocumentation.dox
[ ] If new miniapps directory (e.g.miniapps/nurbs), add it to MINIAPP_SUBDIRS in the makefile.
[ ] If new miniapps directory (e.g.miniapps/nurbs), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add miniapp-specific documentation, see e.g. the src/meshing.md and src/electromagnetics.md files.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] The miniapps go at the end of the page, and are usually listed only under a specific "Application (PDE)" category.
[ ] Add a short description of the miniapp in the "Extensive Examples" section of features.md.

[ ] New capability:

[ ] All new public, protected, and private classes, methods, data members, and functions have full Doxygen-style documentation in source comments. Documentation should include descriptions of member data, function arguments and return values, template parameters, and prerequisites for calling new functions.
[ ] Pointer arguments and return values must specify whether ownership is being transferred or lent with the call.
[ ] Any new functions should include descriptions of their intended use e.g. for internal use only, user-facing, etc., along with references to example code whenever possible/appropriate.
[ ] Consider adding new sample runs in existing examples to highlight the new capability.
[ ] Consider saving cool simulation pictures with the new capability in the Confluence gallery (LLNL only) or submitting them, via pull request, to the gallery section of the mfem/web repo.
[ ] If this is a major new feature, consider mentioning it in the short summary inside README (rare).
[ ] List major new classes in doc/CodeDocumentation.dox (rare).

[ ] Update this checklist, if the new pull request affects it.
[ ] Run make unittest to make sure all unit tests pass.
[ ] Run the tests in tests/scripts.
[ ] (LLNL only) After merging:

[ ] Update internal tests to include the new features.

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

I think this looks good. The serial version of SUNDIALS ex10 should be updated to match the parallel version... I'm happy to do that unless you're opposed @jandrej ?

TIL there's a serial version. Have at it.

Looks like the Picard option doesn't converge, is this a feature or a bug?
./ex10 -nls kinsol -nls-type 2
mpirun -n 2 ./ex10p -nls kinsol -nls-type 2

It might not be suitable for the problem?

It might not be suitable for the problem?

That's more-or-less the scenario I was referring to with it being a "feature", i.e., that the option is provided in ex10 as an example of how to choose a solver that does not work.

Looks like it was a bug: the Picard iteration works fine so long as KINSolver::EnableAndersonAcc isn't called.  I'll push a fix momentarily (with a bit of refactoring to avoid combinations of features that cause issues).

Probably better this way. Looks good.

ping: @kmittal2

Merged in next for testing...

SUNDIALS <v6 doesn't seem to define KIN_ORTH_MGS in kinsol.h. Should I add a define if SUNDIALS <v6 is used?

It will be good to document in CHANGELOG the changes to the examples and the API changes (at least the removal of the method SetMAA) in class KINSolver.

SUNDIALS <v6 doesn't seem to define KIN_ORTH_MGS in kinsol.h. Should I add a define if SUNDIALS <v6 is used?

It makes sense to define KIN_ORTH_MGS for SUNDIALS < v6 just so it can be used as the default value for the second parameter of KINSolver::EnableAndersonAcc. However, in additiom, it looks like the call to KINSetOrthAA (that uses the second parameter) needs to be inside #if SUNDIALS_VERSION_MAJOR >= 6 since this function was added in v6.

Re-merged in next for testing...


chore(main): release zeta-icons 0.8.1

:robot: I have created a release beep boop
0.8.1 (2024-10-22)
🧹 Miscellaneous Chores

Refactor android to remove 24 from file name and create code in formatted state (#44) (c88a550)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

zeta-icons-v0.8.1
:sunflower:


add void* typedefs for c-api

This is a first step on the path to fixing #202

I want to reuse the macro to do something considerably more complicated once I have simplified the templates.


Feature request: support for customizable tags

*** Motivation: MPD is a flexible, reliable solution for local distribution of audio contents but suffers from a major limitation. The set of supported tags is not customizable. This makes MPD and MPD clients virtually unusable for applications with specific classification needs. Even for users with a focus on, for example, classical music or opera, the current set of core tags is virtually unusable.
*** Realization: MPD users should be able to extend the set of tags MPD supports in a dedicated mpd.conf sections. Something like
user_specific_tags {
  album         "Album"         "single"
  title         "Title"         "single"
  ...
  composer      "Composer"      "multi"
  conductor     "Conductor"     "multi"
  ...
  first_violin  "First Violin"  "single"
}

MPD fills in a dynamical mpd_user_specific_tags data structure at start. Clients request a mpd_user_specific_tags value from the MPD server after connect via a libmpdclient primitive.
*** Implementation: my impression (after I have spent one afternoon on the source code of MPD and of ncmpcpp to add an arbitrary tag to the core set) is that customizable tags can be implemented in MPD quite easily. In libmpdclient it would be certainly necessary to add to the static array mpd_tag_type_names a suitable mpd_user_specific_tags, dishardwire the code and support clients mpd_user_specific_tags queries. On the client side no changes are required. But clients could take advantage of  mpd_user_specific_tags to support customizable searching and browsing. Client customization should be easily implementable.
*** Impact: MPD and MPD clients could be configured for specific applications and customized to meet user specific classification schemes. They could become true alternatives to overbloated commercial solutions without increasing in weight.

this is not the official repository for libmpdclient (which is not on github)
this is: http://git.musicpd.org/cgit/master/libmpdclient.git
I support you in your request and even had a talk with mpds developer about this. He thinks it might be a useful feature and he would be open to merge a patchset, if it isn't too much overhead.

What @carnager said. This repo exists only because I added the vala file. It's not intended for further development and not even up-to-date.


Connect mongoDB  through backend

here I am creating Node.js server which accept data . information from a frontend and stores it in MongoDb.

@DhanushNehru  bro I am still waiting for Ur response

Hi @SoulNikhar I am not able to understand your question?
Do you want to contribute any , or do you have any question on MongoDb?

I want to contribute this under hacktoberfest

Sure @SoulNikhar


Add patterns to text_patterns.py

for asking about

fav things
feelings
help

@Jonah-gr pull request ready to be merged


Mdpx Conduit Application Changes

Description of change
Changes for conduit application, removing turbine references and usage. Includes new user login as well, we don't need to set env variables, the cli will just prompt the user for inputs.
How to test / use:

Grab the latest mdpx changes and build them locally.
Create a new user with roles appended (I usually just give my user owner role) and verified
Use that user to log in, on first run cli will ask you for tenant url which locally should just be http://localhost:8090
Give your email and password in following prompts
Navigate to mdpx/platform/internal/conduitapps/tests/conduit-project-01
Run  meroxa app deploy . --timeout 90s to deploy the app
You should be able to see the app with meroxa app ls
Remove the app by supplying meroxa app remove  test-pipeline-2 --force    with test-pipeline-2 coming from conduit app name

Fixes https://github.com/meroxa/mdpx/issues/1674
Type of change

[ ]  New feature
[ ]  Bug fix
[x]  Refactor
[ ]  Documentation

How was this tested?

[ ]  Unit Tests
[x]  Tested in staging
[ ]  Tested in minikube

Demo

before
after

Additional references

Documentation updated

@anna-cross can you make another PR which removes all the turbine stuff, then rebase this PR from the other pr, so we can easily review the new code.


Requested application data is not configured correctly

It show:

Requested application data is not configured correctly. View/enable debug logs for more details.

while request <IP_ADDRESS>:8088 use the browser
Enable the debug log in conf/log4rs.yaml, we can see:

2022-08-07T11:47:08.480307622+08:00 DEBUG actix_web::data - Failed to extract Data<tera::tera::Tera> for index handler. For the Data extractor to work correctly, wrap the data with Data::new() and pass it to App::app_data(). Ensure that types align in both the set and retrieve calls.

Fixed by #9


Don't free the apartment_context while we are still using it

The apartment-switching function resume_apartment_sync takes a context and a coroutine handle and resumes the coroutine in that context. The context is taken by reference, which is a problem if the coroutine resumption is going to destruct the context: We destruct the context while its call to ContextCallback is still active.
The awaiter for IAsync* captures the context into the completion handler, which is a separate object from the coroutine, so resuming the coroutine will not destruct the context.
However, the awaiter for apartment_context uses the context stored directly inside the apartment_context itself, which could be destructed as part of resumption:
fire_and_forget Something()
{
    // Delay 1 second and return to original context.
    {
        apartment_context save;
        co_await resume_after(1s);
        co_await save;
    }
    // do more stuff
}

The first thing the coroutine does on resumption from co_await save is destruct the apartment_context, which releases the context while ContextCallback is still active.
Fix by copying the context and resuming the copy. That way, the context isn't destructed until after resume_context_sync has definitely returned from ContextCallback.
We can't std::move the context out of the apartment_context because that would prevent an apartment context from being co_awaited more than once.

I chose this solution, rather than having resume_apartment_sync always copy, so we continue to avoid the copy in the co_await IAsyncXxx code path, which is far more common than co_await apartment_context.
I couldn't think of a way to unit test this, since the issue is not really observable to clients. The mismanaged reference-counted object belongs to COM, not the app.

/azp run


Move webui installation to poise-archive

Add spec for webui suite
Fixes #377

@tanner-bruce Thanks! LGTM.
Then we will be able to fix this spec:
https://github.com/johnbellone/consul-cookbook/blob/master/test/spec/libraries/consul_installation_webui_spec.rb

@legal90 I added in the missing checksum for 0.7.1 and fixed up the specs. Not sure why the build is failing randomly, it passes locally.

It appears the last build job has been failed due to the channel we use to install ChefDK in TravisCI (chef-current-trusty). Currently, it installs ChefDK v1.1.3 which looks unstable.

Quote from the Chef slack chat, about this TravisCI build failure:

I just spun up Chef-DK 1.1.3 and ran rspec in it. Everything was fine. I then checkout out your repo, did a bundle install, and then ran rspec. It blew up. So there's a conflict between something in your Gemfile and newer versions of Chef-DK

cc @johnbellone

JFYI: #382 is gonna fix the TravisCI build failure mentioned above


Feature/linting hooks

Adding husky to do git hooks for linting before commit. If fails, it doesn't do file commits.

Good idea


Unable to get table configuration after #2994

So, I merged #2994 after multiple successful IT builds. Created a new cluster using Terraform and the head of main. Created the ci table, then I went into the shell to check that the encryption properties that I set it the configuration were there. And, permission denied. Even thought according to userpermissions I have the correct ones.
 root@accumulo-testing> userpermissions
System permissions: System.GRANT, System.CREATE_TABLE, System.DROP_TABLE, System.ALTER_TABLE, System.CREATE_USER, System.DROP_USER, System.ALTER_USER, System.SYSTEM, System.CREATE_NAMESPACE, System.DROP_NAMESPACE, System.ALTER_NAMESPACE, System.OBTAIN_DELEGATION_TOKEN

Namespace permissions (accumulo): Namespace.READ, Namespace.ALTER_TABLE

Table permissions (accumulo.metadata): Table.READ, Table.ALTER_TABLE
Table permissions (accumulo.replication): Table.READ
Table permissions (accumulo.root): Table.READ, Table.ALTER_TABLE
Table permissions (ci): Table.READ, Table.WRITE, Table.BULK_IMPORT, Table.ALTER_TABLE, Table.GRANT, Table.DROP_TABLE, Table.GET_SUMMARIES
root@accumulo-testing> config -t accumulo.root
2022-10-07T19:35:28,604 [shell.Shell] ERROR: org.apache.accumulo.core.client.AccumuloException: org.apache.accumulo.core.client.AccumuloSecurityException: Error PERMISSION_DENIED for user root - User does not have permission to perform this action
root@accumulo-testing> config -t accumulo.metadata
2022-10-07T19:35:31,563 [shell.Shell] ERROR: org.apache.accumulo.core.client.AccumuloException: org.apache.accumulo.core.client.AccumuloSecurityException: Error PERMISSION_DENIED for user root - User does not have permission to perform this action
root@accumulo-testing> config -t ci
2022-10-07T19:35:37,635 [shell.Shell] ERROR: org.apache.accumulo.core.client.AccumuloException: org.apache.accumulo.core.client.AccumuloSecurityException: Error PERMISSION_DENIED for user root - User does not have permission to perform this action

But, I have no issue scanning the tables:
root@accumulo-testing> table ci
root@accumulo-testing ci> scan
root@accumulo-testing ci> table accumulo.metadata
root@accumulo-testing accumulo.metadata> scan
+rep< srv:dir []	default_tablet
+rep< srv:time []	L0
+rep< ~tab:~pr []	\x00
...

Looking at this ConfigCommand in the Shell retrieves the Site, System, Namespace, and Table configurations to print out the table configuration. Also, looking at the list of permissions ALTER_NAMESPACE was missing for the root user on the default namespace and the accumulo namespace. We didn't add the ALTER_NAMESPACE permission in the tests for the default namespace in #2994, but I think I assume that the ALTER_NAMESPACE permission would be their for the accumulo namespace.
I added those permissions and things worked:
root@accumulo-testing> grant Namespace.ALTER_NAMESPACE -ns "" -u root
root@accumulo-testing> grant Namespace.ALTER_NAMESPACE -ns accumulo -u root
root@accumulo-testing> config -t ci
-----------+---------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SCOPE      | NAME                                        | VALUE
-----------+---------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
default    | table.balancer ............................ | org.apache.accumulo.core.spi.balancer.SimpleLoadBalancer

I feel like two things should happen from this:

The root user should get the ALTER_NAMESPACE permission (and maybe others) on the accumulo namespace.
The logic for getting the different configuration information in ConfigCommand should be moved server-side. If we leave it in the Shell, then we need to back out the changes in #2994. However, if we leave it in the shell, then we are exposing information about the site and system configuration to all users.

If we grant the root user the ALTER_NAMESPACE permission then wouldn't that fix things and allow us to keep the logic in the shell? It worked once you granted the proper permissions as the root user would have access. I only briefly looked at this but trying to figure out why the changes would need to get moved to the server if the user running the shell had the proper permissions granted.

I spent some time prototyping a server side change and the change would be a decent sized change as we'd need to update the API with a new RPC call (probably multiple for both namespace and tables) and handle all the logic the shell is doing to figure out where the properties came from and then return that information (likely associating an enum value for where the config is applied). I think a change that extensive would be better for 3.0 and not 2.1 if we wanted to go that path and would probably generate some discussion on the API and shouldn't be rushed.
After talking to @dlmarion a bit I think another approach for now (which would avoid having to revert the permissions checks) would be to simply not show the level where the properties came from if the user doesn't have permission when they provide a table or namespace. The call for getTableConfiguration() already gets all the properties merged together and that is really what the user cares about if they want to view a table config. The user also has permission to view defaults. So if a user doesn't have permission to view site or system or namespace configuration when we display the table we could just show any property that was not set specifically on the table as "default" and not the exact level it came from.
For admin users (or other users with permissions) that can view the Site/System config, etc we can still display the existing information. This check could be done as simply as try/catch on those calls to detect if they can view it.
I will work on a PR tomorrow that will modify the command to just skip over the get site, system, namespace, etc calls if there is no permission to view them and show default instead. My thinking is if any of those calls failed we'd just switch "modes" and just show "default" if not set on the table or namespace they wanted to see.
The other option is to just revert #2994 but I do think it would be a good idea to not allow all users without to look up the full configs for system and site.

I fixed the first permission issue for the root user in this PR https://github.com/apache/accumulo/pull/3011
There was a bug for the accumulo namespace and default namespace was not set at all

@dlmarion pointed out that root user shouldn't have access to the default namespace by default so I'm updating my PR to remove that.

Ok, I'm out of time for today but submitted 2 PRs to address this as linked, #3011 and #3012. When testing #3012 it's best to also merge in #3011.


Replace route number with color name

BACKGROUND: The optimization produces numbered routes, but users may use a different numbering system that corresponds to geographic location. This can cause confusion when referring to routes. Also, using route colors as the ID make the routes instantly identifiable.
REQUEST: Use the color name, rather than a number, to identify routes.

Also applicable to #13


Can't bypass the selection of user even adding the logoutRedirect method

Core Library
MSAL.js (@azure/msal-browser)
Core Library Version
2
Wrapper Library
MSAL Angular (@azure/msal-angular)
Wrapper Library Version
None
Public or Confidential Client?
Confidential
Description
Can't bypass the selection of user even adding the logoutRedirect method
Error Message
No response
MSAL Logs
No response
Network Trace (Preferrably Fiddler)

[ ] Sent
[ ] Pending

MSAL Configuration
export function MSALInstanceFactories(): IPublicClientApplication {
    return new PublicClientApplication({
        auth: {
            clientId: Config.clientId,
            authority: Config.authority,
            redirectUri: Config.redirectUri,
            postLogoutRedirectUri: Config.redirectUri
        },
        cache: {
            cacheLocation: BrowserCacheLocation.LocalStorage,
            storeAuthStateInCookie: isIE
        }
    });
}

Relevant Code Snippets
public logOut(url : string) {
       const account = this.msalService.instance.getActiveAccount();
       this.msalService.logoutRedirect({ postLogoutRedirectUri: url, account: account});
      };
    };

Reproduction Steps

Log in on site
sign out
show selecting which user to sign out

Expected Behavior

Log in on site
sign out
directly sign out no selecting of user which to sign out

Identity Provider
Entra ID (formerly Azure AD) / MSA
Browsers Affected (Select all that apply)
Chrome, Edge
Regression
@azure/msal-browser 2.0.0
Source
Internal (Microsoft)

Please see here for instructions regarind promptless logout. You will need to make sure you have:

enabled the login_hint optional claim on your app registration
You are passing it into the logoutRedirect function either as logoutHint or embedded in the account
You are using a version of MSAL that supports it (2.22.0+)

If you've done all 3 and it still isn't working please file a ticket here


Deserialize product.db using protobuffer

I ran into an issue with the plugin not detecting Overwatch as installed.
Looking into the code, I noticed that product.db, which is a Protocol Buffer serialized object, wasn't being parsed correctly.
I got the object definition from https://github.com/TinkoLiu/blizzard-product-parser/blob/master/src/assets/bundle.json (not sure if there are License issues in this case), transformed it into a proto object using protobufjs's CLI, and compiled it to Python (src/product_db_pb2.py) using protoc.
This should be a more robust parsing approach for the product.db file.

Hi there, thanks for PR!
It looks way better than current implementation and works like a charm. I'm gonna test it over the weekend :)

Deserializing products.db with this approach yields more attributes, but I haven't looked at them. There might be useful information in there, so make sure to take a look at it!


[SPARK-27571][CORE][YARN][EXAMPLES] Avoid scala.language.reflectiveCalls

What changes were proposed in this pull request?
This PR avoids usage of reflective calls in Scala. It removes the import that suppresses the warnings and rewrites code in small ways to avoid accessing methods that aren't technically accessible.
How was this patch tested?
Existing tests.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/10219/
Test PASSed.

Test build #104913 has started for PR 24463 at commit f599a65.

Test build #104913 has finished for PR 24463 at commit f599a65.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/104913/
Test PASSed.

Merged to master


Add support for 'callCustomMethod'

Noticed the lack of support for 'callCustomMethod' in the API, complicates extending Wordpress beyond it's base capabilities.

Thanks @Lifesnoozer


Deprecate DeduplicateSeriesSet() in favor of NewMergeSeriesSet().

Federation makes use of dedupedSeriesSet to merge SeriesSets for every
query into one output stream. If many match[] arguments are provided,
many dedupedSeriesSet objects will get chained. This has the downside of
causing a potential O(n*k) running time, where n is the number of series
and k the number of match[] arguments.
In the mean time, the storage package provides a mergeSeriesSet that
accomplishes the same with an O(n*log(k)) running time by making use of
a binary heap. Let's just get rid of dedupedSeriesSet and change all
existing callers to use mergeSeriesSet.

Wow! I just gave this patch a try. We want to do cherry picking of about ~100 metrics from one Prometheus server and store it in another one. This /federate request would take at least one minute of CPU time. With this patch attached, the requests now finish in ~3.5 seconds.

Sweet! I’ll take a look first thing tomorrow, but nice improvement.

This does introduce a semantic change; if two supplied matches to the federate endpoint returned the same timeseries, the previous code would drop one, whereas this code will merge them.  Given the series come from the same datasource, the merge on them should be harmless (as the merge will also dedupe), but I think a second opinion would be worth it here.  So +1 from me, but maybe someone from @brian-brazil, @fabxc or @juliusv should also take a look?

That sounds fine to me semantically. Only technically correct with isolation, but that's the case with isolation generally :)

I think this is fine too, great improvement!

Awesome! Thanks for merging this so quickly!


auth working

Pull Request Template
Description
plz see 445. this implements the ability for devs to implement their own 3rd_party_oAuth function and provide it to our /auth endpoint
one potential problem is we should probably do asyc / await on 3rd_party_oAuth function call the but flask is not async... maybe we should use aiohttp package or we can deal with it when we get there.
Fixes #445
Type of change
Please mark options that are relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] success or NO_oAUTH_HIGH_RISK_FLOW = True https://share.getcloudapp.com/DOu8k64w
[x]  NO_oAUTH_HIGH_RISK_FLOW = False and 3rd_party_verification fails  https://share.getcloudapp.com/5zuy29d5
[x] NO_oAUTH_HIGH_RISK_FLOW but no custom function provided https://share.getcloudapp.com/04uKy5Qv

Checklist:

[x] I did follow the contribution guidelines
[ ] New Unit tests added
[ ] Unit tests pass locally with my changes

Before merging this @Prtfw - I'd like to hear from @vvmnnnkv

Looks good to me! This abstracts auth endpoint.
Note since the func is implemented inside pygrid itself this is useful for some pygrid plugin-style authenticators? This is not complete oauth flow yet (where the auth server that makes you an auth token is located outside of pygrid)

Note since the func is implemented inside pygrid itself this is useful for some pygrid plugin-style authenticators? This is not complete oauth flow yet (where the auth server that makes you an auth token is located outside of pygrid)

Thanks for reviewing!
Yes, I think we are saying to ppl who want to deploy:
you need to implement your own oAuth that is at the right level of security.
you need to tell pygrid what that is so we can call it.
If you don't... it's not secure but you can do that at your own risk
(we probably should update the documentation to reflect this at some point)
as for the auth token. I believe that is something the pygrid host provides to the workers....
i.e. if I am uber hosting pygrid and then I want a driver's phone to be a worker ... I would have to give phone a auth_token and then the worker calls the pygrid instance with the token pygrid did not generate.

as for the auth token. I believe that is something the pygrid host provides to the workers....

auth_token is given to PyGrid by a worker trying to authenticate. PyGrid supplies the worker_id to the worker.

Hello @Prtfw , This PR is ready to be merged?

Merged @IonesioJunior @Prtfw !
Any fixes or changes can come in subsequent PR's. I know there's a few todo's remaining for this.


F-bound polymorphic constraints don't work in trait inheritance

If a trait has an F-bound polymorphic constraint then no type can provide that. If you try then the method types don't match:
Example:
trait T
  fun f[A: (Number & Real[A] box)](x: A): U32

class C is T
  fun f[A: (Number & Real[A] box)](x: A): U32 => 4

The error produced is "Clashing type for method f provided by trait to class C".
Without the F-bound element polymorphic methods work fine in traits.

We needed to reify the subtype function with the type parameters of the supertype function before checking if type parameter constraints are contravariant. Fixed.


notify ci status to gitter

both Travis and CircleCI

Any reason not to self merge? My only thought here was that I see a key marked as secure being pushed into a public repo :-)

I'm self merging, just wanted to make sure i didn't brake CI, the secure key is already encrypted so we should be fine :)


Refactoring

Noticed a couple cases of copy-paste code. I think this would make the code more readable, especially the flag comparisons weren't exactly easy on the eye.

Coverage increased (+0.2%) to 59.623% when pulling 6f568096c8a5e7cc7af1696d2baff416425b9045 on juntuu:refactorings into 1bd9105c80aab2874c6a330b67036633e4903454 on newsboat:master.

Excellent, thank you!


Fixed composer warning

Deprecation warning: require-dev.mikey179/vfsStream is invalid, it should not contain uppercase characters. Please use mikey179/vfsstream instead. Make sure you fix this as Composer 2.0 will error.

Duplicate of https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/4325

Oh, ok. The original PR is pointing at the wrong branch, however.

Fixed when merging 4325 , thanks @GrahamCampbell for this PR and your comments/review :)


feat: spanner transformer for migration data added

Codecov Report

Merging #35 (aafe487) into main (1556cd3) will decrease coverage by 0.34%.
The diff coverage is 98.41%.

:exclamation: Current head aafe487 differs from pull request most recent head 080118a. Consider uploading reports for the commit 080118a to get more accurate results

@@              Coverage Diff              @@
##                main      #35      +/-   ##
=============================================
- Coverage     100.00%   99.65%   -0.35%
- Complexity       100      123      +23
=============================================
  Files              3        9       +6
  Lines            237      292      +55
=============================================
+ Hits             237      291      +54
- Misses             0        1       +1

Impacted Files
Coverage Δ

src/MysqlParser/Transformer/SpannerTransformer.php
96.77% <96.77%> (ø)

src/MysqlParser/Parser.php
100.00% <100.00%> (ø)

src/MysqlParser/Processor/CloudSpanner.php
100.00% <100.00%> (ø)

src/MysqlParser/Traits/TableColumnTrait.php
100.00% <100.00%> (ø)

src/MysqlParser/Traits/TableDescriberTrait.php
100.00% <100.00%> (ø)

src/MysqlParser/Transformer/DataTypeFactory.php
100.00% <100.00%> (ø)

.../MysqlParser/Transformer/DataTypes/DecimalType.php
100.00% <100.00%> (ø)

.../MysqlParser/Transformer/DataTypes/DefaultType.php
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1556cd3...080118a. Read the comment docs.


anthropomorphically, gutturalisation

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.4
logical conflict every: 5
sleep for: 300s
[pullrequest]
requests per hour: 30
deps=[a,g]

/trunk merge


release-notes job fails even with release-notes-none

Looking for release notes in ./releasenotes/notes.
Executing: cd ./releasenotes/notes; git diff-tree -r --diff-filter=AMR --name-only --relative=releasenotes/notes '869c8b3233f6ea1c178dcac7f4b604e2c9e1a667' '729aa093772a89f6ac3aa2d3abc57c7c52190888'
Found 1 files.

Parsing release notes
Unable to read release notes: unable to open file releasenotes/notes/gateway-target-port.yaml: open

https://prow.istio.io/view/gs/istio-prow/pr-logs/pull/istio_istio/31798/release-notes_istio/1377107914166112256
https://prow.istio.io/view/gs/istio-prow/pr-logs/pull/istio_istio/31782/release-notes_istio/1377104733877047296

actually looks like manually rebasing  (even if there are no conflicts) fixes this


ROS1 and Ubuntu 20.04

Hi, I have an OPS-241A radar and I am trying to collect data from it using ROS1 inside Ubuntu 20.04. This is what I did:

Downloaded the repo and added to my catkin workspace;
Added the include/rapidjson folder to my /usr/include directory;
Gave read/write privileges to /dev/ttyACM0;
Built the workspace.

I can successfully launch the single radar node. However, when I run rostopic echo /radar_report, the cursor keeps blinking and nothing happen in the terminal. If I run rostopic hz /radar_report, it keeps saying no new messages. What am I missing? Thank you!

Hi paarujo, Just a quick check or question, is anything moving in front of the sensor?  If nothing is moving the sensor should not report any speeds detected and no messages are sent.  If you wave your hand in front of the sensor messages will be sent from the sensor.  Let us know if you see any messages within ROS with motion present.

A few years back I removed the dependency on rapidJson, so there should be no issues with that.  I just now removed the bit in the readme.md that mentioned it.
Glad you solved a port-permission problem.  That's a good way to solve the /dev/ttyACM0 permission issue so that it stays solved even after reboots and replugs. When you say "the communication error disappeared" are you saying that it works now?
Improvising a bit from the Readme, you can send commands to the radar.  I'm reasonably sure that the replies will be visible with rostopic echo /radar_report running.
For instance
rosservice call /radar_1/send_api_command "command: 'R?'"

I tried the rosservice call /radar/send_api_command "command: 'R?'" and I got an error: ERROR: Service [/radar/send_api_command] is not available.
The communication error happened when I launched the node. After I add the command the node didn't give me errors. However, I can't echo messages, the problem persists.

OK, I have put the driver on an ubuntu 20.04 ("focal") release after a clean install of ROS ("noetic")

Okay @jimwhitfield, thanks for the detailed answer. So, I try the "double make" call to see if the messages will be built. I think I tried that not intentionally, but I will check that and I will let you know the result. I have a 241A. When I call rostopic echo /radar_report, after the Enter, the cursor stays blinking in the next line and nothing appears. When I call rostopic hz /radar_report, I keep receiving the message no new message.

Hi @jimwhitfield, installed and built the drive following the documentation, just to record I am using this command:
catkin_make -DPYTHON_EXECUTABLE=/usr/bin/python3
It seems that the 5s rebooting issue was happening to me as well. So, I timed to launch the node and it seems that the communication was successfully established. However, I can't receive messages and the problem still persists :-(
Is there anything else I can't try to find the problem?

Glad to hear it's working!
The API calls like rosservice call /radar/send_api_command "command: 'S2'" should double the standard sampling rate (twice as fast => 2x the report frequency.  S2= 20k-samples per sec   SL = 50k/s)  but I haven't had success with that call yet. (A high priority override issue prevented any ROS investigation yesterday).
Alternatively, you can forgo ROS for a moment and just connect directly to the com port the sensor is on using screen /dev/ttyACM0 or minicom (or teraterm on a PC) to issue the S2 or SL call, then save the setting persistently by P! and then the sensor will keep that rate after power cycles.  (As a general rule, once a sensor is configured, there's not been a pressing need to issue api commands, which is why that code may have stopped working without anyone being aware.)

Hi @jimwhitfield, I will try the commands. For now, I am getting about 6 measurements per second. I didn't get the screen command. After I start it, I just need to write S2 + Enter in the terminal?

Yeah, screen /dev/ttyACM0  or minicom -D /dev/ttyACM0 are both readily-available programs that can talk to /dev/ttyACM0 like a terminal.    (Either of them are installable with the command sudo apt-get install screen or sudo apt-get install minicom   minicom is more focused on being a terminal program.)   Note: Either of them show somewhat helpful menus with a ^A ^Z key sequence.  Note #2: From my memory, it might be that ^A ^X  may be the quit characters for both of them.
Once you're connected to the sensor, ?? will show you many of your settings.  S2 + Enter (or SL) will indeed change the sampling rate.    P! will save the setting.

Thanks! I will try that tomorrow in the lab and I will let you know the results.

Hi @jimwhitfield, good news! I tried screen and it worked. I noticed that the HZ inside ROS is different. For example, if I set SX, rostopic echo /radar_report will report an average frequency of around 6. If I set S2, I get ~16Hz. Is it related to ROS or does the radar itself work like that?

Yay! Those commands (SX, S2, SL) are API commands to change the settings on the radar.  (All commands are found in https://omnipresense.com/wp-content/uploads/2019/10/AN-010-Q_API_Interface.pdf )
Also, it's cool to me that ROS is observing/confirming that the radar's report rate per second (hz) has doubled when moving from SX to S2

I added information about solving permission problems to the README, including the udev rules approach you referred to.
I'm going to close this issue now.  Thanks for opening it in the first place.

Hi, I'm having a similar issue running this on Noetic. I am not having any LED change when waving my hand over the lidar.

Hello blcaw524,
Can you provide more information about your setup, what sensor you are using and what configuration of the sensor are set?
Thanks,
Sandy
From: bclaw524 @.>
Sent: Wednesday, January 25, 2023 1:47 AM
To: SCU-RSL-ROS/radar_omnipresense @.>
Cc: Rob Frizzell @.>; Comment @.>
Subject: Re: [SCU-RSL-ROS/radar_omnipresense] ROS1 and Ubuntu 20.04 (Issue #15)
Hi, I'm having a similar issue running this on Noetic. I am not having any LED change when waving my hand over the lidar.
—
Reply to this email directly, view it on GitHubhttps://github.com/SCU-RSL-ROS/radar_omnipresense/issues/15#issuecomment-1403342503, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE26OUT2EG24X2NCJRE4E43WUDY7PANCNFSM5QZFYCXQ.
You are receiving this because you commented.Message ID<EMAIL_ADDRESS>

@omnipresense
Hi. I managed to get the red/blue light to appear, turns out I had an error when trying to enable the relaxed privileges. I'm using a OPS243 on noetic.
I tried connecting to it using minicom and I'm getting the following:

Is this correct?
I also managed to get the settings menu open, but I'm not understanding how to send the api commands.

Hi, can you open a new issue on github?  Better to not mess with history on this old closed one.
I do not know what you mean by "enable the relaxed privileges".
Good to know you're seeing data.  That's a very messed up flow of data.  I'm wondering if you also still have ROS running? (or two minicoms? two ros programs) because you're not seeing all the characters that the sensor puts out.  There should be commas between any consecutive numbers (like 2.4,2.4,2.4  ) and also after any "m" (meters).  Furthermore, there should be many more linefeeds.  There would never be more than one "m" on a line.  Lines should end with a number.
Sending API commands when interacting with the terminal is as simple as typing them in.  Typing ? ? should get you a whole bunch of data about the current settings.  You could even set some settings and then enter the A! command, the settings will persist across power loss.
(Once you've got the sensor working well, then you can retry ros, and then you can use the rosservice call /send_api_command "command: 'S2'" to send commands (like S2 in this example)

@omnipresense
The "enable relax privileges" was a fix in the error section of the readme (the echo kernel etc.)
Will make a new post.
Thanks

@omnipresense
Well...it fixed itself, somehow. dev/ttyACM0 bugged out and wouldn't detect. Moved to a different usb port and it worked.

I can send commands through minicom too. No idea what caused the original issue

Glad to hear it.   I see it's switched over to JSON--something that the ROS library does.  There's still missing characters there


Akshar/formatting hackathon

Hackathon Moving Formatting/Remove Formatting to lang server

✅ No public API change.


array[0:0] should return empty array

Currently it is equivalent to array[:] which is quite surprising.

As empty arrays don't really exist yet a good compromise might to to return None.

They do exist. array(dim4()) is an empty array in ArrayFire. The functions can't handling them properly is a different issue..

This is partially solved when using logical indexing in devel.

This is fixed in devel.


zconf: rewrite lsluns in C

This is one step further regarding issue #5
Signed-off-by: Rafael Fonseca<EMAIL_ADDRESS>

@Benjamin-Block Could you please have a look?

Any comments on this patch?

Hej Rafael. Sry, but our team (zFCP) doesn't have enough room to review full tool rewrites. We added this to our backlog, but it may take a while till someone can work on it; I can't give you a time frame for this ATM.
I don't feel comfortable with too much code-churn at once. As is, these tools take some effort servicing for us. Reviews and verification on this 'scale' will take effort we can't spend right now.
Regarding issue #5; if fedora wants to get rid of perl dependencies that are pulled in because of core-packages, we have no issue if they decide to remove lsluns from s390utils-base, and put it into a subpackage. Much like they already do with various other tools like ziomon, cpuplugd, ... Then our users could install them still, and would only then pull perl (which I assume is fine, because I doubt fedora wants to get rid of perl in every package). As far as I am aware no other tools depend directly on lsluns.

@Benjamin-Block I understand. Thank you for the reply. The most important rewrite is the zipl_helper, since it's needed for booting.The others can take some time or not happen at all in case there is no interest.


Separate model and view interfaces into separate assembly

This PR contains the first five commits out of PR #190. It creates a new assembly target, nunit.gui.core, intended to hold those parts of the application that will not vary based on the gui toolkit we use.
Further splits are possible as we go along.

sorry about the delay on this, rough day yesterday. i'm starting to review the commits now.

I personally would like to see e5c418a and c86b478 squished (the first two commits).

@jnm2 I was particularly looking for your review of the entire concept of separating the platform dependent and independent parts of the gui into separate assemblies.
Lately, I'm thinking we should have even more separation, putting the model into it's own assembly. If the model assembly has no reference to the presenter or view, then it's impossible to make the mistake of using something that breaks the design pattern. Of course, the alternative is that we be more disciplined about it. 😄
FYI, second commit was a result of code review in the original PR.
To give us time to make this decision, I plan to hold it back from the 0.4 release, which I expect to do in a day or two.

That would help me!
Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------
From: CharliePoole<EMAIL_ADDRESS>Date: 5/28/17 11:55 (GMT-06:00)
To: nunit/nunit-gui<EMAIL_ADDRESS>Cc: Robert Snyder<EMAIL_ADDRESS>Review requested<EMAIL_ADDRESS>Subject: Re: [nunit/nunit-gui] Separate model and view interfaces into separate assembly (#193)
@jnm2https://github.com/jnm2 I was particularly looking for your review of the entire concept of separating the platform dependent and independent parts of the gui into separate assemblies.
Lately, I'm thinking we should have even more separation, putting the model into it's own assembly. If the model assembly has no reference to the presenter or view, then it's impossible to make the mistake of using something that breaks the design pattern. Of course, the alternative is that we be more disciplined about it. 😄
FYI, second commit was a result of code review in the original PR.
To give us time to make this decision, I plan to hold it back from the 0.4 release, which I expect to do in a day or two.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHubhttps://github.com/nunit/nunit-gui/pull/193#issuecomment-304526625, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADTj7UHA-2IhL7IgLgY0dXVagaCeKv7Nks5r-ab9gaJpZM4NoZ0c.

Erm... finally have time to sit down and think about this. Actually I may have a lot of time to sit down. I'll find out tomorrow if I've torn a ligament in my knee.

If the model assembly has no reference to the presenter or view, then it's impossible to make the mistake of using something that breaks the design pattern. Of course, the alternative is that we be more disciplined about it.

For me I'd prefer an analyzer to a separate assembly. I'm usually in favor of augmenting discipline with hard structure, but I dislike separating things into layers. Whether using projects or even Views/Models/Presenters folders. I haven't seen the new version of Jimmy Bogard's talk Slices not Layers but it's probably as good as the first one. When I do WinForms MVVM (which is most of the time) I have each view .cs file immediately next to each view model .cs file. I'm still moving further this direction as time goes on.
 For example, I got away from the interface per view as fast as I could. I always had exactly one view. The coupling between the view and the interface was brittle and high maintenance. It felt like it was always getting in the way of development. But in your case, you intend multiple identically-behaving implementations of each view so it makes sense to enforce that through interfaces.

Both this pull and #190 have gotten really stale, with a number of conflicting changes added to master.
I redid the first four commits from #190 as two commits here. All it does is move things around, creating a new nunit.gui.core assembly that holds both the model and the interfaces for the views. I'd like to get this merged before much more happens. We'll keep #190 around for a while in order to cherry-pick changes from it and then close it without merging.

Fixed assemblyinfo by adding a common assemblyinfo file for all six assemblies.


OpenGL improvements

It's done :grin:.
I was too lazy to copy all the commit messages here, so if you have any questions feel free to ask.
Needs testing on OS X.

Yeah :+1:
Wouldn't it be clearer to add an enum for the context flags, rather than separate booleans? It would take less arguments, and be clearer if set with the constructor.
Isn't there a license associated to the code generated by GLLoader?
Was it really necessary to request a 24-bit depth buffer in the OpenGL and Window examples? The code is supposed to pick the closest valid configuration if some attributes are not available.

Wouldn't it be clearer to add an enum for the context flags, rather than separate booleans? It would take less arguments, and be clearer if set with the constructor.

Perhaps... didn't think of that all this time somehow :stuck_out_tongue:.

Isn't there a license associated to the code generated by GLLoader?

No... we use a loader generator to generate the code that you see in GLLoader.cpp and GLLoader.hpp, and even that (initial) code is heavily modified. It's like using MS Paint to draw a picture and asking if that picture has to have a specific license :stuck_out_tongue:. I don't see any problems here.

Was it really necessary to request a 24-bit depth buffer in the OpenGL and Window examples? The code is supposed to pick the closest valid configuration if some attributes are not available.

If you try to request settings that don't perfectly match what the system can provide, you will stumble into the fallback path. On some systems, that might lead to other settings not being met as well, going as far as decreasing the OpenGL version number to < 3.0 because the initial attempt at getting a 3.0+ didn't yield any matching configurations. Sure, it isn't that important in the examples, but I figured since they are examples, why not make them able to run on more systems without having to go into the fall back path :stuck_out_tongue:.
There currently isn't a way for the user to enumerate all the valid configurations that the system can provide, so if a certain setting is important to them, they just have to keep trying all possible combinations until nothing gets "downgraded". This happens even when settings are completely unrelated. This might be something we would want to add in the future in addition to the video mode enumeration.

Needs testing on OS X.

Alright. I'll do it probably in 10 days (after the exams). Beside code snippet from #778 and the examples, is there anything specific I should test? Any corner cases?

#778 occurred on Windows, or at least I encountered it only on Windows. It might not be an issue on OS X even with the current master.
As for testing the rest, no there isn't anything specific to test. If the pong, shader and OpenGL examples build and run fine (without any warnings as well) then it is more or less safe to assume that it "just works" on OS X.

:ok_hand: I'll test that.

The new version provides the context attribute flags as enums.
Anything else? :grin:

Flags that can be combined use the Uint32 type in other classes (sf::Window, sf::Text), so... :grimacing:

Anything else? :grin:

As for testing the rest, no there isn't anything specific to test. If the pong, shader and OpenGL examples build and run fine (without any warnings as well) then it is more or less safe to assume that it "just works" on OS X.

Pong and shader run fine. However, the OpenGL sample is broken: there is no longer the cube in place of the cursor. Is it the same on Linux/Windows or yet another OS X speciality?

I always test all examples on all the systems I have (Windows and Linux). The OpenGL example works on both for me. If you can, try to get a console up and look for errors. It might have something to do with the context settings/versions.

Nothing in the terminal nor the logger. Using git bitsect I can incriminate 1dae59c1143e6cece00895a9e9b5303081a018ee, if that helps you...

The "strange" thing is that according to your description, only the rotating cube is missing. Since the background and text are still rendered properly, sfml-graphics and sfml-window have to work as intended in regards to how they take care of context management. The problem has to be specific to the OpenGL code (or build configuration settings?) in the example since it doesn't occur with the the pong or shader examples.

I've to admit I don't understand everything that's going on. For example, I see Unix/GlxExtensions.* and Win32/WglExtensions.* but nothing similar for the other platforms, is it intentional?
I've enable more warnings at compilation, I get a lot of this:

SFML/src/SFML/Graphics/GLLoader.cpp:56:34: warning: cast between
pointer-to-function and pointer-to-object is an extension [-Wpedantic]
sf_ptrc_glBlendEquationEXT = (void (CODEGEN_FUNCPTR *)(GLenum))IntGetProcAddress("glBlendEquationEXT");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

No idea if it matters, though.

BTW, I also get this one, not that it really matters.
> ```
SFML/include/SFML/Window/ContextSettings.hpp:46:25: warning: commas at the end of
      enumerator lists are a C++11 extension [-Wc++11-extensions]
        Debug   = 1 << 2, ///< Debug attribute

Regarding those two flags (Debug and Core), the doc should probably state that they do nothing on OS X.

For example, I see Unix/GlxExtensions.* and Win32/WglExtensions.* but nothing similar for the other platforms, is it intentional?

Yes... OS X doesn't rely on an extension to get access to the newer context management functions.
I'll look into those warnings. They shouldn't really change anything though, since pong and shader run fine. You do see the background and text in the OpenGL example right? Just not the spinning cube? Also, does it stop working right after the commit that introduces GLLoader, or only after a later commit?

You do see the background and text in the OpenGL example right? Just not the spinning cube?

Exactly, I see only background and text.

Also, does it stop working right after the commit that introduces GLLoader, or only after a later commit?

Commit on bugfix/glx_context are fine, the first with this issue is the one introducing the loader, that is, after your rebase, this one: https://github.com/LaurentGomila/SFML/commit/dab8ecc3b0bf30d92875fc5e2f7788dea0f641b5

Hmm... I'm running out of ideas :confused:.
Can you try and replace the rotating cube by something "simpler", like a simple untextured triangle using glBegin() and glEnd()? It might be one of those cases where the code relies on... "not so well specified behaviour" such as the starting OpenGL state which might be different on different implementations.
Also... it would be nice if others with OS X can test as well to see if this is "reproducible" on their systems as well.

I tried a few things, such as
        glColor3f(1.0, 1.0, 1.0);
        glMatrixMode(GL_PROJECTION);
        glLoadIdentity();
        glOrtho(0.0, 1.0, 0.0, 1.0, -1.0, 1.0);
        glBegin(GL_POLYGON);
        glVertex3f(0.25, 0.25, 1.0);
        glVertex3f(0.75, 0.25, 1.0);
        glVertex3f(0.75, 0.75, 0.0);
        glVertex3f(0.25, 0.75, 0.0);
        glEnd();

which works fine.
And by luck, I ended up having something close to working. In this gist you can find a edited version of the OpenGL example where basically I moved all ogl code inside the main loop (except for the texture loading). Here is the result:

Instead of no cube I got this brownish thing...
Does it give you any idea of where I should look next?

Hmm... somehow the texture isn't being applied. What happens if you move the texture creation block inside the loop (preferably after enabling GL_TEXTURE_2D) as well? You will want to delete the texture object at the end of the loop body if you do this...

:point_up: :grin:

Sorry, I didn't see your previous message...
So, just moving L50-L60 inside the main loop doesn't improve things. Now I remembered you mentioning resetGLStates() on the forum recently. So I tried adding window.resetGLStates(); right before loading (see this other gist) and it worked. :-)
I tried to do the same and add window.resetGLStates(); before line 50 in the first gist and it worked too.
If I do it on line 49 of the opengl example, it works as well!
Do you have any clue why it behaves like that?

Well... the next step would be to replace window.resetGLStates(); with the code that it runs :stuck_out_tongue:.
Place the following block where window.resetGLStates(); is (line 49 of the opengl example) and see if it works.
sf::Shader::isAvailable();
window.setActive();

glClientActiveTexture(GL_TEXTURE0);
glActiveTexture(GL_TEXTURE0);

glDisable(GL_CULL_FACE);
glDisable(GL_LIGHTING);
glDisable(GL_DEPTH_TEST);
glDisable(GL_ALPHA_TEST);
glEnable(GL_TEXTURE_2D);
glEnable(GL_BLEND);
glMatrixMode(GL_MODELVIEW);
glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_COLOR_ARRAY);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);

glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
glBlendEquationSeparate(GL_FUNC_ADD, GL_FUNC_ADD);
glLoadIdentity();
sf::Texture::bind(NULL, sf::Texture::Pixels);
sf::Shader::bind(NULL);

window.setView(window.getView());

If it does work, try to remove 1 line at a time until it doesn't work any longer. Hopefully we will end up with 1 or 2 lines that are responsible for "fixing" the problem.

I'll just jump in to say, that the OpenGL example works fine for me on Windows 8.1 with my AMD Radeon HD 7500M/7600M.

So, apparently, the sf::Shader::isAvailable + window.setActive duo workarounds the issue. But when I tried to replace isAvailable by its code that has side effects, I couldn't make the texture work.
Do you see any reason why, in this specific piece of code, sf::Shader::isAvailable is not equal to the next block?
{
    sf::Context ctx;
    sf::priv::ensureExtensionsInit();
}

(full code)

Hmm... that does seem strange.
I guess the only way to tell if exactly the same "stuff" happens is to step in each variant with a debugger and compare what is done at an even lower level. A lot of the stuff underneath relies heavily on internal state, and they might not be the same even though the code has one think that.

I'll try to dig into it next week -- can't do it sooner. :-/

Since I don't get it on my AMD card on Windows I wonder, is this issue specific to OS X or to a certain GPU vendor?

If someone with a NVIDIA wants to test it on Linux/Window that could rule out, or not, an OS X specific issue. (I've got a NVIDIA GeForce GT 650M btw.)

Might be a long shot, but the way OS X does things could be a bit... different from other operating systems.
One of the main differences between the new implementation and the old one is that the new one relies on manually loading all OpenGL entry points, even the ones that the standard OpenGL library (e.g. the 1.1 one on Windows) would have provided anyway.
Since the OpenGL example is using the system's OpenGL header (and thus uses the entry points from the system's default OpenGL library) and SFML internally manually loads the entry points from some OpenGL dynamic library, it could very well be that they end up calling functions from different libraries. This was never a problem on Windows or Linux because they tend to have just a single OpenGL library that you can use, but OS X might have multiple (I'm just guessing here). Since context state is probably local to the library whose functions you are calling, the assumption that state changes that SFML makes apply to the example's GL environment doesn't hold any more.
I don't know how you would go about doing this, but maybe you can figure out a way to check what the destination of the GL calls inside SFML and in the example are. If they are indeed different, I'll have to come up with something special for our friend OS X :wink:.

Ho God! :weary:
I'll see what I can do but it might be a while until I get something useful...

I tried the opengl example with the gl_dev_new branch with an NVIDIA gt740m under windows and it renders fine, but NVIDIA NSIGHT is telling my about an invalid operation. I guess it's because of legacy opengl, anyways here is the log from NSIGHT: http://pastebin.com/YDq5Gm8S

Yeah those are all legacy warnings. CodeXL spits them out too. They can be ignored.

@jcowgill: Thanks for the error report. It seems that the Intel part of your optimus setup doesn't like XSetWindowColormap for some reason. I'm not sure if it is even required since we are rendering directly through OpenGL.
Does it work if you comment out lines 355 to 363 in GlxContext.cpp of the latest commit?

Yes it seem to work fine if I comment that out.

Hmm... yeah I just did a bit of reading and it seems that the X colormap is used by OpenGL in color index mode rendering. Since nobody really used it, it was deprecated and eventually removed from the core OpenGL profile.
So... I guess those lines can go :stuck_out_tongue:.

@jcowgill: The change should be pushed now. It should work on both adapters in your Optimus set up.

@mantognini: Can you try out the branch without dynamic 1.1 loading? It is almost identical to how GLEW does it, which obviously works on OS X as well.

I've got the same results with both branches. :-/

@mantognini: And this branch?

It seems to work fine. :smiley:

Rebased onto master.
So... I guess the final testing and code review phases can start :stuck_out_tongue:.

So what was wrong?

Tested again for safety on Mac, this branch works fine! Good work there @binary1248

The previous implementation tried to recreate all existing contexts with the settings of the context that is currently created (shared context = legacy, new context = core => shared context core as well). This didn't work out with OS X because of a few differences in how contexts are created there as opposed to in GLX and Wgl, e.g. it doesn't create a new window/view for every single context.
Even though in theory it should have worked, something went wrong and I just resorted to the previous behaviour of letting contexts of different settings be created and shared with each other. This might not always work (the spec makes no guarantees), but testing so far hasn't shown any problems sharing core and compatibility contexts with/without debug bit set.
It is also probably vendor dependent how debug contexts work. If functions are actually executed elsewhere internally (in a non-debug context) even through we issued it in a debug context it might not trigger any debugging related stuff. Since this is not standardized, it doesn't make sense to enforce anything ourselves, if it won't work on a certain implementation it won't work.

I moved the checks into GlContext, indented the definitions in GlExtensions.hpp and added the OS X note to ContextSettings.hpp.
Tell me if there are more issues.

No more question/comment for me. NB: I haven't looked into Unix/Windows part.
Enabling compiler warnings gives me the same as before though. The second one is easily fixed (just remove the comma). Regarding the casting warning, it's a bit more confusing. This SO question could be a beginning of an answer.

The latest version should fix the warnings.
The cast warning was coming from the fact that the getFunction() methods were returning a function pointer as a simple void* (which is a pointer-to-object). They now return sf::GlFunctionPointer instead which is a typedef to void (*GlFunctionPointer)().

Perfect for me! :-)

I merged the glx_swap_interval branch into this one and repositioned its commit since half of the fix for #727 was already part of gl_dev. This PR should be complete now, i.e. I have nothing more to add :wink:.

Still working fine for me.
NB: if this completely supersedes #727 then don't forget to add the proper tags and close the issue. :wink:

I like keeping the original issues open until they are truly fixed in master. :wink:

This PR has been added to my merge list, meaning it will be merged soon, unless someone raises any concerns.

I'm wondering if it was tested on Android/iOS? (I guess it will work but we never know...)
Also, it would be a good idea if a third pair of eyes could have a look at the commits too. :-)

If you look at the changes, they don't touch anything Android/iOS related. GLEW was never used there... Context management was left untouched... Shaders haven't been implemented... The examples were refactored, nothing more.

Nevertheless, at least checking if it compiles shouldn't take too long and can only be beneficial. :wink:

You have a Mac, so feel free to test iOS. :stuck_out_tongue_winking_eye:

Actually... I think I might have forgotten to implement sf::Shader::getNativeHandle() for OpenGL ES :fearful:.
Going to fix now...

There.. should be fixed now.
Any volunteers to test on Android/iOS? :grin:

Sure thing, I can test for OSX and iOS. eXpl0it3r just informed me about this PR. Do I understand correctly that Shaders are now supported on mobile platforms?

Do I understand correctly that Shaders are now supported on mobile platforms?

Nop. And that's not going to happen soon, because it requires OpenGL ES 2, which would involve to rewrite the whole graphics module.

which would involve to rewrite the whole graphics module.

Don't exaggerate :wink:. Maybe like... 20% of the graphics module would have to be "adapted" to not use legacy OpenGL and ES 2 support would come for free. The first step on the way there is this PR obviously :stuck_out_tongue:.

Yeah... so I just found out that XCB has it's own version of GLX that can be used instead of the "classic" GLX functions. The main advantage is that we wouldn't have to set up some elaborate error handling system (as would be necessary using Xlib, but SFML never bothered to do previously either). Further reading here.
The reason why many people suddenly crash out of their application is because X might generate an error in some GLX calls that don't get handled anywhere since we are using XCB now. All other libraries that I have looked at still use Xlib and handle GLX errors through XSetErrorHandler. This catches errors like those that are produced if we feed invalid context versions to glxCreateContextAttribsARB (yes... the GLX specification says it has to raise an X error, which when unhandled just closes the application with some debug information). We obviously can't afford to do this any more, so there will be no other choice than to use XCB GLX.
This will need a bit of rewriting :stuck_out_tongue:.

Actually, I just found out that if one were to go through XCB GLX, it would end up using indirect rendering, which we absolutely don't want. I'm probably going to fix up the error handling using Xlib/XCB interoperation for now (this is really the only way), and in the future we can think about Wayland support along with OpenGL ES on Unix systems as well. It seems that X is slowly dying out and XCB is just a last ditch effort to prolong its lifetime. Many former X developers have already moved on to work on Wayland by now.

The fatal error causing X to close the application has been fixed (handled/ignored), along with a few other minor bugs. Thanks to @AlexAUT for the bug report regarding the X error.
I also added optional debugging to GlxContext.cpp that is disabled by default. It might help in really mysterious cases of OpenGL context related issues.

Doesn't compile for iOS. GL_OES_texture_npot is unknown.

Also, there is some GLLoader.hpp/cpp in the graphics folder, but they aren't part of CMake/the project. What's going on with these?

They are only used to load extensions on desktop systems, where it is necessary unlike on mobile devices. And yeah... they are part of the CMake configuration, just not part of the main file listing block and excluded from projects generated for mobile systems.

Doesn't compile for iOS. GL_OES_texture_npot is undefined.

Can you try replacing GL_OES_texture_npot with GL_APPLE_texture_2D_limited_npot and see if it works? Simply setting it to false would disable support on Android devices that would have supported npot textures as well. Apple decides to roll their own extension for this I guess...

Can you try replacing GL_OES_texture_npot with GL_APPLE_texture_2D_limited_npot and see if it works?

GL_APPLE_texture_2D_limited_npot is an extension which must be checked for at runtime. It should never be used as a static define as for example an iPad Air supports it, but an iPhone 3G doesn't.

I must admit, I don't have much experience developing OpenGL ES for mobile devices, so I simply assumed that the system would "make it work" if the headers define a specific interface. That was what I discerned from what is currently in master.
If we have to check for extensions in the same way as on the desktop, then that can be arranged as well, but your worry that something might be used on a platform which doesn't support it holds for master already, so maybe this might be taken care of in a separate issue. From this, it seems like eglGetProcAddress is only supported from android-9 onwards, and I have no idea what API SFML is currently targeting.
And about npot: The specification states that it can be present on systems that can provide an OpenGL ES 1.1 or 2.0 context as well, so ES 2 is not the minimum requirement for npot support. The opposite is true however, ES 2.0 support implies limited (and for our purposes, adequate) npot support.

What I meant is, that just because the constant is defined, it doesn't automatically mean that the devices supports it. In ES 2 this is a must-have-feature afaik, but in ES 1.X it isn't. Since SFML is using 1.X, generally assuming that the support exists, is a bug. You might be right that this is already from the previous SFML incarnation and thus not your mistake. It does explain though why in that header there are so many "some Android devices don't support" lines exist. Because of course they don't automatically support GL ES 2 features in an ES 1 context (or at all).
But yea, if this is a problem of a previous SFML code base, it should be addressed elsewhere.
However, the current npot-definition doesn't compile for iOS and setting it to false or checking for the extension at runtime are the only valid options here.

I guess we can be conservative for now and simply set npot support to false then.

I think so, yes. It would be king's league to check it at runtime, but that's a new feature imo.

The updated branch should resolve the X visual mismatch that came around after the XCB rewrite.

Needs rebasing.
@MarioLiebisch Could you give this a try on Android?

Compiles, links and runs fine on my Nexus 5 as far as I can tell.

Just one minor note: there is still old copyright years and Laurent's email address in the added header files.

Rebased onto master and updated copyright notices. I think with the exception of #803 (which - pending further information - I have to assume is caused by the Optimus setup involved), there should be no more issues with this branch.
Feel free to give it a final test run and code review. It's time to put this branch behind us. :wink:

This PR has been added to my merge list, meaning it will be merged after a few positive feedbacks, unless someone raises any concerns.

Feel free to give it a final test run and code review.

Still working fine here. :-)

:tada: :tada:

:clap: :clap: :smiley:


Rebase against docker/distribution master

If you're still working on this, I updated your swift-temp-url branch to docker/distribution master and tested.  Works for me.

See https://github.com/lebauce/distribution/pull/2


umash: change the finalizer to xor-rot

umash: change the finalizer to xor-rot
The low 32 bits are fine with just xor-shift.  However, we need to mix
in the high bit some more, if we want to get rid of the
multiplication.  Rotations are perfect here, but plain xor-rot isn't
invertible (e.g., 0 and -1 both map to 0).
Marc Reynolds shows how
xor-2-rotate maps to invertible matrices,
so we use that.  Xoring after bit rotations (instead of right shifts)
affects both the high and low bits, and xoring two different rotations
ensures the finalizer remains invertible.
In terms of latency, we replace one multiplication on the critical
path with a xor.
Why 27 and 59? 27 because x ^= x >> 27 seemed to work pretty well.
59 because it's far from 27 (mod 64).
TESTED=not yet. hafta change the reference code, check on smhasher.

First, confirm that simple xor-shift (in either direction) doesn't cut it: we need to mix some stuff in the low bits, if only because (mod 2**64 - 8) leaves a simple linear pattern in the low 3 bits.  We also have to mix stuff in the high bits, otherwise smhasher finds bias.
xor-shift.log
I exhaustively tested all 126 possibilities with a xor-shift finalizer (positive shifts go left, negative go right). They all failed ("1000%" bias).
This confirms our hypothesis that we at least need something like a xor-rot to flip bits at both ends... and we actually have to xor in a pair of rotations to guarantee invertibility. Again, I tested all pairs of rotation counts exhaustively to see which pass SMHasher.
xor-rot.log
There are 1953 candidate rotation pairs (63 * 62 / 2), and 1223 (62.6%) are good enough for SMHasher. Of those, 858 all report the same (best) worst-case bias of 0.562% for --test=Sparse,Permutation,TwoBytes,Seed,Zeroes. Our second guess (15, 39) is in that list. On the off chance that we'll want to support a platform where short rotations are faster, I suggest we go with (1, 28): it's in the middle of a cluster of good rotation values (with (1, 29), (2, 28)-(2,30), and (27, 63)-(28, 63)).

Plot twist: 1, 28 fails umash32! Let's resume the exhaustive search, this time looking at umash32 and umash32_hi, within the "optimal" values.

It took me a couple days, but here's a list of the rotation values that have pass a subset of SMHasher with optimal bias for umash 63, 32 and 32hi.
xor-rot-all.log
Let's try to make by rotates easier. (9, 32) looks good: 32 is a simple swap of 32-bit values, and 9 is a rotate by 1 followed by a byte shuffle.


Reanimated is crashing on SDK 44

Summary
Reanimated is crashing apps on SDK 44. Might have been related to the changes in the plugin:
_stopObservingProgress is not defined
  Evaluating react-native-reanimated.js
  Evaluating App.js
  Loading App.js
ReferenceError: _stopObservingProgress is not defined
    at Object.defineProperty.value (react-native-reanimated.js:3:144722)
    at n (react-native-reanimated.js:3:436754)
    at Object.eval (react-native-reanimated.js:3:95149)
    at n (react-native-reanimated.js:3:436754)
    at Object.eval (react-native-reanimated.js:3:119689)
    at n (react-native-reanimated.js:3:436754)
    at eval (react-native-reanimated.js:3:437029)
    at eval (react-native-reanimated.js:3:437073)
    at Object.eval (react-native-reanimated.js:3:437079)
    at eval (react-native-reanimated.js:8:4)

What platform(s) does this occur on?
Android
SDK Version
44
Reproducible demo or steps to reproduce from a blank project
https://staging.snack.expo.dev/@bycedrictest/reanimated-sdk44

Is there anyone from reanimated who may know how to fix this?

Let me add the few more details about this issue, which emerged when I have tried to fix this:

bundle with Reanimated 2.3.0+ is affected (including 2.4.0/1), 2.2.x works as expected, so the problem lies in the new LayoutAnimation feature code
I was thought that some of the global type declaration might be missing in gloabl.d.ts, but after altering the code locally and rebundling Reanimated for Snack my change doesn't help with the issue, see (https://github.com/software-mansion/react-native-reanimated/pull/2137/files#diff-5206c097f5448ac0c731d4f9a39c2009cbc2bfad890e5d6f09b82a609518ad6e)
I have also verified that bundle minification/optimization on the Snackager side is not a problem, same problem occurred without this bundle features turned on

Hey Did someone be able to reproduce this issue locally? Because I have just checked android and iOS with Expo 44 and everything works. I want to solve this issue but I am not able to reproduce it 😕

Hey Did someone be able to reproduce this issue locally?

Hey @piaskowyk, yes, but you need to run the Snack website, bundler (Snackager) and proxies locally from this repo (or you can check the Snack link posted by Cedrick).
This issue do not affect the Expo projects, only running using Reanimated 2.3+ inside Snack project is a problem. The difference between those environments is that Expo uses package from NPM, when Snack relies on the bundler which fetches package from NPM, and then processes all the dependencies packing them into bundles for each platform.

Also it looks like the title is misleading a bit, Expo SDK doesn't matter there, same issue occurs on SDK 43, when using Reanimated  2.3.0+. The only difference is that SDK 44 bundles the problematic version (2.3.1) as default one:

https://snack.expo.dev/@simek/rebellious-tea

Ok, so I will try to set up the Snack website on my computer.
Do you know why this patch is required?

Ok, so I will try to set up the Snack website on my computer.

yarn && yarn start in root should be enough in this case IIRC.

Do you know why this patch is required?

Sorry, nope, but we can ask @byCedric. 🙂

Thanks! I will notify you about the progress.

@byCedric can this be closed?


Block error text changed - for mods/admins

We will not be blocked!

It does blocked - You cannot block admins or currently blocked - cannot be a moderator which doesn't make much sense.
Is it possible to remove the field name from showing without breaking anything? Because if not I think this is still an improvement.

Ah, you’re right. Okay then this isn’t too bad


Stages key?

What does NR mean? Can there be some kind of Stage key? I clicked on "What are the stages?" but that didn't explain what NR meant.
(It's possible that this is some kind of unimplemented/early state, in which case, feel free to close the issue!)

Legit bug, @miketaylr.
Until this repo knows better, every feature is marked "Unrecognized". Well, design-wise that word is way too long to put in the Stage column (otherwise 0 - 4). I need to give "Unrecognized" a better shorthand name, because "NR" ("Not Recognized?") is terrible.
And then I need to include a stage key on this page, at least while everything is marked as unrecognized.

How do you feel about what’s been done here? https://jonathantneal.github.io/css-db/ + https://github.com/jonathantneal/css-db#no-stage-unrecognized

nice!


Assertion for set equality

currently equality will also test ordering, an additional assertion should exist to do comparison of the values without ordering. Maybe:
an equivalent set of

The current workaround would be a combination of including (which amounts to a subset test) and length which taken together would prove set equality though the pigeonhole principle.
The specifics around doing this in a decently expressive way are TBD.
An additional consideration would be that there is the distinction between comparing sets and comparing unordered sequences in that the latter could include duplicated values...currently that
only inspires me to procrastinate on this ticket.


Default route disappears briefly when RA advert is received

Hi,
I'm seeing dhcpcd remove the IPv6 default route briefly, seemingly, whenever a RA advert is received. See logs below and pay attention to the closely correlated timestamps.
# journalctl -u dhcpcd -f
18:08:55 dhcpcd[466445]: wlan0: fe80::debb: no longer a default router
18:08:55 dhcpcd[466445]: wlan0: deleting default route via fe80::debb
18:08:58 dhcpcd[466445]: wlan0: adding default route via fe80::debb

# ip monitor route neigh | ts '%.T'
18:08:55.473028 Deleted default via fe80::debb dev wlan0 proto ra metric 3004 mtu 1500 pref medium
18:08:58.547583 default via fe80::debb dev wlan0 proto ra metric 3004 mtu 1500 pref medium

# tcpdump -nli any host fe80::debb and icmp6
18:08:55.470957 wlan0 M   IP6 fe80::debb > ff02::1: ICMP6, router advertisement, length 80
18:08:58.545976 wlan0 M   IP6 fe80::debb > ff02::1: ICMP6, router advertisement, length 80

# rdisc6 wlan0
Soliciting ff02::2 (ff02::2) on wlan0...

Hop limit                 :           64 (      0x40)
Stateful address conf.    :          Yes
Stateful other conf.      :           No
Mobile home agent         :           No
Router preference         :       medium
Neighbor discovery proxy  :           No
Router lifetime           :         1800 (0x00000708) seconds
Reachable time            :  unspecified (0x00000000)
Retransmit time           :  unspecified (0x00000000)
 MTU                      :         1500 bytes (valid)
 Prefix                   : 2001:db8::/64
  On-link                 :          Yes
  Autonomous address conf.:          Yes
  Valid time              :        86400 (0x00015180) seconds
  Pref. time              :        14400 (0x00003840) seconds
 Recursive DNS server     : 2001:db8:acdd::1
  DNS server lifetime     :         1800 (0x00000708) seconds
 from fe80::debb

I'm using a custom build of the 1:10.0.2-4 Debian package (based on dhcpcd v10.0.2).
--Daniel

Additional datapoint: looking at a package capture T1=300 and T2=259. I use dnsmasq and configure a 5min lease time, not sure if T2 makes sense.

Doh. That makes sense, I did configure bird's radv proto to retract the RA default route when the IGP default route disappears. Probably had some route flapping at the time.
The log message could be a bit more telling here, I would recommend something mentioning "RA router lifetime is zero", that would have given me enough of a clue to figure this out I think. From my perspective this sounded more like some timer expiring (perhaps erroneously).
Thanks,
--Daniel


Maybe some optional keyword arguments can be required positional

https://github.com/AlessandroLollo/prefect-cubejs/blob/main/prefect_cubejs/tasks.py#L16-L18
Unlike Prefect 1.0, since there are no defaults trickling down from class initiation, I think
subdomain: Optional[str] = None,
can be
subdomain: str,

subdomain is an Optional[str] because the task is intended to work both with Cube Cloud and self-hosted Cube.js.
If you use Cube Cloud, then it make sense to pass the subdomain, while if you use self-hosted Cube.js then you should pass the API URL with url.

That's a good point. Perhaps query then?

That make sense!
Going to fix it.
Thanks @ahuang11 🙌

Fix done e new version published!
@ahuang11 let me know if I can close this issue 😊

Yup!


Create documentation for turboPy

Starting to work on the documentation for turboPy, as described in #1.

So, I'm still learning how to use autodoc and sphinx to create the html documentation. I'm also thinking about how much documentation should go into the rst files in the docs folder, vs how much should go in the docstrings.
I'm open to suggestions. I kind of like how the numpy.org documentation looks like there is some high-level content (which presumably is in something like static rst files?) and also has automatically generated lower-level content such as the Numpy API Reference. I think something like this would work well for turboPy.

I kind of like the numpy.org approach, too, but the further away the documentation is from the source the higher risk of having outdated documentation. (Admins/reviewers should review docstrings in any source as it is committed, but we may forget or fail to check relevant docs/*.rst.) Of course even docstrings at the lowest level can be outdated or wrong.
One thought is to treat the documentation in docs/*.rst as "integrated documentation" that describe examples of code use and how multiple objects and methods can be used together. The docstrings at the module level give an overview of the objects in that module. Object/method docstrings are the lowest level.

I agree with your assessment of the risk of having the documentation "too far" from the source. I think that for now I will try and keep the docs/*.rst files for organizing the automatically generated documentation, with the goal of eventually adding some "integrated documentation" as you describe.

I found a blog post where the author describes how to get started with Sphinx and ReadTheDocs. It gives a nice, high-level overview.
I'm putting the link here for reference, for my future self and any others who will be helping with this documentation project.

I've created a (hidden) version of the documentation at ReadTheDocs that is automatically generated from this branch. Whenever commits are pushed to this branch, the online docs will get updated:
https://turbopy.readthedocs.io/en/dev-documentation

I didn't realize that GitHub has a "draft PR" feature. This basically enforces the WIP conventions. I think we can move to using draft PRs. I suppose we can continue to use the [WIP] naming convention, but I think the "draft" feature is easier.

I think that we need to close this PR, and then delete the associated branch.


refactor: remove concept of pending resolution

No longer necessary because we resolve from deno_graph in a batch. This will simplify things.
I'll integrate this in the CLI before marking this as ready.

Huh, just rediscovered why it was done this way. I'll do a separate PR outlining why this is done.

Actually, this makes sense. We just need to return back a result for each specifier and a result for the total npm resolution. Then we need to store the npm install error in the graph probably. This will help enable dynamic imports of npm specifiers to fail individually.


Add detect Online or Offline  project

Hey, I'm LGMSOC21 participant. I'd like to add a project which detect you are online or offline.
Please assign me.

sure


[Feature request] Customize PDFtools midnight mode

Change the colors of pdfview mighnight mode to match those of the theme.
Similar to this issue elsewhere: https://github.com/bbatsov/zenburn-emacs/issues/238

The solution seems pretty straight forward. I use this:
  (setq pdf-view-midnight-colors '("#bbc2cf" . "#282c34"))

and its fixed. The two numbers are foreground and background.
  (setq pdf-view-midnight-colors '(bg . fg))

It should be a straightforward fix, but I haven't tested it sufficiently to say it doesn't break anything else.

As of f650b39 this should be resolved. Let me know if that isn't the case and I'll reopen the issue. Thanks for bringing it to my attention!

Not working again. Outside of the config file it works with:
(setq pdf-view-midnight-colors (cons (doom-color 'fg) (doom-color 'bg)))
but it is reset on for instance theme change.


Check for nil before dereferencing the schema field of a Parameter

I caught this issue while testing swagger-diff with some of my endpoints.  Checking for nil seems to solve the problem.

Thank you for your PR! I think this is a subset of the problem you reported in #6, which means it should be fixed by #8.
Thanks to your report in #6, we found a bug parsing "header" and "formData" parameters. schema is required for "body" parameters, so the conditional shouldn't be needed. But prior to #8, "header" and "formData" parameters, which don't have a schema, were hitting this line, which would not have worked.
I'll update this PR when 1.0.3 is released (probably this afternoon) so you can grab the latest version and verify that it addresses this issue for you.

Great, thanks!  I have hit a couple more bugs which I'll try to track
down.  Would it help to send you the JSON causing the errors?
On Wed, Nov 4, 2015 at 10:34 AM jeffreyc<EMAIL_ADDRESS>wrote:

Thank you for your PR! I think this is a subset of the problem you
reported in #6 https://github.com/civisanalytics/swagger-diff/issues/6,
which means it should be fixed by #8
https://github.com/civisanalytics/swagger-diff/pull/8.
Thanks to your report in #6
https://github.com/civisanalytics/swagger-diff/issues/6, we found a bug
parsing "header" and "formData" parameters. schema is required for "body"
parameters, so the conditional shouldn't be needed. But prior to #8
https://github.com/civisanalytics/swagger-diff/pull/8, "header" and
"formData" parameters, which don't have a schema, were hitting this line,
which would not have worked.
I'll update this PR when 1.0.3 is released (probably this afternoon) so
you can grab the latest version and verify that it addresses this issue for
you.
—
Reply to this email directly or view it on GitHub
https://github.com/civisanalytics/swagger-diff/pull/7#issuecomment-153822566
.

If your bugs are related to header or formData parameters, they may be fixed in 1.0.3, but if not, we welcome issues (and pull requests), and would definitely appreciate sample Swagger that triggers the bug. Thanks!

I just released 1.0.3. Hopefully that will address the bugs you've encountered, but if not, please file issues or create pull requests. Thanks!


ALL TEN PERCENT STOCK BOARDS

AFTER WORK STUDY OF CONTINUING EDUCATION OR IF NOT DEGREED THEN UNIVERSITY OR DAPIP ONLINE DEGREE UNIVERSITY?  BUT THERE IS ANOTHER WAY OUT?  THEIR NOT THE STOCK MANAGER OR THE PRODUCTION LINE WORKER?   OR AS THE DOOR JOB SAYS SALES ACCOUNTANT CERTIFICATION?


[Device Registry] More descriptive error responses for missing params

Is your feature request related to a problem? Please describe.
For some of the endpoints, the error response alert the use of missing parameters but do not specify the exact parameters which are missing
Describe the solution you'd like
Error responses which specify the exact missing parameters which are missing.
Describe alternatives you've considered
Consider listing the exact missing parameters which will be used by the user to easily troubleshoot their request body accordingly
Additional context
Raised as a suggestion by @sserurich in a recently closed PR for device registry microservice.

This was addressed, validation checks are now active across microservice


Koi Farm

Project link: https://github.com/jobtalle/Koi
Project license: https://github.com/jobtalle/Koi/blob/master/LICENSE.md
Does it work on 64-bit only Linux: YES
Is source code available?: YES
Is source code stored in Git?: YES
List of Steam AppIds of supported games:
https://store.steampowered.com/app/1518810/Koi_Farm/

Additional information
https://www.gamingonlinux.com/2021/04/koi-farm-the-relaxing-koi-breeding-game-releases-the-source-code

This is a web game, doesn't that mean Lux would have to package an entire browser? That's a lot to compile.
There's several Windows-only web games on Steam that are bundled with CEF, many of which don't work well with Proton. Is it feasible to simply include a Linux CEF and have it working?

It's electron based so its the browser and the node portion which can control the behavior of the game if they added pieces there.
CEF by itself maybe not, since it may use electron's controls for different behavior, such as saves, handling the window, etc.

Added in https://github.com/luxtorpeda-dev/packages/pull/390


Text style picker

Changed Logs

Implement NSViewHoverExtensions.swift to support Hover Behavior
Update to macOS 10.12 to get rid of #available if (need discuss, since we're in dogfooding process, we could ship to mac 10.11 if we have enough human resource)
Override fontSize (but keep another text attribute) to make the title fits properly in TextStylePickerButton
Resolve cycle retain in some closures
Support dynamic size for NSPopover (depend on length of AttributeText inside)
Support dynamic size for TextStyleItemView

Screenshots

Looking forward to hearing your feedback 👍

Thank for pointing this issues.
I will take a look how we could reuse ColorPickerView in TextStylePickerView 👍

Personally, I'd merely copy/pass and rename the ColorList and ColorSwatchView with slight modification in order to implement the Text Style Picker.
Then I will create new PR to implement new General Picker View then refactoring ColorPicker and TextStylePicker. From that, we can reuse GeneralPickerView for any purpose ;]
How do you think ?

@NghiaTranUIT yes! That sounds like a perfect approach 😃

@dabbott I've just updated and improve your last feedback.
Changed log

Support Search functionality
Same behaviour like ColorPickerView
Revert change in AttributeFont and YGNode
Address your feedback

Looking to hearing your thought 👍


Add support for XChaCha20-Poly1305

Pretty self explanatory. This cipher is explicitly required by some things (i.e. paseto), so it'd be nice if we could use it directly.
See mguymon/paseto.rb#1 for a working example.

Nice, thanks!


Floating label overlaps with placeholder

Hello,
im having an issue where the label with class 'bmd-label-floating' overlaps with the placeholder the browser provides when i use a type of an input field. (like date)
i've tried many browsers (Opera, Chrome, Edge) and its always the same issue.

Can you help me ?
With regards
Dieter

I'm running into a similar problem. I have the following form element defined in my layout:
< div class="form-group" >      < label class="bmd-label-floating" >Artifact name< /label >      < input id="artifactName" name="artifactName" type="text" class="form-control artifactData" />      < span class="bmd-help" >** Need to fill in the help text **< /span> < /div >
Using jQuery, when I set the text property of that input, I see this:

When I click on the field and select it, the "is-filled" class is added to the form element (with the exception of the textarea - it always reverts back to overlapping the content), however I cannot get that class added on the initial page/data load.
Thanks for the help and amazing set of templates!

Hello @dietersanty , thank you for using our products, please update your project to the latest version of the product where we fixed this issues. Also, check the documentation to see how to use the labels.
All the best, Stefan


Add option "-no"

If there is "-no" option is not recorded output file.
Add tests for this option.

It's done.


Separate search screen

Should have a Toolbar with an embedded text field for simple search, as well as a button to slide out a right side drawer with advanced options, i.e. filtering, actor / crew search, budget, etc.

Finally the development is back on track by the amazing developer, This app is amzaing I cant wait to test this new version, can you guide us how to compile it. Thanks

It'll be a long time before anything is ready for public testing :smiley:

This app is really awesome, mate...you rocks ;) I always searched exactly this (app+material design), didn't know you already working on.


Feature: add download report button csv or pdf file

So am building a report system for a client and he wants to be able to download csv and PDF files for the report model and also want to download it by filtering the dates he wants
I've been trying to override the slick reporting but i don't know how

duplicate of #50