Test/gui tests

Description
--DRAFT--
Addition of basic GUI tests.  Currently just have tests which ensure that the example files load properly (no errors) . Meant to be run with pyttest.

Contents (#113)
Uncategorised!

[TEST] add gui test basics
[TEST] add more gui tests for test datasets
[TEST] add gui test for test examples

@irahorecka @singjc Likely more tests are needed for the  GUI however I am not sure the best way to go about it since it seems like all the buttons are hidden in the classes.


Revert PR #3323 due to errors caused by client-node upgrade

Description

Due to errors in MR features caused by PR:

#3323

this PR will revert those changes, to restore main to a fully functional condition.
How Has This Been Tested?

NOTE: This PR has NOT been tested in a live cluster yet and as such is on hold until it has.
Test Impact

Request review criteria:

Self checklist (all need to be checked):

[ ] The developer has manually tested the changes and verified that the changes work
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has added tests or explained why testing cannot be added (unit or cypress tests for related changes)

If you have UI changes:

[ ] Included any necessary screenshots or gifs if it was a UI change.
[ ] Included tags to the UX team if it was a UI/UX change.

After the PR is posted & before it merges:

[ ] The developer has tested their solution on a cluster by using the image produced by the PR to main

/hold

/unhold


code clean for the Ns(none) return string.

Signed-off-by: yanggang<EMAIL_ADDRESS>Should we unify the return string ,like "NS(none)"??

Thanks!


New Device: Smart Switch

Hi
I have three of these wifi switches

Partial Support?
currently are not working under this config
{
"name": "Portátil",
"type": "Outlet",
"manufacturer": "SmartLife",
"model": "SCW NF101",
"id": "xx",
"key": "zz"
}
Additional context
raised the case in previous Tuya-lan https://github.com/AMoo-Miki/homebridge-tuya-lan/issues/112 with more context of testing but never worked
thanks in advance!!!!

Looks like you haven't specified the dpPower datapoint in your config. Please re-open this issue if relevant.


pnpm dev fail, cause: No matching export in "browser-external:url" for import "fileURLToPath"

use node.js 14.20.0
unocss v0.44.7                                                                                21:43:37
start UnoCSS in watch mode...                                                                                21:43:37
i Watching for changes in src/**/*.astro                                                                                21:43:38
   astro  v1.0.0-beta.73 started in 36ms

  ┃ Local    http://localhost:3000/
  ┃ Network  use --host to expose

  ▶ This is a  beta  prerelease build
    Feedback? https://astro.build/issues

✘ [ERROR] No matching export in "browser-external:url" for import "fileURLToPath"

    node_modules/.pnpm/rehype-pretty-code@0.3.2_shiki@0.10.1/node_modules/rehype-pretty-code/dist/rehype-pretty-code.js:4:9:
      4 │ import { fileURLToPath } from 'url';
        ╵          ~~~~~~~~~~~~~

21:43:42 [vite] error while updating dependencies:
Error: Build failed with 1 error:
node_modules/.pnpm/rehype-pretty-code@0.3.2_shiki@0.10.1/node_modules/rehype-pretty-code/dist/rehype-pretty-code.js:4:9: ERROR: No matching export in "browser-external:url" for import "fileURLToPath"
    at failureErrorWithLog (D:\Projects\gumori-you\gumori-you\node_modules\.pnpm\esbuild@0.14.50\node_modules\esbuild\lib\main.js:1615:15)
    at D:\Projects\gumori-you\gumori-you\node_modules\.pnpm\esbuild@0.14.50\node_modules\esbuild\lib\main.js:1257:28
    at runOnEndCallbacks (D:\Projects\gumori-you\gumori-you\node_modules\.pnpm\esbuild@0.14.50\node_modules\esbuild\lib\main.js:1037:63)
    at buildResponseToResult (D:\Projects\gumori-you\gumori-you\node_modules\.pnpm\esbuild@0.14.50\node_modules\esbuild\lib\main.js:1255:7)
    at D:\Projects\gumori-you\gumori-you\node_modules\.pnpm\esbuild@0.14.50\node_modules\esbuild\lib\main.js:1368:14
    at D:\Projects\gumori-you\gumori-you\node_modules\.pnpm\esbuild@0.14.50\node_modules\esbuild\lib\main.js:669:9
    at handleIncomingPacket (D:\Projects\gumori-you\gumori-you\node_modules\.pnpm\esbuild@0.14.50\node_modules\esbuild\lib\main.js:766:9)
    at Socket.readFromStdout (D:\Projects\gumori-you\gumori-you\node_modules\.pnpm\esbuild@0.14.50\node_modules\esbuild\lib\main.js:635:7)
    at Socket.emit (events.js:400:28)
    at addChunk (internal/streams/readable.js:293:12)

I don't know how to fix this,
but development and builds should be unaffected for now.
(maybe just waiting for dependency updates?)

After testing, filling ['url'] into vite.optimizeDeps.exclude seems to work.
vite: {
  optimizeDeps: { exclude: ['url'] },
  ...
}


🌹 Update travis node

Since electron 1.5 we're running node 7.4, so better to run the tests at that version? 🤔
As soon as electron 1.7 is released it will be 7.9
https://github.com/electron/electron/pull/9116
Don't know if travis has 7.4, so let's see 😄

Passed. So let's merge.


changing container version to see if anything breaks

#14

@bennypowers It appears something did break here, I don't really understand what. from the error message, any insight?

container version doesn't contain dependencies needed for project, fixing it would out scope, approved by @bennypowers


fixing a bug where ATC from CPE returned TC from ACS

Relating to https://github.com/freeacs/freeacs/issues/289

Need to add a test where i send inform with Event 10 -> empty from server -> atc from client -> atc from server. Or something like that.

dropped adding test for ATC response. instead cleaned up tests


Rename 'One-Offs' guide page to 'One-Off Commands'.

Release Playbook

[ ] Rebase against master
[ ] Code review
[ ] Merge into master
[ ] Verify changes at http://site-staging.convox.com
[ ] Promote release on site-production in the convox/production Rack

I opted for One-Off Commands as opposed to simply Commands to avoid confusion with CMD.

 Guide: Develop / One-Offs => Commands

@soulshake my understanding is that we want to rename this guide page to just "Commands." My fault for not making that clearer. Here's the guide outline I'm referencing: https://github.com/convox/site/issues/295.
If you think "Commands" is too ambiguous, let's bring it up with the team.
Looks good otherwise.

Noted.
For the record, I combined this commit with my other one, so deleting this branch/PR.


Question on how to evaluate DFF on Cityscapes(Re-inplement DFF for Segmentation)

I'm trying to re-implement your work Deep-Feature-Flow on cityscapes dataset based on Deeplab(MXNet version).
Now, I have finished the training process, while I am confused how to evaluate on cityscapes dataset(which is not clear in your paper).
Should I use the sparse annotated frames or all frames of every clip?
If for the sparse annotated frames, does it means warpping its prev-frame's feature into this frame and compare the prediction with the label?
If for all frames, how to evaluate properly?
Thanks.

For cityscapes, we will warp previous frames' feature into the frame which has ground truth, get multiple mIoU number and average them. For ImageNet VID, we just use normal evaluation approach since every frame has ground truth.

Where could I download the cityscapes dataset?

@aromazyl  https://www.cityscapes-dataset.com/

@tonysy I'm afraid that I cannot download from that site. Many thx.

@YuwenXiong  Hi, Thanks for your reply. I have implemented the evaluation on cityscapes.
I would like to know the details of result from your paper(Table 4.). For Cityscapes(l=5), DFF 69.2 in your paper, the l=5 is for training process and the dataiterator will fetch image randomly at an offset from -5 to 0. Do you use the similar random mechanism in the evaluation, or use a fixed offset in evaluation?
In my experiment, I use a fixed offset  in the evaluation, get 69.0 when l=-1, 65.4 when l=-5.
In a word, I wonder know which mechanism in your evaluation experiment(random fetch as training or fixed offset), if fixed offset, what the the exact value of l (DFF 69.2) ?
Thanks a lot!

@tonysy
Can you please share the configuration file that you used for the evaluation on cityscapes?
Thanks in advance.

@tonysy, if you worked on demo part on cityscape segmentation using DFF, pls post the scripts which would be very helpful. Requesting you kindly to do the needul.


SAK-42791 Made Sakai grader work with group assignments

 Here is an overview of what got changed by this pull request:

Complexity increasing per file
==============================
- webcomponents/tool/src/main/frontend/grader/sakai-grader.js  2
- webcomponents/tool/src/main/frontend/grader/submission.js  1

See the complete overview on Codacy


.HelmfileCommand is exposed to hooks but not exposed to other templates

Operating system
Ubuntu 22.04 LTS
Helmfile Version
0.158.1
Helm Version
3.13.2
Bug description
I can use .HelmfileCommand in hooks, which is good. However it would be very useful to use .HelmfileCommand outside hooks too.
Example helmfile.yaml
releases:
  - name: raw
    chart: https://github.com/dysnix/charts/releases/download/raw-v0.3.2/raw-v0.3.2.tgz
    hooks:
      - name: release-level
        events:
          - presync
        showlogs: true
        command: echo
        args:
          # This works
          - ".HelmfileCommand is '{{`{{.Helmfile.Command}}`}}'"
    {{ if eq .HelmfileCommand "sync" }}
    # do something, but this does not work
    {{ end }}

Error message you've seen (if any)
in ./helmfile.yaml.gotmpl: error during helmfile.yaml.gotmpl.part.0 parsing: template: stringTemplate:11:52: executing "stringTemplate" at <.Helmfile.Command>: can't evaluate field Helmfile in type *state.EnvironmentTemplateData

Steps to reproduce
N/A
Working Helmfile Version
N/A
Relevant discussion
No response

Checking the source code of Helmfile makes me believe that it would be incredibly hard to implement this. I will close this since it's not likely to happen anytime soon. And there are other things to worry about.
I am happy to reopen if someone has a different opinion.


Prepare basic user authentication in PowerAuth 2.0 admin

We should have tables used for PowerAuth 2.0 admin authentication for Spring Security:
http://docs.spring.io/spring-security/site/docs/3.2.3.RELEASE/reference/htmlsingle/#user-schema
Also, we should have settings to enable / disable security.

Maybe using something standard, such as LDAP authentication (which is quite common at banks), would be a good idea as well...

Fixed as lime-company/lime-security-powerauth-admin#4


0.0.10 - UI bugfixes

WIP PR to contain further UI fixes.

Note, FYI I'm having a hard time finding more optimizations here - over the last couple days I've stepped through and timed almost everything (albeit only on linux) and nothing seems to take more than just a few ms at most nowadays (except for initial population of cached maps, but this only happens once at client startup).
I still see freezes during blockchain sync though, so there must be something else in play (perhaps waiting for locks?) to cause it since we only do a refresh when we get blocks containing omni transactions and updating all of the UI components seems to take a couple hundred ms in total (assuming there are no changes needed to the displayed data)...
Long story short from my testing it seems we only expend a few hundred ms per omni-containing-block when syncing (and most blocks are not omni-containing) - shouldn't be enough to hang the client...
Anyway, just a heads up & i'll keep at it and try and nail this down :)

The recent changes look fine!
I think it's okay for now. With a smaller wallet, the client was already responsive, and I assume it's even better now. :)
The tests with dummy entries showed the QTableWidget itself seems to be the cause for the major lags, and unfortunally there is probably no easy optimization (except no longer using the widget).

