Change routing-mode and tunnel-protocol based on .Values.tunnel and .Values.routingMode

Fixes https://github.com/cilium/cilium/issues/27756

Marking this for needs-backport since the tunnel flag will be removed in v1.15 according to the upgrade docs

The way I see it, tunnel should only be taken into consideration if routingMode isn't set, wouldn't you agree?
What if someone sets tunnel and tunnelProtocol to different things? That would unnecessarily complicate things.
Since tunnel is deprecated, it should be ignored when (the new) routingMode and tunnelProtocol are set.
The only case in which tunnel should be honored is if it were already set and none of the new values were explicitly given. (This would only happen if you upgraded Cilium without reading the release notes or ignored the deprecation notice).

Also, the commit subject is overly long, thus causing checkpatch.pl to fail in CI. Could you shorten it a bit and instead put the details in the commit message description? Thanks

Will fix it tomorrow.

Interesting, so with the new validation, some of our CI is now failing. For example:
https://github.com/cilium/cilium/actions/runs/6084377949/job/16513347947?pr=27841
Error: Unable to install Cilium: execution error at (cilium/templates/cilium-configmap.yaml:82:6): routingMode and tunnel are mutually exclusive. Please set only one of them.

We might have to change the CI workflows before we can merge this PR.

Hi @gandro,
Yes, that one was easy to fix by removing --helm-set=tunnel=disabled from the install command.
https://github.com/cilium/cilium/actions/runs/6084377962/job/16513356982 is a bit trickier since I can't find where the tunnel value is coming from (assuming there is nothing wrong with the validation).

I'd say it's a bug in cilium-cli:
❯ cilium install --dry-run-helm-values --helm-set=routingMode=native
cluster:
  name: colima-docker
operator:
  replicas: 1
routingMode: native
serviceAccounts:
  cilium:
    name: cilium
  operator:
    name: cilium-operator
tunnel: vxlan

Note I'm passing routingMode but it still generates tunnel in the output. If I force --datapath-mode=native, it works as expected.
Do you want me to add the workaround to the worflows?

Here the datapath-mode is set to tunnel because we're running on Kind.
And this is still using the old syntax. It should set tunnelProtocol instead.

Up for discussion: Should we actually force routingMode=native in the test workflows if cilium-cli data-path autodetect feature uses tunnel under similar circumstances?

Up for discussion: Should we actually force routingMode=native in the test workflows if cilium-cli data-path autodetect feature uses tunnel under similar circumstances?

Thanks for looking into it. I think we want to fix the CLI first. Especially if we backport this to v1.14, it might cause frictions to CLI users.
Aslo note that commit https://github.com/cilium/cilium/pull/27841/commits/30f3cf67808e189f25a15414e12d7abcd9d9c8b8 is likely not working because we don't run CI workflow from forks for security reasons.
Maybe a way forward would be to merge your PR without the validation, backport it to v1.14, In separate PRs, we can then fix CLI and CI for main branches, and then introduce the validation once all the tooling and CI has caught up. What do you think?

Maybe a way forward would be to merge your PR without the validation, backport it to v1.14, In separate PRs, we can then fix CLI and CI for main branches, and then introduce the validation once all the tooling and CI has caught up. What do you think?

Seems reasonable, though I have no say on most of what's going to happen outside this PR. I'd gladly revert it to a CI-passing state so that it can be merged. Everything else would depend more on Cilium committers than on me. If you're ok with it, just let me know when I can create the 2nd PR to add the validation.
Shall we proceed?

Sounds like a plan! Yeah I'm happy to drive the CI fixes forward. If you want, you could of course also attempt a PR for the CLI against cilium/cilium-cli to remove it's use of the tunnel flag on v1.14 and newer, but I can also take that over.

@gandro anything else?

@gandro anything else?

No, this looks good to me know! Thanks again, let's wait for the other CODEOWNERs to review.

/test


Finds no TODOs in Rust source

With some Rust source where grep TODO -r . finds some TODOS, difftodo finds none.  I think this is because highlighter2 does not yet parse Rust?
Maybe the README should explain that behavior.  Possibly you could fall back to a plain grep without smart syntax?

Thanks for the bug report. This is a good point. Falling back to plain grep is probably a sensible default.


Does not compile with Idris 1.2.0

./Data/Mod.idr:75:16-30:
   |
75 | implementation Neg (Mod (S n)) where
   |                ~~~~~~~~~~~~~~~
Data.Mod.abs not a method of interface Neg

