Client Allocation Request for: Goin-tech

Client Allocation Questions
Core Information

Name: Goin-tech
Website / Social Media: https://www.goin-tech.com
Region: Greater China
DataCap Requested: 10TiB
Addresses to be Notarized: f137m6gt5sv7gb6wvgzp7tlagjgp2opkimdvsbkea
Notary Requested: Broz221

Thanks for your application. @126dong
Please answer following questions:
What's your name? What's your duty in this company? Please give me your E-mail address and your brief introduction.
Please give me simple overview of your company. (Company scale, establish time, project, use case, etc.)
What's you/your company's contribution to Filecoin? (If exsit)
What kind of data do you want to store? And how much? How about copy right of data?
How many miners do you want to store data to? Which aspect will you inspect these miners?
Could please you introduce your past usage of cloud storage?

Hi Broz221, I am Zhang Yuanjie, technical director of GOIN-TECH，mainly responsible for the research and development of computer network technology and market transformation. This is my email<EMAIL_ADDRESS>Our company was established in July 2015, mainly focus on computer network technology service provider and engaged in the development and sales of computer software.
Not yet .
We want to store some user information on the network, including text, pictures and videos. It's about 10 TiB. The data does not have copyright implications.
We will mainly look at the size and credibility of the miners.
We mainly used Tencent cloud.

Hi. I have sent you E-mail to get more private detailed information. Please check.

Thank you very much. I have sent the email to you.

Request Approved
Your Datacap Allocation Request has been approved by the Notary
Message sent to Filecoin Network

bafy2bzaceaoyxozimfb3pur7z745a3envxw3eidu75p5fni6xthld6fa6jdg2

Address

f137m6gt5sv7gb6wvgzp7tlagjgp2opkimdvsbkea

Datacap Allocated

10TiB

You can check the status of the message here: https://filfox.info/en/message/bafy2bzaceaoyxozimfb3pur7z745a3envxw3eidu75p5fni6xthld6fa6jdg2


force export fail when "Insights" type folder exists.

When force export, I encountered an error:
$ force export
DeveloperName, Folder.DeveloperName from Insights
                                         ^
ERROR at Row:1:Column:53
sObject type 'Insights' is not supported. If you are attempting to use a custom object, be sure to append the '__c' after the entity name. Please reference your WSDL or the describe call for the appropriate names.

Some orgs return Folder record that Type is "Insights".
Then, this query will be SELECT Id, DeveloperName, Folder.DeveloperName from Insights.
https://github.com/heroku/force/blob/95f3519744e176e8cc23bc55ceacb4781817ad38/export.go#L32
But sObject type "Insights" is not supported. So force export fail.
This query might be SELECT Id, Type, DeveloperName from Folder where Type in ('Dashboard', 'Document', 'Email', 'Report').
https://github.com/heroku/force/blob/95f3519744e176e8cc23bc55ceacb4781817ad38/export.go#L169
I don't know why "Insights" type folder exists, and what "Insights" type means. It's undocumented.
https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_folder.htm

+1 Same issue.

I had overlooked the fix.


Error run sonobuoy with empty plugin list

What steps did you take and what happened:
I tried to run sonobuoy with an empty plugin list, in order to just collect podlogs.
sonobuoy gen config|jq '.Plugins=[]' > noplugins.conf
sonobuoy run --config noplugins.conf

The sonobuoy master docker is stuck in creating:
NAME       READY   STATUS              RESTARTS   AGE
sonobuoy   0/1     ContainerCreating   0          2m1
2s

And the reason is
Events:
  Type     Reason       Age                From               Message
  ----     ------       ----               ----               -------
  Normal   Scheduled    51s                default-scheduler  Successfully assigned heptio-sonobuoy/sonobuoy to minikube
  Warning  FailedMount  19s (x7 over 51s)  kubelet, minikube  MountVolume.SetUp failed for volume "sonobuoy-plugins-volume" : configmap "sonobuoy-plugins-cm" not found

What did you expect to happen:
Sonobuoy master docker is running. And podlogs are gathered in tarball.
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
Environment:

Sonobuoy version: v0.15.0
Kubernetes version: (use kubectl version): 1.14.0
Kubernetes installer & version:
Cloud provider or hardware configuration: local minikube
OS (e.g. from /etc/os-release): macos
Sonobuoy tarball (which contains * below)

This seems like it should have a pretty simple cause; the plugins normally go in the configmap and then they're mounted into the aggregator. In this situation we have no plugins so I guess the plugin config map fails (surprised that doesnt cause some sort of error though in the cm phase).
The template shows:
---
{{- if .Plugins }}
apiVersion: v1
data:{{- range $i, $v := .Plugins }}
  plugin-{{- $i -}}.yaml: |
    {{ indent 4 $v }}
{{- end }}
kind: ConfigMap
metadata:
  labels:
    component: sonobuoy
  name: sonobuoy-plugins-cm
  namespace: {{.Namespace}}
{{- end }}
---

and that just needs tweaked so that the config map is always valid/created and just the data is added as necessary.


Investigate to use embedded database

Some suggestions:

SQLite: https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-mvc-app-mac/working-with-sql
LiteDB: https://github.com/mbdavid/LiteDB/wiki
DBreeze: https://github.com/hhblaze/DBreeze/wiki

This issue is related to #12


This repo does not compile in jdk9

Note: This might just be that I'm super rusty at java and am missing something silly.
When I set my JAVA_HOME to a jdk9 path and mvn compile, I get:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:3.0.0:check (checkstyle) on
project google-cloud-pom: Execution checkstyle of goal
org.apache.maven.plugins:maven-checkstyle-plugin:3.0.0:check failed: Plugin
org.apache.maven.plugins:maven-checkstyle-plugin:3.0.0 or one of its dependencies could
not be resolved: Could not find artifact com.sun:tools:jar:1.7.0 at specified path
/Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home/../lib/tools.jar -> [Help 1]

When I set my JAVA_HOME to a jdk8 path and mvn compile, it works.
This seems to be a known issue with checkstyle. I'm not sure how org.apache.maven.plugins » maven-checkstyle-plugin (which we use) relates to github.com/checkstyle/checkstyle; their versioning seems quite different (github latest is 8.8, whereas maven latest is 3.0.0 ).
edit: the difference between the two seems to be that the github one is the checkstyle project itself, and the maven thing is just a maven plugin possibly using the checkstyle project?

I'm not quite sure how to categorize this. Provisionally giving it P2, but please bump if you think it's more urgent.

This repo compiles with Java 11 and we'll be supporting official GA Java versions moving forward.


Difficulty in evaluating perplexity in story generation task

Thanks for the source code sharing. I re-train the model in story generation task on Writingprompts dataset using almost same config (except less GPUs) and your provided .bpe files. My goal is to evaluate the test perplexity as reported in Table 3 of your paper.
However, the only way I find promising seems not working: the OpenNMT library in your code can evaluate "GOLD score" for the target sequences. The GOLD score is printed after running 'python translate.py' with given target.  However, I got unreasonable PPL results as following:
PRED AVG SCORE: -0.0040, PRED PPL: 1.0040
GOLD AVG SCORE: -9.7727, GOLD PPL: 17548.5739
The GOLD scores are incredibly high. I am wondering how you evaluate the PPL just as you reported in Table 3. Whether or not you would like to share this evaluation code in the repository? Many thanks.

Linked to pull request https://github.com/harvardnlp/encoder-agnostic-adaptation/pull/11


contribute to book

@EDiLD @zachary-foster @gedankenstuecke @arendsee @jarioksa @ibartomeus @jimmyodonnell  @johnbaums
started this bookdown for taxize pkg. I think we can include taxizedb here as well. I think there's sufficient reason to do a bookdown for taxize/taxizedb because of the complexity and importance of the project
if you want to contribute please do. however, there's no pressure at all to contribute.
I have no intention of publishing this - it seems a nice way to package up documentation

Great initiative @sckott !
However, I don't know if my free time permits much contributions :(
In fact, I am happy if I can find the time to take care of the webchem package...

I’ll be busy traveling to finally defend my PhD this week. But i will have a look afterwards. Also @trvinh might have interest in contributing to this!

Cool project! I'll look it over. Are you interested in collecting usage examples?

@EDiLD Okay, thanks for the update

@gedankenstuecke ok, thanks for pinging @trvinh

@arendsee (there's not much there yet :)) Yes, interested in use cases for sure, probably a chapter on use cases, with as many as we can find

Sounds great @sckott! I’m a bit time poor these days - 1 year old at home!
Looking forward to taking a look.
On Sun, 4 Feb 2018 at 4:25 am, Scott Chamberlain<EMAIL_ADDRESS>wrote:

@EDiLD https://github.com/edild @zachary-foster
https://github.com/zachary-foster @gedankenstuecke
https://github.com/gedankenstuecke @arendsee
https://github.com/arendsee @jarioksa https://github.com/jarioksa
@ibartomeus https://github.com/ibartomeus @jimmyodonnell
https://github.com/jimmyodonnell @johnbaums
https://github.com/johnbaums
started this bookdown for taxize pkg. I think we can include taxizedb
here as well. I think there's sufficient reason to do a bookdown for
taxize/taxizedb because of the complexity and importance of the project
if you want to contribute please do. however, there's no pressure at all
to contribute.
I have no intention of publishing this - it seems a nice way to package up
documentation
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ropensci/taxize-book/issues/1, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAx9BlssNdf_TpeAyh3dMqBOk3TUBtXeks5tRJafgaJpZM4R4P2l
.

@gedankenstuecke , @sckott nice to have this documentation 👍  I will be happy to contribute to this project :-)

Same here, very cool idea but not much time. Would be good if you list sections for which you will especially need help (e.g. user cases).

thanks @ibartomeus - good idea, haven't sorted out a preliminary set of chapters yet, but will do that when I do

@sckott If you make a taxizedb chapter, I'll at very least throw in a few usage examples. I've been intending to write a vignette for the package anyways.

@arendsee awesome, thanks. Yes, do plan to have a taxizedb chapter

Good idea @sckott! I will help in my spare time. Ping me if there is anything specific you want me to do.

Ditto to the above -- I don't have a ton of spare time, but support the idea and am happy to at least contribute examples for the functions I've worked on.

thanks @jimmyodonnell , sounds good.

Everyone is an author, just FYI, even for contributing only use cases/examples


Yacht too

yacht: proof solution did not pass the tests

@axtens what happened?

What happened was me not thinking about how cobolcheck runs things. I had written yacht.cob to be loaded and executed for each play. Cobolcheck however, loads the program once and then executes the tests in that environment. So I have to explicitly move zeroes to variables I could otherwise allow the working-storage to initialize for me.

So is everything working now? Would that be an issue for the students?

Everything working. As for it being an issue for the students ... they'd realize eventually

@axtens, Can we do:
           BEFORE-EACH
               MOVE ZEROES TO WS-COUNTER.
               MOVE ZEROES TO WS-RESULT.
           END-BEFORE

or would it have side effects?

Hey @0xE282B0, the BEFORE-EACH keyword doesn't seem to be part of the COBOL standard, maybe it would be better not to use it. Which compilers support the BEFORE-EACH keyword?

