Add TQ as a TSV

Coming out of the spike #360
This will require different display columns than the TSV for TNs.
The goal is to show the MD for the questions using the data in the TSV to index the questions according to the verse.

MD should be displayed the way TN displays but only display default column that are not empty.
The
 to separate the question and answer should be separate lines with whitespace between them.

It will necessary to work with @RobH123 on learning the new TSV format.

@ancientTexts-net most fields should be hidden by default.

@ancientTexts-net most fields should be hidden by default.

Working branches for new TSV format are always named "newFormat".
Here is the manifest entry for Titus:

-
--
  | title: 'Titus'
  | versification: 'ufw'
  | identifier: 'tit'
  | sort: 56
  | path: './TIT_tq.tsv'
  | categories: [ 'bible-nt' ]

Link to Titus: https://qa.door43.org/unfoldingWord/en_tq/src/branch/newFormat/TIT_tq.tsv

Working branches for new TSV format are always named "newFormat".
Here is the manifest entry for Titus:

-
--
  | title: 'Titus'
  | versification: 'ufw'
  | identifier: 'tit'
  | sort: 56
  | path: './TIT_tq.tsv'
  | categories: [ 'bible-nt' ]

Link to Titus: https://qa.door43.org/unfoldingWord/en_tq/src/branch/newFormat/TIT_tq.tsv

Here is an example of the annotation:
What position and responsibility does an overseer have in God’s household?\n\n> He is like God’s household manager.

Here is what it should look like in preview mode:
What position and responsibility does an overseer have in God’s household?

He is like God’s household manager.

Here is an example of the annotation:
What position and responsibility does an overseer have in God’s household?\n\n> He is like God’s household manager.

Here is what it should look like in preview mode:
What position and responsibility does an overseer have in God’s household?

He is like God’s household manager.

@BincyJ @birchamp I have expanded on the requirements and have tagged others for confirmation for parts of it.
The TQ TSV format only uses three columns:

Reference
ID
Annotation
(@RobH123 -- true?)

So in tc-create, only three columns should be available. Alternatively, if they are available, then it should be an error for them to have content. (@RobH123 -- true?)
The annotation columns is a specialized form of Markdown. The differences and conventions are:

The question and answer are in the same Markdown.
The question is followed by 5 characters \n\n>. The first two characters \n indicate a newline that ends the question. The second two characters \n indicates a blank line that should separate the question and answer. The fifth character indicates the beginning of a Markdown block quote.
The above string must be pre-processed for preview:

The question and answer must be separated by a blank line
The answer must be treated as an HTML block quote (indented lines of text with a left vertical bar)

Possible Issues

The bi-directional translation between HTML and Markdown must be updated to change \n to/from
. (@ancientTexts-net -- FYI)
The blockquote visual aid (vertical bar) does not work in currently. It only indents. (@birchamp is this a problem?)
The answer must be written in Markdown mode since there is no way to indicate a block quote in the HTML preview mode. (@birchamp @BincyJ -- this sort of goes against user preference for editing in HTML mode)
Does the CV package handle tQ TSV? And if so, does it generate a notice if columns Tags, SupportReference, Quote, or Occurrence have content? (@RobH123 -- need your input)

@BincyJ @birchamp I have expanded on the requirements and have tagged others for confirmation for parts of it.
The TQ TSV format only uses three columns:

Reference
ID
Annotation
(@RobH123 -- true?)

So in tc-create, only three columns should be available. Alternatively, if they are available, then it should be an error for them to have content. (@RobH123 -- true?)
The annotation columns is a specialized form of Markdown. The differences and conventions are:

The question and answer are in the same Markdown.
The question is followed by 5 characters \n\n>. The first two characters \n indicate a newline that ends the question. The second two characters \n indicates a blank line that should separate the question and answer. The fifth character indicates the beginning of a Markdown block quote.
The above string must be pre-processed for preview:

The question and answer must be separated by a blank line
The answer must be treated as an HTML block quote (indented lines of text with a left vertical bar)

Possible Issues

The bi-directional translation between HTML and Markdown must be updated to change \n to/from
. (@ancientTexts-net -- FYI)
The blockquote visual aid (vertical bar) does not work in currently. It only indents. (@birchamp is this a problem?)
The answer must be written in Markdown mode since there is no way to indicate a block quote in the HTML preview mode. (@birchamp @BincyJ -- this sort of goes against user preference for editing in HTML mode)
Does the CV package handle tQ TSV? And if so, does it generate a notice if columns Tags, SupportReference, Quote, or Occurrence have content? (@RobH123 -- need your input)

Ideally the \n should be converted to a newline in the new TSV reading function. See https://en.wikipedia.org/wiki/Tab-separated_values#Conventions_for_lossless_conversion_to_TSV
(Putting in  or whatever ideally is part of md -> HTML conversion.)

Ideally the \n should be converted to a newline in the new TSV reading function. See https://en.wikipedia.org/wiki/Tab-separated_values#Conventions_for_lossless_conversion_to_TSV
(Putting in  or whatever ideally is part of md -> HTML conversion.)

I would suggest something in a log @mandolyte if there's something in an unexpected column and then ignore it. It shouldn't happen (with present data), however, we don't want it to fail if someone puts something in there. (Remember there's lots of ways for humans to edit / mess-up files.)
But in general, I think most of your assumptions above are correct.

I would suggest something in a log @mandolyte if there's something in an unexpected column and then ignore it. It shouldn't happen (with present data), however, we don't want it to fail if someone puts something in there. (Remember there's lots of ways for humans to edit / mess-up files.)
But in general, I think most of your assumptions above are correct.

@birchamp @RobH123 Quick question... currently the new TSV format for tQ files is not saved in master branch. They are in a branch named "newFormat". My question is whether I can assume that the new format branch will be merged into master and that is where tc-create should look for them.

@birchamp @RobH123 Quick question... currently the new TSV format for tQ files is not saved in master branch. They are in a branch named "newFormat". My question is whether I can assume that the new format branch will be merged into master and that is where tc-create should look for them.

@klappy Wondered if you have any advice on the following findings...
Whereas I have the 7 column TSV version for tQ working, I have not been successful in making the round trip from file -> to md in the datatable -> to html ->  (some edits) -> to md -> saved file.
I have found a number of places that all seem to impact the md from/to html (and perhaps back to DCS?). They are:

datatable-translatable has input and output filters
markdown-translatable has entire TS package markdown-converter.ts that has a slew of functions and filters (I even found one that ostensibly is doing the same thing I had down with filters to remove zero-width-spaces from beginning and end of the cell value)

My last iteration today found that what is saved in DCS is NOT what I see in the raw markdown. So evidently there is some other interference going on - which led me to the markdown converter package. I'm guessing that what I tried to do in the datatable filters is being altered.
Is there a good reason to make changes in both places? Should I stick with the markdown converter package?
My plan for tomorrow is to study the markdown converter package.
@birchamp @ancientTexts-net

@klappy Wondered if you have any advice on the following findings...
Whereas I have the 7 column TSV version for tQ working, I have not been successful in making the round trip from file -> to md in the datatable -> to html ->  (some edits) -> to md -> saved file.
I have found a number of places that all seem to impact the md from/to html (and perhaps back to DCS?). They are:

datatable-translatable has input and output filters
markdown-translatable has entire TS package markdown-converter.ts that has a slew of functions and filters (I even found one that ostensibly is doing the same thing I had down with filters to remove zero-width-spaces from beginning and end of the cell value)

My last iteration today found that what is saved in DCS is NOT what I see in the raw markdown. So evidently there is some other interference going on - which led me to the markdown converter package. I'm guessing that what I tried to do in the datatable filters is being altered.
Is there a good reason to make changes in both places? Should I stick with the markdown converter package?
My plan for tomorrow is to study the markdown converter package.
@birchamp @ancientTexts-net

Ideally we need to identify the proper separation of concerns. Where should the filter exist? Is it something that the UI cares about? Or is it something that the outer layers interacting with reading and saving the file should deal with? What tests can we create and at what point is it valuable for us to know that this is handled? When we write the tests that fail, then we can ensure it is handled properly.

Ideally we need to identify the proper separation of concerns. Where should the filter exist? Is it something that the UI cares about? Or is it something that the outer layers interacting with reading and saving the file should deal with? What tests can we create and at what point is it valuable for us to know that this is handled? When we write the tests that fail, then we can ensure it is handled properly.

:-) I'll take that as encouragement to study how that part of the code actually works. So far, I've just been guessing, testing, and failing.
For posterity, my notes will be here

:-) I'll take that as encouragement to study how that part of the code actually works. So far, I've just been guessing, testing, and failing.
For posterity, my notes will be here

@birchamp So I had some thoughts about https://github.com/unfoldingWord/tc-create-app/issues/621 while trudging thru the code... Perhaps that would be a nice research project for the create 2.0 team. Some ideas:

Is only active, one instance at a time. Why? this gets around the problem noted before that you will run out of memory quickly if hundreds of instances are running.
The above implies that the user would have indicate intent to edit, say via the standard "pencil" icon or an on blur event.
Research how to replicate how section alignment can be done (or perhaps evaluate whether needed).

@birchamp So I had some thoughts about https://github.com/unfoldingWord/tc-create-app/issues/621 while trudging thru the code... Perhaps that would be a nice research project for the create 2.0 team. Some ideas:

Is only active, one instance at a time. Why? this gets around the problem noted before that you will run out of memory quickly if hundreds of instances are running.
The above implies that the user would have indicate intent to edit, say via the standard "pencil" icon or an on blur event.
Research how to replicate how section alignment can be done (or perhaps evaluate whether needed).

This issue can be unblocked now. The next few posts here will be to document what the new spec requires us to implement.
The new spec is here

This post has the general requirements that govern all TSV formats

[ ] The new TSV repos will include the OBS material. They will be treated like another bible book with the id "OBS".
[ ] The filenames in the repos will be of the form BBB_xx.tsv, where 'BBB' is the book id (including OBS) and xx is the two letter abbreviation of the resource type.
[ ] The resource abbreviations are: tn, tq, sn, sq, and twl.
[ ] The repos will be named by language id and resource id. For example, en_tn, en_tq, en_sn, en_sq, and en_twl
[ ] Note that the files will be listed in DCS in alphabetical order, since the numeric prefix for biblical order is no longer used.
[ ] The TSV spec we will be implementing is described here. And is defined here
[ ] The above spec requires that each line have the same number of tabs. Should we consider re-laxing this requirement?
[ ] While not part of the IANA spec, there are several generally accepted escape sequences which we will support. These are: \n, \t, \r, and \\

For TQ and SQ:
These TSV files have FIVE columns: Reference, ID, Tags, Question, Response.
Since these are identical, one set of changes will work for both.

These changes cannot be deployed into production until:

Production cuts over to the new format. Since these two resource types are fairly stable, this can be done independently, but it must be done first.
(optional) The changes to the content validator to support the new formats is ready. NOTE: at this writing, on Translation Notes have a validation function; thus tc-create can move forward.