This has been fixed … well, there are other issues (see #12), but in idris-crypto has been updated for compatibility with Idris 1.2.


Generated docs display items annotated with @ignore

The deno soc website currently displays items annotated with @ignore in the JSDoc comments, which can lead to more confusing documentation.
Eg: https://doc.deno.land/https/raw.githubusercontent.com%2Fdyedgreen%2Fdeno-sqlite%2Frework_api%2Fmod.ts#PreparedQuery (the iterator protocol is implemented by the PreparedQuery class, but this is an internal detail which should not be relied upon by users of the api; hence it would be nice to be able to hide these methods in the generated documentation)
I’m not sure if this is an issue with the deno doc parser or with the html rendering done here, but I would guess that the @ignore directive is parsed out but then subsequently ignored 😅

Consider also masking/redacting blocks annotated with @private as well as @ignore.


Warning under DMCA

Hello, I was passing by and noticed that there is a file which is a copy-paste of async-queue with slightly different names and identical logic. The offending code can be seen below:
https://github.com/fnbrjs/fnbr.js/blob/7b83474a071d7a0edda07411311891f774242bd7/src/util/AsyncQueue.ts#L6-L50
Which is identical to the file of the aforementioned original source code.
Furthermore, this repository does not comply with the LICENSE requirements from sapphiredev/utilities, which async-queue inherits due to being part of it. This license in question is The MIT License, and can be seen here.
Under the MIT license, you have some conditions for the re-distribution of the work, which is to keep the license and copyright notice. However, none can be seen in this repository as of 7b83474a071d7a0edda07411311891f774242bd7, which is the last commit made to the moment of writing this issue.
You may resolve this issue by pasting a full copy of our aforementioned license and a copyright notice within the next 7 days. You can find a valid copyright notice below:
// MIT License | Copyright © `2020` `The Sapphire Community and its contributors`

As a side note, the original code is published under @sapphire/async-queue in npm, so you do not need to keep a copy of the software here.

Alright, I added the copyright notice you suggested.
https://github.com/fnbrjs/fnbr.js/blob/0f94e5988131a3c448870226a195ea87c998bf1e/src/util/AsyncQueue.ts#L1

Alright, I added the copyright notice you suggested.
https://github.com/fnbrjs/fnbr.js/blob/0f94e5988131a3c448870226a195ea87c998bf1e/src/util/AsyncQueue.ts#L1

Don't forget a copy of the license :)

You can create a THIRD_PARTY_LICENSES file and paste the license there. As long as it's distributed with the code it's fine, it doesn't have to be in the files licensed under it, it just makes re-distribution easier.
And yeah, you have to, it's the MIT license's first part of its only condition.
As a side note, is there a reason why you don't want to use the module from npm? It would save you some of the legal hassle.

Looks resolved in 029fb3f2df4f3cb7b5acc9b944246233d0a2b960, thank you :)

I added the full license now:
https://github.com/fnbrjs/fnbr.js/blob/20eb01a5d1cc23d8bfd54e84b32c3ec6c04230cc/src/util/AsyncQueue.ts#L1-L9
I'll probably use the module directly from npm at some point, for now I'll keep it this way.


[bug]: lncli --lnddir= doesn't fetch the rpclisten from lnd.conf

Background
lncli --lnddir= doesn't fetch the rpclisten from lnd.conf
Your environment

0.16.4-beta.rc1

Expected behaviour
lncli should read the lnd.conf file in the specified lnddir and use the rpclisten value for the rpcserver.
Actual behaviour
The default value of 10009 is used for rpcserver instead.
I think that the rpcserver option should be usable to override a value found in the lnd.conf file in the specified lnddir=, but it should not be required.
Right now I feel like rpcserver needs to be duplicately defined if you are using the --lnddir option with lncli.

Thanks for reporting @AndySchroder. Indeed --lnddir is currently only used to instruct lncli where the macaroon and tls cert paths are to be found, see https://github.com/lightningnetwork/lnd/blob/master/cmd/lncli/main.go#L302
For now you have to specify --rpcserver or other config params via the command line parameters. Feel free to convert this ticket into a feature request or otherwise you could also close this issue.

Okay, I changed the title to say feature instead of bug.

It's not always the case that lnd and lncli will run on the same machine, so rpclisten would be mislabeled if it's being used as the host for lncli to connect to. Perhaps a better solution is to add a profile to lncli that specifies the rpc server.
Something like this: lncli --rpcserver <lnd_rpc_host> --opt1 <opt1> --opt2 <opt2> ... profile add --name <profile_name>
Then, when you want to make a call using those options, you can do so using: lncli -p <profile_name> <command>


