[3.2.2 beta1] InspectorDock doesn't display porperties when opening a resource

Godot version:
3.2.2 beta1
OS/device including version:
Fedora 31
Issue description:
Inspector dock doesn't display properties when selecting an AnimationNode in an AnimationNodeBlendTree. It works in 3.2.1 stable (from flathub), see the screenshot; it's the same project.
Edit:I think the issue may be caused by GraphEdit. I created a VisualScript file and have the same issue there.
After more testing; this happens when opening any resource.
Steps to reproduce:
Create an AnimationNode and click it with your mouse to focus it. The Inspector dock will only show the Inspector sections.
Minimal reproduction project:

MinimalProject.zip

On a fresh install of Fedora 32 and using Godot 3.2.2 stable (Flathub) this behaviour doesn't happen anymore. I believe I just had a general installation problem because I noticed other weird problems (for ex. that my preview icons in the project manager were messed up...). So I am closing this.


Differences in segmentation results

Dear all,
First of all I would like to thank you for sharing the code to preprocess the IMC data. I'm just starting to approach the analysis of IMC data, so I have little experience.
I used publicly available data to compare their results with my segmentation (I used the deepcell approach). Unfortunately my mask was not as good as the one posted (attached). Do you have any suggestions for me to improve the result? Did I do something wrong before?
I also attached the panel.csv used for my segmentation process.
A thousand thanks.
Best,
Domenico
mine mask:

published:

panel.csv

Hi @DomenicoSkyWalker89
Could you please give us a bit more information.

What data are you referring to?
Which steinbock version are you using?
Does the panel match the acquired channels?
Does the panel match the panel of the original data?
Are they using deepcell?

Please also carefully read through the documentation. It looks like you are only specifying nuclear channels for segmentation

Dear @nilseling,
thanks for the fast replay.

I'm referring to data from this paper: https://www.nature.com/articles/s43856-022-00197-2;
The version of steinbock I'm using is 0.16.1;
3-4) I downloaded the panel they shared in the paper so it should match perfectly the original data;
5)No, they used their own pipeline for the segmentation;

D

And you did not modify the panel?

I mean the order and number of row is the same. I selected the first and third column renaming them as 'channel' and 'name' to create my own panel to use in steinbock.
Best,
Domenico

@jwindhager just quickly checking here that using 0 instead of 1 for the nuclear markers and 1 instead of 2 for the cytoplasmic markers doesn't make a difference, right? The important thing is that the first grouping level is nuclear and the second one is cytoplasmic.

Hi @DomenicoSkyWalker89, please let us know all the steinbock commands that you used to generate the TIFs. Did you generate the TIFs from raw data or did you start from TIFs not generated by steinbock?

Dear @Milad4849 I started from TIFs not generated by steinbock, as they provided. The result I obtained can be due to bad training on 50x50 crops?
List of command used:

steinbock classify ilastik prepare --cropsize 50 --seed 123
steinbock apps ilastik (there i followed the https://www.ilastik.org/documentation/pixelclassification/pixelclassification.html#training-the-classifier)
3)steinbock classify ilastik run
4)steinbock segment deepcell --minmax

Best,
Domenico

@Milad4849 I just saw that the 50 pixel crops are the default in the steinbock docs. It would be good to align this with the IMC Segmentation Pipeline. I would say that 50 pixel crops are too small for ilastik training.

Dear team,
As suggested by @Milad4849, if you are adopting segmentation using CellProfiler, 50 pixel crops are too small for ilastik training, so I simply increased to 100 pixels getting better results.
I preferred to use Deepcell for the segmentation phase which does not require a previous phase of pixel classification (correct me if I'm wrong). The problem I observed was related to the low expression of some membrane proteins that I chose for segmentation (I selected them from the excel file they provided but some showed huge background). Anyway, selecting membrane proteins with low background helped me improve segmentation (images attached). The result was not identical because I lost some cells but acceptable (I'll study and work on it).
Best,
Domenico
published:

mine (in blue DNA1):


Fix #4994

Fix #4994 , error: `this' was not captured for this lambda function
Checklist:

[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have added or updated relevant unit/integration/functional/e2e tests
[ ] I have made corresponding changes to the documentation

For repository code-owners and collaborators only

[ ] I have assigned this pull request to a milestone

superseded by #5468


SQL updates for new DB

Brief Description
Updated SQL queries for the following routers:

Tickets
Tasks
Newsletter
Events

Added a column to the eventinstances table that allows a default ticket type to be set for the instance
Fixed my earlier attempt to set 'wondertix' as the default database name
References Issue
Partial resolution of issue #118
Type of change

[ ] Bug fix
[ ] Feature
[x] Major change (potentially breaking, list anything that is broken below)
[ ] Documentation

Breaking Changes
There are multiple new SQL queries that will break requests, either by requiring more/less/different data to be provided, or will end up returning more/fewer datapoints. Will require some front end assistance to resolve.
Testing done

[x] Docker was used.
[ ] Docker was not used and I have listed my configuration below.

System Specifications:

Operating System:
Node Version:
NPM Version:

Checklist:

[x] My code follows the styling guidelines.
[ ] I have added unit tests and verified that they pass.
[s] I have used the linter and fixed any linting issues.
[x] I have commented the code.
[x] I have adjusted the documentation to match the changed code.
[x] Prior to submitting the PR, I made sure the latest changes were merged with my branch.
[ ] Existing tests pass locally with changes.

Renamed the following tables:
customers -> contacts
customerorders -> orders

Yes, I just renamed the tables. I told him what i was doing and he'll either do the same renaming process on his end or pull these changes before he pushes anything

Thanks for catching these, I'm fixing them in my next push

OK I fixed the errors you pointed out, with the exception of changing that one route to a put.
I was working on the other routers when I realized it might be better to create a more appropriately named branch for the ticket/event/newsletter router fixes, because they're going to require some front end work to resolve the changes and having a branch dedicated to that work makes the collaboration easier.
If these changes look good I'd like to merge to dev, then create a branch for that work


Hello, I can't find the pretrained model  in the trained_models as you have mentioned.

Hi! Sorry about that, I just uploaded them and now you should find them under trained_models. Those under trained_models/fc4_cwp are meant to be used with confidence-weighted-pooling activated while those under  trained_models/fc4_sum with confidence-weighted-pooling not activated. All models come with the training metrics and a dump of the network architecture.


API 이슈

Call 하니까 이러네...
해결되면 만들자...
{
    "error": "Api is disabled due to throttling we are getting from Bluehole.  Please do not contact us, we will re-enable the API as soon as it's possible. We're sorry for any trouble this has caused, but it's outside of our control.",
    "code": 3
}

URL: https://pubgtracker.com/site-api

PUBG 쪽에서 official API 제공할테니 그거 사용하면 될 듯


Loader data not type safe when returning an interface

Which project does this relate to?
Router
Describe the bug
Route.useLoaderData does not retain the type safety of loaded data when the data is a Promise<T>, where T is an interface. The actual returned type is the shape of the object without the interface.
Your Example Website or App
https://stackblitz.com/edit/tanstack-router-at6s9t9e?file=src%2Froutes%2Fabout.tsx
Steps to Reproduce the Bug or Issue

Open stackblitz
Go to routes/about.tsx
In AboutComponent(), observe that the type of loaderData is { id: number; name: string; email: string; } instead of UserData

Expected behavior
I expected Route.useLoaderData to return an object typed with its original interface from the data loader function. Instead, it returned the object shape without the interface.
Screenshots or Videos
No response
Platform

OS: Stackblitz
Browser: Chrome

Additional context
This regression was introduced in v1.81.0. Previous versions worked correctly and returned the interface instead of the object shape.

I believe this comes from the key iteration in the Expand utility type, which iterates the keys of the loader data.
In the example provided by @go3323, it's not actually a problem, because the UserData interface is reproduced in full, and the provided example is actually fully type safe.
However, consider an example (this is only valid with non-server-side routing, of course) where a loader returns a value that has private or protected fields, which are not iterated over by key (Stackblitz):
import { createFileRoute } from '@tanstack/react-router';

class UserData {
  id: number;
  name: string;
  #email: string;

  constructor(id: number, name: string, email: string) {
    this.id = id;
    this.name = name;
    this.#email = email;
  }

  getEmail() {
    return this.#email;
  }
}

export const Route = createFileRoute('/')({
  loader: () => Promise.resolve(new UserData(1, 'user', 'user@example.com')),
  component: HomeComponent,
});

function HomeComponent() {
  const data = Route.useLoaderData();
  return <UserDataEmail data={data} />;
}

function UserDataEmail(props: { data: UserData }) {
  return props.data.getEmail();
}

In this example, you'll get a type error when using the UserDataEmail component:
Property '#email' is missing in type '{ id: number; name: string; getEmail: () => string; }' but required in type 'UserData'.

Note that as @EskiMojo14 helpfully pointed out to me on Discord, Expand is shallow, so you can currently work around this by returning the user data instance in a plain object:
export const Route = createFileRoute('/')({
  loader: () => Promise.resolve({ user: new UserData(1, 'user'<EMAIL_ADDRESS>}),
  component: HomeComponent,
});


How do I use this for Async validation?

Hi,
I've just found your tool and after spending a few minutes looking at the documentation and trying to use the package in my solution, I see that it's not working quite yet.
I have added "AutoValidation" with "All" strategy, but am not seeing the validators hit, and when I do, I'm seeing this error  The service provider has not been configured to work with FluentValidation. Making use of InjectValidator or GetServiceProvider is only supported when using the automatic MVC integration.
I thought that using this package would allow for using MustAsync on my RuleFor statements.  How do I use this package to enable using IServiceProvider in my validators?  I am using the ValidationContext.GetRequiredService method in my validators to find my services, but as you see above, this does not seem to be possible.

I have written IRuleBuilder extensions, which did accept repository classes and performed db checks in an async manner.  But the repo layer classes instantiate EFCore DbContext's and when run async this has concurrent access issues with the DbContext.  So, I thought I could use FV's ValidationContext to get a ServiceProvider and make the repo classes transient so the validation can perform multiple db queries concurrently and this would even make validation faster, but EFCore is preventing that with the concurrent operation limit.

I don't do any injects in extension methods. Normally I create something like a RemoteDataValidator class which I inject into the validators directly, methods on that class I call from either Must or MustAsync.

does your RemoteDataValidator class take constructor injection or method injection?  sounds like constructor injection might be overkill if you don't use all the repository classes.

Closing since this isn't a bug within the library.


Adds ability to specify specific relations to be included

@chamini2 as you suggested previously, this PR allows for specific relations to be included. I already ran into a case for this, hence the quick addition 👍

Hey, I don't think this is the best API to achieve this.
I was thinking maybe then to do:
relations : false // no relations, none included
relations : true | relations : { included: true } | relations : {} // all relations, all included
relations : { included: false } // all relations, none included
relations : { included: { a: true, b: false } } // relations: 'a' 'b', included: 'a'
relations : { included: ['a', 'b'] } } // relations and included: 'a' 'b'

relations : false // no relations, none included
relations : true | relations : { included: true } | relations : {} // all relations, all included
relations : { included: false } // all relations, none included
relations : ['a', 'b'] // relations and included: 'a' 'b'
relations : { 'a': true, 'b': false } // relations: 'a' 'b', included: 'a'

So, dropping entirely the fields option?
I don't know if it's the best, but it limits problems in input. With the proposed API by this PR think of this case:
relations : { fields: ['a', 'b'], included: ['a', 'c'] }

Hey. I appreciated the suggestion, but I believe the API you proposed is too complex. It just doesn't read well and ultimately seems more of a pain to implement.
However, I do agree that the case you mentioned is problematic. I think we could easily difference those arrays to make it work. Essentially, if fields exists and included is an array, we difference on those to get the fields that can actually be included.
What do you think?

relations : { included: {a: true, b: false} } // relations: 'a' 'b', included: 'a'

You still run into the original issue of not being able to specify the relations to serialize, correct?
For example, without the fields param, the above only allows you to serialize all relations and selectively include or exclude them from the payload.

For example, without the fields param, the above only allows you to serialize all relations and selectively include or exclude them from the payload.

I was thinking that the properties of that object would be the ones to add in relations and just include the true ones in the included array. But I see your point in it being complex.

However, I do agree that the case you mentioned is problematic. I think we could easily difference those arrays to make it work. Essentially, if fields exists and included is an array, we difference on those to get the fields that can actually be included.

I guess this works, I don't love it but seems easier to understand.

@chamini2 see the changes I just pushed.

I guess this works, I don't love it but seems easier to understand.

It seems like a valid solution; not sure how we'd make it much better without making the API over-complex. What don't you love about it? ❤  😄

Ultimately, the solution I provided is just eliminating the ability for a user to make an error. I believe we're going to encounter that regardless of what the API looks like.

@chamini2 just added the test from the other branch and replaced some with includes in the relationsAllowed block.

Hey @jamesdixon, I opened a PR to this branch in your repo to change a bit the checks for options passed. I figured it would be easier to change it myself.

Ok, changes are fine by me.

Thanks for your help!


Requester side lease Support

https://rsocket.io/about/Protocol#flow-control-lease
#173

closed by https://github.com/rsocket/rsocket-js/pull/173


Reduce the amount of whitespace and make it compact

The page currently has a lot of whitespace, near the usernames section. Make it bit cozy. Good first issue for hacktoberfest

Hi) https://github.com/nikhilmufc7/Hacktoberfest-PR/pull/20