The recent changes look fine!

Thanks dude :)

The tests with dummy entries showed the QTableWidget itself seems to be the cause for the major lags, and unfortunally there is probably no easy optimization (except no longer using the widget).

This is what has me a little stumped - I completely agree when we pump the QTableWidget with items it slows things down, but when syncing the blockchain we get freezes taking in a couple hundred blocks that don't contain any transactions affecting the wallet (thus no changes to QTableWidget should occur)...
A bit of fun can be had with --omniuiwalletscope=10 hehe, it's blazing fast then :p !!!

How/where did you see those freezes? While syncing with Qt? (not scanning?)

How/where did you see those freezes? While syncing with Qt? (not scanning?)

I see them pretty much anytime sync with QT yep...  If you're using any kind of virtualization software, snapshot and then in a few days revert to that snapshot so you've got a few days to "catch up" - you'll probably see the QT UI freeze (window greys out and goes unresponsive) several times while it catches up.
It runs perfectly once synced - it's just while catching up I see the issue.

I'm not sure, how to test this, but is it certain that these lags are related to the UI at all?
The parts that may play a role are transaction parsing and storing the file based persistence. On the other hand, but my data might be skewed somehow: while scanning/parsing on mainnet, the average time spent in parseTransaction() after the marker check was only around 1-1.4 ms.

My build with this PR has bad data:
0.00000000 MSC is shown, actual balance is 0.08125000 MSC:

Balance overview is empty (also when clicking on wallet totals):

Send from is empty:

Correct balance is shown here:

I started only a few minutes ago. Could it be that initial data fetching/UI update is missing?

That'll be my next step I think, to time non-UI functions but I'm almost
certain it's the UI because the debug window is unresponsive, but run same
test with the daemon and RPC is fully responsive...
On Jun 12, 2015 6:15 PM, "dexX7"<EMAIL_ADDRESS>wrote:

I'm not sure, how to test this, but is it certain that these lags are
related to the UI at all?
The parts that may play a role are transaction parsing and storing the
file based persistence. On the other hand, but my data might be skewed
somehow: while scanning/parsing on mainnet, the average time spent in
parseTransaction() after the marker check was only around 1-1.4 ms.
—
Reply to this email directly or view it on GitHub
https://github.com/OmniLayer/omnicore/pull/82#issuecomment-111407664.

I started only a few minutes ago. Could it be that initial data fetching/UI update is missing?

After the last block, and after clicking on wallet totals in the balance overview, the balance popped up. It's zero on the overview though.

Oh yikes!
I think it might be related to my set_wallet_totals changes since that's
now called by the block handler only when Omni transactions are present - I
must have forgotten to add one at init as well...  Sorry bud :(  I'm taking
the missus out for a much deserved dinner now (she's been really great
through the health stuff so deserves a treat he he) but I'll take a look &
fix it up tomorrow :)
On Jun 12, 2015 6:22 PM, "dexX7"<EMAIL_ADDRESS>wrote:

My build with this PR has bad data:
0.00000000 MSC is shown, actual balance is 0.08125000 MSC:
[image: overview]
https://cloud.githubusercontent.com/assets/5836089/8126192/8f51c28c-10ec-11e5-8832-5a3e686fe822.png
Balance overview is empty (also when clicking on wallet totals):
[image: totals]
https://cloud.githubusercontent.com/assets/5836089/8126203/b11c2790-10ec-11e5-9bae-f5c49a75440b.png
Send from is empty:
[image: send]
https://cloud.githubusercontent.com/assets/5836089/8126218/c714194a-10ec-11e5-8c65-93abb00fc9a1.png
Correct balance is shown here:
[image: mdex]
https://cloud.githubusercontent.com/assets/5836089/8126224/d389ad5c-10ec-11e5-83a5-36bf08a57950.png
I started only a few minutes ago. Could it be that initial data
fetching/UI update is missing?
—
Reply to this email directly or view it on GitHub
https://github.com/OmniLayer/omnicore/pull/82#issuecomment-111410549.

Aah. :)
Have a good time!

Still trying to get to the bottom of this one FYI - it's quite a strange issue - I've debugged it down to the point I can see that IsMyAddress() actually returns false for keys in the wallet when set_wallet_totals() is called from mastercore_init either directly or via msc_initial_scan - there must be some kind of order of precedence I'm not seeing here between when we init and when the keystore for the wallet is actually available to query...
Narrowing it down hehe :)

OK hopefully that should have sorted it mate :)

Argh! :)
Due to the missing BTC balance signal, the fee warning doesn't vanish after coins were received.

I've seen segfaults, when running the regtests + QT.
I think this is the first time we face locking issues in our own code, which is sort of a good thing, because it shows we're moving away from the single threaded bottleneck.
I believe it's due to the UI signals, but it's not entirely clear to me what happens, and it looks like there is more than one path to cause a segfault. Here is some information, including stacktraces and debug lines:

caused by PopulateBalances(): http://pastebin.com/raw.php?i=3eBdnvAd
caused by PopulateBalances(): http://pastebin.com/raw.php?i=n6UddeGT
caused by set_wallet_totals(): http://pastebin.com/raw.php?i=i0w42PDX

You may try to reproduce the issue as follows:
# Start with a clean state:
$ rm -rf ./bitcoin/regtest
$ ./src/qt/bitcoin-qt

# In another terminal, run the tests:
$ git clone https://github.com/OmniLayer/OmniJ.git
$ cd ./OmniJ
$ ./gradlew :omnij-rpc:regTest

# Head over to the terminal with core dump (assuming there is one):
$ gdb ./src/qt/bitcoin-qt ./core.30609
(gdb) where                # for short overview
(gdb) bt full              # for detailed stack trace

Oh my.. I have the bad feeling we need to start to use locks everywhere.
As far as I understand, cs_tally can be used to lock the globals in mastercore.cpp, which is a pretty wide scope, probably too wide actually, but anyway, I've added a lock to PopulateBalances() and set_wallet_totals(), only to see that other places, such as the MetaDEx dialogs etc. etc ...
But that aside, let's assume we start to use locks properly (we definitely should!), then I'm still wondering, if it's the right thing to do, to update all wallet balances like this.
The benchmarking on Windows showed that set_wallet_totals() is one of the biggest time consumers.
Just to provide some context, but please note this is with extensive locking:

QT with set_wallet_totals():
3 min 49 seconds + more than 1 minute UI freeze on top

QT without set_wallet_totals():
2 min 38 seconds

Daemon with set_wallet_totals():
2 min 33 seconds

Daemon without set_wallet_totals():
2 min 25 seconds

I've tested to use a signal to initiate the balance update, but unfortunally this had a side effect: the balances are updated asynchronously, and even after the tests finished, the updates kept pouring in.
This attempt can be found here:

https://github.com/dexX7/bitcoin/compare/24004e09749c15c46ef367b0436c58ab29eddc31...dexX7:24efa944cf03f2a90264fbc9c424ec0d4d01d203

And with overly extensive use of locks (should not be done this way!), and a first step to move Omni Core related things into a new model:

https://github.com/dexX7/bitcoin/compare/24004e09749c15c46ef367b0436c58ab29eddc31...dexX7:54c00ded3ff7455acf6f5468c318669feb4fc43d

Argh! :)  Due to the missing BTC balance signal, the fee warning doesn't vanish after coins were received.

Shoot - good catch...  We may still need the wallet model for BTC change notifications in send and metadex dialogs - I'll take another look...

The benchmarking on Windows showed that set_wallet_totals() is one of the biggest time consumers.

With a large wallet?  The larger the wallet the longer this takes I believe...

Just to provide some context

So just to confirm, on the daemon set_wallet_totals does not actually add a large overhead, but on QT it does?

With a large wallet? The larger the wallet the longer this takes I believe...

Yeah, the benchmarking was done with a larger wallet (but only 3-4 properties owned). I didn't test the updated code though.

So just to confirm, on the daemon set_wallet_totals does not actually add a large overhead, but on QT it does?

Correct.
I assume it's due to secondary effects: on the overviewpage, and sendmpdialog, the globals are used to initiate other actions, such as updating property balances or the property selector. And this code isn't executed in the non-UI runs.

Yeah, the benchmarking was done with a larger wallet (but only 3-4 properties owned). I didn't test the updated code though.

I believe larger wallets hurt us all round at the moment...  FYI set_wallet_totals makes extensive use of IsMyAddress() which does a keystore lookup for each address in mp_tally_map - I haven't timed it but my assumption would be the larger the keystore the slower set_wallet_totals will be...

I assume it's due to secondary effects: on the overviewpage, and sendmpdialog, the globals are used to initiate other actions

The globals shouldn't initiate anything - set_wallet_totals should now only run once per block and only then if there were Omni transactions within the block.  That shouldn't be any different between daemon and UI...

set_wallet_totals

During the RPC tests set_wallet_totals is 1549x called, and the average time spent during each call is 6.059 ms, and in total 9.383 s. This roughly matches the difference between non-UI run with, and without set_wallet_totals().

The globals shouldn't initiate anything

I was referring to the following parts:

OverviewPage::updateOmni()
SendMPDialog::updatePropSelector()
BalancesDialog::UpdatePropSelector()

If the globals are not filled, then these will have less work to do.

If the globals are not filled, then these will have less work to do.

Ahh, that makes sense...
Also I noticed on another of your commits about set_wallet_totals only being applicable to the UI - I just wanted to note that it's currently only applicable to the UI, but I think it can also be beneficial on the RPC layer - just the same as how you can retrieve the wallet balance over RPC for bitcoin, at some point I'd like to drop in wallet balance calls for Omni into RPC.

During the RPC tests set_wallet_totals is 1549x called, and the average time spent during each call is 6.059 ms, and in total 9.383 s.

Perhaps it's just me, but I don't see that as a major problem...
If set_wallet_totals is called 1500 odd times, that means we've processed some 1500 blocks containing Omni transactions - if that were on mainnet script verification would have eclipsed that 9.383s.
I don't want to miss the point, but this says to me we're looking at 10 seconds of compute for 10 days worth of blocks (1440) assuming every single bitcoin block mined contains Omni data - forgive the Q but - is that an issue?

Perhaps it's just me, but I don't see that as a major problem...

