lmdb: Txn.Reset clears the Txn finalizer when it should not

The docs for Txn.Reset do not mention that the method clears the finalizer on the Txn object. They do indicate however that everything the finalizer is meant to prevent is still possible. So it does seem like retaining the finalizer until Abort is called is the correct action.
I probably did this because of a benchmark, without realizing the impact of it. So the performance impact should be quantified.

It seems like this was done because the finalizer would cause segfault/panic when used with the sync.Pool type. This is a little counter-productive though because any Txn objects freed by a sync.Pool without a finalizer will leak resources and will not release their reader slot, causing the database to grow excessively.
The root cause of what I had determined to be the problem however, I now believe, is that the finalizer would fire after the Env had been closed.
This indicates that, with a finalizer enabled, naive use of a Txn with a sync.Pool type is not advised. And, at a minimum, when a sync.Pool type is going to be used it must be drained before the Env is closed.
for {
	txn, ok := txnPool.Get().(*lmdb.Txn)
	if ok {
		txn.Abort()
	} else {
		break
	}
}

err = env.Close()
//...

The most significant issue with the use of sync.Pool is that, because readers to not release their slots, the database will grow excessively on updates if a 'hot reader' ends up living for a very long time. It seems like it may be possible to avoid this possibility by tracking Txn.ID() for every update and calling Txn.Abort() on any transactions which differ in their ID by some amount (like, by two or more). AFAIK the Txn.ID() only changes when an update transaction is committed. Following is the documentation for mdb_txn_id.

Return the transaction's ID.
This returns the identifier associated with this transaction. For a read-only transaction, this corresponds to the snapshot being read; concurrent readers will frequently have the same transaction ID.

Probably the most minor yet still annoying issue arising from the combination of sync.Pool and the Txn finalizer is that the finalizer logs a warning when it has to clean up a Txn, which is expected behavior inside a sync.Pool.

If you want to be really technical about it modifying the finalizer behavior is not backwards compatible. But the package's stance is that finalizers on the types that it defines are entirely its domain and not part of the "public API". If a user were to clear or change the finalizer on a value allocated by the lmdb package the package does not guarantee them a way to change the finalizer back to an appropriate value if necessary.
So this is just a bug that could result in leaked resources and excessive volume utilization and it will be fixed in the v1.9.0 release (it is not a patch because this behavior is actually quite old).

FWIW, I think lmdb Txn should never be put into a sync.Pool.
From the doc of sync.Pool:
Pool's purpose is to cache allocated but unused items for later reuse, relieving pressure on the **garbage collector**. That is, it makes it easy to build efficient, thread-safe free lists. However, it is not suitable for all free lists.

I don't think it makes sense to tie reclaiming Txn to GC cycles. The application has to decide when / if this happens.

@lmb, Thank you for your comment and concern regarding this issue.
I have read this documentation. While it is true, garbage collection pressure is not the issue as the pooled objects are allocated in C, my benchmarking and experience trying to increase performance of my raft-mdb fork has shown me that pooling Txn objects can lead to drastic performance benefits. My current understanding of the performance gain from pooling transactions is that the benefit is not in reduced memory allocation but reduced contention on the readlock table.
I have recently updated the lmdb benchmarks to include a reset/renew benchmark that accurately demonstrates what I have stated above. You may also look at my fork of raft-mdb, which has such benchmarks as well.
Currently, AFAICT, the largest potential downside of transaction pooling (provided that the finalizer is working) is that you may have idle readers in the pool when an update is committed which would lead to the collection of dirty pages until the transaction is either collected from the pool and finalized or removed from the pool and renewed. The dirty pages cause the database to grow but growth is not indefinite.
Further, my current implementation of lmdbpool.TxnPool allows the user to control how stale and outstanding readers are handled when updates are committed. This gives applications some level of tuning in regards to bounding the accumulation of dirty pages.
I don't intend on forcing transaction pooling onto users. Indeed If it gets integrated into the core lmdb package it probably will not even be the default mode. Though I do think integrating into the core package would produce the cleanest result, at the moment.
I do agree that, in general, complete deferral to GC for abortion of all transactions is a very bad idea. That is why I have the finalizer emit a serious warning when non-pooled transactions are aborted.
My belief is that if you carefully read the C documentation and the lmdbpool code you can become convinced that the implementation is not unsound (at least for some configurations and application use cases). If it does indeed turn out that a sync.Pool is not adequate then another custom pooling implementation could be experimented with. lmdbpool currently uses sync.Pool, yes. But the pool is an internal structure and could be swapped out for a different kind of pooling structure.
One of my driving concerns is that other users will try to implement pooling themselves and make really poor implementation choices. So I think that there should be an official/reference pooling implementation which does things as correctly as possible. Please let me know your thoughts and we can continue to work through this. But you may consider making a new issue to bring up new topics, given that I closed this issue and it is even somewhat off-topic here.
This issue was about the lmdb package clearing the finalizer when it absolutely should not (regardless of the use of sync.Pool).

I think we're misunderstanding each other.

Yes, free lists can be beneficial for lmdb Txns. I'm not saying never put Txn into a freelist. I'm saying never put a Txn into a sync.Pool. It makes no guarantees whatsoever about deallocation, and no guarantees that a finalizer is called when a Pool is GCed. This means you will leak LMDB reader slots over time, rendering the DB inaccessible.

You probably know this, but your benchmark shows such marked difference between Renew and Begin because you call SetMaxDBs with a very high number. I doubt that a lot of applications will use that many DBIs. E.g. I set a max of 5 DBIs, and BeginTxn takes 2000ns, while Renew takes 700ns.

and no guarantees that a finalizer is called when a Pool is GCed.

I'm not sure what use case you are arguing for here. Why would you create many pools and allow them to be GCed over the course of your application life time? It seems to me that the common scenario is that a pool exists for the entire lifetime of an application.
If a pool is only GCed when the program terminates, then a call to Env.ReaderCheck when the program starts again would clear any reader slots that failed to be cleaned up from a pool on the previous execution. A real program should be calling Env.ReaderCheck anyway, so this is not really a big deal.
I do have a method, TxnPool.Close which does its best to flush the pool of any remaining transactions with the expectation that this method is called before Env.Close is called. Now I understand the documentation for Pool.Get do not guarantee that a pool can be flushed. My argument is that in practice is does actually work pretty well and Env.ReaderCheck is there to cover you anyway. Maybe it won't work for every application. Unfortunately, those applications can't use the TxnPool.
Now, it would be very bad if an idle txn could sit indefinitely inside a sync.Pool. I understand this very well. Write-heavy applications which only infrequently access the pool are at the most risk. But read heavy applications should actually cycle the pool effectively in practice.
In the end, I may implement a more strict pool that behaves more like a bounded queue/stack. sync.Pool was the easy first step. Ideally, I wouldn't mention sync.Pool at all in the implementation, but for the fact that is does have peculiarities.

you call SetMaxDBs with a very high number

I actually didn't remember setting MaxDBs to 64k. That was a strange decision I made years ago, and I should address that. But the performance benefits are not solely seen in these benchmarks. As I said, raft-mdb benchmarks also show the relevance of the change and those benchmarks has always called Env.SetMaxDBs with the value 2. Basically the whole txnpool implementation came out of trying to beat boltdb's read benchmarks for raft.

Behind the scenes, a sync.Pool keeps a weak list of "things" per runtime
thread, using a bit of black magic. Any time the GC is run (which you don't
have control over), that weak list can be/is emptied. There are no
destructors called, and finalizers aren't guaranteed to be called anyways.
Have a look at the implementation, that might make things clearer.
That's why the doc stresses that sync.Pool is about reducing pressure on
the GC. It's not meant to be a generic free list.

My understanding is that finalizers aren't guaranteed to be called in general because of program termination. When the program terminates no attempt is made to GC, and thus no attempt is made to finalize any outstanding objects. As I stated, readers left open when a program terminates may not be ideal but they are not too harmful overall because Env.ReaderCheck handles them when the application starts.
The worst way to leak a transaction would be to do it in the middle of a long running program execution, as the leak cannot be detected by Env.ReaderCheck until after the program has exited. If this is truly possible then indeed use of the sync.Pool would not be a feasible.
However, my reading of the mailing lists has indicated that finalizers are supposed to be called for items in the pool. And in practice I have seen pooled items have their finalizer called. I am looking at the pool.go in the sync package now, and I don't see what about the implementation is making the references to pooled objects 'weak'. It seems like there is simply a runtime hook that releases pooled objects at the beginning of a GC (by assigning all internal references to nil). So it's not clear to me that this result in finalizers not being called.
https://golang.org/src/sync/pool.go#L211
If I do not see something in the source which you think is obvious, please show me.

My understanding is that finalizers aren't guaranteed to be called in general because of program termination.

You're right, I had misunderstood the notes on SetFinalizer, sorry!

I don't see what about the implementation is making the references to pooled objects 'weak'

The poolCleanup function does. It's a hack basically.
With that said, I still wouldn't use sync.Pool. Why do you want to tie the lifetime of the reserved transactions to the GC cycle?

Why do you want to tie the lifetime of the reserved transactions to the GC cycle?

This is valid question. I have not implemented a custom free list because can be tricky to determine how many items to hold onto before additional items would be thrown away (aborted in the case of Txns).
For an lmdb.Env the maximum size of the pool is the value of MaxReaders (126 by default), which must be configured before Env.Open is called. So does it make sense that the free list be allowed to grow to MaxReaders size? Possibly. But maybe not. Can I issue an Env.Copy with MaxReaders in the free list? I doubt it.
I can implement a bounded free list so that the application developer is required to specify the maximum number of items it may hold. But I believe Go's general design philosophy is that application developers cannot determine a proper bound much better than I can as a package author, and they are prone to chose a bad value.
Again, I'm not against the idea of implementing a custom own free list. It's merely non-trivial.
I made #116 regarding this issue, please respond to this comment in that thread. Thanks.


Improve readme

remove trailing spaces
add -p arg for mkdir

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
79

Relevant Lines:
92

💛  - Coveralls


Armadillo/lapack multiple issues using CMake

Apologies for posting this mess as a single bug but I ran into multiple issues installing armadillo today, which now depends on BLAS and LAPACK. I am generally pleased about that but it seems not all of the CMake config has been tidied to reflect it. I innocently ran this on a freshly cloned vcpkg today (at commit 5b6b66512):
vcpkg install --triplet x64-windows-static armadillo

After finishing, it helpfully printed the following:
The package openblas:x64-windows-static provides CMake targets:

    find_package(OpenBLAS CONFIG REQUIRED)
    target_link_libraries(main PRIVATE OpenBLAS::OpenBLAS)

The package clapack:x64-windows-static provides CMake targets:

    find_package(clapack CONFIG REQUIRED)
    target_link_libraries(main PRIVATE f2c lapack)

    find_package(lapack CONFIG REQUIRED)
    target_link_libraries(main PRIVATE lapack clapack::clapack)