On a related note, since we do use CV on TN resources and they will also have a new TSV format, then that deployment will need to be coordinated.

This is also waiting for the MD-TSV Converter to add TQ.

@RobH123 TQ has been published in TSV now, correct?

@RobH123 Can you publish TQ as TSV as long as the back converter is ready?

Yip, TQ and OBS-TQ TSV7 are now published into CatalogNext.

@birchamp please close this issue. This is working in v1.2. Since the code switches based on filename patterns both TQ as markdown and TQ as TSV are supported at the same time.

Not seeing the Question column in TSV in  1.3 branch. @mandolyte

Wrote up #1042 as a separate issue for column selection persistence.

@mandolyte From your notes/comments above "For TQ and SQ:
These TSV files have FIVE columns: Reference, ID, Tags, Question, Response.
"
I am seeing Two extra columns (making it 7 column TSV)- Quote and Occurrence  in TQs

Is that correct?

@mandolyte Another problem I found is that markdown display ( upon Preview mode toggle ) is not working for the Question/Response columns.
"MD should be displayed the way TN displays but only display default column that are not empty."

@elsylambert  On the number of columns... that comment was made back in February and things have changed. If you check the actual repo here  you will see these have 7 columns. Not sure why, since the empty columns remain unused as far as I seen. But perhaps the content team has plans for them???

@mandolyte  Yes I saw the 7 column TQ in the repo and was confirming if that was right. Thanks for confirming.

translationCore Create - v1.4.0-rc.3 build 104-85b41fb.. Looks good. Tested with 7 column TSVs.


Discover configured devices

Hello.
Im in the process of looking at the module with a view to implementing discovery of devices on the network.
After looking through the code, I realised that the hard work had already been done, in that it can send discovery requests, and receive the responses.
At the moment the majority of the code is structured under the S20 object, which requires the host details to initialise.  I thought I would open this ticket to discuss breaking some of this out, and restructuring it to make it possible to implement discover as a standalone feature.
Does anyone have any thoughts on this ?

That's the reason I didn't initially add discovery.
I think it may be worthwhile to have an S20Manager object that would handle the following:

Discovery
UDP Socket

This change would move the send/receive functions into the manager, and all S20 objects would share the same manager/socket with a command queue. (which should fix some issues that manifest when you have multiple sockets being controlled at the same time). It would also be a convenient place to do discovery.
The downside is a bit more complexity when using this module.

Thats along the lines of my initial thoughts.
Do you think the S20Manager should decode the messages to retrieve the host and then hand it off the the relevant S20 object, or should it decode the messages and call the relevant method on the registered S20 object to deal with that type of event ?

Thank for your help. For ORVIBO ALLONE R1U? I am interesting a control total with Python.

I don't feel strongly a particular way with respect to which class should handle message decode. Intuitively, I'd think that S20Manager would handle decode, since it has to handle at least some decode already, specifically the discovery messages.

I plan to implement the manager shortly, to make progress on some outstanding issues.

I added discover. It returns a set of host addresses.

I'm using orvibo switch with homeassistant.
I made a fork and commited some changes.
Please review.
https://github.com/seoyoungjin/python-orvibo
Thanks.

some info added to discover()
mac argumemt is added to S20.S20() not to call too many DISCOVERY msg

I took a look at your commits - nice changes. Can you do a pull request? Then we can merge the commits.

I created new pull request but I don't know this is right because I'm not good at git. :-)
Anyway I'm writing more code.

get detail device information i.e. device name
some test code simillar with https://github.com/fernadosilva/orvfms

Merged your PR, thanks!


[3pts] Create a navigation panel (Student B)

In the navigation panel, the user can see links to:

Motorcycles/doctors/classes/items that you selected as a theme.
"Reserve" form.
"My reservations".
"Add motorcycle/doctor/class/item that you selected as a theme" (the link is visible to everybody).
"Delete motorcycle/doctor/class/item that you selected as a theme" (the link is visible to everybody).

Here you will find the link to the PR.


PHP Fatal Error — Yiisoft\ErrorHandler\Exception\ErrorException Class App\Widget\FlashMessage contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Yiisoft\Widget\Widget::render)

What steps will reproduce the problem?  Installing demo.
What is the expected result? A clean run.
What do you get instead? The above error.
Additional info

Q
A

Version
1.0.?

PHP version

Operating system

To avoid the above error I have changed the 'final' to 'abstract' since class Widget contains an abstract method.

Fixed in https://github.com/yiisoft/demo/pull/566

Working fine now. Replaced 3 files. Thanks


TypeError: null is not an object (evaluating 'this.dropinRef.setStatus')

Describe the bug
After migrating to Adyen V6 we got this new error in production.
TypeError: null is not an object (evaluating 'this.dropinRef.setStatus')
To Reproduce

Start a payment workflow
Update dropin with setStatus

Expected behavior
No error should occurred.
Additional context
We might be navigating away in some cases, this might be why we got this error. Before V6 it was okay.
We have specific check already in place but maybe we are missing something :
if (dropin) {
  dropin.setStatus('success', { message: 'Payment successful!' });
}

@tlenclos - I don't really know what to suggest - this functionality definitely works.
Maybe you're losing your reference to dropin, as you suggest?
Try and debug it some more and if that doesn't work perhaps you can share a code snippet showing how you instantiate AdyenCheckout and create a new Dropin

Hello @sponglord, I created a complete example with route transition here, I encounter the same error. https://stackblitz.com/edit/sb1-mshjqk?file=src%2Fcomponents%2FCheckoutForm.tsx
You can see in the CheckoutForm.tsx component what we do on valid payment, simulating an API call.
      onSubmit: (state, component, actions) => {
        return new Promise((resolve) => setTimeout(resolve, 2000)).then(() => {
          actions.resolve();

          if (state.isValid) {
            navigate('/payment-confirm');
          }
        });
      },

I think we could add a ref null check on the status update.