cmd/compile: regalloc spilling unecessarily before ops with constrained inputs

In  the s390x port we have quite a few ops that heavily constrain input registers. For example, STMG4 forces its inputs into R1, R2, R3 and R4. It does this because it requires consecutive registers and there is no other way (that I can think of) to get consecutive input registers using SSA rules. We have a similar problem with instructions that require an even-odd register pair. Other architectures also do something similar for LoweredMoves because it clobbers the input registers.
Unfortunately constraining the input registers can cause the register allocator problems. For example, in BenchmarkAppend:
at entry: R1=b R3=d R4=c

a = MOVDaddr <uintptr> {type.int} _ : R1 // forces b out of R1
b = LoadReg <*uint8> _ : R2
c = Copy <int> R4 : R3                   // forces d out of R3
d = LoadReg <int> _ : R4
_ = STMG4 <mem> _ a b c d _

b and d are spilled unnecessarily because we have unallocated registers available and could have re-arranged the inputs as:
b = Copy <*uint8> R1 : R2
a = MOVDaddr <uintptr> {type.int} : R1
_ = Copy <int> R3 : R5
c = Copy <int> R4 : R3
d = Copy <int> R5 : R4
_ = STMG4 <mem> _ a b c d _

I'm planning to take a look at the register allocator to see if I can fix this. I think both these cases are a little fiddly though. I'm not sure if there is a general solution to this problem... Perhaps copying evicted values to a new register when there are further uses close by?
In this particular case it would also help if the StoreReg ops were moved into this basic block (I noticed there are some TODOs to do this in the regalloc code). Currently the generated code ends up something like this:
for {
     // spill here
     if unlikely {
          // load spilled values
     }
}

I believe this is a dup of #16061.
It would be good to either:

Make the desired register portion of regalloc stronger so it handles these cases.
Maybe just make sure that s390x is triggering desired registers at all.
Implement "spill to register" instead of spill to stack.  That is required for #16061, where no amount of desired register information can help, because we desire 2 different values in the same register (two DIVs that both need their args in AX).

@mundaym @randall77 #16061 is now marked as fixed; can this issue be closed as well?

Ah yes, sorry, it can be closed. The fix for #16061 fixed this too. It would be nice to firm up the 'desired register' code for s390x but it isn't as important.
I'm not completely certain but it looks to me like the desired registers aren't triggered in this case because the Block containing the STMG instruction has a successor that is also a predecessor and has already been processed.
In other words B2's desired registers are  ignored if B1 is processed first and B1 is a successor of B2:
──> B1 ───> B2 ──>
    ^       │
    └───────┘

I'm not sure I understand your example and what exactly isn't working.  Which block is the STMG in?  B1 should get desired register information from B2.
Maybe we should discuss in a new bug.

Hmm, after studying the code again I think the comment above is wrong, my apologies. I'll see if I can put together a better bug report, but I think (I haven't fully verified this) the following is happening:

The desired register information is being dropped when it is propagated backwards through phis here and so it doesn't make it to the initial register allocation of the value.
The desired register information at the start of the block with the STMG in it (B2) is being overridden by the dynamically calculated values present in the previous block (B1) here.

(2) is what I was trying to talk about in my comment above, although (1) is probably the more important bit. 'Fixing' (2) would probably result in code similar to that generated by https://golang.org/cl/29732, albeit with values moved into their desired registers at the start of the block rather than just before they are clobbered.

This might have some bearing on the parameters-in-registers experiment, too.  I'll keep an eye out for unfortunate-looking register movement.


Update vmware-solution-default-route.md

Learn Build status updates of commit 68e2897:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

articles/route-server/vmware-solution-default-route.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

Learn Build status updates of commit 0021c14:
:warning: Validation status: warnings

File
Status
Preview URL
Details

articles/route-server/vmware-solution-default-route.md
:warning:Warning

Details

articles/route-server/vmware-solution-default-route.md

Line 15, Column 30: [Warning: file-not-found - See documentation] Invalid file link: 'concepts-network-design-considerations.md'.
Line 18, Column 3: [Warning: file-not-found - See documentation] Invalid file link: 'concepts-network-design-considerations.md'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Learn Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

@Court72 and @halkazwini - still looking for a review here. We have moved this content over to our AVS specific page. This page will have a brief intro and point to that page: https://learn.microsoft.com/en-us/azure/azure-vmware/concepts-network-design-considerations

#please-close


Introduce proper handling for static calls

Fixes #5