Hehe, sorry. We're talking across a bit right now, I think. :)
I initially assumed set_wallet_totals directly causes the delays, and if we're going to update the balances for each pending transaction, too, then I assumed this would make the issue twice as worse (in the worst case). This doesn't of course mean it's not the right thing to do.
Now that it's clear the wallet balance updates play only a minor role, I'm a lot less concerned. (I time tested it only a few minutes ago.)

OK cool :)
I am concerned about the segfaults you were seeing though :(

With the following changes the segfaults seem to be resolved:

https://github.com/dexX7/bitcoin/compare/886fe553fe70a8aea569c94a78a81aecf9ed94be...dexX7:be772d8581d354b67e392920470399a75ffd3d4d

However, and this is a bit odd, the time to run the regtests took 3:34 min (about a min longer than non-UI), but 3:38 min on top until the UI freeze was over. I messured it by triggering a shutdown via strg+c (or bitcoin-cli stop), and then waited for the actual shutdown.

Heh, I was working on similar changes re the property list :)

It looks like the time on top, where the client remains frozen, is spent to catch up with the updates. I'm currenty logging all relevant calls, and after the tests finished, balancesUpdated, UpdateOffers, UpdateHistory, ... were only half way through.

I'm working on something I think should really, really help this whole process out and optimize significantly - will push soon :)

Thanks heaps for the numbers, it will be interesting to see how they come up after this latest optimization :)

Hehe, now I'm really curious! :)

Let me know what you think :)

Give me a few minutes to test it! :)

Wooho, time doiwn to 02:41 min + 39 seconds freeze on top.

Wooho, time doiwn to 02:41 min + 39 seconds freeze on top.

Is that compared to a or b mate?

a) Time for tests:        04:26 min
b) Time until shutdown:   07:58 min (+ 03:32 min)

To compare:
Time for tests:        02:41 min
Time until shutdown:   03:20 min (+ 00:39 min)

In other words:
After 2:41 min the tests finished, but it took 39 seconds on top until the client was responsive and successfully shutdown, and in total that's 3:20 min. :)
The number from above is slightly higher due to heavy debug printing, but not very much, I think.

Alright, excellent :) thanks heaps for the timing info mate, I'm really glad it seems to be working out well :)

Right now there are freezes, because the arrival rate of new jobs/signals fired is higher than the service/processing rate, or put in other words: the UI can't simply keep up. Once the queue clears, the freeze resolves. Is that correct so far?
I'm wondering: if we could drop new jobs, which are going to be superseded anyway by newer jobs, then we may prevent the forming of a queue right from the start.
A simple approach could be to set a flag to indicate "there is something currently being processed", and that flag could be cleared, once the processing finished. If the flag is set and a new job arrives, the job is ignored.
This is probably not sufficient, and it should be ensured that the latest state is up-to-date (and the latest update request wasn't dropped).
Would that work and make sense?

I'm wondering: if we could drop new jobs, which are going to be superseded anyway by newer jobs, then we may prevent the forming of a queue right from the start.

That's something we could research sure - basically we're queuing up QT messages so if there is some way to say when we emit a signal "if this signal is already in the message queue, don't duplicate it" then that would certainly be a good step...

An alternative to the init.cpp update:
diff --git a/src/init.cpp b/src/init.cpp
index f562ab9..1c06213 100644
--- a/src/init.cpp
+++ b/src/init.cpp
@@ -74,7 +74,6 @@ CClientUIInterface uiInterface;
 // Omni Core initialization and shutdown handlers
 int mastercore_init();
 int mastercore_shutdown();
-void CheckWalletUpdate();

 //////////////////////////////////////////////////////////////////////////////
 //
@@ -1288,10 +1287,6 @@ bool AppInit2(boost::thread_group& threadGroup)
                 }
             }
         }
-
-    // Omni Core code should be initialized and wallet should now be loaded, perform an initial populate of Omni balances and cache
-    CheckWalletUpdate();
-
     } // (!fDisableWallet)
 #else // ENABLE_WALLET
     LogPrintf("No wallet compiled in!\n");
diff --git a/src/qt/overviewpage.cpp b/src/qt/overviewpage.cpp
index bbe3876..7c7239d 100644
--- a/src/qt/overviewpage.cpp
+++ b/src/qt/overviewpage.cpp
@@ -397,6 +397,9 @@ void OverviewPage::setWalletModel(WalletModel *model)

         updateWatchOnlyLabels(model->haveWatchOnly());
         connect(model, SIGNAL(notifyWatchonlyChanged(bool)), this, SLOT(updateWatchOnlyLabels(bool)));
+
+        // Omni Core code should be initialized and wallet should now be loaded, perform an initial populate of Omni balances and cache
+        CheckWalletUpdate();
     }

     // update the display unit, to not use the default ("BTC")

I think the concept of wallet totals will be extended to the RPC layer (at the moment you can't ask RPC a simple question like "how much MSC do I have?") so that initial population probably needs to stay outside the UI :)

how much MSC do I have?

Like: "how much MSC do I have in total"?
I'm not entirely convinced, because a command like this would likely try to update the cache, too, instead of blindly returning some numbers. But I also don't object to the update via init.cpp for now.

That's a fair point - I guess I was going for keeping the balance controlled by the core and having UI & RPC consume, rather than trigger balance updates - but of course it's all up flexible right now :)

I guess I was going for keeping the balance controlled by the core and having UI & RPC consume, rather than trigger balance updates

Ah, that's very well put, and I like this way of thinking. :)

FWIW an overview of the current event sytem:

https://gist.github.com/dexX7/61a0a405f17af3b70f14

Just as quick remainder:
With -debug=ui:
UpdateTip: new best=36d95cfd2015586b6c21808e26d3f00f0eb4606e072d500ce26b3e..
AddToWallet 731c2eed0b0fcce7bdf00f88de0bb1b180838a31754fb4b06269290b6dfa1d94  new
keypool return 1182
GUI: QTableWidget: cannot insert an item that is already owned by another QTableWidget
GUI: QTableWidget: cannot insert an item that is already owned by another QTableWidget
...
AddToWallet d3d3ffc1c1ea1a54cb33c244f1092bf68e611d239ad47831244adc4051fb3705  new

Ahh yes, thanks dude I'll look into that in a bit - I'm just running some tests for P2SH for Craig because he mentioned some things had stopped working in 0.0.10 - I'll CC you in on my response to him mate to keep you in the loop :)

P2SH

That's interesting. Please forward everything you have! :)

Just as quick remainder:

Did you happen to notice what was being updated?

It's triggered once a block confirms, and I think it's related to the trade history.

Alrighty, thanks dude :)

It's caused by cancel-trade transactions (and not by sends or trades).

Ahh that helps thanks, I was having trouble replicating :)

It might not be written to the debug.log without -debug=ui, or maybe even -debug=1.

Note, I'm seeing some quite strange behaviour :( so I'll be giving the MetaDEx UI a bit of a going over tomorrow and hopefully clean it up a bit.

strange behaviour

What do you see?

What do you see?

Duplicate trades in history with bad data
Missing trades
Cancel trades showing as new sells
Lack of updates to history when sending a cancel transaction
Lack of pending support when sending a cancel transaction (likely cause of above)
Duplicate parsing where viewing a trade parses several times

In a nutshell I think I must have thought the MetaDEx UI was in better shape than it actually is - none of the problems are major, just bugs that I'll need to hunt down and figure out, so I'm giving myself a dedicated day tomorrow to focus purely on MetaDEx UI (I bounce between too many different things at the moment) and give it a good clean up :)

Urgh.. :)

Yep :)

I know there is still work to be done on the "minimum fee warning", but the fee in general seems to be quite a bit higher than necessary:

I'll take a look at the fees after I finished the SP serialization. :)
Are those amounts shown in the picture the fees?
Which settings do you have in Send - Bitcoin - Transaction fee?

I'll take a look at the fees after I finished the SP serialization. :)

Sure sure dude, just wanted to note it so I didn't forget about it hehe

Are those amounts shown in the picture the fees?

Left at defaults because that's how end users are likely to use it - but seems unusually high

Hm...

the fee in general seems to be quite a bit higher than necessary

As far as I understand, with this setting the fee selection is up to the wallet.
Let me rephrase: do you think the fees are unexpected and too high, or do you think the wallet fee selection should be smarter?

do you think the fees are unexpected and too high, or do you think the wallet fee selection should be smarter?

Well, perhaps I've misunderstood things but 6K to 10K satoshi mining fee seems well over the top, when an average transaction used to be a flat 1K?

P.S. even with a 6K fee on my latest test tx (72baa1f2af9886d810b679a2d8e4b5928f89804b43f8776d0d365d1a3eaf16f7) it's been unconfirmed for 10 blocks already hehe

0.00006060 BTC isn't very high imho.
Via the RPC command estimatefee n the fee estimation can be retrieved, where n is the confirm target in blocks, and the value is per 1000 byte. If the result of estimatefee roughly matches the fees you paid, then it's indeed the auto fee selection by the wallet.