@tlenclos - thanks for the example.
Can you please tell us, using the stackblitz, what the exact steps are to recreate the issue? (At the moment I just get origin errors in the card component and can't make a payment)

@sponglord I fixed the allowed origin of the adyen key I used. This should be good.

This is an issue for our team.
A temporary fix would be to set disableFinalAnimation at the top level when creating your checkout instance:
const checkoutComponent = await AdyenCheckout({
  disableFinalAnimation: true,
  ...
});

The docs and warning will tell you to put it inside of `paymentMethodsConfiguration`, but this is misleading because the Dropin component is checking the prop at the top level:

packages/lib/src/components/Dropin/Dropin.tsx

```js
public displayFinalAnimation(type: 'success' | 'error') {
  if (this.props.disableFinalAnimation) return;
  this.dropinRef.setStatus(type);
}

Hi @tlenclos
Thanks for sharing the link.
I think the issue here is we didn't clean up the Dropin in the effect. (As we are in the strict mode, React will re-run Effects an extra time, which result into multiple drop-in instances and references got mixed up.)
So I would suggest to clean up the dropin in the effect or only initiate the dropin once.
Another small improvement would be resolving the action with {resultCode: 'xxx'} or {}, e.g: actions.resolve({resultCode: 'Authorised'});.
Pasted one of the solutions here:
import React, { useEffect, useRef } from 'react';
import { AdyenCheckout, Dropin, IDropin } from '@adyen/adyen-web/auto';
import<EMAIL_ADDRESS>import { AdyenConfiguration } from '../types/adyen';
import { useNavigate } from 'react-router-dom';

const ADYEN_CLIENT_KEY = 'test_QZJGWMO6BFDXZM4SW6SWQUM2ZMQIPEBP';

const CheckoutForm: React.FC = () => {
  const dropinContainerRef = useRef<HTMLDivElement>(null);
  const dropin = useRef<IDropin | null>(null);
  const navigate = useNavigate();
  useEffect(() => {
    const configuration: AdyenConfiguration = {
      environment: 'test',
      clientKey: ADYEN_CLIENT_KEY,
      countryCode: 'FR',
      paymentMethodsResponse: {
        paymentMethods: [
          {
            type: 'scheme',
            name: 'Credit Card',
          },
          {
            type: 'paypal',
            name: 'PayPal',
          },
        ],
      },
      amount: {
        value: 1000,
        currency: 'USD',
      },
      onSubmit: (state, component, actions) => {
        return new Promise((resolve) => setTimeout(resolve, 2000)).then(() => {
          actions.resolve({ resultCode: 'Authorised' });

          if (state.isValid) {
            //navigate('/payment-confirm');
          }
        });
      },
      onAdditionalDetails: (state, component) => {
        console.log('Additional details:', state);
      },
    };

    const initializeAdyen = async () => {
      const checkout = await AdyenCheckout(configuration);
      if (dropinContainerRef.current) {
        if (dropin.current === null) {
          dropin.current = new Dropin(checkout).mount(
            dropinContainerRef.current
          );
        }
      }
    };

    initializeAdyen();
  }, []);

  return (

Checkout

Order Summary

            Product Total
            $10.00

  );
};

export default CheckoutForm;

@longyulongyu we got the issue in production, strict mode is only for development mode.
I think considering this is a payment SDK, with a lot of asynchronous behaviour, it should check ref existence before calling any methods.

@tlenclos it's definitely a good improvement. But could you try the solution above, since it's already reproducible in the dev mode.

I updated the example on stackblitz and confirm it's not showing any error with the ref check https://stackblitz.com/edit/sb1-mshjqk?file=src%2Fcomponents%2FCheckoutForm.tsx 👍

Thanks for confirming, cheers!


Added "webhooks" to syntax

This is a suggestion to fix #10727

@NenoLoje : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


Merge 'ThreeMammals:develop' into 'develop'

Let's update your repo with latest top-commits from head repository.
That will allow to perform rebase-operation for feature branches without merge-commits.

Thank you for updating your default branch!


DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-yml-archive-non-versioning-archive/pull/346 is merged into live branch.
Auto archive content to https://github.com/opstest2/docs-yml-archive-non-versioning-archive.git

Docs Build status updates of commit cf8e4c4:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.redirection.json
:white_check_mark:Succeeded

docs/TOC.yml
:white_check_mark:Succeeded
View

docs/index.yml
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/article3-1-1.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/article3-1-2.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/article3-1-3.yml
:white_check_mark:Succeeded
View

docs/to-be-archive/level1/sql-database-engine.png
:white_check_mark:Succeeded

docs/to-be-archive/level2/article3-2-1.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level2/article3-2-2.md
:white_check_mark:Succeeded
View

docs/to-be-archive/level2/article3-2-3.yml
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Enable watch for @angular-devkit/build-angular:server

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

Area
- [ x ] devkit
- [ ] schematics

Versions

node v10.1.0
npm v6.1.0
Desired functionality
Currently developing application features for a server-side rendered app is a real pain. While I can ng build --aot --watch for the browser bundles, I have to manually rerun ng run appname:server to rebuild the server bundles every time I make a change. I suggest support for a watch flag that automatically rebuilds as necessary.

I have tested the same also for<EMAIL_ADDRESS>and the result is the same: it's impossible to enable watch mode for the server target. I have also tried with adding "watch": true to angular.json and I was getting the following error.
  Data path "" should NOT have additional properties(watch).

@Toxicable. you told that it was included in your PR. so I have tried it on RC too. And the result is the same. Also if there is another way to get it to work please tell me.
And I would like to make a note: if you're discussing adding that option to the angular json instead of having cli option then it's a terrible idea.

@hakobpogh I believe adding a flag in the CLI schema file of a schematic also adds support for angular.json and vice versa.

You need to use "@angular-devkit/build-angular": "0.7.0-rc.0",
beta.2 was where it was introduced but rc.0 is the latest

Closing as answered.  (Thanks @Toxicable )


OpenPGP: Old vs. New Packet Format

Hey everyone!
I noticed, that BC supports both the old1 and new2 packet length
format for OpenPGP packets.
When being serialized, BC's packets basically decide which format to use
via a boolean flag passed into writePacket() of the BCPGOutputStream3.
This flag is hard coded in every packet class and there is no clear
pattern to when the new format is used and when the old.
My question is: Would it be possible for a future BC release to
exclusively use the new format when producing packets? I guess support
for the new format should be available in pretty much any other active
OpenPGP implementation. In the end, there are packets in BC which
already use the new format, so any implementation that needs to interop
with BC likely already supports parsing the new format.
Here is a related discussion in PGPainless' issue tracker4.
What do you say?
Happy Hacking,
Paul

Are there any updates on this?
Would you accept a PR that changes all PGP packets to use the new format? I see that this would cause quite a bunch of encoding tests to break, which would need to be rewritten / updated.

I see that in some places it is possible to convince BC to make use of the new packet format, e.g. when encoding key rings (by using keyRing.encode(myBcpgOutputStream) where myBcpgOutputStream was instantiated with newFormatOnly = true.
However, this approach falls short when dealing with encrypted / compressed / literal data.
For example here PGPEncryptedDataGenerator.open(outputStream) will wrap the given output stream into a BCPGOutputStream instance that makes use of the old format, no matter how the outputStream instance that was passed in was configured.

Round-Tripping packets is now possible with #1642


sil-q: use .sil-q to avoid clashing with sil's data

Description of changes
Sil-Q changes the game to a fair degree, so it is probably better to avoid clashing Sil-Q's game data with Sil's, just in case someone would like to play both games at the same time (me included).

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

I think the game data putting together might be okay as long as the other lib files are compatible in both games, and the character names are unique for each game.  This may not always be the case, and in such cases separating the data files are better than mixing them together.
Saved games "gone" may not be as serious as it is looking like, for example, one can easily restore one's games with mv ~/.sil ~/.sil-q in the most simple case.

I'd be on board with someone merging this.
I know the data is not gone, but it might be hard for people who are just it to figure out what to do. But:

if they create an issue, it's easy to help them
sil-q has been in nixpkgs for only a short while, and it's also very niche, so I'd wager a guess that there won't be any issue 🙂


Plugin config page has dead link to README.md

The plugin configuration page contains this link to "configure the jira integration", which points to https://about.mattermost.com/default-jira-plugin, which redirects to https://github.com/mattermost/mattermost-plugin-jira/blob/master/README.md, which 404s. I'm guessing this is because the repo now uses GitBook.

@aaronrothschild what's the correct link now?

Actually both the links (on lines 27 and 84 of https://github.com/mattermost/mattermost-plugin-jira/blob/4de6a5320e6921b48f87351acf84afcf2ef64fce/plugin.json) have this problem, though they're not the same link.

Will quickly fix this as soon  as we get the correct link from @aaronrothschild


 doesn't implement lookup_instance_var

I had the following message when trying to run my program (crystal version Crystal 0.7.1 (Fri May  1 22:39:55 UTC 2015) on Arch Linux 64-bit):
% crystal run src/trouve.cr
Bug: Trouve::CircularBuffer(T) doesn't implement lookup_instance_var
_init +194110 [0]
_init +1861825 [0]
_init +1838412 [0]
_init +1575444 [0]
_init +1597158 [0]
_init +1649161 [0]
_init +1597158 [0]
_init +2306235 [0]
_init +238636 [0]
_init +226429 [0]
_init +210723 [0]
__libc_start_main +240 [0]
_init +191969 [0]
 +191969 [0]

Error: you've found a bug in the Crystal compiler. Please open an issue: https://github.com/manastech/crystal/issues

You can find the source code here: https://github.com/PuerkitoBio/trouve, commit cd04f26ad876f031225873eb072112fbda92a4db
Let me know if you need more details.
Martin

I can reproduce with this minimal code:
class SomeType(T)
  @x = 0
end

Removing the generic (T) type makes the error message disappear. Hope that helps.

If you actually try to use @x in class method you will get an error:
class SomeType
  @x = 0

  def self.x_plus_one
    @x + 1
  end
end

Does not compile:
in line 4: @instance_vars are not yet allowed in metaclasses: use
@@class_vars instead

So instead, just use @@x - it works just fine.
--
Best Regards,
Alexey Fedorov,
Sr Ruby Developer, Clojure Developer, Rust Developer,
+49 15757 486 476
2015-05-18 2:48 GMT+03:00 Martin Angers<EMAIL_ADDRESS>
I can reproduce with this minimal code:
class SomeType(T)
@x = 0
end
Removing the generic (T) type makes the error message disappear. Hope that
helps.
—
Reply to this email directly or view it on GitHub
https://github.com/manastech/crystal/issues/665#issuecomment-102871041.

As far as I know, @@x is a class variable, while @x is an instance variable, so that change , while it may compile, is not the intended code. In any case, I'm not arguing that the original code is good code (though I believe it should compile?), but it still shouldn't cause such an error message (the message explicitly asked to create an issue), so that is why I created this.

@waterlink Check this (near the bottom). @x = 0 at a class level defines an instance variable initializer. This is different from Ruby, but it's useful to avoid the Nil type when reopening classes and adding instance variables.


Render banner in Concierge chat

Details
Adds a banner to the Concierge chat to direct managed users to their account manager chat.
Fixed Issues
$ https://github.com/Expensify/Expensify/issues/227162
Tests

Create two accounts<EMAIL_ADDRESS>and<EMAIL_ADDRESS>Add a validated domain for<EMAIL_ADDRESS>you can use ./script/clitools.sh generator:domain
As<EMAIL_ADDRESS>create a paid policy
Head over to concierge user assignment tool, and assign<EMAIL_ADDRESS>to<EMAIL_ADDRESS>Open NewDot and login as<EMAIL_ADDRESS>Open the Concierge chat and verify that you can see a banner at the top of the chat screen
Tap the text on the banner and verify that it navigates you to your chat with<EMAIL_ADDRESS>Go back to the chat with Concierge
Tap the x button and verify that the banner is closed

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

PR Review Checklist
Contributor (PR Author) Checklist

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

[x] I added steps for local testing in the Tests section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

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

[x] iOS / native
[x] Android / native
[x] iOS / Safari
[x] Android / Chrome
[x] MacOS / Chrome
[x] MacOS / Desktop

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

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product was added in all src/languages/* files
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

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

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] Any functional components have the displayName property
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

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

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

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

PR Reviewer Checklist
The Contributor+ will copy/paste it into a new comment and complete it after the author checklist is completed

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] iOS / native
[x] Android / native
[x] iOS / Safari
[x] Android / Chrome
[x] MacOS / Chrome
[x] MacOS / Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product was added in all src/languages/* files
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

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

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] Any functional components have the displayName property
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

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

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

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

QA Steps

Same as test steps, but you will have to find an user account that is a domain admin and has a paid policy to assign to yourself.

[ ] Verify that no errors appear in the JS console

Screenshots

Web
https://user-images.githubusercontent.com/22219519/193123902-e5fdf0d7-9f5e-4afb-a37a-7e75480ef973.mov
Mobile Web - Chrome

Mobile Web - Safari
https://user-images.githubusercontent.com/22219519/193123943-221fc18c-c7d2-49f0-979f-cde96ce4c55d.mov
Desktop
https://user-images.githubusercontent.com/22219519/193107071-554bac7b-46b2-47fa-8b9c-d3adc7c1115b.mov
iOS
https://user-images.githubusercontent.com/22219519/193123961-35acc771-0cd8-4751-8a91-7ad889b631a2.mov
Android
https://user-images.githubusercontent.com/22219519/193123983-d64bca28-b5a8-4d6d-9c99-7587531172cf.mov

Updated! Conflicts resolved :)

Incorrect @MelvinBot

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by @yuwenmemon in version: 1.2.11-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

Tested on staging and it's a pass 🎉

🚀 Deployed to production by @AndrewGable in version: 1.2.11-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

FYI, I believe this PR caused this bug: https://github.com/Expensify/App/issues/13452


C* table creation is Lazy

C* tables dont get created until you do a REST query. Eager creation would be nice so we know after its installed that the schema is in place.

Closing this since we are now using JIRA. It has been recreated as https://issues.jboss.org/browse/HWKMETRICS-23.


Unable to reproduce the results of the paper

Hello, great job!
I downloaded your code and trained it on the Patio_High dataset (mlp sls), but only got a PSNR of 20.856, far from the 23.12 in the paper. Can you give me any suggestions for improvement?
Below is my running record
CUDA_HOME=/usr/local/cuda-11.8/;CUDA_VISIBLE_DEVICES=0 python spotless_trainer.py --data_dir /home/lh/all_datasets/RobustScene/on-the-go/patio_high/ --data_factor 8 --result_dir patio_high --loss_type robust --semantics --no-cluster --train_keyword "clutter" --test_keyword "extra"
[Parser] 267 images, taken by 1 cameras.
Scene scale: 2.0880561977659355
Model initialized. Number of GS: 204251
╭─────────────── viser ───────────────╮
│             ╷                       │
│   HTTP      │ http://<IP_ADDRESS>:8080   │
│   Websocket │ ws://<IP_ADDRESS>:8080     │
│             ╵                       │
╰─────────────────────────────────────╯
loss=0.100| sh degree=0| :   2%|█▌                                                                          | 597/30000 [00:11<08:14, 59.45it/s]Step 600: 419 GSs duplicated, 800 GSs split. Now having 205470 GSs.
Step 600: 336 GSs pruned. Now having 205134 GSs.
loss=0.072| sh degree=0| :   2%|█▊                                                                          | 698/30000 [00:12<08:22, 58.28it/s]Step 700: 1050 GSs duplicated, 1879 GSs split. Now having 208063 GSs.
Step 700: 147 GSs pruned. Now having 207916 GSs.
loss=0.066| sh degree=0| :   3%|██                                                                          | 795/30000 [00:14<08:22, 58.07it/s]Step 800: 1231 GSs duplicated, 2467 GSs split. Now having 211614 GSs.
Step 800: 112 GSs pruned. Now having 211502 GSs.
loss=0.057| sh degree=0| :   3%|██▎                                                                         | 897/30000 [00:16<08:37, 56.24it/s]Step 900: 1444 GSs duplicated, 3050 GSs split. Now having 215996 GSs.
Step 900: 94 GSs pruned. Now having 215902 GSs.
loss=0.059| sh degree=1| :   3%|██▌                                                                         | 996/30000 [00:17<08:15, 58.49it/s]Step 1000: 1671 GSs duplicated, 3197 GSs split. Now having 220770 GSs.
Step 1000: 82 GSs pruned. Now having 220688 GSs.
loss=0.065| sh degree=1| :   4%|██▊                                                                        | 1100/30000 [00:19<07:47, 61.82it/s]Step 1100: 2370 GSs duplicated, 3807 GSs split. Now having 226865 GSs.
Step 1100: 80 GSs pruned. Now having 226785 GSs.
loss=0.062| sh degree=1| :   4%|██▉                                                                        | 1196/30000 [00:21<07:48, 61.50it/s]Step 1200: 2681 GSs duplicated, 3850 GSs split. Now having 233316 GSs.
Step 1200: 114 GSs pruned. Now having 233202 GSs.
loss=0.070| sh degree=1| :   4%|███▎                                                                       | 1300/30000 [00:23<08:20, 57.37it/s]Step 1300: 3306 GSs duplicated, 4157 GSs split. Now having 240665 GSs.
Step 1300: 80 GSs pruned. Now having 240585 GSs.
loss=0.052| sh degree=1| :   5%|███▌                                                                       | 1400/30000 [00:24<08:07, 58.70it/s]Step 1400: 3334 GSs duplicated, 3772 GSs split. Now having 247691 GSs.
Step 1400: 95 GSs pruned. Now having 247596 GSs.
loss=0.069| sh degree=1| :   5%|███▋                                                                       | 1495/30000 [00:26<08:00, 59.33it/s]Step 1500: 3578 GSs duplicated, 3115 GSs split. Now having 254289 GSs.
Step 1500: 79 GSs pruned. Now having 254210 GSs.
loss=0.057| sh degree=1| :   5%|███▉                                                                       | 1598/30000 [00:28<08:11, 57.74it/s]Step 1600: 4753 GSs duplicated, 3720 GSs split. Now having 262683 GSs.
Step 1600: 83 GSs pruned. Now having 262600 GSs.
loss=0.056| sh degree=1| :   6%|████▏                                                                      | 1699/30000 [00:30<08:11, 57.64it/s]Step 1700: 4346 GSs duplicated, 4047 GSs split. Now having 270993 GSs.
Step 1700: 99 GSs pruned. Now having 270894 GSs.
loss=0.047| sh degree=1| :   6%|████▍                                                                      | 1799/30000 [00:31<08:14, 57.00it/s]Step 1800: 4524 GSs duplicated, 2960 GSs split. Now having 278378 GSs.
Step 1800: 106 GSs pruned. Now having 278272 GSs.
loss=0.052| sh degree=1| :   6%|████▊                                                                      | 1900/30000 [00:33<07:47, 60.12it/s]Step 1900: 5158 GSs duplicated, 3273 GSs split. Now having 286703 GSs.
Step 1900: 99 GSs pruned. Now having 286604 GSs.
loss=0.041| sh degree=2| :   7%|████▉                                                                      | 1997/30000 [00:35<08:09, 57.24it/s]Step 2000: 5465 GSs duplicated, 3693 GSs split. Now having 295762 GSs.
Step 2000: 122 GSs pruned. Now having 295640 GSs.
loss=0.057| sh degree=2| :   7%|█████▏                                                                     | 2096/30000 [00:36<07:49, 59.38it/s]Step 2100: 5422 GSs duplicated, 3134 GSs split. Now having 304196 GSs.
Step 2100: 131 GSs pruned. Now having 304065 GSs.
loss=0.056| sh degree=2| :   7%|█████▍                                                                     | 2199/30000 [00:38<07:57, 58.26it/s]Step 2200: 5225 GSs duplicated, 2939 GSs split. Now having 312229 GSs.
Step 2200: 123 GSs pruned. Now having 312106 GSs.
loss=0.044| sh degree=2| :   8%|█████▋                                                                     | 2296/30000 [00:40<07:50, 58.89it/s]Step 2300: 5374 GSs duplicated, 2848 GSs split. Now having 320328 GSs.
Step 2300: 126 GSs pruned. Now having 320202 GSs.
loss=0.055| sh degree=2| :   8%|█████▉                                                                     | 2399/30000 [00:42<07:45, 59.30it/s]Step 2400: 5533 GSs duplicated, 2671 GSs split. Now having 328406 GSs.
Step 2400: 116 GSs pruned. Now having 328290 GSs.
loss=0.053| sh degree=2| :   8%|██████▏                                                                    | 2497/30000 [00:43<07:53, 58.05it/s]Step 2500: 5179 GSs duplicated, 2727 GSs split. Now having 336196 GSs.
Step 2500: 130 GSs pruned. Now having 336066 GSs.
loss=0.063| sh degree=2| :   9%|██████▍                                                                    | 2599/30000 [00:45<08:17, 55.02it/s]Step 2600: 6119 GSs duplicated, 2918 GSs split. Now having 345103 GSs.
Step 2600: 100 GSs pruned. Now having 345003 GSs.
loss=0.046| sh degree=2| :   9%|██████▋                                                                    | 2695/30000 [00:47<08:04, 56.32it/s]Step 2700: 5442 GSs duplicated, 2323 GSs split. Now having 352768 GSs.
Step 2700: 119 GSs pruned. Now having 352649 GSs.
loss=0.046| sh degree=2| :   9%|██████▉                                                                    | 2797/30000 [00:49<08:03, 56.22it/s]Step 2800: 5555 GSs duplicated, 2338 GSs split. Now having 360542 GSs.
Step 2800: 155 GSs pruned. Now having 360387 GSs.
loss=0.041| sh degree=2| :  10%|███████▏                                                                   | 2899/30000 [00:51<08:15, 54.74it/s]Step 2900: 5324 GSs duplicated, 1987 GSs split. Now having 367698 GSs.
Step 2900: 116 GSs pruned. Now having 367582 GSs.
loss=0.052| sh degree=3| :  10%|███████▍                                                                   | 2996/30000 [00:52<08:23, 53.67it/s]Step 3000: 5363 GSs duplicated, 1859 GSs split. Now having 374804 GSs.
Step 3000: 123 GSs pruned. Now having 374681 GSs.
loss=0.052| sh degree=3| :  10%|███████▋                                                                   | 3098/30000 [00:54<08:04, 55.57it/s]Step 3100: 5704 GSs duplicated, 2243 GSs split. Now having 382628 GSs.
Step 3100: 154 GSs pruned. Now having 382474 GSs.
loss=0.042| sh degree=3| :  11%|████████                                                                   | 3200/30000 [00:56<08:08, 54.81it/s]Step 3200: 6148 GSs duplicated, 2515 GSs split. Now having 391137 GSs.
Step 3200: 130 GSs pruned. Now having 391007 GSs.
loss=0.042| sh degree=3| :  11%|████████▏                                                                  | 3296/30000 [00:58<08:04, 55.13it/s]Step 3300: 5207 GSs duplicated, 1178 GSs split. Now having 397392 GSs.
Step 3300: 157 GSs pruned. Now having 397235 GSs.
loss=0.041| sh degree=3| :  11%|████████▍                                                                  | 3398/30000 [01:00<08:17, 53.48it/s]Step 3400: 5711 GSs duplicated, 2079 GSs split. Now having 405025 GSs.
Step 3400: 150 GSs pruned. Now having 404875 GSs.
loss=0.044| sh degree=3| :  12%|████████▊                                                                  | 3500/30000 [01:02<08:13, 53.75it/s]Step 3500: 5507 GSs duplicated, 1728 GSs split. Now having 412110 GSs.
Step 3500: 119 GSs pruned. Now having 411991 GSs.
loss=0.039| sh degree=3| :  12%|████████▉                                                                  | 3596/30000 [01:04<08:43, 50.42it/s]Step 3600: 5559 GSs duplicated, 1395 GSs split. Now having 418945 GSs.
Step 3600: 181 GSs pruned. Now having 418764 GSs.
loss=0.056| sh degree=3| :  12%|█████████▏                                                                 | 3698/30000 [01:06<07:53, 55.58it/s]Step 3700: 5643 GSs duplicated, 2021 GSs split. Now having 426428 GSs.
Step 3700: 173 GSs pruned. Now having 426255 GSs.
loss=0.045| sh degree=3| :  13%|█████████▌                                                                 | 3800/30000 [01:07<08:15, 52.83it/s]Step 3800: 5642 GSs duplicated, 1708 GSs split. Now having 433605 GSs.
Step 3800: 147 GSs pruned. Now having 433458 GSs.
loss=0.054| sh degree=3| :  13%|█████████▋                                                                 | 3896/30000 [01:09<07:57, 54.65it/s]Step 3900: 6725 GSs duplicated, 1793 GSs split. Now having 441976 GSs.
Step 3900: 220 GSs pruned. Now having 441756 GSs.
loss=0.039| sh degree=3| :  13%|█████████▉                                                                 | 3998/30000 [01:11<08:57, 48.36it/s]Step 4000: 5054 GSs duplicated, 1214 GSs split. Now having 448024 GSs.
Step 4000: 166 GSs pruned. Now having 447858 GSs.
loss=0.050| sh degree=3| :  14%|██████████▏                                                                | 4099/30000 [01:13<07:55, 54.50it/s]Step 4100: 4745 GSs duplicated, 1338 GSs split. Now having 453941 GSs.
Step 4100: 208 GSs pruned. Now having 453733 GSs.
loss=0.039| sh degree=3| :  14%|██████████▍                                                                | 4195/30000 [01:15<07:54, 54.35it/s]Step 4200: 5726 GSs duplicated, 1366 GSs split. Now having 460825 GSs.
Step 4200: 158 GSs pruned. Now having 460667 GSs.
loss=0.040| sh degree=3| :  14%|██████████▋                                                                | 4296/30000 [01:17<07:59, 53.58it/s]Step 4300: 5025 GSs duplicated, 1488 GSs split. Now having 467180 GSs.
Step 4300: 257 GSs pruned. Now having 466923 GSs.
loss=0.034| sh degree=3| :  15%|██████████▉                                                                | 4398/30000 [01:19<08:06, 52.65it/s]Step 4400: 5509 GSs duplicated, 1323 GSs split. Now having 473755 GSs.
Step 4400: 188 GSs pruned. Now having 473567 GSs.
loss=0.059| sh degree=3| :  15%|███████████▏                                                               | 4499/30000 [01:21<08:04, 52.67it/s]Step 4500: 5178 GSs duplicated, 1276 GSs split. Now having 480021 GSs.
Step 4500: 251 GSs pruned. Now having 479770 GSs.
loss=0.048| sh degree=3| :  15%|███████████▍                                                               | 4595/30000 [01:23<07:53, 53.62it/s]Step 4600: 4743 GSs duplicated, 1080 GSs split. Now having 485593 GSs.
Step 4600: 243 GSs pruned. Now having 485350 GSs.
loss=0.037| sh degree=3| :  16%|███████████▋                                                               | 4697/30000 [01:25<07:55, 53.21it/s]Step 4700: 4217 GSs duplicated, 801 GSs split. Now having 490368 GSs.
Step 4700: 199 GSs pruned. Now having 490169 GSs.
loss=0.039| sh degree=3| :  16%|███████████▉                                                               | 4799/30000 [01:27<07:54, 53.17it/s]Step 4800: 4860 GSs duplicated, 1046 GSs split. Now having 496075 GSs.
Step 4800: 215 GSs pruned. Now having 495860 GSs.
loss=0.040| sh degree=3| :  16%|████████████▏                                                              | 4895/30000 [01:29<08:36, 48.64it/s]Step 4900: 5335 GSs duplicated, 1294 GSs split. Now having 502489 GSs.
Step 4900: 252 GSs pruned. Now having 502237 GSs.
loss=0.045| sh degree=3| :  17%|████████████▍                                                              | 4995/30000 [01:30<08:21, 49.88it/s]Step 5000: 5006 GSs duplicated, 1223 GSs split. Now having 508466 GSs.
Step 5000: 227 GSs pruned. Now having 508239 GSs.
loss=0.052| sh degree=3| :  17%|████████████▋                                                              | 5096/30000 [01:32<08:13, 50.45it/s]Step 5100: 4892 GSs duplicated, 1035 GSs split. Now having 514166 GSs.
Step 5100: 245 GSs pruned. Now having 513921 GSs.
loss=0.064| sh degree=3| :  17%|████████████▉                                                              | 5197/30000 [01:34<07:47, 53.07it/s]Step 5200: 5151 GSs duplicated, 966 GSs split. Now having 520038 GSs.
Step 5200: 219 GSs pruned. Now having 519819 GSs.
loss=0.056| sh degree=3| :  18%|█████████████▏                                                             | 5299/30000 [01:36<07:46, 52.97it/s]Step 5300: 4647 GSs duplicated, 1223 GSs split. Now having 525689 GSs.
Step 5300: 280 GSs pruned. Now having 525409 GSs.
loss=0.056| sh degree=3| :  18%|█████████████▍                                                             | 5395/30000 [01:38<08:07, 50.44it/s]Step 5400: 5008 GSs duplicated, 1283 GSs split. Now having 531700 GSs.
Step 5400: 305 GSs pruned. Now having 531395 GSs.
loss=0.044| sh degree=3| :  18%|█████████████▋                                                             | 5496/30000 [01:40<08:05, 50.50it/s]Step 5500: 4433 GSs duplicated, 915 GSs split. Now having 536743 GSs.
Step 5500: 227 GSs pruned. Now having 536516 GSs.
loss=0.052| sh degree=3| :  19%|█████████████▉                                                             | 5598/30000 [01:42<07:42, 52.75it/s]Step 5600: 4620 GSs duplicated, 892 GSs split. Now having 542028 GSs.
Step 5600: 264 GSs pruned. Now having 541764 GSs.
loss=0.045| sh degree=3| :  19%|██████████████▏                                                            | 5697/30000 [01:44<07:50, 51.65it/s]Step 5700: 4399 GSs duplicated, 798 GSs split. Now having 546961 GSs.
Step 5700: 335 GSs pruned. Now having 546626 GSs.
loss=0.036| sh degree=3| :  19%|██████████████▍                                                            | 5797/30000 [01:46<07:48, 51.66it/s]Step 5800: 6273 GSs duplicated, 1394 GSs split. Now having 554293 GSs.
Step 5800: 299 GSs pruned. Now having 553994 GSs.
loss=0.027| sh degree=3| :  20%|██████████████▋                                                            | 5896/30000 [01:48<07:43, 51.97it/s]Step 5900: 3783 GSs duplicated, 831 GSs split. Now having 558608 GSs.
Step 5900: 283 GSs pruned. Now having 558325 GSs.
loss=0.048| sh degree=3| :  20%|██████████████▉                                                            | 5998/30000 [01:50<08:28, 47.16it/s]Step 6000: 4538 GSs duplicated, 842 GSs split. Now having 563705 GSs.
Step 6000: 273 GSs pruned. Now having 563432 GSs.
loss=0.042| sh degree=3| :  20%|███████████████▏                                                           | 6098/30000 [01:52<07:35, 52.43it/s]Step 6100: 4466 GSs duplicated, 873 GSs split. Now having 568771 GSs.
Step 6100: 370 GSs pruned. Now having 568401 GSs.
loss=0.041| sh degree=3| :  21%|███████████████▌                                                           | 6200/30000 [01:54<07:40, 51.67it/s]Step 6200: 4568 GSs duplicated, 972 GSs split. Now having 573941 GSs.
Step 6200: 248 GSs pruned. Now having 573693 GSs.
loss=0.040| sh degree=3| :  21%|███████████████▋                                                           | 6296/30000 [01:56<07:40, 51.44it/s]Step 6300: 4111 GSs duplicated, 847 GSs split. Now having 578651 GSs.
Step 6300: 312 GSs pruned. Now having 578339 GSs.
loss=0.046| sh degree=3| :  21%|███████████████▉                                                           | 6398/30000 [01:58<07:34, 51.88it/s]Step 6400: 3760 GSs duplicated, 643 GSs split. Now having 582742 GSs.
Step 6400: 254 GSs pruned. Now having 582488 GSs.
loss=0.038| sh degree=3| :  22%|████████████████▏                                                          | 6496/30000 [02:00<07:59, 48.98it/s]Step 6500: 4148 GSs duplicated, 827 GSs split. Now having 587463 GSs.
Step 6500: 359 GSs pruned. Now having 587104 GSs.
loss=0.034| sh degree=3| :  22%|████████████████▍                                                          | 6595/30000 [02:02<07:29, 52.02it/s]Step 6600: 4217 GSs duplicated, 890 GSs split. Now having 592211 GSs.
Step 6600: 314 GSs pruned. Now having 591897 GSs.
loss=0.045| sh degree=3| :  22%|████████████████▋                                                          | 6696/30000 [02:04<07:36, 51.10it/s]Step 6700: 4180 GSs duplicated, 772 GSs split. Now having 596849 GSs.
Step 6700: 396 GSs pruned. Now having 596453 GSs.
loss=0.040| sh degree=3| :  23%|████████████████▉                                                          | 6797/30000 [02:06<07:34, 51.02it/s]Step 6800: 3703 GSs duplicated, 648 GSs split. Now having 600804 GSs.
Step 6800: 298 GSs pruned. Now having 600506 GSs.
loss=0.043| sh degree=3| :  23%|█████████████████▏                                                         | 6899/30000 [02:08<07:58, 48.26it/s]Step 6900: 4862 GSs duplicated, 802 GSs split. Now having 606170 GSs.
Step 6900: 341 GSs pruned. Now having 605829 GSs.
loss=0.034| sh degree=3| :  23%|█████████████████▍                                                         | 6999/30000 [02:10<07:37, 50.26it/s]Step:  6999 {'mem': 3.7823853492736816, 'ellapsed_time':<PHONE_NUMBER>6768494, 'num_GS': 605829}
Running evaluation...
PSNR: 21.020, SSIM: 0.6344, LPIPS: 0.303 Time: 0.002s/image Number of GS: 605829
Running trajectory rendering...
Rendering trajectory: 100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 520/520 [00:01<00:00, 262.06it/s]
loss=0.034| sh degree=3| :  23%|█████████████████▍                                                         | 6999/30000 [02:30<07:37, 50.26it/s]Video saved to patio_high/videos/traj_6999.gif
loss=0.047| sh degree=3| :  23%|████████████████▊                                                       | 7000/30000 [03:17<28:25:34,  4.45s/it]Step 7000: 3994 GSs duplicated, 776 GSs split. Now having 610599 GSs.
Step 7000: 336 GSs pruned. Now having 610263 GSs.
loss=0.033| sh degree=3| :  24%|█████████████████▊                                                         | 7100/30000 [03:19<08:52, 42.98it/s]Step 7100: 4247 GSs duplicated, 793 GSs split. Now having 615303 GSs.
Step 7100: 334 GSs pruned. Now having 614969 GSs.
loss=0.051| sh degree=3| :  24%|█████████████████▉                                                         | 7196/30000 [03:21<07:20, 51.72it/s]Step 7200: 3937 GSs duplicated, 633 GSs split. Now having 619539 GSs.
Step 7200: 353 GSs pruned. Now having 619186 GSs.
loss=0.029| sh degree=3| :  24%|██████████████████▏                                                        | 7297/30000 [03:23<07:34, 49.91it/s]Step 7300: 4521 GSs duplicated, 816 GSs split. Now having 624523 GSs.
Step 7300: 400 GSs pruned. Now having 624123 GSs.
loss=0.038| sh degree=3| :  25%|██████████████████▍                                                        | 7398/30000 [03:25<07:17, 51.69it/s]Step 7400: 4074 GSs duplicated, 690 GSs split. Now having 628887 GSs.
Step 7400: 376 GSs pruned. Now having 628511 GSs.
loss=0.043| sh degree=3| :  25%|██████████████████▊                                                        | 7500/30000 [03:27<07:18, 51.26it/s]Step 7500: 4618 GSs duplicated, 754 GSs split. Now having 633883 GSs.
Step 7500: 409 GSs pruned. Now having 633474 GSs.
loss=0.063| sh degree=3| :  25%|██████████████████▉                                                        | 7596/30000 [03:29<07:34, 49.33it/s]Step 7600: 4040 GSs duplicated, 962 GSs split. Now having 638476 GSs.
Step 7600: 358 GSs pruned. Now having 638118 GSs.
loss=0.041| sh degree=3| :  26%|███████████████████▏                                                       | 7695/30000 [03:31<07:11, 51.69it/s]Step 7700: 3910 GSs duplicated, 701 GSs split. Now having 642729 GSs.
Step 7700: 383 GSs pruned. Now having 642346 GSs.
loss=0.041| sh degree=3| :  26%|███████████████████▍                                                       | 7798/30000 [03:33<07:39, 48.27it/s]Step 7800: 4360 GSs duplicated, 645 GSs split. Now having 647351 GSs.
Step 7800: 415 GSs pruned. Now having 646936 GSs.
loss=0.047| sh degree=3| :  26%|███████████████████▋                                                       | 7896/30000 [03:35<07:17, 50.56it/s]Step 7900: 4201 GSs duplicated, 776 GSs split. Now having 651913 GSs.
Step 7900: 332 GSs pruned. Now having 651581 GSs.
loss=0.040| sh degree=3| :  27%|███████████████████▉                                                       | 7997/30000 [03:37<08:25, 43.53it/s]Step 8000: 3620 GSs duplicated, 521 GSs split. Now having 655722 GSs.
Step 8000: 384 GSs pruned. Now having 655338 GSs.
loss=0.043| sh degree=3| :  27%|████████████████████▏                                                      | 8098/30000 [03:39<07:41, 47.49it/s]Step 8100: 3580 GSs duplicated, 581 GSs split. Now having 659499 GSs.
Step 8100: 451 GSs pruned. Now having 659048 GSs.
loss=0.036| sh degree=3| :  27%|████████████████████▍                                                      | 8199/30000 [03:41<07:37, 47.64it/s]Step 8200: 3862 GSs duplicated, 682 GSs split. Now having 663592 GSs.
Step 8200: 509 GSs pruned. Now having 663083 GSs.
loss=0.044| sh degree=3| :  28%|████████████████████▋                                                      | 8296/30000 [03:43<07:22, 49.04it/s]Step 8300: 3963 GSs duplicated, 958 GSs split. Now having 668004 GSs.
Step 8300: 570 GSs pruned. Now having 667434 GSs.
loss=0.052| sh degree=3| :  28%|████████████████████▉                                                      | 8399/30000 [03:45<07:13, 49.88it/s]Step 8400: 3036 GSs duplicated, 588 GSs split. Now having 671058 GSs.
Step 8400: 410 GSs pruned. Now having 670648 GSs.
loss=0.065| sh degree=3| :  28%|█████████████████████▏                                                     | 8497/30000 [03:47<07:23, 48.48it/s]Step 8500: 3663 GSs duplicated, 680 GSs split. Now having 674991 GSs.
Step 8500: 412 GSs pruned. Now having 674579 GSs.
loss=0.044| sh degree=3| :  29%|█████████████████████▌                                                     | 8600/30000 [03:49<07:12, 49.44it/s]Step 8600: 4222 GSs duplicated, 814 GSs split. Now having 679615 GSs.
Step 8600: 435 GSs pruned. Now having 679180 GSs.
loss=0.043| sh degree=3| :  29%|█████████████████████▋                                                     | 8697/30000 [03:51<07:02, 50.40it/s]Step 8700: 3608 GSs duplicated, 812 GSs split. Now having 683600 GSs.
Step 8700: 452 GSs pruned. Now having 683148 GSs.
loss=0.036| sh degree=3| :  29%|█████████████████████▉                                                     | 8796/30000 [03:53<07:16, 48.54it/s]Step 8800: 2735 GSs duplicated, 485 GSs split. Now having 686368 GSs.
Step 8800: 381 GSs pruned. Now having 685987 GSs.
loss=0.033| sh degree=3| :  30%|██████████████████████▏                                                    | 8895/30000 [03:56<07:39, 45.91it/s]Step 8900: 4254 GSs duplicated, 807 GSs split. Now having 691048 GSs.
Step 8900: 512 GSs pruned. Now having 690536 GSs.
loss=0.030| sh degree=3| :  30%|██████████████████████▍                                                    | 8998/30000 [03:58<07:14, 48.35it/s]Step 9000: 3965 GSs duplicated, 631 GSs split. Now having 695132 GSs.
Step 9000: 446 GSs pruned. Now having 694686 GSs.
loss=0.041| sh degree=3| :  30%|██████████████████████▊                                                    | 9100/30000 [04:00<07:00, 49.75it/s]Step 9100: 3060 GSs duplicated, 455 GSs split. Now having 698201 GSs.
Step 9100: 380 GSs pruned. Now having 697821 GSs.
loss=0.047| sh degree=3| :  31%|██████████████████████▉                                                    | 9199/30000 [04:02<06:58, 49.65it/s]Step 9200: 3522 GSs duplicated, 531 GSs split. Now having 701874 GSs.
Step 9200: 557 GSs pruned. Now having 701317 GSs.
loss=0.040| sh degree=3| :  31%|███████████████████████▎                                                   | 9300/30000 [04:04<07:28, 46.16it/s]Step 9300: 3121 GSs duplicated, 446 GSs split. Now having 704884 GSs.
Step 9300: 334 GSs pruned. Now having 704550 GSs.
loss=0.056| sh degree=3| :  31%|███████████████████████▍                                                   | 9397/30000 [04:06<07:11, 47.71it/s]Step 9400: 4015 GSs duplicated, 764 GSs split. Now having 709329 GSs.
Step 9400: 439 GSs pruned. Now having 708890 GSs.
loss=0.043| sh degree=3| :  32%|███████████████████████▋                                                   | 9497/30000 [04:08<07:13, 47.26it/s]Step 9500: 3290 GSs duplicated, 515 GSs split. Now having 712695 GSs.
Step 9500: 490 GSs pruned. Now having 712205 GSs.
loss=0.037| sh degree=3| :  32%|███████████████████████▉                                                   | 9599/30000 [04:10<07:13, 47.07it/s]Step 9600: 3926 GSs duplicated, 886 GSs split. Now having 717017 GSs.
Step 9600: 518 GSs pruned. Now having 716499 GSs.
loss=0.036| sh degree=3| :  32%|████████████████████████▏                                                  | 9700/30000 [04:13<07:01, 48.12it/s]Step 9700: 3407 GSs duplicated, 467 GSs split. Now having 720373 GSs.
Step 9700: 536 GSs pruned. Now having 719837 GSs.
loss=0.040| sh degree=3| :  33%|████████████████████████▍                                                  | 9799/30000 [04:15<06:59, 48.18it/s]Step 9800: 4465 GSs duplicated, 942 GSs split. Now having 725244 GSs.
Step 9800: 476 GSs pruned. Now having 724768 GSs.
loss=0.042| sh degree=3| :  33%|████████████████████████▋                                                  | 9896/30000 [04:17<07:17, 45.97it/s]Step 9900: 3206 GSs duplicated, 458 GSs split. Now having 728432 GSs.
Step 9900: 435 GSs pruned. Now having 727997 GSs.
loss=0.042| sh degree=3| :  33%|████████████████████████▉                                                  | 9999/30000 [04:19<07:25, 44.88it/s]Step 10000: 4047 GSs duplicated, 657 GSs split. Now having 732701 GSs.
Step 10000: 632 GSs pruned. Now having 732069 GSs.
loss=0.034| sh degree=3| :  34%|████████████████████████▉                                                 | 10100/30000 [04:21<07:14, 45.83it/s]Step 10100: 4611 GSs duplicated, 772 GSs split. Now having 737452 GSs.
Step 10100: 509 GSs pruned. Now having 736943 GSs.
loss=0.041| sh degree=3| :  34%|█████████████████████████▏                                                | 10200/30000 [04:23<07:05, 46.49it/s]Step 10200: 2658 GSs duplicated, 409 GSs split. Now having 740010 GSs.
Step 10200: 499 GSs pruned. Now having 739511 GSs.
loss=0.056| sh degree=3| :  34%|█████████████████████████▍                                                | 10296/30000 [04:25<06:56, 47.32it/s]Step 10300: 4461 GSs duplicated, 850 GSs split. Now having 744822 GSs.
Step 10300: 466 GSs pruned. Now having 744356 GSs.
loss=0.052| sh degree=3| :  35%|█████████████████████████▋                                                | 10397/30000 [04:28<07:10, 45.51it/s]Step 10400: 3143 GSs duplicated, 382 GSs split. Now having 747881 GSs.
Step 10400: 519 GSs pruned. Now having 747362 GSs.
loss=0.038| sh degree=3| :  35%|█████████████████████████▉                                                | 10498/30000 [04:30<06:54, 47.02it/s]Step 10500: 3187 GSs duplicated, 538 GSs split. Now having 751087 GSs.
Step 10500: 629 GSs pruned. Now having 750458 GSs.
loss=0.048| sh degree=3| :  35%|██████████████████████████▏                                               | 10598/30000 [04:32<07:10, 45.06it/s]Step 10600: 2839 GSs duplicated, 580 GSs split. Now having 753877 GSs.
Step 10600: 504 GSs pruned. Now having 753373 GSs.
loss=0.040| sh degree=3| :  36%|██████████████████████████▍                                               | 10698/30000 [04:34<06:42, 47.95it/s]Step 10700: 4694 GSs duplicated, 794 GSs split. Now having 758861 GSs.
Step 10700: 497 GSs pruned. Now having 758364 GSs.
loss=0.060| sh degree=3| :  36%|██████████████████████████▋                                               | 10796/30000 [04:36<06:28, 49.39it/s]Step 10800: 3019 GSs duplicated, 409 GSs split. Now having 761792 GSs.
Step 10800: 487 GSs pruned. Now having 761305 GSs.
loss=0.032| sh degree=3| :  36%|██████████████████████████▉                                               | 10896/30000 [04:38<06:59, 45.56it/s]Step 10900: 2827 GSs duplicated, 501 GSs split. Now having 764633 GSs.
Step 10900: 608 GSs pruned. Now having 764025 GSs.
loss=0.053| sh degree=3| :  37%|███████████████████████████                                               | 10996/30000 [04:40<06:27, 49.07it/s]Step 11000: 4195 GSs duplicated, 585 GSs split. Now having 768805 GSs.
Step 11000: 539 GSs pruned. Now having 768266 GSs.
loss=0.035| sh degree=3| :  37%|███████████████████████████▎                                              | 11097/30000 [04:43<06:37, 47.52it/s]Step 11100: 3062 GSs duplicated, 542 GSs split. Now having 771870 GSs.
Step 11100: 489 GSs pruned. Now having 771381 GSs.
loss=0.037| sh degree=3| :  37%|███████████████████████████▌                                              | 11197/30000 [04:45<06:37, 47.35it/s]Step 11200: 3767 GSs duplicated, 575 GSs split. Now having 775723 GSs.
Step 11200: 532 GSs pruned. Now having 775191 GSs.
loss=0.035| sh degree=3| :  38%|███████████████████████████▊                                              | 11298/30000 [04:47<06:33, 47.55it/s]Step 11300: 3015 GSs duplicated, 477 GSs split. Now having 778683 GSs.
Step 11300: 528 GSs pruned. Now having 778155 GSs.
loss=0.044| sh degree=3| :  38%|████████████████████████████                                              | 11398/30000 [04:49<06:34, 47.16it/s]Step 11400: 3409 GSs duplicated, 523 GSs split. Now having 782087 GSs.
Step 11400: 744 GSs pruned. Now having 781343 GSs.
loss=0.036| sh degree=3| :  38%|████████████████████████████▎                                             | 11498/30000 [04:51<06:28, 47.61it/s]Step 11500: 2494 GSs duplicated, 366 GSs split. Now having 784203 GSs.
Step 11500: 553 GSs pruned. Now having 783650 GSs.
loss=0.042| sh degree=3| :  39%|████████████████████████████▌                                             | 11599/30000 [04:53<06:24, 47.89it/s]Step 11600: 2899 GSs duplicated, 604 GSs split. Now having 787153 GSs.
Step 11600: 555 GSs pruned. Now having 786598 GSs.
loss=0.035| sh degree=3| :  39%|████████████████████████████▊                                             | 11699/30000 [04:56<06:25, 47.48it/s]Step 11700: 2695 GSs duplicated, 458 GSs split. Now having 789751 GSs.
Step 11700: 592 GSs pruned. Now having 789159 GSs.
loss=0.038| sh degree=3| :  39%|█████████████████████████████                                             | 11799/30000 [04:58<06:48, 44.59it/s]Step 11800: 3840 GSs duplicated, 626 GSs split. Now having 793625 GSs.
Step 11800: 725 GSs pruned. Now having 792900 GSs.
loss=0.044| sh degree=3| :  40%|█████████████████████████████▎                                            | 11899/30000 [05:00<06:14, 48.39it/s]Step 11900: 3430 GSs duplicated, 458 GSs split. Now having 796788 GSs.
Step 11900: 680 GSs pruned. Now having 796108 GSs.
loss=0.034| sh degree=3| :  40%|█████████████████████████████▌                                            | 11999/30000 [05:02<06:35, 45.57it/s]Step 12000: 4320 GSs duplicated, 823 GSs split. Now having 801251 GSs.
Step 12000: 586 GSs pruned. Now having 800665 GSs.
loss=0.047| sh degree=3| :  40%|█████████████████████████████▊                                            | 12099/30000 [05:04<06:28, 46.06it/s]Step 12100: 2573 GSs duplicated, 361 GSs split. Now having 803599 GSs.
Step 12100: 700 GSs pruned. Now having 802899 GSs.
loss=0.038| sh degree=3| :  41%|██████████████████████████████                                            | 12200/30000 [05:06<06:06, 48.55it/s]Step 12200: 3439 GSs duplicated, 387 GSs split. Now having 806725 GSs.
Step 12200: 594 GSs pruned. Now having 806131 GSs.
loss=0.036| sh degree=3| :  41%|██████████████████████████████▎                                           | 12296/30000 [05:08<06:06, 48.30it/s]Step 12300: 4060 GSs duplicated, 723 GSs split. Now having 810914 GSs.
Step 12300: 748 GSs pruned. Now having 810166 GSs.
loss=0.036| sh degree=3| :  41%|██████████████████████████████▌                                           | 12396/30000 [05:11<06:32, 44.81it/s]Step 12400: 4030 GSs duplicated, 565 GSs split. Now having 814761 GSs.
Step 12400: 576 GSs pruned. Now having 814185 GSs.
loss=0.037| sh degree=3| :  42%|██████████████████████████████▊                                           | 12496/30000 [05:13<06:09, 47.43it/s]Step 12500: 3015 GSs duplicated, 472 GSs split. Now having 817672 GSs.
Step 12500: 582 GSs pruned. Now having 817090 GSs.
loss=0.046| sh degree=3| :  42%|███████████████████████████████                                           | 12596/30000 [05:15<06:11, 46.80it/s]Step 12600: 2814 GSs duplicated, 394 GSs split. Now having 820298 GSs.
Step 12600: 697 GSs pruned. Now having 819601 GSs.
loss=0.039| sh degree=3| :  42%|███████████████████████████████▎                                          | 12696/30000 [05:17<06:16, 45.95it/s]Step 12700: 3781 GSs duplicated, 622 GSs split. Now having 824004 GSs.
Step 12700: 677 GSs pruned. Now having 823327 GSs.
loss=0.035| sh degree=3| :  43%|███████████████████████████████▌                                          | 12796/30000 [05:19<06:18, 45.51it/s]Step 12800: 3100 GSs duplicated, 429 GSs split. Now having 826856 GSs.
Step 12800: 773 GSs pruned. Now having 826083 GSs.
loss=0.051| sh degree=3| :  43%|███████████████████████████████▊                                          | 12896/30000 [05:22<06:32, 43.61it/s]Step 12900: 4902 GSs duplicated, 802 GSs split. Now having 831787 GSs.
Step 12900: 656 GSs pruned. Now having 831131 GSs.
loss=0.047| sh degree=3| :  43%|████████████████████████████████                                          | 12996/30000 [05:24<06:13, 45.50it/s]Step 13000: 2363 GSs duplicated, 313 GSs split. Now having 833807 GSs.
Step 13000: 719 GSs pruned. Now having 833088 GSs.
loss=0.030| sh degree=3| :  44%|████████████████████████████████▎                                         | 13096/30000 [05:26<06:16, 44.90it/s]Step 13100: 3191 GSs duplicated, 438 GSs split. Now having 836717 GSs.
Step 13100: 653 GSs pruned. Now having 836064 GSs.
loss=0.043| sh degree=3| :  44%|████████████████████████████████▌                                         | 13196/30000 [05:28<06:04, 46.12it/s]Step 13200: 3967 GSs duplicated, 717 GSs split. Now having 840748 GSs.
Step 13200: 709 GSs pruned. Now having 840039 GSs.
loss=0.051| sh degree=3| :  44%|████████████████████████████████▊                                         | 13296/30000 [05:30<06:01, 46.14it/s]Step 13300: 2794 GSs duplicated, 394 GSs split. Now having 843227 GSs.
Step 13300: 682 GSs pruned. Now having 842545 GSs.
loss=0.042| sh degree=3| :  45%|█████████████████████████████████                                         | 13396/30000 [05:33<05:48, 47.64it/s]Step 13400: 3368 GSs duplicated, 446 GSs split. Now having 846359 GSs.
Step 13400: 766 GSs pruned. Now having 845593 GSs.
loss=0.050| sh degree=3| :  45%|█████████████████████████████████▎                                        | 13496/30000 [05:35<05:53, 46.69it/s]Step 13500: 3971 GSs duplicated, 594 GSs split. Now having 850158 GSs.
Step 13500: 582 GSs pruned. Now having 849576 GSs.
loss=0.036| sh degree=3| :  45%|█████████████████████████████████▌                                        | 13596/30000 [05:37<06:12, 44.07it/s]Step 13600: 2473 GSs duplicated, 390 GSs split. Now having 852439 GSs.
Step 13600: 742 GSs pruned. Now having 851697 GSs.
loss=0.048| sh degree=3| :  46%|█████████████████████████████████▊                                        | 13696/30000 [05:39<05:49, 46.70it/s]Step 13700: 1861 GSs duplicated, 245 GSs split. Now having 853803 GSs.
Step 13700: 772 GSs pruned. Now having 853031 GSs.
loss=0.033| sh degree=3| :  46%|██████████████████████████████████                                        | 13796/30000 [05:41<05:56, 45.43it/s]Step 13800: 4746 GSs duplicated, 666 GSs split. Now having 858443 GSs.
Step 13800: 846 GSs pruned. Now having 857597 GSs.
loss=0.038| sh degree=3| :  46%|██████████████████████████████████▎                                       | 13896/30000 [05:44<05:56, 45.22it/s]Step 13900: 3026 GSs duplicated, 443 GSs split. Now having 861066 GSs.
Step 13900: 584 GSs pruned. Now having 860482 GSs.
loss=0.037| sh degree=3| :  47%|██████████████████████████████████▌                                       | 13996/30000 [05:46<06:16, 42.48it/s]Step 14000: 2921 GSs duplicated, 468 GSs split. Now having 863871 GSs.
Step 14000: 866 GSs pruned. Now having 863005 GSs.
loss=0.038| sh degree=3| :  47%|██████████████████████████████████▊                                       | 14096/30000 [05:48<05:34, 47.60it/s]Step 14100: 2106 GSs duplicated, 345 GSs split. Now having 865456 GSs.
Step 14100: 490 GSs pruned. Now having 864966 GSs.
loss=0.039| sh degree=3| :  47%|███████████████████████████████████                                       | 14196/30000 [05:50<05:57, 44.24it/s]Step 14200: 2739 GSs duplicated, 349 GSs split. Now having 868054 GSs.
Step 14200: 888 GSs pruned. Now having 867166 GSs.
loss=0.032| sh degree=3| :  48%|███████████████████████████████████▎                                      | 14296/30000 [05:52<05:39, 46.29it/s]Step 14300: 2618 GSs duplicated, 490 GSs split. Now having 870274 GSs.
Step 14300: 878 GSs pruned. Now having 869396 GSs.
loss=0.045| sh degree=3| :  48%|███████████████████████████████████▌                                      | 14396/30000 [05:55<05:41, 45.67it/s]Step 14400: 2584 GSs duplicated, 306 GSs split. Now having 872286 GSs.
Step 14400: 798 GSs pruned. Now having 871488 GSs.
loss=0.042| sh degree=3| :  48%|███████████████████████████████████▊                                      | 14496/30000 [05:57<05:44, 44.98it/s]Step 14500: 3142 GSs duplicated, 682 GSs split. Now having 875312 GSs.
Step 14500: 800 GSs pruned. Now having 874512 GSs.
loss=0.050| sh degree=3| :  49%|████████████████████████████████████                                      | 14596/30000 [05:59<05:47, 44.37it/s]Step 14600: 3154 GSs duplicated, 469 GSs split. Now having 878135 GSs.
Step 14600: 713 GSs pruned. Now having 877422 GSs.
loss=0.050| sh degree=3| :  49%|████████████████████████████████████▎                                     | 14696/30000 [06:01<05:35, 45.56it/s]Step 14700: 3834 GSs duplicated, 608 GSs split. Now having 881864 GSs.
Step 14700: 833 GSs pruned. Now having 881031 GSs.
loss=0.037| sh degree=3| :  49%|████████████████████████████████████▍                                     | 14796/30000 [06:04<05:27, 46.42it/s]Step 14800: 2546 GSs duplicated, 372 GSs split. Now having 883949 GSs.
Step 14800: 774 GSs pruned. Now having 883175 GSs.
loss=0.038| sh degree=3| :  50%|████████████████████████████████████▋                                     | 14896/30000 [06:06<05:26, 46.27it/s]Step 14900: 2552 GSs duplicated, 346 GSs split. Now having 886073 GSs.
Step 14900: 823 GSs pruned. Now having 885250 GSs.
loss=0.035| sh degree=3| : 100%|█████████████████████████████████████████████████████████████████████████▉| 29999/30000 [11:46<00:00,  7.66it/s]Step:  29999 {'mem': 4.169759750366211, 'ellapsed_time':<PHONE_NUMBER>535156, 'num_GS': 885250}
Running evaluation...
PSNR: 20.856, SSIM: 0.6627, LPIPS: 0.253 Time: 0.002s/image Number of GS: 885250
Running trajectory rendering...
Rendering trajectory: 100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 520/520 [00:01<00:00, 325.62it/s]
Video saved to patio_high/videos/traj_29999.gif██████████████████████████████████████████████████████████████████████████████████████████████████████████████████        | 491/520 [00:01<00:00, 308.07it/s]
loss=0.035| sh degree=3| : 100%|██████████████████████████████████████████████████████████████████████████| 30000/30000 [12:55<00:00, 38.70it/s]
Viewer running... Ctrl+C to exit.
^CTraceback (most recent call last):
  File "/home/lh/SpotLessSplats/examples/spotless_trainer.py", line 1265, in <module>
    main(cfg)
  File "/home/lh/SpotLessSplats/examples/spotless_trainer.py", line 1259, in main
    time.sleep(1000000)
KeyboardInterrupt

Have you solved the problem? @HanLingsgjk
the results of my training on on-the-go are closer to the results of 3dgs in Figure 3. What seems to be the problem in the code

Have you solved the problem? @HanLingsgjk the results of my training on on-the-go are closer to the results of 3dgs in Figure 3. What seems to be the problem in the code

No. During the installation process, there were also some errors that I had to put in some effort to resolve. I think the author may need to check if the published code is consistent with the correct version. I hope to achieve the results claimed by the author as soon as possible, so that I can smoothly cite it

Sorry for the delay. I’m investigating if there is something corrupted in the repo.
What installation errors were you having? we did not require any different installation than gsplat library other than added transformers and diffusers packages, is the source of errors those two?

I cloned the repository and I was able to reproduce results with the cloned code on the patio_high dataset with the following command:
results:
PSNR: 22.889, SSIM: 0.7924, LPIPS: 0.183 Time: 0.004s/image Number of GS: 862630

we had previously reported about 0.1 variance in PSNR in the paper so I think the results are consistent with the reported result of PSNR 23 in the README file.
The issue on your end might be either due to inconsistency in data format (e.g. COLMAP) or the environment set up:
For data, I am uploading the data folder to the dataset center so I can share it. I will post the link when uploaded. I suspect the prepare_data.py script might be causing inconsistencies so I am removing that script and providing the dataset directly.
For environment set up, I will try to set up an environment from scratch and see if there are any issues in the installation process but in the meantime here are the details of my current environment:
environment.txt

The dataset files are uploaded here:
https://borealisdata.ca/dataset.xhtml?persistentId=doi%3A10.5683%2FSP3%2FWOFXFT
make sure to unzip all folders (some folders are double-zipped due to upload/download restrictions on the data center)

Thank you very much for your prompt reply. After using the COLMAP pose you provided, the PSNR reached 22.74, which I believe is at the level of the article. Furthermore, I would like to inquire about your COLMAP command. My COLMAP pose generation program seems to be a bit inadequate, resulting in lower reconstruction quality.

Thank you very much for your prompt reply. After using the COLMAP pose you provided, the PSNR reached 22.74, which I believe is at the level of the article. Furthermore, I would like to inquire about your COLMAP command. My COLMAP pose generation program seems to be a bit inadequate, resulting in lower reconstruction quality.

Could you let me know if the experiment was run on Windows or Linux? The newly uploaded COLMAP pose data appears to have some formatting issues on Linux, and the image resolution in the results/renders directory also seems to be problematic.

Hi, all the experiments are run on linux. We use 1/8 resolution which should be the same as provided in the directory.
We use the multinerf framework for our colmap calculations:
https://github.com/google-research/multinerf/blob/main/scripts/local_colmap_and_resize.sh
The options that are printed are:
NerfReconstructOptions.bundle_adjuster_args =
'--BundleAdjustment.function_tolerance=0.000001'
NerfReconstructOptions.mapper_args =
'--Mapper.ba_global_function_tolerance=0.000001'
NerfReconstructOptions.matcher_method = 'vocab_tree_matcher'
NerfReconstructOptions.max_images = 10000
NerfReconstructOptions.max_images_initial_sfm_pass = 5000
NerfReconstructOptions.min_images_initial_sfm_pass = 500
NerfReconstructOptions.target_percent_images_initial_sfm_pass = 1.0
NerfReconstructOptions.use_fast_codepath = True
The project.ini for and-bot log:
[Mapper]
ignore_watermarks=false
multiple_models=true
extract_colors=true
ba_refine_focal_length=true
ba_refine_principal_point=false
ba_refine_extra_params=true
ba_global_use_pba=false
fix_existing_images=false
tri_ignore_two_view_tracks=true
min_num_matches=15
max_num_models=50
max_model_overlap=20
min_model_size=10
init_image_id1=-1
init_image_id2=-1
init_num_trials=200
num_threads=-1
ba_min_num_residuals_for_multi_threading=50000
ba_local_num_images=6
ba_local_max_num_iterations=25
ba_global_pba_gpu_index=-1
ba_global_images_freq=500
ba_global_points_freq=250000
ba_global_max_num_iterations=50
ba_global_max_refinements=5
ba_local_max_refinements=2
snapshot_images_freq=0
init_min_num_inliers=100
init_max_reg_trials=2
abs_pose_min_num_inliers=30
max_reg_trials=3
tri_max_transitivity=1
tri_complete_max_transitivity=5
tri_re_max_trials=1
min_focal_length_ratio=0.10000000000000001
max_focal_length_ratio=10
max_extra_param=1
ba_local_function_tolerance=0
ba_global_images_ratio=1.1000000000000001
ba_global_points_ratio=1.1000000000000001
ba_global_function_tolerance=0
ba_global_max_refinement_change=0.00050000000000000001
ba_local_max_refinement_change=0.001
init_max_error=4
init_max_forward_motion=0.94999999999999996
init_min_tri_angle=16
abs_pose_max_error=12
abs_pose_min_inlier_ratio=0.25
filter_max_reproj_error=4
filter_min_tri_angle=1.5
local_ba_min_tri_angle=6
tri_create_max_angle_error=2
tri_continue_max_angle_error=2
tri_merge_max_reproj_error=4
tri_complete_max_reproj_error=4
tri_re_max_angle_error=5
tri_re_min_ratio=0.20000000000000001
tri_min_angle=1.5

Could you let me know if the experiment was run on Windows or Linux? The newly uploaded COLMAP pose data appears to have some formatting issues on Linux, and the image resolution in the results/renders directory also seems to be problematic.

On ubuntu

My problem has been resolved


Artist is too large

I've got some songs that don't fit inside the database, which makes koel:sync crash after a while with :
[Illuminate\DatabaseQueryException]
  SQLSTATE[22001]: String data, right truncated: 7 ERROR:  value too long for type character varying(255) (SQL: insert into "artists" ("name", "updated_at", "created_at") values (宮
  内れんげ(小岩井ことり)、一条蛍(村川梨衣)、越谷夏&#280
  23;(佐倉綾音)、越谷小鞠(阿澄佳奈), 2016-05-03 20:58:17, 2016-05-03 20:58:17) returning "id")

Yeah, why the hell do I even have this on my library? :smile:
I was hesitant in posting the issue since it probably won't happen very often, but this is real metadata fetched from MusicBrainz, so more or less public.
I'm using PostgreSQL which AFAIK handles varying(255) roughly the same way as text, but I'm not sure about performance impacts for MySQL. For comparison, Beets uses text in its SQLite database and has no issue with this.
Koel version is 2.2.0.

You mean to say, your artist name is greater than 255 in length? :O

And the name is "宮
内れんげ(小岩井ことり)、一条蛍(村川梨衣)、越谷夏Ę
23;(佐倉綾音)、越谷小鞠(阿澄佳奈" ???

Yup, I am not even trolling! :astonished:
To be honest I never noticed it was this long since the import happened automatically and most clients ellipsisize long tags, but I've never had any issues until Koel.
The fact that koel:sync crashes and can't index the remaining files at all is a bit unfortunate, however. I could certainly update my metadata, but it seems that it could emit a warning and skip the file, or truncate the artist name.

Oh, fun. Koel is apparently storing Unicode characters as HTML entities in the database :
select name from artists limit 1;
-- 水谷広実

Is that the expected behavior or does that happen because I'm using PostgreSQL instead of MySQL?

It's the expected behavior. The database is not responsible of converting
entities for us.
On Thu, May 5, 2016 at 6:02 AM, François-Xavier Thomas <
<EMAIL_ADDRESS>wrote:

Oh, fun. Koel is apparently storing Unicode characters as HTML entities in
the database :
select name from artists limit 1;-- 水谷広実
Is that the expected behavior or does that happen because I'm using
PostgreSQL instead of MySQL?
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/phanan/koel/issues/323#issuecomment-217017499

I was thinking along the lines of "we're not sure this database supports Unicode, let's store all those characters as HTML entity codes in the ORM layer". Which seems weird because no ORM I know of does this, but I don't know much about Laravel and haven't (yet) read the source... Thanks for looking into this!

Ah, I see, in there they say :

It is suggested that for most applications you should use tag data
from the root ['tags_html'] array, as this is the only location
where data is stored in a consistant format: HTML-compatible
character entities (ie Ӓ) for characters outside the 0x20-0x7F
range (printable ISO-8859-1 characters).

...which is used verbatim in app/Models/File.php.
Wouldn't moving to the non-HTML version work? ID3v2 marks the encoding it uses, it should work in most cases.


How long/memory cost does it take to extract all slowest features for howto100m?

How long does it take to extract all features for howto100m? such as slowfast features? and how much memory are used. thanks!

Hi there,
Thanks for your interests in our HERO project. We used 2 DGX-2 nodes (2 x 16V100 (32GBs)) to extract all features on howto100m. If I remember correctly, the feature extraction costs roughly 2-3 weeks.

Closed due to inactivity


Job never run

in logcat:
D/JobProxy14: Scheduled alarm, request{id=1, tag=JobRepeatBudget}, delay 04:37:01 (+17171 days), exact true
and job never run.
I attach file db in here.
evernote_jobs.zip
Please help me!

The log says all, you scheduled the job 17171 days in the future. Not sure if you want to wait that long :)

You can see file db
I have a job scheduled at 5/1/2017
Why delay 17171 days? :(
my code:
`PersistableBundleCompat extras = new PersistableBundleCompat();
extras.putLong(JobRepeatBudget.EXTRA_BUDGET_ID,1);
    int jobId = new JobRequest.Builder(JobRepeatBudget.TAG)
            .setExtras(extras)
            .setExact(System.currentTimeMillis() + 60000)
            .setPersisted(true)
            .build()
            .schedule();'

Call setExact(60000). The documentation says:
The milliseconds specified are treated as offset from now, e.g. the job will run at {@code System.currentTimeMillis() + exactMs}.

if call setExact(60000) job do not wait to run immediately

You're saying it's still not working?

Closing because of inactivity. Feel free to reply nonetheless.


#542: added makeExecutable

Fixes: #542
Implements:

replaced default implementation of makeExecutable with an equivalent of 'chmod a+x'.
made sure that no permission changes will be applied on Windows

Pull Request Test Coverage Report for Build<PHONE_NUMBER>3
Details

0 of 0   changed or added relevant lines in 0 files are covered.
17 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.1%) to 64.768%

Files with Coverage Reduction
New Missed Lines
%

com/devonfw/tools/ide/url/model/file/UrlDependencyFile.java
1
70.0%

com/devonfw/tools/ide/io/FileAccessImpl.java
16
55.52%

Totals

Change from base Build<PHONE_NUMBER>1:
-0.1%

Covered Lines:
5732

Relevant Lines:
8541

💛  - Coveralls


docs(infrastructure): update release doc to match release candidate branching

Need update to release.md for new branching system.

Codecov Report

Merging #459 into rc0.7.x will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           rc0.7.x     #459   +/-   ##
========================================
  Coverage    96.67%   96.67%
========================================
  Files           59       59
  Lines         1984     1984
  Branches       234      234
========================================
  Hits          1918     1918
  Misses          66       66

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 63429ec...8259603. Read the comment docs.