drivers: modem: uart_mux errors after second call to gsm_ppp_start

After calling gsm_ppp_start and successfully connecting to the network, then calling gsm_ppp_stop and disconnecting, then calling gsm_ppp_start again, uart_mux errors occur.  Powering up and down the modem via power callbacks.  Using a BG96 modem.
  Maybe the system halts, or just the system workqueue?
This is using v3.1.0-rc1.

Have you tried to use quectel-bg9x driver that should be more suitable for this modem?

@bbilas I haven't.  Thanks for the suggestion.  I'll give it a try.
Shouldn't the gsm_ppp driver also be suitable for the BG96?  There's CONFIG_MODEM_GSM_QUECTEL which suggests it should.  And also the fact that it works great after the first call to gsm_ppp_start :)
Is the main difference between these drivers the fact that quectel-bg9x offloads socket operations to the modem, while gsm_ppp works in PPP mode?  Are there other important differences?

@bbilas I haven't. Thanks for the suggestion. I'll give it a try.
Shouldn't the gsm_ppp driver also be suitable for the BG96? There's CONFIG_MODEM_GSM_QUECTEL which suggests it should. And also the fact that it works great after the first call to gsm_ppp_start :)

I haven't got a chance to use BG96 so I don't know, to be honest. I've been using the gsm_ppp driver with the EC21 and EG21 modules only as it's noted here https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/modem/Kconfig.gsm#L35=.

Is the main difference between these drivers the fact that quectel-bg9x offloads socket operations to the modem, while gsm_ppp works in PPP mode? Are there other important differences?

I've never been using quectel-bg9x driver so I can't help here.


coop scheduling extension

Instead of simulating the behaviour of ES2015 generator functions with our own yield solution with a "throw when done" approach, it might be a good idea to just use them directly. We've already discussed this in slack but I'm not sure if we came to a final decision.
I've modified the most recent version I found, renaming some of the variables:
// spec
interface IPosisCooperativeScheduling {
  readonly used: number;
  readonly budget: number;
  wrap?(makeIterator: () => IterableIterator<void | (() => void)>): void;
}

// example process
class CooperativeProcess implements IPosisProcess {

  context: IPosisProcessContext;

  constructor(context: IPosisProcessContext) {
    this.context = context;
  }

  run() {
    const coop = this.context.queryPosisInterface('coop');
    if(!coop){
      let now = Game.cpu.getUsed()
      coop = { // Shim it!
        budget: Game.cpu.limit - now,
        get used(){ return Game.cpu.getUsed() - now }
      }
    }
    if(!coop.wrap){
      coop.wrap = function(makeGenerator){
        const iterator = makeIterator();
        let result = undefined;
        while(coop.used < coop.budget) {
          if (result && result.done) {
            break;
          }
          result = iterator.next();
        }
        if (result && typeof result.value == 'function') {
          return result.value();
        }
      }
    }
    coop.wrap(()=>this.runCoop())

  }

  * runCoop() {
    // do expensive stuff
    yield; // give kernel option to cancel
    // do more stuff
    yield () => { // give kernel another option to cancel, this time with shutdown function
      // save results
    };
    // and some pretty logging if you want to
  }

If we agree on this I can create a PR to @ezolenko's fork to add this.

@PostCrafter you pass in as makeGenerator then use makeIterator ;) Otherwise, looks good to me

@ags131 Thanks, fixed it.

Ok, changed to PostCrafter's version


mach ordnung in Makefile

[localhost] TASK: wait for tests to finish (debug)> User interrupted execution
make: *** [Makefile:50: check-inside-openshift-zuul] Error 99

recheck

recheck

please rebase it on top of master, to check if tests are wokring well in your case

no brave makefileista?


The floating window did not work fine

Info

Operating System: Arch Linux
Shell: zsh
Terminal: st
nvim --version: v0.8.3
fzf --version: 0.38.0 (352ea072)

[ ] The issue is reproducible with mini.sh

fzf-lua configuration

require('fzf-lua').setup({
})

Description
:FzfLua builtin

" 1. press enter
" 2. search `colorschemes`, and press enter
" 3. then the floating window stuck in there.

The same goes for other commands.

Has this ever worked for you or did you just start using this plug-in?
Have you tried with mini.sh? If it works with mini.sh you probably have an autocmd in your config related to terminal buffers/windows that is causing this, perhaps installed by another plug-in.
Run this and tell me if it works fine:
sh -c "$(curl -s https://raw.githubusercontent.com/ibhagwan/fzf-lua/main/scripts/mini.sh)"

I just start using this plug-in. The mini.sh cmd is works fine for me. Thanks for the reminding. I'll check it out.

I just start using this plug-in. The mini.sh cmd is works fine for me. Thanks for the reminding. I'll check it out.

Great, lmk if you need help, you can use :FzfLua autocmds (even with the float issue) to explore the autocmds and their sources, I would first check BufEnter, WinEnter, TermOpen and TermClose autocmds.

I've located the problem. It's seems that fzf-lua is incompatible with the plugin ethanholz/nvim-lastplace. Thanks!

I've located the problem. It's seems that fzf-lua is incompatible with the plugin ethanholz/nvim-lastplace. Thanks!

Here's a workaround for nvim-lastplace from https://github.com/ibhagwan/fzf-lua/issues/629#issuecomment-1419780400
require 'nvim-lastplace'.setup {
    lastplace_ignore_buftype = {"terminal" },
}

The workaround works for me, thanks!


mod_md still intercepts requests for challenges after disabling MDomain

After testing with one of my domains, I commented out MDomain for that domain. However, if I request https://example.com/.well-known/acme-challenge/, I still get the value from /usr/lib64/apache2/md/challenges/example.com rather than the one from /var/www/example.com/http/.well-known/acme-challenge. This means my previous method of getting new certificates is failing.

Does this work again when you remove the md/challenges/<domain> content?

And by reporting here you are using the latest version from github, I assume?

Please, if you update, give the lastest version v1.1.13 a try.

Ah, sorry, no, I was still using the version delivered with httpd 2.4.33. I now installed 1.1.13 from source (I'm assuming/hoping the whole patching of mod_ssl dance is no longer necessary) and it's interestingly a little better but not quite there: the /.well-known/acme-challenge/ path presents as empty/404, but when I try request any file within it (for example, another challenge that I placed in the correct directory), I still get the challenge value from md/domains. Removing those files did help and I was able to reverify the domain using my other ACME client. Perhaps mod_md should remove those files on configuration changes if MDomain is not enabled?

Thanks for the feedback. The module removes challenges on successful cert retrieval, but - as you noted - obviously not in all cases.
I leave this ticket open to add tests and cleanups.


🐛 [firebase_auth] auth stream changing value when it's not suposed to change - web

When I change my web navigator's size, the user stream changes it's value, making my whole app rebuild (as it looks for the signed state of the user).
I don't know when it started happening, but this wasn't always here (maybe it's related to some recent updates).
Seems related to ScreenUtilInit as if I don't wrap the app with it, the error doesn't occur
Here is a sample project with the error that simulates my app's behavior (there's only the need to set up firebase config):
firebase auth.zip
package versions:
firebase_core: 1.21.1
firebase_auth: 3.7.0
my flutter doctor:
[√] Flutter (Channel unknown, 3.0.5, on Microsoft Windows [versao 10.0.22000.918], locale pt-BR)
[√] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
[√] Chrome - develop for the web
[X] Visual Studio - develop for Windows
    X Visual Studio not installed; this is necessary for Windows development.
      Download at https://visualstudio.microsoft.com/downloads/.
      Please install the "Desktop development with C++" workload, including all of its default components
[√] Android Studio (version 2021.2)
[√] VS Code (version 1.70.2)
[√] Connected device (3 available)
[√] HTTP Host Availability

! Doctor found issues in 1 category.

related to https://pub.dev/packages/flutter_screenutil 5.5.1 to 5.5.2 transition

Thanks for the report @Macacoazul01.

Seems related to ScreenUtilInit as if I don't wrap the app with it, the error doesn't occur

Per this, would be good to follow-up in dedicated repo. If this is happening without any third party plugin, then we would taken this issue forward, or if you are able to replicate the same only with firebase_auth and firebase_core on web, then, please provide an updated code sample that we can use to analyze further.

@darshankawar the problem happens because the package does some sort of "set state" on the app with the navigator size's change, to force the variables to refresh.
I've forced a set state after some seconds to replicate what occurs after the size changes and this is the log ('changed' in the log means that the user stream authStateChanges() was executed):

this issue is more like a "where should I put the user stream" than a firebase problem.
Here's the sample code:
firebase auth.zip

Thanks for the update. Keeping this issue open for further insights from the team.
/cc @russellwheatley

The tree on the real project is like:
Size handler {
Material app{
User stream {
Rest of the app{}
}
}
}

Hello, we released firebase_auth_web 5.2.0 that should fix this. Please update firebase_auth.


errors: More informative error message if wrong table is specified

for relation.

Coverage increased (+0.002%) to 95.782% when pulling 0a94c5b332431dcd6cbd930b180ade6114b74553 on igor-savin-ht:feat/add-model-name-to-ModelNotFoundError into 0f38474e2369dbe0169161c5f8480d9096909788 on Vincit:master.

Coverage increased (+0.002%) to 95.782% when pulling c1441d406eea132b1d753d593d4148a92b50bd76 on igor-savin-ht:feat/add-model-name-to-ModelNotFoundError into 0f38474e2369dbe0169161c5f8480d9096909788 on Vincit:master.

Thanks for the fix! I had one small suggestion. If you fix that, I'll merge this.

@koskimas Done, thank you!

Coverage increased (+0.002%) to 95.782% when pulling bec79bd0c54ca79da04370554490cfcd6f5d3ab5 on igor-savin-ht:feat/add-model-name-to-ModelNotFoundError into 0f38474e2369dbe0169161c5f8480d9096909788 on Vincit:master.

Coverage increased (+0.002%) to 95.782% when pulling bec79bd0c54ca79da04370554490cfcd6f5d3ab5 on igor-savin-ht:feat/add-model-name-to-ModelNotFoundError into 0f38474e2369dbe0169161c5f8480d9096909788 on Vincit:master.

Coverage increased (+0.002%) to 95.782% when pulling bec79bd0c54ca79da04370554490cfcd6f5d3ab5 on igor-savin-ht:feat/add-model-name-to-ModelNotFoundError into 0f38474e2369dbe0169161c5f8480d9096909788 on Vincit:master.

Coverage increased (+0.002%) to 95.782% when pulling bec79bd0c54ca79da04370554490cfcd6f5d3ab5 on igor-savin-ht:feat/add-model-name-to-ModelNotFoundError into 0f38474e2369dbe0169161c5f8480d9096909788 on Vincit:master.

Awesome! Thank you!


Not able to Sign Up new users

Bug Description
I'm disabling Auto_login and setting up superuser.
LANGFLOW_AUTO_LOGIN=false
LANGFLOW_SUPERUSER="admin"
LANGFLOW_SUPERUSER_PASSWORD="dummypasword"
LANGFLOW_NEW_USER_IS_ACTIVE=false
LANGFLOW_SECRET_KEY="randomly_generated_secure_key"
when a new user is trying to sign up, an error will pop up (see screenshot)

Reproduction

pip install langflow==1.0.15
python -m langflow run --env-file ./env
on the login screen, click on sign up

Expected behavior
new user is supposed to be successfully signed up, and admin should be able to receive the new user form to activate it.
Who can help?
No response
Operating System
Ubuntu
Langflow Version
1.0.15
Python Version
3.10
Screenshot
No response
Flow File
No response

Yes, it's a bug that I start facing in v1.0.15. When I downgrade to v1.0.14, signing Up users works fine!

Hey @italojohnny any chance you can reproduce the bug? Just wanted to confirm it is not something wrong with my configs!
To the community, anyone else can reproduce this bug in v1.0.15?

I just went through the same problem, it occurred when signing up and also when accessing with admin and creating a new user.

Yes, I have the same problem, and even with the latest version I can't log in using the login feature, while with version 1.0.14 I don't have these problems using the same .env.
ENV:
LANGFLOW_DATABASE_URL=postgresql://langflow:langflow@langflow_db:5432/langflow
DO_NOT_TRACK=true
LANGFLOW_AUTO_LOGIN=false
LANGFLOW_SUPERUSER="admin"
LANGFLOW_SUPERUSER_PASSWORD="securepassword"
LANGFLOW_SECRET_KEY="eandom_keyss"
AUTH_ACCESS_TOKEN_EXPIRE_MINUTES=-1
AUTH_REFRESH_TOKEN_EXPIRE_DAYS=-1
PYTHONUNBUFFERED=true

@anovazzi1 any chance you can take a look at this issue?

Just leaving my ticket too :D https://github.com/langflow-ai/langflow/issues/3438

#3471


fix Make DorisCallOnce's function exception-safe

Proposed changes
Issue Number: close #xxx
Make the DorisCallOnce's function exception-safe. If the segment calls DorisCallOnce returns an error, remove the cache to prevent subsequent calls from always failing.
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall


Add network timeout support

Updates beanstalk client to support connection and read timeouts.
Defaults to 10s for both types of timeouts with no application changes.
However also adds 2 new functions:
DialTimeout - Connection with supplied timeout argument
SetReadTimeout - Set customisable read timeout
Addressing https://github.com/kr/beanstalk/issues/23

@kr I would appreciate any feedback you have on this, and perhaps it could be merged if you are happy with it. Thanks!

@kr any update on this? Are you happy to merge? thanks

From what I can see, a net.Conn only has Dial and DialTimeout.

No, there's also https://golang.org/pkg/net/#FileConn and https://golang.org/pkg/net/#Pipe. Also, since net.Conn is an interface there are likely lots of other implementations in the world :)

Personally, I'm not really a fan of the 'defaults' being a connection with no timeouts, as it can cause big problems in the real-world of networking.

I agree, but I'm not sure it's something we should work around downstream..

I'm not sure what you mean about removing both Dial and DialTimeout, as it feels like it would make it harder for newcomers to get started with the package (as they would have to construct a net.Conn themselves first).

Yeah, I guess it's a trade-off between library scoping, future maintenance vs. usability. Since I just became the maintainer here I'm going through stuff trying to keep the scope as tight as possible. I'm a big fan of small sharp tools that does very little but very well.

That being said, if we made DialTimeout unexported, or just change Dial to use the default timeouts, then we could merge this PR to make the package 'real world network' safe, without changing the exported API.
Then we could discuss the options for removing the Dial functions in a separate issue perhaps?

Sounds like an excellent plan! 👌 You think you could make that change?
Also, thanks a lot for fixing this!

@JensRantil sounds good, yes will push up an updated PR soon.

hi @JensRantil ive made those modifications.

Hi @JensRantil is this OK to merge now/ I'm preparing a new release of https://github.com/tomponline/beanstalkworker/ and would like to include switching over to go-beanstalk as part of it. Thanks

Hi @JensRantil any chance this could be merged, it'd be great to be able to get rid of my existing fork. Cheers

@JensRantil hello? Can this be merged please?

@dfinkel please don't apologise, your feedback on where this approach falls down in certain usage scenarios is valuable, and even more so is your suggestion for an alternative approach using TCP level keep-alives.
My aim with this patch was to make the go-beanstalk library "real world ready", and avoid others experiencing the production issues we've experienced with this library (programs hanging for days on the reserve command).
I've been using this patch in production for about a year now with no ill effects, however I've been using a restricted sub-set of features in a higher level consumer wrapper (https://github.com/tomponline/beanstalkworker) that disconnects the socket at the first sign of trouble.
I had not considered the multi-reserve scenario or the scenario where people would continue to use the socket after a failure had occurred.
I like the idea of using a TCP socket level keep alive to detect far end failures and cause the socket to close. This feels like a lite-touch way of achieving the aim of making this library recoverable in the scenario of a network glitch.
I'll make the changes and re-submit.
Thanks
Tom

@dfinkel @JensRantil I've had a go at implementing TCP KeepAlives, and it seems to be working as desired.
I used a simple test program:
package main

import (
        "fmt"
	"github.com/tomponline/beanstalk"
        "time"
)

func main() {
	var conn, err = beanstalk.Dial("tcp", "<IP_ADDRESS>:11300")
       if err != nil {
                panic(err)
        }
	id, body, err := conn.Reserve(3600 * time.Second)
        if err != nil {
                fmt.Println(err)
        }

	id, body, err = conn.Reserve(3600 * time.Second)
        if err != nil {
                panic(err)
        }

	fmt.Println("job", id)
        fmt.Println(string(body))
}

Then checked that once the client had connected I could see keepalives being sent:
tcpdump -i lo -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
12:01:48.010387 IP <IP_ADDRESS>.36218 > <IP_ADDRESS>.11300: Flags [.], ack<PHONE_NUMBER>, win 342, options [nop,nop,TS val 58779104 ecr 58769078], length 0
12:01:48.010469 IP <IP_ADDRESS>.11300 > <IP_ADDRESS>.36218: Flags [.], ack 1, win 342, options [nop,nop,TS val 58779104 ecr 58769078], length 0
12:01:58.026384 IP <IP_ADDRESS>.36218 > <IP_ADDRESS>.11300: Flags [.], ack 1, win 342, options [nop,nop,TS val 58789120 ecr 58779104], length 0
12:01:58.026468 IP <IP_ADDRESS>.11300 > <IP_ADDRESS>.36218: Flags [.], ack 1, win 342, options [nop,nop,TS val 58789120 ecr 58769078], length 0
12:02:08.042363 IP <IP_ADDRESS>.36218 > <IP_ADDRESS>.11300: Flags [.], ack 1, win 342, options [nop,nop,TS val 58799136 ecr 58789120], length 0
12:02:08.042443 IP <IP_ADDRESS>.11300 > <IP_ADDRESS>.36218: Flags [.], ack 1, win 342, options [nop,nop,TS val 58799136 ecr 58769078], length 0
^C

At that point, I used iptables to block the connection between the client and the server by just dropping packets:
iptables -A INPUT -p tcp --dport 11300 -j DROP

I then saw the client sending keepalives, but no response from server:
[root@el7build01 ~]# tcpdump -i lo -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
12:05:42.058367 IP <IP_ADDRESS>.36222 > <IP_ADDRESS>.11300: Flags [.], ack<PHONE_NUMBER>, win 342, options [nop,nop,TS val 59013152 ecr 59003136], length 0
12:05:52.074399 IP <IP_ADDRESS>.36222 > <IP_ADDRESS>.11300: Flags [.], ack 1, win 342, options [nop,nop,TS val 59023168 ecr 59003136], length 0
12:06:02.090388 IP <IP_ADDRESS>.36222 > <IP_ADDRESS>.11300: Flags [.], ack 1, win 342, options [nop,nop,TS val 59033184 ecr 59003136], length 0
12:06:12.106377 IP <IP_ADDRESS>.36222 > <IP_ADDRESS>.11300: Flags [.], ack 1, win 342, options [nop,nop,TS val 59043200 ecr 59003136], length 0
12:06:22.122400 IP <IP_ADDRESS>.36222 > <IP_ADDRESS>.11300: Flags [.], ack 1, win 342, options [nop,nop,TS val 59053216 ecr 59003136], length 0
12:06:32.138381 IP <IP_ADDRESS>.36222 > <IP_ADDRESS>.11300: Flags [.], ack 1, win 342, options [nop,nop,TS val 59063232 ecr 59003136], length 0
12:06:42.154387 IP <IP_ADDRESS>.36222 > <IP_ADDRESS>.11300: Flags [.], ack 1, win 342, options [nop,nop,TS val 59073248 ecr 59003136], length 0
12:06:52.170384 IP <IP_ADDRESS>.36222 > <IP_ADDRESS>.11300: Flags [.], ack 1, win 342, options [nop,nop,TS val 59083264 ecr 59003136], length 0
12:07:02.186385 IP <IP_ADDRESS>.36222 > <IP_ADDRESS>.11300: Flags [.], ack 1, win 342, options [nop,nop,TS val 59093280 ecr 59003136], length 0
12:07:12.202395 IP <IP_ADDRESS>.36222 > <IP_ADDRESS>.11300: Flags [R.], seq 1, ack 1, win 342, options [nop,nop,TS val 0 ecr 59003136], length 0
^C

After 10 attempts, the program failed with the following output:
go run beanstalk_demo.go
reserve-with-timeout: read tcp <IP_ADDRESS>:36222-><IP_ADDRESS>:11300: read: connection timed out
panic: reserve-with-timeout: write tcp <IP_ADDRESS>:36222-><IP_ADDRESS>:11300: write: broken pipe

goroutine 1 [running]:
main.main()
	/root/go/beanstalk_demo.go:22 +0x28b
exit status 2

You can see that the 2nd call to reserve fails immediately after the first reserve fails.
So seems to be working, with a default keepalive period of 10s, it takes 100s to timeout and detect connection problem.

@JensRantil any thoughts on this? Please can it be merged yet?

@kr would it be possible to get this PR merged, I think @JensRantil has been rather busy of late and is unable to commit time to this project. Thanks


Add metaclass method examples and description

The problem
Metaclass methods were added in 2015; so far they hadn't been working, or actively used. During release 2019.03 #2673 they were used, which prompted us to request docs for them.
Solution provided
Looking at the implementation, and through a few examples, some use cases have been written and included in the documentation. They can then be pointed at when referring to the corresponding changes in Rakudo, implemented in that release.

@lizmat can you please take a look at this? I can merge it alright, but would like a second opinion.


The clear icon flashes on iOS before opening in fullscreen

The base element’s clear icon flashes in iOS just before the fullscreen dialog covers the icon.
Solution: always hide the base element’s clear icon in fullscreen mode.

No longer relevant; the clear icon is always visible


Fix missing rectangle shape corner

Fixes the corner missing when using the rectangle shape tool with an outline. https://bugs.launchpad.net/pinta/+bug/1922470
Since this bug was marked as a 1.8 milestone, I wasn't sure if it should be added to the gtk 3 branch or master branch. I've attached a before and after picture.

Thanks! The master branch is fine - I can cherry-pick this over to the gtk3 branch

@cameronwhite When will we see a new release? There have been so many fixes since 1.7, I am really waiting for a new release!

I haven't had much spare time lately, but it would make sense to do a minor release soon from the GTK2 branch with all the fixes. We'd also need to go through the bugs currently targeted to the 1.8 release and decide whether they should be fixed immediately or pushed back a bit


Omit curly braces in method call if last argument is a Hash

Is it possible that someday we can omit curly braces  in method call if last argument is a Hash, like in Ruby? Or this is impossible for some reasons?
def method(s : String, to : Hash)
  p s
  p hash
end

# now it works  next way
method "bacon",  { :key => "key" }

# ruby way
method "bacon",  :key => "key"

# or even
method "bacon",  key: "key"

It is pretty cool feature, as it allows to create more clear-looking DSL's

No. This is due to the way keyword arguments are handled in Crystal. See #322 and #560

@ysbaddaden Thanks!

This link helped me. It is really better approach then passing Hashes, and code looks clear as well.


Coverage is not updated at CodeCov

Describe the bug
Coverage is not updated at CodeCov https://codecov.io/gh/swc-project/swc
The latest commit for which coverage is updated is 291251e2dfa6480c86a32ae1d7fe0b3ec3fcffae from Jun 2, 2020.

Screenshot

Expected behavior
Coverage gets updated on codecov on every git push
Version
master
Additional context
Because of this issue, the CodeCov badge shows coverage at 15% which is old

Screenshot

It's killed due to OOM / timeout.
To run coverage, you need a device with 20+ GB ram.
Splitting swc_ecma_transforms can be a solution, but it will make tests much more complex.


Rust Application Migration to fetchCargoTarball Implementation

What
We are making general infrastructure improvements to the cargo fetcher used to
produce the vendor package in Rust applications. This should not materially
change behavior, but will change the cargoSha256, so this is being rolled out
carefully to avoid disruption and merge conflicts.
Motivation
Currently fetchcargo will pull all of the cargo vendor deps into a
attr.cargoDeps package with a recursive sha256 hash. We are migrating to a new
implementation that will compress the cargoDeps into a tar.gz archive that gets
unpacked at the start of the build. This has been implemented and merged in
#78501
The new implementation has several advantages:

It takes up significantly less space on disk in-between builds in the nix store.

It plays nicely with hashed mirrors like tarballs.nixos.org, which only
substitute --flat hashes on single files (not recursive directory hashes).
This is important for internal reproducibility and air-gapped builders.

It's significantly faster with distributed builders, because in that scenario
the actual full src package is copied back and forth (unlike with a binary cache,
where it's compressed). This can be very slow.

It's consistent with how simple fetchurl src derivations work.

It provides a stronger abstraction between input src-package and output
package, e.g., it's harder to accidentally depend on the src derivation at
runtime by referencing something like ${src}/etc/index.html. Moreover, in the
store it's harder to get confused with something that is just there as a
build-time dependency directory vs. an actual runtime package directory,
since the build-time src dependencies are flat tarballs.

It ensures that if a patchPhase makes modifications to the src, the
build/install must reference the patched sources in the build directory,
rather than the original input src package. This prevents issues like #79575

Additional Improvements
Changes to the fetchcargo.nix behavior that cause changes to the cargoSha256
are somewhat disruptive, so historically we've added conditionals to provide
backwards compatibility. We've now accumulated enough of these that it makes
sense to do a clean sweep updating hashes, and delete the conditionals in the
fetcher to simplify maintenance and implementation complexity. These
conditionals are:

When cargo vendors dependencies, it generates a config. Previously, we were
hard-coding our own config, but this fails if there are git dependencies. We
have conditional logic to sometimes copy the vendored cargo config in, and
sometimes not.

When users update the src package, they may forget to update the
cargoSha256. We have an opt-in conditional flag to add the Cargo.lock
into the vendor dir for inspection and compare at build-time, which catches
this mistake; but it defaults to false.

We will bring both of these features in as defaults in the new
fetchCargoTarball implementation.
Migration Plan and Current Status

(DONE in #78501) Implement fetchCargoTarball as a separate, clean fetcher
implementation along-side fetchcargo. Rename verifyCargoDeps (default
false) to legacyCargoFetcher (default true), which switches the fetcher
implementation used. Replace verifyCargoDeps = true; with
legacyCargoFetcher = false; in Rust applications.

(DONE in #79978) Send a treewide Rust PR that sets legacyCargoFetcher = true; in all Rust
applications not using this (which is ~200 of them), with a note to
maintainers to delete if updating the package. Change the default in
buildRustPackage to false.

Backport both (1) and (2) to 20.03 so that other Rust backports can be done without issue.

(In progress, almost done) Go through all Rust src packages deleting the legacyCargoFetcher = false;
line and re-computing the cargoSha256, merging as we go.

Delete the fetchcargo.nix implementation entirely and also remove:

All overrides in application-level packages
The fetchcargo-default-config.toml and conditionals around using it when
no $CARGO_CONFIG exists

This introduced a bug in the legacy fetcher, as found by @Ma27 : previously, it had a step where it would explicitly run chmod -R +w on the vendor directory. I spot-checked ~20 out of the ~220 Rust applications and couldn't find one where this line did anything, and it's done by default in the newer fetcher's unpackFile hook, so I removed the line as a cleanup of "dead" code.
Unfortunately, some Rust applications will run a custom build hook in cargo that writes to the vendor directory; these packages will fail without one of the following two fixes:

Upgrade to the new fetcher, which is now the default behavior unless the package opts-out.  This is preferred since we want to do this anyways for all packages.

Leave it broken on master and wait for the next staging -> master cycle that includes a systemic fix for the legacy cargo fetcher, at which point it will evaluate again.  (See #80153)

For anyone who's looking at bumping a package, no need to recompute the cargoSha256 by hand; just use this script:
#!/usr/bin/env zsh
set -euo pipefail

# Helper script for migrating a NixPkgs Rust pkg to the new cargoSha256
# verification. Run from the root of a NixPkgs git checkout.
if [ -z "$1" ]; then
    echo "USAGE: $0 <attribute>"
    echo "EXAMPLE: $0 ripgrep"
    exit 1
fi

ATTR=$1
FNAME=$(EDITOR=ls nix edit -f . $ATTR)

section() {
    echo "********************************************************************************"
    echo "$ATTR: $1"
    echo "********************************************************************************"
}

main() {
    sed -i '/.*Delete this on next update.*/,/^$/d' $FNAME

    section "Nuking cargoSha256 reference for $FNAME, then rebuilding"
    sed -i 's|cargoSha256.*|cargoSha256 = "0000000000000000000000000000000000000000000000000000";|' $FNAME;
    nix-build -A $ATTR 2>&1 | tee /tmp/nix-rust-logfile-$ATTR || true
    actual=$(grep 'got:.*sha256:.*' /tmp/nix-rust-logfile-$ATTR | cut -d':' -f3-)
    echo "Build of $ATTR determined that cargoSha256 should be $actual"
    sed -i "s|cargoSha256.*|cargoSha256 = \"$actual\";|" $FNAME

    section "Rebuilding with updated hash, expecting a pass:"
    nix-build -A $ATTR || exit 1

    section "Finished successfully!"
}

main

Removing legacyCargoFetcher and updating the cargoSha256 for pkgs/development/tools/parinfer-rust/default.nix behaved weirdly.  On NixOS, it built successfully, but the same commit on MacOS  complained that the same hash is incorrect and tells me to enter all 1s to recompute it.
When I do so, it suggests the hash I tried in the first place.  When I added the hash back, it built.  After it successfully built, I seem to be able to use it from the nix store without issues?
Is it possible there's something nondeterministic here?
See #81005

IIRC, mac can handle encoding differently. It's popped up a few times

I experienced the same issue when I was trying to update pkgs.cargo-make to 0.28.0 on NixOS. @bhipple do you have an idea how this might be fixed (or have some pointers for me how to debug this)? Unfortunately I didn't have the time yet to take a closer look.
I'd like to mention though that I'm now pretty much against #79981 (backport of the fetchCargo-changes to 20.03) as we keep finding issues and I really think that we should leave this on nixos-unstable until 20.09 for further testing (please don't take this personally, I'm still in favor of the actual idea, I just think we should give it more time to stabilize on nixos-unstable).

The issue arises because in pkgs/build-support/rust/default.nix validateCargoDeps is checked during postUnpack, before the cargoPatches are applied.
This would have also happened with fetchcargo  and verifyCargoDeps = true.
Doing the validateCargoDeps check after postPatch fixes the issue:
diff --git a/pkgs/build-support/rust/default.nix b/pkgs/build-support/rust/default.nix
index 3fdfc0636f9..e13662eaefc 100644
--- a/pkgs/build-support/rust/default.nix
+++ b/pkgs/build-support/rust/default.nix
@@ -114,7 +114,9 @@ stdenv.mkDerivation (filteredArgs // {
     EOF

     export RUST_LOG=${logLevel}
-  '' + stdenv.lib.optionalString validateCargoDeps ''
+  ''+ (args.postUnpack or "");
+
+  postPatch = (args.postPatch or "") + stdenv.lib.optionalString validateCargoDeps ''
     if ! diff source/Cargo.lock $cargoDepsCopy/Cargo.lock ; then
       echo
       echo "ERROR: cargoSha256 is out of date"
@@ -131,7 +133,7 @@ stdenv.mkDerivation (filteredArgs // {
     fi
   '' + ''
     unset cargoDepsCopy
-  '' + (args.postUnpack or "");
+  '';

   configurePhase = args.configurePhase or ''
     runHook preConfigure

Tested with the rink crate after removing legacyCargoFetcher, but not further.

@eraserhd does the package have unicode filenames?  You may be hitting https://github.com/NixOS/nix/issues/847, though that would impact you equally on either fetcher.
I've seen this in the wild recently with https://github.com/NixOS/nixpkgs/pull/80583/files.  In that particular case, the non-ASCII filename that causes hash invalidations on MacOS happens to be in a test case, so we can just patch it away by deleting the test case filename without materially impacting the build.  If you find a non-ASCII filename that can't just be nuked like that, then unfortunately you'll have to do something like:
cargoSha256 = if stdenv.isDarin then "XXX" else "YYY";

(Again on either fetcher implementation, since it's an AFS issue for fixed-output derivations on Mac in general, unfortunately.)

@bhipple There's no non-ASCII characters in filenames in the repo.  There's none in the Cargo.toml, either, although there could be transitive dependencies.  It seems like if there were non-ASCII characters, it wouldn't have worked the second time I tried (?).

@B4dM4n / @Ma27 cargo-make and rink are both fixed by #80262, along with anything else that has custom patches or fetcher mutations for the Cargo.lock files. It's been open for a week and a half, waiting for a merge. I think it's good to go though as I've addressed all the PR feedback.

mass rustc rebuilds are tough to review. Rustc seems to mistake my RAM for an all-you-can-eat buffet, and proceeds to consume all of my 32GBs. Linux in a memory-starved environment doesn't handle it very well. Xserver essentially grinds to a halt, and certain processes begin to perform seppuku.

It seems like if there were non-ASCII characters, it wouldn't have worked the second time I tried (?).

Indeed that's true, I was mainly just bringing this up because it's the one known deficiency of fixed-output derivations that has no clean solution on Mac.
Did you see anything interesting in the build output, like Cargo failing or choking out on network access but somehow not killing the build?  What happens if you run nix-store --delete on the package and cargoDeps attribute and rebuild from scratch?  I've built these a few hundred times with Cargo on Linux and haven't noticed an issue yet, and we have some test cases and stripping logic to make Cargo deterministic, but if you have a way to reproduce this (your package worked first try on my machine) I'd be happy to dig into it.

@eraserhd I gave this a try and was successful:
for in in {1..5}; do nix-build -A parinfer-rust.cargoDeps --check || exit 1; done

If you are able to reproduce the issue you saw, please do let me know, as mentioned above.  In the meantime, I'm sweeping forward the remaining PRs that can be done without https://github.com/NixOS/nixpkgs/pull/80262

It would be great if you could add a similar poison mechanism to what we are doing in https://github.com/NixOS/nixpkgs/pull/80953, so that cargo updates force the cargoSha256 hashes to be changed.

@bhipple I ran 10 times on Mac and 10 times on NixOS (parinfer-rust) with no problems.

It would be great if you could add a similar poison mechanism to what we are doing in #80953, so that cargo updates force the cargoSha256 hashes to be changed.

Interesting, we do in fact have some poisoning here: the cargoSha256 will validate that its lockfile is in sync with src, and error out the build immediately if not.  This means there's no risk that you use the "wrong" fetcher with the "wrong" cargoSha256, because an attempt to do so will immediately result it an error like this that the Cargo.lock file is out of sync or cannot be found.  On this particular change, there's a second level of erroring, which is that the cargoDeps derivation is no longer a recursive hash and has a different name, just like in the Bazel poisoning.
One cautionary tale is that the reason a couple packages can't be updated yet (https://github.com/NixOS/nixpkgs/pull/80262) is that the poisoning mechanism itself has a bug for certain packages :)
I haven't been around in the Rust ecosystem long enough to have an idea if Cargo materially changes the vendor directory layout on updates, but if it does I'll look into adding a version poison on this.  That'd be really unfortunate, though, because having to change 200+ fixed output derivations is an expensive amount of churn :/

especially since rust builds are not light. If this were python packages, it would be significantly easier

my simple hello world example breaks because of this change and I'm forced to add legacyCargoFetcher = true for it to build. I did set cargoSha256 to all 1's, wait for fail and copy the expected sha.
but then I get:
these derivations will be built:
  /nix/store/0xji5n7mdsjxw1n533hfrc3prlfs8mh6-hello-hello-0.1.0.drv
building '/nix/store/0xji5n7mdsjxw1n533hfrc3prlfs8mh6-hello-hello-0.1.0.drv'...
unpacking sources
unpacking source archive /nix/store/lrbh9rxl7bls08nkj2j8jgqvjc1yllja-foobar1
source root is foobar1
unpacking source archive /nix/store/09svapal9yq5mjnpi7r1dkxs2av5dxac-hello-hello-0.1.0-vendor.tar.gz
diff: source/Cargo.lock: No such file or directory

ERROR: cargoSha256 is out of date

Cargo.lock is not the same in hello-hello-0.1.0-vendor.tar.gz

To fix the issue:
1. Use "1111111111111111111111111111111111111111111111111111" as the cargoSha256 value
2. Build the derivation and wait it to fail with a hash mismatch
3. Copy the 'got: sha256:' value back into the cargoSha256 field

builder for '/nix/store/0xji5n7mdsjxw1n533hfrc3prlfs8mh6-hello-hello-0.1.0.drv' failed with exit code 1
error: build of '/nix/store/0xji5n7mdsjxw1n533hfrc3prlfs8mh6-hello-hello-0.1.0.drv' failed

here's my Cargo.toml:
[package]
name = "hello-hello"
version = "0.1.0"
edition = "2018"

[dependencies]

[[bin]]
path = "src/hello.rs"
name = "hello"

[[bin]]
path = "src/main.rs"
name = "inout"

and here's my Cargo.lock:
# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
[[package]]
name = "hello-hello"
version = "0.1.0"

and finally default.nix:
{ pkgs ? import <nixpkgs> {}}:
pkgs.rustPlatform.buildRustPackage rec {
  name = "hello-hello-${version}";
  version = "0.1.0";

  src = ./.;

  cargoSha256 = "1nwid5bm5a2fx8jwf5yzslqa72kdbrxxqg7j7rv2q8dpn7qa05d3";
  # legacyCargoFetcher = true;
}

As stated, switching to the legacy fetcher and changing the sha works

That's the aforementioned poison pill bug, which is now fixed on the staging branch (https://github.com/NixOS/nixpkgs/pull/80262).  Until staging is merged to master, continuing to use the fetcher without the cargoSha256 validation is fine, but if you rebase onto staging it should work.
The context here is that you have a fixed-output derivation for the src, and a fixed-output derivation for all the cargo vendor dependencies; when bumping to a new version, you could easily build the new src with the old dependencies.  So the new fetcher has validation that the two Cargo.lock files are in-sync and correspond to the same update.
This worked on ~200/220 of the Rust packages, but the remainder had either patches to the lockfiles, no lockfiles at all, or different src directory layouts than the standards you'd get from pulling off github and crates.io, in which case the poison pill would incorrectly poison the build.  The version on staging is capable of handling all known scenarios, so if you give it a try and it doesn't work please do let me know.

It would probably also make sense to remove the comment in pkgs/build-support/rust/default.nix about this issue, as it is not only incorrect now but also refers to none existing documents.

We're now done with all of the update PRs!  Every package has either been upgraded on master, or has an open PR fixing/upgrading/removing it.
As of this writing, there are 12 open PRs left. The last couple Rust upgrades got really grindy as I encountered a handful of broken packages that have been abandoned upstream without commits for years; in these cases I sent PRs deleting the packages entirely.  In most other cases, we can fix the broken builds on master by just upgrading (as in, they had been broken for a long time, not related to this issue).
I think it probably makes sense to backport the new cargo fetcher implementation to 20.03 now. The main motivation in doing so would be to make it easier to backport Rust updates to 20.03, since right now a maintainer has to re-run the build to re-compute the cargoSha256 after cherry-picking the commit from master to 20.03.  What do you think @ma27 @marsam @NixOS/backports ?
Note that this isn't a forced option; we can keep the old fetcher on 20.03 if we want to, it's just inconvenient for maintainers cherry-picking backport commits if we do so.

Note that this isn't a forced option; we can keep the old fetcher on 20.03 if we want to, it's just inconvenient for maintainers cherry-picking backport commits if we do so.

How inconvenient is mix-and-match, i.e. backporting the existence of the new fetcher and allowing maintainers to decide whether to migrate the backported packages for simpler backporting?

We're now done with all of the update PRs! Every package has either been upgraded on master, or has an open PR fixing/upgrading/removing it.

First of all, thanks a lot for the effort!

I think it probably makes sense to backport the new cargo fetcher implementation to 20.03 now. The main motivation in doing so would be to make it easier to backport Rust updates to 20.03, since right now a maintainer has to re-run the build to re-compute the cargoSha256 after cherry-picking the commit from master to 20.03.

As I stated previously, I'm a bit skeptical about backporting this already. The implementation is rather new and I'm afraid that we'll encounter further regressions that have to be fixed on stable branches as well. For now I think it's better to leave this on master to stabilize.

Note that this isn't a forced option; we can keep the old fetcher on 20.03 if we want to, it's just inconvenient for maintainers cherry-picking backport commits if we do so.

I personally disagree here: this is not the first time where those fixed-output hashes need to be recomputed when backporting and IMHO every maintainer who backports patches should ensure that the hashes are correct.
Also, what if one of the next cargo versions we'll have on unstable changes some behavior that doesn't break anything, but will result in different hashes? (we had this issue about a year ago after a cargo-vendor update for instance).

this is not the first time where those fixed-output hashes need to be recomputed when backporting and IMHO every maintainer who backports patches should ensure that the hashes are correct.

Ah ok, as long as maintainers are aware that they can't just cherry-pick-and-push.  If they go through a pull request and CI though it should fail safely, or if they try to build it.  This just takes ~5 minutes, which is a lot more than the ~30 seconds a cherry-pick may take, but in the grand scheme of things not a big deal. Let's leave it until 20.09 then; LMK if there's somewhere we should communicate this to maintainers for 20.03 backports, though it sounds like they're in the habit of checking this anyways.

Also, what if one of the next cargo versions we'll have on unstable changes some behavior that doesn't break anything, but will result in different hashes? (we had this issue about a year ago after a cargo-vendor update for instance).

This is a big fear of mine, and would really suck. However, a lot of what this ticket is doing is making it easier to mirror / download / transfer the cargoDeps package without having to build it with Cargo itself.  Since it's no longer a recursive fixed-output derivation, it shows up in the content-addressed source tarball mirror https://tarballs.nixos.org, so even users who aren't using the binary cache can pick it up, and even users who aren't using the hashed mirror can just download the tar.gz file and put it into the store or on an FTP server.
All of the above just reduces the blast radius and mitigates damage if Cargo screws us, though; it doesn't solve the root problem.  I'm hoping that Cargo is well-behaved enough that this never happens, or only happens once every couple years and is manageable ... is there a ticket about the cargo vendor update issues that I can check out to see how we've dealt with this in the past?

This is a big fear of mine, and would really suck. However, a lot of what this ticket is doing is making it easier to mirror / download / transfer the cargoDeps package without having to build it with Cargo itself. Since it's no longer a recursive fixed-output derivation, it shows up in the content-addressed source tarball mirror https://tarballs.nixos.org, so even users who aren't using the binary cache can pick it up, and even users who aren't using the hashed mirror can just download the tar.gz file and put it into the store or on an FTP server.

That's true, I wanted to state something different: if cargo alters its behavior and we get different hashes, we'll have to regenerate our hashes again when backporting patches to release-20.03 even if your changes get backported now.
I mentioned this to demonstrate that we can't promise deterministic cargo-hashes between unstable and release which is why I don't consider it a benefit that with your stuff backported you wouldn't need to regenerate cargo-hashes at the moment.

is there a ticket about the cargo vendor update issues that I can check out to see how we've dealt with this in the past?

For instance #60668. The "fix" was to update all hashes. This isn't a totally bad thing, but also shows that we can't guarantee that you don't have to recompute hashes when backporting.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/steps-towards-even-more-pr-automation/5634/11

There are just three uses of the legacy fetcher left:

https://github.com/NixOS/nixpkgs/pull/80243
https://github.com/NixOS/nixpkgs/pull/81994
https://github.com/NixOS/nixpkgs/pull/82213

If someone could help with reviewing/merging, that'd be great.  Once those three are gone, we can proceed with the deletion of the legacy infra and complete this ticket!


Unplant Seeds

Is your feature request related to a problem? Please describe.
Currently user does not have a way to unplant seeds they have already planted.
Describe the solution you'd like
User can begin unplanting seeds.

Coming Soon... Unplant Progress & Claim Unplanted Seeds
Additional context
Add any other context or screenshots about the feature request here.

https://github.com/JoinSEEDS/seeds_light_wallet/issues/1194


Configure Dependabot for Automatic Dependency Updates

Enable Dependabot for Dockerfile and go.mod updates.
This will update images in Dockerfile FROM statements, and go modules.
The purpose is to drastically reduce number of vulnerabilities that affect this repo,
by keeping dependencies up-to-date.
This PR is created by a script. Please let me know if we should modify any values.

/ok-to-test
/lgtm
/approve


aspnet/core/tutorials/first-web-api show how to pass multiple params

add 2nd param for all items where is IsComplete = false or true, whatever you pass.
Customer asked for this.

@scottaddie Is this applicable to what you're working on? Web API stuff, correct? Or is that @guardrex?

@rachelappel @Rick-Anderson Is there any more detail to provide on this? It's not clear to me what needs to be done.


Check QR version

QR codes shouldn't exceed version 22 (with 105x105 modules), provide a warning if they do. Fixes issue #56.
WORK-IN-PROGRESS:

[ ] implement QR version check (TODO)
[x] add test for QR version

Our current QR scanning lib doesn't return the version/module info, so we'll need an alternative way of doing this.

The easiest way to get the version back is to have jsQR return it. I opened a PR on the project; let's see if it gets through rapidly. Otherwise, we'll need to find an alternative solution.

The PR mentioned above was merged in jsQR. Updating to v1.4.0 will allow us to get the QR version back.

Ran npm update to get latest jsQR version, allowing to read the QR version.


sf::text horizontal letter spacing

I’m just wondering what is the status of the old pull request adding the ability to change the spacing between characters.
https://github.com/SFML/SFML/pull/928

I see that nobody answered to your comment in the PR, sorry. But no need to open a new one for that.

Sorry for that, but it was just a single random act of desperation.


index-only option for simple search

Is your feature request related to a problem? Please describe.
I am a heavy user of the simple search, the one I get when I type ctrl-f. The items I search for are always in an indexed field of my database, but the target text appears many times in other fields. This substantially increases the time it takes for me to find anything.
Describe the solution you'd like
The DB Full--Text search window contains a very useful option, Fast search (indexed). I would like that option added to the ctrl-f Find/Replace window. The search would then be conducted only on indexed fields.
Describe alternatives you've considered
DB Full-Text is not a viable alternative because the Databases information must be entered each time, which consumes even more time.

@fossildoc Can you elaborate how you see this added to find/replace? That is a basic cheap feature and it performs the search only in fetched rows.

Fetched rows has nothing to do with it.
"DB Full-Text" has a checkbox,"Fast search (indexed)". This causes the
search to be made only in indexed fields of the table specified in the
"Databases" dropdown list. If the box is not checked, the search is made in
all the fields of the specified table.
That feature is not available in the ctrl-f "Find/Replace" window, so
searches are always made in all the fields of the displayed table.
I would like a "Fast search (indexed)" option added to the "Find/Replace"
window so that the search is made only in indexed fields of the displayed
table.
On Thu, Sep 16, 2021 at 2:56 AM Matvey16 @.***> wrote:

@fossildoc https://github.com/fossildoc Can you elaborate how you see
this added to find/replace? That is a basic cheap feature and it performs
the search only in fetched rows.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dbeaver/dbeaver/issues/13876#issuecomment-920629071,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEF4CXBO4O6RBXNBJJSYY6TUCGIKLANCNFSM5D35MWYQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

@fossildoc I was talking about fetched rows because the "Find/Replace" search is intended for them. They are different operations. DB Full-text performs a query on your database, so indexed search lowers the cost of that query. But the search with ctrl+f is performed on the client only on the fields that are fetched currently in data editor and doesn't actually interact with your database, so it doesn't need an indexed search.
Maybe we are talking about different things, but Find/Replace is just a basic client-side search that you can find in any text editor like notepad.

For the life of me I cannot fathom what you don't understand about my
request. I don't see any ambiguity in it. Let's go through it one more time
with feeling. I'll speak slowly and loudly, like I was talking to a foreign
tourist.
CTRL-F FIND/REPLACE WILL RETURN A SUBSET OF THE FETCHED ROWS OF THE
CURRENTLY DISPLAYED TABLE FOR WHICH THE SEARCH TARGET IS FOUND IN ANY OF
THE DISPLAYED COLUMNS.
i WANT AN OPTION THAT WILL RETURN A SUBSET OF THE FETCHED ROWS OF THE
CURRENTLY DISPLAYED TABLE FOR WHICH THE SEARCH TARGET IS FOUND ONLY IN
DISPLAYED COLUMNS WHICH ARE INDEXED.
If you still cannot understand this, please pass my request to an English
native speaker with experience in database design.
On Mon, Sep 20, 2021 at 6:56 AM Matvey16 @.***> wrote:

@fossildoc https://github.com/fossildoc I was talking about fetched
rows because the "Find/Replace" search is intended for them. They are
different operations. DB Full-text performs a query on your database, so
indexed search lowers the cost of that query. But the search with ctrl+f
is performed on the client only on the fields that are fetched currently in
data editor and doesn't actually interact with your database, so it doesn't
need an indexed search.
Maybe we are talking about different things, but Find/Replace is just a
basic client-side search that you can find in any text editor like notepad.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dbeaver/dbeaver/issues/13876#issuecomment-922821339,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEF4CXCQDKZFQ6GTY4JESLTUC4HNFANCNFSM5D35MWYQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

@fossildoc I don't understand why you think that ctrl+f has anything to do with database design or table metadata (index in this case). As I already said this search has nothing to do with any metadata or indexes, it doesn't even return a subset of rows, it returns a subset of table cells that contain alphanumeric value that you specified in your search. I want to again point on the fact that this search doesn't read any table metadata or even actual data from the table, it works only with the data that is already fetched for the client side. Here is the example of how it works for a table with 1 million rows, but at the time of the actual search it has only 100 rows fetched

For this search to even know which column is indexed it would require an additional metadata read. And that can be a redundant option for such a basic feature and that is why we have DB Full-Text search
The only feature that I see fitting here is adding an option to search only in selected columns. Do you think it will be enough?


Upgrade to use node 18 (LTS) in pipelines

Upgrades to use Node 18 (LTS) in pipelines

VSCode Extension Installation Instructions

Download the extension at https://azuresdkreleasepreview.blob.core.windows.net/azd/vscode/pr/1853/azure-dev-0.5.0-alpha.1.vsix
Extract the extension from the compressed file
In vscode
a. Open "Extensions" (Ctrl+Shift+X)
b. Click the ...\ menu at top of Extensions sidebar
c. Click "Install from VSIX"
d. Select location of downloaded file


page.current_path takes time to change

After clicking on a link, it takes a few hundred milliseconds for page.current_path to update. In one measured case, I saw it take between 300-400 milliseconds.
I'm encountering this as I am trying to migrate from PhantomJS to capybara-webkit, so the behavior is not super exciting :innocent: .
Unfortunately, there's no implicit waiting from Capybara for current_path / current_url. Am I doing something incorrect? Is there a workaround, or should I insert my own busy-wait?
Thanks for a pretty good tool so far!

This also applies to page.response_headers, for probably the same underlying causes.

If the content on the page is being loaded via JavaScript and pushState is being used, this is to be expected. There are other instances where a page load is not triggered before the subsequent request for current_url is received. There are even a few bugs with this logic, so if you can isolate a failing test case, that'd make this a lot easier to debug.
In either case, I'd recommend asserting that you're on the expected page, by checking the content of the page, before using either of these methods. The recommended Capybara strategy is to assert the user experience -- which rarely involves URL structure or headers. Of course, it's sometimes useful to make these assertions, which is why we've added the features.

is being loaded via JavaScript and pushState is being used

This is absolutely the case; it's a normal Rails application with turbolinks enabled.

by checking the content of the page

Yes, this is normally what we do as well, but it's a fine line here about duplicating test content across mostly-unrelated tests.
However, it's more insidious with some of the requests for the response headers, which we use to test if a CSV file was downloaded, or what filename was suggested, for example. Please let me know if there's a way to test that by looking at content!
This sounds like everything is working for the gem as expected, so maybe the correct path is to document this somewhere. Any suggestions for that?

@shepmaster if you upgrade to capybara 2.5 it has waiting behavior on has_current_path/have_current_path

upgrade to capybara 2.5

@twalpole I see that you added that, so thanks! After our emergency switch from PhantomJS to Capybara-Webkit, upgrading Capybara was the first thing I did. Works like a charm, I just wish there were matchers for the other things (headers, status codes) :wink:

Hey @shepmaster. Glad to hear the updated Capybara is working for you. It would probably make sense to add a note, perhaps a new heading above Offline Application Cache, regarding asynchronicity. PRs welcome!


Why is react-native-vector-icons listed in peerDependencies?

Why not list react-native-vector-icons as dependencies?

It should be listed as a peer dependency because it must be installed before being able to use the library. Have you had any issues getting it up and running?

Oh, just realized you said peerDependencies vs dependencies. Mainly because we did at first have it as a dependency and had a lot of people submitting issues because they could not get the vector icons installed, and had nothing to do with RN Elements, so we figured we'd let people get the icons installed themselves, which has led to less issues on our end.


Add node protocol

I've added node protocol prefixes. I manage this repo from within monorepo of libraries I maintain so I couldn't merge this directly.


New pubsub.... now with websockets!

I fixed up the existing websocket code in pubsub.c and made it follow RFC 6455.  This includes properly handshaking with the client and proper data framing and fragmentation.  Everything has been tested and works just fine!
This change has also been moved into pubsub_filterable so that clients can directly connect to a pubsub and filter on it (because reading the full pubsub can sometimes be troublesome!).

I am going to clean up the code a bit.... hold off on merging until there is a fourth commit!

@mynameisfiber these changes look good. Can you bump the version number defined at the top of pubsub.c and pubsub_filtered.c ?
Also, can you run astyle on the files you've changed (you can brew install astyle to get it).
It should probably be documented somewhere (a "contributing" section of the main readme perhaphs) but this is the astyle command we are currently using
astyle --style=1tbs --lineend=linux --convert-tabs --preserve-date --fill-empty-lines --pad-header --indent-switches --align-pointer=name --align-reference=name --pad-oper --suffix=none file.c

Thanks for the updates. this looks good now. can you rebase/squash your commits?

I rebased/squashed and accidentally pushed to bitly/simplehttp... luckily everything was already okay'd to go!  hope this doesn't cramp anyone's style.


Empty data Key in Error Responses

Description:
Currently, error responses include a data key with a null value when no data is present. For example:
{
    "error": {
        "message": "missing params: name, userName, password"
    },
    "data": null
}

Observation:
It may be more streamlined to omit the data key entirely if there is no data to return. This would make the error responses more concise and potentially easier to handle.
Suggested Action:
Consider modifying the response format to omit the data key when it is null, resulting in a cleaner and more straightforward error response structure.
Additional Context:
If there are specific reasons for including the data key even when null, please provide details. Otherwise, this change could improve response clarity.

I will raise a PR for the same

https://github.com/gofr-dev/gofr/pull/915

Could you please review it and let me know if any changes are needed?
Looking forward to your feedback.
Thanks!


Trying to modify last task after with a task without full name on 83.1 release

Terraform CLI and Provider Versions
Terraform v1.1.9
on linux_amd64
...
terraform {
required_providers {
snowflake = {
source  = "Snowflake-Labs/snowflake"
version = "0.83.1"
}
}
}
Terraform Configuration
The code is working fine with the 0.69.0 release version and there is no changes on the after parameter.

Expected Behavior
NO CHANGES OR
 # module.instance.snowflake_task.parse_incoming_data will be updated in-place
  ~ resource "snowflake_task" "parse_incoming_data" {
      ~ after                           = [
          - "<SOME OTHER TASK FULLNAME>",
          + "CTG_DEV_PLK.INGESTION.COPY_FROM_KINESIS_S3_DELIVERY",
        ]
        id                              = "CTG_DEV_PLK|INGESTION|PARSE_INCOMING_DATA_DELIVERY"
        name                            = "PARSE_INCOMING_DATA_DELIVERY"
      + suspend_task_after_num_failures = 0
        # (8 unchanged attributes hidden)
    }

Actual Behavior

 # module.instance.snowflake_task.parse_incoming_data will be updated in-place
  ~ resource "snowflake_task" "parse_incoming_data" {
      ~ after                           = [
          - "CTG_DEV_PLK.INGESTION.COPY_FROM_KINESIS_S3_DELIVERY",
          + "COPY_FROM_KINESIS_S3_DELIVERY",
        ]
        id                              = "CTG_DEV_PLK|INGESTION|PARSE_INCOMING_DATA_DELIVERY"
        name                            = "PARSE_INCOMING_DATA_DELIVERY"
      + suspend_task_after_num_failures = 0
        # (8 unchanged attributes hidden)
    }

Steps to Reproduce

terraform apply

How much impact is this issue causing?
High
Logs
No response
Additional Information
It seems that we have a related issue https://github.com/Snowflake-Labs/terraform-provider-snowflake/issues/2207

Hey @mdefariaborges-rbi. Thanks for reporting the issue.
It seems that moving to SDK implementation broke something in the task resource. It is the same problem as in #2207. I will bump its priority.

@mdefariaborges-rbi could you validate if the issue persists in v0.86.0? If so, please share the configurations of the two tasks you mentioned.

@mdefariaborges-rbi @sgavrilov-rbi @cmogren-rbi is this issue still present in the newest provider version?

Closing due to inactivity. Please report a new issue if the problem persists in the newer provider versions.


packages.config should be deleted

After converting project, packages.config still remains even though those references are now migrated to <PackageReference> elements.
The file is also specifically mentioned in the generated csproj:
<None Include="packages.config" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" />

Which it should not.
I recommend this file is deleted. Or at least renamed to .old.

The same probably applies for any nuspec file being converted to be inside csproj

Agreed, but we still need to figure out if we have parity for both files in the new system.
At first I didn't want to touch any of these files but it is weird to keep them included. I think renaming them too is worthwhile and safe.

This is now renamed by merging #26 the packages config is now renamed.
I won't delete any file as I cannot assume version control being present.


Handle borrows of unions in NLL

This is a small addition to RFC2094 so that we can handle unions as outlined in RFC1444.
Rendered

I think the right place to specify the handling of unions is the place describing

Accessing an lvalue LV

And I think we can write something as follows

there is a loan for the path lvalue;

so: writing a path like a.b.c is illegal if a.b.c is borrowed

there is a loan for some prefix of the path lvalue;

so: writing a path like a.b.c is illegal if a or a.b is borrowed

lvalue is a shallow prefix of the loan path

shallow prefixes are found by stripping away fields, but stop at
any dereference
so: writing a path like a is illegal if a.b is borrowed
but: writing a is legal if *a is borrowed, whether or not a
is a shared or mutable reference

the loan path has a shallow prefix <base>.<field1> that accesses a field of a union, and lvalue has a prefix of the form <base>.<field2> for a different field with the same base union.

so: if a.b is a union with distinct fields x and y, shallowly accessing a path a.b.x.c is illegal if a.b.y or a.b.y.s is borrowed. There <base> is a.b, <field1> is y and <field2> is x.
but: unless a.b.x is also a union, it is legal to access the a.b.x.c is legal if a.b.x.d is borrowed, because the same union field is used in both borrows.
the prefix of lvalue can be an arbitrary prefix - if a.b.y.s is borrowed, then it is illegal to shallowly access *(*a.b.x.c).t.

And on the supporting section:

the loan path has a supporting prefix <base>.<field1> that accesses a field of a union, and lvalue has a prefix of the form <base>.<field2> for a different field with the same base union.

so: if a.b is a union with distinct fields x and y, deeply accessing a path a.b.x.c is illegal if a.b.y, a.b.y.s, or, (in contrast with shallow accesses) as long as both dereferences are of a &mut T, *(*a.b.y.s).t is borrowed. There <base> is a.b, <field1> is y and <field2> is x.

@arielb1 So from the union RFC, we have this property:

any borrow conflicting with a borrow of the union (including a borrow of another union field or a borrow of a structure containing the union) will produce an error.

In your example, that would also mean that a also cannot be borrowed, I.e. we need to add in additional conditions as follows:

the loan path has a shallow prefix <base>.<field1> that accesses a field of a union, and lvalue has a prefix of the form <base>.<field2> for a different field with the same base union, or <base> is in the form of <prefix>.<union> and lvalue is a prefix of <prefix>.

Disregard my previous comment, the case that I was concerned about is covered by the "lvalue is a shallow prefix of the loan path" rule.

Updated the text to display a more correct version of handling union fields.

Specifying borrowing errors through loan path "intersection" seems significantly more complex than recursive definition "borrow<'a>(prefix.field) -> borrow<'a>(prefix) && borrow<'a>(prefix.siblings), repeat until there prefix is empty".

Oh my.
https://github.com/rust-lang/rust/issues/45157

OK, sorry for coming late to the party. I finally carved out some time to read these changes. I agree that these sound roughly correct. I was, however, curious if we could frame this check in a more generic way -- essentially, the key question we are testing here is whether two paths are "disjoint" (i.e., refer to distinct memory).
I was thinking we could frame this in terms of some inference rules. For fun, I typed these up in Prolog, and you can try them out here. The rules are basically like this:
/* Two distinct variables are disjoint */
disjoint(var(V0), var(V1)) :- V0 \= V1.

/* Two paths `p.f` and `p.g` are disjoint
 * if the fields `f` and `g` are disjoint. */
disjoint(field(P, F0), field(P, F1)) :- disjoint_fields(F0, F1).

/* Two paths `p.f` and `q` are disjoint
 * if `p` is disjoint from `q`. */
disjoint(field(P0, _), P1) :- disjoint(P0, P1).
disjoint(P0, field(P1, _)) :- disjoint(P0, P1).

The rules for disjoint fields are then:
/* Two distinct fields in the same struct are disjoint. */
disjoint_fields(F0, F1) :-
    type_of(F0, S),
    type_of(F1, S),
    is_struct(S),
    F0 \= F1.

/* Fields declared in two distinct types are disjoint. */
disjoint_fields(F0, F1) :-
    type_of(F0, S0),
    type_of(F1, S1),
    S0 \= S1.

This seems to behave like I expect -- I included a number of examples in the link above, including rust-lang/rust#45157 (that's the last example, I believe). When I run them, they seem to yield true/false as I expect. =)
What I like about this formulation is that it scales quite readily to supporting fields in traits -- we simply have to make the disjoint_fields predicate line up. I also like that it's declarative.
I'm not proposing that we necessarily implement the rules like this, in any case, but I think it might be a useful way to specify them. I'm not sure yet if this PR is equivalent to the rules I wrote above -- I suspect it is, but I ran out of my quota allotted to reading and thinking here and have to go and get ready for Rust Belt Rust! =)

A meta question: should we keep updating the RFC here, or in the nll-rfc repo? I think I'd prefer to iterate on the nll-rfc repo (which I could move to rust-lang-nursery or something), just because these are narrow questions and I don't know that we need to use the full RFC repo. And we are still tracking some other unresolved questions there as well. But I'm kind of open to either.

Superseded by #2174.


riscv: Fix passing -mabi/-march to linker

TOOLCHAIN_LD_FLAGS gets passed to zephyr_ld_options() that will call
zephyr_check_compiler_flag().  Current zephyr_check_compiler_flag()
fails on RISC-V for -mabi/-march as the compiler expects them to be
set together.  To make this work we quote them together so they'll
get treated as a single option rather than two distinct options.
Doing the same for TOOLCHAIN_C_FLAGS isn't required and actually
doesn't work because target_compile_options will end up keeping
the quoting.
Fixes #28456
Signed-off-by: Kumar Gala<EMAIL_ADDRESS>

@galak Thanks for this.
This was actually discussed here: https://github.com/zephyrproject-rtos/zephyr/pull/26545#discussion_r474618754
I actually has a cleaner fix ready, but seems I missed to create a PR with it:
https://github.com/tejlmand/zephyr/commit/bb2f2b9171f9550ecc43a314538dd83dba1b13fd
This avoids the need to depend on quotes which could lead to other issues at a later time.

placed alternative solution here: https://github.com/zephyrproject-rtos/zephyr/pull/28464

Closing this in favor of #28500


format with Black

This PR reformats everything with 'black -S'. (the -S option is to keep quotes unchanged)
One exception: most files that start with a "Constants" section have a locally-fenced (fmt: off/on) section to keep the constants as a table.
A subsequent PR will add automation and settings for Black and pylint, but this PR is only for the initial (re)formatting as a single commit, so that it can then be ignored by a git blame.

Do you have a strong opinion on single quotes vs double quotes? Although you can use black -S to leave quotation unchanged, it would be nice to auto-format code one way or the other instead of relying on developers to match a preferred style.
black is an opinionated code formatter and does not provide an option to format strings to single quotes. If you feel strongly about single quotes, maybe one of the black forks (like axblack or oitnb) would be useful?

Do you have a strong opinion on single quotes vs double quotes? Although you can use black -S to leave quotation unchanged, it would be nice to auto-format code one way or the other instead of relying on developers to match a preferred style.

I do prefer single quotes a lot, but that's a personal preference. The reason I'm punting on it for now, and still leaving quotes unchanged, is because I want to leave room for the opportunity for black to eventually support single quotes (as do the people who created the blue fork of black: "...Instead, our hope is that eventually we’ll be able to work with the black maintainers to add just a little bit of configuration and merge back into the black project. We’d be ecstatic if blue eventually were retired...".
If that doesn't happen in a reasonable time, then maybe we can decide to just go with single quotes. But let's wait a bit... just in case.
NOTE: I may very well use blue for my own setup, so that I can keep my quotes consistent.


Update f1ac3901-238d-3e38-45dc-f659fd88c23b.md

Needs loop to be on a separate line

Hi @maverickmonster, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;


KIE Docker UI - Fixes and improvements

Removed home view
Improved views usability
Reduced to 4 permutations
Added pulling worker thread to check containers status on the remote docker service (defaults to 10min interval).
Improved performance
Logging
Clean-ups & bug fixing & others

Please check your mail Petr. Thanks


Failure to update WSL v1 to v2

Version
Microsoft Windows [版本 10.0.22000.527]
WSL Version

[ ] WSL 2
[X] WSL 1

Kernel Version
No response
Distro Version
Ubuntu-20.04
Other Software
No response
Repro Steps
wsl -l -v
wsl --set-version Ubuntu-20.04 2
wsl -l -v

Expected Behavior

Actual Behavior
WSL is not updated.
Diagnostic Logs
No response

Just to double-check before investigating further, have you followed the steps for upgrading to WSL 2 listed here? You may need the virtual machine optional component and the Linux kernel package update if you have not done so already


Issues with multi-line strings and comments in Lua

You can see some examples here http://lua-users.org/wiki/StringsTutorial
The way you currently check for multiline strings and comments won't allow for the nesting capability that lua has.

Partially fixed in #97


[BUG] Sample stats don't load when creating Take() stages from the App

On develop, I observe that creating a Take(10) stage from the App loads the view (10 random samples), but the sample stats in the Fields Sidebar are stuck in spinning-icon state. However, if I then do session.view = session.view, then everything loads appropriately.
So it seems randomized views can be loaded via session.view but not created via the App.

Resolved by #710


Remove production usage warning

As soon as we're confident it's ready.

Covered by 464f8bc60257d19d869d4bafb4c069795c6fef08.

:+1:


vellore repeated in tamilnadu covid tracker

vellore in tamilnadu is shown twice
VELLORE | 1
VELLORER | 1
remove the 2nd Vellore, which is having spelling mistake

@vasanth3045 Looks like they had to modify in the main source file. I informed @JunaidBabu to work on this

Did this get fixed?


Use Fetch metadata headers to detect content types properly

https://www.w3.org/TR/fetch-metadata/
Chrome already sends them.

core/pull-requests/1717


Clean up commented-out code

There's a lot of commented-out code originally from CL's bootengine.  We should go through it and either re-enable it, replace it with equivalent functionality, or explicitly decide that we don't want it.
https://github.com/coreos/ignition-dracut/issues/32 is a special case of this.

:+1: :+1: :+1: :+1:


Warning: TensorFlow library wasn't compiled to use SSE instructions

Installed nightly build using

pip3 install tensorflow-1.1.0rc0-cp35-cp35m-win_amd64.whl
on Windows 7 Professional x64.  Simple run gives warning that the libs were not compiled to use SSE, SSE2, SSE3, SSE4.1, SSE4.2 and AVX instructions even though available.

c:\python
Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

import tensorflow as tf
print( tf.version)
1.1.0-rc0
hello = tf.constant('Hello, TensorFlow!')
sess = tf.Session()
2017-03-30 15:20:06.126686: W c:\tf_jenkins\home\workspace\nightly-win\device\cpu\os\windows\tensorflow\core\platform\cpu_feature_
tions, but these are available on your machine and could speed up CPU computations.
<
print(sess.run(hello))
b'Hello, TensorFlow!'

Duplicate of #7778

This is not a bug.

import os
os.environ['TF_CPP_MIN_LOG_LEVEL']='2'
import tensorflow as tf
This will work fine without warning


To Reproduce

Switch to node 16 or 18
Run $ npm i decap-cms-app
The error occurs
Switch to node 14
Run $ npm i decap-cms-app
This time it works

Expected behavior
The install of decap-cms-app works
Applicable Versions:

Decap CMS version: 3.0.4
OS: Fedora 38
Node.JS version: 18.17.1, 16.17.1

Thanks for reporting this, it appears that peer dependencies have to be updated. Working on it.

Perfect, that works now. Thank you, @martinjagodic


If no commits for a user than show a message saying no commits found

This should just be a ng-show check against the user.commits.length and only show the message if the count is 0. The user profile code can be found /client/app/user/profile and you want to look at the profile.controller.js and the profile.html

Anli & Sumit are working on this

Kevin & Tae are working on this (Table 6)


US opportunistic sites need to be kept down in CERN agents

Impact of the bug
WMAgent
Describe the bug
With the production running activity going down, I noticed that T3_US_SDSC is actually enabled in the CERN agents:
cmst1@vocms0252:/data/srv/wmagent/current $ $manage execute-agent wmagent-resource-control --site-name=T3_US_SDSC -p
Executing wmagent-resource-control --site-name=T3_US_SDSC -p ...
Thresholds and current status for all sites:

T3_US_SDSC - 0 running, 350 pending, 2000 running slots total, 375 pending slots total, Site is Normal:
...

as we know, CERN schedds are not - yet - able to run payload in the US Opportunistic resources, e.g.:
T3_US_SDSC, T3_US_NERSC, T3_US_OSG, T3_US_TACC and T3_US_PSC (so far).
Which usually is not a big deal, because those sites are not mapped in the CRIC data-processing API:
http://cms-cric.cern.ch/api/cms/site/query/?json&preset=data-processing
so they don't even get inserted into the agent's resource-control.
However, I do see T3_US_SDSC being returned from that API, which means that there is a PNN defined for T3_US_SDSC, which makes it to be automatically inserted into the agent's local database.
How to reproduce it
add T3 sites in a CERN agent.
Expected behavior
We need to make sure CERN agents won't pick work for those sites, because otherwise, they will simply take up job slots and will never managed to run. The deployment script has this hook, so the change is super simple:
https://github.com/dmwm/WMCore/blob/master/deploy/deploy-wmagent.sh#L214
Additional context and error message
vocms0250, vocms0251 and vocms0252 configuration file have been changed and AgentStatusWatcher restarted.

@hufnagel is it expected to have a PNN defined in CRIC for T3_US_SDSC?

Probably related to T3_US_SDSC being right next to T2_US_UCSD and the latter having storage. Are you currently tying CERN resource control solely to the absence/presence of a mapped PNN? Not sure that's a good idea long term for multiple reasons. First, SDSC does have local storage access at UCSD. Secondly there might be similar T3 in Europe inside the Global Pool later. Also, the next HEPCloud T3 (Theta) will definitely have Rucio managed storage.
Can't we just add a black-list feature (i.e. don't add these sites to resource control) and configure this for the CERN agents? Or vice-versa a white list feature for the FNAL agents? Or do you want to avoid having differences in agent deployments/configurations?

Isn't this precisely what solves the issue of having to route jobs from CERN to FNAL schedds?
Not that it's a feature we wouldn't like to have, of course, but still, e.g. removing NERSC from CERN agents/schedds would solve the issue... And we would save further discussions on e.g. how many jobs to route, whether or not they should remain visible to the global pool, etc.

It alone doesn't solve the issue completely, since Unified overflow right now completely ignores the agents configured sites and overflows based on it's own internal list. But that's arguably also something that should be changed.

That being said, overflow isn't an immediate problem, since all these jobs still have some sites in their white list that are reachable by that agents/schedd. Directly assigned workflows OTOH might now.
Alan, is this actually a concern here, did the CERN agents pull work for the current HEPCloud workflow and now can't run it because they can't reach HEPCloud resources?

@hufnagel if you check the CRIC link above, you will see that:
PSN: T3_US_SDSC
PNN: T3_US_SDSC
so it looks like it has its own storage endpoint.

Are you currently tying CERN resource control solely to the absence/presence of a mapped PNN?

Yes, this is the script executed during the WMAgent deployment:
https://github.com/dmwm/WMCore/blob/master/bin/wmagent-resource-control#L99-L110
which is responsible for adding resources to the local agent database (as you can see, it relies on the data-processing API, which only returns entries that have a PSN <--> PNN mapping. This is what I've been planning to change to support any kind of PSN from the CRIC catalog (no matter whether there is a PNN or not).

Can't we just add a black-list feature (i.e. don't add these sites to resource control) and configure this for the CERN agents?

Yes, that's what we have in the agent configuration, see:
https://github.com/dmwm/WMCore/blob/master/etc/WMAgentConfig.py#L350
the only difference is that we actually add those resources to the database, even though they are always kept down/disabled.

I think we should remove the T3_US_SDSC PNN from CRIC since SDSC doesn't have it's own storage. There is a read rule for MINIAOD from the UCSD cache in it's SITECONF, but other than that everything is AAA (like the other sites). And even the MINIAOD is not really for production, but for (local) analysis.

I'll contact Stephan and ask him how to do this. Is there anything else for me to do here? Seems to me we have a plan for the rest, right?

Ok, I disabled the T3_US_SDSC PNN (on advice from Stephan, seems there is no way to remove a PNN from a site).
Alan, can you check if thar fixes the problem?

Ok, seems I can also remove the PNN, did that as well.

Hi @hufnagel , I just checked in vocms0252, and the site seems to appear  as Down in the schedd tight now: [1].  @amaltaro do we have a full list of opportunistic T3_US sites and in this situation do we still want to explicitly add them to [2].
[1]
cmst1@vocms0252:/data/srv/wmagent/current $ $manage execute-agent wmagent-resource-control --site-name=T3_US_SDSC -p
Executing wmagent-resource-control --site-name=T3_US_SDSC -p ...
Thresholds and current status for all sites:

T3_US_SDSC - 0 running, 0 pending, 2000 running slots total, 375 pending slots total, Site is Down:

[2]
https://github.com/dmwm/WMCore/blob/a09e2aefe700fb9b0d12b9f7089b21bde5a5bd62/etc/WMAgentConfig.py#L350

Todor, the list has been provided in the initial description:
T3_US_SDSC, T3_US_NERSC, T3_US_OSG, T3_US_TACC and T3_US_PSC (so far).
but I think Dirk is about to commission some other resources as well?

T3_US_OSG is no longer in the list (the only resources in it are accessible normally through the global pool now). The new site we are commissioning is T3_US_ANL, but we expect it'll take some time before we are ready to use it. You might as well include it in a list of HEPCloud resources already though.

About T3_US_SDSC, is the 'Down' status expected? In CRIC the site shows up as 'production', with no storage associated with it.
https://test-cmssst.web.cern.ch/cgi-bin/set/ProdStatus/T3_US_SDSC
also shows it as production enabled.


Allow BaseConcept as reference target for RootMappingRules

I changed the reference on RootMappingRuleto reference BaseConcept instead of INamedConcept.
The only place where the name was used was the class name for the generated template and in the editor. I replaced the editor with a isInstanceOf check and if its not a INamedConcept it show the presentation.
In the generator I did that same but not using the presentation but relying on the gencontext.unique name to generate a safe class name in map_RootTemplate.
If this pull request is merged #19 is obsolet because it fixes the same problem.

Created request in MPS tracker: https://youtrack.jetbrains.com/issue/MPS-27143


stream_settings: Fix bug save changes button show on screen width< 575px.

Added css for .hide class on screen width < 575px.

Fixes:
#24589

Screenshots and screen captures:
Before:
https://user-images.githubusercontent.com/64723994/222980970-94d4a8bc-a325-43a9-852f-b014dbc49591.mp4
After:

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

@Ddharmani3 please update the commit message to use proper sentences and would be better to explain how this change fixes the bug. See https://zulip.readthedocs.io/en/latest/contributing/commit-discipline.html#commit-messages for more details.

Merged after editing the commit to explain the situation a bit more clearly, thanks @Ddharmani3!


Prisma transactions are not working

Bug description
I am running this code:
await prisma.$transaction([
    prisma.$queryRaw`SELECT * FROM tankstelle`,
    prisma.$queryRaw`SELECT * FROM tankstelle`,
])

and the script is running continously without a response.
The logs are looking like this:
2023-12-22T13:36:39.424Z prisma:client  prisma.$queryRaw(SELECT * FROM tankstelle, [])
[1] 2023-12-22T13:36:39.425Z prisma:client  Prisma Client call:
[1] 2023-12-22T13:36:39.426Z prisma:client  prisma.$queryRaw({
[1]   query: "SELECT * FROM tankstelle",
[1]   parameters: {
[1]     values: "[]",
[1]     __prismaRawParameters__: true
[1]   }
[1] })
[1] 2023-12-22T13:36:39.426Z prisma:client  Generated request:
[1] 2023-12-22T13:36:39.426Z prisma:client  {
[1]   "action": "queryRaw",
[1]   "query": {
[1]     "arguments": {
[1]       "query": "SELECT * FROM tankstelle",
[1]       "parameters": "[]"
[1]     },
[1]     "selection": {}
[1]   }
[1] }
[1]
[1] 2023-12-22T13:36:39.426Z prisma:client  prisma.$queryRaw(SELECT * FROM tankstelle, [])
[1] 2023-12-22T13:36:39.426Z prisma:client  Prisma Client call:
[1] 2023-12-22T13:36:39.426Z prisma:client  prisma.$queryRaw({
[1]   query: "SELECT * FROM tankstelle",
[1]   parameters: {
[1]     values: "[]",
[1]     __prismaRawParameters__: true
[1]   }
[1] })
[1] 2023-12-22T13:36:39.426Z prisma:client  Generated request:
[1] 2023-12-22T13:36:39.426Z prisma:client  {
[1]   "action": "queryRaw",
[1]   "query": {
[1]     "arguments": {
[1]       "query": "SELECT * FROM tankstelle",
[1]       "parameters": "[]"
[1]     },
[1]     "selection": {}
[1]   }
[1] }
[1]
[1] 2023-12-22T13:36:39.427Z prisma:client:libraryEngine  requestBatch
[1] 2023-12-22T13:36:39.427Z prisma:client:libraryEngine  library already starting, this.libraryStarted: false
[1] 2023-12-22T13:36:39.877Z prisma:client:libraryEngine  library started
[1] 2023-12-22T13:36:40.067Z prisma:client:libraryEngine  library stopping
[1] 2023-12-22T13:36:40.067Z prisma:client:libraryEngine  library stopped

How to reproduce

install<EMAIL_ADDRESS>in NodeJS
set the env variable: DEBUG="prisma:*"
run the forementioned code prisma transaction

Expected behavior
To get back the response of the queries
Prisma information

generator client {
  provider = "prisma-client-js"
  engineType = "binary"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model tankstelle {
...
}

await prisma.$transaction([
    prisma.$queryRaw`SELECT * FROM tankstelle`,
    prisma.$queryRaw`SELECT * FROM tankstelle`,
])

Environment & setup

OS: macOS
Database: PostgreSQL (neon.tech)
Node.js version: 21.2.0

Prisma Version
^5.6.0

Hi @ali3nnn, how many entries are there in the tankstelle table? I'm not able to reproduce this issue.
Consider the following Prisma schema:
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgres"
  url      = env("DATABASE_URL")
}

model test {
  id   Int    @id
  name String
}

and the following TypeScript snippet:
import { PrismaClient } from '@prisma/client'

async function main() {
  const prisma = new PrismaClient()

  await prisma.test.deleteMany()

  await prisma.test.createMany({
    data: [
      { id: 1, name: 'A' },
      { id: 2, name: 'B' },
    ],
  })

  const result = await prisma.$transaction([
    prisma.$queryRaw`SELECT * FROM test`,
    prisma.$queryRaw`SELECT * FROM test`,
  ])

  console.log(result)
}

main()

The output is:
[
  [ { id: 1, name: 'A' }, { id: 2, name: 'B' } ],
  [ { id: 1, name: 'A' }, { id: 2, name: 'B' } ]
]

as one would expect, and it only takes a few milliseconds to resolve.
If the table you're querying in raw mode has several thousands entries, however, I'd expect it to take longer, giving the impression that the query is halted.
An even simpler test that you can try to verify the connection to Neon + see Prisma transactions running is:
  const result = await prisma.$transaction([
    prisma.$queryRaw`SELECT version()`,
    prisma.$queryRaw`SELECT version()`,
  ])

  console.log(result)

which should print something like
[
  [
    {
      version: 'PostgreSQL 15.5 on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit'
    }
  ],
  [
    {
      version: 'PostgreSQL 15.5 on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit'
    }
  ]
]

I'll be closing this issue for now, but please leave a comment in case anything else is unclear. Thanks!

Did you figure out what was wrong with your app @ali3nnn?


Connect two or more panels

Hello,
is posible connect two o more panels?
Thanks.

Hello,
Not at the moment.
The best way for now would be to launch 2 separate docker containers or npm processes.

Ok, Thanks.
Best Regards.

In fact it would not be possible for now because alarm topic prefix is not configurable.
@gfuentesv  Do you have any coding skills to try to make a PR ?
If not, I will try to have a look, but I don't know when I'll have some time to spend on it

Ok, i launch separate process, and the problem is alarm topic prefix.
i don't coding skills, sorry
The ideal would be to be able to configure the alarm topic prefix in the configuration file risco-mqtt.json.
Please, if you can give me any solution, let me know.
Thank you very much.

I change the panel_id, in the panel and in the configuration file, but this does not affect to alarm topic prefix.

I've produced a fix for you to test.
The js file is here: https://github.com/markxroberts/risco-mqtt-local-js/blob/main/risco-mqtt-local.js
You'll need to replace the same file in your file installation.  It usually lives in /app/dist/lib
You'll need to update your config.json to include (as a separate line, not part of the MQTT config):
"mqtt_alarm_topic": "your alarm topic",

If it works for you (I can't test as I only have one installation), then let me know and I'll open a pull request to he main library.

Hello, and thanks.
but
I can't find my file installation in /app/dist/lib.
I can't find /app/dist/lib
I installed the addon automatically.

It will be hiding somewhere in your setup so it might be worth looking elsewhere.  If you can’t find it you’ll need to wait for the pull request.  I’ll try to do that in the next day or two. @vanackej will then need to approve.

I can't find.
I wait for the pull request.
Thank you very much.

Hello,
I find other way to work, now i have connect 4 panels.
Run one VM HomeAssistan for each risco panel, with risco-bride and mosquitto broker addons,
in the main HomeAssistan config mosquitto broker for bridge all mosquitto broker of  other isntances, and config in each bride to remap topic.
Work fine, but mqtt discovery not work, the sensors have to add manually.
But I like test the markxroberts solution.
Thanks.


Threadx Modules call the same driver problem

if i creat A and B Modules need to call the same driver, Will there be a problem of resource competition.
and The compiled volume of AB,will there be two driven volumes.

I'm not a ThreadX developer but yes, drivers need to use Mutexes or Semaphores around hardware usage. The ThreadX samples have some examples of this. Here's one: https://github.com/azure-rtos/getting-started/blob/master/Renesas/RSK_RX65N_2MB/app/console.c
If you're using ThreadX modules then you should probably put device drivers in main application and use the application syscalls to call device functions.

Hi @HarbourXbr,
@mransom-campbell is correct.


Version packages independently

Similar to the feature that Lerna offers, is independent versioning something that you'd consider supporting?
When versioning modules only for the purpose of using them in the same monorepo they reside in, it totally makes sense to keep the versions in sync. However, when you consider publishing the packages to the general public and the implications of using meaningul semver, this strategy brings more complications than benefits.
A breaking change in one package (or my root version), shouldn't mean a major version bump in all the packages - not unless they really had a breaking change. My guess would be that you're using oao to manage an actual application's monorepo rather than building a set components which can each be published independently. There are many use cases, mine included, where you might want to do the latter, or both, and I'm not sure keeping versions in sync really makes sense in that context.
Cheers!

Some food for thought after reading some Lerna issues:
There's an issue at https://github.com/lerna/lerna/issues/961) which suggests to split publish and version commands. Having such functionality would mean that one could task developers or external packages to set appropriate versions in each package.json. These versions could be then used by the publish command to publish each package with "independent" version without overcomplicating things.
Does that sound better?

Still not tried lerna for my use case. I don't remember why im not using it, but there was something.
My use case. Im thinking for a long time to merge as many as possible of all of my 300 packages in one place, for lot of reasons.
Some are coupled, others not, some uses anothers because their are just libs. And most of them definitely cant be sync versioned.
Another important thing is that I rely on full automation: publishing+github releasing on ci, following conventional-commits (angular style, for years - started with standard-version, migrated to semantic-release and finally after creating dozen of tools and apps I end up with new-release+new-release github app) and need either separate changelogs or good looking releases page.

It's now possible to skip version bumps during publish (with the --no-bump flag). This goes in the line of what @maciej-gurban suggests: modify subpackage versions by manual means, or using other tools, and then run oao publish --no-bump to publish to the npm registry.
Just take into account that oao determines the packages to be published by looking and the git history and determining which ones have changed since the latest tag.
I guess this issue is now solved with the new approach — but feel free to reopen if needed.


Project needs help?

Hello to everyone.
First and foremost thank you for the hard work that has been done on this project. I've been using this in some projects and it's working very well.
Despite this, I made a PR a few weeks ago and didn't have feedback relative to that PR besides the PR that I've made, I saw some other PR and issues without much feedback, and because of this raised in my head that this project may need some external help to avoid the dead of this project.
So considering this @bxcodec and the rest of the team, which are the main ideas for this project? do you need help from the community? I would like to avoid seeing dozens of forks for this project and instead see this project growing up.
Cheers
P.S: This is not the typical ETA issue asking for deadlines for new features, this Is an open-source project, made by the community for community.

Hi @rubemlrm ,
Yes, I think most of the maintainers have full-time jobs. I am aware it's been lacking support recently.
Any help is appreciated.
I will gladly onboard new maintainers if anyone can commit to reviewing and doing releases.
Do you think you'll be able to do this? I don't have a proper way for onboarding, but I will seek your understanding of what I can do to help you onboard and be the maintainers.
Thanks

Hi @bxcodec
I can try help you guys with this project, it was like I was saying this is a project that I use in others projects.
Cheers

Hi @rubemlrm ,
I have invited you to be on of the maintainer team.
Let me know if you need anything to help you onboard.
Thakns