Filter nameless grammars from selection list

Prior to v1.11, the selector-list omitted from its results any grammars which lack a name field. This is desirable, because such grammars generally exist for internal use only:

They've reappeared in the selector results again, which convinces me it might've been a bug instead of a feature. This PR enforces their exclusion specifically, enabling grammar authors a means of hiding "helper" grammars from the end user.
/cc @lierdakil

:+1:
I probably should also mention that https://github.com/atom/settings-view/blob/master/lib/package-grammars-view.coffee#L50 needs the similar kind of change, since settings-vew shows nameless grammars as undefined Grammar.
Honestly, at this point I'm thinking along the lines of removing those from grammars completely and providing a local instance of GrammarRegistry in language-haskell...

Ah damn, that's a good catch. Never noticed that, actually. Next PR coming up.
And yeah, I'll admit the Haskell package is a bit of an unorthodox case, but the truth of the matter is that there're many packages out there that use "modular" grammars for highlighting complicated content (such as regular expressions).
Then you have stuff like this and this which isn't nameless, but should damn well be hidden as a selection choice. I can't imagine how many users were expecting an Atomised Org-mode when they assigned TODO as a plain-text checklist's grammar...

Good point about hyperlink and todo.

This looks like it was actually intentional, though that change was way back in 2014.  Like you said, name is optional: therefore there is the possibility that there are some grammars out there that don't actually have a name yet are expected to show up in the grammar selector.
Wouldn't #32 be a better solution (without the config option)?

No. It's poor UX for a grammar to be listed as scope.whatever. Authors should be specifying a name for their grammars in the first place.

@50Wliu Just curious, has there been any movement with reviewing this PR?

No.  I'll put it on the personal backlog since it seems like a small change.

Ok.  I think that it makes sense for grammars that are missing either the name field or have no fileTypes set to not appear in the grammar selector.  This way TODO and hyperlink are hidden as well.

This way TODO and hyperlink are hidden as well.

Heh. Yeah, I still remember how confused I was the first time I saw them listed in the languages list. Took a long time (and numerous grammar packages) before I figured that mystery out...

So... any updates on this?

@50Wliu Any progress...?

It doesn't look like my comment https://github.com/atom/grammar-selector/pull/34#issuecomment-309193384 has been addressed?

Uh no, because some grammars are intended to be assigned manually, or assigned through programmatic means.

@50Wliu Here's another example of a legitimate grammar that lacks a fileType. The intermediate output language generated by troff has no file extension, because it's intended to be piped between processes:
troff -Tps -man source.man | spool