Not crazy high nope, but does highlight the other approach for the minimum warning is invalid (as that's always works out to 2600 satoshis, which is not sufficient to send).  Will loop back around to the fee issue...

Hey @zathras-crypto, I would like to start merging the outstanding PRs. Could you please signal, if there is anything that should be held back? In particular I was thinking about this one + #74, ideally #88, too, to increase the exposure.

Hey @zathras-crypto, I would like to start merging the outstanding PRs. Could you please signal, if there is anything that should be held back? In particular I was thinking about this one + #74, ideally #88, too, to increase the exposure.

Hey bud, yeah we need to merge everything in because @CraigSellars wants release candidate binaries basically yesterday hehe...
Let me step through these outstanding ones again and see where we're at :)

Hey there!

we need to merge everything in because @CraigSellars wants release candidate binaries basically yesterday hehe...

This is going to be interesting, hehe. Is he looking for a release candidate or a preview? What's the target audience?

Is he looking for a release candidate or a preview? What's the target audience?

Something people can get their hands on and start playing with for testing purposes.  @CraigSellars can you advise on target audience?

Alright. I'm currently building dependencies via Gitian, but I won't wait until it's finished (it takes hours.. usually hehe).
So just to confirm: all PRs are good to go, in your opinion?

So just to confirm: all PRs are good to go, in your opinion?

I wouldn't say that mate - I'm sure they'll be fine and 0.0.10 is still development but I'd like to review - I'm just working regtest and this UI reorg thing and then I'll switch gears and start reviewing your outstanding PRs mate (which I'm sure will be stellar :) )

Hehe, thanks. We'll see. I think there might be one or two things you won't like (me neither! -> "prefix"). :)
Just let me know, I'm very curious how it all fits together.

This regtest stuff is definitely easier than I thought haha - can't believe I procrastinated so long!
First issue I'm coming up against is after mining 101 blocks and then sending some BTC to moneyqman and then mining more blocks, I don't seem to get any MSC generated...  Looking into it now...

IIRC Exodus purchases don't go well with the UI, for some reason. It helps to check the log, and use the RPC console to get more information.
If all this doesn't help, then you could quickly edit your bitcoin.conf
server=1
rpcuser=bitcoinrpc
rpcpassword=pass
rpcallowip=<IP_ADDRESS>
txindex=1

And start QT. Then, from anywhere:
git clone https://github.com/OmniLayer/OmniJ.git
cd OmniJ
./gradlew :omnij-rpc:regTest

... and stop inbetween, so your wallet has some MSC. It might be necessary to mine a block afterwards via setgenerate true 1.
The issue I initially described can be reproduced by creating a bunch of Omni transactions, and then invaliding a very early block, say:
./src/bitcoin-cli getblockhash 1
...
./src/bitcoin-cli invalidateblock [hash]
./src/bitcoin-cli setgenerate true 1

I whipped up this quick script:
cat regtest.sh
#!/bin/sh
src/bitcoin-cli --regtest setgenerate true 101
src/bitcoin-cli --regtest getnewaddress
echo "Please enter the new address: "
read addressvar
src/bitcoin-cli --regtest sendtoaddress $addressvar 10
src/bitcoin-cli --regtest setgenerate true 1
src/bitcoin-cli --regtest setaccount $addressvar "TESTACCOUNT"
src/bitcoin-cli --regtest sendfrom "TESTACCOUNT" moneyqMan7uh8FqdCA2BV5yZ8qVrc9ikLP 9
src/bitcoin-cli --regtest setgenerate true 1
src/bitcoin-cli --regtest getbalance_MP $addressvar 1

Which should basically mine some coins, send then to a new address, then send from that new address to moneyman and generate some MSC.
[
...bunch of blocks...
]
mkdCV1MB6fkxNNi9zr7FxmYV9ubQmbBVCr
Please enter the new address:
mkdCV1MB6fkxNNi9zr7FxmYV9ubQmbBVCr
94ca0eeab5b6c2d485e6b94c3a7f35c9a6617afad58d69f8a096336e35c11560
[
    "16fd31e14940abc474b6f92364860ed7dd6e06928841dfb4563602000e7cd6ed"
]
3c9f270100f7248805fa9e8b0c3bed184d672c72b2dfbcb47f2e5d8d7c2a635f
[
    "26b2364061f7ea73524cae1946d8b220a4241f3e32466c64ca218c5a13b6066f"
]
{
    "balance" : "900.00000000",
    "reserved" : "0.00000000"
}

So it seems to be working now - not sure what the issue was earlier.

The issue I initially described can be reproduced by creating a bunch of Omni transactions, and then invaliding a very early block

Thanks dude, I'm just spinning up a test scenario now so I can test properly myself :)

P.S. this is uber cool :)  I always thought I'd lose a whole bunch of productivity deviating away to play with regtest but now I think I'm going to see a whole lot of benefit from it :)

not sure what the issue was earlier

It could also be that coinbase coins were used earlier, which don't count.
Anyway, have fun! It's probably going to make you much more productive. :)

I think this can probably be merged in now to get consolidation moving...

Awesome!  :)
Quick note, it doesn't pass the RPC tests, when run locally on my machine. With lock debugging:
POTENTIAL DEADLOCK DETECTED
Previous lock order was:
 (1) cs_tally  qt/metadexdialog.cpp:387
 (2) cs_main  omnicore/omnicore.cpp:160
Current lock order is:
 (2) cs_main  main.cpp:3123
 (2) cs_main  main.cpp:2213
 (1) cs_tally  omnicore/omnicore.cpp:308
AddToWallet eddcca1353d001444ecf480ec48703a395480205e976ac516c55277648c04800  new

I'll take a look at it now.

@zathras-crypto:
Would it be complicated to attach the hourglass for pending transactions to the left? (... and make sense for you?)
When running the tests, it jumps back and forth the whole time, moving the other icons on the right around.

@zathras-crypto:
Would it be complicated to attach the hourglass for pending transactions to the left? (... and make sense for you?)
When running the tests, it jumps back and forth the whole time, moving the other icons on the right around.

Hmm, to the left of the status bar or to the left of the other icons?  Shouldn't be too much trouble nope :)

You can try this, but I don't think it looks "right"
diff --git a/src/qt/bitcoingui.cpp b/src/qt/bitcoingui.cpp
index 03a7860..6395171 100644
--- a/src/qt/bitcoingui.cpp
+++ b/src/qt/bitcoingui.cpp
@@ -181,6 +181,8 @@ BitcoinGUI::BitcoinGUI(const NetworkStyle *networkStyle, QWidget *parent) :
     if(enableWallet)
     {
         frameBlocksLayout->addStretch();
+        frameBlocksLayout->addWidget(labelOmniPendingIcon);
+        frameBlocksLayout->addStretch();
         frameBlocksLayout->addWidget(unitDisplayControl);
         frameBlocksLayout->addStretch();
         frameBlocksLayout->addWidget(labelEncryptionIcon);
@@ -190,8 +192,6 @@ BitcoinGUI::BitcoinGUI(const NetworkStyle *networkStyle, QWidget *parent) :
     frameBlocksLayout->addStretch();
     frameBlocksLayout->addWidget(labelBlocksIcon);
     frameBlocksLayout->addStretch();
-    frameBlocksLayout->addWidget(labelOmniPendingIcon);
-    frameBlocksLayout->addStretch();

     // Progress bar and label for blocks download
     progressBarLabel = new QLabel();

P.S. how do you paste your diffs in colour?

Ah, let me try this in a few minutes.
The highlighting:
-    deleted
+    added

Can be done by adding "diff" to "```diff":
'''diff
-    deleted
+    added
'''

Where ' is actually: `
https://help.github.com/articles/github-flavored-markdown/#syntax-highlighting

The highlighting

Brilliant, thanks for the tip :)

Hmm.. so you don't like the second one with the text?
I kinda like it, especially with the text it's very visible and good to notice.

Hmm.. so you don't like the second one with the text?
I kinda like it, especially with the text it's very visible and good to notice.

The first one I didn't like (to the left of icons) so I took a stab at a different approach which was the second bit - I actually kind of like it too :)  I'll commit it then :)

Nice!

You have Omni transactions pending confirmation

This sounds slightly twisted to be, due to the "pending confirmation", because I usually refer to "pending transactions". Is that wrong?

The tooltip is slightly different ("awaiting confirmation" rather than "pending confirmation", do you think that's better wording?
Perhaps we should include 'sent' or 'outbound' or similar?  Do any of these sound right to you?

"You have Omni transactions awaiting confirmation."
"You have Omni transactions pending confirmation."
"You have recently sent Omni transactions that are awaiting confirmation."
"Your sent Omni transactions are awaiting confirmation."
"Sent Omni transactions are awaiting confirmation."

Any other suggestions, feel free bud :)

The first two sound best:

"You have Omni transactions awaiting confirmation."
"You have Omni transactions pending confirmation."

So let's go with the first, I'd say?

So let's go with the first, I'd say?

Sure, agreed :)


Crashed after 1-5-10 mins

Problem after playing game. using i7-7700k, gtx 1080
crashing after 1-5-10 min
x64 win, r.c for 1.5
cyber_engine_tweaks.log

Note: potential d3d12 memory leak caused by resizing the viewport too many times

@yamashi I think that's how it is. I enabled UseD3D8to9 in global.ini and the crashes stops

Wow that's weird, have no idea how this could cause issues but thanks a lot for reporting this, I will try to understand what's going on

Likely fixed by newer hooking method


A small bug when running evaluate_line_detection.py

Hi,
When running evaluate_line_detection.py, an IndexError occurs due to match_lines().
The my_matches array of type float, because the pytlbd.lbd_matching_multiscale() also returns descriptor distances.
So would raise IndexError: arrays used as indices must be of integer (or boolean) type
To fix this issue, replace line 66 with:
pred_matches[my_matches[:, 0].astype(np.int32)] = my_matches[:, 1].astype(np.int32)

Finally, Your work has been incredibly helpful to me.

Thanks a lot for reporting it, I just pushed the change: https://github.com/cvg/DeepLSD/commit/6593ead5970a7145c22480f5580c91f344a9422e


Issue #59 - Babel 6 Upgrade

As per issue: .babelrc incompatible with Babel 6 #59
Bebel 6 has been integrated, Stage-0 has been added, React and Webpack have also been updated.
In addition webpack configuration files have been slightly tweaked and adjusted to babel 6 changes.
Currently the Autocomplete.jsx file is disabled due to bug in babel https://phabricator.babeljs.io/T6712
Aside from toolbox-loader, and excluding highlight & sinon, everything else has been updated.
With all test passing this pull is now complete.

This is great. The only thing that I don't like is the need to disabled Autocomplete component. I think it should be fixed before merging so we can have the dev branch working nicely and ready to merge at any point. What do you think? It's going to take too long, is there anything that can be changed to avoid the bug?
Thanks @Bartekus great work!

I'm looking into fixing Autocomplete but after taking two days off I'm only getting back into it now so a little bit more time is needed before I come up with a solution. Thank you for patience and stay tuned!

what is the problem in autocomplete ??

The problem is this:
SyntaxError: components/autocomplete/Autocomplete.jsx: "suggestions2" is read-only (This is an error on an internal node. Probably an internal error. Location has been estimated.)

and it relates to this: https://phabricator.babeljs.io/T6712

Unfortunately at the moment I'm lacking skills to fix this problem properly and hacking it into passing a test won't guarantee artifact-free operation hence I'd like to sway away from that option.
I will monitor the open tickets for the solution on the babel side and implement the solution as soon as one is found.

Great, don't worry! :)

Keeping the books in order: this also fixes #230.

Fixed and merged! Thanks everybody! :D


Do not require a project_config when a local_config is present

It doesn't clearly state that a molecule.yml is required either. IMHO putting that info into the Config File section may be more irritating than helping, since that passage is supposed to be an introduction for people that are new to Molecule.
When I first tried to use a ~/.config/molecule/config.yml only, I was surprised that threw an error. So IMHO it is more intuitive to not require a project molecule.yml if all required settings are already present in the global one.

It doesn't clearly state that a molecule.yml is required either. IMHO putting that info into the Config File section may be more irritating than helping, since that passage is supposed to be an introduction for people that are new to Molecule.

You're adding new functionality.  I'd like it documented that you can leave it out and it comes from local.


Dummy records should be AAAA pointing to 100::

Fixes #160.

This looks great, thanks.
My only question is about this section on the Routes page:
https://github.com/cloudflare/workers-docs-engine/blob/028ecceb3f698342cdba633c011470afd8716913/src/content/platform/routes.md#L106-L108
Is that related and should it be updated too?


Not adding prison sentence to the prison sentences

Not sure if I put the export in the wrong place or not, but it is not putting the prison sentences on the tab on the newspaper. I have used /jail and sent from ps-mdt. below I will screen shot where i put it. everything else works such as publishing stories and viewing
I use Rcore-prison which i know they added the support for it now. Didn't know if i had to do something with rcore for it to work?

Did you check that it gets set into your database?


suggestion / idea

gvt is nice and simple to use, which is the point
The other thing i need to do is handle binary dependencies, that need to be shared etc.
with git there is the ability to do that.
But i think later it might be worth dong it with S3 and minio.
Here are my 2 bash scripts that do it, so show the idea
Merge DOWN:

# minio (for s3)
go get -u github.com/minio/mc

# Get binary tools

LOCAL=$GOPATH"/src/bitbucket.org/XXX/toolbin/"
REMOTE=s3/appdif-dev-toolbin

echo "LOCAL: " $LOCAL
echo "REMOTE: " $REMOTE

echo "Doing a Difference of Local against Remote ..."
mc diff $REMOTE $LOCAL

read -n1 -r -p "Press 'y' to start mirror with Remote (S3) ? " key

if [ "$key" = 'y' ]; then
    # `y´´ pressed, do something..
    echo ""
    echo "Mirroring files from REMOTE down to LOCAL"
    mc mirror --force --remove $REMOTE  $LOCAL
else
    # Anything else pressed, do whatever else.
    echo ""
    echo "No action taken."
fi

Merge UP:

# minio (this pushes it into the golang bin, and so accessable on terminal)
go get -u github.com/minio/mc

# Get binary tools

LOCAL=$GOPATH"/src/bitbucket.org/XXX/toolbin/"
REMOTE=s3/appdif-dev-toolbin/

echo "LOCAL: " $LOCAL
echo "REMOTE: " $REMOTE

#echo "# ls LOCAL"
#ls -l $LOCAL

#echo "# ls REMOTE"
#mc ls $REMOTE

echo "Doing DIff of Local against Remote ..."
mc diff $LOCAL $REMOTE

read -n1 -r -p "Press 'y' to start mirror with Remote (S3) ? " key

if [ "$key" = 'y' ]; then
    # `y´´ pressed, do something..
    echo ""
    echo "# Mirroring up to REMOTE, and deleting any files on Remote(S3) that are not on local."
    mc mirror --force --remove $LOCAL $REMOTE
else
    # Anything else pressed, do whatever else.
    echo ""
    echo "No action taken."
fi

The Other idea is to watch for changes in external repos, based on your vendor list.
shurcooL has been writing a few tools for this. This is one of then.
go get -u github.com/shurcooL/gostatus
Some thing like the 2 ideas above might be cool. Might be overkill too.

Hi, thanks for contributing ideas! The first one I think is a bit out of scope as you imagined, the second one seems addressed by gvt update -all, followed by a git checkout to revert in case.


something is fishy with the assignments SUBMITTABILITY in Round 15 - part A

almost sure, that some of these assignments (Round 15 - part A) must be submittable

the solution that seems to work (@oseppala has 20 submissions):
    /**
     * Returns {@code true} if the exercise is submittable from the plugin, {@code false} otherwise.
     */
    public boolean isSubmittable() {
        // O1_SPECIFIC
        String name = getPresentableName();
        int maxSubmissions = getModel().getMaxSubmissions();
        return name.length() > "Assignment xx (".length()
                && !"Assignment 1 (Piazza)".equals(name)
                && !"Assignment  debugger".equals(name)
                && (maxSubmissions == 10 || maxSubmissions == 0 || maxSubmissions == 20);
    }

0 for non-submittables
5 for quizzes

5 for the others @oseppala

a custom submittability check must be created once @oseppala has set up initial exercises for the course

what if all the assignments are submittable by default, and then the teacher only marks the non-submittables

what if all the assignments are submittable by default, and then the teacher only marks the non-submittables

Suggestion from the meeting:
In the course config file: an assignment is submittable if exerciseModules contains the assignment. For assignments without basecode, add empty JSON object {} there for the assignment's id to make it submittable.


listen_port and listen_host options have no effect

Steps to reproduce the problem:
options have no effect when set on the command line

mitmproxy --set listen_port=1234
lsof -iTCP -sTCP:LISTEN -P | grep python
mitmproxy is still listening on port 8080

options have no effect when set in the ui

mitmproxy
set listen_port option at runtime (pressing O)
ui shows *.1234, lsof still shows port 8080

the same appears to be true for listen_host (bound to *. when set to listen on loopback only)
System information
Mitmproxy: 3.0.3
Python:    3.6.4
OpenSSL:   OpenSSL 1.0.2n  7 Dec 2017
Platform:  Darwin-17.3.0-x86_64-i386-64bit

@bugreport998 the command to set the listen port is mitmproxy --listen-port [PORT] and it is working perfectly fine, you can check mitmproxy --help for that. I will take a look at setting listen port using UI. :)

Thankyou for the quick response to this issue. Using --listen-port does work as expected :)
I think It's a little unintuitive that --set for those options doesn't work where there is a seperate --listen-port switch
That is a little strange because the UI updates to reflect the setting for listen_port and listen_host (when set with --set).

launching mitmproxy with --set listen_port=1234 --set listen_host=<IP_ADDRESS> also reflects that option in the options UI

If --listen-port 1234 and --set listen_port=1234 behave differently, that's definitely a bug.

@mhils was --set listen_port=1234 supposed to work. Also, how does the port changing work here when we set it using console UI option, does it closes the connection and then reopens at the specified port?

listen_host and listen_port cannot be changed during execution at the moment (that's a separate bug I guess) - maybe that's the same issue here, although we should update settings before spawning a server.

Yes, we have two issues here - the fact that the proxy component doesn't rebind on change, and the fact that command-line options are apparently not applied before the proxy initially binds. I'm in the process of refactoring this part of our codebase, and both of these issues should be fixed by the time I'm done.

I did try changing listen_port and listen_host and then toggling the 'server' option - that is what seemed intuitive to me as a user. It might make more sense to make the user (but tell them!) that they need to bounce the proxy themselves rather than tearing down an active proxy that might otherwise be in use.

The proxy now rebinds on master! :)


Add argo_spec variable

Argo spec

Consolidate variable names:

argo_application_enabled -> argo_enabled
argo_application_use_helm -> argo_helm_enabled
argo_application_values -> argo_helm_values

Stress the fact that argo_helm_* variables are related to the "dummy" helm chart that is used to deploy the application object in their description.
--
Add another deep merge for argo_spec and argo_helm_values.spec to enforce passing application object specs through argo_spec only, and still allow to pass additional variables to the dummy helm chart like name overrides, etc.

Work should be done in https://github.com/lablabs/terraform-aws-eks-load-balancer-controller/pull/7,


Filter for null values

Hi
I'm trying to filter for null values but its not returning anything.
eg. /tasks?filter[task_user_id]=null is not working
Any idea how to get this working?

@RitterNorbert by default JR filters does not handle null filter,
but you can override this behaviour easily using verify or apply filter option.
for example:
class TaskResource < JSONAPI::Resource
  filter :task_user_id, verify: :nullable_filter

  def self.nullable_filter(values, _context)
    values == ['null'] ? nil : values
  end
end


Smart select

Highlight the "top priced" item among all recognized rewards.

implemented https://github.com/WFCD/WFinfo/releases/tag/v9.2.3


Navigation: screencast

Showing the new side bar, also a deep dive under the covers in a second, tech video.

Published here: https://waltz.finos.org/blog/waltz/navigation/screencast/2021/08/19/nav-user.html


when gorm not connected to any DB; the  query execute  result has no error

GORM Playground Link

https://github.sheincorp.cn/go-gorm/playground/pull/1
Description

when gorm connect to a wrong dsn config, and ignore the open error handle,
all after db exec don't have result error
DB, err = gorm.Open(mysql.Open(dsn), gormConfig) // dsn is wrong ,and the err is  failed to initialize database, got error dial tcp xxx:3306: i/o timeout
result := DB.Exec("SELECT 1")
if result.Error != nil { // why the result error is nil
	fmt.Println("%v", err)
}

I know i should handle the gorm.Open error. but i want to get my program startup when db is down.
so i tried to  ignore the open error, but the db execute with no error result in some other issue.
hope db execute can result error

When gorm.Open return an error(the second return value), the gorm.DB instance(the first return value) should never be used.
Using an invalid gorm.DB instance is undefined behavior(as no one would ever do this) so the result could be anything(for example, in your case, return err=nil when calling Exec method).
Hence, I think you should change your codes to handle the error properly, if there is an error returned from gorm.Open, stop using the returned gorm.DB instance.

When gorm.Open return an error(the second return value), the gorm.DB instance(the first return value) should never be used. Using an invalid gorm.DB instance is undefined behavior(as no one would ever do this) so the result could be anything(for example, in your case, return err=nil when calling Exec method). Hence, I think you should change your codes to handle the error properly, if there is an error returned from gorm.Open, stop using the returned gorm.DB instance.

I know i should handle the gorm.Open error.  But my goal is just want to start my program as a downgrade solution even when the database cannot be connected

When gorm.Open return an error(the second return value), the gorm.DB instance(the first return value) should never be used. Using an invalid gorm.DB instance is undefined behavior(as no one would ever do this) so the result could be anything(for example, in your case, return err=nil when calling Exec method). Hence, I think you should change your codes to handle the error properly, if there is an error returned from gorm.Open, stop using the returned gorm.DB instance.

I know i should handle the gorm.Open error. But my goal is just want to start my program as a downgrade solution even when the database cannot be connected

Then in your downgrade solution, you must not use the gorm.DB instance


Milestone 4 To Dos

High Priority

4 Docker Files (Pooled into One)
Docker Hub Repository
Update README.md:
a) Add Makefile dependency diagram
b) Docker instructions

Low Priority

Captions in Final Report
Round tables to 2 sig figs
Set diagonal values on correlation map to 0 or nan
Other figure tweaks from feedback
Download script tests/asserts

Most feedback changes have been made. All that is left is to add figure captions, which I'll address now

Feedback has now all been addressed.


Hamburger isn't a good ui element for webview

Description
Normal navigation is missing. Clicking on hamburger icon and viewing different navigation option is used where we have less space available on the screen.
Screenshots/testimonials

Can we discuss what can we show on the navigation bar of HG v2.0?

These are the few sections that we are planning to came up with in hg v2.0

Home
Resources
Projects
Blogs
About

Here is the simple lo-fi wireframe of the nav bar that I came up with.

We can implement colors and icons once we create a style guide for hg v2.0

As of now it looks good to me. We'll make this changes when we update the website.
Thank you


Add optional gas multiplier config to allow for increased fee distribution

Default multiplier is 1.0, so this has no effect unless configured to do so
Can set maximum number of gas multiples per day, default is 1000, count resets every 24 hours after startup time (just in-memory tracking, nothing fancy)

Codecov Report

Merging #50 (d0ecd9b) into main (7897d78) will decrease coverage by 0.05%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##               main      #50      +/-   ##
============================================
- Coverage     11.62%   11.57%   -0.06%
  Complexity       35       35