Hmm can we somehow address this with the existing MemberCallExpression after all, it is still a call to a member of a class, is it not? Not quite sure what the base in this case would be. Hmm

I think the current definition of our MemberCallExpression treating it as a call to a function which is a "member of an object" should not be changed to "member of a class". Otherwise one could argue that basically all calls are somehow member calls, as each method is the member of a class. In the end I would still handle static calls as normal CallExpressions, as it is done here, with the added benefit that we can distinguish static calls from non-static ones in the call resolver

I agree that the definition should not be changed. However, for example if you look at how Java reflect deals with static calls, it is still referring to the method/member of the class but then invoking this call with null instead of a reference to a particular object.
I am not sure if we ever build the functionality on the CPG to retrieve the matching MemberExpression for a MemberCallExpression, it was my original intent to do so. But by looking at the current MemberCallExpression class, we might be able to get rid of it all together and just have a CallExpression

Merging them all into CallExpression sounds like a good idea on the longer term


@AssistedInject.Factory  limitation

Why you add this limitation<EMAIL_ADDRESS>must be declared as a nested type." ?

@JakeWharton we have a case where moving a factory outside the class would be nice.
An assisted factory is used to create a presenter:
package some.feature

class SomePresenter @AssistedInject constructor(
    @Assisted override var view: SomeContract.View,
    ...
) : SomeContract.Presenter {

    ...

    @AssistedInject.Factory
    interface SomePresenterFactory {
        fun create(view: SomeContract.View): SomeContract.Presenter
    }
}

later the factory is used to create a presenter inside of a fragment:
import some.feature.SomePresenter.SomePresenterFactory

class SomeFragment @Inject constructor(
    presenterFactory: SomePresenterFactory
) : Fragment(...), SomeContract.View {

    private val presenter: SomeContract.Presenter by lazy {
        presenterFactory.create(this)
    }

    ...
}

So SomeFragment depends on an interface that is nested in SomePresenter which feels like a dependency on the implementation class which confuses people sometimes.
Not a big deal, just as said it would be nice to move the factory outside the class.
There is currently a way to make this but it requires having a bit of boilerplate:
interface SomePresenterFactory {
    fun create(view: SomeContract.View): SomeContract.Presenter
}

class SomePresenter @AssistedInject constructor(
    @Assisted override var view: SomeContract.View,
    ...
) : SomeContract.Presenter {

    ...

    @AssistedInject.Factory
    interface Factory : SomePresenterFactory
}

I understand that it can be hard to implement since the factory in our case returns not the class itself but its interface.
The only idea I currently have is to allow putting a factory interface inside of a base interface and generate a factory for every interface implementation, like this:
interface Presenter {
    ...

    @AssistedInject.Factory
    interface Factory {
        fun create(view: View): Presenter
    }
}


Issue with the Windows Installation

Good day, I'm more of a Python user never used GO but I read your readme where it you have    1. Windows users will need to use the windows-amd64 version
I did extract it and added it to the desktop but it is not working it will open the terminal for a few seconds and immediately close off. Is this and issue with the exe itself or just on my end because the latest current exe for windows does not work well for me anyway.

I'm having the same issue as well. Were you able to get it working?

no but I created my own discord bot that works and looks similar to andbobs your uncle its made entirely with python will be releasing it soon.

I think ill have to go that route as well. Will keep an eye out for your release. I'm a python guy so would be a blessing to get a python version. Thanks for updating me regardless.

A Python based bot which has style presets.  Quite straight forward to use as well:
https://github.com/CyberTimon/Stable-Diffusion-Discord-Bot


update the pull request url in index.js

reopened cuz i fucked up sumthin
this pr changes the api pull request link into the actual pull request link
this should theoretically work, i didn't test this at all cuz i don't use javascript

hmm what do this do

one sec lemme record a short vid

https://user-images.githubusercontent.com/85838311/218264258-672e3d85-491b-4611-983a-1f13959a0154.mp4
So lets say we someone opens the summary issue #80, and wants to click on the PR #76, "Add Sparrow Atlas Resizer & Funkin Rewritten" by GuglioIsStupid link. They will be redirected to the api version of the pull request, instead of being redirected to the page on github. I don't know if this was intended, so I made a pull request which changes it.


add method for user to disable header view hittest

Hi,
I add a temporary solution to disable header view response to the slide event.
which is also mentioned here: https://github.com/Jiar/SegementSlide/issues/15

reply here


[RFC] Transition to west

Required changes to transition to using west instead of the built-in version, which is removed by this series.
Feel free to push to my branch or comment on it.