Hmm, two different options for linking against LAPACK. I tried the first one to start with (i.e. find_package(clapack) and target_link_libraries(... f2c lapack)`). That gave this error when I ran CMake:
CMake Error at D:/src/_misc/vcpkg_master2/installed/x64-windows-static/share/clapack/clapack-config.cmake:1 (include):
  include could not find load file:

    D:/src/_misc/vcpkg_master2/buildtrees/clapack/x64-windows-static-rel/clapack-targets.cmake
Call Stack (most recent call first):
  D:/src/_misc/vcpkg_master2/scripts/buildsystems/vcpkg.cmake:266 (_find_package)
  CMakeLists.txt:3 (find_package)

-- Configuring incomplete, errors occurred!
See also "D:/src/_misc/zarma/build2/CMakeFiles/CMakeOutput.log".

I changed clpack-config.cmake to point at correct location for clapack-targets (I just set it to an absolute path), which changed the error to this warning:
CMake Warning (dev) at D:/src/_misc/vcpkg_master2/scripts/buildsystems/vcpkg.cmake:169 (_add_executable):
  Policy CMP0003 should be set before this line.  Add code such as

    if(COMMAND cmake_policy)
      cmake_policy(SET CMP0003 NEW)
    endif(COMMAND cmake_policy)

  as early as possible but after the most recent call to
  cmake_minimum_required or cmake_policy(VERSION).  This warning appears
  because target "zarma" links to some libraries for which the linker must
  search:

    clapack

  and other libraries with known full path:

    D:/src/_misc/vcpkg_master2/installed/x64-windows-static/debug/lib/openblas.lib
    D:/src/_misc/vcpkg_master2/buildtrees/clapack/x64-windows-static-rel/F2CLIBS/libf2c/libf2c.lib

  CMake is adding directories in the second list to the linker search path in
  case they are needed to find libraries from the first list (for backwards
  compatibility with CMake 2.4).  Set policy CMP0003 to OLD or NEW to enable
  or disable this behavior explicitly.  Run "cmake --help-policy CMP0003" for
  more information.
Call Stack (most recent call first):
  CMakeLists.txt:5 (add_executable)
This warning is for project developers.  Use -Wno-dev to suppress it.

This was suspicious but I tried building anyway. That gave this error:
LINK : fatal error LNK1104: cannot open file 'clapack.lib' [D:\src\_misc\zarma\build2\zarma.vcxproj]

As a note to help debug this, I notice the targets file includes these lines (but no corresponding _DEBUG variables):
set_property(TARGET f2c APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(f2c PROPERTIES
  IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "C"
  IMPORTED_LOCATION_RELEASE "D:/src/_misc/vcpkg_master/buildtrees/clapack/x64-windows-static-rel/F2CLIBS/libf2c/libf2c.lib"
  )

# Import target "lapack" for configuration "Release"
set_property(TARGET lapack APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(lapack PROPERTIES
  IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "C"
  IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "${_IMPORT_PREFIX}/lib/openblas.lib;f2c"
  IMPORTED_LOCATION_RELEASE "D:/src/_misc/vcpkg_master/buildtrees/clapack/x64-windows-static-rel/SRC/lapack.lib"
  )

OK, so I tried the other suggestion, which was find_package(LAPACK CONFIG REQUIRED) and target_link_libraries(... lapack clapack::clapack). This gave a lot of errors like this:
  Target "zarma" links to target "clapack::clapack" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?

Unsurprisingly, I got another linker error about not finding the library. After searching the web I found the correct target_link_libraries(...) line is actually against ${LAPACK_LIBRARIES}. (Also FindLAPACK is a module, not a config, so I'm not sure how it found it but it did.) But at this change was finally enough to fix the configuration warnings and find the lapack library. But then I got link errors for missing symbols:
zarmatest.obj : error LNK2019: unresolved external symbol wrapper_sgesv_ referenced in function "void __cdecl arma::lapack::gesv<double>(int *,int *,
double *,int *,int *,double *,int *,int *)" (??$gesv@N@lapack@arma@@YAXPEAH0PEAN00100@Z) [D:\src\_misc\zarma\build2\zarma.vcxproj]
zarmatest.obj : error LNK2019: unresolved external symbol wrapper_dgesv_ referenced in function "void __cdecl arma::lapack::gesv<double>(int *,int *,
double *,int *,int *,double *,int *,int *)" (??$gesv@N@lapack@arma@@YAXPEAH0PEAN00100@Z) [D:\src\_misc\zarma\build2\zarma.vcxproj]
zarmatest.obj : error LNK2019: unresolved external symbol wrapper_cgesv_ referenced in function "void __cdecl arma::lapack::gesv<double>(int *,int *,
double *,int *,int *,double *,int *,int *)" (??$gesv@N@lapack@arma@@YAXPEAH0PEAN00100@Z) [D:\src\_misc\zarma\build2\zarma.vcxproj]
< ... and so on ...>

That's odd, armadillo shouldn't be using the wrapper when installed with vcpkg. I found this in ...\installed\x64-windows-static\include\armadillo_bits\config.hpp:
#define ARMA_USE_WRAPPER
//// Comment out the above line if you're getting linking errors when compiling your programs,
//// or if you prefer to directly link with LAPACK, BLAS + etc instead of the Armadillo runtime library.

After this, finally it built and ran. I was left only with a linker warning:
"D:\src\_misc\zarma\build2\zarma.vcxproj" (default target) (3) ->
(Link target) ->
  LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library [D:\src\_misc\zarma\build2\zarma.vcxproj]

    1 Warning(s)

In summary:

the clapack port suggests two different find_package options, which is confusing
the clapack port has a bug that prevents find_package(clapack) working
the clapack suggests the wrong target_link_libraries() link for use with find_package(lapack)
the armadillo port tries to link against the wrapper library, even though it doesn't exist

BLAS/lapack/armadillo/atlas/whatever is still a little bit of a mess. It’s also my fault, sorry, never fixed it properly. @neumann-a tried another approach, better continuing investing on it.
About lapack, i’d suggest you to use find_package(lapack) and then target_link_libraries(targetname PRIVATE ${LAPACK_LIBRARIES}), without listening to the automatic message by vcpkg. That way it works (or at least it works for me.
About the module/config, it works because in the wrapper I redirect everything to the module I wrote, whatever you are asking for.
clapack self-produced configs are broken, and they are known as broken also upstream. Luckily no one use them

No need to apologise! I'm very grateful for the time you've spent on this.
It think a totally reasonable solution would be to get vcpkg to output your CMake suggestion instead of the two broken alternatives. This is actually pretty easy. We just need to create a file that says:
find_package(lapack CONFIG REQUIRED)
target_link_libraries(main PRIVATE ${LAPACK_LIBRARIES}))

Then call that file usage, and copy it to share/clapack when the port is installed. I know this is cheeky, but would you be able to do that? Creating even trivial pull requests is a bit tricky for me (legally speaking).
Maybe I should make a separate issue for the final point I raised, about Armadillo and the LAPACK wrapper?

My apologies were also in fact related to hide the fact that I removed the usage file 🤣
I will do that pr

Now that I understand what CMake commands to use to link against LAPACK, I have had a chance to look into the problems with Armadillo. My original overall goal was just to install and use Armadillo on Windows (x64), which used to work in vcpkg (before it supported BLAS and LAPACK). I have played around quite a bit and found the following.

Current vcpkg, wrapper disabled: Works after disabling wrapper in config.hpp

As I mentioned in my original comment, I can get Armadillo to work by using as a header-only library (with no target_link_libraries()) and turning off the wrapper by commenting out that one line in config.hpp.

Current vcpkg, link to wrapper (via module): Works in debug only after adding link command

If I add find_package(Armadillo) and target_link_libraries(...${ARMADILLO_LIBRARIES}) to my CMake project (along with the BLAS and LAPACK commands) then the project compiles and links correctly, even with the wrapper still enabled. However, this only works in debug mode, because in release mode it still links against the debug armadillo.lib, which causes a link error due to mismatched iterator debug level. I believe find_package is picking up the FindArmadillo module in this case, because there is no config in share/armadillo.

Older vcpkg, link to wrapper (via config): Works after tweaking path in config

I rolled back to an older vcpkg repo (last commit was 12d2020 on 3 June 2019) and used  find_package(Armadillo) and target_link_libraries(...${ARMADILLO_LIBRARIES}). This time linking works in debug and release mode. I did first have to make a change: the file ArmadilloConfig.cmake contained a path ../../share/Armadillo/CMake/ArmadilloLibraryDepends.cmake, which has a spurious "CMake" in it. Unfortunately, it seems all the config files were removed by 6a6d350 for #7022.

It seems to me that a reasonable fix would be:

Undo the change made in #7022, which removed all the Armadillo config files.
Patch the config file to remove the spurious "CMake" path fragment.
Add a usage to Armadillo that says to use find_package(Armadillo) and target_link_libraries(...${ARMADILLO_LIBRARIES})

I think these are independent of the changes in #6786

thanks for your very important debugging. We can try to ping @wangli28 to see if it's possible to merge all these fixes in the #7041 PR

Thanks for posting this issue. This issue has been fixed. You can update vcpkg and rebuild. So I am closing this issue for now.


Allow setting autoreconnect before resuming processing of ops because it is just a policy.

Fixes: https://github.com/microsoft/FluidFramework/issues/3666
Currently setAutoReconnect() is in the form of policy not action, so allow setting it at anytime.

Looks good!


Segmentation fault (core dumped)

When I'm running the testing command, the error always pops out:
Segmentation fault (core dumped)

I debug step by step and find that the program exit at this line of code, but I don't know why, I followed the instructions without any change.
model: pl.LightningModule = instantiate(cfg.system.system_class, cfg)

Can anybody help me? Thanks very much!

Oh, I figured it out. It's because the version of torch and torch-scatter doesn't match.


Strange behaviour from agents in coin game environment

Hi there,
I am trying to get my head around the library but am having an issue in the coin game environment.
This is likely down to user error but I am not 100% sure what the issue may be.
I am using a slightly modified version of the random agent in the README:
import jax
from jaxmarl import make
from PIL import Image
import numpy as np

key = jax.random.PRNGKey(0)
key, key_reset, key_act, key_step = jax.random.split(key, 4)

# Initialise environment.
env = make('coin_game')

# Reset the environment.
obs, state = env.reset(key_reset)

images = []
dones = 0
while dones < 10:
    images.append(env.render(state))
    # Sample random actions.
    actions = {agent: jax.numpy.asarray(4) for i, agent in enumerate(env.agents)}

    # Perform the step transition.
    obs, state, reward, done, infos = env.step(jax.numpy.asarray([4, 2], dtype='uint32'), state, actions)
    if done:
        dones += 1

gif = [i.convert("P", palette=Image.ADAPTIVE) for i in images]
gif[0].save('test2.gif', save_all=True, optimize=False, append_images=gif[1:], loop=0)

My problem is that I am fairly sure that both agents should always just take the 'stay' action due to
actions = {agent: jax.numpy.asarray(4) for i, agent in enumerate(env.agents)}

but, when viewing the gif generated by the above code this does not seem to be the case:

It also seems, from the gif, that agents aren't picking up coins when stepping on them?
Any help/instruction on where I may have misunderstood something would be greatly appreciated!
Thanks,
Stefan

Hey thanks for raising this! We should hopefully have time to take a look later this week, keep updating us with what you find :slightly_smiling_face:

It might be because you're using the same rng state without changing it?

It might be because you're using the same rng state without changing it?

This is likely why the the coins are remaining in the same position when collected. However I'm not sure this explains why agent behaviour is random despite having hardcoded taking the 'stay' action at every timestep?

Sorry for taking so long to get back to you on this!
The API for Coin Game actions is as follows:
actions = jax.numpy.asarray([4, 4])
when doing this instead, it fixes the issue:
obs, state = env.reset(key_reset)

images = []
dones = 0
while dones < 10:
    images.append(env.render(state))
    # Sample random actions.
    # actions = {agent: jax.numpy.asarray(4) for i, agent in enumerate(env.agents)}
    actions = jax.numpy.asarray([4, 4])

    # Perform the step transition.
    obs, state, reward, done, infos = env.step(jax.numpy.asarray([4, 2], dtype='uint32'), state, actions)
    if done:
        dones += 1

gif = [i.convert("P", palette=Image.ADAPTIVE) for i in images]
gif[0].save('test2.gif', save_all=True, optimize=False, append_images=gif[1:], loop=0)


PowerRename in context menu

ℹ Computer information

PowerToys version: 0.27.0
PowerToy utility: PowerRename
Language: Dutch

📝 Provide where the issue is: in the right click context menu of files  / 📷

❌ Actual phrase(s)
Voedingsnaam wijzigen
✔ Expected phrase(s)
Bestandsnaam wijzigen ( or just leave it Power Rename)
ℹ Why is the current translation wrong
Voedingsnaam does not mean anything in dutch with regard to computers, translation of "voedingsnaam" is "foodname"

This is mentioned in#8009 already.
As one Dutch guy to another: Voor een computer is stroom voeding. Denk aan het blok in een computer kast.

OK, didn't know this was reported already. Will close this one

Already adressed in #8009

Tnx Jay, was already trying to figure out how PowerRename could be
translated as voedingsnaam. You made it clear to me :-)
Op do 3 dec. 2020 om 21:31 schreef Jay<EMAIL_ADDRESS>
This is mentioned in#8009 already.
As one Dutch guy to another: Voor een computer is stroom voeding. Denk aan
het blok in een computer kast.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PowerToys/issues/8380#issuecomment-738290013,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AI2JJL4E7IZL6P5TBO5VOOTSS7YTJANCNFSM4UMPXTLQ
.

No problem, happy to help. The first run of translation was done automatically.

Already adressed in #8009

It's not. PowerRename context menu is still wrong. Version 0.41.4

@opus-x Then I guess that it is an exception with you. Have you tried un-installing and re-installing PowerToys too?


Failed to compile with zksolc: Cannot get source files

Component
zkForge
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0 (3df3e0c 2024-03-04T00:19:46.775990000Z)
What command(s) is the bug in?
zkforge test
Operating System
macOS (Apple Silicon)
Describe the bug
Steps to reproduce:

zkforge init hello_zksync
cd hello_zksync
zkforge test

Getting error: Failed to compile with zksolc: Cannot get source files
Full Debug Log:
> RUST_LOG=debug zkforge test
2024-03-04T17:04:12.481504Z DEBUG reqwest::connect: starting new connection: https://github.com/
2024-03-04T17:04:12.481595Z DEBUG hyper::client::connect::dns: resolving host="github.com"
2024-03-04T17:04:12.482980Z DEBUG hyper::client::connect::http: connecting to <IP_ADDRESS>:443
2024-03-04T17:04:12.505512Z DEBUG hyper::client::connect::http: connected to <IP_ADDRESS>:443
2024-03-04T17:04:12.611753Z DEBUG hyper::proto::h1::io: flushed 139 bytes
2024-03-04T17:04:12.633881Z DEBUG hyper::proto::h1::io: parsed 15 headers
2024-03-04T17:04:12.633899Z DEBUG hyper::proto::h1::conn: incoming body is empty
2024-03-04T17:04:12.633932Z DEBUG hyper::client::pool: pooling idle connection for ("https", github.com)
2024-03-04T17:04:12.633964Z DEBUG reqwest::async_impl::client: redirecting 'https://github.com/alloy-rs/solc-builds/raw/55ef6c89b8a09c16feee4a424f8a53f822831a61/macosx/aarch64/list.json' to 'https://raw.githubusercontent.com/alloy-rs/solc-builds/55ef6c89b8a09c16feee4a424f8a53f822831a61/macosx/aarch64/list.json'
2024-03-04T17:04:12.633986Z DEBUG reqwest::connect: starting new connection: https://raw.githubusercontent.com/
2024-03-04T17:04:12.634025Z DEBUG hyper::client::connect::dns: resolving host="raw.githubusercontent.com"
2024-03-04T17:04:12.635184Z DEBUG hyper::client::connect::http: connecting to <IP_ADDRESS>:443
2024-03-04T17:04:12.652797Z DEBUG hyper::client::connect::http: connected to <IP_ADDRESS>:443
2024-03-04T17:04:12.709368Z DEBUG hyper::proto::h1::io: flushed 270 bytes
2024-03-04T17:04:12.736637Z DEBUG hyper::proto::h1::io: parsed 24 headers
2024-03-04T17:04:12.736650Z DEBUG hyper::proto::h1::conn: incoming body is content-length (2861 bytes)
2024-03-04T17:04:12.736774Z DEBUG hyper::proto::h1::conn: incoming body completed
2024-03-04T17:04:12.736938Z DEBUG reqwest::connect: starting new connection: https://binaries.soliditylang.org/
2024-03-04T17:04:12.736985Z DEBUG hyper::client::connect::dns: resolving host="binaries.soliditylang.org"
2024-03-04T17:04:12.738324Z DEBUG hyper::client::connect::http: connecting to <IP_ADDRESS>:443
2024-03-04T17:04:12.755603Z DEBUG hyper::client::connect::http: connected to <IP_ADDRESS>:443
2024-03-04T17:04:12.814586Z DEBUG hyper::proto::h1::io: flushed 86 bytes
2024-03-04T17:04:12.835362Z DEBUG hyper::proto::h1::io: parsed 18 headers
2024-03-04T17:04:12.835381Z DEBUG hyper::proto::h1::conn: incoming body is content-length (53428 bytes)
2024-03-04T17:04:12.851593Z DEBUG hyper::proto::h1::conn: incoming body completed
Error:
Failed to compile with zksolc: Cannot get source files

Full Trace Logs: https://pastebin.com/Fp1rFst3

The same problem as in #272


[RFC] Consider setting default IMU_GYRO_RATEMAX to 400 Hz

The new Invensense IMU drivers have the ability to actually run the driver at a slower (or faster) rate without sacrificing any raw data. The rate at which the driver runs and empties the FIFO is the maximum inner loop (rate controller) update rate (current default is 1000 Hz). Regardless of the configured rate the full FIFO with 8 kHz raw data is transferred (with DMA).
With focus shifting to newer boards based on stm32f7/h7/imxrt/etc (pixhawk 4 launched 2 years ago) and quite a lot of development activity things have been getting tighter on older boards like fmu-v2/v3. For example, current master on a Pixhawk 2 Cube configured as generic multicopter only has around 15% idle cpu (depending on exact configuration). Configured as a VTOL (quadplane, tiltrotor, etc) it can easily drop below 10%.
If we lower the default rate (IMU_GYRO_RATEMAX=400) these numbers become a lot more comfortable (> 30% idle cpu). This is a (probably?) a more appropriate rate for most vehicles other than small multicopters and also synchronizes with typical 400 Hz PWM ESCs.
With a safe default in place we could then explore opting in to much higher rates for specific configurations. For multicopters many of these boards (including f4's like the pixracer) can handle 2 kHz. Newer boards like the Holybro Durandal (and F7s if you're careful) can even comfortably handle 4 kHz.
For historical context PX4's rate was fixed at 250 Hz up until v1.10 (released Dec 2019), so we've really come a long way.

Pixhawk 2 Cube (IMU_GYRO_RATEMAX=400 SYS_AUTOSTART=4001)
 PID COMMAND                   CPU(ms) CPU(%)  USED/STACK PRIO(BASE) STATE FD
   0 Idle Task                  191411 31.104   244/  512   0 (  0)  READY  3
   1 hpwork                          0  0.000   344/ 1260 249 (249)  w:sig  3
   2 lpwork                          0  0.000   344/ 1612  50 ( 50)  w:sig  3
   3 init                         1462  0.000  2192/ 2668 100 (100)  w:sem  3
   4 wq:manager                      1  0.000   376/ 1252 255 (255)  w:sem  3
 633 top                           254  3.155  1248/ 2028 248 (248)  RUN    3
  18 wq:lp_default                 342  0.075  1000/ 1700 205 (205)  w:sem  3
  28 wq:hp_default                7194  1.126  1144/ 1900 241 (241)  w:sem  3
 159 wq:SPI1                     39740  6.461  1928/ 2364 253 (253)  w:sem  3
 169 wq:SPI4                    111234 17.580  1928/ 2364 250 (250)  w:sem  3
 208 wq:att_pos_ctrl            143365 22.464  5016/ 7196 242 (242)  w:sem  3
 209 wq:rate_ctrl                20784  3.305  1080/ 1596 255 (255)  w:sem  3
 215 commander                    7972  1.202  1296/ 3212 140 (140)  w:sig  6
 216 commander_low_prio             14  0.000   856/ 2996  50 ( 50)  w:sem  6
 229 mavlink_if0                 29300  4.733  1824/ 2572 100 (100)  READY  4
 283 gps                           500  0.150  1016/ 1676 208 (208)  w:sem  4
 331 mavlink_if1                  9975  1.577  1888/ 2484 100 (100)  w:sig  4
 332 mavlink_rcv_if1              2506  0.375  2384/ 3908 175 (175)  w:sem  4
 346 mavlink_rcv_if0              2306  0.375  2192/ 3908 175 (175)  w:sem  4
 360 px4io                       16921  2.629  1048/ 1484 240 (240)  READY  4
 582 navigator                     695  0.150  1072/ 1764 105 (105)  w:sem  5
 622 logger                       2852  0.450  1688/ 3644 233 (233)  READY  3
 623 log_writer_file                 0  0.000   368/ 1164  60 ( 60)  w:sem  3

Processes: 23 total, 5 running, 18 sleeping, max FDs: 15
CPU usage: 65.82% tasks, 3.08% sched, 31.10% idle
DMA Memory: 5120 total, 0 used 0 peak
Uptime: 629.682s total, 191.412s idle

update: 1s, num topics: 78
TOPIC NAME                     INST #SUB #MSG #LOST #QSIZE
task_stack_info                   0    0    1     0 2
adc_report                        0    1  100     0 1
system_power                      0    2  100    11 1
sensor_baro                       0    2   74     0 1
sensor_mag                        0    3   94    95 1
sensor_baro                       1    2   74     3 1
sensor_accel                      0    2  773     0 4
sensor_accel_status               0    3   10     0 1
sensor_gyro                       0    2  740     0 4
sensor_gyro_status                0    3   10     0 1
sensor_accel_integrated           0    3  236   242 1
sensor_gyro_integrated            0    4  240   249 1
vehicle_angular_acceleration      0    1  400     0 1
vehicle_angular_velocity          0    6  400  1527 1
vehicle_acceleration              0    1  400   349 1
vehicle_imu                       0    0  231     0 1
battery_status                    0    8   99   375 1
sensor_combined                   0    3  400   401 1
sensor_preflight                  0    1  400     0 1
vehicle_control_mode              0    8    1     0 1
vehicle_status                    0   16    1     0 1
actuator_armed                    0    4    1     0 1
commander_state                   0    0    1     0 1
vehicle_magnetometer              0    3   95    93 1
vehicle_status_flags              0    1    1     0 1
vehicle_air_data                  0    8   74   384 1
sensor_gyro                       1    2  400     0 4
sensor_gyro_integrated            1    4  400   403 1
sensor_gyro_fifo                  0    0  400     0 1
sensor_gyro_status                1    3   10     0 1
sensor_accel                      1    2  400     0 4
sensor_accel_integrated           1    3  400   403 1
sensor_accel_fifo                 0    0  400     0 1
sensor_accel_status               1    3   10     0 1
sensor_gyro                       2    1  399     0 4
sensor_gyro_integrated            2    4  399   403 1
sensor_gyro_fifo                  1    0  399     0 1
sensor_gyro_status                2    1   10     0 1
sensor_accel                      2    1  399     0 4
sensor_accel_integrated           2    3  399   403 1
sensor_accel_fifo                 1    0  399     0 1
sensor_accel_status               2    3   10     0 1
actuator_controls_0               0    7  400  1835 1
safety                            0    2   44     0 1
servorail_status                  0    0   44     0 1
actuator_outputs                  0    3   44    54 1
multirotor_motor_limits           0    2   43     0 1
vehicle_imu                       1    0  400     0 1
vehicle_imu                       2    0  399     0 1
ekf2_timestamps                   0    1  400     0 1
landing_gear                      0    0   46     0 1
rate_ctrl_status                  0    1  400     0 1
vehicle_attitude                  0    7  400  1849 1
vehicle_local_position            0   11  125  1143 1
vehicle_land_detected             0    9    1     0 1
telemetry_status                  0    2    1     0 3
estimator_sensor_bias             0    4  125   123 1
estimator_status                  0    4  125   194 1
estimator_innovations             0    1  125     0 1
estimator_innovation_variances    0    1  125     0 1
estimator_innovation_test_ratios  0    1  125     0 1
vehicle_odometry                  0    1  125   156 1
vehicle_attitude_setpoint         0    4  400   376 1
vehicle_rates_setpoint            0    4  400   376 1

I would change that with flight testing and tuning on different vehicles. I mean if certain boards are just not capable to deal with the load then we're almost forced to lower the rate for them but I saw multiple multicopters benefiting from the improved 1kHz rate loop updates and we should make sure the average user doesn't miss out on this because it's not the default...

I would change that with flight testing and tuning on different vehicles. I mean if certain boards are just not capable to deal with the load then we're almost forced to lower the rate for them but I saw multiple multicopters benefiting from the improved 1kHz rate loop updates and we should make sure the average user doesn't miss out on this because it's not the default...

That's true, so we might want to set the value in the config file for some frames. Racers should run at -at least- 1kHz rate loop, while VTOL planes can run at 400Hz or slower.

Yes with the current PWM400 default, we can also keep the rate loop at that default. I would increase it for boards that can support it easily (durandal, kakute, omnibus, pixracer).
I would also expose this in the QGC setup pages more clearly (in particular the ESC protocol + rate controller update frequency). @DonLakeFlyer is that something you can take care of?

To be clear, I'm proposing changing the system default as a stop gap for the next release because I think it's too easy to bypass the current per board/type/airframe defaults on upgrade or manual configuration. I think we're safer having a conservative default with the ability for users to opt-in to higher performance.
Once https://github.com/PX4/Firmware/pull/14363 lands we can effectively change these defaults and I would want to revert this. In general I think it's slightly preferable to not have a default, which then lets the drivers decide. Beyond our current common Invensense selections there are many sensors with output data rates that don't align with 400 Hz.

I would also expose this in the QGC setup pages more clearly (in particular the ESC protocol + rate controller update frequency). @DonLakeFlyer is that something you can take care of?

From reading the thread this all seems like magic values which the majority of users will not understand. Hence exposing them in something other than the parameter editor doesn't match the model of common usage for the setup pages. Am I wrong? Will these get changed by folks frequently enough and they will actually understand what they are for?

I would also expose this in the QGC setup pages more clearly (in particular the ESC protocol + rate controller update frequency). @DonLakeFlyer is that something you can take care of?

From reading the thread this all seems like magic values which the majority of users will not understand. Hence exposing them in something other than the parameter editor doesn't match the model of common usage for the setup pages. Am I wrong? Will these get changed by folks frequently enough and they will actually understand what they are for?

@DonLakeFlyer it's a one time setup parameter that should be airframe specific, but pragmatically might need to be lowered given actual hardware.

New approach as discussed on the dev cal today.
I'll keep the actual parameter default value the same (0 to let the sensor driver select), then for fmu-v2/v3 (and similar) have the board specific init script change IMU_GYRO_RATEMAX to 400 only if it's still set to 0.

From reading the thread this all seems like magic values which the majority of users will not understand. Hence exposing them in something other than the parameter editor doesn't match the model of common usage for the setup pages. Am I wrong? Will these get changed by folks frequently enough and they will actually understand what they are for?

Yes I prefer setting good defaults as well, and we now have a solution for the update rate.
I'd still like to expose the ESC protocol (maybe with a link to the docs?), as it makes quite a big difference, and people possibly are not even aware of it.

I've updated the branch with the solution discussed on the dev call. Now on px4_fmu-v2/v3 and mro_x21 IMU_GYRO_RATEMAX is always set to 400 Hz in rc.board_defaults if it was the old default value of 0. This can be added for other boards if necessary.

This should do for now.
http://ci.px4.io:8080/blue/organizations/jenkins/PX4_misc%2FFirmware-hardware/detail/pr-default_imu_rate/2/pipeline/527
[2020-04-16T00:14:24.574Z] Board defaults: /etc/init.d/rc.board_defaults
[2020-04-16T00:14:24.574Z]   IMU_GYRO_RATEMAX: curr: 0 -> new: 400


The width of WebviewTextEditorInset is not correct

VSCode Version: 1.36.0-insider (1.36.0-insider) c089daa858f34631f5f827ff8a0313bf1e2ded6d 2019-06-07T06:03:17.956Z
OS Version: macOS High Sierra 10.13.6（17G7024）

Steps to Reproduce:

Disable the minimap.
Execute the following sample code of VS Code extension.
The width of WebviewTextEditorInset is not correct. It is overlayed by the scroll bar.

Does this issue occur when all extensions are disabled?: Yes
This may be related to #73117.
import * as vscode from 'vscode';

export function activate(context: vscode.ExtensionContext) {
    const disposable = vscode.commands.registerCommand('extension.helloWorld', async (args, brgs, crgs) => {
        if (!vscode.window.activeTextEditor) {
            return;
        }

        const inset = vscode.window.createWebviewTextEditorInset(
            vscode.window.activeTextEditor,
            vscode.window.activeTextEditor.selection.with({ end: vscode.window.activeTextEditor.selection.end.translate(30) }),
            // { enableScripts: true, enableCommandUris: true }
        );
        inset.onDidDispose(() => {
            console.log('WEBVIEW disposed...');
        });
        inset.webview.html = `<head><meta></head><body style="background-color: #000;"><body>`;
    });
	context.subscriptions.push(disposable);
}

// this method is called when your extension is deactivated
export function deactivate() {}

That's the design of the scrollbar, it also overlays the text itself.


[FEATURE] Indicate the active generator/tool

Description
When user clicks on a tool, it should show what too, the tasks:

[ ] Show the tool at the top by adding a text of the generator

Screenshot

Read the contributing.md file and the readme

Hello @Dun-sin,
To my understanding, the example I'm providing serves as a demonstration of the intended functionality. Kindly inform me whether I'm on the right track or if any adjustments are required. I've included a swift example that I put together for the feature. If my understanding aligns with the feature's purpose, I'd be delighted to take on the task and implement the feature in a refined manner. Your guidance would be greatly appreciated.
Example:

Thank you!

Absolutely, @Dun-sin!
Consider it done! I made a lightning-fast tweak to capture the essence and showcase our shared understanding. I will refine it properly.

Absolutely, @Dun-sin!
Consider it done! I made a lightning-fast tweak to capture the essence and showcase our shared understanding. I will refine it properly.

thanks for wanting to contribute, Make sure you follow the rules 👉🏽here👈🏽, else your PR will not be accepted and will be closed. Good Luck

@AmanxUpadhyay are you going to create a new PR?

Dun-sin,
Can you assign this to me?

Just want to make sure, if this suffice?

Just want to make sure, if this suffice?

No, just the name, in the location I specified in the issue

How about this?

How about this?

Yeah perfect

How about this?


Test failures with numpy

Describe the bug
np.int was removed in 1.24.0
To Reproduce
Execute tests with pytest.
Expected behavior
Tests to pass
Output
python3.10-cvxpy> platform linux -- Python 3.10.11, pytest-7.2.1, pluggy-1.0.0
python3.10-cvxpy> rootdir: /build/cvxpy-1.3.1, configfile: pyproject.toml
python3.10-cvxpy> collected 1201 items / 7 deselected / 1194 selected
python3.10-cvxpy> cvxpy/tests/test_atoms.py .......F...................................... [  3%]
python3.10-cvxpy> .............................                                            [  6%]
python3.10-cvxpy> cvxpy/tests/test_benchmarks.py ...s....ss                                [  7%]
python3.10-cvxpy> cvxpy/tests/test_complex.py ....................FF............           [  9%]
python3.10-cvxpy> cvxpy/tests/test_cone2cone.py ...................ss................      [ 13%]
python3.10-cvxpy> cvxpy/tests/test_conic_solvers.py ...................................... [ 16%]
python3.10-cvxpy> .sssssssssssssssssssssssssssssssssssssssssssss.............sssssssssssss [ 22%]
python3.10-cvxpy> sssssss...............ssssssssssssssssssssssssssssssssssssssssssssssssss [ 28%]
python3.10-cvxpy> ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss.......... [ 34%]
python3.10-cvxpy> ..s..s................ssssssssssssssssssss                               [ 37%]
python3.10-cvxpy> cvxpy/tests/test_constant.py .                                           [ 37%]
python3.10-cvxpy> cvxpy/tests/test_constant_atoms.py .FF..FF............FFFFFF............ [ 41%]
python3.10-cvxpy> ...............................F...........FFF....FF.....FFFFFFFF....... [ 47%]
python3.10-cvxpy> ....FFFFFFFF....................                                         [ 49%]
python3.10-cvxpy> cvxpy/tests/test_constraints.py ...........                              [ 50%]
python3.10-cvxpy> cvxpy/tests/test_convolution.py ..F                                      [ 50%]
[...]
python3.10-cvxpy> cvxpy/tests/test_von_neumann_entr.py ........                            [100%]
python3.10-cvxpy> =================================== FAILURES ===================================
python3.10-cvxpy> ____________________________ TestAtoms.test_flatten ____________________________
python3.10-cvxpy> self = <cvxpy.tests.test_atoms.TestAtoms testMethod=test_flatten>
python3.10-cvxpy>     def test_flatten(self) -> None:
[...]
python3.10-cvxpy>                 "corresponding NumPy scalar.", FutureWarning, stacklevel=2)
python3.10-cvxpy>         if attr in __former_attrs__:
python3.10-cvxpy> >           raise AttributeError(__former_attrs__[attr])
python3.10-cvxpy> E           AttributeError: module 'numpy' has no attribute 'int'.
python3.10-cvxpy> E           `np.int` was a deprecated alias for the builtin `int`. To avoid this error in existing code, use `int` by itself. Doing this will not modify any behavior and is safe. When replacing `np.int`, you may wish to use e.g. `np.int64` or `np.int32` to specify the precision. If you wish to review your current use, check the release note link for additional information.
python3.10-cvxpy> E           The aliases was originally deprecated in NumPy 1.20; for more details and guidance see the original release note at:
python3.10-cvxpy> E               https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations. Did you mean: 'inf'?
python3.10-cvxpy> /nix/store/v7h09nqghq11903zdrxkqwmsvx5vfcw4-python3.10-numpy-1.24.2/lib/python3.10/site-packages/numpy/__init__.py:305: AttributeError
python3.10-cvxpy> ________________________ TestComplex.test_partial_trace ________________________
python3.10-cvxpy> self = <cvxpy.tests.test_complex.TestComplex testMethod=test_partial_trace>
[...]
python3.10-cvxpy> FAILED cvxpy/tests/test_constant_atoms.py::test_constant_atoms[atom_info118-Maximize] - AttributeError: module 'numpy' has no attribute 'int'.
python3.10-cvxpy> FAILED cvxpy/tests/test_constant_atoms.py::test_constant_atoms[atom_info119-Maximize] - AttributeError:
[...]
python3.10-cvxpy> OPTIMAL (within feastol=8.9e-09, reltol=1.7e-10, abstol=1.2e-09).
python3.10-cvxpy> Runtime: 0.000067 seconds.

Version

OS: NixOS
CVXPY Version: 1.3.1

Additional context
Build log for 1.3.0: https://hydra.nixos.org/build/219600481/nixlog/1

Hi, @fabaff. Thanks for reporting this! The problem is that you have an out-of-date version of ECOS. ECOS 2.0.10 and lower use np.int, but ECOS 2.0.11 and higher do not. @phschiele @SteveDiamond, we should probably set a lower bound of 2.0.11 on the ECOS version. What do you think?

ECOS has been dropped so this is not needed anymore


Turn-off file extension recommendations

This turns off file extension recommendations since we don't currently have any such recommendations.    We'll want to reenable this code in the near-future likely for KQL files, so we can recommend the Kusto extension when those files are opened.  So this is a tactical change for this specific regression.
PR for https://github.com/microsoft/azuredatastudio/issues/10392.

Coverage increased (+0.05%) to 33.95% when pulling 55be08c4d58767e016b035eb25fb43700a5017f5 on defect/filerecommendation into 19fab3fc9c780a8cd8d0df755c96c5f218bada31 on master.


[ic-pagination-bar]: Added component guidance/code/accessibility

What component is this related to?
Pagination Bar
Why do we need it?
The pagination bar is an atom which was initially built for Data Tables. Pagination Bar can also be used as an isolated component. This ticket is to create:

Component gallery image
Component gallery card
Guidance / Code / Accessibility content

Related open issues
N/A

Guidance to be written


Popular Projects : Docs Added

Popular Projects : Docs Added are from 6._Tensorflow.md to 6.30_redux.md file so there are 31 files

@Aryamanz29 i have added 31 files in popular projects


Adding About page

Hey there!
I can create an about page for the website.
Please assign it to me.
Also, I will need information for the about page, how can we communicate that?

Hey, I need information to put in the about page, how do I get that?


Pulsar chart (work in progress)

Marking this as stale. Please update within one week.

Apologies. I meant to target this PR to a fork as a WIP. I'll close for now and re-open at the appropriate time.


Update referrers API to return a list of descriptors

Fixes #2 .

To help frame the conversation, I've added a discussion: Artifact-spec referrers/ API Response

Updated this PR to remove the manifest encoding for now and just return a list of descriptors. I will watch https://github.com/opencontainers/image-spec/pull/826 to see how the data in a descriptor discussions go, but I'd be generally supportive of adding an optional data field to the referrers response once that behavior is defined that could include the encoded artifact manifest and allow clients to save a roundtrip.

I'd be generally supportive of adding an optional data field to the referrers response once that behavior is defined that could include the encoded artifact manifest and allow clients to save a roundtrip.

As our discussion for support of data has been referenced in the data pr on the image-spec, it's worth clarifying the usage here.
The use of the data element in the referrers/ API response is to OPTIONALLY add encoded manifests. It does not imply the storage of duplicative data. It's an optional optimization on a response object.
One of my concerns with data proposal in image-spec PR #826 is it duplicates the data persisted in the layer in the manifest, unwinding the value of the deduping capabilities of registries. Including the most recent cross-mount deduping API in distribution. Allow for automatic content discovery for cross-mounting blobs #275
It's the possibility that an optional encoded manifest that may be returned in the referrers API may include duplicative layer content that makes it harder for the referrers API to support returning encoded manifests.

As our discussion for support of data has been referenced in the data pr on the image-spec, it's worth clarifying the usage here.
The use of the data element in the referrers/ API response is to OPTIONALLY add encoded manifests. It does not imply the storage of duplicative data. It's an optional optimization on a response object.
One of my concerns with data proposal in image-spec PR #826 is it duplicates the data persisted in the layer in the manifest, unwinding the value of the deduping capabilities of registries. Including the most recent cross-mount deduping API in distribution. Allow for automatic content discovery for cross-mounting blobs #275

Hey Steve, I just want to clarify that the data element proposed in https://github.com/opencontainers/image-spec/pull/826 isn't specific to layers or images. It adds a field to descriptors, which enables the exact the use case described here. The flexibility to use that field in multiple contexts is a consequence of how OCI is structured around descriptors, and I would argue that is a good thing.
As I've explained before, registries have the flexibility to reject manifests that they deem too large, if storing them would be burdensome, and we've discussed trying to find a reasonable size that client can rely on. I would encourage you to join in that conversation: https://github.com/opencontainers/distribution-spec/pull/293
The concerns around unwinding the value of deduplication are pretty insubstantial. Data denormalization is a common optimization in distributed systems with well understood trade-offs. While I agree with you that more deduplication is something to be desired, your concerns regarding data embedded within a manifest are a drop in the bucket compared to what we're currently leaving on the table by continuing to distribute images as compressed tarballs.
Given your passion for maximal deduplication, I would encourage you pick up the torch on revisiting how layers are encoded. Some more context:

https://github.com/opencontainers/image-spec/issues/577
https://groups.google.com/a/opencontainers.org/g/dev/c/Zk3yf45HIdA/m/xRS12Hq7BAAJ
https://groups.google.com/a/opencontainers.org/g/dev/c/daBUKI3KkRk/m/RmdRdvCPAAAJ
https://groups.google.com/a/opencontainers.org/g/dev/c/uqyK22Po0Sg/m/voi8mRd6AQAJ
https://hackmd.io/@cyphar/ociv2-brainstorm
https://www.cyphar.com/blog/post/20190121-ociv2-images-i-tar


[reporting] decouple os.Stdout from PrintReport

This enables calling dnspyre from other binaries/tools without worrying about os.Args and
os.Stdout.
Signed-off-by: Raul Gutierrez Segales<EMAIL_ADDRESS>

/test


build: update PKGBUILD

https://wiki.archlinux.org/title/Python_package_guidelines

Codecov Report

Merging #86 (1654e3f) into main (571b763) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##             main      #86   +/-   ##
=======================================
  Coverage   49.00%   49.00%
=======================================
  Files           5        5
  Lines         251      251
=======================================
  Hits          123      123
  Misses        128      128


Converting to PDF or Word Crashes if there is no image in document

What can I say. I was so focused on getting images right I forgot to test it without images. I'll have a fix out later today.

fixed in 1.16.1


create zenlink grant application

Grant Application
This application is (select one):

[x] Speculative (use this by default)
[ ] an RFP response

This application is (select one):

[x] Public (fully)
[ ] Public with private finances

Abstract
Based on the prediction of the further growth of the DEX ecosystem in the future and the rapid development of the public blockchain technology, we propose a Polkadot network-based, high-liquidity, cross-chain DEX Network, Zenlink.
Checklist

[x] The grants document has been read and understood.
[x] The Google Form will be completed accurately. Note that the Google Form requires the pull request URL.
[x] Abstract (above) is succinct and complete.
[x] The application is being included into the correct directory: either 'targeted' or 'speculative'.
[x] The application includes a project description.
[x] The application includes all names of team members.
[x] The application includes a description of the team's experience.
[x] The application includes all necessary links (e.g. GitHub and LinkedIn)
[x] The "Development Roadmap" section in the application has a timeline of development ("milestones").
[x] The "Development Roadmap" section in the application has an estimate of funds required.
[x] The "Development Roadmap" section gives an indication of the team's long term plans.
[x] The "Development Roadmap" section includes documentation as a deliverable for at least one milestone.

We've applied for an open grant.
Close this PR.

We've applied for an open grant.
Close this PR.


Getting n-1 duplicate parent node if it has n child node

could you give more context to that issue ?

Initially i have only one parent node E150. If i am double clicking the parent node i.e E150, it is expanding with three children which is fine but two extra E150 is also coming which is not required.
Double click of E150 result shown in attached image.


question: handling arbitrary %rax values

One question I have after reading your very interesting atc23_slides_yasukata.pdf slide deck: do you have any safeguards in place / planned for detecting syscall() invocations with invalid (arbitrarily large) system call numbers in %rax? If I understand correctly a zpoline-patched program could call into any arbitrary 64-bit address, where (prior to patching) syscall() would have simply returned an error.

Thank you for your message.
Currently, we do not have the safeguard to detect the cases where %rax has an invalid number, and we do not have a solution to this for the moment.
When we come up with a mitigation, we will update the implementation.


Update memory limits for cpu and requests

https://github.ibm.com/IBMPrivateCloud/roadmap/issues/44943

/lgtm


Disable all mirror feature elements when DISABLE_MIRRORS is enabled

Parameter DISABLE_MIRRORS should disable all elements of
mirroring feature (i.e. filters in UI, updating cron job)
not just creating new mirrors. This mod fixes it and still
allows exiting mirrors to be converted to regular repos when
DISABLE_MIRRORS=true.
If one need disabling only new mirror creation, should
create mod with separate parameter like DISABLE_MIRROR_CREATE.
Fixes: a6fd2f23f7e6bdc60c092207ac43af3a9a291f8f
Author-Change-Id: IB#1105104

I was thining about DISABLE_MIRRORS=true|create|false but this would complicate settings code ... so not a good idear
@pboguslawski this pull remove "disable mirror creation" and add a new feature ... can you add DISABLE_MIRROR_CREATE too so this pull will only add a feature :)

DISABLE_MIRRORS should do what it means - disable whole mirroring stuff not just creation of new repos (so this may be treated as bug in master I think). I don't see any point in introducing separate DISABLE_MIRROR_CREATE parameter (overconfiguration?) but please feel free to add it if you need it.

Was not sure if lack of elements in UI won't break backend (in case lack of variable in post will break something else). Feel free to remove rendering if you're sure it won't hurt.

Was not sure if lack of elements in UI won't break backend (in case lack of variable in post will break something else). Feel free to remove rendering if you're sure it won't hurt

A missing optional parameter must not break this and if it does, it needs to be fixed in the PR that removed it (this one).
Also there should be a server-side check to reject the parameter to prevent spoofing. It might already be there, haven't checked.

A missing optional parameter must not break this and if it does, it needs to be fixed in the PR that removed it (this one).

This PR only hides stuff and is backward compatible (same data is send to backend as before). It you need more changes feel free do extend this PR.

Replaced with #18527.


fix(build-config): remove mjs support when resolving files

due to issues in webpack such as https://github.com/webpack/webpack/issues/7032
Checklist

[ ] All commit messages adhere to the appropriate format in order to trigger a correct release
[ ] All code is written in plain ECMAScript v5 and is formatted using prettier
[ ] Necessary unit tests are added in order to ensure correct behavior
[ ] Documentation has been added

@dmbch 👍


Unity 5.6.7f1 Casting Problem

Hey there,
I ran the program on an old project of mine to see the capabilities. It did export a lot of scripts, but actually got stuck due to an error:
Import: Assembly 'System' has been loaded
Import: Assembly 'System.Core' has been loaded
Import: System.InvalidCastException: Unable to cast object of type 'uTinyRipper.Classes.MonoBehaviour' to type 'uTinyRipper.Classes.GameObject'.
   at uTinyRipper.Classes.ResourceManager.TryGetResourcePathFromAsset(Object asset, String& resourcePath)
   at uTinyRipper.AssetExporters.ProjectAssetContainer.TryGetResourcePathFromAssets(IEnumerable`1 assets, Object& selectedAsset, String& resourcePath)
   at uTinyRipper.AssetExporters.AssetExportCollection.Export(ProjectAssetContainer container, String dirPath)
   at uTinyRipper.AssetExporters.ProjectExporter.Export(String path, FileCollection fileCollection, IEnumerable`1 assets, ExportOptions options)
   at uTinyRipper.GameStructure.Export(String exportPath, Func`2 filter)
   at uTinyRipperGUI.MainWindow.ExportFiles(Object data)

