Consider adding datetime environment variables to Project env

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/3425
Originally created by @kgpayne on 2022-04-20 11:22:29

Problem to solve
(Summarize the problem we are trying to solve in the form of we need to do [A], so that [B] can [C])
As per example step 4. in #3397 running an initial EL during development is likely to be costly for many extractors. This can be mitigated by setting the start_date option supported by many Singer taps to limit the amount of data extracted. Today these can be hard-coded per environment, e.g.:
environments:
  - name: dev
    config:
      plugins:
        extractors:
          - name: tap-facebook
            config:
              start_date: 020-10-01T00:00:00Z

However this value must be manually managed and reviewed, to minimise the amount of data retrieved during development.
To help users manage this, Meltano could support a selection of common relative datetime environment variables. e.g.:
environments:
  - name: dev
    config:
      plugins:
        extractors:
          - name: tap-facebook
            config:
              start_date: ${MELTANO_DT_YESTERDAY}

Some common choices would likely include:

MELTANO_DT_YESTERDAY
MELTANO_DT_LAST_WEEK
MELTANO_DT_LAST_MONTH
MELTANO_DT_LAST_YEAR

Target audience
(For whom are we doing this? Include a persona)
Developers working on EL pipelines using Meltano.
Further details
(Include use cases, benefits, and/or goals)
This may also be useful in conjunction with templates in dbt for limiting queries to the same timeframes as the EL step, as per the example in dbts Best Practices docs, modified to use the same env var:
select
  *
from event_tracking.events
{% if target.name == 'dev' %}
where
  created_at >= {{ env_var('MELTANO_DT_YESTERDAY') | "dateadd('day', -1, current_date)" }}
{% endif %}

Proposal
(How are we going to solve the problem? Try to include the user journey)
This could be solved in a number of ways:

Add a number of common relative datetimes as Project-wide environment variables to Meltano. This is possible in Meltano as it is today.

Add a datetime macro for use in templated meltano.yml project files. Templating is not yet supported, but if/when it is the same outcome could be achieved with macros. e.g.
start_date: {{ (datetime.now() - relativedelta(days=1)).strftime('%Y-%m-%dT%H:%M:%S.%f') }}

What does success look like, and how can we measure that?
(Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this)

Users have easy relative time constants to use across plugin types in Meltano.

Reasons not to Build

Time is hard
Datetime formatting (UTC) is not guaranteed to be consistent across taps (somewhat mitigated by the SDK) and other plugins

Regression test
(Ensure the feature doesn't cause any regressions)

[ ] Write adequate test cases and submit test results
[ ] Test results should be reviewed by a person from the team

Links / references
Please note that this was taken from GitLab, to be changed accordingly

Are there any plans for this or something similar? Breaking this out into day/month/year components would be useful for us, since we would then be able to do something like
    config:
      filter_tables:
      - events_${MELTANO_DT_YEAR_TODAY}${MELTANO_DT_MONTH_TODAY}${MELTANO_DT_DAY_TODAY}
      - events_${MELTANO_DT_YEAR_YESTERDAY}${MELTANO_DT_MONTH_YESTERDAY}${MELTANO_DT_DAY_YESTERDAY}

I think expression support would be a lot cleaner and more versatile, but also more of a loaded change.

Are there any plans for this or something similar? Breaking this out into day/month/year components would be useful for us, since we would then be able to do something like
config:
  filter_tables:
  - events_${MELTANO_DT_YEAR_TODAY}${MELTANO_DT_MONTH_TODAY}${MELTANO_DT_DAY_TODAY}
  - events_${MELTANO_DT_YEAR_YESTERDAY}${MELTANO_DT_MONTH_YESTERDAY}${MELTANO_DT_DAY_YESTERDAY}

I think expression support would be a lot cleaner and more versatile, but also more of a loaded change.

@ReubenFrankel I still think this would be useful, but I'd like to have a few alternative implementations to discuss. Adding 6+ environment variables seems less than ideal.


update policy route when join subnet cidr changed

What type of this PR

Bug fixes

1、update policy route when join subnet cidr changed
Which issue(s) this PR fixes:
Fixes #1585

已回合release-1.10 和release-1.9 分支


Crash in testpqeg.tst on OS X

The following code snippet causes the anupq executable to eventually crash on Mac OS X 10.11:
LoadPackage("anupq");
G := ElementaryAbelianGroup( 16 );
procId := PqStart( G );
PqDescendantsTreeCoclassOne( procId : TreeDepth := 15, CapableDescendants );

No such crash on Linux. The issue occurs with both 32 and 64 bit builds. Both with GCC 7.2.0 and clang (specifically: Apple LLVM version 8.0.0 (clang-8<IP_ADDRESS>))
UPDATE: this also works and is much faster:
LoadPackage("anupq");
G := ElementaryAbelianGroup( 16 );
procId := PqStart( G ); PqDescendantsTreeCoclassOne( procId : TreeDepth := 5, CapableDescendants );

Debugging this with lldb is incredibly annoying, because once I attach the debugger, I cannot resume pq, as it'll just die with an error like "Insufficent data read in from or written to file" (at least for interactive pq, I'll now try non-interactive)

After fixing some C compiler warning about variables being used uninitialized, here is what I get with SetInfoLevel(InfoANUPQ,4); right before the crash:
#I  5 is defined on [2, 1] = 2 1
#I  Class 3
#I  6 is defined on [5, 1] = 2 1 1
#I  7 is defined on [3, 1] = 3 1
#I  8 is defined on [3, 2] = 3 2
#I  9 is defined on [4, 1] = 4 1
#I  10 is defined on [4, 2] = 4 2
#I  11 is defined on [4, 3] = 4 3
#I  12 is defined on 1^2 = 1 1
#I  13 is defined on 2^2 = 2 2
#I  14 is defined on 3^2 = 3 3
#I  15 is defined on 4^2 = 4 4
#I  Non-trivial powers:
#I   .1^2 = .12
#I   .2^2 = .13
#I   .3^2 = .14
#I   .4^2 = .15
#I   .5^2 = .6
#I  Non-trivial commutators:
#I  [ .2, .1 ] = .5
#I  [ .3, .1 ] = .7
#I  [ .3, .2 ] = .8
#I  [ .4, .1 ] = .9
#I  [ .4, .2 ] = .10
#I  [ .4, .3 ] = .11
#I  [ .5, .1 ] = .6
#I  [ .5, .2 ] = .6
#I  ToPQ> 9  #to (Main) p-Group Generation Menu
#I  ToPQ> 0  #to (Main) p-Quotient Menu
#I  ToPQ> 5  #set output level
#I  ToPQ> 0  #output level
#I  ToPQ> 9  #to (Main) p-Group Generation Menu
#I  ToPQ> 2  #extend automorphisms
#I  ToPQ> 5  #construct descendants
#I  Cannot open (null)
#I  ToPQ> 3 #class bound
#I  ToPQ> 0  #do not construct all descendants
#I  ToPQ> 1  #step size
#I  ToPQ> 0  #do not compute pcgs gen. seq. for auts.
#I  ToPQ> 0  #do not use default algorithm
#I  ToPQ> 0  #rank of initial segment subgrp
#I  ToPQ> 0  #do not completely process terminal descendants
#I  ToPQ> 0  #exponent
#I  ToPQ> 0  #do not enforce metabelian law
#I  ToPQ> 1  #default output
Error, failed to find any more of line (iostream dead?)
 at /Users/mhorn/Projekte/GAP/gap.github/lib/streams.gi:171 called from
ReadAllLine( iostream, true, IS_ALL_PQ_LINE ) at /Users/mhorn/Projekte/GAP/repos/pkg/anupq/lib/anupqios.gi:389 called from
PQ_READ_NEXT_LINE( datarec.stream ) at /Users/mhorn/Projekte/GAP/repos/pkg/anupq/lib/anupqios.gi:469 called from
FILTER_PQ_STREAM_UNTIL_PROMPT( datarec ); at /Users/mhorn/Projekte/GAP/repos/pkg/anupq/lib/anupqios.gi:630 called from
ToPQ( datarec, [ 1 ], [ "  #default output" ] ); at /Users/mhorn/Projekte/GAP/repos/pkg/anupq/lib/anupqi.gi:2978 called from
PQ_PG_CONSTRUCT_DESCENDANTS( datarec ) at /Users/mhorn/Projekte/GAP/repos/pkg/anupq/lib/anupqi.gi:3028 called from
...  at *stdin*:9
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue
brk>

Note the line "#I  Cannot open (null)"  -- this indicates that OpenFile was called, but the filename string used was a null pointer.

With info level 7:
#I  ToPQ> 9  #to (Main) p-Group Generation Menu
#I
#I  Menu for p-Group Generation
#I  -----------------------------
#I  1. Read automorphism information for starting group
#I  2. Extend and display automorphisms
#I  3. Specify input file and group number
#I  4. List group presentation
#I  5. Construct descendants
#I  6. Advanced p-group generation menu
#I  7. Exit to basic menu
#I
#I  Select option:
#I  ToPQ> 2  #extend automorphisms
#I
#I  Select option:
#I  ToPQ> 5  #construct descendants
#I  Cannot open (null)
#I  Input class bound on descendants:
#I  ToPQ> 3 #class bound
#I  Construct all descendants?
#I  ToPQ> 0  #do not construct all descendants
#I  Input step size:
#I  ToPQ> 1  #step size
#I  PAG-generating sequence for automorphism group?
#I  ToPQ> 0  #do not compute pcgs gen. seq. for auts.
#I  Do you want default algorithm?
#I  ToPQ> 0  #do not use default algorithm
#I  Rank of the initial segment subgroup?
#I  ToPQ> 0  #rank of initial segment subgrp
#I  Completely process terminal descendants?
#I  ToPQ> 0  #do not completely process terminal descendants
#I  Input exponent law (0 if none):
#I  ToPQ> 0  #exponent
#I  Enforce metabelian law?
#I  ToPQ> 0  #do not enforce metabelian law
#I  Do you want default output?
#I  ToPQ> 1  #default output
Error, failed to find any more of line (iostream dead?)
 at /Users/mhorn/Projekte/GAP/gap.github/lib/streams.gi:171 called from
ReadAllLine( iostream, true, IS_ALL_PQ_LINE ) at /Users/mhorn/Projekte/GAP/repos/pkg/anupq/lib/anupqios.gi:389 called from
PQ_READ_NEXT_LINE( datarec.stream ) at /Users/mhorn/Projekte/GAP/repos/pkg/anupq/lib/anupqios.gi:469 called from
FILTER_PQ_STREAM_UNTIL_PROMPT( datarec ); at /Users/mhorn/Projekte/GAP/repos/pkg/anupq/lib/anupqios.gi:630 called from
ToPQ( datarec, [ 1 ], [ "  #default output" ] ); at /Users/mhorn/Projekte/GAP/repos/pkg/anupq/lib/anupqi.gi:2978 called from
PQ_PG_CONSTRUCT_DESCENDANTS( datarec ) at /Users/mhorn/Projekte/GAP/repos/pkg/anupq/lib/anupqi.gi:3028 called from
...  at *stdin*:5
you can 'quit;' to quit to outer loop, or