============================================
  Files            65       65
  Lines          3407     3422      +15
  Branches        358      359       +1
============================================
  Hits            396      396
- Misses         2955     2970      +15
  Partials         56       56

Impacted Files
Coverage Δ

...n/kotlin/io/provenance/engine/config/Properties.kt
0.00% <0.00%> (ø)

...rovenance/engine/service/ChaincodeInvokeService.kt
0.00% <0.00%> (ø)

...provenance/engine/service/ProvenanceGrpcService.kt
0.00% <0.00%> (ø)

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 7897d78...d0ecd9b. Read the comment docs.


Static field not static fielding enough on Nova Sorc

Nova sorc is only static fielding bosses 2-3 times (To about 50-60% health)

what % are you hoping for?  Any more casts and it's wasted for most people.
2 casts = 56% life remaining
3 casts = 42% life remaining but will be limited to 50%, so even the 3rd cast is only half effective
This ignores minus resists from auras/spells/gear, but it would work out similar in terms of # of casts anyway.
If you really want to:
In the file "internal/character/lightning_sorceress.go" you could change the number of casts for each boss.
"step.SecondaryAttack(skill.StaticField, m.UnitID, 3,"
If you change the 3 it could cast more statics on that boss.
Make the changes within your internal folder, run the build batch file to include the changes in your koolo, then try run it again.

Hi
Sorry my mistake :D
thanks for the info, might fiddle with some things just out of curiosity
On Sun, 29 Sept 2024 at 20:33, Millionaar @.***> wrote:

what % are you hoping for?  Any
more casts and it's wasted for most people.
2 casts = 56% life remaining
3 casts = 42% life remaining but will be limited to 50%, so even the 3rd
cast is only half effective
This ignores minus resists from auras/spells/gear, but it would work out
similar in terms of # of casts anyway.
If you really want to:
In the file "internal/character/lightning_sorceress.go" you could change
the number of casts for each boss.
"step.SecondaryAttack(skill.StaticField, m.UnitID, 3,"
If you change the 3 it could cast more statics on that boss.
Make the changes within your internal folder, run the build batch file to
include the changes in your koolo, then try run it again.
—
Reply to this email directly, view it on GitHub
https://github.com/hectorgimenez/koolo/issues/500#issuecomment-2381593296,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARBVFOO6O3WNACGLT76JOR3ZZBP2JAVCNFSM6AAAAABPB5ECBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBRGU4TGMRZGY
.
You are receiving this because you authored the thread.Message ID:
@.***>

If you use lastest version it has validation on UI so you cant set it improperly =)


vagrant: Only set K8S_NODE_NAME if K8S=1

This allows Cilium to start without K8s in the Dev VM started with './contrib/vagrant/start.sh'.
Fixes: #11021
Signed-off-by: Jarno Rajahalme<EMAIL_ADDRESS>

test-me-please

This is not really tested in the CI, as if only affects the devVM started with contrib/vagrant/start.sh. Tested locally.

restart-ginkgo

Coverage increased (+0.003%) to 44.682% when pulling 7f71ad746bb61abc598df99824007f0671462f22 on pr/jrajahalme/vagrant-start-wo-k8s into 5370abedd319257f8c672748080d7eb0fde33f54 on master.

The criSocket failure seems more likely to be related to #11060, although that PR passed CI..

Ginkgo provisioning fail.

As said, this is ready to merge without passing the CI.

The PR that introduced the bug was backported to v1.7 and v1.6, thus breaking the runtime1 VM there. The fix is really small and doesn't conflict, so I think it's worth backporting to v1.7 to ease backport tests (I usually spin up the runtime1 VM to have the appropriate Go version when I test-compile backport PRs).
I'm adding the needs-backport/1.7 label and I will add this commit to https://github.com/cilium/cilium/pull/13402.


New package: DiffFusion v0.1.0

Registering package: DiffFusion
Repository: https://github.com/frame-consulting/DiffFusion.jl
Created by: @sschlenkrich
Version: v0.1.0
Commit: b8b2e3062808fd42ddf37074f99adacd4a9b7f5d
Reviewed by: @sschlenkrich
Reference: https://github.com/frame-consulting/DiffFusion.jl/commit/b8b2e3062808fd42ddf37074f99adacd4a9b7f5d#commitcomment-126309059
Description: High performance hybrid Monte Carlo simulation

Hi, congrats on the new package! Can I ask about the name? I'm rather skeptical cause it is very close to Diffusion.jl, which is apparently unclaimed may be useful for physical models or diffusion neural networks. Plus it seems prone to typos for your users.

Thanks @gdalle for your comment. I see your point.
The name DiffFusion is an abbreviation for 'differential diffusion'. We aim at adding Automatic Differentiation to the simulation framework, e.g., via Zygote and ForwardDiff. Sensitivity calculation for exposure simulations is a key challange which we want to adress with the package. That's why we wanted to have it reflected in the name.

[noblock]
Right, that makes sense. What about DifferentialDiffusion as a package name? It's already clearer and less error-prone, at least in my view

[noblock]
Yes, I thought about DifferentialDiffusion as well. But DiffFusion appears more catchy to me. To be honest, I would prefer to keep the name as is. And in case of difficulties I point ppl to the additional 'F' in the name.

[noblock]
In the spirit of the package naming guidelines I disagree, but I respect your point and so I switched my comment to non-blocking for the PR

[noblock]
Thanks @gdalle, much appreciated!


first build

{package} {version} {:snowflake:}
Destination channel: {Snowflake | defaults}
Links

{ticket_number}
Upstream repository
Upstream changelog/diff
Relevant dependency PRs:

...

Explanation of changes:

...

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_bduapyo7mt/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:15: avoid_noarch: noarch: python packages should be avoided
clone/recipe/meta.yaml:44: missing_description: The recipe is missing a description
===== Final Report: =====
0 Errors and 2 Warnings were found


Documentation: make the GitHub URLs depend on the current branch

Using git to retrieve the current branch and then storing it in the
epilogue where it's globally available. This can later be moved should
there be a conflicts on the names. Since the base URL is a variable now
and used in the blocks, had to change to using a parsed-literal so
they are rendered. One downside to this is that we no longer get the
consistent frame around the text like the code blocks.
Closes: #1755 (Make URLs version specific to provide backwards compatibility in docs)
Signed-off-by: Alexander Alemayhu<EMAIL_ADDRESS>

@scanf Did you generate this locally with sphinx to verify it works?

@tgraf Are you seeing anything wrong with the output? Did not see any issues. Was testing it on a different server, rendered below
https://alemayhu.com/cilium-staging/gettingstarted.html#getting-started-using-kubernetes
https://alemayhu.com/c.pdf

Tested locally now and works for local branches (X), but not for remote branches (origin/X). So git is returning  HEAD for those, but this shouldn't matter assuming the branches are locally checked out on sphinx.

@tgraf Are you seeing anything wrong with the output? Did not see any issues. Was testing it on a different server, rendered below

The only minor issue I can see is that the preformatted boxes are now rendered differently in my browser. The boxes with the links are rendered in a bigger font. Not an issue though.

Noticed the font and frame mismatch as well. So we are changing the default because the code directive does not parse the text and is mainly offering syntax highlighting. Not familiar with the customization options, but could take a look if you want.  Maybe sphinx has some way of creating own directives that inherit from others. If that's the case we could try to inherit from parsed-literal and then try to provide a separate CSS file for the font size and border with similar values as the code directive.

Noticed the font and frame mismatch as well. So we are changing the default because the code directive does not parse the text and is mainly offering syntax highlighting. Not familiar with the customization options, but could take a look if you want. Maybe sphinx has some way of creating own directives that inherit from others. If that's the case we could try to inherit from parsed-literal and then try to provide a separate CSS file for the font size and border with similar values as the code directive.

I think this is fine. File a github issue with the doc tag so we don't forget about this. I think eventually we want to tackle things like these.

@joestringer The tests failed. Do you think it is related with the L7 changes we found a week ago?
@scanf Can you rebase?

@aanm  This failure looks the same as #1362.

@aanm Rebased


Card capacity calculation corrected to csd [69,48]

Incorrect bits of CSD structure were used to calculate card capacity, corrected that and modified print statements and some comments to share information from specifications

Issue #25


Binary wheels?

Hi @dirko,
For dedupe, I've setup some scripts to automatically build binary wheels for OS X and windows for many of the dependencies. This makes it a lot easier for people to use these libraries.
ex: https://github.com/datamade/affinegap/blob/master/.travis.yml
https://github.com/datamade/affinegap/blob/master/appveyor.yml
When you push a tag to github, it automatically builds these wheels and deploys them to github.
Would you be interested in me writing these scripts for pyhacrf?

Hi @fgregg!
I'll definitely be interested - let me know how I can help (I should have some time over this weekend)

I'll make some pull requests that should get you 90% of the way there!

Now working (would be easy to adapt for this repo) https://travis-ci.org/datamade/pyhacrf
https://ci.appveyor.com/project/fgregg/pyhacrf
https://pypi.python.org/pypi/pyhacrf-datamade


Data structure for example usage

The example usage does not provide sufficient information for eventual users to use this code with their data. Please explain in more detail how Data/Test... were obtained and how could eventual users obtain similar data structures from their printing data.

Hey @olivecha,
Thanks for contributing with this issue!
We've updated the Documentation to address your feedback.
Specifically, we created a section called Acquirement of the Necessary Signals where the required information is now available.
If you need more details or have any other suggestions, feel free to let us know.
Best,
Thiago

Thanks for the clarification. Maybe there is still a little gap on how the raw data was processed into Matlab files or perhaps this is handled by your signal acquisition tools? Lets say I have a CSV with columns "time", "DirX on/off", "DirY on/off" and a WAV file with a sample rate of 32 kHz how could I input that into your tool ?
Also mention that the DirX/Y data is in every Test.mat file that was not clear in the documentation.

Thanks for the clarification. Maybe there is still a little gap on how the raw data was processed into Matlab files or perhaps this is handled by your signal acquisition tools? Lets say I have a CSV with columns "time", "DirX on/off", "DirY on/off" and a WAV file with a sample rate of 32 kHz how could I input that into your tool ? Also mention that the DirX/Y data is in every Test.mat file that was not clear in the documentation.

As mentioned in the updated documentation, for all three of the example datasets, the Data Acquisition Device (DAQ) used was the DL 850 oscilloscope from Yokogawa®, Tokyo, Japan. This DAQ present the option to save the waveform data directly in MATLAB format ( for reference, view page 16-10 of the DL850 user manual ).
I have updated the documentation to insert this information, alongside the information that the DIRX/Y data is in every Test.mat file.

That is more clear. It does make sense that a Matlab script takes Matlab files as an input.


API for listing {cipher} properties loaded