Not quite sure what I can make of that error message...

Hey. Upload resource file so I can reproduce this issue.

Thank you for the quick response. The project is quite large, is there a specific file you need?

File called resoucres.asset or something like that

Got it, here you go. We've used quite a lot of ScriptableObjects, so don't wonder ;)
resources.zip

Can't reproduce it only with resources file. Also need globalgamemanagers file

Sure thing, there you go
globalgamemanagers.zip

fixed in e7706e49c3b8a3486d3761bfae1aab21a463629c

I can confirm, that the bug is fixed. I built the dll with the latest commit and the script ran through. Awesome job and congratulations on the really impressive tool! Thank you also for your quick support!


Classic resources

Hi
I've tried version 0.3.0 against Azure and it doesn't appear to be different to version 0.2.0. Screenshot attached of what I'm seeing.
Basically resource group can be selected, but only a single namespace is available in the dropdown option. When I try and hit save I get a huge list of namespaces that are available (although only 1 was through the combo box).
Got the same issue with 0.2.0
Ken

Actually, this might be my error... I did the grafana-cli command to upgrade... it succeeded but I noticed in the UI that it still says 0.2.0 after a restart. Investigating.

Ok, have now really upgraded to 0.3.0 (I think the initial upgrade was via another account)... but now the ONLY namespace showing up is "microsoft.insights/autoscalesettings"...  and nothing else.
No errors at least... but not useful (particularly since I'm after CPU/Memory usage).

I updated the whitelist for Azure Monitor metrics to not show namespaces where there are no metrics available. ClassicCompute is one of those namespaces. I will however be adding support for some classic namespaces in the near future - it requires a change to the code as the api calls for them are different from the rest of the metrics.


2318: Contact form is submitted to zammad

Short description
This PR addresses submitting the malte form to Zammad. It can be tested here http://localhost:9000/testumgebung/de/offers/help
And an example ticket can be found here -> https://zammad-malte.tuerantuer.org/#ticket/zoom/15.
You should be able to create a customer account if you set your email in the contact form (check your mailbox).
Proposed changes

create the body which is submitted to zammad.
submit the form to zammad

Side effects

[!Note]
I struggled a bit with correctly submitting the form and redirecting afterwards. As the submit function is async but a form submit runs synchronously. This was fixed by adding event.preventDefault() on the submit. Not sure if this has any implications... Feel free to enlighten me.

Resolved issues

Fixes: #2318

I realized that we need to show a proper error message for invalid emails, as this is don by zammad. I don't see that we implement this check in the frontend, as they also check whether the mail actually exists, so let's keep the validation for zammad.


Downgrading SDK to <IP_ADDRESS>

Downgrading SDK back to <IP_ADDRESS> because it does not play nice with mono 2.10.2
Undoing the work of: https://github.com/MindTouch/DReAM/pull/150

Since we have upgraded mono, the downgrade is no longer necessary


"Doesn't work" (/api/hydrogen/hooks/global/usequery)

Doesn't work

Feedback received for:

Page: useQuery (/api/hydrogen/hooks/global/usequery)
Page level feedback
Sentiment: Negative
Associated Markdown file

Next steps:

Here are the suggested next steps for triaging feedback issues.
Hydrogen will triage this issue.
Tagging @Shopify/core-storefronts-custom-storefronts-hydrogen for visibility.
Available on Slack at #hydrogen

This is an automated GitHub issue created with feedback received on Shopify.dev.

View User Agent Details
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36

View IP Data
{"asn"=>"267320", "anon"=>"0", "anonVpn"=>"0", "hostProvider"=>"0", "pubProxy"=>"0", "torExit"=>"0", "countryCode"=>"BR", "regionCode"=>"BA", "regionName"=>"Bahia", "cityName"=>"Salvador", "postalCode"=>"40000", "timeZone"=>"America/Bahia", "lat"=>"-12.86710", "long"=>"-38.48070", "ssbipAnon"=>"0", "ssbipAnonVpn"=>"0", "ssbipHostProvider"=>"0", "ssbipPubProxy"=>"0", "ssbipTorExit"=>"0"}

Metadata
  Please do not edit any metadata. Ask in #core-build-learn for help.

slack_channel: hydrogen
vault_team: https://vault.shopify.io/teams/2632
team_name: Hydrogen

Hey,
Just saw this issue and wanted to flag that on version 1.3.0 this is giving me issues too.
On production build it is not working but locally it is absolutely fine. Looking further into it I am guessing what is being used behind the scenes for the useQuery api hook is what is breaking in production with fetch or Axios.
Anyway, it would be good to see if this was being looked into right now.


Fixing the cuda and cudnn versions in 1.5 docs.

We should also make sure to CP this into master and 1.6


Fixes for SHARED_UPGRADES logic and load lgu command arguments

Description
In this PR I have added a pair of fixes for the following elements.
Fix SHARED_UPGRADES logic for shareStatus on UpgradeBus.cs
The logic in this part was causing that if you setted the value of SHARED_UPGRADES to true, instead of sharing all of the upgrades they were set to be individual.
ex:
shareStatus = cfg.SHARED_UPGRADES ? false: cfg.RUNNING_SHOES_INDIVIDUAL;
now has been changed to:
shareStatus = cfg.SHARED_UPGRADES ? true: cfg.RUNNING_SHOES_INDIVIDUAL;
Fix how the load lgu command uses the following arguments
As it was, it only used the 3rd parameter that you entered in the command, therefore you could not use correctly the name of the player, to use it fully I have only made a substring of the text and get the trailing after the load lgu.

Hi, thanks for the ternary fix and load lgu improvement. Not sure how I wound up with ? false. Too much too fast I suppose lol.
I just did a big refactoring of plugin.cs so I just threw your changes in manually instead of merging to the wrong location.
If you would like to have your name added to the credits thing on the thunderstore listing please reply with the name you'd like credited and a link if any.

Yes, you can add me as Croquetilla, that's the name I use on discord.


Ideas for the App name

[ ] - CodeQuiz
[ ] - DevQuestions
[x] - TriviaDev

DevTest
AskDev
Q4D (Questions for Devs)
Q4D is my favorite

CodeLingo!!!

Discodery ( Discovery + Code )

GetStack

curti o TriviaDev, mas n ficaria melhor: DevTrivia?

[ ] - CodeQuiz
[ ] - DevQuestions
[x] - TriviaDev

if we take that TriviaDev as opposite: DevTrivia, wouldn't be better?

Ask4Dev

DevQuiz


embark run crashes if a contract is deleted

Bug Report
Dashboard crash when deleting contracts
Current behavior
If you have embark run dashboard active and then delete a .sol file inside the contracts/ path, it crashes.
It happens often to me because I have an emacs package that is constantly creating and deleting temporary files for syntax checking, but I happened to me once I was deleting a contract that I was no longer using.
@iurimatias suggested a workaround consisting of adding a negative match pattern in embark.json, like this:
"contracts": ["contracts/**", "!contracts/**/flycheck_*.sol"],

This works for me for the first case.
Expected behavior
Not sure, but it should definitely not crash, specially if the file is not actually needed
If you encounter an error, please create a logfile using the following command and post the output here
Error: ENOENT: no such file or directory, open 'contracts/test/mocks/flycheck_TokenMock.sol'
    at Object.fs.openSync (fs.js:663:18)
    at Function.fs.readFileSync (fs.js:568:33)
    at restrictPath (/home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/lib/core/fs.js:54:43)
    at Object.readFileSync (/home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/lib/core/fs.js:111:10)
    at File.content (/home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/lib/core/file.js:137:20)
    at /home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/lib/modules/solidity/index.js:172:18
    at /home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/node_modules/async/dist/async.js:3110:16
    at eachOfArrayLike (/home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/node_modules/async/dist/async.js:1069:9)
    at eachOf (/home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/node_modules/async/dist/async.js:1117:5)
    at Object.eachLimit (/home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/node_modules/async/dist/async.js:3172:5)
    at prepareInput (/home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/lib/modules/solidity/index.js:161:15)
    at nextTask (/home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/node_modules/async/dist/async.js:5324:14)
    at Object.waterfall (/home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/node_modules/async/dist/async.js:5334:5)
    at Solidity.compile_solidity (/home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/lib/modules/solidity/index.js:159:11)
    at /home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/lib/modules/compiler/index.js:50:18
    at /home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/lib/utils/async_extend.js:7:7
    at /home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/node_modules/async/dist/async.js:3110:16
    at eachOfArrayLike (/home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/node_modules/async/dist/async.js:1069:9)
    at eachOf (/home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/node_modules/async/dist/async.js:1117:5)
    at Object.eachLimit (/home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/node_modules/async/dist/async.js:3172:5)
    at Object.asyncEachObject [as eachObject] (/home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/lib/utils/async_extend.js:4:9)
    at Compiler.compile_contracts (/home/bingen/.nvm/versions/node/v9.4.0/lib/node_modules/embark/lib/modules/compiler/index.js:36:11)

Please provide additional information about your system
OS: Ubuntu 16.04
Embark Version: 4.0.0-alpha.1
Node Version: v.9.4.0
NPM Version: 5.7.1

This will be fixed with: https://github.com/embark-framework/embark/pull/1104


Feature/binding discovery poc

Description
POC for property pane codeeditor changes that is expected to improve Binding discovery for new trial users.
product doc: https://www.notion.so/appsmith/Improve-JS-Binding-Discovery-d00fe2b3d92f402399e41098be89d012
Engineering POC doc : https://www.notion.so/appsmith/POC-for-Binding-Success-07157e8e90c7451a850d6d054d975f36
PR fixes following issue(s)
Fixes #26084
Media
NA
Type of change

New feature (non-breaking change which adds functionality)

Testing

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Also list any relevant details for your test configuration.
Delete anything that is not relevant

[x] Manual
[ ] Jest
[ ] Cypress

Test Plan
test cases for POC are captured here
Engineering POC doc : https://www.notion.so/appsmith/POC-for-Binding-Success-07157e8e90c7451a850d6d054d975f36
Issues raised during DP testing
Checklist:
Dev activity

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Speedbreak features have been covered
[ ] Test plan covers all impacted features and areas of interest
[ ] Test plan has been peer reviewed by project stakeholders and other QA members
[ ] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/build-deploy-preview

/build-deploy-preview

/build-deploy-preview skip-tests=true

/build-deploy-preview skip-tests=true


[Feature] Can lmdeploy quant InternVL2 to AWQ?

Motivation
How to deploy a finetuned InternVL2 of AWQ?
Related resources
No response
Additional context
No response

Yes.
All the **_AWQ models in https://huggingface.co/collections/OpenGVLab/internvl-20-667d3961ab5eb12c7ed1463e are quantized by LMDeploy

Yes. All the **_AWQ models in https://huggingface.co/collections/OpenGVLab/internvl-20-667d3961ab5eb12c7ed1463e are quantized by LMDeploy

quant failed!
shard = {tensor: state_dict[tensor] for tensor in tensors}
NameError: cannot access free variable 'state_dict' where it is not associated with a value in enclosing scope

Pls provide the reproducible code


moving away from intermediate String in more places and using byte[] instead

moving away from intermediate String in more places and using byte[] instead.
this is a follow up PR in the https://github.com/Azure/azure-sdk-for-java/pull/8486 series

/azp run java - cosmos - tests

/azp run java - cosmos - tests

/azp run java - cosmos - tests


go-toolset: update to latest container base ubi9 version.

Description
Update Go Toolset for UBI9 to latest version as per https://catalog.redhat.com/software/containers/ubi9/go-toolset/61e5c00b4ec9945c18787690?architecture=amd64&image=653020421d14c242647051fc&container-tabs=overview
FIXES: https://issues.redhat.com/browse/THEEDGE-3586
Type of change
What is it?

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[ ] Tests update
[ ] Refactor

Checklist:

[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes
[X] I run make pre-commit to check fmt/vet/lint/test-no-fdo

closing this PR in favor of updating tyo latest version of ubi8 as this needs too much time to investigate on fdo compilation problem


Let FlutterEngineGroup be passed in proxy engine constructors in FlutterViewController/FlutterActivity

We're creating a new FlutterEngineGroup spawn API in https://github.com/flutter/flutter/issues/72009.
This requires custom creation of pre-warmed engines. Since we already have shorthands for creating engines implicitly and they're currently all heavyweight engines, create new variants to allow creation of lightweight engines by passing in an existing FlutterEngineGroup.

One of the reasons stated by the user is to take advantage of the lifecycle binding with the UI component rather than self-managing a FlutterEngine instance created from a FlutterEngineGroup. The creator/owner of the FlutterEngine can't easily tap into the destruction lifecycle event of the UI component. Seems like a reasonable concern.


[FEATURE] automatically set max_new_tokens to its maximum value

Hi @OlivierDehaene and @Narsil,
Feature request
Would it be possible to automatically set max_new_tokens to its maximum value. E.g. max_new_tokens=-1 or max_new_tokens=None would be replaced by max_new_tokens=max_total_tokens - len(tokenizer(input_string).input_ids).
Motivation
Right now I'm setting max_new_tokens=max_total_tokens - len(tokenizer(input_string).input_ids) which has the following downsides:

we tokenized twice the input: once to find the desired TGI argument, and once in TGI
we need to know and have access to the path of the tokenizer on the client side. This is annoying when the tokenizer is on the machine where TGI server is running.

It also seems that there are many issues where people hit the max_length limit, it would be very nice (and easy) to automatically select max_new_tokens instead of failing. In any case you can know whether the output was truncated and deal with that if needed.
Your contribution
I don't know any rust but can help if you show me where to.
Thanks for the great library 💯

Thanks for the kind words.
Asking for max_new_tokens all the time will mean the router will consider a lot of tokens for that particular query, meaning it will less be able to stack users.
That being said, it's something that could be nice indeed.

Makes sense, then maybe a better way would be to just support max_length like in HuggingFace GenerationConfig so that we can get a fixed total length without it having to always be the maximum. That would also make TGI more similar to .generate


Fixed #24811 -- Added details on installing PostgreSQL extensions.

When you can add @sbhushan's annotation for multi database setup, this PR LGTM


Add tests for v4

This is a tracking issue for v4 tests.

[x] Clients

[x] AsyncBaseClient
[x] AsyncClient
[x] Client

[x] Dimensions
[x] Filters
[x] Groups
[x] Metrics
[x] OIDC

Missing authentication tests involving the webserver These are now done!

[x] Queries
[x] Reports
[x] Shards
[x] Sort options
[x] Utils

Closed in cc0bf3c.


What is the license of SOLIDER?

Is it under an MIT license? Could you add the license file to the project?

It is under a Apache License 2.0. Thanks for your advice, we will add the license ASAP.


Fix #26

wrong variable in for loop

Thank you for the issue and the fix @crissthiandi 👍🏻 😄  I am going to go ahead and merge!


strange reading on the light sensor & bugs in example code??

hi!
i got your sensor running with a raspberry pi and after a lot of research and tries i got very good readings.. my raspberry pi code:
#!/usr/bin/python

#https://github.com/adafruit/Adafruit-Raspberry-Pi-Python-Code/tree/master/Adafruit_I2C
from Adafruit_I2C import Adafruit_I2C
from time import sleep, strftime
from datetime import datetime
deviceAddr = 0x20

i2c = Adafruit_I2C( deviceAddr, -1, False )

#to change adress
#i2c.write8( 1, 0x22 )

#reset sensor, we need this otherwise i get inconsistent light reading in the dark...
i2c.write8( deviceAddr, 0x06 )
sleep(5)

i2c.write8(deviceAddr, 3)
sleep(3)
light = i2c.readU16(4, False)
temp = i2c.readS16(5, False)/float(10)
moisture = i2c.readU16(0, False)
print str(temp) + ":" + str(moisture) + ":" + str(light)

... only strange thing i noted there was that i had to reset the sensor always before reading values, because otherwise i got strange readings from the light sensor after a few reads... have no clue why... buts that ok with me.
but now i got a shiny new arduino uno and i tried to run your sensor with it, and once again i get wrong readings from the light sensor, e.g. i get a negative reading when measuring in a dark room
i used the provided example code from github a adapted it:
void loop(){

    //Reset i2c moisture sensor
    Serial.println("Reset i2c moisture sensor");
    writeI2CRegister8bit(0x20, 6); //reset
    delay(5000);

    writeI2CRegister8bit(0x20, 3); //request light measurement
    delay(3000);
    int light = readI2CRegister16bit(0x20, 4); //read light register
    int moisture = readI2CRegister16bit(0x20, 0); //read capacitance register
    float temp = readI2CRegister16bit(0x20, 5)/(float)10; //temperature register
    char tempstr[15];
    dtostrf(temp,4, 1, tempstr);

    Serial.print("moisture: ");
    Serial.print(moisture);
    Serial.print(", Temp: ");

    Serial.print(tempstr);
    Serial.print(", Light: ");
    Serial.println(light);
    delay(2000);
}

void writeI2CRegister8bit(int addr, int value) {
    Wire.beginTransmission(addr);
    Wire.write(value);
    Wire.endTransmission();
}

unsigned int readI2CRegister16bit(int addr, int reg) {
    Wire.beginTransmission(addr);
    Wire.write(reg);
    Wire.endTransmission();
    delay(20);
    Wire.requestFrom(addr, 2);
    unsigned int t = Wire.read() << 8;
    t = t | Wire.read();
    return t;
}

and i noted a few strange things in it:
unsigned int readI2CRegister16bit(int addr, int reg) {
...
}

why unsigned ?? ...what about negative temperature values (just tested with a cool-pack, give completely wrong values) (this works with my raspberry pi, python code)
also the example code does not wait 3 seconds with reading light value after writing...?
all in all the provided example code seems wrong to me... i reads values, but i think there is something wrong with the conversion of the values... would be nice if you could have a look into this  or give me some hints what i'm doing wrong... thx

Hi,
I'm not exactly sure why you get weird readings. Are aware that light
measurement takes some time, if you query the sensor before reading is
done, it returns the old value. So basically you should wait for ~3 - 5
seconds before reading light measurement result.
Thanks for the code!
On 11/07/2015 12:08 AM, krikk wrote:

hi!
i got your sensor running with a raspberry pi and after a lot of
research and tries i got very good readings.. my raspberry pi code:
|#!/usr/bin/python
#https://github.com/adafruit/Adafruit-Raspberry-Pi-Python-Code/tree/master/Adafruit_I2C
from Adafruit_I2C import Adafruit_I2C from time import sleep, strftime
from datetime import datetime deviceAddr = 0x20 i2c = Adafruit_I2C(
deviceAddr, -1, False ) #to change adress #i2c.write8( 1, 0x22 ) #reset
sensor, we need this otherwise i get inconsistent light reading in the
dark... i2c.write8( deviceAddr, 0x06 ) sleep(5) i2c.write8(deviceAddr,
3) sleep(3) light = i2c.readU16(4, False) temp = i2c.readS16(5,
False)/float(10) moisture = i2c.readU16(0, False) print str(temp) + ":"

str(moisture) + ":" + str(light) |

... only strange thing i noted there was that i had to reset the sensor
always before reading values, because otherwise i got strange readings
from the light sensor after a few reads... have no clue why... buts that
ok with me.
but now i got a shiny new arduino uno and i tried to run your sensor
with it, and once again i get wrong readings from the light sensor, e.g.
i get a negative reading when measuring in a dark room
i used the provided example code from github a adapted it:
|void loop(){ //Reset i2c moisture sensor Serial.println("Reset i2c
moisture sensor"); writeI2CRegister8bit(0x20, 6); //reset delay(5000);
writeI2CRegister8bit(0x20, 3); //request light measurement delay(3000);
int light = readI2CRegister16bit(0x20, 4); //read light register int
moisture = readI2CRegister16bit(0x20, 0); //read capacitance register
float temp = readI2CRegister16bit(0x20, 5)/(float)10; //temperature
register char tempstr[15]; dtostrf(temp,4, 1, tempstr);
Serial.print("moisture: "); Serial.print(moisture); Serial.print(",
Temp: "); Serial.print(tempstr); Serial.print(", Light: ");
Serial.println(light); delay(2000); } void writeI2CRegister8bit(int
addr, int value) { Wire.beginTransmission(addr); Wire.write(value);
Wire.endTransmission(); } unsigned int readI2CRegister16bit(int addr,
int reg) { Wire.beginTransmission(addr); Wire.write(reg);
Wire.endTransmission(); delay(20); Wire.requestFrom(addr, 2); unsigned
int t = Wire.read() << 8; t = t | Wire.read(); return t; } |
and i noted a few strange things in it:
|unsigned int readI2CRegister16bit(int addr, int reg) { ... } |
why unsigned ?? ...what about negative temperature values (just tested
with a cool-pack, give completely wrong values) (this works with my
raspberry pi, python code)
also the example code does not wait 3 seconds with reading light value
after writing...?
all in all the provided example code seems wrong to me... i reads
values, but i think there is something wrong with the conversion of the
values... would be nice if you could have a look into this or give me
some hints what i'm doing wrong... thx
—
Reply to this email directly or view it on GitHub
https://github.com/Miceuz/i2c-moisture-sensor/issues/2.
[ok]

--
mic.

I think you need an "Unsigned int" for the light reading ... then you will never get negaive values.
For Temperature it could work with "signed" values ... will test the next days ...

I tested the sensor today in "cold" environment an git interesting "light" values - it seems that the light sernsor don't like cold :-)
I've put the sensor in my -14 degree celsius fridge ... each reading in the following list is 3 seconds delay:
At start of the test the values wew at around 236-238 capaticitance, 22,7 degree celsius and ligth around 25/26.000 as you see in the first values. Then I moved to the fridge and light was changig, but this is also not interesting. Look at the timepoint where temperature in falling ...

Any idea?! Except that the sensor do't work well <0 degree celsius :-)

Weel, yes, light measurement is a hack that worked ok for room temperature operated devices ;) If you apply large temperature swings to the sensor, light measurement goes crazy as it depends on AVR pin leakage current and on parasitic capacitance in the LED.

:-)) ok for me personally because I will not really use it, but should maybe be noted on the info-page ...

Shouldn't the light counter top out at 65534 (2^16 - 1) instead of 65535 (2^16) in main.c, line 129 (https://github.com/Miceuz/i2c-moisture-sensor/blob/master/src/main.c#L129)?
I'd recommend to #include <limits.h>  and then use the UINT_MAX constant.
I've noticed this possibility after experiencing a discontinuity in my readings:

i have a few sensors in testing now and all i can say is, that the light reading is a bit jumpy if it comes to low light conditions ... have a look on my graphs for 5 i2c-moisture-sensors and one BH1750 light sensor:

...i first thought resetting the sensor before each reading will get better results, but this is not the case...  we all know the light reading is a "hack" so i can live with it...

To get the idea how does the light sensing work, please look for "led as light sensor" posts on hackaday and whatnot. The basic idea being that parasitic capacitance is charged when reverse-biasing it. Then this capacitance discharges in two ways - via pin leakage and via photo electric effect - more light shines into the led, faster it discharges. By timing this discharge event one can get an estimate of light level there is.
The method is very cheap, but very inaccurate - readings will depend wildly on ambient temperature and from sensor to sensor. Thus it is just suitable for rough estimate is it dark or not.


Add codeclimate config.

Coverage remained the same at 98.684% when pulling 44dc20d8561503b13055c656ae75cdc39883ef34 on add-code-climate into a5fa48a2803620738fef577a2e2f8e5509f02ad9 on master.