Add support to remove stale locks using a maintenance loop

Add a maintenance mechanism to remove stale locks. Stale locks are detected by querying back to the original requestor for the 'golden' state of the lock (relying on the fact that the 'localhost' server will never have 'network' problems and thus always have the correct state). In case the original server cannot be reached because of a network issue, the status of the lock is unknown and resolution of the lock will try to be obtained in a next maintenance cycle.
Other improvements & additions:

uid added to (r)lock message
added node & rpcPath from originator to (r)lock message so it is known to which server to query back
added new test cases for single & multiple stale locks, and single and multiple clients with locks that crash
locks that do not include its own 'localhost' server are not treated as valid locks (released immediately)

Basic algorithm for Stale Lock detection
The algorithm relies on the fact that the 'localhost' server of the client that is trying to get the lock is always actively participating in granting the lock. This is a logical assumption since there's no 'real' network traffic for this request  and in fact this commit now guarantees this to be the case.
So we can say that the status of the lock at this server is the 'golden' status for this lock. We require that the client and server are running in the same process, ie a crash will take both down.
For each lock server a maintenance loop is added that iterates over all locks that are active and that will perform a 'check' on a lock with a certain (configurable) age (say a minute, so short lived locks are never checked).
For each lock to be checked a call is made back to the server of the originating client to query whether the lock is still active or not (based on the combination of name and the uid of the original request). Three things can happen:

the lock is still active --> not a stale lock
the lock is no longer active --> we have detected a stale lock and can remove it
the call fails (for whatever reason, can be either network failure, server down, something else, etc.): we cannot draw any conclusions so we will retry during a future maintenance loop

The following table summarizes the different situations that can occur:

Client/Server
Network
Has Lock
Remark

Running
Connected
No
Lock can be requested provided quorum is obtained

Running
Connected
Yes
Lock can be released

Crashed
Connected
No
No side effects

Crashed
Connected
Yes
Client/Server crashed while lock was active: see scenario 1

Running
Disconnected
No
Lock request will always fail due to absence of quorum

Running
Disconnected
Yes
Client/Server has lock but are unable to deliver release message to quorum: see scenario 2

Crashed
Disconnected
No
No side effects

Crashed
Disconnected
Yes
Client/Server crashed while lock was active and network is down: see scenario 3

Scenario 1: Both client and server go down while the client was holding a lock. The check call in the maintenance loop at other servers will fail as long as the client and server remain down. Once client and server are restarted, the lock is obviously lost at both the client and the server, so during a next iteration of the maintenance loop stale locks will be detected at the other servers.
Scenario 2: Client and server are still running and the client got a lock while the network was still up. Now it is disconnected from the network and it releases the lock so the unlock message is effectively only delivered at its own 'localhost' server. As long as the network remains disconnected, the call to detect stale locks in the maintenance loop at other servers will fail. Once the network becomes available again, the other servers will detect during their maintenance loops that the lock is no longer active and remove their stale locks.
Scenario 3: Client and server were running while locking a lock but then crashed and got disconnected from the network. As long as they are not restarted and the network connection is restored, the other servers will not be able to detect any stale locks. So both the client and server need to be restarted and the network connection needs to be restored in order to the stale locks to be detected.

Could you add a description of the lock maintenance algorithm in your commit log?  I have gone over the code once. I shall think over the possible scenarios and get back to you on this.

@krisis See https://github.com/minio/dsync/pull/22#issue-176751755 for a basic description of the Stale Lock detection algorithm.

@harshavardhana will do that, to include the following:

update vendored version of dsync
update lock-rpc-server to include maintenance algorithm
update namespace-lock for new sync.RWMutex compatible behaviour


How to receive and store all published messages if a client goes offline?

Hello! I am working with MQTT Broker and Client using MQTTnet library. Using the latest version. I have seen a situation where if a client goes offline after subscribing to a topic then, all the messages published on that during that time is not shown when the client reconnects. I have used the following for the client configuration:
Clean Session = false
QoS = 1 or 2 (AtMostOnce or ExactlyOnce)
According to my understanding, the server should have an internal queue where it should store the messages and when client reconnects, there should be a possibility to deliver all the messages received when the client was offline. I do understand the message retain policy. I have checked the json file being generated by the server where it received only the last message on the topic and when the retain flag is true, the Client when reconnects, only gets the single last message published on that subscribed topic.
My question is, how can I receive all the messages which was published when the client was offline. Please help me on this.
Thank You

If you are interested in the last message for every topic, just set the retain flag when publishing the message. The server will store the last retained message and send it to the client when the client (re)connects and subscribes to that topic (works with wildcards too).
If you want the full set of all messages received by server while the client was disconnected, then MQTT doesn't help. You need to provider your own logic to save the messages and "replay" them when the client reconnect. MQTTnet provides all the plumbing you need but not an out-of-the-box solutoion for this case.

MQTTnet also has such a queue but you use CleanSession=true. This will delete the session and thus the pending messages of that session.

@chkr1011
I am already using "Clean Session" as false so that, the session is saved. But, whenever my client reconnects, it doesn't get the published messages while it was offline.

Please try to set the EnablePersistentSessions property to true at the server options.

"WithPersistentSession" property had worked for my Asp.Net Core 2.0 App! Thanks a lot!

@saba-sabrin I think we just store the messages in memory, so if the broker is restarted you will still loose messages.
@chkr1011 should we extend IMqttServerStorage or provide a similar interface to store pending messages of a session?

@JanEggers Yes that is a good idea.

@JanEggers Yes, you are absolutely right. I was planning to implement my own interface to store the undelivered messages. But, if this can be a part of the library, that will be awesome! Thanks!

@JanEggers @chkr1011  Any updates (or a guide)  on saving session to storage?

This feature is still in progress. I already added some internal interfaces and objects already but the feature is not finished. The problem is not how to load the data when the service starts. It is the saving of that information. My conclusion after some tries for implementation is that this is fully up to the user to save whenever needed. So he needs to use a timer or save on every incoming or queued message or on server shutdown or whatever. I am not able to provide one interface which just needs to be implemented. I hope to release the loading part soon (in a couple of month) so that you can at least load persisted sessions.

Thank you for your reply. I think this feature should have an interface with four methods:
1.To save any message which it's delivery failed.
2.To load messages for a connected client.
3.To save messages on server shutdown by leveraging the HostedService.
4.To load messages when server starts by leveraging the HostedService.
Then it's up to the user to implement the interface and save the messages.

The thing is that this is not only covering messages. The MQTT spec says that also some more data must be stored like open QoS level 2 transactions etc. That is the problem I am trying to solve.
And you are missing some use cases. You only covering failed messages. Other people might want to save queued messages before delivering. That can be done on shutdown but that might not happen if the app is crashing.

The thing is that this is not only covering messages. The MQTT spec says that also some more data must be stored like open QoS level 2 transactions etc. That is the problem I am trying to solve.
And you are missing some use cases. You only covering failed messages. Other people might want to save queued messages before delivering. That can be done on shutdown but that might not happen if the app is crashing.

Now, Any updates (or a guide) on saving session to storage?

Any updates for this feature?
I would love to test the session persistence :)

+1

Any updates for this feature?

No new updates yet. Some more internal preparations are made but no public API.

+1


Guide/process for publishing on Ghost

Guidance for publishing and using Ghost (metadata, ..)

Get the draft reviewed

Can I work on this issue?

Sure go ahead :)


✨ [Feature] Some optimizations for goravel/gin repository

Before feedback (在反馈之前)

[X] There are no features that I want to submit in Issues (当前 Issues 中没有我将要提交的新功能)

Describe Feature (描述功能)

We can remove the gin_ prefix for all files;
Missing route/gin_group_test.go:535::TestThrottle
Missing route/gin_group_test.go:222::Any Options
Change GinRoute to Route
Need to initialize RateLimiterFacade: https://github.com/goravel/gin/blob/a5ba5540bd87de1bdbe042e2ee800eace27a7598/service_provider.go#L23C2-L23C36

Finished, the tests of Throttle middleware and CORS middleware will be moved to the http-middleware repository for testing.