For auditing or migration tool purposes (moving the backing secret store to Vault for example), it would be helpful to allow retrieving a list of the key names and values that have {cipher} properties.
Right now they are transparently replaced with the values which is great for runtime use but it's indistinguishable from normal properties.
The alternative of parsing all the source configuration files to search for the word {cipher}, reconstructing dotted paths from YAML, and keeping track of actually referenced values, hierarchy, and overrides is non-trivial.
I'm open to alternate methods to accomplish this as well.
Straw man proposal
Property source example
spring:
  datasource:
    username: dbuser
    password: '{cipher}FKSAJDFGYOS8F7GLHAKERGFHLSAJ'

API endpoint
/decrypt/list
Output
spring.datasource.password=<actualpassword>

Let's see if there is other interest. You can always implement this on your own


Remove hacky sendViewChangedEvent

Description
This is a follow up to PR #1675.  It removes the hacky mechanism for generating viewChangedEvent events introduced, and causes the view change code to pass back the events directly.  It moves the old innerStack viewChange method into the legacy structures.
Motivation and Context
This is one in the long series of PRs trying to turn PBFT into more of a simple state machine, by removing the threading, and causing all state changes to be event driven.
The old code was pushing execution into the plugin layer directly by sending the thread into the plugin code.  This changeset removes this tight coupling via the viewChange() method by removing it from the innerStack interface and into the legacyInnerStack interface.  It also removes the viewChange empty implementation from obc-batch.go as it now consumes only the event.
How Has This Been Tested?
This has been tested locally via the unit tests.  The remainder should be covered by CI. As this is code restructuring, with no new function, no new tests are required.
Checklist:

[X] I have added a Signed-off-by
[X] Either no new documentation is required by this change, OR I added new documentation
[X] Either no new tests are required by this change, OR I added new tests
[X] I have run goimports, go vet, and golint. I have cleaned up all valid errors and warnings in code I have added or modified. These tools may generate false positives.  The goal is clean, consistent, and readable code.

Signed-off-by: Jason Yellick<EMAIL_ADDRESS>

LGTM

very nice

Hi @jyellick, thanks for the patch.  It looks like a rebase is needed to resolve the conflicts.

I am not familar with the subsystem enough to comment intelligently on the code, but since the consensus SMEs are happy, I am happy.
Reviewed-by: Greg Haskins<EMAIL_ADDRESS>


"oneOf" property in @Schema annotation ignored in resource response

Q
A

Bug or feature request?
Unknown

Which Swagger-Core version?
v2.0.0-rc2

Which Java version?
1.8.0_131

Which JAX-RS framework & version?
2.0.1

I try to annotate my jaxrs class in order to generate an open api 3.0.0 spec that supports inheritance / polymorphism. For some reason I'm not able to generate a responses object that reflects the semantic of "oneOf" in order to show the user that different "subtypes" of the response type may be returned.
In detail, I want to achieve the following result
{
    "openapi": "3.0.0",
    "paths": {
        "/test/bean": {
            "get": {
                "summary": "Test inheritance / polymorphism",
                "operationId": "getBean",
                "parameters": [
                    {
                        "name": "number",
                        "in": "query",
                        "description": "Test inheritance / polymorphism",
                        "required": true,
                        "schema": {
                            "type": "integer",
                            "format": "int32"
                        },
                        "example": 1
                    }
                ],
                "responses": {
                    "200": {
                        "description": "bean answer",
                        "content": {
                            "application/json": {
                                "schema": {
                                    "oneOf": [
                                        {
                                            "$ref": "#/components/schemas/MultipleSub1Bean"
                                        },
                                        {
                                            "$ref": "#/components/schemas/MultipleSub2Bean"
                                        }
                                    ]
                                }
                            }
                        }
                    }
                }
            }
        }
    },
    "components": {
        "schemas": {
            "MultipleSub2Bean": {
                "type": "object",
                "properties": {
                    "d": {
                        "type": "integer",
                        "format": "int32"
                    }
                },
                "description": "MultipleSub2Bean",
                "allOf": [
                    {
                        "$ref": "#/components/schemas/MultipleBaseBean"
                    }
                ]
            },
            "MultipleBaseBean": {
                "type": "object",
                "properties": {
                    "beanType": {
                        "type": "string"
                    },
                    "a": {
                        "type": "integer",
                        "format": "int32"
                    },
                    "b": {
                        "type": "string"
                    }
                },
                "description": "MultipleBaseBean",
                "example": {
                    "a": 0,
                    "b": "test"
                }
            },
            "MultipleSub1Bean": {
                "type": "object",
                "properties": {
                    "c": {
                        "type": "integer",
                        "format": "int32"
                    }
                },
                "description": "MultipleSub1Bean",
                "allOf": [
                    {
                        "$ref": "#/components/schemas/MultipleBaseBean"
                    }
                ]
            }
        }
    }
}

At present I use the following java code:
@Path("/test")
public class TestSwaggerApi {
    @GET
    @Path("/bean")
    @Operation(summary = "Test inheritance / polymorphism",
    responses = {
        @ApiResponse(description = "bean answer",
            responseCode = "200",
            content = @Content(
                mediaType = MediaType.APPLICATION_JSON,
                schema = @Schema(
                    oneOf = { MultipleSub1Bean.class, MultipleSub2Bean.class }
                )
            )
        )
    })
    @Produces({ MediaType.APPLICATION_JSON })
    public MultipleBaseBean getBean(
        @Context HttpServletRequest req,
        @Parameter(description = "Test inheritance / polymorphism",
        required = true,
        example = "1")
        @QueryParam("number") final int beanNumber) {

        // do something...
        ...
    }
}

@io.swagger.v3.oas.annotations.media.Schema(
    description = "MultipleBaseBean",
    subTypes = { MultipleSub1Bean.class, MultipleSub2Bean.class }
)
public class MultipleBaseBean {
    public String beanType;
    public int a;
    public String b;
}

@io.swagger.v3.oas.annotations.media.Schema(
    description = "MultipleSub1Bean"
)
public class MultipleSub1Bean extends MultipleBaseBean {
    public int c;
}

@io.swagger.v3.oas.annotations.media.Schema(
    description = "MultipleSub2Bean"
)
public class MultipleSub2Bean extends MultipleBaseBean {
    public int d;
}

But the generated api holds not the expected responses object:
{
    "openapi": "3.0.0",
    "paths": {
        "/test/bean": {
            "get": {
                "summary": "Test inheritance / polymorphism",
                "operationId": "getBean",
                "parameters": [
                    {
                        "name": "number",
                        "in": "query",
                        "description": "Test inheritance / polymorphism",
                        "required": true,
                        "schema": {
                            "type": "integer",
                            "format": "int32"
                        },
                        "example": 1
                    }
                ],
                "responses": {
                    "200": {
                        "description": "bean answer",
                        "content": {
                            "application/json": {
                                "schema": {
                                    "type": "string"
                                }
                            }
                        }
                    }
                }
            }
        }
    },
    "components": {
        "schemas": {
            "MultipleSub2Bean": {
                "type": "object",
                "properties": {
                    "d": {
                        "type": "integer",
                        "format": "int32"
                    }
                },
                "description": "MultipleSub2Bean",
                "allOf": [
                    {
                        "$ref": "#/components/schemas/MultipleBaseBean"
                    }
                ]
            },
            "MultipleBaseBean": {
                "type": "object",
                "properties": {
                    "beanType": {
                        "type": "string"
                    },
                    "a": {
                        "type": "integer",
                        "format": "int32"
                    },
                    "b": {
                        "type": "string"
                    }
                },
                "description": "MultipleBaseBean",
                "example": {
                    "a": 0,
                    "b": "test"
                }
            },
            "MultipleSub1Bean": {
                "type": "object",
                "properties": {
                    "c": {
                        "type": "integer",
                        "format": "int32"
                    }
                },
                "description": "MultipleSub1Bean",
                "allOf": [
                    {
                        "$ref": "#/components/schemas/MultipleBaseBean"
                    }
                ]
            }
        }
    }
}

I played around with the swagger test classes code, but I was not able to produce the requested result. I also tried to use the "implementation" property, but by doing so my "oneOf" property definition gets completely ignored.
Am I doing something wrong, or is this a missing feature?

It was indeed a missing feature / bug; correct support has been added in #2585, and is part of latest 2.0.0-SNAPSHOT version available on sonatype, and will be part of next release; closing ticket, please reopen if your issue isn't fixed.

Appreciate your work! Thank you very much!!!


Could not find a declaration module for 'styled-theming'.

Anyone got solution for this?
Please help.

Can you explain what exactly happened? It's hard to help when we don't know what the issue is in detail.

I installed the module using "npm install --save styled-theming" version is 2.2.0.
But then, when i try to import this API, i facing the issue.

Did you try npm install @types/styled-theming as well?

I tried, but seem not working

Going to close this since it’s not even our library. Please open an issue with them.


Release new version with APIv4 changes

Howdy!
Thanks for merging in #9, I wanted to follow up to ask when we could expect a new release to rubygems with these changes in place? Thanks!

@ssplatt any chance this could get some attention?

sorry, pushed.


zephyr_library_compile_options(): de-duplicate

PR #14776 / commit 915a35325562 changed function
zephyr_library_compile_options() to use MD5 instead of RANDOM for build
reproduction reasons. As later predicted by Sebastian Bøe in the PR
(thx), the names generated for these pseudo-libraries won't be unique
anymore if the exact same flag gets added more than once.
To reproduce the issue, simply add the following two lines in some
CMakeLists.txt file like samples/hello_world/CMakeLists.txt:
zephyr_library_compile_options("-Dfubar=barfu")
zephyr_library_compile_options("-Dfubar=barfu")
cmake will then fail like this:
CMake Error at zephyr/cmake/extensions.cmake:403 (add_library):
add_library cannot create target
"options_interface_lib_e689fdb7eb15d801c2f95dd61301fc5e" because
another target with the same name already exists.  The existing
target is an interface library created in source directory
"zephyr/samples/hello_world".  See documentation for
policy CMP0002 for more details.
Call Stack (most recent call first):
CMakeLists.txt:9 (zephyr_library_compile_options)
As suggested by Sebastian, discard duplicate options. After this fix
cmake succeeds with this warning:
CMake Warning at zephyr/cmake/extensions.cmake:404 (message):
-Dfubar=barfu already added, ignoring duplicate
Call Stack (most recent call first):
CMakeLists.txt:9 (zephyr_library_compile_options)
Fixes #15093
Signed-off-by: Marc Herbert<EMAIL_ADDRESS>

Codecov Report

Merging #15094 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #15094   +/-   ##
=======================================
  Coverage   52.87%   52.87%
=======================================
  Files         309      309
  Lines       45267    45267
  Branches    10451    10451
=======================================
  Hits        23934    23934
  Misses      16558    16558
  Partials     4775     4775

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 1eead93...3417d54. Read the comment docs.


I added the Login with Guest Button

I just added the Login Guest Button

I've reviewed and merged into the main #444 ticket, no need for a second reviewer since it isn't into developer. Thanks Lana!