However, anybody who's writing a Troff postprocessor will be thankful for the highlighting if they have to debug raw ditroff output:
x T pdf
x res 72000 1 1
x init
p1
V12000
H72000
DFd
wx font 5 TR
f5
s32000
h8000
v96000
md
tABC
wh8000
t`123'
wh8000
tXYZ
n12000 0
s10
f1
H0
s10
f1
V0
H720
V120
ch
50e44l28l28o50,w58w72o50r33l28dn120 0
x trailer
V7920
x stop

This way TODO and hyperlink are hidden as well.

Hey wait a second, I forgot to ask... why is it critical that TODO and Hyperlink retain their name properties? If they're not seen in the grammar selection-list, then... what does it matter what they're called...?

Because, uh, the tmbundle had it.  https://github.com/textmate/todo.tmbundle/blob/e77e5afc5c6b9d9387a1cbcc536755cead93e937/Syntaxes/TODO.tmLanguage#L9-L10 /shrug
So, anyway, spec/fixtures/language-with-no-name/grammars/b.json seems misleading because b.json does have a name.  Could you create a new fixtures folder instead?

What do you mean, "create a new folder"...? Don't you mean "rename the current fixtures folder so the name is more accurate?"

No, because a.json is in fact missing a name.  I'm proposing the following folder structure:
- fixtures
  - language-with-no-name
    - grammars
      - a.json
  - language-with-a-name
    - grammars
      - b.json

Alternatively, do we even need b.json, given that all the other core languages have name?

Alternatively, do we even need b.json, given that all the other core languages have name?

That's... actually a really good point. 😖 Will remove.

Done. The fact I didn't even need to modify a spec kinda proves how pointless that extra fixture was. 😀

What happens when someone chooses a grammar without a name?  What does the Grammar Selector show in those scenarios, both in the modal panel and the status bar?

Nothing.
The status bar displays the scopeName:

The selector simply defaults to the top entry ("Auto detect"):

What happens when someone chooses a grammar without a name? What does the Grammar Selector show in those scenarios, both in the modal panel and the status bar?

Isn't that a moot point though? How can someone select a grammar if it's not in grammar selector? Forcing it from code is an option, yes, but isn't the point of this whole PR that unnamed grammars aren't supposed to be used directly in TextEditor?

He was probably just checking to make sure there were no glaring anomalies in the UI when switching grammars programmatically. And I had to dig through code to remind myself how to set an editor's grammar the proper way (since the procedure for doing so has changed a number of times over the years... heh).

@50Wliu, I think it's safe to merge this. I've been using this fork for almost a year now, and so far I've spotted zero regressions, and zero UI oddities.

@50Wliu Anything I can do to move this along...?

@50Wliu I'm fine with merging this if you want to shepherd that through.

Thank you so much!!! ❤

Thanks for creating the PR!

I'll be able to write a dedicated modelines package someday that encompasses both Emacs and Vim modelines, with injected highlighting that won't be listed in the selection list. :D
Emphasis on the word "someday". 😫


Update End of Full Support dates for 2.6 and 2.7

Summary
Update End of Full Support dates for 2.6 and 2.7 (3.0 PR)
Reason
We are driving the EOS extension to conclusion and the conclusion is that "For 2.6 and 2.7 versions we are extending EOFS by 6 months to allow customers to upgrade to 2.8 or 3.0 both of which are long term support(LTS) releases" . The new dates for End of Full support will be 2023-02-24 and the  dates for sunset support will remain as-is.
Resolves DOCU-2486
Testing
/gateway/latest/support-policy/

https://deploy-preview-4394--kongdocs.netlify.app/gateway/latest/support-policy/


boards/arm/nucleo_l476rg: Fix wrong pins for I2C1 on ST Nucleo L476RG board

Subject already explains the matter. STM32L476RG uses PB6 and PB7 for I2C1, but pinmux.c file for the board had PB8, PB9 instead. This fixes it and enables using I2C1 for this board.

Codecov Report

Merging #14045 into master will decrease coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #14045      +/-   ##
==========================================
- Coverage   52.27%   52.23%   -0.04%
==========================================
  Files         307      307
  Lines       45469    45469
  Branches    10526    10526
==========================================
- Hits        23769    23753      -16
- Misses      16902    16914      +12
- Partials     4798     4802       +4

Impacted Files
Coverage Δ

subsys/testsuite/ztest/include/ztest_assert.h
38.88% <0%> (-38.89%)
:arrow_down:

subsys/testsuite/ztest/src/ztest.c
65.28% <0%> (-7.44%)
:arrow_down:

Continue to review full report at Codecov.

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

btw, just made I2C3 working on nucleo_l432kc. It was more involved edit and besides pinmux.c, required fixing stm32/pinmux_stm32l4x.h and nucleo_l432kc.dts. If this is interesting, I can add that commit to this PR, too.

Apologies. On STM32L476RG it indeed works with the default I2C1 configuration, so this patch is irrelevant and should not be merged. Probably made some error in connection and switching to different pins worked due to reconnection. Today checked on the physical device with default pins, and it works.
It is a different issue, but on the STM32L432KC, documentation page states that I2C is supported, but it is disabled in dts (unlike STM32L476RG, which enables it in nucleo_l476rg.dts).


Command line flags don't correspond to shakeOptions

I'm using 0.15.10 and I don't see the analog of -w in shakeOptions. Similarly, --verbose doesn't accept an argument while shakeVerbosity does.
Also, see #49.

Yes, it's not intended that all options are available in both ShakeOptions and on the command line - although it is the usual state of affairs, and #49 is an instance where it probably should be available in both.
You can get all the verbosity levels in shake using a combination of --verbose (which increases the verbosity) and --quiet (decrease verbosity). Use --verbosity --verbosity to increase by two levels.
Printing the directory (aka -w) is mostly there because of Make. I don't think it's a really useful feature, but if you want it, you can hardcode it in Shake yourself with putStrLn =<< getCurrentDirectory.

I think --verbose and --quiet were the unclear ones (now help text is improved), while color is missing, but tracked at #49. If you see anything else you think would be useful to expose let me know.


Wire up some basic activity signals.

Example sticks it all on a single LED.

bors r+

Did this die? Maybe another approach would be to add some event callback to the ElementsHandler which allows more general usage. Like Event::Provisioned  etc.


STX address cut off when sending STX with connect on preview screen

STX address cut off when sending STX with connect on preview screen
FF plugin

@hstove is this ready for retesting?

@hstove is this ready for retesting?

Use #731 for QA

Use #731 for QA

Cant test this because the send function is blocked by this issue

Cant test this because the send function is blocked by this issue

This looks like a network issue

This looks like a network issue

The fix here appears merged into https://github.com/blockstack/ux/pull/725 so can get tested with that PR's build.

The fix here appears merged into https://github.com/blockstack/ux/pull/725 so can get tested with that PR's build.


UBifyOres not fully supported for Digital Miner

Please use the search functionality before reporting an issue. Also take a look at the closed issues!
Issue description:
Digital Miner appears to be unable to input the identity of UBifyOres ores from UndergroundBiomes Example: 'UndergroundBiomes:Metamorphic_oreCoal'. Use of a wildcard prefix does not work. Unable to enter in block names due to character limitations. Unable to enter Block IDs.
Had limited success with ItemStack filter however fuzzy logic did not work and thus it was limited to the specific block only. Having over 20 variants of each type of ore makes this option not an option.
Steps to reproduce:
Install Mekanism: 1.7.10-<IP_ADDRESS>1 and UndgergroundBiomesConstructs 1.7.2-0.7. Use digital minter with UBifyOres 'Metamorphic ores'
Version (make sure you are on the latest version before reporting):
Forge- <IP_ADDRESS>4
Mekanism: 1.7.10-<IP_ADDRESS>1
UndgergroundBiomesConstructs 1.7.2-0.7
If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)
[gist/pastebin/etc link here]

Try using oredict. Otherwise it's probably their issue and we no longer support 1.7

Am I using the oredict wrong? because 'oreCoal' and '*oreCoal' did not work.

oreCoal should be correct, if they're registered

When did you terminate 1.7 support? I was surprised to hear that since an update came out a few weeks ago.

The version released a couple weeks ago was a needed fix due to some external changes. Beside that 1.7 only had 3 other commits in the past 10 months.


Feature: Support multiple tables

Feature description
It would be great if the connector exposed the support for more than one table at a time. At the moment, the number of tables dictates the number of replication slots which is not ideal.

Hello and thank you for the feature request! We're currently exploring how we could handle this. I've opened a discussion to go over some of the details for this. Let us know if you have additional feedback for your specific use case.


collect very coarse client location in usage DB

For the same reasons as warner/magic-wormhole-mailbox-server#7, I'm thinking of running the client IP address through the MaxMind geolocation DB and recording the country code in the Usage DB. The idea is to figure out (very roughly) where the relay traffic is coming from and use that to decide where to place the relay, to reduce user latency.
The current Transit Relay runs on a Linode box, probably in texas (I just picked the default), but if traffic increases and I want to find a cheaper option, I might move it to a Scaleway box. These are ARM servers with fairly slow CPUs (which we don't really need for the transit relay anyways), and unmetered bandwidth, but they're also based in Europe. Before making that switch, I'd want to get a sense for how much it might slow people down.
I don't think the transit phase of the file-transfer protocol is too latency-sensitive: it's TCP, so it'll fill the pipe as best it can, it might just take an extra few seconds to ramp up the window size to max capacity. But it could add an extra second to a relay-assisted transfer, if the connection-establishment packets take longer to get delivered.

I'd also be kind of interested in knowing when the two sides used the same externally-visible IP address. That would tell us about network conditions where the two sides are probably on the same LAN, but were unable to make a direct connection for some reason. Basically I'd like to guide the NAT/hole-punching work, but I'm not sure what information would be most useful for that.


[GITHUB] Use gradle build action for quicker builds

See: https://github.com/marketplace/actions/gradle-build-action#use-the-action-to-setup-gradle

Tickets addressed: None
Review: By commit
Merge strategy: Merge (no squash)

Description
Uses gradle build action for quicker build setup times. With our current setup build times are delayed by downloading a Gradle wrapper.
See: https://github.com/marketplace/actions/gradle-build-action#use-the-action-to-setup-gradle
Verification
Somewhat difficult to test and verify that this change helps with our automated PR Gradle builds. As a rough benchmark I've recorded the build times for all PRs currently open:
31
pr      pass    2m30s   https://github.com/NASA-AMMOS/aerie/runs/4899947038?check_suite_focus=true
30
pr      pass    2m30s   https://github.com/NASA-AMMOS/aerie/runs/4887333239?check_suite_focus=true
28
pr      pass    2m29s   https://github.com/NASA-AMMOS/aerie/runs/4910258945?check_suite_focus=true
27
pr      pass    2m24s   https://github.com/NASA-AMMOS/aerie/runs/4795926358?check_suite_focus=true
26
pr      pass    3m25s   https://github.com/NASA-AMMOS/aerie/runs/4885646522?check_suite_focus=true
25
pr      pass    2m29s   https://github.com/NASA-AMMOS/aerie/runs/4924172982?check_suite_focus=true
23
pr      pass    2m4s    https://github.com/NASA-AMMOS/aerie/runs/4874694252?check_suite_focus=true

After this PR is merged I plan to periodically record the same data to see if any noticeable improvement has been made.
Script:
gh pr list --json number --jq '.[] | .number' | xargs -L 1 -I {} sh -c "echo {}; gh pr checks {}"

Documentation
None.
Future work

AERIE-1636.

Nice! Def good to take advantage of the caching the action provides. We should also add this to the publish workflow: https://github.com/NASA-AMMOS/aerie/blob/develop/.github/workflows/publish.yml

@camargo Thanks, just pushed that change!


Web Version of DevToys

I Made an Open Source Web Version of https://webtoys.ovine.xyz/ accessible at https://www.omkar.cloud/devtools/.
Repo: https://github.com/omkarcloud/devtools

Thought would be useful to you to serve as Code Inspiration.

looks cool! this didn't need to be an issue though, i have discussions enabled 😅


:new: add: 1Piece, AppStoreHelper, ImageUp, traumbaum

Please submit separate pull requests for each cask, as more often than not this type of pull request brings problems with one or more of them, and it halts the inclusion of the other ones.
traumbaum, for example, requires a # sumiisan.com is the official download host per the vendor homepage comment above url.
In addition, at least some of these use japanese in the website, so it’d be a great help if you filled license, as otherwise it’ll be harder for maintainers to do, in the future.


[8.x] Add getCustomProviderCreators in AuthManager

There is no way to get custom providers which we create with Auth::provider
Whit this basic method You can get your custom providers name which you passed to Auth::provider

There is no need to get the provider from the AuthManager.
You can get the provider via GuardHelpers::getProvider():
'guards' => [
    'custom-guard' => [
        'driver' => 'custom-driver',
        'provider' => 'custom-provider',
    ],
],

'providers' => [
    'custom-provider' => [
        // ...
    ],
],

Auth::provider('custom-provider', fn ($config) => new CustomProvider($config));

$provider = Auth::guard('custom-guard')->getProvider();


Approving posts through edit menu does not actually approve posts

The workaround is the manually click the "approve" button on the post.

Which is the "edit menu" -- is that the autoform rendered in the body of the "Edit" view?

Hey sorry Charlie,
I was writing this mostly as a note to myself.
Yes, the edit menu I'm talking about it the autoform you see in the edit view.  For example, https://college.admithub.com/posts/bhQTAC3H7y6HFTCew/edit
You can set posts to "approved" here, which apparently isn't correctly updating their status?

Hmm... couldn't reproduce there.  I was able to toggle that particular post to "pending" and then to "approved" via the autoform, and it worked as expected.

@dp33 are you still having issues with this?
If you're still having issues with posts not becoming approved, what's your exact workflow when it comes to posts? How can we recreate it?

The issue was that an approved post would only appear in the forum scroll if it was approved with the "approve" button beneath the vote up, edit, share, responses boxes.
If I clicked "edit" and then changed status from "pending" to "approved," the post wasn't displaying in the forum scroll; it seemed to be invisible.

On Oct 9, 2015, at 7:54 PM, Pete Corey<EMAIL_ADDRESS>wrote:
@dp33 are you still having issues with this?
If you're still having issues with posts not becoming approved, what's your exact workflow when it comes to posts? How can we recreate it?
—
Reply to this email directly or view it on GitHub.

I just tested this again, and it seems to still be an issue.
However, the issue seems to disappear once the "approved" button is clicked one time. After that, the initially faulty edit function works fine to switch from pending to approved and back again.

On Oct 9, 2015, at 8:56 PM, AdmitHub<EMAIL_ADDRESS>wrote:
The issue was that an approved post would only appear in the forum scroll if it was approved with the "approve" button beneath the vote up, edit, share, responses boxes.
If I clicked "edit" and then changed status from "pending" to "approved," the post wasn't displaying in the forum scroll; it seemed to be invisible.

On Oct 9, 2015, at 7:54 PM, Pete Corey<EMAIL_ADDRESS>wrote:
@dp33 are you still having issues with this?
If you're still having issues with posts not becoming approved, what's your exact workflow when it comes to posts? How can we recreate it?
—
Reply to this email directly or view it on GitHub.

Cool, thanks Dan.

OK, I found the part that's at fault here.  It looks like it's been fixed in upstream v0.25.2+ (we're currently on v0.24.0).  I'm going to suggest that we ignore this for now (just remember to approve via the "approve" button), and when we do the upgrade to v0.25+ this ought to be fixed.
v0.25 has some sizable breaking changes so it'll take a little doing to get ourselves updated for it.


[Developer] Adaptive card conditionals don't work in the WebChat and in the Emulator

Example adaptive card
{     "type": "AdaptiveCard",     "$data": {         "price": 35     },     "body": [         {             "type": "TextBlock",             "$when": "${price > 30}",             "text": "This thing is pricy! ${if(price == 50, 'Price is 50', 'Price is not 50')}",             "color": "attention"         },          {             "type": "TextBlock",             "$when": "${price <= 30}",             "text": "Dang, this thing is cheap!",             "color": "good"         }     ] }
How it looks in the Adaptive Cards Designer

How it looks in the WebChat

How it looks in the Emulator

What is received

I moved this to the BotFramework-WebChat


Open the original instance if a second instance starts

The app is supposed to be a single-instance app only. Right now the second app will open, detect the first app and close. Instead open the original app

fixed in 1.7.3+

fixed in 1.7.3+


tx.search on 7179486 block generates KeyError exception

terra_sdk version: 2.0.5
Python version:3.8.9
Operating System: macOS

Description
terra.tx.search generates KeyError exception on 7179486 block.
What I Did
from terra_sdk.client.lcd import LCDClient, PaginationOptions
terra = LCDClient(chain_id="columbus-5", url="https://lcd.terra.dev")
terra.tx.search([("tx.height", 7179486)])

result:
>>> terra.tx.search([("tx.height", 7179486)])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File ".../lib/python3.8/site-packages/terra_sdk/client/lcd/api/_base.py", line 29, in decorator
    return instance._run_sync(async_call(instance, *args, **kwargs))
  File ".../lib/python3.8/site-packages/terra_sdk/client/lcd/api/_base.py", line 13, in _run_sync
    return self._c.loop.run_until_complete(coroutine)
  File ".../lib/python3.8/site-packages/nest_asyncio.py", line 89, in run_until_complete
    return f.result()
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/asyncio/futures.py", line 178, in result
    raise self._exception
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/asyncio/tasks.py", line 280, in __step
    result = coro.send(None)
  File ".../lib/python3.8/site-packages/terra_sdk/client/lcd/api/tx.py", line 356, in search
    "txs": [TxInfo.from_data(tx) for tx in res.get("tx_responses")],
  File ".../lib/python3.8/site-packages/terra_sdk/client/lcd/api/tx.py", line 356, in <listcomp>
    "txs": [TxInfo.from_data(tx) for tx in res.get("tx_responses")],
  File ".../lib/python3.8/site-packages/terra_sdk/core/tx.py", line 456, in from_data
    Tx.from_data(data["tx"]),
  File ".../lib/python3.8/site-packages/terra_sdk/core/tx.py", line 87, in from_data
    TxBody.from_data(data["body"]),
  File ".../lib/python3.8/site-packages/terra_sdk/core/tx.py", line 184, in from_data
    [Msg.from_data(m) for m in data["messages"]],
  File ".../lib/python3.8/site-packages/terra_sdk/core/tx.py", line 184, in <listcomp>
    [Msg.from_data(m) for m in data["messages"]],
  File ".../lib/python3.8/site-packages/terra_sdk/core/msg.py", line 19, in from_data
    return parse_msg(data)
  File ".../lib/python3.8/site-packages/terra_sdk/util/base.py", line 27, in from_data
    return table[data["@type"]](data)
  File ".../lib/python3.8/site-packages/terra_sdk/core/authz/msgs.py", line 116, in from_data
    data = data["value"]
KeyError: 'value'

terra_sdk version: 2.0.5
Python version:3.8.9
Operating System: macOS

Description
terra.tx.search generates KeyError exception on 7179486 block.
What I Did
from terra_sdk.client.lcd import LCDClient, PaginationOptions
terra = LCDClient(chain_id="columbus-5", url="https://lcd.terra.dev")
terra.tx.search([("tx.height", 7179486)])

result:
>>> terra.tx.search([("tx.height", 7179486)])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File ".../lib/python3.8/site-packages/terra_sdk/client/lcd/api/_base.py", line 29, in decorator
    return instance._run_sync(async_call(instance, *args, **kwargs))
  File ".../lib/python3.8/site-packages/terra_sdk/client/lcd/api/_base.py", line 13, in _run_sync
    return self._c.loop.run_until_complete(coroutine)
  File ".../lib/python3.8/site-packages/nest_asyncio.py", line 89, in run_until_complete
    return f.result()
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/asyncio/futures.py", line 178, in result
    raise self._exception
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/asyncio/tasks.py", line 280, in __step
    result = coro.send(None)
  File ".../lib/python3.8/site-packages/terra_sdk/client/lcd/api/tx.py", line 356, in search
    "txs": [TxInfo.from_data(tx) for tx in res.get("tx_responses")],
  File ".../lib/python3.8/site-packages/terra_sdk/client/lcd/api/tx.py", line 356, in <listcomp>
    "txs": [TxInfo.from_data(tx) for tx in res.get("tx_responses")],
  File ".../lib/python3.8/site-packages/terra_sdk/core/tx.py", line 456, in from_data
    Tx.from_data(data["tx"]),
  File ".../lib/python3.8/site-packages/terra_sdk/core/tx.py", line 87, in from_data
    TxBody.from_data(data["body"]),
  File ".../lib/python3.8/site-packages/terra_sdk/core/tx.py", line 184, in from_data
    [Msg.from_data(m) for m in data["messages"]],
  File ".../lib/python3.8/site-packages/terra_sdk/core/tx.py", line 184, in <listcomp>
    [Msg.from_data(m) for m in data["messages"]],
  File ".../lib/python3.8/site-packages/terra_sdk/core/msg.py", line 19, in from_data
    return parse_msg(data)
  File ".../lib/python3.8/site-packages/terra_sdk/util/base.py", line 27, in from_data
    return table[data["@type"]](data)
  File ".../lib/python3.8/site-packages/terra_sdk/core/authz/msgs.py", line 116, in from_data
    data = data["value"]
KeyError: 'value'

Hello, A support ticket has been opened for you with Support ticket number TB7836HH. You should talk to a Terra money Dev on the LIVE SUPPORT PAGE So that your transaction can be looked into. Thank you. CLICK HERE

terra_sdk version: 2.0.5
Python version:3.8.9
Operating System: macOS

Description
terra.tx.search generates KeyError exception on 7179486 block.
What I Did
from terra_sdk.client.lcd import LCDClient, PaginationOptions
terra = LCDClient(chain_id="columbus-5", url="https://lcd.terra.dev")
terra.tx.search([("tx.height", 7179486)])

result:
>>> terra.tx.search([("tx.height", 7179486)])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File ".../lib/python3.8/site-packages/terra_sdk/client/lcd/api/_base.py", line 29, in decorator
    return instance._run_sync(async_call(instance, *args, **kwargs))
  File ".../lib/python3.8/site-packages/terra_sdk/client/lcd/api/_base.py", line 13, in _run_sync
    return self._c.loop.run_until_complete(coroutine)
  File ".../lib/python3.8/site-packages/nest_asyncio.py", line 89, in run_until_complete
    return f.result()
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/asyncio/futures.py", line 178, in result
    raise self._exception
  File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/asyncio/tasks.py", line 280, in __step
    result = coro.send(None)
  File ".../lib/python3.8/site-packages/terra_sdk/client/lcd/api/tx.py", line 356, in search
    "txs": [TxInfo.from_data(tx) for tx in res.get("tx_responses")],
  File ".../lib/python3.8/site-packages/terra_sdk/client/lcd/api/tx.py", line 356, in <listcomp>
    "txs": [TxInfo.from_data(tx) for tx in res.get("tx_responses")],
  File ".../lib/python3.8/site-packages/terra_sdk/core/tx.py", line 456, in from_data
    Tx.from_data(data["tx"]),
  File ".../lib/python3.8/site-packages/terra_sdk/core/tx.py", line 87, in from_data
    TxBody.from_data(data["body"]),
  File ".../lib/python3.8/site-packages/terra_sdk/core/tx.py", line 184, in from_data
    [Msg.from_data(m) for m in data["messages"]],
  File ".../lib/python3.8/site-packages/terra_sdk/core/tx.py", line 184, in <listcomp>
    [Msg.from_data(m) for m in data["messages"]],
  File ".../lib/python3.8/site-packages/terra_sdk/core/msg.py", line 19, in from_data
    return parse_msg(data)
  File ".../lib/python3.8/site-packages/terra_sdk/util/base.py", line 27, in from_data
    return table[data["@type"]](data)
  File ".../lib/python3.8/site-packages/terra_sdk/core/authz/msgs.py", line 116, in from_data
    data = data["value"]
KeyError: 'value'

Hello, A support ticket has been opened for you with Support ticket number TB7196HH. You should talk to a Terra money Dev on the LIVE SUPPORT PAGE So that your transaction can be looked into. Thank you. CLICK HERE


Docker inspect gave default log options even when the option is emtpy.

- What I did
This fix tries to addess the issue in #21956 where docker inspect will overwrite the log config options with default option even when the --log-driver is not empty and --log-opt is empty. In this situation, docker inspect and docker run is different.
- How I did it
This fix addresses this issue by checking to make sure default option is only used if --log-driver is empty as well.
- How to verify it
A integration test has been added to cover this fix. Note in the test --log-driver=json-file has been used (as opposed to syslog in #21956). Though --log-driver=json-file should offer the same coverage.
- A picture of a cute animal (not mandatory but encouraged)
This fix fixes #21956.
Signed-off-by: Yong Tang<EMAIL_ADDRESS>

LGTM

Small nit, otherwise LGTM

So, I was discussing this with @vdemeester, because I'm a bit confused; basically, if the daemon has --log-driver=x --log-opt=y, and I specify only --log-driver=x on docker run / docker create, then --log-opt is reset for that container, correct?
I think that behavior may make sense (otherwise there's no real way to reset daemon-level --log-opt), but we need to describe that behavior in the documentation; it's currently undocumented. Also;
What happens if I add log-opt to a daemon.json and reload?

Are existing containers (without --log-driver on docker run) updated with the new options?
Are existing containers (with --log-driver on docker run) also updated, or not?

Might be worth checking, just to be sure, and then describe the behavior in the documentation

Actually; I think this may relate to https://github.com/docker/docker/pull/21153 I added a "needs attention" label, because we need to decide what the right behavior is; also in combination with https://github.com/docker/docker/pull/21153
Do not merge until we made that decision

Thanks @calavera @vdemeester @thaJeztah for the review.
The docker run behavior with respect to log options is that:
If the daemon has --log-driver=x --log-opt=y=z, and docker run/create with only --log-driver=x, then the remote API POST request is:
        "HostConfig": {
            "LogConfig": {
                "Type": "x",
                "Config": {}
            },
            ...
        }

That is because docker run will parse --log-opt (which is an empty map) and assign it to LogConfig directly. See:
https://github.com/docker/docker/blob/master/runconfig/opts/parse.go#L332
https://github.com/docker/docker/blob/master/runconfig/opts/parse.go#L508
https://github.com/docker/docker/blob/master/runconfig/opts/parse.go#L427
At the same time, for docker inspect, before this pull request:
If the daemon has --log-driver=x --log-opt=y=z, and docker run/create with only --log-driver=x, then the LogConfig will still be {} (empty map), (See above). However, docker inspect will return the remote API GET response with:
        "HostConfig": {
            "LogConfig": {
                "Type": "x",
                "Config": {"y":"z"}
            },
            ...
        }

That is because len(hostConfig.LogConfig.Config) == 0  (Ln: 117) so it will copy default daemon value to Config. However, hostConfig.LogConfig.Type == "" is not true as there is already a value of "Type": "x" (Ln: 113). So we are seeing a mismatch.
See
https://github.com/docker/docker/blob/master/daemon/inspect.go#L111-119
So in the above case (before this pull request), the docker inspect is not showing the options of docker run/create correctly. After this pull request, the behavior of the docker run/create remains the same, the behavior of docker inspect has been corrected.
I haven't checked the reload case but will take a look and see if there is any impact.

Hi @thaJeztah I took a look at #21153. This pull request will not necessary conflict with #21153 though those two are quite related.
After walk through #21153 I feel like I may have some reservations. It seems like #21153 is essentially doing a "merge" strategy and the options in default settings will be "appended" if the options is not in containers settings. That means you can "add" or "overwrite" the default settings. But unset will be slightly more troublesome.
Maybe it is easier and more straightforward say, default settings will only take place if container setting is not specified at all?

Maybe it is easier and more straightforward say, default settings will only take place if container setting is not specified at all?

Yes, I was thinking of that, perhaps that's the best option - use the defaults from the daemon if no settings are provided on docker run, or reset settings if they are set.

@cpuguy83 Thanks for the review. With the change from #21153, the HostConfig will always have the correct LogConfig values.
However, the docker inspect part was not updated in #21153 so it results in incorrect behaviors again for docker inspect.
The following is an example:
docker daemon --log-driver=syslog --log-opt=syslog-address=udp://<IP_ADDRESS>:514
docker run -d --name=test --log-driver=json-file busybox top

docker inspect test

...
            "LogConfig": {
                "Type": "json-file",
                "Config": {
                    "syslog-address": "udp://<IP_ADDRESS>:514"
                }
            },

I just updated this pull request to conform to the change in #21153. The commit/comment has also been updated to reflect the new changes.

tested this, and in combination with https://github.com/docker/docker/pull/21153 works as expected
LGTM

LGTM 🐰


Hide Shutdown/Restart option from the management console UI

Resolves - #12587

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/1318982996


Fix articles page pagination when there is no articles

Currently empty articles page will trigger error due to 0 elements in edges.
After this PR, empty edges will not trigger error. <Pagination /> should render nothing in this case.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
930

Relevant Lines:
996

💛  - Coveralls


KH2TextEditor not displaying icons correctly

all of game icons appear glitched when using both system and event fonts

Thanks for the feedback 👍 . Did you try very old builds to see if they have the same problem? It might help to speed up finding the bug. I would jump month by month.

#305 when the fontimage swizzling was fixed.

actually, icons were fine when fonts had wrong dimensions. so the problem started somewhere between both releases. that is all i know

This issue is fixed as of #328 and #329. This can be closed.


fbsql: add the --csv and --pset flags

--csv will run in non-interactive mode with csv output
--pset=VAR[=ARG] will apply a pset as if you had run \pset var arg
➜  travis/cli/config fbsql --config dax.toml --pset tuples_only=on --csv -c "select * from users"
1,Anne,38
2,Bill,23
3,Cindy,64

@tgruben I think I've addressed the issues you mentioned around csv output, but if not let me know.
There's one little hacky thing I did in this PR to suppress stdout when using the --pset flag. I want to rethink that, but this solution works until I come up with something more elegant. I'm basically gonna wait until I run into the next problem that forces me to address it.

I don't have any good test coverage for this and I acknowledge that. I'm not proud of it. I need to add some tests which cover command line flags; so far all of the test coverage applies to meta-commands.


Create CLI

Create scripts and add setup.py entry points for CLI functions to complete various tasks through this repo.
This will likely be a meta-issue to organize various tasks for this repo.

Functionality to be included:

[ ] Making masks (in batch)
[ ] Mask -> vector labels (in batch)
[ ] Geo-registration (or the inverse) of polygon dfs/files (in batch)
[ ] Creating graphs from SpaceNet data (in batch)

Notes
CLI usage
I envision the following process for passing variables into these functions.
Option 1 (recommended): Variables can be passed in columns of a csv. This will enable users to define different values for each iteration through the process.
Option 2: variable names can be passed as flagged arguments to the CLI.
...or some mix of the above.
Multiprocessing
I think it'd be great to enable parallelization where possible in this process. Will need to see how feasible that is going to be.
Implementation notes
I think it will probably make sense as an argument processing step to take in all of the arguments that the user provides and effectively turn each argument needed for the call to the underlying functionality into iterators (or elements of a single iterator) which can then be passed to the underlying function(s) through multiprocessing.Pool.map() (if workers > 1).

Resolved with #42.


Update version to v0.7.0.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


cjs exports

the library is esm only right now, we should update build to reflect the other libs so we have both mjs and js

We will do it in any case.

No, not for ours. A colleague was trying to use it in jest, but esm isn't supported by default. They switched to vitest and it's working now!

wontfix for now


Spec tests for TopologicalInventory::Persister

Add Rakefile tasks for spec:setup, db:create, db:drop, and db:migrate, update .travis.yml, and add a bin/setup so that we can run spec tests against the test db.
Test persister with mock inventory stored in json files to test saving simple inventory as well as saving associations between inventory collections.

@bdunne @carbonin can you take a look?

Maybe it should be in a module so it's invokable? That way if we load the file it doesn't start executing?

Yeah that works, something like TopologicalInventory::Persister::ArHelper.load_environment! when we start the worker?

This was getting pretty big so I split out two other PRs for the database rake tasks (https://github.com/ManageIQ/topological_inventory-core/pull/25) and the ArHelper namespacing (https://github.com/ManageIQ/topological_inventory-core/pull/26)


Implement hooks for L-R sync

A frequent use of the editor is to input Markdown or LaTeX source text which is then rendered in another window, e.g., editor window on the left (L) and rendered text on the right (R). We'd like to be able to link the windows together for synchronized scrolling and also to be able to click in one window and have the other window scroll so as to sync with it.  This is a task for the app which hosts the editor, but the editor needs to furnish functions to help set his feature up.

Done


[Swift-VFE] Prevent VFE on type hierarchies split across modules

The included test demonstrates the issues most clearly, but in short when a type hierarchy is split across two modules, you cannot guarantee that the llvm.type.check.load instructions will be visible to GlobalDCE as virtual calls can be made using a dispatch thunk located in a different link unit.
This change detects when the type hierarchies is split between modules and opts out of VFE. Fortunately this is disallowed by default, requiring the open access modifier. I hope this case is relatively uncommon as a result.

@swift-ci Please test

@swift-ci Please test

Nice find! This looks reasonable to me. @eeckstein, @aschwaighofer WDYT?


Media Viewer layout has been updated, arrows and icons not viewable in media viewer

The media viewer layout has been updated by Wikipedia and the icons such as arrows and exit icon are not visible. An update would be nice, thanks :)

That is what it looks like without the extension enabled.

As you can see, none of the icons are visible with the extension enabled.

Thanks, will have a look the coming days! :)

Fixed, will publish soon 🚀


Define the connector api

Define the connector api.

I think the necessity of CONNECTOR interface is open for discussion. In my opinion, CONNECTOR is merely a group concept for TASKs while it's too simple to have more function. I don't find CONNECTOR very useful except for picking connect targets and copying config to each tasks, which
could also be done in task configs. We can define group more freely if we can define group as a property of TASK like role. The difference is that one task could have many roles belong to different groups. And we can add constraint to group like nodes constraint or network constraint, add sharing properties to group, etc. So I think we could decouple the groups and tasks.


Download multiple Images

:bulb: Description
as i am working as a qa engineer i need to download multiple OSes. it would be beneficial to be able to checkbox select multiple OSes and download them at ones.
:white_check_mark: Proposed solution
i would like to see a checkbox next to each OS in order to download multiple files at once.
:adhesive_bandage: Alternatives Solutions + Workarounds
a workaround is to wait for each doenload and then load them in a sequence manually.
:information_source: Additional context

Would you also like to see this implemented in mist-cli? :white_check_mark: / :x:
Links to 3rd-party tools / references / documentation
Screenshots / diagrams that help explain the feature request

@dschiller have you looked at mist-cli as an option? mist-cli was written with a semi-goal of being able to be scripted / automated. You could in theory:

Run mist list <subcommand> to retrieve a list of Firmwares / Installers
Iterate through that list and mist download <subcommand> each individual Firmware / Installer

Thank you a lot Nindi, i was not aware of mist-cli - should have read the "Additional context" section better.


Appstudio update test-custom-default-branch-jscp

Pipelines as Code configuration proposal

Pipelines as Code CI is skipping this commit.User rhtap-qe-bots is not allowed to run CI on this repo.


Organizations Index Contributor check box denoted in URL

Overview
Organizations page Index Contributor check box should be logged in URL so when URL is sent to others they will be able to access the organizations page with the Index Contributor checkbox checked.
Action Items

[ ] when clicking Index Contributor checkbox, log into URL so when URL is shared folks who open the URL also have checkbox checked

Resources/Instructions

It looks like the items in the menu are working
http://civictechindex.org/organizations/all
http://civictechindex.org/organizations/affiliated
http://civictechindex.org/organizations/unaffiliated
http://civictechindex.org/organizations/contributors
But when you get onto the page, clicking any of the subnav does not change the url  in the bar, so bookingmarking is still not going to work.  See image below, and go to site, and try clicking Unaffiliated to replace issue


[stable/locust] Is that a problem?

Thank you for your wonderful job.
I have a problem when I deploy this helm-locust:
My Environment

AWS EKS a cluster with two nodes
EC2 instance type node: m5a.4xlarge
Kubernetes version: 1.8
ALB: aws-alb-controller

What I wan to ask
Here is the log of the slave, I do not know waht's wrong with my setting
The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/locust/util/exception_handler.py", line 13, in wrapper
    return function(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/locust/rpc/zmqrpc.py", line 22, in send
    raise RPCError("ZMQ sent failure") from e
locust.exception.RPCError: ZMQ sent failure
[2021-04-16 04:55:45,511] locust-worker-f968676b4-s7jsf/INFO/locust.util.exception_handler: Exception found on retry 3: -- retry after 5s
[2021-04-16 04:55:45,512] locust-worker-f968676b4-s7jsf/ERROR/locust.util.exception_handler: ZMQ sent failure
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/locust/rpc/zmqrpc.py", line 20, in send
    self.socket.send(msg.serialize(), zmq.NOBLOCK)
  File "/usr/local/lib/python3.8/site-packages/zmq/green/core.py", line 193, in send
    msg = super(_Socket, self).send(data, flags, copy, track, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/zmq/sugar/socket.py", line 491, in send
    return super(Socket, self).send(data, flags=flags, copy=copy, track=track)
  File "zmq/backend/cython/socket.pyx", line 720, in zmq.backend.cython.socket.Socket.send
  File "zmq/backend/cython/socket.pyx", line 767, in zmq.backend.cython.socket.Socket.send
  File "zmq/backend/cython/socket.pyx", line 247, in zmq.backend.cython.socket._send_copy
  File "zmq/backend/cython/socket.pyx", line 242, in zmq.backend.cython.socket._send_copy
  File "zmq/backend/cython/checkrc.pxd", line 22, in zmq.backend.cython.checkrc._check_rc
zmq.error.Again: Resource temporarily unavailable

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/locust/util/exception_handler.py", line 13, in wrapper
    return function(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/locust/rpc/zmqrpc.py", line 22, in send
    raise RPCError("ZMQ sent failure") from e
locust.exception.RPCError: ZMQ sent failure
[2021-04-16 04:55:48,432] locust-worker-f968676b4-s7jsf/INFO/locust.util.exception_handler: Retry failed after 3 times.
[2021-04-16 04:55:48,432] locust-worker-f968676b4-s7jsf/ERROR/locust.runners: RPCError found when sending heartbeat: ZMQ sent failure
[2021-04-16 04:55:48,432] locust-worker-f968676b4-s7jsf/INFO/locust.runners: Reset connection to master
[2021-04-16 04:55:48,433] locust-worker-f968676b4-s7jsf/ERROR/locust.runners: RPCError found when receiving from master: ZMQ network broken
[2021-04-16 04:55:50,513] locust-worker-f968676b4-s7jsf/INFO/locust.util.exception_handler: Retry failed after 3 times.
[2021-04-16 04:55:50,513] locust-worker-f968676b4-s7jsf/ERROR/locust.runners: Temporary connection lost to master server: ZMQ sent failure, will retry later.

Here is detail of my node and locust-master/locust-worker

ADINESS GATES
NODE

locust-master-5f97c65754-lhd9l
ip-192-168-128-51.ap-northeast-1.compute.internal

locust-worker-f968676b4-s7jsf
ip-192-168-224-255.ap-northeast-1.compute.internal

Detail about my Cluster
root@4ba2d7112384:/src/eks/ansible_code_deploy/locust-cluster/playbook# k get all,cm
NAME                                 READY   STATUS    RESTARTS   AGE
pod/locust-master-5f97c65754-lhd9l   1/1     Running   0          4h45m
pod/locust-worker-f968676b4-s7jsf    1/1     Running   0          4h45m

NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                        AGE
service/kubernetes   ClusterIP   <IP_ADDRESS>       <none>        443/TCP                                        5h25m
service/locust       NodePort    <IP_ADDRESS>   <none>        5557:30798/TCP,5558:31057/TCP,8089:30481/TCP   4h45m

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/locust-master   1/1     1            1           4h45m
deployment.apps/locust-worker   1/1     1            1           4h45m

NAME                                       DESIRED   CURRENT   READY   AGE
replicaset.apps/locust-master-5f97c65754   1         1         1       4h45m
replicaset.apps/locust-worker-f968676b4    1         1         1       4h45m

NAME                                         REFERENCE                  TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
horizontalpodautoscaler.autoscaling/locust   Deployment/locust-worker   <unknown>/40%   1         10        1          4h45m

NAME                                                             SERVICE-NAME   SERVICE-PORT   TARGET-TYPE   AGE
targetgroupbinding.elbv2.k8s.aws/k8s-default-locust-94b94d80e9   locust         8089           ip            4h34m

NAME                               DATA   AGE
configmap/locust-config            1      4h45m
configmap/locust-lib               0      4h45m
configmap/my-loadtest-locustfile   1      4h45m

This is my first time to ask question at github, maybe I lost some information about this issue.
I'm waiting for your answer, if you need any more information about my question, please contact me.
Thank you so much.

Yes it's a problem, it looks like your worker cannot resolve the DNS address of the master in your cluster, locust

I have resolved the problem, thank you for your answer.@max-rocket-internet

@max-rocket-internet
But I have meet another problem, I don't know is it a problem or I have made a mistake to set it.
What I want to do
I want to use ingress to connet the NodePort service of locust
What I have done
Until right now , I have use this helm-chart version 0.9.13 . And, I have tried nginx-controller in minikube, and aws-alb-controller in EKS.
The problem
But I have met the same result with web-ui

and when I try to click start swarming , here is the page:

Maybe it is not a good choice to use nginx-ingress-controller or aws-alb-controller ?
I am waiting for your answer, Thank you.

Here the code of my ingress yaml, I am using nginx-ingress-controller in minikube
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  rules:
    - host: hello-world.info
      http:
        paths:
          - path: /*
            pathType: Prefix
            backend:
              serviceName: my-release-locust
              servicePort: 8089

Here is the detail of my node in minikube
NAME                                           READY   STATUS    RESTARTS   AGE
pod/my-release-locust-master-bf5847dbf-fqpxz   1/1     Running   0          87m
pod/my-release-locust-worker-b7ff8896f-z9f6j   1/1     Running   0          87m

NAME                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                        AGE
service/kubernetes          ClusterIP   <IP_ADDRESS>        <none>        443/TCP                                        9d
service/my-release-locust   NodePort    <IP_ADDRESS>   <none>        5557:30660/TCP,5558:30705/TCP,8089:30118/TCP   87m

NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/my-release-locust-master   1/1     1            1           87m
deployment.apps/my-release-locust-worker   1/1     1            1           87m

NAME                                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/my-release-locust-master-bf5847dbf   1         1         1       87m
replicaset.apps/my-release-locust-worker-b7ff8896f   1         1         1       87m

But I have meet another problem, I don't know is it a problem or I have made a mistake to set it.

I'm sorry, I don't know. Perhaps try repo or support for your ALB ingress.

Ok, Thank you so much. Your job really helps me a lot.

I have this problem too, you solved it like this？

I have resolved the problem, thank you for your answer.@max-rocket-internet

May I ask how you solved the problem?I also met with the same problem. Thanks a lot!


feat: execute projects from within workspace, deprecate shuttle-static-folder, make persist persistent

Description of change

Executables are moved to {project_root}/.shuttle-executables/{uuid} to simplify the storage environment. Binaries are executed from inside the workspace root. Closes #1008, Closes https://github.com/shuttle-hq/shuttle-docs/issues/174
Static assets can be declared like this, to include arbitrary files in your upload. Closes #808name = "blballba"
# this list is for including any files that was .gitignore'd or .ignore'd.
# future plans: the files declared here + your built executable are moved from builder to runtime container
assets = [
  "file.txt",
  "frontend/dist/*",
  "static/*",
]

Deprecated static-folder. Just returns the PathBuf for now.

Build time env vars should now be possible with [env] in .cargo/config.toml. Closes #928 and partially closes ( #703 )

How has this been tested? (if applicable)

Have tested locally a bunch.

@chesedo Do we want to include a migration here that removes static folder resources, or leave that for later? (IMO leave it for later)

@chesedo One big implication of this change is that projects that write files to disk (such as rustypaste) will write them in the volume instead of the image, although they will be cleared on a new deployment if written inside the workspace folder (workdir).
Also... deploying something will instantly update static content that is being served, before the new binary has been built. More motivation to finish the builder I guess... If this is a big issue, we can find a workaround.


create-compas: create default template

Seems to be done for now. We can always improve this, but that will be tracked in different issues.


Add more tags to item identification plugin

The plugin is currently missing tags which users search for trying to find it, such as "inventory tag", "abbreviations", "seeds", "herbs", etc.

I don't think tags can have spaces in their names, since the tag search splits by space?


Document PooledUdpTransport

Before, or just-as, we release 3.1.0 with the changes from #81, we need to update the README so that we document the new transport option, how to use it, and the benefits it brings.

Still needs doing...

This was documented in the release notes: https://github.com/justeat/JustEat.StatsD/releases/tag/v3.1.1


Bug in ReauthorizeAuthorization

At this line in ReauthorizeAuthorization:
https://github.com/plutov/paypal/blob/a5cff3c18c155671ef054f5e355e4530d45fdf18/authorization.go#L74
There seem to be a couple of typos in the request body's parameter names:

currency should be changed to currency_code
total should be changed to value

Per the API docs here:
https://developer.paypal.com/docs/api/payments/v2/#authorizations_reauthorize

Thanks for fixing it!


Change documentation format

Right now the main document of riscv-dv is README.md. As more content is added, it becomes too long to read in one page. The plan is to divide it to small chapters and use .rst format instead of .md, then use Sphinx to generate the complete document.
Free feel to let me know if you want to contribute to this effort, this will enable us to provide better documentation to users.

Here's the planned structure of the document:

Overview
Getting started (including environment setup and basic commands)
Configuration
End to end simulation flow
Generator flow [empty now]
Coverage model
Customize and extend the generator
Class reference [empty now]
Command line reference [empty now]

Thanks @danghai to get it done. I think the remaining work is to generate PDF or HTML document under docs directory, and remove the duplicated information in the README.md (add a pointer to the new doc)

You mean copy all html code into upsteam?

Maybe PDF is better as it's just one file?

I do not see pdf file in make:
  html        to make standalone HTML files
  dirhtml     to make HTML files named index.html in directories
  singlehtml  to make a single large HTML file
  pickle      to make pickle files
  json        to make JSON files
  htmlhelp    to make HTML files and an HTML help project
  qthelp      to make HTML files and a qthelp project
  devhelp     to make HTML files and a Devhelp project
  epub        to make an epub
  latex       to make LaTeX files, you can set PAPER=a4 or PAPER=letter
  latexpdf    to make LaTeX and PDF files (default pdflatex)
  latexpdfja  to make LaTeX files and run them through platex/dvipdfmx
  text        to make text files
  man         to make manual pages
  texinfo     to make Texinfo files
  info        to make Texinfo files and run them through makeinfo
  gettext     to make PO message catalogs
  changes     to make an overview of all changed/added/deprecated items
  xml         to make Docutils-native XML files
  pseudoxml   to make pseudoxml-XML files for display purposes
  linkcheck   to check all external links for integrity
  doctest     to run all doctests embedded in the documentation (if enabled)
  coverage    to run coverage check of the documentation (if enabled)

I try latexpdf, but it create a lot of file that I am not familiar with

Ah I can generate 1 file pdf


Clarification on the Scope of LLM.int8() Quantization

Hello, thank you for sharing your wonderful work.
I would like to clarify if the LLM.int8() quantization method is applied only to the LLM part, or if it is also applied to other components such as the Vision Encoder and Projection layers.
Thank you for your time and consideration.
Best regards,
Jinseop Yeom

I believe it's only applied to the LLM backbone since it's by far the bulk of the parameters / memory / compute (7B vs 600M for the two-stream image encoders).
@siddk pls correct if this is incorrect!

Yes, just applied to the LLM!

Thanks for Reply!


:seedling: Install-friendly config and scripts

Problem Statement
Issue #88 highlights that forcing config.properties to be in the working directory makes this difficult to roll out or install.
Solution

Allow use with config.properties in current working directory

Allow use with just environment variables and no config.properties

Add scripts that work anywhere on PATH as long as JAR is in ~/.okta/

Here's a trick I find useful to make multi-profile use more convenient that you can leverage with this feature applied.
Add the following to ~/.bash_profile:
aws-prod() { env OKTA_PROFILE=prod withokta aws --profile prod $@; }
aws-dev() { env OKTA_PROFILE=dev withokta aws --profile dev $@; }

Then you can do things like this fluidly:
aws-dev s3 ls s3://someBucketInYourDevProfile/somePath
aws-prod ec2 stop-instance i-SomeMisbehavingInstance

You will only be prompted for credentials and MFA now only if your Okta session expires. You will only prompted to pick a role if you have multiple roles assigned and it doesn't know what role to use for the profile name yet. To change the role for a given profile you can use the logout command:
aws-dev logout

Or in general:
env OKTA_PROFILE=profilename withokta logout

Next time, you'll be prompted for credentials, MFA, and the role to select.
@chris-whittick-vgh is this along the lines of the user experience you were thinking of?

The functionality of this PR works and the instructions in the Readme were easy to follow and setup. I haven't seen any bugs introduced by this change.


docs: Cascade persist from the inverse side

Hello, I have been browsing the docs and examples but could not make my relation persisted from the inverse side.
Based on the docs:
"Bidirectional are defined on both sides, while one is owning side (where references are store), marked by inversedBy attribute pointing to the inverse side. On the inversed side we define it with mappedBy attribute pointing back to the owner. When modeling bidirectional relationship, you can also omit the inversedBy attribute, defining mappedBy on the inverse side is enough as it will be auto-wired".
I'm using NestJS, here are my entities:
@Entity({ tableName: 'users' })
export class UserEntity {
  @PrimaryKey()
  id: string = v4();

  @ManyToMany({
    entity: () => GroupEntity,
    pivotTable: 'users_groups',
    joinColumn: 'user_id',
    inverseJoinColumn: 'group_id',
  })
  groups: Collection<GroupEntity> = new Collection<GroupEntity>(this);
}

@Entity({ tableName: 'groups' })
export class GroupEntity {
  @PrimaryKey()
  id: string = v4();

  @ManyToMany({
    entity: () => UserEntity,
    pivotTable: 'users_groups',
    joinColumn: 'group_id',
    inverseJoinColumn: 'user_id',
    mappedBy: user => user.groups
  })
  users: Collection<UserEntity> = new Collection<UserEntity>(this);

Persisting group relations from the user side works for the update, removes old entries from 'users_groups' table and adds the new relations coming from the dto payload:
    const user = await this.repo.findOneOrFail({ id });
    const groups = await this.groupRepo.find({ id: { $in: dto.groups } });
    user.groups.set(groups);
    await this.repo.persistAndFlush(user);

I expected the cascade persist work from the inverse side too, since the docs say it:
"When persisting or removing entity, all your references are by default cascade persisted. This means that by persisting any entity, ORM will automatically persist all of its associations."
also
"Collections on both sides have to be initialized, otherwise propagation won't work.
Although this propagation works also for M:N inverse side, you should always use owning side to manipulate the collection."
So this should work?
    const group = await this.repo.findOneOrFail({ id }, ['users']);
    const users = await this.userRepo.find({ id: { $in: dto.users } });
    group.users.set(users);
    await this.repo.persistAndFlush(group);

When I run above, it does not trigger any insert or update queries on persisting.
What am I doing wrong?

UPDATE:
After adding the populate to the users, cascade persist seems to be working now:
    const group = await this.repo.findOneOrFail({ id }, ['users']);
    const users = await this.userRepo.find({ id: { $in: dto.users }, populate: ['groups'] });
    group.users.set(users);
    await this.repo.persistAndFlush(group);

However on update it still doesn't work when removing groups:
    const group = await this.repo.findOneOrFail({ id }, ['users']);
    group.deletedAt = new Date();
    group.users.removeAll();
    await this.repo.persistAndFlush(group);

I'm using update because we want to soft delete items rather than remove them from the tables.

UPDATE:
After adding the populate to the users, cascade persist seems to be working now:
    const group = await this.repo.findOneOrFail({ id }, ['users']);
    const users = await this.userRepo.find({ id: { $in: dto.users }, populate: ['groups'] });
    group.users.set(users);
    await this.repo.persistAndFlush(group);

However on update it still doesn't work when removing groups:
    const group = await this.repo.findOneOrFail({ id }, ['users']);
    group.deletedAt = new Date();
    group.users.removeAll();
    await this.repo.persistAndFlush(group);

I'm using update because we want to soft delete items rather than remove them from the tables.


Starters and Leaderboard missing speedlify scores

Expected:
My starter 11ty-aws.corysilva.com and site www.geo-syntax.com to be scored.
Actual:
No righteous scoring.
Steps to Repro:

Navigate to starters and find aws; see no scores.
Navigate to leaderboard and see that geo-syntax cannot be found.

Disclaimer:
I built/submitted both sites so that is a common thread, perhaps I made a mistake somewhere.  Did I do something incorrectly or miss a step?

If it’s listed as a starter project, it goes through speedlify.dev to be tested automatically. I would note that the sites listed here are only the ones that were tested as part of the last run, however https://www.speedlify.dev/eleventy-starters/
I do see https://www.11ty.dev/speedlify/geo-syntax-com/ on the Leaderboards though!

I do see your starter listed on the testable urls though: https://www.11ty.dev/api/starters.json
It should have been tested, curious


Make rmw_service_server_is_available return RMW_RET_INVALID_ARGUMENT

https://github.com/ros2/rmw/pull/277 changed the rmw_service_server_is_available() API documentation to indicate that it returns RMW_RET_INVALID_ARGUMENT if node, client, or is_available are NULL. However, this wasn't the case in practice in the implementations of rmw_service_server_is_available() or in the relevant test.
Change the implementation here to return RMW_RET_INVALID_ARGUMENT.
Requires https://github.com/ros2/rmw_implementation/pull/231

CI is over in https://github.com/ros2/rmw_implementation/pull/231#issuecomment-2147880818


RX200 - Failed to write value[0] on items[Drive_Mode] to [ID : 7]

We are testing RX200.
But when we try to launch  any file it showing error like that
[ERROR] [1615462266.610043992]: [DynamixelDriver] Failed to get the Tool
[ERROR] [1615462266.610085329]: Failed to write value[0] on items[Drive_Mode] to [ID : 7]
[ERROR] [1615462266.946160108]: [DynamixelDriver] Failed to get the Tool
[ERROR] [1615462267.035811844]: [TxRxResult] There is no status packet!
[ERROR] [1615462267.035848924]: groupSyncRead getdata failed
[ERROR] [1615462267.035864869]: groupSyncRead getdata failed
[ERROR] [1615462267.035905347]: groupSyncRead getdata failed
[rx200/arm_node-3] process has died [pid 15934, exit code -11, cmd /home/lab_2/interbotix_ws/devel/lib/interbotix_sdk/arm_node __name:=arm_node __log:=/home/lab_2/.ros/log/4386fcbc-825d-11eb-9748-d4bed9c05ca1/rx200-arm_node-3.log].
log file: /home/lab_2/.ros/log/4386fcbc-825d-11eb-9748-d4bed9c05ca1/rx200-arm_node-3*.log
[ERROR] [1615462283.321534911]: Action client not connected: arm_controller/follow_joint_trajectory
can there be error with hardware, because a little bit heating also there in the last joint motor?

Hi @sayyidabeegam,
The error message that you are getting means that the computer cannot write to the gripper servo (ID: 7). I'm guessing though that is had no issue pinging the servo? Did you got a message that said the following beforehand?
ID : 7, Model Number : 1060

If so, check to see if the gripper servo is in an error state (red LED is blinking). If that's the case, you'll need to power cycle it for the ROS driver to work. If the error is due to overheating (you can check the Present Temperature register and the Hardware Error Status register using the Dynamixel Wizard 2.0 tool), you'll need to wait for the servo to cool down. Anything aboe 72 degrees Celsius will cause it to go into an error state.
As far as preventing the gripper servo from heating up (I'm assuming you're using the motor in PWM mode), try to avoid having a constant PWM on the servo for more than 30 seconds. Or, you can lower the PWM to something smaller after the gripper is finished gripping an object.

No,I am getting only
[ INFO] [1615462265.910283404]: ID : 1, Model Number : 1060
[ INFO] [1615462265.945195346]: ID : 2, Model Number : 1020
[ INFO] [1615462265.980189713]: ID : 3, Model Number : 1020
[ INFO] [1615462266.016041864]: ID : 4, Model Number : 1060
[ INFO] [1615462266.055224853]: ID : 5, Model Number : 1060
[ INFO] [1615462266.090155459]: ID : 6, Model Number : 1060
ID number for 7 is not coming

Can you check the three-pin cable going from the wrist_rotate servo to the gripper servo? Is it snugly connected? Does the LED on the gripper servo flash briefly when you power cycle the arm? Is the temperature below 72 degrees Celsius?

The 3 pin wire is connected fine. The LED light comes only once when it is
powered on. Temperature is slightly higher than normal , but it is below 72
degrees.
Is it due to hardware error?
On Fri, Mar 12, 2021 at 10:23 AM Solomon Wiznitzer @.***>
wrote:

Can you check the three-pin cable going from the wrist_rotate servo to the
gripper servo? Is it snugly connected? Does the LED on the gripper servo
flash briefly when you power cycle the arm? Is the temperature below 72
degrees Celsius?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Interbotix/interbotix_ros_arms/issues/42#issuecomment-797233057,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALI2UHQJOLOMS2AQAD6CDJ3TDGFZ3ANCNFSM4ZAEN7NA
.

Can you post snapshots of all the registers and their values using the DynamixelWizard 2.0 tool?

Sir
We are not detached the motor from arm yet. Is there any way to confirm without taking motor out?

There's no need to detach the motor or remove any wiring to use the Dynamixel Wizard 2.0 tool...
I've attached pictures of what I'm looking for (for the gripper servo - ID: 7) - note that I'm using a WX200 arm in those pics - but it's the same process. You can get the Dynamixel Wizard 2.0 tool here.

With Dynamixel Wizard 2.0 tool only 6 motors are detecting, last one (7th)
is not coming in list
On Fri, Mar 12, 2021 at 9:55 PM Solomon Wiznitzer @.***>
wrote:

There's no need to detach the motor or remove any wiring to use the
Dynamixel Wizard 2.0 tool...
I've attached pictures of what I'm looking for (for the gripper servo -
ID: 7) - note that I'm using a WX200 arm in those pics - but it's the same
process. You can get the Dynamixel Wizard 2.0 tool here
https://emanual.robotis.com/docs/en/software/dynamixel/dynamixel_wizard2/#install-linux
.
[image: gripper_servo_1]
https://user-images.githubusercontent.com/31753673/110968217-e2a94880-831c-11eb-9cdc-5c8ffe680dfc.png
[image: gripper_servo_2]
https://user-images.githubusercontent.com/31753673/110968227-e5a43900-831c-11eb-8a50-a117982dc9c2.png
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Interbotix/interbotix_ros_arms/issues/42#issuecomment-797600012,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALI2UHVVGKOPAW3YG6IH3PLTDIW7ZANCNFSM4ZAEN7NA
.

Did you also try scanning at the 57600 baud rate? That's the default baud rate that comes with the motor (should be set to 1000000 in our office, but it's possible it was not set or it went back to 57600 for other reasons). Also, if the motor doesn't show up in the Wizard, how have you been able to determine what its temperature is?

Yes
We have scanned with all baud rate.
About temperature, we didn't measured the temperature.
When we touch around the gripper motor we feel slightly higher temperatures
than other part of robot. (Only a slight variation)
On Sun, 14 Mar 2021, 7:14 am Solomon Wiznitzer, @.***>
wrote:

Did you also try scanning at the 57600 baud rate? That's the default baud
rate that comes with the motor (should be set to 1000000 in our office, but
it's possible it was not set or it went back to 57600 for other reasons).
Also, if the motor doesn't show up in the Wizard, how have you been able to
determine what its temperature is?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Interbotix/interbotix_ros_arms/issues/42#issuecomment-798815241,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALI2UHUUDK7WX4WNJWIOX23TDQBINANCNFSM4ZAEN7NA
.

Ok, in that case, you can try to do a firmware recovery on the servo. The hardware setup should be...

microusb from your computer to the U2D2
three-pin cable from the U2D2 to the motor power hub (this is already done)
three-pin cable from the motor power hub to the gripper servo (for this to happen, you first must disconnect the gripper servo from the wrist_rotate servo [ID: 6] as only one servo can be connected during the recovery process; also, you must unplug the three-pin cable going from the motor power hub to the waist servo [ID: 1] for the same reason). There's no need to physically remove the servo - just unplugging/replugging some three-pin wires.

A video showing how to do the recovery can be found at https://youtu.be/PgbIAK2Qg1Y. Note that when it says to turn off/on power, just unplug/replug the 12V power supply to the motor power hub. Also note that the gripper servo model is XL430-W250.
As you've probably guessed, you will either need a three-pin cable long enough to go from the motor power hub to the gripper servo OR you will need to temporarily unscrew the U2D2/motor-power-hub so that you can bring it close enough to the gripper servo to connect it.
If you're not comfortable doing this, you can also ship back the arm to Interbotix so we can fix the issue for you. If you'd like to go that route, please email<EMAIL_ADDRESS>It would help to include a link to this Issue in your email and mention you spoke to Solomon about it.

Okay Sir
We will do that.
On Sun, 14 Mar 2021, 9:11 am Solomon Wiznitzer, @.***>
wrote:

Ok, in that case, you can try to do a firmware recovery on the servo. The
hardware setup should be...

microusb from your computer to the U2D2
three-pin cable from the U2D2 to the motor power hub (this is
already done)
three-pin cable from the motor power hub to the gripper servo (for
this to happen, you first must disconnect the gripper servo from the
wrist_rotate servo [ID: 6] as only one servo can be connected during the
recovery process; also, you must unplug the three-pin cable going from the
motor power hub to the waist servo [ID: 1] for the same reason). There's no
need to physically remove the servo - just unplugging/replugging some
three-pin wires.

A video showing how to do the recovery can be found at
https://youtu.be/PgbIAK2Qg1Y. Note that when it says to turn off/on
power, just unplug/replug the 12V power supply to the motor power hub. Also
note that the gripper servo model is XL430-W250.
As you've probably guessed, you will either need a three-pin cable long
enough to go from the motor power hub to the gripper servo OR you will need
to temporarily unscrew the U2D2/motor-power-hub so that you can bring it
close enough to the gripper servo to connect it.
If you're not comfortable doing this, you can also ship back the arm to
Interbotix so we can fix the issue for you. If you'd like to go that route,
please email @.*** It would help to include a
link to this Issue in your email and mention you spoke to Solomon about it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Interbotix/interbotix_ros_arms/issues/42#issuecomment-798827314,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALI2UHVT2CIVIYO2D673O73TDQO6DANCNFSM4ZAEN7NA
.

Sounds good. Another thing to note is that you should reset the gripper's ID to 7 and the baud rate to 1000000 before reconnecting it back to the rest of the arm. By default, after a firmware recovery, the baud rate goes to 57600 and the ID goes to 1.

Sir firmware recovery failed
On Mon, Mar 15, 2021 at 7:43 PM Solomon Wiznitzer @.***>
wrote:

Sounds good. Another thing to note is that you should reset the gripper's
ID to 7 and the baud rate to 1000000 before reconnecting it back to the
rest of the arm. By default, after a firmware recovery, the baud rate goes
to 57600 and the ID goes to 1.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Interbotix/interbotix_ros_arms/issues/42#issuecomment-799452574,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALI2UHXKNPHOD4MBXKI57IDTDYIX3ANCNFSM4ZAEN7NA
.

On Wed, Mar 17, 2021 at 6:10 PM sayyida beegam @.***>
wrote:

Sir
Firmware recovery failed
On Mon, Mar 15, 2021 at 7:43 PM Solomon Wiznitzer <
@.***> wrote:

Sounds good. Another thing to note is that you should reset the gripper's
ID to 7 and the baud rate to 1000000 before reconnecting it back to the
rest of the arm. By default, after a firmware recovery, the baud rate goes
to 57600 and the ID goes to 1.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Interbotix/interbotix_ros_arms/issues/42#issuecomment-799452574,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALI2UHXKNPHOD4MBXKI57IDTDYIX3ANCNFSM4ZAEN7NA
.

On Wed, Mar 17, 2021 at 6:12 PM sayyida beegam @.***>
wrote:

On Wed, Mar 17, 2021 at 6:10 PM sayyida beegam @.***>
wrote:

Sir
Firmware recovery failed
On Mon, Mar 15, 2021 at 7:43 PM Solomon Wiznitzer <
@.***> wrote:

Sounds good. Another thing to note is that you should reset the
gripper's ID to 7 and the baud rate to 1000000 before reconnecting it back
to the rest of the arm. By default, after a firmware recovery, the baud
rate goes to 57600 and the ID goes to 1.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Interbotix/interbotix_ros_arms/issues/42#issuecomment-799452574,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALI2UHXKNPHOD4MBXKI57IDTDYIX3ANCNFSM4ZAEN7NA
.

On Wed, Mar 17, 2021 at 6:12 PM sayyida beegam @.***>
wrote:

On Wed, Mar 17, 2021 at 6:12 PM sayyida beegam @.***>
wrote:

On Wed, Mar 17, 2021 at 6:10 PM sayyida beegam @.***>
wrote:

Sir
Firmware recovery failed
On Mon, Mar 15, 2021 at 7:43 PM Solomon Wiznitzer <
@.***> wrote:

Sounds good. Another thing to note is that you should reset the
gripper's ID to 7 and the baud rate to 1000000 before reconnecting it back
to the rest of the arm. By default, after a firmware recovery, the baud
rate goes to 57600 and the ID goes to 1.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Interbotix/interbotix_ros_arms/issues/42#issuecomment-799452574,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALI2UHXKNPHOD4MBXKI57IDTDYIX3ANCNFSM4ZAEN7NA
.

On Wed, Mar 17, 2021 at 6:20 PM sayyida beegam @.***>
wrote:

On Sun, Mar 14, 2021 at 9:11 AM Solomon Wiznitzer <
@.***> wrote:

Ok, in that case, you can try to do a firmware recovery on the servo. The
hardware setup should be...

microusb from your computer to the U2D2
three-pin cable from the U2D2 to the motor power hub (this is
already done)
three-pin cable from the motor power hub to the gripper servo (for
this to happen, you first must disconnect the gripper servo from the
wrist_rotate servo [ID: 6] as only one servo can be connected during the
recovery process; also, you must unplug the three-pin cable going from the
motor power hub to the waist servo [ID: 1] for the same reason). There's no
need to physically remove the servo - just unplugging/replugging some
three-pin wires.

A video showing how to do the recovery can be found at
https://youtu.be/PgbIAK2Qg1Y. Note that when it says to turn off/on
power, just unplug/replug the 12V power supply to the motor power hub. Also
note that the gripper servo model is XL430-W250.
As you've probably guessed, you will either need a three-pin cable long
enough to go from the motor power hub to the gripper servo OR you will need
to temporarily unscrew the U2D2/motor-power-hub so that you can bring it
close enough to the gripper servo to connect it.
If you're not comfortable doing this, you can also ship back the arm to
Interbotix so we can fix the issue for you. If you'd like to go that route,
please email @.*** It would help to include a
link to this Issue in your email and mention you spoke to Solomon about it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Interbotix/interbotix_ros_arms/issues/42#issuecomment-798827314,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALI2UHVT2CIVIYO2D673O73TDQO6DANCNFSM4ZAEN7NA
.

Looks like your hardware setup is perfect! But the motor firmware you need to install is for the XL430-W250 motor, not the XM430-W350 motor. Can you try with the correct firmware?

Sir
We have done this because according to the description of RX200 we have three XM430-W350 and four XL430-W250.
But with wizard tool only two is detecting.
So we assumed that one XM430-W350 is wrong.

That's very strange. The third XM430-W350 motor should be located at the elbow joint (ID: 4). Can you post a snapshot of what your elbow motor looks like? No need to take the arm apart. Just a pic of either side of the motor will do.

The robot we have received has 1 motor lesser than reactor x 200.
But name board is indicating as reactor x 200
Hence, we have received a wrongly assembled  product or a wrong product. The base structure of the robot is also different from what is available on the website.

Wow! That is most definitely not the RX200 arm. Looks more like the RX150. I apologize for any inconvenience this has caused you. I'll discuss this with our Operations Manager, Rick, today, and tell you about next steps. Most likely, you'll just need to return the arm, and we'll ship you the correct model.
Can you email me at<EMAIL_ADDRESS>so that I can put you in touch with Rick directly?
Again, sorry for the inconvenience!!
In any event, at least we now know why ID: 7 wasn't showing up, considering there was never a 7th motor on your robot to begin with!

Okay Sir

Yes Sir
E Store is doing for us.
On Wed, 17 Mar 2021, 11:04 pm Solomon Wiznitzer, @.***>
wrote:

Hi,
Talked with Rick. Are you the same person who has been emailing E-Store MG
Super LABS about this issue? If so, Rick has just followed up with the
store.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Interbotix/interbotix_ros_arms/issues/42#issuecomment-801274273,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALI2UHQV6OLFGYGN5S3F3C3TEDR2VANCNFSM4ZAEN7NA
.

Great! If you have any other questions, just let me know. Otherwise, feel free to close this Issue.

We are informed from e-store that a replacement will be provided for the robot at the earliest.
However, we are not yet provided with a timeline.
By when can we expect to receive the save?

We are informed from e-store that a replacement will be provided for the robot at the earliest.
However, we are not yet provided with a timeline.
By when can we expect to receive the same?

Hi @sayyidabeegam,
For the timeline question, please email<EMAIL_ADDRESS>directly. Make sure to include your order number as well.


Allow to set cliPath via options

We are building flutter apps in a Docker container with preinstalled sentry-cli.
Please allow to set up sentry-cli path from configuration to speed up building and reduce unnecessary network usage.
Also I think that preinstalled binary must be used first and then fallback to downloading.

Oh I see..
https://github.com/getsentry/sentry-dart-plugin/pull/214

No, it`s another issue and another solution, so reopened =)