runtime: openbsd/arm fails when compiled with GOARM=5

When the arm architecture is compiled with GOARM=5, the linker rewrites TLS register loads from MRC with a call to runtime.read_tls_fallback - on OpenBSD post 6.9, this fails since runtime.read_tls_fallback is still a direct system call:
https://github.com/golang/go/blob/master/src/runtime/sys_openbsd_arm.s#L90
This code path is generally never hit, since the minimum ARM CPU supported by OpenBSD is v7 and hence GOARM=7 is the default.
We should either:

Revise runtime.read_tls_fallback to use a libc-based system call.

Prevent GOARM < 7 from being used on openbsd/arm and remove the fallback code entirely.

I think we only support GOARM=5 on Linux. On other OSes we only support GOARM=6 or 7.
I think it is okay to have a check with better error message (and remove fallback code). Thanks.


About detecting many extra boxes

Hello author, thank you for your hard work!
Drawing on your ideas, I am developing my own single-stage object detection network, but there are a lot of extra boxes in the visualization results.
Since my network structure is deep, I guess it may be caused by the disappearance of the gradient or the explosion of the gradient, but why do these two situations lead to the appearance of a large number of abnormal boxes, can you give any suggestions?

In addition, I don't think this is the cause of nms. In fact, such results are already the results after nms.

How about your training loss ? @pengjizhi I think the value of your training loss may be very large.

@yqyao
Hello!
I also feel very strange about this, because in my display, the value of loss has been falling normally, so I didn't realize that this happened, and it wasn't until I tested it that I found a lot of exception boxes.

What dataset you use for training ? @pengjizhi

Have you solved this problem?I've met the same issue. The false positive rate was very high. @pengjizhi

@yin19961202
Hello, I haven't found the main cause of this problem at present, I guess it may be because the model is too complicated, and it caused gradient explosion or gradient disappearance during training.
Currently I can solve this problem by reducing the learning rate.

Hello, I found that if I increased the threshold of the positive box (for example, 0.8), the extra boxes would be removed but some correct boxes would be removed, too. I also found the training loss was very high in the end. Can you share the setting of your learning rate? Thanks
| |
尹锐红
<EMAIL_ADDRESS>|
签名由 网易邮箱大师 定制
On 12/23/2019 09:34, pengjizhi wrote:
@yin19961202
Hello, I haven't found the main cause of this problem at present, I guess it may be because the model is too complicated, and it caused gradient explosion or gradient disappearance during training.
Currently I can solve this problem by reducing the learning rate.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.


[rpc] Implemented rpc logging

This adds logging to rpc communications, by adding a wrapper around "RPCChannel". The wrapper, "RPCChannelLogging", has a "NanoRPCListener" that only listens to ongoing communication and log them in a human readable way. "NanoRPCListener" uses a "MinRPCSniffer" to decode the rpc commands. "MinRPCSniffer" is based on "MinRPCServer" and shares the same code to decode the packets, but replaces the execution and return handling with no-operation functions. The log is disabled by default for backward compatibility, and a test case ("test_rpc_simple_wlog") is added to the "test_runtime_rpc.py" with logging enabled.

This PR fixes the windows build issue with PR#10967
@areusch, @mehrdadh, @alanmacd

@mehrdadh, is there any specific Hexagon test I should run? the CI tests are passed.

@mkatanbaf Nothing on your end, I'm gonna test it locally and get back to you.

I tested hexagon_launcher and looks good.

@mkatanbaf i think this fix makes sense to me, but that we should propagate tvm_ssize_t to most of the other ssize_t mentions in the codebase. in particular, in src/support/socket.h we still have a competing definition using ssize_t = int; for Windows builds, and i think we should get rid of that in favor of this.


[TS migration] Migrate 'WorkspaceMembers' page to TypeScript

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/25201
PROPOSAL: N/A
Tests

Log into the app
Make sure you are an admin of a workspace (if not, create one and add some members)
Go to Settings -> Workspaces -> (The workspace mentioned above) -> Members
Test that screen, make sure you can invite/remove members

[x] Verify that no errors appear in the JS console

Offline tests

N/A
QA Steps

Same as Tests section above

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
android.webm

Android: mWeb Chrome
chrome.webm

iOS: Native
https://github.com/Expensify/App/assets/44364829/efa35436-983b-4fa9-8010-7ce700d887a1

iOS: mWeb Safari
https://github.com/Expensify/App/assets/44364829/91f139e2-83c7-4bb6-bfc0-91b9081889c5

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/44364829/bcff4b72-6345-4bb4-b2d6-44e947ba9f33

MacOS: Desktop
https://github.com/Expensify/App/assets/44364829/a29286bb-0e66-4807-80ce-7cf0932eef37

@VickyStash @fabioh8010 can you take another look? 🙏

FYI @JKobrynski is OOO from Feb 12th to Feb 16th.

@hoangzinh PR updated!

Can you fix the conflict please?

@tgolen done!

🚀 Deployed to production by https://github.com/puneetlath in version: 1.4.44-13 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Server Error while running cvat on local ubuntu machine for automatic annotation

docker_logs.txt
nuctlgetfunction.txt
dockerpsoutput.txt
My actions before raising this issue

[x] Read/searched the docs
[x] Searched past issues

Trying automatic annotation using CVAT.
I accessed the cvat in localhost:8080. Nuclio is running and has uploaded all models successfully. I am able to create tasks. After that once I click on automatic annotation, it shows the set of models(like Faster RCNN, Yolo etc too).
However, when I run any model it shows the error:
Error: Inference status for the task 2 is failed. requests.exceptions.HTTPError: 503 Server Error: Service Unavailable for url: http://nuclio:8070/api/function_invocations

Expected Behaviour

Ideally, it should run the model and annotate the images.
Current Behaviour
Currently it is just throwing an error, whenever I try to run the pre loaded models for automatic annotation
Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

Git hash commit (git log -1): Using latest CVAT version
Docker version docker version (e.g. Docker 17.0.05):  Docker version  19.03.12
Are you using Docker Swarm or Kubernetes? No
Operating System and version (e.g. Linux, Windows, MacOS):  Ubuntu 18.04.5 LTS
Code example or link to GitHub repo or gist to reproduce problem:
Other diagnostic information / logs:
Logs from `cvat` container

Next steps
You may join our Gitter channel for community support.

Hi closing this as, it was a proxy issue.
On the docker compose file, added an extra site to surpass proxy under the no_proxy: <IP_ADDRESS>,<your invocation url>, ${no_proxy} line.
The invocation url from nuclio dashboard has to be added to the above line, so that it surpasses the proxy of your network.

@varchanaiyer I am facing the same issue, can you please share exactly where it needs to be configured. I could not see no_proxy variable in docker compose file. I have it in docker service and ~/.docker/config.json file. But it is not taking this variable from these locations.

"internalInvocationURLs": ["<IP_ADDRESS>"] added the IP address to components/serverless/docker-compose.serverless.yml still getting the same error "503 Server Error: Service Unavailable for url: http://nuclio:8070/api/function_invocations"
docker-compose:
version: '3.3'
services:
  serverless:
    container_name: nuclio
    image: quay.io/nuclio/dashboard:1.6.8-amd64
    restart: always
    networks:
      default:
        aliases:
          - nuclio
    volumes:
      - /tmp:/tmp
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      http_proxy:
      https_proxy:
      no_proxy: <IP_ADDRESS>,<IP_ADDRESS>,<IP_ADDRESS>/24,${no_proxy}
      NUCLIO_CHECK_FUNCTION_CONTAINERS_HEALTHINESS: 'true'
      NUCLIO_DASHBOARD_DEFAULT_FUNCTION_MOUNT_MODE: 'volume'
    ports:
      - '8070:8070'
  cvat:
    environment:
      CVAT_SERVERLESS: 1
      no_proxy: kibana,logstash,nuclio,${no_proxy}
volumes:
  cvat_events:

Any suggestions?