That CrashReporter output actually was quite helpful: it crashes because FILE * ifp is NULL. And that in turn is so because in pgroup_generation, also StartName is NULL, leading to StartFile being set to NULL, which ultimately is used as value for ifp inside restore_pcp.

Seems I had this pinned down and then stopped, huh..... So next thing to look at: why is it NULL here and not on Linux?

I've inserted fprintf(stderr, ...) statements at the start and end of pgroup_generation, and also whenever StartName is modified and used... and that caused the bug to trigger on Linux, too! Output looks like this (excerpt):
...
#I  Number of descendants of group #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 to class 13: 1
RESTORE_GROUP: StartName [grp]_class14
ITERATION: StartName [grp]_class14
ITERATION2: StartName [grp]_class14
#I  Number of descendants of group #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 to class 14: 1
RESTORE_GROUP: StartName [grp]_class15
ITERATION: StartName [grp]_class15
ITERATION2: StartName [grp]_class15
#I  Number of descendants of group #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 #1;1 to class 15: 1
RESTORE_GROUP: StartName [grp]_class2
pgroup_generation END
pgroup_generation START
pgroup_generation END
pgroup_generation START
ITERATION: StartName (null)
Cannot open (null)
Error, failed to find any more of line (iostream dead?)
...

So pgroup_generation is called and StartName is set... and then it exits, starts again, exits, starts again, and StartName is accessed. My guess: this can work if StartName is not initialized (as was the case before commit 6929d52c62570d9326cc226f589cc9acb132c345), because the old value of StartName may still be on the stack, undisturbed (and we never free the storage for StartName either).


Cluster setup flow for microk8s points to 1.19

Is your feature request related to a way you would like Akri extended? Please describe.
Currently, the cluster setup page points to 1.19 version of Kubernetes when setting up MicroK8s.
Describe the solution you'd like
Could we remove the channel and let users deploy the latest version? That is currently 1.21.1.

I believe we chose a specific version so it could be one that we are validating in our tests. Maybe we have this be a part of our release cycle to have the docs point to the latest K8s version we are testing. Or we could use the latest stable channel and if there are any issues, it will help us catch them sooner.

@jiria Maybe we change it to latest but add a note pointing to the current versions we test?

maybe another solution would be to have the docs not call out a specific version, but rather link to our supported versions (in the CHANGELOG.md maybe?)


Add Colorbar to contouring app

For the plot of the data, a colorbar and/or a histogram of the data would aid in contour selection.

Implemented on #GEOPY-211
Works for you @ThomasMGeo ?

Looks great! Perfect. Thanks!

Added on GEOPY-211


Deduplicate browser test scripts

Description
Today we have 2 scripts that run browser tests: bin/run-browser-tests-local and wait_for_server_start_and_run_tests.sh. They do basically the same thing with the only difference in server urls they use to call CiviForm. This PR updates bin/run-browser-tests-local to call wait_for_server_start_and_run_tests.sh and have the latter the meaty logic of running tests.
Checklist

[x] Added the correct label: < feature | bug | dependencies | infrastructure | ignore-for-release >
[ ] Created tests which fail without the change (if possible)
[ ] Extended the README / documentation, if necessary

Codecov Report

Merging #3656 (b9466ea) into main (8ffc494) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               main    #3656   +/-   ##
=========================================
  Coverage     80.53%   80.53%
  Complexity     2431     2431
=========================================
  Files           295      295
  Lines          9618     9618
  Branches        658      658
=========================================
  Hits           7746     7746
  Misses         1619     1619
  Partials        253      253

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


What is the effect of 'adam_onecycle' optimizer ?