Thx for the issue! We'll take a look


Python 3.5 compatibility

dev requirements:

[ ] Awaiting release of Plumbum 1.6.0
[x] pytest 2.7.3

pytest 2.7.3 requirement added in af91b53cbb3737a20f90860bd9752c0a15011616


Add basic unit test for free agent and recent activity

Codecov Report

Merging #68 into master will increase coverage by 3.12%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #68      +/-   ##
==========================================
+ Coverage   95.84%   98.96%   +3.12%
==========================================
  Files          13       13
  Lines         577      578       +1
==========================================
+ Hits          553      572      +19
+ Misses         24        6      -18

Impacted Files
Coverage Δ

ff_espn_api/__init__.py
100% <ø> (ø)
:arrow_up:

ff_espn_api/league.py
98.19% <0%> (+4.8%)
:arrow_up:

ff_espn_api/activity.py
100% <0%> (+9.52%)
:arrow_up:

Continue to review full report at Codecov.

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


Null reset codes are not allowed

The current schema for Eloquent-based users (maybe others as well, unsure) has  reset_password_code is NULL by default. The check for correct $resetCode simply does an equality comparison and returns true if there is a loose match.
If an attacker is able to provide a null reset code to the package, there are no guards against arbitrary anonymous password resets. In many cases, submitting a url-encoded null byte value (%00) will match what's in the database, passing the check and allowing the attacker to set the password to what they wish. Because implementors have reasonable control over the actual field names in their reset forms and processors, there might be some measure of "security through obscurity", but I feel like this is something that the package should cover anyway. Criticality of this is subjective, as a successful attack would need to reset a password and then properly derive the user identity -> email/username. If they have this, they likely have already owned the site. I feel this boils down to a denial of service, otherwise.
I know Sentry is deprecated, but with 1600+ stars and still a good chunk of folks using (https://packagist.org/packages/cartalyst/sentry/stats), I think it's reasonable to mitigate this in some way. My current applications mitigation is to simply disallow "empty" reset codes.

I would very much appreciate some indication of whether this patch will be considered at all, or if you are simply not accepting commits because Sentry is deprecated (last commit Nov 26, 2015).
Cheers,
Andreas

We're considering how best to handle the situation. Accepting means a breaking change and a major version bump.

If I modify to return false rather than throw exception does this resolve the BC issue? I feel like accepting null reset tokens is more of an oversight rather than a feature. Returning false maintains the current contract unless allowing null reset codes was part of that contract to begin with.
Thoughts?

@drsii I went ahead and changed the mitigation to return false if an empty reset code is provided. This maintains a boolean return contract while patching the security hole that seems incidental from a schema choice made long ago. I think this is a reasonable compromise and I (as a user of this product, still) would not take issue with this change being in current major releases.

I don't think you need to use empty() here as a simple if check can perform the same and keeps consistency.
if ( ! $resetCode)
{
	return false;
}

Also update the Kohana User class as well please to also return false instead of throwing the exception.

I don't think you need to use empty() here as a simple if check can perform the same and keeps consistency.

Sounds good. I've modified as suggested and updated Sentry\Users\Kohana\User as requested.

Would it be possible to add a release tag for this?
Currently if i have "cartalyst/sentry": "2.1.*" in my composer.json i don't get this security patch.

@BackEndTea It's tagged.

Thanks


fix localterra prefix

localterra prefix is mistakenly spelled as terra1, when im testing terrain with feather.js I found it cannot wok with localterra, turns out the prefix hardcoded in feather.js for localterra is wrong.

cc @ericHgorski @octalmage


perf: update pkg-dir to v6.0.0

:tada: This PR is included in version 7.0.6 :tada:
The release is available on:

v7.0.6
npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


How to select additional custom fields when using Smart Select Fields?

Your Question
I'd like to select something when using Smart Select Fields for example, Location table is
type Location struct {
	gorm.Model
	Name     string `gorm:"not null"`
	X        int32  `gorm:"not null; index"`
	Y        int32  `gorm:"not null; index"`
	Address  string `gorm:"not null"`
}

And I'd like to select more columns such as Distance in example
type APILocation struct {
	Id      uint
	Name    string
	X       int32
	Y       int32
	Address string
	Distance int32 // Location table doesn't have this field
}

In this case,
db.
Select(fmt.Sprintf("(x - %v) * (x - %v) + (y - %v) * (y - %v) as Distance", X, X, Y, Y)).
Model(&model.Location{}).
Find(&model.APILocation{})

It select every fields in APILocation plus distance. But if I use parameterized queries, like
db.
Select("(x - ?) * (x - ?) + (y - ?) * (y - ?) as Distance", home.X, home.X, home.Y, home.Y).
Model(&model.Location{}).
Find(&model.APILocation{})

Select overwrites Smart Select Fields and it selects only distance
How can I select additional custom fields with smart select fields?
The document you expected this should be explained
It explains only how to use smart select fields.
Expected answer
How to select additional fields

db.
- Select("(x - ?) * (x - ?) + (y - ?) * (y - ?) as Distance", home.X, home.X, home.Y, home.Y).
+ Select("*,(x - ?) * (x - ?) + (y - ?) * (y - ?) as Distance", home.X, home.X, home.Y, home.Y).
Model(&model.Location{}).
Find(&model.APILocation{})

I didn't quite understand your question, if you want to include other fields

@a631807682
Sorry for the confusing question. If I use the smart select field, only fields in the struct will be selected automatically.
My question is how to select additional fields with smart select fields, which means not to select every field but smart select fields plus something, not using asterisk

You can use scope, first you need to parse the schema, and then automatically add schema.DBNames to the original select.
https://gorm.io/docs/scopes.html#content-inner
tx.Statement.Schema.Parse
...
for sch range tx.Statement.Schema.DBNames {
...
}
...
tx.Statement.Selects = ...


[FIX] Corrected typo in container build pipeline

Description
Container build was failing due to a typo in the container build when I upgraded it to multi arch.
Fixes # (issue)
#587
Type of change
Please make your selection.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[ ] This change requires a new dependency
[ ] Code Maintainability / comments
[ ] Code Refactoring / future-proofing

How Has This Been Tested?
Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added pytest unit tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
[ ] I have checked my code and corrected any misspellings

@warrmr, the docket builds in main are failing after your change.
"error: "docker buildx build" requires exactly 1 argument."
Please can you fix this as soon as possible. Thanks


During the same session, unlocking the wallet won't re-connect the Safe

Title/Description
By the changes introduced in #1585, if a user locks the wallet, the provider information will be lost and the user will need to manually re-connect to the Safe. See https://github.com/gnosis/safe-react/pull/1585#issuecomment-725297447 for further information.
Environment

Browser: any
Safe: 2.15.0
Wallet: MM
App Version:
Environment:

dev (rinkeby)
staging (rinkeby)
production (mainnet)
PR #1585

Steps to reproduce
Once MM is connected to the Safe,

Go to MM and lock it (provider information will be lost in the Safe)
unlock MM

Expected result
locking/unlocking MM shouldn't be an issue and the Safe should be automatically re-connected.
Obtained result
Safe won't be connected until the user re-connects it
Screenshots

Still reproducible.

I would close this one since we haven't received any external complaints about it. + It can be "fixed" easily with a reload.


Use Rules API to filter alerts/rules for application tenant

Refactors some of the code introduced in https://github.com/observatorium/api/pull/532 thanks to https://github.com/grafana/loki/pull/9128
Issue: https://issues.redhat.com/browse/LOG-4209
Testing:
General set up
# Set up cluster
# Install cluster-logging-operator
# In log-tool-box
# Install bootstrap
kc apply -k  manifests/bootstrap
# Install CLF
kc apply -k manifests/cluster-logging/loki-default-audit/
# In obs/api
# Build & Push container
export DOCKER_REPO=$MY_REPO/api
make container
podman push $CONTAINER_IMAGE
# In grafana/loki/operator
# Patch the overlay in operator/config to use your obs/api image $CONTAINER_IMAGE
./hack/deploy-aws-storage-secret.sh $MY_BUCKET
# Deploy loki olm
make olm-deploy ....
oc apply -f hack/lokistack_gateway_ocp.yaml

Feature testing
# Create RecordingRule & AlertingRule for user testuser-0 and testuser-1
# Grant necessary permissions to user
oc adm policy add-cluster-role-to-user monitoring-rules-view testuser-0
oc adm policy add-cluster-role-to-user monitoring-rules-edit testuser-0
# Login as user testuser-0 and get API TOKEN
# Use token to CURL rules API with parameters
# Should work
curl -k -H "Authorization: Bearer $LOKI_BEARER_TOKEN" https://lokistack-dev-openshift-logging.apps.MY_CLUSTER/api/logs/v1/application/loki/api/v1/rules?kubernetes_namespace_name=log-test-0
#  Should not return any rules
curl -k -H "Authorization: Bearer $LOKI_BEARER_TOKEN" https://lokistack-dev-openshift-logging.apps.MY_CLUSTER/api/logs/v1/application/loki/api/v1/rules?kubernetes_namespace_name=log-test-1

Labeling with do-not-merge/hold as per required Loki API is not released yet.


[feat] added ter-no-tabs rule (closes #215)

Adding ter-no-tabs rule, which implements no-tabs from ESLint
https://eslint.org/docs/rules/no-tabs
closes #215
part of #251

The CI issue is for terIndentRule.ts file which is unrelated to this PR
Details: https://travis-ci.org/buzinas/tslint-eslint-rules/jobs/275754692#L897

Any update on this request? There's no update for 18 days.
As part of #251 we're planning to create new rules in tslint-eslint-rules, and this PR was posted to understand the process.

Hi @trivikr, thanks for the PR. Could you merge master so that we can verify that the all the tests are passing? I'll try to make a release soon.

Hi @jmlopez-rod, I've fetched latest upstream and rebased my branch with master.

Sorry @trivikr, I was on vacation since Sep 16th, just got back yesterday, still catching up.

No worries @buzinas, thanks for maintaining this awesome project.
The rules in tslint-eslint-rules are very helpful in my private projects. My friends and I are happy to help! :-)


Use Unapply trick on folds.

Because things like Cofree are shaped like [?[_], A] rather than just [?[_]] we end up needing to annotate folds like
p.cata[Cofree[ProfF, Unit]](Cofree((), _))

however, we might be able to create something like cataU (analogous to traverseU) that allows us to avoid the type annotation.

@tpolecat will probably take a look at this.

:+1:

we don’t represent folds over Cofree that way any more and
we recommend using some fix for SI-2712 rather than providing Unapply-like workarounds.


fix: return array of string instead of collection when fetching phone numbers

closes #1527
fixes PROD-SWC-WEB-523
What changed? Why?
Currently when fetching the phone numbers we're returning a collection with all phone numbers and this is causing the function to fail when the internal state reaches 32 MB.
// Payload returned by each step now
[{ phoneNumber: "+1xxx" }]

// After this PR
["+1xxx"]

How has it been tested?

[x] Locally
[ ] Vercel Preview Branch
[ ] Unit test
[ ] Functional test

Created #279 to work on a long term solution


CLOUDP-57849:List events, Atlas

Proposed changes

Jira ticket: CLOUDP-57849

Checklist

[x] I have signed the MongoDB CLA
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have added any necessary documentation (if appropriate)
[x] I have run make fmt and formatted my code

Further comments

Waiting for https://github.com/mongodb/go-client-mongodb-atlas/pull/72


Update peerDependencies so you don't have to use legacyPeerDeps

The peerDependencies are too specific, so you can't use this with a capacitor 5 or 6 project even though it works fine unless you npm install with --legacy-peer-deps
Simple fix

@taxilian thanks for this . I do not use the hook anymore it is the reason why it was not updated


Some links doesn't show up until a day or days later

The addon pulls many links, but it doesn't pull every link from each torrent site selected from the initial setup. Some links doesn't show up until a day or days later.
Also it would be nice if we could get a size/bitrate limit option, a HDR/Dolby Vision priority setting, a format priority option (prefer MKV over MP4 for example), maybe Seren/Fen/Umbrella from Kodi sources etc. There's so many things that would make the addon even better.

Torrent sites are scraped roughly every 4 hours, and also result are heavily cached on each request, so it can take up 8 hours for new episodes to appear. Tho usually it's quicker.
The addon is great as is, and I don't want to increase complexity and config options, which would lead


Add examples to the README

A couple of examples to illustrate the capabilities of the library. We can begin with :

Closed-form posterior
Sparse regression

Hey can I work on this please.I am new to open source it would be a great achievement for me.

Thank you for your interest! Unfortunately there's already a PR open for that. But there are plenty of issues open in Aesara/AePPL/AeMCMC and hopefully you can find something. For instance we'd like to add examples in AePPL's documentation.

Yeah that's okay with me.