I have a similar problem. After every server restart, I have to re-deploy the models for them to work. I think after restart the invocation URL of the function might change but in the model config it still has the old URL. After the restart, I'm can't ping the internal invocation IP that is listed under the 8070 page. When I then re-deploy the model (via command line since it doesn't work on the web page) I'm able to ping the IP and the function works properly


ARC19 needs to specify explicitly that the data pointed to by the reserve address is JSON

Several groups such as Project Raven were uploading images at the CID specified by the reserve address, I copied that pattern, since it is not stated in the specification that it needs to be any particular file type.
There are numerous places where terms like MUST and SHOULD are used, but nowhere does it say that this CID MUST point to JSON.
So since that was the intention, it needs to be stated explicitly in this format. Also should be clarified explicitly that any JSON file is valid, rather than necessarily ARC3 format (as is implied).

I originally asked about this (because I was interested in using arc-69 and arc-19 together).
The resulting discussion was that ARC-19 could deliberately not specify what the url points to to leave future flexibility and other ARCs could be created to tackle that.
cc @cusma @pbennett

Would be interesting to see where that was stated in the discussion. Patrick told me today that it was expressly intended to be used with metadata only and that not specifying that with a "MUST" was something he felt was unnecessary because it was implied by the rest of the text. Based on that claim, I made announcements on my Discord server and Twitter that I had implemented arc19 incorrectly and so had those other projects.

It feels weirdly limiting to me to assume that ARC-19 always points to “ARC-3 metadata”. They limits all kinds of potential future use cases.
sure, that was the context within which it was designed but it could be kept as a more general purpose standard that simply deals with mutable urls.
here was the original discussion by the way: https://github.com/algorandfoundation/ARCs/pull/116

He did not tell me arc3, just metadata JSON.

Ok, I understand what happened. He just didn't 100% agree with the actual spec that was finalized supposedly implemented his idea. To me it was sensible that Fabrice decided to leave it open. I understand that there is a strong desire here to avoid arc69, but practically speaking ensuring the file is only metadata should be another arc. So I was ultimately misinformed about the final arc form today and made an incorrect announcement. I still plan to build arc3 as an option and probably default for this but now I might have to also allow arc69 at the same time as a choice. I'm not looking forward to making an announcement that my announcement about being incorrect was incorrect though..maybe take a break from announcements.

Sure there’s heaps of references to arc 3 as examples but the core of the spec isn’t explicit.
Even the lead-in paragraph of motivation is like “there are cases where some type of mutability is desired for NFT metadata and/or digital media”
But sure, that doesn’t mean that clients will support that today since my assumption would be that most implementations would assume arc3.
Whenever I’ve minted ARC-19 using arc-3 metadata I’ve added the arc3 marker so a client could make the assumption.
I think it’s fair to say that there should be a separate arc dealing with specific uses of arc-19 with a metadata standard (which is hinted at in arc-19 anyway).

Side-note: if we did have an ARC-69+19 I vote it should be called ARC-88 :p

Right, it really should have something saying arc3 at then end if that's what it is.
The discussion that specifically addresses this question as to whether the reserve (CID) can point to metadata or an image and references the ambiguity in the text is clear. @pbennett if you still disagreed at that point then you needed to reply to @fabrice102 's message or say something at some point to contradict when he specifically said he was going to leave that open.
I think it would have been quite problematic for fabrice to make another decision at that point, due to the schism related to arc3/arc69. I know there are different viewpoints on this, and different practicalities depending on projects.

Someone could link to an image and have no metadata and be a compliant ARC19 asset.
If someone tacks #arc3 on the end it means it references an arc3 json spec and its spec is explicit.  ARC19 leaves the specific metadata spec up to others - as that's an entirely different can of worms (arc3 makes no mention of traits for eg - that's a different ARC)
Wanting a mutable URL link but to also have note transactions represent metadata needs to be a new ARC because nothing in ARC19, ever, says note transactions should be read - in fact it makes a point about explicitly avoiding their need - fetching all data from a single aglod call.
If you have an asset where part of its data is in note transactions and the only way to display the asset is to fetch those, it's not ARC19 - it should be a new ARC (and could even be a super simple one).  Just please make sure there's something in the asset that makes it clear.
New ARCs should just be sequential... but ARC-88 would be kind of funny. 😂

However, ARC-19 is fully compatible with ARC-69 as ARC-69 does have the asset hash optional.

That's what fabrice said before he finalized it. He's the referee of the process. Its a process and someone has this role because there are different people involved. He specifically said that it was compatible with arc69, and many projects have been using it that way. You specifically did not say that it MUST be metadata. That is the key usage of those terms in these types of documents. and it failed to be included here. @pbennett again, it was a requirement of the process to contradict him if you felt that the standard should not proceed with that interpretation.
I am planning on making arc3 the default anyway with arc19 as soon as I can get to it. Not because it actually makes more sense to me, but because I am tired of the conflict.

Hello guys, here are my 2 cents on the subject.
I don't think you implemented (ARC19 or AR69) wrong. In my opinion, the main issue is that we are using one part of the 69 (note) and one part of the 19 (mutable ipfs template).  And neither of those 2 ARCs cover the compatibility for this.
From the Motivation section of arc 19:

An asset-config transaction may include a note, but it is limited to 1KB and accessing this value requires clients to use an indexer to iterate/retrieve the values.
Using the reserve address in this way means that what an ASA 'points to' for metadata can be changed with a single asset config transaction, changing only the 32-bytes of the reserve address. The new value is accessible via even non-archival nodes with a single call to the /v2/assets/xxx REST endpoint.

So based on those 2 quotes, we can see the purpose of ARC 19.
From a technical point of view, it makes more sense to use ARC 3 + ARC 19 if you want mutability for metadata because you already force the client to fetch the URL.
When using ARC 19 + ARC 69, you must fetch IPFS content and the indexer's new note txn.
That is why it might not have been covered inside the ARC-19.
However. Even if the ARC-19 mutable ipfs template was not INTENDED to be used with ARC-69, I understand that it was maybe more convenient for some project creators to keep using ARC-69.
So I see 2 options:

We update the ARC-69, which is living, to mention the possibility of using a mutable ipfs template (ARC-19 like) @ChrisAntaki @TommyAlex79 @algokittens
We create a new ARC that says explicitly that the Url is linked to a mutable Media file and the metadata to the indexer note.

I propose updating ARC19 to remind people the #arc3 suffix is necessary for valid ARC3 URLs

Using ARC69 isn't just about convenience, it's also loads media more efficiently, so it provides a better user experience

I agree with your points @ChrisAntaki, ARC-69 also has an advantage for fetching the URL. That's why I don't want to remove this option from using the mutable IPFS content.

I would like to add to the conversation from the perspective of project creator.
The reason why I decided to use arc19/arc69 is because arc19/arc3 requires two files to be pinned to IPFS network and in my opinion this is hugely inefficient.
It already takes about 30 seconds to process one mutation and another pin would only increase that time.
Also I use Pinata as IPFS provider and I'm restricted by the amount of pins so adding another pin for each mutation would mean that I would run out of available pins twice as fast. Of course there are some services that offer unlimited pins but I cannot simply assume it will stay that way.
People don't realise that this is not much of a problem for static NFTs as in case of IPFS provider failure all they have to do is to find another provider and pin their files there. For mutable NFTs that are dynamically generated like Project R4V3N this would be a catastrophic failure with no means of recovery.
Arc69 is a sort of a fallback for me as based on the metadata I'm always in position to recover the actual image if IPFS side of things suddenly disappears and retain full mutations history.
I've said it numerous times already but as much as I like the mutability aspect of arc19 the storage requirements for larger collections are simply unrealistic.
That's why I was planning on making a formal proposal to introduce either a new arc or update arc3 specs to introduce image layers metadata @fabrice102 @pbennett.
This way instead of forcing the back-end to do the image processing and pinning the resulting file, you could simply embed metadata pointing to already pinned layer files and construct the image on the client side.
Project R4V3N website already does it this way as it's more efficient for me to have layers data stored locally and let the client do all the heavy lifting. HTML 5 canvas processing is quite fast with the current hardware so there really is no point to pin massive images to IPFS network.
In my testing, asynchronously processing 200 unique pins 500x500 in size with 10 layers each takes about 16 seconds on standard desktop PC.
I'm happy to discuss this further in a more relevant place but I just wanted to show you how difficult mutability really is in real life scenario.

Fracctal Tamers is another great example of a project that combines the best of ARC69 and ARC19 to give their collectors better UX. No blocking JSON requests necessary
Mostly Frens chose ARC3 + ARC19, and they define valid* ARC3 URLs by including the "#arc3" suffix in their template URLs
Both are valid options IMO

ARC19 needs to specify explicitly that the data pointed to by the reserve address is JSON

I disagree, please do not do that @SudoWeezy .
ARC19 is a standard to mutate the URL (by changing the CID using the reserve address).
ARC19 should be able to point to an image, or an arc3 json, or some other future arc-x json or other file format.
ARC19 is powerful and flexible and should NOT be limited to json or arc3.
The issue here is that there has been a very long debate regarding arc3 vs arc69 and this is now affecting arc19 unfortunately. Let's ignore arc69 for a second, arc19 should be able to point to any ipfs CID, image or json, etc...
The arc19 abstract summarises this perfectly:

This ARC describes a template substitution for URLs in ASAs, initially for ipfs:// scheme URLs allowing mutable CID replacement in rendered URLs.

Mutable CID replacement in rendered URLs. That's all!
Then if you are pointing to an arc3 json, simply follow the arc3 spec (except metadata hash).
I see why @pbennett wants people to use arc3 json if there is metadata, and I agree, if there is metadata that is the cleanest approach in my opinion. However, I think it's a huge mistake to limit Arc19 to arc3 json, to try and prevent arc69. If we want to prevent arc69 we should simply state arc69 is discouraged with arc19. Limiting arc19 to just arc3 json would be excessive, an over-reaction.
@robdmoore , I agree, limiting arc19 to just arc3 json would "limits all kinds of potential future use cases".

"Someone could link to an image and have no metadata and be a compliant ARC19 asset."
@pbennett , glad to see you also agree, I hope you meant it can link the image directly, and not forcibly via arc3.

@runvnc , fyi, I fully understand why your raised this issue, not that you want that change, but that you felt you did something allowed by the standard.
@SudoWeezy , I seem to be dragged-in always to discuss arc69, not exact sure why tbh, my contribution here is instead to try and avoid limiting arc19 to arc3 json, I think arc19 is a lot more beautiful and powerful than that.

@1fatalix1 the image generated on the fly from constituent layers thing is a really interesting idea. If you make an ARC for it then I will try to support it on algonfts.art, especially if you can get some marketplace to support it. Seems like something that definitely would go in it's own ARC, whether you based it off of ARC3 or whatever.
Also thanks to the people who reaffirmed that I can still read English. Yes, metadata was implied, no, it was not specified. As I said, the missing keyword "MUST" is the key failure here for the people who wanted it to mean something else. Also the fact that the question was specifically asked and answered immediately prior to being finalized and then not contradicted.
I am very very tired of this debate though. I will probably make arc3 the default option for arc19 on my site (when I have time to implement it) just to avoid this discussion further, even if it adds 1000 HTTP requests to every page load or requires me to build my own metadata Indexer. At this point it's probably worth just about anything to not have to get into this discussion again. Probably.

... just to avoid this discussion further, even if it adds 1000 HTTP requests to every page load

I feel like degrading the performance would have a higher chance of creators/collectors starting the discussion again, vs leaving it efficient like Fracctal Tamers, Raven, etc


Add sixth order spatial derivatives

This adds the sixth order derivatives code I used in arXiv:2101.11015. It has been added to all of the examples and is enabled by setting the new max_spatial_derivative_order to 6 (it is defaulted to 4 and gives an error when set to any other value). Note that in the case max_spatial_derivative_order == 6, the default value of num_ghosts is automatically changed to 4 (as one needs). The "max" is in the name as it only affects the CCZ4RHS compute class (and not e.g. the constraint compute classes, tagging criterion, etc.) but of course a user is free to use the max for all their compute classes.
The Derivatives unit test has been modified to test both 4th and 6th order derivatives.
The order of the Kreiss-Oliger dissipation is 6th order (same as 4th order derivatives). Whilst naively you might think that one should go to a higher order than the order of the ordinary spatial derivatives (cf. Alcubierre p345), actually the relevant order to compare is that of the time integration (which is of course 4th order). I did try 8th order dissipation at one point but didn't get very good results (though the evolution was stable) with the 1 or 2 values of sigma I tried so have left it in the file but commented out. Note that the sign of the whole dissipation term needs to be changed in this case.
I have also added the printing of default parameter values in the pout files so it prints out e.g.
Parameter: fill_ratio not found in parameter file. It has been set to its default value = 0.7.

instead of
Parameter: fill_ratio not found in parameter file. It has been set to its default value.

I'm not reviewing officially but this looks great :-) One question: should we alias the CCZ4RHS class templating as we do for ScalarFieldWithPotential in the ScalarFieldLevel.hpp file or do you think it is useful for it to be explicit?

I'm not reviewing officially but this looks great :-)

I think @TaigoFr will want you to check a couple of things.

One question: should we alias the CCZ4RHS class templating as we do for ScalarFieldWithPotential in the ScalarFieldLevel.hpp file or do you think it is useful for it to be explicit?

I think it's not worth it. The names would get too long! I think before I really understood templating (or C++) the ScalarFieldWithPotential alias confused me for a while (although that's probably just me).


ui.indeterminate used?