@KTSnowy it's not Cobol it's part of the test framework:
https://github.com/openmainframeproject/cobol-check/wiki/A-Brief-Example#a-brief-sample

@KTSnowy it's not Cobol it's part of the test framework:

Ohhh that makes sense, I'm sorry.
So maybe we could do that so that the students don't have to move ZEROES themselves, and we would probably have to explain that the variables already have zeroes in them to avoid confusion. Maybe with a comment?

Would that cause any issues for the students?

@axtens, Can we do:
           BEFORE-EACH
               MOVE ZEROES TO WS-COUNTER.
               MOVE ZEROES TO WS-RESULT.
           END-BEFORE

or would it have side effects?

I can't think what side effects there would be. Exercism encourages students to read the test cases. The above would simplify off at least reduce the code in the proof


How to run pod with exposed port and two apps from the same image? (port name defined multiple apps)

I'm trying to run something like the following
rkt ${ACI} --exec /bin/sleep -- 33 --- ${ACI} --name app-two --exec /bin/sleep -- 44

It works but fails as soon as I map a port --port app:8888 ("app" is defined in manifest):
run: error setting up stage0
└─port name "app" defined multiple apps

Is it possible to run pod with exposed port(s) and two apps from the same image?
How?

I've just ran into the same problem but wasn't able to find a solution either, but I think the problem here is the shared network namespace in the pod(both apps want to bind localhost:8888) and the fact that rkt doesn't like the port "app" to be defined twice.


URL Cleanup

This commit updates URLs to prefer the https protocol. Redirects are not followed to avoid accidentally expanding intentionally shortened URLs (i.e. if using a URL shortener).
Fixed URLs
Fixed But Review Recommended
These URLs were fixed, but the https status was not OK. However, the https status was the same as the http request or http redirected to an https URL, so they were migrated. Your review is recommended.

[ ] http://www.puppycrawl.com/dtds/configuration_1_2.dtd (404) with 1 occurrences migrated to:
https://www.puppycrawl.com/dtds/configuration_1_2.dtd (https result 404).
[ ] http://www.puppycrawl.com/dtds/suppressions_1_1.dtd (404) with 1 occurrences migrated to:
https://www.puppycrawl.com/dtds/suppressions_1_1.dtd (https result 404).

Fixed Success
These URLs were switched to an https URL with a 2xx status. While the status was successful, your review is still recommended.

[ ] http://www.springframework.org/schema/beans/spring-beans.xsd with 4 occurrences migrated to:
https://www.springframework.org/schema/beans/spring-beans.xsd (https result 200).
[ ] http://www.springframework.org/schema/context/spring-context.xsd with 2 occurrences migrated to:
https://www.springframework.org/schema/context/spring-context.xsd (https result 200).
[ ] http://www.springframework.org/schema/integration/kafka/spring-integration-kafka.xsd with 4 occurrences migrated to:
https://www.springframework.org/schema/integration/kafka/spring-integration-kafka.xsd (https result 200).
[ ] http://www.springframework.org/schema/integration/spring-integration.xsd with 2 occurrences migrated to:
https://www.springframework.org/schema/integration/spring-integration.xsd (https result 200).
[ ] http://www.springframework.org/schema/task/spring-task.xsd with 2 occurrences migrated to:
https://www.springframework.org/schema/task/spring-task.xsd (https result 200).
[ ] http://www.springframework.org/schema/util/spring-util.xsd with 2 occurrences migrated to:
https://www.springframework.org/schema/util/spring-util.xsd (https result 200).

Ignored
These URLs were intentionally ignored.

http://www.springframework.org/schema/beans with 8 occurrences
http://www.springframework.org/schema/context with 4 occurrences
http://www.springframework.org/schema/integration with 4 occurrences
http://www.springframework.org/schema/integration/kafka with 8 occurrences
http://www.springframework.org/schema/task with 4 occurrences
http://www.springframework.org/schema/util with 4 occurrences
http://www.w3.org/2001/XMLSchema-instance with 4 occurrences

Merged after upgrading to SI-4.3.20


Flow First Step Size Multiplier impacts overall step size

Follow instructions in #3318
Adjust First Step Size Multiplier

Notice the final trajectory length varies as you change the First Step Size Multiplier. Below are examples with different First Step Size Multiplier values:
1E-4

1E-3

1E-2

1E-1

2E-1

Hmm, I would not consider this a bug. Let me clarify.
A less obvious fact about flow line integration is, there isn't an absolutely true flow line that renders all others false. The step size in use definitely has an impact on the shape and/or length of the output flow line, they can all be correct step sizes, though different.
Ideally, the flow integration step size results the particle being advected travel exactly one grid cell a step. If a particle travels more than one grid cell a step, it skips grids, which is usually considered wrong. If a particle travels multiple steps in one grid cell, one doesn't gain more information/accuracy inside of the same grid cell;  it's considered less than ideal because unnecessary computation is performed, but it's not considered wrong. In fact, the flow code automatically adjusts the step size of every integration operation trying to be close to the ideal situation.
As far as the observation reported here, it's just a natural result of different step sizes. They can be and do appear to be correct at the same time.


Add 'nil' alternative for param and return docs in meta

Add nil alternative to the Optional types in in the generated meta files.

looks good


refactor: Raise an exception

Checklist

[x] I've ran pre-commit to format and lint the change(s) made.
[ ] I've checked to make sure the change(s) work on 3.8.6 and higher.
[ ] This fixes/solves an Issue.

(If existent):

[ ] I've made this pull request for/as: (check all that apply)

[ ] Documentation
[ ] Breaking change
[ ] New feature/enhancement
[x] Bugfix

should be fixed by #848


Room concensus

Trying to wrap my head around the best approach to maintaining our distributed photo albums. @andrewxhill @carsonfarmer one of you mentioned CRDTs, there's some good stuff out there: CRDTs. We've also discussed blockchain consensus techniques.
However, after drawing it out, I think our current solution might just work as is. A room can be thought of as a set of cumulative updates (adds / deletes). The problem we have is just how to get each peer every add and every update, considering very unstable connectivity?
We currently broadcast updates which are simply just the root hash of the added photo set (photo, thumb, metadata, last), where "last" is a file containing the hash of that node's last update's root hash. Our little blockchain of updates. #40 is important: each peer needs to continuously re-publish it's HEAD update, otherwise new comers won't be able to partake until a new update happens. When a peer gets an update, it handles it recursively, making sure it has locally (and has indexed) the contents of the update, and each prev. update by inspecting the last file.
Side note: Right now, every update is implicitly considered an "add", but we could change that via some scheme on the update itself: op:hash, e.g., add:QmY2nposvuCaikdazPNDc4vY4CAxZgioZ9Wf1JuamBmRQQ, del:QmXARYDDjf27tDNGpWYjCW9c8X6i5BrvUkLKKwrRotsuys.
That said, just considering adds for now, this is what happens with 2 peers:
n1
<--0:a
<--a:b
<--b:c
n2
0:a<--
a:b<--
b:c<--
The syntax here is <--last:new for sending and last:new<-- for receiving an update. So far n1 has been making updates and n2 has been receiving them just fine, easy peachy! Ok but now n2 goes for an airplane ride and looses the p2p network. The thing is, both peers are still taking photos:
n1
<--0:a
<--a:b
<--b:c
<--c:d
<--d:e
n2
0:a<--
a:b<--
b:c<--
<--c:d'
<--d':e'
When n2 lands, this happens:
n1
<--0:a
<--a:b
<--b:c
<--c:d
<--d:e
d':e'<--
c:d'<--
n2
0:a<--
a:b<--
b:c<--
<--c:d'
<--d':e'
d:e<--
c:d<--
Each node gets the latest update from the other, then back propagates on each to find its peer's older updates. Each will stop on the common ancestor, i.e., n2 will stop when it hits c:d because it already has c, and n1 will stop when it hits c:d', because it too already has c. Since each update is indexed locally by the time it was initially added to the system, we end up with the same exact set of data. The update order doesn't matter (esp. in the only add case, little more complex with deletes, but I think still in our current wheel house... we just have to reprocess deletes until the target content is available). So, different update chains lead to the same data set, same as there are different (infinite) ways to add to any number. I guess it's obvious in the end...  Also, I don't think we care about POW / POS since in order to generate a valid update in the room, you need to encrypt / sign the payload with the rooms private key... so we can just say, if you're able to decrypt / verify it, it should be considered good. So, in our case, all peers are trusted (is that bad?)
Making sense? What am I missing? Seems too easy!? Maybe this is actually a simple CRDT protocol.

This all seems reasonable sander. I think the ipfs folks were discussing these types of issues.  But for us, with this simple application to start, I say keep it simple 👍

i'll think about this more, but on first pass it seems fine. later optimizations could be made with blocks of transactions for example. i realized also that your delete issue is easily solvable by adding deletes as a new add transaction. same with say, a concept like a modification.
a delete would just add an action delete on an old hash, in reverse traverse you get the delete first so the world is easier actually.
a modification would be an add of an action replace, old for new. again, in reverse traverse you'd only ever get the newest modification and the older would be treated like a delete. so again for the node catching up the world is actually a bit easier since you just ignore everything about it prior.

this is getting at that comment i made to you a couple weeks ago. where you could prepend the hash with our own hash code, where perhaps the first character just indicates an action.

@andrewxhill re: hash structure, yeah for sure. I think actually this won't work though since the deletes will need to be part of a peer's update chain as well... so it'll need to be content addressed with a last hash, which means it's own root hash won't be the same as the root hash it's indicating to delete... so the advantage of the simplification in putting the operation in the publish payload itself falls away, since it can be equally implied, like an add operation.
re: blocks, totally, especially (or perhaps only) for high frequency data like location updates

@gpestana ^

Hey there! Really cool project, great job! I've talked with @sanderpick really briefly about what you are up to and textile.io. I've been really interested about CRDTs and decentralization in general so glad to see this happening. Anyways, I really haven't got much time to go through the code and get a good overview of the current implementation and ideas, but these are my 2 cents based on this thread. I'm sorry in advance if my comments are useless/out of context because of lack of understanding of the project.
Ok, first I assume that a "blockchain of updates" is a sort of set with all transactions made on an album level. A grow-only (no item removal) set. This blockchain makes it possible  to traverse the whole album just by knowing the latest picture ID.
It seems to me, based on what @sanderpick explained when opening this thread is that you are using a grow-only set. Some concerns with GO-sets are tombstones and garbage collection - when an item is removed, it's hard to know when it can be really removed from the set without the risk of being added back by some node which didnt get the 'delete' update. On the other hand, keeping all the transactions might bring scalability issues in the future (not sure if I'm bringing up stuff that really doesn't matter much atm)
Another thing I'm thinking about is casual ordering, but it seems that in the album example it does not really matter? So a photo is either in 'added' or 'removed' based on the state of the blockchain. Is there any possibility that a node received a 'delete' update of a photo he never had in his local replica? I can't see this happening, so it should be fine. But then again, I might be missing something.
Oh, BTW, It'd be really cool if you guys would have some simple documentation on the technical decisions and whatnot so that newcomers could easily get up to speed. Or did it exist and I didn't find it? Anyways, I will create an issue about it.
I will be adding more comments here as I think about this. Keep it up!! :)