Don't display download stats of metadata-only records

(I am simply transcribing the feedback received when presenting the May release)
This feedback was coming from the worry of an attendee that a record without attached files would not convey its usefulness well. People would see 0 downloads and assume it's not worthwhile, while it may actually be a case where the files were not deposited but the depositor is amenable to sharing them on a case by case basis (just don't want to upload the files in InvenioRDM).
I don't know if there are alternatives to hiding the stats, but it is the feedback that was given by the attendee.

Tracked in https://github.com/inveniosoftware/product-rdm/issues/13


chore(main): release 1.0.0

:robot: I have created a release beep boop
1.0.0 (2024-08-14)
⚠ BREAKING CHANGES

move to version 1.0.0

Features

move to version 1.0.0 (368a5ca)
move to version 1.0.0 (ed06f0e)

This PR was generated with Release Please. See documentation.

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

Project coverage is 92.51%. Comparing base (368a5ca) to head (f676df3).

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #57   +/-   ##
=======================================
  Coverage   92.51%   92.51%
=======================================
  Files          11       11
  Lines         775      775
=======================================
  Hits          717      717
  Misses         58       58

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

:robot: Release is at https://github.com/IFCA-Advanced-Computing/anjana/releases/tag/v1.0.0 :sunflower:


If I set height on video element, fullscreen is broken

If there is a css height/width set on my  element, then when I go to fullscreen, the video itself is still that size.
How can I force a size on the video, but still support fullscreen?
Example:
<video id='foo' class='afterglow' autoplay='true' controls style='max-height:140px;width:auto;' preload='auto' poster='' style='display: inline-block;'><source src='video/bar.webm' type='video/webm' /></video>

+1

You can try below.
$("button[data-plyr=fullscreen]").on("click", function() {
                setTimeout(function() {
                    $("video").css("height", "100%");
                }, 1000)
            });

I'm having same problem and It's not working.

@MTyson
It's simply will done with pure CSS:
video {
  max-height: 140px;
}
.plyr:fullscreen video{
  max-height: initial;
}

P.S: for best browser compatibility use autoprefixer.


Periodically save state and store in indexedDB

Fixes atom/atom#4161

[x] separate serialization from package deactivation
[x] extract serialization logic from unloadEditorWindow
[x] fix package manager tests
[x] save state asynchronously on keydown and mousedown, write tests
[x] get rid of AtomEnvironment state instance variable
[x] fix AtomEnvironment tests
[x] profile serialization time for various environment states
[x] store state in IndexedDB
[x] add command-line flag to clear indexedDB object store

Is this saved to .atom/storage ?
On the forum, when atom crash on startup, deleting the storage folder is a standard debug step.
Maybe there's an interest in discarding most of the state but restoring unsaved file content.

@jeancroy thanks for your comment. To answer your question - yes, the atom environment state is saved to .atom/storage. That said, I'm going to create an unsaved text buffers store that will be located elsewhere (possibly using IndexedDB). So in the event of a crash and deletion of the storage folder, your unsaved buffers will be preserved.
The unsaved buffer store will be a part of a separate pull request. I've updated the title of this one to be more specific as to what aspect of crash recovery will be addressed here.

This is looking good! How long does saveStateSync on average? Does it vary much depending on how many open buffers you have?

I wonder if we can use requestIdleCallback here once we have chrome 47+

I wonder if we can use requestIdleCallback here once we have chrome 47+

Yeah, we should start using that, as soon as https://github.com/atom/atom/pull/9627 lands

Did some profiling. Here are durations for saveState (synchronous serialization, and async writing to disk):

State
Time

20 tabs opened
2 ms

large unsaved buffer (jquery, 10K lines)*
11 ms

*Marker Layer serialization took 8.3 ms
20 tabs open:

large unsaved buffer (jquery, 10K lines)

Great job, @kuychaco. I think those are really impressive results: the ideal idle time is 50ms, which, if I am interpreting the results correctly, means we have room for serializing ~ 5 large files or ~ 400 open tabs.
Also, I find very interesting that most of the time is spent in dumping markers: I guess it's because we have to perform a full traversal of the tree, which can be time consuming for large files. I still wonder, though, if we can dissect that MarkerIndex call and maybe optimize based on that.
Also, @kuychaco, what's the time spent in JSON.stringify?
I am really excited about this! :sparkles:

Also, I find very interesting that most of the time is spent in dumping markers

I'd like to implement serialization of the MarkerIndex directly for this case. Then we don't have to traverse the tree and build an alternate structure. Instead we can just convert the tree to JSON directly.

/cc @atom/core feedback welcome. Note that the travis failure can be disregarded (flakey spec)
This PR is intended to improve crash recovery by serializing and saving the AtomEnvironment state regularly to minimize data loss.
Serializing
Serializing will occur upon debounced mousedown and keydown events (debouce interval is set to 1 second). As part of this PR, I've cleaned up the AtomEnvironment code and done away with the state instance variable. Assuming that the serialized state is successfully saved, that means that worst-case-scenario a lovely Atom user will lose only 1 second worth of work upon crash. And speaking of successful saving...
Saving
With this PR, the state is now stored in IndexedDB rather than the ~/.atom/storage folder. Here are some of the benefits of using IndexedDB:

transactional nature means:

when the disk is full we won't lose data as we would in the case of truncated files on disk
when two Atom windows have the same project folders open we don't have to worry about race conditions

IndexedDB can store JS objects so there is no need to JSON.stringify/parse the state (possible performance improvements for startup time if deserializing large state object)
state can be easily accessed in chrome dev tools, which is pretty cool I think

TODO: come up with a user-friendly way to clear the state from IndexedDB for debugging purposes

Very solid work @kuychaco. I did a pretty quick scan and things look good to me. Are you thinking of adding the --clear-workspace-state flag before merging?

@nathansobo thanks for the review! I think I will add the command-line flag before merging. Hope to get that done tonight.

:boom:

Hi @kuychaco
Is there mechanism to migrate state data from previous format to the new IndexedDB format ?
Here's one thread where a beta user think he lost all his state data on upgrade, but it was there, just ignored/not loaded.
https://discuss.atom.io/t/upgrading-to-1-7-0-beta0-blew-away-my-session-any-way-to-restore/26918
It could be interesting to avoid a widespread fear of data loss.

cc @as-cii ☝

Talked with @as-cii and he's planning on falling back to reading the state out of ~/.atom if it is present and there's nothing in the database.

Great to hear there is a fallback in the works. :+1:

[...] People care more about their session state than I realized.

People (me) have even written a package to list / inspect / make use of session state. It really is a nice feature of Atom.


Update snippet

Our snippet has changed, which is what was causing loading test failures. This updates the snippet to the newest version and also makes the test parameters a little nicer.
Two things about this

Tests still fail. This is due to the facade changes (https://github.com/segmentio/facade/pull/83) which have merged, but haven't trickled down through this repo's dependencies yet.
I would really like to test this end to end on a site before putting a rubber stamp on it.

@DingoEatingFuzz Apologies for the haphazard handling here. Looking like we never should have merged the previous pull, which had some bugs in its identify method and tests, so we went ahead and merged/tweaked this one to get us back to green. However, there are still some implementation details to iron out before we release.
It looks like the test failures were due to a mismapping of id in the identify method (mapping a nonexistent userId trait field to user_id, then in tests looking for it to have been mapped to _uid), which was separate from the page aliasing which was covered by the update to facade (that change has been propagated to analytics.js-core and is included in the test build and all releases going forward.
Can you please confirm 2 things?

The proper userId field for lytics' jstag's send method is _uid, and that others are unnecessary/redundant (id, user_id, userId). If this is not the case, we need to make some further changes to include id again. We can't find any docs pointing to proper native instrumentation that we can mimic here.

That if users were previously sending nothing for the stream field, and then begin sending "default", there will be no issues or discernible differences in their data to lytics.

The proper userId field for lytics' jstag's send method is _uid, and that others are unnecessary/redundant (id, user_id, userId). If this is not the case, we need to make some further changes to include id again. We can't find any docs pointing to proper native instrumentation that we can mimic here.

The property userId for jstag's send method is user_id. _uid is an anonymous identifier that jstag handles internally. user_id is what should be mapped within this integration.

That if users were previously sending nothing for the stream field, and then begin sending "default", there will be no issues or discernible differences in their data to lytics.

There will be no issues. default is equivalent to the lack of the option.

@sperand-io ping.

@DingoEatingFuzz gotcha, thanks for the response. looks like that's never been implemented correctly then.
Your original update changed the mapping from [userId => _uid] to [userId => user_id]:

...but we were thrown by the tests, which mapped [userId => id], contradicting both implementations.
We guessed wrong and fixed the implementation to match the tests, but that's why asked, and why we haven't released :) I'll fix that right now so that we properly map the userId to user_id.
As for the stream update, makes sense! Thanks for the explanation.

It definitely was never correctly implemented. The userId => user_id` was one of the original intentions of the PR. As for the tests being wrong and confusing, I'll take the blame on that. I just sorta looked at the tests for other integrations and followed suit.
Last question, is there a way for me to test this integration pre-release? I would like to make sure it works end to end before its broadcasted to our customers.

hmm, good question. i can do a manual standalone build of analytics.js with the latest integration and your settings if you can email me your settings: cid, apiKey, and stream
chris.sperandio [at] segment [dot] com

Email sent.


strip only newlines instead of all whitespace

I think it was always the intention to work like that and this bug is just a typo... I could be wrong obviously...
Attached is a small test case. It works fine after the patch.
leading_blanks_testcase.zip
Btw, nbconvert works correctly on this.

the failure https://travis-ci.org/spatialaudio/nbsphinx/jobs/424793148#L890 does not seem to be related to my change (but rather to a dead link)

Thanks, this was indeed a typo!
The second example in your test case already worked because it uses a different code path.
The datatype for "standard output" and "standard error" is called 'ansi', because it can be colored with ANSI escape sequences:
https://github.com/spatialaudio/nbsphinx/blob/448f00b98c7382dcd1bf5b3e322851ac62012cd9/src/nbsphinx.py#L166-L185
And thanks for reminding me of this dead link.
I wasn't sure if the failure is temporary, but it has been broken for quite some time now ...


Add suffix to Aardvark internal network filenames

Use the %int suffix for internal network files passed to AV so we can properly trigger DNS handling (or, more accurately, lack of DNS handling) over there. Also, to handle version migrations, if there is a previous file for the network named without the suffix, delete that.
This will unblock [1].
[1] https://github.com/containers/aardvark-dns/pull/447

CI test failures round 1 are expected. I will disable those tests until https://github.com/containers/aardvark-dns/pull/447 merges

@Luap99 PTAL

Tests are... passing. That's unexpected.

heya @mheon wanna push this through ?

I think we're good to merge.

Let me do some actual manual test on the update path to be sure the logic does what we intend, if it works I will merge