@Christof, I remember you using it, but I don't think we do anymore?
@balmas, is this the reason why you added ui-utils to bower?
If but questions are answered with yes, we can remove this dependency again :)

I added it to bower because the build task failed without it .

Hm interesting. This is something bower is really bad at - handling obsolete dependencies. This might just have been a remnant of and older bower install - we'll, I'll leave this open and investigate another time - not really important.

FWIW, the reference to ui.indeterminate remains in arethusa.core which is probably why the build failed. I'm not sure though if it needs to be there or not .. it could have been my mistake with a merge.  I see that Christof added it in this commit ee0e3be8ef75825bab7fdc7109d9e1bf19a05b26 and I don't see it removed after but it also shows as being added (back?) in my merge commit 956fc1bf49103873127b0e590e2956392160adcf

Sorry, I added and used it at some point for the token selection stuff. But in a redesign I deleted the parts where I used it. I will clean it up.


quality can't changing

540 and 1080 resolutions not seeing in quality changing section of youtube player.is there any solution

Did you find a solution ?


Support for CURLOPT_UNIX_SOCKET_PATH

Hello, I want to use CPR with my existing project, but it looks like CPR doesn't support connect to UNIX socket HTTP server for now. I used to made it work by using curl_easy_setopt with  CURLOPT_UNIX_SOCKET_PATH option.
Is it possible to add this feature to CPR? If it is, I'm happy to contribute a PR for it.
@tstack @whoshuu

Looks like a nice to have feature.
If you need it in time, it might be the best if you create a PR for it ;).
Else we are currently starting to work on the backlog of feature requests.

There already exists a PR for this:
https://github.com/whoshuu/cpr/pull/282
Related issue:
https://github.com/whoshuu/cpr/issues/279


grin-miner does not resume mining after connection to stratum server severed

I’ve got 3 miners connected to 1 stratum server. One of the miners runs locally (on the same machine as the stratum server), 2 of them run remotely (on 2 MacBook Pro’s conected over the internet). When the miners lose connection to the stratum server (either because of a flaky network connection or because the stratum server was stopped/restarted), they create a new connection successfully (with a new worker ID) but fail to resume mining.
May 07 08:22:37.000 DEBG Received response with id: 0
May 07 08:22:37.000 INFO Status for worker 0 - Height: 56723, Difficulty: 1, (1440/166/841)
May 07 08:22:38.009 DEBG Mining: Plugin 0 - Device 0 (CPU) Status: OK : Last Graph time: 3.722362434s; Graphs per second: 0.269 - Total Attempts: 109831
May 07 08:22:38.009 INFO Mining: Cuckoo30 at 0.2686465968133612 gps (graphs per second)
May 07 08:22:41.005 DEBG Mining: Plugin 0 - Device 0 (CPU) Status: OK : Last Graph time: 3.741235456s; Graphs per second: 0.267 - Total Attempts: 109832
May 07 08:22:41.005 INFO Mining: Cuckoo30 at 0.2672913832237561 gps (graphs per second)
May 07 08:22:44.006 DEBG Mining: Plugin 0 - Device 0 (CPU) Status: OK : Last Graph time: 3.657733812s; Graphs per second: 0.273 - Total Attempts: 109833
May 07 08:22:44.007 INFO Mining: Cuckoo30 at 0.27339332258659177 gps (graphs per second)
May 07 08:22:47.006 DEBG Mining: Plugin 0 - Device 0 (CPU) Status: OK : Last Graph time: 3.602388513s; Graphs per second: 0.278 - Total Attempts: 109834
May 07 08:22:47.006 INFO Mining: Cuckoo30 at 0.27759360113193876 gps (graphs per second)
May 07 08:22:49.000 ERRO Error reading message: ConnectionError("broken pipe")
May 07 08:22:49.000 WARN Connection Status: Can't establish server connection to <IP_ADDRESS>:13416. Will retry every 5 seconds
May 07 08:22:49.019 DEBG Miner recieved message: StopJob
May 07 08:22:49.255 DEBG Stopping jobs
May 07 08:22:55.000 WARN Connection Status: Connected to Grin server at <IP_ADDRESS>:13416.
May 07 08:22:55.000 DEBG sending request: {"id":"0","jsonrpc":"2.0","method":"getjobtemplate","params":null}
May 07 08:23:06.000 DEBG sending request: {"id":"0","jsonrpc":"2.0","method":"status","params":null}
May 07 08:23:15.000 DEBG Received message: {"id":"Stratum","jsonrpc":"2.0","method":"job","params":"{\"height\":56723,\"difficulty\":1,\"pre_pow\":\"0001000000000000dd938c746ec80d0dad8db5d27367453d8327fb302767987e649f208f918030641690000000005aeffece00000000000135eaaa4a7ec93c5cd92b4aa0f13c4e1adb44dabfee59bfbacef817ec1f1700a9e26038d55efa9b1d5d0667aff833126b67ddaa3ebf49405b8692075012447813916a650209f1a804b4d38f9dbb4be65aa2c78ef829a34eb64ba881db427b05d99e361f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d\"}"}

May 07 08:23:15.000 DEBG Received request type: job
May 07 08:23:15.000 INFO Got a new job: JobTemplate { height: 56723, difficulty: 1, pre_pow: "0001000000000000dd938c746ec80d0dad8db5d27367453d8327fb302767987e649f208f918030641690000000005aeffece00000000000135eaaa4a7ec93c5cd92b4aa0f13c4e1adb44dabfee59bfbacef817ec1f1700a9e26038d55efa9b1d5d0667aff833126b67ddaa3ebf49405b8692075012447813916a650209f1a804b4d38f9dbb4be65aa2c78ef829a34eb64ba881db427b05d99e361f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d" }
May 07 08:23:15.000 DEBG Received message: {"id":"0","jsonrpc":"2.0","method":"getjobtemplate","result":null,"error":{"code":-32701,"message":"Node is syncing - Please wait"}}

May 07 08:23:15.000 DEBG Received response with id: 0
May 07 08:23:15.000 ERRO Failed to get a job template: RpcError { code: -32701, message: "Node is syncing - Please wait" }
May 07 08:23:35.000 DEBG Received message: {"id":"Stratum","jsonrpc":"2.0","method":"job","params":"{\"height\":56724,\"difficulty\":1,\"pre_pow\":\"0001000000000000dd94013b26c698d2969f012338dacc66c91422a605d992a6ffe37bcf5d98d5e8c9c9000000005aeffee200000000000135ebef5725ff15e9a4e1f4e44c1aae9f72ef16a76a4ab252da5f218eeeac87caaa72d72478ac9fa61d243e0b0afe8ab72a32743e87463f186fb5ba78815898e05496f62972149dee78f78e134eb1f48ac7dd2459c54922af3b8658a3dd644bdc56ab1f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d\"}"}

May 07 08:23:35.000 DEBG Received request type: job
May 07 08:23:35.000 INFO Got a new job: JobTemplate { height: 56724, difficulty: 1, pre_pow: "0001000000000000dd94013b26c698d2969f012338dacc66c91422a605d992a6ffe37bcf5d98d5e8c9c9000000005aeffee200000000000135ebef5725ff15e9a4e1f4e44c1aae9f72ef16a76a4ab252da5f218eeeac87caaa72d72478ac9fa61d243e0b0afe8ab72a32743e87463f186fb5ba78815898e05496f62972149dee78f78e134eb1f48ac7dd2459c54922af3b8658a3dd644bdc56ab1f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d" }
May 07 08:23:35.000 DEBG Received message: {"id":"0","jsonrpc":"2.0","method":"status","result":"{\"id\":\"0\",\"height\":56724,\"difficulty\":1,\"accepted\":0,\"rejected\":0,\"stale\":0}","error":null}

May 07 08:23:35.000 DEBG Received response with id: 0
May 07 08:23:35.000 INFO Status for worker 0 - Height: 56724, Difficulty: 1, (0/0/0)
May 07 08:23:37.000 DEBG sending request: {"id":"0","jsonrpc":"2.0","method":"status","params":null}
May 07 08:23:53.000 DEBG Received message: {"id":"Stratum","jsonrpc":"2.0","method":"job","params":"{\"height\":56726,\"difficulty\":1,\"pre_pow\":\"0001000000000000dd9623fe44663ee00a7051902935f13da41f3c8c16b423bd36263205627d2059cd57000000005aeffef500000000000135eddbdcbe83024770107f779977695e48a2ddc6173bd5ffb2572e601cf0057eb82fa093fb84983d0ef08c08eb23a14695f8310ec85022cf71401fd86b0625e5dbd71a6bb7351af6ebf28dceae82327ac444dbb5401cca824acf72c535644e1cae5a1f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d\"}"}

May 07 08:23:53.000 DEBG Received request type: job
May 07 08:23:53.000 INFO Got a new job: JobTemplate { height: 56726, difficulty: 1, pre_pow: "0001000000000000dd9623fe44663ee00a7051902935f13da41f3c8c16b423bd36263205627d2059cd57000000005aeffef500000000000135eddbdcbe83024770107f779977695e48a2ddc6173bd5ffb2572e601cf0057eb82fa093fb84983d0ef08c08eb23a14695f8310ec85022cf71401fd86b0625e5dbd71a6bb7351af6ebf28dceae82327ac444dbb5401cca824acf72c535644e1cae5a1f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d" }
May 07 08:23:53.000 DEBG Received message: {"id":"0","jsonrpc":"2.0","method":"status","result":"{\"id\":\"0\",\"height\":56726,\"difficulty\":1,\"accepted\":0,\"rejected\":0,\"stale\":0}","error":null}

May 07 08:23:53.000 DEBG Received response with id: 0
May 07 08:23:53.000 INFO Status for worker 0 - Height: 56726, Difficulty: 1, (0/0/0)
May 07 08:24:08.000 DEBG sending request: {"id":"0","jsonrpc":"2.0","method":"status","params":null}
May 07 08:24:13.000 DEBG Received message: {"id":"Stratum","jsonrpc":"2.0","method":"job","params":"{\"height\":56727,\"difficulty\":1,\"pre_pow\":\"0001000000000000dd97c725f4a63f20273d669a852f33570ab890d30ae7b77d6b7d437bc8132174a207000000005aefff0800000000000135ee5039422e68a14ba30fb598f86237a54efc3336fde346c1090eabc3d9499d6aae62332147fd6d737de255e6e7e4af6318530cd45fd4d91a9948ec6c09ac6bda4f1661c3ef2e98bfed3aa58bb1627b88307a4b5b4a1ee9015ddedc246827e2a8481f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d\"}"}