Codecov Report

Merging #11307 into topic-west will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           topic-west   #11307   +/-   ##
===========================================
  Coverage       51.55%   51.55%
===========================================
  Files             216      216
  Lines           27665    27665
  Branches         6937     6937
===========================================
  Hits            14263    14263
  Misses          10653    10653
  Partials         2749     2749

Continue to review full report at Codecov.

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

@SebastianBoe @nashif @dbkinder  addressed your comments
@nashif we need to add pip3 install west to docker in order for this PR to work
@dbkinder @nashif @mbolivar we need to think about how to document releases, should we tag the manifest repo?

@dbkinder @nashif @mbolivar we need to think about how to document releases, should we tag the manifest repo?

We mostly have a plan for this as discussed in https://github.com/zephyrproject-rtos/west/issues/39#issuecomment-423629912. The short story is:

Tag every project (zephyr gets v1.14.0, hypothetical-other-thing gets v1.14.0, etc.)
Set the revisions for each project in the manifest file to v1.14.0; tag the commit that does that v1.14.0 as well

Then you can do west init --mr v1.14.0. But there is a problem: west itself will continue to be updated, which is not what we want, as the v1.14-compatible version of west should probably stay fixed.
We need to think this through; I've created https://github.com/zephyrproject-rtos/west/issues/106 for that.

@mbolivar I've addressed your comments
@dbkinder @mbolivar @nashif I've added a section on history and motivation behind west

@nashif can you please remove the cloning instructions from zephyrproject.org/developers/#downloads ?

done

@carlescufi : Was it the intention to merge this into topic-west branch? I thought the idea to merge it into master, to let (make) users use up to date west?

@pfalcon yes, we want to collect all required changes in topic-west first, then send an email to the mailing list and at the same time merge topic-west into master


fix #928 improve the allowSendingMsg performance

After applying this patch, I did a simple performance test.
For gearpump sol benchmark, I run 48 producers and 48 processors on 16 workers.

Version
Throughput
Latency

Without patch
11,000,000 msg/s
5ms

With the patch
14,000,000 msg/s
8ms

Also, this will improvement the performance of storm-over-gearpump.

@huafengw great job!

Update the pr according to Sean's advice.

Current coverage is 63.12%

Merging #929 into master will change coverage by +0.10% by 4ae64d7

Coverage Diff
@@            master    #929   diff @@
======================================
  Files          208     208
  Stmts         4430    4436     +6
  Branches         0       0
  Methods          0       0
======================================
+ Hit           2792    2800     +8
  Partial          0       0
+ Missed        1638    1636     -2

Uncovered Suggestions

+0.41% via ...ne/PipeLineDSL.scala#72...89
+0.34% via ...rt/QueryServer.scala#104...118
+0.34% via .../client/Client.scala#113...127
See 7 more...

Powered by Codecov

+1


Gossip Analysis (Network Partition)

Add functionality to the Gossip Analysis CLI which outputs a DAG showing which nodes are gossiping blocks.
Acceptance:

Allows the user to visually verify a network partition
Outputs an image for visual verification
Optionally outputs a JSON representation which can be processed by testing tools

Blocked pending #4816

Just output is still oustanding, moving to infra board

https://github.com/openmina/mina-network-debugger is the new solution


Handle exception double

Fixes https://github.com/apache/pulsar/pull/12744
Motivation
The exception here was handled twice, resulting in a null pointer exception.
And the position will be updated twice.
Modifications
Keep the exceptionally() part and convert the whenComplete() into thenAccept().
Verifying this change

[ ] Make sure that the change passes the CI checks.