Coverage remained the same at 98.684% when pulling 0a5763c0e5c8310ad3ede3e1304a6f020c5c4072 on add-code-climate into a5fa48a2803620738fef577a2e2f8e5509f02ad9 on master.

Coverage remained the same at 98.684% when pulling f671da00b1106af2e2a5dc0bfb73c05014c06af9 on add-code-climate into a5fa48a2803620738fef577a2e2f8e5509f02ad9 on master.


Add binary releases via GitHub releases or Bintray

Releases are now provided by Travis-CI(Linux, FreeBSD) and AppVeyor(Windows).
Releases starting from rsbx 1.0.5 will have deployment builds supplied through GitHub releases.


datatable dependabot warning fixed

Packages / libraries updated to resolve the security warnings (Dependabot alerts)

datatable.net
ws,
tmpl
path-parser
ansi-regex

Few code blocks updated for better code formatting and indentation

data table files taken from https://datatables.net/download/

license link is https://datatables.net/license/ same information will be found in<EMAIL_ADDRESS>file.


resizable is not working in 5.1.0 verison

using react 18 and above you can't use last versions of gridjs and gridjs-react , because of reactDom issue (ReactDOM.render is no longer supported in React 18. Use createRoot instead) , in older vesion of grid js resizable is working well , but in last version (5.1.0) it just show to resizing arrow without any resizing achived !