May 07 08:24:13.000 DEBG Received request type: job
May 07 08:24:13.000 INFO Got a new job: JobTemplate { height: 56727, difficulty: 1, pre_pow: "0001000000000000dd97c725f4a63f20273d669a852f33570ab890d30ae7b77d6b7d437bc8132174a207000000005aefff0800000000000135ee5039422e68a14ba30fb598f86237a54efc3336fde346c1090eabc3d9499d6aae62332147fd6d737de255e6e7e4af6318530cd45fd4d91a9948ec6c09ac6bda4f1661c3ef2e98bfed3aa58bb1627b88307a4b5b4a1ee9015ddedc246827e2a8481f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d" }
May 07 08:24:13.000 DEBG Received message: {"id":"0","jsonrpc":"2.0","method":"status","result":"{\"id\":\"0\",\"height\":56727,\"difficulty\":1,\"accepted\":0,\"rejected\":0,\"stale\":0}","error":null}

May 07 08:24:13.000 DEBG Received response with id: 0
May 07 08:24:13.000 INFO Status for worker 0 - Height: 56727, Difficulty: 1, (0/0/0)
May 07 08:24:31.000 DEBG Received message: {"id":"Stratum","jsonrpc":"2.0","method":"job","params":"{\"height\":56728,\"difficulty\":1,\"pre_pow\":\"0001000000000000dd98d9a1b6faa8bbc4165df4f8b9f8d9746c0b55dfaa75e242d5f7c5df90cc64376a000000005aefff1b00000000000135efd84df979025358be033774ad47ee40d878d4bd3ed5072f3e6908070b51fedec701f3cfafd78d7bc9932dd96ef74d4135145acc729e786a98b45addc209067b2f287bd49f2bb2983ad6a801a1c78abaed0d47d27d67e8e7bacdb0a65f6736a2911f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d\"}"}

May 07 08:24:31.000 DEBG Received request type: job
May 07 08:24:31.000 INFO Got a new job: JobTemplate { height: 56728, difficulty: 1, pre_pow: "0001000000000000dd98d9a1b6faa8bbc4165df4f8b9f8d9746c0b55dfaa75e242d5f7c5df90cc64376a000000005aefff1b00000000000135efd84df979025358be033774ad47ee40d878d4bd3ed5072f3e6908070b51fedec701f3cfafd78d7bc9932dd96ef74d4135145acc729e786a98b45addc209067b2f287bd49f2bb2983ad6a801a1c78abaed0d47d27d67e8e7bacdb0a65f6736a2911f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d" }
May 07 08:24:39.000 DEBG sending request: {"id":"0","jsonrpc":"2.0","method":"status","params":null}
May 07 08:24:51.000 DEBG Received message: {"id":"Stratum","jsonrpc":"2.0","method":"job","params":"{\"height\":56729,\"difficulty\":1,\"pre_pow\":\"0001000000000000dd99f794a71ffdaab682c1b928fe5183cdedf6c537a6562f89eb23e01384b34758e3000000005aefff2e00000000000135f092b357b92439d1a1fb6b32b79482d634d0d01e08e6c89e93d727633312904cdd9bffbbe2bb8b1dcdbe4a603bbe9163f63d0a848fa69ddde28f779032657f5eae7a4f37d0b4f28243fff10bf96a8dd9106b2d167a72108984807abc0adbc2e5411f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d\"}"}

May 07 08:24:51.000 DEBG Received request type: job
May 07 08:24:51.000 INFO Got a new job: JobTemplate { height: 56729, difficulty: 1, pre_pow: "0001000000000000dd99f794a71ffdaab682c1b928fe5183cdedf6c537a6562f89eb23e01384b34758e3000000005aefff2e00000000000135f092b357b92439d1a1fb6b32b79482d634d0d01e08e6c89e93d727633312904cdd9bffbbe2bb8b1dcdbe4a603bbe9163f63d0a848fa69ddde28f779032657f5eae7a4f37d0b4f28243fff10bf96a8dd9106b2d167a72108984807abc0adbc2e5411f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d" }
May 07 08:24:51.000 DEBG Received message: {"id":"0","jsonrpc":"2.0","method":"status","result":"{\"id\":\"0\",\"height\":56729,\"difficulty\":1,\"accepted\":0,\"rejected\":0,\"stale\":0}","error":null}

May 07 08:24:51.000 DEBG Received response with id: 0
May 07 08:24:51.000 INFO Status for worker 0 - Height: 56729, Difficulty: 1, (0/0/0)
May 07 08:25:10.000 DEBG sending request: {"id":"0","jsonrpc":"2.0","method":"status","params":null}
May 07 08:25:15.000 DEBG Received message: {"id":"Stratum","jsonrpc":"2.0","method":"job","params":"{\"height\":56730,\"difficulty\":1,\"pre_pow\":\"0001000000000000dd9ad377d42b43abe92e8ff66bf4d393a5e6f1972caa90ee0a5b44bc6057bbd1397d000000005aefff4600000000000135f164776439dc7b8edfb0290a601f1825cb187a48305829ec441103cdb135fe0b3ffea096166fa92df0775baa327774c32c73e2724462befe67de290beb6353bf7fe90b8763d3cd3c0c2fca33ebc6eda070843b39406a067f93cebb535d3cdb1d7c1f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d\"}"}

Confirmed. Stopped 'grin server' and started after a few seconds new. On both miners:
May 07 11:01:59.000 ERRO Communication error with stratum server: Connection reset by peer (os error 104)
May 07 11:01:59.000 ERRO Error reading message: ConnectionError("broken pipe")
May 07 11:01:59.023 WARN Connection Status: Can't establish server connection to <IP_ADDRESS>:13416. Will retry every 5 seconds
May 07 11:02:05.022 WARN Connection Status: Can't establish server connection to <IP_ADDRESS>:13416. Will retry every 5 seconds
May 07 11:02:11.022 WARN Connection Status: Can't establish server connection to <IP_ADDRESS>:13416. Will retry every 5 seconds
May 07 11:02:17.022 WARN Connection Status: Can't establish server connection to <IP_ADDRESS>:13416. Will retry every 5 seconds
May 07 11:02:23.022 WARN Connection Status: Can't establish server connection to <IP_ADDRESS>:13416. Will retry every 5 seconds
May 07 11:02:29.023 WARN Connection Status: Connected to Grin server at <IP_ADDRESS>:13416.
May 07 11:02:29.023 DEBG sending request: {"id":"0","jsonrpc":"2.0","method":"getjobtemplate","params":null}
May 07 11:02:29.023 DEBG sending request: {"id":"0","jsonrpc":"2.0","method":"status","params":null}
May 07 11:03:00.000 DEBG sending request: {"id":"0","jsonrpc":"2.0","method":"status","params":null}
May 07 11:03:31.000 DEBG sending request: {"id":"0","jsonrpc":"2.0","method":"status","params":null}
May 07 11:03:45.000 DEBG Received message: {"id":"Stratum","jsonrpc":"2.0","method":"job","params":"{\"height\":56879,\"difficulty\":1,\"pre_pow\":\"0001000000000000de2f78f9a023eb167d3a9cd09ebe38f479d81047ab6bef2da400d5559758a6f6c8e1000000005af016220000000000013693437f12ef638824bbb8dff9551a6e61f8bdc03bde6d0a93736fcfdc215d0544525eca16102b2ea0f83573a8121be25f26fa35e4e9f8ead9934ffcc96067316fecf34b20fc5f5235d2c810b89f34c99e03a3a0c39e7a31458369d6b72b90f306c41f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d\"}"}
May 07 11:03:45.000 DEBG Received request type: job
May 07 11:03:45.000 INFO Got a new job: JobTemplate { height: 56879, difficulty: 1, pre_pow: "0001000000000000de2f78f9a023eb167d3a9cd09ebe38f479d81047ab6bef2da400d5559758a6f6c8e1000000005af016220000000000013693437f12ef638824bbb8dff9551a6e61f8bdc03bde6d0a93736fcfdc215d0544525eca16102b2ea0f83573a8121be25f26fa35e4e9f8ead9934ffcc96067316fecf34b20fc5f5235d2c810b89f34c99e03a3a0c39e7a31458369d6b72b90f306c41f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d" }
May 07 11:03:45.000 DEBG Received message: {"id":"1","jsonrpc":"2.0","method":"getjobtemplate","result":"{\"height\":56879,\"difficulty\":1,\"pre_pow\":\"0001000000000000de2f78f9a023eb167d3a9cd09ebe38f479d81047ab6bef2da400d5559758a6f6c8e1000000005af016220000000000013693437f12ef638824bbb8dff9551a6e61f8bdc03bde6d0a93736fcfdc215d0544525eca16102b2ea0f83573a8121be25f26fa35e4e9f8ead9934ffcc96067316fecf34b20fc5f5235d2c810b89f34c99e03a3a0c39e7a31458369d6b72b90f306c41f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d\"}","error":null}
May 07 11:03:45.000 DEBG Received response with id: 1
May 07 11:03:45.001 INFO Got a job at height 56879 and difficulty 1
May 07 11:04:02.000 DEBG sending request: {"id":"0","jsonrpc":"2.0","method":"status","params":null}
May 07 11:04:33.000 DEBG sending request: {"id":"0","jsonrpc":"2.0","method":"status","params":null}
May 07 11:04:39.000 DEBG Received message: {"id":"Stratum","jsonrpc":"2.0","method":"job","params":"{\"height\":56881,\"difficulty\":1,\"pre_pow\":\"0001000000000000de316820fdfc32a8d0b3bb4b1c3c5708fc69520efcdcc6a72583924657cea6179973000000005af0166e00000000000136953c3726b8b47b99a8c6a2452efb02f5bb8c324298d81db11b1449fd5f95cc5ae81e3699b4614431ed3d1452ab5853e03bd3aa2463e212d0821822f0162811a9587a33499ee48fdc99ec5e802ee8e6535a0c3c957ac166826e792f3f100d6c5fb61f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d\"}"}
May 07 11:04:39.000 DEBG Received request type: job
May 07 11:04:39.000 INFO Got a new job: JobTemplate { height: 56881, difficulty: 1, pre_pow: "0001000000000000de316820fdfc32a8d0b3bb4b1c3c5708fc69520efcdcc6a72583924657cea6179973000000005af0166e00000000000136953c3726b8b47b99a8c6a2452efb02f5bb8c324298d81db11b1449fd5f95cc5ae81e3699b4614431ed3d1452ab5853e03bd3aa2463e212d0821822f0162811a9587a33499ee48fdc99ec5e802ee8e6535a0c3c957ac166826e792f3f100d6c5fb61f9c6284dfee7be0fff46f5e3b53d05161464b4be24a8b8774c1e25f60417e1d" }
May 07 11:04:39.000 DEBG Received message: {"id":"1","jsonrpc":"2.0","method":"status","result":"{\"id\":\"1\",\"height\":56881,\"difficulty\":1,\"accepted\":0,\"rejected\":0,\"stale\":0}","error":null}

