Debug New Motion

This PR is intended to debug the error of ArbitraryAction motion when testing in oneAPI.
I don't want to fill #442 with (more) unnecessary commits, so I'll upload them here and delete the PR when I find the error.

I am not able to reproduce the error, as it does not appear when I try to isolate it. I will try again, but, for the moment, I merge this branch into #442 in order to have, at least, a temporary solution for this.

The CI jobs here have killed our oneAPI CI server multiple times, consuming over 20GB of shared memory, so I'm temporarily disabling the JuliaGPU Buildkite integration KomaMRI.jl.

I think I am able to re-enable it myself. Thank you!
Talking with @pvillacorta, it seems that debugging this locally would be hard, as it appears that we encountered an issue with oneAPI.jl. This seems to be a problem with max/min like the one we had on Metal.jl  https://github.com/JuliaGPU/GPUCompiler.jl/pull/602/files#diff-52d57b551d62b4dc18df904b53dfbbf149404dd5f9e748b0f417364f5d32966f. On oneAPI.jl the symptoms are different, instead of being wrong all the time like for Metal.jl, the operation on oneAPI.jl sometimes gives incorrect results (approx 2/10 times).
function _unit_time(t::AbstractArray{T}, ts::TimeRange{T}) where {T<:Real}
    if ts.t_start == ts.t_end
        return (t .>= ts.t_start) .* oneunit(T)
    else
        # Metal.jl: Separating the min/max statements fixes the problem for now
        # until https://github.com/JuliaGPU/GPUCompiler.jl/pull/602/files#diff-52d57b551d62b4dc18df904b53dfbbf149404dd5f9e748b0f417364f5d32966f
        tmp = max.((t .- ts.t_start) ./ (ts.t_end - ts.t_start), zero(T))
        # oneAPI.jl: The problem was fixed by adding an additional instruction here
        # _ = sum(t)
        # Could this be a GPUCompiler.jl problem?
        return min.(tmp, oneunit(T))
    end
end

Pablo hasn't completely identified/isolated the problem, as he tells me that it is a little bit random when it happens, so he hasn't filed an issue.
@maleadt Do you think using ifelse instead of min/max could be better? Would you happen to have any recommendations for what to do?
Thank you very much for all your help!

@maleadt, I want to apologize for the inconvenience I've caused with my recent commits. It was never my intention to overload the server or create issues in the CI environment. I’m working on debugging this issue as best as I can, but I’ve encountered some challenges, as @cncastillo mentioned.
I understand the importance of being more mindful of shared resources and I’m committed to changing my approach to ensure that I don’t cause further disruptions. I would greatly appreciate any advice or guidance on how I could handle this situation more effectively. Once again, I’m very sorry for what happened and I’m eager to collaborate on resolving this in the best possible way.
Thank you for your understanding and help.

debugging this locally would be hard, as it appears that we encountered an issue with oneAPI.jl.

Is the issue that you don't have the hardware? Many Intel CPUs come with an oneAPI-compatible IGP.

On oneAPI.jl the symptoms are different, instead of being wrong all the time like for Metal.jl, the operation on oneAPI.jl sometimes gives incorrect results (approx 2/10 times).

The function you quote there doesn't look like a kernel issue, so it's probably different. If this ends up dispatching to MKL, this may be https://github.com/JuliaGPU/oneAPI.jl/issues/445; try setting the environment variable mentioned in that issue.

Do you think using ifelse instead of min/max could be better?