Yep, this should definitely be fixed.


RBAC issues with Pipe and Knative

What happened?
Based on https://github.com/apache/camel-k/issues/5402 but different error, hence a separate issue.
When I install SERVING and EVENTING (1.14), and than install the Camel-K operator Helm chart(2.3.0), I am getting RBAC errors:
brokers.eventing.knative.dev \"kamelet\" is forbidden: User \"system:serviceaccount:default:camel-k-operator\" cannot get resource \"brokers\" in API group \"eventing.knative.dev\" in the namespace \"default\""}

Steps to reproduce

install the script from https://github.com/matzew/eventing-cloud-integraton with serving
apply the samples manifest
Notice that no pipe gets created (no pod)
log the camel-operator and see the RBAC errors on the log

Relevant log output
camel-k-operator-56d74d67bd-ml8nd camel-k-operator {"level":"info","ts":"2024-04-24T06:50:18Z","logger":"camel-k.controller.build","msg":"Build duration 1m2.567014979s","request-namespace":"default","request-name":"beer-source-pipe","build-attempt":0,"build-result":"Succeeded","build-duration":62.567014979,"api-version":"camel.apache.org/v1","kind":"Build","ns":"default","name":"kit-cokamr7r05jt021tkk40"}
camel-k-operator-56d74d67bd-ml8nd camel-k-operator {"level":"info","ts":"2024-04-24T06:50:18Z","logger":"camel-k.controller.build","msg":"State transition","request-namespace":"default","request-name":"kit-cokamr7r05jt021tkk40","api-version":"camel.apache.org/v1","kind":"Build","ns":"default","name":"kit-cokamr7r05jt021tkk40","phase-from":"Running","phase-to":"Succeeded"}
camel-k-operator-56d74d67bd-ml8nd camel-k-operator {"level":"info","ts":"2024-04-24T06:50:18Z","logger":"camel-k.controller.integrationkit","msg":"Invoking action build","request-namespace":"default","request-name":"kit-cokamr7r05jt021tkk40","api-version":"camel.apache.org/v1","kind":"IntegrationKit","ns":"default","name":"kit-cokamr7r05jt021tkk40"}
camel-k-operator-56d74d67bd-ml8nd camel-k-operator {"level":"info","ts":"2024-04-24T06:50:18Z","logger":"camel-k.controller.integrationkit","msg":"State transition","request-namespace":"default","request-name":"kit-cokamr7r05jt021tkk40","api-version":"camel.apache.org/v1","kind":"IntegrationKit","ns":"default","name":"kit-cokamr7r05jt021tkk40","phase-from":"Build Running","phase-to":"Ready"}
camel-k-operator-56d74d67bd-ml8nd camel-k-operator {"level":"info","ts":"2024-04-24T06:50:18Z","logger":"camel-k","msg":"Kit kit-cokamr7r05jt021tkk40 ready, notify integration: beer-source-pipe"}
camel-k-operator-56d74d67bd-ml8nd camel-k-operator {"level":"info","ts":"2024-04-24T06:50:18Z","logger":"camel-k.controller.integrationkit","msg":"Invoking action monitor","request-namespace":"default","request-name":"kit-cokamr7r05jt021tkk40","api-version":"camel.apache.org/v1","kind":"IntegrationKit","ns":"default","name":"kit-cokamr7r05jt021tkk40"}
camel-k-operator-56d74d67bd-ml8nd camel-k-operator {"level":"info","ts":"2024-04-24T06:50:18Z","logger":"camel-k.controller.integration","msg":"State transition","request-namespace":"default","request-name":"beer-source-pipe","api-version":"camel.apache.org/v1","kind":"Integration","ns":"default","name":"beer-source-pipe","phase-from":"Building Kit","phase-to":"Deploying"}
camel-k-operator-56d74d67bd-ml8nd camel-k-operator {"level":"info","ts":"2024-04-24T06:50:18Z","logger":"camel-k.controller.integration","msg":"State transition","request-namespace":"default","request-name":"beer-source-pipe","api-version":"camel.apache.org/v1","kind":"Integration","ns":"default","name":"beer-source-pipe","phase-from":"Deploying","phase-to":"Error"}
camel-k-operator-56d74d67bd-ml8nd camel-k-operator {"level":"info","ts":"2024-04-24T06:50:18Z","logger":"camel-k.controller.integration","msg":"Integration error","request-namespace":"default","request-name":"beer-source-pipe","api-version":"camel.apache.org/v1","kind":"Integration","ns":"default","name":"beer-source-pipe","reason":"InitializationFailed","error-message":"error during trait customization: knative trait execution failed: unexpected error while executing handler for broker for event kamelet: cannot determine address of broker for event kamelet: brokers.eventing.knative.dev \"kamelet\" is forbidden: User \"system:serviceaccount:default:camel-k-operator\" cannot get resource \"brokers\" in API group \"eventing.knative.dev\" in the namespace \"default\""}
camel-k-operator-56d74d67bd-ml8nd camel-k-operator {"level":"error","ts":"2024-04-24T06:50:18Z","msg":"Reconciler error","controller":"integration-controller","controllerGroup":"camel.apache.org","controllerKind":"Integration","Integration":{"name":"beer-source-pipe","namespace":"default"},"namespace":"default","name":"beer-source-pipe","reconcileID":"5a90526c-1580-4943-8ff8-77dd310851e1","error":"error during trait customization: knative trait execution failed: unexpected error while executing handler for broker for event kamelet: cannot determine address of broker for event kamelet: brokers.eventing.knative.dev \"kamelet\" is forbidden: User \"system:serviceaccount:default:camel-k-operator\" cannot get resource \"brokers\" in API group \"eventing.knative.dev\" in the namespace \"default\"","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/controller-runtime@v0.15.2/pkg/internal/controller/controller.go:324\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/controller-runtime@v0.15.2/pkg/internal/controller/controller.go:265\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.15.2/pkg/internal/controller/controller.go:226"}
camel-k-operator-56d74d67bd-ml8nd camel-k-operator {"level":"info","ts":"2024-04-24T06:50:18Z","logger":"camel-k.controller.pipe","msg":"State transition","request-namespace":"default","request-name":"beer-source-pipe","api-version":"camel.apache.org/v1","kind":"Pipe","ns":"default","name":"beer-source-pipe","phase-from":"Creating","phase-to":"Error"}

Camel K version
2.3.0

Probably an issue with the Camel K Helm chart installation @gansheer?

Yes, that's exactly the issue @christophd . The  triggers resources are declared but not brokers:
Helm:
https://github.com/apache/camel-k/blob/494b0040c154594981cb51f4f7b87023431c0162/helm/camel-k/templates/operator-cluster-roles.yaml#L295-L303
Default installation files:
https://github.com/apache/camel-k/blob/494b0040c154594981cb51f4f7b87023431c0162/pkg/resources/config/rbac/descoped/operator-cluster-role-knative.yaml#L38-L49
That goes for descoped and namespaces files of course.

I just came to the same conclusion.  I did
k edit roles.rbac.authorization.k8s.io camel-k-operator

and added the brokers, and it works

I added a PR for this:https://github.com/apache/camel-k/pull/5412
for the messaging group there were also a few types missing.

Fixed with #5412