Hi :)
Thx for your nice work.
btw, I wonder the effect of 'adam_onecyle' optimizer. (used in pointpillar model's config)
What part of this adam_onecycle method helps our learning?
And why did you use adam_onecycle as a default? (origin pointpillar paper used just adam optimizer)
Best,
Daeun Lee

I think it helps in converging faster and allows to use higher learning rates. Refer section 4.1 in this paper: https://arxiv.org/pdf/1803.09820.pdf for more details.

Thanks !
I experienced AP degradation when I used just 'Adam' optimizer. (not Adam_onecycle optimizer).
it seems that learning didnt converge and fluctuate.. ;(
is there any reason why performance is poor?
and is this common issue ?

I think when you just use adam the learning rate starts with the learning rate specified in the model config yaml file and then decays according to this:
https://github.com/open-mmlab/OpenPCDet/blob/0642cf06d0fd84f50cc4c6c01ea28edbc72ea810/tools/train_utils/optimization/__init__.py#L40
Whereas if you use a one cycle lr scheduler, it ramps up to the learning rate specified in the model config yaml file and then ramps down.
Maybe try using a smaller learning rate if you are not using one_cycle lr scheduler?

really helpful answer. thanks XD


Can we update mysql-connector version to 8 ?

Why you need it?
Is your feature request related to a problem? Please describe in details
How it could be?
A clear and concise description of what you want to happen. You can explain more about input of the feature, and output of it.
Other related information
Add any other context or screenshots about the feature request here.

as @sharajava  said.
because of no update for a long time, I will close the issue, if you have other questions, please reopen it or create a new one


Index selector combo box still broken some time

I don't know if this is because I need to recompile the webapp bundle or somthing like that...

The bug is confirmed in main

Still broken when using Ctrl + Enter instead of clicking on the button

Closed by #3043


Inconsistent duplicate dependency resolution

Afternoon
I'm currently using Librarian-Puppet 1.5.0 with librarianp 0.6.3 on a Centos 6 host which is restricted to Ruby 1.8.7...
I seem to be experiencing inconsistent dependency resolution, as per the following log: https://gist.github.com/fatmcgav/700f9d8be6950f593eb6#file-librarian-puppet-20install-20log
As you can see from the Puppetfile, all 4 modules are over-ridden from the metadata.json file.
However 2 are being resolved to the forge, and 2 to github...
Any idea how I can get all 4 to resolve to their Github links?
Cheers
Gavin

can you try in another machine with ruby 1.9+ and latest librarian-puppet version to see if it behaves differently ?

It seems to resolve the dependencies as expected on my MBP running Ruby 2.2.1, librarian-puppet 2.2.0 and librarianp 0.6.3...
librarian-puppet install --clean --verbose --path /tmp/librarian-test
[Librarian] Ruby Version: 2.2.1
[Librarian] Ruby Platform: x86_64-darwin14
[Librarian] Rubygems Version: 2.4.6
[Librarian] Librarian Version: 0.6.3
[Librarian] Librarian Adapter: puppet
[Librarian] Librarian Adapter Version: 2.2.0
[Librarian] Project: /Users/gavinw/Work/Puppet/ACT-Modules/cataloguesvc
[Librarian] Specfile: Puppetfile
[Librarian] Lockfile: Puppetfile.lock
[Librarian] Git: /usr/local/bin/git
[Librarian] Git Version: 2.4.0
[Librarian] Git Environment Variables:
[Librarian]   (empty)
[Librarian] Pre-Cached Sources:
Replacing Puppet Forge API URL to use v3 https://forgeapi.puppetlabs.com. You should update your Puppetfile
[Librarian] Post-Cached Sources:
[Librarian]   [:forge, "http://forge.puppetlabs.com", {}]
[Librarian]   [:git, "git@github.com:weareact/puppet-base.git", {:ref=>"develop"}]
Dependency 'act-base' duplicated for module, merging: ["act-base (>= 0.1.0) <https://forgeapi.puppetlabs.com>", "act-base (>= 0.1.0) <git@github.com:weareact/puppet-base.git#develop>"]
[Librarian] Resolving act-base (>= 0.1.0) <git@github.com:weareact/puppet-base.git#develop>
[Librarian]   Checking manifests
[Librarian]     --- No output
[Librarian]     --- No output
[Librarian]     --- No output
[Librarian]     --- No output
[Librarian]     --- No output
[Librarian]     --> origin
[Librarian]     -->   origin/HEAD -> origin/develop
[Librarian]     -->   origin/develop
[Librarian]     -->   origin/feature/beaker_acceptance
[Librarian]     -->   origin/master
[Librarian]     --> fbb058d72cd59089cb363c2aa1a2926601171365
[Librarian]     --> fbb058d72cd59089cb363c2aa1a2926601171365
[Librarian]     Checking act-base/0.1.0 <git@github.com:weareact/puppet-base.git#develop>
[Librarian] Pre-Cached Sources:
Replacing Puppet Forge API URL to use v3 https://forgeapi.puppetlabs.com. You should update your Puppetfile
[Librarian] Post-Cached Sources:
[Librarian]   [:forge, "http://forge.puppetlabs.com", {}]
[Librarian]   [:git, "https://github.com/cescoffier/puppet-nexus.git", {}]
[Librarian]   [:git, "https://github.com/ripienaar/puppet-module-data.git", {}]
[Librarian]   [:git, "https://github.com/datacentred/datacentred-ldap.git", {}]
[Librarian]   [:git, "https://github.com/ghoneycutt/puppet-module-facter.git", {:ref=>"v2.0.0"}]
Dependency 'cescoffier-nexus' duplicated for module act-base, merging: ["cescoffier-nexus (>= 0.0.1) <https://forgeapi.puppetlabs.com>", "cescoffier-nexus (>= 0.0.1) <https://github.com/cescoffier/puppet-nexus.git#master>"]
Dependency 'datacentred-ldap' duplicated for module act-base, merging: ["datacentred-ldap (>= 0.3.0) <https://forgeapi.puppetlabs.com>", "datacentred-ldap (>= 0.3.0) <https://github.com/datacentred/datacentred-ldap.git#master>"]
Dependency 'ripienaar-module_data' duplicated for module act-base, merging: ["ripienaar-module_data (>= 0.0.4) <https://forgeapi.puppetlabs.com>", "ripienaar-module_data (>= 0.0.4) <https://github.com/ripienaar/puppet-module-data.git#master>"]
Dependency 'ghoneycutt-facter' duplicated for module act-base, merging: ["ghoneycutt-facter (>= 2.0.0) <https://forgeapi.puppetlabs.com>", "ghoneycutt-facter (>= 2.0.0) <https://github.com/ghoneycutt/puppet-module-facter.git#v2.0.0>"]
[Librarian]       Resolved act-base (>= 0.1.0) <git@github.com:weareact/puppet-base.git#develop> at act-base/0.1.0 <git@github.com:weareact/puppet-base.git#develop>
[Librarian]   Resolved act-base (>= 0.1.0) <git@github.com:weareact/puppet-base.git#develop>
[Librarian] Resolving cescoffier-nexus (>= 0.0.1) <https://github.com/cescoffier/puppet-nexus.git#master>

I've merged master into 1.x, you can try if the latest there works

Better, but still not perfect...
librarian-puppet install --clean --verbose --path /etc/puppet/modules
[Librarian] Ruby Version: 1.8.7
[Librarian] Ruby Platform: x86_64-linux
[Librarian] Rubygems Version: 1.3.7
[Librarian] Librarian Version: 0.6.3
[Librarian] Librarian Adapter: puppet
[Librarian] Librarian Adapter Version: 1.5.0
[Librarian] Project: /tmp/cataloguesvc
[Librarian] Specfile: Puppetfile
[Librarian] Lockfile: Puppetfile.lock
[Librarian] Git: /usr/bin/git
[Librarian] Git Version: 1.7.1
[Librarian] Git Environment Variables:
[Librarian]   (empty)
[Librarian] Deleting .tmp/librarian/cache
[Librarian] Pre-Cached Sources:
[Librarian] Post-Cached Sources:
[Librarian]   [:forge, "http://forge.puppetlabs.com", {}]
[Librarian]   [:git, "git@github.com:weareact/puppet-base.git", {:ref=>"develop"}]
Dependency 'act-base' duplicated for module, merging: act-base (>= 0.1.0) <http://forge.puppetlabs.com>act-base (>= 0.1.0) <git@github.com:weareact/puppet-base.git#develop>
[Librarian] Resolving act-base (>= 0.1.0) <git@github.com:weareact/puppet-base.git#develop>
[Librarian]   Checking manifests
[Librarian]     --- No output
[Librarian]     --- No output
[Librarian]     --- No output
[Librarian]     --- No output
[Librarian]     --- No output
[Librarian]     --> origin
[Librarian]     -->   origin/HEAD -> origin/develop
[Librarian]     -->   origin/develop
[Librarian]     -->   origin/feature/beaker_acceptance
[Librarian]     -->   origin/master
[Librarian]     --> fbb058d72cd59089cb363c2aa1a2926601171365
[Librarian]     --> fbb058d72cd59089cb363c2aa1a2926601171365
[Librarian]     Checking act-base/0.1.0 <git@github.com:weareact/puppet-base.git#develop>
[Librarian] Pre-Cached Sources:
[Librarian] Post-Cached Sources:
[Librarian]   [:git, "https://github.com/ghoneycutt/puppet-module-facter.git", {:ref=>"v2.0.0"}]
[Librarian]   [:git, "https://github.com/ripienaar/puppet-module-data.git", {}]
[Librarian]   [:forge, "http://forge.puppetlabs.com", {}]
[Librarian]   [:git, "https://github.com/datacentred/datacentred-ldap.git", {}]
[Librarian]   [:git, "https://github.com/cescoffier/puppet-nexus.git", {}]
Dependency 'ripienaar-module_data' duplicated for module act-base, merging: ripienaar-module_data (>= 0.0.4) <https://github.com/ripienaar/puppet-module-data.git#master>ripienaar-module_data (>= 0.0.4) <http://forge.puppetlabs.com>
Dependency 'cescoffier-nexus' duplicated for module act-base, merging: cescoffier-nexus (>= 0.0.1) <http://forge.puppetlabs.com>cescoffier-nexus (>= 0.0.1) <https://github.com/cescoffier/puppet-nexus.git#master>
Dependency 'datacentred-ldap' duplicated for module act-base, merging: datacentred-ldap (>= 0.3.0) <http://forge.puppetlabs.com>datacentred-ldap (>= 0.3.0) <https://github.com/datacentred/datacentred-ldap.git#master>
Dependency 'ghoneycutt-facter' duplicated for module act-base, merging: ghoneycutt-facter (>= 2.0.0) <http://forge.puppetlabs.com>ghoneycutt-facter (>= 2.0.0) <https://github.com/ghoneycutt/puppet-module-facter.git#v2.0.0>
[Librarian]       Resolved act-base (>= 0.1.0) <git@github.com:weareact/puppet-base.git#develop> at act-base/0.1.0 <git@github.com:weareact/puppet-base.git#develop>
[Librarian]   Resolved act-base (>= 0.1.0) <git@github.com:weareact/puppet-base.git#develop>

I thought the dependency resolution is a function of librarianp rather than librarian-puppet, so surely the version of that should be all that matters?
Cheers
Gav

yes, most likely. Take a look at https://github.com/carlossg/librarian/commit/befb958a380106143f178480962e646ef6e331b8
I'm not sure when I'll have time to look at it, so if you want to try to send a PR...

OK, I'll see if I can find where the issue is...
Cheers
Gav


Multiple cameras independent from the vehicle

Hi guys,
first of all thank you for your wonderful work!
I was wondering if there's any chance to use different cameras which are positioned in a certain real-world point and are independent from the position of the vehicle.
I started diving into the carla's code just today, so I'm certain I still miss something. Up to now I found that the Camera object has a set position method. However, in the client_example.py it looks like this position is always relative to the car position.
Conversely, I'd like to have the possibility to set one or more cameras in precise town position, independently from where the player's vehicle currently is.
Thank you again for your time
Andrea

Hi Andrea,
Exactly, from the client side it is only possible to add cameras relative to the player vehicle. I will mark this as "feature request" because I think it can be an useful feature for more people.
Now, if you are willing to hack into the Unreal project, you can already save images to disk from an arbitrary position. We have an actor called "Scene Capture To Disk Camera", just add this actor to the scene from the Modes tab and drop it wherever you want in the map

Now in the details panel you can adjust the camera parameters as you would do in the Python client

If you hit Play (or Simulate), this cameras will start recording images to disk. They are pretty slow but do the job.

Thank you for your prompt response.
Indeed I guess that this feature would be useful for many applications! In the meanwhile I'll give a try to the hack you suggested.
Thanks,
A.

Thank you for the response @nsubiron
Could you redirect me to the latest version which might be free of this bug?

@rawalkhirodkar Yes, I'll let you know when we have a fix

@rawalkhirodkar this bug is fixed in #333
cheers

@juaxix It works. Thank you!

Hello, I'm looking for the very same feature, but not sure whether I can use it as it is. What I need is to set several SceneCaptureToDisk cameras and capture frames from them, but at the same time I need to get their sensor data, i.e., have to run something like(from carla docs):measurements, sensor_data = client.read_data()
measurements, sensor_data = client.read_data()
for agent in measurements.non_player_agents:
agent.id # unique id of the agent
if agent.HasField('vehicle'):
agent.vehicle.forward_speed
agent.vehicle.transform
agent.vehicle.bounding_box
This code works fine for cameras added through settings.add_sensor()
However, if I just add SceneCaptureToDiskCameras through the editor, they, naturally, do not appear in the sensor_data.keys(). Is there any way to create them through the client code(or to refer to these editor-created cameras in the client code) in order to pass them to add_sensor(), in the same way as we do with cameras in client_example.py?
Thanks a lot

This is already possible with API 0.9.0.

Is it possible to change the focal length of these static sensors?


Ingest vhs1256b try2

Updated JSON files for VHS1256b and scripts for ingesting spectra.

Need to add original spectra before merging.


Minor styling improvements on inline highlight

this should be "fira-code" font and do not break the words

Found at: http://localhost:3000/til/how-to-fix-command-not-found-for-global-pnpm-packages


schemes dictionary problems

"If you would like to use a particular scheme, you can pick one from the dictionary quadpy.t2.schemes."  However,
kbriggs@Dell:~/python> python3
Python 3.6.9 (default, Oct  8 2020, 12:12:24)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import numpy
import quadpy
scheme=quadpy.s3.schemes['mysovskih']
scheme.integrate(lambda x: np.exp(0),[0.0,0.0,0.0],1.0)
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'function' object has no attribute 'integrate'

You need to instantiate the scheme first:
scheme = quadpy.s3.schemes['mysovskih']()

That's very non-obvious - it needs documenting.   Or could you have a lazy dictionary, which instantiates when looked up?
(Anyway "import quadpy" is bad as it typically imports too much.  Why not "from quadpy import s3"?)

That's very non-obvious

I agree. If you have a good idea how to handle this, let me know.

Ah, I just remembered one other hurdle: Some schemes have arguments, a parameter, and those obviously must be called with (something). That's why I once decided to make them all callable, and to avoid the long import times.

I thought about this some more and decided to keep things as they are.
Reasons:

A considerable number or schemes only make sense when instantiated with arguments. For example, all n-dimensional schemes need dim. Other schemes are really parametrized scheme families that need an alpha. It's consistent to have to instantiate all schemes, not just some.
This also fixes the slow import problem.
Implementing a "lazy dict" would perhaps be possible, but adds more complication.

If you can think of a method to work around these issues, let me know.

ok


All images look safe

I was happy to see all of our images come up as safe, but when I tried one that was known to be unsafe, it also showed as safe.  Have I possibly misconfigured?
I tried Aerospike <IP_ADDRESS> and got this:
$ docker images | grep aero
aerospike    latest                             1f38428d7a6f        12 days ago         153.2 MB
$ ./analyze-local-images -endpoint "http://<IP_ADDRESS>:6060" -my-address "<IP_ADDRESS>" 1f38
Saving 1f38
Getting image's history
Setting up HTTP server (allowing: <IP_ADDRESS>)
Analyzing 11 layers

Analyzing c950d63587be10331540688387593721eb728628b75cdaf1dcf266188dfc6e6b
Analyzing 3ba3ba0cdebdf6c3fc49dc6ee09f0c01d653796d925ef9c99b4c9ea988bcee7f
Analyzing d9376c3ba53cb09b9301a76d07e9a47c784b5d6d4829d6f5142a31339dd41da5
Analyzing<PHONE_NUMBER>7ad2f6373701d0515f3bda7e8e86f530416d0c8c493309d65d7a16
Analyzing fbb261c1559b777bcbb16a39a762ad32a478a050b730fedd61f1315ba404c50a
Analyzing 38a15afbc1c259497ea86103ded6274289c47e00967eeeab20b00e99e9b892df
Analyzing e997a3007992b4ef65921b0d4284b20a59b789da9a887794106e0328a70ae89d
Analyzing 975d8801fa166fd701505a6640f368cd70871d64b41d72a527e26f0811c6428d
Analyzing fa0642e3ade87b09cbc02c406ad3cc4902376a61ca322643934f4725a60205be
Analyzing 63b21889144306f2b65e874677fac6b8453fd9baf569eac399eeb44cfd1b022b
Analyzing 1f38428d7a6f1f67c84c1cc3ff8fd19a6b8bf5233e35a30d388992fa14056243
Getting image's vulnerabilities
Bravo, your image looks SAFE !

Within the running Clair container I took a look around for  CVEs and only found what looks like ubuntu-relevant CVES:
root@d1e39d76aa90:/go/src/github.com/coreos/clair# ls /tmp
aberr  k5_skip	tce  tcloop  ubuntu-cve-tracker386367386
root@d1e39d76aa90:/go/src/github.com/coreos/clair# ls /tmp/ubuntu-cve-tracker386367386/repository/active
-- shows around 3932 CVE's from CVE-2002-2439 to CVE-2015-8660
I also tried the curl commands on individual layers of the image and didn't get anything.
During setup, I had let the updater finsh not once but twice:
docker run -it  -v /tmp:/tmp -p 6060:6060 -p 6061:6061 clair:0.1 --db-path bolt
2015-12-29 18:50:56.093322 I | database: database at bolt does not exist yet, creating it
2015-12-29 18:50:56.100647 I | api: starting API on port 6060.
2015-12-29 18:50:56.101250 I | api: starting Health API on port 6061.
2015-12-29 18:50:56.102573 I | updater: updater service started. lock identifier: 6b423c83-4eca-4d72-80c8-4094db0fd45c
2015-12-29 18:50:56.104140 I | updater: updating vulnerabilities
2015-12-29 18:50:56.104371 I | updater/fetchers: fetching Ubuntu vulneratibilities
2015-12-29 18:50:56.130798 I | updater/fetchers: fetching Debian vulneratibilities
2015-12-29 18:50:56.137502 I | updater/fetchers: fetching Red Hat vulneratibilities
2015-12-29 19:08:36.082005 N | database: Ignoring 17060 notifications
2015-12-29 19:08:36.118490 I | updater: update finished
2015-12-29 20:08:36.008813 I | updater: updating vulnerabilities
2015-12-29 20:08:36.009312 I | updater/fetchers: fetching Ubuntu vulneratibilities
2015-12-29 20:08:36.012095 I | updater/fetchers: fetching Debian vulneratibilities
2015-12-29 20:08:36.013228 I | updater/fetchers: fetching Red Hat vulneratibilities
2015-12-29 20:09:38.079677 I | updater: update finished
Is the ignoring of 17060 notifications something that I might not want to ignore in my case?

Hi,
The files in /tmp are only used internally by the Clair updater to update its internal database with Ubuntu vulnerabilities. Clair also handle RHEL and Debian vulnerabilities (as shown in the logs), the files in /tmp are not relevant and does not define Clair's knowledge. Clair's knowledge is stored in its database (either Bolt, in-memory, PostgreSQL, ...). You can request data about specific vulnerabilities with the appropriate API call.
Notifications are something else too, they are used to tell a webhook about new or updated vulnerabilities. They are ignored on the first update, reason is pretty obvious. You don't really need to worry about this.
Now, about your issue,  as explained in this comment, you can basically debug and see what does Clair know about your images and ensure that Clair detected their operating system and packages properly. I'd start with that. If Clair did not detect any package/operating system - it can not tell anything. Also, in the logs you pasted, it doesn't seem that there is any analysis but just the updater running?
Also, please use master instead of 0.1 as a lot of things have been fixed, improved and modified. I don't think that the contrib tool you are using can even use 0.1 properly. There isn't a new release yet because the next release will be a major one, including profound changes in the database management: significantly improving the results, performances, accuracy, ...).

I tried the curl commands and it didn't return anything so that is certainly the root cause.  I will try with master and work out issues until I can see os and packages returned.
After the updater runs, and I try to analyze an image it does alot of POST /v1/layers:
2015-12-29 20:08:36.008813 I | updater: updating vulnerabilities
2015-12-29 20:08:36.009312 I | updater/fetchers: fetching Ubuntu vulneratibilities
2015-12-29 20:08:36.012095 I | updater/fetchers: fetching Debian vulneratibilities
2015-12-29 20:08:36.013228 I | updater/fetchers: fetching Red Hat vulneratibilities
2015-12-29 20:09:38.079677 I | updater: update finished
2015-12-29 20:39:12.452296 I | api: 201 POST /v1/layers (13.315908ms)
2015-12-29 20:39:12.471128 I | api: 201 POST /v1/layers (16.103432ms)
2015-12-29 20:39:12.485011 I | api: 201 POST /v1/layers (12.398084ms)
2015-12-29 20:39:12.499446 I | api: 201 POST /v1/layers (13.117661ms)
2015-12-29 20:39:12.517434 I | api: 201 POST /v1/layers (16.571963ms)
2015-12-29 20:39:12.534517 I | api: 201 POST /v1/layers (15.805879ms)
2015-12-29 20:39:12.546710 I | api: 201 POST /v1/layers (10.806028ms)
2015-12-29 20:39:12.560906 I | api: 201 POST /v1/layers (12.865442ms)
2015-12-29 20:39:12.580750 I | api: 201 POST /v1/layers (18.52829ms)
2015-12-29 20:39:12.591330 I | api: 201 POST /v1/layers (9.301349ms)
2015-12-29 20:39:12.609846 I | api: 201 POST /v1/layers (17.249646ms)
2015-12-29 20:39:12.627082 I | api: 201 POST /v1/layers (15.940935ms)
2015-12-29 20:39:12.641281 I | api: 201 POST /v1/layers (12.630593ms)
2015-12-29 20:39:12.655048 I | api: 201 POST /v1/layers (12.539726ms)
2015-12-29 20:39:12.673151 I | api: 201 POST /v1/layers (16.751349ms)
2015-12-29 20:39:12.685148 I | api: 201 POST /v1/layers (10.804623ms)
2015-12-29 20:39:12.700892 I | api: 201 POST /v1/layers (14.68342ms)
2015-12-29 20:39:12.711849 I | api: 201 POST /v1/layers (9.78777ms)
2015-12-29 20:39:12.729051 I | api: 201 POST /v1/layers (15.936753ms)
2015-12-29 20:39:12.740578 I | api: 201 POST /v1/layers (9.313641ms)

I am running master now with the same issue.  The problem is probably due to Clair not being able to access the layer.tar that  it needs to.  Using analyze-local-images, it posts the layer with a path of  h t t p : / / 1 9 2 . 1 6 8 . 9 9 . 1 : 9 2 7 9 / [imageId]/ l a y e r . t a r  but it never can get os, package, or vulnerabilities from it.  Is there an available way to see logs from the Clair container about whether it is actually finding this layer on this web server or not, I do not see much in the docker logs.

You can use --log-level=trace, it will definitely tell you more.

It says the OS is unknown on every layer, every image.  My environment might have something untested that's causing an issue locating the layer.tar's.  I am using docker-machine, running clair in one shell and analyze-local-images in another shell, setting docker-machine env to be the machine that clair is running in.
As an example, clair reports like this for every layer when I run analyze-local-images:
2016-01-04 17:24:43.045334 D | worker: layer 54da947db59aafbbc0f691c96d6d3eedabb123628e2268662e0eedd875603c8f: processing (Location: http://<IP_ADDRESS>:9279/54da947db59aafbbc0f691c96d6d3eedabb123628e2268662e0eedd875603c8f/layer.tar, Engine version: 1, Parent: 785ac3a080c0dc76bc66bb7ce5d492a00a64e1d2a09195b732b42bad8f0ee7a9)
2016-01-04 17:24:43.046205 D | worker: layer 54da947db59aafbbc0f691c96d6d3eedabb123628e2268662e0eedd875603c8f: OS is unknown.
2016-01-04 17:24:43.046513 D | worker: layer 54da947db59aafbbc0f691c96d6d3eedabb123628e2268662e0eedd875603c8f: detected 0 packages: installs 0 and removes 0 packages

I am getting 403 Forbidden as a response in worker.getLayerData so it cannot process anything else.  The code should probably fail to progress on this error, and since it doesn't, I cannot run the analyzer again because it stored flawed layer data under the layer ID.
I am running the container in one docker-machine shell on osx, and calling analyze-local-images from another docker-machine shell set up with the same env, e.g.:
./analyze-local-images -endpoint "http://<IP_ADDRESS>:6060" -my-address "<IP_ADDRESS>" imageID
I have tried using the container's internal address as the endpoint, but that just gives tcp timeouts.  Any ideas on how I might make the transient HTTP server amenable to this setup?

Hi,
I think that this line is relevant: https://github.com/coreos/clair/blob/master/contrib/analyze-local-images/main.go#L250

I can make it run from within the docker machine. Looks great now.  However, I still think it is worth fixing the code to report an error and abort if the layer data cannot be obtained, instead of reporting the image as safe.

True! Thank you so much for pointing that out and for your diagnostic. That's definitely an issue. I will address it as soon as possible.

I saw this issue with when running clair and "analyze-local-images/main.go" on two different VMs. Following change in analyze-local-images/main.go fixes the issue for me. I have not tried yet a scenario where the IPs are behind reverse proxies or load balancers:
func restrictedFileServer(path, allowedHost string) http.Handler {
fc := func(w http.ResponseWriter, r *http.Request) {

          if r.Host == allowedHost {

          //fmt.Printf ("r.RemoteAddr = %s r.Host = %s and allowedHost = %s\n", r.RemoteAddr, r.Host, allowedHost)

          //Get client ip address

          realIP,_,_ := net.SplitHostPort(r.RemoteAddr)

          fwdFor := r.Header.Get("X-FORWARDED-FOR")

          if fwdFor != "" {

                  fmt.Printf("--Fix me hdrForwardedFor = %s\n", fwdFor)

                  //realIP = fwdFor

          }

          if realIP == allowedHost {
                  http.FileServer(http.Dir(path)).ServeHTTP(w, r)
                  return
          }

Hi,
This contrib tool has not been meant to be used in any production environment (or behind any proxy/load-balancer) but simply as a tool to help users to analyze their local images and to show how the Clair API works.

This is closely related to #85, which I believe, implements your fix. We might want to upstream support for X-Forwarded-For if you need it. Feel free to submit a PR if it's the case.

@candita @kuldeepb We just merged a fix for #85. Does it fix the issue you have as well?

Closing for now due to inactivity and the fact that I believe this is fixed. Feel free to re-open if necessary.


Helm 3.13 is not backward compatible with 3.12

Output of helm version:
version.BuildInfo{Version:"v3.13.0", GitCommit:"825e86f6a7a38cef1112bfa606e4127a706749b1", GitTreeState:"clean", GoVersion:"go1.20.8"}

Output of kubectl version:
Client Version: v1.28.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.27.3-gke.100

Cloud Provider/Platform (AKS, GKE, Minikube etc.): Not applicable

I have found in a few projects that helm 3.13 is not rendering the same output as 3.12. I've set up a simple minimal reproducible example at https://github.com/zevisert/helm-3-13-rendering-mre
Either way, here's some console output showing what I'm running into:
$ helm version
version.BuildInfo{Version:"v3.12.3", GitCommit:"3a31588ad33fe3b89af5a2a54ee1d25bfe6eaa5e", GitTreeState:"clean", GoVersion:"go1.20.7"}

$ helm create example
Creating example

$ rm -r example/charts/ example/templates/*

$ echo '{{ include "helmet.app" . }}' > example/templates/app.yaml

$ yq e '. += ({"dependencies": [{"name": "helmet", "version": "~0.9.1", "repository": "https://companyinfo.github.io/helm-charts", "import-values": ["defaults"]}]})' < example/Chart.yaml | sponge example/Chart.yaml

$ helm dependency build example
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "helmet" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 1 charts
Downloading helmet from repo https://companyinfo.github.io/helm-charts
Deleting outdated charts

$ helm template example > templated-3.12.yaml

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh
Helm v3.13.0 is available. Changing from version v3.12.3.
Downloading https://get.helm.sh/helm-v3.13.0-linux-amd64.tar.gz
Verifying checksum... Done.
Preparing to install helm into /opt/tooling/helm/bin
helm installed into /opt/tooling/helm/bin/helm

$ helm version
version.BuildInfo{Version:"v3.13.0", GitCommit:"825e86f6a7a38cef1112bfa606e4127a706749b1", GitTreeState:"clean", GoVersion:"go1.20.8"}

$ helm dependency build example
Hang tight while we grab the latest from your chart repositories...
... This is also a case for #11162

@zevisert I think #12480 fixes your issue. I tested it against your example chart. Can you take a look.

@mattfarina I think this should make things work like most people would expect again. I'm a little wary about all these precedence changes going on in helm 3.13, but I suppose it's for the better.
I also think #11162 deserves some attention since you initially must have had a use-case for the values precedence when you were working on #12162

#10998
Helm 3.13 was actually compatible with anything below Helm 3.8.1. :( Helm 3.8.2 - 3.12 were the incompatible ones!

Can we have some comment from the maintainers of Helm whether 3.13 or 3.14 was an error and might be reverted again - right now Flux v2.2.2 is running Helm 3.13 and at least @hedayat here has a use case that prefers the 3.13 (and <3.8.2) behavior. I understand that it has been changed again in 3.14.
Flux is not able to upgrade to 3.14 immediately due to some unrelated issues that may be resolved in their own time.
I refer to all these issues, I'm not sure if there is any response. But if there is any chance that it will be reverted again, then Flux devs may abandon their efforts to migrate to Helm 3.14.
Ref:

https://github.com/helm/helm/pull/12480
https://github.com/helm/helm/issues/12511
https://github.com/helm/helm/issues/12599
https://github.com/helm/helm/issues/12677
https://github.com/helm/helm/issues/12730
https://github.com/fluxcd/helm-controller/issues/878
https://github.com/helm/helm/issues/12488

Again, I am asking for clarification only because right now there is an incompatibility that I'm not fully briefed on which prevents Flux from upgrading to Helm 3.14.x, if someone from the Helm project can weigh in, it may save us from some waste cycles, or help us better direct our efforts here.
Thanks friends

Can we have some comment from the maintainers of Helm whether 3.13 or 3.14 was an error and might be reverted again - right now Flux v2.2.2 is running Helm 3.13 and at least @hedayat here has a use case that prefers the 3.13 (and <3.8.2) behavior. I understand that it has been changed again in 3.14.

Hi @kingdonb and @hedayat, appreciate you raising this and asking again. Thanks for your patience and community collaboration.
We know there are a handful of people who are trying to reconcile which version of Helm had breaking changes and which ones fix them.
Maintainers have replied to questions and comments in issues and PRs, and have discussed these in weekly Helm dev meetings. However, I acknowledge we could be better about communicating where we are at with this, given that it seems to be not fully resolved for all use cases.
About the versions. While Helm values handling has worked for the majority of users, for less common use cases there have been several previous bugs for years. We attempted to fix some of these in Helm 3.13, but that introduced breaking changes we missed. We fixed the breaking changes in 3.14, but that seems to have introduced related bugs for other use cases like @hedayat’s. There may be versions or details I missed here, but we can test/document them together.
For now, we are working on Helm values handling as a high priority:

several dedicated working sessions over the past few weeks
discussed again in yesterday's weekly Helm dev meeting
currently clarifying the intended behavior for each method of managing values in Helm charts and their dependencies in this Google doc

Feel free to comment on that Google doc, just bear in mind it is very much a work in progress at present.
A good way to help this effort is to document your use cases. This would help us ensure there are automated tests for each, to catch bugs that would impact your use cases before any future PRs are merged.
If you have any further questions about this or other ideas on how you can help, the weekly Helm dev meetings are a good place to engage or coordinate with maintainers working on this.

@scottrigby
Thanks for your comprehensive reply. I've added a comment and a use-case to the doc.


cattle-cluster-agent and cattle-node-agent got 400 Bad Request when ping

Hi, all
I build up a HA rancher(v2.4.10) via K3S.
There're some special in the K3S cluster that

I've changed the SRC_PORT and containerPort and hostPort of  DaemonSet:svclb-traefik, so that , My cluster listens at 30080 and 30443. All things goes well....I can visit rancher via https://my-domain:30443.
my-domain has a public-CA signed certificate.
my-domain is polled to 3 ips.  my-domain  ---> ip1, ip2, ip3

In above cases , cattle-cluster-agent and cattle-node-agent could not run, they are aways Unavailable and restarted.
The log shows that:
INFO: Environment: CATTLE_ADDRESS=<IP_ADDRESS> CATTLE_CA_CHECKSUM= CATTLE_CLUSTER=true CATTLE_FEATURES=dashboard=true CATTLE_INTERNAL_ADDRESS= CATTLE_K8S_MANAGED=true CATTLE_NODE_NAME=cattle-cluster-agent-68799f7d6b-qcwgh CATTLE_SERVER=https://my-domain:30443
INFO: Using resolv.conf: nameserver <IP_ADDRESS> search cattle-system.svc.cluster.local svc.cluster.local cluster.local options ndots:5
ERROR: https://my-domain:30443/ping is not accessible (The requested URL returned error: 400 Bad Request)

I don't know why I meet 400 Bad Request and what causes.
I tried curl -k  https://my-domain:30443/ping on a node, it repsonsed 400 Bad Request
I tried curl -k  https://my-domain:30443/ping on other machine, it responsed "pong" as well
I tried curl -k https://my-domain:30443/ping in rancher pod's shell, it repsonsed 400 Bad Request
I tried curl -k https://rancher.cattle-system/ping in rancher pod's shell, it repsonsed "pong"
Can anyone give some help! Thanks!!

I found that, if I use
echo -n | openssl s_client -showcerts -connect my-domain:30443 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /root/test.crt
the content of test.crt is different between on node and on other machine
Why??what's happend??

Can you show the certificates? That is a good indication what is going wrong. If you are pointing it to 3 IPs, please query the IPs directly with a hostname (e.g. curl --resolve) or just point it to one IP if your DNS TTL is low enough to find what is causing the HTTP 400 and track it down from there (is it coming from NGINX, what is NGINX logging etc)

Can you show the certificates? That is a good indication what is going wrong. If you are pointing it to 3 IPs, please query the IPs directly with a hostname (e.g. curl --resolve) or just point it to one IP if your DNS TTL is low enough to find what is causing the HTTP 400 and track it down from there (is it coming from NGINX, what is NGINX logging etc)

Finally, I've found it was an certificates error.
In the node, wrong certificates got because of NAT configuration.
Thanks for your suggest!


Typo "Azure Pipeline YAML file"→"Azure Pipelines YAML file"

https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/sap/automation-configure-devops
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/virtual-machines/workloads/sap/automation-configure-devops.md
#PingMSFTDocs

@hyoshioka0128 : Thanks for your contribution! The author(s) have been notified to review your proposed change.


DataSignDoesntMatch exception since 0.5.0

HA core version
2024.7.2
Current integration version
0.5.1
Last known working integration version
0.4.3
Device type and model
Dehumidifier 00000Q17 (0) by Midea & Dehumidifier 00000Q12 (0) by Midea
Used App
none
The description of problem
Since 0.5.0 and now also on 0.5.1 I have issues with both appliances.
They are "unavailable" most of the time.
Logger: midealocal.device
Source: /usr/local/lib/python3.12/site-packages/midealocal/device.py:596
First occurred: 19:26:26 (1 occurrences)
Last logged: 19:26:26
[146235046613512] Unknown error : /usr/local/lib/python3.12/site-packages/midealocal/device.py, 572
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/midealocal/device.py", line 572, in run
result = self.parse_message(msg)
^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/midealocal/device.py", line 385, in parse_message
messages, self._buffer = self._security.decode_8370(self._buffer + msg)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/midealocal/security.py", line 356, in decode_8370
raise DataSignDoesntMatch
midealocal.exceptions.DataSignDoesntMatch
The logs
https://dpaste.org/683kn

How do I disable logging via call service?

I "think" but not sure that Dehumidifier 00000Q12 (0) by Midea has "no issues" since this is "online" a while now. Only the Dehumidifier 00000Q17 (0) by Midea will not come online...

This log is incomplete. I can't see the issue in the integration. Can you please provide full log?

Please help me how to do

Please help me how to do

https://github.com/wuwentao/midea_ac_lan?tab=readme-ov-file#debug

https://dpaste.org/jWmFr
I have reloaded 2 times here... hope this helps

Have you tried 0.5.2? Can you please install midea-local lib locally?
pip install midea-local
Then run midealocal discover --host <IP_ADDRESS> -d

I only see 0.5.1...?

Ok 0.5.2 installed. Now both mideas are not working anymore :-(

When reporting an issue, always attach fresh debug log

I added 2 fresh debug logs... all was so fine before 0.5.0 I really miss that... How to get back?

Fresh log: https://dpaste.org/mmEPw

The root cause is the failure to retrieve capabilities. This should fix https://github.com/rokam/midea-local/pull/217

I would love this to be fixed again... I rely on this marvelous piece of sw

@sanderlv can you confirm 0.5.3 fixes the issue?

Hi, currently I reverted to 0.4.3 and all works. I will test after holiday period asap. Thanks in advance!

0.5.4 fixes! Thank you!


Improve already providing completions in ballerina shell

Description:
$Title
Describe your problem(s)
Currently we are providing a predefined hardcoded set of keywords as completions for any use case. Some completions are incorrect and some are missing. ex: fail keyword

 [check](https://github.com/ballerina-platform/ballerina-lang/blob/master/ballerina-shell/modules/shell-cli/src/main/resources/command.keywords.txt)
Describe your solution(s)
Get the keywords using SyntaxInfo.keywords() instead of hardcoding them.

Will not be prioritised as of now.


clear the dataset cache on explicit pre-tokenization

TheBloke reported that when experimenting with custom prompt strategies, the transformed dataset gets cached and has to be manually cleared. This will clear it automatically when --prepare_ds_only option is set.

Hm, would it be better to make it to not load from cache (or clear all cache) on load? I think we had the discussion about caching pre-tokenization? Can we take this time to base it off the lack of dataset_prepared_path?

Hm, would it be better to make it to not load from cache (or clear all cache) on load? I think we had the discussion about caching pre-tokenization? Can we take this time to base it off the lack of dataset_prepared_path?

In this case, dataset_prepared_path wouldn't matter. The caching is the native datasets caching that caches transforms on the dataset.

Could we, if not cfg.dataset_prepared_path: clearcache()?

Thanks Wing!

Could we, if not cfg.dataset_prepared_path: clearcache()? I'm not clear if using prepare_ds_only to indicate no cache makes sense.

Yeah that sounds good. Yesterday I was doing training and I left out dataset_prepared_path thinking it might solve the problem, so it's logical to link those IMHO.
I know they're different caching processes, but it's logical to think that all caching will either happen or not happen together.
Also, leaving out dataset_prepared_path doesn't stop it saving its prepared dataset - it just creates last_run_prepared instead.
In total I would love to see:

A way to disable it saving prepared runs - either dataset_prepared_path is blank, or else a new boolean. I prefer the former; I didn't like that it added last_prepared_run in the current folder, especially as it's not mentioned in .gitignore
Some way to disable the HF dataset caching as Wing mentioned - I think that's best linked to 1, or it could be a new boolean perhaps.

Thanks very much

To add: I do agree that just linking it to prepared_ds_only isn't quite enough.  For example if I aborted training, or I wanted to re-run training with tweaked prompt_strategy code, I would still need to manually delete both the datasets and last_run_prepared entries
Ideally I would like a solution where I don't have to remember to manually delete the prepared and cached datasets, both when I've just done prepare_ds_only (which I do only to test my prompt_strategy code with --debug`, and when a previous run has been done on this same dataset JSON.

@TheBloke this new PR will clear the cache whenever prepare_ds is called. it also adds a new cli python -m axolotl.cli.prepare_ds examples/your.yml  (you can still use the old cli too, and it will use the new behavior)

Hello caseus, what if we have a new cfg as @TheBloke mentioned? dataset_use_cache: false? This would be very explicit.

I'd vote for a much more explicit config parameter. prepare_ds_only implies absolutely nothing about cache in my world.

Yeah I agree that a specific config param would be best.
While prepare_ds_only has been brought up again, I've been meaning to mention for a while that this param is no longer functional, in the sense that it no longer only prepares the dataset.
Running python3 -m axolotl.cli.train config.yaml --prepare_ds_only --debug will now proceed on to training, necessitating a Control-C to abort this manually.
(I've not checked to see if --prepare_ds_only still does something useful, like interacting with --debug, or whether it's now completely non-functional.)
Here's a log of that happening - you can see the final example_labels message, followed by it then starting to train
[2023-11-24 22:41:47,011] [INFO] [axolotl.check_example_labels:36] [PID:17755] [RANK:0]

[2023-11-24 22:41:47,011] [INFO] [axolotl.scripts.load_datasets:330] [PID:17755] [RANK:0] printing prompters...
[2023-11-24 22:41:47,011] [INFO] [axolotl.scripts.load_datasets:332] [PID:17755] [RANK:0] Pre-tokenized or custom dataset types are unsupported for logging
[2023-11-24 22:41:47,024] [DEBUG] [axolotl.train.log:60] [PID:17755] [RANK:0] loading tokenizer... Intel/neural-chat-7b-v3-1
[2023-11-24 22:41:47,338] [DEBUG] [axolotl.load_tokenizer:100] [PID:17755] [RANK:0] EOS: 2 / </s>
[2023-11-24 22:41:47,338] [DEBUG] [axolotl.load_tokenizer:101] [PID:17755] [RANK:0] BOS: 1 / <s>
[2023-11-24 22:41:47,338] [DEBUG] [axolotl.load_tokenizer:102] [PID:17755] [RANK:0] PAD: 2 / </s>
[2023-11-24 22:41:47,338] [DEBUG] [axolotl.load_tokenizer:103] [PID:17755] [RANK:0] UNK: 0 / <unk>
[2023-11-24 22:41:47,338] [DEBUG] [axolotl.train.log:60] [PID:17755] [RANK:0] loading model
Downloading shards: 100%|████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 2/2 [00:00<00:00, 14.39it/s]
Loading checkpoint shards:   0%|                                                                                | 0/2 [00:00<?, ?it/s]Loading checkpoint shards:   0%|                                                                                | 0/2 [00:14<?, ?it/s]
Traceback (most recent call last):
  File "/root/miniconda3/envs/py3.10/lib/python3.10/runpy.py", line 196, in _run_module_as_main
(CONTROL-C)

@TheBloke , regarding your second point, the cli has been updated to axolotl.cli.preprocess https://github.com/OpenAccess-AI-Collective/axolotl/tree/main#preprocess-dataset
Concerning this PR, you can now leave dataset_prepared_path: as empty, and it won't load from cache anymore, but will still save to cache in case you need it later. Does that solve the problem? We wish to make this clearer.

@NanoCode012 ahhh I see! I missed that change. That explains it then. My bad.
Could I suggest that if --prepare_ds_only is not going to do anything, it should generate an error if used on axolotl.cli.train?
And that's great to know regarding dataset_prepared_path.  That behaviour sounds fine.  Thanks for the info!
By the way, it's slightly off-topic, but as we're talking about preparing datasets and rather than open an Issue specifically for it:  do you know why Wing implemented this change in utils/tokenization.py https://github.com/OpenAccess-AI-Collective/axolotl/blob/main/src/axolotl/utils/tokenization.py#L34 :

Specifically, telling it not to output a space between tokens when text_only is used?
It makes the output really hard to read, and means you can't spot the token boundaries.  At first I assumed it must be a bug but then I looked at the commit history and realised it was done deliberately.  I can PR a change to remove it but maybe there's some good reason for it I've not realised?

@TheBloke , sorry for late reply.

By the way, it's slightly off-topic, but as we're talking about preparing datasets and rather than open an Issue specifically for it: do you know why Wing implemented this change in utils/tokenization.py https://github.com/OpenAccess-AI-Collective/axolotl/blob/main/src/axolotl/utils/tokenization.py#L34 :

I am not aware of why as well. It does make things hard to read. Perhaps, we can move this to a new issue/PR and hopefully ask for a change?

OK sure, I will open a little PR for it and then if there's some reason, Wing can tell us there.  Maybe it was just a mistake.
Thanks for your help!

Closing this as we fixed this with cli.preprocess


Self generated cacheId?

Hi, I really like this package and I use a lot in my project, but it's bothersome to set cacheId for erver table.
Would it be better that cacheId could self generated?

Here is my PR #44, but I don't know how to pass the test.
Is there any advice?
Thanks.

PR #44 had been merged.


fix: powerbi-docs/visuals/power-bi-visualization-customize-x-axis-and-y-axis.md

visuaization -> visualization
Remove duplicate link that was emedded in the same one

@nschonni : Thanks for your contribution! The author, @mihart, has been notified to review your proposed change.

Verified the changes.

@ktoliver : Thanks for your contribution! The author, @mihart, has been notified to review your proposed change.


tech debt

Some tech debt is starting to slowly creep in:

[x] build warnings are ignored.
[x] typescript typing is implemented sporadically, and likely badly implemented.

[x] add coverage report, and upload as artifacts

[x] selenium tests run against live site: needs to run again local build.
[x] remove timestamps from test report in README
[ ] decide what to do with libs that won't run in backend

Closing for now. Will likely re-open later.


Sketch default date fix

With the default date being this now %works_date_only% is no longer of any use (which it wasn't really before, considering one could just use their own format)

not sure why shown as pull request, but the code already in the master

not sure why shown as pull request, but the code already in the master

This is Modifying PixivModelSketch.py , not PixivImage.py

ah, I missed it. I'll update from my side.


Comments plugin - forever the spinner

So, the safe://diy.yvette comments seemed to work for a short while but the following day I saw the spinner not resolve to content and no comments display.
Today I see that beaker has a console that notes error suggesting:
comments-tutorial.js:242 Error: {"error":"Get StructuredData handle failed with status 400 Bad Request","errorPayload":{"method":"GET","headers":{"Authorization":"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IitqN2NDUzF2VmpwcjRBUEhmd1ZOVWNLcFNHMzZTaW5oSVh1SUduYlIvZnc9IiwiaWF0IjoxNDc1NzczOTMxfQ.4-mki6nbyH6lhXrbLe8z7Qn4hz1OLnSqwRE_BQxfs94"}},"errorUrl":"http://localhost:8100/0.5/structured-data/handle/2"}
    at onCbReply (/home/davidpbrown/SAFE/SAFE10/safer-beaker-browser-0.2.11/resources/app.asar/node_modules/pauls-electron-rpc/lib/import-api.js:179:17)
    at EventEmitter.onIPCMessage (/home/davidpbrown/SAFE/SAFE10/safer-beaker-browser-0.2.11/resources/app.asar/node_modules/pauls-electron-rpc/lib/import-api.js:118:14)
    at emitMany (events.js:127:13)
    at EventEmitter.emit (events.js:201:7)

that was while logged in as owner, so would expect no errors re authorisation. I don't know if that is lost data stopping the loading of whatever does remain.

I found I can clear the console log and a cleaner check for error on simple load of page, gives:
comments-tutorial.js:242 Error: {"error":"Get StructuredData handle failed with status 400 Bad Request","errorPayload":{"method":"GET","headers":{"Authorization":"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IkE2aGFhbFd2bURCc2czZTN2dnU2VVJQcU0zNHlrWTUyOEhqZ2dJSzZDM3M9IiwiaWF0IjoxNDc1Nzc5MDE0fQ.q3r3khDYh5JZDaNMqlkNQDhuETieeSlw3NGbh-BUJKg"}},"errorUrl":"http://localhost:8100/0.5/structured-data/handle/567"}(…)window.safeStructuredData.getHandle.then.err @ comments-tutorial.js:242
comments-tutorial.js:243 No blocked user structured data found

I've now also hacked the .js and .css enough that the spinner doesn't occlude the comments box and I note that submitting makes some change that allows past comments to display.. but not the comment just submitted. So, some glitch there that submit prompts enough to make progress. I'll leave as is for now in that submit will allow users to then see the list if the submit (something or nothing).
Off topic - submit of empty comment, creates a comment where perhaps that should bounce.

After a longer period, perhaps 10mins, it seems that the comments to appear.. duplicated as pair of each comment.

Will check this issue, @davidpbrown. The log related to  No blocked user structured data found seems to be fine, although it shouldn't be printed in error console. Will try to reproduce the issue and address it.
Thank you.


Support HTTPoison/hackney pools

At the moment hackney pools are disabled which means:

no control on the maximum number of requests in-flight (max_connections)
connections are not reuse

Golden plating would be to be able to have a pool per service.
https://github.com/benoitc/hackney/tree/b29a643c572bb83f8089bd57c373e7aaf1e86608#use-the-default-pool

So, this is something I'm not going to change for two reasons.

Pools have exhibited broken behavior in high load situations (hex.pm specifically) and are thus not a safe default.
It's trivially easy to set them yourself, on a per service or arbitrary basis.

Example:

Updated with example.

I don't know the details of hex.pm issues with hackney pools but hopefully the configurations used was not the one that you sugested as they would cause serious issues.
IMO right set up should be:

Before sending requests start the pool and set the max connections and the connections TTL

pool_name = :s3
options = [{:timeout, 120_000}, {:max_connections, 100}]
:ok = :hackney_pool.start_pool(pool_name, options)

Notes:

The timeout IMO should be chosen on per service basis. A simple test is doing a telnet HTTP requests and check the avg disconnect time done by the service and subtract ~20%. This way hackney will disconnect proactively and connect again while if the service (S3) disconnects there's a latency to hackney acknowledge the disconnect and it can try to use a disconnected connections. Natural overhead here, so just trying reduce it. One can argue that if the timeout if bigger than the service disconnect would take full advantage of the connection TTL given by the service. However, that's not deterministic and I favour deterministic approaches.
Max connections should be per usage basis. Meaning it depends on: OS, hardware and service usage. By default hackney will set the pool max_connections to 50 which might not be enough depending on the service. S3 is a candidate to not use the default pool value as requests can take a long time (seconds) which will jam the pool. Load tests are required to tune the max connections (same as official SDKs - not sure if all of them).

Use your example

I won't discuss the why pools/queue are extensively used on IO, specially on high load situations. That's a long thread by itself! But if there isn't a known bug/issue on the hackney pools in my case I'll use them.
Down the line you're right. I can easily use hackney pools without a library change. I was missing what you reply as an example. Thank you :)

Hex.pm disables the hackney pool: https://github.com/hexpm/hex_web/blob/master/config/config.exs#L39-L41 because we had issues where connections were not returned to the pool. This would cause all requests to eventually stop without any errors because their is no timeout on checking out from the pool.

I'm perfectly aware of how pools are used with IO. I've disabled pools in hackney not on the basis of some general stance towards pooling and IO but, as I said, because the particular pool implementation hackney uses has exhibited crippling behavior in production.
However, feel free to configure hackney however you like. The whole point of the adapter pattern I've taken with the request module is that ExAws doesn't need to take an opinionated stance here. I've chosen what are known safe defaults for httpoison. When their pool situation improves, I'll consider enabling it again by default.
"hopefully the configurations used was not the one that you sugested as they would cause serious issues." care to elaborate? My example simply indicates how one might use a particular pool name in an adapter, I wasn't advocating any particular recv_timeout value or pool size.

Hi @ericmj
That's a serious issue! Going without some application throttling is something I can't consider...
So, I've tried to replicate the issue by having a simple node.js server that never responses and making hackney (version 1.3.2) requests using a pool. I wasn't able to replicate the exact behaviour that you've described but I've got some unexpected weirdness.
So, I think I'm going to ditch hackney for the time being, at least until the pool issues are solved. It sounds I'll be researching for a new HTTP lib to use...
Thank you for sharing the hex.pm issue. It was very helpful.

Hi @benwilson512
Sorry if I sounded harsh. It wasn't my intention at all. I'm not native in English and sometimes I write things sounding wrong. My apologize.

"hopefully the configurations used was not the one that you sugested as they would cause serious issues." care to elaborate?

I'll speak on my experience of releasing a game where the player assets are stored on S3 and have in average 400KB. In peak time we had ~55000 CCUs which means that we were doing around 400 req/sec to S3 (List/Put/Get/Copy) per Ec2 instance. We build the game server in .net 4.5 and the library was the official one. By default max connections were 50 as hackney. On the load tests I've bump the number of connections to 150 base on load tests results. It wasn't a complete disaster by luck... The requests started to queue up in such a way that we almost ran out-of-memory and naturally a high performance hit on the receive timeout exceptions. This had even more impact because S3 latency is not predictable as in Dynamo (latency is 1 digit figure) so in the load tests we had an average of 200ms of latency and on production we had times of 900ms with spikes up to >2s (Nothing wrong how the assets were stores as we follow S3 best practices extensively).
Lessons learned:

The ones that I've wrote above
Load test are not good enough (this one I knew but you know...)
S3 is a b****
Pools must be in place
Pool sizing is a science when you can't predict latency

So my statement can be miss leading as I don't know what's "high load" on hex.pm means. But I've assume, wrongly, that the 50 max conns weren't enough by linking to my experience on S3.
Once again, I apologize if I sounded harsh on you. It wasn't my intention.

Hello @mr-bt,
Did you get to production with the app you were working at? AWS really encourage reusing connections and I would like to know your experience on tweaking HTTP clients in that respect.
Thanks.


Add support for COG mosaic

This will allow users to display a mosaic of Cloud-Optimized GeoTIFF (COG) files.
Reference: https://github.com/developmentseed/titiler/blob/master/docs/examples/Working_with_MosaicJSON.ipynb

This feature has been implemented. Users can now use Map.add_COG_mosaic() to load a virtual mosaic of of Cloud-Optimized GeoTIFFs (COG). See this example.


#63: added client certificates config option

Added a new config option, ClientCertificates, to lib/util/tls/type.go.

Looks like a failing test - working on a fix.

 The config needs changing so that you specify a list of certificate file paths, then you read and load them in the Get call.

Rebase on master and that test is gone.

Perfect - will have a full update on this within the next hour.

@Jeffail tests are passing, let me know if the change looks like what you had in mind! 🙂

Look great, I've merged into a temporary branch for now as I also made a breaking change to the root CAS field. If you and @nwest1 could run it and make sure it works for your use case I'm happy to merge.

Branch is at: https://github.com/Jeffail/benthos/tree/feature/tls-configs

Taking a look at this now.

This is working for me!


README updated

Revamped README.md of this project.

give @ritvij14 25 points

@janvig @sanket143 This was a readme change, so do you think 25 points is justifiable?

@abhinavraj23 we were considering 5 points for small changes like typos or style changes and it is much more than that so it is indeed worth more than 5 points.


Orientation Change Portrait to Landscape Issues on iOS 14

ISSUE & REPRODUCTION
When viewing the core demo (https://swiperjs.com/demos/010-default/core.html) on an iphone, and changing orientation to landscape, the slide is offset towards the top. This cuts off the top area of a slide, and instead shows an empty grey area at the bottom.
This is happening on an iphone 6s - browser: Safari; not sure about other phones.
I have made my own swipe, with my own slides, according to documentation, but getting the exact same issue.
EXPECTED BEHAVIOUR
Orientation change aligns & fits slide to screen correctly
Does anybody know how to remedy this issue and move the slides down? straight forwards css did not work for me.

And if you disable Swiper, it will be the same, so closing as not related to Swiper, for me more like iOS issue/feature

Is it though? Please try it on your phone. Your script is changing the html, adding styles to it. I think this may be misaligning your content. We know it is possible to line up content with the bottom of the screen when not using swiper. The fact that it is no longer possible WHEN using swiper suggest that this clearly is a Swiper issue. Please reopen.


[grahpql] Move SystemState into Epoch

Description
Moves the system state summary unique fields into the Epoch struct. It removes validatorSet from SystemStateSummary as this is part of the Epoch anyway, and it will be retrieved correctly according to the given epoch.
Supersedes #15398.
Test Plan
Used existing tests.

If your changes are not user-facing and not a breaking change, you can skip the following section. Otherwise, please indicate what changed, and then add to the Release Notes section as highlighted during the release process.
Type of Change (Check all that apply)

[ ] protocol change
[ ] user-visible impact
[ ] breaking change for a client SDKs
[ ] breaking change for FNs (FN binary must upgrade)
[ ] breaking change for validators or node operators (must upgrade binaries)
[ ] breaking change for on-chain data layout
[ ] necessitate either a data wipe or data migration

Release notes

Could we have an e2e test that creates two epochs, makes system state changes at both, and validate that each epoch fetches the correct data?

Yes, let's do that! Thanks for the feedback.

Thanks @wlmyng and @amnn for the excellent feedback. I addressed it all and will merge once the CI is green.


[Feature Request] don't invoker input click in component Upload

Existing Component
是
Component Name
Upload
Description
// upload.vue
handleClick() {
  if (!this.disabled) {
    this.$refs.input.value = null;
    this.$refs.input.click();
  }
},

don't do this, it not working on iOS safari
.el-upload {
  position: relative;

  .el-upload__input {
    display: block !important;
    opacity: 0;
    position: absolute;
    left: 0;
    top: 0;
    width: 100%;
    height: 100%;
  }
}

if disabled = true, file[type=input].display = none

Element is designed for desktop. It's not compatible with mobile devices.


embed relaxng validation into gem for output

Should validate output against the RFC XML schemas as a courtesy: if output is invalid, and we can't make it valid automatically, user needs to be warned. This is important for v3, for which rfc2xml has not been implemented yet.

Done


Support for object styles

To be on part with emotion and styled api, I would suggest supporting object styles.
For example:
export const ThisIsTheCSS = () => {
  return (
    <div
      className={css({
        color: "white",
        padding: "8px",
        background: "blue"
      })
    >
      hello world
    </div>
  );
};

This will make it easier for more projects to adopt kuma-ui for styling.

@OhadBaehr
Thank you for the suggestion!
Indeed, incorporating object styles would be a great addition, and it's something I've been considering. However, there are a few challenges that we need to address before moving forward with this idea.
Firstly, allowing object styles means we can embed not only string literals but also variables and even objects defined elsewhere in the code:
const cssObj = {
    color: 'red'
}
<Box className={css({...cssObj, { color: 'blue'}})} />

This significantly complicates static analysis and could potentially increase the time it takes to analyze the code.
Secondly, figuring out how to integrate this with the React Server Components while using our Hybrid Approach is another hurdle. While it's straightforward to add a "use client" directive to components, determining where functions like css are executed can be unpredictable until the JS is run, which presents a challenge.
I'm definitely keen on exploring this further, but I want to ensure we approach it in a way that maintains the efficiency and effectiveness of the library. I appreciate your understanding as we navigate these complexities.


[Feature] Do not depend on ActiveSupport

Would it be a big effort to drop dependency on ActiveSupport?
I'd like not to pull this dependency in my Ruby-only project.

Thanks for the issue!
See #903. The short version is that we are not likely to drop ActiveSupport.

Sorry didn't see this issue.
Understood, closing this issue.


md5 bash script handling

running md5 if osx, md5sum otherwise, also ignoring hash1/hash2 in git.
decided not to actually wait for #76  and just do the quick win.
WDYT?

Can one of the admins verify this patch?


Example script saves to a single zarr

Fixes #296

This PR combines changes to the example scripts with changes to the CLI. I haven't tested the CLI changes yet.

My fault! Fixed now.


Update maven-plugin-annotations to 3.10.1

About this PR
📦 Updates org.apache.maven.plugin-tools:maven-plugin-annotations from 3.9.0 to 3.10.1
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.apache.maven.plugin-tools", artifactId = "maven-plugin-annotations" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.apache.maven.plugin-tools", artifactId = "maven-plugin-annotations" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #249.


Extended 'spo page clientsidewebpart add' to include dynamicDataPaths and dynamicDataValues

Extended 'spo page clientsidewebpart add' to include dynamicDataPaths and dynamicDataValues resolving #751

Coverage remained the same at 100.0% when pulling 13249687a3e4ec528108209c24bf455dff5f3160 on mpowney:fix/dynamic-data-in-clientsidepages into 8354ad6d7fb2cfe21f428f988f98886e9ac0e626 on pnp:dev.

Awesome! Thank you @mpowney 👏

Merged manually. Thank you! 👏


Exception / error handling is reporting the wrong error

In this code piece: https://github.com/osism/openstack-image-manager/blame/4aa9fca869d3f25c1f4d54dab791c4eee606b599/openstack_image_manager/manage.py#L290-L336
there is an exception handling. If an exception is caught a specific error regarding the checksum url is gives as feedback to the user.
However aside from the specific case in which an exception is raised (https://github.com/osism/openstack-image-manager/blob/4aa9fca869d3f25c1f4d54dab791c4eee606b599/openstack_image_manager/manage.py#L314) exceptions can occur in other places, in those cases the printend error is misleading.

@fkr Take a look here, this should fix up your mentioned issues:
https://github.com/osism/openstack-image-manager/pull/658


Need the publish task for docs

Use gulp-gh-pages for that. Prompt before publishing.
Do when the docs are ready and it's safe to try it (there is an option for dry run in gulp-gh-pages - but do you trust it?).

And, yeah, consider using  https://github.com/SBoudrias/Inquirer.js/ for prompting

Unfortunately, GitHub Pages engine disables all custom Jekyll plugins for safety reasons.
So, if we want to go with automatic anchor links (which I'm going to implement via a plugin), we need to build the website locally and then push it to gh-pages instead of pushing Jekyll sources

build the website locally

We have task for this already, so it's not a big problem I think

yep, I just post this as a reminder

Before building the website, this task should check that the local Jekyll is > 3.0
(we happen to use extensionless permalinks)


ANC - Outside Care - Preclampsia [4h]

Issue
We need to add a screen for preeclampsia in outside care. The screen should only appear if they select preeclampsia in the initial outside care screen (the same as the other outside care There is no next steps logic associated with these inputs but are used for data gathering.

To Do:

Style screen per design
Add screen into Outside Care

@balagan73 please test on Nutrition env

https://nutrition-ihangane.pantheonsite.io/
QA Review
Found issues and questions:

Typo in  Amlodipine dosage

Shouldn't the medication administered in outside care be noted on the report page? Currently it doesn't display.

Checked and approved:

Question about medicine displays when Mild to moderate preeclampsia is selected.

@anvmn please fix typo and and check question about medication.


Remove utxo parameter from announce-auction. The CLI will now look in…

… the user UTxOs for a token matching the Mona Lisa asset.
Closes #113

@nazrhom Sorry, did not know about that feature. Thanks for explanation.


allow custom engine instantiation

Due to https://github.com/RxNT/json-rules-engine-simplified/issues/31 it is currently not possible to use custom predicates. A quick hack would be to allow custom Engine instantiation as then one would be able to not pass a schema which would not trigger validation. and validation in this case is the reason for the ticket mentioned above.

@theluk @mavarazy I need this change, I saw it merged to master but hasn't released yet.. so when I npm install, it still give me 0.3.12 instead of 0.3.13. Can you release 0.3.13?

Hello, i am trying to add custom engine to extend the predicates... @theluk, can you please share a code snippet if you could because even after adding the rulesRunner, my rules are not applied on the json form, i am getting in promise as schema, uiSchema and formData only... but how would i use the doRunRules to apply the rules on my form ??


Hello World

Write Hello World in README

IBM Cloud toolchain: Delivery Pipeline deployed sample-cloud-native-toolchain-tutorial-20180304184701834 to test, including commit e237035ede7daca16bfbaa3ab189f53ae3141548


backend/session: wait for session to become active

with seatd as libseat backend, when there is one sway already running on one terminal, new sway on the other terminal could not be started. originally issue was reported to seatd. testing offered change for seatd revealed actual problem in wlroots wlr_backend_autocreate. after wlr_session_create, it is proceeding to further initialization without ensuring if just created session is active or not. this PR wraps original wlr_session_create with waiting on session->events.active. code is based on wlr_session_find_gpus, thus i had to move wlr_session_create below it, as it reuses same functions. original wlr_session_create is renamed to _wlr_session_create

Debug logs before:
00:00:00.000 [INFO] [sway/main.c:347] Sway version 1.6.1
00:00:00.000 [INFO] [sway/main.c:348] wlroots version 0.14.1
00:00:00.002 [INFO] [sway/main.c:155] Linux nomad-lp1 5.13.13 #1 SMP 1 x86_64 GNU/Linux
00:00:00.002 [INFO] [sway/main.c:143] LD_LIBRARY_PATH=
00:00:00.002 [INFO] [sway/main.c:143] LD_PRELOAD=
00:00:00.002 [INFO] [sway/main.c:143] PATH=/run/setuid-programs:/home/greeter/.config/guix/current/bin:/home/greeter/.guix-profile/bin:/run/current-system/profile/bin:/run/current-s
ystem/profile/sbin
00:00:00.002 [INFO] [sway/main.c:143] SWAYSOCK=
00:00:00.002 [DEBUG] [sway/server.c:47] Preparing Wayland server initialization
00:00:00.002 [INFO] [wlr] [libseat] [libseat/libseat.c:67] Seat opened with backend 'seatd'
00:00:00.002 [INFO] [wlr] [backend/session/session.c:110] Successfully loaded libseat session
00:00:00.002 [ERROR] [wlr] [backend/session/session.c:291] Failed to open device: '/dev/dri/card0': Operation not permitted
00:00:00.003 [INFO] [wlr] [backend/backend.c:223] Found 0 GPUs
00:00:00.003 [ERROR] [wlr] [backend/backend.c:371] Failed to open any DRM device
00:00:00.003 [ERROR] [sway/server.c:53] Unable to create backend

Debug logs after:
0:00:00.000 [INFO] [sway/main.c:347] Sway version 1.6.1
00:00:00.000 [INFO] [sway/main.c:348] wlroots version 0.14.1
00:00:00.001 [INFO] [sway/main.c:155] Linux nomad-lp1 5.13.13 #1 SMP 1 x86_64 GNU/Linux
00:00:00.001 [INFO] [sway/main.c:143] LD_LIBRARY_PATH=
00:00:00.001 [INFO] [sway/main.c:143] LD_PRELOAD=
00:00:00.001 [INFO] [sway/main.c:143] PATH=/run/setuid-programs:/home/greeter/.config/guix/current/bin:/home/greeter/.gu
ix-profile/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin
00:00:00.001 [INFO] [sway/main.c:143] SWAYSOCK=
00:00:00.001 [DEBUG] [sway/server.c:47] Preparing Wayland server initialization
00:00:00.001 [INFO] [wlr] [libseat] [libseat/libseat.c:67] Seat opened with backend 'seatd'
00:00:00.001 [INFO] [wlr] [backend/session/session.c:110] Successfully loaded libseat session
00:00:00.002 [INFO] [wlr] [backend/session/session.c:557] Waiting for a session to become active
00:00:00.438 [INFO] [wlr] [libseat] [libseat/backend/seatd.c:222] Enabling seat
00:00:00.440 [INFO] [wlr] [backend/backend.c:223] Found 1 GPUs
00:00:00.440 [INFO] [wlr] [backend/drm/backend.c:182] Initializing DRM backend for /dev/dri/card0 (i915)
00:00:00.440 [DEBUG] [wlr] [backend/drm/drm.c:84] Using atomic DRM interface
00:00:00.440 [DEBUG] [wlr] [backend/drm/drm.c:98] ADDFB2 modifiers supported
00:00:00.440 [INFO] [wlr] [backend/drm/drm.c:259] Found 4 DRM CRTCs
00:00:00.440 [INFO] [wlr] [backend/drm/drm.c:186] Found 32 DRM planes
00:00:00.489 [INFO] [wlr] [render/egl.c:312] Using EGL 1.5
00:00:00.489 [INFO] [wlr] [render/egl.c:313] Supported EGL client extensions: EGL_EXT_client_extensions EGL_EXT_device_b

closing in favor of #3180


Swagger yaml is large and hard to manage manually

The current swagger yaml file grows every day and its hard to work with.
The following pain points exist:

too large (editor gets laggy)
everything is in one file (splitting failed the last time we tried)
failures can be overlooked because it contains a lot of duplications

the issue is just a placeholder and could grow overtime, we need to find a way how we could fix the above issues.

Interesting read https://chriskapp.medium.com/typeapi-an-alternative-to-openapi-e666eefe8a76


How do I set desc or asc for the orderBy?

I noticed in the documentation/example you have an orderBy field, but how do you go about setting the direction?

Solved.
You have to use a combination of EnumType when constructing your query.
import { jsonToGraphQLQuery, EnumType } from 'json-to-graphql-query';

const query = {
    query: {
        Posts: {
            __args: {
                where: { id: 2 }
                orderBy: { "post_date": new EnumType("asc") // can be "asc or desc"
            },
            id: true,
            title: true,
            post_date: true
        }
    }
};
const graphql_query = jsonToGraphQLQuery(query, { pretty: true });


Test inheritance with  MySQL 8.0.29

Test for latest MySQL connector: https://bugs.mysql.com/bug.php?id=107447

I've just realized that I need to test this on 5.6


Git .NET error

Git  .NET error
Respectful Reader
I am Padmashree, and the feature I want to request is that when I use a JetBrains IDE to push a git repository I do not get the .NET version error but while doing it by vs-code I face this issue. Kindly check this issue.
Thank you for reading till end
Padmashree :slightly_smiling_face:

/needsMoreInfo
Provide more info about versions, OS and especially what error is it.

@IllusionMH ok sir
OS
Windows 7 professional 64 bit
VS code
VS code user version 1.60.2
Git
Git version 2.32.0.windows.2

You've omitted most important part - what error do you see when you perform the action?

oh sorry

The error comes from GCM, which is bundled with and used by Git for Windows for authentication by default.
The problem is irrelevant to VS Code. It's likely that your .NET runtime version is too low, since GCM on Windows requires .NET Framework 4.7.2 or higher. https://github.com/microsoft/Git-Credential-Manager-Core/pull/283
Installing the latest .NET Framework and .NET Runtime should solve your problem.

Ok sir but when I push a repo by a JetBrains product like Pycharm I do not
see this error.
On Fri, 24 Sep, 2021, 22:32 Lemmingh, @.***> wrote:

The error comes from GCM
https://github.com/microsoft/Git-Credential-Manager-Core, which is
bundled with and used by Git for Windows for authentication by default.
The problem is irrelevant to VS Code. It's likely that your .NET runtime
version is too low, since GCM on Windows requires .NET Framework 4.7.2 or
higher. microsoft/Git-Credential-Manager-Core#283
https://github.com/microsoft/Git-Credential-Manager-Core/pull/283
Installing the latest .NET Framework
https://dotnet.microsoft.com/download/dotnet-framework and .NET Runtime
https://dotnet.microsoft.com/download should solve your problem.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/133675#issuecomment-926784545,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AS6BMKDMOPTXMMR7FNSTQKDUDSVJDANCNFSM5ETYEVKA
.

If I recall correctly, JetBrains products have their own credential manager which may override the default one (GCM Core).
VS Code's built-in Git integration simply calls the Git client. "Push" in VS Code should be equal to invoking git push in a terminal.

To inspect configured credential manager:
git config --show-origin --show-scope --get-all credential.helper

Since Git for Windows 2.29, the output should contain a line that looks like:
system  file:C:/Program Files/Git/etc/gitconfig manager-core

This should be the only one, if you didn't change the config.

oh that is why I see the error Thank you for your time and implement it if you have time and if you can Thank you.
*With Regards and Thanks
Padmashree


"truncated input" API change seems like a mess

The PNG decoder still loops around "short read" in one place.
DecodeImage0 doesn't reflect this change (no DecodeImage_UnexpectedEndOfFile as far as I can tell).
All decoders have their own version of this error, is that necessary?

The PNG decoder still loops around "short read" in one place.

Can you elaborate on (1) where is this one place and (2) why this is a problem?
If the answer to (1) is in decoder.do_decode_frame line 1248 then decoder.decode_frame should 'catch' it and turn it into "truncated input".

DecodeImage0 doesn't reflect this change (no DecodeImage_UnexpectedEndOfFile as far as I can tell).

Yeah, DecodeImage_UnexpectedEndOfFile ought to be unreachable now. We could probably remove it in v0.4.

All decoders have their own version of this error, is that necessary?

Go isn't Wuffs, but in the Go standard library, we returned a common error (io.ErrUnexpectedEOF) instead of each image decoder having their own version of this error. This was apparently confusing / surprising, so it's the other way round in Wuffs.

https://github.com/google/wuffs/blob/main/std/png/decode_png.wuffs#L1237

OK that (line 1237) rolls into line 1248 that I referenced above. I suppose we could make line 1248 return "#truncated input" directly, which would be a little cleaner. As I said, though, decoder.decode_frame should already 'catch' "$short read", so it shouldn't make a difference, in practice.

This particular argument doesn't convince me.

If you're not convinced then we'll agree to disagree. I'm just telling you why it's the way it is.

The thread is about people trying to receive as much of an image as they can, and dealing with the possibility of receiving an error (warning) at the same time.

There's two concerns in that thread. One is about trying to receive as much of an image as they can, as you said. Two is about what error you get when it's truncated (a generic io error versus an image-format-specific jpeg error) which is relevant to your "All decoders have their own version of this error, is that necessary?" in the OP. A quote from that thread: "How do I know that io.ErrUnexpectedEOF has anything to do with "wrong" JPEGs?"