If this is a kernel function (which it doesn't look like), using ifelse reduces branching which may help.

From c71fee8, we can notice how tests fail even using KernelAbstractions.synchronize after calculating the time array:
const AdjointOneArray{T, N, M} = LinearAlgebra.Adjoint{T, oneArray{T, N, M}} where {T, N, M}
## Extend KomaMRIBase.unit_time (until bug with oneAPI is solved)
function KomaMRIBase.unit_time(t::AdjointOneArray{T, N, M}, ts::KomaMRIBase.TimeRange{T}) where {T, N, M}
    if ts.t_start == ts.t_end
        return (t .>= ts.t_start) .* oneunit(T)
    else
        tmp = max.((t .- ts.t_start) ./ (ts.t_end - ts.t_start), zero(T))
        t = min.(tmp, oneunit(T))
        KA.synchronize(KA.get_backend(t))
        return t
    end
end

What I thought would solve the problem every time, was to use a somewhat heavier operation that would make use of the calculated variable t, such as a sum function (see https://github.com/JuliaHealth/KomaMRI.jl/commit/97048f063f3d89ad2969e497511349123199d83f). The tests now pass 8/8 times, but it may be a coincidence:
## Extend KomaMRIBase.unit_time (until bug with oneAPI is solved)
function KomaMRIBase.unit_time(t::AdjointOneArray{T, N, M}, ts::KomaMRIBase.TimeRange{T}) where {T<:Real, N, M}
    if ts.t_start == ts.t_end
        return (t .>= ts.t_start) .* oneunit(T)
    else
        tmp = max.((t .- ts.t_start) ./ (ts.t_end - ts.t_start), zero(T))
        t = min.(tmp, oneunit(T))
        _ = sum(t) # Dummy sum
    end
end

As I thought that this sum could be a good temporary solution (until I could find the source of the problem), I included it in branch #442 (commit 51c71cc), but the test failed again for oneAPI.
So I started to think that this function unit_time was not the source of the problem, and I tried to isolate and reproduce the problem (commits 3e5b845 in advance) including also Interpolations.jl, to see if it was something related with this package. I did not get it, by the way, as all tests were passing now.

debugging this locally would be hard, as it appears that we encountered an issue with oneAPI.jl.

Is the issue that you don't have the hardware? Many Intel CPUs come with an oneAPI-compatible IGP.

On oneAPI.jl the symptoms are different, instead of being wrong all the time like for Metal.jl, the operation on oneAPI.jl sometimes gives incorrect results (approx 2/10 times).

The function you quote there doesn't look like a kernel issue, so it's probably different. If this ends up dispatching to MKL, this may be JuliaGPU/oneAPI.jl#445; try setting the environment variable mentioned in that issue.

Do you think using ifelse instead of min/max could be better?

If this is a kernel function (which it doesn't look like), using ifelse reduces branching which may help.

Just saw this message, I will check it and let you know.
Thank you!


chore: update CHANGELOG

Ping @EliseChouleur since I think there was an interest in a new version and it's there now: https://crates.io/crates/cryptoki thanks to our great @hug-dev :smiling_face_with_tear:


remove no longer needed dependencies

This PR cleans up the dependencies and remove the following, which are nowhere used:

btoa
bunyan-sentry-stream
raven
socket.io
valid-url

Coverage remained the same at 95.098% when pulling aa8eac0200ce083b3f68f02a4a0a85c39f71ff2a on Shegox:remove-deps into 0701447c47bfd259d13d77f9996ef620cd2e3ae7 on cla-assistant:master.


how to print each interface's IP

I can print the name,
how to print the IP ?
FFI::PCap.each_device{|x|
	p x.name
}

thanks

Maybe p x.net will work.

I find it from pcap.rb  :
FFI::PCap.lookupnet(x.name)


bug(windows client): Welcome screen appearing after upgrading with a new MSI

Describe the bug
The Welcome screen is showing up when it shouldn't.
To Reproduce
Install a slightly old version, sign in, then install a newer version.
Expected behavior
Expect:

Welcome screen should not appear at all since I was signed in before the update
Welcome screen should not appear simply because I updated the Client

Screenshots / Logs
Platform (please complete the following information)

Component (i.e. macOS client / Linux client / Gateway / Admin portal): Client
Firezone Version (e.g. 1.0.0 or N/A): The new version was e3b150c. The old one was probably just the tip of main this morning.
OS and version: (e.g. Ubuntu 22.04 or N/A): Windows 11
Deployment method: (e.g. Docker / Systemd / App Store or N/A): MSIs from CI/CD

Additional context

Trying to reproduce:

On e3b150c, signed in
Quit and restart the app
It signs in again, good
stat ~/AppData/Local/dev.firezone.client/data/ran_before.txt shows mtime of 23:31 UTC
Download a new MSI from here https://github.com/firezone/firezone/actions/runs/8383072668#artifacts
Quit Firezone, install the new MSI, restart Firezone
It signs in to 47e5c84 just fine

Weird.

Restart 47e5c84, still signed in
Sign out and quit
Restart, it doesn't show the Welcome screen

I know what happened. I probably deleted the ran_before.txt file while testing something else, I was trying to delete wintun.dll and needed the whole folder gone.
Won't fix, not the software's fault.


Applied Counter to compare special VLANs collections

Closes #506
Summary
Applied a Counter to all types of tags and compare available tags with restricted tag collection
Local Tests
Replicated issue case
End-to-End Tests
N/A

It can also be changed to set(), just for the comparison.


Different URL for editionView for data fetch and update

When we enter editionView data is first fetched from url and then displayed and allowed to make changes and on submit is updated. But in my api I have different url for fetching and updating data. On setting custom url to editionVew(), one of them has to fail this way as they both uses same url instead of different ones. So can we make data fetch using url from showView instead or setting another url for show?

Did you try to use a custom Restangular interceptor to handle you case ?
You could "require" PUT call for your resource inside the interceptor to make a call to the correct URL

But the problem i think is with fetching of data. Editionview tries to fetch data using same url as it uses for put request. Although this seems ideal case but is not always true. Sometimes different endpoints might exist for both requests. If i override API calls in interceptor it would me to check all GET (not PUT) requests and to correct them. A better solution will be if EditionView have two urls, one for get and other for put (as EditionView always fetch before update). Or other approach might be to use url from showView for GET request.

Can you configure this server side?
I looked a bit more into your use case and think its far easier to have the server redirect your request wherever it may have to go.
For instance, if you perform your search (GET) on an indexed server (ElasticSearch or other), but do the edit (PUT), create (POST), delete (DELETE) directly on the source DB server, then still target all your request (GET, POST, PUT, DELETE) to the same URL, and have this URL redirect the call.
This can be done in Java, or directly using nginx

Hello,
As explained in the README, the GitHub issue tracker is for bugs and enhancement requests.
So I close this issue, but feel free to write a question on StackOverflow with the tag ng-admin.
Thanks for using ng-admin!


[Transaction Pool] - Duplicate zkapp cmd nonce fee payers are not removed

Preliminary Checks

[X] This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/MinaProtocol/mina/issues
[X] This issue is not a question, feature request, RFC, or anything other than a bug report. Please post those things in GitHub Discussions: https://github.com/MinaProtocol/mina/discussions

Description
The transaction pool has logic to remove zkapp commands that are submitted that have duplicate nonce values from the same fee payer. Say we construct the following zkapp commands:

Fee Payer Keypair, with nonce value of 0 and fee of 10_000_000_000
Fee Payer Keypair, with nonce value of 0 and fee of 20_000_000_000

If we submit these zkapp commands into the transaction pool, we would expect the first to be removed and the second to be the one that is left. This is not the case however, if the second fee payer as a fee equal to or greater than the previous zkapp command, the transaction pool contains the two zkapp commands. IF the fee is lower than the previous zkapp cmd, then the second one is removed (which makes sense).
So in the case where the fee is greater with the same nonce, the first should be replaced but instead both are kept in the transaction pool.is
Steps to Reproduce
I have created a branch that can reproduce this behaviour.
See the following link here: https://github.com/MinaProtocol/mina/pull/12383/files#diff-163dbe21d215ac37560cd6328ade1c05a5e607d13164e12a5f6de07a73dc37cbR2639
To reproduce:

Check out to reproduce/transaction-pool-nonce-zkapp
Run the transaction pool tests -- ./scripts/testone.sh src/lib/network_pool/transaction_pool.ml
View results

Expected Result
The expected result should be that only the second submitted zkapp command should be in the transaction pool
Actual Result
The returned result shows that both submitted zkapp commands are in the transaction pool, and the test fails.
How frequently do you see this issue?
Always
What is the impact of this issue on your ability to run a node?
Medium
Status
NA

Additional information
No response

Note: this happens for regular payments too, not just zkapp commands

Note: This only happens if you add these commands at the same time in the same diff

I suspect, but am not 100% sure yet, that there is a similar error happening here that we saw with the verification key bits. There is something that is "read" at a state at the beginning of diff application that doesn't update as the diff is being applied.
However, rather than continuing to dig and adding logic to support this -- further complicating the transaction-pool and/or indexed-pool, can we instead just pre-process the diffs to pick the largest fee for duplicate transactions (of the same nonce)?

Latest information on this:

Make sure you start from Martin's repro and reduce from there. Be 100% sure you're still reproducing the bug as you move forwards. I lost some time going down a wrong path by not being careful of this. It could be the case that actually this only happens with zkapp commands and not payments, but not 100% sure
We do want to dig into the logic for the txn pool -- and specifically it's important that this happens in the apply function since we want to make sure the world doesn't shift from underneath us as we're processing data. I recommend building the solution on top of https://github.com/MinaProtocol/mina/pull/12380 as there are several changes to the txn pool there.
In addition to fixing this failing test directly, it's also important to fix the way we handle stacked nonces from the same fee-payer; right now Nathan claims the transactions being sent around are bundled into a hashmap and the order sorted by nonce is forgotten. We should modify the keys of the table to include the nonce in them so we don't forget that order (so something like account_id of fee-payer * nonce as the key)


Ansible request for

Please put the name of the software product (and affected platforms if relevant) in the title of this issue
Delete as appropriate from this list:

Missing install
Bug in ansible playbook
Request for new playbook addition

Details:

is this a wrongly created issue? you can edit original description with detail requests or can close it if nothing is needed.


Config for default generate path

Bug Report or Feature Request (mark with an x)
- [ ] bug report -> please search issues before submitting
- [ X ] feature request

Desired functionality

ng g m dashboard
ng g c myComponent --module=dashboard
It would be nice if there was a setting in angular.json for when generating anything there could be a prefix path.. in the example about I would like to have the component generated in the "components" folder in the dashboardModule
if the command is executed from the root and no module is given, user should be prompted with available modules

Hi @mackelito, thanks for this feature request. This currently out of the scope of the Angular CLI. You can create/extend the schematics to achieve the above mentioned behaviour.
Let's revisit this in the future, if we see a bigger demand for this feature.
Thanks.


Apply the 'classycle' plugin consistently to all projects

Existing cycles are now explicitly excluded in the corresponding build scripts and are thus more visible. They may or may not be improved on when working on the corresponding project.
Whether or not we want to keep this check in the future, or want to replaces with a different tool, is another question. This PR is only to have a more consistent build setup, where all quality checks are applied by default and exceptions are more clearly visible.

As a thought for the future, we could switch to using archunit for detecting the cycles: https://www.archunit.org/userguide/html/000_Index.html#_cycle_checks
I think the errors would be much better.

Have we tracked those exclusions somewhere else before? Or do we need to exclude them now given it's the first time we apply the plugin? I think I'm missing some context given we seem to exclude a lot of classes from those checks in the core plugins (are those acceptable exclusions or did we just exclude everything to make the check a noop?)

Sorry, I should have given a better explanation of what I did.
This cycle check was added quite arbitrary to projects (or not). So what I did was:

Enable it for all projects since we do not have any criteria for using or not using the check in a project. Then there were some projects with cycles (there were also some without cycles which did not have the check before).
For those projects who had one or two cycles, I explicitly excluded internal packages. Having a cycle between a public and a corresponding internal package is a common pattern it seems which we accept.
Some of the core projects have cycles all over. There I just excluded everything (effectively deactivating the check) as the goal of this PR is not to analyze the situation in these projects, but just to bring this part of our build into a consistent state.

We do not track any information about this topic somewhere else as far as I know.


Update buildspecs_interface.rst

Changed the documentation to reflect the change to the buildtest buildspec edit-test command. The alias for the buildspec command that allowed you to edit tests based on a supplied test name has been changed from buildtest buildspec edit to buildtest buildspec edit-test.  This was done in order to better match with the buildtest buildspec edit-file.

@JeffreyFG thanks for your contribution. I presume you are going to make the change to codebase first before updating the docs. Can you please make the changes in this same PR.

@JeffreyFG thanks for your contribution. I presume you are going to make the change to codebase first before updating the docs. Can you please make the changes in this same PR.

I have made changes to the code base but i had questions on the proper etiquette for pushing those change so i haven't done so yet

@JeffreyFG this looks great! Thanks for your contribution to buildtest.


:GoMetaLinter does Not call 'go vet'

even if add to .vimrc:
let g:go_metalinter_enabled = ['vet','golint', 'errcheck']

what is the output of explicit invocation of ":GoVet" on your go file? does it pass or does it report any errors?

Please open this issue to https://github.com/fatih/vim-go. This repo is only about the tutorial. Thanks.


Async unary client

Fledging support for the Async unary client.
This is a line-by-line translation of the Lwt client.
We believe we've fixed a hang-forever bug that was ported over from the Lwt side. Basically, if the server returns an empty response it doesn't send trailers, so the request never becomes determined. We haven't evaluated if this affects the Lwt client.

Thank you for the contribution!
One question about the fix you've mentioned. According to the docs

For responses end-of-stream is indicated by the presence of the END_STREAM flag on the last received HEADERS frame that carries Trailers.

I understand what you described is a special case. Is it documented anywhere? Or should the headers be treated as both headers and trailers at the same time according to the spec?
I must say I'm finding the grpc spec lacking but maybe I haven't found the right source yet.

the wonders of grpc APIs... We've also experienced various oddities. It feels very brittle for an emerging (but already X years old) lang agnostic rpc standard.
Are you willing to contribute an impl for streaming use cases, too?

We'll likely tackle the streaming interface in the near future, not quite there yet. I wouldn't necessarily want to block this PR on adding that though.

Okay we needed streaming clients sooner than I expected. Pushed streaming client implementations as well.

Thanks @mbacarella


Issues with peer dependencies found

Environment

Operating System: Darwin
Node Version:     v18.15.0
Nuxt Version:     3.3.3
Nitro Version:    2.3.2
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      -
Runtime Modules:  -
Build Modules:    -

Reproduction
https://stackblitz.com/github/nuxt/starter/tree/v3-stackblitz?file=README.md
Describe the bug
There's a warning after installing @nuxtjs/i18n:
 WARN  Issues with peer dependencies found
.
└─┬ @nuxtjs/i18n 8.0.0-beta.10
  ├─┬ vue-i18n 9.3.0-beta.16
  │ └── ✕ missing peer<EMAIL_ADDRESS>  └─┬ vue-i18n-routing 0.12.2
    ├── ✕ missing peer<EMAIL_ADDRESS>|| ^2.7.0 || ^3.2.0"
    └─┬ @intlify/vue-router-bridge 0.8.0
      └─┬ vue-demi 0.13.11
        └── ✕ missing peer<EMAIL_ADDRESS>|| ^2.6.0"
Peer dependencies that should be installed:
<EMAIL_ADDRESS><4.0.0"

I installed Nuxt by using the method at https://nuxt.com/docs/getting-started/installation
Additional context
No response
Logs
No response

Hi, thanks for opening an issue on this repository.
This is a minor thing in Nuxt often faced with pnpm. Usually installing latest version with refreshed lock-files can help, or you can also add vue if you really want. Please see https://github.com/nuxt/nuxt/issues/14146 for pnpm support. Closing this as it is not an issue for this module.


AI Private radio channel

About the PR

Adds the 'AI Private' radio channel, similar in scope to the one from SS13.
The channel can be accessed by the AI (duh) and by all intercoms.
Intercom hearing range is also increased a bit to allow the AI to actually eavesdrop.
Why / Balance

The concept was suggested/discussed in #31906.

Gives the AI some opportunities to listen in on the crew and get an idea of what's happening without needing them to use their headset.
Allows the AI to speak 'locally' to crew through an intercom without being heard by everyone on radio.
Allows crew to communicate semi-privately with the AI, which may be useful in some situations. Messages sent via AI private also stand out compared to the constant flow of common radio messages, making requests made via the intercoms harder to miss.

Technical details

The Intercom component has a new FreeChannels attribute, which indicates what channels it can be tuned to regardless of inserted encryption keys.
When created without encryption keys, the intercom will automatically try to tune in to AI Private instead of common, otherwise it will just use the first key (usually common).
Media

Requirements

[X] I have read and am following the Pull Request and Changelog Guidelines.
[X] I have added media to this PR or it does not require an ingame showcase.

Changelog

:cl:

add: The AI can now use its own private channel to eavesdrop and communicate via intercoms.

With this, we may also want to consider increasing the range of intercoms, because currently the way most intercoms are mapped requires you to basically stand directly next to them to be heard.

"private" channel someone can just turn on permanently to snoop on:

With this, we may also want to consider increasing the range of intercoms, because currently the way most intercoms are mapped requires you to basically stand directly next to them to be heard clearly.

Yes I did increase the hearing range of intercoms as the description says. I'm not sure if enough though

Yes I did increase the hearing range of intercoms as the description says. I'm not sure if enough though

I suppose it depends on where the intercoms actually are in the maps, and it definitely doesn't help there's not really a mapping standard for them. 4-5 tiles would probably be reasonable, but I'm just eyeballing it.

It's currently increased from 2 to 4, but yes most maps don't really have them in consistent places because they're quite rarely used as anything other than free encryption key lootboxes.

Part of me thinks that intercoms should be turned into poor man’s holopads, letting the AI “possess” one to hear and communicate like they were a sentient hydroponic tray

I feel like if someone went and added all that extra functionality to intercoms it'd be better if they just added it to, well, actual holopads.

Could call it AI Direct, instead of Private?

Maintainer consensus seems to be that this implementation of the feature isn't very good, and it'd be better if we just had SS13's implementation. For those who are not familiar:

Radio channels are all specific frequencies, common is 145.9 kHz and AI private is 144.7 kHz.
Intercoms (and handheld radios) can just be set to any frequency in the range 144.1 kHz through 148.9 kHz, though it's in 0.2 kHz steps.

Channels with encryption keys still use this frequency system, but they're all below 144.1 kHz.

AI private only really shows up around the uplink and core and is not really considered security critical because it's a fixed frequency.

This has some implications:

You don't need to literally show a drop down in the intercom, meaning you don't have "AI private" in every intercom...
Enterprising crewmembers or silicons can make a mostly-private radio channels by just using one of the open radio channels.
The AI has 3 intercoms in its room that it can configure to anything. One of these is common, another is AI private, and another is unconfigured by default (IIRC?).

This enables many neat emergent game mechanics which this PR just doesn't have.

This makes sense, and I agree it would be a better mechanic but since radio frequencies are currently only flavor text as far as I can tell, it would imply a heavy rework of the radio system (and all radio-enabled devices), which would be way beyond the scope of this PR. Feel free to close this for now, and if the future radio system rework doesn't include the AI channel I'll request for this to be re-opened.

Feel free to close this for now, and if the future radio system rework doesn't include the AI channel I'll request for this to be re-opened.

Allright, leave a comment when you want it re-opened. Thank you for your contribution.
Until the radio refactor is done #32711 should serve as a good alternative way for players to privately communicate with the AI without relying on intercoms.


Made a few clarifications to the instructions in the README.

Made a few clarifications to the instructions in the README initializing a working R package.

Based on the wrong branch.  See PR #12.


Ts improvements 2

Tried to improved a little bit the types. Mostly copying React's definitions where needed. There is a breaking change though. I removed ComponentProps as in my opinion is not needed. The recommended way with react and ts2 is to use the ClassAttributes interface.

Coverage remained the same at 100.0% when pulling a2ab1976f2731a5119c1de4973b0ee60e58dc761 on valotas:ts-improvements-2 into b03bb360b123f95ebe6b2d08944eb32a92863745 on developit:master.

On top of that, I believe that we need some more tests. Any ideas? In my opinion the best way to have properer testing would be to write tests in ts, compile them and then run them to also test some behavior. For example I use JSX.Element[] as the type of the children but I am not sure if this is what I get back.

Coverage remained the same at 100.0% when pulling d91fcb880a2e323c5bd91fc37f0b911b178596da on valotas:ts-improvements-2 into b03bb360b123f95ebe6b2d08944eb32a92863745 on developit:master.

Coverage remained the same at 100.0% when pulling 2d45e141b3793ae8de760741f11b3e4fb50746ad on valotas:ts-improvements-2 into b03bb360b123f95ebe6b2d08944eb32a92863745 on developit:master.

Changes Unknown when pulling 853e31cfa7b7c4091f8110b513f91137111fa677 on valotas:ts-improvements-2 into ** on developit:master**.

@developit I am in need of a review and maybe ideas one complex typescript usage. In theory this branch is ready for merging.

@valotas this seems to work really well for me! Quick question though, I didn't see any examples of how to use children with a regular component.
Is something like this possible?
render(props: Props) {
  return (

{props.children}

  )
}

Sure, I'll add a test for it once I'll get back online (back from vacation)

@matthewmueller I had to introduce the RendableProps for what you need. You can see an example usage at Component-test.jsx

👍 big fan of getting something like this merged and released! The current types have enough issues that it makes it very difficult to use Preact with TS. (For example, props being optional where it shouldn't be, strings not being allowed to be mixed with Elements properly, etc.)

@valotas thanks 😄! I'll be testing this out again next week.
@JKillian right now I'm just copying these into my project as types/preact.d.ts and adding definitions in my tsconfig:
"paths": {
  "*": [
    "types/*"
  ]
}

a bit manual, but works fine.

I forgot that. I'll try to fix the merge conflict this weekend.

Merge conflicts fixed. As I saw previously the base attribute of the Component was not optional. Is this the case? Is there a guarantee that with a Component instance base will always be accessible?

Coverage remained the same at 100.0% when pulling fa22ad6d1fc72facacf9538f27f64fdf37ed7f7f on valotas:ts-improvements-2 into 2205c0f65d9595df1b1fddd7b09c79102ae34401 on developit:master.

@valotas nice just had a chance to try the updates. everything seems to be working well, but I had a quick question:
what's the reason to go with RendableProps over just attaching it to attributes? something like this:
interface Attributes {
    key?: string | number | any
    children?: JSX.Element[]
  }

Then using it:
export interface Props extends Attributes {
  filepath: string
  head: any
  style: any
  page: any
}

export default class Document extends Component<Props, void> {

}

^ attributes bit makes sense to me.
Regarding base - it's always added by Preact, though it is undefined in the constructor and componentWillMount() (as part of mount lifecycle timing).

If you guys greenlight this I think we can test them out in a release. Any type definition breakages tend to get noticed and reported quickly haha.

Oh I get it now, attributes are for the class itself (in the example above: Document). Nonetheless, I think it'd be a bit easier to remember if we could use extend.
Rather than:
interface Props {
  filepath: string
  head: any
  style: any
  page: any
}

export default class Document extends Component<Props, void> {
  render({ children }: RendableProps<Props>) {
    // ...
  }
}

Unfortunately, this is really due to a limitation around Typescript definitions (while inherited classes are type-checked, the types don't flow through).
Just for others, in the case above, you can do the types yourself pretty easily, which is what I'd probably end up doing:
export interface Props {
  filepath: string
  head: any
  style: any
  page: any
  children?: JSX.Element[]
}

export default class Document extends Component<Props, void> {
  render({ children }: RendableProps<Props>) {
    // ...
  }
}

But, i still think it'd be better if it was something like this:
import { h, Component, Props } from 'preact'

interface DocumentProps extends Props {
  filepath: string
  head: any
  style: any
  page: any
}

export default class Document extends Component<DocumentProps, void> {
  render({ children }: DocumentProps) {
    // ...
  }
}

Sorry for my late answer.
@matthewmueller I believe you answered the question regarding Attributes yourself :) I will rename Rendable to Renderable. Yet, if someone has a better idea regarding this, let me know. I do not like the name either. Regarding it's use, I tend to use this.props instead which inherits the types :).
Apart from that I do not understand the problem with preact/devtools. Never saw that error before.

@matthewmueller I believe you answered the question regarding Attributes yourself :) I will rename Rendable to Renderable. Yet, if someone has a better idea regarding this, let me know. I do not like the name either. Regarding it's use, I tend to use this.props instead which inherits the types :).

Ah I see. My vote would be it being an interface as opposed to a type with a generic. So we could do:
interface Props extends Renderable {
  name: string
}

Could also be an additional type.

Apart from that I do not understand the problem with preact/devtools. Never saw that error before.

I think happens if you copy + paste the type into your project. Shouldn't be a problem once this gets merged!
Two more things:

Noticed a bug with the VNode. children can also accept as string (for textnodes). Should be:

interface VNode
 {
    nodeName: string | ComponentClass
 | SFC

    attributes: P
    children: Array<VNode<any> | string>
    key: Key | null | undefined
  }

What do you think about adding an additional property jsx?: boolean to HTMLAttributes?

Basically to support styled-jsx a bit better. I wish they didn't use something custom, but at this point, prettier also has styled-jsx auto formatting via that tag, so seems like it's getting standardized sorta.

Happy to help push this forward if you don't have time. It's just a bit weird on Github branching off a branch.

@matthewmueller for Strings, children boxes them into an Array:
h('div', null, 'a string').children // ['a string']

@developit This would be related to creating raw VNodes. e.g.
const style: VNode = {
  nodeName: "style"
  attributes: {
    id: "some-id"
  },
  children: ["hi there"]
}

Right now the type definition only allows something like this (which I don't think would work):
const style: VNode = {
  nodeName: "style"
  attributes: {
    id: "some-id"
  },
  children: [{
     nodeName: "hi there"
  }]
}

^ correct, that would result in preact rendering a <hi there> element (which would throw an exception).  I'd definitely recommend always passing things through h() - it does children normalization that the rest of the diff kinda expects to be already done by the time it runs.
--edit--:  I totally misread your type definition - you're right, it needs to be Array<VNode | string>!  I had read it as "an array of vnodes, or a string".

Coverage remained the same at 100.0% when pulling 970c456e6d8151884ab97659e29dcce2fa19617b on valotas:ts-improvements-2 into 2205c0f65d9595df1b1fddd7b09c79102ae34401 on developit:master.

Ok, fixed the VNode types. Can someone explain me the jsx property thingy? I think I didn't understand that or never stumbled upon this pattern.

Apart from that. I also do not like the RendableProps approach and for sure it's name. But I can not think of something better. In react's types there is no type/interface exposure. The only reason that I define a type here is to allow proper typed destructuring on the render function. I am also not fun of the base props class as children is something that you should not care about when you define the properties of your component. You get it for free from the framework and that is how they should be defined. Have in mind that react used to have the a base class and not anymore.
Never the less I am happy to remove the RendableProps, inline the types at the render function and provide a Props interface for easy access in the render function. I have to state again though that I do not like the idea.
My workaround is to destructure this.props in the render function instead of the the function's arguments.

Finally, please let me know of any name changes. Changing this afterwords would make preact backwards incompatible. I'll check again against the react's type names. I believe it makes sense to be as close as possible there.

@valotas awesome! I'm much more interested in seeing this get in there than the specific types can be done in PRs later.
After closer inspection of the TS test, it's not terrible to just add, when needed:
render({ initialName, children }: RendableProps<SimpleComponentProps>) {

I'd still prefer it to be called RenderableProps, but not a big deal either way.

@matthewmueller sorry, I forgot to rename it. RenderableProps it is now!

Coverage remained the same at 100.0% when pulling 5f3a60ec5d03ea91b9bb4a001468f66ca8bf7313 on valotas:ts-improvements-2 into 2205c0f65d9595df1b1fddd7b09c79102ae34401 on developit:master.

One more thing that I mentioned above: what should I do with the jsx: boolean? I haven't seen its use anywhere at the moment. Can someone give me an example or try to explain it to me?

Awesome :-) I'd say @developit's call there. Doesn't really hurt, but it's also nonstandard.
https://github.com/zeit/next.js uses it via https://github.com/zeit/styled-jsx, so it'd be handy for next.js folks.
The main issue for me is that prettier doesn't support formatting without the jsx field, so I was sorta falling into a pit of despair. That's likely to not be an issue soon though: https://github.com/prettier/prettier/pull/2774

Added jsx attribute too. Shall I squash the commits?

Coverage remained the same at 100.0% when pulling 7f58084e86f250faaa65846e5124d1db511fd7ca on valotas:ts-improvements-2 into 2205c0f65d9595df1b1fddd7b09c79102ae34401 on developit:master.

+1, thanks for all your hard work @valotas!

@developit Is this going to be merged anytime soon? Is there anything else needed? It is open for 3 months now.

Coverage remained the same at 100.0% when pulling aa219b52a3b72abcd66f518b41f57ad7c41ea55e on valotas:ts-improvements-2 into f7834ec9fb7848581c6fbc7833bcbe2f2db9fe61 on developit:master.

Could this be rebased and merged? 🎉

Coverage remained the same at 100.0% when pulling f127380950bbbd560c8be06c2f3eaa3dee7da3ee on valotas:ts-improvements-2 into 4bc9af44321e5e4c9fccf373d7e189fda8b7a635 on developit:master.

Coverage remained the same at 100.0% when pulling f127380950bbbd560c8be06c2f3eaa3dee7da3ee on valotas:ts-improvements-2 into 4bc9af44321e5e4c9fccf373d7e189fda8b7a635 on developit:master.

Rebased. Merging is not up to me

Coverage remained the same at 100.0% when pulling 33e1a017acf0b42e6e538ce54ab9a62a98b9f834 on valotas:ts-improvements-2 into e58337062d80763821258f692c78e928ba90c782 on developit:master.

@UnwrittenFun can you review that again?

@developit I wouldn't like to bother you with ts stuff, but if you are not willing to merge this, I would propose to just close the pr. It doesn't make sense to clean conflicting files every week.

Spoke with @developit and I’ll take a look at this over the next day or so.
Thank you for your continued persistence and patience.

Maybe the definitions can be moved to DefinitelyTyped.

My vote would go for DefinitelyTyped as well, if this really won't be merged. There is really great stuff in this PR and it would be a shame to leave it to collect dust

+1 for moving typings to DefinitelyTyped. Theres a ton of PR open with TS improvements none of them got merged for months and current state of them is far from React typings. Please let people more familiar with TS manage them as they found more suitable.

@valotas I've just become part of the core preact team and I'm currently going through all TypeScript related PRs. Would really love to merge this. Any chance you could rebase the changes one last time?

I'll have a look at it

@valotas Awesome! Thank you so much for your patience and sorry that it took so long🎉


Set up a new Architectural Design Document with Architectural Decision Records

Create a new documents folder in the code repo and add a new Architectural Design Document (ADD) and begin filling in content. It doesn't need to be complete at this stage, only high level information about the project and architecture.
Also add a folder and start recording Architectural Decision Records (ADRs) to document why we've made certain choices.
Acceptance Criteria

[x] An ADD exists in the code base with a high level outline of the project.
[x] An ADR folder exists with at least one ADR covering the decision to use ADRs.

ADD exists in the folder docs/architecture/description and contains a high level overview of system architecture.
ADR folder exists (docs/architecture/ADRs) and contains one ADR,


Make Tailor to work with immutable non-optional types

Let's say I have an immutable model (which I do have often, and it's a good think to do :smiley:  )
struct Person {

  let firstName: String
  let lastName: String
}

let p = Person(firstName: "Sarah ", lastName: "Connor")

Now I want to use Tailor Mapper to map my JSON to the Person type
extension Person: Mappable {
  init(_ map: JSONDictionary) {
    firstName <- map.property("first_name")
    lastName  <- map.property("last_name")
  }
}

let dictionary = ["first_name" : "Sarah", "last_name" : "Connor"]
let model = Person(dictionary)

In that way you can first start with making models and using them directly.
After that you can add Mapping support without breaking ability to directly instantiate your Person model

@kostiakoval Started looking into this and then I found this thread - http://stackoverflow.com/questions/27825362/can-i-initialize-a-variable-using-a-custom-assignment-operator/27827754#27827754
Seems like we can't achieve this using infix operators, I'm current looking into other alternatives and nifty stuff that could potentially work.

:tada:


Support to reload configuration file without killing process

Having a signal like HUP or something to reload the configuration file will be really helpful since we do swap instances sometimes.

I created a hot config reload patch which does not drop connections. Will release in form of a pull request by the end of this week.

@vlm looking forward to it

@vlm looking forward to it +1

@bobrik @mckelvin check out https://github.com/twitter/twemproxy/pull/321

Any news about the pull request? I can see tons of feedback on it but no update on this thread..


Create Tamper plugins and Python Connector

I think use this to load python modules to use tamper at payloads...
https://docs.python.org/2/extending/extending.html

I think that Python is not fast for this. You can use dinamic libraries written in C too. So you'd have to do the tampering call using dlopen/dlsym/dlclose with some predefinided function names, like tamper_parameter(), tamper_useragent so on.

nice, thanks master
next step i search something with dlopen()
cheers


Change gem name to pi_piper-bcm2835

Hi,
I changed the name of the gem. It is really important for two reasons :

Bcm2835 is a name of a chip from Broadcom, it represent for everybody a chip and nothing else.
The name of the C library is libbcm2835, but it is also a not so good name for the same reason.
by prepending the name with pi_piper we clearly state that the gem reside in PiPiper ecosystem and use the PiPiper namespace.

:+1: This is actually exactly what I was thinking right after creating this placeholder repo.


fixes an r-group symmetrization problem

Here's the issue:
In [8]: scaff = Chem.MolFromSmiles('Cc1ccccc1')
In [16]: ms = [Chem.MolFromSmiles(x) for x in ('c1ccccc1C','Fc1ccccc1C','c1cccc(F)c1C','Fc1cccc(F)c1C')]
In [17]: rdRGroupDecomposition.RGroupDecompose([scaff],ms,asSmiles=True)[0]
Out[17]:
[{'Core': 'Cc1c([*:1])cccc1[*:2]', 'R1': '[H][*:1]', 'R2': '[H][*:2]'},
 {'Core': 'Cc1c([*:1])cccc1[*:2]', 'R1': '[H][*:1]', 'R2': 'F[*:2]'},
 {'Core': 'Cc1c([*:1])cccc1[*:2]', 'R1': 'F[*:1]', 'R2': '[H][*:2]'},
 {'Core': 'Cc1c([*:1])cccc1[*:2]', 'R1': 'F[*:1]', 'R2': 'F[*:2]'}]

Surprisingly few changes.  We should note somewhere that the smilesSet and getSmiles are broken as well.

Ok, done. I went ahead and fixed the problem with the SMILES being combined incorrectly and added a REVIEW comment about the set.

Thanks Greg!


Cleanups for ProgramBlockView and functionality

A selection of suggested improvements for the ProgramBlockViews and their functionality

Cleanup methods and names (they take more arguments than required and they don't use standard conventions (starting with a verb)
Rename ProgramBlockAllAspectsView and ProgramBlockView to ProgramBlockView and ProgramBlockBaseView

Would also be good to improve the comments in the ProgramBlockViews
Examples: specify better what each bit is rendering to make it easier to find
Ensure each class has good top level docs
Main place Shane and I noticed this in: ProgramBlockBaseView

We could also consider improving tests by introducing BeforeAll and possibly several describes in one file https://sourcegraph.com/github.com/civiform/civiform/-/blob/browser-test/src/civiform_admin_program_statuses.test.ts?subtree=true
I should check with Bion first what specifics actually make a difference for performance though

Also rename ProgramEditView to ProgramDetailsEditView because it is the view that gets shown when you click on "Edit Program details" and it is easy to confuse with ProgramBlockEditView.

Other things that could be improved:

There are various todos saying that "Block" should be renamed to Screen
The classes that are named ProgramBlockXXXview are not limited to one ProgramBlock. From their functionality they are more of a ProgramXXXView. Renaming would improve readability, but would require a bit of research into what names are in use already

I'm using this bug as an umbrella bug for various ideas and observations, which could be split out later on.

Suggestions for improving  the admin_program_viewing.test.ts:
The questions themselves in the block view have some edit controls e.g. the optional toggle and soon the address verification toggle. Need to account for those when rendering the read only version.


params not matching with route

Versions

nuxt: v2.14.3
node: v12.16.1

Reproduction
when using the following directory structure
dir: blog/
dir: blog/_country/
dir: blog/_country/_year
file: blog/_country/_year/index.vue
file: blog/_country/_year/_slug.vue

and the following content of file blog/_country/_year/index.vue
async asyncData({ params }) {
    console.log(params)
}

Steps to reproduce
go to http://localhost:3000/blog/new-zealand
What is Expected?
{
  country: 'new-zealand',
  year: undefined,
}

What is actually happening?
{
  country: undefined,
  year: 'new-zealand',
}

params are not correctly matched with _params in folders/files

FYI: this works as expected in<EMAIL_ADDRESS>and<EMAIL_ADDRESS>but has stopped working from 2.14.1 onwards

I believe this is the correct behavior based on your directory structure.
Explanations:
With your structure router will create two routes.

/blog/:country?/:year
/blog/:country?/:year?/:slug

On the page /blog/new-zealand router matches with first route. As you see :year params is required and :country is optional, so router use new-zealand and :year and left :country empty
You should create file blog/_country/index.vue to handle /blog/new-zealand as you expected.

@farnabaz Thanks for that clear explanation.


Client is crashing at server join

Version of Advanced Rocketry
1.12.2-1.4.1-104
Have you verified this is an issue in the latest unstable build
Yes. Before i use the version 104, i had used version 96. No crashes when i join server.
I have now again to test the version 96 loaded on the server. Now the client does not crash anymore. The error is clearly at the 104.
Older version that i used before: LibVulpes 0.2.8-37 and AdvancedRocketry 1.4.0-96. This Versions make any Error messages in the Server logs, but i can join the server.
Version of LibVulpes
1.12.2-0.2.8-39
Version of Minecraft
1.12.2
##Forge Version
forge-1.12.2-<IP_ADDRESS>68-universal.jar
Crash report
https://pastebin.com/jcTkunLQ
Description of the problem
When joins the server, the screen turns white and shortly afterwards the game crashes.

Welp, I guess that solves the question as to whether it occurs without sponge and/or optifine

I think i might have the same exact issue with AR. Unless im just tremendously dumb. Here's the log

Can you upload the planetDefs xml and startup log?

https://pastebin.com/cesCGYEu
Cannot find planetDefs.xml (we haven't made one. Shouldn't it be created automatically or smth?). The weirdest thing is that it works perfectly on a dedicated machine, but fails on localhost o.O

It should be in the /advRocketry/planetDefs.xml, and it should be created automatically.
Works perfectly on dedicated machine but fails on localhost.... that is strange, but helpful information.

Issue is reproduced on the Rebirth3 modpack.
https://gist.github.com/LemADEC/e90cc1d70cf54e7faaf9422149bdb654 (planetDefs.xml)
AdvancedRocketry-1.12.2-1.4.1-108-universal

Kind of an update on this, had someone come by with this same crash coming up. For testing they updated the server and client(s) to v111 but same issue. For the moment they just set PlanetSkyOverride, StationSkyOverride, and overwoldSkyOverride to false and that is allowing them to not crash currently.
https://pastebin.com/QjqF2eig This is the crash when using v111

@FallenEagle1  that makes sense since it's a thing with the sky renderer.
@LemADEC what version, latest as of Nov 1?

Just thought I'd mention it, since I was thinking that v109 was to fix the issue.

I thought it would but apparently not.  It's hard to fix an issue I've not been able to recreate.  I'll keep looking.

@zmaster587 my comment said it was AdvancedRocketry-1.12.2-1.4.1-108-universal . What do you mean by latest?

@LemADEC I meant of Rebirth3

It was on Rebirth3-1.12.2-r13-hotfix2.

Above patch should have fixed it


Error following installation guides

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/1220
Originally created by @evan_burke on 2019-10-28 23:39:36

What is the current bug behavior?
In Docker for Windows, under WSL: after initializing a project and attempting to run the UI, I'm receiving the error, "Error: meltano ui must be run inside a Meltano project."
What is the expected correct behavior?
After initializing the project, Meltano should launch without an error.
Steps to reproduce
In Ubuntu WSL, with Docker for Windows <IP_ADDRESS>, following the steps outlined here: https://meltano.com/docs/installation.html#installing-on-docker
~$ docker pull meltano/meltano
[ download completes ]

~$ docker run meltano/meltano --version
meltano, version 1.3.0

~$ mkdir -p meltano; cd meltano

~/meltano$ docker run -v $(pwd):/projects -w /projects meltano/meltano init myproj

        Created [ files list ]
Project myproj has been created.

Next steps:
        cd myproj
        Visit https://meltano.com/docs/getting-started.html in order to try us out

Meltano sends anonymous usage data that helps us improve the product.
For more information, see https://www.meltano.com/docs/environment-variables.html#anonymous-usage-data

# Look for 'myproj' directory on host - doesn't exist. Should it?
# Docker installation instructions seem to imply it should be present on host,
# but the init command is creating files within the container.
~/meltano$ ls myproj
ls: cannot access 'myproj': No such file or directory

# as specified in instructions:
~/meltano$ docker run -v $(pwd):/project -w /project -p 5000:5000 meltano/meltano
Error: `meltano ui` must be run inside a Meltano project.
Use `meltano init <project_name>` to create one.

# try using project name as directory instead:
~/meltano$ docker run -v $(pwd):/myproj -w /myproj -p 5000:5000 meltano/meltano
Error: `meltano ui` must be run inside a Meltano project.
Use `meltano init <project_name>` to create one.

View 13 previous comments from the original issue on GitLab


Editor voxel paint

Voxel painting in editor on selected VoxelInstance3D

working now. Requires VoxelBody3D and convex mesh to work. Could add these temporarily for editing pure VoxelInstance3D:s


Expose V1 entity versions / conflict detection

From:

https://github.com/GoogleCloudPlatform/gcloud-python/pull/2107/files#r75191382
https://github.com/GoogleCloudPlatform/gcloud-python/pull/2107/files#r75192591
https://github.com/GoogleCloudPlatform/gcloud-python/pull/2107/files#r75191517

See the docs for the new (seemingly related) features:

EntityResult.version  field
Mutation.base_version field
MutationResult.conflictDetected field

Hello,
One of the challenges of maintaining a large open source project is that sometimes, you can bite off more than you can chew. As the lead maintainer of google-cloud-python, I can definitely say that I have let the issues here pile up.
As part of trying to get things under control (as well as to empower us to provide better customer service in the future), I am declaring a "bankruptcy" of sorts on many of the old issues, especially those likely to have been addressed or made obsolete by more recent updates.
My goal is to close stale issues whose relevance or solution is no longer immediately evident, and which appear to be of lower importance. I believe in good faith that this is one of those issues, but I am scanning quickly and may occasionally be wrong. If this is an issue of high importance, please comment here and we will reconsider. If this is an issue whose solution is trivial, please consider providing a pull request.
Thank you!


MINOR: fix pom for Eclipse

This is a cleanup for #99

@bbejeck The build failed with
[ERROR] /home/****/workspace/fka-streams-examples_PR-102-3MNRSCXHSUDN25ZUJID3UYKBBERCJKI6EHYR2JYEV2VLC34EHF2Q/src/test/java/io/confluent/examples/streams/kafka/EmbeddedSingleNodeKafkaCluster.java:[107,19] cannot find symbol

Seems to be your latest commit... Any insights?

@mjsax I'll look into it

Updated this.


Comments Tweaks

Badge color is now primary
Badge count is thread count, not all comments
Threads are sorted DESC
Threads are only loaded if the sidebar is open
Thread count for badge is loaded separately if needed
Some other minor cache tweaks

I moved to loading from Commentable this opens open the room for something like
query {
  language(id: "") {
    commentThreads { total }
  }
}

To load the badge count (or more info) without a separate network request.
This is only a half baked idea, so nothing like that changed here.
In general, I think it makes more sense from DX because we view the comments under a resource and now this & cache reflect that.
Performance wise before and after are the same. We always loaded the Commentable first anyways in the API.

Seems awkward having the count load separately from the rest of the data.

That's an optimization. If the sidebar isn't open we only load the total count. If it is open, then the sidebar loads the total count and the button just uses that query (via cache).


Add Multi OS support for Troubleshooting commands

Description:
The UI has code blocks defined for troubleshooting node setup. These code blocks should support multiple OS types

Added in f3299ac

This looks good! Having #10 would be nice

https://github.com/ethersphere/bee-status/pull/1/commits/e6b0cea1a3321f7ae4f236093643b732b86e3b82. Added localhost detection. Would like to have the actual node report the OS though as it really should be something coming from the node itself so that this application can support remote connections.

Closing as the basic functionality is fulfilled. #10 expands upon further refinement


Removing attached validators when cloning the model

Q
A

Is bugfix?
✔

New feature?
❌

Breaks BC?
❌

Tests pass?
❌

Fixed issues
#18567

@shkolin is it possible to add unit tests verifying the behavior?

@shkolin what is the status of this PR?

@bizley  , this can be closed also, it's already fixed


Chore(cli dev): Show what port the bot is running on when starting it up.

Update dev file and start file in the robo CLI so they display the port the bot is currently running on.
We could use the .env file to display the port it is using, or fallback to default when there is nothing in it.

Doesn't it already do that? See screenshot attached:

I'm assuming you're talking about the API plugin because bots themselves are socket-based and don't listen to incoming connections via ports. Rather, they are the ones to initiate the connection.

It works with the plugin-api indeed, but we had users concerned about what port the actual bot was running on, I'll surely let them know about it then.


do not generate "empty" constraints in Gopkg.toml on init

I actually used the dep init workflow on a real thing for the first time in a while today, and noticed that we generate "empty" dependencies - entries with only a name, but no actual constraints - probably when we encounter a revision with no known branch or version in GOPATH. let's not do that - it's meaningless, but having those entries there will confused people into thinking it's necessary.
I'm even tempted to say we should add a warning for this case, but that might be too much.

Could you elaborate on how to reproduce this behavior? I'm not able to get dep init to generate empty dependencies...

check out an arbitrary revision for a dependency onto GOPATH, run dep init, and I believe it should occur.

*arbitrary revision, with an associated tag or branch

@sdboyer,
Has anyone picked this up yet? If not, I'd be willing to try as I saw this was a good first pr candidate.

@jonstacks nope, nobody has - please do have at it!

@sdboyer, I took a shot at it https://github.com/jonstacks/dep/commit/b084b99c37d98a4ec45b3cf38577328e852fd598
Since you know the codebase much better than I, can you tell me if I'm on the right track before I open up a PR? I wasn't sure if this was better suited for being in gps.

@jonstacks so fast! 🎉  don't worry about that - please do open up a PR! Doesn't matter if we end up closing it. It's much easier to discuss & review in public with a PR, anyway 😄


SMTP.yml - new SMTP problems

I did my periodic update for the first time in a month or so yesterday and SMTP has now broken for me. I see a commit in the recent commits as removing smtp.yml, but I had all my config in the .env anyways. Any ideas why a plain localhost SMTP server is now not authenticating despite having set type as "plain"?

Hm, after a bunch of playing around it seems the .env variables aren't being accepted. In my config I needed to disable TLS for example and only editing the config/initializers/action_mailer.rb settings actually seem to work in the changes. Did that last commit from @dsander somehow override the .env variables?

Hey @bobbysteel, that certainly wasn't the intention. Are other .env settings being loaded for other parts of Huginn?

Everything else seems to be fine with the other .env variables. Database access is good as usual. It's just ignoring the old .env settings it seems. I can try and troubleshoot it some more but was wondering if anyone else was seeing this. I haven't done a line by line test to see if it's ignoring everything but at least some of the paramaters like autostart TLS didn't seem to be honored in the .env but in the main.rb file though.

@bobbysteel That is odd, I did not have issue with the smtp configuration after updating, is enable_starttls_auto the only setting that is not set correctly?

Unfortunately, I wasn't able to test granularly to determine if it was just one setting. My server stopped sending emails entirely with a unable to authenticate error (despite being set to "plain" as auth type). At various points I just switched both files, but it did seem that the "plain" and "starttls" were both ignored in the .env but respected in the main.rb file. Presumably all other .env settings are fine as database etc are still working great.

@bobbysteel Thanks, I see. We probably have to wait if we get more issue reports, I don't see how the changes would cause issues, but nothing is impossible :)


Fix the OTEL tracer package name

There were two trace packages. Now both the OpenTracing and the OpenTelemetry tracers are in the same trace package.

What I'd really meant was:
It's bad that the OpenTracing one is in "trace" at all. It forces people to pull a tree dependency on opentracing-go, which is going to go away as OpenTelemetry ramps up. These two tracers should both be in their own packages, but the old one has to stay where it is in case anyone referenced it (until you hit 2.x.y on versioning, then can break it, unless you want to relax the Semver rules).
What I'd really suggest is:

Near term - Old tracer in "trace" new one in "oteltrace" (so you only pick up a vendor/dep of that if you're using opentelemetry).
Near Future - Migrate older tracer to new package and leave only the interfaces in "trace".
Distant future - Migrate both out to graph-gophers/contrib-tracing-x packages

Nothing irks me more than pulling a dep on a range of possible platforms and then only one of them's getting used. Even today people who aren't using any tracing are picking up OpenTracing packages in their tree.

I was thinking about using the OpenTelemetry in a different package that implements the interface. I agree with you and this is the reason I haven't cut the next release. Maybe we should start moving them to a new packages as of now and the OpenTelemetry one should be in a new package.

This library doesn't need to have this baked in. It's worth adding it as an example only and have the two implementations in a separate package.

It wouldn't download both if it was split into 3 packages (trace, graph-gophers/tracing-opentelemetry and graph-gophers/tracing-opentracing). Code that only references graphql-go would only download that package.
The real question is do you want to wear the "breaking change" for moving the OpenTracing one out of the main folder. If you can do that, then you could just go balls-out and do the two sub-projects for the tracers and be done with the problem forevermore.

I'm not willing to introduce a breaking change without a new major version. This is not planned for anytime soon. So at the moment I can move the OTel one into a new subpackage. I'd personally remove both of them from this project in a new major version and add them as an example.

So, new one and old one both to packages, but leave copy of old one where it is with a deprecation notice?

I can move the OTEL one like this https://github.com/graph-gophers/graphql-go/pull/496 (this is your original suggestion I beleive). However, I cannot introduce a breaking change, although, I agree with you that the two implementations need to be in two separate sub packages.

Actually, the opentracing-go library is deprecated now. They have left this notice on their repo:

OpenTracing API for Go. 🛑 This library is DEPRECATED!

This means that indeed I can add the deprecation notice and leave them both in the same package. Then later completely delete the OpenTracing one or move it to an example or to a separate package. The thing is that there are many organisations which are still using the OpenTracing package and haven't switched to OTEL.


[FEATURE] User-specifiable transform function to modify the slide XML before it's written

Issue Category

[x] Enhancement
[ ] Bug
[ ] Question
[ ] Documentation gap/issue

Desired Behavior
It would provide a lot of flexibility if we could specify a transformer-function which runs on the output of each slide.
E.g. an option called transformSlideXML with the signature (inputSlideXML) => string;
So if specified then makeXMLSlide would run the output through this function before returning.
This would give users the option to implement anything you do not support by piping the XML of each slide through this function.
(In my case I would really like to have control over autoplay & looping of videos. I realize this is too much of an ask as a feature. So a transformer function would let me find/replace to add this myself in an elegant way.)
This would essentially let people write mini plugins to patch new features in if they do not have the confidence/familiarity to submit them as PRs. (E.g. in my case I can identify the XML that would need to be added and where to add it but I don't have the confidence to turn this into a PR).

In fact I could probably make a PR for this if you like the idea.
Really like this library - thank you for what you're doing.


[Feature]: Running the script without root privileges

Description
It would be great in v4 to be able to install coolify via ssh under any user.  It is not safe to keep ssh root open.  In v3 this works great.
Minimal Reproduction (if possible, example repository)

Exception or Error
No response
Version
v4

100% agree. root user should not be required. Installing coolify using sudo should be possible, and from that coolify should create it's own user with the needed permissions, add itself to sudoers, etc.

I recently stumbled on this project and saw a scary revelation by a user on ycombinator that Coolify is doing a -v /var/run/docker.sock:/var/run/docker.sock.
Is this still the case?


vmcluster: change to storageClassName does nothing

I changed the storageClassName of the storage used for vm: https://github.com/uhthomas/automata/commit/d7a1e722b6270b715ca75bf9874189f04ea4fd1e
I checked the logs of the operator and initially it looked like it didn't even notice a change, but further investigation shows:
❯ k -n vm-operator logs vm-operator-67dfdcc756-xmncl | grep -A 2 -B 2 nvme
{"level":"info","ts":1689739302.245668,"logger":"vmcluster-resource","msg":"deprecated property is defined `vmcluster.spec.vmselect.persistentVolume`, use `storage` instead."}
{"level":"info","ts":1689739302.2575405,"logger":"controller","msg":"Reconciling VMCluster","Request.Namespace":"vm","Request.Name":"vm"}
{"level":"info","ts":1689739302.2685633,"logger":"client_utils","msg":"pvc changes detected","metaDiff":[],"specDiff":["StorageClassName: rook-ceph-nvme-ec-delete-block != rook-ceph-hdd-ec-delete-block","VolumeMode: <nil pointer> != v1.PersistentVolumeMode"],"pvc":"vmstorage-db"}
{"level":"error","ts":1689739302.302114,"msg":"Reconciler error","controller":"vmcluster","controllerGroup":"operator.victoriametrics.com","controllerKind":"VMCluster","VMCluster":{"name":"vm","namespace":"vm"},"namespace":"vm","name":"vm","reconcileID":"2916101f-c849-4573-89f2-0386a560f6d9","error":"failed create or update vmcluster: statefulsets.apps \"vmstorage-vm\" not found","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/controller-runtime@v0.13.1/pkg/internal/controller/controller.go:326\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/controller-runtime@v0.13.1/pkg/internal/controller/controller.go:273\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.13.1/pkg/internal/controller/controller.go:234"}
{"level":"info","ts":1689739302.3022468,"logger":"controller","msg":"Reconciling VMCluster","Request.Namespace":"vm","Request.Name":"vm"}
{"level":"info","ts":1689739302.564611,"logger":"client_utils","msg":"pvc changes detected","metaDiff":[],"specDiff":["StorageClassName: rook-ceph-nvme-ec-delete-block != rook-ceph-hdd-ec-delete-block","VolumeMode: <nil pointer> != v1.PersistentVolumeMode"],"pvc":"vmselect-cachedir"}
{"level":"info","ts":1689739302.5771284,"logger":"KubeAPIWarningLogger","msg":"would violate PodSecurity \"restricted:latest\": allowPrivilegeEscalation != false (container \"vmselect\" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container \"vmselect\" must set securityContext.capabilities.drop=[\"ALL\"])"}
{"level":"error","ts":1689739302.5962908,"logger":"controller","msg":"cannot update cluster status field","error":"Operation cannot be fulfilled on vmclusters.operator.victoriametrics.com \"vm\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"github.com/go-logr/logr.Logger.Error\n\tgithub.com/go-logr/logr@v1.2.4/logr.go:299\ngithub.com/VictoriaMetrics/operator/controllers.(*VMClusterReconciler).Reconcile\n\tgithub.com/VictoriaMetrics/operator/controllers/vmcluster_controller.go:83\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile\n\tsigs.k8s.io/controller-runtime@v0.13.1/pkg/internal/controller/controller.go:121\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/controller-runtime@v0.13.1/pkg/internal/controller/controller.go:320\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/controller-runtime@v0.13.1/pkg/internal/controller/controller.go:273\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.13.1/pkg/internal/controller/controller.go:234"}

I don't understand why it would error with "the object has been modified; please apply your changes to the latest version and try again".
To be clear, I don't even know what the correct behaviour here should be. Given it's a cluster, it would be awesome to bring each pvc down sequentially and let the new ones replicate, though that is some effort.
A gripe:

"deprecated property is defined vmcluster.spec.vmselect.persistentVolume, use storage instead."
This isn't true.
https://github.com/uhthomas/automata/blob/d7a1e722b6270b715ca75bf9874189f04ea4fd1e/k8s/unwind/vm/vm_cluster_list.cue

Hello!
What operator version do you use?
It works in my environment, operator will create a new statefulset using new storageClass.

I'm using 0.34.1. Strange as I didn't observe that behaviour.

I'm using 0.34.1. Strange as I didn't observe that behaviour.

v0.35.0 contains a fix about spec change check, can you upgrade to  latest and see if the problem still exist.

@uhthomas the issue is still relevant?

closed as stale. Feel free to reopen.


Allow Rotation by hovering near corner

The best example I can think of is Figma. If you hover near a corner (but not directly on it), it will let you rotate the image.

Not sure if we're gonna support this any time soon. In the meantime, you can rotate via the circle (unclear from the issue if you are aware of this or not):


Update packs.load to register triggers by default

Part of https://github.com/StackStorm/st2/issues/3112.
Not loading rules by default was intentional, but not loading triggers was an oversight - we missed it when we added support for new triggers resource type.
TODO

[ ] Tests

Current coverage is 77.29% (diff: 100%)

Merging #3115 into master will decrease coverage by 0.08%

@@             master      #3115   diff @@
==========================================
  Files           430        430
  Lines         22144      22144
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits          17134      17116    -18
- Misses         5010       5028    +18
  Partials          0          0

Powered by Codecov. Last update 89d3e0b...742c1b2


Padding bug in align_rigid?

Thank you for your great work, I am plannig to use it for refining alignment of our multimodal recordings after camera geometry-based pre-alignment and so far it seems to works well!
However, when running your example.py script, the images example_flo_image.png and example_flo_image_recovered.png seem to have a shift difference of 1 pixel to the right. I dug a bit into your code and globalalign.py line 306, you are calculating the modulu with the padded input sizes. Subtracting 1 from x fixes the issue, but I have not checked whether the error is actually with the padding or happens later in the transformations, maybe somebody of you could take a look?

Glad it works well for you @phflot !
Good catch with the 1 pixel shift-issue; thanks for reporting. (Sorry for the slow response; for unknown reason I wasn't "subscribing" to issues for this repo.)
Your guessed reason is not the real cause though, but instead the different coordinate conventions used by torchvision.transforms.functional.rotate (origin at upper left corner of top left pixel) and scipy.ndimage.map_coordinates (origin at the center of the top left pixel). This leads to a half-a-pixel offset of the center of rotation, which together with the 90-degree rotation lead to the observed shift of one pixel.
Commit 2d9065c and release v1.0.2 should fix the problem.
$ diff -s example_flo_image_recovered.png example_flo_image.png
Files example_flo_image_recovered.png and example_flo_image.png are identical


Custom error handling hook for RequestHandler._execute_method

This is a suggestion to make error handling that happens in _execute_method customizable in subclasses of RequestHandler.
My use case was that I wanted to have "nicer" JSON errors for model validation errors. The first solution was to create a subclass class JsonRequestHandler(RequestHandler) that overwrites the complete _execute_method. This turned out to be messy and a maintenance burden considering future upstream changes of _execute_method, so I though is hook-like approach may be feasible.
See docstring for an example.

Ok, closing this PR for now.


Ensure capture inventory is set back to false after processing a command

This PR fixes https://github.com/SpongePowered/SpongeForge/issues/3008
Issue:
When an invalid command is executed it throws an exception which bypasses the call inventory.bridge$setCaptureInventory(false); this results in future events capturing item transactions when they are not suppose to.
Fix:
The changes I made moves the inventory variable to be outside the try-catch so the added finally block can disable capturing regardless of the command result.

https://github.com/SpongePowered/SpongeCommon/commit/341e4cc81c63426795cdfd9065d6b320c0acee72
Thanks!


x/net/http/httpproxy: support proxy authentication in env vars eg HTTPS_PROXY=https://user:pwd@host

Many tools built with golang rely on the environment variables documented in https://pkg.go.dev/golang.org/x/net/http/httpproxy#Config to let their users specify the http proxy to use (e.g. HTTPS_PROXY and NO_PROXY), and don't offer other configuration mechanism to configure http proxies used by outgoing http requests they make.
Besides, many CLIs such as curl have adopted the convention of extracting proxy authentication basic auth username and password from the http proxy url such as HTTPS_PROXY=https://user:pwd@fqdn , see https://curl.se/docs/manpage.html#-x

Using an environment variable to set the proxy has the same effect as using the -x, --proxy option. [...]
User and password that might be provided in the proxy string are URL decoded by curl. This allows you to pass in special characters such as @ by using %40 or pass in a colon with %3a.

Currently, the x/net/http/httpproxy#Config does not document the explicit support for username and password that would translate in http request made to comply with http proxy client authentication specified in https://datatracker.ietf.org/doc/html/rfc9110#section-11.7
This proposal suggests to document and implement as required such client proxy authentication support in proxy environment variables so that the golang binaries ecosystem relying on environment variables can leverage proxy authentication.
Note that the Deprecation of userinfo in http(s) URIs in RFC9110  (as I understand it), does not preclude using user info in URIs for configuration such as environment variables, but rather aims at preventing propagating Uris with user info from untrusted sources (e.g. in emails messages in the context of  phishing attacks).

Moving out of proposals because there's nothing to change.
httpproxy already supports user:pass in urls, sending them in Proxy-Authorization.
Given that we document support for a complete URL, I'm not sure there's anything to do.


Add support for token auth instead of basic

As per https://developer.jamf.com/jamf-pro/docs/classic-api-authentication-changes
Would be good to move away from basic auth

Sounds like a great idea! Here's an addendum from an offline conversation we had:

If the first request fails auth for whatever reason, bail. kmart is a good way to lock an account if you get the auth wrong


Storage file Datalake test improvement

There are no test cases about listPaths().byPage() in the existing test cases in the Java storage file datalake. So, it is recommended to add test cases related to paged retrieval results validation for method listPaths() of DataLakeFileSystemAsyncClient class in java test FileSystemAPITest.groovy.
By the way, python storage file datalake sdk have the test cases about  get_paths().by_page().
@scottaddie , @joshfree , @kyle-patterson , @tg-msft , @alzimmermsft for notification.

@scottaddie , @joshfree , @kyle-patterson , @tg-msft , @alzimmermsft  Do you have any ideas about this issue?

It seems to be true, the DataLakeFileSystemAsyncClient.listPaths doesn't seem to be covered at all and it doesn't seem to share much with sync version which is covered.

@alzimmermsft Do you have any plans on who will fix this issue?


migrate danger CI job to GHA

This PR migrates the danger CI job from Circle CI to GHA.

Thinking about this in the context of https://github.com/badges/shields/issues/8535 I am hoping that the combination of
https://github.com/badges/shields/blob/de3b3cebae673ceffdbb25283a53ad679e0f54e4/.github/workflows/danger.yml#L3-L4
and
https://github.com/badges/shields/blob/de3b3cebae673ceffdbb25283a53ad679e0f54e4/.github/workflows/danger.yml#L14
should keep things in check.
We might consider tweaking https://github.com/badges/shields/blob/master/dangerfile.js#L104 down slightly as that means a PR modifying 100 files can now eat 10% of our rate limit, as opposed to just 2%.


Update README.md

Hi, we would like to add our Builders Program to the README.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Add the ability add/edit user comments on workflows [BW-759]

This PR allows the ability to specify a comment when launching a workflow, and the ability to view/edit the comment from either the Job History page or the Submission Details.
It introduces a reusable "ValidatedTextArea", based on our style guide. The existing "ValidatedInput" is for single-line input only.
It also does a bit of clean-up with regard to marking div's that display error messages as aria-live, and fixing some syntax that was throwing deprecation warnings.
See also https://github.com/broadinstitute/rawls/pull/1510

Nice catch @aednichols. The returned string is truncated (e.g., "Incorrect string value: '\xF0\x9F\x98\x80\xF0\x9F...' for column 'USER_COMMENT' at row 1"), so I don't think we can reliably parse it to display the right thing. The request payload (as rendered by Chrome) looks good to me, so I'd look to Rawls as the source of the bug.
I judge the details in the error message are useful, so I don't think I'd change this code. It seems to me it is doing the best it can with what it gets.

Yes, thanks @aednichols for thinking to test with non-ASCII characters… my mind still default to an ASCII world.
It's interesting because some unicode characters, like ăѣ, work fine (and @salonishah11 included a unit test for them in https://github.com/broadinstitute/rawls/pull/1489), but others like 𝔠 or 😍, do not. As @dmohs commented, I think the terra-ui code is doing the best it can, unless we wanted to add client-side validation to exclude certain classes of characters. My thought is that we should probably create a new ticket for further investigation/changes (most likely on the rawls side). But I will continue to poke a bit more as well.

The more common/"normal" non-ASCII characters used by major languages have lower indexes in the unicode numbering system, causing them to require only one byte in a possible multi-byte encoding. So that explains why some non-ASCII works but not all.
I tried some Polish characters (my other language) and they work fine as expected.

Right, I think the 4-byte characters are the problem… though supposedly mysql has the ability to support them. https://dev.mysql.com/doc/refman/5.6/en/charset-unicode.html

I could look into the MySQL encoding configuration with you if you like, I find text encoding problems fascinating.
On the other hand, to save time it makes me feel better knowing that it works just fine with most characters/languages people are actually going to use.

@aednichols I agree that character encoding is interesting, but I think we probably shouldn't get too distracted from the other things we are working on (and probably product should weigh in on how much they do or don't care). I'll create a separate ticket to capture this issue, and we can discuss with product whether it's worth spending time on it.

Agreed.
Even if we did figure out a fix, it would be a potentially invasive DB reconfiguration that we would have to weight against the chance of introducing new, worse bugs.

@petesantos @kyuksel I am hoping to merge this by EOD today. Please let me know if you have any concerns about that-- I am not sure if I am expected to wait for both of you to approve, or if the 2 checkmarks I have are considered sufficient.

I am hoping to merge this by EOD today. Please let me know if you have any concerns about that-- I am not sure if I am expected to wait for both of you to approve, or if the 2 checkmarks I have are considered sufficient.

@cahrens Two 👍🏼s are sufficient to merge (as long as at least one is from "terra devs" group member) so you're good to merge 😊  Thanks for making sure though!


make_node(f::Function) is broken if all input args are DataVariable

Current implementation returns an actual result of f(args), it should be PointMass at least. Also would be nice to implement args::Union{ConstVariable, DataVariable}...

@bvdmitri what's the status of this?


GCP_PROJECT environment variable not set

Description
The production environment sets the GCP_PROJECT env var (same value as GCLOUD_PROJECT).  UUIC there may be some libs which look for this value, but the emulator does not set it.

I've never seen this variable before, maybe as some point the Cloud client libraries looked for it. Now they're generally look for GCLOUD_PROJECT or GOOGLE_CLOUD_PROJECT.

But I'll update the Emulator, if this is was prod does.


[optimizer] Optimizer to manage list of weights

Update optimizer to handle a list of weights than weights and bias individually
as layers like RNN, LSTM will have more than just (w,b)
Signed-off-by: Parichay Kapoor<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.4.20191203. Thank you for submitting PR #224. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnsuite.mooo.com/.

:octocat: cibot: @kparichay, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnsuite.mooo.com/nntrainer/ci/repo-workers/pr-checker/224-202006241641180.34481811523438-ff43260dd737133ddd45d966d73f1254c2d18513/.

:octocat: cibot: @kparichay, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnsuite.mooo.com/nntrainer/ci/repo-workers/pr-checker/224-202006241648170.72122502326965-d8fa5c94f5dfa7563c50ef5e823edff4e99b5698/.

I think conv2d backwarding must be fixed.
 opt.calculate(djdw, delBias[i], filters[i], bias[i], iteration);

I think conv2d backwarding must be fixed.
 opt.calculate(djdw, delBias[i], filters[i], bias[i], iteration);

Applied.


QnAMaker released new version.

Can we somehow switch into using New version of QnAMaker?
New version is way much better. But I could find a way to point my existing FAQ Plus to the new KB.

You can create new knowledge base manually and then you must change bot app service, function, and cofig app parameters with new QnA maker and Search service keys, endpoint and url's from configuration section.
For instance when you create a new KB you should get new config parameters from azure portal and qnamaker.ai
From qnamaker.ai:

Knowledge Base ID
Host
EndPointKey

From portal:
Search Service > Keys and Endpoint

Search Service Name
Primary Key
Key

QnA Service > Keys and Endpoint

EndPoint URL
Key 1

and then you should navigate one by one to your app service, function, app service of config app's configuration menu and change the parameters below with the new paramaters. And also, update the ConfigurationTable in storage account with the new knowledebase id and key.
AppService > Configuration

QnAMakerApiEndpointUrl
QnAMakerHostUrl
QnAMakerSubscriptionKey

SearchServiceAdminApiKey
SearchServiceName
SearchServiceQueryApiKey

Function > Configuration

QnAMakerApiUrl
QnAMakerSubscriptionKey
SearchServiceAdminApiKey
SearchServiceName
SearchServiceQueryApiKey

App Service (Config) > Configuration

QnAMakerApiEndpointUrl
QnAMakerSubscriptionKey

Storage > Inside ConfigurationTable

QnaMakerEndpointKey
KnowledgeBaseId


Update the MAINTAINERS.md in iroha2-dev

At some point, we want iroha2-dev branch to become a main one.
After https://github.com/hyperledger/iroha/pull/3946 is merged and https://github.com/hyperledger/iroha/issues/3945 is resolved, I'd like to replace the severely outdated https://github.com/hyperledger/iroha/blob/iroha2-dev/MAINTAINERS.md with a new version, so at the later point, we don't accidentally add a version of MAINTAINERS from Iroha 1 and leave it.

@6r1d does this need any work done, or should I close it?


Temporarily removing Windows from UsersDirectory

The e2e tests of GRR started to break due to the UsersDirectory supporting Windows. The issue is that this definition uses "provides: [users.username]" and the Knowledge Base used by GRR relies on it, so suddenly it has an unexpected list of users.
As a temporary solution until we figure out a better one, I'd ask that we remove the Windows support so the GRR builds can pass again.

@joachimmetz - PTAL :)


about how to get parameters

Hi , i want to know if  have method to get parameters like as   declare_parameter()  and get_parameter_or<>()  under micro-ROS  ?

Sorry but parameters are not currently supported in micro-ROS. It is in our roadmap.


ResourceManager round robin allocation paradigm docstring out of date

I believe 6c674e186c4005cd042d90c298f8054a6a7e826c makes the ResourceManager.allocate_round_robin's docstring out of date. The round robin method nows covers this case.
https://github.com/NOAA-OWP/DMOD/blob/267428bd903dd0f58bfbdba7620f77af03b30cff/python/lib/scheduler/dmod/scheduler/resources/resource_manager.py#L239-L243

Closed by #581.


[WIP] Add pytest-based acceptance tests

This is a work in progress.
Run py.test from Flintrock's root directory and you'll kick off a full set of acceptance tests. This will perhaps eventually replace lint.sh and test-integration.sh.
I'm still figuring out what to test and how to do it. I gather this is not a typical way to test software, but I think it's what makes the most sense for Flintrock.
Any input here would be great.
Fixes #49.

@shivaram and @broxtronix - I'm curious if, from your experience with spark-ec2 and spark-gce, you have any thoughts on how to test Flintrock.

Is there a high level description of what these tests are doing ? I never found a good way to test spark-ec2, but I do see some mock implementation of boto (like https://github.com/spulec/moto) that might be useful to get a realistic test -- @nchammas  Have you had any experience using any of these ?

Is there a high level description of what these tests are doing ?

@shivaram - At a high level these tests just invoke Flintrock's various commands like a user would and confirm that the return codes and other output are as expected. Each test's name describes what it's testing for.
For example:
def test_try_launching_duplicate_cluster(running_cluster):
    p = subprocess.run([
        './flintrock', 'launch', running_cluster],
        stderr=subprocess.PIPE)
    assert p.returncode == 1
    assert p.stderr.startswith(b"Cluster already exists: ")

Given an already running cluster, this tests that Flintrock exits with a code of 1 and a specific message if it tries to launch a new cluster with the same name.
Other tests confirm that HDFS and Spark are functioning, or that files can be uploaded to the cluster, and so on.

I never found a good way to test spark-ec2, but I do see some mock implementation of boto (like https://github.com/spulec/moto) that might be useful to get a realistic test -- @nchammas Have you had any experience using any of these ?

I've heard of Moto and similar libraries which mock out AWS, but I'm skeptical of their utility with Flintrock. As far as I can tell, they have 2 main problems:

They don't help us test critical Flintrock features like whether Spark is functioning after a launch, or whether a file can be copied up to a cluster. We need a real cluster with real hosts we can SSH into and install stuff on to test these features.

This alone is a critical issue that Moto cannot help with. Only full acceptance tests can confirm that Flintrock is behaving as expected, and it seems impractical to try to mock subcomponents like a host for more granular tests.
2. Moto will always be playing catchup with AWS's real behavior. The same goes for any other libraries which mock other critical endpoints that Flintrock interacts with, like an Amazon Linux host.
Instead of doing all this work to mock out AWS, Linux hosts, storage, etc. it seems better to just test against the real thing. Using t2.small instances, which is what the tests in this PR default to, the cost of a full batch of acceptance tests is roughly 4 instance-hours of t2.small, which is $0.104. Even as we add more tests, the cost is going to be less than a dollar.
These end-to-end tests are slow, but they test critical features in the only way that I can see is possible.

Using a real EC2 instance sounds good to me. There are scenarios where say you want to test if SSDs are coming up right or if all of the disks are getting formatted that'll be hard to do with t2.small. But to capture the most essentially features with t2.small sounds like a good idea.

I've been using m3.xlarge and sometimes even d2.xlarge instances to test the storage work in #51, but yeah for most things t2.small does the job.
Perhaps I can add storage tests that fail if a cluster with ephemeral storage is launched (e.g. d2.xlarge instances) but the storage doesn't come up correctly. With instances that have no ephemeral storage the tests always pass.
I'll look into that.

I've converted the lint tests from shell to Python, revamped the structure of the pytest-based tests, and added documentation.
A few items remain:

[ ] Testing operations against stopped clusters.
[ ] Running tests in parallel.

I think getting these tests to run in parallel in a sensible way via pytest and its xdist plugin will depend on some resolution to this issue.
Right now, using py.test -n 4 will spin up multiple instances of a given fixture (e.g. a running, t2.small cluster) which is wasteful and slow. What we want is each fixture to be spun up exactly once but in parallel (e.g. t2.small and m3.medium clusters get spun up once but in parallel). That's currently not possible.

I've created a proposal to improve how xdist distributes tests to workers. If implemented, it would give us a sane way to run Flintrock's tests in parallel using pytest.
https://github.com/pytest-dev/pytest-xdist/issues/18
That'll be a while in the making, though, so I'm gonna merge this is since everything else is working.


Fix waker behavior when invoked before a poll finishes

It's possible for a task's waker to be invoked in the middle of a call
to that task's poll by the executor. We had accounted for that
possibility if the task called its own waker, but that's not good
enough: the waker can escape to other threads that can invoke it before
poll finishes (e.g., if the task blocks to acquire a lock).
This change fixes the waker behavior by clarifying the semantics of a
call to wake: a task whose waker is invoked should not be blocked
when it next returns Pending to the executor, and should be woken if
that has already happened. To do this, we introduce a new Sleeping
state for tasks, that has the same semantics as Blocked but that is
recognized by waker invocations, which will only unblock a task in
Sleeping state. This also removes the special case "woken by self"
behavior -- being woken by any thread should be enough to trigger this
sleep logic.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

This PR reminds me -- an interesting use of Shuttle could be to warn if your poll function could ever lead to blocking as this may be undesirable.

I like this idea a whole bunch. Feels related to some of the recent clippy lints around holding a lock inside a future, e.g. https://github.com/rust-lang/rust-clippy/pull/5439.


When authenticating requests to the Twitter API v2 endpoints, you must use keys and tokens from a Twitter developer App that is attached to a Project. You can create a project via the developer portal.

I'm always get this error when using Bearer token.

When authenticating requests to the Twitter API v2 endpoints, you must use keys and tokens from a Twitter developer App that is attached to a Project. You can create a project via the developer portal.

What can I do?

I finally realized that X API must purchase Basic plan to retrieve posts.


Deploys hanging on "creating zip package..."

I'm seeing this on stable and insiders in WSL and SSH so it may be related to remote environments.

I noticed this on Visual Studio Online as well


Savon 2.3.0 causes "Requested value 'APIObject' was not found." error

Having switched to the Dot9Refactor branch, I'm still getting the error:
"Requested value 'APIObject' was not found."
This is the same error I got when trying to send a post request to a data extension using the master branch, and it is caused by the same test re-implemented using your Dot9Refactor branch.
Can you please do a proper test of the DataExtension post method against an actual live Exact Target account? Since the post test is the only one of my suite that's failing (all the rest are get) I'm still inclined to think that this is a bug with the FuelSDK-Ruby library. But I'd be happy to find out otherwise, that'd be easier to fix!

I am getting this same issue trying to create a new list.  When I installed savon in my Gemfile it installed 2.11.1 by default.  I also tried just installing savon 2.2 on the command line (after removing 2.11.1)
But I still get the same error about APIObject not found.
@body=
{:create_response=>
{:results=>
{:status_code=>"Error", :status_message=>"Requested value 'APIObject' was not found.", :ordinal_id=>"0", :new_id=>"0", :object=>{:partner_key=>nil, :object_id=>nil}},
:request_id=>"ff4d2256-dc36-4fb3-a6a2-7ab05b3ef494",
:overall_status=>"Error",
:@xmlns=>"http://exacttarget.com/wsdl/partnerAPI"}},
Not sure if there is something else obviously potentially going on or if this might be Savon related?

Hey there,
I don't know if this is still an issue, but I came across this problem and then fixed it today in my own implementation of the ExactTarget SOAP API (in Python, mind you).
The meaning of this error:
When you submit a request to ET's SOAP API you have to declare the type of the object and make sure it matches the expected format.  In most cases, if you screw up that format, ET will be very explicit about what the expected object was (i.e. "Requested value 'RetrieveRequest' was not found.") , but there are a few methods that aren't as strict and will accept multiple object types (Delete is the one that caught me out today), and in that case it gives the generic error for the superclass APIObject - "Requested value 'APIObject' was not found."
The solution:
I have no idea where this would be cropping up in the SDK, because I'm building my own, but basically I just had to set up a switch to determine the type of the object (usually just by passing in an object_type value) and then ensure that the correct object is created and sent to the SDK for each different ObjectType.

I had to deal with these guys on my previous job. It was horrible. I hope I never have to deal with ExactTarget or it's crappy and old SOAP API, along with their horrible support.

@c4collins are you perhaps planning to share your own implementation in future?