The assumption about the "blockchain of updates" is spot on.
re: tombstones, good point, makes sense. At least for now, the only node that would be "adding it back" is the one that created it, which I suppose would be the only one that could delete it. However, we haven't seriously talked about deletion. Soon we'll have to figure out how to republish other peers' updates, at which point this will have to come up.
re: deletes that may not be local, I think this could happen in the current setup. However, in theory, it would be able to traverse back through those updates and find the add... more logic needed here since in this case it would result in an add. We'd have to save off the deletes as "pending" if it didn't yet exist locally.
We'll have to come back to this soon, after our current beta release sprint (next week). The biggest weakness, and I'd say deal breaker, is the fact that both the update sender and receiver have to be online at the same time for a sync to happen.
The updates are sent via IPFS pubsub (floodsub). Our current experience is one of "fire and forget", where the "forget" applies to the whole network. In other words, the updates are not persistent. If a node could come online and get all the updates it missed, we'd be gold! @andrewxhill found a very relevant issue... seems a lot of folks want this: https://github.com/libp2p/go-floodsub/issues/42
Thanks for your helpful thoughts!

closing in favor of #123


[Release] sdk/resourcemanager/appcontainers/armappcontainers/2.0.0-beta.3

https://github.com/Azure/sdk-release-request/issues/4132

@Alancere please add the swagger breaking change source.


fix: bitwise shift overflow of UInt types

It is an undefined behavior in C when the right operand of a shift operation exceeds the bit-width of the left operand.
It caused a difference between compiled code and kernel interpretation because 1 << 32 evaluates to 1 with a typical x86_64 compiler.
Note: 32 in the (1 : UInt8) <<< 32 test is because the (1 : UInt8) <<< 8 test doesn't cause overflow because the operand is promoted to int.
The added test is failing because an inline C code is not realized until stage2.
Should I include "update stage0" commit to the PR in such a case?

Introducing a branch to such a low-level operation feels a bit wrong; we could use Java's semantics and reduce the RHS modulo the type's bitwidth (e.g. take the lowest 5 bits for UInt32). Those are also Rust's semantics, except it panics instead (as on any overflow) if debug assertions are enabled. @leodemoura @joehendrix WDYT?

@Kha I agree with you.

@kha I agree.  I think using the Java semantics is the way to go.

I changed the implementation to match Rust's wrapping_shl (RHS is modulo LHS bit width). Note Java has only shift operators defined for int and long, and other integer types are promoted, so this UInt8 shift and Java's (byte)x << (byte)y is different.
The implementation is a bit awkward (uses of toNat and ofNat) due to the heterogeneous nature of the shift operation.
I wonder it should be an instance of HShiftLeft UInt8 (Fin 8) to make it more type-correct, but I think it is getting out-of-scope for this PR as it was intended to be a quick fix.

Thanks!

Could the new shift operation get a different name, similar to Rust's wrapping_shl? I think it would be better for the lean version to reserve the simpler name for the less mathematically surprising behavior, even if it comes at the cost of a branch.

@digama0 Do you object only to the name or to using the operator for it as well?


Real-time updates aren't working :-(

This appears to be because the cron wasn't picking up the DEPLOYMENT_TARGET. Should be fixed now.

It's fixed!


Cannot read property 'subscribe' of null

I may be missing something obvious, so apologies if that's the case but I can't seem to figure out how to get this Addon to work correctly (latest master build).
I've installed the addon, injected the service controller bindings but I get the following error:
Error while processing route: index Cannot read property 'subscribe' of null TypeError: Cannot read property 'subscribe' of null
  at ConnectChannel
  at wire

After looking through the source code it appears service.init() is being triggered, but service.setup() is not, which is where this.pusher is defined. How do I call service.setup() from my application with the required configuration?

@marcqualie You call setup in an application instance initializer. It takes the same arguments as the Pusher constructor. See: https://github.com/jamiebikies/ember-pusher/blob/master/addon/services/pusher.js#L55-L59

export function initialize(instance) {
  let pusherService = instance.container.lookup('service:pusher');
  pusherService.setup(YOUR_KEY, extraPusherOptions);
  });
}

export default {
  name: 'ember-pusher',
  initialize: initialize
};

@mmun thanks for the very quick reply, that worked perfectly. It was my lack of service understanding that I needed to add my own initializer to my application as it existed in your app/initializers folder.

Shouldn't this be mentioned in the README?...

Yes, I'm not using pusher right now so I don't have time to update it. Happy to review any PRs that bring the addon closer to 1.0. Please make an issue if you'd like to discuss something before implementing.


[2.4.X] Node Stuck Deleting if Node Template was already deleted

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):
Using the rancher terraform provider I create a node_template and a node_pool. Then I run a destroy and the node_template is deleted along with the node_pool.
Result:
The nodes are still being processed by the node controller and start to error that the node_template does not exist anymore and is not deleted.
Other details that may be helpful:
Few options to fix this:

Rancher should reject a node_template delete so that it can't be removed when nodes are still referencing it
The nodes should hold a copy of the last used node_template version so that way if it is deleted it can still processed.

Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):
Installation option (single install/HA): HA

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): vSphere
Machine type (cloud/VM/metal) and specifications (CPU/memory): VM
Kubernetes version (use kubectl version): 1.17

The only work around is to manually delete the nodes and update the node object in rancher cluster and remove the node controller finalizer.

Rancher version: v2.4.2
Using terraform destroy -target=rancher2_node_template.foo
Here I see this behavior. In the Rancher UI the cluster will be in a Red Updating state with NodeController errors in the Rancher logs.
Deleting the node_template resource from Terraform will also trigger the deletion of node pools as dependencies.
Deleting Manually from UI
Also if done quick enough to delete the node pools and then the Node Template the cluster ends up in a similar Failed state, but it could also be because the etcd node and other nodes were deleted here is a screenshot:

Cluster health check failed: Failed to communicate with API server: Get https://<IP_ADDRESS>:6443/api/v1/namespaces/kube-system?timeout=30s: waiting for cluster [c-txnxx] agent to connect; waiting for etcd and controlplane nodes to be registered

E0403 00:03:17.286921       7 reflector.go:153] github.com/rancher/norman/controller/generic_controller.go:229: Failed to list *v1.Endpoints: Get https://<IP_ADDRESS>:6443/api/v1/namespaces/cattle-prometheus/endpoints?limit=500&resourceVersion=0&timeout=30s: waiting for cluster [c-txnxx] agent to connect

The cluster will keep failing unless I delete it.

Same here, I have rancher 2.3.6.
Steps to reproduce from the UI:

Assing a new node template to a existing node pool.
Delete old node template while nodes keep running.
Delete one node on the node pool to recreate with the new template.

The node stuck in "Removing" state with the following error:
Unable to refresh config for node m-gz2r6: nodetemplates.management.cattle.io "nt-76gkj" not found; waiting on node-controller

With rancher 2.3.6, another side effect, is that when using the Terraform provider 1.8.2, with dedicated node pool for etcd, if we do not create a direct dependency between the node template and the cluster, destroying the cluster and all resources will succeed with no error but etcd nodes will be left in the backing cloud (in our case openstack).

I have tried adding depends_on and it didn't work for me. Part of the reason could be that I am using a mixture of Amazon EC2 and Custom nodes, though I am not sure why would that make a difference.