(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (10MB)
Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API: (yes / no)
The schema: (yes / no / don't know)
The default values of configurations: (yes / no)
The wire protocol: (yes / no)
The rest endpoints: (yes / no)
The admin cli options: (yes / no)
Anything that affects deployment: (yes / no / don't know)

Documentation
Check the box below and label this PR (if you have committer privilege).
Need to update docs?

[x] no-need-doc

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

Good work @liangyepianzhou !


dnscrypt client is not working if original DNS server is non-recursive

The following function in "check-hijacking.sh" will never succeed if the original DNS server is working with non-recursive mode. That causes dnscrypt client in "standby" mode.
try_resolution() {
exec alarmer 5 dig +tries=2 +time=3 +short google-public-dns-a.google.com
| egrep '^8[.]8[.]8[.]8' > /dev/null 2>&1
}

wrong project?


https is redirected to http

see the following request/response:
HTTP/1.1 301 MOVED PERMANENTLY
Date: Wed, 04 Dec 2019 23:58:34 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 273
Connection: keep-alive
Server: openresty/<IP_ADDRESS>
Location: http://ui.adsabs.harvard.edu/abs/2015arXiv151106066W/abstract
X-RateLimit-Limit: 400
X-RateLimit-Remaining: 363
X-RateLimit-Reset:<PHONE_NUMBER>
Retry-After: 83221
Vary: Cookie
Set-Cookie: session-core=.eJwVzVtygjAAQNG95FsdglEefyggj_qgppX4wwAJGkCRJjTajntvXcC95xfkgzwD-xfkZcmEyGTXsCuwwUKEfMqILNv5bmmZH_3KVAdjVj1cRKeBkR4iHhvKC8EIFJ0EdpW3go0Au9_4F8v4a6Fr0BpDfazNsD61EbI1bQIRnCEDPEeg7LqGM_GixT_Mu1cyYZGitfTiU-2Q99Zss4v8xp5G6NIng3T8TuxNj-5ucA37vMN8eFBWpe4peEO-aPr7Kdn2Ze0pt4gvizfsoKQJeUg3iKfBZkl4sb3oY6-6Jo1Fi413nGdVgAl5oP5iXlcBnboUrwfruFNhDgv8mX43mtmr5Kc0nLr7CN2gl1srGw9fdy379I_7d90P5iW-yfXqJ-KyecQnhRMlU3MRUJK1mdK9ZJKycxgnk73p4LKO7gGUaeoQF63gXkQ3BqM1eD7_AAy6gYs.XehIKg.h5PKBSIirwOn0-Z-bRZIY8Bb6G0; HttpOnly; Path=/

the problem is likely on this line: https://github.com/adsabs/ADSCore/blob/c02ced2f3c0cb0795ac039233aa477fdb7bd6b4c/adscore/routes.py#L266
if it returns relative url, the server is already running on http; not sure if nginx needs to be told to turn that properly into https; also the links are relative

@marblestation please see this issue; currently it makes one of adsrex tests fail

This is closed by 768d28ea9f85dd8e612c9cbfed019dfe329a77a2


iotdk: couldn't flash image into iotdk board using west flash.

Describe the bug
Couldn't use west flash command to flash image into iotdk board.
To Reproduce
Steps to reproduce the behavior:

west build -b iotdk -p auto samples/hello_world/
west flash
see error

Logs and console output
-- west flash: using runner openocd
Open On-Chip Debugger 0.10.0+dev-01341-g580d06d9d-dirty (2020-06-25-12:07)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter
adapter assert |deassert [srst|trst [assert|deassert srst|trst]]
adapter deassert |assert [srst|trst [deassert|assert srst|trst]]
adapter usb
adapter usb location [-port[.port]...]
adapter_khz [khz]
adapter_name
adapter_nsrst_assert_width [milliseconds]
adapter_nsrst_delay [milliseconds]
interface driver_name
interface_list
reset_config [none|trst_only|srst_only|trst_and_srst]
[srst_pulls_trst|trst_pulls_srst|combined|separate]
[srst_gates_jtag|srst_nogate] [trst_push_pull|trst_open_drain]
[srst_push_pull|srst_open_drain]
[connect_deassert_srst|connect_assert_srst]
Error: invalid subcommand "driver ftdi"
zephyrproject/zephyr/boards/arc/iotdk/support/openocd.cfg:11: Error:
in procedure 'script'
at file "embedded:startup.tcl", line 26
at file "zephyrproject/zephyr/boards/arc/iotdk/support/openocd.cfg", line 11
FATAL ERROR: command exited with status 1: zephyr-sdk-0.11.4/sysroots/x86_64-pokysdk-linux/usr/bin/openocd -s zephyrproject/zephyr/boards/arc/iotdk/support -s  zephyr-sdk-0.11.4/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts -f zephyrproject/zephyr/boards/arc/iotdk/support/openocd.cfg -c init -c targets -c 'reset halt' -c 'load_image zephyrproject/zephyr/build/zephyr/zephyr.elf' -c 'resume 0x0000000020001354' -c shutdown
Environment (please complete the following information):

OS: fedora32
Toolchain: zephyr-sdk-0.11.4
Commit ID: ae35d3000f

@abrodkin  @ruuddw fyi

Update SDK to v0.12.0 which was finally released yesterday: https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.12.0.

it was passed with sdk 0.12.0, closed this.


u32 converters may have an issue.

On Fri, Mar 24, 2023 at 2:50 AM lcineyes @.***> wrote:

[image: image]
https://user-images.githubusercontent.com/30033031/227486620-ebfe82b9-e4ac-49d4-914c-38681c081349.png
[image: image]
https://user-images.githubusercontent.com/30033031/227486796-3ee95dda-ba2d-4fea-9982-3903e19aa4ea.png
[image: image]
https://user-images.githubusercontent.com/30033031/227486993-63852fef-257d-4a02-8b4f-0a658133a0c6.png
—
Reply to this email directly, view it on GitHub
https://github.com/nix-rust/nix/issues/2015, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA7VOOVVZAG2Y7GINMX3ATW5VU6FANCNFSM6AAAAAAWGKRB6Q
.
You are receiving this because you are subscribed to this thread.

This is not nearly enough information for a bug report, in Nix or in any
other project.  If you think you've found a bug, you need to clearly
explain it.  Explain what you did, what you expected to happen, and what
actually happened.  Be as specific as possible.  Include error messages and
code snippets if applicable.  And do it all with text, not images, unless
the bug is somehow graphical in nature.

Message ID: @.***>

Closing for lack of feedback.


HBASE-24843 Sort the constants in hbase_constants.rb

Addresses comment from #2215

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 30s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

_ Patch Compile Tests _

+1 :green_heart:
rubocop
0m  6s
There were no new rubocop issues.

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

_ Patch Compile Tests _

+1 :green_heart:
rubocop
0m  5s
There were no new rubocop issues.

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.


add statement on UGent deposit and access policy to full text page

Describe the improvement
During the "add publication" workflow, in step 3 "Add full text", a text should be added to mention the deposit and access policy of UGent (see below).
Can this text be added above the drag and drop area?
"Upload full text to comply with Ghent University's deposit and access policy for publications. By depositing the full text, you enable UGent to preserve this file and agree to make it available in accordance with the access level and license specified in the full text details."

The above text is added correctly. Can you also add the link to the policy document?
https://www.ugent.be/intranet/en/research/publications.htm#Immediatedeposit/optionalopenaccessmandate


IsPlatformSupported performed 3 times for Editor and Player seperately

Describe the bug
3 classes distinguish between Editor and Runtime for the way they check platform support.
It's easier and less error prone to move that into a merged check.

Fixed via #7748


Does MSInlet belong in ixdat?

Getting a calibration factor in [A]/[mol/s] = [C/mol] out of an experiment where a gas of known composition is flowed over a mass spec inlet requires a function for calculating the molar flux of analyte molecules through the inlet as a function of the gas composition, pressure, and temperature.
Right now ixdat has a MSInlet object which has that function in its calc_n_dot_0 method. The equation used is for a Spectro Inlets (SI) chip. However, the SI chip is described authoritatively in the spectro_inlets_quantification (siq) package which has a Chip object with a method of the same name. The siq version is more powerful as it, for example, computes the viscosity of gas mixtures.
My thinking is that the code representation of the SI chip should live in siq, because the chip is made by SI. But this opens the question, where do gas flux calibration methods go?
Confusingly, ixdat at present has two methods that do the same thing, MSInlet.gas_flux_calibration which uses ixdat native stuff and MSMeasurement.gas_flux_calibration which uses siq stuff. That is not intuitive at all. This behaviour is demo'd here.
Reflecting that we know the present state is a mess, MSInlet is now deprecated. But how to replace it is not clear.
I can think of the following options:

ixdat has no native gas flux calibration. Existing gas flux calibration measurements are moved to siq.
ixdat has gas flux calibrations as methods of MSMeasurement but require siq as a plugin (as MSMeasurement.gas_flux_calibration, etc do now)*. The method returns an object defined in the plugin package.
ixdat has gas flux calibrations as methods of MSMeasurement which return the native MSCalResult object but require an MSInlet from an external package. Then ixdat needs to make a requirement on the interface with this MSInlet**
ixdat has (as now) a native MSInlet which defaults to the one we know

*What to do when/if other MS quantification plugins become available is a problem for then.
**i.e. any MSInlet has to have a calc_n_dot method which takes some specific set of arguments and returns a float in mol/s.
Maybe it would be best for now to just delete the calibration methods in MSInlet and have the calibration methods in MSMeasurement behave differently based on whether siq is active, like ECMSMeasurement.ecms_calibration etc already do?
And I think ixdat.plugins.si_quant (maybe should be renamed ixdat.plugins.siq?) should have methods that convert between ixdat.techniques.ms.MSCalResult and spectro_inlets_quantification.calibration.CalPoint , etc.

I think I better understand the problem now and I think my previous comments on the matter were a little confusing.
First of, we can totally agree that having similarly named methods on different objects perform similar actions is not the way to go. However, I don't see the need to loose ixdat's internal methods for quantification, as it has some merit that you can get started without dealing with an external dependecy.
What I would suggest is the MSMeasurement simple has one method per quantification route and the name prefix to indicate the souce, like gas_flux_calibration_native and gas_flux_calibration_siq. The latter will of course depend on the plugin. This approach also means that you can convert the resulting siq calibrations to ixdat calibrations, avoiding that whole mess. And since there are now two methods, there will be no confusiong about taking different arguments, like of e.g. the siq one will take a chip name/id or alternatively chip kana dimensions.

I agree with @KennethNielsen that having an internal method for quantification is good.
One major advantage of using IXDAT for thermal / photo microreactor-MS is the quantification part.
I might be missing the point but missing the internal quantification part of IXDAT would make the package less usefull.
Having to rely on an external package to begin using quantification in IXDAT seems like an unnessecary obstacle.
However, I did not use the si_quant package that much so I might be missing the point of this post and how much impact removing MSInlet will have.

Thanks for the comments here and discussions elsewhere about this!
We'll do as @KennethNielsen suggests, moving the native MS calibration functions over to MSMeasurement and giving the siq one a different name. MSInlet will stay. PR coming soon.
Duplication of molecule data between ixdat and siq was a related issue. @KennethNielsen suggested the possibility that both siq and ixdat rely on a common separate package for it. Such a package could make optional use of NistChemPy


issue/SITES-2854 I reduced the margin-right size of icon

https://jira.corp.adobe.com/browse/SITES-2854

@sandru85 I can merge this PR? This is the fix for SITES-2854 on open source coral-spectrum

@Pareesh can you please review?
@RazvanPRA let's wait for a review from the dedicated team


Minor spelling errors in the documentation

Hi @naokazuterada
I found some minor spelling errors.
I find the documentation a bit sparse, would you mind if I gave it a shot and wrote some more documentation. I use MarkdownTOC heavily on several projects at work, writing specifications etc, so perhaps I can be regarded as a super-user.
Please see an example like:
https://github.com/DK-Hostmaster/epp-service-specification/blob/master/README.md
Well anyway it is just an offer - you are free to take it or leave it. Keep up the good work and thanks for a marvellous plugin, you make much of my work so much easier.
jonasbn

This change is

Hello @jonasbn, and thank you again!
I'm so grad to know that this plugin helps you and receive your kind offer! I also used it for work In the beginning, but to be honest, I don't use it so heavily currently. And I also think about rewrite README nicer.  So I just added you to 'collaborators' of this project now.
I'm expecting your contributions in the future.


Bugfix manifest set

Specifically, StateWriter is an interface, which means it needs a wrapper
struct, and the command itself took the bare interface rather than the graph
package wrapper. Regression test added to cli_test.go and fix made.
Additionally, I realized while testing this that the output for sous {manifest,metadata} {set,get} was incredibly obtuse. This improves on that as
well.

Current coverage is 59.80% (diff: 78.94%)

Merging #243 into master will increase coverage by 0.06%

@@             master       #243   diff @@
==========================================
  Files           136        136
  Lines          6973       6984    +11
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           4166       4177    +11
  Misses         2443       2443
  Partials        364        364

Powered by Codecov. Last update 971300c...04f95c2


NPM package and TypeScript typings for JSDO 4.3.1

Any chance to merge this? Would be very helpful for Angular2+ projects.

NPM package support for the JSDO was added in 4.4.1.
Develop branch includes support for NPM packages and typings.
Thank you.


Fix huggingface authorization when using tools/llama/generate.py

Add a parameter to tools/llama/generate.py to provide huggingface token for pretrained model downloading.
This pr adds a --hf-token parameter to tools/llama/generate.py, thus the user can pass their access tokens generated on https://huggingface.co/settings/tokens to download pretrained models.
Without this fix, AutoTokenizer.from_pretrained(...) will raise a requests.exceptions.HTTPError: 401 Client Error.

Since we host the models on the huggingface, it's not possible to add arguments for all downloads that requires auth. Use huggingface-cli login should be a better solution.

Okay I understand that, fair enough.
but I am still thinking that adding a global configuration value (like token) to avoid the installation of huggingface-cli would be a neat choice ;)
Anyway thanks for your explanation!