Both miners (one arm64 with 6 cores, the other arm64 with 4 cores) use two of the available cores for 'whatever':
[grin@rock64 miner]$ top -b -1 -n1 | head -n20
top - 11:21:22 up 9 days, 19:02,  1 user,  load average: 2.18, 2.12, 2.10
Tasks: 102 total,   2 running, 100 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.0 us, 11.8 sy,  0.0 ni, 88.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 23.5 us,  0.0 sy,  0.0 ni, 76.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   3986.2 total,   3278.0 free,     66.9 used,    641.3 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   3880.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
11690 grin      20   0  645428   5940   4656 R 218.8   0.1   1767:41 grin-miner
12007 grin      20   0    9444   3312   2788 R   6.2   0.1   0:00.02 top
    1 root      20   0  162072   8236   6260 S   0.0   0.2   0:11.52 systemd

top - 09:26:26 up 2 days, 10:57,  1 user,  load average: 2.27, 2.18, 2.17
Tasks: 102 total,   2 running, 100 sleeping,   0 stopped,   0 zombie
%Cpu0  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 16.3 us,  0.3 sy,  0.0 ni, 83.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu4  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu5  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  4035764 total,  3465248 free,    49200 used,   521316 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  3703436 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 2260 grin      20   0  642648   9484   3104 R 215.9  0.2  17316:09 grin-miner
    1 root      20   0    6836   4432   2744 S   0.0  0.1   0:09.16 systemd
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.02 kthreadd

I see the issue here.  Resolved with:  https://github.com/mimblewimble/grin-miner/pull/7

@photis Please verify the fix and close this issue if you find it resolved.


[armature][neutralConfiguration] start loading srdf files when loading robots - [closed]

In GitLab by @proyan on Jan 24, 2019, 10:24
Merges armature -> topic/refact
Deals with #53
This PR loads the neutralConfiguration (q0) and armature from the srdf.

In GitLab by @proyan on Jan 24, 2019, 10:43
added 1 commit
ace62c36 - [armature][neutralConfiguration] start loading srdf files when loading robots....
Compare with previous version

In GitLab by @proyan on Jan 24, 2019, 12:25
I created an equivalent PR in talos_data. I'll wait for that to be merged.
https://gepgitlab.laas.fr/pyrene-dev/talos_data/merge_requests/5

In GitLab by @proyan on Jan 24, 2019, 12:52
added 1 commit
d51acdb9 - [armature][neutralConfiguration] load srdf files when loading robots. Load...
Compare with previous version

In GitLab by @proyan on Jan 24, 2019, 12:54
added 1 commit
6d7ab492 - [armature] use values from srdf in unittests
Compare with previous version

In GitLab by @proyan on Jan 24, 2019, 12:58
added 1 commit
cec5f23e - [armature][verbosity] remove verbosity for srdf load
Compare with previous version

In GitLab by @proyan on Jan 24, 2019, 12:59
@nmansard
This should be ok to be merged.
In case you wish to run it, you would need to wait for the https://gepgitlab.laas.fr/pyrene-dev/talos_data/merge_requests/5.
Closes #53

In GitLab by @proyan on Jan 24, 2019, 13:00
assigned to @nmansard

In GitLab by @proyan on Jan 24, 2019, 13:00
unmarked as a Work In Progress

In GitLab by @cmastalli on Jan 24, 2019, 14:08
marked as a Work In Progress

In GitLab by @cmastalli on Jan 24, 2019, 14:10
@rbudhira -- enable WIP pull-request for these cases; this would prevent undesired merge.
This time I enabled for you :)
Note that you can't merge before "Resolve WIP Status"

In GitLab by @proyan on Jan 24, 2019, 14:11
unmarked as a Work In Progress

In GitLab by @proyan on Jan 24, 2019, 14:12
I had already removed it when it became ready to merge.

In GitLab by @proyan on Jan 24, 2019, 14:12
changed the description

In GitLab by @cmastalli on Jan 24, 2019, 14:19
If you're using these changes in any unit-test, I'd suggest:

to wait for talos-data binaries, or
to do not use in common unit-test.

In GitLab by @proyan on Jan 24, 2019, 14:59
added 1 commit
ee139c17 - [armature] fix size of robot.q0
Compare with previous version

In GitLab by @proyan on Jan 24, 2019, 15:00
added 1 commit
073a3513 - [armature] fix size of robot.q0
Compare with previous version

In GitLab by @proyan on Jan 24, 2019, 15:01
Should I also check that the armature is positive on other joints?

In GitLab by @proyan on Jan 24, 2019, 15:08
added 1 commit
0d9cc958 - [armature] assert that ff armature is zero
Compare with previous version

In GitLab by @proyan on Jan 24, 2019, 15:08
Done with the last commit

In GitLab by @proyan on Jan 24, 2019, 15:09
added 1 commit
f38ec226 - [armature] assert that ff armature is zero
Compare with previous version

In GitLab by @proyan on Jan 24, 2019, 15:13
added 3 commits
ed742d90 - [armature] save neutralconfiguration to robot.q0e95b87c0 - [armature] fix size of robot.q094c8404e - [armature] assert that ff armature is zero
Compare with previous version

In GitLab by @proyan on Jan 24, 2019, 18:32
@nmansard This is ok to merge. Please go ahead.

In GitLab by @proyan on Jan 24, 2019, 20:56
This was merged with !62

In GitLab by @proyan on Jan 24, 2019, 20:56
closed


Modify the type of archive depending on release version

All versions before and including v1.0.0 are packaged in 'gz' archives, however, versions coming afterwards, such as v1.1.0 and further are packages in 'zip'.

@genebean , I messed up the PR from the last fork, so I've recreated it in order to keep it clean.

No problem, thanks for the patch!


How to display statistics on other sites!?

⚠ Please verify that this bug has NOT been raised before.

[X] I checked and didn't find similar issue

🛡 Security Policy

[X] I agree to have read this project Security Policy

📝 Describe your problem
Hello I have entered many domains, how can I display them in one tab on a WordPress site?
📝 Error Message(s) or Log
No response
🐻 Uptime-Kuma Version
1
💻 Operating System and Arch
Ubuntu
🌐 Browser
Chrome
🐋 Docker Version
No response
🟩 NodeJS Version
14

displaying custom statistics is possible via the prometheus integration.
You can also embed a uptime-kuma dashboard into your site via an iframe, but likely this is either not going to look as nice or require some css modificaiton.
Sidenote: Please update your Node.js version v14 was releases quite a while ago. Security Support for this platform has ended on 30 Apr 2023 as by https://endoflife.date/nodejs


Quote $PATH in Makefile to avoid word splitting

If the $PATH contains a path with a space, make can fail due to the $PATH being split into multiple words.
Thank you for contributing to the CF CLI! Please read the following:

Please make sure you have implemented changes in line with the contributing guidelines
We're not allowed to accept any PRs without a signed CLA, no matter how small.
If your contribution falls under a company CLA but your membership is not public, expect delays while we confirm.
All new code requires tests to protect against regressions.
Contributions must be made against the appropriate branch. See the contributing guidelines
Contributions must conform to our style guide. Please reach out to us if you have questions.

Does this PR modify CLI v6 or v7?
Does not modify the Golang source code.
Description of the Change
Fixes a small quoting bug in the Makefile
Why Is This PR Valuable?
Users affected by this bug can't run any make targets locally.
Why Should This Be In Core?
N/A
Applicable Issues
N/A
How Urgent Is The Change?
Not urgent, but also very simple.
Other Relevant Parties
None.

Hey @tjvman, can you please fix EasyCLA ?


Something wrong with Bing translate

Thanks for this great app!
There is something wrong with Bing translator
[jerry@VM_0_5_centos ~]$ trans -debug -e bing -brief -s en -t zh-CHT -brief "Profile"
16 bytes > HTTP/1.1 200 OK
23 bytes > Cache-Control: private
19 bytes > Content-Length: 18
46 bytes > Content-Type: application/json; charset=utf-8
62 bytes > P3P: CP="NON UNI COM NAV STA LOC CURa DEVa PSAa PSDa OUR IND"
93 bytes > Set-Cookie: SRCHD=AF=NOFORM; domain=.bing.com; expires=Thu, 17-Mar-2022 02:46:47 GMT; path=/
136 bytes > Set-Cookie: SRCHUID=V=2&GUID=21D2E16534BD447496CEB0A0990C0971&dmnchg=1; domain=.bing.com; expires=Thu, 17-Mar-2022 02:46:47 GMT; path=/
98 bytes > Set-Cookie: SRCHUSR=DOB=20200317; domain=.bing.com; expires=Thu, 17-Mar-2022 02:46:47 GMT; path=/
79 bytes > Set-Cookie: _SS=SID=04346362BE8F6E1B1C2B6DF2BFF06F32; domain=.bing.com; path=/
101 bytes > X-MSEdge-Ref: Ref A: F279ACBA1FEC4714909C8AF9DF97BCF8 Ref B: HKGEDGE0506 Ref C: 2020-03-17T02:46:47Z
96 bytes > Set-Cookie: _EDGE_S=F=1&SID=04346362BE8F6E1B1C2B6DF2BFF06F32; path=/; httponly; domain=bing.com
96 bytes > Set-Cookie: _EDGE_V=1; path=/; httponly; expires=Sun, 11-Apr-2021 02:46:47 GMT; domain=bing.com
137 bytes > Set-Cookie: MUID=04925455F59267A424A55AC5F4ED66E3; samesite=none; path=/; secure; expires=Sun, 11-Apr-2021 02:46:47 GMT; domain=bing.com
108 bytes > Set-Cookie: MUIDB=04925455F59267A424A55AC5F4ED66E3; path=/; httponly; expires=Sun, 11-Apr-2021 02:46:47 GMT
36 bytes > Date: Tue, 17 Mar 2020 02:46:46 GMT
18 bytes > Connection: close
1 bytes >
18 bytes > {"statusCode":400}
content = '''
{"statusCode":400}
'''
tokens = ["{", ""statusCode"", ":", "400", "}"]
ast = {
"0,statusCode"	"400"
}
[jerry@VM_0_5_centos ~]$ trans -V
Translate Shell       <IP_ADDRESS>-git:b0564ad
platform              Linux
terminal type         xterm-256color
bi-di emulator        [N/A]
gawk (GNU Awk)        4.0.2
fribidi (GNU FriBidi) 1.0.2
audio player          [NOT INSTALLED]
terminal pager        less
web browser           xdg-open
user locale           zh_CN.UTF-8 (Chinese Simplified)
home language         zh-CN
source language       auto
target language       zh-CN
translation engine    google
proxy                 [NONE]
user-agent            Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/602.1 (KHTML, like Gecko) Version/8.0 Safari/602.1 Epiphany/3.18.2
ip version            [DEFAULT]
theme                 default
init file             [NONE]
Report bugs to:       https://github.com/soimort/translate-shell/issues