Summary of investigating this:
The first cause seems to be that nodes are deleted later than the API returns that parent resources are deleted, meaning that when a cluster and/or nodepool is deleted (as in, confirmed by API response from Rancher), the nodes are not actually deleted yet using the backed node driver. The controller will start taking care of that, but at that point, the parent resource is already deleted and returned by the API. This means that the state that the caller (using API/UI or Terraform) gets is valid for that resource, but not dependent resources. This means that nodes still need the node template when they are actually deleted, but based on the response (and the missing check for node references to the node template), the node template is deleted before the nodes are removed. The second part is that the check when deleting a node template is only done on node pools referencing the node template. As node pools can be deleted at any time (and the nodes will be deleted after the controller and backed node driver took care of it), the node template needs to be present as long as nodes are referencing it (and not just node pools). The node config is refreshed using the node template, so it needs to be present at the time of deletion.
The least intrusive way to fix this issue in my opinion is to extend the check on node template deletion from just checking node pools referencing it to also include checking the nodes referencing it (https://github.com/rancher/rancher/blob/release/v2.4/pkg/api/store/nodetemplate/store.go#L119). The API will return the same response as when node pool(s) is/are referencing it, namely MethodNotAllowed. The reason why this is least intrusive is that its reusing the logic for node pools referencing the node template, and we make the caller in a similar way responsible for retrying to delete it when its not referenced anymore. (in the example of Terraform, the logic needs to adjusted to retry on this response). This could be made configurable so that when backing node driver takes longer to delete, the retries can be extended.
The reason this behavior is not seen "by default", is because when you delete a cluster in the UI, we don't delete the node template. In case of terraform, all resources are in scope (being created and destroyed).
Other options might be:

Introduce a dependency on the nodes when deleting nodepool (which would basically include a dependency from cluster->nodepool->nodetemplate). This is part of why the option above is less intrusive, as we retain most of the current logic and add another check. If we add a dependency check in either of those, the API call will be blocked until everything is done (which can be a long time if any of the dependencies is slow to delete). I also dont like creating a chain of dependencies that can be blocking (and also defers from the way it is now)
Save a copy of the nodetemplate when creating the node so its always available for deletion. This is a change that needs migration for existing setups (if even properly possible) and possible sync issues between the copy and the changed nodetemplate.
Mark the nodes for deletion and return success if node template is deleted without nodes referencing it or only with nodes referencing that are marked for deletion. This won't work as it needs it on deletion.

Reproduced with terraform in Rancher v2.4.5, some nodes were left in the infrastructure provider as well as errors with node template references.
Rancher v2.4-head (07/16/2020) e28427e4a
Rancher master-head (07/16/2020) e4e2a13da
Standard user used for creating and destroying the cluster in all Rancher versions.

All the nodes were removed from the infrastructure provider
No 405 errors if the build with the new retry logic is used.


release notes, previous to 0.20, have unexpected links to API

Describe the bug
The website https://docs.quantum.ibm.com/api/qiskit-ibm-runtime/release-notes includes some funky link. While they work as expected, it seems that they do not look as expecting:
Steps to reproduce

Go to https://docs.quantum.ibm.com/api/qiskit-ibm-runtime/release-notes
Ctrl+F and search for >`__
See 116 instances of Sphinx syntax showing up after rendering

@Eric-Arellano @arnaucasau can you take a look? I'm not sure why the links aren't rendering correctly


Adding GH action to generate literate documentation

Description
Added GH Actions to generate literate docs
Type of change

Refactor (refactoring code, removing useless files)
Documentation update

Testing steps
Regular CI + Actions run
Checklist

[x] make before_commit passes
[x] updated documentation wherever necessary
[x] added or modified tests if necessary
[x] updated schemas and validators in insights-data-schemas in case of input/output change

Codecov Report

Merging #494 (e4bc6fd) into master (37e77ae) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #494   +/-   ##
=======================================
  Coverage   50.60%   50.60%
=======================================
  Files          12       12
  Lines        1162     1162
=======================================
  Hits          588      588
  Misses        489      489
  Partials       85       85

Continue to review full report at Codecov.

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


Update to Java 17

https://github.com/actions/setup-java/issues/233#issuecomment-925039615

@ThoSap Thank you!


Obioma Eke: Assignment4

This PR is pulling in your assignment 3 commit, we don't want that to happen. Try rebasing and pushing again with
git fetch upstream
git rebase upstream/main
git push -f origin assignment4```

If this doesn't work, stop by office hours and we will help you fix it. Always make sure to start on a fresh branch after pulling latest upstream down to avoid such issues in the future.

This PR is pulling in your assignment 3 commit, we don't want that to happen. Try rebasing and pushing again with
git fetch upstream
git rebase upstream/main
git push -f origin assignment4```

If this doesn't work, stop by office hours and we will help you fix it. Always make sure to start on a fresh branch after pulling latest upstream down to avoid such issues in the future.

@umohnani8 Thank you so much for letting me know! I just force pushed it. I also accidentally closed my pull request with my comment but I reopened it. Is there anything else I need to do?

You are all set! LGTM


updating deps. rn 24.1

we upped to rn 23 yesterday but this goes to 24.1
@keybase/react-hackers

👍


mkpr

Applied mkpr on package.json
sed s/"npm-pkgbuild": "^.*"/"npm-pkgbuild": "^6.10.4"/

Pull Request Test Coverage Report for Build 2279

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

Totals

Change from base Build 2277:
0.0%

Covered Lines:
361

Relevant Lines:
375

💛  - Coveralls


Error while trying to run application via command line

Issue type: Support request
What happened:
I got error(see below), while trying to start the application via commandline.
How to reproduce it (as minimally and precisely as possible):

Deploy nginx with provided log format and generate some logs
Start it with command below

Other important information:
# Nginx log config:
    log_format mtail '$remote_addr - $remote_user "$time_local" '
                     '"$request" $status $body_bytes_sent '
                     '"$http_referer" "$http_user_agent" '
                     'rt="$request_time" uct="$upstream_connect_time" uht="$upstream_header_time" urt="$upstream_response_time"';

Configuration file (remove section, if not applicable):
# Please post the contents of your configuration file, here
# Was started via comandline
/prometheus-nginxlog-exporter
-format="$remote_addr - $remote_user \"$time_local\" \"$request\" $status $body_bytes_sent \"$http_referer\" \"$http_user_agent\" rt=\"$request_time\" uct=\"$upstream_connect_time\" uht=\"$upstream_header_time\" urt=\"$upstream_response_time\""
-listen-port=9114
-namespace=nginx
/tmp/nginx-logs/access.log

Example log file (remove section, if not applicable):
# Please post an excerpt of a log file that can be used to reproduce the error
# Keep the excerpt as short as possible and make sure to redact any sensitive data.
 using configuration {{%!s(int=9114) <IP_ADDRESS>} {%!s(bool=false)     {  []}} [{nginx [/tmp/nginx-logs/access.log] "$remote_addr - $remote_user \"$time_local\" \"$request\" $status $body_bytes_sent \"$http_referer\" \"$http_user_agent\" rt=\"$request_time\" uct=\"$upstream_connect_time\" uht=\"$upstream_header_time\" urt=\"$upstream_response_time\"" map[] [] [] []}] %!s(bool=false)}
starting listener for namespace nginx
running HTTP server on address <IP_ADDRESS>:9114
panic: regexp: Compile(`^"(?P<remote_addr>[^ ]*) - (?P<remote_user>[^ ]*) \\"(?P<time_local>[^\]*)\\" \\"(?P<request>[^\]*)\\" (?P<status>[^ ]*) (?P<body_bytes_sent>[^ ]*) \\"(?P<http_referer>[^\]*)\\" \\"(?P<http_user_agent>[^\]*)\\" rt=\\"(?P<request_time>[^\]*)\\" uct=\\"(?P<upstream_connect_time>[^\]*)\\" uht=\\"(?P<upstream_header_time>[^\]*)\\" urt=\\"(?P<upstream_response_time>[^\]*)\\""$`): error parsing regexp: missing closing ]: `[^\]*)\\" \\"(?P<http_user_agent>[^\]*)\\" rt=\\"(?P<request_time>[^\]*)\\" uct=\\"(?P<upstream_connect_time>[^\]*)\\" uht=\\"(?P<upstream_header_time>[^\]*)\\" urt=\\"(?P<upstream_response_time>[^\]*)\\""$`
goroutine 8 [running]:
regexp.MustCompile(0xc420166180, 0x176, 0xc420037e38)
	/usr/local/go/src/regexp/regexp.go:240 +0x171
github.com/martin-helmich/prometheus-nginxlog-exporter/vendor/github.com/satyrius/gonx.NewParser(0x7ffec5480396, 0xec, 0xc420028708)
	/go/src/github.com/martin-helmich/prometheus-nginxlog-exporter/vendor/github.com/satyrius/gonx/parser.go:27 +0x19a
main.main.func2(0x7ffec54804a0, 0x5, 0xc42000e180, 0x1, 0x1, 0x7ffec5480396, 0xec, 0x0, 0x0, 0x0, ...)
	/go/src/github.com/martin-helmich/prometheus-nginxlog-exporter/main.go:174 +0x4d
created by main.main
	/go/src/github.com/martin-helmich/prometheus-nginxlog-exporter/main.go:173 +0x5db

Environment:

Exporter version: quay.io/martinhelmich/prometheus-nginxlog-exporter:latest (on 9/nov)
OS (e.g. from /etc/os-release): GKE(coreOS probably)
Others: As far as I can get the error is in "[^]* part of regex: https://regex101.com/r/YTSx9W/1

Cannot reproduce. In my tests, your log format is translated to the regular expression ^(?P<remote_addr>[^ ]*) - (?P<remote_user>[^ ]*) "(?P<time_local>[^"]*)" "(?P<request>[^"]*)" (?P<status>[^ ]*) (?P<body_bytes_sent>[^ ]*) "(?P<http_referer>[^"]*)" "(?P<http_user_agent>[^"]*)" rt="(?P<request_time>[^"]*)" uct="(?P<upstream_connect_time>[^"]*)" uht="(?P<upstream_header_time>[^"]*)" urt="(?P<upstream_response_time>[^"]*)", which works without issue.
Are you absolutely sure that you entered the command above in a POXIS-compliant shell (like bash or zsh)? From your error output, it looks like your command line passed the entire string (including surrounding quotes and quote escape characters) to the exporter, which is most likely the cause of this issue.
Closing for now. Feel free to reopen.


MultiZMW stitching, model structure inputs, log(0) fixes

Hi,
The code now allows multiple ZMWs in a HDF5 file to run inference and stitching. I will  switch my branch from master to dev-v0.1.0 after this to sync with you.

MultiZMW stitching: multiple zmws in HDF5. readids in hdf5 delinate
zmw/window boundaries for correct stitching. Many zmws can be sent
to GPU for inference with results stitched at end.

- model structure inputs: hardcoded values are now inputs. same
  create_model between training and inference. TODO: should hardcode
  values in python source files and import different models by name
  for continuity

- fixed log(0) in QV values. Softmax can get numeric 1.0 resulting in
  undefined QV.

Can one of the admins verify this patch?

allowlist

add to allowlist

@michaelbrownid this is an awesome change. would it be okay if we leave a couple of comments on this itself for suggested changes, or would you prefer we fork from this branch and make the changes we're thinking of and push separately?

Logistically, I'm good whatever is easiest to allow us both to be in sync.

@michaelbrownid I pushed some updates to your branch itself - logic is the same, just updated some variable names and refactored a bit.

add to allowlist

rerun tests

ok to test

rerun tests

rerun tests

rerun tests

rerun tests

add to allowlist


LDON: Lurk Data Object Notation

The Lurk Data Object Notation, or LDON (pronounced "Ladon"), is a content-addressable linked data format designed for zero knowledge contexts, such as the Lurk zkSNARK language.
LDON is a simple syntax over Lurk expressions, and is compatible with JSON and IPLD.
The primary distinction between LDON and Lurk proper is that LDON makes no assumptions about reserved symbols or reduction rules.
For example, the ldon expression (lambda (x) x) corresponds to the Lurk expression (lambda (x) x), but in Lurk this will evaluate to a function object, whereas ldon considers expressions to be static. Furthermore, ldon is agnostic to what is built on top of it. One could define a language with evaluation rules totally different from lurk, where functions are built out of expressions that look like the ldon expression (fun x => x).
LDON syntax is defined as follows:
pub enum Syn<F: LurkField> {
  // A field element: 1, 0xff
  Num(Pos, F)
  // A u64 integer: 1u64, 0xffu64
  U64(Pos, u64),
  // A hierarchical symbol: foo, foo.bar.baz
  Symbol(Pos, Vec<String>),
  // A hierarchical keyword: :lambda, :lurk:lambda
  Keyword(Pos, Vec<String>),
  // A string literal: "foobar", "foo\nbar"
  String(Pos, String),
  // A character literal: 'a', 'b', '\n'
  Char(Pos, char),bin
  // A cons-list of expressions, which can be terminated by nil: (1 2 3)
  // or can be terminated with the right-most expression (1, 2, 3)
  List(Pos, Vec<Syn<F>>, Option<Box<Syn<F>>>),
  // A map of expressions to expressions: { foo = 1, blue = true, 3 = 4 }
  Map(Pos, Vec<(Syn<F>, Syn<F>)>),
  // A contextual link or descriptor of some piece of foreign data:
  // [sha256 0xffff_ffff_ffff_ffff 0xffff_ffff_ffff_ffff 0xffff_ffff_ffff_ffff 0xffff_ffff_ffff_ffff]
  Link(Pos, Box<Syn<F>>, Vec<u64>),
}

This pull request implements ldon and lurk-ff subcrates which feature:

An improved LurkField trait, with built-in tagging, version and field information, as well as a representation-agnostic mechanism for reading/writing field elements.
Canonical poseidon hashing of ldon expressions using a separate ldon::store::Store
Serialization and deserialization of ldon expressions and stores to either Vec<F: LurkField> or Vec<u8> (this is intended to replace all current use of json and cbor)
Parsing and printing of ldon expressions via a nom parser combinator library, including positional errors, bare symbols with unicode escaping, content-addressed links, key-value pairs, etc.
Quickcheck property testing for all the above

This PR does not integrate these changes with the lurk-rs parent crate, since this will require some delicate surgery to switch over serialization from scalar_store.rs. Once this is merged, I will make a follow-up PR for this.

Superseded by #364 , @johnchandlerburnham feel free to reopen if relevant


Add RpcConnect component

This PR:

Adds Material UI dependency.
Adds and wires up the component for setting the RPC node url.

Note that skipLibCheck tsconfig flag was added since bringing in Material UI v5 results in many Typescript duplicate identifier errors.

I do wonder if just refreshing the page, and having the url as a query param would be the neatest solution

Sketch here #31

the title of the page is "Vite + React + ..." shall we change it to "NitroConnect" / "Nitro Explorer" or something?

fix here #30


Fixed positioning bug where MMPopLabel would not work for UIBarButtonIte...

Hi,
I did a change regarding the way the center position of the pop label is computed. Previously it did not work to show a pop label against a UIBarButtonItem if the latter was inside a navigation bar. With this change, the existing example is still working + if you add the pop label to 'self.navigationController.view' then you can get the pop label point at button item of the nav bar.
Kind regards.
Patrick

It actually fixed the issue for me. Thanks @pajai, Really appreciate the work.


Remove include

The log.h include in msf.c seems not needed and if so should be removed (making it somewhat easier to repurpose in xemu for instance)

Referring to https://github.com/xemu-project/xemu/issues/435#issuecomment-2226738051

Above applies to master branch

Perhaps the cue reader could be moved to a separate repo, and used here via a git submodule?

Sure, I'll be working towards a separate repo, shouldn't take too long

Perhaps the cue reader could be moved to a separate repo, and used here via a git submodule?

Code is up: https://github.com/allkern/cue

I guess one of your next commits in the cdrom_rewrite branch will make use of the extracted tiny cue repo?


JsonSerializerSetting for TypeNameHandling not working

Hi,
Been struggling to get my deserialization working - we are using polymorphism.
I get the following error:
Type is an interface or abstract class and cannot be instantiated
I tried to set the settings for refit, which should make it work - works for other examples:
http://stackoverflow.com/questions/5780888/casting-interfaces-for-deserialization-in-json-net
    `
    var JourneyClient = new HttpClient(messageHandler)
    {
         BaseAddress = uri
    };

       `
return RestService.For<IJourneyServiceClient>(JourneyClient, new RefitSettings
	{
		JsonSerializerSettings = new JsonSerializerSettings
		{
			TypeNameHandling = TypeNameHandling.Auto
		}
	});

Anything I'm missing? Please assist this is causing a massive deadlock in our teams development

Is this a Refit issue? Refit just uses Newtonsoft.Json, so if you can use that to deserialize your payload, you can use Refit too.

@Cheesebaron thank you for reply.
I assumed it was a refit issue because it didn't seem to change anything when setting the TypeNameHandling.
We found a possible side route to use - busy testing

Check below code
Rest.For(client, new RefitSettings
{
ContentSerializer = new JsonContentSerializer(
new JsonSerializerSettings
{
NullValueHandling = NullValueHandling.Ignore
}
)
});


GetDeveloperProductsAsync needs return type information

addressed by https://github.com/roblox-ts/types/pull/206


Cant take free look when i am taking a viehcle

when i active freelook option, cant look around when i am taking a viehcle

The vehicle camera system is different from the infantry camera. We currently have no plans to fix this.


r_sole and l_sole are not centered

#22 added the unit tests that checks if l_sole and r_sole are parallel.
It gives the following error:
l_sole_y is 0.07435, while r_sole_y is -0.07445 while they should be simmetric (diff : 0.0001 )

sole_height and sole_x seems fine instead
cc @salvi-mattia @traversaro @mfussi66 @pattacini @Mick3Lozzo

in cad model they r parallel

and they are parallel in the SW mechanism

where does this misalignement came from??

I tried to compute from code the same transform as:
    iDynTree::Transform l_sole_H_r_sole = comp.getRelativeTransform(l_sole,r_sole);
    std::cerr<<"l_sole - r_sole "<<l_sole_H_r_sole.getPosition().toString()<<std::endl;

And I got:
l_sole - r_sole -5e-05 -0.1488 0

That is the same as the cad.
Since we are computing the alignment of the frames using the two transforms root_link_H_r_sole and root_link_H_l_sole, maybe the root_link frame is not perfectly centered?
cc @fiorisi @traversaro @Mick3Lozzo @salvi-mattia

the two soles' CSYS are off center
@Mick3Lozzo is investigating

The problem is the placement of the upper body on the lower body, is merely a CAD assembling problem.

⬆Between the bright green supports of the torso pitch motor and the dark green plate housing the torso yay motor, there is a 0.1 mm gap in assembling the components without interference problems due to the tolerance chain.

⬆  This gap should be equally distributed between the joint's left and right sides of the joint but is all on one side.

⬆  This coincident should be offset 0.05 mm.
I have corrected the misalignment, and now the robot is fully symmetrical again ⬇.

We must correct some shrinkwrap, probably the root link and the other links directly constrained to it.
@fiorisi @traversaro @mfussi66  @salvi-mattia @Nicogene

We must correct some shrinkwraps, probably the root link and the other links directly constrained to it.
@fiorisi @traversaro @mfussi66 @salvi-mattia @Nicogene

Done, both in Creo 7 and in Creo 9 shrink-wraps, we can generate e new URDF @Nicogene.
cc @fiorisi @traversaro @mfussi66 @salvi-mattia

Resolved, and as a bonus, I resolved some other inconsistencies I found on the shoulders.

We can re-generate the URDF again (until the next bug).
@fiorisi @traversaro @mfussi66 @salvi-mattia @Nicogene


tool/train_siammask: val dataset in val_loader didn't use to evaluate model ?

I read train function in train_siammask then saw that have no evaluation step on val dataset. That's why mean_iou, iou_5, iou_7 are not displayed during training time. Can anyone explain for me?

i have too problem with IoU during train, and whan i train refine model, i have mask_loss = 0


Missing symbols when initializing LocalContent

In LocalContentStorageTransaction.Commit(), symbols was missing
when LocalContent is initialized.

It would be good to have a test for the case.

It would be good to have a test for the case.

@vasili-v , I'll do so shortly as a separate PR.
Thanks for the review.


Fixed RichTextLabel wrong selection offset after drop cap

Fixes an issue in RichTextLabel where starting a selection, or selecting across a drop cap, would incorrectly start the selection offset by the width of the drop cap.
I would recommend leaving in the comments, because this is where a future improvement would fix the issue of the drop cap text not currently being selectable, and figuring out how to obtain the drop cap text is not obvious.

I would recommend leaving in the comments, because this is where a future improvement would fix the issue of the drop cap text not currently being selectable, and figuring out how to obtain the drop cap text is not obvious.

If this code is not valid yet, then there is no point leaving it there. You can stash the changes and work on it after we merge this. So please strip these lines from the PR.

You need to squash your commits.

If this code is not valid yet, then there is no point leaving it there. You can stash the changes and work on it after we merge this. So please strip these lines from the PR.

Is there a mechanism somewhere for adding code comments like this one for the benefit of a different, future contributor? I'll have my own comments, but it could save someone else some effort?

Is there a mechanism somewhere for adding code comments like this one for the benefit of a different, future contributor? I'll have my own comments, but it could save someone else some effort?

You can comment your suggestion on an issue. If there is no issue, you can open one and leave a comment there. Code comments aren't discoverable and having dead code in the codebase is mostly just contributes to the noise.

Thanks!

Code comments aren't discoverable and having dead code in the codebase is mostly just contributes to the noise. And you also cannot guarantee that your solution is the correct one, so leaving it in the code would be misleading.

I agree with these good observations - thanks!


Support Optimized Write

Description

Support OptimizeWrite described in https://docs.databricks.com/delta/optimizations/auto-optimize.html#how-optimized-writes-work
Fixes #1158
If OptimizeWrite is enabled, inject OptimizeWriteExchangeExec on top of the write plan and remove ShuffleExchangeExec or CoalesceExchange operation at the top of the plan to avoid unnecessary shuffle / stage.
In OptimizeWriteExchangeExec,

Repartition data

RoundRobinPartitining for non partitioned data, HashPartitioning for partitioned data.
Use spark.sql.shuffle.partitions for partitioning. We can introduce a new config like spark.sql.adaptive.coalescePartitions.initialPartitionNum if needed.

Rebalance partitions for write

Step1 - merge small partitions (CoalescedPartitionSpec)
Step2 - split large partitions (PartialReducerPartitionSpec)
targetSize config: spark.databricks.delta.optimizeWrite.binSize (default: 128MB)

How to enable
Ref: https://docs.databricks.com/delta/optimizations/auto-optimize.html#enable-auto-optimize
We can enable OptimizeWrite using Spark session config or table property.

Spark session config

spark.databricks.delta.optimizeWrite.enabled = true
applied for write operations of all Delta tables)

Table property

delta.autoOptimize.optimizeWrite = true

Spark session config is prior to the table property.
How was this patch tested?

Unit tests (+ more tests will be added)
Does this PR introduce any user-facing changes?

Yes, support OptimizeWrite

Can you please fix the conflicts?

Gentle ping on this again, just started using this in our production environment and would be great not to have to maintain my own Delta fork 😅

Please let me know if someone is ready to review. I'll rebase the PR then.

any update on this PR?

Any update on this PR?.

Hi @tdas @scottsand-db  Any update? So no plan to deliver this feature to OSS delta?

I am using your PR for optimize write in my EMR streaming use cases.
I want that optimize write should create around 128m parquet files but it is topping at 64m.
Configuration I am using is as below
"spark.sql.catalog.spark_catalog": "org.apache.spark.sql.delta.catalog.DeltaCatalog",
"spark.databricks.delta.autoCompact.enabled": "true",
"spark.databricks.delta.optimizeWrite.enabled": "true",
"spark.databricks.delta.autoCompact.minNumFiles": "500",
"spark.sql.adaptive.enabled": "true",
"spark.sql.adaptive.coalescePartitions.enabled": "true",
"spark.sql.adaptive.advisoryPartitionSizeInBytes": "128m",
"spark.sql.adaptive.coalescePartitions.minPartitionNum": "1",
"spark.sql.adaptive.coalescePartitions.initialPartitionNum": "200",
"spark.databricks.delta.optimizeWrite.binSize": "134217728
2023-09-22 08:22:54 61.9 MiB part-00000-eb8c145c-7ac4-420c-8b85-c6fd58861e40.c000.snappy.parquet
2023-09-22 08:24:55 43.7 MiB part-00001-4fbd8215-5129-48aa-b858-d2ab9d2ca7a6.c000.snappy.parquet
2023-09-22 08:24:58 54.8 MiB part-00000-de4d1a37-543c-4c80-a2dd-9cbc06af7b3c.c000.snappy.parquet
2023-09-22 08:27:06 52.7 MiB part-00000-c6cf2c15-8dc3-4346-a03c-eb83171fdf46.c000.snappy.parquet
2023-09-22 08:27:06 59.3 MiB part-00001-a5f3db2e-e352-45b0-aa1b-bbf1570ebb6f.c000.snappy.parquet
2023-09-22 08:28:56 69.1 MiB part-00000-697cca77-e7ea-4267-9f7b-3fd406678b31.c000.snappy.parquet
2023-09-22 08:31:03 52.8 MiB part-00000-3dfbf27e-53f3-4f35-8955-7675d0ec86bf.c000.snappy.parquet
2023-09-22 08:31:05 60.5 MiB part-00001-6b7bc1d7-9882-4ba0-a01b-619a0a424ae4.c000.snappy.parquet
2023-09-22 08:32:58 32.5 MiB part-00001-ea4d882a-f182-48d4-a3e8-bc23260e617e.c000.snappy.parquet
2023-09-22 08:33:03 54.1 MiB part-00000-4c53bf10-eede-45c3-b178-f9d4f2895956.c000.snappy.parquet
2023-09-22 08:35:00 45.7 MiB part-00001-138bdaab-8d77-4faf-af49-489c4cfad4f6.c000.snappy.parquet
2023-09-22 08:35:01 51.7 MiB part-00000-62a2bdfa-9dea-41ff-9f8c-4e3ebcb12d04.c000.snappy.parquet
2023-09-22 11:42:10 52.0 MiB part-00000-64bccc7b-2664-4e67-b478-413a5a7554db.c000.snappy.parquet
2023-09-22 11:42:12 57.9 MiB part-00001-b79e83d9-c65e-438b-a555-aa2028320ea5.c000.snappy.parquet
2023-09-22 11:45:20 56.4 MiB part-00001-1ef411fb-160c-4cba-a5e7-cdee540295a5.c000.snappy.parquet
2023-09-22 11:45:20 57.0 MiB part-00004-fa51fd84-c4d3-4980-9a88-5566283d3234.c000.snappy.parquet
2023-09-22 11:45:20 57.5 MiB part-00005-80e03284-a8a6-4937-857c-1c434527c956.c000.snappy.parquet
2023-09-22 11:45:20 57.8 MiB part-00000-a347b170-d15f-4328-b402-ccdc099e94da.c000.snappy.parquet
2023-09-22 11:45:20 57.9 MiB part-00006-d566e257-f0cf-4cf9-b968-cad449784226.c000.snappy.parquet
2023-09-22 11:45:20 57.9 MiB part-00009-18a54bcf-3d53-4766-b485-62332266c974.c000.snappy.parquet
2023-09-22 11:45:20 58.5 MiB part-00003-8cf66203-9a32-41b5-a617-a3a9e9b2e465.c000.snappy.parquet
2023-09-22 11:45:21 38.7 MiB part-00010-1b8e65ae-b366-46fa-818e-d8ac95fd5904.c000.snappy.parquet
2023-09-22 11:45:22 57.1 MiB part-00007-05dc33ff-5125-435f-b0f1-f4215fba9d5b.c000.snappy.parquet
2023-09-22 11:45:22 58.9 MiB part-00008-5c99002a-1d7b-4db5-8c14-8e3f966773ec.c000.snappy.parquet
2023-09-22 11:45:23 57.6 MiB part-00002-6844ca06-b437-486f-b15b-ebf93fc0e740.c000.snappy.parquet
Any suggestions?

@adityakumar84 you can try to increase the binSize config. It's used for row format size in memory.
The result parquet size, we cannot control it precisely as it depends on data property / parquet compression ratio.
To make more accurate, we need to collect parquet compression ratio history from previous wrtie job... etc


Add type attribute support for JWT

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 84.80%. Comparing base (161d3ef) to head (e0daa2b).
Report is 6 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #46      +/-   ##
==========================================
+ Coverage   81.73%   84.80%   +3.07%
==========================================
  Files          17       17
  Lines        5332     5181     -151
==========================================
+ Hits         4358     4394      +36
+ Misses        974      787     -187

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Vundle plugins from my config isn't initializing

I've just build app from 1aa7f4126414d33810aa9499b8dce4e190e02f86 commit by README instructions and sourced my config by command: source ~/blablabla/init.vim. Config was applied but none of specified plugins by Plugin command were initialized.
$ uname -a
Linux fedorafarm25 4.10.10-200.fc25.x86_64 #1 SMP Thu Apr 13 01:11:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/fedora-release
Fedora release 25 (Twenty Five)

$ nvim --version
NVIM v0.2.0-dev
Build type: Debug
Compilation: /usr/bin/cc -Wconversion -DNVIM_MSGPACK_HAS_FLOAT32 -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/home/unclechu/.compile_n_build/neovim/neovim-v0.2.0-1338-g263849b/build/config -I/home/unclechu/.compile_n_build/neovim/neovim-v0.2.0-1338-g263849b/src -I/home/unclechu/.compile_n_build/neovim/neovim-v0.2.0-1338-g263849b/.deps/usr/include -I/home/unclechu/.compile_n_build/neovim/neovim-v0.2.0-1338-g263849b/.deps/usr/include -I/home/unclechu/.compile_n_build/neovim/neovim-v0.2.0-1338-g263849b/.deps/usr/include -I/home/unclechu/.compile_n_build/neovim/neovim-v0.2.0-1338-g263849b/.deps/usr/include -I/home/unclechu/.compile_n_build/neovim/neovim-v0.2.0-1338-g263849b/.deps/usr/include -I/home/unclechu/.compile_n_build/neovim/neovim-v0.2.0-1338-g263849b/.deps/usr/include -I/usr/include -I/home/unclechu/.compile_n_build/neovim/neovim-v0.2.0-1338-g263849b/build/src/nvim/auto -I/home/unclechu/.compile_n_build/neovim/neovim-v0.2.0-1338-g263849b/build/include
Compiled by unclechu@fedorafarm25

Optional features included (+) or not (-): +acl   +iconv    +jemalloc +tui
For differences from Vim, see :help vim-differences

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/home/unclechu/neovim-v0.2.0-1338-g263849b/share/nvim"

I can't execute for example NERDTree command or CtrlSpace, it gets me an error 'not an editor command'.

Have you tried setting "oni.loadInitVim" to true in ~/.oni/config.js (or preferences -> edit ONI config from the main menu) instead of sourcing?

@ohle this way it's working, thanks. I wonder why it doesn't work by sourcing?

I'm not really sure, but there are some subtle ways in which init.vim loading is special. Probably load order and the construction of the runtimepath has something to do with it.
I'd guess that if you start regular neovim with -u NONE to skip your init.vim and then :source it later, you'd run into the same problems.

@ohle you're right, it's true, I have the same situation with nvim TUI, so this isn't connected to the Oni. Thank you again for clarifying it for me, I'm closing this issue because it solved by setting oni.loadInitVim option to true.


Test cases render problem

Sorry to bother you
When I read this paper [RESTTESTGEN: Automated Black-Box Testing of RESTful APIs], I was a bit confused about the test case s generation module.
According to the paper, RestTestGen constructs an ODG graph based on the OpenAPI, and then test cases are generated according to the order of the ODG graph. I would like to know how test sequences are generated in RestTestGen by traversing the ODG graph. Specifically, is the test sequence generated by selecting an ODG node according to the dependency and then rendering the next node according to the ODG graph if the current node is successful？ Or construct a test sequence template by traversing the node order of the ODG graph and rendering them all for testing?

Hi.
Thank you very much for your reply, can I understand your answer this way: the test sequence is generated by first selecting the nodes in the ODG graph that match the dependencies and expanding them according to the dependencies. However, when this node does not receive a 200 response due to parameters or other reasons, the RTG will either tag these operations or add them to a collection for separate processing and re-render them in the test sequence as you have described. But I still have a question for you, when this node fails in the test sequence expansion phase, does it affect the subsequent expansion process? For example, in ODG, there is A->B, when operation B fails the test, will operation A not be tested? If it is convenient, can you tell me where in the project the test sequence generation and parameter filling is implemented. I think I will get a better understanding by reading the code.
Best,
PAG

All operations will be tested. If operations A fails the test, then we will store a variable testingAttempts = 1. Operation B has the same variable set to 0, so it will be eventually tested. To better understand the algorithm you might look at the ODG-based opertations sorter class: https://github.com/SeUniVr/RestTestGen/blob/main/src/main/java/io/resttestgen/implementation/operationssorter/GraphBasedOperationsSorter.java

Thanks a lot ! I will look the code

Hello.
I would like to add the following feature to RTG: when rendering the request sequence, first render the "required" parameters for testing and then render the other non-required parameters for testing. Which part of the code do I need to change?
Thank you very much!

Hello,
you will need to create a custom version of the NominalFuzzer.
In particular, at line 158 we set the value for all the mandatory parameters, plus the value of non mandatory parameters with a give probability. You can set that probability to 0.


Add bypass for exe.io step one

 NOTICE
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.

Fixes: #117

Presses the button for the first step, second step needs crowd bypass

[x] I made sure there are no unnecessary changes in the code*
[x] Tested on Chromium- Browser OS
[x] Tested on Firefox

* indicates required

not working

crowd bypass for exe.io / exey.io isn't working properly
aometimes it works, sometimes it doesn't

site has added this domain now
exey.app


Update ciris to 2.0.0

Updates is.cir:ciris from 2.0.0-RC3 to 2.0.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "is.cir", artifactId = "ciris" } ]

labels: library-update, semver-pre-release

Superseded by #686.


Adding service version

Added ECS service.version field support.
Refs: https://github.com/elastic/ecs-logging-java/issues/129

:grey_exclamation: Build Aborted

The PR is not allowed to run in the CI yet

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Build Cause: Pull request #132 opened

Reason: The PR is not allowed to run in the CI yet

Start Time: 2021-06-13T11:18:10.363+0000

Duration: 4 min 2 sec

Commit: 4189e802ef57854683d053f8b0bead9ba6e6f01a

Trends :test_tube:

Steps errors
Expand to view the steps failures

Load a resource file from a shared library

Took 0 min 0 sec . View more details on here
Description: approval-list/elastic/ecs-logging-java.yml

Error signal

Took 0 min 0 sec . View more details on here
Description: githubPrCheckApproved: The PR is not allowed to run in the CI yet. (Only users with write permissions can do so.)

Log output
Expand to view the last 100 lines of log output

[2021-06-13T11:18:29.766Z]  > git checkout -f 4189e802ef57854683d053f8b0bead9ba6e6f01a # timeout=15
[2021-06-13T11:18:29.778Z] Commit message: "adding service version"
[2021-06-13T11:18:29.779Z] First time build. Skipping changelog.
[2021-06-13T11:18:29.779Z] Cleaning workspace
[2021-06-13T11:18:29.779Z]  > git rev-parse --verify HEAD # timeout=10
[2021-06-13T11:18:29.784Z] Resetting working tree
[2021-06-13T11:18:29.784Z]  > git reset --hard # timeout=10
[2021-06-13T11:18:29.796Z]  > git clean -fdx # timeout=10
[2021-06-13T11:18:29.804Z]  > git --version # timeout=10
[2021-06-13T11:18:29.809Z]  > git --version # 'git version 2.17.1'
[2021-06-13T11:18:29.813Z] fatal: bad object db7712a735aca0ba4b034fda8ff92b345936f195
[2021-06-13T11:18:30.416Z] Masking supported pattern matches of $JOB_GCS_BUCKET or $NOTIFY_TO
[2021-06-13T11:18:30.482Z] Timeout set to expire in 1 hr 0 min
[2021-06-13T11:18:30.504Z] The timestamps step is unnecessary when timestamps are enabled for all Pipeline builds.
[2021-06-13T11:18:45.612Z] Still waiting to schedule task
[2021-06-13T11:18:45.613Z] ‘apm-ci-immutable-ubuntu-1804-1623352653617791229’ is offline
[2021-06-13T11:21:38.529Z] Running on apm-ci-immutable-ubuntu-1804-1623583110716739093 in /var/lib/jenkins/workspace/java_ecs-logging-java-mbp_PR-132
[2021-06-13T11:21:44.979Z] [INFO] 'shallow' is forced to be disabled when running on PullRequests
[2021-06-13T11:21:45.004Z] Running in /var/lib/jenkins/workspace/java_ecs-logging-java-mbp_PR-132/src/github.com/elastic/ecs-logging-java
[2021-06-13T11:21:45.045Z] [INFO] gitCheckout: Checkout SCM PR-132 with default customisation from the Item.
[2021-06-13T11:21:45.085Z] [INFO] Override default checkout
[2021-06-13T11:21:45.144Z] Sleeping for 10 sec
[2021-06-13T11:21:55.180Z] The recommended git tool is: NONE
[2021-06-13T11:21:57.381Z] using credential f6c7695a-671e-4f4f-a331-acdce44ff9ba
[2021-06-13T11:21:57.389Z] Wiping out workspace first.
[2021-06-13T11:21:57.403Z] Cloning the remote Git repository
[2021-06-13T11:21:57.403Z] Using shallow clone with depth 3
[2021-06-13T11:21:57.403Z] Avoid fetching tags
[2021-06-13T11:21:58.334Z] Cleaning workspace
[2021-06-13T11:21:58.356Z] Using shallow fetch with depth 3
[2021-06-13T11:21:58.356Z] Pruning obsolete local branches
[2021-06-13T11:21:57.431Z] Cloning repository git@github.com:elastic/ecs-logging-java.git
[2021-06-13T11:21:57.505Z]  > git init /var/lib/jenkins/workspace/java_ecs-logging-java-mbp_PR-132/src/github.com/elastic/ecs-logging-java # timeout=10
[2021-06-13T11:21:57.538Z] Fetching upstream changes from git@github.com:elastic/ecs-logging-java.git
[2021-06-13T11:21:57.538Z]  > git --version # timeout=10
[2021-06-13T11:21:57.547Z]  > git --version # 'git version 2.17.1'
[2021-06-13T11:21:57.548Z] using GIT_SSH to set credentials GitHub user @elasticmachine SSH key
[2021-06-13T11:21:57.572Z]  > git fetch --no-tags --progress -- git@github.com:elastic/ecs-logging-java.git +refs/heads/*:refs/remotes/origin/* # timeout=15
[2021-06-13T11:21:58.302Z]  > git config remote.origin.url git@github.com:elastic/ecs-logging-java.git # timeout=10
[2021-06-13T11:21:58.313Z]  > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
[2021-06-13T11:21:58.328Z]  > git config remote.origin.url git@github.com:elastic/ecs-logging-java.git # timeout=10
[2021-06-13T11:21:58.337Z]  > git rev-parse --verify HEAD # timeout=10
[2021-06-13T11:21:58.348Z] No valid HEAD. Skipping the resetting
[2021-06-13T11:21:58.348Z]  > git clean -fdx # timeout=10
[2021-06-13T11:21:58.361Z] Fetching upstream changes from git@github.com:elastic/ecs-logging-java.git
[2021-06-13T11:21:58.362Z] using GIT_SSH to set credentials GitHub user @elasticmachine SSH key
[2021-06-13T11:21:58.367Z]  > git fetch --no-tags --progress --prune -- git@github.com:elastic/ecs-logging-java.git +refs/pull/132/head:refs/remotes/origin/PR-132 +refs/heads/master:refs/remotes/origin/master # timeout=15
[2021-06-13T11:21:58.999Z] Merging remotes/origin/master commit b62f7415be3af6ed99a14c51ca2bd254fc3aaed1 into PR head commit 4189e802ef57854683d053f8b0bead9ba6e6f01a
[2021-06-13T11:21:59.076Z] Merge succeeded, producing 4189e802ef57854683d053f8b0bead9ba6e6f01a
[2021-06-13T11:21:59.077Z] Checking out Revision 4189e802ef57854683d053f8b0bead9ba6e6f01a (PR-132)
[2021-06-13T11:21:59.006Z]  > git config core.sparsecheckout # timeout=10
[2021-06-13T11:21:59.012Z]  > git checkout -f 4189e802ef57854683d053f8b0bead9ba6e6f01a # timeout=15
[2021-06-13T11:21:59.047Z]  > git remote # timeout=10
[2021-06-13T11:21:59.052Z]  > git config --get remote.origin.url # timeout=10
[2021-06-13T11:21:59.055Z] using GIT_SSH to set credentials GitHub user @elasticmachine SSH key
[2021-06-13T11:21:59.060Z]  > git merge b62f7415be3af6ed99a14c51ca2bd254fc3aaed1 # timeout=10
[2021-06-13T11:21:59.070Z]  > git rev-parse HEAD^{commit} # timeout=10
[2021-06-13T11:21:59.079Z]  > git config core.sparsecheckout # timeout=10
[2021-06-13T11:21:59.092Z]  > git checkout -f 4189e802ef57854683d053f8b0bead9ba6e6f01a # timeout=15
[2021-06-13T11:22:02.605Z] Commit message: "adding service version"
[2021-06-13T11:22:02.605Z] Cleaning workspace
[2021-06-13T11:22:02.682Z]  > git --version # timeout=10
[2021-06-13T11:22:02.693Z]  > git --version # 'git version 2.17.1'
[2021-06-13T11:22:02.709Z] fatal: bad object db7712a735aca0ba4b034fda8ff92b345936f195
[2021-06-13T11:22:02.607Z]  > git rev-parse --verify HEAD # timeout=10
[2021-06-13T11:22:02.622Z] Resetting working tree
[2021-06-13T11:22:02.622Z]  > git reset --hard # timeout=10
[2021-06-13T11:22:02.641Z]  > git clean -fdx # timeout=10
[2021-06-13T11:22:03.864Z] Masking supported pattern matches of $GIT_USERNAME or $GIT_PASSWORD
[2021-06-13T11:22:04.506Z] + git fetch<EMAIL_ADDRESS>+refs/pull/*/head:refs/remotes/origin/pr/*
[2021-06-13T11:22:04.848Z] Running in /var/lib/jenkins/workspace/java_ecs-logging-java-mbp_PR-132/src/github.com/elastic/ecs-logging-java/.git
[2021-06-13T11:22:04.957Z] Archiving artifacts
[2021-06-13T11:22:05.636Z] + git rev-parse HEAD
[2021-06-13T11:22:05.985Z] + git rev-parse HEAD
[2021-06-13T11:22:06.300Z] + git rev-parse origin/pr/132
[2021-06-13T11:22:06.347Z] [INFO] githubEnv: Found Git Build Cause: pr
[2021-06-13T11:22:06.777Z] Masking supported pattern matches of $GITHUB_TOKEN
[2021-06-13T11:22:07.859Z] [WARN] githubApiCall: The REST API call https://api.github.com/repos/elastic/ecs-logging-java/pulls/132/reviews return 0 elements
[2021-06-13T11:22:07.918Z] [INFO] githubPrCheckApproved: Title: Adding service version - User: szisiu - Author Association: FIRST_TIME_CONTRIBUTOR
[2021-06-13T11:22:08.246Z] ERROR: githubPrCheckApproved: The PR is not allowed to run in the CI yet
[2021-06-13T11:22:08.246Z] ERROR: githubPrCheckApproved: The PR is not allowed to run in the CI yet. (Only users with write permissions can do so.)
[2021-06-13T11:22:08.323Z] [INFO] Let's stop build #1. The PR is not allowed to run in the CI yet
[2021-06-13T11:22:08.350Z] Sleeping for 5 sec
[2021-06-13T11:22:09.307Z] Stage "Build" skipped due to earlier failure(s)
[2021-06-13T11:22:09.515Z] Stage "Tests" skipped due to earlier failure(s)
[2021-06-13T11:22:09.648Z] Stage "Unit Tests" skipped due to earlier failure(s)
[2021-06-13T11:22:09.661Z] Stage "Javadoc" skipped due to earlier failure(s)
[2021-06-13T11:22:09.674Z] Stage "Sanity checks" skipped due to earlier failure(s)
[2021-06-13T11:22:09.777Z] Failed in branch Unit Tests
[2021-06-13T11:22:09.786Z] Failed in branch Javadoc
[2021-06-13T11:22:09.795Z] Failed in branch Sanity checks
[2021-06-13T11:22:11.101Z] Running on worker-1095690 in /var/lib/jenkins/workspace/java_ecs-logging-java-mbp_PR-132
[2021-06-13T11:22:11.340Z] [INFO] getVaultSecret: Getting secrets
[2021-06-13T11:22:11.393Z] Masking supported pattern matches of $VAULT_ADDR or $VAULT_ROLE_ID or $VAULT_SECRET_ID
[2021-06-13T11:22:14.155Z] + chmod 755 generate-build-data.sh
[2021-06-13T11:22:14.155Z] + ./generate-build-data.sh https://apm-ci.elastic.co/blue/rest/organizations/jenkins/pipelines/apm-agent-java/ecs-logging-java-mbp/PR-132/ https://apm-ci.elastic.co/blue/rest/organizations/jenkins/pipelines/apm-agent-java/ecs-logging-java-mbp/PR-132/runs/1 ABORTED 241675
[2021-06-13T11:22:14.155Z] INFO: curl https://apm-ci.elastic.co/blue/rest/organizations/jenkins/pipelines/apm-agent-java/ecs-logging-java-mbp/PR-132/runs/1/steps/?limit=10000 -o steps-info.json
[2021-06-13T11:22:14.155Z] INFO: curl https://apm-ci.elastic.co/blue/rest/organizations/jenkins/pipelines/apm-agent-java/ecs-logging-java-mbp/PR-132/runs/1/tests/?status=FAILED -o tests-errors.json
[2021-06-13T11:22:14.855Z] Retry 1/3 exited 22, retrying in 1 seconds...
[2021-06-13T11:22:16.304Z] Retry 2/3 exited 22, retrying in 2 seconds...

@szisiu Thanks for your input and proposed PR!
We try to be very selective on what we choose as a primary ecs-logging configuration, and so far we did not identify service.version as such. The rationale is that any field for which we don't expose a dedicated config can be set through the additionalField config (or KeyValuePair in log4j2).
Did you try that? Any reason this won't be good enough for this purpose?

@szisiu Thanks for your input and proposed PR!
We try to be very selective on what we choose as a primary ecs-logging configuration, and so far we did not identify service.version as such. The rationale is that any field for which we don't expose a dedicated config can be set through the additionalField config (or KeyValuePair in log4j2).
Did you try that? Any reason this won't be good enough for this purpose?

Hi, @eyalkoren. I thought that it could be a good and convenient addition. I tried and still using now the additionalFields. It works too.
The final decision is yours, guys.

@eyalkoren Now that the Java agent integrated elastic/apm-agent-java#1726, elastic/apm-agent-java#1922 and elastic/apm-agent-java#2434 I think it makes sense to expose service.version as dedicated field. The agent can then automatically set the (auto discovered or explicitly set) service.version when using ECS reformatting or instrumenting the library (see elastic/apm-agent-java#1626).

@tobiasstadler I agree!
Do you have the capacity to bring this to be ready for review?
If not, we can prioritize this when we get the chance.

I will have a look.

@szisiu Could please sign the CLA? See https://github.com/elastic/ecs-logging-java/pull/132#issuecomment-860194104. Unfortunately, we can't move forward with this PR, otherwise.

@szisiu Could please sign the CLA? See #132 (comment). Unfortunately, we can't move forward with this PR, otherwise.

Hi @felixbarny, it will be hard at this moment.
What about pushing the code provided by @tobiasstadler in https://github.com/elastic/ecs-logging-java/pull/168?

Closing in favor of https://github.com/elastic/ecs-logging-java/pull/168


Links in REST API docs don't work

These anchors don't work:
https://mesosphere.github.io/marathon/docs/rest-api.html#post-/v2/groups
I'm not sure if this is fixable but if not, they should just be removed, so that it's not confusing.

There is a discrepancy between the expected anchor tag ID value and the actual IDs.
Example:
The first link expects the target ID to be #post-/v2/apps but the id of the section is actually id="post-v2-apps".
I

@pierlo-upitup I am currently updating this docs. If possible look (and potentially merge) https://github.com/mesosphere/marathon/pull/1857 first.

@kolloch As far as I can see you didn't touch the first 50 lines or so – we should be good.

Great, thanks!
On Thu, Jul 23, 2015 at 3:27 AM, Peter Kolloch<EMAIL_ADDRESS>wrote:

Closed #1859 https://github.com/mesosphere/marathon/issues/1859 via
#1860 https://github.com/mesosphere/marathon/pull/1860.
—
Reply to this email directly or view it on GitHub
https://github.com/mesosphere/marathon/issues/1859#event-363252489.


Publish typechain-types and deployment contract addressess to npm

From Discord discussion:
"It'd be a nice to have, since this code might not change too much, but since it will go through an audit phase anyway, would just need to republish and update the version in the frontend. it would also reduce some of the hardcoded typechain stuff"
https://discord.com/channels/839548879216181309/958758626003148830/1034141683329290250

https://www.npmjs.com/package/@fractal-framework/fractal-contracts


Create a new Release

Can you create a new release of this package?
Since there were for a longer time no new changes were added and there are changes in the master branch that are not in the latest release it would be really helpfull if you create a new release.

@bwaidelich


feat: Ignore Catalog Cache

closes #6919

Adds no_catalog_cache to config extras, so that a single plugin can be run every time without the catalog cache.
Adds --catalog-refresh option to meltano select and meltano el

Adding a new extra seems extreme, but I don't know how else to implement this where it could be used as part of a job for any tap. If there's a better way to do it, I'm happy to adjust this based on feedback.

Adding a new extra seems extreme, but I don't know how else to implement this where it could be used as part of a job for any tap. If there's a better way to do it, I'm happy to adjust this based on feedback.

The new extra is probably fine, and it's a nice way for users to tell Meltano to always use a fresh catalog.

@andyoneal I think files in https://github.com/meltano/meltano/tree/42405debc9369235c64c2f5a0ad8fbd9a1e61a35/integration/meltano-manifest/expected-manifests need to be updated so the integration tests can pass

@andyoneal I think files in https://github.com/meltano/meltano/tree/42405debc9369235c64c2f5a0ad8fbd9a1e61a35/integration/meltano-manifest/expected-manifests need to be updated so the integration tests can pass

was wondering where those were coming from. will update.

@andyoneal Are you interested in getting this PR across the finish line? Unfortunately I can't push to your main branches so I can't make the last-mile changes to this PR.

Closing in favor of #8580


Include build demo-app

After this, it could be run from the root project.
AGP versions used by demo-app and the root project should be kept the same.
includeBuild phrases should be placed in pluginManagement block.

@Goooler Thanks for the pull request. Would it be possible now to specify the Reveal dependencies in demo-app via project references and not use the artifacts from Maven Central?

We have to move demo-app out as a normal subproject instead of a standalone root project, or there will be a circular dependency issue in reverse.

In commit afe6b08ec7052ac4f30bf8e98b0be56a807d6899 I moved the demo app to a separate project. It was a subproject before. There was some reason why I did it but I don't remember. Maybe it was a build issue because of Kotlin Multiplatform, maybe it had something to do with the publication of the library. I don't know.

Or we can let demo-app include build reveal-root, shared module now depends on core and shapes.

Or we can let demo-app include build reveal-root, shared module now depends on core and shapes.

I think I like that better. But instead of the substitutes, couldn't we directly use project(":reveal:core") etc?

I'm not sure how to depend on composite build subproject instead of module notation.


[ABW-2387] Fix bug where a failing TX was never removed from request queue

Jira Ticket ABW-2387
Description
We missed handling addressReservationValue

What is the point of an empty function mustNotHaveAssociatedValue?


Fix 'linux' and specific BSD feature tags

After #76540, GDExtension's that have libraries like this are broken:
linux.debug.x86_64 = "res://bin/libexample.so"

... you now have to change that to:
linuxbsd.debug.x86_64 = "res://bin/libexample.so"

This also affects project settings that used the ".linux" suffix - those would also need to update to ".linuxbsd".
This PR makes the 'linux' feature tag work on Linux again, and it should also allow specific BSD tags (ex. freebsd, netbsd, etc) which were previously supported as well, but I don't personally have a way to test those.

Bugsquad edit: This closes https://github.com/godotengine/godot/issues/76990.

Thanks!


Dropping in and out of standard console

Hey,
Just wondering if there's a simple method of dropping out of a Frame back to the console, showing what ever's been printf-ed to there, and then returning back to the Frame.
The reason I ask is I've built an interface to some test software and what I'd like to happen is:

Use navigates to correct test
User presses test button
Asciimatic application drops back to console as test software runs
Any printf statements sent to stdout in the test software are seen in console
Software returns back to the Asciimatics application

Thanks for your time,
Colin

In theory this is possible, but might be a little messy...
The safest option is to stop asciimatics, close your Screen while the test is running and then open a new one after it has finished.  However, that means you need to reconstruct where you were before you closed the Screen.  You could re-use the resize infrastructure inside asciimatics to handle that - i.e. save your current Scene and use that as the start_scene when you re-open.
The other options get quite fragile after that...  Assuming you're running on Linux (or another curses system), you could just stop the Screen from playing temporarily - e.g. raise a StopApplication exception - and then use curses directly to switch between the normal and alternate screens, using the smcup and rmcup terminfo strings.  See http://invisible-island.net/xterm/xterm.faq.html#xterm_tite for some background on what they mean.
If you're in Windows, then you need to remember the current screen buffer and console input, restore the original screen buffer and console input that asciimatics stored away on start-up, and reset them as needed afterwards.
These latter 2 options use varying amounts of the internals of asciimatics, though, which will likely break in the future.
The other option that springs to mind is to prevent the need for dropping out at all.  You could instead pipe stdout to your asciimatics app, save it off in a widget and then display that instead.

That was a quick reply, thanks!
I've got a mock-up for your latter suggestion, where everything gets thrown at a widget. The problem I'm having though is the version of asciimatics I've pipped is 1.7.2 and doesn't have the force_update signal I've seen you mention in other answers. When the test code was off running and generating data the TUI was sitting static.
I'm going to have a go of closing the screen and bringing everything back up once complete. I've completely abstracted my data from my view so at least that wont be too messy.
Cant I just double check something before I create too much of a mess:
My application is started as follows:
def start_app():
    # Build the test runner app
    devices = DeviceModel()
    last_scene = None

    while True:
        try:
            Screen.wrapper(testrunner,
                           catch_interrupt=True,
                           arguments=[last_scene, devices])
            sys.exit(0)
        except ResizeScreenError as e:
            last_scene = e.scene

I'm closing my screen and getting to the console by using self._screen.close()
Where self._screen is created during the instantiation of my Frame
Now, once I've executed my code at console and I want to return to the application running start_app() from anywhere works, but I'm worried this is leaving two copies of the Screen running somewhere. I hope this make sense. I unfortunately cannot post the full app here as it's for work.

Yeah - that's a good concern.  You can't do this inside the widget as you will have conflicting Screen instances.  Instead you need to drop out to tat start_app main loop to handle it.
On the other hand, if you've already got working code that just needs the force_update patch, you could build a new distribution from the current code. Simply clone the current master branch and run python setup.py sdist from the respository root directory to get your own personal source distribution.

Magic. I'll have at both options tomorrow when I'm back behind the desk.
Although uglier I think dropping in and out of console will be the best
method as it means my test code with be agnostic to the platform running it.
Although having everything piped in and out of the TUI will look
significantly cooler.
Thanks again for your time, it was much appreciated.
On 31 Jan 2017 5:22 p.m., "peterbrittain"<EMAIL_ADDRESS>wrote:
Yeah - that's a good concern. You can't do this inside the widget as you
will have conflicting Screen instances. Instead you need to drop out to tat
start_app main loop to handle it.
On the other hand, if you've already got working code that just needs the
force_update patch, you could build a new distribution from the current
code. Simply clone the current master branch and run python setup.py sdist
from the respository root directory to get your own personal source
distribution.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/peterbrittain/asciimatics/issues/62#issuecomment-276430427,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABw0BQtVpEcuW-Yh2OM4SthnPcWFYPgFks5rX23igaJpZM4Ly2Tb
.

Good stuff.  I'll close this issue now.  Feel free to re-post here, though...

Just a little update in case anyone else is looking for a similar answer.
My code to exit to console belongs in a Frame which looks like:
class TestRunnerView(Frame):
    def __init__(self, screen, model):
        super(TestRunnerView, self).__init__(
                                        screen,
                                        screen.height * 4 // 5,
                                        screen.width * 4 // 5,
                                        hover_focus=True,
                                        has_shadow = True,
                                        title="Running Test Scheme")

        # Setup the screen
        self._model = model
        self._screen = screen
        self.fix()

    def reset(self):
        # Do standard reset to clear out form, then populate with new data.
        super(TestRunnerView, self).reset()
        self._start()

    def _start(self):
        dut = self._model.get_current_device();
        self._screen.close()
        print("Starting...")
        self.runTestSchemeFromPartNumber(dut["serial_number"])
        raise(RestartApp("Finished running tests... Restarting application"))

Where RestartApp is a custom exception:
class RestartApp(Exception):
    pass

This is caught by the app runner which builds the application:
def start_app():
    devices = DeviceModel()
    last_scene = None

    while True:
        try:
            Screen.wrapper(testrunner,
                           catch_interrupt=True,
                           arguments=[last_scene, devices])
            sys.exit(0)
        except ResizeScreenError as e:
            last_scene = e.scene
        except RestartApp as r:
            print(r)

I could make an exception like the ResizeScreenError which passes which Scene to jump into but for now I'm quite happy with the app returning to its starting point.
Cheers again for your help @peterbrittain :trophy: