text:
feat(iroh): Gossip client

Description
This makes gossip available in iroh. Using iroh-gossip directly, while not horrible, is a bit verbose.
Breaking Changes
Not sure. It exports a few more things, and adds things. But in theory it should not modify existing things.
Notes & open questions

There can be some scenarios where this can cause trouble. E.g. when subscribing and then unsubscribing to a topic that is also used for doc sync.
Gossip messages are deduped it seems. So if you send the exact same message twice it will be dropped. If that's how it work we must document it.
I see lots of errors like the following:

2024-05-01T13:16:20.430596Z ERROR sync{me=kkpbi4eb5h6jcdjz}:sync{me=kkpbi4eb5h6jcdjz}: iroh::sync_engine::gossip: Failed to process gossip event namespace=atqlwoptbmnd724j err=Serde Deserialization Error

It seems that the sync engine thinks that it "owns" gossip, so it uses subscribe_all and then will deserialize everything, even messages that are not for it. How can we avoid that? Using an entirely different ALPN for normal gossip?

What should be the behaviour when a subscriber lags? Close it or just send Lagged and continue?

I think that relying on guaranteed delivery for gossip is not a good idea in any case. so maybe just sending a Lagged but then continuing is best? Forcing the client to resubscribe could be a bit annoying.
Change checklist

[ ] Self-review.
[ ] Documentation updates if relevant.
[ ] Tests if relevant.
[ ] All breaking changes documented.

I think it is safe to just ignore any messages that are not for us. See https://github.com/n0-computer/iroh/pull/2258/commits/b88398e743935c5975571e8b4fcb54c929ddc5e8
Obviously you can mess with things by subscribing to a namespace that is currently being synced, but doing so accidentally is highly unlikely. And you can also mess with other stuff by using the low level blobs api, so 🤷 .

It seems that due to the fact that the rpc protocol is public, we can not ever do an additional rpc request without breaking compat.
--- failure constructible_struct_adds_field: externally-constructible struct adds field ---

Description:
A pub struct constructible with a struct literal has a new pub field. Existing struct literals must be updated to include the new field.
        ref: https://doc.rust-lang.org/reference/expressions/struct-expr.html
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.31.0/src/lints/constructible_struct_adds_field.ron

Failed in:
  field Iroh.gossip in /home/runner/work/iroh/iroh/iroh/src/client.rs:44

--- failure enum_variant_added: enum variant added on exhaustive enum ---

Description:
A publicly-visible enum without #[non_exhaustive] has a new variant.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#enum-variant-new
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.31.0/src/lints/enum_variant_added.ron

we need to mark the rpc enums as non exhaustive, that should solve this

longterm I wish the rpc types where all private anyway

It seems that the sync engine thinks that it "owns" gossip, so it uses subscribe_all

@Frando can we change this? seems unfortunate to subscribe to everything by default

It seems that the sync engine thinks that it "owns" gossip, so it uses subscribe_all

@Frando can we change this? seems unfortunate to subscribe to everything by default

I think we can, yes. What is our primitive of choice these days to merge a changing list of streams?

https://docs.rs/futures-lite/latest/futures_lite/stream/trait.StreamExt.html#method.race

#2265 changes the sync engine usage of gossip to not use subscribe_all (based on this branch).
However as outlined in the previous comment I think I'd prefer to move the new gossip_dispatcher module to iroh_gossip, and make both the node's gossip client and the node's sync engine use that dispatcher.

@Frando so the basic idea of the gossip dispatcher is just to have a thing that wraps the gossip and does some management so that it is less fragile to use.
If you agree with / can live with the public interface (which is just the subscribe function), we could move something with that signature into iroh-gossip as a higher level interface and then I would use it here, and you could update docs to use it (or not...).
The interface is basically this:
    pub fn subscribe(
        &self,
        msg: GossipSubscribeRequest,
        updates: UpdateStream,
    ) -> impl Stream<Item = RpcResult<GossipSubscribeResponse>> {

where UpdateStream is just a stream of either broadcast or broadcast_neighbours:
/// Send a gossip message
#[derive(Serialize, Deserialize, Debug)]
pub enum GossipSubscribeUpdate {
    /// Broadcast a message to all nodes in the swarm
    Broadcast(Bytes),
    /// Broadcast a message to all direct neighbors
    BroadcastNeighbors(Bytes),
}

I think the API is fine. And still very much in favor of having only one and not 2 high level dispatch interfaces to gossip.

Ok, I will clean up the dispatcher a bit and make sure it is independent of the rpc protocol, in preparation for moving it into iroh-gossip.

Moved the dispatcher to iroh-gossip and moved the types into the dispatcher file.
I reexported some of the dispatcher types instead of making newtypes for them in the rpc protocol. Not 100% sure about this, but making so many single element newtypes is a drag...

This is missing adapting the docs stuff to the new gossip dispatcher.

Also at least a smoke test for the gossip client API would be good so that we don't break things.

@Frando I have added a test. It seems to work, now that I have added the ability to tell the endpoint about node addrs (see https://github.com/n0-computer/iroh/pull/2433 ).
I think this kind of test is nice, because it forces us to make the client API sufficiently rich that you can do tests with it. Also it is much less likely to fluke out than a full cli type tests.
But - do you think this test for gossip will reliably work? I am connecting two nodes and then send a msg from one to the next. Can there be a situation where I send the message too early and it gets lost?

But - do you think this test for gossip will reliably work? I am connecting two nodes and then send a msg from one to the next. Can there be a situation where I send the message too early and it gets lost?

Yes, Gossip::join is awaited here, and that waits for at least one neighbor to come up before completing.
So the remaining TODO is to merge the two dispatchers (in dispatcher.rs and net.rs) so that messages flow only over a single channel and not two. We should do this, but IMO it can also happen in a followup.

authors: Frando dignifiedquire rklaehn


text:
Replication the field using a button

Hi,
I am creating subjects form a dropdown menu which gets replicated after I press a button.
Is there a way I can implement it as below using the material drop down?
Below is what it should look like.

I don't really understand what you're asking but if you're looking to make a dropdown that appears on a button click perhaps this example will help
            <DropdownToggleButton onPress={() => this.dropdown.focus()} />
            <Dropdown
              containerStyle={{height: 0, width: 0}}
              pickerStyle={{width: 200}}
              dropdownOffset={{ top: 32, left: -190 }}
              ref={e => this.dropdown = e}
              data={data}
              renderAccessory={() => null}
            />

source: gharchive/issue

authors: c-moss-talk fithaN

license_type: permissive

license_source: bigquery


text:
Export [x] images label is incorrect

Thank you for the Figma Frame Exporter plugin, it works really well and helped me out quite a lot!
Steps to reproduce

Select more than 20 frames
See the preview icons capped at 20 items

Expected output
for the previews to be capped at 20, but for the bottom links to say "Export [x] images" where x is the actual number of frames selected.
Actual output
The label says "Export 20 images" even though there are more than 20 images in the final zip that gets downloaded.
From a very quick glance is seems that this numbers comes from the limit default value on the _refreshPreview function signature.

Thanks for the clear report! Should be a pretty simple fix. I’ll look into it shortly.

Fixed in https://github.com/naftalibeder/figma-frame-exporter/commit/6e21c7c6037966e3dce9423e26bef0075e1bec86.

authors: germain-gg naftalibeder

repo: naftalibeder/figma-frame-exporter

license: MIT

license_source: github-api


text:
Calendar Date pick is crazy

When I picked one date, the calendar didn't stop changing the date
https://github.com/nainglinnkhant/shadcn-view-table/assets/6184866/0daf39c3-e877-432f-8570-9af7c46df1ed

Thanks for the heads up. Could you please specify how can I reproduce it?

No secret... open the URL and try to change the date on the calendar, and the error happens.
I've use Chrome (Version 126.0.6478.127 (Official Build) (64-bit)) with AdBlock on Windows OS

Thanks for the heads up. Could you please specify how can I reproduce it?

It doesn't happen on my end (MacOS but the same Chrome version as you) and I don't have a Windows device to debug it. While I'm unable to find a way to debug it, could you check if the issue is solved in this preview?

I've tested on the virtual env of Windows 10 and Windows 11 with the same Chrome version you use and didn't have this error. Can you specify more information about your environment or try it on incognito mode?

Hey @nainglinnkhant, I can't access the preview link. I also tried on incognito mode, Firefox, Edge, and Opera, and all the browsers have the same error. on Edge and Opera I have zero extensions.

I see, I've just granted you access. Please check.

Yes, the problem was fixed on this link [shadcn-view-table-git-fix-fix-d-63531b-nainglinnkhants-projects.vercel.app](https://shadcn-view-table-git-fix-fix-d-63531b-nainglinnkhants-projects.vercel.app/)

Thanks for your contribution. The fix's merged now. However, there's a tradeoff of the date picker not being updated with a new date when date params change in URL. But I think the bug that we're tackling in this issue is a more serious concern.

authors: johanguse nainglinnkhant

repo: nainglinnkhant/shadcn-view-table


text:
Vac Kick after Update, please help me !

After yesterday's update (March 31, 2020 the cheat ends up being expelled by the VAC saying that it was not possible to verify the session, how can I fix this? Thanks namaszo !

i have the same problem, im whaiting for some one to find out how to fix it...

i have the same problem, im whaiting for some one to find out how to fix it...

I fix it with Junk Code + New injector :) it:'s work so good !

What "kind" of junk code did you use?

I'm using auto Junk code
https://www.unknowncheats.me/forum/downloads.php?do=file&id=22312
"selecr "Float" and click start. The "Passes" max is 10
Em qua, 8 de abr de 2020 10:13, pbrainho notifications@github.com
escreveu:

What "kind" of junk code did you use?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/namazso/nSkinz/issues/197#issuecomment-610951483, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/APAPY7FG34RORVYHY5B2XBDRLRZ6FANCNFSM4LYNM4QQ
.

thx, ill try

It works with extreme injector, with the injector bundled to osiris I get the vac error

I use my private injector, try use the RandoInjector (see tutorial n the
YouTube How to use) :)
Em sex, 10 de abr de 2020 04:34, KEEDLife notifications@github.com
escreveu:

It works with extreme injector, with the injector bundled to osiris I get
the vac error
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/namazso/nSkinz/issues/197#issuecomment-611917995, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/APAPY7BWETYX3OWH2WT34UDRL3DY7ANCNFSM4LYNM4QQ
.

You need to use the "Auto Junk Code" on Source to avoid being banned.
There are people on forums that say to use VMPRotector together with
Junk, however, VMProtector is banning it!
Em sex, 10 de abr de 2020 04:34, KEEDLife notifications@github.com
escreveu:

It works with extreme injector, with the injector bundled to osiris I get
the vac error
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/namazso/nSkinz/issues/197#issuecomment-611917995, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/APAPY7BWETYX3OWH2WT34UDRL3DY7ANCNFSM4LYNM4QQ
.

What are you Even saying dude, „banning it“ what do you think this is? A
Minecraft server?
On Fri 10. Apr 2020 at 13:47, zSniiKeR notifications@github.com wrote:

You need to use the "Auto Junk Code" on Source to avoid being banned.
There are people on forums that say to use VMPRotector together with
Junk, however, VMProtector is banning it!
Em sex, 10 de abr de 2020 04:34, KEEDLife notifications@github.com
escreveu:

It works with extreme injector, with the injector bundled to osiris I get
the vac error
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/namazso/nSkinz/issues/197#issuecomment-611917995,
or
unsubscribe
<
https://github.com/notifications/unsubscribe-auth/APAPY7BWETYX3OWH2WT34UDRL3DY7ANCNFSM4LYNM4QQ
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/namazso/nSkinz/issues/197#issuecomment-611996408, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AG75EZUB7Z5WYPOYOZHVLYDRL4BNJANCNFSM4LYNM4QQ
.

When I use VMProtect with Rando Injector, it is banning! Without it, only with the Junk Code it works normally. That's why I told him to use RandoInjector without VMProtector, with other injectors I don't know if the same thing happens.

You mean a vac ban.. omg I was thinking you’re saying „it’s banning the
junk code“ sry ma dude I just think people are stupid.
On Fri 10. Apr 2020 at 13:53, zSniiKeR notifications@github.com wrote:

When I use VMProtect with Rando Injector, it is banning! Without it, only
with the Junk Code it works normally. That's why I told him to use
RandoInjector without VMProtector, with other injectors I don't know if the
same thing happens.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/namazso/nSkinz/issues/197#issuecomment-611998069, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AG75EZWAEQWNTPES5WVOHD3RL4CERANCNFSM4LYNM4QQ
.

You mean a vac ban.. omg I was thinking you’re saying „it’s banning the junk code“ sry ma dude I just think people are stupid.
…
On Fri 10. Apr 2020 at 13:53, zSniiKeR @.***> wrote: When I use VMProtect with Rando Injector, it is banning! Without it, only with the Junk Code it works normally. That's why I told him to use RandoInjector without VMProtector, with other injectors I don't know if the same thing happens. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#197 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG75EZWAEQWNTPES5WVOHD3RL4CERANCNFSM4LYNM4QQ .

I'm just trying to help dude, sorry for my bad English kkk, sometimes the translation is not very good. The Junk Code works perfectly :)

Well, reinforcing how I solved this: In my case I ONLY used the Junk Code on Source and RandoInjector, only these two changes worked perfectly here and the VAC Kick problem is over, if RandoInjector continues to give VAC Kick, try to use the VAC Kick SimpleLoader which is great too

;)

Well, reinforcing how I solved this: In my case I ONLY used the Junk Code on Source and RandoInjector, only these two changes worked perfectly here and the VAC Kick problem is over, if RandoInjector continues to give VAC Kick, try to use the SimpleLoader Injector (have Source Code in The GitHub) which is great too .

;)

Sorry for my nab question, but where do you add the Junk Code?

authors: KEEDLife M1XT3NZ flawnn pbrainho zSniiKeR

repo: namazso/nSkinz

license: mit


text:
Out of Sync with latest go version - Newer fork available jnovack/flag

This repository includes the v1.17.4 of golang/src/flag.  We are currently at v1.15 and a number of improvements have been made to the package which are not reflected here.

I have updated flag and committed a version suitable for v1.15 of golang.
https://github.com/jnovack/flag

I'd personally love to see jnovack/flag's improvements integrated here.
The old style flag help feels downright archaic these days

old
new

authors: donatj jnovack

repo: namsral/flag


text:
feat: pass variant and variants props to a styled component

Resolve #184

Hi @nandorojo ,
Any changes needed to validate this PR ?
Thanks,

Released in 4.2.0.

source: gharchive/pull-request

repo: nandorojo/dripsy


text:
[Feature request] Add a way to access to the whole list of parameters

Hello! 👋
The way solito exposes parameters to the React tree is pretty interesting, simple as
const { useParam, useUpdateParams } = createParam()

const FooComponent = () => {
  const [fooParam] = useParam('foo')

  ...
}

However, I noticed it does not expose ways to retrieve all the parameters simultaneously. Going straight to the code, I'm talking about
const useParams = createParams()

const FooComponent = () => {
  const { foo } = useParams()

  ...
}

which would be handy when:

we are not interested in picking a specific param, but the entire set: this would be extremely useful when a screen is dependent on many params, avoiding so to access every single parameter with a call to useParam;
there are unknown or hardly typeable parameters that we want to access
For example, the search string on the web is an excellent place to store data pieces. If we put query parameters with a UUID as a key, this would be impossible to type in typescript. The situation would be even more challenging in case the UUID represents a key of an object-like data structure, like ?foo[4faf73da-b6ef-4808-b53e-c999a5372aef]=bar&foo[2af22232-1156-44d3-a46d-cfc9594e1dc6]=baz
a third-party developer wants the freedom to create abstractions just on top of the parameters list'

Is it something planned to be introduced, or is it out of the scope of this library's responsibilities?

sounds like a fair use case

authors: nandorojo valeriobelli

repo: nandorojo/solito


text:
🛑 impro-impact.ch is down

In 56049c1, impro-impact.ch (https://impro-impact.ch) was down:

HTTP code: 0
Response time: 0 ms

Resolved: impro-impact.ch is back up in c2b8e06 after 20 minutes.

repo: nanhosting/monitoring


text:
Show incoming deploys in the dashboard

Since nanobox deploy hits the api to register a deploy, it seems like we could show in the dashboard that a deploy has been initialized

When nanobox deploy initially hits the Odin API its only doing a GET for info about the current deploy. It doesn't actually register anything about the new deploy until it's ready for it to be deployed, which is when the dashboard starts to show the progress viewer. Also, even if we did display something about a deploy in progress, maybe after the initial GET, if anything failed during the local compile/deploy, we would need to clear that message since it would no longer be applicable.
So I'll close this issue for now, but let me know if it's important enough that we should consider rearchitecting.

authors: glinton jedgalbraith

repo: nanobox-io/nanobox-dashboard-issues


text:
nanoc 4.11.1 introduces breaking change by making compiled_content include the layout

I upgraded my project from 4.11.0 to 4.11.2 and noticed a weird glitch: the full-text post previews included the layout again.

Turns out that between 4.11.0 and 4.11.1, #compiled_content changed and now returns a cached representation with the layout already added. I found that a call to compiled_content(snapshot: :pre) makes it look as expected.
So fixing this was pretty easy, I just wanted to let you know that this is a change at all so you might add it to the release notes.
I couldn't reproduce this in a vanilla project with v4.11.1, though. Maybe it's because the affected items are references in preprocess? If you aren't aware of this change and don't have a hunch what's going on and want me to investigate, I can try different configurations @ddfreyne

Yikes — that is definitely a bug. Will investigate.

This is almost certainly caused by 5cbad99abfed9e3cb02bc271f2be1ad7f12b1641 (part of #1394). It’s a refactoring that I’ve been wanting to make for a long time.
I’m still investigatating why it fails for you, though.

@DivineDominion I’m not able to reproduce the problem you described. Could you create a zip of tmp/nanoc and send it to me (denis+github@denis.ws)? After you’ve done that, can you try removing tmp/nanoc and re-running Nanoc?

@DivineDominion Are you still experiencing this issue?

This is not an isolated issue, as I just saw the same issue come in: https://groups.google.com/forum/#!topic/nanoc/pbHOJ3T6wiY

While finding the fix wasn't that bad, I find it pretty hard to create a test project that crashes. I stopped a while ago but will try to squeeze in time this week to figure this out.

I am now able to reproduce the problem, and am working on a fix.

Here is a fix: #1421
I am struggling to write a regression test for it, though.

Good you found the culprit! I ran into it in another project just last week but couldn't trim it down to a simple example :/

authors: DivineDominion ddfreyne

repo: nanoc/nanoc


text:
label:"help wanted" error on k3s, but not in bash

I can run FediFetcher from bash without issue.

{
"access-token": "TOKEN_xxxxxxxxxxxxxxxxxxxxx",
"server": "mastodon.xx.xx",
"home-timeline-length": 200,
"max-followings": 80,
"from-notifications": 1
}

but not inside a k3s/k8s pod.

apiVersion: apps/v1
kind: StatefulSet
metadata:
name: fedifetcher
spec:
selector:
matchLabels:
app: fedifetcher
template:
metadata:
labels:
app: fedifetcher
spec:
containers:
- name: fedifetcher
image: ghcr.io/nanos/fedifetcher:latest
args:
- --server=mastodon.xx.xx
- --access-token=["TOKEN_xxxxxxxxxxxxxxxxxxxxx"]
- --home-timeline-length
- "200"
- --max-followings
- "80"
- --from-notification
- "4"
resources:
requests:
memory: "64Mi"
cpu: "0.1"
limits:
memory: "1Gi"
cpu: "1"
volumeMounts:
- name: fedifetcher
mountPath: "/app/artifacts"
volumes:
- name: fedifetcher
persistentVolumeClaim:
claimName: nfs-mastodon-fedifetcher

Don’t leave me hanging: What happens on k3s?

Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/urllib3/connection.py", line 174, in _new_conn
2024-04-18 05:56:54.009683 UTC: Starting FediFetcher
2024-04-18 05:56:59.032337 UTC: Error getting timeline toots: HTTPSConnectionPool(host='mastodon.xx.xx', port=443): Max retries exceeded with url: /api/v1/timelines/home (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7268d1af5150>: Failed to establish a new connection: [Errno 101] Network unreachable'))
2024-04-18 05:56:59.047916 UTC: Job failed after 0:00:05.038199.
conn = connection.create_connection(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/urllib3/util/connection.py", line 95, in create_connection
raise err
File "/usr/local/lib/python3.11/site-packages/urllib3/util/connection.py", line 85, in create_connection
sock.connect(sa)
OSError: [Errno 101] Network unreachable

Glad you got that sorted. I guess we should add that to the example file.
Are you able to provide a PR by any chance?

The problem was the lack of knowledge about network functionality in k3s.
A pod uses the internal DNS structure and cannot access resources in the LAN (e.g. proxy).
As I understood...
A PR doesn't seem appropriate here.

OK, great. Thanks for the feedback, and I'll close the issue again then.

authors: RJGhugo nanos

repo: nanos/FediFetcher


text:
Cnt example rc 1.0

Created 10,0 CNT example using LAMMPS USER-Phonons, similar as instruction in the supplement information for our submitted manuscript.

good to merge.

good to merge.

repo: nanotheorygroup/kaldo


text:
Update README.md

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=ru
Description of changes:

"An unexpected error has occurred, could you please contact admins. Your RequestID: 6c195a20-5395-44bd-9f21-f31b57857f9f"


text:
What does [DEPRECATED] mean?

Hi!
Does this mean you have decided not to maintain this library any more?

Yes. I don't have enough time to maintain this library. So, if anyone wants to maintain this, I will welcome him/her as a collaborator.

Hi - It would be a pity to deprecate this. I see there are other libraries that do Swift - but this looks the most popular.
I am happy to help with testing it out i see people have contributed Swift 3 fixes already.

@grantkemp Thank you! Can I make you a collaborator?

Sure - feel free.  I don't know the library well enough yet -barring using it but I can merge and do my best to keep it updated as I use it on one of my apps.

@grantkemp Thank you so much! I added you as a collaborator!

Since I found a collaborator, I will remove [DEPRECATED]. 👍

authors: grantkemp naoty nkanellopoulos

repo: naoty/SwiftCSV


text:
无法解析虾米音乐 Invalid character entity

info: Starting app...

info:
info:
info:    Sails              <|
info:    v0.10.5             |\
info:                       /|.\
info:                      / || \
info:                    ,'  |'  \
info:                 .-'.-==|/_--'
info:                 `--'-------'
info:    __---___--___---___--___---___--___
info:  ____---___--___---___--___---___--___-__
info:
info: Server lifted in `/var/www/xiamiRun`
info: To see your app, visit http://localhost:1337
info: To shut down Sails, press <CTRL> + C at any time.

debug: --------------------------------------------------------
debug: :: Tue Apr 21 2015 22:58:03 GMT-0400 (EDT)

debug: Environment : development
debug: Port        : 1337
debug: --------------------------------------------------------
connect deprecated res.headerSent: use standard res.headersSent node_modules/sails/node_modules/express/node_modules/connect/lib/proto.js:129:22
connect deprecated res.on("header"): use on-headers npm module instead node_modules/sails/node_modules/express/node_modules/connect/lib/middleware/session.js:247:9
errors [Error: Unexpected close tag
Line: 128
Column: 7
Char: >]
errors [Error: Unexpected close tag
Line: 128
Column: 7
Char: >]
errors [Error: Invalid character entity
Line: 130
Column: 120
Char: =]
errors [Error: Invalid character entity
Line: 130
Column: 127
Char: &]
errors [Error: Invalid character entity
Line: 130
Column: 135
Char: &]
errors [Error: Invalid character entity
Line: 147
Column: 78
Char: =]
errors [Error: Invalid character entity
Line: 162
Column: 33
Char: ']
errors [Error: Invalid character entity
Line: 162
Column: 67
Char: ']

/var/www/xiamiRun/node_modules/xmlreader/node_modules/sax/lib/sax.js:912
  if (this.error) throw this.error
                            ^
Error: Invalid character entity
Line: 162
Column: 67
Char: '
    at error (/var/www/xiamiRun/node_modules/xmlreader/node_modules/sax/lib/sax.js:642:8)
    at strictFail (/var/www/xiamiRun/node_modules/xmlreader/node_modules/sax/lib/sax.js:662:22)
    at Object.write (/var/www/xiamiRun/node_modules/xmlreader/node_modules/sax/lib/sax.js:1335:11)
    at Object.exports.read (/var/www/xiamiRun/node_modules/xmlreader/xmlreader.js:157:12)
    at IncomingMessage.<anonymous> (/var/www/xiamiRun/api/controllers/XiamiController.js:41:27)
    at IncomingMessage.emit (events.js:117:20)
    at _stream_readable.js:944:16
    at process._tickDomainCallback (node.js:492:13)

试了一下，我这边是可以的。
测试地址是 http://localhost:1337/xiami/run?song=http://www.xiami.com/song/87855

如果你的服务器是运行在国外的话，这个服务访问虾米的音乐 url 时因为版权问题无法正常读取页面。
不知道是不是这个原因。
当时我是跑在阿里云上的。

喔我主机是在国内……考虑重开国内的主机吗？

On 22 Apr, 2015, at 4:15 pm, J.Y Han notifications@github.com wrote:
如果你的服务器是运行在国外的话，这个服务访问虾米的音乐 url 时因为版权问题无法正常读取页面。
不知道是不是这个原因。
当时我是跑在阿里云上的。
—
Reply to this email directly or view it on GitHub https://github.com/naoyeye/xiamiRun/issues/1#issuecomment-95069956.

@cdiscrete 暂时还不会开。因为这个服务几乎没什么访问量，一个月最多也就我自己用的那么一两次。
你可以在 https://github.com/naoyeye/xiamiRun/blob/master/api/controllers/XiamiController.js 这个文件里 console.log() 看下访问页面的时候出了什么问题。看你上面的 log 应该是解 析 xml 的时候出错了。
line 40:
resp.on('end', function() {
    console.log('xml=', xml); // 在这里加一行 然后看下输出的 xml 是什么
    xmlreader.read(xml, function(errors, responsive){
        .......
    }
}

正常的话会是这样：

@cdiscrete 我正在 leanCloud 上搭一个音乐解析服务，完成后告诉你地址

http://xiamirun.avosapps.com/run?song=http://www.xiami.com/song/1774205606

authors: cdiscrete naoyeye

repo: naoyeye/xiamiRun


text:
Set threshold for codecov failure

Description
As mentioned on zulip, I am slightly bothered by the red "X" next to PRs that are good in every way except a very slight drop in codecov.  I certainly don't want to encourage PRs lacking tests, but the status starts to be useless if you know there are relatively "nitpicky" things that might be causing it to show a failed status.  It'd be nice if the fail/success status were a direct predictor of whether the PR is ready (or close to ready) to merge or not.
This would set a minimum threshold of a 0.5% loss in coverage in order for codecov to fail a build.  (We can of course, continue to manually evaluate whether there are sufficient tests as usual).  Certainly open to changing that number if anyone wants.
Type of change

[x] CI change

References
https://docs.codecov.io/docs/commit-status

thanks for the approval.  i suppose we should wait for cirrus windows CI work again so that we can make sure codecov runs ok.  will check tomorrow

windows finally worked and it looks like the codecov changes also worked (in that it ignored a 0.11% change).  So we could just merge and be done...
but one other codecov characteristic that would be nice to tweak is shown here, where it's highlighting some apparent changes in shapes files that were unaffected in this PR.  This link has some details on unexpected changes... but after reading it I'm still confused.
It's also possible that we should be using patch status (which "only measures lines adjusted in the pull request or single commit, if the commit is not in a pull request") instead of project status (which "measures overall project coverage and compares it against the base of the pull request or parent commit.")

Cool thanks.  Maybe the seemingly unrelated coverage changes can be a challenge for another day

repo: napari/napari


text:
Add loader on both like and comment

Description
Currently, when you click on comments or likes they will show blank because the data is loading which create bad UX. I want to add loader(or shimmer?) on both.
Steps to reproduce
Go to home page.
Click on comments or likes.
It will take some time to load and in the meantime it shows nothing to the user.
Screenshots
No response
Desktop (please complete the following information)
No response
Smartphone (please complete the following information)
No response
Additional information
No response
Record

[X] I agree to follow this project's Code of Conduct
[X] I have checked the existing issues
[X] I'm a GSSoC'23 contributor
[X] I want to work on this issue

Ohkk.


text:
Mouse cursor switching problem in Rich4 game (not a problem introduced in the new version)

Tested using DDrawCompat v0.5.3 & DDrawCompat v0.4.0 versions
When the player is stationary in the game, open the configuration menu (shift+f11) without making any settings and close it.
The mouse cursor in the game can be moved and used normally.
But when the player is moving in the game, open the configuration menu (shift+f11) without making any settings and close it.
The mouse cursor in the game can be moved, but cannot be used (the game is not frozen and there is still background music)
Turning on the statistics column (shift+f12) will not cause the above problem
Also not sure if this is a problem with DDrawCompat
If it is not a problem with DDrawCompat, I will close this issue myself. Thank you for your support for old games.
Attached are relevant logs and videos
https://mega.nz/folder/wHZQRIxK#j5rg_rbfiFKp82lrWD4u6Q

When you open the config overlay, a low level mouse hook is installed in order to make sure mouse events are not processed by the game, and are processed be the overlay instead. When you close the overlay, the hook is uninstalled, so your game can start processing mouse events again. This is why you can't move your in-game cursor while the config overlay is open, and clicks will go to the overlay only and won't affect the game.
Since you can move your in-game cursor again after closing the overlay, this proves that the hook was uninstalled successfully. And since the issue only happens on your laptop, it's unlikely to be a bug in the game or DDrawCompat itself. The game also doesn't install any similar low level hooks, though it does install a normal keyboard hook (WH_KEYBOARD).
My best guess is that your laptop has some other 3rd party software running that's interfering here. Perhaps something that also installs mouse or keyboard hooks. From your logs, I can only see that at some point the game window stops receiving WM_MOUSEMOVE and similar mouse event messages, as if it somehow got deactivated or lost focus. But there is no log to indicate that anything like that happened.
Try closing all background processes until you find the one that might be responsible. Also, try changing the keyboard shortcut for the config overlay to something much simpler (preferably also without any modifier keys), in case the issue is caused by the F12 key being intercepted by some other app too or something.
Also, doesn't alt-tabbing out and back into the game restore the focus?

Rich4 does not support the function of pressing alt+tab to return to the game because Rich4 is an old game for Win95.

Have you tried if any of the AltTabFix settings help?

Also, I would like to ask if DDrawCompat supports simulating the keyboard configuration of Win95? (I remember that Microsoft changed the keyboard bottom layer after WinXP)
Because the keyboard configuration of the Rich4 game cannot be used in Win10 and Win11

I don't really understand the problem or what changed after XP, but solving keyboard issues doesn't really belong in DDrawCompat (unless the issue is caused by DDrawCompat).

repo: narzoul/DDrawCompat


text:
Rev 2.0 - PCB updates

Resolves issue #187 regarding test point T3 and duplicate 16 connectors. Renamed connector to J28. Connectivity unchanged. Documentation updated to refer to J28.

Removed extraneous trace described in issue #177. No other changes around J6 and J7 because that might still be an open discussion,

Resolved issue #169 by moving C2 closer to the data pins for RoboClaw 1

Made trace widths consistent for +5 going to encoders. (There was some discussion about this. The change was probably unnecessary, but it didn't hurt anything.)

The +12V and GND labels for J13 get lost under the part. The label has been moved slightly.

TODOs
Schematic Todo

[x] Eliminate voltage divider circuitry
[x] Add E_STOP3 to S5
[x] Add pull-up resistors to E_STOP2 and E_STOP3
[x] Power ina260 via 3.3V
[x] Update ina260 high-current connector for 0.2" Digi-key
[x] Power servo controller via 3.3V
[x] Put +12 or +BATT on RoboClaw LB+ pins (NOT DOING)

[x] Add decoupling capacitor on voltage supply to RC LB+ pins

[x] Connect RPi GPIO pin to servo controller OE pin to allow RPi to enable/disable servos
[x] Add extra servo output pins from servo controller to board
[x] Add LEDs for debugging

[ ] LEDs will need pullup resistors
Proposed list of LEDS:

[x] BATTPOS
[x] +BATT
[x] +12V
[x] +5V
[x] ESTOPS
[x] Alert from ina260

[x] Add decoupling capacitors to +5V and +3.3V
[x] Determine which lines on J6 should not go to J7

Proposed list:

[x] E_STOP
[x] Alert from ina260 (to be discussed)
[x] LEDs controlled by Pi (to be discussed)

[x] At least two +5 and GND pins on J12
[x] Rearrange pin assignments on J12 so that plugging connector in backwards will not destroy anything
[x] Pin header with test points

[x] Proposed list:

[x] Each voltage level
[x] GND
[x] Serial lines

[x] Change Arduino from USB-Dongle to I2C - discussion in progress
[x] Replace existing fuse with standard glass fuse
[x] Impliment the large +5V/15A Pololu voltage converter

[x] Change to schematic/part library
[x] Determine PCB implementation

[x] add i2c header for externally talking to rpi

Layout Todo

[ ] Avoid through-holes opposite electrolytic capacitors on RoboClaws

Layout Changes for v1

[ ] Look at changing the transistor footprint so that the holes are farther apart
[ ] All passives, diodes, and transistors on the motor board should be on the same side. Most are, but there are few that show up on the reverse side without a good reason
[ ] Labeling of resistors and capacitors needs to be fixed so that the label for a particular device is not located under a different device
[ ] The electrolytic capacitors need to have labels with the correct polarity
[x] The orientation for the LED block is not clear. -- updated LED footprint for correct numbering. Also added chamfered corner on silkscreen to correspond to chamfer on part
[ ] The orientation for the switch block is not clear
[ ] The large electrolytic capacitor C19 is to close to nearby parts
[ ] Label the power connections and DROK
[ ] Evaluate better combination of parts for J21+J26
[ ] Wrong footprint for J24 - it should be ok but it isn't
[ ] Label pins on J20
[ ] Label LEDs
[ ] Brain board interferes with the Molex motor connectors - not as bad as I originally thought. The problem is that J21 and J26 don't really match, and it's possible to attach them incorrectly so that the wrong pins go into the sockets and the brain board moves too much in one direction.
[ ] Connect unused GPIOs between J22 and J23
[ ] Orientation of pin 1 is inconsistent
[ ] Consider moving the 5V converter to the opposite side of the brain board and flip it over as was done with the previous board. (Just a thought. The voltage converters, the ina260, and the servo controller all need to be socketed with standoffs, and flipping the 5V converter would take up less vertical space.)
[ ] For the servo controller, we might want to consider a single row of signal pins for outputs 1-4. This will simplify soldering the part or header. The power and ground pins don't really accomplish anything since we use a separate set of of pins on the edge of the board. If we don't include additional sets of pins on the edge of the board for outputs 5-16, then the holes beneath the servo controller need to be removed.

Schematic Changes for V1

[ ] Add weak pull-down to the TxD and RxD lines so that they don't light up the LED before the Pi is ready
[ ] Bring +3.3V to J20
[x] Alert line needs a pull-up instead of a pull down
[ ] Move alert LED from brain board to motor board and connect to red LED

Documentation Todo

[ ] The A0 address pads on the pca9685 need to be bridged to give the device i2c address 041. The default address for both the ina260 and the pca9685 are both 0x40, so there will be a conflict if you don't change one of them.

Parts list additions

[ ] Adafruit ina260
[ ] Adafruit pca9685
[ ] Pololu 5V/15A converter

Parts list removals

[ ] Remove small Pololu 5V converter

Parts list changes to part counts

[ ] Change Roboclaws from 5 to 3

@dcschooley I'll take a look at this soon, I think there might be a few additional things we were looking at doing if we were going to do a PCB rev. Let me see if I can collect those and compare it here.

I'll be happy to incorporate additional things if you have a list and if it would take some of the load off of you all.

@dcschooley I took at look at this and it does look like it looks good on the items 1-5 that you listed above, which close a couple of the open issues, great job on this thanks.
I think we should discuss some potential upgrades that would be nice for addition things as well. Below are a few that I'm aware of

Connect all ground pins between J6 and J7
Connect the 5V rail  to the J7 connector
Remove J12 and C1

These changes will mean that we will be powering the RPi through the Ribbon cable instead of a micro USB port. It bypasses the internal protection on the Pi, however because it is being supplied directly from the regulator which is nowhere near its' limit I believe this is fine to do.

Look at ways of integrating in a different voltage/current sensing system, to be able to be read into the Pi (@Achllle was particularly thinking about this with issue #196)
Change the inputs to the PCB to be a little simpler with working with the battery/any external monitor system. Right now it's a bit of a spaghetti between in/out
There had been some discussion at one point about choosing a better connector (issue #190) instead of the terminal blocks. We could explore options and if there is something that allows this to be done easier.

@mikcox @Achllle @gfosmire @Roger-random Might be able to give some more feedback of ideas of things we might want to do as well

@ericjunkins Powering the PI via the ribbon cable also helps out those switching to a PI 4 because it uses a USB C connector, thus requiring a USB-A to USB-C cable. I assume the ribbon cable can handle the current, but Adafruit doesn't provide the current limits.
https://www.adafruit.com/product/4226 might be the device @Achille was thinking about. It looks like it would work. I would mount it on the RoboClaw side of the board to the left of RC2, so between RC2 and the PI headers. Someone needs to try it to see if it works.
Is there any reason to keep J14 as a USB connector? Why not make it like J13? One possibility might be to leave the existing 5V regulator dedicated to the PI, Arduino, and LED panel. A second, optional 5V converter could be added for aux power. Most people might not need it, but it could be really useful for those who want it. It could probably go on the Raspberry PI side of the board near J8. Putting it on the RoboClaw side of the board would make it hard to get to the screws in J5.
I had been thinking along the same lines regarding the board connectors. The 30AWG wires are all sorts of painful. I ended up using ferrules for all of my connections. Any plugs need to fit through the 0.5" holes in the  pattern plates, otherwise you require a connector on the motor side too. (Most people are probably doing that already, but I still think it is a good idea not to trap the connector. For JST connectors, you are limited to 3A until you get to the VH series. Maybe 3A is enough for a short period of time.. You could split up the connectors into a small data connector for the encoders and a 2-position VH connector for the motors. The Molex Micro-fit connectors are pretty great. They make a PCB mount version, and I know the 2x3-position plug will fit through the holes.
I would also bring back both encoder lines for the corner motors. You don't really need the extras right now, but someone might want to use quadrature encoders in the future.

I'll tackle the battery and power monitoring first, since that will be somewhat hairy when updating the PCB. I think the current connection to the meter needs to be in series with the switch, with that series combination in parallel with the 10k ohm resistor . That way the diode/fuse combination can do their thing if the meter dies, falls out, or gets disconnected while the motors are running. It's going to take two more connectors, one large one for current and a small one for voltage.

Ferruls are great and definitely more industry standard, I was hoping to avoid having everyone have to purchase all the specific tooling to help with that, but in the end it might be worth it, I think the ferrule crimper is only like $20. I'm working on updating the docs and build list to not use the 30AWG wire, issue #190 has an update on that. Definitely in general worth thinking about moving to something like the Molex Microfit jr or some other kind of connector. Of course ideally you can put all 6 on one connector, but like you said sizing is an issue. I do have connectors trapped in mine, my version goes:
Terminal block on PCB -> 25 Position Mico - D connector (one on left side one on right side)
25 Position Micro - D connector -> 5 individual bundles, terminated each with a Molex Mini fit Jr (6 position)
6 Position Mini fit Jr -> Motor
Although I have cables trapped inside the routing of the rocker-bogie I can disconnect individual motors, or the entire rocker-bogie from the body for storage with this scheme. It is extremely convenient, but definitely required a bit more expenses to make it happen.

I wouldn't recommend ferrules for most people simply for the specialized crimper that you can't really use for anything else. If someone needs to buy a crimper for a project like this, it would be better if it could be used for lots of different connectors. You can also break off the ferrule in the terminal block if you are not careful. I was running into problems keeping the wires in place in the RoboClaw connections, and the ferrules totally fixed that. I then went a bit crazy and used them everywhere. They solve the problem with the 30AWG wires, although I don't think they are intended for that small of wire. I work for an electric utility, and ferrules are in our construction standards. Things need to last for decades, and a loose strand of wire in the wrong place at the wrong time can cause all sorts of grief.
Going with a different connector, such as a JST-PH largely fixes the 30AWG problem, but I'm always a bit concerned about breaking a wire in the wiring harness somewhere.
Trapping the cables is ok if you can disconnect what's needed. If you have a big connector inside the body, then you need a connector on the other end of the cable that you can push through the holes.
I commented on Issue #190. 16AWG wire limits connector options and might be bigger than necessary. It pushes things in the direction of a four-pin JST PH connector for data and a 2-pin JST VH for the motors.

Somewhat relevant: The encoders on the GoBilda motors use 4 pin JST XH connectors. Would probably be good to use as much of the same connectors as possible

Is there a pretty crimped cable available for the jst connectors?

For sure, for example: https://www.gobilda.com/wiring/

heads up, I rebased this pull request on top of master, needed to be done. There's a copy of the original, unrebased branch here https://github.com/apollokit/open-source-rover/commits/revF_backup

Lots of updates pushed. This should be bulk of the functionality for revF now, including:

splitting the single control board into a motor board and a brain board, with an inter board connector between them
deleting two roboclaw motor controllers and adding a servo controller
additional e stop signal
adding the ina260 daughter board for digital measurements of voltage and current from battery
you can now actually run the electrical rules checker in kicad
fixing references to kicad symbol library

@apollokit Here's a list of feedback
Motor Board
General feedback

[ ] RoboClaws actually shouldn't have +5V to the LB + pin. When I initially made this I thought that this set the logic voltage. What this actually does is give the logic an external power source seperate from the motor bus. If we use it we just put either +12V or +BATT, it expects something ABOVE 5V
[ ] Yes connect S5 on the Roboclaws, we might as well
[ ] You should put pull-up resistors on S4 and S5 yes
[ ]  At this point I think we're full commit to removing the corner motors and replacing with servos. You can nuke anything with RC4x and RC5x (there's a lot in the Roboclaw Motor Connection Output block)
[ ] Voltage Divider can be nuked, don't need literally anything from this when moving to servos
[ ] You could tie OE to a GPIO and use it also as an "ESTOP" for the servos as well
[ ] I agree with @dcschooley about might as well break out all the extra servo pins to our board 🤷

J12 Specific connector changes

[ ] I think we want multiple +5V & GND pins. 2 each probably. Each is max limited to 2A, but it seems that there is space so might as well add one more of each just in case the Pi power + inrush currents etc etc.
[ ] Think about the location of pins on a connector, I usually try to avoid conditions where a power pin is next to a ground pin, in case you mess up, or touch something while probing etc. Also try and avoid if you plug it in backwards that something bad happens, ie. don't mirror power/gnd pins on a connector either

LEDs!
Let's add some debug LEDs to this biotch. It'll make it so much easier to debug/test and help people while assembling. The things that should have LEDs are:

[ ] BATTPOS
[ ] +BATT
[ ] +12V
[ ] +5V
[ ] ESTOPS?
[ ] alert?

Brain Board
General feedback

[ ] GPIO_GEN0 is part of the SPI bus, i'd try to pick things for our general use pins that aren't part of SPI, I2C, UART, or PWM pins. https://www.raspberrypi.org/documentation/usage/gpio/
[ ] My philosophy is that any pin we are actively using for a purpose (alert, leds, estop) shouldn't be connected to J7 . I'm happy to discuss about it though
[ ] There needs to be a decoupling capacitor on the +5V line on this as it powers the Pi directly

LEDs

[ ] +5V
[ ] +12V
[ ] A few from GPIO pins as well

Depending on how the boards stack, we might have to put all the LEDS on the brain board. we'll have to see what the dimensions look like and how things arrange

Bring test points out to a pin-header to simplify hooking up to the board for debugging.

Request: Change Arduino connection from USB-dongle serial to I2C.

@apollokit Here's a list of feedback
Motor Board
General feedback

[ ]  RoboClaws actually shouldn't have +5V to the LB + pin. When I initially made this I thought that this set the logic voltage. What this actually does is give the logic an external power source seperate from the motor bus. If we use it we just put either +12V or +BATT, it expects something ABOVE 5V

Do we even need something on the LB+ pin? I think this connection is for a second battery is to keep the RoboClaw functioning if the main battery voltage gets too low. We don't have a second battery, and if the battery voltage gets too low to support the RoboClaws, it's game over.

Bring test points out to a pin-header to simplify hooking up to the board for debugging.

Each voltage level
Ground
All of the serial lines: TXD, RXD, SDA, SCL

Is there a reason you want to for serial comm lines? Only reason I could think of is if you have a logic analyzer, which I expect most people not to have

From Slack: Vcc on the ina260 needs to be 3.3V, otherwise the Pi has a bad day. (That's why I was feeding it from the Pi's 3.3V before.) Maybe we just add a tiny +3.3V converter on the motor board, otherwise the 3.3V needs to come from the Pi. Our I2C bus needs to operate at 3.3V.

@apollokit Here's a list of feedback
Motor Board
General feedback

[ ]   RoboClaws actually shouldn't have +5V to the LB + pin. When I initially made this I thought that this set the logic voltage. What this actually does is give the logic an external power source seperate from the motor bus. If we use it we just put either +12V or +BATT, it expects something ABOVE 5V

Do we even need something on the LB+ pin? I think this connection is for a second battery is to keep the RoboClaw functioning if the main battery voltage gets too low. We don't have a second battery, and if the battery voltage gets too low to support the RoboClaws, it's game over.

We Can either leave it disconnected, or attach another voltage with some caps with it. Because the voltage on the motor bus can fluctuate if you power it only off of that you can potentially drop before Vmin for the roboclaw.
A solution to this would be using LB+ on either +BATT or +12V and utilizing a decoupling capacitor to smooth out fluctuations

From Slack: Vcc on the ina260 needs to be 3.3V, otherwise the Pi has a bad day. (That's why I was feeding it from the Pi's 3.3V before.) Maybe we just add a tiny +3.3V converter on the motor board, otherwise the 3.3V needs to come from the Pi. Our I2C bus needs to operate at 3.3V.

Is arduino I2C bus 3.3V and 5V tolerant? Ie. Will it work with 3.3V or does it need a logic converter

Bring test points out to a pin-header to simplify hooking up to the board for debugging.

Each voltage level
Ground
All of the serial lines: TXD, RXD, SDA, SCL

Is there a reason you want to for serial comm lines? Only reason I could think of is if you have a logic analyzer, which I expect most people not to have

My oscilloscope can interpret serial communications. It's a not terribly expensive Siglent. Having it was useful when I was trying to debug some problems with the RoboClaws. You can get to these signals on J7, but getting an clip around those pins requires adding a jumper.

From Slack: Vcc on the ina260 needs to be 3.3V, otherwise the Pi has a bad day. (That's why I was feeding it from the Pi's 3.3V before.) Maybe we just add a tiny +3.3V converter on the motor board, otherwise the 3.3V needs to come from the Pi. Our I2C bus needs to operate at 3.3V.

Is arduino I2C bus 3.3V and 5V tolerant? Ie. Will it work with 3.3V or does it need a logic converter

3.3V will be fine on the Arduino.

Two other changes we have talked about and need documenting here:

Change fuse to something more easily replaceable.
Do we want to go with the big 15A Pololu 5V converter?

Bring test points out to a pin-header to simplify hooking up to the board for debugging.

Each voltage level
Ground
All of the serial lines: TXD, RXD, SDA, SCL

Is there a reason you want to for serial comm lines? Only reason I could think of is if you have a logic analyzer, which I expect most people not to have

My oscilloscope can interpret serial communications. It's a not terribly expensive Siglent. Having it was useful when I was trying to debug some problems with the RoboClaws. You can get to these signals on J7, but getting an clip around those pins requires adding a jumper.

If there's room we can look at adding it. I expect that there should be space but if not this is one of the first things I'd cut

Two other changes we have talked about and need documenting here:

Change fuse to something more easily replaceable.
Do we want to go with the big 15A Pololu 5V converter?

Yes to both actually, I didn't catch that this isn't the bigger regulator

@dcschooley can you make a checklist of things so it's easier to keep organized all together

@dcschooley can you make a checklist of things so it's easier to keep organized all together

Yes. Is there a mechanism for that on GitHub that I am not seeing? Otherwise I'll do a google doc.

From Slack: Vcc on the ina260 needs to be 3.3V, otherwise the Pi has a bad day. (That's why I was feeding it from the Pi's 3.3V before.) Maybe we just add a tiny +3.3V converter on the motor board, otherwise the 3.3V needs to come from the Pi. Our I2C bus needs to operate at 3.3V.

3.3V is also needed for the servo controller. Pull-up to the 3.3 on the motor board with the ina260. The brain board 3.3V can be supplied  by the Pi.

@dcschooley can you make a checklist of things so it's easier to keep organized all together

Yes. Is there a mechanism for that on GitHub that I am not seeing? Otherwise I'll do a google doc.

Yup, you can make a checklist using the ☑ icon in the toolbar, or this markdown syntax:
- [ ] do stuff!

Does it seem like Rev. F is going to add new features? Or is it only a simplification and redoing of the current Rev. E? I'm leading a group that's just finishing up the testing and configuration of PCB Rev. E, so I'm wondering what the overall benefits will be.

Does it seem like Rev. F is going to add new features? Or is it only a simplification and redoing of the current Rev. E?

Does it seem like Rev. F is going to add new features? Or is it only a simplification and redoing of the current Rev. E?

I would say yes it is adding new features

Here is a TODO list in markdown that needs to parked somewhere.
TODO.md

Here is a TODO list in markdown that needs to parked somewhere.

Parked them for you in the original PR opening comment. Simply copy pasted them. GitHub supports checking the boxes by clicking on them.

Here is a TODO list in markdown that needs to parked somewhere.

Parked them for you in the original PR opening comment. Simply copy pasted them. GitHub supports checking the boxes by clicking on them.

That seems like a good place. Maintaining it as a separate file could have been a mess.

I've added an additional section in the ToDo for changes to the documentation such as adding or removing parts from the parts list.

Bring test points out to a pin-header to simplify hooking up to the board for debugging.

Each voltage level
Ground
All of the serial lines: TXD, RXD, SDA, SCL

Is there a reason you want to for serial comm lines? Only reason I could think of is if you have a logic analyzer, which I expect most people not to have

My oscilloscope can interpret serial communications. It's a not terribly expensive Siglent. Having it was useful when I was trying to debug some problems with the RoboClaws. You can get to these signals on J7, but getting an clip around those pins requires adding a jumper.

I'll also add that it's good to be able to do an easy "liveness test". If you can see signals on TXD but nothing on RXD, that means for some reason the motor controller is not responding. That's useful. Cheap enough to add these as debug points anyway.

could be nice to have just LEDs on the serial comms lines so you can tell exactly

could be nice to have just LEDs on the serial comms lines so you can tell exactly

yeah, i'm thinking we should have that as well

The reason for pins on the serial lines is to simplify debugging weird things. I have a strange issue with my rover where two of the roboclaws don't communicate if the USB hub is powered from the board. It works fine otherwise. I still don't know why, but I was able to at least confirm that the communications is garbled from those to RoboClaws. It's just a partial garble, not a complete garble. You can access most things from J7, but you can't really get oscilloscope clips around those pins without jumpers.

@apollokit Here's some of my feedback for the Schematic Changes:
Motor Board

It looks like you added filtering capacitors to all the encoder lines? I believe C19-C30 are them. I don't think we need filtering capacitors for the quadrature lines, in fact I think it would hurt them to have it. The caps we had before on the Absolute encoders were to act as filtering for the Analog signals that could fluctuate rapidly, but we shouldn't have that issue here.
J29 and J30 could be merged into a single 4 pin Terminal block, as all 4 of the wires go to the same device (the DROK volt/current meter)
Are the resistor values for R49-R52 what you want for these LEDs?  (also can you split up the ref des from the value for them, it bleeds together and looks like it says the designator is R49690)

Brain Board

The J6/J7 connectors don't have a lot of things on them, I thought our decision was to connect all the pins except for the ones we're currently using for other things ie. Estop,  LED controls etc.

The filter caps on the encoder lines are something I added. There is an often used snubber-circuit design that tags along with the encoders in a lot of motors. It's a cheap design and not very good but cheap wins out. It's normally not a problem but it can cause excessive ringing on the encoder signals if you are unlucky. The ringing confuses the RoboClaw and it miscalculates the motor speed. The motors cog as a result and don't run well at all. I ran into the problem with one or two of my ServoCity drive motors. The capacitors fix the problem by filtering out the ringing. The Gobilda motors probably use the same snubber circuit. The capacitors won't hurt anything and will clean up the encoder signals. I think all of my motors ran more cleanly after I added the caps.

The filter caps on the encoder lines are something I added. There is an often used snubber-circuit design that tags along with the encoders in a lot of motors. It's a cheap design and not very good but cheap wins out. It's normally not a problem but it can cause excessive ringing on the encoder signals if you are unlucky. The ringing confuses the RoboClaw and it miscalculates the motor speed. The motors cog as a result and don't run well at all. I ran into the problem with one or two of my ServoCity drive motors. The capacitors fix the problem by filtering out the ringing. The Gobilda motors probably use the same snubber circuit. The capacitors won't hurt anything and will clean up the encoder signals. I think all of my motors ran more cleanly after I added the caps.

Hm interesting, I haven't really observed any issues with them in the past. It doesn't hurt to leave it there and not install as well.

I'm a bit surprised that nobody else has had the problem. It's possible some have but without it being bad enough to worry about or even noticeable as a problem. The Pololu drive motors might have better encoders. I'm using the ServoCity HD Planetary Gear Motors so they definitely have the cheap snubbers. Wire length is a factor. One of my rear motors didn't really work at all and the other was not nearly as bad but still better after adding the capacitors. (Swapping motors won't fix the problem.) I ultimately added capacitors to all six motors. The caps will only be a problem if they are too big. It's been a while but I think I found the capacitor recommendation on BasicMicro's web site.

Adding a note to the kicad drawing about the capacitors being for filtering cheap snuggle circuits
Also wrt eric's response above:

@apollokit Here's some of my feedback for the Schematic Changes:
Motor Board

It looks like you added filtering capacitors to all the encoder lines? I believe C19-C30 are them. I don't think we need filtering capacitors for the quadrature lines, in fact I think it would hurt them to have it. The caps we had before on the Absolute encoders were to act as filtering for the Analog signals that could fluctuate rapidly, but we shouldn't have that issue here.
J29 and J30 could be merged into a single 4 pin Terminal block, as all 4 of the wires go to the same device (the DROK volt/current meter)
Are the resistor values for R49-R52 what you want for these LEDs?  (also can you split up the ref des from the value for them, it bleeds together and looks like it says the designator is R49690)

Brain Board

The J6/J7 connectors don't have a lot of things on them, I thought our decision was to connect all the pins except for the ones we're currently using for other things ie. Estop,  LED controls etc.

Motor board

Filtering caps: already addressed above
Ack for J29 and J30, adding todo
Splitting out the ref designators to make it more clear, don't know how i missed that. And yes, those are the values I calculated to give about 20 mA thru the leds. Those are ~exact, of course - I imagine there are more standard values i should be using

Brain board

ah, I've vaguely remember discussion about this. We wanted to just connect everything else to leds, right?

E_STOP lines should be pulled-up to 3.3V
RPI I2C header j67 - do we want more than one? -- going to add a 3x4 header
Power LEDs need to have standard size resistors -- see below
Remove 3.3V decoupling capacitor C18 from Raspberry PI -- decoupling caps go near the loads
Change 140 ohm resistors to 130 or 150
Change 690 ohm resistors to 680
Can J55-J66 be consolidated onto three headers? -- I think we have a solution for this; 3x4 pin headers for each block of four
+3.3 on the servo header needs a decoupling cap
Do we really need all of the extra V+ and GND headers on the servo controller? The row of signal pins should be enough to support the long side. Maybe put pins on the far short side for support

My latest code is pushed here, with most of

@apollokit @dcschooley
What design program are y'all using / do I need to view these files?
Thanks!
J Phelan

@apollokit @dcschooley
What design program are y'all using / do I need to view these files?
Thanks!
J Phelan

You can use KiCad to look at the files. It's free. The schematics are still a work in progress but we are getting there.

@dcschooley
There's not a .pro project file that lets me open the project in Control Board.zip.
JHP

@dcschooley
There's not a .pro project file that lets me open the project in Control Board.zip.
I WAS able to pull individual files, incl .pro, from your repo.
JHP

Ignore the .zip file. The updated files are in electrical/pcb/control_board

Todos from PCB convo on 12/16

[ ] all: look at logic for LED circuits
[ ] All: think about power distribution
[ ] David to measure: y spacing for pins 9,10 on ina260 footprint
[ ] David: to look at refdes for the board. Update pca9685, and others as needed
[ ] David: to look into xt60 vs powerpole connectors
[ ] Eric to finish off ina260 footprint
[ ] Eric to look into EN pin for 12v reg, connecting to rpi (might need a logic level shifter)
[ ] Eric to redo schematic symbol for 12v regulator
[ ] Eric to add more LEDs on other GPIO pins
[ ] Kit: assign someone on everything for double checking all the footprints/symbols
[ ] Kit: add another column in the spreadsheet for links to diagram
[ ] Kit: start looking at board shapes, where parts are going to go. Gen netlist, throw into pcb editor, get an idea of how things are going to fit together
[ ] Kit to add a keep out zone for the little lip thing on the molex connector
[ ] Kit to make i2c header3x4, with additional i2c connections available
[ ] Kit to consolidate switches with new symbol, footprint

The spacing between pins 9 and 10 on the ina260 is 0.2". We can either use the part I found earlier or have people cut a 3-pin header and remove the center pin. Perhaps more importantly, the distance between center of the screw holes and the centers of the pins is close to 1mm.

Made a spreadsheet with todos for v1 of rev2.0, here: https://docs.google.com/spreadsheets/d/11z5cvzA-VE1Sw-QGvqT-ah1rxA7fTCOmoqyYwPDZBWs/edit#gid=0

I propose we close this out in favor of my new PR here: https://github.com/nasa-jpl/open-source-rover/pull/396
There's simply too much going on in this PR at this point. All the work that was done for this is reflected in that other pull request, just cleaned up and consistent with @Achllle's latest updates to the documentation.
@dcschooley @Achllle @ericjunkins thoughts?

closing because #396 was merged in

authors: Achllle JHPHELAN SConaway apollokit dcschooley ericjunkins

repo: nasa-jpl/open-source-rover


text:
Script to Print Versions of Software on Robot

For Issue #86

@kbrowne15 Can you add the HLP stuff where I put a todo? Thanks!

repo: nasa/astrobee


text:
Time State flags near duplicate functions, one skips IsToneGood

CFE_TIME_GetStateFlags in cfe_time_utils.c is nearly identical to CFE_TIME_GetClockInfo in cfe_time_api.c except GetStateFlags doesn't include IsToneGood flag (both convert state data to flags).
Recommend removing GetStateFlags (internal, only used in HK generation) and replace with call to GetClockInfo (From API).
From Keegan Moore email thread (5/6/2019)

Trac comment by jhageman on 2019-07-10 10:40:32:
See [changeset:961b83f] in trac-309-time-state-flags.

Imported from trac issue 309.  Created by jhageman on 2019-07-10T10:17:21, last modified: 2019-07-17T19:07:16

Trac comment by jhageman on 2019-07-10 13:30:17:
CCB 7/10/2019 - code reviewed and approved for test

Trac comment by jhageman on 2019-07-10 10:48:44:
CCB - flagged for code review, may need change to EDS telemetry definition packet.

Trac comment by jphickey on 2019-07-11 11:31:02:
Merged to ic-ccb-2019-07-10 for integration test

Trac comment by jphickey on 2019-07-11 12:40:56:
This is causing the unit test to fail, because the UT code is still calling CFE_TIME_GetStateFlags
Most likely these test cases can be simply removed as the GetClockInfo function should already be covered.

Trac comment by jphickey on 2019-07-11 13:21:36:
Follow-on commit to fix unit test: [changeset:470055b]

Trac comment by jhageman on 2019-07-17 16:53:39:
CCB 7/17/2019 - approved for merge to dev, included review of [changeset:470055b]

Trac comment by jphickey on 2019-07-17 19:07:16:
Merged to "development" branch

repo: nasa/cFE


text:
ubuntu20.04 启动报错

环境：ubuntu20.04
安装： 2.1.13-amd64
12.11.10版本都试过都能打开，13版本安装后无法打开，
直接用命令dingtalk启动，报错
[69706:1216/113329.612759:ERROR:nss_util.cc(286)] After loading Root Certs, loaded==false: NSS error code: -8018

先不要升级，目前发现打成二进制包后有问题

发了新版本了，你下载试试https://github.com/nashaofu/dingtalk/releases/tag/v2.1.13

可以了

repo: nashaofu/dingtalk


text:
Parameterize all queries

I will parameterize all queries we've made in the style of how login.php is done.

closing as completed


text:
Incorrect Documentation?

Sorry for the question, but the documentation in the README implies one can simply:
$ npm install mocha-phantomjs-core
$ phantomjs mocha-phantomjs-core.js my-tests.html

However if I try to do this I get the following error from phantom:
Can't open 'mocha-phantomjs-core.js'

I can resolve this by giving phantomjs the relative path to the mocha-phantomjs-core.js file, ie:
phantomjs ./node_modules/mocha-phantomjs-core/mocha-phantomjs-core.js my-tests.html

Should the README be updated to reflect this or am I missing a trick?

I added some examples. usually in those usage examples where the binary refers to itself, specifying the location to the binary (or in this case the script) is up to the user. but I'm sure 99.9% of usage is via npm so it's good to add.

authors: jonny-improbable nathanboktae

repo: nathanboktae/mocha-phantomjs-core


text:
space char in bolt/spout id causes UI exception

If there is a space charater in bolt/spout id (such as "generate spout" bellow), the storm ui can not display. URISyntaxException is thrown in ui.log.
The cause is that backtype.storm.ui.core core.clj passes bolt/spout id as part of url. And hiccup use the url to create a java URI. But java URI does not accept space.
Instead backtype.storm.ui.core core.clj could encode bolt/spout id by java URLEncoder.encode() to avoid this problem.
Caused by: java.net.URISyntaxException: Illegal character in path at index 51: /topology/testdedup-9-1325861645/component/generate spout
at java.net.URI$Parser.fail(URI.java:2809)
at java.net.URI$Parser.checkChars(URI.java:2982)
at java.net.URI$Parser.parseHierarchical(URI.java:3066)
at java.net.URI$Parser.parse(URI.java:3024)
at java.net.URI.(URI.java:578)
at hiccup.core$resolve_uri.invoke(core.clj:314)
at hiccup.page_helpers$link_to.doInvoke(page_helpers.clj:93)
at clojure.lang.RestFn.applyTo(RestFn.java:140)
at clojure.core$apply.invoke(core.clj:540)
at hiccup.core$add_optional_attrs$fn__5069.doInvoke(core.clj:293)
at clojure.lang.RestFn.invoke(RestFn.java:422)
at backtype.storm.ui.core$component_link.invoke(core.clj:348)
at backtype.storm.ui.core$spout_comp_table$iter__6022__6026$fn__6027.invoke(core.clj:359)
at clojure.lang.LazySeq.sval(LazySeq.java:42)
... 34 more

Fixed for 0.7.1

Thanks!

authors: nathanmarz xiaokang

repo: nathanmarz/storm


text:
Validation always fails in Web version

Describe the bug
When inputting a valid phone number for any country in the Web version, the validation fails. When running the same code on a phone or in an emulator, these same numbers are accepted as valid.
Package version
intl_phone_number_input: ^0.7.0+2
Flutter version
Flutter 2.10.4
To Reproduce
Steps to reproduce the behavior:

Code Snippet

import 'package:flutter/material.dart';
import 'package:intl_phone_number_input/intl_phone_number_input.dart';

void main() => runApp(const MyApp());

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    var darkTheme = ThemeData.dark().copyWith(primaryColor: Colors.blue);

    return MaterialApp(
      title: 'Demo',
      themeMode: ThemeMode.dark,
      darkTheme: darkTheme,
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: Scaffold(
        appBar: AppBar(title: const Text('Demo')),
        body: const MyHomePage(),
      ),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key}) : super(key: key);

  @override
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  final GlobalKey<FormState> formKey = GlobalKey<FormState>();

  final TextEditingController controller = TextEditingController();
  String initialCountry = 'NG';
  PhoneNumber number = PhoneNumber(isoCode: 'NG');

  @override
  Widget build(BuildContext context) {
    return Form(
      key: formKey,
      child: Column(
        mainAxisAlignment: MainAxisAlignment.center,
        children: <Widget>[
          InternationalPhoneNumberInput(
            onInputChanged: (PhoneNumber number) {
              print(number.phoneNumber);
            },
            onInputValidated: (bool value) {
              print(value);
            },
            selectorConfig: const SelectorConfig(
              selectorType: PhoneInputSelectorType.BOTTOM_SHEET,
            ),
            ignoreBlank: false,
            autoValidateMode: AutovalidateMode.disabled,
            selectorTextStyle: const TextStyle(color: Colors.black),
            initialValue: number,
            textFieldController: controller,
            formatInput: false,
            keyboardType:
            const TextInputType.numberWithOptions(signed: true, decimal: true),
            inputBorder: const OutlineInputBorder(),
            onSaved: (PhoneNumber number) {
              print('On Saved: $number');
            },
          ),
          ElevatedButton(
            onPressed: () {
              formKey.currentState?.validate();
            },
            child: const Text('Validate'),
          ),
          ElevatedButton(
            onPressed: () {
              getPhoneNumber('+15417543010');
            },
            child: const Text('Update'),
          ),
          ElevatedButton(
            onPressed: () {
              formKey.currentState?.save();
            },
            child: const Text('Save'),
          ),
        ],
      ),
    );
  }

  void getPhoneNumber(String phoneNumber) async {
    PhoneNumber number =
    await PhoneNumber.getRegionInfoFromPhoneNumber(phoneNumber, 'US');

    setState(() {
      this.number = number;
    });
  }

  @override
  void dispose() {
    controller.dispose();
    super.dispose();
  }
}

Access Web UI
Input any valid phone number (eg US +1 800 555 1234)
Press validate

Expected behavior
Number should be valid.
Screenshots

** Targeted platforms (please complete the following information):**

Web [✔ or ❌]

Additional context
Add any other context about the problem here.

Check here ISSUE 297 for possible duplicated


text:
Error: TypeError: params.extensions.map is not a function when openFilePicker

When call openFilePicker console return: Error: TypeError: params.extensions.map is not a function
My SelectModal.vue:
openPicker(item) {
                switch (item.key) {
                    case 'photo':
                        this.mediaService.showCameraPicker().then((files) => {
                            item.files = files;
                            this.$modal.close(item);
                        });
                        break;
                    case 'gallery':
                        this.mediaService.showGalleryPicker().then((files) => {
                            item.files = files;
                            this.$modal.close(item);
                        });
                        break;
                    case 'file':
                        this.mediaService.showFilePicker().then((files) => {
                            item.files = files;
                            this.$modal.close(item);
                        });
                        break;
                    default:
                        this.$modal.close(item);
                        break;
                }
            },

My MediaService.js:
import { openFilePicker } from '@nativescript-community/ui-document-picker';

export default class MediaService {
    showCameraPicker() {
        openFilePicker({
            extensions: 'jpg',
            multipleSelection: true,
        });
    }
    showGalleryPicker() {
        openFilePicker({
            extensions: 'jpg',
            multipleSelection: true,
        });
    }
    showFilePicker() {
        openFilePicker({
            extensions: 'pdf',
            multipleSelection: true,
        });
    }
}

@xpalacincreditoh the errors tells you that extensions should be an array

authors: farfromrefug xpalacincreditoh


text:
Keyvisuals needed

Hey @janlauber
I need the logos and icons from Natron to implement in the GUI.

Got them, thanks. I added them to /src/Assets

repo: natron-io/tenant-dashboard


text:
Is it possible to detect if any subscriber received my message?

After publishing a message i wanted to know if any subscriber received it, is it possible?

@ericholiveira the only way for you to know if someone got it would be to send the message as a request/reply.
If you needed to know that at least one client got the message, you would:
// Request with Auto-Unsubscribe. Will unsubscribe after the first response is received via {'max':1}
nats.request('help', null, {'max':1}, function(response) {
  console.log('Got a response for help: ' + response);
});

The clients for the request are normal subscribers. They simply use the replyTo inbox subject to send the response:
// Replies
nats.subscribe('help', function(request, replyTo) {
  nats.publish(replyTo, 'I can help!');
});

Hope it helps.

authors: aricart ericholiveira

repo: nats-io/node-nats


text:
Write more docs!

I am willing to take this on, but if anyone wants to lend a hand, please do!
I've peppered the entire Rust codebase with comments and descriptions of what everything is doing, and very soon I'm going to create a video explaining exactly how the macros work and where to find the key ingredients.
Regardless, as we get closer to beta release, we're gonna need some docs!
Feel free to join me in grabbing anything worth covering in detail from the codebase and documenting it in the markdown files on the doc site: docs/md

Hi, I can take this on with you! Would be my first time writing documentation for a project such as this so might need a bit of help at the start.

go for it, mate! The code blocks on the docs site look pretty shaky right now, as mentioned in #52 but don't let that stop you

Alright :), will start going through the code and see where I can contribute. If I have any questions is this a good medium to ask them or is there any other specific channel where I could post them?

authors: ajwadjaved buffalojoec

repo: nautilus-project/nautilus


text:
🛑 Harmony Bot Website is down

In 0ea5197, Harmony Bot Website ($HARMONY_WEB) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Bot Website is back up in 3654bb5.


text:
🛑 Harmony Bot Website is down

In f5aa5ab, Harmony Bot Website ($HARMONY_WEB) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Bot Website is back up in 0296ecd.


text:
🛑 Harmony Bot is down

In 91cbd77, Harmony Bot ($HARMONY) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Bot is back up in 9ac44ef.


text:
🛑 Harmony Bot Website is down

In 56d8374, Harmony Bot Website ($HARMONY_WEB) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Bot Website is back up in 1388fda.


text:
🛑 Harmony Backup Bot is down

In d6731ae, Harmony Backup Bot ($HARMONY_BACKUP) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Backup Bot is back up in 5ff2b44.


text:
🛑 Harmony Bot Website is down

In 9c33758, Harmony Bot Website ($HARMONY_WEB) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Bot Website is back up in d1222cb.


text:
🛑 Harmony Bot Website is down

In a62d118, Harmony Bot Website ($HARMONY_WEB) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Bot Website is back up in f768cdd.

Resolved: Harmony Bot Website is back up in f768cdd.


text:
🛑 Harmony Bot Website is down

In 9e04c56, Harmony Bot Website ($HARMONY_WEB) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Bot Website is back up in 8cf8884.


text:
🛑 Harmony Bot Website is down

In ca6ebb3, Harmony Bot Website ($HARMONY_WEB) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Harmony Bot Website is back up in 4eeb995.


text:
will hibernate plugin be added?

Which module is your feature request related to?
Plugin
Is your feature request related to a problem?
some web projects prefer ORM framework for hibernate

Hi @meifamao
hibernate is already famous all over the world, but mybatis still prevails in Korea. As far as I know, some projects in Pinpoint already use mybatis. so, I think If they support hibernate, it is expected to take a lot of work.

authors: DevelopDestroyer meifamao

repo: naver/pinpoint


text:
pinpoint-agent 설정 후, Connection refused 오류 질문드립니다.

pinpoint-version : 2.0.3
로컬 환경 : MacOSX
원격 서버 : toast cloud, ubuntu 16.04, docker

안녕하세요 APM으로 pinpoint를 적용해보려고 하는 개발자입니다.
기본 컴포넌트 환경에 대한 설정은 원격지 클라우드 서버에 pinpoint-docker로 설치 진행하였구요.
로컬에서 개발하고 있는 jar로 컴파일된 spring app에 agent 바이너리와 설정만 가져와서 붙여보는 작업을 하고 있는데,
java로 agent 설정을 추가한 app 실행 시,
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /127.0.0.1:9991
오류가 나며 agent가 collector에 붙지 않는 상황입니다.
관련된 이슈들 검색해봐도 도저히 힌트가 나오지 않아 부득이 질문 드리게 되었습니다.
pinpoint-docker의 원격지 서버 세팅은 비교적 간단하였기에 바로 진행할 수 있었고,
필요한 외부 포트 개방 작업(tcp, udp 9991-9996)도 해두었습니다.
로컬에서는 pinpoint-agent 바이너리 패키지 다운받아서 pinpoint.config 에서 원격지 ip만 변경하였고,
/script/networktest.sh까지 정상 작동 되는 것을 확인하였습니다.

gRPC Mode

CLASSPATH=./tools/pinpoint-tools-2.0.3.jar: 2020-06-25 21:34:06 INFO(com.navercorp.pinpoint.bootstrap.config.DefaultProfilerConfig) configuration loaded successfully.
Transport Module set to GRPC
TCP Base:// 133.186.151.175
=> 133.186.151.175:9991 [SUCCESS]
TCP Meta:// 133.186.151.175
=> 133.186.151.175:9991 [SUCCESS]
TCP Stat:// 133.186.151.175
=> 133.186.151.175:9992 [SUCCESS]
TCP Span:// 133.186.151.175
=> 133.186.151.175:9993 [SUCCESS]

THRIFT mode

2020-06-25 21:33:07 INFO(com.navercorp.pinpoint.bootstrap.config.DefaultProfilerConfig) configuration loaded successfully.
Transport Module set to THRIFT
UDP-STAT:// 133.186.151.175
=> 133.186.151.175:9995 [SUCCESS]
UDP-SPAN:// 133.186.151.175
=> 133.186.151.175:9996 [SUCCESS]
TCP:// 133.186.151.175
=> 133.186.151.175:9994 [SUCCESS]

이후 로컬에서 작동하는 pinpoint-docker를 끄고, 원격서버 ip로 세팅한 바이너리를 실행시키는데,
다음과 같은 에러 시도가 반복되면서 agent 가 연결되지 않는 상황입니다.
2020-06-25 13:35:03 INFO  Error. request=apiId: 1176 apiInfo: "io.lettuce.core.AbstractRedisReactiveCommands.geopos(java.lang.Object key, java.lang.Object[] members)" line: 648, cause=UNAVAILABLE: io exception
io.grpc.StatusRuntimeException: UNAVAILABLE: io exception
at io.grpc.Status.asRuntimeException(Status.java:526)
at io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onClose(ClientCalls.java:420)
at io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:459)
at io.grpc.internal.ClientCallImpl.access$300(ClientCallImpl.java:63)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.close(ClientCallImpl.java:546)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.access$600(ClientCallImpl.java:467)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:584)
at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /127.0.0.1:9991
Caused by: java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:330)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:334)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:702)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
pinpoint-docker 안에 있는 가장 간단한 pinpoint-agent-attach-example에서 진행해보아도 같은 오류가 발생하였습니다.
~/Workspace/devops/pinpoint-docker/pinpoint-agent-attach-example/java/build$  java -javaagent:${AGENT_PATH}/pinpoint-bootstrap.jar -Dpinpoint.agentId=sample -Dpinpoint.applicationName=sample Sample
pinpoint.config 내용입니다. ip말고는 별다르게 수정한 사항은 없었습니다.
# Pinpoint agent configuration
#
# Profiles
#  - -Dpinpoint.profiler.profiles.active=release or local
#  - Modify `pinpoint.profiler.profiles.active=release` in $PINPOINT_AGENT_DIR/pinpoint.config
# Custom Profile
#  - 1. Create a custom profile in $PINPOINT_HOME/profiles/MyProfile
#    - Add pinpoint-env.config & log4j.xml
#  - 2. -Dpinpoint.profiler.profiles.active=MyProfile
# Support external property
#  - -Dpinpoint.config=$MY_CONFIG_PATH/pinpoint.config
pinpoint.profiler.profiles.active=release

# GRPC or THRIFT
profiler.transport.module=GRPC
###########################################################
# gRPC Configuration                                      #
###########################################################
profiler.transport.grpc.collector.ip=133.186.151.175

# placeHolder support "${key}"
# Agent
profiler.transport.grpc.agent.collector.ip=${profiler.transport.grpc.collector.ip}
profiler.transport.grpc.agent.collector.port=9991
profiler.transport.grpc.agent.sender.channel.executor.queue.size=1000
profiler.transport.grpc.agent.sender.request.timeout.millis=6000
profiler.transport.grpc.agent.sender.keepalive.time.millis=30000
profiler.transport.grpc.agent.sender.keepalive.timeout.millis=60000
profiler.transport.grpc.agent.sender.connect.timeout.millis=3000
profiler.transport.grpc.agent.sender.headers.size.max=8K
profiler.transport.grpc.agent.sender.message.inbound.size.max=4M
profiler.transport.grpc.agent.sender.flow-control.window.size=1M
profiler.transport.grpc.agent.sender.write.buffer.highwatermark=32M
profiler.transport.grpc.agent.sender.write.buffer.lowwatermark=16M

# Metadata
profiler.transport.grpc.metadata.collector.ip=${profiler.transport.grpc.collector.ip}
profiler.transport.grpc.metadata.collector.port=9991
profiler.transport.grpc.metadata.sender.executor.queue.size=1000
profiler.transport.grpc.metadata.sender.channel.executor.queue.size=1000
profiler.transport.grpc.metadata.sender.request.timeout.millis=6000
profiler.transport.grpc.metadata.sender.retry.max.count=3
profiler.transport.grpc.metadata.sender.retry.delay.millis=1000
profiler.transport.grpc.metadata.sender.keepalive.time.millis=30000
profiler.transport.grpc.metadata.sender.keepalive.timeout.millis=60000
profiler.transport.grpc.metadata.sender.connect.timeout.millis=3000
profiler.transport.grpc.metadata.sender.headers.size.max=8K
profiler.transport.grpc.metadata.sender.message.inbound.size.max=4M
profiler.transport.grpc.metadata.sender.flow-control.window.size=1M
profiler.transport.grpc.metadata.sender.write.buffer.highwatermark=32M
profiler.transport.grpc.metadata.sender.write.buffer.lowwatermark=16M

# Stat
profiler.transport.grpc.stat.collector.ip=${profiler.transport.grpc.collector.ip}
profiler.transport.grpc.stat.collector.port=9992
profiler.transport.grpc.stat.sender.executor.queue.size=1000
profiler.transport.grpc.stat.sender.channel.executor.queue.size=1000
profiler.transport.grpc.stat.sender.request.timeout.millis=6000
profiler.transport.grpc.stat.sender.keepalive.time.millis=30000
profiler.transport.grpc.stat.sender.keepalive.timeout.millis=60000
profiler.transport.grpc.stat.sender.connect.timeout.millis=3000
profiler.transport.grpc.stat.sender.headers.size.max=8K
profiler.transport.grpc.stat.sender.message.inbound.size.max=4M
profiler.transport.grpc.stat.sender.flow-control.window.size=1M
profiler.transport.grpc.stat.sender.write.buffer.highwatermark=32M
profiler.transport.grpc.stat.sender.write.buffer.lowwatermark=16M

# Span
profiler.transport.grpc.span.collector.ip=${profiler.transport.grpc.collector.ip}
profiler.transport.grpc.span.collector.port=9993
profiler.transport.grpc.span.sender.executor.queue.size=1000
profiler.transport.grpc.span.sender.channel.executor.queue.size=1000
profiler.transport.grpc.span.sender.request.timeout.millis=6000
profiler.transport.grpc.span.sender.keepalive.time.millis=30000
profiler.transport.grpc.span.sender.keepalive.timeout.millis=60000
profiler.transport.grpc.span.sender.connect.timeout.millis=3000
profiler.transport.grpc.span.sender.headers.size.max=8K
profiler.transport.grpc.span.sender.message.inbound.size.max=4M
profiler.transport.grpc.span.sender.flow-control.window.size=1M
profiler.transport.grpc.span.sender.write.buffer.highwatermark=32M
profiler.transport.grpc.span.sender.write.buffer.lowwatermark=16M
profiler.transport.grpc.span.sender.discardpolicy.logger.discard.ratelimit=1
profiler.transport.grpc.span.sender.discardpolicy.maxpendingthreshold=1024

# This configuration enable some function of netty
# Functions are available without the this configuration when using jdk8 and below,
profiler.system.property.io.netty.tryReflectionSetAccessible=true
# disable netty directbuffer
profiler.system.property.io.netty.noPreferDirect=false

###########################################################
# Thrift Configuration                                    #
###########################################################
profiler.collector.ip=133.186.151.175

# placeHolder support "${key}"
profiler.collector.span.ip=${profiler.collector.ip}
profiler.collector.span.port=9996

# placeHolder support "${key}"
profiler.collector.stat.ip=${profiler.collector.ip}
profiler.collector.stat.port=9995

# placeHolder support "${key}"
profiler.collector.tcp.ip=${profiler.collector.ip}
profiler.collector.tcp.port=9994

###########################################################
# Profiler Global Configuration                           #
###########################################################
profiler.enable=true

# Application namespace
# Differentiate from external pinpoint agents. (e.g., com.pinpoint)
profiler.application.namespace=

profiler.interceptorregistry.size=8192

# Manually override jvm vendor name (Oracle, IBM, OpenJDK, etc)
# You probably won't ever need to set this value.
profiler.jvm.vendor.name=

# Manually override agent's OS name (MAC, Window, Linus, AIX, HP_UX, BSD)
# You probably won't ever need to set this value.(to collect file descriptor)
profiler.os.name=

# Interval (in milliseconds) at which agent stat data is collected. (default : 5000, min : 1000, max : 5000)
profiler.jvm.stat.collect.interval=5000
# Number of agent stat data sent to the collector in a single batch. (default : 6)
profiler.jvm.stat.batch.send.count=6

# Allow to add detailed collector's metrics
profiler.jvm.stat.collect.detailed.metrics=true

# Allow sampling.
profiler.sampling.enable=true

# 1 out of n transactions will be sampled where n is the rate. (1: 100%, 20: 5%)
profiler.sampling.rate=1

# Permits per second, if throughput is 0, it is unlimited.
# "New" is a transaction that is newly traced.
profiler.sampling.new.throughput=0
# "Continue" is a transaction that is already being tracked.
profiler.sampling.continue.throughput=0

# Allow buffering when flushing span to IO.
profiler.io.buffering.enable=true

# How many spans to store if buffering enabled.
profiler.io.buffering.buffersize=20

###########################################################
# Base Tcp Sender                                        #
###########################################################
# Allow TCP data command.
profiler.tcpdatasender.command.accept.enable=true
profiler.tcpdatasender.command.activethread.enable=true
profiler.tcpdatasender.command.activethread.count.enable=true
profiler.tcpdatasender.command.activethread.threaddump.enable=true
profiler.tcpdatasender.command.activethread.threadlightdump.enable=true

profiler.tcpdatasender.client.write.timeout=3000
profiler.tcpdatasender.client.request.timeout=3000
profiler.tcpdatasender.client.reconnect.interval=3000
profiler.tcpdatasender.client.ping.interval=300000
profiler.tcpdatasender.client.handshake.interval=60000

profiler.tcpdatasender.client.write.buffer.highwatermark=32m
profiler.tcpdatasender.client.write.buffer.lowwatermark=16m

# Interval to retry sending agent info. Unit is milliseconds.
profiler.agentInfo.send.retry.interval=300000

###########################################################
# Stat Data Sender                                        #
###########################################################
# Should keep in mind
# 1. Loadbancing : TCP transport load balancing is per connection.(UDP transport loadbalancing is per packet)
# 2. In unexpected situations, UDP has its own protection feature (like packet loss etc.), but tcp does not have such a feature. (We will add protection later)
profiler.statdatasender.transport.type=UDP

# These settings are active only when using UDP.
# Capacity of the StatDataSender write queue.
profiler.statdatasender.write.queue.size=5120
#profiler.statdatasender.socket.sendbuffersize=1048576
#profiler.statdatasender.socket.timeout=3000
profiler.statdatasender.chunk.size=16384
profiler.statdatasender.socket.type=OIO

# These settings are active only when using TCP.
profiler.statdatasender.write.buffer.highwatermark=16m
profiler.statdatasender.write.buffer.lowwatermark=8m

###########################################################
# Span Data Sender                                        #
###########################################################
# Should keep in mind
# 1. Loadbancing : TCP transport load balancing is per connection.(UDP transport loadbalancing is per packet)
# 2. In unexpected situations, UDP has its own protection feature (like packet loss etc.), but tcp does not have such a feature. (We will add protection later)
profiler.spandatasender.transport.type=UDP

# These settings are active only when using UDP.
# Capacity of the SpanDataSender write queue.
profiler.spandatasender.write.queue.size=5120
#profiler.spandatasender.socket.sendbuffersize=1048576
#profiler.spandatasender.socket.timeout=3000
profiler.spandatasender.chunk.size=16384
profiler.spandatasender.socket.type=OIO

# These settings are active only when using TCP.
profiler.spandatasender.write.buffer.highwatermark=16m
profiler.spandatasender.write.buffer.lowwatermark=8m

# Trace Agent active thread info.
profiler.pinpoint.activethread=true

# Trace DataSource
profiler.pinpoint.datasource=true

# Deadlock Monitor
profiler.monitor.deadlock.enable=true
profiler.monitor.deadlock.interval=60000

## Call Stack
# Set max depth, if -1 is unlimited and min is 2.
profiler.callstack.max.depth=64

# weather or not to propagate exceptions occurred at interceptor
profiler.interceptor.exception.propagate=false

# Allow bytecode framework (ASM only)
profiler.instrument.engine=ASM

# bytecode dump option
# java bytecode debug option
bytecode.dump.enable=false
#bytecode.dump.classlist=com.pinpoint.user.UserService,com.pinpoint.debug.TestClass
bytecode.dump.classlist=
bytecode.dump.bytecode=false
bytecode.dump.verify=false
bytecode.dump.asm=false

# Matcher
profiler.instrument.matcher.enable=true
# Matcher cache. max size is 64.
profiler.instrument.matcher.interface.cache.size=4
profiler.instrument.matcher.interface.cache.entry.size=16
profiler.instrument.matcher.annotation.cache.size=4
profiler.instrument.matcher.annotation.cache.entry.size=4
profiler.instrument.matcher.super.cache.size=4
profiler.instrument.matcher.super.cache.entry.size=4

# Lambda expressions.
profiler.lambda.expressions.support=true

# Proxy HTTP headers.
# Please see (https://github.com/naver/pinpoint/blob/master/doc/proxy-http-header.md) for more information.
profiler.proxy.http.header.enable=true

# HTTP status code with request failure.
# 1xx, 2xx, 3xx, 4xx, 5xx, 100, 101, 200, 201, ... 501, 502, 503, 504, 505
# e.g. profiler.http.status.code.errors=5xx, 401, 403
profiler.http.status.code.errors=5xx

###########################################################
# application type                                        #
###########################################################
#profiler.applicationservertype=TOMCAT
#profiler.applicationservertype=BLOC

# Needs to be a comma separated list of plugin's groupId:artifactId
# Ex: com.navercorp.pinpoint:pinpoint-tomcat-plugin, com.navercorp.pinpoint:pinpoint-jboss-plugin
profiler.plugin.load.order=
profiler.plugin.disable=

###########################################################
# Thread
###########################################################
# which package of runnable(callable) instance can be thread plugin trace
# Set the package name to track
# eg) profiler.thread.match.package=com.company.shopping.cart, com.company.payment
profiler.thread.match.package=

혹시 제쪽에서 config 잘못된 점이 있는지 한번 살펴봐주시고
pinpoint-docker 쪽에 이슈 남겨야 되는 사항이면 코멘트 부탁드립니다.
감사합니다.

안녕하세요 핀포인트를 개발중인 구태진입니다.
저희가 2.0.0 부터는 다양한 환경에 대응하기 위해 Profiles를 적용함으로써
profiles/{$profile}/pinpoint-env.config
를 먼저 읽게 되어 있습니다.
이런 이유로 pinpoint.config에 설정하신
profiler.transport.grpc.collector.ip=133.186.151.175

해당 설정이 적용이 되지 않아 127.0.0.1로 접근한 것으로 예상됩니다.
profiles/{$profile}/pinpoint-env.config 의 profiler.transport.grpc.collector.ip설정을 변경하시거나
에이전트 실행시에 -Dprofiler.transport.grpc.collector.ip=133.186.151.175
로 실행하시면 기대하시는 형태로 동작할 것으로 예상됩니다.
관련 문서는
https://github.com/naver/pinpoint/blob/v2.0.0/doc/installation.md#profiles-2
에서 확인이 가능합니다.
참고로, 저희가 영어로만 문의를 받고 있어서,
이슈가 해결이 되신다면 빠르게 닫아주시기를 부탁드립니다.
감사합니다.