Have the same issue. The problem is in language detection.

I fixed the issue by specifying User Agent in my library.

Have the same issue. The problem is in language detection.

Thanks, I added the source language and it worked.
However, then I find that if I add the -b option, it returns a blank result. If I use the -i option, it returns the result in English without translating. These all work well if I use the default engine google. The bing implementation is still broken in some way.


Simple README instructions

Hey, it was easy enough to figure out from the code the following:
Install:

bower install --save signalwerk/colorLab
include colorLab.js in your template

DeltaE of two colors:

var color1 = new colorLab('CIELAB', [red, green, blue])
var color2 = new colorLab('CIELAB', [red, green, blue])
color1.CIEDE2000(color2); // this tells you the DeltaE, or perceptible color difference, between color1 and color2

@shadesoflight Thanks a lot for your example. The lib was built a bit in a hurry. Therefor it's also lacking of some nice examples ._. But thanks to you we have now something in the readme ^.^
II added your instructions to the readme (11b051656f52c5fd9fe0ac84657766fb3991c843) and gave you also credits (3c176e0104650250e7401d95c5cdd0f19564bb5d). Thanks a lot and if you do something cool with it or have a pull request; just let me know.


Custom errors should not introduce useless at line 0 column 0 into fmt::Display output

The serde::ser::Error trait's custom methods is meant to be used by serializers in case they encounter an unforeseen error during serialization. serde_json currently implements this like this:
impl ser::Error for Error {
    /// Raised when there is general error when deserializing a type.
    fn custom<T: Into<String>>(msg: T) -> Error {
        Error::Syntax(ErrorCode::Custom(msg.into()), 0, 0)
    }
}

Note that line and column are always 0 here. serde_json::Error then has the following fmt::Display implementation:
impl fmt::Display for Error {
    fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result {
        match *self {
            Error::Syntax(ref code, line, col) => {
                write!(fmt, "{} at line {} column {}", code, line, col)
            }
            Error::Io(ref error) => fmt::Display::fmt(error, fmt),
        }
    }
}

This results in an error message like this:

MissingType: missing type NoSuchFields at line 0 column 0

Not only is the at line 0 column 0 part useless, it is also plain wrong, since the error did not in fact occur at that line and column.
IMO it would make sense to move Custom out of ErrorCode and make it a variant of Error instead, without any line and column information at all.

I removed "at line 0 column 0" in #206.


uprobes do not respect mount namespaces (0.9.2)

Using bpftrace included with ubuntu eoan (0.9.2), there are several issues with uprobes not respecting mount namespaces:
listing probes, I would expect that if I do:
bpftrace -l 'uprobe:*' -p MY_PID

That this should be taken relative to the path of the command within the mount namespace of the pid. However, this fails, as bpftrace checks that the path against the mount namespace which bpftrace itself is running in. I believe this can be rather easily fixed for uprobes, by preppending /proc/MY_PID/root to the namespace, or perhaps there is a helper in bcc that can be used.
Likewise, I would expect that if the mount namespace of the process I am trying to probe is not equal to the mount namespace that bpftrace is running from, that it should determine this and probe the correct mount namespace. For instance, when I try to run:
bpftrace -e 'uprobe:/usr/local/bin/memcached:process_command { printf("arg1: %s\n", arg1)}' -p MY_PID

I receive the following error:
failed to stat uprobe target file /usr/local/bin/memcached: No such file or directory

However, I can force it to work by hacking in the path accordingly:
bpftrace -e 'uprobe:/proc/MY_PID/root/usr/local/bin/memcached:process_command { printf("arg1: %s\n", str(arg1))}'

I would expect that if a PID is specified, that this should not be necessary, as it should be able to infer the correct path from this. I would also expect that, as with USDT probes, the path can be omitted entirely if the PID is specified, as it can be inferred from the pid's own executable path.
I would be more than happy to submit these changes and associated tests, perhaps I'm missing the boat for the 0.9.3 release?
Also, I beg your pardon in case any of this has been fixed between 0.9.2 and the 0.9.3 release.

I would be more than happy to submit these changes and associated tests,

+1, bpftrace + namespaces still needs a bit (lots?) of love.

perhaps I'm missing the boat for the 0.9.3 release?

It won't make 0.9.3, but if you have the time to work on this I'll happily tag it for 0.9.4.

It won't make 0.9.3, but if you have the time to work on this I'll happily tag it for 0.9.4.

Yeah i figured it was too late to board that train. I'll happily have this done before 0.9.4 release.

It looks like listing USDT probes is also broken, I'll take a look at that while i'm working on this.

Sorry for the long delay here, I've got a failing regression test for this now, so i'll go ahead and make it passe

Ok, i've got #1021 up which includes regression tests and appears to fix the issue


Remove unnecessary use of unsafe

Replace use of unsafe with same functionality without unsafe (reflection)
Do not enable terminal size syscall (which uses unsafe) on appengine (build constraint)

Issue #218.

Coverage decreased (-0.3%) to 87.38% when pulling 949da127345631ebd2e068ee829bf0623a9eb698 on #218/no-unsafe into be4b90d564eb751c4ee1f658da5aa20a63aa1684 on master.

Coverage decreased (-0.3%) to 87.38% when pulling 949da127345631ebd2e068ee829bf0623a9eb698 on #218/no-unsafe into be4b90d564eb751c4ee1f658da5aa20a63aa1684 on master.


C++ build documentation and examples lacking

I've been attempting to build grpc with the opencensus support via grpcpp/opencensus.h and have been running into issues. I'm trying to use cmake and make (preferably cmake) and there's no documentation on building grpc with any extension support or general guidance on the web.
So I'd appreciate some help, but also I feel the build documentation could do with a lot of improvements

I'll leave the issue open for tracking the documents enhancement. But if you still have any question, please move the discussion to gRPC mailing list.

Unfortunately, opencensus does not support building with cmake, only with bazel.  So the only way we can build gRPC with opencensus support is to build gRPC with bazel.


Support plain java

PR for issue #173
NB I didn't add EBLog support into any of the ErrorDialog classes because ErrorDialogManager allows arbitrary log TAG and those classes don't naturally seem to fit into the EventBus library.

NB one difference between Sun's implementation of Java security and Android's looks like it has cropped up.
In Android I have been using the pattern:
class someClass {
    private final Object eventListener = new Object() {
        public void onEvent(SomeEvent e) {
            // react to event
        }
    };

    public void onCreate() {
        EventBus.getDefault().register(eventListener);
    }

    public void onDestroy() {
        EventBus.getDefault().unregister(eventListener);
    }
}

And this has worked really well.
But the same pattern using Sun's JVM will result in an IllegalAccessException unless I make the eventListener attribute public.

Scrap that comment about the difference in security.
Looks like I had some stale classes in my test environment.

Revisiting this again.
Definitely the case that the Oracle JVM won't allow access to a private eventListener attribute..
Not a big deal, just something to note.
Any chance of integrating this PR soon?

:+1: the only show stopper for me is the need for android. I want to use the event bus in libgdx and plain java version would be awesome.

Fine by me. I'll run off a branch until then.
Are you going to IO?
If so, I'd love to buy you a beer as way of saying thanks for the library.
On Mon, 25 May 2015 2:36 am greenrobot<EMAIL_ADDRESS>wrote:

Sorry I hav to ask for some patience on this one. Annotations will be in
first.
—
Reply to this email directly or view it on GitHub
https://github.com/greenrobot/EventBus/pull/174#issuecomment-105034106.

An update on the Sun/Oracle JVM accessibility. It appears that it is is denying access because it is an anonymous class. If I declare a class and then instantiate it its ok.
@greenrobot And great to catch up with you at IO.

Hey Marcus, any chance of getting this merged?

Marcus, If you need me to rebase I can.

Closed in favour of #247


[Wait for other PR] [Connection] list of connections

Add list of connection data and remove glib table.
Signed-off-by: Jaeyun<EMAIL_ADDRESS>

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

:octocat: cibot: @jaeyun-jung, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/78-202208301758560.37283396720886-950079307c1753cb74e1764fde63450edb7ed8a4/.

:octocat: cibot: @jaeyun-jung, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/78-202208301835500.27094888687134-0d39edd3d1d1000b28829fd6fee5045e272dd802/.

:octocat: cibot: @jaeyun-jung, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/78-202208301901110.714026927948-31c23b0dc912e96829ec5cfff6b092adebf36346/.

:octocat: cibot: @jaeyun-jung, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/78-202208301910070.84167695045471-0bf1638d68b5b80d070cff470a8abe1224c3ff82/.


where  is currentStep()??

i can't get current step

@yuraSpivak1994 https://shepherdjs.dev/docs/Tour.html#getCurrentStep
this.shepherdService.tourObject.getCurrentStep


Creating a new artifact should return the URL to it

Feature or problem description
When creating an artifact in Schema Registry in CLI, it should print the URL to UI to view the newly created artifact.
Proposed solution
The artifact url in the ui looks something like this - https://console.redhat.com/beta/application-services/service-registry/t/d5e6012f-ce90-4aaf-85b3-5f6e21a97e60/artifacts/default/rama-5/versions/latest
URL format: <registry-browser-url>/artifacts/<group>/<id>/versions/<version>

@wtrocki would we like something similar for get metdata command?

Sure.


Add Go app

Added using the steps from #27.

Nothing important left to discuss, so getting this merged in.


Format conventions for all pages

We need a consistent way to format the rules, explanation and examples.
Constraints

Docusaurus

Goal of this issue

Gather possible formats
Decide on a format

Out of scope

Update all existing pages according the new format.

First thoughts that come to mind:
## <Subject>
### Generic
### Settings
### Variables
### Test Cases or Tasks
### Keywords
### Specials

We should document this in the Contribution.md see issue #42


[bump] build-tools: 0.23.0 => 0.23.1 (patch)

Bumped build-tools from 0.23.0 to 0.23.1.

from incorrect branch


Create nadaelkady

All things empowerment are at the core of what drive Nada. Her passion and dedication to the growth of individuals, teams, and organizations coupled with her laser-focused, methodical, and agile approach to strategic planning and tactical implementation allow her to get to the heart of any initiative to help create clarity, alignment, and relentless movement forward.

not quite right, working with nada to fix


feature: adding syevd in PCA Cov

Description
This pr contains adding new syevd gpu function in PCA. Will be green after moving on the new MKLGPUFPK

What's the status for this PR?

@ethanglaser This pr will be closed, but the changes will be added in https://github.com/oneapi-src/oneDAL/pull/2756, due to we will not have an access to micromkl syevd later